| name | search-first |
| description | 코딩 전 리서치 워크플로우. 커스텀 코드를 작성하기 전에 기존 도구, 라이브러리 및 패턴을 검색합니다. "구현하기 전에 기존 솔루션을 검색하는" 접근 방식을 체계화합니다. 새 기능을 시작하거나 기능을 추가할 때 사용하세요.
|
| metadata | {"origin":"ECC"} |
/search-first — 코딩 전 리서치 (Research Before You Code)
"구현하기 전에 기존 솔루션을 검색하는" 워크플로우를 체계화합니다.
트리거 (Trigger)
다음과 같은 경우 이 스킬을 사용하세요:
- 기존 솔루션이 있을 법한 새 기능을 시작할 때
- 의존성(dependency) 또는 통합(integration)을 추가할 때
- 사용자가 "X 기능을 추가해줘"라고 요청하고 코드를 작성하려 할 때
- 새 유틸리티, 헬퍼 또는 추상화 계층을 만들기 전
워크플로우
┌─────────────────────────────────────────────┐
│ 1. 니즈 분석 (NEED ANALYSIS) │
│ 필요한 기능 정의 │
│ 언어/프레임워크 제약 사항 식별 │
├─────────────────────────────────────────────┤
│ 2. 병렬 검색 (리서처 에이전트) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ npm / │ │ MCP / │ │ GitHub / │ │
│ │ PyPI │ │ Skills │ │ Web │ │
│ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────┤
│ 3. 평가 (EVALUATE) │
│ 후보 점수 매기기 (기능, 유지보수, 커뮤니티,│
│ 문서, 라이선스, 의존성) │
├─────────────────────────────────────────────┤
│ 4. 결정 (DECIDE) │
│ ┌─────────┐ ┌──────────┐ ┌─────────┐ │
│ │ 채택 │ │ 확장 │ │ 자체 │ │
│ │ (Adopt) │ │ (Extend) │ │ 구축 │ │
│ └─────────┘ └──────────┘ └─────────┘ │
├─────────────────────────────────────────────┤
│ 5. 구현 (IMPLEMENT) │
│ 패키지 설치 / MCP 구성 / │
│ 최소한의 커스텀 코드 작성 │
└─────────────────────────────────────────────┘
결정 매트릭스 (Decision Matrix)
| 신호 (Signal) | 행동 (Action) |
|---|
| 정확히 일치, 유지보수 잘 됨, MIT/Apache 라이선스 | 채택 (Adopt) — 직접 설치 및 사용 |
| 부분적으로 일치, 좋은 토대 | 확장 (Extend) — 설치 + 얇은 래퍼(wrapper) 작성 |
| 여러 개의 약한 일치 항목들 | 구성 (Compose) — 2~3개의 작은 패키지 결합 |
| 적절한 항목을 찾지 못함 | 자체 구축 (Build) — 커스텀 코드를 작성하되, 리서치 결과 참고 |
사용 방법
퀵 모드 (Inline)
유틸리티를 작성하거나 기능을 추가하기 전에 다음 사항을 점검하세요:
- 저장소(repo)에 이미 존재하나요? → 관련 모듈/테스트를 먼저 검색하세요.
- 흔한 문제인가요? → npm/PyPI를 검색하세요.
- 이를 위한 MCP가 있나요? → MCP 구성을 확인하고 검색하세요.
- 이를 위한 스킬이 있나요? → 사용 가능한 스킬을 확인하세요.
- GitHub 구현체/템플릿이 있나요? → 완전히 새로운 코드를 작성하기 전에 유지보수되고 있는 OSS를 GitHub 코드 검색으로 찾아보세요.
풀 모드 (Subagent)
복잡한 기능의 경우, 리서치 전용 서브 에이전트에게 위임하세요:
다음 프롬프트로 서브 에이전트 호출:
"다음에 대한 기존 도구를 리서치해줘: [설명]
언어/프레임워크: [언어]
제약 사항: [제약 사항]
검색 대상: npm/PyPI, MCP 서버, 스킬, GitHub
결과: 추천이 포함된 구조화된 비교 리포트"
카테고리별 검색 단축키
개발 툴링
- 린팅(Linting) →
eslint, ruff, textlint, markdownlint
- 포매팅(Formatting) →
prettier, black, gofmt
- 테스트 →
jest, pytest, go test
- Pre-commit →
husky, lint-staged, pre-commit
AI/LLM 통합
- Claude SDK → 최신 문서를 확인하세요.
- 프롬프트 관리 → MCP 서버를 확인하세요.
- 문서 처리 →
unstructured, pdfplumber, mammoth
데이터 및 API
- HTTP 클라이언트 →
httpx (Python), ky/got (Node)
- 검증(Validation) →
zod (TS), pydantic (Python)
- 데이터베이스 → 먼저 MCP 서버를 확인하세요.
콘텐츠 및 퍼블리싱
- 마크다운 처리 →
remark, unified, markdown-it
- 이미지 최적화 →
sharp, imagemin
통합 포인트
플래너(Planner) 에이전트와 함께
플래너는 1단계(아키텍처 리뷰) 전에 리서처를 호출해야 합니다:
- 리서처가 사용 가능한 도구를 식별합니다.
- 플래너가 이를 구현 계획에 통합합니다.
- 계획 단계에서 "바퀴를 다시 발명하는" 것을 방지합니다.
아키텍트(Architect) 에이전트와 함께
아키텍트는 다음 사항에 대해 리서처와 상담해야 합니다:
- 기술 스택 결정
- 통합 패턴 발견
- 기존 참조 아키텍처
반복적 검색(Iterative-retrieval) 스킬과 함께
점진적인 발견을 위해 결합하세요:
- 1주기: 광범위한 검색 (npm, PyPI, MCP)
- 2주기: 상위 후보 상세 평가
- 3주기: 프로젝트 제약 조건과의 호환성 테스트
예시
예시 1: "데드 링크(Dead link) 체크 기능 추가"
니즈: 마크다운 파일의 깨진 링크 확인
검색: npm "markdown dead link checker"
발견: textlint-rule-no-dead-link (점수: 9/10)
행동: 채택 (ADOPT) — npm install textlint-rule-no-dead-link
결과: 커스텀 코드 0줄, 검증된 솔루션 사용
예시 2: "HTTP 클라이언트 래퍼 추가"
니즈: 재시도(retry) 및 타임아웃 처리가 포함된 회복 탄력성 있는 HTTP 클라이언트
검색: npm "http client retry", PyPI "httpx retry"
발견: got (Node) - retry 플러그인 포함, httpx (Python) - 기본 retry 포함
행동: 채택 (ADOPT) — retry 설정과 함께 got/httpx 직접 사용
결과: 커스텀 코드 0줄, 프로덕션 수준의 라이브러리 사용
예시 3: "설정 파일 린터 추가"
니즈: 스키마에 따라 프로젝트 설정 파일 검증
검색: npm "config linter schema", "json schema validator cli"
발견: ajv-cli (점수: 8/10)
행동: 채택 + 확장 (ADOPT + EXTEND) — ajv-cli 설치, 프로젝트별 스키마 작성
결과: 패키지 1개 + 스키마 파일 1개, 커스텀 검증 로직 없음
안티 패턴 (Anti-Patterns)
- 바로 코드부터 작성: 이미 존재하는 유틸리티가 있는지 확인하지 않고 작성하는 경우
- MCP 무시: MCP 서버가 이미 해당 기능을 제공하는지 확인하지 않는 경우
- 과도한 커스텀: 라이브러리를 너무 과하게 감싸서 이점을 잃는 경우
- 의존성 비대화: 작은 기능 하나를 위해 거대한 패키지를 설치하는 경우
이 스킬을 사용하는 시점
- 새 기능을 시작할 때
- 의존성 또는 통합을 추가할 때
- 유틸리티나 헬퍼를 작성하기 전
- 기술 선택을 평가할 때
- 아키텍처 결정을 계획할 때
