도메인 주도 에이전트: LLM이 레거시 코드베이스에서 실패하는 이유와 해결책
Domain-Driven Agents
LLM을 레거시 코드베이스에 적용하면 품질이 급격히 떨어진다. 모델이 시스템에 대한 질문에 답을 추측하기 때문이다. 저자는 DDD(도메인 주도 설계)를 기반으로 코드베이스가 '준비'되도록 만드는 전략을 제시한다. 전략적 작업(결정)과 전술적 작업(구현)을 분리하고, 각 저장소에 `.workflow.json` 매니페스트와 `CONTEXT.md` 용어집을 두어 에이전트가 도메인 경계와 언어를 정확히 알게 한다. 또한 양측이 엣지 관계를 선언하고 생성기가 불일치를 찾아 이슈로 관리하는 방법을 소개한다.
모델이 업그레이드될 필요는 없다. 코드가 준비되지 않은 것이며, 준비 상태는 우리가 만들 수 있는 것이다.
HN 토론
20- stephen
저도 소문자 d DDD 팬인데, 엔티티별 `md` 파일로 도메인 동작/특이사항/사용법을 언어에 독립적으로 문서화하는 방식이 잘 맞았습니다.
즉, `Author.ts`에는 `Author.md`가 있고, `Book.ts`에는 `Book.md`가 있습니다.
에이전트에게는 `md` 파일을 읽고 쓰는 스킬을 부여했습니다:
https://github.com/joist-orm/joist-orm/blob/main/packages/co...
그래서 에이전트가 작성한 `md` 업데이트가 PR에 나타나고 있습니다. 지금까지는 유용해 보입니다 (저희 메인 저장소는 35만 줄 규모의 TypeScript 모놀리스입니다).
물론, 이는 원문의 "모든 바운디드 컨텍스트의 in/out 엣지 그래프"보다 훨씬 덜 정교하고 (그리고 덜 복잡합니다) 하지만, 아마도 그것은 다시 제 "소문자 d" DDD 선호 때문일 것입니다. 저는 "대규모 DDD" 패턴 중 일부가 과도한 엔지니어링으로 이어진다고 생각합니다.
- owaiswiz
앞부분에서 LLM이 그린필드 프로젝트에서 더 다루기 쉽다는 내용을 읽었는데...
제 경험은 정반대입니다. 기존 프로젝트에서는 잘 작동하지만 새 프로젝트에서는 그리 좋지 않습니다 (단순한 바이브 코딩이 아니라면).
제 생각에는 기존 프로젝트의 수년간 확립된 구조/관례에 의존할 수 있기 때문에 더 잘 작동하는 것 같습니다.
- scotty79
면접에서 DDD에 대해 질문받았을 때, 저는 디버그 주도 개발(Debug Driven Development)이라고 농담했습니다. 빈 디렉토리에서 시작해서 첫 번째 버그를 "앱이 아무것도 하지 않습니다. ~해야 합니다..."로 제출하는 방식이요.
아이러니하게도, 지금 제가 AI 에이전트와 작업하는 방식이 거의 그렇습니다.