생성은 싸지고, 검증은 비싸진다

지난 몇 달 동안 Coding Agents와 함께 일하면서 한 가지 현상이 점점 더 분명해졌다. 놀랍게도 이제는 코드 자체가 문제의 중심이 아닌 경우가 많다.

예전 같으면 반나절 정도를 잡았을 구현도, 조건이 좋으면 지금은 몇 분 안에 나온다. Agent가 관련 범위를 분석하고, 여러 파일을 수정하고, Unit Tests를 추가하고, Build와 Lint를 실행한 뒤 기술적으로 그럴듯한 Patch를 내놓는다.

여전히 인상적이다. 하지만 그렇다고 일이 자동으로 끝나는 것은 아니다.

나는 무엇이 바뀌었는지 이해해야 한다. 기능 요구사항이 정말 충족되었는지 판단해야 한다. 해법이 기존 아키텍처 모델에 맞는지, 기존 개념을 이어가는지, 아니면 어느새 두 번째 개념을 만들어 냈는지 확인해야 한다. 다른 변경에서는 Security, Contracts, Migration, 운영 동작, Performance가 중요해질 수 있다.

그래서 묘한 비대칭이 생긴다. 구현은 5분이면 끝나는데, 진지한 Review에는 여전히 20분, 30분, 혹은 60분의 집중이 필요하다면 어떻게 될까?

여러 Agents가 병렬로 작업하면 이 효과는 더 선명해진다.

이 글에서는 아직 비용을 계산하지 않는다. 그 이야기는 다음 글에서 다룬다. 여기서 관심 있는 질문은 다른 것이다.

코드 생성이 싸고 빨라질수록, 검증이란 실제로 무엇을 의미하는가?

처리량이 늘어나면 바뀌는 것은 소프트웨어를 만드는 방식만이 아니다. 진짜 어려운 지점도 이동한다.

생성은 신뢰보다 빠르게 확장된다.

Patch는 하나의 주장이다

이 시리즈의 6번째 글에서는 이미 비슷한 문제를 다뤘다. 그럴듯함은 진실의 기준이 아니다. 모델은 설득력 있게 틀릴 수 있다. 여기서는 그 논의를 반복하기보다 한 단계 더 나아가고 싶다.

Coding Agent가 Patch를 만들면, 그 Patch는 암묵적으로 꽤 넓은 주장을 한다.

이 변경은 요구사항을 충족하고, 기존 시스템에 맞으며, 관련 Constraints를 위반하지 않고, 받아들일 수 없는 부작용을 만들지 않는다.

Patch 자체는 아직 그 주장을 증명하지 않는다. Patch는 그 주장 자체다.

Verification은 우리가 그 주장을 받아들일 수 있게 만드는 근거를 제공해야 한다.

일상적인 엔지니어링보다 더 추상적으로 들리지만 실제로는 그렇지 않다. 우리는 이미 다양한 Evidence Channel을 사용하고 있다. 문제는 각각의 신호가 실제로 무엇을 말해 줄 수 있는지 혼동하지 않는 데 있다.

Signal	실제로 답하는 질문
Build	주어진 조건에서 검사된 코드를 빌드할 수 있는가?
Typecheck	타입 시스템이 포착하는 정적 가정들이 일관적인가?
Lint	변경이 명시적으로 코드화된 규칙을 지키는가?
Unit Test	제한된 단위가 기술된 경우에 기대한 대로 동작하는가?
Integration Test	여러 구성 요소가 테스트된 시나리오에서 함께 동작하는가?
E2E / Acceptance Test	구체적인 Flow가 여러 시스템 경계를 가로질러 동작하는가?
Architecture Rule	명시적으로 모델링된 구조적 경계가 지켜지는가?
Human Review	주어진 기능적·기술적 Context에서 해법이 타당한가?
Architecture Review	Responsibility, Concept, Dependency가 여전히 시스템 모델에 맞는가?

이 중 어느 것도 무가치하지 않다. 오히려 좋은 소프트웨어 엔지니어링은 중요한 속성을 가능한 한 많이 기계적으로 검증 가능하게 만드는 데 의존한다. 다만 각 신호가 증명할 수 있는 범위에는 한계가 있다.

Build가 통과했다고 기능적으로 올바른 것은 아니다. Unit Test가 통과했다고 Business Rule이 올바른 Layer에 있다는 뜻도 아니다. E2E Test가 완전한 사용자 Flow를 보호하더라도, 같은 Flow를 위해 기존 메커니즘 옆에 두 번째 State 개념이 새로 생겼다는 사실을 놓칠 수 있다.

초록색 신호는 우리가 실제로 물어본 질문만 증명한다.

따라서 Verification의 핵심 질문도 바뀐다. “Tests가 있는가?”가 아니다.

이 구체적인 변경을 받아들이기 위해 어떤 Evidence가 필요한가?

Verification Surface

이를 위해 나는 하나의 Engineering Model로 Verification Surface라는 개념을 사용한다.

변경의 Verification Surface란, 그 변경이 건드리기 때문에 의미 있게 검증해야 하는 기능적·기술적·구조적·운영적 속성의 집합을 말한다.

핵심은 이 Surface가 Diff 크기와 같지 않다는 점이다.

기계적인 변경은 500줄을 건드릴 수도 있다. 기존 패턴에 맞춰 Mapper를 바꾸거나, 파일을 이동하거나, 명확히 정의된 DTO 변환을 수정할 수 있다. Patch는 크지만 의미 있는 자유도는 작다. Compiler, Tests, 몇 가지 집중적인 Check만으로도 관련 오류 클래스의 상당 부분을 덮을 수 있다.

반대로 10줄짜리 변경은 완전히 다를 수 있다.

Diff는 작다.

Verification Surface는 크다.

중앙 State 메커니즘, 권한 결정, Schema 변경, Public Contract의 작은 수정도 마찬가지다.

코드 양과 Verification Surface는 같은 것이 아니다.

코드 생산이 계속 싸질수록 작성된 줄 수는 더 의미를 잃는다. 더 중요한 질문은 변경이 몇 개의 차원에서 틀릴 수 있는가이다.

이 관점은 또 다른 잘못된 습관도 막아 준다. Review 깊이는 Diff 크기에 반사적으로 비례해서는 안 된다. 작은 텍스트 수정에는 Architecture Review가 필요 없다. 하지만 작은 Authorization Rule 변경에는 필요할 수 있다.

로컬에서는 맞고, 시스템적으로는 틀릴 수 있다

최근의 한 경험이 이 차이를 아주 선명하게 보여 줬다.

어떤 시스템에는 이미 +state에 일반적인 Signal Store가 있었다. 역할은 의도적으로 정의되어 있었다. 관련 Business State가 그곳에 있었고, Reactive Derivation도 그곳에서 만들어졌으며, 데이터 흐름과 상태 변화도 정해진 모델을 따랐다.

그런데 나중에 한 Agent가 application Layer 안에 두 번째 수제 Store를 만들었다.

나에게 Store가 두 개 있다는 사실 자체가 자동으로 아키텍처 오류는 아니다. Source Store와 별도의 ViewModel Store는 충분히 정당한 서로 다른 Responsibilities를 가질 수 있다. 둘이 다른 목적을 맡고 있고 그 분리가 의도적으로 모델링되었다면 오히려 더 나은 아키텍처일 수 있다.

하지만 이번 경우는 아니었다.

두 번째 Store에는 독립적인 기능 Responsibility가 없었다. 이미 존재하는 Derivation을 다시 가져와 또 변환했고, State Responsibility를 중복하기 시작했다. 동시에 구현은 computed, effect 같은 Reactive Mechanism과 훨씬 더 Imperative한 스타일을 섞었다.

그 결과 두 종류의 Drift가 생겼다.

첫 번째는 Responsibility Drift였다. 새로운 기능 개념도 없는데 Responsibility가 이동하거나 중복되었다.

두 번째는 Paradigm Drift였다. 같은 Problem Space 안에 두 번째 프로그래밍 및 State 모델이 생기기 시작했다.

로컬에서 코드는 터무니없지 않았다. 동작할 수 있었다. Tests도 초록색일 수 있었다.

바로 그 점이 이 변경을 흥미롭게 만들었다. 그 Agent는 이전 약 열 번의 작업 동안 매우 깔끔하게 일했다. 그래서 내 집중도 자연스럽게 낮아졌다. 한 번 덜 깊게 봤을 뿐인데, 시스템에 갑자기 두 번째 State 개념이 생겨 있었다.

변경은 로컬에서는 올바르면서도 시스템 전체에서는 잘못될 수 있다.

Architecture Drift는 흔히 하나의 명백히 잘못된 결정에서 생기지 않는다. 각각은 로컬에서 그럴듯한 결정들이 누적되면서 시스템을 서서히 다른 방향으로 끌고 간다.

신뢰할 만한 과거는 주의의 깊이를 바꾼다

이 예시에는 내게 중요한 두 번째 메커니즘도 있다.

Agent가 열 번 연속 안정적으로 일하면 나는 그 경험에서 학습한다. 당연한 일이다. 신뢰는 경험을 통해 형성된다. 사람과도 비슷하게 일한다. 수년간 좋은 결과를 낸 사람의 변경과, 기본적인 문제를 자주 내는 사람의 변경은 똑같이 Review하지 않는다.

하지만 신뢰에는 부작용이 있다. 성공적인 과거는 내 주의의 깊이를 바꿀 수 있다.

이것은 사람이 게으르거나 부주의해진다는 뜻이 아니다. 우리는 제한된 Attention을 배분하고 그 과정에서 확률을 사용한다는 뜻일 뿐이다. 오랫동안 안정적으로 동작한 시스템은 덜 의심스럽게 보인다.

자동 생성에서는 여기에 생산 속도까지 동시에 증가하기 때문에 특별한 문제가 생길 수 있다.

신뢰할 만한 과거가 다음 Patch를 증명해 주지는 않는다.

좋은 이력은 Workflow의 기대 신뢰도에 대한 Evidence다. 하지만 구체적인 변경의 Verification을 대신하지는 않는다.

바로 이 지점에서 나중에 중요해질 형태의 부채가 시작된다. Verification Debt다.

Architecture Review는 Responsibility Verification이다

내 아키텍처는 Layer를 의도적으로 지루하게 유지하려고 한다. 특히 application이 그렇다.

보통 그곳에서 놀라운 Business Logic을 발견하고 싶지 않다. 이 Layer는 관련 Store Properties나 Use Cases를 묶고 Presentation 쪽에 명확한 Contract를 노출한다. Business Rule이 이미 State Responsibility에 속한다면 application에서 다시 한 번 생겨나지 않기를 원한다.

다른 방향도 마찬가지다. 적절한 Event가 Presentation에서 도착했다는 이유만으로 Business Rule이 Presentation으로 들어가서는 안 된다. Signal을 쓰기 편하다는 이유만으로 UI Responsibility가 Store로 이동해서도 안 된다. Infrastructure Mapping은 State에 속하지 않는다. 새로운 State Abstraction에는 분명한 Responsibility가 있어야 한다. 단지 기술적으로 만들 수 있다는 이유만으로 존재해서는 안 된다.

그래서 Architecture Review는 Behavior Test와 다른 질문에 답한다.

Test는 동작을 검증할 수 있다. Architecture Review는 Responsibility가 여전히 올바른 위치에 있는지를 검증한다.

그래서 나는 Architecture Review를 Pattern Matching으로 축소하고 싶지 않다.

Patterns는 도움이 된다. Layering Rules도 도움이 된다. Import Constraints는 자동화하기에 훌륭하다. 예를 들어 presentation이 infrastructure에 직접 접근하지 못하게 만들 수 있다.

하지만 더 어려운 질문은 때때로 이것이다. 이 새로운 Abstraction은 왜 존재하는가? 이 Concept에는 정말 독립적인 Responsibility가 있는가, 아니면 같은 Responsibility를 두 번째로 모델링하고 있는가?

이런 질문에 답하려면 Reviewer가 시스템의 모델을 가져야 한다.

오늘날 이런 시스템적 이해는 내가 경험 많은 개발자를 특히 가치 있게 보는 지점 중 하나다. 그렇다고 이를 인간과 기계 사이의 영구적인 경계로 만들고 싶지는 않다. Review Models는 좋아지고 있고, Context Retrieval도 좋아지고 있으며, Architecture Knowledge도 점점 더 명시적으로 제공할 수 있다.

더 신중한 표현은 이렇다.

오늘의 System Review는 Local Diff Review보다 더 많고 더 안정적인 Context를 요구하는 경우가 많다.

규칙은 도움이 된다 — 다만 미래의 모든 편차를 미리 알 수는 없다

Store 사례가 흥미로운 또 다른 이유는 이 환경이 결코 무규칙 상태가 아니었다는 점이다.

나는 이제 Layering Rules, Agent Files, Skills, 전용 Review Instructions, Mechanical Checks를 사용한다. 이 시리즈의 이전 글은 바로 그 발전을 다뤘다. Build, Lint, Tests, E2E가 점점 Agent Infrastructure의 일부가 되어 Coding Agent가 자신의 변경을 직접 실행하고 검증할 수 있게 된다.

그런데도 두 번째 Store Abstraction은 생겼다.

이것은 이전 글과 모순되지 않는다. 명시적인 규칙이 특히 잘하는 일이 무엇인지 보여 줄 뿐이다. 바로 알려진 Drift 클래스다.

허용되지 않은 Import는 Architecture Rule로 막을 수 있다. 잘못된 Dependency는 Constraint에서 실패할 수 있다. 누락된 Tests는 CI에서 드러날 수 있다. Naming Violation은 Linting으로 잡는다. 잘못된 Layer Access는 기계적으로 제한할 수 있다.

더 어려운 것은 아직 규칙이 없는 Divergence다. 두 번째 경쟁 Concept, 새로운 암묵적 Responsibility, 불필요한 Abstraction, Paradigm Mix, 혹은 세 개의 Library 밖에 이미 있는 Mechanism을 다시 만드는 기술적으로는 동작하는 해법 같은 것들이다.

Architecture Rule이 이를 정확히 금지하려면 그 문제를 미리 알고 있어야 한다.

명시적 규칙은 알려진 Drift 클래스를 줄여 준다. 하지만 새롭고 로컬에서는 그럴듯한 모든 Divergence를 미리 예상할 수는 없다.

그래서 나는 여전히 “더 많은 아키텍처 규칙을 실행 가능하게 만든다”는 방향이 맞다고 본다. 그렇다고 Architecture Review가 사소해지는 것은 아니다. Rule Review는 점점 더 자동화할 수 있다. System Review는 현재로서는 여전히 더 어렵다.

Reviewer는 설득당해서는 안 된다

Review Agents와 일하는 방식을 바꾼 또 하나의 지점이 있다. 가능하면 Reviewer가 먼저 Implementing Agent의 정당화부터 받아들이지 않게 하려고 한다.

이유는 놀랄 만큼 인간적이다. 수사는 앵커를 만든다.

말을 잘하는 개발자는 기술적으로 의심스러운 결정을 아주 설득력 있게 설명할 수 있다. 나도 경험한 적이 있다. 몇 년 전, 학문적으로 매우 탄탄하고 말도 잘하는 동료와 Microservices에 대해 긴 토론을 했다. 대화가 끝날 무렵에는 그 개념이 기본적으로 작동할 수 없는 것처럼 거의 설득당했다.

나중에 자전거를 타다가 문득 생각했다.

잠깐. 방금 그 논리는 말이 안 되는데.

그 동료가 아무것도 몰랐기 때문이 아니다. 오히려 반대다. 전문성이 높았기 때문에 논증이 더 설득력 있게 들렸다.

그 경험은 오래 남았다. 좋은 설명은 내가 대상을 독립적으로 검토하기 전에 평가에 영향을 줄 수 있다.

AI Generated Code도 마찬가지다. Coding Agent는 구현을 마친 뒤 왜 선택한 해법이 우아하고, 기존 Pattern을 따르며, 모든 Requirements를 충족하는지 아주 멋지게 설명할 수 있다.

그 설명은 유용한 정보다.

하지만 그 주장이 참이라는 Evidence는 아니다.

그럴듯한 정당화는 Evidence가 아니다.

그래서 Review Agent에게는 다른 형태의 과제를 주는 편을 선호한다. “Coding Agent의 해법이 합리적인지 설명하라”가 아니다. 대략 이런 식이다.

Requirement
+
Constraints
+
관련 System Context
+
Diff
↓
독립 검증

Implementation Rationale은 나중에 여전히 유용할 수 있다. 다만 그것이 Verifier의 첫 관점을 정하게 하고 싶지는 않다.

Verifier는 Generator의 설명이 아니라 Requirements와 Constraints를 기준으로 해법을 검증해야 한다.

Independent Evidence에는 다른 관점이 필요하다

여기서 또 하나의 개념이 나온다. Independent Evidence다.

우리는 독립성을 참여한 모델 수와 쉽게 동일시한다. Agent A가 구현하고 Agent B가 Review했으니 두 개의 관점이 있다고 생각한다.

하지만 자동으로 그렇게 되지는 않는다.

실제 Workflow에서 한 Junior가 Agent 지원으로 구현하고, 두 번째 Junior가 역시 Agent 지원으로 Review한 상황을 본 적이 있다. 결과는 좋아 보였다. Review Agent도 중요한 문제를 찾지 못했다.

그런데 경험 많은 Reviewer가 단 하나의 비판적 질문을 던졌다.

해법 전체가 무너지기 시작했다.

그 뒤 더 강하게 구성한 Review Agent를 돌렸더니 여러 개의 심각한 문제가 나왔다.

이것은 Junior가 AI를 쓰면 안 된다는 뜻도 아니고, 두 번째 모델이 쓸모없다는 뜻도 아니다. 흥미로운 관찰은 다른 곳에 있다.

두 번째 모델이 참여했다는 사실만으로 Review가 독립적이 되는 것은 아니다.

두 모델은 같은 가정을 받아들일 수 있다. 같은 Repository 영역을 찾지 못하고, 같은 Architecture Rule을 놓치고, 같은 불완전한 Requirement Context를 읽고, 같은 그럴듯한 이야기를 받아들일 수 있다.

따라서 독립성은 모델의 정체성보다 검증 관점에서 더 많이 나온다.

Generator는 묻는다. 이 Requirement를 어떻게 구현할까?

Verifier는 오히려 묻는 편이 낫다. 이 Patch가 어떤 관련 Requirement, Constraint, System Assumption을 위반할 수 있는가?

이 역시 독립성을 보장하지는 않는다. 하지만 적어도 두 작업이 동일하지는 않다.

반론할 수 있는 능력도 Capability다

나는 이제 강한 모델에게 명시적으로 반론을 기대한다.

내 아이디어가 꽤 괜찮다고 설명해 주는 Reviewer는 필요 없다. 내가 틀렸다면 가능한 한 빨리 알고 싶다.

Frontier Models와 긴 기술 토론을 하면서 이런 일은 이미 여러 번 있었다. 나는 꽤 명확한 의견으로 시작하고, 모델은 특정 지점에서 반대한다. 우리는 밑에 깔린 가정을 하나씩 검토하고, 결국 내가 원래 입장을 바꾼다.

나는 그것을 Workflow의 실패라고 생각하지 않는다.

그게 Workflow다.

내 해법이 그럴듯하다고 확인해 주는 Reviewer는 필요 없다. 충분한 이유가 있을 때 나에게 반론하는 Reviewer가 필요하다.

그렇다고 모든 Review를 최대 강도의 Red Teaming으로 만들자는 뜻은 아니다.

나도 해 봤다. Agent에게 무슨 일이 있어도 Risk를 찾아내라고 하면 Risk를 찾아낸다. 어느 순간 이론적인 Edge Cases가 실제 Architecture Violation과 같은 강도로 추적된다. 다음 Fix는 Guards, Fallbacks, Abstractions를 추가하고, 그것들이 다시 다음 Review의 새로운 공격면이 된다.

이런 방식이 소프트웨어를 더 견고하게 만들 때도 있다.

반대로 지나치게 방어적이고 읽기 어려운 소프트웨어를 만들 수도 있다.

그래서 내게 더 좋은 특성은 최대 공격성이 아니라 Calibration이다. 충분한 이유가 있으면 반론하고, 현재 Evidence가 충분하다면 해법을 받아들인다.

Verification Diversity

Independent Evidence는 또 다른 원칙으로 이어진다. 서로 다른 Verification Channel은 가능하면 같은 질문만 반복해서는 안 된다.

나는 이를 Verification Diversity라고 부른다.

구현에 가까운 Unit Test는 E2E Test와 다른 종류의 오류에 민감하다. Architecture Rule은 도메인 Reviewer와 다른 문제를 본다. Static Typecheck는 Security Review와 다른 Defect를 찾는다. Review LLM은 어떤 Test에도 기술되지 않은 Smell을 발견할 수 있다. Domain Owner는 기술적으로 완벽한 구현이 사실은 잘못된 Requirement를 구현하고 있다는 사실을 알아챌 수 있다.

목표는 모든 Patch에 최대한 많은 검증 인스턴스를 던지는 것이 아니다.

검증이 많다고 자동으로 더 좋은 검증이 되는 것은 아니다. 중요한 것은 서로 다른 채널이 서로 다른 관련 오류 클래스를 드러내는가이다.

따라서 Review 깊이는 Verification Surface가 결정해야 한다. 정적인 텍스트 변경은 Surface가 작다. Presentation, Application, State, Infrastructure, API를 모두 건드리는 Feature는 Surface가 더 크다. 이 경우 Layering Boundaries, Slicing, Autonomy, Established Patterns, 불필요한 새 Dependencies, 기존 도구를 재사용했는지 아니면 Self-Made Solutions를 도입했는지가 중요해진다.

Diff 크기는 여러 신호 중 하나일 뿐이다.

Verification Surface는 변경된 줄 수보다 변경이 어떤 경계를 건드렸는지에 더 크게 좌우된다.

Test Level마다 필요한 독립성은 다르다

Independent Evidence를 원한다고 해서 새로운 교조를 만들 필요는 없다.

예를 들어 Implementing Agent가 자신의 Unit Tests를 작성하면 안 된다는 일률적인 규칙에는 큰 의미를 느끼지 못한다. Unit Tests는 구체적인 구현을 보호하기 위해 존재하는 경우가 많다. 이런 맥락에서는 구현과 가깝다는 사실 자체가 문제가 아니다.

도메인 함수를 구현하는 Agent는 관련 Unit Tests를 함께 추가하고, Edge Cases를 다루고, Local Invariants를 보호할 수 있다. 그런 Tests는 Patch의 일부가 되고 바로 그 구현에 대한 Evidence를 늘린다.

반면 Acceptance Tests와 E2E Tests에는 대체로 더 많은 독립성을 원한다.

그곳에서 중요한 것은 개별 Method가 동작하는가보다 기대한 Flow가 관련 Layer 전체를 가로질러 동작하는가이다. 그래서 Requirements와 System Access를 가진 전문 Agent가 다른 관점에서 전체 흐름을 검증하게 하는 편을 선호한다.

여기서도 증명력을 과장해서는 안 된다. E2E Test는 우리가 설명한 기대 동작만 검증한다. 실제 Requirements는 드물게 완전하다.

Tests는 충분히 명시된 Expectations에 대해서만 검증할 수 있다. 빠진 Requirements가 Testing을 더 많이 한다고 자동으로 완성되지는 않는다.

이것은 Verification 자체의 중요한 한계다. Evidence는 알려져 있거나 추론 가능한 Expectations에 비추어 Claim을 검사할 수 있을 뿐이다. 어떤 예외 상황이 기능적으로 어떻게 동작해야 하는지 아무도 모른다면 Test가 그 결정을 무에서 만들어 낼 수는 없다.

좋은 Verifier는 자신의 권한 경계를 안다

그래서 내게 Verification에는 누가 실제로 그 결정을 내릴 권한이 있는가라는 질문도 포함된다.

기능 요구사항이 불명확하면 도메인 쪽이 결정한다. Architect나 Developer는 선택지를 설명하고, 기술적 결과를 드러내고, 모순을 지적할 수 있다. 그렇다고 새로운 Business Rule을 만들어 낼 권한까지 자동으로 생기는 것은 아니다.

반대로 기능 Ticket에서 시작된 변경이라고 해서 Architecture Decision까지 도메인 쪽의 몫이 되는 것도 아니다.

내 작업에서는 경계가 비교적 분명하다. 도메인 쪽은 기능적 권한을 갖고, Engineering / Architecture는 기술적 권한을 갖는다.

강한 모델에서는 내가 명확히 원하는 행동을 점점 자주 본다. 모델이 불명확함을 발견하고, 이 질문은 Domain Owner와 확인해야 한다고 말한다.

좋은 답이다.

10번째 글은 이미 추측하지 말고 멈추기라는 생각 아래 이런 태도를 다뤘다. Verification 관점에서는 다음과 같다.

좋은 Verifier는 모든 질문에 답할 필요가 없다. 자신에게 그 답을 결정할 권한이 없는 순간을 알아야 한다.

의도적인 예외인가, 눈치채지 못한 Drift인가?

Architecture Rules 자체도 자연법칙은 아니다.

규칙에서 벗어나는 것이 합리적인 상황은 있다. Legacy Contract가 깔끔한 Target Architecture를 막을 수도 있다. 기술적 제약 때문에 Established Pattern이 실용적이지 않을 수도 있다. 완전한 해법은 가능하지만 특정 Product Context에서 경제적으로 정당화되지 않을 수도 있다.

하지만 나는 “다른 방법이 없다”는 말을 충분한 이유로 받아들이지 않는다.

규칙을 깨야 한다면 그 규칙 자체가 다시 분석의 대상이 된다. 왜 여기서는 작동하지 않는가? 어떤 Alternative가 있는가? 이미 Established Solution이 있는가? 편차를 로컬에 제한할 수 있는가? 장기적으로 어떤 의미가 있는가?

분석한 뒤의 답이 실제로 “이번에는 예외를 둔다”일 수도 있다.

그렇다면 의식적인 결정으로 만들고 싶다. 경제적 현실 때문에 기술적으로 더 나쁜 해법을 선택해야 한다면 그것은 Tech Debt다. 중요한 것은 우리가 그것을 떠안았다는 사실을 알고 있는가이다.

의도적인 예외는 결정이다. 알아차리지 못한 예외는 Architecture Drift다.

이것은 모든 작은 일에 관료적인 ADR을 쓰자는 이야기가 아니다. 중요한 편차가 평범한 구현 세부사항 속으로 무심코 사라지지 않게 하자는 이야기다.

Verification Debt

이제 앞에서 말한 개념을 더 정확히 정의할 수 있다.

내가 말하는 Verification Debt는 단순히 Tests가 부족하다는 뜻이 아니다.

기능적·시스템적 올바름에 대한 신뢰할 만한 Evidence를 만드는 속도보다 변경이 생성되는 속도가 빠를 때 Verification Debt가 생긴다.

여러 Agents가 병렬로 일할 때 생길 수 있다. Implementation Time은 급격히 줄었는데 Review Time은 비례해서 줄지 않을 때도 생긴다. Build, Lint, Unit Tests는 훌륭하게 자동화했지만 Systemic Changes는 겉핥기만 할 때도 생긴다. 혹은 Review Agent가 Local Diff만 보고, 관련 경쟁 Abstraction이 Context 밖에 있을 때도 생긴다.

여기서 중요한 제한이 있다. Agentic Work가 자동으로 Verification Debt를 만드는 것은 아니다.

Verification도 비례해서 성장한다면 Debt가 생길 필요는 없다. 바로 그것이 실제 Engineering Task다.

Generation만 확장해서는 안 된다. 그 결과를 검사하고, 해석하고, 신뢰할 수 있게 받아들이는 능력도 함께 확장해야 한다.

Generation은 병렬화하기 더 쉽다

현재 나는 아주 실용적인 한계에 계속 부딪힌다.

Coding Agents 여러 개를 동시에 시작할 수 있다. 하나는 Feature를 구현하고, 하나는 Refactoring을 하고, 세 번째는 Tests를 추가하고, 네 번째는 Documentation을 작업한다.

계산상 이런 처리량은 거의 끝없이 늘릴 수 있다. 하지만 내 Attention은 같은 방식으로 병렬화할 수 없다.

두 변경이 서로 다른 기능 및 Architecture Context를 갖는다면 나는 둘을 동시에 진지하게 이해할 수 없다. 오가며 볼 수는 있다. Review를 위임할 수 있다. Mechanical Checks를 자동화할 수 있다.

하지만 Systemic Judgment는 현재 제한된 자원이다.

그래서 내 개인적인 Bottleneck은 놀랍게도 코드 작성이 아닌 경우가 점점 많아졌다.

진지한 Review가 현재의 Bottleneck이다.

여기서 현재라는 말이 중요하다.

Review Models는 좋아지고 있다. Repository Retrieval도 좋아진다. Architecture Rules는 더 명시적으로 바뀐다. Models는 더 크고 안정적인 작업 공간을 얻는다. 몇 년 뒤에는 오늘 내가 직접 확인하는 것의 상당 부분이 신뢰성 있게 자동화될 수도 있다.

그러므로 더 일반적인 주장은 영구적인 Human-vs.-AI 경계에 의존할 필요가 없다.

Bottleneck은 신뢰를 아직 충분히 자동화할 수 없는 곳으로 이동한다.

그리고 이는 병렬화의 한계를 만든다.

Generation은 시스템이 결과를 신뢰성 있게 Verification할 수 있는 능력보다 더 빠르게 확장되어서는 안 된다.

소프트웨어 개발은 실제로 Verification Work로 이동하고 있는가?

이 개인적 관찰은 현재 연구의 일부와 놀랄 만큼 잘 맞는다. 하지만 아직 모든 소프트웨어 팀의 보편적 변화라고 말할 만큼 Evidence가 강한 것은 아니다.

Annie Vella와 Kelly Blincoe의 2026년 Longitudinal Study는 특히 흥미롭다. 저자들은 Professional Software Engineers를 6개월 간격으로 두 차례 조사했다. 첫 번째 Wave에는 158명, 두 번째에는 101명이 참여했고, 95명에 대해 Paired Longitudinal Data가 있었다. 82%가 실제 코드 작성에 쓰는 시간이 줄었다고 답했다. 저자들은 creation에서 verification으로의 더 넓은 이동을 설명하며, AI Output을 Steering, Evaluating, Correcting하는 작업을 supervisory engineering work라고 제안한다. 동시에 Perceived Productivity Improvement는 높게 유지되었지만, Paired Participants 중 적어도 하나의 Developer Experience 차원에서 악화를 보고한 비율은 14%에서 27%로 늘었다. 2026년 9월 현재 이 연구는 Preprint 또는 Submitted Manuscript 상태이므로 그에 맞게 신중히 해석해야 한다.

Agnia Sergeyuk, Ilya Zakharov, Ekaterina Koshchenko, Maliheh Izadi의 Systematic Literature Review는 더 넓은 범위를 다룬다. 개발 환경의 Human-AI Experience에 관한 90개의 Empirical Studies를 종합했다. 저자들은 Productivity Gains와 함께 Verification Overhead, Over-Reliance를 보고하며, Quality 측면에서는 Correctness, Maintainability, Security 위험이 반복해서 나타난다. 이 연구는 Empirical Software Engineering에 게재되었고, 동시에 이 분야가 얼마나 이질적이며 더 길고 현실적인 평가가 얼마나 필요한지도 보여 준다.

Mohamed, Assi, Guizani의 또 다른 Systematic Review and Mapping Study도 39개의 Peer-Reviewed Studies를 바탕으로 비슷하게 신중한 결론을 내린다. 대부분의 연구가 특히 Routine Tasks와 Code Search에서 Productivity Benefits를 보고하지만, Code Quality에는 일관된 효과가 없고 결과는 Task, Measurement Method, Context에 크게 좌우된다.

즉, 연구는 업무 구성의 이동을 어느 정도 뒷받침한다. 하지만 Verification Work가 늘면 자동으로 Productivity가 떨어진다는 단순한 등식은 뒷받침하지 않는다.

Output이 늘면 일이 다른 곳으로 이동할 수 있다

Feiyang Xu와 동료들의 2025년 연구는 GitHub Copilot 도입 이후의 Open-Source Projects를 살펴본다. 저자들은 특히 경험이 적거나 Peripheral한 Contributors의 Productivity가 높아지는 동시에 Rework도 증가했다고 보고한다. 분석에서 경험 많은 Core Developers는 6.5% 더 많은 코드를 Review했고, 자신의 Code Productivity는 19% 낮아졌다. 이 연구는 Conference Contribution 또는 Preprint로 보는 것이 적절하다. 로컬한 Productivity Gain이 시스템 내부의 다른 사람에게 일을 이동시킬 수 있다는 흥미로운 신호지만, AI-Assisted Software Development 전반에 적용되는 보편적 Effect Size는 아니다.

Qualitative Data는 같은 가능성을 다른 각도에서 보여 준다. Sebastian Baltes, Marc Cheong, Christoph Treude는 2026년 Preprint에서 이른바 AI Slop을 다룬 Reddit과 Hacker News 게시물 1,154개를 분석했다. Coding 결과의 주요 Theme Cluster 중 하나는 Review Friction이다. 개발자들은 추가 Reviewer Burden, Trust Loss, Countermeasures를 논의한다. 이 자료는 특정 Online Communities의 인식과 담론을 보여 주는 것이지, 대표적인 개발팀의 실제 Productivity Effect를 측정한 것은 아니다.

Fawzy, Tahir, Blincoe의 또 다른 2026년 Preprint는 162명을 대상으로 Non-Developers, Novices, Professional Developers의 Verification Practices를 비교한다. 저자들은 perception-action gap을 설명한다. AI-Generated Code에 문제가 있을 수 있다는 인식은 비교적 널리 퍼져 있지만, 실제로 코드를 평가하고 Debug하고 Verification할 수 있는 능력은 Experience와 Hands-On Programming Practice에 더 크게 좌우된다. 이것은 경험 많은 개발자만 AI Code를 검증할 수 있다는 증거가 아니다. Risk Awareness와 Verification Capability가 서로 다른 역량이라는 더 신중한 주장을 뒷받침한다.

반대 Evidence도 똑같이 중요하다

이 연구들만 고르면 쉽게 미리 정해진 이야기를 만들 수 있다. AI가 더 많은 코드를 만들고, 경험 많은 개발자는 전부 고쳐야 하며, 결국 모두가 손해를 본다는 이야기다.

연구는 그렇게 단순하지 않다.

Microsoft, Accenture, 또 다른 Fortune 100 Company에서 수행한 Randomized Field Experiments는 총 4,867명의 개발자를 포함했다. Cui와 동료들의 Pooled Analysis에서는 Generative Coding Assistant를 사용할 수 있는 개발자들이 약 26% 더 많은 Tasks를 완료했다고 보고했다. 경험이 적은 개발자들은 Adoption도 높고 Productivity Gain도 더 컸다. 이 연구는 2026년 Management Science에 게재되었으며, 실제 기업 환경에서 AI Assistance가 측정된 Throughput에 긍정적인 전체 효과를 줄 수도 있음을 분명히 보여 준다.

반대 방향을 보여 준 유명한 연구는 2025년 METR Experiment다. 경험 많은 Open-Source Developers 16명이 수년간 익숙했던 Repositories에서 246개의 실제 Tasks를 수행했다. 당시 사용 가능한 AI Tools를 썼을 때 평균 19% 더 오래 걸렸다. 특히 흥미로운 것은 Perception Gap이었다. 개발자들은 자신이 더 빨랐다고 생각했다. 추가 시간의 일부는 Prompting과 Generated Output Review에 쓰였다.

하지만 이 수치 역시 영원한 사실처럼 고정해서는 안 된다.

METR는 2026년 2월 이후 Model Generations에 대한 새 데이터를 공개했다. 결과는 가능한 Speedup 쪽을 더 가리켰지만, Selection Effects와 Agents가 병렬로 작업할 때 시간 측정이 어려운 문제 때문에 새로운 정확한 Effect Size를 제시하기에는 충분히 Robust하지 않았다. 연구진도 그래서 Study Design을 바꿨다.

내게 더 흥미로운 과학적 결론은 바로 이것이다. Task Type, Experience, Codebase, Model Generation, Tooling, Quality Bar, 사용 가능한 Verification Infrastructure, Workflow가 결과를 모두 바꾼다.

현재 가장 타당한 요약은 훨씬 절제되어 있다.

개발자 업무의 일부가 Creation에서 Steering, Review, Verification으로 이동하고 있다는 Evidence는 늘고 있다. 그것이 Net Productivity Gain이 될지 추가 부담이 될지는 Context에 크게 좌우된다.

왜 System Understanding은 오늘 여전히 가치가 있는가

이제 다시 두 번째 Store 이야기로 돌아간다.

경험 많은 Developer가 그 구현을 더 빨리 알아챘다면, 10줄 코드를 더 빨리 읽을 수 있어서가 아닐 가능성이 크다. 장점은 다른 데 있다.

그는 보통 System Model을 가지고 있다.

이미 Store가 있다는 것을 안다. 그 Responsibility를 안다. 새로운 Abstraction이 기능적으로 독립적인 것을 모델링하지 않는다는 것을 알아챈다. 또 다른 세 개의 Local Changes가 각각은 그럴듯하지만, 합쳐지면 새로운 Architecture Paradigm을 만들고 있다는 점도 볼 수 있다.

이런 지식은 Experience의 가치를 바꾼다.

오늘, 시스템을 이해하는 개발자의 가치는 Patch를 더 빨리 쓰는 데서보다 많은 Patches의 합이 시스템에 무엇을 하고 있는지 알아차리는 데서 점점 더 커진다.

여기서도 오늘이라는 말이 중요하다.

AI System이 충분히 좋은 System Model을 가질 수 없다는 기술적 원칙은 없다. Review Agents는 좋은 Context를 받으면 이미 놀랄 만큼 강하다. 잘못된 Layer Access, Broken Contracts, Missing Tests, 수상한 Error-Handling Paths, Inconsistent Implementations를 찾는다.

난도가 올라가는 것은 이런 질문이다. 이 Abstraction은 동작한다. 하지만 이 Concept이 다른 Slice에 이미 존재하지 않는가? 그래서 장기적으로 두 개의 경쟁 State Models를 만들고 있지는 않은가?

이를 답하려면 Agent가 먼저 관련 비교 Mechanism을 찾아야 하고, Semantic Relationship을 이해한 뒤, 그 유사성이 의도된 분리인지 불필요한 중복인지 판단해야 한다.

이는 Local Diff Review보다 훨씬 큰 Verification Surface다.

Review Automation은 접근 가능한 Evidence만큼만 확장된다

그래도 여기서 AI Review가 피상적일 뿐이라고 결론 내리고 싶지는 않다.

오히려 반대다. 나는 이제 Specialized Review Agents를 즐겨 사용하고, Requirements, Architecture Rules, Diffs를 기준으로 의도적으로 검토하게 한다. 특히 Explicit Constraints에서는 엄청난 양의 Mechanical Review Work를 맡길 수 있다.

핵심은 다른 데 있다.

Review Automation은 Reviewer가 관련 Evidence와 Context에 접근할 수 있는 범위만큼만 확장된다.

이 점은 이 글을 이전의 AI-Friendly Software 글과 다시 연결한다.

그 글의 질문 중 하나는 이랬다. Agent가 Build, Lint, Tests, E2E를 스스로 실행할 수 있는가?

이번 글의 질문은 다르다. 그 초록색 결과들이 실제로 무엇을 증명하며, 그 뒤에도 어떤 Quality Dimensions가 여전히 열려 있는가?

실행 가능한 Workspace는 강한 Verification의 중요한 기반이다. 하지만 구체적인 변경에 어느 정도의 Verification이 충분한지는 아직 정의하지 않는다. 그것은 Verification Surface에 달려 있다.

“Expensive”는 우선 Attention을 뜻한다

이 글의 제목은 다음과 같다.

Generation is cheap, verification is expensive.

여기서 expensive는 아직 주로 유로, 달러, Token을 뜻하지 않는다.

Verification에는 Attention이 필요하다. Judgment가 필요하다. Relevant Context가 필요하다. 때로는 Independent Model Runs가 필요하고, 때로는 실제 Runtime Environment, Security Expertise, 혹은 Agent 혼자 결정해서는 안 되는 Domain Decision이 필요하다.

Generation은 몇 분 안에 네 개의 그럴듯한 해법을 만들 수 있다. 그중 어느 것이 받아들일 만한지에 대한 질문은 사라지지 않는다.

미래에는 그 결정 자체도 점점 더 자동화될 수 있다. 자연스러운 발전이다. 하지만 Generation이 Reliable Verification보다 빠르게 확장되는 한, Bottleneck은 단지 이동할 뿐이다.

그래서 내게 실무적 결론은 꽤 분명하다. Coding Agents는 Verification System이 그 Throughput을 감당할 수 있는 범위까지만 병렬화해야 한다. 동시에 Coding Agents 자체에 투자하는 만큼 Review Agents, Acceptance Tests, Architecture Rules, 기타 Verification Infrastructure에도 의식적으로 투자할 가치가 있다. 그리고 큰 Systemic Verification Surface를 가진 변경에는 오늘도 해당 시스템을 정말 이해하는 사람을 의도적으로 참여시킨다.

마지막 지점이 영구적으로 인간의 몫일지는 열려 있다. 그 뒤의 원칙은 더 일반적이다.

Generation이 싸질수록, 변경을 받아들이기 전에 어떤 Evidence를 요구할 것인지가 더 중요해진다.

그래서 우리는 Agent가 얼마나 많은 코드를 생산할 수 있는지만 측정해서는 안 된다. Generated Patch가 어떻게 검증된, 받아들일 수 있는 변경이 되는지 이해해야 한다.

그리고 바로 거기서 다음 질문이 나온다.

Verification에 Attention, Model Runs, Tests, E2E, 실제 Infrastructure, Human Judgment가 필요하다면, 우리가 충분히 신뢰할 수 있는 변경 하나는 실제로 얼마의 비용이 드는가?

그것이 경제적 관점이다.

그리고 그 이야기는 다음 글에 속한다.

코드는 싸진다. 신뢰는 자동으로 싸지지 않는다. Bottleneck은 신뢰를 아직 충분히 자동화할 수 없는 곳으로 이동한다.

출처와 연구상 위치

Annie Vella, Kelly Blincoe — “The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study”, 2026.
Professional Software Developers를 대상으로 6개월 간격의 두 시점에서 수행한 Longitudinal Mixed-Methods Study. Creation에서 Verification으로의 이동과 supervisory engineering work라는 용어와 관련 있다. 2026년 9월 기준으로는 Preprint 또는 Submitted Manuscript로 분류하는 것이 적절하다.

Agnia Sergeyuk, Ilya Zakharov, Ekaterina Koshchenko, Maliheh Izadi — “Human-AI experience in integrated development environments: a systematic literature review”.
90개 연구를 다룬 Systematic Literature Review로, Empirical Software Engineering에 게재되었다. Productivity Gains, Verification Overhead, Over-Reliance, Correctness·Maintainability·Security Risk와 관련 있다. 동시에 연구 분야의 이질성을 보여 주며 더 길고 폭넓은 평가가 필요하다고 지적한다.

Amr Mohamed, Maram Assi, Mariam Guizani — “The Impact of LLM-Assistants on Software Developer Productivity: A Systematic Review and Mapping Study”.
39개의 Peer-Reviewed Studies를 종합했다. 대다수는 Productivity Gains를 보고하지만 Code Quality 결과는 일관되지 않고 Context 의존성이 크다.

Feiyang Xu, Poonacha K. Medappa, Murat M. Tunç, Martijn Vroegindeweij, Jan C. Fransoo — “AI-assisted Programming May Decrease the Productivity of Experienced Developers by Increasing Maintenance Burden” / “GenAI as a coding partner”.
Copilot 도입 이후 Open-Source Development를 분석했으며 Core Developers의 Review 및 Rework 증가 등을 보고한다. Conference Contribution 또는 Preprint로 분류하는 것이 적절하다. 결과는 가능한 Work Redistribution의 신호이지 보편적 Effect Size가 아니다.

Sebastian Baltes, Marc Cheong, Christoph Treude — “An Endless Stream of AI Slop: How Developers Discuss the Burden of AI-Assisted Software Development”, 2026.
Reddit과 Hacker News 게시물 1,154개를 분석한 Qualitative Study. Perceived Review Friction, Trust Loss, Maintenance Burden과 관련 있다. 이 자료는 개발자 담론을 반영하며 대표적인 Productivity Measurement로 해석해서는 안 된다.

Ahmed Fawzy, Amjed Tahir, Kelly Blincoe — “From Prompting to Verification: How Experience Shapes Vibe Coding Practices”, 2026.
서로 다른 경험 수준의 참여자 162명을 대상으로 한 Survey Preprint. perception-action gap과 관련 있다. Risk Awareness와 AI-Generated Software를 실제로 Verification할 수 있는 능력은 같은 것이 아니다.

Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng, Tobias Salz — “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers”. Management Science, 2026년 2월 27일 온라인 게재. 게재 정보 및 DOI.
Microsoft, Accenture, Fortune 100 Company에서 총 4,867명의 개발자를 대상으로 한 Randomized Field Experiments. Pooled Analysis는 상당한 Productivity Gain을 보고하며, 여기서는 단순한 부담 증가 서사에 대한 중요한 Counterevidence로 사용된다.

Joel Becker, Nate Rush, Elizabeth Barnes, David Rein / METR — “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”.
익숙한 Repositories에서 실제 Tasks 246개를 수행한 경험 많은 Open-Source Developers 16명을 대상으로 한 Randomized Experiment. Early-2025 Tools는 대상 개발자를 평균 19% 느리게 만들었다. METR 자체도 일반화를 경고하며, 2026년 후속 데이터는 Effect 변화 가능성을 보여 주지만 새로운 정확한 Effect Size를 제시할 만큼 Robust하지 않다.

이 글의 Verification Surface, Verification Debt, Verification Diversity는 Engineering Models로 사용하는 용어다. 인용한 연구가 이 구체적인 용어 체계를 정립한 것은 아니다. 다만 Verification Overhead, 업무 구성 변화, Review Burden, Context-Dependent Productivity와 연결되는 Empirical Evidence를 제공한다.