LLM에게 문서 리뷰-수정을 반복 요청하다 보면 두 가지 문제가 겹쳐서 발생합니다. 매 리뷰마다 새로운 제안이 붙어 범위가 커지고, 직전 버전 기준으로만 수정하다 원래 목표에서 벗어납니다. ‘검토’를 개선점 제시로 해석하는 LLM의 편향과, 고정된 기준점 없는 반복 구조가 쌓여 생기는 현상입니다.

현상

기획이나 설계 문서를 세 단계로 나눠 작성하고, 각 단계마다 LLM에게 리뷰를 맡기는 방식으로 일해봤습니다.

  • 1단계 (현황 파악): 현재 코드/시스템이 어떻게 생겼는지 정리
  • 2단계 (요구사항 정리): 무엇을 만들 것인가 정의
  • 3단계 (개발계획): 어떻게 만들 것인가 정의

이 흐름에서 다음과 같은 일이 반복됐습니다.

  1. 작성한 문서의 검토를 요청하면 (동일 세션이든 다른 세션이든 무관하게) 원래 의도와 다른 방향의 피드백이 나옵니다
  2. 피드백을 반영해서 문서를 수정합니다
  3. 수정한 문서로 다시 리뷰하면 또 다른 피드백이 나옵니다
  4. 이 과정이 반복됩니다 (주로 2단계, 3단계 MD 파일 사이에서 발생)
  5. 결과적으로 처음 목표와 다른 곳에 도착합니다

원인

  1. LLM은 ‘검토’ 지시를 받으면 개선점을 제시해야 한다고 해석하는 경향이 있습니다

    “문제 없음"보다 “이런 것도 고려하세요"를 내놓는 쪽으로 기울어집니다. 동일 세션에서 원본 맥락(context)이 있어도 이 편향은 그대로 작동하고, 그 결과 scope creep (범위가 점진적으로 커지는 현상)이 발생합니다.

  2. 고정된 기준점 없이 수정을 반복하면 목표에서 벗어납니다

    매 반복마다 직전 버전 기준으로만 평가하므로, 각 단계는 “개선된 것"처럼 보여도 원래 출발점에서 점점 멀어집니다. 이것이 goal drift (목표 이탈)입니다.

  3. 문서가 길어지거나 시간이 지날수록 초반 맥락의 영향력이 약해집니다

    동일 세션이라도 리뷰 시점엔 초반 대화의 영향력이 희석되고, 리뷰어는 MD 문서 내용 자체를 주 기준으로 삼게 됩니다. 그래서 원본 맥락보다 문서에 명시적으로 박힌 기준이 더 중요해집니다.


해결 방법

1. 2단계 MD 맨 위에 Goals / Non-goals 섹션 고정

2단계가 “무엇을 만들 것인가"를 정의하는 문서이므로, 작업 전체의 목표는 여기에 박아둡니다. 모든 리뷰 세션이 이 섹션을 기준으로 평가하도록 강제합니다.

  • Goals: 이 작업으로 달성할 것 (1~2문장)
  • Non-goals: 명시적으로 하지 않을 것
  • 성공 기준: 뭐가 되면 끝인가

Non-goals가 특히 중요합니다. 리뷰어의 scope creep 제안을 끊어내는 근거가 됩니다.

3단계 MD 맨 위에는 “2단계의 Goals/Non-goals를 따른다"는 참조 링크만 걸고, 3단계 자체의 범위(기술 설계만 다룸, 요구사항 재논의는 하지 않음)를 명시합니다.

2. 리뷰어의 역할을 좁혀서 지시

“검토해줘"라고만 하면 반드시 개선점을 찾습니다. 대신:

“이 문서를 2단계의 Goals / Non-goals / 성공 기준 섹션 기준으로만 평가해줘.

  • 이 기준과 모순되는 부분이 있는가?
  • 기준 달성에 누락된 것이 있는가? 새 요구사항이나 범위 확장 제안은 하지 마. 필요하면 ‘기준 외 제안’ 섹션에 따로 적어줘.”

이렇게 하면 scope creep 제안이 본문 수정이 아닌 별도 섹션으로 격리됩니다. 채택 여부는 작성자가 결정합니다.

3. 리뷰 피드백을 즉시 반영하지 않기

받자마자 수정하면 goal drift가 시작됩니다. 중간 단계를 끼웁니다:

리뷰 받음 -> Goals/Non-goals와 대조 -> 기준 위배면 반영, 기준 외 제안이면 보류 -> 수정

4. 리뷰 횟수 제한

같은 문서를 여러 번 리뷰할수록 제안이 누적되고, 일부만 반영해도 drift가 쌓입니다. 1~2회로 제한하길 권장합니다.

5. 단계 간 baseline 관리

1단계 -> 2단계 -> 3단계 넘어갈 때 이전 단계를 잠급니다(baseline 설정).

  • 3단계 리뷰에서 “이 기능 말고 다른 기능이 낫지 않나?” 같은 피드백이 나오면, 실제로는 2단계 이슈입니다. 3단계 문서에서 고치지 말고, 2단계로 돌려보낼지 기본 거절할지 판단합니다.
  • 2단계를 뒤집는 피드백은 중대한 경우만 수용하고, 나머지는 거절합니다.