항해99 백엔드 플러스 1주차 회고 - TDD

 

들어가기전에...

10월까지 일하고 퇴사 후 약 한달정도 쉬었네요.

퇴사 직전에 남은 휴가 몰아쓰고 일주일정도 개발엔 손도 안대고 쉬었던거 같습니다.

 

퇴사를 결심하게 된 원인은 건강 문제가 컸습니다. 개발 업무 자체에 불만은 없었지만 업무 외적으로 스트레스가 쌓였고 공황장애로 이어지더라고요.

재직중에 이직하는게 가장 좋다지만 그게 건강보다는 중요하지 않다고 생각했어요. 그래서 제 상태를 인지하자마자 퇴사 결정을 하였습니다.

 

퇴사 후에 몇 번의 면접을 진행하였는데요. 신입때의 면접과는 많이 달라져있었습니다.

크게 두 가지가 체감되었는데요.

- 과제에 테스트 코드 작성이 거의 필수로 들어간다.

- 대용량 트래픽에 대한 동시성 제어에 대한 질문이 많다. (이건 경력 면접이라 그럴지도..?)

 

동시성 제어는 그렇다 쳐도 테스트코드를 이렇게나 많이 사용할 줄은 몰랐습니다...

그래서 이 두 가지에 대해 공부가 필요하다고 많이 느꼈습니다.

혼자 공부할까 하다가 퇴사한김에 교육을 받고 싶었습니다.

 

퇴사 전부터 여러 교육들을 찾아봤었는데요. 그 중에서 항해99 백엔드 플러스 과정을 눈여겨보고 있었습니다.

재직중에도 할까 말까 고민을 했었지만, 학교도 병행중이라 고민만하고 하지는 않았어요.

마침 퇴사도 했으니 이번이 기회다 라고 생각하여 뒤도 안돌아보고 신청하였습니다.

 

 

시작 전의 내 상태

기술스택의 차이

저의 주 기술스택은 Nodejs / Nestjs 입니다. 그런데 제가 신청한 과정은 Java / Spring 이었는데요.

자바, 스프링은 학생때 이후로 처음인지라... 복습이 필요했습니다.

마침 항해에서 사전 스터디를 진행했기에 최대한 공부하며 감을 잡아갔습니다.

 

테스트코드 작성 경험이 거의 없다...

보통 회사에서 API 개발하며 하는 일은 정해져있죠. API 개발 -> Postman 등으로 API 찔러보기 -> 반복...

제 주업무는 팀에서 운영하는 서비스의 고도화였습니다. 그래서 기존에 postman으로 직접 찔러보는 테스트를 e2e테스트로 자동화 하는 수준만 진행해봤었어요.

단위 테스트도 진행해봤었지만 제대로 해본것도 아니었고 핵심 로직을 보호하는 목적으로 몇번 해본게 전부였습니다.

사전 스터디에 TDD 과정도 있어서 스터디를 진행하며 TDD에 대한 감이라도 잡아보고자 하였습니다.

 

 

1주차 시작!

12월 중순부터 본격적으로 과정이 시작되었습니다.

1주차 과제 자체는 언뜻보면 단순했습니다. 간단한 API를 TDD 방식으로 개발하는거였죠.

그런데... 코드 한줄 짜는것조차 쉽지 않았습니다.

 

API를 개발하고 테스트를 적용하는거라면 간단했을겁니다. 그런데 TDD.... 이건 진짜 쉽지 않더라고요???

정책을 짜고 그에 맞는 테스트가 선행되어야 하는데 그러질 못했습니다.

테스트코드 한줄 짤때마다 머릿속엔 기능 구현이 떠올라서 계속해서 버벅였습니다.

 

테스트 하나 짜는것도 오래걸리는 자신을 보며 머리 한대 얻어맞은거 같았어요.

하지만 익숙하지 않아서 그런거라 생각하며 한줄한줄 힘들게 작성해나갔습니다.

 

 

점점 익숙해지는 TDD

테스트를 몇개 작성하면서 나름대로의 경험을 얻게 되었습니다.

기능들은 인터페이스로 미리 작성하니 테스트를 작성할때 버벅임이 많이 사라지더라고요.

테스트 작성 후에는 인터페이스 기반으로 자연스럽게 구현으로 이어졌습니다.

 

TDD를 하면서 개인적으로 가장 좋았던 경험은 구조 개선에 도움이 자연스럽게 떠오르는 점이었습니다.

모킹을 진행하며 무엇이 사이드 이펙트인지 잘 보였고 이는 의존성을 분리하는데 도움이 되었습니다.

 

코드를 수정할때마다 테스트를 직접 할 필요 없다는 점은 말할것도 없구요. (사실 가장 큰 장점!)

 

 

처음 해보는 동시성 제어

Nodejs로 비동기 처리만 하던 저에게 동시성... 심지어 직접 락을 제어해보는건 굉장히 생소한 경험이었습니다.

DB 락에 대한건 어렴풋이 알고 있었지만 스레드 락은 금시초문이라 처음부터 공부했습니다.

 

저는 이번 과제에서 ConcurrentHashMap과 ReentrantReadWriteLock을 조합하여 유저별로 락을 제어하였습니다.

단순 조회에 읽기락을 적용하는 것에 대해서는 많이 고민되더라고요.

일반적으로 데이터에 대한 수정보다 조회가 많이 이루어집니다.

그런데 쓰기락은 읽기락보다 우선순위가 떨어집니다. 즉, 우선순위에 의해 쓰기락의 대기가 길어지며 락 고갈 사태가 발생할 수도 있습니다.

 

하지만 데이터를 자료구조로 사용중인 HashMap 특성상 수정중에 조회를 하면 데이터 정합성이 깨질 수 있다고 판단하여 읽기락도 적용하는게 낫다고 판단하였습니다.

(사실 이 판단은 지금도 긴가민가합니다...ㅠ)

 

 

멘토링 좋다

과제를 진행하는동안 현업에 계신 시니어 분들께서 주 1시간씩 팀별 멘토링을 해주십니다.

멘토링을 진행하며 모르는 부분을 질문하며 부족한 부분을 채워나갈 수 있어서 좋았습니다.

다른 팀의 멘토링도 청강이 가능하여 다른 팀의 멘토님들의 멘토링도 들을 수 있던것도 너무 좋았어요.

 

 

어찌저찌 끝낸 1주차

퇴사한 상태이기에 모든 시간을 과제에 쏟았습니다.

그런데 집중이 진짜 안되더라고요... 하루종일 한가지 일만 하다보니 더 그런것 같았습니다 ㅠ

앞으로는 밀도 있게 공부할 수 있도록 하루 루틴을 정해야한다고 느꼈습니다.

 

 

 

KPT 회고

KPT 회고를 통해 한 주를 되돌아보며 마무리합니다!

Keep

- 팀별 모각코를 매일 진행했다.

- 구현보다 테스트를 먼저 작성하는걸 성공했다.

 

Problem

- 집중도가 높지 않다...

- 정책이 분석이 부족하여 테스트에 구멍이 많았다.

- 문서 작성 실력이 아직 부족하다.

- 질문이 잘 떠오르지 않는다.

 

Try

- 밀도 있게 개발을 하자

- 테스트를 작성하기 전에 정책 분석에 많은 시간을 쏟자.

- 나만 보는 문서가 아닌 남에게 보여주기 위한 문서 작성임을 인지하자