워크플로우(Workflows)는 코딩 에이전트(Coding Agents)의 새로운 인터페이스다

Claude Code의 동적 워크플로우(Dynamic Workflows)는 코딩 에이전트 (coding-agent) 시장이 채팅(chat)을 넘어 이동하고 있다는 가장 명확한 신호입니다.

이는 좋은 소식입니다. 지난 몇 달 동안 Atomic에서 워크플로우를 사용해 온 저희의 경험에 따르면, 이것이 현재 저희가 일하는 유일한 방식입니다. 단 한 번의 에이전트 턴(agent turn)은 마이그레이션(migration), 보안 감사(security audit), 저장소 전체의 버그 탐색(repo-wide bug hunt), 또는 누군가 신뢰하기 전에 적대적 검토(adversarial review)가 필요한 계획을 수행하기에는 적절한 형태가 아닙니다.

이러한 변화는 특정 제품 발표보다 더 중요합니다. 미래는 단순히 더 나은 모델(models)만을 의미하지 않습니다. 모델을 둘러싼 더 나은 제어 평면(control planes)을 의미합니다.

워크플로우가 중요한 이유

소프트웨어 엔지니어링 (Software engineering)은 단일 동작이 아닙니다. 그것은 판단이 많이 필요한 단계들의 연속입니다:

시스템을 이해하고,
작업 영역(work surface)을 선택하며,
계획을 작성하거나 업데이트하고,
제한된 청크(bounded chunks) 단위로 구현하며,
테스트와 검토자(reviewers)를 통해 검증하고,
다음 엔지니어가 신뢰할 수 있는 산출물(artifacts)을 남기는 것입니다.

채팅(Chat)은 그 순서를 모방할 수 있습니다. 하지만 워크플로우(workflow)는 그 순서를 강제할 수 있습니다.

하위 에이전트(Subagents)와 기술(skills)은 유용한 빌딩 블록(building blocks)이지만, 목표는 루프(loop)를 소유하는 워크플로우입니다: 분기(branching), 재시도(retries), 검토 게이트(review gates), 그리고 중간 상태(intermediate state)를 포함하는 루프 말입니다. 중간 결과물들을 모두 하나의 컨텍스트 윈도우(context window)에 쏟아부어서는 안 됩니다. 검토(Reviews)는 독립적이어야 합니다. 장시간 실행되는 작업은 실행되는 동안 관찰 가능(observable)해야 합니다.

하지만 계획이 코드로 변하면, 다음 질문은 이것입니다: 그 코드는 누가 소유하는가?

Claude Code 동적 워크플로우: 인상적이지만 Claude 중심적이다

동적 워크플로우(Dynamic Workflows)는 오케스트레이션(orchestration)을 네이티브하게 느끼게 해주기 때문에 인상적입니다. 작업을 설명하면, 런타임(runtime)이 백그라운드에서 작업을 분산(fan out)시키고, /workflows를 통해 진행 상황을 검사할 수 있습니다. 주요 사용 사례는 정확히 워크플로우가 빛을 발하는 지점들입니다: 코드베이스 전체 감사(codebase-wide audits), 대규모 마이그레이션(large migrations), 교차 검증된 연구(cross-checked research), 그리고 여러 번의 시도와 적대적 검토(adversarial review)가 필요한 중요한 계획들입니다.

하지만 제품의 형태는 여전히 Claude 중심입니다. Claude가 워크플로우(workflow)를 작성하고, Claude가 이를 실행하며, Claude가 오케스트레이션(orchestration)의 많은 부분을 결정합니다. 공개 문서 또한 명확한 경계들을 설명하고 있습니다: 연구용 프리뷰(research-preview) 상태, 더 높은 토큰 사용량, 세션 범위의 재개(session-scoped resume), 제한적인 실행 중 사용자 입력, 그리고 파일 시스템이나 쉘(shell)에 직접 접근하지 않고 에이전트들을 조정하는 워크플로우 스크립트 등이 그것입니다.

많은 팀에게는 이것만으로도 충분할 것입니다. 하지만 워크플로우 계층을 자신들만의 인프라로 만들고자 하는 엔지니어들에게는 이것이 하나의 기회가 됩니다.

Atomic: 개발자가 소유하는 인프라로서의 워크플로우

Atomic은 다른 전제에서 시작합니다: 워크플로우는 어시스턴트의 구현 세부 사항(implementation detail)이 아닙니다. 그것은 개발자가 소유해야 하는 인터페이스입니다.

해당 리포지토리(repo)는 Atomic을 "코딩 에이전트(coding agents)를 위한 워크플로우 계층"이자, 모델 기반의 세션이 작업을 수행하되 Atomic이 프로세스를 따르도록 보장하는 프로그래밍 가능한 제어 평면(control plane)으로 설명합니다. 내부적으로 Atomic은 Pi 패키지(packages)를 기반으로 구축된 TypeScript/Bun 모노레포(monorepo)입니다. CLI는 워크플로우, 서브 에이전트(subagents), MCP, 웹 액세스, 그리고 인터콤(intercom)을 위한 퍼스트 파티(first-party) 패키지들을 번들링합니다. 이것이 중요한 이유는 Atomic이 단순한 프롬프트 관례(prompt convention)가 아니라, 확장 가능한 런타임(runtime)이기 때문입니다.

Atomic에서 워크플로우는 TypeScript 모듈입니다:

import { defineWorkflow } from "@bastani/workflows";

export default defineWorkflow("review-changes")
...

중요한 부분은 문법이 아니라 계약(contract)입니다. Atomic은 추적 가능한 단계(tracked stages), 병렬 브랜치(parallel branches), 컨텍스트 핸드오프(context handoffs), 아티팩트(artifacts), ctx.ui를 통한 인간의 입력, 재개 가능한 실행 제어(resumable run control), 모델 폴백 체인(model fallback chains), 재사용 가능한 워크트리(worktrees), 그리고 패키지 배포를 제공합니다. 워크플로우는 프로젝트를 위한 .atomic/workflows/, 사용자를 위한 ~/.atomic/agent/workflows/, 설정 또는 패키지 내에 존재할 수 있습니다. 이것들은 사후에 저장된 성공적인 대화 기록이 아니라, 검사 가능한 파일들입니다.

내장된 Atomic 루프

Atomic은 엔지니어들이 보통 직접 다시 만들어야 했던 워크플로우들을 이미 탑재하고 있습니다:

워크플로우 (Workflow)	사용 사례
`deep-research-codebase`	스카우트 (scout), 전문가 웨이브 (specialist waves), 집계 (aggregation), 그리고 지속 가능한 연구 산출물 (durable research artifacts)을 포함한 광범위한 저장소 조사가 필요할 때.
...

Atomic의 표준 (canonical) 흐름은 직관적이며, 슬래시 명령어 (slash commands)를 외우는 대신 대화하듯 호출할 수 있습니다:

이 저장소 전반의 결제 재시도 동작을 매핑하기 위해 심층 조사(deep research)를 실행해줘.
research/payment-retries.md로부터 명세서(spec)를 생성해줘.
목표(goal)를 사용하여 명세서를 구현하고 집중된 재시도 테스트를 실행해줘.
...

이를 통해 엔지니어는 조사 파일, 명세서 (specs), 원장 (ledgers), 작업 영수증 (worker receipts), 리뷰어 결정 (reviewer decisions), 최종 보고서 등 검토 가능한 프로세스를 갖게 됩니다. 만약 작업이 실패하더라도, 단순히 "Claude가 시도했습니다"라는 결과만 남는 것이 아닙니다. 어디서 실패했는지 설명해 주는 산출물 (artifacts)이 남습니다.

만약 이것이 귀하의 프로세스가 아니라면, 직접 작성하면 됩니다. 장애 대응 (Incident response), 릴리스 준비 상태 점검 (release readiness), 의존성 감사 (dependency audits), 마이그레이션 점수 산정 (migration scoring), 접근성 검토 (accessibility review), 문서 QA (docs QA), 벤치마크 분류 (benchmark triage) 등: 워크플로우 인터페이스는 범용적 (general-purpose)입니다.

더 깊은 차이점: 제어 (control), 가시성 (visibility), 신뢰 (confidence)

Claude Code의 동적 워크플로우 (Dynamic Workflows)는 오케스트레이션 (orchestration)을 요청하기 쉽게 만듭니다. Atomic은 오케스트레이션을 소유하기 쉽게 만듭니다.

이러한 차이점은 다음 네 가지 영역에서 나타납니다:

고려 사항	Claude Code 동적 워크플로우 (Dynamic Workflows)	Atomic
워크플로우 작성 (Workflow authoring)	Claude가 현재 작업을 위한 오케스트레이션 스크립트를 동적으로 생성합니다. 성공적인 실행 결과는 Claude Code에 다시 저장될 수 있습니다.	개발자는 Atomic에 특정 워크플로우 사용을 요청하거나, 새로운 워크플로우를 자연어로 설명하여 Atomic이 스캐폴딩 (scaffold)하게 할 수 있습니다. 또는 명시적인 TypeScript 워크플로우를 저장소 소유 코드로서 버전 관리할 수 있습니다.
...

또한 주의 깊게 언급할 만한 실질적인 공급망 (supply-chain) 세부 사항이 있습니다. Atomic의 공개된 CLI 패키지는 설치 라이프사이클 스크립트 (install lifecycle scripts)를 요구하지 않으며, README에는 --ignore-scripts 옵션으로 설치할 수 있다고 명시되어 있습니다. 이는 전역(globally)으로 설치하는 도구로서 더 안전한 기본값입니다.

이것이 임의의 제3자 Atomic 패키지들이 마법처럼 안전하다는 의미는 아닙니다. Atomic의 자체 문서에서도 패키지와 확장 프로그램(extensions)이 전체 시스템 권한을 가지고 실행된다고 경고합니다. 핵심은 더 좁고 유용한 지점에 있습니다. 기본 도구는 핵심 설치 과정을 더 단순하게 유지하면서도, 팀이 신뢰할 수 있는 확장 프로그램을 검토하고 선택할 수 있게 해준다는 점입니다.

엔지니어가 내재화해야 할 사항

워크플로우(Workflows)는 거대한 코드 재작성(rewrites)만을 위한 것이 아닙니다. 대화의 유연성보다 프로세스의 충실도(process fidelity)가 더 중요한 경우라면 언제든 사용하십시오:

발견 사항이 지속적인 메모리(durable memory)가 되어야 하는 광범위한 조사(research),
독립적인 검토가 필요한 위험한 변경 사항,
반복적인 파일 수준의 작업이 수반되는 마이그레이션(migrations),
검증 결과가 증거로서 캡처되어야 하는 작업,
모든 에이전트가 동일한 방식으로 실행하기를 원하는 팀 프로세스.

탐색(exploration)에는 채팅(chat)을 사용하십시오. 위임(delegation)에는 서브에이전트(subagents)를 사용하십시오. 프로세스가 제품의 일부일 때는 워크플로우를 사용하십시오.

Claude Code의 동적 워크플로우(Dynamic Workflows)는 이 카테고리의 정당성을 입증합니다. 이는 진지한 에이전트 기반 코딩(agentic coding)을 위해서는 스크립트(scripts), 백그라운드 실행(background execution), 병렬 처리(parallelism), 그리고 교차 검증(cross-checking)이 필요함을 보여줍니다. Atomic은 동일한 아이디어를 엔지니어에게 한 단계 더 가깝게 밀어붙입니다. 즉, 워크플로우를 저장소(repo)에 유지하고, 수정하고, 패키징하고, 검토하고, 다시 실행할 수 있는 개방적이고, 검사 가능하며, 모델 불가지론적(model-agnostic)인 인프라로 만드는 것입니다.

이것이 코딩 에이전트가 나아가는 방향입니다. 승자는 워크플로우를 가장 잘 숨기는 도구가 아니라, 엔지니어가 신뢰할 수 있을 만큼 워크플로우를 충분히 가시화하는 도구가 될 것입니다.