AI가 탑재된 브라우저가 MCP를 통해 웹사이트와 직접 소통하면서, 우리의 웹 경험이 클릭과 스크롤에서 자연어 대화로 바뀌고 있습니다. 이 변화가 개발자에게 왜 중요하고 어떻게 준비해야 하는지 살펴보겠습니다.
AI 브라우저 시대의 시작
OpenAI와 Perplexity의 브라우저 전략
OpenAI가 자체 브라우저 출시를 준비하고 있다는 소식과 함께, Perplexity가 월 200달러짜리 Comet 브라우저를 선보였습니다. 이들의 목표는 기존 브라우저를 없애는 것이 아닙니다. 오히려 브라우저를 더 똑똑하게 만드는 것입니다.
핵심은 사용자가 여전히 브라우저를 사용하되, 브라우저 내 AI가 대신 복잡한 작업을 처리한다는 점입니다. “항공편 예약해줘”라고 말하면, AI가 여러 사이트를 비교하고 최적의 옵션을 찾아 예약까지 완료합니다.
기존 브라우저의 한계
문제는 기존 웹사이트들이 사람의 클릭을 전제로 설계되어 있다는 점입니다. AI가 웹사이트를 자동화하려면 HTML을 파싱하고, 버튼을 찾고, 폼을 채우는 복잡한 과정을 거쳐야 합니다.
웹사이트 디자인이 조금만 바뀌어도 AI의 자동화 스크립트가 깨집니다. 요소 선택자가 달라지거나 새로운 팝업이 나타나면 AI는 혼란에 빠집니다.
이런 한계 때문에 MCP가 핵심 해결책으로 떠오르고 있습니다.
MCP가 게임을 바꾸는 이유
브라우저 자동화에서 직접 통신으로
MCP(Model Context Protocol)는 AI 브라우저가 웹사이트의 HTML을 분석하는 대신, 구조화된 인터페이스로 직접 소통할 수 있게 해줍니다.
예를 들어 항공편 예약 시나리오를 보면:
기존 방식 (HTML 기반):
- AI가 항공사 사이트 접속
- 출발지 입력 필드 찾기
- 목적지 입력 필드 찾기
- 달력에서 날짜 클릭
- 검색 버튼 찾아서 클릭
- 결과 페이지에서 항공편 정보 파싱
MCP 방식:
- AI가
book_flight(departure, destination, date)함수 직접 호출 - 즉시 예약 완료
안정성과 속도의 혁신
MCP 방식의 가장 큰 장점은 안정성입니다. 웹사이트의 디자인이 바뀌어도 API 인터페이스는 그대로 유지됩니다. AI는 예측 가능한 방식으로 일관된 결과를 얻을 수 있습니다.
속도 면에서도 압도적입니다. 기존 방식에서 10-15분 걸리던 복잡한 온라인 쇼핑이 MCP를 통하면 1-2분 내에 완료됩니다.
효과적인 MCP 도구 설계의 핵심
하지만 이런 효율성을 얻으려면 MCP 도구를 올바르게 설계해야 합니다. 많은 개발자들이 기존 API를 그대로 MCP로 래핑하는 실수를 범하는데, 이는 AI의 특성을 제대로 이해하지 못했기 때문입니다.
AI와 인간 개발자의 근본적 차이
AI는 인간 개발자와 완전히 다르게 작동합니다.
인간 개발자는 한 번 API 사용법을 배우면 재사용합니다. 변수에 프로젝트 ID를 저장하고, 다음 API 호출에서 그 값을 활용합니다. 실패하면 예외 처리를 하고, 효율적인 패턴을 만들어 계속 활용합니다.
AI 에이전트는 매번 처음부터 시작합니다. 대화가 새로 시작되면 이전 경험을 기억하지 못합니다. 사용 가능한 도구들을 다시 파악하고, 어떤 순서로 호출해야 하는지 매번 새로 계산해야 합니다.
Vercel의 배포 사례
Vercel의 실제 사례를 보면 이 문제가 명확해집니다. 프로젝트 배포를 위해 기존 API 방식에서는:
// 기존 API 방식 - 개발자가 상태를 관리
const project = await client.projects.create({
name: domain.replace(/\./g, '-'),
gitRepository: { repo: repoUrl }
});
await client.projects.createProjectEnv({
idOrName: project.id, // 이전 단계의 ID 활용
upsert: 'true',
requestBody: envVariables
});
const deployment = await client.deployments.createDeployment({
requestBody: {
name: project.name,
target: 'production',
gitSource: { type: 'github', repo: repo, ref: 'main' }
}
});
await client.projects.addProjectDomain({
idOrName: project.id, // 다시 ID 재사용
requestBody: { domain: domain }
});AI는 매번 이 복잡한 과정을 처음부터 다시 배워야 합니다. 프로젝트 ID를 다음 단계에 전달하는 것을 잊거나, 필수 필드를 빠뜨리거나, 에러가 발생했을 때 어떻게 복구해야 하는지 헤맵니다.
워크플로우 중심 설계의 필요성
단일 의도 처리 도구
해결책은 사용자의 완전한 의도를 처리하는 단일 도구를 만드는 것입니다:
// MCP 워크플로우 방식
deploy_project(repo_url, domain, environment_variables, branch="main")이 하나의 도구가 내부적으로 모든 복잡한 과정을 처리합니다. AI는 “프로젝트를 배포하고 싶다”는 의도만 전달하면 됩니다.
결과도 기술적 상태 코드 대신 자연스러운 응답을 제공합니다: “프로젝트가 example.com에 성공적으로 배포되었습니다. 빌드는 45초 만에 완료되었습니다.”
API 설계 vs 워크플로우 설계
기존 API 설계 사고방식과 MCP 도구 설계의 차이:
API 중심 사고: create_project, add_env, deploy, add_domain
워크플로우 중심 사고: deploy_project
API 중심: 여러 번의 호출과 상태 관리 필요
워크플로우 중심: 단일 원자적 작업
API 중심: 기술적 상태 코드 반환
워크플로우 중심: 대화형 업데이트 제공
실전 MCP 도구 설계 가이드
사용자 의도 분석부터
효과적인 MCP 도구를 만들려면 사용자 의도 분석부터 시작해야 합니다.
“전자상거래 사이트를 만들고 싶다”는 요청이 있다면, 이를 위해 필요한 모든 과정을 하나의 도구로 통합합니다:
- 프로젝트 초기화
- 상품 관리 시스템
- 결제 시스템 연동
- 사용자 인증
- 배송 관리
이 모든 과정을 create_ecommerce_site(business_name, products, payment_options) 하나로 처리합니다.
설계 원칙
완전성: 사용자의 목표를 처음부터 끝까지 달성할 수 있어야 합니다.
예측 가능성: 같은 입력에 대해 항상 일관된 결과를 제공해야 합니다.
진행 상황 공유: 긴 작업의 경우 “데이터베이스 설정 중…”, “결제 시스템 연동 중…” 같은 중간 업데이트를 제공합니다.
명확한 네이밍: processData 같은 모호한 이름 대신 generate_invoice, send_notification 처럼 명확한 이름을 사용합니다.
실패 사례와 성공 사례
실패 사례: 기존 REST API를 그대로 MCP로 래핑
- AI가 매번 복잡한 API 조합을 새로 학습
- 일관성 없는 결과와 반복적인 실패
성공 사례: 완전한 워크플로우를 하나의 도구로 통합
- AI가 명확한 의도만 전달하면 모든 과정 자동 처리
- 안정적이고 예측 가능한 결과
마무리
AI 브라우저와 MCP의 결합은 웹 경험의 근본적 변화를 가져오고 있습니다. 사용자는 여전히 브라우저를 사용하지만, 그 안에서 일어나는 상호작용은 완전히 달라집니다.
중요한 것은 이 변화를 단순한 기술 트렌드가 아닌 새로운 인터페이스 패러다임으로 이해하는 것입니다. API 설계에서 워크플로우 설계로, 기능 중심에서 의도 중심으로 사고방식을 전환해야 할 때입니다.
참고자료:
Comments