왜 필요한가

결제사를 바꾸는데 주문 규칙과 모든 화면을 다시 고쳐야 한다면 변경의 범위가 너무 얽혀 있는 것입니다. 기능들이 서로의 저장소를 직접 수정하고 책임 주인이 없을 때 이런 일이 생깁니다. 상자를 그리거나 유명한 패턴을 고르기 전에, 어느 변경이 누구의 책임이며 다른 부분은 무엇을 믿어도 되는지 정해야 합니다.

어떻게 해결하는가

  1. 주문 확정 같은 실제 동작 하나를 따라갑니다. 주문 확인, 재고 예약, 결제 요청, 결과 안내를 일상적인 말로 적습니다. 재고를 예약한 뒤 결제가 실패하는 경우도 넣습니다. 성공 경로만 그리면 보이지 않던 조정과 복구의 책임이 드러납니다. 아직 없는 미래 기능까지 미리 설계할 필요는 없습니다.
  2. 책임을 나눕니다. Order는 주문 확정 규칙, Inventory는 재고, 결제 연동부는 외부 사업자와의 통신을 맡습니다. 체크아웃 조정자는 호출 순서와 복구를 맡습니다. 두 모듈이 같은 주문의 확정 여부를 따로 판단하게 두지 않습니다. 책임표에서 답이 둘이라면 어느 쪽이 최종 결정을 소유하는지 먼저 정합니다.
  3. 경계를 넘는 정보를 적습니다. 식별자, 요청한 작업, 결과, 가능한 실패가 무엇인지 확인합니다. 호출자가 상대의 내부 테이블이나 프레임워크 객체까지 알아야 하지 않도록 계약을 작게 유지합니다. 데이터를 직접 바꿀 수 있는 주체와 소유자에게 변경을 요청해야 하는 주체도 구별합니다.
  4. 실제로 바뀔 만한 부분을 찾습니다. 결제사가 달라질 수 있다면 요청 번역과 오류 처리를 분리합니다. 반대로 항상 함께 바뀌고 주인도 같은 두 부분 사이에 인터페이스를 추가하면 문제 해결보다 관리 일이 늘 수 있습니다. 작은 앱에 큰 조직의 구조를 그대로 복사하지 말고, 분리 이유를 현재 요구와 연결합니다.
  5. 대체물 하나로 경계를 확인합니다. 가짜 결제 결과만 주어도 주문 규칙을 시험할 수 있나요? 결제 응답이 늦어져도 주문 상태가 명확하고 재시도나 복구 담당이 있나요? 이런 확인이 폴더의 개수를 세는 것보다 의존 관계를 잘 드러냅니다. 복구하지 못한 상태를 누가 관찰하는지도 빠뜨리지 않습니다.

AI에게 짧은 책임표와 의존 방향 그림을 작성하게 한 뒤 클래스와 메서드를 구체화하게 합니다. 사용자는 프로젝트 전체의 역할, 동작과 운영 제약을 확인하면 됩니다. 개별 객체 이름까지 승인할 필요는 없습니다. 책임이 바뀌면 그림도 갱신하고, 오래된 그림이 현재 코드의 구조를 증명한다고 여기지 않습니다.

동료가 계약만 보고 같은 실패 경로를 따라가게 하고, 담당자가 둘로 읽히는 단계는 책임표에서 명확히 합니다.

UI↓   Use case↓   DomainPort ← Adapter

무엇이라 부르는가

이처럼 시스템의 책임·소유권·계약·의존 관계를 정하는 일이 소프트웨어 아키텍처입니다. 관심사 분리와 캡슐화는 명시한 계약 뒤에서 구현을 바꿀 수 있게 돕습니다. 계층, 포트, 서비스는 이 합의를 표현하는 선택지입니다. 관리 비용을 정당화하는 것은 실제 변경과 협업의 필요이지, 도식에 상자가 얼마나 많은지가 아닙니다.