AI Commons

1. 외부 서비스 (Canva, Plus AI, SlideSpeak 등)

각각을 검토했지만, 서비스에 필요한 수준의 커스터마이징이 불가능하거나 비용 구조가 맞지 않았다.

2. LaTeX 기반 생성

분명한 장점이 있었다. AI를 활용하면 안정적이고 예측 가능한 포맷으로 슬라이드가 나오고, 학계에서 익숙한 형식이기도 했다. 다만 디자인 자유도가 제한적이고, 교수들이 기대하는 현대적인 시각 품질을 달성하기 어려웠다.

3. HTML 템플릿 고도화

기존 방식의 연장선이라 레이아웃 다양성과 템플릿 유지 비용 문제가 남는다.

4. AI 이미지 생성 (Gemini NanoBanana)

그 무렵 Gemini의 새로운 이미지 생성 모델이 공개되었다. LLM으로 슬라이드 이미지를 직접 생성한다는 것이 당시에는 생소한 접근이었고, 실제로 초기 버전에는 미세한 글자 깨짐이나 이미지 수정 시 원하는 대로 반영되지 않는 문제가 있었다.

결정

당시에는 LaTeX이 출력 안정성에서 유리했지만, 데모 일정 안에서 시각 품질을 높이고 템플릿 유지 비용을 줄이는 목표를 함께 만족하기 어려웠다. 그래서 출력 편차를 감수하고 Gemini 이미지 생성 방식을 선택했으며, 공통 디자인 지침과 페이지별 지침으로 편차를 줄이는 데 집중했다.

일관성 확보

결과 일관성은 3단계 프롬프트 체인(덱 공통 디자인 지침 → 페이지별 지침 → Gemini 이미지 합성)으로 보완했다. 후속 모델에서 글자 깨짐과 수정 정밀도가 개선되면서 현재 제품 요구에는 이 방식이 더 잘 맞았다.

4단계 호출 레이어

Worker
  │  로컬 병렬 제어 (동시 이미지 생성 수 제한)
  ▼
Distributed Rate Limiter
  │  Redis 기반 전역 permit + 429 적응 제어
  ▼
Circuit Breaker
  │  5xx/네트워크 장애 감지 → 서비스 차단
  ▼
API Client → Vertex AI (retry 비활성화, 직접 제어)

분산 Rate Limiting (AIMD)

TCP 혼잡 제어의 AIMD(Additive Increase/Multiplicative Decrease) 알고리즘을 차용한 4-State FSM을 설계했다.

NORMAL (permit 40) → 429 발생 → COOLDOWN (5s→10s→20s→30s)
COOLDOWN → 타이머 만료 → PROBE (permit 1개로 테스트)
PROBE → 3회 연속 성공 → DEGRADED (1→2→4→8→16→32→40)
DEGRADED → baseLimit 도달 → NORMAL

Redis Lua 원자적 연산

permit 획득·반환·429 보고를 3개의 Lua script로 구현했습니다. Redis의 single-thread 실행으로 여러 서버에서도 race condition이 발생하지 않게 했습니다. 같은 burst에서 발생한 여러 429가 limit을 과도하게 줄이지 않도록 wave ID 기반 중복 제거도 구현했습니다.

Circuit Breaker

외부 API 호출에 Circuit Breaker(CLOSED→OPEN→HALF_OPEN)를 적용했습니다. 429는 서비스 장애가 아니므로 Circuit Breaker 대상에서 제외하고, distributed rate limiter가 별도로 처리하도록 분리했습니다.

Redis 장애 대비

Redis 자체가 장애가 나는 경우를 대비하여 로컬 동시성 제어로 자동 폴백. 10초 복구 윈도우 후 Redis 재시도.

1. ffmpeg CPU 핀닝으로 자원 격리

ffmpeg이 모든 CPU를 점유하는 것이 블로커 이슈였다. Linux의 taskset을 사용하여 ffmpeg 프로세스를 특정 CPU 코어에 고정(pinning)하여, 나머지 코어는 API 서버와 다른 워커가 사용할 수 있도록 격리했다.

taskset -c 0-1 ffmpeg -y -loop 1 -i slide.webp -i audio.mp3 ...

환경변수로 사용할 CPU 수를 설정 가능하게 하여, 서버 사양에 따라 유연하게 조정.

2. TTS/세그먼트 병렬 처리

영상 생성 과정에서 TTS 음성 생성과 세그먼트 인코딩을 순차적으로 처리하고 있었다. async.mapLimit으로 병렬 처리를 도입하되, 각 단계의 특성에 맞게 동시성을 다르게 설정했다.

TTS 생성:     mapLimit(pages, ttsConcurrency=10)      // I/O 바운드 (API 호출)
세그먼트 생성: mapLimit(pages, segmentConcurrency=2)   // CPU 바운드 (ffmpeg)
비디오 큐:     concurrency: 2~4                        // 전체 영상 작업 동시 수

TTS는 외부 API 호출이라 I/O 바운드이므로 10개까지 병렬, 세그먼트 인코딩은 CPU 바운드이므로 2개로 제한.

3. 오디오/비디오 싱크 드리프트 수정

슬라이드가 많아질수록 오디오와 비디오의 싱크가 서서히 어긋나는 현상이 있었다. 원인은 ffmpeg 인코딩 시 비디오 스트림(5fps, 200ms 프레임 간격)과 오디오 스트림의 길이가 미세하게 달라서, concat 시 오차가 누적되는 것이었다.

ffprobe로 실제 재생 시간을 측정하고, -itsoffset과 오디오 패딩으로 밀리초 단위 정렬을 적용했다. 50장 이상으로 구성한 테스트 영상에서는 눈에 띄는 싱크 드리프트가 관찰되지 않았다.

4. 슬라이드 간 음성 여백

슬라이드 전환 시 오디오에 포즈가 없이 다음 슬라이드 첫 문장이 바로 이어져서 부자연스러웠다. ffmpeg의 anullsrc 필터로 무음 오디오를 생성하고, 동일한 포맷/길이의 무음은 캐시하여 반복 생성을 최소화하면서 자연스러운 전환을 확보.

출발점: 검색과 설계를 한 호출에서 분리할 수 있는가

기존 구조는 검색한 원문을 곧바로 강의 설계에 사용한다. 대안은 업로드 단계에서 교육 가능한 개념과 관계를 먼저 추출하고, 설계 단계에는 이 구조를 우선 제공하는 방식이다. 원문은 세부 내용을 채울 때 다시 참조한다.

검증할 가정

• 강의의 순서와 학습 목표를 잡는 단계에서는 원문 전체보다 개념과 선후관계가 더 유용한가.
• 문서별 중요도와 출처를 함께 보존하면 검색 청크만 사용할 때보다 누락을 줄일 수 있는가.
• 읽기, 설계, 세부 내용 생성을 나누는 비용이 품질 향상으로 상쇄되는가.

목표 표현

입력 문서에서 개념, 출처, 선후관계, 난이도와 교육 단위를 구조화하고, 강의의 학습 목표와 순서를 설계할 때 이 표현을 사용한다.

제안: Knowledge Structure First

기존: 문서 → (검색) → LLM → 강의. LLM이 읽기와 사고를 동시에 수행.

제안: 문서 → 지식 구조 → LLM → 강의. 읽기와 사고를 분리.

• Phase 1 (읽기): 업로드 시점에 각 문서의 지식 구조를 비동기로 추출 — 개념, 개념 간 선후관계, 난이도, 교육 가능 단위(teachable units)
• Phase 2 (설계): 지식 구조(JSON)를 중심으로 강의를 설계하고, 필요한 경우 출처를 다시 조회
• Phase 3 (채우기): 특정 레슨의 세부 콘텐츠 생성 시에만 source_ref로 해당 문서의 해당 부분을 가져와서 원본 기반으로 생성

다음 검증

아직 구현 전 설계 가설이다. 문서 규모별 개념 수와 누락률, 출처 정확도, 토큰 사용량, 강의 구성 품질을 기존 File Search 방식과 같은 평가셋에서 비교해야 한다.

1차 대응: 배치 사이즈 축소 + 병렬 처리

전체 페이지를 한 번에 보내던 것을 20페이지씩 나누어 병렬로 요청. 각 배치에 전체 맥락(시스템 프롬프트)을 첨부하고, 유저 프롬프트에서 현재 생성할 페이지 인덱스를 지정. 타임아웃은 줄었지만, 배치 간 컨텍스트가 공유되지 않아 스크립트의 일관성이 떨어지는 문제가 남았다.

재설계: 순차 생성 + Responses API

발상을 전환했다. "한 번에 많이" 대신 "한 페이지씩 순차적으로" 생성하되, OpenAI Responses API의 previous_response_id를 활용하여 이전 페이지의 컨텍스트를 자동으로 유지하는 방식이다.

트레이드오프 분석

배치 방식 대비 순차 방식은 전체 완료 시간이 길어진다는 단점이 있었다. 하지만 다른 측면에서의 이점이 그 단점을 충분히 상쇄했다:

• 안정성: 한 번에 처리하는 컨텍스트를 줄여 초과 위험을 낮춤. 오류가 난 페이지만 최대 2회 재시도하고, 이후에는 명시적 오류 상태를 표시하고 중단
• 품질: previous_response_id로 컨텍스트가 연속 유지되므로, 앞 페이지의 내용을 참고한 일관성 있는 스크립트 생성. 배치 방식에서는 불가능했던 부분
• 사용성: 완료되는 스크립트를 순서대로 즉시 표시. 사용자는 전체 완료를 기다릴 필요 없이 첫 페이지부터 확인하고 검토 가능

1. 비활성 탭의 불필요한 폴링

작업 상태를 확인하기 위한 폴링이 React Query 외부에서 setInterval로 구현되어 있어서, 탭이 비활성 상태여도 5초마다 서버에 요청을 계속 보내고 있었다. 탭을 여러 개 열면 이 요청이 누적되어 DB 커넥션 풀이 포화되는 핵심 원인이었다.

해결: React Query의 refetchInterval로 전환하여, AI 작업이 실제로 진행 중일 때만 폴링이 동작하고 비활성 탭에서는 자동으로 멈추도록 변경했다.

2. 캐스케이드 캐시 무효화

React Query의 mutation 성공 콜백에서 관련 데이터의 캐시를 무효화할 때, 무효화 대상이 특정되지 않으면 슬라이드, 영상, 과목 등 모든 도메인의 캐시를 한꺼번에 날리고 있었다. React Query의 partial key matching 특성상 실제 refetch 수는 그보다 훨씬 많았고, 이 burst가 불필요한 API 재호출과 컴포넌트 리렌더링을 유발했다.

해결: 무효화 대상을 해당 리소스 도메인으로 명확히 한정하고, 공통 훅에서 무효화 로직을 직접 정의하지 않고 사용처에서 필요한 만큼만 옵션으로 추가하도록 구조를 개선했다.

3. 슬라이드 에디터 리렌더링

대량의 슬라이드를 편집할 때 불필요한 컴포넌트 리렌더링이 발생했다. 이벤트 핸들러나 배열 참조가 매 렌더마다 새로 생성되면서 하위 컴포넌트가 전부 다시 그려지고 있었다.

해결: React.memo와 커스텀 비교함수를 적용하고, 불안정한 참조들을 안정화하여 실제로 변경된 컴포넌트만 리렌더링되도록 개선했다.

4. 서버 순차 조회 → 병렬화

작업 상태를 조회하는 API에서 여러 종류의 Job 테이블을 순차적으로 조회하고 있었다. 최대 5번의 DB 왕복이 필요했고, 응답이 길어지면 커넥션 점유 시간이 늘어나 풀 포화를 악화시켰다.

해결: Promise.all로 최대 5개의 순차 조회를 하나의 병렬 구간으로 묶었다.

5. SSE와 폴링 로직 통일

작업 상태를 받는 경로가 SSE(Server-Sent Events)와 API 폴링으로 이원화되어 있어서, 같은 데이터를 두 경로로 중복 요청하는 경우가 있었다.

해결: 두 경로를 하나로 통일하여 중복 요청을 제거했다.

검증 결과

Chrome DevTools (CPU 4× throttling + Slow 4G)에서 슬라이드 에디터 6개 탭과 전체 이미지 생성을 동시에 실행하며 10분간 측정했습니다.

단일 통제 실행에서 얻은 결과다. CPU 4배 감속과 느린 네트워크를 가정했으며, 실제 기기 전반이나 반복 실행의 분산을 뜻하지는 않는다.