2025-01-14

목차

1. Soft Delete 구현 방식과 쿼리 설계
2. JWT 토큰과 Redis를 이용한 블랙리스트 관리 방법
3. Access Token과 Refresh Token 관리 전략
4. 토큰 블랙리스트 저장 이슈와 효율성 논의
5. 무료 설문조사 라이브러리 및 상업용 라이선스 고민
6. 소셜 로그인 구현 방식과 OAuth 활용 사례
7. 도메인 설계: 유저 관련 기능 분리와 DDD 적용
8. Typia 라이브러리의 transform 기능 사용 경험
9. 쿠폰 만료 상태 처리 방법과 설계 고민
10. 프로덕션 에러 및 리버트 경험 공유

1. Soft Delete 구현 방식과 쿼리 설계

• 핵심: 소프트 딜리트는 실제 데이터를 삭제하지 않고 삭제 여부를 표시하는 컬럼으로 관리함.
• 설명: 삭제 시 데이터를 제거하지 않고 is_deleted 또는 deleted_at 같은 컬럼을 업데이트함.
• 조회 시: 해당 컬럼으로 필터링하여 '삭제되지 않은' 데이터만 표출.
• 옵션: find 쿼리에서 소프트 딜리트를 자동 처리할지 여부를 컨트롤 하는 기능이 있으면 편리함.
• 의견: 소프트 딜리트는 테이블 설계 방법 중 하나이며, ORM이나 라이브러리가 이를 완벽히 지원해주지 않으면 실용적이지 않다는 의견도 있음.

2. JWT 토큰과 Redis를 이용한 블랙리스트 관리 방법

• 핵심: JWT를 Redis에 저장해 블랙리스트를 구현하는 방식에 대한 토론.
• JWT 저장: 보통 Redis에 토큰을 직접 저장하는 것보다, 사용자 ID 또는 토큰 상태값을 기준으로 관리하는 접근 추천.
• 설명: 토큰을 value로 저장하거나 hset 구조로 상태값을 기록함.
• 아이디어: 토큰 페이로드에 사용자 ID를 넣고, Redis에는 user:{id}:id 형태 키로 관리하여 로그인 시 토큰과 Redis 값을 비교해 검증 가능.
• 장점: 토큰 자체를 저장하지 않고, 사용자 단위 검증으로 블랙리스트 구현 가능.

3. Access Token과 Refresh Token 관리 전략

• 핵심: Refresh Token은 서버에서 반드시 보관해야 하며, Access Token은 서버에 저장하지 않아도 되는 JWT의 특성을 활용함.
• 설명:
  • Access Token은 짧은 유효기간을 두고, 갱신 시 Refresh Token 검증 후 재발급함.
  • Refresh Token 블랙리스트를 관리하여 탈취 및 로그아웃 대응.
• 팁: 유저가 로그인할 때마다 Refresh Token을 서버에 저장하고, Access Token은 클라이언트에만 유지.
• 효율성: Refresh Token 취소 관리가 핵심이며, Access Token은 기본적으로 서버 부담 없이 작동함.

4. 토큰 블랙리스트 저장 이슈와 효율성 논의

• 쟁점: 블랙리스트에 Access Token을 저장하는 부담 및 Redis가 죽으면 블랙리스트가 날라가는 문제.
• 대안: 정상 유저 토큰을 저장하기보다 비정상/차단 대상 토큰만 관리하는 것이 효율적.
• 기술적 고민: 토큰 크기가 무한정 커질 수 있어서 토큰 자체 저장보다는 토큰 내 상태값(예: payload.black:true)으로 필터링하는 방법 추천.
• 유지관리: 로그아웃, 토큰 갱신 시에만 상태값 업데이트하며, 자주 발생하는 Access Token 검증부하는 클라이언트에서 디코드 후 최소화.

5. 무료 설문조사 라이브러리 및 상업용 라이선스 고민

• 대화: SurveyJS 같은 UI 빌더 라이브러리의 상업용 라이선스 비용 문제.
• 대안: 무료 버전이나 오픈소스, 혹은 구입 고려를 통한 비용과 기능 비교 필요.
• 팁: 관리자 페이지의 빌더 기능은 사업 규모와 라이선스 비용을 고려해 결정.

6. 소셜 로그인 구현 방식과 OAuth 활용 사례

• 핵심:
  • 큰 회사는 OAuth 인증을 정석대로 활용하고, 전화번호나 기타 정보와 매칭하여 사용자 식별.
  • 작은 곳은 user ID만 받고 내부 토큰 발급하는 간단한 설계도 흔함.
• 설명: OAuth 인증은 인증 토큰으로 사용자 확인, 내부에서 별도 토큰을 만들어 세션 관리하거나 API 접근 제어.
• 의견: OAuth를 제대로 쓰면 보안과 확장성, 유지보수가 더 쉽지만 상황별 케이스가 존재함.

7. 도메인 설계: 유저 관련 기능 분리와 DDD 적용

• 핵심: "내 비디오", "내 책장" 같은 유저 관련 기능을 유저 도메인에 몰아넣지 않고 별도의 도메인으로 분리함.
• DDD 적용법:
  • 유저 도메인은 사용자 정보의 핵심만 포함.
  • 다른 기능은 별도 도메인(예: 책장 도메인)으로 분리해 독립적 관리.
• 이점: 장애 시 도메인 간 전파를 막고, 복잡도 절감과 유지보수 편의를 도모.
• 참고: 상황과 문제마다 적용 방식 다르므로 무조건적 원칙은 없음.

8. Typia 라이브러리의 transform 기능 사용 경험

• 문제: Typia에서 request 데이터를 원하는 형태로 변환해서 DTO에 할당하는 기능이 어려움.
• 요청: 사용 경험 및 활용 예제 공유 희망.
• 설명: Typia는 타입 안정성 확보에 유용하지만, 변환(transform) 기능은 문서나 예제가 부족해 초보자에게 진입장벽 있음.

9. 쿠폰 만료 상태 처리 방법과 설계 고민

• 두 가지 방법
  1. 배치(Cron) 작업으로 쿠폰 상태(Status)를 "Active"에서 "Expired"로 업데이트하고, 상태값으로 조회.
  2. 조회 시점에 만료일(expired_date)과 현재 날짜를 비교하여 만료 여부 판단.
• 장단점
  • 1번: 상태 컬럼 관리 필요, 배치 유지관리 부담 있음, 복잡도 높음.
  • 2번: 쿼리와 로직 단순, 실시간 판별, 관리포인트 적음.
• 의견: 대부분은 2번 간단한 방법 선호. ELasticsearch 같이 검색 최적화 솔루션 사용 시 1번 방식을 쓸 수도 있음.
• 콕 집어 팁: 컬럼명은 expires_at으로 명명하는 게 관례이며, 만료를 의미하는 영어 단어 선택은 주의 필요.

10. 프로덕션 에러 및 리버트 경험 공유

• 사례: 프로덕션에서 실수로 에러 발생 후 리버트 경험 공유.
• 마음가짐: 실수는 누구나 할 수 있으니 너무 자책하지 말고, 빠른 리버트와 안정화가 중요.
• 팁: 장애 시 침착한 대응과 복구 경험은 값진 자산임.

면접팁⚡

• JWT 토큰과 Refresh Token의 역할과 관리 방법에 대해 설명할 수 있도록 준비하자.
• Soft Delete 구현 시 DB 설계와 쿼리 접근법을 이해하고, 장단점을 말할 수 있어야 함.
• DDD(도메인 주도 설계)의 개념과 유저 관련 기능을 분리하는 이유에 대해 정리.
• 쿠폰 만료 처리 방식의 두 가지 접근법과 상황에 맞는 선택 기준을 설명할 수 있어야 함.
• OAuth 인증 프로세스와 내부 토큰 관리 차이에 대해 숙지.

링크🔗

• GitHub 상태 확인: https://www.githubstatus.com/
• DDD 관련 유튜브 영상: https://youtu.be/7pOWbjZuirw?si=XKeAm1FvMjdf4y_K