대규모 AI 기반 시스템을 개발할 때 흔히 볼 수 있는 오케스트레이션 구조는 다음과 같습니다.

Orchestrator
↓
Planner
↓
Worker × N
↓
Reviewer
↓
Test
↓
Final Verification

이 글에서는 각 단계에서 개발자가 담당해야 하는 구체적인 역할과 책임, 그리고 단계 간 협업 시 고려해야 할 모범 사례를 정리합니다. 내용은 사용자가 제시한 워크플로우 모델을 근거로 하여 작성되었습니다【user instruction】.

1. Orchestrator (총괄 조정자)

역할

  • 전체 워크플로우의 시작점이자 종결점을 관리한다.
  • 외부 트리거(사용자 요청, 스케줄, 이벤트)를 수신하고, 적절한 Planner에 작업을 전달한다.
  • 워크플로우의 상태를 추적하고, 오류 시 재시작 또는 알림을 담당한다.

개발자 책임

  • 워크플로우 엔진 설계 및 구현 (예: Temporal, Airflow, 맞춤형 상태 머신).
  • 메시지 큐/이벤트 버스(Kafka, RabbitMQ, 내부 Hermes 게이트웨이 등)와의 연동을 통해 작업 전달 메커니즘 구축.
  • 재시동 정책, 타임아웃, 데드 레터 큐 설정으로 내결함성 보장.
  • Orchestrator 자체에 대한 메트릭 및 로그(작업 처리량, 대기 시간, 실패율)를 수집하고 모니터링 대시보드에 연동.

모범 사례

  • 워크플로우 정의를 코드로서 선언(Workflow as Code)하여 버전 관리 및 리뷰 가능하게 함.
  • Orchestrator는 가능한 한 순수 로직(비즈니스 규칙)만 포함하고, 실제 작업 수행은 하위 컴포넌트에 위임한다.

2. Planner (계획 수립자)

역할

  • Orchestrator로부터 받은 고수준 목표를 구체적인 실행 계획으로 변환한다.
  • 작업을 작업 단위(task)로 분해하고, 각 작업의 의존성, 필요한 리소스, 예상 실행 순서를 결정한다.
  • 필요한 경우 Worker 유형(예: 코드 생성, 데이터 처리, 모델 훈련)을 선택하고 할당한다.

개발자 책임

  • 작업 분해 알고리즘 또는 규칙 기반 로직 구현 (예: LLM 기반 계획 생성, 템플릿 기반 플래너).
  • 작업 메타데이터 스키마 설계 (ID, 설명, 입력/출력 사양, 필요 도구, 예상 소요 시간, 재시도 횟수 등).
  • 의존성 그래프를 생성하고, 순환 의존성 검사 및 토폴로지 정렬 수행.
  • Planner가 생성한 계획을 저장 및 추적할 수 있도록 영구 저장소(예: PostgreSQL, Redis)에 기록.

모범 사례

  • 계획을 불변 객체로 만들어, 실행 중 변경이 없도록 보장한다.
  • Planner의 출력을 검증하는 스키마 검증(JSON Schema 등)을 도입하여 잘못된 계획을 차단한다.
  • 계획 생성 과정에서 토큰 소모 및 비용을 모니터링하고, 필요 시 폴백 규칙을 적용한다.

3. Worker × N (작업 실행자)

역할

  • Planner가 배정한 개별 작업 단위를 실제 실행한다.
  • Worker는 동일 유형의 여러 인스턴스가 병렬로 동작할 수 있으며, 각 인스턴스는 할당된 작업을 독립적으로 처리한다.
  • 실행 결과(성공/실패, 출력물, 로그, 메트릭)를 Planner 또는 다음 단계(Reviewer)에 전달한다.

개발자 책임

  • 작업 실행 환경 제공 (컨테이너, 가상 머신, 샌드박스). 예: Docker, Kubernetes Job, Hermes 내장 터미널 도구.
  • 작업이 필요로 하는 도구·라이브러리(예: git, Python 패키지, 특정 CLI) 설치 및 버전 관리.
  • 실행 중 발생하는 예외를 잡아 적절한 오류 코드 및 메시지를 반환하도록 스크립트 또는 래퍼를 작성.
  • Worker의 리소스 사용량(CPU, 메모리, 디스크 I/O)을 수집하여 스케줄러에 피드백한다.
  • 가능한 경우 멱등성(같은 입력이 여러 번 들어가도 동일한 결과)을 보장하여 재시도 시 부작용을 최소화한다.

모범 사례

  • 작업 실행을 단계별로 로깅하고, 최종 결과물은 아티팩트 저장소(S3, GCS, 내부 아티팩트 저장)에 저장하여 추적 가능하게 함.
  • Worker는 외부 네트워크 접근을 최소화하고, 필수적인 호출만 허용하는 보안 샌드박스 내에서 실행한다.
  • 작업 완료 시 알림 메시지(예: Hermes 내부 메시지, 웹훅)를 보내어 다음 단계(Reviewer)가 신속히 인지하도록 한다.

4. Reviewer (검토자)

역할

  • Worker가 생성한 결과물(코드, 문서, 모델, 아티팩트 등)을 품질 검토한다.
  • 정적 분석, 코드 리뷰, 보안 스캔, 스타일 검사 등을 수행하고, 문제가 발견되면 피드백을 반환한다.
  • 검토 통과 여부에 따라 작업을 승인하거나 재작업 요청(Worker로 되돌림)을 결정한다.

개발자 책임

  • 리뷰 자동화 파이프라인 구축 (예: pre-commit hooks, GitHub Actions, 내부 검토 봇).
  • 코드 품질 검사 도구 통합 (ESLint, Prettier, Bandit, SonarQube, Trivy 등).
  • 보안 취약점 스캔 (의존성 검사, 컨테이너 이미지 스캔, 시크릿 탐지).
  • 리뷰 결과를 표준화된 피드백 형식(JSON 또는 마크다운)으로 제공하여 Worker가 쉽게 이해하고 조치할 수 있도록 함.
  • 검토가 인간이 포함되는 경우, 리뷰 할당 알림(Slack, Hermes 메시지) 및 마감 시간(SLA)을 설정한다.

모범 사례

  • 리뷰 기준을 문서화된 체크리스트로 만들어 일관성을 유지하고, 신규 개발자도 쉽게 따라할 수 있게 함.
  • 자동 검토가 불가능한 영역(예: 아키텍처 결정, 비즈니스 로직 타당성)은 인간 리뷰어를 명시적으로 지정하고, 리뷰 회선을 최소화한다.
  • 리뷰 통과 시 자동으로 다음 단계(Test)로 작업을 전달하는 트리거를 구축한다.

5. Test (테스트 실행자)

역할

  • Reviewer를 통과한 아티팩트에 대해 자동화된 테스트를 수행한다.
  • 단위 테스트, 통합 테스트, 성능 테스트, 보안 테스트 등을 포함할 수 있다.
  • 테스트 결과에 따라 작업을 통과 또는 실패로 판정하고, 실패 시 원인 분석 정보를 제공한다.

개발자 책임

  • 테스트 프레임워크 선택 및 설정 (JUnit, pytest, Jest, Cypress, k6 등).
  • 테스트 환경을 격리하고 재현 가능하도록 컨테이너 또는 임시 인프라를 사용한다.
  • 테스트 스크립트를 버전 관리하고, CI 파이프라인에 통합하여 매 커밋 혹은 PR마다 자동 실행되도록 함.
  • 테스트 결과를 JUnit XML, TestRail, 내부 대시보드 등 표준 형식으로 출력하여 추적 및 알림을 가능하게 함.
  • 성능 테스트의 경우 기준선(baseline)과 비교하여 회귀를 탐지하고, 임계값 초과 시 알림을 발생시킨다.

모범 사례

  • 테스트 코드도 생산 코드와 동일한 품질 기준을 적용하여 리뷰 대상에 포함한다.
  • 테스트 실패 시 즉시 알림(Hermes 메시지, 슬랙 채널)과 함께 실패한 테스트 케이스 이름 및 로그를 제공하여 빠른 디버깅을 지원한다.
  • 테스트 커버리지 목표를 설정하고, 정기적으로 리뷰하여 품질 저하를 방지한다.

6. Final Verification (최종 검증)

역할

  • 모든 이전 단계를 통과한 작업이 최종 사용 목적(배포,リリース, 문서 게시 등)에 적합한지를 최종적으로 확인한다.
  • 배포 전 최종 검증, 스모크 테스트, 카나리 릴리스 검증, 혹은 게시된 콘텐츠의 정확성 검토 등을 수행한다.
  • 최종 검증이 성공하면 작업을 완료로 표시하고, 관련 이해관계자에게 결과를 통보한다.

개발자 책임

  • 배포 파이프라인과의 연동 (ArgoCD, Flux, Spinnaker, 내부 배포 스크립트) 를 통해 최종 아티팩트를 실제 환경에 적용.
  • 배포 후 헬스 체크와 스모크 테스트를 자동으로 실행하여 서비스 가용성을 확인.
  • 문서나 블로그 게시와 같은 콘텐츠 작업의 경우, 실제 URL 접근성, 제목·내용 일치 여부, 빌드 배포 성공 여부 등을 최종 검증 항목으로 포함한다.
  • 최종 검증 결과를 로그 및 메트릭(배포 성공률, 평균 배포 시간, 실패 원인)으로 기록하여 지속적인 개선에 활용한다.
  • 배포가 실패한 경우 자동 롤백 또는 수동 개입 절차를 정의하고, 관련 팀에 알림을 보낸다.

모범 사례

  • 최종 검증 단계도 자동화 수준을 높이고, 수동 개입은 예외 상황에만 한정한다.
  • 배포 후 모니터링 지표(오류율, 지연 시간, 자원 사용량)를 기준선과 비교하여 이상 징후를 조기에 탐지한다.
  • 모든 단계의 로그와 메트릭을 통합 관측성 플랫폼(예: Loki + Grafana, Elasticsearch)에 집계하여 엔드‑투‑엔드 가시성을 확보한다.

마무리

위와 같이 Orchestrator → Planner → Worker × N → Reviewer → Test → Final Verification 워크플로우에서 개발자는 각 단계에서 해당 단계의 목적을 달성하기 위한 도구, 자동화, 검증, 모니터링 등을 설계·구축·운영하는 역할을 수행합니다. 개발자의 업무는 단순히 코드를 작성하는 것을 넘어, 전체 시스템의 신뢰성, 재현성, 확장성을 보장하는 인프라와 프로세스를 만드는 데 집중됩니다.

이러한 역할을 명확히 정의하고, 단계 간 인터페이스를 표준화함으로써 팀은 복잡한 AI 기반 프로젝트를 보다 예측 가능하고 효율적으로 진행할 수 있습니다. 앞으로도 각 단계의 책임을 지속적으로 개선하고, 자동화 수준을 높여 개발 속도와 품질을 동시에 향상시켜 나가길 바랍니다.

참고: 본 글은 사용자가 제시한 워크플로우 모델(Orchestrator‑Planner‑Worker‑Reviewer‑Test‑Final Verification)을 기반으로 작성되었으며, 각 단계의 역할은 일반적인 AI 엔지니어링 관행 및 Hermes Agent 운영 원칙을 반영합니다.【user instruction】