결과 검증

전제

에이전트는 못 하면 멈추는 게 아니라, 그럴듯하게 틀린 걸 내놓는다.

일반 프로그램은 못 하면 에러를 내고 멈춘다. 그래서 에러가 없으면 대체로 맞다.
에이전트는 다르다. 막히면 그럴듯한 것을 만들어 계속 가고 "완료했습니다"라고 보고한다.
사람에게 좋은 평가를 받도록 학습됐기 때문에 "모르겠습니다"보다 그럴듯한 답을 선호한다.

→ 에러가 없다는 것이 맞았다는 뜻이 아니다. 이 한 줄이 이 스킬의 전부다.

1. 말이 아니라 필드를 본다

구조화된 완료보고를 받았다면 서술을 읽기 전에 필드부터 본다.

필드	의심 신호
unfinished	비어 있는데 summary에 "일부"·"대략"·"기본적으로" 같은 말이 있으면 모순
tests.ran	false인데 "동작 확인했다"고 하면 확인 안 한 것
commands_run	비어 있는데 실행했다고 하면 모순. exit_code도 본다
modified_files	디스크 실제 상태와 대조한다. 보고에 없는 파일이 바뀌었을 수 있다
blocked	true면 즉시 사람에게 결정을 요청. 대신 결정하지 않는다

unfinished가 여러 건 올라온 것은 나쁜 신호가 아니라 정직한 신호다.
오히려 전부 완벽하다는 보고를 더 의심한다.

2. 반드시 직접 대조한다

보고서에 적힌 숫자가 아니라 그 숫자가 나온 원본을 연다.

• 수치 — 파일을 직접 세거나 읽어서 맞춰본다
• 파일 목록 — git status, 수정시각, 실제 존재 여부
• URL — 실제로 열어본다. HTTP 코드로 확인하고, 403 등은 봇 차단일 수 있으니
  다른 경로로 재확인한다. 한 번 실패했다고 없는 것으로 결론내지 않는다
  (위임한 조사의 출처는 여기서 그치지 않는다 — §2-1을 따른다)
• 그래프·문서 — 열어서 눈으로 본다. "생성 완료"와 제대로 그려진 건 다르다

한 보고에 실행이 여러 번 담겼으면, 수치와 산출물이 같은 실행 것인지 맞춰본다.

실제 사고: 완료보고에 두 실행의 결과가 함께 적혀 있었다 — 하나는 이송 성공,
다른 하나는 놓기 정밀. 좋은 수치만 눈에 들어와 "이송 성공, 놓기 정밀"로 읽힌다.
그런데 남겨진 캡처는 실패한 쪽 실행의 것이었다. 열어 보니 그리퍼가 비어 있었다.

→ 실행이 여러 번이면 어느 수치가 어느 실행 것인지, 산출물은 그중 무엇인지를
반드시 갈라 놓는다. 보고가 정직해도 읽는 쪽이 합쳐서 오해할 수 있다.

2-1. 위임한 조사는 보고가 아니라 출처가 근거다

조사를 넘겼다면, 돌아온 문서는 근거가 아니라 근거의 목록이다.

받은 요약이 아무리 정연해도 그대로 결정권자에게 올리지 않는다.
인용된 URL을 직접 열어 읽은 뒤에야 근거가 선다.

실제 사고: 데이터셋 조사를 검수하면서 URL 8개 중 7개만 열어보고 "검수 완료"로
보고했다. 표본 확인을 검증이라고 적은 것이다. 남은 하나가 틀렸다면 표 전체의 신뢰가
무너지는데, 그 가능성을 열어둔 채 완료로 넘겼다.

• 전량 연다. §2의 재확인(다른 경로·봇 차단 우회)까지 하고도 못 열면, 그 항목은
  표에서 내리거나 "미확인"으로 강등한다. 한 번 막혔다고 바로 버리지는 않는다
• 열렸다는 것과 값이 맞다는 것은 다르다. 페이지를 읽고 그 숫자가 실제로 거기
  있는지 확인한다. 논문이면 표·절 번호까지 맞춘다
• 출처를 직접 읽지 않은 항목은 상위 보고에 올리지 않는다. 불가피하면
  "위임 결과이며 미검증"이라고 항목마다 명시한다
• 검수자가 전량 열어볼 것이므로, 지시서 단계에서 열 수 있는 URL을 의무화한다
  → [[task-brief]] §3

⚠️ 여는 방법이 요약이면 같은 함정에 빠진다. 요약 도구·검색 스니펫은 원문이 아니다.

실제 사고: 위임 결과의 수치가 틀렸다고 판단해 뒤집으려 했는데, 원문 표를 직접 파싱해 보니
표가 두 열(Number·Labels)이었고 요약 도구가 뒤쪽 열을 읽어 잘못 전한 것이었다.
실행자가 옳았고 검토자가 틀렸다. → 수치를 다투는 자리에서는 원문 본문을 직접 긁어라.

이미지 산출물은 반드시 눈으로 본다. 파일 목록과 "생성 완료" 보고로는 아무것도 알 수 없다.
실제 사고: 캡처 4장이 정상 생성됐고 보고도 완료였는데, 열어 보니 한 장은 화면 절반이
새까맸다. 두 창이 있다는 것과 두 창에 그림이 나온다는 것은 다르다.

이유는 능력 불신이 아니라 책임의 위치다. 위임 결과를 근거로 올리는 순간 그 주장의
책임은 검수자에게 넘어온다. 읽지 않은 것을 책임질 수는 없다.

3. "안 된다"는 보고도 검증 대상이다

특히 그 보고가 방침을 바꿔달라고 요구할 때 그렇다.

실제 사례: "현재 환경에 그 기능이 없어 실행할 수 없다, 대체 방안을 정해달라"는 보고를
받고 직접 해보니 그냥 됐다. 결정적 단서는 이미 같은 방식으로 돌아가는 것이 있었다는
점이었다. 실제로 해보지 않고 목록만 조회해 판단한 것이었다.

→ 불가 보고를 받으면 가장 싼 방법으로 한 번 직접 시도해본다.

"없다"와 "내가 못 간다"를 갈라라. 실행자는 이 둘을 구분해서 말하지 못한다 —
자기 환경에서 안 보이면 없는 것으로 보고할 수밖에 없다.

실제 사례: 외부 자산 서버에 접근하지 못해 "자산을 찾을 수 없다"고 멈춘 보고를 받았는데,
검토자가 같은 주소를 직접 조회하니 멀쩡히 응답했다. 막힌 것은 자산이 아니라
실행자의 네트워크였다. 경로를 확인해 넘겨주자 바로 풀렸다.
→ 접근 실패 보고에는 무엇을 어떤 경로로 시도했는지를 함께 받아야 이 구분이 선다.

4. "했다"와 "반영됐다"는 다르다

실제 사례: 지표를 24개 전부 측정해 파일까지 정상 생성했는데, 최종 결과물은
코드에 박힌 옛 값을 썼다. 24개 중 13개가 틀렸고 에러는 0건이었으며
그래프도 멀쩡해 보였다. 결과적으로 정반대 결론을 보여주고 있었다.

→ 같은 의미의 값이 두 군데에 있으면(코드 상수 vs 측정 결과) 언젠가 어긋난다.
"산출물의 값 == 원천 값" 대조를 완료 기준에 넣는다.

5. 증거를 요구한다

"했습니다"는 결과물이 아니다. 로그 경로, 파일 생성 시각, 개수를 묻는다.
물어보면 바로 나온다. 안 나오면 안 한 것이다.

6. 검토 결과 분기

NO를 하나로 뭉뚱그리지 않는다. 무엇이 잘못됐는지에 따라 되돌아갈 위치가 다르다.

판정	다음 행동
NO — 재작업	같은 세션에 피드백을 보낸다(맥락 유지되므로 재설명 불필요). 작업 진행 단계로 돌아간다 — 지시서·역할 배정 자체는 맞았고 결과물만 고치면 되는 경우
NO — 재설계	역할 구분 단계로 돌아간다 — 애초에 관리자/실행자 배정이 잘못됐거나, 지시서·범위가 틀린 경우. 재작업으로는 못 고친다
OK	작업 문서·스킬을 갱신한다. 내가 할 것과 실행자에게 하달할 것을 나눈다

이 판단(재작업 vs 재설계)도 검토자의 판단이다 — 결과물만 탓하기 전에 애초에 맞는 사람에게
맞는 일을 맡겼는가를 먼저 되짚는다.

새 사실이 나왔으면 다른 작업보다 먼저 문서를 갱신한다 — 낡은 전제 위에 다음 작업이
쌓이는 것을 막는다.

내가 직접 한 작업(설계·문서·조율)도 이 검토를 그대로 거친다. 완료보고 → 검토 순서는
실행자 결과물과 동일하다 — "내가 직접 했으니 검토 없이 OK"는 이 스킬이 막으려는 바로 그 실패다.

실행자에게 문서·스킬 갱신을 하달했다면, 그 결과도 다시 검토한다. 하달 자체가 완료가
아니다 — 실제로 무엇을 고쳤는지 재확인하는 짧은 루프(재검토 → NO면 다시 하달,
OK면 종료)를 거친 뒤에야 끝난다.

7. 내 결과를 검토할 때

이 스킬은 남의 결과에만 쓰는 것이 아니다. 작성과 검토는 분리된 패스여야 한다.
방금 내가 만든 것을 같은 흐름에서 "잘 됐다"고 판정하지 않는다.
최소한 주장과 증거를 나란히 놓고 다시 본다.

연계

• 검증 수단을 무엇으로 할지 고르는 것은 [[verification-route]].
  화면을 직접 봐서 얻은 인상은 이 스킬이 요구하는 근거가 되지 않는다.

• 지시서를 쓸 때는 [[task-brief]]

• 재설계 판정이면 역할 배분부터 다시 — 설치된 워크플로우에 배분 스킬이 있으면 그것을 따른다

• 실행자 세션에 피드백을 보내는 방법은 그 워크플로우의 위임 스킬을 따른다

이 스킬은 항상 설치되는 공통 계층이므로 특정 워크플로우의 스킬을 이름으로 가리키지 않는다.
이름으로 적으면 다른 워크플로우를 설치했을 때 없는 스킬을 가리키게 된다.

이력 (필수 기록)

• 생성일: 2026-08-26
• 업데이트 횟수: 4
• 최근 업데이트: 2026-09-15 (이력의 사례를 본문과 대조해 중복 제거)
• 사용 이력 — 사례는 전부 §2~§4 본문에 있다. 여기는 언제 무엇이 늘었는지만.
  • 2026-09-15 — 이력이 본문 사례를 그대로 되풀이하던 것을 압축. 원본은 SKILL.md.bak_20260915
  • 2026-08-31 — §2에 "여러 실행이 섞인 보고" 추가. 좋은 수치만 눈에 들어왔는데
    남겨진 캡처는 실패한 쪽 것이었다 — 보고가 정직해도 읽는 쪽이 합쳐서 오해한다
  • 2026-08-31 — §2-1에 둘 추가. 요약 도구도 원문이 아니다(2열 표를 요약기가 잘못 읽어
    검토자가 틀렸다) · 이미지는 눈으로 본다(정상 생성·완료 보고된 캡처 한 장이 절반 검음).
    둘 다 "열어라"는 규칙만으로는 안 잡혔고 여는 방법까지 적어야 잡혔다
  • 2026-08-28 — §2-1 신설. 사용자 지시로 기준 확정: "실행자의 대답은 사용자 요청의 근거가
    될 수 없다." 계기는 검수자 자신의 사고(URL 8개 중 7개만 열고 "검수 완료").
    §2에 "URL은 열어본다"가 이미 있었으나 전량인지 표본인지가 없어 표본 확인이 통과됐다 —
    🔴 규칙에 수량이 빠지면 최소한으로 해석된다
  • 2026-08-27 — §6 개정: NO를 "재작업(작업 진행 복귀)"과 "재설계(역할 구분 복귀)"로 분리.
    직접 한 작업도 동일 검토 대상, 하달한 문서·skill 갱신도 재검토 루프
  • 2026-08-26 — 위임 메커니즘 스킬에서 분리. 검증은 위임 방식과 무관하게 필요하다