AI 에이전트를 업무에 도입한 기업들이 공통으로 맞닥뜨리는 문제가 있습니다. 사내 문서를 벡터 DB에 쏟아붓고 RAG(검색 증강 생성) 환경을 구축해도, 에이전트가 ‘경력직이라면 당연히 알 법한’ 판단을 내리지 못한다는 것입니다.
“결제 모듈을 긴급 배포할 때는 테스트를 통과했더라도 반드시 보안팀의 담당 파트장에게 슬랙 사전 알림을 보내야 한다”거나 “외부 프리랜서가 참여하는 프로젝트의 클라우드 테스트 환경은 별도의 리소스 할당 기준이 적용된다” 같은 맥락 — 즉 시스템에 명문화되지 않은 암묵지(Tacit Knowledge)가 빠져 있기 때문입니다.
이 글에서는 에이전트가 실무자의 파편화된 암묵지를 어떻게 수집하고, 이를 기계가 이해할 수 있는 구조화된 스펙(Spec)으로 변환하며, 엔터프라이즈 환경에서 안전하게 통제할 수 있는지 그 아키텍처의 핵심을 짚어봅니다.
왜 RAG만으로는 부족한가 — 암묵지의 본질
문서화된 지식에는 명확한 한계가 있습니다. 사내 위키나 매뉴얼을 아무리 정교하게 인덱싱해도, 실무자의 머릿속에만 존재하는 ‘업무 노하우’나 엣지 케이스 대처법은 검색되지 않습니다. 철학자 폴라니(Michael Polanyi)의 유명한 역설 — “우리는 말할 수 있는 것보다 더 많이 안다” — 이 바로 이 상황을 설명합니다.
암묵지가 구체적으로 기록되고 인코딩되는 순간, 비로소 기계가 일관되게 실행할 수 있는 절차적 지식(Procedural Knowledge) 및 SOP(표준운영절차)로 변환됩니다. 관건은 인간의 개입(Human Bottleneck) 없이 이 암묵지를 어떻게 끄집어내어 명확한 스펙으로 만드느냐에 있습니다.
에이전틱 워크플로우로 암묵지를 ‘자연스럽게’ 수집하기
실무자에게 “당신의 노하우를 문서화해 주세요”라고 요청하는 방식은 현업의 반발만 부를 뿐 지속 가능하지 않습니다. 발상을 전환해야 합니다.
- 에이전트에게 업무를 위임한다: 직원이 직접 코드를 짜거나 문서를 작성하는 대신, AI 에이전트에게 업무를 지시하게 만듭니다. 에이전트가 제대로 된 결과물을 내게 하기 위해, 실무자는 필연적으로 자신의 ‘의도와 맥락’을 상세히 설명하게 됩니다. 이 과정에서 암묵지가 자연스럽게 시스템에 기록됩니다.
- 프롬프트 로깅으로 지속 센싱: 사용자가 에이전트에게 어떤 지시와 피드백을 내리는지 로그를 수집하여 암묵지를 지속적으로 감지하고 개선하는 루프를 만듭니다.
- 지식의 PR (Pull Request): 코드 변경에 PR이 있듯, 지식 체계가 변경될 때도 AI가 변경점과 사유를 정리하여 ‘날리지 매니저(Knowledge Manager)’가 검토·반영하는 체계가 필요합니다.
핵심은 생산성 향상의 경험을 제공하는 것입니다. 에이전트에게 노하우를 전달할수록 내 업무가 폭발적으로 빨라지는 선순환을 경험하면, 실무자는 자발적으로 암묵지를 AI에게 학습시키기 시작합니다.
컨텍스트 그래프 — 단순한 지식 그래프를 넘어서
수집된 암묵지를 어디에, 어떤 형태로 저장해야 할까요? 여기서 컨텍스트 그래프(Context Graph)가 등장합니다. 기초적인 지식 모델이나 온톨로지를 정의하지 않고 무작정 데이터만 밀어 넣는 것은 AI 프로젝트 실패의 지름길입니다.
| 구분 | 지식 그래프(Knowledge Graph) | 컨텍스트 그래프(Context Graph) |
|---|---|---|
| 저장 대상 | 사실(Fact) — “A 모듈은 B DB를 참조한다” | 사실 + 관계 + 메타데이터 |
| 시간 차원 | 현재 스냅샷 | 시간적 유효성(Temporal Validity) 포함 |
| 출처 추적 | 없음 또는 약함 | 출처(Provenance)와 신뢰도 점수 내장 |
| 의사결정 기록 | 미지원 | Decision Traces로 ‘왜’ ‘어떻게’ 결정됐는지 기록 |
실무 적용 Case: 암묵지는 어떻게 저장되고 충돌을 해결하는가?
Case 1. 긴급 배포 프로세스의 맥락화:
- 단순 지식 그래프: 배포 ↔ 슬랙 알림
- 컨텍스트 그래프: 배포 + 조건: 결제 모듈 + 상황: 긴급(Hotfix) + 수신자: 보안팀 특정 파트장 + 출처: 데브옵스 리드(신뢰도 95%). 에이전트는 이 맥락을 읽고 긴급 배포 스크립트 실행 전 알아서 올바른 수신자에게 알림 파이프라인을 구성합니다.
Case 2. 부서별 룰 충돌 (예: 클라우드 리소스 할당):
내부 개발팀의 인스턴스 무제한 생성 룰과 외부 인력의 리소스 제한 룰이 충돌할 때, 에이전트는 다음 기준으로 접근합니다.
- 팩트 체크: 폐기된 과거 권한 규정이나 잘못된 문서는 즉각 제거합니다.
- 맥락 태깅: 규정에 얽힌 화자, 소속, 계약 형태를 식별하여 요청자의 컨텍스트에 맞는 지식만 호출합니다.
- 조직 문화 (Human-in-the-loop): 완전히 충돌하는 엣지 케이스에서는 “우리 회사는 이런 예외 상황을 어떻게 처리해왔는가?”를 묻고, 관리자의 최종 판단을 새로운 디시전 트레이스(Decision Trace)로 그래프에 추가해 이후의 표준 스펙으로 삼습니다.
엔터프라이즈 컨트롤 플레인 — 지능과 통제의 분리
컨텍스트 그래프가 진정한 위력을 발휘하는 곳은 멀티 에이전트 환경의 거버넌스입니다. AI 모델(지능)이 스스로 규칙을 판단하게 두는 대신, 컨텍스트 그래프를 별도의 ‘컨트롤 플레인’으로 두어 에이전트를 강력하게 통제하는 하네스(Harness)를 구축해야 합니다.
- 제로 스탠딩 프리빌리지 (Zero Standing Privilege): 에이전트 자체는 기본 권한을 갖지 않습니다. 호출한 사람이나 상위 에이전트가 부여한 컨텍스트 내에서만 일시적 권한을 갖습니다.
- 토큰 교환 기반 위임 체인: OAuth 토큰 교환 방식으로 최초 사용자 → 에이전트 1 → 에이전트 2의 전체 호출 체인을 추적하여 권한을 상속하고 엄격하게 제한합니다.
- 동적 런타임 제어: 정적인 역할 기반 접근(RBAC)을 넘어, 사용자의 의도·데이터 민감도·환경 신호를 런타임에 동적으로 평가합니다.
실제 시스템에서는 같은 사내 챗봇을 사용하더라도, 데브옵스 엔지니어가 접속하면 인프라 프로비저닝 스크립트와 과거 장애 대응 이력을 참조하여 작업을 돕지만, 권한이 없는 일반 인턴 개발자가 동일한 인프라 제어를 요청하면 시스템이 토큰 체인을 통해 부서와 역할을 식별하고 즉각 접근을 차단합니다.
정리 — 명확한 스펙(Spec)과 하네스(Harness)의 구축
단순히 업무를 자동화하는 개별 프롬프트를 깎는 것을 넘어, 조직 전체의 판단 체계를 자산화하는 것이 AI 시대 기업의 핵심 경쟁력입니다.
| 단계 | 핵심 활동 |
|---|---|
| 1. 수집 | 에이전틱 워크를 통해 실무자의 암묵지를 자연스럽게 포착 |
| 2. 구조화 | 지식 모델을 먼저 정의하고, 컨텍스트 그래프로 인코딩 |
| 3. 유지보수 | 지식 PR + 팩트 체크 + 맥락 태깅으로 지속 관리 |
| 4. 거버넌스 | 컨트롤 플레인으로 분리하여 에이전트 동적 권한 제어 (Harness) |
에이전트가 진정으로 ‘우리 회사 방식’을 이해하고 오류 없이 움직이게 만드는 유일한 방법은, 실무자의 머릿속에 파편화된 암묵지를 명확한 컨텍스트 그래프 기반의 스펙(Spec)으로 치환하고, 에이전트가 그 한계를 절대 벗어나지 못하도록 정교한 하네스(Harness)를 엔지니어링하는 것입니다. 그것이 다가오는 AI 중심 비즈니스의 성패를 가를 것입니다.