🔖

프로젝트 중간 피드백 기록

일시 : 2022.08.06 (토)

프로젝트 마감 조율

제한된 기간 내에 프로젝트를 완성시킬 수 있을지 잘 조율하면서 진행하면 좋을 것 같다.

크롬 익스텐션

익스텐션에서의 로그인은 계속 유지되는가?

현재 웹 버전에서 자동 로그인은 2주일까지 자동으로 가능하다.
웹 버전과 익스텐션 버전에서 토큰 공유가 되는지는 확인해봐야 할 것 같다.

익스텐션에서 로그인은 2주보다는 조금 더 오래 유지되면 좋을 것 같다.

CI/CD 및 배포

최대한 빨리 프론트에 API 및 DB 데이터를 전달하는게 좋을 것 같다.

현업에서는 더미데이터 까지도 서버에서 제공받을 수 있도록 인프라를 구성해두곤 한다.

프론트에서는 데이터를 가지고 있지 않도록 관리하는 편

API 명세서 관리

Postman으로는 자동화 형상 관리가 어렵다.

HTTP Client | IntelliJ IDEA 을 사용해서 API 명세서 형상관리 하는 것을 고려해보면 좋을 것 같다.
코드를 변경하면 API 문서도 자동으로 변경될 수 있는 자동화 툴을 사용하는 것이 좋을 것 같다.

현재 사용하고 있는 Postman의 경우 코드에서 API URL이 변경되면 Postman 에서도 직접 변경해줘야 하므로, 형상관리가 어려울 수 있음.

기술적 도전

북마크 폴더를 FORK 하는 로직

내가 다른사람의 북마크를 FORK 했을 때

내 저장소에는 FORK 하는 시점의 북마크 상태가 영원히 유지되어야 한다.
즉 내가 특정 사용자의 폴더를 FORK 한 이후, 원본 폴더의 작성자가 해당 폴더 내용을 수정해도 내가 FORK 한 폴더의 상태는 유지되어야 한다.

지금은 북마크 폴더를 FORK 하는 경우 복사 → 붙여넣기가 된다.

이렇게 되면 DB 테이블에 중복 row가 너무 많아지지 않을까?

URL 을 어떻게 저장할 것인가?

100명의 사람이 각자의 폴더에 www.naver.com 을 저장하는 경우

DB 에는 100개의 www.naver.com 데이터가 생기게 된다.
이 문제를 어떻게 해결하면 좋을까?

엄청나게 복잡한 URL 을 저장하는 경우

불필요한 parameter, request param, query string 이 붙어서 URL이 복잡해진 것일 수 있다.
이것을 정제해주는 작업이 존재하는가?
유저가 입력하는 URL 이 기존에 저장된 URL 과 문자열은 달라도, 같은 페이지를 가리키는 경우 역시 중복된 데이터가 DB에 저장될 수 있는데 이것을 어떻게 처리할 것인가?

질의응답

질문1 API 설계시 재사용성 고려

다 때려넣기 VS 재사용성 고려하기

API 상으로는 하나의 API 로 통일하되, 내부적으로는(Controller, Service) 분리하는 방식으로 코드를 설계하는 것이 좋지 않을까?

적절하게 객체지향을 얼마나 잘 활용할 수 있을지 고민해보면 좋을 것 같다.

질문2 User의 식별자를 클라이언트 단에 넘겨서 사용해도 되는지?

대부분의 서비스가 식별자(DB의 PK ID값)를 사용하지 않고 email 등을 사용하는 것 같은데 왜 그런지, 보안상의 이유인지 궁금합니다!

실제로 식별자(DB의 PK ID값)는 보안상의 이슈가 있을 수 있다.

예) 해커가 서버를 모니터링 하면서 드나드는 사용자들의 PK ID 를 확인했다. 목격된 사용자 ID 값 중 가장 큰 값이 1000 이었다면 → 이 서비스는 1000명 정도의 사용자가 있군! / 이런 부분이 유추가 가능함

그래서 보통 hash 값 등을 사용하곤 한다. 다른 사람이 값을 봤을 때 이게 도대체 무슨 값인지 모르도록.

토큰으로 유저를 식별한다면 토큰 관리가 어렵지 않을까?

사람마다 토큰이 재발급 되어야하는 주기가 다르기 때문에.

질문3 현업에서 JWT 인가를 사용하는 경우 리프레시 토큰을 활용하는지?

리프레시 토큰을 사용하지 않는다면 자동 로그인을 어떻게 구현해야 할지?
액세스 토큰이나 리프레시 토큰을 탈취당하는 경우를 어떻게 방어해야 할지?
리프레시 토큰을 사용하면 리프레시 토큰 갱신에 대해 어떻게 처리하는지 궁금합니다!

자동 로그인 구현에는 세션 ID, 쿠키를 사용하지 않을까?

세션 ID, 쿠키와 더불어 액세스 토큰 등의 사용 여부는 서비스마다 다른 것 같다.
헤더에 토큰 넣고, 헤더와 세션을 보고 로그인한 사용자인지 아닌지 구분했던 것 같다.

현업에서 JWT는 별로 사용해보지 않았던 것 같다.