EDD는 루프를 닫지만, 그 절반에 불과하다

Andrea Laforgia가 작성한 Expectation-Driven Development (EDD, 기대 기반 개발)에 관한 최근 글이 화제가 되었으며, 이는 진지하게 주목할 가치가 있습니다. 핵심 논거는 설득력이 있습니다. AI 에이전트는 인간이 의미 있게 검토할 수 있는 속도보다 더 빠르게 코드를 생성하므로, 구현 전에는 의도를 명시하고 구현 후에는 충족에 대한 증거를 요구하는 구조화된 프로토콜이 필요하다는 것입니다. 인간 개발자는 _작성자 (author)_에서 _편집자 (editor)_로, 즉 코드를 작성하는 것에서 코드를 평가하는 것으로 전환됩니다.

그 프레임워크는 옳습니다. 그리고 EDD 워크플로우 — 평문으로 기대를 작성하고, 에이전트가 구현하게 하며, 에이전트에게 이를 증명하도록 요청하고, 증거에 이의를 제기하며, 반복하는 과정 — 는 대략 "신뢰하고 CI가 통과하기를 바라는" 현재의 기본 방식보다 실질적인 개선입니다.

하지만 EDD는 특정한 문제, 즉 _인간의 의도 (human intention)_와 AI 구현 (AI implementation) 사이의 간극을 해결합니다. 그것은 그다음에 발생하는 문제는 해결하지 못합니다.

이를 구체화하기 위해, 개발자가 에이전트에게 결제 시 할인 코드가 적용되는 방식을 수정하도록 요청하는 상황을 상상해 보십시오. 기대 사항은 정밀합니다: 할인은 세전 소계에 적용되어야 하며, 세금은 그 이후에 계산되어야 하고, 빈 장바구니는 에러 대신 0을 반환해야 합니다. 에이전트는 이를 구현하고, 테스트 스위트 (test suite)를 실행하며, 증거를 생성합니다 — 명시된 내용과 정확히 일치하는 실제 숫자가 포함된 세 가지 시나리오입니다. 개발자는 적대적인 방식으로 증거를 검토하고, 중복 할인 엣지 케이스 (edge case)에 대해 한 번 이의를 제기한 후, 수정된 버전을 받고 만족합니다. 이것이 의도한 대로 작동하는 EDD입니다.

EDD가 멈추는 지점

EDD는 개발자가 증거에 만족할 때 끝납니다. 기대 사항이 충족되었습니다. 코드는 작동합니다. 디프 (diff)가 준비되었습니다.

그 이후에는 어떤 일이 일어날까요?

대부분의 팀에서 답은 이렇습니다: 머지 (merge)됩니다. 동료가 디프를 훑어볼 수도 있고, 아닐 수도 있습니다. CI는 통과(green)되었고, 기대 사항은 검증되었으며 (적어도 에이전트 자신의 추정치로는), 코드는 메인 브랜치 (main branch)에 반영됩니다.

우리의 예시에서, 할인 수정 사항은 재고 팀의 예약 로직(reservation logic)이 의존하는 것과 동일한 공유 PricingEngine 인터페이스를 건드렸습니다. 아무도 그것을 무시하기로 선택한 것이 아니었습니다. 단지 그것이 기대 사항(expectation)의 일부가 아니었을 뿐입니다. 기대 사항은 할인과 세금에 관한 것이었지, 그 인터페이스를 누가 또 읽는지에 관한 것이 아니었습니다. 3주 후, 이 머지(merge)까지 추적하는 데 이틀이 걸리는 예약 버그가 발생합니다.

이것이 바로 다른 문제가 시작되는 지점입니다 — _완료된 코드(finished code)_와 신뢰할 수 있는 저장소(trusted repository) 사이의 거리입니다.

EDD는 본질적으로 인지 도구(awareness tool)입니다. 이는 개발자가 코드가 명시된 의도를 충족하는지에 대해 더 잘 알 수 있게 해줍니다. 하지만 인지 도구에는 구조적인 한계가 있습니다. 그 효과는 이제 알게 된 사실에 대해 누군가가 실제로 행동하느냐에 전적으로 달려 있습니다. 매우 철저한 EDD 프로세스라 할지라도, 아키텍처 경계(architectural boundary)를 조용히 위반하는 머지를 만들어낼 수 있습니다. 이는 코드가 틀렸기 때문이 아니라, 기대 사항이 올바른 제약 조건(constraints)을 포착하지 못했기 때문입니다.

아무도 다음과 같은 기대 사항을 작성하지 않았습니다: "이 변경 사항은 다른 세 팀이 인지하지 못한 상태에서 그들이 의존하는 공유 인터페이스를 수정해서는 안 된다." 그러한 종류의 제약 조건은 기능 명세서(feature spec)에 들어있지 않습니다. 그것은 코드베이스(codebase)의 구조 속에 존재합니다.

그 차이를 접수원(receptionist)과 회전식 게이트(turnstile)의 차이로 생각해 보십시오. 접수원은 제한 구역으로 향하는 누군가가 소속되지 않은 사람처럼 보이면 이를 알아차리고 한마디 합니다. 그 방문객이 멈출지 여부는 전적으로 그들이 말을 들을 의지가 있는지에 달려 있습니다. 회전식 게이트는 아무것도 알아차리지 못합니다 — 그저 올바른 배지(badge) 없이는 열리지 않을 뿐입니다. EDD는 아무리 철저하더라도 접수원입니다. 플래그를 표시하고, 조언하고, 경고할 수는 있지만, 결연한 머지를 막을 수는 없습니다.

두 가지 서로 다른 문제, 두 가지 서로 다른 도구

**명세 문제(Specification problems)**는 다음과 같이 묻습니다: 코드가 내가 의도한 대로 작동하는가? EDD는 이 문제를 다룹니다. 이는 개발자가 구현 전에 의도를 명확히 표현하고, 그 의도가 충족되었다는 증거를 요구하도록 강제합니다.

**조정 문제 (Coordination problems)**는 다음과 같이 질문합니다: 이 변경 사항이 다른 누군가에게 속한 무언가에 영향을 미치는가? 기대 사항을 아무리 많이 작성하더라도 이 문제는 해결되지 않습니다. 왜냐하면 영향을 받는 당사자들이 그 자리에 없기 때문입니다. 이 제약 조건은 기능 명세 (feature spec)만으로는 도출할 수 없습니다. 코드베이스의 실제 결합 구조(coupling structure) — 즉, 어떤 파일들이 역사적으로 함께 변경되었는지, 어떤 팀이 어떤 컴포넌트를 소유하고 있는지, 실제 경계가 어디인지에 대한 지식이 필요합니다.

EDD는 첫 번째 문제를 위해 설계되었습니다. 두 번째 문제를 위해 설계된 것이 아닙니다. EDD를 두 번째 문제에 적용하면 실체 없는 엄격함만을 느끼게 됩니다.

리포지토리가 이미 알고 있는 것

좋은 소식은 조정 문제들이 흔적을 남긴다는 점입니다.

두 컴포넌트가 진정으로 결합되어 있을 때 — 즉, 하나를 변경하면 다른 하나도 반드시 변경해야 할 때 — 그 패턴은 커밋 히스토리 (commit history)에 나타납니다. 시간이 흐름에 따라 반복적으로 함께 수정된 파일들은 _변경 결합 (change coupling)_을 보여줍니다. 이는 아키텍처에 대한 누군가의 의견에서 도출된 데이터 신호가 아니라, 코드베이스가 어떻게 진화해 왔는지에 대한 실제 이력에서 도출된 데이터 신호입니다.

지진계는 판 구조론을 제1원리로부터 추론하여 지진을 예측하지 않습니다. 지진계는 진동을 기록하며, 과거 진동의 패턴은 다음 진동이 어디에서 발생할 가능성이 높은지에 대해 실질적인 정보를 제공합니다. 변경 결합도 같은 방식으로 작동합니다. PricingEngine과 재고 예약 로직이 왜 연관되어 있는지 이해할 필요는 없습니다. 단지 이전 40개의 커밋 중에서 그들이 23번 함께 움직였다는 사실을 인지하기만 하면 됩니다. 그것만으로도 진지하게 받아들일 만한 경고를 울리기에 충분합니다.

프롬프트로부터 생성된 권고(advisory)와 데이터로부터 생성된 트리거(trigger) 사이의 이러한 차이가 바로 인지(awareness)와 거버넌스(governance)의 차이입니다. 하나는 무엇이 중요할 수도 있는지에 대한 의견이고, 다른 하나는 무엇이 중요했는지에 대한 증거입니다.

루프의 두 가지 측면

AI 지원 개발을 위한 전체 워크플로우는 두 개의 뚜렷한 측면을 가진 루프처럼 보입니다:

첫 번째 절반 (EDD): 의도 명시 (Specify intent) → 에이전트 구현 (agent implements) → 에이전트 증명 (agent proves) → 인간의 이의 제기 (human challenges) → 수렴할 때까지 반복 (iterate to convergence). 이는 개발자가 원했던 것과 에이전트가 생성한 것 사이의 간극을 메워줍니다.

두 번째 절반 (변경 결합도 + 거버넌스 (Change Coupling + Governance)): 머지 (merge) 전, 해당 변경 사항이 저장소(repository)의 이력이 암시하는 실제 소유권 경계(ownership boundary)를 넘어서는지 확인합니다. 만약 그렇다면, 단순한 제안이 아닌 필수 요구 사항으로서 조정(coordination) 단계를 실행합니다.

두 절반 중 어느 것도 다른 하나를 대체하지 않습니다. 거버넌스(governance)가 없는 EDD는 잘 명시된 코드를 생성하지만, 팀 경계를 넘어 조용히 머지되는 문제를 막지 못합니다. EDD가 없는 거버넌스는 조정 문제를 잡아내는 게이트(gate)를 만들지만, 명세(specification) 문제를 해결하지는 못합니다. 이 둘이 결합되어야 의도(intent)에서 저장소(repository)에 이르는 전체 거리를 다룰 수 있습니다.

더 깊은 핵심

Laforgia는 EDD의 핵심적인 약점 중 하나인 '여우가 닭장을 지키는 문제 (fox-guarding-the-henhouse problem)'에 대해 솔직하게 말합니다. 코드를 작성한 바로 그 AI가 코드가 작동한다는 증거를 생성한다는 점입니다.

하지만 루프의 거버넌스 절반 역시 이 문제의 독자적인 버전을 가지고 있습니다. 만약 게이트가 정적 규칙(static rules) — 예: 인터페이스 변경은 항상 리뷰를 필요로 함 — 에 기반한다면, 개발자들은 이를 우회하는 법을 배우게 됩니다. 규칙이 너무 투박하기 때문입니다. 게이트는 형식적인 절차(theater)로 전락합니다.

대안은 코드베이스 자체가 생성한 무언가에 기반한 게이트입니다. 즉, 실제 커밋 이력(commit history)에서 도출되어 실제 소유권 구조(ownership structure)에 매핑된 결합 패턴(coupling patterns)입니다. 저장소 자체의 이력이 이 영역의 변경 사항이 역사적으로 국지적인 결정(local decisions)이 아니었다고 말한다면, 그것은 의견이 아닙니다. 그것은 데이터입니다.

마지막 구간(last mile)은 더 나은 프롬프트(prompts)를 위한 곳이 아닙니다. 더 나은 데이터, 그리고 그 데이터가 실질적인 영향력(teeth)을 가질 수 있도록 만드는 곳입니다.

원문은 calyntro.com에 게시되었습니다. Calyntro는 Git 이력에서 변경 결합도 패턴을 추출하여 이를 팀 소유권에 매핑함으로써, 저장소 자체의 이력을 거버넌스 신호(governance signal)로 전환합니다. 라이브 데모 확인하기.