AI 에이전트 설계, 프롬프트 엔지니어링만으로는 안 되는 이유
n8n 블로그는 오래 도는 AI 에이전트의 성패가 프롬프트가 아니라 기억·재시작·검증 설계에서 갈린다고 짚었습니다.
n8n 블로그가 8월 31일 공개한 글에서 저자 앤드루 그린은 오래 돌아가는 AI 에이전트를 프롬프트만으로 만들 수 없다고 못 박았습니다. 모델은 글자를 받고 내놓는 부품일 뿐입니다. 언제 멈추고 어떻게 다시 이어갈지는 사람이 미리 설계해야 한다는 이야기입니다. 저자는 특히 작업이 잘 됐는지 AI에게 되묻는 방식을 가장 손쉽지만 가장 못 믿을 검증으로 지목했습니다. 업무 자동화를 준비하는 직장인에게도 남의 이야기가 아닙니다.
프롬프트, 컨텍스트, 루프로 이름만 바뀌었습니다
지난 몇 년 사이 자동화 현장의 유행어는 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로, 다시 루프 엔지니어링으로 옮겨갔습니다. 저자는 이름표만 갈아 끼웠을 뿐 같은 습관이 반복된다고 봅니다. 모델에게 더 좋은 지시문을 주면 알아서 끝까지 해내리라는 기대 말입니다.
구조를 뜯어보면 그 기대가 왜 무너지는지 드러납니다. 언어 모델은 이전 대화를 스스로 기억하지 못합니다. 그래서 매 호출마다 지금까지 오간 기록 전체를 다시 밀어 넣습니다. 대화가 길어지면 입력 한도를 넘습니다. 넘기 전부터 모델이 중심 지시를 놓치는 컨텍스트 부패가 시작됩니다. 채팅 화면은 기억이 이어지는 듯한 착시를 줄 뿐입니다.
글이 제시한 세 갈래 설계
기억을 모델 밖에 둡니다
첫째는 맥락과 기억입니다. 구글의 에이전트 개발 키트(ADK)는 오래된 대화 기록을 요약해 입력을 줄이는 압축 기능을 제공합니다. 공식 문서를 보면 방식이 두 가지입니다. 소비한 토큰(모델이 글을 처리하는 단위) 양이 기준값을 넘으면 압축하는 방식, 그리고 정해진 대화 턴마다 압축하되 앞뒤를 조금 겹쳐 두는 방식입니다. 구글은 비용과 응답 지연을 줄이려는 목적이라고 설명합니다.
저자는 여기에 저장 원칙을 덧붙입니다. 에이전트가 기록을 추가할 수는 있어도 지우거나 고칠 수는 없는 장부 형태로 남기라는 주문입니다. 기억을 만드는 작업은 본 작업과 떼어 뒤에서 돌리고 오래된 정보에는 만료 기한을 걸어 정리합니다.
중간에 멈춰도 이어집니다
둘째는 지속성 있는 실행입니다. 저자는 살려둘 대상과 버릴 대상을 나눕니다. 에이전트 상태, 저장된 표, 예약된 작업은 살려둡니다. 메모리에 떠 있는 변수, 돌아가던 타이머, 진행 중인 외부 호출은 버립니다. 작업이 오래 걸리면 붙잡고 기다리지 말고 잠들었다가 완료 신호를 받아 깨어나거나, 간격을 점점 늘려가며 다시 확인합니다.
복구도 같은 원리입니다. 장부를 되짚어 어디까지 했는지 확인하고 그 지점부터 이어갑니다. 저자는 이런 기능을 제공하는 도구로 DBOS, Restate, Inngest를 듭니다.
합격 판정을 기계에 맡깁니다
셋째 갈래의 비판이 가장 셉니다. 저자는 모델에게 채점을 맡기는 관행을 이렇게 정리합니다.
가장 쉬운 해법이면서 가장 믿을 수 없는 해법입니다. (n8n 블로그, 앤드루 그린)
대신 기계가 시비를 가릴 수 있는 신호를 쓰라고 권합니다. 응답 코드 확인, 정해진 형식대로 값이 들어왔는지 검사, 값들이 서로 앞뒤가 맞는지 보는 교차 필드 일관성 검사, 데이터가 실제로 바뀌었는지 다시 조회, 테스트 실행 순으로 신뢰도가 높다고 봅니다. 여기에 실행 전 완료 기준을 체크리스트로 적어두고 하나씩 지워가는 방식, 도구 호출이 같은 자리를 맴돌거나 토큰 사용이 갑자기 튀는지 감시하는 방식을 더합니다. 모델의 판단은 예 아니오로 답이 갈리는 좁은 질문에만 씁니다.
직장인에게 어떤 의미인가
당장 바꿀 수 있는 습관이 하나 있습니다. 자동화를 짜기 전에 성공 조건을 문장으로 적어두는 습관입니다. 보고서 초안 작성을 맡긴다면 지정한 폴더에 파일이 생겼는가, 표에 행이 늘었는가, 요청한 항목이 빠짐없이 들어갔는가처럼 눈으로 확인 가능한 조건이어야 합니다. AI에게 잘했냐고 묻고 잘했다는 답을 받는 절차는 검증이 아닙니다.
긴 작업을 한 덩어리로 던지지 않는 습관도 같이 갑니다. 단계를 쪼개고 각 단계가 끝날 때마다 결과를 남기면, 도중에 멈춰도 처음부터 다시 하지 않습니다. 도구를 고를 때는 실행 기록이 남는지, 실패한 단계만 다시 돌릴 수 있는지 미리 확인해 두면 좋습니다.
과장은 금물입니다. 이 글은 실험 결과나 성능 비교가 아니라 저자의 현장 판단과 벤더 문서를 엮은 정리입니다. 저자 스스로 단계별 청사진이 아니라고 밝혔고, 짧게 도는 에이전트로 충분하다면 그렇게 하고 가장 단순한 도구를 고르라고도 적었습니다. 사내 도입을 설득할 때 이 글 하나만 근거로 삼기는 어렵습니다.
정리
오래 도는 에이전트의 성패는 지시문 문장이 아니라 기억·재시작·검증을 어떻게 설계했느냐에서 갈립니다. 업무에 도입한다면 완료 조건을 기계가 확인할 수 있는 형태로 바꾸는 작업부터 시작하면 됩니다. 자동화 도구들이 이런 지속 실행 기능을 기본으로 품는지 지켜볼 만합니다.