한 줄로 — 그래프 엔지니어링은 AI가 알아서 해주는 신기술이 아니라,
큰 작업을 어떻게 나누고 어디서 경계를 그을지 정하는 설계의 이름이다.

• 하네스·루프·그래프는 서로를 대체하는 게 아니라 겹쳐 있는 층이다.
• 나누기만 하고 공유할 기준을 못 박지 않으면 합칠 때 어긋난다 (직접 겪은 사례).
• Bun의 Rust 재작성은 가능성을 보여줬지만 사람의 검토를 대신하지 못했다.
• 한계는 사라진 게 아니라 토큰 비용과 검토 책임으로 옮겨갔다.

하네스를 겨우 이해했더니, 이번에는 그래프라는게 나왔네....

요즘 AI 개발 흐름을 따라가다 보면 정신이 없다. 얼마 전까지는 모델보다 하네스가 중요하다고 했다. AI가 파일을 읽고 코드를 수정하고 터미널을 실행할 수 있도록 만든 작업 환경을 말한다. 하네스를 겨우 이해했더니 이번에는 프롬프트보다 루프를 설계해야 한다고 했다. AI에게 한 번 작업을 시키고 끝내는 것이 아니라, 테스트가 통과할 때까지 수정과 검증을 반복하게 만드는 방식이다.

그런데 루프를 따라가기도 전에 이번에는 그래프 엔지니어링이라는 말이 등장했다. 처음에는 또 새로운 개념을 공부해야 하나 싶었다. 하지만 알아보니 하네스와 루프, 그래프는 앞의 기술이 사라지고 다음 기술이 등장하는 관계가 아니다.

이 글에서는 세 개념을 다음처럼 구분해 보려고 한다.

• 하네스는 AI가 실제로 일할 수 있는 자율성과 제어를 설계한다.
• 루프는 완료 조건을 만족할 때까지 작업을 반복하는 방식이다.
• 그래프는 여러 작업의 순서와 관계를 연결하는 방식이다.

하네스라는 작업장 안에서 루프가 돌고, 여러 작업이 그래프로 연결될 수 있다. 그래프의 한 단계 안에서 다시 루프가 돌 수도 있다.

그래프가 곧 여러 AI를 동시에 사용한다는 뜻도 아니다. 하나의 에이전트가 정해진 순서대로 작업하는 그래프도 만들 수 있다. 다만 서로 독립적인 작업을 여러 에이전트에게 나눠 처리할 수 있기 때문에 그래프와 멀티에이전트가 자주 함께 언급된다.

Anthropic의 멀티에이전트 연구 시스템도 하나의 리드 에이전트가 작업을 나누고, 여러 서브에이전트가 병렬로 조사한 뒤 결과를 다시 합치는 구조를 사용한다.

알고 보니 이미 하던 행동이었다

그래프 엔지니어링을 알아보면서 가장 먼저 든 생각은 이것이었다.

이게 정말 완전히 새로운 방식일까?

AI를 자주 사용하는 사람들은 이미 비슷하게 일하고 있었다. 큰 작업을 한 번에 맡기지 않고 조사와 구현을 나눈다.

1. 프론트엔드와 백엔드를 따로 작업시킨다.
2. 결과가 나오면 다른 AI에게 검토를 맡기고, 문제가 있으면 다시 수정시킨다.

즉, 그래프 엔지니어링이 완전히 새로운 행동이라기보다, 사람들이 이미 하던 작업 분할과 재검토 방식을 더 분명한 실행 구조로 만든 것에 가까웠다. 작업의 순서와 분기를 정하고, 동시에 처리할 부분을 나누고, 실패하면 앞 단계로 돌아가도록 만드는 것이다. 그렇게 생각하니 새로운 단어가 나왔다고 해서 피로감을 느낄 이유는 없었다. 중요한 것은 그래프라는 이름이 아니었다.

큰 작업을 AI에게 통째로 던지지 않고, 수행할 수 있는 단위로 나누는 것. 그리고 그 작업들이 어떤 순서와 관계로 이어지는지 정하는 것.

결국 핵심은 설계였다.

작업을 나누는 것보다 경계를 정하는 일이 먼저다

이걸 몸으로 배운 적이 있다.

나는 게임 만드는 사람들이 모여 팀을 꾸리고 자기 게임을 알리는 디벨 게임즈라는 커뮤니티를 만들고 있다. 여기에는 성격이 다른 두 종류의 글이 올라온다. 하나는 질문이나 후기 같은 일반 게시글이다. 제목과 본문이 있고 댓글과 좋아요가 달리면 그만이다. 다른 하나는 자기 게임을 올리는 프로젝트 글이다. 이쪽에는 팀원 목록, 장르, 진행 단계, 지원 플랫폼, 다운로드 수 같은 성과 지표, 패치노트가 줄줄이 붙는다. 팀원을 모집하고 지원을 받는 창구이기도 하다. 글이라기보다 사실상 하나의 페이지에 가깝다.

그래서 게시판도 일반 게시판과 프로젝트형 게시판으로 나눠 두었다. 문제는 화면만 나누고 데이터는 나누지 않았다는 것이다. 어차피 둘 다 '글'이라고 생각해서 게시글 테이블 하나에 전부 넣고, type 값으로 일반 글인지 프로젝트인지만 구분했다. 처음에는 간단해 보였지만 프로젝트에만 필요한 컬럼이 스무 개 넘게 붙고, 코드 여기저기에 type을 확인하는 분기가 서른여섯 개 파일로 퍼지면서 감당이 안 되기 시작했다. 결국 프로젝트를 독립된 테이블로 떼어내기로 했다.

이 작업을 AI에게 한 문장으로 맡길 수도 있었다.

프로젝트를 별도 테이블로 분리해 줘.

하지만 그러기엔 범위가 너무 컸다. 그래서 계획서를 먼저 쓰고 단계로 쪼갰다.

기존 구조는 건드리지 않고 새 테이블만 추가
→ 조회 유틸을 새 테이블 기준으로 전환
→ 하위 테이블을 새 기준 id로 전환
→ 프로젝트 전용 API 경로 분리
→ 프론트엔드 경로 보완

돌아보면 이건 이미 그래프였다. 순서가 있고, 앞 단계가 끝나야 다음 단계로 넘어가고, 실패하면 되돌아왔다. 각 단계는 계획대로 끝났고 타입 검사와 빌드도 전부 통과했다.

그런데 실제로 화면을 열어보니 문제가 줄줄이 나왔다. 통합 피드에서 프로젝트 글이 제대로 보이지 않았다. 태그 화면의 '더 보기'를 누르면 프로젝트 글만 빠졌다. 카테고리에 표시되는 글 개수가 실제와 맞지 않았다. 어떤 화면은 옛날 주소로, 어떤 화면은 새 주소로 링크를 걸고 있었다. 분리 작업 이후에 이런 문제를 수습하는 커밋만 네 개를 더 쌓아야 했다.

원인을 따라가 보니 하나였다. 무엇을 프로젝트로 볼 것인지를 단계마다 다르게 잡고 있었다. 어떤 코드는 아직 기존 테이블에서 type이 프로젝트인 글을 찾고 있었고, 어떤 코드는 새 테이블만 보고 있었다. 개수를 세는 쪽은 새 테이블만 합산하느라 기존 테이블에 남아 있던 이벤트나 질문 글을 빠뜨렸다.

작업은 분명히 나눴다. 그런데 나눠진 작업들이 공유해야 할 기준을 먼저 못 박지 않았다. 그래서 각 단계는 정상적으로 끝났는데 합쳐 놓으니 화면이 어긋났다.

여기서 중요한 것은 프론트엔드와 백엔드 구현은 나눌 수 있지만, 두 작업이 공유하는 API 구조와 데이터 형식은 먼저 맞춰야 한다. 즉, 서로 독립적인 부분은 나누고, 강하게 연결된 부분은 같은 기준을 공유하게 만들어야 한다.

이처럼, AI에게 큰 작업을 맡길 수 있다는 것과 큰 작업을 통째로 맡겨도 된다는 것은 다르다.
반대로 작업을 나눌 수 있다는 것과 무조건 나눠야 한다는 것도 다르다.

Bun 사례가 보여준 가능성

그렇다면 이런 구조로 실제로 얼마나 큰 작업까지 처리할 수 있을까. 대표적인 사례가 Bun의 핵심 코드를 Zig에서 Rust로 옮긴 작업이다.

Bun은 JavaScript와 TypeScript 런타임이다. Bun 창립자 Jarred Sumner는 Claude Code의 동적 워크플로를 이용해 약 50개의 워크플로를 11일 동안 실행하며 코드 이전을 진행했다고 밝혔다. 각 워크플로는 코드 변환, 컴파일 오류 수정, 명령어 복구, 테스트 통과, 리팩터링 같은 작업을 반복했다. 최고점에는 4개의 워크플로가 동시에 실행됐고, 각 워크플로마다 16개의 Claude가 움직였다. 약 64개의 에이전트가 동시에 작업한 셈이다.

Bun 측 발표에 따르면 최종적으로 6개 플랫폼에서 전체 테스트가 통과했고, 건너뛰거나 삭제한 테스트는 없었다. 새 버전은 이전 버전에서 재현되던 버그 128개를 수정했다. 메모리 누수와 충돌부터 도움말 색상이 잘못 표시되는 문제까지 포함됐다. 바이너리 크기도 Linux와 Windows에서 약 20% 줄었다. 다만 이 결과는 Rust 전환만으로 나온 것이 아니라 ICU 데이터 정리와 링커 최적화가 함께 반영된 결과다.

결과만 보면 대단하다. 하지만 이 사례는 AI가 갑자기 더 똑똑해졌다는 뜻이라기보다, 작업을 잘게 나누고 여러 번 검토하고 실패한 부분을 다시 수정하도록 만든 결과에 가깝다. 실제로 Bun 작업에서는 코드가 커밋되기 전에 별도의 에이전트들이 적대적 검토를 진행하고, 다시 수정하는 절차가 포함됐다. Jarred Sumner도 대부분의 기간 동안 워크플로 결과를 직접 확인하고 문제가 있을 때 반복 구조를 수정했다고 설명한다.

그러다 한 가지 의문이 들었다.

그렇게 빠르게 만들어진 코드를 사람은 얼마나 읽었을까?

테스트를 통과했다고 모든 검토가 끝난 것은 아니다

자동 검사는 자신이 보도록 만들어진 항목만 확인한다. 테스트가 통과했는지, 빌드가 성공했는지, 응답 속도가 기준에 들어오는지는 검사할 수 있다. 하지만 코드가 장기적으로 읽기 좋은지, 위험한 우회 방식이 과도하게 들어갔는지, 유지보수 비용이 얼마나 커졌는지는 저절로 알려주지 않는다.

Bun 측은 Rust 코드의 약 4%가 unsafe 블록 안에 있으며, 약 13,000개의 unsafe 키워드가 있다고 밝혔다. 동시에 이 가운데 상당수는 C++ 포인터나 C 라이브러리 호출처럼 외부 코드와 연결하기 위한 짧은 구간이라고 설명했다.

Rust 공식 문서에서도 unsafe는 곧 버그라는 뜻이 아니다. Rust의 일반적인 안전 검사를 컴파일러가 보장할 수 없는 영역에서, 개발자가 직접 조건을 지켜야 한다는 뜻이다. C 같은 외부 언어의 함수를 호출할 때도 정상적으로 사용된다. 다만 unsafe가 필요할 수 있다는 사실과, 테스트가 통과했으니 안전성 검토까지 끝났다는 주장은 전혀 다른 이야기다. 자동 테스트가 보지 않는 부분은 여전히 남아 있다.

Anthropic도 장기 실행 코딩 에이전트 실험에서 비슷한 문제를 확인했다. Claude가 단위 테스트나 curl 테스트는 수행했지만, 실제 사용자가 쓰는 전체 흐름이 작동하지 않는 경우가 있었다. 브라우저 자동화 도구를 이용해 사람처럼 처음부터 끝까지 테스트하도록 명시했을 때 검증이 개선됐다.

앞서 말한 테이블 분리 작업이 정확히 그랬다. 단계마다 타입 검사와 빌드는 전부 통과했지만, 정작 화면을 열었을 때 목록에서 글이 빠지고 개수가 어긋났다. 각 부분의 검사가 모두 통과해도 실제 사용자 흐름은 실패할 수 있다.

그래서 이 내용을 알아보며 결국 이렇게 정리하게 됐다.

검사하지 않은 항목은 통과한 것이 아니다. 아무도 확인하지 않은 것이다.

에이전트가 늘어나면 비용과 통제 문제도 커진다

에이전트를 늘리면 생산량만 늘어나는 것이 아니다.
각 에이전트가 읽어야 할 맥락과 서로 맞춰야 할 결과도 함께 늘어난다.

Bun의 Rust 이전 작업은 병합 전까지 59억 개의 비캐시 입력 토큰, 6억 9,000만 개의 출력 토큰, 720억 개의 캐시 입력 토큰 읽기를 사용했다. Bun 측은 이를 당시 API 가격으로 환산하면 약 16만 5,000달러라고 밝혔다. 이는 실제 청구 금액을 공개한 것이 아니라 API 가격 기준 환산값이다.

Anthropic의 멀티에이전트 연구 시스템에서도 일반적인 채팅보다 약 15배 많은 토큰이 사용됐다. 모든 그래프가 정확히 같은 비율로 비용이 늘어난다는 뜻은 아니다. 다만 에이전트와 검증 단계를 늘릴수록 비용이 커질 수 있다는 방향은 분명하다.

통제도 문제다. 에이전트가 많다고 해서 결과가 자연스럽게 하나로 합쳐지는 것은 아니다. 나는 혼자서 순서대로 진행한 작업에서도 단계마다 기준이 어긋났다. 여러 에이전트가 동시에 움직이면 한쪽은 기존 구조를 유지한다고 생각하고 다른 쪽은 새 구조로 바꾼다고 판단하기가 훨씬 쉬워진다.

Anthropic 역시 모든 에이전트가 같은 맥락을 공유해야 하거나 작업 간 의존성이 많은 분야는 멀티에이전트에 적합하지 않을 수 있다고 설명한다. 특히 연구보다 코딩 작업은 실제로 병렬화할 수 있는 부분이 적다고 지적한다. 현재의 에이전트는 다른 에이전트에게 실시간으로 일을 위임하고 조율하는 능력에도 한계가 있다.

그래프는 일을 나눠 주는 방식인 동시에, 나눠진 일을 다시 하나로 묶는 방식이기도 하다. 작업의 경계와 공통 규칙을 제대로 정하지 않으면 에이전트 수만 늘고 마지막 통합이 더 어려워질 수 있다.

AI 개발의 한계는 사라진 것이 아니라 이동했다

그래프 엔지니어링을 처음 봤을 때는 AI가 처리할 수 있는 작업의 한계가 거의 사라지는 것처럼 느껴졌다. 하나의 에이전트가 감당하기 어려운 작업도 여러 단계로 나누고 여러 에이전트에게 맡기면 처리할 수 있기 때문이다.

하지만 한계가 사라진 것은 아니다. 예전에는 AI에게 얼마나 큰 작업을 시킬 수 있는지가 한계였다. 그래프와 멀티에이전트 구조는 그 한계를 넓혔다. 대신 새로운 한계가 생겼다고 생각한다. 얼마나 많은 토큰과 비용을 사용할 것인가. 그리고 쏟아져 나온 결과를 누가 읽고 검토하며 책임질 것인가.

Bun 사례에서도 AI가 만든 코드는 자동 테스트와 에이전트 검토만으로 끝나지 않았다. 사람이 워크플로를 지켜보고, 테스트가 실제로 실행되는지 직접 확인하고, 병합 이후에도 보안 검토와 퍼징을 계속했다.

AI 에이전트는 여러 개로 늘릴 수 있다. 하지만 사람의 눈과 시간은 같은 속도로 늘어나지 않는다.

그래프 엔지니어링은 AI가 알아서 복잡한 문제를 해결해 주는 "딸깍"이라기보다,
복잡한 일을 AI가 처리할 수 있도록 사람이 작업을 나누고 연결하고 검사하는 방식에 가까웠다.

참고 자료

1. Anthropic, 「How we built our multi-agent research system」 리드 에이전트가 작업을 나누고 여러 서브에이전트가 병렬로 조사한 뒤 결과를 합치는 구조를 설명한다. 멀티에이전트 시스템의 토큰 사용량과 병렬 작업에 적합한 업무의 조건도 확인할 수 있다.
2. Anthropic, 「Effective harnesses for long-running agents」 장기 실행 코딩 에이전트가 실제 사용자 흐름을 충분히 확인하지 않고 작업을 완료했다고 판단하는 문제를 다룬다. 단위 테스트뿐 아니라 브라우저를 이용한 전체 흐름 검증이 필요한 이유를 설명한다.
3. Bun, 「Rewriting Bun in Rust」 Bun의 핵심 코드를 Zig에서 Rust로 이전한 공식 기록이다. 작업 기간, 워크플로와 에이전트 수, 테스트 결과, 수정된 버그 수, 바이너리 크기 변화, 토큰 사용량과 비용 환산 등을 확인할 수 있다.
4. Bun, 「Bun’s Unsafe Rust Audit」 Bun의 Rust 코드에 사용된 unsafe 영역을 분석한 감사 자료다. unsafe 사용 현황과 안전한 코드로 바꿀 수 있다고 판단된 부분, 별도 검토가 필요한 함수 등을 확인할 수 있다.
5. Rust 공식 문서, 「Unsafe Rust」 unsafe가 곧 버그를 뜻하는 것은 아니며, 컴파일러가 보장하지 못하는 조건을 개발자가 직접 책임져야 하는 영역이라는 점을 설명한다. 외부 언어의 함수 호출 등 unsafe가 필요한 사례도 소개한다.