2024년, 어떤 걸 보여주고 싶었을까
전년에 “동작하는 서비스”를 만들었다면, 올해는 “잘 굴러가는 구조”를 만들고 싶었다. 그리고 기술만큼이나 나 자신을 이해하고 싶었다. 부족함은 느끼는데 무엇을 채워야 할지 가늠이 안 될 때, “잘하는 사람일수록 잘게 나눈다”는 말에 기대어 나를 세세하게 뜯어본 해였다.
무엇을 했을까 - 개발 요소
한 해의 앞머리는 분산 추적 시스템을 정리하는 데 썼다. 전년의 Zipkin에서 Elastic APM + Logstash + Kibana로 옮기며, 서비스 사이의 호출 관계를 한눈에 보게 만들었다. traceparent 헤더가 충돌해 trace id가 변형되는 문제와, 게이트웨이-서비스 간 부모-자식 관계가 Service Map에 제대로 그려지지 않는 문제를 트러블슈팅했다.
- 무중단 배포: Eureka 기반 배포를 AWS ECS Service Discovery로 전환
- 포인트 정산: 별도 집계 테이블 + 일 단위 배치, 최종 일관성 채택
- 보안: 게이트웨이 HMAC 인증과 Nonce 기반 재전송 공격 방지
- 정렬 API 개선(Spring Data
Pageable, 로직 약 20줄 감소), 소비자 계약 패턴 적용 - 업무 외: Fixture Monkey(NAVER) 오픈소스 PR(#929, #967), 헥사고날·DDD 팀 스터디, 『Tidy First?』 정독과 구름 COMMIT 켄트 벡 세션 참석
좋은 경험이었던 일
포인트 정산 시스템을 설계한 일이 가장 기억에 남는다. 요구사항은 두 가지였다. 빠른 정산 내역 조회를 제공하는 것, 그리고 데이터를 정확히 동기화하는 것.
먼저 데이터 모델을 나눴다. 기존 모델을 바꾸는 대신, 사용 이력과 정산 이력을 분리하고 별도의 정산 테이블을 새로 뒀다.
조회 성능은 배치로 확보했다. 몇 백만 건의 데이터를 매번 집계하는 대신, 일 단위로 미리 집계해 두는 배치를 뒀다.
동기화는 날짜를 기준으로 맞췄다. 0.01%의 오차를 허용하되, 최종적으로는 값이 수렴하도록 설계했다. “더 이상의 검증이 필요하지 않으냐”는 의문이 들 수 있지만, 나는 최종 일관성을 지키고 있다고 말할 수 있었다. 이 과정에서 “아키텍처를 단순하게 만들 수 있다면 더 많은 메모리를 투입할 가치가 충분하다”는 판단 기준이 생겼다. 무엇보다, 성능을 직접 확인하기 전에 어느 정도 결과를 유추할 수 있게 된 게 가장 큰 변화였다.
아쉬웠던 일
기능은 완수했지만, 팀이 더 원활하게 일할 방법까지는 찾지 못한 게 계속 아쉬웠다. 보안 강화도 정산도 “내 업무를 끝냈다”는 느낌은 났지만, 그 과정을 팀의 것으로 남기는 데까지는 이르지 못했다. “하고 싶은 것만 보지 말고 해야 할 일에 집중하자”는 문장을 자주 되뇌었다.
무엇을 했을까 - 비개발 요소
면접 스터디를 하며 『질문하는 힘』을 읽었다. 질문이 답을 만들고, 정보를 얻고, 상대를 여는 도구라는 걸 배웠다. 앞으로 변경 가능성이 있으면 유연하게, 그렇지 않으면 관리 포인트를 줄이는 쪽으로 선택하는 기준도 이때 정리됐다.
프로세스를 그림으로 정리하는 습관도 붙었다. 사이드 프로젝트의 쿠폰 교체 흐름을 액티비티 다이어그램으로 그려, 동시성 제어가 정말 필요한 지점인지 판단했다.
“닭 잡는 데 소 잡는 칼을 쓰지 말자”는 경계도 여기서 나왔다. 이런 판단은 프로세스가 정리된 위에서만 할 수 있다는 걸 알았다.
2024년, 터닝 포인트
| 구분 | Before | After |
|---|---|---|
| 성능 | 돌려봐야 아는 것 | 어느 정도 유추할 수 있는 것 |
| 코드 수정 | 방대한 코드가 두려움 | 단위 테스트가 준 자신감 |
| 설계 | 완벽하게 한 번에 | 지나갈 만큼만 정리하는 리듬 |
방대한 코드를 겁 없이 고칠 수 있게 해준 건 결국 단위 테스트였다. Fixture Monkey에 오픈소스 PR을 올릴 때도, 메인테이너와 함께 문제를 풀어나가는 자신감의 바탕은 테스트였다. 『Tidy First?』를 읽고 나서는 “동작 변경 사이사이에 구조 변경을 끼우는” 리듬을 실무(엑셀 생성 로직 일원화)에 적용했다. 한 번의 구조 변경에 오랜 시간을 쏟는 대신, 누군가 쉽게 지나갈 수 있을 만큼만 정리하기로 했다.
2024년, 나 자신을 이해한 해
StrengthsFinder로 강점을 잘게 쪼개 봤다. 전략, 공감, 성취, 책임, 긍정. 특히 “책임”이 내 중심이라는 걸 알았는데, 빛이 밝을수록 그림자가 선명하듯 그 강점은 강박이라는 그늘도 함께 데려왔다. 너무 많은 업무를 떠안다 지치는 패턴이 보였고, 그래서 “거절도 책임”이라는 경계선을 처음으로 그어봤다.
강점이 서로 부딪히지 않고 보완할 때 개인의 성과가 팀의 성과로 이어진다는 것도 이때 알았다. 부족함을 느끼면서도 무엇을 채워야 할지 몰랐던 이유는, 나를 충분히 잘게 나눠 보지 않았기 때문이었다.
2025년의 목표
- 오버엔지니어링을 경계한다. 닭 잡는 데 소 잡는 칼을 쓰지 않는다.
- 퀄리티를 포기하지 않아도 되는 여유는 30분 채 안 되는 짧은 시간에서 나온다. 그 시간을 의도적으로 만든다.
- 강점을 알았으니, 개인의 성과를 팀의 성과로 잇는다.