모델은 제품이 아니다: 로컬 Gemma 4 구축에서 얻은 교훈

Source: Dev.to

이 글은 Gemma 4 챌린지 Write About Gemma 4에 대한 제출물입니다.
능력 있는 로컬 모델을 사용할 때 가장 쉬운 실수는 모델 호출 자체를 전체 애플리케이션이라고 생각하는 것입니다.
저도 Gemma 4 E2B로 작업하면서 그 실수를 거의 저질렀습니다.

제 프로젝트는 RememberMe CareGrid라는 로컬 치매 케어 어시스턴트였습니다.
제품 목표는 똑똑하게 들리는 챗봇을 만드는 것이 아니라,
혼란스러운 환자에게 차분한 맥락을 제공하고,
보호자가 무슨 일이 있었는지 이해하도록 돕고,
신뢰할 수 있는 커뮤니티 구성원이 안전하게 대응하도록 돕는 것이었습니다.

이 때문에 Gemma 4를 보는 시각이 달라졌습니다.
Gemma 4는 제품이 아니라 제품 안의 추론 레이어였습니다.
제품은 그 주변 모든 것을 포함합니다: 전사, 맥락 경계, 동의, 구조화된 출력, 폴백, 지연 시간, UI 상태, 그리고 긴 답변이 해가 될 경우 답변을 짧게 유지하는 결정 등.

제가 얻은 가장 큰 교훈은 다음과 같습니다.

로컬 AI는 단순히 모델을 로컬에서 실행하는 것이 아니라,
모델이 담당해야 할 일, 앱이 담당해야 할 일, 그리고 절대 모델에 위임해서는 안 되는 일을 결정하는 것입니다.

Gemma 4는 개발자에게 여러 모델 옵션을 제공하고, 가장 큰 모델을 잡아먹고 싶어 하는 유혹이 당연히 생깁니다.
하지만 제 사용 사례에서는 그 직감이 잘못된 선택이었습니다.

저는 Gemma 4 E2B를 선택했습니다. 왜냐하면 애플리케이션은 로컬, 충분히 빠른, 프라이버시를 고려한 추론이 필요했으며, 가장 큰 모델이 필요하지 않았기 때문입니다. 신뢰할 수 있는 짧은 응답과 구조화된 케어 액션이 필요했습니다.

치매 케어 워크플로에서 모델이 답해야 할 질문 예시:

• “나는 누구인가?”
• “나는 어디에 있나?”
• “아난야는 누구인가?”
• “나는 안전한가?”
• “내 앞에 서 있는 사람은 누구인가?”

이 질문들은 긴 답변이 자동으로 더 좋은 경우가 아닙니다. 혼란스러운 사람은 에세이가 아니라 한두 개의 차분한 문장과 안전한 다음 단계가 필요합니다.

그래서 E2B가 적합했습니다. 실험하기에 충분히 작지만, 케어 맥락을 추론하고 유용한 구조화된 응답을 생성할 만큼 충분히 능력 있습니다.

더 큰 모델은 무거운 요약이나 복잡한 다단계 분석에 유용할 수 있지만, 환자와 직접 마주하는 루프에서는 모델 크기가 주요 병목이 아니라 제품 설계가 병목이었습니다.

이 선택을 통해 모델 선택은 리더보드 경쟁이 아니라 제품 제약에 대한 결정이라는 것을 배웠습니다.

이번 구축에서 가장 좋은 모델은 가장 큰 모델이 아니라, 로컬 지원을 실현 가능한 모델이었습니다.

핵심 깨달음은 Gemma 4가 모든 일을 담당해서는 안 된다는 것이었습니다.

초기 사고 흐름

사용자 말하기 → AI 응답

실제 시스템에서는 이 흐름이 너무 모호했습니다.

더 나은 아키텍처

오디오 또는 텍스트 입력
  → 필요 시 전사
  → 케어‑맥락 검색
  → Gemma 4 추론
  → 구조화된 응답 검증
  → UI, 시계, 전화, 혹은 보호자 행동

각 구성 요소는 서로 다른 책임을 가집니다.

• Speech‑to‑text: 오디오를 텍스트로 변환
• Gemma 4: 텍스트와 케어 맥락을 추론
• 앱: 허용된 행동인지 검증
• UI: 환자가 볼 정보량을 결정
• 보호자/커뮤니티 흐름: 누가 어떤 정보를 알 수 있는지 결정

이러한 분리는 시스템 디버깅을 크게 수월하게 만들었습니다. 환자가 무언가를 말했는데 응답이 실패한다면 다음과 같이 질문할 수 있습니다.

• 전사가 텍스트를 반환했는가?
• Gemma 4가 올바른 맥락을 받았는가?
• 모델이 유효한 JSON을 반환했는가?
• 정제 과정에서 위험한 행동을 차단했는가?
• 전달 경로가 시계나 전화에 도달했는가?

경계가 없으면 “AI가 실패했다”는 쓸모 없는 설명이 되고, 경계가 있으면 실패 원인을 관찰할 수 있습니다.

구조화된 JSON 응답 요청

일반 챗봇이라면 텍스트 응답만으로 충분할 수 있지만, 케어 어시스턴트에서는 텍스트 외에 의도, 위험 수준, 행동 여부까지 알아야 합니다.

간단히 표현한 응답 형태는 다음과 같습니다.

{
  "reply": "You are Rajamma. You are safe, and Ananya is your care contact.",
  "intent": "patient_identity",
  "risk_level": "medium",
  "action": "notify_caregiver",
  "should_end_session": false
}

이렇게 하면 모델의 역할이 문장을 쓰는 것에서 안전한 케어 경로를 선택하도록 돕는 것으로 바뀝니다.

하지만 JSON 모드가 검증 필요성을 없애지는 못합니다. 앱은 여전히 다음을 확인해야 합니다.

• 의도가 허용된 의도 중 하나인가?
• 행동이 허용된 행동 중 하나인가?
• 위험 수준이 유효한가?
• 답변이 환자에게 충분히 짧은가?
• 모델이 존재하지 않아야 할 필드를 만들어내지는 않았는가?

따라서 래퍼(Wrapper) 가 중요합니다. 모델은 제안할 수 있지만, 앱이 허용 여부를 최종 결정합니다.

가장 중요한 안전 교훈

구조화된 출력 ≠ 안전한 출력
모델 주위에 계약을 반드시 두어야 합니다.

AI 데모는 종종 극적인 답변을 보상하지만, 치매 케어 UX는 그렇지 않습니다. 환자가 혼란스러울 때 화려한 문장은 오히려 해가 될 수 있습니다. 과도한 정보는 스트레스를 증가시킵니다.

그래서 저는 환자용 응답에 세 가지 규칙을 적용했습니다.

1. 한두 개의 차분한 문장으로 답한다.
2. 기억을 잊었다고 환자를 비난하지 않는다.
3. 항상 하나의 안전한 다음 단계를 제공한다.

예를 들어 환자가 “나는 누구인가?”라고 물으면, 답변은 전기식 전기가 아니라 다음과 같이 간단히 합니다.

“당신은 라자마입니다. 케어 노트에 따르면 가끔 불안해할 수 있는데, 괜찮아요. 저는 여기서 당신과 함께하고, 아난야에게 알려드릴게요.”

이것은 Gemma 4가 만들 수 있는 가장 기술적으로 인상적인 출력은 아니지만, 제품에 맞는 올바른 출력입니다.

로컬 모델의 매력

모델이 애플리케이션에 가깝게 실행될 때, 개발자는 주변 동작을 매우 세밀하게 설계할 수 있습니다. 단순히 모델에 프롬프트를 주는 것이 아니라 경험을 설계하는 것입니다.

로컬 추론은 도움이 되지만, 자동으로 앱을 프라이버시하게 만들지는 않습니다. 이것이 Gemma 4와 작업하면서 가장 명확히 깨달은 점입니다. 프라이버시는 제품 흐름 안에 실제로 나타나야 합니다.

저희 케어 어시스턴트의 프라이버시 경계

• 모델은 케어 맥락을 추론하지만, 앱이 어떤 맥락을 보낼지 제어한다.
• 신뢰된 사람만 리콜 가능
  • 등록된 사람에 대해서만 확인
  • 알 수 없는 얼굴은 신원으로 변환되지 않음
• 이름, 사진, 전사 내용 저장 전 동의 요청
• 커뮤니티 헬퍼는 역할에 맞는 지시만 받고, 전체 환자 기록은 받지 않음
• SOS 에스컬레이션은 안전 로직이 필요할 때만 위치를 공유

이렇게 하면 프라이버시가 구체적으로 구현됩니다. Gemma 4를 로컬에서 실행하면 민감한 추론을 원격 모델에 보내야 할 필요가 줄어들지만, 신원, 동의, 보관, 에스컬레이션에 대한 규칙은 여전히 앱이 강제해야 합니다.

로컬 모델은 프라이버시 기회이며, 아키텍처가 그 기회를 현실화합니다.

또 다른 교훈: 로컬 ≠ 간단

클라우드 API가 실패하면 오류는 보통 외부에 있습니다. 로컬 모델이 실패하면 문제는 어디에서든 발생할 수 있습니다.

• 모델이 로드되지 않음
• 모델은 로드됐지만 아직 차가움(콜드 스타트)
• 요청이 타임아웃
• 프롬프트가 너무 큼
• 모델이 잘못된 JSON 반환
• 로컬 음성 인식기가 텍스트를 반환하지 않음
• 앱이 오디오를 잘못된 컴포넌트에 라우팅

그래