트레드링스
Backend Engineer · Manager해운 물류 SaaS의 데이터 수집, 선적 및 선박 추적, 광고, CRM 연동 등의 백엔드 업무 진행
BACKEND ENGINEER · ANYANG
복잡한 데이터 흐름을
운영 가능한 서비스로 만듭니다.
외부 API, EDI, Webhook, 크롤링처럼 통제하기 어려운 시스템을 안정적인 데이터와 API로 바꿔온 6년 차 Java·Kotlin 백엔드 개발자 이도훈입니다.
External systemsAPI · EDI · Webhook
Backend platformJava · Kotlin · Spring
Product dataReliable · Observable
전체 흐름기능보다 서비스 전체를 봅니다
신뢰 가능한 데이터정합성과 복구 가능성을 설계합니다
점진적 전환운영을 유지하며 구조를 개선합니다
운영 책임배포 이후의 문제까지 추적합니다
01 RESUME
기능 구현 이전에, 서비스의 전체 흐름을 봅니다.
도메인과 기존 구조를 빠르게 파악하고 반복 장애의 원인을 데이터 구조와 처리 흐름에서 찾습니다. 설계부터 정합성 검증, 배포와 모니터링까지 제품의 전체 수명주기를 경험했습니다.
LanguageJava · Kotlin · TypeScript
BackendSpring Boot · JPA · QueryDSL
DataMSSQL · Cosmos DB · Redis
PlatformAzure · AKS · Kubernetes · Docker · Service Bus
경력2019 — 2026
프리랜서
Full-stack Engineer땡겨요(배달앱) 백오피스 API 및 화면 개발
티웹
Software EngineerJava 기반 업무 시스템과 서비스 기능 개발
드림시스
Software Engineer기업용 웹 시스템 개발 및 유지보수
02 CAREER
경력기술서
개별 프로젝트 목록이 아니라 트레드링스에서 맡았던 책임 범위와 일하는 방식을 정리했습니다.
데이터 수집·정규화 플랫폼 개발
통제하기 어려운 외부 데이터를 제품에서 신뢰할 수 있는 공통 데이터로 만드는 업무를 담당했습니다.
- 외부 API, EDI와 웹 크롤링 데이터를 공통 도메인 모델로 변환
- 원천 데이터와 서비스용 집계를 분리하고 중복·누락·정합성 검증
- 실패 유형을 분석해 재시도, 구간 재수집과 운영 모니터링 체계 구축
Ownership신규 수집 구조 설계부터 구현, 데이터 검증과 운영까지 담당
선적 추적 제품과 고객사 API 개발
컨테이너와 선박 추적 데이터를 SaaS 내부뿐 아니라 고객사 서비스에서도 사용할 수 있도록 확장했습니다.
- 선적·선박 추적, 스케줄, 정시성과 지도 조회 API 개발
- White Label, Plugin과 Partner API의 고객사별 제공 조건 구현
- 플랜과 사용자 상태에 따른 기능 접근 정책을 제품 전반에 적용
Ownership정책과 데이터 흐름 분석, API 설계, 프론트엔드·QA 연동 조율
비즈니스 운영 백엔드와 외부 시스템 연동
광고, CRM과 구독 정책처럼 운영 조직이 사용하는 기능을 제품 흐름과 연결했습니다.
- 광고 상품·노출·집계와 백오피스 관리 기능 개발
- CRM Webhook과 내부 데이터의 생성·변경·복원 동기화
- 플랜·Feature·구독 상태에 따른 정책과 외부 시스템 예외 처리
Ownership요구사항 구체화, 도메인 모델과 API 설계, 일정 산정과 배포 조율
운영 안정화와 점진적 구조 개선
운영 중인 서비스를 멈추지 않으면서 장애 원인을 추적하고 구조를 단계적으로 개선했습니다.
- Datadog 로그 기반 서비스 오류 원인과 영향 범위 분석
- 기존·신규 데이터 비교, 마이그레이션과 API 전환 절차 수립
- Kubernetes 배포, 모니터링 정리와 기술·인수인계 문서 작성
Ownership영향 범위와 일정을 산정하고 QA·배포 이후의 운영 문제까지 추적
03 SELECTED WORK
문제와 판단이 보이는 포트폴리오
수치뿐 아니라 왜 바꿨고, 어떤 기준으로 설계했는지 정리했습니다.
Key impact
일 1.8만 → 4.5만 건 증가수집량 2.5배 증가운영 PC 12대 → VM 1대 감소
Challenge
개선 전
IP 차단, CAPTCHA, 브라우저 중단과 PC 장애로 수집량이 일정하지 않았고 누락 구간 복구에도 많은 운영 시간이 들었습니다.
Outcome
개선 후
처리량을 늘리면서 운영 장비와 장애 요인을 줄였습니다. 실패를 발견하고 재처리할 수 있는 경로까지 함께 설계해 새 구조를 운영자가 신뢰할 수 있게 했습니다.
My contribution
기술적 판단과 기여
- 01
실패 사유별 메시지 처리, 저장 재시도와 특정 구간 재수집 API를 먼저 구축해 기존 구조를 안정화
- 02
서비스가 실제 사용하는 BL·컨테이너·기업별 집계 항목을 기준으로 외부 API와 흐름 재설계
- 03
원천 수집과 서비스용 집계를 분리하고 중복 BL 제거, 건수 비교와 정합성 검증을 처리 과정에 포함
Stack
Java · NestJS · Azure Service Bus · VM · Azure
Key impact
약 20개 테이블 → 1 문서기존·신규 데이터 비교 검증gRPC → REST
Key impact
광고 구좌 4개 운영CTR 0.31% · 0.36% 측정신규 광고 계약 발생
Key impact
25개 이상 선사6개 터미널일 5.9만 대상 · 1.7만 유효 스케줄
+ MORE WORK
CRM 리드 수집·동기화 자동화
Meta, Calendly, 내부 서비스와 Pipedrive 사이의 리드 흐름을 실시간으로 연결
- Pipedrive API Client와 생성·수정·삭제 Webhook 처리
- Update Upsert, Custom Field와 삭제·복원 예외 대응
- Deal·Lead·Organization 관계와 초기 데이터 매핑
수집 시스템 모니터링·배포 자동화
크롤러의 수집 상태 확인부터 Slack 알림, Docker 기반 빌드와 Azure VM 배포까지 운영 흐름 정리
- FCL·Vessel·Terminal 크롤러의 수집 상태와 작업 현황 모니터링
- 모니터링 애플리케이션의 Slack 직접 알림과 발송 주기 개선
- Dockerfile·Azure DevOps 파이프라인 구성과 배포 오류 대응
선박 정시성 데이터 서비스
선박 스케줄과 ETA 데이터를 정시성 정보로 가공해 기존 추적 제품에 제공
- 선박 스케줄과 ETA 기반 정시성 판단 데이터 처리
- Azure Data Factory를 이용한 초기 데이터 구성과 조회 API 개발
- 초기 수집 데이터 증가 원인 분석과 기존 추적 서비스 연동