느린 단계는 어디에서
생길까?

전체 응답 시간 하나를 작업과 대기로 풀어낸다

교내 규정 안내 서비스가 평소 1.4초 안에 답하다가 어느 날 3.1초가 걸렸다고 합시다. 모델 호출만 의심하면 검색 큐에서 900ms를 기다린 사실이나 출처 검사가 끝나기를 기다린 400ms를 놓칠 수 있습니다. 워터폴의 가로축은 공통 시간, 각 행은 작업 하나입니다. 막대의 왼쪽 끝은 시작, 오른쪽 끝은 종료, 길이는 지속 시간입니다. 행 사이의 겹침은 동시 실행을 뜻하고, 다음 막대 전의 빈칸은 대기나 기록 누락 후보가 됩니다.[1]

먼저 기준 시각을 하나 정합니다. 사용자가 전송 버튼을 누른 시각, 서버가 요청을 받은 시각, 내부 작업이 시작된 시각은 서로 다를 수 있습니다. 어느 시각을 0으로 삼았는지 기록해야 서로 다른 실행을 비교할 수 있습니다. 또한 평균만 보면 드문 긴 지연이 가려지므로 중앙값과 상위 백분위 시간도 함께 봅니다.

막대의 위치는 시작 시각, 길이는 지속 시간이다

워터폴에서 길이가 같은 막대라도 놓인 위치가 다르면 의미가 다릅니다. 검색이 200ms에 시작해 700ms에 끝났다면 지속 시간은 500ms입니다. 모델 호출이 720ms에 시작했다면 두 작업 사이에 20ms 간격이 있습니다. 이 간격은 결과 직렬화, 스케줄러 대기, 네트워크 전송처럼 따로 기록되지 않은 작업일 수 있습니다. 시작 시각과 지속 시간을 섞지 않고, 공통 기준점에서 잰 상대 시간인지 실제 시각인지도 제목에 밝혀야 합니다.

종료 시각에서 시작 시각을 뺀 값은 경과 시간입니다. CPU가 실제로 계산한 시간과는 다를 수 있습니다. 경과 시간 안에는 네트워크 응답과 다른 작업을 기다린 시간이 들어갑니다. 따라서 워터폴 막대 하나를 곧바로 계산 비용이라고 부르지 않고, 더 세밀한 측정 자료가 있을 때 처리와 대기를 나눕니다.

큐 대기와 실제 처리를 서로 다른 모양으로 표시한다

작업이 오래 걸렸다는 말에는 두 경우가 있습니다. 실행 자원을 얻지 못해 기다린 경우와 실행을 시작한 뒤 계산이 길어진 경우입니다. 큐에 들어간 시각, 실행 시작, 종료를 모두 알면 대기 시간과 처리 시간을 나눌 수 있습니다. 대기는 빗금 막대, 처리는 단색 막대로 표현하고 범례를 붙입니다. 큐 대기가 길면 동시 처리량과 우선순위를 살피고, 처리 막대가 길면 입력 크기·검색 범위·모델 설정을 살핍니다.

큐 대기는 요청량이 늘 때 갑자기 길어질 수 있습니다. 처리 시간은 거의 그대로인데 전체 응답만 늘어난다면 자원 수, 동시 실행 한도, 우선순위 정책을 확인합니다. 반대로 한 요청의 처리 막대가 입력 길이에 따라 늘어난다면 문서 수와 토큰 수를 같이 기록해 관계를 살핍니다. 같은 긴 막대라도 조치가 달라지는 까닭입니다.

검색·도구·사람 승인에서 시간의 성격이 달라진다

검색 증강 답변은 검색과 모델 호출 사이의 빈칸에서 문맥 조립 비용이 생길 수 있습니다. 계산 도구를 쓰는 답변은 모델이 도구 요청을 만든 뒤 외부 계산 결과를 기다리는 구간이 나타납니다. 사람 승인을 포함한 게시 흐름은 승인 대기가 몇 분이나 며칠로 길어질 수 있어 컴퓨터 처리 시간과 같은 축에 놓으면 짧은 작업이 사라집니다. 이때는 초 단위 운영 워터폴과 일 단위 진행 시간표를 분리합니다. 한 도표에는 비교 가능한 시간 규모만 담는 편이 읽기 좋습니다.

사람 승인처럼 단위가 큰 작업은 접수, 검토 시작, 보완 요청, 승인 완료의 네 시점을 나누어 기록할 수 있습니다. 그러면 담당자가 실제 검토한 시간과 요청자가 답을 기다린 시간을 구분할 수 있습니다. 자동 처리와 사람 판단을 한 숫자로 합치기보다 서로 다른 시간표로 보여 주고, 상위 진행표에서 두 결과를 이어 주는 편이 정확합니다.

겹친 막대는 모두 더하지 않고 기다림을 만든 구간을 찾는다

문서 검색 500ms와 개인정보 검사 300ms가 동시에 시작해 모델이 두 결과를 모두 기다린다면 합류까지의 경과 시간은 500ms입니다. 두 작업 시간을 더한 800ms는 순차 실행일 때의 값입니다. 반면 검색이 끝난 뒤 검사가 시작되면 800ms가 됩니다. 전체 완료 시점을 늦추는 연속 구간을 임계 경로라고 부릅니다. 워터폴은 실제 겹침을 보여 주고, 다음 회의 의존 그래프는 어떤 작업이 무엇을 기다리는지 설명합니다. 두 그림을 함께 사용하면 느린 막대와 전체 지연을 만든 막대를 구분할 수 있습니다.

임계 구간은 가장 긴 개별 막대와 항상 같지 않습니다. 오래 걸린 작업이 다른 필수 작업과 완전히 겹치면 전체 종료 시점을 추가로 늦추지 않을 수 있습니다. 반대로 짧은 작업 여러 개가 차례로 이어지면 긴 경로를 만듭니다. 그래서 막대 길이를 정렬하는 표와 의존 관계를 따라간 경로 계산을 함께 제시합니다.

겹치는 구간을 계산할 때는 각 작업의 시간을 모두 더하기보다 다음 단계가 실제로 시작할 수 있는 시각을 찾습니다. 이 원칙을 적용하면 병렬 처리의 효과와 아직 줄여야 할 대기를 같은 축에서 구별할 수 있습니다.

시작·종료 자료와 관찰 범위를 요청문에 고정한다

LLM에 작업 이름과 소요 시간만 주면 임의의 실행 순서를 만들기 쉽습니다. 요청 ID, 작업 ID, 부모 작업, 큐 진입·실행 시작·종료 시각, 상태를 표로 제공해야 합니다. 겹친 막대는 병렬 실행 후보로 표시하고, 의존 관계는 부모 ID나 별도 규칙으로만 확정하도록 지시합니다. 누락된 구간은 추정값으로 채우지 않고 ‘기록 없음’으로 남기게 합니다. 사용자 원문과 문서 본문은 제거하고 운영에 필요한 식별자와 시간만 전달합니다.

요청문에 시간 단위를 통일하라는 조건도 넣습니다. 초와 밀리초가 섞인 표는 막대 길이를 크게 틀리게 만들 수 있습니다. 표의 행 수, 가장 이른 시작, 가장 늦은 종료, 원자료로 다시 계산한 전체 시간을 결과와 대조합니다. LLM이 만든 그림은 계산 결과를 설명하는 초안이며 원자료 검사가 최종 판정을 맡습니다.

다음 작업 표를 공통 시작 시각 0ms의 실행 워터폴로 정리해 주세요.\n열: 작업 ID / 부모 ID / 큐 진입 / 실행 시작 / 종료 / 상태.\n계산: 각 작업의 큐 대기, 처리 시간, 작업 사이 빈 구간, 전체 경과 시간을 구한다.\n표현: 대기는 빗금, 처리는 단색으로 구분하고 시간 눈금을 표시한다.\n검토: 종료가 시작보다 빠른 행, 부모보다 먼저 시작한 자식, 중복 ID를 표시한다.\n판단: 가장 긴 막대와 전체 완료를 실제로 늦춘 구간을 따로 쓴다.\n금지: 기록에 없는 작업·원인·의존 관계를 만들어 넣지 않는다.\n출력: ①시간표 ②워터폴 ③지연 후보 ④추가로 필요한 기록.

막대를 왼쪽부터 붙이는 그림은 실제 대기를 지운다

자주 생기는 오류는 모든 막대를 앞 작업 뒤에 붙여 그리는 것입니다. 보기에는 정돈되지만 실제 시작 시각과 병렬 실행이 사라집니다. 또 막대 길이를 처리량이나 비용으로 오해하게 만드는 범례 없는 도표도 위험합니다. 수정할 때는 공통 시간축을 먼저 만들고 원자료의 시작·종료 좌표를 그대로 옮깁니다. 대기와 처리의 색·무늬를 구분하고, 확대가 필요한 짧은 구간은 별도 부분 그림으로 뺍니다.

또 하나의 오류는 시간축을 중간에서 잘라 작은 차이를 크게 보이게 하거나, 요청마다 다른 축 너비를 쓰면서 이를 표시하지 않는 것입니다. 비교 그림은 같은 단위와 범위를 사용합니다. 아주 짧은 작업을 보여 줄 때는 전체 그림의 위치를 남겨 둔 채 확대 상자를 붙입니다. 확대 전후의 연결 위치가 보여야 독자가 비율을 오해하지 않습니다.

긴 막대, 늦은 시작, 반복되는 빈칸을 따로 묻는다

검토자는 세 질문을 순서대로 봅니다. 첫째, 어느 작업의 처리 막대가 긴가. 둘째, 짧은 작업이 왜 늦게 시작했는가. 셋째, 여러 요청에서 같은 위치의 빈칸이 반복되는가. 한 번의 워터폴은 개별 사례를 보여 주므로 여러 요청의 분포와 함께 봐야 일반적인 병목을 말할 수 있습니다. 샘플링에서 빠진 요청, 기기·지역·입력 길이 차이도 함께 기록합니다. 워터폴은 원인 후보를 좁히고, 프로파일·로그·지표가 원인을 더 확인합니다.[2]

개선 전후를 비교할 때는 같은 입력 유형, 같은 지역, 비슷한 요청량을 맞춥니다. 전체 시간 감소가 캐시 적중이나 입력 길이 차이에서 생겼을 수 있기 때문입니다. 변경 전·후 표본 수와 측정 기간을 기록하고, 중앙값뿐 아니라 느린 요청 구간도 함께 봅니다. 이렇게 해야 워터폴의 변화가 실제 수정 효과인지 판단할 수 있습니다.

큐 대기와 병렬 검사를 바꾸어 전체 시간을 계산하자

교육용 흐름은 큐 대기, 질문 정리 80ms, 검색 420ms, 안전 검사 260ms, 모델 호출 760ms, 출처 검사 140ms로 이루어집니다. 검색과 안전 검사를 동시에 하면 둘 중 긴 420ms가 반영되고, 차례로 하면 680ms가 반영됩니다. 아래에서 큐 대기와 실행 방식을 바꾸어 가장 긴 구간과 전체 경과 시간을 확인해 보세요.

실습 결과를 읽을 때는 가장 긴 구간의 이름과 전체 시간에 실제로 들어간 값을 구별합니다. 큐 대기가 1,200ms이면 가장 긴 단일 구간이 되며, 병렬 검사를 순차로 바꾸면 전체에 260ms가 더해집니다. 두 설정을 한 번에 바꾸지 않고 하나씩 바꾸어야 어느 조건이 결과를 얼마나 움직였는지 설명할 수 있습니다.