문제 관측
기능을 개발하다 보면 이런 고민을 자주 하게 됩니다:
- “이 흐름이 맞는 걸까?”
- “클래스 구조는 어떻게 나누지?”
- “요구사항이 막연해서 테스트를 어디서부터 시작할지 모르겠다…”
예전에 작성했던 글 “TDD, 어디서부터 시작해야 할까?”에서도 저는 이런 질문을 던졌습니다:
“E2E 테스트부터 시작해야 할까? 단위 테스트부터 시작해야 할까?”
“기능이 머릿속에는 있는데, 테스트나 설계로 어떻게 쪼갤 수 있지?”
결국 제가 느낀 건 하나였습니다:
기능 구현보다 먼저 "설계를 위한 설계"가 필요하다.
다양한 시도: 요구사항 명세부터 시작한 설계 실험
이번에 이커머스 서비스를 설계하며 저는 "설계 자체를 목적으로 한 설계 실험"을 해봤습니다.
그 중심에는 요구사항 정의 → 흐름 시각화 → 구조 설계 → 데이터 설계가 있었습니다.
1. 요구사항 정의서 작성
가장 먼저 기능별로 다음과 같은 포맷을 만들었습니다:
- 유저 스토리
사용자가 어떤 니즈를 가지고 있는지 자연어로 서술
Ex: "사용자는 상품을 좋아요할 수 있다." - 기능 흐름
- Main Flow: 정상 흐름
- Alternate Flow: 조건 분기, 반복 요청 등
- Exception Flow: 실패 시나리오 (→ 테스트/예외 설계에 매우 중요)\
- 고려사항
인증/인가, 트랜잭션, 동시성, 예외 처리 등 기능 외적인 조건 - 요청/응답 명세
HTTP 요청 구조 및 반환 필드 정의
작성한 주요 기능 항목은 다음과 같습니다:
- 상품 목록 조회 / 상세 조회
- 브랜드 조회
- 상품 좋아요 등록 / 취소 / 조회
- 주문 및 결제 (포인트, 재고, 외부 연동 포함)
시각화: 시퀀스 다이어그램으로 흐름 정리
요구사항 명세서를 바탕으로 기능 흐름을 시퀀스 다이어그램으로 시각화했습니다.
시퀀스 다이어그램을 통해 명확히 알 수 있었습니다:
- 어떤 서비스/레포지토리가 호출되는지
- 어느 단계에서 어떤 예외가 발생하는지
- 인증/검증 → 상태 변경 → 응답 구조까지 흐름을 자연스럽게 따라갈 수 있음
예시: 상품 좋아요 등록
구조 설계: 클래스 다이어그램으로 책임 분리
시퀀스 다이어그램이 "행위 중심"이라면,
클래스 다이어그램은 "구조와 책임 중심"입니다.
- 도메인 중심 구조 (Order, Product, User, Brand, Point 등)
- Service → Repository 간 책임 분리
- 연관관계 명확화 (예: Order → OrderItem → Product)
이 구조를 만들면서 객체 간 협력 관계를 명확히 정리할 수 있었고,
이후 테스트 코드나 실제 구현을 할 때도 훨씬 수월해질 것이라는 확신이 들었습니다.
데이터 설계: ERD로 실체화
클래스 다이어그램을 기반으로 ERD(Entity-Relationship Diagram) 까지 도출했습니다.
설계 기준
- Long 타입 PK (auto increment)
- ID 기반 외래키 설계 (JPA 연관관계 최소화 고려)
- 1:N, N:M 관계 명확화
- Order ↔ OrderItem: 1:N
- User ↔ Product Like: N:M (→ 중간 테이블 분리)
예시 구조:
흐름 정리: 설계 → 테스트 → 구현의 전 단계 준비
이번 과정을 통해 제가 얻은 가장 큰 인사이트는 다음과 같습니다:
“요구사항을 설계하고 흐름을 시각화하는 것 자체가, 테스트와 구현을 위한 가장 강력한 준비가 될 수 있다.”
요구 → 행위 흐름 → 책임 구조 → 데이터 설계
이 흐름이 머릿속에서 정리되면, 실제 코드는 자연스럽게 따라올 수 있습니다.
회고: 설계를 위한 설계, 그 가치는 충분했다
이번 프로젝트는 아직 구현 이전입니다.
하지만 저는 테스트나 코드 이전에 ‘설계를 위한 설계’만으로도 충분히 값진 경험을 했다고 느낍니다.
- 요구사항을 글로 풀어내면서 기능에 대한 이해가 깊어졌고
- 시퀀스/클래스/ERD를 그리며 흐름이 머릿속에 새겨졌습니다
그리고 무엇보다 중요한 점:
좋은 테스트는 명확한 요구에서 시작되고,
좋은 구현은 선명한 구조에서 나온다.
다음 단계: 이제 테스트로 넘어간다
이제 이 설계 자료를 바탕으로 TDD 사이클을 시도해보려 합니다.
요구사항 → 시각화 → 구조화 → DB설계의 흐름을 기반으로 테스트 설계 → 실제 코드로 확장해나갈 예정입니다.
그 흐름이 끊기지 않도록,
이번 설계를 발판 삼아 더 탄탄한 구현과 테스트 루틴을 만들어가고 싶습니다.
'Test Code' 카테고리의 다른 글
| E2E부터 단위 테스트까지, 나만의 TDD 루틴 만들기 (0) | 2025.07.16 |
|---|