그래프 엔지니어링은 여러 특화 에이전트를 노드로 두고, 엣지로 라우팅하며, 공유 상태(state)를 엣지 위로 흘려보내는 설계를 말해요. 오르카(Orca)는 그 구조를 CLI 프리미티브 5종(Run·Task·Dispatch·Message·Decision gate)으로 구현한 데스크톱 ADE이고, MIT 라이선스에 2026년 8월 9일 기준 GitHub 스타 약 40,500개예요.

랭체인 CEO가 "그냥 랭그래프 아닌가"라던 그래프 엔지니어링, 오르카로 돌려봤어요

그래프 엔지니어링은 여러 특화 에이전트를 노드로 두고, 엣지로 라우팅하며, 공유 상태를 엣지 위로 흘려보내는 설계예요. 오르카(Orca)는 그 구조를 CLI 프리미티브 5종으로 구현한 MIT 라이선스 데스크톱 ADE이고, 2026년 8월 9일 기준 GitHub 스타 약 40,500개예요. 다만 오케스트레이션은 아직 실험 기능이고, 에이전트 3개를 병렬로 돌리면 구독 쿼터도 3배로 나가요.

그래프 엔지니어링(Graph Engineering)이라는 말이 퍼지기 시작한 시점은 2026년 7월 18일이에요. 오픈클로(OpenClaw)를 만든 피터 스타인버거(Peter Steinberger)가 X에 “우리는 아직 루프 얘기를 하고 있나, 아니면 그래프로 넘어갔나”라고 던진 게 발화점이었어요. 이틀 뒤인 7월 20일 랭체인(LangChain) CEO 해리슨 체이스(Harrison Chase)가 “그게 뭔지 몰랐고 지금도 잘 모르겠는데, 그냥 랭그래프 아닌가”라고 받아쳤고요. 용어는 3주 남짓 됐지만, 개념을 실제로 돌려볼 도구는 이미 나와 있어요. 오르카(Orca)입니다.

한눈에 보기

그래프 엔지니어링은 여러 특화 에이전트를 노드로 두고, 엣지로 라우팅하며, 공유 상태(state)를 엣지 위로 흘려보내는 설계를 말해요.
오르카(Orca)는 그 구조를 CLI 프리미티브 5종(Run·Task·Dispatch·Message·Decision gate)으로 구현한 데스크톱 ADE이고, MIT 라이선스에 2026년 8월 9일 기준 GitHub 스타 약 40,500개예요.
오케스트레이션 기능은 Settings → Experimental에서 켜야 하는 실험 기능이고, 에이전트 3개를 병렬로 돌리면 구독 쿼터도 3배로 나가요.

루프와 그래프의 차이

루프와 그래프의 차이는 실행 단위가 하나냐 여럿이냐에 있어요. 루프 엔지니어링은 하나의 세션이 종료 조건에 닿을 때까지 계획·실행·검토를 반복하는 구조고, 그래프 엔지니어링은 그 단위를 여러 개 두고 관계로 엮어요. 부모 노드가 끝나면 자식 노드가 돌고, 상태 값에 따라 분기가 갈리고, 검토 결과가 나쁘면 앞 노드로 되돌아가는 식이죠.

여기서 자주 오해되는 부분이 하나 있어요. 그래프가 루프를 대체하는 게 아니라는 점이에요. 용어를 확산시킨 AI Builder Club 가이드의 한 줄이 정확해요.

그래프는 루프의 죽음이 아니에요. 그래프의 모든 노드는 여전히 루프예요.

스타인버거 본인의 원래 주장도 “코딩 에이전트에 직접 프롬프트하지 말고, 에이전트에게 프롬프트하는 루프를 설계하라”였어요. 그 층위는 그대로 살아 있어요. 그래프는 루프를 하나의 노드 안으로 집어넣고, 노드 바깥의 흐름을 따로 관리하는 방식이에요.

오르카(Orca)라는 도구의 정체

오르카는 여러 AI 코딩 에이전트를 동시에 굴리는 데스크톱 ADE(Agent Development Environment)예요. 클로드 코드(Claude Code), 코덱스(Codex), 커서 CLI, 오픈코드 등 20~30종의 CLI 에이전트를 붙일 수 있어요. 검색창에 ‘오르카 ai’, ‘orca ide’, ‘orca ade’가 섞여 들어오는데, 공식 문서가 쓰는 표현은 IDE가 아니라 ADE예요.

구조에서 가장 중요한 건 격리 단위예요. 오르카는 작업 1개 = 격리된 git worktree 1개로 두고, worktree마다 전용 터미널과 브라우저 탭을 붙여요. 그래프 논의에서 자주 빠지는 실무 조건이 바로 이 지점이에요. 노드를 병렬로 돌리려면 노드끼리 같은 파일을 밟지 않아야 하는데, 라이브러리 층위는 이 문제를 사용자에게 떠넘기거든요. 추상 개념(노드)을 OS 수준 격리(worktree)에 1:1로 붙인 게 이 제품의 실질적 기여예요.

만든 곳과 라이선스

오르카를 만든 곳은 스테이블리 AI(Stably AI, 법인명 Lovecast Inc.)이고, 라이선스는 MIT예요. Y Combinator W22 배치 출신이고, 팀은 4명, 샌프란시스코에 있어요. 공동창업자는 진징 량(Jinjing Liang, CEO, 전 구글 크롬 시니어 엔지니어)과 닐 파커(Neil Parker, 전 우버 테크리드)입니다.

소스는 전체가 공개돼 있어요. 레포는 stablyai/orca, 2026년 8월 9일 기준 스타 약 40,500개에 main 브랜치 커밋 8,202개예요. 오르카 자체는 무료이고, 에이전트는 본인 구독을 그대로 쓰는 BYO 방식이에요. 사내 보안 검토를 통과시켜야 하는 조직이라면 MIT + 소스 공개라는 조건이 꽤 유리하게 작동해요.

오케스트레이션 프리미티브 5종

오르카의 오케스트레이션 프리미티브는 Run·Task·Dispatch·Message·Decision gate 5종이에요. 공식 문서가 정의한 개념이고, 그래프 어휘로 옮기면 대응이 상당히 깔끔합니다.

오르카 프리미티브	문서상 정의	대응하는 그래프 개념
Run	네임스페이스 + 코디네이터 인박스	그래프 인스턴스 1개
Task	작업 단위, 상태 6종 보유	노드(Node)
Dispatch	워커에 작업 할당	노드 실행 트리거
Message	스레드형 메시지 전달	엣지 위를 흐르는 상태
Decision gate	`gate-create --question ... --options`	조건 분기 + 사람 검토 노드

오른쪽 열은 제가 두 출처를 대조해 붙인 해석이에요. 스타인버거의 그래프 담론을 다룬 기사 어디에도 오르카 언급은 없어서, 업계 정설처럼 받아들이지는 않는 게 맞아요.

Task 상태는 pending, ready, dispatched, completed, failed, blocked 6종이에요. pending과 ready가 분리돼 있다는 건 선행 의존성이 풀려야 실행 가능 상태로 넘어간다는 뜻이고, 이게 DAG(방향성 비순환 그래프) 실행의 최소 요건이에요. 상태 라벨이 아니라 상태 기계(state machine)라고 보는 편이 이해가 빨라요.

설치와 활성화 순서

오르카 CLI 설치는 별도 설치가 아니라 등록이에요. CLI가 데스크톱 앱에 이미 동봉돼 있거든요.

CLI 등록 — Settings → General → Orca CLI
오케스트레이션 켜기 — Settings → Experimental (안정 기능이 아니라 실험 기능이에요)
설치 확인 — command -v orca, orca status --json
스킬 목록 확인 — orca skills list
스킬 설치 — orca skills install --skill orchestration (전체는 --all)
가이드 조회 — orca skills get orchestration --full

여기서 헷갈리기 쉬운 게 get과 install의 차이예요. get은 가이드를 읽어오는 조회 명령이고, 실제 설치는 install이에요. 온보딩 안내 글들이 이 둘을 섞어 쓰는 경우가 있으니 한 번 확인해 두면 편해요.

직접 깔아보면서 겪은 것 두 가지를 덧붙일게요. 첫째, npx skills add로 스킬을 하나씩 지정해 넣다 보면 누락이 생기기 쉬워요. 저는 몇 개만 깔고 나머지를 통째로 빠뜨렸는데, orca skills install --all로 다시 돌리니 호스트에 실제로 있는 에이전트 기준으로 맞춰 깔려서 누락이 없었어요. 무엇이 실행될지 미리 보고 싶으면 --dry-run을 붙이면 돼요.

둘째, 사내 프라이빗 npm 레지스트리를 쓰는 환경이라면 전역 ~/.npmrc 때문에 설치가 ENOTFOUND로 죽어요. 그 프로세스에만 레지스트리를 덮어쓰는 방식(PowerShell이면 $env:npm_config_registry='https://registry.npmjs.org/')으로 넘어갔어요. 전역 설정을 고치면 회사 프로젝트 빌드가 같이 깨지니 손대지 않는 편이 안전해요.

5개 병렬에서 검토 게이트까지

5개 병렬에서 검토 게이트까지는 run-create → task-create → worker-start → check –wait → gate-create 다섯 단계로 이어지는 흐름이에요. 아래는 공식 문서에 실재하는 명령으로 구성한 예시 설계예요. 특정 회사의 실제 도입 사례가 아니라, 문서상 프리미티브만으로 짜본 그림이라는 점은 밝혀둘게요.

orca orchestration run-create --objective "..." --json — 그래프 하나 생성
task-create --spec "..." --task-title "..." --json — 노드 5개 등록, 의존성 지정
worker-start --task <id> --worktree current --agent codex --json — 워커 기동
check --wait --types worker_done,escalation,question --json — 완료 이벤트 대기
gate-create --task <id> --question "..." --options '["yes","no"]' --json — 사람 검토 노드

승인되면 종료, 반려되면 오케스트레이터가 피드백을 담아 앞 노드를 다시 태워요. 검토 결과에 따라 이전 단계로 회귀할 수 있다는 게 선형 파이프라인과 갈라지는 지점이에요. 터미널을 직접 다뤄야 할 때는 orca terminal send/read/wait가 있고, --for tui-idle --timeout-ms 300000 같은 조건 대기도 붙일 수 있어요.

폴링을 없앤 worker_done 계약

worker_done 계약은 워커가 완료 신호를 정확히 1회만 보내도록 못 박은 프로토콜이에요. 멀티 에이전트를 직접 굴려본 사람이라면 “워커가 끝났는지 어떻게 아느냐”가 제일 지저분한 부분이라는 걸 알 거예요. 출력 문자열을 정규식으로 훑거나, 파일 생성 여부를 감시하거나, 타임아웃을 거는 식으로 때우게 되죠.

오르카는 그 지점을 규격으로 굳혔어요. 워커는 worker_done을 정확히 1회만 보내고, --outcome succeeded|failed를 함께 담아요. 오케스트레이터 쪽은 check --wait로 이벤트를 기다리고요. 정확히 1회라는 제약이 중복 전송으로 인한 이중 진행을 막아줘요. 개념적 우아함보다 실무 가치는 여기에 있어요.

스킬 구조도 비슷한 결이에요. SKILL.md에 전체 가이드를 박아두지 않고, 에이전트가 실행 시점에 orca skills get으로 앱 버전과 맞는 가이드를 불러오는 하이브리드 스텁 방식이에요. 문서는 그 목적을 플래그 드리프트(flag drift) 방지로 설명해요. CLI 문법을 프롬프트에 하드코딩해두면 앱이 업데이트될 때마다 에이전트가 없는 플래그를 호출하고, 그 실패를 자기 실수로 오해해 엉뚱한 재시도를 반복하거든요.

병렬 3개는 쿼터 3배

병렬 처리의 비용은 노드 수에 정비례해요. 그래프 엔지니어링 담론이 잘 말하지 않는 부분이죠. 노드를 늘리면 처리량은 늘지만 토큰 소비도 노드 수만큼 늘어나요. 리뷰 실측 기준으로 에이전트 3개 병렬은 앤트로픽 쿼터 3배 소모예요. “병렬로 5개 돌리세요”는 곧 “구독 한도를 5배 속도로 태우세요”라는 뜻이기도 해요.

설치 용량 — DMG 약 250MB
메모리 — 에이전트 몇 개 구동 시 유휴 RAM 400~800MB (일렉트론 기반)
리눅스 — AppImage만 제공, .deb/.rpm/Snap/Flatpak 없음
SSH 원격 worktree — 원격 머신에도 오르카 설치 필요
모바일 컴패니언 — 데스크톱 세션이 살아 있어야 동작
릴리스 — 매일 배포, 버그도 함께 나가고 수정은 보통 24시간 내

유휴 RAM 400~800MB는 브라우저 탭 대여섯 개 정도라 요즘 개발 머신에서는 큰 부담이 아니에요. 실질적인 진입 장벽은 메모리보다 에이전트 구독 비용 쪽이에요. 하나 더, 오르카 터미널 안에서 코딩 에이전트 세션을 돌리는 중이라면 앱 재시작이 곧 그 대화의 종료예요. 긴 작업 중에는 업데이트 타이밍을 잡아두는 편이 안전해요.

랭그래프와 겹치는가

랭그래프와 오르카는 겹치지 않아요. 다루는 층위가 다르거든요. 검색 독자가 이어서 던지는 질문일 텐데, 표로 정리하면 이렇게 갈려요.

구분	랭그래프 계열 (LangGraph·AutoGen GraphFlow·Google ADK)	오르카 오케스트레이션
층위	라이브러리, 코드 안에서 그래프 정의	앱/CLI, 에이전트 프로세스 자체가 노드
노드의 실체	함수 호출 또는 LLM 호출	독립 터미널에서 도는 CLI 에이전트
격리 단위	애플리케이션 상태 변수	git worktree + 전용 터미널
주 사용자	에이전트 제품을 만드는 개발자	코딩 작업을 병렬로 돌리려는 개발자

체이스의 “그냥 랭그래프 아닌가”라는 반문은 라이브러리 층에서는 타당해요. 랭체인 블로그(2026년 7월 22일)에서도 그래프 엔지니어링이 “실제 설계 난제를 가리키기에 등장한 용어”라고 부분적으로 수용했고요. 다만 오르카가 다루는 건 에이전트 프로세스 오케스트레이션이라 대상이 달라요. 같은 개념어를 쓴다고 같은 문제를 푸는 건 아니에요.

지금 써서 이득 보는 사람

지금 오르카로 실익이 가장 큰 쪽은 코딩 에이전트를 매일 쓰는 개발자예요. 사용자 유형별로 나누면 이렇게 갈려요.

AI 입문자 — 오케스트레이션은 나중이에요. 먼저 첫 세션 6단계(레포 추가 → worktree 생성 → 에이전트 선택 → 3개 병렬 → 분할 화면 → diff 비교 후 커밋)로 병렬 감각부터 익히는 순서가 편해요.
코딩 에이전트를 매일 쓰는 사람 — 실익이 가장 커요. check --wait 기반 이벤트 대기만으로도 터미널 들여다보는 수작업이 사라져요.
팀·기업 — MIT 라이선스는 유리하지만 오케스트레이션이 Experimental 상태라는 점은 불리해요. 릴리스 파이프라인 같은 크리티컬 경로보다는 개발자 개인 도구로 먼저 들이는 편이 안전해요.
비개발 사용자 — CLI 중심이라 현재로선 맞지 않아요.

용어는 새것, 구현은 3년 전부터

그래프 엔지니어링은 새 기술이 아니라 기존 기술에 붙은 새 이름이에요. 2026년 7월 18일에 등장한 3주짜리 용어에 랭그래프를 비롯한 기존 구현체 여러 개가 이미 붙어 있다는 사실이 그 근거예요. 그렇다고 무의미하지는 않아요. 이름이 붙어야 비교가 되고, 비교가 돼야 “우리 워크플로는 어느 층위에서 실패하고 있는가”를 물을 수 있으니까요.

앞으로 갈릴 지점은 담론이 아니라 격리와 비용이에요. 노드를 늘리는 건 명령 한 줄이지만, 노드끼리 파일을 밟지 않게 만드는 일과 늘어난 토큰을 감당하는 일은 여전히 사람 몫이에요. 오르카가 git worktree를 노드 경계로 삼은 선택이 오래 살아남을지, 오케스트레이션이 Experimental 딱지를 언제 뗄지가 다음 관전 포인트예요. 지금 당장은 개인 개발 환경에서 병렬 감각을 익혀두는 정도로 시작하면 충분해요.

핵심 정리

그래프 엔지니어링은 특화 에이전트를 노드로, 라우팅을 엣지로, 공유 상태를 엣지 위 흐름으로 두는 설계예요. 2026년 7월 18일 피터 스타인버거의 X 발언에서 퍼졌고, 7월 20일 해리슨 체이스가 “그냥 랭그래프 아닌가”라고 반박했어요.
그래프는 루프를 대체하지 않아요. 모든 노드는 여전히 루프이고, 그래프는 노드 바깥의 흐름을 따로 관리하는 층이에요.
오르카는 20~30종 CLI 에이전트를 붙일 수 있는 데스크톱 ADE예요. 작업 1개 = git worktree 1개라는 OS 수준 격리가 라이브러리 계열과 갈라지는 핵심 지점이에요.
개발사는 스테이블리 AI(YC W22, 4인, 샌프란시스코), 라이선스는 MIT, 레포는 stablyai/orca, 2026년 8월 9일 기준 스타 약 40,500개·main 커밋 8,202개예요.
프리미티브는 Run·Task·Dispatch·Message·Decision gate 5종이고, Task 상태 6종 중 pending/ready 분리가 DAG 실행의 최소 요건이에요.
오케스트레이션은 Settings → Experimental에서 켜는 실험 기능, 스킬 설치는 orca skills install --all(조회는 get, 설치는 install)이에요.
비용은 노드 수에 비례해요. 에이전트 3개 병렬 = 앤트로픽 쿼터 3배 소모, 유휴 RAM 400~800MB, DMG 약 250MB, 릴리스는 매일·수정은 보통 24시간 내예요.

참고 출처

오르카 오케스트레이션 공식 문서: https://www.onorca.dev/docs/cli/orchestration
오르카 스킬 문서: https://www.onorca.dev/docs/cli/skills
GitHub stablyai/orca (MIT 라이선스·스타 수): https://github.com/stablyai/orca
Y Combinator — Stably AI (Orca): https://www.ycombinator.com/companies/stably-ai-orca
LangChain 블로그 (Harrison Chase): https://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph
andrew.ooo 오르카 리뷰 (자원·비용 실측): https://andrew.ooo/posts/orca-stablyai-parallel-coding-agents-ide-review/

랭체인 CEO가 “그냥 랭그래프 아닌가”라던 그래프 엔지니어링, 오르카로 돌려봤어요