search-first

검색 우선 스킬 개요

검색 우선이란

search-first 스킬은 코드를 직접 작성하기 전에 기존 도구, 라이브러리, 구현 패턴을 먼저 찾아보는 “조사 후 코딩” 워크플로입니다. 추측부터 하는 개발자가 아니라, 신중하게 길을 탐색하는 정찰병처럼 어시스턴트가 움직이길 원할 때 유용합니다.

누가 사용해야 하나

새 기능을 시작하거나, 의존성을 검토하거나, 통합을 추가하거나, 이미 존재할 수도 있는 보조 기능을 만들 때 search-first 스킬을 사용하세요. 검증된 패턴을 새로 발명하기보다 재사용하고 싶을 때는 search-first for Skill Scaffolding 활용 사례에 특히 잘 맞습니다.

왜 중요한가

핵심 가치는 의사결정의 질에 있습니다. 이 스킬은 코드를 추천하기 전에 npm, PyPI, GitHub, 웹 소스, 관련 스킬까지 넓게 검색하도록 유도합니다. 그 결과 중복 작업을 줄이고, 의존성 선택의 정확도를 높이며, “직접 만들기 vs 채택하기 vs 감싸서 쓰기” 판단을 더 설득력 있게 만들어 줍니다.

검색 우선 스킬 사용법

설치하고 실행하기

search-first install을 하려면 npx skills add affaan-m/everything-claude-code --skill search-first로 스킬을 추가하세요. 작업이 “X를 추가해 줘”, “Y에 쓸 라이브러리를 찾아줘”, “이걸 더 나은 방식으로 이미 할 수 있나?”처럼 들릴 때 실행하면 됩니다. search-first usage 패턴은 구현보다 먼저 조사를 요청할 때 가장 잘 작동합니다.

결정형 브리프로 요청하기

약한 브리프는 “파일 파서를 만들어 줘”입니다. 더 강한 브리프는 이렇게 씁니다: “Node 18용 TypeScript 파일 파서가 필요합니다. 스트리밍을 지원해야 하고, 네이티브 의존성은 없어야 하며, MIT 라이선스를 우선합니다. adopt-or-build 옵션 3개와 각각의 트레이드오프를 보고 싶습니다.” 이런 형식은 스킬이 맥락을 충분히 이해하고, 후보를 비교하면서 검색할 수 있게 해 줍니다. 막연한 제안만 내놓는 결과를 줄이는 데도 도움이 됩니다.

먼저 읽어야 할 파일

먼저 SKILL.md를 보고, 그다음 README.md, AGENTS.md, metadata.json을 확인하세요. rules/, resources/, references/, scripts/ 폴더가 있다면 그것들도 살펴보면 좋습니다. 이 저장소에서는 SKILL.md가 주요 기준 문서이므로, 불필요하게 지원 파일을 뒤지지 않고 빠르게 진행할 수 있습니다.

워크플로를 프롬프트 템플릿으로 쓰기

실용적인 search-first guide 프롬프트는 필요사항, 제약조건, 후보 검색, 평가 기준, 명확한 결론을 모두 요청해야 합니다. 예를 들어: “X에 대한 기존 옵션을 조사하고, 3개 후보를 비교해 유지보수성, 문서, 라이선스, 적합성 기준으로 점수화한 뒤, adopt/extend/build custom 중 무엇이 맞는지 추천해 주세요.” 이런 구조는 리서치 에이전트가 느슨한 목록이 아니라 실제로 쓸 수 있는 결과를 내도록 돕습니다.

검색 우선 스킬 FAQ

검색 우선은 대규모 프로젝트에서만 유용한가?

아닙니다. 오히려 작은 작업에서 더 가치가 큰 경우가 많습니다. 작은 헬퍼 함수, UI 유틸리티, 의존성 선택처럼 조용히 기술 부채를 만들 수 있는 작업이 대표적입니다. 단순해 보이는 변경일수록 조사 생략의 비용이 커지기 쉽습니다.

일반 프롬프트와 무엇이 다른가?

일반 프롬프트는 아이디어를 물을 수 있지만, search-first skill은 연구 워크플로와 의사결정을 요구합니다. 이 차이가 중요한 이유는, 출력물이 단순히 “무엇을 코딩할 수 있나”를 말하는 것이 아니라 채택 판단을 뒷받침하도록 설계되어 있기 때문입니다.

초보자도 쓰기 쉬운가?

네, 목표와 제약을 설명할 수 있다면 충분히 사용할 수 있습니다. 초보자에게 특히 좋은 이유는 검색 범위를 좁혀 주고, 미처 찾지 못했을 기존 옵션을 드러내 주기 때문입니다. 다만 트레이드오프 분석 없이 바로 코드를 받고 싶다면 도움이 덜 될 수 있습니다.

언제는 사용하지 말아야 하나?

작업이 분명히 커스텀이어야 하거나, 시간이 매우 촉박하거나, 코드베이스 안에서만 국한되어 외부 솔루션이 현실적으로 맞지 않을 때는 건너뛰세요. 이미 정확히 원하는 패키지나 패턴을 알고 있다면, 전체 검색보다 바로 구현하는 편이 더 빠를 수 있습니다.

검색 우선 스킬 개선 방법

검색을 바꾸는 제약조건을 먼저 제시하기

가장 큰 품질 향상은 처음부터 하드 제약을 명시하는 데서 나옵니다. 언어, 런타임, 프레임워크, 라이선스, 번들 크기, 보안 규칙, 플랫폼 제한, 네이티브 의존성 허용 여부를 분명히 적으세요. 이런 정보가 있어야 스킬이 단순히 인기 있는 후보가 아니라 실제로 쓸 수 있는 후보만 추려낼 수 있습니다.

추천만 말고 비교를 요청하기

더 나은 search-first usage 요청은 짧은 후보군과 그 이유가 포함된 추천을 요구합니다. 예를 들어: “라이브러리 3개를 비교하고, 각각이 어떤 이유로 실패할 수 있는지 설명한 뒤, 프로덕션용 1개와 대안 1개를 골라 주세요.” 이렇게 해야 이름 하나만 던져 주는 답보다 훨씬 실행 가능한 조사 결과를 얻을 수 있습니다.

얄팍한 새로움 편향을 경계하기

자주 있는 실패 패턴은 가장 새롭거나 가장 눈에 띄는 프로젝트를 고르면서 유지보수성, 문서, 통합 비용을 확인하지 않는 것입니다. search-first skill을 개선하려면 채택 마찰, 생태계 적합성, 그리고 후보를 탈락시킬 조건이 무엇인지까지 포함해 달라고 요청하세요.

첫 결과 뒤에 한 번 더 다듬기

첫 결과가 너무 넓다면, 다음 프롬프트에서 빠진 제약 하나나 수용 테스트 하나만 더 구체화하세요. search-first for Skill Scaffolding의 경우라면 대상 언어, 저장소 구조, 혹은 재사용하려는 스캐폴드의 정확한 형태를 추가하는 식입니다.