4장. AI 모델을 선택하는 기준

1. AI 모델은 하나만 있는 것이 아니다

AI를 처음 접하면 “AI 모델”이라는 말을 하나의 기술처럼 생각하기 쉽다.

하지만 실제로는 목적에 따라 다양한 모델이 있다.

텍스트를 잘 다루는 모델이 있고,
이미지를 잘 이해하는 모델이 있고,
음성을 텍스트로 바꾸는 모델이 있고,
코드 작성에 강한 모델도 있다.

예를 들어 다음 요구사항을 보자.

- 고객 문의를 자동으로 분류하고 싶다.
- 사내 문서를 검색해서 답변하는 챗봇을 만들고 싶다.
- 방송 음성을 실시간 자막으로 변환하고 싶다.
- 개발자가 작성한 PR을 자동으로 리뷰하고 싶다.
- 사용자가 올린 이미지를 검사하고 싶다.
- 긴 회의록을 요약하고 싶다.

이 요구사항들은 모두 AI를 사용할 수 있는 영역이다.

하지만 모두 같은 모델을 쓰면 좋은 결과가 나오지 않을 수 있다.

방송 음성을 자막으로 바꾸려면 음성 인식 모델이 필요하다.
이미지를 검사하려면 비전 모델이 필요하다.
문서를 요약하거나 코드를 리뷰하려면 LLM이 필요하다.

즉, AI 모델을 선택할 때는 먼저 이렇게 질문해야 한다.

“내가 해결하려는 문제가 무엇인가?”

AI 모델 선택은 유명한 모델을 고르는 일이 아니다.
해결하려는 문제에 맞는 도구를 고르는 일이다.

2. 모델 선택 전에 먼저 목적을 정해야 한다

AI 모델을 고르기 전에 가장 먼저 해야 할 일은 목적을 명확히 하는 것이다.

목적이 불분명하면 모델 선택도 흔들린다.

예를 들어 “AI 챗봇을 만들고 싶다”는 말은 너무 넓다.

챗봇이라고 해도 종류가 다양하다.

- 단순 FAQ 챗봇
- 사내 문서 검색 챗봇
- 고객센터 상담 보조 챗봇
- 개발 문서 검색 챗봇
- 결제 문의 응대 챗봇
- 운영자용 장애 분석 챗봇

이 챗봇들은 겉으로 보기에는 비슷해 보이지만, 필요한 모델과 구조가 다를 수 있다.

단순 FAQ 챗봇은 비교적 작은 모델로도 가능할 수 있다.
사내 문서 검색 챗봇은 RAG 구조가 필요할 가능성이 높다.
결제 문의 챗봇은 정확성과 보안이 중요하다.
장애 분석 챗봇은 로그, 메트릭, 배포 이력 같은 운영 데이터와 연결되어야 한다.

그래서 모델 선택 전에 다음 질문을 먼저 정리해야 한다.

- 사용자가 누구인가?
- 어떤 문제를 해결하려는가?
- 답변은 얼마나 정확해야 하는가?
- 실시간성이 필요한가?
- 개인정보나 내부 데이터가 포함되는가?
- 비용 제한이 있는가?
- 결과를 사람이 검토하는가, 자동으로 실행하는가?

이 질문에 따라 모델 선택 기준이 달라진다.

예를 들어 단순 문서 초안 작성 도구라면 약간 틀려도 사람이 수정할 수 있다.
하지만 결제 처리나 계정 권한 변경처럼 실제 시스템에 영향을 주는 기능이라면 훨씬 엄격해야 한다.

AI 모델은 성능만 보고 고르는 것이 아니다.

업무 목적, 위험도, 비용, 보안, 운영 방식을 함께 보고 선택해야 한다.

3. 클라우드 모델과 오픈소스 모델

AI 모델은 크게 두 가지 방식으로 사용할 수 있다.

하나는 클라우드 모델을 API로 사용하는 방식이고,
다른 하나는 오픈소스 모델을 직접 실행하는 방식이다.

AI 모델 사용 방식

1. 클라우드 모델 사용
   - OpenAI, Anthropic, Google, AWS Bedrock 같은 서비스를 API로 호출

2. 오픈소스 모델 사용
   - Llama, Mistral, Qwen 같은 모델을 직접 다운로드해서 실행

클라우드 모델은 사용하기 쉽다.

서버를 직접 구성하지 않아도 되고, GPU를 구매하지 않아도 된다.
API Key를 발급받고 요청을 보내면 바로 사용할 수 있다.

예를 들어 개발자는 다음처럼 AI 기능을 빠르게 붙일 수 있다.

사용자 질문
→ 백엔드 서버
→ 클라우드 AI API 호출
→ AI 응답 반환
→ 사용자에게 보여주기

반면 오픈소스 모델은 직접 실행 환경을 구성해야 한다.

모델 파일을 다운로드하고, 실행 도구를 설치하고, GPU나 CPU 자원을 준비해야 한다.
운영 환경에서는 모니터링, 장애 대응, 모델 업데이트도 직접 고려해야 한다.

하지만 장점도 있다.

내부 데이터를 외부 API로 보내지 않고 처리할 수 있다.
요청량이 많을 경우 장기적으로 비용을 줄일 수도 있다.
특정 환경에 맞게 모델을 더 세밀하게 통제할 수 있다.

클라우드 모델:
빠르게 시작하기 좋고 성능이 좋지만,
사용량 기반 비용과 데이터 외부 전송 이슈를 고려해야 한다.

오픈소스 모델:
직접 운영해야 하지만,
보안과 비용 통제 측면에서 장점이 있다.

오픈소스 모델은 모델 구조나 가중치가 공개되어 직접 실행하거나 수정할 수 있는 모델을 말한다.
단, “오픈소스”라고 해서 항상 상업적 사용이 자유로운 것은 아니므로 라이선스 확인이 필요하다.

4. 클라우드 모델의 장단점

클라우드 모델의 가장 큰 장점은 빠르게 시작할 수 있다는 점이다.

별도의 GPU 서버를 준비하지 않아도 된다.
복잡한 모델 실행 환경을 구성할 필요도 없다.

API 호출만으로 고성능 AI를 사용할 수 있다.

예를 들어 다음과 같은 기능은 클라우드 모델로 빠르게 만들 수 있다.

- 문서 요약
- 고객 문의 분류
- 이메일 초안 작성
- 코드 설명
- 번역
- 회의록 정리
- 관리자용 AI 보조 기능

클라우드 모델은 보통 최신 성능을 빠르게 사용할 수 있다는 장점도 있다.

모델 제공사가 성능 개선, 인프라 운영, 확장성, 장애 대응을 맡아준다.
개발자는 모델 운영보다 서비스 기능 개발에 집중할 수 있다.

하지만 단점도 있다.

첫 번째는 비용이다.

클라우드 AI는 대부분 사용량 기반으로 과금된다.
질문이 길고 답변이 길수록 비용이 늘어난다.
사용자가 많아질수록 비용도 증가한다.

두 번째는 데이터 외부 전송 문제다.

사용자의 질문, 회사 문서, 로그, 코드 일부가 외부 AI API로 전송될 수 있다.
따라서 개인정보, 보안 정책, 계약 조건을 반드시 검토해야 한다.

세 번째는 벤더 의존성이다.

특정 API 형식, 특정 모델 특성, 특정 가격 정책에 의존하게 될 수 있다.
나중에 다른 모델로 바꾸려면 코드와 프롬프트를 수정해야 할 수도 있다.

클라우드 모델 장점:
- 빠르게 시작 가능
- 고성능 모델 사용 가능
- 인프라 운영 부담 적음
- 확장성 확보 쉬움

클라우드 모델 단점:
- 사용량 기반 비용 발생
- 민감 정보 외부 전송 이슈
- 벤더 의존성
- API 장애나 정책 변경 영향

클라우드 모델은 빠른 PoC나 일반적인 AI 기능에 적합하다.

하지만 개인정보, 내부 문서, 대량 요청, 비용 통제가 중요한 경우에는 신중하게 설계해야 한다.

PoC는 Proof of Concept의 약자다.
본격적인 개발 전에 “이 방식이 실제로 가능한지”를 작게 검증해보는 단계를 말한다.

5. 오픈소스 모델의 장단점

오픈소스 모델은 직접 실행할 수 있는 AI 모델이다.

대표적으로 Llama, Mistral, Qwen 같은 모델들이 있다.

이런 모델은 로컬 PC, 사내 서버, 클라우드 GPU 서버 등에 올려서 사용할 수 있다.

오픈소스 모델의 가장 큰 장점은 통제권이다.

외부 API로 데이터를 보내지 않고 내부 환경에서 처리할 수 있다.
모델 실행 위치, 로그 저장 방식, 접근 권한, 네트워크 구성을 직접 통제할 수 있다.

예를 들어 다음과 같은 경우에는 오픈소스 모델을 고려할 수 있다.

- 개인정보가 포함된 문서를 처리해야 하는 경우
- 사내망 안에서만 AI를 사용해야 하는 경우
- 외부 API 사용이 보안 정책상 어려운 경우
- 요청량이 많아 API 비용이 부담되는 경우
- 특정 업무에 맞게 모델을 조정하고 싶은 경우

하지만 오픈소스 모델은 운영 부담이 있다.

모델을 실행하려면 하드웨어 자원이 필요하다.
특히 큰 모델을 빠르게 실행하려면 GPU와 충분한 VRAM이 필요하다.

또한 모델 서버를 직접 운영해야 한다.

- 모델 실행 환경 구성
- GPU 자원 관리
- 장애 대응
- 응답 속도 튜닝
- 모델 업데이트
- 보안 패치
- 사용량 모니터링

클라우드 모델은 API만 호출하면 되지만, 오픈소스 모델은 운영 책임이 사용자에게 있다.

또 하나 중요한 점은 성능이다.

최신 대형 클라우드 모델은 일반적인 오픈소스 모델보다 성능이 좋은 경우가 많다.
특히 복잡한 추론, 긴 문서 이해, 고난도 코딩 작업에서는 차이가 날 수 있다.

오픈소스 모델 장점:
- 내부 데이터 보호에 유리
- 운영 환경 통제 가능
- 장기적으로 비용 절감 가능
- 특정 업무에 맞게 커스터마이징 가능

오픈소스 모델 단점:
- 실행 환경 구성 필요
- GPU 등 하드웨어 비용 발생
- 운영과 장애 대응 부담
- 모델 성능이 클라우드 최신 모델보다 낮을 수 있음

오픈소스 모델은 “무료 AI”로만 보면 안 된다.

모델 비용은 없을 수 있지만, 서버 비용과 운영 비용이 발생한다.
따라서 전체 비용을 함께 계산해야 한다.

VRAM은 GPU가 사용하는 전용 메모리다.
AI 모델을 GPU에서 실행할 때는 모델 크기에 따라 많은 VRAM이 필요할 수 있다.

6. GPT, Claude, Gemini 계열의 차이를 어떻게 볼 것인가

클라우드 AI 모델을 선택할 때 자주 비교되는 모델들이 있다.

대표적으로 GPT, Claude, Gemini 계열이 있다.

이 모델들은 모두 강력한 LLM이지만, 실제 사용해보면 성향과 강점이 조금씩 다르다.

중요한 것은 “어느 모델이 무조건 최고인가?”가 아니다.

업무 목적에 맞는 모델을 선택하는 것이다.

예를 들어 일반적으로 모델을 비교할 때는 다음 기준을 볼 수 있다.

- 한국어 답변 품질
- 코드 작성 능력
- 긴 문서 처리 능력
- 추론 능력
- 응답 속도
- 비용
- API 사용 편의성
- 멀티모달 지원 여부
- 보안 및 기업용 기능

어떤 모델은 긴 문서를 잘 다룰 수 있고,
어떤 모델은 코드 생성에 강할 수 있고,
어떤 모델은 응답 속도와 비용 측면에서 유리할 수 있다.

또 모델은 계속 업데이트된다.

오늘 성능이 좋은 모델이 몇 달 뒤에도 항상 최고라고 보장할 수 없다.
그래서 특정 모델 하나에 모든 기능을 강하게 묶는 것은 위험할 수 있다.

실무에서는 모델을 교체할 수 있도록 구조를 잡는 것이 좋다.

좋지 않은 구조:
서비스 코드 곳곳에서 특정 AI API를 직접 호출

좋은 구조:
AI 호출을 담당하는 별도 모듈을 만들고,
내부에서 모델 제공사를 교체할 수 있게 구성

예를 들면 다음과 같은 구조다.

서비스 코드
→ AI Gateway
→ OpenAI / Claude / Gemini / Local Model

이렇게 하면 나중에 비용, 성능, 장애 상황에 따라 모델을 바꾸기 쉬워진다.

AI Gateway는 여러 AI 모델 호출을 하나의 공통 인터페이스로 감싸는 구조를 말한다.
서비스 코드는 AI Gateway만 호출하고, 실제 어떤 모델을 쓸지는 내부 설정으로 바꿀 수 있다.

7. Llama, Mistral, Qwen 같은 오픈소스 모델

오픈소스 모델을 사용할 때 자주 등장하는 이름들이 있다.

대표적으로 Llama, Mistral, Qwen 같은 모델 계열이다.

이 모델들은 직접 다운로드해서 실행하거나, Ollama, LM Studio, vLLM 같은 도구를 통해 사용할 수 있다.

오픈소스 모델 예시:
- Llama 계열
- Mistral 계열
- Qwen 계열
- Gemma 계열
- DeepSeek 계열

오픈소스 모델을 볼 때는 이름만 보면 안 된다.

같은 계열 안에서도 크기와 용도가 다르다.

예를 들어 모델명에 7B, 8B, 14B, 32B, 70B 같은 숫자가 붙는 경우가 있다.

여기서 B는 Billion, 즉 10억 개 단위를 의미한다.
대략 모델이 가진 파라미터 수를 나타낸다.

7B  = 약 70억 파라미터
14B = 약 140억 파라미터
32B = 약 320억 파라미터
70B = 약 700억 파라미터

일반적으로 파라미터 수가 큰 모델일수록 더 복잡한 작업을 잘할 가능성이 높다.

하지만 무조건 큰 모델이 좋은 것은 아니다.

큰 모델은 더 많은 메모리와 GPU 자원이 필요하다.
응답 속도가 느릴 수 있고, 운영 비용도 증가한다.

간단한 문서 분류나 요약에는 작은 모델로 충분할 수 있다.
복잡한 코드 분석이나 긴 문서 추론에는 큰 모델이 더 적합할 수 있다.

작은 모델:
- 빠름
- 가벼움
- 비용 적음
- 단순 작업에 적합

큰 모델:
- 성능 좋음
- 복잡한 작업에 유리
- 느릴 수 있음
- 높은 하드웨어 요구

오픈소스 모델 선택은 “가장 큰 모델을 쓰자”가 아니라,
“우리 작업에 필요한 수준의 모델을 쓰자”에 가깝다.

파라미터는 모델이 학습 과정에서 조정한 내부 값이다.
파라미터 수가 많을수록 더 복잡한 패턴을 표현할 수 있지만, 실행에 필요한 자원도 증가한다.

8. 텍스트 모델, 음성 모델, 비전 모델, 멀티모달 모델

AI 모델은 처리하는 데이터 종류에 따라 나눌 수도 있다.

개발자가 자주 보게 될 유형은 다음과 같다.

- 텍스트 모델
- 코드 모델
- 음성 모델
- 비전 모델
- 멀티모달 모델

텍스트 모델은 문장을 다룬다.

문서 요약, 번역, 고객 문의 답변, 보고서 작성 같은 작업에 사용된다.

코드 모델은 코드를 다룬다.

코드 생성, 리팩토링, 테스트 코드 작성, PR 리뷰, 오류 분석에 사용된다.
요즘은 일반 LLM도 코드 작업을 잘하지만, 코드에 특화된 모델도 따로 존재한다.

음성 모델은 음성을 다룬다.

대표적으로 STT와 TTS가 있다.

STT:
음성을 텍스트로 변환

TTS:
텍스트를 음성으로 변환

예를 들어 라이브 방송에서 실시간 자막을 만들려면 STT가 필요하다.
텍스트 안내문을 음성으로 읽어주는 기능을 만들려면 TTS가 필요하다.

비전 모델은 이미지를 다룬다.

이미지 속 객체를 인식하거나, 이미지 내용을 설명하거나, 부적절한 이미지를 탐지할 때 사용된다.

멀티모달 모델은 여러 종류의 입력을 함께 처리한다.

예를 들어 텍스트와 이미지를 같이 넣고 질문할 수 있다.

이 에러 화면을 보고 원인을 설명해줘.

또는 음성과 화면 자료를 함께 분석하는 식으로 확장될 수 있다.

모델 선택에서 중요한 것은 입력과 출력이다.

입력이 텍스트인가?
입력이 음성인가?
입력이 이미지인가?
출력은 텍스트인가?
출력은 음성인가?
출력은 JSON인가?

입력과 출력이 정리되면 필요한 모델 유형도 더 명확해진다.

9. 성능만 보고 모델을 고르면 안 된다

AI 모델을 선택할 때 가장 많이 하는 실수는 성능만 보는 것이다.

물론 성능은 중요하다.

하지만 실무에서는 성능만큼이나 비용, 속도, 보안, 운영성이 중요하다.

예를 들어 가장 성능이 좋은 모델을 모든 요청에 사용한다고 해보자.

처음에는 결과가 좋아 보일 수 있다.
하지만 사용자가 늘어나면 비용이 급격히 증가할 수 있다.

또 응답 속도가 느려 사용자 경험이 나빠질 수도 있다.

반대로 너무 저렴하고 가벼운 모델만 쓰면 비용은 줄어들지만 답변 품질이 떨어질 수 있다.

그래서 모델은 작업 난이도에 따라 나누는 것이 좋다.

간단한 작업:
- 문장 분류
- 짧은 요약
- 태그 생성
- 간단한 변환

중간 난이도 작업:
- 고객 문의 답변 초안
- 문서 요약
- 코드 설명
- 일반적인 챗봇 응답

높은 난이도 작업:
- 복잡한 코드 리뷰
- 긴 문서 분석
- 장애 원인 추론
- 여러 조건을 고려한 의사결정 보조

각 작업에 같은 모델을 쓸 필요는 없다.

간단한 작업은 저렴하고 빠른 모델을 사용하고,
중요하거나 복잡한 작업은 더 성능 좋은 모델을 사용할 수 있다.

모델 라우팅 예시:

간단한 분류 요청
→ 저렴하고 빠른 모델

긴 문서 분석 요청
→ 긴 컨텍스트를 지원하는 모델

코드 리뷰 요청
→ 코드 성능이 좋은 모델

민감 정보 포함 요청
→ 로컬 모델 또는 내부망 모델

이렇게 요청 종류에 따라 모델을 선택하는 방식을 모델 라우팅이라고 부를 수 있다.

모델 라우팅은 요청의 성격에 따라 적절한 AI 모델로 보내는 구조다.
비용, 속도, 품질, 보안 요구사항에 따라 모델을 다르게 선택할 수 있다.

10. 모델 선택 기준 1: 정확도

정확도는 모델 선택에서 가장 기본적인 기준이다.

AI가 얼마나 정확한 답변을 하는지,
요구사항을 얼마나 잘 이해하는지,
잘못된 내용을 얼마나 적게 생성하는지를 봐야 한다.

하지만 정확도는 단순히 “답변이 좋아 보인다”로 판단하면 안 된다.

가능하면 테스트 질문 세트를 만들어 비교해야 한다.

예를 들어 사내 문서 검색 챗봇을 만든다면 다음과 같은 질문을 준비할 수 있다.

- 회원 탈퇴 정책은 어떻게 되는가?
- 환불 요청은 어떤 절차로 처리하는가?
- 방송 신고 처리 기준은 무엇인가?
- 관리자 권한 변경은 누가 승인하는가?
- 장애 발생 시 보고 절차는 어떻게 되는가?

각 모델에 같은 질문을 던지고 답변을 비교한다.

평가할 때는 다음 기준을 볼 수 있다.

- 질문 의도를 정확히 이해했는가?
- 답변이 문서 근거와 일치하는가?
- 모르는 내용을 추측하지 않았는가?
- 필요한 조건과 예외를 포함했는가?
- 답변 형식이 일관적인가?

코드 모델을 평가할 때는 실제 실행 여부도 중요하다.

- 코드가 실행되는가?
- 테스트를 통과하는가?
- 보안 문제가 없는가?
- 예외 처리가 되어 있는가?
- 현재 프로젝트 스타일과 맞는가?

AI 모델의 정확도는 반드시 실제 업무 데이터와 실제 질문으로 평가해야 한다.

일반적인 벤치마크 점수가 높다고 해서 우리 업무에서도 항상 좋은 것은 아니다.

벤치마크는 모델 성능을 비교하기 위해 사용하는 표준 평가 기준이다.
참고용으로는 유용하지만, 실제 업무 적용 여부는 별도 테스트가 필요하다.

11. 모델 선택 기준 2: 비용

AI 모델은 비용 구조를 반드시 봐야 한다.

특히 클라우드 AI는 대부분 토큰 사용량에 따라 비용이 발생한다.

입력이 길수록 비용이 증가하고, 출력이 길수록 비용이 증가한다.

예를 들어 다음 두 요청은 비용이 다르다.

짧은 요청:
이 문장 요약해줘.

긴 요청:
50페이지짜리 회의록을 넣고,
핵심 요약, 액션 아이템, 참석자별 발언 요약,
리스크, 후속 일정까지 정리해줘.

긴 문서를 넣으면 입력 토큰이 많아진다.
상세한 답변을 요구하면 출력 토큰도 많아진다.

서비스에 AI를 붙일 때는 다음을 계산해야 한다.

- 하루 요청 수
- 요청당 평균 입력 토큰
- 요청당 평균 출력 토큰
- 사용하는 모델의 토큰 단가
- 재시도 발생률
- 캐시 적용 가능성

비용을 줄이기 위한 방법도 있다.

- 꼭 필요한 문맥만 AI에게 전달한다.
- 긴 답변이 필요 없으면 출력 길이를 제한한다.
- 반복 요청은 캐싱한다.
- 간단한 작업은 저렴한 모델을 사용한다.
- 복잡한 작업만 고성능 모델로 보낸다.
- 사용자별 사용량 제한을 둔다.

AI 비용은 개발 초기에 작게 보일 수 있다.

하지만 사용자가 늘어나면 인프라 비용처럼 중요한 운영 비용이 된다.
따라서 모델 선택 시 비용 구조를 반드시 함께 고려해야 한다.

12. 모델 선택 기준 3: 속도

AI 서비스에서 응답 속도는 매우 중요하다.

사용자가 버튼을 눌렀는데 답변이 20초 뒤에 나온다면 답답하게 느낄 수 있다.

특히 실시간성이 중요한 서비스에서는 더 민감하다.

예를 들어 다음 기능은 속도가 중요하다.

- 실시간 채팅 보조
- 실시간 자막
- 고객센터 상담 보조
- 코드 자동완성
- 검색형 챗봇

반면 다음 기능은 상대적으로 느려도 괜찮을 수 있다.

- 하루 한 번 생성하는 보고서
- 대량 문서 요약 배치 작업
- 회의록 정리
- 야간 로그 분석

모델 속도는 여러 요소에 영향을 받는다.

- 모델 크기
- 입력 길이
- 출력 길이
- 서버 위치
- 네트워크 지연
- 스트리밍 응답 지원 여부
- 동시 요청 처리량

사용자 경험을 개선하기 위해 스트리밍 응답을 사용할 수도 있다.

스트리밍 응답은 AI 답변이 모두 완성된 뒤 한 번에 보여주는 것이 아니라, 생성되는 대로 조금씩 보여주는 방식이다.

사용자는 답변이 시작되는 것을 바로 볼 수 있기 때문에 체감 속도가 좋아진다.

일반 응답:
요청 → 전체 답변 생성 완료 → 한 번에 표시

스트리밍 응답:
요청 → 답변 일부 생성 → 바로 표시 → 계속 이어서 표시

AI 모델을 선택할 때는 단순히 전체 응답 시간이 아니라, 사용자가 느끼는 체감 속도도 함께 고려해야 한다.

13. 모델 선택 기준 4: 보안과 데이터 처리

AI 모델을 선택할 때 보안은 매우 중요하다.

특히 회사 내부 데이터나 개인정보를 다루는 경우에는 모델 성능보다 보안 요구사항이 우선될 수 있다.

AI에게 입력되는 데이터에는 다음과 같은 정보가 포함될 수 있다.

- 사용자 이름, 이메일, 전화번호
- 결제 내역
- 상담 내용
- 내부 운영 로그
- 소스 코드
- DB 스키마
- API Key
- 미공개 사업 계획

이런 데이터를 외부 클라우드 AI API로 보내도 되는지 반드시 검토해야 한다.

외부 API를 사용한다면 다음을 확인해야 한다.

- 입력 데이터가 모델 학습에 사용되는가?
- 데이터가 어느 지역에 저장되는가?
- 로그 보관 기간은 어떻게 되는가?
- 기업용 보안 옵션이 있는가?
- 개인정보 처리 계약이 가능한가?
- 민감 정보 마스킹이 필요한가?

보안 요구가 높은 경우에는 로컬 AI나 사내망 AI 구성을 고려할 수 있다.

하지만 로컬 AI라고 해서 자동으로 안전한 것은 아니다.

내부에서 실행하더라도 접근 권한, 로그 저장, 모델 서버 보안, 네트워크 제어가 필요하다.

클라우드 AI 보안 포인트:
- 외부 전송 데이터 검토
- 계약과 정책 확인
- 마스킹 처리
- API Key 보호

로컬 AI 보안 포인트:
- 모델 서버 접근 제어
- 내부 로그 관리
- 권한 분리
- 네트워크 격리

AI는 데이터를 많이 다루는 기술이다.

따라서 모델 선택 단계부터 보안과 개인정보 처리를 함께 설계해야 한다.

14. 모델 선택 기준 5: 한국어와 도메인 이해

한국어 서비스에서는 한국어 성능도 중요하다.

모델이 영어는 잘하지만 한국어 답변 품질이 떨어질 수 있다.
또 한국어는 존댓말, 조사, 문맥, 생략 표현이 많아서 모델에 따라 품질 차이가 날 수 있다.

예를 들어 고객 문의 답변을 만든다고 해보자.

결제가 두 번 됐는데요?

좋은 모델은 이 문장을 단순히 번역하듯 처리하지 않는다.
고객이 중복 결제 문제를 제기하고 있다는 점을 이해하고, 적절한 안내 문장을 만들어야 한다.

한국어 품질을 볼 때는 다음을 확인할 수 있다.

- 자연스러운 한국어 문장을 생성하는가?
- 존댓말과 반말을 일관되게 유지하는가?
- 업무 문서 스타일을 잘 따르는가?
- 한국어 질문 의도를 정확히 이해하는가?
- 줄임말이나 도메인 용어를 어느 정도 처리하는가?

도메인 이해도 중요하다.

예를 들어 방송 플랫폼에서는 일반적인 한국어 능력만으로 부족할 수 있다.

- 방송 시작
- 시청자
- 후원
- 하트
- 매니저
- 강퇴
- 채팅 금칙어
- 랭킹
- 환전

이런 용어는 일반적인 의미와 서비스 내부 의미가 다를 수 있다.

모델이 도메인 용어를 잘 모른다면, 프롬프트나 RAG를 통해 문맥을 제공해야 한다.

도메인 용어 처리 방법:
- 용어집을 프롬프트에 포함
- 사내 문서를 RAG로 연결
- 예시 질문과 답변 제공
- 금칙어, 정책, 운영 기준을 별도 문서로 관리

모델 선택에서 한국어 성능과 도메인 적합성은 반드시 직접 테스트해야 한다.

15. 모델 선택 기준 6: 컨텍스트 길이

컨텍스트 길이는 AI가 한 번에 참고할 수 있는 문맥의 양을 의미한다.

긴 문서 요약, 여러 파일 코드 분석, 긴 대화 이력 기반 응답을 만들 때 중요하다.

예를 들어 다음 작업은 긴 컨텍스트가 필요할 수 있다.

- 100페이지 문서 요약
- 여러 API 파일을 함께 분석
- 긴 회의록에서 액션 아이템 추출
- 장문의 계약서 검토
- 대화 이력을 바탕으로 고객 문의 응대

컨텍스트 길이가 짧은 모델은 이런 작업에서 중요한 정보를 놓칠 수 있다.

하지만 컨텍스트가 길다고 항상 좋은 것은 아니다.

긴 내용을 넣으면 비용이 늘어난다.
모델이 중요한 부분을 제대로 찾지 못할 수도 있다.
응답 속도가 느려질 수도 있다.

그래서 긴 문서를 다룰 때는 무작정 전체를 넣는 것보다 구조를 잘 설계해야 한다.

좋은 방식:
문서를 작게 나눈다.
→ 질문과 관련 있는 부분만 검색한다.
→ 필요한 문맥만 AI에게 전달한다.
→ 답변에 출처를 붙인다.

이 방식이 바로 RAG와 연결된다.

긴 컨텍스트 모델은 강력하지만, 모든 문제를 긴 컨텍스트로 해결하려고 하면 비용과 품질 문제가 생길 수 있다.

컨텍스트 길이는 AI가 한 번에 참고할 수 있는 입력 범위다.
길수록 많은 내용을 넣을 수 있지만, 비용과 속도, 정확성을 함께 고려해야 한다.

16. 모델 선택 기준 7: 운영 안정성

실무에서는 모델 성능만큼 운영 안정성도 중요하다.

AI 기능이 서비스에 들어가면 다음 문제가 발생할 수 있다.

- AI API 장애
- 응답 지연
- 사용량 급증
- 비용 폭증
- 잘못된 답변 생성
- 응답 형식 깨짐
- 특정 시간대 요청 집중

따라서 모델 선택 시 운영 관점도 봐야 한다.

예를 들어 클라우드 모델을 사용한다면 다음을 확인해야 한다.

- SLA가 있는가?
- 장애 발생 시 상태 페이지를 제공하는가?
- 요청 제한이 있는가?
- 동시 요청 처리량은 충분한가?
- 특정 리전 선택이 가능한가?
- 기업용 지원 채널이 있는가?

로컬 모델을 사용한다면 다음을 봐야 한다.

- GPU 장애 시 대체 서버가 있는가?
- 모델 서버를 여러 대로 늘릴 수 있는가?
- 큐를 통해 요청을 제어할 수 있는가?
- 사용량 모니터링이 가능한가?
- 모델 업데이트를 어떻게 배포할 것인가?

AI 기능은 일반 API보다 응답 시간이 길고, 실패 가능성도 다르다.

따라서 운영 환경에서는 타임아웃, 재시도, fallback 구조가 필요하다.

사용자 요청
→ AI 호출
→ 일정 시간 내 응답 없음
→ 재시도 또는 대체 모델 호출
→ 그래도 실패하면 안내 메시지 반환

fallback은 기본 모델이 실패했을 때 대체 수단으로 처리하는 구조다.

예를 들어 고성능 모델이 장애가 나면 저렴한 모델로 임시 전환하거나,
AI 답변 대신 기본 안내 문구를 보여줄 수 있다.

fallback은 장애나 실패 상황에서 대체 경로로 처리하는 방식이다.
AI API 장애 시 다른 모델을 호출하거나, 미리 준비한 기본 응답을 제공하는 식으로 사용할 수 있다.

17. 모델 선택 기준 8: 라이선스와 정책

오픈소스 모델을 사용할 때는 라이선스를 반드시 확인해야 한다.

모델이 공개되어 있다고 해서 회사 서비스에 자유롭게 사용할 수 있는 것은 아니다.

어떤 모델은 연구 목적 사용만 허용할 수 있고,
어떤 모델은 상업적 사용이 가능하지만 조건이 있을 수 있다.
또 일정 규모 이상의 서비스에서는 별도 계약이 필요할 수 있다.

확인해야 할 내용은 다음과 같다.

- 상업적 사용이 가능한가?
- 모델을 수정해서 사용할 수 있는가?
- 모델 출력물을 서비스에 사용할 수 있는가?
- 재배포가 가능한가?
- 사용 규모에 제한이 있는가?
- 별도 고지 의무가 있는가?

클라우드 AI도 정책 확인이 필요하다.

- 입력 데이터가 학습에 사용되는가?
- 금지된 사용 사례는 무엇인가?
- 로그 보관 정책은 어떻게 되는가?
- 기업용 계약 조건은 무엇인가?
- 데이터 처리 지역을 선택할 수 있는가?

AI 모델은 기술 선택이면서 동시에 법무, 보안, 정책 선택이기도 하다.

회사 서비스에 적용할 때는 개발팀만 판단하지 말고, 필요하면 보안팀, 법무팀, 개인정보 담당자와 함께 검토해야 한다.

18. 상황별 모델 선택 예시

이제 몇 가지 예시를 통해 어떤 모델을 선택하면 좋을지 생각해보자.

18.1 관리자용 문서 요약 기능

관리자가 긴 신고 내용이나 고객 문의를 빠르게 파악해야 하는 기능이다.

목적:
긴 텍스트를 짧게 요약

중요한 기준:
- 한국어 요약 품질
- 비용
- 응답 속도
- 개인정보 포함 여부

개인정보가 적고 내부 정책상 외부 API 사용이 가능하다면 클라우드 LLM이 적합할 수 있다.

다만 개인정보가 포함된다면 마스킹 처리가 필요하다.

18.2 사내 문서 검색 챗봇

직원이 사내 정책, 개발 문서, 운영 매뉴얼을 검색하는 챗봇이다.

목적:
사내 문서를 근거로 질문에 답변

중요한 기준:
- RAG 구성 가능 여부
- 긴 문서 처리
- 출처 표시
- 권한 제어
- 내부 데이터 보안

이 경우 단순 LLM 호출만으로는 부족하다.

문서 검색을 위한 임베딩 모델과 벡터DB가 필요하고,
답변 생성에는 LLM을 사용할 수 있다.

보안 요구가 높다면 로컬 모델이나 기업용 클라우드 옵션을 검토해야 한다.

18.3 PR 코드 리뷰 도우미

개발자가 올린 PR을 AI가 요약하고 위험 요소를 알려주는 기능이다.

목적:
코드 변경사항 분석과 리뷰 보조

중요한 기준:
- 코드 이해 능력
- 긴 컨텍스트 처리
- 보안 취약점 탐지
- 응답 형식 안정성
- 소스 코드 외부 전송 정책

코드 품질이 중요한 작업이므로 코드 성능이 좋은 모델을 선택해야 한다.

회사 소스 코드가 외부 API로 전송되는 것을 허용할 수 있는지도 확인해야 한다.

18.4 실시간 방송 자막

방송 음성을 실시간으로 텍스트로 변환하는 기능이다.

목적:
음성을 텍스트로 변환하고 필요 시 번역

중요한 기준:
- STT 정확도
- 지연시간
- 한국어 인식 품질
- 방송 용어 처리
- 실시간 처리 비용

이 경우 LLM만으로는 부족하다.

먼저 STT 모델로 음성을 텍스트로 변환하고,
필요하면 LLM으로 문장을 보정하거나 번역할 수 있다.

실시간 서비스에서는 정확도뿐 아니라 지연시간이 매우 중요하다.

18.5 고객 문의 자동 답변

고객 문의에 대해 답변 초안을 생성하는 기능이다.

목적:
고객 문의 답변 초안 작성

중요한 기준:
- 한국어 답변 품질
- 정책 준수
- 환각 방지
- 답변 톤
- 상담원이 검토하는 구조

이 기능은 AI가 직접 고객에게 답변을 보내는 구조보다,
상담원이 검토 후 전송하는 보조 도구로 시작하는 것이 안전하다.

AI가 회사 정책과 다른 답변을 할 수 있기 때문이다.

19. 모델 선택 체크리스트

AI 모델을 선택할 때는 다음 체크리스트를 사용할 수 있다.

1. 목적
- 어떤 문제를 해결하려는가?
- 사용자는 누구인가?
- 결과는 사람이 검토하는가, 자동 실행되는가?

2. 입력과 출력
- 입력은 텍스트, 코드, 이미지, 음성 중 무엇인가?
- 출력은 텍스트, JSON, 코드, 음성 중 무엇인가?

3. 품질
- 정확도가 중요한가?
- 한국어 품질이 중요한가?
- 도메인 용어를 이해해야 하는가?

4. 비용
- 하루 예상 요청 수는 얼마인가?
- 요청당 평균 입력/출력 길이는 얼마인가?
- 저렴한 모델과 고성능 모델을 나눌 수 있는가?

5. 속도
- 실시간 응답이 필요한가?
- 배치 처리로도 가능한가?
- 스트리밍 응답이 필요한가?

6. 보안
- 개인정보나 내부 데이터가 포함되는가?
- 외부 API로 전송해도 되는가?
- 로컬 모델이 필요한가?

7. 운영
- 장애 시 대체 모델이 있는가?
- 사용량 제한이 필요한가?
- 로그와 모니터링을 어떻게 할 것인가?

8. 정책
- 라이선스 문제가 없는가?
- 서비스 약관상 사용 가능한가?
- 회사 보안 정책과 충돌하지 않는가?

이 체크리스트를 보면 알 수 있듯이 모델 선택은 단순히 “성능 좋은 모델을 고르는 일”이 아니다.

서비스 전체 구조와 운영 조건을 함께 고려하는 설계 작업이다.

20. 정리

AI 모델은 하나만 있는 것이 아니다.

텍스트를 잘 다루는 모델, 코드를 잘 다루는 모델, 이미지를 이해하는 모델, 음성을 처리하는 모델, 여러 입력을 함께 처리하는 멀티모달 모델이 있다.

또 사용 방식에 따라 클라우드 모델과 오픈소스 모델로 나눌 수 있다.

클라우드 모델은 빠르게 시작하기 좋고 성능이 우수한 경우가 많다.
하지만 비용, 데이터 외부 전송, 벤더 의존성을 고려해야 한다.

오픈소스 모델은 내부에서 직접 실행할 수 있어 보안과 통제 측면에서 장점이 있다.
하지만 하드웨어, 운영, 성능 튜닝 부담이 있다.

모델을 선택할 때는 다음 기준을 함께 봐야 한다.

- 정확도
- 비용
- 속도
- 보안
- 한국어 품질
- 도메인 이해
- 컨텍스트 길이
- 운영 안정성
- 라이선스와 정책

가장 좋은 모델은 항상 하나로 정해져 있지 않다.

간단한 작업에는 빠르고 저렴한 모델이 좋을 수 있다.
중요한 판단이 필요한 작업에는 고성능 모델이 필요할 수 있다.
민감 정보가 포함된 작업에는 로컬 모델이 더 적합할 수 있다.

AI 모델 선택의 핵심은 이것이다.

가장 유명한 모델을 고르는 것이 아니라,
해결하려는 문제에 가장 적합한 모델을 고르는 것이다.

4장 핵심 요약