[Lymo 개발일지 #3] AI 환각 때려 잡기

1️⃣ Lymo 개발일지 #1: https://parkcool.tistory.com/8

2️⃣ Lymo 개발일지 #2: https://parkcool.tistory.com/12

3️⃣ Lymo 개발일지 #3: 현재 글

4️⃣ Lymo 개발일지 #4: https://parkcool.tistory.com/17

안녕하세요! 지난 글에서는 SSE를 버리고 RTDB로 갈아탄 삽질기를 통해 실시간 데이터 스트리밍을 어떻게 구현했는지 이야기했었죠.

 

오늘은 혼란의 AI 개발 과정을 다뤄보려 합니다. 그리고 그 혼란 속에서 저를 구원해 준 TypeScript와 Zod 이야기도요.

 

🤯 AI 개발의 현실

흔히 AI 개발이라고 하면, "프롬프트를 입력하니 AI가 척척박사처럼 대답해주는" 모습을 상상합니다. 저도 그랬고요. Genkit 코드 몇 줄로 LLM을 호출하고, 가사를 번역해달라고 명령하면 끝날 줄 알았죠. 저는 심지어 위 사진처럼 프롬프트도 정말 자세하게 작성했습니다.

 

하지만 현실은 시궁창이었습니다. Lymo는 반응 속도를 위해 가볍고 빠른 gemini-2.5-flash-lite 모델을 주로 사용합니다. 그런데 얘는 비용이 저렴하고 반응 속도가 빠릿빠릿한 대신, 지침을 무시하거나 딴소리, 헛소리를 하는 빈도가 꽤 높았습니다. 심지어 일반 모델인 gemini-2.5-flash 모델에서도 이런 현상은 적지 않게 일어났습니다. 대표적으로 발생한 현상들을 살펴보겠습니다.

🤯 1. 지침 무시

저는 가사 중간에 들어가는 추임새(예: "Yeah", "Ooh", "Baby")처럼 의미 없는 말은 번역하지 말고 null을 반환하라고 명시했습니다. 하지만 AI는 굳이 원문을 그대로 뱉어내거나("Yeah"), 억지로 번역하려고 시도했습니다.

 

해석 대상 언어와 원문 언어가 동일한 경우에도 null을 반환하라고 했습니다. 예를 들어 사용자가 가사를 한국어로 번역하기를 요청했는데, 가사가 이미 한국어인 경우에는 null를 반환해야 합니다. 하지만 이 경우에도 AI는 원문을 그대로 뱉어내는 경우가 많았습니다.

🤯 2. 할루시네이션

위 짤을 보신 적 있으신가요? ChatGPT 출시 초반 대중들에게 AI 환각이라는 개념에 대해 각인시켜준 사례였습니다.

 

AI가 없는 사실을 지어내거나, 그럴 듯하게 꾸며내어 진실인 양 답변하는 하는 것을 환각, 할루시네이션이라고 합니다. 제 경우에는 최신 노래에 대해 해석을 요청했을 때 특히 많이 발생했는데요. AI는 학습된 시점의 이후의 사건에 대해서는 전혀 알지 못하기 때문에 발생하는 현상이었습니다. (cutoff 문제) 알지 못하는 정보에 대해 물어보니 없는 사실을 억지로 만들어 이상한 소리를 해대는 것이죠.

🤯 3. 반환 형식 불일치

가장 치명적인 문제는 배열 길이 불일치였습니다. 가사 4줄을 배열로 보냈으면 번역도 정확히 4줄이 와야, 앱 화면에서 원문과 번역문을 1:1로 매칭할 수 있겠죠? 그런데 AI가 자기 마음대로 두 문장을 합치거나, 한 문장을 쪼개서 3줄이나 5줄을 반환해버리는 겁니다. 이러면 뒤따라오는 모든 가사 싱크가 다 밀려버리는 대참사가 발생합니다.

 

🛠️ 프롬프트 깎기

처음엔 AI를 설득하려고 노력했습니다. 프롬프트를 수정하고 또 수정했죠.

1. 프롬프트 깎기: "모르는 것은 답변하지 말 것.", "절대로 ~~하지 말 것.", ...처럼 해서는 안 되는 것을 명확히 명시하고, 입/출력 형식과 그 예시를 제시하고, "너는 가사 분석 전문가야.", "너는 가사 해석에 타고난 번역가야.", ...처럼 AI의 역할을 정해주는 등 AI의 답변 품질을 올리는 데 효과적인 것으로 알려진 문구들을 다수 포함시켰습니다.
2. 번호표 붙여주기: 입력 데이터 (JSON 배열)를 그냥 주지 않고, 각 문장 앞에 1, 2, 3 번호를 붙여서 줬습니다. "자, 1번 줄 번역해. 2번 줄 번역해."라고 명확하게 번호를 명시한 거죠.
3. 생각할 시간 주기: 바로 답을 내놓으라고 하면 틀리니까, 출력 스키마 맨 앞에 reasoning 필드를 추가했습니다. "답변하기 전에 이 문장을 어떻게 번역할지, 혹시 합쳐야 할 문장은 없는지 먼저 생각해 봐" 라고 낙서장을 쥐여준 셈입니다.

그 결과 정답률이 (체감상) 70%에서 80%까지 올라갔습니다. 부족했습니다. 사용자가 20%의 확률로 엉망진창인 해석을 보게 할 수는 없었습니다. 또한 이러한 방법으로는 할루시네이션 문제를 근본적으로 해결할 수 없었습니다.

 

🌐 웹 검색 능력 쥐여주기

할루시네이션 문제를 해결하기 위한 대표적인 방법 중 하나는 검색증강생성, RAG입니다. 쉽게 설명하면 AI에게 외부 지식을 제공하여 정확하고 최신의 정보를 반환할 수 있도록 하는 기술입니다. 이 기술을 이용하면 AI가 검색 엔진을 통해 스스로 필요한 정보를 검색하고, 이 정보를 바탕으로 응답을 생성하도록 할 수 있습니다.

 

import { genkit } from 'genkit';
import { vertexAI } from '@genkit-ai/google-genai';

const ai = genkit({
  plugins: [ vertexAI({ location: 'us-central1' }) ]
});

const response = await ai.generate({
  model: vertexAI.model('gemini-2.5-pro'),
  prompt: 'Explain Vertex AI in simple terms.',
});

console.log(response.text());

제가 사용 중인 AI 개발 프레임워크인 Genkit에서는 이 기능을 정말 쉽게 결합할 수 있습니다. Genkit이 제공하는 플러그인 중 하나인 Vertex AI를 사용하면 됩니다. Vertex AI는 Google Cloud에서 제공하는 AI 플랫폼인데, 여기서 제공하는 웹 검색 + 스크래핑 + 답변 기능을 "설정 딸깍" 한 번으로 갖고 올 수 있습니다.

 

실제로 제가 웹 검색 RAG을 결합하기 위해 작성했던 코드의 양이 10줄이 채 안 돼요. Genkit을 사용하시는 분들 중에 자신의 서비스에 웹 검색 RAG를 결합해보고 싶으신 분들은 무조건 Vertex AI 찾아보시기 바랍니다!! 🥹🥹 자세한 정보는 다음 공식 문서를 참고해보세요.

Vertex AI plugin

 

프롬프트를 개선하고, 웹 검색 RAG까지 붙이니 정답률이 80%에서 90%까지는 올라간 것 같았습니다. 특히 최신 노래에 대해 말을 지어내는 현상은 정말 많이 개선되었습니다. 하지만 서비스에 필요한 건 90%가 아니라 99%의 안정성이었습니다. 10%의 확률로 사용자는 여전히 엉망진창인 해석을 봐야 했으니까요.

 

🛡️ 결국 믿을 건 '코드'뿐이다

저는 AI를 100% 신뢰하는 것을 포기하고, 기계적인 검증 로직으로 AI를 검증하기로 했습니다. AI가 뱉은 결과물을 코드가 채점하는 코드를 짜는 것이죠.

1. 📏 텍스트 유사도 검사

const similarity = calculateSimilarity(lyrics[index].text, translation);
if (similarity > 0.8) return null;

AI한테 "Yeah"를 번역하라고 했더니 "Yeah"라고 그대로 답했다고 가정해봐요. 프롬프트로는 이걸 막기가 너무 힘듭니다. 그래서 코드로 입력값과 출력값의 텍스트 유사도 (Levenshtein 거리, 레벤슈타인 거리)를 계산했습니다. 유사도가 지나치게 높으면(거의 베껴 썼으면) 코드가 강제로 그 값을 null로 덮어씌워 버립니다.

2. 🌪️ 입력값 필터링

const filteredLyrics = lyrics.filter((lyric) => {
  const detectedLang = detectLanguage(lyric.text);
  return detectedLang !== targetLanguage;
});

번역 대상 언어가 한국어이고 번역할 가사가 "안녕하세요"인데, AI가 마찬가지로 "안녕하세요"를 그대로 반환하는 경우도 많았습니다. 가사가 이미 번역 대상 언어인 경우에는 null을 반환하라고 명령했음에도 불구하고요. 그래서 저는 이미 번역 대상 언어인 문장은 입력값에서 제외하는 필터링 로직을 추가하였습니다. 1번 방법인 텍스트 유사도 검사 방법과는 달리, AI에게 값을 전달하기 전에 필터링해버리는 방법이기 때문에, 입출력 토큰을 절감할 수 있다는 추가적인 이점도 있었습니다.

 

import { franc } from "franc-min";

const language = franc(text)

가사가 어떤 언어인지 구별하기 위해서는 franc 라이브러리를 활용했습니다. 이 라이브러리의 franc 함수를 이용하면 위 코드처럼 매우 손쉽게 문장의 언어를 판별할 수 있습니다!

3. 🔄 재시도

config: { temperature: Math.max(0.1, 0.4 - (retry * 0.3) / MAX_RETRIES) }

배열 길이가 안 맞으면 어떻게 할까요? 답이 없습니다. 맞을 때까지 다시 시키는 수밖에요. 단, 그냥 다시 시키면 또 틀릴 수 있으니, 재시도할 때마다 temperature (창의성 수치)를 조금씩 낮췄습니다. "다시 해. 이번엔 좀 덜 창의적으로, 더 기계적으로 번역해" 라고 다그치는 로직을 구현한 거죠. (물론 이 방법 역시 보조적인 수단일 뿐, 완벽한 결과를 보장하는 수단은 아닙니다.)

 

이 과정에서 배운 교훈은 명확합니다. "AI 기능 구현에서 AI 모델은 부품일 뿐이다. 그 부품을 완벽하게 동작하게 만드는 건 결국 개발자의 직접 작성한 코드이다."

 

🤝 Typescript + Zod: 혼란스러운 백엔드에 평화를

AI와 씨름하며 멘탈이 나갈 때쯤, 저를 치유해 준 건 TypeScript와 Zod였습니다. 1인 개발의 최대 장점은 프론트엔드와 백엔드를 혼자 다 짠다는 점이고, 이 장점을 극대화하려면 타입과 스키마를 공유해야 합니다.

 

저는 packages/schemas라는 폴더를 만들고, 거기에 DB 스키마와 API의 입출력 스키마를 Zod로 정의해서 양쪽에서 같이 썼습니다. 특히 RTDB 데이터 구조 정의에서 Discriminated Union 패턴이 빛을 발했습니다.

export const StoryRequestSchema = z.union([
  // status가 "PENDING"일 때
  z.object({
    status: z.literal("PENDING"),
    trackId: z.string(),
  }),
  
  // ...
  
  // status가 "COMPLETED"일 때
  z.object({
    status: z.literal("COMPLETED"),
    generatedStory: StorySchema,
  }),
]);

Discriminated Union이란, 여러 객체 타입이 공통된 리터럴 필드(여기서는 status)를 가짐으로써, 그 필드의 값만으로 객체의 구체적인 타입을 식별할 수 있게 하는 타입스크립트의 패턴입니다. 이렇게 정의해두면, 코드를 짤 때 if (request.status === "PENDING") 조건문 안으로 들어가는 순간, 타입스크립트가 "여기엔 아직 generatedStory는 없고 trackId는 무조건 있다" 라고 똑똑하게 추론해버립니다. 예시 코드를 살펴볼까요?

 

📌 Discriminated Union 적용 사례

const reducer = (_acc, chunk) => {
  if (chunk.status === "IN_PROGRESS" || chunk.status === "COMPLETED") {
    return {
      id: chunk.storyId,
      data: chunk,
    };
  }
}

위 코드는 프론트엔드에서 RTDB에 작성된 storyRequest 값을 처리하는 함수입니다. chunk는 StoryRequestSchema의 스키마를 따르는 값으로, status 값이 "IN_PROGRESS"이거나 "COMPLETED"이면 overview, lyricsTranslations 등 해석 정보가 선택적으로 존재합니다. 따라서 이러한 값들을 그대로 반환하여 사용자 화면에 뿌려주는 구조인 것이죠.

 

이것을 Type Narrowing이라고 하는데요, 덕분에 옵셔널 체이닝(?.)을 남발할 필요가 사라집니다. AI가 뱉어내는 데이터는 불확실하지만, Zod이 지켜주는 타입 시스템 덕분에, 컴파일 에러가 안 나면 런타임에서도 안전하다는 확신을 가질 수 있었습니다. 그 확신은 개발 생산성을 엄청나게 높여주었습니다.

 

➡️ 정리 및 다음 단계

이렇게 우여곡절 끝에 Lymo의 백엔드가 얼추 완성되었습니다.

• Firebase + Genkit으로 서버리스 AI 환경을 구축하고,
• RTDB로 실시간 스트리밍을 구현해냈으며,
• 프롬프트 엔지니어링 + 견고한 알고리즘으로 AI를 참교육하고,
• Typescript + Zod로 견고한 타입 안정성도 확보했습니다.

혼자서 이 모든 의사결정을 하고, 디버깅하고, 삽질하는 과정이 참 고되면서도 즐거웠습니다. "이게 되네?" 하는 순간의 짜릿함이 개발을 멈출 수 없게 만드는 것 같네요.

 

다음 편부터는 프론트엔드 개발기로 넘어가겠습니다. 읽어주셔서 감사합니다!!!