AI에게 소프트웨어 아키텍처를 지키게 하는 이유와 방법

최근 들어 클린 아키텍처(Clean Architecture)가 안티패턴이거나, AI에 맡기는 것이 오히려 더 좋은 결과물을 만들 수 있다는 의견들이 세상을 휩쓸고 있다.

반면, 아키텍트의 관점에서 볼 때 이러한 의견들은 그저 헛소리일 뿐이라는 것은 이미 잘 알려져 있을 것이다.

업무상 작성한 애플리케이션의 수명이 짧은 경우는 드물다. 아무리 PoC(Proof of Concept)라고 전제하고 트라이얼을 부탁하더라도, 어느새 본 운영 환경에서 사용되어 결함 보고가 자신에게 날아오는 것이 세상의 이치이다.

얽히고설킨 아키텍처, 어디에 무엇이 있는지 모르는 스파게티 코드.

물론 AI에게 의존하면 조사하고 해결해 주는 것은 사실이지만, 토큰도 시간도 공짜는 아니다.

쉽게 해결할 수 있다면 더 좋을 일이다.

유지보수성(Maintainability)이란 '오랫동안 사용될 가능성이 있는 애플리케이션' 전반에 요구되는 것이라는 주장은,

이 AI 구동 개발(AI-driven development)의 전성시대에도 오히려 설득력을 더하는 논거이다.

자, 아키텍처를 지키게 하는 방법은 여러 가지가 있지만, 제가 추천하는 것은 'TDD의 맥락'에 아키텍처 검사를 결합하는 것이다. 이른바 'Arch-Unit'으로, 코딩이 정한 규약에 따르고 있는지 전체 소스 코드 파일을 읽어 기계적으로 검사하는 방식이다.

최근 AI는 강력한 경향성 학습(trend learning)을 통해 TDD를 네이티브하게 다룰 수 있다. 먼저 Red를 수행하고 구현하여 Green으로 만드는 과정도 최근 AI는 순조롭게 해낼 수 있어, 의외로 요청만 하면 정적 분석(static analysis) → Arch-Unit까지 가능해진다.

예를 들어 TypeScript(ts)라면 다음과 같은 Agent.md 파일로 요청할 수 있다.

（이는 기억에서 꺼낸 예시일 뿐이다. 더 좋은 작성 방식이 있을 것이다）

# 규약
## 아키텍처
Functional Core / Imperative Shell (FCIS)을 채택합니다.
...

이렇게 하면 AI가 코드를 작성한 후 자율적으로 검사하는 npm run test를 통해, 만약 작성 방식이 잘못되었다면 테스트가 실패한다.

그 피드백은 컨텍스트/메모리(context/memory)의 성장을 촉진하고, 유지보수성을 의식하는 개발로 이어지게 되는 것이다.

쉽게 시도해 볼 수 있을 것이라 생각하니, 꼭 한번 해보기를 바란다.