---
category: Unified
tags: [auto-wikified, technical-documentation]
title: LLM 기반 컨텍스트 추출 (LLM-based Context Extraction)
description: "LLM 기반 컨텍스트 추출은 단순한 코드의 실행 의미(What)를 넘어, 해당 코드가 왜 작성되었고(Why) 전체 아키텍처에서 어떤 역할을 하는지 파악하기 위해 관련 자연어 아티팩트 및 구조적 정보를 추출하여 대규모 언어 모델(LLM)에 제공하는 과정입니다 [1,..."
last_updated: 2026-05-02
---

# LLM 기반 컨텍스트 추출 (LLM-based Context Extraction)

## 📌 Brief Summary
LLM 기반 컨텍스트 추출은 단순한 코드의 실행 의미(What)를 넘어, 해당 코드가 왜 작성되었고(Why) 전체 아키텍처에서 어떤 역할을 하는지 파악하기 위해 관련 자연어 아티팩트 및 구조적 정보를 추출하여 대규모 언어 모델(LLM)에 제공하는 과정입니다 [1, 2]. 이를 위해 GitHub의 풀 리퀘스트(PR) 설명, 이슈 토론, 커밋 메시지, 종속성 맵 등 코드베이스 내외부의 지식을 추출하고 구조화합니다 [2, 3]. 이 과정은 MCP(Model Context Protocol)와 같은 표준을 통해 동적으로 이루어지며, 추출된 문맥은 환각(Hallucination)을 필터링하는 검증 단계를 거쳐 개발자의 코드 리뷰 및 레거시 코드 온보딩을 돕는 통찰력으로 제공됩니다 [4-6].

## 📖 Core Content
**컨텍스트 추출의 필요성**
* 현대 소프트웨어 시스템은 매우 복잡하며, 기존의 LLM 및 코드 분석 도구들은 광범위한 소프트웨어 엔지니어링 문맥(예: 아키텍처 결정, 기술적 부채, 비즈니스 요구사항)이 부족하여 새로운 문제나 시스템의 전체상을 설명하는 데 한계를 보입니다 [1, 7]. 
* 분산 시스템이나 대규모 코드베이스에서 통합 실패를 방지하고 아키텍처의 버그를 식별하려면 여러 저장소(Cross-repository)에 걸친 컨텍스트 및 종속성 추출이 필수적입니다 [8, 9].

**주요 추출 소스 (Artifacts)**
* 시스템은 소스 코드 자체뿐만 아니라 버전 관리 및 이슈 트래커에 존재하는 풍부한 자연어(NL) 아티팩트를 활용합니다 [2]. 
* 주요 소스에는 커밋 메시지, PR 설명, 이슈 및 관련 토론 내용, 위키(Wiki), README 파일, 데이터베이스 스키마 및 티켓 시스템(예: Jira)의 기록이 포함됩니다 [2, 10].

**컨텍스트 추출 및 구조화 파이프라인 (Context Builder)**
* **데이터 수집 및 계층화:** GraphQL API 등을 사용하여 코드 스니펫과 관련된 커밋 내역을 역추적하고, 연관된 PR 및 이슈를 식별하여 계층적 데이터 구조로 조직화합니다 [11-13].
* **노이즈 제거 및 필터링 (Filtering):** 이모지만 있거나 형식이 잘못된 본문을 제거하고, 상용구(Boilerplate) 텍스트를 정규식으로 삭제하여 LLM에 전달될 신호 대 잡음비를 극대화합니다 [14, 15].
* **프롬프트화 (LLM-ready Structuring):** 추출된 데이터를 하이퍼텍스트 태그와 들여쓰기를 활용해 직렬화하여, LLM이 아티팩트 간의 관계를 명확히 참조할 수 있는 구조화된 문맥(Context)으로 변환합니다 [15, 16].

**구현 방식 및 프로토콜 (MCP 통합)**
* 컨텍스트 추출 도구는 MCP(Model Context Protocol) 서버의 형태로 구현될 수 있습니다 [4, 17].
* 이를 통해 LLM(예: Claude)은 단순한 텍스트 봇을 넘어, 개발자의 로컬 환경이나 외부 API를 호출하여 저장소 읽기, PR 세부 정보 확인, 커밋 기록 조회 등을 직접 수행하는 에이전트로 작동합니다 [18, 19].

**결과 검증 (LLM-as-a-Judge)**
* 추출된 컨텍스트를 기반으로 생성된 설명이 환각(Hallucination)을 포함하지 않는지 실시간으로 평가하는 '검증기(Validator)'가 필요합니다 [20, 21].
* 검증 과정은 단일 프롬프트가 아닌, '주장(Claims) 나열'과 '컨텍스트 기반 근거 확인'이라는 다단계(Multi-step) 구조로 분리할 때 가장 높은 정확도와 낮은 오탐율(False positive)을 달성합니다 [22-24].

## ⚖️ Trade-offs & Caveats
* **토큰 한계 및 정보 잘림 현상 (Token Limits and Truncation):** PR이나 이슈의 설명이 너무 길 경우 LLM의 컨텍스트 창(Context Window)을 초과할 수 있으므로, 필수적으로 텍스트 길이 제한 및 요약 기술을 적용해야 하며 이로 인해 일부 세부 정보가 유실될 수 있습니다 [14].
* **성능 및 확장성 병목 (Performance & Scalability Issues):** 20년 이상의 코드 이력, 수십 개의 PR 및 이슈가 연결된 코드를 분석할 때는 API 속도 제한과 네트워크 병목으로 인해 컨텍스트 추출에 1분 이상이 소요될 수 있습니다 [25]. 또한 40만 개 이상의 파일이 있는 대규모 시스템의 경우 초기 인덱싱에 2~4시간이 걸릴 수 있습니다 [26].
* **대형 변경 사항 처리의 한계 (Large Diffs Limitation):** 추출 메커니즘을 사용하더라도 한 번의 PR이 50개 이상의 파일을 건드리는 대규모 변경 사항인 경우, LLM이 문맥을 완전히 유지하는 데 어려움을 겪으므로 개발자가 특정 부분에 대한 명확한 질문으로 범위를 좁혀야 하는 수동 개입이 필요합니다 [27].
* **환각에 대한 지속적 위험 (Hallucination Risks):** LLM은 명시된 컨텍스트가 주어지더라도 리소스를 '분석'하는 코드를 '프로비저닝'하는 코드로 잘못 설명하는 등의 환각을 생성할 수 있습니다 [28]. 따라서 정적 분석이나 LLM-as-a-Judge와 같은 추가 검증 파이프라인 없이는 신뢰성을 담보하기 어렵습니다 [29, 30].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처/기반 기술]
- [[Model Context Protocol (MCP)]]
  - 연결 이유: LLM이 코드를 복사-붙여넣기 하는 대신, 외부 도구(GitHub 등)에 접근해 저장소와 PR 정보를 직접 구조화된 형태로 가져오는 표준 인터페이스입니다 [4, 18].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: LLM이 정적인 한계를 벗어나 어떻게 실시간으로 코드베이스의 컨텍스트(파일, 브랜치, 커밋 등)를 수집하고 통합하는지 구체적인 워크플로우를 이해할 수 있습니다 [19, 31].

- [[LLM-as-a-Judge (LaaJ)]]
  - 연결 이유: 컨텍스트를 기반으로 LLM이 생성한 코드 설명이나 통찰력이 실제 사실에 부합하는지(Groundedness) 다른 LLM을 사용하여 판별하는 평가 체계입니다 [5, 21].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드 분석 도구가 생성하는 결과물의 신뢰성을 보장하기 위해 도입하는 다단계 프롬프트 설계(Multi-step evaluation)와 환각(Hallucination) 필터링 기법을 배울 수 있습니다 [22, 23].

#### [분석 대상/소스]
- [[GitHub 아티팩트 (GitHub Artifacts)]]
  - 연결 이유: LLM이 코드를 깊게 이해하기 위해 참조해야 하는 PR, 커밋 메시지, 이슈 트래커 기록 등 핵심 자연어 컨텍스트의 출처입니다 [1, 2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 버전 관리 시스템의 이력 데이터가 어떻게 아키텍처의 의사 결정, 기술적 부채, 비즈니스 요구사항 등의 암묵적 지식을 명시적으로 제공하는지 파악할 수 있습니다 [2, 32].

### Deeper Research Questions
- 수십만 개의 파일을 가진 엔터프라이즈 모노레포(Monorepo)에서 LLM의 토큰 한계를 피하면서 가장 관련성 높은 아티팩트만 선별적으로 추출하는 임베딩 및 인덱싱 최적화 방법은 무엇인가? [14, 26]
- GitHub GraphQL API를 이용해 커밋, PR, 이슈를 계층적으로 횡단 추출할 때, 속도 제한(Rate Limits)을 회피하고 쿼리 레이턴시를 최소화하기 위한 페이징 및 배치 처리 기법은 무엇인가? [12, 25]
- LLM-as-a-Judge (LaaJ) 모델을 구현할 때, 평가 프로세스를 '주장 추출(Claim enumeration)'과 '검증'으로 분리하는 것이 거짓 환각(False Hallucination) 탐지율을 낮추는 구체적인 원리는 무엇인가? [23, 24, 33]
- PR에서 50개 이상의 파일이 변경된 대규모 Diff 환경에서, LLM이 문맥 상실 없이 효과적으로 코드 리뷰를 수행하도록 컨텍스트를 분할(Chunking)하여 주입하는 아키텍처 패턴은 무엇인가? [27]
- 코드 분석 AI가 정적 분석(AST 등) 정보와 아티팩트 기반 자연어 컨텍스트를 결합하여 답변을 생성할 때, 둘 간의 충돌하는 정보를 조율하는 모델 라우팅 및 결정 전략은 어떻게 구현되는가? [9, 34]

### Practical Application Contexts
- **Implementation:** MCP(Model Context Protocol) 서버를 로컬에 띄워 GitHub의 저장소 도구(Repository tools) 및 PR 도구를 활성화하고, Claude와 같은 LLM과 연결하여 IDE나 터미널에서 즉각적인 코드 리뷰 시스템을 구현합니다 [17, 18, 31].
- **System Design:** 컨텍스트 추출기(Context Builder), 요약기(Summarizer), 판별기(Validator)로 이어지는 3단계 파이프라인을 설계하여, 추출된 문서의 노이즈를 제거하고 환각이 없는 안전한 지식만 개발자에게 서빙하는 아키텍처를 구성합니다 [35, 36].
- **Operation / Maintenance:** 오래된 레거시 코드를 수정해야 할 때, 이 도구를 사용하여 해당 코드를 도입하게 된 과거의 PR과 이슈 배경을 요약받고 기존 로직의 제약 사항을 파악함으로써 예기치 못한 회귀(Regression) 오류를 방지합니다 [6, 32].
- **Learning Path:** 대규모 코드베이스에 처음 투입된 신규 개발자가 "이 서비스의 진입점은 어디인가?", "왜 이 데이터베이스 모델을 선택했는가?" 등과 같은 구조적 질문을 던지고 맥락화된 통찰을 얻는 가상 멘토링/온보딩 도구로 활용합니다 [6, 30].
- **My Project Relevance:** 방대한 문서와 히스토리가 흩어져 있는 프로젝트에서 개발자가 일일이 Git Blame과 PR을 뒤지는 수동 탐색 시간을 줄이고, 시스템 구조와 의도를 빠르게 추적하여 '코드베이스 읽기 지식'을 심층적으로 습득하는 데 직접적으로 기여합니다.

### Adjacent Topics
- [[검색 증강 생성 (RAG, Retrieval-Augmented Generation)]]
  - 확장 방향: 소스 코드 자체와 외부 문서, 시스템 로그 등을 벡터 데이터베이스화하여 LLM의 맥락을 동적으로 확장하는 범용 지식 검색 아키텍처로 조사를 확장할 수 있습니다 [37, 38].
- [[추상 구문 트리 (AST, Abstract Syntax Tree) 분석]]
  - 확장 방향: 자연어 아티팩트를 통한 문맥적 이해와 병행하여, 소스 코드의 컴파일 구조와 의존성을 정밀하게 역추적하는 정적 분석의 핵심 기반 기술을 탐구할 수 있습니다 [30, 34].

---
*Last updated: 2026-05-02*