기획·PM·디자인 실무 질문과 답변을 모았어요. 총 67건.
페르소나는 서비스 사용자의 대표적인 특징을 가진 '가상의 인물'입니다. 막연한 사용자 대신 실제처럼 느껴지는 인물을 통해 공감과 문제 정의가 쉬워집니다.
a. 데이터 수집 및 분석
b. 페르소나 프로필 작성
c. 유사 인물 탐색
d. 일상 시뮬레이션
e. 활용
기획자 C: 모달이라는 개념자체가 레이어나 다이얼로그 같은 게 나타났을 때, 기존에 있던 페이지를 사용하지 못하는 방식으로 알고 있어요. 반대가 모달리스인데, 레이어가 떠있어도 기존 페이지 클릭 가능한 개념일 거예요
기획자 D: 모달과 모달리스를 기본으로 띄워지는 방식이 팝업이냐, 레이어냐를 따지는 것으로 보면 되지 않을까 함.
기획자 E: 모달과 모달리스는 뒤에 화면을 비활성화 해 주느냐 활성화 해 주느냐의 개념으로 구분하고, 뒤의 화면을 비활성화 하는 방법으로 레이어를 이용하는 느낌?
기획자 F: 저희 개발팀에서는 말씀하신 모달리스는 걍 레이어팝업과 동일하게 간주하고, 모달레이어는 뒤에 클릭 안되게 딤(dim)처리해서 하는 정도로 인식하고 처리한다고 하네요.
프로젝트 수행 전에 세운 가설과 지표, 이를 검증할 수 있는 데이터가 무엇인지에 따라 수집해야하는 값이 상이합니다.
페이지 사용성을 검토할 때, 유입 & 이탈 데이터(페이지뷰, 유입 경로, 이탈률, 체류 시간)로 전반적인 관심도를 파악하고, 인터랙션 데이터(클릭 이벤트, 스크롤 깊이, CTA 클릭률)로 사용자 행동을 분석해야 합니다. 또한, 전환 데이터(전환율, 폼 이탈률, 에러 발생)와 사용자 행동 흐름(사용 경로, 세션 리플레이)을 추적하여 UX를 최적화할 수 있습니다.
SEO는 전통적으로 마케터, 퍼블리셔, 개발자, 기획자 등 다양한 역할이 협업해야 하는 영역입니다. 하지만 웹 기획자(PM)도 SEO를 일정 수준 이상 이해하고 관리할 책임이 있습니다.
정리하자면
SEO관련 아티클 모음 SEO는 무엇이고, 왜 필요하나요? https://disquiet.io/@tjrwjdgus225/makerlog/seo%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B4%EA%B3%A0-%EC%99%9C-%ED%95%84%EC%9A%94%ED%95%98%EB%82%98%EC%9A%94-1692084734116
SEO 관리 https://disquiet.io/@leehreen/makerlog/2817
성공적 SEO 마케팅의 No.1 핵심 https://www.nnt-consulting.com/%ec%84%b1%ea%b3%b5%ec%a0%81-seo-%eb%a7%88%ec%bc%80%ed%8c%85%ec%9d%98-no-1-%ed%95%b5%ec%8b%ac%ec%9d%80-%eb%ac%b4%ec%97%87%ec%9d%bc%ea%b9%8c/
구글 SEO 체크 리스트 항목 https://novela-soft.com/seo-check
핵심 비교 요약
가격 및 정책
요약
이용약관과 개인정보 수집 및 이용 동의는 별개로 받아야 합니다.
개인정보 처리방침에는 동의를 받지 않습니다. 이용자에게서 수집하는 개인정보 및 해당 정보들의 수집 목적, 보유기간에 대해 별도로 명시한 개인정보 수집 및 이용에 대한 동의를 받아야 합니다.
회원의 개인정보가 제3자에게 제공되거나 광고/마케팅 목적으로 사용되는 경우 해당 항목들에 대해서도 별개의 동의를 받아야 합니다.
공공기관 : 기관장 또는 CISO(정보보호최고책임자)
일반 기업 : IT부서장, 보안 책임자, 법무팀장, 전략기획실장 등
중소기업 : 대표자 또는 개인정보 실무 담당자
학교/비영리단체 : 교장, 원장, 행정책임자, 정보 담당 교사 등
책임자는 조직 규모나 개인정보 처리 수준에 따라 전담 조직 구성도 가능
반드시 조직 내 임직원이어야 함. 위탁은 불가함
개인정보 보호법상 유저 리뷰는 작성자의 개인정보가 포함될 수 있어, 이를 수집·이용하기 위해서는 원칙적으로 동의를 받아야 하나, 개별 동의 없이 리뷰를 활용하고자 할 경우 이용약관/개인정보처리방침/개인정보 수집 및 이용 동의에 명확히 이용 목적 및 관리범위를 고지가 되어 있어야 합니다.
참고
일반적으로는 관리자용 앱도 별도의 약관 및 개인정보처리방침을 갖추는 것이 원칙입니다. 해당 앱에서 처리되는 정보의 주체, 목적, 범위가 다르기 때문입니다.
항목 기준 구분
요약 고객앱 약관으로 관리자앱까지 포괄하는 것은 위험하며, 운영목적과 정보 수집 목적이 다르므로 반드시 별도 문서가 필요합니다.
참고 사례
약관의 규제에 관한 법률에 따르면 약관이란 그 명칭이나 형태 또는 범위에 상관없이 계약의 한쪽 당사자가 여러 명의 상대방과 계약을 체결하기 위해 일정한 형식으로 미리 마련한 계약의 내용을 말하며, 다수의 이용자에게 적용하기 위해 표준화된 계약 양식으로 볼 수 있습니다.
서비스 이용약관을 처음 작성할 경우, 공정거래위원회에서 제공하는 표준약관을 참고하여 개별 서비스에 맞도록 변경하여 사용할 수 있습니다. 업종별로 약 80개의 약관이 제공됩니다. -표준약관 참고: https://www.ftc.go.kr/www/selectBbsNttList.do?bordCd=201&key=202
개인정보 처리방침 가이드 (by 개인정보보호위원회) https://www.privacy.go.kr/front/bbs/bbsView.do?bbsNo=BBSMSTR_000000000049&bbscttNo=13153
서비스 정책서는 불가항력적인 요소를 우선 고려하며 정책을 결정하고 문서로 작성해야 합니다.
**정책서 작성시 **
정책서 작성 방법(아래 외에도 다양한 방법이 있음)
*팀 구성원 모두가 확인하기 편한 방식으로 정리
즉, 위치정보사업 이용약관은 위치정보 수집·관리 주체의 법적 책임과 의무를 규정에 중점되어 있고, 위치기반서비스 이용약관은 이용자가 서비스를 어떻게 이용하는지에 대해 구체적인 약관임
원칙적으로 플랫폼의 소유권 및 운영 주체가 누구인지에 따라 달라집니다.
소유자/운영 주체 구분에 따라 구분
추가 설명
필수는 아니지만, 특정 법률에 따라 소비자에게 정보를 제공하는 것이 요구될 수 있습니다.
예를 들어, 전자상거래 등에서의 소비자보호에 관한 법률에 따르면, 인터넷쇼핑몰 사업자는 전자적 대금지급이 이루어진 경우에 소비자에게 신속하게 대금지급 사실을 알리는 것이 필요합니다. 이는 전자우편, 전화, 휴대전화 단문메시지(SMS), 팩스를 통해 이루어질 수 있습니다.
결론적으로, 상거래 결과를 발송하는 것은 필수는 아니지만, 소비자 보호를 위해 특정 정보를 제공하는 것은 필요할 수 있으며, 광고 목적이 아닌 경우에는 별도의 동의 없이도 가능합니다.
푸시 발송과 관련된 개인정보 처리 방침의 출처는 주로 정보통신망 이용촉진 및 정보보호 등에 관한 법률과 개인정보 보호법입니다.
워치는 화면이 작고, 입력 방식(터치/버튼/음성)이 제한적 → 핵심 기능만 간결하게 보여줘야 함
기획자는 "이건 진짜 워치에서 필요한가?"를 반복해서 자문해야 함
예시: 알림 확인, 빠른 응답, 헬스/센서 기반 데이터에 집중해서 체크
스마트워치 앱 기획 시 먼저 고려해야 할 것들
각 스토어에서 고려해야할 점
2.비밀유지 동의서(NDA) 샘플 항목
푸시/이메일 수신 동의와 마케팅 목적 수신 동의의 차이점은 아래의 구분을 참고하시면 되겠습니다.
맥비톡방 현직 기획자들의 실무 의견을 정리한 내용입니다. 정답이 하나로 정해진 영역은 아니니 상황에 맞게 참고하세요.
두 파트로 나누면 정리가 쉽습니다.
해당 부분은 회사/조직별로 다르며, R&R 정리 및 협업 프로세스 협의를 통해 가장 최선의 방법을 찾아나가야 함. 아래 내역은 참고하시기 바라며, RACI 프레임워크 참조한 적용도 좋은 방법임
기획자의 기획서가 과도한 완성형으로 전달되면 디자이너는 경험 개선 여지를 찾기 어려움 → 와이어프레임은 정답이 아님. 더 나은 서비스를 위해 변동될 수 있음을 모두가 인지.
[서비스 제안 & 요구사항 도출]
[서비스 기획]
[와이어프레임]
[UI 디자인]
[피드백 / 수정]
[개발 전달 (핸드오프)]
[공동 리뷰 & 개선]
[Release 기준 정리]
- 프로세스
[요구사항 정의] → [IA 구조 작성 ]→ [UX 구조 검토] → [와이어프레임 작성]→ [UI 디자인 및 비주얼 구성] → [기획자-디자이너 상호 피드백] → [최종안 확정] → [개발 진행 ] → [추가 이슈 반영 & 업데이트]
- 커뮤니케이션 가이드
- 피그마 코멘트 활용 기준
- 모든 피드백은 @이름 태그 + 목적 명시 → 개발자가 양쪽의 의도 파악하는 것도 가능.
- 기획자 : 기능 목적 및 기획 의도 공유
- 디자이너 : 개선 사유 및 의도 공유
(예시)
@디자이너 기존에 정의된 팝업 대신 다른 형태의 팝업이 필요한 이유가 뭔가요?
@기획자 여기서 다른 형태의 팝업을 띄우는 것은 유저에게 다른 액션을 유도하기 위함입니다
- 정기 Sync 및 일일 스크럼을 통해 지속 업데이트
- 각 기능별 기획 의도 vs 실제 구현 내용 비교 가능하도록 UI QA 기준 정리
- 기능 QA & 디자인 QA 일정도 반영 필요
- Tip : Figma dev mode 이용 시 개발자와의 효율적 커뮤니케이션 가능 (유료)
당신의 조직이 기획자 주도 조직이라면?
→ 기획자가 기능 명세 및 IA 구조, 플로우 구성, UX 디자이너에게 피드백 우선권과 리디자인 권한을 부여해야 함
당신의 조직이 디자이너 중심 조직이라면?
→ IA는 디자이너가 가져가고, 기획자는 비즈니스 로직과 기능 명세에 집중해야 함 raci 프레임워크
비로그인 사용자의 경우
[상세] 쿠키 유형과 동의 필요 여부
전자정부 UI/UX가이드에 의하면 푸터는 브랜드영역에 있어야 하는 항목이고, 사이트 목적에 따라 필수적으로 푸터에 넣어야 되는 항목들이 존재합니다.
따라서 웹사이트의 푸터는 페이지마다 반드시 적용되어야 하는 것은 아닙니다. 푸터는 사용자가 탐색 과정에서 확인하지 못한 내용을 다시 확인할 수 있도록 도와주는 역할을 하지만, 모든 페이지마다 동일한 내용이 반복되지 않아도 됩니다. 특정 정보나 서비스에 대한 접근성을 높이고, 사용자의 다음 행동을 유도하기 위한 목적으로 사용될 수 있기 때문에 웹사이트의 목적과 사용자의 편의성을 고려하여 적절하게 적용되어야 합니다.
웹사이트 기능별로 필요한 푸터 항목을 아래와 같이 정리할 수 있습니다:
이 구성을 통해 웹사이트의 목적과 사용자 요구를 충족시키면서 법적 요구사항도 준수할 수 있습니다. 한국디자인시스템
** 브레이크포인트(Breakpoint)란?**
브레이크포인트(Breakpoint)는 반응형 웹 디자인에서 화면 크기에 따라 레이아웃이 변경되는 기준점입니다. 주로 CSS 미디어 쿼리(@media)를 사용하여 특정 해상도에서 스타일을 조정할 때 활용됩니다.
주요 브레이크포인트 기준 (일반적인 해상도 예시)
브레이크포인트는 프로젝트에 따라 다르지만, 보편적으로 다음과 같은 기준이 사용됩니다.
2025년 AI 도구 순위 (필수 툴부터 아쉬운 툴은?)
정책적인 부분은 크게 법률·규제 준수, 서비스 운영 정책, 보안·인증 정책을 알아야 함
법률·규제 준수
개인정보 수집·이용 동의 >> 수집·이용 목적, 보유기간, 수집 항목을 명확히 고지, 거부 시 안내 노출 >> 개인정보 필수/선택 항목 구분 만 14세 미만 가입 제한 및 보호자 동의 >> 법정대리인(보호자) 동의 필수, 본인/보호자 인증 절차 필수 적용 약관 동의 >> 이용약관, 개인정보처리방침은 필수동의 마케팅 수신 동의 >> 광고성 정보 발송시 사전 동의 필수, 수신 거부권 안내 포함 필요 외부 인증 연동 시 개인정보 제3자 제공 동의 다크패턴 방지 : 2025년 2월 14일부로 전자상거래법 개정 시행으로 회원가입, 결제 유도, 자동결제(정기결제) 전환 등에서 사전 동의/고지 의무, 특정 옵션 사전 선택 금지, 시각적 착오 유발 금지 등 다크패턴 규율 신설, 위반시 과태로 부과 있음 필수 대상과 선택 대상에 대해 명확히 표시하고, 선택 대상 미동의 시 서비스 이용을 제한할 수 없음
서비스 운영 정책
회원가입 승인 절차 : 실시간 가입인지 관리자 승인에 따른 가입인지 중복 가입 방지 아이디/닉네임 정책 : 길이, 특수문자 허용 여부, 욕설/비속어 필터링 비밀번호 규칙 : 최소 자릿수, 대소문자/숫자/특수문자 조합, 주기적 변경 여부 회원등급 및 권한 설정 : 일반회원/기업회원/관리자 등 역할별 권한 정의 탈퇴 절차와 데이터 삭제 정책 : 탈퇴 시 즉시 삭제 항목, 일정기간 보관 후 삭제 항목(전자상거래법상 거래기록 5년 보관 등)
보안·인증 정책
간편로그인/소셜로그인 방식 추가시 고려사항
이용자 동의 및 약관 구성 간편 로그인 자체는 외부 서비스 약관과 연동되지만, 서비스 제공자의 약관·개인정보 수집·이용 동의는 별도로 받아야 함 예: 카카오로그인 시 ‘제3자 제공’ 동의뿐 아니라, 본 서비스의 약관 및 개인정보 수집 동의를 반드시 받아야 함
각 플랫폼별 수집 데이터 이해 및 보완 소셜 로그인 플랫폼마다 제공하는 유저 정보가 다르므로, 사업 목적에 맞춰 추가 정보 수집 필요 만약 회원가입 정책이 중복계정 생성 불가라면 CI정보 필요 개인정보 보호법
정보통신망법
전자상거래법
국내 서비스에서는 대한민국의 개인정보보호법과 정보통신망법 등 국내 규제의 영향을 받습니다. 반면, 글로벌 서비스를 기획할 때에는 서비스 대상 국가 범위에 따라 지역별 규제를 고려해야 합니다. 대표적인 지역별 규제로는 GDPR(유럽), CCPA(캘리포니아)와 같은 규정이 있습니다. 글로벌 서비스를 런칭할 때 현실적으로 모든 국가의 규제를 검토하기에는 역부족인 경우가 많습니다. 이런 경우 GDPR을 기준으로 주요 서비스 대상 국가의 규제를 보완해서 적용하면 효율적입니다. GDPR은 동의 방식이나 데이터 수집 및 처리 등에 있어 대부분의 경우 가장 까다로운 요건을 포함하고 있기 때문에, 이를 준수하면 대부분의 선진국 규제를 커버할 수 있습니다.
소셜 로그인 방식에 사용되는 플랫폼을 선정할 때 타겟 국가의 선호도를 고려할 필요가 있습니다. 예를 들어 동남아 국가들에서는 해당 국가들에 점유율이 높은 WhatsApp을 활용한다거나, 중국의 경우 WeChat이나 QQ같은 서비스를 통한 로그인을 고려할 수 있습니다. 타겟 국가가 광범위하다면 서비스 런칭 초기에는 글로벌 표준 플랫폼으로 인식되는 Google이나 Facebook로그인 옵션을 먼저 구현하고, 주요 타겟 국가에 따라 한두 가지의 옵션을 추가로 고려해볼 수 있습니다. 휴대폰 인증이 필요할 경우, 국내와 다른 환경을 고려해야 합니다. 국가 코드 등의 입력 양식에서부터, SMS 국제 발송 비용과 전송 성공률을 검토하고 서비스를 설계하는 것이 좋습니다. 비밀번호 정책의 경우 국내에서 자주 사용하는 영문+숫자+특수문자 방식을 활용할 수도 있으나 일부 국가의 경우 보안 규정이 더 엄격한 편입니다.
글로벌 서비스를 런칭할 때에는 언어, 문화적인 로컬라이제이션이 필요합니다. 언어의 경우 런칭 초기에는 영어 및 점유율이 높은 언어 위주로 서비스한 후, 사용자층이 높아진 시장에 맞춰 언어를 추가할 수 있습니다. 이름, 주소, 결제 정보 등의 정보를 수집할 때에도 문화권에 따라 형식이 달라질 수 있습니다.
예시) 날짜/시간 형식 : (MM/DD/YYYY) vs (YYYY-MM-DD) vs (DD/MM/YYYY) 이름 필드 : 서양권은 성(last name)과 이름(first name) 분리 필수, 동남아 일부는 성 없음 주소 형식 : 미국·유럽은 우편번호 위치, 중국·일본은 행정구역 순서 다름 로그인 방식 : SNS사용률에 따른 선호도 차이 (SNS 로그인 vs 이메일+비밀번호 로그인)
법률
동의방식
처리/보관
소셜로그인
인증방식
관련 법규
사업자등록 여부와 무관하게 개인도 개인정보처리자가 될 수 있습니다. 다만, 수집·이용·보관·파기 전 과정에서 개인정보보호법 제15조, 제29조, 제30조 등 주요 조항을 반드시 지켜야 합니다.
★개인정보보호법 제15조(개인정보의 수집·이용) ① 개인정보처리자는 다음 각 호의 어느 하나에 해당하는 경우에는 개인정보를 수집·이용할 수 있다.
*기본 개념 정보주체 = 개인정보의 주인, 즉 회원가입하는 사람 동의 = “내 정보를 이렇게 쓰는 것에 괜찮다”라고 허락하는 것
사이드 프로젝트 상황에 맞추면
★개인정보보호법 제29조(수집한 개인정보를 제대로 보호할 책임) 개인정보처리자는 개인정보가 분실ㆍ도난ㆍ유출ㆍ위조ㆍ변조 또는 훼손되지 아니하도록 내부 관리계획 수립, 접속기록 보관 등 대통령령으로 정하는 바에 따라 안전성 확보에 필요한 기술적ㆍ관리적 및 물리적 조치를 하여야 한다.
사이드 프로젝트라도 회원가입을 받는 순간, 최소한 위와 같은 보안 조치를 해야 합법적인 개인정보처리가 됩니다. 사이드 프로젝트 상황에 맞추면
★개인정보보호법 제30조 (개인정보 처리방침의 수립 및 공개) ① 개인정보처리자는 개인정보의 처리 목적, 보유 및 이용기간, 제3자 제공 등에 관한 사항을 포함하는 개인정보 처리방침을 수립하여야 한다. ② 개인정보처리자는 개인정보 처리방침을 정보주체가 쉽게 확인할 수 있도록 인터넷 홈페이지 등에 공개하여야 한다. ③ 개인정보처리자는 개인정보 처리방침을 변경하는 경우에는 그 내용을 공개하여야 한다.
개인정보를 모으는 사람(개인·사업자 불문)은 “우리 서비스는 개인정보를 이렇게 다룬다”라는 안내문(개인정보 처리방침)을 반드시 작성해야 합니다. 그리고 이걸 사용자(회원)가 쉽게 볼 수 있도록 홈페이지, 앱 화면, 가입 화면 등에 공개해야 합니다. 바뀌면 바뀐 사실을 공지해야 합니다. 사이드 프로젝트 상황에 맞추면 회원가입을 받는다면 간단한 개인정보 처리방침을 만들어서 공개해야 합니다.
※추가로 고려해야 할 것들
보유기간 & 파기 (제21조)
정보주체 권리 보장 (제4조, 제36~38조)
민감정보/주민등록번호 금지 (제23조, 제24조)
주민등록번호, 고유식별정보, 민감정보(건강, 신념 등)를 다루면 별도의 관리·보호 조치가 추가로 필요하며, 위반 시 과태료 등 제재가 있습니다.
★최종 요약★ 사업자 등록 없이도 개인정보 수집 가능 (개인도 개인정보처리자) 하지만 **15조(동의) · 29조(보안) · 30조(처리방침)**는 반드시 지켜야 함 여기에 **21조(파기), 36~38조(권리보장), 23·24조(민감정보 금지)**까지 챙기면 실무에서 안전 개인정보보호법
개인정보보호위원회 및 방송통신위원회 가이드라인
멤버십은 단순 구독모델과 달리 혜택·데이터·결제·광고가 얽히기 때문에, 국내 규제 고려가 필수입니다.
개인정보보호법 / 정보통신망법 : 회원 가입 시 최소 수집 원칙, 동의 절차, 제3자 제공 고지 의무. 특히 멤버십 혜택으로 제휴사가 관여하는 경우 개인정보 제3자 제공 동의 필요.
전자상거래법 / 소비자보호법 유료 멤버십(구독형)은 ‘청약철회(환불)’ 규정을 따라야 함. 결제 전 취소/환불 정책을 명확히 고지해야 하고, 자동 결제 갱신 시에는 재결제 안내 고지 필수.
표시광고법 / 공정거래위원회 고시 멤버십 혜택(예: “최대 50% 할인”) 표시 시 실제 적용 조건을 명확히 표기해야 함. 과장 광고나 미표시 시 과징금 위험.
통신사/PG사 관련 규정 정기결제 인앱결제(IAP)와 외부 결제 규정(구글/애플 정책 vs 자체결제) 통신사 소액결제 시 한도, 청소년 결제 제한 고려.
대한민국에서는 이미 다양한 멤버십 모델이 자리 잡았어요. 성공 포인트를 참고하면 좋아요.
쿠팡 로켓와우 멤버십 : 무료배송, 새벽배송, 쿠팡플레이 같은 생활+콘텐츠 번들링 전략.
네이버 플러스 멤버십 : 네이버페이 포인트 적립, 웹툰·뮤직·클라우드 연계. 결제 생태계 락인(lock-in)을 통한 재방문/재구매 유도.
SKT T멤버십 → 우주패스/Universe : 통신료+구독 번들 (넷플릭스, 디즈니+, 배달 앱 할인). 제휴사 묶음 제공이 핵심.
스타벅스 리워드 : 포인트 기반 멤버십으로 충성 고객 확보. 모바일앱 적립·결제 통합 성공사례.
멤버십 서비스 기획 시 한국 시장에서는 특히 아래를 점검해야 합니다.
가입 채널(앱 내 / 제휴사 앱 / 통신사 연동)
가격 정책
해지/환불 정책
CRM·푸시 운영
공정거래위원회 "전자상거래 등에서의 소비자보호지침" (유료 구독/멤버십 환불 관련)
개인정보보호위원회 가이드라인 (마케팅 동의 및 제휴사 데이터 제공 관련)
KISDI(정보통신정책연구원) 보고서 : 한국의 구독경제/멤버십 시장 현황
산업연구원(KIET) 트렌드 보고서 : OTT, 커머스 멤버십 비교 분석
일반적으로 탈퇴 즉시 개인정보가 삭제되므로, 아이디 찾기 할 때 탈퇴 이력이 있는 아이디는 미노출합니다. 단, 이후 탈퇴한 아이디로 재가입했을 경우에는 노출이 될 수 있습니다,
탈퇴한 아이디를 재가입 시 다시 사용할 수 있는지는 각 서비스의 운영 정책에 따라 결정됩니다.
**일반적인 온라인 서비스(커머스, 커뮤니티, 포털 등)**에서는 탈퇴 시점 이후에는 아이디를 다시 사용할 수 있도록 하는 것이 보통입니다.
이유: 아이디는 본질적으로 **식별자(ID)**일 뿐, 탈퇴하면 더 이상 해당 사용자에게 귀속될 필요가 없음 신규 유저의 선택지를 제한하지 않음 불필요하게 아이디 풀(pool)이 고갈되는 것을 방지
단, 일정 기간(예: 30일) 보류 후 재사용 가능하게 하는 경우도 있습니다. 이는 악의적 탈퇴→재가입 반복을 방지하기 위함입니다.
게임, 금융, 보안 민감 서비스에서는 동일 아이디 재사용을 막는 경우가 있습니다.
이유: 과거 탈퇴 계정과 혼동 방지 (예: 친구가 예전에 쓰던 아이디를 다른 사람이 쓰면 혼동 발생) 해킹이나 계정도용 피해자가 “내 아이디를 다른 사람이 다시 쓰고 있다”라고 민원 제기 가능 특히 결제·거래 내역과 연결되는 서비스에서는 동일 아이디 재사용을 원천적으로 차단하기도 합니다.
아이디 자체가 개인정보에 해당될 수 있음 (특히 이메일 형식, 전화번호 기반 아이디 등) 따라서 재사용을 허용한다면, 개인정보처리방침에 명확히 기재해야 합니다. “회원 탈퇴 시 해당 아이디는 즉시(또는 일정 기간 후) 재사용될 수 있습니다.” 반대로 재사용을 금지한다면, “회원 탈퇴 후 동일 아이디는 재사용 불가”라고 안내해야 합니다.
보안 민감하지 않은 일반 서비스라면 → 동일 아이디 재사용 허용 단, 탈퇴 후 30일~90일 보류 기간 두는 방식 권장 보안/금융/게임 서비스라면 → 동일 아이디 재사용 불가 계정 도용·혼동 리스크 방지
미성년자 회원가입과 관련해서는 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」, 「개인정보 보호법」, 그리고 「청소년 보호법」 등에 따라 법정대리인의 동의 및 인증 절차가 필요합니다.
일반적으로 서비스 사업자가 문서에 포함해야 할 내용은 다음과 같습니다.
미성년자의 회원가입 시 법정대리인의 본인 여부 확인 및 동의 절차를 위해 다음과 같은 정보를 수집할 수 있습니다. 단, 최소한의 정보만 수집해야 함
법정대리인 동의를 확인하기 위해 아래 인증 방법이 사용됩니다.
회원탈퇴 시 개인정보를 즉시 모두 삭제해야 하는 것은 아니며, 법적으로 일부 정보는 일정 기간 의무적으로 보관해야 함
회원이 탈퇴하면 개인정보는 원칙적으로 즉시 파기(삭제)해야 하나, 다음과 같은 예외적 보관 의무가 있음
「전자상거래 등에서의 소비자보호에 관한 법률」 등 관련 법령에 따라 거래·결제·분쟁처리 관련 정보 등은 아래 기준에 따라 별도 보관이 필요
계약 또는 청약철회 관련 기록 (전자상거래법 제6조) : 5년
대금 결제 및 재화 공급 기록 (전자상거래법 제6조) : 5년
소비자 불만 도는 분쟁처리 기록 (전자상거래법 제6조) : 3년
웹사이트 방문·접속기록 (통신비밀보호법) : 3~6개월
세법상 거래 증빙 (국세기본법, 부가가치세법 등) : 5년 이상
개요 : 한국 법(개인정보보호법)에는 “회원탈퇴 버튼을 반드시 둬라”는 문구는 없지만, 이용자가 삭제·동의철회·처리정지 등 권리를 쉽게 행사할 길을 마련해야 하고(권리 행사 수단 고지/운영), 목적 달성·보유기간 경과 시 지체 없이 파기해야 합니다. 이를 충족하지 않으면 위법 리스크가 큽니다.
관련 조항 : 이용자는 열람·정정·삭제·처리정지·동의철회를 요구할 권리가 있습니다(제4조, 제36·37조). 서비스는 권리 행사 방법과 절차를 마련·공개해야 하고, 수집 방법보다 쉽게 할 수 있어야 합니다(제38조). 이를 막거나 이행하지 않으면 제재 대상이 됩니다.
요약 : “회원탈퇴 버튼” 자체를 강제하는 조항은 없지만, 권리행사 창구(자기결정권 보장) 와 파기 의무를 실질적으로 이행하려면, 사용자 스스로 즉시 요청할 수 있는 회원 탈퇴 기능이 가장 확실하고 안전합니다.
실무적인 기준 앱 마켓 심사(Apple/Google) 는 “앱에서 계정 생성이 가능하면 앱 내에서 계정 삭제를 제공”하도록 사실상 의무화하고 있어, 실무적으로는 회원탈퇴(=계정/개인정보 삭제) 기능을 제공해야 통과됩니다.
Apple App Store: 2022-06-30부터 앱에서 계정 생성이 가능하면, 앱 내에서 계정 삭제를 시작할 수 있어야 하며 단순 비활성화만 제공하면 불충분. 삭제는 개발사 보관 데이터(법적 보존분 제외)까지 포함. 재인증·확인 단계는 가능하되 과도한 방해 UX는 불합격.
Google Play: 계정 생성 가능 시 ① 앱 내 삭제 경로와 ② 웹 링크(앱 없이도 삭제 요청 가능) 를 모두 제공. Data safety 폼에 삭제 실무 기재해야 하며, 2024-05-31 이후 미준수 시 제재(삭제 등). 법적 보존이 있으면 고지·분리보관.
법적으로 개인정보처리자는 「개인정보보호법」 제21조, 시행령 제16조에 따라 보유기간이 경과하거나 처리 목적이 달성(회원 탈퇴 등)된 경우, 해당 정보를 복구·재생 불가하도록 즉시 파기해야 함
단, 「전자상거래법」 등 관련법에서 정한 거래증빙, 세무자료 등은 정해진 기간(최대 5년) 분리 보관 가능하지만, 이용자 재가입 시 서비스 데이터(로그인 기록, 주문내역 등)를 복구하여 제공할 수는 없음
고객이 실수로 탈퇴한 경우, "탈퇴 후 곧바로 복구 요청" 수준에서는 기술적으로 임시유예기간(예: 7일~30일) 내에 한해 복구를 지원하는 곳이 있으나, 정식 '탈퇴처리 후'에는 개인정보가 완전히 파기된 것으로 간주되어 복원이 불가함
결론 회원 탈퇴 후 재가입은 내부 정책에 따라 사용 또는 불가로 진행은 가능하나, 데이터 복구는 불가
서비스(웹/앱 등) 운영자가 이용자의 개인정보를 어떻게 수집, 이용, 보관, 파기하는지를 투명하게 알리는 문서임. 한국에서는 「개인정보 보호법」, 「정보통신망법」 등에 의해 의무적으로 작성·공개해야 합니다.
일반적으로 다음 항목들을 포함해야 합니다.
(출처) 개인정보보호위원회 : 개인정보 처리방침 작성지침(2024)
개인정보 수집 및 동의 내용을 변경할 경우, 신규로 가입하는 회원에게는 별도의 조치가 필요하지 않고, 기존 회원에 대해서는 수집되는 개인정보가 추가될 경우, 추가 정보를 수집하기 전 별도의 안내가 필요합니다.
기존회원 대상으로 별도의 팝업 등 정보 수집 동의를 위한 플로우를 구성해야 하며, 기존 회원들의 거부감을 최소화하기 위해 해당 정보가 필수적으로 수집되어야 하는 시점에 동의를 받는 것을 권장합니다.
예를 들어 상품 배송을 위해 회원의 주소를 수집할 경우, 로그인한 모든 회원에 대해 동의를 받는 것보다는 상품 결제 및 배송 단계에서 정보 수집 동의를 받는 것이 회원 이탈 방지 및 과도한 개인정보 수집 방지 차원에서 바람직할 수 있습니다.
수집되는 개인정보가 추가되지 않고 삭제되는 경우, 별도의 동의 절차는 필요하지 않고 관련된 개인정보처리방침 개정 사항에 대한 공지만 진행되어도 무방합니다.
서비스 이용약관에 대한 동의는 확인 및 동의 의사를 나타내는 버튼 형식으로 대체될 수 있습니다. 하지만 회원가입시 일반적으로 이용약관과 함께 동의받는 항목인 개인정보수집 이용동의 및 제3자 제공 동의, 마케팅 수신 동의는 관련법에 의해 사용자의 명시적인 동의가 필요합니다.
따라서 사용자가 직접 체크하여 의사표시를 할 수 있는 체크박스 UI가 적합합니다. (미리 체크된 체크박스 사용 불가)
참고
→ WBS는 프로젝트 범위가 확정된 직후, 일정 및 자원 계획을 수립하기 전에 작성하는 것이 일반적
챗봇 기획 개요 작성
챗봇 플랫폼 선택
시나리오 설계 (1) 환영인사, 공지사항, 프로모션 안내, 운영시간 등 표기 (2) 선택할 수 있는 카테고리 제공 (예. 제품 문의, 상품 추천 등) (3) 카테고리별로 답변 및 버튼 연결
배포 이후 운영 개선
웹 접근성(Web Accessibility)이란?: 장애가 있든 없든 모든 사람이 웹 사이트를 이용할 수 있도록 만드는 것
예시로 설명하면:
학습자 개개인의 다양성을 고려하여, 모두가 효과적으로 학습할 수 있도록 수업이나 콘텐츠를 설계하는 방법론
핵심은 3가지 원칙:
예시: 한 수업에서 동영상을 자막과 함께 제공하거나, 시험을 서술형뿐만 아니라 포스터 제작 등 다양한 방법으로 대체하는 것 등
screen_view 이벤트를 직접 등록해야 함page_view 이벤트는 자동 수집screen_view 이벤트는 직접 설정 필요참고 문서 : [GA4] 자동 수집 이벤트 - 애널리틱스 고객센터)
현실적으로 업무 환경에 따라 다르기에 회사마다 다릅니다. 두 문서를 동일하게 또는 다르게 사용할 수 있습니다.
다만 <u>각 기능의 정책, 세부 내용, 개발 요건 등을 상세하게 기술하여 기능이 어떻게 구현되는지 정리하는 문서</u>라는 점에서 보편적으로 두 문서의 작성항목은 동일하다고 볼 수 있습니다
보편적으로 포함되는 내용은 크게 다음과 같습니다. 작성자, 프로젝트 성격 등에 따라 작성 방법이 다양하므로 회사 내부 양식이 있는지 확인 후 포함되는 내용 추가/생략이 필요합니다.
기능 코드 : 각 기능별로 부여되는 코드로, 기능을 명확하게 식별하기 위해 필요 : 회사의 정해진 규칙을 따라 작성하며, 보통 알파벳과 숫자의 조합
Depth : 기능의 상/하위 관계를 나타내기 위해 기재
작업 요소 : 디자인, 퍼블리싱, 개발 모듈 등을 작성
구현 대상 : 웹(PC, 모바일), iOS 앱, Android 앱 등을 작성
상세 기능 정의 : 상세한 작동 방식, 규칙, 제약 조건 등 구체적인 설명 작성 : 개발자가 기능을 정확히 구현할 수 있도록 모든 세부사항을 포함
관리자 연동 유무
우선 순위
구현 상태
비고
메뉴구조도: 웹, 앱에 구성된 전체 메뉴 및 서비스를 쉽게 파악할 수 있도록 메뉴의 구조를 시각화한 문서
IA(Information Architecture, 정보구조도): 웹, 앱 구축 시 필요한 화면과 메뉴의 정보 구조를 설계 및 정의하는 문서
정보의 구조화를 통해 사용자가 화면을 마주하기까지 필요한 화면들의 흐름을 시각화하여 나타낸다. 이를 통해, 각 화면들의 연관성과 접근성을 업무별 필요한 기준으로 분류하여 웹, 앱의 큰 틀을 파악할 수 있다.
기능정의서(=기능명세서): 개발자가 실제 구현에 들어가기 전에 어떤 기능이 필요하고 어떤 식으로 구현 해야할지를 생각해보고 정리해놓은 문서
참고 자료
기획서의 버전업 기준을 설정할 때는 명확한 기준과 일관성이 중요합니다. 다음과 같은 기준을 적용하면 효율적으로 관리할 수 있습니다.
버전 구분
예시) SRS_v1.0.0: 초기 기획서 배포 SRS_v1.1.0: 신규 기능 추가 SRS_v1.1.1: 오타 및 사소한 수정
예시:
효율적 관리 방법
이러한 기준을 적용하면 기획서의 버전 관리가 체계적으로 이루어지며, 수정 및 업데이트 이력을 명확하게 정리할 수 있습니다.
반응형 규격 구분 및 기획서 작성 가이드
반응형 레이아웃 참고 링크:
결제 서비스 제공을 위한 프로덕트 파악
결제 서비스 정책 설계 전에 프로덕트의 특징을 우선적으로 고려해야합니다. 어떤 부분을 고려해야할 체크리스트 아래 브런치 참고해주세요.
결제 시스템 구조
결제 시스템을 알아야지 어떤 방식으로 결제 기능을 제공할지 더 적합한 방법을 고려할 수 있습니다.
결제 기획 시 개발자 이해
결제 관련 개발 요청 혹은 개발자와 커뮤니케이션시 참고해주세요.
각종 인앱 결제 규정
인앱 결제를 제공한다면 구글 플레이스토어완 앱스토어 결제 규정을 필수적으로 확인해야합니다.
정보성 알림은 원칙적으로 광고성 정보와 달리 별도의 명시적인 사전 동의를 받지 않아도 발송할 수 있습니다. 정보성 알림은 '영리목적 광고성 정보의 예외'로 분류되어, 특정 조건을 충족할 경우 별도의 사전 동의 없이 전송이 가능합니다.
정보통신망범에 따르면, 정보성 메시지로 인정 되는 경우는 다음과 같습니다.
푸시기획은 엑셀로 전달하셔도 좋겠습니다.
타겟유저, 내용, 타입, 전송시간, 푸시눌렀을 때 액션 등 필요한 항목들을 열로 나누어 전달하시면 될 것 같아요.
장바구니 변경 후 n시간 후” 방식으로 트리거 변경
하루 1회, 사용자 기준 발송 제한
버퍼링(지연 큐) 처리
애플 또는 구글에서 디지털 상품(게임 아이템, 구독 서비스, 전자책 등) 또는 서비스를 판매하는 경우, 해당 플랫폼의 결제 시스템을 사용해야 하며 이를 우회할 경우 앱삭제 등의 제재가 있을 수 있음.
Google Play Billing, Apple in-app purchase 를 사용
애플 및 구글 인앱 결제는 일반적으로 15~30% 정도의 수수료를 부과(연 매출에 따라 상이함)
결제 과정에서 사용자 정보를 안전하게 처리하고 보호해야함. SSL 인증서 사용, 데이터 암호화, 개인정보 보호정책 준수가 필요함.
프로모션 코드나 할인 기능을 제공할 계획이라면, 인앱결제 시 이러한 기능을 사용할 수 있는지 사전에 확인 필요
신용카드, 계좌이체, 간편 결제 등 다양한 결제 수단을 제공하는 금융 중개 업체로서 대표적으로 KG이니시스, NHN KCP, 토스페이먼츠, 나이스페이, 다날, 페이코 등이 있음. 온라인 및 모바일 결제를 처리하기 위해 가맹점(Ex. 쇼핑몰)과 카드사/은행을 연결
PG사를 사용하는데 적합한 경우
여러개의 PG사 및 간편결제 서비스를 통합하여 제공하는 결제 통합 플랫폼으로 포트원을 사용하면 단일 API로 여러 PG사 및 결제 수단을 연동할 수 있음(PG사와 직접적인 계약이 필요 없음). 여러 결제사와 일일이 계약하지 않고, 포트원을 통해 다양한 결제 수단을 간편하게 적용할 수 있음.
포트원을 사용하는데 적합한 경우
서비스 특성과 사용자 요구에 따라 요금제 변경의 적용 시점을 고려해야함. 서비스의 특성마다 모두 다름
업그레이드 시 추가 혜택을 즉시 제공할 수 없어 수익 기회가 지연될 수 있음
한국소프트웨어산업협회는 2019년까지 자격증 유무, 경력 연차 등에 따라 공식적인 등급 기준을 발표했으나, 현재는 공식 등급 체계가 존재하지 않습니다. 다만 여전히 실무에서는 다음과 같은 예전 기준이나 각 업체 내부 등급 규정을 참고해 등급을 사용하는 경우가 있습니다.
등급 경력 연차 기준 참고 단가 (월)
초급 3년 300 ~ 400만 원
중급 37년 400 ~ 550만 원
고급 7년 이상 550 ~ 700만 원
※ 위 금액은 **프리랜서 계약 기준(3.3% 원천징수 전)**으로, 커뮤니티(맥비기획톡방 등)에서 2024년 하반기에 오간 실제 사례를 기반으로 한 범위입니다. ※ 실제 단가는 프로젝트 성격(공공/민간), 난이도, 기간, 클라이언트 예산, 업무 역할 등에 따라 유동적입니다.
협회는 매년 IT 근로자 노임단가를 발표하고 있으며, 다음은 주요 직무별 2024년 기준 단가입니다.
직무 월 단가 (원) 일 단가 (원) 시간 단가 (원) IT 기획자 11,597,656 562,993 70,374 IT PM 9,145,473 443,955 55,494 UI/UX 기획·개발자 6,727,260 326,566 40,821
※ 이 단가는 공공 프로젝트 기준으로, 나라장터 입찰 등에서 참고 자료로 사용됩니다. ※ 민간 프로젝트에서는 이보다 낮거나 높은 단가로 협의가 이뤄질 수 있습니다. ※ 계약 당사자 간의 합의에 따라 월 단가 고정 계약 방식도 일반적입니다.
질문자가 이 방법으로 실행 해봤음에도 질문 했을 경우를 대비해 추가 설명을 드립니다.
구글 계정으로 연결 로그인 했을경우, 크롬에 구글 아이디가 로그인 상태라면, 타인이 figma 로그인이 가능한데 이것을 해결하기 원할 경우, 구글 계정에서는 다음과 같이 다른 기기에서 로그아웃할 수 있습니다:
사용자 식별 기준: 'sub' 값 사용 (Google의 고유 사용자 ID, 불변) ※ DB에는 자체 user_id를 기본키로 사용하고, 'sub' 값은 별도 매핑 테이블로 관리하는 것이 안전함
수집 가능한 사용자 정보 sub, email, name, picture (기본 제공, 별도 동의 불필요)
중복 가입 처리 동일 이메일 존재 시 "기존 계정이 존재합니다. 간편 로그인을 연결하시겠습니까?"와 같은 UX 제공 필요. 이메일 기준 매핑 또는 사용자 확인 후 병합 여부 결정. 기획서에 병합 정책 명시 권장
세션 및 토큰 관리: access_token 약 1시간 유효, refresh_token 발급 시 access_type=offline 설정 필요. 서비스 자체 세션(JWT 또는 쿠키 등)으로 로그인 유지 필요
보안 고려사항 HTTPS 필수, access_token은 클라이언트 저장 금지, refresh_token은 서버에만 저장. PKCE 사용 권장, Client Secret 노출 금지
기획서 포함 필수 항목
로그인 흐름 : 로그인 버튼 클릭 → Kakao OAuth 인증 → 카카오톡 앱 인증 또는 계정 로그인 → 동의 화면 표시 → Access Token 수신 및 사용자 정보 API 호출 → 회원가입 또는 로그인 처리 → 세션 및 토큰 저장
사용자 식별 기준 : 'id' 값 사용 (Kakao 고유 사용자 ID, 숫자형, 앱 단위로 고정) ※ DB에는 자체 user_id를 기본키로 사용하고, 'id' 값은 별도 매핑 테이블로 관리 권장
수집 가능한 사용자 정보:
세션 및 토큰 관리 access_token 약 6시간 유효, refresh_token은 약 30일 이상 (기기 단위). -> 서비스 자체 세션(JWT 또는 쿠키 등)으로 로그인 유지 필요
보안 고려사항: HTTPS 필수, access_token/refresh_token은 서버에만 저장, 클라이언트 저장 금지. 연동 해제 시 unlink API 호출 필요. 카카오싱크 도입 시 데이터 연동 범위 확대 가능
기획서 포함 필수 항목: 지원 SNS는 Kakao, 사용자 식별 키는 id, 동의 항목 구분(기본/선택), 로그인 vs 회원가입 분기 처리 기준, 이메일 중복 병합 정책 및 UX, 세션 유지 및 토큰 갱신 정책, 연동 해제 처리 흐름 및 unlink API, 보안 정책(HTTPS, 서버 저장 방식 등), 예외 처리(카카오톡 미설치, 선택 동의 거부 등) 카카오 디벨로퍼 사이트
전자상거래 등에서의 소비자보호에 관한 법률 시행령에 서비스를 무료에서 유료화로 전환 할 경우, 고객에게 안내해야 하는 방법을 고지하고 있다.
제20조의2(정기결제 대금이 증액되거나 유료 정기결제로 전환되는 경우 소비자 동의ㆍ고지 기간)에 따르면, <u>정기결제 대금이 증액되거나 유료 정기결제로 전환되기 전 30일 이전에 고지</u>해야 합니다.
상장사: 👉 전자공시시스템(DART)에서 ‘사업보고서’ 또는 ‘반기보고서’ 확인 => 오른쪽 링크 참조 👉 손익계산서 섹션에서 당기순이익/영업이익 체크
비상장사: 👉 국세청에 등록된 사업자라면 ‘기업정보조회사이트’ 또는 ‘딥서치’, ‘CEO스코어’, 등에서 일부 확인 가능 => 오른쪽 링크 참조 👉 중소기업청이나 중소기업중앙회 등에도 기본 정보 제공
유료 서비스
최근 트렌드에서는 AARRR보다 RARRA 구조(관계 중심)도 주목받지만, 극초기 서비스에서는 여전히 AARRR이 실험 설계에 유용한 것으로 보임. 따라서 AARRR 기반으로 설명함.
초기 제품이나 MVP의 사용자 흐름을 퍼널로 구조화해서 유입부터 전환, 확산, 수익화까지 단계적으로 실험하고 지표를 추적하는 프레임워크.
① 사업자는 전자상거래 및 통신판매에서의 표시ㆍ광고, 계약내용 및 그 이행 등 거래에 관한 기록을 상당한 기간 보존하여야 한다. 이 경우 소비자가 쉽게 거래기록을 열람ㆍ보존할 수 있는 방법을 제공하여야 한다.
② 제1항에 따라 사업자가 보존하여야 할 거래기록 및 그와 관련된 개인정보(성명ㆍ주소ㆍ전자우편주소 등 거래의 주체를 식별할 수 있는 정보로 한정한다)는 소비자가 개인정보의 이용에 관한 동의를 철회하는 경우에도 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」등 대통령령으로 정하는 개인정보보호와 관련된 법률의 규정에도 불구하고 이를 보존할 수 있다. → 따라서 현재 전자상거래법상 거래기록의 보존 의무가 있으나, 이를 사업자가 본인인증 의무를 부여하는 것으로 해석하기는 어려움. → 19세 미만 사용자 (청소년) 에 대해서는 법적 보호와 연령 기반 접근 제어를 위해 본인인증이 더욱 중요하게 적용됨. (보호자 동의 절차가 포함되는 경우도 있음)
본인인증은 시스템에 정당한 사용자가 접근했는지를 확인하는 절차로, 서비스 보안과 사용자 정보 보호를 위해 필수적으로 고려되어야 함. 단, 서비스의 목적과 민감도에 따라 인증 절차의 적용 필요 여부 및 수준을 합리적으로 판단하는 것이 중요.
본인인증 : ‘사용자가 진짜 본인이 맞는지?’ 확인하는 절차이며, 실명기반으로 법적 효력이 필요한 경우 본인인증을 필수로 진행
본인인증 특징
점유인증 : ‘사용자가 특정기기를 소지하며 있고 실제로 사용하고 있는지?’ 일회성으로 확인하는 절차이며, 개인정보 외에 해당 PC/모바일 기기를 물리적으로 갖고있거나 접근이 가능한지 증명하는 방식
점유인증 특징 → 인증하는 과정에서 실명확인은 생략 → 현재는 본인인증 + 생체 점유인증 조합으로 활용하여 2단계 인증을 구성하는 추세
인증 구현 방식
약관 동의 및 개인정보 수집 구조 UX/UI 설계
본인인증 프로세스 설계
가입 완료 후 데이터 연동 및 보안 강화
CI/ DI의 차이점
FedCM(Federated Credential Management)은 Chrome v120 이상에서 Google 로그인을 지원하는 방식으로, 기존 gapi.auth2 방식은 2025년 종료 예정입니다. 브라우저가 계정 선택 UI를 직접 렌더링하며, 3rd-party 쿠키 없이 작동해 보안성과 프라이버시를 강화합니다. Safari, Firefox 등은 아직 지원하지 않으므로 fallback 구조가 필요합니다. Google 로그인 플랫폼 라이브러리는 2025년 8월부터 FedCM API를 필수 채택합니다.
외주 사용 여부는 회사의 SEO 목표 수준과 내부 리소스에 따라 달라집니다.