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

배경

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

역할

운영 쿼리를 모아 실행 계획과 인덱스 사용 여부를 확인했습니다. 미사용 인덱스와 레거시 테이블을 추린 뒤 SQL을 손봤고, 실제 삭제 범위와 적용 순서는 팀 리뷰를 거쳐 확정했습니다.

핵심 작업

• 실제 사용되는 쿼리 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월 파일 단위 동기화의 한계를 제기하며 CDC 구조 전환을 제안했고, 2026년 1분기에 설계·구현과 배포 시나리오 리뷰를 마친 뒤 기술지원팀에 이관했습니다. 이후 운영에서 접수된 이슈를 재현·개선하고 있습니다.

핵심 작업

• 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배. 데이터가 클수록 격차 확대

배경

MySQL과 수집·배포 서비스가 AWS EC2에서 직접 운영되면서 클라우드 비용 부담이 누적됐습니다. 자원을 직접 통제하기도 어려운 구조였습니다.

역할

데이터 이송과 검증을 맡고 자체 환경에 DB primary/replica, 수집 서버, 모니터링을 다시 구성했습니다. 전환 뒤에는 네트워크와 백업·복원 경로를 확인하고 이전 대상 AWS 인스턴스를 종료했습니다.

핵심 작업

• 이송 — EC2의 DB 데이터를 자체 서버로 이전
• 검증 — 백업·복원과 데이터 정합성 확인 후 전환
• 재구성 — DB primary/replica·수집·모니터링을 자체 환경에 구축
• 전환·종료 — 운영(prod) DB용 EC2만 AWS에 남기고 다른 EC2 인스턴스 정리

결과

• 비용 절감 — 운영 DB용 EC2 외 인스턴스 정리로 월 AWS 비용 약 94% 절감
• 운영 통제권 — 데이터 인프라를 자체 환경에서 직접 운영·통제할 수 있는 구조로 전환
• 안전 전환 — 대용량 데이터를 정합성 검증 후 무손실로 이전

배경

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

역할

데이터 동기화 체계의 설계·구현과 배포 시나리오 리뷰까지 맡아 기술지원팀에 이관했습니다. 고객사 배포와 상시 운영은 기술지원팀이 담당하고, 저는 운영 중 전달받은 이슈를 재현하고 코드를 개선하는 최종 기술지원을 맡았습니다.

핵심 작업

• 환경별 배포 시나리오 설계·리뷰 — 기본·파일 검수·시간 제한·폐쇄망·중계 경로 구성을 나눠 기술지원팀에 이관
• 배포 형상 기준 정리 — 고객사별 DB 백업본과 동기화 모듈·프록시 버전을 비교할 수 있도록 관리 기준을 정리
• 최종 기술지원 — 기술지원팀에서 전달받은 DB·동기화·정합성·네트워크 이슈를 시스템 담당자로서 재현·개선
• 지원 표준화 — 설치 가이드·배포 시나리오·신규 고객사 등록 절차를 문서화

결과

• 배포 지원 — 기술지원팀이 같은 기준으로 배포·운영할 수 있도록 시나리오와 검증 기준을 제공
• 이슈 개선 — 운영 중 접수된 복합 문제를 재현하고 코드 개선으로 연결
• 현안 추적 — 고객사별 환경 차이와 오류 유형을 문서·이슈로 남겨 재처리와 패치 검증까지 연결
• 표준화·온보딩 — 가이드·시나리오·등록 절차로 지원 품질과 인수인계를 보강