(Claude Opus 4.5의 도움을 받아 작성되었습니다.)
소프트웨어는 현실의 문제를 푼다. 제품에서 "사용자가 이용료를 지불해야 한다"는 필요가 생기면, 사람들은 자연스럽게 "결제"라는 기능을 떠올린다. 그리고 결제에 기대되는 것들이 요구사항으로 나열된다.
이처럼 문제를 해결하는 가장 범용적인 바운더리가 도메인이 된다. 도메인 안에는 이미 세상에서 통용되는 이름들이 있다. 결제, 승인, 취소, 환불 같은 것들. 이 이름들은 각자 본래의 의미를 가지고 있다.
도메인의 이름들은 제품의 전략 안에서 구체적인 의미를 갖게 된다. 일회성 결제가 중요한 제품에서 "결제"는 사용자가 직접 금액을 지불하는 행위를 뜻한다. 정기 결제가 중요한 제품에서 "결제"는 구독에 의해 발생한 청구를 처리하는 행위를 뜻한다.
같은 이름이지만 전략에 따라 의미가 달라진다. 전략은 도메인의 이름들이 우리 제품 안에서 어떤 의미를 가지는지를 결정하는 맥락이다.
이름에는 본래의 의미가 있다. 승인은 허락하는 행위고, 결제는 금액을 지불하는 행위고, 구독은 지속적으로 서비스를 제공 받는 것이다. 이것이 컨셉이다. 컨셉은 어떤 제품에서 쓰이든, 어떤 전략 안에서 쓰이든 변하지 않는다.
컨셉은 경계 역할을 한다. "구독"이라는 이름을 쓰면서 일회성 결제를 구현할 수는 없다. 전략이 의미를 구체화할 수는 있지만, 컨셉을 배반할 수는 없다.
문제는 같은 단어를 듣고도 사람마다 다르게 상상한다는 것이다. 이름은 함축이기 때문에 정보가 압축되어 있고, 사람마다 그 압축을 푸는 방식이 다르다.
"구독"이라고 하면 누군가는 넷플릭스를, 누군가는 뉴스레터를 떠올린다. 누군가는 결제까지 포함해서 생각하고, 누군가는 청구 생성까지만 생각한다. 이게 방향성의 차이다. 월간 구독만 생각하는 사람과 연간 구독도 포함하는 사람의 차이는 범위의 차이다.
범위는 마일스톤으로 조정할 수 있지만, 방향성은 초기에 정렬되어야 한다.
정렬은 대화를 통해 이루어진다. 컨셉은 변하지 않지만, 우리 제품의 전략 안에서 그 이름이 어디까지를 담당하는지는 합의가 필요하다. "우리 제품에서 구독은 청구를 생성하는 것까지만 한다. 결제는 구독의 책임이 아니다."처럼.
중요한 것은 개발자든 아니든, 모든 구성원이 동일하게 이해하는 것이다. 이해가 충분히 쌓이면 자연스럽게 글로 정리된다. 명문화는 이해의 결과이지 목적이 아니다. 너무 일찍 문서화하면 오히려 잘못된 결정이 굳어버릴 수 있다.
이름의 컨셉과 경계가 합의되면, 그 다음은 정책이다. 정책은 컨셉을 구체적으로 어떻게 구현할지를 결정한다.
구독의 컨셉이 "지속적으로 청구를 발생시키는 것"이라면, 정책은 그 구체적인 방식을 정한다. 월간으로 할지 연간으로 할지, 중간에 취소하면 어떻게 할지, 다음 청구일은 어떻게 계산할지.