Metadata

source	https://www.oreilly.com/radar/context-engineering-bringing-engineering-discipline-to-prompts-part-2/
created	2026-04-04
by	openai:gpt-5.4

Context Engineering: 프롬프트에 엔지니어링 규율을 도입하기--2부

다음 글은 애디 오스마니(Addy Osmani)의 원문 " 컨텍스트 엔지니어링: 파트(Parts)에 엔지니어링 규율을 도입하기" 3부작 중 2부이다. 1부는 여기에서 볼 수 있다.

훌륭한 컨텍스트 엔지니어링은 균형이 핵심이다. 모델에 정말 필요한 것은 모두 넣되, 주의를 흐리게 하거나 비용만 늘리는 무관하거나 과도한 세부 사항은 피해야 한다.

안드레이 카파시(Andrej Karpathy)가 설명했듯이, 컨텍스트 엔지니어링은 과학(science)과 예술(art)이 정교하게 섞인 작업이다.

여기서 “과학”은 성능을 체계적으로 높이기 위한 원칙과 기법을 따르는 일을 말한다. 예를 들어 코드 생성이라면 관련 코드와 오류 메시지를 포함해야 한다는 점은 거의 과학에 가깝다. 질의응답 작업이라면 뒷받침 문서를 찾아 모델에 제공하는 것이 합리적이다. 소수 예시 프롬프팅(few-shot prompting), 검색 증강 생성(retrieval-augmented generation, RAG), 연쇄적 사고 프롬프팅(chain-of-thought prompting)처럼 연구와 실험을 통해 성능 향상에 도움이 된다고 알려진 방법도 있다. 또 모델의 제약을 존중하는 것 역시 과학이다. 모든 모델에는 컨텍스트 길이 제한이 있다. 그 창을 지나치게 채우면 지연 시간과 비용이 늘어날 뿐 아니라, 중요한 정보가 잡음에 묻혀 품질이 오히려 떨어질 수도 있다.

카파시는 이를 이렇게 잘 요약했다. “컨텍스트가 너무 적거나 형식이 잘못되면 LLM은 최적 성능을 내는 데 필요한 올바른 컨텍스트를 갖지 못한다. 반대로 너무 많거나 너무 관련이 없으면 LLM 비용은 올라가고 성능은 떨어질 수 있다.”

즉, 과학은 컨텍스트를 최적으로 선택하고, 가지치기하고, 형식을 갖추는 기법에 있다. 예를 들어 임베딩(embeddings)을 이용해 포함할 문서 가운데 가장 관련성 높은 것을 찾으면 무관한 텍스트를 끼워 넣지 않게 된다. 긴 대화 이력을 요약으로 압축하는 방법도 있다. 연구자들은 긴 컨텍스트에서 나타나는 실패 양상도 정리해 왔다. 예를 들면 컨텍스트 오염(context poisoning)은 앞선 환각이 이후 오류를 낳는 경우이고, 컨텍스트 주의 분산(context distraction)은 쓸데없는 세부 사항이 너무 많아 모델이 초점을 잃는 경우다. 이런 함정을 알면 좋은 엔지니어는 컨텍스트를 더 신중하게 선별한다.

그리고 “예술”의 영역도 있다. 경험에서 나오는 직관과 창의성이다.

이 부분은 LLM의 특성과 미묘한 행동을 이해하는 일과 관련된다. 가독성 좋은 코드를 어떻게 짜야 하는지 “그냥 아는” 숙련 개발자를 떠올리면 된다. 경험 많은 컨텍스트 엔지니어는 특정 모델에 맞춰 프롬프트를 어떻게 구성해야 할지 감각이 생긴다. 예를 들어 어떤 모델은 세부 내용에 들어가기 전에 먼저 해결 접근법의 개요를 잡아주면 더 잘 작동한다고 느낄 수 있다. 그래서 프롬프트에 “단계별로 생각해 보자…” 같은 첫 단계를 넣는다. 또는 특정 도메인의 어떤 용어를 모델이 자주 오해한다는 점을 알아차리고, 컨텍스트 안에서 미리 뜻을 분명히 해둘 수도 있다. 이런 내용은 매뉴얼에 적혀 있지 않다. 모델 출력을 관찰하고 반복하면서 익히는 것이다. 바로 이 지점에서 프롬프트 작성(prompt-crafting)의 전통적 의미가 여전히 중요하다. 다만 이제는 더 큰 컨텍스트를 뒷받침하는 역할을 한다. 이는 소프트웨어 설계 패턴과 비슷하다. 공통 해법을 이해하는 데는 과학이 있고, 그것을 언제 어떻게 적용할지 판단하는 데는 예술이 있다.

이제 컨텍스트 엔지니어가 효과적인 컨텍스트를 만들 때 자주 쓰는 전략과 패턴 몇 가지를 살펴보자.

관련 지식 검색: 가장 강력한 기법 가운데 하나가 검색 증강 생성(retrieval-augmented generation)이다. 모델이 학습 기억 속에 반드시 들어 있다고 장담할 수 없는 사실이나 도메인 특화 데이터를 필요로 한다면, 시스템이 그 정보를 가져와 포함하게 하라. 예를 들어 문서 도우미를 만든다면 문서를 벡터 검색한 뒤, 질문을 던지기 전에 가장 잘 맞는 구절을 프롬프트에 삽입할 수 있다. 이렇게 하면 모델의 답변은 때때로 오래된 내부 지식이 아니라, 당신이 제공한 실제 데이터에 근거하게 된다. 여기서 핵심 역량은 적절한 검색 질의나 임베딩 공간을 설계해 올바른 조각(snippet)을 찾는 일, 그리고 삽입한 텍스트를 인용이나 따옴표와 함께 분명하게 형식화해 모델이 그것을 활용하도록 만드는 일이다. LLM이 사실을 “환각”하는 이유는 실제 사실을 제공하지 않았기 때문인 경우가 많다. 검색은 그에 대한 해독제다.

소수 예시와 역할 지시: 이것은 고전적 프롬프트 엔지니어링을 떠올리게 한다. 모델이 특정 스타일이나 형식으로 출력하게 하고 싶다면 예시를 보여주면 된다. 예를 들어 구조화된 JSON 출력을 원한다면 프롬프트에 JSON 형태의 입력과 출력 예시를 몇 개 넣은 뒤, 새로운 항목을 만들어 달라고 요청할 수 있다. 소수 예시 컨텍스트는 본보기로 모델을 가르치는 셈이다. 마찬가지로 시스템 역할(system role)이나 페르소나를 설정하면 어조와 행동을 유도할 수 있다. 예를 들면 “당신은 사용자를 돕는 전문 파이썬 개발자다…” 같은 식이다. 이런 기법이 기본 도구로 자리 잡은 이유는 실제로 효과가 있기 때문이다. 모델이 원하는 패턴 쪽으로 치우치게 만든다. 컨텍스트 엔지니어링 관점에서 보면 프롬프트 문구와 예시는 컨텍스트의 한 부분일 뿐이지만, 여전히 결정적으로 중요하다. 사실 프롬프트 엔지니어링, 즉 지시문과 예시를 설계하는 일은 이제 컨텍스트 엔지니어링의 부분집합(subset)이라고 할 수 있다. 여러 도구 중 하나일 뿐이다. 우리는 여전히 문구와 시범 예시에 큰 관심을 두지만, 그 주변에서 훨씬 더 많은 일을 함께 하고 있다.

상태와 메모리 관리: 많은 애플리케이션은 여러 차례의 상호작용이나 장시간 세션을 수반한다. 컨텍스트 창은 무한하지 않다. 그래서 컨텍스트 엔지니어링의 큰 부분은 대화 이력이나 중간 결과를 어떻게 다룰지 결정하는 일이다. 흔한 기법은 요약 압축(summary compression)이다. 몇 차례 상호작용이 지나면 전체 텍스트 대신 그 내용을 요약하고, 이후에는 그 요약을 이용한다. 예를 들어 앤트로픽의 클로드(Claude) 도우미는 대화가 길어지면 컨텍스트 넘침을 막기 위해 이를 자동으로 수행한다. 이전 턴을 압축한 “[이전 논의 요약]” 같은 문구가 나오는 것을 볼 수 있다. 또 다른 방법은 중요한 사실을 외부 저장소, 예컨대 파일이나 데이터베이스에 명시적으로 기록해 두었다가 필요할 때 다시 가져오는 것이다. 매 프롬프트마다 들고 다니지 않아도 된다. 일종의 외부 메모리다. 더 발전한 에이전트 프레임워크는 LLM이 “자기 자신에게 남기는 메모(notes to self)”를 생성하게 하고, 이를 저장한 뒤 나중 단계에서 다시 불러오게 하기도 한다. 여기서의 예술은 무엇을 남길지, 언제 요약할지, 어떻게 과거 정보를 적절한 시점에 다시 드러낼지를 판단하는 데 있다. 잘 해내면 AI는 매우 긴 작업에서도 일관성을 유지할 수 있다. 순수한 프롬프팅만으로는 어려운 일이다.

도구 사용과 환경 컨텍스트: 현대의 AI 에이전트는 작업 과정에서 도구를 사용할 수 있다. 예를 들면 API 호출, 코드 실행, 웹 탐색 같은 것들이다. 이때 각 도구의 출력은 다음 모델 호출을 위한 새로운 컨텍스트가 된다. 이런 시나리오에서 컨텍스트 엔지니어링은 모델에 도구를 언제, 어떻게 사용해야 하는지 지시하고, 그 결과를 다시 입력으로 돌려주는 일을 뜻한다. 예를 들어 에이전트에 “사용자가 수학 문제를 물으면 계산기 도구를 호출하라”는 규칙이 있을 수 있다. 도구를 사용한 뒤에는 결과, 예컨대 42를 프롬프트에 “도구 출력: 42”처럼 삽입한다. 그러려면 도구 출력을 분명히 형식화해야 하고, 경우에 따라 “이 결과를 바탕으로 이제 사용자의 질문에 답하라” 같은 후속 지시도 덧붙여야 한다. 에이전트 프레임워크(랭체인(LangChain) 등)에서 이뤄지는 많은 작업은 사실상 도구 사용을 둘러싼 컨텍스트 엔지니어링이다. 모델에 사용 가능한 도구 목록을 주고, 이를 호출하는 문법 지침을 함께 제공하며, 결과를 어떻게 반영할지 템플릿화한다. 핵심은 엔지니어인 당신이 모델과 외부 세계 사이의 대화를 오케스트레이션(orchestrate)한다는 점이다.

정보 형식화와 패키징: 앞에서도 언급했지만, 이 부분은 특히 중요하다. 포함할 수 있는 정보가 너무 많거나, 모두 넣는 것이 그다지 유용하지 않은 경우가 많다. 그래서 압축하거나 형식을 바꾼다. 모델이 코드를 작성하는데 대규모 코드베이스가 있다면, 전체 파일 대신 함수 시그니처나 독스트링(docstrings)만 넣어 컨텍스트를 줄 수 있다. 사용자 질의가 장황하다면 끝부분에 핵심 질문을 강조해 모델의 초점을 모을 수 있다. 제목, 코드 블록, 표 등 데이터를 가장 잘 전달하는 구조라면 무엇이든 써라. 예를 들어 “사용자 데이터: [방대한 JSON]… 이제 질문에 답하라.”라고 하기보다, 필요한 몇 개 필드만 뽑아 “사용자 이름: X, 계정 생성일: Y, 마지막 로그인: Z”처럼 제시하는 편이 낫다. 모델이 파악하기도 쉽고 토큰도 덜 든다. 요컨대 UX 디자이너처럼 생각하되, 당신의 “사용자”는 LLM이라는 점을 기억하라. 그것이 소비하기 좋게 프롬프트를 설계해야 한다.

이런 기법의 영향은 매우 크다. 복잡한 작업을 해결하는 인상적인 LLM 데모, 예를 들어 코드 디버깅이나 다단계 프로세스 계획 같은 것을 볼 때, 그 뒤에는 단 하나의 영리한 프롬프트만 있는 것이 아니라고 봐도 된다. 이를 가능하게 하는 컨텍스트 조립 파이프라인이 있다.

예를 들어 AI 페어 프로그래머는 다음과 같은 워크플로를 구현할 수 있다.

코드베이스에서 관련 코드를 검색한다.
그 코드 조각을 사용자 요청과 함께 프롬프트에 포함한다.
모델이 수정안을 제안하면 백그라운드에서 테스트를 실행한다.
테스트가 실패하면 실패 출력을 프롬프트에 다시 넣어 모델이 해법을 다듬게 한다.
테스트를 통과할 때까지 반복한다.

각 단계에는 신중하게 설계된 컨텍스트가 있다. 검색 결과와 테스트 출력 등이 각각 통제된 방식으로 모델에 공급된다. 그저 “내 버그를 고치라고 LLM에 프롬프트를 던지고 잘되길 바란다”는 수준과는 거리가 멀다.

컨텍스트 부패(context rot)의 과제

풍부한 컨텍스트를 조립하는 데 점점 능숙해질수록, 우리는 새로운 문제와 마주친다. 시간이 지나면서 컨텍스트가 스스로를 오염시킬 수 있다는 점이다. 해커 뉴스(Hacker News)에서 개발자 Workaccount2가 적절하게 “컨텍스트 부패(context rot)”라고 부른 이 현상은, 대화가 길어지고 산만한 요소, 막다른 시도, 저품질 정보가 쌓이면서 컨텍스트 품질이 떨어지는 현상을 뜻한다.

이 패턴은 답답할 만큼 흔하다. 세심하게 구성한 컨텍스트와 명확한 지시로 세션을 시작한다. 처음에는 AI가 훌륭하게 작동한다. 하지만 대화가 이어지면서, 특히 잘못된 출발, 디버깅 시도, 탐색적 옆길로 새는 과정이 생기면 컨텍스트 창은 점점 더 많은 잡음으로 채워진다. 그러면 모델의 응답은 서서히 부정확해지고 혼란스러워지며, 환각을 일으키기 시작한다.

컨텍스트 부패의 과제

왜 이런 일이 생길까? 컨텍스트 창은 단순한 저장 공간이 아니다. 모델의 작업 메모리다. 그 메모리가 실패한 시도, 모순된 정보, 곁가지 논의로 어질러지면, 오래된 초안과 무관한 종이들이 가득 쌓인 책상에서 일하는 것과 비슷해진다. 모델은 지금 중요한 것과 과거의 잡음을 구별하기 어려워진다. 대화 초반의 실수는 누적되며 문제를 키울 수 있다. 모델이 자기 자신의 좋지 않은 출력을 다시 참조하면서 점점 더 엉뚱한 방향으로 벗어나는 피드백 고리가 생기는 것이다.

이 문제는 특히 반복적 워크플로에서 심각하다. 공교롭게도 바로 그런 복잡한 작업에서 컨텍스트 엔지니어링의 강점이 빛난다. 디버깅 세션, 코드 리팩터링, 문서 편집, 연구 프로젝트에는 원래 잘못된 출발과 방향 수정이 자주 뒤따른다. 그러나 실패한 시도 하나하나는 컨텍스트 안에 흔적을 남기고, 이후 추론을 방해할 수 있다.

컨텍스트 부패를 관리하는 실용적 전략은 다음과 같다.

컨텍스트 가지치기와 새로 고침: Workaccount2의 해법은 이렇다. “저는 이를 해결하려고 인스턴스의 요약을 정기적으로 만들고, 새 컨텍스트를 가진 새 인스턴스를 띄운 뒤 이전 인스턴스의 요약을 넣습니다.” 이 접근법은 핵심 상태는 보존하면서 잡음은 버린다. 본질적으로 컨텍스트에 가비지 컬렉션을 수행하는 셈이다.
구조화된 컨텍스트 경계: 작업의 서로 다른 단계를 분리하도록 명확한 표시를 사용하라. 예를 들어 “이전 시도(참고용만)”와 “현재 작업 컨텍스트”를 분명히 구분해 표시할 수 있다. 그러면 모델이 무엇을 우선해야 하는지 이해하기 쉬워진다.
점진적 컨텍스트 정제: 의미 있는 진전이 생긴 뒤에는 의식적으로 컨텍스트를 처음부터 다시 구성하라. 핵심 결정, 성공한 접근법, 현재 상태를 추출한 뒤 새로 시작하는 것이다. 이는 코드 리팩터링과 비슷하다. 가끔은 쌓인 군더더기를 걷어내야 한다.
체크포인트 요약: 일정 간격마다 모델에게 지금까지 무엇을 해냈고 현재 상태가 어떤지 요약하게 하라. 새 세션을 시작할 때 이 요약을 새로운 컨텍스트의 씨앗으로 활용하면 된다.
컨텍스트 윈도잉(windowing): 아주 긴 작업은 컨텍스트를 재설정할 수 있는 자연스러운 경계를 기준으로 여러 단계로 나누어라. 각 단계는 이전 단계에서 꼭 필요한 내용만 넘겨받고 깨끗하게 시작한다.

이 과제는 또 하나의 사실을 드러낸다. “그냥 모든 것을 컨텍스트에 쏟아 넣는 것”은 장기적으로 성립하지 않는 전략이라는 점이다. 좋은 소프트웨어 아키텍처와 마찬가지로, 좋은 컨텍스트 엔지니어링에는 의도적인 정보 관리가 필요하다. 무엇을 포함할지만이 아니라, 무엇을 언제 제외하고, 요약하고, 새로 고칠지도 결정해야 한다.