별 헤는 밤을 운영하며 배운 것 — 결국 Simple is Best
사이드 프로젝트로 별 헤는 밤이라는 커뮤니티 사이트를 배포하고 운영하면서, 기능을 만들고 고치고 다시 걷어내는 과정을 꽤 오래 겪었다.
그중에서도 가장 기억에 남는 건 날씨 캐싱 설계와 회원 탈퇴 처리였다.
지금 돌아보면, 정말 많은 시간을 쏟았는데 결과적으로는
“굳이 이렇게까지 했어야 했나?”라는 생각이 든다.
좌표 기반 온디맨드 날씨 캐싱 — 이상과 현실의 괴리
별 헤는 밤은 접속자의 좌표를 기준으로 도시를 판단하고,
그 도시의 날씨를 수집해 별 관측에 적합한지 알려주는 서비스였다.
제공하던 정보는 다음과 같았다.
- 구름량
- 날씨 상태
- 이를 기반으로 계산한 시정
- 오늘 별 관측 가능 상태 (Excellent ~ Bad)
처음에는 서버 비용과 성능을 모두 잡고 싶어서
온디맨드 방식의 캐싱 구조로 구현했다.
처음 설계
- 사용자가 접속
- 좌표 → 도시 판별
- 해당 도시 날씨 수집
- 15분 캐싱
- 이후 동일 도시 요청은 캐시 제공
이론상으로는 꽤 그럴듯했다.
“필요한 도시만 수집하니까 효율적이겠지”라는 생각이었다.
현실
- 구현이 생각보다 복잡해짐
- 좌표 기반 도시 판별 + 캐시 키 관리가 까다로움
- 사이트 특성상 트래픽이 많지 않음
- 결과적으로 캐시 히트율이 매우 낮음
정리하면,
복잡도는 높은데, 얻는 이득은 거의 없는 구조
였다.
단순화 이후 — 성능도, 비용도 더 좋아졌다
결국 구조를 단순하게 바꿨다.
변경 후 설계
- 주요 도시 기준
- 30분 간격으로 정기 수집
- 모든 사용자에게 동일 데이터 제공
결과는 의외로 훨씬 좋았다.
- 구현이 단순해짐
- 캐시 구조가 명확해짐
- 서버 비용 감소
- 성능 안정
- 운영 난이도 하락
“온디맨드”라는 말에 너무 끌렸지,
이 프로젝트에 정말 필요한 구조인지는 깊게 고민하지 않았던 것 같다.
탈퇴 처리 — 왜 이렇게 나눴는지 기억도 안 난다
회원 탈퇴 처리도 비슷한 시행착오를 겪었다.
초기 구현은 다음과 같았다.
- 일반 회원: 탈퇴 시 즉시 탈퇴
- 소셜 로그인 회원:
- 탈퇴 후 1개월 이내 로그인 시 복구 가능
지금 와서 보면,
왜 이렇게 나눴는지 스스로도 설명을 못 하겠다.
아마도 “서비스답게 만들어야 한다”는 강박이 있었던 것 같다.
사실은 더 단순하게 구현할 수 있었다.
- 모든 회원 동일한 정책 적용
- 탈퇴 후 1개월 이내 로그인 시 복구
- 1년 경과 시 완전 삭제
이 정도면 충분했고,
유저 경험도 더 일관됐을 것이다.
진짜로 배운 점
이 프로젝트에서 얻은 가장 큰 교훈은 기술 그 자체가 아니었다.
- 더 복잡한 구조가
- 더 멋진 설계가
- 더 정교한 아키텍처가
항상 더 좋은 결과를 주는 건 아니었다.
특히 사이드 프로젝트나 작은 서비스일수록 더 그렇다.
Simple is Best.
트레이드오프를 고려해서
“지금 이 프로젝트에 정말 필요한가?”를 기준으로 선택해야 한다.
괜히 의미 없는 복잡함에 시간을 쓰기보다는,
단순하고 명확한 구조로 빠르게 검증하고 운영하는 게 훨씬 낫다.
마무리
돌이켜보면 진짜 개고생이었다.
그런데 이상하게도, 그 고생이 헛되다고만은 느껴지지 않는다.
이제는 안다.
- 무엇을 만들지보다
- 무엇을 만들지 말아야 하는지가 더 중요하다는 걸.
다음 프로젝트에서는
조금 덜 고생하고,
조금 더 현명한 선택을 할 수 있을 것 같다.
