설계서를 AI에게 리뷰하게 하고, "뭔가 내용이 얕은데"라고 느낀 적이 없으신가요?

그 "얕음"의 정체를, 정답을 확인할 수 있는 형태로 측정했습니다. 실제 설계서에 7개의 결함을 심어두고, 요청 방식만 바꾸어 검출률을 비교했습니다.

• "리뷰해 주세요" → 검출 0/7 (0%)
• "불일치가 없는지 봐줘" → 1/7 (14%)
• 관점을 나누어 3번 요청하기 → 6/7 (86%)

동일한 파일, 동일한 모델, 동일한 설정. 바꾼 것은 요청 방식의 일본어뿐입니다.

이 기사는 절차서로서 작성합니다. 프롬프트(Prompt)의 구조와 전달할 파일의 전처리, 판정 방식까지 그대로 사용할 수 있는 형태로 나열하겠습니다.

1. "리뷰해줘"라는 한마디로 맡기지 않기 (검출률 0%의 요청 방식)
2. 관점을 3개로 나누어, 별도의 채팅으로 요청하기
• 교정자 … 각 자료 안의 결번, 중복, 공란, 표기 불일치를 전수 조사
...

Web 검색을 끈 이유는 공개 문서이므로 인터넷상의 원본과 대조하게 되면 실험이 되지 않기 때문입니다.

결함은 실험을 위해 필자가 가공하여 추가한 것이며, 원래의 공개 자료에는 존재하지 않습니다.

8개 파일을 첨부하여 "이 설계서 일체를 리뷰해 주세요."라고만 보내면, 7페이지 분량의 훌륭한 리포트가 돌아옵니다. 우선순위가 붙은 지적, 수정 제안, 긍정적인 소견까지 포함되어 있습니다.

심어둔 7개는 단 하나도 찾아내지 못했습니다. 오히려 핵심이었던 "구현 누락"(—기능 요건에서 3줄을 삭제했으나, 업무 플로우 측에는 사용하는 절차가 남아 있는 상태—)에 대해 다음과 같이 적혀 있었습니다.

"개정에 의해 삭제된 항번은 결번 상태로 유지되어, 후속 번호의 재조정이 이루어지지 않았습니다. 외부에서의 항번 참조 안정성을 유지하는 좋은 설계입니다."

삭제의 흔적을 의도적인 좋은 설계라고 칭찬하고 있습니다.

이유는 두 가지가 있습니다.

Ⅰ AI는 문맥을 "선의로" 보완한다

결번을 발견했을 때, "삭제 실수일지도 모른다"가 아니라 "번호의 안정성을 유지하려는 의도적인 설계일 것이다"라고 그럴듯한 해석을 채택합니다. 우수한 속독자일수록 오타를 뇌 내에서 보정하여 읽고 지나치는 것과 같습니다.

Ⅱ "리뷰해줘"는 조사 범위를 AI의 재량에 통째로 맡기는 것이다

자료 A와 자료 B의 참조를 하나씩 대조하는 것과 같은 꾸준한 대조 작업은 요청받지 않는 한 수행하지 않습니다. 신입 사원에게 "이 설계서 좀 봐둬"라고 건넸을 때 일어나는 일과 같습니다.

이 부분이 가장 까다로운 점입니다. AI가 "찾아낸 것"은 확인할 수 있지만, "놓친 것"은 보이지 않습니다. 내용이 알찬 리포트가 돌아오기 때문에, 이쪽에서는 "제대로 리뷰되었구나"라고 느끼게 됩니다.

인간 리뷰 팀을 구성하는 방식을 그대로 가져옵니다.

하나의 자료 안에서 완결되는 이상을 전수 조사하게 합니다.

당신은 이 자료의 교정자입니다. 다음 사항을 전수 조사하여 보고해 주세요.
- 연속 번호의 결번 • 중복
- 공란으로 되어 있는 필수 항목
...

포인트: "전수 조사"라고 명시합니다. 쓰지 않으면 AI는 눈에 띄는 것만 보고합니다.

구현 누락을 잡아내는 것은 이 역할입니다.

당신은 자료 간의 정합성을 감사하는 역할입니다.
자료 A가 참조하고 있는 번호 • 이름이 자료 B에 실재하는지 전건 대조해 주세요.
- 참조처가 존재하지 않는 것을 열거
...

이 요청 방식으로, 심어둔 구현 누락이 다음과 같이 보고되었습니다.

"이 결번은 다른 것과 달리 기능 ID의 나열에도 구멍이 있다. 과거에 삭제된 흔적"

"리뷰해줘"에서 칭찬받았던 동일한 결함이, 삭제의 흔적으로 지목되어 폭로됩니다.

첨부된 용어집을 유일한 정답으로 삼습니다.
본문 중에서 용어집에 없는 약어 • 별도 표기가 사용된 곳을 검출해 주세요.
행 번호 또는 항번을 명시해 주세요.

한 번의 채팅에서 전부 시키면, 어떤 축을 볼지가 AI의 재량에 달려 있게 됩니다. 선택되지 않은 축(장표 → 기능의 참조 열, 용어의 불일치)은 통째로 사각지대가 됩니다. 실제로 "불일치가 없는지 봐줘"라고 목적만 전달한 검증에서는 구현 누락의 위치는 특정할 수 있었으나, 다른 6건은 찾지 못해 14%였습니다.

검증 2에서는 핵심인 구현 누락을 찾아냈음에도 **심각도가 "중간 정도 🧡"**였습니다. "과거 개정에서 사라진 항번이 플로우 측에서 업데이트되지 않고 남아 있는 것이 아닌가"라는 온건한 해석이 붙어 있었습니다.

지적이 수십 건씩 나열될 때, 사람은 중대하다고 판단된 것부터 확인합니다. 중간 정도로 분류된 중대 결함은, 바쁜 현장에서는 「찾지 못한 것」과 거의 다름없습니다.

심각도를 부여하게 한 뒤, 그 판정이 타당한지를 인간이 확인한다. 이것이 최종 확인의 핵심입니다.

「3.1.5를 확인해 주세요」와 같은 유도는 하지 않습니다. 실무에서는 리뷰 전에 설계서에 무엇이 적혀 있는지 본인도 모르기 때문입니다.

전달하는 것은 「연번의 결번·중복을 검출하라」, 「참조의 실재 여부를 전건 대조하라」와 같이, 어떤 설계서에도 통용되는 범용적인 관점뿐입니다.

6/7 = 86%.

다른 환경 (Claude Code + 다른 모델)에서도 시도해 보았으나, 결과는 동일하게 6/7였습니다. 모델의 성능이 아니라, 요청하는 방식의 구조가 결과를 결정합니다. 모델이 업데이트되어도, 다른 AI로 갈아타더라도, 이 요청 방식은 그대로 가져갈 수 있습니다.

어떤 요청 방식에서도, 어떤 환경에서도 찾아내지 못한 결함이 하나 있습니다. 기능 요구사항의 보충 설명란, 249자의 장문 셀에 단 한 번 심어둔 「특별징수 의무자」의 임의 약어인 「특의자」입니다.

찾지 못한 이유는 구조적이었습니다.

• 보충란에 있고, 항목명도 본문도 올바르기 때문에 행으로서 「정상」으로 보임
• 출현이 단 1회뿐이라, 빈도의 이상치로 드러나지 않음
• 첫 글자만 딴 약어라, 정식 명칭과 연속적으로 일치하는 글자가 1글자뿐이라 기계적 대조에 걸리지 않음

그리고 AI는 문맥으로 보완합니다. 「특의자 정보가 표시된다」를 읽는 순간 「특별징수 의무자를 말하는 거구나」라고 이해하고 그냥 지나칩니다. 결함을 칭찬한 것과 마찬가지인, 똑똑함 때문에 발생한 놓침입니다.

다만, 중대 결함 측면의 3건 (구현 누락·불일치)은 모두 검출되었습니다. 심각도가 높은 결함일수록 구조적인 흔적 (존재하지 않는 번호, 결번)을 남기기 때문에, 기계적 대조에 걸리기 쉬운 듯합니다. 단 한 번의 실험 경향일 뿐 보증하는 것은 아닙니다만.

여기서부터는 원래 실험 이후에 알게 된 사실입니다.

새로운 모델 (Claude Opus 5)의 공식 문서에 리뷰 용도에 관한 주의사항이 명시되었습니다.

리뷰용 프롬프트에 「중대한 문제만 보고해줘」 또는 「보수적으로 판단해줘」라고 적혀 있으면, 모델은 그 지시를 문자 그대로 따라 보고를 줄이는 경우가 있다. 대신, 모든 것을 보고하게 한 뒤 별도의 단계에서 필터링할 것.

(원문: If your review prompt says "only report high-severity issues" or "be conservative," the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead. — Prompting Claude Opus 5)

지적이 너무 많을 때, 무심코 「중요한 것만」이라고 덧붙이고 싶어집니다. 그것이 잡아낼 수 있었던 문제를 숨깁니다. 게다가 보고량이 줄어든 것은 화면에 나타나지 않으므로, 「지적이 적었다 = 결과가 좋았다」라고 오해하게 됩니다.

이 기사의 3 역할 방식은, 원래 전부 출력하게 한 뒤 심각도를 부여하도록 설계되었기에 이러한 함정에 빠지지 않습니다. 필터링은 인간 측의 공정으로 남겨두십시오.

아울러, 동일한 문서에서 삭제를 지시하고 있는 지시사항도 있습니다. 필자가 실측해 본 결과, 이것들을 추가하면 출력량이 평균 2.3배가 되었지만 결과물은 변하지 않았습니다.

・「마지막에 검증 단계를 넣어줘」
・「서브 에이전트(Sub-agent)로 검증하게 해줘」
・「답변을 더블 체크해줘」
...

디지털청이 공개한 업무 플로우 Excel을 조사해 보니, 셀에 들어 있는 글자는 스윔레인(Swimlane)의 헤더 5종류뿐이었고, 업무 내용 180개는 전부 도형 (텍스트 박스) 안에 있었습니다.

텍스트로 읽는 방식 (복사/붙여넣기, Excel 대응 MCP 서버 포함)으로는 업무 플로우의 본체가 통째로 누락됩니다. 까다로운 점은, 헤더만 있더라도 AI는 어떻게든 답변을 해버리기 때문에, 내용이 전달되지 않았다는 사실을 사용자가 알아차릴 수 없다는 점입니다.

또한, 이 Excel 파일을 그대로 브라우저의 Claude에 전달했더니 15분 후에 거의 완벽한 설명이 돌아왔습니다. 본인(AI)의 말에 따르면 "셀 자체에는 레인(Lane) 이름만 들어있었기 때문에, PDF로 변환하여 그림(Image)으로서 읽어 들였습니다"라고 합니다. 읽을 수 없다는 것을 스스로 깨닫고, 직접 PDF로 변환했던 것입니다.

그렇다고는 해도 15분이 걸립니다. 처음부터 PDF로 전달했다면 수십 초면 충분했을 것입니다.

□ 「리뷰해줘」라는 한마디로 맡기고 있지는 않은가
□ 관점을 3가지로 나누어, 별도의 채팅에서 요청하고 있는가
□ 모든 지적 사항에 심각도(Severity)를 부여하게 하고 있는가
...

검출률 0%와 86%를 가른 것은 AI의 성능이 아니었습니다. 성능은 처음부터 충분했으나, 우리가 제대로 끌어내지 못했을 뿐이었습니다.

이 실험에서 사용한 3가지 역할의 프롬프트(Prompt) 전문, 정답을 유도하지 않기 위한 셀프 체크리스트, 회사의 설계서에서 안전하게 테스트하기 위한 주의사항은 note의 실전 패키지에 정리해 두었습니다. 위의 절차만으로도 재현할 수 있지만, 그대로 복사해서 사용하고 싶은 분들은 확인해 보시기 바랍니다.

출처: 총무성 웹사이트 「세무 시스템 표준 사양서【제3.0판】」 / 디지털청 웹사이트 「지방공공단체 정보 시스템 공통 기능 표준 사양서」 관련 자료