이직을 준비하는 마케터 미나가 온라인 강좌 사이트의 AI 도우미에게 이렇게 묻는다고 해 보자. “스프레드시트밖에 다룰 줄 몰라요. 평일 저녁에 시간이 있고, 6주 안에 자동화 보고서를 만들 수 있게 되고 싶어요. 어떤 강좌가 맞을까요? 8월에 아직 신청할 수 있는 반이 있나요?”

이 질문에는 성격이 다른 세 가지 일이 숨어 있다. 강좌를 비교하고 어떤 강좌가 그녀의 배경에 맞는지 판단하려면 사이트에 공개된 강좌 소개를 읽기만 하면 된다. 8월에 아직 자리가 있는지 확인하려면 바뀌는 데이터를 조회해야 한다. 그녀 대신 신청하고 카드로 결제하는 것은 사람을 대신해 실행하는 일인데, 그녀는 애초에 그걸 요청하지 않았다.

요즘 AI가 “연결될” 수 있도록 API나 MCP를 만들어야 하느냐를 두고 고민하는 사이트가 많다. 답은 AI가 해야 할 일이 읽기, 조회, 실행 중 어디에 속하느냐에 달려 있다. 세 입구가 지는 책임은 크게 다르고, 대부분의 사이트가 먼저 고쳐야 할 것은 가장 눈에 띄지 않는 층, 즉 AI가 읽고 이해할 수 있는 공개 페이지다.

먼저 MCP가 무엇을 해결하는지 짚어 두자

MCP(Model Context Protocol)는 AI 애플리케이션을 외부 데이터, 도구, 워크플로에 연결하기 위한 개방형 표준이다. MCP가 답하는 것은 “어떻게 연결하느냐"이지, “무엇을 열어 둘 것인가"를 사이트 대신 정해 주지는 않는다.

MCP 개발 서비스를 제공하는 Cloudflare는 자사 문서에서 분명히 당부한다. MCP 서버를 API 전체를 감싸는 포장으로 다루지 말고, 사용자의 구체적인 목표에 맞춰 도구를 설계하라는 것이다. 잘 설계된 소수의 도구가 잘게 쪼갠 많은 도구보다 더 쓸모 있는 경우가 많고, 권한도 좁혀야 한다고 한다. 이 기술을 파는 쪽조차, 어떤 문을 열지 정하기 전에 AI가 무엇을 해내야 하는지부터 생각하라고 권하는 셈이다.

읽기, 조회, 실행은 단계별로 올라가는 경로가 아니다. 읽기 입구를 열었으니 다음엔 조회, 그다음엔 실행을 열어야 하는 것이 아니다. 셋은 서로 다른 책임에 대응한다. 읽기 입구가 잘못되면 AI는 틀린 소개를 한다. 조회 입구가 잘못되면 AI는 낡은 답을 준다. 실행 입구가 잘못되면 잘못된 신청이나 결제가 현실에 생긴다. 입구가 깊어질수록 사이트가 떠안는 결과도 무거워진다.

읽기: 대부분 사이트의 진짜 빈틈은 여기에 있다

미나가 원하는 첫 번째 답의 출처는 공개된 강좌 소개이고, 데이터베이스는 필요 없다. AI가 이유 있는 추천을 할 수 있는지는 그 페이지들이 서로 어긋나지 않는지에 달려 있다. 강좌 이름, 선수 지식, 학습 성과, 수업 시간대가 모든 페이지에서 같은 말을 하는가. 페이지 제목, 설명, 날짜, 언어 버전이 같은 내용을 가리키는가. 이미 종료된 강좌 페이지에 “모집 중"이 그대로 떠 있지는 않은가.

이런 문제에는 이미 쓸 수 있는 도구가 있다. Google 검색 센터에 따르면 사이트맵(사이트의 중요한 페이지와 갱신 시점을 나열한 파일)은 검색엔진이 페이지와 언어 버전을 찾도록 돕는다. rel="canonical"은 중복되거나 매우 비슷한 페이지들 가운데 어느 것이 원본인지 검색엔진에 알려 준다. 둘 다 새로운 기술이 아니고, AI를 위해 따로 개발할 필요도 없다.

강좌 페이지끼리 서로 모순된다면 MCP를 더해 봤자 AI가 그 모순을 더 빨리 읽을 뿐이다. 읽기 층에서 할 일은 먼저 내용을 고치는 것이다.

광고

조회: 질문 하나에 답하는 창만 연다

자리, 재고, 가격, 배송 상태는 바뀐다. 이런 숫자를 AI가 페이지 배치에서 짐작하게 하면 사이트를 개편하는 순간 망가진다. 안정적인 읽기 전용 조회를 마련할 가치가 생기는 건 이때다.

그 창은 좁게 연다. 미나의 경우 AI가 조회할 수 있으면 되는 것은 후보 강좌의 코드, 8월 반, 평일 저녁 시간대, 남은 자리, 데이터 갱신 시각, 그리고 “마감”, “동기화 전”, “해당 반 없음”, “일시적 장애” 같은 상태뿐이다. 수강생 명단, 결제 기록, 내부 메모, 정원을 바꾸는 기능은 이번 작업에 들어가지 않는다.

특히 중요한 것은 마지막 상태들이다. 조회에 실패했을 때 AI는 오래된 데이터를 답으로 내놓지 말고 “지금은 확인할 수 없다"고 말할 수 있어야 한다. 테스트할 때는 조회 도구를 일부러 빼 보면 된다. AI는 공개 내용만으로도 강좌를 추천할 수 있어야 하지만, 지금 자리가 있는지는 확인할 수 없다고 솔직하게 밝혀야 한다.

실행: 승인과 뒷수습 방법부터 준비한다

신청, 환불, 설정 변경, 알림 발송은 누군가의 권한을 써서 바깥 세계의 상태를 바꾼다. 이런 입구를 열기 전에 누구의 계정을 쓰는지, 누구에게 하는지, 매개변수는 무엇인지, 되돌릴 수 있는지, 상대에게 알림이 가는지, 잘못되면 어떻게 바로잡는지를 분명히 해 둬야 한다.

AI agent를 만드는 개발 도구 모음인 OpenAI의 Agents SDK는 “사람이 개입하는” 승인 방식을 구체적으로 보여 준다. 민감한 도구를 실행하기 전에 멈추고, 도구 이름과 인자를 사람에게 보여 주고, 그 한 번의 호출에 대해 승인하거나 거절하게 한 뒤, 저장해 둔 상태에서 다시 이어 간다. 핵심은 “그 한 번"이다. 막연한 “동의” 하나만 남겨 두면 나중에 어떤 대상과 어떤 매개변수를 승인했는지 알 수 없다.

처리가 중간에 실패할 수 있다면 이미 일어난 결과, 안전하게 다시 시도할 수 있는지, 누가 뒷수습을 맡는지도 먼저 기록해 둔다. 자동화가 중간에 멈췄다면, 다시 돌리기 전에 이미 무슨 일이 있었는지부터 확인한다를 참고할 수 있다. 이 가운데 하나라도 빠져 있다면 실행 입구는 아직 열 때가 아니다.

실제 작업 하나에서 판단을 시작한다

“우리도 MCP를 만들어야 할까"라는 회의를 열기보다, 실제 작업 하나를 골라 완료 조건을 적고 이렇게 물어보는 편이 낫다. 이 일 가운데 어느 부분은 읽기만 하면 되고, 어느 부분은 조회가 필요하고, 어느 부분은 실행이 필요한가.

미나의 작업은 추천 이유와 신청할 수 있는 8월 저녁반 하나를 얻는 순간 끝난다. “실행"을 빼도 그녀의 답에서 빠지는 것이 없다. 이 작업에 필요한 가장 얕은 입구가 읽기와 좁은 조회 창이라는 증거다. 그녀가 이어서 “이 반에 신청해 줘"라고 하고, 본인 확인, 개인 정보, 호출마다의 확인, 결제, 중복 신청 방지, 실패 시 복구를 모두 맡을 사람이 있을 때에야 실행 입구를 다시 검토할 가치가 생긴다.

대부분의 사이트에게 다음 단계는 새 인터페이스 개발이 아닌 경우가 많다. AI가 가장 자주 질문받는 페이지 몇 개를 골라 그 페이지들이 같은 말을 하는지 확인하는 일이다. AI가 팀을 위해 코드도 고친다면 같은 층위의 판단을 적용할 수 있다. 이 issue를 coding agent에 맡길 수 있는지는 첫 번째 diff를 적을 수 있느냐에 달렸다를 참고하자.

AI 정리 카드

사이트 작업에 어느 층의 입구가 필요한지 AI와 함께 판단하기 이 프롬프트는 실제 작업 하나를 설명하게 한 뒤, 그것을 읽기, 조회, 실행으로 나누고, 작업에 필요한 가장 얕은 입구만 제안한다.

내 웹사이트에 AI를 위한 새 입구(API나 MCP 등)를 열어야 하는지 판단하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/agentic-web-needs-machine-readable-doors/
글의 관점은 이렇다. 실제 작업 하나를 "공개 내용 읽기", "바뀌는 데이터 조회", "사람 대신 실행"으로 나누고, 작업에 필요한 가장 얕은 층만 연다. 대부분의 사이트가 먼저 고칠 것은 AI가 읽을 수 있는 공개 페이지다.

먼저 나에게 질문 3개를 해 달라:
1. 사용자가 AI에게 내 사이트에서 해 달라고 할 실제 작업은 무엇이고, 무엇을 완료로 보는가;
2. 그 작업에 답하려면 어떤 데이터가 필요한가. 공개 페이지에 이미 있는 것과 수시로 바뀌는 것은 무엇인가;
3. 그 작업은 누군가의 계정으로 신청, 결제, 변경, 발송을 하는가.

내 답을 바탕으로 다음을 출력해 달라:
- 작업을 읽기, 조회, 실행으로 나누고 각각 필요한 데이터나 동작;
- 읽기 부분: 먼저 고쳐야 할 공개 페이지의 불일치 후보;
- 조회 부분: 이 작업에만 답하는 읽기 전용 조회에 필요한 항목과 오류 상태;
- 한 줄 결론: 이 작업에 필요한 가장 얕은 입구는 어느 층인가;
- 실행 입구가 필요하다면: 미리 준비해야 할 승인, 기록, 복구 방법. 단, 구현 설계까지 하지는 말 것.
내가 말하지 않은 데이터나 기능이 사이트에 있다고 가정하지 말 것.

제안은 출발점일 뿐이다. 어느 층의 입구를 열지는 그 데이터와 결과를 책임지는 사람이 정한다.

광고

Share

이 미니 클래스 공유

이 글이 업무 병목을 푸는 데 도움이 되었다면, AI를 어떻게 쓸지 고민하는 사람에게도 공유해 주세요.

참고 자료