항해+ 백엔드 코드 1주차 회고

 

정말 바쁜 한 주가 지나갔다. 물론 이제 시작이고 앞으로 9주가 더 남았다......

나는 웹 개발자가 아니라서 학습하는 거의 대부분이 생소한 개념들이라 과제도 바로 시작을 못하고, 개념부터 학습하는 방식으로 작업하다 보니, 정말 많은 시간이 필요했고, 이번주엔 회식도 겹치는 바람에 더 시간이 없었다. ㅜㅜ
과제에서 얻을 수 있었던게 100이라면, 난 30만 얻은 것 같다. 하지만 30이라도 확실히 내 것으로 만들었다는 것이 중요한 거 같다.

 

1. 과제내용

STEP01 - 기능 추가 및 테스트 구현

• 포인트 충전, 사용에 대한 정책 추가 (잔고 부족, 최대 잔고 등)
• 4가지 기본 기능 (포인트 조회, 포인트 충전/사용 내역 조회, 충전, 사용)에 대한 구현
• 4가지 기본 기능에 대한 테스트 작성
• 단, 이때 /database 패키지의 구현체는 수정하지 않고, 이를 활용해 기능을 구현함

STEP02- 동시성 학습 및 구현

• 동일한 사용자에 대한 동시 요청에 대한 테스트를 먼저 작성함
• 이후 해당 테스트가 정상적으로 처리될 수 있도록 개선함
• 선택한 언어에 대한 동시성 제어 방식 및 각 적용의 장/단점을 기술한 보고서 작성 ( README.md )

 

https://github.com/seuthootDev/hanghae99-backend-week1/pull/1

Step01 by seuthootDev · Pull Request #1 · seuthootDev/hanghae99-backend-week1

https://github.com/seuthootDev/hanghae99-backend-week1/pull/2

Step02 by seuthootDev · Pull Request #2 · seuthootDev/hanghae99-backend-week1

 

과제는 기본, 심화 2가지 step이 있었고, 개별 브랜치로 pr해서 링크를 제출하는 방식으로 제출했다.

---

2. 과제 진행 과정

이번 과제는 TTD 기반의 포인트 충전 API 작성 + 동시성 제어였다

TDD란 Test Driven Development의 약자로 ‘테스트 주도 개발’이라고 한다.

반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다. 특징적인 것은 "테스트 코드를 먼저 작성하는 개발 방법론"이라는 것이다.

 

이번 과제에서는 동시성 제어보다 TDD에 더 많은 시간을 쏟게 되었다. 웹 개발 자체에 익숙하지 않다 보니 기능 구현에 많은 시간이 필요했고, 테스트 코드를 작성하는 데에도 상당한 시간을 투자하게 되었기 때문이다.

이번 과제를 통해 테스트 코드의 필요성과 유용성에 대해 깊이 생각해보는 계기가 되었다. 항해 본 과정을 시작하기 전에 동기들과 함께한 사전 스터디에서는 Postman을 사용해 수동으로 테스트를 진행했었는데, 테스트 코드를 작성해서 자동화하는 방식이 훨씬 효율적이였다.

사실 지금 다니는 회사에서는 테스트 코드를 따로 작성하지 않고 있었지만, 지난주에는 내가 작성한 모든 파일에 테스트 코드를 작성했다. 테스트 도구를 활용한 것은 아니지만, Python 프로젝트에서 main.py를 실행하는 방식 대신, 의존성 있는 파일을 직접 실행해서 테스트할 수 있도록 구성했다. 이 과정에서 직접 Mock 클래스를 구현해 사용했는데, 과제를 통해 처음 접한 ‘모킹’이라는 개념을 바로 실무에 적용했다는 것이 신기했다. 실무 환경은 웹 개발이 아니지만, 테스트라는 개념은 개발 전반에 걸쳐 통용될 수 있다는 점에서, 나만의 개발 철학이 하나 생긴 것 같았다.

심화 과제였던 동시성 제어는 async-mutex 라이브러리를 활용해 구현해보았지만, 시간 부족으로 깊이 있게 학습하지는 못했다. 다행히 3~4주차 과제에서 다시 다룰 기회가 있다고 하니, 그때는 더 시간을 들여 제대로 학습해보고 싶다.

---

3. 어려웠던 점 & 해결 방법

TDD 관련해서 어려웠던게 몇가지 있는데,
 - TDD 싸이클은 얼마나 지켜야 하지?
 - 테스트 커버리지는 목표를 어느정도로 잡아야하지?
 - 모킹은 언제 활용하고 또 언제 활용하면 안 되지?

이 외에도 고민이 많았지만, 공통점은 모두 '명확한 정답이 없는 문제'라는 점이다.

항해에서는 매주 팀별로 코치님과의 온라인 멘토링 시간이 주어지며, 다른 팀의 멘토링을 청강하는 것도 허용된다. 나 또한 우리 팀뿐만 아니라 다른 팀의 멘토링, 전체 Q&A 시간을 적극 활용하면서 여러 인사이트를 얻었고, 결국 나만의 결론에 도달했다.

그 결론은 바로 "비즈니스적 가치를 기준으로 판단하자"였다.
TDD 사이클처럼 ‘방식’ 자체에 너무 얽매일 필요는 없고, 상황과 조건에 따라 유연하게 접근하는 것이 더 중요하다고 느꼈다. 테스트 커버리지나 모킹 여부도 마찬가지다. 정답이 아닌 ‘적합한 선택’을 하는 것이 핵심이다.

물론 아직 나는 상황 판단의 눈이 충분히 갖춰져 있진 않다. 그래서 이번에는 기본을 최대한 지키되, 생산성과 효율을 고려한 융통성을 곁들이는 방식으로 접근했다.
예를 들어, TDD의 원칙은 ‘레드-그린-리팩터’ 순서지만, 작업 중에는 먼저 그린 단계(기능 구현)를 진행한 뒤 테스트 코드를 작성하는 경우도 있었다. 그 방식이 개발 흐름과 생산성을 더 잘 살려준다고 판단했기 때문이다.

---

4. TypeScript 팀 화이팅

우리 팀은 정말 실력자들로만 구성된 것 같다. 물론... 나를 제외하고 말이다.
이게 팔이 안으로 굽는게 아니라, 진심으로 그렇게 생각하고 있다. TypeScript 언어는 물론, NestJS 프레임워크 활용 능력이나 개발에 대한 철학까지 모두 다들 뛰어난 분들이다.

항해에서는 사용하는 언어 기준으로 팀을 나누는데, TS를 사용하는 팀은 우리 팀이 유일하다. 이유는 정확히 모르겠지만, 우리나라에서는 아직 TypeScript를 사용하는 회사가 별로 없기 때문이라고 생각한다.

그런데 솔직히 말하면, 지금 이 상황이 나에게는 오히려 좋은 기회다.
항해에서는 매주 랜덤 코드 리뷰를 진행하는데, 팀을 섞어서 다른 사람들과 코드 리뷰를 하게 된다. 실력자들은 다양한 시각과 네트워킹을 위해 매주 새로운 사람들과 리뷰하는 걸 좋아할 수 있지만, 나는 아직 초심자라서 내 실력을 잘 파악하고, 정확한 피드백을 줄 수 있는 우리 팀원들과 꾸준히 리뷰를 할 수 있는 점이 오히려 더 큰 행운이라고 느낀다. 오늘도 팀원들로부터 정말 많은 피드백을 받았고, 하나하나가 큰 도움이 되었다. 팀원들에게 진심으로 감사하다.

회사에서는 주로 혼자 개발을 하다 보니 협업의 경험이 부족했는데, 이번 과제를 하며 팀원들이 실무에서 협업하는 방식, 코드 리뷰에서 나오는 다양한 시각들을 접하면서 많은 인사이트를 얻고 있다. 단순히 기술적인 성장을 넘어, 협업하는 개발자로서도 한 걸음 나아가고 있는 느낌이다.

---

5. 다음 주 목표 & 다짐

이번 주 과제는 다행히 기본 과제와 심화 과제 모두 PASS를 받았다.

다음 주에도 좋은 결과를 얻기 위해서는 일요일부터 화요일까지의 시간을 어떻게 쓰느냐가 정말 중요하다고 생각한다. 특히, 코치님과의 멘토링 시간을 효과적으로 활용하려면 사전 학습이 필수다.
사실 지난주 멘토링 때는 준비가 부족해서, 멘토링이 끝난 뒤에야 "아, 그때 이걸 물어봤어야 했는데..." 하는 아쉬움이 많았다.

또한 애초에 과제를 하는 시간이 넉넉하지는 않다. 그래서 이번 주는 화요일 전까지 기본 과제를 마무리하고, 남은 시간 동안 심화 과제를 더 깊이 있게 학습하는 것을 목표로 삼았다.
이번에는 더 효율적인 시간 활용과 준비를 통해, 더 의미 있는 한 주를 만들어보고 싶다.

 

 

 

 

항해 추천인코드:NYFKU8

20만원 할인 받으세요~