느린 답변을 ‘모델이 느렸다’는 추측에서 실제 구간으로 좁힌다
규정 안내 답변이 4초 뒤에 나타났다고 해 봅시다. 전체 시간만 보면 모델 호출, 문서 검색, 권한 검사, 네트워크 재시도 가운데 어느 단계가 지연됐는지 모릅니다. 실행 추적은 요청 전체를 루트 스팬으로 두고 검색과 모델 호출, 출처 검사를 자식 스팬으로 남깁니다. 시작 시각, 종료 시각, 상태, 주요 속성과 오류 사건을 함께 기록하면 지연 구간을 찾을 수 있습니다. 모든 내부 생각을 저장하는 것이 아니라 운영상 관찰 가능한 작업 경계를 기록한다는 점이 중요합니다.[1]
| 스팬 | 시작 | 종료 | 상태 |
|---|---|---|---|
| 요청 처리 | 0ms | 4,000ms | 성공 |
| 권한 확인 | 30 | 90 | 성공 |
| 문서 검색 | 100 | 2,450 | 재시도 후 성공 |
| 모델 호출 | 2,500 | 3,800 | 성공 |
트레이스·스팬·부모·자식을 구별한다
트레이스는 하나의 요청이나 작업 전체를 연결한 기록 묶음입니다. 각 스팬은 그 안의 한 작업 구간이며 이름, 시작·종료 시각, 상태와 속성을 가집니다. 자식 스팬은 자신을 시작하게 한 부모 스팬의 식별자를 가집니다. 같은 트레이스의 스팬은 공통 Trace ID를 사용하고 각각 고유한 Span ID를 가집니다. 분산 시스템에서는 HTTP 헤더의 traceparent 같은 문맥을 다음 서비스에 전달해 떨어진 기록을 같은 요청으로 묶을 수 있습니다.[2]
요청 처리 · Span A
Span B
Span C
들여쓰기와 시간축을 함께 봐야 병렬과 순서를 안다
트리의 부모-자식 관계만으로는 두 자식이 동시에 실행됐는지 차례로 실행됐는지 확정할 수 없습니다. 시작·종료 시각을 함께 봐야 합니다. 검색 스팬과 개인정보 검사가 같은 부모 아래에 있고 시간 구간이 겹치면 병렬 실행으로 볼 수 있습니다. 검색이 끝난 뒤 모델 호출이 시작되었다면 검색 결과에 의존하는 순차 관계입니다. 단순히 화면에 위에 그려졌다는 이유로 먼저 실행됐다고 판단하지 않습니다. 트리 구조는 원인 관계, 시간 막대는 실제 겹침을 보여 줍니다.
| 작업 | 부모 | 시간 막대 | 읽기 |
|---|---|---|---|
| 문서 검색 | 요청 처리 | 100–600ms | 구간이 겹쳐 병렬 |
| 개인정보 검사 | 요청 처리 | 120–300ms | |
| 모델 호출 | 요청 처리 | 620–1,300ms | 검색 뒤 시작 |
검색 증강 답변에서 검색·문맥 구성·모델 호출을 추적한다
검색 증강 답변의 루트 스팬은 사용자 요청 처리입니다. 그 아래 권한 확인과 질문 정리가 실행되고, 검색 스팬은 벡터 검색과 문서 읽기를 자식으로 가질 수 있습니다. 문맥 구성 스팬에는 사용한 문서 ID 수와 토큰 수처럼 민감하지 않은 운영 속성을 남길 수 있습니다. 모델 호출 스팬에는 모델 식별자, 입력·출력 토큰 수, 종료 상태와 지연 시간을 기록하되 질문 원문이나 문서 전체를 기본 속성에 넣지 않습니다. 출처 검증 스팬은 답변 주장과 문서 ID의 대응을 검사합니다.
벡터 검색 170 + 문서 읽기 80
실패 스팬을 지우지 말고 재시도를 형제로 남긴다
첫 모델 호출이 시간 초과되고 두 번째 호출이 성공했다면 최종 성공만 기록해서는 원인을 찾을 수 없습니다. 첫 호출 스팬은 오류 상태와 시간 초과 사건을 남기고, 재시도 스팬은 같은 부모 아래 별도 작업으로 기록합니다. 재시도 번호, 대기 시간과 사용한 대체 모델을 속성으로 남기면 비용과 지연 증가를 설명할 수 있습니다. 반면 오류 메시지에 사용자 원문이나 비밀 토큰이 포함되면 그대로 기록하지 않도록 가림 규칙이 필요합니다. 추적은 관찰성을 높이면서도 데이터 최소 수집 원칙을 지켜야 합니다.
실패 횟수와 대기 시간을 알 수 없습니다.
대기 · 200ms
호출 2 · 500ms · 성공
로그를 트리로 바꿀 때 관찰 사실과 추정을 분리한다
LLM은 스팬 표를 읽어 트리와 병목 후보를 정리하는 데 쓸 수 있습니다. 각 행에 Trace ID, Span ID, Parent Span ID, 이름, 시작·종료 시각, 상태를 제공하고 누락된 부모를 임의로 만들지 말라고 지시합니다. 시간 겹침은 계산해 병렬 후보로 표시하되 비동기 메시지의 인과 관계는 링크나 별도 증거가 없으면 추정으로 남깁니다. 기록되지 않은 모델 내부 계산과 사고 내용을 재구성하지 않도록 명시합니다. 민감한 원문은 전달 전에 제거합니다.
다음 스팬 표를 실행 추적 트리와 시간표로 정리해 주세요. 열: trace_id / span_id / parent_span_id / 작업 이름 / 시작 ms / 종료 ms / 상태 / 오류 종류. 규칙: 부모-자식 관계는 ID로만 확정한다. 시간 구간이 겹치면 ‘병렬 후보’라고 쓴다. 계산: 각 스팬 지속 시간, 전체 시간, 실패·재시도 횟수, 가장 긴 의존 경로를 구한다. 오류: 부모가 없는 스팬, 종료가 시작보다 이른 스팬, 같은 span_id를 표시한다. 보안: 사용자 원문·문서 본문·인증값은 출력하지 않는다. 금지: 기록에 없는 모델 내부 사고, 호출 원인, 성공 기준을 만들어 내지 않는다. 출력: ① 트리 ② 시간표 ③ 병목 후보 ④ 데이터 품질 문제 ⑤ 추가로 필요한 기록.
시각적 위치나 이름이 비슷하다는 이유로 부모를 만들지 않는다
잘못된 추적 트리는 시작 시간이 빠른 스팬을 모두 부모로 삼거나, 이름에 ‘검색’이 들어간 작업을 한 줄로 이어 붙입니다. 분산 시스템의 시계가 약간 어긋나거나 비동기 작업이 나중에 끝나면 이런 추정은 깨집니다. 부모 관계는 Parent Span ID 또는 명시적 링크로 정하고, 누락된 문맥은 ‘고아 스팬’으로 표시합니다. 또한 같은 Span ID가 중복되거나 종료 시각이 시작보다 이르면 그림을 그리기 전에 기록 품질 오류를 고쳐야 합니다.
비슷한 이름을 한 가지로 합침
링크가 없으면 고아 스팬 표시
중복 ID·역전 시간 먼저 검사
실행 추적은 원인 후보를 좁히지만 설명 전체를 보증하지 않는다
검색 스팬이 길었다고 해서 검색 시스템 자체가 항상 느리다고 단정할 수 없습니다. 상위 서비스의 대기, 네트워크, 샘플링과 누락된 스팬이 영향을 줄 수 있습니다. 추적은 어떤 호출이 있었고 언제 끝났는지 보여 주지만 모델이 왜 특정 문장을 선택했는지 설명하지 않습니다. 또한 모든 요청을 상세 기록하면 비용과 개인정보 위험이 커집니다. 표본 추출, 속성 최소화, 보존 기간과 접근 통제를 함께 설계하고, 지표·로그·사용자 보고와 대조해야 합니다.
| 추적으로 확인 | 추가 자료가 필요한 판단 |
|---|---|
| 호출 관계·시간·상태·재시도 | 느림의 근본 원인 |
| 도구와 모델이 반환한 오류 | 답변 내용이 틀린 이유 |
| 기록된 요청의 경로 | 모든 요청의 일반적 성능 |
| 선택된 속성과 사건 | 기록되지 않은 내부 계산 |
순차와 병렬 스팬의 임계 경로를 계산하자
교육용 실행에는 권한 확인 60ms, 검색 300ms, 개인정보 검사 140ms, 모델 호출 700ms, 출처 검사 120ms가 있습니다. 검색과 개인정보 검사를 함께 시작하고 모델이 두 결과를 모두 기다리면 전체 핵심 경로는 60 + max(300,140) + 700 + 120 = 1,180ms입니다. 모두 순차로 실행하면 1,320ms입니다. 아래에서 병렬 여부와 첫 모델 호출의 시간 초과를 바꾸어 전체 시간을 계산해 보세요.