엔트로픽은 그래프 엔지니어링의 결함을 어떻게 해결하려고 하는가?
본문 로딩 중...
댓글 1
댓글을 작성하려면 로그인이 필요합니다.
출처 — AI Labs 채널(YouTube) 영상의 한국어 번역·정리. 약 13분 30초 분량. 성격 — Anthropic의 공식 발표가 아니다. 채널 운영자가 자기 워크플로와, Anthropic 내부 팀이 쓴다고 알려진 방식을 함께 소개한 내용이다.
그래프 엔지니어링(Graph Engineering)이 무엇인지 설명하고,
그래프가 가진 결함과 그 결함을 검증(Verification)으로 막는 방법을 다룬다.
여기서 말하는 결함은 두 가지다.
그래프의 작은 부분에서 발생한 오류가 최종 결과 전체로 번진다는 것, 그리고 사용자에게는 최종 결과만 전달되기 때문에 어느 지점에서 틀어졌는지 추적하기 어렵다는 것이다.
영상이 제시하는 해법은 새로운 기능이 아니라, 검증을 결과물을 만든 에이전트에게 맡기지 않고, 그래프 안의 별도 노드로 분리하는 것이다.
앞서 쓴 그래프 엔지니어링 글은 개념과 내 경험까지만 다뤘고, "그래서 어떻게 적용하는가"에 대한 답이 없었다. 이 영상은 그 적용 지점 — 특히 검증을 어떻게 구성하는가 — 을 다루고 있어서 참고용으로 옮겼다.
07:45 구간은 후원사(SerpApi) 광고이며 본문 내용과 무관하다.최근 X에서 그래프 엔지니어링(Graph Engineering)이라는 새로운 용어가 많이 언급되고 있습니다.
그래프 이전에는 주로 루프 엔지니어링(Loop Engineering)이 사용됐습니다. 에이전트에게 하나의 목표를 전달하면, 에이전트가 스스로 목표를 향해 반복적으로 작업하는 방식입니다.
하지만 그래프를 사용하면 루프보다 작업을 훨씬 빠르게 처리할 수 있고, 동시에 더 넓은 범위의 작업을 수행할 수 있습니다.
다만 그래프에는 큰 문제가 하나 있습니다.
그래프의 작은 부분에서 오류가 발생해도 최종 결과 전체가 영향을 받을 수 있습니다. 더 큰 문제는 최종 결과만 전달되기 때문에, 어떤 부분에서 문제가 발생했는지 추적하기 어렵다는 것입니다.
그런데 최근 Anthropic이 이 문제를 해결하고, 그래프가 중간에 실패하지 않도록 만드는 방법을 공개했습니다.
저희는 소프트웨어 회사이며, 이 채널 AI Labs에서는 AI를 활용해 비즈니스를 최적화하는 방법을 소개합니다.
자신의 사업이 없더라도, 다른 사람이나 기업의 업무를 AI로 최적화해 수익을 얻는 데 이러한 기술을 사용할 수 있습니다.
이번 영상에서는 그래프 엔지니어링을 처음 접하는 사람을 위해 개념을 설명하고, Anthropic이 제안한 구체적인 해결 방법까지 살펴보겠습니다.
그래프 엔지니어링을 이해하기 전에 먼저 루프 엔지니어링을 알아야 합니다.
이미 루프를 알고 있다면 이 부분은 건너뛰어도 됩니다.
루프는 에이전트에게 넘겨주는 하나의 작업 사이클입니다.
사용자가 모든 단계를 하나씩 프롬프트로 지시하는 대신, 에이전트에게 도달해야 할 최종 목표를 알려줍니다. 그러면 에이전트가 작업 과정에서 스스로 판단하고 수정하면서 목표까지 도달합니다.
저희 역시 실제 업무 흐름에서 루프를 적극적으로 사용하고 있습니다. 루프를 구성하는 여러 방법을 자세히 설명한 별도의 영상도 이미 제작했습니다.
하지만 이제 루프는 그래프라는 형태로 발전하고 있습니다.
루프의 문제는 기본적으로 작업이 구성되는 방식에 있습니다.
루프에서는 먼저 하나의 작업을 수행합니다. 그다음 검증 단계가 실행되어 결과가 요구사항에 맞는지 확인합니다. 검증을 통과하면 다음 작업으로 넘어갑니다.
즉, 모든 작업이 직선 형태로 실행됩니다.
서로 아무런 관련이 없는 작업이라도 앞 단계가 끝날 때까지 기다려야 합니다.
그래프 엔지니어링은 바로 이 문제를 해결합니다.
그래프는 하나의 큰 작업을 여러 개의 작은 작업으로 나누고, 각각의 작업을 별도의 에이전트에게 맡깁니다.
가장 먼저 얻는 장점은 속도입니다.
에이전트 하나가 전체 작업을 순서대로 처리하는 것이 아니라, 여러 에이전트가 동시에 작업하기 때문입니다.
작업을 나누면 각 작업에 사용할 모델도 따로 선택할 수 있습니다.
높은 지능이 필요하지 않은 단순 작업에는 저렴한 모델을 사용하고, 복잡한 판단이 필요한 작업에만 비싼 모델을 사용할 수 있습니다.
따라서 개별 에이전트에 들어가는 비용은 줄어들 수 있습니다.
하지만 이것은 어디까지나 에이전트 한 개당 비용에 대한 이야기입니다. 전체 비용이 줄어든다는 뜻은 아닙니다.
그래프는 하나의 에이전트보다 훨씬 많은 토큰을 사용합니다. 여러 에이전트가 동시에 실행되기 때문입니다.
그래프를 사용하면 평소보다 훨씬 빠르게 사용량 제한에 도달할 수 있습니다.
따라서 Claude Code나 Codex의 월 20달러 수준 요금제만으로 그래프 구조를 본격적으로 운영하기는 어렵습니다.
Claude Code를 사용해 본 사람이라면 그래프가 완전히 새로운 개념은 아닐 수 있습니다.
Claude Code의 동적 워크플로(Dynamic Workflow)가 그래프의 한 형태이기 때문입니다.
동적 워크플로는 사용자가 전달한 작업을 여러 하위 에이전트에게 분산합니다. 이것이 기본적으로 그래프가 하는 일입니다.
그래프의 형태를 살펴보기 전에 그래프를 구성하는 요소부터 알아야 합니다.
모든 그래프는 두 가지 요소로 구성됩니다.
노드는 전체 작업에서 분리된 하나의 개별 작업입니다.
각 노드는 독립적으로 실행됩니다. 하나의 에이전트가 별도의 컨텍스트 창에서 작업을 수행한 후 결과를 보고합니다.
이처럼 분리된 작업을 서로 연결하는 것이 엣지입니다.
엣지는 한 노드에서 다른 노드로 데이터가 이동하는 방식을 제어합니다.
즉, 한 에이전트의 결과가 적절한 시점에 적절한 다른 에이전트에게 전달되도록 합니다.
따라서 모든 노드는 어떤 방식으로든 나머지 그래프와 연결돼 있어야 합니다.
예를 들어 여러 에이전트가 동일한 결과물을 동시에 검토할 수 있습니다.
이 에이전트들은 서로의 작업이 끝나기를 기다리지 않습니다. 모두 동일한 결과물을 입력으로 받아 동시에 검토합니다.
그리고 각 에이전트의 검토 결과는 마지막에 하나의 지점으로 모입니다.
이것이 그래프를 구성하는 기본 원리입니다.
이제 노드와 엣지가 어떤 형태로 배치되는지 살펴보겠습니다.
첫 번째는 저희 채널에서도 이전에 소개했던 구조입니다.
당시에는 이를 루프라고 불렀지만, 그래프 엔지니어링이라는 용어가 등장하기 전이었습니다.
정확히 말하면 당시 사용했던 것은 그래프를 반복 실행하는 구조였고, 그래프의 형태는 다이아몬드였습니다.
상단에 있는 하나의 작업이 여러 개의 하위 에이전트 작업으로 분리됩니다.
여러 에이전트는 나란히 동시에 작업합니다.
작업이 끝나면 결과가 다시 하나의 에이전트로 모입니다.
마지막 에이전트는 각 에이전트가 발견한 내용을 하나의 답변으로 통합합니다.
구조를 단순화하면 다음과 같습니다.
하나의 작업
↓
여러 에이전트로 분기
↓
각 에이전트가 병렬 실행
↓
하나의 에이전트가 결과 통합
다음은 팬아웃 후 배리어를 거쳐 팬인되는 그래프입니다.
하나의 결과물을 여러 관점에서 동시에 평가해야 할 때 사용하는 구조입니다.
팬아웃 단계에서는 동일한 문제를 여러 에이전트에게 전달합니다.
각 에이전트는 서로 다른 관점에서 문제를 검토합니다.
모든 에이전트가 결과를 반환하기 전까지 다음 단계는 진행되지 않습니다.
모든 검토 결과가 모이면 그때 수정 작업을 실행합니다.
이 밖에도 다양한 형태의 그래프가 있습니다.
그러나 모든 그래프 구조의 기반에는 동일한 요소가 있습니다.
바로 검증(Verification)입니다.
검증 과정을 제대로 구성하지 않으면, 뒤에서 실행되는 모든 에이전트가 앞에서 발생한 잘못된 결과를 기반으로 계속 작업하게 됩니다.
여러 에이전트를 동시에 실행하면 하나의 에이전트를 사용할 때와는 전혀 다른 문제가 발생합니다.
가장 큰 문제는 작업량입니다.
여러 에이전트가 동시에 작업하기 때문에 많은 결과물이 한꺼번에 반환됩니다.
최종 단계에서 이 모든 결과를 검토하는 것은 매우 어렵습니다.
또 다른 문제는 중간 과정을 확인하기 어렵다는 것입니다.
문제가 발생했을 때 무엇이 원인이었는지 파악하기 어렵습니다.
에이전트는 사용자가 별도로 요청하지 않더라도 자신이 작성한 결과를 어느 정도 검증합니다.
코드 작업이라면 일반적으로 테스트를 실행하고, 발생한 오류를 확인합니다.
하지만 이 방식은 주로 명백한 오류만 탐지합니다.
코드가 어떤 방식으로 작성됐는지, 장기적으로 유지보수 문제가 발생할 수 있는지까지는 충분히 확인하지 않습니다.
Claude가 당장은 작동하지만 좋지 않은 방식으로 코드를 계속 작성한다면, 미래에 문제가 발생할 수 있습니다.
Claude Code에는 몇 가지 검증 도구가 기본으로 제공됩니다.
첫 번째는 Verify Skill입니다.
Verify Skill은 코드의 시작부터 끝까지 확인하고, 실제로 의도한 대로 동작하는지 검증합니다.
두 번째는 도구 체이닝(Tool Chaining)입니다.
에이전트가 여러 도구를 연속으로 실행해 결과를 검증하는 방식입니다.
Claude는 작업을 확인하는 데 필요한 도구를 실행하고, 도구에서 반환된 오류를 읽은 다음 스스로 수정할 수 있습니다.
프로젝트에서 사용하는 명령어도 스스로 파악할 수 있습니다.
그러나 프로젝트의 CLAUDE.md 파일에 테스트 명령어나 검증 명령어를 미리 작성해 두면, Claude가 매번 명령어를 다시 알아내는 과정을 줄일 수 있습니다.
세 번째는 코드 리뷰 스킬(Code Review Skill)입니다.
이 스킬은 코드를 사전에 정의한 기준과 비교해 검토합니다.
모든 에이전트에 코드 리뷰 스킬이 기본으로 포함돼 있는 것은 아닙니다.
스킬이 없다면 에이전트에게 직접 코드 리뷰 스킬을 만들어 달라고 요청할 수 있습니다.
하지만 가장 효과적인 검증은 기본 기능에만 의존하는 것이 아니라, 사용자가 자신의 프로젝트에 맞게 직접 구성한 검증입니다.
작업을 검증하는 스킬을 빠르게 만드는 방법은 Claude Code의 Skill Creator 플러그인을 사용하는 것입니다.
이 Claude Code 스킬은 Codex에서도 사용할 수 있습니다.
플러그인 명령어를 실행한 후 Skill Creator를 검색해 설치합니다.
설치 범위는 두 가지 중 하나를 선택할 수 있습니다.
첫 번째는 사용자 범위입니다.
사용자 범위로 설치하면 어떤 폴더나 프로젝트에서 작업하더라도 해당 스킬을 사용할 수 있습니다.
두 번째는 현재 프로젝트에만 설치하는 방식입니다.
검증 스킬은 지속적으로 사용하게 되기 때문에, 저희는 사용자 범위로 설치했습니다.
설치 후 슬래시 명령어를 사용해 플러그인을 다시 불러오면 Skill Creator를 사용할 수 있습니다.
그다음 만들고 싶은 검증 스킬을 설명합니다.
이때 중요한 것은 어떤 검증을 원하는지 구체적으로 작성하는 것입니다.
저희는 주로 완성된 결과물이 최초 요구사항과 일치하는지 확인하는 리뷰 스킬을 사용합니다.
그래프에서는 이 검증이 특히 중요합니다.
각 에이전트는 자신이 담당한 작업만 보기 때문입니다.
검증 스킬을 사용하면 각 에이전트가 자신이 만든 결과를 전체 원본 요구사항과 비교할 수 있습니다.
스킬의 성능은 해당 스킬을 실행하는 모델의 성능에 크게 영향을 받습니다.
저희가 커뮤니티 웹사이트의 UI 검증 시스템을 만들 때, 리뷰 작업이 단순해 보였기 때문에 저렴한 Haiku 모델을 사용했습니다.
Haiku는 매우 긴 문제 목록을 반환했습니다.
발견한 문제의 개수만 보면 훌륭한 결과처럼 보였습니다.
그다음 동일한 리뷰를 Opus로 실행했습니다.
Opus는 Haiku보다 훨씬 적은 문제를 발견했습니다.
처음에는 Opus의 결과가 더 나빠 보였습니다.
하지만 검토 이유를 읽어 보니 상황이 달랐습니다.
Haiku가 문제로 판단한 항목 중 상당수는 저희가 의도적으로 남겨둔 부분이었습니다.
따라서 Haiku가 발견한 문제 대부분은 수정할 필요가 없는 내용이었습니다.
Opus는 주변 코드를 함께 분석해 해당 코드가 의도적으로 작성됐다는 사실을 판단했습니다.
Haiku는 이 맥락을 전혀 파악하지 못했습니다.
결국 저렴한 모델을 사용한 리뷰는 비용을 절감하지 못했습니다.
검토 결과를 다시 사람이 검토해야 했기 때문입니다.
이 문제를 그래프 안에 넣어 보면 더 심각해집니다.
여러 노드가 동일한 스킬을 사용해 자신의 작업을 검토한다고 가정해 보겠습니다.
판단 능력이 부족한 모델을 사용하면, 에이전트들이 실제로 문제가 없는 부분을 수정하는 데 시간과 토큰을 사용하게 됩니다.
이 작업이 서로 분리된 여러 에이전트에서 동시에 진행되기 때문에, 어떤 노드가 잘못된 수정을 시작했는지 확인하기도 어렵습니다.
따라서 모델 선택은 단순히 리뷰 품질만 결정하지 않습니다.
그래프 전체의 품질을 결정합니다.
판단과 검증을 담당하는 노드는 토큰을 절약해서는 안 되는 영역입니다.
다른 작업 노드에서는 저렴한 모델을 사용할 수 있지만, 최종 판단을 담당하는 노드에 저렴한 모델을 사용하면 전체 그래프가 잘못된 방향으로 갈 수 있습니다.
검증 스킬을 구성할 때는 어떤 방식으로, 언제 스킬을 실행할지도 결정해야 합니다.
검증 스킬은 실행 방식에 따라 크게 세 가지 종류로 나눌 수 있습니다.
실시간 웹 데이터를 가져와 본 경험이 있다면 웹 스크래핑이 얼마나 번거로운지 알 것입니다.
캡차와 요청 제한을 처리하고, 프록시를 관리해야 하며, 웹사이트 레이아웃이 변경될 때마다 코드를 수정해야 합니다.
저희는 이러한 문제를 해결하기 위해 SerpApi를 사용합니다.
API 요청 한 번으로 필요한 데이터를 정리된 JSON 객체 형태로 받을 수 있습니다.
SerpApi는 99.9% 이상의 가동률과 약 1.2초의 응답 속도를 제공합니다.
AI 에이전트를 구축할 때는 최신 정보가 필요한 에이전트에 Google Search API를 연결할 수 있습니다.
또는 전체 메타데이터가 포함된 동료 심사 논문이 필요하다면 Google Scholar API를 사용할 수 있습니다.
많은 프로덕션 환경의 에이전트가 이를 사용하는 이유입니다.
설명란의 링크나 화면의 QR 코드를 이용하면 250개의 무료 크레딧으로 시작할 수 있습니다.
이 영상을 후원해 준 SerpApi에 감사드립니다.
첫 번째 유형은 독립 실행형 스킬(Standalone Skill)입니다.
사용자가 직접 실행할 때만 동작하는 스킬입니다.
독립 실행형 스킬은 이미 완성된 결과물을 깊이 검토하기 위해 만들어집니다.
따라서 모든 작업이 실행될 때마다 자동으로 작동하도록 만들 필요는 없습니다.
완성되지 않은 작업을 매번 깊게 검토하면 불필요하게 토큰만 소비하게 됩니다.
저희가 사용했던 독립 실행형 스킬 중 하나는 Cursor의 Thermonuclear Code Review입니다.
이 스킬은 여러 에이전트를 분기시키고, 각 에이전트가 서로 다른 보안 관점에서 코드를 검토하도록 합니다.
각 에이전트가 발견한 내용은 한곳으로 모이고, 이후 수정 작업을 통합해 진행합니다.
이러한 종류의 리뷰는 애플리케이션 개발이 완료된 후 한 번 실행하는 것이 적절합니다.
독립 실행형 스킬을 만들 때는 단순히 프롬프트로 리뷰를 요청하는 것보다 Skill Creator를 사용하는 편이 좋습니다.
Skill Creator가 생성한 스킬은 생성 과정에서 테스트되기 때문에 상대적으로 신뢰하기 쉽습니다.
프롬프트에는 어떤 영역을 검토할 것인지 작성해야 합니다.
빠른 검토가 아니라 깊은 검토를 원한다면, 리뷰가 포괄적이어야 한다는 점도 명확히 전달해야 합니다.
하지만 독립 실행형 스킬은 아직 작업 중인 노드에는 적합하지 않습니다.
사용자가 직접 실행해야 하기 때문입니다.
이 문제를 해결하는 것이 임베디드 스킬입니다.
임베디드 스킬(Embedded Skill)은 사용자가 별도로 실행하지 않아도 기존 워크플로의 일부로 자동 실행됩니다.
예를 들어 누군가 새로운 기능 구현을 요청할 때마다 실행되는 스킬을 만들 수 있습니다.
이 스킬은 새로 생성된 모든 컴포넌트가 사전에 정의된 규칙을 따르는지 확인합니다.
정해진 규칙에 대한 검증이 끝나기 전까지 구현 작업이 완료되지 않도록 만들 수도 있습니다.
임베디드 스킬은 직접 만들 수 있습니다.
하지만 앞에서 설명한 Verify Skill처럼 제품에 기본으로 설치된 스킬을 사용자가 원하는 조건으로 자동 실행되도록 수정할 수는 없습니다.
기본 스킬의 실행 지침은 제품 내부에 포함돼 있으며 사용자가 수정할 수 없기 때문입니다.
자체 임베디드 스킬을 만들려면 Skill Creator에 다음과 같은 요구사항을 전달합니다.
각 기능 구현이 완료된 후 검증 단계를 실행한다.
기능을 처음부터 끝까지 테스트한다.
새로 구현한 기능이 기존 기능을 망가뜨리지 않았는지 확인한다.
그러면 Claude가 해당 검증 스킬을 생성합니다.
Skill Creator가 생성한 스킬에는 생성 과정에서 구조화하고 테스트한 참고 자료와 스크립트도 포함됩니다.
기능을 검증할 때 Claude는 기본적으로 브라우저 테스트를 사용합니다.
전체 Chrome 브라우저를 실행하고 페이지를 불러온 다음 스크린샷을 촬영해 인터페이스를 확인합니다.
Puppeteer나 Playwright를 연결한 경우에도 비슷한 방식으로 브라우저를 자동 조작합니다.
하지만 Chrome은 메모리 사용량이 크고 무겁게 동작하는 것으로 유명합니다.
워크플로 내부에서 동일한 페이지를 반복적으로 확인해야 한다면 속도가 느려지고 실제 작업 시간이 증가합니다.
이보다 가벼운 방법으로 Chrome Headless Shell을 사용할 수 있습니다.
Chrome Headless Shell은 브라우저에서 불필요한 요소를 제거한 가벼운 버전입니다.
에이전트는 기존과 동일하게 페이지에 접속하고 스크린샷을 촬영할 수 있습니다.
하지만 전체 Chrome을 사용하는 것보다 훨씬 빠르게 작업을 처리합니다.
이 방식을 검증 스킬 안에 직접 포함할 수 있습니다.
그러면 에이전트가 기능을 구현할 때마다 사용자가 별도로 설정하지 않아도 시각적 검증이 자동으로 실행됩니다.
저희가 실제 워크플로에서 가장 많이 사용하는 스킬은 Second Opinion입니다.
이유는 간단합니다.
결과물을 만든 에이전트는 그 결과물을 검토하기에 가장 좋지 않은 에이전트입니다.
동일한 컨텍스트를 사용해 결과물을 만들었기 때문에, 검토할 때도 같은 관점과 전제를 그대로 사용합니다.
반면 새로운 Claude 세션은 기존 작업 과정을 보지 않았습니다.
따라서 편향되지 않은 관점에서 결과물을 검토하고 더 직접적인 평가를 내릴 수 있습니다.
Claude에는 이와 비슷한 역할을 하는 기본 Advisor 기능이 있습니다.
하지만 Advisor는 현재 대화 내용을 읽습니다.
따라서 기존 세션이 가진 컨텍스트를 그대로 물려받습니다.
Second Opinion은 기존 컨텍스트 없이 리뷰를 받고 싶을 때 사용합니다.
기존 세션 내부에서 -p 플래그를 사용해 별도의 Claude Code 세션을 시작하는 방식입니다.
-p 플래그는 프롬프트를 전달하면서 완전히 분리된 Claude Code 세션을 실행합니다.
이 방식을 사용할 때 알아야 할 점이 있습니다.
완전히 별도의 세션을 실행하기 때문에 결과를 반환하는 데 시간이 오래 걸립니다.
또한 Second Opinion의 목적은 더 뛰어난 모델로 다시 검토하는 것이기 때문에 모델 선택이 특히 중요합니다.
따라서 새 세션을 Opus 모델로 실행하도록 Claude에게 명시적으로 지시하는 것이 좋습니다.
이렇게 하면 그래프의 각 노드는 자신이 수행한 작업에 관여하지 않은 별도의 모델에게 검토를 받을 수 있습니다.
하지만 하나의 스킬만으로 모든 검증을 처리할 수는 없습니다.
결과물을 제대로 검토하려면 여러 관점에서 확인해야 합니다.
각 관점은 서로 다른 평가 기준을 가지고 있습니다.
모든 리뷰 기준을 하나의 스킬에 넣으면 에이전트가 너무 많은 지시를 동시에 처리해야 합니다.
그 결과 검토 성능이 오히려 낮아질 수 있습니다.
따라서 검토 관점마다 별도의 스킬을 만들고, 여러 스킬을 체인으로 연결해야 합니다.
Anthropic 내부 팀도 이러한 방식으로 작업합니다.
Anthropic은 다음 스킬들을 연결해 사용합니다.
이 세 가지 스킬은 현재 Claude Code에 기본으로 포함돼 있습니다.
여기에 별도의 Design Skill도 사용합니다.
Design Skill은 인터페이스를 design.md 파일과 비교합니다.
design.md는 제품의 모든 디자인 의사결정을 기록한 파일입니다.
따라서 이 구조에서는 하나의 결과물을 다음 네 가지 관점에서 검토합니다.
코드 품질 검토
코드 단순화 검토
기능 동작 검증
디자인 기준 검증
실제로 그래프를 운영하다 보면 이처럼 서로 다른 관점을 담당하는 여러 스킬을 구성하게 됩니다.
그러나 에이전트에게 단순히 모든 스킬을 한꺼번에 실행하라고 지시해서는 안 됩니다.
여러 검증 스킬 위에는 또 하나의 스킬이 필요합니다.
이 스킬은 오케스트레이터 스킬(Orchestrator Skill)입니다.
오케스트레이터 스킬의 유일한 역할은 다른 검증 스킬을 실행하는 것입니다.
오케스트레이터는 각 리뷰 스킬마다 별도의 에이전트를 생성합니다.
각 에이전트는 하나의 리뷰 스킬을 전달받습니다.
모든 리뷰 에이전트는 서로 분리된 컨텍스트 창에서 동시에 결과물을 검토합니다.
검토가 완료되면 오케스트레이터가 모든 발견 사항을 하나의 보고서로 통합합니다.
이후 수정 작업을 담당하는 에이전트들은 통합 보고서를 기준으로 작업합니다.
구조는 다음과 같습니다.
검증 오케스트레이터
├─ 코드 리뷰 에이전트
├─ 기능 검증 에이전트
├─ 코드 단순화 에이전트
└─ 디자인 검증 에이전트
↓
검토 결과 통합
↓
수정 에이전트 실행
이 구조를 만들어 두면 그래프를 실행할 때 프롬프트에 여러 검증 스킬을 일일이 지정할 필요가 없습니다.
그래프가 오케스트레이터 스킬 하나만 사용하도록 지시하면 됩니다.
각 노드는 동일한 오케스트레이터 스킬을 불러옵니다.
그러면 실제 검토 작업은 오케스트레이터 아래에서 여러 에이전트로 자동 분기됩니다.
저희는 그래프 검증을 구성하는 여러 방법을 자세히 정리한 문서를 제작했습니다.
이 문서와 영상에서 소개한 모든 스킬은 저희 커뮤니티인 AI Labs Pro에서 확인할 수 있습니다.
저희 콘텐츠가 도움이 되었고 채널을 지원하고 싶다면 커뮤니티에 참여하는 것이 가장 좋은 방법입니다.
링크는 영상 설명란에 있습니다.
이것으로 영상을 마치겠습니다.
이와 같은 영상을 계속 제작할 수 있도록 채널을 지원하고 싶다면 영상 아래의 Super Thanks 버튼을 사용할 수도 있습니다.
항상 시청해 주셔서 감사합니다.
다음 영상에서 뵙겠습니다.
- 5분 동안 검증 스킬 네 개를 에 넣는다. - 가 요구사항·코드·테스트 검증을 묶어서 실행한다. - 작업 분할, 계약, 파일 소유권까지 매번 적기 귀찮다면 1분 더 써서 을 추가한다. - 자동 테스트를 먼저 실행하고, 코드로 판정하지 못한 화면만 브라우
- 하네스·루프·그래프는 서로를 대체하는 게 아니라 겹쳐 있는 층이다. - 나누기만 하고 공유할 기준을 못 박지 않으면 합칠 때 어긋난다 (직접 겪은 사례). - Bun의 Rust 재작성은 가능성을 보여줬지만 사람의 검토를 대신하지 못했다. - 한계는 사라진 게 아니라 토큰 비용과 검토 책임으로 옮겨갔다.
우리들의 게임 발매 이야기
- 5분 동안 검증 스킬 네 개를 에 넣는다. - 가 요구사항·코드·테스트 검증을 묶어서 실행한다. - 작업 분할, 계약, 파일 소유권까지 매번 적기 귀찮다면 1분 더 써서 을 추가한다. - 자동 테스트를 먼저 실행하고, 코드로 판정하지 못한 화면만 브라우
- 하네스·루프·그래프는 서로를 대체하는 게 아니라 겹쳐 있는 층이다. - 나누기만 하고 공유할 기준을 못 박지 않으면 합칠 때 어긋난다 (직접 겪은 사례). - Bun의 Rust 재작성은 가능성을 보여줬지만 사람의 검토를 대신하지 못했다. - 한계는 사라진 게 아니라 토큰 비용과 검토 책임으로 옮겨갔다.
대단합니다..ㄷㄷㄷ