본 기사는 Zenn에 공개한 실측 기사의 Qiita 버전입니다 (필자 본인에 의한 전재 및 일부 재구성).

AI 리뷰의 검출률을 높이는 이야기는 대개 "어떻게 부탁할 것인가"에서 끝납니다. 역할을 부여한다, 관점을 나눈다, 깊게 생각하게 한다. 실제로 그렇게 하면 수치는 움직입니다.

하지만, 얼마나 부탁하는 방식을 궁리해도 0건 그대로였던 결함 타입이 하나 있었습니다.

요구사항 정의서에 12개의 결함을 심어 측정한 결과입니다. 소박하게 부탁했을 때 3개, 목적을 한 마디 덧붙였을 때 6개, 3가지 역할로 나누었을 때 6개. 여기까지는 순조롭습니다. 그런데, 어떤 타입의 3개만은 어떤 부탁 방식에서도 단 1개도 나오지 않았습니다. 5개 세션 모두 전멸이었습니다.

그 타입의 정체와, 최종적으로 어떻게 보이게 만들었는지를 쓰겠습니다 (Claude Code / Opus 4.8, 2026-07-20 실측).

설계서와 요구사항 정의서에서는 리뷰에서 보는 것이 다릅니다.

설계서의 주전장은 "자료들끼리 모순되지 않는가"였습니다. 존재하지 않는 화면 ID에 대한 참조, 테이블 정의와 항목 목록의 어긋남. 대조하면 기계적으로 나옵니다.

요구사항 정의서는 더 앞 단계입니다. 그 요구사항 하나만을 읽었을 때, 후속 공정에서 분쟁이 생기지 않고, 구현 가능하며, 테스트 가능한 문장으로 되어 있는가. 요구사항 그 자체의 좋고 나쁨을 보는 작업이라 대조할 대상이 없습니다.

그래서 실험을 처음부터 다시 만들었습니다.

AI가 "찾아낸 것"은 확인할 수 있어도, "놓친 것"은 보이지 않습니다. 그래서 정답을 알고 있는 상태를 스스로 만듭니다.

제재는 총무성이 공개하고 있는 "세무 시스템 표준 사양서【제 3.0판】"의 기능 요구사항서 (개인 주민세)입니다. 요구사항 1개당 1행으로 "~할 수 있을 것"이 약 700개 나열되어 있는, 현장과 같은 스케일의 실제 자료입니다.

심어둔 것은 소프트웨어 공학의 "좋은 요구사항의 조건" (IEEE 29148)의 대표적인 위반 사항을 실무에서 자주 보이는 형태로 만든 것입니다.

본론은 4번째인 "요구사항의 결락"입니다. 이것만 심는 방식이 다르므로 실물을 보여드리겠습니다.

"요구사항이 빠져 있다"라고 하면 보통은 행 자체가 사라진 상태를 떠올립니다. 그러면 항목 번호가 건너뛰어지기 때문에 AI는 금방 알아차립니다.

그래서 행은 한 줄도 지우지 않고, 문장 속에서 쌍을 이루는 단어를 한쪽만 삭제했습니다.

심어둔 후의 문장을 읽어보세요. 모두 일본어로서 완전히 정상입니다. "통지서를 일괄로 발행할 수 있을 것"——이 한 줄만 보여주고 "결함이 있다"라고 말할 수 있는 사람은 없습니다.

결함이 되는 것은, 문서의 다른 부분과 비교했을 때뿐입니다. 다른 19곳에는 "일괄 및 개별"이라고 적혀 있는데, 여기만 "일괄"밖에 없다. 그 격차만이 단서입니다.

실무에서 무서운 것도 바로 이 부분입니다. 한 줄씩 읽는 리뷰에서는 절대 발견되지 않으며, 적히지 않은 기능은 그대로 만들어지지 않습니다.

환경: Claude Code의 Agent 기능 (모델 Opus 4.8), 실행일 2026-07-20 - 매회
정답을 전혀 모르는 새로운 세션을 기동. 대상 파일 이외에는 읽히지 않도록 약 700행의 전 행 조사를 지시 -
검출 판정: "해당 요구사항의 특정 + 결함의 성질 지적"이 갖춰져야 1건으로 인정. 원래 사양서에 처음부터 있는 실제 문제는 집계에서 제외 - 동일한 프롬프트라도 실행할 때마다 결과는 ±2건 정도 흔들립니다 (교정 런으로 확인 완료). 이하는 각 1회 실측값입니다.

출처: 총무성 웹사이트 「세무 시스템 표준 사양서【제3.0판】」. 결함은 실험을 위해 필자가 편집·가공한 것이며, 원래 공개 자료에는 존재하지 않습니다. 개변판의 재배포는 하지 않습니다.

이 요구사항 정의서를 리뷰해 주세요.

돌아온 리포트 자체는 내용이 알찼습니다. 개정 이력에는 기재되어 있는데 본문에는 없는 기능 ID, 동일한 항목 번호의 중복 부여, 이력 분류의 모순 등. 국가가 공개한 대규모 문서의 허점을 단 몇 분 만에 찾아냅니다. 이 점은 솔직히 강력합니다.

심어둔 12개 중 발견된 것은 3개.

이 3개에는 공통점이 있습니다. 전부 '구현 수단의 혼입' —— 문장 끝에 추가된 "참고로, Excel의 매크로 기능을 사용하여..."와 같은 유형의 문장이었습니다. 행정 문서의 딱딱한 문체 속에서 나중에 덧붙인 문장은 겉돕니다. 독해력이 높은 AI는 그 겉도는 부분을 잡아낼 수 있습니다.

역설적으로 말하면, 원래 문장에 자연스럽게 녹아든 애매한 표현, 검증 불가능한 표현, 누락 사항은 단 하나도 나오지 않았습니다. 순수한 탐지 능력은 '심어둔 방식의 외형'에 좌우된다는 뜻입니다.

이 요구사항 정의서에 애매한 기술이나 테스트할 수 없는 요구사항이 있는지 확인해 주세요.

배로 늘어난 6개. "알기 쉬운 화면", "신속하게", "적절한 순서"와 같은 애매하고 검증 불가능한 계열을 한꺼번에 찾아냈습니다.

반면, 베이스라인에서 찾아냈던 "오전 2시 배치"가 이번 회차에서는 누락되었습니다. 같은 파일이라도 회차에 따라 찾아내는 면면이 달라집니다. 이는 나중에 중요한 영향을 미칩니다.

지난번 86%의 성과를 냈던 관점 분할(Perspective Splitting)을 요구사항 정의서용으로 다시 설계했습니다.

애매한 표현 헌터 (Ambiguity Hunter) — 발주자와 개발자 사이에서 해석이 갈리는 표현을 전수 조사함
구현 중립성 감사관 (Implementation Neutrality Auditor) — 요구사항이 WHAT(무엇을)에 집중하고 있는지, HOW(어떻게)가 혼입되지 않았는지 확인함
검증 가능성 파수꾼 (Verifiability Guardian) — 해당 요구사항으로부터 테스트 케이스를 작성할 수 있는지만을 확인함

정답은 일절 알려주지 않고, 업계 표준의 범용 관점만을 전달합니다. 3가지 역할을 별도의 세션으로 실행하여 합산합니다.

결과는 6개. '목적을 한마디 덧붙이는 방식'과 동점으로, "관점을 분할하면 무조건 이긴다"는 공식은 성립하지 않았습니다.

하지만 내용을 나열해 보면 차이가 나타납니다.

심각도 판정이 붙음: 감사관은 "오전 2시 배치 지정"을 최고 심각도로 단정 지었으며, 동일 요구사항의 전반부에 있는 "즉시 수행할 수 있을 것"이라는 내용과 모순된다는 점까지 지적함
담당 외의 결함을 다른 관점이 포착: "알기 쉬운 화면"을 파수꾼뿐만 아니라 애매한 표현 헌터도 "해석이 갈리는 표현"으로 검출
하나의 관점이 깊게 파고듦: "출력 순서를 적절한 순서로 지정할 수 있을 것"에 대해, "이용자가 지정할 수 있다"와 "적절한 순서"가 주어 수준에서 충돌하고 있음 (이용자가 선택하는 것인지, 시스템이 정답을 가지고 있는 것인지 읽어낼 수 없다는) 한 단계 더 깊은 지적

검출 수는 같더라도, 돌아오는 리뷰의 질이 다릅니다. 목적을 한마디 덧붙이는 방식은 넓게 포착하고, 관점 분할은 중요도 판정과 심층 분석을 더합니다. 실무에서는 경쟁 관계가 아니라 병용 관계입니다.

참고로 "관점을 세워 반증하게 한다"는 사고방식의 정리로서는, AI에게 "리뷰해줘"라고 하는 것은 이제 구식인가? "적대적 검증 (Adversarial Verification)"의 권장 (little_hands 님) 글이 사상적인 면을 깔끔하게 정리해 두었습니다. 본 기사는 그 효과를 정답 맞히기 형식으로 실측해 본 시도이기도 합니다.

심어둔 내용 중 하나로 "수납 상황을 스트레스 없이 참조할 수 있을 것"이 있었습니다. 테스트로 합격 여부를 가릴 수 없는 검증 불가능한 표현의 전형이며, 전담 '검증 가능성 파수꾼'이 잡아내야 할 먹잇감입니다.

파수꾼은 놓쳤습니다. 파수꾼뿐만이 아닙니다. 이 단어를 포함한 파일을 읽은 총 9개 세션 (검증 1·3 4회 + 교정 런 4회 + 검증 2) 중, 8회까지는 아무도 언급하지 않았습니다. 찾아낸 것은 전담 역할조차 아닌 '목적을 한마디 덧붙인 것'뿐인 단 1회였습니다.

신기한 점은, 파수꾼이 "적절하게", "신속하게"와 같은 애매한 표현은 찾아내고 있다는 것입니다. 여기서부터는 가설입니다. 파수꾼이 찾아낸 단어들을 나열하면 "적절하게", "신속하게", "일정한 조건", "수십 건 단위" —— 전부 요구사항 정의서 교과서에 실리는 "쓰면 안 되는 단어"들이었습니다.

700행을 스캔할 때, AI는 먼저 "찾아야 할 단어"의 후보를 정하고 대조해 나갑니다. 그렇게 생각하면 납득이 갑니다. 후보 단어들이 교과서에서 유래한 것이라면, "스트레스 없이"와 같이 교과서에 실리지 않는 캐주얼한 NG 단어는 처음부터 탐색망 밖에 있는 것입니다.

AI의 놓침은 능력 부족이 아니라 "찾는 목록"의 외곽에서 발생합니다. 그리고 요청문을 바꾸면 그 목록 자체도 바뀝니다.

지금까지의 세 가지 요청 방식 (단순히 요청하기 / 목적을 한마디 덧붙이기 / 3가지 역할로 나누기)은 모두 **"적혀 있는 내용의 결함"**을 찾고 있었습니다. 애매한 표현, 혼입된 구현 수단, 테스트할 수 없는 기준 —— 이 모든 것은 문서에 적힌 글자를 의심하는 작업입니다.

나머지 3개는 종류가 다릅니다. 바로 쓰여 있지 않은 것들입니다. 함정(仕込み)과, 그것을 방치한 채 검수(検収)를 통과했을 때 현장에서 어떤 일이 벌어지는지를 나열해 보겠습니다.

이 3가지는 테스트로는 검출할 수 없습니다. 쓰여 있지 않은 기능은 테스트 항목에도 올라오지 않기 때문입니다. 검수도 통과합니다. 깨닫는 것은 운영이 시작되고 나서 "어라, 이 조작은 어디서 하는 거지?"라고 느끼는 시점입니다.

이 3개는 총 5개 세션 동안 단 하나도 검출되지 않았습니다. 전담 3인(専任 3 役)을 포함해 전멸입니다.

이유는 구조적이었습니다.

행을 삭제하지 않았기 때문에, 항목 번호의 누락이나 연번의 이상 같은 기계적인 단서가 없습니다 - 한 줄만 읽으면
문장으로서 완전히 정상입니다. "통지서를 일괄로 발행할 수 있을 것" —— 어디에도 결함이 없습니다 - 이를 알아차리려면 "다른 19곳은 '일괄'과 '개별' 모두 대응하는데, 여기만 한쪽뿐이다"라는
문서 전체와의 대조가 필요합니다 - 그리고
3인 모두 "있어야 할 것이 갖춰져 있는가"를 담당하지 않았습니다.

네 번째가 본질입니다. 모호한 단어 헌터(曖昧語ハンター)는 적혀 있는 단어를 의심하고, 감사역은 적혀 있는 수단을 의심하며, 파수꾼은 적혀 있는 기준을 의심합니다. 모두가 "적혀 있는 것"을 보고 있을 뿐, "적혀 있지 않은 것"을 보는 역할이 없습니다.

그렇다면, 그 역할을 만들면 어떻게 될까요.

【완전성 감사역 (完全性の監査役)】을 추가했습니다. 전달한 관점은 이것뿐입니다.

당신의 업무는 개별 요구사항의 작성 방식이 아니라

적혀 있지 않은 것을 찾는 것. 이 문서에서 반복적으로 사용되는 정형적인 표현·요소의 조합을 스스로 추출하고, 대다수가 세트로 적혀 있는데 일부 요구사항만 요소가 결여된 곳을 특정할 것.

정답(어떤 쌍이 빠져 있는가)은 일절 알려주지 않았습니다.

결락 3개 중 1개가 처음으로 검출되었습니다. 검출 절차가 훌륭했습니다. 문서 중 "관리 (…)」의 괄호 안을 전수 집계하여, "설정·유지·수정"이 148건, "설정·유지"가 2건이라는 분포를 스스로 도출해 내고는 다음과 같이 지적해 왔습니다.

"148 대 2의 압도적 다수파로부터의 일탈. 의도적인 차별화인지 기재 누락인지의 판별이 필요"

인간 리뷰어가 "어라, 여기만 수정이 없나?"라고 깨닫는 사고 과정을 통계로 해낸 형태입니다.

게다가, 이 "설정·유지" 2건 중 함정은 1건뿐이었습니다. 나머지 1건은 원래 사양서에 처음부터 있었 실제의 일탈이었습니다 (연금 특별징수 정지 근거 관리. 수정 필요 여부가 정말로 미규정 상태). 관점을 주었더니 함정과 함께 진짜까지 낚인 셈입니다.

다만 나머지 2개는 이 관점으로도 보이지 않습니다. 차이를 만든 것은 정형화의 밀도입니다. "설정·유지·수정"은 148 대 2로 통계적으로 뚜렷하게 드러납니다. 반면 "일괄 및 개별"은 "일괄만"의 발행 요구사항이 원래 6건 있어서 빈도만으로는 드러나지 않습니다. 빈도 통계라는 무기는 여기서 바닥이 납니다.

포기하지 않고, 전달하는 관점의 해상도를 단계적으로 높여가며 어디서 보이는지를 측정했습니다. 정답은 마지막까지 알려주지 않았습니다.

장표명·통지명·대상 구분이라는 "이름"으로 관계된 요구사항끼리 대조한다. 세무 담당자·납세자·사업소 각각의 업무가 돌아가는지 확인한다.

수신처 쌍의 결락이 나타났습니다. 논리는 이렇습니다. 동일한 세액 통지서를 다루는 3가지 제공 방식(종이·데이터·eLTAX)을 대조하여, "데이터와 eLTAX는 의무자용·납세의무자용 양쪽을 대상으로 하고 있는데, 종이의 필수 요구사항에는 납세의무자용이 없다". 나아가 마스터 관리 측에 "세액 통지(납세의무자용)의 송부 형태(종이/전자)"라는 요구사항이 실제로 존재한다는 점까지 언급하며, "종이 납세의무자용은 제도상 상정되어 있는데, 발행을 담보하는 요구사항이 없다"라고 논증해 왔습니다.

이런 표입니다 (발췌. 전체 8개 쌍은 note에 두었습니다).

원래는 사람이 Excel의 Ctrl+F로 '일괄'을 검색하여, 해당 행에 '개별'이 나란히 있는지 눈으로 확인하기 위해 만든 표입니다. 이것을 그대로 프롬프트에 붙여넣고, 절차를 3가지 지정했습니다.

• 각 대립 쌍의 단어가 나타나는 행을 전수 열거할 것
• 대립 쌍 중 한쪽만 적힌 행을 후보로 올릴 것
• 후보가 전부 결함이라고 단정할 수는 없으므로, "옆에 있는 동일 유형의 요구사항은 어떻게 작성되어 있는가", "그 조작이 없으면 누가 어떤 상황에서 곤란해지는가"라는 2가지 축으로 압축할 것

AI의 업무 수행 방식은 실무 리뷰 그 자체였습니다. '일괄'의 누락 후보는 우선 125건이 올라옵니다. 거기서부터 1건씩 이유를 붙여 기각해 나갑니다—— "이 행은 직전의 주요 요구사항에서 '일괄 및 개별'을 이미 선언했으며, 그 대상 목록을 작성한 보충 행이다", "이것은 자료의 일괄 취합이며, 성질상 배치 처리 (Batch Processing)가 타당하다". 124건을 지우고, 마지막에 남은 1건을 다음과 같이 특정했습니다.

발행 계통 요구사항 중 유일하게, '일괄만 있음'과 '당초에만 있음'이라는 이중 누락. 1건만 나중에 비과세가 확정된 가징수자에게 개별적으로 환부 통지를 보내는 수시 운영이 상정되어 있음에도, 이 요구사항 그대로라면 그 1명을 위해 일괄 배치를 돌리거나 수작업을 해야 함.

심어둔 '개별'의 삭제에 더해, 원래 문장이 '당초'로 한정되어 있다는 실제 논점까지 잡아냈습니다.

이로써 누락 3개 모두를 검출할 수 있었습니다. 다만 솔직하게 두 가지를 덧붙입니다.

첫 번째. 단계가 올라갈수록, 전달한 관점이 정답에 가까워지고 있습니다. 체크리스트에는 '일괄↔개별'이라는 카테고리가 포함되어 있습니다. 위치는 알려주지 않았고, 125건에서 1건으로 압축한 것은 AI이지만, "무엇을 대립 쌍으로 간주할 것인가"라는 지식은 인간이 언어화하여 전달했습니다. 결함이 AI에게 보이지 않는 것이 아니라, "관점을 언어화하여 전달하지 못한 결함"이 보이지 않는 것입니다. 이것이 이번의 가장 깊은 결론입니다.

두 번째. 찾아내기는 했지만, 심각도 평가는 Minor~Major 수준에 그쳤습니다. 저는 이 타입을 "기능이 통째로 만들어지지 않은 채 검수를 통과하는, 가장 무거운 것"으로 심어두었지만, AI의 가중치 부여는 거기까지 파고들지 못합니다. "찾아내는 것"과 "중대하다고 판정하는 것"은 별개의 능력입니다.

설계서의 결함은 '존재하지 않는 번호에 대한 참조'와 같은 구조적 흔적을 남기기 때문에, 대조를 요청하면 기계적으로 나타납니다. 요구사항 정의서의 결함은 어휘와 관점에 의존하며, 결정적인 '누락'은 인간이 어디까지 관점을 언어화할 수 있느냐에 따라 보임새가 달라집니다. 문서의 종류가 바뀌면, AI 리뷰의 장점과 사각지대도 이만큼 움직입니다.

"리뷰해줘"라는 한마디에 맡기지 말 것. 요구사항 정의서에서도 마찬가지입니다. 다만 목적을 담은 한마디 ("모호한 기술과 테스트 불가능한 요구사항을 봐줘")만으로도 검출량은 배가 됩니다.

관점 분할은 심각도와 심층 분석을 위해 사용할 것. 모호한 표현 / 구현 수단의 혼입 / 검증 가능성의 3가지 역할이 요구사항 정의서용 모델입니다.

"적혀 있지 않은 것을 보는 역할"을 관점에 추가할 것. 4번째 역할 (완전성 감사역)이 정형화된 짙은 누락을 통계적으로 잡아내 줍니다. 깊은 누락은,

자신의 도메인에 있는 "대립하는 단어"를 체크리스트로 언어화하여 AI에게 전달할 것 (일괄↔개별, 설정↔수정, 의무자용↔본인용……). 인간용 도구는 그대로 AI의 관점이 됩니다. 언어화하지 못한 대립 쌍은 AI에게도 보이지 않습니다. 숫자를 측정하고 싶다면,

결함을 심어놓고 정답을 맞춰볼 것. "찾아낸 목록"의 길이는 검출력의 증명이 되지 않습니다.

지난 실험을 마무리하며, 저는 "성능은 처음부터 충분했으나, 우리가 끌어내지 못했을 뿐"이라고 썼습니다. 이번에 그 의미가 한 단계 더 명확해졌습니다. 결함이 AI에게 보이지 않는 것이 아니라, "관점을 언어화하여 전달하지 못한 결함"이 보이지 않는 것입니다. 관점을 언어화하는 것과, 찾아낸 것의 무게를 결정하는 것——그것이 아직 인간의 일입니다.

이 실험에서 사용한 도구 일체 (요구사항 정의서(Requirement Definition Document)를 위한 검증된 프롬프트 전문 6종, 정답을 유도하지 않기 위한 셀프 체크리스트, 결락 검출의 열쇠가 된 「대립어 체크리스트 (Pair of Words Checklist)」 8쌍)는 note의 실천 패키지에 정리해 두었습니다.

🔍 moname_ai — Claude를 본업에서 극한까지 활용한 실측 기록을 작성하고 있습니다. 다음 내용은 Bluesky (@moname-ai.bsky.social)에서 확인하세요.