exercises-debugging

지뢰요소 디버깅 연습문제

arch-cross-cutting pattern-pitfalls pattern-incident

이 노트의 사용법

이 문서는 air-intl-adapter에서 실제로 사고가 나는 지점(landmines)을 “장애 시나리오”로 재구성한 디버깅 훈련 모음이다. 전 문항이 debug 유형이며, 운영에서 마주칠 법한 증상을 먼저 주고 신입이 직접 조사 순서를 세워 보게 한다. 푸는 법: ① 증상만 보고 “내가 콜이라면 어디부터 로그를 깔까”를 적는다. ② 조사 순서 → 근본원인 → 예방을 스스로 정리한다. ③ [!answer]- 정답 보기를 펼쳐 파일경로·라인·예외 타입·전파 경로까지 맞췄는지 대조한다.

이 시스템의 사고는 메시지큐가 아니라 4개 경로로만 표면화된다(중요): ①동기 예외→RestExceptionHandler, ②서킷 OPEN→검색 fallback 200 [], ③fire-and-forget 코루틴→AdapterCoroutineExceptionHandler(Sentry 로깅만), ④Slack 수동 경보(best-effort). → landmines §0, error-handling, async-coroutines, resilience-and-events

---

0. 디버깅 근육 6 + α (이 문서가 다루는 함정)

#	시나리오	대표 함정	핵심 노트
1	GDS 세션 누수 → 전체 예약 마비	stateful 세션 미종료(Amadeus/Sabre)	landmines §1, amadeus-pitfalls, sabre-pitfalls
2	”발권 성공인데 결제/PNR 안 닫힘”	fire-and-forget 보상취소 유실	async-coroutines, landmines §2
3	검색 결과 0건인데 장애인가 정상인가	서킷 OPEN 200 [] vs isSearchable vs pmap 부분실패	resilience-and-events, landmines §7
4	외화 운임이 100배 / 1원 안 맞음	통화 decimals 미적용, tax+fuelCharge 이중계상	landmines §5, lufthansa-pitfalls, amadeusndc-pitfalls
5	T’way 결제만 전 건 인증 실패	SEED 인증/암호화 경로 깨짐	tway-pitfalls, landmines §1·§6
6	재발행이 자꾸 “실패”로 보임	202+폴링키 흐름 오해, ERROR 재던짐	common-operations, landmines §10
7	코루틴 예외가 흔적도 없이 사라짐	withAsync 핸들러 부재, pmap swallow	async-coroutines, error-handling
8	Sentry에 안 잡힘 / Slack이 안 옴	.capture() 누락, 자동 Slack 없음	error-handling, landmines §4

디버깅 제1원칙 — "이건 어느 표면화 경로인가?"

증상을 받으면 가장 먼저 4개 경로 중 어디로 드러난 사고인지 분류하라. 5xx면 ①(동기예외), 200 []이면 ②(서킷 OPEN) 또는 검색 부분실패, “API는 성공인데 뒤가 안 맞음”이면 ③(fire-and-forget), Sentry/Slack은 자동이 아니라 조건부/수동이다. 이 분류만으로 조사 범위가 1/4로 줄어든다.

---

문제 1 — [debug] “오후부터 Amadeus 예약·발권·취소가 전부 막혔다”

오후 2시경부터 Amadeus(/internals/AMADEUS/booking, /ticketing, /cancel)가 전부 실패하기 시작했다. 검색(/search)은 정상이다. 에러 메시지는 GDS 측 “no more sessions available / session limit exceeded” 류다. 재배포하면 잠깐 풀렸다가 다시 막힌다.

증상: 비검색 Amadeus 오퍼레이션 전량 실패, 검색은 정상, 재배포 후 일시 회복.

시작점: supplier/amadeus/application/AmadeusBookingService.kt, support/protocol/StatefulBuilder.kt(있다면), landmines §1

정답 보기

근본원인: stateful 세션 누수로 TOPAS 동시세션/라이선스 한도 소진. Amadeus(TOPAS·1A)는 PNR 트랜잭션을 stateful 세션 토큰 위에서 수행하고, 예외 시 세션을 닫지 않으면 GDS 측 세션이 열린 채 쌓여 한도가 고갈된다. 검색은 stateless라 멀쩡하다 → “검색 정상 + 예약/발권/취소 전멸”이 결정적 단서.

조사 순서:

1. 검색이 정상인지 확인 → 정상이면 네트워크/공통 인프라가 아니라 stateful 경로 한정 문제로 좁힌다.
2. 최근 배포 diff에서 새 stateful 오퍼레이션 추가/리팩터링 여부 확인. 누수는 거의 항상 “세션 종료 패턴 누락”에서 온다.
3. AmadeusBookingService.kt의 catch 블록이 전부 종료 패턴으로 끝나는지 점검:

} catch (e: Exception) {
    if (session?.transactionStatusCode == TransactionStatusCode.InSeries) {
        end { amadeusClient.signOut(statefulBuilder = this) }
    }
    throw e
}

이 패턴이 AmadeusBookingService.kt:172, :268, :316, :373, :400 등 모든 catch에 있어야 한다(누락 시 누수 재생산). Sabre는 finally { closeSessionToken(token) } 쌍 — SabreTicketingService.kt:47-48, SabreCashReceiptService.kt:54-55, SabreQueueService.kt:74-75/130-131, SabrePassengerService.kt:68-69. 4. 코너케이스: signOut은 transactionStatusCode == InSeries일 때만 호출된다. start{} 직후 InSeries 전이 전에 인증 실패/네트워크 오류가 나면 패턴을 정확히 복붙해도 세션이 닫히지 않는다(landmines §1 “Start 직후 예외”).

재배포로 일시 회복하는 이유: 프로세스가 죽으면 어댑터 측 커넥션이 끊겨 GDS가 일부 좀비 세션을 정리하기 때문. 즉 재배포는 증상 완화일 뿐 근본 치료가 아니다.

예방: 새 stateful 메서드는 반드시 종료 패턴을 검증하고, TOPAS 동시세션 모니터링 지표를 둔다. 시그니처 복붙이 누수를 재생산하므로 코드리뷰 체크리스트화. 출처: landmines §1, amadeus-pitfalls, amadeus-operations, sabre-pitfalls, amadeus-gds

---

문제 2 — [debug] “취소 API는 200인데 실제 PNR이 안 닫혔다 / 결제 환불이 안 됐다”

발권 실패 케이스에서 고객은 취소/환불 성공 응답(200)을 받았다. 그런데 며칠 뒤 정산에서 고아 PNR과 미환불 결제가 발견됐다. 어떤 건은 멀쩡하고, 어떤 건만 이런 불일치가 난다. 재현이 들쭉날쭉하다.

증상: 동기 응답은 성공인데 후속 보상(취소/결제취소)이 누락. 산발적 재현.

시작점: supplier/amadeus/application/AmadeusBookingService.kt:179, AmadeusCancelService.kt:311, support/util/CoroutineExtensions.kt, landmines §2

정답 보기

근본원인: fire-and-forget 보상취소가 분리 코루틴 스코프에서 실행되어, 보상이 실패하거나 그 사이 프로세스가 죽으면 통째로 유실된다.

발권/예약 실패 시 보상은 호출자에게 즉시 원 예외를 던지고(throw e) 취소만 백그라운드로 분리한다:

// AmadeusBookingService.kt:179~180
pnr?.run { cancelService.pnrCancelAsync(this) }
throw e   // 사용자에겐 즉시 예외, 단 응답 자체가 성공 케이스도 있음

// AmadeusCancelService.kt:311~313
fun pnrCancelAsync(pnr: String) {
    CoroutineScope(Dispatchers.IO).withLaunch {
        delay(5000)   //locked pnr 방지
        ...pnrCancelRepeat(pnr)

이 CoroutineScope(Dispatchers.IO)는 부모가 없는 분리 스코프다(Job을 보관하지 않음 → 구조화된 동시성 밖, 60+ 사용처). 인메모리이고 영속큐가 아니다.

조사 순서:

1. “동기 성공 + 비동기 보상” 패턴인지 확인 → withLaunch/pnrCancelAsync/pnrCancelRepeat(AmadeusCancelService.kt:237)를 grep.

2. 불일치 발생 시각에 재배포/스케일인이 있었는지 확인. delay(5000) 만료 전 프로세스가 죽으면 취소가 영영 실행되지 않는다(고아 PNR).

3. 보상 코루틴 자체가 던진 예외 추적: withLaunch는 AdapterCoroutineExceptionHandler()를 컨텍스트에 주입(CoroutineExtensions.kt:20-25)하므로 Sentry 로깅은 남는다. 단 호출자에게는 전파 안 됨.

4. 사후 추적의 유일한 능동 신호는 Slack 수동 경보: pnrCancelRepeat가 최종 실패 시 slackService.sendCancelFail(...)(AmadeusCancelService.kt:249), 결제취소 실패는 sendPaymentCancelFail(...)(:435) 후 rethrow. 이건 best-effort라 전송 실패도 조용히 사라진다.

"치명 오류 = 자동 Slack"은 오해 RestExceptionHandler/AdapterCoroutineExceptionHandler는 Slack을 호출하지 않는다. 자동 경보는 Sentry뿐이고, Slack은 서비스 코드가 수동으로 부르는 지점에서만 나간다. → error-handling §5.3

예방: 신뢰성이 필요한 보상은 support/util/PollingUtils.kt의 polling처럼 Redis에 상태를 남기는 패턴으로 바꿔야 한다(DeferredResult PENDING/COMPLETE/ERROR를 TTL과 함께 저장, PollingUtils.kt:12-40). 전 공급사 동일 패턴 — AmadeusTicketingService.kt:217, SabreTicketingService.kt, KoreanairTicketingService.kt(결제 5초/예약 10초 시간차) 등. 출처: async-coroutines, landmines §2, resilience-and-events, amadeus-pitfalls

---

문제 3 — [debug] “특정 공급사만 검색 결과가 0건이다 — 장애인가 정상인가?”

대시보드에서 어떤 공급사의 검색 결과가 한동안 0건으로 보인다. 다른 공급사는 정상. 5xx는 없고 응답코드는 전부 200이다. 같은 0건이라도 원인이 4가지나 된다고 한다. 어떻게 구분하나?

증상: 한 공급사 검색이 200 []. 5xx 없음.

시작점: supplier/amadeus/interfaces/controller/internals/AmadeusSearchController.kt:73, interfaces/request/SearchRequest.kt:26, support/util/CoroutineExtensions.kt:62, landmines §7·§10

정답 보기

200 []은 4가지 전혀 다른 원인을 같은 모습으로 위장한다. 구분 절차:

후보 원인	어디서	구분 단서
(a) 서킷 OPEN	searchFallback(exception: CallNotPermittedException) → ResponseEntity.ok(emptyList()) (AmadeusSearchController.kt:73-79)	Datadog span 태그 supplier.circuit-breaker=OPEN(:76). RestExceptionHandler를 안 탄다. 같은 공급사만 2분(waitDurationInOpenState 120s) 동안 0건
(b) isSearchable 제약	SearchRequest.isSearchable(supplier)(SearchRequest.kt:26-34)	공급사가 검색에서 스스로 빠짐. TWAY/JINAIR는 여정≤2 & 항공사코드 포함, SINGAPOREAIR는 SQ 포함, GROUPAIR는 왕복만. 조건 불충족이면 정상 동작으로 0건
(c) Jin Air 당일 컷오프	JinairFlightSearchService.kt:54 return emptyList()	departureDate < today().plusDays(2)(KST) 류 제약/필터로 출발 임박편은 무조건 0건. “왜 진에어만 안 되지?”의 단골
(d) pmap 부분/전체 실패 swallow	getOrEmpty()(CoroutineExtensions.kt:62)	OD 조합 일부가 타임아웃/에러여도 성공분만 반환, 전부 실패면 0건. 로그 warn에만 흔적

조사 순서:

1. Datadog에서 supplier.circuit-breaker=OPEN 태그 확인 → 있으면 (a) 확정. (a)는 5xx가 아니라 태그/0건으로만 드러나므로 알람이 없으면 운영자가 모른다(landmines §7).

2. 요청 본문의 항공사코드/여정수/왕복여부를 isSearchable 규칙과 대조 → (b).

3. 출발일이 임박했나? → (c).

4. 위가 다 아니면 검색 로그의 warn(AsyncFail)을 본다 → (d). getOrEmpty가 실패를 삼키므로 로그 확인이 필수.

서킷 fallback은 CallNotPermittedException만 받는다 searchFallback 시그니처가 CallNotPermittedException만 받으므로(AmadeusSearchController.kt:73), 검색 로직 내부의 타임아웃/비즈니스 예외는 fallback을 안 타고 그대로 500 전파된다. "왜 어떤 검색 실패는 빈 결과인데 어떤 건 500이냐"의 답. → resilience-and-events, exercises-architecture 문제5

예방: 0건이 정상 동작일 수 있음을 인지. 서킷 상태전이는 onStateTransition 컨슈머가 0건이라 사람이 알 방법이 없으니 Datadog 태그 알람을 건다. 출처: resilience-and-events, landmines §7·§10, jinair-pitfalls, async-coroutines

---

문제 4 — [debug] “유럽 노선 운임이 100배로 찍히거나 1원씩 안 맞는다”

Lufthansa/Singapore 등 유럽·동남아 노선에서 운임이 비정상적으로 크게(약 100배) 표시되거나, 검색가와 발권가가 미세하게 어긋난다는 신고가 들어왔다. 국내선·KRW 노선에서는 멀쩡하다.

증상: 외화(EUR/USD/SGD) 노선 운임 100배 부풀림 또는 미세 오차. KRW 노선은 정상.

시작점: lufthansa Offer.kt:182/DataList.kt:163, amadeusndc Passenger.kt, landmines §5

정답 보기

근본원인 두 갈래. “KRW만 정상”이 결정적 단서다 — KRW는 decimals=0이라 버그가 우연히 가려진다.

(1) 통화 소수자릿수(decimals) 미적용 → 100배 부풀림

• lufthansa: CurrencyAmountValue.getAmount는 movePointLeft(decimals)를 적용하지만, 검색(Offer.kt:182)·예약(DataList.kt:163)은 toLong() 직접 변환으로 decimals를 무시한다. EUR(소수 2자리) 응답이면 12345가 123.45가 아니라 12345로 들어가 100배. FareRule 변경수수료만 올바른 getAmount() 사용 — 같은 모듈 안에서도 비일관.
• singaporeair: Amount/CurrencyAmount/ResponseParameter의 curCode 기본값이 전부 KRW라 SQ가 SGD/USD로 줘도 KRW로 취급(통화 일치 검증 없음 → 정산 사고).
• amadeusndc: convertPriceDropLast가 반올림이 아닌 truncation, currencyMap에 통화 없으면 자릿수 0. toBooking(convert)과 toReissueBooking(toLong() 무변환)이 같은 totalPrice를 다른 스케일로 — 명백한 버그.

(2) tax에 fuelCharge가 합산되어 유류할증 이중계상

• 다수 공급사가 Fare.tax에 유류할증을 이미 합산하면서 fuelCharge/surcharge를 별도로도 보관한다. Fare.total = airPrice + tax라 유류할증은 이미 포함. 신입이 airPrice + tax + fuelCharge로 다시 합하면 즉시 이중계상. tway(Fare.kt), jinair(AirAvailabilityRS.kt), groupair, amadeusndc(Passenger.kt).

조사 순서:

1. 신고 노선의 통화 코드 확인 → 비-KRW면 (1) 강력 의심.

2. 부풀림 배율이 정확히 100배/10배면 decimals 누락(toLong() vs getAmount()) 확인.

3. 미세 오차/이중계상이면 운임 합산 코드에서 + fuelCharge/+ surcharge가 tax와 중복되는지 확인. 세금만 분리 표시하려면 tax - fuelCharge.

KRW funnel만으로 테스트하면 절대 못 잡는다 toLong()과 getAmount()가 같은 값을 내므로 단위테스트가 통과한다. EUR/USD/SGD 실전문으로 검증해야 한다.

decimals=0인 KRW에서는

예방: 신규 운임 매핑 시 통화 코드 검증 + decimals 적용을 반드시 확인하고, Fare.total getter(airPrice+tax)를 쓰고 수동 합산을 피한다. → landmines §5 출처: landmines §5, lufthansa-pitfalls, singaporeair-pitfalls, amadeusndc-pitfalls, koreanair-pitfalls, singaporeair-ndc

---

문제 5 — [debug] “T’way 결제만 전 건 인증/암호화 실패한다”

T’way(/internals/TWAY/...)에서 다른 오퍼레이션은 되는데 카드결제가 들어가는 발권/부가결제(/book/ModifyBooking) 만 전 건 실패한다. 어떤 환경에서는 빌드 자체가 깨진다. 또 개인카드 고객만 NPE로 죽는 케이스도 있다.

증상: T’way 결제 경로 전 건 실패, 일부 환경 빌드 실패, 개인카드 NPE.

시작점: supplier/tway/infrastructure/request/CardInfo.kt, build.gradle.kts:67, Dockerfile, tway-pitfalls, landmines §1·§6

정답 보기

T’way 결제는 SEED 암호화 인증에 의존한다. 증상별 원인이 다르다.

(A) 빌드가 깨진다 → TwaySEED.jar 로컬 파일 의존성 누락 build.gradle.kts:67의 implementation(files("libs/TwaySEED.jar"))와 Dockerfile의 COPY libs ./libs 중 하나라도 빠지면 com.twayair.security.seed.SeedUtil 미해결로 컴파일 실패. 이 jar는 Maven Central에 없고 T’way가 제공 — 삭제하면 재취득 불가, 의존성 감사 도구가 추적 못 함.

(B) 전 건 인증 실패 → SEED 암호화 경로를 건너뜀 암호화는 반드시 CardInfo.of()가 수행한다(CardInfo.kt:20-40):

// CardInfo.kt:24~32 — SeedUtil.encoding으로 양방향 암호화
cardNumber   = SeedUtil.encoding(cardInfo.cardNumber),
expireDate   = SeedUtil.encoding(cardInfo.expiryYear + cardInfo.expiryMonth),
cardPassword = SeedUtil.encoding(cardInfo.password),

OfflineAuthInfo(...)를 생성자로 직접 만들면 SEED 암호화를 건너뛰어 평문 카드정보가 와이어에 나가고 T’way가 거부한다. 반드시 CardInfo.of()를 통해서만 생성. SEED 키 'twayBookingAPI@014'는 jar 안 정적 필드에 하드코딩 — 키 로테이션은 T’way가 새 jar를 배포해야만 가능.

(C) 개인카드만 NPE → cardHolderBirthDate!! 강제 언랩

// CardInfo.kt:26~31
registrationNumber = SeedUtil.encoding(
    when (cardInfo.cardUserType) {
        CardUserType.PERSONAL -> cardInfo.cardHolderBirthDate!!.format("yyMMdd")  // null이면 NPE
        CardUserType.CORPORATE -> cardInfo.identityNumber
    }
)

개인카드(PERSONAL)인데 cardHolderBirthDate가 null이면 등록번호 인코딩에서 NPE. 법인카드는 identityNumber라 안전.

조사 순서:

1. 빌드 단계 실패면 (A) — clean 체크아웃/CI/Docker에 jar가 따라갔는지 확인.

2. 런타임 인증 실패면 결제 본문이 SEED 암호화돼 나가는지 확인 → CardInfo.of()를 우회했는지 (B). BouncyCastle이 전이의존으로만 들어오므로 상위 업그레이드 시 bcprov가 빠지면 SEED가 런타임에 깨질 수도 있다.

3. 특정 카드유형(개인)만 NPE면 (C).

SEED 문자열을 로그에 남기지 마라 SeedUtil의 encoding/decoding은 양방향이라 SEED 인코딩 문자열이 로그에 남으면 복호 가능하다. 카드번호/비밀번호가 든 /book/ModifyBooking 평문 바디 로깅 금지. (어댑터 내부 support/util/SeedEncryptor.kt는 Korean Air NicePay 전용으로 T'way SEED와 별개 — 혼동 금지)

예방: 결제 객체는 CardInfo.of()로만 생성, jar 동봉을 CI 체크, 개인카드 birthDate null 가드. 출처: tway-pitfalls, tway-protocol, landmines §1·§6, build-deploy-config

---

문제 6 — [debug] “재발행(reissue)이 자꾸 실패로 보이는데 실제로는 진행 중이다”

Triple 쪽에서 “Korean Air 재발행 API를 부르면 즉시 202가 오는데, 그걸 실패로 처리하고 있다” “또는 결과를 한 번만 조회하고 안 보이면 실패로 친다”는 보고. 어떤 건은 실제 ERROR인데 조용히 넘어간다.

증상: 재발행이 동기 응답을 안 주고 202를 줌. Pending을 실패로 오해. ERROR 누락.

시작점: supplier/koreanair/interfaces/controller/internals/KoreanairTicketingController.kt:53, support/util/PollingUtils.kt, common-operations, landmines §10

정답 보기

근본원인: 재발행(addition/reissue)은 동기가 아니라 202 ACCEPTED + 폴링키 모델이다. Pending은 정상 진행 상태다.

흐름(KoreanairTicketingController.kt):

POST .../addition (reissue)              ── 202 ACCEPTED + DeferredKeyView(pollingKey)   (:53~66)
  │   polling(key, ttl, redisTemplate) { 실제 재발행 } → 백그라운드 실행, 즉시 키 반환
  ▼
GET  .../addition/{reissueKey}           ── DeferredView<...>  (:69~)
      DeferredStatus.PENDING  -> DeferredView.Pending     (:77)  ← 정상 진행!
      DeferredStatus.ERROR    -> throw throwable!!         (:78)  ← 저장된 예외 재던짐
      DeferredStatus.COMPLETE -> DeferredView.Complete(...) (:79~)

서버측 polling(PollingUtils.kt:12-40)은 Redis에 DeferredResult.pending()을 TTL과 함께 저장한 뒤 CoroutineScope(Dispatchers.IO).withLaunch로 실제 작업을 돌리고, 성공/실패에 따라 complete/error로 갱신한다(:21-37). 조회측 poller(:43-49)는 키가 없으면 CacheKeyInvalidException(INVALID_CACHE_KEY), throwable != null이면 재던진다.

조사 순서:

1. 컨트롤러 응답코드 확인 → 202이고 body가 DeferredKeyView면 폴링 모델 확정.

2. Triple이 GET .../{reissueKey}로 폴링하고 있는지 확인. 한 번만 조회하고 Pending이면 실패로 치는 게 진짜 버그.

3. ERROR 누락이면: 폴링 결과 DeferredStatus.ERROR일 때 throw throwable!!(:78)로 저장된 예외를 재던지는데, 호출자가 이를 못 잡고 흘리는지 본다.

4. 결과가 통째로 사라졌으면 Redis TTL(REISSUE.ttl) 만료 의심 — 폴링이 늦으면 poller에서 INVALID_CACHE_KEY.

tway/jinair/jejuair/koreanair/singaporeair 모두 동일한 202+폴링 모델 Pending=정상임을 인지. → landmines §10

동기 응답을 기대하면 결과 누락.

예방: 재발행은 폴링 흐름임을 계약 문서에 명시, ERROR 상태를 반드시 처리, TTL 내 폴링 보장. 출처: common-operations, landmines §10, koreanair-pitfalls, singaporeair-overview

---

문제 7 — [debug] “코루틴에서 던진 예외가 흔적도 없이 사라진다”

병렬 처리 로직을 직접 withAsync로 짠 뒤부터, 한 코루틴이 던진 예외가 호출자에게 안 가고 로그에도 없고 Sentry에도 없다. 어떤 때는 형제 코루틴까지 통째로 죽는다. pmap을 쓸 때와 동작이 다르다.

증상: 코루틴 예외 유실 또는 형제 동반 취소. withAsync 직접 사용 시에만 발생.

시작점: support/util/CoroutineExtensions.kt:28-50, support/exception/AdapterCoroutineExceptionHandler.kt, async-coroutines, error-handling

정답 보기

근본원인: withAsync에는 AdapterCoroutineExceptionHandler가 주입되지 않는다. 그리고 코루틴 표준상 async/Deferred의 예외는 핸들러를 무시하고 await() 지점에서 재던져진다.

// CoroutineExtensions.kt
fun <T> withBlocking(...) = runBlocking(context + SupervisorJob()
    + AdapterCoroutineExceptionHandler() + MDCContext()) { ... }   // :16  핸들러 O
fun CoroutineScope.withLaunch(...) = launch(context + SupervisorJob()
    + AdapterCoroutineExceptionHandler() + MDCContext(), ...)      // :25  핸들러 O
fun <T> CoroutineScope.withAsync(...) = async(context + SupervisorJob()
    + MDCContext(), ...)                                            // :33  핸들러 X !!

CoroutineExceptionHandler는 launch/runBlocking 루트에서만 동작하고 async에는 무력하다. 그래서 pmap은 withAsync 안의 작업을 직접 try/catch로 감싸 예외를 던지지 않고 AsyncFail “값”으로 변환한다:

// CoroutineExtensions.kt:39~47
withAsync<AsyncMapResult<R>> {
    try { AsyncSuccess(block(it)) }
    catch (e: Exception) { AsyncFail(e) }     // 예외를 값으로 — 던지지 않음
}.awaitAll()

조사 순서:

1. 문제 코드가 withAsync를 직접 쓰고 있는가? → 그렇다면 await() + 예외 수거를 빠뜨린 게 원인.

2. await()를 try/catch로 감쌌는지 확인. 안 감싸면 예외가 await 지점에서 재던져지거나, SupervisorJob 덕에 형제는 살지만 해당 Deferred를 await 안 하면 유실.

3. pmap을 거치는 경로면 예외는 AsyncFail로 흡수되고 getOrEmpty()(:62)는 삼키고, getOrThrow()(:64-68)는 첫 예외만 던진다 — “유실”의 또 다른 형태.

AdapterCoroutineExceptionHandler는 BeanUtils 정적 룩업에 의존 핸들러는 new로 매번 생성되어 Spring DI를 못 받고, BeanUtils.getBean(RestExceptionHandler)로 런타임 룩업해 findRootCause().log().sentryLog()로 위임한다(AdapterCoroutineExceptionHandler.kt:15-25). BeanUtils.applicationContext가 lateinit이라 컨텍스트 초기화 전 코루틴 예외는 NPE 가능. 부팅 시점 코루틴 작업을 피하라. → async-coroutines, support-common

예방: 병렬 작업은 직접 withAsync 대신 pmap을 쓴다. 직접 쓸 땐 반드시 await + 예외 수거. SupervisorJob이 한 자식 실패를 형제로 전파하지 않게 격리한다. 출처: async-coroutines, error-handling, landmines §2

---

문제 8 — [debug] “장애가 분명한데 Sentry에 안 잡히거나, 멀쩡한 게 노이즈로 잡힌다”

운영 중 두 정반대 현상이 동시에 보고됐다. (a) 카드 거절(한도초과 등)이 분명히 났는데 Sentry에 안 올라온다. (b) 단순 외부 타임아웃이 INTERNAL_SERVER_ERROR로 Sentry를 도배한다. 응답 code는 또 따로 논다.

증상: 분류된 비즈니스 실패는 Sentry 미보고, 비-ApiException은 Sentry 과보고, 응답/로그 예외 불일치.

시작점: support/exception/RestExceptionHandler.kt, support/web/ClientSupport.kt:62, support/exception/Exceptions.kt, error-handling, landmines §4

정답 보기

근본원인: Sentry 전송 조건이 예외 타입에 따라 비대칭이다.

(a) 분류된 실패가 안 잡힘 → ApiException.capturable 기본값 false ApiException은 .capture()를 호출해야만 Sentry에 잡힌다(기본 capturable=false, Exceptions.kt). sentryLog()는 this is SentryAlertHandler && capturable.not()이면 전송 스킵. 즉 .capture() 없이 던진 비즈니스 예외(예상된 실패)는 의도적으로 조용하다. 결제 거절도 분류된 코드는 .capture() 없이 안 잡히고, set에 없는 미분류만 PAYMENT_ETC로 capture되는 모듈도 있다(landmines §4 “결제 에러코드 미등록”).

(b) 타임아웃이 과보고 → SOAP fault 파싱 실패 시 raw 예외 전파 ClientSupport.handleSoapFaultException(ClientSupport.kt:62)은 errorData가 null이거나 비-SOAP 형식이면 ?: this.exception 폴백으로 원본 예외(IOException 등)를 던진다. 타임아웃(OkHttpError.isTimeout, ClientSupport.kt:206)도 errorData가 없어 이 경로로 빠진다. 비-ApiException은 capturable 체크를 우회해 무조건 Sentry로 전송되고 응답 code는 분류를 잃고 INTERNAL_SERVER_ERROR로만 나간다.

(응답/로그 불일치) → findRootCause()가 cause 래핑의 분류를 버린다 RestExceptionHandler.findRootCause()는 가장 안쪽 cause를 로그/Sentry 대상으로 삼는다. InternationalAdapterException(BOOKING_FAILED, cause=ioException)처럼 던지면 root cause인 ioException이 Sentry로 가고 BOOKING_FAILED 분류가 사라진다. 게다가 응답 변환은 원본 e를 쓰므로(RestExceptionView.of(exception=e)) 응답 code는 정상 — 로그/Sentry와 응답이 서로 다른 예외를 본다.

조사 순서:

1. 안 잡히는 실패가 ApiException(비즈니스)인지 확인 → .capture() 호출 여부 grep. 모니터링하고 싶으면 .capture()를 붙인다.

2. 노이즈가 INTERNAL_SERVER_ERROR 빈발이면 SOAP fault 정규화 실패/타임아웃 경로 의심(handleSoapFaultException 폴백).

3. 응답 code와 Sentry 예외가 다르면 cause 래핑(findRootCause) 분류 손실을 의심.

HTTP status는 ErrorMessage(코드)가 아니라 예외 "타입"이 정한다 @ControllerAdvice(RestExceptionHandler)가 MethodArgumentInvalidException→400, CacheKeyInvalidException→410, InternationalAdapterException/그 외→500으로 분기. 응답 code는 exception.errorMessage.name이라 enum 상수명이 곧 외부 API 계약 — 추가만 안전, 리네임/삭제는 브레이킹. → error-handling, exercises-architecture 문제5

예방: 모니터링 대상 비즈니스 실패는 .capture(), 정규화 실패 경로 모니터링, cause 래핑 시 분류 손실 인지. 일부 lufthansa 분기(booking, changeApis)는 .capture() 누락으로 Sentry 사각지대. 출처: error-handling, landmines §4, lufthansa-pitfalls

---

학습 포인트 요약 (꼭 가져갈 것)

시나리오	한 줄 핵심	근거 위치
세션 누수	검색만 정상+예약/발권/취소 전멸 = stateful 세션 미종료. catch마다 InSeries→signOut/finally→closeSessionToken	AmadeusBookingService.kt:172, SabreTicketingService.kt:48
보상취소 유실	동기 성공+뒤 안 맞음 = fire-and-forget. delay(5000)중 셧다운 시 유실, Slack은 수동 best-effort	AmadeusCancelService.kt:311, PollingUtils.kt:12
0건의 4원인	서킷 OPEN(Datadog 태그) / isSearchable / 당일컷오프 / pmap swallow. fallback은 CallNotPermittedException만	AmadeusSearchController.kt:73, SearchRequest.kt:26
통화 오차	KRW만 정상이면 decimals 미적용(100배) 또는 tax+fuelCharge 이중계상. KRW 테스트로 못 잡음	Offer.kt:182, landmines §5
SEED 인증	jar 누락=빌드깨짐, CardInfo.of() 우회=평문, 개인카드 birthDate null=NPE, SEED 양방향이라 로그금지	CardInfo.kt:20, build.gradle.kts:67
재발행	202+폴링키, Pending=정상, ERROR는 throw throwable!!, TTL만료 시 INVALID_CACHE_KEY	KoreanairTicketingController.kt:53, PollingUtils.kt:43
코루틴 유실	withAsync엔 핸들러 없음(async는 핸들러 무력), pmap이 try/catch로 AsyncFail 흡수	CoroutineExtensions.kt:33, :39
Sentry/Slack	.capture() 없으면 ApiException 미보고, 비-ApiException은 무조건 보고(노이즈), Slack 자동 없음	Exceptions.kt, RestExceptionHandler.kt

---

관련 노트

• landmines — 전체 지뢰 마스터 (모든 문항의 원천)
• error-handling — 예외 타입→HTTP status, capturable/Sentry 조건 (문제 7·8)
• async-coroutines — pmap/withLaunch/withAsync 상세 (문제 2·7)
• resilience-and-events — 서킷브레이커 OPEN·fallback·Slack (문제 3)
• amadeus-pitfalls — 세션 누수/운임 파싱 (문제 1)
• sabre-pitfalls — 세션 토큰 close (문제 1)
• tway-pitfalls — SEED 인증/암호화 (문제 5)
• lufthansa-pitfalls · singaporeair-pitfalls · amadeusndc-pitfalls — 통화 decimals (문제 4)
• koreanair-pitfalls — 재발행 폴링 (문제 6)
• common-operations — key/pnr, 재발행 202 폴링 모델 (문제 6)
• 아키텍처 추적 연습은 exercises-architecture, 공급사별 심화는 exercises-suppliers