페이지별 저장과 재개를 위해 생성 단위를 바꾼 이유

완료 시간과 강의 분량을 함께 봤다

AI Commons의 강의 스크립트 생성은 한 번의 응답을 통째로 저장하던 방식에서 페이지별 생성·저장으로 바뀌었다. 팀의 10페이지 비교에서는 전체 완료 시간이 68초에서 162초로 늘었다. 같은 10페이지 자료의 예상 강의 길이는 23분 35초에서 37분 53초로 바뀌었다. 사용자가 요청한 목표는 38분이었다. 팀의 변경 결과에는 완료 시간과 요청한 분량 사이의 절충이 드러난다.

기록의 62%와 99%는 목표 강의시간에 대한 분량 비율이다. 정확도나 만족도 점수가 아니다. 팀 비교 기록에 더해 70페이지 문맥 제한·실패 재개 검증을 연결했다. 느려진 생성 단위가 요청 분량뿐 아니라 완료 결과를 보존하는 복구 단위로도 쓰이는지를 살펴본다.

전체를 한 번에 요청하던 흐름을 페이지별로 나눴다

기존 방식은 전체 페이지의 스크립트를 한 번의 요청으로 생성했다. 많은 내용을 한 요청에 담다가 컨텍스트 한계를 넘겨 실패하는 경우가 있었고, 결과도 전체 생성이 끝난 뒤 한꺼번에 저장했다. 생성에 걸리는 시간만 보면 유리할 수 있지만, 마지막까지 기다린 후에야 성공 여부와 결과를 확인하는 구조였다.

팀의 변경 명세에서는 한 페이지를 생성하고 저장한 다음 다음 페이지를 요청하도록 했다. 초기 순차 생성은 previous_response_id로 앞선 응답과 연결해 강의의 흐름을 이어 갔다. 이 응답 연결은 당시 구현이며, 이후 문맥 크기를 제한한 경로와 구분한다. 화면에도 완료한 페이지부터 보여 주도록 했다. 실패하면 해당 페이지를 재시도하고, 재시도 한도를 넘으면 이유와 재시도 버튼을 표시하며 진행을 멈췄다.

이 선택은 요청 사이에 의존 관계를 만든다. 다음 페이지가 앞선 페이지를 기다리므로 전체 완료 시간은 길어질 수 있다. 대신 저장과 실패 처리를 페이지 단위로 다룰 수 있다. 응답을 연결하는 것만으로 입력 크기가 계속 커지는 문제까지 해결되지는 않으므로, 문맥을 유지하는 방법과 문맥의 크기를 제한하는 방법은 별도로 판단해야 한다.

팀의 10페이지 테스트 기록에서 두 시간을 비교했다

비교 자료는 자료구조의 힙을 설명하는 10페이지 슬라이드였다. 팀의 테스트에서는 목표 강의시간을 38분으로 두고, 표지와 마무리 옵션을 켠 조건에서 일괄 생성과 순차 생성 결과를 비교했다. 아래의 완료 시간에는 생성 흐름 전체에 걸린 시간이 들어 있으며, 강의 길이는 결과 스크립트의 예상 소요 시간이다.

생성 완료까지는 94초를 더 기다렸다. 그 대신 결과의 예상 분량이 목표에 가까워졌다. 전체 생성 시간이 줄었다고 설명할 수 있는 변경은 아니지만, 정해진 시간의 강의를 준비하는 작업이라면 이 차이는 방식 선택에서 고려할 근거가 된다. 강의 길이는 스크립트에서 추정한 값이다.

페이지를 나눠도 앞선 응답이 계속 쌓이면 다시 막힌다

순차 생성의 다음 문제는 문맥의 크기였다. 앞선 응답을 계속 이어 가면 강의 뒤쪽의 요청일수록 입력이 커질 수 있다. 후속 구현은 최근 N페이지의 스크립트만 참고하는 슬라이딩 윈도우를 사용했다. 필요한 문맥을 매 페이지 새로 조립하고, 오래된 페이지는 참고 범위 밖으로 내보낸다. 페이지별 저장과 문맥 제한은 서로 다른 역할이다.

70페이지 PPTX를 gpt-5.1로 생성하고 참고 윈도우 1·3·5·10을 비교했다. 네 조건 모두 70페이지를 끝까지 생성했고, 입력은 페이지 수에 비례해 계속 늘지 않았다. 다음 표는 그 기록의 요청당 입력 토큰이다.

윈도우 10의 52페이지는 42~51페이지, 70페이지는 60~69페이지를 참고했다. 이 조건에서 11페이지 이후 입력은 약 19.6k~21.8k에 머물렀다. “문맥을 이어 간다”와 “모든 이전 응답을 유지한다”를 분리한 결과다. 현재 코드의 관리형 경로도 윈도우 입력 조립을 사용하고, 이전 응답 연결은 오래된 작업의 재개 호환 경로로 남아 있다.

52페이지가 실패해도 앞의 51페이지는 다시 만들지 않았다

같은 검증에서는 52페이지 이미지 파일을 숨겨 실패를 유발했다. 재개는 52~70페이지 19장만 생성했고 약 3분 뒤 완료했다. 앞의 1~51페이지는 스크립트 내용·버전·버전 이력의 차이가 모두 0이었다. 실패를 기록하고 어디서부터 다시 만들지를 정한 덕분에 생성 완료분을 복구의 입력으로 재사용할 수 있었다.

1. 1~51페이지 저장완료 스크립트와 버전 이력이 남는다.
2. 52페이지 입력 누락이미지를 읽지 못해 생성이 실패하고 재개 위치가 기록된다.
3. 입력 복원 후 재개확정된 시간 분배를 재사용하고 52~70페이지 19장만 만든다.
4. 재개 전후 대조완료된 51페이지의 내용·버전·이력을 비교해 변경이 없음을 확인한다.

스크립트가 전부 저장된 뒤 상태 갱신만 실패한 경우에는 생성 호출을 하지 않고 상태만 갱신한 기록도 있다. 저장 실패와 생성 실패를 같은 “처음부터 다시 생성”으로 처리하면 이미 지불한 호출을 반복하게 된다. 실패 지점을 넘는 재개 위치나 목표 시간이 달라진 요청은 거부하고, 정상 재개를 방해하지 않는지도 검사했다.

실행은 검증 CLI가 워커의 서비스 메서드를 같은 인자로 직접 호출한 방식이다. 큐 워커를 띄워 프로세스를 중간에 죽인 테스트는 아니다. 실패 기록이 남지 않는 실제 워커 종료 경로는 당시 문서의 후속 과제다. 원래 장애의 66페이지 PDF도 확보하지 못해 70페이지 PPTX로 대체했다.

길어진 대기에는 진행 상황과 복구 단위가 필요했다

전체 생성이 오래 걸릴 때 화면에 로딩 표시 하나만 남겨 두면 사용자는 기다릴 이유를 판단하기 어렵다. 페이지별 저장과 순차 노출은 이미 끝난 부분과 아직 진행 중인 부분을 구분할 수 있게 한다. 실패한 페이지를 표시하는 것도 같은 이유다. 작업 전체가 멈췄다는 사실에 더해, 어디까지 완료됐는지를 알려 줘야 한다.

완료 페이지를 먼저 보여 주는 동작을 구현한 사실과 첫 결과가 얼마나 빨리 보이는지는 다른 문제다. 이 비교에는 첫 페이지 표시 시간의 전후 측정이 없다. 따라서 전체 시간이 늘어도 체감 대기가 줄었다고 단정할 수는 없다. 실제로 기다림을 줄였는지 확인하려면 전체 완료 시간과 첫 결과 표시 시간을 따로 재야 한다.

시간·문맥·복구의 검증을 품질 점수로 합치지 않는다

이 결과만으로 순차 생성이 언제나 더 좋은 방식이라고 결론내리지는 않는다. 짧고 서로 독립적인 내용이라면 앞선 응답을 기다리는 비용이 불필요할 수 있다. 긴 강의에서는 이어지는 문맥이 도움이 되더라도 누적 입력량, 실패 위치, 복구 비용까지 함께 봐야 한다. 한 번의 성공 결과에는 실행마다 생기는 편차도 드러나지 않는다.

10페이지 비교는 예상 분량과 완료 시간, 70페이지 검증은 제한한 입력 크기와 저장 결과 보존의 근거다. 순차 처리와 함께 모델·프롬프트·시간 분배도 바뀌었으므로 62%→99%를 순차 처리 하나의 효과로 확정하지 않는다. 교수자의 내용 품질 평가, 첫 결과 표시 시간, 반복 실행 편차는 별도 비교가 필요하다. 느린 단위를 선택한 이유는 목표 분량을 다루고, 실패 뒤 이미 끝난 페이지를 지키는 데 있었다.

이 생성 흐름이 들어간 제품은 AI Commons 프로젝트에서 볼 수 있다.