Portfolio
택배 연동 게이트웨이
STL내부 시스템마다 따로 있던 택배 연동(송장 발급, 라벨, EDI 전송, 배송상태 수집)을 하나로 모은 연동 서비스
- 단독 구축, 착수 8일 만에 운영 전환
- 운영 3주간 21,161건 처리
- 포트/어댑터 구조로 택배사 확장 대응
개요
내부 시스템 3곳이 송장 발급, 라벨 출력, EDI 전송, 배송상태 수집을 각자 구현하고 있었음. 택배사가 규격을 바꾸면 모든 시스템을 고쳐야 했고, 택배사 계정과 접속 IP 등록도 시스템마다 따로 관리해야 했음.
역할
택배 연동 게이트웨이 신규 구축. 설계 문서 작성부터 개발, 연동 시스템의 게이트웨이 전환, 운영까지 단독으로 담당.
담당 업무
- 송장번호 발급과 라벨 PDF 생성
- 택배사 EDI 전문 생성 및 SFTP 전송
- 배송상태 수집 및 이벤트 발행
- 유통물류 관리 시스템의 택배 연동을 게이트웨이로 전환
주요 성과
연동 일원화와 확장 구조
- 택배사 연동부를 포트/어댑터로 분리해, 고객사마다 다른 택배사를 쓰더라도 어댑터 추가만으로 대응 가능한 구조
- 포트는 바뀔 수 있는 외부 연결 지점(택배사, 파일 저장소, 이벤트 발행 등)에만 두어 구조를 단순하게 유지
- 택배사 계정, 접속 IP, 호출 한도(초당 1건)를 게이트웨이 한 곳에서 관리
파일 전송 신뢰성
- 임시 파일명으로 SFTP 업로드 후 rename해, 수신 측이 업로드 중인 파일을 읽지 않도록 처리
- 재시도 전에 서버의 파일 상태를 확인해 중복 전송 방지
- 전송 작업이 겹치지 않도록 DB 기반 분산락(ShedLock) 적용, Redis 장애와 무관하게 동작
인코딩 정규화와 사전 차단
- 택배사 EDI는 1,900바이트 고정길이 레코드라, MS932로 표현할 수 없는 문자 하나가 레코드 전체를 밀어내는 구조
- 보이지 않는 문자 제거, 혼동 문자 치환, 인코딩할 수 없는 문자의 NFKC 정규화 적용
- 남는 오류는 주문 수집 시점의 검증 API에서 차단해 전송 단계 실패를 사전에 방지
이벤트 발행
- DB를 원장으로 두고 아웃박스 패턴으로 Redis Streams에 이벤트 발행
멀티테넌트 구조 전환
STL단일 고객사용 유통물류 시스템을 여러 고객사가 함께 쓰는 구조로 전환
- 테이블 91개 고객사 격리
- 격리 누락을 PR 단계에서 자동 검출
개요
고객사마다 시스템을 한 벌씩 운영해 서버 비용과 기능 수정이 고객사 수만큼 늘어나는 구조였음. 하나의 시스템으로 합치려면 고객사 간 데이터가 섞이지 않는다는 것을 보장해야 했음.
역할
기존 단일 고객사용 시스템을 기반으로 멀티테넌트 구조 전환을 단독 진행. 격리 설계, DB 마이그레이션, 검증 체계 구축까지 담당.
담당 업무
- 고객사 격리 설계 및 테이블 마이그레이션
- JPA, MyBatis 조회 경로 전반의 고객사 조건 적용
- 접속 도메인 기반 고객사 판별과 로그인 연동
- 격리 검증 테스트와 CI 구축
주요 성과
행 단위 고객사 격리
- 테이블 91개에 고객사 구분을 적용하고, JPA는 트랜잭션 시작 시점에 고객사 필터가 자동으로 켜지도록 구성 (인터셉터, OSIV 방식은 비교 후 제외)
- MyBatis 조회 55곳의 고객사 조건 적용 방식을 하나로 통일
- 고객사를 정하지 못한 요청은 조회 자체를 막도록 설계
- 운영자도 반드시 고객사 하나를 선택하도록 해, 조회 조건이 빠지더라도 고객사 데이터가 섞일 수 없는 구조로 설계
격리 검증 체계
- H2는 MySQL 전용 함수를 처리하지 못해, Testcontainers 기반 실제 MySQL로 격리 테스트
- 매퍼 SQL 700개에 고객사 조건을 적용한 상태로 전수 문법 검사
- 새로 깨진 SQL이 생기면 실패하는 기준선을 두고, PR마다 자동 실행
일본 유통물류 관리 시스템
STL국내 화장품 브랜드사 등 고객사의 일본 물류센터 운영을 위한 유통물류 관리 시스템
- 주소 검증 통과율 71.10% → 99.97%
- DB CPU 100% 장애 원인 쿼리 1.1s → 0.1s 미만
- 커머스 채널 주문 처리 주기 일 1회 → 5분
개요
일본 현지 물류센터의 주문, 재고, 출고를 관리하는 시스템. 현지 창고 오픈에 맞춰 주문과 출고 도메인을 구축했고, 운영 중 드러난 주소 검증 정확도와 조회 성능 문제를 개선했음.
역할
일본 현지 물류 운영 프로세스 분석부터 주문, 출고 도메인 설계와 개발, 운영 전환까지 담당. 운영 이후 주소 검증, 조회 성능, 외부 커머스 채널 연동을 개선.
담당 업무
- 일본 현지 물류 운영 프로세스 분석 및 요구사항 정의
- 주문 및 출고 도메인 백엔드 설계 및 개발
- 주소 검증 방식 전환
- 실행 계획 분석 기반 성능 개선
- 커머스 채널 주문 수집과 발송 통보 연동
주요 성과
주소 검증 정확도 개선
- 외부 업체 조회 방식은 같은 주소를 반복 조회하고, 외부 장애 시 검증이 멈추는 구조였음
- 일본 우편번호 마스터 대조 방식으로 전환하고, 표기 차이(이체자, 장음 기호, 정령시 구 생략 등) 정규화 규칙 정리
- 두 고객사 시스템이 같은 판정 로직과 회귀 테스트를 공유하도록 정리
- 실주문 31,925건 기준 통과율 71.10% → 99.97%
실측 기반 성능 개선
- 실행 계획 분석으로 원인을 확인한 뒤 조인 순서 고정, 건수 조회 분리, 일괄 조회 적용
- DB CPU 100% 장애 원인 쿼리 1.1~1.4s → 44~96ms
- 출고대기 조회(필터 8종 합계) 10.5s → 2.6s
- 주문관리 건수 조회 1,750ms → 177ms
- 엑셀 업로드 메모리 1,578MB → 155MB (스트리밍 파싱 적용)
커머스 채널 주문 연동
- 하루 1회이던 자동 출고요청을 5분 간격 회차로 바꾸고, 100건 단위로 커밋해 실패가 전체로 번지지 않도록 처리
- 다중 인스턴스 환경에서 발송 통보가 두 번 나가지 않도록 선점 갱신과 유니크 키로 중복 방지
- 주문 저장 DB 왕복 2,644 → 28회 (661건 기준)
일본 통관 시스템
STL포워딩 시스템 연동 기반 일본 통관 프로세스 관리 시스템
- 주소 영문 변환 오류율 2.4% → 0.35%
- 주소 변환 500건 4분 36초 → 16초
개요
포워딩 시스템에서 수신한 에어웨이빌, 주문 데이터를 기반으로 통관 프로세스(통관대기 → 통관입고 → 수입신고 → 검사처리 → 통관출고)를 관리하는 시스템. 통관 서류용 수하인 주소를 일본어에서 영문으로 변환하는 과정의 오류와 처리 시간이 문제였음.
역할
통관 도메인 설계부터 API 개발까지 담당하고, 주소 영문 변환의 정확도와 처리 속도를 개선.
담당 업무
- 통관 도메인(에어웨이빌, 수입신고) 설계 및 API 개발
- 주소 영문 변환과 검증 로직 개선
- 주소 변환 병렬 처리 구조 설계
주요 성과
주소 영문 변환 정확도 개선
- Google Address Validation API 호출 전 번지 구분자를 정규화하고, 영문 지명이 나오지 않으면 우편번호로 다시 조회
- 일본우편 공식 로마자 데이터를 적재해 지명 표기를 보정
- 5,976건 기준 영문 변환 오류율 2.4% → 0.35%
주소 변환 병렬 처리
- Google API 호출을 Kotlin Coroutines로 바꾸고, API 호출과 DB 반영 단계를 분리
- API 분당 호출 한도(3,000건)에 맞춰 동시 처리 수를 5 → 30으로 조정해 500건 4분 36초 → 16초
- 두 건을 동시에 변환할 때 발생한 DB 데드락을 결과 저장 트랜잭션 분리로 해결
자사 정산 시스템
STL출고 데이터 기반 정산 프로세스 자동화 시스템
- 데이터 수집 성능 90% 개선 (30분 → 3분)
- 출고 스케줄러 CPU 사용률 90% → 20% 최적화
- 정산 프로세스 완전 자동화
개요
기존 정산 프로세스가 수작업으로 진행되어 운영 부담이 컸으며, 외부 시스템에서 출고 데이터 수집 시 블로킹 I/O로 인해 5만 건 기준 30분이 소요되는 성능 문제 존재.
역할
대용량 출고 데이터를 기반으로 정산 프로세스를 자동화하는 시스템 개발. 외부 시스템에서 데이터를 수집하고 정산 처리하는 전체 파이프라인을 담당.
담당 업무
- 대용량 출고 데이터 수집 스케줄러 개발
- 정산 시스템 안정화 및 프로세스 자동화
- WebFlux 기반 비동기 처리 도입
주요 성과
데이터 수집 성능 90% 개선
- 외부 API의 1회 호출당 99건 제한으로 5만 건 수집 시 500회 이상의 API 호출 필요
- 성능 개선 단계별 발전 과정:
- 1단계: 동기 순차 방식 - 블로킹 I/O로 30분 소요
- 2단계: ExecutorService 멀티스레드 - 병렬 처리로 속도는 개선되었으나 스레드 생성/관리 오버헤드 존재
- 3단계: WebFlux 비동기 병렬 - 논블로킹 I/O로 최종 3분 달성
- flatMap concurrency 30으로 설정하여 외부 API 서버 부하를 고려하면서 병렬 처리
- 5만 건 기준 30분 → 3분으로 단축 (90% 개선)
정산 프로세스 자동화
- 수작업 정산 프로세스 완전 자동화
- JPA에서 JdbcTemplate Batch Insert로 전환하여 대량 저장 성능 개선
- 출고-비용 OneToMany 관계에서 PK 생성 시점 문제로 배치 처리 불가 → 고유 ID를 별도 생성하여 배치 저장 구현
- 일/월 단위 대용량 데이터 안정적 처리
운영 환경 CPU/메모리 오버헤드 최적화
- 개발 단계에서 concurrency 30으로 성능 목표를 달성했으나, 특정 기간 출고 집중(일 최대 30만 건) 시 CPU 사용률 90% 이상, 메모리 오버헤드 발생
- 원인 분석: 단일 flatMap 구조에서 30개 동시 호출 시 JSON 역직렬화와 객체 변환이 4코어에서 경합, 전체 출고 데이터를 메모리에 로딩하는 비효율적 중복 체크
- flatMap 구조를 클라이언트별 × 청크별 2단계로 분리하고, 중복 체크를 IN절 기반 DB 조회로 변경
- CPU 평균 사용률 90% → 20% 수준으로 개선
출고 스케줄러 CPU 사용률 추이 (배포 전후)
B2B/B2C 유통 물류 통합 플랫폼
팀프레시신규 서비스 출시와 아키텍처 전환
- 미오출률 1% 미만 개선
- 센터 귀책비용 70% 감소
- 동시성 이슈 해결로 데이터 정합성 확보
개요
멀티 인스턴스 환경에서 재고, 출고 등 공유 자원에 대한 동시 접근으로 중복 처리 및 데이터 불일치 문제 발생. 또한 서비스 클래스가 과도한 책임을 지고 외부 인프라에 강하게 결합되어 단위 테스트 작성이 어려운 상황.
역할
B2B 유통, 물류 통합 신규 서비스 출시를 위한 시스템 개발. 안정적인 서비스 제공을 위한 서버 아키텍처 설계부터 물류/배송 프로세스 개발, 아키텍처 전환 및 테스트 코드 도입까지 담당.
담당 업무
- 신규 서비스 출시 - B2B 유통, 물류 통합 신규 서비스 출시
- 서버 아키텍처 설계 - 안정적인 서비스 제공을 위한 서버 설계
- 물류/배송 프로세스 개발 - 안정적인 물류, 배송 프로세스 개발 및 리팩토링
- 아키텍처 전환 - 유지보수성과 테스트 용이성을 높이고 개발 생산성 향상
- Spring Batch 기반 통계 데이터 처리 - 실무자 및 운영팀의 수기 작업 자동화
주요 성과
센터 운영 안정화
- 미오출률 1% 미만으로 개선
- 센터 귀책비용 70% 감소
통계 데이터 자동화
- 일/월 단위 통계 제공으로 운영팀 공수 감소
데이터 정합성 확보
- 동시성 이슈 해결을 통한 데이터 정합성 확보
- 수기 작업 감소 및 개발자 운영 리소스 감소
아키텍처 전환
- 도메인 결합도 완화, 테스트 구조 개선
- 구조적 장점을 팀에 전파, 타 도메인 확산 기반 마련
새벽시장
팀프레시B2C 식자재 유통 플랫폼
- 지연 프로젝트 3개월 내 안정적 오픈
- 결제 시스템 모듈화 및 구조 개선
개요
일정 지연 상태였던 프로젝트에 중간 투입. 기존 결제 시스템이 결제 수단별로 분리되지 않아 유지보수와 기능 확장이 어려운 구조였음.
역할
B2C 식자재 유통 플랫폼 신규 시스템 개발. 개발 리드 및 백엔드 개발을 담당하여 신규 서비스 출시와 주문/결제 기능 리팩토링 및 PG 연동을 수행.
담당 업무
- 신규 서비스 출시 - B2C 유통, 물류 통합 신규 서비스 출시
- 주문/결제 기능 리팩토링 및 PG 연동 - 안정적이고 확장 가능한 주문/결제 시스템 구현
주요 성과
지연된 프로젝트 오픈
- 일정 지연 상태였던 프로젝트에 중간 투입되어 약 3개월 내 안정적 오픈 달성
- 백엔드, 앱, 프론트, 운영팀 등 내부 팀과의 커뮤니케이션과 일정 조율을 직접 리드
결제 시스템 구조 개선
- 결제 수단별 API를 모듈화해 도메인 책임을 분리하고 기능 추가나 수정이 유연한 구조로 개선
- 자연키 기반 테이블을 대체키 기반으로 전환해 요구사항 확장에 유연하게 대응
- PG 연동 로직을 직접 구현해 외부 결제 시스템과 안정적으로 연결
팀플레이스
팀프레시B2B 유통 플랫폼
- 통계 생성 99.6% 개선 (20분 → 5초)
- 주문 처리 성능 개선으로 수 배 트래픽 대응
개요
주문 집중 시간대에 MsSQL의 락 경합과 데드락이 발생하여 CPU/메모리 사용률 급증, 서비스 응답 지연 및 중단 장애가 반복되는 상황. 또한 통계 데이터 생성에 20분이 소요되어 운영팀의 업무 효율이 저하됨.
역할
기존 B2B 유통 플랫폼의 개발 및 운영. 백엔드와 프론트엔드 개발 및 운영을 단독으로 담당하며 통계 조회 및 다운로드 개선, 주문 기능 성능 개선, 전반적인 프로덕트 성능 개선을 수행.
담당 업무
- 통계 조회 및 다운로드 개선 - 통계 조회 및 엑셀 다운로드 기능 리팩토링, 월별 통계 데이터 생성 기능을 20분에서 5초로 리팩토링
- 주문 기능 성능 개선 - 특정 시간대 주문 폭주 문제 해결, 일 주문 금액 및 건수 수배 수준의 주문증가에도 성능 이슈 없도록 개선
- 프로덕트 성능 개선 - 코드 리팩토링 및 쿼리 튜닝으로 전체적인 서비스 성능 향상
주요 성과
통계/지표 성능 개선 및 자동화
- 월별 통계 생성 속도를 20분 → 5초로 단축하여 운영팀 업무 효율을 향상
매출단가 예약 기능 개발
- 예약 단가 설정 기능을 새로 도입하여 수기 설정 부담 및 휴먼 에러로 인한 매출 손실을 방지
주문 처리 성능 개선
- 주문 처리 병목을 제거하는 리팩토링을 통해, 기존 대비 수 배 수준의 주문 증가 상황에서도 안정적으로 처리 가능하도록 개선
서비스 전반 성능 개선
- 코드 최적화 및 쿼리 튜닝을 통해 전체 프로덕트의 응답성과 안정성 향상
- 고객사 이탈 방지 및 만족도 개선에 기여
건강비밀
와이즈셀렉션개인 맞춤 영양제 추천 플랫폼
- 자가진단 응답 98% 개선 (60초 → 1초 이내)
- Kafka 기반 CDC 파이프라인 구축
개요
MSA 환경에서 서비스 간 통신이 모두 동기 방식으로 구현되어 응답 지연 이슈 발생. 협업사 DB 수작업 수정에 따른 운영 리스크 존재. 또한 자가진단 결과 제공에 최대 60초가 소요되어 사용자 이탈 발생.
역할
개인 맞춤형 영양제 자가진단 서비스 개발 및 운영. 백엔드와 프론트엔드 개발 및 운영을 담당하며 리워드 서비스 개발, 자가진단 서비스 성능 향상, 협업 데이터 인프라 구축을 수행.
담당 업무
- 리워드 서비스 개발 - 신규 서비스 런칭을 통한 리텐션 및 재구매율 증가
- 자가진단 서비스 성능 향상 - 고객 경험 개선을 위한 자가진단 서비스 성능 개선
- 협업 데이터 인프라 구축 - 협업 데이터 실시간 처리 기반 마련
주요 성과
유지보수 및 성능 개선
- 통계 페이지 시각화 개선을 통해 운영팀의 데이터 분석 효율 향상
- 쿠폰 및 마일리지 지급 기능을 안정화하여 프로모션 운영 리스크 완화
- 쿼리 튜닝을 통해 지표 집계 및 알고리즘 처리 속도 개선
Kafka 기반 비동기 통신 인프라 및 CDC 인프라 구축
- 기존 MSA 환경에서 동기 통신으로 처리되던 서비스 흐름을 Kafka를 통해 비동기로 처리
- Kafka 기반 CDC 파이프라인을 통해 공통 데이터를 단일 발행하고, 협업사별로 독립 처리할 수 있는 유연한 연동 구조를 구현
자가진단 서비스 성능 개선
- 쿼리 리팩토링 및 서비스 로직 리팩토링을 통해 기존 60초가 소요되던 자가진단 결과 제공 시간을 1초 이내로 단축
- 사용자 체감 속도를 크게 개선하고, 서비스 만족도를 높임
Kafka CDC 파이프라인