경력
경력
운영 여부, 개인과 팀의 책임 범위, 당시 확인한 한계까지 함께 기록했습니다.
샤플앤컴퍼니
백엔드 개발
운영 중인 현장 관리 서비스에서 배치 재실행과 SQS 메시지 중복 전달을 서로 구분해 처리해야 했습니다. 배치·메일 서버를 분리하고 두 단계에 다른 DB UNIQUE 제약을 적용하기로 판단했습니다. 메일 구조와 보고서 빌더를 구현하고 재실행·재전달 시나리오별 방어 범위를 대조했습니다. Exactly-once 전송을 보장하지 않는 한계를 명시해 실패 지점별 멱등 경계를 나눈 사례입니다.
- 핵심 판단
- 배치 서버와 메일 서버를 SQS로 분리하고 발송 요청과 메시지 소비 단계에 서로 다른 DB UNIQUE 제약을 적용했습니다.
- 검증
- 배치 재실행과 메시지 재전달 시나리오를 분리해 각 UNIQUE 키와 방어 범위를 대조했습니다.
휴니크
개발 리드·백엔드·인프라
레거시 결제 테이블에 상품·이용권·프로모션·회원·수업·주문 책임이 결합된 상황에서 신규 시스템을 개발했습니다. 기존 구조를 복제하지 않고 도메인별 책임을 나눈 별도 Spring 시스템을 선택했습니다. 4인 팀의 개발 리드로 API와 AWS 배포 환경까지 구현했지만 출시 전 종료돼 운영 트래픽에서는 검증하지 못했습니다. 구조 분리의 구현 범위와 운영 성과의 경계를 구분한 사례입니다.
- 핵심 판단
- 기존 구조를 그대로 신규 시스템에 복제하지 않고 도메인별 책임을 분리한 별도 Spring 시스템을 개발했습니다. 기존 회원은 기존 인증 서비스와 연결했습니다.
- 검증
- 주요 어드민·키오스크 API와 프론트엔드·백엔드 배포 환경까지 구현했습니다. 다만 프로젝트가 출시 전에 종료돼 실제 사용자 트래픽에서는 검증하지 못했습니다.
호두랩스
결제 API 및 복구 배치 개발
PG와 인앱 결제를 하나의 API 흐름으로 처리하고 외부 승인과 내부 재화 제공 상태를 분리했습니다. PURCHASED 상태와 Redis 정보가 남아 있는 미완료 주문을 식별해 다시 처리하는 복구 배치를 구현했습니다.
- 핵심 판단
- 주문을 REQUESTED·PURCHASED·COMPLETED로 나누고, PURCHASED 상태와 Redis 정보가 남은 주문만 복구 배치가 재처리하도록 했습니다.
- 검증
- 주문 상태, Redis TTL과 DB 제약이 담당하는 범위를 대조해 정상 처리와 재처리 조건, 처리하지 못하는 실패를 구분했습니다.
지투이
애플리케이션·백엔드 개발
응급의료 키오스크 앱과 공공 포탈을 개발하며 인증·세션·오류·권한을 화면마다 반복하지 않아야 했습니다. 공통 애플리케이션 기능과 메뉴별 권한으로 분리하기로 판단했고, Flutter 앱과 Spring Boot API를 담당해 적용 경로를 확인했습니다. 전체 보안 정책 설계가 아닌 애플리케이션 경계에서 반복 책임을 분리한 사례입니다.
- 핵심 판단
- 화면별로 반복하지 않도록 인증·세션·전역 오류·감사 로그를 공통 기능으로 분리하고 Spring Boot API와 연결했습니다.
- 검증
- 인증 상태와 오류 처리를 공통 경로로 적용하고, 메뉴별 권한에 따라 접근 가능 범위를 구분했습니다.