Context Graph는 에이전트 메모리가 아니라 작업 경계다

에이전트에 “메모리”를 붙인다고 곧바로 똑똑해지지 않는다. 장기 맥락이 필요한 시스템에서 중요한 것은 많이 기억하는 것이 아니라, 어떤 사실이 어떤 업무 경계 안에서 사용될 수 있는지 구조화하는 것이다. 그래서 Context Graph는 저장소 이름보다 작업 경계를 표현하는 모델에 가깝다.

두 그래프를 섞으면 설계가 흐려진다

에이전트 시스템에서 graph라는 말은 두 가지를 가리킬 수 있다. 하나는 실행 순서를 정하는 control graph다. 다른 하나는 사람, 회의, 문서, 결정, 프로젝트 사이의 관계를 담는 work graph다. 둘은 연결될 수 있지만 같은 것이 아니다.

flowchart TD
  input[회의·문서·화면 맥락] --> work[Work Graph]
  work --> control[Control Graph]
  control --> action[승인된 행동]
  action --> work
  control --> ask[불확실하면 질문]
  ask --> work

Work Graph는 “무엇이 무엇과 연결되어 있는가”를 설명한다. Control Graph는 “다음에 무엇을 실행해도 되는가”를 결정한다. 이 구분이 없으면 에이전트는 오래된 맥락을 근거로 외부 행동을 하거나, 실행 실패를 단순 기억으로 덮어버린다.

좋은 맥락은 관계와 권한을 함께 가진다

예를 들어 회의 후속 조치 에이전트를 생각해보자. 회의록에는 출시 결정, 담당자, 관련 문서, 슬랙 공유 대상이 들어 있다. 단순 요약은 한 문단을 만들 수 있다. 하지만 실제 업무를 이어가려면 더 많은 관계가 필요하다.

• 누가 회의에 참석했는가?
• 어떤 결정이 명시적으로 승인됐는가?
• 어떤 문서가 그 결정의 대상인가?
• 누가 후속 행동의 소유자인가?
• 외부 시스템에 쓰기 전에 사람 승인이 필요한가?

이 관계를 표현해야 에이전트가 “문서를 수정해도 되는 상황”과 “질문해야 하는 상황”을 구분할 수 있다. 맥락은 답변 품질뿐 아니라 권한 경계에도 영향을 준다.

그래프가 필요한 순간

Context Graph가 필요한 경우는 명확하다.

1. 입력 유형에 따라 다른 경로가 필요하다.
2. 여러 작업을 병렬로 실행하고 결과를 합쳐야 한다.
3. 핸드오프 뒤에도 같은 상태를 공유해야 한다.
4. 실패 유형마다 다른 복구 경로가 필요하다.
5. 외부 행동에 승인 경계가 필요하다.
6. 개별 단계와 전이를 따로 평가해야 한다.

반대로 단일 문서를 요약하거나, 한 번 쓰고 버릴 답변을 만드는 작업이라면 그래프는 과하다. 프롬프트 하나나 짧은 루프로 충분한 일을 그래프로 만들면 관측성보다 유지비가 먼저 늘어난다.

제품 지능은 관계에서 나온다

그래프가 효과를 내는 사례는 공통점이 있다. 허위정보 분석은 주장, 변형된 주장, 게시자, 팩트체크 관계를 본다. 지원 티켓 라우팅은 사람, 팀, 기술, 현재 업무량, 과거 처리 이력을 연결한다. 시장 분석은 정책 충격과 기업·산업 의존성을 따라간다.

이 경우 그래프는 데이터 저장소가 아니라 제품이 판단하는 방식 그 자체다. 질문과 비슷한 문서를 찾는 것만으로는 부족하고, 관계를 따라가야 더 나은 추천이나 설명이 나온다.

설계 체크리스트

• 이 작업은 단일 변환인가, 반복 루프인가, 명시적 그래프가 필요한가?
• 보존할 맥락은 사람, 문서, 결정, 행동 중 무엇인가?
• 어떤 관계가 외부 행동의 권한 경계를 결정하는가?
• 오래된 맥락을 무효화하거나 재검증하는 규칙이 있는가?
• 실패했을 때 기록할 것은 기억인가, 재시도 경로인가, 사람 승인 요청인가?

Context Graph는 에이전트의 장기 기억 장식이 아니다. 실행 가능한 자동화가 어떤 맥락을 읽고, 어디까지 행동하고, 언제 멈춰야 하는지 결정하게 만드는 경계 모델이다.