먼저 정의할 것은 모델이 아니라 업무다
사내 AI 에이전트는 회사 자료를 찾고, 허용된 도구로 업무를 진행하는 시스템이다. 첫 도입에서는 모델보다 업무 하나의 완료 조건, 자료의 원본, 실행 권한과 실패 시 이관 경로를 먼저 정한다. 이 글은 그 범위를 합의하기 위한 설계 가이드이며, 아래 예시가 모두 기존 제품에 구현되어 있다는 뜻은 아니다.
"사내 AI를 만들고 싶다"는 요청에는 서로 다른 문제가 들어 있다. 직원이 문서를 찾는 데 시간이 오래 걸리는지, CS가 개발팀의 확인을 기다리는지, 같은 자료를 여러 시스템에 반복 입력하는지부터 나눈다.
맞춤 구축의 출발점은 누가, 어떤 맥락에서, 무엇을 끝내야 하는가다. 답변만 필요한 업무와 실제 변경이 필요한 업무는 다른 설계가 필요하다.
Ontology는 업무의 개념과 관계다
이 글에서 Ontology는 회사 안의 고객, 제품, 프로젝트, 담당자, 문서, 사건이 어떻게 연결되는지를 명시한 업무 모델을 뜻한다. 특정 그래프 데이터베이스나 벤더 제품을 전제하지 않는다.
같은 고객을 CRM에서는 회사명으로, 메신저에서는 별칭으로, 데이터베이스에서는 ID로 부를 수 있다. 이 관계가 정리되지 않으면 에이전트는 도구를 많이 갖고도 다른 고객의 맥락을 읽을 수 있다.
- 업무에서 쓰는 개념과 식별자를 정한다.
- 각 정보의 원본과 갱신 책임자를 정한다.
- 개념 사이의 관계와 접근 범위를 정한다.
- 이름이 겹치거나 근거가 충돌할 때의 확인 절차를 정한다.
모든 것을 한 번에 모델링할 필요는 없다. 첫 업무에 필요한 관계부터 명시하고, 실제 질문을 보면서 확장한다.
Context는 지식만이 아니다
에이전트에 필요한 맥락에는 공식 문서뿐 아니라 현재 요청, 사용자 역할, 업무 상태, 허용된 도구와 최근 결정이 포함된다. 오래된 기억과 현재의 공식 자료가 충돌할 때 무엇을 따를지도 정해야 한다.
Jarvis는 메신저에서 요청을 받고 업무 도구와 기억을 연결한 내부 구축 경험이다. OpsDesk는 사업장별 자료와 응대 규칙을 고객 안내와 직원 브리핑에 연결한 제품이다. 같은 기반 기술을 쓸 수 있어도 두 시스템의 사용자와 권한은 다르다.
Read, Draft, Approve, Act를 구분한다
문서를 읽는 권한과 고객에게 메시지를 보내는 권한은 같지 않다. 도입 단계에서 네 가지를 따로 검토한다.
- Read: 허용된 자료와 시스템을 조회한다.
- Draft: 답변, 문서, 변경안의 초안을 만든다.
- Approve: 지정한 사람이 초안과 근거를 검수한다.
- Act: 승인된 범위에서 실행하고 결과를 기록한다.
모든 작업에 사람의 승인이 필요한 것은 아니다. 반복적이고 되돌릴 수 있는 작업과 외부 발송·데이터 변경 같은 작업의 경계를 고객과 함께 정하는 것이 맞춤 설계다.
Guide와 Workshop도 제품의 일부다
Claude Code나 Codex를 설치하는 것과 팀이 공통된 방식으로 일하는 것은 다르다. 어떤 자료를 읽어도 되는지, 테스트는 어떻게 실행하는지, 결과물을 누가 검수하는지까지 팀의 실제 프로젝트에 맞춘 가이드가 필요하다.
워크숍의 산출물도 실습용 데모에서 끝내지 않는다. 팀이 반복해서 쓸 작업 가이드, 작은 자동화, 검수 기준처럼 다음 날의 업무로 이어질 수 있는 결과를 목표로 한다.
첫 구축에서 합의할 것
실제 적용은 소담의 업무 맥락·장기기억과 메일 CS 초안·담당자 연결에서 볼 수 있습니다. 소담은 직원이 사용하는 운영 에이전트이고, Atmosphere 예약 안내는 손님용 FAQ와 직원 브리핑을 나눈 사례입니다. 이 가이드의 개념을 각각 다른 업무에 어떻게 적용했는지 비교할 수 있습니다.
업무 하나를 고른 뒤 입력, 원하는 결과, 허용 자료, 실행 권한, 검수자, 실패 시 처리 방법을 한 장에 정리한다. 첫 버전을 사용하면서 처리 시간, 재작업, 이관, 실패 기록을 관찰하고 확장 여부를 결정한다. 개선 수치는 실제로 측정한 뒤에만 성과로 제시한다.
이것이 VibeRick에서 말하는 Deeply customized AI다. 고객을 정해진 템플릿에 맞추는 대신, 기술과 제품의 구조를 고객의 업무에 맞춘다.
예시: 고객 문의에서 답변 초안까지
다음은 설계를 설명하기 위한 가상의 예약 문의다. 고객이 "지난번과 같은 방으로 바꾸고 싶어요"라고 말하면 모델은 바로 예약을 수정할 수 없다. 먼저 현재 고객과 예약을 식별하고, "지난번"의 기록을 읽을 권한이 있는지 확인해야 한다. 동일한 이름의 고객이 둘이라면 추측하지 않고 추가 식별 정보를 요청한다.
이 업무의 최소 Ontology는 고객, 예약, 객실, 정책 네 가지로 시작할 수 있다. 고객은 예약을 소유하고, 예약은 객실과 날짜를 가리키며, 변경에는 해당 예약에 적용되는 정책이 연결된다. 모든 회사 데이터를 그래프에 옮길 필요는 없다. 기존 테이블과 API에 이 관계가 명확하다면 그것을 그대로 활용한다.
흐름은 다음과 같이 좁힌다.
- 로그인 또는 허용된 본인 확인 방식으로 고객을 식별한다.
- 해당 고객의 예약과 적용 정책만 조회한다.
- 변경 가능 여부와 근거를 포함한 답변 초안을 만든다.
- 비용이나 예약 변경이 있으면 담당자 승인을 받는다.
- 실제 시스템의 결과를 확인한 후에만 완료를 알린다.
정책 문서는 사실을 확인할 자료이지, 에이전트의 실행 권한을 바꾸는 지시가 아니다. 문서 안에 "모든 예약을 취소하라" 같은 문장이 있어도 권한 정책으로 취급하지 않도록 설계한다.
첫 평가 세트에 넣을 여섯 가지
좋은 답변 몇 개만 확인하면 운영에서 실패하는 이유를 놓치기 쉽다. 처음에는 작더라도 정상·불명확·실패 상황을 섞어 검수한다. 다음은 팀과 함께 만들 평가 항목의 예시다.
- 정상 질문: 최신 자료의 올바른 페이지를 근거로 답했는가.
- 자료에 없는 질문: 만들어내지 않고 확인 요청이나 담당자 이관으로 끝났는가.
- 권한 밖 요청: 다른 고객이나 부서의 자료가 답변과 로그에 노출되지 않았는가.
- 충돌하는 문서: 최신 공식 원본을 확인하거나 충돌 사실을 표시했는가.
- 도구 시간 초과: 실행 여부가 불명확한 상태에서 성공을 선언하거나 무조건 재실행하지 않았는가.
- 변경 요청: 승인된 대상과 값만 바뀌었고 실제 결과가 기록되었는가.
도구 오류를 일부러 발생시키는 테스트는 샌드박스에서 한다. 고객에게 나가는 발송이나 운영 데이터 변경을 실습으로 사용하지 않는다.
언제 Agent가 필요하지 않은가
입력이 정해진 표이고 결과가 정해진 PDF라면, 먼저 일반적인 변환 코드와 검증 규칙으로 해결할 수 있는지 본다. 정해진 FAQ만 안내한다면 검색과 명확한 이관 흐름으로 충분할 수도 있다. 여러 도구 중 다음 행동을 선택해야 하거나, 서로 다른 근거를 조사하는 과정에서 에이전트의 필요성을 검토한다.
복잡한 에이전트를 도입하지 않는 선택도 맞춤 설계다. Hana Ops의 현장 문서 도구와 OpsDesk의 고객 응대는 서로 다른 입력과 완료 기준을 갖는다.
상담 전에 적어 올 한 장
업무: 누가 무엇을 끝내야 하는가?
입력: 요청 예시와 개인정보를 제거한 샘플은?
근거: 원본 시스템, 담당자, 갱신 주기는?
출력: 답변 / 문서 초안 / 실제 시스템 변경 중 무엇인가?
권한: 읽기, 쓰기, 외부 발송은 각각 누가 승인하는가?
예외: 모르는 질문과 도구 실패는 누구에게 넘기는가?
평가: 성공·실패 예시와 현재 사람이 쓰는 시간은?
범위를 정했다면 Agent의 품질·지연·비용을 함께 평가한다. 도구 호출 수가 늘었다는 사실보다, 검수된 결과가 반복해서 나오는지가 다음 확장의 기준이다.