엔지니어로서의 성장, 배움의 순간, 그리고 커리어 전환점들을 기록한 타임라인입니다.
지금까지의 프로젝트들 — Kafka 클러스터 운영, Airflow 기반 파이프라인, CI/CD 인프라 — 을 돌아보면 공통점이 하나 있었다. 항상 "데이터가 어떻게 흐르고, 어디서 막히고, 왜 막히는지"를 가장 오래 들여다보고 있었다는 것. 이 포트폴리오를 처음부터 다시 정리하는 과정 자체가, 흩어져 있던 프로젝트들에서 그 공통점을 발견하고 Data Platform Engineer라는 방향으로 스스로를 재정의하는 작업이었다.
경찰청 자율주행 순찰차 V2X 데이터 연동 프로젝트에 Senior Backend Engineer로 참여했다. Kafka를 데이터 백본으로 채택한 이유는 재생 기능과 멀티 컨슈머 독립 구독이 필요했기 때문이었고, 결과적으로 메시지 크기를 60% 줄이면서 100ms 지연 요건을 충족시켰다. 개인 프로젝트에서는 지표를 스스로 정하고 스스로 만족하면 끝이었는데, 정부 프로젝트에서는 요건이 먼저 있고 그 요건을 충족하는지 숫자로 증명해야 했다. 판단의 기준이 "내가 만족하는가"에서 "요건을 만족시키는가"로 바뀐 경험이었다.
시공관리 종합 솔루션 프로젝트에서 GitLab CI/CD를 구축하며 develop→dev, master→prod로 브랜치와 배포 대상을 명확히 매핑했다. 이전까지는 개발/운영 배포가 명확히 분리돼 있지 않아 사고 위험을 안고 있었는데, 브랜치 전략을 인프라 설계의 일부로 다루고 나서야 배포가 "각자 알아서 조심하는 일"에서 "구조적으로 안전한 일"로 바뀌었다.
인수인계 없이 넘겨받은 아동 행동패턴 연구 앱(PLEY)의 코드베이스를 처음 열었을 때는 단순 유지보수 건인 줄 알았다. 웨어러블 토큰 갱신이 왜 자꾸 끊기는지 로그를 따라가다 보니, 문제는 코드 품질이 아니라 "이 기능을 어느 계층에 배치했는가"라는 아키텍처 설계 자체에 있었다. 클라이언트가 활성 상태일 때만 갱신되던 토큰 로직을 서버사이드 스케줄러로 옮기고 나서야, 데이터 수집 성공률이 0%에서 90%로 올라갔다. 그 이후로 레거시를 마주치면 증상부터 고치려 하지 않고, 그 기능이 왜 그 계층에 놓였는지부터 묻는 습관이 생겼다.
Producer/Consumer가 늘어나면서 관리형 Kafka(AWS MSK)의 비용이 감당하기 어려운 수준으로 올라갔다. 결국 온프레미스로 Kafka 클러스터를 직접 구축·운영하는 쪽을 선택했는데, 이 결정은 단순히 비용 문제가 아니라 "우리가 이 인프라를 직접 책임질 준비가 됐는가"를 스스로 확인하는 과정이었다. 이후 파이프라인 설계에서도 Lambda 대신 Kappa 아키텍처를 택해 배치·스트림 처리를 이원화하지 않기로 했는데, 두 결정 모두 복잡도를 늘리지 않는 방향을 우선한 선택이었다.