---
template: policy-doc@1
doc_id: 02-failure-semantics
title: 벤더 응답 의미 — 장애와 자료없음을 가르는 두 축
config: ../_meta/template-config.yaml
last_verified: 4d798f55
policies:
  - id: vendor:__dispatch__:fallback
    status: conditional-unknown
    evidence: [A-vendor, A-comment]
    unknown_reason: 채택과 폴백의 규칙 자체는 동결 stg 4d798f55 의 코드로 확정되지만 그 규칙이 발효하는지는 편성 값에 걸려 있다 — TREAT_PROVIDER 가 다중 공급자 모드일 때만 성립하고(기본값은 단일 공급자다) TREAT_POOL 이 어느 공급자를 담는지도 주입값이다. 두 값 모두 저장소 밖에 있어 후보 인덱스가 이 행의 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/config/configuration.ts:29
      - insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:35
      - insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:73
  - id: vendor:aligo:failure
    status: conditional-unknown
    evidence: [A-vendor, A-comment]
    unknown_reason: 이 행의 후보 인덱스 policy_gates 가 빈 배열이다 — 게이트 부재. 이 벤더의 환경 키는 벤더 설정 블록 소유이고 조사 규약의 정책 게이트 목록과 이름 교집합이 0이라 조건을 걸 게이트 자체가 없다. 그래서 미판정의 원인은 게이트 값 미상이 아니라 도달 증거 부재이며 후보 인덱스가 status_basis 를 deployment-unproven 으로 기록했다.
    anchors:
      - insuniverse-server/libs/aligo/src/aligo.exception.ts:3
  - id: vendor:aligo:no_data
    status: conditional-unknown
    evidence: [A-vendor, A-comment]
    unknown_reason: 이 행의 후보 인덱스 policy_gates 가 빈 배열이다 — 게이트 부재. 여기에 더해 이 결과 자체가 관측되지 않았다. 후보 인덱스의 evidence 가 빈 유일한 부류가 이 축의 자료없음 세 칸이고, 그 빈칸은 근거를 못 찾은 것이 아니라 벤더 API 에 그 개념이 없다는 관측이다(limitations).
    limitations:
      - 발송 API 에 조회 결과 개념이 없다 — 발송요청과 발송완료 확인 응답만 존재한다. 이것은 분류 누락이 아니라 개념 부재이며, 진료수집 축의 자료없음과 같은 어휘로 접으면 두 결손이 같아 보인다
    anchors:
      - insuniverse-server/libs/aligo/src/aligo.service.ts:68
  - id: vendor:aligo:success
    status: conditional-unknown
    evidence: [A-vendor, A-comment]
    unknown_reason: 이 행의 후보 인덱스 policy_gates 가 빈 배열이다 — 게이트 부재. 이 벤더의 환경 키는 벤더 설정 블록 소유이고 조사 규약의 정책 게이트 목록과 이름 교집합이 0이라 조건을 걸 게이트 자체가 없다. 그래서 미판정의 원인은 게이트 값 미상이 아니라 도달 증거 부재이며 후보 인덱스가 status_basis 를 deployment-unproven 으로 기록했다.
    anchors:
      - insuniverse-server/libs/aligo/src/aligo.service.ts:68
  - id: vendor:codef:failure
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 실패 코드를 분류로 접는 맵은 동결 stg 4d798f55 에서 해석되지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:9
  - id: vendor:codef:no_data
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더가 공급자 풀에 들어 있는가가 TREAT_POOL 과 TREAT_PROVIDER 의 주입값에 걸려 있고 그 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다. 발효 여부와 별개로 이 칸에는 분류 자체의 결손이 있다(limitations).
    limitations:
      - 맵에 자료없음으로 분류된 코드가 0건이다. 미수록 코드는 미상 폴백으로 떨어지고 그 폴백의 대상은 운영자다. 코드 목록이 불완전한 것인지 벤더가 실제로 구분하지 않는 것인지는 저장소 안 근거로 갈리지 않는다 — 분류 부재다
      - 그 갈림을 판정할 설계 문서가 저장소에 없다. 택소노미 정의 파일과 벤더 맵 파일이 각각 첫 세 행에서 같은 설계 문서를 출처로 적는데 동결 stg 4d798f55 트리에 그 경로가 없다. 확인하지 못한 것이 아니라 관측된 부재다
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:9
  - id: vendor:codef:success
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 성공 코드를 분류로 접는 맵은 동결 stg 4d798f55 에서 해석되지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:9
  - id: vendor:coocon:failure
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 실패 코드를 분류로 접는 맵은 동결 stg 4d798f55 에서 해석되지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:34
  - id: vendor:coocon:no_data
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 자료없음 코드는 분류를 갖지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:34
  - id: vendor:coocon:success
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 성공 코드를 분류로 접는 맵은 동결 stg 4d798f55 에서 해석되지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:34
  - id: vendor:hyphen:failure
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 실패 코드를 분류로 접는 맵은 동결 stg 4d798f55 에서 해석되지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:134
  - id: vendor:hyphen:no_data
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 자료없음 코드는 분류를 갖지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:134
  - id: vendor:hyphen:success
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 성공 코드를 분류로 접는 맵은 동결 stg 4d798f55 에서 해석되지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:134
  - id: vendor:inhouse:failure
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 실패 코드를 분류로 접는 맵은 동결 stg 4d798f55 에서 해석되지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고, 이 벤더만 INHOUSE_CAR_CANARY 가 하나 더 걸린다. 세 값 모두 저장소 밖에 있어 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    limitations:
      - 택소노미 정의 파일 첫 행의 주석이 이 택소노미를 진료내역 네 벤더의 것으로 적는데, 같은 창의 벤더 유니온과 벤더 맵은 이 벤더를 포함해 다섯이다. 어느 쪽이 옳은지는 이 문서가 판정하지 않고 둘을 앵커와 함께 싣는다 — 주석만 읽은 독자는 이 벤더에 통합 분류가 없다고 결론짓게 된다
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:168
  - id: vendor:inhouse:no_data
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 자료없음 코드는 분류를 갖지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고, 이 벤더만 INHOUSE_CAR_CANARY 가 하나 더 걸린다. 세 값 모두 저장소 밖에 있어 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    limitations:
      - 택소노미 정의 파일 첫 행의 주석이 이 택소노미를 진료내역 네 벤더의 것으로 적는데, 같은 창의 벤더 유니온과 벤더 맵은 이 벤더를 포함해 다섯이다. 어느 쪽이 옳은지는 이 문서가 판정하지 않고 둘을 앵커와 함께 싣는다
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:168
  - id: vendor:inhouse:success
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 성공 코드를 분류로 접는 맵은 동결 stg 4d798f55 에서 해석되지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고, 이 벤더만 INHOUSE_CAR_CANARY 가 하나 더 걸린다. 세 값 모두 저장소 밖에 있어 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    limitations:
      - 택소노미 정의 파일 첫 행의 주석이 이 택소노미를 진료내역 네 벤더의 것으로 적는데, 같은 창의 벤더 유니온과 벤더 맵은 이 벤더를 포함해 다섯이다. 어느 쪽이 옳은지는 이 문서가 판정하지 않고 둘을 앵커와 함께 싣는다
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:168
  - id: vendor:octover:failure
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 실패 코드를 분류로 접는 맵은 동결 stg 4d798f55 에서 해석되지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:81
  - id: vendor:octover:no_data
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 자료없음 코드는 분류를 갖지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:81
  - id: vendor:octover:success
    status: conditional-unknown
    evidence: [A-vendor, S-constant]
    unknown_reason: 이 벤더의 성공 코드를 분류로 접는 맵은 동결 stg 4d798f55 에서 해석되지만 그 분류가 실제로 쓰이는지는 이 벤더가 공급자 풀에 들어 있는가에 걸려 있다. 그 편성은 TREAT_POOL 과 TREAT_PROVIDER 의 주입값이 정하고 두 값은 저장소 밖에 있다 — 후보 인덱스가 status_basis 를 gate-value-unknown 으로 기록했다.
    anchors:
      - insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:81
  - id: vendor:smartro:failure
    status: conditional-unknown
    evidence: [A-vendor, A-comment]
    unknown_reason: 이 행의 후보 인덱스 policy_gates 가 빈 배열이다 — 게이트 부재. 이 벤더의 환경 키는 벤더 설정 블록 소유이고 조사 규약의 정책 게이트 목록과 이름 교집합이 0이라 조건을 걸 게이트 자체가 없다. 그래서 미판정의 원인은 게이트 값 미상이 아니라 도달 증거 부재이며 후보 인덱스가 status_basis 를 deployment-unproven 으로 기록했다.
    anchors:
      - insuniverse-server/libs/pg/src/smartro/smartro.exception.ts:3
      - insuniverse-server/libs/pg/src/smartro/smartro.service.ts:139
  - id: vendor:smartro:no_data
    status: conditional-unknown
    evidence: [A-vendor, A-comment]
    unknown_reason: 이 행의 후보 인덱스 policy_gates 가 빈 배열이다 — 게이트 부재. 여기에 더해 이 결과 자체가 관측되지 않았다. 후보 인덱스의 evidence 가 빈 유일한 부류가 이 축의 자료없음 세 칸이고, 그 빈칸은 근거를 못 찾은 것이 아니라 벤더 API 에 그 개념이 없다는 관측이다(limitations).
    limitations:
      - 결제 승인·취소 API 에 조회 결과 없음 개념이 없다 — 승인과 실패 두 갈래만 존재한다. 이것은 분류 누락이 아니라 개념 부재다
    anchors:
      - insuniverse-server/libs/pg/src/smartro/smartro.service.ts:139
  - id: vendor:smartro:success
    status: conditional-unknown
    evidence: [A-vendor, A-comment]
    unknown_reason: 이 행의 후보 인덱스 policy_gates 가 빈 배열이다 — 게이트 부재. 이 벤더의 환경 키는 벤더 설정 블록 소유이고 조사 규약의 정책 게이트 목록과 이름 교집합이 0이라 조건을 걸 게이트 자체가 없다. 그래서 미판정의 원인은 게이트 값 미상이 아니라 도달 증거 부재이며 후보 인덱스가 status_basis 를 deployment-unproven 으로 기록했다.
    anchors:
      - insuniverse-server/libs/pg/src/smartro/smartro.service.ts:139
  - id: vendor:toss:failure
    status: conditional-unknown
    evidence: [A-vendor, A-comment]
    unknown_reason: 이 행의 후보 인덱스 policy_gates 가 빈 배열이다 — 게이트 부재. 이 벤더의 환경 키는 벤더 설정 블록 소유이고 조사 규약의 정책 게이트 목록과 이름 교집합이 0이라 조건을 걸 게이트 자체가 없다. 그래서 미판정의 원인은 게이트 값 미상이 아니라 도달 증거 부재이며 후보 인덱스가 status_basis 를 deployment-unproven 으로 기록했다.
    anchors:
      - insuniverse-server/libs/pg/src/toss/toss.exception.ts:3
      - insuniverse-server/libs/pg/src/toss/toss.service.ts:15
  - id: vendor:toss:no_data
    status: conditional-unknown
    evidence: [A-vendor, A-comment]
    unknown_reason: 이 행의 후보 인덱스 policy_gates 가 빈 배열이다 — 게이트 부재. 여기에 더해 이 결과 자체가 관측되지 않았다. 후보 인덱스의 evidence 가 빈 유일한 부류가 이 축의 자료없음 세 칸이고, 그 빈칸은 근거를 못 찾은 것이 아니라 벤더 API 에 그 개념이 없다는 관측이다(limitations).
    limitations:
      - 빌링키 발급·결제·취소 API 에 조회 결과 없음 개념이 없다 — 성공과 실패 두 갈래만 존재한다. 이것은 분류 누락이 아니라 개념 부재다
    anchors:
      - insuniverse-server/libs/pg/src/toss/toss.service.ts:43
  - id: vendor:toss:success
    status: conditional-unknown
    evidence: [A-vendor, A-comment]
    unknown_reason: 이 행의 후보 인덱스 policy_gates 가 빈 배열이다 — 게이트 부재. 이 벤더의 환경 키는 벤더 설정 블록 소유이고 조사 규약의 정책 게이트 목록과 이름 교집합이 0이라 조건을 걸 게이트 자체가 없다. 그래서 미판정의 원인은 게이트 값 미상이 아니라 도달 증거 부재이며 후보 인덱스가 status_basis 를 deployment-unproven 으로 기록했다.
    anchors:
      - insuniverse-server/libs/pg/src/toss/toss.service.ts:43
---

# 벤더 응답 의미 — 장애와 자료없음을 가르는 두 축

이 문서가 다루는 것은 **벤더가 무엇을 돌려줬을 때 그것을 장애로 볼 것인가 자료없음으로 볼
것인가**, 그리고 그 판단이 사용자 화면과 관리자 화면에 도달하는가다. 벤더 여덟이 각각 성공 ·
자료없음 · 실패 세 결과를 갖고, 여기에 어느 공급자의 응답을 채택하는가를 정하는 라우팅 규칙
하나가 더해져 정책 스물다섯이 된다.

**여기 없는 것 셋.** 벤더 native 코드값의 정의와 열거는 코드 인덱스 소유이고 이 문서는 참조만
한다 — 예외는 폴백 트리거 코드 하나이며 그 값 없이는 조건을 기술할 수 없어 라우팅 정책에서만
쓴다. 호출 제한시간 같은 수치 상수의 정의는 계약·한계 문서 소유이고 여기서는 해석하지 않는다.
통합 택소노미 열여덟 값의 정의는 런타임 인덱스 소유이며 이 문서는 그 값으로 결과를 해석만 한다.

**두 축을 한 표로 뭉치지 않는다.** 진료수집 다섯 벤더에는 통합 택소노미가 코드 안에 있고 발송 ·
결제 세 벤더에는 없다. 한 표에 섞으면 뒤쪽의 미상이 앞쪽의 판정과 같은 무게로 읽힌다. 각 표의
벤더 집합은 이 문서가 고르지 않고 런타임 인덱스의 축 값이 정한다.

## 정책 (기획)

**이 절에는 정책 블록이 없다. 스물다섯 전부가 `## 부록` 에 있다.**

응답 의미는 *무엇을 어떻게 해석하는가* 로 확정되고 *그 해석이 지금 걸려 있는가* 로 발효한다.
이 문서의 정책은 앞의 절반만 갖는다. 진료수집 축에서 해석이 발효하려면 **그 벤더가 공급자 풀에
들어 있어야** 하고, 풀의 구성과 다중 공급자 모드 여부는 배포 시점에 주입되는 값이라 저장소 안에
없다. 발송 · 결제 축은 사정이 다르다 — 걸 게이트 자체가 없고 대신 그 코드가 실제 운영에
도달했다는 증거가 없다. 두 사유는 형태가 다르지만 결론이 같다: 어느 쪽도 지금 발효한다고 말할 수
없다.

배치 어휘 여덟 중 본문 자격을 갖는 셋은 전부 *도달했다* 또는 *게이트가 켜져 있다* 를 주장하는데,
후보 인덱스의 이 축 스물다섯 행 전건이 도달 증거 없음으로 기록돼 있다. **본문 자격 0건이므로
본문 정책 0건이다.** 이것은 판정을 미룬 것이 아니라 판정 근거가 저장소 안에 없다는 관측이며,
근거가 서면 같은 게이트가 승격을 자동으로 허용한다.

**이 문서가 지는 답은 그 발효 여부가 아니라 그와 독립인 것이다** — 어떤 응답이 어떤 의미로
해석되는가(아래 두 대조표), 그 의미가 화면까지 가는가(소비 사슬), 그리고 결과가 갈릴 때 무엇이
채택되는가(라우팅 정책). 셋 다 코드로 확정돼 있고 게이트 값과 무관하다.

## 응답 의미 대조 — treat 축

진료수집 다섯 벤더. 벤더 코드는 통합 택소노미의 분류 하나로 수렴하며, `코드 수` 는 그 벤더 맵에서
해당 결과로 분류된 코드의 개수다. `사각` 은 이 문서가 고른 값이 아니라 인덱스와 아래 소비 사슬의
재계수에서 유도된 값이다.

| 정책 id | 벤더 | 결과 | 분류 기제 | 인덱스 근거 | 코드 수 | 사각 |
|---|---|---|---|---|---|---|
| vendor:codef:success | codef | success | 통합 택소노미 | code-only | 2 | 없음 |
| vendor:codef:no_data | codef | no_data | 통합 택소노미 | code-only | 0 | 분류 부재 |
| vendor:codef:failure | codef | failure | 통합 택소노미 | code-only | 19 | 없음 |
| vendor:coocon:success | coocon | success | 통합 택소노미 | code-only | 1 | 없음 |
| vendor:coocon:no_data | coocon | no_data | 통합 택소노미 | code-only | 1 | 화면 미분기 |
| vendor:coocon:failure | coocon | failure | 통합 택소노미 | code-only | 66 | 없음 |
| vendor:hyphen:success | hyphen | success | 통합 택소노미 | code-only | 1 | 없음 |
| vendor:hyphen:no_data | hyphen | no_data | 통합 택소노미 | code-only | 6 | 화면 미분기 |
| vendor:hyphen:failure | hyphen | failure | 통합 택소노미 | code-only | 43 | 없음 |
| vendor:inhouse:success | inhouse | success | 통합 택소노미 | code-only | 2 | 없음 |
| vendor:inhouse:no_data | inhouse | no_data | 통합 택소노미 | code-only | 1 | 화면 미분기 |
| vendor:inhouse:failure | inhouse | failure | 통합 택소노미 | code-only | 11 | 없음 |
| vendor:octover:success | octover | success | 통합 택소노미 | code-only | 4 | 없음 |
| vendor:octover:no_data | octover | no_data | 통합 택소노미 | code-only | 1 | 화면 미분기 |
| vendor:octover:failure | octover | failure | 통합 택소노미 | code-only | 84 | 없음 |

**자료없음 칸 다섯이 같은 값을 갖지 않는다.** 넷은 분류를 갖지만 그 분류가 화면에서 실패와
갈리지 않고(`화면 미분기`), 하나는 분류 자체가 0건이라 미수록 코드가 미상 폴백으로 떨어진다
(`분류 부재`). 뒤쪽이 더 나쁜 결손이다 — 앞쪽은 화면을 고치면 해소되지만 뒤쪽은 그 벤더가
자료없음을 실제로 구분하는지조차 저장소 안 근거로 갈리지 않는다.

## 응답 의미 대조 — non-treat 축

발송 · 결제 세 벤더. 통합 택소노미가 없고 각 벤더 서비스가 응답을 직접 해석한다. `코드 수` 열이
대시인 것은 값을 못 찾은 것이 아니라 **분류 기제가 없어 셀 대상이 없다**는 뜻이다.

| 정책 id | 벤더 | 결과 | 분류 기제 | 인덱스 근거 | 코드 수 | 사각 |
|---|---|---|---|---|---|---|
| vendor:aligo:success | aligo | success | 없음 | code-only | — | 없음 |
| vendor:aligo:no_data | aligo | no_data | 없음 | not-observed | — | 개념 부재 |
| vendor:aligo:failure | aligo | failure | 없음 | code-only | — | 없음 |
| vendor:smartro:success | smartro | success | 없음 | code-only | — | 없음 |
| vendor:smartro:no_data | smartro | no_data | 없음 | not-observed | — | 개념 부재 |
| vendor:smartro:failure | smartro | failure | 없음 | code-only | — | 없음 |
| vendor:toss:success | toss | success | 없음 | code-only | — | 없음 |
| vendor:toss:no_data | toss | no_data | 없음 | not-observed | — | 개념 부재 |
| vendor:toss:failure | toss | failure | 없음 | code-only | — | 없음 |

**이 축의 자료없음 세 칸은 `개념 부재` 이지 미조사가 아니다.** 발송 API 에는 조회 결과라는 것이
없고 결제 API 에는 승인과 실패 두 갈래만 있다. 진료수집 축의 `분류 부재` 와 같은 어휘로 접으면
"코드를 더 넣으면 해소된다" 로 읽히는데 여기서는 넣을 코드가 존재하지 않는다.

라우팅 정책 `vendor:__dispatch__:fallback` 은 **두 표 어디에도 없다.** 그것은 벤더 하나의 결과가
아니라 여러 벤더의 결과 사이에서 무엇을 채택하는가에 대한 규칙이고, 어느 벤더 열에도 귀속되지
않는다. 부록과 예외·폴백 절이 그 정책을 진다.

## 구별 신호 소비 사슬

응답 의미가 화면까지 가는 통로다. 행 집합은 이 문서가 고르지 않고 계획서가 봉인한 신호 일곱이며,
`server 소비` · `site 소비` · `admin 소비` 세 열은 동결 세 트리에서 그 토큰을 담은 파일 수를 게이트가
다시 센 값이다. `도달` 은 그 계수만으로 정하지 않는다 — 계수는 상한이고, 판정은 그 표면의 파일이
진료수집 축 전용 토큰을 함께 담는가로 좁힌다.

| 신호 | 생산 앵커 | 소비 표면 | server 소비 | site 소비 | admin 소비 | 도달 |
|---|---|---|---|---|---|---|
| category | insuniverse-server/apps/api/src/modules/treat/error/treat-error-category.ts:5 | 예외 필터가 응답에 붙이고 관리자 모니터가 읽는다 | 46 | 23 | 34 | 진단 표면만 |
| retryable | insuniverse-server/apps/api/src/modules/treat/error/treat-error-category.ts:39 | 예외 필터가 응답에 붙이고 site 가 파생 재시도 헬퍼로 인증 화면에서 분기한다 | 7 | 5 | 2 | 사용자 경로 |
| userMessage | insuniverse-server/apps/api/src/modules/treat/error/treat-error-category.ts:30 | 정의 파일과 진단 모듈, 관리자 모니터 API | 5 | 0 | 4 | 진단 표면만 |
| alimtalkMessage | insuniverse-server/apps/api/src/modules/treat/error/treat-error-category.ts:32 | 정의 파일과 알림톡 이벤트 처리기 | 2 | 0 | 0 | 미도달 |
| audience | insuniverse-server/apps/api/src/modules/treat/error/treat-error-category.ts:34 | 정의 파일과 진단 모듈 | 3 | 0 | 1 | 미도달 |
| NO_DATA | insuniverse-server/apps/api/src/modules/treat/error/treat-error-category.ts:17 | 택소노미 정의와 벤더 맵, 자체 수집 서비스 | 5 | 0 | 1 | 미도달 |
| PROVIDER_FAULT_CODES | insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:35 | 디스패처 루프에서만 참조된다 | 1 | 0 | 0 | 미도달 |

**Q17 — 장애를 자료없음으로 오처리하지 않으려면 무엇을 보아야 하는가.** `category` 다. 그리고
`retryable` 이 **아니다.** 자료없음의 재시도성은 거짓이고 입력 오류 · 인증번호 오류 · 미상도 전부
거짓이라, 재시도 신호로는 자료없음과 실패가 갈리지 않는다. 갈리는 것은 분류 값 자체뿐이며 그
값을 보려면 응답에 붙은 `category` 를 읽어야 한다.

**Q40 전반부 — 결과가 갈리면 무엇을 채택하는가.** 첫 성공이다. 디스패처는 공급자를 순서대로 돌며
성공 응답이 나오는 즉시 그것을 채택하고 반환한다. 폴백은 두 경우에만 일어난다 — 응답 코드가
공급자측 장애 목록에 있을 때, 그리고 호출이 예외로 끝날 때. **사용자측 실패는 폴백하지 않고 그대로
반환된다**, 다음 공급자에게 물어도 같은 답이 오기 때문이다. 좌표는 라우팅 정책의 앵커가 진다.

**Q40 후반부 — 자료없음과 장애가 사용자 화면에서 구별되는가. 구별되지 않는다.** 위 표의 `도달`
열이 그 답이고, 이 문서의 주장이 아니라 게이트가 동결 세 트리에서 다시 센 값이다. 사용자 경로에
닿는 신호는 `retryable` 하나뿐인데 그 값이 두 경우에 모두 거짓이다. 분류 값을 담은 `category` 는
관리자 모니터까지만 가고, 사용자에게 보일 문구를 담은 `userMessage` 도 같은 자리에서 멈춘다.
알림톡 문구와 대상 구분은 사용자 화면 어느 쪽에도 도달하지 않는다.

**택소노미의 자료없음 값 자체는 관리자 화면에도 코드로 도달하지 않는다.** 위 표의 `NO_DATA` 행이
`미도달` 인 것이 그 값이며, 관리자 모니터가 그 값을 따로 다루는 분기 없이 기본 낙하로 접기
때문이다. 운영자가 그 구분을 보는 경로는 그 값 자체가 아니라 `category` 문자열의 표시다.

**이 판정에 남는 사각 둘.** 계수는 토큰 단어 일치라 다의어가 섞인다 — `site 소비` 23 중 상당수는
게시판·강좌 화면의 같은 이름이며 진료수집 축과 무관하다. 주석 안 등장도 계수에서는 코드와
구별되지 않는다 — `admin 소비` 의 `NO_DATA` 한 건은 주석 행이다. 그래서 `도달` 은 계수가 아니라 축
전용 토큰과의 파일 교집합이 정하고 **그 교집합은 양쪽 다 코드 행만 본다** — 위 `NO_DATA` 행이
`미도달` 인 것이 그 좁힘의 결과다. 두 사각 모두 게이트 출력에 매 실행 찍힌다.

## 강제 지점 (개발)

정책 내용을 다시 쓰지 않는다. 각 정책이 저장소 안 **어디에서** 강제되는가와 그 기제만 적는다.
배치가 부록인 정책도 이 절에 있어야 한다 — 이 절의 id 집합은 배치와 무관하게 프론트매터 전체와
결속돼 있다. 기준점은 전건 동결 stg `4d798f55` 다.

### vendor:__dispatch__:fallback

- 강제 방식: 디스패처 루프. 공급자 목록을 순회하며 성공 판정 · 공급자측 장애 코드 목록 · 예외 세 갈래로 분기한다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:35` (장애 코드 목록) · `:73` (공급자 풀 맵) · `insuniverse-server/apps/api/src/config/configuration.ts:29` (모드 선택)
- 게이트: `TREAT_PROVIDER` · `TREAT_POOL`

### vendor:aligo:failure

- 강제 방식: 벤더 전용 예외 클래스. 호출 실패를 하나의 서버 오류 예외로 감싼다.
- 앵커: `insuniverse-server/libs/aligo/src/aligo.exception.ts:3`
- 게이트: 없음 — 이 행의 후보 인덱스 `policy_gates` 가 빈 배열이다.

### vendor:aligo:no_data

- 강제 방식: 없음. 발송 서비스의 응답 처리 지점에 조회 결과 없음 분기가 존재하지 않는다.
- 앵커: `insuniverse-server/libs/aligo/src/aligo.service.ts:68` — 부재의 관측 지점이다.
- 게이트: 없음 — 이 행의 후보 인덱스 `policy_gates` 가 빈 배열이다.

### vendor:aligo:success

- 강제 방식: 응답 DTO 변환. 성공 판정 분기 없이 응답 본문을 그대로 옮긴다.
- 앵커: `insuniverse-server/libs/aligo/src/aligo.service.ts:68`
- 게이트: 없음 — 이 행의 후보 인덱스 `policy_gates` 가 빈 배열이다.

### vendor:codef:failure

- 강제 방식: 통합 택소노미 맵. 벤더 코드를 분류 하나로 접는 상수 맵의 이 벤더 구간이 정한다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:9`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:codef:no_data

- 강제 방식: 통합 택소노미 맵의 부재 구간 + 미수록 코드 폴백. 이 벤더 구간에 자료없음 분류가 없어 미수록 코드가 미상으로 떨어진다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:9`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:codef:success

- 강제 방식: 통합 택소노미 맵. 벤더 코드를 분류 하나로 접는 상수 맵의 이 벤더 구간이 정한다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:9`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:coocon:failure

- 강제 방식: 통합 택소노미 맵. 벤더 코드를 분류 하나로 접는 상수 맵의 이 벤더 구간이 정한다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:34`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:coocon:no_data

- 강제 방식: 통합 택소노미 맵. 이 벤더 구간에 자료없음 분류가 있고 응답 정규화를 거쳐 같은 형태로 흐른다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:34`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:coocon:success

- 강제 방식: 통합 택소노미 맵. 벤더 코드를 분류 하나로 접는 상수 맵의 이 벤더 구간이 정한다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:34`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:hyphen:failure

- 강제 방식: 통합 택소노미 맵. 벤더 코드를 분류 하나로 접는 상수 맵의 이 벤더 구간이 정한다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:134`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:hyphen:no_data

- 강제 방식: 통합 택소노미 맵. 이 벤더 구간의 자료없음 분류는 코드 여섯을 담아 이 축에서 가장 두껍다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:134`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:hyphen:success

- 강제 방식: 통합 택소노미 맵. 벤더 코드를 분류 하나로 접는 상수 맵의 이 벤더 구간이 정한다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:134`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:inhouse:failure

- 강제 방식: 통합 택소노미 맵. 벤더 코드를 분류 하나로 접는 상수 맵의 이 벤더 구간이 정한다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:168`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER` · `INHOUSE_CAR_CANARY`

### vendor:inhouse:no_data

- 강제 방식: 통합 택소노미 맵. 이 벤더 구간에 자료없음 분류가 있고 벤더 서비스가 같은 이름을 직접 참조하는 유일한 벤더다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:168`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER` · `INHOUSE_CAR_CANARY`

### vendor:inhouse:success

- 강제 방식: 통합 택소노미 맵. 벤더 코드를 분류 하나로 접는 상수 맵의 이 벤더 구간이 정한다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:168`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER` · `INHOUSE_CAR_CANARY`

### vendor:octover:failure

- 강제 방식: 통합 택소노미 맵. 이 벤더 구간이 이 축에서 가장 두껍다 — 공통 코드군이 한 번에 등록돼 있다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:81`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:octover:no_data

- 강제 방식: 통합 택소노미 맵. 이 벤더 구간에 자료없음 분류가 있고 응답 정규화를 거쳐 같은 형태로 흐른다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:81`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:octover:success

- 강제 방식: 통합 택소노미 맵. 벤더 코드를 분류 하나로 접는 상수 맵의 이 벤더 구간이 정한다.
- 앵커: `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:81`
- 게이트: `TREAT_POOL` · `TREAT_PROVIDER`

### vendor:smartro:failure

- 강제 방식: 결과 DTO 판정 + 벤더 전용 예외. 승인 실패는 예외가 아니라 실패 플래그를 단 결과로 반환되고, 호출 자체의 실패만 예외 경로로 간다.
- 앵커: `insuniverse-server/libs/pg/src/smartro/smartro.service.ts:139` · `insuniverse-server/libs/pg/src/smartro/smartro.exception.ts:3`
- 게이트: 없음 — 이 행의 후보 인덱스 `policy_gates` 가 빈 배열이다.

### vendor:smartro:no_data

- 강제 방식: 없음. 승인 판정 지점에 조회 결과 없음 분기가 존재하지 않는다.
- 앵커: `insuniverse-server/libs/pg/src/smartro/smartro.service.ts:139` — 부재의 관측 지점이다.
- 게이트: 없음 — 이 행의 후보 인덱스 `policy_gates` 가 빈 배열이다.

### vendor:smartro:success

- 강제 방식: 결과 DTO 판정. 응답의 결과 코드가 승인 성공 코드 둘 중 하나일 때만 성공으로 접는다.
- 앵커: `insuniverse-server/libs/pg/src/smartro/smartro.service.ts:139`
- 게이트: 없음 — 이 행의 후보 인덱스 `policy_gates` 가 빈 배열이다.

### vendor:toss:failure

- 강제 방식: 벤더 전용 예외 + 노출 허용 목록. 대부분의 실패는 예외로 감싸지만 결제요청 경로만 실패 상태를 단 결과로 반환하며, 허용 목록에 든 오류에 한해 벤더 메시지를 그대로 전달한다.
- 앵커: `insuniverse-server/libs/pg/src/toss/toss.exception.ts:3` · `insuniverse-server/libs/pg/src/toss/toss.service.ts:15`
- 게이트: 없음 — 이 행의 후보 인덱스 `policy_gates` 가 빈 배열이다.

### vendor:toss:no_data

- 강제 방식: 없음. 응답 처리 지점에 조회 결과 없음 분기가 존재하지 않는다.
- 앵커: `insuniverse-server/libs/pg/src/toss/toss.service.ts:43` — 부재의 관측 지점이다.
- 게이트: 없음 — 이 행의 후보 인덱스 `policy_gates` 가 빈 배열이다.

### vendor:toss:success

- 강제 방식: 응답 DTO 변환. 성공 판정 분기 없이 응답 본문을 그대로 옮긴다.
- 앵커: `insuniverse-server/libs/pg/src/toss/toss.service.ts:43`
- 게이트: 없음 — 이 행의 후보 인덱스 `policy_gates` 가 빈 배열이다.

## 적용 범위 (actor × 서비스)

**`적용` 은 위 §구별 신호 소비 사슬의 `도달` 이 그 표면을 지목한 경우에만 쓴다.** 그 밖은 `—`
이며 빈 칸이 아니라 관측된 부재다.

actor 다섯 열이 전건 `—` 인 데에는 축 판정이 하나 걸려 있다. `actors` 는 **로그인 주체 축**이고
(정본이 로그인하지 않는 표면을 이 축의 여집합으로 뒀다) 응답 의미가 닿는 사용자 화면은 알림톡
링크로 진입하는 인증 화면 계열이다. 그 화면에 도달하는 사람이 어느 로그인 주체인가는 저장소
안에서 갈리지 않는다 — 개인 진입 계열과 그 대응 계열이 같은 재시도 신호를 소비할 뿐 계정 종류로
분기하지 않는다. 관리자 모니터는 로그인 주체 축의 원소를 지목하지만, 그 화면이 읽는 것은 이
문서의 정책이 아니라 그 정책이 만든 값이므로 같은 이유로 `—` 다.

서비스 축은 갈린다. 모든 앵커가 server 저장소에 있으므로 `server` 는 전건 `적용` 이고, `site` 와
`admin` 은 소비 사슬이 그 표면으로의 도달을 보인 진료수집 다섯 벤더에서만 `적용` 이다. 발송 ·
결제 축과 라우팅 정책은 어느 신호도 그 두 표면에 닿지 않아 `—` 다.

| 정책 id | 관리자 | 영업대리점 | 기업담당자 | 일반회원 | 기업회원 | server | site | admin |
|---|---|---|---|---|---|---|---|---|
| vendor:__dispatch__:fallback | — | — | — | — | — | 적용 | — | — |
| vendor:aligo:failure | — | — | — | — | — | 적용 | — | — |
| vendor:aligo:no_data | — | — | — | — | — | 적용 | — | — |
| vendor:aligo:success | — | — | — | — | — | 적용 | — | — |
| vendor:codef:failure | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:codef:no_data | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:codef:success | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:coocon:failure | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:coocon:no_data | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:coocon:success | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:hyphen:failure | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:hyphen:no_data | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:hyphen:success | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:inhouse:failure | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:inhouse:no_data | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:inhouse:success | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:octover:failure | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:octover:no_data | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:octover:success | — | — | — | — | — | 적용 | 적용 | 적용 |
| vendor:smartro:failure | — | — | — | — | — | 적용 | — | — |
| vendor:smartro:no_data | — | — | — | — | — | 적용 | — | — |
| vendor:smartro:success | — | — | — | — | — | 적용 | — | — |
| vendor:toss:failure | — | — | — | — | — | 적용 | — | — |
| vendor:toss:no_data | — | — | — | — | — | 적용 | — | — |
| vendor:toss:success | — | — | — | — | — | 적용 | — | — |

## 예외·폴백

예외가 없는 정책도 행을 둔다 — 없다는 것도 확인의 결과이며 그 확인 근거를 함께 적는다.

| 정책 id | 예외 | 폴백 | 확인 근거 |
|---|---|---|---|
| vendor:__dispatch__:fallback | 다중 공급자 모드가 아니면 규칙 자체가 성립하지 않는다 (기본값은 단일 공급자) | 세 갈래다 — 성공 응답이 나오면 그 자리에서 채택하고 반환한다 · 응답 코드가 공급자측 장애 목록(`CF-12103`)에 있거나 호출이 예외로 끝나면 다음 공급자로 넘어간다 · 그 외 실패는 폴백 없이 그대로 반환한다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:35` · `insuniverse-server/apps/api/src/config/configuration.ts:29` |
| vendor:aligo:failure | 없음 | 없음 — 다중 공급자 폴백은 진료수집 축 전용이고 이 벤더는 디스패처 풀에 없다 | 런타임 인덱스의 이 벤더 `fallback.kind` 가 `none` 이고 그 사유가 같은 칸에 있다 |
| vendor:aligo:no_data | 해당 결과가 성립하지 않는다 — 발송 API 에 조회 결과 개념이 없다 | 없음 | `insuniverse-server/libs/aligo/src/aligo.service.ts:68` — 응답 처리 지점에 그 분기가 없다 |
| vendor:aligo:success | 없음 | 없음 — 다중 공급자 폴백은 진료수집 축 전용이고 이 벤더는 디스패처 풀에 없다 | 런타임 인덱스의 이 벤더 `fallback.kind` 가 `none` 이다 |
| vendor:codef:failure | 사용자측 실패는 다음 공급자로 넘어가지 않는다 | 공급자측 장애 코드와 호출 예외에 한해 다음 공급자로 넘어간다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:35` |
| vendor:codef:no_data | 이 벤더에는 해당 분류가 0건이라 이 결과로 접히는 응답이 없다 | 미수록 코드는 미상 분류로 떨어진다 | `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:9` |
| vendor:codef:success | 없음 | 성공은 폴백 대상이 아니다 — 첫 성공이 즉시 채택된다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:73` |
| vendor:coocon:failure | 사용자측 실패는 다음 공급자로 넘어가지 않는다 | 공급자측 장애 코드와 호출 예외에 한해 다음 공급자로 넘어간다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:35` |
| vendor:coocon:no_data | 없음 | 없음 — 자료없음은 재시도 대상도 폴백 대상도 아니다 | `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:34` |
| vendor:coocon:success | 없음 | 성공은 폴백 대상이 아니다 — 첫 성공이 즉시 채택된다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:73` |
| vendor:hyphen:failure | 사용자측 실패는 다음 공급자로 넘어가지 않는다 | 공급자측 장애 코드와 호출 예외에 한해 다음 공급자로 넘어간다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:35` |
| vendor:hyphen:no_data | 없음 | 없음 — 자료없음은 재시도 대상도 폴백 대상도 아니다 | `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:134` |
| vendor:hyphen:success | 없음 | 성공은 폴백 대상이 아니다 — 첫 성공이 즉시 채택된다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:73` |
| vendor:inhouse:failure | 사용자측 실패는 다음 공급자로 넘어가지 않는다 | 공급자측 장애 코드와 호출 예외에 한해 다음 공급자로 넘어간다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:35` |
| vendor:inhouse:no_data | 없음 | 없음 — 자료없음은 재시도 대상도 폴백 대상도 아니다 | `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:168` |
| vendor:inhouse:success | 없음 | 성공은 폴백 대상이 아니다 — 첫 성공이 즉시 채택된다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:73` |
| vendor:octover:failure | 사용자측 실패는 다음 공급자로 넘어가지 않는다 | 공급자측 장애 코드와 호출 예외에 한해 다음 공급자로 넘어간다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:35` |
| vendor:octover:no_data | 없음 | 없음 — 자료없음은 재시도 대상도 폴백 대상도 아니다 | `insuniverse-server/apps/api/src/modules/treat/error/treat-error-vendor-map.ts:81` |
| vendor:octover:success | 없음 | 성공은 폴백 대상이 아니다 — 첫 성공이 즉시 채택된다 | `insuniverse-server/apps/api/src/modules/treat/dispatch/treat-dispatcher.service.ts:73` |
| vendor:smartro:failure | 승인 실패와 호출 실패가 다른 경로로 간다 — 앞은 결과 DTO, 뒤는 예외 | 없음 — 다중 공급자 폴백은 진료수집 축 전용이다 | `insuniverse-server/libs/pg/src/smartro/smartro.service.ts:139` · `insuniverse-server/libs/pg/src/smartro/smartro.exception.ts:3` |
| vendor:smartro:no_data | 해당 결과가 성립하지 않는다 — 승인과 실패 두 갈래뿐이다 | 없음 | `insuniverse-server/libs/pg/src/smartro/smartro.service.ts:139` — 승인 판정 지점에 그 분기가 없다 |
| vendor:smartro:success | 없음 | 없음 — 다중 공급자 폴백은 진료수집 축 전용이다 | 런타임 인덱스의 이 벤더 `fallback.kind` 가 `none` 이다 |
| vendor:toss:failure | 결제요청 경로만 예외 대신 실패 상태를 단 결과를 반환한다 | 노출 허용 목록에 든 오류는 벤더 메시지를 그대로 전달하고 나머지는 공통 메시지로 덮는다 | `insuniverse-server/libs/pg/src/toss/toss.service.ts:15` · `insuniverse-server/libs/pg/src/toss/toss.exception.ts:3` |
| vendor:toss:no_data | 해당 결과가 성립하지 않는다 — 성공과 실패 두 갈래뿐이다 | 없음 | `insuniverse-server/libs/pg/src/toss/toss.service.ts:43` — 응답 처리 지점에 그 분기가 없다 |
| vendor:toss:success | 없음 | 없음 — 다중 공급자 폴백은 진료수집 축 전용이다 | 런타임 인덱스의 이 벤더 `fallback.kind` 가 `none` 이다 |

## 부록

이 절의 정책은 **현행 발효 여부가 판정되지 않아** 본문에서 격리한다. 진료수집 축은 공급자 풀
편성이 저장소 밖 주입값이고, 발송 · 결제 축은 걸 게이트가 없는 대신 그 코드가 운영에 도달했다는
증거가 없다. 그 상태로 본문에 두면 독자가 지금 걸려 있는 응답 해석 규칙으로 읽는다.

**여기 실린 어떤 정책도 그 해석이 틀렸다고 말하지 않는다.** 미판정은 부정이 아니다. 해석 규칙
자체는 동결 stg `4d798f55` 의 코드로 확정되며, 판정되지 않은 것은 그 규칙이 지금 어느 벤더에
걸려 있는가다.

각 블록은 **그 결과의 의미와 그것이 사용자·관리자에게 무엇으로 보이는가**를 코드 심볼 없이
적는다. 좌표는 프론트매터 `anchors` 와 `## 강제 지점 (개발)` 이 진다.

### vendor:__dispatch__:fallback

여러 공급자에게 같은 진료내역을 물을 수 있을 때 무엇을 답으로 삼는가의 규칙이다. **첫 성공을
채택한다** — 순서대로 물어 성공이 나오면 그 자리에서 멈춘다. 뒤에 더 좋은 답이 있을지는 보지
않는다.

폴백은 두 경우에만 일어난다. 공급자 쪽 사정으로 실패했을 때, 그리고 호출이 응답 없이 끝났을 때다.
**입력이 틀려서 실패한 경우에는 폴백하지 않는다** — 다음 공급자에게 물어도 같은 답이 오기
때문이며, 폴백하면 같은 실패를 여러 번 겪게 하는 대신 시간만 쓴다.

사용자에게 일어나는 일: 한 공급자가 막혀도 사용자는 그 사실을 모른 채 다른 공급자의 결과를 받는다.
반대로 입력을 잘못 넣었으면 즉시 실패가 돌아온다. 관리자에게는 어느 공급자가 답했는지가 모니터에
남는다.

이 규칙이 지금 걸려 있는지는 판정되지 않았다 — 기본값은 단일 공급자이고 다중 모드일 때만 이
규칙이 성립한다.

### vendor:aligo:failure

알림톡·문자 발송 요청이 실패했을 때 그것을 하나의 서버 오류로 접는다. 벤더가 왜 거절했는지는
이 지점에서 구분되지 않고 한 덩어리가 된다.

사용자에게 일어나는 일: 발송이 실패해도 사용자 화면에 그 사유가 나뉘어 보이지 않는다. 관리자도
같은 한 덩어리를 본다.

### vendor:aligo:no_data

**이 결과는 성립하지 않는다.** 발송 API 에는 조회라는 동작이 없고 따라서 조회 결과가 없다는 답도
없다. 발송을 요청했는가와 발송이 완료됐는가만 있다.

이것을 진료수집 축의 자료없음과 같은 칸으로 읽으면 안 된다 — 저기서는 물었는데 없다는 답이 오고,
여기서는 물을 것이 없다.

### vendor:aligo:success

발송 요청이 정상 응답을 받으면 그 응답 본문을 그대로 결과로 삼는다. 벤더가 준 결과코드를 보고
성공인지 다시 판정하는 단계가 없다.

사용자에게 일어나는 일: 요청이 접수됐다는 것까지가 이 결과가 보장하는 전부이며, 실제로 도착했는지는
별도의 발송 이력 확인이 답한다.

### vendor:codef:failure

이 공급자가 진료내역을 가져오지 못했을 때의 사유들이다. 인증서·인증번호·연령 제한처럼 사용자가
고칠 수 있는 것과 기관 오류·네트워크처럼 기다리면 되는 것이 한 분류 체계 안에서 갈린다.

사용자에게 일어나는 일: 화면은 그 갈림 중 **기다리면 되는가만** 받는다. 무엇이 잘못됐는지의 구체는
관리자 모니터까지만 간다.

### vendor:codef:no_data

**이 공급자에는 자료없음으로 분류된 응답이 하나도 없다.** 조회 결과가 없다는 답이 오더라도 그것을
자료없음으로 접는 규칙이 없어 알 수 없는 실패로 떨어지고, 그 실패의 대상은 사용자가 아니라
운영자로 표시된다.

사용자에게 일어나는 일: 진료내역이 없어서 못 가져온 경우와 원인 불명으로 못 가져온 경우가 같은
화면이 된다. **이 문서의 가장 나쁜 결손이 여기다.**

이것이 코드 목록이 아직 덜 채워진 것인지 이 공급자가 실제로 그 둘을 구분하지 않는 것인지는
저장소 안 근거로 갈리지 않는다. 갈라 줄 설계 문서를 두 코드 파일이 출처로 적고 있으나 그 문서가
저장소에 없다.

### vendor:codef:success

이 공급자가 진료내역을 가져왔거나 추가 인증이 필요하다고 답한 경우다. 추가 인증 요청도 실패가
아니라 성공 계열로 접힌다 — 흐름이 계속되기 때문이다.

사용자에게 일어나는 일: 인증 화면이 다음 단계로 넘어간다.

### vendor:coocon:failure

이 공급자가 진료내역을 가져오지 못했을 때의 사유들이다. 이 축에서 두 번째로 두꺼운 분류 구간이며
인증서 · 인증 미승인 · 요청 한도까지 갈린다.

사용자에게 일어나는 일: 화면은 그 갈림 중 기다리면 되는가만 받는다.

### vendor:coocon:no_data

조회는 됐는데 가져올 진료내역이 없는 경우다. **이 공급자는 그것을 실패와 다른 것으로 분류한다.**

사용자에게 일어나는 일: 그럼에도 화면에서는 실패와 구별되지 않는다. 분류는 있지만 그 분류를 담은
값이 사용자 응답 경로까지 가지 않고, 함께 가는 재시도 신호는 자료없음과 여러 실패에서 똑같이
거짓이기 때문이다. 관리자 모니터에서는 갈린다.

### vendor:coocon:success

이 공급자가 진료내역을 가져왔거나 추가 인증이 필요하다고 답한 경우다. 응답 형태가 다른 공급자와
달라 공통 형태로 한 번 옮긴 뒤 흐른다.

사용자에게 일어나는 일: 인증 화면이 다음 단계로 넘어간다. 어느 공급자가 답했는지는 보이지 않는다.

### vendor:hyphen:failure

이 공급자가 진료내역을 가져오지 못했을 때의 사유들이다. 운영 중 실측으로 코드가 여러 차례
보강된 구간이다.

사용자에게 일어나는 일: 화면은 그 갈림 중 기다리면 되는가만 받는다.

### vendor:hyphen:no_data

조회는 됐는데 가져올 진료내역이 없는 경우다. **이 공급자의 자료없음 분류가 이 축에서 가장
두껍다** — 같은 뜻의 응답을 여러 형태로 주기 때문이다.

사용자에게 일어나는 일: 그럼에도 화면에서는 실패와 구별되지 않는다. 이유는 다른 공급자와 같다.

### vendor:hyphen:success

이 공급자가 진료내역을 가져왔거나 추가 인증이 필요하다고 답한 경우다. 응답 형태가 달라 공통
형태로 한 번 옮긴 뒤 흐른다.

사용자에게 일어나는 일: 인증 화면이 다음 단계로 넘어간다.

### vendor:inhouse:failure

자체 수집기가 진료내역을 가져오지 못했을 때의 사유들이다. 외부 공급자와 같은 분류 체계를 쓰며
혼잡으로 인한 지연이 별도 분류를 갖는 유일한 공급자다.

사용자에게 일어나는 일: 화면은 그 갈림 중 기다리면 되는가만 받는다.

### vendor:inhouse:no_data

조회는 됐는데 가져올 진료내역이 없는 경우다. **이 공급자는 자체 수집기 안에서 그 구분을 직접
다루는 유일한 공급자다** — 다른 공급자는 코드 맵에서만 갈린다.

사용자에게 일어나는 일: 그럼에도 화면에서는 실패와 구별되지 않는다. 구분이 코드 안쪽에서 더
분명한 것과 그것이 화면까지 가는 것은 다른 문제다.

### vendor:inhouse:success

자체 수집기가 진료내역을 가져왔거나 추가 인증이 필요하다고 답한 경우다.

사용자에게 일어나는 일: 인증 화면이 다음 단계로 넘어간다. 다만 이 공급자는 다른 공급자와 달리
별도의 편성 조건이 하나 더 걸려 있어 발효 조건이 한 겹 더 좁다.

### vendor:octover:failure

이 공급자가 진료내역을 가져오지 못했을 때의 사유들이다. **이 축에서 가장 두꺼운 구간이며** 공통
오류군이 한 번에 등록돼 있다.

사용자에게 일어나는 일: 화면은 그 갈림 중 기다리면 되는가만 받는다. 이 공급자에서 특히 그 손실이
크다 — 갈래가 가장 많은데 도달하는 것은 다른 공급자와 똑같이 하나뿐이다.

### vendor:octover:no_data

조회는 됐는데 가져올 진료내역이 없는 경우다. 이 공급자는 그것을 실패와 다른 것으로 분류한다.

사용자에게 일어나는 일: 그럼에도 화면에서는 실패와 구별되지 않는다.

### vendor:octover:success

이 공급자가 진료내역을 가져왔거나 추가 인증이 필요하다고 답한 경우다. 응답 형태가 달라 공통
형태로 한 번 옮긴 뒤 흐른다.

사용자에게 일어나는 일: 인증 화면이 다음 단계로 넘어간다.

### vendor:smartro:failure

일반 결제 승인이 거절된 경우다. **거절은 오류가 아니라 결과로 다뤄진다** — 승인되지 않았다는
사실을 담은 결과가 정상적으로 돌아온다. 호출 자체가 닿지 못한 경우만 별도의 오류 경로로 간다.

사용자에게 일어나는 일: 결제가 되지 않았다는 것은 전달되지만 왜 거절됐는지의 구체는 이 지점에서
갈리지 않는다.

### vendor:smartro:no_data

**이 결과는 성립하지 않는다.** 결제 승인·취소에는 승인됐는가와 되지 않았는가만 있고 조회 결과가
없다는 답이 없다.

### vendor:smartro:success

응답의 결과 코드가 승인 성공을 뜻하는 둘 중 하나일 때만 성공으로 접는다. **이 축에서 벤더 결과
코드를 보고 성공 여부를 다시 판정하는 유일한 벤더다** — 나머지 둘은 정상 응답을 곧 성공으로 본다.

사용자에게 일어나는 일: 결제 완료 화면으로 넘어간다.

### vendor:toss:failure

정기결제 계열의 호출이 실패한 경우다. 대부분은 하나의 서버 오류로 접히지만 **결제요청 경로만
예외적으로** 실패 상태를 담은 결과를 돌려주고, 그 경로에서는 미리 정한 몇 가지 오류에 한해 벤더가
준 문구를 사용자에게 그대로 보여 준다. 나머지는 공통 문구로 덮인다.

사용자에게 일어나는 일: 같은 결제 실패라도 어느 경로에서 났느냐에 따라 보이는 문구의 구체성이
다르다.

### vendor:toss:no_data

**이 결과는 성립하지 않는다.** 빌링키 발급 · 결제 · 취소에는 성공과 실패만 있고 조회 결과가 없다는
답이 없다.

### vendor:toss:success

호출이 정상 응답을 받으면 그 응답 본문을 그대로 결과로 삼는다. 벤더 결과코드를 보고 성공인지 다시
판정하는 단계가 없다.

사용자에게 일어나는 일: 결제 또는 빌링키 등록이 완료된 것으로 흐름이 이어진다.

## 연혁

릴리스 태그가 존재하지 않는다. 릴리스 열은 `—` 로 두고 커밋 SHA 로 추적한다. 행은
`docs/_meta/index/commits.server.jsonl` 이 이 문서의 앵커 경로 접촉으로 기록한 커밋 집합
(65건) 안에서 **응답 의미가 바뀐 시점**만 골랐다. 코드 매핑을 늘리기만 한 커밋은 해석 규칙을
바꾸지 않으므로 제외했고, 그 판정은 게이트가 하지 못한다 — 게이트는 앵커 경로 접촉까지만 본다.

**만들 수 없는 행이 하나 있다.** 분류와 재시도성이 HTTP 오류 응답에 실린 시점(2026-06-08)은 이
문서의 Q40 답변에서 가장 무거운 한 지점인데, 그 변경이 일어난 파일은 예외 필터이고 예외 필터는
이 문서 어느 정책의 앵커도 아니다. 응답에 무엇이 실리는가는 이 문서가 소유한 벤더 응답 해석이
아니라 그 위층의 응답 형태이기 때문이다. 그 시점은 §구별 신호 소비 사슬이 좌표와 함께 지고
여기서는 행으로 만들지 않는다.

| 릴리스 | 날짜 | SHA | 변경 요약 |
|---|---|---|---|
| — | 2026-06-04 | `21b4a602` | 진료수집에 둘째 공급자가 붙고 공급자 스위치가 생긴다 — 같은 요청에 결과가 갈릴 수 있게 된 첫 시점 |
| — | 2026-06-05 | `af16d981` | 다중 공급자 디스패처 신설 — 결과가 갈릴 때 무엇을 채택하는가가 이때 처음 규칙이 된다 |
| — | 2026-06-06 | `91158193` | 1차 실패 시 다음 공급자로 넘기는 폴백 도입 — **사용자측 실패를 폴백에서 제외하는 갈림이 여기서 선다** |
| — | 2026-06-08 | `a6e323b5` | 벤더 통합 오류 분류 체계 신설 — 벤더 코드가 분류 하나로 수렴하기 시작한다 |
| — | 2026-06-12 | `45f2698b` | 자체 수집기가 다섯째 공급자로 편입 — 통합 분류의 대상이 넷에서 다섯이 된다 |
| — | 2026-06-12 | `dcb54846` | 자체 수집기의 오류 분류와 자료없음 처리를 정합 — 자료없음을 실패와 다르게 다루는 공급자가 넷이 된다 |
| — | 2026-06-30 | `90b878fb` | 채택 순서를 고정 순서에서 우선순위 기준으로 전환 — 첫 성공 채택은 그대로이나 무엇이 첫째인가가 바뀐다 |
| — | 2026-07-06 | `3f23349d` | 정기결제 실패에서 벤더 문구를 그대로 노출할 오류 목록 도입 — 이 축에서 실패 문구의 구체성이 경로마다 갈리기 시작한다 |
| — | 2026-07-20 | `8cc3230c` | 자체 수집기 편성에 별도 차단 게이트가 추가 — 이 공급자만 발효 조건이 한 겹 더 좁아진다 |

**여기서 멈춘 것이 있다.** 분류 체계는 네 값을 함께 정의했는데 그중 응답에 실린 것은 둘뿐이었고,
위 표가 끝나는 시점까지 나머지 둘이 실린 적이 없다. 규칙 쪽은 계속 정교해졌지만 **사용자 화면의
구별 가능성은 늘지 않았다** — 폴백 순서가 두 번 바뀌고 공급자가 다섯이 되는 동안에도 화면에
도달하는 신호는 하나 그대로였다.