Transcript
00:00:00요즘 X에서 다들 이야기하는 '그래프 엔지니어링'이라는 새로운 용어가 등장했습니다.
00:00:04그래프 이전에는 모두 '루프 엔지니어링' 방식이었죠. 에이전트에게 목표를 주면 알아서 작업을 수행하는
00:00:09방식이었습니다. 하지만 그래프를 활용하면 작업 처리 속도가 훨씬 빨라지고, 기존 루프 방식보다
00:00:14단번에 훨씬 많은 영역을 다룰 수 있습니다. 하지만 치명적인 문제가 하나 있습니다.
00:00:18그래프의 아주 작은 부분에서 오류가 발생하면 최종 결과물 전체가 망가지고,
00:00:23최종 결과물만 출력되기 때문에 원인을 추적하기도 어렵죠. 이에 앤스로픽(Anthropic)이 바로 이 문제를
00:00:27해결하고 그래프가 실패 없이 계속 동작하도록 돕는 솔루션을 발표했습니다.
00:00:32처음 오신 분들을 위해 소개하자면, 저희는 소프트웨어 기업이며 이 채널은 AI로 비즈니스를 최적화하는 방법을 알려드리는 AI Labs입니다.
00:00:37자신의 비즈니스가 없더라도, 이 기술을 활용해 타인의 비즈니스를 최적화해주고 수익을 창출할 수 있습니다.
00:00:42이번 영상에서는 그래프 엔지니어링이 생소한 분들을 위해 개념을 정리해 드리고
00:00:46앤스로픽이 제안한 정확한 해결책까지 소개해 드리겠습니다. 그래프 엔지니어링을 설명해 드리기 전에
00:00:52우선 루프 엔지니어링이 실제로 무엇인지 이해해야 합니다. 이미 알고 계신 분은 이 부분을 건너뛰셔도 됩니다.
00:00:56루프는 기본적으로 에이전트에게 맡기는 작업 사이클입니다. 모든 단계를 일일이
00:01:02프롬프트로 지시하는 대신, 도달해야 할 최종 목표를 알려주면 에이전트가 알아서
00:01:07수정해 가며 목표에 도달하죠. 저희도 자체 워크플로에서 루프를 적극적으로 활용해 왔습니다. 이미
00:01:12다양한 루프 설정 방식을 깊이 있게 다룬 전용 영상도 제작했었죠. 하지만 이제 루프는
00:01:17'그래프'라는 새로운 형태 발전하고 있습니다. 루프의 문제는 근본적으로 그 구조에서 비롯됩니다.
00:01:22루프가 작업을 일부 수행하면, 올바르게 처리되었는지 확인하는 검증 단계가 동작합니다.
00:01:27검증을 통과해야 다음 단계가 시작되죠. 모든 것이 직선형으로 실행되므로, 두 단계가 전혀 상관이 없더라도
00:01:32모든 단계가 이전 단계가 끝나기만을 기다리며 멈춰 서게 됩니다. 그래프 엔지니어링은
00:01:37바로 이 문제를 해결합니다. 직선으로 실행하는 대신, 그래프는 주요 작업을 더 작은 단위로
00:01:42쪼개고 각 부분에 전담 에이전트를 배정합니다. 이를 통해 얻을 수 있는 첫 번째 장점은 속도입니다.
00:01:47단일 에이전트가 전체를 혼자 힘겹게 처리하는 대신 여러 에이전트가 동시에 작업을 분담하기 때문이죠. 또한 작업을
00:01:52이렇게 분할하면 비용도 어느 정도 절감됩니다. 각 에이전트가 실행될 모델을 직접
00:01:56선택할 수 있기 때문입니다. 따라서 굳이 높은 지능이 필요 없는 단계에 굳이 가장 비싼
00:02:01모델을 낭비하는 일을 줄일 수 있습니다. 하지만 이는 '에이전트당' 비용일 뿐, 전체 비용을 의미하지는 않습니다. 그래프는
00:02:07단일 에이전트보다 훨씬 많은 토큰을 소비합니다. 에이전트 하나가 아닌 여러 에이전트가 동시에 동작하기 때문입니다.
00:02:12그래프를 사용하면 예상보다 한도에 훨씬 일찍 다다르게 되므로,
00:02:17Claude Code나 Codex의 20달러짜리 플랜으로는 구축하기 어렵습니다. 평소 Claude Code를 써오셨다면
00:02:22이 개념이 아주 생소하지는 않으실 겁니다. 이미 동적 워크플로(Dynamic workflow)라는
00:02:27그래프 형태를 접해보셨을 테니까요. 동적 워크플로는 전달받은 작업을 여러 하위 에이전트로 확장시키는데,
00:02:33이것이 기본적으로 그래프가 하는 역할입니다. 그래프가 가질 수 있는 여러 형태를 살펴보기 전에,
00:02:38그래프가 실제 어떤 요소로 구성되어 있는지 알아야 합니다. 모든 그래프는 노드(Node)와 엣지(Edge), 두 가지로 구성됩니다.
00:02:44노드는 부여된 큰 작업 중 독립적으로 실행되는 하나의 개별 작업입니다.
00:02:49독립된 자체 컨텍스트 윈도우에서 작업하고 보고하는 에이전트인 셈이죠. 이러한 개별 작업들을
00:02:55하나로 묶어주는 것이 바로 엣지입니다. 엣지는 한 노드에서 다음 노드로 데이터가 이동하는 방식을 제어하여, 한 에이전트의 출력이
00:03:01적절한 시점에 적절한 에이전트에 전달되도록 합니다. 즉, 모든 노드는 어떤 방식으로든
00:03:06그래프의 나머지 부분과 연결되어 있어야 합니다. 동일한 결과물을 검토하는 여러 에이전트를 예로 들 수 있죠. 그중
00:03:10어떤 에이전트도 서로 기다리지 않습니다. 하지만 모두 동일한 작업에서 시작해, 각각의 보고서가
00:03:15마지막에 동일한 한 곳으로 모이게 되므로, 이것이 바로 그래프의 기본 구조입니다. 이제 이러한 요소들이
00:03:20배치되는 다양한 형태를 살펴보겠습니다. 첫 번째 형태는 이 채널에서 이미 보여드린 적이 있는데, 당시에는
00:03:25명칭을 잘못 불렀었습니다. 그래프 엔지니어링이라는 개념이 존재하기도 전이라, 이를 '루프'라고 불렀었죠.
00:03:30하지만 실제 구조는 루프 형태로 다루고 있었던 '다이아몬드형' 그래프였습니다. 상위의 단일 작업이
00:03:35병렬로 실행되는 여러 하위 에이전트로 뻗어나간 뒤, 다시 각자 찾은 내용을 하나의 답변으로
00:03:41취합하는 단일 에이전트로 모이는 구조입니다. 다음은 '팬인 어트 바리어(Fan-in at a barrier)' 그래프 방식인데,
00:03:46하나의 사안을 여러 각도에서 동시에 평가해야 할 때 적합한 형태입니다. '팬아웃' 단계에서는
00:03:51동일한 문제를 여러 에이전트에 분산시키며, 각 에이전트는 서로 다른 관점에서 문제를 검토합니다.
00:03:56모든 에이전트가 보고를 완료할 때까지 다음 단계로 진행되지 않으며, 그 후에야
00:04:00수정 작업을 수행하게 됩니다. 이 외에도 수많은 형태가 존재합니다. 하지만 이 모든 형태는
00:04:05동일한 핵심 요소 위에 구축되는데, 그것이 바로 '검증(Verification)'입니다. 이러한 검증 절차를 제대로 설정하지 않으면,
00:04:10이후에 이어지는 모든 에이전트는 결국 오류 위에 또 다른 작업을 쌓아 올릴 뿐입니다. 검증에 대해 이야기하기 전에,
00:04:15채널 구독과 좋아요 버튼을 눌러주시면 감사하겠습니다. 이러한 작은 응원이 저희에게는 큰 힘이 됩니다.
00:04:20여러 에이전트 그룹을 함께 운영하기 시작하면, 단일 에이전트일 때는 발생하지 않던 문제들이 생겨납니다.
00:04:25가장 큰 문제는 단순히 작업량 그 자체입니다. 모든 에이전트가 동시에 구동되므로 엄청난 양의 결과물이
00:04:30한번에 쏟아져 나와, 마지막에 이를 검토하기가 대단히 어렵습니다. 또 다른 문제는
00:04:34내부 과정을 볼 수 없다는 점입니다. 문제가 터졌을 때 무엇이 원인이었는지 파악할 길을 찾기 힘듭니다.
00:04:39기본적으로 모든 에이전트는 지시 여부와 상관없이 자신이 작성한 내용을 검증합니다. 코딩 작업의 경우
00:04:44에이전트가 테스트를 실행하고 발생한 오류를 잡아내는 수준에 불과합니다. 하지만 이는 치명적인 오류만
00:04:49잡아낼 뿐입니다. 코드가 어떤 방식으로 작성되었는지는 점검하지 못하는데, 이는 중요한 문제입니다.
00:04:53Claude가 계속 이런 식으로 코드를 작성하면 향후 문제를 일으킬 수 있으니까요. Claude Code에는 이를 위한
00:04:58내장 도구가 몇 가지 있습니다. 첫 번째는 '검증(Verify) 스킬'로, 코드를 처음부터 끝까지
00:05:03확인하여 실제로 의도한 대로 동작하는지 검증합니다. 두 번째는 '툴 체이닝(Tool chaining)'으로,
00:05:08에이전트가 검증을 위해 다양한 도구를 순차 실행하는 방식입니다. Claude는 작업을 점검하는 도구를
00:05:13스스로 알아서 실행하므로, 반환된 오류를 읽고 스스로 수정합니다. 에이전트는 프로젝트에 필요한
00:05:18정확한 명령어를 스스로 알아낼 수도 있습니다. 하지만 Claude.md 파일에 미리 작성해 두면 매번
00:05:24명령어를 알아내야 하는 번거로움을 줄일 수 있습니다. 세 번째는 '코드 리뷰 스킬'로, 설정된 표준에 따라
00:05:29코드를 검사합니다. 모든 에이전트에 기본 탑재되어 있지는 않지만, 없더라도 에이전트에게 만어 달라고 요청하면
00:05:33됩니다. 하지만 가장 효과적인 검증은 내장 기능에만 온전히 의존하기보다,
00:05:38직접 구축하는 검증 체계입니다. 결과물을 검증하는 스킬을 만드는 가장 빠른 방법은
00:05:44Claude Code의 Skill Creator 플러그인을 활용하는 것입니다. 이 Claude Code 스킬은
00:05:49Codex에서도 동일하게 사용할 수 있습니다. 플러그인 명령어를 실행하고 Skill Creator를 검색하여 설치합니다. 이제
00:05:54두 가지 선택지가 있습니다. 사용자 범위(User scope)로 설치하면 작업 폴더에 관계없이
00:05:58항상 사용할 수 있습니다. 또는 현재 작업 중인 특정 프로젝트에만 설치할 수도 있습니다.
00:06:03지속적으로 사용할 스킬이므로 저희는 사용자 범위로 설치했습니다. 그 후
00:06:07슬래시 명령어(`/`)로 플러그인을 새로고침하면 Skill Creator를 사용할 준비가 끝납니다. 이제 제작할 스킬을
00:06:12지시하는데, 이 단계에서 실제 구현하고자 하는 검증의 유형을 구체적으로 설명해야 합니다.
00:06:17저희는 완성된 결과물이 초기에 요청한 사항에 부합하는지 점검할 때 리뷰 스킬을 주로 활용합니다.
00:06:22각 에이전트가 자신에게 할당된 부분만 볼 수 있는 그래프 구조에서는 이 점이 훨씬 더 중요합니다.
00:06:28이 스킬을 통해 해당 작업 분량을 원래 요구사항에 비추어 검증할 수 있게 됩니다. 하지만 스킬의 성능은
00:06:32결국 실행하는 언어 모델의 성능에 비례합니다. 커뮤니티 웹사이트의 UI 검증 시스템을
00:06:37구축할 때, 비용이 저렴하고 작업이 간단해 보인다는 이유로 리뷰어를 Haiku 모델로 실행한 적이 있습니다.
00:06:43Haiku는 지적 사항을 수없이 많이 제시했습니다. 지적된 항목의 개수만 보면 작업을 아주 훌륭히
00:06:47해낸 것처럼 보였습니다. 하지만 동일한 검증을 Opus 모델로 실행해 보니 지적 사항이 훨씬 적게 나왔습니다.
00:06:53그 이유를 읽어보기 전까지는 Opus의 결과가 더 좋지 않은 것처럼 보였습니다. Haiku가 지적했던 항목 대다수는
00:06:58저희가 의도적으로 남겨둔 코드였습니다. 즉, Haiku가 찾아낸 지적 항목의 대부분은 완전히 불필요했던 것이죠.
00:07:03Opus는 주변 코드를 분석해 이를 파악한 반면, Haiku는 그 맥락을 완전히 놓친 것이었습니다. 결국 저렴한
00:07:08리뷰 모델을 쓴다고 비용이 절감되기는커녕 검토 결과를 다시 검토해야 하는 상황이 되었습니다. 이제 이 상황을
00:07:13수많은 노드가 동일한 스킬로 각자의 작업을 검증하는 그래프 내부에 적용해 보십시오.
00:07:18에이전트들이 고장 나지도 않은 부분을 고치느라 시간과 토큰을 허비하게 될 것입니다. 게다가 이 과정이
00:07:23여러 에이전트에 걸쳐 동시에 일어나므로 어떤 에이전트가 문제를 일으켰는지 파악할 길도 없습니다.
00:07:27따라서 선택하는 모델은 단순히 리뷰의 품질만 결정하는 것이 아니라,
00:07:31그래프 전체의 품질을 좌우합니다. 판단을 내리는 노드는 토큰을 아끼려다 모든 것을 그르칠 수 있는 가장 중요한 지점입니다.
00:07:37또한 고려해야 할 점은 해당 스킬이 호출되는 '방식'과 '시점'입니다.
00:07:41이에 따라 세 가지 유형으로 나뉩니다. 세부 유형을 다루기 전에 잠시 스폰서 소식을 전해드리겠습니다.
00:07:46웹에서 실시간 데이터를 추출해 본 적이 있다면 스크래핑이 얼마나 번거로운 작업인지 잘 아실 겁니다. 캡차(CAPTCHA)나
00:07:51요청 제한과 씨름하고, 프록시를 설정하며, 배포하자마자 깨져버리는 레이아웃을
00:07:56수정해야 하죠. 저희가 사용하는 SERP API는 이러한 문제를 모두 해결해 개발에만 집중할 수 있게 해줍니다.
00:08:01단 한 번의 API 호출로 요청을 보내면 필요한 정확한 데이터가 담긴 깔끔한 JSON 객체를 받게 됩니다.
00:08:0799.9% 이상의 가동률과 약 1.2초의 빠른 응답 속도를 자랑합니다. AI 에이전트를 구축할 때
00:08:14최신 정보가 필요한 에이전트에 Google Search API를 연결하거나, 완전한 메타데이터가 포함된 피어 리뷰 논문 수집을 위해
00:08:20Google Scholar API를 연결할 수 있습니다. 수많은 상용 에이전트가 이 서비스를 신뢰하는 이유기도 합니다. 영상 설명란의
00:08:25링크를 클릭하거나 화면의 QR 코드를 스캔하여 250개의 무료 크레딧으로 시작해 보세요. 이번 영상을 후원해 준
00:08:32SERP API에 감사드립니다. 첫 번째 유형은 '독립형(Standalone)'으로, 사용자가 수동으로 직접
00:08:37실행할 때만 동작하는 스킬입니다. 독립형 스킬은 이미 완성된 기존 결과물을 정밀하게
00:08:42재검토하도록 설계되었습니다. 따라서 매 실행 시점마다 자동으로 호출되는 것은 바람직하지 않습니다. 아직 완성되지도 않은
00:08:48작업에 무거운 검토를 진행하느라 토큰을 낭비하게 되기 때문입니다. 저희가 사용했던 대표적인 예는
00:08:53Cursor의 'Thermonuclear code review'입니다. 여러 에이전트를 확장시켜 각 에이전트가 서로 다른
00:08:59보안 관점에서 코드를 검토하도록 합니다. 모든 지적 사항이 한곳에 모이므로 수정 작업을
00:09:04일괄 처리할 수 있으며, 이는 앱 개발이 완료된 후 한 번만 실행하는 검토 방식입니다. 이러한 스킬을 구축할 때는
00:09:10단순 프롬프트 지시보다 Skill Creator를 사용하는 편이 훨씬 좋습니다. 반환되는 결과물이 테스트를 거쳐 생성되므로
00:09:15신뢰도가 높기 때문입니다. 프롬프트에 검토를 원하는 영역을 지정하고, 겉핥기 식이 아닌
00:09:20심층적인 검토를 진행하도록 '종합적인 검토(Comprehensive review)'를 명시해야 합니다. 하지만 독립형 스킬은
00:09:26직접 실행해야 하므로 현재 동작 중인 노드 내부에서는 쓸모가 없습니다. 이럴 때 필요한 것이 바로 '임베디드(Embedded)'
00:09:31스킬입니다. 임베디드 스킬은 사용자가 별도로 요청하지 않아도 진행 중인 워크플로의 일부로 자동 실행됩니다.
00:09:36예를 들어 새로운 기능 구현이 요청될 때마다 작동하는 스킬을 만들 수 있습니다. 스킬에 작성된 규칙에 따라
00:09:41생성되는 모든 구성 요소가 제대로 작성되었는지 확인하며, 해당 규칙 검증을
00:09:45통과할 때까지 구현을 완료하지 못하게 막습니다. 임베디드 스킬은
00:09:50직접 제작할 수 있습니다. 하지만 앞서 언급한 Verify 스킬처럼 사전 설치된 기존 스킬을
00:09:54자동으로 호출되도록 수정할 수는 없습니다. 이러한 내장 스킬의 작동 지침은 제품 내부에 고정되어 있어
00:10:00사용자가 수정할 수 없습니다. 커스텀 스킬을 만드시려면, Skill Creator에 프롬프트를 전달하여 매 기능 구현 후
00:10:05검증 단계를 실행하도록 지시하세요. 새로운 작업이 기존 동작 기능을 망가뜨리지 않았는지
00:10:10처음부터 끝까지 테스트하도록 지시하면 됩니다. 그러면 Claude가 스킬을 생성하며, Skill Creator가
00:10:16생성했기 때문에 공정 과정에서 자체 구조화 및 테스트를 마친 참조 문서와 스크립트가 함께 제공됩니다.
00:10:21기능을 검증할 때 Claude는 기본적으로 브라우저 테스트 방식을 사용합니다. 전체 Chrome 브라우저를 열어
00:10:26페이지를 로드하고 스크린샷을 찍어 인터페이스를 확인하는 방식이죠.
00:10:31자동 브라우저 제어 도구로 널리 쓰이는 Puppeteer나 Playwright를 연동해 두었다면
00:10:36마찬가지로 동일하게 작동합니다. 하지만 Chrome은 메모리 소모가 크고 무거운 것으로 유명하며,
00:10:41워크플로 내부에서 페이지를 반복 점검하기에는 속도가 느려 실제 상당한 시간 지연을 유발합니다.
00:10:46따라서 'Chrome Headless Shell'이라는 더 가벼운 대안이 있습니다. 기본적으로 불필요한 요소를 모두
00:10:52제거한 경량화 브라우저 버전입니다. 에이전트는 동일하게 페이지에 접속하여
00:10:57스크린샷을 캡처하지만, 전체 Chrome을 띄울 때보다 이 과정을 훨씬 더 빠르게
00:11:02처리를 끝냅니다. 작성하는 검증 스킬 내부에 이 방식을 직접 탑재할 수 있습니다. 그렇게 하면 에이전트가
00:11:07새로 만드는 모든 기능을 별도 설정 없이 시각적으로 검증할 수 있습니다. 이외에
00:11:12저희 워크플로에서 가장 자주 활용하는 스킬은 'Second Opinion'이라는 스킬이며, 이유 간단합니다.
00:11:17결과물을 직접 만든 에이전트는 검수자로서는 최악의 선택입니다. 에이전트는 자신이 개발할 때 썼던
00:11:23동일한 컨텍스트를 바탕으로 평가하므로 편향된 검토를 하게 됩니다. 반면 새로운 Claude 세션은
00:11:28이전 맥락을 전혀 알지 못합니다. 그렇기에 객관적인 평가와 솔직한 답변을 제공하죠. Claude에는 유사한 역할을
00:11:33비슷하게 작동하는 기본 어드바이저가 있지만, 현재 대화 내용을 읽기 때문에
00:11:38컨텍스트를 그대로 상속받게 됩니다. 'Second Opinion'은 편향 없는 검토를 원할 때 사용합니다. 동작 방식은
00:11:43현재 실행 중인 세션 내부에서 `-p` 플래그를 사용해 또 다른 Claude 세션을 시작하는 것입니다. `-p`는
00:11:48백그라운드에서 별도의 Claude Code 세션을 새로 띄우고 지시할 프롬프트를
00:11:53전달하는 플래그입니다. 다만 이 기능을 사용할 때 유의해야 할 점이 몇 가지 있습니다.
00:11:57완전히 독립된 세션을 실행하기 때문에 답변을 받아보기까지 상당한 시간이 걸리며,
00:12:02더 똑똑한 2차 검토를 받는 것이 목적이므로 모델의 선택이 무엇보다 중요해집니다.
00:12:07따라서 해당 세션을 Opus 모델로 시작하도록 Claude에 명시적으로 지시하는 것이 좋습니다. 이를 통해 그래프 내의 모든 노드가
00:12:12작업 과정에 관여하지 않은 객관적인 주체로부터 결과물을 검증받을 수 있습니다. 하지만 단 하나의 스킬로
00:12:18모든 요소를 검증할 수는 없습니다. 제대로 된 검토를 하려면 여러 다양한
00:12:22관점에서 접근해야 하며, 각 관점마다 측정하는 기준이 다릅니다. 모든 검토 유형을 단 하나의
00:12:27스킬에 몰아넣으면 지시사항이 지나치게 많아져 에이전트의 검토 성능이 오히려 저하됩니다.
00:12:33따라서 각 관점별로 개별 스킬을 구축한 뒤 이를 사슬처럼 연결해야 합니다. 앤스로픽의
00:12:38자체 팀도 이와 같은 방식으로 일합니다. Code Review 스킬, Simplify 스킬, Verify 스킬을
00:12:43하나로 체이닝하여 사용하며, 이 세 스킬은 현재 Claude Code에 기본 탑재되어 제공됩니다. 여기에 더해 그들은
00:12:49자체 Design 스킬을 함께 실행하여, 제품의 모든 디자인 결정사항이 담긴 design.md 파일과
00:12:54인터페이스를 대조 검증합니다. 즉, 단일 방향이 아닌 네 가지 관점에서 종합적인 검토가 이루어지는 셈입니다.
00:12:59결국 여러분도 각 분야를 담당하는 스킬 모음을 갖추게 될 것입니다. 다만 에이전트에게
00:13:04이 모든 스킬을 한 번에 실행하라고 지시할 수는 없습니다. 필요한 것은 다른 스킬들을 총괄 제어하는
00:13:09상위 '오케스트레이터(Orchestrator) 스킬'입니다. 보유한 검토 스킬마다 에이전트를 하나씩
00:13:15생성하고 각각 담당 스킬을 할당합니다. 에이전트들은 독립된 컨텍스트 윈도우에서 동시에 검토를 진행하며,
00:13:20오케스트레이터 스킬은 모든 지적 사항을 하나의 보고서로 취합하여 수정 담당 에이전트에 전달합니다.
00:13:25따라서 그래프를 구축할 때는 프롬프트에 해당 오케스트레이터 스킬 하나만
00:13:30사용하라고 지시하면 됩니다. 생성되는 모든 노드가 그 단일 스킬을 불러오고, 그 하위에서 전체 검토 과정이
00:13:35알아서 병렬로 확장되어 진행됩니다. 저희는 그래프의 검증 절차를 구축하는 모든 상세한 요령을 담은
00:13:40가이드 문서를 정리해 두었습니다. 해당 문서와 영상에 등장한 모든 스킬은 저희 커뮤니티인
00:13:45AI Labs Pro에서 확인하실 수 있습니다. 저희 콘텐츠가 유용하셨고 채널을 응원하고 싶으시다면
00:13:50가장 좋은 방법이 될 것입니다. 링크는 영상 설명란에 있습니다. 오늘 준비한 영상은 여기까지입니다.
00:13:55채널을 후원하고 앞으로도 이런 영상이 계속 제작되도록 돕고 싶으시다면 아래의 Super Thanks
00:14:00버튼을 이용해 주세요. 늘 시청해 주셔서 감사드리며, 다음 영상에서 인사드리겠습니다.