2026년 AI 에이전트 용어 정리: 프롬프트, 컨텍스트, 하네스, 루프, 그래프 엔지니어링

요즘 AI 에이전트 이야기를 조금만 따라가도 새 용어가 계속 튀어나옵니다. 프롬프트 엔지니어링은 익숙해졌는데 컨텍스트 엔지니어링이 나오더니, 하네스 엔지니어링이 붙고, 루프 엔지니어링이 뒤를 이었고, 이제는 그래프 엔지니어링까지 등장했어요. 새 단어가 나올 때마다 "내가 알던 게 벌써 낡은 건가" 싶어지죠.

먼저 결론부터 말씀드릴게요. 이 다섯 가지는 뒤엣것이 앞엣것을 밀어내는 세대교체가 아닙니다. 관심의 대상이 모델 안쪽에서 모델 바깥쪽으로 넘어가면서, 각 층에 이름이 하나씩 붙은 것에 가깝습니다. 그리고 다섯 중 둘은 아직 표준 용어라고 부르기 어려운 상태예요. 이 글에서는 각 용어를 누가 언제 처음 썼는지 1차 출처로 확인하고, 어디까지가 실무에서 검증된 이야기이고 어디부터가 아직 논쟁 중인지 구분해 드립니다.

다섯 가지 용어를 한눈에 보기

각 용어가 언제, 누구에게서 나왔는지 날짜로 정리하면 그림이 훨씬 선명해집니다. 아래 표의 기준일은 2026년 7월 29일입니다.

다섯 가지 용어를 한눈에 보기

이미지 출처: langchain.com

용어	명명하거나 유행시킨 사람	날짜	현재 상태
프롬프트 엔지니어링	특정 창시자 없음, 실무자 커뮤니티에서 굳음	2020~2021년경	정착된 표준 용어
컨텍스트 엔지니어링	Tobi Lütke, Andrej Karpathy가 증폭	2025-06-19, 2025-06-25	사실상 표준
하네스 엔지니어링	Mitchell Hashimoto가 명명, OpenAI가 공식화	2026-02-05, 2026-02-11	빠르게 정착 중
루프 엔지니어링	Addy Osmani가 명명	2026-06-07	신조어, 확산 중
그래프 엔지니어링	특정 저자 없음, X에서 발단	2026-07-18 전후	합의된 정의 없음

눈에 띄는 건 아래 두 줄입니다. 루프 엔지니어링은 이름이 붙은 지 52일, 그래프 엔지니어링은 11일밖에 되지 않았어요. 그래프 프레임워크 LangGraph를 만든 LangChain조차 자사 블로그에서 이 용어를 "X의 AI 콘텐츠 공장이 낳은 최신 용어"라고 부릅니다. 그러면서도 "버즈워드라고 부르고 싶어지는 것도, 그렇게 부르는 게 정확한 것도 사실이지만, 이 용어들은 이유가 있어서 생긴다"고 덧붙이죠. 실체가 있는 문제와 마케팅된 신조어가 같은 속도로 늘고 있다는 뜻입니다.

프롬프트와 컨텍스트 엔지니어링: 말할 것과 보여줄 것

프롬프트 엔지니어링: 모델에게 주는 지시문을 최적의 결과가 나오도록 쓰고 조직하는 방법입니다.

프롬프트와 컨텍스트 엔지니어링: 말할 것과 보여줄 것

이미지 출처: x.com

이 말이 언제 누구에게서 시작됐는지는 사실 깔끔하게 정리되지 않습니다. GPT-3가 나오던 2020년 무렵 실무자 커뮤니티에서 쓰이기 시작해 2021년 학술 문헌에 표기가 나타났다는 정도가 확인 가능한 범위예요. 프롬프트로 모델 행동을 끌어내는 관행 자체는 그보다 앞섭니다. 그러니 "누가 만든 말"이라고 단정하는 설명은 걸러 들으시는 게 좋습니다.

컨텍스트 엔지니어링: 모델이 답을 만드는 동안 어떤 정보를 보여주고 어떤 정보를 뺄지 선별하고 유지하는 전략 전체를 말합니다.

이쪽은 기원이 아주 명확합니다. 2025년 6월 19일 Shopify CEO Tobi Lütke가 X에 이렇게 적었어요. "프롬프트 엔지니어링보다 컨텍스트 엔지니어링이라는 말이 좋다. 핵심 역량을 더 잘 설명한다. LLM이 그 일을 풀 수 있게끔 모든 맥락을 제공하는 기술이다." 엿새 뒤인 2025년 6월 25일 Andrej Karpathy가 여기에 힘을 실으면서 용어가 퍼졌습니다. 그는 "다음 단계에 딱 맞는 정보로 컨텍스트 창을 채우는 섬세한 기술이자 과학"이라고 표현했어요. 개발자 Simon Willison도 같은 시기 정리 글을 남겼습니다.

여기서 자주 오해가 생깁니다. "이제 프롬프트 엔지니어링은 끝났다"는 식의 이야기인데, 1차 출처 어디에도 그런 말은 없어요. Anthropic은 2025년 9월 29일 공식 글에서 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 "자연스러운 다음 단계"라고 못박았습니다. 프롬프트는 컨텍스트의 부분집합이에요. 시스템 프롬프트를 잘 쓰는 일은 여전히 중요하고, 거기에 검색 결과나 툴 설명처럼 프롬프트 바깥에서 들어오는 정보까지 관리 대상에 들어온 것뿐입니다. 이 주제는 지금도 갱신 중이라, Anthropic은 2026년 7월 24일에도 Claude 5 세대를 겨냥한 후속 글을 내놓았습니다.

하네스 엔지니어링: 모델 바깥 전부를 설계하는 일

하네스 엔지니어링: 모델을 뺀 나머지 전부, 즉 에이전트가 일하는 환경을 설계하는 일입니다. 업계에서는 흔히 "에이전트 = 모델 + 하네스"로 요약합니다.

하네스 엔지니어링: 모델 바깥 전부를 설계하는 일

이미지 출처: langchain.com

하네스(harness)는 말에 채우는 마구를 뜻하는 단어예요. 말이 아무리 빠르고 힘이 좋아도 고삐와 안장이 없으면 원하는 곳으로 갈 수 없죠. 소프트웨어에서도 테스트 하네스, 평가 하네스라는 말이 먼저 있었고, 그 계보를 이어 에이전트 하네스가 됐습니다.

이 이름을 붙인 사람은 Terraform과 Ghostty를 만든 Mitchell Hashimoto입니다. 2026년 2월 5일 자신의 글에서 이렇게 썼어요. "업계에 널리 받아들여진 용어가 있는지는 모르겠지만, 나는 이걸 하네스 엔지니어링이라 부르게 됐다. 에이전트가 실수하는 걸 볼 때마다 그 실수를 다시는 하지 않도록 해결책을 설계해 넣는다는 발상이다." 본인이 "더 나은 용어가 있으면 갈아타겠다"고 덧붙였다는 점도 같이 기억해 두시면 좋습니다. 처음부터 표준을 선언한 게 아니라 편의상 붙인 이름이었어요.

엿새 뒤 OpenAI가 공식 글로 이 개념을 받았습니다. 내용이 꽤 구체적이에요. 빈 저장소에서 시작해 5개월 동안 사람이 코드를 한 줄도 직접 쓰지 않고, 엔지니어 3명(나중에 7명)이 Codex를 몰아 약 100만 줄의 코드와 약 1,500건의 PR을 만들었다고 보고했습니다. 엔지니어 한 명이 하루 3.5건의 PR을 낸 셈이죠. 이들이 말하는 핵심은 엔지니어의 일이 "코드를 쓰는 것"에서 "환경을 설계하고, 의도를 명세하고, 피드백 루프를 만드는 것"으로 옮겨간다는 겁니다.

숫자로 된 증거도 있습니다. LangChain은 2026년 2월 17일 실험에서 모델을 gpt-5.2-codex로 고정한 채 시스템 프롬프트와 툴, 미들웨어만 손봤습니다. 그 결과 Terminal Bench 2.0 점수가 52.8에서 66.5로 13.7점 올랐어요. 모델을 바꾸지 않고 환경만 다듬어서 낸 차이입니다. 이게 하네스라는 말이 빠르게 자리 잡은 이유예요.

정리도 계속 나오고 있습니다. Thoughtworks의 Birgitta Böckeler는 2026년 4월 2일 글에서 하네스를 유지보수 하네스, 아키텍처 적합성 하네스, 행동 하네스로 나누고 조종 루프(steering loop)라는 개념을 제시했고, Hugging Face는 2026년 5월 25일 용어집에서 층을 더 잘게 쪼갰습니다. 모델은 텍스트를 넣으면 텍스트를 내놓을 뿐이고, 스캐폴드는 모델이 세상을 보는 방식(시스템 프롬프트, 툴 설명, 기억 관리)을 정하며, 하네스는 실제로 모델을 호출하고 툴 실행을 처리하고 언제 멈출지 결정하는 실행 층이라는 구분이에요. 다만 Claude Code나 Codex 같은 제품 이야기를 할 때는 이 전부를 뭉뚱그려 하네스라고 부릅니다.

루프 엔지니어링: 프롬프트를 넣는 사람을 시스템으로 대체하기

루프 엔지니어링: 에이전트에게 매번 프롬프트를 넣는 사람의 자리를 시스템으로 대체하는 설계를 말합니다. 목적을 정의해 두면 AI가 완료될 때까지 반복하게 만드는 구조예요.

루프 엔지니어링: 프롬프트를 넣는 사람을 시스템으로 대체하기

이미지 출처: addyosmani.com

이 이름은 Google의 엔지니어링 리더 Addy Osmani가 2026년 6월 7일 자신의 블로그에 붙였습니다. 원문 표현이 인상적이에요. "루프 엔지니어링은 에이전트에게 프롬프트를 넣는 사람의 자리에서 스스로를 대체하는 것이다. 대신 그 일을 해 줄 시스템을 설계한다."

관행 자체를 그가 발명한 건 아닙니다. 코딩 에이전트를 오래 굴려 온 사람들이 이미 하던 일에 이름을 붙이고 구성요소로 정리한 쪽에 가까워요. 그리고 중요한 대목이 하나 있습니다. Osmani 본인이 같은 글에서 "아직 초기이고, 나는 회의적이며, 토큰 비용을 반드시 조심해야 한다"고 명시했어요. 홍보성 개념이 아니라 조건부 제안으로 내놓은 겁니다. 이 유보를 빼고 "이제 루프 엔지니어링의 시대"라고만 옮기면 원저자의 뜻을 왜곡하는 셈이 됩니다.

실무에서 루프를 짤 때 필요한 것은 네 가지로 정리됩니다. 언제 멈출지 정하는 종료 조건, 에이전트가 쓸 툴 접근 권한, 만든 쪽과 검사하는 쪽을 분리하는 검증 구조, 그리고 반복 사이에 유지되는 상태와 기억이에요. 이 중 실패가 가장 자주 터지는 지점이 종료 조건입니다. 멈출 조건을 흐리게 두면 무한 루프, 목표 표류, 토큰 비용 폭증이 한꺼번에 옵니다. Osmani가 비용을 조심하라고 한 이유도 여기 있어요.

그래프 엔지니어링: 발단이 풍자 트윗이었던 11일 된 말

그래프 엔지니어링: 에이전트의 실행 흐름을 열린 루프가 아니라 명시적인 그래프(상태 기계)로 모델링하는 접근을 가리킵니다. 다만 2026년 7월 29일 기준으로 합의된 정의는 아직 없습니다.

이 용어는 사연이 재미있습니다. 2026년 7월 18일 개발자 Peter Steinberger가 X에 한 줄을 올렸어요. "우리 아직 루프 얘기 중인가요, 아니면 벌써 그래프로 넘어갔나요?" 새 개념을 제안한 게 아니라 용어가 2주 간격으로 갈아치워지는 상황을 비꼰 문장에 가깝습니다. 좋아요 7,724개에 답글이 1,249개나 붙었는데, 좋아요 대비 답글이 이렇게 많다는 건 그만큼 논쟁이 붙었다는 신호예요.

그런데 나흘 뒤 LangChain이 이 트윗을 그래프 엔지니어링의 발단으로 지목하며 공식 정리 글을 냈습니다. 그래프 프레임워크를 만들어 파는 회사가, 자기 제품 영역의 신조어를 소개하면서 동시에 "버즈워드라고 불러도 정확하다"고 인정한 구도예요. 이 장면이 지금 커뮤니티 정서를 가장 잘 압축합니다. 문제는 진짜인데 용어 장사가 피곤하다는 것이죠.

내용으로 보면 가리키는 대상은 분명합니다. 노드는 결정론적 코드일 수도, LLM 호출 하나일 수도, 툴 호출일 수도, 자체 내부 루프를 가진 완전한 에이전트일 수도 있습니다. 엣지는 다음에 무엇이 올지를 정의하고, 조건부로 갈라질 수도 있어요. 헷갈리기 쉬운 두 가지만 짚고 갈게요. 첫 번째, 지식 그래프나 GraphRAG와는 다른 이야기입니다. 지식 그래프는 검색을 위해 데이터를 개체와 관계로 모델링하고, 그래프 엔지니어링은 실행 흐름을 모델링합니다. 같은 단어를 쓰는 다른 문제예요. 두 번째, 새로운 역량이 아니라 새로운 어휘입니다. LangGraph, AutoGen, Google ADK는 이 말이 생기기 전부터 그래프 오케스트레이션을 하고 있었어요.

반론도 세게 나왔습니다. 상태 관리 라이브러리 XState를 만든 David K는 2026년 7월 20일 글에서 이렇게 시작합니다. "처음엔 루프였다. 이제 그래프다. 다음 달엔 또 딴 게 될 거다." 그리고 "우리는 수십 년 된 소프트웨어 엔지니어링 패턴을 계속 재발견하고는 혁신이라며 재포장하고 있다"고 덧붙였어요. 그가 지목한 건 액터 모델과 상태 기계이고, 상태 기계의 본질을 (상태, 이벤트) → 다음 상태 한 줄로 요약합니다. 새 단어를 외우는 대신 오래된 패턴을 제대로 배우라는 이야기죠.

계단이 아니라 층위입니다

다섯 용어를 계단처럼 세우면 "지금은 그래프의 시대"라는 결론이 나오지만, 1차 출처들은 그렇게 말하지 않습니다. LangChain은 다섯을 나열하면서 "프롬프팅이든 에이전트든 루프든 그래프든 그건 구현 세부"라고 정리했어요. 층위로 겹쳐 보는 편이 실무에 훨씬 쓸모 있습니다.

층	무엇을 다루나	실무에서 하는 일	대표 산출물
프롬프트	모델에게 무엇을 말할까	지시문 작성과 구조화, 예시 제공	시스템 프롬프트
컨텍스트	모델에게 무엇을 보여줄까	넣을 정보와 뺄 정보 선별, 압축, 오염 관리	컨텍스트 관리 전략, 툴 설계
하네스	모델 바깥 환경을 어떻게 만들까	에이전트가 틀릴 때마다 다시 틀리지 않도록 환경을 고침	규칙 파일, 검증 스크립트, 린터
루프	누가 반복을 돌릴까	종료 조건과 검증자, 상태 설계	자동 반복 실행기, 제작과 검사 분리
그래프	흐름을 어떻게 명시할까	분기와 재시도, 장기 상태를 상태 기계로 표현	노드, 엣지, 상태 스키마

루프와 그래프의 경계도 실무 기준이 있습니다. Claude Code나 Codex 같은 코딩 에이전트가 보여주듯, 툴 접근만 잘 열어 주면 단순한 반복(행동하고 관찰하고 다시 행동하는 것)만으로도 실제 업무의 상당 부분이 처리됩니다. 워크플로가 갈라지기 시작할 때, 그러니까 전문 에이전트를 나누고 조건부 라우팅과 재시도가 붙고 상태가 오래 살아남아야 할 때 암묵적 루프는 관리 불가능한 if문 더미가 되고, 그때 그래프가 흐름을 눈에 보이게 만듭니다. 반대 경고도 함께 있어요. 대부분의 일은 작업 하나와 검증자 하나로 끝나며, 성급하게 그래프로 가면 없던 분산 시스템 문제를 새로 사게 됩니다.

이 흐름이 왜 2025년과 2026년에 몰려서 터졌는지도 설명이 됩니다. Anthropic이 2024년 12월 19일 글에서 워크플로와 에이전트를 구분한 게 출발점이에요. 워크플로는 LLM과 툴이 미리 정해진 코드 경로로 조율되는 시스템이고, 에이전트는 LLM이 스스로 프로세스와 툴 사용을 지휘하는 시스템입니다. 후자가 실용화되면서 모델 바깥을 부를 이름이 필요해진 거죠. 여기에 모델을 안 바꿔도 성능이 크게 움직인다는 증거가 쌓였고, 자율성이 올라갈수록 실패 비용이 커지면서 종료 조건과 검증이 성능 문제가 아니라 안전 문제로 승격됐습니다.

팀에서 무엇부터 손대면 될까요

용어를 다 외우는 것보다 중요한 건 순서입니다. 커뮤니티가 실제로 지적하는 지점을 보면 방향이 보여요.

하네스 관련 최대 규모의 Hacker News 토론은 옹호가 아니라 반론입니다. 2026년 7월 23일 올라온 HumanLayer의 "Why Software Factories Fail"에 390점과 댓글 270개가 붙었는데, 제목 자체가 "하네스 엔지니어링만으로는 부족하다"예요. 가장 많이 공감받은 지적은 이렇습니다. "프롬프트만으로는 필요한 정밀도까지 코딩 에이전트를 몰 수 없다. 깊은 프로그래밍적 검증 없이는 결과물이 늘 조금씩, 혹은 많이 어긋난다." 또 하나 뼈아픈 관찰도 있어요. "AI로 최고의 성과를 내는 팀은 원래 규율과 위생 수준이 높던 팀이었다."

이 두 문장이 사실상 실행 순서를 알려 줍니다. 테스트와 린터, 코드 리뷰, 배포 절차처럼 사람이 일할 때도 필요했던 기본기가 먼저입니다. 에이전트는 그 기본기를 빌려 쓰는 존재라서, 검증 장치가 없는 조직에 에이전트를 붙이면 틀린 결과물이 더 빨리 쌓일 뿐이에요. 그다음이 하네스입니다. 에이전트가 같은 실수를 반복할 때마다 규칙 파일과 검증 스크립트로 그 실수를 봉인하는 작업이죠. 루프는 이 두 가지가 갖춰진 뒤에 붙이는 자동화이고, 그래프는 루프가 관리 불가능해질 만큼 복잡해졌을 때 꺼내는 카드입니다. 참고로 컨텍스트 엔지니어링 자체는 여전히 최상위 관심사라서, Anthropic의 Claude 5 세대 컨텍스트 글은 2026년 7월 25일 Hacker News에서 462점과 댓글 402개를 기록했습니다.

QJC에서도 기업의 AI 전환을 도울 때 같은 순서를 씁니다. 새 용어를 도입하는 것보다, 그 팀이 이미 가진 검증 장치를 에이전트가 쓸 수 있는 형태로 정리하는 일이 먼저 효과를 내거든요.

마무리

다섯 용어를 한 문장씩으로 줄이면 이렇습니다. 프롬프트는 모델에게 무엇을 말할지, 컨텍스트는 무엇을 보여줄지, 하네스는 모델 바깥 환경을 어떻게 만들지, 루프는 그 반복을 누가 돌릴지, 그래프는 반복이 복잡해졌을 때 흐름을 어떻게 명시할지에 대한 이야기예요. 앞의 셋은 이미 자리를 잡았고, 루프는 확산 중이며, 그래프는 아직 정의가 합의되지 않았습니다.

그러니 새 단어가 나올 때마다 뒤처졌다고 느끼실 필요는 없어요. Anthropic이 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 다음 단계라고 표현한 것처럼, 이 계보는 무언가를 폐기하며 나아가지 않습니다. 지금 팀에서 에이전트가 반복해서 틀리는 지점이 있다면, 그걸 다시는 틀리지 않게 만드는 장치를 하나 만들어 보세요. 그게 하네스 엔지니어링의 전부이고, 나머지 용어는 그 위에 얹히는 이야기입니다.

자주 묻는 질문 (FAQ)

Q: 프롬프트 엔지니어링은 이제 필요 없어진 건가요?

아닙니다. Anthropic은 2025년 9월 29일 공식 글에서 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 "자연스러운 다음 단계"라고 표현했어요. 프롬프트는 컨텍스트의 부분집합이라서, 시스템 프롬프트를 잘 쓰는 능력은 여전히 그대로 필요합니다.

Q: 하네스 엔지니어링은 구체적으로 무슨 일을 하는 건가요?

에이전트가 실수할 때마다 그 실수를 다시 하지 않도록 환경을 고치는 일입니다. 규칙 파일을 다듬거나, 검증 스크립트와 린터를 붙이거나, 결과를 스크린샷으로 확인하게 만드는 식이에요. LangChain은 모델을 고정한 채 이 환경만 손봐서 Terminal Bench 2.0 점수를 52.8에서 66.5로 올린 사례를 공개했습니다.

Q: 루프 엔지니어링과 그래프 엔지니어링, 지금 바로 도입해야 하나요?

서두를 이유는 없습니다. 루프 엔지니어링은 명명된 지 두 달이 채 안 됐고, 이름을 붙인 Addy Osmani 본인이 "아직 초기이고 회의적이며 토큰 비용을 조심해야 한다"고 밝혔어요. 그래프 엔지니어링은 2026년 7월 29일 기준 등장한 지 11일 정도이고 합의된 정의가 없습니다. 대부분의 작업은 작업 하나와 검증자 하나로 충분합니다.

Q: 그래프 엔지니어링은 지식 그래프나 GraphRAG와 같은 말인가요?

다릅니다. 지식 그래프는 검색을 위해 데이터를 개체와 관계로 모델링하는 방식이고, 그래프 엔지니어링은 에이전트의 실행 흐름(다음에 어느 단계가 돌고 어떤 상태를 넘겨받는지)을 모델링합니다. 같은 단어를 쓰지만 푸는 문제가 서로 다릅니다.

2026년 AI 에이전트 용어 정리: 프롬프트, 컨텍스트, 하네스, 루프, 그래프 엔지니어링

쏟아지는 AI 용어, 질문 5개면 끝나요 - 비개발자를 위한 쉬운 가이드