이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
AI 에이전트가 원하는 결과를 내지 못하는 원인은 모델 자체뿐 아니라 어떤 데이터와 규칙을 Context로 제공하는지에 있습니다. Context Architecture는 접근 가능한 정보의 범위, 행동 규칙, 예외 처리, 작업 메모리, 사람의 검증 절차를 함께 설계해 bicycle tires와 car tires를 혼동하거나 낮은 신뢰도의 지식으로 행동하는 문제를 줄입니다. RAG는 데이터를 저장·검색·전달하는 Infrastructure와 이를 구현하는 Engineering, 전체 시스템의 설계 원칙인 Architecture가 결합된 형태이며, 인덱싱·태깅·Vector search·재정렬로 필요한 Context를 단계적으로 좁힙니다. 원천 권한과 Scopes를 검색·저장 단계에 적용하면 에이전트가 사용자보다 넓은 데이터에 접근하지 못하고, 적절한 Context 구조는 결과의 일관성뿐 아니라 토큰 비용까지 낮춥니다.
섹션별 상세
Context Architecture는 AI 에이전트 주변에 어떤 정보를 제공하고 어떤 행동을 허용할지 함께 설계하는 개념입니다. 에이전트가 모든 로그나 데이터에 접근하는 대신 문제 해결에 필요한 특정 로그와 규칙만 사용하도록 범위를 제한하고, 막혔을 때 수행할 절차까지 정해 모호한 판단을 줄입니다. Context Infrastructure가 Context를 저장·검색·전달하는 기반이라면, Architecture는 왜 그런 구조를 선택하는지 정하고 Engineering은 이를 .NET, Python, Rust 같은 언어와 알고리즘으로 구현하는 단계입니다.
근거
- Context Architecture는 에이전트가 접근할 정보와 행동 범위를 제한해 예측 가능한 결과를 만들고, 막혔을 때의 처리 절차까지 정한다. — Doug Whitley와 Ash Zade의 Context Architecture 정의 및 car tires 사례
RAG는 Context Infrastructure, Architecture, Engineering이 동시에 결합되는 사례입니다. 인덱싱과 Context store가 자료를 저장하고 검색 가능한 형태로 만들며, 구현 코드는 질문에 맞는 자료를 찾아 LLM이나 ML 모델에 전달하고, 전체 시스템은 어떤 Context를 어떤 순서로 제공할지에 관한 설계 원칙을 따릅니다. MCP는 요구사항이 정의된 프로토콜이라는 점에서 Architecture에 가깝지만, 어떤 언어로 구현하고 어떤 서버 기능과 클라이언트를 지원할지는 Engineering과 설계의 선택으로 남습니다.
근거
- RAG는 Context Infrastructure, Architecture, Engineering의 세 측면을 모두 포함하며 MCP는 정의된 프로토콜로서 Architecture에 가깝다. — RAG와 MCP의 Infrastructure·Architecture·Engineering 구분 대화
Context Architecture는 에이전트가 car tires를 찾아야 할 때 bicycle이나 airplane tires까지 가져오는 검색 범위의 이탈을 막습니다. 접근 가능한 지식 자체를 car tires 또는 sports car tires로 제한하고, 이전에 확인한 sports car·van·truck tire 정보를 메모리에 저장해 다음 작업에서 이어 쓰며, 여러 에이전트가 참여할 때도 작업 이력과 생성 지식을 유지합니다. 이 구조는 프롬프트에만 의존하는 Guardrail보다 데이터 접근 범위와 기억할 내용을 직접 통제해 예측 가능한 결과를 만드는 데 초점을 둡니다.
안전한 에이전트는 정보의 신뢰도와 사람의 검증 절차를 Context Architecture 안에 포함합니다. Stack Internal은 지식에 High, Medium, Low Trust Score를 부여하고 Medium 또는 Low인 자료를 Subject Matter Expert validation flow로 보내며, 사용자가 불완전하거나 잘못된 지식에 대해 직접 판단하도록 에이전트가 임의로 행동하지 못하게 합니다. 검색 과정에서는 질문과 업무 흐름을 기준으로 인덱싱, 태깅, Vector search, Context mapping, 재정렬을 여러 단계 적용해 넓게 수집한 자료에서 필요한 종류와 품질의 Context만 남깁니다.
근거
- Stack Internal은 Medium 또는 Low Trust Score의 지식을 Subject Matter Expert validation flow로 보내 Human-in-the-Loop 검증을 수행한다. — Stack Internal의 Trust System과 Subject Matter Expert validation flow 설명
데이터 접근 권한은 원천 시스템의 권한을 에이전트에 상속하고, Scopes로 그보다 좁은 업무 범위를 다시 지정하는 두 층 구조로 관리됩니다. 사용자가 비공개 Slack 채널에 접근할 수 없으면 에이전트도 접근할 수 없으며, 사용자가 접근할 수 있더라도 특정 제품 영역만 허용하도록 Scope를 설정해 지식의 검색 범위를 줄일 수 있습니다. 에이전트가 새로 만든 지식을 일반 지식 풀이나 팀에 공유하지 않고 사용자에게 먼저 보내도록 저장 단계에도 제한을 적용할 수 있어, 검색뿐 아니라 Context 생성과 재주입까지 통제됩니다.
근거
- 원천 시스템 권한은 에이전트에 상속되고 Scopes를 통해 사용자가 접근 가능한 지식 중 더 좁은 범위를 지정할 수 있다. — Slack 권한 상속과 Scopes를 통한 검색·저장 범위 제한 설명
좋은 Context Architecture의 기준은 특정 모델에 종속되지 않으면서 사용자와 모델에 일관되고 예측 가능한 결과를 제공하는지에 있습니다. 검색 범위를 전체 도서관에서 자동차 관련 책, 타이어 관련 페이지, sports car의 타이어와 PSI 문단으로 좁히면 불필요한 검색과 토큰 사용을 줄이고 필요한 정보를 더 빠르게 전달할 수 있습니다. 동시에 구조가 지나치게 좁으면 wheelbarrow tires 같은 다른 업무를 car tires로 오인할 수 있으므로, 사용 사례에 맞는 범위와 새로운 Context를 보완하는 유연성을 함께 확보해야 합니다.
근거
- Context를 좁히는 여러 검색·필터링 단계는 불필요한 정보와 토큰 사용을 줄이며 결과의 일관성과 예측 가능성을 높인다. — 인덱싱, 태깅, Vector search, 재정렬과 도서관·그물 비유
Context Architecture를 직접 구축하는 일은 데이터 수집과 인덱싱만으로 끝나지 않고 충돌·불완전·오류 정보의 판별과 우선순위 결정까지 포함합니다. Slack, MS Teams, Google Drive, SharePoint, Confluence, GitHub, Jira처럼 여러 시스템에 흩어진 자료를 한데 모으면 서로 다른 답변이 생길 수 있으므로, 충돌을 식별하고 어떤 자료를 신뢰할지 정하는 정책과 운영 경험이 필요합니다. 구매 방식은 이런 기술 구현뿐 아니라 다양한 고객의 Edge Case와 Trust·Conflict 문제를 축적한 지식을 활용한다는 이점이 있고, 반대로 고유한 사용 사례와 통제 요구가 있으면 직접 구축할 이유도 남습니다.
용어 해설
- Context Architecture
- — AI 에이전트가 참고하고 행동할 정보의 범위, 우선순위, 제약 조건, 예외 처리 방식을 설계하는 구조입니다. 필요한 데이터만 검색하도록 범위를 좁히고, 신뢰도가 낮은 정보에는 검증 절차를 연결해 결과의 예측 가능성과 안전성을 높입니다.
- Context Infrastructure
- — AI 에이전트에 Context를 저장하고 검색해 전달하는 기술적 기반입니다. Context library, 인덱싱, Context store, Vector search처럼 데이터를 보관하고 질의에 맞는 정보를 꺼내는 구성 요소가 포함되며, 에이전트가 문제 해결에 필요한 자료를 실제로 받게 합니다.
- Context Engineering
- — 설계한 Context 구조를 실제 시스템과 코드로 구현하는 작업입니다. RAG를 어떤 언어와 알고리즘으로 만들지, 데이터를 어떻게 인덱싱하고 재정렬할지 결정하며, 추상적인 설계를 작동하는 검색·전달 과정으로 바꿉니다.
- 에이전트 메모리(Agentic Memory)
- — AI 에이전트가 이전 작업, 학습한 내용, 대화, 생성한 결과를 저장하고 다음 작업에서 다시 활용하는 기능입니다. 여러 단계의 업무나 여러 에이전트가 협업할 때 작업 이력을 유지해 같은 내용을 반복하지 않고 진행 중인 목표를 이어갈 수 있게 합니다.
- Human-in-the-Loop
- — AI 에이전트가 불완전하거나 신뢰도가 낮은 정보에 직면했을 때 사람의 판단과 검증을 작업 흐름에 포함하는 방식입니다. 에이전트가 임의로 결론을 내리지 않고 Subject Matter Expert에게 확인을 요청하게 해 오류가 있는 지식에 기반한 행동을 막습니다.
- 신뢰도 점수(Trust Score)
- — 지식이나 검색 결과의 신뢰 수준을 High, Medium, Low처럼 평가하는 기준입니다. 점수가 Medium 또는 Low인 정보에는 추가 검증 흐름을 적용해 에이전트가 불완전하거나 잘못된 자료를 확정된 사실처럼 사용하지 않도록 통제합니다.
기술
- Context Architecture
- Context Infrastructure
- Context Engineering
- RAG
- MCP
- .NET
- Python
- Rust
- Stack Internal
- Codex
- Slack
- MS Teams
- Google Drive
- SharePoint
- Confluence
- GitHub
- Jira
- Vector search
활용 사례
- AI 코딩 에이전트의 지식 검색
- 제품 영역별 업무 지원
- 불완전한 지식에 대한 전문가 검증
- 여러 AI 에이전트의 작업 이력 관리
- 기업 내부 데이터 검색과 지식 생성
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 15.수집 2026. 08. 15.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
