AI 생성 코드의 아키텍처 드리프트 방어: 적합도 함수(Fitness Functions) 기반 거버넌스 설계

1. 생산성의 역설: AI 코딩 에이전트가 가속하는 '보이지 않는 아키텍처 드리프트'

소프트웨어 개발 현장에서 AI 코딩 에이전트(GitHub Copilot, Cursor, Claude Code 등)의 도입은 엔지니어링 속도를 전례 없는 수준으로 끌어올렸습니다. 개발자가 프롬프트를 입력하면 수십 초 만에 복잡한 CRUD API와 비즈니스 로직, 단위 테스트 코드가 체계적이고 검증 가능한 문법으로 완성됩니다. 스프린트당 완료되는 티켓의 수가 증가하고, 개별 엔지니어의 기능 구현 시간은 획기적으로 단축되었습니다.

그러나 이 화려한 지표의 이면에서 대다수 엔지니어링 리더들이 심각한 기술적 위기감을 호소하고 있습니다. 바로 아키텍처 드리프트(Architectural Drift)와 아키텍처 침식(Architectural Erosion)의 급격한 가속화입니다.

[전통적 개발 환경]
엔지니어의 숙고 -> 설계 문서 검토 -> 점진적 구현 -> 상대적으로 완만한 구조적 부채 축적

[AI 에이전트 개발 환경]
대화형 프롬프트 -> 국소 최적화 코드 대량 양산 -> 전역 경계 무시 -> 초고속 아키텍처 드리프트 폭증!

AI 코딩 에이전트의 근본적인 한계는 '국소적 최적화(Local Optimization)'에 갇혀 있다는 점입니다. 대규모 언어 모델(LLM)은 현재 주어진 파일, 주변 컨텍스트, 프롬프트의 직접적인 요구사항을 충족하는 코드를 생성하는 데 최적화되어 있습니다. 모델은 주어진 티켓의 요구사항을 통과시키기 위해 가장 손쉬운 방법을 선택합니다.

• 순수 도메인 계층(Domain Layer)에서 인프라스트럭처나 웹 프레임워크의 특정 유틸리티를 직접 임포트하여 사용합니다.
• 서로 분리되어야 할 마이크로서비스나 바운디드 컨텍스트(Bounded Context) 간의 데이터베이스 엔티티를 무단으로 직접 참조합니다.
• 빠른 데이터 조회를 위해 서비스 간 양방향 순환 참조(Circular Dependency)를 생성합니다.
• 팀 내에 이미 엄격히 확립된 공통 로깅·예외 처리 추상화 계층을 무시하고, 임의의 서드파티 라이브러리를 직접 호출하는 보일러플레이트를 삽입합니다.

이러한 변경점들은 단위 테스트를 실행하면 모두 통과합니다. 화면에서도 정상 동작하며, 비즈니스 요구사항도 완벽히 만족하는 것처럼 보입니다. 그러나 3~6개월이 흐른 뒤 시스템은 회복 불가능한 '스파게티 모놀리스'로 퇴화합니다. 모듈 간 경계는 완전히 흐려지고, 한 곳을 수정하면 전혀 관계없는 3개 서브시스템이 연쇄 장애를 일으키는 취약한 상태에 도달합니다. 국소적 성공이 전역적 파멸을 잉태하는 전형적인 시스템 사고(System Thinking)의 비극입니다.

2. 인간 코드 리뷰의 붕괴: 왜 PR 리뷰는 구조적 붕괴를 막지 못하는가

많은 조직이 이 문제에 직면했을 때 내놓는 첫 번째 대책은 "시니어 엔지니어들의 코드 리뷰를 강화하자"는 훈계입니다. 풀 리퀘스트(PR) 템플릿에 아키텍처 준수 항목을 추가하고, 테크리드가 모든 변경점을 꼼꼼히 살피도록 요구합니다.

그러나 인간공학과 소프트웨어 엔지니어링 실증 연구는 이 접근법이 필연적으로 실패할 수밖에 없음을 증명합니다. 소프트웨어 아키텍처 침식 연구(Rosik et al., 2011, IEEE ICSE)에 따르면, 일반적인 인간 코드 리뷰어의 복합적 아키텍처 규칙 위반 적발률은 20% 미만에 불과했습니다. 특히 AI 도구 도입으로 PR의 크기와 빈도가 폭증하면서 이 수치는 더욱 처참하게 떨어집니다.

+-----------------------------------------------------------------------------------+
|                  인간 코드 리뷰어가 아키텍처 드리프트를 놓치는 3대 인지적 장벽           |
+-----------------------------------------------------------------------------------+
| 1. 문맥 폭증 (Context Explosion): 단일 PR의 30개 파일 diff에서 거시적 의존성 그래프를  |
|    머릿속으로 멘탈 모델링하는 것은 인간 작업 기억(Working Memory)의 용량을 초과함       |
|                                                                                   |
| 2. 기능 편향 (Functional Bias): 리뷰어의 시선은 '요구한 기능이 올바르게 도는가'에     |
|    집중되며, import 경로 하나가 야기하는 장기적 계층 결합도는 시각적으로 은폐됨         |
|                                                                                   |
| 3. 피로와 리뷰 병목: 쏟아지는 AI 생성 PR 앞에서 시니어는 'LGTM(Looks Good To Me)' 도장을 |
|    찍는 승인 자판기로 전락하며 팀 전체의 딜리버리 병목을 유발함                       |
+-----------------------------------------------------------------------------------+

수십 줄의 파일 diff를 보면서 "이 서비스가 저 서비스의 내부 도메인 모델을 침범하고 있는가?", "이 패키지 간의 구심 결합도(Afferent Coupling)가 허용 한도를 넘었는가?"를 인간의 육안으로 판별하는 것은 물리적으로 불가능합니다.

인간의 주의력과 윤리적 헌신에 기대어 품질을 지키려는 시도는 엔지니어링이 아닙니다. 소프트웨어 구조의 무결성은 인간의 의지가 아니라 기계적인 시스템 가드레일을 통해 지켜져야 합니다.

3. 진화적 아키텍처와 '적합도 함수(Architectural Fitness Functions)'의 핵심 원리

이 딜레마를 해결하기 위한 강력한 아키텍처 공학 프레임워크가 바로 닐 포드(Neal Ford), 레베카 파슨스(Rebecca Parsons), 패트릭 쿠아(Patrick Kua)가 제창한 진화적 아키텍처(Building Evolutionary Architectures)와 '적합도 함수(Architectural Fitness Functions)'입니다.

생물학에서 적합도 함수가 유기체가 환경에 얼마나 잘 적응했는지를 수치화하듯, 소프트웨어 엔지니어링에서의 적합도 함수는 "시스템의 구조와 비기능적 요구사항(NFR)이 정의된 아키텍처 목표와 불변식에 얼마나 부합하는지를 지속적으로 평가하는 실행 가능한 메커니즘"을 뜻합니다.

적합도 함수는 정적인 위키 문서나 아키텍처 가이드라인을 "빌드가 실패하는 실행 가능한 테스트 코드"로 전환합니다.

[기존 방식: 종이 호랑이 문서]
- Confluence 문서: "도메인 서비스는 Web/Controller 계층을 참조해서는 안 됨"
- 현실: 주니어나 AI가 바쁘다고 import Controller를 박아도 아무도 모름 -> 1년 뒤 발견

[적합도 함수: 물리적 철조망]
- CI/CD 파이프라인: ArchUnit 테스트 실행
- 현실: AI가 잘못된 import를 한 줄이라도 추가하는 순간 git push 즉시 빌드 실패(Exit 1)
- 결과: 잘못된 아키텍처 코드는 코드베이스에 1초도 머무를 수 없음

적합도 함수는 크게 세 가지 특성으로 분류됩니다:
1. 원자적 vs 총체적 (Atomic vs Holistic): 단일 모듈의 패키지 규칙을 검증하는가(원자적), 분산 트랜잭션의 지연 시간과 보안 경계를 시스템 전체 차원에서 검증하는가(총체적).
2. 지속적 vs 주기적 (Continuous vs Periodic): 모든 커밋과 PR마다 CI에서 신속하게 도는가(지속적), 주간 부하 테스트나 월간 보안 감사 배치로 실행되는가(주기적).
3. 결정론적 vs 에이전틱 (Deterministic vs Agentic): 정적 분석과 AST 기반으로 100% 참/거짓을 판정하는가(결정론적), LLM 루브릭을 통해 도메인 명명 규칙과 의사결정 기록(ADR) 정합성을 판정하는가(에이전틱).

▲ 결정론적 정적 분석부터 에이전틱 루브릭 평가까지, AI 코드 폭주를 차단하는 3단계 적합도 함수 파이프라인 아키텍처

4. 실무 구현: 결정론적 ArchUnit 가드레일부터 에이전틱 적합도 함수까지

그렇다면 시니어 엔지니어는 현업 팀의 파이프라인에 적합도 함수를 어떻게 구체화해야 할까요? Java/Spring 생태계의 사실상 표준인 ArchUnit과 Node.js/TypeScript 환경의 dependency-cruiser를 활용한 실전 구현 패턴을 살펴봅니다.

1) 헥사고날 / 클린 아키텍처 계층 침범 방지 (ArchUnit)

AI 코딩 에이전트가 가장 흔하게 저지르는 실수는 도메인 엔티티나 유스케이스 안에 JPA 어노테이션이나 Spring 프레임워크 패키지, HTTP 서블릿 객체를 끌어들이는 것입니다. 이를 원천 차단하는 원자적 적합도 함수입니다.

package com.company.architecture;

import com.tngtech.archunit.core.importer.ImportOption;
import com.tngtech.archunit.junit.AnalyzeClasses;
import com.tngtech.archunit.junit.ArchTest;
import com.tngtech.archunit.lang.ArchRule;

import static com.tngtech.archunit.library.Architectures.onionArchitecture;
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.noClasses;

@AnalyzeClasses(packages = "com.company.order", importOptions = {ImportOption.DoNotIncludeTests.class})
public class DomainPurityFitnessTest {

    // 1. 도메인 계층의 순수성 보장: 프레임워크 및 외부 인프라 의존 금지
    @ArchTest
    public static final ArchRule domain_must_not_depend_on_external_frameworks =
        noClasses()
            .that().resideInAPackage("..domain..")
            .should().dependOnClassesThat()
            .resideInAnyPackage("org.springframework..", "javax.persistence..", "jakarta.persistence..")
            .because("도메인 모델은 특정 ORM이나 프레임워크에 종속되지 않는 순수 POJO여야 합니다.");

    // 2. 어니언(헥사고날) 아키텍처 계층 불변식 강제
    @ArchTest
    public static final ArchRule onion_architecture_boundaries_must_be_respected =
        onionArchitecture()
            .domainModels("com.company.order.domain.model..")
            .domainServices("com.company.order.domain.service..")
            .applicationServices("com.company.order.application..")
            .adapter("persistence", "com.company.order.adapter.out.persistence..")
            .adapter("web", "com.company.order.adapter.in.web..")
            .because("모든 어댑터는 인바운드/아웃바운드 포트를 통해서만 코어와 통신해야 합니다.");
}

이 테스트 코드는 평범한 JUnit 5 테스트처럼 동작하지만, mvn test나 ./gradlew check 시점에 클래스파일의 바이트코드를 파싱하여 의존성 그래프를 전수 검사합니다. AI 에이전트가 빠른 작성을 위해 도메인 서비스에 @Transactional이나 HttpServletRequest를 추가하면, 컴파일 후 즉시 테스트 실패로 PR 머지가 차단됩니다.

2) 패키지 간 순환 의존성(Cycle) 차단

모듈형 모놀리스(Modular Monolith)나 멀티 모듈 시스템에서 AI가 생성한 코드는 쉽게 순환 의존성 고리를 만듭니다. 순환 의존성은 독립적 배포와 격리 테스트를 완전히 불가능하게 만듭니다.

import static com.tngtech.archunit.slices.syntax.SlicesRuleDefinition.slices;

public class CyclomaticIntegrityFitnessTest {

    @ArchTest
    public static final ArchRule no_cycles_between_business_slices =
        slices().matching("com.company.order.(*)..")
            .should().beFreeOfCycles()
            .because("서브 도메인 슬라이스 간의 순환 참조는 시스템의 진화적 확장을 가로막습니다.");
}

3) 에이전틱 적합도 함수(Agentic Fitness Functions)의 도입

2026년 현재 가장 혁신적인 발전은 정적 바이트코드 분석을 넘어선 에이전틱 적합도 함수(Agentic Fitness Functions)의 등장입니다. 정규표현식이나 AST 분석으로는 "이 변경사항이 우리 팀의 아키텍처 결정 기록(ADR)의 설계 철학을 위배하는가?", "비즈니스 예외 네이밍이 유비쿼터스 언어와 일치하는가?"와 같은 시맨틱한 판단을 내리기 어렵습니다.

에이전틱 적합도 함수는 LLM 평가기(Evaluator)를 CI 파이프라인에 심어, 변경된 diff와 사내 ADR 문서를 대조하는 루브릭(Rubric) 기반 평가를 수행합니다.

+-----------------------------------------------------------------------------------+
|               에이전틱 적합도 함수 (Agentic Fitness Function) 파이프라인              |
+-----------------------------------------------------------------------------------+
|  [PR 변경 Diff] + [사내 ADR 저장소] + [바운디드 컨텍스트 온톨로지]                       |
|                                |                                                  |
|                                v                                                  |
|  +-----------------------------------------------------------------------------+  |
|  | LLM 아키텍처 심사관 (Strict Evaluator Agent)                                    |
|  | - 평가 루브릭: 도메인 격리성(1~5점), 예외 처리 계약(1~5점), 멱등성 보장(1~5점)       |
|  | - 판정 기준: 전 항목 4점 이상 & 심각한 아키텍처 모순 0건 필수                       |
|  +-----------------------------------------------------------------------------+  |
|                                |                                                  |
|                                v                                                  |
|  [구조적 채점표 및 위반 리포트 생성 -> 기준 미달 시 PR 머지 블로킹]                     |
+-----------------------------------------------------------------------------------+

5. 스태프 엔지니어의 커리어 레버리지: 코드 감시자에서 '거버넌스 아키텍트'로

이러한 적합도 함수 시스템을 도입하는 것은 단순한 테스트 도구 추가가 아닙니다. 이는 시니어 및 스태프 엔지니어(Staff Engineer)의 커리어 궤적을 송두리째 바꾸는 전략적 레버리지(Strategic Leverage)입니다.

전통적인 시니어 개발자의 일상은 비극적이었습니다. 후배 개발자들과 AI가 쏟아내는 수십 개의 PR에 갇혀 하루 종일 코드를 읽고, "이거 왜 계층 위반하셨나요?", "이거 순환 참조입니다"라는 잔소리성 리뷰 댓글을 수십 개씩 다느라 정작 자신의 설계와 심도 있는 기술 전략 연구는 손도 대지 못했습니다. 이는 조직적으로도 병목이며, 개인의 커리어 측면에서도 극히 소모적인 저레버리지 노동입니다.

[레벨 1: 주니어/미드 엔지니어]
- 산출물: 개별 기능 코드, 단위 테스트
- 영향력: 자신이 직접 작성한 코드 범위 (1x)

[레벨 2: 전통적 시니어 엔지니어 (리뷰 병목)]
- 산출물: 코드 리뷰 피드백, 긴급 장애 패치
- 영향력: 자신이 직접 읽고 승인할 수 있는 수동 감시 범위 (2~3x)

[레벨 3: 스태프 엔지니어 (거버넌스 아키텍트)]
- 산출물: 아키텍처 적합도 함수 하네스, IDP 골든 패스 가드레일, ADR 루브릭
- 영향력: 수십 명의 개발자와 수천 개의 AI 에이전트가 안전하게 질주하는 고속도로 인프라 (20~50x)

스태프 엔지니어의 핵심 책무는 "시스템이 올바른 궤도에서 이탈하지 않도록 기계적인 제어판(Control Plane)을 만드는 것"입니다.

당신이 작성한 20줄의 ArchUnit 적합도 함수는 당신이 휴가를 가든, 회사를 비우든, 새벽에 AI 에이전트가 100개의 PR을 올리든 간에 단 1초의 지침도 없이 24시간 365일 조직의 아키텍처를 수호합니다. 이것이 바로 기술 리더십에서 말하는 진정한 아키텍처 레버리지(Architectural Leverage)입니다.

독자가 팀의 리더로서 바로 활용할 수 있도록, 팀 아키텍처 헌장에 적합도 함수 도입을 명시하는 표준 제안서 템플릿을 제공합니다.

# 🏛️ 아키텍처 적합도 함수(Fitness Functions) 도입 헌장

## 1. 제안 배경 및 핵심 원칙

- **문제 진단**: AI 코딩 도구 도입 이후 모듈 간 결합도 증가 및 도메인 계층 침범(Architectural Drift) 급증.
- **거버넌스 원칙**: "문서로만 존재하는 규칙은 규칙이 아니다. 아키텍처 불변식은 빌드를 차단하는 코드로 존재해야 한다."

## 2. 3대 필수 적합도 검증선

1. **도메인 격리성 (Domain Purity)**:
   - 도메인 패키지는 Web, DB, Framework 패키지를 역참조할 수 없다. (위반 시 빌드 Exit 1)
2. **비순환 의존성 (Acyclic Dependencies)**:
   - 비즈니스 슬라이스 간의 직접적인 순환 참조는 100% 금지하며 이벤트 버스 또는 인터페이스로 디커플링한다.
3. **NFR 성능 가드레일 (Performance Bounds)**:
   - 주요 트랜잭션의 p95 데이터베이스 쿼리 수 n+1 발생 시 통합 테스트에서 예외를 던진다.

## 3. 예외 승인 및 기술 부채 프로세스

- 비즈니스 긴급성으로 인해 부득이하게 적합도 규칙을 우회해야 할 경우:
  1. `@ArchIgnore` 어노테이션에 만료 기한(Jira 티켓 번호) 명시
  2. 테크리드 및 아키텍처 위원회의 2-Key 승인 필수
  3. 14일 이내 부채 해소 미완료 시 빌드 경고가 차단(Failure)으로 승격

6. 적합도 함수 도입의 안티패턴과 실무적 주의사항

적합도 함수는 강력하지만, 잘못 설계되면 개발팀의 생산성을 질식시키는 거대한 관료주의적 족쇄로 변질될 수 있습니다. 도입 시 우선적으로 경계해야 할 3가지 안티패턴이 있습니다.

1. 빅뱅(Big Bang) 도입으로 인한 빌드 전면 중단:
2. 수년 된 레거시 코드베이스에 첫날부터 체계적이고 검증 가능한 클린 아키텍처 ArchUnit 규칙을 걸면 2,000개의 위반이 쏟아지며 팀의 모든 배포가 멈춥니다. 현명한 엔지니어는 "Freezing(현재 동결) & Ratcheting(점진적 조이기)" 전략을 씁니다. 기존 위반 사항은 베이스라인 파일로 캡처하여 무시하되, 신규 추가되거나 변경된 코드에 대해서만 0개의 위반을 강제하는 방식으로 점진적 정화를 유도해야 합니다.

1. 느린 피드백 루프로 인한 개발자 경험(DX) 파괴:
2. 모든 커밋마다 20분씩 걸리는 총체적 성능·보안 적합도 함수를 돌리면 엔지니어들은 테스트를 우회하기 시작합니다. 패키지 및 의존성 검사(단위 테스트 레벨, <3초)는 매 PR마다 돌리고, 대규모 부하·보안 적합도 검사는 야간 배치(Nightly Build)나 스테이징 배포 파이프라인으로 계층화해야 합니다.

1. 맥락 없는 맹목적 규칙 숭배:
2. 아키텍처는 비즈니스 가치를 전달하기 위해 존재합니다. 아주 작은 마이크로서비스나 일회성 배치 파이프라인에까지 대규모 엔터프라이즈급 헥사고날 규칙을 강요하는 것은 과도한 엔지니어링 낭비입니다. 시스템의 수명 주기와 복잡도에 따라 적합도 함수의 엄격도를 유연하게 조율하는 안목이 필요합니다.

결론: 아키텍처 무결성을 코드화하는 엔지니어가 미래를 지휘한다

AI는 앞으로 더 많은 코드를, 더 빠른 속도로, 더 그럴듯하게 쏟아낼 것입니다. 그러나 어떤 도구도 "우리 회사의 비즈니스 도메인 경계가 3년 뒤에도 건강하게 유지될 것인가?"를 스스로 고민해주지 않습니다.

코드를 한 줄 더 빨리 타이핑하는 능력은 이제 시장에서 아무런 프리미엄을 갖지 못합니다. 진정한 최고 수준의 엔지니어링 가치는 "AI가 맹렬히 질주해도 전체 시스템이 탈선하지 않도록, 보이지 않는 아키텍처 궤도를 견고한 적합도 함수로 설계하는 능력"에서 나옵니다.

개별 PR의 수동 감시자 역할을 내려놓으십시오. 여러분의 아키텍처 철학을 실행 가능한 테스트 코드로 작성하여 파이프라인에 심으십시오. 그것이 바로 AI 시대에 스태프 엔지니어가 조직에 선사할 수 있는 가장 우아하고 강력한 커리어 레버리지입니다.

참고 자료

• Neal Ford, Rebecca Parsons, Pat Kua: Building Evolutionary Architectures
• Thoughtworks Technology Radar: Architectural Fitness Functions
• ArchUnit: Unit Testing Java Architecture Rules