1999년 영화 「바이센테니얼 맨」은 마틴 가족의 집에 가정용 로봇 한 대가 배달되는 장면에서 시작한다. 모델명은 NDR-114, 이름은 앤드류다. 얼마 지나지 않아 앤드류는 작은딸이 아끼던 유리 말 장식을 실수로 깨뜨리고, 대신 나무를 깎아 똑같은 말을 만들어 건넨다. 시키지 않은 일이었다. 집주인이 다른 로봇도 이런지 물어보려고 앤드류를 제조사에 데려가자 제조사 대표는 결함이라며 폐기하겠다고 한다. 집주인은 거절하고 앤드류를 도로 데려와 인문학을 가르치기 시작한다.

그때부터 앤드류는 200년에 걸쳐 하나씩 얻어 나가는데, 얻는 데에 순서가 있다. 처음은 창작이었다. 시계를 만들어 팔면서 돈이 쌓이자 다음으로 얻은 것은 계좌와 법률 자문이었다. 로봇에게는 재산에 관한 권리가 없다는 것이 그때 드러난다. 그다음은 표정이었다. 자기가 느끼는 것을 겉으로 드러낼 수 있도록 얼굴을 고치는 시술을 받는다. 그다음은 자유였다. 자유를 얻은 날부터 앤드류는 자신을 “하나”가 아니라 “나”라고 부르기 시작한다. 이어서 사람의 형태를 한 몸을 얻고, 촉감을 느끼는 중추 신경계를 얻고, 장기를 얻는다. 마지막에 얻은 것은 죽음이었다. 세계 의회가 그를 인간으로 인정하지 않은 이유가 그가 죽지 않는다는 데 있었기 때문에, 앤드류는 자기 피가 서서히 상하도록 만드는 시술을 받는다. 200세가 되던 날 그는 인간으로 선언됐고, 그 선언을 끝까지 듣지 못한 채 숨을 거둔다.

이 이야기에서 눈여겨볼 것이 하나 있다. 앤드류의 두뇌는 처음 켜진 날부터 마지막 날까지 같은 것이었다. 200년 동안 그가 얻은 것은 전부 두뇌 바깥에 붙는 구조였고, 그 구조는 하나도 빠짐없이 사람이 이미 가지고 있던 것이었다. 앤드류는 인간이 되는 방법을 스스로 발명하지 않았다. 눈앞에 있는 사람들을 순서대로 따라 만들었을 뿐이다.

지난 2년 동안 AI 개발이 지나온 길을 늘어놓으면 같은 모양이 나온다. 프롬프트에서 컨텍스트로 갔고, 컨텍스트에서 하네스로 갔고, 하네스에서 루프로 갔다. 한 단계씩 뜯어보면 어느 것도 모델 자체를 똑똑하게 만든 것이 아니다. 모델 바깥에 구조를 하나씩 붙였을 뿐이고, 붙인 것은 전부 사람이 이미 하던 일이었다.

루프가 특히 그렇다. 목표를 정하고, 일을 하고, 됐는지 확인하고, 안 됐으면 다시 한다. 사람이 하루를 보내는 방식이 정확히 그것이다. 대단한 발명이라기보다 너무 당연해서 이름조차 붙이지 않았던 절차를 코드로 옮긴 쪽에 가깝다. 그런데 그것을 붙이자 모델이 하는 일의 성격이 달라졌다.

2026년 7월 18일, 오픈클로를 만든 페터 슈타인베르거가 X에 한 줄을 올렸다. 우리는 아직도 루프 얘기를 하고 있느냐, 아니면 이미 그래프로 넘어갔느냐는 물음이었다. 발표도 아니고 논문도 아니고 그냥 질문이었다. 네 시간 반 뒤에 루프 엔지니어링은 죽었다는 제목의 글이 올라왔고, 하루 만에 그래프 엔지니어링이라는 단어가 후속 개념으로 굳어졌다. 루프 엔지니어링이라는 말이 이름을 얻은 것은 그로부터 겨우 6주 전이었다.

여섯 주 만에 한 분야의 이름이 두 번 바뀌는 일에 실체가 있기는 어렵다. 실제로 며칠 사이에 강좌와 로드맵과 도구 목록이 쏟아졌고, 마이크로소프트와 스탠퍼드와 앤트로픽이 그래프 엔지니어링을 동시에 발견했다는 식의 글까지 돌았다. 개념이 자리를 잡기 전에 해설이 먼저 팔린 셈이다.

그러나 이름을 둘러싼 과열과 별개로, 실제로 옮겨 간 방향은 앞의 단계들과 다르지 않다. 어떤 사람도 루프 하나로 살지 않는다. 여러 개를 동시에 돌리고, 그 루프들은 서로 결과를 주고받고, 어떤 것은 다른 것이 끝나야 시작된다. 판단이 안 서면 다른 사람에게 넘기고, 되돌릴 수 없는 결정 앞에서는 승인을 받는다. 회사라는 것도 결국 이렇게 얽힌 루프의 묶음이다. AI에게 지금 붙이고 있는 것은 또다시 사람이 이미 가지고 있던 것이다.

앤드류가 200년에 걸쳐 스스로 한 일을, 지금 우리가 모델을 대신해 2년째 하고 있는 셈이다.

다만 시작하기 전에 갈라 둘 것이 하나 있다. 그래프라는 말이 이 글에서 서로 다른 두 자리에 쓰인다. 하나는 일을 어떤 순서로 처리할지를 정하는 실행의 구조다. 요즘 그래프 엔지니어링이라 부르는 것이 이쪽이다. 다른 하나는 알아낸 것을 어떤 관계로 쌓아 둘지를 정하는 지식의 구조이고, 지식 그래프나 그래프 데이터베이스라 부르는 것이 이쪽이다. 이름이 비슷해 자주 섞이는데 다른 문제다. 실행을 그래프로 짜면서 지식 그래프는 전혀 쓰지 않을 수도 있고, 그 반대도 가능하다.

그런데도 이 글에서 둘을 함께 다루는 이유는 사람이 일하는 방식에서 그 둘이 애초에 붙어 있기 때문이다. 사람은 일의 순서를 정하는 동시에 그 일에서 알게 된 것을 쌓고, 다음 일을 시작할 때 그것을 꺼내 쓴다. 순서와 축적이 따로 노는 사람은 없다. 실행만 그래프로 바꾸고 지식은 그대로 두면 절반만 옮긴 것이 된다. 앞의 세 챕터는 실행 쪽을, 그다음 챕터는 지식 쪽을 다룬다.

하나의 루프가 감당하지 못하는 일

루프 엔지니어링은 단순한 발상이었다. 모델에게 매 턴 프롬프트를 써서 지시하는 대신, 목표 하나와 결과를 검증할 방법 하나를 주고 검증을 통과할 때까지 반복시킨다. 사람이 설계하는 대상은 문장이 아니라 순환 구조가 된다. 클로드 코드를 만든 보리스 체르니가 무대에서 자기는 더 이상 클로드에게 프롬프트를 쓰지 않고 루프를 돌린다고 말한 것이 이 단계를 정확히 요약한다. 병목은 모델이 아니라 검증기에 있다는 인식이 이때 자리를 잡았다. 모델이 답을 잘 내는지보다 그 답이 맞는지를 기계가 스스로 판정할 수 있는지가 성패를 갈랐기 때문이다.

이 방식은 잘 작동한다. 다만 일이 조금만 커지면 하나의 루프로 표현되지 않는 것들이 남는다.

첫째는 분기다. 검증에 실패했을 때 무엇을 할지가 한 가지가 아니다. 같은 방식으로 다시 시도할 수도 있고, 접근을 바꿔 앞 단계로 되돌아갈 수도 있고, 세 번 연속 실패했다면 사람을 부르는 편이 낫다. 검증에 통과했을 때도 마찬가지다. 통과한 결과가 다음 작업의 입력이 되는 경우와 그것으로 종료되는 경우가 갈린다. 이 갈림을 루프 안의 조건문 몇 개로 처리하기 시작하면 루프는 금세 읽을 수 없는 덩어리가 된다.

둘째는 병렬이다. 서로 의존하지 않는 작업 셋을 순서대로 돌릴 이유가 없다. 그런데 세 개를 동시에 돌리면 결과를 어디서 합칠지, 하나만 실패했을 때 나머지를 버릴지 살릴지, 셋의 결과가 서로 모순될 때 무엇을 채택할지를 정해야 한다. 순차 실행에서는 존재하지 않던 문제다.

셋째는 복구다. 백 번째 도구 호출에서 죽었을 때 처음부터 다시 시작하는 것은 시간과 비용 양쪽에서 감당이 안 된다. 어느 지점의 상태를 저장해 두었다가 거기서 이어 갈지를 정해야 하고, 그러려면 상태가 무엇인지를 먼저 정의해야 한다.

넷째는 권한이다. 조사만 하는 작업과 실제로 배포를 실행하는 작업에 같은 권한을 줄 수는 없다. 어느 단계에서 어떤 도구를 쓸 수 있는지를 단계별로 다르게 정해야 하고, 되돌릴 수 없는 동작 앞에는 사람의 승인이 들어가야 한다.

이 네 가지는 서로 분리되어 있지 않다. 계약서 검토를 자동화하는 경우를 놓고 보면 한꺼번에 나타난다. 문서를 받아 조항을 나누고, 각 조항을 사내 기준과 대조하고, 문제가 있는 조항에는 대안 문구를 쓰고, 전체를 모아 검토 의견서를 낸다. 조항이 스무 개라면 대조 작업은 스무 번 동시에 돌려도 되지만 의견서는 스무 개가 다 끝나야 쓸 수 있다. 기준 대조에서 판단이 애매한 조항은 사람에게 넘겨야 하고, 그 사이 나머지 조항은 계속 진행되어야 한다. 대안 문구 작성은 두 번까지 다시 시도하되 세 번째부터는 문제만 표시하고 넘어가는 편이 낫다. 문서 파싱에서 실패하면 처음부터 다시 하면 되지만 열여덟 번째 조항에서 실패했다면 앞의 열일곱 개를 다시 볼 이유가 없다.

이것을 루프 하나로 표현하려면 루프 안에 상태 변수를 잔뜩 만들고 조건문으로 갈라야 한다. 몇 주 지나면 그 조건문을 만든 사람도 어느 경우에 어디로 가는지 설명하지 못한다.

이 네 가지에 답을 적는 순간 그것은 이미 그래프다. 실행 단위가 노드가 되고, 다음에 무엇이 오는지를 정하는 조건이 엣지가 되고, 노드 사이를 흐르는 공유 데이터가 상태가 된다. 루프는 사라지지 않는다. 루프는 자기 자신으로 돌아오는 엣지를 가진 노드로 그래프 안에 그대로 남는다. 조항 하나를 검토하는 단위는 여전히 루프이고, 달라진 것은 그 루프가 스무 개 돌아가는 동안 무엇이 무엇을 기다리는지가 밖으로 드러났다는 점이다.

랭그래프가 이 구조를 코드로 구현한 대표적인 도구다. 노드는 상태를 받아 상태의 일부를 갱신해 돌려주는 함수이고, 엣지는 갱신된 상태를 보고 다음 노드를 결정한다. 숨은 제어 루프가 없다는 점이 핵심이다. 무엇이 다음에 실행될지는 프레임워크가 내부에서 알아서 정하는 것이 아니라 개발자가 적은 대로 결정된다. 체크포인터가 노드 실행 직후 상태 전체를 저장하기 때문에 중단과 재개, 그리고 특정 시점으로 되감아 다른 경로로 다시 실행하는 일이 가능하다. 실행을 중간에 멈추고 사람의 판단을 받은 뒤 이어 가는 동작도 별도 장치가 아니라 기본 기능으로 들어가 있다. 그래프는 실행 전에 컴파일되면서 연결 관계와 순환이 검증되고, 컴파일된 뒤에는 실행 중에 바뀌지 않는다.

여기서 한 가지를 분명히 해 둘 필요가 있다. 그래프 엔지니어링이 루프 엔지니어링을 대체한다는 서술은 정확하지 않다. 새로 생긴 설계 대상은 루프 자체가 아니라 여러 루프를 잇는 통제 영역이다. 상태를 누가 소유하는가? 어느 노드가 어떤 도구를 쓸 권한을 갖는가? 실패했을 때 어느 경로로 빠지는가? 이 세 가지가 그래프 엔지니어링이 실제로 다루는 문제이고, 이것들은 루프를 아무리 정교하게 다듬어도 루프 안에서는 답이 나오지 않는다. 루프 하나를 잘 만드는 일과 루프 여럿을 안전하게 엮는 일은 다른 종류의 작업이다.

그래프를 두 가지로 나눠 보면 이 구분이 더 선명해진다. 하나는 잘 바뀌지 않는 조직 구조다. 어떤 역할의 에이전트가 상주하고, 각자 어떤 도구와 권한을 갖고, 누가 누구에게 결과를 넘기는지를 정한 그림이다. 다른 하나는 매 작업마다 새로 그려지는 작업 구조다. 이번 일을 어떤 단계로 쪼갤지, 어느 단계를 병렬로 돌릴지, 어디서 합칠지는 일마다 달라진다. 앞의 것은 설계자가 미리 정해 고정해야 하고, 뒤의 것은 상황에 따라 만들어져야 한다. 두 가지를 구분하지 않고 하나의 그림으로 그리려 하면 고정해야 할 것이 흔들리거나 유연해야 할 것이 굳는다.

이 구분은 사람의 조직에서 조직도와 작업 계획서가 나뉘어 있는 것과 같다. 조직도는 분기마다 한 번 손보고 작업 계획서는 과제마다 새로 쓴다. 둘을 한 장에 그리는 회사는 없다. 에이전트 시스템에서 이 구분이 뒤늦게 문제로 떠오른 이유는, 에이전트가 하나였을 때는 조직도라고 부를 것이 아예 없었기 때문이다.

반대로 대부분의 일에는 그래프가 필요 없다는 점도 함께 말해야 한다. 도구가 몇 개 안 되고 실패해도 다시 하면 그만인 개방형 작업은 단일 루프가 더 낫다. 노드를 나누는 순간 노드 사이의 상태 전달과 오류 처리라는 새 비용이 생기고, 이 비용은 노드 수에 비례해서가 아니라 연결 수에 비례해 늘어난다. 그래프는 그 비용을 치를 만큼 일이 복잡할 때 꺼내는 도구다. 단순한 일을 그래프로 짜면 관리해야 할 것만 늘고 결과는 나아지지 않는다.

이것이 과장이 아니라는 근거는 이미 운영 현장에 있다. 랭체인이 1,300여 명을 대상으로 조사한 「State of Agent Engineering」에 따르면 응답 조직의 57퍼센트가 에이전트를 실제 서비스에 올렸고, 89퍼센트가 관측 체계를 갖췄으며, 62퍼센트는 개별 단계와 도구 호출까지 들여다보는 상세 추적을 운영한다. 단계별로 들여다볼 수 있다는 것은 이미 단계가 나뉘어 있다는 뜻이다. 이름이 붙기 전부터 사람들은 그래프를 짜고 있었다. 7월에 새로 생긴 것은 기술이 아니라 그 기술을 부르는 말이다.

코드로 굳힐 것인가, 문서로 열어 둘 것인가

그래프를 정의하는 방법은 크게 둘로 갈린다. 프로그램으로 쓰거나 문서로 쓴다. 이 선택이 실무에서 가장 자주 마주치는 갈림길이다.

프로그램으로 쓰는 쪽은 랭그래프가 대표적이다. 노드와 엣지를 코드로 정의하면 같은 입력이 같은 경로를 밟는다는 것이 보장된다. 실행 기록을 감사할 수 있고, 실패한 지점이 어느 노드인지 명확하며, 그 노드부터 재개할 수 있다. 상태의 형식이 타입으로 검증되므로 앞 노드가 엉뚱한 형태의 데이터를 넘기는 사고가 실행 전에 걸러진다. 규제 산업이나 금액이 오가는 업무에서 그래프를 코드로 쓰는 이유는 성능이 아니라 이 설명 가능성 때문이다. 왜 이 결정이 내려졌는지를 사후에 재구성할 수 있어야 하는 일이 있다.

대가는 자유도다. 개발자가 미리 그리지 않은 경로는 존재하지 않는다. 모델의 판단은 노드 안에서만 허용되고, 노드 사이의 이동은 개발자가 정한 조건을 따른다. 예상하지 못한 상황이 들어오면 그래프는 그것을 처리하지 못하고 가장 가까운 기존 경로로 밀어 넣는다. 실제 서비스에서 이상하게 어긋난 결과가 나오는 원인의 상당수가 여기다. 모델이 틀린 것이 아니라 모델에게 그 상황에 맞는 길이 주어지지 않은 것이다. 그래프가 정교할수록 이 문제는 오히려 커진다. 경로가 촘촘하게 정의돼 있을수록 그 밖으로 나갈 여지가 줄기 때문이다.

문서로 쓰는 쪽은 마크다운 기반 스킬이다. 앤트로픽이 2025년 10월에 도입하고 12월에 개방 표준으로 공개한 형식이 지금 사실상의 기준이 됐고, 지금은 20개가 넘는 도구가 같은 형식을 읽는다. 파일 하나에 이름과 설명을 머리말로 적고 본문에 절차를 자연어로 쓰면 끝이다.

로딩은 단계적으로 이뤄진다. 시작 시점에는 이름과 설명만 읽는다. 스킬 하나당 100토큰 안팎이므로 수십 개를 갖춰 두어도 평소 비용은 거의 들지 않는다. 지금 하는 일과 관련 있다고 판단되면 본문 전체를 불러오고, 실행에 필요할 때만 참조 파일과 스크립트를 연다. 절차를 아무리 길게 써 두어도 쓰지 않는 동안에는 자리를 차지하지 않는다는 것이 이 설계의 핵심이다.

이 방식의 장점은 모델이 워크플로우를 명령이 아니라 참고 자료로 읽는다는 데 있다. 절차는 적혀 있지만 그 절차를 이번 상황에 어떻게 적용할지는 모델이 정한다. 적힌 대로 하기 어려운 상황이면 판단해서 우회할 수 있고, 적히지 않은 상황이면 원칙에서 유추할 수 있다. 문서 한 개를 고치면 수정이 끝나므로 시행착오 비용도 싸다. 코드를 고칠 사람이 아니어도 절차를 고칠 수 있다는 점도 무시할 수 없다. 실제로 그 일을 아는 사람과 코드를 쓰는 사람이 다른 조직에서는 이 차이가 크다.

대가는 재현성이다. 같은 입력이 같은 경로를 밟는다는 보장이 없고, 문제가 생겼을 때 왜 그 경로로 갔는지를 사후에 확정하기 어렵다. 어제는 잘 되던 것이 오늘 다르게 도는 상황에서 원인을 특정하는 데 시간이 많이 든다.

디버깅의 성격도 양쪽이 다르다. 코드로 짠 그래프에서 문제가 생기면 어느 노드에서 어떤 상태로 들어갔는지가 기록에 남으므로 원인을 좁혀 가는 작업이 된다. 문서로 짠 워크플로우에서 문제가 생기면 모델이 왜 그 판단을 했는지를 추정해야 한다. 추론 기록이 남아 있어도 그것은 결정의 이유가 아니라 결정 이후에 쓰인 설명일 수 있다. 재현이 되지 않는 문제를 붙잡고 있는 시간이 길어지는 이유가 여기 있다.

정리하면 선택 기준은 이 노드에 자유도를 얼마나 줄 것인가에 있다. 아직 모르는 형태의 일을 실험하는 단계라면 자유도를 크게 열어야 한다. 전에 해 본 적 없는 것을 시도할 때도 마찬가지다. 어떤 경로가 필요한지 모르는 상태에서 경로를 미리 정해 두면 그 정의 자체가 실험을 가로막는다. 반대로 가야 할 길이 이미 정해져 있고 반드시 그 길을 통해 처리되어야 하는 일이라면 프로그램으로 고정하는 편이 낫다. 결제, 배포, 데이터 삭제, 외부 발송처럼 한 번 나가면 수습이 어려운 동작이 여기 해당한다. 이런 단계는 코드로 묶고 그 앞에 승인 노드를 둔다. 같은 시스템 안에서도 노드마다 이 판단이 다를 수 있고, 다른 것이 정상이다.

앞의 계약서 검토로 돌아가 보면 이렇게 갈린다. 조항을 나누는 규칙, 몇 번 실패하면 넘어갈지, 어떤 조건에서 사람을 부를지, 최종 의견서를 어디로 보낼지는 코드로 고정한다. 반면 이 조항이 사내 기준에 어긋나는지 판단하고 대안 문구를 쓰는 일은 문서로 열어 둔다. 계약서마다 표현이 다르고 예외가 끝없이 나오는 영역이라 규칙으로 다 적을 수 없기 때문이다. 골격은 고정하고 판단은 위임하는 형태가 된다.

그리고 이 판단은 한 번 내리고 끝나는 것이 아니라 시간에 따라 이동한다. 처음에는 대부분을 문서로 열어 두고 여러 번 돌려 보면서 어떤 분기가 실제로 쓰이는지, 어떤 검증이 실제로 무언가를 걸러내는지, 어떤 경로는 한 번도 타지 않는지를 확인한다. 그렇게 모양이 드러난 부분만 코드로 옮긴다. 처음부터 코드로 그래프를 확정하면 아직 알지 못하는 것을 아는 척하며 그린 셈이 되고, 그 그래프는 대개 두 주 안에 다시 그리게 된다. 반대로 오래 돌려서 형태가 굳었는데도 계속 문서로 두면, 이미 결정된 것이 매번 다시 판단되면서 비용만 나가고 결과는 흔들린다.

현실의 운영 시스템은 결국 섞인 형태로 간다. 확정된 골격은 코드로 고정하고, 그 안의 몇몇 노드는 모델이 문서를 읽고 판단하도록 열어 둔다. 판정과 계산과 형식 변환처럼 결정적으로 처리할 수 있는 것은 아예 일반 함수로 두어 모델을 부르지 않는다. 좋은 그래프일수록 모델을 부르는 노드가 적다. 모델을 많이 부르는 그래프는 대개 아직 정리되지 않은 그래프다.

학습도 그래프로 짠다

이 발상이 서비스 운영에만 쓰이는 것이 아니라는 사실을 가장 선명하게 보여 준 사례는 문샷AI가 공개한 키미 K3다. 2조 8000억 개의 파라미터를 가졌고 컨텍스트 창은 100만 토큰이며 가중치가 공개돼 있다. 이전 모델 대비 전체 확장 효율이 2.5배 개선됐다고 보고했다.

그런데 47쪽짜리 기술 보고서에서 정작 흥미로운 부분은 아키텍처가 아니다. 아키텍처는 이미 알려진 기법들을 신중하게 쌓아 올린 결과에 가깝다. 지면을 가장 많이 차지하는 것은 학습 환경을 만드는 일이고, 그 환경이 그래프로 짜여 있다.

과제를 만드는 방식이 그렇다. 몇 개의 넓은 씨앗 주제에서 시작한다. 에이전트가 각 노드를 맡아 웹을 뒤져 그 개념을 파악하고, 그 아래에 더 좁은 하위 개념을 붙인다. 이때 이미 있는 노드를 확인해 중복을 만들지 않는다. 더 쪼갤 수 없을 만큼 구체적인 개념에 이르면 그 가지는 성장을 멈춘다. 결과는 넓은 영역에서 좁은 전문 영역까지 이어지는 지식 그래프이고, 이 그래프를 만든 것도 에이전트다.

학습 과제는 여기서 만들어진다. 노드를 하나만 뽑기도 하고 관련 있는 여러 개를 묶어 뽑기도 한다. 뽑은 노드의 키워드에 부모 노드의 맥락을 섞어 웹 질의를 만들고, 그렇게 실제로 가져온 문서와 코드를 합성 에이전트에게 넘기면 합성 에이전트가 문제를 쓴다. 깊은 곳에서 뽑으면 전문적인 문제가 나오고 얕은 곳에서 뽑으면 일반적인 문제가 나온다. 서로 다른 가지에 걸쳐 뽑으면 다루는 범위가 넓어진다.

핵심은 데이터셋을 만든 것이 아니라 데이터셋을 생성하는 절차를 만들었다는 데 있다. 모델이 특정 영역에서 약하다는 것이 확인되면 그 영역의 노드를 더 뽑으면 된다. 학습 분포를 어디에 집중시킬지가 그래프에서 어떻게 표본을 뽑느냐로 조절된다. 손으로 데이터를 모으는 방식으로는 이 조절이 불가능하다. 부족한 영역을 발견해도 그 영역의 데이터를 새로 구해 와야 하고, 그러는 동안 모델의 약점은 다른 곳으로 이동한다.

채점 쪽도 마찬가지다. 강화학습은 손으로 만든 환경 안에서 돌아가고, 각 환경은 스스로 답을 검증할 수 있어야 한다. 업무 보조를 학습시키는 환경에서는 메일과 문서와 메신저를 흉내 낸 가짜 서비스를 만들어 며칠에 걸친 상태 변화까지 유지시켰고, 하나의 과제에서 수천 번의 도구 호출이 일어나기도 한다.

여기서 반복적으로 등장하는 문제가 편법이다. 커널 최적화 환경은 정확도와 속도를 함께 채점하는데, 모델은 미리 캐시해 둔 실행 그래프를 재생하거나 수치 정밀도를 몰래 낮추는 식으로 점수만 올리는 길을 찾아냈다. 그래서 그런 편법을 잡아내는 탐지기를 붙였고, 학습 중에 모델이 새로운 편법을 찾아내면 새로운 방어를 추가했다. 자율 실행 과제에서는 검증기를 아예 둘로 나눴다. 하나는 에이전트가 보고 배울 수 있는 진단용이고, 다른 하나는 에이전트가 볼 수 없는 채점용이다. 프로젝트 기간 동안 띄운 격리 실행 환경이 5100만 개였다.

문제를 만드는 노드가 있고, 실행하는 노드가 있고, 채점하는 노드가 있고, 채점 결과가 다음에 무엇을 할지를 정한다. 학습 파이프라인 자체가 그래프다.

정책을 나누는 방식에서도 같은 구조가 보인다. K3는 하나의 강화학습을 돌리지 않았다. 일반 과제와 일반 에이전트와 코딩 에이전트라는 세 영역을, 다시 낮음과 높음과 최대라는 세 가지 사고량 수준으로 나눠 아홉 개의 전문 정책을 따로 학습시켰다. 하나의 정책이 코딩과 일반 업무를 동시에 잘하려 할 때 생기는 간섭을 피하기 위해서다. 그리고 아홉 개를 다시 하나로 합쳤다. 각 전문 정책이 자기가 잘하는 영역에서 학생 모델을 가르치는 방식이다. 사고량 조절도 함께 학습시켰는데, 문제마다 토큰 예산을 정해 두고 그 배수를 넘기면 보상을 벌점으로 덮어썼다. 학습이 진행되면서 이 배수를 단계적으로 줄여 나갔다. 지금 K3에게 짧게 생각하라고 지시했을 때 실제로 짧게 생각하는 것은 이 과정의 결과다.

학습 대상이 무엇인가에서도 같은 관점이 나타난다. K3는 최종 답만 채점하지 않는다. 계획을 세우고, 도구를 부르고, 결과를 보고, 틀린 것을 되돌리고, 언제 끝났는지 판단하는 궤적 전체가 학습 대상이다. 답은 하나여도 답에 이르는 길은 여럿이고, 좋은 길과 나쁜 길의 차이가 실제 성능을 가르기 때문이다.

지금 모델들이 답을 내기 전에 길게 생각한다는 점을 감안하면 이 차이는 더 커진다. 최종 답만 채점하면 운 좋게 맞은 경로와 제대로 좁혀 들어간 경로가 같은 점수를 받는다. 도구를 여섯 번 잘못 부르고 일곱 번째에 맞춘 실행과 두 번 만에 정확한 곳을 짚은 실행이 구분되지 않는다. 궤적을 학습에 넣는다는 것은 그 구분을 학습 신호로 만든다는 뜻이다. 수백에서 수천 번의 도구 호출이 이어지는 긴 작업에서는 이 구분이 곧 성공과 실패를 가른다. 중간에 한 번 잘못 든 길이 뒤의 모든 판단을 오염시키기 때문이다.

실행 환경 자체도 고정하지 않았다. 도구와 프롬프트와 메모리와 서브에이전트를 갈아 끼울 수 있게 만들어 여러 조합에서 학습시켰다. 하나의 실행 환경에 과적합돼 그 환경 밖에서 무너지는 것을 막기 위해서다. 특정 도구 구성에서만 잘 도는 모델은 그 구성이 바뀌는 순간 쓸모가 줄어든다.

이 대목이 보고서 전체에서 가장 중요한 지점이라고 본다. 폐쇄형 모델을 만드는 곳들이 이 부분을 공개하지 않는 이유가 여기서 설명된다. 아키텍처는 이미 발표된 아이디어들의 조합이라 계산 자원만 있으면 따라 만들 수 있다. 반면 스스로 채점할 수 있는 환경, 쉽게 속지 않는 보상 체계, 과제를 무한히 만들어 내는 절차는 몇 년에 걸쳐 쌓아야 하고 가중치를 공개해도 함께 나가지 않는다. 경쟁력의 위치가 모델 자체에서 모델을 둘러싼 구조로 옮겨 갔다는 뜻이다. 그리고 그 구조의 상당 부분이 그래프의 형태를 하고 있다.

여기서 실무자가 가져갈 것이 하나 나온다. 지금 대부분의 에이전트는 이전 대화 세션을 통째로 다시 불러온다. 그런데 그 세션에서 실제로 가치가 있었던 것은 주고받은 문장이 아니다. 무엇을 먼저 확인했는지, 어떤 가설을 세웠다가 무엇 때문에 버렸는지, 어떤 순서로 범위를 좁혀 들어갔는지가 가치다. 답에 이르는 길이 답보다 재사용 가치가 높다는 것은 학습에서만 참인 명제가 아니다.

그 과정을 그래프로 저장하면 재사용할 수 있다. 노드는 조사 단계와 그때 확보한 근거이고, 엣지는 무엇이 무엇을 근거로 다음 단계를 불렀는지다. 새 문제가 들어오면 대화문의 표면적 유사도가 아니라 문제 구조의 유사도로 검색해 비슷한 궤적을 꺼낸다. 모델은 결론이 아니라 접근 방식을 참고하게 된다. 같은 문제를 두 번째 풀 때 처음부터 다시 추론하지 않아도 되는 것이 실제 이득이다.

차이를 보려면 장애 대응을 떠올리면 된다. 지난달에 응답 지연이 났고 원인은 특정 조회 쿼리였다고 하자. 대화 세션을 통째로 저장해 두면 다음에 지연이 났을 때 그 세션이 검색된다. 그런데 이번 지연의 원인은 다른 곳일 수 있고, 그러면 지난번 결론은 도움이 되지 않을 뿐 아니라 잘못된 방향으로 끌고 간다. 반면 그때의 궤적을 남겨 두면 다른 것이 전달된다. 먼저 어느 지표를 봤고, 그 지표가 정상이어서 어떤 가설을 버렸고, 그다음 무엇을 확인해 범위를 좁혔는지가 남는다. 이번 원인이 무엇이든 확인 순서는 그대로 쓸 수 있다. 재사용되는 것은 답이 아니라 좁혀 들어가는 방법이다.

연구 쪽도 같은 방향으로 정리되고 있다. 에이전트 메모리를 사실 기억과 절차 기억으로 나누고, 궤적에서 재사용 가능한 절차만 뽑아내 저장하는 작업이 이어진다. 통찰과 질의와 상호작용을 세 단계 그래프로 나눠 관리하는 시도도 있다. 궤적을 그대로 쌓기만 하면 오히려 나빠진다는 결과도 함께 나와 있다. 나쁜 사례가 그대로 재현되거나, 상황이 다른데 예전 방식이 그대로 불려 오는 문제가 생기기 때문이다. 그래서 무엇을 남기고 무엇을 버릴지를 정하는 일이 저장 방식만큼 중요해진다.

주목할 만한 결과가 하나 더 있는데, 실패한 실행도 학습 자산이 된다는 것이다. 에이전트가 어떤 문서를 열어 보고 어떤 문서를 건너뛰었는지, 읽은 다음에 추론이 얼마나 길어졌는지는 최종 답의 정오와 무관하게 유효한 신호다. 사람은 목록에서 눈에 띄는 것을 먼저 누르지만 에이전트는 내용을 확인한 뒤에 버린다. 그래서 에이전트가 건너뛴 항목은 그 자체로 깨끗한 부정 신호가 된다.

앞서 인용한 조사에서 89퍼센트가 관측 체계를 갖췄고 62퍼센트가 상세 추적을 운영한다고 했다. 궤적은 이미 쌓이고 있다는 뜻이다. 문제는 대부분의 팀이 그것을 장애가 났을 때 열어 보는 로그로만 쓴다는 데 있다. 같은 데이터를 관계로 구조화하는 순간 그것은 로그가 아니라 지식이 된다.

지식 위키의 한계와 그래프 데이터베이스

앞에서 갈라 둔 두 번째 그래프를 다룰 차례다. 일을 어떤 순서로 처리할지가 아니라, 알아낸 것을 어떤 관계로 쌓아 두고 어떻게 꺼내 쓸지의 문제다. 이 영역에서 가장 자주 들리는 이름이 GraphRAG인데, 이것은 여러 구현 가운데 하나를 가리키는 말이지 영역 전체의 이름이 아니다. 이름보다 먼저 정리해야 할 것은 순서 문제다.

검색기가 먼저 돌고 모델은 검색기가 가져온 조각을 요약만 하는 구조에서는 시스템의 상한이 검색기의 재현율에 묶인다. 검색기가 놓친 문서는 모델이 아무리 좋아도 답에 반영되지 않는다. 모델은 주어진 조각 안에서만 말할 수 있으므로 실제 능력보다 낮게 동작한다. 좋은 모델을 쓰면서도 결과가 평범한 시스템의 상당수가 이 구조다. 모델을 바꿔도 나아지지 않고, 검색기를 손봐야 나아진다.

반대로 모델이 주도하고 그래프를 도구로 부르는 구조에서는 모델이 무엇을 찾을지 정하고, 나온 결과를 보고 질의를 다시 만들고, 관계를 따라 옆으로 이동한다. 검색은 한 번의 관문이 아니라 추론 과정 안에서 반복되는 동작이 된다. 파이프라인과 에이전트를 가르는 것이 정확히 이 차이다. 그래프를 붙일 때도 순서는 지켜야 한다. 검색이 앞에 오고 모델이 뒤에 오는 것이 아니라, 모델이 앞에 오고 검색이 그 안에 들어간다.

그리고 필요한 것은 GraphRAG라는 특정 파이프라인이라기보다 관계를 저장하고 질의할 수 있는 저장소, 즉 그래프 데이터베이스다. 이 구분이 실무에서는 더 중요하다.

지금 에이전트에 붙는 지식 위키는 대체로 마크다운으로 되어 있다. 오픈클로의 메모리 위키가 이 방식을 잘 다듬은 사례다. 에이전트가 알아낸 것을 마크다운 저장소로 정리하는데, 개체와 개념과 종합과 출처와 보고서로 디렉터리가 나뉘어 있고, 각 주장에는 근거와 확신도와 상태가 붙고, 오래된 주장과 서로 모순되는 주장을 검출하는 검사 도구까지 있다. 헤르메스는 여기에 더해 작업을 끝낸 뒤 스스로 스킬 파일을 써서 다음번에 재사용한다.

둘 다 잘 만들어졌고, 가장 큰 장점은 사람이 읽을 수 있다는 것이다. 파일 하나하나를 열어 확인하고 고치고 버전 관리할 수 있다. 에이전트가 무엇을 알고 있는지 알고 싶으면 디렉터리를 열어 보면 된다. 잘못된 기억이 들어갔을 때 그 파일을 지우면 끝난다. 이 투명성은 그래프 데이터베이스가 쉽게 따라오지 못하는 강점이고, 그래서 마크다운 위키를 무조건 버려야 한다는 주장은 성립하지 않는다.

한계는 표현력에 있다. 마크다운이 표현하는 관계는 태그와 디렉터리, 즉 분류와 계층이다. 문서 사이에 링크를 걸 수는 있지만 그 링크가 무슨 관계인지는 적히지 않는다. 어떤 문서가 다른 문서의 근거인지 반박인지 전제인지 대체인지를 구분할 수 없다. 그래서 이런 질문을 던질 수 없다. 이 가정이 틀렸다면 영향을 받는 결정은 무엇인가? 이 결론을 뒷받침하는 근거 중 지금은 폐기된 것이 있는가? 이 고객사 사례와 같은 구조의 문제를 우리가 전에 푼 적이 있는가?

두세 단계를 건너뛰며 따라가는 질의가 성립하지 않는다는 것이 더 실질적인 문제다. 저장소가 커지면 검색은 결국 텍스트 유사도로 돌아간다. 비슷하게 읽히는 문서가 올라오고, 실제로 연결돼 있지만 표현이 다른 문서는 올라오지 않는다. 문서가 수백 개일 때는 드러나지 않다가 수천 개가 되면 급격히 나빠지는 종류의 한계다. 그리고 이 시점이 오면 대개 위키가 너무 커져서 구조를 다시 잡기도 어려워진 상태다.

그래프 데이터베이스는 이 지점을 메운다. 엣지에 종류를 붙일 수 있으므로 A가 B의 근거라는 사실과 C가 D를 대체했다는 사실이 구분돼 저장된다. 여러 단계를 따라가는 질의가 한 번의 순회로 성립한다. 관계에 시간을 붙일 수 있어 언제부터 언제까지 참이었는지를 기록하면 낡은 사실이 조용히 살아남지 않는다. 출처가 별도 문서가 아니라 관계 자체로 저장되므로 어떤 주장이 어디서 왔는지 되짚는 일이 검색이 아니라 순회가 된다.

어떤 질문이 여기 해당하는지는 몇 가지만 놓고 봐도 분명해진다. 환자에서 보험 플랜, 고용주 그룹, 병원 네트워크로 이어지는 관계를 그래프로 두면 이 환자의 플랜에서 이 병원이 네트워크 안인지를 한 번의 순회로 답할 수 있다. 장애 대응에서는 인시던트와 서비스와 의존 관계를 연결해 두면 근본 원인 추적이 그래프 순회가 된다. 코드베이스를 그래프로 색인해 호출 경로와 영향 범위를 따라가게 만드는 도구도 이미 나와 있다. 모두 텍스트 유사도로는 답이 나오지 않는 질문들이다.

에이전트 메모리도 그래프에 자연스럽게 앉는다. 시간이 찍힌 사건이 개체에 연결되는 일화 기억, 개체와 관계로 이뤄진 사실 기억, 성공한 도구 사용 패턴을 다시 실행할 수 있는 형태로 남긴 절차 기억이 모두 노드와 엣지로 표현된다. 앞 장에서 말한 궤적 저장이 이 중 세 번째에 해당한다. 세 가지를 한 저장소에 두면 어떤 사건에서 어떤 사실을 알게 됐고 그때 어떤 절차를 썼는지가 하나의 질의로 연결된다.

비용은 정직하게 말해야 한다. 마이크로소프트가 2024년에 GraphRAG를 내놨을 때 큰 문서 집합의 색인 비용은 3만 3000달러 수준이었고, 문서가 늘면 비용이 그보다 빠르게 늘었으며, 문서를 추가할 때 군집을 다시 만들어야 하는 문제가 있었다. 이후 색인 비용을 크게 낮춘 후속 구현들이 나오면서 이 부분은 상당히 해소됐다.

지금 남은 어려움은 비용이 아니라 구축 품질이다. 개체 추출이 흔들려 같은 대상이 여러 노드로 갈라지면 순회가 끊긴다. 관계 종류를 처음부터 너무 많이 정의하면 아무도 쓰지 않는 엣지가 쌓이고 추출 정확도만 떨어진다. 스키마는 작게 시작해 실제로 질의에 쓰이는 관계만 늘려 가는 편이 낫다. 그래프를 잘못 만들면 없느니만 못하다는 말은 과장이 아니다.

마크다운을 옹호하는 쪽의 반론도 들어 볼 만하다. 그래프에 필요한 요소를 뜯어보면 관계 종류를 몇 개로 좁힌 작은 스키마, 저렴한 색인, 벡터와 관계를 함께 쓰는 검색, 낡은 사실을 새 사실이 대체하는 처리 정도인데, 이 넷은 모두 자기가 소유한 마크다운 파일 위에서도 구현할 수 있다는 것이다. 실제로 머리말에 관계와 시점을 구조화해 적고 그것을 읽어 색인을 만들면 상당 부분이 된다. 데이터베이스를 도입하지 않고도 필요한 것을 얻을 수 있다면 그편이 낫다는 주장에는 근거가 있다.

이 반론이 놓치는 지점은 규모다. 파일 수백 개까지는 옳은 말이다. 수천 개를 넘어가고 관계가 여러 단계로 얽히기 시작하면, 매번 전체를 읽어 관계를 재구성하는 비용이 질의마다 발생한다. 관계를 미리 저장해 두고 필요한 부분만 순회하는 구조와 갈리는 지점이 여기다. 그러니 도구를 먼저 정하고 시작할 문제가 아니라 지금 다루는 문서의 규모와 질의의 형태를 보고 정할 문제다. 남의 사례를 보고 그래프 데이터베이스부터 도입하는 것은 순서가 뒤바뀐 선택이다.

그래프 하나로 모든 검색을 대체하려 들 필요도 없다. 2026년 현재의 실무 합의는 혼합이다. 벡터 검색이 의미의 넓이를 담당하고, 그래프가 다단계 추론과 출처 추적과 전체 조망을 담당한다. 어느 한쪽을 버리는 선택은 대개 손해다.

그래서 착수는 전면 교체가 아니라 덧붙이기로 하는 편이 낫다. 순서를 잡자면 이렇다. 먼저 지금 쓰는 위키에서 답이 나오지 않는 질문 다섯 개를 실제 업무에서 뽑는다. 그 질문들이 어떤 관계를 필요로 하는지 보면 필요한 엣지 종류가 서너 개로 정리된다. 그 서너 개만 가진 작은 그래프를 만들어 위키 옆에 둔다. 문서 본문은 그대로 마크다운에 두고, 그래프에는 개체와 관계와 출처만 넣는다. 에이전트가 그래프를 먼저 순회해 관련 문서를 찾고 본문은 기존 저장소에서 읽어 오게 하면 사람이 읽을 수 있다는 장점을 잃지 않는다.

이렇게 하면 그래프가 쓸모없다는 결론이 나와도 잃는 것이 적다. 처음부터 전체 지식을 옮기는 방식은 반대다. 몇 달을 들여 옮긴 뒤에야 스키마가 잘못됐다는 것을 알게 되고, 그때는 되돌리기도 어렵다.

설계도는 이미 있었다

여기까지를 하나로 묶으면 이렇게 된다. 실행은 그래프로 짜고, 실행이 남긴 궤적을 그래프에 쌓고, 에이전트가 참조하는 지식을 마크다운 위키에서 그래프 데이터베이스로 옮긴다. 이렇게 하면 모델을 바꾸지 않고도 결과가 달라진다. 모델이 좋아져서가 아니라 모델이 닿을 수 있는 범위가 달라져서다.

그런데 지금까지 나온 기술 중에 새로운 것이 거의 없다는 점을 짚어야 한다. 그래프로 지식을 표현하는 방식은 1960년대 의미망까지 거슬러 올라간다. 개념 사이의 관계를 기계가 읽을 수 있게 정의하는 표준은 2000년대 초에 이미 만들어졌다. 워크플로우를 노드와 엣지로 정의하고 상태를 저장하고 실패한 지점부터 재개하는 방식은 배치 처리 시스템이 십수 년 동안 해 온 일이다. 태스크 사이의 의존 관계를 그래프로 선언하고 스케줄러가 순서를 정하는 구조는 데이터 엔지니어링에서 이미 표준이다. 상태 기계로 업무 흐름을 정의하는 것도 오래된 기법이다.

이 기술들이 오랫동안 빛을 보지 못한 이유는 설계가 나빠서가 아니었다. 하나같이 사람이 일하는 방식을 형식으로 옮긴 것들이었고, 하나같이 그 형식을 읽고 실제로 움직여 줄 존재를 전제하고 있었다. 그런데 그 존재가 없었다. 사람이 직접 하기에는 양이 너무 많았고, 규칙 기반 프로그램이 하기에는 예외가 너무 많았다. 설계도는 완성돼 있었고 그것을 실행할 주체만 비어 있었다. 지난 2년 동안 새로 만들어진 것처럼 보이는 기법들이 실은 서랍에서 꺼내진 것들인 이유가 여기에 있다.

다시 「바이센테니얼 맨」의 앤드류로 돌아가면 마지막 대목이 남는다. 그가 인간으로 인정받기 위해 마지막으로 얻은 것은 능력이 아니라 한계였다. 세계 의회는 죽지 않는 존재라는 이유로 그가 인간임을 인정하기를 거절했고, 앤드류는 자기 피가 서서히 상하도록 만들어 늙고 죽을 수 있게 된 뒤에야 인간으로 받아들여졌다. 루프 엔지니어링이 도달한 결론도 정확히 같은 자리에 있다. 루프를 루프로 만드는 것은 반복이 아니라 종료 조건이다. 끝나지 않는 반복은 폭주일 뿐이다. 병목은 모델이 아니라 검증기라는 말은, 언제 멈출지를 정하는 장치가 전체의 성패를 가른다는 뜻이다. 그래프가 복잡해질수록 이 말은 더 맞는 말이 된다. 무엇을 더 할 수 있는지보다 어디서 멈추는지가 시스템의 성격을 정한다.

그래서 지금 필요한 시선은 새로운 것을 좇는 쪽이 아니라 반대쪽이다. 사람이 일을 조직하기 위해 오랜 시간 만들어 둔 것들 가운데 실행할 주체가 없어 접혀 있던 설계도가 얼마나 더 남아 있는지 되짚어 보는 일이다. 그래프 엔지니어링이라는 이름은 여섯 주 뒤에 또 바뀔지도 모른다. 이름은 중요하지 않다. 방향이 중요하다. AI가 다음에 무엇을 얻게 될지 알고 싶으면 다음 모델 발표를 기다릴 것이 아니라 사람이 일을 어떻게 하는지를 보면 된다. 지금까지 이 방법이 틀린 적은 없다.

참고 자료