research

research skill 개요

research skill이 하는 일

research skill은 기술, 개념, 혹은 복잡한 주제를 이해하기 위한 구조화된 딥 리서치 워크플로입니다. 계획과 실행을 하나의 모호한 프롬프트로 뭉개지 않고 분리해 진행한다는 점이 핵심입니다. 하나의 에이전트에게 어떻게 조사할지 결정하는 일과 실제로 조사하는 일을 동시에 맡기는 대신, 이 스킬은 작업을 계획 단계와 실행 단계로 나눕니다. 이 설계 자체가 이 스킬을 설치할 가장 큰 이유입니다.

어떤 사용자가 research skill을 써야 하나요

이 research skill은 소프트웨어 아키텍처, 프로토콜, 학술 개념, 낯선 시스템처럼 탐색 대상이 복잡한 주제를 반복 가능한 방식으로 조사해야 하는 사용자에게 가장 잘 맞습니다. 특히 전체 리서치를 시작하기 전에 범위를 통제하고, 질문을 정리하고, 중간 검토를 거치고 싶을 때 유용합니다. research for Academic Research, 기술 실사, 개념 맵핑 같은 작업에서는 이런 추가 계획 단계가 단순한 “X를 설명해줘” 식의 범용 프롬프트보다 훨씬 더 큰 가치를 주는 경우가 많습니다.

이 research skill이 해결해 주는 실제 작업

이 스킬이 해결하는 진짜 일은 단순히 “요약 생성”이 아닙니다. 실제로는 주제를 정의하고, 필요한 맥락을 식별하고, 조사 전략을 만들고, 사용자 승인에서 한 번 멈춘 뒤, 새 맥락과 더 명확한 경계 안에서 실행하는 것입니다. 이렇게 하면 조사 방향이 흐려지거나, 표면적으로만 다루거나, 잘못된 방향에 토큰을 낭비하는 일을 줄일 수 있습니다.

도입 전에 봐야 할 핵심 판단 포인트

이 스킬은 저장소 구조 자체는 매우 가볍습니다. 실질적으로 중요한 로직은 거의 전부 SKILL.md에 들어 있습니다. 참고할 만한 헬퍼 스크립트, 레퍼런스 파일, 설치 메타데이터가 따로 없기 때문에, 실제 성공 여부는 사용 중인 에이전트 런타임이 계획 에이전트, 오케스트레이터, 실행 에이전트로 이어지는 의도된 멀티 에이전트 흐름을 지원하는지에 달려 있습니다. 한 번에 바로 답을 받는 방식을 원한다면, 이 research skill은 필요 이상으로 느리게 느껴질 수 있습니다.

research skill 사용 방법

설치 판단 시 먼저 볼 파일과 확인 포인트

이번 research install 판단에서는 EN/.agents/skills/research/SKILL.md부터 보는 것이 좋습니다. 이 파일에 실제 워크플로, 입력값, 오케스트레이션 동작이 들어 있습니다. 저장소상 근거를 보면 스킬 자체에 전용 설치 명령은 보이지 않으므로, 사용 중인 에이전트 플랫폼이 지원하는 방식으로 스킬을 로드한 다음 런타임이 아래를 수행할 수 있는지 확인해야 합니다.

• /research 호출
• planning agent 생성
• 확인을 위해 일시 중지
• plan file path를 넘겨 execution agent 생성

환경이 에이전트 간 작업을 깔끔하게 넘기지 못한다면, research skill의 핵심 가치는 크게 떨어집니다.

research skill에 필요한 입력

최소한 주제는 제공해야 합니다. 다만 아래 정보를 함께 주면 결과가 훨씬 좋아집니다.

• 정확히 어떤 결정을 내려야 하는지
• 원하는 깊이 수준
• 시간, 대상 독자, 사전 지식 같은 제약
• 프로젝트 맥락 또는 도메인 정보

약한 입력:
/research OAuth2

더 강한 입력:
/research Research OAuth2 for a backend team migrating from session auth. Focus on grant types still relevant in 2025, common implementation mistakes, security tradeoffs, and what to recommend for internal APIs vs third-party integrations.

research for Academic Research 용도라면, 연구 질문, 학문 분야, 기대하는 엄밀성 수준, 출력 형식까지 포함하는 것이 좋습니다.
/research Investigate retrieval-augmented generation evaluation methods for academic literature review. Compare offline metrics, human evaluation, and benchmark design. I need a structured brief with terminology, core debates, and a shortlist of methods worth deeper reading.

실전에서 바로 쓰는 research 사용 워크플로

좋은 research usage 패턴은 다음과 같습니다.

1. 범위가 잡힌 주제와 원하는 결과를 넣어 /research를 호출합니다.
2. planning agent가 맥락을 파악하고 plan file을 만들도록 둡니다.
3. 실행 전에 계획을 검토합니다. 이 단계에서 잘못된 독자 설정, 빠진 질문, 지나치게 넓은 범위를 잡아낼 수 있습니다.
4. 계획이 내 의도와 맞을 때만 실행을 승인합니다.
5. 최종 노트를 1차 지도로 활용한 뒤, अस्पष्ट한 부분에 대해서는 더 좁은 후속 리서치 사이클을 돌립니다.

이 검토 게이트가 일반 프롬프팅과 비교했을 때 가장 실질적인 차별점입니다. 계획이 약하면 실행 결과도 대체로 약해집니다.

잘 작동하게 만드는 프롬프트 작성법

계획을 세우기 쉬운 형태로 프롬프트를 쓰는 것이 좋습니다.

• Topic: 무엇을 조사하는지
• Goal: 어떤 결정이나 이해가 필요한지
• Scope: 무엇을 포함하고 무엇을 제외할지
• Audience: 초보자, 실무자, 연구자, 리더십
• Output: 비교, 브리핑, 노트, 권고안

예시:
/research Topic: consistent hashing. Goal: explain it well enough to choose whether to use it in a distributed cache design. Scope: core mechanism, failure cases, virtual nodes, operational tradeoffs; exclude heavy math proofs. Audience: senior engineers. Output: decision-oriented research notes.

research skill FAQ

리서치할 때 일반 프롬프트보다 더 낫나요?

대체로 그렇습니다. 특히 주제가 넓거나, 모호하거나, 결정 중심일 때 차이가 큽니다. 일반 프롬프트는 계획, 가정, 답변 생성을 한 번에 섞어 처리하는 경우가 많습니다. 반면 research skill은 먼저 계획을 명시적으로 만들게 하므로 범위 설정이 좋아지고, 최종 출력도 더 신뢰하기 쉬워집니다.

언제는 research skill을 쓰지 않는 편이 좋나요?

빠른 사실 확인, 단순한 정의, 혹은 이미 정확한 하위 질문을 알고 있는 작업이라면 굳이 쓸 필요가 없습니다. 검토 단계가 필요하지 않다면 2단계 흐름 자체가 오버헤드가 될 수 있습니다. 또한 에이전트 시스템이 하위 에이전트를 안정적으로 조정하지 못하는 환경이라면 적합성이 떨어집니다.

초보자에게도 맞나요?

맞습니다. 다만 초보자도 주제만이 아니라 목표를 설명할 수 있어야 합니다. “Kubernetes를 가르쳐줘”는 너무 넓습니다. “내부 서비스 하나를 배포할 수 있고 흔한 아키텍처 실수를 피할 정도로 Kubernetes를 이해하게 도와줘”가 훨씬 낫습니다. 이 스킬이 도움은 되지만, 좋은 스코프 설정 자체를 대신해 주지는 않습니다.

Academic Research 워크플로에도 맞나요?

질문 프레이밍과 종합 단계에서는 research for Academic Research를 충분히 지원할 수 있습니다. 특히 용어 정리, 쟁점 맵핑, 하위 주제 구조화에 강점이 있습니다. 다만 별도의 시스템이 그 단계를 보완해주지 않는 한, 이를 정식 문헌 검토 방법론, 출처 검증, 인용 관리, 혹은 도메인별 증거 기준의 대체재로 보면 안 됩니다.

research skill 개선 방법

실행 승인 전에 계획부터 다듬으세요

가장 큰 효과를 내는 개선 포인트는 최종 노트보다 계획 자체를 비판적으로 보는 것입니다. 아래 항목을 확인해 보세요.

• 내가 실제로 내려야 하는 결정에 답하고 있는지
• 배경 설명과 실행 가능한 질문이 분리되어 있는지
• 범위가 지나치게 넓지 않은지
• 내 독자와 제약을 제대로 반영했는지

계획이 너무 일반적이라면, 실행 전에 더 좁은 각도로 다시 잡아 달라고 요청하세요.

더 좋은 research 결과를 위해 입력을 강화하세요

research skill은 결정 맥락이 들어갈수록 더 잘 작동합니다. 특히 아래 정보가 유용합니다.

• 이미 알고 있는 것
• 무엇이 헷갈리는지
• 다음 단계에서 어떤 결과가 필요한지
• 어디까지를 “충분히 좋다”고 볼 것인지

예를 들어 “접근법을 비교해줘”보다 “소규모 팀 환경에서 유지보수성, 마이그레이션 리스크, 운영 복잡도 기준으로 접근법을 비교해줘”가 훨씬 낫습니다.

자주 생기는 실패 패턴을 주의하세요

흔한 문제는 지나치게 넓은 주제, 불명확한 대상 독자, 그리고 “모든 것을 전수 조사해줘” 식의 요청입니다. 또 다른 실패 패턴은 스킬이 프로젝트 맥락을 알아서 정확히 추론할 것이라고 기대하는 것입니다. 주제가 실제 코드베이스, 아키텍처, 혹은 학습 과정과 연결되어 있다면 그 사실을 명시적으로 적어야 합니다. 이 스킬의 구조가 도움은 되지만, 빠진 의도까지 복구해 주지는 못합니다.

첫 번째 결과 이후 한 번 더 돌리세요

첫 실행은 지도를 그리는 단계로 보는 것이 좋습니다. 그다음 정말 중요한 부분, 예를 들어 논쟁이 있는 트레이드오프, 이해하기 어려운 개념, 혹은 특정 의사결정 분기만 골라 두 번째 research guide 사이클을 돌리세요. 보통 한 번의 거대한 요청보다, 좁은 범위의 연속적인 리서치 실행이 더 좋은 결과를 냅니다. 이렇게 해야 이 research skill을 일회성 프롬프트가 아니라 믿고 반복해서 쓸 수 있는 워크플로로 만들 수 있습니다.