요약 (TL;DR) — 모든 AI 시스템은 중요한 두 가지 요소로 분해됩니다: 바로 **모델 (model)**과 하네스 (harness) (모델을 감싸는 코드)입니다. Claude Code, GitHub Copilot, ChatGPT — 이것들은 하네스이지 모델이 아닙니다. 현재는 최첨단 연구소(frontier labs)만이 이 두 부분을 모두 구축하고 있습니다. 하지만 이는 오래가지 않을 것입니다. 하네스 엔지니어링 (harness engineering)이 도메인 특화적이고 모델 불가지론적 (model-agnostic)인 독자적인 분야로 자리 잡으면서, 현재 우리가 소프트웨어 엔지니어링이라 부르는 것의 대부분을 흡수할 것입니다. 앱 스토어는 **에이전트 스토어 (agent store)**가 될 것이며, 우리의 업무는 인간을 위한 코드를 작성하는 것에서 인간의 워크플로우를 자동화하는 하네스를 작성하는 것으로 전환될 것입니다.

누군가 AI 엔지니어링이 실제로 어디로 향하고 있는지 물을 때마다 저는 한 가지 공식으로 계속 돌아가게 됩니다:

에이전트 (Agent) = 모델 (Model) × 하네스 (Harness)

너무 단순하게 들릴 수도 있습니다. 하지만 이 공식은 에이전트가 무엇인지, 누가 에이전트를 만드는지, 그리고 우리의 직업이 어떻게 변할지에 대한 놀라울 정도로 많은 혼란을 해소해 주는 선을 긋습니다.

구분: 모델 vs 하네스

Claude Code는 에이전트입니다. GitHub Copilot은 에이전트입니다. 그것들의 CLI(Command Line Interface)도 에이전트입니다. ChatGPT도 에이전트입니다.

이 중 그 어느 것도 모델이 아닙니다. 그것들은 **하네스 (harnesses)**입니다. 즉, 원시적인 다음 토큰 예측 (next-token prediction)을 계획하고, 도구를 호출하며, 컨텍스트를 유지하고, 재시도하며, 결과를 전달하는 무언가로 바꿔주는 LLM (Large Language Model) 기반의 소프트웨어 인프라입니다.

머릿속에 명확하게 정리하는 방법은 다음과 같습니다:

GPT-5.5가 모델이라면, ChatGPT는 그것을 감싸는 하네스입니다.

모델은 하나의 재료입니다. 하네스는 요리입니다.

이것은 말꼬리 잡기가 아닙니다. 이 둘을 분리함으로써 모든 AI 시스템의 최고 수준에서 중요한 유일한 두 가지 레버(levers)를 얻을 수 있습니다:

• 모델 (The model) — 원시적인 추론 (reasoning). 교체 가능합니다. 당신이 통제할 수 없는 곡선을 그리며 발전합니다.
• 하네스 (The harness) — 목표, 루프 (loops), 도구 (tools), 메모리 (memory), 평가 (evals), 제품 인터페이스. 당신이 실제로 엔지니어링하는 부분입니다.

(세 번째 재료인 **데이터 (data)**가 있지만, 이는 양쪽 모두에 내재되어 있습니다. 데이터는 모델을 학습시키고, 하네스를 통해 흐릅니다.)

AI 제품에서의 거의 모든 흥미로운 엔지니어링 결정은 모델이 아니라 하네스 (harness)에 존재합니다. 어떤 프롬프트 (prompts)를 사용할지, 어떤 도구 (tools)를 어떤 가드레일 (guardrails)과 함께 사용할지, 루프 (loop)가 어떻게 종료될지, 무엇이 기억될지, 실패를 어떻게 포착할지 등이 여기에 해당합니다. 당신은 GPT를 학습시키는 것이 아니라, 그것을 감싸는 (wrap) 것입니다. 그 감싸는 과정이 바로 핵심적인 작업 (work)입니다.

왜 지금 이 프레임워크가 중요한가

이 정의를 하나의 논제 (thesis)로 바꾸는 부분이 여기에 있습니다.

오늘날, 오직 프런티어 랩 (frontier labs)만이 양쪽 모두를 구축합니다. OpenAI는 GPT와 ChatGPT를 모두 만듭니다. Anthropic은 Claude와 Claude Code를 모두 만듭니다. 모델과 하네스는 동일한 건물에서, 동일한 회사에 의해 하나의 번들 (bundle)로 출시됩니다.

하지만 이는 일시적인 상태입니다. 이는 모든 플랫폼의 초기 단계에서 나타나는 모습입니다. 엔진을 만드는 사람이 유일한 자동차도 함께 만드는 것과 같습니다.

상황은 계속 이렇게 유지되지 않을 것입니다. 왜냐하면 하네스는 모델로부터 분리 가능하기 때문이며, 우리는 이미 그 분리가 시작되는 것을 목격하고 있습니다.

GitHub Copilot이 가장 명확한 예고편입니다. 이는 어떠한 주요 모델이라도 감쌀 수 있는 하네스입니다. 내부적으로 서로 다른 프런티어 모델 (frontier models)을 지정할 수 있습니다. 하네스가 제품이며, 모델은 교체 가능한 백엔드 (backend)입니다. 이것이 일반화된 미래의 모습입니다: 모델에 구애받지 않고 (model-agnostic), 에이전트가 작동하는 도메인에 점점 더 특화되는, 일급 제품 (first-class products)으로서의 하네스.

코딩 하네스는 도구 접근 권한, 리포지토리 컨텍스트 (repo context), 그리고 테스트 루프 (test loops)를 원합니다. 법률 하네스는 인용의 규율과 검색 근거 (retrieval grounding)를 원합니다. 지원 (support) 하네스는 상태 검증 (state verification)과 에스컬레이션 경로 (escalation paths)를 원합니다. 금융 하네스는 결정론 (determinism)과 감사 추적 (audit trails)을 원합니다. 기반이 되는 모델은 동일하지만, 하네스는 근본적으로 다릅니다. 왜냐하면 엔지니어링이 살아 숨 쉬는 곳은 바로 *도메인 (domain)*이기 때문입니다.

주장: 하네스 엔지니어링이 소프트웨어 엔지니어링을 흡수한다

이제 대담한 버전을 말씀드리겠습니다. 이것이 대담한 주장이라는 점은 저도 인정합니다:

하네스 엔지니어링 (harness engineering)이 독자적인 학문으로 성숙함에 따라, 현재 우리가 소프트웨어 엔지니어링이라고 부르는 것의 대부분을 집어삼킬 것입니다.

이를 에이전트 중심 엔지니어링 (agentic engineering)이라 부르든, 하네스 엔지니어링 (harness engineering)이라 부르든 — 그 명칭보다는 변화 자체가 더 중요합니다. 작업의 무게 중심이 우리가 직접 결정론적 로직 (deterministic logic)을 작성하는 것에서, 모델이 비결정론적 (non-deterministic)인 부분을 잘 수행할 수 있도록 모델을 감싸는 시스템을 설계하는 것으로 이동하고 있습니다.

저만 이렇게 지적하는 것이 아닙니다. Dario Amodei는 공개적으로 이와 유사한 내용을 언급해 왔습니다 — 코드의 엄청난 부분과 일반적인 지식 노동 전반이 사람이 직접 입력하는 방식이 아니라, 이러한 시스템에 의해 작성되고 운영되는 방향으로 나아가고 있다는 것입니다. 그 방향성을 이해하기 위해 가장 공격적인 타임라인까지 받아들일 필요는 없습니다.

그리고 우리는 이미 그 초기 흔적들을 목격하고 있습니다:

• 기업들이 기존 제품에 **챗봇과 에이전트 (chatbots and agents)**를 결합하고 있습니다 — 처음에는 구석에 있는 위젯 같은 부가 기능으로 시작합니다.
• 그러다 이러한 기능들이 단순한 부가 기능에 머물지 않고 핵심 서비스로 스며듭니다 (bleed into the core offering). 에이전트는 제품 옆에 있는 부수적인 존재가 아니라, 제품을 사용하는 주요 방식이 됩니다.

이 흐름을 끝까지 따라가 보면 **에이전트 중심 앱 생태계 (agentic app ecosystem)**에 도달하게 됩니다. 앱스토어를 떠올려 보세요 — 하지만 에이전트를 위한 것입니다. 즉, **에이전트 스토어 (agent store)**입니다.

이것은 절벽이 아니라 스펙트럼 상에서 일어납니다

여기서 저는 정확하게 말하고 싶습니다. 왜냐하면 이 견해에 대한 게으른 해석은 "AI가 모든 코드를 대체한다"는 것인데, 이는 틀린 말이기 때문입니다.

현실적인 버전은 **스펙트럼 (spectrum)**입니다:

• 기초적인 비즈니스 프로세스는 코드와 결정론 (determinism) 중심의 상태를 유지합니다. 결제, 원장, 인증(auth), 그리고 "대략적으로 맞는 것"이 결함이 되는 모든 영역 — 이들은 결정론적 코드(deterministic code)로 남을 것이며, 그래야만 합니다. 확률론적 모델 (probabilistic model)이 당신의 복식부기 (double-entry accounting)를 프리랜서처럼 마음대로 처리하게 두고 싶지는 않을 것입니다.
• 인간 중심의 부분들은 에이전트에 의해 자동화됩니다. 오직 사람만이 할 수 있다는 이유로 결코 자동화되지 않았던 모든 판단, 글루 코드 (glue), 분류 (triage), 그리고 워크플로(workflow) — 이것이 바로 에이전트가 진입하는 영역입니다. 결정론적 핵심을 대체하는 것이 아니라, 과거에 인간의 개입 (human in the loop)을 필요로 했던 그 주변의 간극을 메움으로써 (filling the gaps around it) 이루어집니다.

따라서 작업이 사라지는 것은 아닙니다. 그것은 **재편(re-shapes)**됩니다. 우리의 업무는 단순히 _"다른 사람들이 사용할 코드를 작성하는 것"_에서 점차 _"에이전트(agents)를 통해 인간의 워크플로우를 자동화하는 시스템을 작성하는 것"_으로 변합니다. 결정론적인 중추(deterministic spine)는 그대로 유지되지만, 그 주변의 연조직(soft tissue)이 에이전트화(agentic)됩니다.

이것이 우리의 역할에 의미하는 바

시야를 넓혀보면, 이 분야는 앞서 언급한 공식과 동일한 선을 따라 명확하게 나뉩니다:

개발자는 하네스(harness) 측으로 이동하고, ML 종사자들은 모델(model) 측을 담당합니다.

• 모델 측 (Model side) — 가공되지 않은 추론 엔진(raw reasoning engine)을 훈련, 미세 조정(fine-tuning), 평가 및 개선하는 사람들입니다. 이 영역은 전문화된 상태로 유지되며 ML을 수행하는 사람들의 몫으로 남습니다.
• 하네스 측 (Harness side) — 목표를 설계하고, 도구(tools)를 연결하며, 피드백 루프(feedback loops)를 닫고, 평가(eval) 및 관측성(observability) 레이어를 구축하며, 에이전트가 구동되는 도메인 특화 제품을 형성하는 사람들입니다. 대부분의 개발자가 도달하게 될 지점이 바로 여기입니다.

이것은 소프트웨어 엔지니어의 격하가 아닙니다. 그것은 재배치입니다. 정확성(correctness), 안전성(safety), 지연 시간(latency), 비용(cost), 그리고 사용자 신뢰가 실제로 결정되는 곳은 바로 하네스입니다. 모델은 당신에게 역량(capability)을 제공하지만, 그 역량이 제품이 될지 아니면 부채(liability)가 될지를 결정하는 것은 하네스입니다.

솔직한 주의사항

과장하기 쉬운 부분에 대해 미리 경고를 드리고자 합니다. 이 모든 것이 _"모델이 모든 것을 수행하고 엔지니어는 퇴근한다"_는 뜻은 아닙니다. 오히려 그 반대입니다. 모델이 더 유능해질수록, 하네스는 덜 중요한 것이 아니라 더 중요해집니다. 왜냐하면 허술한 하네스를 가진 더 유능한 모델은, 더 유능한 방식으로 실패하는 방법이 되기 때문입니다. 기반이 되는 모델이 개선됨에 따라 훌륭한 하네스 엔지니어링의 레버리지(leverage)는 _상승_합니다.

이것이 이 모든 베팅의 핵심입니다. 모델은 당신이 통제할 수 없는 곡선을 그리며 스스로 개선되고 있습니다. 당신의 에이전트(agent) — 즉 당신의 제품, 당신의 회사, 당신의 역할 — 가 개선될 것인가의 문제는 바로 당신의 **하네스(harness)**에 관한 문제입니다.

에이전트 (Agent) = 모델 (Model) × 하네스 (Harness). 모델 부분은 우리 모두에게 무료로 제공되고 있으며, 매 분기마다 더 좋아지고 있습니다. 하네스 부분은 우리가 엔지니어링할 수 있는 영역입니다. 바로 그곳에 향후 10년간의 작업이 존재하며, 제가 베팅을 걸고 있는 지점이기도 합니다.

이 글은 제가 LinkedIn에 처음 게시했던 생각의 긴 버전(long-form)입니다. 짧고 강렬한 요약과 그에 대한 논의를 원하신다면 여기를 확인하세요: 원문 LinkedIn 포스트. 하네스 내부에 실제로 무엇이 들어가는지 — 목표 (goals), 루프 (loops), 도구 (tools), 렌즈 (lens), 그리고 평가 (evals) — 그리고 왜 당신의 평가 레이어 (eval layer)가 도구로서 옆에 있는 것이 아니라 에이전트의 일부인지에 대한 동반 기사는 Agent = Model × Harness: Your Eval Layer Is Part of the Agent를 참조하세요.