AWS Context에 대해 이야기하기 전에, AI 세계에서 '컨텍스트(context)'가 무엇을 의미하는지 먼저 이해해 봅시다.
AI 에이전트는 데이터에 접근하고 이를 처리할 수 있지만, 그것이 곧 데이터를 이해한다는 것을 의미할까요?
정보가 데이터베이스, 문서 및 다양한 애플리케이션에 분산되어 있는 조직을 가정해 보세요. AI 에이전트는 이러한 소스에서 기록을 검색할 수는 있습니다. 하지만 정보가 어떻게 연결되어 있는지 또는 어떤 비즈니스 규칙이 적용되는지 모른다면, 올바른 답변을 제공하는 데 어려움을 겪을 수 있습니다.
발표회에 참석한다고 생각해 보세요. 발표가 시작되기 전에 배경과 의제를 설명하는 간략한 브리핑을 받을 수도 있습니다. 이는 무엇이 논의될 것이며 왜 중요한지 이해하는 데 도움을 줍니다.
컨텍스트는 AI 에이전트에게 유사한 역할을 합니다. 이는 에이전트가 자신이 다루고 있는 것을 이해하고, 다양한 정보 조각들이 작업과 어떻게 관련되는지를 파악하는 데 도움이 되는 관련 정보를 제공합니다.
예를 들어, 클라우드 리소스 기록을 검색하는 것은 에이전트에게 해당 리소스가 존재한다는 사실만을 알려줍니다. 어떤 애플리케이션이 이 리소스를 사용하고 있는지, 어느 환경에 속해 있는지, 그리고 비용이 어떻게 할당되는지 아는 것은 에이전트가 그것에 대한 질문에 답할 수 있는 더 나은 기반을 제공합니다.
컨텍스트가 정확한 답변을 보장하는 것은 아니지만, 관련성 있고 신뢰할 수 있는 컨텍스트는 에이전트가 정보를 보다 효과적으로 해석하도록 도울 수 있습니다.
AWS Context란 무엇인가?
AWS Context는 기존 엔터프라이즈 데이터 전반에 걸쳐 관계를 발견하고 이를 지식 그래프(knowledge graph)로 표현하는 데 중점을 둡니다. 이는 AI 에이전트가 런타임(runtime) 시점에 관계, 비즈니스 규칙 및 도메인 지식에 접근할 수 있도록 돕습니다.
모든 기록을 고립된 정보 조각으로 취급하기보다는, 서로 다른 데이터 조각들 간의 연결성을 에이전트가 사용할 수 있도록 만드는 것이 핵심 아이디어입니다.
AWS는 2026년 6월 17일 AWS Summit New York City에서 이 서비스를 발표했습니다.
공식 AWS 발표문에서 Mai-Lan Tomsen Bukovec은 컨텍스트를 AI 에이전트를 위한 데이터 레이크(data lake)로 설명하며, 엔터프라이즈 지식을 AI 시스템에 활용할 수 있도록 하는 역할을 강조했습니다.
공식 AWS 발표 읽기.
2. AWS Context의 구성 요소 이해하기
AWS Context를 이해하려면, 기업 데이터를 AI 에이전트가 유용하게 활용할 수 있도록 만드는 주요 개념들을 살펴보는 것이 좋습니다.
2.1 관계 발견 (Relationship discovery)
조직들은 데이터베이스, 문서, 애플리케이션 등 다양한 곳에 정보를 저장하고 있습니다. 관계 발견은 이러한 여러 출처의 엔티티(개체)와 정보가 어떻게 연결되어 있는지 식별하는 데 도움을 줍니다.
일부 관계는 소스에서 직접 사용할 수 있지만, 다른 관계들은 추론이 필요할 수도 있습니다.
2.2 지식 그래프 (Knowledge graph)
지식 그래프는 엔티티를 노드(node)로, 그들 사이의 관계를 연결(connection)로 표현합니다.
예를 들어, 클라우드 환경에서 특정 애플리케이션은 컴퓨트 인스턴스에 의존할 수 있으며, 이 인스턴스는 스토리지 및 네트워킹 리소스와 연결되어 있습니다. 이러한 관계들을 표현하면 각 리소스를 개별적으로 보는 것이 아니라, 리소스들이 어떻게 연결되어 있는지 애플리케이션이 이해하는 데 도움이 됩니다.
2.3 비즈니스 규칙 및 도메인 지식 (Business rules and domain knowledge)
단순히 관계만으로는 데이터가 무엇을 의미하는지 항상 설명할 수 없습니다.
비즈니스 규칙과 도메인 지식은 AI 에이전트가 이러한 관계를 올바른 맥락에서 해석하는 데 도움을 주는 추가 정보를 제공합니다.
2.4 인간 검토 및 큐레이션 (Human review and curation)
자동으로 식별된 관계는 불완전하거나 부정확할 수 있습니다. 검토와 큐레이션은 관계를 검증하고, 실수를 수정하며, 정보의 품질을 향상시키는 데 도움을 줄 수 있습니다.
2.5 Context 검색 (Context retrieval)
AI 에이전트는 질문을 받았을 때 관련 정보를 검색할 방법이 필요합니다. Context 검색은 특정 작업을 수행하는 데 필요한 엔티티, 관계, 규칙들을 한데 모읍니다.
2.6 거버넌스 (Governance)
모든 사용자나 AI 에이전트가 모든 기업 정보에 접근해서는 안 됩니다. 거버넌스는 접근 권한을 강제하고 데이터 사용에 대한 적절한 통제를 유지하는 데 도움을 줍니다.
2.7 피드백 및 개선 (Feedback and refinement)
컨텍스트는 데이터와 비즈니스 요구사항이 변경됨에 따라 유용성을 유지해야 합니다. 검색 결과를 평가하고, 오류를 수정하며, 피드백을 검토하는 것은 시간이 지남에 따라 컨텍스트 품질을 개선하는 데 도움이 될 수 있습니다.
이러한 개념들은 컨텍스트 레이어(context layer)에 대해 생각할 수 있는 유용한 방식을 구성합니다. 개별 구성 요소의 정확한 구현 및 책임은 구축되는 시스템에 따라 달라집니다.
3. 이러한 구성 요소들은 어떻게 함께 작동하는가?
간단한 예시를 들어보겠습니다.
사용자가 AI 에이전트에게 다음과 같이 질문합니다: "왜 이 클라우드 리소스의 비용이 예상보다 많이 발생하고 있나요?"
리소스 기록만으로는 증가 원인을 설명할 수 없을 수도 있습니다. 에이전트는 또한 해당 리소스의 워크로드, 종속성(dependencies), 환경, 사용량 및 비용 할당에 대한 정보가 필요할 수 있습니다.
컨텍스트 레이어는 이러한 정보 조각들을 연결하는 역할을 합니다.
아키텍처 개요 (Architecture overview)
다음 다이어그램은 개념적인 컨텍스트 레이어 아키텍처를 보여줍니다. 이는 AWS의 공식 내부 구현을 나타내기 위함이 아니라 흐름(flow)을 설명하기 위한 것입니다.
AWS Context Flow Diagram
데이터 흐름 따라가기 (Following the data flow)
1. 정보 수집 및 관계 발견 (Collect information and discover relationships)
시스템은 기존 데이터 소스(data sources)와 상호작용하며 관련 엔티티(entities)와 관계를 식별합니다. 출처에 따라 관계는 명시적으로 제공될 수도 있고, 추론(inferred)되어야 할 수도 있습니다.
2. 지식 그래프 구축 및 풍부화 (Build and enrich the knowledge graph)
엔티티와 그 관계들은 그래프 형태로 표현됩니다. 비즈니스 규칙과 도메인 지식은 이러한 관계에 의미를 더합니다.
3. 관련 컨텍스트 검색 (Retrieve relevant context)
질문이 도착하면, 시스템은 관련된 엔티티, 관계 및 규칙들을 검색합니다. 접근 제어(Access controls)는 요청하는 에이전트가 어떤 정보를 사용할 수 있는지 결정합니다.
**4. 답변 또는 추천 생성 (Generate an answer or recommendation)
AI 에이전트는 검색된 컨텍스트를 사용하여 응답을 공식화합니다. 클라우드 비용에 대한 질문의 경우, 이는 종속성 및 비용 정보와 함께 리소스 사용량을 검토하는 것을 의미할 수 있습니다.
여전히 답변의 품질은 근본적인 데이터의 정확성과 에이전트의 추론 능력에 달려 있습니다. 지식 그래프(knowledge graph)는 컨텍스트를 제공하는 데 도움을 주지만, 올바른 답변을 보장하지는 않습니다.
핵심 아이디어: 각 레코드를 개별적으로 취급하는 대신, 컨텍스트 레이어는 애플리케이션이 필요로 할 때 관련 관계들을 사용할 수 있도록 합니다.
4. 어떤 기술을 사용할 수 있을까요?
기술은 애플리케이션이 지원해야 하는 데이터 유형, 관계 및 쿼리에 따라 달라집니다.
| 구성 요소 | 가능한 기술 |
|---|
| 데이터 통합 | API, AWS SDKs, ETL 파이프라인 |
| ... | |
| 항상 그래프 데이터베이스가 필요할까요? | |
아닙니다. 관계가 간단하고 데이터 모델이 이미 관계형인 경우 PostgreSQL만으로 충분할 수 있습니다. 복잡한 다단계(multi-hop) 관계 쿼리가 애플리케이션의 핵심인 경우에 한해 전용 그래프 솔루션을 고려하는 것이 가치가 생깁니다.
5. 오픈 소스 대안
컨텍스트 레이어를 실험하기 위해 완전 관리형 서비스로 시작할 필요는 없습니다.
무엇을 선택해야 할까요?
기존 관계형 데이터 모델을 사용하여 아이디어를 검증하고 싶다면 PostgreSQL부터 시작하세요. 그래프 순회(graph traversal) 또는 형식 온톨로지 모델링(formal ontology modelling)이 중요해지는 경우 Neo4j나 Apache Jena를 탐색해 보세요.
AWS에서 작동하는 레퍼런스 구현체를 원한다면, 모든 것을 처음부터 구축하기 전에 Context Ontology Accelerator를 살펴보는 것이 좋습니다.
6. 이 아키텍처를 어디에 사용할 수 있을까요?
컨텍스트 레이어(context layer)는 애플리케이션이 여러 데이터 소스 전반의 관계를 이해해야 할 때 유용합니다.
- AI 비서: 문서, 데이터베이스 및 내부 애플리케이션으로부터 정보를 연결합니다.
- 클라우드 운영: 사고 조사를 할 때 클라우드 리소스 간의 종속성을 파악합니다.
- 엔터프라이즈 검색: 단순히 키워드가 아닌 관계와 비즈니스 컨텍스트를 기반으로 정보를 검색합니다.
- 보안 분석: 잠재적 위험을 조사하기 위해 신원(identity), 리소스, 권한을 연결합니다.
이 아키텍처는 실제 정보 문제를 해결해야 합니다. 명확한 사용 사례 없이 지식 그래프를 추가하는 것은 불필요한 복잡성을 야기할 수 있습니다.
7. 이러한 아이디어를 클라우드 인텔리전스에 적용하기
이 아키텍처는 클라우드 인텔리전스 플랫폼에서도 잠재적인 응용 분야를 가집니다.
예를 들어, 클라우드 리소스가 왜 비싼지 이해하려면 월별 비용만 보는 것 이상을 요구할 수 있습니다. 다음 사항들을 고려해야 할 수도 있습니다:
- 리소스 구성 및 활용도(utilization).
- 다른 리소스와의 관계.
- 워크로드 및 환경.
- 비용 귀속(Cost attribution) 및 소유권.
- 잠재적인 최적화 기회.
TattvaLens에서는 리소스 검색, 관계, 그리고 최적화 통찰력과 관련된 클라우드 인텔리전스를 탐색하고 있습니다.
더 광범위한 엔지니어링 과제는 이러한 정보 조각들을 연결하여 추천 사항에 유용한 컨텍스트를 부여하는 것입니다.
8. 트레이드오프 및 한계점
컨텍스트 레이어 자체적으로도 고유의 엔지니어링 과제를 도입합니다.
- 데이터 품질(Data quality): 부정확하거나 오래된 출처 데이터는 오해를 불러일으키는 결론으로 이어질 수 있습니다.
- 관계 정확성(Relationship accuracy): 추론된 관계는 검증(validation)과 출처(provenance)가 필요합니다.
- 운영 복잡성(Operational complexity): 별도의 그래프 데이터베이스를 추가하는 것은 인프라 및 유지보수 오버헤드를 발생시킵니다.
- 접근 제어(Access control): 검색된 컨텍스트는 기존 권한을 존중해야 합니다.
- 비용 귀속(Cost attribution): 리소스 관계만으로는 공유 비용이 어떻게 할당되어야 하는지를 결정하지 못합니다.
- 평가(Evaluation): AI가 생성한 답변과 추천은 신뢰할 수 있는 증거를 기반으로 테스트해야 합니다.
요구 사항을 충족하는 가장 단순한 아키텍처부터 시작하십시오. 추가 구성 요소는 그 이점이 복잡성을 정당화할 때만 도입해야 합니다.
결론
AI 에이전트는 데이터 접근성 이상의 것을 필요로 합니다. 데이터를 해석하기 위해서는 관련 관계와 비즈니스 컨텍스트도 필요합니다.
AWS Context는 이 문제를 엔터프라이즈 수준에서 강조합니다. 동일한 아키텍처 아이디어는 클라우드 운영 및 비용 인텔리전스를 포함하여 다른 영역에도 적용될 수 있습니다.
흥미로운 엔지니어링 질문은 단순히 데이터를 더 많이 저장하는 방법이 아닙니다. 애플리케이션이 필요로 할 때 올바른 정보와 관계를 사용할 수 있도록 만드는 방법을 찾는 것입니다.
