그래프 엔지니어링 뜻과 한계: AI 에이전트 오케스트레이션 유행어를 차분하게 정리했다

핵심 메시지

• '루프 엔지니어링은 죽었다, 그래프 엔지니어링이 왔다'는 말은 본래 용어가 너무 빨리 바뀌는 세태를 비꼰 농담에서 출발했다.
• 그래프는 루프를 포함하는 상위 개념이므로 둘을 대립시키는 비교는 적절하지 않다.
• 체이닝·라우팅·병렬화·오케스트레이터 같은 패턴은 이미 2024년에 정리된 것들로, 개념 자체는 새롭지 않고 다만 훨씬 쉬워졌을 뿐이다.
• 같은 모델을 쓰는 에이전트 20개는 같은 잘못된 맥락을 읽고 사이좋게 동의하며 '아주 잘 정돈된 헛소리'를 대량 생산할 수 있다.
• 확률적인 에이전트에 맡길 부분과 지루하더라도 결정적으로 남겨둘 부분을 가르는 판단이 오래 가는 실력이다.

쉽게 이해하기

AI 업계에서 용어가 바뀌는 속도는 유별나다. 프롬프트 엔지니어링이 컨텍스트 엔지니어링이 되고, 다시 하니스 엔지니어링, 루프 엔지니어링을 거쳐 이제 '그래프 엔지니어링'이 등장했다. 영상 진행자는 이 흐름을 촉발한 화제의 게시물들이 실은 이름이 너무 빨리 바뀌는 세태를 비꼰 농담이었다고 짚는다. 다만 농담이 널리 퍼진 데에는 그럴 만한 실체가 있다고 덧붙인다.

먼저 루프란 무엇인가. 모델에게 한 번 묻고 답을 받는 대신, 목표를 향해 움직이는 에이전트와 결과를 검사하는 외부 검증자, 그리고 멈출 조건을 두는 구조다. 테스트가 통과할 때까지 스스로 고치게 만드는 식이다. 핵심은 사람을 검토자 자리에서 빼내 일을 줄이는 데 있다.

그래프 이야기는 루프 하나로 부족할 때 시작된다. 예를 들어 코드 변경이 올라오면 여러 감사 에이전트를 병렬로 띄우고, 그 결과를 검증자가 모으고, 확인된 문제는 수정 담당에게 넘긴 뒤 테스트를 돌린다. 실패하면 앞 단계로 되돌아가고 통과하면 배포된다. 사람 여러 명이 서로 넘기고 검토하며 일하는 익숙한 구조이며, 그것을 그림으로 그리면 곧 그래프다.

그렇다면 왜 지금 이 이야기가 나올까. 진행자는 그래프의 각 노드 안에 무엇이 들어 있는지가 달라졌기 때문이라고 설명한다. 일반적인 파이프라인의 한 단계는 정해진 규칙을 따르지만, 에이전트는 지시를 해석하고 실행할 때마다 다르게 판단할 수 있다. 그동안은 이 모든 것을 하나의 거대한 대화창 안에 숨겨두고 모델이 스케줄러이자 데이터베이스이자 관리자 역할을 겸하게 했는데, 작업이 며칠에 걸치고 저장소 여러 개와 에이전트 여러 개로 번지면 그 방식은 무너진다.

그래프를 그린다는 것은 무엇을 병렬로 돌릴지, 노드 사이에 어떤 상태가 오갈지, 누가 결과를 거부할 권한을 갖는지, 멈추기 전까지 비용이 얼마나 드는지를 미리 정하는 일이다. 이 질문들은 늘 있었지만 채팅창은 그 결정을 미루기 쉽게 만들었을 뿐이다.

주요 인사이트

• 에이전트를 늘리는 것만으로는 품질이 오르지 않는다. 모델은 자기 답을 선호하는 경향이 있어, 같은 모델 기반 검토자끼리는 서로의 오류에 동의하기 쉽다.
• 판정 체계를 만들 때는 서로 다른 모델과 깨끗한 맥락을 가진 검토자를 섞고, 중요한 반영 직전에는 사람이 한 번 확인하는 단계를 남겨두는 편이 안전하다.
• 그래프 바깥에 최소 한 가지는 결정적인 장치를 둬야 한다. 규칙 기반 검사, 사람의 확인, 혹은 비용 같은 실제 지표처럼 시스템 외부에서 오는 검증이 있어야 부실한 결과물만 대량 생산하는 사태를 막을 수 있다.
• 유행어에 반응해 곧바로 40개짜리 에이전트 그래프를 밤새 돌리는 것은 토큰 한도만 소진하는 지름길이다. 반복되는 작업 하나, 실제로 작동하는 검증자 하나, 예측 가능한 상태 하나에서 시작하는 편이 낫다.
• 그래프를 키울수록 사람은 그 안에서 빠져나오게 된다. 그럴수록 통제권을 어디에 남겨둘지 의식적으로 정해야 한다.

자주 묻는 질문

관련 AI 소식