하네스 엔지니어링이 필요한 이유

모델은 엔진이고, 하네스는 작동 조건이다

AI를 도입할 때 가장 먼저 떠올리는 것은 보통 모델이다. 더 큰 모델, 더 빠른 모델, 더 똑똑한 모델을 찾는다. 물론 모델의 성능은 중요하다. 하지만 프로덕션 환경에서 결과의 안정성을 결정하는 것은 모델 하나가 아니다. 모델을 어떤 입력과 함께 실행하는지, 어떤 도구를 쓸 수 있게 하는지, 어디까지 권한을 줄 것인지, 결과를 어떻게 검증하고 되돌릴 것인지가 함께 결과를 만든다.

이 실행 구조를 이 책에서는 하네스라고 부른다.

물리적인 하네스를 생각해보자. 작업자가 높은 곳에서 일할 때 하네스는 작업자를 대신해 일을 하지는 않는다. 하지만 작업자가 움직일 수 있는 범위, 추락했을 때 멈추는 방식, 장비와 몸이 연결되는 지점을 결정한다. 자동차나 항공기의 배선 하네스도 마찬가지다. 전기를 만드는 장치는 아니지만, 전선이 올바른 곳으로 연결되고 진동과 열, 마찰 속에서도 안정적으로 작동하도록 묶고 보호한다.

AI에서 하네스도 비슷하다. 모델이 생각하고 문장을 생성하는 엔진이라면, 하네스는 그 엔진이 안전하고 반복 가능하게 일하도록 붙잡는 구조다. 좋은 하네스는 모델의 능력을 제한하기만 하는 장치가 아니다. 오히려 모델이 실제 업무에서 쓸 수 있는 능력으로 바뀌도록 길을 만들어준다.

'좋은 프롬프트'만으로는 부족하다

초기 AI 데모는 좋은 프롬프트 하나로도 그럴듯하게 보인다. 사용자가 질문을 넣고, 모델이 답한다. 몇 번의 시연에서 인상적인 결과가 나오면 곧바로 제품이 될 것처럼 느껴진다.

하지만 운영 단계에 들어가면 문제가 달라진다. 같은 질문도 고객, 날짜, 정책, 권한, 이전 대화, 시스템 상태에 따라 다른 답을 요구한다. 모델이 한 번 멋진 답을 하는 것보다, 비슷한 일을 매일 수천 번 처리하면서 허용 가능한 범위 안에 머무는 것이 더 중요해진다.

프롬프트는 중요한 제어 수단이다. 그러나 프롬프트는 하네스의 일부일 뿐이다. 프롬프트가 모델에게 '무엇을 하라'고 말한다면, 하네스는 그 일이 실제로 가능한 환경을 만든다. 필요한 정보를 제공하고, 사용할 수 있는 도구를 제한하며, 결과를 검사하고, 실패했을 때 복구 경로를 제공한다.

예를 들어 고객 환불을 처리하는 AI 에이전트를 생각해보자. '친절하게 환불 요청을 처리하라'는 프롬프트만으로는 충분하지 않다. 에이전트는 주문 상태를 조회할 수 있어야 하고, 환불 정책을 알아야 하며, 환불 한도 이상의 요청은 사람에게 넘겨야 한다. 이미 환불된 주문에 다시 환불을 실행하지 않도록 검증도 필요하다. 이 구조가 없으면 좋은 문장을 쓰는 모델이 위험한 업무 실행자가 된다.

비슷한 말, 다른 영역: 세 가지 하네스

하네스라는 말은 이미 여러 분야에서 쓰인다. 혼동을 줄이기 위해 세 가지를 구분해야 한다.

첫째, 와이어 하네스 엔지니어링은 물리적인 배선 묶음을 설계하는 일이다. 자동차, 항공기, 산업 장비 안에서 여러 전선을 정해진 경로로 묶고 보호하며, 각 부품이 안정적으로 연결되도록 만든다. 핵심은 전기 신호와 전력을 안전하게 전달하는 물리적 구조다.

둘째, Harness.io 같은 CI/CD 제품에서의 하네스는 소프트웨어 배포 파이프라인을 자동화하고 관리하는 의미에 가깝다. 코드를 빌드하고 테스트하고 배포하는 과정을 표준화해, 변경 사항이 더 안전하게 운영 환경으로 나가도록 돕는다. 여기서 관심사는 소프트웨어 전달 과정의 자동화와 통제다.

셋째, AI 하네스 엔지니어링은 AI 모델이 업무를 수행하는 실행 환경을 설계하는 일이다. 프롬프트, 컨텍스트, 도구 호출, 권한, 검증기, 로그, 평가, 휴먼 승인, 롤백 전략을 하나의 구조로 묶는다. 목표는 모델이 매번 완벽하다고 가정하는 것이 아니라, 불완전한 모델도 운영 가능한 방식으로 일하게 만드는 것이다.

세 영역은 서로 다르지만 공통점이 있다. 하네스는 핵심 장치를 대체하지 않는다. 대신 핵심 장치가 실제 환경에서 안정적으로 작동하도록 연결하고 보호하고 통제한다.

같은 모델도 다른 결과를 내는 이유

AI 모델은 고정된 함수처럼 보이지만, 실제 사용에서는 입력 조건에 크게 영향을 받는다. 특히 에이전트형 AI에서는 모델 자체보다 주변 조건이 결과를 크게 바꾼다.

첫 번째 조건은 컨텍스트다. 모델은 현재 대화창에 들어온 정보와 시스템이 제공한 자료를 바탕으로 판단한다. 같은 모델이라도 최신 정책 문서, 고객 이력, 코드베이스 구조, 이전 결정 기록을 받으면 훨씬 정확하게 행동한다. 반대로 필요한 정보가 없으면 추측한다. 추측은 데모에서는 창의성처럼 보일 수 있지만, 운영에서는 장애가 된다.

두 번째 조건은 도구다. 모델이 단순히 답변만 할 수 있는지, 데이터베이스를 조회할 수 있는지, 코드를 실행할 수 있는지, 결제를 취소할 수 있는지에 따라 역할은 완전히 달라진다. 도구는 모델의 손과 발이다. 그러나 손과 발이 생기면 실수의 비용도 커진다. 그래서 도구의 입력 형식, 실행 조건, 실패 응답, 재시도 방식이 명확해야 한다.

세 번째 조건은 권한이다. 모든 도구를 항상 열어두면 에이전트는 빠르게 움직일 수 있지만 위험해진다. 반대로 권한을 지나치게 줄이면 아무 일도 끝내지 못한다. 좋은 하네스는 업무의 위험도에 따라 권한을 나눈다. 읽기 작업은 넓게 허용하고, 쓰기 작업은 제한하며, 되돌리기 어려운 작업은 승인 단계를 둔다.

네 번째 조건은 검증 루프다. 모델의 첫 답을 최종 결과로 바로 쓰면 품질은 모델의 순간 판단에만 의존한다. 하지만 결과를 규칙, 테스트, 평가 모델, 사람 검토로 다시 확인하면 실패를 줄일 수 있다. 코드 생성 에이전트라면 테스트를 실행해야 하고, 문서 작성 에이전트라면 누락된 요구사항을 점검해야 한다. 검증 루프는 AI 시스템을 '한 번 답하는 장치'에서 '품질을 개선하는 작업자'로 바꾼다.

데모 단계와 운영 단계는 다른 게임이다

데모 단계의 AI와 운영 단계의 AI는 겉보기에는 비슷하다. 둘 다 모델을 호출하고 결과를 보여준다. 하지만 실제 요구사항은 크게 다르다.

데모에서는 가장 잘 맞는 입력을 고를 수 있다. 운영에서는 사용자가 입력을 고른다. 데모에서는 실패한 장면을 넘길 수 있다. 운영에서는 실패가 기록되고 누적된다. 데모에서는 모델의 가능성이 중요하지만, 운영에서는 시스템의 책임성이 중요하다.

이 차이를 이해하지 못하면 AI 프로젝트는 자주 같은 지점에서 멈춘다. 시연은 훌륭하지만 배포가 어렵다. 내부 테스트는 괜찮지만 실제 고객 앞에서는 불안하다. 한 명의 숙련자가 사용할 때는 좋아 보이지만 팀 전체가 쓰면 결과가 흔들린다. 이때 필요한 것이 모델 교체만은 아니다. 실행 구조를 설계하는 하네스 엔지니어링이 필요하다.

하네스 엔지니어의 역할 변화

소프트웨어 개발에서 엔지니어는 오랫동안 코드를 직접 생산하는 사람으로 이해되었다. 요구사항을 읽고, 설계를 하고, 코드를 작성하고, 테스트를 고쳤다. AI 에이전트가 코드와 문서, 분석 결과를 점점 더 많이 생성하면서 이 역할은 바뀌고 있다.

하네스 엔지니어는 에이전트가 안정적으로 일하는 환경을 설계하는 사람이다. 직접 모든 코드를 쓰는 대신, 에이전트가 어떤 작업을 맡을 수 있는지 정의한다. 어떤 파일을 읽게 할지, 어떤 명령을 실행하게 할지, 어떤 결과를 성공으로 볼지 정한다. 실패하면 어떻게 멈추고, 언제 사람에게 물어보고, 어떤 로그를 남길지도 설계한다.

이 역할은 단순히 자동화를 많이 붙이는 일이 아니다. 에이전트를 신뢰하되, 맹신하지 않는 구조를 만드는 일이다. 모델의 강점은 활용하고 약점은 시스템으로 보완한다. 빠른 생성 능력은 도구와 연결하고, 불안정한 판단은 검증 루프로 감싼다. 넓은 지식은 컨텍스트로 좁히고, 과도한 자율성은 권한 경계로 조절한다.

앞으로 좋은 AI 시스템은 '가장 똑똑한 모델을 쓴 시스템'만을 뜻하지 않는다. 좋은 모델을 적절한 정보, 안전한 도구, 명확한 권한, 반복 가능한 평가와 결합한 시스템이 더 오래 살아남는다. 하네스 엔지니어링은 그 결합을 설계하는 기술이다.

이 책의 출발점

이 책은 모델을 더 잘 고르는 법보다, 모델이 일할 수 있는 구조를 만드는 법에 초점을 둔다. 프롬프트는 그 구조의 시작이지만 끝은 아니다. 컨텍스트 관리, 입출력 계약, 도구 설계, 권한 통제, 실패 복구, 평가, 관측 가능성이 함께 있어야 AI는 데모를 넘어 운영으로 간다.

하네스 엔지니어링의 핵심 질문은 단순하다.

이 모델이 한 번 좋은 답을 하게 만들 것인가, 아니면 반복해서 안전하게 일하게 만들 것인가.

프로덕션 AI 에이전트를 만들고 싶다면 두 번째 질문에서 출발해야 한다. 모델은 계속 바뀐다. 더 빠르고 더 강한 모델이 나올 것이다. 그러나 모델을 둘러싼 실행 구조를 설계하는 능력은 쉽게 사라지지 않는다. 그 구조가 AI의 결과를 안정시키고, 팀이 AI를 실제 업무에 맡길 수 있게 만든다.