컨텍스트 엔지니어링과 DSPy 실습 정리 — 맥락 오염, 평가 설계, 도구 호출과 RAG까지

핵심 메시지

• 컨텍스트 엔지니어링은 단일 프롬프트를 잘 쓰는 일이 아니라, 모델의 맥락 창을 무엇으로 채울지 설계하는 작업 전체를 가리킨다.
• 맥락 창이 크다고 전부 밀어 넣으면 안 된다. 불필요한 정보가 이해를 오염시켜 오히려 성능이 떨어진다.
• DSPy는 입출력 계약을 선언하는 시그니처와 데이터 흐름을 정의하는 모듈로, 프롬프트를 프로그램처럼 다루게 해준다.
• 언어 모델은 자기 앞에 놓인 결과물을 후하게 평가하는 편향이 있어, 점수를 매기게 하기보다 여러 후보의 순위를 강제하는 편이 낫다.
• 관측과 평가를 먼저 설계하지 않으면 어떤 변경이 실제로 도움이 됐는지 판단할 방법이 없다.

쉽게 이해하기

영상은 컨텍스트 엔지니어링을 안드레이 카파시의 표현을 빌려 정의한다. 모델에게 일을 시키기 전에 맥락 창에 정보를 알맞게 채워 넣는 섬세한 기술이라는 것이다. 여기에는 과제를 하위 문제로 쪼개고 제어 흐름으로 연결하는 일, 도구 호출이나 검색으로 정보를 끌어오는 일, 그리고 가드레일과 평가, 메모리, 캐싱까지 모두 포함된다.

그렇다면 맥락 창이 100만 토큰이니 전부 넣으면 되지 않느냐는 질문에 발표자는 그렇지 않다고 답한다. 불필요한 정보가 많이 들어가면 모델의 전반적 이해가 오염돼 환각이 늘거나 질문과 무관한 패턴을 붙잡는 현상이 보고돼 있기 때문이다. 실습은 파이썬과 DSPy로 진행되는데, 구조화된 출력의 검증을 프레임워크가 대신 처리해준다는 점이 선택 이유로 제시된다.

설계의 출발점은 머릿속에 그래프를 그리는 것이다. 입력에서 출력으로 한 번에 가는 단순 흐름에서 시작해, 결과를 되먹여 다듬는 반복 개선, 조건에 따라 경로를 나누는 분기, 후보를 병렬로 여러 개 만들어 심판 모델에게 순위를 매기게 하는 구조로 확장한다. 모듈마다 다른 모델과 온도를 지정할 수 있어, 비싼 모델은 정말 필요한 단계에만 붙일 수 있다.

여기서 중요한 함정이 하나 드러난다. 결과물 하나를 주고 좋냐고 물으면 모델은 대체로 좋다고 답한다는 것이다. 그래서 단일 채점 대신 여러 후보를 동시에 놓고 순위를 강제하는 비교 방식으로 바꾸고, 순위가 규칙대로 나오지 않을 경우에 대비해 보상 함수로 형식을 되돌려 잡는 장치까지 붙인다.

후반부는 관측과 평가, 그리고 외부 정보 연결을 다룬다. MLflow를 붙이면 네 줄 남짓으로 모듈별 입출력과 토큰 사용량, 지연 시간이 추적된다. 정답이 없는 과제는 하이퍼파라미터를 무작위로 조합해 결과를 모은 뒤, 두 개씩 뽑아 어느 쪽이 나은지 겨루게 하는 방식으로 점수를 만든다. 마지막으로 웹 검색 도구 호출과 MCP 연결, 임베딩·키워드 검색의 결합, 그리고 파일이나 전용 시스템에 대화 기억을 남기는 메모리까지 이어진다.

주요 인사이트

• 맥락은 많을수록 좋은 자원이 아니라 관리 대상이다. 정보를 더 넣으면 성능이 올라간다는 직관과 달리, 관련 없는 내용이 섞이면 모델의 판단 자체가 흐려진다.
• 반복 개선과 형식 교정 같은 장치는 품질을 올리는 대신 지연 시간과 토큰 비용을 함께 늘린다. 몇 번 반복할지 같은 값은 감이 아니라 측정으로 정해야 한다.
• 정답이 없는 결과물은 절대 점수 대신 상대 비교로 평가할 수 있다. 두 결과를 짝지어 승패를 누적하는 방식이면 '더 재미있는 농담' 같은 주관적 목표도 데이터로 다룰 수 있다.
• 시맨틱 검색과 키워드 검색은 양자택일이 아니다. 두 결과 목록을 상호 순위 융합으로 합치면 각 방식의 약점을 서로 메운다. 냉장고 매뉴얼에서 특정 모델명을 찾는 일처럼 키워드 검색이 더 정확한 경우도 분명히 있다.
• 출력 형식을 지정하는 것 자체가 컨텍스트 엔지니어링이다. 인용한 자료의 번호를 함께 내놓으라고 요구하면 모델은 그 자료를 실제로 쓰는 방향으로 생성 경로가 기울어진다.

자주 묻는 질문

관련 AI 소식