박은우

신개념 테마파크 9.81파크를 운영하는 B2C 환경에서 하드웨어 데이터를 주로 다루는 IoT 시스템을 담당했습니다. 운영 데이터 흐름을 정리하고 레거시 시스템의 비용과 확장 한계를 줄이는 구조 개선을 수행했습니다.

• 운영 DB 수작업 분석에 의존하던 구조를 CDC 기반 분석 파이프라인으로 전환
• 레거시 IoT 시스템의 운영 비용과 변경 영향 범위를 줄이는 구조 개선
• 신규 파크와 서비스 확장을 고려한 글로벌 IoT 플랫폼 재설계

B2B 결제플랫폼 뒷단에서 월 평균 백만 건 이상 규모의 정산·대사 시스템을 담당했습니다. 거래·정산·송금 데이터의 기준을 명확히 하고 운영 효율을 높이는 백오피스 개선을 수행했습니다.

• 지급대행 Open API 신규 서비스 구축
• 반기별 영중소 차액정산 자동화
• 백오피스 성능 튜닝과 운영 효율 개선

문제 정의

• 분석 요청이 반복될 때마다 운영 DB를 직접 조회하고 파일을 가공·검증해야 했습니다. 데이터를 뽑는 시간보다 결과를 다시 확인하는 시간이 더 오래 걸렸고, 조건 변경에 따른 재요청도 반복됐습니다.

의사결정

• 문제를 쿼리 작성 업무가 아니라 데이터 흐름 부재로 재정의했습니다. 반복 분석 패턴을 재사용할 수 있도록 Aurora RDB → AWS DMS → S3 → Glue → Athena 기반 구조를 선택했습니다.

구현

• Append-only 방식으로 CDC 데이터를 적재하고 Glue Catalog 기반 스타 스키마를 구성했습니다. Glue 단계의 데이터 품질 검증을 함께 적용해 분석 데이터의 신뢰성과 재사용성을 확보했습니다.

성과

• 분석 리드타임을 1~2시간에서 즉시 조회 가능한 수준으로 단축했습니다. 반복 분석 요청을 Athena 조회 계층으로 옮겨, 개발자가 운영 DB에서 매번 추출하지 않아도 되는 구조로 바꿨습니다.

문제 정의

• 기존 구조는 특정 파크 정책과 기능이 강하게 결합돼 기능 추가 시마다 시스템 전반의 영향 범위를 함께 확인해야 했습니다. 검증 범위가 커지고 확장 시 장애 리스크와 개발 비용이 함께 증가했습니다.

의사결정

• 문제의 본질을 서비스 중심 설계가 아닌 데이터 흐름 중심 설계 부재로 봤습니다. 파일이 많아지는 단기 비용보다 장기적으로 변경 범위를 예측할 수 있는 구조를 우선해 도메인 경계와 Hexagonal Architecture를 채택했습니다.

구현

• 메타데이터·상태·기록·로그·제어의 도메인 경계를 재정의하고 외부 의존성을 분리했습니다. 애플리케이션 간 직접 호출을 줄이며 유스케이스 단위의 버티컬 슬라이스 구조를 도입했습니다.

성과

• 변경 범위를 도메인 단위로 예측할 수 있게 정리했습니다. 신규 파크 대응은 설정 중심으로 확장할 수 있게 만들고, 기존 시스템은 중단 없이 점진적으로 전환하는 방향을 잡았습니다.

전환 전략

• 기존 시스템과의 호환성을 유지하는 점진적 전환 전략으로 도입 리스크를 관리했습니다.

문제 정의

• 많은 알림이 하나의 메신저 채널로 쏟아지는 환경에서 실제 시스템에 영향을 주는 에러를 빠르게 구분하기 어려웠습니다. 에러가 발생할 때마다 Grafana 로그 조회, TraceId 추적, 애플리케이션 역할 확인, 소스 코드 확인이 반복됐습니다.

의사결정

• Grafana 로그 조회, TraceId 추적, 애플리케이션 역할 확인, 소스 코드 확인이 반복되는 흐름을 AI 에이전트가 수행할 수 있는 단위로 분해했습니다.

구현

• 1분 주기로 에러 Trace를 수집하고 애플리케이션명, 오류 메시지, API 경로, 관측 내용, 동일 사건 발생 횟수, 소요 시간, 소스 코드 링크를 바탕으로 긴급도를 분류한 리포트를 생성했습니다.

성과

• 반복 확인하던 로그, TraceId, API 경로, 코드 링크를 하나의 리포트로 묶어 대응 우선순위 판단에 필요한 정보를 줄였습니다.

문제 정의

• 오픈마켓 사업자가 하위 셀러에게 판매 대금을 지급하는 신규 서비스가 필요했습니다. 외부 고객사 연동과 신규 서비스 구축이 동시에 요구돼 초기 설계 단계부터 안정성과 확장성을 함께 고려해야 했습니다.

의사결정

• 거래, 정산, 송금 책임이 혼재되면 기능 확장 시 복잡도가 커질 수 있다고 판단했습니다. 도메인 기준으로 경계를 나누고 명시적 인터페이스로 통신하도록 설계했습니다.

구현

• 기획 단계부터 참여해 핵심 기능 우선 구현 범위를 정리했습니다. 3인 팀 PL로 일정과 우선순위를 관리하며 30개+ 테이블을 재설계하고 지급대행 핵심 API 19개를 개발했습니다.
• JPA, QueryDSL, 테스트 코드 등 개발 표준을 도입하고 팀 내 스터디와 기획·외부 고객사 커뮤니케이션을 주도했습니다.

검증

• 핵심 로직 테스트 100개+와 CI 자동 검증을 도입해 변경 영향 범위를 사전에 확인했습니다.

성과

• 기능 확장과 서비스 성장에 대응할 수 있는 도메인 단위 변경 통제 구조를 확보했습니다. 초기 고객사 연동 구간에서 핵심 거래·정산 흐름이 중단 없이 운영되도록 검증 범위와 변경 통제를 관리했습니다.

문제 정의

• 반기마다 400만 건 이상의 국내 사업자 데이터를 기준으로 영세·중소·일반 사업자 구간을 다시 반영해야 했습니다. 기존에는 정산 담당자가 직접 비교·검증하는 수작업 구조였고, 과거 거래 소급 적용까지 함께 처리해야 해 누락과 정산 오류 리스크가 반복됐습니다.

의사결정

• 문제를 단순 대량 데이터 처리 이슈가 아니라 정책 변경 이력을 시스템이 기억하지 못하는 구조적 문제로 재정의했습니다. 원천 데이터 전체 저장, 반기 스냅샷, 가맹점별 구간 변경 이력 모델을 선택했습니다.

구현

• Spring Batch 청크 처리와 Python/Pandas 기반 전처리를 함께 활용하고, SQL upsert 스크립트 생성 방식으로 400만 건 이상 데이터를 반복 처리할 수 있도록 구성했습니다.

성과

• 반기 정산 수작업을 자동화해 반복 업무를 제거하고 장시간 소요되던 작업을 1일 내 처리 가능한 수준으로 개선했습니다. 비교 검증 리스크를 낮추고 이후 정산에도 활용할 수 있는 기준 데이터를 정리했습니다.

문제 정의

• 핵심 조회 화면 로딩이 15초+로 길고 반복 수동 작업이 누적됐으며, 단일 알림 채널로 장애 신호 누락이 발생했습니다.

의사결정

• 운영 요청 단건 대응 대신 운영 흐름을 기준으로 자동화 우선, 자주 쓰는 화면 성능 우선, 알림 중요도 분리 전략을 수립했습니다.

구현

• EXPLAIN 기반으로 병목 쿼리를 개선하고 복합 인덱스 적용, N+1 제거, 페이지네이션 개선과 자동화 과제 50건+를 수행했습니다.

성과

• 주요 조회 응답을 15,000ms → 2,000ms로 단축하고 운영팀 반복 업무를 주당 4시간 이상 줄였습니다.

모니터링

• 긴급/일반 알림 채널을 분리해 장애 인지와 대응 시간을 5분 이내로 단축했습니다.

1억 건 금융 거래 데이터를 단일 노드에서 신뢰성 있게 처리하기 위해 성능·정합성·운영성을 함께 검증한 레이크하우스 프로젝트.

문제 정의

• 데이터가 커질수록 처리 시간이 급증했고, 차원 변경 이력이 소실되면 과거 분석 결과의 신뢰도가 흔들리는 문제가 있었습니다.

의사결정

• 재처리 비용과 분석 신뢰도의 균형을 기준으로 Medallion + Star Schema를 채택하고, 차원은 SCD Type 2, Fact는 증분 MERGE 전략으로 분리했습니다.

구현

• Bronze/Silver/Gold 계층 파이프라인과 레이어별 품질 검증을 구축하고, 대용량 벤치마크 모드를 분리해 실험 재현성을 확보했습니다.

검증

• 레이어별 품질 체크와 100M 성능 실험을 반복해 정합성 훼손 없이 확장되는지 검증했습니다.

성과

• 처리 시간을 686.5초 → 24.65초까지 단축하고, 병목 원인(CPU·I/O·엔진 초기화)을 분리해 확장 의사결정 근거를 확보했습니다.

확장 전략

• Spark와 DuckDB의 엔진 선택 기준, 압축/비압축 I/O 트레이드오프, 운영 모드와 실험 모드 분리 전략을 정리했습니다.

Kafka, Apache Flink, ClickHouse 기반으로 impression/click 이벤트를 실시간 CTR로 집계하고 초기 다중 싱크 구조의 병목을 ClickHouse Materialized View 중심 구조로 재설계한 개인 데이터 엔지니어링 프로젝트.

문제 정의

• 1BRC를 통해 배치 처리에 대한 기술적 갈증은 일부 해소했지만 스트리밍 처리의 정확성과 운영성은 직접 검증할 필요가 있었습니다.
• CTR 집계는 impression과 click 이벤트가 순서대로 도착하지 않고 지연될 수 있어, 이벤트 시간 기준 집계와 지연 이벤트 처리 정책이 함께 필요한 문제였습니다.

의사결정

• 초기에는 Kafka → Flink → Redis/ClickHouse/DuckDB → FastAPI 구조로 집계, 저장, 조회 책임을 분리했습니다. 이후 Redis/API 계층의 리소스 사용과 직렬화·네트워크 오버헤드, 스키마 변경 비용을 확인하고 ClickHouse 중심 구조로 단순화했습니다.

구현

• Kafka → Flink 10초 tumbling window, event time 처리, 지연 이벤트 허용, DLQ, 설정 검증, 종료 처리 흐름을 구성했습니다.
• Flink는 ClickHouse 원본 테이블에만 기록하고 Materialized View가 최신 상태 조회와 집계 조회를 담당하도록 서빙 구조를 단순화했습니다.

검증

• checkpoint/restart 전략과 지연 이벤트 처리 시나리오를 점검해 중복·누락 리스크를 제어했습니다.

성과

• 초기 다중 싱크 구조의 오버헤드를 확인한 뒤 ClickHouse 원본 테이블과 Materialized View 중심으로 단순화했습니다.
• 기능 구현 이후 checkpoint/restart, 지연 이벤트, DLQ, ClickHouse 서빙 구조까지 검증 범위에 포함했습니다.

확장 전략

• 정확도와 지연시간의 균형점, DLQ 운영 정책, 단일 저장소 전략의 장애/확장 트레이드오프를 기준으로 정리했습니다.