Loopers 10주 회고

 

7월 중순에 시작했던 루퍼스 루프팩 교육과정이 내일이면 끝난다.

금융권 회사로 이직하게 되면서, 최신 기술과는 더 멀어졌고 IT가 메인인 회사가 아니다보니 개발자보다는 현업 업무 직군의 사람들이 많았다. 나는 그냥 스탭부서의 IT지원팀 사원 1명일 뿐이었다ㅎㅎㅎ.

하지만 자유로운 출근, 칼퇴, 복지 등 안정적이고 편한 환경에 점점 익숙해지면서 열정을 잃어가고 있었다.. 이렇게 사는 게 나쁘지 않을 수도 있다는 생각을 하며.....

전 회사인 SI회사에 다니면서 원하는 기술을 사용하는 백엔드 개발자가 되고싶어 호기롭게 퇴사했는데 더 도태되어가고 있는 느낌이었다.

현재의 컴포트 존에서 벗어나야겠다는 생각이 들어서 나를 강제성이 있는 환경에 가둬야겠다고 생각했고, 지인의 추천을 받아 루퍼스 교육과정에 등록하게 되었다.

결과적으로 물론 새로운 기술들을 알게 되고, 개발 실력 또한 많이 성장하였지만, 다른 개발자들이 어떤 환경에서 어떻게 일을 하고 있고 한 주제에 대해 얼마나 많은 고민을 할 수 있는 지, 어떤 회사가 좋은 회사인지 이러한 인사이트 들을 더 많이 알 수 있었던 것 같다.

 

교육 과정

루퍼스는 10주 과정으로 이루어져있는데,

 

1주차 - TDD (Test Driven Development)

기능들을 구현하기에 앞서 테스트 코드를 작성하는 방법에 대해 배웠다. 오히려 성공, 실패 테스트 코드를 생각하며 작성하다 보니 어떤 기능이 필요한 지 더 명확해졌다.

테스트 종류에는 단위테스트(Unit Test), 통합 테스트(Integration Test), E2E 테스트(End-to-End Test)가 있고,

테스트 대상이 의존하는 외부 객체의 동작을 대체 할 수 있는 테스트 더블 Stub, Mock, Spy, Fake가 있다.

테스트 가능한 구조를 작성하다 보면, 외부 의존성 분리/비즈니스 로직분리/책임 단일화/상태중심 설계가 자연스럽게 가능해진다.

 

2주차 - Software Design

2주차에서는 설계 문서를 작성하였다.

평소 ERD 정도만 작성한 뒤 바로 구현에 들어갔었는데, ERD 말고도 요구사항 명세서, 시퀀스 다이어그램, 클래스 다이어그램에 대해 공부할 수 있었고, 작성하는 방법을 알 수 있었다.

이러한 문서들을 작성하며 도메인 별로 어떤 기능들이 필요한 지 명확해졌고, 무엇보다 도메인 중심으로 설계하는 것의 중요성과 편리함을 깨닫게 되었다. 그동안 객체지향에 관련한 많은 책을 읽고, 강의를 들었었는데 오히려 도메인 중심으로 생각하는 방법을 기르다 보니 객체지향에 대해 깊이있게 이해할 수 있었던 것 같다.

 

3주차 - Domain Modeling & Development

3주차부터 본격적으로 구현을 시작하며, 패키지 구조나 아키텍처 등에 대해 고민해볼 수 있었다. 아는거라곤 Spring MVC 구조로 model-view-controller 를 나누는 구조밖에 없었는데, appliction / domain / infrastructure / interfaces 이러한 계층 구조로 레이어드 아키텍처를 만들어가다 보니 의존성과 책임이 어떻게 분리될 수 있는 지 인터페이스를 어떻게 활용해야 하는지 도메인이 왜 순수해야 하는지 이러한 개념들을 확실히 깨달을 수 있었다!

 

4주차 - Transactional Operation

4주차에는 트랜잭션과 그에 따른 동시성 문제에 대해 학습하였다.

기존에는 만약 하나의 서비스에서 두 번 이상 DB에 접근하면 무조건 @Transactional을 붙이면 장땡이라고 생각했었다. 하지만, 무분별한 트랜잭션 사용은 성능 저하와 의도치 않은 트랜잭션 경계를 만들 수 있다는 사실을 알게 되었다. 트랜잭션을 최소한의 경계에만 두고, DB 제약·예외 처리·멱등성을 함께 고려해야 한다는 것을 깨달았다. 

또, 공유 자원에 여러 사용자가 동시에 접근할 때 정합성을 위해 사용하는 락 전략(낙관적 락, 비관적 락)에 대해 배웠다.

 

5주차 - Practical Read Optimization

5주차는 구조 개선을 통해 성능을 개선시켰다. 실제로 10만건 이상의 데이터를 추가하여 읽기 병목을 해결하기 위한 여러 방법등을 적용해보며 확연한 성능 차이를 눈으로 확인할 수 있었다.

성능 개선 방법에는 인덱스 설계 / Redis 캐시가 있다. 인덱스를 적용할 때에도 단일vs복합 인덱스, 또한 복합 인덱스를 사용할때도 어떠한 조합으로 인덱스를 설정하는 지에 따라 성능 차이를 볼 수 있다. 캐시도 적용해보았는데, 항상 동일한 요청이 반복되는 경우 매번 DB를 읽지 않고 캐시를 통해 빠르게 해결할 수 있었다.

실제로 캐시는 회사 업무에 적용하여 사내 메인 포털의 100여개 링크 정보를 캐시로 제공하여 반복적 DB 조회를 제거하고, 무효화 정책으로 변경 시에만 리로드되도록 개선해보았다.

이러한 성능 개선을 그저 적용에만 끝내지 않고, 실제 DB 실행계획이나 Grafana 그래프, k6 도구를 통해 정확한 수치를 비교해보며 확인할 수 있는 방법을 알게되었다.

 

6주차 - Failure-Ready Systems

외부시스템 연동 과정에서 발생할 수 있는 장애와 지연에 대응하기 위한 방법들을 학습했다.

외부시스템에 특정 서비스를 요청했을 때 요청에 실패한다고 해도 우리 서비스는 정상적으로 작동해야한다. 무한 응답 대기 상태가 되지 않기 위해서는 Circuit Breaker, Timeout & Retry, Fallback 처리를 잘 해놓아야 한다. 재시도 횟수를 몇 번 해야 적절한 지, 응답을 얼마나 기다려야 되는지 등등 트래픽이 많은 회사의 실무에서 할 수 있는 고민들과 경험을 듣는 것들이 재밌었던 주차였던 것 같다.

 

7주차 - Decoupling with Event

7주차에서는 Order 로직에 들어가있던 많은 기능(주문 등록, 상품 재고 차감, 할인 처리, 결제 처리, 데이터 플랫폼에 주문 정보 전송)들을 분리해보았다. 이러한 많은 기능들이 하나의 트랜잭션에서 이루어 진다면, 특정 단계에서 실패했을 때 전체가 롤백되므로 재시도가 불가능하다. 핵심 트랜잭션과 후속 트랜잭션으로 나눠서, 꼭! 지금 해야 하는 것들과 부가적인 비즈니스의 트랜잭션을 나눠보았다.

자연스럽게 결합도가 감소되고 장애 격리가 가능해졌다.

 

8주차 - Hello, Kafka!

카프카에 대해 처음 배웠다. 사실 카프카 주차에서 부터 모르는 지식을 한번에 받아들이려니 너무 힘들었고 살짝 포기하고싶었다.

Kafka를 통해 기존에 내부에서 처리하던 이벤트를 외부로 발행하고 별도의 Consumer 앱이 후속 처리를 담당하는 구조를 학습했다.

commerce-streamer 앱을 별도로 만들어서, 두개의 애플리케이션을 실행시킨 후 Producer의 발행과 Consumer의 소비를 통해 이벤트를 주고받는 것을 확인할 수 있었다. 어찌저찌 활용은 하였지만 Kafka에 대한 더 많은 공부가 필요할 것 같다.

 

9주차 - What is Popularity?

Redis의 ZSET을 활용해서 실시간 랭킹 기능을 구현하였다. 

 

 

10주차 - Collect, Stack, Zip

 

구현하기도 부족한 시간이었어서 마지막 후기를 작성할지 말지 고민하였는데 스스로 10주 간의 과정을 정리하며 돌아보니 개념 정리가 확실히 되고 내가 어떤 것들을 했었는지 돌아볼 수 있어서 작성하길 잘한 것 같다!

위에서 말했듯이, 이러한 새로운 기술이나 개발 방법 등 얻은 것들이 많지만 같은 고민을 하는 많은 사람들과 팀을 이루어서 매일매일 같이 생각하고 고민을 나누고 서로 화이팅 하며 페이스 메이커 역할을 해주었던 것들이 기억에 남는다.

또, 트래픽이 많은 서비스 회사에 재직하지 않는 이상은 알 수 없을 실무 관점의 이야기들을 많이해주셔서 좋았다. 

아직 리팩토링도 해야하고, 테스트 코드도 마저 작성해야 하고, 레디스 캐시나 카프카 등 얕게 공부한 지식들에 더 딥다이브 해야 하는 숙제들이 남았다. 교육은 끝났지만 이러한 학습 패턴과 고민하는 습관을 계속 가져가야겠다고 다짐하며 .... 끝!