3부 14장. 컨텍스트 엔지니어링 입문

앞 장에서는 문서를 넣는 법, 자료를 붙이는 법, 맥락을 정리하는 법을 다루었다. 그 장이 실전의 손기술이었다면, 이번 장은 그 손기술을 묶어 주는 한 단계 위의 관점이다. 바로 컨텍스트 엔지니어링이다.

이 말은 처음 들으면 조금 거창하게 느껴질 수 있다. 하지만 뜻은 생각보다 단순하다. AI에게 말을 잘 거는 것에서 멈추지 않고, AI가 지금 이 일을 잘하기 위해 필요한 정보와 상태를 설계하는 일이다.

예전에는 "프롬프트를 어떻게 써야 할까?"가 핵심 질문이었다. 이제는 그 질문만으로 부족하다. 실전에서는 한 줄짜리 지시문보다, 어떤 자료를 함께 주는지, 무엇을 우선 기준으로 삼는지, 지금이 초안 단계인지 검토 단계인지, 이전 대화에서 무엇을 이어받아야 하는지가 더 큰 차이를 만든다.

즉, AI 활용의 다음 단계는 말솜씨가 아니라 정보 설계 능력이다.

왜 이제는 프롬프트만으로 부족한가

프롬프트는 여전히 중요하다. 목표를 분명히 말하고, 출력 형식을 지정하고, 제약을 알려 주는 일은 기본기다. 하지만 실제 작업은 점점 더 복잡해졌다.

예를 들어 블로그 글 하나를 쓴다고 해 보자. 예전에는 "AI야, 블로그 글 써 줘" 같은 요청으로도 어느 정도 결과를 볼 수 있었다. 그러나 지금은 다르다. 독자 수준, 브랜드 톤, 참고 자료, 기존 문서, 금지 표현, 경쟁 글과의 차별점, 이미 결정된 방향까지 함께 맞춰야 한다. 이때 성패를 가르는 것은 예쁜 문장 하나가 아니라, AI가 어떤 작업 공간 안에서 일하느냐다.

이 차이를 사람 일에 비유하면 이해가 쉽다. 누군가에게 일을 맡길 때 "잘 부탁해요"라고만 말하는 것과, 목적·배경·기준·참고자료·마감·주의사항을 정리해서 넘기는 것은 전혀 다르다. 둘 다 부탁은 맞지만, 결과의 안정성은 크게 다르다.

AI도 마찬가지다. 잘 되는 답은 대개 좋은 문장 하나에서 나오지 않는다. 잘 정리된 문맥 환경에서 나온다.

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

컨텍스트 엔지니어링은 한마디로 말해, AI가 지금 이 순간 알아야 할 것을 적절한 형태로 적절한 시점에 제공하는 일이다.

여기서 중요한 말은 세 가지다.

• 무엇을 넣을 것인가

• 어떻게 정리해서 넣을 것인가

• 언제 넣을 것인가

많은 사람은 컨텍스트를 그냥 "많이 넣는 정보"로 생각한다. 하지만 진짜 핵심은 양이 아니다. 적절성이다. 지금 초안을 쓰는 단계인데 세부 반례까지 한꺼번에 밀어 넣으면 오히려 흔들릴 수 있다. 반대로 최종 검토 단계인데 배경 설명만 잔뜩 있고 검수 기준이 없으면 결과는 느슨해진다.

그래서 컨텍스트 엔지니어링은 단순 입력 작업이 아니다. 작업의 단계에 맞게 정보의 배치와 흐름을 설계하는 일에 가깝다.

컨텍스트는 "정보 묶음"이 아니라 "작업 공간"이다

초보자는 컨텍스트를 보통 참고자료 꾸러미처럼 생각한다. 문서 몇 개를 붙이고, 설명을 덧붙이고, 그러면 컨텍스트가 생겼다고 여긴다. 물론 절반은 맞다. 하지만 절반은 빠져 있다.

컨텍스트는 단순한 자료 모음이 아니다. AI가 판단하고, 선택하고, 생성하는 작업 공간이다. 이 공간 안에는 자료만 있는 것이 아니라 목표, 우선순위, 상태, 제약, 최근 결정사항, 아직 미정인 부분까지 함께 들어간다.

예를 들어 같은 시장조사 문서라도 상황에 따라 역할이 다르다. 어떤 때는 핵심 근거가 되고, 어떤 때는 배경 자료일 뿐이다. 중요한 것은 문서 그 자체보다, 그 문서가 이번 작업 안에서 어떤 지위를 가지는가다.

이 관점이 생기면 질문이 달라진다. "무슨 문서를 넣을까?"보다 "AI가 지금 어떤 작업 공간에서 움직여야 하지?"를 먼저 생각하게 된다.

좋은 컨텍스트는 네 가지를 분명히 한다

입문 단계에서는 컨텍스트를 아주 복잡하게 생각할 필요가 없다. 우선 다음 네 가지가 선명하면 절반은 성공이다.

• 과업: 지금 AI가 정확히 무엇을 해야 하는가

• 재료: 어떤 정보와 문서를 바탕으로 일해야 하는가

• 규칙: 무엇을 따라야 하고 무엇을 피해야 하는가

• 상태: 지금이 어떤 단계이며, 어디까지 결정되었는가

과업이 흐리면 AI는 성실하게 엉뚱한 일을 한다. 재료가 흐리면 근거 없는 일반론으로 흘러간다. 규칙이 없으면 형식은 그럴듯하지만 기준을 어긴다. 상태가 빠지면 대화는 자꾸 처음으로 되돌아간다.

특히 많은 사람이 놓치는 것이 상태다. 초안 작성인지, 후보안 비교인지, 최종 검토인지에 따라 AI가 해야 할 일은 완전히 달라진다. 초안 단계에서는 넓게 제안하게 하고, 검토 단계에서는 좁고 엄격하게 따지게 해야 한다. 같은 모델도 상태 정보가 달라지면 행동이 달라진다.

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

프롬프트 엔지니어링과 컨텍스트 엔지니어링은 서로 싸우는 개념이 아니다. 오히려 앞뒤로 이어진다.

프롬프트 엔지니어링이 무엇을 요청할지 분명히 말하는 기술이라면, 컨텍스트 엔지니어링은 그 요청이 제대로 작동하도록 주변 정보를 설계하는 기술이다.

쉽게 말해 프롬프트는 운전대에 가깝고, 컨텍스트는 도로와 지도에 가깝다. 운전대를 잘 잡는 것도 중요하지만, 길이 엉망이면 원하는 곳에 가기 어렵다.

그래서 실전에서는 이런 순서가 된다.

먼저 과업을 정의하고, 필요한 자료를 고르고, 기준과 제약을 정리하고, 현재 상태를 표시한 다음, 마지막으로 그 모든 것을 바탕으로 프롬프트를 쓴다. 즉, 프롬프트는 끝이 아니라 설계의 마지막 표현에 가깝다.

컨텍스트 엔지니어링의 핵심은 "필요한 정보만 적시에"다

컨텍스트 엔지니어링을 처음 배우면 많은 사람이 갑자기 욕심이 생긴다. "그럼 중요한 건 다 넣어야겠네?" 하고 생각하는 것이다. 하지만 실전은 그 반대다. 잘하는 사람일수록 다 넣지 않는다.

왜냐하면 AI는 정보가 많다고 해서 자동으로 더 똑똑해지지 않기 때문이다. 오히려 덜 중요한 정보가 중요한 정보를 가릴 수 있다. 오래된 결정이 최신 결정과 섞일 수도 있고, 배경 설명이 핵심 기준보다 앞에 나와 방향을 흐릴 수도 있다.

그래서 좋은 컨텍스트 엔지니어링은 "많이 넣기"가 아니라 "잘 고르기"다. 더 정확하게 말하면, 지금 단계에 필요한 정보만 앞쪽에 놓고, 나머지는 뒤로 보내거나 나중에 불러오는 것이다.

사람도 회의 시작하자마자 지난 6개월의 모든 메모를 한꺼번에 읽지 않는다. 오늘 결정해야 할 문제와 관련된 핵심만 먼저 본다. AI에게도 같은 배려가 필요하다.

컨텍스트를 설계할 때 가장 먼저 생각해야 할 것

입문 단계에서 가장 유용한 질문은 이것이다.

"이 작업에서 AI가 틀리면 안 되는 것은 무엇인가?"

이 질문을 던지면 중요한 정보가 드러난다. 브랜드 톤이 틀리면 안 되는가? 숫자가 틀리면 안 되는가? 정책 기준을 어기면 안 되는가? 법적 문구가 틀리면 안 되는가? 독자 수준이 어긋나면 안 되는가?

이렇게 핵심 리스크를 먼저 잡으면, 어떤 정보를 앞에 둘지도 정하기 쉬워진다. 숫자가 중요하면 최신 수치와 출처를 앞에 둬야 하고, 정책 준수가 중요하면 공식 기준 문서를 최우선으로 둬야 하며, 톤이 중요하면 좋은 예시와 금지 표현을 함께 줘야 한다.

컨텍스트 엔지니어링은 멋진 구조를 만드는 일이 아니라, 실수 비용이 큰 지점을 먼저 막는 일이라고 생각하면 훨씬 실용적이다.

작은 예시로 보는 차이

같은 작업이라도 컨텍스트 설계 여부에 따라 결과는 크게 달라진다.

단순한 요청은 이렇다.

우리 서비스 소개 글을 써 줘.

이 문장은 틀린 말이 없다. 하지만 AI 입장에서는 빈칸이 너무 많다. 누구에게 소개하는지, 어떤 톤인지, 어떤 기능을 강조할지, 경쟁사 대비 무엇이 다른지, 과장 표현은 가능한지 모두 불분명하다.

컨텍스트를 설계하면 요청은 이렇게 바뀐다.

작업: 신규 고객용 서비스 소개 글 초안 작성

독자: 처음 서비스를 접하는 중소기업 운영자

목표: 기능 나열보다 문제 해결 가치를 먼저 이해시키기

기준: 가격과 출시 일정은 확정되지 않았으므로 단정하지 말 것

강조할 점: 자동화, 사용 편의성, 기존 업무 도구와의 연결성

피할 점: 업계 1위, 혁신적 같은 과장 표현

출력: 500자 이내 소개문 + 핵심 장점 3개

이제 AI는 같은 "소개 글"이라도 훨씬 좁고 정확한 공간 안에서 움직인다. 여기서 좋아진 것은 문장 기술이 아니라, 작업 환경의 밀도다.

컨텍스트 엔지니어링은 정보를 정리하는 일만이 아니다

이쯤 되면 어떤 사람은 이렇게 생각할 수 있다. "결국 정리 잘하라는 말 아닌가?" 맞다. 그런데 거기서 한 단계 더 나가야 한다. 컨텍스트 엔지니어링은 정리만이 아니라 흐름 관리까지 포함한다.

예를 들어 긴 작업에서는 한 번에 모든 것을 넣는 방식보다, 단계별로 다른 정보를 주는 방식이 낫다. 초안 단계에서는 큰 방향과 재료를 주고, 비평 단계에서는 평가 기준과 반례를 주고, 최종 정리 단계에서는 형식 규칙과 체크리스트를 주는 식이다.

즉, 컨텍스트는 정적인 서류철이 아니라 움직이는 작업판이다. 작업이 바뀌면 필요한 정보도 바뀐다. 잘하는 사용자는 그 변화를 따라 컨텍스트를 갱신한다.

초보자가 바로 적용할 수 있는 기본 흐름

처음부터 복잡한 시스템을 만들 필요는 없다. 다음 흐름만 익혀도 컨텍스트 엔지니어링의 감이 생긴다.

1. 과업을 한 문장으로 고정한다

먼저 "무엇을 만들 것인가"를 한 문장으로 쓴다. 이 문장이 흔들리면 뒤의 모든 정보도 흔들린다.

예를 들어 "보고서를 써 줘"보다 "임원 검토용 한 페이지 요약 메모를 작성해 줘"가 훨씬 낫다. 결과물의 성격이 바로 정해지기 때문이다.

2. 필요한 재료만 고른다

자료가 많다고 다 넣지 않는다. 이번 작업에 직접 필요한 것만 고른다. 그리고 기준 문서, 배경 문서, 참고 예시를 구분한다.

핵심은 "있으면 좋을 정보"와 "없으면 안 되는 정보"를 나누는 것이다. 둘을 섞어 넣으면 AI도 우선순위를 잃는다.

3. 규칙과 금지사항을 짧게 적는다

모델은 생각보다 금지선이 분명할수록 안정적이다. 반드시 지켜야 할 기준, 피해야 할 표현, 확정되지 않은 요소를 짧고 선명하게 적는다.

여기서 욕심내어 규칙을 백 개 쓰면 다시 흐려진다. 정말 중요한 것부터 적는 것이 좋다.

4. 현재 상태를 표시한다

초안인지, 검토인지, 수정인지, 비교인지 적는다. 그리고 이미 결정된 것과 아직 미정인 것을 나눈다.

이 정보 하나만 있어도 AI는 쓸데없이 결론을 확정하거나, 이미 끝난 논의를 다시 꺼내는 일을 줄인다.

5. 결과를 받은 뒤 컨텍스트를 업데이트한다

좋은 결과가 나왔든 아니든, 그 결과를 바탕으로 다음 단계의 컨텍스트를 다시 만든다. 유지할 결정사항은 남기고, 필요 없는 정보는 덜어 내고, 새로 생긴 쟁점은 추가한다.

이 반복이 쌓이면 대화는 점점 더 생산적으로 변한다.

실전에서 자주 망가지는 지점

컨텍스트 엔지니어링은 멋있어 보이지만, 실제로는 아주 사소한 곳에서 자주 무너진다.

첫째, 정보의 권위가 섞일 때다. 공식 정책, 개인 의견, 오래된 회의 메모가 같은 무게로 들어가면 AI는 무엇을 믿어야 할지 헷갈린다.

둘째, 최신 상태가 표시되지 않을 때다. 지난주 결정과 오늘 수정사항이 함께 있는데 무엇이 최신인지 표시하지 않으면 답이 과거로 돌아간다.

셋째, 단계 구분이 없을 때다. 브레인스토밍 단계와 최종 문안 단계의 규칙이 같은데도 한 프롬프트 안에 다 넣어 버리면 답이 애매해진다. 넓게도 못 가고 좁게도 못 간다.

넷째, 핵심 기준이 자료 속에만 숨어 있을 때다. 정말 중요한 규칙은 문서 안에만 묻어 두지 말고 지시문 바깥으로 끌어내야 한다. AI가 읽을 수 없는 것이 아니라, 읽더라도 중심이라고 판단하지 못할 수 있기 때문이다.

다섯째, 이전 대화의 잔재를 그대로 끌고 갈 때다. 이미 폐기한 방향, 무효가 된 제약, 초기에만 필요했던 배경을 계속 붙들고 있으면 작업이 무거워진다. 컨텍스트에도 청소가 필요하다.

컨텍스트 엔지니어링은 결국 "선택"의 기술이다

이 개념을 어렵게 만드는 이유는 엔지니어링이라는 말 때문이다. 마치 대단한 시스템을 짜야 할 것 같고, 복잡한 자동화가 있어야 할 것 같다. 물론 나중에는 그렇게 발전할 수 있다. 하지만 입문 단계에서 더 중요한 것은 화려한 기술이 아니라 선택하는 감각이다.

무엇을 남기고 무엇을 뺄 것인가. 무엇을 앞에 두고 무엇을 뒤에 둘 것인가. 무엇을 지금 주고 무엇을 다음 턴에 줄 것인가. 무엇을 기준으로 삼고 무엇을 참고로 둘 것인가.

이 선택이 좋아질수록 AI의 답은 단순히 더 길어지는 것이 아니라, 더 맞아진다.

"말 잘하기"에서 "정보 설계"로 넘어간 사람의 특징

AI를 오래 잘 쓰는 사람들은 공통점이 있다. 질문을 감각적으로 던지는 데서 끝나지 않는다. 일을 받으면 먼저 머릿속에서 구조를 만든다.

이 사람들은 보통 이런 식으로 생각한다. 지금 필요한 배경은 무엇인지, 기준 문서는 무엇인지, 아직 결정되지 않은 부분은 무엇인지, 이번 턴에서 만들 산출물은 무엇인지, 다음 턴에서 검토할 포인트는 무엇인지부터 정리한다.

즉, AI를 잘 쓰는 것은 단순히 대화를 잘하는 능력이 아니다. 생각을 작업 가능한 단위로 구조화하는 능력이다. 프롬프트는 그 구조를 바깥으로 드러내는 마지막 문장일 뿐이다.

아주 간단한 입문 템플릿

처음에는 아래 형식만으로도 충분하다.

작업

이번 턴에서 AI가 해야 할 일 한 문장

목표

왜 이 작업을 하는지

기준 정보

반드시 따라야 할 문서, 규칙, 최신 결정사항

참고 정보

있으면 도움이 되지만 최우선은 아닌 자료

현재 상태

초안 / 비교 / 수정 / 검토 중 어디인지

제약

금지 표현, 길이 제한, 독자 수준, 미확정 요소

출력

원하는 결과 형식

이 틀의 좋은 점은 복잡하지 않다는 데 있다. 그리고 바로 그 단순함 때문에 반복하기 쉽다. 컨텍스트 엔지니어링은 어려운 이론을 외우는 것보다, 매번 같은 틀로 생각하는 습관에서 시작된다.

좋은 컨텍스트는 AI를 똑똑하게 보이게 한다

사실 모델이 갑자기 더 똑똑해진 것이 아닌데도, 컨텍스트를 잘 설계하면 결과가 놀랄 만큼 좋아질 때가 있다. 많은 사용자가 이 순간에 "이 모델이 원래 이렇게 잘했나?" 하고 느낀다.

하지만 비밀은 모델 안보다 바깥에 있다. AI가 잘한 것이기도 하지만, 그보다 먼저 잘 생각된 작업 환경이 주어진 것이다. 좋은 컨텍스트는 모델의 능력을 끌어내고, 나쁜 컨텍스트는 모델의 능력을 묻어 버린다.

그래서 컨텍스트 엔지니어링은 부가 기술이 아니다. 실전 활용에서 점점 중심으로 올라오는 이유가 여기에 있다.

이 장의 정리

컨텍스트 엔지니어링은 AI에게 정보를 많이 넣는 기술이 아니다. 지금 필요한 정보를, 적절한 형태로, 적절한 시점에 배치하는 기술이다.

프롬프트 엔지니어링이 요청을 잘 쓰는 일이라면, 컨텍스트 엔지니어링은 그 요청이 제대로 작동하도록 작업 공간을 설계하는 일이다. 여기에는 과업, 재료, 규칙, 상태가 함께 들어간다. 그리고 무엇보다 중요한 것은 양이 아니라 선택과 우선순위다.

AI 활용의 다음 단계가 왜 "말 잘하기"가 아니라 "정보 설계"인지 이제 감이 올 것이다. 잘 쓰는 사람은 특별한 마법 문장을 아는 사람이 아니라, AI가 헤매지 않도록 일할 환경을 먼저 만들어 주는 사람이다.

다음 장에서는 이 관점을 더 긴 작업으로 가져가 보겠다. 대화가 길어지고 자료가 늘어날수록, 한 번 만든 컨텍스트를 어떻게 유지하고 갱신할지가 중요해진다. 결국 좋은 시작만큼 중요한 것은 문맥을 오래 잃지 않는 운영 방식이기 때문이다.