AI Agents
WhatsApp Business Tools MCP가 보여준 ‘에이전트용 인터페이스’
발행일:
WhatsApp Business Tools MCP는 AI 에이전트가 기업용 소프트웨어의 설정과 운영 작업을 호출하는 흐름을 보여준다. Dashboard가 사라진다는 뜻은 아니다. 이제 제품은 사람이 조작하는 화면과 에이전트가 호출하는 인터페이스를 함께 설계해야 한다.
소프트웨어의 인터페이스라고 하면 지금까지는 화면을 떠올렸다. 메뉴를 열고, 설정 페이지를 찾고, 입력란을 채운 뒤 저장 버튼을 누르는 방식이다.
그런데 사용자가 사람이 아니라 AI 에이전트라면 이 화면은 최적의 인터페이스가 아니다. 에이전트는 메뉴의 위치를 눈으로 찾기보다, 수행할 수 있는 작업과 필요한 입력값이 구조화된 도구를 호출하는 편이 낫다.
WhatsApp Business Tools MCP는 이 변화를 실제 플랫폼에서 보여주는 사례다. 핵심은 WhatsApp에 AI 기능이 하나 추가됐다는 데 있지 않다. AI 에이전트가 기업용 소프트웨어의 새로운 호출 주체로 들어오기 시작했다는 데 있다.
다만 현재 기능은 베타이며 점진적으로 제공되고 있다. 모든 계정과 지역에서 즉시 사용할 수 있다고 단정해서는 안 된다.
공식 문서에서 확인할 수 있는 내용
Meta의 WhatsApp Business Tools MCP 문서는 AI 코딩 에이전트와 WhatsApp Business Platform을 연결하는 방법을 안내한다.
문서에서 안내하는 작업 범위에는 다음 항목이 포함된다.
- WhatsApp Business 계정 관련 작업
- 전화번호 추가와 인증
- Cloud API 사용을 위한 번호 등록
- 메시지 템플릿 생성과 수정
- 템플릿 상태 확인
- 테스트 메시지 전송
- 웹훅 설정과 테스트
- 이용약관, 결제 수단, 비즈니스 인증 상태 확인
인증에는 Meta 개발자 계정을 이용한 OAuth 방식이 사용된다. 동의 과정에서는 사용자가 선택한 비즈니스와 WhatsApp Business 자산에 접근하기 위한 관리 권한이 요청된다.
문서에서 확인할 수 없는 범위까지 확대해 해석해서는 안 된다. 지원 대상, 요금, 제한사항과 작업별 승인 방식은 실제 도입 시점의 공식 문서를 다시 확인해야 한다.
| 구분 | 문서에서 확인할 수 있는 내용 | 추가 확인이 필요한 내용 |
|---|---|---|
| 공개 상태 | 베타이며 점진적으로 제공됨 | 계정별 실제 이용 가능 여부 |
| 작업 범위 | 계정·전화번호·템플릿·웹훅·테스트 메시지 관련 작업 | 각 작업의 세부 조건과 제한 |
| 인증과 권한 | Meta 개발자 계정 OAuth와 비즈니스 관리 권한 사용 | 작업별 승인 흐름과 조직별 권한 설정 |
| 이용 조건 | 공식 문서에서 안내하는 범위 내에서 사용 | 지원 대상, 요금과 지역별 제공 범위 |
Dashboard에서 MCP로
기존 Dashboard의 기본 흐름은 사람이 화면을 탐색하는 방식이다.
사용자는 메뉴 이름을 읽고, 현재 상태를 해석하고, 적절한 버튼을 선택한다. 잘못된 값을 입력하면 경고 문구를 확인하고 다시 수정한다. 제품의 정보 구조와 사용성이 사람의 시선과 클릭을 중심으로 설계된다.
에이전트가 제품을 사용할 때는 흐름이 달라진다.
사용자가 “WhatsApp Business 계정을 만들고 이 번호를 Cloud API에 연결해줘”라고 요청하면, 에이전트는 자신에게 공개된 도구와 입력 형식을 확인한다. 이후 인증된 권한 안에서 필요한 작업을 호출하고, 반환된 상태를 바탕으로 다음 단계를 결정한다.
| 설계 요소 | 사람용 Dashboard | 에이전트용 MCP·API 인터페이스 |
|---|---|---|
| 작업 발견 | 메뉴와 화면을 탐색한다 | 도구 이름, 설명과 입력 구조를 확인한다 |
| 실행 방식 | 버튼을 누르고 폼을 제출한다 | 인증된 도구를 호출한다 |
| 권한 | 로그인 계정과 화면별 권한으로 통제한다 | 인증 범위와 자산별 권한으로 통제한다 |
| 상태 표시 | 배지, 알림과 화면 문구로 보여준다 | 구조화된 상태와 결과를 반환한다 |
| 오류 처리 | 사용자가 메시지를 읽고 다시 시도한다 | 에이전트가 오류 유형과 다음 행동을 해석한다 |
| 중요한 변경 | 확인 화면에서 사람이 승인한다 | 도구 호출 전후의 승인 경계를 설계한다 |
이 차이 때문에 에이전트용 인터페이스는 단순히 기존 API 문서를 AI에게 읽히는 것만으로 완성되지 않는다.
API는 시스템이 제공하는 기능 단위로 나뉘는 경우가 많다. 반면 에이전트는 사용자의 목적을 받아 여러 작업을 연결한다. 제품팀은 에이전트가 어떤 도구를 발견할 수 있는지, 각 도구가 무엇을 변경하는지, 실패했을 때 어떤 상태를 반환하는지까지 설계해야 한다.
MCP가 API를 없애는 것도 아니다. 기존 API가 실제 작업을 수행하는 실행 계층이라면, MCP는 AI 애플리케이션이 외부 시스템의 데이터와 도구를 발견하고 호출할 수 있도록 제공되는 인터페이스 계층에 가깝다.
따라서 변화의 본질은 ‘Dashboard가 MCP로 교체된다’가 아니다. 제품의 인터페이스가 사람용 화면에서 에이전트가 사용할 수 있는 도구까지 확장되는 것이다.

사람용 화면과 에이전트용 도구 호출은 대체 관계라기보다 서로 다른 인터페이스 계층으로 함께 설계될 수 있다.
Dashboard는 사라지지 않는다
에이전트가 반복적인 설정을 대신한다고 해서 Dashboard가 필요 없어지는 것은 아니다.
사람은 전체 상태를 한눈에 확인하고, 예외 상황을 비교하며, 중요한 변경을 승인해야 한다. 계정이 어떤 번호와 연결돼 있는지, 템플릿이 왜 거절됐는지, 예상하지 못한 작업이 실행됐는지를 조사할 때도 시각적인 관리 화면이 유용하다.
오히려 에이전트가 제품을 조작할수록 Dashboard의 역할은 달라질 가능성이 크다.
기존 Dashboard가 ‘사람이 모든 작업을 직접 처리하는 장소’였다면, 앞으로는 ‘에이전트가 수행한 작업을 확인하고 통제하는 장소’가 될 수 있다. 실행의 중심은 도구 호출로 이동하더라도 승인, 예외 처리, 기록 확인, 권한 관리에는 사람용 인터페이스가 계속 필요하다.
결국 제품팀이 준비해야 할 것은 둘 중 하나를 선택하는 일이 아니다.
- 사람은 상태를 이해하고 판단할 수 있어야 한다.
- 에이전트는 가능한 작업과 입력 조건을 이해할 수 있어야 한다.
- 위험한 변경에는 별도의 확인 경계가 필요하다.
- 실행 결과는 사람과 에이전트 모두 해석할 수 있어야 한다.
에이전트가 사용할 제품에는 무엇이 필요한가
WhatsApp Business Tools MCP의 기능 소개와 별개로, 에이전트용 인터페이스를 설계하는 제품팀은 몇 가지 질문을 먼저 정해야 한다.
명령의 단위
도구 이름과 설명만 보고도 에이전트가 작업의 목적을 구분할 수 있어야 한다. 하나의 도구가 너무 많은 상태를 변경하면 실패 원인을 찾기 어렵고, 지나치게 잘게 나뉘면 에이전트가 복잡한 호출 순서를 스스로 조합해야 한다.
중요한 것은 내부 API 구조를 그대로 노출하는 것이 아니라 실제 사용자가 요청하는 업무 단위와 도구의 경계를 맞추는 일이다.
인증과 권한 범위
사람이 로그인했다는 사실만으로 모든 자산에 대한 작업 권한을 주어서는 안 된다. 어느 조직과 계정에 접근할 수 있는지, 읽기와 변경 권한이 어떻게 구분되는지, 동의 과정에서 사용자가 무엇을 선택했는지가 명확해야 한다.
OAuth를 사용한다는 사실만으로 모든 운영 조건이 결정되는 것은 아니다. 실제 적용 전에는 권한 회수, 토큰 관리와 조직별 접근 범위를 별도로 검토해야 한다.
상태 확인
에이전트는 작업이 성공했는지만 알아서는 부족하다. 처리가 진행 중인지, 추가 인증이 필요한지, 승인을 기다리는지, 일부 단계만 완료됐는지를 구분할 수 있어야 한다.
사람에게는 화면의 배지와 안내 문구로 보여줄 수 있지만, 에이전트에는 다음 행동을 결정할 수 있는 구조화된 상태가 필요하다.

에이전트용 인터페이스는 도구 호출뿐 아니라 권한, 상태, 결과 해석까지 포함하는 흐름으로 설계해야 한다.
오류 처리
“작업에 실패했습니다”라는 메시지는 에이전트에게 충분한 정보가 아니다. 재시도할 수 있는 오류인지, 사용자가 직접 처리해야 하는 문제인지, 권한이 부족한지, 입력값이 잘못됐는지를 구분해야 한다.
에이전트가 실패 이유를 잘못 해석하면 같은 작업을 반복하거나 예상하지 못한 우회 경로를 선택할 수 있다.
승인 경계
조회, 초안 생성, 테스트와 실제 계정 변경은 위험도가 다르다. 어떤 작업까지 자동 실행할 수 있고 어떤 작업부터 사람의 확인이 필요한지 제품 차원에서 정해야 한다.
WhatsApp Business Tools MCP의 모든 작업에 동일한 승인 절차가 적용된다고 단정할 수는 없다. 실제 도입 전에는 사용 중인 클라이언트와 공식 문서에서 작업별 승인·인증 흐름을 확인해야 한다.
기록과 추적
에이전트가 어떤 요청을 받고 어떤 도구를 호출했는지 확인할 수 있어야 한다. 문제가 생겼을 때 대화 기록만 남고 실제 시스템 변경 과정이 보이지 않는다면 원인을 재구성하기 어렵다.
기록 제공 범위와 보존 방식 역시 실제 사용 환경과 공식 문서에서 별도로 확인해야 한다.

작업별 위험도에 따라 자동 실행과 사람의 확인 경계를 구분하는 개념도. 실제 제품의 승인 정책을 나타내는 자료는 아님.
제품팀이 지금 확인할 질문
에이전트용 인터페이스를 준비한다는 것은 기존 API 앞에 MCP 서버 하나를 세우는 것으로 끝나지 않는다. 제품팀은 다음 질문에 답할 수 있어야 한다.
- 우리 제품에서 에이전트가 맡아도 되는 반복 작업은 무엇인가.
- 조회와 실제 변경 작업을 어떻게 분리할 것인가.
- 도구는 내부 API 단위가 아니라 사용자 업무 단위로 정의돼 있는가.
- 에이전트가 현재 상태와 다음 행동을 판단할 수 있는 결과를 반환하는가.
- 중요한 변경 전에 사람의 확인을 어디에 둘 것인가.
- 호출 주체, 대상 자산, 실행 결과와 실패 원인을 추적할 수 있는가.
- 에이전트 연결을 해제하거나 권한을 회수하는 절차가 준비돼 있는가.
여기에 답하지 못한다면 MCP 연결 자체는 가능하더라도 운영 가능한 제품 인터페이스라고 보기는 어렵다.
새로운 사용자는 사람이 아닐 수도 있다
WhatsApp Business Tools MCP는 아직 베타이고 점진적으로 제공되는 기능이다. 공개된 문서의 범위를 넘어 실제 사용 환경을 단정하기에는 이르다.
그럼에도 제품 전략 측면에서 눈여겨볼 변화가 있다. AI 에이전트가 단순히 사용법을 설명하는 역할을 넘어, 인증된 권한으로 계정을 설정하고 운영 작업을 호출하는 주체가 되고 있다는 점이다.
앞으로 SaaS의 인터페이스는 사람이 이해할 수 있는 Dashboard와 에이전트가 발견하고 호출할 수 있는 도구를 함께 고려해야 한다.
Dashboard의 종말은 아니다. 인터페이스가 하나 더 생기는 것이다.
- #AI
- #MCP
- #SaaS
- #Product Strategy
- #WhatsApp Business
CONTINUE READING
이 기록에서 이어서 보기
VECTORLOG LETTER
다음 기록도 받아보고 싶다면 구독을 연결해 주세요.