.jpg&blockId=33d5bbc0-e5c2-806a-bb96-e7653c5da3be&width=3600)
Prompt → Context → Harness
저는 요즘 프롬프트를 거의 쓰지 않습니다.
정확히 말하면 프롬프트를 고민하지 않습니다. 1년 전만 해도 ChatGPT 앞에 앉으면 제일 먼저 하는 일이 프롬프트를 다듬는 거였거든요. “너는 데이터 엔지니어링 전문가이고, 광고 도메인 전문가이며 …중략… 지금 이걸 제대로 해내지 않으면 심각한 문제가 발생할 수 있으니 깊게 생각해서 답변해줘” 이런 것들이요. 커뮤니티에서 프롬프트 템플릿이 돌면 북마크하고, 누가 이 프롬프트 쓰면 GPT가 진짜 다르게 답한다고 하면 바로 따라 해봤습니다.
지금 더 중요하게 느껴지는 건 프롬프트 자체보다 모델에게 무엇을 보여주고, 어떤 환경에서 일하게 하느냐입니다. 어떤 문서를 붙이고 어떤 도구를 연결하고 어떤 상태를 넘길지, 모델 바깥의 실행환경을 어떻게 설계할지 같은 부분들이요. 그러다 보니 제가 요즘 보고 있는 변화도 자연스럽게 그 축으로 정리됩니다. Prompt Engineering → Context Engineering → Harness Engineering. 그 위에서 여러 에이전트와 도구, 인간 검토를 함께 다루는 운영과 감독의 문제까지요.
시작하기 전에 한 가지 먼저 말해두자면, 프롬프트 엔지니어링이 필요 없어졌다는 건 아닙니다. OpenAI도, Anthropic도, Google도 2026년 현재 프롬프트 가이드를 여전히 유지하고 있습니다. 프롬프트가 사라진 게 아니라 더 큰 시스템 안으로 흡수되고 있는 것에 가깝죠. 프롬프트만 잘 써서 해결되던 시대가 지나가고 있다는 쪽이 더 정확한 표현일 겁니다.
Step 1. Prompt Engineering: 말만 잘 하면 됐던 시절
전 세계가 프롬프트를 잘짜는 사람을 찾았던 적이 있습니다. 프롬프트 엔지니어라는 직업이 뜨고, 연봉이 3억이라는 기사가 돌고, “이 프롬프트 하나면 생산성 10배”라는 글이 매일 올라왔죠. 실제로 그때는 프롬프트가 거의 전부였습니다. 모델은 이미 충분히 똑똑했고, 성능 차이는 주로 어떻게 물어보느냐에서 나왔으니까요.
OpenAI의 InstructGPT가 사용자 의도를 따르는 모델을 제시했고, ChatGPT가 대화 형식으로 모델에 친근하게 접근하게 해주었으며, GPT-4가 나왔을 때는 좋은 프롬프트와 똑똑한 모델의 조합이 얼마나 잘할 수 있는지를 보여줬습니다. 여기에 Google이 발표한 Chain-of-Thought prompting은 한 번 더 점프를 만들었거든요. 프롬프트에 “단계별로 생각해봐”라고 한 줄 넣는 것만으로 reasoning 성능이 확 올라간다는 발견. 구글은 프롬프트 엔지니어링도 이렇게 잘하는구나 싶었죠.
프론티어 모델 provider들이 직접 프롬프트를 가르치던 시절
이 시기에는 모델을 만든 회사들이 직접 프롬프트를 잘 쓰는 법을 가르치는 데 엄청나게 투자했습니다.
OpenAI는 공식 Prompt Engineering Guide를 운영하면서 system message 작성법부터 few-shot 패턴까지 상세하게 다뤘습니다. 그때의 LLM Engineering은 temperature, system message를 만져가며 좋은 결과를 어떻게 얻을지 고민해야 했고, 이후에 GPTs(Custom GPTs)까지 나오면서 프롬프트만 잘 쓰면 나만의 앱을 만들 수 있도록 길을 열어줬습니다.
Anthropic도 마찬가지였습니다. Prompt Engineering Interactive Tutorial을 공개했고, 이후에는 Console에 Prompt Generator를 넣어서 목표만 입력하면 프롬프트를 자동으로 만들어주는 기능까지 제공했죠.
돌이켜 보면 이 시기의 메시지는 일관적이었습니다. 모델은 충분히 똑똑하다, 프롬프트만 잘 쓰면 된다. 실제로도 제법 오랫동안 그 말이 맞았습니다. 프롬프트를 다듬는 것만으로도 결과가 극적으로 달라지는 경험을 다들 했으니까요.
Step 2. Context Engineering: "뭘 말하느냐"에서 "뭘 보여주느냐"로
그런데 프롬프트를 아무리 잘 써도 벽에 부딪히는 순간이 오더라고요.
최근 데이블에서도 LLM을 비즈니스 로직에 적용하는 시도가 많아졌습니다. 근데 모델이 우리 회사 내부 문서를 모릅니다. 지금 코드베이스가 어떤 상태인지도 모릅니다. 회사 내부적으로 통용되는 단어나 히스토리를 아무리 기가 막힌 프롬프트로 풀어내도, 모델이 필요한 걸 모르면 소용이 없었거든요.
여기서 질문이 바뀝니다. 무슨 말을 할까가 아니라 모델이 지금 뭘 알아야 하는가로요.
Anthropic은 2025년 9월에 이걸 context engineering이라고 불렀습니다. Prompt engineering의 자연스러운 진화라고요.
Building with language models is becoming less about finding the right words and phrases for your prompts, and more about answering the broader question of “what configuration of context is most likely to generate our model’s desired behavior?”
더 이상 올바른 단어와 구문을 찾는 것이 아니라, "어떤 컨텍스트 구성이 모델의 원하는 행동을 가장 잘 이끌어내는가"라는 더 넓은 질문에 답하는 것
— Anthropic, "Effective context engineering for AI agents" (2025.09)
모델들은 이미 이 방향으로 움직이고 있었습니다
OpenAI는 2023년에 function calling을 도입했고, GPT-4에서 128K context, 이후 GPT-4.1에서 1M context까지 열었습니다. Anthropic은 Claude 2에서 100K, 이어서 200K, 그리고 2024년에는 Contextual Retrieval이라는 기법을 따로 발표했습니다. Google은 Gemini 1.5에서 1M, 이후 2M context까지 밀어붙이면서 context caching, code execution 같은 기능을 쌓았습니다.
컨텍스트 윈도우가 커지고 tool calling이 보편화되면서, 모델은 더 이상 질문하면 답하는 챗봇이 아니게 됐습니다. 더 많은 정보를 읽고 더 많은 도구를 호출하는 계산 주체로 바뀌기 시작한 거죠. 이 전환이 context engineering을 선택이 아니라 필수로 만들었습니다.
RAG는 시작일 뿐이었습니다
이 단계의 초기를 대표하는 기법은 RAG(Retrieval-Augmented Generation)입니다. 2020년에 Meta가 제안한 이후 LlamaIndex, LangChain, Chroma, Pinecone 같은 도구들이 retrieval 파이프라인을 쉽게 만들어줬습니다.
하지만 RAG는 context engineering의 전부가 아니라 대표적인 구현 중 하나에 가깝습니다. 문서 검색 말고도 DB 조회, 브라우저 제어, 사내 도구 연결, 메모리 관리까지 전부 모델이 지금 접근해야 하는 컨텍스트와 도구의 문제로 재구성되기 시작했거든요.
여기서 Anthropic이 MCP(Model Context Protocol)를 발표합니다. MCP는 외부 데이터 소스와 AI tool을 연결하는 공통 프로토콜인데, 이게 왜 중요하냐면 context 연결을 각각 독자적으로 구현하는 대신 누구나 쓸 수 있는 인터페이스로 만들기 때문입니다.
Context7이 좋은 예시죠. MCP 서버로 동작하면서 최신 공식 문서와 예제를 원문에서 끌어와 LLM의 컨텍스트에 바로 넣어줍니다. Claude에서도 쓸 수 있고, Gemini CLI에서도 쓸 수 있고, Codex에서도 쓸 수 있습니다. 탭을 왔다 갔다 하면서 문서를 복붙하던 시절과 비교하면 확실히 세상이 바뀌었다는 느낌이 들더라고요.
이렇게 Context engineering은 특정 벤더에 종속된 기능이 아니라 프롬프트 엔지니어링처럼 모델 활용을 위한 필수 인프라로 자리를 잡아가고 있습니다.
Step 3. Harness Engineering: 진짜 승부는 모델 바깥에서 갈린다
2026년 2월, Can Bölük이라는 엔지니어가 글 하나를 올렸습니다. "I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed." 하니스(harness)만 바꿨더니 15개 모델의 코딩 성능이 5~14점 올랐다는 겁니다. 모델은 그대로고 edit format 하나 바꿨을 뿐인데요.
같은 시기에 OpenAI가 "Harness engineering: leveraging Codex in an agent-first world"를 공개했고, Martin Fowler 블로그에서도 다뤄졌습니다. 갑자기 여기저기서 harness라는 단어가 보이기 시작한 거죠.
물론 Harness engineering이라는 용어가 완전히 표준화됐다고 보기는 아직 이릅니다. 하지만 이 단어가 가리키는 느낌이 직관적으로 와닿더군요.
모델은 엔진이고, 하니스는 차체입니다
하니스를 한마디로 정의하면 모델 바깥의 실행 계층 전체입니다. Agent loop, tool, runtime 인터페이스, context 압축, 메모리 관리, 권한 제어, observability, eval, deterministic check, human approval 같은 것들이 여기에 들어갑니다.
모델은 엔진이고, 하니스는 차체와 조향장치에 해당합니다. 같은 엔진도 차체에 따라 전혀 다른 차가 되니까요. Context가 모델에게 무엇을 보여줄지의 문제였다면, harness는 그 모델이 어떤 루프로 일하고 어떤 도구를 쓰고 어디서 확인하고 멈출지를 정하는 실행환경에 더 가깝습니다. 같은 모델도 여기에 따라 결과가 꽤 달라지죠.
Can Bölük의 실험이 정확히 이걸 보여줬습니다. 모델은 똑같은데 edit tool의 포맷만 바꿨더니 성능이 14점이나 올랐습니다. LangChain 팀도 하니스 최적화만으로 Terminal Bench 2.0에서 13.7점을 올려 Top 30에서 Top 5로 뛰었고요. 모델을 바꾸지 않고요.
OpenAI의 harness engineering 글에서 인상적이었던 문장이 있습니다.
"Humans steer. Agents execute."
엔지니어의 일이 좋은 프롬프트를 쓰기보다는 에이전트가 일할 환경을 설계하는 쪽으로 바뀌고 있다는 의미로 읽혔습니다. 저장소 구조, 문서 체계, 테스트 루프, 승인 정책, observability. OpenAI 팀은 실제로 3명의 엔지니어가 Codex를 통해 5개월 만에 약 100만 줄의 코드베이스를 만들었는데 인간이 직접 작성한 코드는 한 줄도 없었다고 합니다. 대신 그 팀이 집중한 건 하니스였다고 하고요.
프론티어 모델 회사들도 이미 여기에 투자하고 있습니다
OpenAI는 Responses API, Agents SDK, Codex harness/App Server를 내놨습니다. 이제 많이 사용하시는 AGENTS.md라는 개념도 흥미로운데, 백과사전처럼 길게 쓰지 않고 짧은 table of contents로 유지하면서 깊은 문서는 docs 폴더에 system of record로 두는 방식입니다.
Anthropic은 Claude Code, Agent SDK, computer use를 통해 하니스를 가장 적극적으로 제품화했습니다. 2025년 11월에는 long-running agent를 위한 effective harness 연구를 공개했는데 init 스크립트, progress log, self-verification 같은 장치들이 핵심이었습니다.
Google은 harness라는 단어를 전면에 쓰지는 않지만 실질적으로는 같은 방향입니다. ADK(Agent Development Kit)에서는 workflow agent와 hierarchy를, Vertex AI Agent Engine에서는 production deploy, manage, scale 같은 운영 계층을 제공하고 있으니까요.
Skills: 프롬프트 템플릿의 시대에서 Capability Package의 시대로
Anthropic이 2025년 10월 공개한 Agent Skills도 눈여겨볼 만합니다.
Anthropic은 Skills를 instructions, scripts, resources를 묶은 폴더 단위의 modular capability로 설명했습니다. 모델이 필요할 때 내용을 로드해서 사용하는 방식입니다.
예전에는 프롬프트 템플릿을 공유했다면 지금은 절차, 스크립트, 리소스를 묶은 capability package를 공유하는 방향으로 재사용 단위가 이동하는 중입니다. 그래서 Skills는 prompt engineering의 확장이라기보다 harness engineering의 핵심 개념에 더 가깝습니다.
Mac Mini 대란 OpenClaw
OpenClaw도 재미있는 사례입니다. 로컬에서 돌아가는 personal AI assistant/runtime인데, Gateway를 control plane처럼 두고 전체 실행환경을 제어하는 구조입니다. OpenClaw를 세팅하다 보면 어떤 실행환경과 권한과 기능 생태계를 에이전트에게 열어줄 것인가에 초점이 있음을 알 수 있죠. harness layer의 프로젝트라고 해도 크게 이상하지 않습니다.
Step 4. Next Step: 모델보다 사람이 병목이 되는 시대
여기서부터는 아직 이름도, 방법론도 완전히 굳지 않은 영역입니다. 다만 에이전트가 더 오래 돌고 더 많은 일을 병렬로 처리할수록 이 문제가 점점 중요해질 것 같아, 마지막에 덧붙여보려 합니다.
앞으로의 병목은 모델이 아니라 사람일지도 모르겠습니다. 아니, 이미 그렇게 보입니다. 에이전트 하나를 잘 굴리는 건 이제 제법 할 수 있게 됐죠. 문제는 여러 개를 동시에 돌릴 때입니다.
각각의 에이전트를 통해 진행 상황을 파악하고, 권한을 승인하고, 대안을 비교하고, 실패 원인을 추적하는 비용이 커집니다. 컨텍스트 스위칭이 개발자의 생산성을 갉아먹듯이 에이전트 스위칭도 인지부하를 갉아먹습니다. 에이전트가 3개면 그럭저럭 따라갈 수 있는데 10개가 되면? 각각 뭘 하고 있는지 파악하는 것만으로도 하루가 가더라고요.
감독의 문제 : Supervisory Engineering
Prompt engineering이 말의 기술이었다면, Context engineering은 정보를 붙이는 기술이었고, Harness engineering은 실행환경을 설계하는 기술이었습니다. 이제 그 위에서 핵심은 사람이 병렬로 돌아가는 에이전트들을 얼마나 적은 인지부하로 검토하고 승인하고 개입하느냐입니다.
얼마 전 Anthropic은 Claude Code 실사용 분석에서 숙련 사용자가 액션을 하나씩 승인하기보다 auto-approve를 더 자주 쓰고, 대신 필요할 때 더 자주 interrupt하는 패턴으로 이동한다고 했습니다. 점점 모델에게 많은 부분을 위임하고 필요한 경우에만 개입하는 방식을 주로 쓴다는 얘기죠.
에이전트의 상태와 진행 상황을 사람이 한눈에 파악하도록 시각화하는 오픈소스들도 등장하고 있습니다. 세부적인 행동을 모두 따라가기보다, 사람이 인지 가능한 수준으로 상태를 요약하고 필요할 때만 끼어들 수 있게 한 단계 감싼 인터페이스에 가깝습니다.
(그리고 이 글을 쓰게 된 계기인) 저번 주 OpenAI가 발표한 Symphony도 같은 맥락으로 읽힙니다. 개별 에이전트의 모든 행동을 사람이 따라가는 대신, work 단위의 상태와 proof of work를 중심으로 관리하게 하려는 시도니까요.
결국 더 많은 에이전트, 더 빠른 에이전트만이 관건이 아니라 그 에이전트들을 인간이 감당 가능한 방식으로 검토하고 개입하게 만드는 기술이 중요해지고 있습니다.
정리하며
프롬프트가 사라진 건 아닙니다. 여전히 모든 계층의 출발점이죠. 다만 이제는 프롬프트만 잘 쓴다고 해결되는 문제보다 그 바깥의 설계와 운영에서 갈리는 문제가 훨씬 많아졌습니다.
LLM 모델 자체는 앞으로도 계속 더 강력해질 겁니다. 그렇다면 이를 사용하는 회사의 경쟁력은 모델 자체의 성능보다, 그 모델이 우리 조직의 맥락 안에서 얼마나 자연스럽고 안정적으로 일하느냐에 더 크게 좌우되겠죠.
그러다 보면 필요한 컨텍스트를 공급하도록 우리 조직의 지식을 정리하게 되고, 반복되는 작업은 재사용 가능한 skills와 workflow로 묶게 됩니다. 실패를 감지하고 복구하는 harness의 중요성도 자연스럽게 커집니다. 그다음에는 사람이 큰 인지부하 없이 검토하고 필요할 때만 개입하는 운영 구조까지 고민하게 되더라고요.
앞으로의 LLM Engineering은 모델 자체를 다루는 기술이라기보다, 이미 충분히 강력해진 모델이 우리 회사 안에서 제대로 일하게 만드는 기술에 더 가까워질 겁니다. 아마 앞으로의 생산성 격차도 더 좋은 모델을 먼저 쓰는 데서보다, 이런 구조를 얼마나 잘 갖추고 있느냐에서 벌어지지 않을까 싶습니다.
참고자료
•
Context7 — MCP 기반 최신 문서 컨텍스트 주입 도구
•
OpenClaw — 로컬 AI assistant runtime
작성자
관련된 글 더 보기