최근 생성 AI에 의한 프로그래밍이 급격히 주류가 되고 있습니다.

발 빠르게 Claude Code를 도입한 기업에서는 "이제 거의 코드를 직접 쓰지 않는다"라고 말하는 엔지니어가 늘어나고 있습니다. 저 자신도 거의 코드를 쓰지 않게 되었으며, 초기 아키텍처 설계(Architecture Design)를 확정하는 데 시간을 쓰고, 나머지는 폭속으로 AI에게 개발을 맡기는 스타일로 변하고 있습니다.

그러한 가운데, 코드 설계도 "AI가 개발하기 쉬운 스타일"로 맞추는 편이 압도적으로 빠르게 개발할 수 있지 않을까 하는 생각이 급속히 퍼지고 있습니다. 이를 "AI-Oriented Architecture (AOA: AI 지향 아키텍처)"라고 부르는 듯합니다.

지금까지 "인간에게 친숙한 모던한 설계"의 최적해로 여겨졌던 DDD나 클린 아키텍처(Clean Architecture)는, AI에게는 길을 잃기 쉬운 복잡한 설계라는 점이 인식되기 시작했습니다. AI 시대에 승리하기 위해서는 기존의 설계를 버리고 AOA로 빠르게 전환해야 할지도 모릅니다.

예시로 "사용자 등록 기능"을 만드는 케이스를 들어 디렉토리 구조의 차이를 비교해 보겠습니다.

DDD나 클린 아키텍처의 사고방식에서는 역할에 따라 파일을 세밀하게 분할하고, 인터페이스(Interface)를 사이에 두어 의존 관계를 느슨한 결합(Loose Coupling)으로 만드는 것이 "깨끗한 코드"로 여겨졌습니다.

src/
├── domain/
│ └── user/
...

이처럼 하나의 기능을 만들기 위해 7~8개의 파일을 넘나드는 구성(파일 호핑, File Hopping))을 하면, AI는 도중에 참조를 놓치거나 토큰(Token)을 낭비하게 됩니다.

AI 시대에는 레이어(Layer, 층)로 나누는 것을 그만두고, 피처(Feature, 기능)별 디렉토리에 모든 것을 가둡니다. 파일 수도 현실적인 2~3개 파일로 집약합니다.

src/
└── features/
└── user/
...

복잡한 추상화(Abstraction)를 거치지 않고 userModel.ts 내에서 직접 SQL이나 ORM 쿼리를 호출(직접 작성)하는 스타일로 맞춤으로써, AI의 생성 정밀도와 개발 속도가 폭발적으로 향상됩니다.

"다층 디렉토리 아키텍처의 종말"은 다소 극단적인 주장처럼 느껴졌을지도 모르지만, 최근 1년(2025~2026년) 사이 소프트웨어 엔지니어링 업계에서 명확한 패러다임 시프트(Paradigm Shift)가 사실로서 일어나고 있습니다.

저명한 iOS/Web 아키텍트인 Krzysztof Zabłocki 씨 등은 AI에게 코드를 쓰게 하는 실험을 거듭한 결과, 복잡한 DI(의존성 주입, Dependency Injection) 컨테이너나 클린 아키텍처의 레이어를 폐지하는 편이 AI의 출력 정밀도를 극적으로 높이고 재작업(Rework)을 줄인다고 보고했습니다. 그들은 "AI의 문맥(Context)을 낭비하지 않는 플랫(Flat)한 설계 사상"으로의 전환을 강력히 권장하고 있습니다.

Vercel의 "v0"나 "Bolt.new"와 같은 최신 UI 생성·개발 도구에서는 컴포넌트(Component), 스타일(Style), 로직(Logic)을 일부러 잘게 나누어 분산시키지 않고, 하나의 파일에 듬뿍 기술하는 스타일이 표준이 되고 있습니다. 이 접근 방식에 의해 AI는 "그 파일만" 수정하면 되기 때문에 버그 혼입률이 극적으로 낮아진다는 것이 실증되었습니다.

GitHub에서 최근 가장 기세가 좋은, 코드를 자율 수정하는 AI 에이전트(Aider나 Claude Code 등)의 운용 데이터에서도 사실이 밝혀지고 있습니다. 추상화 레이어가 높고 파일이 여러 겹으로 나뉘어 있는 리포지토리(Repository)일수록 AI 에이전트는 수정해야 할 파일을 놓쳐 타율(태스크 성공률)이 떨어지고, 반대로 절차적이고 심플한 리포지토리일수록 단번에 정확하게 수정할 수 있다는 특성이 널리 인지되게 되었습니다.

이 AOA(AI 지향 아키텍처)의 근저에 있는 것이 바로 "행동의 국소성(Locality of Behavior: LoB)"이라는 사상입니다.

말만 들으면 매우 이해하기 어려우므로, 간단히 말하면 "어떤 코드의 동작을 바꾸고 싶을 때, 그 파일의 그 위치(Context)만 보면 모든 정보가 완결되어 있는 정도"를 가리킵니다.

지금까지 우리가 해온 "DRY 원칙"이나 "관심사의 분리(Separation of Concerns)"는 LoB와 트레이드오프(Trade-off) 관계에 있습니다.

예를 들어, 사용자 등록의 유효성 검사(Validation) 처리를 공통화(DRY)하는 경우와 직접 작성(LoB)하는 경우를 비교해 보겠습니다.

Before: 과도한 DRY:

유효성 검사 규칙이 src/utils/validation.ts

에 공통화되어 있다. AI가 사용자 등록 로직을 수정할 때, 굳이 다른 파일에 있는 공통 함수의 내용을 읽으러 가야 하며 (파일 호핑 (File Hopping)), 공통 함수 측의 사양에 끌려가 버그를 발생시킬 리스크가 있다.

After: 행동의 국소성(LoB)을 높인 상태:

다소의 중복을 두려워하지 않고, userService.ts 안에 직접 유효성 검사 규칙을 직접 작성한다. AI는 "이 파일의, 이 함수의, 이 몇 줄"만 읽으면 모든 것을 이해할 수 있기 때문에, 어텐션 (Attention, LLM의 주목도)을 한 곳에 집중시켜 완벽한 수정안을 출력할 수 있다.

인간이 보기에는 "다소 작성감이 나빠지더라도, 1개 파일 내, 1개 함수 내에서 이야기를 완결 짓는 것 (LoB를 높이는 것)"
이야말로 AI의 퍼포먼스를 최대화하는 열쇠가 됩니다.

여기서 한 가지 주의할 점은, "무엇이든 1개 파일에 몰아넣는 것"을 권장하는 것은 아니라는 점입니다.

LoB (행동의 국소성)가 AI에게 유리하다고 해서, 모든 DRY를 무시하고 중복 코드를 양산하면 그저 레거시한 스파게티 코드를 만들어낼 뿐입니다.

예를 들어 중요한 도메인 로직 (Domain Logic, 비즈니스 규칙)을 다루는 것이나, 나중에 변경될 가능성이 있는 상수 등도 직접 작성해 버리면, 이번에는 단 하나의 수정만 하고 싶은데도 대량의 파일을 수정해야 하게 되어, 오히려 퍼포먼스가 떨어지거나 버그 투성이가 될 가능성이 있습니다.

이 부분은 아직 최적해를 찾지 못했을 수도 있지만, 제 생각에는 "구조의 DRY는 버려도 좋지만, 도메인 로직은 DRY하게 유지한다"는 균형이 좋은 것 같습니다.

AI를 통해 폭속으로 개발할 수 있게 되면, 다음에 문제가 되는 것은 코드 리뷰입니다.

이제 더 이상 인간만의 리뷰는 불가능해질 것입니다.

현재는 "AI가 리뷰하고, 그것을 또 다른 AI가 수정하는" 자율적인 루프를 어떻게 잘 돌릴 것인가에 대한 시행착오가 이루어지고 있습니다.

최근의 AI 리뷰 동향을 조사해 보았습니다.

다음과 같은 도구와 방식들이 있을 것 같습니다.

• CodeRabbit (코드래빗)

2026년 현재, 많은 테크 기업에서 도입하고 있는 대표적인 사례입니다. PR을 올리면 몇 초 만에 코드의 의도를 요약하고, 버그가 될 만한 부분을 핀포인트로 리뷰해 줍니다. 나아가 "이 지적 사항을 수정하는 커밋을 만들어줘"라고 PR 댓글창에서 채팅하는 것만으로, AI가 코드를 수정하고 푸시까지 완료합니다.

• GitHub Copilot Code Review

GitHub가 2025년 말에 본격 도입하여, 2026년 현재 급속도로 점유율을 넓히고 있습니다. GitHub 네이티브로 동작하며, 보안 취약성이나 설계의 안티 패턴 (Anti-pattern)을 자동으로 걸러냅니다.

• MCP (Model Context Protocol)를 사용한 내제 에이전트

Anthropic (Claude)가 제창한 MCP를 사용하여, 자사의 GitHub 리포지토리와 CI 환경을 연동시킨 독자적인 "자율 수정 에이전트"를 구축하는 기업(특히 스타트업)이 늘어나고 있습니다.

인간은 이제 더 이상 오타나 구문 오류, 임포트 누락 같은 "코드의 정확성"을 확인할 필요가 없습니다.

인간이 할 수 있는 것은 다음의 2가지에 집중하는 것입니다.

사양 확인: 코드는 완벽하게 동작하고 테스트도 통과한다. 하지만 비즈니스 요구사항이나 향후 프로덕트 방침, 법률적인 관점에서 보았을 때 "애초에 이 사양이 맞는가"를 체크한다.

인간 인지 부하의 최종 방어: AI에게는 읽기 쉬워도, 막상 운영 장애가 발생했을 때 "인간이 상황을 파악할 수 있는 단순함"을 갖추고 있는지 확인한다.

지금까지는 "얼마나 복잡한 도메인을 잘 추상화하는가"가 엔지니어의 실력을 보여주는 대목이었습니다. 하지만 앞으로는 "어떻게 AI에게 단번에 올바른 코드를 출력하게 하여 개발 사이클을 최속화할 것인가"의 메커니즘을 만드는 것이 엔지니어링의 주축이 되지 않을까요?

차라리 작성감을 투박하게 만들더라도, AI가 헤매지 않는 심플한 설계 (AOA / LoB)로 기울이고, 인간의 개입을 없애 나간다. 이 메커니즘을 빠르게 구축한 기업이 승리하는 세상이 될 것이라고 생각합니다.