[Claude Code] AI 결과물 검수의 사각지대 — 검수 도구 2종 소스를 뜯어보니 서로 절대 못 잡는 게 있었다

[Claude Code] AI 결과물 검수의 사각지대 — 검수 도구 2종 소스를 뜯어보니 서로 절대 못 잡는 게 있었다

한줄 요약

AI 결과물 검수 도구 두 개(research-survey · SpecKit)의 실제 코드를 읽고 비교했더니, 하나는 "지어낸 것"만 잡고 다른 하나는 "빠뜨린 것"만 잡는다는 걸 확인했습니다. 제 파이프라인에 뚫려 있던 구멍 3개를 찾았습니다.

이런 분들께 도움돼요

• AI가 만든 결과물을 AI로 검수하려는데, 뭘 어떻게 검사해야 할지 막막한 분

• 체크리스트를 만들어 돌리는데도 자꾸 같은 실수가 재발하는 분

• 검수 도구를 도입하려는데 어떤 걸 골라야 할지 판단이 안 서는 분

소개: 시도하고자 했던 것과 그 이유

문제 상황 (Before)

앞선 사례([Claude Code + SpecKit] AI로 개발한 프로그램으로 지속 운영 가능할까?)에서 이런 일을 겪었습니다.

체크리스트 12개 항목이 전부 통과(✅)했는데, 그다음 단계에서 결함이 21건 나왔습니다.

그때는 "체크리스트가 허술했나 보다"라고 넘어갔습니다. 그런데 이상한 게 있었습니다.

1차 검수 → 10건 발견
    ↓ (전부 수정)
재점검  → 신규 7건 발견  ← ???

같은 명령을 한 번 더 돌렸을 뿐인데 7건이 새로 나왔습니다. 1차에서는 왜 못 봤을까요?

그중 하나가 이랬습니다. 문서에 #1e1b4b라는 색상값을 "골드(금색)"라고 적어놨는데, 이 색은 실제로는 인디고(남색)였습니다. 문서끼리는 앞뒤가 맞았으니 1차 검수가 통과시킨 겁니다.

즉 검수가 뭘 못 보는지를 검수 자체는 알려주지 않습니다.

시작하게 된 계기

마침 스터디에서 쓰는 research-survey라는 도구가 "3중 검증"을 내세우고 있었습니다. 소개 문구만 봐서는 제가 쓰던 SpecKit과 비슷해 보였습니다.

그래서 물었습니다.

"둘 중 뭐가 더 나아?"

이 질문이 틀렸다는 걸 나중에 알게 됩니다. 그게 이 글의 핵심입니다.

진행 방법: 어떤 도구를 사용했고, 어떻게 활용했나요?

사용한 도구

• 도구: Claude Code (터미널에서 쓰는 AI)

• 모델: Claude Opus 5

• 검토 대상: research-survey 플러그인 v0.8.0 · SpecKit (GitHub spec-kit)

• 특이사항: 두 도구 다 설명 문서가 아니라 실행되는 파일을 읽혔습니다

AI와 협업한 과정

1. 첫 시도 — 소개 문서만 읽혔다가 헛다리

상황: 두 도구의 README를 읽고 비교하게 했습니다.

이렇게 요청했어요:

research-survey의 검수와 SpecKit의 검수 방법을 비교분석해서 알기 쉽게 설명해줘

결과: 둘 다 "3중 검증", "일관성 검사" 같은 비슷한 말을 쓰고 있어서, 비교표를 만들었더니 거의 같은 도구처럼 보였습니다.

느낀 점: 소개 문서는 잘 보이고 싶은 쪽으로 씁니다. 둘 다 "꼼꼼하게 검사합니다"라고 쓰지, "저희는 이건 못 잡습니다"라고 쓰지 않습니다.

2. 방향 전환 — 설명 말고 "실제로 돌아가는 것"을 읽혀라

여기서 요청을 바꿨습니다.

이렇게 요청했어요:

[도구]의 검수 방법론의 근거는 뭐야?

한 단어 차이인데 결과가 완전히 달라졌습니다. AI가 소개 문서를 건너뛰고 실제 검사 프로그램과 개발 이력을 읽기 시작했습니다.

결과: 소개 문서에 한 줄도 없던 것들이 쏟아졌습니다.

① 검사 프로그램 안의 주석에 "왜 이렇게 고쳤는지"가 적혀 있었습니다

# 정수를 검사에서 뺐더니 '999개 데이터셋'이라는 지어낸 숫자를 놓쳤다

처음엔 숫자 검사에서 정수를 제외했답니다. 오탐이 많아서요. 그랬더니 AI가 지어낸 "999"를 통과시켰습니다. 그래서 다시 넣었다는 기록입니다.

② "검사를 못 하면 무조건 실패로 떨어뜨린다"는 규칙

"조용한 검사 생략은 우회 통로가 된다"

원본을 못 찾으면 그냥 넘어가는 게 아니라 실패 처리합니다. 안 그러면 "검사 안 한 것"이 "통과한 것"으로 둔갑하니까요.

③ 개발 과정에서 실제로 놓친 사건 3건이 실명으로 기록돼 있었습니다

그중 한 건이 소름 돋았습니다.

명령어 실행 방식 문제로 검수 프롬프트가 첫 줄에서 잘렸는데, 결과는 "지적사항 0건"으로 보고됐다

검수가 아무 문제를 못 찾은 게 아니라, 검수 자체가 실행되지 않았는데 "깨끗함"으로 보고된 겁니다.

느낀 점: 도구를 평가할 땐 "뭘 잡는다고 하는가"가 아니라 "뭘 놓쳤던 기록이 있는가"를 봐야 합니다. 후자가 훨씬 정직한 정보입니다.

3. 결정적 발견 — 두 도구는 애초에 다른 걸 검사한다

양쪽을 다 읽고 나서야 보였습니다. 비교표의 첫 줄부터 달랐습니다.

비유하자면 이렇습니다.

• research-survey = 논문 심사위원. "이 인용 진짜 있는 거 맞아요?"

• SpecKit = 공사 감리. "설계도에 있는 방이 실제로 다 지어졌나요?"

심사위원은 안 지어진 방을 못 찾고, 감리는 가짜 인용을 못 찾습니다.

4. 서로의 구멍을 실제 사례에 대입

제가 겪었던 21건이 이 틀에 정확히 들어맞았습니다.

SpecKit이 놓친 것 — 지어낸 값

#1e1b4b를 "골드"라고 쓴 그 건. 문서 A와 문서 B가 사이좋게 같이 틀렸으니 통과했습니다.

research-survey 식으로 말하면 이건 "발명 수치"입니다. 원본과 대조하는 층이 있었다면 1차에 걸렸을 겁니다. SpecKit에는 대조할 원본이 파이프라인에 없습니다.

research-survey가 놓치는 것 — 빠뜨린 것

반대로 research-survey는 "쓴 게 맞나"만 봅니다. "써야 했는데 안 쓴 것"은 경고만 띄우고 실패로 안 떨어뜨립니다.

SpecKit에는 이런 표가 있습니다.

이건 요약 검수 쪽엔 아예 없는 개념입니다.

그리고 SpecKit만 있는 것 — "시키지도 않은 걸 했다"

SpecKit은 어긋남을 4가지로 나눕니다.

빠진 것만 찾는 검수는, AI가 슬쩍 끼워 넣은 것을 절대 못 잡습니다. 제 사례에서 가장 심각한 등급(CRITICAL)이 나온 지점이 정확히 여기였습니다.

인상적이었던 순간

"오!" 했던 순간: research-survey가 자기 검수기를 검수하는 장치를 갖고 있다는 걸 발견했을 때입니다.

일부러 틀린 문서 5개를 심어놓고, 검수기가 몇 개나 잡는지 점수를 냅니다.

일부러 심은 오류 5종        정상 문서 1개(대조군)
├ 없는 숫자 지어내기         └ 이건 통과해야 정상
├ 인용 잘못 붙이기
├ 이력 조작
├ 출처 빼기
└ 필수 항목 빼기

측정 결과가 이랬습니다.

마지막 줄이 진짜입니다. 그 층을 붙이기 전엔 5개 중 2개를 놓치고 있었습니다. "이 검사가 필요하다"를 말이 아니라 숫자로 증명한 겁니다.

그리고 정상 문서 오탐 0도 같이 봐야 합니다. 안 그러면 전부 실패 처리해서 100% 잡았다고 우길 수 있으니까요.

제 파이프라인에는 이게 없었습니다. 재점검에서 7건이 더 나온 걸 제가 알 수 있었던 건 순전히 한 번 더 돌려봤기 때문이지, 도구가 알려준 게 아니었습니다.

막혔던 순간과 해결

문제 1: 참고할 PDF 자료를 AI가 못 읽었습니다. 글자 인코딩이 특수해서 변환 도구를 설치하려다 3번 실패했습니다.

해결: 같은 내용의 마크다운(.md) 파일을 대신 넣어줬습니다. 20분 삽질이 30초로 끝났습니다. → 💡 PDF가 안 읽히면 도구 설치로 싸우지 말고, 원본을 다른 형식으로 구하는 게 빠릅니다.

문제 2: "둘 중 뭐가 나아?"라고 물었더니 AI가 성실하게 우열을 매겨서 답했습니다. 그런데 읽어보니 근거가 빈약했습니다.

해결: 질문을 "각각 뭘 못 잡나?"로 바꿨습니다. 그러자 비교가 아니라 분류가 나왔고, 그게 훨씬 쓸모 있었습니다. → 💡 AI에게 "우열"을 물으면 억지로라도 순위를 만들어냅니다. "차이"를 물어야 합니다.

결과와 배운 점

Before vs After

결과물 — 제 파이프라인에서 찾은 구멍 3개

① 대조할 원본이 없다 문서끼리만 비교하니 둘 다 틀리면 통과합니다. 인디고를 골드라고 부른 그 건.

② 만든 AI가 자기 것을 채점한다 research-survey는 이걸 명시적으로 금지합니다.

"만든 쪽은 자기 결과물을 채점하지 않는다. 검수는 저자 의도를 안 알려준 상태로 독립된 쪽이 한다"

심지어 검수자에게 "원래 이렇게 하려던 거였어"라고 설명하는 것 자체를 금지합니다. 설명을 들으면 봐주게 되니까요. 제 경우 같은 대화창에서 같은 AI가 채점했습니다. 재점검 7건이 그 대가입니다.

③ 검사를 못 하면 조용히 넘어간다 제 사례에서 "커버리지 명목 100% / 실질 67%"가 나왔습니다. 33%는 검사가 안 된 건데 통과로 집계된 겁니다.

배운 점과 나만의 꿀팁

효과적이었던 것

1. 소개 문서 말고 실행 파일을 읽혀라. 설계 의도는 코드 주석에 있습니다. 소개 문서는 자기 약점을 안 씁니다.

2. "이 도구가 놓쳤던 기록 있어?"라고 물어라. 있으면 좋은 도구입니다. 자기가 뭘 놓쳤는지 아는 도구가 안전합니다.

3. "우열" 말고 "차이"를 물어라. 우열을 물으면 AI가 억지 순위를 만듭니다.

4. 일부러 틀린 걸 심어서 검수기를 시험하라. 검수기가 제대로 도는지 확인할 유일한 방법입니다.

이렇게 하면 안 돼요

1. "검수 통과"를 결과로 믿지 마세요. 검수가 실행조차 안 됐는데 "지적 0건"이 나온 실사례가 있습니다.

2. 만든 AI에게 채점시키지 마세요. 최소한 새 대화창에서 돌리세요. 이것만으로도 꽤 잡힙니다.

3. "확인 불가"를 통과로 처리하지 마세요. 이게 가장 흔하고 가장 위험한 구멍입니다.

4. 체크리스트를 O/X로만 만들지 마세요. 제 12개 항목이 전부 O였는데 21건이 남았습니다. 등급(심각/보통/경미)으로 나누는 순간 결함이 드러났습니다.

과정 중 시행착오

가장 큰 시행착오는 "좋은 도구 하나를 고르면 된다"고 생각한 것입니다.

두 도구 다 잘 만들어졌습니다. 문제는 잘 만들어진 도구도 자기가 안 보는 영역이 있다는 겁니다. 그리고 그 영역은 소개 문서에 안 적혀 있습니다.

정직하게 덧붙이면, research-survey에도 약한 데가 있습니다.

• 시험용 오류가 5개뿐입니다. 5/5는 통계적으로 강한 증거가 아닙니다. 6번째 유형은 아무도 모릅니다.

• 오류를 심은 사람 = 검수기를 만든 사람입니다. 자기가 아는 함정만 심게 됩니다. (이 도구가 그렇게 강조하는 "만든 자가 채점하면 안 된다"가 정작 이 층위에선 안 지켜집니다)

앞으로의 계획

다음 단계

• 제 검수 파이프라인에 일부러 틀린 것 심어보기 — 모순 3건을 기획서에 심고 몇 개 잡는지 측정

• 검수는 새 대화창에서 돌리도록 절차 변경

• "확인 불가"를 통과가 아니라 실패로 바꾸기

다른 업무에 적용한다면?

개발이 아니어도 똑같이 씁니다. 이 표 하나로 판단하면 됩니다.

가장 흔한 실수는 원본이 있는데도 정합 검수만 하는 것입니다. 인용이 붙어 있으면 안심하는 거죠. 인용이 붙어 있는 것과 그 인용이 진짜인 것은 완전히 다른 얘기입니다.

도움이 필요한 부분

일부러 심는 오류를 본인이 만들면 자기가 아는 함정만 심게 됩니다. 이걸 어떻게 넘는지 아시는 분 계시면 알려주세요. 스터디원끼리 서로의 결과물에 오류를 심어주는 방식을 생각 중입니다.

재사용 가능한 프롬프트

프롬프트 1: 검수 도구의 진짜 설계 뽑아내기

[도구 이름 또는 경로]의 검수 방법론을 분석해줘.

단, 소개 문서(README)는 근거로 쓰지 마.
실제로 실행되는 파일(스크립트, 설정, 명령 정의)을 읽고
아래 4가지를 뽑아줘:

1. 무엇과 무엇을 대조하나? (대조 대상이 없으면 그것도 결론)
2. 판정을 누가 하나? 프로그램인가, AI인가, 사람인가?
3. 검사를 못 하는 상황이면 어떻게 되나? 통과인가 실패인가?
4. 이 도구가 과거에 뭘 놓쳤다는 기록이 있나?
   (변경 이력, 코드 주석, 개발 로그에서 찾아줘)

4번을 못 찾으면 "기록 없음"이라고 말해줘. 지어내지 마.

💡 4번이 핵심입니다. 놓친 기록이 있는 도구가 오히려 믿을 만합니다.

프롬프트 2: 두 방법론 사이의 사각지대 찾기

[도구 A]와 [도구 B]의 검수 방식을 비교해줘.

"어느 쪽이 더 낫다"는 결론은 쓰지 마.
대신 이 두 가지만 답해줘:

1. A는 잡는데 B는 절대 못 잡는 것
2. B는 잡는데 A는 절대 못 잡는 것

그리고 내 상황([본인 상황 — 예: 논문 요약 / 기획서 작성 /
클라이언트 보고서])에서는 어느 쪽 사각지대가 더 위험한지
근거를 들어 말해줘.

💡 "어느 게 나아?"라고 물으면 AI가 억지로 순위를 만듭니다. "뭘 못 잡나?"로 물어야 쓸모 있는 답이 나옵니다.

프롬프트 3: 내 검수기가 제대로 도는지 시험하기

[내 문서 경로]를 복사해서 시험용 버전을 만들고,
아래 3종류 오류를 각각 하나씩 심어줘.
어디에 뭘 심었는지는 나한테 알려주지 말고
별도 파일에 정답지로 저장해줘.

1. 없는 숫자 지어내기 (원본에 없는 수치)
2. 요구사항 하나 통째로 빠뜨리기
3. 요청하지 않은 항목 슬쩍 추가하기

그리고 정상 버전 1개도 그대로 둬 (대조군).

준비되면 알려줘 — 검수를 새 창에서 돌려서
몇 개나 잡는지 볼 거야.

💡 정답지를 안 보여주는 게 핵심입니다. 그리고 대조군(정상 문서)을 꼭 넣으세요. 없으면 "전부 불합격" 처리로 100% 검출률을 만들 수 있습니다.

도움 받은 글

참고한 자료

• research-survey 플러그인 v0.8.0 — 지피터스 스터디 도구

• SpecKit — GitHub spec-kit (AI 코딩용 명세 기반 개발 도구)

• SpecKit AI Engineering Blueprint — AI 도입 실패의 8가지 유형 정리 자료

작성일: 2026-08-12 작성자: 황금호랑이