11개 Phase에 걸쳐 만든 뉴스 기능을 삭제했습니다
주식도 떨어질 때 파는 게 가장 어렵고, 서비스 개발도 만들어 놓고 삭제하는 게 어렵습니다.
오늘 FullStackFamily에서 "뉴스" 기능을 삭제했습니다. Phase 15부터 77까지 총 11개 Phase, 두 달 넘게 만든 기능입니다. 지우는 데는 반나절이면 됩니다.
뉴스 기능이 뭐였나
개발자들이 기술 뉴스를 일일이 찾아다니지 않아도 되게 하자는 아이디어였습니다.
RSS 수집 → AI 분석(적합성 70점 이상) → 번역 → 카테고리 분류 → 사이트에 게시
해외 기술 블로그의 RSS를 긁어와서, OpenAI API로 적합성을 평가하고, 점수가 높은 글만 자동 번역해서 올리는 구조입니다. 에디터 픽, 카테고리별 필터링, 검색, 댓글까지 전부 갖추고 있었고요.
Phase 15 뉴스 큐레이션 시스템 (RSS 수집, AI 분석, 자동 게시) Phase 20 대표글 모음, 빈 카테고리 숨김 Phase 21 뉴스 검색 기능 Phase 27 성능 최적화 (TBT 개선, 이미지 최적화) Phase 29 시간대 버그, URL 중복 방지 Phase 31 뉴스 본문 가져오기 (Playwright 헤드리스 브라우저) Phase 33 Playwright를 별도 Cloud Run 서비스로 분리 Phase 40 AI 카테고리 자동 분류 Phase 46 뉴스 검색 강화 Phase 55 네비게이션 리디자인 Phase 77 통합 게시판(UnifiedPost)으로 데이터 마이그레이션
JS로 렌더링되는 사이트의 본문을 가져오려고 Playwright까지 붙였는데, 메모리를 너무 잡아먹어서 Cloud Run 별도 서비스로 분리했습니다. 5,673건의 뉴스 데이터를 통합 게시판으로 옮기면서 기존 URL 호환성도 유지했고요. RSS 파서, AI 분석 파이프라인, 헤드리스 브라우저 크롤링, Cloud Run 배포. 기술적으로 재미있는 문제가 계속 나왔고, 하나씩 풀어가는 과정이 좋았습니다.
왜 삭제했나
GA를 열어보면 답이 나옵니다. 뉴스 페이지 방문은 있는데, 거기서 다른 페이지로 넘어가는 비율이 낮아요. 뉴스 보러 왔다가 뉴스만 보고 나갑니다. 수업이나 Q&A, 블로그 같은 핵심 기능과 연결이 안 됐습니다. 뉴스가 커뮤니티 활동의 입구가 되길 바랐는데, 실제로는 독립된 섬이었습니다.
번역 품질도 문제였습니다. 비용 때문에 GPT-3.5 수준의 저렴한 모델을 썼거든요. "shallow copy"를 "얕은 복사"로 옮기는 건 쉽지만, 문맥에 맞게 자연스러운 한국어로 만드는 건 다른 문제입니다. 원문을 직접 읽는 게 나은 수준의 번역이 올라왔습니다. 비싼 모델을 쓰면 나아지겠지만, 그러면 수집량을 줄여야 하고. 어느 쪽이든 매력이 떨어집니다.
그리고 솔직히 가장 큰 건, 긱뉴스가 있다는 겁니다. 한국 개발자 기술 뉴스 큐레이션은 긱뉴스(GeekNews)가 이미 잘 하고 있습니다. 사람이 직접 올리고, 투표하고, 댓글 다는 구조라 AI 자동 번역이 이길 수가 없어요. 같은 판에서 싸울 이유가 없었습니다.
삭제는 어떻게 했나
기능을 지울 때 가장 고민되는 건 "나중에 다시 쓸 일은 없을까"입니다. 고민했는데, 다 지우기로 했습니다. 코드도 데이터도.
프론트엔드 메뉴/홈페이지 뉴스 섹션, features/news/ 전체 백엔드 modules/news/ 전체, 뉴스 관련 엔티티/서비스/컨트롤러 DB unified_post_news, news_domain_rules 등 관련 테이블 인프라 ff-playwright Cloud Run 서비스, GCP 리소스 스케줄러 RSS 자동 수집 비활성화
미련을 남기면 코드베이스가 지저분해집니다. 안 쓰는 코드가 있으면 거기에 의존하는 다른 코드도 못 지우고, 테스트도 돌아가야 하고, 리팩토링할 때마다 신경 써야 하고. 필요하면 git 히스토리에서 꺼내면 됩니다.
월 비용도 OpenAI API $3-5, Cloud Run $2-3 정도 나가고 있었는데, 금액이 작다고 해서 가치 없는 비용을 계속 내고 있을 필요는 없습니다.
지우면서 든 생각
근데 그 재미가 사용자한테도 가치가 있었느냐 하면, 아니었습니다.
만드는 건 재밌었어요. 진짜로. Phase 하나 끝날 때마다 뭔가 나아지는 느낌이 있었고, 문제가 생기면 또 풀어야 하니까 다음 Phase로 자연스럽게 이어졌습니다. Playwright 메모리 문제를 Cloud Run 분리로 해결했을 때는 꽤 뿌듯하기도 했고요.
그런데 돌이켜보면 그건 "이 기능이 필요한가?"가 아니라 "이 기술 문제를 어떻게 풀까?"에 빠져 있었던 겁니다. 기술적 흥미가 제품 판단을 흐리게 한 거죠.
가설을 세우고, 만들고, 측정하고, 안 되면 파기하고 나아가는 게 서비스입니다. 스타트업을 운영하는 건 아니지만, 서비스의 발전은 그래야 한다고 생각합니다. 그래서 내가 잘하는 부분을 먼저 하자는 결론을 냈습니다. 뉴스 큐레이션보다는 수업 콘텐츠와 커뮤니티.
두 달간 배운 건 남아있고, 코드도 남아있습니다. 다만 지금 이 서비스에 뉴스는 필요 없었을 뿐입니다.
댓글
댓글을 작성하려면 이 필요합니다.