네이버 부스트캠프 웹・모바일 10기 멤버십 20주차 회고

한 주를 어떻게 보냈나?

• 이번 한 주는 기술적인 고민을 많이 한 시간이었다. 단순히 기능을 빨리 만드는 것보다는, 왜 이 구조를 선택해야 하는지, 지금의 선택이 이후 작업에 어떤 영향을 줄지를 계속 생각하게 됐다.

• 구현을 하면서도 자주 멈춰서 구조를 다시 그려보고, 설계가 맞는 방향인지 스스로에게 질문하는 시간이 많았다.

• 그 덕분에 작업 속도는 빠르지 않았지만, 중간에 방향을 크게 수정하는 일은 줄어들었고, 한 번 결정한 선택에 대해서도 스스로 납득하면서 진행할 수 있었다.

RSS 크롤러 설계

• 이번 주에 내가 했던 작업 중에서 가장 기억에 남는건 RSS 크롤러 설계였다.

• RSS는 어떤 사이트에 새로운 콘텐츠가 올라왔을 때 해당 사이트에 방문하지 않고, RSS서비스를 통해 리더 한 곳에서 그 콘텐츠를 이용하기 위한 방법이다.

• 우리 서비스는 캠퍼들이 기술 블로그에 올리는 글들을 자체적으로 수집해서 보여줘야하는데, 이때 유용하게 사용할 수 있는 기술이 바로 이 RSS다.

• 국내에서 개발자들이 많이 사용하는 기술 블로그인 Tistory와 Velog를 우선적으로 수집할 수 있도록 크롤러를 설계했다.

RSS는 어떤 식으로 생겼나?

• 위 XML 데이터는 내 티스토리 블로그 RSS 피드의 일부이다.

• <channel> 태그 안에는 블로그 전체를 설명하는 메타데이터(블로그 제목, 링크, 설명 등)가 들어 있고, <item> 태그 하나하나가 각각의 게시글을 의미한다.

• 각  <item>에는 글의 제목(<title>), 원문 링크(<link>), 작성 날짜(<pubDate>), 요약 내용(<description>) 등이 포함되어 있다.

• 즉 RSS는 “게시글 목록 + 각 게시글의 최소한의 정보”를 XML 형태로 정리해둔 문서라고 볼 수 있다.

RSS 크롤러는 어떻게 동작하나?

• RSS 크롤러의 기본 알고리즘은 위 사진과 같다. 크게 피드 수집, 피드 파싱, DB 저장 단계를 가진다.

• 조금 더 구체적으로 크롤러의 작업 흐름을 적어보자면…
1. 스케줄러가 설정된 주기마다 실행된다.
2. 피드 목록을 조회한다.
3. 각 피드에 대해 XML 다운로드 → 구조화된 데이터로 변환 → 데이터베이스에 저장을 한다.

어떤 점이 어려웠나?

• 첫 번째로 고민했던 점은 역할 분리였다.

• 크롤러에 어떤 컴포넌트를 붙일지 미리 생각해두지 않으면, 코드가 금방 한 파일에 뒤엉켜버릴 것 같았다.

• 그래서 구현에 들어가기 앞서 네이버 부스트캠프에서 그동안 갈고 닦았던 설계 방식을 총 동원해서 구조를 먼저 잡아보았다.

• 피드를 다운로드하는 역할, RSS 포맷을 파싱하는 역할, 파싱된 데이터를 도메인 형태로 변환하는 역할을 최대한 분리하려고 했다.

• 이렇게 설계 문서를 쭉 작성한 뒤에 구현은 내가 직접하지 않고 AI의 Plan 모드를 활용해서 개발을 진행했다.

• 이렇게 하니 코드를 거의 손 대지 않고도 내가 원하는 퀄리티의 구조를 빠르게 만들 수 있었다.

• 물론 세부 로직이나 예외 처리는 직접 수정해야 하는 부분도 있었지만, 전체적인 뼈대는 처음 의도한 설계와 크게 다르지 않았다.

• 특히 역할이 명확하게 나뉜 상태에서 코드를 보니, 어디를 고쳐야 할지도 한눈에 들어왔다.

• 두 번째로는 RSS 포맷이 블로그마다 미묘하게 달라서, 모든 케이스를 한 번에 고려하기가 쉽지 않았다.

• 예를 들어서, 네이버 블로그는 <description>에 콘텐츠 HTML 전체가 들어오는 게 아니라 일부 요약된 내용만 전달하고 있었고,

• 깃허브 페이지의 경우 RSS 2.0이 아니라 Atom 포맷을 사용하고 있어 태그 구조 자체가 달랐다.

• 그래서 이번 주에는 성급하게 모든 포맷을 지원하려고 하기 보다 RSS를 먼저 처리하는 방향을 선택했다.

어떤 점을 더 개선해야 할까?

• 우선 가장 급한 것은 블로그 contents 정규화이다. RSS에서는 블로그 원문을 마크다운 형식이 아닌 HTML 형식으로 제공해주고 있다.

• 이로 인해 블로그 플랫폼마다 태그 구조나 스타일이 제각각이라 우리 서비스에서 그대로 사용하기에는 한계가 있었다.

• 그래서 다음 주에는 HTML을 마크다운이나 다른 포맷으로 변환할 수 있는 구조를 고민해볼 계획이다.

커서 기반 페이지네이션

• 페이지네이션 작업도 이번 주에 이루어졌다. 우리 서비스는 게시글 목록을 보여줄 때 무한 스크롤 방식을 사용하고 있다.

• 일반적으로 많이 사용하는 번호 기반 페이지네이션 대신, 마지막으로 조회한 게시글을 기준으로 다음 데이터를 가져오는 커서 기반 페이지네이션을 적용했다.

• 이 방식이 사용자가 스크롤을 빠르게 내리더라도 목록이 자연스럽게 이어지기 때문에 좋은 사용자 경험을 줄 수 있을 것 같다는 팀 내의 의견이 있었다.

무엇이 어려웠나?

• 처음에는 커서를 무엇을 기준으로 잡아야 할지부터 고민이 많았다.

• 단순히 id만으로 커서를 구성하면 정렬 기준이 바뀌는 경우(최신순, 좋아요순 등)에 일관성을 보장하기 어렵다고 판단했다.

• 그래서 게시글 목록에서 실제로 사용하고 있는 정렬 기준과 동일한 컬럼을 커서에 포함시키는 방향으로 접근했다.

• 예를 들어 좋아요순 정렬의 경우 (likeCount, id)를 묶은 복합 커서를 사용했고, 최신순 정렬에서는 (publishedAt, id)를 기준으로 커서를 구성했다.

• 이때 정렬 순서와 커서 조건이 정확히 일치하지 않으면 데이터가 중복되거나 누락되는 문제가 발생할 수 있어, 쿼리 조건을 맞추는 데 특히 신경을 많이 썼다.

내가 알고 있는 지식을 응용해서 성능 개선하기

• 페이지네이션 쿼리문을 작성하면서 데이터베이스 인덱스도 함께 고려해야 효율적이겠구나 하는 생각이 들었다.

• 특히 커서 기반 페이지네이션은 ORDER BY와 WHERE 조건이 맞물려 동작하기 때문에, 인덱스가 없으면 조회 성능이 급격히 떨어질 것 같았다.

• 그래서 실제로 사용하고 있는 정렬 기준에 맞춰 복합 인덱스를 추가했다.

• 예를 들어 좋아요순 정렬에서는 (likeCount, id)를, 최신순 정렬에서는 (publishedAt, id) 형태의 인덱스를 구성했다.

• 이를 통해 full scan을 피하고, index range scan을 통해 빠르게 다음 데이터를 조회하게 했다.

• 인프런에서 들었던 김영한님의 강의와 호눅스님의 DB 강의가 빛을 발하는 순간이었다. 👍🏻

데모 발표

• 이번 주에는 기능 구현과 더불어서 백엔드 파트 발표도 진행하게 됐다.

• 처음에는 Tom에게 발표 제안을 받았을 때 “잘할 수 있을까?” 걱정이 됐지만, 이번 주에 백엔드 파트에서 진행됐던 내용들을 전반적으로 잘 이해했다는 생각이 들어서 발표를 해보겠다고 했다.

• 단순히 내가 맡은 기능만 설명하는 게 아니라, 왜 이런 구조를 선택했는지와 어떤 고민들이 있었는지를 함께 전달하려고 했다.

• 발표를 준비하면서 자연스럽게 이번 주 작업들을 한 번 더 정리할 수 있었고, 그 과정 자체도 꽤 의미 있었다.

아쉬웠던 점은?

• 발표는 잘했다고 생각하지만 ‘데모’보다는 ‘설명 중심의 발표’에 가까웠다는 아쉬움이 남았다.

• 다른 데모 조들은 배포 사이트를 먼저 공유해주고 “한번 써보세요!” 하며 사용자 입장에서 서비스를 먼저 경험하게 했다.

• 반면 나는 구현 과정을 설명하는 데 더 집중하다 보니, 보는 사람 입장에서 “그래서 이게 어떤 경험을 주는 서비스인지”가 덜 와닿았을 수도 있겠다는 생각이 들었다.

• 그래서 다음에는 기술적인 발표보다도 사용자들에게 우리 서비스가 어떻게 느껴지는지, 어떤 문제를 어떻게 해결해주는지를 먼저 보여주는 데 더 집중해보고 싶다.

• 그 위에 필요한 기술적인 설명을 얹는 방식으로 데모를 구성해보면 훨씬 전달력이 좋아질 것 같다는 생각이 들었다.

마무리 하며…

• 이제 남은 개발 기간은 1주, 리팩토링 기간까지 포함하면 총 2주가 남았다.

• 우리 팀이 남아 있는 모든 기능들을 개발할 수 없다면, 욕심내서 전부 만들기보다는 지금까지 만든 기능들의 완성도를 높이는 선택을 해야 한다고 생각했다.

• 그리고 우리 서비스가 부스트캠퍼들을 위한 커뮤니티 서비스인 만큼, 다른 캠퍼들에게도 이 서비스를 알리고 실제로 써보게 해야 할 필요성을 느꼈다.

• 우리 팀만 만족하는 서비스가 아니라, 다른 캠퍼들이 들어와 글을 보고, 탐색하고, 다시 찾게 되는 경험까지 만들어봐야 진짜 검증이 된다고 생각한다.

• 남은 기간 동안은 기능 구현과 함께, 어떤 흐름으로 서비스를 소개해야 부담 없이 처음 써볼 수 있을지, 그리고 한 번 들어온 사용자가 다시 돌아오게 만들 수 있을지까지 고민해보려고 한다.