AI 에이전트의 예시 데이터는 어떻게 다룰까 — 컨텍스트 엔지니어링부터 파인튜닝 준비까지

제조업 개발자를 위한 AI 에이전트를 만들면서 꽤 오래 붙잡고 있던 질문이 있습니다. 예시 데이터를 어떻게 다룰 것인가. 예시를 몇 개 넣을지, 어떤 예시를 넣을지, 예시가 쌓이면 어떻게 할지.

이 글은 정답을 제시하는 글이 아닙니다. 실제로 개발하면서 내린 판단과 그 기준을 기록한 글입니다. 흐름은 단순합니다. 지금은 이렇게 하고, 이런 신호가 오면 다음 단계로 간다.

Why — 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

예시 데이터 이야기를 하기 전에, 이 고민의 바탕이 된 개념부터 짚겠습니다. 요즘은 프롬프트 엔지니어링을 넘어 컨텍스트 엔지니어링이 중요해졌다는 이야기를 많이 합니다.

둘의 차이는 다루는 범위에 있습니다.

• 프롬프트 엔지니어링은 지시문을 잘 쓰는 기술입니다.
• 컨텍스트 엔지니어링은 지시문을 포함해 도구, 외부 데이터, 대화 기록까지 모델이 보는 모든 정보 중에서 무엇을 넣고 무엇을 뺄지 고르고, 작업이 길어지는 동안 그 상태를 관리하는 기술입니다.

Anthropic은 컨텍스트 엔지니어링에 관한 글에서 이걸 프롬프트 엔지니어링의 자연스러운 발전이라고 설명합니다. 프롬프트를 쓰는 건 한 번에 끝나는 일이지만, 컨텍스트 엔지니어링은 모델에게 무언가를 넘길 때마다 다시 고르는 반복적인 일이라는 거죠.

같은 글에서 핵심 원칙을 이렇게 정리합니다. 원하는 결과가 나올 가능성을 최대화하는, 가능한 가장 작은 고신호(high-signal) 토큰 집합을 찾는 것.

왜 “가장 작은”이 중요할까요? 컨텍스트가 길어질수록 모델이 그 안의 정보를 정확히 떠올리는 능력이 떨어지기 때문입니다. 글은 이를 context rot라고 부르고, 모델에게는 일종의 주의력 예산(attention budget)이 있어서 토큰 하나를 더할 때마다 그 예산을 쓴다고 설명합니다. 컨텍스트는 많이 넣을수록 좋은 게 아니라, 넣을수록 효용이 줄어드는 유한한 자원입니다.

그래서 컨텍스트 엔지니어링의 중심은 넣는 것보다 고르고 덜어내는 것에 있습니다. 예시 데이터를 다루는 제 고민도 결국 이 질문이었습니다. 어떤 예시를, 얼마나, 언제 넣을 것인가.

지금의 방식 — 예시는 에이전트가 골라 넣는다

처음에는 가지고 있는 예시를 전부 넣는 방식을 떠올렸습니다. 예시가 많을수록 모델이 더 잘 따라 할 거라는 직관이었죠. 하지만 앞서 본 원칙대로라면 이건 정반대의 선택입니다. 지금 작업과 관련 없는 예시까지 모두 넣으면, 관련 있는 예시의 신호가 묻힙니다.

그래서 예시를 전부 넣지 않고, 지금 작업에 맞는 예시를 에이전트가 판단해서 골라 넣도록 했습니다.

작업이 들어온다
      ↓
에이전트가 작업을 읽고, 예시 목록에서 지금 필요한 것을 고른다
      ↓
고른 예시만 컨텍스트에 넣고 결과를 생성한다

왜 에이전트에게 맡겼나

예시를 고르는 방법은 여러 가지가 있습니다. 예시마다 태그를 달아두고 태그가 일치하는 것을 가져오는 방식, 구조가 비슷한 것을 규칙으로 찾는 방식 같은 것들이요.

그런데 이 도메인에서는 그게 잘 맞지 않았습니다. “이 작업과 이 예시가 비슷하다”를 판단하는 조건이 까다로웠기 때문입니다. 겉으로 드러나는 태그나 구조가 같아도 실제로는 참고하면 안 되는 예시가 있었고, 반대로 겉모습은 달라도 패턴이 같아서 꼭 참고해야 하는 예시도 있었습니다. 이 판단은 단순한 일치 여부가 아니라 패턴을 읽어내는 일이었고, 그래서 규칙보다 에이전트의 판단이 더 잘 맞았습니다.

이것이 컨텍스트 엔지니어링이다

돌아보면, 이 선택은 컨텍스트 엔지니어링을 실제로 적용한 사례였습니다.

Anthropic의 글은 예시(few-shot)를 여전히 강력히 권장하는 방법으로 꼽으면서도, 예외 상황을 잔뜩 나열하기보다는 다양하고 대표적인 예시를 잘 골라서 보여주라고 말합니다. 또 필요한 정보를 미리 다 넣어두는 대신, 에이전트가 가벼운 참조만 들고 있다가 필요한 순간에 필요한 것만 불러오는(just-in-time) 방식도 소개합니다.

제가 한 일은 이 두 가지를 예시 데이터에 적용한 것에 가깝습니다. 예시를 큐레이션하되, 그 큐레이션을 작업마다 에이전트가 수행하게 한 거죠. 컨텍스트에 들어가는 예시는 줄어들고, 남은 예시의 신호는 강해집니다.

고르는 것 자체도 평가한다

예시를 에이전트가 고르게 하고 나니 새로운 문제가 보였습니다. 결과가 나쁠 때, 원인이 어디에 있는지 알 수 없다는 문제입니다.

최종 결과만 평가하면, 결과가 나쁜 이유가 두 가지 중 무엇인지 구분되지 않습니다.

1. 예시를 잘못 골라서 나빠졌다
2. 예시는 제대로 골랐는데 그걸 보고 생성을 잘 못해서 나빠졌다

이 둘은 고치는 방법이 완전히 다릅니다. 1번이라면 예시를 고르는 판단을 개선해야 하고, 2번이라면 생성하는 쪽을 개선해야 합니다. 원인을 모른 채 고치면, 멀쩡한 쪽을 건드리게 됩니다.

그래서 예시 선택 자체를 평가하는 체계를 추가하려 합니다. 방식은 이렇습니다.

• 평가 케이스마다 골라야 할 예시를 정답으로 정해둡니다.
• 에이전트가 고른 예시를 정답과 비교해서 두 가지를 확인합니다.
  • 필요한 예시를 놓쳤는지 (빠뜨림)
  • 관련 없는 예시를 넣었는지 (끼어듦)

이렇게 하면 평가가 두 층으로 나뉩니다. 예시 선택은 제대로 했는지, 그리고 그 예시로 결과를 제대로 만들었는지. 결과가 나쁠 때 어느 층에서 문제가 생겼는지 바로 보이게 됩니다.

다음 단계로 넘어가는 기준

지금의 방식이 끝까지 가는 답은 아닙니다. 다음 단계가 있다는 걸 알고 있고, 중요한 건 언제 넘어갈지의 기준을 미리 정해두는 것이라고 생각했습니다.

벡터화(임베딩 검색) — 아직 이르다

예시를 고르는 일반적인 방법은 예시를 임베딩해두고 작업과 유사한 것을 검색해 오는 방식입니다. Anthropic의 글에서도 추론 전에 임베딩 기반으로 관련 데이터를 미리 가져오는 방식을 전통적인 접근으로 소개합니다.

하지만 지금은 이르다고 판단했습니다. 예시가 아직 적기 때문입니다. 예시가 적을 때는 에이전트가 예시 목록을 직접 보고 고르는 게 충분히 빠르고, 앞서 말한 것처럼 패턴을 읽는 판단이 유사도 검색보다 정확합니다. 벡터 검색을 도입하면 임베딩 파이프라인과 인덱스를 관리하는 비용이 생기는데, 지금 규모에서는 얻는 것보다 그 비용이 큽니다.

넘어가는 신호는 시간입니다. 예시가 늘어나서 에이전트가 예시를 고르는 데 걸리는 시간이 늘어나기 시작하면, 그때 도입합니다. 그때도 에이전트의 판단을 버리는 게 아니라, 벡터 검색으로 후보를 좁히고 그 안에서 에이전트가 고르는 방식이 자연스러운 다음 단계가 될 것 같습니다. 글에서 말하는, 미리 가져오는 것과 필요할 때 탐색하는 것을 섞는 하이브리드 방식이죠.

파인튜닝 — 예시만으로는 한계가 있다

예시를 계속 넣어보면서 하나 분명해진 게 있습니다. 예시만으로는 결국 한계가 있다는 것입니다.

예시는 “이런 경우에는 이렇게 했다”를 보여주는 데는 강합니다. 그런데 모든 작업에 공통으로 적용되는 작업 패턴까지 매번 예시로 보여주는 건 비효율적입니다. 어떤 작업이 오든 반복되는 패턴이라면, 그걸 매 호출마다 컨텍스트에 실어 보내는 대신 모델 자체가 알고 있게 만드는 편이 맞습니다.

그래서 역할을 나누는 방향으로 판단했습니다.

해결할 것	방법
케이스마다 달라지는 참고	예시 선택 (컨텍스트)
모든 케이스에 공통인 작업 패턴	파인튜닝 (모델)

이렇게 나누면 컨텍스트 엔지니어링 관점에서도 이득입니다. 공통 패턴이 모델 안으로 들어가면, 컨텍스트에는 정말 그 케이스에 필요한 예시만 남습니다. 컨텍스트는 더 작아지고 신호는 더 강해집니다.

파인튜닝을 위해 지금부터 준비하는 것

파인튜닝은 결정했다고 바로 할 수 있는 게 아니라서, 지금부터 준비하고 있는 것이 세 가지 있습니다.

• 평가를 통과한 결과를 학습 데이터로 모으고 있습니다. 이미 평가 체계가 있으니, 그 기준을 통과한 결과물은 품질이 검증된 데이터입니다. 따로 데이터를 만들지 않아도 운영하면서 학습 데이터가 쌓입니다.
• 현재 방식의 평가 점수를 비교 기준으로 남겨두었습니다. 파인튜닝을 하고 나서 “좋아졌다”고 말하려면, 무엇보다 좋아졌는지 비교할 기준이 있어야 합니다. 예시 선택 방식만으로 낸 지금의 점수가 그 기준입니다.
• 평가셋은 학습에 쓰지 않습니다. 평가에 쓰는 데이터가 학습에 섞이면, 모델은 평가 문제의 답을 외운 상태가 됩니다. 점수는 올라가도 실제 실력이 늘었는지는 알 수 없습니다. 그래서 평가셋은 처음부터 분리해 둡니다.

학습 데이터는 실제 코드라서, 치환한다

파인튜닝 준비에서 가장 신경 쓰이는 부분이 하나 더 있습니다. 이 에이전트의 결과물은 실제 현장에서 쓰는 코드라는 점입니다. 그대로 학습 데이터로 쓰면, 그 안에 담긴 민감한 정보가 함께 들어갑니다. 유출되어서는 안 되는 정보입니다.

그래서 파인튜닝 전에 데이터 치환을 할 예정입니다. 치환의 원칙은 세 가지로 정했습니다.

1. 민감 정보는 치환하되, 배워야 할 패턴은 남긴다. 고객, 설비, 접속 정보 같은 민감 정보는 다른 값으로 바꿉니다. 하지만 모델이 학습해야 하는 건 코드의 구조와 작업 패턴입니다. 치환하다가 그 패턴까지 지워버리면 학습할 이유가 사라집니다. 바꿀 것은 “무엇에 대한 코드인가”이고, 남길 것은 “어떻게 짜는가”입니다.

2. 같은 원본은 항상 같은 값으로 치환한다. 한 곳에서 A로 바뀐 값이 다른 곳에서 B로 바뀌면, 코드 안의 관계가 깨집니다. 같은 대상을 가리키던 여러 줄이 서로 다른 대상을 가리키게 되는 거죠. 그러면 모델은 잘못된 관계를 학습합니다. 그래서 치환은 일관된 매핑으로 합니다.

3. 치환 후 코드가 깨지지 않았는지 검증한다. 치환은 코드를 직접 바꾸는 작업이라, 문법이 깨지거나 동작이 달라질 수 있습니다. 깨진 코드를 학습하면 깨진 코드를 생성하는 모델이 됩니다. 그래서 치환한 결과가 여전히 올바른 코드인지 확인하는 단계를 둡니다.

치환은 출력 보호이기도 하다

치환이 학습 데이터를 보호하기 위한 것만은 아닙니다. 파인튜닝된 모델은 학습 데이터를 외워서 그대로 출력할 수 있습니다. 민감 정보가 담긴 코드를 그대로 학습시키면, 나중에 전혀 다른 작업을 할 때 그 정보가 모델의 출력으로 흘러나올 수 있습니다.

그래서 치환은 학습 데이터를 지키는 일인 동시에, 모델이 내보내는 출력을 지키는 일이기도 합니다. 데이터가 모델 밖에 있을 때만이 아니라, 모델 안으로 들어간 뒤까지 생각해야 한다는 걸 이번에 정리하게 됐습니다.

정리 — 작게 시작하고, 신호를 보고 넘어간다

지금까지의 판단을 한 장으로 모으면 이렇습니다.

영역	지금	다음 단계로 가는 신호	다음 단계
예시 선택	에이전트가 판단해서 고른다	고르는 시간이 늘어난다	벡터 검색으로 후보를 좁히고 에이전트가 고른다
평가	최종 결과 평가	결과가 나쁜 원인을 구분할 수 없다	예시 선택 자체를 평가한다
공통 패턴	예시로 보여준다	예시만으로는 한계가 보인다	파인튜닝
학습 데이터	평가 통과 결과를 모은다	파인튜닝을 시작한다	치환하고 검증한 뒤 학습한다

결국 원칙은 하나입니다. 데이터가 적을 때는 작게 시작하고, 평가로 신호를 확인하며 다음 단계로 넘어간다.

이건 이전 글 데이터가 작을 때의 온톨로지 설계에서 정리한 원칙의 연장선이기도 합니다. 그때는 온톨로지를 그래프 DB 대신 작은 문서로 시작했고, 이번에는 예시를 벡터 검색 대신 에이전트의 판단으로 시작했습니다. 대상은 달라도 판단 기준은 같았습니다. 규모가 방식을 정하게 하고, 다음 방식으로 넘어갈 때는 감이 아니라 신호를 근거로 삼는 것.

---

📚 시리즈: AI 에이전트, 만들고 평가하기

1. Workflow와 Agent, 그리고 하네스 — LLM에게 얼마만큼의 자유를 줄 것인가
2. 에이전트의 도구(Tool)와 세 층의 평가 — 선택·실행·결과
3. 멀티에이전트의 두 숙제 — 토큰 비용과 안정성, 그리고 평가라는 해법
4. ReAct와 Plan-and-Execute를 LangGraph로 직접 구현하며 배운 것
5. 그래서 Agent에 데이터를 어떻게 입히나요? — 데이터가 작을 때의 온톨로지 설계
6. 제조업 AI 에이전트 프로젝트 1차 회고 — 평가, 저장소, 코드 정리에 대한 세 가지 교훈
7. AI 에이전트의 예시 데이터는 어떻게 다룰까 — 컨텍스트 엔지니어링부터 파인튜닝 준비까지 ← 지금 글