나는 판단의 단계였다

Source: Dev.to

현재 AI 코딩 병목 현상이 코드 리뷰로 옮겨갔다는 주장이 널리 퍼져 있다. 모델은 사람이 코드를 읽는 속도보다 훨씬 빠르게 코드를 작성하므로, 시니어 엔지니어는 최후의 검토자가 된다.

이 주장은 절반은 맞다. 병목은 이동했지만, 코드 리뷰가 아니라 그 앞 단계인 스펙으로 이동했다.

AI가 스캐폴딩, 검증, 보일러플레이트를 사실상 무료로 만들 정도로 빨라지면, 기능이 올바른지 판단하는 기준은 코드가 아니라 그 코드를 만든 의도가 된다.

예를 들어 “결제 상태를 업데이트하는 웹훅 핸들러”라는 의도가 있다면, AI는 정상 흐름을 아름답게 구현하지만 중복 전송, 멱등성, 불가능한 상태 전이와 같은 경우를 조용히 무시한다. 버그는 스펙 단계에서 이미 만들어진 것이다. 코드 단계에서 리뷰어가 이를 잡을 수는 있지만, 이는 상위 단계의 실수를 잡는 것이다. 그 작업은 느리고 비용이 많이 들며 사기를 떨어뜨린다.

따라서 진짜 문제는 스펙을 어떻게 검토하느냐이다.

한때 나는 이것이 내 일이라고 생각했다. 스펙을 작성하고, 그 스펙을 가지고 앉아 시니어 엔지니어가 흔히 하는 질문—범위는 어디까지인가, 어떤 상황에서 크게 실패해야 하는가, 중복 입력에 대한 동작은 무엇인가—을 스스로에게 던졌다.

효과는 있었지만, 역시 느렸다. 그리고 같은 불편함을 계속 느꼈다: 스펙을 작성하면서 놓친 케이스들을 리뷰할 때도 다시 놓친다는 것이다. 리뷰어와 작성자가 같은 사람이기에 맹점이 겹친 것이다.

깨달음은 스펙을 강력한 엔지니어링 팀이 코드를 다루는 방식과 동일하게 다루는 것이었다. 서로 다른 관점을 가진 리뷰어에게 스펙을 통과시키는 것이다.

내가 채택한 설정은 세 가지 모델을 활용한다.

• Claude: 의도에 대한 소크라테스식 인터뷰를 통해 스펙 초안을 만든다. 수용 기준, 엣지 케이스, 범위 외 항목, 남은 질문 등을 포함한다.
• Codex: architecture.md, conventions.md, guardrails.md와 초안을 비교 검토한다. 훈련 데이터와 기본값이 다르기 때문에 다른 관점을 제공한다.
• OpenCode(Qwen 실행): 동일한 루브릭에 따라 독립적으로 검토한다. 또 다른 코퍼스와 문화적 선입견, 그리고 다른 아첨 패턴을 갖는다.

각 모델은 구체적인 이의 제기를 반환한다: 누락된 수용 기준, 모호한 엣지 케이스, 이전 결정과의 모순, 스펙이 전제하고 있는 컨텍스트가 부족한 부분 등.

이것이 효과적인 이유는 모델마다 편향이 다르기 때문이다.

• Claude는 자신감이 넘치고 철저하지만, 프롬프트가 스펙을 이미 좋은 것으로 프레이밍하면 특정 아첨 패턴을 보인다.
• Codex는 코드 패턴을 중시하도록 훈련돼 있어 “이 스펙은 당신의 컨벤션에 맞지 않는다”는 점을 다른 모델보다 빨리 지적한다.
• Qwen은 다른 두 모델이 놓친 부분, 특히 명시적인 실패 모드와 복구 경로를 자주 지적한다.

어느 하나만 옳은 것은 아니다. 그들 간의 의견 차이가 신호가 된다.

이 루프를 통해 얻는 것은 판단이다. 내가 아닌, 나와 다른 편향을 가진 무언가가 더 일찍 판단을 적용한다.

여기서 불편함을 느끼는 이유는 다음과 같다.

수년간 엔지니어로서 나의 강점은 판단이었다. 어떤 질문을 해야 하는지, 무엇에 반박해야 하는지, 숨겨진 문제는 어디에 있는지를 아는 것이었다.

그러나 최근 사이클에서는 검색·합성 작업이 AI에게 대체되었다. 나는 판단을 더 높은 단계로 옮겨야 한다고 스스로에게 말했으며, 그 판단은 맛과 경험이 필요하기 때문에 견고하다고 생각했다.

솔직히 말하면: 판단도 분산 가능하다. 전부는 아니지만, 루브릭 기반 검토(예: 이 스펙이 실패 모드를 다루는가, 이전 결정과 충돌하는가, 컨벤션을 따르는가)는 서로 다른 훈련 데이터를 가진 모델들 사이에 병렬화할 수 있다. 결과는 어느 한 인간 리뷰어가 혼자 할 때보다 낫다. 나조차도 포함한다.

모델이 판단한 것이 아니라, 내가 판단 레이어였던 것이다.

이제 판단 레이어는 패널이 되었고, 나는 그 안의 한 목소리일 뿐이다.

인간에게 남는 일은 작아졌지만, 더 집중된 작업이 된다.

• 루브릭을 정의한다.
• architecture.md와 conventions.md를 유지해 패널이 검토할 구체적인 기준을 제공한다.
• 모델 간 충돌이 발생하면 의견 차이를 해결한다.
• 어떤 상처(실패 사례)를 history.md에 기록할지 결정해 미래 스펙이 과거의 고통을 반영하도록 한다.

이 역시 판단이다. 스펙 검토보다 덜 자주 일어나지만, 한 번 일어날 때마다 그 영향은 크게 누적된다.

“판단은 안전한 후퇴 레이어다”라는 초기 생각은 틀렸다. 안전한 레이어는 없다. 검증이 이루어져야 할 다음 위치가 있을 뿐이며, 그 위치가 이동할 때 정직하게 행동하는 것이 우리의 일이다.

현재는 루브릭 단계에 있다. 내년엔 또 다른 곳이 될 수도 있다.

여러분도 리뷰 쪽에서 다중 모델 패널을 운영하고 있나요? 패널이 가장 많이 의견 차이를 보이는 부분은 어디인가요?