마이크로서비스로 파이프라인을 짜면 각 워커는 깔끔해지지만, "이 워커들을 누가 순서대로 돌리느냐"는 새로운 문제가 생깁니다. AI 영상 자동화 팩토리는 열 개의 독립 워커(대본·이미지·영상·더빙·조립·업로드·스카우트 등)로 이뤄져 있고, 이들을 하나의 흐름으로 엮는 데 GCP Workflows를 오케스트레이터로 썼습니다. 이 글은 그 마이크로서비스 오케스트레이션 설계를 정리한 것입니다.
왜 코레오그래피가 아니라 마이크로서비스 오케스트레이션인가
마이크로서비스를 잇는 방법은 크게 둘입니다. 하나는 각 워커가 완료 이벤트를 발행하고 다음 워커가 그걸 구독하는 이벤트 체인(코레오그래피), 다른 하나는 중앙의 조율자가 워커를 순서대로 호출하는 오케스트레이션입니다. 짧고 선형적인 흐름이면 이벤트 체인이 단순합니다. 하지만 우리 파이프라인에는 이벤트 체인이 감당하기 어려운 요구가 있었습니다.
- 사람 승인 대기: 중간에 며칠씩 멈춰 사람을 기다려야 한다.
- 분기: 승인/거부에 따라 다음 단계가 갈린다.
- 긴 비동기 대기: 영상 변환 완료를 폴링하며 기다린다.
- 전 구간 상태 추적: 지금 어느 단계인지, 어디서 실패했는지 한 곳에서 봐야 한다.
이런 흐름은 "지금 어디에 있고 다음에 어디로 가는가"를 한눈에 관리할 중앙 상태머신이 있어야 합니다. 그래서 코레오그래피 대신 GCP Workflows 오케스트레이터를 택했습니다.
상태머신으로 표현한 파이프라인
파이프라인은 7단계 상태머신입니다. 각 단계는 워커를 호출하고, 성공하면 다음 상태로, 실패하면 FAILED로 전이합니다. 핵심은 모든 단계가 try/except로 감싸여 실패를 격리한다는 점입니다.
한 워커가 죽어도 failed_at에 어느 단계에서 멈췄는지가 기록되고 파이프라인은 그 잡만 FAILED로 내려놓습니다. 다른 잡·다른 채널은 영향을 받지 않습니다. 이 실패 격리가 열 개 워커를 실전에서 돌릴 수 있게 만드는 조건입니다. 파이프라인 단계의 전체 그림은 AI 영상 파이프라인이란에서 볼 수 있습니다.
승인 대기를 오케스트레이터가 관리한다
오케스트레이션의 진짜 값어치는 사람 승인 대기에서 드러납니다. 워크플로가 콜백 엔드포인트를 만들어 URL을 Firestore에 저장하고 await_callback으로 일시정지하면, 그 사이 어떤 워커도 켜져 있을 필요가 없습니다. 대시보드가 URL로 결정을 POST하는 순간 워크플로가 그 지점부터 재개됩니다.
이 방식은 외부 서비스의 웹훅을 받아 시스템 상태를 잇는 통합 패턴과 본질이 같습니다. 웹훅으로 외부 이벤트를 시스템에 통합하는 다른 사례는 전자계약을 시스템에 통합하기에서도 다룹니다. 승인 게이트 설계 자체는 AI 콘텐츠를 완전 자동으로 올리면 안 되는 이유에서 자세히 풀었습니다.
크리덴셜을 코드에 두지 않는다
마이크로서비스가 늘어나면 각 워커의 URL과 API 키를 어디에 두느냐가 문제입니다. 우리는 이를 코드나 환경변수에 하드코딩하지 않고, 워크플로 기동 시 Secret Manager에서 런타임에 불러옵니다. 워커 URL조차 시크릿으로 관리해, 배포 환경이 바뀌어도 코드를 건드리지 않습니다.
- get_script_worker_url:
call: googleapis.secretmanager.v1.projects.secrets.versions.access
args:
name: ${"projects/.../secrets/script-worker-url/versions/latest"}이렇게 하면 시크릿 값이 파이프라인 정의에도, 코드 저장소에도 남지 않습니다. 로그·다이어그램에는 논리적 이름(script-worker-url)만 노출됩니다.
채널 설정을 읽어 동작을 분기한다
같은 파이프라인이 채널마다 다르게 동작해야 합니다. 워크플로는 시작할 때 채널 문서를 읽어 아키타입 같은 설정을 가져오고, 그 값으로 대본 생성 프롬프트를 분기합니다. 설정 필드가 없으면 안전한 기본값(knowledge)으로 폴백해, 옛날에 만든 채널도 깨지지 않습니다. 이 "설정을 읽어 분기하는" 구조 덕분에 채널을 추가해도 파이프라인 코드는 그대로입니다. 전체 사례는 AI 영상 자동화 팩토리에서 볼 수 있습니다.
자주 묻는 질문
긴 비동기 AI 파이프라인을 어떻게 오케스트레이션하나요?
각 단계를 상태로 표현한 상태머신을 중앙 오케스트레이터(GCP Workflows)로 돌립니다. 워커 호출은 try/except로 감싸 실패를 격리하고, 오래 걸리는 단계는 폴링이나 콜백으로 완료를 기다립니다. 이렇게 하면 지금 어느 단계인지, 어디서 실패했는지를 한 곳에서 추적할 수 있습니다.
승인 대기 같은 사람 개입은 어떻게 처리하나요?
워크플로가 콜백 엔드포인트를 만들어 URL을 저장하고 await_callback으로 일시정지합니다. 대기 중에는 어떤 워커도 켜져 있을 필요가 없고, 대시보드가 그 URL로 결정을 POST하면 정확히 그 지점부터 재개됩니다. 타임아웃은 사람을 기다릴 만큼 넉넉히 둡니다.
이벤트 체인(Pub/Sub) 대신 오케스트레이터를 쓴 이유는 무엇인가요?
파이프라인에 사람 승인 대기, 승인/거부 분기, 긴 비동기 대기, 전 구간 상태 추적이 필요했기 때문입니다. 이런 흐름은 "지금 어디에 있고 다음에 어디로 가는가"를 한 곳에서 관리할 중앙 상태머신이 있어야 안정적으로 돌아갑니다.
워커 URL과 API 키는 어디에 두나요?
코드나 환경변수가 아니라 Secret Manager에 두고 런타임에 불러옵니다. 워커 URL조차 시크릿으로 관리하므로 파이프라인 정의와 코드 저장소에 시크릿 값이 남지 않고, 로그에는 논리적 이름만 노출됩니다.