RAG를 아직 고려하지 않는 팀을 위한 Skill 중심 가이드

사내 지식을 AI 코딩 어시스턴트에 연결할 때 가장 먼저 드는 고민은 "지금 RAG까지 해야 하나?"다. 많은 팀은 아직 RAG를 우선순위에 두지 않는다. 우리도 그랬다.

최근 회사에서 사내 문서 수십 개를 주제별로 요약해 Skill로 정리해 운영 중인데, 예상보다 잘 동작했다. 답변 일관성이 올라가고, 규칙 수정도 빠르게 반영됐다. 그 과정에서 "어디까지 Skill로 가고, 어디서 RAG가 필요해지는가"를 계속 판단하게 됐다.

Skill의 적용 맥락이 낯설다면, 먼저 Claude Code 플러그인 구조 — Agents, Commands, Skills 차이를 보고 오면 이 글의 비교 기준을 더 빠르게 이해할 수 있다.

이 글은 이런 독자를 위한 글

RAG를 아직 고려하지 않거나, 당장 도입 계획이 없는 팀
먼저 작게 시작해서 빠르게 효과를 보고 싶은 팀
"언제까지 Skill로 버티고, 언제 RAG로 넘어갈지" 기준이 필요한 팀

두 접근법의 본질적 차이

RAG와 Skill은 LLM에 지식을 제공한다는 목적은 같지만, 동작하는 추상화 레벨이 다르다.

먼저 용어를 짧게 정리하자.

RAG(Retrieval-Augmented Generation): 질문마다 외부 지식 저장소를 검색해서 관련 문서를 붙여 답변하는 방식
Skill: "이 작업은 이렇게 하라"는 절차/규칙을 미리 문서화해 필요한 순간에 불러오는 방식

	RAG	Skill
핵심 질문	"어떤 정보가 관련 있는가?"	"어떻게 행동해야 하는가?"
지식 유형	사실적 지식 (What)	절차적 지식 (How)
동작 방식	질문 → 검색 → 관련 청크 주입	태스크 감지 → 지시사항 주입
지식 선택	임베딩 유사도 + 리랭킹	LLM 추론 (의도 매칭)
컨텍스트 품질	검색 품질에 의존 (노이즈 가능)	큐레이션된 지시사항 (고품질)

Skill은 Claude가 어떻게 생각할지 를 바꾸고, RAG는 Claude가 무엇을 알지 를 바꾼다.

예를 들어:

"우리 팀은 에러 핸들링을 이렇게 한다" → Skill (행동 지침)
"이 API의 응답 스키마는 이렇게 생겼다" → Skill (범위가 작고 안정적인 참조)
"지난 3개월간 고객 문의 중 결제 관련 이슈 패턴" → RAG (대규모, 동적)

왜 RAG는 진입장벽이 높게 느껴질까

많은 팀이 RAG를 "검색 하나 붙이면 되는 기능"으로 생각하고 시작한다. 실제로는 검색 시스템을 새로 운영하는 일에 가깝다.

보통 아래 단계를 모두 설계해야 한다.

원문 수집 (어디서 가져올지, 어떤 주기로 갱신할지)
전처리/청킹 (문서를 어떤 단위로 쪼갤지)
임베딩 생성 (어떤 모델로 벡터화할지)
인덱싱/저장 (벡터 DB 구성, 버전 관리)
검색 품질 튜닝 (리랭킹, 필터링, 노이즈 제거)
평가/운영 (정확도 측정, 비용/지연시간 관리)

즉, "모델 설정"이 아니라 데이터 파이프라인 + 검색 품질 관리가 핵심 업무가 된다.

같은 문제를 Skill로 시작하면 출발점이 훨씬 단순하다.

항목	Skill	RAG
시작 준비물	마크다운 규칙 파일	수집/청킹/임베딩/인덱스 파이프라인
첫 결과 확인	작성 직후 바로 확인	파이프라인 구성 후 검증 필요
변경 반영	문서 수정 후 즉시 반영	재색인/재평가 과정 필요
운영 포인트	규칙 품질	검색 품질 + 데이터 신선도 + 인프라

그래서 실무에서는 보통 기본값을 Skill로 두고, 분명한 조건이 생길 때 RAG로 확장하는 편이 실패 확률이 낮다. RAG를 아직 고려하지 않는 팀이라면 이 순서가 특히 유효하다.

선택 기준 프레임워크

지식의 크기

Skill이 적합한 경우:

프로젝트 컨벤션, 아키텍처 결정문서 → 수천~수만 토큰
내부 API 문서 → Progressive Disclosure로 필요한 부분만 로딩
팀 워크플로우 → 단일 SKILL.md로 충분

RAG가 필요한 경우:

기업 전체 문서 코퍼스 → 수백만 건
고객 지원 아카이브 → 수만 건의 티켓
법률/의료 지식 베이스 → 수천 페이지의 규정

경계점은 컨텍스트 윈도우에 안정적으로 들어가고, 답변 품질이 유지되는가다. 일부 모델은 200K 토큰 전후에서도 태스크에 따라 성능 저하가 나타나고, 더 긴 컨텍스트를 지원하더라도 관련 정보가 묻히는 경우가 있다. 따라서 고정된 토큰 임계값보다, 전체 지식 크기와 별개로 한 태스크에 필요한 지식 크기를 기준으로 판단하는 편이 안전하다.

지식의 변경 빈도

변경 빈도	적합한 방식	이유
거의 변하지 않음	Skill	Git 커밋으로 충분
월 단위 변경	Skill	PR 리뷰 후 업데이트
주/일 단위 변경	RAG	자동 인덱싱 파이프라인 필요
실시간 변경	RAG + API	검색 시점의 최신 데이터 필요

코딩 컨벤션은 몇 달에 한 번 바뀐다. 아키텍처 결정은 더 드물게 변한다. 이런 안정적인 지식은 Skill이 매우 적합하다. 반면 고객 문의 데이터, 제품 카탈로그, 뉴스 피드처럼 매일 쌓이는 데이터는 RAG가 맞다.

지식의 구조

Skill이 유리한 지식:

의사결정 트리 ("A면 X, B면 Y")
단계별 절차 ("1. 먼저 테스트, 2. 빌드, 3. 배포")
규칙과 예외 ("항상 X하되, Y인 경우 Z")
코드 패턴과 안티패턴

이런 지식은 논리적 흐름이 중요하다. RAG에서는 긴 문서를 작은 조각(청크)으로 나눠서 검색하는데, 의사결정 트리처럼 "조건-예외-다음 단계"가 연결된 내용은 이 과정에서 쉽게 찢어진다. 예를 들어 "A면 X, 단 B면 예외로 Y"가 서로 다른 청크에 들어가면, 검색 시 한 조각만 불려와 예외 규칙을 놓치기 쉽다. 그러면 모델이 전체 흐름을 보지 못하고 부분 규칙만 따라 잘못 판단할 수 있다.

RAG가 유리한 지식:

개별적으로 독립된 항목 (FAQ, 이슈 티켓, 제품 설명)
키워드/시맨틱 검색이 필요한 비정형 텍스트
서로 다른 용어로 같은 개념을 설명하는 문서들

지식의 성장 방식

이 기준은 자주 간과되지만, 실제 운영에서 가장 큰 차이를 만든다.

Skill: 유기적 성장

Skill은 프로젝트와 함께 점진적으로 자란다. 처음에는 CLAUDE.md 10줄로 시작해서, 실수가 생길 때마다 규칙을 추가하고, 새 패턴이 정착되면 Skill 파일을 만든다. 피드백 루프가 짧다 — AI가 실수하면 그 자리에서 Skill을 수정하고, 다음 세션부터 바로 적용된다.

1주차: CLAUDE.md에 기본 빌드 명령어만
2주차: 에러 핸들링 규칙 Skill 추가 (AI가 throw new Error를 써서)
3주차: 배포 워크플로우 Skill 추가 (수동 배포 반복이 귀찮아서)
1개월: API 컨벤션 Skill 추가 (팀 코드리뷰에서 패턴 정립)
3개월: 10개 Skill이 팀의 암묵적 지식을 문서화

Claude Code의 Auto Memory 기능은 이 성장을 더 가속한다. Claude가 세션 중에 발견한 패턴이나 프로젝트 특성을 MEMORY.md에 자동으로 기록하고, 다음 세션에서 활용한다. AI가 스스로 지식을 축적하는 것이다.

RAG: 계획적 구축

RAG는 "먼저 문서를 넣고, 그 다음에 검색해서 쓴다"는 구조다. 지식을 추가하려면:

문서 작성
청킹 전략 결정
임베딩 생성
벡터 DB에 인덱싱
검색 품질 테스트

피드백 루프가 길다. "AI가 실수했으니 RAG 문서를 업데이트하자"는 결심에서 실제 반영까지 몇 시간~며칠이 걸릴 수 있다. 마찰이 크면 업데이트를 미루게 되고, 지식이 낙후된다.

반대로 Skill은 "규칙 한 줄 수정 → 즉시 재실행"이 가능하다.
이 짧은 수정 루프가 현업에서 체감되는 가장 큰 장점이다.

우리 팀도 사내 문서 수십 개를 그대로 붙여넣지 않고, 업무 단위로 요약해서 Skill에 넣었다. 이 방식은 문서 최신화와 리뷰 흐름을 Git 기반으로 관리하기 쉬웠고, 실제 운영에서 빠른 수정-재적용 사이클을 만드는 데 도움이 됐다.

핵심 차이:

	Skill	RAG
지식 추가 비용	마크다운 몇 줄 수정	문서 → 청킹 → 임베딩 → 인덱싱
피드백 루프	즉시 (같은 세션에서 수정 가능)	시간~일 (파이프라인 재실행)
자동 반영	Auto Memory 등으로 보완 가능	파이프라인 설계에 따라 자동화 가능
코드와의 동기화	같은 Git 저장소에서 공진화	별도 시스템, 괴리 발생 가능
지식의 버전 관리	Git 히스토리 = 지식의 진화 기록	별도 버전 관리 필요

Skill이 특히 빛나는 상황: 팀의 암묵지(Tacit Knowledge)를 명시적 지식으로 전환할 때. "이건 원래 이렇게 하는 거야"라고 말로만 전해지던 규칙이 Skill 파일로 문서화되면, 사람뿐 아니라 AI도 그 규칙을 따른다.

정확성 요구 수준

RAG는 검색된 원문에 근거하여 답변하므로, 출처 인용과 사실 검증이 가능하다. 규정 준수가 중요한 도메인(법률, 의료, 금융)에서는 이 인용 추적이 필수다.

Skill은 행동을 지시하지만, 그 지시가 올바른지를 외부 원천으로 검증하지는 않는다. Skill에 잘못된 정보가 있으면 모델이 확신에 찬 어조로 틀린 답을 줄 수 있다.

반드시 RAG로 가야 하는 경우

아래 조건 중 하나라도 강하게 해당하면, Skill만으로 버티기 어렵고 RAG가 사실상 필수다. 반대로 이 조건이 아직 아니라면 Skill 중심 운영으로 충분히 성과를 낼 수 있다.

문서 규모가 커서 수동 관리가 불가능할 때

수만~수백만 문서처럼 사람이 규칙 파일로 큐레이션할 수 없는 규모

데이터가 자주 바뀌어 최신성이 중요한 때

고객 문의, 상품 정보, 운영 지표처럼 하루 단위 이상으로 계속 변하는 데이터

근거 문서 제시(출처 추적)가 필수일 때

법률/의료/금융/감사 대응처럼 "어느 문서를 근거로 답했는가"를 보여줘야 하는 환경

질문 패턴이 매우 다양해서 키워드 매칭만으로 못 잡을 때

사용자 표현이 제각각이고 동의어/유사 표현 검색이 핵심인 경우

다수 시스템의 지식을 하나로 묶어 검색해야 할 때

위키, 티켓, 문서 저장소, DB를 통합 검색해야 하는 엔터프라이즈 환경

요약하면, 규모/최신성/근거성/다양성/통합성이 임계치를 넘으면 RAG로 가야 한다.

실전 비교: 같은 문제를 다른 방식으로

사례 1: 코딩 컨벤션 적용

RAG 방식:

코딩 가이드 문서를 청킹
임베딩 생성 → 벡터 DB 저장
코드 작성 시 관련 규칙 검색
검색된 청크를 컨텍스트에 주입

문제점: "에러 핸들링 규칙"이 3개의 청크에 걸쳐 있으면, 일부만 검색될 수 있다. 규칙 간 의존성이 깨진다.

Skill 방식:

---
name: error-handling
description: 에러 핸들링 컨벤션
---
## 원칙
- 비즈니스 에러는 커스텀 에러 클래스 사용
- HTTP 에러 응답은 항상 { code, message, details } 형태
- 예상 가능한 에러는 catch하여 적절한 상태 코드 반환
- 예상하지 못한 에러는 글로벌 핸들러에 위임
 
## 예시
// GOOD
throw new BusinessError("INSUFFICIENT_BALANCE", { required, current });
 
// BAD
throw new Error("잔액 부족");

장점: 규칙이 하나의 문서에 논리적으로 정리되어 있으므로, 모델이 전체 맥락을 이해한 상태로 코드를 작성한다.

사례 2: 대규모 API 문서 참조

Skill 방식으로 커버 가능한 경우:

내부 API가 20~30개 엔드포인트
API 문서가 수천 토큰 수준
Progressive Disclosure로 필요한 API만 로딩

RAG가 필요한 경우:

서드파티 API 문서 수백 페이지 (AWS, GCP SDK 등)
여러 API의 교차 참조가 필요
문서가 자주 업데이트됨

사례 3: 온보딩

Skill이 유리한 경우가 많다:

새 팀원(사람이든 AI든)에게 "우리 프로젝트가 어떻게 동작하는지" 알려주는 것은 전형적인 절차적 지식이다. CLAUDE.md 하나가 RAG 파이프라인 전체를 대체한다:

# 프로젝트 소개
- 패키지 매니저: bun
- 프레임워크: Next.js 16 (App Router)
- 스타일: Tailwind CSS v4
 
# 빌드 & 실행
bun dev      → 개발 서버
bun run build → 프로덕션 빌드
 
# 핵심 규칙
- 컴포넌트는 "@/components/"에서 임포트
- UI 문자열은 한국어
- 클라이언트 컴포넌트는 "use client" 필수

이 정보를 RAG로 처리한다면? 청킹 → 임베딩 → 저장 → 검색 → 주입 단계를 모두 운영해야 한다. 팀 규모가 작고 문서 범위가 제한적이라면 과한 설계가 될 수 있다.

컨텍스트 윈도우의 함정

"컨텍스트 윈도우가 커졌으니 RAG가 필요 없다"는 주장에는 중요한 반론이 있다.

컨텍스트 길이 ≠ 컨텍스트 품질

Stanford/Meta AI의 "Lost in the Middle" 연구(2023, TACL 2024 확장판)는 관련 정보가 컨텍스트 중간에 있을 때 성능이 양 끝 구간보다 떨어지는 경향을 보고했다. Databricks의 일부 실험에서도 긴 컨텍스트에서 모델 품질 저하가 관찰됐다. 100만 토큰을 지원한다고 해서 100만 토큰을 항상 채워 넣는 전략이 최선은 아니다.

문제점:

문맥 집중도 저하(Context Distraction): 관련 없는 정보가 많을수록 중요한 정보에 대한 주의가 분산된다
레이턴시 증가: 토큰이 많을수록 처리 시간이 늘어난다
비용 증가: 입력 토큰에 비례하여 API 비용 상승

RAG의 가치는 단순히 "큰 데이터를 다룬다"가 아니라, 관련성 높은 정보만 골라서 컨텍스트에 넣는다는 것이다. 이 필터링 기능은 컨텍스트 윈도우가 아무리 커져도 여전히 유효하다.

Skill의 Progressive Disclosure가 답

Skill 시스템은 이 문제를 Progressive Disclosure로 해결한다. 모든 지식을 한 번에 넣지 않고, 필요한 레벨의 정보만 단계적으로 로딩한다. 이것은 사실상 규칙 기반의 검색이다 — 임베딩 유사도 대신 LLM의 판단으로 관련성을 결정한다.

하이브리드 패턴: 둘 다 쓰기

가장 현실적인 접근은 Skill이 워크플로우를 정의하고, RAG(또는 외부 API)가 동적 데이터를 제공하는 구조다.

[Skill: 주간 제품 업데이트 작성]
  1. 이번 주 릴리즈 노트 조회 → MCP로 Notion API 호출
  2. 관련 고객 피드백 검색 → RAG 엔드포인트 호출
  3. 템플릿에 맞춰 보고서 작성 → Skill이 포맷 지정
  4. 리뷰어에게 전달 → Skill이 프로세스 정의

이 패턴에서:

Skill: 절차, 포맷, 규칙을 정의 (어떻게 할 것인가)
RAG/API: 동적 데이터를 제공 (무엇을 다룰 것인가)
MCP(Model Context Protocol): Skill과 외부 데이터 소스를 연결하는 다리

Claude Code에서는 MCP 서버를 통해 외부 데이터 소스에 접근하면서, Skill로 그 데이터를 어떻게 처리할지를 정의할 수 있다.

선택 가이드 요약

지식 유형	추천 방식	이유
코딩 컨벤션, 스타일 가이드	Skill	안정적, 큐레이션됨, 논리적 흐름 중요
아키텍처 결정	Skill + 참조 파일	필요 시 상세 문서 로딩
내부 API 문서 (소규모)	Skill	범위가 한정적
서드파티 API 문서 (대규모)	RAG 또는 MCP	규모가 크고 자주 변경
배포/운영 절차	Skill	전형적 절차적 지식
동적 비즈니스 데이터	RAG	매일 변경
대규모 문서 코퍼스 (>1M토큰)	RAG	컨텍스트에 안 들어감
온보딩/프로젝트 정체성	Skill (CLAUDE.md)	항상 필요, 안정적
규정 준수 지식	RAG	인용 추적 필수
워크플로우 + 동적 데이터	하이브리드	Skill이 절차, RAG가 데이터

핵심 질문 하나로 정리하면: "이 지식을 마크다운 규칙 파일로 계속 관리할 수 있는가?"

관리 가능하면 Skill, 관리 범위를 넘으면 RAG, 둘 다 필요하면 하이브리드다.

실무용 결론은 더 단순하다.

RAG를 아직 고려하지 않는 단계라면 먼저 Skill
반드시 검색 기반이어야 하면 RAG
절차는 Skill, 데이터는 RAG면 하이브리드

Skill이 특히 강점을 발휘하는 순간은 팀의 암묵적 지식을 명시적으로 만들 때다. "원래 이렇게 하는 거야"라고 말로만 전해지던 규칙이 Skill 파일 하나로 기록되면, 사람뿐 아니라 AI도 그 규칙을 따른다. 사내 문서 수십 개를 요약해 Skill로 운영해본 경험에서도, 초기 단계에서는 이 접근이 비용 대비 효과가 가장 컸다.