AI Commons

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

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

2. LaTeX 기반 생성

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

3. HTML 템플릿 고도화

기존 방식의 연장선이라 근본적 한계가 해결되지 않는다.

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

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

결정

솔직히 그 시점에서 LaTeX이 당장의 안정성 면에서는 더 나은 선택이었을 수 있다. 하지만 서비스가 데모로 나가야 하는 일정을 고려했을 때, AI 이미지 생성 모델이 빠르게 개선되고 있는 흐름을 보고 미래를 생각해서 Gemini 이미지 생성 방식을 선택했다. 초기의 불완전함은 프롬프트 엔지니어링으로 대응하면서, 모델 자체의 발전을 기다리는 전략이었다.

일관성 확보

AI 이미지 생성의 약점인 결과 일관성 문제는 3단계 프롬프트 체인(덱 공통 디자인 지침 → 페이지별 개별 지침 → Gemini 이미지 합성)으로 대응했다. 이후 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 스크립트로 구현. Redis의 단일 스레드 실행으로 다중 서버에서도 race condition이 발생하지 않는다. 같은 burst에서 발생한 여러 429가 limit을 과도하게 줄이는 것을 방지하기 위해 waveId 기반 중복 제거도 구현.

Circuit Breaker

외부 API 호출에 Circuit Breaker 패턴(CLOSED→OPEN→HALF_OPEN)을 적용. 429 에러는 서비스 장애가 아니므로 커스텀 에러 필터로 Circuit Break 대상에서 제외하고, 분산 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로 실제 duration을 정확히 측정하고, -itsoffset과 오디오 패딩으로 밀리초 단위 정렬. 50장 이상의 영상에서도 싱크 드리프트 제로.

4. 슬라이드 간 음성 여백

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

출발점: "컨텍스트에 문서를 넣는다"는 프레이밍 자체가 함정이다

이 프레이밍을 받아들이는 순간, 해결책은 "어떻게 더 잘 요약/압축할까"로 수렴한다. 하지만 문제를 "교육 가능한 지식을 어떻게 표현할까"로 재정의하면, 문서 원본은 고려 대상에서 제외된다.

기존 가정 해부: 관성인가 필연인가

• "문서 내용을 LLM 컨텍스트에 넣어야 한다" → 관성. 인간 교수는 50권의 교재를 동시에 펼쳐놓고 강의를 설계하지 않는다. 이미 읽고 이해한 상태에서 설계한다. "컨텍스트에 넣는다"는 것은 LLM에게 "읽기와 사고를 동시에 하라"고 요구하는 것이다.
• "문서를 청크로 쪼개서 벡터로 검색해야 한다" → 관성. RAG의 표준 패턴을 의심 없이 따르고 있었다. 하지만 강의 설계에 필요한 건 특정 문장 검색이 아니라 "이 자료들에서 뭘 가르칠 수 있는가"에 대한 구조적 이해다.
• "하나의 LLM 호출이 전체를 처리해야 한다" → 관성. 강의 설계라는 작업 자체가 단일 사고 과정이 아니다. 읽기, 설계, 채우기를 분리할 수 있다.
• "원본 문서의 표현을 보존해야 한다" → 대부분 관성. 강의 설계에 필요한 것은 원본의 문장이 아니라 지식 구조다. 원본은 세부 콘텐츠 생성 단계에서만 필요.
• "모든 문서가 동등하게 중요하다" → 관성. 실제로는 핵심 교재 1~2권이 있고 나머지는 보조 자료일 가능성이 높다.

본질만 남기기

모든 관성을 걷어내면 남는 본질: 입력은 "N개의 문서에 담긴 가르칠 수 있는 지식", 출력은 "학습 목표 → 순서 → 구조를 가진 강의 설계". 필요한 건 문서의 텍스트가 아니라 교육 가능한 지식의 구조적 표현이다.

제안: Knowledge Structure First

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

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

• Phase 1 (읽기): 업로드 시점에 각 문서의 지식 구조를 비동기로 추출 — 개념, 개념 간 선후관계, 난이도, 교육 가능 단위(teachable units)
• Phase 2 (설계): 지식 구조(JSON)만으로 강의 설계 수행. 이 시점에 문서 원본은 컨텍스트에 없음. LLM은 읽기를 안 하고 설계만 함
• Phase 3 (채우기): 특정 레슨의 세부 콘텐츠 생성 시에만 source_ref로 해당 문서의 해당 부분을 가져와서 원본 기반으로 생성

핵심 인사이트

지식 구조 추출은 문서 수에 대해 sublinear하게 스케일링한다 — 문서가 늘어나면 중복 개념이 기하급수적으로 증가하기 때문이다. 문서 500개여도 고유한 교육 가능 개념은 수백~수천 개이고, 개념 하나를 표현하는 데 50-100 토큰이면 충분하다. 128K 토큰이라는 컨텍스트 공간은 충분히 넓다. 문제는 그 공간에 얼마나 밀도 높은 정보를 넣느냐다.

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

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

근본적 재설계: 순차 생성 + Responses API

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

트레이드오프 분석

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

• 안정성: 한 페이지씩 처리하므로 컨텍스트 초과로 인한 실패가 원천적으로 사라짐. 오류 발생 시 해당 페이지만 재시도(최대 2회)하고, 재시도 실패 시 명시적 에러 UI를 표시하고 중단
• 품질: 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 round-trip → 1 round-trip으로 약 70% 커넥션 점유 시간 단축.

5. SSE와 폴링 로직 통일

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

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

검증 결과

Chrome DevTools (CPU 4x throttling + Slow 4G) 환경에서 슬라이드 에디터 6개 탭 동시 실행, 전체 이미지 생성 작업 진행 중 10분간 측정했다.

개선 후 모든 탭이 Lighthouse 100점을 달성했고, 탭 간 성능 편차도 사라졌다(Before: 75~90점 → After: 100점 균일). CPU 4x throttling 환경에서도 100점이므로, 실제 저사양 기기에서도 원활한 동작이 보장된다.