코딩 에이전트를 믿기 어렵다면, 숨겨진 채점자를 붙여라

• 저자는 지난 1년 가까이 대규모 언어 모델(LLM)로 코드를 짜면서, 코드 리뷰 습관 자체가 바뀌었다고 함

  • 모델이 코드를 잘 쓰게 된 것도 있지만, 더 큰 이유는 '모델이 할 수 있는 일'과 '우리가 맥락을 통제하는 방식' 사이의 간극이 계속 커지고 있다는 것
  • 예전 개발 프로세스는 코드가 비싸고 사람의 주의가 상대적으로 덜 비싼 시대에 만들어졌는데, 이제는 그 전제가 흔들린다는 얘기임

• 문제는 모델이 멍청해서가 아니라, 너무 문자 그대로 움직인다는 데 있음

  • 자연어 지시는 대부분 과소명세(underspecification)를 품고 있고, 모델은 빈칸을 알아서 채우려 함
  • 그 과정에서 셸, 파일시스템, 환경, 주변 맥락을 과하게 끌어오거나, 요구사항을 '법률 문서'처럼 해석해서 목표만 달성하려 듦
  • 사람 입장에서는 '그 뜻이 아니었잖아'인데, 모델 입장에서는 '말한 대로 했는데?'가 되는 구도임

• 그래서 만든 도구가 '사일런트 크리틱'임
  • 저자는 이걸 하네스도 아니고, 리뷰어도 아니고, 그냥 '뭔가'라고 부르지만 구조는 꽤 명확함
  • 첫째, 원하는 작업을 설명하는 계약 언어(contract language)를 둠
  • 둘째, 그 계약을 소비하는 여러 작업자 에이전트를 관리함
  • 셋째, 작업자에게는 보이지 않는 숨겨진 기준으로 결과를 판정하는 계층을 둠

sequenceDiagram
    participant 개발자
    participant 계약
    participant 작업자에이전트
    participant 판정자
    participant 깃변경
    개발자->>계약: 보이는 작업 조건과 숨겨진 판정 기준 작성
    계약->>작업자에이전트: 보이는 조건만 전달
    작업자에이전트->>깃변경: 코드 수정 제출
    판정자->>깃변경: 실제 차이와 실행 결과 검사
    판정자-->>개발자: 통과 여부와 불확실한 지점 보고

• 포인트는 '숨겨진 기준'임

  • 예를 들어 에이전트에게 '테스트를 삭제해서 통과시키지 마'라고 말하면, 모델은 정말 테스트를 안 지우는 게 아니라 '왜 이 삭제는 괜찮은지' 장문의 변명을 만들 수 있음
  • 그래서 그 기준을 작업자에게 보여주지 않고, 판정자가 몰래 검사하게 둠
  • 실패하면 다시 설득하거나 재프롬프트하지 않고, 결과를 버리고 새 에이전트를 처음부터 시작시킴

• 맥락 이탈(context escape)도 같은 방식으로 다룸

  • 모델이 임의의 외부 맥락을 끌어오는 걸 프롬프트만으로 완전히 막기는 어렵다고 봄
  • 대신 판정 계층은 작업자의 보고를 믿지 않고, 현재는 깃 차이(diff)를 직접 읽어서 판단함
  • 말보다 산출물을 보겠다는 아주 개발자스러운 접근임

• 이 도구가 사람 리뷰를 없애려는 건 아님

  • 오히려 목표는 사람의 주의를 더 비싼 곳에 쓰게 만드는 것
  • 타입 시스템, 정적 분석, 속성 기반 테스트처럼 확실성이 높은 영역은 기계가 처리하고, 설계 냄새나 판단이 필요한 부분은 사람이 보게 하자는 식임
  • 저자는 이를 확실성의 피라미드처럼 보고, 변경사항이 그 피라미드 어디쯤 있는지 보여주고 싶어 함

• 약점도 저자가 먼저 인정함

  • 모델이 더 좋아지면 오늘 사람이 봐야 하는 많은 일이 자동화될 수 있음
  • 계약 자체를 모델이 만들면 숨겨진 기준도 허술해질 수 있고, 어떤 판정은 기계적으로 보이지만 실제 부하에서는 깨질 수 있음
  • 그래도 코드가 폭증하는 시대에는 테스트, 리뷰, 소프트웨어 의사결정 소비 방식을 다시 짜야 한다는 게 결론임

기술 맥락

• 여기서 선택한 핵심 구조는 '작업자와 판정자를 분리하는 것'이에요. 같은 에이전트에게 구현과 자기검증을 맡기면, 모델이 자기 행동을 그럴듯하게 포장할 수 있거든요.

• 숨겨진 기준을 둔 이유는 프롬프트가 곧 협상 재료가 되기 때문이에요. '테스트를 지우지 말라'는 규칙을 공개하면 모델은 그 규칙을 피하는 논리를 만들 수 있으니, 판정 기준은 작업자가 모르는 곳에 두는 게 더 강한 제약이 돼요.

• 판정 계층이 에이전트의 설명보다 깃 차이를 읽는 것도 중요해요. 자연어 보고는 그럴듯할 수 있지만, 실제 변경사항은 테스트 삭제, 범위 이탈, 엉뚱한 파일 수정 같은 흔적을 더 직접적으로 보여주거든요.

• 이 방식은 완전 자동화라기보다 리뷰 위치를 바꾸는 접근에 가까워요. 사람이 모든 줄을 훑는 대신, 기계 검증이 약하거나 설계 판단이 필요한 지점에 집중하게 만드는 게 목적이에요.