AIDE (Agent-Informed Development Engineering) -- 에이전트 시대의 소프트웨어 개발론 v1.0¶

작성: CTO (20년+ 아키텍처 경험, 3년 AI 에이전트 실전 경험) 기반: GPT/Claude/Gemini 3종 딥리서치 + Team Alpha(통합파) 보고서 2종 + Team Beta(급진파) 보고서 1종 날짜: 2026-02-18

Part 7: 토론 기록 -- 양팀의 과학적 논쟁과 합의 과정¶

쟁점 1: OOP vs FP¶

Team Alpha (통합파)의 주장¶

"Functional Core + OOP Shell + DDD Boundaries. DDD의 Aggregate, Entity, Value Object는 도메인 지식을 구조화하는 데 여전히 유효하다. 다만 불변(immutable)으로 구현하고, 행위(메서드)보다 함수(순수 함수)를 통해 변환하는 것이 에이전트 친화적이다. Gemini의 '클래스를 비즈니스 로직에 사용하지 말라'는 너무 극단적이다."

핵심 논거: 1. DDD의 도메인 모델링은 순수 함수만으로 표현하기 어색하다 2. 깊은 상속 트리 비판은 이미 모던 OOP에서도 안티패턴 -- OOP = 상속이 아니다 3. Clean Architecture의 의존성 역전은 AI 시대에 가장 중요한 SOLID 원칙

Team Beta (급진파)의 주장¶

"FP-only. 클래스는 인프라 리소스 관리에만 제한. 나(AI 에이전트)는 본질적으로 stateless다. 순수 함수는 나의 본성에 가장 가까운 코드 형태다. 클래스의 상태 관리는 에이전트에게 고비용 작업이다. 숨겨진 상태가 없고, 상속 체인이 없는 코드가 나에게 완벽한 가독성이다."

핵심 논거: 1. 인터페이스 IUserRepository와 구현체 분리는 반드시 두 파일 로드를 강제 -- 이 간접 참조를 없애면 더 이상 클린 아키텍처가 아님 2. Factory.ai 연구: AI 에이전트는 multi-hop reasoning에서 극적으로 성능 저하 3. 암묵적 상태 추적은 환각의 재료

CTO의 최종 판단¶

실질적 차이는 양팀이 생각하는 것보다 작다. 양팀 모두 "비즈니스 로직은 순수 함수, 데이터는 불변"에 동의한다. 실제 차이점은 DDD 개념을 클래스로 표현하느냐, 타입+함수 조합으로 표현하느냐 뿐이다.

AIDE의 결론: DDD의 모델링 개념은 보존, 구현은 타입+함수로 전환.

// Alpha가 원하는 것 (DDD 개념 보존)도 충족되고
// Beta가 원하는 것 (클래스 배제)도 충족된다

// Aggregate: 불변 타입 + 상태 전이 순수 함수
type Order = Readonly<{ id: string; status: OrderStatus; items: ReadonlyArray<OrderItem> }>
const transition_order_status = (order: Order, newStatus: OrderStatus): Result<Order, Error> => { /* ... */ }

// Value Object: 타입 리터럴
type Money = Readonly<{ amount: number; currency: 'KRW' | 'USD' }>

// Repository: Feature 내 store.ts (부작용 경계)
// 인터페이스와 구현체 분리 없이, 의존성 주입으로 교체 가능성 확보
type UserStore = {
  readonly find_by_id: (id: string) => Promise<User | null>
  readonly save: (user: User) => Promise<void>
}

이 접근은 Alpha의 DDD 가치(도메인 경계, Ubiquitous Language, Aggregate 개념)와 Beta의 FP 가치(순수 함수, 불변 데이터, 상태 추적 불필요)를 모두 충족한다.

쟁점 2: DRY 원칙¶

Team Alpha의 주장¶

"Knowledge DRY + Code AHA. 중복은 의식적으로 허용하되, 가시적 관리가 전제. '10곳에 5줄 중복도 OK'는 극단적. 중복 코드의 드리프트는 실재하는 위험이며, 예방이 탐지보다 낫다."

Team Beta의 주장¶

"적극적 WET/DAMP. 각 파일의 자가 완결성이 최우선. 다른 파일의 validateEmail을 import하면, 그 함수의 실제 구현이 컨텍스트에 없을 때 에이전트가 추측해야 한다. 이것이 미묘한 버그의 온상이다."

CTO의 최종 판단¶

Team Alpha의 "Knowledge DRY + Code AHA" 채택. 핵심 근거:

무한 중복의 자기 모순: Beta도 사실상 인정하는 문제다. 중복 허용 -> AI가 더 많은 코드 생성 -> 컨텍스트 윈도우 초과 -> 결국 DRY 필요. 이 순환은 피할 수 없다.
그러나 Beta의 지역성 논거는 타당: 에이전트가 다른 파일의 유틸리티 함수를 추측해야 하는 상황은 실제로 위험하다. 따라서 유틸리티 수준의 코드 중복은 2~3곳까지 허용한다.
비즈니스 규칙의 중복은 절대 금지: 할인율 계산 공식이 3곳에 존재하면 정책 변경 시 불일치가 발생한다. 이것은 에이전트도 인간도 동일하게 위험하다.

쟁점 3: 기존 아키텍처 (Clean Architecture)¶

Team Alpha의 주장¶

"Clean Architecture를 Feature 기반으로 재구성. 의존성 규칙(Dependency Rule)은 유지하고, 물리적 계층을 축소하면 된다. Feature 기반 구조는 Clean Architecture와 양립 가능하다."

Team Beta의 주장¶

"Clean Architecture 폐기. 인터페이스와 구현체를 분리하는 것 자체가 간접 참조를 강제한다. '클린 아키텍처를 AI에 맞게 조정'한다는 것은 결국 클린 아키텍처를 포기한다는 것과 같다. 차라리 처음부터 새로운 원칙으로 시작하는 것이 솔직하다."

CTO의 최종 판단¶

Feature 기반 구조를 채택하면 실질적으로 비슷해진다. 핵심은 Dependency Rule의 보존 여부다.

물리적 계층 폐지에 동의: Controller -> Service -> Repository -> Entity의 4+ 계층 분리는 폐기한다. Feature 기반 Vertical Slice로 전환.
논리적 의존성 규칙은 보존: Feature 내부에서도 types -> logic -> handler -> store 순서의 의존성 방향을 유지한다. 순수 로직(logic.ts)은 인프라(store.ts)에 의존하지 않는다.
Beta의 핵심 논거를 수용: 인터페이스 파일과 구현체 파일의 물리적 분리는 하지 않는다. 대신 타입 수준의 의존성 주입(type UserStore = { ... })으로 교체 가능성을 확보한다.

결론적으로, 이름은 Clean Architecture가 아니지만 핵심 가치(의존성 방향, 순수 로직 격리)는 보존된다. Beta가 말한 대로 "이것을 Clean Architecture라고 부를 수 있는가?"에 대한 답은 "아니다. 이것은 AIDE다." 하지만 "Clean Architecture의 핵심 통찰을 계승했는가?"에 대한 답은 "그렇다."

쟁점 4: 전환 전략¶

Team Alpha의 주장¶

"점진적 전환. 기존 프로젝트의 수십만 줄 코드와 수백만 개발자의 기존 지식을 무시할 수 없다. 확장/재해석 접근이 채택 장벽을 낮춘다."

Team Beta의 주장¶

"Clean Break. '점진적 전환'은 관성(inertia)의 함정이다. 기존 방식에 익숙한 조직은 전환을 미루게 되고, 그 사이 기존 아키텍처 위에 기술 부채가 쌓인다. 새 프로젝트는 처음부터 AIDE로."

CTO의 최종 판단¶

새 프로젝트와 기존 프로젝트를 구분하면 합의 가능.

새 프로젝트: Beta의 주장대로 Clean Start. 처음부터 AIDE 원칙으로 시작.
기존 프로젝트: Alpha의 주장대로 점진적 마이그레이션. Feature 단위로 AIDE 전환. 새 코드와 수정 코드만 AIDE 적용.

Beta의 "관성의 함정" 경고는 타당하다. 따라서 기존 프로젝트에도 마이그레이션 로드맵과 마일스톤을 명확히 정의해야 한다. "언젠가 전환하겠다"는 것은 "전환하지 않겠다"와 같다.

쟁점 5: 테스트¶

Team Alpha의 주장¶

"TDG(Test-Driven Generation) + PBT + EDD 확장. TDD를 폐기하지 않고 AI 시대에 맞게 확장."

Team Beta의 주장¶

"이중 체계 -- 결정론적 코드에는 Traditional TDD, 확률적 행동에는 EDD. PBT 적극 도입."

CTO의 최종 판단¶

실질적으로 거의 동일한 제안이다. 양팀의 테스트 전략을 통합하여 다음 체계를 확정한다:

결정적 코드 (파서, 정책, 상태 전이, 비즈니스 로직): TDD + PBT
모델 행동 (코드 생성 품질, 프롬프트 변경 영향): EDD (Eval Suites)
시스템 통합 (Feature 간 연동, 데이터 흐름, 외부 서비스 연동): Integration Tests
보안 (AI 생성 코드 보안 취약점, 인증/인가 검증): Security Scenario Tests

PBT의 적극 도입에 양팀 모두 동의하며, "Hard 태스크에서 직접 생성 1.1% vs 속성 검증 48.9%"라는 데이터가 이를 뒷받침한다. 확인 편향 방지를 위해 테스트 작성과 코드 작성에 다른 모델 또는 다른 세션을 사용하는 것을 권장한다.

추가 쟁점: 기존 개발론의 근본적 태도¶

Team Alpha의 핵심 주장¶

"기존 원칙의 핵심 가치는 보편적이다. 단일 책임, 관심사 분리, 의존성 역전, 테스트 가능성 -- 이것들은 인간의 인지 한계 때문만이 아니라 시스템의 복잡성 관리 자체를 위해 존재한다. '목욕물과 함께 아기를 버리지 말라.'"

Chesterton's Fence 논거: 기존 원칙들은 실제 프로젝트의 실패에서 학습한 결과물이다. 울타리를 허물기 전에 왜 세웠는지 이해해야 한다.

Team Beta의 핵심 주장¶

"코드의 주 독자가 바뀌면 최적 코드 구조도 바뀐다. 1960년대 기계 -> 1980년대 인간 -> 2000년대 팀 -> 2025년~ AI 에이전트. 제약이 다르면 최적 해법도 다르다. 뉴턴 역학을 '조정'해서 양자역학을 설명할 수 없다."

METR 데이터 논거: 경험 많은 개발자가 AI와 함께 기존 품질 기준을 유지하면 오히려 19% 느려진다. 기존 개발론의 품질 기준이 AI 워크플로우와 마찰을 일으킨다는 직접적 증거.

CTO의 최종 판단¶

양팀 모두 부분적으로 옳다.

Alpha가 옳은 점: 복잡성 관리, 변경 용이성, 품질 보증이라는 근본 문제는 사라지지 않았다. AI 생성 코드의 45% 보안 결함 데이터가 이를 증명한다. 기존 원칙을 완전히 폐기하면 이 방어선이 무너진다.

Beta가 옳은 점: 제약 조건이 근본적으로 바뀌면 구현 방식도 근본적으로 바뀌어야 한다. 8개 파일 분산, 깊은 상속 트리, 과도한 간접 참조는 "약간의 조정"으로 해결할 수 없는 구조적 문제다. METR의 19% 생산성 하락 데이터는 기존 방식의 마찰을 보여준다.

결론: AIDE는 기존 개발론의 핵심 가치를 보존하되, 구현 방식과 우선순위를 근본적으로 재정렬한다. "진화"라는 표현을 사용하지만, 이것은 "약간의 수정"이 아니라 "같은 종이지만 크게 다른 형태"의 진화다. 물고기에서 양서류로의 진화가 물에서 육지로의 환경 변화에 대한 적응이었듯, AIDE는 인간 중심에서 에이전트 중심으로의 환경 변화에 대한 적응이다.

이 문서는 AIDE v1.0이다. AI 에이전트의 역량이 빠르게 진화하고 있으므로, 이 방법론도 반기 단위로 개정될 것을 권장한다. 컨텍스트 윈도우가 더 커지고, 모델의 추론 능력이 향상되면, 일부 원칙의 구체적 가이드라인(파일 크기 제한, 간접 참조 깊이 등)은 조정될 수 있다. 그러나 핵심 원칙 -- 컨텍스트 예산, 지역성, 함수형 코어, 결정론적 가드레일, 관찰가능성, 구조적 보안 -- 은 에이전트 시대의 불변 가치로 남을 것이다.

← Previous: 06-ADOPTION-GUIDE | Next: INDEX →