프롬프트에서 하네스로, AI 개발 방식은 어떻게 바뀌었나

지시문만 다듬어서는 에이전트를 운영할 수 없다

2022년 ChatGPT 등장 이후 4년 동안 AI 개발 방식은 세 차례의 근본적인 전환을 겪었다. 출발점은 단일 지시문이었다. 이후 모델이 추론할 때 접하는 정보 환경 전체로 설계 범위가 넓어졌고, 2026년에는 에이전트를 둘러싼 시스템까지 통제해야 하는 단계에 이르렀다.

각 전환은 앞선 접근법의 한계에서 시작됐다. 2022년 말 ChatGPT가 공개되자 개발자들은 지시문의 작은 차이가 출력 품질을 크게 바꿀 수 있다는 사실에 주목했다. 하지만 모델에 복잡한 작업을 맡길수록 단일 프롬프트만으로는 해결할 수 없는 문제가 드러났다. 과거 대화를 기억하지 못하고, 외부 데이터에 접근할 수 없으며, 여러 단계로 이어지는 작업을 안정적으로 수행하기도 어려웠다.

컨텍스트 엔지니어링은 모델이 무엇을 알고 보고 기억한 상태에서 추론할지를 다룬다. 이 접근법으로도 수일 동안 자율적으로 일하는 에이전트의 정책, 상태, 실패 복구까지 관리할 수는 없다. 하네스 엔지니어링은 바로 그 운영 영역을 설계 대상으로 끌어들인다.

⤢✕

프롬프트가 제어하는 범위

프롬프트 엔지니어링은 모델에 전달하는 단일 입력 텍스트를 정교하게 구성해 출력을 조절하는 방법론이다. Chain-of-Thought(CoT) 프롬프팅, Few-Shot 예제, 역할 부여(persona assignment)가 대표적인 기법이다.

이 방식에서는 프롬프트 작성자의 언어적 구성 능력이 출력 품질에 큰 영향을 준다. 요청은 상태를 공유하지 않는 stateless 형태로 독립 처리되므로, 반복 작업이나 복잡한 워크플로우를 다루는 데 한계가 있다.

확장성도 문제였다. 복잡한 엔터프라이즈 환경에서 수천 개의 프롬프트를 체계적으로 관리하고 버전을 통제하기는 사실상 불가능했다. 모델이 활용할 수 있는 지식도 학습 데이터의 경계 안에 머물렀기 때문에 실시간 정보와 기업 내부 데이터를 이용할 수 없었다.

컨텍스트는 모델이 접하는 정보 환경이다

컨텍스트 엔지니어링은 추론 시점에 모델이 접근할 수 있는 정보 전체를 설계한다. 프롬프트는 그중 한 요소다. 검색된 문서와 메모리, 툴 출력, 대화 이력, 사용자 프로필도 같은 설계 범위에 들어간다.

Andrej Karpathy를 비롯한 업계 리더들은 “컨텍스트 엔지니어링이 새로운 프롬프트 엔지니어링”이라고 선언하며 이 변화를 강조했다. 2024년부터 RAG(Retrieval-Augmented Generation)와 MCP(Model Context Protocol)가 빠르게 채택되면서 컨텍스트 중심 접근법이 주류로 자리 잡았다.

⤢✕

검색 결과를 추론 가능한 지식으로 바꾸기

전통적인 RAG는 텍스트를 청크로 나누어 벡터로 임베딩한 뒤, 유사도 검색으로 관련 문서를 가져온다. 2026년에는 엔티티 사이의 관계를 그래프로 표현하고 복잡한 추론 경로를 지원하는 GraphRAG가 더욱 보편화됐다. 벡터 검색과 BM25 키워드 검색을 결합한 하이브리드 검색도 표준으로 자리 잡았으며, 검색 정밀도는 기존 대비 40~60% 향상됐다.

MCP는 모델이 데이터베이스 스키마, API 문서, 이슈 목록과 같은 실시간 정보에 접근하도록 연결하는 표준 프로토콜이다. 컨텍스트 구조에서 MCP는 모델이 접근할 수 있는 대상을 정의한다. 2026년 현재 9700만 다운로드를 기록하며 AI 컨텍스트 접근의 사실상 표준이 됐다.

메모리를 어디에 둘 것인가

컨텍스트 엔지니어링에서 메모리는 저장 위치와 접근 방법에 따라 구분된다.

**인-컨텍스트 메모리(In-Context Memory)**는 현재 컨텍스트 윈도우 안에 있는 정보다. 곧바로 사용할 수 있지만 토큰 비용이 높다.
**외부 메모리(External Memory)**는 데이터베이스, 벡터 스토어, 지식 그래프에 보관한다. RAG를 통해 검색할 수 있고 확장성이 높다.
**파라메트릭 메모리(Parametric Memory)**는 모델 가중치에 내재된 지식이다. 업데이트할 수 없지만 추론 비용은 없다.

실제 설계에서는 이 메모리 계층을 따로 보지 않는다. 작업에 필요한 정보를 적절한 시점에 꺼내 모델에 제공하도록 함께 조율한다.

긴 컨텍스트가 항상 유리하지 않은 이유

컨텍스트 윈도우는 유한하다. 2026년 현재 Claude 3.x와 GPT-4 계열 모델은 100K~200K 토큰을 지원하지만, 공간이 크다고 해서 모든 정보를 넣는 편이 좋은 것은 아니다. 컨텍스트가 지나치게 길면 핵심 정보를 놓칠 수 있으며, 이 현상은 “Needle in a Haystack” 문제로 알려져 있다.

긴 문서는 압축하거나 핵심 내용만 추출할 수 있다. 현재 작업과 관련된 정보만 동적으로 선택하고, 장기 대화의 과거 내용은 압축 요약(Summary Artifacts)으로 교체하는 방법도 사용한다. 반복되는 시스템 프롬프트에는 프롬프트 캐싱(Prompt Caching)을 적용해 API 비용을 70~90% 절감할 수 있다.

하네스는 에이전트의 힘을 시스템으로 통제한다

하네스(harness)는 원래 말의 힘을 제어하고 원하는 방향으로 이끄는 마구(馬具)를 뜻한다. AI 개발에서 하네스 엔지니어링은 에이전트의 능력을 안전하고 예측 가능하며 목적에 맞게 제어하는 시스템 전체를 설계하는 방법론이다.

2026년 초 하네스 엔지니어링은 독립된 패러다임으로 공식화됐다. 핵심 명제는 “에이전트 자체가 어려운 것이 아니다. 하네스가 어렵다.(Agents aren't hard; the Harness is hard.)”이다. OpenAI와 Anthropic이 공동으로 검증한 이 명제는 AI 개발 실패의 65%가 컨텍스트 드리프트, 스키마 불일치, 상태 열화와 같은 하네스 결함에서 비롯된다는 데이터로 뒷받침된다.

⤢✕

규칙 및 정책 엔진(Rules & Policy Engine)은 에이전트가 수행할 수 있는 작업의 경계를 정한다. 파일 시스템 접근 권한, API 호출 제한, 지출 한도, 보안 정책이 여기에 포함된다. 시스템 프롬프트에 지침을 적는 수준이 아니라 코드에서 강제하는 구조적 제약이다.

피드백 루프(Feedback Loop)는 에이전트의 행동을 계속 평가하고 수정한다. 자동화된 테스트, 사람의 검토(Human-in-the-Loop), 오류 감지와 자동 수정이 이 계층에서 작동한다. 피드백이 없다면 장기 실행 중 에이전트가 예측하지 못한 방향으로 표류(drift)할 수 있다.

인프라 및 관찰가능성(Infrastructure & Observability)은 에이전트가 내린 결정과 호출한 툴, 실패한 지점을 기록하고 추적한다. 2026년에는 KV 캐시 히트율(KV-cache hit rate)이 핵심 성능 지표로 부상했다.

워크플로우 제어(Workflow Control)는 여러 단계로 구성된 작업의 실행 순서와 의존성을 관리한다. 병렬 에이전트 조율, 체크포인트와 재시작, 작업 상태 영속성(state persistence)이 핵심 기능이다.

입력 최적화에서 지속 실행 관리까지

프롬프트, 컨텍스트, 하네스 엔지니어링은 서로 단절된 방법론이 아니다. 제어하는 범위가 단일 입력에서 정보 환경으로, 다시 실행 시스템 전체로 넓어진다.

⤢✕

하네스 엔지니어링의 대표적인 사례로는 OpenAI의 내부 소프트웨어 개발이 언급된다. Codex 에이전트를 하네스 엔지니어링으로 제어한 결과, 인간이 직접 작성하지 않고 100만 줄 이상의 코드를 생성했다. Cursor의 컴포저(Composer) 기능도 같은 원리를 적용해 에이전트의 코드 생성 품질을 크게 향상시켰다.

기업 환경에서 에이전트 실패의 65%를 차지하는 하네스 결함은 다음과 같이 나타난다.

컨텍스트 드리프트(Context Drift): 장기 실행 중 에이전트가 처음 설정한 목표에서 벗어난다.
스키마 불일치(Schema Misalignment): API나 데이터 구조가 바뀌었을 때 에이전트가 변경 사항을 처리하지 못한다.
상태 열화(State Degradation): 세션 사이에서 상태 정보가 손실되거나 오염된다.

기존 시스템 설계 원칙과 만나는 지점

하네스 엔지니어링은 새로운 이름을 사용하지만, 해결하려는 문제는 전통적인 IT 시스템 설계와 깊이 연결돼 있다.

신뢰성 공학 관점에서 피드백 루프와 관찰가능성은 SRE(Site Reliability Engineering)와 같은 철학을 공유한다. Mean Time Between Failures(MTBF)와 Mean Time to Recovery(MTTR)는 에이전트 시스템에서도 핵심 메트릭이다.

컨텍스트의 메모리 계층은 운영 데이터, 분석 데이터, 아카이브 데이터로 나누는 전통적인 데이터 아키텍처의 3계층 구조와 닮았다. 인-컨텍스트 메모리는 캐시 계층에, 외부 메모리는 운영 데이터베이스에, 파라메트릭 메모리는 사전 훈련된 도메인 지식에 대응한다.

보안 측면에서 하네스의 규칙 및 정책 엔진은 제로 트러스트(Zero Trust)를 에이전트 행동에 적용한 구조로 볼 수 있다. 최소 권한 원칙(Principle of Least Privilege)에 따라 작업을 완수하는 데 필요한 최소한의 권한만 에이전트에 부여한다. 정보관리기술사(情報管理技術士) 관점에서도 이 연결은 AI 도구의 변화보다 소프트웨어 아키텍처의 재구성에 가깝다.

컨텍스트와 하네스를 구성하는 도구

⤢✕

LlamaIndex와 LangChain은 RAG 파이프라인 구축에 널리 쓰이며, Mem0, Zep, Membase는 에이전트 메모리 관리에 활용된다. MCP는 Linux Foundation의 거버넌스 아래에서 표준화가 진행 중이다.

하네스 영역에서는 LangGraph가 상태 기반 에이전트 워크플로우를, AutoGen이 다중 에이전트 조율을 지원한다. Faros AI는 코딩 에이전트 하네스로 주목받고 있다. AWS, Google Cloud, Azure도 자체 에이전트 제어 플레인(Agent Control Plane) 서비스를 출시했다.

에이전트의 실행을 추적하고 평가하는 도구에는 Arize Phoenix, Langfuse, LangSmith가 있다. KV 캐시 히트율이 핵심 성능 지표로 자리 잡으면서 이를 실시간으로 관찰하려는 도구 수요도 급증했다.

조직의 전환은 인프라에서 시작한다

프롬프트 중심의 개발 체계를 한 번에 하네스 중심 구조로 바꾸기는 어렵다. 먼저 3~6개월 동안 RAG 파이프라인과 메모리 시스템을 구축하고 MCP 기반 툴을 연동한다. 이 과정에서 기존 프롬프트 엔지니어링 역량은 컨텍스트 설계로 확장된다.

그다음 6~12개월에는 에이전트 워크플로우를 정의하고 상태 관리 시스템과 기본 피드백 루프를 구현한다. 컨텍스트 설계와 하네스 제어가 이 구간에서 결합된다.

12개월 이상 이어지는 성숙화 단계에서는 완전한 관찰가능성, 자동화된 평가 시스템, 자기 개선(self-improving) 피드백 루프를 구현한다. 목표는 에이전트 시스템을 독립적으로 운용할 수 있는 수준까지 끌어올리는 것이다.

필요한 개발 역량도 함께 바뀐다. 프롬프트 엔지니어링에는 언어적 직관과 프롬프트 패턴 지식, 모델 행동에 대한 이해가 필요했다. 컨텍스트 엔지니어링에서는 정보 아키텍처, 벡터 데이터베이스, RAG 파이프라인 설계가 중요해졌다. 하네스 엔지니어링은 분산 시스템 설계, 신뢰성 공학, 에이전트 워크플로우 오케스트레이션, 보안과 거버넌스까지 요구한다.

2026년에 가장 수요가 높은 AI 개발자는 이 세 패러다임을 모두 이해하고 상황에 맞게 적용할 수 있는 “멀티패러다임 AI 엔지니어”다.

에이전트가 자신의 실행 환경을 고치는 단계

하네스 엔지니어링 다음에는 에이전틱 하네스 엔지니어링(Agentic Harness Engineering)이 부상하고 있다. 일반적인 하네스 엔지니어링이 인간이 에이전트를 위한 환경을 설계하는 방법론이라면, 에이전틱 하네스 엔지니어링은 에이전트가 자신의 하네스를 검사하고 수정하며 테스트하고 개선하는 자기 발전 시스템을 다룬다.

Claude의 “Dreaming” 기능은 세션 종료 후 패턴을 추출하고 자기 개선 메모리를 만드는 이 방향의 첫 번째 상용화 사례다. 에이전트가 실패 패턴을 학습하고 하네스 규칙을 스스로 업데이트하는 능력은 AI 개발 패러다임의 네 번째 전환을 예고한다.

2022년부터 2026년까지 제어 대상은 프롬프트에서 컨텍스트로, 다시 하네스로 확대됐다. 각 단계는 앞선 방법을 폐기하지 않고 그 위에 새로운 시스템 계층을 추가했다. 2026년의 핵심 변화는 더 좋은 모델을 선택하는 문제보다 에이전트의 목표, 정보, 권한, 상태, 피드백을 하나의 실행 환경으로 설계하는 문제가 중요해졌다는 데 있다.