지난달 AI 트위터에 아홉 단어짜리 트윗 하나가 올라왔습니다. OpenClaw를 만든 피터 스타인버거가 던진 말이었고, 순식간에 260만 조회수를 찍었죠. 곧이어 AI 평가 분야로 유명한 하멜 후사인이 여기에 한 문장을 더 얹었습니다. “루프 엔지니어링은 죽었다. 그래프 엔지니어링이 왔다.” 그 순간 모두의 피드에 새로운 학문 하나가 탄생한 것처럼 보였던 겁니다.

AI 콘텐츠 크리에이터 루이프랑수아 부샤르는 이 소동을 다룬 글에서 반전 하나를 짚었습니다. 두 트윗 모두 농담이었다는 겁니다.

출처: Graph Engineering Explained: What Actually Changed – What’s AI (Louis-François Bouchard), The Current State of Agentic AI – MachineLearningMastery.com

이름은 자주 바뀐다, 프롬프트 엔지니어링부터 루프 엔지니어링까지

부샤르에 따르면 스타인버거가 원래 하려던 말은 “우리가 용어를 얼마나 빨리 갈아치우는지 보라”는 자조 섞인 농담이었습니다. 프롬프트 엔지니어링이 컨텍스트 엔지니어링이 되고, 그다음엔 하네스 엔지니어링, 그다음엔 루프 엔지니어링으로 이름이 바뀌어 왔죠. 대부분 같은 걸 가리키는 말이었습니다. 그런데 농담이 진짜처럼 퍼진 이유는, 그 안에 실제로 뭔가 짚이는 구석이 있었기 때문입니다.

루프란 원래 이런 구조입니다. 에이전트 하나가 목표를 향해 움직이고, 외부 검증자가 결과를 확인하고, 실패하면 다시 돌려보내고, 조건이 맞으면 멈추는 것. 하나의 루프는 하나의 일만 하죠. 이 루프 하나로 안 되는 작업이 나오기 시작하면서 그래프라는 말이 등장했습니다. 코드를 하나 고쳤을 때, 여러 검토 에이전트가 동시에 병렬로 살펴보고, 그 결과가 검증자 하나로 모이고, 문제가 확인되면 수정 담당에게 넘어가고, 테스트를 통과하지 못하면 다시 앞으로 돌아가는 식입니다. 사람 여러 명이 일을 나눠서 주고받는 구조, 그게 그래프인 겁니다.

그래프 구조 자체는 10년 전부터 있었다

부샤르가 짚는 진짜 문제는 여기서부터입니다. 이 그래프라는 개념 자체가 새롭지 않다는 것. 앤트로픽이 2024년에 낸 “Building Effective Agents” 글에 체이닝, 라우팅, 병렬화, 오케스트레이터-워커 같은 패턴이 이미 다 나와 있죠. 이런 패턴을 화이트보드에 그려보면 그 자체가 그래프입니다. 조금 더 시야를 넓히면 워크플로우 엔진이나 DAG 스케줄러, 상태 머신이 하던 일과도 다르지 않고요. 에어플로우 같은 도구는 이미 10년째 작업들의 그래프를 그려왔는데, 그 도구들이 지금 나온 에이전트 프레임워크보다 오히려 훨씬 검증된 상태입니다.

그렇다면 지금 와서 왜 이 이야기가 다시 화제가 됐을까요. 답은 그래프의 각 노드 안에 무엇이 들어있느냐에 있습니다. 평범한 파이프라인의 한 단계는 정해진 규칙만 따르죠. 반면 에이전트는 자기 작업을 스스로 해석합니다. 그래서 지시를 잘못 읽거나, 다음번엔 다른 판단을 내릴 수도 있는 것.

얼마 전까지는 이 모든 걸 하나의 거대한 채팅 맥락 안에 욱여넣고, 모델 혼자서 스케줄러 역할도 데이터베이스 역할도 로그 역할도 프로젝트 매니저 역할도 겸하게 만들었습니다. 작은 작업이라면 이렇게 해도 그럭저럭 굴러가죠. 문제는 작업이 몇 시간씩 걸리고, 여러 저장소를 넘나들고, 여러 에이전트가 얽히기 시작하면 이 방식이 무너진다는 것입니다. 그래프를 그려보는 일은 결국 무엇이 병렬로 돌아가고, 어떤 상태가 노드 사이를 오가고, 누가 결과에 거부권을 행사할 수 있고, 비용은 어디서 멈추는지를 미리 정해두라는 요구죠. 이 질문들은 예전부터 있었는데, 채팅창 안에 다 몰아넣다 보니 계속 뒤로 미룰 수 있었던 것뿐입니다.

모델이 스스로 생각하면서, 개발자의 일도 바뀌었다

비슷한 시기에 MachineLearningMastery에 실린 글은 이 변화를 다른 각도에서 설명합니다. 1년 전만 해도 에이전트를 만드는 주된 방식은 무식하게 오케스트레이션을 손으로 짜는 것이었죠. 개발자가 직접 ReAct 루프를 구성해서, 모델이 계획하고, 스스로 결과를 비판하고, 다시 시도하도록 코드로 강제했습니다. 이렇게 해야 했던 이유는 모델 혼자서는 이 반성과 재시도 과정을 할 수 없었기 때문입니다.

지금은 다릅니다. 최신 모델들은 답을 내놓기 전에 내부적으로 여러 갈래의 풀이를 탐색하고 스스로 틀린 부분을 고치는 과정을 모델 자체 안에서 처리하죠. 겉으로 드러나지 않는 추론 토큰을 생성하면서요. 예전엔 이 과정을 흉내 내려고 외부에 짜 넣었던 코드가, 이제는 대부분 필요 없어진 셈입니다. 그래서 개발자가 신경 써야 할 지점도 옮겨갔습니다. 모델이 알아서 생각하게 만드는 일보다, 여러 에이전트 사이의 라우팅과 상태 관리, 그리고 에이전트가 실제로 작업할 실행 환경을 설계하는 일이 더 중요해진 것.

이렇게 여유가 생긴 자리에, 하나의 거대한 에이전트에 온갖 도구를 다 붙이는 대신 작은 전문 에이전트 여러 개로 쪼개는 흐름이 들어섭니다. 사용자의 요청을 이해해서 어디로 보낼지 정하는 담당, 데이터베이스 스키마만 아는 담당, 격리된 환경에서 데이터 변환만 처리하는 담당 같은 식이죠. 역할을 쪼갠다고 복잡함이 사라지는 건 아닙니다. 다만 그 복잡함이 각각 따로 테스트하고 교체할 수 있는 단위로 나뉘면서, 이전에는 없던 방식으로 다루기 쉬워지는 겁니다.

화려한 이름에 속지 않으려면

부샤르는 여기에 경고 하나를 덧붙입니다. 에이전트가 다른 에이전트를 검토하는 구조는 실제로 잘 작동할 때도 있지만, 잘못되면 그럴듯하게 보이는 헛소리를 대량으로 찍어낼 수도 있다는 것. 그래서 시스템 바깥에서 오는 증거, 즉 실제 테스트와 실제 비용, 실제 사람의 판단이 여전히 필요하다고 짚습니다.

결국 “루프냐 그래프냐”는 애초에 대결 구도로 놓을 질문이 아니었습니다. 그래프는 루프를 담고 있는 더 큰 그릇일 뿐이고, 이름이 유행을 타는 동안 진짜로 옮겨간 건 따로 있었죠. 모델이 스스로 판단하기 시작하면서, 개발자가 손으로 짜야 했던 부분이 “생각하는 법”에서 “여러 에이전트를 조율하는 법”으로 이동했다는 것. 다음에 새 이름이 등장하면, 그 이름 자체보다 무엇이 실제로 달라졌는지부터 확인하는 편이 낫겠습니다.