r/ClaudeCode•4개월 전•13•24

AI와 빈약한 도메인 모델(Anemic Domain Models) 문제

AI and the problem of Anemic Domain Models

핵심 요약

AI가 코드를 짤 때 비즈니스 로직이 도메인 객체가 아닌 UI에 흩어지는 '빈약한 도메인 모델' 안티패턴을 반복하는 문제에 대한 고찰.

빈약한 도메인 모델 — 비즈니스 로직이 객체에 없고 UI 계층에 흩어져 기술 부채를 유발함.
AI의 코드 생성 — Claude가 문맥을 좁게 파악하여 재사용성보다는 당장 작동하는 코드 위주로 작성함.
아키텍처 리팩토링 — AI가 짠 코드를 그대로 쓰지 않고 별도의 아키텍처 개선 세션을 거쳐야 함.
컨텍스트 주입 — AI에게 아키텍처 원칙을 주입하려 해도 무시당하기 일쑤라 운영자의 깊은 이해가 필수적임.

수년 전, 마틴 파울러는 빈약한 객체 안티패턴에 관한 훌륭한 글을 썼습니다: https://martinfowler.com/bliki/AnemicDomainModel.html

그의 관점에 동의한다고 가정하면(글에 대한 논쟁은 하지 맙시다, OK?), AI가 거의 예외 없이 이 안티패턴을 따른다는 것은 분명하며, CLAUDE.md나 다른 지침으로 이를 제어하기란 상당히 어렵습니다.

다음과 같이 코드를 작성하는 대신:

Object1과 Object2가 모든 비즈니스 로직을 가짐
모든 UI 구현체는 모델 데이터를 조작하기 위해 Object1과 Object2를 사용하며, 오직 화면 표시와 사용자 상호작용에만 집중함

결국 이런 결과가 나옵니다:

Object1과 Object2는 동작이 없는 구조체에 불과함
UI 구현체 A는 사용자가 원하는 작업을 수행하는 데 필요한 모든 비즈니스 로직을 내장함
UI 구현체 B는 중복되거나 불필요한 추가 비즈니스 로직을 가짐
UI 구현체 C는 A와 B에도 존재하는 비즈니스 로직을 중복하거나 재발명함

이는 시간이 지남에 따라 엄청난 기술 부채를 만듭니다. 비즈니스 로직이 여러 UI 구현체에 산탄총처럼 흩어져 있기 때문에, 새로운 기능을 구현할 때 재사용 가능한 코드를 활용할 수 없고 기존 비즈니스 로직을 복사/붙여넣기하거나 변형을 만들어야 합니다. 또한 비즈니스 로직이 Object1과 Object2 내부에 캡슐화되지 않고 노출되어, 시스템을 다루는 모든 사람이 해당 객체의 내부 구조를 이해해야 함을 의미합니다.

이 문제를 다루는 제 방식은 완벽하지는 않지만... 저는 다음과 같이 합니다:

제가 작성한 사양을 바탕으로 Claude가 기능을 코딩하게 합니다. 저는 아키텍처 원칙을 강요하지 않습니다. Claude.md에 아키텍처 목표("객체는 동작을 가져야 하며, 빈약한 모델을 만들지 말 것")를 포함하지만, Claude는 보통 그 조언을 무시하고 안티패턴을 따릅니다.
기능을 작동하게 만듭니다.
그런 다음 항상 아키텍처 리팩토링 세션을 가집니다. 이는 새로운 코드에는 항상 필요하지만, 버그 수정이나 기능 개선에는 거의 필요하지 않습니다.

하지만, 지루한 작업입니다.

이 문제를 어떻게 해결하시는지 궁금합니다. 의견 있으신가요?

원문

커뮤니티 목록

r/ClaudeCode•4개월 전•13•24

AI와 빈약한 도메인 모델(Anemic Domain Models) 문제

AI and the problem of Anemic Domain Models

핵심 요약

AI가 코드를 짤 때 비즈니스 로직이 도메인 객체가 아닌 UI에 흩어지는 '빈약한 도메인 모델' 안티패턴을 반복하는 문제에 대한 고찰.

빈약한 도메인 모델 — 비즈니스 로직이 객체에 없고 UI 계층에 흩어져 기술 부채를 유발함.
AI의 코드 생성 — Claude가 문맥을 좁게 파악하여 재사용성보다는 당장 작동하는 코드 위주로 작성함.
아키텍처 리팩토링 — AI가 짠 코드를 그대로 쓰지 않고 별도의 아키텍처 개선 세션을 거쳐야 함.
컨텍스트 주입 — AI에게 아키텍처 원칙을 주입하려 해도 무시당하기 일쑤라 운영자의 깊은 이해가 필수적임.

수년 전, 마틴 파울러는 빈약한 객체 안티패턴에 관한 훌륭한 글을 썼습니다: https://martinfowler.com/bliki/AnemicDomainModel.html

다음과 같이 코드를 작성하는 대신:

Object1과 Object2가 모든 비즈니스 로직을 가짐
모든 UI 구현체는 모델 데이터를 조작하기 위해 Object1과 Object2를 사용하며, 오직 화면 표시와 사용자 상호작용에만 집중함

결국 이런 결과가 나옵니다:

Object1과 Object2는 동작이 없는 구조체에 불과함
UI 구현체 A는 사용자가 원하는 작업을 수행하는 데 필요한 모든 비즈니스 로직을 내장함
UI 구현체 B는 중복되거나 불필요한 추가 비즈니스 로직을 가짐
UI 구현체 C는 A와 B에도 존재하는 비즈니스 로직을 중복하거나 재발명함

이 문제를 다루는 제 방식은 완벽하지는 않지만... 저는 다음과 같이 합니다:

제가 작성한 사양을 바탕으로 Claude가 기능을 코딩하게 합니다. 저는 아키텍처 원칙을 강요하지 않습니다. Claude.md에 아키텍처 목표("객체는 동작을 가져야 하며, 빈약한 모델을 만들지 말 것")를 포함하지만, Claude는 보통 그 조언을 무시하고 안티패턴을 따릅니다.
기능을 작동하게 만듭니다.
그런 다음 항상 아키텍처 리팩토링 세션을 가집니다. 이는 새로운 코드에는 항상 필요하지만, 버그 수정이나 기능 개선에는 거의 필요하지 않습니다.

하지만, 지루한 작업입니다.

이 문제를 어떻게 해결하시는지 궁금합니다. 의견 있으신가요?

주요 댓글

r/claudecode

AI가 Anemic domain model을 생성하는 문제를 해결하기 위해 ADR 문서화와 정적 분석 도구 활용 등 구체적인 아키텍처 가이드라인을 설정해야 한다는 의견이 주를 이룹니다.

Claude가 처음 짠 코드를 리팩토링 안 해도 되는 방법을 아는 사람 있으면 제발 알려줘 😄

계획 단계에서 리팩토링하는 거? 근데 이것도 해결책은 아님. 엄격한 타입 기반 프로그래밍 같은 걸로 비즈니스 로직을 중앙화하라고 강제할 순 없으니까.

근본적인 문제인 듯. Claude Code는 '좁은 범위'에 집중하도록 설계됨. 200개 소스 파일을 다 읽으면 다른 문제가 생기니까. 근데 '재사용성'은 어디에 뭐가 있는지 넓게 알아야 하잖아. Claude는 그걸 모르니까 그냥 '작동하는' 고립된 로직으로 회귀하는 거지.

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

100% 동의함. 여기 관련 생각들 참고해봐. https://np.reddit.com/r/ClaudeCode/s/GvO9XO1d0H 그리고 Claude 관련해서 덧붙이자면, 복잡한 설명 테이블을 넣는 게 항상 먹히진 않음. 필요할 때 대화에 바로 주입해야 함. 소스 코드 파일이나 ADR, 계획서 등을 가리키는 컨텍스트 훅을 잘 설정하면 성공 사례가 많음.

"필요할 때 대화에 바로 주입해야 한다"는 말 공감함. 나도 자주 그렇게 함. 근데 이건 운영자가 자기 코드베이스를 깊이 이해하고 있어야 한다는 뜻이지. 두 부류가 있는 것 같아. Claude가 짜게 두고 결함은 눈감는 쪽, 아니면 고삐를 꽉 쥐고 아키텍처를 통제하는 쪽. 난 항상 후자 쪽임.

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

정말 잘 짚어주셨네요. 저도 몇 년 동안 붙잡고 있을 프로젝트가 하나 있는데, 건승을 빕니다. 나중에 또 얘기 나눌 수 있을까요?

계획을 엄청나게 리팩토링해봐도 Claude는 여전히 Claude 짓을 하더라.

난 항상 빈약한 도메인 모델(anemic model)을 선호하는 편인데, 대신 모든 비즈니스 로직을 담은 별도의 클래스나 모듈 같은 걸 따로 두는 방식을 써. 이렇게 하면 모델 자체는 데이터 구조를 한눈에 파악하기 쉽게 깔끔하게 유지되면서도, 비즈니스 로직이 여기저기 꼬여서 스파게티 코드가 되는 걸 막을 수 있거든.

그러니까... 비즈니스 로직이 UI 컴포넌트에 있으면 안 된다는 거지?

난 개인적으로 '빈약한' 도메인 모델이 나쁘다는 생각엔 동의 안 하지만, 네 문제는 이해함. 아마 DDD 스타일의 풍부한 도메인 모델로 작성된 코드가 전체의 극히 일부라, 학습 데이터에 널린 '빈약한' 모델을 따라 하도록 Claude가 길들여진 것 같음.

Fowler의 주장을 깊게 파고들 생각은 없었어요. 하지만 'Anemic domain model'이 무조건 나쁘다고 단정 짓는 건 또 다른 극단으로 치닫는 거라는 의견에는 동의해요. 어떤 구조나 클래스는 내부를 '투명하게' 공개하는 게 낫고, 어떤 건 데이터를 엄격하게 숨기는 게 나은지 그 중간 지점을 찾는 게 핵심인데, 아쉽게도 정해진 '규칙'은 없죠. 상황마다 다 이해하고 판단해야 하니까요.

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

Fowler의 주장을 깊게 파고들 생각은 없었지만, 'Anemic domain models'가 무조건 나쁘다고 단정 짓는 것도 극단적이라는 의견에는 동의해요. 내부 구조를 투명하게 드러내는 게 유리한 클래스와, 데이터와 구현을 엄격하게 숨기는 게 유리한 클래스 사이의 적절한 균형점을 찾는 게 중요하죠. 정해진 규칙은 없어요. 상황마다 다르게 판단해야 합니다.

UI 계층이랑 데이터 계층에서 비즈니스 로직을 아예 빼버리면 해결됨. 이 방식의 '문제'는 리소스 복사본이 여러 개 생긴다는 건데, 테이블 행, 비즈니스 계층으로 전달되는 DTO, 그리고 UI가 쓰는 API 타입까지 다 따로 노는 거지. 비즈니스 계층은 DTO를 API용 리소스로 변환하면서 도메인 로직을 담는 역할을 함.

두 가지 방향이 있음. 1) 비즈니스 모델이랑 DTO를 완전히 분리하고 비즈니스 모델에 함수형 패턴을 쓰는 거. 2) DTO를 비즈니스 로직에도 쓰는 거. 보통 기술 스택들은 1번을 쓰는데, 마틴 파울러가 말하는 건 1번이 아님. 2번처럼 짤 때가 문제인 거지(Hibernate가 쓰레기인 이유). 근데 이건 다 주관적임. r/java 같은 데 가서 똑같은 질문 던져보면 수십 년 경력자들끼리 피 터지게 싸우는 거 볼 수 있을걸.

원문r/ClaudeCode