먼저 사용자가 플러그인에 어떤 일을 기대할지 목록으로 정리하세요. 사용자는 플러그인의 이름과 설명, 제공하는 스킬과 도구, 기존 제품과의 연동 방식을 보고 어떤 일을 할 수 있을지 예상합니다. 이러한 기대를 충족하도록 구현하세요. 일부 요청을 지원하지 않기로 했다면 그 이유가 분명해야 합니다.
이 목록을 바탕으로 플러그인에 무엇을 포함할지 정하세요.
- 지침, 예시 또는 함께 제공하는 리소스로 모델이 워크플로우를 수행하도록 안내할 수 있다면 스킬을 추가하세요.
- 워크플로우에 실시간 데이터, 인증, 사용을 제어할 수 있는 도구 또는 직접 운영하는 인프라에서 실행되는 코드가 필요하다면 MCP 서버를 추가하세요.
- 시각적 상호작용으로 워크플로우의 일부를 실질적으로 개선할 수 있을 때만 MCP 서버에 UI를 추가하세요.
사용자의 기대에서 출발하기
사용자가 플러그인을 설치하고 문서는 아직 읽지 않았다고 가정해 보세요. 이 사용자는 플러그인에 어떤 일을 자연스럽게 요청할까요?
다음 자료를 살펴보고 사용자가 할 만한 요청을 모으세요.
- 사용자가 제품이나 서비스에서 이미 수행하는 작업
- 사용자 인터뷰, 고객 지원 문의, 검색어, 기능 요청
- 사용자가 제품, 데이터, 워크플로우를 가리킬 때 흔히 쓰는 표현
- 도구 간에 데이터를 복사해야 하는 기존 우회 방법
- 플러그인 이름, 소개 페이지, 시작 프롬프트
플러그인 이름을 언급하는 직접적인 요청과 목표만 밝히는 간접적인 요청을 모두 포함하세요. 예를 들어 프로젝트 관리 플러그인이라면 “내 Acme 출시 보드를 보여 줘”와 “출시를 가로막는 문제가 뭐야?”라는 요청을 모두 처리해야 할 수 있습니다.
사용 사례를 구상할 때 현재 API로 구현할 수 있는 워크플로우에만 한정하지 마세요. 먼저 사용자가 무엇을 기대할지 정리한 다음, 그중 어떤 요청을 안전하고 안정적으로 지원할 수 있는지 살펴보세요.
사용 사례 목록 만들기
각 사용 사례에 대해 다음 항목을 기록하세요.
| 항목 | 확인할 질문 |
|---|---|
| 사용자 목표 | 사용자가 달성하려는 목표는 무엇인가요? |
| 요청 예시 | 사용자는 직접적으로 또는 간접적으로 어떻게 요청할까요? |
| 기대 결과 | 어떤 결과를 얻으면 사용자의 요청이 충족되나요? |
| 필요한 컨텍스트 | 어떤 정보나 계정 접근 권한이 필요한가요? 작업 전에 어떤 상태가 갖춰져 있어야 하나요? |
| 플러그인 기능 | 스킬로 처리할 수 있나요, 아니면 MCP 도구가 필요한가요? |
| 안전 범위 | 데이터를 노출하거나 상태를 변경하거나 비용을 발생시키거나 다른 사람에게 영향을 줄 수 있나요? |
| 지원 여부 | 첫 버전에서 지원할까요, 이후로 미룰까요, 아니면 의도적으로 제외할까요? |
목표가 같은 요청은 한데 묶으세요. “내 미완료 작업 목록을 보여 줘”, “오늘 내가 해야 할 일이 뭐야?”, “기한이 지난 작업을 보여 줘”는 서로 별개의 기능 세 가지로 나누기보다, 작업을 확인하는 하나의 사용 사례에 서로 다른 필터를 적용하는 요청으로 묶을 수 있습니다.
지원 범위 점검하기
사용자가 기대하는 일을 하나씩 살펴보며 계획한 플러그인 기능으로 처리할 수 있는지 점검하세요.
- 지원하기로 한 사용 사례마다 요청을 받아 유용한 결과를 제공하기까지 모든 단계를 수행할 수 있는지 확인하세요.
- 빠진 스킬, 도구, 데이터, 권한이나 미처 고려하지 않은 오류 상태를 파악하세요.
- 기술적인 작업은 제공하지만 사용자가 원하는 일을 끝까지 처리하지 못하는 도구가 있는지 살펴보세요.
- 쓰기 작업에 적절한 권한 검사와 확인 절차가 있는지 검증하세요.
- 플러그인이 수행할 수 없는 일을 설명하고 사용자에게 도움이 될 다음 단계를 제안할 수 있는지 확인하세요.
사용자가 기대하는 워크플로우 중 일부만 지원하면서 플러그인이 훨씬 더 많은 일을 할 수 있다는 인상을 주지 마세요. 예를 들어 프로젝트를 만들 수는 있지만 목록을 보거나 세부 정보를 확인하거나 내용을 수정할 수 없다면, 빠진 기능을 추가하거나 플러그인 소개에서 지원 범위를 더 좁게 명시하세요.
의도적으로 제외한 사용 사례 기록하기
상상할 수 있는 모든 요청을 구현할 필요는 없습니다. 다만 중요한 사용 사례를 제외할 때는 다음과 같이 타당한 이유가 있어야 합니다.
- 작업을 수행하면 안전이나 개인정보 보호 측면에서 감수하기 어려운 위험이 생깁니다.
- 기반 제품이나 API가 해당 작업을 안정적으로 지원하지 않습니다.
- 워크플로우에 필요한 권한이 있는지 플러그인이 검증할 수 없습니다.
- 플러그인이 접근할 수 없는 정보가 있어, 그 정보 없이 결과를 제공하면 사용자가 오해할 수 있습니다.
- 해당 사용 사례는 첫 릴리스의 범위를 벗어나며, 플러그인 소개 페이지에도 이 점을 명시했습니다.
이러한 결정을 기록하세요. 스킬의 적용 범위, 도구 설명, 요청을 거절할 때의 동작, 테스트 케이스, 공개 소개 페이지의 문구에 이 결정을 반영하세요.
사용 사례별 구현 방식 정하기
지원하기로 한 사용 사례마다 사용자의 목표를 달성하는 데 필요한 최소한의 구현 방식을 선택하세요.
- 반복해서 사용할 지침과 리소스는 스킬로 만드세요.
- 실시간 데이터를 제공하거나 작업 실행을 제어하려면 MCP 서버를 만드세요.
- 사용자가 구조화된 정보를 살펴보거나 비교, 편집, 확인, 탐색해야 한다면 MCP 서버에 UI를 추가하세요.
사용 사례 목록을 테스트 계획으로 활용하세요. 직접적인 요청, 간접적인 요청, 예외적인 상황의 요청, 지원 범위를 벗어난 요청을 각각 대표할 만한 예시를 추가하세요. 그런 다음 완성된 플러그인이 각 요청에 대해 의도한 대로 동작하는지 검증하세요.
플러그인에 실시간 데이터가 필요하거나 작업 실행을 제어해야 한다면 도구 정의하기로 이동하세요.