search-first — 짜기 전에 찾는다

바퀴 재발명 방지 워크플로. 커스텀 코드는 검색이 빈손일 때의 마지막 선택지다.

발동 시점

• 기존 솔루션이 있을 법한 새 기능/유틸/헬퍼를 만들려는 순간
• 의존성·통합(외부 API, 파서, 클라이언트 등) 추가 직전
• "X 기능 추가해줘" 요청을 받고 바로 코드를 쓰려는 순간

검색 순서 (안쪽 → 바깥쪽)

순서	채널	방법
1	이 레포 안	rg 로 관련 모듈/테스트 스윕 — 이미 있는데 못 본 것일 수 있음
2	사내 미러	<your-git-host>/mirrors/ 그룹 먼저 (OSS agents/skills/아이콘 등 미러). 외부 원본 직접 참조 대신 미러로 들여와서 사용. 미러 그룹이 없으면 건너뜀
3	패키지 레지스트리	npm / PyPI / crates.io 등 프로젝트 스택에 맞는 곳
4	MCP / 스킬	이미 연결된 MCP 서버가 그 기능을 제공하는지, .claude/skills/ 에 같은 스킬이 있는지
5	GitHub / 웹	유지보수되는 OSS 구현체·템플릿 검색. 채택 시 mirrors 로 포크해서 사용

채널이 사용 불가(오프라인, 인증 없음 등)면 조용히 건너뛰지 말고 어느 채널을 못 봤는지 명시한다.

평가 → 결정

후보는 기능 적합도 / 유지보수 상태(최근 커밋·이슈 응답) / 라이선스 / 의존성 무게로 평가.

신호	결정
정확히 맞음 + 관리 잘됨 + MIT/Apache	채택 — 설치해서 그대로 사용
부분 일치 + 좋은 기반	확장 — 설치 + 얇은 래퍼
약한 후보 여러 개	조합 — 작은 패키지 2~3개 결합
쓸 만한 게 없음	직접 구현 — 단, 검색에서 본 설계를 참고해서

비trivial 기능이면 서브에이전트로

Agent(subagent_type="general-purpose", model="sonnet", prompt="
  다음 기능의 기존 솔루션 조사: [설명]
  언어/프레임워크: [스택], 제약: [있으면]
  검색: 레포 내부 → 사내 미러(<your-git-host>/mirrors) → npm/PyPI → MCP → GitHub
  리턴: 후보 비교표 + 채택/확장/직접구현 권고
")

안티패턴

• 코드 직행: 검색 없이 유틸부터 작성
• 미러 무시: GitHub 원본을 바로 참조 (내부 미러로 들여온 뒤 사용이 원칙)
• 조용한 스킵: 검색 채널이 죽어 있었는데 "없음"으로 보고
• 과도한 래핑: 라이브러리를 두껍게 감싸 장점을 죽임
• 의존성 비대: 작은 기능 하나에 거대 패키지 도입