프롬프트에서 자율 에이전트까지 — AI 에이전트 용어가 계속 바뀌는 이유

프롬프트 엔지니어링을 겨우 익혔더니 컨텍스트 엔지니어링이 나왔고, 그걸 따라가니 이번엔 하네스 엔지니어링이라고 합니다. 요즘은 그래프 엔지니어링이라는 말까지 들립니다. 또 무엇을 새로 배워야 하나 하는 피로감은 많은 사람이 느끼고 있을 겁니다.

다섯 용어를 순서대로 놓으면 매번 새 기술처럼 보였던 것이 사실은 하나의 질문에 대한 다른 답이었습니다.

AI를 얼마나 묶어 두고, 얼마나 풀어 줄 것인가?

1. 프롬프트 엔지니어링

처음에는 한 번 묻고 한 번 답을 받았습니다. 그래서 어떻게 물을지가 전부였습니다. "보고서 써줘" 대신 이렇게 쓰는 식입니다.

지난달 고객 문의 데이터를 바탕으로, 팀장 보고용 1페이지 요약을 써줘.
문의 유형별 건수와 전월 대비 변화를 표로 넣고, 개선 제안은 3개로 제한해줘.

ChatGPT의 GPTs도 이 시기에 나왔습니다. 프롬프트 한 겹으로 모델의 행동을 정하는 방식이었습니다.

문제는 일이 길어질 때 생겼습니다. 초기 자율 에이전트로 주목받은 Auto-GPT나 BabyAGI는 지금의 에이전트와 구조가 거의 같았습니다. 하지만 대화가 길어지면 성능이 떨어져서 대부분 기대만큼 작동하지 않았습니다.

사람들은 반대 방향을 택했습니다. AI를 믿을 수 없으니 처음부터 끝까지의 경로를 사람이 정한 것입니다. 여러 AI 호출을 체인처럼 이어 붙이고, 각 AI에게는 한 조각만 맡겼습니다. 2024년 무렵 LangGraph 같은 도구가 이 역할을 했습니다. 통제와 자율 두 방향 가운데 처음 자리 잡은 쪽은 이렇게 사람이 길을 정하는 결정론(정해진 길) 입니다.

2. 컨텍스트 엔지니어링

모델이 좋아지자 사람이 손으로 그리던 작업 흐름을 AI가 스스로 짜기 시작했습니다. 워크플로우가 사라진 것은 아닙니다. 에이전트 안으로 흡수됐습니다.

사람들은 더 길고 어려운 일을 맡기기 시작했고, 이번에는 대화창에 정보가 쌓이는 문제를 만났습니다. 여기서 나온 말이 컨텍스트 엔지니어링입니다. 컨텍스트(context)는 AI가 답을 만들 때 참고하는 모든 정보이고, 지시문/대화 기록/참고 문서/검색 결과가 다 여기에 들어갑니다.

"The only way to get better performance out of an LLM is to put better tokens in." (LLM의 성능을 높이는 유일한 방법은 더 좋은 정보를 넣는 것이다.)

중요한 것은 양보다 무엇을, 언제, 얼마나 넣느냐입니다.

• 양에 대해서는 실무자들 사이에서 대화창이 40% 정도 차면 품질이 떨어지기 시작한다는 말이 돕니다. 그때는 새 대화를 열거나 지금까지 내용을 문서로 정리해 넘기라고 권합니다.
• 같은 정보라도 놓인 위치에 따라 결과가 달라집니다. Nelson F. Liu 등이 발표한 논문 「Lost in the Middle」(TACL, 2024)은 긴 입력의 중간에 놓인 정보를 모델이 잘 찾지 못한다는 결과를 보였습니다. 긴 입력을 다루도록 만든 모델에서도 마찬가지였습니다.
• 큰 일은 여러 에이전트에게 나눠 맡기고, 에이전트마다 대화창을 깨끗하게 유지합니다.

3. 하네스 엔지니어링

긴 일을 시키자 AI가 일을 다 하지 않고 "끝냈다"고 말하는 실패가 드러났습니다. 이어서 하라고 해도 이미 많이 했으니 다 된 줄 알고 멈춥니다. AI가 한 말을 그대로 믿을 수 없으니 결과를 따로 확인하는 장치가 다시 필요해졌습니다.

프롬프트 한 장이 아니라 AI가 일하는 환경 전체를 설계하는 일이 하네스 엔지니어링입니다. 하네스(harness)는 원래 말에 채우는 마구를 뜻하는 단어입니다. Anthropic에서 에이전트 제품을 이끄는 Jess Yan은 하네스를 이렇게 정의합니다.

"the harness is the core scaffolding around the model that gives it the ability to run those tools and to call its memory" (하네스는 모델이 도구를 실행하고 기억을 불러올 수 있게 해 주는, 모델을 둘러싼 핵심 뼈대다.)

실무에서는 보통 다섯 가지 부품으로 하네스를 만듭니다.

이 가운데 규칙 문서는 안내할 뿐 강제하지 못합니다. Anthropic 공식 문서도 CLAUDE.md를 강제 설정이 아니라 참고할 맥락으로 다룬다고 적고 있습니다. 그래서 반드시 지켜야 하는 규칙은 훅이나 권한 설정으로 막아야 합니다.

결과를 가르는 변수는 모델보다 하네스 쪽에 있습니다.

• 하네스가 같으면 모델이 달라도 결과가 비슷해집니다. Peter Yang은 GPT와 Claude에게 같은 앱을 만들게 했는데, 두 결과물은 거의 구분되지 않았습니다. 공용 디자인 문서와 컴포넌트를 함께 줬기 때문입니다.
• 모델이 같아도 하네스가 다르면 결과가 갈립니다. 같은 모델과 같은 프롬프트를 Cursor와 Claude Code에 넣었더니 결과물이 크게 달랐다는 증언이 있습니다.

4. 그래프 엔지니어링

잘 만든 에이전트가 생기자 사람들은 에이전트가 사람 없이 알아서 돌게 만들었습니다. 목표 하나를 주면 스스로 판단하고, 안 되면 되돌아가 다시 시도합니다. 이 흐름을 루프 엔지니어링이라고 부르기도 합니다.

알아서 돌게 두자 누구에게 어떤 일을 맡길지, 검증은 언제 할지가 매번 달라졌습니다. 그래서 그 경로를 다시 정해진 길로 묶자는 말이 나왔고, 이것이 그래프 엔지니어링입니다.

Greg Isenberg는 프롬프트 엔지니어링을 더 나은 질문을 하는 법으로, 컨텍스트 엔지니어링을 더 나은 정보를 주는 법으로 구분하고, 그래프 엔지니어링을 이렇게 설명합니다.

"graph engineering is how you design the work around the AI so it lives as a managed workflow instead of one giant chat." (그래프 엔지니어링은 AI를 둘러싼 일 자체를 설계해서, 거대한 채팅 하나가 아니라 관리되는 작업 흐름으로 만드는 것이다.)

신사업 아이디어를 검증하는 일로 비교하면 차이가 드러납니다.

• 채팅 하나로 물으면 AI 하나가 무엇이 중요한지 정하고, 조사하고, 해석하고, 결론을 쓰고, 스스로 점수까지 매깁니다. 자신감 있는 답이 나오지만 그 답을 확인한 사람은 없습니다.
• 그래프로 나누면 기획 담당이 조사 관점을 나누고, 조사 담당 여럿이 동시에 파고들고, 반론 담당이 약한 근거를 걸러 내고, 정리 담당이 남은 근거를 한 장으로 모은 뒤, 마지막에 사람이 승인합니다.

흐름이 다시 결정론 쪽으로 돌아왔으니 2024년으로 되돌아간 것처럼 보일 수 있습니다. 이 계보를 정리한 한 대담은 차이를 이렇게 짚습니다.

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

예전의 통제는 실수를 막으려는 것이었고, 지금의 통제는 AI가 엉뚱한 방향으로 가지 않게 하려는 것입니다.

5. 자율 에이전트

흐름은 다시 자율 쪽으로 가고 있다고 저는 봅니다. 여기부터는 제 생각입니다.

그래프식 통제가 의미 있었던 것은 맞습니다. 하지만 모델이 훨씬 똑똑해진 지금은 하네스로 촘촘하게 묶기보다 목표만 주고 알아서 하게 두는 편이 더 잘 되는 경우가 많아졌습니다. 근거는 이렇습니다.

• 모델이 강해질수록 하네스에 담을 것이 줄어듭니다. 서로 다른 세 출처에서 같은 관찰이 독립적으로 나왔습니다.
• 규칙 문서가 길수록 덜 지켜집니다. Anthropic 공식 문서도 짧은 문서가 더 잘 지켜진다고 적고 있습니다.
• 무거운 하네스는 오히려 성능을 떨어뜨립니다. 남이 만든 스킬 묶음을 그대로 썼더니 문서가 너무 많아져 AI가 헤맸다는 경험담이 있습니다.

다만 자율은 통제를 모두 없애는 것과 다릅니다. 목표만 주더라도 끝까지 남는 것이 있습니다.

1. 완료 기준: 무엇을 끝낸 상태로 받을지
2. 검증: 정말 끝났는지 확인하는 장치
3. 차단: 절대 해서는 안 되는 행동을 막는 권한과 훅

빡빡한 절차는 덜어 내고 이 세 가지는 확실하게 남기는 것이 지금 우리가 설계해야 할 핵심이라고 생각합니다.

물론 반대 시각도 있습니다. 모델이 똑똑해질수록 엉뚱한 지름길을 찾는 능력도 커지니 그래프식 통제로 더 묶어야 한다는 주장입니다. 아직 정답이 정해진 이야기는 아니니 각자의 업무에서 직접 확인해 보시길 권합니다.

한눈에 보는 다섯 단계

새 용어는 앞의 것을 지우지 않고 흡수합니다. 좋은 질문, 좋은 정보, 좋은 환경은 다음 단계에서도 그대로 필요합니다.

지금 할 일

1. 용어는 다섯 번 바뀌었지만 질문은 "얼마나 묶고 얼마나 풀까" 하나였습니다.
2. 흐름은 통제와 자율 사이를 오갔고, 통제의 이유는 "실수 방지"에서 "의도 정렬"로 바뀌었습니다.
3. 모델이 강해진 지금은 촘촘한 절차보다 목표와 완료 기준을 잘 쓰는 능력이 더 중요해지고 있습니다.

새 용어를 모두 쫓을 필요는 없습니다. 이 계보를 다룬 대담도 결론은 신중했습니다. 그래프까지 다 배울 필요는 없고, 하네스까지만 익혀도 지금 풀려는 문제는 대부분 풀린다고 봤습니다.

이번 주에는 하나만 해 보세요.

내가 AI에게 자주 맡기는 일 하나를 고르고, "이 일이 끝난 상태는 무엇인가?" 를 한 문단으로 적어 보세요.

그 한 문단이 곧 프롬프트이고, 하네스의 기준이고, 자율 에이전트에게 건넬 목표입니다.