항해 플러스 백엔드 WIL 6, 7, 8, 9, 10주차 회고

항해 플러스 백엔드 WIL - 6/7/8/9/10주차 회고

최초 업로드 2025-09-14 / 마지막 수정 2025-09-14

6주차부터는 회사일도 바빠지고 하여 회고를 적을 여유가 없었다.
또한, 대용량 트래픽은 정말 실무에서 경험해보고 싶고 잘하고 싶지만, 지금 회사에서 주요한 문제는 아니기에 깊게 파고들지는 못했다.
- 오히려 나에게는 1~5주차까지의 전반부가 회사 실무에는 직접적인 도움이 많이 되었던 것 같다.
- 물론 이후에 회사가 확장하거나 내가 다른 환경에서 일하게 될 때에도 많은 도움이 될 개념들을 배울 수 있었다는 것은 너무 좋았다.

6, 7주차 Redis

Redis의 3가지 쓰임새(캐싱, 분산락, NoSQL)를 모두 써볼 수 있어서 알찼었다.
저장소가 여러 군데가 있을 경우 어떻게 해야 원자성을 보장할 수 있는지 고민을 많이 했던 기억이 있다.
- 결론은 분산 트랜잭션처럼 로그성 기록을 항상 함께 남겨서 어느 순간에 서버가 꺼지거나 장애가 났을 때 대비가 되도록하는 것이었다.
Redis에 존재하는 Sorted Set 같은 다양한 자료구조 기능들도 맛보기로 사용해보는 기능 구현도 있었다.

8, 9주차 분산 Transaction, MSA, Kafka

현재 우리 회사도 일부 도메인에서는 rabbitmq를 통해 이벤트로 서로 통신하고 있다.
다만 MSA를 회사에서 언제 도입하게 될지는 모르겠다.
MSA로 꼭 가지 않더라도 쓸 수 있는 흥미로운 패턴들을 배웠다.
- 분산 Transaction을 구현할 때 쓰는 Outbox, Inbox 패턴을 구현해볼 수 있었다.
- Kafka로 쿠폰 선착순 발급 이벤트를 Self-consuming해서 백프레셔 관리를 하는 작업을 진행해보았다.

10주차 장애 대응

APM, datadog, grafana 등의 툴들이 등장했다.
k6로 성능 측정하고 최적화하는 과제였다.
사실 툴들은 써보면서 시간을 많이 투자해보아야 이게 좋은지 나쁜지 언제 쓰는지 감이 올 것 같았다. 현재 내 회사는 영세하기에 다양한 툴들을 마구 도입해보기에도 조금은 벅찬 상황이다. 언젠가 서비스가 커지고 매출이 많아진다면 도입되기 시작하지 않을까싶다. 당장은 더 급한 불들이 많아서 먼저 매출을 내야한다. 매출이 나오고 안정화와 확장을 해야할 때 도입할 것 같다.
k6는 6주차에도 많이써봐서 나름은 익숙해진듯하다. 매우 유용하고 사용하기 편리하다고 느꼈다.
- 확실히 DX에 집중하는 툴이라는게 느껴졌다. 설정할 것도 없고 그냥 원클릭으로 바로 사용가능한 느낌이었다.

항해 전체 회고

처음 0주차, 1주차 때 작성했던 회고가 지금까지 이어지는 것 같다.
- "네트워크"라는 것은 큰 것들을 덜 놓치게 해주는 안전망처럼 느껴졌다.
  - 서로 매주 듣고 보는 것들을 공유하기에 시너지가 존재한다고 생각한다.
  - 물론 그런 안전망의 편안함에 도취되어 생존감각을 잃어서는 안된다.
TS팀이다보니 고립된 느낌이 꽤 강했다.
- TS팀은 Kotlin, Java와 달리 인원이 매우 적어서 우리끼리만 코드 리뷰 같은 것들이 배정된다.
- 후반 주차에는 거의 세션들에 나 혼자 참여했어서 다른 팀들에 몰래 들어가서 양해를 구하는 신세를 면치 못했다.
- 지적인 교류가 적어서 아쉽긴했다. 물론 내가 시간이 훨씬 많았으면 Kotlin으로도 구현해보면서 다른 분들 코드 리뷰에 적극 참여했을텐데, 시간이 절대적으로 부족한 것도 컸다.
- 진짜 회사를 다니면서 작업하시는 분들의 비율이 생각보다는 적었던 것 같다. 아마 한 반반정도되지 않을가 싶다. 일을 쉬면서 하시는 분들이 꽤 많았다.
10기 항해 스터디메이트로 지원했다.
- TS 잘하시는분 보이면 우리 회사로 영입 제안을 해보면 어떨까 한다.
- 면접 10번 보는 것보다 유효한 talent 저격 전략이라고 느꼈다.
뱃지는 레드로 추정된다. 18/20 통과에 2 Best Practice를 받았는데, 3주차에 fail을 맞아서 블랙 뱃지는 받지 못했다.
시간이 더 허락해주었다면 사람들과 zep에서 더 어울리고 그랬을텐데, 회사가 애초에 10to10인 상태에서 작업하다보니 그러기는 어려웠다.

앞으로의 계획

다음주부터는 항해에서 얻은 추진력을 이어나갈 다음 프로젝트들을 찾고자한다.
- 2026 LLM Trend Ebook
  - TSBM에서 운영하는 TSBM Studio의 메이커로서 지원은 해두었다. (진짜로 리드 메이커로 진행할지는 심사도 거쳐야하며 나도 고민중이다.)
  - TSBM Studio 프로젝트가 당장 결렬된다고 해도 아마 혼자 어떻게 진행하지 않을까 싶다.
  - 특히, LLM으로 LLM 트렌드를 모아서 정리해주는 자동 업데이트되는 Ebook을 고안중이다.
    - 토큰 비용은 조금 많이 들수도...
    - 매일 github에 올라오는 trending을 모아서 DA하면 트렌드를 알 수 있지 않을까 => 여기서 출발한 아이디어이다.
- Typescript 생태계 다양한 오픈소스 기여 - class-validator 같은 자주 쓰이는 라이브러리들 보면 이슈가 상당히 존재하는 것으로 보여진다. 기여할 수 있을 것 같다. 몇 개의 레포에서 여러 번 PR 기여를 할 계획이다.
- TSBM 스터디 참여
  - 타 메이커 분들이 진행하는 스터디에 참여하려한다.
  - 다양한 관점에서 사람들의 생각들을 들어볼 수 있을 것 같아서 배울 수 있는 폭을 조금 넓힐 수 있지 않을까 생각중이다.

항해 플러스 백엔드 WIL - 6/7/8/9/10주차 회고

최초 업로드 2025-09-14 / 마지막 수정 2025-09-14

6주차부터는 회사일도 바빠지고 하여 회고를 적을 여유가 없었다.
또한, 대용량 트래픽은 정말 실무에서 경험해보고 싶고 잘하고 싶지만, 지금 회사에서 주요한 문제는 아니기에 깊게 파고들지는 못했다.
- 오히려 나에게는 1~5주차까지의 전반부가 회사 실무에는 직접적인 도움이 많이 되었던 것 같다.
- 물론 이후에 회사가 확장하거나 내가 다른 환경에서 일하게 될 때에도 많은 도움이 될 개념들을 배울 수 있었다는 것은 너무 좋았다.

6, 7주차 Redis

Redis의 3가지 쓰임새(캐싱, 분산락, NoSQL)를 모두 써볼 수 있어서 알찼었다.
저장소가 여러 군데가 있을 경우 어떻게 해야 원자성을 보장할 수 있는지 고민을 많이 했던 기억이 있다.
- 결론은 분산 트랜잭션처럼 로그성 기록을 항상 함께 남겨서 어느 순간에 서버가 꺼지거나 장애가 났을 때 대비가 되도록하는 것이었다.
Redis에 존재하는 Sorted Set 같은 다양한 자료구조 기능들도 맛보기로 사용해보는 기능 구현도 있었다.

8, 9주차 분산 Transaction, MSA, Kafka

현재 우리 회사도 일부 도메인에서는 rabbitmq를 통해 이벤트로 서로 통신하고 있다.
다만 MSA를 회사에서 언제 도입하게 될지는 모르겠다.
MSA로 꼭 가지 않더라도 쓸 수 있는 흥미로운 패턴들을 배웠다.
- 분산 Transaction을 구현할 때 쓰는 Outbox, Inbox 패턴을 구현해볼 수 있었다.
- Kafka로 쿠폰 선착순 발급 이벤트를 Self-consuming해서 백프레셔 관리를 하는 작업을 진행해보았다.

10주차 장애 대응

APM, datadog, grafana 등의 툴들이 등장했다.
k6로 성능 측정하고 최적화하는 과제였다.
사실 툴들은 써보면서 시간을 많이 투자해보아야 이게 좋은지 나쁜지 언제 쓰는지 감이 올 것 같았다. 현재 내 회사는 영세하기에 다양한 툴들을 마구 도입해보기에도 조금은 벅찬 상황이다. 언젠가 서비스가 커지고 매출이 많아진다면 도입되기 시작하지 않을까싶다. 당장은 더 급한 불들이 많아서 먼저 매출을 내야한다. 매출이 나오고 안정화와 확장을 해야할 때 도입할 것 같다.
k6는 6주차에도 많이써봐서 나름은 익숙해진듯하다. 매우 유용하고 사용하기 편리하다고 느꼈다.
- 확실히 DX에 집중하는 툴이라는게 느껴졌다. 설정할 것도 없고 그냥 원클릭으로 바로 사용가능한 느낌이었다.

항해 전체 회고

처음 0주차, 1주차 때 작성했던 회고가 지금까지 이어지는 것 같다.
- "네트워크"라는 것은 큰 것들을 덜 놓치게 해주는 안전망처럼 느껴졌다.
  - 서로 매주 듣고 보는 것들을 공유하기에 시너지가 존재한다고 생각한다.
  - 물론 그런 안전망의 편안함에 도취되어 생존감각을 잃어서는 안된다.
TS팀이다보니 고립된 느낌이 꽤 강했다.
- TS팀은 Kotlin, Java와 달리 인원이 매우 적어서 우리끼리만 코드 리뷰 같은 것들이 배정된다.
- 후반 주차에는 거의 세션들에 나 혼자 참여했어서 다른 팀들에 몰래 들어가서 양해를 구하는 신세를 면치 못했다.
- 지적인 교류가 적어서 아쉽긴했다. 물론 내가 시간이 훨씬 많았으면 Kotlin으로도 구현해보면서 다른 분들 코드 리뷰에 적극 참여했을텐데, 시간이 절대적으로 부족한 것도 컸다.
- 진짜 회사를 다니면서 작업하시는 분들의 비율이 생각보다는 적었던 것 같다. 아마 한 반반정도되지 않을가 싶다. 일을 쉬면서 하시는 분들이 꽤 많았다.
10기 항해 스터디메이트로 지원했다.
- TS 잘하시는분 보이면 우리 회사로 영입 제안을 해보면 어떨까 한다.
- 면접 10번 보는 것보다 유효한 talent 저격 전략이라고 느꼈다.
뱃지는 레드로 추정된다. 18/20 통과에 2 Best Practice를 받았는데, 3주차에 fail을 맞아서 블랙 뱃지는 받지 못했다.
시간이 더 허락해주었다면 사람들과 zep에서 더 어울리고 그랬을텐데, 회사가 애초에 10to10인 상태에서 작업하다보니 그러기는 어려웠다.

앞으로의 계획

다음주부터는 항해에서 얻은 추진력을 이어나갈 다음 프로젝트들을 찾고자한다.
- 2026 LLM Trend Ebook
  - TSBM에서 운영하는 TSBM Studio의 메이커로서 지원은 해두었다. (진짜로 리드 메이커로 진행할지는 심사도 거쳐야하며 나도 고민중이다.)
  - TSBM Studio 프로젝트가 당장 결렬된다고 해도 아마 혼자 어떻게 진행하지 않을까 싶다.
  - 특히, LLM으로 LLM 트렌드를 모아서 정리해주는 자동 업데이트되는 Ebook을 고안중이다.
    - 토큰 비용은 조금 많이 들수도...
    - 매일 github에 올라오는 trending을 모아서 DA하면 트렌드를 알 수 있지 않을까 => 여기서 출발한 아이디어이다.
- Typescript 생태계 다양한 오픈소스 기여 - class-validator 같은 자주 쓰이는 라이브러리들 보면 이슈가 상당히 존재하는 것으로 보여진다. 기여할 수 있을 것 같다. 몇 개의 레포에서 여러 번 PR 기여를 할 계획이다.
- TSBM 스터디 참여
  - 타 메이커 분들이 진행하는 스터디에 참여하려한다.
  - 다양한 관점에서 사람들의 생각들을 들어볼 수 있을 것 같아서 배울 수 있는 폭을 조금 넓힐 수 있지 않을까 생각중이다.