검색

해당 부분은 회사/조직별로 다르며, R&R 정리 및 협업 프로세스 협의를 통해 가장 최선의 방법을 찾아나가야 함. 아래 내역은 참고하시기 바라며, RACI 프레임워크 참조한 적용도 좋은 방법임

협업 기준 명시

• 기획자 : IA / 와이어프레임 1차 설계
• 디자이너 : 디자인 요소/컴포넌트 관점에서 해석 & UX 요소 강화
• 필요 시 RACI 테이블 등 프레임워크 기준 R&R 구분도 가능.

⚠️ 리스크 요소

기획자의 기획서가 과도한 완성형으로 전달되면 디자이너는 경험 개선 여지를 찾기 어려움 → 와이어프레임은 정답이 아님. 더 나은 서비스를 위해 변동될 수 있음을 모두가 인지.

역할 정의 (R&R)

[서비스 제안 & 요구사항 도출]

• 기획자 : 고객 / 비즈니스 / 기능 요구 수집 및 정의, 타겟 유저 페르소나 설정 및 유저 스토리 구성
• 디자이너 : UX 리서치 결과 제공, 유저 페르소나 공유

[서비스 기획]

• 기획자 : IA 설계 및 플로우 차트 정의 (depth에 따른 계위 / 기능 흐름 구성)
• 디자이너 : IA 구조에 기반한 UX 관점의 구조 피드백, 디자인 관점에서 플로우 보완 제안

[와이어프레임]

• 기획자 : 기능 흐름 중심의 와이어프레임 설계, 화면 간 전환, 상태 흐름 정의 포함
• 디자이너 : 초기 비주얼 스케치 및 UX 개선안 적용, 인터랙션 및 사용성을 고려한 재구성 제안

[UI 디자인]

• 기획자 : CTA 및 기능 요구 명확히 정의
• 디자이너 : 유즈케이스(초기/이용/로딩/에러 등)에 따른 화면 디자인, 디자인 시스템 및 컴포넌트 적용 => 최종 Figma 완료본 제작

[피드백 / 수정]

• 기획자 : 사용자 시나리오 기반 피드백 수렴 및 정리
• 디자이너 : 시각적 힌트, 정보 과부하, 사용성 중심 피드백 반영, 디자인 개선안 적용

[개발 전달 (핸드오프)]

• 기획자 : 기능 정의서 작성, 상태 / 예외 처리 정의
• 디자이너 : 디자인 가이드(Figma) 제공, 스타일 가이드 포함

[공동 리뷰 & 개선]

• 기획자 : 개발 및 QA 결과 반영하여 기획 수정,
• 디자이너 : 개발 및 QA 결과 반영하여 디자인 수정

[Release 기준 정리]

• 기획자 : 최종 Release 기준 기획 내용 정리, 백로그 항목 검토
• 디자이너 : 최종 Release 기준 디자인 정리

2. 프로세스 문서화

- 프로세스
    [요구사항 정의] → [IA 구조 작성 ]→ [UX 구조 검토] → [와이어프레임 작성]→ [UI 디자인 및 비주얼 구성] → [기획자-디자이너 상호 피드백] → [최종안 확정] → [개발 진행 ] → [추가 이슈 반영 & 업데이트] 
    
- 커뮤니케이션 가이드
    - 피그마 코멘트 활용 기준
        - 모든 피드백은 @이름 태그 + 목적 명시 → 개발자가 양쪽의 의도 파악하는 것도 가능.
        - 기획자 : 기능 목적 및 기획 의도 공유
        - 디자이너 : 개선 사유 및 의도 공유
        
        (예시)
        @디자이너 기존에 정의된 팝업 대신 다른 형태의 팝업이 필요한 이유가 뭔가요? 
        @기획자 여기서 다른 형태의 팝업을 띄우는 것은 유저에게 다른 액션을 유도하기 위함입니다
        
    - 정기 Sync 및 일일 스크럼을 통해 지속 업데이트

3. 체크리스트 기반 QA

- 각 기능별 기획 의도 vs 실제 구현 내용 비교 가능하도록 UI QA 기준 정리
- 기능 QA & 디자인 QA 일정도 반영 필요
- Tip : Figma  dev mode 이용 시 개발자와의 효율적 커뮤니케이션 가능 (유료) 

4. 적용 시사점

• 당신의 조직이 기획자 주도 조직이라면?

  → 기획자가 기능 명세 및 IA 구조, 플로우 구성, UX 디자이너에게 피드백 우선권과 리디자인 권한을 부여해야 함

• 당신의 조직이 디자이너 중심 조직이라면?

  → IA는 디자이너가 가져가고, 기획자는 비즈니스 로직과 기능 명세에 집중해야 함 raci 프레임워크

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

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

푸터 구성 요소 정리

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

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

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

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. [본인 인증]과 [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. Semantic Versioning (SemVer) ● Major.Minor.Patch (예: 1.2.3)
   • Major (주버전): 큰 방향성 변화, 신규 기능 추가 또는 대규모 개편 시
   • Minor (부버전): 기능 추가, UX/UI 개선, 개선 사항 반영 시
   • Patch (수정버전): 오탈자 수정, 경미한 버그 수정 시

예시) SRS_v1.0.0: 초기 기획서 배포 SRS_v1.1.0: 신규 기능 추가 SRS_v1.1.1: 오타 및 사소한 수정

2. Calendar Versioning (CalVer)

• YYYY.MM.DD 형식 사용
• 날짜 기반으로 관리하는 방식이며, 정기 업데이트 시 유리합니다.
• 특히, 기능 정의서처럼 릴리스 주기가 정해진 문서에 적합합니다.

예시:

• SRS_2024.03.01 → 2024년 3월 1일 버전
• SRS_2024.03.15 → 3월 15일 기능 추가 버전

효율적 관리 방법

• 파일명 규칙: 프로젝트명_버전명_날짜 (예: 당근심부름_기획서_v1.1_20240312)
• 변경 이력 관리: 주요 변경 사항을 간략히 기록
• 백업 체계: 기존 버전은 보관하고, 최신 버전만 공유
• 프로세스: 초안 작성 → 피드백 반영 → 최종 확정 및 기록

이러한 기준을 적용하면 기획서의 버전 관리가 체계적으로 이루어지며, 수정 및 업데이트 이력을 명확하게 정리할 수 있습니다.

푸시/이메일 수신 동의와 마케팅 목적 수신 동의의 차이점은 아래의 구분을 참고하시면 되겠습니다.

1) 목적

• 푸시/이메일 등의 수신 동의: 서비스 이용과 관련된 필수 정보를 전송하는 목적으로 사용된다. 예를 들어, 주문 확인, 계정 정보 변경, 서비스 업데이트, 고객 문의 응답 등의 정보가 포함된다.
• 마케팅 목적 수신 동의: 광고성 정보 전송을 목적으로 사용된다. 예를 들어, 신상품 출시, 프로모션, 할인 이벤트, 광고 및 제휴 마케팅 관련 정보 등이 포함된다.

2) 법적 요구사항

푸시/이메일 등의 수신 동의

• 정보통신망 이용촉진 및 정보보호 등에 관한 법률에 따라 광고성 정보가 아닌 경우, 서비스 제공을 위한 필수적인 정보는 별도의 동의 없이 전송이 가능할 수 있음.
• 다만, 이용자의 알 권리 보호 및 불필요한 정보 수신 방지를 위해 명확한 동의를 받는 것이 권장됨.

마케팅 목적 수신 동의

• 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제50조에 따라 광고성 정보 전송 시 수신자의 명시적인 사전 동의가 필수적임.
• 사용자가 광고성 정보 수신을 거부할 권리를 가지며, 이를 쉽게 철회할 수 있는 방법을 제공해야 함.

1. 정보통신망법 이용촉진 및 정보보호 등에 관한 법률 제50조
2. 개인정보 보호법 제15조
3. 한국인터넷진흥원(KISA) ‘앱 푸쉬(App Push) 광고 안내서

✅ 1. 프리랜서 등급 기준 (참고용)

한국소프트웨어산업협회는 2019년까지 자격증 유무, 경력 연차 등에 따라 공식적인 등급 기준을 발표했으나, 현재는 공식 등급 체계가 존재하지 않습니다. 다만 여전히 실무에서는 다음과 같은 예전 기준이나 각 업체 내부 등급 규정을 참고해 등급을 사용하는 경우가 있습니다.

등급 경력 연차 기준 참고 단가 (월) 초급 3년 300 ~ 400만 원 중급 37년 400 ~ 550만 원 고급 7년 이상 550 ~ 700만 원

※ 위 금액은 **프리랜서 계약 기준(3.3% 원천징수 전)**으로, 커뮤니티(맥비기획톡방 등)에서 2024년 하반기에 오간 실제 사례를 기반으로 한 범위입니다. ※ 실제 단가는 프로젝트 성격(공공/민간), 난이도, 기간, 클라이언트 예산, 업무 역할 등에 따라 유동적입니다.

✅ 2. 실무 기준 노임단가 (한국소프트웨어산업협회, 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

※ 이 단가는 공공 프로젝트 기준으로, 나라장터 입찰 등에서 참고 자료로 사용됩니다. ※ 민간 프로젝트에서는 이보다 낮거나 높은 단가로 협의가 이뤄질 수 있습니다. ※ 계약 당사자 간의 합의에 따라 월 단가 고정 계약 방식도 일반적입니다.

📌 참고 사항

• UI/UX 기획, 서비스 기획, 운영/정책 기획 등 세부 직무에 따라 단가에 차이가 발생합니다.
• 일부 프리랜서는 협회 단가보다 낮은 수준으로 수주하지만, 그 반대도 종종 존재합니다.
• 경력보다는 전문성·포트폴리오·도메인 경험이 단가 형성에 영향을 주는 경우도 많습니다.
• 공공 프로젝트의 경우, 협회 기준이나 나라장터 기준 단가를 따르는 경우가 많고, 민간은 협의 단가로 진행됩니다.

1. 로그인 흐름

• 로그인 버튼 클릭 → Google OAuth 인증 → 계정 선택 → 동의 화면 표시 → ID Token 수신 → 회원가입 또는 로그인 처리 → 세션 및 토큰 저장

2. 사용자 식별 기준: 'sub' 값 사용 (Google의 고유 사용자 ID, 불변) ※ DB에는 자체 user_id를 기본키로 사용하고, 'sub' 값은 별도 매핑 테이블로 관리하는 것이 안전함

3. 수집 가능한 사용자 정보 sub, email, name, picture (기본 제공, 별도 동의 불필요)

4. 중복 가입 처리 동일 이메일 존재 시 "기존 계정이 존재합니다. 간편 로그인을 연결하시겠습니까?"와 같은 UX 제공 필요. 이메일 기준 매핑 또는 사용자 확인 후 병합 여부 결정. 기획서에 병합 정책 명시 권장

5. 세션 및 토큰 관리: access_token 약 1시간 유효, refresh_token 발급 시 access_type=offline 설정 필요. 서비스 자체 세션(JWT 또는 쿠키 등)으로 로그인 유지 필요

6. 보안 고려사항 HTTPS 필수, access_token은 클라이언트 저장 금지, refresh_token은 서버에만 저장. PKCE 사용 권장, Client Secret 노출 금지

7. 기획서 포함 필수 항목

• 지원 SNS는 Google,
• 사용자 식별 키는 sub,
• 동의 항목 정리(email, name, picture),
• 로그인 vs 회원가입 분기 처리 기준,
• 이메일 중복 병합 정책 및 UX,
• 세션 유지 및 토큰 갱신 정책,
• 연동 해제 처리 흐름,
• 보안 정책(PKCE, HTTPS, 서버 저장 방식 등), 예외 처리(email 미동의, 계정 없음 등) 구글 로그인 UX 가이드

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, 서버 저장 방식 등), 예외 처리(카카오톡 미설치, 선택 동의 거부 등) 카카오 디벨로퍼 사이트

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

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

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

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

개인정보 보호법 기준

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

• 관련 조항 : 이용자는 열람·정정·삭제·처리정지·동의철회를 요구할 권리가 있습니다(제4조, 제36·37조). 서비스는 권리 행사 방법과 절차를 마련·공개해야 하고, 수집 방법보다 쉽게 할 수 있어야 합니다(제38조). 이를 막거나 이행하지 않으면 제재 대상이 됩니다.

• 요약 : “회원탈퇴 버튼” 자체를 강제하는 조항은 없지만, 권리행사 창구(자기결정권 보장) 와 파기 의무를 실질적으로 이행하려면, 사용자 스스로 즉시 요청할 수 있는 회원 탈퇴 기능이 가장 확실하고 안전합니다.

실무적인 기준 앱 마켓 심사(Apple/Google) 는 “앱에서 계정 생성이 가능하면 앱 내에서 계정 삭제를 제공”하도록 사실상 의무화하고 있어, 실무적으로는 회원탈퇴(=계정/개인정보 삭제) 기능을 제공해야 통과됩니다.

• Apple App Store: 2022-06-30부터 앱에서 계정 생성이 가능하면, 앱 내에서 계정 삭제를 시작할 수 있어야 하며 단순 비활성화만 제공하면 불충분. 삭제는 개발사 보관 데이터(법적 보존분 제외)까지 포함. 재인증·확인 단계는 가능하되 과도한 방해 UX는 불합격.

• Google Play: 계정 생성 가능 시 ① 앱 내 삭제 경로와 ② 웹 링크(앱 없이도 삭제 요청 가능) 를 모두 제공. Data safety 폼에 삭제 실무 기재해야 하며, 2024-05-31 이후 미준수 시 제재(삭제 등). 법적 보존이 있으면 고지·분리보관.

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

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

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

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

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

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

핵심 비교 요약

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. 기능정의서, 기능명세서의 개념

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

2. 두 개 다 작성 여부

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

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

3. 작성 방법

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

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

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

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

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

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

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

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

페르소나 개념 및 설정 방법

1. 정의

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

1) 왜 중요한가

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

2) 설정 방법

a. 데이터 수집 및 분석

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

b. 페르소나 프로필 작성

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

c. 유사 인물 탐색

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

d. 일상 시뮬레이션

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

e. 활용

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

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

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

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

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

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

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

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

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. 지원하는 회사에 맞춰 큐레이션

• 면접관이 "이 사람 우리 회사랑 맞네"라고 느끼도록 지원 도메인에 맞는 작업만 추려서 구성합니다. (예: O2O로 이직한다면 O2O 관련 프로젝트 위주)
• 딱 맞는 분야가 없으면 최대한 유사한 분야를 골라 연결되는 스토리로 풀어냅니다.

3. 어떻게 구성할까

두 파트로 나누면 정리가 쉽습니다.

1. 프로젝트 소개 — 진행한 프로젝트명, 역할, 기간, 수행 범위
2. 기획 산출물 — 정책서, 요구사항정의서, IA, 스토리보드, 화면설계서, 중간/완료 보고자료 등

• 스토리보드는 모든 프로젝트에 다 넣을 필요 없이 최신 3개 정도면 충분합니다.
• 구축 프로젝트가 있다면 하나 정도는 풀셋(컨셉기획문서 → 정책서 → 요구사항정의서 → IA → 스토리보드 → 보고자료)으로 정리해두면 역량을 잘 보여줄 수 있습니다.

4. 면접에서 화면설계서는 어느 수준으로?

• 보통 파일로 제출하기보다 노트북·패드에 담아가 현장에서 보여주는 방식을 많이 씁니다.
• 포트폴리오 안에 화면설계서 1~2p를 이미지로 넣고 간단한 설명을 덧붙이면 됩니다. 자사 서비스 위주였다면 실제 사이트 캡처를 함께 넣는 것도 좋습니다.