생키 다이어그램은 입력이 어디로 얼마나 흘렀는지 어떻게 보여 줄까?

1,000건의 요청이 여러 처리 경로로 갈라진다

하루 동안 LLM 서비스에 요청 1,000건이 들어왔다. 560건은 검색을 거쳐 답을 만들고, 300건은 캐시된 답을 재사용하며, 140건은 민감한 내용이라 사람 검토로 보냈다. 최종적으로 760건은 완료되고 240건은 보류됐다. 이때 “단계가 무엇인가”보다 “각 단계로 얼마나 갔는가”를 알고 싶다면 생키 다이어그램이 알맞다.

생키 다이어그램은 노드를 처리 지점으로, 굵기가 있는 띠를 노드 사이의 양으로 쓴다. 왼쪽에서 오른쪽으로 읽는 방향을 정하고 모든 띠에 같은 단위인 ‘요청 건’을 적용한다. 아래 수치는 작동 원리를 보여 주기 위해 준비한 교육 자료이며 실제 LTCT나 특정 모델의 측정값이 아니다.

노드와 띠, 방향과 너비를 따로 읽는다

세로 막대인 노드는 입력·처리·출력 지점을 뜻한다. 노드 사이의 띠는 실제 이동량이며, 띠의 시작과 끝은 출발 노드와 도착 노드를 가리킨다. D3의 생키 구현에서는 링크의 value가 양이고 계산된 link.width가 화면 너비가 된다. 노드 높이는 연결된 양을 담을 수 있도록 정해진다.

색은 경로나 상태를 구분하는 보조 수단이다. 초록색이라고 반드시 성공이라는 뜻은 없으므로 범례를 쓴다. 띠 중심선만 보고 경로를 따라가되 너비 비교는 같은 그림과 같은 단위 안에서 한다. 560건과 300건 띠의 굵기가 거의 같다면 눈금 변환이나 최소 굵기 설정을 확인한다.

들어온 양과 나간 양의 수지를 맞춘다

처리 노드에서는 들어온 양과 나간 양이 원칙적으로 맞아야 한다. 검색 노드에 560건이 들어왔는데 완료 430건과 보류 80건만 나가면 50건이 사라졌다. 실패·중단·시간 초과처럼 실제 손실이라면 ‘중단 50’ 노드를 추가한다. 기록 누락이라면 원자료를 고친다. 차이를 조용히 띠 너비에 흡수하면 안 된다.

노드의 값은 구현에 따라 들어오는 합이나 나가는 합의 큰 쪽으로 배치될 수 있으므로 화면 높이만 보고 보존을 단정하지 않는다. 원본 source–target–value 표에서 유입합과 유출합을 직접 계산한다. 시작과 끝 노드는 한쪽 합만 있으며, 단위가 바뀌는 변환 노드는 전환율과 새 단위를 표시한다.

비용·에너지·사람 시간을 섞지 않는다

한 그림에서 첫 단계는 요청 건, 다음 단계는 토큰, 마지막 단계는 원화로 그리면 띠 너비의 의미가 중간마다 달라진다. 독자는 넓어진 띠를 요청 증가로 오해할 수 있다. 요청 흐름, 토큰 흐름, 비용 흐름은 별도 패널로 나누고 공통 ID나 단계 이름으로 연결한다.

같은 요청이라도 입력 토큰과 출력 토큰은 양이 보존되지 않는다. 모델이 새 토큰을 생성하기 때문이다. 이때 “생성”을 공급원 노드로 두거나 입력·출력 토큰 도표를 분리한다. 사람 검토 시간도 건수와 같지 않다. 10건이 각각 1분인지 30분인지 알려면 시간 단위의 두 번째 도표가 필요하다.

시간 비교는 두 그림의 순서와 척도를 고정한다

개선 전후를 비교하려면 노드 순서, 값 척도, 색, 기간 길이를 고정한다. 월요일 24시간과 주말 12시간을 그대로 나란히 놓으면 총량 차이와 비율 차이가 섞인다. 총 요청량을 보고하려면 같은 기간을 쓰고, 구성비가 목적이면 100% 정규화 패널을 별도로 둔다.

노드 자동 정렬은 띠 교차를 줄이지만 두 시점의 위치를 바꿔 비교를 어렵게 만들 수 있다. 경로 ID를 고정하고 사라진 경로는 0 또는 ‘해당 없음’으로 남긴다. 두 도표의 1픽셀이 같은 건수를 뜻하는지 캡션에 쓰며, 비율 그림이라면 총량 숫자를 제목 옆에 보완한다.

흐름도·올루비얼·네트워크와 질문이 다르다

흐름도는 조건과 작업 순서를 묻고 화살표 굵기에 양을 싣지 않는 경우가 많다. 생키는 양의 분배와 합류가 중심이다. 올루비얼 도표는 시점이나 범주 사이에서 집단 구성이 어떻게 바뀌는지를 자주 보여 주며, 생키와 모양은 비슷해도 질문과 데이터 준비가 다르다. 네트워크 그래프는 누가 누구와 연결됐는지에 더 적합하다.

순환 관계는 생키의 한 방향 층 배치와 맞지 않을 수 있다. 재시도가 앞 단계로 돌아가는 과정은 재시도 횟수를 별도 노드로 펴거나 순환 흐름도와 함께 본다. 경로 양이 없이 상태 전환 조건만 있다면 상태차트가 낫다. 먼저 질문을 한 문장으로 쓰고 양·순서·집단 이동·연결 중 무엇을 읽을지 고른다.

LLM에는 source–target–value 표부터 요구한다

LLM에 “생키를 예쁘게 그려 줘”라고만 하면 원자료에 없는 중간 노드를 만들거나 합계를 맞추기 위해 값을 임의로 조정할 수 있다. 먼저 출발ID, 도착ID, 값, 단위, 기간, 근거 행을 표로 만들게 한다. 그다음 노드별 유입·유출 합과 차이를 계산하고 차이가 0이 아닌 행은 그리기 전에 보류한다.

노드 순서와 색 범례, 손실 노드 표기, 0값 처리도 요청문에 쓴다. 결과는 렌더링 코드와 함께 접근 가능한 표·텍스트 요약을 요구한다. 모델이 제안한 경로는 실제 로그의 이벤트 ID와 대조한다. 검색 도구를 썼다는 이유만으로 검색 경로를 추가하지 않고, 측정 로그에 있는 이동만 그린다.

잘못된 그림은 누락과 과장을 숨긴다

수정 전 그림은 성공 띠만 굵게 그리고 실패 90건을 삭제했다. 검색 노드의 유입은 560인데 유출은 510이었고, 비용 원화를 요청 건수와 같은 띠로 붙였다. 가장 작은 경로도 최소 8픽셀로 그려 실제 비율보다 커 보였으며 노드 순서를 바꿔 같은 경로를 따라가기 어려웠다.

수정 후 중단·시간 초과 노드를 추가하고 모든 링크에 건수와 단위를 표시했다. 비용은 별도 도표로 나누고 최소 너비를 썼다면 실제 값 라벨과 기준을 밝혔다. 노드 수지표를 공개하고 전후 도표의 순서를 고정했다. 작은 경로는 확대 패널을 제공하되 전체에서의 비율을 함께 남겼다.

직접 실습 전에 네 숫자를 손으로 검산한다

교육 자료의 검색 560, 캐시 300, 사람 검토 140을 더하면 입력 1,000과 같다. 결과의 완료 760과 보류 240도 1,000이다. 실습에서는 검색 경로의 완료 수를 바꾸어 전체 수지가 어떻게 달라지는지 확인한다. 차이가 생기면 임의로 다른 띠를 줄이지 말고 누락 사유를 먼저 적는다.

실제 자료로 옮길 때는 표본 기간, 중복 제거 규칙, 재시도 건수, 한 요청의 여러 도구 호출을 어떻게 셌는지 기록한다. 요청 건과 호출 건은 다르다. 경로별 합계가 맞아도 같은 이벤트를 두 번 센다면 도표는 틀린다. 고유 ID 수준에서 중복을 검사한 뒤 집계한다.

복사해서 쓸 수 있는 LLM 요청문

아래 요청문은 교육용 예시다. 원문을 함께 제공하고, 모델이 빈칸을 추측하지 않도록 금지 조건을 넣었다. 결과를 받으면 원문 문장과 노드·선의 대응을 사람이 다시 확인한다.

다음 LLM 서비스 이벤트 표를 생키 다이어그램용 자료로 정리해 줘.
1. 출발ID, 도착ID, 값, 단위, 기간, 근거 행을 표로 만든다.
2. 제공하지 않은 중간 경로나 값을 추정하지 않는다.
3. 노드별 유입합·유출합·차이를 계산한다.
4. 차이가 있으면 실패·중단·누락 여부를 확인 대기로 둔다.
5. 요청 건, 토큰, 비용, 시간은 같은 띠에 섞지 않는다.
6. 노드 순서와 색 범례를 명시하고 작은 값에도 실제 수치를 붙인다.
7. 생키와 같은 내용을 담은 접근 가능한 표와 문장 요약을 함께 준다.
8. 실제 로그가 없으면 교육용 숫자를 만들지 않는다.

[이벤트 표] …

직접 실습하고 결과를 읽기

이 실습은 브라우저 안에 준비한 교육용 자료만 사용한다. 외부 LLM을 호출하거나 실제 기관 자료를 조회하지 않는다. 입력을 바꾸어 결과가 어떻게 달라지는지 보고, 설명과 맞지 않는 결과가 나오면 어떤 정보가 빠졌는지 적어 본다.

자료와 출처

아래 자료는 이번 글의 정의와 표기법을 확인하는 데 사용했다. 생각그림과 사례 문장은 원자료를 복제하지 않고 이 글의 교육 목적에 맞게 새로 구성했다.

• d3-sankey API documentation, Observable
• Sankey diagram component, Observable