웹사이트에 AI용 입구가 필요할까요? 먼저 이 표로 판단하세요

Larry

마케팅 일을 하던 미나는 자동화 직무로 옮기고 싶어요. 다룰 줄 아는 건 스프레드시트, 가능한 시간은 평일 저녁, 목표는 6주 안에 자동 보고서를 만드는 거예요. 과정 사이트의 AI 상담에 이 조건을 한꺼번에 설명하고 자신에게 맞는 수업과 8월에 자리가 있는 반을 물었어요.

여기서 AI가 맡을 일은 단순 잔여석 조회가 아니에요. 자연어 조건을 이해하고 여러 과정의 내용과 선수 지식을 비교해 추천 이유를 만드는 일이에요. 8월 시간표와 잔여석은 그 추천이 지금 가능한지 확인하는 동적 자료일 뿐이죠. 그래서 입구는 읽기·조회·행동을 전부 여는 대신, 공개 내용을 읽고 제한된 조회까지만 허용해도 돼요.

먼저 ‘AI가 온다’를 완료 조건으로 바꾸세요

“AI가 사이트를 쓴다”는 말로는 설계할 수 없어요. 미나의 경우 완료 조건은 ‘제약에 맞는 과정 하나, 그 이유, 신청 가능한 8월 저녁 반 하나’예요. 요청자, 입력, 확인 가능한 결과, 데이터 담당자, 오답의 영향을 적으면 기술 이름보다 먼저 경계가 보여요.

Model Context Protocol 공식 문서는 MCP를 AI 애플리케이션과 외부 데이터, 도구, workflow를 연결하는 표준이라고 설명해요. 연결 형식이지 공개 범위에 대한 답은 아니에요. Cloudflare 문서도 전체 API를 그대로 감싸지 말고 구체적인 목표를 위한 도구를 만들며 권한을 좁게 두라고 권해요.

같은 상담 안에서도 아래 분기는 서로 다른 책임이에요.

AI가 이 웹사이트에서 끝내야 하는 일은 무엇인가요?
공개 정보 읽기페이지 정체성, metadata, canonical, 내부 링크, RSS, sitemap, 상태 code를 맞춰요
바뀌는 값 조회범위를 제한한 읽기 전용 결과에 갱신 시점, 빈값, 오류, 한도를 붙여요
사람 대신 행동신원, 대상, 권한, 건별 승인, logs, 제한, 저장 상태, recovery부터 정해요

잔여석은 추천 뒤에 제한해서 조회해요

재고, 가격, 배송 상태, 수업 잔여석은 계속 바뀌어요. 화면 위치에서 값을 추측하면 디자인 개편이 데이터 규격 변경이 돼요. 반복 수요를 확인한 뒤에만 안정된 읽기 전용 endpoint, 제한된 export, 좁은 조회 tool을 검토하세요.

추천 과정이 정해진 다음에만 과정 코드, 8월 반, 평일 저녁 시간, 남은 자리, 갱신 시점을 읽기 전용으로 확인해요. ‘마감’, ‘미동기화’, ‘대상 없음’, ‘일시 장애’도 구분해야 해요. 이 도구는 추천을 만드는 게 아니라 지금 선택 가능한지 검증해요. 수강생 이름, 신청서, 결제 내역, 내부 메모, 정원 수정 권한은 필요 없어요.

동적 도구를 빼도 AI는 공개 내용으로 과정 추천과 이유를 제시하되 현재 잔여석은 모른다고 말할 수 있어야 해요. 반대로 AI를 평범한 SQL/API 조회로 바꿔도 같은 수준의 추천이 나온다면 AI가 필요 없는 사례예요. 두 반증을 통과한 뒤 알 수 없는 과정, 동기화 지연, 마감, timeout, 범위 밖 요청을 시험하세요.

행동은 실행 버튼보다 멈춘 뒤의 기록이 중요해요

신청, 환불, 설정 변경, 메시지 발송은 누군가의 권한으로 외부 상태를 바꿔요. account, 대상, parameter, 알림, 되돌리기 어려운 효과, 요청 식별자와 log를 남기고, 위험한 작업은 검토 가능한 preview로 시작해야 해요. 값이 달라지면 승인도 다시 받아야 해요.

OpenAI Agents SDK의 human-in-the-loop 문서는 민감한 tool call을 실행 전에 멈추고, tool과 argument를 보여 준 뒤 해당 호출을 승인하거나 거절하고, 저장된 RunState에서 이어 가는 흐름을 제시해요. MCP tool에도 같은 승인을 적용할 수 있어요. 막연한 ‘사람이 감독함’보다 무엇을 허용했고 어디서 재개하는지 읽을 수 있는 기록이 더 중요해요.

이 원칙은 AI 에이전트에게 코드를 맡기기 전에, 작업에 체크포인트를 넣으세요에서 다룬 경계와 같아요. 중간에 멈출 수 있는 흐름은 재시도 전에 이미 일어난 효과를 읽어야 해요. 정합성을 되돌릴 담당자와 보상 작업은 자동화가 중간에 실패하면, 누가 수습할까요?를 함께 써서 정할 수 있어요.

선택을 바꿀 조건을 마지막에 남기세요

미나가 추천 과정과 이유, 신청 가능한 8월 저녁 반을 받으면 처음 상담은 끝나요. 요청이 “그 반에 대신 신청해 주세요”로 바뀔 때만 행동 권한을 다시 검토해요. 그때도 신원 확인, 개인정보, 정확한 건별 승인, 결제, 중복 방지, 실패 수습에 담당자가 생기기 전에는 열지 않아요.

다른 사이트라면 canonical 하나를 고치거나, 제한된 dataset 하나를 조회하거나, 실행하지 않는 preview를 설계하거나, 지금 상태를 유지할 수 있어요. 오늘의 한 단계와 선택을 바꿀 조건을 함께 적어야 작은 정보 문제가 이유 없이 영구 플랫폼으로 커지지 않아요.

AI 정리 카드

허용된 website repository, 공개 과정 page, 반 편성 schema, 운영 기록만 읽고 수정, 신청 form 제출, 쓰기 endpoint 호출, 새 외부 service 연결은 하지 마세요. 다음 상담을 점검해요. “마케팅 경력이 있고 스프레드시트를 다뤄요. 평일 저녁에 배워 6주 안에 자동 보고서를 만들고 싶어요. 맞는 과정과 8월 빈 반을 추천해 주세요.” 먼저 배경, 능력, 시간, 결과 제약을 추출해요. 두 개 이상의 후보 과정에서 내용, 선수 지식, 기대 결과를 URL과 함께 비교하고 추천 이유를 만들어요. 공개 내용만으로 확인되는 판단과 읽기 전용 도구가 보충할 과정 코드, 8월 반, 요일, 잔여석, 갱신 시각, error 상태를 나눠요. AI를 평범한 SQL/API 조회로 바꿔도 같은 품질의 추천과 이유가 나오면 ‘AI 불필요’로 표시하고 멈추세요. 실시간 도구를 뺐는데 과정 비교까지 불가능해지면 읽기/조회 분리가 잘못된 거예요. 신청 권한을 빼도 처음 답변이 완성되는지 확인한 뒤 최소 입구 하나만 제안해요. 신원, 개인정보, 신청, 결제, 정원 수정은 허용하지 마세요. 요청이 “대신 신청해 주세요”로 바뀔 때만 건별 승인, 중복 방지, logs, recovery, 보상 절차, 사람 담당자를 정리하고 실행은 하지 마세요.

미나의 상담은 신청 전에 끝나요

미나가 이직 조건을 노트북 AI 과정 상담에 전하고, AI가 여러 과정을 비교한 뒤 8월 저녁 반을 읽기 전용으로 확인하며 신청서와 결제 단말기는 빨간 경계 밖에 두는 4컷 만화

미나는 마케팅 이력, 스프레드시트 경험, 저녁 달력, 6주 기한, 만들고 싶은 보고서를 하나의 질문으로 AI에 보여 줘요.
같은 노트북에서 AI가 여러 과정의 내용과 선수 조건을 제약과 맞춰 보고 한 과정을 이유와 함께 골라요.
이어서 8월 저녁 반과 잔여석만 단방향 읽기 전용으로 확인해요. 신청서, 개인정보, 카드 단말기는 빨간 선 밖에 있어요.
미나는 추천, 이유, 가능한 반을 받아 직접 선택해요. 실제 신청과 결제는 여전히 사람이 맡아요.

평범한 SQL이나 API 조회로 재현할 수 있는 건 세 번째 장면뿐이에요. 첫 두 장면의 자연어 이해, 과정 비교, 추천 이유는 사라져요. 반면 신청 도구가 없어도 네 번째 장면까지 완성돼요. AI가 필요한 판단과 동적 조회가 보충하는 사실, act를 다시 검토할 조건이 이렇게 분리돼야 해요.