[루퍼스] 10주간 돌아보기

10주간의 과정 

PG 개발에서의 원자성 보장과 테스트코드 

당시에는 메서드에 붙은 @Transactional이 어떻게 작성되어야 원자성이 보장되는지 잘 알지 못했다. 이전 주차에 했던 내용이라 생각할 수 있겠지만 실패 케이스를 고려하거나 외부 API를 포함하지 않는 로직에 대해서는 고려하지 않았기 때문이다. 그렇게 Fail을 마주하고 트랜잭셔널에 대해서 로그를 찍어보면서 어떻게 실행되는지 확인하고, 처음부터 차근차근 개발했다. 애플리케이션을 제대로 돌아가게는 두어야 하기에 이벤트를 잠깐 두고 결국은 해냈다. 뭐든 차근히, 너무 멋있게 가 아닌 절차적으로라도 개발하면 그 이후는 더 쉽다는 것을 몸소 깨달았다. 

 

그리고 그 후, 다른 사람들의 코드를 많이 보았다. 다른 분들은 어떻게 이 원자성을 지키려고 했을까? 란 관점으로 보았는데 한눈에 보이는 코드도 있었지만 다른 방식으로 개발한 코드는  “이건 원자성이 잘 보장되나? 실패했을 때 필요한 값들이 제대로 남는 걸까?” 궁금해졌다. 그 때 테스트코드를 확인하거나 돌려보고 싶었는데 없거나 테스트 케이스가 해피케이스 밖에 없을 때는 아쉬운 마음이 들었다. 이 경험을 통해 테스트 코드 작성의 중요성을 느끼기도 했다. 작성한 코드가 의미 있게 동작하는지, 실패 상황에서는 어떻게 처리되는지 빠르게 검증하려면 테스트 코드가 필수적이라는 점을 느꼈다.

이벤트

그 다음에 처음에 잘 와닿지 않았던 주제가 이벤트였다. 특히 POST 요청을 처리하는 API에서 이벤트를 사용하면, 응답이 완전히 최종 상태를 반영하지는 않는다는 점이 어려웠다. 주요 로직에서 일부 처리를 이벤트로 분리하는 방식인데, “분리할 수 있는 걸 분리한다면, 조회와 저장도 분리할 수 있겠다”라는 생각이 들었다.

또한 현재 시스템의 구조에 따라 이벤트로 분리할 수 있는 지점이 달라진다는 것도 느꼈다. 이벤트를 활용하면 단순한 분리뿐 아니라 유량 제어도 가능하다는 점이 인상적이었다. “아, 이벤트를  활용해 시스템 부하를 조절할 수 있구나”라는 깨달음이 꽤 컸다.

 

---

10주간의 전과 후

 

시작하기 전 목표

루퍼스를 하기 전 과정에서 새로운 것을 할 때 빨리 해내는 것이 목표 중 하나였다. 양철인형을 빨리 만들기! 새로운 것들을 마주하게 될 텐데, 그때 나는 너무 고민하지 말고 나만의 튜토리얼을 잘 만들어 나가자라는 마음으로 했다. 트랜잭셔널을 공부하기 위한 아주 작은 프로젝트, 카프카에서 토픽안에서 타입을 분리하기 위해 역직렬화 과정에서 삽질했던 것을 작은 프로젝트로 해결했던 부분들에서 꽤 해냈다고 본다. 그리고 이 과정을 지치지 않고 할 수 있었던 것은 함께한 열정 있는 멘토분들과 1기 분들 덕분이다. 

 

 

토요일의 나, 월요일의 나, 금요일의 나, 그리고 다시 토요일의 나

루퍼스 10주 과정에 참여하면서 토요일 발제를 듣고 나서는… 음..?  월요일쯤 멘토링 전에는 질문을 하기 위해서 새로운 개념과 과제를 붙잡고 씨름하게 된다. 그러다 멘토링 후에는 큰 그림을 그리게 된다. 그렇게 힘을 받고 구현을 하다보면 세세하게 궁금한 것들이 생기게 된다. 그 때 그날의 멘토링을 청강하고 해결해 나가지만 아직 풀리지 않은 것들이 많다. 그러다가 금요일은 키보드에 불이 나게 구현을 하고 제출하게 된다. 리뷰 포인트 적는 것도 고민을 많이 해야한다. 어떤 부분을 질문해야할지, 그리고 질문한 부분을 코드를 보는 사람이 어떻게 보면 좋을지 생각하면서 커밋을 기록한다. 그렇게 제출하면 아직도 머리가 복잡하면서도 뭔가 하나는 뚫린 듯한 뿌듯함이 찾아온다.

 

그리고 다시 토요일이 돌아오면 그 전 주차 고민했던 것들을 자연스럽게 알게 되는 순간들이 오는데 그게 참 신기했다. 리뷰 포인트의 답으로도 랜덤 리뷰로도 알게 되고 다른 주차 과제를 하면서 자연스럽게 알게 되기도 한다. 그 주차에는 단순히 “중요하다”라는 말만 들어왔던 포인트들을 실제로 체감하는 순간들이 있다. 

 

과제를 붙잡고 고민하다 보면 혼자서는 여러 갈래로 흩어지기 쉽지만, 멘토링을 통해 그 고민의 물길이 올바른 방향으로 잡히곤 했다.

 

멘토링을 듣는다고 해서 바로 모든 걸 알게 되는 건 아니다.  어느 정도 해결 방향을 잡고 직접 구현을 해보다 보면 비로소 깨닫게 되는 것들이 있다. 이런 과정이 거의 매일 반복되니 지루할 틈이 없었다. 그 부분이 나와 잘 맞는 부분이였다. 혼자라면 오래 붙잡고 지치거나, 아무 소리 없는 벽과 싸우는 기분이 들 수 있는데 이 과정에서는 매일매일이 해결의 연속이고, 그것도 혼자가 아닌 많은 사람들과 함께였다. 

 

물론 10주 동안 매일 고민하고 해결하는 과정은 쉽지 않았다. 체력적으로 지쳐서, 나중에는 앉아 있는 것조차 힘든 순간도 있었다. 하지만 동시에 10주라는 끝이 멀지 않다는 사실이 버티게 해주었다. 혹시 놓치는 주간이 있더라도, 최소한 “무엇을 해야 하는지”  체크해둘 수 있다면 조급함이나 동시에 올 수 있는 나른함을 피할 수 있다.