
요약이 아닌 diff를 읽으세요
요약
코딩 에이전트의 작업 결과물을 검토할 때 요약(summary) 대신 diff를 확인해야 하는 이유를 설명합니다. 요약은 모델의 주관적인 서술인 반면, diff는 실제 변경 사항을 나타내므로 버그를 방지하기 위해 필수적입니다.
핵심 포인트
- 요약은 모델이 수행했다고 '생각하는' 이야기일 뿐이다.
- diff는 에이전트가 실제로 변경한 코드를 한 줄씩 보여주는 실체다.
- AI 코딩의 병목 현상은 에이전트 실행이 아닌 변경 내용 검토에 있다.
- 에이전트는 자신 있게 틀리거나 불필요한 파일을 수정하는 오류를 범할 수 있다.
코딩 에이전트(Coding agents)들이 코드를 작성하는 능력이 무서울 정도로 좋아졌습니다. Claude Code나 Codex에게 작업을 맡기면 1분 만에 마치 완료된 것처럼 보이는 결과물을 가져옵니다. 함정은 "완료된 것처럼 보이는 것"과 "완료된 것"은 매우 다른 주장이며, 그 차이가 나타나는 유일한 곳은 바로 diff(차이점)뿐이라는 점입니다.
저는 한동안 사이드 프로젝트를 시작으로, 제가 만들고 있는 것(Línea)에 이르기까지 매일 에이전트를 실행해 왔습니다. 그 과정에서 저는 에이전트의 요약(summary)을 읽는 것을 멈추고 diff를 읽기 시작했으며, 이는 제가 내보내는 결과물에 대해 신뢰하는 정도를 바꾸어 놓았습니다. 그 이유는 다음과 같습니다.
요약은 이야기입니다. diff는 실제로 일어난 일입니다.
에이전트가 작업을 마치면 자신이 무엇을 했는지 알려줍니다. "명확성을 위해 인증(auth) 모듈을 리팩터링했습니다. 모든 테스트를 통과했습니다." 이 문단은 해당 세션에 대한 모델의 이야기입니다. 자신이 무엇을 _했다고 생각하는지_를 손실이 있는 방식으로 다시 렌더링한 것이며, 방금 그 일을 수행한 바로 그 주체에 의해 작성된 것입니다.
diff는 다릅니다. diff는 에이전트가 당신에게 보여주고 싶든 아니든, 실제로 한 줄씩 무엇이 변했는지를 보여줍니다. 저는 얼마 전 Bluesky에서 이에 대한 의견을 냈고, 여전히 그 입장을 고수하고 있습니다:
AI 코딩의 병목 현상은 더 많은 에이전트를 실행하는 것이 아닙니다. 그것은 에이전트가 변경한 내용을 검토하는 것입니다.
더 짧은 버전으로 말하자면: 로그(log)는 무엇을 했는지 알려주지만, diff는 무엇을 망가뜨렸는지 알려줍니다. 저는 두 번째를 신뢰합니다.
제가 계속 마주치는 실패 모드들
이것은 편집증이 아니라, 시행착오를 겪으며 얻은 패턴 매칭(pattern-matching) 결과입니다. 제가 반복해서 보고 있는 것들(저뿐만이 아닙니다. 이것은 현재 r/LLMDevs와 X에서 기본적으로 진행 중인 대화 주제입니다)은 다음과 같습니다:
- 자신 있게 틀림 (Confidently wrong). 에이전트가 결함이 있는 계획을 제안하고 이를 끝까지 고수합니다. 방금 자신이 추가한 버그 바로 위에 "정상적으로 보임 (looks correct)"이라고 적어버리기도 합니다.
- 건드릴 이유가 없는 파일을 수정함. 한 가지 변경을 요청했는데, "친절하게도" 디렉터리 세 개를 넘어가서 무언가의 이름을 바꿉니다. Claude Code는 집중력을 유지하는 데 있어 대부분의 모델보다 뛰어나지만, 완벽한 것은 없습니다.
- 테스트는 통과하지만, 코드는 망가져 있음. 가장 무서운 부분입니다. 변경된 코드를 전혀 호출하지 않는 테스트를 작성하거나, 조용히 스킵(skip)을 추가하여 실제 버그가 있음에도 테스트 스위트(test suite)가 초록색(pass)으로 표시되게 만듭니다. "모든 테스트 통과"는 사람들이 인정하는 것보다 더 자주 조작된 신호(gamed signal)로 나타납니다.
모델에게 자신의 숙제를 채점하라고 요청할 수는 없습니다
사람들이 가장 먼저 떠올리는 명백한 해결책은 "에이전트가 자신의 작업물을 스스로 확인하게 하는 것"입니다. 하지만 이는 통하지 않습니다. 실수를 저지른 것과 동일한 가중치(weights)가 그것을 채점하기 때문입니다. 모델에게 스스로를 검증하라고 요청하는 것은 거짓말쟁이에게 시험지를 채점하라고 요구하는 것과 같습니다.
유일하게 신뢰할 수 있는 "알림 (notice)"은 모델 외부에서 옵니다. 모델이 직접 작성하지 않은 테스트, 컴파일러(compiler)에서 발생하는 타입 에러 (type error), 또는 실제 diff를 읽는 사람으로부터 오는 알림입니다.
실제로 효과가 있는 것
이것이 에이전트가 나쁘다는 뜻은 아닙니다. 업무의 성격이 바뀌었다는 의미입니다. 예전에는 코드를 작성하는 것이 업무였다면, 이제는 코드를 읽는 것이 업무입니다. 그리고 직접 작성하지 않은 코드를 읽는 것은 언제나 더 어려운 기술이었습니다.
- diff를 작게 유지하세요. 40개의 파일이 포함된 diff는 승리가 아니라, 실제로 수행할 수 없는 리뷰일 뿐입니다. 작고 의도적인 작업들이 한 번에 읽을 수 있는 diff를 만들어냅니다.
- 코드 조각(hunk)이 반영되기 전에 모두 읽으세요. 좋은 것은 수락하고, 조용히 잘못된 것은 거부하세요. 그것이 게이트키핑(gatekeeping)의 전부입니다.
- 모델이 작성할 수 없는 체크 사항을 신뢰하세요. Git은 이미 진실을 보유하고 있습니다. 제가 참여했던 r/LLMDevs 스레드에서 누군가 말했듯, 기록할 가치가 있는 유일한 부분은 git이 보유할 수 없는 부분뿐입니다.
이것이 Línea의 핵심 아이디어입니다
저는 리뷰 과정이 서투른 부분이 되는 것에 지쳤습니다. 그래서 Línea는 코딩 에이전트(coding agents)를 실행하고, 그들이 만드는 모든 변경 사항을 머지(merge)되기 전에 실제로 읽을 수 있는 diff 형태로 하나씩 확인할 수 있는 네이티브 Mac 터미널입니다. 동일한 에이전트, 동일한 속도입니다. 차이점은 당신이 맹신하는 대신 직접 운전한다는 것입니다.
모델은 결코 병목 현상(bottleneck)이 아니었습니다. diff를 읽는 것이 병목입니다. 그렇다면 그 부분을 제대로 만드는 것이 당연합니다.
원문은 runlinea.com/blog/read-the-diff에 게시되었습니다. 저는 코딩 에이전트를 실행하고 그들이 변경한 내용을 리뷰하는 것에 대해 글을 씁니다. X나 Bluesky에서 인사해 주세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기