Kiro나 Cursor, Claude Code와 같은 AI 코딩 툴을 사용하다 보면, 이런 상황에 직면하지 않나요?

• "CDK는 1파일 1책임(Single Responsibility)으로 작성해"라고 매번 말하는 것이 번거롭다
• 사내 문서가 수백 개나 되는데, 프롬프트(Prompt)에 전부 넣을 수 없다
• "이번 달 AWS 비용이 얼마야?"라고 묻고 싶지만, 실시간 값은 파일에 적혀 있지 않다

저는 2026년 초부터 AI 코딩 툴(주로 Kiro)을 본격적으로 사용하기 시작했고, 처음 몇 달 동안은 계속해서 "프롬프트 작성법"을 고민했습니다.

하지만 해나가면서, 프롬프트의 고민보다 애초에 "어떻게 지식을 전달할 것인가"의 설계가 훨씬 더 중요한 것 아닌가? 라는 생각이 들었습니다.

시행착오 끝에 도달한 것이 MCP · RAG · 컨텍스트(Context) 세 가지를 상황에 따라 구분하여 사용하는 방법이었습니다.

이 기사에서는 세 가지 방식의 차이점 · 판단 흐름 · 조합 패턴을 제 리포지토리(Repository)의 실례와 함께 정리합니다.

먼저 결론입니다. AI 코딩 툴에서 실무적으로 자주 사용하는, 추론 시 지식을 전달하는 방법은 크게 세 가지가 있습니다.

"전부 프롬프트에 넣으면 되지 않을까?"라고 생각할 수도 있지만, 컨텍스트 윈도우(Context Window)에는 상한이 있습니다.

2026년 현재, 주요 모델은 수십만 토큰 급을 다룰 수 있지만, 그럼에도 수백~수천 개의 파일 문서를 전부 싣는 것은 현실적이지 않으며, 실시간 정보(비용, 로그, 가동 상황)는 애초에 파일에 적혀 있지 않기 때문에 각각을 구분해서 사용해야 합니다.

엄밀히 말하면, RAG의 검색 결과도 MCP의 취득 결과도 최종적으로는 컨텍스트 윈도우에 실리게 됩니다. 즉, 세 가지는 완전히 병렬적인 관계가 아니라 "컨텍스트에 싣는 방식의 차이"입니다. 이 기사에서는 "정보를 어떻게 준비해서 LLM에 전달할 것인가"라는 관점에서 분류하고 있습니다.

파일의 내용을 그대로 프롬프트에 넣습니다. (검색도 벡터화(Vectorization)도 하지 않습니다.)

각 툴에서의 명칭은 다르지만, 하고 있는 일은 같습니다.

다른 방법과 비교했을 때 가장 참조되기 쉽습니다. 지연(Latency) 제로 - 설정 불필요. Markdown 파일을 두기만 하면 됨

• 버전 관리 가능 (Git 관리 하에 둘 수 있음)

• 컨텍스트 윈도우에 상한이 있음 (모델에 따라 다르지만 수십만 토큰 급이라도 유한함)

• 파일 수가 늘어나면 전부 실을 수 없음

• 코딩 규약 · 설계 방침 (수십 개 파일 이내)

• 매번 확실하게 참조해주길 바라는 규칙

• "이 기법으로 작성해", "이 프로필을 사용해"와 같은 제약

컨텍스트에 넣은 정보는 다른 방식과 비교했을 때 가장 참조되기 쉽지만, 너무 많이 넣으면 오히려 노이즈(Noise)가 됩니다. 컨텍스트 길이 초과나 지시 사항의 충돌도 발생할 수 있으므로, "적지만 중요한 정보"로 압축하는 것이 요령입니다.

문서를 사전에 청크(Chunk) 분할 → 벡터화 → 저장합니다.

질문이 들어오면 유사도 검색을 통해 관련 청크만 전달합니다.

최근에는 벡터 검색뿐만 아니라, 키워드 검색(BM25)과 조합한 하이브리드 검색(Hybrid Search)이나, 리랭커(Reranker)로 검색 결과를 재정렬하는 구성도 일반적입니다. 정밀도를 높이고 싶다면 이 부분도 검토해 보세요.

• 대량의 문서 (수백~수만 건)에서 필요한 부분만 뽑아낼 수 있음

• 컨텍스트 상한을 신경 쓰지 않아도 됨

• 사용자가 자연어로 질문할 수 있음

검색 정밀도에 의존합니다 (관련 청크를 놓치면 답변할 수 없음) - 인프라 비용이 발생함 (벡터 스토어, Embedding API)

• 설정에 공수가 들어감 (청크 전략, 인덱스 설계)

• 사내 문서 검색 봇 (FAQ, 규정집, 절차서)

• 수백~수천 페이지의 기술 문서에서 답변 생성

• "그 절차서 어디 있었지"를 해결하는 채팅 UI

LLM이 "지금 이 순간에" 외부 툴을 호출하여 실시간 데이터를 취득합니다.

MCP는 어디까지나 외부 툴과의 접속 규격이며, 툴 자체를 의미하는 것이 아닙니다.

"LLM이 외부의 API나 툴을 호출하기 위한 공통 프로토콜"이라고 이해하면 쉽습니다.

• 항상 최신 정보를 가져올 수 있음 (정적 파일로는 불가능)

• '검색'뿐만 아니라 '액션 (Action)'도 가능 (DB 업데이트, 티켓 생성, 파일 조작)

• 원격 서버라면 OAuth 2.1 기반의 표준적인 인가 (Authorization) 플로우를 따를 수 있음

• 레이턴시 (Latency)가 발생함 (API 호출 왕복 시간)

• 툴 측의 장애에 영향을 받음

• MCP 서버의 설계 및 인증 설정이 필요함

• 실시간 정보 (AWS 비용, 가동 상황, 로그)

• CRUD 조작을 LLM이 대행하게 하고 싶을 때 (Notion 업데이트, 티켓 생성)

• 외부 시스템과의 연동 (GitHub, Slack, DB)

• 공식 문서 검색 (항상 최신 버전을 참조하고 싶을 때)

"어떤 방식을 사용해야 하는가"를 5초 만에 결정할 수 있는 플로우차트를 만들었습니다.

실무에서는 하나만 사용하는 경우는 거의 없습니다. 조합해서 사용하는 것이 일반적입니다.

규칙 파일: "AWS CLI는 --profile verification을 붙여라"
↓ 규칙으로서 항상 적용
MCP: 실제로 AWS 명령어를 실행
...

규칙은 정적으로 전달하고, 실행은 실시간으로 수행하는 패턴입니다. 제 리포지토리에서는 이 패턴이 가장 많습니다.

RAG: 사내 문서에서 "이 절차로 대응"을 검색
↓ 답변 생성
MCP: 답변 내용을 Slack에 게시 / Notion에 티켓 생성

"조사하고 → 실행한다"의 2단계입니다. 인시던트 대응 봇 등에서 사용할 수 있는 구성입니다.

규칙 파일: "답변은 불렛 포인트 3줄 이내로. 참고 URL을 반드시 첨부할 것"
↓ 포맷 지정
RAG: 벡터 스토어 (Vector Store)에서 관련 정보를 가져와 답변 생성
...

출력 포맷이나 답변 톤을 컨텍스트로 제어하고, 정보 취득은 RAG에 맡기는 패턴입니다.

제가 걸어온 길을 시계열로 되돌아보면 다음과 같습니다.

가장 큰 배움은 "어느 하나로 모든 것을 해결하려고 하지 마라"는 것이었습니다.

• "RAG로 전부 가능하다" → 저도 학습 테마로 구축해 보았습니다만, 개인 개발의 지식 관리 정도라면 컨텍스트 + MCP로 충분히 돌아갑니다. RAG가 빛을 발하는 곳은 사내 문서가 수백~수천 건에 달하는 조직적 이용 상황입니다.
• "컨텍스트에 전부 넣는다" → 수백 개의 파일은 물리적으로 불가능합니다.
• "MCP는 만능이다" → 정적인 규칙을 굳이 API로 가져올 이유가 없습니다.

적재적소. 각각에 특화된 상황이 있습니다.

AI 코딩 툴에서 실무적으로 자주 사용하는, 추론 시 지식을 전달하는 방법은 크게 3가지입니다.

• 컨텍스트 (Context): 소량으로 확실하게 매번 참조시키고 싶은 규칙 → 규칙 파일 (CLAUDE.md / .cursor/rules 등)
• RAG: 대량의 문서에서 필요한 부분만 검색 → Bedrock KB / OpenSearch
• MCP: 실시간 정보 취득 및 외부 시스템으로의 액션 → MCP 서버

판단 기준은 심플합니다:

• 실시간 or 액션 → MCP
• 소량 + 매번 필요 → 컨텍스트 (Context)
• 대량 + 검색 필요 → RAG

그리고 실무에서는 이것들을 조합해서 사용합니다. "컨텍스트로 규칙을 전달하고, MCP로 실행하며, RAG로 과거의 지견을 끌어온다". 이 3층 구조가 저의 2026년 상반기 AI 활용의 도달점입니다.

AI 툴은 "무엇을 물어보는가"뿐만 아니라 "어떻게 지식을 전달하는가"에 따라 출력의 질이 크게 달라집니다. 아직 "매번 프롬프트에 직접 입력"하고 계신 분이라면, 우선 규칙 파일 하나를 만드는 것부터 시작해 보세요. 그것만으로도 경험이 달라질 것입니다.