🎬 Harness Engineering: The Skill That Will Define 2026 for Solo Devs

▶️ 유튜브

• 원본 링크: https://youtu.be/DN2mhf0b02s?si=siQkSi4qqiqA37x-

🖼️ 4컷 인포그래픽

💡 한 줄 결론

솔로 개발자가 AI 코딩 성과를 끌어올리려면 모델 교체에 집착하기보다, 도구를 줄이고 외부 메모리·작업 추적·표준 확장 지점을 갖춘 단순한 하네스를 설계하는 데 시간을 써야 한다. 실제 성공률·속도·비용은 모델 미세 성능보다 이 실행 구조에서 더 크게 갈린다.

📌 핵심 요점

1. 실제 업무형 Agent Bench에서는 최고급 모델도 단일 실행 성공률이 약 24%, 8회 반복 시도 후에도 약 40% 수준에 머물러, 퍼즐형 벤치마크 고득점이 실무 성과를 보장하지 못했다.
2. 장기 작업 실패의 핵심 원인은 지식 부족보다 실행 붕괴, 맥락 상실, 실패 접근 재반복 같은 조율 문제였고, 이는 모델 교체보다 작업 운영 구조 개선으로 다뤄야 할 영역이었다.
3. Vercel의 텍스트-투-SQL 에이전트는 전용 도구를 대거 붙였을 때보다 bash·파일 읽기·grep·cat 중심의 단순한 도구 집합으로 줄였을 때 정확도는 80%에서 100%로 오르고, 토큰은 40% 줄고, 속도는 3.5배 빨라졌다.
4. 긴 작업에서는 큰 컨텍스트 창만으로는 충분하지 않았고, 핵심 상태를 파일에 기록해 필요 시 다시 읽는 외부 메모리 구조가 맥락 유지와 재시작 복원력에 더 효과적이었다.
5. Codex, Claude Code, Manis는 구조는 달라도 최소 도구 집합, 파일 기반 메모리, 단순한 핸드오프, 표준화된 확장 지점(MCP·스킬)으로 수렴했으며, 솔로 개발자의 차별화 포인트도 이 하네스 자산에 생긴다.

🧠 상세 요약

1) 배경과 문제 정의

영상의 출발점은 “어떤 모델이 최고인가”라는 질문이 실제 생산성 병목을 잘못 짚고 있다는 문제의식이다. 발표자는 실전 업무형 벤치마크와 현업 사례를 통해, 판단해야 할 포인트가 모델 지능 자체보다 장기 실행을 버티게 만드는 하네스 설계인지 묻는다.

2) 섹션별 상세 정리

1. 솔로 개발의 목표를 빠른 실험이 아니라 지속 가능한 제작 체계로 둔다 [00:00]

• 발표자는 자신이 오랜 iOS 개발 경험과 프리랜서 실무를 거쳐, 이제는 안전망 없이 솔로 개발에 전념하고 있다고 밝힌다.
• 핵심 관심사는 AI로 급하게 MVP를 찍는 것이 아니라, 혼자서도 오래 운영 가능한 “진짜 앱” 제작 스튜디오를 만드는 것이다.

2. 기존 모델 순위표가 실무 성과를 설명하지 못한다 [01:35]

• Epic의 Agent Bench는 퍼즐 풀이가 아니라 컨설턴트·변호사·분석가의 실제 업무처럼 1~2시간짜리 작업을 에이전트에게 수행시킨다.
• 여기서 최고 프런티어 모델도 성공률이 약 24%에 그쳤고, 여러 번 다시 돌려도 40% 안팎이라 벤치마크 점수와 실전 성과 사이 괴리가 드러난다.

3. 병목은 추론 능력보다 장기 실행 중 조율 실패에 있다 [02:18]

• 모델은 필요한 지식과 기본 추론 능력은 이미 갖고 있었지만, 긴 작업으로 갈수록 길을 잃고 실패한 접근을 되풀이하며 원래 목표를 놓쳤다.
• 발표자는 이를 “모델이 멍청해서”가 아니라 실행 환경이 장기 작업을 받쳐주지 못한 결과로 본다.

4. 2026년의 핵심 단어는 모델이 아니라 하네스다 [03:00]

• 하네스는 모델이 볼 수 있는 정보, 접근 가능한 도구, 오류 복구 방식, 장기 세션의 작업 추적 구조까지 포함한 실행 인프라 전체다.
• OpenAI, Anthropic, Manis가 서로 다른 맥락에서 모두 하네스 엔지니어링을 강조했다는 점을 들어, 경쟁 축이 모델 내부보다 외부 운영 구조로 이동한다고 본다.

5. 도구를 많이 붙일수록 성능이 좋아진다는 직관이 깨진다 [04:30]

• Vercel은 텍스트-투-SQL 에이전트에 스키마 이해, 쿼리 작성, 검증, 오류 처리용 전용 도구를 풍부하게 붙였지만 정확도는 약 80%에 머물렀다.
• 이후 도구의 80%를 제거하고 일반 명령줄 도구 중심으로 단순화하자 정확도 100%, 토큰 40% 절감, 속도 3.5배 향상이라는 더 좋은 결과가 나왔다.

6. 복잡성 제거가 기능 추가보다 더 큰 개선을 만든다 [05:50]

• Manis도 프레임워크를 여러 번 재구축하는 과정에서 복잡한 문서 검색, 라우팅 로직, 관리자 에이전트 구조를 줄일수록 성능이 좋아졌다고 본다.
• 발표자는 개발자가 안전장치와 특수 기능을 계속 덧대는 습관이 오히려 모델 판단을 흐리고 실행 경로를 꼬이게 만들 수 있다고 해석한다.

7. 긴 작업의 핵심은 큰 컨텍스트 창이 아니라 외부 메모리 설계다 [06:34]

• 장시간 코딩 작업에서는 수십 번의 도구 호출과 중간 산출물이 누적되며, 중요한 초기 지시사항이 노이즈에 묻힌다.
• 이를 막기 위해 Manis는 파일 시스템을 외부 메모리처럼 사용했고, 에이전트가 핵심 상태를 파일에 기록·재독하는 구조를 채택했다.

8. 성공한 시스템들은 서로 다른 방식으로 같은 설계 원칙에 수렴한다 [07:39]

• Codex는 오케스트레이터·실행자·복구 계층을 둔 계층형 구조를 쓰고, Claude Code는 파일 읽기·쓰기·편집·bash라는 최소 도구 중심 철학을 취한다.
• 구조는 달라도 공통점은 복잡한 내장 기능보다 단순한 하네스, 명확한 역할 분리, 외부 메모리, 필요 시 확장 가능한 표준 지점에 무게를 둔다는 점이다.

9. 확장성은 하드코딩이 아니라 MCP와 스킬 같은 표준 연결점에서 나온다 [08:20]

• 발표자는 모든 통합을 전용 로직으로 직접 짜 넣기보다, MCP와 스킬을 통해 필요할 때 외부 도구를 연결하는 방식을 배워야 한다고 말한다.
• 이는 모델이 좋아질수록 수작업 파이프라인을 더 두껍게 만드는 전략이 오히려 역행이 될 수 있다는 ‘씁쓸한 교훈’과도 이어진다.

10. 솔로 개발자가 당장 개선할 수 있는 것은 모델이 아니라 운영 체계다 [08:50]

• 발표자는 Reddit식 모델 우열 논쟁에 시간을 쓰기보다, 특수 도구를 줄인 A/B 실험, progress file, 실행형 TODO, 파일 기반 상태 기록을 먼저 넣어보라고 권한다.
• 같은 모델도 Claude Code, Cursor, Codex, 자체 하네스 안에서 전혀 다르게 행동하기 때문에, 실전 차별화는 모델 선택보다 하네스 축적 자산에서 만들어진다는 결론으로 마무리한다.

11. CraftersLab은 하네스 자산을 공개하는 실전형 운영 공간으로 제시된다 [11:35]

• 후반부에서 발표자는 자신의 MD 파일, 프롬프트, 자동화, Swift/SwiftUI 자산, 노션 팀 공간, 라이브 플레이북을 공유하는 커뮤니티를 소개한다.
• 이 소개는 단순 홍보보다, 하네스가 추상 이론이 아니라 실제 문서·워크플로·자동화 자산의 집합이라는 점을 보여주는 사례로 읽힌다.

✅ 액션 아이템

• 현재 쓰는 코딩 에이전트에서 전용 도구 목록을 전부 뽑고, 그중 50~80%를 제거한 축소 버전으로 동일한 실제 작업 3개를 다시 돌려 정확도·완료시간·토큰 사용량을 비교한다.
• 프로젝트 루트에 progress.md와 todo.md를 두고, 에이전트가 작업 시작 전 반드시 읽고 단계 종료마다 다음 행동·막힌 지점·검증 결과를 기록하도록 시스템 프롬프트를 수정한다.
• 장기 작업 1개를 골라 중간 산출물을 컨텍스트에 계속 누적하는 방식 대신 파일 시스템에 외부화하고, 세션 재시작 후 파일만 읽어 이어 붙였을 때 누락된 요구사항 수와 재작업 횟수를 측정한다.
• 동일한 모델을 Claude Code, Cursor, Codex 또는 내부 하네스에 각각 넣어 같은 태스크를 수행시킨 뒤, 실패 원인을 모델 문제가 아니라 도구 수·메모리 구조·복구 흐름 차이로 분류한다.
• 외부 연동이 많은 작업 3개를 골라 하드코딩 스크립트 대신 MCP·스킬 같은 표준 연결점으로 치환 가능한지 설계안을 작성하고, 유지보수 비용과 재사용 범위를 비교한다.

❓ 열린 질문

• Vercel의 “도구 제거 후 성능 향상”이 SQL처럼 비교적 구조화된 작업에만 강한 현상인지, 실제 앱 개발·리팩터링·디버깅 같은 비정형 작업에서도 재현되는지 어떤 작업셋으로 검증해야 할까?
• 파일 기반 외부 메모리가 장기적으로 누적 오염을 일으킬 때, 어떤 시점에 요약·압축·폐기 규칙을 넣어야 맥락 유지 이점이 오히려 성능 저하로 바뀌지 않을까?
• 같은 모델이 하네스에 따라 전혀 다른 생산성을 보인다면, 앞으로 코딩 에이전트 시장의 방어력은 모델 접근권보다 운영 데이터·프롬프트 자산·워크플로 설계에 형성된다고 봐야 할까?
• 보안·권한 통제·감사 로그가 필요한 팀 환경에서는 “거의 아키텍처가 없는 하네스”를 어디까지 허용할 수 있으며, 단순화 이익이 통제 비용을 넘는 임계점은 어떻게 측정할 수 있을까?