읽은 글을 기억으로: 서버비 0원의 온디바이스 AI 퀴즈 앱 'Blank.' 개발기

우리는 매일 수많은 아티클과 뉴스레터를 읽습니다. 하지만 다음 날이면 내용이 가물가물해지곤 합니다. ‘스크랩만 해두고 다시 보지 않는 글들을 강제로 복습하게 만들 순 없을까?’ 이 작은 고민에서 출발한 앱, Blank.의 개발 과정을 공유합니다. Blank는 링크만 넣으면 AI가 핵심을 파악해 빈칸 채우기(Cloze Test) 문제를 만들어주는 안드로이드 앱입니다.

1. 왜 서버가 아니라 기기 내부(On-device)를 선택했나

개인화된 학습 도구를 만들 때 가장 큰 고민은 두 가지였습니다. 첫째는 트래픽에 비례해 증가하는 유지보수 비용(서버비)이었고, 둘째는 사용자가 어떤 글을 읽는지에 대한 프라이버시 문제였습니다. 이를 해결하기 위해 서버 기반의 API 대신 기기 내부에서 직접 AI를 구동하는 방식을 택했습니다.

온디바이스 LLM (On-device LLM)

• 클라우드 서버를 거치지 않고, 스마트폰 기기 내부의 연산 자원(AP)만으로 구동되는 소형 인공지능 모델(이 프로젝트에서는 Google Gemma 3 사용)입니다.
• 외부로 데이터를 전송하지 않아 사용자의 프라이버시를 완벽히 보호하고, 개발자의 서버 유지 비용을 0원으로 만들기 위해 쓰입니다.
• 데이터 보안이 민감한 메모 앱이거나, 비행기 모드 같은 오프라인 환경에서도 핵심 AI 기능이 동작해야 할 때 사용합니다.
• 디자이너 관점 비교: 피그마(Figma)가 서버에 접속해야만 쓸 수 있는 클라우드 기반이라면, 온디바이스는 포토샵이나 일러스트레이터처럼 내 컴퓨터의 리소스를 직접 써서 오프라인에서도 돌아가는 독립적인 작업 환경과 같습니다.

2. 출시의 기쁨, 그리고 예상치 못한 암초

최초 버전을 완성한 뒤 긱뉴스(GeekNews)에 앱을 공개했고, 5일 만에 87대의 기기에서 다운로드되는 의미 있는 성과를 얻었습니다. 하지만 한 유저분의 뼈아픈 피드백이 도착했습니다.

"나무위키의 특정 인물 링크를 넣었더니, 7문제 중 5문제의 정답이 모두 그 인물 이름이었습니다."

앱의 핵심 경험을 해치는 치명적인 문제였습니다. 문서의 빈도수에 의존하다 보니 AI가 가장 많이 등장하는 단어에만 꽂히는 과적합(Overfitting) 현상이 발생한 것입니다.

3. 문제 해결 과정: AI의 고집 꺾기

처음에는 프롬프트에 "이미 나온 단어는 쓰지 마세요"라고 지시하거나, 중복된 정답이 나오면 다시 생성하게 만드는 재시도(Retry) 로직을 고려했습니다. 하지만 모바일 환경에서 수 초가 걸리는 추론을 여러 번 반복하는 것은 치명적인 UX 저하를 낳습니다. 속도를 희생하지 않으면서 확실한 통제 수단이 필요했습니다.

텍스트 치환 (Input Substitution)

• AI에게 문장을 분석하라고 넘기기 직전, 이미 정답으로 출제된 단어들을 코드 레벨에서 원문으로부터 강제로 가려버리는(OOO 등으로 변경) 전처리 기법입니다.
• AI가 기존 정답 단어 자체를 아예 읽지 못하게 만들어 중복 추출을 원천 차단하고, 무거운 추론 과정을 단 1회로 끝내어 앱의 반응 속도를 방어하기 위해 쓰입니다.
• 모바일 환경처럼 연산 비용이 비싸서 호출 횟수를 1회로 통제하면서 100% 확실하고 다양한 결과를 얻어야 할 때 사용합니다.
• 작업자에게 "파란색은 빼고 그려주세요"라고 말로 지시하는 것(프롬프트)은 무의식적으로 파란색을 쓸 위험이 남습니다. 텍스트 치환은 애초에 팔레트에서 파란색 물감을 빼앗은 뒤 시안을 요구하는 것과 같습니다. 오류 가능성을 시스템적으로 차단합니다.

이 방식을 통해 퀴즈 생성 속도를 늦추지 않으면서 정답의 다양성을 확보할 수 있었습니다.

4. 다음 스텝을 향해

급한 불은 껐지만, 아직 전체 퀴즈 생성 속도를 더 끌어올려야 하는 과제가 남아있습니다. 텍스트의 유사도를 모두 계산하는 무거운 TextRank 알고리즘을 걷어내고, 문단 단위로 빠르게 핵심을 짚어내는 새로운 추출 로직을 도입할 예정입니다.

읽은 것을 온전한 내 지식으로 만드는 경험, Blank.가 계속 만들어가겠습니다.

---

Google Play Store에서 Blank. 다운로드