Constraint로서의 아키텍처: AI의 해 공간 좁히기

내가 지난 몇 년 동안 참여했던 많은 프로젝트에서는, 결국 비슷한 뜻의 문장이 한 번쯤은 등장하곤 했다.

“우리에겐 아키텍트가 필요 없어.”

때로는 정말로 그 역할 자체를 가리키는 말이었다. 때로는 아키텍처는 어차피 팀 안에서 자연스럽게 생겨나는 것이므로 특별한 관심이 필요 없다는 생각을 뜻했다. 그리고 놀랍게도, 처음에는 그런 방식이 꽤 잘 작동하기도 했다. Feature는 구현되고, Release는 나가고, 기술적 결정은 필요한 순간마다 그 자리에서 내려졌다.

문제는 대개 다음 날 바로 드러나지 않는다. 몇 년에 걸쳐 천천히 만들어진다.

어떤 Service가 사실 다른 Boundary 뒤에 있어야 할 것을 직접 건드리기 시작한다. 한 번의 예외는 급한 Use Case 때문에 충분히 이해할 만했고, 나중에는 그 예외가 다음 예외의 기준이 된다. 하나의 기존 Pattern 옆에 두 번째 것이 생기고, 그다음에는 세 번째 것이 생긴다. State에는 여러 Owner가 생긴다. Feature는 다른 Feature의 Internals를 사용하기 시작한다. 새로 들어온 개발자는 거의 모든 구조적 결정을 정당화할 수 있는 기존 예시 하나쯤을 찾을 수 있게 된다.

어느 순간이 되면, 어떤 길이 원래 의도된 길이었는지 더 이상 분명하지 않다.

이것은 AI 시대에 새로 생긴 이야기가 아니다. 소프트웨어 엔지니어링은 수십 년 동안 모듈화, Information Hiding, Cohesion, Coupling, 안정적인 인터페이스, Dependency Direction, 그리고 명확한 책임을 다뤄 왔다. David Parnas는 1972년에 모듈 분해에 관한 기초적인 연구를 발표했다. Stevens, Myers, Constantine은 1974년 Structured Design에서 기능적 모듈을 통해 복잡도를 줄이는 원칙을 설명했다. Foote와 Yoder는 1990년대 말 그 반대편의 극단적인 형태에 Big Ball of Mud라는 이름을 붙였다.

Coding Agent가 이런 문제를 발명한 것은 아니다. 달라진 것은 처리량이다.

Coding Agent는 코드, 테스트, 설정, 문서를 순수하게 인간으로만 구성된 팀이 따라가기 어려운 속도로 변경할 수 있다. OpenAI는 2026년 2월의 실무 보고서에서, 코드가 전부 Codex로 생성된 내부 프로젝트 하나를 소개한다. 작은 팀은 몇 달 동안 약 1,500개의 Pull Request를 병합했다. 이 숫자는 일반적인 생산성 Benchmark가 아니다. 하지만 가능한 변경 속도가 얼마나 크게 달라질 수 있는지는 보여 준다.

그렇게 오래된 문제가 갑자기 더 급해진다.

Agentic 소프트웨어 개발의 많은 문제는 더 높은 처리량 아래에서 다시 나타나는 오래된 소프트웨어 문제다.

예전에는 한 달에 열 번 내려지던 로컬 구조 결정이 앞으로는 백 번 내려진다고 해서 그 결정의 본질이 반드시 달라지는 것은 아니다. 하지만 일관성 없는 결정은 더 빠르게 복제되고, 더 빠르게 새로운 전례가 되고, 다음 Agent가 다시 증거로 삼을 구조 자체를 더 빠르게 바꿀 수 있다.

그래서 내가 Agentic Work와 관련해 아키텍처를 바라보는 이유는 아주 구체적이다. “좋은 아키텍처가 중요하다”는 당연한 말을 다시 하기 위해서가 아니라, 바로 이것 때문이다.

아키텍처는 Coding Agent의 의사결정 공간을 줄인다.

Requirements는 첫 번째 경계였을 뿐이다

이전 글은 Requirements를 하나의 경계로 설명했다. Coding Agent는 서로 다른 해결 경로를 만들 수 있지만, 그렇다고 모든 결과가 허용되는 것은 아니다.

Requirements는 다음과 같은 질문에 답한다.

비즈니스 관점에서 반드시 성립해야 하는 것은 무엇인가?

어떤 상태가 허용되는가?

무엇이 성공인가?

어떤 오류 사례를 처리해야 하는가?

무엇이 Scope 밖인가?

이렇게 기능적 결과 공간이 줄어든다.

하지만 이 모든 질문이 완벽하게 답변되었다고 해 보자. Agent는 Feature가 마지막에 무엇을 해야 하는지 정확히 알고 있다. 그래도 그 결과에 도달하는 구조적 방법은 여전히 여러 개일 수 있다.

바로 거기에서 아키텍처가 시작된다.

Requirements는 기능적 결과 공간을 제한한다. 아키텍처는 구조적 해 공간을 제한한다.

단순화하면 다음과 같다.

모든 가능한 해결책
↓
Requirements
↓
기능적으로 허용 가능한 해결책
↓
Architecture Constraints
↓
구조적으로 허용 가능한 해결책
↓
더 작은 의사결정 공간

이것은 아키텍처가 모든 Task에 대한 완전한 시공 매뉴얼을 제공해야 한다는 뜻이 아니다.

Agent는 여전히 로컬한 결정을 내릴 수 있어야 한다. helper function을 다르게 자를 수도 있고, loop를 다르게 표현할 수도 있으며, 하나의 모듈 안에서 현재 문제에 가장 잘 맞는 구체적인 구현을 선택할 수도 있다.

아키텍처는 오히려 내가 매 Feature마다 다시 결정하고 싶지 않은 결정을 정의한다.

Presentation이 Infrastructure에 직접 접근해도 되는가?

Feature A가 Feature B의 Internals를 Import해도 되는가?

특정 State는 누가 소유하는가?

모듈은 어떤 Contract를 통해 접근되어야 하는가?

어떤 Dependency Direction이 적용되는가?

이런 것들은 하나의 로컬 함수를 어떻게 구현할지보다 훨씬 더 큰 구조적 후속 효과를 가진다.

좋은 아키텍처는 Agent에게서 모든 결정을 없애지 않는다. 매 Feature마다 새로 내려서는 안 되는 결정을 주로 없앤다.

Repository가 여섯 개의 정답을 제공할 때

기능적으로 아주 단순한 변경을 생각해 보자. 어떤 Component가 새로운 데이터를 필요로 한다.

오래 자라난 Repository에서는 Agent가 다음과 같은 변형을 발견할 수 있다.

Component → API

Component → Shared Service → API

Component → Store → API

Component → Feature Service → API

Component → 다른 Feature → API

Component → 과거의 Utility → API

문제는 이 여섯 방식이 모두 명백하게 나쁘다는 데 있지 않다.

실제로 전부 존재할 수도 있다.

각각이 어디선가 Production에서 잘 동작하고 있을 수도 있다. 심지어 각각은 충분히 이해할 만한 역사까지 가질 수 있다. 직접 API 호출은 초창기 방식이다. 나중에는 Shared Service가 들어왔다. 새 팀은 Store를 사용했다. 다른 Feature는 자기만의 Application Service를 가진다. 급한 특수 사례 때문에 이웃 Feature의 기존 Flow가 재사용되었을 수도 있다.

그렇다면 Coding Agent는 여기서 무엇을 배워야 할까?

자주 쓰이는 지시는 이런 식이다.

기존 Pattern을 따르세요.

Repository를 실제로 보기 전까지는 매우 정확한 말처럼 들린다. 하지만 어떤 Pattern을 말하는가? Agent는 여러 파일을 열어 보고 서로 반대되는 여러 방식에 대해 각각 로컬 증거를 찾을 수 있다. Codebase는 동시에 이렇게 말한다.

우리는 여기서 이렇게 한다.

그리고 또 이렇게 말한다.

아니, 우리는 여기서 이렇게 한다.

이 지점에서 변동성는 더 이상 모델의 속성만이 아니다. Repository 자체가 모호한 구조적 해 공간을 포함하고 있다.

“기존 Pattern을 따르라”는 말은 시스템에 실제로 인식 가능한 Pattern이 있을 때만 의미가 있다.

Agent는 빈도, 최신성, 위치적 근접성, Naming을 바탕으로 어떤 예시가 더 관련 있는지 추론할 수 있다. 추가 문서를 찾거나 더 많은 파일을 열 수도 있다. 마지막에는 올바른 결정을 내릴 수도 있다.

하지만 그 모든 행동은 추가적인 해석이다.

전역적인 아키텍처 결정이 미리 내려져 있지 않았기 때문에, Agent는 하나의 로컬 Feature를 구현하면서 그 결정을 다시 재구성해야 한다.

아키텍처는 원하지 않는 변동성를 제거한다

이제 반대로, 이 영역에서는 다음 구조가 명확한 규칙인 시스템을 생각해 보자.

Presentation
↓
Application
↓
Domain
↓
Infrastructure

이 Layering이 보편적인 아키텍처 정답이라는 뜻은 아니다. 다른 시스템은 Vertical Slices, Ports and Adapters, Modular Monolith, Self-contained Systems, 또는 완전히 다른 구조가 더 적합할 수 있다.

중요한 것은 이 그림 자체가 아니다.

중요한 것은 구조가 하나의 분명한 주장을 한다는 것이다.

Presentation이 Infrastructure에 직접 접근할 수 없다면, 구조적으로 가능한 해결 방식의 한 부류 전체가 허용 공간에서 사라진다. 비즈니스 모듈이 Public Contract를 통해서만 접근될 수 있다면 더 많은 변형이 사라진다. State에 하나의 명확한 Owner가 있다면, Agent는 매 Feature마다 두 번째 진실을 어디에 두면 편할지를 새로 결정하지 않아도 된다.

Agent는 여전히 확률적이고, 허용된 구조 안에서 서로 다른 해결책을 만들 수 있다. 바로 그것이 우리가 원하는 것이다.

아키텍처는 변동성를 없애지 않는다. 원하지 않는 변동성를 없앤다.

내게 이것은 고전적인 소프트웨어 아키텍처와 Agentic Development 사이의 가장 중요한 연결 중 하나다.

우리는 Coding Agent를 결정론적 Compiler로 만들려는 것이 아니다. 우리는 어디에서 자유가 가치가 있고, 어디에서 자유가 구조적 위험을 만드는지를 정의하고 있다.

더 적은 edge는 단지 예쁜 다이어그램 이상의 의미를 가진다

“모듈성”은 쉽게 추상적이 된다. 의존성을 보면 이야기가 더 흥미로워진다.

명확한 Responsibility를 가지고, 자신의 State를 직접 통제하고, 적은 Dependencies만 필요로 하며, 작은 Public Contract를 통해서만 사용되는 비즈니스 모듈을 생각해 보자.

그 모듈의 구조적 이웃 공간은 제한적이다.

그 안의 변경에는 다섯 개의 파일, 두 개의 Contract, 하나의 외부 Adapter만 관련 있을 수도 있다. 물론 Agent는 더 넓은 영역도 살펴볼 수 있다. 하지만 아키텍처는 이미 관련 정보가 어디에 있어야 하는지에 대한 강한 추정을 제공한다.

직관은 간단하다.

허용된 edge가 적다
↓
구조적 대안이 적다
↓
잠재적으로 관련 있는 Repository 영역이 적다
↓
의사결정 공간이 작다

이것은 수학적 법칙이 아니다. 작은 모듈이 비즈니스적으로 매우 복잡할 수도 있고, 의존성이 적은 시스템의 문서가 나쁠 수도 있다. 낮은 결합도가 올바른 Requirements나 올바른 코드를 보장하는 것도 아니다.

하지만 아키텍처는 그럴듯한 구조적 경로의 수를 바꾼다.

반대로 강하게 결합된 영역은 많은 입구와 출구를 가진다. 변경이 State, Services, Utilities, 다른 Features, 전역 메커니즘을 건드릴 수 있다. 결국 세 파일만 바꾸면 되는 경우에도 처음에는 훨씬 더 넓은 영역이 관련 있어 보인다.

Agent는 더 많은 것을 배제해야 한다.

그래서 Agentic Work에서는 Loose Coupling이 추상적인 모듈성만큼이나 흥미롭다. 낮은 결합도는 인간의 Change Radius와 조정 비용을 줄일 뿐 아니라, Agent가 Exploration 중에 생각해야 할 구조적 관계의 수까지 줄여 준다.

고전적인 연구는 LLM이 등장하기 오래전부터 이 방향을 다뤘다. Stevens, Myers, Constantine은 이미 1974년 Structured Design을 기능적 모듈을 통해 프로그램 복잡도를 줄이고 Coding, Debugging, Modification을 더 쉽게 만드는 접근으로 설명했다. Cohesion과 Coupling은 이후 소프트웨어 설계의 핵심 개념이 되었다.

여기에서도 그들이 Coding Agent를 위한 원칙을 만들었다고 말하면 역사적으로 잘못된 해석이다.

그들은 소프트웨어를 위한 원칙을 만들었다. 그렇기 때문에 지금의 관찰이 더 흥미롭다. 인간이 시스템을 로컬하게 이해하고 통제된 방식으로 변경하는 데 도움이 되는 특성은 Agent에게도 중요해질 수 있다.

SCS를 직관적인 예시로 보기

Self-contained System은 이를 생각하기 좋은 모델이다.

SCS 아키텍처는 비즈니스 기준으로 나뉜, 대부분 자율적인 시스템을 설명한다. 각 시스템은 자신의 데이터 저장과 Business Logic을 가지고, 가능한 한 스스로 기능을 완수하며, 다른 영역과의 결합을 의도적으로 줄인다. 공유 Business Logic은 피하고, 동기식 의존성은 가능한 범위에서 제한해야 한다.

여기서 실제 프로젝트가 정말 SCS를 사용하는지는 중요하지 않다.

흥미로운 것은 경계의 형태다.

┌───────────────────────────────┐
│          비즈니스 영역         │
│                               │
│  UI                           │
│  Business Logic               │
│  State / Data                 │
│  Technical Adapters           │
│                               │
└───────────────┬───────────────┘
                │
       소수의 명시적 Contract
                │
                ▼
            다른 시스템

이런 영역은 Agent에게 비교적 분명한 작업 공간을 제공한다. 비즈니스 Responsibility는 위치를 가진다. 데이터 소유권도 위치를 가진다. 외부 관계는 제한적이고 눈에 보인다.

Self-contained Systems가 과학적으로 “LLM에 더 좋다”고 결론내릴 수 있는 신뢰할 만한 연구를 나는 알지 못한다. 그렇게 주장하는 것은 지나치다.

여기서 SCS는 더 일반적인 원칙을 보여 주는 아키텍처 예시일 뿐이다. 로컬 책임과 적은 수의 명시적 edge.

같은 원칙은 Modular Monolith 안에서도 똑같이 성립할 수 있다.

Big Ball of Mud는 서로 모순되는 증거를 제공한다

반대편 사례는 이 사이트에서 이미 자세히 다룬 Big Ball of Mud다.

Foote와 Yoder는 구조가 느슨하거나 우연히 형성되고, 일관된 설계보다 단기적인 실용성에 더 많이 좌우되는 시스템을 그렇게 설명했다. 그들은 통제되지 않은 성장, 반복적인 임시 수선, 광범위하게 공유되거나 중복된 정보, 처음부터 명확하지 않았거나 시간이 지나면서 침식된 구조를 설명한다.

Agentic Work의 관점에서 내가 특히 흥미롭게 보는 속성이 하나 있다.

Repository 자체가 서로 모순되는 증거가 된다.

모든 것이 모든 것을 안다

가능한 경로가 많다

서로 모순되는 Pattern이 있다

역사적인 특수 사례가 많다

Ownership이 불명확하다

암묵적 Dependencies가 있다

Agent는 여기서 너무 적은 예시가 아니라 너무 많은 예시를 발견할 수 있다.

API 접근 방법은 다섯 개다. State 모델은 세 개다. 두 Feature는 Public Contract를 통해 서로 접근하지만, 다른 네 Feature는 Internals를 Import한다. 새로운 Pattern이 도입되었지만 기존 Pattern은 완전히 사라지지 않았다. 어떤 예외는 이제 원래 규칙보다 더 자주 보인다.

이렇게 되면 작업은 구현에서 해석으로 이동한다.

어떤 코드가 본보기인가?

어떤 파일은 역사적 잔재인가?

어떤 편차는 의도인가, 우연인가?

가장 흔한 Pattern이 원하는 Pattern인가, 단지 가장 오래된 Pattern인가?

6번 글은 그럴듯한 로컬 결정이 Drift에 어떻게 기여할 수 있는지 이미 설명했다. 여기서는 그 메커니즘을 다시 설명할 필요가 없다. 새로운 결론은 이것이다.

아키텍처는 Drift가 애초에 일어날 수 있는 공간을 줄이는 메커니즘이다.

Big Ball of Mud와의 연결을 더 깊이 보고 싶다면 기존 시리즈의 AI와 Big Ball of Mud를 참고할 수 있다.

이 아이디어는 우리 대부분의 프로그래밍 언어보다 오래되었다

이 논의의 시간적 범위는 꽤 인상적이다.

1972년 David Parnas는 시스템을 모듈로 나누는 서로 다른 두 기준을 살펴보았다. 그의 핵심은 단순히 “모듈은 좋다”가 아니었다. 중요한 것은 어떤 기준으로 모듈을 만드는가였다. 모듈화는 유연성과 이해 가능성을 높여야 하고, Information Hiding은 특히 어렵거나 자주 바뀔 가능성이 있는 설계 결정을 적절한 모듈 경계 뒤에 숨겨야 한다.

그 생각은 지금도 놀랄 만큼 현대적이다.

하나의 변경 때문에 전체 시스템을 다시 이해해야 해서는 안 된다.

특정 지식은 명확한 Owner를 가져야 한다.

다른 영역은 내부 결정에 대해 가능한 한 적게 알아야 한다.

인터페이스는 임의의 구현 세부사항이 아니라 안정적인 가정을 전달해야 한다.

2년 뒤 Structured Design은 모듈 내부의 기능적 결속과, 모듈 사이의 가능한 한 통제된 관계를 통해 비슷한 목표를 설명했다. 이후 용어와 방법은 여러 번 바뀌었다. 객체지향, 컴포넌트 모델, Services, Domain-Driven Design, Microservices, Modular Monolith 등 수많은 접근이 다른 추상을 더했다.

하지만 근본적인 바람은 놀랄 만큼 안정적이었다.

로컬하게 이해하고
로컬하게 바꾸며
전역적 영향을 제한한다

Coding Agent는 여기에 새로운 기술적 조건을 더한다. 제한된 Context, Repository Retrieval, Tool Calls, 확률적 해결 경로, 그리고 기존 코드로부터 구조 규칙을 추론해야 한다는 조건이다.

하지만 그들이 만나는 시스템 문제는 훨씬 오래되었다.

수십 년 동안 인간이 대규모 시스템을 이해하고 안전하게 변경하도록 도왔던 특성은 Agent에게도 흥미롭다.

Parnas가 AI를 예견했기 때문이 아니다.

Repository 구조가 관련 관계와 무관한 관계를 분리해 줄 때, Agent도 더 쉽게 작업할 수 있기 때문이다.

아키텍트가 없어도 아키텍처 작업은 사라지지 않는다

이쯤에서 내 개인적인 프로젝트 경험을 편리한 역할 논쟁으로 바꿀 수도 있다.

“보라, 그러니까 모든 프로젝트에 Software Architect가 필요하다.”

하지만 그건 너무 단순하다.

프로젝트가 꼭 그 Job Title을 가진 사람을 필요로 하는 것은 아니다. 아키텍처 책임은 Tech Lead에게 있을 수도 있고, 팀이 공동으로 가질 수도 있으며, Platform Ownership을 통해 분산될 수도 있고, 명확한 Engineering Process와 기술적 Constraint를 통해 제도화될 수도 있다.

하지만 공식적으로 아키텍처를 담당하는 사람이 없으면 아키텍처 결정도 사라진다는 생각은 통하지 않는다.

“아키텍트”라는 역할이 없다고 해서 아키텍처 작업이 사라지는 것은 아니다. 아키텍처 결정은 단지 다른 곳에서 내려질 뿐이며, 대개 로컬하고 암묵적이고 일관성이 없다.

새로운 Import 하나하나가 아키텍처 결정을 만든다.

State에 Writer 하나를 추가하는 것도 그렇다.

Shared Library를 새로 만드는 것도 그렇다.

원래 존재해야 할 Boundary를 가로지르는 직접 접근도 그렇다.

질문은 오직 하나다. 이런 결정이 하나의 공유된 틀 안에서 의식적으로 내려지는가, 아니면 개별 Ticket에 우연히 흩어지는가.

그래서 내게 아키텍처는 특정 직함을 필요로 하지 않는다. 하지만 책임은 필요로 한다.

아키텍처는 위험 관리다

나는 일관성에 대해 비교적 엄격한 개인 기준을 가지고 있다. 내 프로젝트를 보면 아마 금방 드러날 것이다.

하나의 Feature만 다른 모든 Feature와 다르게 구조화되어 있으면 불편하다. 어떤 Layer가 더 이상 명확한 Responsibility를 가지지 않으면 불편하다. State에 명확한 Owner가 없거나, 어떤 Dependency가 “이번 한 번만” Boundary를 넘어가는 것도 불편하다.

이것은 쉽게 아키텍처 완벽주의처럼 보일 수 있다. 하지만 내게는 이제 그보다 다른 이유가 있다.

아키텍처는 완벽주의 경쟁이 아니라 위험 관리다.

아키텍처 규칙은 문제가 될 미래 상태를 덜 가능하게 만들거나, 아예 불가능하게 만들 때 가치가 있다.

예를 들어:

Feature A는 Feature B를 내부적으로 Import할 수 없다.

이 규칙은 좋은 소프트웨어를 보장하지 않는다. 하지만 Cross-Feature Coupling이 여러 해에 걸쳐 조금씩 커질 위험을 줄인다.

Presentation은 Infrastructure를 직접 호출할 수 없다.

이 규칙도 Business Logic의 품질을 보장하지 않는다. 하지만 UI Orchestration, 기술적 접근 로직, 비즈니스 결정이 서로 섞일 수 있는 지점을 줄여 준다.

또는:

State는 하나의 명확한 Owner를 가진다.

이것이 모든 State Management 문제를 해결하지는 않는다. 하지만 서로 경쟁하는 진실과 가능한 Write Path의 수를 줄인다.

내가 아키텍처 다이어그램보다 규칙을 더 흥미롭게 보는 기준은 바로 이것이다.

이 규칙은 어떤 위험을 줄이는가?

그 질문에 답하지 못한다면, 그 규칙도 그다지 가치가 없을 수 있다.

아키텍처는 Codebase의 문법이다

이전 글에서 나는 개인적인 원칙을 하나 적었다.

프로젝트는 한 명의 개발자가 쓴 것처럼 읽혀야 한다.

아키텍처 관점에서 지금은 이것을 조금 더 정교하게 표현할 수 있다.

아키텍처는 Codebase의 문법이다.

언어는 모든 문장이 똑같을 것을 요구하지 않는다. 작성자는 서로 다른 내용을 표현하고, 다른 단어를 고르고, 문제를 다른 방식으로 설명할 수 있다. 하지만 언어에는 규칙이 있다. 어떤 구조는 그 언어에 속하고, 어떤 구조는 속하지 않는다.

Codebase에 옮기면, 두 Agent가 똑같은 로컬 구현을 만들 필요는 없다는 뜻이다. Agent A는 Agent B와 다른 방식으로 작은 helper function을 쓸 수 있다. Agent C도 같은 Invariant를 만족하는 한 자신의 모듈 안에서 다른 알고리즘을 선택할 수 있다.

내가 피하고 싶은 것은 각 모델이 새로운 시스템 문법을 발명하는 것이다.

               Architecture
                    ↓
        ┌───────────┼───────────┐
        ↓           ↓           ↓
     Agent A     Agent B     Agent C
        ↓           ↓           ↓
      서로 다른 로컬 해결책
                    ↓
         동일한 구조적 문법

바로 여기에서 아키텍처가 모델 변동성를 다루는 데 도움이 된다.

서로 다른 Generation이 서로 다른 시스템 구조로 이어질 필요는 없다.

Micromanagement가 아니라 Invariant

이 구분이 중요한 이유는 Architecture Constraints가 쉽게 또 다른 잘못된 방향으로 갈 수 있기 때문이다.

내가 Agent에게 모든 Method Call, 모든 helper function, 모든 중간 파일, 모든 구현 단계를 미리 정해 준다면, 물론 해 공간은 줄어든다.

하지만 그때 나는 Agent를 비싼 키보드처럼 쓰는 셈이다.

더 흥미로운 Constraint는 이런 형태다.

Invariant:
Presentation은 Infrastructure를 직접 호출할 수 없다.

열려 있음:
허용된 Layer 안에서
로컬 helper function을 어떻게 구현하는가.

또는:

Invariant:
비즈니스 모듈은 오직
Public Contract를 통해서만 사용된다.

열려 있음:
그 Contract를 모듈 내부에서 어떻게 충족하는가.

OpenAI의 Agent-first 실무 보고서는 매우 비슷한 구분을 설명한다. Invariant는 고정하고 기계적으로 강제하지만, 구체적인 구현 세부는 의도적으로 열어 둔다. 예를 들어 데이터 형태는 시스템 경계에서 Parse해야 한다고 요구하지만, 어떤 구체적인 Library를 써야 하는지까지 정하지는 않는다.

내게 이것이 올바른 추상화 수준이다.

아키텍처는 비싼 결정을 고정하고 로컬 결정은 열어 둔다.

여기서 “비싸다”는 꼭 금전적인 의미가 아니다. 구조적인 후속 위험이 큰 결정을 뜻한다. Dependency Direction, Ownership, 모듈 경계, Contracts, 특정 Responsibility가 어디에 있어도 되는가 같은 것들이다.

이런 결정을 매번 새로 내리는 것은 얻는 가치에 비해 변동성를 너무 많이 만든다.

아키텍처를 설명하고, 보이게 하고, 실행 가능하게 만들기

아키텍처를 설명하기

여기서 아주 실용적인 문제가 하나 생긴다.

아키텍처가 실제로 존재해도 Agent에게는 거의 보이지 않을 수 있다.

그래서 첫 번째 단계는 문서다.

Architecture Docs
ADRs
Agent Files
Layering 설명
Dependency Rules

문서는 중요하다. 왜 Boundary가 존재하는지, 어떤 Trade-off를 고려했는지, 어떤 사례를 의도적으로 다르게 처리하는지 설명할 수 있다.

하지만 텍스트에는 한계가 있다. 놓칠 수 있고, 낡을 수 있고, 오해될 수 있다. 그리고 큰 Context 안에서 Task 설명, Code, Tool 출력, 다른 문서 사이에 묻힐 수도 있다.

OpenAI는 예를 들어, 자신의 프로젝트에서 거대한 단일 AGENTS.md가 바로 이런 이유로 잘 작동하지 않았다고 설명한다. Guidance의 양이 제한된 Context 안에서 Task, Code, 관련 문서와 경쟁했다. 그래서 짧은 Agent File이 더 깊은 Repository 문서로 안내하는 지도에 가까운 역할을 하게 되었다.

문서화된 아키텍처는 필요하지만, 가장 강한 Constraint는 아니다.

아키텍처를 보이게 하기

두 번째 단계는 Repository에서 이미 눈에 보이는 아키텍처다.

예를 들어:

orders/
  presentation/
  application/
  domain/
  infrastructure/

또는:

billing/
catalog/
identity/
orders/

그리고 모듈 사이에는 명확한 Public Contract가 있다.

다시 말하지만 구체적인 폴더 구조 자체가 핵심은 아니다. 물리적 구조와 아키텍처 구조가 서로 모순되지 않는 것이 중요하다.

모든 Infrastructure Adapter가 기술적 변환과 I/O만 담당한다면 Repository 자체가 로컬 증거를 만든다.

Business Rule을 담은 새 Adapter는 눈에 띈다.

모든 Feature가 작은 Public Entry Point를 가지고 Internals를 직접 Import하지 않는다면, Deep Import는 이상하게 보인다.

모든 State가 정확히 하나의 Owner를 가진다면, 두 번째 Writer는 의심스럽게 보인다.

일관성은 편차를 보이게 만든다.

내가 “지루한” Layer를 좋아하는 이유 중 하나도 이것이다.

Infrastructure Layer는 지루해도 된다. API Adapter는 예측 가능하게 보여도 된다. 바로 그 예측 가능성이 가치가 있다. Agent가 쉰 가지 창의적인 변형을 보고 먼저 Responsibility를 추론할 필요가 없기 때문이다.

Codebase가 자기 문법을 더 일관되게 표현할수록, 기존 코드는 더 유용한 증거가 된다.

아키텍처를 실행 가능하게 만들기

세 번째 단계에서는 규칙의 성격이 다시 바뀐다.

우리는 더 이상 이렇게 설명만 하지 않는다.

Feature A는 Feature B를 내부적으로 Import하면 안 된다.

Architecture Test가 그 Import를 거부하게 만든다.

우리는 더 이상 이렇게만 쓰지 않는다.

Presentation은 Infrastructure를 사용할 수 없다.

Dependency Constraint가 그 상태를 유효하지 않게 만든다.

Contract가 지켜지길 바라는 데서 멈추지도 않는다.

Types, Schemas, Tests, CI가 그것을 검증한다.

기술에 따라 여러 도구가 가능하다.

• Dependency Constraints,
• Architecture Tests,
• Import Restrictions,
• Linter Rules,
• 모듈 경계,
• Type 및 Schema 검사,
• Structural Tests,
• CI Verification.

구체적인 도구보다 메커니즘이 중요하다.

아키텍처를 설명한다
↓
아키텍처를 보이게 만든다
↓
아키텍처를 실행 가능하게 만든다

마지막 단계에서는 아키텍처 규칙이 Verification Loop의 일부가 된다.

가장 강한 아키텍처 규칙은 Agent가 들키지 않고는 위반할 수 없는 규칙이다.

이것은 다음과 같은 지시와 질적으로 다르다.

X를 하지 마세요.

Guidance가 이렇게 바뀐다.

X는 시스템의 유효한 상태가 아니다.

Coding Agent는 Boundary를 위반하려 할 수 있다. Linter가 반대한다. Architecture Test가 실패한다. Build가 새로운 증거를 제공한다. Agent는 수정할 수 있다.

아키텍처는 더 이상 단순한 Context가 아니다.

실행 가능한 피드백이 된다.

OpenAI의 Agent-first 개발에서 본 최신 실무 사례

바로 이 점 때문에 OpenAI의 Harness engineering: leveraging Codex in an agent-first world 보고서가 내게 특히 흥미롭다.

이 보고서는 과학 연구가 아니며, 매우 독특한 Agent-centric 내부 소프트웨어 프로젝트 하나를 설명한다. 따라서 그 결과를 보편적 법칙처럼 읽어서는 안 된다.

그럼에도 실무 사례로서는 주목할 만하다.

OpenAI는 비즈니스 Domain 내부의 고정된 Layer, 엄격히 검증되는 Dependency Direction, 제한된 수의 허용 edge를 설명한다. Cross-cutting Concerns는 명시적인 메커니즘을 통해 Domain으로 들어가고, 다른 Dependency Path는 금지된다. Custom Linter와 Structural Test가 이런 규칙을 자동으로 강제한다. 동시에 팀은 구현을 Micromanage하기보다 Invariant를 강제한다는 원칙을 명확하게 말한다.

보고서는 여기서 강한 실무 경험을 제시한다. Agent는 엄격한 경계와 예측 가능한 구조가 있는 환경에서 특히 효과적으로 일했다. OpenAI는 이 구체적인 프로젝트에서, 이런 Constraint를 높은 처리량을 유지하면서 구조적 붕괴 또는 Architecture Drift를 피하기 위한 전제 조건으로까지 설명한다.

나는 여기서 다음처럼 결론내리지 않는다.

OpenAI가 증명했다:
엄격한 Layering = 최고의 AI 아키텍처.

그 보고서는 그런 것을 증명하지 않았다.

더 흥미로운 점은 이것이다. 일관되게 Agent-first로 소프트웨어를 만들고 매우 높은 Generation Throughput을 내는 팀이 아주 이른 시점에 허용된 Dependency Path를 줄이고, 기계적으로 검증 가능한 Invariant에 투자한다는 사실이다.

이것은 여기에서 우리가 도출한 메커니즘과 놀랄 만큼 가깝다.

오래된 원칙이 새로운 Context 문제와 만나다

Coding Agent에 대한 현재 연구도 Repository 구조가 중요해지는 바로 그 지점을 연구하고 있다. Context Selection, Fault Localization, Repository Navigation, Dependency Reasoning이다.

이 결과들이 어떤 “깨끗한” 아키텍처 접근이 자동으로 더 좋은 Agent 결과를 만든다는 것을 증명하지는 않는다.

하지만 구조 정보가 Agent에게 실제로 가치가 있을 수 있다는 것은 보여 준다.

2026년 Preprint Repository Intelligence Graph는 예를 들어 Build와 Test 정보에서 결정론적으로 만들어진 아키텍처 지도를 Agent에게 제공한다. 세 개의 상용 Agent와 여덟 개 Repository를 사용한 연구에서 구조적 질문의 평균 정확도는 상대적으로 12.2% 상승했고, 처리 시간은 53.9% 감소했다. 동시에 연구의 한계도 명확하다. Repository는 여덟 개뿐이고 그중 일곱 개가 Synthetic이다. 일부 Agent에서는 Token 사용량 대신 처리 시간을 측정한다. 무엇보다 이 연구는기존 아키텍처의 표현 방식을 연구하지, 아키텍처 자체의 품질을 연구하지 않는다.

ASE 2026에 채택된 LLM Agents Can See Code Repositories는 다른 형태의 구조 지원을 연구한다. 일반 텍스트 인터페이스에 시각적인 Repository Graph를 추가했다. 실험 설정에서 Input Token 사용량은 최대 26% 감소했고 Issue-Resolution Accuracy는 유지되거나 상승했다. 반면 시각 정보만 사용하는 방식은 더 나빴고 Token 비용을 증가시켰다. 여기에서도 결론은 “모듈형 아키텍처가 26% 적은 Token을 쓴다”가 아니다. 연구는 Multimodal Agent에게 Repository 구조를 표현하는 방법을 다룬다.

마찬가지로 ASE 2026에 채택된 DyRetriever는 Partial Dependency Graph를 사용해 Repository-Level Code Generation에서 의존성을 따라 필요한 Context를 수집한다. 저자들은 비교한 RAG Baseline 대비 CoderEval과 DevEval에서 각각 25.63%, 59.73%의 상대 Pass@1 개선을 보고했으며, 정적으로 Dependency Graph를 구축하는 Baseline보다 7.4배 빠른 속도를 보고했다. 이것은 Dependency Structure가 Context Retrieval에 도움이 될 수 있다는 근거이지, 어떤 특정 소프트웨어 아키텍처 Pattern이 우월하다는 근거는 아니다.

다른 최신 연구도 같은 그림에 들어간다. Agent Retrieval Bench는 Agent가 다음에 필요한 파일을 실제로 찾는가라는 문제를 분리해서 본다. 분석한 Logged Trajectory의 27~35%에서는 Gold File을 단 하나도 찾지 못했다. 동시에 통제된 Intervention에서는 Retrieval-based Initial Context가 무작위의 관련 없는 Context보다 이후 Exploration을 더 적게 필요로 했다.

RepoMirage는 Repository-Context Reasoning 요구가 커지는 과제에서 Agent의 성능이 크게 떨어질 수 있다고 보고하고, 저자들이 exploration drift라고 부르는 패턴을 설명한다. Agent는 더 많은 Repository Context를 보지만, 그 Exploration을 올바른 구조 이해로 안정적으로 바꾸지 못한다. 두 단계의 Structure-first 접근은 실험 설정에서 성능을 개선했다. 하지만 이 연구는 2026년 Preprint 또는 Workshop 성격의 작업이며, 일반적인 아키텍처 규칙의 증거는 아니다.

따라서 현재 연구는 아직 우리의 아키텍처 질문에 직접 답하지 못한다.

하지만 왜 그 질문이 흥미로운지는 보여 준다.

Repository Navigation
Context Selection
Dependency Reasoning
Fault Localization
제한된 Context

이것들은 Coding Agent의 새로운 기술적 문제다.

명확한 모듈
적은 Dependencies
Information Hiding
안정적인 Contracts
로컬 책임

이것들은 소프트웨어의 일부를 안전하게 바꾸기 위해 얼마나 많은 시스템을 이해해야 하는가라는 질문에 대해 소프트웨어 엔지니어링이 오래전부터 내놓은 답이다.

이 두 선이 지금 만나기 시작한다.

더 작은 해 공간은 더 적은 Token을 의미할까?

이 연결에서 또 하나의 가설이 나온다.

가능한 한 조건이 비슷한 두 시스템을 생각해 보자.

같은 Model
같은 Agent
같은 Tooling
같은 Test Quality
같은 Linter
비슷한 Task

System A는 결합이 강하고, 가능한 Dependency Path가 많고, Ownership이 불명확하다.

System B는 경계가 명확하고, 허용된 Dependency Path가 적고, Ownership이 분명하다.

내 컴퓨터과학적 직관은 이렇다.

더 큰 구조적 의사결정 공간
↓
더 많은 Exploration 가능성
↓
더 많은 관련 후보
↓
잠재적으로 더 많은 Files / Tool Calls / Context
↓
더 많은 잘못된 경로
↓
더 많은 Rework

반대로:

더 작은 구조적 의사결정 공간
↓
더 적은 구조적 후보
↓
잠재적으로 더 적은 Exploration
↓
더 작은 관련 Working Set
↓
더 적은 잘못된 경로
↓
잠재적으로 더 낮은 전체 비용

메커니즘만 보면 그럴듯하다. 하지만 여전히 말해야 할 것이 있다.

지금까지 나는 이것을 직접적으로 보여 주는 신뢰할 만한 측정을 찾지 못했다.

현재 연구는 인접한 효과를 측정한다. 구조화된 Repository 표현은 Exploration을 더 효율적으로 만들 수 있다. Dependency-aware Retrieval은 관련 Context를 더 잘 선택할 수 있다. *What Context Does a Coding Agent Actually Need to Act?*는 Oracle Localization을 고정한 조건에서, SWE-bench Verified 설정의 압축된 Context가 훨씬 적은 Context Token으로 전체 파일 수준의 결과에 도달할 수 있다고 보여 준다. 하지만 이 연구는 의도적으로 Localization을 고정하고 Code Representation만 바꾼다. 따라서 더 잘 모듈화된 Codebase 자체가 Token 수요를 줄이는지는 역시 조사하지 않는다.

그러므로 조심스러운 표현은 다음과 같다.

다른 조건이 같다면, 더 작은 구조적 의사결정 공간은 더 적은 Exploration을 필요로 하고 따라서 더 낮은 Inference 비용으로 이어질 수 있다. 메커니즘상 가설은 그럴듯하다. 하지만 직접적인 실증은 아직 없다.

언젠가 이것을 통제된 방식으로 직접 시험해 보고 싶다.

같은 애플리케이션의 두 가지 구조 변형을 비교하는 것이, 테스트도 없는 Big Ball of Mud와 문서가 완벽하고 완전한 Agent Harness를 가진 모듈형 시스템을 비교하는 것보다 훨씬 흥미로울 것이다. 그렇지 않으면 너무 많은 변수가 한 번에 바뀌어 무엇을 측정했는지 알 수 없게 된다.

더 흥미로운 비용 지표는 첫 번째 Run 뒤에 있다

언젠가 이 가설을 측정하더라도, 나는 한 번의 Generation이 사용한 Token 수만 보고 싶지는 않다.

Agent 하나는 아주 작은 Context로 싸고 빠르게 해결책을 만들 수 있지만, 이후 세 번의 수정 단계가 필요할 수 있다.

다른 Run은 처음부터 더 많은 Context를 사용하지만 관련 Dependencies를 더 잘 이해하고 첫 시도에서 수용 가능한 변경을 만들 수 있다.

그래서 장기적으로 내가 더 관심을 가지는 것은 이것이다.

검증된 수용 가능한 변경 하나당 비용.

여기에는 한 번의 응답 Token뿐 아니라 Exploration, Tool Calls, Tests, 수정, Rework가 실제로 받아들일 수 있는 상태에 도달할 때까지 모두 포함된다.

이 주제는 별도의 글이 필요하다. **「Agentic Work의 경제학」**에서 더 자세히 다룰 예정이다.

이 글에서는 가설만으로 충분하다. 아키텍처는 구조적 위험만 줄이는 것이 아닐 수도 있다. 비슷한 조건에서 더 작은 의사결정 공간이 경제적으로도 흥미로울 수 있다.

단지 이 두 번째 주장은 현재 첫 번째 주장보다 훨씬 덜 입증되어 있다.

처리량이 높아질수록 경계의 가치는 커진다

이제 다시 글의 시작점으로 돌아온다.

인간은 Coding Agent가 생기기 훨씬 전부터 Architecture Drift를 만들었다. 인간은 Shared Service를 쓰레기통으로 만들고, Feature 경계를 깨뜨리고, 세 가지 State-Management Pattern을 같은 시스템에 나란히 넣으면서 모든 예외를 급한 Ticket으로 정당화했다.

AI는 새로운 종류의 구조적 잘못을 발명하지 않는다. 달라지는 것은 그런 결정이 생길 수 있는 속도다.

높은 변경 처리량
+
큰 구조적 의사결정 공간
=
일관성 없는 로컬 결정이
생길 기회 증가

이것은 종말론이 아니다.

오히려 반대다. 나는 오늘날 Coding Agent가 해낼 수 있는 것에 깊은 인상을 받고 있고, 실제로도 많이 사용한다. 그렇기 때문에 그 속도를 어떻게 수천 번의 추가 변경 뒤에도 이해 가능한 시스템으로 바꿀 수 있을지에 관심이 있다.

아키텍처가 경계를 만들지 않으면, AI는 생산성과 함께 구조적 임의성도 확대할 수 있다.

처리량이 높아질수록 매 Run이 같은 암묵적 아키텍처를 직감적으로 재구성해 주기를 기대하고 싶지 않다.

시스템 자체가 무엇이 유효한지 말해 주기를 원한다.

아키텍처는 모든 문장에 대한 설명서가 아니다

중요한 구분 하나는 남아 있다. 나는 Coding Agent를 규칙으로 둘러싸서 아무 결정도 못 하게 만들자는 것이 아니다. 모든 애플리케이션을 같은 Layering에 밀어 넣자는 것도 아니다.

시스템에는 이해 가능하고, 일관되고, 검증 가능한 경계가 필요하다. 그 경계를 어떤 구체적인 아키텍처가 만드는지는 문제에 달려 있다.

작은 CRUD Service는 스무 개의 비즈니스 Domain을 가진 애플리케이션보다 훨씬 적은 구조가 필요할 수 있다. Modular Monolith가 맞을 수도 있고, SCS 지향 분할이 맞을 수도 있다. Layering은 도움이 될 수도 있고 단지 추가 부담일 수도 있다. Architecture Constraints는 그 자체가 목적이 아니다.

그것들은 하나의 위험 질문에 답한다.

어떤 구조적 결정을
매 변경마다 다시 협상하고 싶지 않은가?

그런 곳에 강한 경계가 있어야 한다.

그 경계 안에서는 Agent가 자유롭게 일할 수 있다.

이것은 5번 글과도 연결된다. 서로 다른 해결책은 계속 허용된다. 단지 새로운 지식을 만들지 않고 추가적인 시스템 변동성만 만드는 차원의 변동을 제한할 뿐이다.

아키텍처는 변동성를 없애지 않는다. 원하지 않는 변동성를 없앤다.

해 공간은 더 작아진다

최근 글들은 이제 꽤 분명한 그림을 만든다. 4번 글은 Agent가 사용할 수 있는 Context로만 일할 수 있음을 보여 주었다. 5번 글은 그 Context 안에서 서로 다른 해결 경로를 선택할 수 있음을 보여 주었다. 6번 글은 그럴듯한 경로도 틀릴 수 있음을 보여 주었다. 아키텍처는 Context나 Verification을 대신하지 않지만, 관련 작업 공간을 줄이고 특정 구조적 오류를 기계적으로 잡아낼 수 있다. 7번 글은 Requirements를 첫 번째 경계로 소개했다.

이제 두 번째 경계가 추가된다.

Requirements
→ 무엇이 반드시 성립해야 하는가?

Architecture Constraints
→ 어떤 구조적 경로가 허용되는가?

이것이 Agent를 결정론적으로 만들지는 않는다.

더 작고 더 의미 있는 작업 공간을 제공할 뿐이다.

그리고 그것이 내가 생각하는 Agentic 소프트웨어 개발에서 좋은 아키텍처의 역할이다.

아키텍처는 Coding Agent의 의사결정 공간을 줄인다.

모든 단계를 미리 지시해서가 아니다.

Modules, Contracts, Ownership, Dependency Direction, Invariants를 통해서다.

무엇이 함께 속하는지를 눈에 보이게 하는 구조를 통해서다.

그리고 가장 좋은 경우에는, 어딘가에 설명만 되어 있는 규칙이 아니라 시스템 자체가 검증하는 규칙을 통해서다.

Agent A, Agent B, Agent C가 작업했더라도 프로젝트는 여전히 한 명의 개발자가 쓴 것처럼 읽혀야 한다.

점점 더 강력한 Coding Agent가 등장하는 세상에서 좋은 아키텍처가 덜 중요해지는 것은 아닐지도 모른다.

어쩌면 바뀌는 것은 어디에서 그 레버리지가 생기는가일 뿐이다.

모든 개발자에게 코드를 어떻게 써야 하는지 설명하는 쪽에서 조금 멀어지고,

사람과 Agent를 포함한 여러 참여자가 매 Feature마다 전역 구조를 다시 발명하지 않고 로컬하게 일할 수 있는 공간을 만드는 쪽으로 이동한다.

그런 의미에서 아키텍처는 시스템 안에서 코드가 무엇을 할 수 있는지에 대한 경계를 정의한다.

다음 글에서는 다른 종류의 경계를 살펴봐야 한다.

Agent는 코드만 바꾸는 것이 아니다. Repository 내용을 읽고, Tool을 사용하고, 시스템 경계를 넘어 정보를 처리할 수도 있다.

그러면 질문은 더 이상 이것만이 아니다.

코드는 어떤 Dependencies를 넘어갈 수 있는가?

다음 질문도 필요하다.

Agent는 어떤 정보를 볼 수 있는가?

그리고 그 정보는 어떤
Trust Boundaries를 넘어갈 수 있는가?

다음 글의 주제는 이것이다. 개인정보 보호, 기밀성 & Trust Boundaries.

출처와 맥락

• David L. Parnas – On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM 15(12), 1053–1058, 1972년 12월, DOI 10.1145/361598.361623. Parnas는 서로 다른 모듈 분해 기준을 조사하고 이해 가능성, 유연성, Information Hiding 등을 통해 모듈화를 설명한다. 이 글에서는 좋은 경계가 지식과 변경의 후속 효과를 국소화한다는 생각의 역사적 근거로 사용한다. 원문은 LLM이나 Coding Agent를 전혀 다루지 않으며, 그 연결은 오늘날의 해석이다.

• W. P. Stevens, G. J. Myers, L. L. Constantine – Structured Design. IBM Systems Journal 13(2), 115–139, 1974, DOI 10.1147/sj.132.0115. 이 연구는 기능 모듈을 통해 프로그램 복잡도를 줄이는 기법을 설명하며, 이후 Cohesion과 Coupling 논의의 고전적인 출처에 속한다. 여기서는 통제된 의존성이 AI 시대에 새로 만들어진 개념이 아니라는 점을 보여 주기 위해 사용한다. 이 연구 역시 Agent Performance에 대한 직접적인 결론을 허용하지 않는다.

• Brian Foote, Joseph W. Yoder – Big Ball of Mud. PLoP ’97, Technical Report WUCS-97-34; 이후 Pattern Languages of Program Design 4, Addison-Wesley, 2000에 수록. Foote와 Yoder는 일관된 설계보다 실용적인 성장과 수선에 의해 조직된 느슨하고 haphazard한 시스템을 설명한다. 이 글에서는 Big Ball of Mud를 제한된 구조적 해 공간의 반대 사례로 사용한다. 원 연구는 물론 Coding Agent를 다루지 않는다.

• OpenAI – Ryan Lopopolo: Harness engineering: leveraging Codex in an agent-first world. 2026년 2월 11일. 이 Engineering Report는 내부의 완전 Agent-generated 소프트웨어 프로젝트를 설명한다. 특히 고정된 Layer, 엄격히 검증되는 Dependency Direction, 적은 수의 허용 edge, Custom Linter, Structural Test가 중요하다. OpenAI는 여기서 구현을 Micromanage하기보다 Invariant를 강제한다는 실무 원칙을 제시한다. 매우 가치 있는 실무 사례지만 통제된 과학 연구는 아니며, 보편적인 아키텍처 법칙으로 일반화해서는 안 된다.

• Self-contained Systems – 공식 SCS 아키텍처 설명. 이 글에서 SCS는 비즈니스 자율성, 자체 데이터와 Business Logic, 적은 외부 의존성을 설명하는 예시로만 사용한다. SCS가 LLM에 과학적으로 우월하다는 결론은 내리지 않는다.

• Tsvi Cherny-Shahar, Amiram Yehudai – Repository Intelligence Graph: Deterministic Architectural Map for LLM Code Assistants. arXiv:2601.10112, 2026. RIG는 Coding Agent에게 Build와 Test 정보에서 도출한 아키텍처 지도를 제공한다. 여덟 개 Repository와 세 개의 상용 Agent에서 저자들은 구조적 질문에 대해 더 높은 정확도와 훨씬 낮은 처리 시간을 보고한다. 여덟 개 Repository 중 일곱 개는 Synthetic이며, 일부 Agent에서는 실제 Token 소비 대신 시간을 Proxy로 사용한다. 무엇보다 이 연구는 명시적인 아키텍처 표현을 연구하지, 기반 소프트웨어 아키텍처의 품질을 연구하지 않는다.

• Dongjian Ma et al. – LLM Agents Can See Code Repositories. ASE 2026 / arXiv:2606.14061. 이 연구는 텍스트 인터페이스를 보완하는 시각적 Repository Graph를 조사한다. 평가 설정에서 Input Token 소비는 최대 26% 감소했고 Accuracy는 유지되거나 향상되었다. 반면 시각 정보만 사용하는 방식은 더 나빴다. 이것은 구조화된 Repository 정보가 Exploration을 더 효율적으로 만들 수 있음을 지지하지만, 더 모듈화된 아키텍처 자체가 26%의 Token을 절약한다는 증거는 아니다.

• Zhongxin Liu et al. – Effective and Efficient Context Retrieval via Partial Dependency Graph for Repository-Level Code Generation. ASE 2026 / arXiv:2608.01927. DyRetriever는 on-demand Partial Dependency Graph를 따라 관련 Repository Context를 선택한다. CoderEval과 DevEval 결과는 Dependency-aware Retrieval의 중요성을 지지한다. 이 연구는 Retrieval 방법을 다루며, 다른 조건이 같은 상태에서 서로 다른 소프트웨어 아키텍처의 효과를 비교하지 않는다.

• Bowen Qin, Yi Xie – Agent Retrieval Bench: Evaluating Repository Context Retrieval for Coding Agents. arXiv:2607.24882, 2026. 이 Benchmark는 실제 Patch Generation 이전의 Context Acquisition을 분리해서 본다. 실제 Agent Trajectory가 관련 파일을 완전히 찾지 못하는 경우가 많고, 좋은 Initial Context가 이후 Exploration을 줄일 수 있음을 보여 준다. Benchmark가 측정하는 것은 Retrieval이며, 더 좋은 Retrieval이 자동으로 올바른 Patch나 더 좋은 아키텍처를 뜻하지는 않는다.

• Brian Sam-Bodden – What Context Does a Coding Agent Actually Need to Act? arXiv:2607.09691, 2026. 이 연구는 Oracle을 이용해 변경 위치의 Localization을 고정하고, SWE-bench Verified에서 서로 다른 Context Representation을 비교한다. 압축된 Context는 이 설정에서 훨씬 더 Token-efficient할 수 있다. 바로 Localization이 고정되어 있기 때문에, 이 연구는 “더 작은 아키텍처 의사결정 공간이 더 적은 Token을 만든다”는 가설에 직접적인 근거를 제공하지 않는다. 따라서 인접한 근거이지 확인 근거는 아니다.

• Hanyu Li et al. – RepoMirage: Probing Repository Context Reasoning in Code Agents with Perturbations. arXiv:2605.26177, 2026. 저자들은 구조는 바뀌지만 의미는 유지되는 perturbation 아래에서 Repository-Context Reasoning을 연구하고, exploration drift를 관찰된 문제로 설명한다. Structure-first Prototype은 실험에서 결과를 개선했다. 현재 단계는 Preprint 또는 Workshop 성격의 연구이므로, 결과는 확립된 일반 법칙이 아니라 초기 근거로 읽어야 한다.