유용우 (me@yowu.dev) / 2026.02.26
Don't Repeat Yourself(DRY) 원칙은 수십 년간 소프트웨어 설계의 근본 교리로 기능해 왔다. 그러나 LLM 기반 AI 에이전트가 주요 코드 생성 주체로 부상함에 따라, DRY의 경제적 전제가 역전되는 현상이 관찰된다. 본 논문은 "참조 추적 비용 > 코드 생성 비용"이라는 비용 역전(cost inversion) 현상을 형식적 비용 모델로 논증하고, 이 역전이 특히 외부 의존성 클라이언트 계층에서 의도적 복제(Intentional Duplication for Isolation, IDI)를 경제적으로 정당화하는 조건을 규명한다. 프로덕션 전자상거래 이벤트 애플리케이션 대상 프로젝트(TypeScript/Fastify, 16,800줄, 12개 API 엔드포인트)에 대한 실증 분석을 통해, 4개 클라이언트 유형에 걸친 14개 의도적 복제 인스턴스를 분석하고 비용 모델의 예측과 대조한다. 분석 결과, 복제본 간 공통 스켈레톤 비율은 14-30%이며, 나머지 70-86%는 비즈니스 로직 분기에서 체계적 차이를 보이고 독립적 진화 경로를 따른다. 높은 공통 변경 빈도 환경에서는 DRY가 우월하며, IDI의 적용 조건과 역전환 기준을 함께 제시한다. 본 논문은 IDI 패턴의 형식적 정의, 적용 조건, 경계 조건을 제시하고, DRY와 IDI가 상호 배타적이 아닌 비용 함수의 교차점에 의해 선택되는 연속체(continuum)임을 논증한다.
키워드: 코드 복제, DRY 원칙, 컨텍스트 창, LLM, AI 기반 개발, 소프트웨어 아키텍처, 비용 모델
"Don't Repeat Yourself"(DRY)는 Hunt와 Thomas [1999]가 "The Pragmatic Programmer"에서 제안한 이래 소프트웨어 공학에서 가장 널리 수용된 설계 원칙 중 하나로 자리잡았다. DRY의 핵심 논거는 경제적이다: 동일한 지식이 시스템 내에서 단일 표현(single representation)을 가져야 하며, 그래야만 변경 시 수정 지점이 하나로 한정되어 유지보수 비용이 최소화된다. 이 논거는 코드를 읽고, 기억하고, IDE로 추적하는 인간 개발자에게 최적화되어 있다.
그런데 2023년 이후 소프트웨어 개발 환경에 근본적 변화가 발생했다. GitHub Copilot, Cursor, Claude Code 등 LLM 기반 AI 코딩 에이전트가 코드 생성의 상당 부분을 담당하게 되었다. Stack Overflow [2025] 조사에서 전문 개발자의 50.6%가 AI 코딩 도구를 일일 사용하고 17.4%가 주간 사용 중이며(전문 개발자 기준, Professional Developers 필터 적용; 전체 응답자 기준은 47.1%/17.7%), 더 주목할 점은 파일 단위 자율 수정이 가능한 에이전틱 코딩(agentic coding) 도구의 확산이다. 129,134개 GitHub 프로젝트를 분석한 연구에서 프로젝트 수준 코딩 에이전트 채택률(한 번이라도 사용한 프로젝트의 비율)이 15.85-22.60%로 보고되었으며(이는 프로젝트 내 수정 비중과는 구분된다) [Feng et al., 2025], GitHub Copilot 코딩 에이전트가 2025년 9월 정식 출시되고 [Copilot Agent, 2025], Anthropic [2026]은 개발자가 업무의 60%에서 AI를 활용하되 완전 위임은 0-20%에 불과함을 보고하였다. 이는 현재 파일 단위 자율 수정이 전체 개발 활동의 소수에 머물러 있음을 시사하지만, 에이전틱 코딩의 채택이 급속히 확대되고 있어(GitHub 프로젝트의 16-23%가 이미 코딩 에이전트를 채택 [Feng et al., 2025]) 5.4절에서 논의하듯 IDI의 경제적 이점은 이 비중에 비례하여 점진적으로 증가한다. GitClear [2025]는 211백만 줄의 코드를 분석하여 복제 블록 발생 빈도가 8배 증가하고 리팩토링 비율이 25%에서 10% 미만으로 하락했음을 보고하였으며, 이는 AI 도구가 코드 복제를 체계적으로 증가시키고 있음을 시사한다.
이 현상을 단순히 "AI가 나쁜 코드를 양산한다"로 해석하는 것은 표면적이다. 본 논문은 더 근본적인 질문을 제기한다: DRY 원칙의 경제적 전제 자체가, AI 에이전트의 인지 모델에서는 역전되는 것이 아닌가?
DRY는 암묵적으로 다음의 비용 부등식을 전제한다:
코드 복제의 유지보수 비용 > 참조 추적의 인지 비용
인간 개발자에게 이는 합리적이다. 코드를 수동으로 작성하는 비용이 크므로, 공통 로직을 한 곳에 모아 재사용하는 것이 총 비용을 절감한다. 그러나 AI 에이전트에게는 비용 구조가 근본적으로 다르다:
이 역전이 성립한다면, 특정 조건 하에서 코드를 의도적으로 복제하여 각 모듈을 자기 완결적(self-contained)으로 만드는 것이 AI 에이전트의 코드 생성 품질을 향상시키는 합리적 전략이 된다.
본 논문은 다음의 연구 질문을 다룬다:
본 논문의 기여는 다음과 같다:
본 논문은 DRY 원칙의 폐기를 주장하지 않는다. IDI는 외부 의존성 클라이언트라는 특정 계층에서, AI 에이전트의 코드 수정 비중이 유의미하고, 소비자 간 분기 잠재력이 높은 조건 하에서만 DRY보다 경제적으로 유리하다. 인증 방식 변경처럼 공통 변경이 빈번한 환경에서는 DRY가 명백히 우월하며, 8.4절에서 IDI에서 DRY로의 역전환 기준을 제시한다. 본 논문은 엄밀한 인과적 증명이 아닌, 비용 모델의 이론적 논증과 단일 사례의 탐색적 분석을 결합한 실무 지향적 탐색적 사례연구(practice-oriented exploratory case study)의 성격을 갖는다.
DRY("Don't Repeat Yourself")는 Hunt와 Thomas [1999]에 의해 제안되었으며, 그 핵심 진술은 다음과 같다: "모든 지식 조각은 시스템 내에서 단일의, 모호하지 않은, 권위 있는 표현을 가져야 한다(Every piece of knowledge must have a single, unambiguous, authoritative representation within a system)." 이 원칙은 Yourdon과 Constantine [1979]의 구조적 설계에서 제안된 결합도(coupling)와 응집도(cohesion) 개념에 뿌리를 두고 있으며, 높은 응집도와 낮은 결합도가 유지보수 비용을 절감한다는 경험적 관찰에 기반한다.
DRY의 경제적 논거는 다음과 같이 분해된다:
그러나 DRY에 대한 비판도 축적되어 왔다. Sandi Metz [2016]는 "duplication is far cheaper than the wrong abstraction(복제는 잘못된 추상화보다 훨씬 싸다)"라고 주장하며, 성급한 추상화가 조건부 분기로 오염된 공유 코드를 낳아 오히려 유지보수를 어렵게 만든다고 경고하였다. Kent C. Dodds [2020]는 AHA(Avoid Hasty Abstractions) 원칙을 제안하여, 충분한 사용 패턴이 드러나기 전의 추상화를 경계하였다. 이들의 비판은 인간 개발자 맥락에서도 DRY의 맹목적 적용이 위험함을 보여주지만, AI 에이전트의 인지 모델이라는 새로운 차원은 다루지 않았다.
본 절에서 인용하는 일부 자료는 peer-reviewed 학술 논문이 아닌 산업 리포트 및 기술 보고서를 포함하며, 이들은 대규모 데이터에 기반한 산업적 신호(industry signal)로서 방향성을 지지하지만 엄밀한 인과적 증거로 취급해서는 안 된다. 코드 클론(code clone) 연구는 소프트웨어 공학에서 오랜 역사를 가진다. Roy와 Cordy [2007]는 코드 클론을 네 가지 유형으로 분류하였다: Type-1(정확한 복사), Type-2(이름 변경), Type-3(구조적 변경 포함), Type-4(의미적으로 유사하지만 구문이 다른 경우). 대부분의 선행 연구는 코드 클론을 제거 대상인 "기술 부채(technical debt)"로 취급하며, 탐지와 리팩토링에 초점을 맞추었다 [Juergens et al., 2009; Sajnani et al., 2016].
그러나 일부 연구는 의도적 클론의 존재와 합리성을 인정한다. Kapser와 Godfrey [2008]는 "Cloning Considered Harmful Considered Harmful"에서 코드 클론이 항상 해로운 것은 아니며, 포킹(forking), 템플릿 기반 생성, 독립적 진화를 위한 의도적 복제가 합리적인 엔지니어링 판단일 수 있음을 논증하였다. Kapser와 Godfrey의 분류에서 "forking patterns"은 본 논문의 IDI와 가장 유사하나, AI 에이전트의 컨텍스트 제약이라는 새로운 동기를 다루지 않는다.
산업 분석 리포트인 GitClear [2025]는 AI 코딩 도구 확산에 따른 코드 클론의 양적 변화를 실증한다. 211백만 줄의 코드를 분석한 결과, 복사/붙여넣기(copy/pasted) 코드 비율이 2021년 8.3%에서 2024년 12.3%로 증가했으며, 5줄 이상의 복제 블록 발생 빈도는 8배 증가하여 2년 전 대비 10배 높은 수준에 도달하였다. 동시에 리팩토링과 관련된 코드 변경 비율은 2021년 25%에서 2024년 10% 미만으로 하락했으며, 2024년에는 최초로 복제 코드 비율이 리팩토링 비율을 추월하였다. 이 데이터는 AI 도구가 "생성 후 정리(generate then refactor)" 패턴을 기피하고 복제를 선호하는 경향을 보여주지만, 이것이 품질 저하인지 아니면 새로운 경제 모델 하의 합리적 적응인지를 구분하지 않는다. 본 논문은 바로 이 질문을 다룬다.
LLM의 컨텍스트 창은 인간의 작업 기억(working memory)과 근본적으로 다른 특성을 보인다. Liu 등 [2024]은 LLM이 긴 입력의 중간에 위치한 정보에 대한 성능이 현저히 저하됨을 보였다("Lost in the Middle").
기술 보고서에서 Chroma Research [2025]가 명명한 "컨텍스트 부패(context rot)" 현상은 더 심각한 함의를 갖는다. 18개 LLM을 측정한 결과, 입력 토큰이 증가할수록 모델 성능이 실제로 저하되며, 이는 이론적 컨텍스트 한계와 실효적 성능 임계치 사이에 큰 간극이 존재함을 의미한다.
2025-2026년의 후속 연구들은 이 문제가 단순히 해결되지 않았음을 확인한다. Sequential-NIAH [2025]에서는 128K 토큰 컨텍스트에서 최고 성능 모델의 정확도가 63.5%에 불과했다. LongGenBench [ICLR 2025]는 모든 모델이 장문 생성 태스크에서 길이 증가에 따라 성능이 저하됨을 보였다. 중요하게도, 단순 검색(retrieval) 태스크에서는 성능이 비교적 안정적이지만, 코드 수정처럼 추론(reasoning)이 필요한 복합 태스크에서는 저하가 더 심각하다 [Context Discipline, 2025]. 또한 "lost in the middle" 편향은 트랜스포머의 어텐션 메커니즘과 위치 인코딩이라는 아키텍처적 특성에서 기인하며 [Liu et al., 2024], 모델 규모가 커지더라도 이 구조적 제약이 해소되지 않을 가능성이 있다. 다만 이 연구들은 장문 컨텍스트 성능 저하를 보여줄 뿐, 에이전틱 코드 수정과 도구 연동 IDE 워크플로우를 직접 측정한 것은 아니므로, 코드 아키텍처에 대한 함의는 간접적이다.
이러한 특성은 코드 아키텍처에 직접적 함의를 갖는다. 공유 의존성이 많은 DRY 아키텍처에서, AI 에이전트가 하나의 모듈을 수정하려면:
각 단계가 컨텍스트 창을 소비하며, 단계가 깊어질수록 "lost in the middle" 영역으로 밀려나는 정보가 증가한다.
AI 코드 생성의 품질과 아키텍처의 관계에 대한 연구는 아직 초기 단계이다. Peng 등 [2023]은 GitHub Copilot 사용 시 개발 생산성이 55.8% 향상됨을 보였으나, 생성 코드의 아키텍처적 품질은 다루지 않았다. Apiiro [2025]의 산업 분석에 따르면 AI 코딩 도구 사용 후 아키텍처 설계 결함이 153% 증가하고 권한 상승 경로가 322% 증가하였으며, 단순 구문 오류는 76% 감소한 반면 깊은 아키텍처 결함이 급증하는 비대칭 패턴이 관찰되었다.
마이크로서비스 아키텍처에서의 코드 복제 연구는 본 논문과 구조적 유사성을 갖는다. 마이크로서비스는 서비스 간 독립성을 위해 공유 라이브러리 대신 각 서비스 내에 필요한 로직을 복제하는 전략을 채택하는 경우가 있으며 [Newman, 2015], 이는 Conway의 법칙 [Conway, 1968]과 결합하여 조직 구조와 시스템 구조의 정합성을 달성한다. 본 논문의 IDI 패턴은 이 마이크로서비스 원칙을 AI 에이전트의 컨텍스트 제약이라는 새로운 축으로 확장한다.
본 논문이 기여하는 연구 공백은 명확하다: 기존 연구는 (1) DRY 비판은 인간 인지 맥락에 한정되어 있고, (2) 코드 클론 연구는 클론을 대부분 기술 부채로 취급하며, (3) LLM 컨텍스트 연구는 정보 검색에 초점을 맞추고 코드 아키텍처를 다루지 않는다. 세 흐름을 통합하여 "AI 에이전트의 컨텍스트 제약이 코드 복제를 경제적으로 정당화하는 메커니즘"을 형식화한 연구는 부재하다.
본 연구는 혼합 방법(mixed-method) 접근을 채택한다. 비용 모델의 구축(연역적 이론 형성)과 프로덕션 코드베이스의 실증 분석(귀납적 패턴 도출)을 결합하며, 양자 간 삼각검증(triangulation)을 통해 내적 타당성을 확보한다.
분석 대상인 대상 프로젝트는 대형 전자상거래 플랫폼을 위해 개발된 프로덕션 이벤트 애플리케이션으로, 다음의 특성을 갖는다:
| 속성 | 값 |
|---|---|
| 언어/프레임워크 | TypeScript / Fastify |
| 총 코드 규모 | 16,800줄 (백엔드 8,244줄 + 프론트엔드 8,556줄) |
| API 엔드포인트 수 | 12개 |
| 프론트엔드 페이지 수 | 6개 도메인 |
| 개발 방식 | AI 에이전트(Claude Code) 중심, 인간 감독 |
| 아키텍처 | 엔드포인트별 완전 격리 (디렉토리 = 배포 단위) |
대상 프로젝트는 AI-Native 아키텍처 원칙을 명시적으로 채택한 코드베이스로서, "코드 복제 > 코드 참조"를 설계 원칙의 하나로 선언하고 있다. 이는 IDI 패턴의 의도적 적용을 관찰할 수 있는 이상적 사례를 제공한다.
코드베이스의 모든 클라이언트 파일(*-client.ts)을 추출하여 다음을 분석한다:
공통 스켈레톤 식별 기준: 동일 클라이언트 유형의 모든 복제본에서 공유하는 구문 구조를 공통 스켈레톤으로 정의한다. 구체적으로 (1) import 및 환경변수 로드 패턴, (2) API 응답 인터페이스 정의, (3) mock 분기 구조, (4) fetch 호출 및 HTTP 요청 구성, (5) 에러 처리 프레임워크(try-catch, Result 반환)가 모든 복제본에서 동일한 구문 구조를 보이는 경우 공통 스켈레톤으로 분류한다. 고유 로직은 이 공통 스켈레톤에 해당하지 않는 나머지 코드(프롬프트 내용, 파라미터 설정, 후처리 로직, 타입 정의 등)로 정의한다.
소프트웨어 모듈 m을 수정하는 총 비용을 두 가지 아키텍처 전략에 대해 정의한다.
전략 D (DRY): 공유 모듈 s를 참조하는 N개의 소비자 모듈이 존재하는 구조.
전략 I (IDI): 각 모듈이 필요한 로직의 자체 복사본을 보유하는 구조.
DRY 아키텍처에서 모듈 m_i를 수정하는 총 비용:
C_DRY(m_i) = C_read(m_i) + C_read(s) + C_trace(s, N) + C_modify(m_i) + C_verify(s, N)
여기서:
C_read(m_i): 대상 모듈을 읽어 컨텍스트에 적재하는 비용C_read(s): 공유 모듈 s를 읽는 비용C_trace(s, N): 공유 모듈의 N개 소비자를 식별하고 사이드이펙트를 추론하는 비용C_modify(m_i): 실제 코드 수정 비용 (코드 작성, 테스트, 리뷰를 포함하는 생산 비용)C_verify(s, N): 수정이 다른 소비자에 영향을 주지 않는지 검증하는 비용핵심: C_trace(s, N)이 컨텍스트 창 크기 W에 의해 제약된다. 추적에 필요한 총 토큰이 W를 초과하면, AI 에이전트는 다중 턴(multi-turn)으로 분할해야 하며, 이전 턴의 정보가 손실되어 추적 품질이 급격히 저하된다.
참조 추적 비용을 더 상세히 전개한다:
C_trace(s, N) = N * C_read_consumer + C_impact_analysis(N)
여기서 C_impact_analysis(N)은 N개 소비자의 사용 패턴을 종합하여 사이드이펙트를 추론하는 비용이며, 컨텍스트 내에 동시에 적재해야 하는 정보량에 비례한다.
실무 에이전트는 IDE 인덱싱, repo map, semantic search, MCP 등 도구로 C_trace의 탐색 비용 부분을 줄인다. 이를 반영하여 C_trace_eff = C_trace_raw × (1 - η)로 표기한다. 여기서 η는 도구 지원에 의한 개념적 감쇄 항이며, 본 논문에서는 η의 구체적 값을 추정하지 않는다. 핵심은 서술이다: 도구는 **찾기 비용(C_read_consumer의 탐색 부분)**을 줄이지만, **영향 분석 비용(C_impact_analysis)**을 없애지 않는다. IDE의 semantic search나 repo map은 '이 공유 모듈을 누가 사용하는가?'라는 발견 문제를 효율화하지만, '이 변경이 소비자 A의 에러 처리 분기에 어떤 사이드이펙트를 유발하는가?'라는 추론 문제는 여전히 컨텍스트 내에서 수행되어야 한다. 따라서 tool-assisted retrieval은 비용 교차점을 이동시키되 소멸시키지 않으며, 특히 C_impact_analysis(N)의 비선형 증가는 도구 지원 하에서도 지속된다.
중요하게도, C_impact_analysis(N)은 컨텍스트 창 크기 W에 대해 비선형적으로 증가한다. 왜냐하면:
이를 반영한 열화 함수(degradation function)를 도입한다:
D(tokens_used, W) = 1 + alpha * max(0, tokens_used / W - theta)^beta
여기서 alpha는 열화 강도, theta는 열화 시작 임계치(경험적으로 0.3-0.5), beta는 열화 곡선의 형상을 결정한다. 이 theta 추정치는 주로 정보 검색 태스크에서 측정된 것이며, 코드 수정과 같은 추론 태스크에서는 열화가 더 일찍 시작될 것으로 예측되므로(2.3절), 본 논문의 실무적 임계치(N>=4, 200줄)는 보수적 추정이다. 비용 모델의 핵심 결론(비용 교차점의 존재)은 beta의 구체적 값이 아니라 단조 증가 + 임계점 이후 급격한 상승이라는 정성적 특성에 의존하며, Chroma Research [2025]의 성능 저하 곡선이 이를 지지한다.
따라서 열화를 반영한 DRY 비용:
C_DRY_eff(m_i) = D(T_total, W) * C_DRY(m_i)
여기서 T_total은 수정에 필요한 총 토큰 수이다.
IDI 아키텍처에서 모듈 m_i를 수정하는 총 비용:
C_IDI(m_i) = C_read(m_i) + C_modify(m_i) + C_dup_maintain(K)
여기서:
C_read(m_i): 자기 완결적 모듈을 읽는 비용 (공유 의존성 추적 불필요)C_modify(m_i): 코드 수정 비용C_dup_maintain(K): K개 복제본의 장기 유지보수 비용 (외부 API 스펙 변경 시 K개 파일 수정). 이를 더 분해하면 C_dup_maintain(K) = C_discover(K) + K * C_apply이다. C_discover(K)는 "어떤 파일을 수정해야 하는가?"의 발견 비용이고, K * C_apply는 K개 파일을 실제로 수정하는 실행 비용이다. 8.3절의 contracts/ 패턴은 usedBy 메타데이터로 C_discover를 O(1)의 선언적 조회로 대체하지만, 이는 메타데이터 자체의 유지보수 비용 C_metadata_maintain(새 엔드포인트 추가 시 갱신, 삭제 시 제거, 코드와의 동기화 검증)을 전제한다. 8.3절에서 논의하는 CI 자동 검증이 이 비용을 최소화하며, 선언적 메타데이터의 유지보수가 코드 grep 기반 탐색보다 비용이 낮으므로, IDI의 유지보수 비용에서 가장 큰 불확실성을 실질적으로 완화한다.IDI의 핵심 이점은 C_trace 항이 완전히 제거된다는 것이다. 모듈이 자기 완결적이므로, 해당 디렉토리만 읽으면 수정에 필요한 모든 컨텍스트를 확보한다. 컨텍스트 사용량이 항상 theta * W 이하로 유지되므로 열화 함수가 활성화되지 않는다.
본 절의 비용 비교 모델은 동반 연구 [T1]에서 제안된 AI-Native 아키텍처 설계 원칙의 경제적 근거를 형식화한다. IDI가 DRY보다 경제적으로 우월한 조건:
C_IDI(m_i) < C_DRY_eff(m_i)
이를 전개하면:
C_dup_maintain(K) < D(T_total, W) * [C_read(s) + C_trace(s, N) + C_verify(s, N)]
좌변은 복제 유지보수 비용, 우변은 참조 추적 비용(열화 포함)이다.
비용 교차점에 영향을 미치는 핵심 변수:
| 변수 | IDI 유리 방향 | DRY 유리 방향 |
|---|---|---|
컨텍스트 창 크기 W |
W 작을수록 |
W 클수록 |
소비자 수 N |
N 클수록 |
N 작을수록 |
| 공유 모듈 크기 | 클수록 | 작을수록 |
| 변경 빈도 | 비즈니스 로직 독립 변경 빈번 | 공통 인프라 변경 빈번 |
복제본 수 K |
K 작을수록 |
K 클수록 |
| 복제본 간 분기 정도 | 분기 클수록 | 분기 작을수록 |
| 도구 지원 수준 (η) | 도구 미성숙 | 도구 고도화 (semantic index, 의존성 그래프) |
실무적 임계치(Rule of Thumb): 비용 모델의 파라미터를 정밀하게 추정하지 않더라도, 기존 연구에서 보고된 컨텍스트 열화 데이터로부터 실무적 판단 기준을 도출할 수 있다. Chroma Research [2025]는 컨텍스트 사용률이 30-50%를 초과하면 성능 저하가 시작됨을 보였고, Sequential-NIAH [2025]는 128K 토큰에서 최고 모델 정확도가 63.5%에 불과함을 보였다. 이로부터 다음의 경험적 판단 기준을 제안한다:
이 임계치는 대상 프로젝트의 관찰과 부합한다: model-client.ts는 N=6, 공유 모듈 가상 크기 약 250줄, 5개 차원의 분기를 보이며, 세 기준 모두를 충족한다.
생명주기 비용 확장: 위 비용 모델은 "단일 수정 비용"을 비교하지만, 현업의 아키텍처 의사결정은 프로젝트 생명주기 전체의 누적 비용으로 이루어진다. 이를 반영하여 생명주기 총 비용을 다음과 같이 확장한다:
Total_IDI = n_A * C_IDI_A + n_B * C_IDI_B
Total_DRY = n_A * C_DRY_A + n_B * C_DRY_B
여기서 n_A는 생명주기 동안 발생하는 독립 변경(비즈니스 로직 수정) 횟수, n_B는 공통 변경(외부 API 스펙 변경, 인증 방식 변경 등) 횟수이다. 공통 변경 비율 r_B = n_B / (n_A + n_B)가 핵심 변수로, 이 비율이 높을수록 DRY가 유리하고, 낮을수록 IDI가 유리하다. 구체적으로 C_IDI_B는 K개 파일을 개별 수정해야 하므로 C_DRY_B의 대략 K배 수준이지만, contracts/의 usedBy에 의해 발견 비용이 제거되고 각 수정이 동일 패턴의 단순 치환이므로 순수 K배보다는 낮다. 반면 C_IDI_A는 컨텍스트 열화가 없으므로 C_DRY_eff_A보다 현저히 낮다. 따라서 r_B가 높을수록 IDI의 공통 변경 비용 불이익이 누적되어 DRY가 유리해지며, 이것이 생명주기 비용 수식의 핵심 역학이다.
프로젝트 생명주기 단계에 따라 r_B는 체계적으로 변화한다. 신규 개발 단계(1-2년차)에서는 기능 추가와 비즈니스 로직 변경이 지배적이므로 r_B가 낮다. 유지보수 단계(3년차 이후)에서는 외부 의존성 업그레이드, 보안 패치, API 마이그레이션 등 공통 변경의 비율이 증가하여 r_B가 상승한다. 소프트웨어 생명주기 비용의 60-80%가 유지보수 단계에서 발생한다는, 산업계에서 널리 인용되는 추정치를 고려하면, IDI 채택 시 유지보수 단계의 r_B 증가에 대한 대비가 필수적이다. 이 대비의 핵심 메커니즘이 8.3절의 contracts/ 패턴과 차별적 전파 정책이다.
대상 프로젝트의 경우, 7.2절의 데이터에서 26회 수정이 모두 독립 변경(유형 A)이고 공통 변경(유형 B)이 0건인 것은 신규 개발 단계의 특성을 반영한다. 유지보수 단계에서 r_B가 증가하면 IDI의 경제적 우위가 축소될 수 있으며, 이때 8.4절의 의사결정 프레임워크에 따라 DRY로의 역전환을 검토해야 한다.
대상 프로젝트의 model-client.ts를 예로 들어 두 전략의 비용을 비교한다.
시나리오: "카테고리 분류 API의 LLM 프롬프트를 수정하라"
DRY 전략 (가상의 공유 LlmClient 클래스가 존재한다고 가정):
POST_ai_classify-category/service.ts 읽기 -- 해당 API 로직 파악shared/model-client.ts 읽기 -- 공유 LLM 클라이언트 이해이 과정에서 AI 에이전트는 최소 7개 파일을 읽어야 하며, "이 변경이 추천 API의 키워드 추출에 영향을 주지 않는가?" 같은 간접적 사이드이펙트를 추론해야 한다.
IDI 전략 (대상 프로젝트의 실제 구조):
POST_ai_classify-category/model-client.ts 읽기 (104줄) -- 이 API 전용 클라이언트필요한 컨텍스트: 1개 파일, 104줄. 사이드이펙트 추론: 불필요 (영향 범위 = 1 디렉토리).
시나리오 B: IDI 불리 케이스 -- "LLM API 인증 방식 변경"
외부 LLM API의 인증 방식이 Bearer 토큰에서 OAuth2로 변경되어, 모든 model-client.ts의 인증 헤더를 수정해야 하는 상황을 가정한다.
IDI 전략 (대상 프로젝트의 실제 구조): contracts/externals/llm-api/spec.ts의 usedBy 배열을 조회하면 6개 소비자 목록이 즉시 확인된다. 각 파일의 Authorization: Bearer ${API_KEY} 부분을 개별 수정해야 하므로 6회의 수정이 필요하다. 그러나 각 수정은 동일한 패턴의 단순 치환이며, AI 에이전트가 1개 파일을 수정한 후 나머지 5개에 동일 패턴을 적용하면 되므로 실제 인지 비용은 낮다.
DRY 전략: shared/model-client.ts 1개 파일의 인증 로직만 수정하면 완료. 수정 횟수 1회.
이 시나리오에서는 DRY가 명백히 유리하다. IDI의 비용은 K에 비례하며, K가 클수록 불리해진다. 이것이 5.5절에서 "높은 공통 변경 빈도" 환경을 IDI의 경계 조건으로 명시한 이유이다. 다만 대상 프로젝트는 인증 정보를 kernel/env.ts에서 환경변수로 관리하므로, 실제로는 이 시나리오의 영향이 완화된다. 또한 contracts/의 usedBy 메타데이터가 "수정 대상 파일 탐색"을 O(1)으로 만들어, IDI의 전파 비용에서 가장 큰 비중을 차지하는 "어디를 수정해야 하는가?"의 탐색 비용을 제거한다.
"컨텍스트 창이 무한히 커지면 이 모델은 무의미해지지 않는가?"라는 반론이 가능하다. 이에 대한 답변은 세 가지이다.
첫째, 실효 성능 임계치와 이론적 최대치의 간극이 지속적으로 관찰된다. NVIDIA의 RULER 벤치마크에서 대부분의 모델이 단순 NIAH는 통과하지만 복합 태스크에서는 시퀀스 길이 증가에 따라 큰 성능 저하를 보인다. LongGenBench [ICLR 2025]는 장문 생성에서 모든 모델이 실패함을 보고하며, 이는 NIAH 같은 벤치마크가 실무 태스크의 난이도를 과소평가하고 있음을 시사한다.
둘째, 비용 모델의 핵심은 절대적 크기가 아니라 비율이다. GitClear [2025]에 따르면 AI 도구 확산 이후 코드 추가량이 2020년 39.2%에서 2024년 46.2%로 증가하고 코드 이탈률(churn)이 연 26% 상승하고 있어, 소프트웨어 프로젝트 규모의 성장이 가속화되고 있다. "프로젝트 전체 / 컨텍스트 창" 비율은 컨텍스트 창이 커져도 일정하게 유지될 가능성이 높다.
셋째, "lost in the middle"은 아키텍처적 문제이다. 이 편향은 트랜스포머의 어텐션 메커니즘과 위치 인코딩에서 기인하며 [Liu et al., 2024], 모델 규모 확대만으로는 해소되지 않는 구조적 제약이다. 이를 해결하려면 관련 정보의 물리적 인접성(physical locality)을 높여야 하며, 이것이 바로 IDI의 핵심 메커니즘이다. 에이전틱 도구(Claude Code의 CLAUDE.md, Cursor의 .cursorrules 등)가 프로젝트 수준 컨텍스트를 주입하고, MCP 등의 프로토콜로 외부 도구가 구조적 컨텍스트를 제공하는 방향은 참조 추적 비용을 부분적으로 완화할 수 있다. 그러나 이러한 메타데이터 기반 컨텍스트 주입이 'N개 소비자의 사이드이펙트 추론'이라는 복합 추론 태스크를 해소하는지는 별도 검증이 필요하며, 현재까지의 벤치마크(Sequential-NIAH, LongGenBench)는 이 수준의 복합 추론에서 성능 저하가 지속됨을 보고하고 있다.
**의도적 복제(Intentional Duplication for Isolation, IDI)**를 다음과 같이 정의한다:
외부 의존성(외부 API, 데이터 소스 등)에 대한 클라이언트 코드를, 공유 모듈 대신 각 소비자 모듈 내에 독립 복사본으로 유지하는 아키텍처 패턴. 각 복사본은 해당 소비자의 비즈니스 컨텍스트에 특화되어 독립적으로 진화하며, 이를 통해 모듈 간 결합을 제거하고 변경 영향 범위를 단일 모듈로 한정한다.
IDI는 Roy와 Cordy [2007]의 분류에서 Type-3 클론(문장의 추가, 삭제, 수정을 포함하는 구조적 변경)에 해당하며, Kapser와 Godfrey [2008]의 분류에서는 forking pattern의 변종이다.
IDI 인스턴스는 다음의 구조를 갖는다:
공통 기반(Common Skeleton): 모든 복제본이 공유하는 구조적 패턴
분기 지점(Divergence Points): 각 복제본이 비즈니스 컨텍스트에 따라 독립적으로 특화하는 부분
격리 경계(Isolation Boundary): 복제본이 위치하는 디렉토리 = 변경 영향 범위
IDI 패턴이 유효하려면 다음의 불변 조건이 유지되어야 한다. 이 불변 조건들은 AI-Native 아키텍처의 영향 범위 최소화 원칙 및 의도적 복제 설계 원칙 [T1]을 형식화한 것이다:
I1. 자기 완결성(Self-Containment): 각 복제본은 외부 모듈의 import 없이 독립적으로 컴파일 및 실행 가능해야 한다. kernel(프레임워크 코어)에 대한 의존은 허용하되, 다른 비즈니스 모듈에 대한 의존은 금지한다.
I2. 독립 진화(Independent Evolution): 한 복제본의 수정이 다른 복제본에 영향을 미치지 않아야 한다. 이는 "Blast Radius = 1 Directory" 원칙의 직접적 구현이다.
I3. 분기의 비즈니스 정당성(Business Justification of Divergence): 복제본 간 차이가 비즈니스 요구의 차이에서 기인해야 한다. 단순히 "복사하고 잊어버린" 것이 아니라, 각 복제본이 고유한 비즈니스 목적에 부합하는 특화를 보유해야 한다. 검증 가능한 프록시 지표로서, 복제본 간 diff에서 비즈니스 도메인 특화 토큰(프롬프트 텍스트, 도메인 상수, 타입 이름, 파라미터 값)이 전체 차이의 50% 이상을 차지하면 I3 충족으로 판정할 수 있다.
IDI가 DRY보다 경제적으로 우월한 충분 조건:
높은 분기 잠재력: 동일 외부 API를 호출하더라도, 각 소비자가 다른 프롬프트, 파라미터, 에러 처리 정책을 요구하는 경우. 이는 공유 모듈이 조건부 분기로 오염될 가능성이 높음을 의미한다.
독립적 진화 패턴: 각 소비자의 비즈니스 로직이 다른 소비자와 독립적으로 변경되는 경우. 하나의 API에 대한 타임아웃 정책 변경이 다른 API에 영향을 미쳐서는 안 되는 경우.
AI 에이전트의 유의미한 활용: 코드 생성 및 수정에서 AI 에이전트의 비중이 유의미한 수준(약 50% 이상)이며, 컨텍스트 격리가 코드 생성 품질에 직접적 영향을 미치는 경우. 에이전틱 코딩의 비중이 증가할수록 IDI의 경제적 이점은 점진적으로 증가한다. 현재 산업 데이터에 따르면 GitHub 프로젝트의 약 16-23%가 코딩 에이전트를 채택하고 있으며 [Feng et al., 2025], 이 비율은 급속히 증가 추세에 있다.
관리 가능한 복제본 수: 복제본 수 K가 외부 API 스펙 변경 시 수동 전파의 비용이 감내 가능한 수준인 경우.
높은 공통 변경 빈도: 외부 API의 인증 방식, 기본 URL, 공통 헤더가 빈번히 변경되는 경우. 이때는 K개 파일을 모두 수정해야 하므로 DRY가 유리하다. (단, 대상 프로젝트는 이를 kernel/env.ts의 환경 설정으로 분리하여 완화한다.)
순수 보일러플레이트: 비즈니스 로직이 전혀 없는 순수 인프라 코드(HTTP 클라이언트 래퍼 등)는 복제 대신 공유가 합리적이다. 대상 프로젝트에서도 kernel/의 공통 타입(Result, AppError)은 공유한다.
극히 많은 복제본: K가 수십 개를 초과하면, 외부 API 스펙 변경 시의 전파 비용이 참조 추적 비용을 상회할 수 있다.
낮은 AI 에이전트 활용 비중: AI 에이전트의 코드 수정 비중이 30% 미만인 환경에서는 DRY의 원래 경제적 논거가 유효하다.
대상 프로젝트 코드베이스에서 4개 외부 API 클라이언트 유형에 걸쳐 14개 의도적 복제 인스턴스를 식별하였다:
동일한 LLM API(Qwen3-235B, 이하 LLM-A)를 호출하지만, 각각 다른 비즈니스 목적을 수행하는 6개 복제본:
| 엔드포인트 | 줄 수 | 비즈니스 목적 | max_tokens | 고유 로직 |
|---|---|---|---|---|
| POST_ai_classify-category | 104 | 카테고리 분류 | 50 | 2줄 파싱 (한글/영문 쌍) |
| POST_ai_generate-scene-prompt | 152 | 장면 이미지 프롬프트 생성 | 400 | 서비스 특화 프롬프트, category/layout 옵션 |
| POST_ai_generate-scene-image | 125 | 이미지 생성 프롬프트 생성 | 2048 | VLM 분석 결과 결합, 한글 시스템 프롬프트 |
| POST_avatar_generate | 140 | 아바타 프롬프트 생성 | 256 | /no_think 지시어, LABEL/DESC 파싱, 유형 입력 |
| POST_resource-allocation | 86 | 리소스 배정 | 10 | 9개 슬롯 유효성 검증, fallback 전략, AbortController 타임아웃 |
| POST_recommend_items | 106 | 키워드 추출 | 500 | 범용 callLlm 인터페이스, AbortController 타임아웃 |
구조적 유사도 분석: 6개 복제본 모두 동일한 패턴(환경변수 로드 -> mock 분기 -> fetch 호출 -> 응답 파싱 -> Result 반환)을 공유하며, 이 공통 스켈레톤은 35줄(평균 119줄 대비 29.4%)이다. 그러나 비즈니스 분기 지점에서 체계적 차이를 보인다:
분기 차원 1: 프롬프트 내용 및 구조
카테고리 분류는 2줄짜리 단순 출력을 요구하는 반면, 장면 프롬프트 생성은 7문장 120단어 제한의 서비스 특화 프롬프트를 사용하며, 아바타 생성은 LABEL/DESC 포맷의 구조화된 출력을 파싱한다. 각 프롬프트는 해당 비즈니스 도메인의 요구에 밀접하게 결합되어 있다.
분기 차원 2: 토큰 예산
max_tokens 설정이 10(리소스 배정)에서 2048(이미지 프롬프트)까지 40배 이상 차이를 보인다. 이는 각 용도의 출력 복잡도를 정확히 반영한다. 공유 클라이언트에서 이를 파라미터화하면, 잘못된 토큰 예산 설정으로 인한 비용 낭비나 출력 절단(truncation) 위험이 발생한다.
분기 차원 3: 에러 처리 및 Fallback 전략
리소스 배정(POST_resource-allocation)은 LLM 실패 시 "기본값(DEFAULT)"으로 graceful fallback하여 저장 흐름을 차단하지 않는다. 반면 이미지 프롬프트 생성(POST_ai_generate-scene-image)은 LLM 실패 시 502 에러를 반환한다. 이는 각 API의 비즈니스 중요도와 대체 가능성이 다르기 때문이다.
분기 차원 4: 응답 후처리
아바타 생성은 parseLlmOutput() 함수로 LABEL/DESC 형식을 파싱하고, <think> 태그를 제거하는 전용 후처리 로직을 갖는다. 카테고리 분류는 줄바꿈 기반 단순 파싱을, 리소스 배정은 유효 슬롯 코드 목록 대조 검증을 수행한다. 이러한 후처리 로직은 공유 모듈에서 조건부 분기 없이는 표현할 수 없다.
분기 차원 5: 입출력 타입
각 복제본은 자체 TypeScript 인터페이스를 정의한다: CategoryClassificationResult, LlmGenerationResult(text + tokensUsed), LlmGenerationResult(category + description + tokensUsed), SlotCode, LlmKeywordResult. 반환 타입의 구조가 완전히 다르므로, 공유 인터페이스는 any나 제네릭 유니온으로 퇴화하여 타입 안전성을 훼손한다.
| 엔드포인트 | 줄 수 | 비즈니스 목적 | 고유 로직 |
|---|---|---|---|
| POST_ai_generate-scene-image | 117 | 장면 이미지 (가변 비율) | aspectRatio 옵션, Ultra HD, 4K 접미사, 가변 해상도 |
| POST_ai_generate-composite-image | 126 | 합성 이미지 (text-to-image) | raw response 로깅, b64_json 대체 경로, JSON 파싱 에러 처리 |
| POST_avatar_generate | 113 | 아바타 이미지 (1:1 고정) | 3분 타임아웃, 고정 해상도 1664x928, raw response 로깅 |
핵심 분기: 동일 이미지 생성 API를 호출하지만, 장면 이미지는 가변 해상도(16:9, 1:1 등)와 Ultra HD, 4K 품질 지시어를 사용하는 반면, 아바타 이미지는 고정 1664x928 해상도와 3분 타임아웃(기본보다 훨씬 긴)을 사용한다. POST_ai_generate-composite-image와 POST_avatar_generate는 운영 중 발견된 문제에 대응하여 raw response 로깅과 b64_json fallback 처리를 추가했으나, POST_ai_generate-scene-image에는 이 로직이 없다. 이 현상은 양면적 해석이 필요하다. 독립 진화의 관점에서는, 각 복제본이 자신의 운영 맥락에서 필요한 강건성만을 축적하는 자연스러운 특화이다. 부분 전파의 위험 관점에서는, 동일한 외부 API를 호출하는 3개 클라이언트 중 2개에만 에러 처리가 보강되어, 나머지 1개에서 동일 장애가 발생할 잠재적 위험이 존재한다. 이 긴장은 IDI의 "독립 진화" 가치와 "알려진 위험의 전파" 가치 사이의 구조적 트레이드오프를 보여주며, 8.3절에서 이를 완화하는 차별적 전파 정책을 제안한다.
| 엔드포인트 | 줄 수 | 비즈니스 목적 | 고유 로직 |
|---|---|---|---|
| POST_ai_analyze-product-design | 131 | 상품 디자인 분석 | stripToPlainSentences() 후처리, 마크다운 제거, 200 max_tokens |
| POST_ai_generate-scene-image | 101 | 이미지 생성용 상품 분석 | 이미지 재현 프롬프트, 1024 max_tokens |
| POST_avatar_generate | 114 | 아바타 스타일링용 분석 | 아바타 디자인 요소 추출, 색상/패턴/소재 초점, 512 max_tokens |
핵심 분기: 세 복제본 모두 동일한 VLM(Qwen2.5-VL-32B-Instruct, 이하 VLM-B)을 호출하지만, 프롬프트의 방향이 완전히 다르다. 상품 디자인 분석은 "색상과 형태를 객관적으로 기술하라"는 최소주의 프롬프트를 사용하며, VLM이 생성하는 마크다운 에세이를 정규식으로 제거하는 전용 후처리 함수 stripToPlainSentences()를 보유한다. 이미지 생성용 분석은 "이 제품을 정확히 재현할 수 있는 프롬프트를 작성하라"는 상세 묘사를 요구하며, 아바타 스타일링용 분석은 "아바타 의상에 영감을 줄 디자인 요소를 추출하라"는 특화된 지시를 사용한다. 세 복제본의 max_tokens가 200, 512, 1024로 각각 다르며, 이는 출력의 기대 길이 차이를 반영한다.
| 엔드포인트 | 줄 수 | 비즈니스 목적 | 고유 로직 |
|---|---|---|---|
| GET_product_ | 132 | 단일 상품 조회 | 전체 ProductItem 타입 (81개 필드), 단건 응답 |
| POST_recommend_items | 117 | 추천용 배치 조회 | 축약 ProductItem 타입 (12개 필드), 배치 API, 20개씩 청크 분할 |
핵심 분기: 동일 외부 상품 카탈로그 API를 호출하지만, 단일 조회와 배치 조회라는 근본적으로 다른 호출 패턴을 사용한다. 더 주목할 점은 타입 정의의 의도적 차별화이다: 단일 상품 조회는 81개 필드를 가진 완전한 ProductItem 타입을 정의하여 상세 정보 표시에 활용하는 반면, 추천 배치 조회는 12개 핵심 필드만 포함하는 축약 타입을 정의한다. 이는 각 API가 필요로 하는 데이터의 범위가 다르기 때문이며, 공유 타입을 사용하면 추천 API가 불필요한 81개 필드를 모두 알아야 하거나, 상품 상세 API가 축약 타입으로 인해 필요한 필드를 잃게 된다.
14개 인스턴스의 분기 지점을 I3(분기의 비즈니스 정당성) 검증을 위해 원인별로 분류한다:
| 분기 원인 | 해당 분기 지점 | 인스턴스 수 |
|---|---|---|
| 비즈니스 요구 | 프롬프트 내용/구조, max_tokens, 전용 타입 정의, 해상도/비율, 후처리 로직, fallback 전략 | 14/14 (전수) |
| 운영 대응 | raw response 로깅, b64_json fallback, JSON 파싱 에러 처리 | 2/14 (image-client의 composite-image, avatar_generate) |
비즈니스 요구 분기는 모든 인스턴스에서 관찰되며, 이는 I3의 "비즈니스 도메인 특화 토큰이 차이의 50% 이상"이라는 기준을 충족한다. 운영 대응 분기는 image-client 유형의 2개 인스턴스에 집중되어 있으며, 이는 비즈니스 요구가 아닌 운영 사고 대응에서 발생한 우연적 분기(accidental divergence)에 해당한다. 이러한 운영 대응 분기에 대해서는 8.3절의 차별적 전파 정책 -- 안전 관련 수정은 모든 복제본에 전파 -- 이 적용되어야 한다.
| 클라이언트 유형 | 인스턴스 수 | 총 줄 수 | 평균 줄 수 | 공통 스켈레톤 (줄/비율) | 고유 로직 비율 |
|---|---|---|---|---|---|
| model-client | 6 | 713 | 119 | 35줄 / 29.4% | 70.6% |
| image-client | 3 | 356 | 119 | 36줄 / 30.3% | 69.7% |
| vlm-client | 3 | 346 | 115 | 35줄 / 30.4% | 69.6% |
| catalog-client | 2 | 249 | 125 | 18줄 / 14.4% | 85.6% |
| 전체 | 14 | 1,664 | 119 | 평균 27.6% | 72.4% |
catalog-client를 제외한 3개 유형의 고유 로직 비율이 약 70%에 수렴하는 것은, 외부 API HTTP 클라이언트의 구조적 특성 -- 인증, 요청 구성, 응답 파싱이라는 공통 보일러플레이트가 약 30%를 차지 -- 에서 기인하는 것으로 추정된다. catalog-client(85.6%)는 단건 조회와 배치 조회라는 근본적으로 다른 호출 패턴으로 인해 공통 스켈레톤이 작아 돌출된다.
전체 코드베이스(백엔드 8,244줄) 대비 복제 코드는 1,664줄(20.2%)이다. 이 중 공통 스켈레톤(약 460줄, 평균 27.6%)이 "순수 중복"에 해당하고, 나머지 1,204줄(72.4%)은 각 비즈니스 컨텍스트에 특화된 고유 로직이다. 즉, **표면적 중복률은 20.2%이지만, 공통 스켈레톤에 해당하는 구조적 중복률은 약 5.6%**에 불과하다. 다만 이 5.6%도 공유 모듈 추출 시 완전히 제거되는 것은 아니다: import 구문과 설정 파라미터 전달 코드(추정 10-15줄)가 추가되므로 실제 절감량은 이보다 작다.
공통 스켈레톤의 구체적 구성 (model-client.ts 6개 복제본 기준): 35줄의 공통 스켈레톤은 (1) Contract 주석 및 kernel import 2줄, (2) 환경변수 상수 정의(BASE_URL, API_KEY, MODEL, USE_MOCK) 4줄, (3) ChatCompletionResponse 인터페이스 정의 8줄, (4) fetch 호출 및 HTTP 요청 구성(method, headers, Authorization, body) 8줄, (5) 에러 처리 프레임워크(response.ok 검증, content null 검증, catch 블록) 10줄, (6) Result 반환 패턴 3줄로 구성된다. 이들은 변수명과 구문 구조가 모든 복제본에서 문자적으로 동일한 Roy-Cordy Type-1 클론(정확한 복사)에 해당한다. 나머지 72.4%의 고유 로직(프롬프트 내용, 파라미터 설정, 후처리 함수, 타입 정의)은 복제본마다 완전히 다르므로 클론으로 분류되지 않는다.
대상 프로젝트의 코드베이스 구성을 비용 모델의 관점에서 계층별로 분석한다.
| 계층 | 줄 수 | 전체 비율 | 조직화 전략 | 근거 |
|---|---|---|---|---|
| kernel/ (백엔드) | 524 | 6.4% | 공유 (DRY) | 변경 빈도 극히 낮음, 분기 잠재력 0 |
| kernel/ (프론트엔드) | 125 | 1.5% | 공유 (DRY) | 위와 동일 |
| contracts/ | 244 | 3.0% | 공유 (메타데이터) | 실행 코드 아님, 역추적 용도 |
| api/ 클라이언트 복제본 | 1,664 | 20.2% | IDI | 높은 분기 잠재력, 독립 진화 |
| api/ 나머지 (spec, handler, service 등) | 5,812 | 70.5% | 격리 (고유 로직) | 엔드포인트별 고유 비즈니스 로직 |
| 프론트엔드 pages/ | ~8,431 | -- | 격리 | 페이지별 독립 |
이 분포는 비용 모델의 핵심 예측을 지지한다: 분기 잠재력이 높은 외부 API 클라이언트에서만 IDI가 채택되고, 분기 잠재력이 0인 인프라 계층에서는 DRY가 유지된다. "모든 것을 복제한다"가 아니라 "비용 교차점을 넘는 모듈만 복제한다"는 선택적 전략이 관찰된다.
특히 주목할 점은 api/ 내부의 **비클라이언트 파일(spec.ts, handler.ts, service.ts, repository.ts)**은 복제가 아니라 고유 로직이라는 사실이다. 이들은 각 엔드포인트의 비즈니스 로직 그 자체이므로 "복제"라는 개념이 적용되지 않는다. IDI는 외부 의존성 클라이언트라는 특정 범주에서만 작동하며, 이는 패턴의 적용 범위를 정밀하게 한정한다.
컨텍스트 예산 분석: 12개 API 엔드포인트의 평균 크기는 약 580줄(spec.ts + handler.ts + service.ts + 클라이언트 파일 합산)이다. 이는 약 2,300토큰에 해당하며, 8K 토큰 컨텍스트 창의 28%, 200K 토큰 창의 1.2%만 소비한다. 반면 DRY 아키텍처에서 동일 수정을 위해 공유 모듈 + 소비자 목록 + 사이드이펙트 분석에 필요한 컨텍스트는 최소 6개 파일(약 700줄, 2,800토큰 추가)이 요구되어, 8K 창에서는 총 63%를 소비하게 된다. 이는 열화 임계치(theta = 0.3-0.5)를 초과하여 "lost in the middle" 효과가 활성화되는 영역이다.
대상 프로젝트의 실제 아키텍처와 비용 모델의 예측을 대조한다.
예측 1: IDI가 유리한 조건(높은 분기 잠재력 + 독립 진화 + AI 중심 개발)이 충족되는 곳에서 IDI가 채택될 것이다.
관찰: 4개 클라이언트 유형 모두에서 IDI가 채택되었다. 모든 인스턴스가 높은 분기 잠재력(프롬프트, 타임아웃, 에러 처리, 타입이 모두 다름)과 독립 진화 패턴(운영 중 발견된 이슈의 개별 수정)을 보인다. AI 에이전트 중심 개발 환경이다. 예측과 일치.
예측 2: 공통 인프라(환경변수, 기본 타입)는 IDI 대신 공유될 것이다.
관찰: kernel/types.ts의 Result, AppError 타입과 kernel/env.ts의 환경변수는 모든 API에서 공유된다. 이는 비용 모델에서 "비즈니스 로직이 전혀 없는 순수 인프라"에 해당하며, 분기 잠재력이 0이므로 IDI의 이점이 없다. 예측과 일치.
예측 3: 복제본 간 구조적 유사도가 높더라도, 분기 지점의 비즈니스 정당성이 있으면 IDI가 유지될 것이다.
관찰: model-client.ts 6개 복제본의 공통 스켈레톤 비율은 29.4%이고, 나머지 70.6%의 분기 지점(프롬프트, 토큰 예산, 에러 처리, 후처리, 타입)이 각각 명확한 비즈니스 정당성을 갖는다. "카테고리 분류에 2048 토큰을 할당하는 것은 낭비"이며 "이미지 프롬프트 생성에 50 토큰을 할당하면 출력이 절단된다"는 것은 도메인 지식에서 직접 도출된다. 예측과 일치.
6개 model-client.ts를 하나의 shared/model-client.ts로 통합한다고 가정했을 때 발생하는 문제:
매개변수 폭발: 6개 용도의 차이를 수용하려면 options 객체가 {systemPrompt, userMessage, maxTokens, model, timeout, retryPolicy, onError, parseResponse, ...}로 비대해진다. 이는 Metz [2016]가 경고한 "wrong abstraction" 패턴에 정확히 해당한다.
조건부 분기 오염: 에러 처리가 용도마다 다르므로(502 반환 vs. fallback 값 반환), 공유 클라이언트 내부에 if (options.useFallback) 같은 조건부 분기가 삽입된다. 이 분기는 시간이 지남에 따라 증가하여, 공유 모듈이 모든 소비자의 요구를 만족시키려는 "God Object"로 퇴화한다.
타입 안전성 상실: 6개 용도의 반환 타입이 모두 다르므로, 공유 인터페이스는 제네릭 T나 유니온 타입으로 표현해야 하며, 각 호출 사이트에서 타입 가드(type guard)가 필요해진다.
AI 에이전트 컨텍스트 부담: AI 에이전트가 "카테고리 분류의 프롬프트를 수정하라"는 지시를 받았을 때, 공유 model-client.ts의 전체 코드(6개 용도의 모든 조건부 분기 포함)를 컨텍스트에 적재해야 하며, 수정이 다른 5개 용도에 미치는 영향을 추론해야 한다.
대상 프로젝트는 IDI를 명시적으로 채택한 단일 사례이므로, 관찰된 패턴의 일반성을 외부 데이터로 간접 검증한다. 본 절의 외부 데이터는 산업 리포트를 포함하며, 방향성을 지지하는 보조적 근거로 활용한다.
코드 복제의 산업적 증가 추세: GitClear [2025]는 211백만 줄의 코드를 분석하여, AI 코딩 도구 확산 이후 복제 블록이 8배 증가하고 리팩토링 비율이 25%에서 10% 미만으로 하락했음을 보고하였다. 이는 AI 에이전트가 DRY 리팩토링보다 코드 복제를 체계적으로 선호하는 경향을 보여주며, 본 논문의 비용 역전 가설과 부합한다. AI 에이전트에게 참조 추적 비용이 높기 때문에, 기존 코드를 참조하여 재사용하기보다 새로 생성하는 것이 비용 효율적인 것이다.
DRY 강제 환경에서의 품질 저하: Apiiro [2025]는 수만 개의 코드 저장소를 분석하여, AI 코딩 도구 사용 후 아키텍처 설계 결함이 153% 증가하고 권한 상승 경로가 322% 증가했음을 보고하였다. 주목할 점은 단순 구문 오류는 76% 감소한 반면 깊은 아키텍처 결함이 급증했다는 것이다. 이는 AI 에이전트가 로컬 코드 생성에는 능숙하지만, 여러 모듈에 걸친 의존성 추론(DRY 아키텍처의 핵심 요구)에서 실패하고 있음을 시사한다.
컨텍스트 인프라의 필요성: Park [2026] (워크숍 발표)은 108,000줄 C# 분산 시스템에서 "Codified Context" 인프라를 구축한 경험을 보고하며, LLM 기반 에이전트가 세션 간 일관성을 유지하려면 구조화된 컨텍스트 인프라가 필수적임을 논증하였다. 본 논문의 contracts/ 디렉토리와 usedBy 메타데이터 패턴은 이 관찰과 같은 방향의 해결책이다.
이들 외부 데이터는 대상 프로젝트의 관찰을 직접 재현하지는 않지만, IDI의 기저에 있는 "AI 에이전트의 컨텍스트 제약이 코드 조직화 전략에 영향을 미친다"는 명제를 독립적으로 지지한다.
H1: 동일한 기능 구현 태스크에 대해, 자기 완결적 컨텍스트(IDI 구조)를 제공받은 AI 에이전트는, 공유 의존성 컨텍스트(DRY 구조)를 제공받은 에이전트보다 더 높은 품질의 코드를 생성한다.
H2: 컨텍스트 내 파일 수가 증가할수록, AI 에이전트의 코드 생성 품질은 비선형적으로 저하된다.
실험 그룹: (A) IDI -- 단일 디렉토리만 제공(약 200-400줄), (B) DRY -- 공유 모듈 + 소비자 목록 + 대상 모듈(약 800-2000줄), (C) DRY-Large -- 그룹 B + 다른 소비자 전체(약 3000-5000줄). 태스크: "LLM 프롬프트에 새 출력 필드 추가", "타임아웃 변경 및 재시도 로직 추가", "에러 fallback 전략 변경", "새 외부 API 엔드포인트 추가"의 4개. 측정 메트릭: 기능 정확성(테스트 통과율), 컴파일 성공률, 사이드이펙트 발생 여부, 첫 성공까지 턴 수, 환각 비율. 통제 변수: 동일 LLM 모델(온도, 시드 고정), 동일 프롬프트 템플릿, 각 태스크 최소 30회 반복.
통제 실험의 본격 실행은 후속 연구에서 보고할 예정이나, 대상 프로젝트의 실제 개발 이력에서 비용 모델의 예측과 부합하는 예비 관찰을 보고한다.
관찰 1: IDI 격리 설계의 구현 검증. 대상 프로젝트의 git 이력 분석 결과, 충분한 수정 이력이 존재하는 9개 클라이언트 파일(model-client.ts 6개, image-client.ts 3개)에 대한 단일 디렉토리 내 수정 커밋은 총 26회(model-client.ts 유형 13회, image-client.ts 유형 13회) 발생하였으며, 이 중 교차 디렉토리 영향이 관찰된 사례는 0건이었다. vlm-client.ts(3개)와 catalog-client.ts(2개)는 분석 기간 내 수정 빈도가 낮아(각 0-2회) 정량 분석에서 제외하였다. 이 관찰은 IDI의 "효과 입증"이 아니라 **구현 검증(implementation validation)**으로 해석해야 한다. IDI 구조에서 교차 영향이 0인 것은 격리 아키텍처의 정의로부터 예측되는 당위이며, 26회 수정에서 이 예측이 실현되었다는 것은 IDI의 격리 설계가 의도대로 기능하고 있음을 확인한 것이다. 각 디렉토리가 평균 580줄(약 2,300토큰)로 자기 완결적이므로, AI 에이전트의 컨텍스트 예산 내에서 수정이 완결되었다.
관찰 2: 교차 디렉토리 변경의 어려움. 반면 여러 API 디렉토리를 순차 수정해야 하는 태스크에서는, AI 에이전트가 이전 수정의 세부사항을 이후 수정에서 일관되게 유지하지 못하는 경우가 관찰되었다. 이는 열화 함수 D(tokens_used, W) 활성화와 부합한다.
관찰 3: 독립 진화의 증거. image-client.ts 3개 복제본의 독립 수정 이력에서 복제본별 수정 빈도에 차이가 관찰된다: POST_ai_generate-scene-image(3회), POST_ai_generate-composite-image(4회), POST_avatar_generate(6회). 총 13회 수정의 3개 파일 분배이므로 수정 횟수 자체의 통계적 유의미성은 이 표본 크기로는 판별할 수 없다. 그러나 양적 빈도보다 주목할 것은 질적 특화의 내용이다: avatar_generate 복제본은 3분 타임아웃, 고정 해상도 1664x928, raw response 로깅 등 운영 환경에서 자연 발생한 고유 특화를 축적한 반면, scene-image 복제본에는 이러한 로직이 없다. 이 질적 분기는 수정 횟수와 독립적으로, IDI 구조가 각 복제본의 비즈니스 맥락에 맞는 독립적 진화를 안전하게 허용함을 보여준다.
관찰 4: 변경 자기완결률(Change Self-Containment Rate, CSCR). 대상 프로젝트의 git 이력에서 model-client.ts 관련 26회 수정 커밋을 분석한 결과, 전체 수정이 단일 디렉토리 내에서 완결되었다(CSCR = 26/26 = 100%). 이는 IDI 아키텍처의 아키텍처 속성 확인이며, 인과적 비교가 아닌 기술적(descriptive) 프록시 메트릭으로 해석해야 한다. DRY 아키텍처에서는 공유 모듈 수정 시 N개 소비자 영향 추적이 필요하므로 CSCR이 1 미만으로 하락할 것으로 예상된다.
7.2.4 예비 A/B 비교 실험 설계: 6개 model-client.ts 복제본을 단일 shared/model-client.ts로 통합한 가상 DRY 버전을 구성하고, Claude Code(Sonnet 4)에 10개 수정 태스크를 각 10회 시도하여 IDI 구조 vs DRY 구조의 첫 시도 성공률, 컴파일 성공 여부, 교차 영향 발생 건수를 비교하는 예비 A/B 비교 실험을 설계하였다. 태스크는 난이도 하(프롬프트/파라미터 변경) 3건, 중(로직 추가) 5건, 상(구조적 변경/신규 추가) 2건으로 구성된다. [실험 결과 삽입 예정 -- 결과 확보 후 이 자리에 IDI vs DRY 성공률 비교 기재]
이들 관찰은 git 이력에서 추출한 정량 데이터에 기반하나, 통제된 실험이 아니므로 인과 추론에는 한계가 있다. 그러나 비용 모델의 핵심 예측 -- "컨텍스트 격리가 변경 영향 범위를 한정한다" -- 과 방향성이 일치한다.
본 논문의 핵심 주장은 **DRY와 IDI가 상호 배타적 교리가 아니라, 비용 함수에 의해 선택되는 연속체(continuum)**라는 것이다. DRY는 "인간 개발자 + 큰 코드 작성 비용 + 작은 참조 추적 비용"이라는 비용 구조에 최적화된 전략이며, IDI는 "AI 에이전트 + 작은 코드 생성 비용 + 큰 참조 추적 비용"이라는 비용 구조에 최적화된 전략이다.
이 관점에서 대상 프로젝트의 아키텍처가 보여주는 구조는 시사적이다:
usedBy)으로 IDI의 유지보수 비용을 완화.같은 코드베이스 안에서 DRY와 IDI가 공존한다. 선택 기준은 "DRY인가 IDI인가"라는 이분법이 아니라, "이 모듈의 비용 구조에서 어떤 전략이 총 비용을 최소화하는가"이다.
더 나아가, contracts/의 usedBy 메타데이터는 이 연속체의 본질을 드러낸다. IDI는 코드 수준에서 DRY를 포기하지만, 메타데이터 수준에서 DRY를 재도입한다. usedBy 배열은 "이 외부 API를 사용하는 모든 엔드포인트"라는 지식의 단일 표현(single representation)이며, 이는 Hunt와 Thomas [1999]의 DRY 정의("모든 지식 조각은 시스템 내에서 단일의, 모호하지 않은, 권위 있는 표현을 가져야 한다")를 메타데이터 계층에서 정확히 구현한 것이다. 즉, 본 논문의 핵심 주장은 "DRY의 폐기"가 아니라 **DRY 적용 수준의 상향 이동(elevation)**이다: 코드(실행 로직)는 복제하여 각 소비자의 독립 진화를 허용하되, 코드 간의 관계에 대한 지식(어떤 복제본이 어떤 외부 API에 의존하는가)은 단일 소스로 유지한다. 이 구분은 "DRY를 부정하는 것 아닌가?"라는 반론에 대한 정밀한 응답이다: IDI가 제거하는 것은 코드 수준의 단일 표현이지, 지식 수준의 단일 표현이 아니다.
IDI 패턴은 마이크로서비스 아키텍처의 "shared-nothing" 원칙과 구조적으로 유사하다. 마이크로서비스가 서비스 간 독립 배포를 위해 코드 복제를 수용하듯, IDI는 AI 에이전트의 컨텍스트 격리를 위해 모듈 내 코드 복제를 수용한다.
그러나 중요한 차이가 있다:
| 차원 | 마이크로서비스 | IDI |
|---|---|---|
| 격리 단위 | 서비스 (독립 프로세스) | 디렉토리 (단일 프로세스 내) |
| 격리 강도 | 강: 독립 배포, 독립 장애 격리, 독립 스케일링 | 약: 인지적/컨텍스트 격리만. 런타임 격리 없음 |
| 격리 동기 | 독립 배포, 팀 자율성 | AI 에이전트 컨텍스트 제약 |
| 복제 대상 | 도메인 모델, 인프라 코드 | 외부 API 클라이언트, 타입 정의 |
| 비용 교환 | 네트워크 복잡성 | 복제 유지보수 |
| 정당화 근거 | Conway의 법칙, 조직 구조 | 컨텍스트 창 경제학 |
IDI와 더 근접한 기존 패턴은 모노레포 내 패키지 분리(Turborepo, Nx 등)이다. 모노레포는 빌드 격리와 독립 배포를, IDI는 AI 에이전트의 컨텍스트 격리를 추구하지만, 두 패턴 모두 "격리를 위한 복제 비용 수용"이라는 동일한 트레이드오프를 공유한다.
이러한 유사성은 IDI가 기존 소프트웨어 공학 원칙의 새로운 맥락으로의 확장임을 시사한다. Conway의 법칙이 "조직 구조가 시스템 구조를 결정한다"고 한다면, 본 논문은 "개발 주체의 인지 모델이 최적 코드 조직화 전략을 결정한다"는 확장 명제를 제안한다. 주니어 개발자 중심 팀이 평이한 코드를 선호하는 현상은 인지 제약이라는 점에서 AI 에이전트의 컨텍스트 제약과 구조적으로 유사하며, AI 에이전트는 "제약 조건이 최적 코드 조직화를 결정한다"는 원칙이 가장 극단적으로 드러나는 사례이다.
IDI의 가장 큰 약점은 외부 API 스펙 변경 시 K개 복제본을 모두 수정해야 하는 유지보수 비용이다. 대상 프로젝트는 이를 contracts/ 디렉토리의 usedBy 메타데이터로 완화한다:
contracts/externals/llm-api/spec.ts:
usedBy: [
"api/ai/POST_ai_classify-category",
"api/ai/POST_ai_generate-scene-prompt",
"api/ai/POST_ai_generate-scene-image",
"api/avatar/POST_avatar_generate",
"api/resource/POST_resource-allocation",
"api/recommend/POST_recommend_items"
]
이 메타데이터는 AI 에이전트에게 "이 외부 API를 사용하는 모든 엔드포인트 목록"을 컨텍스트 탐색 없이 즉시 제공한다. DRY 아키텍처에서 grep이나 IDE의 "Find Usages"로 수행하던 참조 추적을, O(1)의 선언적 조회로 대체한다.
차별적 전파 정책: 6.1.2절의 image-client.ts 사례가 보여주듯, IDI에서는 한 복제본의 수정을 다른 복제본에 전파할지 여부가 핵심 운영 판단이다. 본 논문은 수정의 성격에 따른 차별적 전파 정책을 제안한다: (1) 안전 관련 수정(에러 처리 강화, 보안 패치, 인증 방식 변경)은 usedBy를 참조하여 모든 복제본에 전파한다 -- 이는 알려진 위험의 방치를 방지한다. (2) 비즈니스 로직 수정(프롬프트 변경, 타임아웃 조정, 후처리 로직 추가)은 독립 진화를 허용한다 -- 각 복제본의 비즈니스 컨텍스트가 다르므로 동일 수정이 적절하지 않을 수 있다. 이 구분은 IDI의 실무적 운영 가능성을 높이며, 특히 프로덕션 온콜 환경에서 "다른 복제본에서 발견된 장애를 전파하지 않는다"는 우려를 해소한다.
공통 변경 전파 워크플로우 (K=6, model-client.ts 기준): (1) contracts/externals/llm-api/spec.ts의 usedBy 배열을 조회하여 6개 소비자를 즉시 식별한다. (2) 첫 번째 복제본(예: classify-category/model-client.ts)에서 수정 패턴을 확립한다 -- 인증 헤더 변경이라면 Authorization: Bearer ${API_KEY}를 Authorization: OAuth ${ACCESS_TOKEN}으로 치환. (3) 나머지 5개 복제본에 동일 패턴을 적용하되, 각 복제본의 고유 로직(fallback 전략, 타임아웃, 후처리)은 보존한다. (4) 각 복제본의 개별 호환성을 확인한다 -- resource-allocation의 fallback 경로가 새 인증에서도 작동하는지, avatar_generate의 타임아웃이 OAuth 토큰 갱신과 양립하는지 등.
외부 API의 응답 필드명 변경(예: total_tokens → token_count) 시에도 동일 워크플로우가 적용되며, 각 복제본의 후처리 로직이 독립적이므로 필드 매핑의 개별 검증이 용이하다.
usedBy의 유지보수 비용: usedBy 메타데이터 자체의 동기화 비용을 인정해야 한다. 새 엔드포인트 추가 시 갱신, 삭제 시 제거, 실제 코드와의 불일치 위험이 존재한다. 대상 프로젝트에서는 이를 두 가지로 완화한다. 첫째, 신규 API 생성 시 spec.ts 작성과 함께 contract의 usedBy 갱신을 필수 절차로 규정하여 누락을 방지한다. 둘째, usedBy 배열과 실제 import 관계의 일치 여부를 CI에서 자동 검증하는 방안이 가능하다(각 디렉토리의 *-client.ts 파일 상단에 명시된 Contract 주석을 파싱하여 usedBy와 대조). 이러한 자동 검증은 "문서와 코드의 동기화 비용"이라는 전통적 문제를 낮은 비용으로 해결한다.
본 논문의 비용 모델을 실무에 적용하기 위한 의사결정 흐름을 제시한다. 현업 개발자가 "이 모듈을 공유할 것인가, 복제할 것인가"를 판단할 때 다음의 질문 순서를 따를 수 있다.
질문 0: 이 프로젝트는 어떤 생명주기 단계에 있는가?
질문 1: 이 모듈 수정에서 AI 에이전트의 비중은 어느 수준인가?
질문 2: 이 모듈의 소비자들이 독립적으로 다른 방향으로 진화할 가능성이 있는가?
질문 3: 복제본 수 K는 관리 가능한 수준인가?
usedBy 메타데이터로 추적 가능.질문 4: 공유 모듈이 조건부 분기로 오염될 위험이 있는가?
caller: string, mode: 'A' | 'B')가 추가되었거나 추가가 논의되는 시점, 또는 if (caller === 'A') ... else if (caller === 'B') ... 패턴이 코드나 설계에 등장하면 IDI 전환 시점이다.이 프레임워크는 이분법적 결정이 아닌, 비용 교차점에 근거한 점진적 판단을 지원한다. 새 프로젝트 시작 시에는 DRY로 출발하되, 소비자 간 분기가 관찰되면 IDI로 전환하는 점진적 접근이 가능하다. 역방향 전환도 가이드되어야 한다: 복제본 간 diff가 공통 스켈레톤만 남을 정도로 수렴했거나, K가 2 이하로 감소했거나, 4.4절의 공통 변경 비율 r_B가 지속적으로 높거나, 또는 AI 에이전트의 다중 파일 추론 능력이 비용 모델의 열화 임계치를 넘어서 향상되었다고 판단되는 시점이면 DRY 통합을 재검토할 시점이다. IDI로 독립 진화한 복제본들을 다시 통합하는 것은 단순 병합이 아니다. 각 복제본이 축적한 고유 특화(프롬프트, 타임아웃, fallback 전략, 후처리 로직)의 분기를 조화시키는 설계 작업이며, 이 비용은 복제 기간과 독립 진화의 정도에 비례한다. 이는 Dodds [2020]의 AHA(Avoid Hasty Abstractions) 원칙과도 일맥상통한다: 충분한 패턴이 드러나기 전에는 추상화하지 말고, 복제를 통해 각 소비자의 실제 요구를 파악한 후 결정하라. contracts/ 메타데이터 없이 IDI를 시작한 프로젝트의 경우, 유지보수 단계 진입 시 기존 복제본의 외부 의존성을 조사하여 contracts/를 사후 구축하는 것이 가능하다. 이는 기존 실행 코드의 수정 없이 메타데이터 파일만 추가하는 작업이므로 마이그레이션 비용이 낮다.
본 논문의 비용 모델과 IDI 패턴의 적용 범위를 명확히 한정한다:
프로젝트 규모: 수백 개의 엔드포인트를 가진 대규모 시스템에서는 복제본 수 K가 감내 가능한 수준을 초과할 수 있다. 대상 프로젝트의 12개 엔드포인트에서 최대 K=6인 현재의 관찰을 수백 개 엔드포인트로 일반화하는 것은 추가 검증이 필요하다.
도메인 특성: 대상 프로젝트는 AI/ML 파이프라인으로서 다수의 LLM/VLM API 호출을 포함하는 특성이 있다. CRUD 중심 비즈니스 애플리케이션에서는 외부 API 클라이언트의 분기 잠재력이 낮아 IDI의 이점이 감소할 수 있다.
AI 에이전트 활용 비중: IDI는 AI 에이전트가 코드 수정의 유의미한 비중(50% 이상)을 담당하는 환경에서 경제적 이점이 본격화된다. AI 에이전트 비중이 30% 미만인 환경에서는 DRY의 원래 경제적 논거가 유효하다.
기술 스택: TypeScript의 구조적 타입 시스템이 IDI의 타입 분기를 자연스럽게 지원한다. 명목적 타입 시스템(Java, C#)에서는 타입 복제의 비용이 더 클 수 있다.
도구 지원 성숙도: 고도로 성숙한 IDE 통합(완전한 semantic index, 실시간 의존성 그래프)이 구현된 환경에서는 DRY의 참조 추적 비용이 상당히 감쇄되어 비용 교차점이 DRY 유리 방향으로 이동한다. 4.2절의 η 감쇄 항이 이를 반영한다.
팀 규모 및 조직적 제약: IDI의 유지보수 비용은 팀 규모에 따라 비선형적으로 변화한다. 소규모 팀(1-5명)에서는 복제본 전파를 구두로 조율할 수 있어 IDI 비용이 낮다. 중규모 팀(5-15명)에서는 contracts/ 메타데이터와 CI 자동 검증이 사실상 필수이다. 대규모 팀(15명+)에서 코드 소유권이 분산되면 "누가 어떤 복제본을 관리하는가"의 조율 비용이 급증하므로, usedBy 자동 검증과 복제 그룹 가시화 도구 없이는 IDI 채택이 위험하다. 또한 "중복 코드를 허용하지 않는" 강한 코드 리뷰 문화를 가진 조직에서는 IDI 도입 자체가 사회적 비용을 수반하며, 팀 합의와 온보딩 문서화가 선행되어야 한다.
IDI 적용 도메인 스펙트럼: 본 논문의 분석은 외부 API 클라이언트에 집중되어 있으나, IDI 적용 가능성은 코드 계층에 따라 스펙트럼으로 분포한다.
이 스펙트럼은 비용 모델의 핵심 변수(분기 잠재력, 소비자 수, 독립 진화 패턴)에 의해 결정되며, "모든 것을 복제하라"가 아닌 "비용 교차점을 넘는 계층만 복제하라"는 본 논문의 연속체 논증과 일관된다.
현업의 대부분은 인간과 AI의 혼합 개발 환경이다. IDI 아키텍처가 이 환경에서 제기하는 고유한 과제와 대응 전략을 논의한다.
코드 리뷰: 인간 리뷰어에게 14개의 유사한 클라이언트 파일은 "이건 중복 아닌가?"라는 인지적 부담을 야기한다. 이를 완화하려면 (1) 각 복제본 상단에 // 복사 원본: ... 주석으로 복제 관계를 명시하고, (2) contracts/의 usedBy 메타데이터로 복제 그룹을 가시화하며, (3) 리뷰 시 "이 파일만 보면 됩니다, 다른 디렉토리에 영향 없음"이라는 IDI의 핵심 이점을 팀 컨벤션으로 공유해야 한다. 실제로 IDI 구조에서의 코드 리뷰는 변경 영향 범위가 1개 디렉토리로 한정되므로, DRY 구조에서 "이 변경이 다른 소비자에 영향을 주는가?"를 추적하는 리뷰보다 인지 부하가 낮을 수 있다.
팀 온보딩과 이해 비용: IDI 구조에서 14개의 유사한 파일은 새 팀원에게 "이 파일들이 어떻게 다른가?"라는 이해 비용(comprehension cost)을 부과한다. DRY 구조의 "1개 공유 모듈 이해"와 비교하면, 전체 시스템 파악의 초기 비용은 IDI가 높을 수 있다. 이를 완화하려면 설계 원칙("외부 API 클라이언트를 의도적으로 복제한다")을 온보딩 문서에 명시하고, contracts/의 usedBy로 복제 그룹을 가시화하며, 각 복제본의 고유 목적을 spec.ts에 선언해야 한다. 반면 수정 시 이해 비용은 IDI가 유리하다: "이 파일만 이해하면 된다"는 IDI의 자기 완결성이 "공유 모듈 + N개 소비자 관계"를 이해해야 하는 DRY보다 수정 시점의 인지 부하를 낮춘다.
린터 및 정적 분석 도구 조정: SonarQube, ESLint 등 정적 분석 도구의 중복 코드 경고 설정 조정이 IDI 도입의 실무적 전제이며, CI 파이프라인에서 허용 가능한 복제 패턴을 명시적으로 정의해야 한다.
인간의 수동 수정: 인간이 IDI 코드를 직접 수정할 때는 "이 디렉토리 밖의 파일은 수정하지 않는다"는 원칙과, 공통 변경(API 인증 방식 변경 등) 시 contracts/의 usedBy를 조회하여 영향받는 모든 복제본을 확인하는 절차를 따른다.
본 논문의 근거 체인에는 peer-reviewed 논문과 산업 리포트가 혼재하며, 후자는 보조적 산업 신호로서의 역할에 한정된다.
단일 사례 연구의 한계: 대상 프로젝트는 단일 프로덕션 코드베이스이며, 관찰된 패턴이 이 특정 프로젝트의 고유 맥락에 기인할 가능성을 배제할 수 없다. 반사실적 분석(6.5절)으로 DRY 대안의 구체적 문제를 제시하였으나, 엄밀한 인과 추론에는 통제 실험(7절)의 실행이 필요하다. 7.2.4의 예비 비교는 단일 AI 모델(Claude Sonnet 4), 단일 코드베이스, 10회 시도의 소규모 표본이므로 통계적 유의성은 미검증이다. 방향성 증거(directional evidence)로만 해석해야 하며, 인과적 결론에는 7.1절의 본격 실험이 필요하다.
생존자 편향: 분석 대상인 대상 프로젝트는 IDI를 채택하여 성공적으로 운영 중인 프로젝트이다. IDI를 채택했으나 유지보수 비용이 과도하여 DRY로 회귀한 프로젝트, 또는 부분 전파 실패로 장애를 겪은 프로젝트는 분석 대상에 포함되지 않았다. 이 생존자 편향은 IDI가 성공하기 위한 실제 조건 -- 팀 역량, 메타데이터 관리 규율, 도메인 적합성 등 -- 이 본 논문에서 제시한 것보다 더 엄격할 가능성을 내포한다. 즉, IDI의 적용 범위가 논문의 제안보다 실제로는 좁을 수 있다.
설계자 편향: 대상 프로젝트의 아키텍처 설계자가 "코드 복제 > 코드 참조" 원칙을 사전에 채택한 상태에서 개발이 진행되었으므로, IDI 패턴의 관찰이 설계 의도의 확인에 불과할 수 있다. 이를 완화하기 위해 세 가지 근거를 제시한다. 첫째, 6.1절에서 각 복제본의 분기가 비즈니스 요구에서 자연스럽게 발생했음을 증거로 제시하였다. 둘째, image-client.ts에서 2개 복제본에만 raw response 로깅과 b64_json fallback이 추가된 사례는 설계 의도가 아닌 운영 중 자연 발생한 분기이다. 셋째, 6.6절의 외부 데이터(GitClear의 211M줄 분석, Apiiro의 아키텍처 결함 증가)가 IDI의 기저 명제를 독립적으로 지지한다.
일반화 가능성: 단일 사례 연구로부터의 일반화는 본질적으로 제한적이다. 본 논문은 IDI가 "항상 DRY보다 우월하다"고 주장하지 않으며, 비용 모델에서 도출된 특정 조건 하에서 IDI가 경제적으로 정당화된다고 주장한다. 다양한 도메인, 규모, 기술 스택의 코드베이스에 대한 다중 사례 연구가 후속 연구로 필요하다.
코드베이스 규모: 16,800줄은 산업 표준으로는 소규모이다. 수십만 줄 이상의 대규모 코드베이스에서 IDI의 비용 구조가 어떻게 변화하는지는 미검증이다.
비용 모델의 단순화: 제안된 비용 모델은 참조 추적 비용과 복제 유지보수 비용이라는 두 축의 기술적 변수로 단순화되어 있다. 팀 규모, 코드 소유권 분산, 코드 리뷰 문화 등 조직적 비용 변수가 반영되지 않았다. 특히 IDI의 유지보수 비용 C_dup_maintain(K)는 소규모 팀과 대규모 팀에서 비선형적으로 다를 수 있으며(8.5절 참조), 이 조직적 차원의 비용 모델링은 후속 연구의 과제이다.
"의도적" 복제의 판별: 복제가 "의도적"인지 "우연적"인지의 판별이 연구자의 해석에 의존한다. 본 연구에서는 설계 문서(프로젝트 내부 아키텍처 위키)의 명시적 선언, 복제본 상단의 주석(// 복사 원본: ...), 그리고 분기 지점의 비즈니스 정당성을 판별 기준으로 사용하였다.
분석의 재현 가능성: 구조적 유사도 측정은 수작업 코드 비교에 기반하며, 자동화된 클론 탐지 도구(SourcererCC, NiCad 등)를 사용하지 않았다. 핵심 논거는 비율의 정확한 수치가 아니라 "고유 로직의 비율이 상당하다"는 질적 관찰이므로 결론에 대한 영향은 제한적이나, 후속 연구에서는 자동화된 Type-3 클론 탐지 도구로 재현 가능성을 확보할 필요가 있다.
비용 모델의 파라미터 미추정: 열화 함수 D(tokens_used, W)의 파라미터(alpha, theta, beta)를 실험적으로 추정하지 않았다. 현재 비용 모델은 정성적 방향성(IDI가 DRY보다 유리한 조건의 존재)을 논증하는 수준이며, 정량적 비용 예측에는 7절의 통제 실험 실행이 전제된다.
본 논문은 LLM 기반 AI 에이전트의 컨텍스트 창 제약이 코드 조직화의 경제학을 근본적으로 변화시킨다는 것을 형식적 비용 모델과 프로덕션 코드베이스의 실증 분석을 통해 논증하였다.
핵심 관찰 및 논거를 요약한다:
비용 역전의 형식화: "참조 추적 비용 > 코드 생성 비용"이라는 역전이 AI 에이전트의 인지 모델에서 발생하며, 이는 컨텍스트 창 크기, 소비자 수, 공유 모듈 크기에 의해 결정되는 비용 교차점을 갖는다.
IDI 패턴의 학술적 정립: 의도적 복제(Intentional Duplication for Isolation)를 자기 완결성, 독립 진화, 분기의 비즈니스 정당성이라는 불변 조건으로 형식화하고, 적용 조건과 경계 조건을 명시하였다.
탐색적 사례 분석: 대상 프로젝트의 14개 IDI 인스턴스에서, 표면적 중복률 20.2% 중 실질적 중복은 5.6%에 불과하며, 72.4%는 비즈니스 특화 고유 로직이다. 분기는 프롬프트, 토큰 예산, 에러 처리, 타입 정의, 후처리 로직의 5개 차원에서 체계적으로 발생한다.
DRY-IDI 연속체: DRY와 IDI는 상호 배타적 교리가 아니라, 개발 주체의 인지 모델과 비용 구조에 의해 선택되는 연속체이다. 동일 코드베이스 내에서도 모듈 특성에 따라 DRY(kernel/, contracts/)와 IDI(api/ 클라이언트)가 공존할 수 있다. 특히 contracts/ 패턴이 보여주듯, IDI는 코드 수준에서 DRY를 포기하되 메타데이터 수준에서 DRY를 재도입하는 "적용 수준의 상향 이동"을 통해, DRY 원칙의 본질(지식의 단일 표현)을 보존한다.
소프트웨어 공학 원칙은 불변의 진리가 아니라, 특정 비용 구조와 개발 환경에 최적화된 휴리스틱이다. 개발 주체가 인간에서 AI로 전환됨에 따라, 이 휴리스틱의 전제를 재검토하고 새로운 비용 모델에 적합한 원칙을 탐구하는 것은 소프트웨어 공학 연구의 시의적절한 과제이다.
실무적으로, 코드 리뷰에서 "이 코드가 다른 파일과 중복입니다"라는 지적은 AI 에이전트 중심 환경에서는 반드시 부정적이지 않다. 그 중복이 (1) 비즈니스 특화 분기를 포함하고, (2) 모듈 격리로 변경 안전성을 확보하며, (3) AI 에이전트의 컨텍스트 효율을 향상시키면, 기술 부채가 아니라 아키텍처적 결정이다.
단기 (6개월, 본 논문의 설득력을 결정적으로 강화할 연구):
D(tokens_used, W)의 파라미터(alpha, theta, beta)를 추정하여, 4.4절의 실무적 임계치를 경험적으로 검증한다.중장기 (1-2년, 분야 확장):
[Anthropic, 2026] Anthropic. "2026 Agentic Coding Trends Report: How Coding Agents Are Reshaping Software Development." Anthropic, 2026. https://resources.anthropic.com/2026-agentic-coding-trends-report
[Apiiro, 2025] Apiiro. "4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks." Apiiro Blog, 2025. https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/
[Chroma Research, 2025] Chroma Research. "Context Rot: How Increasing Input Tokens Impacts LLM Performance." Chroma Research, 2025. https://research.trychroma.com/context-rot
[Context Discipline, 2025] "Context Discipline and Performance Correlation: Analyzing LLM Performance and Quality Degradation Under Varying Context Lengths." arXiv:2601.11564, 2025.
[Copilot Agent, 2025] GitHub. "GitHub Introduces Coding Agent For GitHub Copilot." GitHub Newsroom, 2025. https://github.com/newsroom/press-releases/coding-agent-for-github-copilot
[Conway, 1968] Conway, M. E. "How Do Committees Invent?" Datamation, 14(4):28-31, 1968.
[Dodds, 2020] Dodds, K. C. "AHA Programming." https://kentcdodds.com/blog/aha-programming, 2020.
[Feng et al., 2025] Feng, S., et al. "Agentic Much? Adoption of Coding Agents on GitHub." arXiv:2601.18341, 2025.
[GitClear, 2025] GitClear. "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones." https://www.gitclear.com/ai_assistant_code_quality_2025_research, 2025.
[GitHub, 2023] GitHub. "Octoverse: The State of Open Source and Rise of AI in 2023." GitHub, 2023.
[Hunt and Thomas, 1999] Hunt, A. and Thomas, D. "The Pragmatic Programmer: From Journeyman to Master." Addison-Wesley, 1999.
[Ji et al., 2023] Ji, Z., Lee, N., Frieske, R., et al. "Survey of Hallucination in Natural Language Generation." ACM Computing Surveys, 55(12):1-38, 2023.
[Juergens et al., 2009] Juergens, E., Deissenboeck, F., Hummel, B., and Wagner, S. "Do Code Clones Matter?" In Proceedings of the 31st International Conference on Software Engineering (ICSE), pp. 485-495, 2009.
[Kapser and Godfrey, 2008] Kapser, C. J. and Godfrey, M. W. "'Cloning Considered Harmful' Considered Harmful: Patterns of Cloning in Software." Empirical Software Engineering, 13(6):645-692, 2008.
[Liu et al., 2024] Liu, N. F., Lin, K., Hewitt, J., et al. "Lost in the Middle: How Language Models Use Long Contexts." Transactions of the Association for Computational Linguistics, 12:157-173, 2024.
[LongGenBench, 2025] "LongGenBench: Benchmarking Long-Form Generation in Long Context LLMs." In Proceedings of the International Conference on Learning Representations (ICLR), 2025.
[Martin, 2003] Martin, R. C. "Agile Software Development: Principles, Patterns, and Practices." Prentice Hall, 2003.
[Martin, 2017] Martin, R. C. "Clean Architecture: A Craftsman's Guide to Software Structure and Design." Prentice Hall, 2017.
[Metz, 2016] Metz, S. "The Wrong Abstraction." https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction, 2016.
[Newman, 2015] Newman, S. "Building Microservices: Designing Fine-Grained Systems." O'Reilly Media, 2015.
[Park, 2026] Park, J. "Codified Context: Infrastructure for AI Agents in a Complex Codebase." arXiv:2602.20478, 2026.
[Peng et al., 2023] Peng, S., Kalliamvakou, E., Cihon, P., and Demirer, M. "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot." arXiv preprint arXiv:2302.06590, 2023.
[Roy and Cordy, 2007] Roy, C. K. and Cordy, J. R. "A Survey on Software Clone Detection Research." Technical Report 2007-541, Queen's University, 2007.
[RULER, 2024] Hsieh, C.-Y., et al. "RULER: What's the Real Context Size of Your Long-Context Language Models?" In NeurIPS, 2024. https://github.com/NVIDIA/RULER
[Sajnani et al., 2016] Sajnani, H., Saini, V., Svajlenko, J., Roy, C. K., and Lopes, C. V. "SourcererCC: Scaling Code Clone Detection to Big-Code." In Proceedings of the 38th International Conference on Software Engineering (ICSE), pp. 1157-1168, 2016.
[Sequential-NIAH, 2025] "Sequential-NIAH: A Needle-In-A-Haystack Benchmark for Extracting Sequential Needles from Long Contexts." arXiv:2504.04713, 2025.
[Stack Overflow, 2025] Stack Overflow. "2025 Developer Survey Results." Stack Overflow, 2025.
T1. AI-Native-Software-Architecture "AI-Native 소프트웨어 아키텍처: LLM 기반 개발을 위한 설계 원칙." (저자) 미출판 원고, 2025.
[Vaithilingam et al., 2022] Vaithilingam, P., Zhang, T., and Glassman, E. L. "Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models." In CHI Conference on Human Factors in Computing Systems Extended Abstracts, 2022.
[Yourdon and Constantine, 1979] Yourdon, E. and Constantine, L. L. "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design." Prentice Hall, 1979.