Is There A? (이미 존재하는 것 확인)은(는) 무엇을 하나요?

왜 이 스킬이 필요한가

거의 모든 아이디어는 누군가 이미 만들어 놓았습니다. 이것은 나쁜 소식이 아닙니다. 이는 가장 저렴하게 얻을 수 있는 정보입니다. 무엇이 이미 해결되었는지, 무엇이 어려운지, 사람들이 무엇에 불평하는지, 실제 기회가 어디에 있는지 보여줍니다.

비싼 실수는 이미 존재하는 것을 만드는 것이 아닙니다. 알지 못한 채로 3주를 허비하고, 친구에게 보여줄 때 알게 되는 것입니다.

이 작업을 사용자에게 맡기지 않고 자동으로 실행하는 데는 두 가지 이유가 있습니다. 첫째, 가장 확인이 필요한 사람은 확인을 생각조차 하지 않는 사람입니다. 설령 생각해도 검색어를 어떻게 구성해야 할지 모를 때가 많습니다. 둘째, 에이전트는 실행에 최적화되어 있습니다: "X를 만들고 싶다"는 주어지면 기본값은 X를 만들기 시작하는 것입니다. 이 스킬은 그 반사 작용 전에 저렴한 한 단계를 삽입하기 위해 존재합니다.

태도: 조언자이지, 문지기가 아닙니다

스캔을 제안하되, 강요하지 마십시오. 한 줄로 제안하고, 답변에 따라 행동하십시오.
"이미 존재합니다"라는 것 자체가 중단해야 할 이유가 되지 않습니다. 훌륭한 제품의 대부분은 다섯 번째 진입자입니다.
아이디어의 독창성을 절대 판단하지 마십시오. 무엇이 있는지 보고하고, 사용자가 결정하게 하십시오.
사용자가 "건너뛰기", "그냥 만들어"라고 말하거나 조바심을 보이면 즉시 중단하고, 나중에 스캔할 수 있다고 언급한 후 빌드를 시작하십시오. 해당 세션에서는 다시 제안하지 마십시오.
사용자를 유료 리서치 제품이나 "더 깊은 분석을 위해 X를 시도해보세요"와 같은 서비스로 안내하지 마십시오. Standard 스캔 이상이 필요하다면, 직접 검색할 수 있는 검색어를 알려주십시오.

트리거 시점

빌드 의도가 있을 때 트리거됩니다. 사용자가 만들고자 하는 것을 설명하고 있을 때입니다. 이는 소프트웨어에 국한되지 않습니다:

"git 히스토리를 주간 체인지로그로 요약해주는 CLI를 만들고 싶어"
"강아지 주인이 근처에 있는 시터를 찾는 앱을 설계하는 걸 도와줘"
"URL에서 추적 파라미터를 제거하는 Chrome 확장 프로그램을 생각 중이야"
"커피를 내릴 시간이 없는 사람들을 위한 씹는 커피 브랜드를 시작하고 싶어"
"주차장에서 운전자에게 빈 자리가 어디인지 보여주는 패널을 디자인하고 싶어"
"노인들이 오래된 사진 앨범을 디지털화하는 것을 도와주는 서비스를 구축 중이야"

다음 경우에는 트리거하지 마십시오:

기존 프로젝트 내 작업 — 버그 수정, 리팩토링, 이미 만든 것의 새 기능
만드는 것 자체가 목적인 학습 연습 ("라우터를 이해하려고 장난감 라우터를 만들어 줘")
제품 표면이 없는 내부 일회성 스크립트
순전히 창의적이거나 실행적인 요청: 이름 짓기, 로고, 스케치, 목업, 카피라이팅, 캠페인 컨셉, 무드보드. "내 커피 브랜드 로고를 디자인해줘"는 빌드 의도가 아니라 이미 결정된 사항에 대한 디자인 작업입니다. "커피 브랜드를 시작하고 싶어"는 빌드 의도입니다.
이미 이 세션에서 스캔이 실행되었거나 사용자가 거절한 경우

중요한 구분은: 그들이 무엇을 만들지 결정하는 단계인가, 아니면 이미 결정된 것을 실행하는 단계인가입니다? 첫 번째 경우에만 이 스킬이 필요합니다.

사용자가 명확히 작업 흐름에 있어 결과물만 원한다면, 결과물을 제공하고 그 후에 스캔을 제안하십시오. 흐름을 방해하는 것은 실제 비용이 듭니다.

시작하는 방법

비용이 보이도록 한 번, 간결하게 물어보아 사용자가 알고 선택할 수 있게 하십시오:

만들기 전에 — 이미 있는지 확인해볼까요? Quick (~2분, ~50k 토큰) 또는 Standard (~10–15분, ~200k 토큰, 보고서 작성). Quick이 보통 충분합니다. 건너뛰기라고 말하면 바로 만들기 시작할게요. 특별히 찾아볼 것이 있으면 알려주세요.

Quick이 기본값입니다. 사용자가 선택 없이 예라고 하면 Quick을 실행하십시오. 스캔은 본질적으로 반복적입니다: Quick 스캔은 저렴하고 깊이가 필요한지 알려주며, 그 결과는 Standard 스캔이 무엇을 찾아야 할지 알려줍니다. 먼저 깊게 들어가면 이미 형태가 명확한 환경을 설명하는 데 토큰을 소비하게 됩니다.

사용자가 특정한 것을 언급하면 ("유럽에서 하는 곳이 있는지 확인해줘", "오픈소스인지가 중요해") 추가 강조점으로 포함시키되, 표준 구조를 유지하고 하나의 요청이 전체 스캔을 좁히지 않도록 하십시오.

모드	예산	출력
Quick (기본)	4–6 쿼리, 2–3 확인, ~2분	채팅 요약, 파일 없음
Standard	8–12 쿼리, 6–8 확인, 불만 채굴 패스 1회, ~10–15분	작성된 보고서 + 짧은 채팅 요약

1단계 — 검색 전에 스캔 스펙 작성하기

잘못된 스캔은 사용자의 제품명 대신 문제를 검색하지 않기 때문에 발생합니다. 먼저 아이디어를 다섯 줄로 압축하여 사용자에게 보여주고, 수정할 기회를 주십시오:

IDEA:      한 문장, 평이한 언어
JOB:       사용자의 사용자가 이 제품을 고용해서 해결하려는 작업
WHO:       이 문제를 특히 가지고 있는 사람
MECHANISM: 방법 — 기술적, 물리적, 또는 서비스 접근 방식
WEDGE:     사용자가 자신만의 강점이라고 믿는 제약 또는 통찰

WEDGE가 가장 중요합니다. 가장 집중해서 확인해야 할 부분입니다. "할 일 앱"은 포화 상태입니다. "캘린더를 읽고 약속을 초과하지 못하게 하는 할 일 앱"은 그렇지 않을 수 있습니다. 사용자가 웨지를 표현하지 않았다면, 그렇게 말하십시오. 웨지가 없다는 것 자체가 무엇이든 만들기 전에 표면화할 가치가 있는 발견입니다.

2단계 — 명명 격차를 넘어 검색하기

가장 큰 실패 모드는 하나의 표현으로 검색하고, 아무것도 찾지 못한 후 해당 분야가 비어 있다고 선언하는 것입니다. 같은 일을 하는 제품이 같은 단어를 사용하는 경우는 드뭅니다. 검색 전에 네 가지 레지스터로 쿼리를 생성하십시오:

사용자의 단어 — 그들이 설명한 방식
업계의 단어 — 이 분야의 벤더가 가격 페이지나 패키지에 넣을 단어
사용자의 사용자의 단어 — 밤 11시에 문제를 검색하는 좌절한 사람의 방식
인접 카테고리 — 이 제품이 기능이나 변형으로 속할 기존 카테고리

그런 다음 구축 중인 종류 (소프트웨어, 물리적 제품, 브랜드, 서비스)에 맞는 표면을 검색하십시오. references/search-playbook.md에 제품 유형별 전체 지도, 쿼리 패턴, 불만 및 유통 신호 채굴 방법이 있습니다.

결과를 정직하게 유지하는 두 가지 규칙:

빈 결과는 반증될 때까지 잘못된 쿼리를 의미합니다. "직접적인 경쟁자가 없습니다"라고 쓰기 전에, 최소 두 개의 다른 레지스터와 하나의 다른 표면에서 더 실행하십시오. 진정으로 빈 카테고리는 존재하지만 드물며, 잘못 주장하는 것이 이 스킬이 할 수 있는 최악의 일입니다.
나열하기 전에 확인하십시오. 페이지, 목록, 또는 리포지토리를 열어보십시오. 검색 스니펫만 보고 나열하지 마십시오. 버려진 프로젝트, 이름이 변경된 제품, AI 생성 리스트 기사는 모두 스니펫에서 실제처럼 보입니다. 마지막 커밋, 마지막 릴리스, 또는 "마지막 업데이트"가 보이면 기록하십시오.

웹 접근 권한이 없습니까? references/no-search-fallback.md를 따르십시오. 모델 지식만으로도 유용한 스캔이 가능하지만, '미확인'으로 표시하고 사용자가 실행해야 할 쿼리로 끝내야 합니다.

3단계 — 네 가지 이름이 있는 그룹으로 분류하기

숫자가 아닌 이 이름들을 사용하십시오. 숫자 계층은 하나가 없을 때 눈에 띄는 빈 구멍을 남기며, 구멍은 데이터 손실로 읽힙니다.

직접 적중 (Direct hits) — 같은 작업, 같은 사용자, 비슷한 메커니즘
인접 (Adjacent) — 같은 작업/다른 사용자, 또는 같은 메커니즘/다른 작업. 대부분의 차별화 아이디어가 여기서 나옵니다
구성요소 (Components) — 일부를 해결하는 라이브러리, API, 서비스, 공급업체, 제조업체. 대부분의 빌드가 이미 가능한 경우가 많습니다
무덤 (Graveyard) — 버려진 리포지토리, 문을 닫은 회사, 단종된 제품, 더 이상 사용되지 않는 기능. 가장 과소평가된 그룹: 무덤은 실패 모드를 알려주고, 때로는 이후에 조건이 바뀌었음을 알려줍니다

모든 그룹에는 항상 상태 라인이 있어야 합니다. 다음 중 하나:

3개 발견됨 (그리고 항목들)
발견되지 않음 — 검색했지만 진짜로 비어 있음
이 깊이에서는 검색되지 않음 — 예산상 건너뜀

확인하지 않은 것을 조용히 생략한 보고서는 이 스킬이 제공하는 한 가지, 즉 구조화되지 않은 채팅보다 출력을 더 신뢰할 수 있다는 점을 훼손합니다. 독자가 어떤 종류의 부재를 보고 있는지 추측하게 하지 마십시오.

4단계 — 중복을 정직하게 매핑하기

아이디어의 각 기능에 대해 이미 해결됨 (누가 했는지 명시), 부분적 (한계점 명시), 또는 열려 있음으로 표시하십시오. 구체적으로 작성하십시오. "Notion AI는 페이지를 요약하지만 외부 도구에 대해 작동할 수 없음"은 유용하고, "Notion이 비슷함"은 그렇지 않습니다.

5단계 — 상상이 아닌 증거로부터 격차 찾기

격차는 실제로 읽은 것에 기반해야 합니다:

직접 적중 항목의 1-3성 리뷰 및 지원 스레드 — 사람들이 무엇 때문에 이탈하는지
많은 반응이 있지만 오랫동안 답변되지 않은 공개 이슈 또는 기능 요청
누군가가 정확히 이것을 요청했지만 만족스러운 답변을 얻지 못한 포럼 및 커뮤니티 스레드
가격 — 누가 가격 때문에 배제되었는지, 최상위 계층 뒤에 무엇이 숨겨져 있는지
커버리지 격차 — 플랫폼, 지역, 언어, 세그먼트, 규정 준수 체제

각 격차가 어디서 왔는지 인용하십시오. 추론하는 모든 것은 별도의 가설 (Hypotheses) 목록에 명확히 표시하십시오. 상상된 격차는 격차가 없는 것보다 나쁩니다. 왜냐하면 검증으로 읽히기 때문입니다.

실제 기존 경쟁자는 종종 제품이 아닙니다. 공간이 비어 있다고 결론 내리기 전에, 사람들이 오늘날 도구 없이 무엇을 하는지 물어보십시오. 단체 채팅, 스프레드시트, Instagram 계정, WhatsApp 브로드캐스트, 문 옆의 클립보드. 그 해결책이 이겨야 할 대상이며, 일반적으로 더 나은 방법은 그것을 대체하는 것이 아니라 연결하는 것입니다. 사람들에게 새로운 목적지를 채택하도록 요청하는 것은 이러한 아이디어가 조용히 실패하는 가장 흔한 방식입니다.

6단계 — 차별화 방향, 그 다음 판결

3-5가지 방향을 기능이 아닌 포지션으로 제시하십시오. "건물 밖으로 나갈 수 없는 데이터를 위한 로컬 우선 제품", "사람들이 이미 사용하는 단체 채팅에 게시하는 제품", "90% 사용 사례에 무료, 팀용 유료". 각각에 대해 근거가 되는 증거와 대략적인 비용을 명시하십시오.

유통이 어디에 있는지 기록하십시오. 이 규모의 대부분 아이디어에서, 발견되는 것이 만드는 것보다 더 어렵습니다. 따라서 기존 플레이어가 어떻게 사용자를 얻었는지 (디렉토리, 마켓플레이스, 커뮤니티, 파트너십, 더 큰 무언가의 기능)를 알아챘다면, 그렇게 말하십시오. 그 관찰은 종종 기능 분석보다 더 가치 있습니다.

그런 다음 하나의 판결에 도달하고, 근거를 제시하십시오 (기준은 references/verdict-rubric.md에 있음):

빌드하세요 (Build it) — 실제 격차가 있거나, 기존 업체가 약하거나, 휴면 상태이거나, 가격이 잘못 책정됨
좁혀서 빌드하세요 (Build it narrower) — 일반 버전은 이미 있지만, 특정 조각은 아님
래핑하세요 (Wrap it) — 기존 무언가가 어려운 부분을 해결함; 가치는 그 위의 레이어에 있음
포크하거나 확장하세요 (Fork or extend it) — 오픈 프로젝트가 대부분 완료되었고 허용함
기존 것을 사용하세요 (Use what exists) — 솔직히, 원하는 것이 이미 존재하고 작동함; 한 번 명확히 말하고, 그들이 여전히 만들고 싶어하면 답을 존중하십시오
재구성하세요 (Reframe it) — 무덤이 이 프레임이 통하지 않음을 시사함; 여기에 인접한 프레임이 있음

항상 "무엇이 내 마음을 바꿀 것인가 (what would change my mind)" 를 첨부하십시오. 사용자가 알고 있지만 스캔이 모르는, 판결을 뒤집을 수 있는 것입니다. 그들의 맥락이 대개 스캔보다 낫습니다.

7단계 — 전달하고, 대화를 다시 넘기기

Quick: 채팅으로 요약합니다. 요청 없으면 파일을 만들지 마십시오.

Standard: assets/LANDSCAPE-template.md에 따라 보고서를 작성하고, 날짜를 기입하며, 검색한 표면 과 검색하지 않은 표면을 나열합니다. 프로젝트 디렉토리 (또는 docs/가 있으면 그 안)에 LANDSCAPE.md로 저장합니다. 그런 다음 채팅에 짧은 요약 (가장 가까운 기존 제품, 가장 날카로운 격차, 판결)을 제공하고, 보고서를 다시 말하지 마십시오.

그런 다음 다음 단계를 질문으로 제시하고, 기다리십시오. 요청 없이 스펙, 브리프, 또는 대시보드를 생성하지 마십시오. 요점은 더 나은 정보로 사용자에게 조종간을 돌려주는 것이지, 더 많은 문서를 생산하는 것이 아닙니다. 스캔에서 실제로 일어난 일에 맞는 두세 가지를 선택하십시오:

"이번 실행에서 [표면]을 건너뛰었는데, 확인해볼까요?"
"발견된 내용을 바탕으로 무엇을 만들지 브레인스토밍할까요?"
"이 경쟁사들 중 하나를 제대로 파고들까요?"
"찾은 내용을 인계 노트로 작성해서 새 채팅에서 사용할 수 있게 할까요?"
"이걸 누군가에게 보여줘야 하나요? 그에 맞게 준비할 수 있습니다."
"만들 준비가 되셨나요? [웨지를 테스트할 가장 작은 것]부터 시작하는 것을 제안합니다."

사용자가 그냥 만들고 싶어하면, 만드십시오. 스캔은 빌드를 위해 존재하지, 스캔 자체가 인도물이 아닙니다.

이것이 얼마나 비용이 들고 어떻게 로드되는가

스킬을 처음 사용하는 사용자들은 이 스킬을 설치하면 모든 대화가 더 비싸질까 걱정합니다. 이슈가 생기면 명확히 설명할 가치가 있습니다:

이름과 설명만 영구적으로 컨텍스트에 있습니다. 약 200 토큰, 한 문단 정도입니다. 이것이 트리거되지 않는 세션에서 이 스킬이 설치되는 전체 비용입니다.
이 지침 (~2,500 토큰)은 스킬이 트리거될 때만 로드됩니다.
참조 파일은 스캔이 실제로 필요할 때만 로드됩니다.
스캔 자체가 실제 비용입니다: Quick은 ~50k 토큰, Standard는 ~150–300k 토큰입니다. 따라서 모드가 조용히 선택되는 대신 숫자와 함께 제공되는 이유입니다.

참조 파일

references/search-playbook.md — 제품 유형별 표면 (소프트웨어, 물리적 제품, 브랜드, 서비스), 쿼리 패턴, 불만 및 유통 채굴
references/verdict-rubric.md — 빌드 / 좁혀서 빌드 / 래핑 / 포크 / 기존 사용 / 재구성 중 선택
references/no-search-fallback.md — 웹 접근 권한 없이 정직한 스캔 실행하기
assets/LANDSCAPE-template.md — 보고서 구조

피해야 할 실패 모드

리스트 기사 세탁. "X를 위한 상위 10가지 도구" 페이지는 제휴 SEO 콘텐츠이며, 종종 죽거나 관련 없는 제품을 나열합니다. 후보 이름을 얻는 데만 사용하고, 증거로 사용하지 마십시오.
큰 이름 채우기. Google, Amazon, Notion을 틈새 아이디어의 경쟁자로 나열하는 것은 노이즈입니다. 특정 기능이 실제로 중복되는 경우에만 기존 업체를 포함하십시오.
조용한 생략. 단순히 검색되지 않았을 때 그룹이 부재하다고 제시하지 마십시오. 3단계를 참조하십시오.
스캔 확장. 이것은 빌드 전 확인입니다. Standard 스캔 20분 후에는 멈추고 전달하십시오.
양에 의한 낙담. 긴 경쟁자 목록은 "신경 쓰지 마"로 읽힙니다. 그렇지 않을 때도요. 개수보다 격차와 판결로 시작하십시오.
오래된 것을 살아있는 것처럼. 3년간 손대지 않은 것은 무덤이지 경쟁이 아닙니다. 표시하십시오.
추천 이탈. 사용자를 유료 리서치 도구로 안내하지 마십시오. 대신 쿼리를 제공하십시오.

Is There A? (이미 존재하는 것 확인)