결론: AI 에이전트의 검증 설계를 조사하다가 클린 아키텍처로 돌아왔다

왜 이 글을 쓰려고 했는가 하면, AI 에이전트의 검증역(verifier)에게 어떤 판정 기준을 갖게 할지를 조사하다가, 최종적으로 클린 아키텍처(Clean Architecture)에 대한 설명으로 돌아왔기 때문이다. 지난번 그래프 엔지니어링(Graph Engineering) 기사의 마지막에 나는 이렇게 적었다. 테스트 코드를 작성하는 것, 타입을 작성하는 것, 리뷰 기준을 문서화하는 것――소프트웨어 공학이 예전부터 해온 일의 재정식화(re-formulation)에 가깝지 않을까, 라고. 작성 당시에는 솔직히 깊게 생각하지 않고 쓴 한 문장이었다. 하지만 다시 읽어보며 "그렇다면 그 '예전부터'라는 것을 실제로 직접 따라가 보면 어떻게 될까"라고 생각한 것이 이 글의 출발점이 되었다.

먼저 결론을 쓰겠다. 클린 아키텍처는 누군가가 어느 날 갑자기 생각해낸 신발명이 아니다. 1968년에 "소프트웨어 위기"라는 말이 생겨난 이후, 구조적 프로그래밍(Structured Programming), 모듈 분할(Module Decomposition), 객체 지향(Object-Oriented), 디자인 패턴(Design Pattern), SOLID 원칙, 도메인 주도 설계(Domain-Driven Design), 헥사고날 아키텍처(Hexagonal Architecture), 어니언 아키텍처(Onion Architecture)와 같이, 반세기 이상에 걸쳐 서로 다른 사람들이 동일한 문제(변경에 취약한 소프트웨어)에 도전해 온 결과, 2012년에 Robert C. Martin 씨가 "의존성 규칙(The Dependency Rule)"이라는 핵심 규칙으로 정리한, 현시점에서 널리 받아들여지고 있는 도달점 중 하나다. Functional Core/Imperative Shell이나 Vertical Slice처럼, 이 이후로도 설계론 그 자체는 계속해서 발전하고 있다.

계보: 1968년의 "소프트웨어 위기"부터 오늘날까지를 단숨에 따라가기

먼저 연표를 제시해 두겠다. 세세한 연도를 전부 외울 필요는 없지만, 이후의 이야기는 모두 이 흐름 위에 놓여 있다.

1968년: "소프트웨어"가 처음으로 "위기"라고 불리다

컴퓨터의 성능이 올라감에 따라 다룰 수 있는 소프트웨어의 규모도 커졌다. 그런데 규모가 커질수록 납기 지연, 예산 초과, 버그 투성이 상태가 상시화되었다. 1968년, 서독의 가르미슈에 각국의 기술자들이 모여 이 상태에 "소프트웨어 위기(Software Crisis)"라는 이름을 붙였다. 이때 처음으로 "소프트웨어 공학(Software Engineering)"이라는 말이 공식적인 자리에서 사용되었다는 점은 기억해 두어도 좋다. 토목이나 기계 같은 다른 공학 분야처럼, 경험과 직감이 아닌 재현 가능한 방법론으로 소프트웨어를 만들 수 없을까 하는 것이 이 회의의 출발점이었다.

같은 1968년, Edsger Dijkstra 씨가 CACM지에 투고한 짧은 편지가 구조적 프로그래밍(Structured Programming)의 기점이 되었다. "goto 문은 유해하다고 생각된다"라는 유명한 제목(사실은 편집자인 Niklaus Wirth 씨가 붙인 것으로, Dijkstra 씨 본인의 명명이 아니라는 뒷이야기도 있다)으로 알려진 이 편지의 주장은 단순하다. 프로그램의 모습(정적 텍스트)과 실행 시에 일어나는 일(동적 프로세스) 사이의 간극을 goto 문은 점점 더 넓혀버린다. 그러므로 if-then-else, while, for와 같은 제어 구조로 좁혀야 한다는 이야기였다.

이것이 지금의 우리에게는 너무나 당연해서 오히려 와닿지 않을지도 모른다. 하지만 당시에는 "어디로든 점프할 수 있는 것"이 보통이었고, 그것을 "읽을 수 있는 순서로 쓰는 것"이 오히려 새로운 규율이었다는 전제를 이해해 두면, 이후의 이야기가 연결되기 쉬워진다.

1972년: Parnas가 "무엇을 숨길 것인가"로 모듈을 나눈다는 발상을 도입하다

제어 흐름을 읽을 수 있게 되어도, 더 큰 단위――"모듈을 어떻게 분할할 것인가"라는 문제는 남아 있었다. 1972년, David Parnas 씨가 CACM지에 발표한 논문 "모듈 분할의 기준"이 여기서 하나의 답을 내놓는다.

당시의 주류는 처리 절차(알고리즘)에 따라 모듈을 나누는 발상이었다. Parnas 씨는 이에 대해 모듈이 무엇을 외부로부터 숨기고 있는가에 따라 나누어야 한다고 제안했다. 데이터 구조의 내부 표현, 알고리즘의 구현 상세, 향후 변경될 가능성이 있는 설계 판단――이것들을 하나의 모듈 안에 가두고 외부에는 인터페이스(Interface)만을 보여준다. 이것이 "정보 은닉(Information Hiding)"의 원점이 된다.

솔직히 말해, 이 논문을 이번에 처음으로 제대로 읽어보았는데 내용이 전혀 낡았다는 느낌이 들지 않았다. Parnas 씨는 이러한 분할을 통해 얻을 수 있는 이점을 세 가지로 꼽았다. 개발 시간 단축(팀이 서로 간섭하지 않고 병렬로 작업할 수 있음), 유연성 향상(하나의 모듈을 수정해도 다른 곳에 영향을 주지 않음), 이해하기 쉬움(시스템을 모듈 단위로 학습할 수 있음). 이 세 가지는 클린 아키텍처(Clean Architecture)나 혹은 마이크로서비스(Microservices)를 채택하는 이유로 자주 언급되는 것들과 정확히 일치한다. 50년이 넘어도 모듈 분할의 목적 그 자체는 변하지 않았다.

50년도 더 된 논문이지만, GitHub Copilot에게 코드 리뷰를 부탁할 때도 그 근저에 있는 요구사항은 변하지 않았다. "변경점을 하나의 모듈 안에 가두어라"라는 지시는 인간 리뷰어에게 전달하는 인수인계로서도, AI에게 리뷰 관점을 지정하는 용도로도 그대로 재사용할 수 있다.

1980~90년대: 객체 지향과 디자인 패턴이 '숨기기'를 언어 기능으로 만들다

Parnas 씨의 정보 은닉(Information Hiding)은 초기에는 언어적 지원 없이 규율로서 지킬 수밖에 없었다. Smalltalk나 C++의 보급을 통해 캡슐화(Encapsulation), 상속(Inheritance), 다형성(Polymorphism)이라는 형태로 이 규율이 언어 기능 그 자체에 내장되게 된다.

1994년, Erich Gamma 씨를 포함한 4명(통칭 GoF, Gang of Four)이 『디자인 패턴(Design Patterns)』을 출판했다. 이 책 자체는 23개 패턴의 카탈로그이지만, 그보다 더 컸던 것은 패턴의 토대로 제시된 두 가지 원칙이었다. "구현이 아닌 인터페이스(Interface)에 맞춰 프로그래밍하라", "상속보다 합성을 우선하라(Composition over Inheritance)". 이 두 가지는 이후의 설계론 거의 모든 곳에서 등장한다.

2000년 전후: SOLID 원칙이 클래스 단위의 설계 지침으로 정리되다

2000년, Robert C. Martin 씨가 「Design Principles and Design Patterns」라는 논문에서 단일 책임(Single Responsibility), 개방-폐쇄(Open-Closed), 리스코프 치환(Liskov Substitution), 인터페이스 분리(Interface Segregation), 의존성 역전(Dependency Inversion)이라는 다섯 가지 원칙을 정리했다. 이 개별 아이디어 자체는 Bertrand Meyer 씨(Open-Closed, 1988년)나 Barbara Liskov 씨(1987년)의 작업에 이미 존재하고 있었으나, Martin 씨가 이를 하나의 세트로 정리했고, 이후 Michael Feathers 씨가 앞 글자를 따서 'SOLID'라는 기억하기 쉬운 이름을 붙였다.

이 중에서 클린 아키텍처와 직결되는 것이 마지막인 의존성 역전 원칙(DIP)이다. "상위 모듈은 하위 모듈에 의존해서는 안 된다. 양쪽 모두 추상(Abstraction)에 의존해야 한다"라는 주장은 단순하게 들리지만, 이것이 "어느 방향으로 의존성을 걸 것인가"라는, 이후의 이야기 전체를 관통하는 테마의 기점이 된다. 후반부에 작성할 AI 에이전트의 검증 설계에도 이 "방향"이라는 발상이 그대로 등장한다.

2003년: DDD가 '비즈니스 로직을 기술로부터 보호한다'는 발상을 체계화하다

Eric Evans 씨의 『도메인 주도 설계(Domain-Driven Design, DDD)』는 도메인 모델(비즈니스 규칙 그 자체)을 데이터베이스나 UI 같은 기술적인 관심사로부터 분리하여 키워나가야 한다는 생각을 체계화했다. 도메인 전문가와 개발자가 동일한 언어(유비쿼터스 언어, Ubiquitous Language)로 대화해야 한다는 주장도 여기서 나왔다. DDD 자체가 아키텍처 도표를 제시한 것은 아니지만, "비즈니스 로직은 기술적 편의에 의해 왜곡되어서는 안 된다"라는 가치관이 다음 단계인 헥사고날 아키텍처(Hexagonal Architecture)의 토대가 된다.

2005년: 헥사고날 아키텍처에서 '의존의 방향'이 처음으로 도식화되다

Alistair Cockburn 씨가 2005년에 발표한 헥사고날 아키텍처(Ports & Adapters)를 통해, 마침내 "도메인을 중심에 두고 외부의 기술적 요소를 어댑터(Adapter)로 취급한다"라는 발상이 구체적인 그림으로 그려졌다. 육각형이라는 형태 자체에 깊은 의미가 있는 것은 아니며, 단순히 "포트(Port, 인터페이스)를 얼마든지 자유롭게 그려 넣기 위해" 그 형태가 선택된 것이라는 게 본인의 설명이다. UI로부터의 입력도 데이터베이스로의 출력도, 둘 다 도메인 입장에서 보면 "외부"이며 대등하게 취급된다.

솔직히 이것을 조사하면서 가장 놀랐던 지점이 여기였다. 나는 이전 글에서 계측기 제어를 했던 경험을 바탕으로, "기종이 바뀔 때마다 폼(Form) 전체를 다시 쓰는 것을 피하기 위해 IInstrumentController

「와 같은 인터페이스를 사이에 두었다」라고 썼다. 당시에는 자신의 현장에서 고안한 방식이라고 생각하며 썼던 것이지만, 이는 Cockburn 씨가 2005년에 명명한 '포트 (Port)'와 '어댑터 (Adapter)'의 관계 그 자체였다. 도메인 (점검 로직) 관점에서 보면 계측기는 외부의 존재이며, IInstrumentController가 포트, 기종별 구현 클래스가 어댑터에 해당한다. 이름을 알지 못한 채 동일한 구조에 도달했던 셈이다.

2008년~2012년: 오니언 아키텍처에서 클린 아키텍처로, 명칭이 통일되어 가다

2008년, Jeffrey Palermo 씨가 오니언 아키텍처 (Onion Architecture)를 제창한다. 기본적인 발상은 헥사고날 아키텍처 (Hexagonal Architecture)와 같지만, 육각형이 아닌 동심원으로 다시 그려 중심에 도메인 모델 (Domain Model), 그 외곽에 애플리케이션 서비스 (Application Service), 더 외곽에 인프라 (Infrastructure)라는 계층 구조로 정리했다.

그리고 2012년, Robert C. Martin 씨가 블로그 게시물 「The Clean Architecture」를 통해 헥사고날, 오니언, DCI 등 이름은 다르지만 본질적으로 같은 이야기를 하고 있는 여러 아키텍처를 비교하며, 공통되는 규칙을 하나로 언어화한다. 그것이 바로 「의존성 규칙 (The Dependency Rule)」이다. 소스 코드의 의존은 항상 외부에서 내부(도메인 방향)로만 향해야 한다. 역방향으로 의존이 필요한 경우에는 인터페이스를 사이에 두어 의존성 역전 원칙 (Dependency Inversion Principle)으로 방향을 반전시킨다. 2017년에 동명의 서적이 출간되면서 이것이 업계 공통의 어휘로 정착되었다.

화살표의 방향에 주목해 주길 바란다. 인프라 계층은 도메인 계층을 알고 있지만, 도메인 계층은 인프라 계층의 존재를 전혀 모른다. 이것이 의존성 규칙 (The Dependency Rule)의 핵심이다. 실제 클린 아키텍처는 Entity · Use Case · Interface Adapter · Frameworks & Drivers라는 4개의 동심원으로 구성되지만, 이 4개 계층 모두를 관통하는 것은 '의존은 내부로만 향한다'는 이 규칙 하나뿐이다.

왜 '지금' 클린 아키텍처가 좋다고 여겨지는가, 역사와 대조해 보기

여기까지 살펴보면, "왜 클린 아키텍처가 지금의 표준적인 답이 되었는가"라는 질문에 대한 답이 사실 단순하게 보인다. 단순히 유행하는 베스트 프랙티스이기 때문이 아니라, 반세기 이상의 시행착오가 반복되며 도달해 온 몇 가지 원칙의 합류점이기 때문이다.

• Parnas의 정보 은닉 (Information Hiding, 1972) → 변경의 영향 범위를 모듈 내부에 가둠
• SOLID의 의존성 역전 (Dependency Inversion, 2000) → 의존의 방향을 추상화에 대해 고정함
• DDD (2003) → 비즈니스 로직을 기술적 관심사로부터 보호함
• Hexagonal/Onion (2005~2008) → 이 두 가지를 하나의 그림으로 가시화함

클린 아키텍처는 이 4가지 흐름을 「의존성 규칙 (The Dependency Rule)」이라는 중심 규칙으로 집약했다. Entity · Use Case · Interface Adapter · Frameworks라는 계층 구조나 그 외의 세부적인 규칙들도 있지만, 토대가 되고 있는 것은 바로 이 한 점이다. 그렇기에 프레임워크가 바뀌어도 (WinForms에서 Blazor로, 혹은 .NET 8에서 .NET 10으로), 이 규칙 자체는 낡지 않는다. 프레임워크 고유의 지식은 교체되더라도 의존의 방향을 어떻게 관리할 것인가라는 설계 판단은 재사용할 수 있다는 것이, 이번에 역사를 따라가며 얻은 나만의 실감이다.

과거 글을 다시 읽으며 깨달은 점: 나 또한 이 역사의 끝단에 있었다

WinForms → Blazor 관련 글에서 나는 WinForms 시대의 세 가지 습관을 적었었다. 로직을 폼 (Form)에 직접 쓰지 않는다, 인터페이스를 정의하여 DI (Dependency Injection)로 교체 가능하게 만든다, 테스트 용이성을 의식하여 로직을 폼 외부로 뺀다. 이번 조사를 바탕으로 다시 정리해 보니, 사실 이 세 가지가 각각 서로 다른 시대의 원칙과 연결되어 있었다는 사실을 깨닫게 되었다.

WinForms 시대의 나는 이러한 이름들을 단 하나도 알지 못했다. 그저 "기종이 바뀔 때마다 폼(Form) 전체를 다시 쓰고 싶지 않다"라는 현장의 필요성에 떠밀려, 같은 구조에 도달했을 뿐이었다. 이번에 깨달은 것은 이것이 우연이나 재능이 아니라, 반세기 이상에 걸쳐 수많은 기술자가 동일한 필요성에 직면하여 같은 결론에 도달해 왔다는 사실이다. 이름을 모르더라도 같은 문제에 직면하면 같은 형태의 답에 가까워진다. 이것이 클린 아키텍처(Clean Architecture)가 "발명"이 아니라 "수렴"이라고 생각하는 가장 큰 이유다.

최소 샘플: The Dependency Rule을 준수한 코드의 형태

말로만 설명하면 이미지를 떠올리기 어려우므로, 최소한의 코드 예시를 남겨둔다. 점검 결과가 임계값(Threshold)을 초과했는지 판정한다는 단순한 예시로, 도메인 계층(Domain Layer)이 인프라 계층(Infrastructure Layer)의 존재를 일절 모르는 상태를 작성하고 있다.

// Domain/InspectionRule.cs
// 도메인 계층: 무엇에도 의존하지 않는다. 여기에 HttpClient나 DbContext는 절대 등장하지 않는다.
public class InspectionRule
...

// Application/IInspectionRepository.cs
// 애플리케이션 계층: "무엇을 하고 싶은가"만을 인터페이스(Interface)로서 선언한다.
public interface IInspectionRepository
...

// Infrastructure/SqlInspectionRepository.cs
// 인프라 계층: 도메인 계층의 인터페이스를 구현한다. 화살표는 여기서 안쪽을 향한다.
public class SqlInspectionRepository : IInspectionRepository
...

InspectionRule은 IInspectionRepository의 존재조차 모른다. DB 연결 문자열이 바뀌어도, EF Core를 Dapper로 교체해도, InspectionRule의 코드는 한 줄도 변경할 필요가 없다. 이것이 The Dependency Rule이 실제 코드에 나타난 모습이다.

여기서 AI 이야기로 연결하기: Judgment Engineering의 실체는 사실 이 역사 그 자체였다

지난번 그래프 엔지니어링(Graph Engineering) 기사에서, 나는 "Judgment Engineering(판정 엔지니어링)"이라는 가칭을 붙였다. 배선(Graph)을 아무리 공들여 설계해도, 각 분기점의 판정 정밀도가 낮으면 의미가 없다는 이야기다. 그때 이 판정을 뒷받침하는 부품은 자기 개선 루프(Self-improvement loop)와 메모리 두 가지뿐이라고 썼다.

이번에 반세기 이상의 역사를 따라가 보며 이 가설에 살을 붙일 수 있게 되었다. 판정 엔지니어링의 내용은 사실 새로운 개념이 아니라, 소프트웨어 공학이 지금까지 축적해 온 세 가지 원칙을 AI 에이전트의 검증역(Verifier)이라는 레이어에 재적용하고 있는 것뿐이라는 것이 이번의 결론이다.

특히 세 번째는 실무적으로 효과적이다. 루프 엔지니어링 기사에서 썼던 "구현은 저렴한 모델에, 검증은 강력한 모델에 맡긴다"라는 구성에서, 검증역에 전달하는 리뷰 관점으로서 "의존의 방향이 도메인을 향하고 있는가"는 인간 리뷰어에게도, AI 검증역에게도 판단이 흔들리지 않는 명확한 기준이 된다. "읽기 쉬운가"와 같은 주관적인 기준보다 "이 클래스는 using으로 인프라 계층의 네임스페이스(Namespace)를 참조하고 있지 않은가"와 같이 기계적으로 체크할 수 있는 기준이 AI의 판정 정밀도를 안정시킨다.

이를 한 단계 물러나서 보면, 리뷰 기준을 기계에 맡기는 흐름 자체는 AI 에이전트에서 갑자기 시작된 것이 아님을 알 수 있다. 인간이 문서화한 리뷰 관점 → Lint 규칙으로서의 코드화 → 정적 분석(Static Analysis)을 통한 자동 체크 → 그리고 지금, AI 검증역에 의한 판정이라는 순서로, 판정을 맡기는 범위가 서서히 넓어져 왔을 뿐이다. Clean Architecture의 Dependency Rule은 이 어느 단계에서도 동일한 기준으로 재사용할 수 있는 몇 안 되는 원칙 중 하나가 된다.

지난 기사에서 언급한 review-mistakes.md

(review-mistakes.md (검증역이 과거에 놓친 실수를 기록하는 파일))도 이 맥락에서 다시 파악하면 이해가 깊어진다. 그것은 새로운 발상이 아니라, 회귀 테스트 스위트 (Regression Test Suite)라는 오래된 관행을 재정식화한 것이다. 한 번 놓친 버그와 동일한 패턴을 두 번 놓치지 않도록 테스트 케이스를 쌓아가는 것과, 검증역이 과거의 오판 패턴을 review-mistakes.md에 쌓아가는 것은 구조적으로 동일한 일을 하고 있는 것이다.

## review-mistakes.md에 쌓는 항목의 예 (Clean Architecture 관점)
- 대상: 도메인 계층 (Domain Layer)의 클래스가 인프라 계층 (Infrastructure Layer)의 타입을 직접 참조함
- 판정: 승인(오류)
...

이것을 검증역 서브 에이전트(Sub-agent)에 대한 리뷰 요청 프롬프트에 읽혀 두면, Clean Architecture의 원칙 그 자체가 AI의 판정 기준으로 기능한다. 루프(Loop)나 그래프(Graph)라는 새로운 용어가 생겨나더라도, 그 내용의 상당수는 C# 엔지니어가 이미 실무에서 사용해 온 설계 원칙의 적용 대상이 인간 리뷰어에서 AI 검증역으로 확장된 것뿐일지도 모른다.

나의 경우, 어디서부터 시작할 것인가

설비 점검 관리 시스템 개인 학습 프로젝트에서 다음에 해보고 싶은 것은 이것이다. requesting-code-review 프롬프트에 Clean Architecture의 의존성 규칙 (Dependency Rule)을 체크 항목으로 명시적으로 추가하는 것이다. "도메인 계층의 파일이 Infrastructure 네임스페이스나 HttpClient, DbContext를 직접 참조하고 있지 않은가"를 검증역에 대한 지시 사항에 한 줄 추가하는 것과 같은 작은 변경부터 시도할 생각이다.

이름을 모르더라도 현장의 필요에 직면하면 동일한 구조에 도달한다 —— 이것이 이번에 역사를 되짚어보며 가장 쓰고 싶었던 내용이다. 인류는 수십 년 동안 동일한 문제를 풀어왔다. 그 결과를 이름이 붙여진 형태로 재사용할 수 있는 것이 지금 우리의 강점이라고 생각한다. 수치가 나오면 다시 기사로 쓰고 싶다.

자주 묻는 질문 (FAQ)

Q. 클린 아키텍처 (Clean Architecture)와 오니언 아키텍처 (Onion Architecture), 헥사고날 아키텍처 (Hexagonal Architecture)는 결국 무엇이 다른가요?

A. 본질적인 부분은 거의 같습니다. 도메인을 중심에 두고 의존성의 방향을 안쪽으로 고정한다는 발상은 공통적입니다. 차이점은 주로 명칭과 도식화하는 방식인데, 헥사고날은 육각형, 오니언은 동심원, 클린 아키텍처는 그 양쪽의 공통점을 "The Dependency Rule"로서 언어화한 것이라는 위치에 있습니다.

Q. 개인 개발의 소규모 앱에서도 클린 아키텍처가 필요한가요?

A. 필수 사항은 아닙니다. WinForms → Blazor 기사에서도 썼지만, 기능이 늘어날 전망이 있는지에 따라 판단하는 것을 추천합니다. 이번에 알게 된 것은 이름을 모르더라도 현장의 필요에 따라 자연스럽게 유사한 구조에 도달한다는 것이므로, 억지로 틀(Type)부터 맞출 필요는 없다고 생각합니다.

Q. SOLID 원칙과 클린 아키텍처의 관계를 알려주세요.

A. SOLID는 클래스 단위의 설계 원칙이고, 클린 아키텍처는 그것을 시스템 전체의 레이어 구조로 확장한 것이라는 관계입니다. 특히 의존성 역전 원칙 (DIP)이 클린 아키텍처의 The Dependency Rule의 토대가 됩니다.

Q. Judgment Engineering과 Clean Architecture는 관계가 있나요?

A. 지난 기사에서 가칭으로 두었던 Judgment Engineering이라는 개념 자체는 업계에서 사용되는 용어가 아닙니다. 다만, AI 에이전트의 검증역에게 무엇을 판정 기준으로 갖게 할지 고민할 때, Clean Architecture의 Dependency Rule과 같은 소프트웨어 공학의 기존 원칙을 그대로 사용할 수 있다는 것이 이 기사를 통해 제가 스스로 얻은 고찰입니다.

Discussion