🧩 03. 개발자: 클린아키텍처 에이전트 구성

클린아키텍처는 이론 문서가 아니라, 기능이 늘어도 코드가 무너지지 않게 만드는 운영 장치입니다. 에이전트와 함께 개발할 때는 특히 경계 설계가 중요합니다. 경계가 느슨하면 생성 속도는 빨라도 유지보수 비용이 빠르게 올라갑니다.

이 문서는 Codex를 쓰는 개발팀 기준으로 구조를 먼저 고정하고, 테스트로 경계를 잠그는 실전 루프를 다룹니다.

안내: 본문은 생성형 AI를 활용해 초안을 작성했고, 공개된 공식/원문 자료를 교차 확인해 실무 운영 관점으로 보강했습니다.

flowchart TD
A[요구사항] --> B[UseCase 정의]
B --> C[Interface 분리]
C --> D[Infra 연결]
D --> E[Test 검증]
E --> F[작은 리팩토링]

🧠 칠판 치트시트

구조를 먼저 고정하면 구현이 빨라진다

domain은 외부 의존을 모르면 안 된다

테스트가 경계를 지키는 가장 강한 장치다

큰 설계보다 작은 단위 검증이 실무에 맞다

경계 위반은 리뷰가 아니라 자동 체크로 막는다

실무 시나리오

권장 기본 구조:

Codex 요청은 구현보다 경계를 먼저 지시하는 편이 좋습니다.

최소 테스트 세트:

이 단계의 목표는 기능 확장이 아니라 “경계가 실제로 지켜지는지” 확인입니다.

초기엔 빠르게 개발됐지만, 인프라 코드가 도메인으로 침투해 리팩토링 비용이 커졌습니다. 구조 선언과 경계 테스트를 먼저 붙인 뒤 수정 속도가 안정됐습니다.

유스케이스 테스트를 인프라에서 분리하자 테스트 시간이 크게 줄고, 리뷰 주기가 짧아졌습니다.