마구 · 고삐
강한 말이라도 방향이 없으면 수레를 끌지 못한다. 마구는 말을 더 강하게 만들지 않지만 그 힘을 쓸모 있게 만든다.
AI가 더 강해지는 시대일수록 질문은 모델의 힘 자체에서 그 힘을 어떻게 묶고, 연결하고, 확인하고, 멈추게 할 것인가로 이동한다. 1장은 ‘Harness’라는 말의 오래된 뜻을 따라가며, AI 시대의 새로운 엔지니어링이 실은 오래된 공학의 귀환이라는 사실을 보여준다.
Vibe Coding, Prompt Engineering, Context Engineering. 새 이름이 너무 빨리 생겨나는 장면에서 회의가 생기는 것은 자연스럽다. 1장은 그 피로감을 숨기지 않는다. 오히려 그 반감에서 출발한다.
그러나 Harness Engineering은 누군가가 멋진 이름을 먼저 만들고 시장이 뒤따른 경우로 설명되지 않는다. 서로 직접 연결되지 않은 OpenAI, Mitchell Hashimoto, Martin Fowler 팀, LangChain이 몇 달 사이 비슷한 문제를 같은 단어로 가리켰다는 점이 핵심이다.
이미 여러 팀이 같은 종류의 작업을 하고 있었고, 뒤늦게 공통 언어가 생긴 장면에 가깝다.
코드를 직접 쓰는 일보다 AI가 움직일 환경과 경계를 설계하는 일이 더 중요한 비중을 갖기 시작했다.
Harness는 AI 업계가 만든 단어가 아니다. 1장은 그 어원을 1300년경의 고대 프랑스어 harnois까지 거슬러 올려놓는다. 초기 의미는 군대의 보급품, 갑옷과 장비였고, 이후 말에 씌우는 마구의 뜻으로 확장되었다.
군사 장비와 갑옷을 가리키던 말에서 출발한다. 핵심은 힘 자체가 아니라 힘이 임무를 수행할 수 있도록 갖추는 ‘장비의 체계’다.
동사로서는 ‘힘을 통제하고 이용 가능한 동력으로 바꾼다’는 비유적 의미가 자리 잡는다. 오늘날 AI 문맥의 핵심 의미도 여기에 닿아 있다.
모델의 지능을 더 크게 만드는 장치가 아니라, 지능이 실제 작업을 수행하도록 연결하고 제한하고 검증하는 환경을 뜻한다.
1장은 서로 다른 다섯 영역의 harness를 나란히 놓는다. 표면의 물건은 다르지만, 모두 핵심 힘을 대신하지 않는다. 힘이 엉뚱한 곳으로 새지 않도록 방향을 만들고, 연결을 보장하고, 실패를 막는다.
강한 말이라도 방향이 없으면 수레를 끌지 못한다. 마구는 말을 더 강하게 만들지 않지만 그 힘을 쓸모 있게 만든다.
NASA의 배선 표준은 움직임, 마모, 열원, 날카로운 모서리, 압착 강도까지 관리한다. 우주에서는 느슨한 선 하나가 임무 전체를 끝낼 수 있다.
stub과 driver를 통해 제어된 시험 환경을 만들고, 대상이 예측 가능한 조건에서 움직이게 한다.
행동을 없애지 않는다. 자유를 보존하면서 추락이 재난으로 이어지는 순간을 막는다.
엔진·센서·계기판을 하나의 작동 체계로 묶는다. 자체로 에너지를 만들지는 않지만 연결이 없으면 부품은 고립된다.
| 영역 | Harness 형태 | 핵심 기능 | AI Agent 대응 |
|---|---|---|---|
| 승마 | 고삐 / 마구 | 방향과 힘의 유도 | 제약 + 방향 |
| 항공우주 | 전기 하네스 | 정밀한 신호 전달 | 정보 / 컨텍스트 파이프라인 |
| 소프트웨어 테스트 | 테스트 하네스 | 격리 + 모의 환경 | 샌드박스 + 피드백 루프 |
| 안전 | 안전 하네스 | 실패 시 보호 | Guardrails / 롤백 |
| 군사(어원) | 갑옷 / 장비 | 보호 + 역량 부여 | Agent의 전체 장비 체계 |
1장은 2026년 2월 OpenAI가 제시한 정의를 중심에 둔다. 이 정의의 중요한 단어는 tool shell이다. Harness는 한 줄의 프롬프트나 하나의 설정 파일이 아니라, agent가 실제 세계에 영향을 미칠 수 있도록 둘러싸는 실행의 껍질이다.
1장의 정의는 이를 명시적으로 부정한다. Prompt는 agent에게 하는 말일 수 있지만, Harness는 agent가 실제로 움직이는 전체 환경이다.
지능을 높이는 장치가 아니라 지능이 행동으로 이어지게 하는 손과 발, 그리고 그 손과 발이 움직이는 조건이다.
따라서 Harness가 모델을 ‘더 똑똑하게’ 만든다는 표현은 정확하지 않다. 두뇌는 같은 두뇌일 수 있다. 달라지는 것은 그 두뇌가 무엇을 볼 수 있고, 무엇을 할 수 있고, 어디까지 갈 수 있으며, 잘못했을 때 어떻게 멈추고 되돌아오는가이다.
1장은 Harness Engineering의 새로움을 과장하지 않는다. 항공우주 분야는 오래전부터 자동 시스템을 둘러싸고 제약, 피드백 루프, 중복 점검, 예외 처리를 설계해 왔다. 산업 제어에서는 PLC의 안전 인터록이 같은 기능을 한다. 소프트웨어 테스트의 test harness 역시 개념적으로 닮아 있다.
새로운 것은 공학 원리 자체라기보다 적용 대상이다. 이전에는 인간이나 기계 장치가 규율의 대상이었다면, 이제는 생성형 AI agent의 자율성이 그 대상이 된다.
공통 언어가 없을 때는 서로 비슷한 일을 해도 각자의 기술로 남는다. 누군가는 CLAUDE.md를 쓰고, 다른 누군가는 AGENTS.md를 관리하며, 또 다른 팀은 hooks와 CI pipeline을 다듬는다. 이름이 없으면 이것들은 흩어진 팁처럼 보인다.
‘Harness Engineering’이라는 이름은 이들을 하나의 문제군으로 묶는다. 그 순간 경험은 비교할 수 있고, 설계 원칙은 전파될 수 있으며, 업무의 중심이 어디로 이동했는지 말할 수 있게 된다.