강하동 — 경력 기술서

주식회사 윌로그

Backend Developer · 2025.03 ~ 재직중

기술 스택: Nest.js, Spring, PostgreSQL, InfluxDB, Redis(Cache, BullMQ), Kafka, AWS(ECS, EKS, S3, Glue, Athena)

Willog Platform — 서비스 전반의 아키텍처·인프라 부채 개선

2026.02 ~ 진행 중

윌로그는 물류 전 구간의 온도·습도·충격·위치를 측정하는 IoT 로거와 관제 SaaS를 함께 제공하는 콜드체인 모니터링 서비스를 운영하고 있습니다. 화물 유형별로 먼저 구축된 레거시 3종(바이오·창고·국제운송)은 모든 측정 정보 조회를 InfluxDB에 직접 의존하고 있습니다.

백엔드 조직이 분화되면서, 기존 서비스 전반에 흩어져 있던 아키텍처·인프라 부채를 정리하고 공통 플랫폼을 구축하는 업무를 맡았습니다.

문제

• 3개의 각기 다른 서비스에서 각각 InfluxDB에 직접 접근하여 측정 정보를 조회
• 동일한 조회 로직과 정책(소수점 처리, 화씨 표기 등)이 서비스마다 중복 구현 → 정책 하나를 바꾸려면 최소 3곳을 동시에 수정해야 하고, 누락 시 서비스 간 표시값이 달라지는 문제 발생
• InfluxDB 운영 부담 누적 — AWS 매니지드 환경에서의 관리 범위 한계로 인해 장애 상황이 1~2달 단위로 발생하며 팀 내 운영 피로도가 누적

해결 1 — Telemetry API 신설 및 대체

측정 정보 조회를 전담하는 Telemetry API를 별도로 설계·구축하여, 각 서비스의 InfluxDB 직접 의존성을 제거했습니다. 조회 정책을 단일 지점에서 일괄 반영할 수 있는 구조로 전환하여, 정책 변경이 전 서비스에 동일하게 적용되도록 했습니다.

해결 2 — InfluxDB → PostgreSQL 단계적 이관 (진행 중)

• 위 운영 부담을 근거로 대체 DB 리서치 진행
• 개인 자원으로 아키텍처를 단순화한 PoC를 먼저 구성하여 실효성을 1차 검증한 뒤 팀에 공유. 이후 단계적 이관을 리드 중
• 운영 안정성 확보를 위해 Amazon Timestream for InfluxDB가 제공하는 운영 metric을 수집한 간이 대시보드를 제작하여 팀 내 공유했고, 이후 조직의 정식 metric 대시보드 개발에 선행 사례로 활용됨

검토했으나 채택하지 않은 대안

• InfluxDB 유지: 리텐션 정책 조정·스키마 재설계 등으로 대응하는 방안을 먼저 검토했으나, AWS가 제공하는 매니지드 범위를 고려할 때 유지 비용이 이관 비용을 넘어선다고 판단
• Cassandra·MongoDB: 대체 DB 후보로 함께 검토했으나, 운영 복잡도 대비 PostgreSQL보다 나은 점이 없다고 판단하여 기각

주요 업무 및 상세 역할

• 기여자: 2명 / 담당: Telemetry API 설계·구축, 이관 PoC 구성 및 이관 실행 주도

성과 / 결과

• InfluxDB 직접 접근 지점 3곳 → 1곳(Telemetry API)로 통합
• 이관 완료 구간 기준 운영 이슈 0건
• 개인 제작 대시보드가 조직 정식 metric 대시보드 개발의 선행 사례로 채택

현재 진척과 남은 범위

• 현재 80% 이관 완료. 잔여 구간은 레거시 중 가장 복잡하고 히스토리가 많은 바이오 도메인으로, 해당 도메인 담당 개발자의 일정에 맞춰 진행 중

Willog Hub — 차세대 플랫폼 기반 설계 및 차량 모니터링 서비스 구축

2025.03 ~ 2026.02

Willog Hub는 레거시의 기술 부채를 근본적으로 해결하기 위해 구축한 차세대 플랫폼이며, 차량 모니터링은 해당 플랫폼을 기반으로 런칭한 첫 대외 서비스입니다.

문제

레거시 서비스의 기술 부채로 신규 기능 구현과 유지보수가 어려워진 상황에서, 차세대 플랫폼(Willog Hub)을 기반으로 신규 차량 모니터링 서비스를 함께 만들어야 했습니다.

• 빠른 성장 과정에서 기술 부채가 누적되어, 동일한 테이블이 도메인마다 다른 의미로 사용되는 상황까지 발생 — 데이터 신뢰도와 신규 기능 개발 속도가 함께 저하
• 측정 지표 조회를 InfluxDB에 전적으로 의존하는 레거시 구조 → 신규 서비스도 같은 구조를 따를 경우 동일한 부채를 그대로 물려받는 상황
• 차량 서비스는 위치 정보를 다루므로 개인 위치정보 사업자 인가 취득이 정식 서비스의 전제 조건이었고, 이를 위해 위치 정보 암호화가 필수

접근 — 서비스보다 기반을 먼저

차량 서비스를 곧바로 구현하지 않고, 차세대 플랫폼의 공통 기반(도메인 모델·백오피스)을 먼저 구축한 뒤 그 위에 서비스를 올리는 순서로 진행했습니다.

Phase 1 — 공통 기반 설계 및 백오피스 백엔드 단독 개발

• 차세대 프로젝트에서는 도메인별로 의미가 명확히 분리된 DB 설계를 적용하여, 레거시의 테이블 의미 중첩 문제를 구조적으로 차단
• 기획자의 초안을 함께 검토하며 기술적 관점에서 기획을 역제안

Phase 2 — 차량 모니터링 서비스 아키텍처 설계 및 MVP

해결 1 — 10분 단위 시계열 집계로 InfluxDB 의존도 축소

차량 서비스가 실제로 요구하는 조회 정밀도를 분석한 결과, 과거 시점 측정 정보를 원시 해상도로 조회할 필요는 없다고 판단했습니다. 이에 10분 단위 시계열 집계 배치 로직을 설계하여 서비스에 필요한 측정 정보를 PostgreSQL에 적재하는 방식을 채택했고, InfluxDB 의존도를 낮추면서 조회 성능의 안정성을 확보했습니다.

• 하드웨어의 측정 시점과 InfluxDB 적재 시점이 10분 경계를 넘어 어긋나는 경우 집계 대상에서 누락되는 문제가 있어, 2시간 단위 backfill 집계를 함께 구성하여 데이터 정합성을 보정

해결 2 — 위치 정보 암호화의 적용 지점 선정

규제 요구사항인 위치 정보 암호화를 측정 정보의 원천인 InfluxDB 계층에 적용할 경우, 같은 데이터를 사용하는 기존 레거시 3개 서비스 전체에 사이드 이펙트가 발생할 수 있다고 판단했습니다. 이에 원천을 건드리지 않고, 10분 단위 집계 결과를 PostgreSQL에 저장하는 시점에 AES 암호화를 적용하는 아키텍처를 제안했습니다.

• 레거시 서비스는 기존 동작을 그대로 유지 → 회귀 위험 없이 규제 요건 충족
• 암·복호화 범위가 신규 서비스 경계 안으로 한정 → 감사 대응 범위도 함께 축소

해결 3 — 제약된 컨테이너 환경에서의 20만 row 엑셀 다운로드

ECS 컨테이너당 vCPU 0.5 / memory 0.5GB인 제약 환경에서 20만 row 규모의 엑셀 다운로드 기능을 구현했습니다. 기존 레거시는 화면에 표시되는 페이지 단위로만 엑셀이 생성되어 대량 데이터 다운로드가 사실상 불가능한 상태였습니다.

• Worker Thread(Piscina)로 엑셀 생성을 분리하여 메인 이벤트 루프 블로킹 방지
• 워커 로직 객체를 프레임워크 기본 방식대로 싱글톤으로 유지한 결과, 엑셀 생성이 끝나도 GC 대상 부산물이 해소되지 않고 누적되어 메모리가 반환되지 않는 문제 발생 → 요청 시점에 워커 로직 객체를 생성하고 작업 종료 시 제거하는 방식으로 전환하여 해소
• 동시 요청이 몰릴 때 워커가 요청마다 작업을 수행하면서 컨테이너가 OOM으로 종료되는 문제 발생 → 글로벌 세마포어로 컨테이너당 동시 작업을 1건으로 제한하고, 대기 중인 요청에는 SSE로 대기 순번을 전달
• SSE로 클라이언트에 실시간 진행률 제공 — 장시간 작업의 사용자 이탈 방지. 대기 상태가 길어져 45초간 응답이 없으면 커넥션이 끊기는 문제가 있어, 20초 interval의 heartbeat 이벤트를 별도 타입으로 전송하여 해소
• 200건 단위 chunk 조회 및 S3 스트리밍 write를 이용하여 생성 속도와 메모리 안정성 간의 트레이드 오프를 조율
• AbortController로 클라이언트 연결 해제를 감지하여 진행 중인 워커 작업을 중단하고 리소스 즉시 정리

주요 업무 및 상세 역할

• Phase 1 (기반·백오피스) — 백엔드 단독 (프론트엔드 1명, 기획 1명과 협업) / 요구사항 검토, DB 설계, 백엔드 전체 구현
• Phase 2 (차량 서비스) — 백엔드 3명 / 아키텍처 설계 및 MVP 런칭 주도, 백엔드 개발의 60~70% 담당

성과 / 결과

• 개인 위치정보 사업자 인가 취득 (2025.11) — 제안한 암호화 아키텍처가 인가 요건 충족의 근거
• Phase 1에서 설계한 기반 위에서 약 6개월 뒤 차량 서비스 MVP 런칭. 이 시점은 정식 대외 오픈이 아닌 고객사 PoC 단계로 운영 범위를 한정하여, 인가 심사 기간과 서비스 검증을 병행
• 20만 row 엑셀 다운로드: 기존에는 불가능했던 대용량 데이터 처리를 지원(약 1분 30초 소요), 기저 사용량을 포함한 컨테이너 피크 메모리 사용률 80% 이하로 관리
• MVP 런칭 후 용마로지스, 지오영, 코미코 등 다수 기업과 PoC 및 도입 진행
• 관련 기록: SSE + Worker Thread 기반 엑셀 다운로드 구현 · 10분 단위 집계 정보 저장 로직

(주)펄핏

Backend Engineer · 2024.03 ~ 2025.01

기술 스택: Nest.js, MongoDB, Qdrant, Python, FastAPI, AWS(Lambda, Bedrock)

PerfittSize — 백엔드 아키텍처 개선 및 이미지 기반 신발 검색

2024.03 ~ 2025.01

PerfittSize는 단 한 번의 발 촬영으로 신발 사이즈를 모델별로 추천하는 B2B 서비스입니다. 고객사가 신발 모델을 등록하면 실측 정보를 기반으로 사이즈 추천 데이터를 산출해 제공하며, 모델 1건당 산출 비용이 발생합니다.

문제 1 — 서버리스 아키텍처의 유지보수 생산성 저하

Nest.js + AWS Lambda 기반 서버리스 아키텍처로 인해 디버깅의 AWS 콘솔 의존도가 높고 코드 복잡도가 증가하여, 장애 대응 및 신규 개발 생산성이 저하되었습니다.

해결 1 — Feature Flag 기반 무중단 점진 이관

메인 비즈니스 로직을 Layered Architecture Nest.js로 이관하는 프로젝트를 주도했습니다. 서비스 중단 없는 전환을 위해 Feature Flag를 도입하여 기능 단위로 트래픽을 점진 전환하는 방식을 택했고, 문제 발생 시 즉시 롤백 가능한 구조를 확보했습니다.

잔여 범위와 그 이유

재직 기간 중 핵심 로직 60%의 이관을 무중단으로 완료했습니다. 잔여 40%는 신규 기능 개발을 병행해야 했고 고객사별 스펙 협의가 선행되어야 하는 영역이어서 후순위로 판단했습니다.

문제 2 — 동일 신발의 중복 산출로 인한 불필요 비용

고객사로부터 사이즈 추천 요청이 지속적으로 인입되는 상황에서, 이미 산출이 완료된 신발과 구조적으로 동일한 신발이 다시 요청되어 재계산이 발생하고 있었습니다.

• 담당자가 신발 모델 매핑 기록을 엑셀로 수동 관리 → 중복 판별이 사람의 기억과 눈에 의존
• 고객사별 요청량이 인입 건당 최소 20개, 많게는 500개 이상 → 수동 판별의 한계가 명확
• 중복을 걸러내지 못하면 이미 보유한 데이터를 재활용하지 못하고 건당 약 20분의 재작업 공수가 발생

해결 2 — 이미지 벡터 검색 도입

• 인입되는 이미지의 구도가 제각각이라 유사도 비교 자체가 성립하지 않는 문제가 있어, Teachable Machine으로 '신발 옆면' 판별 모델을 만들어 비교 대상을 옆면 사진으로 한정하고 흑백 변환·크기 통일 전처리를 적용
• 약 6만 건의 신발 이미지를 벡터화하여 Qdrant Vector DB에 저장하고 유사 신발 검색 기능을 구현
• 유사도 비교 방식은 이미지 검색에 일반적으로 권장되는 Euclidean distance 대신, 자체 비교 결과 의도한 검색 결과에 더 근접했던 Cosine similarity를 채택
• Qdrant를 선택한 이유: 실험적 도입 단계라 초기 비용과 셋업 리소스를 최소화해야 했고, Qdrant Cloud의 free tier로 인프라 투입 없이 즉시 검증에 착수할 수 있으며 필요 시 인스턴스 확장도 용이. 문서화 수준과 오픈소스로서의 기능 추가 속도도 함께 고려
• 자체 평가 기준 약 80%의 검색 정확도 달성

오매칭 방지 설계

• 오매칭은 곧 잘못된 사이즈 추천으로 이어지므로, 유사도 임계값 85% 미만은 자동 매칭하지 않고 기존 방식대로 신규 산출하도록 설계하여 위험을 차단

그 외 담당 업무

• Amazon Bedrock Knowledge Bases 기반 신발 추천 챗봇 PoC 개발 — 구조화된 신발 리뷰 데이터의 특성에 맞춰 커스텀 청킹 방식을 리서치하여 적용 (기본 청킹은 리뷰 단위 의미가 분절되는 문제가 있었음)
• 2주 단위 스프린트와 기술 공유 세션을 주도

주요 업무 및 상세 역할

• 기여자: 2명 / 담당: 아키텍처 이관 주도, 이미지 검색 기능 전체 구현, 추천 로직 고도화

성과 / 결과

• 핵심 로직 60% 무중단 이관 완료
• 담당자의 수동 매핑 업무 주당 약 10시간 → 3시간, 중복 산출 건당 약 20분의 재작업 공수 제거
• 관련 기록: Qdrant를 이용한 유사 신발 검색 기능 구현

주식회사 인에디트 (inedit Corp.)

Senior Backend Developer · 2023.03 ~ 2024.02

기술 스택: Nest.js, PostgreSQL, BullMQ, Jest, DBT, Trino, AWS(Glue)

Brandazine — 레거시 마이그레이션 및 '협업' 도메인 재설계

2023.03 ~ 2024.02

Brandazine은 크리에이터와 패션 브랜드를 연결하는 프라이빗 네트워크로, 의류 대여·브랜드 행사 초청 등 브랜드-크리에이터 간 상호작용을 중개합니다.

문제 1 — 레거시의 조회 복잡도

Django REST Framework 기반 레거시를 Nest.js로 이관하는 전사 프로젝트에 참여했습니다. 조회 기능 하나에 테이블 간 7~9개의 nested join이 발생하는 고복잡도 시스템인 데다 초기 개발자들이 모두 퇴사한 상태여서, 당시 개발 조직의 판단으로 Nest.js 이관을 결정했습니다.

해결 1 — 점진적 이관과 조회 성능 개선

• 주요 기능의 안정성을 유지하면서 약 70%의 백엔드 코드 마이그레이션을 완료. Slow Query 해소 및 Materialized View 도입을 통해 조회 속도를 평균 1분에서 5초 이하로 개선
• 잔여 30%는 신규 기능 개발을 병행하기 위해 다음 단계로 인계

문제 2 — 유사 성격 기능의 분산 운영

의류 대여, 브랜드 행사 초청 등 브랜드-크리에이터 간 상호작용이 각각 별도 기능으로 존재해, 성격이 같은 활동이 서로 다른 Flow로 관리되고 있었습니다.

해결 2 — '협업' 도메인으로 재구성

이를 '협업'이라는 새로운 개념으로 재구성하는 전사 프로젝트에서 DB 설계와 백엔드 개발을 주도했습니다.

• 기존 데이터와 신규 기능이 단절 없이 통합되도록 안정적인 Data Migration을 수행 — 서비스 확장성을 고려한 구조로 설계
• MVP 기능 구현부터 data migration까지 약 2~3개월 소요

문제 3 — 데이터 파이프라인의 처리 요건 미충족

기존 AWS Glue 기반 파이프라인이 늘어나는 데이터 처리 요건을 충족하지 못해 개선이 필요한 상황이었습니다.

해결 3 — MWAA 대신 DBT + Trino 채택

• 데이터 파이프라인 개선을 위해 AWS Managed Airflow(MWAA) 도입을 우선 검토했으나, 당시 조직의 비용 제약 하에서는 매니지드 서비스의 고정비가 과하다고 판단
• 오픈소스 기반 대안을 리서치하여 DBT + Trino 조합을 채택. 기존 AWS Glue 기반 파이프라인을 대체하면서 요구되던 데이터 처리 요건을 충족
• 트레이드오프: 매니지드 대비 초기 구축 공수가 증가하나, 실행 빈도를 고려할 때 감내 가능한 수준으로 판단. 또한 실제 데이터 운영 주체(사무 직군)의 SQL 활용 역량을 고려하여, Python 기반의 Airflow보다 SQL 중심으로 작동하는 DBT가 조직 환경에 더 적합하다고 판단

주요 업무 및 상세 역할

• Nest.js 이관: 기여자 4명 중 B2C 관련 기능 영역 이관 담당
• '협업' 도메인 재설계: DB 설계 및 백엔드 주도
• ETL Pipeline 개선: 기술 선정 및 구축 참여

성과 / 결과

• 레거시 마이그레이션 70% 완료, 이관 구간 장애 0건
• '협업' 도메인 통합으로 기능별 Flow를 하나의 방향으로 통일

(주)더블유클럽

Tech Lead · 2021.11 ~ 2023.03

기술 스택: Node.js, MongoDB, Redis, Jest, Firebase, AWS(SNS, SQS, S3, CloudFront, ECS)

WClub — Tech Lead 및 조직 운영

2021.11 ~ 2023.03

WClub은 결혼정보회사와 소개팅 앱이 각각 가진 문제를 해결하는 프리미엄·프라이빗 매칭 서비스입니다. 만남이 무산되었을 때 어느 쪽 사유인지를 판정하는 '귀책 판별'이 페널티·환불 정책과 직결되어, 정확성과 일관성이 요구됩니다.

조직 — Tech Lead 역할

최대 10인의 주니어 개발자를 리딩하며 개발 조직의 성장과 운영을 주도했습니다.

• 주니어 채용 및 육성 체계를 수립하여 온보딩 기간 3개월 → 1.5개월로 단축
• 2주 단위 스프린트 문화 정착, 정기 코드 리뷰 및 기술 공유 세션 운영
• 전반적인 API 설계 및 DB 모델링

문제 — 성장에 따른 스케줄러 부하 집중

재직 기간 중 서비스 매출이 2배 성장함에 따라 매일 실행되는 '시간 만료 취소' 스케줄러의 처리 대상이 비례해 증가하면서, 단일 인스턴스에서 매칭 취소와 귀책 판별 로직을 함께 처리하기에 부하가 가중되는 문제가 발생했습니다.

해결 — SNS + SQS Fan-Out

• AWS SNS + SQS 기반 Fan-Out Pattern을 도입
• SNS의 메시지 필터링을 활용해 귀책 대상을 성별 기준으로 분리된 SQS Queue에 전파
• 각 인스턴스가 Queue를 구독하여 처리 로직을 분산
• 도입(2022.08) 이후 AWS SDK 업데이트로 SNS의 Region 정보가 필수화되면서 메시지 발행이 실패하는 장애가 발생(2022.12) → 원인 파악 후 Region 설정 추가 및 재배포로 해소

성과 / 결과

• 단일 인스턴스에 집중되던 스케줄러 처리 부하를, SNS 메시지 필터링으로 분리한 남/여 2개 Queue와 인스턴스별 Consumer 구성으로 분산
• 귀책 판별 로직이 성별 단위로 분리되어 모듈 간 결합도 감소 및 처리 효율 증대
• 온보딩 기간 3개월 → 1.5개월 (50% 단축)
• 연간 팀원 이탈률 10% 이하 유지 (재직 중 팀 규모 5명 → 10명)
• 관련 기록: 부하분산을 위한 Fan-Out Pattern 적용

쿠팡 주식회사

Software Developer → Senior Software Developer · 2016.06 ~ 2021.11

기술 스택: Spring, JPA, MySQL, Kafka, React.js, D3.js, AngularJS, AWS

RMS — 반품 검수 프로세스 설계 및 구현

2018.01 ~ 2021.11 · Senior Software Developer

RMS는 여러 경로로 인입되는 반품 상품을 검수해 재판매·리퍼비시·폐기를 결정하고 후속 처리를 지원하는 반품 관리 시스템입니다. 반품 검수는 상품 상태·구성품 누락 여부·상품 정책을 확인해 등급을 부여하는 공정이며, 그 '검수 기준'은 상품 카테고리·재질 등 조건에 따라 달라지는 검수 문항과 분기 규칙의 집합입니다.

문제

반품 검수 기준이 통일되어 있지 않아 검수 결과가 작업자 개인의 판단에 의존하고 있었고, 이로 인해 다음 문제가 발생했습니다.

• 일관되지 않은 검수로 인한 양방향 손실
  • 재판매 가능한 상품을 폐기 등급으로 판정 → 회수 가능했던 재고 가치 손실
  • 폐기해야 할 상품을 재판매 등급으로 판정 → 고객 VOC 및 재반품 발생, 처리 비용 이중 발생
• 검수 기준 변경 시마다 개발자의 코드 수정과 배포가 필요 → 정책 변경 속도가 현업 요구를 따라가지 못함
• 판정 근거를 추적할 수 없어, 분쟁 발생 시 어떤 기준으로 판정했는지 소명 불가
• 작업자가 상품 정보를 수동으로 확인해야 하여 상품당 처리 시간 증가

기능 요구사항

• 지속적으로 추가될 수 있는 검수 문항과 파라미터를 개발자 개입 없이 관리자가 직접 조합할 수 있어야 함
• 상품 유형·공급사·가격대에 따라 서로 다른 검수 흐름을 적용할 수 있어야 함
• 검수 기준의 변경 이력을 추적할 수 있어야 하고, 특정 시점 기준으로 판정 결과를 재연할 수 있어야 함

해결 1 — 문답(Q&A) 기반 Decision Tree

검수 흐름을 Root Node(질문) → Branch(답변) → … → Leaf Node(최종 등급)로 구성되는 문답 기반 Decision Tree 구조로 설계하여, 검수의 일관성과 신뢰성을 확보했습니다. 작업자는 시스템이 제시하는 문항에 순차적으로 답하고, 그 경로에 따라 최종 등급이 결정됩니다.

해결 2 — D3.js 기반 트리 UI 어드민

• 관리자가 검수 기준을 직관적으로 관리할 수 있도록 D3.js 기반 트리 구조 UI를 개발
• 검수 기준은 조건 분기가 중첩되는 구조여서, 일반 폼이나 테이블 형태로는 "이 조건이면 최종적으로 어느 등급으로 가는지"를 관리자가 확인할 수 없음. 오설정이 곧 상품 폐기 또는 잘못된 재판매로 이어지므로, 전체 분기와 그 흐름이 시각적으로 인지될 수 있는 트리 형태가 필요하다고 판단
• 어드민 도입을 통해 현업 담당자가 개발자 의존 없이 검수 기준을 즉시 수정·운영할 수 있게 되었으며, 축적된 판정 데이터를 바탕으로 기준을 지속해서 고도화할 수 있는 환경을 마련함

주요 업무 및 상세 역할

• 기여자: 총 4명
• 담당: 검수 기준 관리 어드민 화면 개발, 검수 프로세스 진행 로직 및 판정 결과 저장

성과 / 결과

• 특허 취득 (공동 발명자) — 반송된 제품의 등급을 매김으로써 재고를 관리하기 위한 컴퓨터 시스템 및 방법
  • US11763255 · patents.google.com/patent/US11763255
  • KR102523469B1 · patents.google.com/patent/KR102523469B1
• 전적으로 작업자 주관에 의존하던 판정을 시스템이 제시한 문답 경로로 등급이 결정되는 구조로 전환하여, 작업자의 임의 판단 개입률 10% 이하로 감소
• 시간당 검수 판정 처리량 2배 이상 증가

RMS 민감정보 분리보관 — 상장 대비 보안 감사 대응

2020.03 ~ 2020.10 · Senior Software Developer

탈퇴자·장기 휴면자의 개인정보를 운영 DB에서 분리해 보관하고, 보관 기간이 지나면 파기하는 개인정보 보호 요건을 처리한 내용입니다.

문제

• 상장(IPO)을 앞두고 전사 보안 감사 기준을 충족해야 하는 상황. 팀 소유 약 60개 테이블 중 민감정보를 포함한 10개 테이블이 대상이며, 3개년치 데이터를 운영 중단 없이 처리해야 하는 조건
• 멤버 정보의 원천은 중국팀, 보안 기준 수립은 미국팀 → 3자 협업이 전제 조건이며 기준 해석이 어긋나면 감사 재수행 위험
• 대량 데이터 일괄 인입 시 운영 DB 부하 및 처리 오류 가능성

해결

• 보안 조직의 요구사항을 분석하여 아키텍처 설계: 멤버팀이 발행하는 Kafka 이벤트 수신, 논리적 DB Schema 분리, 분리보관·5년 경과 삭제·원복 Batch 구성
• '장기 미사용자가 재접속하면 분리보관된 정보를 원본 저장소로 되돌려야 한다'는 요건을 충족하기 위해 원복(restore) 처리를 함께 설계. 보안 정책상 Hard Delete가 강제되어 삭제 시 Cascade를 무시해야 했고, 원복 시 PK를 원본 값 그대로 복원해야 해 JPA의 Auto Increment 제약을 우회하는 native query insert로 구현
• 멤버팀 사정으로 3일에서 4일치 대상이 한 번에 발행되는 경우가 있어, 200 row 단위 pagination 및 트랜잭션으로 처리. 10만 row 중 일부가 실패해도 전체 롤백이 아닌 해당 200 row만 실패하고, 재실행 시 그 구간만 재처리되도록 설계
• 중국팀·미국팀과 지속 커뮤니케이션하며 보안 요구사항을 충족하는 동시에 실행 가능한 분리보관 방식을 도출

주요 업무 및 상세 역할

• 기여자: 2명 / 담당: 요구사항 분석, 아키텍처 설계, Batch 로직 설계 및 구현, 마이그레이션 수행

성과 / 결과

• 약 7개월간 진행하여 전사 개발팀 중 최초로 보안 감사 통과
• 관련 기록: 민감정보 분리 경험 기록

TMS — 라스트마일 배송 시스템

2016.06 ~ 2017.12 · Software Developer

TMS는 전국 각지의 쿠팡 배송 캠프에서 배송 물품과 배송 대상을 확인·관리하는 라스트마일 시스템입니다.

문제 및 해결

• 캠프별로 흩어져 있던 배송 데이터를 수동으로 취합하여 리포팅하고 있었음 → 캠프별 배송량을 집계·시각화하는 일간 배송량 대시보드 구축에 참여하여 수동 리포팅을 대체하고 데이터 기반 의사결정을 지원
• 일반인이 아르바이트 형태로 배송에 참여할 수 있는 유연 배송 PoC 프로젝트에서 배송기사용 웹앱 화면 개발

성과 / 결과

• 수동 취합하던 120개 캠프의 일간 리포팅을 자동화
• 참여한 유연 배송 PoC가 이후 쿠팡 플렉스로 이어짐