2023년 연간 회고

2023년, 어떤 걸 보여주고 싶었을까

신입으로 들어와 처음으로 하나의 서비스를 온전히 맡은 해였다. 잘 해내고 싶다기보다, 내가 만든 게 누군가에게 실제로 쓸모 있었으면 했다. “열심히 만들었는데 가치가 없는 건 정말 슬픈 일”이라는 마음으로 한 해를 보냈다.

동시에 부끄러운 습관도 마주했다. “성능이 좋아진다”, “효율이 좋아진다”는 말을 왜 좋아지는지도 모른 채 습관적으로 내뱉고 있었다. 그래서 2023년은, 말이 아니라 근거로 증명하는 사람이 되고 싶었던 해였다.

무엇을 했을까 - 개발 요소

9월부터 12월까지 팀업 회원 백업 서비스를 런칭부터 운영까지 책임졌다. 수만 명의 회원 데이터를 조회하고 압축해 전달하는 배치 서비스였고, 한 서비스의 생애주기를 처음부터 끝까지 겪었다.

• 팀업 회원 백업 서비스: 데이터 조회 · 압축 · 전달까지의 배치 파이프라인 구현과 성능 튜닝
• fly-away-thumbnail: 프론트엔드 팀의 이미지 관리 부담을 덜기 위해 Spring Cloud Gateway로 만든 리사이즈 CDN. AWS Lambda 방식은 기능 확장에 유연하지 않아 배제했다
• 모니터링: Zipkin으로 시작해 ElasticSearch + Kibana로 옮기며 분산 추적 기반을 마련
• 업무 외: 스프링 배치 문서를 학습해 팀에 공유, 『이펙티브 소프트웨어 테스팅』·『대규모 시스템 설계 기초』 정독

좋은 경험이었던 일

백업 서비스의 성능 개선이 가장 기억에 남는다. 문제는 특정 회원의 데이터가 방대할 때였다. 그룹 단위로 조회할 때마다 풀 테이블 스캔이 그룹 수만큼 반복됐고, 최악의 경우 한 요청이 30초씩 대기했다.

처음엔 “풀 테이블 스캔이 문제니 조회 횟수를 줄이자”에 매달렸다. 그룹마다 조회하는 대신 사용자 전체 데이터를 한 번에 추출한 뒤 애플리케이션에서 그루핑하도록 바꿨다. 그런데 오히려 더 느려졌다. 순차 처리로 CPU가 DB 응답만 기다렸고, 유동적인 실행 계획과 Using where를 남발하는 쿼리가 겹쳤기 때문이다.

방향을 바꿔, 회피가 아니라 활용 가능한 인덱스를 기준으로 쿼리를 다시 짰다. 페이징 단위도 조정했다. 12,000건을 한 번에 조회하면 3초 timeout이 났기 때문에 1,000건 단위로 낮추고, 페이지 크기를 환경변수로 조절할 수 있게 뒀다. 폴더 단위로 저장하던 데이터는 Redis에 모아 압축해 파일 I/O를 1/3로 줄였다.

결과적으로 그룹 조회 한 건이 최소 2초에서 0.2초로, 단일 회원 백업 처리 시간이 30분에서 7분으로 줄었다.

측정 대상: 팀업 백업 서비스, 단일 회원 백업 처리 계산: (after - before) / before * 100

단계별로 보면 뒤로 갈수록 AS-IS와 TO-BE의 격차가 벌어졌다. 흥미로운 건 Redis 압축의 효과가 기대만큼 드라마틱하지 않았다는 점이다. 병목의 대부분은 파일 I/O가 아니라 DB 접근 횟수였다. “속도를 빠르게 하려면 비율이 가장 높은 작업부터 빠르게 해결해야 한다”는 걸 그제야 몸으로 이해했다.

아쉬웠던 일

운영에서 OOM을 만난 일이다. 단일 요청이 힙을 2.3GB나 썼다. 데이터가 소실되지는 않았지만, 물리 메모리를 80%까지 쓰는 상황이었다. 우선 JVM 힙을 임시 증설해 막았다.

문제는 대응이 아니라 예방이었다. 최대 데이터량도, 평균 실행 시간도, 하루 총 실행량도 미리 재두지 않았다. 그래서 문제를 예측하지 못하고 터진 뒤에야 만났다. 데이터로 예산(리소스)을 먼저 산정했어야 했다는 걸 이때 배웠다.

무엇을 했을까 - 비개발 요소

대학 수업과 개인 공부를 병행하며 운영체제를 제대로 들여다봤고, 코딩 테스트도 꾸준히 풀었다. 인문학 책을 읽는 빈도가 늘면서 사고가 조금 유연해졌다.

QA 팀과 처음 협업하며 배운 것도 컸다. 기획 의도가 바뀔 때 그게 모두에게 전해지지 않으면 얼마나 큰 혼란이 생기는지 몸으로 겪었다. QA는 기획서를 기준으로 테스트하기 때문에, 의도 변경은 반드시 모든 참여자에게 전달돼야 했다. 신입인 내 의견도 경청해 주는 문화가 고마웠다.

2023년, 터닝 포인트

솔직히 처음에는 성능 개선이 왜 실패하는지조차 판단하기 어려웠다. 쿼리 실행 계획을 들여다보고 최악의 시간 복잡도를 계산하고 나서야, 무엇을 빠르게 해야 하는지가 비로소 보였다. 성능 개선은 결국 “지금 남는 리소스가 무엇이냐”를 두고 하는 트레이드오프였다.

2023년, 나 자신을 이해한 해

나는 성능과 테스트 앞에서 유독 눈이 반짝인다는 걸 알았다. 문제에 정답이 없고, 상황을 근거로 가설을 세워 증명하는 일이 재밌었다.

자유로움에 이끌려 개발자를 선택했지만, 개발자도 결국 회사원이더라. 사람과 사람 사이에서 약속된 무언가를 하는 일이었다. 그럼에도 이 일을 계속하고 싶은 이유는, 그냥 좋아지길 바라는 게 아니라 좋아지도록 직접 바꿀 수 있는 자리이기 때문이다.

2024년의 목표

• 동작하는 서비스를 넘어 구조를 다룬다. 헥사고날 아키텍처와 모니터링을 제대로 세운다.
• 요구사항을 먼저 질문으로 좁힌 뒤 구현한다.
• 인간 관계와 인문학 책을 꾸준히 읽는다.