루프 엔지니어링(Loop Engineering)의 전성기, 딱 6주였나 봅니다.

이제 AI 개발자들은 각각의 루프를 서로 연결해서 ‘더 큰 시스템’을 만들고 있습니다. 그리고 이걸 ‘그래프 엔지니어링(Graph Engineering)’이라고 부르고 있어요.

지난 7월 18일, 피터 스타인버거(Peter Steinberger)가 X에 이런 질문을 던졌습니다.

그리고 바로 몇 시간 뒤에 하멜 후세인(Hamel Husain)이 마치 신문에 실리는 부고처럼 “루프 엔지니어링은 죽었다. 그리고 그래프 엔지니어링이 등장했다”고 선언했습니다.

일요일이 되자 타임라인에는 벌써 그래프 엔지니어링에 대한 강의와 로드맵, 툴 스택 들이 쏟아졌고, 마이크로소프트와 스탠포드, 앤트로픽에서 동시에 그래프 엔지니어링을 이야기하고 있다는 스레드도 줄줄이 올라왔고요.

그런데, 잠깐만요.

‘루프 엔지니어링’이라는 말 자체가 세상에 나온 지 이제 겨우 6주 남짓입니다 - 이 용어를 널리 알린 애디 오스마니(Addy Osmani)의 에세이가 나온 날이 6월 7일이었으니까요.

그 글도 완전히 새로운 개념을 발명한 것은 아니긴 했죠. 스타인버거가 이미 언급했던 슬로건과 Claude Code를 만든 보리스 체르니(Boris Cherny)의 말에서 출발한 것이었어요. 체르니는 “나는 이제 Claude에게 프롬프트를 쓰지 않습니다”라고 했는데, 그건 자기 일이 프롬프트를 쓰는 게 아니라, 그 일을 대신해 줄 ‘루프’를 만드는 것이라는 얘기였구요.

이 아이디어 자체는 좋습니다. 사실 과학이나 소프트웨어 개발에서는 이미 꽤 익숙한 방식이기도 하고요. 에이전트에게 매 순간 뭘 해야 할지 일일이 지시하는 대신에, 목표 하나와 스스로 결과를 점검할 방법, 그리고 일이 끝날 때까지 반복할 수 있는 사이클 하나를 쥐여주는 겁니다.

문제는 업계 대부분이 아직 ‘루프 엔지니어링 해설서’를 다 쓰기에도 짧은, 단 6주가 지났을 뿐인데, 벌써 다음의 전문 용어가 등장했다는 겁니다.

물론, 피터는 일종의 장난을 치고 있는 거라는 건 알아요. 하지만 그 농담을 한 겹 걷어내고 보면 꽤 흥미로운 변화가 하나 보입니다.

먼저, 루프가 뭔가 생각해 보면, ‘에이전트가 일을 처리하는 기본 사이클’이라고 보면 됩니다. 다음에 할 일을 찾고, 계획을 세우고, 실행하고, 결과를 확인합니다. 그 다음에 계속할지 멈출지를 정하죠.

해야 할 작업이 복잡하지 않을 때는 이 정도만으로 충분합니다.

그런데 일이 조금만 복잡해지면 상황이 달라집니다. 어떤 작업은 여러 갈래를 동시에, 그러니까 병렬로 처리해야 합니다. 어떤 단계에서는 코딩 모델이 필요하고, 다른 단계에서는 검색이 필요하죠.

한 에이전트가 답을 내놓으면 다른 에이전트가 그 답을 반박해 보기도 합니다. 어떤 결정은 자동으로 처리해도 되지만, 어떤 결정은 반드시 사람의 승인을 받아야 하고요.

여기까지 오면 루프를 잘 만드는 것만으로는 부족합니다. 서로 다른 조각을 어떤 순서로, 어떤 조건에 따라 연결할지도 정해야 하니까요.

그 더 큰 구조가 바로 ‘그래프’라고 생각하면 됩니다.

이게 아주 낯선 구조는 아닙니다. 그래프는 노드(node), 엣지(edge), 상태(state)로 이루어진다는 거, AI나 데이터 엔지니어링에 관심이 있으신 분이라면 많이 들어보셨을 거예요.

노드는 하나의 작업 단위입니다. 에이전트일 수도 있고, 모델 호출이나 코드 한 조각, 또는 사람의 결정일 수도 있습니다. 엣지는 그 다음에 어떤 일이 일어날지를 정합니다. 상태는 한 단계에서 다음 단계로 필요한 정보를 전달하고요.

그러고 보면 조금 웃기기도 한데, 루프도 사실 그래프잖아요? 다만, 경로가 앞선 노드로 되돌아오는 형태의 그래프일 뿐이죠.

게다가 지금까지 이야기한 모든 게 소프트웨어 엔지니어링의 영역에서는 새로운 개념이 아닙니다. 상태 기계(state machine), DAG, 워크플로우 엔진, 오케스트레이션 시스템은 수십 년 동안 이런 작업을 여러 가지 형태로 처리해 왔어요. LangChain도 2024년 1월, 개발자가 상태를 유지하는(stateful) 에이전트 워크플로를 만들 수 있도록 하겠다고 내놓은 게 바로 LangGraph구요.

그렇다면 뭐가 달라진 걸까요?

제가 보기에는, 핵심은 ‘그래프 자체’가 아니라 이 구조 안에서 ‘모델에게 어떤 역할을 맡길 것인가’에 있습니다.

초기 에이전트 시스템은 모델에게 거의 모든 것을 맡기는 경우가 많았습니다. 다음에 뭘 할지 정하고, 도구를 고르고, 결과를 해석하고, 계획을 수정하고, 멈출지 말지까지 판단하게 했죠.

데모에서는 이 방식이 꽤 멋지게 작동하고 쓸만하게 보여요. 그렇지만, 실제 프로덕션의 길고 복잡한 워크플로에 적용하기 시작하면, 그에 못지않게 다양한 실패 방식도 함께 드러나게 됩니다.

에이전트는 별다른 이유 없이 같은 루프를 반복하기도 하고, 꼭 지켜야 할 비즈니스 로직을 건너뛰거나 상태를 놓치는 일도 있어요. 도구가 쏟아낸 출력값으로 컨텍스트 창을 가득 채워버리기도 하고요.

구글은 Agent Development Kit(ADK) 2.0을 설명하면서 이 문제를 이렇게 정리합니다. 어떤 순서로 움직일지, 어떤 조건에서 다음 단계로 넘어갈지가 이미 정해져 있는 일은 코드로 처리하고, 상황을 해석하거나 판단해야 하는 부분만 모델에 맡기라는 겁니다. 예를 들어서 “검토가 끝나면 승인 단계로 넘어간다”는 규칙은 코드가 처리하고, “이 결과에 문제가 있는가?”처럼 맥락을 읽어야 하는 질문은 모델이 판단하는 식이죠.

돌이켜 보면 너무나 당연한 이야기입니다. 하지만 에이전트가 처음 주목받기 시작했을 때는 모델이 다음에 할 일을 고르고, 도구를 선택하고, 계획을 바꾸고, 언제 멈출지까지 스스로 결정해야 제대로 된 에이전트라고 여기는 분위기가 있었습니다. 그러다 보니 모델의 판단이 꼭 필요한 부분 뿐 아니라, 정해진 규칙대로 처리하면 되는 과정까지 모델에 맡기게 됐어요.

앤트로픽도 같은 문제를 조금 다른 방식으로 풀고 있습니다. Claude Code의 다이내믹 워크플로우(dynamic workflows)는 Claude에게 자바스크립트로 작업 진행 방식을 짜게 합니다. 어떤 작업을 동시에 진행할지, 각각의 작업을 어떤 서브에이전트에게 맡길지, 나온 결과를 어떤 순서로 모을지 등을 먼저 코드로 만드는 겁니다.

이렇게 해두면 Claude가 작업을 진행하는 내내 “다음에는 뭘 하지?”라고 되풀이해서 판단할 필요가 없습니다. 처음에 Claude가 전체 진행 방식을 짜더라도, 실제 작업이 시작된 뒤에는 미리 만들어둔 코드에 따라 움직이니까. 모델을 불필요하게 여러 번 호출하지 않아도 되니까 토큰을 아낄 수 있고, 작업이 어떤 순서로 진행될지도 훨씬 쉽게 파악할 수 있습니다.

이런 방식이 ‘그래프 엔지니어링’의 가장 현실적인 모습에 가깝습니다. 중요한 건 에이전트에 더 많은 자유를 주는 게 아니라, 모델이 판단해야 할 부분과 코드가 책임져야 할 부분을 제대로 나누는 겁니다. 상황에 따라 해석이 달라질 수 있는 일은 모델에 맡기고, 반드시 지켜야 하는 순서와 규칙은 코드로 확실하게 잡아두는 거죠.

이렇게 보면 모델은 모든 과정을 혼자 이끄는 존재라기보다, 더 큰 시스템 안에서 판단이 필요한 일을 맡는 구성 요소에 가깝습니다. 그러니까, 시스템을 믿고 쓸 수 있게 만들려면 프롬프트만 잘 작성해서는 부족합니다. 작업을 어디로 보낼지, 앞 단계에서 나온 정보를 어떻게 다음 단계로 넘길지, 결과가 제대로 나왔는지 어떻게 확인할지, 중간에 문제가 생기면 어떻게 수습할지까지 함께 설계해야 합니다.

프롬프트는 여전히 중요합니다. 단지 이제는 프롬프트 자체를 잘 만드는 것만큼, 그 프롬프트가 제대로 작동할 수 있는 환경을 함께 만드는 일이 중요해지고 있다는 겁니다.

여기서부터 이야기가 조금 복잡해지는데, 모두 그래프를 이야기하고 있지만, 정작 같은 그래프를 뜻하는 건 아니기 때문입니다.

가장 먼저 떠올릴 수 있는 건 컨트롤 그래프(control graph)입니다. 워크플로우가 어떤 단계로 이루어져 있는지, 어떤 조건에서 다음 단계로 넘어가는지를 나타낸 구조입니다. 쉽게 말해서, 일이 어떤 순서와 규칙에 따라 진행되는지를 그려놓은 지도같은 거죠.

다른 맥락에서는, 그래프가 지식 그래프(knowledge graph)를 뜻하기도 합니다. 정보를 개체(entity)와 그 사이의 관계(relationship)로 정리하는 방식이고, 마이크로소프트의 GraphRAG가 여기에 해당합니다. GraphRAG는 문서에서 개체와 관계를 찾아 그래프로 만든 뒤에, 필요한 정보를 검색할 때 그 구조를 활용합니다.

실행 트레이스(execution trace)를 그래프라고 부르는 경우도 있고요. 에이전트가 한 번 작업을 수행하는 동안 어떤 도구를 사용했고, 어떤 판단을 거쳤고, 어느 단계에서 문제가 생겼는지를 보여주는 실행 기록입니다.

‘Intuition Machine’의 카를로스 페레즈(Carlos Perez)는 지난 주말에 또 다른 해석을 내놓았는데, ‘시스템을 개선하는 여러 루프를 하나의 그래프로 보자’는 겁니다. 하나의 루프는 특정한 지표를 높여 주고, 다른 루프는 그 과정에서 나빠질 수 있는 견제 지표(counter-metric)를 살펴 보고요. 또 다른 루프는 애초에 정한 지표가 우리가 이루려는 진짜 목표를 여전히 제대로 보여주고 있는지 점검하는 식으로요.

이런 구조는 자가 개선 시스템에서 특히 중요합니다. 하나의 수치를 높이는 데만 집중하다 보면, 그 수치가 처음 목표와는 점점 멀어지더라도 시스템이 계속 같은 방향으로 치고나갈 수 있을 테니까요. 다시 말해서, 개선하는 루프만 있고 제대로 가고 있는지 확인하는 루프가 없다면 시스템은 엉뚱한 결과를 누구보다 잘 만들어내게끔 발전할 수도 있을 테니, 그걸 막자는 겁니다.

이 그래프들은 모두 여러 구성 요소가 서로 연결되어 있다는 공통점이 있고, 그래서 연결된 구조만 있다면 누구든 거기 ‘그래프’라는 이름을 붙일 수 있죠. 하지만 그 공통점을 빼고 보면, 각각은 전혀 다른 문제를 다루고 있습니다.

그러던 중에, Sprytix라는 개발자 계정이 올린 X 스레드가 빠르게 퍼졌는데요. 마이크로소프트와 스탠포드, 앤트로픽이 그래프 엔지니어링으로 RAG를 대체했고, 그 결과로 정확도는 18% 높아지고 비용은 85% 낮아졌다는 주장이었습니다. 하지만 출처를 따라가 보면, 이 수치는 세 조직의 공통된 성과가 아니라 특정 산업용 도면을 대상으로 한 별도의 GraphRAG 연구에서 나온 거였습니다.

결론부터 말하면, 이 주장은 사실이 아닙니다.

문제의 성능 수치는 ‘특정한 자료와 용도를 대상으로 진행한 연구’였어요. 그런데 이 특정한 환경에서의 결과가 순식간에 어디에나 적용할 수 있는 일반 법칙처럼 포장돼버린 거예요.

하나씩 살펴보면 더 분명합니다. 마이크로소프트는 GraphRAG를 RAG를 대체하는 기술이 아니라, RAG를 구현하는 한 가지 방식으로 설명하죠. 스탠포드의 DSPy는 언어 모델을 활용하는 프로그램을 최적화하는 도구지, 지식 그래프를 만드는 시스템이 아닙니다. 앤트로픽도 ‘그래프 엔지니어링’이라는 이름의 분야나 제품을 발표한 적이 없고요.

결국 이 주장을 뒷받침한다는 근거는 고객 사례 하나와 MCP, 여기에 꽤 후한 해석을 보태 만든 이야기에 가깝습니다.

성격이 다른 세 갈래의 작업을 하나로 엮은 뒤에, 마치 업계 전체가 같은 방향으로 움직이기 시작한 것처럼 보여준 셈이라고 봅니다. 안드레 카파시(Andrej Karpathy)가 앤트로픽에 합류한 뒤에 새로운 용어를 만들어주는 일을 그만두면서, 피터 스타인버거(Peter Steinberger)가 그 역할을 이어받은 걸까요?

물론 농담으로 던진 말에 지나치게 무거운 책임을 물을 필요는 없지만, 수많은 팔로워가 무심코 던진 표현 하나까지 다음에 올 업계 트렌드로 바꿀 준비를 하고 있다면, 새로운 이름을 붙이는 일에도 어느 정도 책임이 따라야 합니다.

그럼 다시 그래프 엔지니어링 이야기로 돌아가 볼까요? 누군가 “그래프 엔지니어링을 도입했더니 정확도가 18% 높아졌다”고 말한다면 세 가지만 물어보면 됩니다: 어떤 종류의 그래프인지, 뭐하고 비교해서 18% 높아졌다는 건지, 그리고 그 수치는 정확히 어디에서 나온 건지 말이죠.

이 세 가지 질문만으로도 ‘그래프 엔지니어링’이라는 이름으로 돌아다니는 주장 가운데 놀랄 만큼 많은 부분을 걸러낼 수 있을 겁니다.

새로운 엔지니어링 용어가 등장하면, 지금 있는 에이전트를 모두 작은 분산 시스템으로 다시 만들고 싶은 마음이 들기 마련입니다.

하지만 그럴 필요 없습니다.

여전히 대다수의 경우에는 모델 하나와 도구를 사용하는 루프 하나, 그리고 분명한 종료 조건만 있으면 충분합니다. 여기에 그래프 프레임워크를 추가하면 상태를 관리하고 작업 경로를 정하는 코드도 함께 만들어야죠, 디버깅해야 할 부분과 워크플로우가 망가질 수 있는 지점도 그만큼 늘어나고요.

그래프가 필요한 건 작업의 구조 자체가 복잡할 때겠죠. 여러 작업을 동시에 진행해야 한다거나, 나온 결과를 별도로 검증해야 한다거나, 단계마다 서로 다른 도구와 모델을 사용해야 할 때가 여기에 해당합니다. 중요한 행동을 실행하기 전에 반드시 사람의 승인을 받아야 하는 경우에도 그래프가 유용할 수 있고요.

반대로 처음부터 끝까지 순서대로 처리하면 되는 일이라면, 그냥 그렇게 두면 됩니다. 네모 상자와 화살표로 그린 복잡한 다이어그램이 있다고 해서 에이전트가 더 뛰어나지는 건 아니겠죠. 솔직히, 상당수의 경우에는, ‘내가 직접 만들어낸 교통 체증 상황’을 그냥 보기 좋게 그려놓은 것에 불과할 수도 있으니까요.

물론, 이런 용어들이 가리키는 방향만큼은 분명합니다.

에이전트를 만드는 일은 계속 프롬프트의 외연으로 넓어지고 있습니다. 개발자들의 관심은 프롬프트를 잘 쓰는 것에서 필요한 정보를 제대로 구성하는 것으로, 다시 모델이 안정적으로 일할 수 있는 하네스(harness)와 루프를 만드는 것으로 옮겨왔습니다. 이제는 모델과 도구, 평가자(evaluator), 코드, 그리고 사람의 판단을 어떤 구조로 연결할 것인지에 더 많은 관심이 쏠리고 있는 거죠.

벌써 누군가는 ‘메타그래프 엔지니어링(metagraph engineering)’이라는 말까지 제안했다는데... 인터넷은 역시 이런 데서 아주…빨라요. ^.^

이름은 아마 또 바뀌겠지만, 우리가 풀어야 할 문제는 그대로 남습니다. 일을 어떻게 나눌지, 작업이 진행되는 과정을 어떻게 통제할지, 모델이 내놓은 주장과 결과를 어떻게 독립적으로 검증할지, 다음 단계에 필요한 정보를 어떻게 보존할지, 그리고 사람이 결정해야 할 일은 어떻게 계속 사람의 손에 남겨둘지에 관한 문제 말이예요.

루프는 이 시스템을 이루는 한 부분이고, 그래프는 나머지 구조까지 함께 볼 수 있게 해주는 하나의 방법일 뿐입니다. 우리가 지금 어디쯤 와 있는지, 다음에는 뭘 만들어야 하는지 알아가는 동안, 새로운 용어는 앞으로도 계속 등장할 겁니다.