컨텍스트 엔지니어링이라는 새로운 관점

1장에서 우리는 한 가지 사실을 확인했다. AI의 성패는 질문 한 줄의 세련됨만으로 결정되지 않는다는 점이다. 이제 시선을 한 걸음 더 옮겨 보자. 문제는 더 이상 "프롬프트를 어떻게 잘 쓸까"가 아니다. 진짜 질문은 이것이다.

모델이 일을 잘하게 만들기 위해, 어떤 정보와 규칙과 도구와 기억을 어떤 방식으로 보여 줄 것인가?

바로 이 질문에서 컨텍스트 엔지니어링이라는 관점이 시작된다.

컨텍스트 엔지니어링이란 무엇인가

컨텍스트 엔지니어링은 AI가 추론하는 순간 보게 되는 입력 환경 전체를 설계하는 일이다. 여기서 말하는 입력 환경은 단순한 프롬프트 한 문장이 아니다. 시스템 지시문, 사용자 요청, 이전 대화, 첨부 문서, 검색 결과, 메모리, 도구 설명, 도구 실행 결과, 출력 형식 규칙까지 모두 포함된다.

조금 쉽게 말하면 이렇다. 프롬프트 엔지니어링이 "무슨 말을 할까"에 가까웠다면, 컨텍스트 엔지니어링은 "AI의 책상 위에 무엇을 올려둘까"에 가깝다.

같은 모델이라도 책상 위에 놓인 재료가 달라지면 결과가 달라진다. 해야 할 일의 목표가 또렷하게 적혀 있고, 참고 문서가 최신이며, 도구 사용 규칙이 분명하고, 이전 결정 사항이 잘 정리되어 있으면 답변은 훨씬 안정적이 된다. 반대로 자료가 뒤섞여 있거나 오래되었거나, 중요 규칙이 묻혀 있거나, 필요할 때 도구를 쓰지 못하면 성능은 쉽게 무너진다.

그래서 컨텍스트 엔지니어링은 문장을 다듬는 기술이라기보다 정보를 배치하는 기술, 작업 환경을 조립하는 기술, 모델의 주의를 올바른 곳으로 보내는 기술이라고 보는 편이 더 정확하다.

왜 이제 프롬프트보다 컨텍스트인가

초기의 생성형 AI 활용에서는 프롬프트가 거의 전부처럼 보였다. 실제로 그때는 한 번 묻고 한 번 답하는 사용이 많았고, 사용자가 만질 수 있는 가장 눈에 띄는 손잡이도 프롬프트였다. 하지만 지금의 AI 시스템은 다르다.

문서 작성 AI는 참고 자료를 읽어야 하고, 고객지원 봇은 정책 문서와 최신 예외 규정을 알아야 하며, 코딩 에이전트는 저장소 구조와 테스트 결과를 이해해야 한다. 개인 비서형 AI는 일정, 메일, 할 일, 사용자 선호를 함께 고려해야 한다. 즉, 현대의 AI는 점점 더 하나의 문장이 아니라 여러 정보원 사이를 오가며 일하는 시스템이 되고 있다.

이 변화 때문에 프롬프트만 잘 써서는 해결되지 않는 문제가 늘어난다. 예를 들어 사용자가 아무리 정확한 질문을 해도, 최신 정책 문서가 빠져 있으면 고객지원 AI는 틀릴 수 있다. 코드 수정 요청이 아무리 명확해도, 테스트 실패 로그나 프로젝트 규칙이 없으면 코딩 에이전트는 엉뚱한 방향으로 갈 수 있다.

즉, 오늘날의 핵심 역량은 "모델에게 좋은 말을 건네는 능력"만이 아니다. 모델이 좋은 판단을 내릴 수 있도록 필요한 맥락을 제때 공급하는 능력이 더 중요해졌다.

프롬프트 엔지니어링과 무엇이 다른가

둘은 적이 아니다. 오히려 프롬프트 엔지니어링은 컨텍스트 엔지니어링의 한 부분으로 보는 것이 자연스럽다. 다만 초점이 다르다.

프롬프트 엔지니어링은 보통 이런 질문에 집중한다. 요청을 어떻게 쓰면 원하는 톤이 나오는가, 어떤 예시를 넣으면 형식이 안정되는가, 어떤 표현이 지시를 더 잘 전달하는가 같은 문제다. 말하자면 좋은 지시문을 만드는 기술이다.

반면 컨텍스트 엔지니어링은 더 넓은 질문을 다룬다. 이 작업에 필요한 정보는 무엇인가, 어떤 정보는 빼야 하는가, 최신 문서는 어디서 가져오는가, 긴 대화는 어떻게 요약할 것인가, 어떤 도구를 언제 호출하게 할 것인가, 도구 결과는 어떤 형식으로 다시 넣을 것인가, 서로 충돌하는 규칙이 있으면 무엇을 우선할 것인가 같은 문제다.

차이를 비유해 보면 이렇다.

프롬프트 엔지니어링이 회의에서 "질문을 잘하는 기술"이라면, 컨텍스트 엔지니어링은 회의 전에 안건을 정리하고, 필요한 자료를 모으고, 참석자를 고르고, 회의록 양식을 준비하고, 결정 사항이 다음 회의에 이어지게 만드는 기술이다.

둘 다 중요하다. 하지만 회의가 복잡해질수록 질문 기술만으로는 부족해지고, 준비와 구조 설계의 비중이 커진다. AI도 마찬가지다.

컨텍스트의 범위는 생각보다 훨씬 넓다

많은 사람이 컨텍스트를 단지 "이전 대화 내용" 정도로 이해한다. 물론 그것도 맞지만, 실무에서는 훨씬 넓게 봐야 한다.

컨텍스트는 모델이 참고하는 모든 작업 재료다. 시스템 지시문처럼 행동 기준을 정하는 정보도 컨텍스트이고, 사용자 질문처럼 현재 목표를 알려 주는 정보도 컨텍스트다. 첨부된 파일, 검색으로 가져온 문서 조각, 데이터베이스 질의 결과, 함수 호출 설명, 장기 기억에 저장된 사용자 선호도 역시 모두 컨텍스트다.

중요한 것은 이 재료들이 같은 무게를 갖지 않는다는 점이다. 어떤 것은 규칙이고, 어떤 것은 사실이며, 어떤 것은 배경이고, 어떤 것은 방금 얻은 결과다. 따라서 컨텍스트 엔지니어링은 단순히 많이 넣는 일이 아니라 역할이 다른 재료를 구분해서 배치하는 일이다.

예를 들어 "항상 한국어로 답하라"는 규칙과 "이번 분기 영업 보고서를 요약해 달라"는 요청은 같은 텍스트라도 기능이 다르다. 전자는 행동 기준이고, 후자는 현재 과제다. 또 "회사 공식 정책 문서"와 "사용자가 방금 말한 추측"도 신뢰도와 우선순위가 다르다. 이런 차이를 무시하면 컨텍스트는 금세 혼잡해진다.

결국 컨텍스트를 잘 다룬다는 것은 정보를 많이 모으는 것이 아니라, 어떤 정보가 어떤 역할을 하는지 아는 것이다.

문장 작성에서 정보 환경 설계로

컨텍스트 엔지니어링이 주는 가장 큰 변화는 역할 인식의 변화다. 이제 우리는 단순히 AI에게 말을 거는 사용자가 아니다. AI가 일하는 환경을 설계하는 사람이 된다.

이 차이는 작아 보여도 실무에서는 매우 크다. 사용자의 관점에서는 "왜 내 말을 못 알아듣지?"라고 묻게 된다. 하지만 설계자의 관점에서는 "이 작업에 필요한 정보가 실제로 공급되었나?"라고 묻게 된다.

예를 들어 보고서 작성 AI가 자꾸 추상적인 문장만 내놓는다고 해 보자. 사용자의 시선은 프롬프트를 더 길고 정교하게 바꾸는 쪽으로 향한다. 그러나 설계자의 시선은 다르게 움직인다. 참고할 내부 데이터가 없었는지, 목표 독자가 명시되지 않았는지, 이전 초안에 대한 비평 결과가 전달되지 않았는지, 출력 형식이 너무 모호했는지부터 점검한다.

이 차이가 바로 관점의 전환이다. 좋은 결과는 말솜씨에서만 나오지 않는다. 좋은 작업 조건에서 나온다.

컨텍스트 윈도우를 작업 기억처럼 이해하라

컨텍스트 엔지니어링을 이해하려면 컨텍스트 윈도우를 떠올려야 한다. 컨텍스트 윈도우는 모델이 한 번에 보고 처리할 수 있는 작업 공간이라고 생각하면 된다. 사람으로 치면 머릿속 작업 기억과 비슷하다. 당장 문제를 풀기 위해 눈앞에 올려놓은 종이, 메모, 계산 흔적 같은 것이다.

이 작업 공간은 무한하지 않다. 그래서 무엇을 넣을지, 무엇을 빼야 할지 결정해야 한다. 이 점에서 컨텍스트 윈도우는 컴퓨터의 RAM에 비유하면 이해가 쉽다. RAM이 넓다고 모든 파일을 한꺼번에 열어두는 것이 좋은 전략은 아닌 것처럼, 컨텍스트 윈도우도 무조건 길게 채운다고 성능이 좋아지는 것은 아니다.

오히려 흔한 문제는 네 가지다.

• 꼭 필요한 정보가 빠지는 경우

• 중요하지 않은 정보가 너무 많이 들어오는 경우

• 서로 충돌하는 지시가 함께 들어오는 경우

• 긴 기록 속에서 핵심이 묻혀 버리는 경우

그래서 컨텍스트 엔지니어링은 결국 제한된 작업 공간을 관리하는 기술이기도 하다. 지금 필요한 규칙은 살리고, 오래된 잡음은 줄이고, 긴 문서는 요약하고, 세부 정보는 필요할 때만 불러오게 만들어야 한다.

AI가 똑똑해 보이는 순간은 종종 모델 자체가 갑자기 더 영리해져서가 아니라, 이 작업 공간이 잘 정리되어 있을 때다.

좋은 컨텍스트는 어떤 모습인가

좋은 컨텍스트는 길거나 화려한 컨텍스트가 아니다. 모델이 지금 해야 할 일을 정확히 이해하고, 근거를 찾고, 규칙을 지키고, 필요한 행동을 취할 수 있게 만드는 컨텍스트다.

그런 컨텍스트에는 몇 가지 특징이 있다. 먼저 목적이 분명하다. 모델은 지금 무엇을 해야 하는지, 누구를 위해 답하는지, 어떤 형식으로 결과를 내야 하는지를 알아야 한다. 다음으로 근거가 있다. 내부 문서든 검색 결과든 도구 응답이든, 판단에 사용할 재료가 제공되어야 한다. 또 우선순위가 정리되어 있어야 한다. 시스템 지시문, 사용자 요청, 정책 문서가 충돌할 때 무엇을 따를지 모호하면 결과가 흔들린다.

여기에 더해, 좋은 컨텍스트는 적절히 절제되어 있다. 너무 많은 정보는 친절함이 아니라 방해가 될 수 있다. 모델이 지금 풀어야 하는 문제와 직접 관련 없는 문장들이 많이 섞이면 핵심 규칙이 약해진다. 사람도 책상 위에 서류를 산더미처럼 쌓아 두면 오히려 일을 못하듯, AI도 마찬가지다.

좋은 컨텍스트를 만드는 사람은 정보를 수집하는 사람이라기보다 편집하는 사람에 가깝다. 많이 가져오는 것보다 잘 고르는 것이 더 중요하다.

실무에서 컨텍스트 엔지니어가 실제로 하는 일

컨텍스트 엔지니어링을 거창한 이론으로만 생각하면 손에 잘 잡히지 않는다. 하지만 실무에서는 의외로 매우 구체적인 선택들의 연속이다.

문서 작성 시스템을 만든다면 먼저 독자, 목적, 톤, 금지 표현, 참고 문서를 정리해야 한다. 리서치 에이전트를 만든다면 검색 결과 중 무엇을 채택할지, 근거가 약한 정보는 어떻게 표시할지 정해야 한다. 코딩 에이전트를 만든다면 프로젝트 구조 설명, 코드 스타일 규칙, 테스트 결과, 에러 로그, 수정 범위를 어떻게 묶어서 전달할지 설계해야 한다. 고객지원 챗봇이라면 답변 가능한 범위와 사람에게 넘길 조건, 최신 정책 우선 규칙을 만들어야 한다.

이 모든 일의 공통점은 하나다. 모델이 더 좋은 판단을 내리도록 입력 조건을 정리하는 일이라는 점이다.

따라서 컨텍스트 엔지니어는 단순히 프롬프트를 잘 쓰는 사람이 아니다. 문서 구조를 이해하고, 지식의 출처를 관리하고, 업무 흐름을 나누고, 기억을 남길 것과 지울 것을 결정하고, 도구 사용 경계를 정하는 사람이다. 말하자면 AI 시스템의 정보 설계자에 가깝다.

프롬프트를 버리는 것이 아니라, 제자리를 찾는 것이다

여기서 오해하지 말아야 할 점이 있다. 컨텍스트 엔지니어링이 중요하다고 해서 프롬프트 엔지니어링이 쓸모없어졌다는 뜻은 아니다. 좋은 지시문은 여전히 중요하다. 다만 지시문은 전체 설계의 일부다.

아무리 정교한 시스템 프롬프트가 있어도 참고 문서가 없으면 근거 없는 답을 할 수 있다. 반대로 좋은 문서가 있어도 출력 형식 지시가 없으면 결과가 제멋대로일 수 있다. 도구를 연결해 두어도 언제 써야 하는지 설명이 모호하면 모델은 사용을 망설일 수 있다.

즉, 프롬프트는 엔진이 아니라 조향 장치에 가깝다. 방향을 잡아 주지만, 연료와 지도와 계기판이 없으면 목적지에 도착하기 어렵다. 컨텍스트 엔지니어링은 그 전체 운행 시스템을 함께 보는 관점이다.

이 장에서 가져가야 할 시야의 변화

이 장의 핵심은 정의 하나를 외우는 데 있지 않다. 시야를 바꾸는 데 있다.

이제부터 AI를 볼 때는 단지 "이 모델은 똑똑한가, 아닌가"만 묻지 말아야 한다. 그보다 먼저 "이 모델은 지금 무엇을 보고 있는가"를 물어야 한다. 그리고 "그 정보는 충분한가, 최신인가, 충돌하지 않는가, 과하지 않은가, 행동으로 이어질 수 있는가"를 점검해야 한다.

바로 이 질문들이 컨텍스트 엔지니어링의 출발점이다.

프롬프트 엔지니어링이 AI에게 말을 거는 법을 익히는 과정이었다면, 컨텍스트 엔지니어링은 AI가 제대로 일할 수 있는 작업장을 만드는 과정이다. 이 차이를 이해하는 순간, 우리는 단순한 사용자에서 한 단계 나아간다. AI의 출력에 반응하는 사람이 아니라, 그 출력이 만들어지는 조건을 설계하는 사람이 된다.

다음 장에서는 이 관점을 바탕으로 한 걸음 더 들어가 보겠다. AI의 실패를 모델 자체의 한계로만 돌리지 않고, 실제로는 어떤 컨텍스트 문제가 반복해서 실패를 만드는지 살펴볼 것이다.