AI 업무 비서는 어떻게 내 업무 맥락을 기억할까?｜이메일·문서·리서치를 연결하는 Context-Aware AI 워크플로우 설계

World Story Factory World Story Factory 9/21/2026 07:00:00 오전

AI 업무 비서는 어떻게 내 업무 맥락을 기억할까?｜이메일·문서·리서치를 연결하는 Context-Aware AI 워크플로우 설계

이메일·문서·리서치를 연결하는 Context-Aware AI 워크플로우 설계

먼저 짚고 갈 점
이 글에서 말하는 ‘AI가 기억한다’는 표현은 모든 이메일과 문서를 AI가 영구 저장한다는 뜻이 아닙니다. 실제 업무형 AI에서는 Memory(저장된 정보), Retrieval(필요한 정보 검색), Context(현재 추론에 실제 제공된 정보), Context Window(한 번에 참고할 수 있는 범위)를 구분해야 합니다.

오후 4시 17분, AI에게 “그 자료 있잖아”라고 물었습니다.

AI 업무 비서와 Context Engineering의 핵심은 정보를 많이 저장하는 데 있지 않습니다. 이메일·문서·리서치 가운데 현재 업무에 필요한 Context를 찾아 Working Context로 구성하는 것이 AI Productivity와 Enterprise AI Workflow의 출발점입니다.

오후 4시 17분.

가상의 식품 유통회사 상품기획팀에서 일하는 36세 ‘유나’는 다음 날 오전 협력업체 미팅을 준비하고 있습니다.

책상 한쪽에는 식어버린 라테가 놓여 있고, 모니터에는 메일함과 클라우드 문서, 시장조사 보고서가 겹겹이 열려 있습니다.

협력업체에서 두 시간 전 메일이 왔습니다.

“지난번 논의했던 조건을 반영해 내일 미팅 자료를 준비해 주세요.”

문제는 ‘지난번 논의했던 조건’이 어디에 있느냐입니다.

가격 조정 요청은 이메일에 있습니다.

팀장의 의견은 회의록에 있습니다.

지난번 제안서 최종본은 클라우드 폴더에 있습니다.

경쟁사 가격 변화는 어제 조사한 웹 리서치에 있습니다.

다음 미팅 일정과 참석자는 캘린더에 있습니다.

유나는 AI에게 이렇게 말하고 싶어집니다.

“지난번 내용 다 알지? 내일 미팅 자료 만들어줘.”

사람과 오래 일한 비서라면 “지난번 내용”이 무엇인지 짐작할 수도 있습니다.

그런데 AI는 어떻게 알까요?

바로 여기에서 Context-Aware AI의 진짜 이야기가 시작됩니다.

※ 위 장면은 특정 기업이나 실제 인물을 다룬 사례가 아닙니다. 「AI 업무 비서는 어떻게 내 업무 맥락을 기억할까?」를 설명하기 위해 실무에서 자주 접할 수 있는 상황을 재구성한 가상의 시뮬레이션입니다.

Context Engineering이란?｜좋은 프롬프트 다음에 등장한 새로운 문제

한동안 생성형 AI 활용의 핵심어는 Prompt Engineering이었습니다.

“AI에게 어떻게 질문해야 좋은 답을 얻을까?”

이 질문은 여전히 중요합니다.

하지만 업무가 복잡해질수록 더 어려운 문제가 나타납니다.

“AI가 답하기 전에 무엇을 알고 있어야 할까?”

Anthropic은 Context Engineering을 Prompt Engineering의 자연스러운 확장으로 설명합니다. 단순히 프롬프트 문구를 잘 만드는 것을 넘어, 추론 시점에 시스템 지시, 도구, 외부 데이터, 메시지 기록 등 어떤 정보를 모델의 제한된 Context에 넣을지를 관리하는 문제라는 것입니다. (Anthropic)

Anthropic — Effective Context Engineering for AI Agents

초보자에게는 이렇게 구분하면 쉽습니다.

Prompt Engineering = 비서에게 어떤 지시를 할 것인가

Context Engineering = 그 비서의 책상 위에 어떤 자료를 올려놓을 것인가

“내일 고객 미팅을 준비해줘”라는 지시가 아무리 명확해도 책상 위에 작년 계약서만 있고 어제 온 고객 메일이 없다면 좋은 결과를 기대하기 어렵습니다.

반대로 관련 없는 이메일 2,000통과 문서 300개를 전부 책상 위에 쏟아놓는다고 더 똑똑해지는 것도 아닙니다.

이것이 Context Engineering의 묘미입니다.

WSF 필자의 한 줄
“AI에게 필요한 것은 모든 자료가 아니라, 지금 이 판단에 필요한 자료입니다.”

AI가 ‘기억한다’는 말부터 다시 이해해봅시다.

여기서 예상 밖의 반전이 하나 나옵니다.

좋은 AI 업무 비서는 모든 것을 기억하는 AI가 아닐 수 있습니다.

오히려 필요할 때 필요한 정보를 정확히 찾아오는 AI가 더 실용적일 수 있습니다.

첨부 조사자료에서도 이를 명확하게 구분하고 있습니다.

Memory = 저장되어 있는 정보
Retrieval = 필요한 정보를 찾는 과정
Context = 현재 모델이 실제로 참고하도록 제공된 정보

여기에 Context Window와 Tool까지 추가하면 전체 그림이 완성됩니다.

Memory vs Retrieval vs Context vs RAG 비교 분석

📊 Memory vs Retrieval vs Context vs RAG 비교 분석

개념	핵심 질문	쉬운 비유	업무 예시
Prompt	무엇을 시킬까?	비서에게 주는 지시	"내일 고객 미팅 브리핑을 만들어줘"
Memory	무엇을 저장해 두었나?	서랍·수첩	프로젝트 선호도, 과거 상태
Retrieval	필요한 정보를 어떻게 찾나?	자료실 사서	관련 이메일·문서 검색
RAG	찾은 외부 지식을 답변에 어떻게 활용하나?	자료를 찾아 읽고 답하는 과정	사내 문서를 찾아 답변 생성
Context	지금 AI가 실제로 무엇을 참고하고자나?	현재 책상 위 자료	관련 메일+회의록+조사자료
Context Window	한 번에 참고할 수 있는 범위는?	책상의 크기	현재 입력·대화·검색결과 등
Tool	외부에서 무엇을 조회·실행할까?	전화·검색·업무 프로그램	이메일 검색, 파일 조회
Permission	어디까지 접근·행동해도 될까?	출입카드의 권한	특정 Drive 폴더만 읽기

※ 모바일 화면에서는 표를 좌우로 스크롤하여 전체 내용을 편하게 확인하실 수 있습니다.

첨부된 사전 조사에서도 Prompt·Context·Context Window·Retrieval·RAG·Memory·Tool·Permission을 이와 같은 별도 질문으로 구분하는 것이 핵심 콘텐츠 축으로 제안됐습니다.

이 구분 하나만 정확히 이해해도 “AI가 내 모든 자료를 기억한다” 같은 과도한 표현을 피할 수 있습니다.

Context Retrieval 가이드｜이메일·문서·리서치는 어떻게 하나의 업무 맥락이 될까?

다시 유나의 내일 미팅으로 돌아가 보겠습니다.

유나가 원하는 것은 이메일 요약이 아닙니다.

필요한 정보는 여러 장소에 흩어져 있습니다.

Email → 고객의 최신 요청

Document → 이전 제안서와 계약조건

Meeting Notes → 팀 내부 결정

Calendar → 미팅 일정과 참석자

Research → 최신 시장정보

Task → 아직 끝나지 않은 후속 업무

이것들을 하나로 연결하면 Unified Work Context, 즉 통합 업무 맥락이 만들어집니다.

실제 업무에서는 이 문제가 꽤 중요합니다.

OpenAI가 공개한 Company Knowledge 역시 회사에서 필요한 맥락이 문서·파일·메시지·이메일·티켓·프로젝트 도구 등에 분산되어 있다는 문제를 전제로, 연결된 업무 소스에서 관련 정보를 찾아 조직별 답변을 만드는 구조를 설명합니다. (OpenAI)

OpenAI — Company Knowledge 공식 안내

현재 Company Knowledge는 지원되는 지식 소스와 연결 앱 등을 이용하며, 기존 소스의 접근권한을 존중합니다. 즉 사용자가 원래 볼 수 없는 회사 데이터를 Company Knowledge를 연결했다는 이유만으로 볼 수 있게 되는 구조는 아닙니다. (OpenAI Help Center)

여기서 중요한 단어가 Context Retrieval입니다.

AI가 “기억해냈다”기보다 현재 질문에 필요한 정보를 허용된 데이터 소스에서 찾아 Context로 가져왔다고 표현하는 것이 더 정확한 경우가 많습니다.

Working Context란?｜AI 책상 위에는 무엇을 남겨야 할까?

유나의 회사 자료가 10만 개 있다고 가정해보겠습니다.

AI에게 10만 개를 모두 보여주는 것이 좋을까요?

그렇지 않습니다.

Anthropic은 Context를 유한한 자원으로 설명하면서, 높은 신호를 가진 정보의 작은 집합을 잘 구성하는 것이 중요하다고 설명합니다. Context가 길어질수록 무조건 정확도가 좋아진다고 볼 수 없으며, 관련성이 떨어지는 정보가 많이 섞이면 집중해야 할 정보의 선별 문제가 생길 수 있습니다. (Anthropic)

이를 실제 책상으로 상상해보세요.

책상이 크다고 업무가 자동으로 잘되는 것은 아닙니다.

책상 위에 지난 5년간의 서류를 전부 쌓아두면 오히려 오늘 결재해야 할 한 장을 찾기가 어려워집니다.

그래서 좋은 AI Workspace는 다음과 같은 사고방식이 필요합니다.

전체 지식 저장소

→ 관련 후보 검색

→ 현재 업무와의 관련성 판단

→ 필요한 정보만 Working Context에 구성

→ 추론

→ 새로운 결과 생성

→ 필요하면 다시 Retrieval

이 구조가 Context-Aware Workflow의 뼈대입니다.

WSF 필자의 한 줄
“AI의 책상이 커지는 것보다 중요한 것은, 지금 필요한 서류가 책상 위 어디에 놓여 있는지를 아는 것입니다.”

Context Window가 크면 모든 것을 기억할까?

이 질문은 앞으로 검색량이 커질 가능성이 높은 주제입니다.

답은 단순한 ‘예’가 아닙니다.

Context Window와 Memory는 같은 개념이 아니기 때문입니다.

Context Window는 모델이 현재 추론 과정에서 참고할 수 있는 정보 범위와 관련된 개념이고, Memory는 정보를 이후에도 유지하거나 다시 활용하는 구조와 관련됩니다.

첨부 조사자료에서도 “Context Window가 크면 AI가 모든 것을 기억하는가?”를 별도의 핵심 검색 질문으로 제시하며, Context가 길어져도 정보 선별과 Context Pollution 문제가 남는다고 정리하고 있습니다.

Anthropic 역시 장시간 Agent 작업에서는 단순히 더 큰 Context Window만 기대하기보다 Compaction, structured note-taking, multi-agent architecture 같은 전략을 설명합니다. (Anthropic)

Context Compaction은 무엇일까?

여행가방에 비유해보겠습니다.

일주일 여행을 마치고 다음 도시로 이동하는데 호텔 방의 모든 물건을 그대로 들고 갈 필요는 없습니다.

필요한 옷, 여권, 예약정보, 다음 일정만 추려 다시 가방에 넣습니다.

AI에서도 긴 작업 기록을 핵심 정보 중심으로 압축해 다음 Context에서 이어가는 접근을 Compaction이라고 생각하면 이해하기 쉽습니다.

중요한 것은 단순 삭제가 아니라 업무 연속성에 필요한 정보를 보존하면서 불필요한 세부정보를 줄이는 것입니다.

RAG와 AI Memory는 무엇이 다를까?

RAG는 Retrieval-Augmented Generation, 한국어로는 보통 ‘검색 증강 생성’이라고 부릅니다.

이름이 어렵지만 도서관으로 생각하면 간단합니다.

질문을 받은 사람이 모든 책 내용을 외우고 답하는 대신, 질문과 관련된 책을 찾아 필요한 부분을 읽은 뒤 답변을 작성합니다.

이것이 RAG의 기본적인 직관입니다.

Memory는 다릅니다.

Memory는 과거의 정보나 상태를 이후 업무에서 재사용할 수 있도록 유지하는 문제에 더 가깝습니다.

그래서 실무에서는 다음처럼 연결될 수 있습니다.

Memory/Knowledge Store → Retrieval → Context Construction → Reasoning → Output

RAG와 Memory를 경쟁 관계로 볼 필요도 없습니다.

프로젝트의 지속 상태는 Memory에 남기고, 최신 문서는 Retrieval로 찾고, 지금 필요한 것만 Context에 올리는 식으로 함께 설계할 수 있습니다.

Just-in-Time Context｜모든 자료를 미리 넣지 않는 이유

Context Engineering에서 특히 흥미로운 개념이 Just-in-Time Context입니다.

필요할지도 모르는 자료를 처음부터 몽땅 넣어두기보다 필요해지는 순간 찾아오는 방식입니다.

Anthropic은 agentic 시스템에서 파일 경로, 저장된 쿼리, 웹 링크 같은 가벼운 참조를 유지하고 Agent가 도구를 사용해 실행 중 필요한 데이터를 동적으로 가져오는 접근을 설명합니다. 이를 통해 필요한 정보가 점진적으로 Context에 들어올 수 있습니다. (Anthropic)

예를 들어 유나의 AI 업무 비서는 처음부터 회사의 모든 제안서를 읽을 필요가 없습니다.

“내일 A사 미팅”

이라는 목표를 받으면,

A사 최신 이메일을 찾고,

거기에서 ‘가격 변경’이라는 단서를 발견하고,

Context-Aware AI 워크플로우 설계｜실전 8단계

이제 실제 업무 구조로 바꿔보겠습니다.

① Goal — 무엇을 끝내야 하는가?

“자료 찾아줘”보다 “내일 A사 가격협상 미팅을 위한 1페이지 브리핑을 만들어줘”처럼 완료 상태를 정의합니다.

② Identity & Permission — 누구의 권한으로 접근하는가?

어떤 이메일·Drive·SharePoint·CRM을 읽을 수 있는지 먼저 정합니다.

③ Context Discovery — 정보가 어디에 있는가?

메일, 문서, 일정, 프로젝트 관리도구, 사내 지식베이스 등 후보 소스를 파악합니다.

④ Context Retrieval — 관련 자료만 찾습니다.

프로젝트명, 고객명, 날짜, 문서 버전, 작성자 같은 단서를 이용해 관련성이 높은 정보를 검색합니다.

⑤ Working Context — 지금 필요한 정보만 구성합니다.

오래된 계약서 전체가 아니라 현재 계약조건에 필요한 조항, 최신 메일, 회의 결정사항처럼 필요한 부분을 구성합니다.

⑥ Reasoning & Synthesis — 정보 사이의 관계를 해석합니다.

“고객은 가격 인하를 요청했지만 지난 회의에서는 납기 보장을 우선하기로 했다”처럼 서로 다른 자료 사이의 관계를 분석합니다.

⑦ Create or Act — 결과물을 만듭니다.

브리핑, 이메일 초안, 비교표, 보고서, Task 등으로 변환합니다. 외부 시스템을 변경하는 Action은 권한과 승인 절차를 별도로 설계해야 합니다.

⑧ Update State — 다음 업무를 위해 상태를 남깁니다.

완료된 업무, 미결정 사항, 다음 단계처럼 이후에도 필요한 정보를 구조적으로 유지합니다.

이 흐름을 한 줄로 압축하면 이렇습니다.

Goal → Discover → Retrieve → Build Context → Reason → Create → Act → Update

2026년 최신 흐름｜Agent 경쟁은 ‘모델’만의 경쟁이 아닙니다.

이 주제가 지금 중요한 이유가 있습니다.

2026년 9월 10일 OpenAI는 Agents API를 public beta로 발표했습니다. OpenAI는 장시간 실행되는 Agent가 실제로 작동하려면 모델만이 아니라 Context 관리, 효율적인 Tool 사용, Subagent Coordination을 담당하는 harness와 파일·코드·중간 결과를 다룰 수 있는 실행 환경이 필요하다고 설명했습니다. (OpenAI)

OpenAI — Introducing the Agents API

즉 경쟁의 중심을 단순화하면,

Model

에서

Model + Context + Tools + State + Execution Environment

로 넓혀 볼 수 있습니다.

이것은 꽤 큰 변화입니다.

AI가 30초짜리 질문에 답할 때는 Context 관리가 크게 눈에 띄지 않을 수 있습니다.

하지만 30분, 몇 시간, 며칠에 걸쳐 파일을 읽고 조사하고 결과를 저장하며 업무를 이어간다면 “현재 어디까지 했는가?”와 “다음 단계에서 무엇을 알아야 하는가?”가 중요해집니다.

사람에게도 월요일에 맡긴 프로젝트를 금요일까지 이어가려면 업무노트가 필요한 것과 비슷합니다.

반전｜AI 업무 비서의 핵심은 ‘기억력’보다 ‘선택력’입니다.

처음 유나는 이렇게 생각했습니다.

“내 AI가 모든 업무를 기억하면 얼마나 편할까?”

하지만 실제 Context Engineering 관점에서는 질문이 달라집니다.

“AI가 지금 필요하지 않은 것을 얼마나 잘 제외할 수 있을까?”

입니다.

모든 이메일을 항상 기억하는 AI보다,

오늘 고객과 관련된 최신 이메일을 찾고,

잘못된 옛 버전 문서는 제외하고,

현재 승인된 가격표를 확인하고,

필요한 시장자료만 가져오고,

근거가 불확실하면 출처를 다시 확인하는 AI가 실제 업무에는 더 유용할 수 있습니다.

Anthropic의 Context Engineering 가이드 역시 Context를 무한히 채우기보다 제한된 attention budget 안에서 정보성이 높고 간결한 Context를 구성하는 방향을 강조합니다. (Anthropic)

WSF 필자의 한 줄
“좋은 기억은 모든 것을 붙잡는 능력이 아니라, 지금 중요한 것을 놓치지 않는 능력일지도 모릅니다.”

Enterprise AI 도입 가이드｜Context가 많아질수록 Permission도 중요해집니다.

여기서 기술 이야기만 하고 끝내면 절반짜리 글이 됩니다.

AI가 이메일·문서·CRM·프로젝트 데이터를 연결할수록 Context의 양뿐 아니라 접근권한도 중요해집니다.

OpenAI의 현재 Company Knowledge 안내에 따르면 연결된 소스의 기존 권한을 존중하며, 사용자는 원래 접근할 권한이 있는 정보만 검색할 수 있습니다. Business·Enterprise·Edu 환경에서 관리자는 앱과 소스 접근을 관리할 수 있습니다. (OpenAI Help Center)

ChatGPT의 앱 역시 외부 서비스의 정보를 검색·참조해 관련 Context를 가져올 수 있고, 일부 앱에서는 Action도 지원합니다. 기능 이용 범위는 플랜과 워크스페이스 설정, 앱 자체의 권한 등에 영향을 받을 수 있습니다. (OpenAI Help Center)

OpenAI — Apps in ChatGPT 공식 안내

따라서 기업용 AI Workspace에서는 다음 식의 원칙이 중요해집니다.

Can Retrieve ≠ Should Retrieve

검색할 기술적 능력이 있다고 해서 모든 자료를 항상 가져와야 한다는 의미는 아닙니다.

회사 임원회의 자료, 인사정보, 고객 개인정보, 계약자료가 모두 같은 Context에 들어갈 이유는 없습니다.

Identity → Permission → Retrieval → Context → Action

이 순서를 함께 설계해야 합니다.

AI Workspace가 바꾸는 일상의 작은 장면

Context-Aware AI라고 하면 거대한 기업 시스템부터 떠올리기 쉽습니다.

하지만 변화는 아주 작은 곳에서도 느껴질 수 있습니다.

퇴근 직전 누군가에게서

“지난번에 이야기했던 자료 다시 보내주세요.”

라는 메일이 왔다고 생각해보세요.

예전에는 메일 검색창을 열고 이름을 검색하고, 첨부파일을 찾고, Drive 폴더를 열고, 파일 버전을 확인하고, 다시 이메일로 돌아와 답장을 작성했습니다.

AI Workspace가 제대로 작동한다면 그 여러 번의 작은 이동을 줄일 수 있습니다.

그리고 그렇게 절약된 10분이 반드시 또 다른 업무로 채워져야 하는 것도 아닙니다.

퇴근길에 조금 천천히 걷고, 집에 도착해 가족과 저녁을 먹을 때 회사 메일을 한 번 덜 확인하는 것.

생산성 기술의 가치는 때로 숫자로 측정되는 처리량보다 사람의 머릿속에 남아 있던 미완료 업무의 무게를 조금 덜어주는 데 있을 수 있습니다.

Context Engineering의 경제성｜정보를 많이 넣는 것도 비용입니다.

여기에서 경제적인 관점도 살펴볼 필요가 있습니다.

AI 업무 자동화에서는 데이터가 많으면 무조건 좋은 것이 아닙니다.

불필요한 Context를 계속 처리하면 토큰과 처리시간이 늘어날 수 있고, 검색 과정이 복잡하면 Tool Call도 증가할 수 있습니다.

따라서 기업은 AI Workspace를 도입할 때 단순히 모델 사용료만 보는 것이 아니라,

Retrieval 비용 + Model 비용 + Tool 실행 비용 + 저장·검색 인프라 + 사람 검토시간 + 오류 수정비용

까지 함께 살펴볼 필요가 있습니다.

이것이 Total Cost of Ownership(TCO) 관점입니다.

쉽게 말하면 자동차 가격만 보는 것이 아니라 보험료·연료비·정비비까지 합쳐 실제 보유비용을 계산하는 것과 같습니다.

Context Engineering 역시 기술적인 정확성뿐 아니라 얼마나 적은 비용으로 필요한 정보를 정확하게 공급할 것인가라는 경제성 문제를 품고 있습니다.

실무 체크리스트｜AI 업무 비서를 만들기 전에 확인해보세요.

AI가 해결해야 할 최종 업무가 명확한가?
이메일·문서·리서치 중 실제 필요한 데이터 소스를 구분했는가?
Memory와 Retrieval을 같은 것으로 취급하고 있지 않은가?
최신 문서와 오래된 문서를 구분할 기준이 있는가?
문서의 작성일·버전·소유자 정보를 활용할 수 있는가?
Context에 불필요한 자료가 과도하게 들어가지 않는가?
사용자의 기존 접근권한을 그대로 반영하는가?
외부 Action에는 추가 승인 단계가 필요한가?
검색 결과의 출처를 사람이 다시 확인할 수 있는가?
장시간 업무에서는 상태 저장·Compaction·중간 결과 관리가 가능한가?

자주 묻는 질문 FAQ

Context Engineering이란 무엇인가요?

프롬프트 문장만 최적화하는 것을 넘어 모델이 추론할 때 사용할 시스템 지시, 도구, 외부 데이터, 대화 기록 등 전체 Context를 선별·구성·관리하는 접근입니다. Anthropic은 이를 Prompt Engineering의 자연스러운 발전으로 설명합니다. (Anthropic)

Prompt Engineering과 Context Engineering의 가장 큰 차이는 무엇인가요?

Prompt Engineering이 “어떻게 지시할까?”에 가깝다면 Context Engineering은 “그 일을 하기 위해 지금 무엇을 알려줘야 할까?”에 가깝습니다.

AI Memory와 Context는 같은가요?

같다고 보기 어렵습니다. Memory는 이후 재사용할 수 있도록 유지되는 정보·상태와 관련되고, Context는 현재 추론 과정에 실제로 들어와 있는 정보와 관련됩니다. 첨부 조사자료에서도 Memory·Retrieval·Context를 별도로 구분하고 있습니다.

Context Window가 크면 AI가 모든 것을 기억하나요?

그렇게 단순하게 볼 수 없습니다. 긴 Context에서도 관련성 선별과 Context Pollution 문제가 남을 수 있습니다. Anthropic은 긴 작업에서 Compaction, structured note-taking, multi-agent architecture 등의 접근을 함께 설명합니다. (Anthropic)

RAG와 Context Engineering은 같은 기술인가요?

아닙니다. RAG는 외부 정보를 검색해 생성 과정에 활용하는 접근이고, Context Engineering은 검색된 정보뿐 아니라 지시사항·도구·대화기록·작업상태 등 현재 추론에 필요한 Context 전체를 어떻게 구성할지를 다루는 더 넓은 설계 관점으로 이해할 수 있습니다.

AI 업무 비서는 이메일과 문서를 모두 기억하나요?

제품·플랜·설정에 따라 다르며, ‘기억한다’는 표현 자체를 주의해야 합니다. 연결된 앱이나 지식 소스에서 질문 시점에 관련 정보를 검색해 가져오는 경우도 있기 때문입니다. OpenAI Company Knowledge 역시 지원되는 연결 소스를 활용하며 기존 접근권한을 존중합니다. (OpenAI Help Center)

Just-in-Time Context는 무엇인가요?

모든 자료를 미리 Context에 넣는 대신 파일 경로·검색 단서 등을 유지하고, 필요한 순간 Agent가 관련 데이터를 가져오는 접근입니다. Anthropic은 이를 agentic context retrieval 전략 중 하나로 설명합니다. (Anthropic)

필자의 주관적인 마무리 의견

제가 Context Engineering을 흥미롭게 보는 이유는 이 개념이 AI에 대한 우리의 기대를 조금 현실적으로 바꿔주기 때문입니다.

우리는 흔히 “내 AI가 나에 관한 모든 것을 기억했으면 좋겠다”고 생각합니다. 하지만 업무에서는 기억의 양보다 정확한 정보가 정확한 순간에 등장하는 것이 더 중요할 수 있습니다. 지난달 초안보다 어제 승인된 최종본을 찾아야 하고, 관련 없는 메일 100통보다 오늘 고객이 보낸 한 문장을 놓치지 않는 것이 중요합니다.

그래서 저는 앞으로 AI 업무 비서의 경쟁력을 모델의 지능만으로 평가하기 어렵다고 봅니다. Context Retrieval, Permission, Working Context, Tool, State, Source Verification이 함께 움직여야 실제 업무에서 신뢰할 만한 결과가 만들어집니다.

그리고 이 기술이 사람의 일상을 조금 더 편안하게 만들어줬으면 합니다. 우리가 하루 종일 “그 파일 어디 있었지?”, “누가 뭐라고 했더라?”, “메일에 첨부했나?”를 기억하기 위해 집중력을 소비하지 않아도 된다면, 그만큼 더 중요한 판단과 사람에게 집중할 여유가 생길 수 있기 때문입니다.

AI가 인간처럼 모든 것을 기억하는 미래보다 저는 필요한 순간에 필요한 것을 정확히 찾아주고, 모르는 것은 모른다고 말하며, 근거가 어디에서 왔는지 보여주는 AI Workspace가 더 유용하다고 생각합니다.

Context Engineering의 목적은 AI의 머릿속을 끝없이 채우는 것이 아닙니다. 일을 끝내는 데 필요한 정보만 제대로 연결하는 것, 저는 그것이 앞으로의 AI 업무 비서를 이해하는 가장 현실적인 출발점이라고 봅니다.

WSF 필자의 한 줄
“좋은 AI 비서는 과거를 모두 외우는 비서가 아니라, 현재의 질문에 필요한 과거를 제대로 찾아오는 비서입니다.”

이번 글의 핵심을 한 문장으로 압축하면 이렇습니다.

AI 업무 비서가 모든 이메일과 문서를 영구적으로 ‘기억하는 것’보다, 현재 업무에 필요한 정보를 권한 범위 안에서 찾아 가장 작은 고품질 Working Context로 구성하는 능력이 더 중요합니다.

2026년 9월 공개된 OpenAI Agents API가 Context 관리와 Tool 사용, Subagent Coordination을 장시간 Agent의 핵심 요소로 설명하고, Anthropic 역시 Context를 유한한 자원으로 보면서 Just-in-Time Retrieval과 Compaction 같은 전략을 제시하는 이유도 이 흐름과 맞닿아 있습니다. (OpenAI)

이제 AI 활용의 질문은 “프롬프트를 어떻게 잘 쓸까?”에서 한 단계 더 나아가고 있습니다.

“AI가 지금 이 일을 제대로 하기 위해 무엇을 알아야 하고, 무엇은 굳이 알 필요가 없으며, 필요한 정보는 어디에서 가져와야 하는가?”

바로 그 질문에서 Context Engineering과 차세대 AI Workspace 설계가 시작됩니다.

공식 자료 및 추가 확인

이번 주제는 기술 변화가 빠르므로 아래 공식 문서를 기준으로 기능과 개념의 최신 상태를 다시 확인하는 것이 좋습니다.

Anthropic — Effective Context Engineering for AI Agents

Context Engineering, Just-in-Time Retrieval, Context Compaction, structured note-taking, long-horizon agent 설계를 확인할 수 있습니다. (Anthropic)

OpenAI — Company Knowledge 공식 도움말

기업의 연결된 지식 소스, 기존 접근권한, 관리자 설정 등 현재 Company Knowledge 구조를 확인할 수 있습니다. (OpenAI Help Center)

OpenAI — Introducing the Agents API

2026년 9월 10일 발표된 Agents API와 장시간 Agent에서 Context 관리·Tool 사용·Subagent Coordination이 왜 중요한지 확인할 수 있습니다. (OpenAI)