Eunice · StewardAI
· 15분 읽기
- #교육
- #AI
- #제품분석
Anki FSRS: 당신이 무엇을 잊을지 알고리즘이 정하는 법
Anki는 무료 플래시카드 소프트웨어지만, 진짜 제품은 FSRS입니다 — 카드를 언제 잊어버릴지 예측해서 그에 맞춰 복습 일정을 짜는 오픈소스 알고리즘입니다.
Anki는 이 블로그에서 가장 재미없어 보이는 앱입니다 — 무료 오픈소스 플래시카드 프로그램인데, UI는 몇 년째 리디자인 근처에도 가지 않았습니다. 하지만 그건 잘못된 곳을 보고 있는 겁니다. 진짜 제품은 플래시카드가 아니라, 카드 한 장 한 장마다 "이 카드를 정확히 언제 잊어버릴 가능성이 가장 높은가"를 판단하는 스케줄러입니다. 이 스케줄링 알고리즘의 이름이 **FSRS(Free Spaced Repetition Scheduler)**이고, 이게 바로 Anki를 어깨 으쓱하고 넘길 게 아니라 뜯어봐야 할 이유입니다.
오래된 아이디어: 모든 뇌에 하나의 공식
간격 반복(spaced repetition) 자체는 새로운 개념이 아닙니다 — 하루 뒤도 아니고 한 달 뒤도 아니라, 잊어버리기 직전에 딱 맞춰 복습하면 더 오래 기억한다는, 수십 년 된 통찰입니다. Anki의 공식 매뉴얼은 오랫동안 기본으로 탑재해온 알고리즘인 SuperMemo 2(SM-2)를 "Anki의 레거시(legacy)" 스케줄러라고 부릅니다. SM-2는 고정된 공식입니다. 카드를 맞히면 간격이 정해진 배수만큼 늘어나고, 틀리면 간격이 리셋됩니다. 당신에 대해서는 아무것도 모릅니다 — 쉬운 단어 하나와 지독한 유기화학 반응 메커니즘에 똑같은 배수를 적용합니다.
이 글이 실제로 다루는 오래된 문제가 바로 이겁니다. 서로 다른 수백만 개의 기억을 하드코딩된 공식 하나로 뭉뚱그려 처리한다는 것.
FSRS 알고리즘의 작동 방식: 하나의 공식 대신 세 개의 숫자
FSRS는 고정된 공식을 세 가지 변수를 중심으로 만든 작은 예측 모델로 대체합니다. 알고리즘 자체의 GitHub 문서에는 이렇게 나와 있습니다.
- Difficulty(난이도) — "암기할 자료가 복잡할수록 stability 증가폭은 낮아진다."(the more complex the memorized material, the lower the stability increase.)
- Stability(안정도) — "기억의 저장 강도. 높을수록 더 천천히 잊는다."(the storage strength of memory; the higher it is, the slower it is forgotten.)
- Retrievability(인출 가능성) — "기억의 인출 강도. 낮을수록 잊어버릴 확률이 높다."(memory's retrieval strength; the lower it is, the higher the probability that the memory will be forgotten.)
카드마다 배수 하나를 적용하는 대신, FSRS는 이 세 숫자를 카드마다, 사용자마다 계속 갱신하면서 추정치를 유지하고, 이를 이용해 감쇠 곡선(decay curve) — 말 그대로 미래의 어느 날에도 그 카드를 여전히 기억하고 있을 확률 — 을 예측합니다. py-fsrs 패키지는 이걸 직접 노출합니다. scheduler.get_card_retrievability(card)를 호출하면 지금 이 순간 그 카드를 기억해낼 확률에 대한 모델의 현재 추정치를 돌려받을 수 있습니다.
실제로 만지는 다이얼은 딱 하나: desired retention
Anki는 difficulty, stability, retrievability를 이해하라고 요구하지 않습니다. 대신 숫자 하나만 설정하라고 합니다. 바로 **desired retention(목표 기억 유지율)**입니다. 공식 매뉴얼에 따르면 이건 "FSRS에서 가장 중요한 설정"(the most important setting in FSRS)이고, 이름 그대로 작동합니다 — 90%로 설정하면 FSRS는 "다음에 그 카드가 다시 복습 대상으로 나올 때 90%의 확률로 기억하고 있도록 카드를 스케줄링"(will schedule cards so you have a 90% chance of remembering them when they come up for review again)합니다. 이 다이얼을 올리면 복습이 더 잦아지고, 내리면 다음 테스트까지 카드 간 간격이 더 멀어집니다.
매뉴얼은 이 다이얼이 어디서 무너지는지 놀랍도록 솔직하게 밝힙니다. "90%를 넘어가면 작업량이 매우 빠르게 늘어나고, 97%를 넘어가면 작업량이 감당하기 어려워질 수 있다."(Above 90% the workload increases very quickly, and above 97% the workload can be overwhelming.) 이건 이 알고리즘이 단순한 다이얼이 아니라 UX 절벽(cliff)을 갖고 있다는, 출처가 명확한 진짜 인정입니다 — 거의 완벽한 기억을 쫓다 보면 100%에 도달하기 훨씬 전에 복습량에 파묻히게 됩니다.
이 하나의 트레이드오프가 바로 다른 곳에도 옮겨 쓸 수 있는 아이디어이고, 습관 앱에서 손실 회피가 스트릭 카운팅을 이기는 이유의 배경과 같습니다. 좋은 스케줄링 메커니즘은 자신의 정밀도가 요구하는 대가를 숨기지 않고, 그 대가를 올리거나 내릴 수 있는 숫자 하나로 눈에 보이게 만듭니다.
모델의 파라미터는 실제로 어디서 오는가
FSRS는 모두에게 똑같은 고정 가중치 세트를 배포하지 않습니다. fsrs4anki 프로젝트 — Anki 코어 팀이 아니라 open-spaced-repetition 조직이 관리합니다 — 는 "머신러닝을 이용해 당신의 기억 패턴을 학습하고 복습 기록에 가장 잘 맞는 파라미터를 찾아내는"(uses machine learning to learn your memory patterns and finds parameters that best fit your review history) 별도의 "옵티마이저(optimizer)"를 설명합니다. py-fsrs에 따르면 이 모델은 이런 가중치 21개로 돌아갑니다.
함정은 이겁니다. 이 옵티마이저가 뭐라도 쓸모 있는 일을 하려면 당신의 복습 기록이 필요합니다. 복습 로그가 전혀 없는 갓 만든 덱은 개인화된 모델이 아니라 범용 기본 파라미터를 받습니다 — 개인화는 설치할 때 켜지는 스위치가 아니라, 몇 주에 걸친 복습으로 얻어내는 것입니다.
프로젝트 자체 연구 그룹은 이 접근법을 대규모로 테스트했습니다. srs-benchmark 저장소는 평가 데이터셋이 "Anki를 사용하는 1만 명의 사용자"(10 thousand users who use Anki)로부터 나왔고, 전체적으로 "약 7억 2,700만 건의 플래시카드 복습"("~727 million reviews of flashcards")을 담고 있다고 밝힙니다. 큰 숫자이긴 하지만, 이건 FSRS를 만들고 유지보수하는 바로 그 조직이 직접 밝힌 수치입니다 — 독립적인 감사가 아닙니다 — 그러니 중립적인 제3자 측정치가 아니라 프로젝트 스스로 밝힌 테스트베드 설명으로 받아들여야 합니다.
여전히 활발히 유지보수 중이고, 2026년다운 툴링까지 받아들이는 중
Anki는 방치된 학술 프로젝트가 아닙니다. 메인 저장소는 스타 30.2k개, 포크 3.2k개를 갖고 있고, 최신 태그 릴리스는 26.08.1로 2026년 8월 5일자입니다. 데스크톱 클라이언트는 AGPL-3.0 라이선스를 따릅니다 — 무료이고, 이 저장소를 포크하는 누구든 법적으로 계속 무료로 유지해야 합니다.
안드로이드 클라이언트인 AnkiDroid는 별도의 GPL-3.0 프로젝트로 자체 스타 11.7k개를 갖고 있고, Google Play에서 무료로 받을 수 있으며, 99개 언어를 지원하는 번역가가 1,400명 넘게 참여하고 있다고 밝힙니다.
AI 툴링 블로그를 읽는 사람이라면 눈여겨볼 만한 작고 구체적인 디테일이 하나 있습니다. Anki 저장소 루트에는 자체 CLAUDE.md가 있는데, AI 코딩 에이전트를 위해 쓰인 빌드·테스트 치트시트입니다 — ./ninja나 ./run을 직접 호출하지 말고 프로젝트의 just 레시피를 통해서만 모든 걸 실행하라고 지시합니다. 스타 30k개, 10년 넘은 오픈소스 프로젝트가 이제 사람을 위한 온보딩 문서를 쓰던 것과 똑같은 방식으로 AI 에이전트를 위한 온보딩 문서를 쓰고 있는 겁니다.
기본 스케줄러 자리를 둘러싼 논쟁은 아직 끝나지 않았다
FSRS가 하룻밤 사이에 Anki에 접붙여진 것도 아니고, SM-2를 완전히, 확정적으로 대체한 것도 아직 아닙니다. 커밋 히스토리를 보면 FSRS 옵티마이저가 코드베이스에 처음 통합된 건 2023년 9월 5일입니다. 1년도 더 지난 뒤, Anki의 리드 메인테이너는 "Make FSRS the default?"라는 제목의 이슈 #3616을 열고 2024년 12월 6일 이렇게 썼습니다. "다음번 사소하지 않은(24.11.x가 아닌) 업데이트에서, 이제 FSRS를 기본값으로 켜도 될 때가 된 것 같습니다. 반대하시는 분 있나요?"(In the next non-trivial (not 24.11.x) update, I think it's about time we enable FSRS out of the box. Any objections?) 이 글을 확인한 시점 기준으로 그 이슈는 여전히 열려 있었습니다 — 이것 자체가 작은 데이터 포인트입니다. 더 나은 알고리즘을 만든 팀조차 기본값을 바꾸는 걸 사소한 결정으로 취급하지 않았고, 매뉴얼은 지금도 SM-2를 삭제하는 대신 "레거시"라고 설명해야 하는 상황입니다.
매뉴얼은 이 추가된 정밀도가 치르는 두 번째 대가도 살짝 흘립니다. 굵은 글씨로 "파라미터를 직접 바꾸거나 다른 사람 것을 복사해서 쓰지 마세요"(Do not change the parameters manually or copy them from someone else)라고 경고하는데, 이런 경고는 사람들이 실제로 그렇게 계속해왔을 때만 의미가 있습니다 — 이해도 못 하는 가중치를 잘못 건드려서 자기 스케줄을 망가뜨리는 일 말입니다.
이게 일반화되면 어떤 이야기가 될까요
여기서 다른 곳에 옮겨 쓸 수 있는 아이디어는 "스케줄링 로직에 머신러닝을 얹자"가 아닙니다. 더 좁고 더 쓸모 있는 아이디어입니다. Anki는 알고리즘이 예측하는 것(카드별·사용자별 망각 곡선)과 사용자가 통제하는 것(기억 유지율 숫자 하나)을 분리했고, 어려운 부분 — 가중치 21개를 당신의 구체적인 복습 기록에 맞춰 피팅하는 일 — 은 필수 설정 단계가 아니라 선택적 옵티마이저로 백그라운드에서 돌아가게 놔뒀습니다. 이는 AI 페어 프로그래머가 딱 떨어지는 숫자 하나만 던지는 대신, 반증 가능한 방법으로 자기 코드베이스를 실제로 얼마나 직접 작성했는지 측정하는 것과 같은 원칙입니다. 정말 중요한 레버 하나만 드러내고, 나머지를 뒷받침하는 방법론은 공개하고, 더 세밀한 통제를 원하는 사람이 알아서 찾아가게 두는 것입니다.
사용자 행동을 예측해야 하는 무언가를 만들고 있다면 — 이탈, 습관 붕괴, 무엇이든 간격을 두고 반복되는 것 — Anki/FSRS의 이 분리 구조는 훔쳐 갈 만한 패턴입니다. 모두를 위한 정직한 다이얼 하나, 그리고 그 뒤에서 조용히 수학을 처리하는 진짜 모델.
출처
아래 링크는 발행 전 직접 확인했습니다.
- 1.GitHub — ankitects/anki (메인 저장소) · 확인일
- 2.GitHub — Anki README (raw) · 확인일
- 3.GitHub — Anki 최신 릴리스 (26.08.1, 2026년 8월 5일) · 확인일
- 4.GitHub — Anki LICENSE (raw, AGPL-3.0) · 확인일
- 5.GitHub — Anki 저장소 파일 트리 (main 브랜치) · 확인일
- 6.GitHub — Anki CLAUDE.md (raw, AI 에이전트용 빌드 안내) · 확인일
- 7.GitHub — Anki blame: rslib/src/scheduler/fsrs/mod.rs (FSRS 통합 커밋) · 확인일
- 8.GitHub — Anki 이슈 #3616, "Make FSRS the default?" · 확인일
- 9.GitHub — ankitects 조직(organization) 페이지 · 확인일
- 10.GitHub — ankidroid/Anki-Android (메인 저장소) · 확인일
- 11.GitHub — open-spaced-repetition 조직(organization) 페이지 · 확인일
- 12.GitHub — fsrs4anki README (raw) · 확인일
- 13.GitHub — free-spaced-repetition-scheduler README (raw, DSR 모델) · 확인일
- 14.GitHub — py-fsrs README (raw) · 확인일
- 15.GitHub — srs-benchmark README (raw, 데이터셋 통계) · 확인일
- 16.GitHub — ankitects/anki-manual, deck-options.md (raw, FSRS vs SM-2) · 확인일