Harness (하네스)

모델 주변에서 무엇을 관리하는가

모델은 입력을 해석하고 다음 응답이나 행동을 생성합니다. 그러나 실제 작업에는 파일·도구·권한·실행 결과·중단 처리가 함께 필요합니다. 이런 요소를 연결하는 주변 구조를 하네스라고 부릅니다. 제품과 문맥에 따라 범위는 다를 수 있습니다.

하네스가 항상 모델이 접근할 수 없는 저장소를 갖는 것은 아닙니다. 신뢰 경계가 필요한 조건은 별도 권한과 실행 경로로 설계해야 합니다.

모델·Skill·온톨로지의 역할

BOAZ가 회사 위키를 실제로 운영하며 정리한 질문은 ‘모델과 하네스가 좋아져도 회사가 계속 정하고 고칠 것은 무엇인가’였습니다.

이는 역할을 구분하기 위한 설명입니다. 한 제품의 폴더가 반드시 이 표대로 나뉘어야 한다는 뜻은 아닙니다. 중요한 것은 회사의 기준이 바뀌었을 때 어디를 수정해야 하는지 아는 것입니다.

위키 운영에서는 어떻게 나타나는가

AI가 새 원문을 읽어 수정안을 작성하면, 코드는 링크 대상과 인용 위치, 변경 버전을 검사합니다. 사람은 사실·표기·해석·적용 범위를 판단합니다. 반영 단계에서는 판단한 버전과 실제 적용할 버전이 같은지 확인합니다.

이 과정에서 코드는 ‘출처 파일이 있다’를 확인할 수 있지만 ‘그 문장이 주장을 뒷받침한다’를 자동으로 보장하지는 않습니다. 하네스의 검사를 통과한 범위와 아직 의미 검토가 필요한 범위를 구분해야 합니다.

워크플로의 순서와 에이전트의 선택을 연결한다

하네스는 정해진 처리 순서를 실행하거나 모델이 다음 도구를 선택하는 구조를 지원할 수 있습니다. 두 방식을 한 업무에 섞는 것도 가능합니다. 가상 문서 검토에서는 필수 항목 검사를 코드로 고정하고, 모호한 표현의 근거 탐색은 모델이 선택하게 할 수 있습니다.

어느 방식이든 단계 사이에 넘길 상태와 완료 조건이 필요합니다. 실패한 작업을 다시 시도할 때 무엇이 이미 반영됐는지 모르면 중복 저장이나 반복 실행이 생길 수 있습니다. 재시도 횟수만 정하기보다 다시 실행해도 되는 범위와 사람에게 넘길 조건을 정합니다.

AI 에이전트의 동적 선택은 이런 실행 구조 안에서 다뤄집니다. 모델이 계획을 설명했다는 것과 실제 도구가 그 순서와 권한으로 실행됐다는 것은 별도로 확인합니다.

기준의 저장과 강제는 다르다

프롬프트에 ‘검증하라’고 적는 것도 유용한 지침입니다. 다만 지침을 제공하는 것과, 검증 실패 시 배포나 반영을 막는 것은 다른 수준의 장치입니다.

예를 들어 검증 스크립트를 만들었어도 실행하지 않고 완료할 수 있다면 강제된 경로가 아닙니다. 검사 자체가 잘못됐거나 우회할 수 있다면 통과 기록의 의미도 약해집니다. 가드레일은 이 실행 경계를 다룹니다.

작은 업무에서 시작한다

업무 하나의 입력·출력·완료 조건을 정하고 실제로 실행해 봅니다. 반복되는 실패가 나오면 자료 부족인지, Skill의 절차 문제인지, 도구 오류인지, 사람의 기준이 모호한지 나눠봅니다. 모델을 바꾸는 것과 주변 구조를 고치는 것은 둘 다 가능한 선택입니다.

검증 Loop에는 최대 반복 횟수뿐 아니라 근거 부족·반복 실패·시간과 비용 한도에서 멈추는 조건도 둡니다. 검사를 많이 만드는 것보다 어떤 실패를 잡는지 확인하는 편이 중요합니다.