Harness Engineering 101: 프롬프트 엔지니어링만으로는 부족했다. 컨텍스트도 마찬가지였다. '하네스'가 필요했다.

요약 (TL;DR)

• 프롬프트 엔지니어링과 컨텍스트 엔지니어링 모두 여전히 나를 병목 지점으로 남겼다. 매 세션마다 스스로를 재설명해야 했다.
• 해결책은 언어적인 것이 아니라 구조적이었다. 즉, 하네스(harness)였다: 지속되는 컨텍스트, 메모리 파일, 실제 계정 접근 권한, 위임 및 스킬을 갖추어 모델이 매일 아침 이미 나의 업무를 알고 시작하게 하는 것이다.
• 이 용어는 2026년에 명명되었다 (Agent = Model + Harness). 현재 두 진영이 이 문제에 대해 논쟁하고 있지만, 그들이 동의하는 점은 놓치고 있다: 핵심(edge)이 모델에서 그 주변 구조로 이동했다는 것이다.
• 하네스는 공짜가 아니다. 낡는다. 이를 유지하는 것이 실제 업무다. 그리고 아직 아무도 구축하지 않은 버전은 단순히 책상 주변에 있는 하네스가 아니라, 당신이 출시할 제품 안에 내장된 하네스이다.

하네스란 모델이 당신의 세상에서 실질적인 작업을 수행할 수 있도록 주변에 구축하는 모든 것을 의미한다: 당신의 파일, 당신의 계정, 당신의 표준, 당신의 이력. 모델은 교체 가능한 부분이다. 하네스는 모델을 유용하게 만드는 부분이며, 아무도 스크린샷 찍지 않는 부분이기도 하다.

프롬프트 엔지니어링, 그리고 컨텍스트 엔지니어링, 그리고 벽

약 1년 반 전만 해도, 이 모델들과의 나의 관계는 프롬프트 엔지니어링 그 자체였다. 작동하는 구문들을 수집했다.

그래서 나는 당연한 다음 단계인 컨텍스트 엔지니어링 (context engineering)으로 넘어갔다. 단어를 튜닝하는 것을 멈추고, 올바른 컨텍스트 윈도우 (context window)를 조립하기 시작했다. 관련 파일을 붙여넣고, 컨벤션 (conventions)을 붙여넣었다. (얼마 전 컨텍스트 엔지니어링에 관한 글을 쓴 적이 있다. [→ 링크 추가])

어제의 결정 사항도 붙여넣었다. 답변은 극적으로 좋아졌다. 그러다 나는 벽에 부딪혔고, 그 벽은 바로 나 자신이었다.

내가 곧 컨텍스트였다. 매일 아침 나는 내가 누구인지, 무엇을 만들고 있는지, 무엇이 확정되었는지, 어제 무엇을 출시했는지와 같은 동일한 윈도우를 수동으로 조립하며 앉아 있었다. 나는 내 삶을 텍스트 박스에 복사해 넣는 인간 접착제 계층 (human glue layer)이었고, 세션이 종료되는 순간 그 모든 것이 증발해 버렸다. 컨텍스트 엔지니어링은 세션당 모델을 더 똑똑하게 만들었지만, 모든 세션이 차가운 상태 (cold start)로 시작된다는 사실에 대해서는 아무런 해결책도 주지 못했다.

그 콜드 스타트 (cold start)가 실제 문제였다. 문구의 문제가 아니다. 컨텍스트 자체의 문제도 아니다. 그 어떤 것도 지속되지 않아서, 매일 내가 직접 다시 구축해야 한다는 사실이 문제였다.

대신 내가 만든 것: 따뜻하게 시작하는 제2의 뇌

나를 끌어들인 첫 번째 AI 유스케이스 (use case) 중 하나는 제2의 뇌 (second brain) 접근 방식이었다. 나는 일찍 시작했고, 한 가지만 말하겠다. 이것은 정말 놀랍다. 나는 누구에게나 제2의 뇌를 추천할 것이다. 개인적으로 그 어떤 AI 유스케이스도 이것보다 나은 것은 없다. 시작을 돕기 위한 가이드를 준비해 두었다: 제2의 뇌 시작 가이드.

나는 콜드 스타트 문제를 의도적으로 해결하려 했던 것이 아니다. 한 번에 하나의 번거로움을 해결해 나갔을 뿐이며, 나중에야 그 수정 사항들이 모여 하나의 형태를 갖추고 있다는 것을 알게 되었다.

그것은 단 하나의 파일로 시작되었다. 모델에게 내가 누구인지 알려주는 루트 CLAUDE.md 파일이다: React Native 경력 9년, 나의 글쓰기 스타일, 내가 출시하려는 것, 그리고 논쟁의 여지 없이 확정된 결정 사항들. 그다음에는 프로젝트당 하나의 CLAUDE.md를 두었다. 그래서 Wire RN 리포지토리 (repo) 안에서는 해당 코드베이스의 규칙을 알고, 나의 보관함 (vault) 안에서는 콘텐츠 규칙을 알게 했다. 모델은 더 이상 차갑게 시작하지 않았다. 모델은 마치 몇 달 동안 나와 함께 일해온 사람처럼 시작되었다.

다음은 메모리 (Memory)입니다. 이제 거의 100개의 마크다운 (Markdown) 파일이 있으며 (내가 확인한 그날 아침에는 97개였습니다), 각 파일에는 하나의 사실이 담겨 있고, 모델은 매 세션의 시작 부분에서 인덱스 (Index) 파일을 읽습니다. 예를 들면 다음과 같습니다:

• "Morrow Self는 잠긴 앱 이름이다."
• "액센트 색상은 보라색이 아니라 청록색이며, 6월 11일에 변경되었다."
• "나의 ICP (Ideal Customer Profile, 이상적 고객 프로필)는 B2C 모바일 앱 창업자이다."

이제 인덱스의 크기가 너무 커져서 자체적인 크기 제한에 걸릴 정도인데, 이는 이것이 어떻게 축적되는지에 대해 솔직한 사실을 말해줍니다. 나는 더 이상 매일 아침 내 사업에 대해 다시 설명하지 않습니다. 모델이 기억하고 있으며, 모델이 틀렸을 때 나는 백 번째 반복해서 말하는 대신 파일 하나를 수정합니다.

다음은 액세스 (Access)입니다. Gmail, Calendar, Drive로 연결되는 MCP (Model Context Protocol) 커넥터입니다. 모델은 그것들을 설명하는 문장이 아니라, 나의 실제 일정과 실제 편지함을 읽습니다. 컨텍스트 엔지니어링 (Context engineering)이 내가 내 일정을 이야기하는 것이었다면, 이것은 모델이 그냥 일정을 가지고 있는 것입니다.

다음은 위임 (Delegation)이며, 여기에 나의 단 하나의 진짜 규칙이 들어 있습니다. 10개의 파일을 grep으로 검색하거나 코드베이스 (Codebase)를 매핑해야 할 때, 그것은 별도의 컨텍스트에서 실행되어 결론을 전달합니다. 이것은 내가 모든 빌드 (Build)에서 실행하는 것과 동일한 원리입니다. 가장 최신의, 가장 유능한 모델이 계획을 세우고, 더 저렴하고 단순한 모델이 실행합니다. 비싼 두뇌가 무엇을 할지 결정하고, 저렴한 두뇌는 자신의 창에서 단순 작업 (Grunt work)을 수행하며 나의 창을 절대 오염시키지 않습니다.

이 중 그 어떤 것도 영리한 것이 아니었습니다. 모든 조각은 내가 반복해서 말하는 것에 지쳤기 때문에 존재합니다. 그것이 전부이며, 관련 게시물들이 들려주는 것보다 훨씬 더 지루한 일입니다.

이제 이것에도 이름이 생겼습니다: 하네스 엔지니어링 (harness engineering)

정말 놀라운 일이었습니다. 저는 12월부터 이 작업을 해오고 있었습니다. 단지 적절한 단어를 몰랐을 뿐입니다.

그 단어가 여기 있습니다. Mitchell Hashimoto는 2026년 초에 "하네스 엔지니어링 (harness engineering)"이라는 용어를 만들었습니다: 에이전트 (Agent) = 모델 (Model) + 하네스 (Harness). 모델은 두뇌입니다. 하네스는 그 두뇌가 당신의 세상에서 활동할 수 있게 해주는 주변의 모든 것입니다. 사람들은 하네스를 대략 다섯 가지 부분으로 나눕니다:

• 개인화 (personalisation)
• 컨텍스트 (context)
• 액션 (action)
• 메모리 (memory)
• 위임 (delegation), 여기에 배율을 높여주는 기술 (skills)과 예약된 작업 (scheduled jobs)이 추가됨.

저는 제 자신의 설정을 이 목록과 대조하며 빈틈이 있기를 기대했지만, 제가 조용히 이 다섯 가지를 모두 구축했다는 것을 발견했습니다.

모두가 반복하는 수치는 Claude Code의 분석(teardown)에서 나온 것인데, 시스템의 약 98%가 하네스이고 모델은 2% 미만이라는 주장입니다. 솔직히 말씀드리면, 저는 그 수치가 실제로 무엇을 집계한 것인지 확인하지 않았고, 이를 재게시하는 대부분의 사람들도 확인하지 않았으므로 정확한 수치는 가볍게 받아들이시기 바랍니다. 방향성 측면에서는 제가 매일 보는 것과 일치합니다. 모델은 작고 교체 가능한 부분입니다. 스캐폴딩 (scaffolding, 비계)이 바로 작업이 실제로 이루어지는 곳입니다. (진짜 버전을 알고 싶다면, Martin Fowler의 노트와 HumanLayer의 실무자 기술 문서가 제가 읽은 것 중 가장 과장되지 않은 두 가지 설명서입니다.)

이것이 왜 폭발적으로 성장했는지, 그리고 본질을 놓치고 있는 논쟁

하시모토(Hashimoto)가 '하네스'라는 이름을 붙이는 동안, 또 다른 빌더인 Jake Van Clief는 정반대의 방향으로 나아가 약 6주 만에 수만 명 규모의 커뮤니티를 성장시키며, 에이전트 기반 프레임워크(agentic frameworks) 사용을 완전히 중단하라고 모두에게 말했습니다. 그의 주장은 이렇습니다: LangChain을 삭제하고, 오케스트레이션 라이브러리(orchestration libraries)를 삭제하며, 그 모든 것을 번호가 매겨진 폴더와 마크다운 파일로 대체해야 합니다. 그는 폴더 하나와 모델 하나가 커스텀 에이전트보다 낫다고 주장합니다.

Jake에게 큰 박수를 보냅니다. 저는 이 사람을 좋아하고, 팔로우하며, 그의 조언과 콘텐츠는 진정으로 좋습니다. 여러분도 꼭 그를 팔로우할 것을 강력히 추천합니다: youtube.com/@JEVanClief.

한쪽 캠프는 더 많은 스캐폴딩(scaffolding)을 구축하라고 하고, 다른 쪽은 프레임워크 자체를 뜯어내고 파일 시스템(filesystem)을 사용하라고 합니다. 이들은 서로 적처럼 들립니다. 하지만 같은 말을 하고 있습니다.

두 주장 모두 모델 자체가 핵심이 아니라고 말하고 있습니다. 모델 주변의 아키텍처가 핵심이라는 것입니다. 여러분의 아키텍처가 LangChain 그래프이든, 02-draft라는 이름의 폴더이든, 베팅은 동일합니다: 경계(edge)가 모델에서 벗어나 그 주위에 감싸는 구조로 이동했다는 것입니다.

이것이 제가 두 사람의 용어를 접하기 6개월 전부터 말해왔던 내용입니다. 저는 [

메모리 파일은 부패합니다. 제가 관리하는 파일들도 가지치기 (pruning)를 하지 않으면 서로 모순됩니다. 제 파일 중 상당수는 작성된 지 한 달도 채 되지 않아 출시 날짜가 어긋나 있었습니다. 오래된 메모리는 메모리가 없는 것보다 더 나쁩니다. 모델이 그것을 신뢰하고, 당신 또한 신뢰하기 때문입니다. 저보다 더 큰 메모리 시스템을 운영하는 사람들은 분기별로 정기적인 청소를 하는데, 이제 저는 그 이유를 정확히 이해합니다.

기술 (Skills) 또한 같은 방식으로 부패합니다. 저는 60개의 기술을 설치해 두었습니다. 평범한 한 주 동안 아마 12개 정도만 발휘될 것입니다. 나머지 48개는 계속 감사 (audit)해야겠다고 생각만 하는 잡동사니들입니다. 돌보지 않은 하네스 (harness)는 중립을 유지하지 않습니다. 그것은 당신의 삶에 대한 자신만만한 거짓말들로 조용히 채워집니다.

따라서 누군가 하네스가 새로운 해자 (moat)라고 말한다면, 솔직한 버전은 하네스가 새로운 헬스장 멤버십이라는 것입니다. 소유하는 것만으로는 아무것도 할 수 없습니다. 그것을 유지하기 위해 꾸준히 나타나는 것 자체가 모든 수익 (return)입니다.

강의 없이 시작하는 방법

만약 당신이 제로 상태에서 시작한다면, 프레임워크 (framework)나 강의, 혹은 3만 명 규모의 커뮤니티가 필요하지 않습니다. 당신에게는 세 가지가 필요합니다:

• 모델에게 당신이 누구인지, 무엇이 고정되어 있는지 알려주는 하나의 CLAUDE.md (또는 그에 상응하는 파일).
• 모델이 세션 시작 시 읽을 수 있는, 각각 하나의 사실을 담은 몇 개의 메모리 파일.
• 같은 내용을 두 번 설명하고 있다는 것을 깨달을 때마다 새로운 파일을 추가하는 절제력.

그것이 바로 하네스입니다. 그 이상의 모든 것은 기초가 아니라 정교화 (refinement)의 영역입니다.

이미 하네스를 가지고 있다면, 더 만들지 마세요. 감사 (audit)하세요. 자신의 메모리 파일을 열어보고 얼마나 많은 내용이 여전히 사실인지 세어보세요. 이번 주에 실제로 발휘된 기술이 몇 개인지 세어보세요. 그 숫자는 겸허하게 만들 것이며, 가지치기 (prune)를 하는 것이 그 어떤 새로운 추가 사항보다 전체 시스템을 더 잘 작동하게 만들 것입니다.

다음 단계: 개발자 주변이 아닌, 앱 내부의 하네스

여기에 제가 계속 응시하고 있는 간극 (gap)이 있습니다. 이 주제에 대해 글을 쓰는 모든 사람은 자신의 책상을 향하고 있습니다. 코딩 에이전트 (Coding agents), 연구 보조원 (Research assistants), 저와 같은 제2의 뇌 (Second brains), 개발 도구 (Dev tools) 및 지식 노동 (knowledge work) 말입니다.

하지만 소비자용 모바일 앱을 출시하기 위한 하네스를 구축하는 사람은 아무도 없습니다.

그곳이 바로 아무도 주목하지 않았던 영역이며, 제가 서 있는 곳입니다. 모델이 신뢰할 수 있는 구조로 감싸져 있다는 동일한 개념은, 모바일 앱이 모든 사용자에게 똑같은 6개의 하드코딩된 질문을 던지는 대신 사용자마다 서로 다른 온보딩 흐름 (onboarding flow)을 렌더링할 수 있게 해주는 것과 같습니다.

제품을 위한 하네스 (harness)는 CLAUDE.md가 아닙니다. 그것은 검증된 컴포넌트 레지스트리 (component registry), 실제 휴대폰에서 작동하는 스트리밍 런타임 (streaming runtime), 그리고 채팅 대신 화면을 구동하는 에이전트 (agent)입니다. 이것이 제가 지난 6개월 동안 Wire RN에 구축해 온 것이며, 이는 다른 인터페이스를 향하고 있을 뿐 '제2의 뇌 (second brain)'와 동일한 교훈을 담고 있습니다.