과거 리뷰 지적을 AI에 학습시키니, 사전에 막아낸 것은 절반 정도였다

리뷰에서 받은 지적 사항들을 '형태(型)'로 모아서, Merge Request (MR)를 올리기 전에 Claude Code와 대조해 보는 시스템을 만들었습니다.

효과를 측정해보니, 처음에는 15군데 중 13군데를 사전에 포착할 수 있었습니다. 오, 꽤 효과적이네! 하고 기뻐하는 순간, 시험의 답이 카탈로그에 그대로 남아있다는 것을 깨달았습니다.

답을 제외하고 다시 측정해 본 결과는 **11군데 중 67군데 (5564%)**였습니다.

절반 조금 넘게는 사전에 포착할 수 있다. 하지만, 절반 가까이는 빠져나간다. 이것이 이 시스템의 현재 실력입니다.

리뷰 지적 사항을 AI에 학습시키는 시스템은 이미 몇몇 아티클에서 소개된 적이 있습니다 (아티클 마지막에 첨부했습니다). 이번 글에서는 시스템 자체보다는, 실제로 측정해 보니 어땠는지와 그 과정에서 두 번이나 발견한 **'확인하는 시스템 자체가 확인하지 않고 통과했다'**는 이야기를 중심으로 작성합니다.

먼저 말씀드리자면, 이 제작 방식이 좋은 것인지는 저 자신도 아직 모릅니다. 시행착오의 중간 과정을 읽어주시면 감사하겠습니다.

같은 지적 사항을 반복해서 받다

알고 보니, 전에 받았던 것과 같은 형태의 지적을 또 받고 있었습니다. 예를 들어, 다른 MR에서 받은 이 4가지입니다.

AI도 마찬가지였습니다. Claude Code는 대화가 이어지면 이전 지적 사항을 기억하지 못하기 때문에, 방치하면 몇 번이고 같은 구멍을 파게 됩니다. 저와 AI가 같은 구멍에 번갈아 빠지고 있었습니다.

지적 사항을 '형태(型)'로 모으기

그래서 받은 지적 사항들을 MR별로 메모하는 것을 멈추고, '형태(카테고리)'로 정리한 카탈로그를 만들었습니다. 형태 아래에 실제로 받은 지적 사항을 실례로 매달아 놓습니다.

MR별 기록으로는 다음 MR의 내용이 다르면 적용 가능한지 판단할 수 없습니다. 형태로 만들어 두면, 내용이 달라도 '이거, 저 형태 아닌가?' 하고 대조해 볼 수 있습니다.

지적 사항을 모아서 AI에게 읽히게 한다는 생각 자체는 선행 아티클과 동일합니다. memory에서 rules로 격상시키는 방법이나, 주간 단위로 rules를 자동 업데이트하는 방법, 지적 사항을 카테고리로 집계하는 방법 등이 이미 소개되었습니다 (참고 문헌에 첨부했습니다).

8월 말부터 모으기 시작해서 지금은 40개의 형태가 있습니다. 많은 순서대로 나열하면 다음과 같습니다.

MR을 올리기 전에 AI에게 대조해 보기

Claude Code의 skill (AI에게 전달할 작업 절차서)로 2가지를 준비했습니다.

MR을 만드는 skill: 올리기 전에, 변경 내용을 카탈로그의 형태와 대조해 보기 -
지적 사항을 고치는 skill: 수정한 후에, 새로운 형태라면 카탈로그에 추가하기

카탈로그는 금방 1,000줄이 넘었기 때문에 매번 전부 읽히게 하지는 않습니다. 매번 읽게 하는 것은 색인과 일부 형태만으로 하고, 나머지는 변경 내용에 맞는 형태만 열리도록 했습니다. (이 '전부 읽히지 않게'한 것은 전문가에게 배웠습니다.)

확인하는 시스템 자체가 확인하지 않고 통과했다

그런데 형태가 30개, 40개로 늘어나자, AI는 **'주요 항목을 확인했습니다'**라고 말하며 나머지를 건너뛰기 시작했습니다.

...이것은 1위 형태인 '무언가 없이 통과' 그 자체였습니다. '확인되고 있는가?'를 체크하게 하는 시스템에, AI 자신이 확인하지 않고 통과하고 있었던 것입니다.

그래서 부탁하는 것을 멈추고, 시스템으로 막았습니다.

• AI에게,
  모든 형태에 대해 '적용되는가/적용되지 않는가'와 근거를 표로 작성하게 함 - 빈칸이나 근거 없는 행이 있으면, 검사 스크립트가 다운됨
• Claude Code의
  훅(Hook) (특정 작업 전에 자동으로 작동하는 스크립트)으로, MR을 만드는 커맨드 전에 이 검사를 삽입함

'해줘'라고 쓰는 것보다, '안 하면 진행할 수 없게' 하는 것이 더 확실했습니다.

정말 효과가 있는지 측정해 보기

계속 '확인되고 있는가?'라는 말을 들었기 때문에, 이 시스템도 측정하지 않을 수 없었습니다.

과거의 MR을 처음 제출했을 때로 되돌려 AI에게 표를 채우게 하고, 실제로 리뷰에서 받은 지적 사항들을 몇 군데 '해당된다'고 말할 수 있었는지 세어보았습니다.

1차 때는 '꽤 맞는 것 같다!'라며 기뻐했지만, 곧 깨달았습니다. 카탈로그의 실례에 시험에 사용한 MR 기록이 그대로 남아 있었습니다. 답이 적힌 노트를 보면서 시험을 치르고 있었던 상태입니다.

2차 때는 사용하지 않는 MR을 다시 골라보고, 카탈로그에서도 그 기록을 빼고 측정했습니다. 수치가 확 떨어졌습니다.

앞서 말씀드린 '절반 정도'는 이 2차의 수치입니다. 게다가 두 모델 모두가 놓친 것은 또다시 '말없이 통과하는 것'이었습니다.

여기에서도, 확인하는 장치(메커니즘)를 확인하지 않고 통과했던 것입니다. 2차 내용입니다.

카탈로그에 없는 형태는 빠져나간다 (스리누케루)

카탈로그에 실려 있는 것은 과거에 받은 형태들뿐입니다. 그래서 어떤 형태에도 사용할 수 있는 확인 방법으로, 일부러 망가뜨려서 제대로 불합격이 되는지 보는 방식을 취하고 있습니다.

그래도 떠오르지 않는 것이 있습니다.

• 보호(방어) 설정을 지우는 것이 아니라
  주석 처리(コメントアウト)로 무효화하는 것 ( '줄을 삭제하는' 것은 시도했습니다.) - 연결을 허용할 상대 목록을
  빈 상태로 만드는 것은 설정 자체를 지워버리고 인터넷 전체에서 오는 상태가 됩니다 (CI는 전부 통과했습니다)

어떻게 망가질지, 어디서 침투할 수 있을지를 떠올리는 것이 지금의 과제입니다.

고민하는 점

처음에 말씀드린 대로, 이 제작 방식이 좋은지는 모르겠습니다. 지금 고민하고 있는 것은 이 3가지입니다.

1. 카탈로그가 계속 늘어남

형태(패턴)가 많아질수록 읽히게 하는 것이 무거워지고, AI가 건너뛰기 쉬워집니다. 줄이거나 통합할 시점을 알 수 없습니다.

2. 형태 구분 방식이 모호함

측정해 보니, AI가 같은 문제를 다른 형태 이름으로 제시하는 경우가 있었습니다. 사람이 나누더라도 경계가 모호한 형태가 있습니다.

3. AI에게 읽히게 하는 것보다 기계로 검사해야 하지 않을까?

'말없이 통과하는 것'을 52개나 받고 있다면, AI에게 매번 주의를 주게 하는 것보다 lint 규칙이나 테스트의 틀(템플릿)로 만들어 버리는 것이 더 확실할지도 모릅니다. AI에게 기억시키는 것은 기계로 검사할 수 없는 것에만 해야 할지도 모르겠습니다.

다음으로 시도해 보고 싶은 것

지금 카탈로그가 효과를 보는 건 MR을 제출하기 직전뿐입니다. 작성한 코드를 대조하여 나중에 발견하고 있습니다. 이전 기사처럼, 자주 나오는 형태들만 rules로 격상하면, 코드 작성하는 도중부터 효력이 생겨서 애초에 만들지 않아도 될 수도 있을 것 같습니다. 상위 2~3가지 형태만 관련 파일을 건드릴 때 읽히는 형태로 시도해 보고 싶습니다. 시도한 후에는 지적이 줄었는지 여부도 측정해 보겠습니다.

같은 일을 하고 계신 분들 중, '저희는 이렇게 하고 있다' 하는 것이 있다면 댓글로 알려주세요.

요약 (まとめ)

• 지적은 MR별이 아니라
  형태(型)별로 모으면, 내용이 달라도 대조할 수 있다 - AI에게 '확인해 달라'고 부탁만 하면, AI 스스로가
  말없이 통과한다. 근거를 쓰게 하고, 안 쓰면 진행하지 못하게 하는 시스템을 만들었다 - 효과는
  답을 빼서(答えを抜いて) 측정했다. 측정해보니 절반 정도였다

보너스: 내가 기억하기 위한 스킬

카탈로그는 'AI가 같은 지적을 반복하지 않게' 하는 장치입니다. 하지만 AI가 기억해도, 제가 기억하지 못하면 의미가 없습니다. 지적을 받고 고치면, 그 자리에서는 작동하는 코드를 만들 수 있습니다. 다만, 방치해 두면 '그때 들었으니까 고쳤다'만 남습니다.

그래서, MR을 교재로 삼아 제가 공부하는 스킬도 만들었습니다. MR이 끝난 후에 '이 MR로 공부하고 싶다'고 말하면 이렇게 진행됩니다.

• MR의 본문・차분(diff)・
  리뷰 지적 사항을 모은다 (지적 사항에는 '왜 안 되는지'가 적혀있어 가장 좋은 교재입니다) - 교재를
  3~5개로 좁힌다. 기준은 '이직할 곳에서도 사용할 수 있는가'. 이 리포지토리에서만 사용하는 이름이나, 일회성 회피책은 선택하지 않습니다 - 하나씩 '무엇이 문제였는가 → 일반화하면 → 최소 형태 → 다른 곳에서는 이렇게 사용한다 → 흔한 실수' 순서로 설명합니다

5문제의 확인 테스트를 냅니다. 답은 미리 내지 않고, 제 답변을 기다려 채점합니다 - 설명・문제・채점 과정을 노트에 남깁니다.

skill에 작성된 문제 생성 방식은 다음과 같습니다.

5번째 문제가 가장 중요하고, 가장 많이 틀립니다. 이번 코드에서는 답할 수 있어도, 다른 상황에 적용하지 못하면 체득했다고 말할 수 없기 때문입니다.

'복습하고 싶다'고 하면, 이전 노트에서 틀린 문제만 설명 없이 바로 내줍니다. 기억해내는 과정 자체가 정착이 된다는 생각입니다.

카탈로그가 AI용 '실패 노트'라면, 이곳은 저 개인용 '오답 노트'입니다. AI와 저, 양쪽 모두에 남겨야 같은 함정에 번갈아 빠지는 것을 막을 수 있다고 생각합니다.

4월에는 AI에게 맡기니 여기저기 땜질식 처방이 되었습니다. 지금도 AI는 틀리고, 저도 틀립니다. 다만, 똑같은 실수를 AI가 이어가지 않도록, 실수를 외부에 기록하는 것은 할 수 있게 되었습니다.

끝까지 읽어주셔서 감사합니다.

참고 문헌

리뷰 지적을 AI에게 학습시키는 선행 기사

• Claude Code에 같은 리뷰 지적을 반복시키지 않는 실패 학습 루프 구축 방법: 지적 사항을 memory에 기록하고, 습득된 것을 rules로 격상하기
• Claude Code의 규칙을 계속 발전시키기 — Routines를 사용해 리뷰 지적을 .claude/rules에 자동 반영하기: PR에서 나온 지적 사항을 주간 단위로 모아 rules를 자동으로 업데이트하기
• Claude Code × Gemini 협조 개발 실황 (1/3) — 321건의 리뷰 지적이 밝히는 AI 구현의 약점: 지적 사항을 카테고리별로 집계하여, AI가 반복하기 쉬운 경향을 수치화함
• Claude Code × Gemini 협조 개발 실황 (3/3) — 리뷰 지적을 사전에 방지하는 시프트 레프트 4가지 기둥: 서브 에이전트나 SKILL.md를 활용하여, 지적받기 전에 문제를 해결하기

Claude Code의 작동 방식

• Claude를 스킬로 확장하기 - Claude Code Docs: skill(SKILL.md) 작성법. 본체는 사용할 때만 로드됨
• 스킬 생성 모범 사례 - Claude Platform Docs: '단계적 공개'. SKILL.md는 목차로 사용하고, 상세 내용은 별도 파일에 분리하는 근거. 카탈로그를 '전부 읽게 하지 않는' 형태로 만든 배경
• Hooks 레퍼런스 - Claude Code Docs: 특정 작업 전에 검사를 거쳐, 통과하지 못하면 멈추는 메커니즘
• 커스텀 서브 에이전트 생성 - Claude Code Docs: 판정표를 채우는 작업을 다른 AI에게 맡기고, 메인 대화에 카탈로그가 로드되지 않도록 사용함

보너스 skill의 사고방식

• Roediger, H. L., & Karpicke, J. D. (2006). Test-Enhanced Learning: Taking Memory Tests Improves Long-Term Retention.
  Psychological Science, 17(3): 다시 읽는 것보다 테스트로 기억해내는 것이 장기 기억에 도움이 된다는 점 (테스트 효과). 복습을 '설명 없이 문제부터'로 바꾼 근거

지금까지의 기사

Discussion