AI 보조 개발에서의 아키텍처 드리프트 — 다들 어떻게 대처하고 계신가요?

ARCHITECTURE.md에 대해 들어본 적 있음?

드리프트가 발생하는 이유는 제약 조건이 레포가 아니라 사람 머릿속에 있기 때문임. 그래서 상태가 없는(stateless) 모델은 그걸 볼 수가 없음. 나한테 실제로 효과가 있었던 건 두 가지임: 에이전트가 매 세션마다 읽을 수 있는 곳에 아키텍처 규칙(모듈 경계, 허용된 의존성, 승인 없는 새 패키지 금지 등)을 적어두는 것, 그리고 dependency-cruiser나 아키텍처 린트 규칙 같은 저렴한 CI 게이트로 강제해서 모델이 기억해주길 바라는 대신 위반 시 빌드가 실패하게 만드는 것. 모델은 당신의 아키텍처를 유지해주지 않음...

아키텍처적으로 중요한 변경 사항을 확인하고 자동으로 ADR(아키텍처 결정 기록)을 생성하는 커서 훅을 설정하셈. 만약 변경 사항에 ADR이 필요하면, PR은 테크 리드의 승인을 받아야 하고 비즈니스/제품 영향이나 리스크에 따라 리더십 팀까지 에스컬레이션해서 최종 승인을 받아야 함.

그 접근 방식의 문제는 ADR이 리뷰하고 유지하기가 매우 어렵다는 거임. 특히 LLM이 쓴 ADR은 더더욱. 내 생각엔 그럼.

내 다른 댓글 확인해보셈.

나한테 실제로 효과가 있었던 접근 방식은 아키텍처를 문서로 취급하지 말고 테스트 스위트로 취급하는 거임. 새로운 건 아님. ArchUnit(Java)이나 dependency-cruiser(JS) 같은 계보니까. 근데 AI 보조 개발로 속도가 빨라지면서 이걸 진지하게 받아들일 수밖에 없게 됐음. 관례라는 게 AI 앞에서는 살아남질 못하거든. 문서는 썩고, 리뷰어들은 import 레벨의 문제들을 놓치고, 모델은 기꺼이 3개 레이어를 건너뛰는 '도움 되는' 지름길을 택하니까.

내 본업 코드는 공유할 수 없지만, 내가 관리하는 공개 레포는...