AI를 활용할 때는 업무 전체를 살펴보고 활용하는 능력이 중요하다는 것은 이제 더 이상 논란의 여지가 없는 주장일 겁니다.

거기에 최근 흐름이 AI 에이전트인 만큼 업무에 대한 이야기도 중요하지만, 이를 활용하기 위한 사전 지식도 상당히 중요합니다.

그렇기에 첫 글로 전체 AI이야기의 흐름을 쭉 따라가 보는 글을 준비했습니다.

최근 트렌드는 단순하게 AI에게 응답을얻는것이아닌 AI에이전트 즉 사용자가 지정한 목표를 이루기 위해 상황을 판단하고, 계획을 세우고, 필요한 행동을 수행하는 소프트웨어 시스템을 만드는 것을 목표로 하고있습니다.

그런데 그놈의 AI에이전트가 뭘까요? 오늘날 말하는 AI 에이전트의 발상을 이해할 때 추천하는 논문은 Wooldridge와 Jennings의 「Intelligent Agents: Theory and Practice」입니다.

핵심 문장을 먼저 보시면 다음과 같습니다.

위와같은 정의가 나온 논문으로, 최근 AI 에이전트 이론의 많은 이야기가 여기서 시작되었다고 봐도 무방합니다. 이 이야기를 시작하면 1950년대까지 올라가야 하니 우선은 고루한 역사 여기에서 잠깐 멈춰 두고 핵심을 이야기해 봅시다.

위 논문에서 논해야 할 이야기는 많지만, 핵심만 뽑아 보자면 AI 에이전트를 네 가지 속성으로 정의합니다.

지금도 많이 이야기되는 개념이 1995년 논문에서 나왔다는 사실도 상당히 흥미롭습니다.

우선은 여기에서 출발해 많은 발전이 이루어졌다는 사실을 기억하고, 시계를 돌려 2023년으로 날아가 봅시다. AI 에이전트가 최근에 대두된 개념이라고 생각하실 수 있지만, 2023년과 2024년 당시에도 AI 에이전트는 존재했습니다.

GPT-4 기반의 에이전트는 있었지요. 다만 컨텍스트 윈도나 여러 제약 조건으로 인해 성능이 매우 낮았고, 툴 콜링, 즉 다른 도구를 가져다 쓰는 능력도 매우 부족했죠 그렇기에 LangChain, LangGraph 등 여러 방법론이 등장했으며, 당시 실무자들이 AI를 잘 활용하기 위한 다양한 방법론이 제시했습니다.

다만 니치한 영역에 머물러 일반인들에게 주요 키워드로 인식되지는 않았습니다. 그렇다면 이 이야기가 왜 중요할까요?

그래서 대체 요즘유행하는 엔지니어링이 뭐야?

우선 최근에 유행하고 있는 말들을 정리해 볼까요?

단순하게 정리하자면 다음과 같은 용어들이 계속해서 등장하고 있습니다

굉장히 많고 다양해 보이지만, 필요에 의해 만들어진 키워드일 뿐이에요.”

굳이 모두 이해하실 필요는 없지만, 이해하면 도움이 된답니다.

이러한 용어를 바탕으로 실제 내용을 한 번 더 톺아보죠.

그렇다면 그놈의 엔지니어링이 왜이렇게 많은가?

우선 이에 대해 논하기 전에 이야기해야 하는 부분이 있습니다.

이 다섯 가지는 간단하게 보면 키워드가 순서대로 발전해 왔으며, 이전의 하위 개념이 필요 없어졌다고 생각할 수 있습니다.

하지만 프롬프트가 낡아서 컨텍스트로 교체된 것도 아니고, 루프보다 그래프가 무조건 높은 단계인 것도 아닙니다.

한 번의 호출에도 프롬프트가 필요하고, 그래프로 구성한 시스템에서도 각 노드에 들어갈 컨텍스트와 도구 인터페이스를 설계해야 합니다.

일이 길고 위험해질수록 다뤄야 하는 설계 대상이 늘어났다고 보는 편이 좋겠지요.

갑자기 복잡한 말이 나와서 어렵죠? 예시를 보며 문제를 하나 풀어 볼까요?

이 과제를 푼다고 생각해 봅시다.

물론 지금의 모델들은 이 문제를 곧잘 푸는 것처럼 보입니다.

제법 그럴듯한 문서가 나오는 것이 사실이지만, 많은 분과 이야기해 보면 대개 비슷한 문제가 반복됩니다.

출처가 오래됐고, 숫자 하나는 원문과 다르며, 경쟁사 한 곳이 빠지고, 믿을 수 없는 주장을 하는 경우도 있지요. 여기에 늘 들어가는 프롬프트가 있습니다

숫자는 고쳤지만 보고서 구조가 이상해지거나, 특정 부분만 고치고 결론이 그대로 나오는 문제가 계속해서 발생합니다.

이렇게 입력하니 문서는 좋아졌지만, 토큰을 너무 많이 사용하고도 같은 검색을 반복하는 등의 문제가 발생했습니다.

그렇다면 이러한 실패를 전부 단순하게 “프롬프트를 더 자세히 써야 한다”는 방법으로 해결할 수 있을까요?

실제로 유명한 프롬프트 작성법처럼 역할, 목표, 제약 조건, 출력 형식을 명확히 적으면 모델이 모든 내용을 인지하고 실행하는 것처럼 보입니다.

그런데 정작 결과물은 그대로 인 경우가 허다하고 더 큰 문제는 장시간, 즉 2~3시간 정도 걸리는 일을 시키려면 어떻게 해야 하느냐는 것입니다.

어떤 자료를 참고할지, 어떤 도구를 사용할지, 실패하면 어디서 다시 시작할지, 여러 조사 결과를 어떻게 합칠지까지 제대로 입력하지 않으면 평균적인 내용을 내뱉게 됩니다. 사실상 전체 구조를 설계해야 하는 것이지요.

그렇다면 이것은 어떻게 지시해야 할까요?

 프롬프트가 모델의 임시 프로그램이 되다

이야기는 2020년 GPT-3의 In-context Learning으로 거슬러 올라갑니다.

이때까지만 해도 LLM에서 원하는 응답을 얻으려면 모델의 가중치를 다시 학습시켜야 한다는 인식이 연구의 대세였습니다.

그런데 프롬프트와 관련된 여러 실험을 진행한 학자들은 자연어 지시와 몇 개의 예시만 입력해도 모델이 새로운 작업을 수행할 수 있다는 점을 발견했습니다.

물론 이에 대해서도 할 이야기가 매우 많지만, 여기에서 우리가 기억해야 할 사실은 랜덤한 확률에 따라 결과가 도출되던 시스템을 어느 정도 제어할 수 있는 방법이 추가되었다는 것입니다.

위 이미지는 GPT-3를 실제로 웹사이트 내에서 구현한 사례입니다. 이론적인 QKV 행렬 연산 등이 사용자에게 반드시 중요한 개념은 아니고, 그냥 저런 복잡한 연산을 한다는 정도로 이해하면 됩니다.

여기에서의 핵심은 LLM이라는 녀석은 확률을 기반으로 모든 것을 처리하지만, 이 확률을 어느 정도 제어할 수 있게 되었고 프롬프트는 결국 내가 원하는 응답을 끌어내는 도구가 되었다는 것이겠지요.

여기에서 프롬프트를 모델의 임시 프로그램이라고 부르는 이유가 나옵니다.

입력되는 프롬프트는 확률을 기반으로 작동하기 때문에 결정적인 프로그램처럼 언제나 같은 결과를 보장하지는 않습니다.

그렇지만, 한 번의 호출 동안 모델이 따라갈 목표와 작업 방식을 지정하는 인터페이스로 활용할 수 있으며, 이를 바탕으로 결정론적인 워크플로를 만들 수는 있습니다.

직관적으로 말하면 말하면 알아듣는것처럼 보인다는거에요

그렇기에, 많은 분이 AI를 계속 사용하면서 다음과 같은 고민을 하게 됩니다.

“AI가 일을 못 하는 것이 아니라, 내가 일을 충분히 자세하게 설명하지 않은 것 아닐까?”

솔직히 저는 “질문만 잘하면 된다”는 말을 굉장히 싫어합니다.

현대의 LLM에는 단순히 질문만으로 해결되지 않는당면 과제가 엄청나게 많습니다. 그렇기에 역할, 목표, 절차, 제약 조건, 출력 형식, 예시 등 수많은 방법론을 프롬프트에 세세하게 적기 시작했고, 이제는 그것만으로 해결되지 않아 물리적인 브레이크까지 만들고 있으니까요.

컨텍스트 엔지니어링은 왜중요한가?

최근 받은 질문중 이런게 있습니다. AI의 작동원리를 왜 이해해야하나요?

정말 그렇게 차이가 나나요? 아래 글을 잠깐 읽어보시죠

우선 우리가 이해해야 하는 것은 Claude Code의 구조입니다. 작업 과정에서 모델이 수십 번 호출되면 최초 요구 사항, 시스템 지침, 계획, 검색 결과, 오류 로그, 생성 파일, 테스트 결과, 남은 할 일이 계속해서 쌓입니다.

물론 이 과정을 전부 호출에 넣으면 모델이 작업 내용을 완벽하게 기억할 것이라고 착각하는 분들이 많습니다.

 우선은 컨텍스트가 조금 복잡해진 예시를 봅시다.

제팔로워 분들이라면 이장표를 한번쯤 보셨을겁니다.

「  llms get lost in multi-turn conversation 」   이라는 논문에 나왔던 질문으로 바로 chat gpt 5.6sol로 실행시켜봤습니다.

실제로 ChatGPT 안에서 매우 간단한 질문만 던져도 이러한 문제가 발생합니다.

그렇다면 훨씬 더 거대한 작업을 수행하는 Claude Code에서는 어떨까요?

방금 추가한 오류 로그만 붙들고 최초 요구 사항을 잊거나, 긴 문서 한가운데 있는 필수 조건을 건너뛰거나, 내용이 누락되는 등의 문제가 비슷하게 발생할 가능성이 상당히 높겠지요.

「Lost in the Middle」 연구는 다중 문서 질의응답과 합성 키-값 검색에서 관련 정보의 위치만 달라져도 성능이 달라질 수 있음을 보여 주었습니다.

많은 모델이 시작과 끝에 있는 정보는 비교적 잘 활용하지만, 가운데 있는 정보를 활용해야 할 때 성능이 떨어지는 U자형 경향을 보였습니다.

물론 AI가 발전하면서 이러한 현상이 모든 최신 모델과 모든 장문 작업에서 같은 폭으로 나타나는 보편적인 법칙이라고 보기는 어렵습니다. 그래도 최신 AI 서비스를 사용하며 확실히 말할 수 있는 것은 지원되는 컨텍스트 길이와 그 안의 정보를 안정적으로 이용하는 능력이 같은 의미는 아니라는 점입니다.

경험론적으로 이야기하면 “모든 AI 서비스는 첫 프롬프트에서 가장 똑똑하다”는 감각 정도는 다들 가지고 계실 겁니다. 그래서 기억을 작업장에 남겨 지속적으로 어떤 문제를 해결해야 하는지 관리하는 방법을 고민하지요.

문제는 단순하게 여기까지만 고려하는 것이 아니라는 점입니다.

Anthropic은 컨텍스트 엔지니어링을 추론 시점에 들어갈 최적의 토큰 집합을 선별하고 유지하는 전략으로 설명합니다.

실제 2025년에 나온 공식 문서를 살펴볼까요?

시스템 프롬프트뿐만 아니라 도구 설명, 외부 데이터, 메시지 기록도 여기에 포함됩니다.

최근에 나온 글을 확인해 보면 기존 규칙에서 내용을 서서히 줄여 나가는 방식으로 명령을 간결하게 구성하라는 이야기도 등장합니다.

문제는 실무에서는 질문이 훨씬 어려워진다는 점입니다.

지금 판단하는 데 꼭 필요한 정보는 무엇인가?

무엇을 요약하고 무엇을 원문으로 남길 것인가?

모든 검색 결과를 미리 넣을 것인가, 파일 경로나 URL 같은 가벼운 식별자만 두고 필요할 때 가져올 것인가?

도구 열 개를 한꺼번에 보여 줄 것인가, 현재 단계에 필요한 세 개만 노출할 것인가?

오래된 결정과 새로운 결정이 충돌할 때 무엇을 버릴 것인가?

각각의 문제는 단순해 보이지만, 실제로는 복잡한 문제들이 얽혀 있습니다. 여기에 호출 비용도 살펴봐야 합니다.

누적 입력량은 턴 수가 늘어남에 따라 대략 제곱에 비례해 증가할 수 있습니다. 호출할 때마다 앞의 내용을 지속적으로 다시 읽어야 하기 때문입니다. 다만 요약, 캐시, 검색, 상태 델타 전송 등을 활용하면 실제 비용 곡선은 달라집니다.

따라서 컨텍스트 관리는 이에따른 반복 비용및 활용 효율성을 좌우하는 핵심적인 지표라고 봐도 무방하겠지요

 하네스는 모델이 일하는 사무실이다

긴 문서 작업이나 코딩 작업을 에이전트에게 맡겼다고 가정해 봅시다.

자료를 조사하고, 각 문서를 분석하고, 계산하고, 글을 쓴 다음 문서화합니다. 문제는 각 단계에서 어떤 일을 해야 하는지, 어떤 작업을 수행해야 하는지, 가장 중요한 완료 조건이나 정리 조건은 무엇인지 정의해야 한다는 것입니다. 일반인들은 이것을 어떻게 정리해야 할지 몰라 굉장히 어려움을 겪으시지요.

하네스는 넓게 보면 모델을 둘러싼 실행 환경 전체를 의미합니다.

시스템 프롬프트, 도구와 API, 파일 시스템, 권한, 작업 큐, 장기 메모리, 체크포인트, Git 이력, 테스트, 로그, 관측 장치, 오류 복구, 예산과 중단 조건 등이 모두 포함됩니다.

그러니까 “우리가 엄청나게 큰일을 AI에게 시키고 싶다”는 문제를 해결하기 위해 나온 방법론인 것이죠.

말이 많이 복잡하죠?

기본적으로 CLAUDE.md 파일이나 SKILL.md 파일을 만든다는 이야기는 많이 들어 보셨을 겁니다.

프롬프트가 규칙을 넣어 주는 것이라면 하네스는 사무실, 업무 시스템, 출입 권한, 결재선, 품질 관리 체계를 합친 회사의 운영체제를 만드는 것입니다.

한마디로 모델에 조금 더 많은 권한을 부여하면서도, 동시에 물리적인 브레이크를 설계하는 것이지요

루프 엔지니어링이란 무엇인가?

우리는 지금까지 하네스를 살펴보면서 수많은 브레이크와 절차, 복잡한 내용들을 설계해야 한다는 이야기를 나누었습니다.

다만 여기에서 또 다른 문제가 발생합니다.

“이것들이 제대로 작동할까?”

“오류가 발생하면 처음부터 다시 해야 하지 않나?”

이러한 고민이 생기게 되지요.루프 엔지니어링을 설명하는 말은 많습니다.

테스트, 빌드, 정적 분석, 스키마 검사, 출처 확인 같은 장치가 잘못된 생성을 거부해야 하고, 실패한 작업은 다시 실행해야 합니다.

말이 더럽게 어렵지만 직관적으로 보면, 결국 실패 조건을 지정해 두고 목표에 도달하지 못하면 다시 시도하는 방법론입니다. AI를 완전히 신뢰할 수 없기 때문에 반복과 검증을 설계하는 것이지요.

하네스를 통해 단계를 잘게 쪼개고 나누는 방법론에는 익숙해졌습니다. 하지만 작업이 길어질수록 작은 오류가 누적되며, 결국 이러한 오류가 전체 실패로 이어집니다. 그래서 반드시 성공해야 하는 작업을 100개의 단계로 나누는 것입니다.

가정해 볼까요?

각 단계의 성공 확률이 서로 독립적이며 모두 99%라고 가정해 봅시다. 100단계를 거칠 때 전체 과정이 한 번에 성공할 확률을 산술적으로 계산하면 다음과 같습니다.

0.99¹⁰⁰ ≈ 36.6%

LLM이 확률을 기반으로 작동하는 녀석이기에 우리에게는 다른 선택지가 없습니다.

실제로 각 단계는 완전히 독립적이지 않으며, 앞 단계의 오류가 뒤 단계의 입력을 오염시킬 수도 있으므로 위험은 더욱 커질 수 있습니다.

결국 이러한 AI를 완전히 신뢰할 수 없기에 만들어진 방법론이라고 이해하셔도 무방합니다.

 그래프 엔지니어링이 이슈가 되다

2026년 7월, 그래프 엔지니어링이라는 말이 이슈가 되었습니다.

7월 11일 Peter Steinberger가 X에서 “아직 루프를 이야기하는가, 이제 그래프로 넘어갔는가”라는 질문을 던졌지요.

매우 짧은 트윗이었고, 그의 글에는 ‘Graph Engineering’이라는 정확한 표현도 없었으며 새로운 기술을 발표한 것도 아니었습니다.

다만 LangChain은 7월 22일 공개한 공식 글에서 그 주말의 논의가 이 질문으로 촉발됐다고 정리했습니다. 마치 안드레 카파시가 바이브 코딩을 이야기한 뒤 모두가 그 용어를 사용하기 시작한 것과 비슷한 상황이었지요.

다만 LangChain은 해당 글에서 그래프로 에이전트를 구성하는 실무 자체는 새로운 것이 아니라고 동시에 선을 그었습니다. 그래프 엔지니어링이라는 개념 자체가 완전히 새로운 것은 아니었기 때문입니다.

그렇다면 그래프 엔지니어링은 무엇이고, 왜 하필 이 이름이 널리 퍼졌을까요?

항상 방향은 같습니다. 루프만으로 해결하기 어려운 문제들이 계속해서 발생했기 때문입니다.

실무로 갈수록 선형적으로 업무를 처리하는 구조를 복잡한 비선형 구조로 확장하고 싶어집니다. 에이전트 루프는 자유롭지만, 병렬 조사, 전문 에이전트 간 인계, 사람의 승인, 실패 복구 등이 늘어나면 어떤 경로가 유효한지 통제하기 어려워집니다.

결국 LangChain에서 이야기한 핵심은 “노드의 크기가 달라졌다”는 것입니다.

초기 그래프에서 하나의 노드는 고정된 코드나 단일 모델 호출인 경우가 많았습니다. 하지만 이제는 내부에서 계획을 세우고, 도구를 호출하고, 여러 번 검증하는 에이전트의 실행 전체를 하나의 노드로 둘 수 있다는 것이지요.

조금 더 직관적으로 설명하면 다음과 같이 정리할 수 있습니다.

“일의 단위를 겁나 키울 거야!”

여기까지 쭉 살펴보면서 어떠셨나요? 쉬운 내용은 아니었습니다. 나름대로 쉽게 정리한다고 했지만, 간단한 문제는 아니었던 것 같습니다. 다음 시간부터는 하나하나 짚어 가며 세세하게 이야기해 보도록 하지요.