Clean Architecture로 AI 코딩을 가속화하기

Cursor나 Copilot, Codex와 같은 AI 코딩 도구에 의해 구현 속도는 크게 변했다.

간단한 CRUD나 API 구현이라면 몇 분 만에 그럴싸한 코드가 생성된다.

테스트 코드(Test Code)나 DTO, Repository 구현까지 자동 생성되는 것도 드문 일이 아니다.

실제로 이전보다 "코드를 쓰는 속도"는 명확히 올라갔다.

하지만 그 한편으로는,

"코드 전체의 구성이 무너지기 쉬워진다"

라는 문제도 느끼게 되었다.

예를 들어,

• 수정하면 다른 부분이 망가진다
• 유사한 구현이 증식한다
• 책임(Responsibility)이 모호해진다
• Domain에 Infra 지식이 새어 나간다
• Utility 클래스가 비대해진다
• UseCase가 무엇이든 하기 시작한다
• 동일 개념의 표기 불일치나 통일성 결여

와 같은 일들이 일어나기 쉽다.

언뜻 보면 구현 속도는 올라가고 있다.

하지만 장기적으로 보면,

코드 전체의 구조가 서서히 붕괴되어 가는 감각이 있다.

이것은 단순히 "AI의 정밀도가 낮다"는 이야기가 아니다.

오히려,

AI가 코드를 생성하는 메커니즘 자체가,

이러한 문제를 일으키기 쉬운 것이 아닌가라고 느끼고 있다.

AI 코딩 도구는 매우 우수하다.

기존 코드를 참고하면서,

필요한 구현을 고속으로 생성해 준다.

예를 들어,

• Repository 구현
• DTO
• CRUD
• 테스트 코드(Test Code)
• API 엔드포인트(Endpoint)

등은 상당히 높은 정밀도로 생성할 수 있다.

하지만 여기서 중요한 것은,

AI는 "시스템 전체를 완전히 이해하고 있는" 것이 아니다

라는 점이다.

많은 경우 AI는,

• 주변 파일
• import
• 명명(Naming)
• 기존 구현
• 유사 패턴

등을 참고하면서,

"이 위치에 있을 법한 코드"를

추론하여 생성하고 있다.

즉, AI는 매우 강력한 "국소 최적화(Local Optimization)"를 수행하고 있다.

이는 역으로 말하면,

구조가 모호한 코드에서는

그 모호함을 그대로 증폭시키기 쉽다는 뜻이기도 하다.

예를 들어,

• UserService
• UserManager
• UserHandler

와 같이 비슷한 책임을 가진 클래스가 복수 존재할 경우,

인간이라면 "대충 같은 개념이구나"라고 이해할 수 있다.

하지만 AI는,

각각을 별개의 개념으로 취급하기 쉽다.

결과적으로,

• 동일한 책임의 구현이 늘어난다
• 미묘하게 다른 구현이 양산된다
• 유사 로직이 산재한다
• 명명 규칙(Naming Convention)이 붕괴한다

와 같은 일이 일어나기 쉬워진다.

또한, 기존 코드에 책임 누락이 존재하면,

AI는 그것도 기존 패턴으로서 답습하며 구현을 넓혀 나간다.

즉 AI는,

좋은 구조도 나쁜 구조도 그대로 증폭한다.

실제로 나 자신도 비슷한 것을 느끼고 있다.

처음에 어느 정도 레이어 구조나 책임을 정리한 상태에서 AI에게 구현을 맡기면,

출력되는 코드의 일관성은 비교적 높았다.

예를 들어,

• UseCase의 책임이 일치한다
• Repository의 사용법이 통일된다
• DTO나 Validator의 배치가 정돈된다

등,

기존 구조에 따른 형태로 구현되기 쉬웠다.

반면,

처음부터 넓은 범위를 AI에게 맡기면,

서서히 구조가 무너지는 경우도 많았다.

예를 들어,

• 동일한 책임인데 별칭 클래스가 늘어난다
• Utility에 처리가 모이기 시작한다
• Domain과 Infra의 경계가 모호해진다
• Repository를 거치기도 하고 거치지 않기도 한다

와 같은 상태가 일어나기 쉬웠다.

적어도 현시점에서는,

"AI에게 코드를 쓰게 하기"

이전에,

"AI가 기존 패턴을 답습하기 쉬운 구조를 만드는 것"

이 중요하지 않을까라고 느끼고 있다.

그렇다면 AI가 추론하기 쉬운 구조란 무엇일까.

그 하나가,

Clean Architecture와 같은 "책임 경계를 명확하게 분리하는 구조"라고 느끼고 있다.

기존에 Clean Architecture는 주로,

• 유지보수성(Maintainability)
• 테스트 용이성(Testability)
• 변경 용이성(Modifiability)

을 위해 이야기되는 경우가 많았다.

하지만 AI 코딩 시대에는,

또 다른 가치도 나타나고 있다.

그것은,

AI가 코드를 추론하기 쉬워진다

라는 점이다.

예를 들어,

• UseCase는 애플리케이션의 처리를 수행한다
• Repository는 데이터 취득을 수행한다
• Domain은 비즈니스 규칙을 가진다

와 같이 책임이 정리되어 있으면,

AI는 "이 위치에 써야 할 코드"를 추측하기 쉬워진다.

반대로 책임이 모호하면,

• Repository에 비즈니스 로직을 작성한다
• UseCase에 DB 조작을 작성한다
• Utility에 무엇이든 밀어 넣는다

와 같은 구현이 발생하기 쉽다.

AI는 거대한 코드베이스 전체를 완전히 이해하고 있는 것이 아니다.

많은 경우,

• 주변 파일
• import
• 인접한 구현

등을 참고하며 추론하고 있다.

그렇기 때문에,

1개 파일의 책임(Responsibility)이 작을수록,

AI는 해당 코드를 추론하기 쉬워진다.

예를 들어,

• "이 UseCase를 수정한다"
• "이 Repository를 추가한다"
• "이 Validator를 구현한다"

와 같이,

국소적인 변경으로서 다루기 쉬워진다.

이는 AI 코딩과 궁합이 상당히 좋다.

Clean Architecture에서는,

의존 방향(Dependency Direction)이 어느 정도 정해져 있다.

예를 들어,

• Domain은 Infra를 모른다
• UseCase는 Repository Interface에 의존한다

와 같은 규칙이 있다.

이를 통해,

AI가 무질서하게 의존 관계를 넓히기 어려워진다.

AI는 기존 구현이나 주변 컨텍스트(Context)를 참고하며 코드를 생성하는 경향이 있기 때문에,

의존 방향이 모호하면 책임 누락이 발생하기 쉽다.

구조 규칙이 명확할수록,

AI의 생성도 안정되기 쉽다.

기존의 Clean Architecture는,

구현 비용이 높다는 점이 문제였다.

예를 들어,

• Interface
• DTO
• Mapper
• DI (Dependency Injection)
• 테스트 템플릿

등,

보일러플레이트(Boilerplate)가 늘어나기 쉽다.

하지만 AI 시대에는,

• 템플릿 생성
• DTO 작성
• Mapper 작성
• 테스트 코드 생성

등을 AI가 고속으로 대신 처리해 준다.

즉,

"책임 분리 그 자체"가 아니라,

"책임 분리로 인해 증가하는 구현량"이

기존의 큰 비용이었다.

그리고 그 비용은,

AI에 의해 상당히 약화되고 있다.

지금까지,

AI 시대에는 책임이 분리된 구조의 가치가 높아지고 있다는 이야기를 해왔다.

하지만,

그렇다고 해서 "무조건 Clean Architecture로 하면 좋다"는 뜻은 아니다.

오히려,

형식적으로 너무 과하게 분리된 구조는,

반대로 AI의 추론 비용을 높이는 경우도 있다.

예를 들어,

• Interface가 대량으로 존재한다
• 단 하나의 메서드만 가진 Wrapper가 늘어난다
• 의미가 희박한 DTO가 난립한다
• Repository가 너무 세밀하게 나뉜다
• 레이어(Layer)가 너무 깊어진다

와 같은 구조는,

인간에게도 읽기 어렵다.

그리고 이것은,

AI에게도 마찬가지다.

AI는 기존 코드나 주변 컨텍스트를 참고하여 추론하기 때문에,

구조가 과도하게 복잡해지면,

어디에 무엇을 써야 할지 판단하기 어려워진다.

중요한 것은,

"Clean Architecture라는 이름의 구조"를 채택하는 것이 아니다.

정말로 중요한 것은,

• 명명 규칙 (Naming Convention)
• 책임 경계 (Boundary of Responsibility)
• 의존 방향 (Dependency Direction)
• 레이어의 역할

등이,

시스템 전체에서 일관성을 유지하는 것이다.

예를 들어,

• UseCase는 무엇을 하는 계층인가
• Repository는 어디까지 책임을 갖는가
• Domain에는 무엇을 써도 되는가

가 팀 내에서 통일되어 있으면,

AI도 기존 패턴을 따르기 쉬워진다.

반대로,

동일한 개념에 여러 가지 작성 방식이 존재하면,

AI는 그 흔들림을 그대로 증폭시키기 쉽다.

기존의 설계에서는,

• 유지보수가 용이한가
• 테스트하기 쉬운가
• 변경하기 쉬운가

와 같은 관점이 중시되었다.

물론 그것들은 지금도 중요하다.

하지만 AI 코딩 시대에는,

그에 더해 "AI가 추론하기 쉬운가"라는 관점도 설계 품질의 일부가 되기 시작하고 있다고 느낀다.

예를 들어,

• 책임이 명확함
• 명명이 통일됨
• 의존 방향이 정리됨
• 패턴이 정렬됨

과 같은 구조는,

AI가 기존 구현을 따르며 코드를 생성하기 쉽다.

즉 앞으로는 "인간이 이해하기 쉬운 구조"뿐만 아니라, "AI가 일관성을 유지하며 추론하기 쉬운 구조"도 중요해지지 않을까 생각한다.

AI가 코드를 쓰는 시대에,

"정말로 인간이 읽기 쉬운 코드를 작성할 필요가 있는가"라는

논의는 앞으로 늘어날 것이라 본다.

실제로,

AI가 코드 생성 및 수정을 수행한다면,

인간이 세부 구현을 직접 읽을 기회는 줄어들 가능성도 있다.

극단적으로 말하자면,

• 인간은 사양(Specification)만 작성한다
• AI가 구현한다
• 인간은 결과만 확인한다

라는 개발 스타일도,

조금씩 현실성을 띠기 시작하고 있다.

한편으로는,

현시점의 AI는 시스템 전체를 완전히 이해하고 있는 것이 아니라,

기존 구조나 주변 컨텍스트 (Context)를 참고하며 추론하고 있다.

그렇기 때문에,

• 명명 (Naming)
• 책임 경계 (Responsibility Boundary)
• 의존 방향 (Dependency Direction)
• 구현 패턴 (Implementation Pattern)

등이 정리되어 있을수록,

AI의 생성도 안정되기 쉽다.

그리고 흥미로운 점은,

AI가 추론하기 쉬운 구조를 지향하다 보면,

결과적으로 인간에게도 읽기 쉬운 구조가 되기 쉽다는 것이다.

책임이 정리되고,

명명이 통일되며,

의존 관계가 명확해진 코드는,

인간에게도 이해하기 쉽다.

즉 앞으로는,

"인간을 위한 설계"와

"AI를 위한 설계"가

대립하는 것이 아니라,

오히려 가까워질지도 모른다.

적어도 현시점에서는,

AI에게 코드를 작성하게 할수록,

구조 설계나 일관성의 중요성은 오히려 높아지고 있다고 느끼고 있다.