AI 에이전트를 도입했는데 아무도 안 쓴다면, 모델이 아니라 하네스를 봐야 합니다

사내에 AI 플랫폼을 깔아두고도 실제로 쓰는 사람은 한두 부서에 그친다는 이야기를 요즘 부쩍 자주 듣습니다. 대개는 모델 탓을 하시더군요. GPT가 별로라서, 우리 데이터가 정리가 안 돼서, 아니면 아직 기술이 덜 익어서. 그런데 같은 모델을 쓰면서도 잘 돌아가는 조직과 그렇지 않은 조직이 갈리는 걸 보면, 문제는 모델보다 그 모델을 감싸고 있는 케이스에 있는 경우가 훨씬 많습니다. 요즘 해외에서 그 케이스를 하네스(harness)라고 부르고 있습니다.

에이전트 하네스(Harness)란 무엇인가

에이전트 하네스는 모델을 감싸는 소프트웨어 계층입니다. AI가 실제로 일할 수 있게 환경과 지침, 도구를 쥐여주고 결과가 나올 때까지 다시 시도하게 만듭니다.
흔히 [에이전트] = [모델] + [하네스] 라는 식으로 정리하죠.

이름은 등반할 때 몸에 차는 안전벨트에서 따왔습니다. 등반용 하네스처럼 로프를 걸어 추락을 막아주면서 초크백이나 퀵드로를 목적에 맞게 달았다 뗐다 할 수 있게도 해주죠. AI 하네스도 모델을 붙잡아두는 역할과 필요한 장비를 붙여주는 역할을 같이 합니다.

Earendil이 정리한 하네스 설명 참고 링크

구성은 보통 네 가지입니다.

여기서 눈여겨보실 대목은 목록 자체가 아닙니다. 이 네 가지가 전부 회사가 직접 만들고 소유하는 영역이라는 사실입니다. 모델이야 사서 쓰면 그만이지만 하네스는 그럴 수가 없거든요.

Databricks가 재본 비용 차이

하네스가 정말 그 정도로 중요하냐는 질문에는 Databricks가 자사 코드베이스로 진행한 벤치마크가 꽤 분명한 답을 줍니다. 수백만 줄짜리 실제 코드베이스에서 엔지니어들이 실제로 처리했던 작업을 그대로 가져다 측정했습니다. 같은 모델을 같은 조건으로 돌려도 어떤 하네스를 통했느냐에 따라 작업당 비용이 2배 넘게 벌어졌습니다. 품질은 비슷했고요.

원인은 문맥 관리였습니다. 한쪽 하네스가 매 턴마다 모델에게 훨씬 적은 문맥을 넘기면서 작업 범위를 좁게 유지했고 그 덕에 더 적은 시도로 일을 끝냈다는 겁니다. Databricks는 토큰 단가로 비용을 비교하는 방식이 실제 비용을 거의 설명하지 못한다는 점도 이 벤치마크에서 함께 짚었습니다. 저는 이쪽이 국내 기업 담당자분들께 더 와닿는 이야기라고 봅니다. 견적서에 찍히는 백만 토큰당 단가는 결재는 통과시키기 쉬워도 실제 청구서와는 별로 관계가 없거든요.

모델은 애초에 회사가 통제할 수 있는 변수가 아닙니다. 몇 달마다 세대가 바뀌고, 가격도 정책도 우리가 정하지 않고, 경쟁사도 똑같은 걸 씁니다. 반면 하네스에는 우리 회사의 업무 용어와 결재 규칙, 데이터 구조, 권한 경계가 들어가고 그건 어떤 AI 회사도 대신 만들어주지 않습니다. 모델이 렌터카라면 하네스는 우리가 낸 길입니다. 차는 계속 바뀌어도 길은 남습니다.

왜 우리 회사 에이전트는 한 부서에서 멈춰 있을까

해외에서 하네스가 화제가 된 맥락은 "개인이 자기 하네스를 소유하면 AI 회사에 끌려다니지 않는다"는 쪽이었습니다. 개발자 한 명이 자기 노트북에서 시스템 프롬프트를 고쳐 쓰고 도구를 붙여가며 자기만의 작업 환경을 만드는 그림이죠. 개인 입장에서는 분명 멋진 이야기인데 회사 입장에서 그대로 옮겨놓고 보면 이건 두 가지 골칫거리의 정의에 가깝습니다.

첫 번째는 확산이 안 된다는 것. AI를 잘 쓰는 직원은 자기 하네스를 계속 다듬습니다. 잘 먹히는 프롬프트, 손에 익은 도구 조합, 어떤 질문에는 어떻게 물어야 한다는 감각까지 전부 그 사람 노트북과 머릿속에 쌓입니다. 옆자리 동료에게는 그중 아무것도 넘어가지 않죠. 플랫폼은 도입했는데 쓰는 사람은 일부뿐이라는 상황, 그 상당수는 하네스가 개인 소지품으로 남아 회사 자산이 되지 못한 상태입니다. 도입에 실패한 게 아니고요.

두 번째는 통제가 안 된다는 것. 각자 자기 하네스를 소유한다는 말은, 회사 관점에서는 각자 자기 규칙으로 사내 데이터를 물린 에이전트가 돌아간다는 뜻입니다. 어떤 지침을 줬는지, 어떤 데이터를 건드렸는지, 왜 그런 답이 나왔는지 나중에 아무도 되짚을 수가 없죠. 사고가 나면 로그가 없어서 원인 규명부터 막힙니다.

개인의 편의와 회사의 통제가 정면으로 부딪히는 지점입니다. 그렇다고 어느 한쪽을 포기할 일은 아닙니다. 개인이 만들되 조직이 공유하고 감독할 수 있는 하네스 계층을 따로 두면 됩니다.

부탁과 통제

거버넌스를 고민하시는 조직에서 가장 흔히 하는 선택이 규칙을 시스템 프롬프트에 몽땅 적어 넣는 겁니다. 심정은 이해가 갑니다. 제일 빠르고 제일 싸니까요.

해외 개발자 커뮤니티 반응 중에 사내 회계 에이전트를 만든 사람의 경험담이 있습니다. 처음에는 업무 절차를 아주 상세한 스킬로 잔뜩 작성해서 물려줬다더군요. 결과는 반대로 나왔습니다. 2천 줄짜리 절차를 따르게 하니 오히려 에이전트의 판단력이 떨어졌습니다. 결국 도구와 안전장치만 주고 판단은 모델에게 맡겼더니 상세 지침을 줬을 때보다 성능이 좋아졌다는 이야기였습니다.

지시문으로 넣은 통제는 성능을 깎아먹고 그마저도 지켜졌다는 보장이 없습니다.

"고객 개인정보는 외부로 보내지 마"라고 프롬프트에 적는 것과 애초에 그 도구를 호출할 권한을 주지 않는 것은 완전히 다른 일입니다. 앞쪽은 부탁에 그치죠. 그래서 통제는 지침이 아니라 하네스의 각 층에 구조로 박혀 있어야 합니다.

모델은 넓게 풀어두고 경계만 단단히 잠그는 방식입니다. 성능과 거버넌스를 같이 챙기려면 이 길밖에 없습니다.

세 가지가 동시에 굴러가야 합니다

정리하면 기업의 AI 과제는 "좋은 모델 고르기"가 아니라 "우리 조직에 맞는 하네스를 설계하고, 자산으로 남기고, 퍼뜨리기"로 다시 써야 합니다. 그리고 이건 도구 하나 사서 끝나는 일이 아닙니다.

무엇을 감쌀지 정하는 일. 하네스는 특정 업무를 감싸는 물건이라 감쌀 업무가 불분명하면 하네스도 만들어지지 않습니다. 애매한 자동화 도구 서른 개보다 실무자가 매일 부딪히는 병목 하나를 푸는 에이전트가 강한 이유가 여기 있습니다. 어떤 업무에 하네스를 씌울지, 그게 왜 돈이 되는지부터 정리되어야 합니다.

실제로 만드는 일. ERP·CRM·그룹웨어 연동, 커스텀 도구, SSO와 권한 체계, 지식 검색 구조, 자동 평가 체계, 그리고 ISMS나 금융권 망분리 같은 규제 요건까지. 앞에서 말한 "통제를 넣는 계층"이 전부 이 단계에서 구현됩니다.

조직에 퍼뜨리는 일. 가장 자주 생략되고 가장 자주 발목을 잡는 부분입니다. 하네스의 본질은 쓰는 사람이 직접 고쳐 쓸 수 있다는 데 있습니다. 실무진이 자기 업무용 에이전트를 스스로 만들 수 있게 되지 않으면 하네스는 계속 IT팀이나 외주사 소유로 남고요. 프로젝트가 끝나도 외부 의존이 안 끊기는 이유가 대개 이겁니다.

그리고 이 세 가지를 서로 다른 회사에서 따로 조달하면 하네스가 세 조각으로 쪼개집니다. 컨설팅사가 정의한 과제와 개발사가 만든 시스템과 교육사가 가르친 사용법이 서로 안 맞물리는 상황을 저희도 여러 번 봤습니다.

Dify를 사내 공용 하네스로 쓴다는 것

오픈네트웍시스템이 Dify를 기반 플랫폼으로 삼는 이유도 여기에 있습니다. 앞에서 정리한 하네스 네 요소가 Dify 구조와 그대로 맞물리거든요.

Dify는 앱이 어떻게 분기하고 도구를 호출하는지를 Workflow와 Chatflow로 그려 보여줍니다. 눈에 보이는 경로라 팀끼리 공유할 수 있고 에이전트가 승인된 도구만 호출하도록 경계를 두는 구조도 함께 옵니다. 마켓플레이스에서 모델 제공자와 도구, 데이터 소스, MCP 통합을 설치하거나 직접 정의해두면 승인된 플러그인을 모든 앱에서 재사용할 수 있고요. 배포한 뒤에는 로그와 피드백, 지연 시간, 사용량 데이터로 운영 상태를 들여다봅니다. Dify 엔터프라이즈는 여기에 SSO/SAML, RBAC, 감사 로그를 얹고 셀프 호스팅과 VPC 배포를 지원합니다. SOC 2 Type II와 ISO 27001 인증도 갖추고 있어서 망분리나 개인정보 이슈가 걸린 국내 기업 환경에도 붙일 수 있습니다.

개인용 하네스와의 차이는 딱 하나입니다. 그게 개인 노트북에 있느냐 회사 안에 있느냐죠.

한 사람이 만든 프롬프트와 도구를 다른 부서가 그대로 가져다 고쳐 쓰고, 실행 이력이 남고, 모델을 바꿔 끼워도 업무 자산은 그 자리에 남는 것. 재무팀이 만든 에이전트를 법무팀이 열어보는 순간부터 하네스는 개인 소지품에서 조직 자산으로 넘어갑니다.

ONS AX Foundry는 이 과정을 7단계로 나눠서 함께 갑니다. Discovery에서는 경영진과 현업을 인터뷰해 과제를 골라냅니다. Design에서 에이전트 아키텍처와 보안·거버넌스를 함께 설계하고 나면, PoC는 4주 안에 작동하는 프로토타입으로 판단 근거를 만드는 단계고요. 뒤이어 사내 시스템에 깊이 붙이는 Development, 파일럿 부서에 안착시키는 Deployment가 옵니다. 운영에 들어가서는 매월 성능을 점검하는 Operate, 그리고 전사 에이전트 맵과 Dify Playground 운영 체계까지 가는 Expand로 이어집니다. 컨설팅과 개발, 교육을 한 팀이 맡는 이유는 단순합니다. 하네스는 나눠서 만들면 안 맞거든요.

지금 우리 회사는 어느 쪽입니까

지금 사내 AI 도입이 어디쯤 와 있는지 가늠해보고 싶으시면, 제일 잘 쓰는 직원의 프롬프트가 문서로 남아 다른 부서로 넘어가고 있는지, 에이전트가 손댈 수 있는 사내 시스템이 목록으로 관리되고 있는지부터 보시면 됩니다. 어떤 도구를 언제 호출했는지 로그는 남는지, 사람 승인이 꼭 필요한 작업은 구조로 막아두었는지, 아니면 프롬프트로 부탁만 해두었는지, 데이터 민감도에 따라 쓰는 모델이 나뉘어 있는지, 답변 품질을 정기적으로 재는 체계가 실제로 돌아가고 있는지도 같이 짚어보아야 합니다.

그리고 마지막 두 가지. 모델 제공사를 갈아 끼워도 그동안 쌓은 업무 자산이 그대로 남는지, 외주사를 부르지 않고도 내부 인력이 에이전트를 고치고 새로 만들 수 있는지. 여기까지 오는 동안 "네(Yes)"가 몇 번 나오지 않았다면 조직의 하네스는 아직 없는 겁니다.

앞으로도 시장의 관심은 계속 모델로 쏠릴 겁니다. 이대로면 다음 세대 모델이 나올 때마다 회사는 또 한 번 흔들릴 거고요. 모델이 아무리 좋아져도 우리 회사의 결재 규칙과 데이터 구조, 권한 경계, 부서마다 다른 업무 용어를 알아서 챙겨주지는 않습니다. 그건 우리가 만들어 씌워야 하는 물건이고 그게 하네스입니다. 좋은 모델을 고르느라 쓴 시간은 반년 뒤면 사라집니다. 좋은 하네스를 만드느라 쓴 시간은 회사에 쌓이고요. 그래서 저희가 드리고 싶은 질문은 하나입니다.

지금 우리 회사의 하네스는 누구 노트북에 있습니까.

오픈네트웍시스템 ㅣ 권태규