[특강] AI 프로젝트를 위한 AI 모델 선택 노하우

이 글은 Velog에서 이전한 글입니다. Velog 원문 보기

영어 회화 서비스에 Realtime API를 써도 될까?

2026.05.23.
온라인 강의, 박성준 멘토님.

영어 회화 서비스에서 중요한 건 결국 두 가지다.
사용자가 실제로 대화하고 있다는 느낌을 받아야 하고, 피드백도 빠르게 돌아와야 한다.

기존에는 이 지점에서 병목이 컸다. 음성을 텍스트로 바꾸고, LLM이 답변을 만들고, 다시 음성으로 변환하는 과정을 순서대로 거치면 아무래도 느릴 수밖에 없다. 사용자는 “대화하고 있다”기보다 “응답을 기다리고 있다”는 느낌을 받게 된다.

그런데 이제는 상황이 조금 달라졌다. OpenAI Realtime API 같은 선택지가 생기면서, 초반 PoC 단계에서는 직접 모델을 띄우지 않고도 꽤 자연스러운 음성 대화 경험을 만들 수 있게 됐다.

직접 만들 것인가, API를 쓸 것인가

AI 서비스를 만들 때 보통 세 가지 선택지가 있다.

첫 번째는 모델을 직접 개발하는 방식이다. 성능과 구조를 가장 깊게 통제할 수 있지만, GPU 인프라와 학습 코드, 데이터가 모두 필요하다. 기간도 수주에서 수개월 단위로 잡아야 한다.

두 번째는 파인튜닝이다. 직접 모델을 만드는 것보다는 가볍지만, 그래도 학습 데이터와 튜닝 도구가 필요하다. 비용 최적화나 특정 도메인 말투, 출력 포맷을 맞추는 데는 의미가 있다.

세 번째는 API 활용이다. 비용은 사용량에 따라 나가지만, SDK만 붙이면 바로 시작할 수 있다. SW Maestro처럼 기간이 제한된 프로젝트에서는 대부분 이 선택지가 현실적이다.

강의에서도 결론은 명확했다. 4개월 안에 PoC와 MVP를 만들어야 한다면, 처음부터 모델 개발에 들어가기보다 API로 빠르게 검증하는 편이 낫다.

모델 학습이 적합한 경우도 분명 있다. 프로젝트 목표 자체가 새로운 아키텍처나 학습 기법을 연구하는 것이라면 모델을 직접 다루는 게 맞다. 기존 API가 도저히 해결하지 못하는 태스크이거나, 모델 자체가 결과물인 경우도 마찬가지다.

하지만 그 외의 대부분의 서비스형 프로젝트는 API부터 시작하는 것이 안전하다. 프론티어 모델 성능이 이미 충분히 높고, 프롬프트 수정만으로 개선할 수 있는 문제를 굳이 재학습으로 풀 필요는 없다.

음성 서비스의 병목

음성 기반 서비스에는 보통 세 가지 모델이 필요하다.

• STT.
• LLM.
• TTS.

문제는 이 세 단계를 모두 파이프라인으로 처리하면 속도가 느려진다는 점이다. STT가 끝나야 LLM이 시작되고, LLM이 끝나야 TTS가 시작된다. 이렇게 직렬로 이어지면 사용자는 매 턴마다 대기 시간을 느낀다.

영어 회화 서비스에서는 이 지연이 더 크게 체감된다. 회화는 텍스트 QA보다 리듬이 중요하기 때문이다. 답변이 조금 늦어지는 것만으로도 실제 대화감이 깨진다.

그래서 우리 서비스에서는 초반부터 Realtime API 같은 실시간 음성 인터페이스를 적극적으로 고려할 만하다. 직접 STT, LLM, TTS를 모두 붙이는 구조보다 빠르게 대화 경험을 검증할 수 있다.

비용도 설계의 일부다

강의에서 인상적이었던 부분은 비용을 꽤 현실적으로 봐야 한다는 점이었다. GPU를 직접 빌려 모델을 띄우는 비용과 API 비용은 성격이 다르다.

GPU는 계속 켜두는 순간 고정비가 된다. A100, H100 같은 GPU를 쓰면 시간당 비용이 계속 쌓인다. 반면 API는 사용량 기반이라 초반 트래픽이 적을 때는 훨씬 관리하기 쉽다.

물론 API도 싸기만 한 것은 아니다. 사용량이 커지면 금방 비용이 올라간다. 그래서 처음에는 API로 시작하되, 나중에 비용 최적화가 필요해지는 시점에 파인튜닝이나 모델 라우팅을 고민하는 흐름이 자연스럽다.

비용을 줄이는 방법도 몇 가지가 있다. 쉬운 작업은 더 저렴한 모델로 보내고, 어려운 추론만 고성능 모델에 맡기는 모델 라우팅을 쓸 수 있다. 같은 시스템 프롬프트를 반복해서 쓴다면 프롬프트 캐싱도 고려할 수 있다. 실시간 처리가 필요 없는 작업은 Batch API를 쓰는 것도 방법이다.

결국 비용 관리는 모델 선택 하나로 끝나지 않는다. 어떤 작업을 실시간으로 처리할지, 어떤 작업은 나중에 처리해도 되는지까지 같이 설계해야 한다.

좋은 AI 프로젝트 주제의 조건

좋은 프로젝트 주제가 결과의 80%를 결정한다는 말도 기억에 남았다. AI 프로젝트는 단순히 “AI를 붙였다”만으로 좋은 주제가 되지 않는다.

좋은 주제에는 몇 가지 조건이 있다.

첫째, AI가 없으면 불가능하거나 비현실적인 가치가 있어야 한다. AI 없이도 쉽게 만들 수 있는 기능이라면 AI 프로젝트로서의 설득력이 약하다.

둘째, 4개월 안에 프로토타입이 나올 수 있어야 한다. 범위가 너무 크면 반드시 쪼개야 한다.

셋째, 성공과 실패를 측정할 수 있어야 한다. “잘 되는 것 같다”는 평가 방법이 아니다. 무엇이 잘 된 것이고, 무엇이 실패인지 구체적으로 정의해야 한다.

넷째, 데이터에 접근할 수 있어야 한다. 데이터가 없으면 테스트도 어렵고, 태스크를 조정하기도 어렵다.

다섯째, 실제 사용자가 있어야 한다. 사용자 피드백이 없으면 방향을 잡기 어렵다.

나쁜 주제와 좋은 주제의 차이도 결국 구체성에서 갈린다. “AI 챗봇 만들기”는 너무 넓고 ChatGPT와 차별화하기 어렵다. 반면 “대학생 수강신청 전략 추천 Agent”처럼 대상과 문제를 좁히면 훨씬 좋은 프로젝트가 된다.

우리 서비스도 마찬가지다. “영어 회화 AI”라고 하면 너무 넓다. 특정 상황, 특정 사용자, 특정 피드백 기준을 잡아야 한다. 예를 들어 면접 영어, 여행 영어, 발표 연습처럼 태스크를 좁히면 평가 기준도 더 분명해진다.

MVP 아키텍처는 어떻게 잡을까

강의에서는 MVP 아키텍처 패턴을 네 가지로 나눴다.

가장 단순한 구조는 단일 모델이다. 입력을 넣고 LLM 응답을 받아 출력한다. 텍스트 생성, 요약, 분류처럼 단순한 작업에는 이 방식이 적합하다.

두 번째는 멀티스탭 구조다. 하나의 LLM이 모든 걸 처리하게 하지 않고, 중간에 검증이나 후처리를 넣는다. 실패 지점을 파악하기 쉽고, 각 단계별 테스트도 가능하다.

세 번째는 RAG다. 외부 문서나 지식을 벡터 DB에 넣고, 검색 결과를 바탕으로 LLM이 답변하게 만드는 방식이다. Q&A나 검색 보강이 필요한 서비스에 잘 맞는다.

네 번째는 Agent Loop다. 질문을 받고, 계획을 세우고, 도구를 호출하고, 관찰한 뒤 다시 반복하는 구조다. 외부 도구를 써야 하거나 복잡한 자동화가 필요한 경우에 맞지만 난이도도 가장 높다.

우리 서비스는 단일 모델에서 시작하되, 점점 멀티스탭 구조로 가는 흐름이 맞아 보인다. 실시간 대화는 빠르게 처리하고, 자세한 피드백은 별도 단계에서 검증하거나 저장하는 식으로 나눌 수 있다.

프롬프트 엔지니어링에서 조심할 점

프롬프트 엔지니어링에서 중요한 원칙도 있었다. 모델에게 답을 억지로 강제하기보다, 모델이 생각해야 할 방향을 잡아주는 것이 낫다는 점이다.

예를 들어 “이런 스타일로 말하지 마”라고 금지 목록을 길게 주는 방식은 오히려 성능을 떨어뜨릴 수 있다. 대신 역할, 맥락, 목표, 출력 형식을 분명히 주는 편이 더 안정적이다.

시스템 프롬프트와 Few-shot 예시는 가장 기본적인 방법이다. Zero-shot으로 잘 안 되는 경우에는 입출력 예시 2~3개만 넣어도 결과가 꽤 좋아질 수 있다.

출력 형식이 중요하다면 Structured Output이나 Tool Use를 쓰는 편이 낫다. 단순히 “JSON으로 출력해”라고 말하는 것보다 스키마를 강제하는 방식이 훨씬 안정적이다.

또 하나 흥미로웠던 건 LLM-as-Judge다. AI가 만든 결과를 다시 AI가 평가하게 하는 방식인데, 평가 기준을 잘 정의하면 사람 평가의 상당 부분을 대체할 수 있다. 우리 서비스에서도 영어 피드백의 품질을 자동으로 점검하는 데 활용할 수 있을 것 같다.

우리 서비스에 적용해 보면

이번 강의를 들으면서 우리 영어 회화 서비스의 방향도 조금 더 선명해졌다.

초반에는 API 중심으로 가는 게 맞다. 직접 모델을 서빙하려면 인프라와 운영 부담이 크고, 팀 안에 AI 모델링 경험이 충분하지 않다면 시행착오가 길어질 가능성이 높다.

Realtime API는 대화감 검증에 쓰고, STT나 TTS도 처음부터 직접 서빙하기보다 API를 붙여 빠르게 실험하는 쪽이 현실적이다. 정확도가 걱정된다면 먼저 평가 기준과 테스트 케이스를 만들어야 한다. 파인튜닝은 그다음이다.

또한 모든 피드백을 실시간으로 처리할 필요는 없다. 대화 중에는 짧고 빠른 반응을 주고, 세부 피드백은 세션이 끝난 뒤 정리해서 제공하는 식으로 나누면 속도와 정확도를 함께 챙길 수 있다.

결론

오늘 강의의 결론은 네 가지로 정리할 수 있다.

첫째, 모델을 직접 만들지 API를 쓸지 먼저 결정해야 한다. 대부분의 4개월 프로젝트는 API부터 시작하는 것이 현실적이다.

둘째, 주제를 좁혀야 한다. AI-native하고, 4개월 안에 만들 수 있고, 측정 가능한 문제여야 한다.

셋째, 스택은 단순하게 시작해야 한다. SDK 직접 호출부터 시작하고, 필요할 때 멀티스탭, RAG, Agent Loop로 확장하는 편이 낫다.

넷째, 구현은 Playground, PoC, MVP, Production 순서로 가야 한다. Stage 0에서 가능성을 먼저 확인하고, 그다음에 제품화를 고민해야 한다.

AI 프로젝트는 기술만의 문제가 아니라 의사결정의 문제라는 말이 가장 크게 남았다. 무엇을 직접 만들고, 무엇을 빌려 쓰고, 어디까지를 MVP로 볼 것인지 정하는 과정이 프로젝트의 성패를 좌우한다.