AI 이후의 소프트웨어: 하네스(Harness) 시대의 개막 — GeekNews 토론 분석

원문 정보

• 제목: "Software After AI" (AI 이후의 소프트웨어)
• 저자: Tomasz Tunguz — Theory Ventures 벤처캐피탈, 15만+ 창업가 구독, Bloomberg/WSJ/Economist 인용
• 게시일: 2026년 5월 27일
• 출처: tomtunguz.com → GeekNews 30061번 → PyTorchKR 공유
• GeekNews 댓글: 8개 (하네스 유지 vs 제거 논쟁)

하네스 시대의 의미

Tomasz Tunguz는 소프트웨어 시대의 종말이 곧 하네스(harness) 시대의 시작이라고 주장합니다. 핵심 메타포는 머스탱(야생마)입니다. AI는 강력하지만 길들여지지 않은 상태이며, 그 힘을 실제로 활용하려면 체계적인 가축화(domestication)가 필요합니다.

과거 소프트웨어는 "인간의 작업을 코드로 정의하는 것"이었습니다. AI 시대에는 "AI를 제어하는 시스템을 정의하는 것"이 핵심이 됩니다. 이것이 바로 하네스의 본질입니다.

SaaS(소프트웨어-as-a-Service)는 고정된 워크플로우와 관리형 데이터베이스로 작동했습니다. AI는 그런 접근을 outdated하게 만들었습니다 — 지능 자체를 가진 도구가 등장했기 때문입니다. 하지만 지능만으로는 부족합니다. 하네스가 그 차이를 만듭니다.

AI 에이전트 하네스의 7가지 구성요소

1. 맥락과 메모리 (Context & Memory)

일반 목적 LLM은 모든 분야에 대해 평균적인 지식을 가지고 있지만, 전문 분야에서는 맞춤형 검색이 필요합니다. 방사선과 의사가 폐 CT 영상을 분석할 때 필요한 컨텍스트 시스템과 법률 보조원이 계약서를 검토할 때 필요한 시스템은 완전히 다릅니다.

때로는 단기 메모리가 중요합니다. 에이전트가 45초 전에 무엇을 작업하고 있었는가. 때로는 대규모 이미지 검색이 필요합니다 — 방사선학이나 영상 생성 분야. 때로는 10억 개 문서에 걸친 키워드 검색이 필요합니다. 이러한 시스템은 각 사용 사례에 맞춰 개별적으로 설계되어야 합니다.

검색 시스템과 함께 작동하는 것이 컨텍스트 데이터베이스입니다. 각 기업이 실제로 어떻게 운영되는지에 대한 레시피 책과 같습니다. 우리가 머리에 담아두고 매일 직장에 가져오는 표준 운영 절차가 바로 그 레시피입니다. 처음에 그것을 포착하고 사람과 프로세스가 바뀔 때 함께 진화시키는 것이 컨텍스트 데이터베이스의 핵심입니다.

2. 도구와 행동 (Tools & Action)

도구는 에이전트가 외부 세계에 실제로 영향을 미치는 수단입니다. 컨텍스트 데이터베이스의 레시피가 "무엇을 할지"를 정의한다면, 도구는 "실제로 그것을 수행하는 재료와 도구"입니다.

현대적인 하네스는 도구를 레지스트리(registry)를 통해 노출하고, 모델이 전달하는 인수를 검증하며, 호출을 분배하고, 민감한 행동을 승인 뒤에 두고, 결과를 에이전트의 루프로 다시 파싱합니다. MCP(Model Context Protocol)가 연결 고리로 부상했습니다. 하네스의 품질은 얼마나 많은 도구를 안전하게 노출할 수 있는지, 그리고 실패를 얼마나 깔끔하게 처리하는지에 달려 있습니다.

3. 오케스트레이션과 루프 (Orchestration & Loop)

에이전트 루프의 기본 구조는 생각 → 행동 → 관찰 → 반복입니다. 계획, 분해, 서브 에이전트, 재시도, 종료 조건이 작업을 어떻게 완료할지 정의합니다.

또한 소프트웨어가 사용하면서 개선되기를 기대합니다. 각 실행에서 학습하는 폐쇄 루프 패턴(closed loop patterns)이 벤더들 간의 차별화 요소가 될 것입니다.

4. 상태와 영속성 (State & Persistence)

대규모 기업 시스템에서 시스템은 견고해야 합니다. 하네스가 10단계 작업 중 7단계에서 충돌하면, 8단계에서 재개해야지 0부터 재시작하면 안 됩니다. 파일 시스템, 체크포인트, 세션 스레드, 아티팩트 저장소가 작업 손실을 방지하는 메커니즘입니다.

실제 예: 에이전트가 5시간 동안 실행 중인 데이터 분석 작업 중 서버가 다운되었습니다. 체크포인트가 있다면 마지막 완료 단계(7/10)에서 재개해서 3시간만 더 소요됩니다. 체크포인트가 없다면 0부터 다시 시작해서 5시간을 다시 써야 합니다.

5. 샌드박스와 컴퓨팅 (Sandbox & Compute)

각 에이전트는 격리된 작업 공간이 필요합니다. 격리된 Unix 워크스페이스, 통제된 네트워크휜궬, 모델 외부에 있는 자격 증명이 샌드박스를 안전하고 기밀하며 확장 가능하게 만듭니다.

에이전트가 rm -rf / 명령어를 실행하려고 해도 샌드박스 내부에서만 실행되므로 실제 시스템에는 영향이 없습니다.

6. 관측성과 거버넌스 (Observability & Governance)

"볼 수 없는 것은 신뢰할 수 없음". 모든 단계 추적, 모든 도구 호출 로깅, 회귀 테스트로서의 evals(평가), 최고위험 결정에 인간 투입 — 이것이 데모를 프로덕션 시스템으로 만드는 방법입니다. 가드레일(guardrails)이 정책을 강제하고, evals가 고객보다 먼저 회귀를 잡습니다.

의료 진단 보조 에이전트 예시: 어떤 증상을 어떤 진단과 연결했는지 전체 이력을 추적해야 합니다. 최종 진단은 의사가 확인해야 합니다. 새로운 모델 버전이 기존 버전보다 진단 정확도가 떨어지지 않았는지 테스트해야 합니다.

7. 비용과 워크플로우 최적화 (Cost & Workflow Optimization)

7번째 дисципли나(학문)는 아키텍처 판단입니다. 결정론적(deterministic) vs 비결정론적(non-deterministic)의 구분, 각 단계에 적합한 모델(최신/중형/소형/파인튜닝), 스킬 vs 메모리에 지식을 어디에 둘 것인지 — 이러한 설계 결정이 AI 시스템의 생존을 결정합니다.

예시: 고객 서비스 에이전트에서 티켓 분류는 소형 모델로 처리하고, 응답 초안 작성은 중형 모델, 복잡한 문제 해결은 최신 모델 + 인간 에스컬레이션으로 처리합니다.

새로운 경쟁 구도

Tomasz는 이것이 모든 카테고리에 적용되는 것은 아니라고 말합니다. 주요 연구소들이 우선순위로 삼는 시장에서는 그들의 빠른 대응력과 모델에 대한 직접적인 통제력이 유리합니다. 하지만 수천 개의 별도 시장이 스타트업에게 열려 있습니다.

핵심 질문: 모든 회사가 동일한 모델에 접근할 수 있게 되었을 때, 누가 이기는가? — 가장 좋은 기수(rider)가 이깁니다. 모델은 같지만 하네스가 다릅니다.

GeekNews 댓글 분석 — 하네스 유지 vs 제거 논쟁

GeekNews 댓글 8개에서 흥미로운 논쟁이 펼쳐집니다. 단순히 원문을 지지하거나 반대하는 것이 아니라, 실제 사용자 경험을 바탕으로 하네스의 가치를 재평가하는 논의입니다.

하네스 제거론 (4.7→4.8 모델 진화 관점)

한 사용자는 "저는 저에게 있던 하네스 설정을 모두 제거했습니다"라고 말합니다. 논리는 명확합니다:

• 하네스는 모델이 발전할수록 오히려 모델 성능을 제약하는 요소로 작용한다
• 어설픈 하네스 설정은 오히려 더 후진한 결과물을 만들어낸다
• 이미 GPT-4.7 이하에 있던 하네스 설정들은 4.8에서는 더 이상 의미가 없다
• GPT-5.5에서도 걸리적거리기만 한다

또 다른 사용자는 GPT-4.8에서 추가된 ultracode effort 기능이 이전 개발자가 수작업으로 만들었던 하네스 모드보다 더 잘 오케스트레이션을 처리한다고 지적합니다. 따라서 지금 시점에서 사용하던 하네스 모드에서 오케스트레이션 부분을 삭제하는 것이 더 낫다고 생각합니다.

세 번째 사용자는 동의하면서 "저도 4.7용 수제 오케스트레이션이나 장황한 플래닝 강제는 4.8에서는 방해라 들어냈어요"라고 말합니다.

하네스 유지론 (도메인 특화 관점)

반대 측의 논지는 더 세분화되어 있습니다. 한 사용자가 핵심을 찌릅니다:

"본문에 언급된 하네스 구성요소들은 단순히 LLM 지능이 높아진다고 해결될 내용들이 아닙니다."

하네스의 정의가 불명확했던 시절의 하네스를 말씀하신다면 그럴 수 있지만, 본문에서 다루는 하네스라면 앞으로도 지속 관리해야 할 영역입니다.

또 다른 사용자는 모델들이 지능 문제와 별개로 오케스트레이션, 도구 사용 능력도 함께 키우고 있다고 지적합니다. 오케스트레이션 분야가 하네스의 핵심 부분 중 하나였으나, 모델이 이미 그것을 지원한 상태입니다. 그럼 지금 시점에서 싸제 오케스트레이션과 정품 오케스트레이션이 있다고 했을 때 어떤 것을 쓰는 것이 맞을까요?

중도론 — 코드베이스의 나이에 따라 갈린다

가장 흥미로운 관점은 세 번째 사용자의 분석입니다:

"수십만 줄을 수년 유지보수한 코드베이스에서는 하네스의 진짜 가치가 오케스트레이션이 아니라 ultracode가 대체 못 하는 층(지식그래프, 도메인 컨벤션, 검증 불변식)에 있습니다. 그 컨텍스트 층은 남기고, 정말 독립적인 구간만 workflow로 병렬화했습니다."

반대로 신규 프로젝트라면 굳이 하네스 없이 ultracode가 맞습니다. 결국 "지운다 vs 남긴다"가 아니라 코드베이스 나이, 결합도에 따라 갈리는 문제입니다.

이 주장에 다른 사용자가 동의합니다: "오케스트레이션 부분을 뺀 부분은 여전히 가치 있습니다."

OpenAI 공식 입장

한 사용자가 OpenAI 홈페이지에 공식적으로 발표된 하네싱 포스팅을 인용합니다. OpenAI조차 자신들 내부 프로젝트에 하네싱을 사용한다는 것입니다. 하네싱은 분명 필요하고, 최종 구현 퀄리티에 직접적인 영향을 줍니다. 무엇보다 같은 퀄리티의 결과물을 구현하는데 드는 토큰을 절반까지 줄일 수 있습니다. 성능과 가격 전부를 잡을 수 있는데 안 쓸 이유가 없습니다.

새로운 시각

1. "하네스"의 정의가 진화하고 있다

GeekNews 댓글에서 드러나는 핵심 인사이트는 하네스의 정의 자체가 시대에 따라 달라진다는 점입니다. 2025년 초에 사람들이 말하던 하네스(프롬프트 템플릿, 시스템 프롬프트, 간단한 규칙)와 2026년의 하네스(지식그래프, 도메인 컨벤션, 검증 불변식)는 완전히 다른 개념에 가깝습니다.

Tomasz가 본문에서 정의하는 7가지 구성 요소는 후자에 더 가깝습니다. 즉, 모델이 자체적으로 오케스트레이션을 처리할 수 있게 되었다고 해서 하네스가 사라지는 것이 아니라, 하네스의 무게중심이 오케스트레이션에서 도메인 컨텍스트와 검증 메커니즘으로 이동하고 있습니다.

2. 모델 진화 vs 하네스 진화의 비동기성

댓글에서 "4.8에서는 하네스가 필요 없다"는 주장과 "하네스는 여전히 필요하다"는 주장은 둘 다 맞습니다. 왜냐하면 그들이 말하는 하네스가 다른 층(layer)이기 때문입니다.

• 1층 하네스(프롬프트/시스템 지시): 모델 진화에 의해 대부분 흡수됨
• 2층 하네스(오케스트레이션/루프): 모델의 내부 능력으로 일부 대체 가능
• 3층 하네스(도메인 컨텍스트/검증/거버넌스): 모델 진화와 무관하게 지속 필요

이 3층 모델을 이해하지 못하면 "하네스가 필요 없다"는 주장과 "하네스가 필수다"는 주장이 서로 다른 이야기를 하고 있다는 사실을 놓칩니다.

3. "최적의 하네스"는 프로젝트 수명에 따라 다름

신규 프로젝트 vs 레거시 코드베이스에 따라 하네스 전략이 달라져야 한다는 점은 매우 실용적인 통찰입니다. 신규 프로젝트에서는 모델의 내장 능력을 최대한 활용하고, 레거시 프로젝트에서는 도메인 컨텍스트 층을 유지하면서 오케스트레이션만 모델에 위임하는 하이브리드 접근이 가장 효율적입니다.

4. 비용 관점의 하네스 — 토큰 절감 효과

OpenAI 내부 사례에서 하네싱이 "같은 퀄리티의 결과물을 구현하는데 드는 토큰을 절반까지 줄일 수 있다"는 점은 매우 중요한 경제지표입니다. 모델이 똑똑해졌다고 해서 토큰 비용이 줄어드는 것은 아닙니다. 오히려 더 큰 모델은 더 비쌉니다. 하네스가 잘 설계되면 모델 호출 횟수를 줄이고, 컨텍스트 길이를 최적화하여 비용을 절감할 수 있습니다.

자녀/미래 영향

아인(첫째 딸) 관점

AI 시대의 디자이너는 단순히 UI를 그리는 사람이 아닙니다. 하네스 설계자 — AI 에이전트가 어떤 도구를 가지고, 어떤 컨텍스트에서, 어떻게 작동할지 설계하는 사람입니다. 디자인은 이제 프롬프트와 도구의 조합을 설계하는 일이 되었습니다.

석현/은한(둘째/셋째 아들) 관점

하네스의 7가지 구성 요소는 사실 컴퓨터 공학의 근본 개념을 다른 각도에서 바라본 것입니다. 상태 관리, 샌드박스, 관측성, 비용 최적화 — 이것들은 전통적인 소프트웨어 공학의 핵심 주제입니다. AI가 변하지만, 시스템 설계의 기본 원리는 변하지 않습니다.

관련 노트

• AI 에이전트 하니스 아키텍처 — Tomasz Tunguz — 같은 저자의 원문 분석 (7가지 구성 요소 상세)
• OpenAI 하네스 엔지니어링 — AI 에이전트 중심 개발 방식 — OpenAI의 실제 하네스 엔지니어링 사례
• LLM 지향 엔지니어링 — Yair Weinberger (Reindeer) — LLM 중심 개발 철학
• Claude Code 동적 워크플로우 — 심층 분석 — 오케스트레이션 패턴과 실패 모드
• The Founder's Playbook: Building an AI-Native Startup — Anthropic의 AI 네이티브 스타트업 가이드