실제 사용자를 받는 서비스를 만들면서 배운 것 (회고)

[그때 내린 판단]

학교 공지사항 알림 서비스를 만들었습니다. 50여 개 게시판을 크롤링해서 신규 공지를 푸시로 보내는 구조예요. 처음에는 제가 공지를 놓치는 게 싫어서 시작했습니다.

지금 지표는 이렇습니다.

항목	수치
누적 접속자	약 2,800명
가입자	466명
MAU	약 300명
최근 90일 푸시 발송	약 75,000건

메일 서비스도 하나 운영하고 있어요. 가입자 322명에 유료 구독을 붙였습니다. 실제로 결제가 일어나는 서비스입니다.

토이 프로젝트로 시작했는데 사용자가 생겼고, 그때부터 성격이 달라졌어요.

[지금 다시 보면]

사용자가 생기면 롤백할 수 없습니다

혼자 쓰는 코드는 언제든 갈아엎을 수 있어요. 스키마를 바꾸고 싶으면 DB를 지우고 다시 만들면 됩니다.

466명이 쓰기 시작하면 그게 안 돼요. 토큰이 저장돼 있고, 구독 설정이 쌓여 있고, 알림 이력이 남아 있습니다. 마이그레이션을 잘못 짜면 누군가는 알림을 못 받아요.

이 제약이 저를 가장 많이 바꿨다고 생각합니다. 코드를 짤 때 “이걸 나중에 어떻게 되돌리지”를 먼저 생각하게 됐어요. Outbox 테이블에 상태를 8단계로 나눈 것도, 발송 실패를 지우지 않고 PERMANENT_FAIL 로 남긴 것도 같은 이유입니다. 무슨 일이 있었는지 나중에 볼 수 있어야 했으니까요.

숫자를 보면 내 판단이 틀린 게 보입니다

누적 접속자 2,800명에 가입자 466명입니다. 전환율이 약 17%예요.

처음 이 숫자를 계산했을 때 좀 당황했습니다. 저는 서비스가 명확하다고 생각했거든요. 공지를 놓치기 싫으면 가입하면 되는 건데, 열 명 중 여덟 명이 안 하고 나갔어요.

가입자 466명 중 MAU가 300명인 것도 그렇습니다. 166명이 이탈했는데 저는 그 이유를 모릅니다. 물어본 적이 없어요.

이게 제가 놓치고 있던 부분이었습니다. 저는 지표를 성과를 증명하는 용도로만 봤어요. 466명, 75,000건 같은 숫자는 이력서에 쓰기 좋으니까요. 정작 그 숫자가 알려주는 문제는 안 봤습니다.

피드백은 기능이 아니라 전제를 바꿉니다

구독과 알림 수신을 분리한 적이 있습니다. 원래는 게시판을 구독하면 알림도 같이 받는 구조였어요. 저는 이게 당연하다고 생각했습니다. 알림을 받으려고 구독하는 거니까요.

그런데 사용자들은 달랐어요. 게시판은 보고 싶은데 알림은 안 받고 싶은 경우가 있었습니다. 제 머릿속에는 없던 조합이었어요.

기능을 추가한 게 아니라 제가 세운 전제가 틀렸다는 걸 알게 된 일이었습니다. 구독과 알림이 하나라고 묶어둔 건 사용자의 요구가 아니라 제 편의였어요.

[무엇이 달랐어야 했나]

가장 아쉬운 건 떠난 사람에게 물어보지 않은 것입니다.

이탈한 166명에게는 접근할 방법이 없어요. 탈퇴했거나 그냥 안 들어옵니다. 남아 있는 300명에게 물어보면 “잘 쓰고 있다”는 답만 돌아와요. 당연합니다. 문제가 없으니 남아 있는 거니까요.

이탈 시점에 이유를 물어보는 장치를 처음부터 넣었어야 했다고 생각합니다. 탈퇴 버튼 옆에 선택지 세 개만 있었어도 지금 저는 답을 알고 있었을 거예요.

두 번째는 전환율을 늦게 계산한 것입니다. 2,800과 466은 처음부터 있던 숫자였어요. 나누기 한 번이면 17%가 나옵니다. 그런데 저는 두 숫자를 각각 자랑거리로만 보고 있었고, 관계를 따져본 건 한참 뒤였습니다.

지표를 모으는 것과 지표를 읽는 것은 다른 일이었어요.

[남은 질문]

서비스를 어떻게 끝낼 것인가를 아직 정하지 못했습니다.

졸업이 2027년 2월입니다. 그 뒤로도 이 서비스를 운영할 수 있을지 모르겠어요. AWS 비용은 계속 나가고, 학교 게시판 구조가 바뀌면 크롤러도 고쳐야 합니다.

300명이 매달 쓰고 있는 서비스를 그냥 내리는 건 무책임하다고 생각해요. 그렇다고 무기한 운영할 수도 없습니다. 인수인계할 사람을 찾을지, 공지를 띄우고 정리할지, 아니면 다른 방법이 있을지 고민 중이에요.

만드는 것보다 끝내는 게 어렵다는 걸 예상 못 했습니다. 사용자가 없었으면 고민할 일도 아니었을 텐데, 466명이 생긴 순간부터 이건 제 마음대로 할 수 있는 프로젝트가 아니게 됐어요.

그래도 이 제약이 저를 더 나은 개발자로 만들었다고 생각합니다. 되돌릴 수 없는 상황에서 코드를 짜본 경험은 혼자 만드는 프로젝트로는 얻기 어려웠을 거예요.