주요 기사 요약
2026년 초거대 언어모델 분야에서 주목받는 기술은 Few-shot Learning이다. IBM과 Google이 발표한 최신 보고서에 따르면, 제한된 예시만으로도 모델의 성능을 극적으로 향상시킬 수 있다는 것이 증명되었다. 특히 금융 분야에서 GPT-4는 FinQA 데이터셋에서 78% 정확도를 달성했으며, 이는 평균적인 인간의 점수를 능가하는 수준이다. 또한 프롬프트 기반 메타 러닝(Meta-Learning)과 프로토타입 네트워크가 컴퓨터 비전에서 혁신적인 성과를 보이고 있다. 의료, 금융, 고객 서비스 등 다양한 산업에서 Few-shot Learning의 실용화가 가속화되고 있다.
모든 걸 Zero-shot으로 풀 수 있을 줄 알았다
우리 서비스는 지난 1년간 Zero-shot 프롬프팅으로 대부분의 작업을 처리했다. LLM이 사전학습된 모델이니 별도의 예시를 줄 필요 없이, 명확한 지시만 주면 될 거라고 생각했다. 처음엔 잘 작동했다. “고객 리뷰의 감정을 판단해줘”, “이 지원서를 검토해줘” 같은 작업들이 꽤 괜찮은 수준에서 돌아갔다.
하지만 3개월쯤 지나면서 문제가 보이기 시작했다. 우리 고객들의 데이터는 매우 도메인 특화적이었다. 부동산 관련 텍스트, 금융 계약서, 의료 기록 같은 전문적인 콘텐츠들이었다. Zero-shot 프롬프팅으로 이런 걸 처리하면 정확도가 70% 정도에 그쳤다. 때로는 형식을 이해하지 못해 쓸모없는 답변을 내보냈다.
“이정도면 괜찮지 않아?”라고 생각할 수도 있다. 하지만 우리의 고객은 금융사와 의료기관이었다. 70%는 프로덕션 서비스로는 절대 부족한 수준이었다. 정확도 90% 이상이 되어야 실제로 쓸 만했다.
이론적으로만 알던 Few-shot을 직접 해보다
Few-shot Learning이 뭔지는 알고 있었다. 적은 수의 예시를 모델에 보여줘서 패턴을 학습하게 하는 방식이다. 하지만 “실제로 몇 개의 예시가 필요할까?” “정말 성능이 달라질까?” 이런 궁금증은 남아있었다.
그래서 우리는 실험을 시작했다. 통제된 환경에서 정확히 검증해보기로 했다. 우리가 선택한 테스트 케이스는 “부동산 계약서에서 계약 금액 추출”이었다. 일반인이 봐도 쉬워 보이지만, 계약서 형식이 천차만별이라 실제로는 어려운 작업이다. 대출금, 선금, 후금, 수수료 등 여러 금액이 섞여 있고, 숫자로만 표기된 부분도 있고 글자로 표기된 부분도 있다.
테스트 셋으로 100개의 부동산 계약서를 준비했다. 이 중 10개는 우리가 추출한 정답과 함께 예시로 사용하기로 했다.
Zero-shot의 결과: 정확도 62%
먼저 Zero-shot으로 테스트했다. 프롬프트는 이런 식이었다:
“다음 텍스트는 부동산 계약서입니다. 이 계약서에서 계약 금액을 추출해주세요. 숫자로 된 금액만 반환하세요.”
결과는 예상보다 형편했다. 정확도는 62%였다. 계약 금액을 찾기는 했는데, 틀린 금액을 찾거나 여러 금액 중 잘못된 것을 선택하거나, 수수료를 계약금으로 잘못 인식하는 경우가 자주 발생했다.
특히 문제가 됐던 부분은 이거였다:
- “2억원에서 3천만원의 대출금을 빼면 1억7천만원” 같은 표현을 이해 못함
- 한글로 표기된 금액(“이억원”)을 제대로 인식 못함
- 선금 5천만원, 후금 1억5천만원이라는 표현에서 후금만 추출하거나, 둘을 더하버림
이미지다. 도메인 지식 없이는 불가능해 보였다.
Few-shot으로 5개 예시 추가: 정확도 87%
이번엔 정확한 부동산 계약서 예시 5개를 프롬프트에 포함시켰다. 각 예시는 계약서 일부와 “이 경우 정답은 2억원입니다”라는 형태였다.
예를 들면:
예시 1: [계약서 텍스트] -> 정답: 200,000,000원
예시 2: [다른 형식의 계약서 텍스트] -> 정답: 450,000,000원
…이런 식으로 5개를 넣었다. 예시 선택의 기준은 다양한 형식을 포함하는 것이었다. 숫자로만 표기된 것, 한글로 표기된 것, 선금/후금 구분이 있는 것, 대출금이 포함된 것 등등.
결과는 놀라웠다. 정확도가 62%에서 87%로 뛰어올랐다. 25%포인트의 향상이다.
특히 좋아진 부분들:
- 한글 금액 표기를 이제 제대로 인식함
- 선금/후금이 있을 때, 어떤 것이 최종 계약금인지 제대로 판단함
- “대출금을 제외한” 같은 표현을 이해하기 시작함
여전히 13%의 오류가 있었지만, 처음보다는 훨씬 낫다.
더 정교한 실험: 10개, 15개는?
정확도가 향상됐으니, 당연한 궁금증이 생겼다. “그럼 10개, 15개, 20개 예시를 주면?”
우리는 계속 실험했다. 예시 개수에 따른 정확도 변화를 측정했다:
- Zero-shot: 62%
- 5개 예시: 87%
- 10개 예시: 91%
- 15개 예시: 92%
- 20개 예시: 92%
15개부터는 증가 폭이 거의 없었다. 정확도 개선의 한계에 도달한 것 같았다. 그리고 재미있는 발견이 또 하나 있었다. 프롬프트 길이 때문에 응답 속도가 느려지기 시작했다.
왜 예시 5~10개에서 멈추는가
이건 우리가 예상 못 했던 부분이었다. 더 많은 예시가 무조건 더 좋은 줄 알았는데, 그게 아니었다. AI가 과도하게 많은 예시를 보면 오버피팅이 일어나는 것 같았다. 특히 예시에 없던 새로운 형식의 계약서가 들어오면 성능이 떨어졌다.
예를 들어:
- 테스트 데이터 셋 내에서는 20개 예시가 92% 정확도
- 하지만 완전히 새로운 고객의 계약서를 처리할 때는 87% 정도로 떨어짐
이것은 Few-shot Learning의 딜레마다. 예시가 너무 적으면 일반화 성능이 떨어지고, 너무 많으면 특정 예시에 과도하게 적응해서 새로운 데이터에 약해진다.
결과적으로 우리가 선택한 최적 포인트는 10개 예시였다. 일반화 성능과 정확도의 균형이 가장 좋았다.
비용과 속도, 예상 못 했던 트레이드오프
Few-shot을 도입하면서 예상하지 못한 문제들이 생겼다.
먼저 비용이다. 우리가 쓰는 API는 입력 토큰 기준으로 요금을 부과한다. Zero-shot은 프롬프트가 짧으니 저렴했다. 하지만 10개 예시를 포함한 Few-shot 프롬프트는 토큰 수가 3~4배 늘어났다. 결과적으로 비용이 3~4배 증가했다.
월 1000만원을 쓰던 회사라면, Few-shot 도입으로 월 3000~4000만원으로 늘어나는 것이다.
속도도 문제였다. 프롬프트가 길어지니 응답 시간이 2초에서 4~5초로 늘어났다. 실시간 처리가 중요한 우리 서비스 입장에서는 이것도 생각해야 할 문제였다.
비용을 줄이면서 성능 유지하기
그래서 우리는 다른 접근을 시도했다. Few-shot을 모든 작업에 적용하되, 어떤 경우에만 적용할지를 선별하기로 했다.
전략은 이런 거였다:
- 첫 번째 요청: Zero-shot으로 빠르게 처리 (비용 저)
- 모델이 확신도 낮은 경우: Few-shot으로 재처리 (높은 정확도)
이렇게 하니 비용과 성능의 균형을 맞출 수 있었다. 전체 요청의 20~30%만 Few-shot으로 재처리하면, 전체 정확도는 85% 이상으로 유지하면서 추가 비용은 최소화할 수 있었다.
또 다른 방법은 더 똑똑한 예시 선택이었다. 10개를 다 보여주는 것보다, 현재 입력 데이터와 가장 유사한 5개 예시만 동적으로 선택해서 보여주는 것이다. 이 방법으로 프롬프트 길이를 30% 줄이면서도 정확도는 비슷하게 유지할 수 있었다.
실제 프로덕션 운영의 현실
이론과 실제는 다르다는 걸 또 한 번 느꼈다.
실험에서 정확도 87~92%는 좋은 수치였다. 하지만 실제 고객 데이터는 더 복잡했다. 우리가 테스트할 때 못 본 형식의 계약서, 특이한 기호, 외국어가 섞인 텍스트 등등. 프로덕션에서는 정확도가 80% 정도로 약간 떨어졌다.
또한 계절성도 있었다. 부동산 거래가 많은 시즌과 적은 시즌에 계약서 형식이 달라지는 경향이 있었다. 그 시즌의 대표적인 예시들을 프롬프트에 포함시키면 성능이 다시 올라갔다.
결론적으로, Few-shot Learning은 “셋 앤 포겟(Set and forget)”이 아니었다. 주기적으로 모니터링하고, 새로운 형식의 데이터가 들어오면 예시를 업데이트해야 했다. 이건 지속적인 유지보수가 필요한 시스템이라는 뜻이다.
Zero-shot vs Few-shot, 언제 뭘 쓸까
이제 우리는 명확한 기준을 가지고 있다.
Zero-shot을 써야 하는 경우:
- 비용이 중요한 프로젝트 (API 비용 최소화)
- 응답 속도가 중요한 경우 (실시간 처리)
- 일반적인 질문 (이미지 설명, 텍스트 요약 등)
- 정확도가 그렇게 중요하지 않은 경우 (70~75%면 괜찮음)
Few-shot을 써야 하는 경우:
- 정확도가 매우 중요한 경우 (금융, 의료, 법률)
- 도메인 특화적인 작업 (전문 용어, 특이한 형식)
- 기존 지식으로는 충분하지 않은 경우
- 비용보다 정확도를 우선하는 경우
그리고 중요한 건, 언제 뭘 쓸지는 처음부터 정하는 게 아니라 실제 데이터로 검증해야 한다는 거다.
앞으로의 방향
현재 우리는 더 나아가고 싶다.
Few-shot과 프롬프트 엔지니어링의 조합, 메타 러닝(Meta-Learning)을 더 탐색하고 있다. 만약 모델이 스스로 좋은 예시를 선택하는 법을 배운다면? 모델이 새로운 도메인에 더 빠르게 적응할 수 있을 거다.
또한 RAG(Retrieval-Augmented Generation)와의 결합도 고려하고 있다. 예시를 미리 정해두는 게 아니라, 입력 데이터와 관련된 예시를 실시간으로 검색해서 보여주는 방식이다. 이렇게 되면 비용도 더 효율적으로 관리할 수 있을 것 같다.
마지막으로
“예시 5개 추가하면 진짜 답변이 달라질까?” 라는 질문에 우리의 답은 명확하다.
달라진다. 매우 크게 달라진다. 62%에서 87%로, 25%포인트나 개선된다.
하지만 모든 상황에서 그런 건 아니다. 도메인, 비용, 속도, 유지보수 복잡도 등을 종합적으로 고려해야 한다. 그리고 반드시 실제 데이터로 검증해야 한다.
우리가 배운 가장 중요한 교훈은 이것이다. 이론적으로 좋아 보이는 기술도, 실제 프로덕션 환경에 적용하면 예상 못 한 어려움들이 생긴다는 거. 그래서 작은 실험으로 시작하고, 점진적으로 확장하고, 계속 모니터링하고, 필요하면 조정해야 한다는 거.
Few-shot Learning은 도구일 뿐이다. 좋은 도구지만, 모든 문제를 푸는 만능열쇠는 아니다. 우리 서비스의 특성을 이해하고, 고객이 원하는 정확도를 알고, 그에 맞는 전략을 세우는 게 진짜 중요하다.