
1. 이전 글
2. 진행 내용
1주차에 진행했던 것들을 크게 3가지로 나누면 아래와 같다.
- 요구사항 분석
- TDD
- 동시성 제어 분석 보고서 작성
2-1. 요구사항 분석
1주차 발제를 담당하신 허재 코치님은 요구사항을 뾰족하게 분석하는 것이 중요하다고 했다. 개발에 들어가기 전 요구사항을 분석해야 한다는 것은 알겠는데, 대체 "뾰족하게" 분석한다는 것은 뭘까?
멘토님 왈 뾰족한 요구사항 분석이란, 비판적으로 집요하게 파고들어 요구사항을 분석하는 것이라고 했다.
1주차 발제 자료에 있던 요구사항을 살펴보자.
<1주차 TDD 과제 요구사항>
PATCH /point/{id}/charge : 포인트를 충전한다.
PATCH /point/{id}/use : 포인트를 사용한다.
GET /point/{id} : 포인트를 조회한다.
GET /point/{id}/histories : 포인트 내역을 조회한다.
잔고가 부족할 경우, 포인트 사용은 실패하여야 합니다.
동시에 여러 건의 포인트 충전, 이용 요청이 들어올 경우 순차적으로 처리되어야 합니다.
위에 정의된 요구사항만으로는 해석하기에 따라서 애매한 부분들이 있기에, 뾰족한 요구사항 분석을 통하여 아래와 같이 명확하게 정의했다.
- 동시에 들어온 요청 단위?
- 동시에 들어온 요청의 단위를 무엇으로 설정할 것인지 애매하다.
- 유저 한명에게 들어온 포인트 충전or사용 요청 / 모든 포인트 충전or사용 요청"으로 정의할 것인지 갈린다.
- 동시에 처리될 때 문제가 발생할 수 있는 것은 "유저 한명에게 들어온 포인트 충전or사용 요청"이다. 따라서 "모든 포인트 충전or 사용 요청"에 대해서 동시성 제어를 하게 되는 것은 성능 상 적절하지 못하다.
- 순차적으로 ?
- 어느 시점을 기준으로 순차적으로 처리되어야 하는지 애매하다.
- 클라이언트가 요청을 한 시점 / 서버가 요청을 받은 시점 / Lock을 획득한 시점
- 위 중 제어할 수 있는 것은 Lock을 획득한 시점만 제어할 수 있다고 판단하여 Lock을 획득한 시점을 기준으로 삼았다.
또한 최소 잔고/ 최대 잔고에 대하여 최소 잔고는 0, 최대 잔고는 1,000,000이라는 정책을 세웠다.
2-2. TDD
TDD에는 테스트를 먼저 작성한 뒤 기능 개발을 하는 TFD(Test-First-Development) 방식과, 기능 개발을 먼저 하고 테스트를 작성하는 TLD(Test-Last-Development) 방식이 있다.
중요한 것은 TFD를 하건, TLD를 하건 테스트가 왜 중요한지에 대해서 먼저 인지를 하는 것부터 시작해서, 정확히 기능의 동작을 확인하는 테스트를 작성하는 것이다.
과제를 진행하며 먼저 무엇을 테스트해야 하는지에 대한 범위를 선정해야 했는데, 뾰족한 요구사항 분석을 통해 쉽게 범위를 선정할 수 있었다.
1. 포인트 충전/사용/조회 기능 테스트
2. 포인트 충전/사용 동시성 제어 테스트
3. 최소잔고 및 최대잔고 정책 테스트
또한 하나의 기능에 대해서 여러가지 테스트를 해야할 땐 `@Nested` 키워드를 이용하여 테스트의 응집력을 높였다.
2-3. 동시성 제어 분석 보고서 작성
코드 레벨에서 동시성을 제어하기 위해서는 여러가지 방법이 있지만 임계영역을 "하나의 유저 포인트"로 설정했기에, `ConcurrentHashMap`, `ReentrantLock`을 활용하여 동시성을 제어했다. 해당 방법을 선택한 근거로 아래와 같이 리드미에 작성했다.
3. 회고
3-1. 아쉬웠던 점
- 동시성 제어 테스트를 할 때 동시 수행 횟수를 100개로 과도하게 설정했다.
- 현실 세계에서는 같은 유저에게 동시에 100개의 요청이 일어날 확률은 제로에 육박한다. 실제로 빈번하게 일어날만한 횟수를 적절하게 선정하여 동시성 테스트를 수행해야겠다.
- 문서 작성의 목적은 쓰는 사람이 아닌, 읽는 사람의 기준으로 작성해야 하지만 과제 제출에 급급해서 쓰는 사람의 기준으로 작성하게 되었다.
- 코드 스니펫 또는 비교 표 및 그림을 통해서 읽는 사람의 이해를 돕는 좋은 문서를 작성해보는 연습을 꾸준히 해보자.
3-2. 앞으로 시도해볼 것
- 아무래도 회사를 다니는 중이기에 과제에 쏟을 수 있는 시간이 한정적이다. 2주차부터 10주차까지 한정적인 시간을 효율적으로 사용할 수 있도록 지속 가능한 일주일 루틴을 설정해보자.
4. 마무리
어찌저찌 1주차 과제 대해서는 Pass를 받았다.
과제 진행 깃허브 레포지토리 : https://github.com/DevCHW/hhplus-tdd-kotlin
기본과제 PR 링크 : https://github.com/DevCHW/hhplus-tdd-kotlin/pull/2
심화과제 PR 링크 : https://github.com/DevCHW/hhplus-tdd-kotlin/pull/3
단순히 Pass에 만족하지 말고 2주차부터는 명예의 전당에 이름을 올리고 싶다.
'외부활동 > 항해플러스' 카테고리의 다른 글
항해플러스 백엔드 7기 수료 후기 및 회고 (2) | 2025.03.12 |
---|---|
항해플러스 3~5주차 회고 (0) | 2025.01.17 |
항해 플러스 백엔드 2주차 회고 - Clean Architecture (0) | 2024.12.30 |
항해플러스 백엔드 7기를 시작하며... (1) | 2024.12.20 |
개발을 하며 만났던 문제들과 해결 과정, 공부한 내용 등을 기록합니다.
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!