다들 이해하지?! 설계의 청사진 시퀀스 다이어그램

한줄요약 : 이커머스 기능 요구사항을 분석하여, 각 도메인의 책임을 나누고 데이터 정합성을 고려한 ERD를 설계하며 겪은 고민과 선택의 과정을 담았습니다.

 

아이디어를 견고한 설계로 만드는 여정

2주차 과제는 만들고 싶은 시나리오를 토대로 설계를 하는것이다.

기능 요구명세서, 시퀀스 다이어그램, 클래스 다이어그램, ERD 를 작성하여 개발 전 토대를 만드는 것이다.

최근 사용해본것은 ERD 뿐이고 앞의 3개는 한지 오래되서 기억도 잘 나지 않지만 갓-Alen 님의  Q&A 라이브 세션

을 토대로 공부하며 해쳐 나가기로 했다.

 

그중에서 4개의 작업물 중 작업하는데 가장 고민을 많이했던 시퀀스 다이어그램에 대해 말해보고자 한다.

---

시퀀스 다이어그램은 '책임 할당 계획서'다

시퀀스 다이어그램을 그리면서 나에게는 한 가지 명확한 목표가 있었다.

'이 문서는 나와 동료들을 위한 소통의 도구가 되어야 한다.'

단순히 내가 이해하는 것을 넘어, 다른 사람이 보더라도 기능의 핵심 흐름을 쉽게 파악하고, 이를 기반으로 원활하게
협업할 수 있어야 했다. 바로 이 지점에서 딜레마가 시작됐다. 모든 기술적 세부사항(DB 접근을 위한 Repository 등)을 다이어그램에 포함하자니 너무 복잡하고 장황해져 핵심을 파악하기 어려웠다.

반대로, 과감히 생략하자니 중요한 정보를 누락한 부실한 설계가 아닐까? 하는 불안감이 들었다.

이 글은 '소통'이라는 목적을 위해 시퀀스 다이어그램의 상세 수준을 어떻게 조절했는지, 그리고 그 선택의 기준은 무엇이었는지에 대한 나의 고민의 기록이다.

 

🤔 문제 : 표현의 문제

가장 많이 고민한 [주문 요청] 기능을 예시로 들면

처음에는 유저 인증을 뺀 다른 모든 객체를 포함하는 상세한 다이어그램을 작성 했었다.

따라서 로직상 필요한 UserService, ProductService, PointService 등 관련된 모든것이 다이어그램에 표현되었다.

하지만 작성 후 다이어그램을 확인하니 상품의 재고, 판매중 여부, 유저의 포인트 등 표현해야 할 정보량이 너무 많아

한눈에 보기 어려워 누가 봐도 이해하기 어렵다고 생각이 들었다.

 

💭 해결?

설계에 정답은 없다

하지만 이 설계 문서는 같이 일할 동료들과 의사소통을 하기위한 것이라고 생각하고 핵심 책임 중심으로

생략가능한 것은 생략해 좀 더 깔끔하게 보이도록 수정하였다.

 

• Repository를 생략한 이유:
  Service가 Repository를 호출하는 것은 너무나 당연한 내부 구현이다. 이 구현의 세부사항까지 다이어그램에 노출하는 것은 오히려 전체적인 비즈니스 흐름을 이해하는 데 방해가 된다고 판단했다. ProductService에게 "상품을 찾아줘"라고 요청하면, 그가 DB를 뒤지든 캐시를 쓰든 그건 ProductService의 책임이다.
• UserService를 생략한 이유:
  '주문'이나 '좋아요' 기능에서 사용자 정보가 필요할 때, SecurityContext 등에서 인증된 사용자 정보를 가져오는 것은 공통 로직에 가깝다. 매번 이 과정을 다이어그램에 그리는 것보다, "인증된 사용자(userId) 정보는 이미 사용 가능하다"고 전제하는 것이 핵심 흐름에 더 집중하게 해주었다.

 

 

---

마치며: 설계 초기에는 좀 더 추상화?

지금 설계는 Api - Facade - Servicd - Repositoy 흐름으로 구성을 했지만 
설계 초기이기 때문에 좀 더 추상화 하여 하는편이 표현이나 작성하는 속도가 높아지지 않을까 생각이 든다.

 

또한 어떤 기준과 생각을 가지고 설계를 해가야 할지 의식하면서 작업을 하니

좋은 설계 문서를 만들 수 있을것 같다는 자신이 붙었다.

어떻게 하는게 정답인지 모르지만 앞으로 더 학습하면서 배워나가 내 기술이 되도록 정진해야겠다.