<aside> 🧭

핵심 결론: 복잡한 도메인에서 문제는 대개 모델이 너무 적어서가 아니라, 하나의 명사에 너무 많은 시간대·책임·변화 단계를 억지로 넣는 데서 시작된다. 같은 대상을 언제(Time), 누구의 책임 관점에서(Angle), 어느 모델링 깊이로(Depth) 볼지 분리하면 경계와 전환이 보인다.

</aside>

“사용자”, “주문”, “상품”, “세션”처럼 너무 자연스러운 명사는 설계에서 종종 위험 신호다. 그것들은 현실의 모든 측면을 담는 말처럼 보이지만, 실제 시스템은 그 대상이 시간에 따라 바뀌고, 부서·서비스·사용자 역할마다 다른 책임으로 보이며, 단순 데이터에서 행위와 전환 규칙까지 여러 깊이를 가진다.

Damian Płaza의 글 Time, angle and depth: dimensions in software design은 이 문제를 바닥재 판매·창고·시공의 이야기로 풀어낸다. 판매 담당자, 창고 담당자, 시공 담당자는 모두 같은 “바닥재”를 말하지만 실제로는 서로 다른 현실의 단면을 다룬다. 이 글의 가치는 새로운 다이어그램 하나를 제안하는 데 있지 않다. 모델을 고정된 명사 목록으로 보지 말고, 관점·시간·깊이를 움직이며 탐색하라는 사고 도구를 준다는 데 있다.

하나의 명사가 대화를 망가뜨리는 방식

같은 대상을 보더라도 책임과 목적이 다르면 각 컨텍스트가 보는 현실의 단면도 달라진다.

판매 담당자에게 바닥재는 고객이 고른 경험과 상품 약속이다. 창고에는 입고·재고·보관 조건·출고 참조번호가 중요하다. 시공자에게는 현장 습도, 자재 상태, 설치 가능 여부가 핵심이다. 세 사람은 같은 단어를 쓰지만 같은 모델을 공유하지 않는다.

소프트웨어에서도 같은 일이 반복된다.

DDD의 Bounded Context가 중요한 이유도 여기에 있다. 큰 모델을 여러 문맥으로 나누고, 그 관계를 명시해야 팀과 시스템이 서로 다른 뜻을 같은 말에 숨기는 일을 줄일 수 있다. 하지만 컨텍스트만 그려서는 충분하지 않다. 컨텍스트가 언제 어떤 순서로 만나고, 그 안에서 모델이 얼마나 깊게 다뤄져야 하는지가 빠지면 설계는 다시 정적인 상자 그림이 된다.

첫 번째 차원: 관점(Angle)은 ‘누가 무엇을 책임지는가’다

여기서 Angle은 단순한 사용자 화면 관점이 아니다. 특정 목적과 책임 때문에 같은 대상을 다르게 단순화하는 업무적·기술적 시선이다.

관점이 잘 분리된 설계는 “바닥재”를 억지로 공유 엔터티 하나로 만들지 않는다. 창고 컨텍스트에는 InventoryItem, 시공 컨텍스트에는 InstallationMaterial이 있을 수 있다. 둘이 같은 물리 자재를 가리키더라도, 하나는 재고·위치·보관을 책임지고 다른 하나는 현장 조건·설치 가능성·품질을 책임진다.

flowchart LR
    S[Sales view] -->|order request| W[Warehouse view]
    W -->|dispatch notice| I[Installation view]
    I -->|completion result| S

관점 분리의 목적은 이름을 늘리는 것이 아니다. 각 모델에서 불필요한 세부사항을 제거하고, 그 모델의 결정과 불변식을 선명하게 하는 것이다. 따라서 “이 필드는 어느 서비스에 둬야 하나?”보다 먼저 “이 사실을 이용해 결정을 내리고 결과에 책임지는 사람 또는 컨텍스트는 누구인가?”를 물어야 한다.

두 번째 차원: 시간(Time)은 상태가 아니라 ‘전환’을 보게 한다

Płaza의 가장 실용적인 통찰은 관점을 시간축에 올리는 순간 정적인 컨텍스트 지도가 핸드오프 지도가 된다는 것이다. 판매·창고·시공이 각자 존재한다는 사실보다 중요한 것은 주문 정보가 판매에서 창고로, 자재가 창고에서 시공으로, 완료 사실이 다시 고객 경험으로 넘어가는 순서다.

시간축을 추가하면 다음 질문이 가능해진다.

• 이 사실은 어느 시점에 처음 생기는가?
• 어느 컨텍스트가 다음 컨텍스트에 무엇을 넘겨야 하는가?
• 전달 전에는 불가능하고 전달 후에만 가능한 행동은 무엇인가?