원준호

1. 커머스 택배허브 — 9개 택배사 배송추적·반송장 파이프라인 및 이벤트 인프라 구축

회사: 다우기술기간: 2026.04 ~ 2026.09인원: 택배허브 개발 3명(본인 포함) · 사방넷 개발 2명 · 기획 3명역할: Gateway·Kafka·배송추적·관측성 설계·구현

배경

외부 대행사(굿스플로)를 거치던 택배접수·배송추적을 사방넷이 9개 택배사(CJ·한진·롯데·로젠·우체국·일양·카카오T·딜리박스·딜리래빗)와 직접 연동할 수 있도록 허브를 새로 구축했습니다. 택배사마다 API·인증·상태 코드가 달랐고, 기존 WMS는 동기식 처리 구조로 인한 중복 출고·보상 이슈가 있어, 이벤트를 정확히 추적·재처리하는 구조가 핵심 과제였습니다.

배송추적·반송장 배치 흐름 · Gateway는 외부 API 호출(hub-api) 전용으로 배치와 분리 · 전 구간 trace_id로 Grafana에서 추적

주요 기여

① 배송추적 · 반송장 배치 파이프라인 설계·구현 (Spring Batch)

• 택배사 어댑터 9종 전량 구현, 상이한 상태 코드를 표준 8값(매핑 106건)으로 정규화 — 신규 택배사 추가 시 수정 지점 2곳
• Transactional Outbox → Kafka → 웹훅으로 이벤트 유실을 구조적으로 차단하고, 4계층 멱등성으로 재처리해도 웹훅은 1회만 발송
• 택배사가 사후에 채우는 반송장을 3가지 경로로 획득, 후보가 모호하면 갱신하지 않고 알림 — 반송장 오귀속 차단

② Kafka 도입 제안·이벤트 아키텍처 설계

• WMS의 동기식 처리 구조로 인한 중복 출고·보상 이슈를 보완하기 위해, 디스크 영속·로그 재읽기로 이벤트 추적·재처리가 가능한 Kafka 도입을 제안
• 트래픽 산정(일 16만 건·피크 100 msg/s)으로 서버 스펙·디스크를 산출하고, 초기 3대 Combined 안은 Confluent 운영 미지원을 확인해 폐기 → 브로커 3 + 컨트롤러 3 Isolated 구성으로 설계

③ 관측성 전환 (Pinpoint → Grafana LGTM)

• 로그 확인에 서버 접속이 필요하고 트레이스·로그가 분산되던 Pinpoint의 한계를 보완 — trace_id로 트레이스↔로그 양방향 이동, Kafka 브로커·consumer lag·Redis까지 한 화면에서 관측
• Kafka ISR 축소·컨슈머 중단·5xx 비율 등 알림 룰 17종 → Slack, 대시보드 7종 구축. 계측은 인프라운영팀이 대응 가능한 사내 표준(OTel 에이전트)으로 단일화

④ API Gateway 설계·구현

• 서버 간 호출(Basic)과 셀러 브라우저 iframe(JWT) 2트랙 인증을 엣지 한 곳으로 통합. 자격증명 검증은 내부 API로 위임하고 비동기 캐시(stampede 방지)로 흡수해 GW의 DB·bcrypt 의존을 없애고 event loop 블로킹 0
• Redis Lua 기반 Sliding Window 레이트리밋을 직접 구현(계약·클라이언트·토큰발급 3 tier) — 계약 하나의 트래픽이 다른 계약에 영향을 주지 않도록 격리, Redis 지연 시 fail-open
• 재시도를 TCP 연결 실패로만 제한해 POST 중복(운송장 중복 발행) 차단, XFF 신뢰 hop 기반 판정으로 IP 위조 차단(CVE-2026-47825 대응)

성과

• 택배사 9사 연동 허브의 인프라(Gateway·Kafka·관측성)와 핵심 데이터 흐름(배송추적·반송장)을 설계·구현
• 이벤트 유실·중복을 코드 규칙이 아닌 트랜잭션 경계와 DB 제약으로 차단 — 이벤트를 로그에서 다시 읽어 재처리할 수 있는 구조 확보
• Kafka 클러스터·토픽·Outbox·메시지 계약을 허브 비동기 연동 표준으로 수립

협업: 사방넷 개발자 2명, 기획팀 3명, 인프라운영팀기술 스택: Spring Boot 4, Java 25, Spring Cloud Gateway(WebFlux), Spring Batch, Kafka(Confluent 8.2, KRaft), Redis Cluster, MySQL, OpenTelemetry, Prometheus, Grafana, Loki, Tempo, NCP

2. WMS 물류 — 엑셀 발주 일괄등록 배치 전환 (PHP → Spring Batch)

회사: 다우기술대상 서비스: WMSPHP / 스프링 배치기여도: 100%

서비스 설명

PHP 기반 엑셀 발주 배치에서 파일당 15,000건 처리 시 12분 이상 소요되거나 OOM으로 중단되는 문제가 반복됐습니다. Spring Batch로 전환한 초기 버전에서도 동일 증상이 재현돼, "프레임워크 전환"이 아니라 병목의 실체를 프로파일링으로 재정의하는 것부터 다시 시작한 프로젝트입니다.

문제 정의 (병목 실측)

• 건별 조회·처리 반복(N+1)으로 15,000건 처리에 판매상품 조회만 15,000회 발생 — 처리 시간의 지배 요인
• 파일 전체 데이터를 힙에 유지한 채 처리해 60,000건 파일에서 Peak 메모리 1GB+ → OOM — 처리량이 아니라 상주 객체가 원인

판단·설계

• 생성키 구간과 벌크 구간의 분리 — 주문 생성처럼 생성키(PK) 반환이 필요한 구간과 하위 데이터처럼 벌크 처리가 가능한 구간을 나눠 MyBatis ExecutorType을 SIMPLE / BATCH로 구간별 선택 적용 — "키 반환"과 "배치 효율"의 트레이드오프를 일괄 적용이 아닌 구간 단위로 판단하고, 공용 BatchInsertExecutor로 규격화해 다른 배치에서도 재사용
• N+1 제거 — 건별 조회를 벌크 조회로 전환해 판매상품 조회 15,000회 → 1회
• 메모리 상주 제한 — 청크 단위 처리 + 배치 단위 flush·clear 기반 메모리 해제로 힙에 남는 객체를 처리 중 청크로 한정
• 구조 단순화·실패 격리 — 5개 독립 프로세스를 1개 통합 Job(4단계 Step)으로 재편하고, 파일 단위 독립 처리로 부분 실패 격리, 원자적 상태 변경 Commit으로 중복 처리 배타 제어

검증

• IntelliJ Profiler로 개선 전후 힙 사용량을 실측 대조하고, 처리 시간·쿼리 횟수를 수치로 확인 — 추정이 아닌 측정으로 개선 효과를 증명

성과

항목	개선 전	개선 후
처리 시간 (15,000 row)	약 12분	45초 (93.75% 감소)
판매상품 조회 쿼리	15,000번	1번 (99.997% 감소)
Peak 메모리 (60,000 row)	1GB+ (OOM 발생)	250~400MB (60~75% 감소, OOM 해결)

협업: 커머스서비스기획팀, 커머스운영팀기술 스택: Spring Batch, SpringBoot, MyBatis, Java, Bitbucket(Git), MySQL, NCP

3. 물류 피킹통합 기능 확장 및 주문 단위 출고 작업 기능 신설, 출고지시 자동화 배치 구현

회사: 다우기술대상 서비스: WMSFrontend / Backend / 스프링 배치기여도: 100%

서비스 설명

목적: 출고 작업 효율성 향상을 위한 다양한 피킹 방식 지원.
핵심 기능: 출고주문별조회 메뉴 신설, 피킹통합 기능, 출고지시 자동화 배치.
배경: 기존 출고회차 기준 피킹 방식의 한계 해소 및 출고 프로세스 자동화 확대.

핵심 과제는 2개월 일정 안에서 신규 출고·택배접수 로직의 신뢰성을 확보하면서, 운영 중인 기존 출고 흐름에 사이드 이펙트를 만들지 않는 것이었습니다.

책임 — 설계부터 오픈까지 전 과정 담당 (2개월)

• 주문 수신부터 피킹·재고 할당·출고 상태 변경까지의 흐름 전체를 분석해 통합 지점과 분리 지점을 결정
• 출고주문별조회 메뉴 신설(10여개 핵심 기능), 출고지시 자동화 배치 설계·구현

판단·설계

• 데이터 구조가 다른 회차 단위 피킹과 주문 단위 피킹을 Strategy 패턴으로 통합 — 피킹 방식(송장/총량 등)이 늘어나도 구현체 추가만으로 확장되는 구조로 설계
• 기존 회차 단위 출고와 신설 주문 단위 출고를 서비스 레벨에서 완전 분리 — 기존 로직을 확장하는 대신 분리를 선택해 운영 기능 사이드 이펙트 제로 달성
• 출고요청 → 출고지시 상태 자동 변경 배치 Step 구현으로 출고 프로세스 자동화 확대

검증

• 재고 검증·할당·이동과 출고 상태·히스토리의 상태 전이 조합, 할당 실패 조건을 테스트 케이스로 먼저 정의하고 JUnit + Mockito로 코드화 (정상·예외·경계값)
• 기획팀 작성 TC 1,500건 전수 PASS — 단위 테스트 결과와 대조해 누락된 예외 조건을 보완, 운영 전환 리스크를 오픈 전에 제거

협업: 커머스서비스기획팀, 운영팀기술 스택: Spring Batch, SpringBoot, MyBatis, Java, Bitbucket(Git), MySQL, NCP

4. 정산 시스템 연동 안정화를 통해 데이터 정합성 100% 확보 및 회계 리스크 제거

회사: 다우기술대상 서비스: BackOffice 빌링 시스템 / 신정산 시스템기여도: 80%

서비스 설명

연간 약 300억 규모의 빌링-정산 데이터를 관리하는 그룹웨어 백오피스에서, 빌링시스템 내 정산 코드를 분리하고 신정산시스템 연동 인터페이스를 재설계·구현하는 프로젝트를 진행했습니다.

연동 오류·데이터 불일치·정산 마감 지연을 빌링 시스템 분리 및 연동 구조 개선으로 해결하여 2025년 6월 정산 시스템 안정 오픈을 지원했고, 정산 데이터 정합성 100%를 확보했습니다.

문제

• 월말 정산 마감 시, 빌링·정산 데이터 불일치를 엑셀 기반 수작업 검증으로 처리
• 오류 데이터 발생 시 DB 직접 수정 방식으로 대응하여 휴먼 에러 및 회계 리스크가 여전히 존재
• 빌링 데이터 변경이 매출 데이터에 직접 영향을 미치는 구조로 스파게티 코드가 산재되어 있고 도메인 간 불필요한 의존성으로 인해 원인 추적이 어려움 (도메인 강한 결합)
• 이로 인해 월말 매출/매입 마감에 약 1주일 이상 소요되는 고질적인 문제 발생

판단·해결

• 불일치의 근본 원인을 "빌링 데이터 변경이 매출 데이터에 직접 전파되는 강결합 구조"로 진단 — 직접 참조를 끊고 이력 저장 + 배치 동기화 방식으로 연동 구조를 재설계해, 오류가 나도 이력으로 추적·재처리 가능한 구조로 전환
• 연동 실패 데이터에 대해 히스토리 기반 검증 및 수동 재동기화 기능 구현 — DB 직접 수정 관행을 도구 기반 복구로 대체
• 계약·결제·환불 단위의 실시간 데이터 검증 및 재동기화가 가능한 빌링·정산 모니터링 구현 — 불일치를 월말 마감 때가 아니라 발생 시점에 감지

성과

• 월말 매출/매입 마감 소요 시간 1주일 → 1~2시간으로 단축 (개발팀 담당 파트 기준)
• 월 수천만 원 규모로 발생하던 정산 데이터 정합성 이슈 완전 해소
• 엑셀 수작업 검증·DB 직접 수정 제거로 업무 안정성 및 신뢰도 향상

협업: 플랫폼기획팀, 정산팀기술 스택: SpringBoot, Hibernate, JPA, Java, Bitbucket(Git), Postgresql, Linux, Jira, Vue.js

5. 백오피스 & 4개의 플랫폼서비스 개발 & 운영 & 트러블슈팅

회사: 다우기술대상 서비스: BackOffice / 고객 인입 포털 / 외부 API 연동 서비스 / 클라이언트 조직도 동기화 서비스 등기여도: 40%

책임

• 주문, 계약, 환불, 정산 등에 대한 코드 리팩토링 및 운영
• 외부시스템 근태, 전자결재 연동을 위한 API 연동 서비스 개발 및 운영
• 다우오피스 회사별 조직도를 내부 서비스로 단방향 동기화하는 미들웨어 서버 개발 및 운영
• 매달 정산 마감 진행 → 데이터 정합성이 깨진 케이스 분석 후 즉시 코드 개선

주요 기여

• 대용량 엑셀 다운로드 OOM 개선 — 전체 데이터 기준 200초 → 60초 미만. XSSFWorkbook → SXSSFWorkbook 스트리밍 전환, 쿼리 개선 및 QueryProjection 적용으로 메모리 사용량 감소
• 주문 케이스별 복잡 로직 유지보수성 개선 — 공통 인터페이스 설계 후 주문 타입별 서비스 구현체 동적 로딩으로 개선
• 만료 멤버십 해지 프로세스 Spring Batch 자동화 — 수동 업무 제거, 해지 실패 시 다우메신저 알림 발송
• 신규 고객포털 오픈 전 약 13,000명 담당자 대상 초대장 일괄 전송 및 재시도 전략 수립
• BackOffice ddl-auto none → validate 전환 — Entity·PostgreSQL 타입 불일치 일괄 정리, DBA와 ID 생성 전략 정립 후 시퀀스 기반 일괄 적용으로 데이터 일관성 강화

협업: 사업부, 영업부, 기획팀, DBA, 내외부 클라이언트 등기술 스택: SpringBoot, Hibernate, JPA, Java, Bitbucket(Git), Postgresql, Linux, Jira, Vue.js

6. RabbitMQ & Scheduling 기반의 서비스 신규개설 요청에 대한 통합 알림 프로세스 개발

회사: 다우기술대상 서비스: BackOffice기여도: 100%

서비스 설명

고객의 멤버십 서비스 개설 요청 시, 총 6개 시스템(다우오피스, 외부 API 서버, 조직도 동기화 서버, 회계 시스템, 메일 시스템, DNS 등)에 대해 개설 처리를 수행함. 기존에는 서비스별 개설 성공/실패 여부를 로그를 통해 개별 분석해야 하는 번거로움이 있었음.

운영 효율을 높이기 위한 목적에서, 기존 시스템에 영향 없이 확장 가능한 비동기 알림 구조가 필요하다고 판단하여 자발적으로 기획하고 구현.

책임

• 기존에 구축된 서비스 개설 요청 및 응답 큐 구조를 활용
• 각 서비스 개설 요청 시, 알림 요청 데이터를 별도 테이블에 저장하여 상태 추적 가능하도록 구성
• 서비스별 성공 응답 큐 또는 실패 큐 수신 시, 해당 알림 요청 데이터를 기반으로 상태 판단 및 알림 발송 처리
• 메일 시스템의 도메인 등록 지연 등을 고려해 실패 알림은 10분 후 발송되도록 스케줄링 처리
• 모든 서비스 개설 요청에 대한 성공/실패/지연 응답 데이터를 실시간으로 수집하고 다우메신저로 알림을 발송해주는 통합 알림 메신저 발송 기능 개발

주요 기여

• 기존 시스템에 영향 없이 알림 요청/응답 추적 구조와 다우메신저 알림 발송을 독립 설계·구현
• 성공 시 실시간 알림, 실패 시 지연 알림(10분 후) 발송 로직 구축
• 알림 상태 데이터화로 로그 분석 없이 개설 성공/실패를 실시간 파악 가능
• RabbitMQ·스케줄링 기반으로 메일 시스템 지연에 유연 대응

협업: 기획팀, 운영팀기술 스택: SpringBoot, RabbitMQ, Hibernate, JPA, Java

7. 멤버십 구요금제 → 신요금제로 전환 프로세스 설계 및 구현

회사: 다우기술대상 서비스: BackOffice / 고객 인입 포털기여도: 50%

책임

• 구요금제 ↔ 신요금제가 보유한 상품 매핑 전략 수립
• 요금 인상 전체 프로세스에 대한 다이어그램 작성
• 연장 주문 시점에 요금제 전환 컨버터 설계 및 개발
• 전환 시 발생할 수 있는 예외 케이스 정리 및 테스트를 통한 검증

주요 기여

• 약 3,000개 이상 고객사 요금제 전환 완료
• 요금제 전환 인터페이스를 설계 및 구현하여 이후 요금제 전환 시 개발 공수 1MM → 1MD로 최소화, 테스트 시나리오 검증만으로 사업부 니즈 충족
• 검증 시나리오로 예외 케이스 최소화, 전환 시점 오류 발생 시 메신저 알림으로 즉시 대응 가능한 프로세스 구축

상세 설명

멤버십의 요금제가 변경될 경우 요금제 전환을 하기 위해 고객사별 할인 승계, 사용중인 데이터 마이그레이션 등 수 많은 검증 케이스를 통과해야 했습니다.
현재는 요금제 전환 인터페이스를 활용하여 요금제 전환이 필요한 구요금제 ↔ 신요금제 간의 데이터 관계만 설정하면 신속하게 전환이 가능하도록 개선했습니다.

협업: 사업부, 개발자(2명)기술 스택: SpringBoot, Hibernate, JPA, Java

8. 클러스터간 PK 중복없이 회사를 이관하기 위한 다우오피스 전체 클러스터 채번 전략 재수립

회사: 다우기술대상 서비스: 다우오피스 SaaS 서비스기여도: 100%

책임

• 운영 배포는 보류된 프로젝트
• 클러스터 단위로 PK Generator를 적용하기 위한 채번 전략 재수립 및 구현
• AS-IS 다우오피스 PK 전략 변경 후 Cloud/VPC 등 환경별 테스트
• PK 마이그레이션 이후 DB에 String 타입으로 저장된 마이그레이션이 불가능한 PK에 내부링크 적용 — 내부링크: 마이그레이션 이전 PK를 담은 Model을 Client에게 전달할 때 마이그레이션 PK로 변경

주요 기여

• Snowflake 기반 분산 PK 비트 단위 정책 수립 (With DBA) — timestamp 41비트, sequence 12비트로 약 69년간 workerId당 1ms당 4,096개까지 중복 없이 사용 가능. workerId 10비트로 클러스터·대형 VPC 고객사 확장 고려
• 클러스터 단위 PK Generator 전략 구현 — 채팅용 Sequence, Table Generator 커스텀 및 Snowflake 구현체 구현. CustomIdentifier 인터페이스·@GenericGenerator 기반으로 클러스터 구동 시 프로퍼티에 따른 PK 전략 적용

상세 설명

배경·수행 — 9개 클러스터(클러스터당 약 8억 PK)·12,000개 고객사 환경에서 클러스터별 회사 PK가 중복 증가해 클러스터 간 회사 이동이 불가했음. 기존 클러스터는 기존 전략을 유지하고 신규 클러스터에만 Snowflake 채번을 적용하는 클러스터별 PK Generator 전략을 설계·구현, 다우메신저·그룹웨어 등 전체 서비스 전수 테스트까지 완료 (사업상 사유로 운영 배포는 HOLD).

이후 — 차세대 다우오피스 개발팀에 인수인계, 본 설계를 기반으로 한 채번 모듈이 다우오피스 4.0에 구현되어 현재 전 모듈에서 운영 중.

협업: DBA, 메일 엔지니어, QA 엔지니어, 백엔드 개발자 다수기술 스택: SpringBoot, Hibernate, JPA, Java, Bitbucket(Git), Jira

9. 복수 클라이언트 확장을 고려한 SSO 연동 표준 서비스 설계 및 개발 (다우오피스 LG 복지몰 오픈)

회사: 다우기술대상 서비스: 다우오피스 외부 클라이언트 연동 서비스기여도: 100%

책임

• 다우오피스와 연동 서비스간 2차 인증을 통한 신뢰성 확보
• 연동 서비스와 LG 복지몰간 SSO 개발
• 고객별 광고성 정보/개인정보 제3자 동의 약관 정보 관리
• 모든 시나리오에 대한 신뢰성 확보를 위해 테스트케이스 및 단위 테스트 작성

주요 기여

• 다우오피스 이용 기업 대상 SaaS 복지몰 오픈
• 인터페이스 기반 설계로 클라이언트별 구현체·외부 클라이언트 정보만 등록하면 연동 가능, 테스트 포함 2~3일 내 신규 클라이언트 SSO 오픈 가능하도록 설계
• 테스트 시나리오·JUnit 단위 테스트 전부 통과까지 반복 검증 — 외부 클라이언트 보안 이슈 2건 발견 후 재개발·재검수로 신뢰성 확보

상세 설명

다우오피스 이용 기업을 대상으로 25년 1월 설 선물 사업을 위해 다우오피스 내 LG 복지몰 오픈

협업: 다우오피스 개발자(1명), 외부 클라이언트 개발자(1명), 기획, 사업기술 스택: SpringBoot, Hibernate, JPA, Java, Vue.js, Bitbucket(Git), Jira