에이전트의 작업은 세 단계입니다. 맥락을 모으고, 실행하고, 결과를 확인합니다. 대부분의 조직이 마지막 단계를 사람에게 맡깁니다.
앤트로픽은 그 확인 절차를 스킬로 만들라고 제안합니다. 에이전트가 스스로 검사하고 실패한 것을 고친 뒤 넘어가는 구조입니다.
핵심은 개인 습관을 팀 인프라로 바꾸는 것입니다. 한 사람의 검수 요령이 모든 작업에 자동으로 적용됩니다.
AI가 만든 결과를 매번 당신이 검사하고 있다면,
병목은 AI가 아니라 당신입니다.
AI가 만든 결과를 받아 들고 매번 같은 것을 확인하는 사람이 있습니다. 숫자가 맞는지, 형식이 맞는지, 빠진 항목이 없는지입니다.
그 확인이 세 번째 반복됐다면 그것은 업무가 아니라 절차입니다. 앤트로픽이 7월 22일 공개한 글의 요지는 간단합니다. 그 절차를 사람이 아니라 에이전트가 돌게 만들라는 것입니다.
지난달 우리는 같은 것을 두 번 고쳤다면 스킬로 만들라는 앤트로픽의 사례를 다뤘습니다. 이번 글은 그 다음 칸입니다. 만드는 절차뿐 아니라 검사하는 절차도 스킬이 된다는 이야기입니다. 생성이 빨라질수록 확인이 병목이 되는 지금, 이 구분이 조직의 처리 용량을 가릅니다.
첫째, 검증 루프의 정의가 분명합니다. 원문은 이를 에이전트가 자기 작업을 스스로 점검하는 반복 주기로 규정합니다. 테스트를 돌리거나 검사 도구를 실행하거나 별도 점검을 수행한 뒤 실패한 것을 고치고 다음으로 넘어갑니다. 사람이 끼어드는 지점이 사라지는 구조입니다.
둘째, 대부분의 조직이 세 번째 단계를 비워 두고 있습니다. 에이전트가 일하는 방식은 세 단계입니다. 맥락을 모으고, 행동하고, 결과를 확인합니다. 앞의 둘은 이미 자동화돼 있습니다. 확인만 사람의 눈으로 돌아옵니다. 자동화율이 3분의 2에서 멈추는 이유가 여기 있습니다.
셋째, 검증 스킬은 짧은 문서 한 장입니다. 특별한 개발이 필요하지 않습니다. 이름과 설명, 쓸 수 있는 도구, 그리고 무엇을 어떻게 확인할지 적은 평문이 전부입니다. 원문은 오류 로그에 요청 식별자가 들어 있고 요청 본문은 들어 있지 않은지 확인하는 스킬을 예로 듭니다.
| 스킬 파일의 구성 | 역할 | 작성 요령 |
|---|---|---|
| 이름 | 스킬을 부르는 식별자 | 동작을 드러내는 짧은 이름 |
| 설명 | 언제 이 스킬을 쓰는지 | 발동 조건까지 함께 적기 |
| 사용 가능 도구 | 읽기, 수정, 검색 등 권한 범위 | 필요한 최소한만 부여 |
| 본문 | 무엇을 어떻게 확인할지 | 새 팀원에게 설명하듯 평문으로 |
출처: de Oliveira (2026, July 22), 예시 스킬 구조 재구성.
넷째, 배치 방식이 네 가지로 정리됩니다. 단독으로 불러 쓰는 방식은 보안 점검이나 접근성 감사처럼 여러 작업에 걸친 검사에 맞습니다. 만드는 스킬 안에 심어 두면 산출과 동시에 검사가 돕니다. 여러 스킬을 이어 붙이면 순서대로 돌고, 이 연쇄가 안정되면 모든 병합 요청에 자동으로 걸리는 관문이 됩니다.
다섯째, 앤트로픽 팀 자신이 연쇄로 씁니다. 클로드 코드 팀은 코드 검토, 단순화, 검증, 디자인 점검을 차례로 잇는다고 밝혔습니다. 하나의 요청이 네 개의 관문을 통과한 뒤 사람에게 옵니다. 사람이 보는 것은 걸러진 결과이지 초안이 아닙니다.
여섯째, 이 구조는 개발 밖에서도 그대로 작동합니다. 확인 절차가 반복되는 업무라면 종류를 가리지 않습니다. 계약서 초안에서 위약금 조항과 관할 법원이 빠지지 않았는지 보는 일, 보고서의 숫자가 원자료와 맞는지 대조하는 일, 대외 문서가 회사 표기 규칙을 지켰는지 확인하는 일이 모두 같은 형태입니다.
차이는 하나뿐입니다. 개발 조직은 테스트라는 이름으로 이 절차를 이미 문서화해 뒀습니다. 나머지 조직은 그 절차가 담당자의 머릿속에만 있습니다. 검증 스킬을 만드는 일은 사실 그 암묵지를 꺼내 적는 일입니다.
일곱째, 그래서 이것은 인력 문제로 이어집니다. 검수를 잘하는 사람의 기준이 문서로 나오면, 그 기준은 그 사람이 자리에 없어도 작동합니다. 반대로 문서로 꺼내지 않으면 그 사람의 퇴사와 함께 사라집니다. 원문의 표현대로 개인 작업 방식을 팀 인프라로 바꾸는 일입니다.
지난 한 주 동안 AI 결과물을 받고 반복해서 본 항목을 떠올려 한 줄로 쓰세요. 원문이 제시한 첫 단계가 이 기록입니다. (오늘, 10분)
코드가 아니라 문장으로 씁니다. "각 항목마다 원자료의 숫자와 대조하고, 다르면 표시한다" 수준이면 충분합니다. (이번 주)
새로운 작업 두 건에 적용해 실제로 발동하는지 확인하고 문장을 다듬으세요. 한 번으로는 발동 조건이 맞는지 알 수 없습니다. (이번 주)
검증 스킬 두세 개가 자리를 잡으면 순서대로 잇고 모든 산출물이 통과하도록 기본 절차에 넣으세요. 사람은 걸러진 결과만 봅니다. (이번 분기)
성과 수치가 제시되지 않았습니다. 원문은 시간 절감이나 오류 감소를 숫자로 밝히지 않습니다. 방법론 소개이지 효과 검증 보고가 아닙니다. 도입 전에 자체 측정 기준을 세워야 합니다.
개발 워크플로 중심의 사례입니다. 예시가 코드 검토와 테스트에 집중돼 있습니다. 비개발 업무로 옮길 때는 확인 항목을 스스로 정의해야 하고 그 정의가 절반 이상의 일입니다.
검증 스킬 자체가 틀릴 수 있습니다. 잘못 쓰인 검사 기준은 틀린 결과를 통과시킵니다. 스킬을 만든 뒤에도 주기적으로 그 기준이 맞는지 사람이 되짚어야 합니다.
자동화가 책임까지 옮기지는 않습니다. 관문을 통과했다는 사실이 결과에 대한 책임을 없애지 않습니다. 최종 승인의 주체와 근거는 사람 쪽에 남겨 두어야 합니다.
생성은 이미 자동입니다. 확인까지 자동이 될 때 비로소 사람의 시간이 남습니다.
검증 루프(Verification Loop): 에이전트가 자기 작업을 스스로 점검하고 실패한 부분을 고친 뒤 다음으로 넘어가는 반복 주기입니다.
스킬(Skill): 특정 작업의 절차를 담은 짧은 문서입니다. 조건이 맞으면 자동으로 불려 나와 적용됩니다.
연쇄(Chaining): 여러 스킬을 순서대로 이어 하나의 흐름으로 만드는 방식입니다.
관문(Gate): 모든 산출물이 통과해야 하는 자동 점검 지점입니다. 통과하지 못하면 다음 단계로 넘어가지 못합니다.
도구 권한(Allowed Tools): 해당 스킬이 쓸 수 있는 기능의 범위입니다. 읽기만 허용할지 수정까지 허용할지 정합니다.
- de Oliveira, D. (2026, July 22). Building verification loops in Claude Code with skills [Article]. Anthropic. (원문 보기 ↗)