다양한 도메인을 빠르게 이해하고,
AI로 비즈니스 문제를 제품화합니다.

판매 사고 가능성이 높은 사용자도 일반 판매자와 같은 기준으로 거래할 수 있어 고액권과 C2C 거래에서 회사의 손실 노출이 커지고 있었습니다.

판매등급별 한도, 판매차감예정금액, 고액권·C2C 제한, 임시한도 심사와 정책 예외를 모델링했습니다. 판매신청·판매확정·자동 구매확정마다 상태와 한도를 다시 검증하고 신규 백엔드·레거시·CMS에 같은 정책을 적용했습니다.

결제 상태 변경과 SQS 발행이 분리돼 메시지 발행에 실패하면 결제는 완료됐지만 어떤 상품권을 다시 발송해야 하는지 찾기 어려웠습니다.

결제·상품 상태와 Outbox record를 같은 트랜잭션에 저장하는 Transactional Outbox 구조를 제안·설계했습니다. 공통 relay 구현을 맡은 동료를 멘토링하고 리뷰했으며, 판매콘 상태 동기화 등 실제 도메인 이관에는 직접 적용했습니다.

특정 시간대마다 writer RDS CPU가 80% 이상으로 올라가 라이브 API 응답에 영향을 줄 위험이 있었습니다.

Performance Insights의 Top SQL과 Kubernetes Job 실행 이력을 같은 시간대에 비교해 상품권 만료·재고·정산 배치가 집중되는 구간을 찾았습니다. 실행 시간, chunk size, concurrency와 인덱스를 조정했습니다.

뱅크샐러드 사용자가 NCNC 앱 밖에서 상품을 조회하고 구매한 뒤 보유 상품권과 환불 상태까지 확인할 수 있는 별도 거래 흐름이 필요했습니다.

제휴 TF를 리드해 API Key 인증과 전용 사용자 분리부터 상품·재고·검색·장바구니·주문·결제·취소·환불 API를 설계하고 구현했습니다. Redis, private CDN, NICE 결제 키와 Kubernetes 배포 설정까지 함께 구성했습니다.

주문·결제·상품권·CMS와 cron·consumer가 여러 Express 저장소에 흩어져 모델 변경의 영향 범위를 확인하기 어려웠습니다.

기존 API 응답과 배포 단위를 확인한 뒤 NestJS·Turborepo로 도메인별 점진 이관을 진행했습니다. 내콘함·판매콘·사용자 API와 리워드·요청 정리 배치를 신규 서버로 옮기고 Native 호출과 Kubernetes CronJob을 함께 전환했습니다.

리워드 이벤트가 일회성 참여로 끝나지 않도록 반복 참여와 재방문을 유도하고 효과를 확인할 수 있는 장치가 필요했습니다.

Claude Code와 Codex로 기존 적립 데이터와 화면 구조를 분석하고 집계 규칙과 예외를 정의했습니다. NestJS API·월간 집계 cron·CMS·Next.js 화면·Amplitude 이벤트와 실험 variant를 구현하고 Kubernetes에 배포했습니다.

기존 제휴몰은 일반 상품 중심으로 구성돼 C2C 상품의 재고, 구매 권한, 카드·니콘머니 결제와 환불 정책을 그대로 적용할 수 없었습니다.

일반·C2C 상품의 통합 최저가와 옵션 결정, 주문 단계 권한·재고 검증, NICE 카드결제와 니콘머니 결제, 구매취소·부분환불을 연결했습니다. 결제 후 내부 주문 생성에 실패하면 니콘머니를 복구하고 중복 승인·콜백 경쟁을 막는 보상 로직을 적용했습니다.

별도 자동화 서버에서 주문 처리, 재고·품절 동기화, 클레임과 지연 주문 취소가 실행돼 장애 범위와 중복 실행을 통제하기 어려웠습니다.

5개 작업을 NestJS 프로그램으로 이관하고 FOR UPDATE SKIP LOCKED와 MySQL leader election으로 작업 소유권을 제어했습니다. 외부 API에는 초당 2건 제한, 429 응답의 3·6·12초 백오프와 인증 만료 시 토큰 갱신을 적용했습니다.

장기 미연락 판매자를 자동 등록하는 배치가 판매자마다 트러블과 상태를 반복 조회해 처리 대상이 늘수록 쿼리 수도 함께 증가했습니다.

판매자별 조회를 집합 쿼리로 바꾸고 신규 판매자를 1,000건 단위로 bulk insert했습니다. 자동 탐지부터 담당자 일괄 배정, 처리 상태·이력과 TheCheat 사기주의정보 등록·해제를 CMS에 연결했습니다.

회계감사와 재고 확인을 위해 수천만 건의 상품권 거래 데이터를 날짜·상품별로 반복 집계해야 했습니다.

3,500만 건 이상 cons 데이터를 약 60만 건의 일별 상품 통계로 집계하고 조회용 snapshot DB와 저장용 운영 DB를 분리했습니다. 1,000건 단위 chunk와 idempotent UPSERT를 적용하고 CMS 페이지네이션·합계·엑셀 다운로드를 구현했습니다.

네이버 가격비교에 상품을 노출하려면 내부 상품·재고·할인 정책을 네이버 EP 규격에 맞춰 정기적으로 제공해야 했습니다.

전체 EP와 요약 EP 생성 cron을 개발하고 상품 노출, 가격, 할인율과 C2C 포함 정책을 공통화했습니다. 파일 저장과 배포 인프라, CMS 조회와 웹 유입 파라미터까지 연결했습니다.

아키텍처, API와 운영 절차가 여러 저장소와 문서에 흩어져 레거시 영향 범위와 장애 대응 방법을 찾는 데 시간이 들었습니다.

아키텍처·API·DB·인프라 문서를 Markdown vault로 정리하고 Slack Bot, Claude Code와 로컬 MCP를 연결했습니다.

여러 모바일 단말의 응답을 기다리는 구조는 사용자 증가에 따라 전달 대상과 네트워크 응답 의존성이 함께 커졌습니다.

근접 사용자 탐색과 실제 인증 검증 책임을 분리하고, 암호화된 인증 기준 데이터를 키오스크에 미리 준비해 장치 내부에서 비교하는 흐름을 제안·설계했습니다.

하나의 생체인증 결과가 출입 제어, 근태 기록과 결제 처리까지 각 시스템의 상태로 정확하게 이어져야 했습니다.

NestJS 기반 사용자·키오스크 인증, 출입·근태·결제 API와 React 관리자를 개발했습니다. Firebase RTDB·MQTT로 서버·키오스크·IoT 상태를 동기화하고 ESP32 기반 스피드게이트와 도어락 통신을 구현했습니다.

Stored Procedure에 비즈니스 로직이 집중돼 변경 영향도 파악과 개별 배포가 어려웠고 C·Java 외부 SDK 제약도 핵심 서버에 섞여 있었습니다.

비즈니스 로직을 NestJS 애플리케이션과 RDS로 옮기고 C·Java SDK는 별도 Spring Boot 연동 서버로 분리했습니다. 사용자·키오스크 서비스를 ECS/Fargate에 나누고 GitHub Actions·CodeDeploy 배포 흐름을 구축했습니다.

로그인, 생체인증, 결제, FCM과 외부 본인인증이 여러 시스템을 거쳐 장애가 발생한 단계를 한 곳에서 확인하기 어려웠습니다.

로그인·결제·transaction·오류·FCM·landmark·NICE 인증 이력을 MongoDB에 유형별로 저장하는 공통 로깅 모듈을 만들었습니다. AES 암호화 유틸과 NICE·UseB 외부 인증 모듈도 분리했습니다.

백엔드, 프론트엔드와 Windows 클라이언트가 함께 개발해 우선순위와 인터페이스 기준이 없으면 각 애플리케이션의 일정이 쉽게 어긋날 수 있었습니다.

6명의 일정과 우선순위를 조율하고 Jira 스프린트, 코드 리뷰, Git branch·commit 기준과 인터페이스 문서화를 운영했습니다.

증권사마다 응답 형식과 계좌·주문 상태, 실패 사유가 달랐습니다.

신한·NH·KB·삼성증권의 차이를 adapter 계층에서 흡수하고 내부 상태와 API 계약을 표준화했습니다.

외부 증권사 확인, 보상 지급과 알림이 한 요청에 묶이면 지연과 중복 지급 위험이 커졌습니다.

총 5회의 이벤트에서 참여 조건 검증, 계좌 상태 확인, 보상 지급과 알림을 SQS 기반 후속 처리로 분리했습니다.

사용자가 보고 있지 않은 종목 데이터까지 전달돼 불필요한 전송과 서버 부하가 발생했습니다.

Socket.IO 채널을 종목 구독 단위로 나누고 Redis로 서버 간 데이터를 공유했습니다.

초기 제품 검증을 위해 Android 앱이 필요했지만 별도 앱 개발 리소스가 부족했습니다.

계좌 개설, 종목 조회와 매매 화면을 Android(Java)로 구현하고 백엔드 API까지 연결했습니다.

공장마다 설비와 공정 데이터의 형태가 달랐고 현장 담당자는 설비 상태와 생산 이력을 전화와 메신저로 확인했습니다.

공장별 공정 이력을 DynamoDB에 유연하게 저장하고 생산·재고·주문·품질 데이터를 공통 API 형태로 제공했습니다. WebSocket 기반 실시간 대시보드도 구현했습니다.

일정 시간 요청이 없던 Lambda의 첫 실행이 약 600ms까지 지연됐습니다.

EventBridge warm-up 트리거를 적용해 실행 환경이 주기적으로 유지되도록 구성했습니다.