"Graph engineering isn't a new idea. It's the latest name for a well established approach to building reliable agents."
(그래프 엔지니어링은 새 아이디어가 아니다. 믿을 만한 에이전트를 만드는, 이미 자리 잡은 방식에 붙은 가장 최근의 이름일 뿐이다.) — LangChain
같은 글에서 LangGraph를 "3년 전부터 만들어 왔다"고 적었고, 지금 월 6,500만 회 이상 내려받힌다고 밝혔다.
공개된 패키지 기록으로는 2024년 1월이 첫 자취다. 대략 2년 반 전이다. 어느 쪽으로 세든, 이번 유행보다 한참 앞선다.
고정 API 호출·단일 모델 호출·풀 에이전트가 한 그래프 안에 섞인 예. 출처: LangChain — 3 Years of Graph Engineering with LangGraph
그런데 개발자들은 별 반응이 없었다
X 타임라인은 뜨거웠는데, 개발자 커뮤니티는 조용했다. 확인하려고 Hacker News 검색 API를 돌려 봤다.
"graph engineering"이라는 정확한 문구로 걸리는 글은 단 네 건이다.
그중 둘은 2019년·2023년의 무관한 논문이고, 이번 유행에 해당하는 건 두 건뿐이다.
날짜
제목
점수
댓글
7월 21일
Loop Engineering, Graph Engineering, and Layers That Matters
5점
0개
7월 19일
We are entering the graph engineering phase
2점
0개
두 건 합쳐 7점이고, 둘 다 댓글이 0개다. 차이는 점수보다 댓글 수에 있다. 5점에 댓글 20개면 의견이 갈렸다는 뜻이지만, 5점에 댓글 0개는 거의 안 읽혔다는 뜻이다. 게다가 2점짜리는 글쓴이가 자기 글을 직접 올린 것이었다.
비교해 보면 차이가 뚜렷하다.
같은 곳에서 "loop engineering"으로 검색하면 45건이 나온다. 그중 하나는 37점에 댓글 10개가 달렸다.
그래프 엔지니어링은 X에서 유행했지, 개발자 커뮤니티에서 유행한 게 아니다.
소셜에서 본 열기와 실제 논의량이 이 정도로 어긋나는 경우도 드물다.
2. 먼저 걷어낼 것 — 떠도는 가짜 수치
본론에 들어가기 전에 숫자부터 걸러 보자.
확인해 보니 사실이 아닌 것들
"그래프 엔지니어링 도입으로 정확도 18% 향상, 비용 85% 절감" — 두 숫자는 진짜다. 다만 출처가 화학 공정 배관 도면(P&ID)을 다룬 2026년 3월 논문이다. 게다가 둘은 비교 대상이 서로 다르다 — 18%는 이미지 원본과 비교한 값이고, 85%는 도면 파일을 통째로 넣는 방식과 비교한 값이다. 유행하는 문장은 이 둘을 하나의 도입 전후처럼 붙여 놨다. 그 논문에는 "graph engineering"이라는 말이 아예 나오지 않는다.
"스탠퍼드·Anthropic 310만 달러 공동 연구" — 확인되지 않는다.
"마이크로소프트가 RAG를 그래프로 교체했다" — GraphRAG 이야기인데 두 군데가 틀렸다. 마이크로소프트 스스로 GraphRAG를 "모듈형 그래프 기반 RAG 시스템"이라고 설명한다. RAG의 한 종류지 대체가 아니다. 게다가 2024년 2월에 발표된 것이라, 이번 유행보다 2년 넘게 앞선다.
"스탠퍼드가 그래프 엔지니어링을 채택했다" — 스탠퍼드의 DSPy는 지식 그래프 시스템이 아니다.
"Anthropic이 그래프 엔지니어링 서비스를 출시했다" — Anthropic이 그런 이름의 제품이나 분야를 발표한 적은 없다.
3. 루프도 이미 그래프다 — 세대 교체가 아니다
"루프 엔지니어링은 죽었다"는 말은 좀 어색하다. 이유는 단순하다.
"A loop is already a graph. It is simply a graph whose path returns to an earlier node."
(루프는 이미 그래프다. 경로가 앞선 노드로 되돌아가는 그래프일 뿐이다.) — Turingpost
지난 글에서 그린 파이프라인을 다시 보자.
Planner에서 Critic까지 상자가 늘어서 있고, 통과하지 못하면 Writer로 되돌아간다.
이건 형식적으로 이미 그래프다. 노드가 있고 엣지가 있으니까.
그래서 "여기까지는 루프고, 여기부터는 그래프"라고 가를 수 없다. 루프가 그래프의 한 종류이기 때문이다.
만들고 평가하는 쪽이 한 바퀴 도는 구조. 경로가 앞 노드로 돌아오는 그래프(=루프)의 공식 그림. 출처: Anthropic — https://www.anthropic.com/engineering/building-effective-agents
루프로 보면
완료 조건까지 반복한다. 경로가 앞 노드로 돌아올 뿐이다.
VS
그래프로 보면
노드·엣지·갈래·합류. 루프는 그 안의 한 종류다.
세대 교체가 아니다 — 루프 ⊂ 그래프
그럼 하네스·루프·그래프는 서로 무슨 사이일까.
앞 기술이 사라지고 다음 기술이 등장하는 발전 단계가 아니다. 겹쳐 있는 개념이다.
이름
정체
비유
하네스
AI가 실제로 일할 수 있게 만든 환경. 파일을 읽고 고치는 도구, 터미널, 기억, 권한과 안전 규칙. Claude Code·Codex가 여기 해당한다.
작업장
루프
그 작업장 안에서 완료 조건을 걸어두고 반복시키는 방식. "테스트 12개가 다 통과할 때까지 고쳐라."
건조기
그래프
작업이 흘러가는 관계를 미리 지도처럼 그려둔 것. A가 끝나면 B와 C로 갈리고, 둘 다 끝나면 D에서 합친다.
지도
핵심은 셋이 겹친다는 점이다.
하네스라는 작업장 안에서 루프도 돌고, 그래프도 돈다. 그래프 안에 루프가 들어가기도 한다.
그래프라고 해서 여러 AI를 동시에 돌린다는 뜻도 아니다 — 에이전트 하나만 움직이는 그래프도 있고, 순서대로만 실행되는 그래프도 있다.
4. 그래도 남는 것 — 언제 그래프가 필요해지나
그래프 엔지니어링 안에도 충분히 건져갈 인사이트가 있다.
핵심 질문 하나는 이거다. 내 작업 단계가 언제부터 머릿속으로 안 그려지나?
여기서 말하는 상자(노드)는 거창한 게 아니다. 일을 하는 단계 하나이다.
초안 쓰기, 테스트 돌리기, 사람 승인 받기 — 각각이 한 단계다.
단계가 세 개면 머릿속으로 따라간다.
다섯 개도 괜찮다. 그런데 열 개가 되면 "실패하면 어디로 가지?"가 헷갈리기 시작한다.
그때 그래프가 필요해진다.
단계가 늘어나는 이유는 보통 아래 세 가지다.
■■■
단계 3개
머릿속으로 OK
■■■■■
단계 5개
아직 괜찮다
■■■■■■■■■■
단계 10개
못 따라감 → 지도(그래프) 필요
① 실패 원인이 여러 개일 때
루프에서는 뭔가 실패하면 보통 이전 단계로 되돌아간다.
그런데 실제 실무에서 실패는 한 종류, 단 한가지의 케이스 가 아니다.
테스트가 깨지고, 스펙이 모호하거나, 외부 서버가 죽은 것 등등 다양할 것 이다.
이런 것들을 구분하지 않고 전부 "이전 단계로 돌아가 다시 해봐"로 처리하면 루프가 이상해진다.
서버가 죽었는데?? 코드를 다섯 번 고치는 그런식이다.
원인마다 처리 방식이 달라야 한다.
그래서 "실패 종류 분류" 단계가 하나 생기고, 갈래마다 단계가 또 생긴다. 그래서 단계가 하나씩 더 붙는다.
실패·입력 종류를 나눈 뒤 경로를 가르는 Routing. ① "실패 원인이 여러 개일 때"와 같은 그림. 출처: Anthropic — https://www.anthropic.com/engineering/building-effective-agents
② 일을 나눠 동시에 돌릴 수 있을 때
파일 다섯 개를 순서대로 고치면 느리다.
서로 안 얽혀 있다면 동시에 일을 시키고 마지막에 하나로 합치면 된다.
이때 "여러 갈래로 펼치는 단계(팬아웃)"와 "다시 모으는 단계(팬인)"가 추가된다.
파일 개수만큼 단계가 실행 중에 늘어나기도 한다.
classify → 검색 갈래(fan-out) → synthesize. ② "일을 나눠 동시에 돌릴 수 있을 때"의 공식 예. 출처: LangChain — 3 Years of Graph Engineering with LangGraph
③ 단계 사이에 넘길 기록이 필요할 때
이건 단계를 늘리는 이유라기보다, 단계가 늘면 같이 따라오는 숙제에 가깝다.
단계끼리 데이터를 주고받는데 형식이 제각각이면 읽고 쓰기가 힘들다. 그래서 통일된 형식의 상태 객체(작업일지)를 하나 정해 두고, 모든 단계가 그걸 조금씩 고쳐 다음으로 넘긴다.
이게 있으면 나중에 "계획보다 두 바퀴 더 돈 이유가 뭐였지"를 되짚을 수 있다.
한 번은 테스트 실패, 한 번은 외부 연결이 끊긴 것이었다는 식으로.
늘어난 단계가 전부 AI일 필요는 없다
흔한 오해다. 테스트를 돌리는 단계는 그냥 npm test면 되고, 검색하는 단계는 grep이면 된다. 사람이 승인하는 단계가 끼어도 된다.
오히려 명령어로 끝날 일을 AI 단계로 만들면 손해다.
AI에는 늘 환각 위험이 따라붙는다.
"이 테스트 다 통과하는지 확인해 줘"라고 말로 시키는 것보다, 테스트 명령을 그냥 실행하는 쪽이 정확하다.
5. 루프로는 못 하고 그래프로는 되는 네 가지
"그냥 루프가 복잡해진 것 아닌가?" 어찌 보면 맞는 말이다. 다만 다른 지점이 하나 있다.
모든 절차를 미리 노드와 엣지로 코드에 적어둔다는 것.
Shell 스크립트로 짠 루프는 흐름이 실행 중에만 있다.
그래프는 그 흐름을 파일·코드로 남겨 두고, 돌리기 전에 검사하거나 중간에 이어서 할 수 있다.
그래서 네 가지가 가능해진다.
돌리기 전에 눈으로 검사한다. 그림으로 그려 놓고 막다른 길이나 멈춤 조건 없는 순환을 미리 잡아낸다.
멈췄다가 이어서 한다. 사람 승인이 필요한 지점에서 멈추고, 며칠 뒤 승인하면 그 자리에서 재개한다. 상태를 DB에 저장해 두기 때문이다.
되돌려서 다른 갈래로 다시 해본다. 처음부터가 아니라 갈림길에서부터.
단계를 갈아 끼운다. 쉬운 단계는 작은 모델, 어려운 단계는 큰 모델. 노드마다 모델을 달리 두면 토큰이 절약된다.
Shell로 돌리던 루프는 터미널을 실수로 닫거나 한도에 걸리면 그냥 끊기기 때문에 처음부터 다시 해야 한다.
그래프는 체크포인트가 있어 멈춘 자리부터 잇는다.
그럼 언제 루프에서 그래프로 넘어가야 할까? 답은 이전에 얘기 했었다.
작업 단계가 머릿속으로 안 그려질 때 — 예를 들면 열 개정도 되는 복잡한 단계라던지, "실패하면 어디로 가지?"등등의 루프가 헷갈리기 시작할 때가 아닐까. 이정도로 복잡한 순간이 아니라면 지금 방식으로 충분하다.
참고할 만한 공식 문서는 따로 있다
여기까지 읽고 "그래서 뭘 보고 배우나" 싶다면, "graph engineering"으로 검색하지 않는 편이 낫다는 생각이 들었다.
이 글이 정리한 워크플로 패턴 다섯 개가 사실상 그래프 엔지니어링이 말하려던 것이고, 패턴마다 다이어그램이 붙어 있다.
앞 절 ①②③에 그대로 대응되는 얘기인데 그중 두 장만 간단히 설명하고 넘어 가려 한다.
오케스트레이션이 일을 쪼개 워커에게 맡기고 합친다. 표의 Orchestrator-Workers 행. 출처: Anthropic — Building effective agents (The orchestrator-workers workflow)미리 나눈 일을 동시에 돌리고 프로그램이 합친다. 표의 Parallelization 행. 출처: Anthropic — Building effective agents (The parallelization workflow)
공식 패턴 이름
하는 일
이 글의 어디
Routing
입력을 분류해 각각 다른 후속 작업으로 보낸다.
① 실패 원인이 여러 개일 때
Parallelization
여러 LLM이 동시에 일하고 결과를 프로그램이 합친다.
② 일을 나눠 동시에 돌릴 수 있을 때
Evaluator-Optimizer
한쪽이 만들고 다른 쪽이 평가·피드백하는 루프.
만드는 AI와 검사하는 AI 분리
Orchestrator-Workers
중앙 LLM이 일을 쪼개 일꾼에게 맡기고 결과를 종합한다.
Bun의 팬아웃·팬인
Prompt Chaining
한 단계 출력이 다음 단계 입력이 되는 사슬.
순차 그래프(내 하네스)
차이는 이름보다 구조에 있다.
새 이름이 붙기 훨씬 전에 이미 그림까지 그려져 있었다.
같은 글이 워크플로와 에이전트를 갈라 둔 것도 이 글 3절과 같은 이야기다.
"Workflows are systems where LLMs and tools are orchestrated through predefined code paths."
(워크플로는 LLM과 도구가 미리 정해진 코드 경로로 엮인 시스템이다.)
다른 하나는 LangGraph 공식 문서의 Graph API다. 용어 정의가 가장 짧고 분명하다.
상태는 "현재 스냅숏을 나타내는 공유 데이터 구조", 노드는 "현재 상태를 받아 계산하고 갱신된 상태를 돌려주는 함수", 엣지는 "다음에 어느 노드를 실행할지 정하는 함수"다.
같은 문서의 한 줄이 이 개념 전체를 요약한다.
"Nodes do the work, edges tell what to do next."
(노드가 일을 하고, 엣지가 다음에 뭘 할지 알려준다.) — LangGraph 공식 문서
덧붙는 한마디도 새겨둘 만하다. "Nodes and Edges are nothing more than functions." (노드와 엣지는 함수일 뿐이다.)
앞에서 "단계가 전부 AI일 필요는 없다"고 한 게 공식 문서에도 같은 말로 적혀 있다.
그런데 공식 문서가 제일 먼저 하는 말은 "쓰지 마라"에 가깝다
Anthropic의 그 글은 패턴을 늘어놓기 전에 이렇게 못 박는다.
"Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short."
(단순한 프롬프트로 시작하고, 충분한 평가로 다듬어라. 여러 단계짜리 에이전트 시스템은 더 단순한 방법이 한계에 부딪힌 뒤에만 더해라.)
유행을 타고 들어온 사람이 제일 놓치기 쉬운 문장이다. "많은 경우, 검색과 예시를 붙인 단일 LLM 호출 하나면 충분하다"는 말도 같은 글에 있다. 단계를 늘리는 건 마지막 수단이지 출발점이 아니다.
이번엔 같은 걸 그래프 기준으로 다시 본다. 결론부터 말하면 절반은 그래프고, 절반은 아니다.
내 하네스 흐름 (요약)
spec→evidence→draft→qa→final
조건부 루프백은 있음 · 실행 위치 체크포인트는 없음 (세션 한도 → 조용히 끊김)
그래프의 조건
내 하네스
판정
조건부 엣지
있다. 실패 코드마다 갈 곳이 다르다. 근거가 부족하면 Researcher로, 문체가 어색하면 Writer로, HTML이 깨지면 Publisher로.
✅
노드별 모델
있다. 초안을 쓰는 첫 바퀴만 큰 모델을 쓰고, 이후 기계적인 수정은 중간 모델로 내린다.
✅
규격화된 상태
있다. spec.json→evidence.json→draft.md→qa_report.json→final.html이 단계 사이를 흐른다.
✅
멈춤 조건
있다. 루프백은 최대 3회, Critic 라운드는 기본 2회로 잘라 둔다.
✅
코드로 선언
아니다. 흐름이 코드가 아니라 마크다운 문서에 설명문, 매뉴얼 문장으로 적혀 있고, 그걸 오케스트레이터 모델이 읽고 해석한다. 라우팅 표는 있지만 컴파일되지는 않는다.
❌
체크포인트·재개
아니다. 산출물 파일은 남지만 실행 위치는 저장되지 않는다.
❌
팬아웃·팬인
있긴 하지만 리서치 단계만 백그라운드로 병렬을 쓰고, 나머지는 순차 동작이다.
⚠
표로 보면 갈래·모델 배치·상태·멈춤 조건은 갖췄고, 코드 선언과 체크포인트는 비었다. 흐름이 문서에 설명문·매뉴얼 문장으로 적혀 있으니 그림으로 그려 검사하는 것도 안 된다.
이 글을 쓰며 내가 사용하던 워크플로우를 까보니 개선하고싶은 부분이 생기는걸 알게 되었다. 체크포인트가 없어서 실제로 손해를 본 것 같다.
재개가 안 되면 생기는 일
격리 모드로 하네스를 돌리면 별도 프로세스에서 비대화형으로 실행된다. 그런데 여기서 세션 한도에 걸리면 사람에게 묻지도 못하고 최종 결과물 없이 조용히 죽는다. 남는 건 중간 산출물 파일뿐이고, 어디까지 갔는지는 사람이 파일을 열어 눈으로 확인한 뒤 손으로 다시 붙여야 한다.
그래프 엔지니어링이 자랑하는 체크포인트·재개가 정확히 이 문제를 겨냥한다. 이름이 농담이든 아니든, 내 하네스에 실제로 빈 자리가 있다는 건 사실이다.
7. 냉정하게 — 단계를 늘리면 비용이 늘어난다
그래프를 쓴다고 AI가 갑자기 똑똑해지진 않는다.
작업을 나누고, 동시에 돌리고, 결과를 검증해서 성공률을 올리는 쪽에 가깝다.
천재처럼 보일 때까지 여러 번 시킨 셈이다. 그리고 여러 번 시키면 돈이 든다.
나또한 이렇게 글의 퀄리티를 높이기 위해 반복하면서 토큰 소모가 엄청 급증 하게 된다.
리드 에이전트가 서브에이전트를 병렬로 띄우는 구조. 토큰이 채팅 대비 크게 늘어나는 배경. 출처: Anthropic — How we built our multi-agent research system
16
동시 에이전트
워크플로 1개 상한 예시. Bun 피크는 4×16≈64
2
사람 눈
검토와 책임은 여전히 사람 몫
만드는 일은 넘겨도, 읽는 일은 아직이다
가장 큰 실측 사례가 Bun이다. JavaScript·TypeScript 런타임인 Bun은 Claude Code의 동적 워크플로(dynamic workflows)를 써서 핵심 코드를 Zig에서 Rust로 옮겼다.
왜 여기 끌어오냐면, 숫자가 크기 때문이다.
워크플로 하나가 최대 16개 에이전트를 동시에 굴리는데, 최고점에 워크플로 네 개를 겹쳐 돌렸다. 클로드 예순네 개가 동시에 일한 셈이다.
Bun 사례에서 남은 숫자
기간 11일(5월 3일 시작 → 5월 14일 병합), 워크플로 약 50개. 최고점에 워크플로 네 개를 각각 다른 워크트리에서 돌렸고, 워크플로마다 클로드가 16개씩이라 동시에 약 64개가 일했다.
옮기기 전 Zig 코드가 주석 제외 535,496줄이었고, 병합된 변경은 +1,009,272줄이다. 커밋은 6,502개(병합 커밋 제외), 최고점에 분당 약 1,300줄이 나왔다.
병합 전 CI에서 기존 테스트를 전부 통과했다. Bun v1.4.0 기준으로 v1.3.14에서 재현되던 버그 128개를 고쳤다.
토큰은 캐시되지 않은 입력 59억 개, 출력 6억 9천만 개, 캐시된 입력 읽기 720억 개가 들었다. 공개 API 단가로 환산하면 약 16만 5천 달러다.
Rust 코드의 약 4%가 unsafe 블록 안에 있다. 별도 감사 문서가 센 정확한 수는 13,365개다.
마지막 줄을 오해하진 말자.
unsafe가 1만 3천 개라고 버그가 1만 3천 개라는 뜻은 아니다. C나 C++ 라이브러리와 연결할 때는 정상적인 코드에도 unsafe가 필요하다. 실제로 그 블록의 78%는 한 줄짜리다.
이 감사 자체도 Bun이 직접 하고 공개한 것이다.
외부 감시가 잡아낸 게 아니라 스스로 밝힌 쪽에 가깝다. 그 문서는 약 9,300개는 안전한 코드로 바꿀 수 있고 4,000개쯤은 남는다고 적었고, 별개로 안전한 코드에서 부를 수 있는데 위험한 함수 다섯 개를 찾아냈다.
자동 테스트를 통과했다는 것과 안전성 검토가 끝났다는 말은 다르다. 자동 검사는 재기로 한 것만 잰다.
테스트·빌드는 알 수 있어도, 읽기 쉬운지·위험한 우회가 많은지·유지비가 얼마나 늘었는지는 재지 않는다.
검사하지 않은 항목은 통과한 게 아니다. 아무도 보지 않은 것이다.
이 지점에서 실제로 논쟁이 붙었다.
Zig를 만든 Andrew Kelley가 7월 9일에 반박 글을 올렸다. 테스트만으로 충분하다는 주장을 이렇게 되받았다.
"It's not sufficient to catch bugs in Zig code but it is sufficient to catch bugs in 1 million lines of unreviewed slop?"
(Zig 코드의 버그를 잡기엔 부족한 테스트가, 검토 안 된 100만 줄짜리 쓰레기의 버그는 잡기에 충분하다고?) — Andrew Kelley
인용할 때 주의할 게 하나 있다. "unreviewed slop"은 반문 안에 들어 있는 표현이지, "이 작업물은 쓰레기다"라고 단정한 문장이 아니다. 기사 제목들이 이걸 직접 인용처럼 옮겨 놓았는데, 원문 구조는 조금 다른 것 같다.
바이너리가 작아진 것도 Rust 덕분만은 아니다.
Bun 스스로 Rust 재작성과 ICU 데이터 정리, 링커 최적화가 합쳐진 결과라고 적었다.
Kelley는 여기서 한 발 더 나가 "그 엔지니어링 작업은 재작성과 아무 상관이 없다"고 반박했다.
비용 방향도 분명하다.
Anthropic이 자사 멀티에이전트 리서치 시스템을 설명하면서 이렇게 적었다 — "에이전트는 보통 채팅보다 토큰을 약 4배 쓰고, 멀티에이전트 시스템은 채팅보다 약 15배 쓴다."
기준을 헷갈리면 안 된다. 15배는 채팅 대비지 단일 에이전트 대비가 아니다. 그리고 모든 그래프가 정확히 15배라는 뜻도 아니다. 다만 에이전트를 늘리고 서로 검토하게 할수록 비용이 빠르게 커진다는 방향만은 분명하다.
진짜 병목 포인트는 AI 숫자는 병렬로 늘어나는데, 이를 검증하는 사람의 눈은 안 늘어난다. 에이전트가 16대여도 검토하는 눈은 둘이다.
쓸 때 기억할 세 가지
완료 여부를 기계가 분명히 판정할 수 있는 일에만 쓴다. 테스트 통과, 빌드 성공, 파일 형식처럼 기준이 뚜렷해야 한다.
실행 전에, 자동 검사가 보는 것과 보지 않는 것을 나눠 적는다. 앞 목록은 맡겨도 되지만 뒤 목록은 결국 사람이 읽어야 한다.
"쪼갤 수 있는가"보다 "쪼개도 되는 일인가"를 먼저 묻는다. 시장 조사처럼 서로 독립된 일은 나누기 쉽다. 그런데 코드는 얽혀 있다. 로그인 화면을 고치면 DB에 영향이 가고, DB를 바꾸면 결제가 깨질 수 있다.
흔한 함정 네 가지
필요 없는데 단계부터 늘리기. 토큰과 디버깅 시간만 나간다.
명령어로 될 일을 AI 단계로 만들기. 환각 위험을 굳이 사서 넣는 셈이다.
갈래를 만들어 놓고 전부 같은 곳으로 보내기. 그러면 분류한 의미가 없다.
멈춤 조건 없는 순환. 그래프는 눈으로 확인할 수 있으니, 그리고 나서 꼭 훑어본다.
지난 글은 "천장이 사라진 게 아니라 지렛대 받침점이 옮겨갔다"로 끝냈다. 이번에도 비슷한 자리다. 천장은 안 사라졌다. 자리만 옮겼다. 예전 한계는 한 번에 얼마나 큰 일을 시키느냐였다. 지금은 토큰을 얼마나 태울지, 나온 결과를 누가 읽고 책임질지다.
만드는 일은 AI에게 넘길 수 있다. 읽는 일은 아직 사람 몫이다.
8. 자주 묻는 질문
Q. 이름이 농담이면 그냥 무시해도 되나?
이름은 무시해도 된다. 그 뒤에 붙은 문제까지 무시하면 안 된다. 작업 단계가 열 개를 넘어 머릿속으로 못 따라가는 상황은 실제로 생기고, 그때 쓰는 도구도 이미 있다. 용어를 몰랐다고 뒤처진 건 아니지만, 그 문제를 몰랐다면 이야기는 달라진다.
Q. 루프 엔지니어링은 이제 안 배워도 되나?
반대다. 루프가 그래프의 한 종류라, 루프를 건너뛰고 그래프로 갈 수는 없다. 순서는 그대로다. 루프로 해보다가 감당이 안 될 때 그래프로 넘어가면 된다.
Q. 뭘로 시작하면 되나?
LangGraph가 가장 무난하다. 2024년부터 쓰였고 자료가 많다. 노드 함수를 만들고, 상태 객체를 정하고, add_node·add_edge로 이어 붙인 뒤 컴파일하면 된다. 그래프 그림도 자동으로 그려 준다. Claude Code를 쓴다면 동적 워크플로가 비슷한 자리를 맡는다.
그래도 도구보다 개념이 먼저다. Anthropic Building Effective Agents로 패턴 다섯 개를 먼저 보고, 내 문제가 그중 어디에 해당하는지 정한 다음 도구를 고르는 순서를 권한다. 그 글의 조언대로 더 단순한 방법이 한계에 부딪히기 전에는 안 늘리는 쪽이 낫다.
Q. 그래프로 바꾸면 비용이 줄어드나?
방향은 둘 다 있다. 노드마다 작은 모델을 배치하면 줄고, 에이전트 수를 늘리고 서로 검토시키면 는다. 순 효과는 설계에 달렸다. 다만 단계를 늘리는 쪽이 기본값이라, 신경 쓰지 않으면 늘어나는 쪽으로 간다.
마무리 — 이름은 흘려보내고, 점검표만 챙긴다
이번 소동에서 건질 것도 새 프레임워크가 아니다. 질문 몇 개다.
내 파이프라인에 대볼 점검표
실패를 종류별로 나누고 있나? 전부 "다시 해봐"로 돌리고 있다면 갈래를 만들 때다.
멈췄을 때 이어서 할 수 있나? 처음부터 다시 돌리고 있다면 체크포인트가 없는 것이다.
상태가 규격화돼 있나? 단계마다 데이터 모양이 다르면 늘릴수록 힘들어진다.
멈춤 조건이 다 걸려 있나? 한 군데라도 비면 무한히 돈다.
네 개 중 하나만 골라 이번 주에 손봐도 충분하다. 나는 체크포인트부터 볼 생각이다. 앞에서 말했듯, 거기서 실제로 손해를 봤기 때문이다.
다음에 또 새 엔지니어링이 나오면 이번처럼 하면 된다. 이름은 흘려보내고, 내 작업에서도 같은 불편이 있는지만 본다. 없으면 넘기고, 있으면 그때 배운다.
