성진혁

재시도가 중복 과금이 되지 않도록 — API Key 발급부터 사용량 계량, 정산 원장까지 돈이 걸린 경계를 검증하는 멀티테넌트 게이트웨이

• 클라이언트 재시도·네트워크 중복 전송이 그대로 중복 과금으로 이어질 수 있다

  → 체크 150/150 통과 · HTTP 실패 0건 · 중복 계량 0건 (3회 모두)

• PG webhook은 재전달·순서 뒤바뀜·위조가 전제 조건이다

  → duplicate delivery가 결제 상태를 두 번 바꾸지 않음을 통합 테스트·k6 branch로 검증

• 환불·조정이 섞이면 "지금 잔액이 왜 이 값인지"를 추적할 수 없게 된다

  → 환불 흐름 포함 원장 정합성을 Testcontainers 통합 테스트로 검증

100명이 같은 좌석에 몰려도 중복 판매 0건 — 락 전략 3종을 같은 조건에서 실측 비교한 좌석 예약 시스템

• 동일 좌석에 동시 예매가 몰리면 중복 판매(oversell)가 발생할 수 있다

  → 100 VU 동일 좌석 경합에서 3전략 모두 성공 1건·oversell 0건, p95는 낙관 106ms / Redis 145ms / 비관 215ms

• 서로 다른 좌석을 예매해도 낙관적 락 성공률이 40%로 무너졌다

  → 분산 예약 성공률 비관 100% vs 낙관 40%를 근거로, 공유 카운터가 있는 모델에서의 전략별 트레이드오프를 문서화

• 예약 확정 이벤트가 브로커 장애 시 유실될 수 있다

  → Outbox 실패/재시도와 DLT replay를 Testcontainers 통합 테스트로 검증 (OutboxIntegrationTest, KafkaDltReplayIntegrationTest)

"화면에 보였다"와 "실제 저장됐다"를 구분하는 채팅 — DB 커밋 후에만 브로드캐스트하고, 1,000명 수신 검증에서 유실 0건

• 채팅방 목록 API가 방 N개당 2N+1회 쿼리를 실행 (방 50개면 101회)

  → k6 200 VU에서 RPS 937 → 1,598 (+70.5%), p95 212.85ms → 149.22ms (−29.9%)

• 브로드캐스트 후 DB 저장이 실패하면, 화면에는 보였지만 사라지는 메시지가 생긴다

  → 2대 인스턴스 · 1,000명 receiver matrix 3회 반복에서 expected 99,900건 전량 수신 — 유실 0 · 중복 0 · 순서 역전 0

• 데이터가 쌓이면 조회 경로가 느려질 수 있는데, 어떤 인덱스가 실제로 쓰이는지 모른다

  → 멱등성·멤버 확인은 Index Only Scan, 핵심 쿼리 실행 시간 0.08 – 1.3ms 확인

7인 팀 (기획·리서치 3 · 프로덕트 개발 4) · 15조 피프틴피프틴 · 백엔드 전담 (FastAPI)

교통약자의 실제 보행속도로 도착시간을 다시 계산하는 배리어프리 내비게이션 — 하나금융×SKT Tech4Good 2026 해커톤

• 지도 앱의 ETA는 표준 보행속도 기준이라 휠체어·노약자에게는 항상 틀린 값이 된다

  → 일반 ETA와 개인화 ETA를 함께 반환하는 경로 API 제공, 경사·보행환경 페널티 반영

• 엘리베이터·저상버스 정보가 없을 때 "이용 가능"으로 단정하면 사용자를 계단 앞에 데려다 놓는다

  → 실측·시간표·추정·미확인 데이터를 구분해 응답 — 없는 데이터를 지어내지 않는 설계

• 대중교통을 놓치거나 경로를 이탈하면 기존 안내는 무용지물이 된다

  → 이탈·놓침 감지 시 현재 위치를 새 출발점으로 경로와 ETA 갱신, 위치 요청 지연 복구 처리