
"단톡방에 사진 메시지가 와도 운영자 톤으로 자동 답장이 가능한가요?"
가능합니다. 다만 텍스트 답장보다 한 단계 복잡합니다. 사진을 LLM 이 "보고" 텍스트 응답을 만들어야 하는데, 이 과정을 두 모델로 나누느냐 한 모델로 통합하느냐에 따라 운영 부담과 응답 품질이 갈립니다.
두 가지 경로, 한눈에 비교
같은 사진 메시지가 두 파이프라인을 통과할 때 어떻게 흐르는지 다이어그램으로 봅니다. 위쪽이 옛 직렬 방식, 아래쪽이 Replyer 가 v0.13.0 부터 쓰는 단일 멀티모달 방식.
옛 방식: 비전 모델 + 일반 LLM 직렬
~3GB
~5GB
지금 방식: 단일 멀티모달 LLM + mmproj
~0.5GB
~5GB, 같은 모델
핵심 결론: 텍스트 + 이미지를 한 호출로 처리하는 멀티모달 LLM 이 응답 톤과 운영 부담 양쪽에서 우세합니다.
별도 비전 모델 방식의 한계
초기에 많이 채택되던 흐름:
- 사용자가 사진 보냄
- 비전 모델 (Qwen2.5-VL 등) 이 사진 → 캡션 텍스트 생성 ("두 명이 카페에 있는 사진")
- 캡션을 본 LLM (페르소나 가진 모델) 에 텍스트 메시지처럼 전달
- 본 LLM 이 페르소나 톤으로 답장 생성
이 직렬 흐름의 함정:
1. 캡션 모델은 페르소나를 모름
비전 모델은 일반 캡션 모델이라 "카페", "사람 두 명", "햇살" 같은 객관 묘사만 합니다. 운영자 페르소나의 시선 ("이 카페 분위기 좋네", "둘이 친한가봐") 은 사라집니다.
2. 두 모델의 메모리 합산
비전 모델 3GB + 본 LLM 5GB = RAM 에 8GB 이상 상주. 일반 노트북 16GB RAM 환경에서 다른 앱과 충돌 빈도가 늘어납니다.
3. 캡션 토큰 손실
사진의 미세한 정보 (표정 / 분위기 / 배경 소품) 는 캡션 텍스트로 변환되면서 많이 사라집니다.
단일 멀티모달 LLM 방식
Gemma 3 (4B / 12B / 27B) 와 Gemma 4 (E2B / E4B / 26B-A4B / 31B) 모두 mmproj (멀티모달 프로젝션) 파일을 같이 로드하면 이미지를 직접 받습니다.
흐름:
- 사용자가 사진 보냄
- 페르소나 시스템 프롬프트 + 사진 + (텍스트 캡션이 있으면 같이) 를 단일 호출로 LLM 에 전달
- LLM 이 페르소나 톤으로 직접 답장 생성
컨텍스트 윈도우 안의 토큰 예산
같은 n_ctx 안에서 사진 토큰 (각 256) 이 차지하는 비중. 텍스트만 가는 단톡방과 사진 많은 단톡방의 차이가 한눈에 보입니다.
사진 5장이 8192 컨텍스트에 들어오면 여유가 거의 0. 사진 비중 높은 단톡방은 n_ctx 16384 이상 권장.
mmproj 파일은 어떻게 작동하나
mmproj 는 "multimodal projection" 의 줄임말. 비전 인코더 (이미지 → 시각 토큰) 와 LLM 의 텍스트 임베딩 공간을 연결하는 작은 신경망입니다.
llama.cpp 가 이미지 처리할 때의 흐름:
- 사용자가 보낸 이미지를 base64 data URI 로 인코딩
- mmproj 가 이미지 → 256개 (모델별 다름) 의 시각 토큰으로 변환
- 시각 토큰을 텍스트 토큰과 같은 임베딩 공간에 배치
- LLM 이 시각 + 텍스트 토큰 통합 컨텍스트로 응답 생성
운영자가 신경 써야 할 것
1. mmproj 파일 다운로드 확인
본 LLM 만 받고 mmproj 를 빼먹으면 사진 메시지에 텍스트 응답이 안 나옵니다. Replyer 의 Settings → 모델 카드에 "비전" 뱃지가 있어야 mmproj 가 같이 다운로드된 상태.
2. 응답 시간 약간 증가
이미지 토큰화 단계가 추가되어 텍스트만 처리할 때보다 2~5초 지연이 추가됩니다.
3. 토큰 예산 (컨텍스트 윈도우)
위 차트에서 본 것처럼 사진 많은 단톡방은 cfg.n_ctx 를 16384 이상으로.
4. 운영자 톤이 사진 묘사에도 맞아야
페르소나 작성 시 "사진을 봤을 때 어떻게 반응하는지" 의 가이드를 1~2줄 추가하면 일관성 향상. 예: agents/casual_chat.yaml 의 system_prompt 에 "사진엔 짧게 반응하고 본인 경험으로 연결한다".
어떤 단톡방에 효과적인가
사진 비중이 높은 단톡방일수록 멀티모달 자동 응답의 효과가 큽니다:
- 취미 단톡방 (사진 비중 30~60%) - 카페 / 운동 / 게임 인증샷 등
- 육아 / 일상 단톡방 - 사진 위주 일상 공유
- 여행 / 사진 동호회 - 거의 모든 메시지가 사진
반대로 사진 비중이 5% 이하인 정보 단톡방 (주식 / 부동산 / 뉴스) 은 단일 텍스트 LLM 으로 충분. 굳이 mmproj 메모리를 추가하지 않아도 됨.
자세한 단톡방 종류별 자동화 적합도는 정보 단톡방 자동화의 수직성 참고.
자주 묻는 질문
Q. Gemma 3 와 Gemma 4 중 어떤 것을 골라야 하나요?
Gemma 4 (E2B / E4B) 가 더 신모델이고 같은 크기 대비 한국어 / 멀티모달 품질이 약간 우수합니다. 단 일부 구버전 llama.cpp 빌드에서 Gemma 4 가 로드 실패하는 사례가 있어, Replyer 의 기본 프리셋은 Gemma 4 안 되는 환경에선 Gemma 3 또는 Qwen 으로 자동 폴백합니다. Settings → 모델 카드에서 환경에 맞는 프리셋 선택 가능.
Q. 비전 모델 두 개 (Qwen2.5-VL + Gemma) 를 같이 쓰던 사용자는 어떻게 마이그레이션하나요?
Replyer v0.13.0 부터 두 모델 직렬 호출 방식을 제거하고 단일 멀티모달 LLM 으로 통합했습니다. 기존 사용자는 자동 마이그레이션 (옛 비전 모델 설정은 cfg 에서 무시 처리). 처음 [시작] 시 mmproj 파일이 없으면 자동 다운로드.
Q. 사진 답장이 부정확하거나 엉뚱한 경우는?
세 가지 원인:
- 페르소나 시스템 프롬프트에 사진 응답 가이드가 없음 → 한 줄 추가
- mmproj 파일이 옛 버전 → 모델 카드에서 재다운로드
- 컨텍스트 윈도우가 가득 차 사진 토큰이 잘려나감 → n_ctx 16384 이상으로
대부분 1번 케이스. 페르소나에 "사진엔 짧게 반응하고 본인 톤 유지" 1줄 추가가 가장 큰 효과.
Q. 동영상 / GIF 메시지도 자동 답장 되나요?
현재 멀티모달 LLM 은 정지 이미지만 처리합니다. 동영상은 첫 프레임만 추출되거나 텍스트 응답 ("영상 잘 봤어") 으로 폴백.
Q. 응답 토큰 1장당 비용이 어떻게 되나요?
로컬 LLM (Replyer 기본) 은 호출 비용 0. 전기료 + CPU/GPU 시간만 소모됩니다. 로컬 vs 클라우드 비교는 로컬 LLM vs 클라우드 API 참고.
Q. mmproj 파일도 GGUF 인가요?
네. mmproj-f16.gguf 또는 mmproj-q8_0.gguf 형식. f16 (~500MB) 이 품질 좋고 q8 (~250MB) 이 가벼움. 일반 노트북은 f16 권장.
다음 단계
본인 단톡방에 자동 답장을 도입하려면 Replyer 다운로드 에서 본인 OS 빌드를 받고, 단계별 사용법은 사용 매뉴얼 을 참고하세요.