코드 리뷰가 너무 늦게 시작되는 이유

AI 보조 개발 (AI-assisted development) 도구 대부분은 다음과 같은 질문에 답합니다:

• 무엇이 바뀌었는가?
• 코드가 더 나빠졌는가?
• 패치 (patch)가 테스트를 통과하는가?
• 에이전트 (agent)가 작업을 완료했는가?

이것들은 유용한 질문들입니다.

하지만 이 질문들은 모두 동일한 가정을 공유하고 있습니다:

리뷰 프로세스는 디프 (diff)가 존재할 때 시작된다.

이 가정은 인간이 코드의 주요 작성자였을 때는 타당했습니다.

하지만 저는 더 이상 이 가정이 맞다고 확신하지 않습니다.

진정한 결정은 디프 (diff) 이전에 일어납니다

경험 많은 엔지니어가 작업을 받을 때, 그들은 보통 코드 한 줄을 쓰기도 전에 여러 가지 결정을 내립니다:

• 무엇을 변경해야 하는가?
• 무엇을 변경하지 말아야 하는가?
• 어떤 모듈이 관련되어 있는가?
• 어떤 의존성 (dependencies)이 위험한가?
• 이 변경 사항이 어디까지 퍼져야 하는가?

그러한 추론의 대부분은 암묵적으로 일어납니다.

AI 에이전트 (AI agents)의 경우, 상황은 다릅니다.

에이전트는 목표를 받자마자 즉시 코드베이스 (codebase)를 탐색하기 시작합니다.

첫 번째 중요한 결정은 다음과 같은 것이 아닙니다:

이것을 어떻게 구현해야 하는가?

첫 번째 중요한 결정은 다음과 같습니다:

내가 무엇을 건드려도 되는가?

그 결정이 변경 사항이 안전하고, 유지보수 가능하며, 리뷰 가능한 상태로 남을지를 결정하는 경우가 많습니다.

그럼에도 불구하고 대부분의 툴링 (tooling)은 패치 (patch)가 이미 생성된 후에야 관심을 갖기 시작합니다.

AI가 오래된 가정을 깨뜨렸습니다

전통적인 코드 리뷰 (code review)는 다음과 같이 가정합니다:

작업 (Task) ↓ 구현 (Implementation) ↓ 디프 (Diff) ↓ 리뷰 (Review)

디프 (diff)는 리뷰 프로세스의 시작으로 취급됩니다.

AI 에이전트에게 디프 (diff)는 종종 결정 프로세스의 끝입니다.

리뷰어가 패치 (patch)를 볼 때쯤에는 이미 다음과 같은 상황이 벌어집니다:

• 범위 (scope)에 대한 결정이 이미 내려졌고
• 의존성 (dependencies)이 이미 탐색되었으며
• 관련 없는 파일들이 이미 수정되었을 수 있고
• 아키텍처 경계 (architectural boundaries)가 이미 넘어갔을 수 있습니다

패치 (patch)는 결과만을 기록합니다.

에이전트가 어떻게 그 결과에 도달했는지는 설명하지 않습니다.

테스트 통과만으로는 충분하지 않습니다

간단한 작업을 상상해 보세요:

하나의 API 파라미터 (parameter) 이름 변경하기.

에이전트는 다음과 같이 수정합니다:

• 대상 API
• 8개의 의존 모듈
• 3개의 테스트 스위트 (test suites)
• 요청에 포함되지 않았던 2개의 유틸리티 파일

모든 테스트를 통과합니다.

대부분의 현대적인 워크플로우 (workflows)는 이를 성공적이라고 간주할 것입니다.

하지만 정말 그래야 할까요?

구현 (implementation) 자체는 올바를 수 있습니다.

하지만 변경 프로세스 (change process)는 그렇지 않을 수 있습니다.

테스트를 통과한 패치 (patch)가 에이전트가 합리적인 범위 내에 머물렀음을 자동으로 의미하지는 않습니다.

누락된 계층

저는 AI 지원 개발 (AI-assisted development)에서 누락된 제어 계층 (control layer)이 있다고 점점 더 확신하게 됩니다.

태스크 (task)와 디프 (diff) 사이의 무언가 말입니다.

다음과 같은 방식 대신:

태스크 (Task) ↓ 에이전트 (Agent) ↓ 디프 (Diff)

워크플로우는 다음과 같은 모습이어야 합니다:

태스크 (Task) ↓ 의도 (Intent) ↓ 영향 범위 (Blast Radius) ↓ 제한된 편집 (Bounded Edit) ↓ 검증 (Verification) ↓ 디프 (Diff)

목표는 변경을 막는 것이 아닙니다.

목표는 구조적 확장 (structural expansion)을 명시적으로 만드는 것입니다.

만약 에이전트가 하나의 파일에서 20개의 파일로 이동하기로 결정했다면, 그 결정은 가시적이어야 합니다.

만약 변경 사항이 아키텍처 경계 (architectural boundaries)를 넘나든다면, 그 사실 또한 가시적이어야 합니다.

범위가 확장된다면, 패치가 리뷰 (review)에 도달하기 전에 그것이 보여야 합니다.

이것은 에이전트를 불신하는 것에 관한 문제가 아닙니다

일반적인 반응은 다음과 같습니다:

우리는 그저 더 나은 모델이 필요할 뿐이다.

그럴지도 모릅니다.

하지만 역사는 다른 패턴을 시사합니다.

소프트웨어 엔지니어링 (software engineering)은 사람들이 더 똑똑해진다고 해서 신뢰성이 높아지는 경우가 드뭅니다.

시스템이 더 관찰 가능 (observable)해질 때 신뢰성이 높아집니다.

버전 관리 (version control)가 개발자들을 더 똑똑하게 만들지 않았습니다.

테스트 (testing)가 개발자들을 더 똑똑하게 만들지 않았습니다.

CI가 개발자들을 더 똑똑하게 만들지 않았습니다.

이 모든 것들은 실수를 더 쉽게 감지할 수 있게 만들었을 뿐입니다.

AI 개발 워크플로우도 아마 같은 경로를 따를 것입니다.

신뢰성은 오로지 더 강력한 파운데이션 모델 (foundation models)에서만 오지 않을 것입니다.

신뢰성은 해당 모델들을 둘러싼 더 강력한 제어 시스템 (control systems)에서 올 것입니다.

디프 대신 결정을 리뷰하기

수년 동안 소프트웨어 엔지니어링은 코드를 리뷰하는 것에 집중해 왔습니다.

에이전트가 주요 기여자 (contributors)가 됨에 따라, 다른 질문이 떠오릅니다:

우리는 코드만 리뷰해야 할까요?
아니면 코드를 만들어낸 결정을 리뷰해야 할까요?

디프 (diff)는 여전히 중요합니다.

하지만 그것은 더 이상 리뷰 프로세스의 시작이 아닐 수도 있습니다.

그것은 단순히 최종 영수증일 뿐일지도 모릅니다.

⸻

이것이 제가 CodeClone 2.1을 통해 탐구하고 있는 방향입니다.

CodeClone은 Python 프로젝트를 위한 결정론적 구조적 리뷰(structural review) 및 변경 제어(change-control) 레이어입니다. 2.1 라인에는 구조적 변경 컨트롤러(Structural Change Controller)가 추가되었습니다. 에이전트(agents)는 의도를 선언하고, 영향 범위(blast radius)를 조사하며, 명시적인 경계 내부에서 편집하고, 결과로 생성된 패치(patch)를 검증한 뒤, 감사 가능한 영수증(auditable receipt)을 남깁니다.

목표는 에이전트에게 코드를 어떻게 작성할지 알려주는 것이 아닙니다.

목표는 디프(diff)가 우리가 가진 유일한 증거가 되기 전에, 에이전트의 변경 사항을 명시적(explicit), 제한적(bounded), 관찰 가능(observable), 그리고 검증 가능(verifiable)하게 만드는 것입니다.