제품을 만드는 방법에 대한 고찰에서 이어지는 글입니다.
(Claude Opus 4.5의 도움을 받아 작성되었습니다.)
컨셉을 중심으로 데이터 모델을 먼저 정의한다. 도메인의 이름들이 타입으로 표현되고, 이름들 사이의 관계가 타입 정의에서 드러난다. 구독은 상품을 참조하고, 상품은 가격 정책을 참조하는 식으로.
전략이 부여한 맥락, 대화를 통해 합의한 경계, 이 모든 것이 타입에 담긴다.
타입에서 드러난 관계가 동일한 형태로 로직에서 나타난다. 이 로직은 두 가지로 나뉜다.
비즈니스 로직은 제작자의 의도로 데이터를 변경한다. 정책, 규칙, 계산. "구독에서 청구를 생성할 때 상품의 가격 정책을 참조해서 금액을 계산한다"처럼. 각 이름은 자기만의 단일 목적 함수들을 가지고, 이 함수들이 조합되면서 상호작용이 만들어진다.
컴포넌트는 사용자의 의도로 데이터를 변경한다. 입력, 선택, 조작. 컴포넌트는 흔히 UI와 결부되어 생각되지만, 본질적으로는 사용자의 의도를 받아 데이터를 변경하는 함수다. 비즈니스 로직과 마찬가지로 타입의 구조를 따르고, 조합의 대상이 된다.
둘 다 타입의 구조를 따르며 데이터를 변경한다. 차이는 누구의 의도로 변경하느냐다.
비즈니스 로직과 컴포넌트가 실제 데이터와 만나는 곳이 앱이다. 여기서 인스턴스화가 일어나고, 비로소 프로그램이 된다.
UI는 데이터를 표현하기 위한 세부사항이다. 핵심 구조는 이미 타입에서 결정되어 있고, 비즈니스 로직과 컴포넌트는 그 구조를 따르며, 앱은 이것들을 실제로 동작하게 만드는 마지막 단계다.
컨셉이 타입에 드러나고, 같은 구조가 비즈니스 로직과 컴포넌트에서 반복된다. 이 일관성이 여러 가지를 가능하게 한다.
변경이 생겨도 어디를 고쳐야 하는지가 명확하다. 구독의 정책이 바뀌면 구독 관련 타입과 로직만 보면 된다. 다른 컨셉으로 번지지 않는다.
타입을 보면 컨셉들 사이의 관계가 보이고, 로직을 보면 같은 구조가 반복되니까 예측이 된다. 코드를 읽기 쉬워진다.
팀에서 합의한 컨셉이 코드에 그대로 드러나니까, 코드가 곧 공유된 언어가 된다. 협업이 수월해진다.