Questack 개발 일지 - 2026-06-01

작업 배경

Questack의 MVP 목표는 매일 백엔드 학습에 도움이 되는 기술 소재 3개를 선별하는 것이다.
그런데 수집 파이프라인이 아무리 잘 동작해도, 최종 Top 3에 프론트엔드 전용 글이나 하드웨어 중심 뉴스가 섞이면 서비스의 핵심 가치가 흔들린다.

그래서 어제 작업은 크게 두 가지였다.

1. Top 3 랭킹 결과가 백엔드 취업 준비에 적합한지 fixture로 검증하기
2. MVP Done Criteria에 맞춰 RSS 기술 블로그 소스를 최소 5개로 확장하기

관련 PR은 다음 두 개다.

• PR #19: test: lock ranking quality with labeled fixtures
• PR #20: feat: expand RSS sources to five feeds

구현한 기능

1. 랭킹 품질 fixture 추가

PR #19에서는 useful / not_useful 라벨이 붙은 수집 항목 fixture를 추가했다.

useful 항목에는 Spring AI/RAG, DB migration, Kafka retry처럼 백엔드 실무와 면접에 연결하기 좋은 주제를 넣었다.
반대로 not_useful 항목에는 frontend-only, hardware-heavy, business-only 성격의 소재를 넣었다.

핵심은 단순히 점수가 계산되는지만 보는 것이 아니라, 실제 Top 3 결과에 useful 항목만 올라오는지를 테스트로 고정한 것이다.

관련 파일:

• src/test/resources/fixtures/ranking/labeled-collected-items.json
• src/test/java/com/questack/ranking/service/RankingQualityFixtureTest.java
• docs/technical-decisions.md의 TD-019

2. RSS 소스를 5개로 확장

PR #20에서는 MVP 기준을 맞추기 위해 RSS/Atom 수집 대상을 5개로 늘렸다.

기존 소스:

• Spring Blog
• NAVER D2
• Kakao Tech

추가 소스:

• AWS News Blog
• InfoQ Software Engineering

AWS News Blog는 클라우드와 인프라 신호를 얻기 좋고, InfoQ Software Engineering은 아키텍처, DevOps, AI engineering 같은 넓은 백엔드 주제를 다룬다. 둘 다 RSS feed를 제공하기 때문에 기존 RSS 수집 파이프라인을 그대로 활용할 수 있었다.

관련 파일:

• src/main/resources/application.yaml
• src/test/java/com/questack/collection/rss/config/RssPropertiesTest.java
• docs/sources/source-candidates.md
• README.md
• docs/technical-decisions.md의 TD-020

트러블슈팅

이번 작업에서 가장 중요했던 문제는 “수집은 되는데 좋은 결과인지 어떻게 검증할 것인가”였다.

기존 테스트는 수집기나 랭킹 서비스가 동작하는지는 확인할 수 있었지만, Top 3가 실제로 백엔드 학습에 적합한지는 보장하지 못했다.
그래서 live 데이터에 의존하지 않고, 라벨이 붙은 fixture를 만들었다.

이 방식의 장점은 다음과 같다.

• GitHub/RSS live 데이터 변화에 영향을 받지 않는다.
• 프론트엔드, 하드웨어, 비즈니스 중심 소재가 상위에 올라오는 회귀를 빠르게 잡을 수 있다.
• 현재의 결정론적 키워드 랭킹 전략을 테스트로 설명할 수 있다.

RSS 소스 확장에서는 단순히 feed를 추가하는 것에서 끝내지 않고, 설정 테스트를 추가했다.
최소 5개 feed가 존재하는지, 각 feed가 명시적인 priority를 가지는지 검증해서 MVP 기준이 설정 변경 중에 깨지지 않도록 했다.

기술적 의사결정

TD-019: Top 3 랭킹 품질은 labeled fixture로 고정

랭킹 품질은 live 수집 결과가 아니라 라벨 fixture로 검증하기로 했다.

이유는 live 데이터가 계속 변하기 때문이다. 오늘은 좋은 결과가 나오더라도 내일은 다른 저장소나 글이 올라와 테스트가 흔들릴 수 있다.
MVP 단계에서는 랭킹 로직이 설명 가능하고 재현 가능해야 하므로, useful/not_useful fixture를 기준으로 품질 기대치를 고정했다.

TD-020: MVP RSS 소스를 5개 기술 블로그 feed로 확장

MVP Done Criteria에는 GitHub와 최소 5개 기술 블로그 source 수집이 포함되어 있다.
따라서 기존 3개 feed에 AWS News Blog와 InfoQ Software Engineering을 추가했다.

이 결정은 단순한 양적 확장이 아니라, Questack이 다루는 백엔드 학습 소재의 폭을 넓히는 작업이었다.
Spring/JVM 중심 소스에 클라우드, 인프라, 아키텍처 신호를 더해 일일 브리핑의 후보군을 더 다양하게 만들었다.

검증

두 PR 모두 다음 명령으로 검증했다.

./gradlew test

PR #19에서는 ranking quality fixture 테스트가 추가되었고, PR #20에서는 RSS 설정 테스트가 추가되었다.
즉, 이번 작업은 기능 추가뿐 아니라 “앞으로 이 기준이 깨지지 않도록 막는 테스트”를 함께 남긴 작업이었다.

관련 커밋 / PR 링크

• PR #19: test: lock ranking quality with labeled fixtures
  • 닫은 issue: #7
  • 커밋: test: lock ranking quality with labeled fixtures
• PR #20: feat: expand RSS sources to five feeds
  • 닫은 issue: #6
  • 커밋: feat: expand rss sources to five feeds

회고

이번 작업은 Questack의 “자동 수집 서비스”를 “학습에 쓸 수 있는 서비스”로 한 단계 좁혀가는 작업이었다.

수집량을 늘리는 것도 중요하지만, 결국 사용자가 보는 것은 Top 3 브리핑이다.
그래서 랭킹 품질을 fixture로 고정한 것이 특히 의미 있었다.

또 RSS 소스를 5개로 확장하면서 MVP Done Criteria에 더 가까워졌다. 이제 남은 과제는 수집과 랭킹의 결과를 포트폴리오 데모와 회고 자료로 설득력 있게 보여주는 것이다.