AX LABS
← 블로그 AX 전략

제품 기능은 버튼이 아니라 계약이다

agent가 호출할 수 없으면 기능은 잠긴다

AX LABS 6분 읽기

제품팀 회의에서 아직도 “이 기능은 어느 화면에 버튼을 둘 것인가”로 논의가 시작된다. 자연스러운 질문처럼 보이지만, AI-Native 제품에서는 출발점이 틀렸다. 이제 기능의 1차 표면은 버튼이 아니다. agent가 이해하고 호출하고 검증할 수 있는 action contract다.

OpenAI는 2026년 4월 Agents SDK 업데이트에서 agent가 파일, 도구, 컴퓨터 환경을 다루는 harness를 강조했고, MCP, skills, shell, apply patch 같은 실행 프리미티브를 agent loop 안에 넣었다. Anthropic도 2025년 10월 Agent Skills를 “instructions, scripts, resources”를 담은 폴더형 능력 단위로 설명했다. 제품 기능이 화면 뒤에 숨어 있으면 이런 실행 계층과 접속하지 못한다. (openai.com)

제품 표면의 기준이 UI에서 계약으로 이동한다

UI는 사람이 기능을 발견하고 조작하는 표면이다. action contract는 agent가 기능을 발견하고 실행하는 표면이다. 둘은 경쟁하지 않는다. UI는 contract 위에 올라가는 human client다.

계약은 단순한 API 문서가 아니다. 호출 의도, 입력 스키마, 권한, 사전 조건, 실패 코드, 감사 로그, 되돌리기 조건까지 포함한 실행 약속이다. agent는 버튼을 보지 않는다. 기능의 이름, 설명, 파라미터, 제약, 결과 형식을 본다.

AI-Native 제품에서 기능은 “화면에 보이면 존재한다”가 아니라 “agent가 안전하게 호출하면 존재한다”로 정의된다.

MCP 2025-11-25 specification은 tool을 LLM이 action을 취하도록 노출되는 함수로 다룬다. A2A도 2025년 6월 Linux Foundation 프로젝트로 넘어가며 agent 간 안전한 통신과 협업을 표방했다. 이 흐름의 공통점은 명확하다. 제품 기능은 더 이상 단일 앱의 화면 안에서만 소비되지 않는다. (modelcontextprotocol.io)

버튼 중심 설계는 agent 시대의 부채가 된다

버튼 중심 제품은 기능을 사람의 클릭 경로에 묶는다. agent가 그 기능을 쓰려면 화면을 흉내 내거나, RPA처럼 취약한 조작을 하거나, 별도 API를 뒤늦게 붙여야 한다. 이때 제품 구조와 agent 구조가 갈라진다.

설계 관점 버튼 중심 제품 contract 중심 제품
기능 정의 화면 요소와 플로우 호출 가능한 action
권한 메뉴 접근권한 action별 scope와 정책
실패 처리 팝업과 안내문 machine-readable error
감사 사용자 조작 로그 agent 호출·입력·결과 로그
확장 화면 추가 contract 재사용

경영진이 봐야 할 지점은 개발 효율이 아니다. 기능 자산의 유통성이다. 같은 승인, 조회, 생성, 변경 기능이 사내 포털, 모바일 앱, Copilot형 assistant, 외부 agent workflow에서 각각 따로 구현되면 제품은 커질수록 느려진다. contract는 기능을 한 번 정의하고 여러 표면에서 소비하게 만든다.

action contract는 제품 전략의 최소 단위다

AI-Native product surface를 설계할 때 첫 산출물은 화면 목록이 아니다. action catalog다. 어떤 기능을 agent에게 열 것인지, 어떤 기능은 사람 확인을 거칠 것인지, 어떤 기능은 절대 자동 실행하지 않을 것인지를 먼저 정한다.

좋은 action contract에는 다섯 가지가 들어간다.

  1. Intent: agent가 언제 이 action을 선택해야 하는가.
  2. Schema: 입력과 출력이 검증 가능한 구조인가.
  3. Policy: 누가, 어떤 조건에서, 어느 범위까지 실행하는가.
  4. Recovery: 실패·중복·취소·되돌리기를 어떻게 처리하는가.
  5. Trace: 호출 이유, 입력, 결과, 승인 이력을 남기는가.

OpenAI의 2026년 Responses API 설명은 orchestration, shell tool, hosted container, skills, compaction을 조합해 end-to-end workflow를 만든다고 설명한다. 이것은 제품 기능이 agent 실행 환경에서 재조합된다는 뜻이다. 기능이 contract로 정리되어 있지 않으면 재조합은 통제가 아니라 우회가 된다. (openai.com)

지금 할 일은 화면 개편이 아니라 기능 재분류다

제품 조직은 기존 기능을 세 묶음으로 나눠야 한다. 첫째, 즉시 agent-callable action으로 열 기능. 둘째, human-in-the-loop 승인 후 실행할 기능. 셋째, 정책상 agent에게 노출하지 않을 기능.

이 분류가 끝나면 UI 기획, API 설계, 권한 설계, 로그 설계가 같은 테이블에 올라온다. 여기서부터 AI 도입은 챗봇 프로젝트가 아니라 제품 운영 모델의 재설계가 된다.

AX Ops에서는 이 작업을 product surface inventory로 시작한다. 화면을 세는 것이 아니라 action을 센다. 기능명을 정리하는 것이 아니라 실행 계약을 정리한다. 그래야 agent가 제품을 “대화”로 쓰는 것이 아니라 “운영 가능한 방식”으로 쓴다.

참고

제품을 AI-Native로 바꾸는 첫 단계는 새 화면이 아니라 호출 가능한 계약을 세우는 일이다. AX Ops 방법론 →