2026년 7월 ~ 2026년 9월
들어가며
입사한 지 1년이 되었다.
여전히 나는 한 사람의 몫을 해내고 있는지 돌아보며 반성하고 있다.
이번 분기에는 기술적인 고민을 더 하게 되었다.
그리고 개인적인 역할에 대해서도 고민한다.
이번에도 기억해둘 만한 일을 정리해보았다.
1. DB 저장소 이관
배경
서비스의 대부분의 데이터가 구버전 NoSQL DB에 쌓이면서 조회 지연과 메모리 한계가 나타나기 시작했다.
이에 관계형 데이터는 RDBMS로, 누적되는 로그성 데이터는 새로운 NoSQL DB 옮기는 장기 계획을 세웠다.
첫 단계로는 이벤트 데이터 이관을 진행하였다.
문제
서비스를 멈추지 않고 옮겨야 했다.
혹자는 이러한 과정을 '달리고 있는 기차의 바퀴를 교체하는 일'이라고 표현했다.
새로운 이벤트는 쉬지 않고 들어오고, 이미 쌓인 과거 데이터는 수억 건의 볼륨이었다.
접근 방식
먼저 스키마를 설계했다.
새로운 NoSQL DB는 스키마에 대해 엄격하였다. 기존에 사용하던 DB와는 다르게 동적인 스키마를 허용하지 않았다.
이벤트의 날짜를 기준으로 파티션을 묶고, 데이터 보존 기간을 기준으로 TTL을 설정하였다.
추후 운영을 위한 모니터링도 신경 썼다.
Prometheus와 Grafana로 모니터링 체계를 갖춘 다음, 데이터 이관 기간에는 새 저장소에도 함께 쓰도록 구성하였다.
과거 데이터는 별도 이관 도구로 백필(back-fill)을 진행하였다.
결과
수억 건의 데이터를 7시간가량에 걸쳐 이관하였다.
이후 서비스에서 점진적으로 신규 DB에서 조회하도록 이관되었으며, 사용자들은 속도 개선 외에 체감하는 변화는 없었다.
회고
단계를 잘게 나누고, 단계마다 무엇을 확인해야 하는지 체크리스트를 미리 작성하고 진행하는 것이 크게 도움이 되었다.
내가 익숙하지 않은 작업이다 보니 작업 중 문제를 겪는 일이 많았는데, 그 체크리스트가 길을 잃지 않고 되돌아올 수 있게 해 준 이정표였다.
아쉬운 점도 있다.
작업의 속도에 신경을 쓰다 보니 서비스 레벨에서 어느 정도의 영향을 받을지를 제대로 평가하지 않고 작업 기간을 책정하였다.
이에 예상보다 작업이 훨씬 늦게 완료되었다.
작업 착수 전 얼렁뚱땅 넘어가지 말고 충분히 영향도 평가를 하고 시작하는 것이 중요하겠다.
내부에서만 아는 작업이라도 납기일 준수는 중요하니까.
2. 이벤트 보정
배경
모든 이벤트가 완벽하게 정확히 발생하여 서버까지 들어오면 좋겠지만 우리가 사는 세상은 그렇지 않다.
잘못 발생하거나 누락된 이벤트가 만든 틈새를 메워야 할 필요가 생겼다.
문제
잘못 채우면 오히려 오발생 이벤트와 보정 이벤트가 중복될 수 있다.
실시간으로 이벤트 누락을 탐지하는 방법을 검토했지만, 모든 이벤트의 순서가 보장될 수는 없었다.
이벤트 스트림의 파티션 문제도 있고, 드물게 네트워크 사정으로 서버까지 늦게 도착하는 이벤트가 있을 수도 있었다.
접근 방식
이벤트를 발생시키는 단말들끼리의 구조를 그래프로 정의하였다.
배치가 1분마다 같은 ID의 연속된 이벤트 사이에서 빠진 구간을 찾고, 그래프의 경로로 어느 구간이 누락되었는지 찾도록 하였다.
누락 구간에 비슷한 ID나 인식 실패 이벤트가 있으면, 보정한 이벤트가 이미 들어온 이벤트와 중복될 수 있으니 보정하지 않도록 했다.
결과
아직까지는 테스트 기간이지만 크게 문제는 없는 것 같다.
회고
사실 설명하면 복잡하지만 로직 자체는 그렇게 어렵지가 않았다.
하지만 이 작업이 인상 깊었던 건 학부에서 배웠을 몇 가지 알고리즘이 직접적으로 사용되었기 때문이다.
노드들 사이의 관계를 표현한 그래프 개념이 있었고, 유사한 ID를 판단하기 위해 레벤슈타인 거리 알고리즘을 적용하였다.
물론 현장에서는 더 정밀하게 판단하기 위해 추가로 작업을 하도록 했지만 흥미로웠다.
서비스 개발을 하면서 느낄 수 있는 즐거움이었다.
3. 해외 업체와의 커뮤니케이션
배경
해외 업체가 우리 시스템을 사용할 수 있도록 API를 열어주는 작업을 진행했다.
고민
이건 기술적인 고민은 아니었다.
해당 업체에 메일을 띄우기 위해 영어 서명을 적용하였는데 내 이름 옆에 Senior라는 직위가 적혀 있었다.
업무를 시니어라는 이름에 맞게 하고 있는지 되돌아봤다.
그리고 내가 생각하고 기대하던 시니어 개발자들의 모습은 어땠는지 떠올려보았다.
회고
사실 아직 고민이 끝나진 않았다.
그냥 일하다 보니 시니어라는 이름을 받은 느낌이다.
시니어라는 말에 걸맞은 모습은 무엇인지 조금 더 생각해보자며 조금 미뤄둔다.
4. AI 도구
배경
개발자들은 어떤 문의가 인입되었을 때 몇 가지 명령어와 도구로 확인을 진행한다.
하지만 운영 담당자, 기획자 등은 그게 쉽지가 않다.
요즘같이 AI 서비스들이 있는 시대라면 그들의 어려움을 조금은 덜 수 있겠다는 기대를 품게 되었다.
고민
지난 분기의 문서화 스킬이 나를 위한 도구였다면, 이번에는 팀을 위한 도구를 만들어보게 되었다.
하지만 막상 만들어서 소개할 단계가 되었을 때, 난 잠시 미루기로 하였다.
내가 미룬이라서는 아니고, 지금의 사용법은 터미널과 CLI를 전제로 하기 때문이다.
사실 비개발자 직군의 동료들에겐 CLI 환경 자체가 또 하나의 낯섦이다.
회고
비개발자가 AI 서비스를 쉽게 쓰게 하려면 어떻게 해야 할까.
CLI가 아닌 사용법은 어떤 모습이어야 할까.
사용하기 쉬운 내부 도구를, 더 간편하게 만들 수 있는 길이 있을까.
사회성 좋은 개발자가 되는 방법을 고민하는 느낌이다.
마무리
내가 가진 불안은 그대로다.
여전히 어려움에 봉착했을 때, 회사가 갖는 기대치를 내가 충족하고 있는지 걱정부터 든다.
다만 기본을 지키기 위해 노력하고는 있다.
'돌아가는 프로그램'보단 '잘 돌아가는 빠릿한 프로그램'을 만들고자 하고, 작업 중 눈에 띈 결함은 고치고 지나간다.
시니어는 노력하는 모습보단 잘하는 모습을 보여야 하려나.