2P by GN⁺ | ★ favorite | 댓글 2개
  • 모바일 키보드의 스와이프 입력 방식을 공개 모델 + 알고리듬으로 구현하려는 시도
  • 기존 고품질 스와이프 입력은 프라이버시 침해적 키보드 앱이나 라이선스 없는 비공개 라이브러리에 묶여 있어 대체재가 필요했음
  • 완전 오프라인 안드로이드 앱 FUTO Keyboard에 탑재되며, 모델을 내려받아 직접 빌드도 가능
  • 2024년 8월부터 QWERTY 영어 스와이프를 수집해 100만 건 이상을 확보했고, 2025년 3월 MIT 라이선스 데이터셋으로 HuggingFace에 공개함
  • 구조는 범용 Encoder, 언어별 ContextLM, 언어·레이아웃별 Decoder로 나뉘며, 테스트셋에서는 top-4 실패율 약 4%, OOV 제외 오류율 1% 미만을 기록함
  • 전체 모델은 약 250만개 파라미터 규모, 활성 파라미터 약 136만 개의 소형 모델로 C++ 추론 라이브러리 swipe-library를 통해 저사양 기기에서도 밀리초 단위 실행을 목표로 함

공개 스와이프 입력 모델로 풀려는 문제

  • FUTO Swipe는 스와이프 경로를 단어 예측으로 변환하는 모델과 알고리듬 제품군임
  • 현재 완전 오프라인 Android 키보드 앱인 FUTO Keyboard 에서 사용할 수 있음
  • 웹페이지 데모는 페이지 크기를 줄이기 위해 서버 측에서 실행되지만, 실제 제품 환경에서는 온디바이스로 동작해 지연 시간이 더 낮음
  • FUTO는 이 시스템을 FUTO Keyboard용으로 주로 개발했지만, 더 넓은 커뮤니티의 모델 활용도 환영
  • 장기 투자 결과물이기 때문에 최종 사용자에게 보이는 형태의 저작자 표시를 요청하며, 모델 라이선스는 FUTO Model License를 따름

데이터셋과 모델 구성

  • 2024년 8월 swipe.futo.org에서 QWERTY 영어 스와이프 데이터 수집을 시작함
    • 사용자는 모바일 웹페이지에 자발적으로 방문해 안내와 데이터셋 정보를 확인함
    • 동의 후 주로 Wikipedia에서 온 문장을 단어별로 스와이프함
    • 결과적으로 100만 건 이상의 스와이프가 만들어졌고, 일부 저품질 스와이프는 필터링됨
    • 2025년 3월 100만 스와이프 데이터셋을 MIT 라이선스로 HuggingFace에 공개
  • 모델 아키텍처는 역할이 다른 세 모델로 나뉨
    • Encoder: 레이아웃과 언어에 독립적인 범용 모델로 일반적인 스와이프 입력 예측에 쓰이지만, 최첨단 정확도를 제공하지는 않음
    • ContextLM: 단일 언어용의 아주 작은 언어 모델로, 앞선 단어를 바탕으로 말이 안 되는 후보를 제거해 예측 품질을 높임. 학습에 텍스트 데이터만 필요
    • Decoder: 언어와 레이아웃에 특화된 모델로 레이아웃 특성을 학습해 최고 수준 정확도를 내며, 현재는 QWERTY 영어 Decoder만 있음

성능과 실행 규모

  • 성능 수치는 벤치마크에 크게 의존하므로 실제 사용 결과는 달라질 수 있음
    • 3개 모델과 beam width 300 조합에서 테스트셋 top-4 실패율은 약 4%
    • 사전에 없는 단어를 제외하면 오류율은 1% 미만
    • FUTO는 대형 기술 기업의 키보드와 맞먹는 수준으로 평가함
  • 모델은 모바일 실행을 고려한 작은 규모임
    • Encoder는 635,140개 파라미터
    • Decoder는 추가 304,155개 파라미터
    • ContextLM은 150만 개 파라미터이며, 이 중 110만 개는 임베딩
    • 활성 파라미터는 1,364,271개, 총 파라미터는 2,494,767개
    • 저사양 기기에서도 밀리초 단위로 실행 가능하고, 학습에는 워크스테이션 GPU 1개를 넘게 필요로 하지 않았음

추론 라이브러리와 라이선스

  • 모델 예측만으로는 충분하지 않아, 단어 후보를 점수화하고 가장 가능성 높은 후보를 찾는 사전 제약 beam search가 필요함
    • 이를 위해 C++ 라이브러리인 swipe-library를 공개함
    • swipe-library는 전체 추론, 디코딩, beam search를 처리해 스와이프 경로에서 단어 예측까지 연결함
    • 모델은 FUTO Model License, 추론 라이브러리는 GPL로 제공됨
  • FUTO는 학습과 아키텍처를 더 자세히 다룰 논문을 준비 중임

댓글과 토론

이 회사의 음성 인식 키보드 쓰고 있는데 좋습니다.

Hacker News 의견들
  • 속도 때문에 스와이프 입력을 좋아함. 탭보다 대체로 빠르고 한 손으로 쓰기 쉽지만, 비슷한 단어를 계속 틀리고 단일/중복 글자 구분도 약함
    오래전부터 스와이프 전용 새 키보드 배열을 원했음. Dvorak이 영어 타이핑의 인체공학을 최적화했듯, 스와이프할 때 단어 겹침과 모호성을 줄이는 배열이 있으면 좋겠음
    꼭 26키일 필요도 없고, v/w/x/z를 한 키에 몰아넣고 단일 글자는 길게 눌러 입력하게 할 수도 있음. 반대로 eee를 분리하거나 “이전 글자 중복” 특수 키가 필요할 수도 있음
    QWERTY가 스와이프에 너무 맞지 않아서 생기는 문제가 대부분이라, 영어에서 정확도를 지금 체감상 90~95%가 아니라 99.9% 까지 올릴 최적 배열이 나오면 새 배열을 배울 의향이 충분함

    • FUTO Swipe가 바로 그런 스와이프 최적화 키보드 배열인 ClearFlow를 지원함: https://clearflowkeyboard.github.io/
      https://github.com/futo-org/futo-keyboard-layouts/issues/163
    • 90~95%라는 추정은 꽤 정확하고, 테스트셋에서도 그 정도로 측정됨. 곧 관련 블로그 글이 나올 예정임
      모델 구조상 각 배열에서 약 5만 단어의 합성 스와이프를 만들고 모델에 통과시켜 인식 정확도를 직접 최적화할 수 있었고, 이런 방식으로 약 80만 개 배열을 테스트했음
      QWERTY의 가장 큰 문제는 너무 많은 단어가 일직선이거나 둔각인 3글자 연속 패턴으로 스와이프된다는 점임. 이런 패턴은 인식도 어렵고 사용자가 어떤 글자를 의도했는지 제스처로 명확히 표시하기도 어려움
      신경망 스와이프 모델은 알고리즘식 모양 매칭처럼 제스처 형태를 맞추기보다, 사용자가 특정 글자를 겨냥했다는 신호를 제스처 패턴에서 찾음
      키보드의 형태를 바꾸면 제스처가 더 잘 형성되어 글자 신호가 뚜렷해질 수 있음. 모델은 모양 매칭과 달리 시간 정보도 쓰기 때문에 머무른 시간에도 반응할 수 있지만, 머무름은 흐름을 끊으므로 스와이프 배열에서는 최소화하는 편이 낫다고 봄
    • 예전 물건이라 지금은 관련성이 낮을 수 있지만, 제스처 인터페이스를 멋지게 다시 상상한 사례로 https://www.the8pen.com/가 있음
      현대적 후속작도 있는 듯함: https://play.google.com/store/apps/details?id=inc.flide.vi8
    • 나도 한동안 이걸 원해왔음. 지금은 좋은 입력 속도를 위해 휴대폰을 가로로 돌렸을 때 나오는 분할 모드에서 Dvorak을 쓰고 있음
  • 이 키보드를 한동안 간헐적으로 써왔지만 항상 gboard로 돌아갔는데, 이번 업데이트 이후 완전히 갈아탔음. 정말 좋음
    문장 중간 단어를 무작위로 대문자화하는 문제도 있고, 단어 추천에서 문맥을 잘 고려하지 않는 듯해서 직전 단어 뒤에 올 리 없는 단어가 자주 뜸
    아직 gboard만큼은 아니지만 계속 쓸 만큼 가까워졌음
    더 강력한 기기를 쓰면 사이트에서 더 큰 음성 모델과 더 큰 사전을 받을 수 있고, 체감 차이가 꽤 남
    근본적으로 아쉬운 건 GIF 검색 추가에 이념적으로 반대하는 듯하다는 점인데, 가끔 그 기능이 그리움: https://github.com/futo-org/android-keyboard/issues/293#issu...

    • 비슷한 상황인 듯함. 음성-텍스트 변환이 가끔 갑자기 이모지를 마구 뱉기 시작하던데, 그런 적 있었는지 궁금함
  • 멋짐. FUTO 키보드를 2년째 쓰고 있고 지금까지 찾은 무료·프라이버시 친화 키보드 중 최고였지만, 이런 키보드들의 스와이프는 너무 안 좋아서 스와이프를 많이 쓰는 입장에서는 고통이었음
    데이터셋에 보태려고 한 시간 정도 스와이프한 게 실제로 도움이 된 듯해 반가움. 지금 써보니 Google 키보드만큼 좋아진 느낌임
    다만 what's 대신 whats로 계속 스와이프되는 건 좀 웃김. 나중에 고쳐지면 좋겠음

  • 라이선스가 궁금한 사람을 위해 말하면, 라이브러리는 GPLv3라 좋지만 Android 키보드는 Futo License라 별로임
    https://gitlab.futo.org/keyboard/swipe-library/-/blob/master...
    https://github.com/futo-org/android-keyboard/blob/master/LIC...

    • 라이선스 복잡성을 더하자면, 모델은 FUTO가 따로 작성한 또 다른 라이선스를 쓰지만 적어도 키보드 라이선스만큼 나빠 보이지는 않음: https://huggingface.co/futo-org/futo-swipe/blob/main/LICENSE...
    • Futo License에서 특히 문제가 되는 부분이 무엇인지 궁금함
      혹시 이 조항 때문인가: 배포하는 사본에서 라이선스 제공자에게 지불하는 기능을 제거하거나 가릴 수 없다는 부분
    • 그냥 조건이 아주 약한 상업용 라이선스에 가까움
  • 몇 년 전 iOS에서 Nintype을 경험한 뒤로는 다른 스와이프 키보드를 못 쓰겠음. 지금은 기본 키보드로 타이핑하고, 두 손을 쓸 수 없을 때만 가끔 한두 단어를 스와이프함
    폰을 양손으로 들고 있을 때 한 손가락으로 스와이프하는 건 부자연스럽고 굼뜨게 느껴짐. Apple이 Nintype을 사들이거나 셜록해서 기본 키보드에 통합했으면 좋았겠음

    • 나도 그걸 썼음. FUTO에 여러 개의 동시 또는 비동시 스와이프로 한 단어를 입력하는 기능이 있는지 궁금했는데, 아마 없는 듯함. 앱 이름도 잊고 있었는데 정말 추억 돋음
      Apple이 공식적으로 서드파티 키보드를 허용하기 전부터 쓰고 있었음
    • 완전히 동의함. 제작자가 keyboard 69라는 이름의 버그 많은 Android용 Nintype 포트를 만들었고, 그걸 몇 년 동안 썼음
      사용자 경험은 놀라웠고, 이후 시도한 모든 스와이프 시스템은 비교하면 정말 둔하게 느껴짐. 두 손가락 스와이프가 인체공학적으로 최고지만, 안타깝게도 너무 틈새적인 혁신인 듯함
  • 새 스와이프 모델을 넣은 Futo는 내가 써본 Android 키보드 중 처음으로 GBoard 대비 타협한다는 느낌이 들지 않음
    통합 음성 입력, 좋은 자동 수정 타이핑, 좋은 자동 수정 스와이프를 갖췄음

  • 수정: 무료·오픈이 보장되는 것은 아님. 라이선스 구성이 헷갈림. 그래도 잘 작동하니 Gboard 대신 쓸 생각임
    이건 굉장히 큰 일임. 내가 보기에는 최초로 쓸 만한 무료 오픈 스와이프 모델에 가까움. iOS와 Android 외 플랫폼에서 스와이프 타이핑을 가능하게 하는 길을 열어주고, 새 운영체제 진입자들에게 큰 고통이던 부분을 줄여줌

  • 마침 Microsoft가 SwiftKey에 광고와 Bing으로 보내는 다크 패턴 리다이렉트를 넣기 시작해서 지웠는데, 타이밍이 좋음

    • 지웠다는 뜻이라면 나도 같은 이유로 그랬음
      백업 기능을 쓰라는 패널이 계속 다시 나타났고, 너무 심해서 결국 GBoard로 옮겼음. 같지는 않지만 익숙해지는 중임
    • 지웠다는 뜻 맞지? Microsoft 안에서 Bing 팀의 힘이 너무 센 건 안타까움. Bing의 영광과 돈을 위해 제품을 망가뜨림
      아마 돈 때문이겠지만, Microsoft가 하는 모든 일에서 큰돈을 벌어야만 하는 건 아니라고 느낌
  • 좋아 보이지만 Futo 키보드의 큰 문제는 한 번에 한 언어만 된다는 점임. gboard에서는 내가 쓰는 3개 언어를 계속 전환하지 않고도 스와이프 입력할 수 있음. Futo도 그렇게 만들었으면 좋겠음

  • 음성 받아쓰기는 지금까지 쓰던 GBoard보다 훨씬 좋음. 내가 신경 쓰지 않아도 문장 대문자화와 구두점을 처리하고, 여러 문장을 후편집 없이 완벽하게 맞췄으며 전부 로컬 모델로 돌아감
    단점은 실시간 갱신이 아니라 말을 끝낸 뒤 일괄 변환된다는 점임. 1~2년 전 마지막으로 써봤을 때처럼 백스페이스 스와이프와 스페이스바가 과민하지 않게 고쳐진 듯하고, 일부 커스터마이징도 가능해졌음