MCP vs API vs CLI: 에이전트용으로 셋 다 만들어 봤다. 내 생각은 이렇다

https://x.com/hot_town/status/2117922543092793474

AI 에이전트가 제 앱을 잘 쓸 수 있으면 좋겠다는 생각에, 현재 업계 모범 사례를 바탕으로 MCP, API, CLI를 모두 갖춘 앱을 하나 만들어 봤습니다.

그러기 위해 조사를 정말 많이 했고, 그렇게 알게 된 모든 것을 바탕으로 제 생각을 말씀드리면 이렇습니다.

아마 99%의 앱은 MCP 서버에 대부분의 노력을 쏟아야 합니다.

그렇다고 해도 같은 코드 위에 괜찮은 REST API는 여전히 만들어 두어야 하고(이걸 쉽게 해 주는 영리한 방법이 있는데, 아래에서 설명하겠습니다), CLI는 사용자에게 정말 필요할 때만 추가하면 됩니다.

아래에서는 왜 그런지, 그리고 직접 만들 때 반드시 제대로 챙기라고 권하고 싶은 것들을 모두 다룹니다. 예제 앱 저장소와 전체 가이드 링크도 글 끝에 있습니다.

참고로 예제 앱인 Linkly는 이 글에서 다루는 원칙에 따라 MCP 서버, API, CLI를 갖춘 링크 단축 서비스입니다. 도구 자체에 집중할 수 있도록 일부러 단순한 앱을 예제로 골랐습니다.

내 웹 앱에 맞는 에이전트 도구는 어떻게 골라야 할까요?

1분 만에 알아보는 MCP

MCP(Model Context Protocol)는 어떤 에이전트든 앱에 연결해 사용할 수 있게 해 주는 표준 방식입니다.

MCP가 특히 강력한 이유는 MCP 서버가 하는 일과 클라이언트가 하는 일을 모두 스펙에서 정의한다는 점입니다. 여기서 클라이언트란 하네스나 에이전트 앱(Claude, ChatGPT, OpenCode 등)을 말합니다.

API는 서버가 하는 일만 정의할 뿐이고, 그 데이터를 받는 쪽의 클라이언트나 하네스, 에이전트 앱이 데이터를 어떻게 다뤄야 하는지는 아무것도 표준화하지 않습니다. API는 다른 시대에, 다른 목적(스크립트, 소프트웨어 간 연동)을 위해 만들어졌습니다.

MCP는 처음부터 에이전트를 위해 만들어졌고, 그 차이가 분명히 드러납니다.

그러니 지금부터는 "에이전트"가 사실 두 가지로 이루어져 있다는 점을 기억해 주세요.

• 무엇을 할지 결정하는 바탕의 모델.
• 서버에 연결해 도구와 도구 설명을 불러오고, 호출을 실행하고, 로그인 정보를 저장하고, 여러분이 보고 있는 화면을 담당하는 클라이언트(Claude Code, ChatGPT, Cursor, Codex 등).

에이전트는 두 부분으로 이루어집니다. MCP 클라이언트(하네스 또는 앱)와, 그 아래에서 무엇을 할지 결정하는 LLM입니다. 클라이언트는 모델과도, MCP 서버와도 통신합니다.

MCP는 "컨텍스트 비대화"의 주범 아닌가요?

예전에는 그랬고, 그게 초창기에 MCP가 평판이 나빴던 큰 이유 중 하나입니다.

연결한 서버마다 모든 도구 정의를 처음부터 모델의 컨텍스트에 쏟아부었기 때문에, 서버를 몇 개만 연결해도 컨텍스트 창을 이미 상당히 잡아먹었습니다.

이 문제는 이제 거의 해결되었습니다. 클라이언트들이 다음 기능을 구현한 덕분입니다.

• 도구 검색(Tool search): 클라이언트가 현재 작업에 필요한 도구만 불러옵니다. Claude Code와 Claude 앱에서는 기본으로 켜져 있습니다.
• 코드 모드(Code mode): 모델이 도구를 호출하는 짧은 코드를 작성하면 클라이언트가 이를 샌드박스에서 실행하고, 중간 호출 하나하나가 아니라 최종 결과만 컨텍스트로 돌아갑니다. OpenCode에서는 기본으로 켜져 있고, Codex에서는 플래그로 켤 수 있습니다.

이제 Claude Code에서는 도구 검색이 기본 설정이라, 도구를 쓰지 않을 때는 연결된 MCP 서버가 컨텍스트를 부풀리지 않습니다.

저는 머지않아 대부분의 클라이언트와 하네스에서 도구 검색과 코드 모드가 기본값이 될 거라고 봅니다.

그러니 이제 이 문제를 서버 쪽에서 우회할 필요는 없습니다. 의미 있는 도구를 노출하고, 그 도구를 찾고 실행하는 방법은 클라이언트에 맡기면 됩니다.

MCP는 그냥 API를 감싼 래퍼 아닌가요?

처음에는 어느 정도 그랬지만, 지금은 아닙니다.

클라이언트 쪽도 표준화되어 있기 때문에, MCP 클라이언트는 MCP 서버에 무엇을 기대할 수 있는지 알고 있고, 그렇지 않았다면 여러분이 직접 만들거나 에이전트가 알아서 해 주길 바라야 했을 일을 상당 부분 대신 처리합니다.

• 로그인을 처리합니다. 이것 하나만으로도 MCP를 쓸 가치가 있습니다. 사용자가 MCP URL을 붙여 넣으면 앱의 브라우저 창이 열리고, 사용자는 허용을 누르기만 하면 됩니다. OAuth 앱을 미리 등록하거나 API 키를 만들 필요가 없습니다. 클라이언트가 전부 처리해 줍니다.
• 도구와 함께 사용 지침이 전달됩니다. 서버는 클라이언트에게 앱이 무엇이고 도구들이 어떻게 맞물리는지 알려 주고, 각 도구 설명에는 언제 이 도구를 쓰고 다음에 무엇을 해야 하는지가 담겨 있습니다. MCP 서버에 변경 사항이 생기면 에이전트는 이를 자동으로 파악합니다. API를 쓰면 에이전트가 새 세션마다 문서를 다시 읽어야 하거나, 여러분이 그 API에 맞는 스킬을 만들고 관리해야 합니다. 서버가 바뀔 때마다 연결 코드도 고쳐야 합니다.
• 사람들이 채팅을 벗어나지 않고도 여러분의 앱을 찾을 수 있습니다. Claude와 ChatGPT에는 모두 커넥터 디렉터리가 있습니다.
• 어떤 에이전트는 MCP로만 여러분의 앱에 닿을 수 있습니다. Claude와 ChatGPT의 데스크톱 앱과 모바일 앱에서는 모델에게 셸이 없고 샌드박스가 기본적으로 외부 호스트 대부분을 차단하므로, 주요 커넥터 중 지원되는 것은 MCP뿐입니다.

Claude Code가 Linkly 계정에 접근하도록 허용할지 묻는 Linkly의 동의 화면입니다. 권한마다 체크박스가 있습니다.

MCP가 API 호출 이상으로 표준화하는 것들

MCP는 클라이언트까지 표준화하기 때문에, 서버가 클라이언트에게 사용자를 위해 무언가를 해 달라고 요청할 수 있습니다.

스펙은 계속 발전하고 있고, 저는 그 방향이 정말 마음에 듭니다. 에이전트 클라이언트를 위해 표준화된 것 중 제가 특히 좋아하는 몇 가지를 소개합니다.

일리시테이션(Elicitation)

일리시테이션은 쉽게 말해 MCP 서버가 사람에게 직접 가서 작업을 확인받거나 마무리하게 하는 기능입니다. 단순하지만, 사람을 루프 안에 두고 싶은 경우가 여전히 많기 때문에 저는 이 기능을 아주 좋아합니다.

에이전트에게 민감한 정보를 삭제하는 일을 맡겼다고 해 봅시다.

API라면 `confirm=true` 같은 매개변수를, CLI라면 `--yes` 같은 플래그를 요구할 겁니다. 어느 쪽이든 확인 단계가 담긴 응답은 항상 바탕의 모델을 거치게 되고, 모델은 얼마든지 혼자서 확인해 버릴 수 있습니다.

MCP에서는 삭제 도구가 클라이언트에게, 앱의 확인 페이지를 열지 묻는 대화상자를 사용자에게 띄우라고 지시할 수 있습니다. 이를 지원하는 클라이언트에서는 모델이 완전히 건너뛰어지므로, 모델이 여러분 대신 행동할 기회가 아예 없습니다. 모델은 작업의 최종 결과만 전달받습니다.

비서에게 신용카드를 맡기는 상황과 비슷합니다. 가게에서 결제할 때 "정말 결제하시겠어요?"라고 물으면 비서가 대신 "네"라고 할 수는 있지만, 구매를 확정하려면 은행이 여러분 휴대폰으로 문자를 보내고, 승인은 여러분만 할 수 있습니다. 비서는 구매를 도울 뿐, 최종 결정권은 갖지 않습니다.

Claude Code가 URL 모드 일리시테이션으로 Linkly 링크를 삭제하는 모습입니다. 링크를 삭제해 달라고 요청하면 클라이언트가 Linkly의 확인 페이지를 열고, 결정은 여러분이 합니다.

필요할 때 요청하는 권한

MCP에서는 에이전트의 현재 권한에 따라 앱 기능을 얼마나 노출할지 정할 수 있습니다.

• 현재 권한으로 쓸 수 있는 도구만 보여 줍니다. 사용 가능한 도구 목록을 에이전트가 실제로 할 수 있는 일에 맞춰 간결하게 유지합니다.
• 추가 권한이 필요한 도구도 보여 줍니다. 에이전트가 무엇이 가능한지 알아보게 하고, 그 작업이 필요해지면 사용자에게 권한을 요청하게 합니다.

두 번째 방식은 단계적 인증(step-up auth)을 사용합니다. 예를 들어 에이전트가 읽기 전용 권한으로 시작했다고 해 봅시다. 에이전트가 링크를 만들려고 하면 서버는 쓰기 권한이 필요하다고 알립니다. 이를 지원하는 클라이언트는 사용자에게 갱신된 동의 절차를 거치게 한 뒤 호출을 다시 시도합니다.

API도 같은 바탕의 OAuth 표준을 써서 단계적 인증을 할 수 있습니다. 하지만 MCP는 클라이언트의 동작 규칙까지 정해 두기 때문에, 서버가 더 많은 권한을 요청할 때 모델이 어떻게 해야 할지 스스로 알아낼 필요가 없습니다.

다음은 예시입니다.

Linkly에서 권한이 부족할 때 단계적 인증이 이루어지는 모습입니다.

MCP 앱(MCP Apps)

MCP 앱은 차트나 폼, 심지어 편집기 전체 같은 실제 인터랙티브 UI를 채팅 안에 띄웁니다.

다음은 제가 시각적인 풀스택 앱 편집기를 에이전트 채팅 인터페이스 안에 넣어 만든 예시입니다. 이렇게 하면 데이터베이스 모델부터 클라이언트 상호작용까지 앱을 기획하고 만들 수 있을 뿐 아니라, 에이전트가 한 번에 만들어 준 복잡한 앱을 이해하는 데도 쓸 수 있습니다.

Wasp 프로토타입 MCP 앱입니다. Claude 채팅 안에서 에이전트와 함께, 풀스택 앱 아키텍처를 시각적이고 인터랙티브하게 다룹니다.

저는 이 분야에서 가능한 일 중 아직 겉핥기만 했다고 생각합니다. TLDRAW의 멋진 예시도 한번 보세요.

MCP 이벤트(MCP Events)

이벤트를 쓰면 무언가 바뀌었을 때 서버가 에이전트에게 알림을 보낼 수 있어서, 아무도 프롬프트를 입력하지 않아도 에이전트가 깨어나 작업을 마칩니다. ChatGPT는 9월 29일에 이 기능을 출시했습니다.

Cloudflare 워커에서 오류가 나면 MCP 이벤트로 에이전트에게 알려 문제를 해결하게 하는 모습입니다.

이 기능들은 클라이언트마다 지원 수준이 제각각이므로, 기능마다 대체 수단을 마련해 두세요. 대체 수단은 거의 항상 앱으로 돌아가는 링크 하나면 충분합니다. 예를 들어 Linkly의 통계 결과에는 모두 대시보드에서 차트를 여는 dashboardUrl이 들어 있습니다. 나중에 클라이언트가 그 기능을 지원하게 되면, 사용자는 별다른 조치 없이 더 나은 버전을 쓰게 됩니다.

들어 보지 못했을 수도 있는 기능 몇 가지를 더 소개합니다.

• 스킬(Skills). 서버가 에이전트 스킬, 즉 앱에서 일을 처리하는 방법을 적은 지침과 보조 파일을 함께 제공하면, 클라이언트가 이를 찾아 불러옵니다. 이 확장은 9월에 최종 확정되었고, ChatGPT는 이미 MCP 서버에서 스킬을 가져올 수 있습니다.
• 프롬프트(Prompts). 서버가 미리 만든 프롬프트 템플릿을 제공하면, 사용자가 직접 실행합니다. 보통 클라이언트에서 슬래시 명령으로 쓰입니다.
• 자동 완성(Autocomplete). 사용자가 프롬프트나 리소스를 채우는 동안 클라이언트가 서버에 인자 자동 완성을 요청할 수 있습니다. 입력하는 동안 링크 슬러그를 제안하는 식입니다.
• 실시간 도구 목록(Live tool lists). 도구, 프롬프트, 리소스가 바뀌면 서버가 클라이언트에 알려 주므로, 다시 연결하지 않아도 새 항목이 나타납니다.
• 진행 상황과 취소(Progress and cancel). 오래 걸리는 도구 호출이 진행 상황을 보고할 수 있고, 클라이언트는 표준 방식으로 호출을 취소할 수 있습니다.
• 엔터프라이즈 관리형 인증(Enterprise-managed auth). 회사 관리자가 자체 ID 공급자를 통해 어떤 에이전트가 앱에 접근할지 통제할 수 있습니다. 팀 단위로 판매한다면 중요한 기능입니다.

에이전트가 그냥 API를 쓰면 안 되나요? CLI는요?

경우에 따라서는 그렇습니다. 다음과 같은 경우에는 API가 더 낫습니다.

• 대량 작업과 원시 데이터 내보내기.
• 반복해서 다시 돌릴 작업. 팀원 누구나 읽고 일정을 걸 수 있는 스크립트가, 채팅 하나 안에만 존재하는 예약 작업이나 루프보다 나을 때가 있습니다.
• 야간 동기화나 다른 회사의 연동처럼 루프 안에 에이전트가 없는 모든 작업.

에이전트가 로컬 파일을 읽으려고 bash가 필요한 경우처럼 CLI가 이기는 경우도 있습니다. 원격 MCP 서버는 디스크를 읽을 수 없으므로, 파일에 든 URL 수천 개를 단축하려면 모든 URL이 모델의 컨텍스트를 거쳐야 합니다. CLI라면 명령 한 줄이면 되고, 데이터가 모델에 닿지도 않습니다.

MCP 서버를 추가하려면 앱을 다시 짜야 하나요?

아닙니다. 요령은 앱을 두 계층으로 나누는 것입니다.

1. 오퍼레이션(Operations): 비즈니스 로직입니다. 사용자가 할 수 있는 일 하나당 함수 하나를 둡니다.
2. 서피스(Surfaces): 그 오퍼레이션을 호출하는 얇은 어댑터(대시보드, MCP, REST API, CLI)입니다.

제 앱인 Linkly에서는 대시보드에서 "링크 만들기"를 누르면, 에이전트가 MCP로 호출하는 것과 똑같은 createLink 함수가 호출됩니다. 각 서피스는 자기 방식의 로그인 정보를 "누가 호출하는지" 나타내는 객체 하나로 바꾸고, 입력을 넘기고, 결과를 형식에 맞게 다듬습니다. 오류도 같은 방식으로 처리됩니다.

이미 앱이 있다면 한꺼번에 옮기지 마세요. 에이전트가 가장 많이 쓸 작업 3~5개(Linkly라면 링크 만들기, 링크 목록 보기, 통계 보기)를 골라 오퍼레이션으로 옮기고, 먼저 대시보드가 그 오퍼레이션을 쓰게 해서 실제 사용자들이 테스트하게 하세요. 그다음에는 어댑터만 추가하면 MCP나 API로 노출할 수 있습니다.

자세한 내용은 다음을 참고하세요.

• 전체 가이드: https://wasp.sh/blog/2026/11/03/mcp-vs-api-vs-cli-connect-ai-agents-to-your-app
• 저장소: github.com/vincanger/linkly-api-mcp-cli.

네 가지 호출자가 모두 같은 createLink 오퍼레이션에 도달합니다.

만들 때 고려해야 할 중요한 사항

앱에서 에이전트에 최적화된 도구를 노출할 때 쓸 수 있는 체크리스트 같은 것입니다.

MCP 서버

• 도구 설명에는 비슷한 도구 대신 이 도구를 언제 써야 하는지, 후속 작업으로 어떤 도구를 쓸 수 있는지, 흔한 오류가 난 뒤에는 무엇을 해야 하는지를 적습니다.
• 권한이나 위험도의 경계를 넘어서 도구를 합치지 마세요. 읽기 작업과 쓰기 작업은 별도의 도구로 둡니다.
• 모든 도구에 어노테이션과 출력 스키마를 붙이고, 서버에는 사용 지침을 추가합니다.
• 대부분의 경우 앱으로 돌아가는 딥 링크를 함께 보냅니다. 그러면 사용자가 대시보드에서 직접 확인할 수 있고, 클라이언트가 MCP 앱이나 일리시테이션 같은 기능을 지원하지 않을 때 대체 수단 역할도 합니다.
• whoami 도구를 추가해, 에이전트가 시도하기 전에 자신이 무엇을 할 수 있는지 확인하게 합니다.
• 사람이 쓰는 식별자를 받아들입니다. 제 예제 앱 Linkly라면 UUID뿐 아니라 슬러그도 받는다는 뜻입니다.
• 모든 오류 메시지에 다음에 할 일을 적습니다. 예를 들면 Link "abc" not found. Use list_links to find valid IDs or slugs. 같은 식입니다.
• search_docs와 read_doc 도구를 추가해, 에이전트가 추측하는 대신 직접 찾아보게 합니다.
• 도구 검색과 코드 모드는 클라이언트에 맡기고, 도구를 자체 search()와 execute() 뒤에 숨기지 마세요. 앱이 데이터 중심이라면 읽기 전용 쿼리 도구 하나는 여전히 둘 만합니다. PostHog의 executeSql은 "가입자가 왜 줄었지?"라는 질문을 도구 호출 네 번에서 한 번으로 줄였습니다.

REST API

• OpenAPI 문서는 오퍼레이션이 검증에 쓰는 것과 같은 스키마에서 생성해, 둘이 어긋나지 않게 합니다.
• 필요한 권한과 로그인 방법을 문서에 적습니다.
• 위험한 경로에는 x-destructive를 표시합니다. POST도 DELETE만큼 되돌릴 수 없을 수 있는데, HTTP 메서드만으로는 에이전트가 그걸 알 수 없습니다.
• 오류 형식은 어디서나 하나로 통일합니다: { "error": { "code": "conflict", "message": "…" } }.

OAuth

• CIMD(Client ID Metadata Documents)를 사용합니다. 클라이언트 ID가 작은 JSON 파일을 가리키는 URL이므로, 어떤 클라이언트든 앱을 먼저 등록하지 않고도 연결할 수 있습니다.
• 클라이언트의 첫 요청에는 토큰이 없으므로, WWW-Authenticate 헤더가 메타데이터를 가리키는 401로 응답합니다. 클라이언트는 이렇게 URL 하나만으로 로그인 방법을 찾아냅니다.
• 쓰기 권한은 읽기 권한을 포함합니다. 요청마다 권한 부여 여부를 확인하세요. 사용자는 나중에 권한을 회수할 수 있지만, 앱이 요청한 것보다 많은 권한을 부여해서는 안 됩니다.
• 토큰 수명은 짧게 유지합니다. Linkly의 액세스 토큰은 한 시간 동안 유효하고, 리프레시 토큰은 쓸 때마다 교체되며, 이미 쓴 리프레시 토큰을 다시 쓰면 연결 전체가 취소됩니다.
• 에이전트는 아직 일반 API에서 OAuth를 수행하지 않으므로, 당분간 API 사용자는 대부분 개인 액세스 토큰을 넘겨주게 됩니다.
• 쓰고 있는 인증 공급자가 MCP 인가 스펙을 지원한다면 그냥 그걸 쓰세요.

파괴적 작업

• 모든 서피스가 함께 쓰는 확인 페이지를 앱에 먼저 만듭니다. 소유자만 확인할 수 있고, 한 번만 쓸 수 있으며, 시간이 지나면 만료됩니다(Linkly에서는 15분).
• 삭제, 결제, 계정 연결처럼 실제 사용자가 필요한 작업에는 채팅 안의 폼이 아니라 페이지를 쓰세요. 페이지에서의 클릭은 사용자 본인이 로그인한 세션에서 일어나지만, 폼 응답은 클라이언트에서 오기 때문에 그 응답을 믿을 수밖에 없습니다.
• 링크 대체 수단을 먼저 만듭니다. URL 모드 일리시테이션을 지원하지 않는 클라이언트는 status: "confirmation_required"와 함께 전달할 confirmUrl을 받고, REST API도 202와 함께 같은 내용을 반환합니다.
• destructiveHint는 힌트일 뿐입니다. 사용자에게 묻는 클라이언트도 있고 묻지 않는 클라이언트도 있습니다.
• 클라이언트는 곧바로 재시도하는데, 보통 사용자가 아무것도 누르기 전입니다. Linkly는 다시 묻지 않고 결정을 최대 20초까지 기다립니다.
• 재시도와 함께 돌아오는 requestState에 서명하고, 이를 사용자와 대기 중인 삭제 요청에 묶은 뒤, 단 한 번만 받아들입니다.
• 되돌릴 방법을 제시합니다. Linkly의 delete_link 설명은 대신 링크를 보관 처리하라고 제안합니다.

CLI

• 절대 프롬프트로 묻지 마세요. 에이전트는 대화형 프롬프트에 답할 수 없어서 명령이 그대로 멈춰 버립니다. 대신 오류를 내고 빠진 플래그 이름을 알려 주세요.
• 파이프로 연결되면 JSON을 출력하고, --json 플래그도 추가합니다.
• 오류는 stderr로 보내고, 에이전트가 분기 처리할 수 있는 종료 코드를 씁니다.
• --help에는 예시를 넣어 작성합니다. 에이전트는 그걸 보고 CLI 사용법을 익히기 때문입니다.

발견 가능성

누군가 에이전트에게 "myapp.com을 써"라고 하면 에이전트는 홈페이지를 가져오는데, 싱글 페이지 앱이라면 빈 <div id="root">만 받게 됩니다. 그러니 다음을 챙기세요.

• 연결 방법을 적은 llms.txt를 제공합니다.
• 랜딩 페이지나 에이전트용 페이지를 사전 렌더링하고, MCP URL이 담긴 "AI 에이전트용" 섹션을 눈에 보이게 둡니다.
• OpenAPI 문서를 /.well-known/openapi.json에서 제공하고, /.well-known/api-catalog에 등록하고, API 응답에 Link: rel="service-desc"헤더를 추가합니다.
• 앱 안에 MCP URL과 복사할 프롬프트가 담긴 "AI 에이전트 연결하기" 카드를 추가합니다. 사용자가 직접 건네주는 URL이 여전히 가장 확실한 진입 경로입니다.

보안 강화

• 자기 도구의 결과도 프롬프트 인젝션 입력으로 취급합니다. Linkly에서는 단축 링크를 클릭하는 누구나 Referer 헤더를 조작할 수 있으므로, 호스트 이름만 남깁니다.
• 사용자 단위뿐 아니라 연결 단위로도 요청 속도를 제한하고, 429와 Retry-After로 응답해 에이전트가 요청을 퍼붓지 않고 기다리게 합니다.
• 클라이언트 하나가 아니라 여러 개에서 테스트합니다. localhost에서 Claude Code로 시작한 다음, claude.ai와 ChatGPT는 공개 HTTPS URL에만 연결되므로 터널을 써서 테스트합니다.

코드 받아 가기

가장 쉬운 방법은 저장소와 전체 가이드를 코딩 에이전트에게 넘겨주고, 여러분의 앱에 맞게 고치게 하는 것입니다.

• 저장소: github.com/vincanger/linkly-api-mcp-cli.
• 전체 가이드: https://wasp.sh/blog/2026/11/03/mcp-vs-api-vs-cli-connect-ai-agents-to-your-app

Linkly는 Wasp로 만들었습니다. 오퍼레이션을 MCP 도구와 REST 경로로 바꾸거나 OAuth 서버를 운영하는 것 같은 배관 작업은 상당 부분 저희가 기능으로 만들어 Wasp가 대신 처리하게 할 예정입니다. 곧 더 자세히 알려 드리겠습니다!

지금도 Wasp는 AI 에이전트와 함께 풀스택 앱을 개발하는 최고의 경험을 제공합니다. Wasp의 Spec은 애플리케이션 전체(경로, 엔티티, 오퍼레이션, 인증, DB 등)를 압축해 보여 주는 고수준 지도 역할을 합니다. 에이전트는 명확한 가드레일 안에서 이를 읽고 수정할 수 있고, 컴파일러가 그 결과를 검증합니다.

직접 써 보세요.

npm i -g @wasp.sh/wasp-cli@latest