Transcript
00:00:00지난달에는 루프 엔지니어링이었고, 그 전에는 컨텍스트 엔지니어링이었는데, 오늘의 새로운
00:00:05트렌드는 그래프 엔지니어링입니다. 하지만 이게 실제로 이해해야 하는 개념일까요, 아니면
00:00:11AI 거품이 그저 별거 아닌 주제에 화려한 이름만 붙인 것일까요?
00:00:17이번 영상에서 그 질문에 답해 드리겠습니다. 스포를 하자면, 이건 결코 허황된 주제가 아닙니다.
00:00:23물론 그래프 엔지니어링이 만드는 모든 작은 작업에 다 적용되는 건 아닙니다.
00:00:28하지만 꼭 이해해 두어야 할 개념입니다. 특히 복잡한 루프를 사용하는 분들이라면
00:00:33더더욱 그렇죠. 본인이 그렇거나 조만간 그렇게 될 예정이라면 영상을 끝까지 시청해 보세요.
00:00:38그래프 엔지니어링은 사실 루프 엔지니어링의 확장이자 진화 형태입니다.
00:00:43개념을 정립하기 위해 먼저 루프 엔지니어링이 무엇인지 아주 간단히 짚고 넘어가겠습니다.
00:00:47모든 루프에는 크게 세 가지 단계가 있습니다. 첫째는 트리거입니다. 어떻게
00:00:54작동을 시작할까요? 이상적으로는 자율적으로, 매일 특정 시간에 실행되거나 이벤트 기반으로 작동합니다.
00:01:00두 번째 단계는 작업입니다. 실제로 무엇을 수행하는가입니다. 그리고 세 번째 단계에서는 일종의 성공
00:01:07기준이 필요합니다. 무언가를 하라고 지시했으면, 제대로 수행되었는지 어떻게 확인할까요?
00:01:13제대로 되지 않았다면 처음부터 다시 실행되기를 원하니까요. 이상적으로는 전부 자동으로 실행되고 데이터가
00:01:19어딘가에 저장되어 자체적인 개선 요소까지 추가할 수 있는 구조입니다. 하지만 가장 기본적으로는
00:01:25트리거가 필요하고, 작업을 수행해야 하며, 잘 되었는지 테스트할 수 있어야 하고
00:01:30이 모든 과정이 자동화되어야 합니다. 여기에 있는 예시를 보면, 매일 아침 보고서를
00:01:35생성하는 루프가 있습니다. 이 AI 에이전트는 매일 오전 7시에 실행되는데, 이것이 트리거입니다.
00:01:42수행할 작업은 유튜브, 트위터, 레딧 등 다양한 소셜 미디어 플랫폼을 확인하여
00:01:47AI 트렌드 정보를 찾는 것입니다. 그리고 이메일도 확인하도록 하고 싶습니다. 이 모든 작업을 마치면
00:01:54정보를 취합하여 보고서를 생성하도록 합니다. 이것이 작업입니다. 여기서 성공의 기준은
00:02:00약간 모호할 수 있습니다. 보고서가 제대로 작성되었는지 어떻게 정의할까요? 이 경우
00:02:05루프에게 보고서에 이런 종류의 정보가 들어가야 하고, 분량은 어느 정도여야 하며,
00:02:11링크가 포함되어야 한다는 지침을 줍니다. 평가할 만한 기준을 제공하는 것이죠. 이것이 바로
00:02:17루프입니다. 간단하죠. 단일 에이전트가 실행합니다. 그렇다면 이걸 어떻게 그래프 구조로 바꿀까요?
00:02:25동일한 작업을 목표로 하면서 루프 엔지니어링에서 그래프 엔지니어링으로 어떻게 넘어갈까요?
00:02:30여전히 매일 아침 보고서가 완성되기를 원합니다. 한번 살펴보죠. 오른쪽에 있는 것이
00:02:35동일한 작업을 그래프 엔지니어링 방식으로 설계한 버전입니다. 얻고자 하는 보고서는 같습니다.
00:02:40하지만 작업을 수행하는 에이전트의 수를 늘렸습니다. 정확히는 한 에이전트가
00:02:46모든 것을 처리하던 것에서, 서로 연결되어 특정 작업을 수행하는 여러 에이전트로 변경했습니다.
00:02:53트리거는 여전히 동일합니다. 매일 아침 7시에 실행됩니다. 하지만 이제 유튜브를 전담하는 에이전트,
00:02:58트위터를 전담하는 에이전트, 레딧 전담 에이전트, 이메일을 전담하는 에이전트가
00:03:04각각 존재합니다. 각 에이전트는 필요한 정보를 가져와서
00:03:09스스로 요약 및 종합합니다. 그리고 그 결과를 보고서 작성 전담
00:03:17에이전트에게 보냅니다. 보고서 에이전트는 데이터를 모아 원하는 형태의 보고서로 재종합합니다.
00:03:23여기서 한 단계 더 나아가 검토 전담 에이전트를 둘 수도 있습니다. 검토 에이전트는
00:03:30생성된 보고서를 독자적으로 확인하고, 우리가 정의한 성공적인 보고서 기준과 비교하여
00:03:36이 전체 과정을 다시 한 번 루프로 돌려야 할지, 아니면 그대로 최종 출력할지를 결정합니다.
00:03:41이것이 간단히 요약한 그래프 엔지니어링입니다. 자세히 분석해 봅시다. 아마 여러분은
00:03:48“에이전트를 여러 개 추가한 것뿐인데 정확히 무슨 차이가 있는지 모르겠다”고 생각할 수 있습니다.
00:03:51맞습니다, 에이전트를 추가한 게 맞고 거기에는 명확한 이유가 있습니다. 그래프 엔지니어링이
00:03:58조금 더 복잡한 이유는 단순히 복잡하게 만들고 싶어서가 아니라,
00:04:03각각의 개별 작업을 자신만의 루프 엔지니어링을 실행하는
00:04:09독립된 에이전트로 전환했기 때문입니다. 이전에는 무엇이 있었나요? 루프 엔지니어링이 있었죠.
00:04:14그 루프가 모든 것을 처리하고 성공 기준을 확인했습니다. 하지만 아주 높은 수준에서
00:04:18여러 가지 다른 일들을 한 번에 처리하고 있었죠. 반면 그래프 엔지니어링에서는
00:04:22하나의 특정 작업에 집중하여 확대했습니다. 이제 유튜브 분석 및
00:04:29유튜브 조사를 전담하는 에이전트 하나가 있으며, 이것 역시 루프 엔지니어링 구조로 바뀌었습니다.
00:04:34생각해 보세요. 하나의 작업으로 줄어들었지만 여전히 루프 엔지니어링입니다. 똑같이 트리거가 있죠.
00:04:39오전 7시라는 조건은 동일합니다. 작업도 있습니다. 유튜브에서 AI 관련 정보를 찾아서
00:04:46요약 및 종합해야 합니다. 그리고 세 번째로, 여전히 성공 기준이 존재합니다. 하지만 이것을
00:04:51그래프 엔지니어링 구조로 바꿈으로써, 각 단계별 성공의 기준을
00:04:57매우 구체적으로 설정할 수 있습니다. 예를 들어 최소 5개 이상의 출처를 확보하도록 하거나,
00:05:03요약 분량이 최소 두 단락 이상이어야 한다거나, 수집한 모든 출처와 정보마다
00:05:09그에 따른 시사점(So What)을 적어주도록 요구할 수 있습니다.
00:05:16따라서 검증 프로세스가 대략적이고 거창하게 작동하여 모든 것을 “잘됐다” 혹은 “안됐다” 식으로
00:05:22몰아넣는 대신, 개별 세부 단계로 세분화한 것입니다. 이것이 왜 중요할까요?
00:05:27우선 결과물의 품질이 향상됩니다. 한 에이전트가 모든 일을 처리하는 대신
00:05:33한 에이전트가 한 가지 일에만 집중하기 때문입니다. 컨텍스트 저하(Context Rot) 관점에서 보더라도,
00:05:4010가지 일을 한 번에 처리하려는 에이전트보다 컨텍스트 윈도우가 상대적으로 쾌적하게 유지되므로
00:05:44더 뛰어난 결과물을 얻을 수 있습니다. 게다가 처리 속도도 훨씬 빠릅니다.
00:05:51한 에이전트가 10가지 일을 순차적으로 하는 대신 4개의 에이전트가 4가지 일을 병렬로 처리하니까요.
00:05:56따라서 더 빠르고 효율적이며, 문제가 발생했을 때 지점을 파악하기도 훨씬 쉽습니다.
00:06:03유튜브 쪽 문제인지 레딧 쪽 문제인지 즉시 식별할 수 있기 때문이죠. 단일 에이전트 구조에서는
00:06:08보고서가 마음에 들지 않아 수정으로 돌려보낼 때 어느 단계에서 잘못되었는지 신호와 노이즈를
00:06:15구분하기가 더 어렵습니다. 각 세부 작업마다 성공 기준을 독립적으로 정의할 수 있는
00:06:20그래프 엔지니어링의 장점이 바로 여기에 있습니다. 이것이 그래프 엔지니어링의 핵심이자
00:06:27우리가 관심을 가져야 하는 이유입니다. 단일 에이전트 대신 일련의 에이전트 일체를 보유하며,
00:06:33이들이 다양한 방식으로 연결됩니다. 각 작업을 원자 단위처럼 세분화한 것이죠.
00:06:38원자 단위의 작업으로 나누어졌기 때문에 수행할 내용과 성공 기준을 각 작업별로 매우 구체적으로
00:06:44설정할 수 있습니다. 결과적으로 이 에이전트들은 각각 독립된
00:06:48루프 엔지니어링 구조가 되며, 우리는 그 루프들을 연결해 준 셈입니다. 이 시점에서 나올 법한 질문은
00:06:54“그렇다면 언제 그래프 엔지니어링을 쓰고, 언제 루프 엔지니어링을 써야 하는가?”일 것입니다.
00:06:58솔직히 말해, 항상 이렇게 지나치게 복잡한 다중 에이전트 시스템을 구축할 필요는 없습니다.
00:07:04그럴 필요가 없죠. 많은 경우 단순한 루프 하나만으로도 충분합니다. 하지만 그래프 엔지니어링 기반
00:07:09구축을 진지하게 고려해야 하는 세 가지 상황이 있습니다. 첫 번째 시나리오는
00:07:15컨텍스트 문제, 특히 컨텍스트 저하 문제에 직면했을 때입니다. 만약 어떤 에이전트에게
00:07:20계속해서 루프를 돌리도록 요청하고, 실행될 때마다 4, 5, 6, 7, 8가지의 작업을
00:07:25수행하게 해서 각 실행 후 컨텍스트 윈도우가 30만, 40만, 50만 토큰 영역에
00:07:29도달하는 상황이라면, 작업을 분할하는 것이 타당합니다.
00:07:36굳이 가득 찬 컨텍스트 윈도우 때문에 결과물의 품질 저하를 감수할 필요가 전혀 없으니까요.
00:07:41굳이 그럴 필요가 없다면 말이죠. 두 번째 시나리오는 독립적인 검토가 필요할 때입니다.
00:07:48어느 시점에는 성공 여부를 판단해야 하며, 이것이 아까 언급한 성공 기준 항목입니다.
00:07:55생성물(이 경우 보고서)을 만든 바로 그 에이전트가 스스로 판단하여
00:08:01“이것이 잘되었다, 아니다”를 평가하는 것이 적절한지 스스로에게 물어봐야 합니다.
00:08:07모닝 보고서 정도라면 스스로 평가하는 것도 괜찮습니다. 그렇게 복잡하지도 않고, “이 보고서는
00:08:13꽤 잘됐다”고 평가하는 위험 부담이 크지 않으며 어느 정도 주관적이기도 하니까요. 하지만 리스크가 매우 크고
00:08:18객관적인 교차 검증이 필요한 작업이라면, 작성한 결과물을 검토하기 위해 완전 별개의 에이전트를
00:08:24투입하는 그래프 엔지니어링 시나리오를 활용하기 시작해야 합니다.
00:08:28심지어 클로드 코드 에이전트가 아닌 GPT 5.6 같은 다른 모델일 수도 있죠.
00:08:32어느 쪽이든 다중 에이전트 오케스트레이션이 필요하며 그래프 엔지니어링이
00:08:37매우 유용하게 쓰이는 시나리오입니다. 세 번째는 속도입니다. 작업을 얼마나 빠르게 완료해야 할까요?
00:08:44이 경우 그래프 엔지니어링 기반 자동화를 적용하는 것이 아주 타당합니다. 단일 에이전트가
00:08:48유튜브를 보고, 그다음 트위터를 보고, 레딧을 보고, 지메일을 보게 할 이유가 없기 때문입니다.
00:08:52클로드 코드도 그런 식으로 동작하지 않습니다. 딥 리서치 같은 기능을 실행할 때
00:08:57모든 정보 출처를 하나씩 순차적으로 조사하던가요? 아닙니다. 수십, 수백 개의
00:09:02서브 에이전트를 동시에 투입하여 처리합니다. 실제로 클로드 코드가 울트라 코드나
00:09:08동적 워크플로우를 사용할 때 생성하는 거의 모든 시스템은 그래프 엔지니어링 형태를 띱니다.
00:09:13여러 에이전트가 정보 수집을 담당하고, 여러 에이전트가 종합을 담당하며,
00:09:17수집된 정보에 대해 비판적 검토(Adversary review)를 수행하는 여러 에이전트가 존재합니다.
00:09:23이러한 복잡한 설정에서 단일 루프에만 의존하는 경우는 없습니다. 대신 루프 형태의 에이전트들이
00:09:28연결된 구조입니다. 하지만 처음에 말씀드렸듯이 대부분의 작업은 이 세 가지
00:09:34범주에 해당하지 않습니다. 해당하지 않는다면 굳이 그래프 엔지니어링을 쓸 이유가 없습니다.
00:09:39도구함에 들어 있는 여러 도구 중 하나일 뿐이죠. 필요한 경우도 있고 아닌 경우도 있지만, 적용 시의 장점은 명확합니다.
00:09:44반면에 단점도 있습니다. 굳이 필요하지 않은 작업에 괜히 복잡한 단계와
00:09:48인프라를 추가하게 될 수 있다는 점이죠. 이것으로 그래프 엔지니어링에 관한
00:09:52이야기를 마치겠습니다. 그래프 엔지니어링이 실제로 무엇인지 이해하는 데 도움이 되었기를 바랍니다.
00:09:57앞으로 이 개념에 대해 자주 듣게 되실 겁니다.
00:10:01하지만 루프 엔지니어링을 이해하고 계신다면, 루프 엔지니어링을 실행하는 여러 에이전트가
00:10:07함께 작동하며 서로 소통하는 구조라고 생각하시면 됩니다. 이는 품질을 높여주고
00:10:12처리 속도를 빠르고, 어느 지점에서 문제가 발생하는지 파악하기 쉽게 만들어 줍니다.
00:10:17특정 작업에 이 기술이 필요한지 판단이 안 서신다면, 아마 필요 없을 가능성이 높습니다.
00:10:24언제나처럼 의견을 댓글로 남겨주세요. 저의 클로드 코드 마스터클래스를 듣고 싶다면
00:10:27Chase AI Plus를 확인해 보세요. 아래에 링크를 남겨두겠습니다. 그럼 다음 영상에서 뵙겠습니다.