Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

11 KiB

Raw Blame History

title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed

title

source_type

url

archive_url

status

confidence

토스 — 결제/Gateway 모니터링과 알람 운영 (raw 인용 검증 실패)

Layer: raw/company-tech-blogs/ — 토스 SLASH 23 발표 글 발췌 시도. 2026-05-27 검증 결과: 원 raw 기록 (2026-05-22) 에 적힌 5개 한국어 인용 ("P1은 사용자가 결제를 못 하는 상황...", "에러율 1%가 critical 일 수도...", "alert 에는 항상 1차 확인할 dashboard 링크...", "metric naming 은 일관성이 핵심..." 등) 은 인용 출처로 명시된 toss.tech/article/slash23-server 페이지의 본문에서 재확인되지 않음. 실제 해당 페이지 (제목: "토스는 Gateway 이렇게 씁니다", 저자: 최준우, 2023-10-12) 는 Gateway 아키텍처 주제이며, 모니터링 섹션은 Logging (Elasticsearch) / Metrics (Prometheus + Grafana) / Tracing 의 도구 언급만 있고 severity 정의·임계값·payload 구조에 대한 인용은 없음. 따라서 본 문서는 raw 보존 + needs-confirmation 라벨로 마이그레이션하되, claim 들을 사실로 격상 금지.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-metrics-alerting-contract	P1/P2/P3 severity 정의 + alert payload 5종 필드의 외부 fintech 사례 후보 — 단 본 문서 인용 미검증, 결정의 1차 근거로 사용 금지
raw/branch-notes/feature-operational-runbook-contract	alert 와 runbook 링크 연결 정책의 외부 사례 후보 — 동일하게 인용 미검증
raw/project-notes/ca-skeleton-operational-contract	§18. Control Plane Contract (Metrics / Alerting) 의 외부 사례 — 인용 검증 후 별도 wiki 인용 가능 여부 재판단

컨텍스트 / 왜 저장했는지

원 raw 의 의도: ca-tmpl 이 결정한 "P1/P2/P3 정량 기준" 및 "alert payload 에 operation/dependency/error.code/error.category/runbook_link 필수" 의 국내 fintech 사례 근거로 보관.

검증 후 실제 상태: 인용 출처 URL 이 다른 주제 (Gateway 아키텍처) 의 글이므로, 본 자료는 ca-tmpl 결정의 근거로 사용 불가. 별도 토스/카카오페이/네이버페이의 실제 alerting 사례 글을 찾아 raw 재수집 필요.

출처 / Source

원본 URL (검증 시점에 본문 확인): https://toss.tech/article/slash23-server
실제 글 제목: "토스는 Gateway 이렇게 씁니다"
실제 저자: 최준우 (Toss Server Developer)
발행일: 2023-10-12
아카이브 URL: (미수집)
마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim)

verified (2026-05-27, 실제 글 본문에서 확인된 인용):

[§모니터링 — 로깅] "Gateway를 지나는 모든 요청, 응답의 Route id와 method, URI, 상태 코드 등을 Elasticsearch에 남기고 있습니다"

[§모니터링 — 메트릭/트레이싱 요약 (verbatim 일부만 회수, 본 fetch 한계)] 시스템·애플리케이션 메트릭은 Prometheus 수집 + Grafana 시각화 + Slack 알림. 트레이싱은 분산 트레이싱 구현 언급.

unverified (원 raw 2026-05-22 기록, 출처 URL 본문에 부재 — needs-confirmation):

[§unverified] "결제는 사용자 경험과 매출에 직결되기 때문에, 단순 error rate threshold 보다 영향 범위와 비즈니스 임팩트를 기준으로 알람을 나눕니다."

[§unverified] "P1은 사용자가 결제를 못 하는 상황, P2는 일부 가맹점·일부 카드사 영향, P3는 내부 운영 지표 이상으로 구분합니다."

[§unverified] "에러율 1%가 critical 일 수도 minor 일 수도 있어서, baseline 대비 spike (예: 평소 0.1% → 1%로 10배) 기준도 같이 봅니다."

[§unverified] "alert 에는 항상 1차 확인할 dashboard 링크, 관련 로그 query, on-call runbook 링크가 함께 들어가야 한다."

[§unverified] "metric naming 은 일관성이 핵심. 결제_성공률 같은 한글 metric 은 절대 금지하고, 영문 dot-case 로 통일했습니다."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
TOSS-ALERT-C1	토스 Gateway 는 모든 요청/응답의 Route id, method, URI, 상태 코드를 Elasticsearch 에 로깅	[§모니터링 — 로깅] "Gateway를 지나는 모든 요청, 응답의 Route id와 method, URI, 상태 코드 등을 Elasticsearch에 남기고 있습니다"	`company-case-study`	토스 Gateway 의 로깅 시스템	결제 도메인 전체의 로깅 표준이라는 뜻은 아님 — Gateway 한 영역
TOSS-ALERT-C2	토스 는 메트릭 수집에 Prometheus, 시각화에 Grafana, 알림에 Slack 을 사용 (도구 스택)	(본 fetch 본문 요약 — verbatim 일부 회수)	`company-case-study`	토스 의 모니터링 도구 선택	Slack 알림의 payload 구조 / severity 정의 / threshold 는 본 인용 범위 밖
TOSS-ALERT-C3	(unverified) P1=결제 차단, P2=일부 가맹점/카드사 영향, P3=내부 지표 이상 — 비즈니스 임팩트 기반 severity 분류	[§unverified] "P1은 사용자가 결제를 못 하는 상황, P2는 일부 가맹점·일부 카드사 영향, P3는 내부 운영 지표 이상으로 구분합니다."	`needs-confirmation`	토스 결제 도메인의 severity 정책 (재확인 필요)	본 인용은 cited URL 본문에서 확인 안 됨. 토스 의 실제 정책일 수 있으나 출처 재발굴 전까지 사실로 격상 금지
TOSS-ALERT-C4	(unverified) 에러율 절대값이 아닌 baseline 대비 spike (예: 평소 0.1% → 1% = 10배) 도 같이 기준으로 사용	[§unverified] "에러율 1%가 critical 일 수도 minor 일 수도 있어서, baseline 대비 spike ... 기준도 같이 봅니다."	`needs-confirmation`	spike-based alert 정책 (재확인 필요)	출처 검증 실패. 일반 모니터링 기법이지만 토스 의 명시적 정책이라는 증명 없음
TOSS-ALERT-C5	(unverified) alert payload 에 dashboard 링크 + 로그 query + runbook 링크 동시 포함 의무	[§unverified] "alert 에는 항상 1차 확인할 dashboard 링크, 관련 로그 query, on-call runbook 링크가 함께 들어가야 한다."	`needs-confirmation`	alert payload 표준 (재확인 필요)	출처 검증 실패. 일반적 권고이나 토스 의 명시적 contract 증거 없음
TOSS-ALERT-C6	(unverified) metric naming 은 영문 dot-case 통일, 한글 metric 금지	[§unverified] "metric naming 은 일관성이 핵심. `결제_성공률` 같은 한글 metric 은 절대 금지하고, 영문 dot-case 로 통일했습니다."	`needs-confirmation`	metric naming convention (재확인 필요)	출처 검증 실패. Micrometer dot-case 는 별도 OpenTelemetry/Prometheus 표준 — 토스 의 명시적 정책 증거 부재
TOSS-ALERT-C7	(unverified) 비즈니스 임팩트 기반 severity 분류 가 단순 error rate threshold 보다 우선	[§unverified] "결제는 사용자 경험과 매출에 직결되기 때문에, 단순 error rate threshold 보다 영향 범위와 비즈니스 임팩트를 기준으로 알람을 나눕니다."	`needs-confirmation`	결제 도메인의 alerting 철학 (재확인 필요)	출처 검증 실패

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- TOSS-ALERT-C1 ~ C2: 토스 Gateway 의 로깅 / 메트릭 도구 스택 (verified 2026-05-27, Gateway 한정)
이 자료가 증명하지 않는 것:
- TOSS-ALERT-C3 ~ C7: severity 정의, spike threshold, alert payload 구조, metric naming, 비즈니스 임팩트 기반 분류 — 모두 출처 URL 본문에서 미확인. needs-confirmation 상태로 보존
- "토스가 이러니까 한국 fintech 표준" 격상 (CLAUDE.md §5: company-tech-blog 등급은 사례/관점)
- ca-tmpl 의 P1/P2/P3 정량 threshold 의 fintech 산업 검증
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- 토스 의 실제 alerting/severity 정책이 공개된 다른 글 (예: 토스페이먼츠 기술 블로그, SLASH 컨퍼런스 다른 발표, infcon 발표) 의 raw 재수집
- 카카오페이 / 네이버페이 / KG이니시스 등 다른 한국 fintech 의 비교 가능한 공개 자료
- ca-tmpl 의 정량 threshold (>5% 5분 / >1% 10분 / >0.1% 1시간) 의 별도 근거 (SRE workbook 등)

메모 / Notes

검증되지 않은 내 해석은 wiki source-summary 단계에서만.

검증 실패의 의미: 원 raw 에 적힌 인용 5종은 의도는 합리적이나 (P1/P2/P3 비즈니스 임팩트 기반, spike threshold, payload 표준, dot-case naming) cited URL 본문에 존재하지 않음. 이는 원작성자의 해석/요약을 인용 형태로 기록했거나, 출처 URL 이 부정확할 가능성.
재발굴 후보 키워드:
- "토스 결제 알람 severity"
- "토스페이먼츠 on-call runbook"
- "SLASH 22/23/24 결제 모니터링"
- "infcon 토스 alerting"
ca-tmpl 결정과의 관계 (재검토 권고):
- 본 raw 가 cited 출처와 불일치하므로 feature-metrics-alerting-contract 의 결정 근거 표에서 본 raw 인용 제거 또는 needs-confirmation 명시 필요.
- 새 raw (토스/카카오페이 실제 alerting 글) 발굴 시까지 정책 결정은 SRE Workbook / Google SRE Book / OpenTelemetry semconv 등 official-doc 으로 보강 권고.
공정 기록: 본 migration 은 raw 정확성 회복이 목표 — fabricated quote 를 사실로 ingest 하면 wiki/concepts → wiki/blog 까지 오염되므로 단호한 라벨링 필요 (CLAUDE.md §11 "출처 없는 단정적 진술" 금지 조항).

같은 주제 다른 raw:
- (재발굴 필요 — 토스 실제 alerting 글, 카카오페이 / 네이버페이 비교 자료)
인용하는 branch:
- raw/branch-notes/feature-metrics-alerting-contract (근거 표에서 needs-confirmation 명시 권고)
- raw/branch-notes/feature-operational-runbook-contract
인용하는 project:
- raw/project-notes/ca-skeleton-operational-contract (§18. Control Plane Contract)
인용한 wiki 요약: (미작성 — 검증 실패 상태에서는 wiki 인용 금지)

11 KiB Raw Blame History