WebAuthn / Passkey 인증

  • 패스키 로그인은 브라우저의 conditional UI 지원 여부를 먼저 확인하고 자동완성 가능한 환경에서만 조용히 시도하는 편이 UX가 좋음
  • HTML input 을 패스키와 같이 쓸 때는 autocomplete="username webauthn" 같은 힌트가 자동완성과 자격 증명 선택 흐름에 직접 영향을 줌
  • WebAuthn Signal API 는 페이지 진입마다 동기화하는 것보다, 패스키 추가/삭제, 이름·닉네임 변경처럼 실제 상태가 바뀌는 시점에만 호출하는 편이 맞음
  • 서버에 없는 credential로 로그인 시도가 들어왔을 때 signalUnknownCredential로 비밀번호 관리자 쪽 상태를 정리해 주면, 오래된 패스키 때문에 반복 실패하는 문제를 줄일 수 있음
  • 패스키 로그인도 결국 challenge 발급과 검증이 분리된 서버 플로우라서, challenge를 Redis에 저장하고 getdel처럼 한 번만 소비되게 만드는 것이 중요함
  • Turnstile은 모든 로그인 시도에 강제하기보다, rate limit 결과를 보고 위험도가 올라간 시도에만 요구하는 쪽이 더 자연스러움

REST API 설계

  • mixed PUT/DELETE 요청이 동시에 들어올 수 있는 기능은 사용자 단위 row lock 같은 직렬화 장치를 두는 편이 결과 예측이 쉬움

Next.js App Router / Search Params

  • App Router에서는 초기 searchParams는 서버에서 읽고, 이후 동기화는 클라이언트에서 별도 sync 컴포넌트로 맡기는 패턴이 안정적이었음
  • useSearchParams를 여러 컴포넌트가 각자 해석하면 CSR/SSR 경계가 흐려지기 쉬워서, 읽기와 반영 위치를 줄이는 게 중요함
  • replaceState로 URL만 갱신하는 UI는 초기 렌더 기준값과 클라이언트 상태가 어긋나지 않도록 설계해야 함

GTM / Kubernetes

  • GA에서 GTM으로 옮기는 일은 프론트 이벤트 함수만 바꾸는 게 아니라, 환경 변수, 스크립트 로딩, 서버 컨테이너, Argo CD 리소스까지 같이 손봐야 끝남
  • GTM 서버 배포는 deployment에 앞서 namespace, ingress, HPA, service account, external secret 같은 주변 리소스가 먼저 정리돼야 운영 가능함
profile
이유와 방법을 알려주는 메모장 겸 블로그 (Frontend, AI, 경제, 책)

0개의 댓글