검색

전자정부 UI/UX가이드에 의하면 푸터는 브랜드영역에 있어야 하는 항목이고, 사이트 목적에 따라 필수적으로 푸터에 넣어야 되는 항목들이 존재합니다.

따라서 웹사이트의 푸터는 페이지마다 반드시 적용되어야 하는 것은 아닙니다. 푸터는 사용자가 탐색 과정에서 확인하지 못한 내용을 다시 확인할 수 있도록 도와주는 역할을 하지만, 모든 페이지마다 동일한 내용이 반복되지 않아도 됩니다. 특정 정보나 서비스에 대한 접근성을 높이고, 사용자의 다음 행동을 유도하기 위한 목적으로 사용될 수 있기 때문에 웹사이트의 목적과 사용자의 편의성을 고려하여 적절하게 적용되어야 합니다.

푸터 구성 요소 정리

웹사이트 기능별로 필요한 푸터 항목을 아래와 같이 정리할 수 있습니다:

• (기능 없는) 브랜드 홈페이지
  • 회사 정보: 대표자명, 사업자등록번호, 주소, 전화번호 등
  • 이용약관
• 회원가입 기능이 있는 경우
  • 개인정보처리방침
  • 이메일 주소 무단수집 거부 안내
• 결제 기능이 있는 경우
  • 전자상거래 이용약관 추가
• 업종별 특성에 따른 추가 요소
  • 언론사: 고충처리인 제도 안내, 저작권 보호 관련 정보

이 구성을 통해 웹사이트의 목적과 사용자 요구를 충족시키면서 법적 요구사항도 준수할 수 있습니다. 한국디자인시스템

FedCM(Federated Credential Management)은 Chrome v120 이상에서 Google 로그인을 지원하는 방식으로, 기존 gapi.auth2 방식은 2025년 종료 예정입니다. 브라우저가 계정 선택 UI를 직접 렌더링하며, 3rd-party 쿠키 없이 작동해 보안성과 프라이버시를 강화합니다. Safari, Firefox 등은 아직 지원하지 않으므로 fallback 구조가 필요합니다. Google 로그인 플랫폼 라이브러리는 2025년 8월부터 FedCM API를 필수 채택합니다.

1. 적용 배경

• 기존 OAuth 로그인은 accounts.google.com 쿠키에 의존 → 보안/프라이버시 문제
• 3rd-party 쿠키 폐지 (Chrome 기준 2025년)
• 브라우저가 로그인 중개자 → 사용자 동의 확보
• Privacy Sandbox의 핵심 요소

2. Google FedCM 로드맵 및 OAuth 영향도

• 2024.03: GIS SDK 기반 FedCM default 적용 시작 (기존 OAuth 서버 사용 가능)
• 2024.07: iframe 내 One Tap도 FedCM 전환
• 2025.03: platform.js 강제 FedCM 전환 시작
• 2025.08: platform.js 완전 종료
• 이후: SAML, 다중 IdP, 로그아웃 메트릭 API 지원

3. 각 서비스에 대한 영향도

1) 웹/앱 영향도

• OAuth 프로토콜 유지 & 로그인 UI만 FedCM 변경 → 앱 영향 없음
• 영향을 받는 영역: 로그인 UI, IDP UI 처리, 토큰 발급 방식
• 영향을 받지 않는 영역: id_token/access_token 발급, OAuth 서버, API 호출

2) 하이브리드 앱

• WebView 기반 앱: FedCM 미작동 → OAuth2 유지 or Custom Tab 필요
• 구조별 영향도:
  • WebView: ❌ FedCM 작동 안 됨
  • Custom Tab: ✅ FedCM 작동 가능
  • Safari View Controller: ✅ 가능
  • Web App 형태: ✅ 완전 적용 대상

3) 기존 OAuth와 FedCM 비교

• 인증 방식: OAuth는 팝업/redirect / FedCM은 브라우저가 UI 렌더링
• 쿠키: OAuth는 3rd-party 쿠키 사용 / FedCM은 쿠키 불필요
• UI 제어: OAuth는 서비스 직접 구성 / FedCM은 브라우저가 제어
• 자동 로그인: OAuth는 prompt=none 지원 / FedCM은 명시적 선택 필요
• 브라우저 지원: OAuth는 전 브라우저 / FedCM은 Chrome만 지원 (2024.07 기준)

4. UI 관련 주의사항

• 브라우저가 UI를 통제 → 브랜드 스타일 반영 불가
• UI 미노출 상황 존재 (예: 구글 로그인 상태 아닐 경우)
• UI 노출 위치는 Active/Passive 모드에 따라 다름
• 대응 팁: “Google 계정 선택창이 나타납니다” 안내 문구 제공

5. 서비스 운영 측면

• 웹/앱 로그인 단절 (SSO 불가) → 앱→웹 토큰 전달 구조 필요
• 브라우저별 분기 필요 (window.FederatedCredential 체크)
• 기존 로그인 트래킹은 수동 이벤트 전환 필요
  • 로그인 시도: 버튼 클릭 이벤트 수집
  • UI 노출: 직접 감지 불가 → 버튼 클릭 기준 추정
  • 로그인 성공: onCredentialResponse() 시점 수집
  • 로그인 실패: fallback 흐름에서 실패 이벤트 기록
• 트래킹 팁: navigator.userAgent, window.FederatedCredential 기반 분기
  • FedCM과 OAuth 퍼널 별도 구성 권장

6. 개발 측면

• 기존 gapi.auth2 제거 → google.accounts.id.initialize() 사용
• 로그인 토큰은 onCredentialResponse()로 수신
• UI 비노출/계정 미보유 등 예외 처리 필요
• fallback 시 기존 OAuth redirect 방식 유지

7. 기타 고려사항

• SEO/트래킹: 쿠키 기반 분석 구조 → 로그 기반 변경
• QA 테스트: 브라우저/OS 조합별 UI 테스트 필요
• 보안: 앱 → 웹 토큰 전달 시 1회용 + HTTPS 설계 필요
  • Google Identity Services – FedCM 마이그레이션 가이드
  • Chrome Privacy Sandbox – FedCM 설명
  • SuperTokens – Post-cookie OAuth 대응 전략