9부 49장. 작업에 따라 모델을 바꾸는 전략

지난 장에서 우리는 모델을 볼 때 긴 문맥, 추론, 도구 사용, 코딩 성능 같은 능력 축으로 봐야 한다고 이야기했다. 이제 남은 질문은 하나다. 그래서 실제 일에서는 어떤 모델을 어떻게 배치할 것인가?

많은 사람이 여기서 다시 예전 습관으로 돌아간다. 가장 유명한 모델 하나를 고른 뒤, 요약도 맡기고, 분류도 맡기고, 보고서도 맡기고, 코드도 맡긴다. 마치 회사에 입사한 신입사원에게 회계, 영업, 디자인, 법무를 한꺼번에 맡기는 것과 비슷하다. 못하는 사람이어서가 아니라, 애초에 배치가 이상한 것이다.

물론 처음부터 복잡한 멀티 모델 시스템을 만들 필요는 없다. 이미 쓰고 있는 단일 모델이 현재 업무 요구를 충분히 만족한다면 그대로 써도 된다. 다만 업무가 다양해지고, 요청량이 늘고, 비용과 속도 차이가 체감되기 시작하면 모델을 작업별로 나누는 편이 훨씬 실용적이다.¹

이 장의 핵심은 간단하다. 모델을 브랜드로 고르지 말고, 작업 역할로 배치하라. 그러면 "가장 좋은 모델"을 찾는 싸움에서 벗어나, "이 일에 가장 알맞은 모델"을 고르는 습관이 생긴다.

먼저 모델이 아니라 일을 분해하라

좋은 모델 전략은 모델 이름표에서 시작하지 않는다. 먼저 해야 할 일은 업무를 쪼개 보는 것이다. 같은 "AI 활용"처럼 보여도 실제로는 서로 다른 일이 섞여 있기 때문이다.

예를 들어 보고서 작성이라고 해 보자. 겉으로는 하나의 작업 같지만 안쪽을 들여다보면 여러 단계가 숨어 있다. 자료 찾기, 관련 문장 추출, 초안 작성, 논리 점검, 형식 변환, 최종 다듬기가 모두 다른 성격의 일이다. 이 단계들을 전부 같은 모델로 처리할 수도 있지만, 꼭 그럴 이유는 없다.

작업을 나눌 때는 적어도 다음 여섯 가지를 먼저 묻는 것이 좋다.

• 이 일의 본질은 분류, 추출, 변환, 생성, 추론 중 무엇인가

• 실수 비용이 큰가, 아니면 다시 시도해도 되는가

• 응답 속도가 중요한가, 아니면 품질이 더 중요한가

• 요청량이 많은가, 적은가

• 긴 문맥이나 여러 자료를 함께 봐야 하는가

• 민감한 데이터나 규제 이슈가 있는가

이 질문에 답해 보면 놀랍게도 많은 일이 세 덩어리로 정리된다. 아주 단순한 일, 대부분의 일, 그리고 정말 어려운 일이다. 그리고 이 셋은 보통 서로 다른 모델이 더 잘 맡는다.¹²

가장 쉬운 시작은 세 가지 역할을 정하는 것이다

처음부터 열 개 모델을 붙일 필요는 없다. 실제로는 세 가지 역할만 정해도 전략이 크게 달라진다.

• 빠른 모델: 분류, 태깅, 단순 추출, 짧은 요약, 형식 변환처럼 규칙이 비교적 뚜렷하고 대량 처리에 어울리는 일

• 균형형 모델: 초안 작성, 일반 요약, 문서 정리, 실무 문서 작성, 보통 수준의 분석처럼 대부분의 일

• 고성능 모델: 여러 자료를 엮는 추론, 중요한 판단, 애매한 케이스, 고난도 디버깅, 사람이 바로 쓰게 될 최종 결과물

이렇게만 나눠도 "모든 일을 최고급 모델로 처리하는 습관"에서 벗어나기 쉽다. 실제 현장 가이드들도 가장 흔한 비용 낭비가 모델 균일화, 즉 쉬운 일과 어려운 일을 같은 비싼 모델에 몰아주는 것이라고 지적한다.²

여기서 중요한 포인트가 하나 있다. 빠른 모델은 열등한 모델이 아니라 좁고 분명한 일에 잘 맞는 모델이라는 점이다. 간단한 분류나 포맷 변환에서는 오히려 작고 빠른 모델이 더 경제적이고, 때로는 더 덜 장황해서 다루기 쉽다. 반대로 복잡한 의사결정이나 장문 종합에서는 강한 모델이 제값을 한다.

모델을 이렇게 역할로 보면 머리가 맑아진다. 이제 질문이 "무슨 모델이 최고지?"가 아니라 "이 단계는 어느 역할의 모델이 맡아야 하지?"로 바뀌기 때문이다.

조사형 업무는 한 모델보다 릴레이가 잘 맞는다

리서치나 조사형 업무는 멀쩡해 보여도 사실 여러 성격의 작업이 이어 붙은 형태다. 웹 검색 키워드를 만들고, 관련 자료를 훑고, 중복을 걷어내고, 핵심을 요약하고, 마지막으로 비교와 판단을 해야 한다. 이 전 과정을 하나의 모델에 몰아주면 종종 비싸고 느리며, 중간 단계에서 과한 추론을 해 버리기도 한다.⁴

이럴 때는 릴레이처럼 나누는 편이 좋다.

먼저 빠른 모델이 검색 질의를 다듬고, 문서의 관련성 여부를 걸러낸다. 그다음 균형형 모델이 여러 문서를 읽고 핵심을 정리한다. 마지막으로 고성능 모델이 상충하는 정보들을 비교하고, 장단점과 권고안을 묶어 최종 판단을 만든다.

이 구조의 장점은 명확하다. 쉬운 단계에서 괜히 비싼 추론을 하지 않게 되고, 정말 비싼 사고력이 필요한 순간에만 강한 모델을 쓰게 된다. 특히 자료가 많고 출처가 여러 개인 조사형 업무에서는 마지막 종합 단계만 고성능 모델로 올려도 체감 품질이 크게 좋아진다.

조사형 업무에서는 한 가지를 더 조심해야 한다. 라우팅에 들어가는 후보 모델들의 문맥 길이가 제각각이면, 긴 자료를 다루는 단계와 짧은 분류 단계를 같은 풀에서 처리하기 어려워진다. 긴 문서 입력이 필요한 단계는 애초에 긴 문맥을 감당할 수 있는 모델군으로 분리해 두는 편이 안전하다.¹

글쓰기 업무는 초안 모델과 최종 모델을 분리하면 편해진다

글쓰기에서 흔한 실수는 시작부터 가장 무거운 모델을 붙잡고 첫 문장부터 완벽하게 쓰려는 것이다. 하지만 실제 글은 대개 기획, 초안, 비평, 수정, 변환의 흐름으로 움직인다. 이 단계마다 필요한 능력이 조금씩 다르다.

초안 단계에서는 균형형 모델이 아주 유용하다. 속도와 품질이 적절해서 개요를 잡고, 자료를 정리하고, 첫 버전을 만드는 데 부담이 적다. 반면 최종 메시지의 설득력, 어조, 논리적 정교함이 중요한 글이라면 마지막 정리 단계에서 고성능 모델을 쓰는 편이 낫다. 특히 대표 명의 메일, 제안서 요약, 대외 발표문처럼 한번 나가면 되돌리기 어려운 문서는 이 차이가 크다.

반대로 짧은 변환 작업은 빠른 모델로 충분한 경우가 많다. 예를 들어 긴 글을 회의용 5줄 요약으로 줄이기, 블로그 초안을 메일 형식으로 바꾸기, 문단을 불릿으로 변환하기 같은 일이다. 이런 작업에 매번 가장 비싼 모델을 쓰는 것은 고급 셰프를 불러 라면 물 끓이게 하는 것과 비슷하다.

글쓰기에서 실전적으로 가장 효과적인 조합은 이렇다. 균형형 모델로 기획과 초안을 만들고, 빠른 모델로 반복 변환을 처리하고, 고성능 모델로 마지막 논리 점검과 품질 상승을 맡긴다. 이 순서만 익혀도 생산성이 꽤 달라진다.

운영과 실무 문서는 분류와 판단을 떼어 놓는 것이 핵심이다

고객 문의 처리, 내부 헬프데스크, 문서 접수, 회의 정리, 티켓 분배 같은 운영성 업무는 얼핏 단순해 보여도 실제로는 두 층으로 나뉜다. 하나는 기계적으로 나눌 수 있는 일이고, 다른 하나는 상황 판단이 필요한 일이다.

예를 들어 문의 메일이 들어오면 우선 해야 할 일은 의도 분류, 긴급도 태깅, 관련 부서 판별, 필요한 정보 추출이다. 이런 단계는 빠른 모델이 맡기 좋다. 반면 환불 예외 처리, 민감한 고객 응대 문안 작성, 정책 충돌 판단처럼 애매한 문제는 더 강한 모델이나 사람 검토가 필요하다.

AI 워크플로 문헌이 반복해서 강조하는 것도 바로 이 구조다. 간단한 분류형 단계와, 여러 단계에 걸친 작성·검토형 단계를 분리해야 자동화가 깔끔해진다는 점이다.⁴

이 영역에서는 특히 "최종 결과를 사람이 꼭 보느냐"가 중요하다. 사람이 중간에서 확인한다면 균형형 모델 비중을 높일 수 있다. 반대로 사람이 바로 읽지 않고 외부로 발송되거나 시스템을 움직이는 결과물이라면 더 높은 품질의 모델이나 명확한 검증 절차가 필요하다.²

즉, 운영 업무에서는 단순히 모델 성능보다 오류가 밖으로 나가는 지점을 기준으로 배치하는 것이 중요하다.

코딩 업무는 특히 작업별 분리가 잘 먹힌다

코딩에서 작업별 모델 전략은 거의 필수에 가깝다. 왜냐하면 코딩이라고 해서 다 같은 코딩이 아니기 때문이다.

짧은 함수 작성, 문법 질문, 단순 수정, 설명 생성 같은 일은 빠르거나 균형 잡힌 모델이 매우 잘 처리한다. 반면 여러 파일을 넘나드는 버그 추적, 아키텍처 설계, 테스트 실패 원인 분석, 대형 코드베이스 리팩터링은 훨씬 더 강한 추론과 문맥 유지가 필요하다. 실제 개발 도구 문서들도 일반 코딩과 깊은 디버깅, 에이전트형 개발, 시각 자료 기반 분석을 구분해서 다른 모델을 권장한다.³

예를 들어 이런 식으로 생각하면 쉽다.

빠른 모델은 "이 문법 왜 에러예요?", "이 함수 테스트 하나만 짜 줘", "이 코드 주석으로 설명해 줘" 같은 질문에 잘 맞는다. 균형형 모델은 일반적인 함수 작성, 리드미 초안, 코드 리뷰 요약, 보통 수준의 수정 작업에 잘 맞는다. 고성능 모델은 "이 버그가 왜 여러 파일에서 동시에 터지는지 추적해 줘", "이 모듈 구조를 어떻게 나누는 게 좋은지 비교해 줘", "실패 로그와 테스트 결과를 보고 수정 방향을 제안해 줘" 같은 문제에서 진가를 발휘한다.³

또 하나, 화면 캡처나 다이어그램이 섞이는 프런트엔드 작업이라면 멀티모달 지원 여부도 중요하다. 오류 메시지 스크린샷, UI 캡처, 구조도를 함께 읽는 작업은 텍스트 전용 코딩 모델보다 다른 종류의 강점을 요구하기 때문이다.³

코딩에서 작업별 분리가 특히 잘 먹히는 이유는 간단하다. 작은 질문은 자주 오고, 큰 문제는 드물지만 비싸다. 그러니 작은 질문까지 전부 가장 무거운 모델로 처리하는 순간 비용과 대기 시간이 순식간에 불어난다.

수동 라우팅으로 시작하고, 자동 라우팅은 나중에 올려라

멀티 모델 전략을 들으면 많은 사람이 곧바로 복잡한 오케스트레이터, 동적 라우터, 자동 평가기를 떠올린다. 하지만 실제로는 그렇게 시작할 필요가 없다. 오히려 처음에는 수동 규칙이 더 낫다.¹

예를 들면 이런 식이다. 분류·태깅·추출은 빠른 모델, 일반 문서 작성과 요약은 균형형 모델, 고위험 판단과 장문 종합은 고성능 모델. 이 정도 규칙만 있어도 대부분의 조직은 바로 효과를 본다.

수동 라우팅이 좋은 이유는 예측 가능성 때문이다. 왜 이 모델이 선택됐는지 설명하기 쉽고, 디버깅도 쉽고, 비용 계산도 쉽다. 반면 자동 라우팅은 요청마다 모델이 달라질 수 있어 유연하지만, 관찰성과 비용 예측이 더 어려워진다.¹

그렇다고 자동 라우팅이 나쁘다는 뜻은 아니다. 요청 난도가 들쭉날쭉하고, 트래픽이 많고, 작업 종류가 섞여 있는 서비스라면 자동 라우팅이 오히려 더 잘 맞는다. 다만 그 단계는 보통 작업 분류 기준이 어느 정도 검증된 뒤에 가는 편이 안전하다.

한마디로 정리하면 이렇다. 작게 시작해서, 잘 보이게 운영하고, 필요할 때 자동화하라.

좋은 전략은 모델 이름이 아니라 정책으로 남아야 한다

실무에서 정말 중요한 것은 "이번 달에는 A 모델, 다음 달에는 B 모델" 같은 이름 암기가 아니다. 이름은 계속 바뀐다. 대신 오래가는 것은 정책이다.

예를 들어 이런 식의 정책은 꽤 오래 쓸 수 있다.

• 입력이 짧고 규칙이 분명하면 빠른 모델을 우선 사용한다

• 여러 문서를 종합하거나 판단 책임이 크면 고성능 모델로 올린다

• 사람이 검토하는 중간 산출물은 균형형 모델을 기본으로 둔다

• 민감한 데이터는 승인된 제공자나 로컬 모델로만 보낸다

• 실패 시에는 더 강한 모델로 재시도하되, 무한 재시도는 막는다

이런 정책 기반 사고가 중요한 이유는 모델 시장이 너무 빨리 바뀌기 때문이다. 오늘의 최고 모델이 내일도 최고라는 보장이 없고, 가격도 바뀌고, 맥락 길이와 도구 지원도 바뀐다. 그래서 애플리케이션 로직과 모델 선택을 분리하는 추상화 계층이 유리하다. 그래야 모델을 갈아 끼워도 전체 워크플로를 다시 짜지 않아도 된다.⁶

결국 잘 만든 시스템은 특정 모델에 충성하지 않는다. 대신 "이런 종류의 일에는 이런 수준의 모델"이라는 원칙에 충실하다.

운영에서 진짜 차이를 만드는 것은 평가와 폴백이다

모델을 여러 개 쓰기 시작하면 또 다른 유혹이 생긴다. 라우팅만 붙이면 끝났다고 생각하는 것이다. 하지만 실제 운영에서 차이를 만드는 것은 그다음이다. 정말 그 배치가 잘 작동하는지 확인하는 과정이다.

가장 좋은 방법은 대표 작업 샘플을 만들어 두는 것이다. 자주 들어오는 요청 20개, 중요한 문서 작업 10개, 실패하면 큰 문제인 케이스 10개처럼 실제 업무를 닮은 묶음을 만든다. 그리고 후보 모델 조합을 같은 조건에서 돌려 품질, 속도, 비용을 함께 본다. 일반 벤치마크보다 이런 자체 테스트가 훨씬 현실적이다.⁵

또한 한 번에 전면 교체하지 말고, 일부 트래픽이나 일부 팀에서 먼저 시험하는 편이 좋다. 실무 가이드들도 10% 정도의 제한된 트래픽으로 A/B 테스트를 하거나, 특정 작업군부터 단계적으로 라우팅을 적용하는 방식을 권한다.⁷

폴백도 중요하다. 값싼 모델이 1차로 응답하되, 품질 기준을 못 넘으면 더 강한 모델로 올려보내는 구조는 꽤 실용적이다. 이렇게 하면 평소에는 비용을 아끼고, 어려운 요청이 들어왔을 때만 추가 비용을 낸다.⁷

멀티 모델 전략은 결국 멋진 구조도가 아니라 운영 습관의 문제다. 측정하지 않으면 라우팅은 신앙이 되고, 폴백이 없으면 자동화는 도박이 된다.

좋은 모델 전략은 팀 짜기와 비슷하다

축구팀을 만든다고 생각해 보자. 골키퍼가 잘한다고 해서 공격수 자리까지 맡기지는 않는다. 반대로 공격수가 스타라고 해서 수비까지 다 시키지도 않는다. 역할이 다르기 때문이다.

AI 모델도 마찬가지다. 빠른 모델은 전방 압박처럼 자잘하고 많이 오는 일을 처리한다. 균형형 모델은 경기의 대부분을 소화하는 미드필더 같다. 고성능 모델은 정말 승부를 가를 장면에서 투입하는 해결사에 가깝다.

이렇게 보기 시작하면 모델 선택이 훨씬 현실적으로 바뀐다. 하나의 모델을 숭배하는 대신, 작업의 성격에 맞는 배치를 고민하게 된다. 그리고 그 순간부터 AI 활용은 "프롬프트 한 방"의 세계에서 벗어나, 설계된 워크플로와 운영되는 시스템의 세계로 들어간다.

이번 장에서 기억할 것은 단 하나다. 하나의 모델로 모든 일을 억지로 처리하려 하지 말고, 일의 종류에 따라 모델을 배치하라. 그러면 비용은 내려가고, 속도는 올라가고, 정말 중요한 순간에 더 좋은 품질을 얻을 수 있다.

다음 장에서는 여기서 한 걸음 더 나아가, 왜 하나의 모델만 고집하는 태도 자체가 점점 위험해지는지 살펴보겠다.

참고

¹Choose the right AI model for your workload

²Model Selection Guide: Choosing the Right Model for Each Task

³AI model comparison - GitHub Docs

⁴What is AI workflow automation?

⁵How to Choose the Best AI Model

⁶Choosing AI Models For Business

⁷Model Switching | Onaro Implementation Guide