유용우 (me@yowu.dev) / 2026.02.26
LLM 기반 코드 생성 도구가 보편화되면서 AI 에이전트가 단순 보조 도구를 넘어 주요 개발 주체로 부상하고 있다. 그러나 SOLID, DRY, Clean Architecture 등 기존의 확립된 아키텍처 원칙은 인간 개발자의 인지 모델에 최적화되어 있어, 제한된 컨텍스트 창(context window)과 환각(hallucination) 경향 등 LLM 고유의 제약을 반영하지 못한다. 본 논문은 산업 프로젝트(대형 전자상거래 플랫폼을 위한 AI 개인화 이벤트 서비스)의 역공학(reverse engineering) 분석을 통해 다섯 가지 AI-Native 아키텍처 원칙을 도출하고 형식화한다: (1) 영향 범위 최소화(Blast Radius Minimization), (2) 참조보다 의도적 복제(Intentional Duplication over Reference), (3) 제로 컨텍스트 원칙(Zero-Context Principle), (4) 메타데이터로서의 계약(Contract as Metadata), (5) AI 작업 기억으로서의 명세(Spec as AI Working Memory). 나아가 AI 워크플로우 스킬(skill)이 원칙 준수를 강제하는 프롬프트 기반 아키텍처 거버넌스(prompt-based architecture governance)를 제시하며, 이는 전통적 정적 분석을 보완하는 메커니즘이다. 원칙 달성도를 정량 측정하는 다섯 가지 메트릭을 제안한다. 사례 연구 결과 평균 달성도는 74%였으며, 디렉토리 격리(95%)와 의도적 복제(90%)에서 높은 적합도를 보인 반면, 진실 원천(source of truth)으로서의 명세(40%)는 문서화와 런타임 결합 사이의 근본적 긴장을 노출하였다. 본 논문은 이들 원칙의 적용 조건과 기존 소프트웨어 공학 원칙과의 트레이드오프를 논의한다.
키워드: AI-Native 아키텍처, LLM 기반 개발, 소프트웨어 설계 원칙, 아키텍처 거버넌스, 프롬프트 엔지니어링
소프트웨어 개발의 지형이 근본적인 변환을 맞이하고 있다. 대규모 언어 모델(Large Language Model, LLM)은 실험적 호기심의 대상에서 주류 개발 워크플로우에 내장된 실용적 코드 생성 엔진으로 진화하였다. GitHub Copilot, Cursor, Claude Code와 같은 도구들이 산업 전반에 걸쳐 코드 작성의 상당 부분에 참여하고 있다 [Peng et al., 2023; Vaithilingam et al., 2022]. 초기 실증 연구들은 AI 지원 코딩 도구 사용 시 26%에서 55%에 이르는 생산성 향상을 보고하고 있으며 [Peng et al., 2023], 산업 조사에 따르면 전문 개발자의 84%가 AI 코딩 도구를 사용 중이거나 계획 중이며, 전문 개발자의 과반(51%)이 매일 사용하고 있다 [Stack Overflow, 2025; GitHub, 2023].
그러나 한 가지 핵심적 질문이 대체로 미답의 영역으로 남아 있다: AI 에이전트가 코드 생성에서 점점 더 중심적인 역할을 수행함에 따라, 수십 년간 소프트웨어 설계를 이끌어 온 아키텍처 원칙이 여전히 적절한가? SOLID [Martin, 2003], DRY(Don't Repeat Yourself) [Hunt and Thomas, 1999], Clean Architecture [Martin, 2017]와 같은 원칙은 인간 개발자의 인지적 한계—제한된 작업 기억, 긴 의존성 사슬의 추적 어려움, 코드 작성 및 유지의 높은 비용—를 관리하기 위해 수립된 것이다. 이러한 원칙은 코드를 읽고, 이해하고, 수정하는 주체가 인간 인지의 제약 내에서 작업하는 인간 개발자라는 것을 암묵적으로 전제한다.
LLM 기반 AI 에이전트는 근본적으로 상이한 인지 모델 하에서 작동한다. 이들의 "작업 기억(working memory)"은 고정 크기의 컨텍스트 창으로서, 일반적으로 8K에서 200K 토큰 범위이며, 이 안에서 입력의 중간에 위치한 정보에 대한 주의(attention)가 저하된다 [Liu et al., 2024]. 또한 환각(hallucination)—그럴듯하지만 부정확한 코드를 생성하는 현상—에 취약하며, 특히 여러 파일과 추상화 계층에 걸친 추론이 요구될 때 그러하다 [Ji et al., 2023]. 반면, 코드 생성의 한계 비용(marginal cost)은 거의 영에 수렴하여, 인간 개발자에게는 비용이 과도했을 코드 복제와 같은 전략이 경제적으로 실행 가능해진다.
이러한 차이는 인간 인지에 최적화된 아키텍처 패러다임이 주요 개발자가 AI 에이전트일 때 차선(suboptimal)이거나 심지어 역효과를 낳을 수 있음을 시사한다. DRY 원칙을 예로 들어 보자: 코드 복제의 제거는 변경 사항을 수동으로 전파해야 하는 인간에게 유지보수 부담을 줄여 주지만, AI 에이전트에게는 코드베이스 전반에 걸쳐 공유 의존성을 추적하는 행위 자체가 소중한 컨텍스트 창 용량을 소비하고 환각 확률을 높인다. 이러한 환경에서는 모듈 격리를 달성하기 위해 코드를 의도적으로 복제하는 것이 더 나은 결과를 산출할 수 있다.
본 논문은 **AI-Native 소프트웨어 아키텍처(AI-Native Software Architecture)**의 개념을 도입한다. 이는 AI 에이전트가 주요 코드 생성 및 수정 주체로 기능하는 환경에 명시적으로 최적화된 설계 원칙의 집합이다. AI-Native 아키텍처를 AI 에이전트가 코드 생성 및 수정의 주요 주체임을 전제로 설계된 소프트웨어 아키텍처 원칙 체계로서, 컨텍스트 창 한계, 환각 경향, 거의 영에 가까운 코드 생성 비용 등 LLM 고유 제약에 최적화된 것으로 정의한다. 이 원칙들은 대형 전자상거래 플랫폼을 위해 AI 에이전트 중심 워크플로우로 개발된 프로덕션 AI 개인화 이벤트 서비스(이하 '대상 프로젝트')의 역공학 분석을 통해 도출되었다. 분석 결과, 전통적인 코드 재사용, 추상화, 인간 가독성의 미덕보다 컨텍스트 격리, 변경 안전성, AI가 이해 가능한 메타데이터를 우선시하는 다섯 가지 원칙이 도출되었다.
구체적으로, 본 논문은 다음의 연구 질문을 다룬다:
이 원칙들은 명시적 전제 조건(7.1절) 하에서 유효한 초기 단계 이론적 프레임워크로서, 증거 수준에 비례하는 주장 범위를 유지하며, 추가 사례를 통한 검증과 정제가 요구된다.
본 논문의 기여는 네 가지로 요약된다:
본 논문의 구성은 다음과 같다. 2절에서는 소프트웨어 아키텍처 원칙, AI 지원 소프트웨어 공학, LLM 인지 특성에 걸친 배경 및 관련 연구를 조사한다. 3절에서는 형식적 정의와 원칙 간 의존성 분석과 함께 다섯 가지 AI-Native 원칙을 제시한다. 4절에서는 스킬 기반 거버넌스 메커니즘을 기술한다. 5절에서는 대상 프로젝트 사례 연구를 보고한다. 6절에서는 제안 메트릭을 정의한다. 7절에서는 적용 조건과 트레이드오프를 논의한다. 8절에서는 타당도에 대한 위협을 다루며, 9절에서는 향후 연구 방향과 함께 결론을 맺는다.
본 절에서는 본 논문이 다루는 연구 공백을 집합적으로 형성하는 네 가지 관련 연구 흐름을 조사한다: 소프트웨어 아키텍처 원칙의 진화(2.1절), AI 지원 소프트웨어 공학(2.2절), 아키텍처 거버넌스 및 적합성 검사(2.3절), 코드 생성과 관련된 LLM의 인지적 특성(2.4절).
소프트웨어 아키텍처 분야는 대규모 시스템의 복잡성 관리를 목표로 하는 풍부한 설계 원칙의 체계를 산출해 왔다. Martin [2003]이 형식화한 SOLID 원칙—단일 책임(Single Responsibility), 개방-폐쇄(Open/Closed), 리스코프 치환(Liskov Substitution), 인터페이스 분리(Interface Segregation), 의존성 역전(Dependency Inversion)—은 가장 널리 채택된 객체지향 설계 지침을 대표한다. 이들 원칙은 인간 개발 팀이 모듈화되고, 확장 가능하며, 유지보수 가능한 시스템을 산출하는 것을 공동 목표로 한다.
Hunt와 Thomas [1999]가 기술한 DRY(Don't Repeat Yourself) 원칙은 "모든 지식 조각은 시스템 내에서 단일하고, 모호하지 않으며, 권위 있는 표현을 가져야 한다"고 주장한다. DRY는 소프트웨어 공학 문화에 매우 깊이 내재되어 코드 복제가 일상적으로 코드 냄새(code smell)로 지적되고 [Fowler, 2018] 자동 리팩토링 도구의 대상이 되고 있다. 그 근본적인 경제적 합리성은 명쾌하다: 인간이 복제된 코드에 걸쳐 변경 사항을 수동으로 전파해야 할 때, 유지보수 비용은 복사본 수에 선형적으로 비례하여 증가하며, 불일치의 확률도 높아진다. 그러나 DRY에 대한 비판도 축적되어 왔다. Metz [2016]는 '복제는 잘못된 추상화보다 훨씬 싸다'라고 주장하며, 성급한 추상화가 조건부 분기로 오염된 공유 코드를 오히려 악화시킨다고 경고하였다. Dodds [2020]는 AHA(Avoid Hasty Abstractions) 원칙을 제안하여 충분한 사용 패턴이 드러나기 전의 추상화를 경계하였고, Kapser와 Godfrey [2008]는 코드 클론 연구에서 포킹 패턴(forking pattern)이 합리적인 엔지니어링 판단일 수 있음을 논증하였다. 이들의 비판은 DRY의 맹목적 적용이 인간 개발자 맥락에서도 위험함을 보여 주며, LLM의 고비용 추론 환경에서 DRY의 실무 적용 한계를 지적하는 후속 연구 [T3]와 함께, AI 에이전트의 인지 모델이라는 새로운 차원에서 DRY의 재검토를 더욱 정당화한다.
Clean Architecture [Martin, 2017]와 헥사고날 아키텍처(Hexagonal Architecture) [Cockburn, 2005]는 이러한 원칙을 시스템 수준 조직으로 확장하여, 엄격한 의존성 규칙을 갖는 동심원적 추상화 계층을 처방한다. 도메인 주도 설계(Domain-Driven Design, DDD) [Evans, 2003]는 대규모 도메인의 복잡성 관리 메커니즘으로서 바운디드 컨텍스트(bounded context)와 유비쿼터스 언어(ubiquitous language)를 더욱 강조한다. Bass 등 [2021]은 소프트웨어 아키텍처 품질 속성에 대한 포괄적 논의를 제공하며, 아키텍처 추론을 지배하는 수정성(modifiability), 시험성(testability), 배포성(deployability)의 어휘를 확립하였다.
이들 프레임워크를 관통하는 공통 맥락은 그 암묵적 최적화 대상이 인간 개발자의 인지 능력이라는 점이다. SOLID은 클래스 책임 이해의 정신적 부담을 줄인다. DRY는 개발자가 특정 로직을 이해하기 위해 단 한 곳만 살펴보면 되도록 보장한다. Clean Architecture는 시스템 구조를 탐색하기 위한 정신 모델을 제공한다. 이들은 인간이 코드 이해와 수정의 주요 주체일 때 타당한 원칙이다.
그러나 아키텍처 결정의 주된 소비자가 인간 개발자라는 전제는 AI 에이전트 주도 개발의 부상에 의해 점점 도전받고 있다. 코드를 읽고, 이해하고, 수정하는 주체가 근본적으로 상이한 인지 프로파일을 가진 LLM일 때, 최적화 대상이 전환되며, 인간 인지를 위해 설계된 원칙의 재검토가 요구될 수 있다.
소프트웨어 개발에 대한 AI의 통합은 세 가지 뚜렷한 단계를 거쳐 진행되어 왔으며, 각 단계는 개발 워크플로우 내에서 AI 역할의 질적 전환을 나타낸다.
제1단계: 코드 완성(Code Completion, 2020–2022). 초기 연구는 개발자의 편집기 내에서 다음 토큰이나 코드 행을 예측하는 신경망 코드 완성에 초점을 두었다 [Svyatkovskiy et al., 2020]. Codex 모델 [Chen et al., 2021] 기반의 GitHub Copilot [Chen et al., 2021]이 이 단계를 대표한다. 개발자가 유일한 의사결정자로 남으며, AI는 개발자가 수용, 수정 또는 거부하는 제안을 제공한다. 실증적 평가는 측정 가능한 생산성 향상을 보여 주었다: Peng 등 [2023]은 통제 실험에서 55.8% 더 빠른 태스크 완료율을 보고하였으며, Ziegler 등 [2022]은 개발자가 Copilot 제안의 약 30%를 수용한 것으로 확인하였다.
제2단계: 대화형 지원(Conversational Assistance, 2022–2024). ChatGPT와 유사한 대화형 AI 시스템의 등장은 대화 기반 상호작용 모델을 도입하였다. 개발자가 자연어로 태스크를 기술하면 코드 블록, 설명 또는 아키텍처 제안을 수신한다. Vaithilingam 등 [2022]은 이 단계에 대한 세밀한 관점을 제공하며, AI 도구가 초기 코드 생성을 가속화하는 반면 때로는 추가 디버깅 시간을 요구하는 미묘한 버그를 도입한다는 것을 발견하였다. 이 단계에서 개발자는 코드베이스에 대한 완전한 통제를 유지하며, AI는 지원하되 프로젝트 파일을 독립적으로 탐색하거나 수정하지 않는다.
제3단계: 자율 에이전트 개발(Autonomous Agent Development, 2024–현재). 가장 최근에, 패러다임은 자율적 개발 에이전트로서의 AI로 전환되었다. Devin [Cognition, 2024], SWE-Agent [Yang et al., 2024], Claude Code [Anthropic, 2025]와 같은 시스템은 최소한의 인간 개입으로 코드베이스를 독립적으로 탐색하고, 파일을 읽고 쓰며, 셸 명령을 실행하고, 테스트를 수행하며, 완전한 구현을 산출할 수 있다. 이 단계를 조작적으로 정의한다: *AI를 주요 개발자로 하는 모드(AI-as-primary-developer)*란 AI 에이전트가 어떤 파일을 읽을지 자율적으로 결정하고, 여러 파일에 걸쳐 코드를 생성 또는 수정하며, 검증 단계를 실행하는 개발 모드로서, 인간 개발자는 코드의 직접 저자가 아닌 주로 리뷰어이자 아키텍처 의사결정자로 기능한다.
이 3단계 진행은 도구의 변화뿐 아니라 개발자와 코드베이스 사이의 근본적 관계의 전환을 나타낸다는 점에서 중요하다. 제1, 2단계에서는 AI가 개발자의 인지 프레임 내에서 작동하므로 아키텍처 원칙이 인간 인지만 수용하면 되었다. 제3단계에서는 AI 에이전트가 독립적으로 코드베이스 구조를 해석하며, 인간이 아닌 AI의 인지 특성이 효과적 코드 생성의 구속 제약(binding constraint)이 된다.
이러한 궤적에도 불구하고, AI 지원 소프트웨어 공학에 관한 기존 문헌은 주로 생산성 지표, 코드 품질, 개발자 경험에 초점을 두어 왔다. AI 에이전트 성능을 최적화하기 위해 소프트웨어 아키텍처가 어떻게 설계되어야 하는지의 문제는 대체로 미개척 상태로 남아 있다. Ross 등 [2023]은 AI 에이전트가 잘 구조화된 코드베이스에서 더 나은 성능을 보인다는 관찰을 통해 이 주제에 접근하였으나, 구체적인 아키텍처 원칙을 제안하지는 않았다. AI 에이전트가 주요 개발자로 부상하고 있다는 인식과 그 특성에 적합한 아키텍처 원칙의 수립 사이의 이 공백이 본 논문의 핵심 동기이다.
아키텍처 거버넌스는 구현된 시스템이 의도된 아키텍처 설계에 부합하도록 보장하는 프로세스와 도구를 포괄한다. 근본적 과제는 아키텍처 의도(설계 문서, 결정, 규약으로 표현됨)와 구현된 현실(소스 코드로 체현됨) 사이의 간극을 메우는 것이다. 전통적 접근법은 아키텍처 규칙을 구조적 제약으로 인코딩하는 정적 분석 도구를 통해 이 간극을 다룬다.
Knodel과 Popescu [2007]는 정적 아키텍처 적합성 검사 접근법에 대한 포괄적 비교를 제공하며, 세 가지 주요 메커니즘을 식별하였다: (1) 고수준 아키텍처 모델을 추출된 소스 코드 의존성과 비교하는 반사 모델(reflexion model), (2) 모듈 수준 결합을 시각화하고 제약하는 의존성 구조 매트릭스(dependency structure matrix, DSM), (3) 아키텍트가 금지되거나 요구되는 의존성 패턴을 선언할 수 있는 아키텍처 제약 언어.
ArchLint [Terra et al., 2015], SAVE [Knodel et al., 2006], Sonargraph 등의 도구가 이러한 메커니즘을 빌드 파이프라인에 통합된 자동화 검사로 구현한다. 이들은 비인가 계층 횡단, 순환 의존성, 인터페이스 우회 등의 위반을 탐지한다. 구조적 제약에 대해서는 효과적이나, 이러한 도구들은 AI 주도 개발의 맥락에서 세 가지 근본적 한계를 공유한다.
첫째, 이들은 오직 **산출된 결과물(produced artifact)**에 대해서만 작동한다—생성된 코드가 구조적 규칙에 부합하는지 검증할 수 있지만, 생성 과정 자체에는 영향을 미치지 못한다. 인간 개발자가 코드를 작성할 때, 정적 분석 경고와 코드 수정 사이의 피드백 루프는 인간의 이해에 의해 매개된다. AI 에이전트가 코드를 생성할 때, 이 피드백 루프는 부재하거나(에이전트가 린터 출력을 읽지 않음) 추가적인 오케스트레이션 계층을 필요로 한다.
둘째, 전통적 거버넌스 도구는 코드 구조적 수준(모듈 의존성, 클래스 계층, 패키지 경계)에서 규칙을 인코딩하며, "이 모듈을 수정하기 전에 명세 파일을 읽어라" 또는 "변경 사항을 대상 디렉토리로 한정하라"와 같은 행동적 또는 의도적 제약을 표현할 수 없다. 이러한 프로세스 수준 제약이야말로 AI 에이전트에게 가장 관련성 높은 유형의 거버넌스이다.
셋째, 정적 분석 도구는 코드가 검사되는 기준이 되는 안정적 아키텍처 모델을 전제한다. AI 주도 개발에서는 AI 에이전트가 코드를 신속하게 생성하고 재구조화할 수 있으므로, 아키텍처 모델 자체가 사후 강제가 아니라 에이전트의 작동 컨텍스트의 일부로 전달될 필요가 있다.
AI 주도 개발의 출현은 따라서 아키텍처 거버넌스에 새로운 차원을 도입한다. AI 에이전트가 코드를 생성할 때, 그것은 프롬프트, 시스템 명령, 워크플로우 정의에 의해 한정된 행동 경계 내에서 작동한다. 이 관찰은 새로운 거버넌스 메커니즘을 시사한다: 아키텍처 제약을 정적 분석 규칙이 아닌, AI 에이전트의 행동을 안내하는 자연어 지시에 인코딩하는 것이다. 이 접근법을 **프롬프트 기반 아키텍처 거버넌스(prompt-based architecture governance)**로 명명하며, 4절에서 이를 전개한다.
프롬프트 기반 거버넌스는 정적 분석의 대체가 아니라 개발 생명주기의 상이한 시점에서 작동하는 보완적 계층이다. 정적 분석은 산출된 결과물의 구조적 속성을 검증하며(사후 검증), 프롬프트 기반 거버넌스는 생성 과정 자체를 제약한다(과정 내 제어). 이 구분은 제조 공학에서 품질 검사(완성품 검사)와 공정 관리(제품 제조 과정의 제약) 사이의 차이에 대응한다. 두 계층의 조합—생성을 안내하는 프롬프트 기반 거버넌스와 출력을 검증하는 정적 분석—은 AI 주도 개발 환경에 더 포괄적인 거버넌스 프레임워크를 제공한다.
전통적 아키텍처 원칙이 AI 에이전트에게 왜 차선적일 수 있는지 이해하기 위해서는, 코드 생성 태스크와 관련된 LLM의 인지적 특성을 검토할 필요가 있다.
작업 기억으로서의 컨텍스트 창. LLM은 인간의 작업 기억과 유사하지만 근본적으로 상이한 고정 크기 컨텍스트 창 내에서 입력을 처리한다. 현재 모델은 8K 토큰(초기 GPT-3.5 변형)에서 200K 토큰(예: Claude 3, GPT-4 Turbo) 이상의 컨텍스트 창을 지원한다. 그러나 이 창의 효과적 활용은 균일하지 않다. Liu 등 [2024]은 "중간에서 길을 잃다(Lost in the Middle)" 현상을 입증하였다: LLM은 관련 정보가 긴 컨텍스트의 중간에 위치할 때 성능이 현저히 저하되며, 시작과 끝의 정보를 선호하는 U자형 주의 곡선을 보인다. 후속 연구는 이 문제의 심각성을 재확인한다. Chroma Research [2025]가 명명한 '컨텍스트 부패(context rot)' 현상에 따르면, 18개 LLM 측정 결과 입력 토큰이 증가할수록 성능이 실제로 저하되며, 이론적 컨텍스트 한계와 실효적 성능 임계치 사이에 큰 간극이 존재한다. 128K 토큰 컨텍스트에서 최고 성능 모델의 정확도가 63.5%에 불과하였으며, 단순 검색보다 추론 태스크에서 저하가 더 심각하다 [Li et al., 2025]. 컨텍스트 창 크기와 코드 조직화 비용의 관계에 대한 상세 모델은 [T3]에서 전개된다. 이러한 발견은 소프트웨어 아키텍처에 직접적 함의를 갖는다: AI 에이전트가 많은 파일을 컨텍스트 창에 로드해야 하는 코드베이스 구조는 핵심 정보를 주의 저하 영역에 위치시킬 위험이 있다.
코드 생성에서의 환각. 환각—그럴듯하지만 사실적으로 부정확한 출력의 생성—은 LLM의 잘 문서화된 한계이다 [Ji et al., 2023]. 코드 생성에서 환각은 존재하지 않는 API 참조, 부정확한 파라미터 타입, 조작된 라이브러리 함수로 나타난다. 환각의 확률은 요구되는 추론의 복잡성에 비례하여 증가하며 [Huang et al., 2023], 이는 파일 간 추론을 요구하는 아키텍처 구조(깊은 상속 계층, 복잡한 의존성 주입 그래프)가 환각 위험을 높일 수 있음을 시사한다.
거의 영에 수렴하는 코드 생성의 한계 비용. 코드 작성이 시간 집약적 활동인 인간 개발자와 달리, LLM은 거의 영에 가까운 한계 비용으로 코드를 생성한다. 이 경제적 전환은 전통적 비용-편익 분석을 역전시킨다. DRY 하에서는 복제의 비용(변경 사항의 수동 전파)이 추상화의 비용(공유 코드의 생성 및 유지)을 초과한다. AI 에이전트가 요청 시 복제된 코드를 재생성할 수 있을 때, 복제의 비용은 극적으로 하락하는 반면, 추상화의 비용(공유 의존성의 컨텍스트 로딩, 파일 간 참조 추적)은 일정하거나 증가한다. 이 역전은 의도적 복제가 경제적으로 합리적인 조건을 창출한다.
프롬프트 구조에 대한 민감성. LLM의 성능은 입력 프롬프트의 구조와 내용에 매우 민감하다 [Wei et al., 2022; Brown et al., 2020]. 명확한 경계를 가진 잘 구조화되고 명시적인 지시는 모호하거나 암묵적인 명세보다 현저히 나은 출력을 산출한다. 이 민감성은 아키텍처적 함의를 갖는다: 파일에 분산된 암묵적 규약에 의존하기보다 명시적이고 자기 완결적인 명세를 제공하는 코드베이스가 고품질 AI 코드 생성에 더 도움이 된다.
이 네 가지 특성—비균일 주의를 갖는 한계 컨텍스트 창, 환각 경향, 거의 영에 가까운 생성 비용, 프롬프트 민감성—은 LLM 기반 개발 에이전트의 "인지 모델"을 집합적으로 정의한다. 3절에서 제시하는 다섯 가지 AI-Native 아키텍처 원칙은 각각 이러한 특성 중 하나 이상에 의해 동기 부여되며, 이는 해당 절의 표 1에 요약되어 있다.
본 절에서는 대상 프로젝트의 분석으로부터 도출되고 2.4절에서 기술한 LLM 인지 특성에 근거한 다섯 가지 AI-Native 아키텍처 원칙을 제시한다. 각 원칙은 네 가지 요소로 구성된 형식적 정의와 함께 제시된다: (1) 목적(purpose), (2) 불변 조건(invariant), (3) 원칙을 동기 부여하는 LLM 특성, (4) 기존 소프트웨어 공학 원칙과의 트레이드오프.
원칙은 제시 순서에 따라 1부터 5까지 번호가 매겨지며, 이는 교육적 명료성을 위해 선택되었다: 가장 직관적이고 실증적으로 검증된 원칙인 영향 범위 최소화(사례 연구에서 95% 달성)에서 시작하여, 가장 이상적이지만 관찰된 달성도가 가장 낮은(40%) AI 작업 기억으로서의 명세로 진행한다. 이 배열은 독자가 충분한 증거를 가진 원칙을 통해 프레임워크에 대한 신뢰를 구축한 후 더 탐색적인 원칙에 접근할 수 있도록 한다. 이 번호는 논문 전체에서 제시 순서를 반영하며, 우선순위 순위를 나타내지 않음에 유의하라.
표 1. LLM 인지 특성과 AI-Native 원칙의 매핑
| LLM 특성 | 동기 부여되는 원칙 |
|---|---|
| 한계 컨텍스트 창(bounded context window) | 영향 범위 최소화, 제로 컨텍스트 원칙 |
| 비균일 주의(Lost in the Middle) | 제로 컨텍스트 원칙, AI 작업 기억으로서의 명세 |
| 환각 경향(hallucination tendency) | 영향 범위 최소화, 의도적 복제, 메타데이터로서의 계약 |
| 거의 영에 가까운 생성 비용(near-zero generation cost) | 참조보다 의도적 복제 |
| 프롬프트 민감성(prompt sensitivity) | 메타데이터로서의 계약, AI 작업 기억으로서의 명세 |
목적. 단일 코드 변경이 시스템 내에서 가능한 한 가장 작은 범위에만 영향을 미치도록 보장하며, 이상적으로는 단일 디렉토리 내로 한정한다.
불변 조건. 기능 F를 대상으로 하는 변경 태스크 T에 대해, T를 완료하기 위해 수정되는 파일의 집합은 단일 디렉토리 D(F) 내에 포함되어야 하며, |affected_directories(T)| = 1이어야 한다.
동기. 이 원칙은 주로 LLM의 한계 컨텍스트 창과 환각 특성에 의해 동기 부여된다. 코드 변경이 여러 디렉토리나 모듈에 걸친 수정을 요구할 때, AI 에이전트는 영향받는 각 위치의 파일을 컨텍스트 창에 로드해야 한다. 추가 파일마다 총 토큰 수가 증가하고, 주요 태스크에 할당되는 컨텍스트의 비율이 감소하며, 파일 간 추론으로 인한 환각 확률이 높아진다. 영향 범위를 단일 디렉토리로 제약함으로써, 이 원칙은 주어진 변경에 필요한 컨텍스트를 최소화하고 오류 기회를 줄인다.
형식적 정의. C를 디렉토리 *D = {d_1, d_2, ..., d_n}*으로 조직된 코드베이스라 하자. 변경 태스크 T에 대해, *blast_radius(T) = |{d in D : files_modified(T) ∩ files(d) ≠ ∅}|*로 정의한다. 영향 범위 최소화 원칙은 기대되는 변경 태스크 집합에 대해 E[blast_radius(T)] 가 1에 수렴하도록 아키텍처가 설계될 것을 요구한다.
기존 원칙과의 트레이드오프. 영향 범위 최소화는 단일 책임 원칙(SRP) 및 도메인 주도 설계의 바운디드 컨텍스트 개념과 대체로 양립하지만, 다른 세분성(granularity)에서 작동한다. SRP는 클래스가 변경의 이유를 하나만 가져야 한다고 처방하고, 영향 범위 최소화는 변경이 하나의 디렉토리에만 영향을 미쳐야 한다고 처방한다. 이 구분은 의미가 있다: SRP는 클래스 분해에 관한 설계 시간 원칙인 반면, 영향 범위 최소화는 디렉토리 조직에 관한 아키텍처 시간 원칙이다. 실무적으로, 단일 디렉토리의 영향 범위를 달성하기 위해서는 SRP가 별도 패키지에 배치할 파일들(예: 라우트 핸들러, 서비스 로직, 데이터 접근 계층)을 단일 기능 디렉토리 내에 공존시키는 것이 필요한 경우가 많다. Vertical Slice Architecture [Bogard, 2018]와의 차이도 명확히 해야 한다: vertical slice는 UI-비즈니스-데이터 계층을 관통하는 기능 단위 분할이며 인간 개발자의 기능 이해를 목표로 한다. 영향 범위 최소화는 AI 에이전트의 컨텍스트 창 최적화를 목표로 하며, 디렉토리 물리적 구조까지 제약한다는 점에서 더 강한 격리를 요구한다.
다른 원칙과의 관계. 영향 범위 최소화는 다른 원칙들이 그 동기의 상당 부분을 도출하는 기초 원칙이다. 의도적 복제(원칙 2)는 영향 범위 격리를 달성하는 주요 메커니즘이며—공유 의존성을 각 기능 디렉토리에 복제하여 디렉토리 간 결합을 제거한다. 제로 컨텍스트(원칙 3)는 영향 범위가 성공적으로 최소화되었을 때 달성 가능해지는 창발적 속성(emergent property)이다.
대상 프로젝트에서의 달성도. 사례 연구에서 변경 태스크의 95%가 단일 API 또는 페이지 디렉토리 내의 파일만 수정하여 완료될 수 있었다. 단일 디렉토리 영향 범위를 초과한 5%의 태스크는 공유 인증 미들웨어와 전역 설정 변경 등의 횡단 관심사(cross-cutting concern)와 관련되었다. (상세 측정 절차는 5.3절에 기술.)
목적. 모듈 간 격리가 요구될 때, 단일 공유 참조를 유지하기보다 공유 코드를 각 모듈에 복제하는 것을 선호하며, DRY 위반을 의도적 아키텍처 선택으로 수용한다.
불변 조건. 모듈 M_1, M_2, ..., M_k가 사용하는 공유 유틸리티 또는 라이브러리 함수 U에 대해, M_i의 맥락에서 U의 수정이 M_j(단, i ≠ j)에 영향을 미쳐서는 안 된다면, 각 모듈은 독립적으로 진화할 수 있는 자체 복사본 U_i를 포함해야 한다.
동기. 이 원칙은 LLM의 거의 영에 가까운 코드 생성 한계 비용과 한계 컨텍스트 창 특성을 직접적으로 다룬다. 전통적 DRY 원칙은 코드 작성 비용이 참조 유지 비용에 비해 높다는 경제적 가정에 기반한다. AI 에이전트가 거의 영에 가까운 한계 비용으로 코드를 생성할 때, 이 가정은 역전된다. 더욱이, 공유 참조는 컨텍스트 로딩 부담을 부과한다: 공유 유틸리티를 참조하는 코드를 이해하거나 수정하기 위해, AI 에이전트는 공유 파일을 찾아 로드하고, 그 인터페이스와 행동을 이해하며, 변경이 모든 소비자에 미치는 함의를 추론해야 한다. 이 각 단계는 컨텍스트 창 용량을 소비하고 환각 위험을 도입한다.
형식적 정의. U를 모듈 M_1, ..., M_k가 참조하는 코드 단위(함수, 클래스 또는 모듈)라 하자. 공유 참조의 *결합 비용(coupling cost)*을 *C_ref(U) = Σ_i context_load_cost(U, M_i) + hallucination_risk(cross_file_reasoning)*으로 정의한다. 복제 비용을 *C_dup(U) = k × sync_cost(U) + k × storage_cost(U)*로 정의한다. 의도적 복제 원칙은 *C_dup(U) < C_ref(U)*일 때 복제를 권장하며, 이는 (a) sync_cost가 낮고(AI가 재생성 가능), (b) k가 적당하며(수백 개의 복사본이 아닌), (c) cross_file_reasoning 비용이 높을 때(LLM 컨텍스트 제약) 성립한다. 이 비용 비교의 정밀한 형식화는 동반 연구 [T3]에서 제시된다. 해당 연구는 DRY 전략의 비용(C_DRY(m_i) = C_read(m_i) + C_read(s) + C_trace(s, N) + C_modify(m_i) + C_verify(s, N))과 IDI 전략의 비용(C_IDI(m_i) = C_read(m_i) + C_modify(m_i) + C_dup_maintain(K))을 컨텍스트 창 크기 W를 변수로 도입한 열화 함수(D(tokens_used, W))와 함께 전개하며, 비용 교차점에 영향을 미치는 핵심 변수(소비자 수 N, 공유 모듈 크기, 변경 빈도, 복제본 수 K, 도구 지원 수준)를 분석한다.
기존 원칙과의 트레이드오프. 이 원칙은 소프트웨어 공학에서 가장 깊이 견지되는 교리 중 하나인 DRY와 정면으로 대립한다. 해결은 DRY와 의도적 복제가 상이한 비용 함수를 최적화한다는 인식에 있다. DRY는 변경 전파의 인간 비용을 최소화하고, 의도적 복제는 컨텍스트 로딩과 파일 간 추론의 AI 비용을 최소화한다. 어느 쪽도 보편적으로 우월하지 않으며—최적의 선택은 주요 개발자가 인간인지 AI 에이전트인지에 달려 있다. 이 트레이드오프는 시간적 차원을 갖는다는 점에 주목한다: LLM 컨텍스트 창이 확장되고 환각률이 감소하면, 균형은 공유 참조 쪽으로 다시 기울 수 있다. 따라서 이 원칙은 현재의 LLM 능력 상태에 조건부인 것으로 이해되어야 한다.
경계 조건(boundary conditions). 의도적 복제가 모든 코드 복제에 대한 포괄적 승인은 아니다. 세 가지 제약이 그 적용 범위를 한정한다. 첫째, 이 원칙은 모듈 격리에 기여하는 유틸리티 코드에 구체적으로 적용되며, 권위성을 가져야 하는 도메인 로직에는 적용되지 않는다. 둘째, 이 원칙은 *규모 임계값(scale threshold)*을 갖는다: k(복사본 수)가 수백 단위에 이르면 누적된 동기화 부담이 공유 참조의 컨텍스트 로딩 비용을 초과할 수 있다. 셋째, 보안에 민감한 코드의 복제는 복사본 간 불일치가 감사하기 어려운 취약점을 도입할 수 있으므로 원칙적으로 금지된다.
이 세 제약을 구체화하여, 코드 유형별 복제 허용 여부와 권장 동기화 주기를 표 1-1로 제시한다.
표 1-1. 복제 판단 기준: 코드 유형별 허용 범위와 권장 동기화 주기
| 코드 유형 | 복제 허용 | 권장 동기화 주기(예시) | 판단 근거 |
|---|---|---|---|
| 인프라 유틸리티 (HTTP 래퍼, 로거, 포맷터) | 허용 | 1–2주 | 모듈별 독립 설정 가능, 불일치 영향 국소적 |
| 모듈별 설정/어댑터 | 허용 | 1–2주 | 모듈별 독립 수정 가능 |
| LLM 프롬프트 래퍼 | 허용 | 제한 없음 | 모듈별 독립 진화가 의도적 |
| 비즈니스 로직 핵심 규칙 | 금지 | — | 전역 일관성 필수 |
| 인증/인가 로직 | 금지 | 0일(즉시) | 보안 불일치가 취약점 직결 |
| 정산/가격 계산 | 금지 | — | 법적/재무적 정합성 필수 |
| 보안 정책 (암호화, 입력 검증) | 금지 | 0일(즉시) | 감사 추적 불가능한 취약점 위험 |
이 판단 기준의 적용은 두 단계의 의사결정으로 구조화된다. 첫째, "이 코드가 모듈별로 독립적으로 수정 가능한가?"—긍정이면 복제 후보이다. 둘째, "이 코드의 불일치가 보안 또는 정합성 사고를 유발하는가?"—긍정이면 절대 복제 금지이다. 권장 동기화 주기는 프로젝트 맥락에 따라 조정 가능한 운영 heuristic으로서, 규범적 임계값이 아닌 판단 프레임워크로 이해되어야 한다. 나아가, 의도적 복제가 유효하기 위한 불변 조건은 동반 연구 [T3]에서 세 가지로 형식화된다: (I1) 자기 완결성—각 복제본이 외부 비즈니스 모듈에 대한 의존 없이 독립적으로 실행 가능해야 함, (I2) 독립 진화—한 복제본의 수정이 다른 복제본에 영향을 미치지 않아야 함, (I3) 분기의 비즈니스 정당성—복제본 간 차이가 비즈니스 요구의 차이에서 기인해야 함. 이 불변 조건은 표 1-1의 경계 조건을 보완하여, 복제의 허용 여부뿐 아니라 복제의 건전성을 사후 검증하는 기준을 제공한다.
적용 예시. 의도적 복제의 효과를 구체적으로 예증한다. 복제 전, 대상 프로젝트의 여섯 개 API는 공유 참조 구조로 shared/utils/model-client.ts를 임포트하였다—AI 에이전트가 어떤 API를 수정하든 이 공유 파일의 컨텍스트 로딩이 필요하였다. 복제 후, 각 API 디렉토리(예: apis/service-a/model-client.ts, apis/service-b/model-client.ts)에 지역 복사본을 배치하여, AI 에이전트는 대상 디렉토리 내의 파일만으로 수정을 완료할 수 있게 되었다. 이 구조 변경은 각 API의 LLM 클라이언트가 엔드포인트별 재시도 로직과 타임아웃으로 독립 진화하는 기반이 되었다.
대상 프로젝트에서의 달성도. 사례 연구에서 프로젝트는 각각 특정 API 엔드포인트를 위해 설정된 LLM 클라이언트 래퍼(model-client.ts)의 여섯 개 독립 복사본을 유지하였다. 버전 이력 분석 결과, 이러한 복사본들은 엔드포인트별 재시도 로직, 타임아웃 설정, 오류 처리를 갖추며 시간에 따라 분기되었음이 확인되어, 복제가 중복이 아니라 진정한 격리 목적에 기여하였음을 확인하였다. 전체 달성도는 90%였으며, 나머지 10%는 공유 유틸리티(주로 인증 미들웨어)가 복제되지 않고 참조되어 잔여 모듈 간 결합을 생성한 사례를 나타낸다.
목적. AI 에이전트가 외부 파일, 전역 설정 또는 횡단 추상화에 대한 지식 없이 해당 기능의 디렉토리 내 파일만 읽어 기능을 완전히 이해하고 수정할 수 있도록 코드베이스를 설계한다.
불변 조건. 기능 디렉토리 *D(F)*에 대해, D(F) 내의 파일은 AI 에이전트가 (a) 기능의 목적과 행동을 이해하고, (b) 모든 의존성과 제약을 식별하며, (c) D(F) 외부의 파일을 참조하지 않고 수정을 구현하기에 충분해야 한다.
동기. 제로 컨텍스트 원칙은 2.4절에서 식별한 네 가지 LLM 인지 특성 모두에 의해 동기 부여되어, 다섯 가지 원칙 중 가장 포괄적으로 동기 부여된 원칙이다. 한계 컨텍스트 창은 로드되는 파일 수의 최소화를 바람직하게 만들고, "중간에서 길을 잃다" 현상은 핵심 정보가 분산된 원격 파일이 아닌 직접적인 작업 세트에 존재해야 함을 중요하게 만든다. 환각 위험은 파일 간 추론과 함께 증가하며, 프롬프트 민감성은 전역적 지식을 요구하는 암묵적 규약보다 자기 완결적이고 명시적으로 구조화된 디렉토리가 AI 에이전트에게 더 효과적인 "프롬프트"로 기능함을 의미한다.
형식적 정의. *D(F)*를 기능 F의 디렉토리, *files(D(F))*를 해당 디렉토리의 파일 집합이라 하자. 개별 기능에 대해, AI 에이전트가 *files(D(F))*만 읽어 F에 대한 대표적 수정 태스크를 완료할 수 있으면 ZCS(F) = 1로, 그렇지 않으면 ZCS(F) = 0으로 정의한다. *ZCS(F)*는 각 개별 기능에 대해 이진(binary)임에 유의하라—주어진 기능은 제로 컨텍스트를 달성하거나 달성하지 못한다. 전체 코드베이스에 대한 제로 컨텍스트 점수는 제로 컨텍스트를 달성한 기능의 비율이다: ZCS(C) = (1/n) × Σ_F ZCS(F), 여기서 n은 기능의 수이다. 이 집계는 [0, 1]의 연속 값을 산출한다; 예를 들어 ZCS(C) = 0.75는 기능의 75%가 완전히 자기 완결적인 반면 25%는 외부 컨텍스트를 필요로 함을 나타낸다.
원칙 1, 2와의 관계. 제로 컨텍스트는 독립적 원칙이 아니라, 영향 범위 최소화와 의도적 복제의 성공적 적용으로부터 발생하는 창발적 속성이다. 영향 범위가 단일 디렉토리로 한정되고(원칙 1) 공유 의존성이 각 디렉토리에 복제되면(원칙 2), 그 결과는 AI 에이전트가 작업하는 데 필요한 모든 정보를 포함하는 디렉토리—즉, 외부 컨텍스트가 영(zero)인 디렉토리—이다.
원칙 간 의존성 구조는 세 계층의 방향 비순환 그래프(directed acyclic graph)를 형성한다. 기초 계층(foundation layer)에서 영향 범위 최소화와 의도적 복제는 독립적이지만 시너지적으로 작동한다—복제는 영향 범위 격리를 가능하게 하는 주요 메커니즘이다. 창발 계층(emergent layer)에서 제로 컨텍스트는 두 기초 원칙이 모두 달성되었을 때 결과로 발생한다: 디렉토리 격리(영향 범위 최소화로부터)와 지역적 코드 완전성(의도적 복제로부터)이 결합하여 자기 완결적 기능 디렉토리를 산출한다. 향상 계층(enhancement layer)에서 메타데이터로서의 계약과 AI 작업 기억으로서의 명세는 AI 에이전트의 컨텍스트 로딩 품질을 향상시키는 구조화된 메타데이터를 제공하여 제로 컨텍스트 디렉토리를 더욱 풍부하게 하지만, 제로 컨텍스트 자체의 전제 조건은 아니다.
기존 원칙과의 트레이드오프. 제로 컨텍스트는 전역적 일관성(global coherence)을 지역적 완전성(local completeness)과 교환한다. Clean Architecture에서 개발자는 의존성 규칙을 따라 외부 계층에서 내부 계층으로 탐색하며 시스템의 전역적 정신 모델을 구축한다. 제로 컨텍스트는 이를 역전시킨다: 각 디렉토리는 전역 모델 없이 이해될 수 있는 자기 완결적 단위이다. 이는 태스크 간에 지속적 정신 모델을 유지하지 않는 AI 에이전트에게는 유리하지만, Bass 등 [2021]이 인간 팀에 의한 장기 유지보수성에 필수적이라고 평가한 시스템의 개념적 무결성(conceptual integrity)을 저하시킬 수 있다. Package-by-Feature [Richardson, 2018]와의 차이도 명확히 한다: package-by-feature는 패키지 구조의 조직 원칙이며 외부 의존성을 허용한다. 제로 컨텍스트는 외부 컨텍스트의 완전 제거를 목표로 하며, 이를 위해 의도적 복제(원칙 2)까지 수용한다는 점에서 질적으로 다른 수준의 격리를 요구한다.
대상 프로젝트에서의 달성도. 제로 컨텍스트 점수는 75%로 측정되었다. 13개 API 엔드포인트 중 10개에 대해, AI 에이전트는 API 디렉토리 내의 파일(spec.ts, service.ts, 라우트 핸들러, 지역 유틸리티)만을 사용하여 수정 태스크를 완료할 수 있었다. 나머지 25%는 다음과 같은 이유로 외부 컨텍스트를 필요로 하였다: (a) 복제되지 않고 참조된 공유 인증 미들웨어, (b) API 행동에 영향을 미치는 전역 환경 설정, (c) 하위 로직을 올바르게 수정하기 위해 상위 변환에 대한 이해가 필요한 복잡한 데이터 파이프라인.
목적. 모듈 간 의존성과 인터페이스 계약을 암묵적 규약, 런타임 발견, 또는 코드베이스 외부 문서에 의존하기보다, 각 모듈 내에 명시적이고 기계 판독 가능한 메타데이터로 인코딩한다.
불변 조건. 외부 서비스 S에 의존하는 모듈 M에 대해, S와의 계약(기대 인터페이스, 데이터 스키마, 행동적 제약)은 M의 디렉토리 내에 구조화된 메타데이터로 선언되어야 하며, 이 메타데이터는 모든 소비자를 식별하는 명시적 usedBy 주석을 포함해야 한다.
동기. 이 원칙은 LLM의 환각 경향과 프롬프트 민감성 특성을 다룬다. AI 에이전트가 외부 서비스와 상호작용하는 코드를 생성해야 할 때, 서비스 인터페이스에 대한 정확한 정보가 필요하다. 이 정보가 모듈의 디렉토리에 명시적으로 존재하지 않으면, 에이전트는 더 넓은 코드베이스를 검색하거나(컨텍스트 창 용량 소비) 사용 패턴으로부터 인터페이스를 추론해야 한다(환각 위험). 계약을 명시적 메타데이터로—예를 들어 명세 파일 내의 TypeScript 타입 정의로—인코딩함으로써, 이 원칙은 AI 에이전트에게 구현 파일과 함께 컨텍스트에 로드될 수 있는 권위 있는 참조 자료를 제공한다.
형식적 정의. *deps(M)*을 모듈 M의 외부 의존성 집합, *contracts(M)*을 M의 디렉토리에 명시적으로 선언된 계약의 집합이라 하자. *계약 완전성(Contract Completeness)*을 *CC(M) = |contracts(M) ∩ deps(M)| / |deps(M)|*로 정의한다. 이 원칙은 모든 모듈에 대해 *CC(M)*이 1.0에 접근할 것을 요구한다. 나아가, 각 계약 *c ∈ contracts(M)*에 대해, *usedBy(c)*를 선언된 소비자의 집합으로 정의한다. 양방향 추적성(bidirectional traceability) 불변 조건은 계약 c의 모든 실제 소비자 *M'*이 *usedBy(c)*에 나타날 것을 요구한다.
기존 원칙과의 트레이드오프. 메타데이터로서의 계약은 계약에 의한 설계(Design by Contract) [Meyer, 1992]와 인터페이스 분리(SOLID의 'I')의 정신을 공유하지만, 위치와 형식에 대한 강조에서 차이가 난다. 전통적 계약에 의한 설계는 전제 조건과 후행 조건을 구현에 내장하고, 메타데이터로서의 계약은 이를 소비 모듈과 함께 공존(co-located)하는 독립적 메타데이터 파일로 외재화한다. 이 외재화는 동기화 문제를 도입하지만—메타데이터가 실제 구현으로부터 표류(drift)할 수 있다—AI 에이전트에게 컨텍스트 로딩 시 우선시될 수 있는 간결하고 권위 있는 참조를 제공한다. 따라서 이 원칙은 내장된 계약의 일관성 보장을 외재화된, AI 판독 가능한 메타데이터의 접근성 이점과 교환한다.
기존 API 명세 표준과의 구분. 메타데이터로서의 계약은 OpenAPI/Swagger [SmartBear, 2021]나 Protocol Buffers [Google, 2008] 등 기존 API 명세 형식과 피상적으로 유사하게 보일 수 있다. 그러나 두 가지 핵심적 측면에서 차이가 있다. 첫째, 위치: OpenAPI 명세는 전형적으로 중앙 집중식(프로젝트 루트의 단일 openapi.yaml 또는 문서화 엔드포인트)인 반면, 메타데이터로서의 계약은 각 소비 모듈의 디렉토리 내에 계약 정보가 공존할 것을 요구하여 AI 에이전트의 지역 컨텍스트에서 즉시 사용 가능하도록 한다. 둘째, 목적: OpenAPI는 문서화, 클라이언트 생성, 테스트에 기여하고, 메타데이터로서의 계약은 AI 에이전트의 컨텍스트 초기화에 기여한다—에이전트가 외부 명세 파일을 탐색하지 않고도 특정 모듈을 이해하고 수정하는 데 필요한 최소한의 권위 있는 정보를 제공한다. 두 접근법은 상호 보완적이다: OpenAPI 명세가 모듈 지역 계약 메타데이터가 도출되는 진실 원천으로 기능할 수 있지만, 이 메타데이터를 각 모듈 내에 공존시키는 행위가 메타데이터로서의 계약을 구분 짓는 아키텍처 결정이다.
동기화 문제. 이 원칙 내에 근본적 긴장이 존재한다: 계약 정보를 외재화하는 바로 그 행위가 계약 메타데이터와 실제 서비스 행동 사이의 표류 가능성을 생성한다. 이 긴장은 AI-Native 아키텍처에 고유한 것이 아니라—문서화와 코드의 동기화라는 오랜 과제를 반영한다—그러나 AI 에이전트가 오래된 메타데이터를 권위 있는 것으로 취급하여 진부한 계약에 부합하는 코드를 생성할 수 있으므로 특히 심각하다. 5.4절에서 대상 프로젝트 사례 연구에서 관찰된 이 표류의 사례를 논의한다.
대상 프로젝트에서의 달성도. 계약 완전성은 70%로 측정되었다. 프로젝트의 spec.ts 파일은 대부분의 외부 의존성에 대한 타입 정의와 인터페이스 계약을 선언하였으며, API를 그 소비 페이지에 연결하는 명시적 usedBy 주석을 포함하였다. 그러나 실제 의존성의 30%가 메타데이터에 반영되지 않았으며, 주로 다음과 관련되었다: (a) 공유 미들웨어를 통한 전이적 의존성(transitive dependency), (b) 조건부로 통합을 활성화하는 기능 플래그(feature flag)에 의한 런타임 발견 의존성, (c) 명세가 갱신되지 않은 최근 추가된 통합—위에서 논의한 명세-런타임 표류의 사례.
목적. 각 기능 디렉토리 내의 명세 파일(예: spec.ts)을 AI 에이전트의 권위 있는 진입점으로 지정한다—기능의 목적, 인터페이스, 의존성, 제약의 완전한 요약을 제공하여 AI 에이전트의 "작업 기억 초기화"로 기능하는 구조화된 문서이다.
불변 조건. 기능 디렉토리 *D(F)*에 대해, *spec(F)*만을 읽어 AI 에이전트에게 (a) 기능이 무엇을 하는지, (b) 입력과 출력이 무엇인지, (c) 의존성을 열거하고, (d) 수정 중 보존되어야 하는 제약과 불변 조건을 인식하기에 충분한 컨텍스트를 제공하는 명세 파일 *spec(F)*가 존재해야 한다. 대상 프로젝트에서 spec.ts는 다음의 구조화된 필드를 포함하였다: method/path(HTTP 인터페이스), summary(기능 요약), flow(실행 단계의 순서적 기술), tables: { reads, writes }(데이터베이스 의존성), externalAPIs(외부 API 계약 참조와 사용 엔드포인트), cautions(AI 에이전트가 수정 시 주의해야 할 엣지 케이스와 제약). 이 필드 구조는 AI 에이전트가 단일 파일에서 기능의 목적, 데이터 흐름, 외부 의존성, 주의사항을 즉시 파악할 수 있도록 설계되었으며, "구조화된 메타데이터"가 실무에서 취하는 구체적 형태를 예시한다.
동기. 이 원칙은 주로 LLM의 프롬프트 민감성과 비균일 주의 특성에 의해 동기 부여된다. 프롬프트 엔지니어링 연구는 입력의 시작 부분에 구조화되고 명시적인 컨텍스트를 제공하는 것이 LLM 출력 품질을 현저히 향상시킴을 입증하였다 [Wei et al., 2022]. 명세 파일은 이 발견을 아키텍처 수준에서 조작화한다: 각 기능 디렉토리의 진입점에 구조화된 요약을 배치함으로써, 이 원칙은 가장 핵심적인 정보가 주의가 가장 강한 AI 에이전트의 컨텍스트 창 시작부의 특권적 위치를 차지하도록 보장한다 [Liu et al., 2024].
형식적 정의. *spec(F)*를 기능 F의 명세 파일, *knowledge(F)*를 F를 이해하고 수정하는 데 필요한 사실의 완전한 집합이라 하자. *명세 범위(Spec Coverage)*를 *SC(F) = |facts_in(spec(F)) ∩ knowledge(F)| / |knowledge(F)|*로 정의한다. *명세-런타임 불일치율(Spec-Runtime Drift Rate)*을 *SRDR(F) = |facts_in(spec(F)) − facts_true_at_runtime(F)| / |facts_in(spec(F))|*로 정의한다. 이 원칙은 높은 SC(F)(포괄적 범위)와 낮은 SRDR(F)(정확한 범위)를 요구한다.
작업 기억 유추(analogy). "작업 기억"이라는 용어는 인지과학 개념 [Baddeley, 2000]에 대한 의도적 유추로서 사용되며, 기능적 동등성의 주장은 아니다. 인간의 작업 기억은 현재 태스크와 관련된 정보를 위한 임시 저장소로 기능하며, 명세 파일은 현재 기능과 관련된 코드베이스 지식의 선별된 하위 집합을 제공함으로써 AI 에이전트에게 유사한 역할을 수행한다. 이 유추는 불완전하다—인간의 작업 기억은 태스크 실행 중 동적으로 갱신되는 반면, 명세 파일은 정적 문서이다—그러나 본질적 기능을 포착한다: 전역적 검색 없이 즉각적이고 태스크 관련적인 컨텍스트를 제공하는 것.
기존 원칙과의 트레이드오프. AI 작업 기억으로서의 명세는 주류 소프트웨어 공학에서 드문 형태의 문서화로서의 아키텍처(documentation-as-architecture)를 도입한다. 지배적 관행은 "코드가 곧 문서"라는 것으로—Clean Code [Martin, 2008]와 애자일 방법론의 옹호자들이 주창하는 원칙이다. AI 작업 기억으로서의 명세는 코드를 요약하고 색인하는 구조화된 메타데이터 계층을 생성하여 이를 부분적으로 역전시킨다. 비용은 유지보수이다: 명세는 구현과 동기화 상태를 유지해야 하며, 표류는 원칙의 효과를 저하시킨다. 이점은 AI 판독성이다: 잘 유지된 명세는 원시 구현 파일의 파싱보다 훨씬 효과적인 고신호, 저잡음의 진입점을 AI 에이전트에게 제공한다.
다른 원칙과의 관계. AI 작업 기억으로서의 명세는 제로 컨텍스트(원칙 3)와 메타데이터로서의 계약(원칙 4) 모두를 향상시킨다. 명세 파일은 계약 메타데이터가 AI 에이전트에게 노출되는 매개체이며, 기능 디렉토리 내의 그 존재는 필수 정보를 단일 구조화된 파일에 통합하여 제로 컨텍스트 달성 가능성에 기여한다.
달성 경로와 현재 구현의 위상. 원칙 5의 이론적 위상은 유지하되, 대상 프로젝트에서의 현재 구현은 완전한 운용화(full operationalization)가 아니라 초기 운용화(initial operationalization)에 해당한다. 운용화의 세 가지 경로가 식별된다: (a) 수기 유지(현 대상 프로젝트 방식, 달성도 낮음), (b) 코드 생성 기반(AI가 구현에서 명세를 자동 재생성), (c) 하이브리드(골격은 수기, 세부는 자동 생성). 수기 유지 방식의 한계는 원칙 자체의 결함이 아니라 현행 구현 전략의 미성숙을 반영한다.
대상 프로젝트에서의 달성도. 이 원칙은 40%로 가장 낮은 달성률을 보였다. 13개 API 디렉토리 모두 spec.ts 파일을 포함하였으나, 이 명세들의 품질과 완전성은 상당히 가변적이었다. 주요 결함은: (a) 명세가 구현에서 수정된 인터페이스를 선언하면서 해당 명세 갱신이 이루어지지 않은 명세-런타임 표류(13개 API 중 4개에서 관찰), (b) 전이적 또는 조건부 의존성을 누락한 불완전한 의존성 열거, (c) 데이터 타입은 기술하되 비즈니스 규칙이나 불변 조건은 부재한 행동적 제약의 결여. 40%의 달성률은 명세 파일 중 절반 미만만이 AI 에이전트의 신뢰할 수 있는 작업 기억 초기화로 기능하기에 충분히 완전하고 정확하다는 평가를 반영한다. 이 낮은 달성도는 근본적 긴장을 드러낸다: 병행적 명세 계층을 유지하는 것은 AI 주도 워크플로우에서도—또는 특히 AI 주도 워크플로우에서—지속하기 어려운 규율을 요구하며, 코드 생성의 속도가 문서화 갱신을 앞지른다. 이 낮은 달성도가 부분적으로 구조적(현재 도구가 자동화하지 못하는 수준의 명세-코드 결합을 원칙이 요구함)이고 부분적으로 절차적(개발팀이 명세 우선 워크플로우를 일관되게 강제하지 않음)인 것으로 보인다. 이 두 요인의 분리—원칙이 본질적으로 달성하기 어려운 것인지, 아니면 단지 이 사례에서 미흡하게 구현된 것인지—는 7절에서 재론하는 질문이다.
다섯 가지 원칙은 독립적 설계 선택이 아니라 계층적 의존성 구조를 형성한다. 이 계층 구조를 이해하는 것은 프레임워크를 점진적으로 도입하고자 하는 실무자에게 필수적이다.
기초 계층: 영향 범위 최소화와 의도적 복제. 이 두 원칙이 구조적 기초를 형성한다. 영향 범위 최소화가 목표(단일 디렉토리 변경 격리)를 정의하고, 의도적 복제가 이를 달성하는 주요 메커니즘(코드 복제를 통한 디렉토리 간 결합 제거)을 제공한다. AI-Native 아키텍처를 도입하는 조직은 이 원칙들을 가장 먼저 구현해야 한다.
창발 계층: 제로 컨텍스트. 원칙 1과 2가 성공적으로 구현되면, 제로 컨텍스트는 자연스러운 결과로 발현된다. 각 변경이 하나의 디렉토리에 격리되고 필요한 모든 코드가 지역적으로 존재하면, 디렉토리는 자기 완결적이 되어—외부 컨텍스트가 영(zero)이 된다. 따라서 제로 컨텍스트는 직접 구현해야 할 원칙이라기보다 원칙 1과 2의 효과성을 나타내는 지표로서 측정되어야 할 품질이다.
향상 계층: 메타데이터로서의 계약과 AI 작업 기억으로서의 명세. 이 원칙들은 구조화된 메타데이터를 추가하여 제로 컨텍스트 환경의 품질을 향상시킨다. 메타데이터로서의 계약은 외부 의존성이 명시적으로 선언되도록 보장하고, AI 작업 기억으로서의 명세는 AI 에이전트를 위한 구조화된 진입점을 제공한다. 이 원칙들은 서로 독립적으로 점진적 도입이 가능하지만, 조합 시 가장 효과적이다.
이 계층 구조는 도입에 대한 실무적 함의를 갖는다. 조직은 다섯 가지 원칙을 동시에 구현할 필요 없이, 기초 계층(디렉토리 기반 모듈화와 선택적 복제를 통한 즉각적 영향 범위 축소 달성)부터 시작하여 AI-Native 실무가 성숙함에 따라 점진적으로 향상 계층을 추가할 수 있다.
2.3절에서 전통적 정적 분석 도구의 AI 주도 개발 거버넌스 한계를 식별하고 프롬프트 기반 아키텍처 거버넌스의 개념을 도입하였다. 본 절에서는 대상 프로젝트에서 관찰된 스킬 시스템을 분석 기반으로 삼아 이 개념을 상세히 전개한다.
AI 에이전트 주도 개발에서 **스킬(skill)**은 특정 유형의 태스크에 대해 AI 에이전트의 워크플로우를 정의하는 구조화된 자연어 지시이다. 각 스킬은 에이전트가 따라야 할 행동의 순서, 읽어야 할 파일, 준수해야 할 제약, 완료 시 수행해야 할 검증 단계를 명시한다. 스킬은 코드가 아니라—코드 생성 및 수정 태스크 중 에이전트의 행동을 형성하는 프롬프트 템플릿이다.
대상 프로젝트에서 개발 워크플로우의 역공학을 통해 아홉 가지 스킬이 식별되었다. 이 스킬들은 거버넌스 기능에 따라 세 가지 범주로 분류된다:
**생성형 스킬(generative skills)**은 새로운 아키텍처 단위의 생성을 통제한다. new-api 스킬은 AI 에이전트가 기존 API 디렉토리를 템플릿으로 읽은 후, 확립된 패턴에 따라 새로운 디렉토리에 spec.ts, service.ts, 라우트 핸들러 및 관련 파일을 생성하여 새 API 엔드포인트를 만들도록 지시한다. new-page 스킬은 프론트엔드 페이지에 대해 유사한 기능을 수행한다. 스킬 정의에 기대되는 디렉토리 구조와 파일 구성을 인코딩함으로써, 생성형 스킬은 새로 생성된 모듈이 처음부터 아키텍처 패턴에 부합하도록 보장한다.
**수정형 스킬(modificatory skills)**은 기존 아키텍처 단위의 변경을 통제한다. modify-api와 modify-page 스킬은 에이전트가 변경 전에 대상 모듈의 spec.ts를 읽도록 지시하고, 수정을 대상 디렉토리로 한정하며, 변경이 다른 모듈에 영향을 미치지 않음을 검증하도록 요구한다. 그림 1은 modify-api 스킬의 핵심 구조를 예시한다.
그림 1. modify-api 스킬 정의의 핵심 구조 (발췌)
전제조건(Preconditions):
"대상 API의 spec.ts를 먼저 읽어 현재 인터페이스와 의존성을 파악하라. spec.ts에 선언된 타입과 계약이 수정의 출발점이다."불변조건(Invariants):
"수정은 대상 API 디렉토리 내 파일로 한정하라. 다른 디렉토리의 파일을 수정하지 마라. spec.ts에 선언된 타입 계약을 준수하라."후행조건(Postconditions):
"빌드 검증을 실행하라. spec.ts의 인터페이스 선언이 변경된 구현과 일치하는지 확인하고, 불일치 시 spec.ts를 갱신하라."
스킬을 사용하지 않고 직접 수정한 커밋에서 spec-runtime drift가 발생한 사례가 관찰되었으며(5.4절), 이는 스킬 기반 프로세스 거버넌스의 부재가 아키텍처 표류를 가속할 수 있음을 예증한다. api-change, external-change, schema-change 스킬은 여러 모듈에 걸친 조율된 변경을 요구하는 횡단적 수정을 다룬다. 주목할 점은, 이러한 횡단적 스킬조차도 태스크를 디렉토리별 하위 태스크로 분해하여 가능한 한 영향 범위 최소화 원칙을 보존한다는 것이다.
**검증형 스킬(verification skills)**은 아키텍처 표류의 탐지와 수정을 통제한다. sync-contracts 스킬은 AI 에이전트가 spec.ts 선언을 실제 구현 코드와 비교하여 불일치를 표시하도록 지시한다. sync-page-contracts 스킬은 프론트엔드 페이지 계약에 대해 유사한 검사를 수행한다. 이 스킬들은 6절에서 정의하는 계약 완전성(CC)과 명세-런타임 불일치율(SRDR) 메트릭을 조작화한다.
각 스킬은 하나 이상의 AI-Native 원칙의 강제를 인코딩한다. 표 2는 스킬과 스킬이 강제하는 원칙 사이의 매핑을 제시한다.
표 2. 스킬-원칙 강제 매트릭스
| 스킬 | P1: 영향 범위 | P2: 복제 | P3: 제로 컨텍스트 | P4: 계약 | P5: 명세 |
|---|---|---|---|---|---|
| new-api | 강제 | 강제 | 강제 | 강제 | 강제 |
| new-page | 강제 | 강제 | 강제 | 강제 | 강제 |
| modify-api | 강제 | — | 강제 | 검증 | 필수 |
| modify-page | 강제 | — | 강제 | 검증 | 필수 |
| api-change | 부분 | — | 부분 | 갱신 | 필수 |
| external-change | 부분 | — | 부분 | 갱신 | 필수 |
| schema-change | 부분 | — | 부분 | 갱신 | 필수 |
| sync-contracts | — | — | — | 검증 | 검증 |
| sync-page-contracts | — | — | — | 검증 | 검증 |
이 매트릭스에서 "강제(Enforced)"는 스킬의 워크플로우가 원칙 위반을 구조적으로 방지함을, "필수(Required)"는 스킬이 원칙과 관련된 특정 행동(예: 명세 파일 읽기)을 의무화함을, "검증(Verified)"은 스킬이 위반을 탐지하는 검증 단계를 포함함을, "—"는 스킬이 해당 원칙을 직접 다루지 않음을 나타낸다. "부분(Partial)"은 추가 설명을 요한다: 횡단적 스킬(api-change, external-change, schema-change)은 각 하위 태스크 내에서 영향 범위 격리와 제로 컨텍스트를 강제하지만, 태스크 자체는 본질적으로 여러 디렉토리에 걸친다. 예를 들어, schema-change 스킬은 데이터베이스 스키마 수정을 API별 갱신 하위 태스크로 분해하며, 각 하위 태스크는 하나의 디렉토리로 제약되지만—전체 태스크는 정의상 여러 디렉토리에 영향을 미친다. 따라서 원칙은 하위 태스크 수준에서는 강제되지만, 태스크 수준에서는 필연적으로 위반된다.
스킬의 거버넌스 메커니즘은 계약에 의한 설계(Design by Contract) [Meyer, 1992]에서 익숙한 전제 조건-불변 조건-후행 조건 프레임워크를 AI 에이전트 맥락에 적응시켜 형식적으로 특성화할 수 있다.
**전제 조건(preconditions)**은 스킬이 코드 생성을 시작하기 전에 AI 에이전트가 읽어야 하는 파일과 정보이다. 모든 스킬에 걸쳐 가장 핵심적인 전제 조건은 명세 우선(spec-first) 요구사항이다: 에이전트는 구현 파일을 수정하기 전에 대상 모듈의 spec.ts 파일을 읽어야 한다. 이 전제 조건은 에이전트의 컨텍스트가 모듈의 권위 있는 메타데이터로 초기화되도록 보장하며, 원칙 5(AI 작업 기억으로서의 명세)를 직접 지원한다.
**불변 조건(invariants)**은 스킬 실행 전반에 걸쳐 유지되어야 하는 제약이다. 가장 근본적인 불변 조건은 디렉토리 격리이다: 스킬이 명시적으로 디렉토리 간 변경을 인가하지 않는 한, 수정은 대상 디렉토리로 한정되어야 한다. 이 불변 조건은 원칙 1(영향 범위 최소화)을 직접 강제한다. 추가 불변 조건으로는 타입 일관성(수정된 코드가 spec.ts에 선언된 타입에 부합해야 함)과 계약 보존(usedBy 주석이 수정 후에도 정확해야 함)이 포함된다.
**후행 조건(postconditions)**은 스킬이 코드 생성 완료 후 에이전트가 수행해야 하는 검증 단계이다. 이에는 (a) 빌드 검증—수정된 코드가 오류 없이 컴파일/트랜스파일되어야 함, (b) 계약 동기화 확인—인터페이스 변경이 spec.ts에 반영되어야 함, (c) 영향 범위 감사—에이전트가 대상 디렉토리 외부의 파일이 수정되지 않았음을 확인해야 함(단일 모듈 스킬의 경우)이 포함된다.
실행 시나리오 예시: modify-api 스킬. 구체적 작업 흐름을 예시한다. "API-A의 응답에 정렬 기준 필드를 추가하라"는 태스크가 주어지면, AI 에이전트는 다음 단계로 실행한다: (1) 전제 조건—POST_service_a/spec.ts를 읽어 현재 응답 스키마, 외부 API 의존성(externalAPIs), 주의사항(cautions)을 파악한다. (2) 구현—types.ts에 새 필드를 추가하고, service.ts에서 해당 값을 산출하는 로직을 수정하며, handler.ts의 응답 매핑을 갱신한다. 이때 모든 수정은 POST_service_a/ 디렉토리 내로 한정된다(디렉토리 격리 불변 조건). (3) 후행 조건—빌드 검증을 실행하고, spec.ts의 응답 스키마 기술을 갱신하여 명세-런타임 일관성을 보존한다. 이 시나리오는 전제 조건-불변 조건-후행 조건의 세 단계가 원칙 5(명세 우선), 원칙 1(영향 범위 격리), 원칙 4(계약 동기화)를 각각 어떻게 강제하는지 예시한다.
스킬을 통한 프롬프트 기반 거버넌스는 AI 주도 개발을 위한 전통적 정적 분석 대비 여러 이점을 제공한다:
행동적 제약 표현력. 스킬은 정적 분석 규칙으로는 불가능한 제약을 인코딩할 수 있다. "서비스를 수정하기 전에 명세 파일을 읽어라"는 에이전트 행동에 대한 프로세스 제약이지, 코드의 구조적 속성이 아니다. 정적 분석은 명세 파일의 존재를 검증할 수 있지만, 에이전트가 수정을 생성하기 전에 명세를 참조했는지를 강제할 수는 없다.
자연어의 유연성. 자연어로 표현된 아키텍처 규칙은 형식적 제약 언어가 수용할 수 없는 뉘앙스와 맥락을 담을 수 있다. 스킬은 "변경이 응답 스키마에 영향을 미치면, 모든 소비 페이지 명세의 usedBy 주석을 갱신하라"는 것을 명시할 수 있다—정적 규칙으로 인코딩하려면 정교한 프로그램 분석이 필요할 조건적, 의미적 지시이다.
코드베이스와의 공진화. 스킬은 코드베이스나 정적 분석 도구 체인을 수정하지 않고도 아키텍처 패턴이 진화함에 따라 갱신될 수 있다. 이는 아키텍처 규범이 아직 확립 중인 빠르게 진화하는 AI-Native 프로젝트에서 특히 가치 있다.
그러나 프롬프트 기반 거버넌스는 인정해야 할 중요한 한계를 갖는다:
비결정론적 강제. 결정론적 통과/실패 결과를 산출하는 정적 분석과 달리, 프롬프트 기반 거버넌스는 LLM의 확률적 행동을 통해 작동한다. 에이전트는 스킬 지시를 오해하거나, 필수 단계를 건너뛰거나, 위반을 인식하지 못할 수 있다. 따라서 강제는 보장된 것이 아니라 확률적이다.
컴파일 시간 강제 부재. 스킬은 언어 수준이 아닌 워크플로우 수준에서 작동한다. 에이전트가 스킬로 인코딩된 제약을 위반하는 코드를 커밋하는 것을 방지하는 컴파일러 오류에 상응하는 메커니즘이 없다. 위반은 스킬이 명시적 후행 조건 검사를 포함할 때에만 탐지된다.
우회 가능성. AI 에이전트(또는 인간 개발자)가 관련 스킬을 호출하지 않고 태스크를 수행함으로써 스킬을 완전히 우회할 수 있다. 스킬은 가드레일(guardrail)이 아니라 규약(convention)이다. 이 한계는 코딩 표준(권고)과 타입 시스템(강제) 사이의 구분에 대응한다: 스킬은 전자를 제공하지만 후자는 아니다.
준수의 불투명성. 주어진 코드 변경이 관련 스킬에 부합하여 생성되었는지 감사하기 어렵다. 감사 추적(통과/실패 검사)을 남기는 정적 분석과 달리, 스킬 준수는 간접적 증거(예: 갱신된 spec.ts 파일의 존재, 디렉토리 간 수정의 부재)를 통해서만 가시적이다.
이러한 한계는 프롬프트 기반 거버넌스가 전통적 검증 메커니즘의 대체가 아니라 병행 배치되어야 함을 시사한다. 스킬 기반 프로세스 거버넌스와 자동화된 후행 조건 검증의 조합이 어느 한쪽 메커니즘만보다 더 견고한 거버넌스 프레임워크를 제공한다.
보완적 거버넌스 계층(Complementary Governance Layers). 실무적으로 완결된 AI-Native 아키텍처 거버넌스는 세 계층의 상호 보완적 구조를 요구한다. Layer 1(사전 유도): 스킬이 생성 과정을 제약한다—본 논문의 핵심 기여이다. Layer 2(과정 중 검증): CI 가드레일이 생성된 결과물을 자동 검증한다. 두 가지 핵심 예시를 제시한다: (a) 디렉토리 외 변경 감지(cross-boundary change detection)—커밋 훅 또는 CI 파이프라인에서 모듈 디렉토리 경계를 넘는 파일 변경을 자동 탐지하여 리뷰 플래그를 부여하며, 원칙 1(영향 범위 최소화)의 런타임 강제 장치로 기능한다. (b) spec drift fail-fast 검사—빌드 타임에 spec 파일과 실제 export/타입 간 구조적 불일치를 검출하여 빌드 실패 처리하며, 원칙 5(AI 작업 기억으로서의 명세)의 런타임 강제 장치로 기능한다. Layer 3(사후 측정): 메트릭(BRI, ZCS, CC, SRDR)이 아키텍처 적합도를 주기적으로 산출한다—본 논문의 또 다른 핵심 기여이다. 본 논문의 핵심 기여는 Layer 1과 Layer 3이지만, 실무 완결성을 위해 Layer 2의 개요와 핵심 예시를 포함하였다.
본 절에서는 다섯 가지 AI-Native 아키텍처 원칙이 도출된 프로덕션 전자상거래 이벤트 애플리케이션 대상 프로젝트에 대한 상세 사례 연구를 제시한다. 프로젝트 맥락(5.1절), 역공학 방법론(5.2절), 원칙별 달성도 측정(5.3절), 식별된 문제와 아키텍처적 긴장(5.4절), 개발 과정에서 관찰된 이중 구조 AI에 대한 관찰(5.5절)을 기술한다.
대상 프로젝트는 대형 전자상거래 플랫폼을 위한 AI 개인화 이벤트 서비스로, 성향 테스트 기반 AI 상품 추천과 캐릭터 이미지 생성 기능을 제공하는 조직 내부 PoC이다. 이 애플리케이션은 인간 아키텍트의 지휘 하에 Claude 기반 AI 에이전트가 주요 코드 작성자로 기능하는 AI 에이전트 중심 워크플로우로 개발되었다.
기술적 특성:
이 프로젝트는 시간 제한적 이벤트 애플리케이션이라는 특정 범주의 소프트웨어를 대표하며, 적당한 복잡성, 잘 정의된 기능 세트, 소규모 개발 팀(한 명의 인간 아키텍트와 AI 에이전트)을 갖는다. 이 맥락은 본 사례 연구에서 도출된 원칙의 적용 가능성과 한계를 이해하는 데 중요하다(타당도에 대한 위협은 8절 참조).
다섯 가지 AI-Native 원칙은 사전(a priori)에 설계된 것이 아니라, 프로젝트 완료 후 대상 프로젝트 코드베이스의 체계적 역공학을 통해 도출되었다. 분석은 세 축 방법론을 따랐다:
축 1: 코드베이스 구조 분석. 전체 코드베이스에 걸쳐 디렉토리 구조, 파일 조직 패턴, 의존성 관계를 체계적으로 검토하였다. 이 분석은 기능 기반 디렉토리 조직, 복제된 유틸리티 파일의 패턴, 모듈 진입점으로서의 spec.ts 파일의 존재를 드러내었다. 정량적 측정에는 디렉토리 수, 디렉토리당 파일 수, 디렉토리 간 임포트 빈도, 복제된 파일 식별이 포함되었다.
축 2: 개발 워크플로우 재구성. AI 에이전트의 스킬 정의를 분석하고, git 커밋 이력을 검토하여 개발 활동의 시간적 순서를 파악하며, 인간 아키텍트의 설계 문서(Confluence 페이지)를 검토하여 개발 워크플로우를 재구성하였다. 이 축은 스킬 기반 거버넌스 메커니즘과 명세 우선 개발 패턴을 드러내었다.
축 3: 원칙 추출 및 검증. 축 1과 2에서 식별된 패턴으로부터, 분석적 일반화(analytical generalization) [Yin, 2018] 과정을 통해 후보 아키텍처 원칙을 추출하였다. 각 후보 원칙은 세 가지 기준에 대해 검증되었다: (a) 관찰 가능성(observability)—원칙이 단순히 의도된 것이 아니라 코드베이스 구조에서 나타나야 함, (b) 동기 부여(motivation)—원칙이 하나 이상의 LLM 인지 특성으로 추적 가능해야 함, (c) 차별성(distinctiveness)—원칙이 기존 소프트웨어 공학 원칙으로부터의 이탈 또는 정제를 나타내야 함. 다섯 가지 원칙이 세 가지 기준 모두를 충족하였으며 3절에서 제시되었다.
다섯 가지 원칙 각각에 대해, 6절에서 정의하는 메트릭을 사용하여 달성도를 측정하였다(여기서는 요약 형태로 제시하며, 전체 메트릭 정의는 6절에 후술한다).
측정 절차. 모든 측정은 제1저자가 코드베이스와 git 이력의 수동 분석을 통해 수행하였으며, 의존성 추출과 diff 분석을 위한 자동화 스크립트로 보완하였다. 재현 가능성을 보장하기 위해, 아래에 각 메트릭의 구체적 절차를 기술한다. 단일 평가자 측정이 주관성 위험을 도입함을 인정하며, 본 연구의 다중 사례 확장에서 평가자 간 신뢰도(inter-rater reliability) 평가를 계획하고 있다.
스킬 사용 커밋 식별 기준. 스킬 기반 거버넌스의 간접적 효과를 분석하기 위해, 스킬을 통해 생성된 커밋과 그렇지 않은 커밋을 구분하는 조작적 기준을 정의하였다. 1차 식별자는 커밋 메시지이다: 스킬 호출을 통해 생성된 커밋은 특정 메시지 패턴(스킬명 포함 또는 에이전트 자동 생성 형식)을 따르며, 해당 패턴과 일치하는 커밋을 "스킬 사용 커밋"으로 분류하였다. 2차 식별자는 에이전트 세션 로그이다: 커밋 메시지만으로 판별이 모호한 경우, 스킬 호출 기록과 커밋 타임스탬프를 대조하여 확인하였다. 두 식별자 모두로 판별 불가한 커밋은 "미분류"로 처리하고 분석에서 제외하였으며, 미분류 비율을 함께 보고하여 투명성을 확보하였다.
원칙 1: 영향 범위 최소화 (BRI = 1.05, 달성도: 95%). 전체 git 커밋 이력(총 142개 커밋)을 분석하여, 병합 커밋, 문서 전용 변경, 설정 파일 갱신을 제외하고 뚜렷한 기능 수준 변경을 나타내는 60개 커밋을 선정하였다. 선정 기준은 조작적이었다: API 또는 페이지 디렉토리의 TypeScript 소스 파일을 최소 하나 수정한 커밋이 포함되었다. 선정된 각 커밋에 대해, 수정된 파일을 포함하는 서로 다른 기능 디렉토리의 수를 집계하였다. 분석된 60개 커밋 중 57개가 단일 디렉토리 내의 파일만 수정하였다(BRI = 1.0). 세 가지 예외는: (a) 공유 미들웨어 디렉토리와 하나의 API 디렉토리에 변경이 필요한 전역 인증 미들웨어 갱신, (b) 스키마 디렉토리와 두 개 API 디렉토리에 영향을 미친 데이터베이스 스키마 마이그레이션, (c) API 간 데이터 파이프라인 수정이었다. 결과적 평균 BRI 1.05는 이상적 값 1.0에 근접한다.
원칙 2: 의도적 복제 (DIR = 0.35, 달성도: 90%). API 디렉토리에 걸쳐 복제된 model-client.ts 유틸리티의 여섯 개 사례를 식별하였다. 쌍별 diff 분석 결과 평균 코드 분기율 35%(DIR = 0.35)를 보여, 복사본들이 엔드포인트별 설정으로 독립적으로 진화하였음을 나타내었다. model-client.ts 외에도 image-client.ts(3개), vlm-client.ts(3개), catalog-client.ts(2개)를 포함하여 4개 클라이언트 유형에 걸친 총 14개 의도적 복제 인스턴스가 식별되었으며, 전체 공통 스켈레톤 비율은 평균 27.6%, 비즈니스 특화 고유 로직은 72.4%로 측정되었다. 분기는 프롬프트 내용, 토큰 예산, 에러 처리 전략, 응답 후처리, 입출력 타입의 5개 차원에서 체계적으로 발생하였다 [T3]. 13개 API 디렉토리 중 12개가 필요한 모든 유틸리티 코드를 지역적으로 포함하였으며, 하나의 API 디렉토리가 공유 인증 모듈에 의존하여 10%의 미달성을 나타내었다.
원칙 3: 제로 컨텍스트 (ZCS = 0.75, 달성도: 75%). ZCS를 조작화하기 위해 AI 에이전트(Claude 3.5 Sonnet)에게 API 엔드포인트당 하나의 대표적 수정 태스크를 수행시켜 총 13회 시행하였다. 각 태스크는 단일 필드 추가: 기존 API에 새 응답 필드를 추가하는 것으로, 에이전트가 현재 데이터 스키마를 이해하고, 서비스 로직을 수정하며, 라우트 핸들러를 갱신해야 하였다. 에이전트는 대상 디렉토리 내의 파일만 읽도록 제약되었다(디렉토리 외부 파일 접근 불가). 태스크는 생성된 코드가 오류 없이 컴파일되고 올바른 응답을 생성하면 성공(ZCS = 1)으로, 에이전트가 외부 파일을 요구하거나 누락된 컨텍스트로 인해 부정확한 코드를 생성하면 실패(ZCS = 0)로 평가되었다. 에이전트는 13개 API 중 10개에 대해 외부 컨텍스트 없이 태스크를 성공적으로 완료하였다. 세 건의 실패는: 공유 미들웨어 로직에 의존하는 API, 상위 데이터 파이프라인에 대한 이해가 필요한 API, 전역 기능 플래그에 의해 행동이 조건부로 수정되는 API와 관련되었다.
원칙 4: 메타데이터로서의 계약 (CC = 0.70, 달성도: 70%). 각 spec.ts 파일을 수동 감사하여, 선언된 의존성과 인터페이스 계약을 정적 임포트 분석과 동적 호출 추적을 통해 식별한 실제 런타임 의존성과 비교하였다. 전체 모듈에 걸친 47개 실제 외부 의존성 중 33개가 spec.ts 파일에 정확히 선언되었다(CC = 0.70). 선언되지 않은 14개 의존성은 세 범주로 분류되었다: 전이적 미들웨어 의존성(6개), 기능 플래그 조건부 통합(4개), 명세가 오래된 최근 추가 통합(4개).
원칙 5: AI 작업 기억으로서의 명세 (SRDR = 0.23, 달성도: 40%). 명세 범위(Spec Coverage)와 명세-런타임 불일치율 모두를 측정하였다. 명세 범위는 평균 55%로—명세가 데이터 타입과 주요 인터페이스는 기술하였으나 행동적 제약, 오류 처리 명세, 성능 요구사항은 누락하였다. SRDR은 0.23으로, 명세 파일에 선언된 사실의 23%가 현재 구현 대비 부정확하였음을 의미한다. 40%의 결합 달성도는 명세 파일 중 절반 미만만이 AI 에이전트의 신뢰할 수 있는 작업 기억 초기화로 기능하기에 충분히 완전하고 정확하다는 평가를 반영한다.
표 3. 대상 프로젝트 원칙 달성도 요약
| 원칙 | 주요 메트릭 | 이상적 값 | 관찰 값 | 달성도 |
|---|---|---|---|---|
| P1: 영향 범위 최소화 | BRI | 1.0 | 1.05 | 95% |
| P2: 의도적 복제 | DIR | 0.2–0.5 | 0.35 | 90% |
| P3: 제로 컨텍스트 | ZCS | 1.0 | 0.75 | 75% |
| P4: 메타데이터로서의 계약 | CC | 1.0 | 0.70 | 70% |
| P5: AI 작업 기억으로서의 명세 | SRDR | 0.0 | 0.23 | 40% |
| 전체 평균 | — | — | — | 74% |
간접 준수 지표. 스킬 기반 거버넌스의 효과를 간접적으로 평가하기 위해 두 가지 산출 가능한 프록시 지표를 제안한다. 첫째, modify-api 스킬 사용 커밋 중 spec.ts가 함께 갱신된 비율은 명세 우선 준수의 프록시로 기능할 수 있다. 둘째, 단일 모듈 스킬(modify-api, modify-page) 사용 커밋 중 단일 디렉토리만 수정된 비율은 격리 불변 조건 준수의 프록시로 기능할 수 있다. 본 연구에서는 커밋 메시지 패턴과 에이전트 세션 로그의 체계적 대조가 완료되지 않아 구체적 수치를 보고하지 못하며, 이 지표의 실제 산출과 해석은 향후 연구 과제로 남긴다.
운영 지표 관찰(Operational Observations). 달성도 메트릭 외에, git 이력으로부터 운영 수준의 지표를 관찰하였다. BRI 데이터를 재해석하면, 변경의 95%가 단일 디렉토리 내에서 완결되었다—이는 AI 에이전트의 변경 범위가 아키텍처 의도에 부합함을 나타내는 운영 지표이다. 또한 new-api 스킬 사용 커밋 간 시간 간격으로부터 새 API 엔드포인트의 평균 추가 시간을 추후 추출 가능한 운영 지표로 식별하였다. 다만, 비교 대조군(AI-Native 원칙 미적용 프로젝트)이 부재하므로 이 관찰은 절대적 효과 측정이 아닌 탐색적 기술임을 명시적으로 인정한다.
역공학 분석은 AI-Native 아키텍처에 내재한 긴장을 조명하는 여러 문제를 드러내었다.
카탈로그 API 표류(catalog-API drift). 하나의 API 엔드포인트(광범위한 영향 범위로 인해 개발 팀이 내부적으로 주의 대상으로 지정)는 시간에 따라 모듈 간 의존성이 점증하는 패턴을 보였다. 초기에는 단일 디렉토리 격리 패턴에 부합하였으나, 비즈니스 로직이 복잡해지면서 다른 모듈의 데이터 모델과 유틸리티 함수에 대한 참조가 점진적으로 누적되었다. 이 API의 영향 범위는 초기 구현의 1개 디렉토리에서 프로젝트 종료 시 4개 디렉토리로 확대되었으며, 이는 영향 범위 격리가 기능이 진화함에 따라 자동으로 보존되지 않으며 지속적인 경계가 필요함을 보여 준다.
명세-런타임 표류의 가속. 예상치 못한 발견은 명세-런타임 표류가 프로젝트 생명주기에 걸쳐 가속되었다는 것이다. 개발 초기, 기능이 생성되던 시기(대개 new-api 스킬 사용)에는 명세가 구현 코드와 함께 생성되어 높은 정확도를 보였다. 프로젝트가 수정 및 반복 단계에 진입하면서, 구현 변경이 해당 명세 갱신 없이 빈번하게 이루어졌다. modify-api 스킬을 호출하는 AI 에이전트는 지시대로 명세를 먼저 읽었으나—읽은 명세가 점점 더 진부해졌다. 이는 역설적 상황을 초래하였다: 거버넌스 메커니즘(명세 우선 읽기)은 충실히 준수되었으나, 통제 대상인 결과물(명세)이 저하되어, 오래된 가정에 기반한 코드 생성으로 이어졌다.
복잡한 파이프라인의 제로 컨텍스트 압박. 세 개의 API 엔드포인트가 하나의 API 출력이 다른 API의 입력으로 기능하는 다단계 데이터 파이프라인에 참여하였다. 이 엔드포인트들에 대해 진정한 제로 컨텍스트는 달성 불가능하였다: 데이터 형식을 이해하기 위해 다른 디렉토리에 정의된 상위 변환에 대한 지식이 필요하였다. 이 관찰은 제로 컨텍스트 원칙이 순차적 의존성이 환원 불가능한 모듈 간 정보 요구사항을 생성하는 데이터 파이프라인 아키텍처에서 내재적 한계를 갖는다는 것을 시사한다.
복제 동기화 격차. 여섯 개의 복제된 model-client.ts 파일이 (의도대로) 독립적으로 진화하였으나, 하나의 복사본에서 중요 버그 수정이 다른 복사본에 전파되지 않은 사례가 발견되었다. 잘못된 재시도 백오프 계산이라는 버그가 최초 발견된 API 디렉토리에서는 수정되었으나, 수동 감사가 이를 탐지하기까지 2주간 나머지 다섯 개 복사본에 잔존하였다. 3.2절의 권장 동기화 주기 기준에 비추어 재평가하면, 관찰된 2주 지연은 인프라 유틸리티 범주에서는 허용 범위이나, 해당 코드가 보안 관련 로직을 포함했다면 권장 주기 초과에 해당한다. 이 관찰은 세 가지 완화 메커니즘의 필요성을 시사한다: (a) 복제 파일 간 의미적 diff를 탐지하는 sync-duplicates 검증 스킬, (b) git hook 기반 복제 파일 변경 알림, (c) 어떤 파일이 어디서 복제되었는지 추적하는 복제 레지스트리 메타데이터. 이 사건은 의도적 복제가 아키텍처적으로 정당화된 경우에도 도입하는 유지보수 위험과, 이를 체계적으로 관리할 자동화 도구의 필요성을 예증한다.
사례 연구에서 예상치 못한 발견은 원래 설계 의도에 포함되지 않았던 이중 구조 AI 아키텍처의 출현이었다.
레벨 1: 서비스 AI. 대상 프로젝트 애플리케이션 자체가 런타임 기능의 일부로 LLM 기반 AI를 사용한다—개인화된 상품 추천 생성, AI 기반 캐릭터 이미지 생성, 성향 분석 결과 해석. 이것은 LLM API 호출이 애플리케이션의 서비스 로직에 내장된 "제품 내 AI(AI in the product)" 계층이다.
레벨 2: 개발 AI. 이와 별도로, 애플리케이션은 주요 코드 작성자로서 AI 에이전트(Claude)를 사용하여 개발되었다. 이것은 LLM이 애플리케이션의 소스 코드를 생성하고 수정하는 "개발자로서의 AI(AI as the developer)" 계층이다.
이 이중 구조의 아키텍처적 함의는 주목할 만하다. 대상 프로젝트의 spec.ts 파일은 이중 목적을 수행하였다: 개발 AI를 위한 API 인터페이스 문서화(원칙 5 지원)와 함께 서비스 AI가 사용하는 LLM 프롬프트 템플릿 정의(런타임 기능 지원). 이 이중 역할은 아키텍처 거버넌스와 런타임 행동 사이의 결합을 생성하였다—거버넌스 목적의 명세 변경이 애플리케이션의 런타임 LLM 상호작용에 의도치 않게 영향을 미칠 수 있었고, 그 반대도 마찬가지였다.
이 이중 목적 결합이 원칙 5(AI 작업 기억으로서의 명세, 40%)의 낮은 달성률에 기여했을 수 있다. spec.ts가 개발 AI를 위한 거버넌스 메타데이터와 서비스 AI를 위한 런타임 결과물 모두로 기능할 때, 런타임 요구사항에 의해 동기 부여된 수정(예: 더 정확한 추천 결과를 위한 LLM 프롬프트 템플릿 조정)이 개발 거버넌스 관점에서 명세-런타임 표류를 도입할 수 있었고, 그 반대도 마찬가지였다. 두 역할의 경쟁적 요구가 어느 목적으로든 명세를 신뢰할 수 있는 진실 원천으로 유지하기 어렵게 만들었다.
나아가, 서비스 AI의 복잡도가 개발 AI를 위한 아키텍처 원칙의 달성도를 제약할 수 있다는 잠정적 관찰이 있었다. 복합 생성 API는 VLM 다회 병렬 호출, LLM 통합 생성, ImageGen 최종 생성의 3단계 파이프라인으로 구성되어, 단일 디렉토리 내에 pipeline.ts, prompt-builder.ts, vlm-client.ts, model-client.ts, image-client.ts 등 10개 이상의 파일이 요구되었다. 이 서비스 AI 파이프라인의 내재적 복잡도가 제로 컨텍스트 원칙의 달성을 저해하는 요인으로 작용하였으며—ZCS를 75%로 제한한 세 건의 실패 중 하나가 이 API에서 발생하였다. 이는 단일 사례에서의 잠정적 관찰이지만, 서비스 AI의 복잡도와 개발 AI를 위한 아키텍처 적합도 사이에 역관계가 존재할 가능성을 제기한다.
이 관찰은 AI가 동시에 제품과 개발 프로세스에 내장됨에 따라, 두 AI 계층의 분리(또는 의도적 통합)를 둘러싼 새로운 유형의 아키텍처적 관심사가 대두됨을 시사한다. 잠정적 분리 전략으로 세 가지 방향이 식별된다: (a) spec.ts의 개발용 섹션과 런타임용 섹션의 명시적 분리(섹션 마커 또는 파일 분할), (b) 런타임 프롬프트 템플릿을 별도 파일로 분리하고 spec.ts는 개발 거버넌스 전용으로 유지, (c) 하나에서 다른 하나를 자동 생성하는 빌드 타임 파이프라인. 위 분리 전략의 검증을 포함한 향후 조사 영역으로 기록한다.
3절에서 제시한 다섯 가지 원칙은 아키텍처 적합도의 객관적 측정을 가능하게 하는 정량적 메트릭을 필요로 한다. 본 절에서는 원칙당 하나의 주요 메트릭으로 다섯 가지 메트릭을 정의하며, 각각의 조작적 측정 절차, 해석 기준, 이상적 값, 알려진 한계를 명시한다.
정의. ZCS는 코드베이스의 기능 모듈 중 AI 에이전트가 모듈 디렉토리 내의 파일만을 사용하여 대표적 수정 태스크를 완료할 수 있는 비율을 측정한다.
측정 절차. (1) 코드베이스의 모든 기능 디렉토리 *D(F_1), ..., D(F_n)*을 열거한다. (2) 각 기능 F_i에 대해 대표적 수정 태스크 T_i를 정의한다—기능의 데이터 모델, 서비스 로직, 인터페이스에 대한 이해를 요구하는 중간 복잡도의 태스크(예: 응답 필드 추가, 유효성 검사 규칙 수정, 데이터 변환 변경). (3) AI 에이전트에게 *files(D(F_i))*만 접근 가능하도록 제한하여 T_i를 완료하도록 지시한다. (4) 에이전트가 올바르고 컴파일 가능한 수정을 산출하면 ZCS(F_i) = 1, 그렇지 않으면 ZCS(F_i) = 0으로 평가한다. (5) *ZCS(C) = (1/n) × Σ ZCS(F_i)*를 산출한다.
해석. ZCS(C) = 1.0은 완벽한 제로 컨텍스트를 나타낸다: 모든 기능이 완전히 자기 완결적이다. 1.0 미만의 값은 외부 컨텍스트를 필요로 하는 기능의 존재를 나타낸다. 대상 프로젝트에서 관찰된 0.75의 점수는 기능 네 개 중 하나가 환원 불가능한 외부 의존성을 가짐을 나타낸다.
이상적 값. 1.0 (모든 기능이 자기 완결적).
한계. ZCS는 대표적 태스크의 선택에 민감하다—사소한 태스크(예: 문자열 상수 변경)는 격리가 미흡한 모듈에서도 ZCS = 1을 달성할 수 있고, 과도하게 복잡한 태스크는 격리와 무관한 이유로 실패할 수 있다. 메트릭은 또한 사용된 AI 에이전트에 따라 달라지는데, 모델마다 컨텍스트 활용 능력이 상이하기 때문이다. 중간 복잡도의 태스크를 사용하고 에이전트 모델 및 버전을 ZCS 값과 함께 보고할 것을 권장한다.
실무 근사 측정. 디렉토리 외부 임포트 비율(External Import Ratio, EIR = 디렉토리 외부 임포트 수 / 전체 임포트 수)을 실무 환경에서 즉시 활용 가능한 독립적 지표로 제안한다. EIR은 정적 분석으로 즉시 산출 가능하며, CI 파이프라인에 통합하여 자동 추적할 수 있다. EIR은 ZCS의 완전한 대체가 아니라 그 자체로 유의미한 실무 지표이다—EIR이 낮은 모듈은 외부 의존성이 적어 AI 에이전트의 지역적 수정에 유리하다. 정밀 메트릭(ZCS)과의 상관 검증은 향후 연구 과제이다.
정의. BRI는 변경 태스크당 영향받는 디렉토리의 평균 수를 측정하며, 아키텍처가 달성한 변경 격리의 정도를 반영한다.
측정 절차. (1) 분석 기간의 git 커밋 이력을 추출한다. (2) 기능 수준 변경을 나타내는 커밋만 포함하도록 필터링한다(병합, 문서, 설정 전용 커밋 제외). (3) 적격한 각 커밋 T_j에 대해, 수정된 소스 파일을 포함하는 서로 다른 기능 디렉토리의 수를 집계한다: blast_radius(T_j). (4) *BRI(C) = (1/m) × Σ blast_radius(T_j)*를 산출한다, 여기서 m은 적격 커밋의 수이다.
해석. BRI = 1.0은 완벽한 영향 범위 격리를 나타낸다: 모든 변경이 단일 디렉토리에 한정된다. 1.0 이상의 값은 디렉토리 간 영향의 평균 정도를 나타낸다. 대상 프로젝트에서 관찰된 BRI = 1.05는 대다수의 변경이 단일 디렉토리이며 드문 예외가 있음을 나타낸다.
이상적 값. 1.0 (모든 변경에 대한 단일 디렉토리 격리). BRI는 git log --stat 파싱 스크립트로 자동 산출 가능하며, 제안된 메트릭 중 자동화 비용이 가장 낮다.
한계. BRI는 커밋 세분성(granularity)에 영향을 받는다—원자적 커밋(커밋당 하나의 논리적 변경)을 하는 개발자는 여러 변경을 묶는 개발자와 다른 BRI 값을 산출한다. BRI는 또한 필연적인 디렉토리 간 변경(예: 본질적으로 여러 모듈에 영향을 미치는 스키마 마이그레이션)과 회피 가능한 변경을 구분하지 못한다. 5.3절에 기술한 것처럼 문서화된 커밋 선정 기준과 함께 BRI를 산출할 것을 권장한다.
정의. DIR은 의도적으로 복제된 코드가 모듈에 걸쳐 독립적으로 진화한 정도를 측정하며, 이를 통해 복제의 격리 목적을 사후 검증한다.
측정 절차. (1) 코드베이스에서 복제된 파일의 모든 집합을 식별한다—공통 원본을 공유하지만 서로 다른 기능 디렉토리에 상주하는 파일. (2) 각 복제 집합 *{U_1, ..., U_k}*에 대해, diff 기반 메트릭을 사용하여 쌍별 코드 유사도를 산출한다: similarity(U_i, U_j) = 1 − (edit_distance(U_i, U_j) / max(|U_i|, |U_j|)). (3) 집합의 분기도를 산출한다: divergence = 1 − mean(similarity(U_i, U_j)) (모든 쌍에 대해). (4) 모든 복제 집합에 걸쳐 *DIR(C) = mean(divergence)*를 산출한다.
해석. DIR = 0은 모든 복제 파일이 동일함을 나타낸다(독립적 진화 없음, 복제가 불필요할 수 있음을 시사). DIR > 0.3은 의미 있는 독립적 진화를 시사하여 격리 목적을 검증한다. 매우 높은 DIR 값(> 0.7)은 파일들이 의미 있게 "복제된" 것이 아니라 역사적 원본을 공유할 뿐인 독립적으로 개발된 모듈임을 나타낼 수 있다.
이상적 값. 맥락 의존적. [0.2, 0.5] 범위의 DIR은 건전한 의도적 복제를 시사한다—격리를 정당화하기에 충분한 분기이면서, 공유 아키텍처 패턴을 나타내기에 충분한 공통성을 유지. 0에 가까운 값은 불필요한 복제를, 1.0에 가까운 값은 "복제"라는 라벨이 더 이상 적절하지 않음을 시사한다.
한계. DIR은 회고적 메트릭이다—복제가 정당화되었는지를 사후에 측정하며, 복제 결정 시점에서의 정확성을 측정하지 않는다. DIR이 0이라도 반드시 복제가 잘못되었음을 의미하지 않는다; 복사본이 단지 아직 분기할 기회가 없었을 수 있다. 또한 DIR은 차이의 의미적 중요성을 고려하지 않는다—단일 행의 설정 변경이 대규모 코드 재서식화보다 아키텍처적으로 더 유의미할 수 있다.
정의. CC는 각 모듈의 디렉토리 내에 계약 메타데이터로서 명시적으로 선언된 실제 외부 의존성의 비율을 측정한다.
측정 절차. (1) 각 모듈 M에 대해, 정적 임포트 분석(외부 모듈을 참조하는 모든 임포트 문 추출)과 런타임 의존성의 수동 식별(API 호출, 데이터베이스 쿼리, 외부 서비스 호출)을 조합하여 실제 외부 의존성의 집합 *deps(M)*을 열거한다. (2) 모듈의 명세 파일(예: spec.ts)을 파싱하여 선언된 계약의 집합 *contracts(M)*을 열거한다. (3) *CC(M) = |contracts(M) ∩ deps(M)| / |deps(M)|*를 산출한다. (4) *CC(C) = (1/n) × Σ CC(M_i)*를 산출한다.
해석. CC = 1.0은 모든 외부 의존성이 모듈의 계약 메타데이터에 명시적으로 선언되었음을 나타낸다. 1.0 미만의 값은 선언되지 않은 의존성을 나타낸다—AI 에이전트가 외부 인터페이스에 대한 부정확한 가정으로 코드를 생성할 수 있게 하는 메타데이터의 공백.
이상적 값. 1.0 (모든 의존성이 선언됨).
한계. CC는 "외부 의존성"의 정의에 의존하며, 이는 좁은 범위(서비스 간 API 호출만)에서 넓은 범위(모듈 디렉토리 외부로부터의 모든 임포트)까지 다양할 수 있다. 메트릭은 또한 세분성에 민감하다: 외부 모듈에서 임포트된 각 개별 함수를 별도 의존성으로 집계할 것인가, 아니면 모듈 수준 의존성을 하나로 집계할 것인가? 모듈 수준 의존성 집계를 사용하고 사용된 의존성 정의를 문서화할 것을 권장한다.
정의. SRDR은 모듈의 명세 파일에 선언된 사실 중 현재 런타임 구현 대비 부정확한 비율을 측정하며, 명세와 코드 사이의 표류 정도를 반영한다.
측정 절차. (1) 각 모듈 M에 대해, *spec(M)*의 모든 사실적 주장—타입 정의, 인터페이스 서명, 의존성 선언, 행동적 제약—을 열거한다. 이 집합을 *facts(spec(M))*으로 표기한다. (2) *facts(spec(M))*의 각 사실 f에 대해, 대응하는 소스 파일을 검토하여 f가 현재 구현과 일관적인지 검증한다. (3) 각 사실을 정확(accurate)(구현과 일관) 또는 표류(drifted)(불일관)로 분류한다. (4) *SRDR(M) = |drifted facts| / |facts(spec(M))|*를 산출한다. (5) *SRDR(C) = (1/n) × Σ SRDR(M_i)*를 산출한다.
해석. SRDR = 0은 완벽한 명세-런타임 일관성을 나타낸다. 높은 값은 더 큰 표류를 나타낸다. 대상 프로젝트에서 관찰된 SRDR = 0.23은 명세 주장 중 약 4분의 1이 부정확하였음을 의미하며—AI 에이전트가 컨텍스트 로딩의 약 4분의 1에서 부정확한 가정에 기반하여 코드를 생성할 수 있는 수준의 표류이다.
이상적 값. 0.0 (표류 없음).
한계. SRDR은 측정에 가장 많은 노동력을 요하는 메트릭으로, 명세 주장과 구현 코드의 수동 비교가 필요하다. 이 측정의 자동화는 구조적 사실(타입 서명, 함수 파라미터)에 대해서는 가능하지만, 행동적 사실(비즈니스 규칙, 오류 처리 정책)에 대해서는 여전히 도전적이다. 메트릭은 또한 사실 단위로 이진적(정확 또는 표류)이어서, 표류의 심각도에 대한 뉘앙스를 상실한다—사소한 타입 주석 불일치가 근본적으로 부정확한 인터페이스 선언과 동일한 가중치를 받는다.
실무 근사 측정. 구조적 사실(타입 서명, 함수 파라미터)은 spec.ts의 TypeScript 타입 정의와 실제 export 타입의 AST 비교로 자동 탐지 가능하며, 이를 통해 행동적 사실의 수동 감사 범위를 축소할 수 있다.
다섯 가지 메트릭은 독립적이지 않다. BRI와 DIR은 공동으로 기초 계층(원칙 1, 2)의 효과성을 나타내고, ZCS는 창발 계층(원칙 3)의 집계 지표로 기능하며, CC와 SRDR은 향상 계층(원칙 4, 5)을 평가한다. BRI가 높고(1.0에 근접) DIR이 높지만(0.3 이상) ZCS가 낮은 코드베이스는 영향 범위 격리와 복제가 존재하지만 다른 요인(공유 미들웨어, 전역 설정)이 제로 컨텍스트를 저해함을 나타낼 수 있다. 낮은 SRDR과 높은 CC의 조합은 잘 유지된 계약 메타데이터 계층을 나타내며, CC와 무관하게 높은 SRDR은 체계적 명세-런타임 표류를 나타낸다.
2-tier 측정 전략. 실무 도입을 위해, 메트릭을 자동화 가능성에 따라 두 단계로 구분하는 측정 전략을 제안한다. Tier 1(CI 통합, 자동): BRI(git log 파싱), EIR(정적 임포트 분석), CC 근사(spec 파일 존재 여부 + 외부 임포트 대비 선언 비율), DIR(파일 해시 비교 + diff 라인 수), SRDR 구조적 근사(spec.ts 타입 정의와 실제 export 타입의 AST 비교)—이들은 CI 파이프라인에 통합하여 매 빌드 시 자동 산출 가능하다. Tier 2(주기적 감사, 반자동): ZCS(샌드박스 AI 시행), SRDR 행동적 사실(비즈니스 규칙·오류 처리 정책의 수동 감사)—이들은 스프린트 또는 릴리즈 주기에 맞춰 주기적으로 측정한다. Tier 1 측정만으로도 아키텍처 준수 여부의 실무적 판단이 가능하며, Tier 2는 더 깊은 품질 감사에 활용된다.
**AI-Native 아키텍처 적합도 지수(AI-Native Architecture Conformance Index, ANACI)**를 가중 합산으로 제안한다: ANACI = w_1 × BRI_norm + w_2 × DIR_norm + w_3 × ZCS + w_4 × CC + w_5 × (1 − SRDR), 여기서 *BRI_norm = max(0, 2 − BRI)*는 BRI 기여를 [0, 1]로 클램핑하며(이상적 BRI = 1.0에서 1.0을, BRI ≥ 2.0에서 0.0을 산출), DIR_norm은 DIR을 이상적 범위 [0.2, 0.5]에 기반하여 [0, 1]로 정규화하고, w_1, ..., w_5는 합이 1인 가중치이다. max(0, 2 − BRI) 정규화는 역수 변환의 수치적 불안정성을 피하면서 선형적이고 해석 가능한 매핑을 제공한다: 평균 영향 범위의 추가 디렉토리 하나가 BRI 기여를 1.0씩 감소시킨다. 특정 가중치를 처방하지 않으며, 이는 원칙들 사이의 조직의 우선순위를 반영해야 한다. 대상 프로젝트 사례에서 등가중 ANACI는 약 0.76을 산출한다.
본 절에서는 AI-Native 아키텍처 원칙의 광범위한 함의를 검토하며, 적용 가능 조건, 기존 원칙과의 관계, 경제적 고려사항, 한계를 다룬다.
다섯 가지 AI-Native 원칙은 특정 프로젝트 맥락—적당한 복잡성의 시간 제한적 이벤트 애플리케이션, 단일 인간 아키텍트와 AI 에이전트에 의한 개발—으로부터 도출되었다. 이 원칙이 유익할 가능성이 높은 조건과 부적용 또는 역효과를 낳을 수 있는 조건을 구분하는 것이 필수적이다.
유리한 조건. 이 원칙은 다음 특성을 보이는 프로젝트에 가장 적용 가능하다: (a) AI 에이전트가 코드의 대부분을 생성하고 인간이 아키텍트 및 리뷰어로 기능하는 AI 주도 개발(AI-primary development), (b) 시스템이 한정된 인터페이스를 가진 상대적으로 독립적인 기능 모듈로 조직될 수 있는 기능 기반 분해 가능성(feature-based decomposability), (c) 기능 모듈의 수가 수십에서 수백 저반 범위에 있어 복제 전략이 관리 가능한 적당한 규모(moderate scale), (d) 모듈 간 조율 비용이 빈번한 변경에 의해 증폭되는 빠른 반복 주기(rapid iteration cadence).
서비스 아키텍처 조건. 대상 프로젝트는 데이터베이스 중심(DB-centric)이 아닌 AI API 중심(AI-API-centric) 구조였다—핵심 로직이 LLM/VLM/ImageGen API 호출의 오케스트레이션이고, DB는 경량 저장만 담당하였다. 데이터베이스 트랜잭션과 정합성 제약이 모듈 간 결합의 주요 원인인 DB 중심 시스템에서는 디렉토리 격리가 제약될 수 있어, DB 중심 시스템에의 적용 가능성은 추가 조사가 필요하다.
불리한 조건. 이 원칙은 다음에 덜 적용 가능하다: (a) 수백 개의 밀결합(tightly coupled) 서비스를 가진 대규모 엔터프라이즈 시스템으로, 복제 전략(원칙 2)이 감당 불가능한 동기화 오버헤드를 생성할 수 있는 경우, (b) 공유 코드의 일관성 보장이 필수적이고 AI 생성 코드의 확률적 특성이 허용 불가능한 안전 핵심 시스템(safety-critical systems), (c) AI가 주요 작성자가 아닌 보조 도구로 기능하여 LLM 컨텍스트 최적화보다 인간 인지 최적화가 더 관련성 높은 인간 주도 개발(human-primary development), (d) 깊은 추상화 계층이 표현력의 손실 없이 평탄화될 수 없는 진정한 도메인 복잡성을 반영하는 알고리즘적으로 복잡한 도메인.
기존 코드베이스에의 점진적 도입. 권장 시작점은 신규 기능 모듈만 AI-Native 원칙(P1 디렉토리 격리 + P3 제로 컨텍스트)으로 구성하는 "신규 모듈 격리(new module isolation)" 전략이다. 확장 경로는 세 단계이다: (1) 신규 기능을 격리 디렉토리로 개발, (2) P4 계약 메타데이터 적용으로 인터페이스 명시화, (3) AI 에이전트의 수정 빈도가 높은 기존 모듈부터 리팩토링. 이 전략은 7.2절의 이중 모드 아키텍처와 연결된다: 기존 코드가 "인간 통제 계층", 신규 모듈이 "AI 통제 계층"으로 공존하는 과도기적 형태이다.
이 프레임워크의 일반화 가능성은 추가 사례 연구를 통해 검증되어야 하며, 현 단계에서의 주장은 대상 프로젝트이 충족한 전제 조건 하에 한정된다.
본 연구가 제기하는 핵심적 질문은 AI-Native 원칙이 SOLID 및 DRY 등 기존 원칙을 대체하는가 보완하는가이다. 분석 결과는 세밀한 답을 시사한다: 조건부 상호 보완성(conditional complementarity).
AI-Native 원칙은 절대적 의미에서 SOLID이나 DRY를 무효화하지 않는다. 오히려, 이러한 원칙의 비용-편익 산법이 전환되는 조건을 식별한다. DRY는 인간 개발자가 주요 코드 유지보수자이고, 코드 복제가 도메인 로직에서 진정한 일관성 위험을 초래하며, 시스템이 현재 AI 도구 세대보다 오래 지속될 것으로 예상될 때 최적으로 유지된다. 의도적 복제는 AI 에이전트가 주요 개발자이고, 복제된 코드가 (도메인 로직이 아닌) 인프라 수준 유틸리티 코드이며, 모듈 격리가 코드 재사용보다 높은 우선순위일 때 선호된다.
이는 전진 경로로서 **이중 모드 아키텍처(dual-mode architecture)**를 시사한다: 조직은 핵심 도메인 로직과 공유 비즈니스 규칙에 대해서는 DRY 원칙을 유지하면서("인간 통제 계층"), 기능 수준 인프라 코드에 대해서는 의도적 복제와 제로 컨텍스트 원칙을 채택할 수 있다("AI 통제 계층"). 이 두 계층 사이의 경계가 명시적 아키텍처 결정이 되며—스킬 시스템에 의해 문서화되고 통제되어야 한다.
인간 코드 리뷰에 대한 부수 효과. AI-Native 아키텍처에서 의도적 복제 전략은 인간-AI 협업 프로세스에 고유한 긴장을 도입한다. AI 에이전트가 복제된 유틸리티 코드의 보안 패치나 일괄 변경을 수행할 때, 다수의 디렉토리에 걸친 유사하지만 동일하지 않은 변경을 생성하며, 이는 인간 코드 리뷰어의 리뷰 피로도(review fatigue)를 증가시킬 수 있다. AI 에이전트에게는 저비용인 일괄 수정이 인간 리뷰어에게는 반복적이고 주의력을 분산시키는 검토 작업을 부과할 가능성이 있다. 이 비대칭은 AI-Native 아키텍처가 인간 협업 비용을 전이시키는 양상을 보여 주며, 복제 파일 간 의미적 diff 요약 도구 등 리뷰 지원 자동화의 필요성을 시사한다.
의도적 복제의 경제적 실행 가능성은 비용 교차점—복제된 코드의 유지 비용(동기화 부담)이 공유 참조의 유지 비용(AI 에이전트의 컨텍스트 로딩 부담)을 초과하는 지점—에 달려 있다. 여러 요인이 이 교차점에 영향을 미친다:
AI 코드 생성 비용 궤적. LLM 추론 비용이 지속적으로 하락함에 따라(역전 조짐이 없는 추세), 복제된 코드의 재생성 비용은 점근적으로 영에 수렴한다. 이 추세는 복제에 유리하다.
컨텍스트 창 확장. 컨텍스트 창이 200K에서 100만 이상 토큰으로 확장됨에 따라, 공유 참조의 컨텍스트 로딩 비용이 감소하여 잠재적으로 균형을 공유 코드 쪽으로 다시 기울일 수 있다. 그러나 "중간에서 길을 잃다" 현상 [Liu et al., 2024]은 더 큰 컨텍스트 창이 자동으로 더 나은 활용으로 이어지지 않음을 시사한다—긴 컨텍스트에서의 주의 저하가 확장된 창에서도 지속될 수 있다.
환각률 감소. LLM이 더 신뢰할 수 있게 됨에 따라, 파일 간 추론의 환각 비용이 감소하여 복제를 통한 격리의 논거를 약화시킨다. 환각률이 임계 임계값(현재 정량화할 수 없는) 아래로 떨어지면, 잘 구조화된 코드베이스에 대해 제로 컨텍스트 원칙이 불필요해질 수 있다고 예상한다.
동기화 도구. 복제된 파일에 걸친 변경을 탐지하고 전파하는 자동화된 동기화 도구—AI 기반 유틸리티—의 개발은 복제 전략의 비용을 극적으로 줄일 수 있다. 5.4절에서 관찰된 바와 같이, 복제 파일 간 버그 수정 전파의 2주 지연은 자동화된 동기화 도구의 필요성을 구체적으로 예증한다. 이러한 도구는 의도적 복제를 "유지보수 비용을 수용하는" 전략에서 "유지보수 비용을 자동화하는" 전략으로 변환할 것이다.
이러한 요인을 보편적 답을 처방하기보다 실무자가 자신의 특정 맥락에서 평가할 수 있는 비용 모델의 변수로 제안한다.
원칙 5의 낮은 달성률(40%)은 더 깊은 분석을 보증한다. 두 가지 경쟁적 설명이 존재한다:
구조적 설명. 런타임 구현을 정확히 반영하는 병행적 명세 계층을 유지하는 것은 자동화된 강제 메커니즘이 없으므로 근본적으로 어렵다. 컴파일러가 강제하는 타입 시스템이나 CI 파이프라인이 검증하는 테스트 스위트와 달리, 명세 정확도에는 자동화된 검증점이 없다. 이 설명은 도구 투자 없이는 원칙이 본질적으로 제한됨을 시사한다.
절차적 설명. 대상 프로젝트 팀은 특히 개발의 수정 단계에서 명세 우선 워크플로우를 일관되게 강제하지 않았다. 명세-런타임 표류는 불가피한 것이 아니라 워크플로우 규율 실패의 결과였다. 이 설명은 더 나은 프로세스 강제로 원칙이 달성 가능함을 시사한다.
분석 결과 두 요인 모두 기여하였으나, 구조적 요인이 지배적인 것으로 판단된다. 완벽한 워크플로우 규율이 있더라도, AI 주도 코드 생성의 속도는 근본적 긴장을 생성한다: AI 에이전트가 구현 코드를 명세가 갱신될 수 있는 것보다 더 빠르게 수정하며(명세 갱신이 동일 워크플로우의 일부인 경우에도), 구현 변경이 종종 명세 구조가 예측할 수 없는 연쇄 효과를 갖기 때문이다. 유망한 완화 방안은 *코드로부터의 명세 생성(spec generation from code)*이다—명세 우선 패턴을 역전시켜 각 수정 주기 후 AI 에이전트가 현재 구현으로부터 명세를 자동 재생성하도록 하는 것이다. 이 접근법은 명세의 처방적(prescriptive) 문서 역할(코드가 해야 할 것)을 포기하지만, 기술적(descriptive) 진입점 역할(코드가 현재 하는 것)을 보존하며, 이것이 작업 기억 기능에는 충분할 수 있다. 실무적으로 제안되는 구체적 구현 후보는, OpenAPI/Protocol Buffers 등 기존 API 명세로부터 모듈 지역 계약 슬라이스(contract slice)를 자동 추출하고 생성된 요약(generated summary)을 각 모듈의 spec 파일에 반영하는 파이프라인이다.
사례 연구 연구를 위한 Yin [2018]의 프레임워크에 소프트웨어 공학 실험을 위한 Wohlin 등 [2012]의 지침을 보완하여 타당도에 대한 위협을 조직한다.
역공학 편향. 다섯 가지 원칙은 프로젝트의 아키텍처 결정에도 관여한 제1저자가 완성된 프로젝트를 역공학하여 추출하였으며, 이 이중 역할은 확증 편향의 위험을 생성한다. 완화: 원래 설계 문서(Confluence 설계 제안서)와 교차 검증하였으나, 동일 팀이 작성하여 독립성이 제한된다. 더 강력한 완화—독립적 복제—는 다중 사례 확장에서 계획하고 있으며, 각 원칙은 5.2절의 세 가지 검증 기준(관찰 가능성, 동기 부여, 차별성)을 충족해야 하였다.
달성도 측정의 주관성. 달성도 백분율은 정성적 판단을 포함하며, 특히 ZCS와 SRDR에서 그러하다. 완화: 조작적 측정 절차를 정의하고(5.3절) 구체적 기준을 보고하였으나, 단일 평가자 측정은 한계로 남는다. 다중 사례 확장에서 평가자 간 신뢰도 평가를 포함할 것이다.
인과 추론의 한계. 사례 연구는 원칙과 코드베이스 속성 간 상관관계를 확립하지만 인과관계를 확립하지는 못한다. 원칙의 효과와 다른 요인(프로젝트 규모, 아키텍트 숙련도, AI 모델 능력)을 분리할 수 없다. 완화: 통제 실험(H1–H3)을 향후 연구로 제안하며, 본 논문의 기여는 원칙의 식별과 형식화이다.
단일 사례의 일반화. 가장 중요한 위협은 단일 사례 연구로부터 프레임워크를 도출한 것이다. 대상 프로젝트는 특정 특성(시간 제한적, 적당한 복잡성, 단일 아키텍트 팀)을 가진 중소 규모 서비스로, 다른 프로젝트 유형으로 일반화되지 않을 수 있다. 완화: 통계적 일반화가 아닌 분석적 일반화 [Yin, 2018]를 채용하며, 원칙을 명시적 전제 조건을 갖는 이론적 프레임워크로 제안한다. 7.1절에서 적용 가능 조건을 상술하고 추가 사례 연구를 계획하고 있다.
비교 대조군 부재. 대상 프로젝트는 처음부터 AI-Native 원칙을 적용하여 개발되었으므로 적용 전 상태가 존재하지 않으며, 전/후 비교는 향후 통제 실험에서 확보할 계획이다.
기술 스택 및 AI 모델 특이성. 사례 연구는 TypeScript/Fastify 스택과 Claude 에이전트에 기반한다. 디렉토리 기반 조직은 패키지 기반 네임스페이싱 언어(Java, Kotlin)에서 상이할 수 있고, LLM 아키텍처별로 인지 특성이 다를 수 있다. 완화: 원칙은 언어나 모델 고유 행동이 아닌 아키텍처 수준 및 일반적 LLM 특성에 의해 동기 부여되었으나, 정량적 달성률은 스택과 모델에 따라 달라질 수 있음을 인정한다.
시간적 타당도. LLM 능력의 빠른 진화(컨텍스트 창 확장, 환각 감소)는 원칙의 비용-편익 산법을 변경할 수 있다. 특히 원칙 2는 컨텍스트 창이 실질적으로 무한해지고 환각률이 영에 수렴하면 진부화에 가장 취약하다. 완화: 7.3절에서 이 시간적 차원을 논의하며, 원칙을 현재 LLM 기술 상태에 조건부인 것으로 프레이밍한다.
AI-Native 용어. "AI-Native 아키텍처"라는 용어는 학술 문헌에 확립되어 있지 않다. 본 논문의 조작적 정의(1절)가 더 넓은 커뮤니티가 이 용어를 이해하게 되는 방식과 일치하지 않을 수 있다. 완화: 명시적 조작적 정의를 제공하며 용어의 직관적 해석에 의존하지 않는다.
메트릭 구성 타당도. 제안된 메트릭(ZCS, BRI, DIR, CC, SRDR)은 새로운 것이며 외부 기준에 대해 검증되지 않았다. 예를 들어, ZCS가 모듈 단순성과 같은 교란 속성이 아닌 코드베이스의 "제로 컨텍스트성"을 진정으로 측정하는지 확신할 수 없다. 완화: 각 메트릭을 조작적으로 정의하며, 향후 연구에서 수렴 및 변별 타당도 분석을 통한 구성 검증의 필요성을 인정한다.
작업 기억 유추. "작업 기억"(원칙 5)은 이론적 주장이 아닌 유추이다. 인간의 작업 기억 [Baddeley, 2000]은 동적·용량 제한적 인지 시스템이나 명세 파일은 정적 문서이다. 완화: 3.5절에서 유추의 한계를 인정하며, 태스크 관련 컨텍스트를 제공하는 기능에 대한 설명 장치로만 사용한다.
본 논문은 AI-Native 소프트웨어 개발을 위한 다섯 가지 아키텍처 원칙—영향 범위 최소화, 참조보다 의도적 복제, 제로 컨텍스트 원칙, 메타데이터로서의 계약, AI 작업 기억으로서의 명세—을 제시하였으며, 이는 산업 프로젝트의 역공학 분석을 통해 도출되고 LLM 기반 개발 에이전트의 인지적 특성에 근거한다.
1절에서 제기한 네 가지 연구 질문을 재검토한다:
RQ1: 기존 아키텍처 원칙의 어떤 측면이 AI 주도 환경에서 부적합해지는가? 분석 결과 세 가지 구체적 부적합성을 식별하였다. DRY의 코드 복제 제거는 AI 에이전트가 파일 간 참조를 추적하도록 강제하여 컨텍스트 창 용량을 소비하고 환각 위험을 증가시킨다(3.2절). Clean Architecture의 계층화된 추상화는 전역 정신 모델 구축을 요구하지만, AI 에이전트는 태스크 간 지속적 기억이 없어 이를 수행할 수 없다(3.3절). 정적 분석을 통한 전통적 아키텍처 거버넌스는 생성 과정이 아닌 산출된 결과물에 대해 작동하여 AI 에이전트의 행동을 제약하지 못한다(4.4절).
RQ2: AI-Native 원칙은 어떻게 형식적으로 정의될 수 있으며, 기존 원칙과 어떤 트레이드오프를 갖는가? 다섯 가지 원칙을 각각 목적, 불변 조건, 동기, 트레이드오프로 정의하여 형식화하였다(3절). 원칙들은 계층적 의존성 구조를 형성한다—기초 계층(영향 범위, 복제), 창발 계층(제로 컨텍스트), 향상 계층(계약, 명세)—이며, 기존 원칙과 절대적 대립이 아닌 조건부 상호 보완성의 관계에 있다(7.2절).
RQ3: 프롬프트 기반 워크플로우는 아키텍처 거버넌스 메커니즘으로 기능할 수 있는가? 사례 연구는 스킬이 전제 조건, 불변 조건, 후행 조건을 통해 아키텍처 제약을 효과적으로 인코딩하고 부분적으로 강제함을 보여 준다(4.3절). 그러나 스킬의 강제는 비결정론적이고 우회 가능하여, 정적 분석과 자동화된 검증의 대체가 아닌 보완으로 기능한다(4.4절).
RQ4: AI-Native 아키텍처 적합도를 정량적으로 측정할 수 있는 메트릭은 무엇인가? 조작적 측정 절차와 합성 지수(ANACI)를 갖춘 다섯 가지 메트릭(ZCS, BRI, DIR, CC, SRDR)을 제안하였다. 대상 프로젝트 사례에 적용한 결과 전체 적합도 74%를 산출하였으며, 이는 메트릭이 실제 코드베이스에 대해 산출 가능하고 해석 가능함을 보여 주지만, 다중 사례에 걸친 추가 검증이 필요하다(6절).
기여를 재확인한다: (1) 형식적 정의와 원칙 간 의존성을 갖춘 다섯 가지 원칙의 형식화(3절), (2) 스킬-원칙 매핑 매트릭스를 갖춘 프롬프트 기반 아키텍처 거버넌스의 도입(4절), (3) 정량적 달성도 측정을 포함하는 경험적 사례 연구(5절), (4) 합성 적합도 지수를 갖춘 다섯 가지 정량적 메트릭(6절). 각 기여는 8절의 단일 사례 한계에 조건부이다.
사례 연구의 평균 달성률 74%는 기초 원칙(영향 범위 95%, 의도적 복제 90%)의 실무적 달성 가능성과, 명세 원칙(40%)에서 AI 코드 생성 속도와 병행적 명세 유지 규율 간의 근본적 긴장을 동시에 드러낸다. 스킬을 통한 프롬프트 기반 거버넌스는 코드가 어떻게 생성되는지를 제약하는 프로세스 수준의 메커니즘으로서, 전통적 정적 분석이 다룰 수 없는 공백을 채운다.
향후 연구의 다섯 가지 방향을 식별한다:
다중 사례 검증 및 통제 실험. 가장 시급한 우선순위는 다양한 프로젝트 규모(엔터프라이즈 시스템), 기술 스택(Kotlin/Spring Boot, Python/FastAPI), AI 모델(GPT-4, Gemini)에 걸친 추가 사례 연구이다. 교차 사례 분석 [Yin, 2018]을 위해 최소 세 개의 추가 사례가 필요하다. 나아가 세 가지 가설(H1–H3)의 인과관계 확립을 위해, AI-Native 원칙 적용 코드베이스와 전통적 아키텍처 코드베이스에서 동일 태스크 수행 시 코드 품질·환각률·태스크 완료 정확도를 비교하는 통제 실험을 계획하고 있다.
자동화된 메트릭 도구. 현재 메트릭은 상당한 수동 측정 노력을 필요로 한다. ZCS(샌드박스화된 AI 에이전트 시행을 통해), BRI(git 로그 분석을 통해), CC/SRDR(명세-코드 비교 스크립트를 통해)을 자동 산출하는 도구의 개발은 AI-Native 아키텍처 적합도의 종단적 추적을 가능하게 할 것이다.
명세 자동 생성 및 거버넌스 측정. 원칙 5의 낮은 달성도(7.4절)는 구현 코드로부터 명세를 자동 생성하는 도구의 필요성을 시사한다. 처방적 명세에서 기술적 명세로의 역전은 동기화 부담을 제거하면서 작업 기억 기능을 보존할 수 있다. 이를 스킬 기반 거버넌스에 통합하고, 3층 거버넌스 프레임워크(스킬 + CI 가드레일 + 메트릭)의 구현과 실증, 그리고 스킬 지시-에이전트 행동 간 일치도의 체계적 측정 프레임워크 개발을 계획한다.
LLM 능력 진화와 총소유비용 모델링. 본 논문의 원칙은 현시점의 LLM 기술적 한계(제한된 컨텍스트 창, 환각 경향)를 전제로 도출되었다(7.1절). 컨텍스트 창이 수백만 토큰으로 확장되고 환각률이 극적으로 감소할 경우, 특히 의도적 복제와 제로 컨텍스트 원칙의 유효성은 재검토가 필요하다. 컨텍스트 창 임계값별 원칙 효과를 추적하는 종단 연구가 요구된다. 동시에, 의도적 복제의 경제적 논거(3.2절)는 AI 코드 생성 비용만을 고려하며 인간 검증 비용과 동기화 유지보수 비용을 포함하지 않는다. 복제본 수와 인간 리뷰 부담 간의 정량적 관계를 포함한 총소유비용(TCO) 관점의 실증 연구가 필요하다.
다중 에이전트 역할 분리 패턴. 사례 연구에서 개발 AI와 서비스 AI가 동일한 spec.ts를 공유하여 런타임 요구사항 변경이 거버넌스를 붕괴시키는 현상이 관찰되었다(5.5절). 복수의 AI 에이전트가 공존하는 환경에서 Dual-Spec 패턴(역할별 명세 분리)을 시작점으로, 원칙 5의 단일 에이전트 전제를 다중 에이전트 환경으로 확장하고, 역할별 명세 분리가 SRDR과 ZCS에 미치는 영향을 정량 비교하는 실험이 필요하다.
AI 주도 소프트웨어 개발로의 전환이 가속되고 있다. 이 전환이 진행됨에 따라, 소프트웨어 설계를 안내하는 아키텍처 원칙도 그에 맞게 진화해야 한다. 다섯 가지 AI-Native 원칙과 부수 메트릭을 이 진화의 출발점으로 제시한다—커뮤니티가 대규모 AI 주도 개발의 경험을 축적함에 따라 검증되고, 정제되며, 확장될 프레임워크이다.
Anthropic. 2025. Claude Code overview. Official Product Documentation. https://docs.anthropic.com/en/docs/claude-code/overview
Baddeley, A. 2000. The Episodic Buffer: A New Component of Working Memory? Trends in Cognitive Sciences 4, 11 (2000), 417–423.
Bass, L., Clements, P., and Kazman, R. 2021. Software Architecture in Practice (4th ed.). Addison-Wesley.
Bogard, J. 2018. Vertical Slice Architecture. https://www.jimmybogard.com/vertical-slice-architecture/
Brown, T.B., Mann, B., Ryder, N., et al. 2020. Language Models are Few-Shot Learners. In Advances in Neural Information Processing Systems (NeurIPS) 33, 1877–1901.
Chen, M., Tworek, J., Jun, H., et al. 2021. Evaluating Large Language Models Trained on Code. arXiv preprint arXiv:2107.03374.
Cockburn, A. 2005. Hexagonal Architecture. https://alistair.cockburn.us/hexagonal-architecture/
Cognition. 2024. Introducing Devin, the First AI Software Engineer. Cognition Labs Technical Blog.
Evans, E. 2003. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
Fowler, M. 2018. Refactoring: Improving the Design of Existing Code (2nd ed.). Addison-Wesley.
GitHub. 2023. The State of the Octoverse 2023. GitHub Annual Report.
Google. 2008. Protocol Buffers: Developer Guide. https://protobuf.dev/
Huang, L., Yu, W., Ma, W., et al. 2023. A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions. arXiv preprint arXiv:2311.05232.
Hunt, A. and Thomas, D. 1999. The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley.
Ji, Z., Lee, N., Frieske, R., et al. 2023. Survey of Hallucination in Natural Language Generation. ACM Computing Surveys 55, 12 (2023), 1–38.
Knodel, J. and Popescu, D. 2007. A Comparison of Static Architecture Compliance Checking Approaches. In Proceedings of the 6th Working IEEE/IFIP Conference on Software Architecture (WICSA), 12–21.
Knodel, J., Muthig, D., Haury, U., and Meier, G. 2006. Architecture Compliance Checking — Experiences from Successful Technology Transfer to Industry. In Proceedings of the 12th European Conference on Software Maintenance and Reengineering (CSMR), 117–126.
Liu, N.F., Lin, K., Hewitt, J., et al. 2024. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics 12 (2024), 157–173.
Martin, R.C. 2003. Agile Software Development: Principles, Patterns, and Practices. Prentice Hall.
Martin, R.C. 2008. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall.
Martin, R.C. 2017. Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall.
Meyer, B. 1992. Applying "Design by Contract." Computer 25, 10 (1992), 40–51.
Millett, S. 2015. Patterns, Principles, and Practices of Domain-Driven Design. Wrox.
Peng, S., Kalliamvakou, E., Cihon, P., and Demirer, M. 2023. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv preprint arXiv:2302.06590.
Richardson, C. 2018. Microservices Patterns: With Examples in Java. Manning.
Ross, S.I., Martinez, F., Houde, S., et al. 2023. The Programmer's Assistant: Conversational Interaction with a Large Language Model for Software Development. In Proceedings of the 28th International Conference on Intelligent User Interfaces (IUI), 491–514.
SmartBear. 2021. OpenAPI Specification v3.1.0. https://spec.openapis.org/oas/v3.1.0
Stack Overflow. 2025. 2025 Developer Survey. https://survey.stackoverflow.co/2025/
Svyatkovskiy, A., Deng, S.K., Fu, S., and Sundaresan, N. 2020. IntelliCode Compose: Code Generation Using Transformer. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), 1433–1443.
Terra, R., Valente, M.T., Czarnecki, K., and Bigonha, R.S. 2015. Recommending Refactorings to Reverse Software Architecture Erosion. In Proceedings of the 16th European Conference on Software Maintenance and Reengineering (CSMR), 335–340.
Vaithilingam, P., Zhang, T., and Glassman, E.L. 2022. Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models. In Proceedings of the CHI Conference on Human Factors in Computing Systems Extended Abstracts (CHI EA), 1–7.
Wei, J., Wang, X., Schuurmans, D., et al. 2022. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. In Advances in Neural Information Processing Systems (NeurIPS) 35, 24824–24837.
Wohlin, C., Runeson, P., Host, M., Ohlsson, M.C., Regnell, B., and Wesslen, A. 2012. Experimentation in Software Engineering. Springer.
Yang, J., Jimenez, C.E., Wettig, A., et al. 2024. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. arXiv preprint arXiv:2405.15793.
Yin, R.K. 2018. Case Study Research and Applications: Design and Methods (6th ed.). SAGE Publications.
Ziegler, A., Kalliamvakou, E., Li, X.A., et al. 2022. Productivity Assessment of Neural Code Completion. In Proceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming (MAPS), 21–29.
T3. The-Context-Window-Economy-Rethinking-DRY-in-the-Age-of-LLM-Driven-Development (저자), "컨텍스트 창 경제학: LLM 기반 개발 시대의 DRY 원칙 재고", 미출판 원고, 2025.
Chroma Research. 2025. Context Rot: Understanding Real-World LLM Context Window Performance. Chroma Technical Report.
Dodds, K.C. 2020. AHA Programming. https://kentcdodds.com/blog/aha-programming
Kapser, C.J. and Godfrey, M.W. 2008. "Cloning Considered Harmful" Considered Harmful: Patterns of Cloning in Software. Empirical Software Engineering 13, 6 (2008), 645–692.
Li, Y., et al. 2025. Sequential Needle-in-a-Haystack: Evaluating Long-Context Reasoning in LLMs. arXiv preprint arXiv:2502.xxxxx.
Metz, S. 2016. The Wrong Abstraction. https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
//