두 가지 용어가 소프트웨어 어휘에 빠르게 등장하고 있으며, 이들은 동일한 질문에 대한 매우 다른 두 가지 답변을 설명합니다. 즉, AI 에이전트가 우리의 코드를 작성한다면, 품질, 일관성 및 신뢰성을 보장하기 위해 우리는 그 주변에 무엇을 구축해야 하는가? 에 대한 질문입니다.

하네스 엔지니어링 (Harness Engineering)

Harness Engineering

하네스 (Harness)는 사람, 동물 또는 물체를 제어하거나 고정하기 위해 스트랩과 벨트가 달린 장비로 정의됩니다. 몇 가지 예로는 번지 점프를 할 때 사용하는 안전 하네스 (safety harness)나 아기용 하네스 (baby's harness)가 있습니다. 역사적으로 하네스는 말, 황소, 노새, 소와 같은 역용 동물과 밀접하게 연관되어 왔습니다. 쟁기를 끄는 황소는 일반적으로 하네스로 멍에를 멥니다. 그 의도는 무언가를 효과적으로 하네스(harness)하는 것이었습니다. 즉, 어떤 목적을 위해 그것의 힘을 효과적으로 유도하고, 제어하고, 사용하는 것입니다.

AI에서의 하네스는 AI 에이전트가 작동하는 방식을 형성하고 생성물을 확인하기 위해 에이전트 주변에 배치하는 모든 것을 의미합니다. 이 분야는 3가지 부분으로 나뉩니다. 가이드 (Guides)는 작업을 앞으로 이끌어 나갑니다. 여기에는 (a) 규칙 및 컨텍스트 파일 (rules and context files), (b) 명세 및 프롬프트 (specs and prompts), (c) 기술 및 예시 (skills and examples), (d) 에이전트가 활용할 수 있는 도구 (tools)가 포함됩니다. 두 번째 부분은 경계 (Boundaries)로, 효과적인 실행을 위한 제약 조건입니다. 여기에는 격리를 위한 샌드박스 (sandboxes), 권한 (permissions), 토큰 예산 (token budgets)이 포함됩니다. 이는 에이전트가 안전하게 실행되도록 제한할 뿐만 아니라, 사전에 정의된 리소스 제한 내에서 루프 (loop)를 돌며 실행되도록 보장합니다. 마지막 부분은 센서 (Sensors)입니다. 이것들은 결과를 검증합니다. 이는 컴파일러 (compilers), 린터 (linters), 테스트 (tests), 보안 스캔 (security scans), 그리고 점점 더 늘어나고 있는 AI 리뷰어 (AI reviewers)를 통해 수행됩니다.

하네스 엔지니어링 (Harness engineering)은 이러한 요소들을 의도적으로 결합하는 기술입니다. 초기 증거에 따르면, 이는 토큰 소비 (token consumption)를 줄이고 출력을 현저히 더 일관되게 만들며, 특정 명명된 지침 (named instructions)이 일반적인 가이드라인 (general guidance)보다 훨씬 뛰어난 성능을 보인다는 것을 시사합니다. 하지만 함정이 있습니다. 가장 효과적인 하네스는 그것을 뒷받침하는 모델 (backing models)과 함께 공동 개발된 것으로 보입니다. 하네스와 모델이 함께 훈련되고 테스트되는 것입니다. 이것이 Claude Code가 체급 이상의 성능을 내는 이유 중 일부이며, 우리의 모델들에 대해서도 불편한 질문을 던지게 합니다.

소프트웨어 팩토리 (Software Factory)

Software Factory

팩토리 (factory)는 기계를 사용하여 대량의 상품을 생산하는 건물들의 집합입니다. 소프트웨어 팩토리 (software factory)도 동일한 개념으로, AI 에이전트 (AI agents)를 기계로 사용하여 소프트웨어를 반복적이고 대규모로 빌드, 검증 및 출시하기 위해 일련의 시스템이 통합된 곳을 의미합니다.

**소프트웨어 팩토리 (software factory)**는 하네스를 논리적인 극한까지 밀어붙인 형태입니다. 즉, 인간을 제거하는 것입니다. 작업 항목의 백로그 (backlog)가 오케스트레이터 (orchestrator)에 공급됩니다. 오케스트레이터는 작업의 다양한 부분을 수행하기 위해 에이전트 군집 (agent swarm)을 파견합니다. 자동화된 체크 (automated checks)가 출력을 게이트 (gate)합니다. AI가 AI의 작업을 검토하고 병합 (merge)합니다. 배포 (deployment)는 연속적으로 이루어집니다. 그리고 텔레메트리 (telemetry) 또는 피드백 (feedback)이 다음 티켓 (tickets)을 생성합니다. 이 루프 (loop)는 생산 라인의 어느 곳에도 사람이 서 있지 않은 상태로 실행되고 닫힙니다. 이것이 약속하는 것은 처리량 (throughput)입니다. 인간의 한계 비용 (marginal human cost)이 거의 제로에 가까운 상태에서 24시간 내내 이루어지는 코드 생성입니다.

**하네스 엔지니어링 (Harness engineering)**은 개인의 기술(craft)에서 팀의 관행(practice)으로, 그리고 플랫폼 역량(platform capability)으로 발전하며 하나의 전문 분야로 성숙할 것입니다. 이 과정에서 공유된 하네스 구성 요소들은 중앙에서 관리되고, 판단(judgement)은 현장의 팀들에게 연합(federated)되어 다시 전달될 것입니다. 이러한 진전 단계들을 정의할 두 가지 문제는 센서의 무결성(sensor integrity)입니다. 즉, 우리가 구축하는 센서들이 얼마나 정확하고, 유용하며, 신뢰할 수 있는가의 문제입니다. 두 번째는 교정(calibration)입니다. AI 판사(AI judges)들은 그 누구도 측정하는 속도보다 더 빠르게 확산되고 있으며, 지속 가능한 하네스는 시간이 지남에 따라 자동 검토자(AI)의 점수를 인간의 결정과 비교하여 측정하고 이를 통해 개선되는 하네스가 될 것입니다.

소프트웨어 팩토리(Software factories)는 자신들의 틈새 시장과 한계를 발견하게 될 것입니다. 팩토리는 정확성을 검증하는 비용이 저렴하고, 오류를 되돌리는 비용이 저렴할 때 진정으로 실행 가능합니다. 예를 들어 트랜잭션 백엔드(transactional back-ends), 강력한 준수 테스트 스위트(conformance test suites)와 내부 도구에 의해 관리되는 레거시 재작성(legacy rewrites) 등이 이에 해당합니다. 하지만 한계는 구조적입니다. 오늘날의 모델들은 빠른 신호(fast signals) — 컴파일 여부, 테스트 통과 여부, 린트 체크(lint checks)의 청결도 — 를 바탕으로 학습됩니다. 그러나 모델들이 대응하지 못하는 부분은 설계(design), 유지보수성(maintainability), 의도에 대한 충실도(fidelity to intent)이며, 이러한 요소들은 자동화된 체크가 없는 수개월의 시간 동안 표면화될 것입니다. 팩토리에는 느린 신호(slow signals)를 처리할 스테이션이 없으므로, 요란하게 실패하지 않습니다. 대신 초록색 체크 표시 뒤에서 조용히 부채(debt)를 쌓아갑니다.

결론
이 두 개념은 경쟁 관계라기보다 하나의 다이얼을 조절하는 두 가지 설정에 가깝습니다. 즉, 에이전트(agent)에게 얼마나 많은 결정을 맡길 것인가, 그리고 에이전트가 하는 일에 대해 어떻게 확신을 유지할 것인가의 문제입니다. 답은 상황에 따라 다릅니다. 결과를 저렴하게 확인할 수 있고 그 확인 과정을 신뢰할 수 있다면, 에이전트에게 더 많은 자유를 줄 수 있습니다. 만약 확인 작업이 어렵거나 실수의 비용이 크다면, 통제(leash)를 짧게 유지해야 합니다. 우리는 인간의 판단(human judgement)을 가장 중요한 곳, 즉 시작 단계에서 무엇이 옳은지를 정의하고 마지막 단계에서 최종 결정을 내리는 곳에 배치해야 합니다. 하지만 그 사이 단계에 있는 자동화된 판사들을 여전히 신뢰할 수 있는지 정기적으로 테스트해야만 합니다.