WIL 2주차 - Software Design (루퍼스 백엔드 부트캠프)

들어가기 앞서

2주 차는 개인 일정이 겹쳐서 토요일 정규수업조차 참여할 수 없었다. 또, 회사에서 팀 간의 인원 조정되어 우리 팀의 인원이 8명에서 6명으로 축소되었다. 맡게 되는 일은 동일한데 일할 사람은 줄어드는 상황이 아이너리하다.

 

그렇게 새로운 스프린트가 시작되었는데 이번에 맡게되는 일은 다른 도메인 모듈과의 카프카 통신을 간단하게 수정하는 일이었다. 이전 팀장이 있을 때 진행해보고 싶었어도 맡지 못했던 일이었는데 팀장이 바뀌면서 자연스럽게 나에게 내려왔다. 회사일이 루퍼스에서 진행하는 이번 설계 과제보다 흥미롭고, 일이 바빠서 2주 차 과제는 크게 신경 쓰지 못했다. 사실 그렇게 흥미로운 과제가 아니라서 하기 싫었다는 표현이 어울린다.

 

그럼에도 불구하고 이번 주차의 내용은 상당히 중요했다. 설계를 어떻게 하는지 감을 잡아보는 시간을 가질 수 있었는데, 회사에서는 설계가 문서화로 이뤄지지 않기 때문이다. 물론 나의 경우는 excalidraw와 같은 툴로 도식화하고 슬랙 캔버스에 최대한 남기려고 하는데 대부분의 설계가 이미 떠나간 사람들이 진행하였고, 남는건 구전설화뿐이어서 레거시 시스템을 유지보수하는 일은 상당히 어렵다.

 

이번 주차에 배운 내용들을 앞으로 계속 회사에서 활용해볼 계획인데, mermaid라는 툴이 굉장히 흥미로웠다.

 

키워드

• 요구사항 정리/기능 명세
• 시퀀스, 클래스 다이어그램
• ERD(Entity Relationship Diagram)
• 도메인 모델
• 엔티티
• VO
• 설계 문서화

Tools

아래 세 가지 툴이 사용된다고 한다. 그 중 Mermaid는 알고 있었지만 사용하지 않았고 Lucidchart는 전혀 모르는 툴이었다. draw.io와 유사해 보인다. 그리고 Excalidraw는 굉장히 자주 사용하고 있는 툴이다.

 

중요한 점은 빠르게 그릴 수 있는 익숙한 툴을 하나 선정하고, 다이어그램을 그리는 컨벤션을 익혀서 활용하는 것이라고 정리할 수 있었다.

 

• Mermaid : https://mermaid.js.org/
• Excalidraw : https://www.lucidchart.com
• Lucidchart : https://excalidraw.com/

 

Excalidraw에 관해

 

이미 Excalidraw는 회사에 업무 용도로 빈번하게 사용 중이다.

• PR을 작성할 때 테스트를 어떻게 해주면 좋을지 이미지를 캡처해서 표시
• 슬랙 스레드에서 프런트, 디자이너, 기획자에게 의도를 물어보거나 질문할 때
• 복잡한 알고리즘을 설계할 때

이와 같이 주로 효율적인 커뮤니케이션을 위해 잘 사용하고 있다.

 

SaaS로서 매우 훌륭한데 VSC나 옵시디언에 플러그인으로 사용할 수 있다는 확장성도 있으며 마크다운에서 수정가능한(editable) 이미지를 만드는 데 사용한다. 확장자는. excalidraw인데 뒤에 svg나 png를 붙여주면 정적 이미지로 생성되지만 수정이 가능하다. 그래서 Repository하나를 만들어서 나중에 참고 가능한 노트를 만드는데 유용하게 활용하고 있다.

 

Mermaid에 관해

머메이드는 활용도가 좋아 보인다. Github의 마크다운과 Notion에 이식성이 매우 훌륭하다. 둘 다 editable 한 svg를 생성해 준다는 장점이 있는데, 단점은 플러그인이 없는 환경에서는 화면을 그려주지 않는다는 점?

 

Notion을 사용하기 힘들었던 이유는 도식화하는 툴이 없었기 때문이었는데 Mermaid와의 호환성이 좋아서 Notion을 사용해도 괜찮지 않을까 생각된다.

 

 

Lucidchart에 관해

왠지 북미 아메리카 개발자들이 좋아할 것 같은 스타일인데 렌 멘토님이 본인이 작성한 다이어그램들을 보여주었다. 이런 것을 직접 보고 안 보고의 차이점이 상당히 큰데, 무엇을 할 수 있을지 아는 것이 상당히 중요하다.

 

Lucidchart를 보고 생각해 보니 draw.io도 접근성이나 활용성이 괜찮아 보인다. UML을 그리는 방법을 연습해서 회사에서 다양하게 활용해 보고 깨달아봐야겠다. 관련 서적 좋은 게 뭐가 없나?

 

 

 

이 서적 저렴하고 보증된 저자(로버트 C. 마틴)라서 나중에 읽어봐야겠다. 

 

디자인 플로우

위에서 언급한 키워드를 바탕으로 내가 이해한 디자인 플로우는 아래와 같다. 참고로 하나의 단계가 완료되면 그것을 더 이상 immutable 하게 보지 않고 커뮤니케이션을 통해, 그리고 클라이언트의 요구사항 변경에 따라 수시로 업데이트하고 진화하는 문서가 되어야 한다.

 

2주차 PR링크 : https://github.com/gukin-han/commercial-service/pull/2

 

아래는 내가 작성한 PR에 담겨있는 설계문서들에 대한 생각을 정리해보았다:

 

 

 

1. 요구사항 작성

 

개발관점이 아닌 관점에서의 요구사항을 정리한다. 여기서 너무 디테일한 내용이 들어가면 문서 자체가 volatile 해지는 문제가 발생할 거라는 것을 깨달았다. 클린 아키텍처에서 말하고자 하는 내용이 간접적으로 여기에 연관 지을 수 있었다. 예를 들어, 로그인한 유저가 주문을 할 수 있다는 유스케이스를 JWT 헤더가 있고 유효성이 검증된 유저가 API를 요청하여 200OK를 받을 수 있다고 표현한다면 세부 구현이 포함되어 버리기 때문에 변경 가능성이 있는 포인트가 이미 생겨버리는 유스케이스가 되어버린다.

 

 

 

2. 시퀀스 다이어그램 작성

 

모호했던 요구사항이 구체화되지만 여기서도 너무 디테일할 필요가 없다고 느꼈다. 클라이언트로 부터 시작된 요청이 성공 케이스와 여러 alternative 케이스를 거치는지를 작성할 수 있다.

 

 

 

Alen 멘토는 서버로 진입점을 하나로 Controller나 퍼사드로 구성하고 너무 디테일하게 구성할 필요는 없다는 의견을 전해주었다. 내 생각도 너무 디테일하면 생각해야할 부분도 많고 시간을 비효율적으로 사용하게 되기 때문이다. 또, 요구사항이 빈번하게 바뀌는 스타트업의 경우는 다이어그램만 그리다가 끝날 수가 있다. 

 

빅픽쳐를 그리는게 핵심이 아닐까??

 

 

3. 클래스 다이어그램 작성

 

 

 

클래스 다이어그램을 그릴때 핵심은 ERD와 같이 DB 계층을 고려하지 않고 작성하는것이다. 하지만 이 둘은 뗄래야 뗄수 없는 관계 아닌가?

 

결과적으로는 클래스 다이어그램 내부의 요소가 ERD 내부의 요소보다 많이 표현되어야 한다는 점이다. 단순히 코어 도메인 객체만 표현하는 것이 아닌 VO, 상태 enum 객체 등을 추가적으로 그려볼 수 있을것 같다. 이 프로그램이 돌아가기 위한 객체들이 포함된다던가.

 

 

4. ERD 작성

 

 

 

결국은 erd는 그러면 서버에 존재하는 이 인스턴스들이 영속성이 필요해? 라는 질문에 yes라고 대답하는 인스턴스를 레코드로 저장하는 단계를 설계하는것이다. 영속성을 구현하는 방법은 다양한데 RDBMS의 벤더를 이용한 방법이 대표적이다.

 

QnA

질문 1

• 소프트 딜리트는 왜 쓰는가?
• 하드 딜리트 대비 구현 로직이 복잡한데 그럼에도 쓰는 이유(기능적/비기능적/비즈니스적 이점)는?

답변 1

• 기능점 이점
  • 히스토리 추적 (Undo, Audit Trail)
  • 복구 가능성
• 비기능점 이점
  • 데이터 정합성 안전장치
  • 데이터 유실방지
  • "생성/삭제"가 많은 경우 반복적인 삭제 쿼리보다 유리

-- 컬럼 추가
ALTER TABLE product
  ADD COLUMN deleted_at TIMESTAMP WITH TIME ZONE,
  ADD COLUMN deleted_by VARCHAR(50);

-- 논리 삭제
UPDATE product
SET deleted_at = NOW(), deleted_by = #{userId}
WHERE id = #{id} AND deleted_at IS NULL;

-- 조회 예시 (항상 NULL 조건!)
SELECT * FROM product WHERE deleted_at IS NULL AND id = #{id};

 

• 확장 아이디어
  • 3단계 삭제 모델
    • 소프트 딜리트 : 앱에서 안 보이게만 함
    • 아카이브 무브 : 별도 아카이브 테이블 혹은 스토리지로 옮김 (S3, BigQuery)
    • 하드 퍼지 : 법적 보존 기간 끝나면 영구 삭제
  • Temporal Table / Validity Range : 이 레코드는 언제부터 언제까지 유효했는가를 기간 컬럼으로 관리
  • Event Sourcing : 삭제 자체를 이벤트로 남기고, 읽기 모델은 소프트 딜리트 개념없이 재구성
• 요약
  • 소프트 딜리트 = 복구/히스토리/컴플라이언스 + 정합성 버퍼 -> 단 쿼리 누락/데이터 부패/인덱스 문제는 내 책임
  • 소프트 -> 아카이브 -> 하드 퍼지를 기본 전략으로 생각해야 나중에 덜 고생

 

팀원들 코드 리뷰

내 코드를 발전시키려면 피드백을 주거나 받으면 된다. 좋은 코드나 설계사례를 보거나 피어 리뷰가 필요하다. 아래는 이번주를 마무리하면서 PR리뷰를 진행해볼 리스트를 작성해본다:

 

• 수호님 PR : https://github.com/clapho/Loopers-dev-spring/pull/8
• 상일님 PR : https://github.com/sangil8585/willys_commerce1/pull/2
• 상일님 글 : 개발자와 비개발자의 오작교, 다이어그램
• 세진님 PR : https://github.com/loopers-bootcamp/e-commerce/pull/2
• 세진님 글 : 우리 무슨 사이야? (feat. 도메인 바운더리)
• 지은님 PR : https://github.com/jinnie-j/loopers-ecommerce/pull/2

PR하나당 25분 정도 잡고 진행하면 되지 않을까?

 

 

마무리

2주차는 크게 신경쓰지 못했지만 그럼에도 불구하고 처음 배우게된 내용들이 많았다. 처음에는 부트캠프의 비용이 부담스럽지 않을까 생각했는데 회사 업무와의 괴리감이 크게 느껴지지 않아서 만족하고 있다. 앞으로 인강을 볼일은 많지 않을것 같다.

 

설계가 어설퍼 보일 수 있지만 무언가를 완성할때는 초안을 빠르게 만들어서 피드백을 받고 데드라인 전까지 끊임없이 고쳐서 발전해나가는게 중요하다. 회사업무도 그랬었고, 논문을 쓸때도 그랬다.

 

 

2025.08.03 : 최근 읽기 시작한 책에 나온 내용. 생각해보니 멘토님들 마다 설계에 대한 태도가 달랐다. 어떤 멘토님은 설계를 철저히 준비하며, 어떤 멘토님은 인수인계를 위한 최소한의 문서화 목적. 로버트 마틴은 장기적으로 남길 목적의 다이어그램은 그릴 필요가 없다고 했다. 비효율적이기 때문일까? 아니면 결국 사람들은 코드를 통해서 이해하기 때문일까?

References

1. UML 실전에서 이것만 쓴다 | 로버트 C. 마틴