제 1회 게으른 개발자 컨퍼런스 다녀온 후기

게으른 개발자 컨퍼런스

 

데브코스 멘토님을 통해 알게된 컨퍼런스로 주니어 백엔드 개발자 대상이라 한 번 신청해보았다. 100명 랜덤 추첨이었고 이런 운은 없는 편이라 기대도 안했다. 그런데 메일을 열어보니, 우와! 선정되었다! 주변에 선정되신 분이 딱 한 분이었고 함께 듣기로 했다. 

 

 

들었던 세션은 분산 트랜잭션 : 과거와 현재, 소비자 관점의 API 설계 패턴, JPA Patterns, 신규 서비스 개발기, 2년차 주니어 개발자의 성능 개선 도전기 순이다.

 

내 첫 컨퍼런스였기에 꽤 설레는 마음으로 컨퍼런스로 향했다.

분산 트랜잭션 : 과거와 현재

분산 시스템과 분산 서비스가 왜 등장했는지부터 시작해서 분산 트랜잭션의 발전 과정에 대한 내용이었다. 2PC, TCC, SAGA, SAGA + outbox 순으로 발전해왔고 각 기술의 특징과 장점 및 단점을 알 수 있었다. MSA도 제대로 모르는데 분산 트랜잭션에 대한 세션을 들으려고 하니 굉장히 어려웠다. 그래서 키워드만 가져가자는 생각으로 경청했다.

 

SAGA의 단점으로 이벤트의 순서를 보장할 수 없고 이벤트가 유실될 수 있다는 이야기나 등장했다. 이러한 단점을 극복하기 위해 이벤트를 신뢰성 높은 곳에 잠깐 적재 후 발송한다고 한다. 이때 신뢰성 높은 곳이란 데이터베이스이고 이와 같은 방법을 outbox 패턴이라고 한다.

 

들으면서 이벤트로 알림 서비스와 느슨한 결합 만들기 이 글이 떠올랐다. 글에서 이벤트 유실에 대한 문제를 언급했고 outbox 패턴을 통해 극복할 수 있겠다고 생각했다.

 

소비자 관점의 API 설계 패턴

공급자 관점에서 API를 설계할 시 늦은 커뮤니케이션이 발생하고 그로 인한 리소스와 병목이 생긴다. 따라서 소비자 관점의 API 설계, API First Approach를 통해 해결하자는 내용이었다. 마지막으로 Server Driven UI를 활용한 API 설계에 대해 설명해 주셨다. Server Driven UI는 사용자 경험을 중요시할 경우 사용된다고 한다.

 

프론트와 프로젝트를 진행하면서 API 스펙에 이것 좀 추가해주세요 라는 요청을 많이 받았다. 프로젝트 진행 전 프론트와 함께 유저 스토리, 플로우 차트 그리면서 설계에 대해 많은 이야기를 나눴다. 그럼에도 여전히 많은 요청사항에 따른 변경 비용이 발생했었던 경험이 떠올랐다. 그리고 API 스펙에 대한 커뮤니케이션 비용을 줄일 수 있는 방법론이 있다는 것을 알게된 시간이었다. 

JPA Patterns

도메인 패턴은 데이터베이스에 대한 연결이 복잡하다는 한계가 있다. 따라서 ORM이 등장했고 ORM에는 객체 상태 추적(Unit of Work Pattern), 객체 한번 로드 보장(Identity Map), Lazy Load 패턴이 들어있다. 다만 데이터소스의 발전이 ORM 기술보다 빠르기 때문에 한계가 있다. 따라서 멀티 데이터 소스일 때 일관성 있는 도메인 사용 경험을 가지도록 여러 패턴을 소개해 주셨다. 

 

POJO한 도메인 모델을 구현하고 영속성 지향 레포지토리로 구현함으로써 도메인을 지킬 수 있다. 도메인과 데이터베이스 엔티티를 분리함으로써 더티체킹이 어려워지니 save()를 사용할 수 있다. 헥사고날 아키텍처에 대해 이해하고 들었으면 좋았겠다는 아쉬움이 있다. 

 

신규 서비스 개발기

신규 서비스 개발하면서 잘 못 했던 점 그리고 어떻게 개선해야 하는지에 대해 이야기해 주셨다. 이야기를 통해 사이드 이펙트에 대한 고려를 충분히 해야하며 도메인에 대한 이해도가 높아야 하며 적절한 테스트, 복잡한 구조 지양 등 서비스 개발할 때 주의점을 알았다. 그리고 요구사항에 맞춰 개발을 해내는 것을 넘어 실제 운영하면서 유지보수하는 경험이 중요하다고 말씀해주셨다.

 

멘토님도 새로운 프로젝트보다 기존 프로젝트를 리팩토링, 기능 수정이 더 중요하다고 말씀해주셨는데 세션을 들으면서 다시 한 번 그 중요성을 깨닫게 되었다. 

 2년차 주니어 개발자의 성능 개선 도전기

레거시 프로젝트에 투입되어 성능을 개선한 경험에 대해서 이야기해 주셨다. 대량의 데이터 CRUD는 단건 반복 쿼리를 벌크 쿼리로 변경함으로써 성능 개선을 이뤄냈다고 하셨다. 그리고 Explain으로 실행 계획을 분석한 뒤 슬로우 쿼리를 제거하셨다. 마지막으로 대용량 엑셀 다운로드는 서버 분리 후 비동기 방식으로 처리했고 CompletableFuture를 통한 병렬 처리로 성능 개선을 이뤄내셨다고 한다. 마지막으로 대용량 PDF 다운로드는 AWS 람다를 도입하여 아키텍처 변경을 통해 개선했다고 하셨다.

 

사이드 프로젝트에 적용해 볼만한 경험들을 이야기 해주셔서 좋았다.  그리고 모니터링을 통해 병목을 찾아내는 것을 보고 직접 모니터링 툴을 프로젝트에 연결해봐야 겠다고 결심했다.