run = self._runs.submit(workload=..., pipeline_origin=origin, ctx=ctx)
return run.id

run = self._runs.submit(...)
if run.state is RunState.QUEUED:
    self._runs.start(run.id, actor=

회귀 테스트(regression test)인 `test_pipeline_starts_its_child_runs`는 자식 작업이 `running` 상태로 전환되는지 확인합니다. 이 테스트는 이전에는 실패했지만, 지금은 통과했습니다. 왜 제가 이걸 가지고 있지 않았을까요? 제 단위 테스트(unit test)가 동기식 실행기(synchronous executor)를 사용해서 누락된 시작 과정을 숨겼기 때문입니다. 동기식 경로는 워커(worker)가 필요하지 않으므로, 워커의 부재는 눈에 띄지 않았습니다. 오직 워커가 없는 실제 스택(live stack)만이 이를 노출했습니다. Docker 보고서의 [§3.3](https://github.com/deghosal-2026/hiveplane/blob/main/docs/field-test/v0.2.0/DOCKER_TEST_REPORT.md)는 정확한 전환 과정을 추적하며, [오케스트레이션 설계(orchestration design)](https://github.com/deghosal-2026/hiveplane/blob/main/docs/design/orchestration-design.md)가 파이프라인 실행 모델을 문서화하고 있습니다.

> **팁:** 자식 작업을 생성하는 모든 구성 요소(파이프라인, 트리거, 인증 등)는 해당 작업을 시작하거나, 해당 작업을 임대하는 워커에 의존해야 합니다. 테스트 실행기가 동기식이라면, 당신이 배포하려는 정확한 버그를 숨기고 있는 것입니다.

## 어둠 속에서 성공한 전달(delivery)

D-4가 더 교묘했습니다. 팬아웃(fan-out)은 실제로 작동했습니다. 웹훅 싱크(webhook sink)는 `run.completed` 페이로드를 기록했습니다. 시도들은 `fan_out_deliveries`에 `delivered` 상태로 작성되었습니다.

하지만 제가 시나리오에서 폴링했던 `/delivery/audit`는 M51의 `delivery_attempts` 스토어를 읽습니다. 두 개의 하위 시스템, 하나의 개념, 두 개의 스토어입니다. 성공적인 전달은 **제어 평면(control plane)을 통해서는 감사할 수 없었습니다**. 제 테스트는 200과 빈 리스트를 확인하고 넘어갔는데, 이는 빈 리스트가

이 부분이 저를 가장 무섭게 만들었습니다. 인터랙티브하고 모바일 환경에서의 승인(approvals) — Slack 버튼, 이메일 링크 등 — 은 `resolve()` 함수가 아무 동작도 하지 않는 (no-op) 람다에 연결되어 있었습니다:

결정(decision)은 `approval_decisions` 테이블에 영구적으로 저장되었습니다. 테스트는 해당 행이 존재하는지 확인했습니다. 테스트는 통과했습니다. 하지만 일시 중단된 실행(run)은 절대 재개되지 않았습니다. 운영자가 '승인'을 클릭하고, 확인 메시지를 보았지만, 실행은 영원히 일시 중단 상태로 머물렀습니다.

녹색으로 나온 테스트는 한 행이 작성되었다는 것만 증명했습니다. 그 실행(run)이 이동했다는 것은 증명하지 못했습니다. 해결책은 `resolve()`가 `RunService.resume(run_id)`를 호출하도록 하는 것이었습니다. 이것이야말로 운영자가 실제로 신경 쓰는 부수 효과(side effect)입니다. 회귀 테스트(regression test)는 결정 기록의 존재 여부가 아니라, 실행이 'running' 상태로 전환되는지 확인합니다.

> **팁:** 가장 위험한 '녹색' 테스트는 기록만 확인하고 실제 효과를 확인하지 않는 테스트입니다. 승인 과정에서 아무런 재개 없이 단순히 기록만 남기는 것은 워크플로우처럼 위장된 단순 동작(no-op)일 뿐입니다. 테스트에게 물어보세요: '운영자가 무엇을 보았는가?' 그리고 그것을 검증하세요.

## 제가 배운 것들

단위 테스트(unit test)는 경계선에서 멈췄습니다. 버그는 그보다 한 단계 더 나아간 경계에 존재했고, 동기식 테스트 실행기(synchronous test executor)가 바로 이 경계선을 보이지 않게 만든 원인이었습니다. 워커도 없고, 단축키도 없는 실제 스택만이 유일하게 정직한 증인입니다.

v0.2.0 필드 테스트는 **36/36 시나리오, 67/67 컨테이너 테스트, 50/50 부하 테스트**라는 결과를 가져왔습니다. 하지만 이것은 제가 실제 스택에 대해 엔드투엔드로 재실행하고, 제 녹색 단위 테스트 모음(green unit suite)을 더 이상 믿지 않게 되었기 때문이었습니다. 전체 보고서는 [field-test report](https://github.com/deghosal-2026/hiveplane/blob/main/docs/field-test/v0.2.0/FIELD_TEST_REPORT.md)와 [Docker test report](https://github.com/deghosal-2026/hiveplane/blob/main/docs/field-test/v0.2.0/DOCKER_TEST_REPORT.md)에서 확인할 수 있습니다.

## 참고 자료

-   [HivePlane](https://github.com/deghosal-2026/hiveplane) — `pip install hiveplane==0.2.0`
-   [Field test report (36/36)](https://github.com/deghosal-2026/hiveplane/blob/main/docs/field-test/v0.2.0/FIELD_TEST_REPORT.md) · [Docker report (67/67)](https://github.com/deghosal-2026/hiveplane/blob/main/docs/field-test/v0.2.0/DOCKER_TEST_REPORT.md)
-   [Orchestration design](https://github.com/deghosal-2026/hiveplane/blob/main/docs/design/orchestration-design.md)
-   [v0.2.0 릴리스 노트](https://github.com/deghosal-2026/hiveplane/blob/main/docs/release/v0.2.0/release-notes.md)

**당신의 테스트 스위트에서 가장 비용이 많이 드는 '녹색' 테스트, 즉 200과 행은 확인하지만 부작용(side effect)은 확인하지 않는 테스트가 무엇인지 찾아보세요. 가서 보세요. 기다릴게요.**