🌱 0. 들어가며

Chapter2 시작

항해의 chapter2 가 드디어 시작되었다.
chapter1 은 항해를 시작하면서 워밍업의 느낌이었다면,
chapter2 는 이제 제대로된 시작의 느낌이다.

위 두개의 서비스 중 하나를 선택해서 항해 여정의 마지막까지 끝까지 디벨롭을 하게 된다.

우리조가 선택한 프로젝트는 '콘서트 예약 시스템'

처음에는 프로젝트 설명을 들으면서 e-커머스에 마음이 갔지만,
콘서트예약 시스템에 대한 설명을 들으면서 마음이 옮겨갔다.

콘서트 예약 시스템의 요구사항은 다음과 같다.

Description

• 콘서트 예약 서비스를 구현해 봅니다.
• 대기열 시스템을 구축하고, 예약 서비스는 작업가능한 유저만 수행할 수 있도록 해야합니다.
• 사용자는 좌석예약 시에 미리 충전한 잔액을 이용합니다.
• 좌석 예약 요청시에, 결제가 이루어지지 않더라도 일정 시간동안 다른 유저가 해당 좌석에 접근할 수 없도록 합니다.

Requirements

• 아래 5가지 API 를 구현합니다.
  • 유저 토큰 발급 API
  • 예약 가능 날짜 / 좌석 API
  • 좌석 예약 요청 API
  • 잔액 충전 / 조회 API
  • 결제 API
• 각 기능 및 제약사항에 대해 단위 테스트를 반드시 하나 이상 작성하도록 합니다.
• 다수의 인스턴스로 어플리케이션이 동작하더라도 기능에 문제가 없도록 작성하도록 합니다.
• 동시성 이슈를 고려하여 구현합니다.
• 대기열 개념을 고려해 구현합니다.

콘서트 예약 시스템의 가장 핵심은 '대기열 시스템'을 구축하는 것이다.
DB를 활용해서 직접 대기열 시스템을 구현하는 것을 먼저 하고, 그 후에 점차적으로 redis 나 MQ등을 사용하는 시스템으로 전환해나간다고 했다.

3주차의 목표는?

이번주 과제의 목표는 api 개발이 아니었다. 두둥..

💡 3주차 목표 : 프로젝트를 '설계' 하는 것

백엔드 개발자 역량으로 가장 중요한 것중 하나는 '좋은 설계'를 할 수 있는 것이다.
지금까지는 설계가 된 것들을 개발을 하는 주니어의 역할을 주로 했었는데, 이번엔 프로젝트 하나를 실제로 설계하는 경험을 해볼 수 있었다.

그런데...ㅋㅋㅋㅋㅋㅋㅋ... 다 처음해보는 것들이었다. 😅
특히나, '이벤트 시퀀스 다이어그램' 을 어떻게 해야하나.. 싶었다.
팀원들의 조언으로 mermaid 를 사용해서 구현을 해봤다. 휴...감사감사 🙏🏻

요런 이쁜 이벤트 시퀀스 다이어그램이 만들어졌다 후후...

🍐 1. 3주차 항해 여정 회고

면역력이 떨어져서 골골..😇

갑자기 찾아온 독감, 난생 처음 수액을 맞아봄 😷

몸이 갑자기 면역력이 떨어지더니 독감이 심각하게 왔다.
회사에서도 골골 거리다가 결국 재택행... 🤕
그러다가 난생 처음 수액까지 맞게 되었다.
목소리도 나오지 않는 아주아주 지~~독한 독감이었다.

그래도 과제는 해야지..🫠

불행중 다행인건지, 이번주는 상대적으로 실질적인 개발이 아닌, 설계가 이번주 과제였어서 과제를 제출할 수 있었다. 휴...
아프기전에 미리 고민을 많이 해놓아서 겨우겨우 과제를 제출 할 수 있었다.
역시 미리미리는 언제나 옳다..😇

과제를 하면서 가장 고민이 많이 되었던 지점은 다음과 같다.

• DB로 선착순 유량 제어를 어떻게 설계할 것인가.
• 토큰의 책임은 어디까지 가져가야하는가. 대기열과 같은 역할로 생각해도될까?
• 트랜잭션에 대한 관리를 어떻게 끊어서 설계할 것인가.
• 스케쥴러의 역할을 어디까지 둘 것인가.

🍉 2. 좋은 코드를 위해서는 좋은 설계가 우선되어야 한다.

이번 과제를 통해 생각한 것들

💡 좋은 설계란 어떤 것일까?
설계를 해보면서 '좋은 설계'란 무엇일까 고민을 해봤다.
이번 과제를 하면서 느낀 것이 있다면, '정말 잘 짜여진 설계는 코딩을 쉽게 하도록 할 수 있겠다' 라는 것이다.

이번주는 요구사항에 대한 명확한 분석이 얼마나 중요한지 알 수 있었던 시간이었다.
요구사항에 대해 분석하고, 코드를 짜기보다 설계에 집중해서 시간을 쏟다보니 고민할 것들이 점점 많아지더라.
처음에는 간단하게 생각했던 것들이 생각을 거듭할수록 "어? 이건 어떻게해야하지? 어? 이건 이렇네?" 하는 것들이 많았다.

💡 좋은 개발자란, '요구사항에 대한 명확한 분석'을 할 수 있는 사람이다.
'요구사항에 대한 명확한 분석이 정말 개발자에게 제일 중요한 역량이 맞구나..'
'코드를 잘 짜고, 기술을 잘 알고, 우아하게 코드를 분리하는 것은 어쩌면 요구사항에 대한 명확한 분석보다는 덜 중요할 수 있겠구나..'

이번주의 경험이 없었다면, 나는 설계나 요구사항에 대한 분석의 중요도를 이렇게나 깊게 생각할 수 없었을 것 같다.
당연히 중요하다고는 생각했지만, 내 생각이나 손은 코드의 구현으로 빠르게 가려고 했기 때문이다.
"어쨌든, 나는 개발자니까 코드를 짜는 사람이고, 설계에 시간을 더 쏟기보다는 더 좋은 코드를 쓰자" 라는 생각이 앞섰던 것 같다.

💡 설계가 좋지 않으면 코드를 몇번이나 반복해서 수정해야한다.
처음 설계를 해놓고 mock api 를 구현해보려고 하니 설계의 오류를 발견했다.
그러고 나서도 몇번이나 설계를 다시 생각하고 고민했는지 모른다.

설계를 잘 한다는 것은 첫 단추를 제대로 끼우는 것을 의미한다.
물론, 당연히 나도 머리로는 알고 있었다.
그리고 아마 대부분의 개발자들도 알고 있을 것이다.
마치 교과서의 정석적인 내용이랄까?
당연히 설계를 잘하는 것이 중요하고, 그 설계를 통해 개발이 잘되는 것은 당연하니까..

하지만, 이번 경험을 통해 설계를 계속 수정해나가면서 이게 정말 중요하다는 것을 체감하게 되었다.
머리로 중요하다는 것을 아는 것과, 경험해보면서 아, 이게 정말 왜 중요한지 알겠다 라고 깨닫는 것은 다른 것같다.

🙏🏻 3. 글을 마치며

이번 한 주는 정말 개인적으로 너무 힘들었던 시간이었다.
몸이 이렇게 안좋았던적은 처음이라 당황스러울 정도였다.

컨디션 관리의 중요성도 깨달았던 한 주였던 것 같다.

이제, 본격적으로 콘서트 예약 프로그램을 개발할 차례다.
이번 한 주는 치열하게 고민하면서 실제로 구현을 하며 부딫혀보겠다.

이번 한 주도 화이팅!

지난 회고 보러가기

1주차 회고 - 테스트코드를 모르던 내게 찾아온 TDD
2주차 회고 - 코딩에 정답을 찾지말자. 고민을 통해 더 나아짐을 시작하자.

항해에 관심이 있으시다구요?

항해플러스에서 벌써 백엔드 6기 모집이 시작된다고해요. (내가 벌써 선배..?)
제 회고글을 모두 읽어 보신 분들은 잘 아시겠지만, 이 과정을 통해 정말 많은 것을 누리고, 배우고, 경험하고, 느끼고 있습니다.

솔직히 말씀드리면, 이 과정은 마냥 즐겁지는 않아요.
고통스럽고, 힘들고, 많이 지칩니다. 😔

더군다나 직장을 다니면서 병행한다면 잠을 포기하고 시간을 많이 갈아 넣어야해요.
하지만, 지금 열심히 항해중인 제가 감히 자신있게 말씀드리자면, 이 과정을 통해 지금까지 경험하지 못했던 압축된 성장을 경험할 수 있습니다.

혹시, 관심이 있으시다면 지원하실 때 추천인 코드(HHPGS0893)를 작성해주신다면 할인이 된다고 해요 ㅎㅎ
고민되시는 분은, 댓글로 달아주시면 커피챗을 통해 이야기 해도 좋을 것 같습니다.

성장을 위해 시간을 쏟을 준비가 되신 주니어 분들에게 정말 진심을 다해 추천합니다.