리텐션(Retention)이란? 개발자가 알아야 할 ‘사용자가 다시 돌아오는 이유’

서비스를 개발하다 보면 “리텐션을 높여야 한다”는 말을 듣게 된다. 처음에는 마케팅이나 서비스 기획에서 사용하는 용어처럼 느껴질 수 있다. 개발자는 기능을 구현하고, 오류를 수정하고, 서버가 안정적으로 동작하도록 만드는 일을 맡으니 리텐션과는 거리가 있다고 생각하기 쉽다.

하지만 사용자가 다시 찾아오는 이유를 살펴보면 개발과 맞닿아 있는 부분이 꽤 많다. 지난번에 작성하던 내용을 이어서 작업할 수 있는지, 원하는 정보를 빠르게 찾을 수 있는지, 저장 버튼을 눌렀을 때 데이터가 제대로 저장되는지와 같은 경험이 쌓여 사용자가 서비스를 계속 사용할지에 영향을 준다.

리텐션은 결국 우리가 만든 서비스가 사용자의 생활이나 업무에서 얼마나 지속적으로 쓰이고 있는지 살펴보는 개념이다.

리텐션의 뜻

리텐션은 영어로 ‘유지’ 또는 ‘보존’을 뜻한다. 웹이나 앱 서비스에서는 주로 사용자가 서비스를 이용한 뒤, 시간이 지나도 다시 돌아와 사용하는 정도를 의미한다. 우리말로는 사용자 유지율이라고 부르기도 한다.

예를 들어 어떤 학습 서비스에 오늘 100명이 처음 방문했다고 해보자. 다음 날 이 중 30명이 다시 방문했다면, 처음 방문한 사람들을 기준으로 다음 날의 리텐션은 30%라고 볼 수 있다.

여기서 중요한 것은 전체 방문자 수가 아니라 처음 이용했던 사용자 가운데 누가 다시 돌아왔는가이다. 다음 날 방문자가 200명으로 늘었더라도 모두 새로운 사용자라면, 전날 처음 방문했던 100명의 다음 날 리텐션은 0%일 수 있다.

따라서 신규 사용자 수와 리텐션은 서로 다른 질문에 답한다. 신규 사용자 수는 “얼마나 많은 사람이 새로 들어왔는가”를 보여주고, 리텐션은 “들어온 사람들이 이후에도 사용하고 있는가”를 보여준다.

물론 다시 방문했다는 사실만으로 서비스에 만족했다고 단정할 수는 없다. 필요한 정보를 찾지 못해 여러 번 접속했을 수도 있고, 오류 때문에 같은 작업을 반복했을 수도 있다. 리텐션은 지속적인 사용을 살펴보는 지표이며, 그 사용이 어떤 경험에서 비롯되었는지는 추가로 확인해야 한다.

개발자가 리텐션을 알아야 하는 이유

기능이 정상적으로 동작하는 것과 사용자가 그 기능을 계속 사용하는 것은 별개의 문제다.

가령 할 일 관리 서비스를 만들었다고 해보자. 회원가입, 로그인, 할 일 등록, 수정, 삭제까지 모두 구현했다. 테스트도 통과했고, 배포 후 서버 오류도 거의 없다. 개발 요구사항만 놓고 보면 완성된 서비스다.

그런데 사용자가 할 일을 등록한 뒤 다시 방문하지 않는다면 어떨까? 등록 과정이 번거로웠을 수도 있고, 다음 날 해야 할 일을 확인하기 어려웠을 수도 있다. 이미 사용하던 메모 앱보다 편리한 점을 발견하지 못했을 가능성도 있다.

이때 리텐션을 살펴보면 개발 이후의 질문이 달라진다. “할 일 등록 기능이 있는가?”에서 한 걸음 더 나아가, “할 일을 등록한 사용자가 다음 주에도 이 서비스를 사용하는가?”를 확인하게 된다.

이 차이는 기능의 우선순위를 정할 때도 중요하다. 새로운 메뉴를 추가하는 것보다 기존 작업을 쉽게 이어서 할 수 있도록 개선하는 편이 사용자에게 더 도움이 될 수 있다. 리텐션은 이런 판단을 위한 근거 중 하나가 된다.

리텐션은 어떻게 계산할까?

가장 기본적인 계산 방식은 다음과 같다. 여기서 기준 사용자 수는 분석을 시작하는 행동을 한 사용자 수이고, 다시 사용한 사용자 수는 정한 재사용 행동을 해당 시점에 수행한 사용자 수다.

리텐션(%) = 특정 시점에 다시 사용한 사용자 수 ÷ 기준 사용자 수 × 100

예를 들어 10월 1일에 처음 학습을 완료한 사용자가 100명이고, 그중 10월 8일에 다시 학습을 완료한 사용자가 25명이라면 해당 그룹의 D7 리텐션은 25%다. 여기서는 첫 학습 완료일을 D0으로 두고, 정확히 7일 뒤의 학습 완료 여부를 확인한다고 가정한다.

지표	확인하는 내용
D1 리텐션	첫 이용 후 1일 뒤에 다시 이용했는가
D7 리텐션	첫 이용 후 7일 뒤에 다시 이용했는가
D30 리텐션	첫 이용 후 30일 뒤에 다시 이용했는가

다만 ‘D7 리텐션’이라는 이름만으로 계산 기준이 완전히 정해지는 것은 아니다. 정확히 7일째 돌아온 사용자를 셀 수도 있고, 7일째부터 그 이후에 한 번이라도 돌아온 사용자를 셀 수도 있다. 분석 도구에서도 이런 방식을 구분한다. Amplitude는 이를 Return On과 Return On or After 등으로 나누어 설명한다.

예를 들어 어떤 사용자가 첫 이용 후 7일째에는 접속하지 않고 9일째에 돌아왔다면, 정확히 7일째의 사용을 보는 방식에서는 포함되지 않는다. 반면 7일째 이후의 재방문을 보는 방식에서는 포함될 수 있다.

날짜를 나누는 기준도 맞춰야 한다. 한국 시간의 달력 날짜로 비교할지, 첫 이용 시점부터 24시간 단위로 비교할지에 따라 결과가 달라질 수 있기 때문이다.

그래서 리텐션을 보고서에 적을 때는 숫자와 함께 기준을 남기는 편이 좋다. “D7 리텐션 25%”보다 “첫 학습 완료일을 기준으로, 한국 시간의 7일 뒤에 다시 학습을 완료한 사용자 비율 25%”가 훨씬 명확하다.

코호트와 함께 보면 더 잘 이해할 수 있다

리텐션을 분석할 때 자주 등장하는 용어가 코호트(Cohort)다. 코호트는 일정한 공통 조건을 가진 사용자 집단을 뜻한다. 같은 날 처음 방문한 사용자, 같은 주에 가입한 사용자, 특정 기능을 처음 사용한 사용자 등을 하나의 그룹으로 묶을 수 있다.

전체 사용자를 한꺼번에 보면 변화의 원인을 파악하기 어렵다. 서비스 이용 기간이 서로 다르고, 사용을 시작했을 때 경험한 화면이나 기능도 다를 수 있기 때문이다.

예를 들어 가입 절차를 개선했다면, 개선 전에 가입한 사용자와 개선 후에 가입한 사용자의 리텐션을 나누어 볼 수 있다. Google Analytics의 동질 집단 탐색 분석도 공통 조건을 가진 그룹의 행동을 시간에 따라 살펴보는 데 사용된다.

아래는 설명을 위한 가상 데이터다.

가입 그룹	가입자 수	D1 리텐션	D7 리텐션
가입 절차 개선 전	100명	30%	15%
가입 절차 개선 후	100명	42%	24%

이 결과를 보면 개선 후에 가입한 사용자들이 더 많이 돌아왔다는 사실은 확인할 수 있다. 다만 가입 절차 개선이 원인이라고 바로 결론 내리기는 어렵다. 같은 시기에 광고 채널이 바뀌었거나, 이벤트가 진행되었거나, 유입된 사용자의 특성이 달라졌을 수도 있다.

리텐션은 변화를 발견하는 데 도움이 된다. 그 변화가 특정 개발 작업의 효과인지 확인하려면 다른 조건도 함께 살펴봐야 한다.

무엇을 ‘다시 사용했다’고 볼 것인가?

리텐션을 측정할 때 가장 먼저 정해야 할 것은 재사용의 기준이다.

앱을 실행한 것만으로 사용했다고 볼 것인지, 로그인해야 하는지, 실제로 핵심 기능을 수행해야 하는지에 따라 수치의 의미가 달라진다.

학습 서비스라면 앱 실행보다 문제를 풀거나 학습을 완료한 행동이 더 중요할 수 있다. 운동 기록 서비스에서는 홈 화면을 보는 것과 운동 기록을 저장하는 것이 서로 다른 경험이다.

서비스	의미 있는 재사용 행동의 예
학습 서비스	문제 풀이 완료, 강의 학습 완료
운동 기록 서비스	운동 기록 저장
협업 서비스	문서 편집, 업무 상태 변경
쇼핑 서비스	상품 탐색, 구매
AI 문서 서비스	문서 분석 완료, 분석 결과 활용

어떤 행동을 선택할지는 분석 목적에 따라 달라진다. 사용자의 재방문 자체를 확인하려면 방문을 기준으로 삼을 수 있고, 서비스의 핵심 가치가 반복해서 사용되는지 보려면 주요 작업의 완료를 기준으로 삼을 수 있다.

예를 들어 AI 문서 서비스에서 로그인 리텐션은 높지만 문서 분석 완료 리텐션이 낮다면, 사용자는 돌아오고 있지만 실제 작업을 끝내는 과정에서 어려움을 겪고 있을 가능성이 있다. 이때는 분석 속도, 오류, 결과 품질, 사용량 제한 등을 살펴볼 수 있다.

개발에서 리텐션과 연결되는 부분

리텐션을 높이는 방법을 생각하면 푸시 알림이나 이메일부터 떠올리기 쉽다. 하지만 사용자가 다시 돌아왔을 때 편리하게 일을 할 수 있어야 반복 사용으로 이어질 가능성이 생긴다.

먼저 살펴볼 부분은 첫 사용 경험이다. 가입 직후 무엇을 해야 하는지 알기 어렵거나, 설정을 너무 많이 요구하거나, 아무 설명 없이 빈 화면만 보인다면 사용자는 서비스의 가치를 경험하기 전에 떠날 수 있다. 첫 작업을 안내하거나 예시 데이터를 제공하는 작은 개선이 도움이 될 수 있다.

작업을 이어서 할 수 있는 구조도 중요하다. 작성 중인 문서의 자동 저장, 최근 작업 목록, 마지막 학습 위치 복원, 이전 분석 결과 보관 등이 여기에 해당한다. 사용자가 돌아왔을 때 처음부터 다시 시작해야 한다면 반복 사용의 부담이 커진다.

성능과 안정성 역시 사용자 경험의 일부다. 페이지가 느리게 열리거나 저장 요청이 자주 실패하면 사용자는 서비스를 믿고 쓰기 어렵다. 특히 기록이나 업무를 다루는 서비스에서는 데이터가 제대로 남는다는 신뢰가 중요하다. 오류 메시지를 이해하기 쉽게 제공하고, 실패한 작업을 다시 시도할 수 있게 만드는 일도 개발자가 할 수 있는 개선이다.

알림은 이런 경험을 보완하는 수단으로 생각할 수 있다. 사용자가 설정한 학습 시간이나 마감일을 알려주는 알림에는 돌아올 이유가 있다. 반면 맥락 없이 반복되는 알림은 부담이 될 수 있다. 알림을 눌렀는지만 확인하기보다, 이후에 필요한 작업을 완료했는지도 살펴보는 편이 좋다.

어떤 기능이 리텐션을 개선할지는 서비스마다 다르다. 자동 저장이나 알림을 추가했다고 수치가 반드시 높아지는 것은 아니다. 사용자에게 실제로 도움이 되었는지 확인하는 과정이 함께 필요하다.

측정하려면 이벤트 설계가 필요하다

리텐션을 분석하려면 사용자의 행동을 기록할 수 있어야 한다. 여기서 이벤트는 회원가입 완료, 학습 완료, 운동 기록 저장처럼 분석하려는 행동을 뜻한다.

예를 들어 학습 서비스에서는 다음과 같이 이벤트를 구분할 수 있다.

이벤트 이름	기록하는 시점
signup_completed	회원가입이 성공했을 때
lesson_started	학습을 시작했을 때
lesson_completed	학습을 완료했을 때
review_completed	복습을 완료했을 때

앞에서 정한 재사용 행동을 분석하려면, 해당 행동이 실제로 일어났을 때 이벤트가 기록되도록 설계해야 한다.

이벤트 이름보다 중요한 것은 발생 조건을 일관되게 정하는 일이다. 예를 들어 저장 성공을 측정하려는 서비스에서는 저장 버튼을 누른 순간과 서버에 저장이 완료된 순간을 구분해야 한다. 버튼 클릭을 기록하면 실패한 요청까지 성공으로 해석할 수 있다.

기본적으로는 사용자 식별자, 이벤트 이름, 발생 시각이 필요하다. 앱 버전이나 유입 경로처럼 분석 목적에 필요한 정보도 추가할 수 있다. 같은 사용자를 중복 집계하지 않도록 해야 하고, 새로고침이나 요청 재시도로 이벤트가 여러 번 기록되는 경우도 고려해야 한다.

또한 관찰 기간이 충분히 지난 사용자만 비교해야 한다. 코호트 시작 시점에서 3일밖에 지나지 않은 사용자는 아직 D7 사용 여부를 판단할 수 없다. 이들을 미복귀 사용자로 처리하면 리텐션이 실제보다 낮게 계산될 수 있다.

이벤트 설계는 나중에 대시보드를 만들 때 시작하는 작업이 아니다. 기능을 개발할 때 “이 기능이 사용되는지 어떻게 확인할 것인가?”를 함께 생각하면, 이후 분석에 필요한 데이터를 훨씬 일관되게 남길 수 있다.

서비스의 사용 주기에 맞춰 해석해야 한다

리텐션은 높은 숫자 하나만으로 평가하기 어렵다. 서비스마다 자연스러운 사용 주기가 다르기 때문이다.

매일 사용하는 메신저나 학습 앱과, 여행을 준비할 때 사용하는 예약 서비스에 같은 기준을 적용하기는 어렵다. 한 달에 한 번 필요한 업무 도구라면 다음 날 돌아오지 않았다는 사실만으로 문제라고 보기 어렵다.

따라서 먼저 “사용자가 이 서비스를 얼마나 자주 필요로 하는가?”를 생각해야 한다. 매일 필요한 서비스라면 일 단위, 주간 업무를 지원한다면 주 단위, 월간 보고서를 작성하는 도구라면 월 단위의 반복 사용을 살펴볼 수 있다.

사용 시간이 길다고 항상 좋은 것도 아니다. 업무를 빨리 끝내도록 돕는 서비스라면 사용 시간이 줄어드는 것이 개선의 결과일 수 있다. 리텐션과 함께 작업 완료율, 오류율, 완료까지 걸린 시간 등을 확인하면 사용 경험을 더 균형 있게 이해할 수 있다.

데이터 리텐션과는 뜻이 다르다

개발 문서에서 ‘리텐션’은 사용자 유지율 외에 데이터 보존 기간을 뜻하기도 한다.

“로그 리텐션을 30일로 설정한다”는 말은 로그를 일정 기간 보관하도록 설정한다는 의미다. 사용자들이 30일 뒤에 다시 방문하는지를 말하는 것이 아니다.

표현	의미
사용자 리텐션	사용자가 시간이 지나도 다시 서비스를 이용하는 정도
데이터 리텐션	데이터를 얼마나 오래 보관할지에 대한 기준
로그 리텐션	로그의 보존 기간
백업 리텐션	백업의 보존 기간 또는 유지 정책

같은 단어라도 회의나 문서의 맥락에 따라 의미가 달라진다. “리텐션을 늘리자”는 말을 들었다면 사용자 유지율을 높이자는 것인지, 로그 보존 기간을 늘리자는 것인지 구분해야 한다.

마치며

서비스 개발에서 사용자 리텐션을 이해한다는 것은 기능 구현 이후의 사용까지 관심을 갖는다는 뜻이다. 사용자가 처음에 무엇을 경험했는지, 다시 돌아왔을 때 어떤 일을 했는지, 반복 사용을 어렵게 만드는 부분은 무엇인지 살펴보게 된다.

기능을 완성한 뒤 “잘 동작하는가?”를 확인하는 것은 기본이다. 여기에 “사용자가 다음에도 이 기능을 필요로 하고, 편하게 사용할 수 있는가?”라는 질문을 더하면 개발의 방향도 조금씩 달라진다. 리텐션은 그 질문을 실제 사용자 행동으로 확인하는 데 도움이 되는 개념이다.