'사기 정리앱' 소리 듣는 앱, 백엔드로 정직함 증명하기

유틸리티 앱을 만들다 보면 "이거 사기 아니냐"는 반응을 한 번쯤 마주쳐요. 계산기, 정리 도구처럼 흔한 카테고리일수록 더 그래요. 앱 자체가 나빠서가 아니라, 앞에선 무료라 해놓고 뒤에서 결제를 숨기거나 개인정보를 몰래 긁어가는 앱들이 그 카테고리 전체의 신뢰를 깎아놨거든요.

그래서 정직함은 화면의 문구가 아니라 백엔드 구조로 증명해야 한다고 생각해요. 말은 누구나 하지만, 서버가 어떻게 동작하는지는 재현할 수 있으니까요.

"로그인 없이"는 인증 테이블이 없다는 뜻

플랜씨(plan-c) 금융계산기는 로그인 0단계로 써요. 직접 만들어 보니 "로그인 없이"를 진짜로 지키는 가장 정직한 방법은, 유저·세션 테이블을 아예 두지 않는 거였어요. 계정 테이블이 0개면 유출될 개인정보도 없어요. "안전하게 보관합니다"라고 약속할 필요 자체가 사라지는 구조죠.

• ✓로그인 없이
• ✓무료 한도 서버 강제
• ✓최소 수집

무료 한도는 프론트가 아니라 서버가 강제

플랜엘(plan-l) 법령·판례 검색은 월 3건 무료예요. 이 3이라는 숫자를 프론트엔드에서만 세면 개발자 도구로 금방 우회돼요. 그래서 카운트는 서버측 결정론으로 둬야 해요. 요청이 올 때마다 서버가 사용량을 확인하고, 한도를 넘으면 응답 자체를 막는 방식이죠.

요청→서버 카운터 확인→한도 초과면 429→통과면 200

테스트해 보면 차이가 바로 보여요. 한도 안에서는 HTTP 200에 정상 데이터가 오고, 초과하면 429가 떨어져요. 프론트 표시만 바꾼 앱은 이 429가 안 나와요. 상태 코드 하나로 "말과 서버가 같은지"가 갈리는 거예요.

데이터를 안 판다는 건 애초에 덜 받는 것

돌려 보니, 안 파는 것보다 애초에 덜 받는 쪽이 훨씬 정직했어요. 필요 없는 필드는 스키마에서 빼고, 테이블 권한은 기본 허용이 아니라 명시적으로 회수해 두는 편이 안전해요. "우리는 데이터를 팔지 않아요"보다 "받지 않으니 팔 데이터가 없어요"가 검증하기 쉬운 문장이니까요.

이런 걸 몇 번 적용해 봤더니, 정직한 포지셔닝은 마케팅 회의보다 백엔드 설계 단계에서 대부분 결정되더라고요. 무료라고 쓰기 전에 결제 코드가 정말 없는지, 로그인 없이라고 쓰기 전에 유저 테이블이 정말 없는지 확인해 보는 순간, 문구가 약속이 아니라 사실이 돼요.

라이프케어로그의 작은 도구들을 만들면서 세운 기준도 결국 이거예요. 화면의 정직함은 서버의 정직함 위에서만 유지된다는 것. 흔한 카테고리일수록, 남는 신뢰는 결국 재현 가능한 동작에서 나오는 것 같아요.