AI 에이전트의 천장은 검토다 — 하네스·루프·그래프를 한 번에 이해하기
하네스·루프·그래프는 서로를 대체하는 유행어가 아니다. AI가 일하는 환경, 반복하는 방식, 작업의 의존관계를 구분하고 자동화의 새 병목인 검토와 책임을 짚는다.
AI 개발 이야기를 따라가다 보면 공부가 늘 한 박자 늦는 기분이 든다. 모델만 알면 될 것 같았는데 하네스가 중요하다고 하고, 하네스를 이해할 무렵에는 프롬프트보다 루프를 설계하라고 한다. 이제는 그래프 엔지니어링까지 등장했다.
하지만 이 셋은 앞의 기술이 사라지고 다음 기술이 자리를 차지하는 발전 단계가 아니다. 서로 다른 층의 문제를 설명하는 말이다. 영상의 표현을 빌리면, 하네스라는 작업장 안에서 루프가 돌고 그 작업의 관계가 그래프로 그려진다.
세 용어를 같은 선 위에 놓지 않기
- 하네스Harness는 AI가 실제로 일할 수 있게 만든 작업 환경이다. 모델이 머리라면 파일 읽기와 수정, 터미널, 메모리, 권한, 안전 규칙은 손발에 가깝다.
- 루프Loop는 그 환경 안에서 AI가 완료 조건에 도달할 때까지 행동을 반복하는 방식이다. 코드를 고치고, 테스트하고, 실패 원인을 찾아 다시 고치는 흐름이 대표적이다.
- 그래프Graph는 작업 사이의 의존관계를 지도처럼 표현한 것이다. A가 끝난 뒤 B와 C로 갈라지고, 두 결과를 D에서 합치거나 검증 실패 시 앞 단계로 돌아갈 수 있다.
하네스·루프·그래프는 경쟁하는 개념이 아니라 서로 다른 층에서 함께 작동한다.
그래프라고 해서 반드시 여러 AI가 동시에 움직이는 것도 아니다. 한 에이전트가 정해진 순서로 노드를 통과할 수 있고, 그래프의 한 노드 안에서 다시 루프가 돌 수도 있다. 서로 독립적인 작업이 발견될 때만 여러 에이전트가 병렬로 움직이는 편이 유리하다.
이 구분을 알고 나면 유행을 쫓는 부담이 조금 줄어든다. 새로운 이름이 나올 때마다 기존 지식을 버릴 필요가 없다. 어디서 일하는가, 언제까지 반복하는가, 어떤 순서와 관계로 흘러가는가를 각각 묻기만 하면 된다.
그래프는 지능을 높이는 마법이 아니다
영상은 Claude Code의 동적 워크플로와 Bun의 대규모 코드 이전 사례를 소개한다. 여러 워크플로가 작업을 나누고 병렬로 수행한 뒤 테스트를 통과하도록 반복했다는 사례다. 인상적인 부분은 에이전트 수 자체가 아니다. 큰 작업을 더 작은 단위로 쪼개고, 각 결과를 다시 검증할 수 있도록 구조를 만든 점이다.
그래프는 지능을 마법처럼 높이는 장치가 아니다. 작업을 나누고 병렬로 실행하고 결과를 검증해서 성공 확률을 높이는 구조에 가깝다.
AI가 갑자기 더 똑똑해진 것이 아니라, 실패를 발견하고 다시 시도할 기회가 많아진 셈이다. 그래서 그래프의 효과를 “에이전트를 몇 개 썼는가”로만 판단하면 핵심을 놓친다. 작업 경계가 적절했는지, 합치는 지점에서 충돌을 발견할 수 있었는지, 완료 조건이 실제 품질을 대변했는지가 더 중요하다.
테스트 통과는 관찰한 항목의 통과다
대규모 자동화 사례는 동시에 불편한 질문을 남긴다. 그렇게 빠르게 만들어진 코드를 사람은 얼마나 읽었을까.
테스트는 자신이 확인하도록 설계된 것만 본다. 빌드 성공, 응답 시간, 정해진 입출력은 자동으로 판정할 수 있다. 그러나 장기적으로 읽기 좋은 코드인지, 위험한 우회가 숨어 있는지, 유지보수 비용이 커지지는 않았는지까지 저절로 확인해 주지는 않는다.
영상에서 가장 오래 남은 문장은 이것이었다.
검사하지 않는 항목은 통과한 것이 아니다. 아무도 보지 않은 것이다.
자동 검사가 늘어날수록 이 구분은 더 중요해진다. 녹색 체크가 많다는 사실과 제품이 안전하다는 판단은 같은 말이 아니다. 단위 테스트가 모두 통과해도 사용자가 거치는 전체 흐름이 망가질 수 있고, 형식 검사를 통과한 문서가 실제 독자에게는 이해되지 않을 수도 있다.
자동화는 완료 여부를 기계가 명확히 판정할 수 있는 일에서 가장 안정적으로 작동한다.
루프와 그래프를 설계할 때 지킬 세 가지
영상은 복잡한 용어 설명을 세 가지 실무 규칙으로 정리한다.
1. 기계가 완료를 판정할 수 있는가
“잘 만들어라”는 루프의 종료 조건이 될 수 없다. 테스트 통과, 빌드 성공, 필수 필드 존재, 파일 형식 준수처럼 관찰 가능한 조건이 필요하다. 완료 조건이 흐리면 에이전트는 일을 끝낸 것이 아니라 끝났다고 선언하는 법부터 배울 수 있다.
2. 자동 검사가 보는 것과 보지 않는 것을 나누기
실행 전에 두 목록을 적어야 한다. 앞의 목록은 테스트나 검증 스크립트에 맡기고, 뒤의 목록은 사람이 직접 읽는다. 보안 경계, 사용자 경험, 문맥의 자연스러움, 브랜드 톤처럼 정량화하기 어려운 항목은 검토 책임자를 남겨둬야 한다.
3. 쪼갤 수 있는가보다 쪼개도 되는가 묻기
시장 조사처럼 서로 독립적인 작업은 나누기 쉽다. 반면 같은 코드와 맥락을 공유하는 작업은 한쪽의 수정이 다른 쪽을 망가뜨릴 수 있다. 병렬화 가능성보다 맥락을 분리해도 결과의 일관성이 유지되는가를 먼저 봐야 한다.
테스트·린트·빌드로 판정할 부분과 사람이 공유해야 할 맥락을 분리해야 한다.
천장은 사라진 것이 아니라 검토 쪽으로 이동했다
에이전트는 병렬로 늘어날 수 있지만 사람의 눈은 같은 속도로 늘어나지 않는다. 생성 비용도 함께 커진다. 에이전트가 서로 검토하고 고치도록 만들수록 토큰과 실행 시간은 빠르게 불어난다.
예전의 한계가 “AI에게 한 번에 얼마나 큰 일을 시킬 수 있는가”였다면, 이제는 다음 질문이 새 한계가 된다.
- 결과를 만드는 데 얼마의 비용을 쓸 것인가
- 쏟아진 결과를 누가 읽을 것인가
- 자동 검사가 놓친 부분을 누가 책임질 것인가
- 검토 가능한 양보다 생성량이 커졌을 때 어디서 멈출 것인가
만드는 속도가 빨라질수록 결과를 읽고 책임지는 일이 새로운 병목이 된다.
그래서 좋은 에이전트 시스템은 가장 많은 작업을 자동화한 시스템이 아니다. 사람이 반드시 봐야 할 지점을 가장 선명하게 남긴 시스템에 가깝다.
내 일에 적용한다면
루프나 그래프를 만들기 전에 아래 다섯 줄부터 적어보는 편이 낫다.
- 결과물: 무엇을 만들어야 하는가
- 완료 조건: 기계가 무엇을 확인하면 끝났다고 판단할 수 있는가
- 미검사 영역: 자동 검사가 보지 못하는 품질은 무엇인가
- 작업 경계: 독립적으로 나눠도 되는 부분과 같은 맥락을 유지해야 하는 부분은 어디인가
- 검토 책임: 누가 마지막 결과를 읽고 승인할 것인가
이 다섯 줄이 없으면 멀티에이전트는 생산성이 아니라 생성량만 늘릴 가능성이 크다. 반대로 이 기준이 선명하면 단일 에이전트와 짧은 루프만으로도 충분히 좋은 자동화를 만들 수 있다.
하네스, 루프, 그래프 가운데 무엇이 최신인지 묻는 것보다 더 실용적인 질문은 따로 있다. AI가 어디까지 만들고, 기계가 어디까지 판정하며, 사람이 어디서 책임질 것인가. 결국 에이전트 설계의 중심에는 도구가 아니라 이 경계가 남는다.
원본 영상
- 제목: 하네스? 루프? 이번엔 또 그래프라고?
- 채널: 바이브랩스