2025년 AI 도구 순위 (필수 툴부터 아쉬운 툴은?)

S 등급

• Perplexity: 구글 검색을 대체, 정확한 결과와 검증 가능한 출처를 제공
• ChatGPT: 빠른 질문 답변, 음성 상호 작용, 기본 데이터 분석에 유용
• Claude: 글쓰기 및 편집에 가장 좋음

A 등급

• Superwhisper: 음성 메모를 맥락에 맞는 텍스트 문장으로 변환
• RiversideFM: 팟캐스트 제작 시 무음 구간 제거, 오디오 편집 등 편리한 기능을 제공
• v0: Figma와 연동하여 목업을 픽셀 단위로 완벽한 프로토타입으로 만들어 줌
• Cursor: 코딩 지식이 부족한 사람도 쉽게 코딩할 수 있도록 도움
• Copilot : 전통적인 코드 자동완성에 강점

B 등급

• Suno: 노래 창작에 특화된 도구
• HeyGen: 가상 인물 영상 제작 및 다국어 음성 변환에 활용
• Websim: 텍스트 아이디어를 웹사이트로 빠르게 변환
• Grok: 간단한 이미지 생성에 유용하며, 무료로 사용 가능.
• Playground AI: 로고 및 소셜 미디어 디자인에 가장 좋음.
• Napkin AI: 텍스트 기반 인포그래픽 제작에 유용
• Granola: 회의록 작성에 도움.
• Zapier AI: AI 자동화 기능은 강력하지만, UX 다소 불편
• Elevenlabs:  텍스트 음성 변환 및 음성 복제에 뛰어남
• Runway: 텍스트 프롬프트를 기반으로 짧은 비디오 제작
• NotebookLM: 텍스트를 10분 분량의 팟캐스트로 변환하는 데 유용

C 등급

• Figma AI: 기능이 부족함. 디자인을 프로토타입으로 바꾸는 기능 대신 레이어 이름 바꾸기 같은 기본적인 작업에 집중
• Poe: 모든 것을 평범하게 하려고 함. 최고의 AI 모델에 접근할 수 있다는 장점이 있지만, UX가 불편하고 ChatGPT Voice나 Claude Artifacts 같은 주요 기능이 없음
• Gemini: LLM 모델 중 3위. ChatGPT나 Claude보다 성능이 떨어짐
• Grammarly: 제안이 문장의 의미를 완전히 바꾸는 경우가 있어 일관성이 부족함

D 등급

• Apple Intelligence: 평이 좋지 않음. 메시지 요약 기능이 핵심을 놓치는 경우가 많음
• Gemini for Google Workspace: AI 기능이 유용하지 않음. 이메일 초안 작성, 문서 요약, 배경 생성 등의 기능이 AI의 장점을 제대로 활용하지 못함

핵심 비교 요약

1. GA4 (Google Analytics 4) 분석 관점 : 세션 중심 + 이벤트 기반 핵심 대상 : 마케터, 웹사이트 관리자 리텐션 분석 : 제한적 (설정 복잡) 퍼널 분석 : 가능 (하지만 불편) 코호트 분석 : 일부 지원 데이터 모델 : 이벤트+세션 혼합 쿼리 기능 : 탐색 기능 제한적 외부 연동 : BigQuery, G Ads 등 강력 가격 : 무료 (유료 플랜 있음) 적용대상: PC+모바일 모두
2. Amplitude 분석 관점 : 이벤트 기반 + 사용자 여정 핵심 대상 : PO, 기획자, PM 리텐션 분석 : 매우 강력 퍼널 분석 : 직관적, 시각화 우수 코호트 분석 : 강력 데이터 모델 : 완전 이벤트 기반 쿼리 기능 : Custom Formula & SQL 유사 UI 외부 연동 : Segment, Snowflake 등과 연동 가격 : 무료(제한) + 유료 플랜 적용대상: PC+모바일 모두(앱에 강점)
3. Mixpanel 분석 관점 : 이벤트 기반 + 전환 최적화 핵심 대상 : PO, PM, 마케터 리텐션 분석 : 강력 퍼널 분석 : 직관적, 실시간 가능 코호트 분석 : 강력 데이터 모델 : 완전 이벤트 기반 쿼리 기능 : Custom Query Builder 외부 연동 : 다양한 SaaS 연동 가격 : 무료(제한) + 유료 플랜 적용대상: PC+모바일 모두

가격 및 정책

1. GA4 기본 가격 : 무료 유료 기능 : GA360 (고가) 예산 민감 기업에 적합 : ✅
2. Amplitude 기본 가격 : 무료(10M events/월) 유료 기능 : Growth / Enterprise 플랜 예산 민감 기업에 적합 : ⚠️ (규모 따라 비용 증가)
3. Mixpanel 기본 가격 : 무료(20M events/월) 유료 기능 : Growth / Enterprise 플랜 예산 민감 기업에 적합 : ⚠️

요약

• 광고 & 유입 분석 + 무료 우선 : GA4
• 기능 단위 사용자 행동 분석 : Amplitude
• 리텐션과 전환 퍼널 최적화 : Mixpanel
• 데이터 내보내기(BigQuery 연동) : GA4
• UX 개선 등 실시간 실험 기반 분석 : Amplitude (Experiment)

페르소나 개념 및 설정 방법

1. 정의

페르소나는 서비스 사용자의 대표적인 특징을 가진 '가상의 인물'입니다. 막연한 사용자 대신 실제처럼 느껴지는 인물을 통해 공감과 문제 정의가 쉬워집니다.

1) 왜 중요한가

• 사용자 중심 사고 가능
• 니즈와 문제점 명확화
• 의사결정 기준 제공
• 타겟 사용자 집중 가능

2) 설정 방법

a. 데이터 수집 및 분석

• 설문조사, 인터뷰, 행동로그 분석 등
• 클러스터/요인 분석으로 세그먼트 도출

b. 페르소나 프로필 작성

• 인구통계학적 정보(성별, 나이, 직업, 연봉 등)
• 심리·행동 특성(목표, 고민, 라이프스타일 등)
• 예시 질문
  어디에 살까?
  성별은?
  직업은?
  연봉은?
  가족 관계는?
  주로 즐기는 취미는?
  평소 고민이나 불안한 점은?
  꿈이나 목표는?
  가치관은?
  평일/주말의 라이프스타일은?

c. 유사 인물 탐색

• 유튜브, 커뮤니티, AI 등을 통해 유사 사용자 이해

d. 일상 시뮬레이션

• 하루 동선을 시각화하여 사용할 매체 및 메시지 탐색
  ex) 아침~저녁 동선 따라 노출 매체 상상

e. 활용

• 기획 시 디자인/기능 판단 기준
• 마케팅 시 채널 및 메시지 설계 기준

2. 진행중인 프로젝트에 적용해보기

• 타겟 서비스 : 초등학생을 위한 **AI 기반 학습 지원 챗봇" 개인화된 학습 도우미 학생이 "구석기 시대가 뭐야?"와 같은 질문을 입력하면, AI가 아이 수준에 맞는 개념 설명과 시각 자료, 추가 학습 키워드를 제공
• 페르소나 예시보기

프로젝트 수행 전에 세운 가설과 지표, 이를 검증할 수 있는 데이터가 무엇인지에 따라 수집해야하는 값이 상이합니다.

페이지 사용성을 검토할 때, 유입 & 이탈 데이터(페이지뷰, 유입 경로, 이탈률, 체류 시간)로 전반적인 관심도를 파악하고, 인터랙션 데이터(클릭 이벤트, 스크롤 깊이, CTA 클릭률)로 사용자 행동을 분석해야 합니다. 또한, 전환 데이터(전환율, 폼 이탈률, 에러 발생)와 사용자 행동 흐름(사용 경로, 세션 리플레이)을 추적하여 UX를 최적화할 수 있습니다.

• Mixpanel, Hotjar, GA4 - 가이드
• pxd 데이터로 현상을 파악하기 https://story.pxd.co.kr/1591
• PM을 위한 데이터 리터러시 https://zzsza.github.io/data-for-pm/

1. 데이터 수집 방식 차이

웹사이트

• JavaScript 기반의 트래킹 코드 사용 (gtag.js 또는 Google Tag Manager)
• URL이 바뀌면 자동으로 페이지뷰 수집
• 세션은 브라우저 탭 기준으로 유지되며, 비활성화 시 종료

모바일 앱

• Firebase SDK 설치 필요 (iOS/Android 전용)
• 화면 전환 시 screen_view 이벤트를 직접 등록해야 함
• 앱은 백그라운드로 전환 후 일정 시간 내 재실행 시에도 세션 유지

2. 구현 방식 차이

웹사이트

• 트래킹 코드 삽입만으로 대부분의 기본 이벤트 자동 수집 가능
• 코드 수정 시 바로 반영 가능 (배포 필요 없음)

모바일 앱

• Firebase SDK 연동 및 이벤트/스크린 트래킹 수동 설정 필요
• 앱 빌드 후 배포해야 수정사항이 반영됨 (딜레이 존재)

3. 측정 지표 및 용어 차이

웹사이트

• page_view 이벤트는 자동 수집
• 사용자 식별은 쿠키 기반(Client ID)
• 전환 이벤트는 GA4에서 정의 가능
• 사용자 유지율은 재방문 위주로 측정

모바일 앱

• screen_view 이벤트는 직접 설정 필요
• 사용자 식별은 App Instance ID 또는 User ID 기반
• 앱 설치, 인앱 구매 같은 앱 특화 전환 지표 활용 가능
• 'first_open'이라는 최초 앱 실행 지표를 주로 사용 (원인은 Google Play Console(AOS)이나 iTunesConnect(iOS)에서 안내되는 순수 다운로드 횟수가 가장 정확) 추가로 iOS의 경우 iOS 14 앱 추적 프롬프트를 수락하는 사용자에 한해서 'first_open' 주요 이벤트 측정을 지원
• 사용자 유지율은 리텐션, 세션 빈도, 구매 행동 등 중심

4. Firebase 연동 필요성 (앱 전용)

• 앱은 Firebase Analytics와 연동 필수
• Firebase에서 수집된 데이터가 GA4로 자동 연동됨
• Firebase SDK 설치 → GA4 속성 연결 → 데이터 통합 분석 가능

5. 활용 시나리오 예시

웹사이트

• 유입 채널 및 페이지 유입 분석
• 버튼 클릭, 회원가입, 결제 완료 등의 전환 추적
• 장바구니 → 결제 → 완료 같은 퍼널 흐름 분석

모바일 앱

• 앱 설치 채널, 앱 열기 경로 분석
• 특정 화면 방문, 인앱 구매 등 이벤트 추적
• 앱 내 사용자 흐름 또는 행동 단계별 퍼널 분석

참고 문서 : [GA4] 자동 수집 이벤트 - 애널리틱스 고객센터)

1. 법·규제 관련 체크

멤버십은 단순 구독모델과 달리 혜택·데이터·결제·광고가 얽히기 때문에, 국내 규제 고려가 필수입니다.

• 개인정보보호법 / 정보통신망법 : 회원 가입 시 최소 수집 원칙, 동의 절차, 제3자 제공 고지 의무. 특히 멤버십 혜택으로 제휴사가 관여하는 경우 개인정보 제3자 제공 동의 필요.

• 전자상거래법 / 소비자보호법 유료 멤버십(구독형)은 ‘청약철회(환불)’ 규정을 따라야 함. 결제 전 취소/환불 정책을 명확히 고지해야 하고, 자동 결제 갱신 시에는 재결제 안내 고지 필수.

• 표시광고법 / 공정거래위원회 고시 멤버십 혜택(예: “최대 50% 할인”) 표시 시 실제 적용 조건을 명확히 표기해야 함. 과장 광고나 미표시 시 과징금 위험.

• 통신사/PG사 관련 규정 정기결제 인앱결제(IAP)와 외부 결제 규정(구글/애플 정책 vs 자체결제) 통신사 소액결제 시 한도, 청소년 결제 제한 고려.

2. 국내 성공 사례 참고

대한민국에서는 이미 다양한 멤버십 모델이 자리 잡았어요. 성공 포인트를 참고하면 좋아요.

• 쿠팡 로켓와우 멤버십 : 무료배송, 새벽배송, 쿠팡플레이 같은 생활+콘텐츠 번들링 전략.

• 네이버 플러스 멤버십 : 네이버페이 포인트 적립, 웹툰·뮤직·클라우드 연계. 결제 생태계 락인(lock-in)을 통한 재방문/재구매 유도.

• SKT T멤버십 → 우주패스/Universe : 통신료+구독 번들 (넷플릭스, 디즈니+, 배달 앱 할인). 제휴사 묶음 제공이 핵심.

• 스타벅스 리워드 : 포인트 기반 멤버십으로 충성 고객 확보. 모바일앱 적립·결제 통합 성공사례.

3. 기획 관점에서 체크리스트

• 멤버십 서비스 기획 시 한국 시장에서는 특히 아래를 점검해야 합니다.

  • 가입 장벽 설계
  • 무료 vs 유료 (예: 무료 멤버십 → 기본 혜택, 유료 멤버십 → 프리미엄 혜택)

• 가입 채널(앱 내 / 제휴사 앱 / 통신사 연동)

  • 혜택 구성
  • 할인/적립 : 국내 사용자는 “현금성 포인트” 선호.
  • 콘텐츠 : OTT, 웹툰, 음원, 전자책, 배달 등 생활밀착형 번들 강세.
  • 전용 서비스 : 우선 예약, 전용 고객센터, 이벤트 초대 등.

• 가격 정책

  • 한국 사용자는 월 4,900원~9,900원 구간에 가장 민감하게 반응.
  • 연간 결제 시 1~2개월치 무료 혜택 제공이 흔한 전략.

• 해지/환불 정책

  • 첫 달 무료 → 자동 결제 고지 필수.
  • 환불/부분 환불 정책을 명확히 공지해야 민원 방지.

• CRM·푸시 운영

  • 혜택 리마인드 알림 필수 (예: “남은 쿠폰 2장 사용하세요”).
  • 비로그인 사용자에게 푸시/CRM 불가하므로 로그인 전환 전략 선행 필요.

• 공정거래위원회 "전자상거래 등에서의 소비자보호지침" (유료 구독/멤버십 환불 관련)

• 개인정보보호위원회 가이드라인 (마케팅 동의 및 제휴사 데이터 제공 관련)

• KISDI(정보통신정책연구원) 보고서 : 한국의 구독경제/멤버십 시장 현황

• 산업연구원(KIET) 트렌드 보고서 : OTT, 커머스 멤버십 비교 분석

1. 챗봇 기획 개요 작성

   • 챗봇으로 해결할 문제, 필요한 기능 등 챗봇의 주요 역할을 명확하게 기재함
   • 챗봇 배포 위치 선정 (예. 웹사이트, 앱, 메신저 등)

2. 챗봇 플랫폼 선택

   • 카카오톡 챗봇
   • 채널톡

3. 시나리오 설계 (1) 환영인사, 공지사항, 프로모션 안내, 운영시간 등 표기 (2) 선택할 수 있는 카테고리 제공 (예. 제품 문의, 상품 추천 등) (3) 카테고리별로 답변 및 버튼 연결

4. 배포 이후 운영 개선

   • 사용자 피드백과 데이터를 분석하여 지속적으로 개선

1) iOS/AOS 결제 정책 준수

애플 또는 구글에서 디지털 상품(게임 아이템, 구독 서비스, 전자책 등) 또는 서비스를 판매하는 경우, 해당 플랫폼의 결제 시스템을 사용해야 하며 이를 우회할 경우 앱삭제 등의 제재가 있을 수 있음.

Google Play Billing, Apple in-app purchase 를 사용

2) 인앱 결제 수수료

애플 및 구글 인앱 결제는 일반적으로 15~30% 정도의 수수료를 부과(연 매출에 따라 상이함)

3)보안 및 개인정보 보호

결제 과정에서 사용자 정보를 안전하게 처리하고 보호해야함. SSL 인증서 사용, 데이터 암호화, 개인정보 보호정책 준수가 필요함.

4) 프로모션 및 할인 기능 고려

프로모션 코드나 할인 기능을 제공할 계획이라면, 인앱결제 시 이러한 기능을 사용할 수 있는지 사전에 확인 필요

1. 플랫폼별 정책과 가이드라인 준수
2. 디바이스 특화 기능 활용 - GPS, 카메라, 마이크, 푸시 알림 등
3. 권한 동의 및 개인정보 보호 - 알림, 이미지 접근, 위치 정보 등
4. 업데이트 및 버전 관리 - 이전 버전과의 호환성을 고려하여 기획
5. 사용자 여정(User Journey)과 온보딩 전략

• 앱 기획 시 단순히 기능 나열이 아니라, 사용자가 언제, 어떤 흐름으로 앱을 쓰게 될지 구체적으로 설계해야 함
• **첫 사용자 경험(FTE)**이 앱 이탈률을 결정함 → 온보딩 튜토리얼, 가입 유도 흐름, 첫 화면의 설득력 등을 고려. 자주 사용하는 기능은 접근성 중심으로 배치

6. 접근성 및 UX 가이드 준수

• 텍스트 크기, 색상 대비, 음성 읽기(Screen Reader), 터치 영역 등 → 시각/청각/운동 능력이 다르더라도 앱을 사용할 수 있도록
• 특히 iOS는 접근성 기능 연동 여부도 심사 포인트로 봄

7. 데이터 수집 및 지표 설계

• 어떤 데이터를 앱에서 수집할 것인가?
• 이벤트 트래킹, 전환율, 이탈률, 버튼 클릭률 등
• 추후 서비스 개선을 위한 데이터 기반 설계 필요
• 하이테크소프트웨어
• 브런치 검색

1. [본인 인증]과 [SNS 간편 로그인] 비교 정리

1) 목적

• 본인 인증: 실명 확인 및 법적으로 유효한 행위 수행을 위해 사용
• SNS 간편 로그인: 사용자가 별도 회원가입 없이 계정을 빠르게 연동하여 로그인할 수 있도록 함

2) 제공 주체

• 본인 인증: 통신사, 금융기관, 인증기관(KISA, NICE 등)과 같은 공식 기관
• SNS 간편 로그인: 카카오, 네이버, 구글, 페이스북 등 포털 또는 SNS 플랫폼

3) 인증 수단

• 본인 인증: 휴대폰 본인 인증, 공동인증서, PASS 앱 등
• SNS 간편 로그인: OAuth 기반의 계정 인증 방식

4) 법적 효력

• 본인 인증: 주민번호 기반 실명 확인이 가능하며, 전자서명법 상의 인증으로 법적 효력 존재
• SNS 간편 로그인: 실명 확인은 불가하고, 단순 로그인 수단으로만 활용됨 (법적 효력 없음)

5) 활용 예시

• 본인 인증: 정부24, 온라인 금융 서비스, 성인 인증 등 실명 기반 서비스
• SNS 간편 로그인: 쇼핑몰 회원가입, 커뮤니티 이용, 간편 앱 가입 등

2. 회원가입 시 본인인증은 필수?

전자상거래법 제6조 (거래기록의 보존 등)

① 사업자는 전자상거래 및 통신판매에서의 표시ㆍ광고, 계약내용 및 그 이행 등 거래에 관한 기록을 상당한 기간 보존하여야 한다. 이 경우 소비자가 쉽게 거래기록을 열람ㆍ보존할 수 있는 방법을 제공하여야 한다.

② 제1항에 따라 사업자가 보존하여야 할 거래기록 및 그와 관련된 개인정보(성명ㆍ주소ㆍ전자우편주소 등 거래의 주체를 식별할 수 있는 정보로 한정한다)는 소비자가 개인정보의 이용에 관한 동의를 철회하는 경우에도 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」등 대통령령으로 정하는 개인정보보호와 관련된 법률의 규정에도 불구하고 이를 보존할 수 있다. → 따라서 현재 전자상거래법상 거래기록의 보존 의무가 있으나, 이를 사업자가 본인인증 의무를 부여하는 것으로 해석하기는 어려움. → 19세 미만 사용자 (청소년) 에 대해서는 법적 보호와 연령 기반 접근 제어를 위해 본인인증이 더욱 중요하게 적용됨. (보호자 동의 절차가 포함되는 경우도 있음)

본인인증은 시스템에 정당한 사용자가 접근했는지를 확인하는 절차로, 서비스 보안과 사용자 정보 보호를 위해 필수적으로 고려되어야 함. 단, 서비스의 목적과 민감도에 따라 인증 절차의 적용 필요 여부 및 수준을 합리적으로 판단하는 것이 중요.

3. 본인인증 vs 점유인증, 차이점 알아보기

본인인증 : ‘사용자가 진짜 본인이 맞는지?’ 확인하는 절차이며, 실명기반으로 법적 효력이 필요한 경우 본인인증을 필수로 진행

본인인증 특징

• 외부 인증기관과의 연동
• 실명 정보 기반으로 DB 대조하여 인증

2. 본인인증 API 제공 회사

• NICE 평가정보
• 한국모바일인증 (KMC)
• 다날
• 드림시큐리티
• KG 모빌리언스

점유인증 : ‘사용자가 특정기기를 소지하며 있고 실제로 사용하고 있는지?’ 일회성으로 확인하는 절차이며, 개인정보 외에 해당 PC/모바일 기기를 물리적으로 갖고있거나 접근이 가능한지 증명하는 방식

1. 점유인증 특징 → 인증하는 과정에서 실명확인은 생략 → 현재는 본인인증 + 생체 점유인증 조합으로 활용하여 2단계 인증을 구성하는 추세

2. 인증 구현 방식

• 사용자 기본정보 입력: 이름, 생년월일, 성별, 통신사, 전화번호 등 입력
• 인증 요청 전송: 서버에서 무작위로 임시 인증코드 생성 및 1회성 인증번호(SMS,카카오톡 등)가 발송
• SMS 전송: SMS 및 카카오톡 메시지 발송 API(KT, LG U+, 알림톡, 토스트 등)를 통해 인증번호 전송
• 입력 검증 절차: 사용자가 인증번호 입력 → 서버에서 임시 저장된 값과 비교 → 일치 시 인증 성공 처리
• 인증 처리 결과 : 코드가 일치하고 시간내에 기입했을 경우 성공 처리 및 성공 여부에 따라 다음 프로세스(예: 로그인 성공, 비밀번호 재설정)로 연결 : 반환된 인증번호 식별값은 회원가입, 로그인, 중복 가입 방지 등의 로직에 활용

4. 회원가입/본인인증 프로세스에서 기획자의 역할 ~ 기획자의 핵심 역할 ~ 가입 전환율을 높이되, 사용자에게 인증하는 과정을 간소화하여 부담을 최소화하고, 본인인증을 통해 보안과 법적 요건을 충족하는 흐름을 만들어내는 것.

1. 회원가입 수단 및 인증 방식 정의

• 서비스 특성과 법적 요건에 따라 가입 방식을 명확히 정의.
  : 예를 들어, 금융·헬스케어 등 민감 정보를 다루는 서비스는 본인인증을 필수로 적용
• 외부 인증 수단 도입 검토 및 벤더사(예: KCB, NICE 등) 선정 업무를 수행.
• 인증번호 발송, 유효 기간, 재시도 횟수 제한 등 인증 절차 구체화 및 인증 실패 및 재시도 정책, 보안 취약점 대응 방안 마련. → 사용자 경험(UX) 설계 과정 필요.

2. 약관 동의 및 개인정보 수집 구조 UX/UI 설계

   • 서비스 이용 약관과 개인정보 수집 동의 절차를 UI상에 반영하여 설계.
   • 전체 동의, 개별 동의, 펼침·접기 기능 등을 포함하여 사용자 편의성을 극대화.
   • 이용자의 선택권을 보장하는 UX 설계를 통해, ex) 선택 약관 체크 해제 시에도 회원가입이 가능하도록 프로세스 구축.

3. 본인인증 프로세스 설계

   • 외부 인증 모듈(API) 연동에 필요한 요구사항을 도출하고, 안정적인 연동 방안을 설계.
   • 서비스 유형에 맞는 인증 방식에 따라 본인인증 필요 여부를 파악 후 서비스 정책 설계.
   • 유지보수와 확장성을 고려한 재사용성 높은 인증 플로우를 설계함으로써, 향후 인증 수단 추가 및 변경에 유연하게 대응.

4. 가입 완료 후 데이터 연동 및 보안 강화

   • 회원 정보 저장, 외부 인증 시스템 API 연동 및 데이터 암호화 규약 문서화하여 접근 권한 관리 정책을 수립.
   • 자동 로그인, 온보딩 프로세스 등 사용자 후속 동선 설계

5. 본인인증 제공 정보 특이사항

1. CI (Connecting Information)
   • 동일인의 식별을 위한 암호화 고유값. 플랫폼 간 사용자 연동 가능.
   • 주민번호와 같이 사람에 주어지는 고유 값이므로 다른 플랫폼간 회원 매칭 또는 회원 중복 여부 체크용으로 사용하며, 금융권에서는 사실상 필수값으로 쓰임.
2. DI (Duplication Information)
   • 중복 가입 방지용 암호화 ID.
   • 특정 서비스에 한정하여 동일값으로 제공됨.
   • 타 플랫폼, 서비스 간 모두 다른 값이므로 상호 비교는 어렵고, 동일 서비스 내 재가입 체크 용도로 쓰임.

• KISA 및 통신사 연동으로 제공되며, 전자서명법 및 정보통신망법의 보호 대상임.
• CI와 DI의 차이점 ※ CI/DI는 주민등록번호를 대체하는 비식별 고유값이므로 보안등급이 높음. [전자상거래법 제6조 (거래기록의 보존 등)]

CI/ DI의 차이점

일반적으로는 관리자용 앱도 별도의 약관 및 개인정보처리방침을 갖추는 것이 원칙입니다. 해당 앱에서 처리되는 정보의 주체, 목적, 범위가 다르기 때문입니다.

항목 기준 구분

1. 주요 사용자 고객용 앱 : 일반 사용자, 국민 관리자용 앱 : 관리자(직원), 프리랜서
2. 수집 정보 고객용 앱 : 이름, 연락처, 이용 기록 등 관리자용 앱 : 위치, 업무 수행 데이터, 계약 정보 등
3. 이용 목적 고객용 앱 : 서비스 제공 관리자용 앱 : 운영 관리, 업무 수행, 모니터링 등
4. 약관 필요 여부 고객용 앱 : 필수 관리자용 앱 : 권장 (사실상 필수)

요약 고객앱 약관으로 관리자앱까지 포괄하는 것은 위험하며, 운영목적과 정보 수집 목적이 다르므로 반드시 별도 문서가 필요합니다.

참고 사례

• 쿠팡이츠: 배달파트너 전용 앱에 별도 약관 및 개인정보 처리방침 존재
• 배민커넥트: 라이더 앱 내 ‘커넥터 약관’, ‘위치정보 이용 동의’ 별도 제공

푸시 발송과 관련된 개인정보 처리 방침의 출처는 주로 정보통신망 이용촉진 및 정보보호 등에 관한 법률과 개인정보 보호법입니다.

1) 정보통신망 이용촉진 및 정보보호 등에 관한 법률

• 광고성 정보 전송 시 수신자의 사전 동의를 요구하며, 이를 위반할 경우 과태료가 부과될 수 있습니다.
• 참고 조항
  • 제50조: 영리목적의 광고성 정보 전송 시 수신자의 명시적인 사전 동의를 요구합니다
  • 제50조의4항: 광고성 정보 전송 시 전송자 명칭, 수신거부 방법 등을 명확히 표기해야 합니다
  • 제62조의3: 수신동의 확인 후 14일 이내 통지하지 않을 경우 과태료가 부과될 수 있습니다

2) 개인정보 보호법

• 개인정보의 수집, 이용, 제공에 대한 기준을 정하고 있으며, 정보주체의 동의를 기반으로 개인정보를 처리해야 합니다.
• 참고 조항
  • 제15조: 개인정보의 수집 및 이용은 정보주체의 동의를 기반으로 하며, 동의 시에는 수집 목적, 항목, 보유 기간 등을 명확히 고지해야 합니다
  • 제20조의2: 개인정보의 수집·이용 목적, 항목, 보유 기간 등을 정보주체에게 통지해야 합니다

1. 로그인 흐름 : 로그인 버튼 클릭 → Kakao OAuth 인증 → 카카오톡 앱 인증 또는 계정 로그인 → 동의 화면 표시 → Access Token 수신 및 사용자 정보 API 호출 → 회원가입 또는 로그인 처리 → 세션 및 토큰 저장

2. 사용자 식별 기준 : 'id' 값 사용 (Kakao 고유 사용자 ID, 숫자형, 앱 단위로 고정) ※ DB에는 자체 user_id를 기본키로 사용하고, 'id' 값은 별도 매핑 테이블로 관리 권장

3. 수집 가능한 사용자 정보:

• 필수 : id (기본),이메일, 프로필 사진
• 선택 등의 : 성별, 연령대, 생일, 출생년도, 카카오계정(전화번호), 배송지 정보 (수령인명, 배송지 주소, 전화번호) , CI(연계정보, 비교만 가능),

4. 중복 가입 처리

• 동일 이메일 존재 시 병합 알림 UX 제공 필요 ("기존 계정이 존재합니다. 간편 로그인을 연결하시겠습니까?" 등).
• 이메일 기준 매핑 또는 사용자 확인 후 병합 여부 결정. 기획서에 병합 정책 명시 권장

5. 세션 및 토큰 관리 access_token 약 6시간 유효, refresh_token은 약 30일 이상 (기기 단위). -> 서비스 자체 세션(JWT 또는 쿠키 등)으로 로그인 유지 필요

6. 보안 고려사항: HTTPS 필수, access_token/refresh_token은 서버에만 저장, 클라이언트 저장 금지. 연동 해제 시 unlink API 호출 필요. 카카오싱크 도입 시 데이터 연동 범위 확대 가능

7. 기획서 포함 필수 항목: 지원 SNS는 Kakao, 사용자 식별 키는 id, 동의 항목 구분(기본/선택), 로그인 vs 회원가입 분기 처리 기준, 이메일 중복 병합 정책 및 UX, 세션 유지 및 토큰 갱신 정책, 연동 해제 처리 흐름 및 unlink API, 보안 정책(HTTPS, 서버 저장 방식 등), 예외 처리(카카오톡 미설치, 선택 동의 거부 등) 카카오 디벨로퍼 사이트

1. 워치OS / Wear OS의 UX·기능 제약 이해

• 워치는 화면이 작고, 입력 방식(터치/버튼/음성)이 제한적 → 핵심 기능만 간결하게 보여줘야 함

• 기획자는 "이건 진짜 워치에서 필요한가?"를 반복해서 자문해야 함

• 예시: 알림 확인, 빠른 응답, 헬스/센서 기반 데이터에 집중해서 체크

스마트워치 앱 기획 시 먼저 고려해야 할 것들

2. 각 스토어(앱스토어/플레이스토어) 정책

• 워치용 앱은 스마트폰 앱과 다른 배포 요건이 있음
  • 애플: 워치 단독 앱이면 iPhone 앱 없이도 배포 가능, 그러나 일부 API는 제한
  • 구글: Wear OS는 독립 설치 가능, 하지만 별도 APK 준비 필요
• 기획자는 초기에 배포 전략까지 설계가 필요.

각 스토어에서 고려해야할 점

3. 하이브리드 프레임워크 한계

• React Native, Flutter 등은 워치용 앱 지원이 거의 없음
  • 특히 Apple Watch 앱은 Swift/SwiftUI 필수
  • Wear OS는 Kotlin/Java 위주
• 기획자는 기획단계에서부터 네이티브 개발 리소스를 고려해야 함 스마트워치 앱 개발 단계에서 반드시 고려해야 할 사항들

4. 개인정보·동의 처리 흐름 설계

• 워치에서 개인정보 동의 UI를 넣기 어렵기 때문에 스마트폰 앱에서 먼저 처리 → 워치 앱은 기능만 수행
• 기획자는 동의 흐름을 어디서, 어떻게, 어느 시점에 받을 것인지를 반드시 명확히 설계해야 함 스마트워치 앱에서 개인정보 관련 고려사항

정책적인 부분은 크게 법률·규제 준수, 서비스 운영 정책, 보안·인증 정책을 알아야 함

• 법률·규제 준수

  1. 개인정보보호법, 정보통신망법, 전자상거래법 필수 준수
  2. 회원가입 설계 단계에서 가장 중요한 부분으로 위반 시 서비스 중단, 과태료, 손해배상 등의 위험이 있음
  3. 확인해야 할 항목

     개인정보 수집·이용 동의 >> 수집·이용 목적, 보유기간, 수집 항목을 명확히 고지, 거부 시 안내 노출 >> 개인정보 필수/선택 항목 구분 만 14세 미만 가입 제한 및 보호자 동의 >> 법정대리인(보호자) 동의 필수, 본인/보호자 인증 절차 필수 적용 약관 동의 >> 이용약관, 개인정보처리방침은 필수동의 마케팅 수신 동의 >> 광고성 정보 발송시 사전 동의 필수, 수신 거부권 안내 포함 필요 외부 인증 연동 시 개인정보 제3자 제공 동의 다크패턴 방지 : 2025년 2월 14일부로 전자상거래법 개정 시행으로 회원가입, 결제 유도, 자동결제(정기결제) 전환 등에서 사전 동의/고지 의무, 특정 옵션 사전 선택 금지, 시각적 착오 유발 금지 등 다크패턴 규율 신설, 위반시 과태로 부과 있음 필수 대상과 선택 대상에 대해 명확히 표시하고, 선택 대상 미동의 시 서비스 이용을 제한할 수 없음

• 서비스 운영 정책

  1. 서비스 운영 안정성과 사용자 신뢰를 위해 내부적으로 정해야 할 정책
  2. 정책 대상 항목

     회원가입 승인 절차 : 실시간 가입인지 관리자 승인에 따른 가입인지 중복 가입 방지 아이디/닉네임 정책 : 길이, 특수문자 허용 여부, 욕설/비속어 필터링 비밀번호 규칙 : 최소 자릿수, 대소문자/숫자/특수문자 조합, 주기적 변경 여부 회원등급 및 권한 설정 : 일반회원/기업회원/관리자 등 역할별 권한 정의 탈퇴 절차와 데이터 삭제 정책 : 탈퇴 시 즉시 삭제 항목, 일정기간 보관 후 삭제 항목(전자상거래법상 거래기록 5년 보관 등)

• 보안·인증 정책

  1. 본인 확인 절차 : 이메일 인증, 휴대폰 인증 -> 난수번호 또는 자릿 수만 체크인지, 본인확인 서비스 연동
  2. CAPTCHA 적용 : 자동 가입(봇) 방지
  3. 비밀번호 암호화 저장
  4. 2단계 인증(2FA) : 금융/개인정보 서비스(관리자 포함) 권장
  5. SSL/TLS(HTTPS) : 가입 페이지와 데이터 전송 암호화
  6. 로그 기록 : 회원가입부터 활동내역에 대한 로그 보관 (분쟁대비로 필요)

• 기타 보완 사항 해외 서비스/플랫폼 : 해외 기업의 개인정보 수집도 국내법 강화 적용, 현지 대리인 책임 강화

간편로그인/소셜로그인 방식 추가시 고려사항

1. 이용자 동의 및 약관 구성 간편 로그인 자체는 외부 서비스 약관과 연동되지만, 서비스 제공자의 약관·개인정보 수집·이용 동의는 별도로 받아야 함 예: 카카오로그인 시 ‘제3자 제공’ 동의뿐 아니라, 본 서비스의 약관 및 개인정보 수집 동의를 반드시 받아야 함

2. 각 플랫폼별 수집 데이터 이해 및 보완 소셜 로그인 플랫폼마다 제공하는 유저 정보가 다르므로, 사업 목적에 맞춰 추가 정보 수집 필요 만약 회원가입 정책이 중복계정 생성 불가라면 CI정보 필요 개인정보 보호법

• 제15조, 제17조, 제22조

정보통신망법

• 제31조
• 제50조

전자상거래법

• 제12조

1. 법, 규제 측면

국내 서비스에서는 대한민국의 개인정보보호법과 정보통신망법 등 국내 규제의 영향을 받습니다. 반면, 글로벌 서비스를 기획할 때에는 서비스 대상 국가 범위에 따라 지역별 규제를 고려해야 합니다. 대표적인 지역별 규제로는 GDPR(유럽), CCPA(캘리포니아)와 같은 규정이 있습니다. 글로벌 서비스를 런칭할 때 현실적으로 모든 국가의 규제를 검토하기에는 역부족인 경우가 많습니다. 이런 경우 GDPR을 기준으로 주요 서비스 대상 국가의 규제를 보완해서 적용하면 효율적입니다. GDPR은 동의 방식이나 데이터 수집 및 처리 등에 있어 대부분의 경우 가장 까다로운 요건을 포함하고 있기 때문에, 이를 준수하면 대부분의 선진국 규제를 커버할 수 있습니다.

2. 로그인, 인증 및 보안

소셜 로그인 방식에 사용되는 플랫폼을 선정할 때 타겟 국가의 선호도를 고려할 필요가 있습니다. 예를 들어 동남아 국가들에서는 해당 국가들에 점유율이 높은 WhatsApp을 활용한다거나, 중국의 경우 WeChat이나 QQ같은 서비스를 통한 로그인을 고려할 수 있습니다. 타겟 국가가 광범위하다면 서비스 런칭 초기에는 글로벌 표준 플랫폼으로 인식되는 Google이나 Facebook로그인 옵션을 먼저 구현하고, 주요 타겟 국가에 따라 한두 가지의 옵션을 추가로 고려해볼 수 있습니다. 휴대폰 인증이 필요할 경우, 국내와 다른 환경을 고려해야 합니다. 국가 코드 등의 입력 양식에서부터, SMS 국제 발송 비용과 전송 성공률을 검토하고 서비스를 설계하는 것이 좋습니다. 비밀번호 정책의 경우 국내에서 자주 사용하는 영문+숫자+특수문자 방식을 활용할 수도 있으나 일부 국가의 경우 보안 규정이 더 엄격한 편입니다.

3. 언어, 문화 로컬라이제이션

글로벌 서비스를 런칭할 때에는 언어, 문화적인 로컬라이제이션이 필요합니다. 언어의 경우 런칭 초기에는 영어 및 점유율이 높은 언어 위주로 서비스한 후, 사용자층이 높아진 시장에 맞춰 언어를 추가할 수 있습니다. 이름, 주소, 결제 정보 등의 정보를 수집할 때에도 문화권에 따라 형식이 달라질 수 있습니다.

예시) 날짜/시간 형식 : (MM/DD/YYYY) vs (YYYY-MM-DD) vs (DD/MM/YYYY) 이름 필드 : 서양권은 성(last name)과 이름(first name) 분리 필수, 동남아 일부는 성 없음 주소 형식 : 미국·유럽은 우편번호 위치, 중국·일본은 행정구역 순서 다름 로그인 방식 : SNS사용률에 따른 선호도 차이 (SNS 로그인 vs 이메일+비밀번호 로그인)

국내 / 글로벌 비교

법률

• 국내 : 개인정보보호법, 정보통신망법
• 글로벌 : GDPR, CCPA, 각국 데이터법

동의방식

• 국내 : 포괄/명시적 동의, 버튼/체크박스
• 글로벌 : 명확한 opt-in

처리/보관

• 국내 : 목적달성 후 즉시 삭제/익명화
• 글로벌 : 국가별 보관 주기 차이

소셜로그인

• 국내 : 카카오, 네이버, 구글, 애플, 페이스북 등
• 글로벌 : 구글, 페이스북, 왓츠앱 등

인증방식

• 국내 : 국내 통신/금융사 표준 인증
• 글로벌 : 국제 SMS/이메일 다양한 인증 방식

관련 법규

• GDPR 6조 : 데이터처리의 합법 명분, 동의 등
• GDPR 7조 : 명시적 동의 요건 (개별 체크박스 등)
• GDPR 17조 : "잊혀질 권리", 삭제 요구 시 처리
• CCPA 1798 조항 : 소비자 정보 접근·삭제·거부권
• 대한민국 개인정보보호법 15조 : 정보수집 동의 원칙

사업자등록 여부와 무관하게 개인도 개인정보처리자가 될 수 있습니다. 다만, 수집·이용·보관·파기 전 과정에서 개인정보보호법 제15조, 제29조, 제30조 등 주요 조항을 반드시 지켜야 합니다.

★개인정보보호법 제15조(개인정보의 수집·이용) ① 개인정보처리자는 다음 각 호의 어느 하나에 해당하는 경우에는 개인정보를 수집·이용할 수 있다.

1. 정보주체의 동의를 받은 경우

*기본 개념 정보주체 = 개인정보의 주인, 즉 회원가입하는 사람 동의 = “내 정보를 이렇게 쓰는 것에 괜찮다”라고 허락하는 것

사이드 프로젝트 상황에 맞추면

• 회원 가입 프로세스에 꼭 동의 절차를 넣어야 합법적입니다.

★개인정보보호법 제29조(수집한 개인정보를 제대로 보호할 책임) 개인정보처리자는 개인정보가 분실ㆍ도난ㆍ유출ㆍ위조ㆍ변조 또는 훼손되지 아니하도록 내부 관리계획 수립, 접속기록 보관 등 대통령령으로 정하는 바에 따라 안전성 확보에 필요한 기술적ㆍ관리적 및 물리적 조치를 하여야 한다.

사이드 프로젝트라도 회원가입을 받는 순간, 최소한 위와 같은 보안 조치를 해야 합법적인 개인정보처리가 됩니다. 사이드 프로젝트 상황에 맞추면

• 비밀번호 평문 저장 금지 → 반드시 해시 처리
• DB 접근 제한 → 최소한 관리자만 접근 가능
• 데이터 최소 보관 → 서비스 운영에 필요 없는 개인정보는 받지 말 것
• 탈퇴 시 즉시 삭제 → 사용자가 원하면 바로 파기

★개인정보보호법 제30조 (개인정보 처리방침의 수립 및 공개) ① 개인정보처리자는 개인정보의 처리 목적, 보유 및 이용기간, 제3자 제공 등에 관한 사항을 포함하는 개인정보 처리방침을 수립하여야 한다. ② 개인정보처리자는 개인정보 처리방침을 정보주체가 쉽게 확인할 수 있도록 인터넷 홈페이지 등에 공개하여야 한다. ③ 개인정보처리자는 개인정보 처리방침을 변경하는 경우에는 그 내용을 공개하여야 한다.

개인정보를 모으는 사람(개인·사업자 불문)은 “우리 서비스는 개인정보를 이렇게 다룬다”라는 안내문(개인정보 처리방침)을 반드시 작성해야 합니다. 그리고 이걸 사용자(회원)가 쉽게 볼 수 있도록 홈페이지, 앱 화면, 가입 화면 등에 공개해야 합니다. 바뀌면 바뀐 사실을 공지해야 합니다. 사이드 프로젝트 상황에 맞추면 회원가입을 받는다면 간단한 개인정보 처리방침을 만들어서 공개해야 합니다.

• 수집하는 항목: 이메일, 비밀번호
• 이용 목적: 회원 식별 및 로그인 서비스 제공
• 보유 기간: 회원 탈퇴 시 즉시 삭제
• 제3자 제공: 없음
• 보안 조치: 비밀번호 암호화 저장

※추가로 고려해야 할 것들

보유기간 & 파기 (제21조)

• 필요 이상 오래 보관 금지.
• 보관 기간이 끝나면 지체 없이 파기해야 함.

정보주체 권리 보장 (제4조, 제36~38조)

• 사용자가 “내 정보 보여줘/삭제해줘”라고 하면 응해야 함.

민감정보/주민등록번호 금지 (제23조, 제24조)

• 주민등록번호, 건강정보 같은 민감정보는 특별한 경우 외에는 절대 수집 금지.
• 사이드 프로젝트라면 이메일/비밀번호/닉네임 정도만 모으는 게 안전.

주민등록번호, 고유식별정보, 민감정보(건강, 신념 등)를 다루면 별도의 관리·보호 조치가 추가로 필요하며, 위반 시 과태료 등 제재가 있습니다.

★최종 요약★ 사업자 등록 없이도 개인정보 수집 가능 (개인도 개인정보처리자) 하지만 **15조(동의) · 29조(보안) · 30조(처리방침)**는 반드시 지켜야 함 여기에 **21조(파기), 36~38조(권리보장), 23·24조(민감정보 금지)**까지 챙기면 실무에서 안전 개인정보보호법

• 제15조, 제29조, 제30조
• 제21조, 제2324조, 제3638조

개인정보 보호법 기준

• 개요 : 한국 법(개인정보보호법)에는 “회원탈퇴 버튼을 반드시 둬라”는 문구는 없지만, 이용자가 삭제·동의철회·처리정지 등 권리를 쉽게 행사할 길을 마련해야 하고(권리 행사 수단 고지/운영), 목적 달성·보유기간 경과 시 지체 없이 파기해야 합니다. 이를 충족하지 않으면 위법 리스크가 큽니다.

• 관련 조항 : 이용자는 열람·정정·삭제·처리정지·동의철회를 요구할 권리가 있습니다(제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일) 내에 한해 복구를 지원하는 곳이 있으나, 정식 '탈퇴처리 후'에는 개인정보가 완전히 파기된 것으로 간주되어 복원이 불가함

결론 회원 탈퇴 후 재가입은 내부 정책에 따라 사용 또는 불가로 진행은 가능하나, 데이터 복구는 불가

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 대응 전략

비로그인 사용자의 경우

• 필수 쿠키만 사용 → 동의 없이 수집 가능
• 트래킹·광고·분석 쿠키 사용 → 이용 동의 필요 (쿠키 확인창 활용)

[상세] 쿠키 유형과 동의 필요 여부

1. 필수 쿠키

• 웹사이트 운영에 반드시 필요한 쿠키 (예: 로그인 세션, 보안) > 동의 불필요

2. 기능성 쿠키

• 사용자의 설정을 저장하는 쿠키 (예: 언어 설정) > 동의 필요할 수 있음

3. 성능 쿠키

• 웹사이트 이용 통계를 분석하는 쿠키 (예: Google Analytics) > 개인정보가 포함될 경우 동의 필요

4. 광고/추적 쿠키

• 사용자 활동을 추적하여 맞춤형 광고 제공 > 반드시 동의 필요

1. 요구 분석 및 시장 조사 단계 (기획 초기)

• 유사 서비스 벤치마킹: 경쟁사 기능 비교, 장단점 분석 요약
• 사용자 페르소나 구성: 대상 사용자의 특징, 니즈 기반 페르소나 생성
• 기획 방향 설정 보조: 요구사항 정리, 기능 범위 스케치, 컨셉 도출
• 예시 프롬프트:
  “운전자 대상 안전 알림 앱 기획 중인데, 핵심 기능 5가지만 정리해줘”
  “20대 직장인 여성 사용자 페르소나 만들어줘”

2. 기능 정의 및 IA(정보구조) 설계

• 기능 목록 도출 및 정리: 서비스 목적에 따라 필요한 기능 자동 도출
• 사용자 플로우 설계: 유저의 행동 흐름 기반 사용자 여정 생성
• 메뉴 구조 설계 보조: 앱/웹 기준의 카테고리 및 화면 흐름 구성
• 예시 프롬프트:
  “중고거래 앱의 주요 기능을 사용자 플로우 기반으로 정리해줘”
  “고객센터 웹페이지의 메뉴 구조 예시 보여줘”

3. 요구사항 명세 작성

• 기능별 요구사항 명세 초안 작성: 기획자 관점에서 개발 요청사항 자동 정리
• 텍스트 기반 요구사항 문서 작성 보조: 목적, 조건, 예외사항 등 구조화
• 협업을 위한 정형 템플릿 구성: 기능명, 설명, 입출력 등 개발 협업 기준 마련
• 예시 프롬프트:
  “회원가입 기능에 대한 요구사항 명세서 예시 만들어줘”
  “파일 업로드 기능의 예외처리 조건까지 포함한 기술 요구 정리해줘”

4. 화면 기획서 작성

• 화면 구성요소 설명 초안: 버튼, 입력창, 메시지 등 기능별 UI 설명
• 와이어프레임 기반 서술 지원: 각 화면에 포함될 기능 자동 설명
• 협업 문서용 문장 다듬기: 개발자/디자이너와 공유하기 쉬운 표현 정제
• 예시 프롬프트:
  “이 와이어프레임에 해당하는 기능 설명 작성해줘”
  “회원정보 수정 화면의 구성요소별 기능 문구 예시 알려줘”

5. 프로젝트 관리 지원 (WBS, 일정 등)

• WBS 및 업무 분장 구조 작성: 개발/디자인/QA 항목 구분 자동 분해
• 일정 산정 기준 마련: 기능별 예상 일정 템플릿 제안
• 리스크 요소 사전 식별: 예상 일정 지연 포인트 사전 분석
• 예시 프롬프트:
  “웹 기반 설문 플랫폼 프로젝트의 WBS 작성해줘”

6. 커뮤니케이션 문서 자동화

• 회의록 요약: 회의 대화 내용 요약 및 액션아이템 정리
• 클라이언트 보고/회신 문구 작성: 일정 변경, 요구 수용 여부 등 외부 커뮤니케이션 템플릿 제공
• 내부 공유용 공지문 작성: 변경 내용 공지, 배포 일정 안내 등
• 예시 프롬프트:
  “회의 요약 + 다음 액션 정리해줘”

7. 개발 커뮤니케이션 보조

• 개발 용어 설명: 백엔드, API, DB 등 용어 정리
• API 정의서 구조 보조: API 요청/응답 구조 요약 및 예시 생성
• QA 테스트 항목 구성: 기능별 테스트 케이스 자동 도출
• 예시 프롬프트:
  “REST API를 비개발자에게 설명해줘”
  “로그인 기능에 대한 QA 테스트 항목 5가지 만들어줘”

8. 배포 및 유지보수 단계 활용

• 배포 노트 문구 정리: 신규 기능/버그 수정 내용 요약 정리
• 고객 안내 문구 초안: 앱 업데이트/점검 공지 등 사용자 안내 문장 자동화
• 기능 요청 대응 전략 구성: 유입된 피드백에 대한 답변 및 우선순위 판단 근거 정리
• 예시 프롬프트:
  “앱 점검 안내문 예시 써줘 써줘”
  “고객이 ‘검색이 안 된다’고 했을 때 대응 절차 어떻게 구성할까”

1. 기능정의서, 기능명세서의 개념

• 기능정의서: 각 기능의 정의를 내리고, 개발요건 등을 담은 설명을 통해 어떻게 구현되는지를 설명하는 문서
• 기능명세서: 시스템이나 시스템 요소가 수행해야 할 기능을 체계적으로 분류하고 종합해 놓은 문서

2. 두 개 다 작성 여부

현실적으로 업무 환경에 따라 다르기에 회사마다 다릅니다. 두 문서를 동일하게 또는 다르게 사용할 수 있습니다.

다만 <u>각 기능의 정책, 세부 내용, 개발 요건 등을 상세하게 기술하여 기능이 어떻게 구현되는지 정리하는 문서</u>라는 점에서 보편적으로 두 문서의 작성항목은 동일하다고 볼 수 있습니다

3. 작성 방법

보편적으로 포함되는 내용은 크게 다음과 같습니다. 작성자, 프로젝트 성격 등에 따라 작성 방법이 다양하므로 회사 내부 양식이 있는지 확인 후 포함되는 내용 추가/생략이 필요합니다.

기능 코드 : 각 기능별로 부여되는 코드로, 기능을 명확하게 식별하기 위해 필요 : 회사의 정해진 규칙을 따라 작성하며, 보통 알파벳과 숫자의 조합

Depth : 기능의 상/하위 관계를 나타내기 위해 기재

작업 요소 : 디자인, 퍼블리싱, 개발 모듈 등을 작성

구현 대상 : 웹(PC, 모바일), iOS 앱, Android 앱 등을 작성

상세 기능 정의 : 상세한 작동 방식, 규칙, 제약 조건 등 구체적인 설명 작성 : 개발자가 기능을 정확히 구현할 수 있도록 모든 세부사항을 포함

관리자 연동 유무
우선 순위
구현 상태
비고

4. 참고 자료 기능정의서 작성방법, 개발자 질문 줄이는 첫 기준

** 브레이크포인트(Breakpoint)란?**

브레이크포인트(Breakpoint)는 반응형 웹 디자인에서 화면 크기에 따라 레이아웃이 변경되는 기준점입니다. 주로 CSS 미디어 쿼리(@media)를 사용하여 특정 해상도에서 스타일을 조정할 때 활용됩니다.

주요 브레이크포인트 기준 (일반적인 해상도 예시)

브레이크포인트는 프로젝트에 따라 다르지만, 보편적으로 다음과 같은 기준이 사용됩니다.

• 모바일 (Mobile): ≤ 576px
• 태블릿 (Tablet): 577px ~ 992px
• 노트북 & 데스크탑 (Laptop & Desktop): 993px ~ 1200px
• 대형 디스플레이 (Large Screens): > 1200px 부트스트랩 가이드 / 블로그

웹 접근성(Web Accessibility)이란?: 장애가 있든 없든 모든 사람이 웹 사이트를 이용할 수 있도록 만드는 것

예시로 설명하면:

• 시각 장애인이 스크린 리더로 텍스트를 읽을 수 있게 하거나,
• 색약이 있는 사용자를 위해 색상 대비를 높이거나,
• 마우스를 쓰지 못하는 사용자가 키보드만으로도 조작할 수 있게 하는 것 등이 포함

왜 중요할까?

• 웹은 모두의 공공 자원
• 법적으로도 (예: 공공기관 웹사이트) 웹 접근성 준수가 요구
• 누구나 동등하게 정보에 접근할 수 있는 디지털 권리를 보장

UDL(Universal Design for Learning, 보편적 학습 설계)이란?

학습자 개개인의 다양성을 고려하여, 모두가 효과적으로 학습할 수 있도록 수업이나 콘텐츠를 설계하는 방법론

핵심은 3가지 원칙:

1. 표현 방식의 다양화 (Representation): 정보를 글, 이미지, 소리 등 다양한 방식으로 제공
2. 행동 및 표현 방식의 다양화 (Action & Expression): 학습자가 배운 것을 말, 글, 그림 등 다양한 방법으로 표현할 수 있게 함
3. 참여 방식의 다양화 (Engagement): 동기 부여를 위한 다양한 학습 참여 방식 제공

예시: 한 수업에서 동영상을 자막과 함께 제공하거나, 시험을 서술형뿐만 아니라 포스터 제작 등 다양한 방법으로 대체하는 것 등

• WCAG 2.2 (최신 버전, 2023년 10월 공개): https://www.w3.org/TR/WCAG22/
• 한국웹접근성인증평가원&한국장애인단체총연합회
• 한국형 웹 콘텐츠 접근성 지침 2.2
• UDL : 공식 가이드라인: CAST에서 제공: https://udlguidelines.cast.org/
• 기타 참고자료 :
  • https://news.seoul.go.kr/gov/archives/47485
  • http://www.websoul.co.kr/accessibility/WA_guide22.asp
  • http://pubguide.geistkorea.co.kr/markup/checklist/acc.html
  • https://oneoneone.kr/content/807f8997?utm_source=kakao_productlab

1. 메뉴구조도: 웹, 앱에 구성된 전체 메뉴 및 서비스를 쉽게 파악할 수 있도록 메뉴의 구조를 시각화한 문서

2. IA(Information Architecture, 정보구조도): 웹, 앱 구축 시 필요한 화면과 메뉴의 정보 구조를 설계 및 정의하는 문서

정보의 구조화를 통해 사용자가 화면을 마주하기까지 필요한 화면들의 흐름을 시각화하여 나타낸다. 이를 통해, 각 화면들의 연관성과 접근성을 업무별 필요한 기준으로 분류하여 웹, 앱의 큰 틀을 파악할 수 있다.

3. 기능정의서(=기능명세서): 개발자가 실제 구현에 들어가기 전에 어떤 기능이 필요하고 어떤 식으로 구현 해야할지를 생각해보고 정리해놓은 문서

4. 참고 자료

• 현대자동차의 메뉴구조도
• IA, 메뉴구조도, 화면목록이 헷갈린다면?
• 기능정의서 작성 방법 및 이유

AARRR 구조를 활용한 마케팅 퍼널 방법론

1. RARRA vs. AARRR

최근 트렌드에서는 AARRR보다 RARRA 구조(관계 중심)도 주목받지만, 극초기 서비스에서는 여전히 AARRR이 실험 설계에 유용한 것으로 보임. 따라서 AARRR 기반으로 설명함.

• AARRR: 퍼널 기반 지표 추적 → 채널과 행동별 실험 구조화에 유리
• RARRA: 관계 기반 성장 구조 → 서비스 안정기 이후 리텐션 중심 제품 개선에 적합

2. AARRR 프레임워크 요약

초기 제품이나 MVP의 사용자 흐름을 퍼널로 구조화해서 유입부터 전환, 확산, 수익화까지 단계적으로 실험하고 지표를 추적하는 프레임워크.

[Acquisition (획득)]

• 유저는 어떻게 우리 서비스에 유입되는가?
• 핵심 질문: 어떤 채널이 유입에 가장 효과적인가?

[Activation (활성화)]

• 유저가 ‘처음으로 가치’를 경험했는가?
• 핵심 질문: 첫 방문에서 핵심 기능을 체감했는가?

[Retention (유지)]

• 유저는 다시 돌아오는가?
• 핵심 질문: 처음 사용 이후 돌아오게 만드는 요인은?

[Referral (추천)]

• 유저는 다른 사람에게 우리를 소개하는가?
• 핵심 질문: 자발적 확산이 일어나는 구조인가?

[Revenue (수익)]

• 유저로부터 수익을 창출하는가?
• 핵심 질문: 유료화 지점이 자연스럽고 설득력 있는가?

3. 각 단계별 실험 설계 & 지표

Acquisition

• 실험 가설: 특정 커뮤니티가 전환률이 높다
• 실험 방법: 각 채널에 별도 링크 배포(UTM 활용)
• 추적 지표: CTR, CAC, 유입 채널별 전환률

Activation

• 실험 가설: 온보딩 완료 시 핵심 가치 인지율 높임
• 실험 방법: 온보딩 A/B 테스트 or 최소 미션 삽입
• 추적 지표: 온보딩 완료율, 의미 있는 첫 액션률

Retention

• 실험 가설: 주간 미션/리마인드가 재방문 높임
• 실험 방법: 미션 알림 또는 주간 요약 전송
• 추적 지표: D1, D7 리텐션율, 주간 활성 유저

Referral

• 실험 가설: 공유하기 기능이 바이럴을 유도한다
• 실험 방법: 간단한 링크 공유 기능 삽입
• 추적 지표: 사용자당 공유 수, 초대 전환율

Revenue

• 실험 가설: 기능 제한이 유료 전환 의향 높임
• 실험 방법: 프리미엄 기능 or ‘가짜 결제’ 배치
• 추적 지표: 전환 클릭률, 유료 전환율, LTV

4. 초기 마케팅 관점의 AARRR 실험 방법론 예시

• AARRR 실제 추진 예시
• 초기 실험에서 자주 쓰는 KPI
• 스타트업을 위한 AARRR(해적지표) 개념잡기
• CleverTap – AARRR vs. RARRA 비교
• Statsig – AARRR 실험 중심 성장 전략