AX LABS
← 블로그 AX 전략

업무 기능은 등록돼야 한다

AI 시대의 조직도는 부서가 아니라 호출 가능한 기능이다

AX LABS 6분 읽기

현장에서 AI agent를 붙이면 가장 먼저 막히는 지점은 모델 성능이 아니다. “이 업무는 어느 부서가 해요?”라는 질문이다. 사람에게는 부서명과 매뉴얼이 충분했다. agent에게는 부족하다. agent는 부서를 이해하지 않는다. 호출할 기능, 입력값, 권한, 실패 시 책임자를 알아야 일한다.

최근 agent 플랫폼도 같은 방향으로 움직인다. OpenAI는 2026년 Responses API 글에서 agent loop가 도구 호출과 결과 반영을 반복한다고 설명했고, skill을 versioned bundle로 저장·불러오는 구조를 공개했다(https://openai.com/index/equip-responses-api-computer-environment/). MCP Registry는 공개 MCP server의 중앙 metadata repository를 표방한다(https://modelcontextprotocol.io/registry/about). 시장의 방향은 명확하다. 조직 내부의 업무도 registry가 필요하다.

매뉴얼은 사람이 읽고, registry는 agent가 호출한다

부서 매뉴얼은 설명 문서다. 책임 회피에는 유용하지만 실행 단위로는 거칠다. “구매 요청 처리”라는 문장은 agent에게 충분한 instruction이 아니다. agent는 어떤 조건에서 호출 가능한지, 어떤 입력 schema를 받는지, 어느 시스템에 접근하는지, 실패하면 누구에게 넘길지 알아야 한다.

AI-Native capability registry는 업무를 문서가 아니라 운영 자산으로 등록한다. 최소 단위는 부서가 아니라 capability다.

구분 부서 매뉴얼 Capability registry
기본 단위 팀, 역할, 절차 agent-callable capability
실행 조건 사람이 해석 호출 조건과 입력 schema
책임 조직장 중심 owner와 backup owner
품질 관리 사후 민원 eval 기준과 갱신 주기
권한 시스템 권한 중심 capability별 scope

이 차이가 운영을 가른다. 매뉴얼 기반 조직은 agent가 업무를 시작할 때마다 해석 회의를 연다. registry 기반 조직은 agent가 호출 가능한 기능 목록에서 일을 시작한다.

AI agent 운영의 핵심 자산은 prompt가 아니라 호출 가능한 업무 기능의 목록이다.

Capability에는 owner와 eval SLA가 붙어야 한다

Capability registry는 IT 자산 목록이 아니다. 조직 운영 계약이다. 한 capability에는 네 가지가 반드시 붙는다.

  • capability 정의: 무엇을 입력받아 어떤 결과를 반환하는가
  • owner: 품질과 변경 승인 책임자는 누구인가
  • eval SLA: 언제, 어떤 기준으로 재평가하는가
  • 권한 범위: 어떤 데이터와 시스템까지 접근 가능한가

여기서 eval SLA는 “정확도 몇 퍼센트” 같은 장식 문구가 아니다. 업무가 바뀌었을 때 언제 eval을 다시 돌릴지, 실패 케이스가 쌓이면 누가 기준을 고칠지, model·tool·policy 변경 시 어떤 회귀 테스트를 통과해야 배포할지 정하는 약속이다. OpenAI의 Evals 문서는 model output을 기대 기준에 맞춰 테스트하고 개선하는 절차를 API와 dashboard로 다룬다(https://platform.openai.com/docs/guides/evals?api-mode=responses). 기업 내부 registry도 이 원리를 업무 기능 단위로 가져와야 한다.

owner가 빠진 capability는 곧 orphan tool이 된다. 처음에는 잘 작동한다. 하지만 양식이 바뀌고, 승인선이 바뀌고, 예외 규정이 생기면 agent는 낡은 기능을 계속 호출한다. 운영 사고는 보통 큰 전략 실패가 아니라 이런 작은 방치에서 나온다.

권한은 계정이 아니라 capability별로 잘라야 한다

agent에게 사람 계정을 빌려주는 방식은 오래가지 않는다. 사람의 권한은 넓고 맥락적이다. agent의 권한은 좁고 명시적이어야 한다. “이 agent는 구매 시스템 접근 가능”이 아니라 “이 capability는 승인 전 견적 조회만 가능”이어야 한다.

MCP authorization specification은 HTTP 기반 MCP client가 restricted server에 접근할 때 authorization header를 사용하는 구조를 정의한다(https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization). 표준의 세부 구현을 그대로 가져오라는 뜻이 아니다. 중요한 것은 방향이다. agent 시대의 권한은 연결 단위가 아니라 호출 단위로 관리된다.

Capability registry에는 권한 범위를 함께 적어야 한다. 읽기, 쓰기, 제출, 승인, 외부 발송을 분리한다. 특히 승인과 외부 발송은 human-in-the-loop를 기본값으로 둔다. agent가 초안을 만들고, 검증하고, 라우팅하는 것과 조직을 대신해 확정 행위를 하는 것은 다른 문제다.

먼저 핵심 업무의 호출 지도를 만든다

경영진이 할 일은 agent를 많이 도입하라는 지시가 아니다. 먼저 회사의 핵심 업무를 capability 단위로 쪼개고, 호출 가능한 지도부터 만들게 해야 한다. 이것이 없으면 각 부서는 자기 방식으로 prompt와 자동화를 만들고, 회사는 같은 기능을 여러 번 만든다.

첫 번째 registry는 거창할 필요가 없다. 반복 호출되는 업무, 예외가 잦은 업무, 승인과 조회가 섞인 업무부터 등록한다. 그리고 각 capability에 owner, eval SLA, 권한 범위를 붙인다. 이 네 가지가 없는 기능은 운영 투입 대상에서 제외한다.

AX Ops에서는 이 작업을 전략 문서가 아니라 운영 설계로 다룬다. 업무 기능을 등록하고, agent 호출 흐름을 설계하고, eval과 권한 체계를 같은 테이블에서 맞춘다. AI 도입은 모델 선택으로 시작해도 운영 정착은 capability registry에서 갈린다. 지금 필요한 것은 더 많은 agent가 아니라, agent가 안전하게 호출할 수 있는 조직의 기능 목록이다. AX LABS의 접근은 사업 영역 →에서 이어진다.

참고