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

이번 한 주를 어떻게 보냈나?

• 이번 한 주는 캠퍼들이 우리 서비스를 실제로 사용해 보고, 피드백을 줄 수 있는 수준까지 끌어올리기 위해 개발에 집중하느라 바쁘게 보냈다.

• 사용자의 입장에서 생각하며 개발을 진행하다 보니 팀원들과 기능의 필요성, 사용 흐름, 우선순위에 대해 자연스럽게 많은 대화를 나누게 되었다.

• 이 과정에서 각자 바라보는 관점이 다르다는 것을 느꼈고, 그 차이를 조율하면서 더 나은 서비스를 만들어가는 경험을 할 수 있었다.

JWT 기반 인증 로직 구현

• 이번 주에 내가 했던 작업 중에서 가장 기억에 남는건 JWT 기반 인증 로직 구현이었다.

• 지난 학습 스프린트에서 고민했던 내용들을 바탕으로, 실제 서비스에 적용 가능한 형태로 인증 로직을 설계하고 구현해볼 수 있었다.

리프레시 토큰을 사용하는게 좋을까?

• 가장 고민이었던건 리프레시 토큰을 사용할지 말지였다.

• 구현해야 할 기능들이 많은 남은 시점이었고, 리프레시 토큰을 도입하면 토큰 저장 방식, 재발급 로직, 탈취 대응 등 고려해야 할 요소가 많아질 것이라고 생각했다.

• 그래서 액세스 토큰만 사용하는게 어떨지 고민하던 찰나에, Jack이 시간이 조금 더 걸리더라도 완성도 있는 프로젝트를 위해 리프레시 토큰을 도입하는 게 좋겠다는 의견을 줬다.

• 지금 당장 구현하기 쉬운 선택 보다는, 실제 서비스에 가까운 인증 구조를 경험해보는 것도 좋을 것 같아 리프레시 토큰을 포함한 JWT 인증 방식을 채택했다.

토큰은 클라이언트 어디에 저장할까?

• 다음으로 고민했던 부분은 발급된 토큰을 클라이언트의 어느 위치에 저장할지였다.

• 인메모리, 로컬 스토리지, 쿠키 등 여러 선택지가 있었지만, 최종적으로 액세스 토큰과 리프레시 토큰 모두 쿠키로 관리하는 방식을 선택했다.

• 이유는 우리 서비스가 웹 환경에 한정된 서비스라는 점이 컸다. 모바일 앱 연동을 고려하지 않아도 되는 상황에서, 쿠키 기반 인증이 가장 보안성도 좋고 빠르게 개발이 가능할 것 같았다.

• 또 자바스크립트에서 토큰에 접근할 수 없도록 제한함으로써 XSS 공격으로 인한 토큰 탈취 위험을 줄일 수 있었다.

• 마지막으로 토큰을 쿠키로 관리하면 클라이언트에서 별도로 토큰을 헤더에 실어 보내는 로직을 작성할 필요가 없다는 점도 장점으로 느껴졌다.

리프레시 토큰을 백엔드 어디에 저장하는게 좋을까?

• 다음으로 고민했던 부분은 리프레시 토큰을 서버에서 어디까지 관리할지였다. 크게는 세 가지 선택지를 두고 고민했다.

• 첫 번째는 리프레시 토큰을 서버에 별도로 저장하지 않는 방식이었다. 구현은 가장 단순하지만, 토큰 탈취 시 강제로 만료시킬 수 없다는 한계가 있었다.

• 두 번째는 RDBMS에 리프레시 토큰을 저장하는 방식이었다. 토큰 탈취 시 강제로 만료시킬 수 있다는 장점이 있지만, 인증 요청마다 DB 접근이 발생할 수 있어 성능 부담이 생길 수 있다고 판단했다. 또, 토큰 기한 만료 시 만료된 데이터를 정리하기 위한 별도의 관리 로직이 필요하다는 단점이 있었다.

• 세 번째는 Redis에 리프레시 토큰을 저장하는 방식이었다. 만료 시간을 TTL로 관리할 수 있고, DB 부하를 줄일 수 있다는 점에서 매력적으로 느껴졌다.

• 이러한 장단점을 비교한 끝에, 리프레시 토큰을 Redis에 저장하는 방식을 선택했다. 이유는 이 당시에 Redis를 필요로 하는 기능(이미지 업로드 등)이 이미 존재했고, 인프라를 추가로 복잡하게 만들지 않으면서도 인증 로직에 Redis를 자연스럽게 활요할 수 있다고 판단했기 때문이다.

캠퍼들의 이야기 피드 등록 기능 구현

• 이번 주에는 캠퍼들의 이야기 피드 등록 기능 구현 작업도 이루어졌다.

• 캠퍼가 자신의 블로그 RSS URL을 한 번만 등록하면, 우리 서비스에서 이를 주기적으로 수집해 캠퍼들의 이야기에 자동으로 노출하는 방식이다.

• 사용자는 별도의 추가 작업 없이도 자신의 글을 자연스럽게 공유할 수 있고, 서비스 입장에서도 콘텐츠가 지속적으로 축적되는 구조를 만들 수 있었다.

사용자의 입장에서 한번 생각해보기

• 처음에는 June이 디자인해준 방식을 그대로 차용해 개발을 진행하려고 했다.

• 다만 구현을 시작하면서 한 가지 고민이 들었다. 과연 모든 사용자들이 ‘RSS URL’이 무엇인지 알까?

• 부끄럽지만 나 조차 이 프로젝트가 시작한 이후에 RSS라는 존재를 처음 알게 됐다.

• 즉, 사용자가 RSS의 개념을 모른다면 내 블로그를 등록하는 과정에서 사용자의 이탈이 발생할 것 같았다.

• 그래서 사용자가 블로그 주소만 입력해도 내부에서 RSS 주소로 변환해 주는 방식으로 방향을 바꾸었다.

• 사용자는 “내 블로그 주소를 등록한다”는 인식만 가지면 되기 때문에 사용자 경험이 더 좋아질 것 같았다.

신뢰할 수 있는 블로그 주소만 받기

• 뿐만 아니라 서버에서도 사용자가 제출한 주소가 정말 유효한지 검증을 진행했다.

• 사용자가 실수로 오타를 내거나, 우리 서비스에서 지원하지 않는 블로그 플랫폼의 주소를 입력하는 상황도 충분히 발생할 수 있다고 판단했다.

• RSS 피드 유효성 검증 로직은 3단계로 동작한다.
1. 도메인 검증 (Velog, Tistory RSS URL인지?)
2. HTTP 요청 수행 (응답 상태 코드가 200인지?)
3. Content-Type 검증 (text/xml 인지?)

• 이 세 가지가 모두 만족하면 믿을 만한 RSS 주소라고 판단하고 데이터베이스에 저장을 한다.

아쉬웠던 점은?

• 내 기준에서는 완벽하다고 생각했는데, 한 가지 놓친 부분이 있었다.

• 바로 사용자가 자신의 블로그가 아닌, 다른 사람의 블로그 주소를 등록할 수도 있다는 가능성이었다.

• 이 부분에 대한 피드백은 깐부팀(web14)과 데모에서 만난 web06팀의 질문을 통해 처음 인지하게 되었다.

• 우리 팀은 “사용자는 자신의 블로그를 등록할 것”이라는 전제를 깔고 있었기 때문에, 해당 시나리오를 깊게 고민하지 못했던 것 같다.

• 하지만 외부 팀의 시선에서는 충분히 제기할 수 있는 문제였기에, 외부 사용자의 피드백이 얼마나 중요한지 다시 한 번 깨닫게 됐다. (기능 구현에 매몰되다보니, 오히려 가장 당연한 전제를 의심하지 못했다.)

• 다만 현재는 캠퍼 인증을 완료한 사용자만 블로그 등록이 가능한 구조이기 때문에, 당장 큰 문제로 이어질 가능성은 낮다고 판단했다.

• 그래서 이 부분에 대한 해결책을 당장 생각하기보다는, 추후 개선 포인트로 명확히 인지하고 기록해두는 선택을 했다.

마무리하며…

• 이번 한 주는 팀원들 모두 각자의 역할을 다 해주었기 때문에 만족스러운 시간이었다.

• 바쁜 일정 속에서도 서로의 작업 상황을 공유하고, 막히는 부분이 있으면 함께 고민하며 해결하려는 팀 분위기가 너무 좋았다.

• 이제 최종 발표를 앞두고 있다. 남은 한 주는 빠르게 기능을 구현하는 과정에서 쌓인 기술 부채들을 정리하는 시간을 가지기로 했다.

• 그리고 우리가 어떤 문제를 해결하려 했는지가 잘 전달될 수 있도록, 위키를 잘 정리하는 데도 신경 쓰려고 한다.