로컬 LLM 첫 실험: 요약보다 중요했던 것

Google AI Edge Gallery로 공개 릴리즈노트를 읽어보며 확인한 입력 정제의 중요성

며칠 전, Google AI Edge Gallery 앱을 설치해봤습니다.
스마트폰에서 인터넷 없이도, 로컬 LLM이 직접 돌아간다는 점이 꽤 신기했습니다.

대부분의 LLM 사용 경험은 클라우드 기반입니다.
ChatGPT, Claude, Gemini처럼 서버에 요청을 보내고 응답을 받는 방식에 익숙합니다. 반면 로컬 LLM은 모델이 기기 안에서 직접 실행됩니다. 네트워크 연결이나 외부 서버 의존 없이, 스마트폰 자체에서 추론이 일어납니다.

AI/LLM Product Manager 관점에서는 이 지점이 흥미로웠습니다.

단순히 “핸드폰에서 AI가 돌아간다”는 기술적 신기함보다, 실제 제품에 붙인다면 어떤 가능성과 제약이 있을지 궁금했습니다. 그래서 아주 가볍게 1시간 정도 짧은 실험을 해봤습니다.

이번 실험의 질문은 단순했습니다.

로컬 LLM은 공개 릴리즈노트를 PM 관점에서 요약하고 해석할 수 있을까?

실험 대상: 공개 릴리즈노트

회사 문서나 내부 기획안을 넣는 것은 보안상 적절하지 않다고 판단했습니다.
그래서 공개된 문서를 사용했습니다.

이번에 사용한 문서는 Linear의 Releases 관련 공개 changelog였습니다.

처음에는 “패치노트”라고 생각하니 자연스럽게 게임 업데이트 문서가 떠올랐습니다. 하지만 이번 실험의 목적은 게임 밸런스 해석이 아니었습니다. 보고 싶었던 것은 기능 변화가 실제 업무 흐름을 어떻게 바꾸는지, 그리고 로컬 LLM이 단순 요약을 넘어 제품 관점의 해석까지 할 수 있는지였습니다.

그래서 게임 패치노트보다 업무툴 릴리즈노트가 더 적합하다고 봤습니다.

실험 환경

기기는 갤럭시 S23+를 사용했습니다.
앱은 Google AI Edge Gallery였습니다.

실제로 비교한 모델은 두 개였습니다.

• Gemma-4-E2B-it
• Gemma-3n-E2B-it

그 외에 Qwen, DeepSeek 계열 모델은 실행 엔진 생성 단계에서 실패했고, Gemma-4-E24-it은 RAM 부족으로 앱이 종료됐습니다.

이 지점부터 하나의 관찰이 생겼습니다.

온디바이스 LLM에서는 “목록에 있는 모델”과 “내 기기에서 실제로 안정적으로 실행 가능한 모델”이 다를 수 있습니다.

클라우드 LLM에서는 잘 보이지 않던 제약입니다.
하지만 로컬 LLM에서는 기기 성능, 모델 크기, 런타임 호환성이 바로 사용자 경험이 됩니다.

실험 방식

프롬프트는 단순 요약이 아니라 PM 관점의 해석을 요청하는 방식으로 구성했습니다.

핵심 조건은 세 가지였습니다.

• 기능 나열보다 업무 흐름 변화 중심으로 볼 것
• 원문에 없는 내용은 추정하지 말 것
• 마케팅 문구를 제품 관점으로 번역할 것

즉, “무슨 기능이 추가됐나요?”가 아니라
“이 기능이 팀의 일하는 방식을 어떻게 바꾸나요?”를 물어본 셈입니다.

첫 번째 관찰: 원문 전체를 넣으면 노이즈까지 해석했습니다

처음에는 changelog 페이지의 내용을 거의 그대로 붙여넣었습니다.
그런데 원문에는 Releases 섹션 외에도 Project Slack channels라는 별도 업데이트 항목과 페이지 하단 메뉴가 함께 섞여 있었습니다.

사람이라면 자연스럽게 구분할 수 있습니다.

“아, 여기부터는 다른 업데이트 항목이구나.”

하지만 모델은 그렇지 않았습니다.
두 모델 모두 Slack 채널 자동 생성 기능까지 Linear Releases의 일부처럼 섞어서 해석했습니다.

이때 가장 먼저 든 생각은 이것이었습니다.

로컬 LLM이 문서를 잘 요약하는지보다, 어떤 범위를 분석해야 하는지 구분하게 만드는 일이 먼저 필요합니다.

모델 성능 이전에 입력 정제가 중요했습니다.

두 번째 관찰: 본문을 정제하자 결과가 안정됐습니다

이후 불필요한 Slack 섹션과 푸터를 제거하고, Linear Releases 본문만 다시 넣었습니다.
동일한 프롬프트로 두 모델을 비교했습니다.

결과는 꽤 명확했습니다.

Gemma-4-E2B-it은 약 24.7초가 걸렸습니다.
핵심을 비교적 간결하게 잡았습니다. 특히 “코드가 merge 되었는가”가 아니라 “실제로 고객에게 live 되었는가”를 확인한다는 점을 잘 해석했습니다. 리스크도 CI/CD 연동 의존성, 기존 워크플로우 전환 비용처럼 PM 관점에서 볼 만한 항목을 뽑았습니다.

Gemma-3n-E2B-it은 약 58.6초가 걸렸습니다.
구조는 나쁘지 않았지만, 상대적으로 장황했고 일부 표현은 원문보다 확장된 해석에 가까웠습니다.

이번 환경에서는 Gemma-4-E2B-it이 속도와 결과 품질의 균형 면에서 더 실사용에 가까웠습니다.

PM 관점에서 얻은 인사이트

이번 실험은 거창한 벤치마크는 아니었습니다.
하지만 짧은 실험만으로도 몇 가지 방향은 보였습니다.

첫째, 로컬 LLM은 1차 구조화에는 충분히 가능성이 있었습니다.
공개 릴리즈노트의 핵심 변화, 업무 흐름 변화, 리스크 후보를 뽑는 정도는 기대보다 괜찮았습니다.

둘째, 모델보다 입력 정제가 먼저였습니다.
웹페이지 전체를 그대로 붙여넣으면 모델은 주변 섹션과 푸터까지 함께 해석할 수 있습니다. 실제 제품이라면 “본문만 추출하기”, “분석 범위 확인하기”, “불필요한 텍스트 제거하기” 같은 UX가 중요해 보였습니다.

셋째, 결과 검토 UX가 필요합니다.
프롬프트에 “추정하지 말라”고 넣어도 모델에 따라 일부 과잉 해석은 발생했습니다. 따라서 로컬 LLM을 실무 보조도구로 쓴다면, 최종 판단보다는 초안 생성, 1차 분류, 검토 질문 생성처럼 사람이 확인할 수 있는 단계에 먼저 붙이는 것이 현실적이라고 느꼈습니다.

정리하면 이렇습니다.

로컬 LLM은 공개 문서의 1차 요약과 구조화에는 충분히 쓸 만했지만, 실무형 PM 보조도구로 쓰려면 입력 정제, 추정 억제, 결과 검토 UX가 함께 설계되어야 합니다.

다음 실험을 예고하며

이번에는 공개 릴리즈노트 하나로 짧게 실험해봤습니다.
다음에는 공개 데이터셋을 활용해, 로컬 LLM이 반복적인 텍스트 분류나 리뷰 구조화 같은 PM 업무 보조에 어디까지 쓸 수 있는지 조금 더 긴 실험으로 확인해보려고 합니다.

다만 아직 주제를 고정하지는 않으려고 합니다.
직접 돌려봐야 보이는 제약이 있고, 실험하면서 더 적합한 질문이 생길 수도 있기 때문입니다.

이번 실험에서 가장 인상적이었던 것은 모델의 답변 자체보다, 답변이 흔들리는 지점이었습니다.

AI 제품은 모델만으로 만들어지지 않습니다.
모델이 잘하는 일과 흔들리는 지점을 제품 경험 안에서 어떻게 다룰지가 더 중요합니다.

이번 짧은 실험은 그걸 확인한 첫 번째 기록이었습니다.