2026년 4월 ~ 2026년 6월
들어가며
지난 분기가 새로운 환경에 적응하며 이해해나가는 시기였다면, 이번 분기는 온전히 한 사람의 몫을 해낼 수 있도록 노력한 시기였다.
특히 두 번에 걸쳐 배우자 출산휴가를 사용하면서 팀에 피해를 주지 않고 내가 있어야 할 이유를 증명하고자 하기도 했다.
지난 글 말미에 "코드를 잘 짜는 것만큼 무엇을 왜 만드는지 아는 것이 중요해질 것"이라고 적었었다.
이번 분기를 돌아보니 그 방향으로 조금은 나아간 것 같다.
단순히 기능을 만드는 데서 그치지 않고, 왜 저장소를 바꿔야 하는지, 왜 같은 버그가 반복되는지, 왜 이 기능을 만들어야 하는지 고민하곤 했다.
이번에도 몇 가지 기억해둘 만한 일을 정리해보았다.
1. 전체 카메라 이벤트 리스트
배경
현장에 설치된 모든 카메라의 이벤트를 확인할 수 있는 화면이 필요했다.
기존에는 개별 현장에 대해 조회가 가능했지만, 모든 현장의 이력을 한 곳에서 보고 CSV로 내려받는 기능은 없었다.
문제
조회 이외에 간단한 몇 가지 기능이 추가로 요구되어 도메인을 새로 설계해야 했고 데이터 조회량도 상당했다.
특히나 Couchbase에 쌓인 이벤트를 N1QL로 조회하니 다건 조회에서 성능이 현저하게 떨어지는 문제가 있었다.
접근 방식
헥사고날 아키텍처 경계를 지키며 도메인을 여러 단계로 나눠 점진적으로 확장했다.
특히나 조회 성능 문제는 처음엔 Couchbase 안에서 N1QL을 KV 조회로 바꿔 대응했지만, 만족할 만큼 향상시키진 못했다.
결국 Elasticsearch와 Couchbase를 조합하여 결과를 만들도록 구성하였다.
결과
3주 남짓의 작업 끝에 전체 이력을 조회하고, CSV 다운로드까지 안정적으로 수행할 수 있었다.
회고
처음부터 데이터의 위치를 면밀히 확인하고 시작했다면 곧바로 ES를 활용했을 텐데, 이 부분을 분명하게 하지 않다 보니 데이터 소스 전환 비용이 발생했다.
다행인 점은 아키텍처를 준수하며 수행하다 보니, 데이터 소스를 갈아끼우는 작업은 오래 걸리지 않았단 점이다.
2. 집계 API 최적화
배경
협력사에게 제공되는 화면에서 쓰이는 집계 API가, 집계 대상 데이터가 늘어나며 응답이 점점 느려지고 있었다.
문제
하나의 요청을 처리하는 동안 같은 데이터를 여러 차례 반복 조회하고 있었고, Elasticsearch와 Couchbase 쿼리도 따로따로 반복적으로 호출되고 있었다.
병목의 실체는 복잡한 로직이 아니라, 단순한 조회를 필요 이상으로 반복 수행하는 것이었다.
접근 방식
먼저 한꺼번에 조회할 수 있는 쿼리는 통합하여 조회 횟수를 절반으로 줄였다.
그다음 반복 조회되던 데이터는 캐시를 적용해 한 번만 DB에 다녀와도 되도록 개선하였다.
캐시 TTL은 데이터 특성에 맞춰 짧게(60초) 잡아 캐시에 오래된 데이터가 남아 발생하는 불편을 최소화하였다.
결과
병목 구간의 조회 횟수를 10분의 1 수준으로 줄였고, 실제로 조회 시간은 약 30초에서 1초 내외로 크게 개선되었다.
회고
사실 문제 자체는 크게 어려운 것은 아니었다.
결국 시스템 개선은 '문제를 식별하는 단계'에서 시작하는 것이라는 걸 다시금 느꼈다.
3. update-kb 스킬과 CLAUDE.md 문서 카탈로그
배경
AI 에이전트가 업무의 영역으로 깊이 들어오고 있다는 걸 느낀다.
어느 날 문득, 내가 수행한 작업을 정리하는 일은 나보다 클로드가 더 내 맘에 들게 해낼 수 있겠다는 생각이 들었다.
접근 방식
작업 완료 시점에 KnowledgeBase를 갱신하는 update-kb 스킬을 만들었다.
실행하고 프롬프트를 수정하고, /clear하는 작업을 만족할 만한 결과를 얻을 때까지 반복하였다.
결과
그 이후 업무를 진행하며 실제로 여러 차례 사용해보았고, 정리된 KB 문서를 Git 리포지토리에 공유하였다.
이후 클로드를 이용해 업무를 수행할 때, 정리된 KB 문서를 참조하며 더 정확하게 작업을 수행하는 것을 볼 수 있었다.
회고
사실 기능을 구현하는 것보다 테스트를 작성하고 문서화를 하는 것이 더 어렵게 느껴지고 오래 걸리는 경우가 많다.
문서화 비용을 낮추며 그 시간을 기능 구현에 더 투자할 수 있게 되었다.
4. ELK + Kafka 중앙 로그 수집 구축
배경
늦은 감은 있지만 한 곳에서 로그를 조회할 수 있도록 ELK를 구성하였다.
문제
Tomcat 로그, syslog, 서버마다 제각각인 JSON 형식 로그 등 다양한 서버 유형에 맞는 로그 수집 방식을 구성해야 했다.
접근 방식
표준 설정을 만들고, 서버 유형별로 필요한 패턴과 필드 매핑을 하나씩 늘려갔다.
약 50여 대의 서버였고, 유사한 유형을 묶어 나흘 동안 순차적으로 설치, 배포하였다.
일부 서버는 기존에 Beats를 구동하고 있던 것이 확인되어 Beats 업데이트 및 설정 마이그레이션을 수행했다.
결과
배포 완료 이후 APM과 연동하여 오류 추적을 더 효율적으로 할 수 있게 되었다.
사실 ELK는 가장 기본이 되는 작업이었고, 이후 n8n 등을 활용해 전일자 오류 리포트를 작성하거나 실시간 이상 로그를 탐지하는 등, 서비스 모니터링을 더 효율적이고 효과적으로 할 수 있도록 확장하게 되었다.
회고
전체적으로 어떤 서버가 있고, 어떤 역할을 하는지 막연하게만 알고 있었지만, 하나하나 직접 접속하고 로그를 확인하며 더 명확하게 알 수 있게 되었다.
구축 이후 실제로 이 기능을 활용해 오류를 잡아낸 적도 있어서, 내가 한 일의 효용을 직접 느낄 수 있었다.
마무리
이번 분기는 밀도가 높았다.
지금 맡은 서비스에도 점점 익숙해지고, 기여할 수 있도록 제안을 하기도 했다.
그 사이사이 원인을 알 수 없던 문제를 정량적으로 설명해내는 조사도 있었고, 개별 작업만 볼 땐 안 보이던 패턴을 기억을 더듬는 과정에서 발견하기도 했다.
돌아보면 반복되는 교훈이 하나 있다.
처음에 명확히 정리하지 않고 허겁지겁 시작한 일은, 나중에 꼭 한 번은 되돌아와 다시 손보게 됐다.
반대로, 무엇을 왜 하지 않기로 했는지를 명확히 남겨둔 결정들은 후회가 없었다.
업계가 많이 어렵다.
내가 있었던 회사도, 인근 업체도, 또 건너건너 알게 되는 곳도 어렵다는 이야기만 들려온다.
단순히 AI 때문이라거나 고질적인 취업난 때문이라고, 쉽게 단정할 수는 없을 것 같다.
기본에 충실하고 책임감 있게 또 한 분기를 보내야겠다.
다음 분기엔 내 주변의 변화도 조금은 잦아들고, 불안감도 해소가 되었으면 한다.