김현욱 대표 기술 포트폴리오

배경

수년간 운영되어 온 중앙 운영 DB는 그동안 누적된 미사용 인덱스와 비효율 쿼리로 인해 저장 용량이 비대해지고 전반적인 성능이 저하된 상태였습니다.

역할

데이터 엔지니어로서 쿼리 수집 → 실행 계획 분석 → 인덱스 정리 → SQL 튜닝의 전 과정을 단독으로 수행했습니다. 운영 중인 중앙 운영 DB를 다루는 만큼, 실제 사용 패턴을 근거로 안전하게 변경 범위를 좁혀가며 진행했습니다.

핵심 작업

• 실제 사용되는 쿼리 95개를 EXPLAIN으로 분석해 전체 인덱스 311개 중 224개(72%)가 실행 계획에서 전혀 쓰이지 않음을 정량적으로 증명
• 불필요 인덱스를 삭제하고 복합 인덱스의 컬럼 순서를 실제 실행 계획에 맞게 재구성
• SQL 튜닝: OR 조건을 UNION으로 전환하고 LIKE 와일드카드 패턴을 인덱스가 타도록 최적화

임팩트

• DB 용량 53.8% 절감 — 2.6TB → 1.2TB
• 초기 설치 시간 절반 — DB 생성 12시간 → 6시간
• 비용 절감 — 저장 자원 축소로 운영 비용에 직접 기여
• 서비스 품질 향상 — 쿼리 효율 개선으로 응답 성능 개선

배경

레거시(v2/v3) Updater는 mysqlbinlog 유틸리티를 파이프로 실행해 binlog를 타겟 DB에 그대로 밀어넣는 단순 리플레이였습니다. SQL을 제어할 수 없으니 중복 키 에러가 나면 수동 개입이 필요했고, DEFINER 절·Virtual Column처럼 고객사 환경에서 깨지는 구문도 거를 수 없었습니다.

역할

2025년 9월 품질 개선 회의에서 Binlog Shipping의 파일 단위 한계를 제기하며 CDC 구조 전환을 제안했고, 2026년 1분기에 설계·구현을 맡아 4월 배포까지 진행했습니다. 비교 검토(Debezium·Maxwell·커스텀)부터 Go Updater의 파싱·변환·상태 관리 설계, SSD/HDD 환경별 v2 대비 성능 측정까지 문서로 남기며 작업했습니다.

핵심 작업

• binlog 직접 파싱 → SQL 변환 엔진을 Go로 구현 — INSERT/UPDATE를 INSERT ... ON DUPLICATE KEY UPDATE(UPSERT)로 변환해 재실행 시에도…
• 타겟 환경에 맞춘 SQL Sanitization — DEFINER 절 제거, GRANT 문 스킵, GENERATED ... VIRTUAL 컬럼은 information_schema 조회로 자…
• 무결성 검증을 MD5에서 SHA256으로 교체 — 서버가 보낸 평문 해시와 클라이언트가 복호화 후 계산한 해시를 대조해 전송 깨짐·키 오류를 즉시 감지
• Smart Polling 프로토콜 설계 — 마지막 수신 해시를 헤더로 보내 변경 없으면 304 Not Modified, 파일 생성 중이면 404 대신 202 Accepted로 "에러"와 "…

임팩트

• 정합성 — 멱등 UPSERT + 이벤트 단위 제어로 중복·누락 없이 재시도 가능, 사실상 exactly-once 적용
• 자동 복구 — 체크포인트 롤백이 내장되어 파일 손상·임포트 실패가 사람 개입 없이 다음 주기에 스스로 복구
• 처리 속도 — binlog 파일당 SSD 평균 96초 → 39초(2.56배), HDD 최대 5배. 데이터가 클수록 격차 확대

배경

데이터 백엔드와 수집 인프라가 AWS(EC2 / EFS 등) 위에서 운영되면서 클라우드 비용 부담이 누적됐습니다. 자원을 직접 통제하기도 어려운 구조였습니다.

역할

데이터 엔지니어 · 인프라 담당으로서 데이터 이송 → 정합성 검증 → 자체 인프라 재구성 → 전환·AWS 종료를 단독으로 수행했습니다. DB primary/replica·수집 서버·모니터링을 자체 환경에 재구성하고 네트워크·백업·복원 체계를 정비해 반복 비용을 줄이면서 데이터 인프라를 직접 통제하는 구조를 만들었습니다.

핵심 작업

• ① 이송S3 경유로 자체 서버에 데이터 적재
• ② 검증인덱스 문서 수 일치 등 정합성 확인
• ③ 재구성DB primary/replica·수집·모니터링 구축
• ④ 전환·종료전환 완료 후 AWS 자원 종료

임팩트

• 비용 절감 — 전환 완료 후 AWS 자원 종료로 반복 과금 중단 (예: AWS K8s 클러스터의 EC2 8대 + EFS 스토리지 과금 중단)
• 운영 통제권 — 데이터 인프라를 자체 환경에서 직접 운영·통제할 수 있는 구조로 전환
• 안전 전환 — 대용량 데이터를 정합성 검증 후 무손실로 이전

배경

제품 데이터는 중앙 운영 DB에서 만들어지고 고객사는 이 데이터를 자사 인프라 안에서 직접 운영해야 합니다. 운영 DB의 replica를 직접 제공·연결하는 방식은 고객사 보안 정책상 허용되기 어려워 고객사 내부에 DB를 두고 초기 백업본 + 바이너리 로그 변경분으로 동기화하는 별도 구조가 필요했습니다.

역할

데이터 엔지니어로서 on-premise DB 백업본과 바이너리 로그 기반 데이터 동기화 체계의 설계·구현·운영을 단독으로 수행했으며 고객사 환경별 배포와 심층 기술지원을 책임졌습니다. 1차 지원은 다른 인원이 맡았지만 시스템을 가장 잘 아는 담당자로서 다른 손에서 풀리지 않는 이슈의 최종 해결자 역할을 수행했습니다. 2026년부터는 데이터 엔지니어링 리드로 전환 작업과 지원 표준화를 함께 이끌었습니다.

핵심 작업

• 환경별 맞춤 설치·구성 — 고객사 환경 제약에 맞춰 데이터 동기화 모듈을 시나리오별(기본·파일 검수·시간 제한·폐쇄망·중계 경로)로 설치·구성
• 설치 형상관리 — 고객사별 DB 백업본 버전 · 동기화 모듈/프록시 버전 · 설치일을 추적해 환경 차이를 체계적으로 관리
• 심층 기술지원 (최종 해결자) — 기술지원팀이나 외주가 1차로 해결하지 못하는 DB · 바이너리 로그 기반 동기화 · 동기화/정합성 · 네트워크 이슈를 시스템 담당자로서 직접 진단·해결
• 고객사 현안 대응 — 업로드/반영 실패, 동기화 지연, TLS·네트워크 오류, 분석 결과 오탐처럼 제품 데이터와 고객사 환경이 만나는 지점의 문제를 로그·DB 상태·배포 형상까지 연결해 추…

임팩트

• 안정적 배포·동작 — 환경이 제각각인 고객사 on-premise에서 DB·동기화 구성의 안정 배포와 동작을 책임
• 끝까지 해결 — 1차 지원에서 풀리지 않는 심층 문제를 시스템 담당자로서 최종적으로 해결
• 현안 추적 — 고객사별 환경 차이와 오류 유형을 문서·이슈로 남겨 재현, 재처리, 패치 검증까지 이어지게 함
• 표준화·온보딩 — 가이드·시나리오·등록 절차 문서화로 지원 품질을 표준화하고 인수인계를 수월하게