1~2주차는 TDD와 클린 아키텍처를 학습 하고 작은 요구사항을 구현하면서 익숙해지는 과정이였다.
3주차가 본격적인 프로젝트의 시작이였다.
장난감 프로젝트용 시나리오를 하나 선택한 뒤, 실제 대규모 서비스 회사에서 경험할 수 있는 일들인 동시성 처리, 메시지 큐, AWS 인프라 구축, 장애 대응 등 직접 체험하면서 점진적으로 고도화 해가는 과정을 경험할 수 있다.
3주차 과제는 다음과 같다.
- 시나리오 선택 및 분석
- 3~5주차 마일스톤 작성
- 시퀀스 다이어그램 작성
- API 명세서 작성
- Mock API 작성
- ERD 설계
서비스 시나리오 선택
e-커머스 서비스와 콘서트 예약 서비스 두개가 있었다.
e-커머스 서비스는 상품 주문 서비스를 구현하는 것이였다.
Key Point는 주문에 대한 동시성 처리와 재고 관리였다.
콘서트 예약 서비스는 콘서트를 예약하는 일련의 과정을 구현하는 것이였다.
Key Point는 대기열 구현이였다.
- 유저 진입시 대기열 발급 및 만료를 잘 시킬 수 있나?
- 다시 대기열에 진입했을때도 문제가 없나?
우리 조는 콘서트 예약 서비스를 선택했다. 대기열을 구현하는 일이 좀더 복잡하고 재밌을 것 같았다.
대기열 하면 바로 큐를 쓰면 되는거 아니야? 라고 할 수도 있다. 하지만 처음에는 RDBMS로 대기열을 구현해야 한다.
이유는 첫번째로 RDBMS 역량을 숙달시키기 위함이고, 두번째는 모든 회사에서 레디스나 메시지 큐를 사용할 수 있는 것도 아니기에 RDBMS로도 설계를 할줄 알아야 한다고 하셨다. 세번째는 큐가 모든 상황에서 정답이 아닐 수 있다. 단계적으로 학습 해서 설계 능력을 키워야 적절한 상황에서 적절한 아키텍처를 구현할 수 있다.
내가 잘한다고 생각하는 개발자 기준 중 하나도 회사의 상황마다 적절한 아키텍처 능력을 가진 사람이라고 생각한다.
코치님은 콘서트 서비스를 제대로 구현할 줄 안다면 국내 모든 회사의 과제 전형은 통과할 수 있을 것이다라고 말씀 하셨다.
(맛집 검색 서비스도 있었는데 외부 API에 과금 정책이 생겼고, API 문서도 정확하지 않아서 없어졌다.)
마일 스톤
마일스톤은 프로젝트가 완성되기 까지의 중간 단계에서 각각의 TASK에 대한 일정을 세우는 것이다.
마일스톤은 여러개가 될 수도 있다. 3주차부터 10주차 까지는 3~5주차, 6~7주차, 8주차~10 주차로 나눠지고 총 3차 마일스톤으로 진행한다.
마일 스톤은 업무를 시작하기 전에 초기에 일정을 산정하는 것이기 때문에 구체적이기 보다는 "언제부터 언제까지 업무를 진행할꺼야" 정도로만 작성해주면 된다.
clickup 이란 것도 있었지만 Github 저장소 내에서 모든 것을 관리하고 싶었기에 Github의 Loadmap을 사용하였다.
시퀀스 다이어그램
시퀀스 다이어그램은 시스템 내에서 객체들의 상호작용하는 방식을 나타내는 다이어그램이다.
최근 면접에서도 시퀀스 다이어그램을 그려봤어요? 라는 질문을 받았지만.. 직전 회사에서 3년 넘게 일했지만 그려본 적이 없다..
(코치님도 반 농담으로 큰일 났다고..) 하지만!! 이제부터 배우면 되지!! 라는 생각으로 그려보았다.
유저가 콘서트 예약을 위한 대기열에 진입 후 발급 받는 토큰 기능을 표현한 시퀀스 다이어 그램이다.
시퀀스 다이어그램은 하나에 모두 그려도 되고, UseCase 별로 나눠서 그려도 된다. 한번에 표현하면 하나의 UseCase 흐름을 파악하기 어려울 것 같아서 약간의 중복을 허용 하더라도 UseCase 별로 분리해서 그렸다.
어려웠던 부분은 객체를 어디까지 표현해야 할까 였다. (위 그림의 사용자, API, 대기열)
디비도 표현해야 할까? 객체를 도메인 별로 나누긴 해야 하는데 이름을 어떻게 짓지? 궁금한게 많았다.
디비는 표현하지 않아도 된다고 하셨다. 디비에 crud 하는건 각 객체가 하는 일이기 때문에 UseCase를 분석하기 위한 시퀀스 다이어그램에선 필요가 없다.
코치님은 어떤 관점으로 볼것 이냐에 따라 아래와 같은 기준을 정하고 그린다고 하셨다.
1. 숲을 보는 것 ( 시스템 전체적인 관점 )
2. 나무를 보는 것 ( Usecase 별 분석 )
3. 뿌리를 보는 것 ( 객체간의 흐름을 보는 것 )
1번은 경험치가 있어야 그릴 수 있다.
이번 과정에서 키워야 할 역량은 2번이라고 하셨다. 그래서 DB는 표현하지 않고 결제, 주문, 유저와 같은 비즈니스의 도메인만을 객체로 표현해야 한다. 2번을 할 줄 모른다면 1번도 하기 쉽지 않다.
API 명세서
스웨거는 이번 주차에 붙이지 말라고 하셨다. 그래서 Chatgpt한테 양식을 받아서 md 문법으로 작성하였다.
요구사항을 보고 만들었고, 마지막에 ERD 설계를 하면서 덩달아 API 명세서도 조금 수정되었다.
초기 설계이기 때문에 예외 케이스는 개발해봐야 정확히 알 수 있기 때문에, 초반에는 성공 응답만 만들어도 충분하다.
API를 호출하는 입장에서 curl, postman 등으로 API 시뮬레이션을 할 수 있어야 한다.
Mock API
프론트와 협업할 때 Mock API를 제공한 적이 없었다. API 명세서를 만든뒤 해당 명세를 보고 json 파일을 별도로 만들어서 작업을 하라고 전달했다. 하지만 Mock API를 제공하는 것이 더 좋다고 말씀하셨다.
Mock API 없이 API 개발을 시작하면 시간도 오래 걸리고, API 개발이 끝났다고 해도 버그가 없다고 자부할 수 있을까? ( 난 아니다..)
Mock API를 만들면 실제 API를 호출하는 것이기 때문에 필터나 인터셉터가 있다면 해당 부분도 검증을 할 수 있고, 프론트에서 API 스펙 변경 요청이 와도 서비습 로직이 완성되지 않았기 때문에 변경도 매우 쉽다. 요청값도 임시로 받아서 해당 값에 따라 반환값도 분리해서 하기도 편하다.
Mock API를 만들지 않으면 어느 순간 프론트가 API를 닥달하는 시점이 분명히 있다. 나도 여러번 겪어봤다. 저랑 같이 일했던 프론트 분들 미안해요..
ERD 설계
ERD 설계는 마지막에 진행하였다.
concert_schedule 테이블에 total_seat 필드랑 total_seat_status 필드가 있다. 콘서트 스케줄 마다 좌석수가 다르다고 생각했고, 좌석을 예약 하여 concert_seat에 삽입될 때 total_seat 이하 로만 데이터 개수를 조절하기 위함이다.
total_seat_status는 콘서트를 예약할 수 있는 날짜를 구분하기 위함이다. 좌석이 모두 차면 예약할 수 없는 날짜로 생각했다.
payment 테이블에 좌석 금액과 좌석 번호 필드가 있는 것은 결제 시점의 정보가 최신 좌석 정보와 다를 수 있다고 생각하여 비정규화를 하였다.
user_queue 테이블은 대기열 정보를 보관한다. token 필드는 추가하지 않았는데 token payload안에 user_id를 넣고, API에서 토큰을 받으면 payload에서 user_id를 추출하여 user_queue 테이블에서 조회하면 된다. concert_schedule_id 필드는 콘서트 스케줄 마다 대기열을 구분짓기 위해 추가 하였다. 아이유 100주년 콘서트 1월 2일 토요일 20:00 ~ 24:00 / 아이유 100주년 콘서트 1월 3일 일요일 20:00 ~ 24:00 같은 콘서트 지만 각각의 스케줄이 있고 해당 스케줄마다 대기열은 달라야 한다고 생각했다.
user_cash 테이블을 굳이 추가한 이유는 잔액을 수정하는 트랜잭션으로 인해 user 테이블의 조회 성능에 영향을 끼침을 막기 위해 정규화를 하였다. 하지만 이번 과제에서는 user 테이블에 합쳤어도 괜찮지 않았을까 싶다.. (이런게 오버 엔지니어링?!)
배운것
유명한 회사들은 개발 시작 전에 문서화 하는 과정이 필수다.
- API 문서
- 시퀀스 다이어그램
- 아키텍처 흐름도
이 3가지는 반드시 가져가야 한다.
| 문서화의 중요성
모든 팀원이 강한 오너십을 가지고 있기에, 긴 설명 없이도 일의 진행 과정과 맥락에 대해 얼라인(align)이 잘 되어 있어요. 하지만, 목표에 대한 얼라인을 온전히 코드레벨로 가져오지는 못한 상황도 종종 있었어요. 개발 막바지에 엣지케이스가 발견되는 경우 타협을 해야 하는 경우도 있었고요. 이러한 상황들로부터 발생하는 커뮤니케이션 코스트를 줄이기 위해, 개발 시작 전 작업의 배경과 목표, 목표가 아닌 것 그리고 계획을 문서화한 테크스펙을 작성을 선행하기 시작했어요. 덕분에, 개발중 발생했던 불필요한 커뮤니케이션 코스트를 줄일 수 있었어요. 더 나아가, 문서화 덕분에 작업에 필요한 프론트엔드 코드의 일부분은 자동으로 생성할 수 있게 되었어요. 결과적으로 개발 생산성이 향상되었어요.
cc. 당근에서 커리어를 시작한 비전공자 개발자 이야기
코치님들은 팀의 리더를 맡고 계시다. 잘하는 시니어 개발자 중 한 가지 조건은 아키텍처를 그릴 줄 알아야 한다고 하셨다.
그래서 코딩보다 문서를 만들고 설계하는데 더 많은 시간을 쏟는다고 하셨다.
코치님 개발 시 작업 순서
1. 마일스톤 작성
2. API 명세 작성 및 Mock API 개발 및 배포
3. 요구사항 분석 ( Usecase 별로 시퀀스 다이어그램, 클래스 다이어그램.. )
4. 개발 하면서 ERD 설계 ( 완전 새로운 시스템을 개발한다고 하면 ERD를 먼저 설계함 )
테이블을 먼저 설계하지 않는 이유는 비즈니스 로직이 메인이기 때문이다. DB 데이터는 부차적인거라고 생각한다. 개발을 하다보면 엔티티 명세가 자주 바뀐다. ( 맞다..) 그래서 ERD 설계를 먼저 하지 않는다. 비즈니스 로직을 다 구성 한뒤, 필요한 데이터가 어떤 건지 추린뒤 해당 데이터 기반으로 ERD를 작성한다.
질문 잘하는 법
1. 이런 문제가 있어요 혹은 이런 기능을 구현해야 해요.
2. 내가 이걸 해결하기 위해 이러한 시도를 했어요.
3. 그랬더니 이러한 문제가 발생했는데 잘 모르겠어요.
참고
===
현재 항해 플러스 백엔드 코스 6기 모집중입니다.
항해플러스 관련해서 문의 주실 내용 있으시면 이메일 혹은 댓글로 편하게 문의주세요!!
지원시 추천 코드 입력 한번 부탁드립니다!!
추천코드
HHPGS0858
https://hanghae99.spartacodingclub.kr/plus/be
'외부활동 > 항해플러스 5기' 카테고리의 다른 글
| [항해 플러스 5기 백엔드 4주차] Usecase 개발 (0) | 2024.07.12 |
|---|---|
| [항해 플러스 5기 백엔드 2주차] 클린 아키텍처 (1) | 2024.06.22 |
| [항해플러스 5기 백엔드 1주차] TDD (0) | 2024.06.22 |
| [항해플러스 5기 백엔드 OT] 시작하는 마음 (0) | 2024.06.15 |