2025년 12월 20일, 저는 운 좋게도 AWS Community Day Kochi의 일원이 되었습니다. 행사 내내 환상적인 세션들이 이어졌지만, 특히 제 모든 주의를 사로잡고 머릿속을 떠나지 않았던 발표가 하나 있었습니다.

발표자는 무대에 올라오자마자 엄청난 결과부터 공개했습니다. 바로 AWS Bedrock를 사용하여 AI 운영 비용을 14배 절감했다는 사실이었습니다. 하지만 이것은 단순히 빠른 성공만을 보여주는 하이라이트 영상이 아니었습니다. 솔직히 말해서, 좋은 점만 보여주는 기술 강연은 우리에게 큰 교육적 가치를 주지 못합니다. 대신, 이 세션에는 팀이 큰 승리를 거두기까지 과정에서 어떻게 반복해서 실패했는지에 대한 명확한 이야기가 담겨 있었습니다.

만약 당신이 개발자이거나, 전체 자금을 다 써버리지 않고 AI 기능을 확장하려는 기업이라면 이 세션은 그야말로 금광과 같습니다. 그 여정과 기술적 도전 과제, 그리고 그들이 어떻게 마침내 퍼즐을 풀었는지 살펴보겠습니다.

비즈니스 문제: 3체 문제 (A 3-Body Challenge)

해결책으로 넘어가기 전에, 팀이 직면했던 악몽 같은 상황을 이해해야 합니다. 그들은 이를 "3체 문제"라고 불렀습니다.

문제는... 그들이 데이터에 파묻혀 있었다는 점입니다. 구체적으로, 화물 예약에 관한 비정형 통신 데이터에 압도당하고 있었습니다.

• 이메일은 이중 언어로 되어 있었으며, 일본어와 영어 콘텐츠가 복잡하게 섞여 있었습니다.
• 시스템은 이러한 이메일에서 항공 화물 운송장 (Air Waybill, AWB) 번호, 편명 (Flight Numbers), 중량 및 치수와 같은 23개의 복잡한 엔티티 (Entities)를 정확하게 추출할 수 있어야 했습니다.

정확도 vs 비용의 딜레마

목표는 실시간 자동 개체명 인식 (Named Entity Recognition, NER)을 수행하는 것이었습니다. 시스템은 프로덕션 파이프라인에서 유용하게 사용되기 위해 낮은 지연 시간 (Low latency)과 95% 이상의 매우 높은 정확도 (F1 score)를 갖추어야 했습니다.

왜 그냥 거대 언어 모델 (Large Language Model, LLM)을 투입하지 않았는지 궁금하실 수도 있습니다. 실제로 투입했고, LLM은 요구되는 정밀도를 충분히 충족했습니다. 하지만 그 높은 볼륨에서의 운영 비용이 결정적인 걸림돌이 되었습니다.

익숙한 상황인가요? 이는 많은 팀이 빠지는 함정입니다. 그들은 잘 작동하는 시스템을 설계했지만, 14배나 높은 비용 문제로는 결코 비즈니스를 구축할 수 없다는 사실을 알고 있었습니다.

핵심 문제에 대한 재고 (Rethinking the Core Problem)

그들의 사고방식에서 나타난 첫 번째 중요한 변화는 개체명 인식 (Named Entity Recognition, NER)에 접근하는 방식이었습니다. 전형적인 BIO (Beginning, Inside, Outside) 태깅을 사용하는 대신, 그들은 NER을 시퀀스 투 시퀀스 (Sequence-to-Sequence, Seq2Seq) 작업으로 정의했습니다.

구조화된 JSON 생성 (Generating Structured JSON)

이를 이해하기 위해, 이커머스 결제 시스템을 상상해 보세요. 시스템이 장바구니에 있는 무작위 상품을 단순히 강조 표시하기를 원하는 것이 아니라, 잘 구성된 영수증을 생성하기를 원하는 것과 같습니다.

그들의 사례에서 입력값 (시퀀스 1)은 모델에게 23개의 모든 엔티티를 JSON 배열로 추출하도록 요청하는 가공되지 않은 뒤섞인 이메일 텍스트 프롬프트였습니다. 기대되는 출력값 (시퀀스 2)은 해당 엔티티들과 일치하는 정확한 JSON 텍스트였습니다.

기술적 목표: 지식 증류 (Knowledge Distillation)

거대한 LLM의 높은 정확도를 막대한 비용 없이 달성하기 위해, 그들은 지식 증류 (Knowledge Distillation)라고 알려진 개념을 활용했습니다.

데이터베이스를 거대한 도서관으로, "교사 모델 (Teacher Model)"을 모든 책을 읽고 이해한 수석 사서로 생각해 보세요. 교사는 거대하고 복잡하며 상담 비용이 많이 듭니다. 증류의 목적은 지식을 압축하여 "학생 모델 (Student Model)"로 전달하는 것입니다. 학생은 더 작고, 훨씬 빠르며, 실행 비용이 훨씬 저렴하여 높은 정밀도와 낮은 비용이라는 두 마리 토끼를 모두 잡을 수 있게 해줍니다.

증류 옵션 평가 (Evaluating the Distillation Options)

발표자는 이러한 지식 전달을 달성하기 위해 취할 수 있는 주요 경로들을 설명했습니다:

• 옵션 1: 로짓 기반 (Logit-Based, 예: DistilBERT): 이 방법은 KL 발산 (KL Divergence)이라는 지표를 사용하여 학생 모델의 최종 출력 확률 (logits)을 교사 모델의 확률과 일치시킵니다. 쉽고 빠르며 효과적입니다. 하지만 일반적으로 교사 모델의 정교한 내부 "추론 (reasoning)" 과정을 많이 놓치게 됩니다.

• 옵션 2: 특징 기반 (Feature-Based, 예: TinyBERT): 즉, 두 모델의 내부 은닉 상태 (hidden states)와 어텐션 매핑 (attention mappings)을 정렬하는 방식입니다. 이 방식은 지식을 매우 깊게 전달합니다. 단점은 무엇일까요? 상당히 취약합니다. 모델 아키텍처가 동일해야 하며, shape_mismatch 오류가 발생하기 매우 쉽습니다.

• 옵션 3: 토큰 기반 (Token-Based): 여기서는 교사 모델을 학생 모델의 최종 출력 시퀀스와 토큰 단위로 비교합니다. 교사 모델의 소프트 라벨 (soft labels)로부터 학습하며, 그들이 필요로 했던 JSON 추출과 같은 생성형 Seq2Seq 작업에 적합합니다.

그들은 JSON 배열을 생성해야 했기 때문에 토큰 기반 (Token-Based) 방식을 선택하기로 결정했습니다. 그리고 이제 흥미로운 부분이 나옵니다. 여기서 흥미롭다는 말은 그들의 엔지니어링 팀에게 매우 좌절스러운 상황을 의미합니다.

엔지니어링의 악몽 (The Engineering Nightmares)

시도 1: 토큰 불일치의 벽 (The Token Mismatch Wall)

그들의 초기 접근 방식은 PyTorch로 구축된 커스텀 토큰 증류 (token distillation)였습니다. 그들은 자신들의 특화된 Seq2Seq 작업을 위해 Llama 3-8B 모델을 Llama 3-1B 모델로 증류하고자 했습니다.

공정하게 말하자면, 논리는 타당했지만 기술적인 현실은 실패였습니다. 토큰 기반 증류를 수행하려면 출력되는 JSON을 효과적으로 증류하기 위해 절대적이고 완벽한 토큰 정렬 (token alignment)이 필요합니다. 그들은 큰 문제에 직면했습니다. Llama 3 토크나이저 (tokenizer)와 그들의 일본어/영어 이중 언어 텍스트가 서로 어긋나 있었던 것입니다.

그들은 서로 일치하지 않는 출력 시퀀스를 비교하려 했고, 이로 인해 훈련 손실 (training loss)이 매우 불안정해졌습니다. 이는 지속적인 token_mismatch_error를 유발했습니다.

시도 2: 취약한 아키텍처의 벽 (The Brittle Architecture Wall)

두 번째 시도입니다. 그들이 포기할 리 없었습니다. 그들은 TextBrewer라는 라이브러리를 사용하여 로짓/특징 기반 (Logit/Feature-Based) 증류 기술을 실행해 보았습니다.

이 또한 기술적인 실패로 끝났습니다. 해결책이 너무 취약했고 아키텍처(Architecture)가 완전히 일치해야 했기 때문입니다. 해당 라이브러리는 요구 사항이 매우 엄격했으며, 그들이 사용하던 특정 Llama 모델들과는 호환되지 않았습니다.

작업은 다시 실패했고, shape_mismatch_error가 발생했습니다. 팀은 자신들이 시간의 100%를 엔지니어링 문제를 해결하는 데 허비하고 있으며, 실제 데이터 연구에는 0%의 시간도 쓰지 못하고 있다는 사실을 깨달았습니다.

전환점: 진짜 문제의 격리

팀은 한 걸음 물러나 자신들의 문제가 끔찍한 이론 때문이 아니라는 것을 확인했습니다. 그들의 문제는 잘못된 엔지니어링이었습니다. 그들은 파이프라인(Pipeline)에서 가장 어려운 두 가지 구간에서 고전하고 있었습니다:

1. 토크나이저(Tokenizer) 및 아키텍처 정렬 (Architecture Alignment).

2. 안정적인 분산 학습 환경 (Distributed Training Environments) 구축.

요약하자면, 그들은 프레임워크 선택, 데이터셋 준비, 정규화(Normalization)와 같은 엔지니어링 요구 사항의 힘든 작업을 대신 처리해 줄 완전히 관리형 솔루션(Managed Solution)이 필요했습니다. 그래야만 비즈니스 과제를 해결하는 데 온전히 집중할 수 있기 때문입니다.

Amazon Bedrock 모델 증류 (Model Distillation) 도입

그들은 전체 파이프라인을 Amazon Bedrock으로 이전했습니다. 새로운 방식은 다음과 같았습니다:

• 사용자 프롬프트(Prompt)를 가져와 거대한 교사(Teacher) 모델에 입력합니다.

• 고품질의 합성 데이터(Synthetic Data)를 생성합니다.

• 해당 데이터를 사용하여 더 작은 학생(Student) 모델을 학습시키고 지식을 전이(Transfer)합니다.

• 맞춤화된 증류된 모델을 실제 추론(Inference)을 위해 배포합니다.

워크플로우는 기분 좋게 단순했습니다. 준비된 프롬프트 데이터셋을 데이터 과학자가 가져와 JSONL 파일로 변환한 뒤 Amazon S3 버킷에 업로드하기만 하면 되었습니다. 그런 다음 Amazon Bedrock 서비스 내에서 원하는 교사 모델과 학생 모델을 선택하여 증류 작업(Distillation job)을 시작했습니다.

다른 시도들은 실패했는데 왜 이것만 성공했을까요? 발표자는 그것이 마법이 아니었다고 지적했습니다. CloudWatch 학습 로그를 확인해 보니 그냥... 제대로 작동했습니다.

• 정렬(Alignment) 문제 해결: 호환 가능한 Nova Pro 및 Nova Lite 모델 제품군을 사용함으로써 토큰 불일치(token mismatch)가 전혀 발생하지 않았습니다.

• 안정성(Stability) 문제 해결: 관리형 서비스(managed service)가 백그라운드에서 모든 복잡한 오케스트레이션(orchestration)을 처리했습니다.

그들의 학습 손실(training loss)은 단 4 에포크(epochs)와 총 70 스텝(steps) 만에 0.05에서 매우 정확한 0.008로 감소했습니다.

결과: 빠르고, 정확하며, 저렴함

그들은 뒤섞인 입력 프롬프트를 받아 원하는 엔티티(entities)가 포함된 완벽하게 형식화된 JSON 출력 배열을 생성하는, 새로 증류된 Nova Lite 모델을 실행했습니다.

결론은 무엇일까요? 통계가 그 이야기를 증명합니다:

• 교사 모델 (Teacher, Nova): 97%의 전체 F1 스코어(영어 96.3%, 일본어 95.4%)를 달성했지만, 실행 비용이 14배 더 높았습니다.

• 학생 모델 (Student, Nova Lite): 1배의 기준 비용(baseline cost)으로 95.085%의 전체 F1 스코어(영어 96.535%, 일본어 93.635%)를 달성했습니다.

그들은 14배의 운영 비용 오버헤드를 완전히 제거하면서 동시에 95% 이상의 정확도 목표를 달성했습니다!

오류에 대한 심층 분석

항상 개선을 추구하는 팀은 교사 모델과 학생 모델 사이의 미세한 1.9% 정확도 차이를 더 자세히 살펴보았습니다.

• 언어 (Language): 학생 모델은 일본어 텍스트에서 현저히 낮은 성능을 보였습니다 (교사 모델 95.4% 대비 93.6%). 이 격차를 메우기 위한 다음 즉각적인 단계는 150개의 샘플로 구성된 미미한 규모의 일본어 데이터셋을 확장하고 늘리는 것입니다.

• 복잡성 (Complexity): 학생 모델 오류의 약 20%는 "롱테일 (long-tail)" 또는 다중 부분 개체 (multi-part entities)에서 발생했습니다. 예를 들어, "취급 주의; 4°C 이하로 냉장 보관"과 같이 정교하게 계층화된 지침이 이에 해당합니다. 이러한 까다로운 엣지 케이스 (edge instances)에서도 교사 모델의 풍부한 기본 추론 (baseline reasoning) 능력이 결국 우위를 점했습니다.

핵심 요약 (Key Takeaways)

• 생성형 NER (Generative NER)은 게임 체인저입니다: 전형적인 BIO 태깅 (BIO tagging) 방식에서 Seq2Seq 기법으로 전환함으로써, 복잡한 다중 개체 추출을 처리해야 할 때 놀라운 유연성을 얻을 수 있습니다.

• 태스크가 방법론을 결정합니다: Seq2Seq 태스크를 선택하면 토큰 기반 (Token-Based) 증류 (distillation) 기법을 사용할 수밖에 없습니다. 이 과정에서 수반되는 취약한 엔지니어링 및 정렬 (alignment) 요구 사항에 대비해야 합니다.

• 진정한 승리는 속도가 아닌 비용입니다: 14배라는 거대한 개선은 운영 비용 절감에 관한 것이었습니다. 두 모델 모두 유사한 추론 (inference) 성능을 보였으나, 더 작은 Nova Lite 모델을 통해 대규모 LLM 처리량 (throughput)을 확보해야 하는 막대한 재정적 부담을 줄였습니다.

• 엔지니어링 부담을 덜어내세요: 만약 팀이 시간의 100%를 아키텍처 불일치 문제를 해결하는 데 소비하고 있다면, 그들은 데이터 과학을 수행하고 있는 것이 아닙니다. AWS Bedrock와 같은 관리형 서비스 (managed services)를 사용하여 이러한 경직된 토크나이저 (tokenizer) 병목 현상을 완전히 제거하십시오.

결론 (Conclusion)

하루 일과가 끝날 무렵 코치 (Kochi)의 관객석에 앉아 있으면서, 거대한 기술적 승리로 가는 길이 결코 직선이 아니라는 점을 다시금 깨달았습니다. 이 팀은 단순히 14배 더 저렴한 AI를 구축한 것이 아닙니다. 그들은 실패를 통해 전진(fail forward)했고, 언제 자신이 엔지니어링 함정에 빠져 있는지 파악했으며, 근본적인 비즈니스 과제를 해결하는 데 집중할 수 있게 해주는 관리형 솔루션으로 피벗 (pivot)했습니다.

만약 여러분이 AI 솔루션을 제작하고 있다면, 운영 비용이 비즈니스 모델을 위협하기 시작할 때 아키텍처 (architecture)를 변경하는 것을 두려워하지 마세요. 때로는 관리형 서비스 (managed service)가 힘든 작업을 대신 수행하도록 맡기는 것이 여러분이 내릴 수 있는 가장 현명한 기술적 선택일 수 있습니다.

저자 소개

AWS Community Builder로서, 저는 저 자신의 경험과 이벤트를 통해 배운 것들을 공유하는 것을 즐기며, 다른 이들의 여정을 돕는 것을 좋아합니다. 이 글이 도움이 되었거나 궁금한 점이 있다면 언제든 연락해 주세요! 🚀

🔗 LinkedIn에서 저와 연결하세요

참고 문헌

이벤트: AWS Community Day Kochi

주제: 14배 더 저렴한 AI: Bedrock를 활용한 실질적인 LLM 증류 (Distillation) 사례 연구

날짜: 2025년 12월 20일

다른 게시처