한 줄 정의
Context는 모델이 지금 답을 만들 때 참고하라고 받은 정보 묶음이야. 프롬프트, 이전 대화, 붙여 넣은 문서, 검색 결과, 표의 셀, 로그, 도구 호출 결과처럼 이번 작업에 같이 들어간 재료를 가리켜.
컨텍스트 윈도우는 이 재료가 들어갈 수 있는 크기 제한이고, Context는 실제로 그 안에 들어간 내용이야. 메모리가 여러 세션에 걸쳐 남는 저장 정보라면, Context는 이번 실행에서 모델 앞에 놓인 작업대에 가까워.
어떻게 작동하나
모델은 바깥세상을 직접 보지 않아. 앱이 사용자 요청, 시스템 지시, 이전 메시지, 검색한 문서, Function Calling 결과를 한 묶음으로 넣어 주면 그 범위 안에서 답을 계산해. 그래서 같은 모델이라도 어떤 컨텍스트를 넣느냐에 따라 답이 크게 달라져.
예를 들어 장애 대응 에이전트라면 로그와 보안 알림이 컨텍스트가 돼. arXiv 2602.13156의 사고 대응 에이전트는 14B 모델 하나에 인지, 추론, 계획, 행동을 넣고, 실제 관측과 시뮬레이션 결과가 어긋나면 공격 가설을 다시 고쳐. 논문은 이 방식을 in-context 적응으로 설명했고, 평가 로그에서는 frontier LLM보다 회복 시간이 최대 23% 짧았다고 적어.
도구를 쓰는 앱에서는 도구 결과가 다시 컨텍스트로 들어오는지가 중요해. Google의 2026년 3월 17일 Gemini API 글은 built-in tool과 커스텀 함수를 한 요청에 함께 넣고, 한 도구의 출력이 다음 도구 입력으로 이어지도록 context circulation을 제공한다고 설명해. 이때 도구 응답 ID까지 남기면 병렬 호출에서도 어떤 응답이 어떤 요청에 돌아왔는지 맞추기 쉬워져.
표 질의응답도 같은 얘기야. TraceBack 논문은 답변 문장만 보는 대신, 답을 뒷받침하는 행과 열, 중간 추론에 필요한 셀까지 맞추려 해. 여기서 좋은 컨텍스트는 표 전체를 아무렇게나 넣는 게 아니라, 질문과 답을 실제로 지탱하는 셀을 빠뜨리지 않는 쪽이야.
왜 중요한가
Context를 알아야 “모델이 똑똑하다”와 “입력으로 준 근거가 좋다”를 나눠 읽을 수 있어. 최신 문서를 넣어 답했다면 그건 모델의 학습 지식이라기보다 Grounding이나 RAG 같은 실행 시점 근거 연결 덕분일 수 있어.
실무에서는 비용과 품질 판단이 여기서 갈려. 긴 정책 문서 20개를 전부 넣는 방식은 편해 보이지만, 토큰 비용과 지연 시간이 늘고 중요한 문장이 묻힐 수 있어. 반대로 검색 결과를 너무 적게 넣으면 모델이 빈칸을 추측으로 채울 수 있어. 컨텍스트 설계는 “많이 넣기”보다 “필요한 근거를 잃지 않게 줄이기”에 더 가까워.
에이전트 작업에서는 더 민감해. 파일 수정, 브라우저 조작, 사내 API 조회처럼 여러 단계를 이어 가면 앞 단계의 관측과 실패 기록이 다음 판단을 좌우해. 중간 결과를 컨텍스트에 제대로 남기지 않으면 에이전트가 같은 조사를 반복하거나, 이미 틀린 가설을 계속 밀 수 있어.
주의해서 볼 점
첫째, Context와 긴 문맥을 같은 말로 쓰면 헷갈려. 긴 문맥은 많이 담을 수 있는 능력이고, Context는 실제로 담긴 내용이야. 1M 토큰을 넣을 수 있어도 엉뚱한 문서 1M 토큰이면 답은 좋아지지 않아.
둘째, Context는 기억이 아니야. 제품이 이전 대화를 요약해 다시 넣거나 별도 저장소에서 꺼내오면 기억처럼 보일 수 있지만, 모델 입장에서는 다시 받은 입력일 뿐이야. 그래서 민감한 자료를 넣는 시스템은 권한, 삭제, 감사 로그를 앱 쪽에서 따로 설계해야 해.
셋째, 도구 결과도 검증해야 해. 검색 결과가 낡았거나 API 응답이 실패했거나 표 셀 매핑이 틀리면, 모델은 그 잘못된 컨텍스트를 근거처럼 사용해. 컨텍스트를 잘 관리한다는 건 모델을 믿는 일이 아니라, 모델이 읽는 재료를 계속 점검하는 일에 가까워.