# 느린 요청을 세 레이어로 추적하기

> App·Prisma·DB 관측, trace 연결, error budget과 policy

- Canonical: https://learning.reopt.ai/courses/prisma-production/lessons/pp-m4-concept
- Language: ko-KR
- HTML: https://learning.reopt.ai/courses/prisma-production/lessons/pp-m4-concept

---

[Prisma 프로덕션 가드레일](/courses/prisma-production) 4. 관측·SLO·변경 거버넌스 7 / 9

# 느린 요청을 세 레이어로 추적하기

App·Prisma·DB 관측, trace 연결, error budget과 policy
개념 학습 45 XP 9분

장애 원인은 application request, Prisma query, DB connection·lock·replica 중 어디에든 있습니다. HTTP→service→DB span을 같은 trace로 묶고 SQL·parameter를 마스킹합니다. 배포 뒤 30~60분은 임계값을 낮추고 error budget 소진 시 schema 변경을 동결합니다.
변경 권한은 위험에 비례 schema owner·DBA·service owner·release manager 책임을 분리하고 destructive change·대규모 backfill·PITR에는 추가 승인을 둡니다.

| 레이어 | 필수 신호 | 대표 경보 |
| Application | error rate·p95·timeout | 사용자 영향·rollback |
| Prisma | query latency·error code·pool | slow query·connection pressure |
| Database | lock·connection·replica lag | blocking·capacity·failover |
| Governance | change·approval·exception | 무승인 DDL·freeze 위반 |

- 1 Trace 연결 request와 query·DB span을 correlation합니다.

- 2 민감정보 보호 SQL parameter·PII 마스킹과 retention을 둡니다.

- 3 배포 관찰 임계값을 낮추고 30~60분 집중 관찰합니다.

- 4 Budget action error budget 25% 초과 등 freeze 조건을 정합니다.

실무에 남길 기준

- Query Insights·OTel·DB 지표는 같은 incident 맥락으로 연결되어야 한다
- 배포 직후 임계값과 owner를 평시와 다르게 운영한다
- 관측과 승인 없는 자동 migration은 속도가 아니라 위험의 자동화다

[이전](/courses/prisma-production/lessons/pp-m3-checklist) 이해했어요 · 계속

---

에이전트용 사이트 안내: https://learning.reopt.ai/llms.txt · 사이트맵: https://learning.reopt.ai/sitemap.xml · 문의: https://learning.reopt.ai/contact