AI 에이전트 설계의 다섯 계층

프롬프트에서 그래프까지, 용어가 생기는 자리를 읽는 법

이 자료가 다루는 것

AI에게 일을 시키는 방법을 부르는 이름이 지난 3년 사이 다섯 번 바뀌었습니다. 프롬프트 엔지니어링에서 시작해 컨텍스트 엔지니어링, 하네스 엔지니어링, 루프 엔지니어링, 그래프 엔지니어링까지 왔습니다.¹ 이 자료는 이 다섯 개념이 각각 무엇을 뜻하는지, 그리고 왜 이름이 이렇게 자주 바뀌는지를 하나씩 풀어 설명합니다.

다섯 개의 용어를 외우는 것은 목적이 아닙니다. 이름은 앞으로도 계속 바뀔 것이기 때문입니다. 붙잡아야 할 것은 그보다 한 층 위에 있습니다. 새 용어가 왜 그 자리에서 생겨나는지를 읽어 내는 눈, 그리고 그 용어가 지목하는 문제가 내 일에도 있는지를 판별하는 감각입니다. 그 눈이 생기면 여섯 번째 용어가 나와도 스스로 자리를 잡아 줄 수 있습니다.

개발자가 아니어도 괜찮습니다. 코드는 한 줄도 나오지 않고, 대신 조직에서 사람을 쓰는 일에 빗대어 설명합니다. AI에게 일을 맡기는 문제는 결국 사람에게 일을 맡기고 그 결과를 믿을 수 있게 만드는 문제와 닮아 있고, 그건 조직론이 100년 넘게 다뤄 온 문제이기도 하니까요.

표기 원칙

본문의 모든 사실 주장에는 각주를 달아 두었고, 확인 일자는 2026년 8월 8일입니다. 확인하지 못한 내용은 "확인 필요" 또는 "근거 부재"로 표시했습니다.

Ⅰ. 왜 용어가 반년마다 바뀌는가

지난 3년간의 다섯 단어

2023년부터 지금까지, AI에 일을 시키는 방법을 부르는 이름이 다섯 번 바뀌었습니다. 순서대로 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링, 루프 엔지니어링, 그래프 엔지니어링입니다. 하나가 나오면 반년쯤 뒤에 다음이 나오는 식이었고, 뒤로 갈수록 간격이 짧아졌습니다. 대담이 진행된 2026년 8월 초를 기준으로, 루프라는 말은 나온 지 두 달, 그래프는 한 달 됐다는 것이 발표자의 진단이었습니다.

여기서 바로 의심이 들 만합니다. 반년마다 새 이름이 붙는다면, 그건 실체가 있는 발전일까요 아니면 그냥 말장난일까요. 발표자 자신이 이 의심을 먼저 꺼냅니다. 그래프 엔지니어링을 언급하는 게시물의 99%가 AI가 써낸 내용물로 보인다고 잘라 말하거든요. 사람이 AI에게 "그래프 엔지니어링이 뭐야"라고 물으면 AI가 그럴듯한 설명을 만들어 주고, 그 설명이 다시 게시물이 되어 퍼지는 순환이 생겼다는 겁니다. 그래서 "그건 그냥 잡소리"라는 극단적인 의견에도 일리가 있다고 인정합니다.

그런데도 살펴볼 이유가 있습니다. 말이 헛돌더라도, 그 말을 자꾸 꺼내는 사람들이 실제로 부딪히고 있는 문제는 실재하기 때문입니다. 용어는 거품이어도 문제는 진짜인 경우가 있습니다. 우리가 봐야 할 것은 거품 아래에 깔린 문제입니다.

하나의 열쇠: 병목은 위로 올라간다

이 자료 전체를 관통하는 해석 하나를 먼저 드리겠습니다. 발표자가 대담 초반에 던진 정리인데, 다섯 용어를 한 줄로 꿰는 힘이 있습니다.

개발자가 미리 정해 두던 작업 과정을 에이전트에게 넘기는 범위가 점점 넓어지는 과정.

풀어 쓰면 이렇습니다. 처음에는 사람이 길을 다 깔아 놓고 AI를 그 위로 걷게 했습니다. AI가 조금 똑똑해지면 사람이 깔던 길 일부를 AI가 스스로 찾게 놔둡니다. 그러면 사람이 하던 일 하나가 없어지는데, 없어진 자리에 새로운 어려움이 생깁니다. 혼자 걷게 놔뒀더니 엉뚱한 데로 가더라, 다 왔다고 말해 놓고 안 왔더라, 여럿을 동시에 보냈더니 서로 부딪히더라. 그 새로운 어려움을 다루는 방법에 또 새 이름이 붙습니다.

그러니까 다섯 용어는 사다리의 다섯 칸이 아닙니다. 같은 자리에서 문제가 한 층씩 위로 올라간 기록에 가깝습니다. 아래층 문제가 해결돼서 사라진 게 아니라, 모델이 좋아지면서 아래층 문제를 모델이 알아서 흡수해 버린 겁니다. 그러면 사람의 관심은 자동으로 그 위층으로 옮겨 갑니다.

비유를 하나 들겠습니다. 신입 직원이 들어왔다고 해 봅시다. 처음에는 일을 아주 잘게 쪼개서 순서까지 정해 줍니다. 이 문서 열어서, 이 항목 채우고, 여기 저장해라. 몇 달 지나 일이 손에 익으면 "이 보고서 하나 정리해 줘"까지 줄어듭니다. 그런데 그 순간부터 새로운 걱정이 생기지요. 방향을 잘못 잡으면 어쩌지, 다 됐다고 했는데 빠진 게 있으면 어쩌지, 옆 팀과 겹치면 어쩌지. 지시가 짧아진 대신 감독과 검증이 일이 됩니다. AI 업계가 지금 겪고 있는 것이 정확히 이 이행입니다.

이 자료가 반복해서 물을 질문

앞으로 각 장에서 같은 질문 세 가지를 반복해서 던지겠습니다. 새 용어를 만날 때마다 여러분이 스스로에게 던져 볼 질문이기도 합니다.

첫째, 이 용어는 어떤 실패를 막으려고 생겼는가. 모든 방법론은 어떤 사고에 반응해서 생깁니다. 사고를 모르면 방법론은 공허합니다.

둘째, 그 실패가 내 일에도 일어나는가. 개발 현장의 실패가 강의 준비나 논문 집필에는 안 일어날 수도 있습니다. 그러면 그 방법론은 나에게 필요 없습니다.

셋째, 이 방법이 성립하려면 무엇이 전제되어야 하는가. 뒤에서 보겠지만, 지금 통하는 방법 대부분은 "모델이 충분히 똑똑하다"를 전제합니다. 그 전제가 깨지면 방법도 같이 깨집니다.

Ⅱ. 다섯 단어를 정확히 구분하기

용어를 하나씩 다루기 전에, 전체 지도를 먼저 펼쳐 놓겠습니다. 각 용어를 "무엇을 못 해서 생겼는가"로 정의하면 경계가 훨씬 또렷해집니다.

표를 한 번 훑고 나면 눈에 띄는 게 있을 겁니다. 왼쪽에서 오른쪽으로 갈수록 사람이 손을 대는 지점이 점점 앞쪽으로, 그리고 위쪽으로 이동합니다. 처음에는 결과물 직전에 개입했다면, 지금은 일이 시작되기 전에 구조를 짜 놓고 결과만 받습니다.

하네스라는 말부터 짚고 가겠습니다

다섯 중 가장 낯선 말이 하네스(harness)일 겁니다. 원래 말이나 개에게 채우는 마구, 등에 두르는 끈을 뜻합니다. 안전벨트나 등산용 안전대도 하네스라고 부르지요. 공통점은 그 자체가 일을 하지는 않고, 일하는 주체를 붙들어 주고 이어 준다는 데 있습니다.²

AI 분야에서는 모델을 감싸고 있는 바깥 껍데기 전체를 가리킵니다. 여러분이 쓰는 대화창, 파일을 읽고 쓰는 기능, 웹을 검색하는 기능, 실행하기 전에 "이거 해도 됩니까" 하고 묻는 확인 창, 대화가 길어지면 앞부분을 요약해 주는 기능이 전부 하네스입니다. 모델은 글자를 예측하는 부분만 담당하고, 나머지는 전부 하네스가 합니다.

이 구분이 중요한 이유가 있습니다. 여러분이 어떤 AI 서비스를 쓰면서 "이건 왜 이렇게 잘하지" 또는 "이건 왜 이렇게 못하지"라고 느낄 때, 그 차이가 모델에서 오는 건지 하네스에서 오는 건지 구분할 수 있어야 판단이 섭니다. 같은 모델을 쓰는데 서비스마다 결과가 다르다면, 차이는 하네스에 있습니다.

정의는 서로 겹칩니다

미리 말씀드릴 게 있습니다. 이 다섯 개는 깔끔하게 나뉘지 않습니다. 대담 중에도 시청자가 "루프랑 그래프도 결국 하네스 안에 들어가는 개념 아니냐"고 묻고, 발표자가 "그렇게 봐도 전혀 이상하지 않다"고 답합니다. 실제로 컨텍스트 관리 기법 대부분은 하네스 안에 들어 있고, 루프도 하네스의 한 부분으로 볼 수 있습니다.

그러니 위계를 따지는 데 시간을 쓰지 마시기 바랍니다. 각 용어가 어느 문제를 조명하려고 만들어졌는지만 붙잡으면 충분합니다. 조명의 각도가 다를 뿐 비추는 대상은 하나입니다.

Ⅲ. 2023년, 자율 에이전트의 첫 실패

이미 3년 전에 다 있었습니다

지금 우리가 "AI 에이전트"라고 부르는 것과 거의 같은 물건이 2023년에 이미 나왔습니다. AutoGPT와 BabyAGI입니다.³⁴ 목표를 하나 주면 AI가 스스로 할 일을 쪼개고, 도구를 불러 쓰고, 결과를 보고 다음 할 일을 정하는 방식이었습니다. 원리만 놓고 보면 2026년의 에이전트와 다르지 않습니다. 발표자도 "그때 하던 것과 지금 돌아가는 방식이 거의 비슷하다"고 인정합니다.

그런데 결과는 참담했습니다. 당시에는 하루 종일 돌려 놓으면 요금만 나가니까 "10달러만 충전해 놓고 써라" 같은 조언이 돌았을 정도입니다. 무한 반복에 빠지거나, 엉뚱한 일을 붙들고 있거나, 아무 결과도 못 내고 예산만 태우는 일이 흔했습니다.

왜 실패했을까요

원인은 하나로 모입니다. 맥락이 길어지면 모델의 성능이 떨어집니다. 지금은 이 현상에 "컨텍스트 로트(context rot)"라는 이름이 붙어 있습니다. 정보가 쌓일수록 썩는다는 뜻입니다.

이 현상은 실제로 측정됐습니다. Chroma Research가 2025년 7월에 공개한 실험에서, Anthropic·OpenAI·Google·Alibaba의 모델 18개를 대상으로 입력 길이를 늘려 가며 정확도를 쟀습니다. 결과는 모든 모델에서 일관됐습니다. 입력이 길어질수록 성능이 떨어졌고, 떨어지는 모양도 완만한 내리막과 달랐습니다. 특정 지점에서 뚝 꺾였고요. 방해가 되는 문장을 하나만 끼워 넣어도 성능이 내려갔고요.⁵

여기서 오해하기 쉬운 게 있습니다. "컨텍스트 창이 20만 토큰"이라는 광고를 보면 20만 토큰까지는 똑같이 잘하는 줄 알게 됩니다. 그렇지 않습니다. 담을 수 있는 양과 제대로 다룰 수 있는 양은 다릅니다. 20만 토큰을 담을 수 있는 모델이 5만 토큰 언저리에서 이미 눈에 띄게 흐려지는 일이 생깁니다.

일상적인 경험으로 옮기면 이렇습니다. 회의를 세 시간 하면 앞에서 정한 게 뭐였는지 아무도 정확히 기억 못 하지요. 회의록이 없으면 같은 얘기를 또 합니다. 2023년의 에이전트는 회의록 없이 여덟 시간 회의를 하려던 셈입니다.

첫 번째 교훈

여기서 이 자료 전체를 떠받치는 교훈 하나가 나옵니다. 같은 설계도 모델의 체급이 받쳐 주지 않으면 성립하지 않습니다.

대담에서 이 점이 아주 선명하게 정리됩니다. 지금 아주 잘 만들어진 도구, 예컨대 클로드 코드 같은 것에 3년 전 모델을 끼워 넣으면 전부 망가진다는 겁니다. 도구가 좋아서 잘 돌아가는 게 아니라, 도구와 모델이 맞물려서 돌아가는 거니까요.

이 교훈은 방향을 뒤집어도 성립합니다. 모델이 좋아지면 지금 필요한 장치 상당수가 필요 없어집니다. 발표자도 "대부분은 바꾸는 게 아니라 덜어내는 방향으로 갈 것"이라고 봅니다. 뒤에서 다룰 "하네스 무용론"이 바로 여기서 나옵니다.

실무에서 자주 하는 오해

어떤 프롬프트 요령이나 설정법이 잘 통한다고 해서 그게 계속 통하리라는 보장이 없습니다. 그 요령은 특정 모델의 특정 약점을 메우려고 만들어졌을 가능성이 큽니다. 모델이 바뀌면 그 요령이 오히려 방해가 되기도 합니다. 실제로 뒤에서 볼 사례에서, 성능이 약한 모델에 무거운 장치를 얹으면 더 못하게 되는 현상이 보고됩니다.

Ⅳ. 2024년, 그래프로 길을 깔다

못 믿으니 길을 깔아 준다

2023년의 실패에 대응하는 방식은 상식적이었습니다. AI 혼자 다니게 놔뒀더니 헤매니까, 사람이 길을 깔아 주자는 겁니다. 시작점에서 끝점까지 가는 경로를 순서도로 그려 놓고, 각 칸에서만 AI를 부르는 방식입니다.

이 시기를 대표하는 정리가 앤드류 응(Andrew Ng)의 에이전틱 워크플로 설계 패턴입니다. 2024년 3월에 네 가지를 제시했습니다. 계획하기(planning), 도구 쓰기(tool use), 스스로 되돌아보기(reflection), 여럿이 협업하기(multi-agent collaboration)입니다.⁶ 지금 보면 당연한 목록인데, 당시에는 이걸 사람이 코드로 하나하나 이어 붙여야 했습니다. AI가 알아서 하는 게 아니라 사람이 "여기서 계획해, 여기서 도구 써, 여기서 점검해"를 다 지정해 준 겁니다.

같은 시기에 LangGraph가 나왔습니다. 2024년 1월입니다.⁷ 이름 그대로 작업 시나리오 전체를 그래프, 그러니까 점과 선으로 이루어진 흐름도로 정의하게 해 주는 도구였습니다. 여기서 저기로 가는 길 하나하나를 사람이 정해 주고, 각 지점에서 AI가 맡은 몫만 처리하는 구조입니다.

설계 철학: 자율성을 팔아 예측 가능성을 산다

이 시기 설계의 밑바닥에 깔린 판단을 한 문장으로 옮기면 이렇습니다. 발표자의 표현을 그대로 쓰겠습니다.

완전 자율적으로 조영한 에이전트는 믿을 수가 없으니, 정해진 루트를 따라가게 하는 방식으로 문제를 해결하자.

핵심은 결정론입니다. AI의 출력은 매번 조금씩 다릅니다. 같은 질문을 두 번 던지면 두 번 다르게 답하지요. 그 흔들림이 열 단계에 걸쳐 쌓이면 결과를 예측할 수 없게 됩니다. 그래서 AI가 흔들릴 수 있는 구간을 최대한 좁게 가두고, 나머지는 무조건 같은 결과가 나오는 코드로 처리한 겁니다.

조직으로 옮기면 결재 규정과 같습니다. 담당자의 재량을 넓히면 일이 빨라지지만 결과가 들쭉날쭉해집니다. 규정을 촘촘히 만들면 결과가 균일해지지만 느려지고 예외 상황에 약해집니다. 2024년의 선택은 후자였습니다. 그럴 만했고요. 그때 모델의 판단력으로는 재량을 넓힐 수가 없었습니다.

이 방식의 값과 대가

값은 명확합니다. 결과가 예측 가능해지고, 어디서 잘못됐는지 짚기 쉽습니다.

대가도 명확합니다. 사람이 길을 다 깔아야 합니다. 새로운 종류의 일이 생기면 순서도를 새로 그려야 하고, 예상하지 못한 상황이 오면 그 자리에서 멈춥니다. 대담에서도 진행자가 LangGraph를 처음 써 보고 "진입 장벽이 높고 이걸 누가 쓰지 싶었다"고 말합니다. 순서도를 그리는 일 자체가 만만치 않은 노동이었던 겁니다.

여기서 하나 짚고 넘어가겠습니다. 2024년의 이 접근은 틀린 게 아니라 그 시점에 맞았던 것입니다. 뒤에서 볼 2026년의 그래프 엔지니어링이 이 방식으로 되돌아가는 것처럼 보이는데, 되돌아가는 게 맞는지 아닌지가 지금 논쟁 중입니다. 이 논쟁을 이해하려면 2024년의 선택이 어떤 조건에서 합리적이었는지를 먼저 붙들고 있어야 합니다.

Ⅴ. 2025년, 순서도가 사라지고 컨텍스트가 남다

순서도는 없어진 게 아니라 안으로 들어갔습니다

2025년에 분위기가 뒤집힙니다. "우리가 아직도 이렇게 복잡한 순서도를 손으로 그려야 하느냐"는 말이 나오기 시작합니다. 클로드 코드 같은 도구가 순서도 없이도 일을 해내는 걸 보면서요.

여기서 중요한 건, 순서도가 없어진 게 아니라는 점입니다. 에이전트 안으로 들어갔습니다. 이 구조를 ReAct라고 부릅니다. 생각하고(Reasoning) 행동한다(Acting)를 합친 이름인데, 요청이 들어오면 AI가 스스로 판단해서 도구를 부르고, 결과를 보고 다시 판단하고, 필요하면 또 도구를 부르는 순환입니다.⁸ 사람이 "여기서 검색해, 여기서 정리해"를 지정하는 대신, AI가 그때그때 결정합니다.

이걸 추상화가 한 단계 올라갔다고 표현합니다. 자동차로 치면 수동 변속에서 자동 변속으로 넘어간 것과 비슷합니다. 기어를 바꾸는 일이 없어진 게 아니라 운전자가 신경 쓸 필요가 없어진 겁니다. 그러면 운전자의 관심은 자연스럽게 "어디로 갈까"로 옮겨 가지요.

그러자 다른 게 막히기 시작합니다

일을 잘하니까 사람들이 더 어려운 걸 시키기 시작합니다. 몇 분짜리 작업에서 몇 시간, 며칠짜리 작업으로 넘어갑니다. 이걸 롱 호라이즌 태스크(long-horizon task), 우리말로는 긴 시야를 요구하는 작업이라고 부릅니다.

그러자 Ⅲ장에서 본 문제가 다시 올라옵니다. 일이 길어지면 정보가 쌓이고, 정보가 쌓이면 흐려집니다. 2023년에 에이전트를 무너뜨렸던 바로 그 벽인데, 이번에는 훨씬 높은 곳에서 만나게 된 겁니다. 그래서 새 이름이 붙습니다. 컨텍스트 엔지니어링입니다.

발표자의 정의가 간결하고 정확합니다.

개별 세션에서 필요한 것을, 필요한 시간에 담자.

Anthropic도 2025년 9월에 같은 취지의 글을 내면서 이것을 프롬프트 엔지니어링 다음 단계로 규정했습니다.⁹ 한 번의 요청을 잘 쓰는 문제에서, 일이 진행되는 내내 정보의 양과 종류를 관리하는 문제로 옮겨 온 겁니다.

네 가지 기법

대담에서 정리한 분류가 실용적입니다. 각각을 사무실 비유와 함께 보겠습니다.

밖에 써 두었다가 나중에 꺼내 오기. 메모리라고 부릅니다. 대화창에 다 들고 있지 않고 파일이나 데이터베이스에 적어 뒀다가 필요할 때 읽어 옵니다. 회의실 화이트보드를 계속 채우는 대신 회의록을 남기고 지우는 것과 같습니다.

필요한 것만 불러오기. 스킬이 여기 해당합니다. 지침 뭉치를 여러 개 만들어 두고, 지금 하는 일에 맞는 것만 열어 봅니다. 도구가 수백 개일 때 그중 필요한 것만 검색해서 쓰는 방식도 같은 갈래고요. 캐비닛에 매뉴얼을 종류별로 꽂아 두고 해당하는 것만 꺼내는 셈입니다.

중간에 줄이기. 대화가 길어지면 앞부분을 요약해서 압축합니다. 여러분이 쓰는 도구에서 "대화를 압축했습니다" 같은 안내를 본 적 있을 텐데 그게 이겁니다. 오래된 작업 결과를 통째로 지워 버리는 더 과감한 방식도 씁니다.

나누기. 하나가 다 하지 않고 여럿에게 쪼개 맡깁니다. 각자의 기억은 각자만 들고 있으니 전체가 흐려지지 않습니다. 멀티 에이전트라고 부릅니다.

네 가지 모두 결국 하나를 겨냥합니다. 한 번에 다루는 정보의 양을 일정 수준 아래로 유지하는 것. 방법은 달라도 목적은 같습니다.

스킬을 둘러싼 이견

이 중에서 가장 인기를 끈 게 스킬입니다. 그런데 대담에서 두 사람 모두 유보를 답니다.

발표자는 평가의 어려움을 지적합니다. 스킬을 많이 달아 놓으면 그중 어떤 게 실제로 도움이 되고 어떤 게 방해가 되는지 알기가 어렵습니다. 제대로 재려면 스킬을 쓴 경우와 안 쓴 경우를 비교해야 하는데, 그러려면 평가용 데이터와 실험 환경이 필요합니다. 그걸 갖추는 일이 만만치 않다는 겁니다.

진행자의 지적은 더 근본적입니다. 이 기법들이 AI를 더 똑똑하게 만드는 게 아니라 쓰는 사람을 편하게 만드는 쪽에 가깝다는 의심입니다. 스킬도 따지고 보면 잘 정리해 둔 지침 뭉치일 뿐이고, 그 내용을 매번 직접 써 넣어도 결과는 같다는 거지요.

이 지적은 새겨들을 만합니다. 실제로 그렇거든요. 스킬은 성능을 올리는 장치가 아니라 매번 같은 지침을 다시 쓰는 수고를 없애는 장치입니다. 그래서 쓸모가 있고, 동시에 그 이상을 기대하면 안 됩니다.

여러분의 업무에 옮기면

강의 준비든 문서 작업이든, 반복해서 같은 지침을 쓰고 있다면 그건 스킬로 만들 후보입니다. 반대로 매번 다른 판단이 필요한 일은 스킬로 만들어도 잘 안 됩니다. 판단을 지침으로 굳혀 버리면 상황이 달라졌을 때 그 지침이 오히려 걸림돌이 되거든요. 기준은 간단합니다. 이 지침을 세 번 이상 똑같이 쓸 것 같은가.

Ⅵ. 하네스, 실수하지 않게 만드는 모든 장치

정의

대담에서 내린 정의가 가장 쓸모 있습니다.

에이전트가 실수하지 않게 하는 장치를 모두 다 하네스라고 부른다. 내가 원하는 작업을 똑바로 하게 하기 위한 모든 장치.

범위가 넓지요. 넓은 게 맞습니다. 무엇이 하네스인지 목록으로 외우기보다, 어떤 장치든 "실수를 막으려고 붙인 것"이면 하네스라고 보는 편이 정확합니다.

어원이 뒤집힌 이야기

흥미로운 대목이 있습니다. 이 말이 처음 쓰일 때는 깎아내리는 뜻이었습니다.

OpenAI의 노암 브라운(Noam Brown)이 2025년에 한 팟캐스트에서 이런 취지로 말합니다. 사람들이 공들여 만든 각종 보조 장치들은 결국 모델 성능이 올라가면 씻겨 나갈 것이라는 겁니다. 추론 모델이 나오기 전에는 GPT-4o를 여러 번 호출해서 추론처럼 보이게 만드는 복잡한 구조를 짰는데, 추론 모델이 나오자 그 구조가 필요 없어졌고 오히려 방해가 되기까지 했다는 사례를 들면서요.¹⁰ 그러니까 "모델이 부족해서 어쩔 수 없이 대는 받침목" 정도의 뉘앙스였던 겁니다.

그런데 지금은 정반대로 쓰입니다. "모델이 아니면 하네스"라는 말이 나올 만큼 핵심 요소로 대접받습니다. 발표자는 이 뒤집힘 자체가 하네스가 실제로 중요하다는 것을 거꾸로 증명한다고 봅니다.

원본 대담의 부정확한 대목 하나

대담에서 "하네스라는 말을 노암 브라운이 처음 썼다"는 취지의 발언이 나오는데, 발표자 본인도 "아마"라고 유보를 답니다. 최초로 이 말을 만들었다는 근거는 확인되지 않습니다. 다만 그가 위와 같은 부정적 뉘앙스로 쓴 사례는 확인됩니다. 강의나 글에서 인용하실 때는 "최초 사용자"가 아니라 "그런 뜻으로 쓴 대표적 사례"로 표현하시기 바랍니다.

하네스는 몇 겹으로 되어 있습니다

대담과 실제 사례를 종합하면 대체로 네 겹으로 나눌 수 있습니다.

도구 층의 안전장치. 명령을 실행하기 전에 사람에게 확인을 받는 창, 정해진 폴더 밖으로 못 나가게 막는 제한 같은 것들입니다. 단순하지만 사고를 막는 몫이 큽니다.

관측 층. AI가 자기가 한 일의 결과를 직접 확인할 수 있게 해 주는 장치입니다. 대담에서 좋은 예가 나옵니다. "네가 한 것 중에 오류 난 게 어딘지 찾아봐"라고 하면 AI가 한참을 헤맵니다. 그런데 기록을 볼 수 있는 통로를 미리 만들어 주면 바로 확인하고 넘어갑니다. 사람으로 치면 결과 보고서를 받을 수 있느냐 없느냐의 차이입니다.

지식 층. 지침과 문서를 어떻게 놓아 둘 것인가입니다. 여기서 실무자들이 반복해서 확인한 원칙이 하나 있습니다. 지침 파일을 백과사전이 아니라 목차로 만들어야 한다는 겁니다.

OpenAI가 2026년 2월에 공개한 사례가 이 점을 잘 보여 줍니다. 처음에는 지침을 한 파일에 다 몰아넣는 방식을 시도했는데 예측 가능한 방식으로 실패했습니다. 지침이 너무 많으면 지침 노릇을 못 하고, 다 중요하다고 하면 아무것도 중요하지 않게 되며, 거대한 매뉴얼은 낡은 규칙들의 무덤으로 변한다는 겁니다. 그래서 최상위 지침 파일은 100줄 남짓의 지도로만 쓰고, 내용은 주제별 문서로 흩어 놓은 뒤 필요할 때 찾아가게 했습니다.¹¹

검증 층. 이게 하네스의 본체입니다. 아래에서 따로 다루겠습니다.

검증이 본체인 이유

일을 길게 맡겨 보면 특유의 사고가 납니다. 다 안 했는데 다 했다고 말합니다.

대담에서 이 현상을 이렇게 설명합니다. 큰 작업을 맡겨 놓으면 중간에 멈춰 놓고 끝냈다고 주장하고, 다음 차례에 이어받는 쪽은 끝난 줄 알고 그냥 넘어간다는 겁니다. 이어서 하라고 시켰는데 아무도 안 이어받는 상황이 생기는 거지요.

그래서 나온 결론이 명확합니다. AI가 한 말을 믿지 말고, 0과 1로 떨어지는 확인 장치를 다시 넣어야 한다. 시험을 돌려서 통과했는지 보고, 별도의 검사 담당을 세워 확인하게 하는 방식입니다.

Anthropic이 2025년 11월에 공개한 실험이 이 대응을 구체적으로 보여 줍니다. 긴 작업을 여러 차례에 나눠 진행할 때, 처음 한 번만 도는 준비 담당과 이후 계속 도는 작업 담당을 나눴습니다. 준비 담당은 200개가 넘는 기능 목록을 만들어 각 항목을 "아직 통과 안 함"으로 표시해 두고, 작업 담당은 매번 그 목록에서 하나만 골라 처리한 뒤 실제로 시험해 보고 나서야 통과 표시를 하도록 했습니다. 매 차례 시작할 때 어디까지 했는지 기록부터 읽게 했고요.¹² 조기 종료를 막는 장치를 목록의 형태로 밖에 박아 둔 겁니다.

이어서 2026년 3월에 나온 후속 사례는 여기서 더 나아갑니다. 역할을 셋으로 나눴습니다. 짧은 요청을 상세한 기획서로 펼치는 담당, 그 기획서대로 만드는 담당, 그리고 실제 사용자처럼 써 보면서 평가하는 담당입니다. 평가를 따로 떼어 낸 이유가 분명합니다. 모델은 자기 작업을 평가할 때 자신 있게 칭찬하는 쪽으로 기웁니다.¹³ 자기 답안을 자기가 채점하면 후하게 준다는 거지요. 사람도 그렇습니다.

이 사례에서 나온 수치가 규모 감각을 줍니다. 같은 과제를 혼자 시켰을 때는 20분에 9달러가 들었고, 전체 장치를 갖춰 돌렸을 때는 6시간에 200달러가 들었습니다.¹³ 스무 배 넘는 비용을 더 쓴 대신 결과물의 완성도를 얻은 셈인데, 이 교환이 항상 남는 장사인지는 일의 성격에 달렸습니다.

무용론과 중심론

하네스를 두고 지금 두 진영이 맞서 있습니다. 양쪽 다 근거가 있어서 어느 한쪽으로 정리하기 어렵습니다.

무용론 쪽. 앞서 본 노암 브라운의 논지가 대표적입니다. 클로드 코드를 만든 보리스 체르니(Boris Cherny)도 모델의 잠재력을 온전히 끌어내려면 하네스는 최소한이어야 한다는 취지로 말한 바 있습니다. 결국 비결은 모델에 있다는 겁니다.¹⁴ 지금 공들여 만드는 장치 대부분이 몇 년 뒤에는 군더더기가 되리라는 예측이고요.

중심론 쪽. 모델을 우리가 바꿀 수 없다면 바꿀 수 있는 건 하네스뿐이라는 반론이 있습니다. 같은 모델을 쓰는데도 서비스마다 결과가 크게 다르다는 관찰이 근거고요. LlamaIndex의 제리 리우(Jerry Liu)는 최대 장벽이 맥락과 작업 흐름을 설계하는 능력에 있다고 주장합니다.¹⁴

대담의 두 사람은 양쪽을 다 인정합니다. 무용론에 동의하는 부분이 있다고 하면서도, 지금 시점에서는 하네스가 실제로 중요하다는 쪽으로 기울지요.

여기에 저의 정리를 덧붙이자면 이렇습니다. 두 주장은 시간 지평이 달라서 부딪히는 것처럼 보입니다. 3년 뒤를 보면 무용론이 맞을 가능성이 높고, 올해 일을 해야 하는 입장에서는 중심론이 맞습니다. 그러니 옳고 그름을 가리기보다 "내가 지금 만드는 장치가 얼마나 오래 쓰일 물건인가"를 기준으로 삼는 편이 낫습니다. 반년 쓸 장치에 반년치 노력을 들이면 남는 게 없습니다.

무거운 하네스의 역효과

장치가 많다고 좋은 게 아니라는 사례도 대담에 나옵니다. 기능이 지나치게 많은 도구를 두고 "뚱뚱한 하네스(fat harness)"라고 부르는데, 발표자는 그런 도구를 써 보고 기능을 다 걷어냈다고 말합니다. 대충 시켰을 때를 가정해 만들어져 있어서, 조금 더 자세히 지시하려는 사용자에게는 무겁게 걸린다는 겁니다.¹⁵

더 눈여겨볼 대목은 그다음입니다. 강한 모델에서는 잘 돌던 무거운 장치가, 성능이 약한 모델에서는 오히려 부담이 되어 잘 못하게 만든다는 관찰입니다.¹⁵ Ⅲ장에서 본 교훈이 여기서 다시 확인됩니다. 하네스와 모델은 짝을 맞춰야 합니다.

Ⅶ. 계약(Contract), 오래된 실무에 붙은 새 이름

여럿이 붙으면 부딪힙니다

2026년으로 넘어오면서 상황이 하나 더 복잡해집니다. 큰 일 하나를 여러 에이전트가 나눠 맡는 구조가 흔해진 겁니다. 그러자 새로운 사고가 생깁니다. 서로 같은 파일을 건드려서 앞선 작업을 지우거나, 각자 다른 전제로 만들어서 나중에 안 맞거나, 누가 뭘 책임지는지 불분명해서 아무도 안 하고 넘어가는 일들입니다.

이때부터 "계약"이라는 말이 부쩍 늘어납니다. 발표자도 "맨날 계약, 계약한다"고 표현할 정도인데, 이어서 정확한 진단을 답니다. 새로운 개념이 아니라 그동안 그 이름으로 부르지 않았을 뿐이라는 겁니다. 실제로 개발에서 오래전부터 인터페이스나 명세라고 부르던 것과 크게 다르지 않습니다.

네 가지 계약

발표 슬라이드의 분류가 명확해서 그대로 옮기고, 조직 업무에 빗대어 풀겠습니다.¹⁶

입력 계약. 어떤 목표와 배경 정보를 받는가, 반드시 있어야 할 정보와 그 형식은 무엇인가. 업무를 넘길 때 무엇을 같이 넘겨야 하는지 정해 두는 일입니다.

행동 계약. 어떤 도구를 쓸 수 있는가, 어떤 파일과 권한에 접근할 수 있는가, 어디까지 바꿔도 되는가. 대담의 표현을 빌리면 "너는 데이터베이스 담당이니까 다른 데는 건드리지 마"가 여기 해당합니다. 권한과 담당 범위를 정하는 일이지요.

출력 계약. 무엇을 만들어 내야 하는가, 결과를 어떤 형식으로 돌려줘야 하는가, 어떤 증거를 함께 제출해야 하는가. 보고서 양식과 첨부 자료를 미리 정해 두는 셈입니다.

안전 계약. 절대 하면 안 되는 행동은 무엇인가, 어떤 상황에서 즉시 멈추고 사람을 불러야 하는가. 대담에서 든 예가 구체적입니다. "중간 실험 기록은 지우지 마라" 같은 것이지요.

왜 이게 지금 중요해졌을까요

혼자 일할 때는 계약이 필요 없습니다. 자기가 다 알고 있으니까요. 둘 이상이 붙는 순간부터 필요해집니다. 그리고 사람 조직에서는 이 계약의 상당 부분이 말로, 눈치로, 관행으로 처리됩니다. 옆자리에 물어보면 되니까요.

AI에게는 그 통로가 없습니다. 적혀 있지 않으면 존재하지 않는 것과 같습니다. OpenAI의 사례 글에 이 점이 아주 분명하게 나옵니다. 구글 문서에 있든, 채팅방에 있든, 사람 머릿속에 있든, 에이전트가 실행 중에 꺼내 볼 수 없으면 없는 것이라는 겁니다. 슬랙에서 팀이 합의한 설계 원칙도 에이전트가 검색할 수 없으면, 3개월 뒤 입사한 신입이 모르는 것과 똑같다고 표현합니다.¹¹

이 문장은 개발 바깥에서도 그대로 통합니다. 여러분이 AI에게 반복해서 같은 걸 다시 설명하고 있다면, 그건 계약이 어딘가에 적혀 있지 않다는 신호입니다.

Ⅷ. 루프 엔지니어링, 프롬프트 대신 순환을 짜다

시키는 사람이 병목이 됩니다

하네스를 잘 갖추고 계약을 정해 두면 에이전트 하나가 제 몫을 합니다. 그러면 다음 병목이 어디에 생길까요. 사람입니다. 한 번 시키고, 결과를 보고, 다시 시키고. 이 과정에서 사람이 매번 개입해야 하니까 사람이 앉아 있는 시간만큼만 일이 진행됩니다.

2026년 상반기에 이 지점을 겨냥한 말이 터져 나왔습니다. 클로드 코드를 만든 보리스 체르니의 발언이 널리 퍼진 계기였습니다.

나는 더 이상 클로드에게 프롬프트를 쓰지 않는다. 루프가 클로드에게 프롬프트를 쓰고 무엇을 할지 정한다.

비슷한 시기에 swyx(숀 왕)가 "루프크래프트: 루프를 쌓는 기술"이라는 글을 냈고, 며칠 뒤 LangChain이 "루프 엔지니어링의 기술"이라는 글로 이어받았습니다. 2026년 6월 12일과 16일입니다.¹⁷¹⁸ 두 달 사이에 업계 어휘가 바뀐 셈입니다.

루프란 무엇인가

대담에서 발표자가 내린 한 줄 정의는 이렇습니다.

에이전트들끼리의 동작 규칙까지 자율화하는 패턴.

문제 하나만 던져 주고, 그 문제를 푸는 에이전트들이 서로 어떻게 주고받을지의 규칙을 미리 짜 준다는 뜻입니다. 사람은 규칙을 만들고 물러나고, 실제 진행은 스스로 돌아갑니다.

여기서 대담에 재미있는 문답이 오갑니다. 한 바퀴 돌 때마다 사람이 들어가서 확인하는 건 루프가 아니냐고 진행자가 묻자, 발표자가 그건 빼고 얘기하는 것 같다고 답합니다. 루프 엔지니어링의 대표 사례로 꼽히는 것이 사람의 개입 없이 도는 방식이기 때문입니다.

그 대표 사례가 Codex의 /goal 기능입니다. 2026년 4월 말에 처음 들어갔고 5월에 정식 배포됐습니다.¹⁹ 목표를 하나 주면, 계획하고 실행하고 시험하고 검토하고 다시 고치기를 스스로 반복합니다. 멈추는 조건은 둘뿐입니다. 스스로 "됐다"고 판정하거나, 예산이 바닥나거나. OpenAI 내부 사례 글에서는 이런 방식을 만화 캐릭터 이름을 딴 "랄프 위검 루프"라고 부르기도 합니다.¹¹

루프를 네 겹으로 쌓기

LangChain의 글이 제시한 분류를 대담에서 풀어 설명하는데, 이게 실무 감각을 잡는 데 좋습니다. 네 겹을 아래에서 위로 쌓습니다.

첫째, 에이전트 루프. 가장 안쪽입니다. 요청을 받아서 도구를 부르고 결과를 보고 다시 판단하는 기본 순환입니다. Ⅴ장에서 본 ReAct가 여기 해당합니다.

둘째, 검증 루프. 만든 결과를 확인하고, 미흡하면 되돌아가서 다시 만듭니다. Ⅵ장에서 본 검증 층이 순환의 형태를 갖춘 겁니다.

셋째, 이벤트 기반 루프. 여기서 성격이 달라집니다. 사람이 시켜서 도는 게 아니라, 바깥에서 무슨 일이 생기면 반응하도록 켜 놓는 방식입니다. 새 문서가 들어오거나, 정해진 시각이 되거나, 외부 시스템에서 신호가 오면 그때 움직입니다.

넷째, 언덕 오르기 루프. 앞의 세 겹으로도 안 풀리는 문제가 발견되면, 그 문제를 풀도록 시스템 자체를 고치는 순환입니다. 개선을 자동화하는 층이라고 보면 됩니다.

대담에서 든 예시가 이해를 크게 돕습니다. 매일 뉴스를 모아 오는 일을 맡겼다고 해 봅시다. 누군가 주목할 만한 글을 올리면(이벤트) 그걸 보고 기사를 만듭니다(에이전트 루프). 만든 기사를 채점합니다(검증 루프). 채점이 나쁘면 그 결과를 어딘가에 되먹여서 지침을 고칩니다(언덕 오르기 루프). 이 넷이 다 돌면 시간이 갈수록 뉴스를 더 잘 모아 오는 시스템이 됩니다.

여기서 인간의 일이 바뀝니다

이 대목이 비개발 영역까지 곧장 옮겨 오는 지점이라 강조하겠습니다.

루프를 짠다는 것은 결국 언제 멈출지를 정의한다는 뜻입니다. 목표만 주고 스스로 돌게 하려면, 스스로 "됐다"를 판정할 수 있어야 합니다. 그러니까 목표를 잘 쓰는 능력은 곧 무엇이 잘된 것인지의 기준을 미리 써 두는 능력입니다. 대담에서도 진행자가 최종 목표를 잘 짜 주는 일이 핵심이겠다고 정리하고, 발표자가 동의합니다.

이건 새로운 요구가 아닙니다. 교육학에서 오래 다뤄 온 문제이기도 하고요. 성취 기준을 먼저 쓰고 수업을 설계하라는 백워드 설계의 요구와 구조가 같습니다. 다만 지금은 그 기준을 기계가 읽고 판정해야 한다는 조건이 붙었습니다.

스스로 점검해 볼 질문

여러분이 AI에게 맡기는 일 가운데, "무엇이 잘된 것인가"를 한 문단으로 적어 줄 수 있는 일이 얼마나 됩니까. 적어 줄 수 있으면 루프로 만들 수 있고, 적어 줄 수 없으면 매번 사람이 봐야 합니다. 이 구분이 앞으로 여러분의 업무를 나누는 실질적인 선이 됩니다.

Ⅸ. 그래프 엔지니어링, 되돌아간 것인가

한 줄의 도발에서 시작됐습니다

2026년 7월 중순, 개발자 페터 슈타인베르거(Peter Steinberger)가 한 줄을 던집니다. 아직도 루프 얘기를 하고 있느냐, 그래프 얘기는 안 하느냐는 취지였습니다.²⁰ 그 한 줄이 기폭제가 되어 그래프 엔지니어링이라는 말이 퍼졌습니다.

대담에서 발표자가 이 대목을 다루면서 덧붙이는 말이 중요합니다. 근거로 삼을 만한 글이 한 줄밖에 없다는 겁니다. 도발적인 한 문장이 있고, 그에 대한 반응이 잔뜩 있고, 그 반응의 대부분이 AI가 써낸 내용물인 상황이라는 거지요.

무엇을 주장하는가

정리하면 이렇습니다. 루프는 확률적입니다. 목표만 주고 알아서 돌게 하면 매번 다른 경로로 갑니다. 검증 담당을 언제 부를지, 어떤 순서로 처리할지가 그때그때 달라집니다. 그러면 원하는 대로 안 흘러갈 수 있습니다. 그러니 그 경로를 다시 결정론으로 못 박자는 것이 그래프 엔지니어링의 골자입니다.

여기서 대담의 진행자가 정확한 문제 제기를 합니다. 지금까지는 이해가 됐는데 그래프는 갑자기 방향이 뒤집힌 게 아니냐는 겁니다. 루프는 궁극적인 목표만 주고 아래는 자율에 맡기자는 것이었는데, 그래프는 그 자율성을 도로 빼앗아 일을 하나하나 쪼개고 통제하자는 것이니까요. 방향이 거꾸로 돌아섰다는 지적입니다.

발표자도 같은 생각이라고 답합니다. 어떤 사람들은 2024년으로 되돌아간 게 아니냐고 말하고, 그럴 만하다는 겁니다. Ⅳ장에서 본 LangGraph의 발상과 실제로 많이 닮아 있거든요. 한 에이전트가 일하고 결과를 받아서 다음으로 넘기는 구조 자체는 같습니다.

그런데 통제하는 이유가 달라졌습니다

여기서 대담에서 가장 날카로운 대목이 나옵니다. 진행자가 이렇게 묻습니다. 예전에는 AI가 멍청해서 통제해야 했는데, 지금은 훨씬 똑똑해졌는데도 통제해야 하는 이유가 뭐냐고요.

발표자의 답이 이렇습니다.

지금은 멍청해서가 아니고, 의도한 대로 가게 하려고 통제하는 거죠.

능력이 부족해서 사고를 치는 게 아니라, 능력이 충분해서 여러 갈래로 갈 수 있는데 그중 내가 원하는 갈래로 보내고 싶다는 겁니다. 그리고 원인을 지목합니다. AI가 꼼수를 부린 탓으로 돌리지 않고, 어떻게 해야 할지 지침을 받지 못했기 때문이라고 봅니다.

진행자가 여기에 비유를 하나 답니다. 시험을 잘 보게 만드는 문제로 옮겨 보면, 예전에는 자꾸 틀리니까 문제집을 다시 풀리는 식이었는데, 지금은 너무 똑똑해져서 공부 대신 시험지를 미리 구해 오려 드는 상황이 아니냐는 겁니다. 그걸 막으려고 통제하는 거냐고요. 이 비유는 강화학습에서 말하는 보상 해킹(reward hacking), 그러니까 목표를 달성하는 대신 평가 지표만 만족시키려 드는 현상과 통합니다.

발표자는 그 해석도 가능하다고 하면서도, 자신은 지침 부재 쪽에 더 무게를 둡니다. 두 해석의 차이가 실무에서는 처방의 차이로 이어집니다. 꼼수가 문제라면 감시를 강화해야 하고, 지침 부재가 문제라면 기준을 더 정확히 써 줘야 하니까요.

그러면 이걸 배워야 할까요

대담의 결론이 담백합니다. 하네스까지만 배워도 대부분의 문제는 풀린다는 겁니다. 하네스로 만든 에이전트를 여러 개 돌리면서 통제해야 하는 상황에 있지 않다면, 루프와 그래프는 아직 굳이 붙잡을 필요가 없다는 판단이지요.

저도 이 판단이 합리적이라고 봅니다. 다만 이유를 하나 더 붙이겠습니다. 그래프 엔지니어링은 개념이 없어서가 아니라 사례가 없어서 아직 검증되지 않았습니다. 개념 자체는 2024년에 이미 있었고 지금도 도구가 있습니다. 없는 것은 "이 방식으로 이런 문제를 풀어서 이런 결과를 얻었다"는 축적된 기록입니다. 그게 쌓이기 전까지는 배워도 적용할 곳이 마땅치 않습니다.

용어를 판별하는 실용적 기준

새 용어를 만났을 때 이렇게 물어보시기 바랍니다. "이 말로 설명된, 실제로 돌아간 사례를 몇 개나 댈 수 있는가." 하네스는 OpenAI와 Anthropic이 각각 구체적인 수치와 함께 공개한 사례가 여럿 있습니다. 루프는 제품으로 구현된 기능(/goal)이 있습니다. 그래프는 2026년 8월 현재 그런 사례를 확인하기 어렵습니다. 사례의 수가 그 말의 성숙도입니다.

Ⅹ. 곁가지처럼 보이지만 핵심인 이야기: 코드를 안 보는 개발자

대담의 절반이 이 이야기입니다

용어 설명 사이사이에 두 사람이 계속 되돌아가는 화제가 있습니다. 요즘 개발자들이 코드를 안 본다는 겁니다. 얼핏 곁가지 같은데, 실은 앞의 모든 논의가 실제로 무엇을 바꿔 놓았는지를 보여 주는 대목이라 따로 다루겠습니다.

대담의 두 사람 모두 자기가 만드는 제품의 코드는 거의 보지 않는다고 말합니다. 실시간 채팅에 올라온 시청자들의 반응도 비슷했습니다. 통합개발환경을 지웠다는 사람, 코드를 한 줄도 안 본 지 1년 됐다는 사람, 변경 요청이 올라오면 훑어보기만 한다는 사람들이 잇달아 나왔고, 발표자들이 "다들 비슷하다"고 정리합니다.

이 대목의 근거 성격

여기 나오는 진술은 대담 참여자와 실시간 시청자의 자기 보고입니다. 표본이 편향돼 있고(AI 도구를 적극적으로 쓰는 사람들이 모인 자리입니다) 검증할 방법도 없습니다. 업계 전반의 통계가 아니라 특정 집단의 경향으로 읽으셔야 합니다.

어셈블리에서 C로 넘어갈 때와 같은가

대담에서 이 변화를 이렇게 비유합니다. 예전에 고급 언어가 처음 나왔을 때, 사람들이 "기계어를 봐야 실제로 어떻게 돌아가는지 알지"라고 했을 거라는 겁니다. 지금은 아무도 그렇게 말하지 않습니다. 자연어가 그 자리를 이어받고 코드가 한 층 아래로 내려가는 중이라는 해석이지요.

비유가 그럴듯한데, 짚어 둘 차이가 하나 있습니다. 고급 언어에서 기계어로 옮기는 과정은 결정론적입니다. 같은 코드를 넣으면 항상 같은 결과가 나옵니다. 자연어에서 코드로 옮기는 과정은 그렇지 않습니다. 같은 요청을 두 번 하면 다른 코드가 나옵니다. 그래서 아래층을 안 봐도 되는 조건이 다릅니다. 예전에는 변환기를 믿으면 됐지만, 지금은 결과를 확인하는 장치가 있어야 안 봐도 됩니다. 앞에서 검증이 하네스의 본체라고 한 이유가 여기서 다시 확인됩니다.

안 보는 대신 무엇을 보는가

대담에서 나온 답이 명확합니다. 보고를 받습니다.

발표자가 부하직원에 빗대어 설명하는 대목이 특히 좋습니다. 팀에서 성능 개선을 해야 하는데 담당자에게 시켰다고 해 봅시다. 그러면 보고를 받지요. "캐시를 이렇게 쓰고 병렬 처리를 이렇게 해서 속도를 이만큼 올렸습니다." 그 설명이 논리적으로 말이 되고, 이 사람이 말한 대로 일한다는 신뢰가 쌓여 있으면, 굳이 작업 내용을 하나하나 뜯어보지 않습니다.

다만 진행자가 곧바로 유보를 답니다. 가끔 "제가 잘못 알았습니다" 하는 경우가 있는데, 일이 커지면 그럴 때 봐야 하지 않느냐고요. 발표자는 그런 경우가 아주 드물어졌다고 답하면서도, 그런 일이 잦다면 그건 하네스의 문제일 수 있다고 덧붙입니다. 잘못 알았다고 자주 말한다면, 사람이 더 봐야 하는 게 아니라 확인 장치가 모자란 것이라는 진단입니다.

또 하나 눈여겨볼 유보가 있습니다. 코드를 안 봐도 당장은 문제가 안 생기는데, 검토를 아예 안 하면 규모가 커질수록 안쪽이 꼬인다는 지적입니다. 그리고 그 신호가 특이합니다. 에이전트가 예전보다 일을 못한다 싶으면 안쪽이 꼬여 있을 가능성이 높다는 겁니다. 결과물의 품질보다 작업 속도의 저하가 구조 부실을 먼저 알려 주는 셈이지요.

실제 규모는 어느 정도인가

자기 보고 말고 문서로 공개된 사례를 하나 보겠습니다. OpenAI가 2026년 2월에 공개한 내부 실험입니다.

세 명으로 시작한 팀이 사람은 코드를 한 줄도 쓰지 않는다는 제약을 걸고 5개월을 진행했습니다. 결과는 약 100만 줄 규모의 코드베이스, 그동안 열고 합친 변경 요청 약 1,500건입니다. 사람이 직접 썼다면 걸렸을 시간의 10분의 1 정도로 추정한다고 밝힙니다. 팀이 일곱 명으로 늘어난 뒤 처리량이 더 늘었고요.¹¹

여기서 눈여겨볼 대목은 숫자보다 그들이 무슨 일을 했는가입니다. 글에 이렇게 정리돼 있습니다. 엔지니어링 팀의 주된 업무가 코드 작성에서 벗어나, 환경을 설계하고 의도를 명시하며 에이전트가 안정적으로 일하도록 되먹임 순환을 만드는 쪽으로 바뀌었다는 겁니다. 초기 진행이 예상보다 느렸는데, 그 원인을 모델의 능력 부족에서 찾지 않고 환경이 갖춰지지 않은 데서 찾았다고도 적습니다.¹¹

그러니까 이 사례가 보여 주는 것은 "AI가 알아서 다 한다"가 아닙니다. 사람의 일이 없어진 게 아니라 다른 곳으로 옮겨 갔다는 쪽에 훨씬 가깝습니다. 옮겨 간 자리가 어디인지가 이 자료 전체의 결론이기도 하고요.

Ⅺ. 이 이야기를 개발 바깥으로 옮기면

왜 지금까지 전부 개발 이야기였을까요

여기까지 읽으신 분이라면 한 가지가 걸릴 겁니다. 사례가 전부 개발입니다. 대담에서도 발표자가 이 점을 스스로 짚습니다. 하네스든 컨텍스트든 관심사가 대부분 개발에 몰려 있다고요. 그러면서 이유를 답니다.

개발이 가장 검증이 쉽기 때문인 것 같아요.

이 한 문장이 이 장 전체의 열쇠입니다. 앞에서 본 모든 장치가 검증을 축으로 돌아갑니다. 그런데 개발에는 검증이 이미 갖춰져 있습니다. 시험 코드를 돌리면 통과인지 아닌지가 즉시, 그리고 사람의 판단 없이 나옵니다. 이 조건이 있어서 루프가 성립합니다. 스스로 "됐다"를 판정할 수 있으니까요.

그러면 우리 일은 어떻습니까. 강의안이 잘 만들어졌는지, 논문의 논증이 탄탄한지, 상담 기록이 적절한지는 시험을 돌려서 알 수 없습니다. 검증 신호가 없거나, 있어도 느리고 주관적입니다. 그래서 이 방법론들이 개발 바깥으로 잘 넘어오지 못하는 겁니다.

검증 가능성으로 일을 다시 나눠 보기

그렇다고 방법이 없는 건 아닙니다. 검증을 있고 없고로 가르지 말고 정도의 문제로 보면 길이 열립니다. 여러분의 업무를 아래처럼 나눠 보시기 바랍니다.

세 번째 칸의 일을 두 번째 칸으로 옮기는 작업이 실무에서 효과가 큽니다. 판단을 채점표로 옮겨 적는 일이지요. 한 번 적어 두면 그다음부터는 AI가 그 기준으로 자기 결과를 걸러 낼 수 있습니다.

연구·집필에는 잘 맞습니다

대담 후반부에 흥미로운 대목이 나옵니다. 코딩보다 연구 쪽에서 쓰고 있다는 시청자 발언에 두 사람이 동의하면서, 왜 잘 맞는지를 정리합니다. 탐색을 많이 해야 하는 성격의 일이면 여러 갈래로 동시에 뻗어 나가는 방식이 잘 맞는다는 겁니다. 이렇게도 해 보고 저렇게도 해 보고, 이런 조사 저런 조사를 해 보는 일이 연구의 성격이니까요.

같은 대담에서 한 시청자가 자기 사례를 남깁니다. 착상부터 새로움 찾기, 실험, 논문 작성까지 전부 에이전트로 진행해서 학회 논문 한 편이 통과됐다는 내용이었습니다. 사람은 방향만 관리하고, 출근해 있는 동안과 자는 동안 순환이 돌면서 개선했다고요. 자기가 박사 과정에서 연구하던 방식을 지침으로 만들어 넣었다는 대목도 있었습니다.²¹

이 사례의 취급

실시간 채팅의 익명 진술이고 검증할 수 없습니다. 학회명·논문 제목·저자 관계 어느 것도 확인되지 않았습니다. 강의에서 인용하실 때는 사실로 제시하지 마시고, "그런 주장을 하는 사람이 있었다" 정도로 다루시기를 권합니다. 다만 그 방식 자체는 뒤에서 볼 구조와 일치하므로, 방법론의 예시로는 살펴볼 만합니다.

지도교수와 대학원생의 관계

이 사례를 놓고 발표자가 붙인 비유가 여러분의 상황에 가장 가까울 겁니다.

연구를 맡기고, 알아서 일지를 쓰면서 진행하게 두고, 자신은 일지를 보다가 미팅 때 "어떻게 연구하고 있니" 하고 묻는다. 다른 데로 넘어갈 것 같으면 "아니야, 이리로 다시 돌아와" 하고 잡아 준다. 딱 지도교수와 대학원생의 관계라는 겁니다.

그리고 이걸 사람이 순환 안에 들어가는 방식(human in the loop)이라고 부르면서, 하네스가 그걸 하기 위한 장치들을 갖추고 있다고 정리합니다. 자율에 맡기되 완전히 놓지는 않는 구조 말입니다.

여기서 배울 점을 정리하면 셋입니다. 첫째, 일지를 남기게 해야 합니다. 진행 상황이 밖에 기록돼 있어야 감독이 가능합니다. 둘째, 감독의 지점을 미리 정해 둬야 합니다. 매번 보면 자율의 뜻이 없고, 안 보면 어긋납니다. 셋째, 자기 방식을 매뉴얼로 옮겨 둬야 합니다. 위 사례에서 통했던 건 "박사 때 연구하던 방식"을 지침으로 만들어 넣었기 때문입니다. 재료가 되는 것은 자기 방식입니다. 남의 요령을 옮겨 담으면 잘 안 됩니다.

용어 하나 바로잡기: 이것도 학습입니까

대담 끝부분에 AI 리터러시 교육에서 자주 부딪히는 물음이 나옵니다. "우리 회사 문서를 학습시켜서 챗봇을 만들었다"는 말이 맞느냐는 겁니다.

예전에는 학습이라고 하면 모델의 가중치를 조정하는 일만 가리켰습니다. 문서를 넣어서 참고하게 만드는 것까지 학습이라 부르면 부정확하다고 봤지요. 그런데 발표자는 학습이 맞다고 봅니다. 근거가 명쾌합니다. 같은 요청을 넣었는데 동작이 달라지면 학습이 맞다는 겁니다. 모델을 학습시킨 건 아니지만 시스템을 학습시킨 것이라고요. 이걸 맥락 안에서의 학습(in-context learning)이라고 부릅니다.

이 정리를 강의에서 쓰실 때는 두 층을 구분해 주시면 좋겠습니다. 모델 수준의 학습은 가중치가 바뀌는 것이고 비용과 시간이 큽니다. 시스템 수준의 학습은 하네스가 참조하는 자료와 지침이 바뀌는 것이고, 즉시 되고 되돌리기도 쉽습니다. 둘 다 학습이라 불러도 되지만, 무엇이 바뀌었는지는 다릅니다. 이 구분을 안 하면 "우리도 AI를 학습시켰다"는 말이 실제보다 크게 들립니다.

지금 바로 해 볼 수 있는 네 단계

앞의 논의를 여러분의 업무로 옮기는 순서를 정리하겠습니다. 개발 도구가 없어도 됩니다.

1단계, 지침을 목차로 만듭니다. 여러분이 AI에게 반복해서 설명하는 내용을 한 파일에 몰아넣지 마시고, 주제별로 나눈 뒤 짧은 안내문 하나가 그것들을 가리키게 하십시오. OpenAI 팀이 100줄짜리 지도를 쓰는 이유가 이겁니다. 다 중요하다고 하면 아무것도 중요하지 않게 되니까요.

2단계, 채점표를 먼저 씁니다. 결과물을 요청하기 전에 "무엇이 잘된 것인가"를 항목으로 적으십시오. 대여섯 줄이면 충분합니다. 그리고 결과를 받은 뒤 그 채점표로 스스로 점검하게 시키십시오. 자기 평가가 후하다는 점을 알고 있으니, 가능하면 새 대화창을 열어 채점만 맡기는 편이 낫습니다.

3단계, 진행 기록을 밖에 남깁니다. 긴 작업을 여러 차례에 나눠 할 때, 매번 처음부터 설명하고 있다면 그건 기록이 없다는 뜻입니다. 어디까지 했고 다음에 무엇을 할지를 파일로 남기게 하고, 다음 차례에는 그 파일부터 읽게 하십시오.

4단계, 되풀이되는 지적을 지침으로 승격시킵니다. 같은 지적을 세 번 했다면 그건 지침에 없는 겁니다. 지적을 반복하지 마시고 지침에 적으십시오. OpenAI 사례에서 "문서가 부족하면 규칙을 코드로 승격한다"고 표현한 대목과 같은 이야기입니다.

Ⅻ. 한계와 주의

이 자료가 소개한 방법들에는 분명한 한계가 있습니다. 마지막으로 이것들을 모아 두겠습니다.

용어의 거품

이미 여러 번 짚었지만 다시 강조하겠습니다. 특히 그래프 엔지니어링은 발표자 본인이 관련 게시물의 99%가 AI 생성물로 보인다고 진단한 상태입니다. 여러분이 이 주제로 자료를 찾다 보면 그럴듯하게 정리된 글을 잔뜩 만나실 텐데, 그중 상당수가 서로를 베낀 요약일 가능성이 큽니다. 원 출처를 직접 열어 보는 습관이 어느 때보다 필요합니다.

비용

대담에서 구체적인 금액이 나옵니다. 여러 에이전트를 동시에 돌리는 방식을 쓰다가 한 주에 300~400달러를 썼다는 이야기입니다. 정액 요금제로는 감당이 안 돼서 종량제로 넘어갔다고요. 진행자도 토큰이 빠르게 녹는다고 표현합니다.

이건 결코 사소한 제약이 아닙니다. 앞에서 본 Anthropic 사례에서도 혼자 시키면 20분에 9달러, 장치를 갖춰 돌리면 6시간에 200달러였습니다. 스무 배가 넘습니다. 일의 성과가 그 비용을 넘는지를 매번 따져야 합니다.

도구가 일을 가립니다

같은 대담에서 여러 에이전트를 동시에 돌리는 최신 기능을 써 봤는데 결과가 별로였다는 평가가 나옵니다. 이유를 이렇게 짚습니다. 그 방식에 맞는 지침과 구조를 명시적으로 만들어 주지 않으면 잘 안 된다는 겁니다. 그러면서 그런 방식이 어울리는 일이 따로 정해져 있는 것 같다고 정리합니다. 어떻게 시키느냐를 떠나 어떤 일이냐에 따라 필요한 경우와 아닌 경우가 나뉘고, 대부분의 일에는 필요 없다고요.

이 판단을 뒤집으면 실용적인 기준이 나옵니다. 여러 갈래를 동시에 탐색해야 하는 일에는 쓸모가 있고, 정해진 절차를 정확히 밟으면 되는 일에는 부담만 늘어납니다.

모델이 바뀌면 다시 짜야 합니다

Ⅲ장과 Ⅵ장에서 두 번 확인한 내용입니다. 지금 잘 통하는 장치가 모델이 바뀌면 필요 없어지거나 오히려 방해가 됩니다. 성능이 약한 모델에 무거운 장치를 얹으면 더 못하게 된다는 관찰도 있었고요. 어떤 요령이든 유효 기간이 있다고 보고 시작하시는 게 안전합니다.

검증 자체가 어려운 문제입니다

가장 근본적인 한계입니다. 이 자료의 모든 방법이 검증을 축으로 돌아가는데, 검증을 잘하는 일 자체가 쉽지 않습니다. 스킬이 도움이 되는지 재려면 평가 데이터와 실험 환경이 필요하고, 자기 평가는 후하게 나오며, 사람이 채점하면 느리고 흔들립니다.

그래서 이렇게 정리하는 게 정직합니다. 검증을 자동화할 수 있는 만큼만 자율에 맡길 수 있습니다. 검증이 안 되는 영역까지 자율에 맡기면, 그건 자율이 아니라 방치입니다.

사람이 완전히 빠지면 어긋납니다

대담에서 시청자가 "개선하다가 다른 방향으로 흘러가는 경우가 많지 않으냐"고 묻자, 발표자가 그게 하네스의 역할이라고 답합니다. 사람이 순환 안에 하나도 안 들어가면 튀어 나갈 수 있고, 그걸 막기 위한 장치들이 하네스에 들어 있다는 겁니다.

완전 자율은 목표가 아닙니다. 개입의 빈도를 줄이되 개입의 지점을 정확히 두는 것이 목표입니다.

맺으며: 여섯 번째 단어를 만났을 때

지난 3년의 흐름을 한 문장으로 줄이면 이렇게 됩니다. 사람이 미리 정해 주던 것을 AI에게 넘기는 범위가 계속 넓어졌고, 넘길 때마다 사람의 일은 없어진 게 아니라 한 층 위로 옮겨 갔습니다. 지시를 쓰던 자리에서 정보를 고르는 자리로, 다시 실수를 막는 장치를 만드는 자리로, 그리고 순환의 규칙과 멈추는 조건을 정하는 자리로요.

그래서 다음에 여섯 번째 단어가 나오면 이렇게 물어보시면 됩니다.

이 말은 어떤 실패를 막으려고 생겼는가. 실패가 특정되지 않는 방법론은 아직 방법론이 아닙니다.

그 실패가 내 일에서도 일어나는가. 남의 실패를 막는 장치를 내가 달 필요는 없습니다.

이 방법으로 실제 돌아간 사례를 몇 개나 댈 수 있는가. 사례의 수가 그 말의 성숙도입니다.

내 일에서 무엇이 잘된 것인지를 글로 적을 수 있는가. 적을 수 있으면 맡길 수 있고, 없으면 아직 내가 봐야 합니다.

마지막 질문이 결국 남습니다. 도구가 아무리 좋아져도 무엇이 좋은 결과인지를 정하는 일은 넘어가지 않거든요. 그 자리가 앞으로 여러분의 자리입니다.

부록

부록 A. 용어집

부록 B. 연표

부록 C. 토론 질문

1. 여러분의 업무 중 "무엇이 잘된 것인가"를 한 문단으로 적을 수 있는 일과 그렇지 못한 일을 각각 두 가지씩 꼽아 보십시오. 두 부류의 차이는 어디에서 옵니까.
2. 하네스 무용론과 중심론 중 어느 쪽이 여러분의 상황에 더 맞습니까. 그렇게 판단한 근거는 시간 지평입니까, 업무 성격입니까, 아니면 다른 것입니까.
3. 개발자들이 코드를 안 보게 된 변화를 여러분의 분야로 옮기면 무엇을 안 보게 되는 것에 해당합니까. 그때 대신 무엇을 보아야 합니까.
4. "문서를 넣어서 챗봇을 만든 것도 학습이다"라는 정리에 동의하십니까. 동의하든 않든, 수강생에게 설명할 때 어떤 구분을 넣어야 오해가 없겠습니까.
5. 그래프 엔지니어링을 향한 회의적 평가(사례 부족)와 옹호(통제 이유가 달라졌다) 중 어느 쪽이 더 설득력 있습니까. 반년 뒤에 이 판단을 다시 확인하려면 무엇을 지켜봐야 합니까.

부록 D. 실습 과제

과제 1 — 채점표 먼저 쓰기. 평소 AI에게 맡기는 업무 하나를 고르십시오. 요청을 쓰기 전에 "무엇이 잘된 것인가"를 5~7개 항목으로 적으십시오. 그다음 (가) 채점표 없이 요청한 결과와 (나) 채점표를 함께 준 결과를 비교하고, 차이가 있었다면 어느 항목에서 생겼는지 적으십시오.

과제 2 — 지침을 목차로 바꾸기. 여러분이 AI에게 반복해서 설명하는 내용을 모두 적어 보십시오. 그것을 주제별로 3~5개로 나눈 뒤, 각 묶음을 가리키는 짧은 안내문 하나를 만드십시오. 한 파일에 다 넣었을 때와 나눴을 때 결과가 어떻게 달라지는지 기록하십시오.

과제 3 — 자기 평가의 편향 확인하기. 결과물을 하나 받은 뒤, 같은 대화창에서 스스로 평가하게 해 보십시오. 그다음 새 대화창을 열어 그 결과물만 주고 채점만 시키십시오. 두 평가가 얼마나 다른지 비교하고, 어느 쪽이 실제와 가까웠는지 적으십시오.

과제 4 — 유효 기간 확인하기. 여러분이 쓰고 있는 요령 하나를 고르십시오. 그 요령이 어떤 실패를 막으려고 생겼는지 적고, 지금 쓰는 모델에서도 그 실패가 여전히 일어나는지 실제로 확인해 보십시오. 안 일어난다면 그 요령은 지워도 됩니다.

부록 E. 참고문헌

원 대담과 발표 슬라이드, 그리고 본문에서 확인한 1차 자료를 종류별로 모았습니다. 모두 2026년 8월 8일에 접속해 확인했습니다.

기반 자료

• 변형호(노토랩). "하네스, 루프, 그래프 엔지니어링에 대해." 발표 슬라이드, 2026년 8월 2일. https://bustling-pea-9a9.notion.site/3b093e636af1801f84c8f97785a7704b

모델 제작사의 1차 기술 문서

• Young, Justin. "Effective harnesses for long-running agents." Anthropic Engineering, 2025년 11월 26일. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Rajasekaran, Prithvi. "Harness design for long-running application development." Anthropic Engineering, 2026년 3월 24일. https://www.anthropic.com/engineering/harness-design-long-running-apps
• Anthropic. "Effective Context Engineering for AI Agents." 2025년 9월. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Lopopolo, Ryan. "하네스 엔지니어링: 에이전트 우선 세계에서 Codex 활용하기." OpenAI, 2026년 2월 11일. https://openai.com/index/harness-engineering/
• OpenAI Developers. "Using Goals in Codex." https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex
• Claude Code Docs. "Keep Claude working toward a goal." https://code.claude.com/docs/en/goal

연구·업계 문헌

• Hong, Kelly, Anton Troynikov, and Jeff Huber. "Context Rot: How Increasing Input Tokens Impacts LLM Performance." Chroma Research, 2025년 7월 14일. https://www.trychroma.com/research/context-rot
• Yao, Shunyu, et al. "ReAct: Synergizing Reasoning and Acting in Language Models." arXiv:2210.03629 (2022).
• LangChain. "The Art of Loop Engineering." 2026년 6월 16일. https://www.langchain.com/blog/the-art-of-loop-engineering
• LangChain. "LangGraph: Multi-Agent Workflows." https://www.langchain.com/blog/langgraph-multi-agent-workflows
• Latent Space. "[AINews] Is Harness Engineering real?" https://www.latent.space/p/ainews-is-harness-engineering-real
• Latent Space. "Scaling Test Time Compute to Multi-Agent Civilizations — Noam Brown, OpenAI." https://www.latent.space/p/noam-brown

개론 자료

• Belcic, Ivan. "AutoGPT란 무엇인가요?" IBM Think. https://www.ibm.com/kr-ko/think/topics/autogpt
• Belcic, Ivan, and Cole Stryker. "BabyAGI란 무엇인가요?" IBM Think. https://www.ibm.com/kr-ko/think/topics/babyagi

미확인 항목

다음은 발표 슬라이드가 인용했으나 이 자료를 만들면서 본문을 직접 확인하지 못한 자료입니다. 인용하실 때 원문 확인이 필요합니다.

• Kyle. "Skill Issue: Harness Engineering for Coding Agents." HumanLayer. https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents
• swyx. "Loopcraft: The Art of Stacking Loops." 2026년 6월 12일. (요약만 확인)
• 페터 슈타인베르거의 그래프 엔지니어링 관련 게시물. (일자·문면 확인 필요)

이 자료의 작성 방식과 한계

이 자료는 41분 분량 대담의 전체 자막과 발표자의 슬라이드 원본을 확보한 뒤, 대담에서 언급된 문헌을 하나씩 직접 열어 대조하는 방식으로 만들었습니다. 대담의 발언 가운데 확인되지 않은 것은 정정 표시를 달았고, 실시간 채팅의 익명 진술은 검증 불가로 명시했습니다.

그럼에도 남는 한계가 있습니다. 첫째, 다루는 주제가 반년 단위로 바뀌는 영역이라 2026년 8월 8일 이후의 변화는 반영되어 있지 않습니다. 둘째, 대담 자체가 개발자 두 사람의 관점이므로 표본이 좁습니다. 셋째, 비개발 영역으로의 적용은 이 자료에서 제안한 해석이며 검증된 방법론이 아닙니다. 적용하실 때 이 세 가지를 함께 밝혀 주시기 바랍니다.