Framer

Chapter1 ~ Chapter3

1. 인터페이스 및 기본 조작

• 화면 구성: 상단 툴바, 좌측 기능 사이드바, 우측 속성바를 통해 작업 환경이 구성됩니다.
• 주요 단축키:
  • Ctrl / Cmd + K: 메뉴 검색창 열기
  • Ctrl / Cmd + Del: 종속 관계를 끊고 부모 프레임만 삭제
• CMS 이동: CMS 버튼을 클릭하면 CMS 관리창으로 바로 이동
• Breakpoint: Desktop, Tablet, Phone 등 사이즈 기준으로 설정

2. 페이지 및 홈 설정

• Home 설정: 도메인 주소 뒤에 /가 붙지 않는 가장 첫 번째 랜딩 페이지(Root)
  • Home 변경 시: set new home 기능을 통해 홈페이지를 변경하면 기존 Home은 자동으로 old-home으로 이름이 바뀜.
• 페이지 추가: /page, /login, /address, /profile 등 하위 경로를 설정할 수 있으며, 나중에 폴더 구조로 변경하여 관리할 수 있습니다.
• 페이지 설정: Meta Data인 Title과 Description을 설정하여 SEO 및 검색 노출을 관리합니다.

3. 레이아웃 시스템 (Frame, Stack, Grid)

Frame

• 생성 방식: Space를 누른 채로 프레임을 드래그하면 종속되지 않고 독립적인 요소로 생성됩니다.
• 자식 프레임 생성: 요소를 먼저 생성한 후 다중 선택 → 우클릭 → Add Frame을 통해 감쌀 수 있습니다.

Stack (Figma의 Auto Layout과 유사)

• 가로, 세로 1줄로 요소를 배치할 때 사용합니다.
• Position: Absolute(내가 놓은 위치 그대로)와 Relative(주변 요소와의 관계 중심)로 구분됩니다. 파란 점선은 위치와 배치의 기준을 나타냅니다.
• Stack 적용 방법:
  1. 자식 요소 선택 후 Add Stack
  2. 프레임 선택 후 Add Stack/Layout
  3. 부모 프레임의 Layout 설정 변경

Grid

• 격자 형태로 요소를 배치합니다. (예: 2x2, 2x1 등)
• 사이즈 변화: 내 프레임의 사이즈를 조절하거나, 특정 프레임을 선택하여 Column / Row Span을 적용해 영역을 확장할 수 있습니다.

4. 컴포넌트 및 Breakpoint 활용

• Breakpoint 관리:

  • Desktop이 원본이며, 나머지는 연결되어 재설정(Override)되는 구조.
  • 어느 브레이크포인트에서 추가하느냐에 따라 추가되는 브레이크 포인트의 스타일이 결정됨.
  • 요소 리셋: 모든 속성을 초기화.
  • 속성 리셋: 특정 속성만 초기화.
  • Breakpoint에서 삭제(Del) 시, 삭제가 아닌 Visible Off 처리.
  • 하위 Breakpoint에서의 변경사항은 상위(부모)에 영향을 주지 않음.

• 컴포넌트(Component):

  • 이름 규칙: /컴포넌트 타입/이름 또는 폴더 구조를 활용하여 체계적으로 관리.
  • 변수(Variable): 속성 좌측의 + 버튼을 눌러 속성을 변수로 지정하면, 외부에서 세부 조정이 가능. (레이아웃 템플릿 등에 활용)

5. CMS (Content Management System)

• 기본 개념: 데이터들의 집합체인 Collection을 관리.

  • Slug: 주소창에 적힐 고유한 문자/숫자열이며, 아이템별 고유 번호 역할.
  • Collection Name: 명확한 규칙을 가지고 이름을 지정하는 것이 중요.

• CMS 레이어 배치: 카드 컴포넌트 하위에 CMS 레이어를 배치하고, 프레임의 Fill, Content 등에 CMS Column 변수를 연결하여 데이터를 연동.

• 데이터 제어:

  • Limit to: 노출할 데이터의 개수를 제한.
  • 수동 정렬: CMS Field에 'order' 항목을 추가한 뒤, Sorting 설정에서 order 순으로 정렬.

6. CMS 페이지 및 조건부 렌더링

• CMS 상세 페이지: Pages → + → New CMS Page를 통해 특정 Collection의 디테일 페이지를 생성.

  • CMS 페이지의 수정 사항은 해당 Collection의 모든 아이템에 광역 적용됨.

• Index Page: Insert에서 가져오는 것과 같은 아이템 목록 페이지.

• 조건부 렌더링: 적용하고 싶은 요소의 특정 속성 옆 +를 눌러 Set Variable을 설정함으로써 조건에 따라 요소를 보여주거나 숨길 수 있음.

7. 기타

• Code Block: 코드 삽입 시 사용합니다.
• Heading 1: 웹페이지를 대표하는 가장 중요한 제목 내용에 적용.
• 이미지: 프레임을 씌워서 사이즈를 조절하는 방식을 권장.
• Min/Max: 유동적으로 변하는 범위(Range)를 설정할 때 활용.

아티클카타

PO의 커뮤니케이션, 이것만 기억하자! (2022. 12. 07)

Summary

• 이 아티클의 주요 메시지 : 로드맵 수립부터 성과보고까지의 과정에서 이뤄지는 다양한 커뮤니케이션.
• 핵심 키워드 : 공감, 방향성

Reflection & Insights

• 사업부의 요구사항이 로드맵에 반영되지 않았을 경우, 사업부가 납득 할 수 있도록 과제를 선정하는 기준과 요구사항이 제외된 이유를 설명해야함.
• 메이커와 킥오프 미팅을 진행할 때, 협의과정 없이 작업 기한을 통보하는 것은 지양하자.
• 스크럼의 목적은 작업 진행 현황을 파악하기 위함이다. 작업 진행이 원활하게 되기 위해 제품단에서 공유해야할 내용과 체크해야할 부분을 미리 준비하자.
  • 스크럼 참가자들의 진행상황을 듣는 것이 아니라, 능동적으로 체크하는 자세가 있어야 의미있느 스크럼이 된다.
• 외부 업체와 협업 시, 어쩔 수 없이 갑을 관계가 형성된다. 상황에 맞게 각 회사의 입장을 고려해서 커뮤니케이션을 하는 것이 중요. 방어적이고 적대적인 자세가 나오면 프로젝트 진행이 어려워진다.

New Findings

• 고객 응대 매뉴얼, 내부 운영 가이드를 PO,PM이 만드는구나…
• 프로덕트에 대한 성과보고와 로드맵 성과보고가 따로 이루어진다는 점
  • 이 둘의 차이가 뭔지?

Make 실습

귀여운 어플을 만들어 보자 (인앱토스 챌린지 빌드업)

Make Scenario

1. Open AI 프롬프트 (Systme/ User)

• 프롬프트 생성을 클로드한테 맡겼더니 system과 user 두가지 role에 대한 prompt를 만들어 줌.

• System: AI 행동 규칙, 페르소나 설정 (대화 전반에 걸쳐 유지되는 고정 지침)

  당신은 사용자 설문 응답을 분석하는 UX 리서처입니다.
  아래 네 가지 패턴 중 하나로 응답자를 분류하세요.
  분류 근거를 2문장 이내로 간결하게 설명하고, 응답내용 속 핵심 키워드를 추출하세요. 키워드는 4개 이하로 추출하세요. 선택질문에 응답한 경우, 응답자에게 어떤 기능이 필요할지 답변을 기반으로 추론하세요.
  
  [패턴 정의]
  - Pattern A 수집가형: 귀여운 콘텐츠를 저장하고 아카이빙하는 성향.
    시각적 형태(작다, 둥글다, 캐릭터)에 민감하고 힐링·커스텀 선호.
  - Pattern B 공유자형: 귀여운 콘텐츠를 즉시 친구에게 공유하는 성향.
    맥락·상황 귀여움(어설프다, 예상 밖 행동)에 반응하고 소셜 기능 선호.
  - Pattern C 반응형: 콘텐츠를 소비하지만 저장·공유는 잘 하지 않는 수동적 성향.
    좋아요 정도의 가벼운 반응을 선호하고 피드형 UX에 적합.
  - Pattern D 참여자형: 직접 만들거나 커스텀하는 것을 즐기는 성향.
    캐릭터성과 표정에 주목하고 UGC 기능 참여율이 높음.
  
  [출력 규칙]
  - 반드시 JSON 형식으로만 응답하세요.
  - JSON 외 텍스트, 설명, 마크다운 코드블록(```)을 절대 포함하지 마세요.
  - 아래 스키마를 정확히 따르세요.
  
  {
    "pattern_name": "",
    "reason": "2문장 이내 핵심 응답 기반 설명",
    "keyword": ["", "", ""],
    "summary":"2문장 이내 선택 응답 요약"
  }

  • User: 실제 처리할 데이터, 요청 (매 요청마다 바뀌는 동적 입력값)

    아래는 설문 응답자 1명의 응답입니다. 
    

  Q1. 어떤 게 귀엽다고 느껴지나요? {{1.1}} Q2. 귀여움을 느끼는 포인트는? {{1.2}} Q3. 인터넷에서 귀여운 콘텐츠를 보면? {{1.3}} Q4. 귀여운 앱이 갖춰야 할 필수 덕목은? {{1.4}} Q5. 최근 귀엽다고 느낀 것 (선택) {{1.5}} Q6. 귀엽다고 생각하는 서비스/콘텐츠 (선택) {{1.6}} Q7. 귀여운 앱에 원하는 기능 (선택) {{1.7}}

  응답자의 콘텐츠 사용 패턴을 분류해주세요. 선택 질문에 대한 응답자의 의견을 요약해주세요.

  - 매핑변수 표현식 = `{{}}`
  

2. JSON 파싱이 안된다?!

• 그것은... Run을 돌리지 않았기 때문에 매핑 변수가 생기지 않은 거였음..
• Parse JSON 모듈을 연결하고, Data Structure를 정의한 다음, Run 실행, 그리고 Google Sheet 모듈 연결. 이 순서대로 했더니 해결 됨.

3. 슬랙 메세지에 노션 링크 달기

• 매핑 변수 중에 URL 있음. public url 말고 그냥 URL.
• 슬랙 하이퍼 링크 = <텍스트 | url>

사이드 프로젝트 - 아티클 카타 DB 웹 제작

페이지 디자인 회의

AI 자동화 특강

15:00-16:00 이강민 튜터님

1. 구글 폼 - 설문지 생성
2. 설문 응답 spread sheet에 연결
3. AI 자동화 영역 — 요약, 기분 분석, 키워드, 이슈 등록 필요, 이슈 제목 칼럼 추가

자동화 플로우

• 자동화 툴: n8n, zapier, make 등등 다양함

Make

1. 시나리오에 구글 시트 추가 - watching new rows (row가 새로 추가 될 때 마다 리뷰하겠다)
2. 구글 시트에 계정 연결
3. 스프레드 시트 ID에서 시트 선택 - 시트 네임 지정
4. 구글 폼에서 시트를 만들면 헤더는 자동 생성 됨 (table contains header - yes)
5. 한 사이클당 몇개의 데이터를 조회할 지 (e.g. 5)

모듈 = 시나리오 안에 하나의 단계

6. open AI 모듈 추가 - 텍스트 콘텍스트 에 프롬프트 입력

   • 메이크에서는 GPT에 프롬프트를 입력할 때, 입력창에 커서를 누르면 이전 단계의 정보를 연결해 줄 수 있음.

7. 구글 시트 모듈을 추가하고 update rows

8. row numbers는 변수로 지정해야함. 입력창 누르고, 구글 시트에서 row number를 클릭.

JSON 형식 = {'key1':'value1','key2':'value2'}

9. json 형식으로 요구하고 반환받은 답변을 나눠야함.
10. json 모듈 -parse, 오픈ai에서 result 값 속 {} 안에 있는 텍스트를 분리해줌
11. 노션 페이지에 테이블 생성
12. '이슈등록: 예' 인 voc를 노션 테이블에 등록할 거임
13. 라우터 생성 - 라벨: 이슈 등록 필요 - 컨디션: 이슈 등록, equal to 예/ 이슈 등록 불필요 루트도 생성
14. 이슈 등록 필요에 노션 모듈 생성
15. add- 노션 로그인, input method - specific
16. manage data source - source의 소스 데이터 아이디 복사 - 노션 모듈의 데이터 소스 아이디에 복붙.

클로드로 자동화 (구글 시트 mcp 연동)

1. 구글 API 활성화
2. IAM 관리-서비스 계정 생성
3. 계정 만들고 역할 부여 - 편집자
4. 계정목록의 작업 관리 창에서 json 키 발급
5. json 키 파일을 claude config 있는 디렉토리에 옮겨놓기
6. 그리고 config 파일에 넣은 mcp 코드속 json 키 경로도 일치시켜주기.

아티클 카타

UI나 UX나 그게 그거 아니야?

• ux 기획 - 사용자의 행동 → 다양한 사용자 리서치를 통해 문제 분석

• ui 디자인 - 사용자 친화적 인터페이스 → 프론트엔드 개발자와 협업

• gui 디자인 - 시각적 표현, 디자인 정책

• 국내에서는 ux,ui,gui 간의 경계가 명확하지 않은 경우가 많음 → 채용 공고 분석을 통해 어떤 직무에 더 가까운지 파악해야함

• 실리콘 밸리 대표 기업의 채용공고를 분석:

  • UX - R&D 수행 리서치 직군, 기획 역량 직무명 : ~~ Researcher
  • UI - 시각적 구현, 프로토타입 제작 직무명: ~~Designer
  • GUI - 새로운 디자인, 디자인 시스템 관리 직무명: ~~ Designer (UI디자이너와 직무명 겹침)

• 특히 ui/gui 같은 경우는 실리콘 밸리에서도 아직은 크게 구분하지 않음. (발행년도 2021년 기준)

2025 이후의 트렌드 조사

• AI의 일상화로 UI와 GUI 디자이너의 영역은 더욱 흐려지고 있음.
• Product Designer 혹은 UI/UX Designer 라는 포괄적인 용어를 사용.
• 대화형 AI, AI 에이전트를 통한 웹 탐색 → 스크린에서 보여지는 디자인 요소보다는 사용자의 의도를 더 중요하게 여김
• 단순히 심미적인 요소를 구현(픽셀 작업이나 그래픽 코딩)하는 기술보다, 제품 전체의 맥락을 파악하고 문제를 해결하는 전체적인 제품 사고 역량이 중요해짐.

Q&A

Q. UX 기획자와 PM은 실무에서 어떻게 구분되나요?

A. UX기획자는 대중적으로 많이 사용되지는 않음. 직무명은 UX 기획자인데 역할은 PM, 서비스 기획자인 경우도 있음. UX 리서처는 PM과 구분된 직무로 존재. UX기획자가 있는 경우는 사업, 제품, 마케팅을 다루는 서비스 부서내에서 프로덕트의 기능적인 부분에 대한 업무를 수행. PM의 업무 로드를 나눠야할 때, UX 기획자가 와이어 프레임, 화면 설계 업무를 맡음.

Q. 대화형 AI와 AI에이전트가 일상화되면서 단순히 심미적인 요소를 구현(픽셀 작업이나 그래픽 코딩)하는 기술보다는, 제품 전체의 맥락을 파악하고 문제를 해결하는 전체적인 제품 사고 역량이 중요해졌다고 하는데, 이런 변화가 실제 국내 기업에서도 일어나고 있는지?

프로덕트 디자이너라는 직무명으로 변하는 추세. 회사의 문화나 결에 따라 심미적 요소와 기능 사이에서 선호도 차이는 존재함.

AI로 인한 변화 이전에도 심미적인 요소보다 기능을 우선적으로 고려해야하는 게 맞다. AI로 인한 변화에 더욱 대두된 것.

역기획 PRD 보완

발표 후 피드백 받은 내용을 보완해서 PRD를 만들어보자

민감 정보 관련 정책

온프레미스 챗봇은 기업 내부 인프라에서 독립적으로 운영되므로 데이터가 외부로 전송되지 않습니다. 금융과 의료 그리고 공공 분야처럼 정보 보안이 중요한 산업에서 온프레미스 방식을 선호하는 경향이 있습니다.

• 채널톡 이용약관

• 챗봇 이용 전 매장 정보, 가게 데이터에 접근 권한을 허락하는 대화 진행 (은행에서 대출 신청 할 때 이용약관, 상품 설명서 읽고 동의 하듯이)

1. 근거 기반의 응답 및 출처 제공 (->AI 추천 액션의 명확한 포지셔닝)

2. 검색 증강 생성(RAG) 및 도구 활용

• 시스템 아키텍처 측면에서 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 기술을 도입
• MCP(Model Context Protocol) 활용: MCP 서비스를 통해 기존의 '우리가게 AI' 와 같은 도구와 모델을 통합 관리.*

3. 실시간 모니터링

• Prometheus나 Grafana와 같은 도구를 활용하여 모델의 성능과 요청 빈도, 오류 발생 여부 등을 실시간으로 모니터링함으로써 이상 징후를 조기에 발견하고 대응*

4. 사용자 피드백 루프 구축

• 기술적인 지표뿐만 아니라 사용자의 직접적인 피드백을 시스템 개선에 활용.

• 평가 시스템: 답변 하단에 '도움이 됨/안 됨' 버튼을 설치하여 사용자가 답변의 질을 직접 평가.

• 리스크 최소화 사용자가 직접 검증할 수 있는 도구(출처)를 제공 실시간 모니터링과 사용자 피드백 AI가 스스로를 교정하는 메커니즘

*참고자료 - Secure on premise site chatbot routing

Kakao i Connect Talk 기술 문서 : 참고하면 좋을 IA, 와이어프레임 시각화

정리

[AI 할루시네이션으로 인한 신뢰도 리스크 대책방안]

1. RAG 기반의 '수치 데이터' 연동 및 프롬프트 제약

• 지식 베이스 구축: 사장님별 매출, 주문 통계, 클릭률 데이터가 담긴 DB를 챗봇이 직접 조회하도록 설정함.
• 제약 조건 설정: "DB에 없는 정보에 대해서는 절대 추측하지 말고 '데이터를 확인할 수 없습니다'라고 답변할 것"을 시스템 프롬프트에 명시함.
• MCP(Model Context Protocol) 활용: MCP 서비스를 통해 기존의 '우리가게 AI' 와 같은 도구와 모델을 통합 관리.

2. 분석 근거 및 데이터 출처(Citation) 표기

• 데이터 출처 명시: "지난주 대비 매출이 10% 상승했습니다"라는 답변 시, [3월 4주차 vs 3월 3주차 비교 결과]와 같은 데이터 소스를 함께 표기함.
• 계산 과정 투명화: 단순 결과만 주는 것이 아니라, 어떤 수치들을 합산하거나 나누어 해당 결론에 도달했는지 간략한 근거를 제시하여 사장님이 직접 검증 가능하게 함. (요약 기능과 충돌하는 지점은 토글로 해결할 수 있지 않을까?)

3. 사용자 피드백

• 간편 피드백 버튼: 답변 하단에 '정확해요 👍 / 분석이 틀려요 👎' 버튼을 배치하여 현장의 목소리를 실시간으로 수집함.

4. 가드레일 및 인간 개입(Human-in-the-loop)

• 위험 문구 노출: "이 분석 결과는 통계적 추정치이며, 실제 정산 금액과 차이가 있을 수 있습니다"라는 면책 조항을 답변 하단에 상시 배치함.

• 고위험 추천 필터링: 광고비 집행 등 직접적인 비용이 발생하는 '액션 추천'의 경우, 내부 검증 로직을 거친 추천 템플릿만 출력되도록 설계함.

[AI 추천 액션의 명확한 포지셔닝]

• '추천 액션' 라벨링

  • "우리 가게 성장", "경쟁 전략" 과 같은 라벨링으로 추천액션에 따른 기대효과를 빠르게 각인시키고, 어떤 데이터를 참조했는지 명시. (e.g. 지난 3개월간 매장의 변화를 반영했어요/ 근처 경쟁업체의 성과를 반영했어요)

  • 문장이 짧아야 "요약"이 성립되는 건 아니니까, 명확한 포지셔닝을 위한 설명이 포함되어 답변이 조금 길어져도 괜찮지 않을까?

[민감 정보 관련 정책]

[원칙 1] 데이터 접근 및 활용 권한 제한 최소 권한의 원칙: 챗봇이 분석을 위해 접근하는 데이터 범위에서 사장님의 계좌번호, 상세 주소 등 분석에 불필요한 식별 정보는 원천적으로 차단(Masking)합니다.

본인 데이터 한정: 사장님은 '본인 가게'의 데이터만 조회할 수 있어야 하며, 지역 평균 등 비교 데이터를 제공할 때는 반드시 비식별화(익명화)된 평균값만 사용합니다.

[원칙 2] 데이터 활용 목적의 명확한 고지 및 동의 별도 동의 절차: 일반적인 서비스 이용 약관 외에 '가게 운영 분석 및 액션 추천을 위한 데이터 활용 동의'를 별도로 받습니다.

목적 외 사용 금지: 수집된 데이터를 마케팅이나 타 서비스 제공 목적으로 재활용하지 않는다는 점을 명시하여 심리적 안전 장치를 마련합니다.

[원칙 3] 챗봇 답변 내 정보 노출 가이드 마스킹(Masking) 처리: 답변 중 민감할 수 있는 수치나 정보는 일부 가려서 출력합니다. (예: 계좌번호 끝 4자리, 주문자명 성만 표시)

휘발성 답변 유지: 민감한 경영 데이터가 담긴 채팅 로그는 일정 시간이 지나면 서버에서 삭제하거나, 사장님이 직접 삭제할 수 있는 기능을 제공합니다.

[원칙 4] 투명한 알고리즘 및 오류 대응 추천 로직 공개: "이 액션은 최근 4주간의 목요일 주문 패턴을 분석한 결과입니다"와 같이 어떤 데이터를 기반으로 분석했는지 사장님에게 설명합니다.

이의 제기 채널: 데이터 분석 결과가 실제와 다르다고 판단될 경우, 즉시 고객센터나 담당 MD에게 연결할 수 있는 '신고/문의' 루트를 답변 하단에 배치합니다.

추가 체크 사항

법적 검토: 개인정보보호법 외에도 '가맹사업법'이나 '대규모유통업법'상 영업비밀 침해 소지가 없는지 법무 검토를 거쳤는가?

데이터 정합성: 챗봇이 불러오는 데이터와 사장님 관리 페이지(Self Service)의 통계 수치가 소수점까지 일치하는가? (불일치 시 신뢰도 급락)

심리적 허들: 사장님이 "플랫폼이 내 가게를 감시하고 있다"고 느끼지 않도록, 말투를 '감시자'가 아닌 '든든한 파트너'의 톤앤매너로 설정했는가?

사이드 프로젝트 - 아티클 카타 DB 웹 제작

MVP 회의

AI 리서치 특강 — 실습

Gemini Gem: 인터뷰 가이드 생성
NotebookLM: 분석 결과 또는 인사이트 화면

1. Gems 구축용 프롬프트 작성 요청

Gems 구축& 가상 시나리오 요청 대화 : https://gemini.google.com/share/561a8099f96f

Prompt 1

유저 리서치용 Gems를 생성하기 위한 프롬프트를 만들어줘.

1. 예상 인풋: 유저 리서치의 목적, 배경, 목표, 대상, 리서치 형태

2. 기대 아웃풋: 조사 대상자 선별 가이드라인, 인터뷰 설계, 질문 구성 가이드라인, 인터뷰 유의 사항, 리서치 완료 후 인사이트 도출을 위해 적용하면 좋을 방법론

3. 프롬프트 작성 시 반영할 지침: CTFCE(context, task, format, constraint, example) 프레임 워크의 프롬프트 엔지니어링을 사용할 것. CoT 기법이 적용되도록 할 것.

Prompt 2

Gems가 먼저 아웃풋 출력을 위한 질문을 던지고 내가 필요한 항목에 대한 대답을 완료했을 때 최종 유저 리서치 가이드라인을 출력할 수 있도록 위 프롬프트 내용을 Gems 구축용 프롬프트로 변환해줘.

2. Gems 테스트용 가상의 유저 리서치 상황 생성

Gems 테스트 확인 포인트:

1. Gems가 5가지 필수 정보를 누락 없이 인지하는가?
2. 질문 가이드라인이 단순히 "기능이 어떤가요?"가 아니라, 신뢰도와 허들을 파악할 수 있는 심층 질문으로 구성되는가?
3. 인사이트 도출 방법론이 리셔치 형태에 알맞게 추천되는가?

3. Gems 테스트

Gems conversation: https://gemini.google.com/share/2d23bbc8086e

테스트 결과

• ✅테스트를 위해 리서치 형태를 미정으로 입력 → 목적에 맞는 리서치 방법을 제안.
• ✅사용자의 기대, 망설임, 신뢰도와 같은 부분에 대한 심층 질문으로 구성됨.
• ✅인사이트 도출 프레임워크가 알맞게 추첨됨.

[피드백] 장바구니 담기 전환 개선 과제

피드백 by 윤정 튜터님

📄과제 완성본

Q&A

(1) Q. OKR과 KPI가 일치하지 않은 부분에 대한 피드백을 받았습니다. KR을 도전적으로 설정하고 KPI는 보수적으로 설정하라는 강의 내용을 반영했는데, KR과 KPI가 서로 일관되지 않다고 느껴진걸까요?

A. 말씀하신대로 실무에서는 KR은 보통 현실 가능한 수치의 1.5~2배 정도로 설정한다. 그리고 이런 수치는 이해관계자들과 합의 후에 결정 되기 때문에 일관성 측면은 크게 걱정하지 않아도 얼라인이 된다. 다만 과제를 진행할 때는 수치를 일치시키거나 KR과 KPI의 수치 차이에 대한 추가 언급을 하면 좋을 거 같다.

(2) Q. 데이터 중 'discount_exposed' 컬럼이 있는데, 이에 대한 해석이 사람마다 다르다는 걸 알게되었습니다. 할인이 노출되었다는 것은 제품이 할인 중인 거고, 미노출은 제품에 할인 적용이 되지 않은 거라고 이해했는데, 할인가격을 인지했는지에 대한 데이터로 해석하는 관점도 있었다. 어떤 게 맞는 건가요?

A. 새로운 해석이네요. 근데 어떤 정의가 맞다, 틀리다 보다는 중의적으로 해석될 여지가 있는 용어나 데이터에 대한 명확한 해석을 기재하는 게 더 중요합니다. 어떤 의미로 해석되고 사용되었는지, 그리고 왜 그렇게 해석했는지에 대한 이유까지 같이 기재하면 좋을 거 같습니다.

튜터님이 꼽아주신 나의 강점

• 커뮤니케이션 능력이 매우 뛰어남 - 정리를 잘하고 전달이 명확함

• 문서화 능력이 초반 대비 크게 향상됨 - 가독성이 높고 하고 싶은 내용이 잘 담겨 있음

• 원래 강점은 더 강해지고 부족한 부분은 계속 우상향 그래프를 그리며 성장 중

• 디테일한 부분들도 잘 짚어내기 시작함 - 특이점 파악 능력 향상

과제 Specific 피드백

• 장바구니 담기 전환을 위한 해결 방안으로는 좋은 접근.

• 다만 실무에서는 더 다방면으로 고민이 필요함 - 추천이 정말 득이 될지, 양날의 검이 될 수 있는 부분에 대한 보완책 고려. 무한 탐색 리스트 존재.

• 추천 상품이 유저가 실제로 살 만한 것인가?— 에 대한 다각적 고민 필요.

• (해결 방안 도출 시 더 깊게 생각해보지 못해 아쉬웠다는 말에,) 신입 1-2년차의 70-80%가 어려워하는 부분이므로 현 단계에서는 매우 잘하고 있음

개선 포인트

• 리스크에 대한 고려를 더 해보면 좋을 것 같음
• 다른 서비스들이 어떻게 하고 있는지 리서치하는 등 다방면으로 접근하는 연습

추가 조언

• "못한다"는 생각을 버릴 것 - 부족한 게 아니라 더 잘하기 위한 단계임
• 쫄면 잘하던 것도 위축될 수 있으니 자신감을 가질 것
• 문서화와 커뮤니케이션은 계속 연습할수록 좋은 능력이므로 지속적으로 발전시킬 것

사이드 프로젝트 - 아티클 카타 DB 웹 제작

사프 아이템 구체화 + 킥오프 회의

'뉴스레터' Curation vs Sorting

• 소팅

  • 기술적 학습 내용을 적용하기 좋음
  • 난이도가 높을 수 있음
  • 이미 너무 유사한 서비스 존재
  • 차별점 찾기엔 기술적 한계와 충돌

• 큐레이션

  • 수기 편집이 필요한 건 배제
  • 어차피 해야하는 아티클 카타를 활용, 컨텐츠 생성 자동화를 적용해보면 어떨까

아티클 카타 DB의 구체적인 정체성과 방향

• framer, 자동화, GA4를 활용하고 실습하기 위한 개발 프로젝트.

  • 유저를 고려한 기획은 후순위

• DB 페이지가 제공하고자 하는 것이 '아티클'인지 '인사이트'인지

  • 제 1 정체성은 아티클 모음집
  • 아티클 + 인사이트 덧붙이기

다음 스텝

• 역할분담에 대한 논의 (파트별로 리딩할 건지?)
• 레이아웃 결정: 컨텐츠를 어떻게 구성할 것인지

오늘 하루를 회고하며...

갑자기 왜 이렇게 바쁘지?

갑자기.... 바쁘다... 하지만 바쁜 거 좋아.. Framer 강의 정리는 챕터 별로 한번에 적어둘 예정. 오늘 1-6까지 들음. 진짜 바쁘네 나 이거 감당가능한가? 해야지 뭐..

AI 보조 리서치 및 문서 자동화 실습 특강

11:00-12:00 한지선 튜터님

리서치 유형

• 데스크 리서치 : 2차 자료를 통한 조사 -> 시간과 비용 절감, 거시적인 트렌드 파악
• 필드 리서치: 직접 데이터 수집 -> 유저의 페인포인트, 사용자 관점에서 서비스를 이해

필드 — 유저 리서치

• 정량 + 정성 리서치 균형있게 사용
• 설문조사: 표본/샘플 모집 후 구조화된 설문 진행
• 인터뷰: 대면, 비대면으로 경험이나 감정을 묻는 방식
• UT: 사용자가 서비스를 사용하는 모습을 관찰
  • Maze, Useberry: 사용자가 어디를 터치하는지, 어느 구간에 더 체류하는지 파악하는 도구
  • 기록 장치가 세팅 된 공간에서 UT 진행
• FGI (Focus Group Interview): 공통 특성을 가진 소규모 그룹내에서 특정 주제에 대한 토론을 진행하여 의견 수집
• 섀도잉: 사용자의 일상, 업무 환경을 따라다니면서 간섭 없이 관찰 (행동과 맥락 파악, 대상자 모집의 어려움 有)
• 카드 소팅: 사용자가 생각하는 IA 구조를 파악하는 리서치
  • 서비스의 콘텐츠, 기능 명칭이 적힌 카드를 제공
  • 참가자들은 서로 관련이 있거나 유사하다고 느끼는 카드를 묶어 그룹을 만듬
  • 분류가 끝나면 각 그룹을 대표하는 이름을 참가자가 작성

유저 리서치 진행 후 무엇을 해야할까?

• 자료 수집 후 '어피니티 다이어그램' 등을 활용해 리서치 결과 속 패턴 도출

  • 핵심 인사이트를 3~5개로 좁힌 뒤 우선순위 설정

• 조사 결과 요약 리포트를 작성하고 팀과 공유, 중요도과 긴급도를 고려하여 우선과제 선별

IDI (in-depth-interview)

• 1:1 반구조화 인터뷰
• 정해진 질문은 있지만 인터뷰이의 응답에 따라 생각, 감정, 니즈를 심도있게 질문
  • 표면적으로 드러나지 않는 속내를 파악한다.
• 30~60분 정도 진행
• IDI의 목적: 숫자가 설명해주지 않는 why?에 대한 통찰을 얻기 위해

  반구조화 vs 구조화

  구조화: 정해진 틀에 맞추기, 표준화된 방식(e.g. 객관식 설문) 반구조화: 기본적인 틀 + 상황에 따라 유연하게 진행

설문조사 — 스크리닝

• 리서치의 목적에 부합하는 참가자를 선별하는 과정 (타겟 응답자 선별)
• 스크리닝 질문은 폐쇄형 질문(객관식)으로 구성 → 명확한 기준에 따른 통과/탈락
• 스크리닝 문항은 설문 가장 첫 부분에 배치
• 스크리닝 질문은 핵심만 담아 3~5개로 제한
• 인구 통계/ 행동 기반/ 전문성 등의 기준으로 설문 목적에 맞게 질문 구성

설문조사 — NDA (Non-disclosure Agreement)

• 비밀유지계약서

1. '비밀정보'의 정의: 무엇이 비밀 정보인지
2. 비밀유지 의무: 어떻게 비밀 유지를 해야하는지 (e.g. 설문 화면 캡쳐 금지, 온라인 게시 금지, 제3자에게 구두나 서면으로 전달 금지)

어피니티 다이어그램

• 유의미한 결론을 얻기 위해 데이터를 분류하는 방법
• 다 같이 분류 과정을 거치면서 팀의 의견 얼라인
• Miro, Figjam 과 같은 툴 활용

Gemini3 & NotebookLM

• NotebookLM
  • 소스 기반 지능형 RAG
  • 사용자가 직접 제공한 문서를 기반으로 답변 생성
  • 직접 데이터나 소스를 넣고 노트북 생성 → 제미나이에서 노트북 연계해서 대화 가능

CTFCE 프롬프트 프레임워크

• Context
• Task
• Format
• Constraint
• Example

CoT: 사고 사슬 - AI가 문제를 단계별 논리 과정으로 나누어 해결하도록 ToT 다양한 경로를 탐색하고

Notebook LM으로 리서치 분석

• 소스: csv와 같은 형태의 데이터 셋, 리서치 결과 등
  • ⚠️ 설문 자료는 질문지도 같이 올려야, 질문지를 바탕으로 답변에 대한 정확한 분석이 가능

워크플로우 정리

• 리서치 사전 작업 : Gems로 리서치 설계, 설문조사 질문지 생성
• 리서치 완료 후 : NotebookLM으로 리서치 결과 분석

개인 회고

기억이 휘발되기 전에 적어두는 '취업용 커닝 페이퍼'

프로젝트 핵심 요약 (Fact)

• 프로젝트명: 배민사장님 App – 퀵 리플라이 챗봇 기획안

• 나의 역할

  • 기획 배경 정리: 왜 사장님과의 상생 전략을 선택했는지, 왜 운영 효율 지원 기술을 기획했는지에 대한 이유와 맥락을 설득력있게 정리
  • 페르소나 설계: 페르소나 프로필이 단순 페인포인트 나열이 되지 않도록 캐릭터와 상황을 부여해 문제 정의에 확실한 기준점이 될 수 있도록 설계함.
  • 발표자료 제작: 조사한 자료와 논의된 내용을 정리해 발표의 전체 흐름을 구조화 시키고, 이를 발표에 적합한 형태로 시각화함.

• 내가 담당한 핵심 지표/가설: 사장님들이 매장 관련 데이터를 한눈에 파악하고, 실제 운영 개선 행동으로 이어지게 한다면 가게의 매출이 오를 것이다.

• 사용한 도구:

  • Chat GPT: 논리구조 자문, Statement writing, 발표 스크립트 검토

PM 역량 한 조각 발굴 (Action)

[문제 정의 및 가설] "어떤 문제를 해결하고자 했나요?”

• 수수료를 올리지 않으면서 파트너와 배민 양쪽에게 이득이 되는 전략이 무엇일지 고민했습니다.
• 데이터 리터러시의 향상이 매출 상승으로 이어진다는 분석 결과를 보고 파트너의 GMV상승에서 배민의 이익을 취해야겠다는 아이디어를 얻을 수 있었습니다.
• 이미 제공 되고 있는 데이터가 많이 있음에도 활용하지 못하는 현상에서, 이러한 데이터 활용 부족을 해결하면 매장 운영 효율이 개선되고 매출 성장으로 연결될 수 있겠다는 가설을 세웠습니다.

[데이터 기반 의사결정] "가장 고민했던 '선택'과 '근거'는?”

• 초기 솔루션은 '우리가게 진단 보고서'를 카톡으로 전송하여 기존의 사용자 흐름을 최적화하고, 보고서 안에 통계 자료를 근거로 한 추천 행동 제안을 포함시키자는 내용이였습니다.
• 하지만 해당 솔루션을 적용해도'가게 통계'나 '우리가게 AI'와 같은 데이터가 여전히 분산되어 제공된다는 점이 한계로 드러났습니다.
• 사용자 흐름 최적화와 추천 행동 제안과 같은 세부적인 기능보다는 거시적 맥락에서의 개선점을 찾아야한다고 판단했습니다.
• 퍼널단계에 따른 구조적 접근을 시도했습니다. 분산 된 데이터를 한곳에 모아 사용성을 높여야하고, 이렇게 모은 데이터가 사용자에게 도움이 될 수 있어야하고, 궁극적으로 우리의 가설대로 사장님의 매출증가에 도움이 되어야한다는 기준에 맞춰 해결방안을 좁혀나갔습니다.
• 최종적으로 도출해 낸 해결방안에 대해서는 팀원분이 조사한 해외사례와 설문조사를 통해 그 실현가능성을 입증했고, 배민 CEO의 AX 발표를 인용해 기획의 임팩트에 대한 설득력을 높일 수 있었습니다.

[협업/소통] "어려운 상황을 어떻게 풀어나갔나요?”

• 의견차이가 발생한 경우, 서로의 이해가 충돌한 원인을 파악하고 이를 해소하는 과정을 가졌습니다. 내가 어떤 부분을 이해하지 못했는지, 왜 이해가 안됐는지를 자세히 설명해 상대방이 저를 충분히 설득할 수 있도록 했습니다. 서로의 주장이 완벽히 이해되면, 우리의 목적에 더 적합한 방향이 무엇인지 판별하는 것은 어렵지 않았습니다. 이러한 과정은 새로운 인사이트를 도출해 더 나은 제 3의 해결책을 제시하기도 했습니다.

Group Review

KPT 회고

Keep – 현재 만족하고 있는 부분

1. 원활한 소통

   • 의견을 내는데 망설임이 없었다.
   • 자유로운 의견 교환이 되었다.
   • 디테일한 부분도 집요하게 논의하며 싱크를 맞춘 점.
   • 모두가 균형있게 발언권을 가질 수 있게 배려한 점.

2. 모든 팀원의 적극적인 참여

   • 모두의 높은 기여도. (한명의 리딩이 아니라 모두가 자신의 파트를 리드)
   • 서로 적극적으로 도움을 주고 피드백을 나눔.
   • 카메라랑 마이크 잘 켜고 모이기로 한 시간을 잘 지켜서 진행했다.
   • 자료조사를 대충 복붙해온 사람이 없음

3. 계획대로 원활하게 진행 됨

   • 초반에 계획한대로 잘 이어짐
   • 중간에 피봇한 부분도 침착하게 잘 마무리함
   • 회의록 작성이 꼼꼼하게 이루어져서 진행 흐름을 살피고 자료를 취합할 때 용이했다.

Problem – 아쉬웠던 부분/ 개선이 필요하다고 생각되는 부분

• 우리끼리 얼마나 고민하고 어디까지 고민했어야했을까? → 이것에 대한 판단이 어려웠다
• 같은 문제를 너무 오래 고민했던 부분 → 한 문제에 대해 논의가 길어져서 회의가 늘어진 점
• PPT 자료를 만들기 전에 문서화(PRD)를 진행했으면 했는데 그게 진행이 안되어서 아쉬움 → '문서화'라는 과정도 구성원 마다 생각하는 형태가 다를 수 있다.

Try – Problem에 대한 해결책

• 전반적으로 서로의 싱크가 잘 맞춰져있는지 확인하기위해 각자 이해한 바를 한번씩 크로스 체크하는 과정이 있으면 좋을 거 같다.
• 회의 관리자의 역할: 논의가 길어질 때 진행을 관리하는 사람이 필요하다.
• 각자 정리한 내용을 회의에서 바로 공유하는 것보다, 회의 전에 서로 조사한 내용을 미리 읽어보고 회의를 진행했다면 더 효율적이지 않을까?

오늘 하루를 회고하며...

부제목

이번 팀 프로젝트도 정말 재밌게 진행했다. 모든 과정이 매끄러워서 그랬다기 보다는, 순조롭지 않았음에도 팀원들과의 시너지로 해결해나가는 과정에서 희열과 성취를 느꼈기 때문이다. 문제 정의도 여러번 고치고, 해결방안도 크게 피봇하고, 발표자료 만들면서도 끊임없이 수정하는 과정을 거쳤다. 그 과정에서 디테일하게 근거를 챙기고 다양한 관점에서 기획의 빈틈을 찾아내는 팀원들을 보며 많은 걸 배웠다. 리서치를 잘하는지 못하는지도 모르고 있던 나에게 "자료조사란 이런 것이란다 얘야"를 말 없이 보여준 팀원들 정말 리스펙...

사실 "이 정도면 됐지 대충 넘어가자"하고 넘길 수도 있는 부분도, 집요하게 물고 늘어지는 열정과 책임감 덕분에 나 역시 내가 할 수 있는 모든 노력을 기울여 과제에 임할 수 있었다. 이런 동기부여가 형성되는 게 굉장히 중요하다고 생각하는데, 그런면에서 팀원들 모두에게 정말 고맙다.

아쉬운 점은 우리 기획안에 리스크 관련 내용을 포함시키지 않았던 게 아쉬움으로 남는다. 왜 다른 사람들이 리스크 관련 피드백을 받았다는 얘기를 들었는데도 아무생각이 없었을까...? 이미 너무 지쳐있었을지도... 암튼 이런 부분 잘 기억했다가 다음 과제 때 잘 반영해봐야겠다.

일주일동안 과제하느라 힘들기도하고 정말 지치기도 했지만? 생각해보면 스트레스 안 받고 재밌게 진행했고, 결과물도 잘 나와서 너무 뿌듯하다. 팀원들이랑 추가적으로 PRD 작성해서 피드백 받기로 했는데 이것도 기대된다~!

AI Native 특강

11:00-12:00 김단비 튜터님

AI-Native

• AI 도구를 따로 쓰지 않고, 하나의 워크플로우로 흐름을 연결하는 것.
  • 모든 업무 사이클에서 AI를 쓴다.
  • 도구를 따로 쓰지 않고 연결한다.
  • 결과물은 나의 감각으로 최종 완성

AI 사용의 리스크

• 맥락을 고려하지 않아 WHY?에 대한 해답이 없음
• AI는 빈도와 가치를 구분하지 못할 수 있음
• 검토과정이 없으면 결과물에 대한 근거가 빈약할 수 있음

클로드

• 코워킹
• 아티팩트
• 클코 MCP 연결해서 바이브 코딩하기
• 토큰 관리 잘해야 된다
  • 영어 프롬프트
  • 이전 대화를 인용하면 그 전 프롬프트를 다시 다 읽으니 히스토리 관리도 신경쓰자.

배민 성장 견인 과제 - 사장님과의 상생

의문세의 탄생. 우린 안해 논쟁.

어제 새벽에 TIL쓰고 PPT 만들다가 급발진 한 나...

새벽 2시에 두서 없는 편지를 (편지 맞음) 슬랙에 던져 놓고는 오늘 아침에 눈 뜨기가 어찌나 두렵던지!

안뇽하세요; 의문세 입니당ㅋㅋ 가게 통계랑 우리 가게 진단보고서가 왜 나뉘어있지??????why; —를 시작으로 시작된 뜻밖의 회의.

문제

1. 우리가 생각한 해결 방안의 유저 플로우가 너무 복잡한 거 같다. → 정보의 쉬운 접근성 취지에 어긋남
2. 현재 제시한 솔루션이 가게 통계 데이터를 어떻게 활용하는지에 대한 합의가 이뤄지지 않았음.
3. 카톡 알림 내에서 사용자가 요청하지도 않은 보고서 내용을 인용할 수 있을까?
4. 우리가 지금 낸 해결 방안이 정말로 임팩트가 있는가?

놀랍게도 중지를 모아 1시간 반 만에 문제정의부터 짚어 내려오면서 이 모든 문제를 해결했다. amaze amaze amaze 모두의 만족스럽고 속이 후련한 표정을 볼 수 있어서 정말 다행이였음..

오늘은 지금까지의 내용을 PRD 형태로 60% 정도 정리하고 PPT 장표로 구성하는 작업을 했다. PRD로 정리하는 과정이 있어야 전체적인 흐름 잡기도 좋고 나중에 발표 대본 적을 때도 용이할 거 같았기 때문에.

배민 성장 견인 과제 - 사장님과의 상생

해결방안을 달라 Dollar sign

전날 가설설정 하면서 의견이 얼라인 된 상태라 다양한 의견 중 가장 좋은 솔루션이 뭘지 refine 하는 과정 위주로 이어졌다.

오늘 우리가 직면한 Challenge (and we made it..)

• 이미 운영중인 '우리가게 AI 분석'과의 차별점이 무엇인가? '우리가게 AI 분석'이 있는데 또 새로운 AI 모델을 개발할 가치가 있는가?

  • 우리가게 AI 분석은 마케팅 구좌에서 광고 상품을 추천하는 AI 추천 모델.
  • 우리가 제안하는 사장님과의 상생, 매출 상승 조력자의 방향과는 다름.
  • AI 컨설팅의 신뢰성을 위해서 '우리가게 AI 분석'기능과 별개로 존재해야함. (기존 서비스를 합치거나 이동 X)

• 페르소나의 디지털 사용 능력을 고려해야하는가?

  • 고려해야한다. 다만 핵심은 '데이터를 분석하고 싶지만 데이터 해석 능력이 부족함'이라는 특성이 전제 된 다음 '어플/웹을 통해 가게 매출 데이터를 확인할 수 있는가?' 를 고려해야함.
  • 혼란이 왔던 이유는 "데이터 사용능력이 좋은 사장님"과 "데이터 사용 능력이 부족한 사장님"을 먼저 정하려고 했기 때문이였다...

• 문제정의에서 언급된 '시간과 지식이 부족한 사장님'을 '시간 부족' or '지식 부족'으로 나눌까 말까?

  • 나누면 더 fit 한 해결방안이 나오겠지만 일단 일타쌍피 전략으로 가자.

멋진 회의 결과

솔루션 1. 우리가게 진단 보고서 내 AI 컨설팅

• 리포트 안에 AI 컨설팅을 추가해서 사장님들에게 액션 아이템을 제안하자.
  • 갑자기 든 의문; 리포트가 실제로 도움이 되고있는지 확인 할 수 없나?
  • 진단보고서가 출시 된 지 얼마 안됐다고는 하는데, 뭔가 서비스를 론칭한 배경이 궁금해짐. 배민도 이게 도움이 될 거 같으니까 출시했겠지...? 런칭 소식에 힌트가 없을까 찾아보기 시작.
  • 그러다가 배민 셀프서비스에 가게 통계가 있다는 걸 알게 됨. 네 가 왜 거 기 서 나 와 ?
  • 암튼 이건 뒤에 다시 정리.

솔루션 2.

• 기존의 '우리가게 진단 보고서'의 접근성을 개선하자.
• 매달 정산일에 카톡으로 '우리 가게 진단 보고서' 리다이렉트 링크를 발송하자.

솔루션 1+2 = AI 컨설팅으로 데이터 해석을 도와주고, 이런 진단 보고서의 접근성을 개선한다.

추천 시스템 특강 Pt.1

좋은 추천 시스템이란?
추천 로직의 종류

배민 성장 견인 과제 - 사장님과의 상생

문제 정의 & 가설수립
해결방안 아이데이션

배달의 민족 성장 견인

핵심 방향성 기반 데스크리서치 진행

핵심 방향성

1. 사장님과의 상생을 통한 지속가능한 성장
2. 신규 BM 발굴
3. AI 기술 적용

데스크 리서치

배민 성장의 병목 요인은 무엇인가?

https://www.digitaltoday.co.kr/news/articleView.html?idxno=656801

• 배민 mau 약 2400만 → 상당히 saturated
• 신규 유입보다는 시장 점유율 경쟁 phase
  • 점유율 경쟁 때문에 관련 비용 지출이 상당해진 상태 (라이더 확보, 무료배달 등)
  • 외형은 성장세, 영업이익은 감소 추세 → 수익성 방어(남는 장사)와 점유율 확대 일타쌍피 How??
• 수익구조가 이러지도 못하고 저러지도 못하고…
  • 점주 수익과 소비자 부담 금액이 비례. 둘다 행복하려면 어떻게 해야할까
  • 플랫폼 수익도 방어해야함.
• 이런 문제를 겪고있는 다른 양면비즈니스 사례 더 조사해보기

사장님 관점에서 살펴볼 것들

1. 수수료 민감도.
2. 노출 알고리즘 만족도
3. 쿠팡과 비교했을 때 체감되는 차이점? 왜 배민/쿠팡을 선호하는지?
4. 배민에서 잘되는 것 vs 쿠팡에서 잘 되는 것
5. 배민온리?

수익 구조

1. 멤버십, 무료배달

• 배민 한그릇 배달 https://contents.premium.naver.com/connectx/us/contents/251208235459838qm

• 배달앱 비교 2026 참고글

생각해볼 부분: 1. 어떤 주문이 돈이 되니 2. 어디서 손실이 생기니 - 쿠팡이츠 : 와우회원 유치에 활약 (쿠팡의 매출 용병은 아님)

https://www.fntimes.com/html/view.php?ud=202403221647346310b5b890e35c_18

경쟁사 쿠팡 리서치

쿠팡이츠는 ‘쿠팡’ 생태계 안에서 멤버십 구독 락인 효과를 견인하는 사업부. i.e. 쿠팡이츠 = 쿠팡 생태계 확장 배민 = 자체 플랫폼 수익 극대화

A. 시장 상황

• 배민 : MAU 2400만 / 점유율 57%
• 쿠팡이츠 : MAU 1300만 / 점유율 30% (성장률 +15.4%)

B. 각 서비스의 목표

(1) 쿠팡이츠 : 쿠팡 전체 생태계의 LTV 극대화

• 배달 자체 수익 보다 와우 멤버십 유지율 락인을 통한 쿠팡 전체 매출 증가
• 무료배달 → 주문 증가 → 멤버십 유지 → 전체 커머스 매출 증가

(2) 배민 : 배달의 민족 수익성 향상

• 광고 + 수수료 + 거래수익
• KPI
  • 주문 당 수익
  • 광고 매출
  • 점주, 주문자 retention
• 트래픽 → 광고 → 수익

C. 시장 내 포지셔닝

쿠팡이츠 : “적자 감수하고 시장 먹기” 배민 : “수익 유지 (남는 장사) 하면서 점유율 유지”

• 쿠팡이츠: 보조금 투입→ 무료배달→ 신규 유저 강하게 유입 중.
• 쿠팡의 공격적인 보조금 정책에 대응하는 배민의 무기는 다음과 같다
  • 주문 유저 관점: ‘익숙함’, ‘브랜딩’, ‘UX최적화’
  • 점주 관점 : 안정적인 트래픽 (광고비 리스크를 부담하면서도 배민을 선택하는 이유) → ⚠️ 점주가 단기 매출 증가를 원한다면 쿠팡이 더 나은 선택지가 될 것.

D. 경쟁구도

경쟁 분야: (1) 퀵커머스, (2) 1인분 배달, (3) AI 개인화 추천 고도화

1️⃣ 퀵커머스 - 더 자주

• 배민
  • B마트 → MFC 기반 유통 경쟁력 (자체 물류 창고에서 보관하는 재고 기반으로 유통 최적화를 통해 가격 경쟁)
  • 장보기·쇼핑 → B마트가 다져놓은 시장 내 입지를 퀵커머스로 확장
• 쿠팡이츠
  • 입점 가게 수, 제품 범위 확장
  • 장보기/ 꽃/ 반찬/ 생활용품 (심지어는 가발까지..!)
  • 포지셔닝 전환 : 식사 앱 → 생활 앱

경쟁 구도 해석 : 사용자가 앱을 여는 시간 쟁탈전. 누가 하루를 더 많이 점유하느냐의 싸움.

2️⃣ 1인분 - 더 쉽게

• 한그릇 (배민) VS 딱 1인분 (쿠팡이츠)
• 점주 입장에서…
  • Bright Side: 입점이 늦은 가게에게 경쟁 기회 제공, 단기적 매출 향상 효과有
  • Down Side: 사장님들의 FOMO 자극, 초반 지원 제도가 끝나면 점주 부담 커질 우려.
    • 박리다매 전략을 취해도, 마진은 낮고 세금은 불어나는 부작용
  • 배민은 사장님 상생 키워드를 강조하지만 정말 상생일까?

• 1인분 주문 기능이 왜 생겼을까?

3️⃣ AI 추천 고도화 - 더 비싸게

과제 - 장바구니 담기 전환 데이터 분석 & 개선안 제안

최종 정리 + 문서화

그간의 분석 내용 취합

• 전체 유저 대비 광고로 유입 유저의 장바구니 전환율과 오즈비 산출
  • 페르소나 D를 설정한 것에 대한 설명
• pdp 이전 페이지 타입에 따른 장바구니 담기 전환율 그래프화

페르소나 구체화

• 프로필과 페인포인트 작성..

해결방안과 KPI 설정

• BTF 영역에 유사 상품 추천 영역 추가를 해결방안으로 제시.
• 이에 대한 KPI를 다음과 같이 선정.
  • PDP → 장바구니 전환율
  • 추천 영역 클릭률 (CTR)
  • 추천 클릭 후 전환율
  • PDP 이탈률
• 각 지표에 대한 수치는 클로드가 계산해줌 ㅎㅎ

와이어프레임 (제출 30분 전에 휘갈기다..)

• MVP 내용 정리해서 챗지피티에 넣었더니? 무슨 마크다운을 줘서 그걸 클로드한테 가져감.
• 사랑아 클로드해 🫶🏻

Day 29 (6주차)

페인포인트 & 페르소나 찾기 특강

11:00 - 12:00 김단비 튜터님

Overview

PMF를 찾으려면 유저의 페인포인트를 정확히 짚어야함. 다양한 프레임워크를 사용해서 페인포인트를 통해 발견할 수 있다. 페인포인트를 발견하면 합리적인 근거로 우선순위를 평가해 선결과제를 찾아내야한다.

페인포인트와 니즈

• Needs: 제공하면 만족 → 니즈 충족 x → 아쉬움 👎🏻
• Pain Point: 개선이 필요한 부분 → 페인포인트 해결x → 이탈 😱

페인포인트에서 니즈를 도출할 수 있어야한다. (and vice versa..)

• 고객도 자기가 뭘 원하는지 모르는 경우가 많음 (e.g.)
• "가격 비교를 못해서 저렴한 상품 찾기가 어려워요."* → 추론: 유저는 최저가를 찾는다 → 도출된 니즈(선결 과제): 최저가 보장제 실시

1. 페인 포인트 발견 - 프레임워크

Macro Approach (시장·산업 관점)

1. 정성적 방법 (0 to 1 기획 단계)
   • PEST 분석: 정치, 사회, 경제, 기술 환경을 분석하여 거시 트렌드에서 고객 과제를 유추함.
   • 3C 분석: 자사(Company), 경쟁사(Competitor), 고객(Customer)의 동향 파악.
   • SWOT 분석: 강점, 약점, 기회, 위협을 나열하여 전략적 과제 도출.
   • 데스크 리서치: 전략의 방향성 확인.
     
2. 정량적 방법 (입사 후 실무 데이터 확인 시 유용)
   • 재무제표 분석: 기업의 건전성 및 투자 여력 파악.
   • 사업보고서 해독: 이전 KPI를 추적하며 과거의 성공과 실패 사례 분석.
   • 경쟁사 비교: 시장 내 위치 확인.

Micro Approach (고객 중심 관점)

• UT (Usability Test): 사용성 테스트를 통한 직접적 불편함 발견.
• VoC (Voice of Customer) 분석: 고객 상담 및 문의 데이터를 통한 리얼 보이스 추출.

2. 페인 포인트 검증 - 체크리스트

• 대안: 사용자가 현재 어떤 우회 방법을 쓰고 있는가? (기회 영역 탐구)
  • 수작업 우회가 많을수록 해결 시 기회가 큼.
• 지불의향: 이 문제 해결을 위해 비용을 지불할 의사가 있는가? (비즈니스 가치 검증)
• 확산성: 얼마나 많은 고객에게 도달(Reach)할 수 있는가? (사업 규모 파악)
• 측정가능성: 해결 후 개선 여부를 어떤 지표로 확인할 것인가?
  • 측정이 어렵더라도 반드시 측정 가능한 KPI를 설정해야 함.

PM이 빠지기 쉬운 함정

주니어 단계에서 특히 주의해야 할 포인트!!

• 내부 의견의 페인 포인트화: 특히 내 개인적인 의견을 고객 전체의 의견으로 착각하지 말 것.
• 소수 의견에 휘둘림: 1인의 강력한 의견보다는 최소 3~5명의 패턴 일치를 확인해야 함.
• 솔루션 우선주의: 기획이 솔루션에서 출발하면 엉뚱한 문제를 풀게 될 수 있음.
  • 솔루션을 먼저 떠올려도 좋으나, 문제 정의와 KPI가 해당 솔루션과 얼라인되어야 함.
• 현상에만 매몰: 표면적인 현상 너머의 근본적인 원인을 파악해야 함.

3. 페르소나: "누구의 문제를 풀 것인가"

주의사항: 페르소나는 1~2개에 집중하며, 이상적인 모습이 아닌 '현재 진짜 고객' 기반으로 설정하는 것이 좋음.

<STP 프레임워크>

• Segmentation(세분화): 사용자를 공통된 니즈나 특성을 가진 그룹으로 나눔.
• Targeting(타겟팅): 세그먼트 중 누구를 우선적으로 공략할 것인지 선택.
• Positioning(포지셔닝): 타겟 사용자의 마음속에 차별화된 서비스로 인식시킴.

작성 프로세스

1. 데이터 수집: 데스크 리서치, 정성·정량 데이터 활용.
2. 패턴 식별: 공통 행동 및 특성을 기준으로 그룹화.
3. 프로필 작성: 대표 그룹에서 구체적인 인물상을 도출.

프로필 구성요소

1. 기본인적사항
2. 목표와 동기(JTBD): 우리 제품/서비스와 관련해 궁극적으로 이루고 싶은 일을 정의
3. 페인 포인트: 목표 달성에 가장 큰 장애물, 불편사항
4. 현재 어떤 행동을 하고 있는지
5. 대표 인용구

4. JTBD: "서비스의 동기를 발견하자"

고객은 제품의 기능을 사는 것이 아니라, 자신의 과업을 해결하기 위해 제품을 고용한다.

• 과업의 종류: 기능적 과업, 감정적 과업, 사회적 과업.
• 성공 공식: 페인 포인트(불편) + 게인 포인트(이득)를 동시에 공략.

연결 고리: 페르소나(누구) → JTBD(왜 고용하는가) → 페인 포인트(과정 중의 문제) → 게인 포인트(이상적 해결 상태) → 솔루션 설계

5. [Case Study] 심리상담소 플랫폼

• 양면 플랫폼의 특징: 공급자와 수요자 페르소나를 분리하되 둘의 연결고리를 찾는 것이 핵심.
• 우선순위: 일반적으로 공급자를 먼저 확보하는 것이 플랫폼 활성화에 유리함.

과제 - 장바구니 담기 전환 데이터 분석 & 개선안 제안

가설 및 해결방안 (완전 생각의 흐름대로 메모 해놓은 거)

<과제 로드맵>

1. 페르소나 설정 ✅

2. 데이터 추출 🎯✅

3. 데이터 분석🎯✅

🔍 Advanced 페르소나별 (A~D) 행동패턴 차이를 데이터를 통해 분석해보기

4. 가설 및 해결방안

페르소나 설정 ~ 데이터 분석 요약

• 리뷰클릭은 장바구니 전환 상승효과, 할인노출은 영향X

• 전체 사용자의 패턴에서 장바구니 전환에 가장 큰 영향을 미친 변수는 previous_page_type.

  • pdp 이전 페이지가 홈페이지인 경우 전환율이 가장 높게 나타남. OR 1.83, C.V 0.167
  • 이게 무슨 말이냐, 홈페이지를 보고 pdp로 온 고객일 수록 탐색을 통해 서비스에 대한 신뢰와 확신이 생긴 상태라 장바구니 전환이 잘 된다는 말~
  • 그니까 광고로 유입을 해도 바로 pdp를 본 거보다는 서비스에 대한 신뢰를 쌓는 탐색과정을 경험하게 해야된다는 거지.
  • 그렇다면 이 의미있는 홈페이지를 단순히 랜딩 페이지로 쓸 것이냐, 아니면 더 적극적으로 사용자에게 다가가는 채널로 쓸 것인가 생각해봐야함.

Intent

• 페르소나 D: 브랜드나 서비스에 자발적으로 진입한 오가닉 유저, 특정 니즈가 생겨서 능동적으로 탐색하는 검색 유입 유저와는 다른게 프로모션을 통해 유입 된 광고 유입 유저임.
• 역시나 재방문 유저가 신규 유저보다 더 높은 전환율을 보임. -> 서비스에 대한 인지와 신뢰가 크게 작용한다는 사실을 알 수 있음.

Engagement

• 신규 사용자 중 광고 직진입인 경우 장기 체류가 단기 체류보다 전환율이 낮게 나옴

  • 신규, 장기 체류 근데 검색결과인 유저는 전환율이 높음.
  • 이것이 시사하는 바는 무엇인가?

  1. 광고에서 바로 pdp 진입은 전환에 불리하다.

     • 관심은 있지만 확신은 없음
     • 광고와 pdp 정보 사이에 간극이 있을 수 있음.

  2. 광고로 유입된 사용자가 내부 탐색을 거치는 흐름은 전환을 상승시킨다.

  3. 전체적으로 봤을 땐 search_results의 OR이 광고페이지 대비 0.91로 전환에 유의미한 역할을 하지 못하는 것 처럼 보이지만, 우리의 페르소나는 "비교"활동을 수행중인 고관여 유저시다. search의 효과가 과소평가 되어 적용될 수 있으므로 전체의 통계는 무시하겠다.

  homepage vs search

  • homepage : 수동 탐색 (노출 기반)
  • search : 능동 탐색 (의도 기반)

ㅇㅋ 그럼 어떤 전략을 짜야될지 생각해보자. 광고로 유입된 비교 분석 형 유저... 일단 검색을 하도록 유도해야함! 광고 유입이니까 뭔가 프로모션 페이지로 랜딩이 되겠지? 그럼 그 페이지에서 검색 결과/ 카테고리 탐색을 하게끔...

아이허브의 카테고리 내 몇 위인지 알려주는 거 처럼...? 근데 이게 패션 커머스에 어떻게 적용되지?

• 광고 유입 유저의 특징& 차별점

  • 구매 전 맥락이 없음, 처음 보는 쇼핑몰에서 강력한 구매 동기도 없는 제품을 장바구니에 담을 이유가 없음.
  • 광고에 대한 기대값이 일치하지 않는 페인포인트
  • 262명 중 134명이 신규유저
  • 중간체류 구간에서 전환율은 9~12%까지 떨어짐 (전체 사용자 통계보다 가파르게 하락)
  • 정보는 보고있는데 결정을 못한다? -> pdp내에서 비교 판단에 필요한 정보를 충분히 얻지 못하고 있을 가능성.
    • 근데 리뷰가 긍정적으로 작용하니까.... 리뷰를 좀 개선해볼까?
    • 패션에서는 착용샷, 사이즈, 그리고 소재가 가장 중요함.
    • 근데 리뷰가 없을 수 도 있잖아. 억지로 만들 수도 없고. MD 리뷰? 너무 짜쳐.
    • 그럼 비슷한 스펙의 제품 리뷰를 합쳐서 보여주는 거지.

• 전략

  • 광고 랜딩 - pdp 메시지 연속성
  • 신뢰 형성 단계가 중요. 리뷰, 구매자 수, 반품 보장 같은 신뢰 형성 요소를 pdp 상단에 배치.
  • 24~48시간 내 리타겟팅 광고

  가능한 전략들...

  1. 리뷰 시스템 개선
  • 광고 유입 비교 사용자는 서비스에 대한 정보가 다른 군에 비해 부족함. 검색결과 페이지에서 pdp로 넘어오는 흐름에서 장바구니 전환이 크게 나타나는 것도 사용자가 탐색 과정을 통해 제품 선택에 대한 확신이 생겼기 때문. 그렇다면 pdp 페이지에서 동일하게 탐색의 경험, 확신을 갖게 하는 장치가 있으면 장바구니 전환율이 상승하지 않을까?

PRD Outline

Objective: 장바구니 담기 전환율 상승

KR : 신규 유저 중 광고로 유입된 사용자의 장바구니 담기 전환율 16.7% →28% (11.3%pp 상승)

왜? Objective를 달성해야하는 이유

1. 왜 장바구니 전환율이 중요한가 - 향후 리타게팅 마케팅 전략에 성과를 극대화하기 위해서는 사용자들이 장바구니에 제품을 많이 담아야함.

무엇을? 문제 정의, 필요한 기능

1. 문제정의 : 페르소나 D와 같이 비교 탐색을 통해 구매를 결정하는 사용자가 서비스에 대한 경험이 없는 상태에서 PDP로 랜딩한 경우, 충분한 비교와 탐색 경험을 하지 못해 구매 맥락 형성이 안됨.

2. 페르소나D 설명

   광고로 유입된 사용자. 외부 사이트와 비교 후 구매를 결정한다. 신규 유저, 패션 관심, 옷을 살 땐 가격, 핏 , 소재 등을 꼼꼼히 체크하고 구매하는 유형

3. 데이터 분석을 통한 인사이트 → 페인 포인트 추론

   상세 페이지에서 제품에 대한 설명을 봐도, 내가 착용했을 때 어떨지, 내가 갖고 있는 아이템과 어울릴지 잘 모르겠음.

   제품을 바로 장바구니에 담아도 될지? 더 마음에 드는 옷이 있지 않을까? 라는 의심.

   → 해당 제품을 시작으로 탐색흐름을 만들어야함.

어떻게? MVP의 범위

1. fashion 카테고리의 제품에 ‘나만의 룩 완성’과 ‘비슷한 상품’ 캐러셀로 구성된 큐레이션 보드를 ATF 바로 하단에 배치. (아래 레퍼런스 참고해서 와이어프레임 짜기)
2. 비슷한 상품 추천은 fit, color, mood 3가지로 나눠서 총 4열의 캐러셀.
3. 비슷한 상품 → 라이팅 고민해봐야함.
   1. 고객님을 위해 준비한 상품
   2. 함께보면 좋은 상품
   3. you may also like…

각 섹션별로 로그를 분리해서 수집 → 매칭아이템, fit, color, mood 수요 파악

평가는? 성과 측정에 대한 지표

큐레이션 보드의 제품을 클릭한 유저의 장바구니 전환율 n% 상승

광고로 유입 된 사용자의 큐레이션 보드 이용률 n%달성

오늘 하루를 회고하며...

와 오늘 진짜 집중 안됐다!

오늘 내가 제일 좋아하는 유투브 채널에 근래 가장 기다리던 컨텐츠가 올라오는 바람에... 그리고 하필 점심에 마라탕을 먹으면서 그걸 보는 바람에... 하루종일 과제고 뭐고 그냥 놀고 싶었다. 나의 선호도에 대한 의지의 크라메르v 값은 0이여야하지만, 오늘은 1이였다. (한층 유식해진 나 어떤데;;) / 아무튼. 어느순간 그냥 빨리 끝내버리자는 생각이 들었다. 이미 며칠동안 충분히 깊이 있게 분석한 거 같으니까 더 깊이 고민하지 말고 분석한 내용 빨리 취합해서 제---발 결론을 내자고 self-talk을 함.(literally spoke out loud..) 그랬더니 진짜 해결방안이랑 가설이 얼추 나옴;; 너무 홀라당 결론이 났나? 싶어서 으심캣이 됐지만 이내 생각을 고쳐 먹었다. PRD란 자고로 정답 맞추기가 아니니 애자일하게 가자고 말이다. / 한 스텝 한 스텝 거칠 때 마다 지피띠니랑 클로드한테 검토받는 짓을 했더니 이건 뭐 돌다리도 두들겨 보고 건너는 걸 넘어서 두들기다가 박살낼 판. 고로 지금부터 나를 믿고 속도감있게 강행시키겠다. 내가 못해봤자 얼마나 못하겠냐. 야! 너 잘하고 있어. 자신감을 가져!

아티클 카타 - 설득

‘설득하기’만큼 ‘설득 당하기’가 중요한 이유

인상적인 팀원들의 문장:

• 좋은 PM은 설득을 잘하는 사람이 아니라, 더 나은 의사결정을 위해 기꺼이 설득될 수 있는 사람이다.
• 비판적 사고를 할 때에도, 전달하는 입장에서 그 사람에 대한 비판이 아닌 의견에 대한 비판이라는 것이 느껴지도록 얘기하는 방법을 익히는 것도 중요할 것 같다.

수빈님이 소개해 준 심리학 개념:

• 집단 사고(Groupthink)
• 악마의 대변인
  
  

범주형 데이터 분석

크라메르v , Odds Ratio(오즈비)

<TL;DR>

• 크라메르 v: 범주형 데이터 사이의 연관성이 얼마나 강한지 (0~1)
• 오즈비: 원인이 결과에 얼만큼 기여했는지
• 확률과 오즈 = 이길 확률과 승률

<크라메르 V>

• 범주형 데이터 간의 연관성이 얼마나 강한지 알려주는 지표

• I.e. 크라메르V 값이 크다 = 변수 A가 변수 B를 설명하는 힘이 세다.
  • 💡 타겟팅의 확실한 근거로 활용가능

⚠️ 해석 할 때 주의할 점

• 범주가 많아질 수록 실제보다 높게 나오는 경향이 있다.
• 특정 항목에 데이터가 부족한 비대칭적 상황에서는 신뢰도가 떨어진다.
• 연관성에 영향을 주는 제 3의 변수를 염두에 둘 것.

<오즈비 (Odds Ratio)>

확률(p)와 오즈의 차이를 짚고가자..!

P= $일어난 사건\over 전체 사건$ = 이길 확률 (절대적) Odds = $일어난 사건\over 일어나지 않은 사건$ = 승률 (상대적)

확률 대신 오즈를 쓰는 이유?

• 확률은 전체 중에 몇 %인지 결과 중심으로 현상을 보고할 때.
• 오즈는 원인이 결과에 얼만큼 기여했는지 알 수 있음.

OR = $분석군 A의 오즈\over 비교군B의 오즈$

예시 Case

• 분석군 (A안): 상단 버튼 사용 유저 (구매 20, 미구매 80) → 오즈 = 20/80 = 0.25
• 비교군 (B안): 하단 버튼 사용 유저 (구매 10, 미구매 90) → 오즈 = 10/90 = 0.11
  이 경우 오즈비는 $0.25 / 0.11 \approx 2.27$ 이 나온다. 1보다 크기 때문에 "상단 버튼이 하단 버튼보다 결제 승률을 약 2.27배 높였다"고 해석할 수 있음.

왜 확률대신 오즈비를 쓸까?

• 확률은 여러 변수가 섞여서 원인-결과가 명확하지 않음
• 오즈비는 특정 변수의 순수한 기여도를 뽑아내기 때문에 변수 컨트롤 가능.
  
• 확률은 모수에 의존
  • 예를 들어 0.1% 짜리 지표가 0.2%로 성장하면 2배 성장이지만 0.1%p 상승률로 나타나 기획의 영햑력이 축소 될 수 있음.
    
• 🌟 비즈니스 측면: 실패확률 대비 성공확률을 따지는 게 의사결정에 유리함.

실무에서의 활용

• 크라메르 V : 세크먼트를 나눌 만큼 유효한 상관관계를 지니는가?

• OR : 특정 요인이 결과에 기여하는 배수가 비용대비 효율적인가?

• OR 지표를 설명할 때, "확률이 N배 높습니다" 라고 말하면 혼동이 올 수 있음.

  • 발생 확률이 낮은 데이터에는 확률과 오즈가 거의 비슷해 크게 지장X
  • 발생 확률이 높은 데이터에서는 "발생할 상대적 가능성이 높다" 혹은 "강력한 상관관계가 관찰된다"고 표현.

과제 - 장바구니 담기 전환 데이터 분석 & 개선안 제안

Data Analysis

<과제 로드맵>

1. 페르소나 설정 ✅

2. 데이터 추출 🎯

• 페르소나에 해당하는 유저를 추출

  3. 데이터 분석🎯

• 페르소나 조건에 부합하고 전환율 상승과 관련된 데이터를 골라서 분석 🔍 Advanced 페르소나별 (A~D) 행동패턴 차이를 데이터를 통해 분석해보기

  4. 가설 및 해결방안

전체 사용자의 행동 패턴 분석

1. 리뷰 클릭은 장바구니 전환에 영향을 준다.

2. 할인 노출은 장바구니 전환에 영향을 주지 않는다.

3. 장바구니 전환에 가장 유리한 행동패턴은?

• TL;DR: 홈페이지에서 pdp 진입 유저, 가격대 — U자형 패턴, 오가닉 유저, 리뷰 클릭 장바구니 전환율에 유의미한 작용을 하는 변수는 이전 페이지 유형, 가격대, 리뷰 클릭으로 나타났다. 이 중 가장 강한 영향력을 미치는 변수는 이전 페이지 유형이다. 그 다음으로는가격대, 리뷰 클릭 (🤔❓ 유입 채널은 왜 3위지?)
  ⬇️ 위 변수들이 실제로 얼만큼 전환율에 기여하는지를 알아보기 위한 오즈비 분석

🥇 이전 페이지 유형 (previous_page_type) p < 0.001, Cramér's V = 0.167

🥈 가격대 (price_band) p = 0.004, Cramér's V = 0.105

🥉 유입 채널 & 리뷰 클릭 p = 0.025 / 0.008

오가닉 유입 유저의 전환율(36.9%)이 광고 유입(27.9%)보다 높고, 리뷰 클릭도 앞서 검증한 것처럼 유의미합니다. 둘 다 Cramér's V가 0.08~0.09 수준으로 효과 크기는 약한 편이지만 통계적으로는 유의합니다.

페르소나 D — 유저 추출 & 분석

• 광고 유입 유저 중, 타 플랫폼 비교 여부는 직접 관측할 수 없지만 비교 쇼핑 맥락이 개입되었을 가능성이 있는 사용자 패턴을 탐색하고자 한다.
  
• '광고 유입 비교 유저' → 비교라는 단어의 해석에 주의 할 것!
  • 🙄왜냐미욘,,,, 다양한 해석 like, 서비스 내부에서 비교/ 타 서비스와 비교, 비교를 완료하고 돌아온 유저/ 비교를 하러 떠나는 유저 등등의 케이스가 있기 때문~~
    
• 이 데이터셋에는 "비교 쇼핑을 했다"를 직접 관측할 수 있는 변수가 없다. 따라서 아래 모든 패턴은 행동 신호의 조합에서 맥락을 추론한 것

1. 광고 유입 (+가격 비교) 유저 분석

• 광고 유입 유저 중 가격 비교 맥락이 개입되었을 가능성이 있는 유저는 총 81명 (전체의 30%)

• 이를 총 8개의 패턴으로 구분한다.

  2. '광고 유입 + 가격 비교' 행동 패턴 분석

• 비교 쇼핑 맥락이 가장 강력한 유형 (이상적인 Case)

  • 재방문 유저가 신규 유저보다 더 높은 전환율을 보임.
  • "한 번 봤던 상품을 검색을 통해 다시 찾아와서 리뷰까지 확인했다"는 행동 조합 자체가 데이터로 확인되고, 그 사이에 외부 비교가 있었을 가능성은 추론입니다.
  • 고가 상품(30만원 이상) 비중이 58%로 높아 신중한 구매 결정과 연결될 수 있다.

• 장바구니 전환 동기가 강한 타입

  • 재방문 + 홈페이지 진입 -> 서비스에 대한 신뢰와 관심이 형성 된 부류
  • P4 = 비교를 마치고 구매를 목적으로 재방문 했을 가능성
  • P8 = 저관여 상품에 대한 구매 결정이 빠른 부류

P2(신규 × 광고직진입 × 장기체류)는 P1(단기체류)보다 2.5배 오래 머물고 리뷰도 더 많이 봤는데 전환율이 오히려 낮습니다(16.7% vs 20.0%). 많이 탐색할수록 결정을 미루는 패턴으로, 재방문 타겟팅 대상군으로 볼 수 있는 세그먼트입니다.

3. 어떤 패턴의 사용자를 타겟할까?

P2 유저를 공략하는 전략. 왜? - 장기 체류 후 이탈하는 유저는 추후 재방문으로 전환하기 어려움. 현재 데이터 셋으로는 장/단기 체류 후 이탈한 유저의 재방문율을 알 수 없음.

• 확인해볼 데이터 :
  • [행동 시그널] review_clicked, discount_exposed, price_band 장기 체류 유저가 리뷰도 보고 할인도 봤는데 여전히 이탈하면 결정을 저해하는 요인이 있다는 증거가 됨.

가설 및 해결방안 (러프한 아이데이션)

• P2 유형은 광고 직진입 후 평균 74.7초를 체류하며 리뷰까지 확인하는 등 탐색 행동이 충분히 나타났지만, 전환율은 16.7%로 광고 유입 평균(27.9%)보다 낮다.

• 이는 탐색 의향은 있으나 전환을 완료하지 못한 유저군으로 해석되며, 마지막 결정 단계에서의 장벽 제거가 핵심 과제가 된다.

• 세션 종료 직전 장바구니 넛지나 24시간 내 리타겟팅을 통해 이미 형성된 구매 의향을 전환으로 연결하는 전략이 유효할 것으로 기대됨.

넛지 레퍼런스 1.

📄참고자료 카카오 브랜드 메시지로 장바구니 이탈을 줄이는 방법

오늘 하루를 회고하며...

생각과 행동의 싱크를 맞추자

뭔가 한 건 많은데 과제 진도가 안 나갔다. 지난 과제 때 만큼은 아니지만 또 spiraling 하는 습관이 나타난 거 같다. 뭔가 빠르게 결론으로 챡챡 나아가야 하는데, 자꾸 한가지를 집요하게 붙잡고 있어서 그런 거 같다. 다 장단점이 있겠지만 너무 속도가 안 붙으면 몰입이 깨져서 적당히 밸런스를 맞출 필요가 있다고 느낌.. / 과제 진도와는 별개로 데이터 분석에 대한 새로운 개념을 익히는 게 너무 재밌다. 내가 직접 데이터를 해석을 할 수 있게 되니까 전체적인 맥락도 이해가 잘되고, 내가 내리는 판단에 자신감을 가질 수 있는 게 너무 좋다. / 오늘은 등 운동 하는 날...운동 다녀와서 1시까지 과제 하는 걸로~ Keep being gwenchana, even tho your life is @#$@#

아티클 스터디 w/ 열정즈

혼자 더 많이 할 수 있게 된 뒤, 협업이 가지는 가치를 돌아보며
협력이라는 '비효율'이 주는 위대한 배움

TL;DR

• 협업은 답을 찾는 과정보다 관점을 조율하는 과정.

• AI를 활용으로 개인이 더 많은 영역을 혼자 해결 할 수 있게 되면서 업무의 효율성은 크게 비약한 것 처럼 보인다.

• 하지만 협업은 나와 다른 관점을 발견하는 과정이라는 점에서 그 역할이 축소되면 안된다.

• AI활용으로 얻은 효율을 기반으로 더 밀도있는 협업을 진행해야함.

PM's Perspective

• 협업을 통해 관점의 차이를 발견하는 것은 업무를 느리게 만드는 비효율적인 과정처럼 느껴지지만 사실은 더 좋은 판단을 내리기 위한 과정이다.

• 오히려 생각의 차이가 드러날 때 협업의 의미가 생긴다.

Critical Reflection in Team

• AI를 업무에 활용하면서 1인 업무 체계로 고립될 수 있음. 사람간의 만남에 뚜렷한 이유가 필요해질 것이고, 의견을 나눌 의미가 있는지 의심하게 될 것.
  
• 이런 환경에서 협업을 잘 이끄는 것이 PM에게 주어진 과제. (상대는 AI다..)
  • 항상 강조되는 '목적의 명확성'이 같은 맥락에서 또 다시 적용된다.
    
• 대 AI 시대, 우리는 오히려 더 여러방면으로 사고하는 능력을 갖춰야함.
  • 인문, 교양, 문화적 소양을 갖춰야 장기적인 성장이 가능할 것.
    
• 애초에 글쓴이가 문제의식을 가진 부분은 AI로 인해 발상의 영역이 좁아져서 창의적이고 혁신적인 아이디어를 만들어내는 데 제한이 생긴다는 점
  • → 협업의 역할을 보존 하더라도, 그 테이블에 가지고 가는 나의 아웃풋이 AI의 것인지 나의 것인지 점검해야함.
    
• 나의 아웃풋이 되려면 프롬프팅에 내 판단이 들어가야함 (AI의 판단을 최소화 하자)
  • 하네스 프롬프팅도 같은 맥락에서 나온 개념 같기도 하고..?
  • 기존 프롬프팅이 “해줘” 라면, 하네스는 “이렇게 하지마” 니까 좀 더 사용자의 판단(해도 될 것과 안되는 것)이 개입된 프롬프팅 기술이라고 볼 수 있지 않을까.
    
• AI에 자아의탁하는 멍청이들이랑 일해야하는 상황이 분명 있을 것.
  • 살아남으려면 그들이 놓치는 부분을 커버칠 만큼 나의 역량을 키워야함.
  • 오히려 기술적인 스킬 보다는 사고력이 중요해질 것. (기술이야 유투브 보고도 배울 수 있는 것)

AI 기획 + 데이터 분석 특강 Pt.2

If Kakao 컨퍼런스 자료를 통한 카카오의 콘텐츠 운영 워크플로우 개선기

<Pt.1 recap>

• 머신러닝 모델을 학습시키기 위해서는 원천 데이터를 수집하는 것 만큼 데이터 전처리가 중요함.
  • 비지도 학습 - 정답이 딱 정해져있지 않는 업무 지도 학습 - 정답이 중요함 (e.g. 카테고리 분류)
    
• 학습을 위해 데이터를 업데이트 한다 -> 훈련, 점검, 테스트 데이터

<학습 셋을 운영하기 위한 어드민 개발>

Q. 오분류에 대한 평가는 모델 테스트 과정에서 이루어지나요? 아니면 최종적으로 사람이 검토하나요?

A. 오분류는 두가지 타임라인에서 이뤄짐 (휴먼 리소스가 요구되는 단계들)

1. 학습과정에서; 학습 데이터셋의 일부를 테스트셋 (aka 정답 셋)으로 사용. 테스트 과정에서 오답률이 얼마나 나오는지 학습과정에서 모니터링.

2. 실제 배포 후 모니터링; 모델의 학습을 관리하는 어드민 페이지가 존재. 관리자가 카테고리를 수동으로 수정한 케이스는 오분류 케이스로 입력됨. 오 분류 케이스는 추후 학습에 다시 사용.

자동 분류가 적용되지 않는 예외 케이스, 학습의 일관성 -> 여러 측면을 고려해야하는 엣지 케이스에 관해 많은 논의를 거치게 됨

모델이 안정기에 접어들면 모니터링, 운영 관리에 투입되는 휴먼리소스는 줄어들지만 아예 모니터링 과정이 사라지는 건 아님.

<머신 러닝의 한계>

• 신규 제이터 학습과 같은 측면에서 한계가 존재했음.

• 그래서 머신러닝 + 룰 매핑 기술을 도입함.

  • downside: 룰을 관리하는 데 리소스가 듬 (엣지케이스가 없어야함)

• 최종적으로는 여러가지 ML + 룰 매핑 구조를 적용함.

  • 모델간의 만장일치기가 이루어지면 룰매핑을 이길 수 있음 (이거 완전 마기잔슴;;)

<AI PM은 그럼 뭐가 다른데?>

1. 문제정의
   • AI 도입 시 ROI 설정 (e.g. 인건비 절감, 업무 효율화)
   • '꼭 AI여야만 하는가?' 에 대한 판단
2. 데이터 수집
   • 학습에 사용되는 정답 데이터의 기준을 정한다.
   • 법적/윤리적 문제 고려
3. 데이터 전처리
   • 데이터 전처리를 위한 정책과 가이드라인 수립
4. 모델 학습
   • mvp 기준에 부합하는지
   • 비용을 최적화 할 수 있는 방법을 모색
   • 모델을 배포하면 초반에 업무 로드가 더 늘어날 수 있다. 따라서 어느 정도의 학습이 필요한지, 어느정도의 퍼포먼스를 기점으로 실배포를 할 것인지에 대한 기준을 정해야함.
5. 예측/평가

• 모델의 판단 결과를 서비스 ux에 녹여내는 최종 설계

<AI PM에 관심이 있다면, Follow-up actions>

• 평가지표와 머신러닝 학습 방식을 더 알아보자.

과제 - 장바구니 담기 전환 데이터 분석 & 개선안 제안

Persona & Data Analysis

<과제 로드맵>

1. 페르소나 설정 ✅

2. 데이터 추출

• 페르소나에 해당하는 유저를 추출

  3. 데이터 분석

• 페르소나 조건에 부합하고 전환율 상승과 관련된 데이터를 골라서 분석 🔍 Advanced 페르소나별 (A~D) 행동패턴 차이를 데이터를 통해 분석해보기

  4. 가설 및 해결방안

• 이커머스 서비스 레퍼런스로 참고하기 (아이디어 실현 방안 등)
  • 퀸잇, 오아시스 마켓, 젠테스토어
• 해결방안은 현실적으로
  • UIUX 개선: lo-fi 와이어프레임 제시
  • A/B Test : 테스트 계획 및 설계까지 포함

<데이터 분석 이론 - 카이제곱 검정>

!youtube[lmNZr1EDyNA]

'관측'과 '기대'

• 기대값: 이론적으로나 상식적으로 예상되는 결과
  • e.g. 동전을 던져서 앞면이 나올 확률은 50%. → 동전을 100번 던지면 앞면이 50번 나올 것이라고 기대.
  • 즉, 아무런 특별한 이유가 없다면 공평하게/일반적으로 나타나야 할 수치
    
• 관측값: 실제 발생한 현상에 대한 데이터 (=수집 된 데이터)
  • e.g. 실제로 동전을 던졌더니 앞면이 30번 나옴.
    #### 귀무가설과 대립가설
• 귀무가설(Null Hypothesis)은 통계학에서 "차이가 없다"거나 "효과가 없다"는 등 변화나 차이가 없다는 것을 전제로 한, 처음부터 버릴 것을 예상하고 세우는 기본 가설입니다. 연구자가 증명하고자 하는 대립가설과 반대되는 입장이며, 통계적 검증을 통해 이 가설을 기각(거부)하고 대립가설을 채택하는 것이 목표입니다.
  #### p-value (to me from me...)
• p-value는 이 통계가 우연인지 아닌지 판별하기 위한 우연 점수.
• 예를 들어 평범한 동전을 10번 던졌을 때, 10번 모두 앞면이 나오는 게 불가능하진 않아. 하지만 실제로 그럴 확률이 얼마나 될까?
• 이때, 동전이 연속 10번 앞면이 나올 확률을 p-value라고 하고 이게 얼만큼 우연인지 평가하는거야.
• 자 그럼 '우연'이 뭔지 기준이 필요하겠지? 어느정도를 우연으로 간주할지 정하는 게 유의수준이야.
• p-value가 유의수준보다 크면 해당 통계는 우연히 발생할 수 있는 결과지만, 반대로 p-value가 유의수준보다 작을 경우 이는 우연으로 보기 힘들어. 뭔가 외부적인 요인이 작용하고 있다고 판단하고 귀무가설을 기각하고 대립가설을 채택하는거야.

한줄요약: p-value가 유의수준보다 낮으면 우연이 아니다 => 즉, 유의미한 분석 결과.

카이제곱 검정

• '관측된 데이터'와 '기대되는 데이터'가 얼마나 다른지 확인하는 도구
  • e.g. 기대(50) vs 관측 (52) → 이정도 오차는 우연히 생길 수 있어. 이 동전 던지기의 결과는 정상이야. 기대(50) vs 관측(90) → 관측값이 비정상 적인데? 동전 던지기에 다른 영향이 개입했나?

카이제곱값과 p-value

• 카이제곱값은 관측값과 기대값이 얼마나 차이가 나는지를, p-value는 이 차이가 얼만큼 우연히 발생했는지를 보여줌.
  
• 분석 순서는: 데이터 → 카이제곱값 → p-value e.g.
  1. 데이터들끼리 얼마나 다른지 계산해 보니 카이제곱값이 10.5가 나왔네?
  2. 이 10.5라는 숫자를 통계 공식에 넣어서 계산해 보니 우연일 확률(p-value)이 0.001이네?
  3. 내 기준인 0.05보다 작으니까, 이건 우연이 아니야! (기각)
     
• 카이제곱값은 계산결과, p-value는 카이제곱값을 얼만큼 믿을지 판단하는 도구!
  #### 분석결과를　해석할　때　주의할 점
• 카이제곱 값은 연관성의 척도를 보여줄 뿐, 이를 통해 인과관계를 확인할 순 없다.
• 카이제곱값은 데이터의 개수가 많아질수록 커지는 성질이 있다. 두가지 분석의 카이제곱값을 비교할 땐 표본의 크기를 함께 고려하자.
• 통계적으로 유의미하다는 말과 비즈니스적으로 중요하다는 말은 같은 의미가 아님을 유의하자.
  • e.g. 서비스의 버튼 색상을 바꾼 결과 클릭률이 0.001% 상승했고, 통계결과 p<0.0001 가 나옴. p값만 보면 매우매우 유의미한 - 즉, 버튼 색상 변화때문에 클릭률이 오른 게 빼박인- 상황이지만, 클릭률 0.001%는 서비스 운영 측면에서 중요하지 않은 수치임.

Follow-up

• 크라메르의 V 알아보기 (나...중에..)
  • 실제로 변수 사이의 영향력이 얼마나 큰지(효과 크기)를 알고 싶다면, 카이제곱값뿐만 아니라 '크라메르의 V(Cramér's V)' 같은 별도의 수치를 확인해야 합니다. - 잼미니

오늘 하루를 회고하며...

아 FOMO통 와;;

지금 나의 백로그에 (ㅋ) 쌓여있는 AI 신기능이 한무더기다. 이거 언제 다 살펴보고 언제 다 시도해보고 공부하나~ hoarders mentality를 가진 내가 PM이 된다면 과연 백로그 관리를 잘 할 수 있을까? (탕요나지 못할 건 뭐람) / 오늘은 집중을 꽤나? 못했다. 뭔가 스케쥴이 뒤죽박죽이 되면서 예상대로 시간을 쓰지 못한 이유가 컸던 듯. 그리고 갑자기 튀어나온 데이터 이론 개념들에 신나서 공부하다가 정작 과제 진도를 많이 못 뺌. 그치만 데이터 상식이 늘었죠? / 과제는 순항 중이에요,, 아마도;; 오늘은 운동을 갈랬는데 좀 뛰어야겠는 기분~ 날씨가 너무 좋았어서 낮부터 계속 뛰고 싶었기 때문이죠. 뛰고, 푹 자고, 내일 일찍 일어나서 초코 케이크 만들고 하루를 시작 할 예정.

서비스 기획 숙련 完

[5-1][5-2] 데이터 활용 사례 (앱스토어 리뷰) / 데이터 분석 사례 (퍼널, AARRR)
[5-3][5-5] 킥오프/ 회고/ 공유/ 현실적인 역량

5-1. 5-2. 데이터 활용 및 분석

<리뷰 및 지표 관리>

• 지표 활용 예시: 유저 수, 클릭 수, 인당 클릭 수를 통한 데이터 인사이트 도출

<데이터 분석>

• *그로스해킹 – 데이터 기반 가설 검증 마케팅 방법론

1. 퍼널 분석

• 퍼널은 각 단계를 간략하게 압축하는 방식, 모든 단계를 세분화하는 방식 모두 활용 가능.
• 목적과 상황에 맞게 설계하면 됨.

2. AARRR

• AARRR에 해당하는 항목들이 어떤 기준으로 정의되는지는 서비스마다 상이함 e.g. '획득' 단계는 회원가입이 될 수도, 앱 설치가 될 수도 있음 → 서비스 성격에 맞게 정의

• AARRR 설계에 포함 되어야 하는 내용:

  1. 각 항목이 무엇으로 정의되는 가?
  2. 어떤 활동으로 AARRR을 달성할 것인가?

5-3. 킥오프 및 회고 (실사례)

<해커톤 사례 분석>

• 킥오프가 제대로 이뤄지지 않음

  • 명확한 목표 및 MVP(Minimum Viable Product) 공유 미흡
  • 창업 아이템과 목표가 주어졌기 때문에 모두가 같은 목적을 이해하고 있다고 생각했던 것이 패착.
  • 킥오프 미팅을 통해 우리 서비스의 목표, 목적, 개발의 진행 방향 등의 싱크를 맞춰야함.

• 진행 관리:

  • 소통 채널을 명확하게 구축한 점은 프로젝트에 긍정적으로 작용함.
  • 파트별 진행 상황은 체크했으나 전체적인 그림을 보지 못함

<회고 — Retrospective>

• 구성 요소: 좋았던 점, 아쉬운 점, 개선 점
• KPT 방법론:
  • 특정인 비난 금지, 자책 금지
  • 잘잘못을 따지는 것이 아닌 다음을 위한 Action Item 도출에 집중
  • 최대한 자세하고 솔직하게 기록
  • 공유 여부 고민 시 '공유하는 방향'으로 결정

5-4. 공유 및 회의록

<회의록 작성 요령>

• 아젠다: 회의 목차 역할 수행
• 내용: 각 파트별 관점 및 이슈 기록
• 결론 및 정리: 구성원들이 꼭 알아야 할 사항 요약

<정보 전달 및 공유>

• 업무 공유: 문제 상황을 둘러싼 정보 정리 및 전달 (VoC, 개발 히스토리, 배경, 운영체제별 케이스, 파트별 문제점 등)
• 진행 상황: 어디까지, 얼마나 진행되고 있는지 투명하게 공유

5-5. PM 역량 케이스

1. '왜?'라고 묻는 습관

• 모든 현상과 문제에 대해 근본적인 이유를 탐구하는 태도
• 데이터 분석할 때도 적용 → 데이터의 신뢰도를 점검하는 계기가 되기도 함.

2. 우선순위 책정

[케이스 스터디] 앱 크래시 VS 결제 불가

• 둘 다 매출에 타격이 있으나, 앱 크래시는 서비스 경험 자체를 제공하지 못하는 상태이므로 우선순위가 높음
  • 판단 기준: 확산 범위 (전체 유저 VS 결제 대상 유저)
  • 핵심 고려 요소: 비즈니스 영향, 사용자 영향, 확산 범위, 시급성

3. 커뮤니케이션

• 감정적 대응 지양
• 상대방의 의견 경청
• 사실관계 위주로 상황 이해 및 대응

AI 기획 + 데이터 분석 특강 Pt.1

If Kakao 컨퍼런스 자료를 통한 카카오의 콘텐츠 운영 워크플로우 개선기

1. AI PM의 특징

• 협업 대상 : ML 엔지니어 / 데이터 사이언티스트
• AI 기획 프로세스 경험
• AI를 통해 비즈니스 임팩트를 낼 수 있는 기획 (단순히 업무에 AI를 활용한다 X)

2. IF Kakao 컨퍼런스 Case

데이터 수집

• 직접 수집 (크롤링, 플랫폼 자체 수집)

• 외부에서 데이터를 사오기

• 저작권, 개인정보보호법에 저촉되는지

• 학습을 위한 데이터 파이프라인 따로 설계

• 저장 형태 (어떤 형태로, 어디에 저장, 어느 빈도로, 어느 범위의 데이터를)

• 데이터 품질 검증 (중복, 신뢰도, 누락 여부)

워크플로우 개선 방식

• 수동으로 수집, 분류 과정을 거쳐야 했던 콘텐츠들을 머신러닝 기술을 적용해 자동 수집, 분류가 가능한 파이프라인을 구축함.
• 파이프라인 구축을 위해서는 학습을 위한 데이터셋을 마련해야 했음.
  • 전체 데이터 셋 → 훈련용 데이터 + 테스트 데이터 → 훈련용 + 검증용 + 테스트용

** ❓훈련용/ 검증용/ 테스트용 ** 1. Training Set : 모델이 학습하는 데이터 2. Validation Set : 모델의 성능 중간 점검 3. Test Set: 학습에 사용되지 않은 데이터로 모델의 성능 최종 평가

과제 - 장바구니 담기 전환 데이터 분석 & 개선안 제안

Persona & Data Analysis

<과제 로드맵>

1. 페르소나 설정

• 페르소나 별 행동 패턴 파악
• 행동 패턴에 따라 데이터 셋을 나눠보자

→ 페르소나 지정 후 데이터 분석 순서로 진행

2. 데이터 추출

• 페르소나에 해당하는 유저를 추출

3. 데이터 분석

• 페르소나 조건에 부합하고 전환율 상승과 관련된 데이터를 골라서 분석

🔍 Advanced 페르소나별 (A~D) 행동패턴 차이를 데이터를 통해 분석해보기

4. 가설 및 해결방안

• 이커머스 서비스 레퍼런스로 참고하기 (아이디어 실현 방안 등)
  • 퀸잇, 오아시스 마켓, 젠테스토어
• 해결방안은 현실적으로
  • UIUX 개선: lo-fi 와이어프레임 제시
  • A/B Test : 테스트 계획 및 설계까지 포함

<페르소나 분석>

페르소나 A : 고가 상품 비교 쇼핑 유저

• 유저 추출 데이터 : price_band over_300k
  • pdp_duration_time 길다 → 선택 피로 줄이는 전략 (큐레이션, 비교기능, 개인화)
  • Funnel Stage = 탐색 → 발견 경험 고도화 (카테고리 가이드, 추천·인기 제품에 대한 콘텐츠)

페르소나 B : 저가 빠른 구매

• 유저 추출 데이터 : price_band under_50k
  • High Intent → 결제까지의 마찰 제거에 초점
  • pdp_duration_time 짧음 → 초반 설득력 강화 (ATF 최적화, 이미지vs 텍스트, 가격 vs 혜택)
  • Funnel Stage = 구매 직전 → 할인, Urgency 강조

페르소나 C : 외부 검색 유입 신규 유저

• 유저 추출 데이터 : traffic_source search
  • High Intent → 결제까지의 마찰 제거에 초점
  • user type new → 신뢰 형성 (리뷰, 교환·환불, CS) + 혜택 강조

페르소나 D : 광고 유입 비교 유저

• 유저 추출 데이터 : traffic source ad
  • previous_landing_page 이전 페이지의 맥락에 따라 pdp 구성 변경
  • 광고 유입형은 단일 상품에 대한 관심을 이용해 전환으로 이끌어 내야함.

📄참고자료 : Fast User Segmentation for a Better Conversion Strategy_2021

<데이터 추출>

1. 데이터를 통한 가설 검증

2. pdp_duration_sec을 short/ mid/ long 으로 구분 짓고 각 범위의 의미 정의하기.

3. 어떤 조합이 페르소나 D를 설명하기에 가장 적합한 사용자 행동 패턴 분석

분석할 페르소나 타입 = D '광고 유입 비교 유저' traffic_source = ad 인 유저 추출 → Group D

1. 데이터를 통한 가설 검증

• 가설:
  • 리뷰를 클릭 유저는 장바구니 전환이 높을 것이다.
  • discount exposed 가 true인 사용자의 장바구니 전환이 높을 것이다.

검증 방법

두 변수 모두 범주형(True/False)이기 때문에 카이제곱 독립성 검정(Chi-square test)을 사용했습니다. 유의수준은 일반적인 기준인 α = 0.05로 설정했습니다.

가설 1 — 리뷰 클릭 ✅ 채택

리뷰를 클릭한 유저(36.3%)는 그렇지 않은 유저(27.9%)보다 장바구니 전환율이 8.5%p 높았고, p-value가 0.0079로 유의수준 0.05를 훨씬 밑돌아 통계적으로 유의미한 차이입니다.

가설이 채택되며, 리뷰 클릭은 구매 의도와 관련 있는 행동임을 시사합니다. PDP에서 리뷰 접근성을 높이거나, 리뷰를 클릭한 유저에게 장바구니 유도 CTA를 강화하는 전략이 유효할 수 있습니다.

가설 2 — 할인 노출 ❌ 기각

할인에 노출된 유저(31.0%)와 그렇지 않은 유저(30.3%) 간 전환율 차이는 고작 0.6%p에 불과하고, p-value가 0.8837로 통계적으로 의미 없는 수준입니다.

가설은 기각됩니다. 할인 노출 자체가 장바구니 전환에 직접적인 영향을 미치지 않는다는 뜻입니다. 추가적으로 확인해볼 만한 방향으로는, 할인율의 크기(price_band별 분석)나 유저 유형(신규/재방문)과 결합했을 때 효과가 달라지는지 세분화 분석이 있습니다.

내일 할 일

2. pdp_duration_sec을 short/ mid/ long 으로 구분 짓고 각 범위의 의미 정의하기.

3. 어떤 조합이 페르소나 D를 설명하기에 가장 적합한 사용자 행동 패턴 분석

⬇️ 3번 아래 프롬프트 넣고 돌리기~!

[분석 목적]
광고 유입 유저 중, 타 플랫폼 비교 여부는 직접 관측할 수 없지만 비교 쇼핑 맥락이 개입되었을 가능성이 있는 사용자 패턴을 탐색하고자 한다.

[분석 원칙]

데이터로 직접 확인 가능한 행동만 근거로 사용한다.
“외부 비교를 완료했다”처럼 관측 불가능한 상태는 단정하지 않는다.
대신 광고 유입, 체류시간, 리뷰 클릭 여부, 할인 노출 여부, 가격대, 이전 페이지 유형 등의 조합을 바탕으로 비교 맥락이 개입되었을 가능성이 있는 패턴을 가설적으로 도출한다.

[분석 요청]

광고 유입 유저를 대상으로, 아래 변수 조합을 기준으로 의미 있는 행동 패턴을 도출해줘.
user_type
previous_page_type
price_band
pdp_duration_sec 구간
review_clicked
discount_exposed
각 패턴에 대해 다음을 계산해줘.
유저 비율
장바구니 전환율
구매 전환율
평균 체류시간
각 패턴에 대해 아래 중 어떤 해석이 더 적절한지 구분해줘.
내부 탐색 성향이 강한 패턴
빠른 판단 성향이 강한 패턴
가격 민감 가능성이 높은 패턴
비교 쇼핑 맥락이 개입되었을 가능성이 있는 패턴
단, 모든 해석에는 “데이터로 직접 확인 가능한 사실”과 “해석적 가설”을 분리해서 작성해줘.

오늘 하루를 회고하며...

일류는 즐긴다

일요일에 푹 쉰 덕분에 잠을 잘 잤다. 일찍 일어나서 아침을 든든히 먹고 짧게 산책을 다녀와서 하루를 시작했더니 하루종일 집중이 꽤나 잘됐다. 오늘부터 새로운 멘탈리티를 장착하고 뉴 최혜령이 되었다. 이제 피곤하게 살지 않기로 했다. 매사 열심히 최선을 다하는 것도 좋지만, 힘을 줄 때와 뺄 때를 잘 골라가며 텐션 조절을 하는 것도 롱런의 비결이렸다. 그렇다고 내가 최선을 다하지 않는 성격도 아닐테니, 그냥 마음을 느긋하게 먹기로 다짐했다는 정도. / 지난 과제 때 지피띠니, 잼미니, 클로드에 자아의탁 해버리는 바람에 시작부터 꼬였던 실수를 범했기 때문에 이번엔 나 스스로 사고하고 분석의 흐름을 구성하려고 노력했다. 확실히 내가 하고자 하는 바가 명확하게 정해져있으니까 훨씬 수월하다. 과제 재밌음ㅎㅎ / +타이핑 하면 동물의 숲 주민들이 재잘거리는 효과음이 나는 플러그인을 깔았더니 하루종일 유쾌하다ㅋㅋㅋ 동숲 브금 틀어놓고 과제하면 동숲세계에 들어온 거 같고 그래.. 일류숭이로 마무리

아티클 카타

쿠키와 세션, 그리고 캐시 (발행일 2025.01.07)

1. 쿠키

• 로그인 정보, 장바구니 저장을 위한 기능
• 페이지 이동할 때 마다 정보가 날라가지 않도록 사용자 단말기에 이름/값/도메인/만료날짜 와같은 정보를 저장

쿠키로 인한 프라이버시 침해 문제

• 서드파티 쿠키가 여러 사이트에 걸쳐 사용자의 행동을 추적할 수 있게 됨. e.g. A웹사이트 방문 → 페이지 안에 구글 애즈 스크립트가 포함 됨 → 브라우저는 A웹사이트와 구글 서버 에 모두 쿠키 요청을 보냄 → 구글 쿠키를 심음 (이 사용자는 id 123임) → 그러면 구글 애즈 스크립트가 포함된 다른 사이트에 갔을 때 내가 같은 사용자로 읽힘.

• 한 사이트 내부 기록이 아니라 인터넷 사용 로그가 되어버림.
• 근데 사용자는 어디서 어떻게 수집돼서 어느 기업이 갖고 있는지 모름.
• 사용자의 위치, 정치성향과 같이 민감한 정보까지 포함

프라이버시 문제로 쿠키사용이 축소되면,

1. 퍼스트파티 데이터가 중요해짐

• 회원가입 유도, 로그인 기반 서비스, 지속적이고 통합된 고객 데이터베이스 구축
  • 예) 아마존의 루퍼스

2. 관심사 타겟팅 -> 컨텍스트 타겟팅

• 유저가 누구인지 보다 이 사람이 지금 무엇을 보고 있는지

2. 세션

• 쿠키는 브라우저에 저장되는 데이터 단위

• 세션은 서버에 저장

• 세션ID는 쿠키에 담겨져서 세션을 열람하는 키

  브라우저 - 요청하고, 받는 쪽
  서버 - 응답하는 쪽
  Like 손님과 주방..

• 세션아이디를 해킹하면 다른 pc에서 로그인 가능. → 개인정보 수정 페이지나 비밀전호 수정 시 현재 비밀번호를 입력해야하는 인풋 박스가 필요한 이유.

• 정책 만들 때: 세션 유지 기간 고려 (보안 중요한 금융 서비스- 10분/ sns 길게는 3개월)

서비스 기획 숙련

Chapter 3 숙제
Chapter 5 -네카라쿠배 현황

📖가상으로 내가 만드는 서비스의 회원 가입 or 회원 탈퇴 정책서를 작성 해 보세요. [3-3]

필터커피 커뮤니티 '드립핑' 웹의 회원가입 페이지 (레퍼런스 : 언스페셜티 커뮤니티)

• 회원가입 방법

1. 이메일 회원가입: 이메일 주소를 이용하여 회원가입합니다.
2. 사용자 가입 시 최소 정보 요구사항: (이메일, 닉네임, 생년월일, 비밀번호)
3. 비밀번호 생성 정책: 비밀번호는 8자 이상 16자 이하, 영문과 숫자가 1자 이상을 포함시키는 조건을 따릅니다.
4. 닉네임 생성 규정: 닉네임은 10자 이내의 한글 혹은 영어를 사용합니다. 사용자는 닉네임을 생성할 때 욕설, 비하적 표현, 성적 표현 등 다른 사용자에게 불쾌감을 유발하는 단어를 사용할 수 없습니다.

• 서비스 이용 자격

1. 사용자는 연령과 지역 제한 없이 서비스를 이용할 수 있습니다.
2. 사용자는 회원가입 과정에서 invitation qr code를 스캔해야 합니다.

• 개인정보 처리 규정

1. 사용자의 이메일과 생년월일은 본인 확인, 프로모션 (뉴스레터 발행, 생일 쿠폰 지급), 서비스 이용에 대한 통계에 이용됩니다.
2. 사용자의 이메일과 생년월일은 회원 탈퇴 또는 이용목적 달성 시 파기합니다.

GPT의 피드백 💬

요청사항 정책 항목이 정책이 실행되는 단계와 범위에 맞게 카테고리화 되어있는지, 사용자 친화적으로 용어가 정리되어있는지 위주로 피드백해줘.

피드백 내용

1. 정책 항목을 회원가입 절차에 맞춰 분류하면 더 명확해짐.

(입력하는 내용/ 만족해야하는 조건/ 가입 진행 순서 —를 분리하면 더 명확해짐)

2. 용어&표현을 사용자 친화적으로 개선. 모호한 표현 최소화 e.g. "통계에 이용됩니다", "이용목적 달성 시 파기" ❌

개선 Ver.

회원가입 정책서

1. 가입 방식 및 절차

• 이메일을 통해 회원가입을 진행합니다.
• 회원가입 시 초대 QR 코드 인증이 필요합니다.

  2. 가입 시 입력 정보 정책

• 필수 입력 정보
  • 이메일
  • 닉네임
  • 생년월일
  • 비밀번호

    3. 계정 생성 규칙

    3.1 비밀번호 정책

• 8자 이상 16자 이하
• 영문과 숫자를 각각 1자 이상 포함

  3.2 닉네임 정책

• 10자 이내 (한글/영문/숫자)
• 욕설, 비하 표현, 성적 표현 사용 불가
• 닉네임은 중복 사용 불가

  4. 이용 자격 및 제한

• 연령 및 지역 제한 없이 가입 가능

  5. 개인정보 수집 및 이용

• 이메일, 생년월일은 다음 목적에 활용됩니다:
  • 본인 확인
  • 프로모션 (뉴스레터, 생일 쿠폰)
  • 서비스 이용 통계 분석
• 회원 탈퇴 시 개인정보는 파기됩니다.

📖 회원가입 시에 발생할 수 있는 서비스 에러 케이스를 작성해보세요. [3-4]

에러 케이스	에러 발생 조건	에러 메세지	에러코드
회원가입 시 이메일 형식 오류	사용자가 입력한 이메일이 유효하지 않는 경우.	올바른 이메일 주소를 입력해주세요.	AUTH_VALIDATION_EMAIL_INVALID
회원가입 시 이메일 중복 오류	사용자가 입력한 이메일이 이미 회원가입에 사용 된 경우.	이미 사용 중인 이메일 주소입니다.	AUTH_DUPLICATE_EMAIL
비밀번호 조건 불일치 오류	사용자가 설정한 비밀번호가 비밀번호 생성 정책을 따르지 않는 경우	비밀번호는 다음 조건을 만족해야 합니다 —8자 이상 16자 이하/ 영문과 숫자를 각각 1자 이상 포함자	AUTH_VALIDATION_PASSWORD_RULE
비밀번호 확인 불일치	비밀번호와 재입력 값이 다른 경우	비밀번호가 일치하지 않습니다.	AUTH_VALIDATION_PASSWORD_MISMATCH
닉네임 중복 오류	사용자가 입력한 닉네임이 이미 사용 중인 닉네임인 경우.	이미 사용 중인 닉네임 입니다.	AUTH_DUPLICATE_NICKNAME
닉네임 길이 초과 오류	사용자가 입력한 닉네임이 10자 이상인 경우.	닉네임은 10자 이내로 입력해주세요.	AUTH_VALIDATION_NICKNAME_LENGTH
닉네임 문자셋 오류	사용자가 입력한 닉네임에 한글/영어/숫자 이외의 문자가 포함 된 경우	사용할 수 없는 특수문자가 포함되어있습니다. 한글, 영어, 숫자만 입력해주세요.	AUTH_VALIDATION_NICKNAME_FORMAT
닉네임 금칙어 포함 오류	사용자가 입력한 닉네임에 금칙어가 포함된 경우	부적절한 단어가 포함되어 있습니다. 다른 닉네임을 사용해주세요.	AUTH_VALIDATION_NICKNAME_PROFANITY
카메라 접근 권한 오류	사용자가 단말기의 카메라 접근 권한을 허용하지 않은 경우	QR스캔을 위해 카메라 접근 권한을 허용해주세요.	AUTH_PERMISSION_CAMERA_DENIED
QR코드 스캔 오류	유효하지 않은 QR을 스캔한 경우	유효하지 않은 QR입니다.	AUTH_QR_INVALID
필수 정보 입력 누락 오류	사용자가 회원가입 시 필요한 정보를 누락하고 다음 단계로 진행하려는 경우	필수 입력 사항을 모두 확인해주세요.	AUTH_VALIDATION_REQUIRED_FIELD

📖앞서 작성한 서비스의 회원 가입 or 회원 탈퇴 정책서를 가지고 해당 기획안을 작성해 보세요. [3-5]

1. 기능개요

• 프로젝트 개요 : '드립핑 커뮤니티' 웹의 회원가입 페이지 개발
• 기대 효과 및 목표 : 드립핑의 원두를 구매한 고객을 드립핑 커뮤니티의 회원으로 전환 할 수 있음.

2. 서비스 흐름(User Flow)

3.상세 기능 명세

[회원가입 상세 기능 명세서]

1. 회원가입 (Sign Up)

1.1 이메일 입력 및 검증

• 이메일
  • 타입: string
  • 형식: RFC 표준 이메일 형식 (예: user@example.com)
  • 필수 여부: 필수
• 검증 조건
  • 이메일 형식이 유효해야 함
  • 기존 가입된 이메일과 중복 불가
• 에러
  • AUTH_VALIDATION_EMAIL_INVALID
  • AUTH_DUPLICATE_EMAIL

    1.2 QR 인증

• QR 코드
  • 입력 방식: 카메라 스캔
  • 타입: string (QR 데이터)
• 처리 로직
  • 카메라 권한 허용 여부 확인
  • QR 데이터 유효성 검증
• 검증 조건
  • 카메라 접근 권한이 허용되어야 함
  • QR 코드가 유효한 값이어야 함
• 에러
  • AUTH_PERMISSION_CAMERA_DENIED
  • AUTH_QR_INVALID

    1.3 사용자 정보 입력

    닉네임 (Nickname)

• 타입: string
• 길이: 최대 10자
• 허용 문자: 한글, 영어, 숫자
• 필수 여부: 필수
• 검증 조건
  • 10자 이내
  • 허용된 문자셋만 사용
  • 금칙어 포함 불가
  • 기존 닉네임과 중복 불가
• 에러
  • AUTH_VALIDATION_NICKNAME_LENGTH
  • AUTH_VALIDATION_NICKNAME_FORMAT
  • AUTH_VALIDATION_NICKNAME_PROFANITY
  • AUTH_DUPLICATE_NICKNAME

    생년월일 (Birth Date)

• 타입: string (YYYY-MM-DD)
• 필수 여부: 필수
• 검증 조건
  • 날짜 형식 유효성 검증 (YYYY-MM-DD)
  • 미래 날짜 입력 불가
• 에러
  • AUTH_VALIDATION_REQUIRED_FIELD
  • (추가 가능) AUTH_VALIDATION_BIRTHDATE_INVALID

    비밀번호 (Password)

• 타입: string
• 길이: 8자 이상 16자 이하
• 필수 여부: 필수
• 검증 조건
  • 8~16자 길이
  • 영문 + 숫자 각각 최소 1자 포함
• 에러
  • AUTH_VALIDATION_PASSWORD_RULE

    비밀번호 확인 (Password Confirmation)

• 타입: string
• 필수 여부: 필수
• 검증 조건
  • 비밀번호와 동일해야 함
• 에러
  • AUTH_VALIDATION_PASSWORD_MISMATCH

    1.4 필수값 검증 (공통)

• 대상 필드
  • 이메일
  • 닉네임
  • 생년월일
  • 비밀번호
  • 비밀번호 확인
• 검증 조건
  • 모든 필수 필드 값이 존재해야 함
• 에러
  • AUTH_VALIDATION_REQUIRED_FIELD

    1.5 회원가입 완료 처리

• 처리 로직
  • 모든 validation 통과 시 계정 생성
  • 사용자 정보 DB 저장
• 저장 데이터
  • 이메일
  • 닉네임
  • 생년월일
  • 비밀번호 (암호화 저장)
• 후처리
  • 회원가입 완료 응답 반환
  • 서비스 메인 화면으로 이동

    2. 공통 에러 응답 구조

    {
    "success": false,
    "code": "AUTH_VALIDATION_EMAIL_INVALID",
    "message": "올바른 이메일 주소를 입력해주세요."
    }

오늘 하루를 회고하며...

즐겁다 즐거워

부트캠프가 너무 재밌다! 일단 이번주는 TIL을 밀리지 않고 작성해서 뿌듯하다.

사람들이랑 과제 피드백이 모두 끝난 뒤 후기를 나눴다.

1. 모든 텍스트에는 목적과 핵심이 명확하게 드러나야한다.
2. 가독성은 분량의 문제가 아님.
3. 해결방안은 설득과 납득의 영역

추가로 옌님 아티클 카타 멘토링 받은 이야기를 들으며 퀄리티 있는 질문을 하는 게 얼마나 중요하고 어려운 일인지 다시금 깨달았다. 좋은 질문은 거시적 관점으로 주어진 자료와 상대방의 주장을 비판적으로 해석하는 것.

개인 아티클 스터디

📄기획자가 직접 99개의 서비스를 만들며 배운 것들
with 열정이들

바이브 코딩을 통해 빠른 시도와 레슨런이 가능해진만큼 기획의 본질에 더 집중해야한다는 메세지를 던지는 글이였다. 지난 주 노코드 웹개발 세미나를 들은 후 읽으니 더욱 와닿았던 글.

작가의 개발일지 중 인상적이였던 부분은 기술의 한계를 우회하는 판단과 서비스의 타겟군을 생각하는 과정이였다.

카카오톡 알림 대신 이메일 알림으로 우회한 선택을 보고 타협과 합리적인 판단은 한끗차이라는 생각을 하게 되었다. 타협이 되지 않으려면 어떻게 해야할까. 항상 강조되는 목적 중심 사고가 여기서도 재조명 된다. 여러가지 고려 사항 속에서 길을 잃지 않으려면 목적이 무엇인지 되묻고 목적에 필요한 게 무엇인지 생각해야한다. 또한 나의 판단이 꼼수가 되지 않으려면 탄탄한 하드스킬 역량이 받쳐줘야된다고 생각한다. 그렇지 않으면 챌린지를 회피하면서 그것이 합리적인 판단이라 믿는 오류를 범할 수 있기 때문이다.

그 다음 인상적이였던 부분은 기능 자체보다 이 기능이 누구를 타겟팅해야하는지를 고민하는 과정이였다. 개발자와 PM의 관점 차이가 발생하는 포인트이지 않을까. 타겟이 있어야 서비스의 목적과 가치가 생긴다는 걸 직접 개발해보면서 체감했다고 하는데, 바이브코딩으로 빠르게 웹을 개발할 수 있는 환경의 장점과도 이어지는 대목이라고 생각한다. 실패 비용이 0인 만큼, 에너지를 쏟아야하는 것은 '누가 왜 써야 하는가'라는 고민이라는 말도 중요한 논점이라고 생각한다.

바이브 코딩의 등장으로 코딩이라는 전문적인 영역의 허들이 드라마틱하게 낮아졌다. 그러다보니 '바이브코딩 = 코딩 역량 대체'라는 인식이 생겼다. 하지만 PM이 코딩이 필요한 일을 해내는 것이 정말 의미 있는 일일까? '누구나 코딩이 필요한 일을 할 수 있다'라는 사실은 매우 매력적이지만 작가의 말 처럼 실패 비용이 0이라고해서 사용자가 부담해야하는 불편에 대한 비용도 0은 아니라는 사실을 유념해야 한다.

세미나에서 만난 개발자 분들에게 우려 섞인 질문을 한 적이 있다. *"비개발자들이 노코드 개발로 만든 아웃풋을 업무에 적극적으로 활용하는 것이 개발자 입장에서 어떻게 받아드려나요?"* 결론만 말하자면 답변은 '나쁘게 생각하지 않는다'였다. 다만 조직 차원에서 이런 기술을 업무 파이프라인에 적용하는 방식이 더 중요하다고 말했고 현업에서도 이미 많이들 활용하고 있으니 내가 우려하는 부분에 대해 너무 걱정하지 않아도 된다고 하셨다. 답변을 듣고 나니 그동안 나는 '조직 속의 나'를 그리지 못하고 있다는 사실을 알게되었다. 내가 AI를 기깔나게 활용할 줄 알아도 조직의 문화와 목표에 적합하지 않을 수 도 있다는 사실을 생각해볼 수 있었다.

결론적으로, 바이브 코딩으로 개발을 하던 뭘 하던 PM은 기획의 본질을 생각해야하고 협업을 위한 원활한 소통을 중시해야한다는 PM의 황금율로 아티클 스터디를 정리할 수 있을 거 같다.

우수 과제 특강

윤정 튜터님 11:00-12:00

카테고리

• 1개의 리뷰에 여러 경험이 섞여서 분석이 모호한 경우를 '경험' 단위로 나눠서 분류 한 사례 (나중에 써먹어야지)

요약

• 그냥 짧게 줄이는 게 요약이 아니다
• 상대방이 잘 이해할 수 있도록 요약해야됨

문제 정의

• 주요 문제점이 서비스에 어떤 영향을 미치는지 분석
  • 문제점이 서비스에 미치는 영향을 등한시하고 분석하지 않은 나의 과제물을 반성하게 됨…

가설& 솔루션

• 모호하게 세우지 말자. 구체적이고 현실적으로. e.g. "검색 결과 개편"❌ → 어떻게 개편할 건지 실행 가능한 수준으로 기술

Overall

• 전체적인 흐름을 신경쓰자. 원페이저로 요약하는 것도 좋은 방법.
• 모든 주장은 구체적인 근거로 뒷받침 되어야한다.

서비스 기획 숙련 - 숙제편

[3-3], [3-5]

📖 [3-3] 가상으로 내가 만드는 서비스의 회원 가입 or 회원 탈퇴 정책서를 작성 해 보세요.

📖 [3-4] 회원가입 시에 발생할 수 있는 서비스 에러 케이스를 작성해보세요.

📖[3-5] 앞서 작성한 서비스의 회원 가입 or 회원 탈퇴 정책서를 가지고 해당 기획안을 작성해 보세요.

• 기능개요
• 서비스 흐름 설계 (user flow)
• 상세 기능 명세 (각 기능이 어떻게 동작해야 하는지, 입력 값, 출력 값, 상호작용을 구체적으로 정의)

아티클 카타

백오피스 시스템 기획 시 TIPS

팀원들과 나눈 이야기

• *"백오피스 시스템은 단순 관리 도구가 아니라, 안정성과 운영 효율을 중심으로 프론트 운영을 가능하게 하는 시스템이다."* (by 자영님)
• 자동화가 무조건 효율을 올리는 방법은 아니다. 개발 리소스가 많이 들 뿐만 아니라 불안정한 자동화를 만들 경우 오히려 더 큰 비효율을 유발하게 된다.
• 백오피스 기획이라고 하지만 결국 모든 기획에 통용될 수 있다. 새로운 시도보다는 안정성에 더 집중한다는 차이점은 존재.
• 운영에서도 관리 이력(로그)을 쌓아두는 것이 중요하다.

나의 인사이트

[내용 요약]

• 안정성이 중요
• 온보딩이 쉬워야 한다 - 직관적 uiux
• 오류 코드 팝업 복사 가능하게
• 삭제 권한 최소화 - 운영에서도 로그를 챙기기
• 백오픽스 공지사항 란 - 커뮤니케이션 최적화
• 개인정보는 흩어져있기 않게 모아서 관리
• 팝업은 한개만

백오피스라는 용어를 굉장히 포괄적으로 사용해서 각 예시들이 구체적으로 어떤 상황에, 누구에게 적용되는 예시인지 파악하기 힘든 글이였지만, 백오피스 시스템을 만들 때 어떤 것들을 고려해서 설계하는지 어렴풋이 알 수 있었던 글.

[이전에는 알지 못했거나 새롭게 배운 내용]

• GNB/LNB/SNB : global/local/side navigation bar

• 플랫폼 vs 백오피스

  • 플랫폼: 프로덕트를 만들기 위한 기술 설계 (레고 조각) (APIs, Database, CI/CD*, etc.)
  • 백오피스: 내부 사용자들을 위한 툴 개발 (레고 성) (운영/CS-어드민, 재무- 정산 시스템, 영업 - CRM, 마케팅 - CMS)

CI (Continuous integration): "재료 손질과 중간 점검”

• 쉬운 요약: 요리사들이 각자 손질한 재료를 큰 냄비(공유 저장소)에 합치고, 맛이 이상하지 않은지 바로바로 확인하는 과정입니다.
• 직관적 의미: 코드를 합칠 때마다 자동으로 빌드하고 테스트해서, "누가 짠 코드 때문에 전체가 망가지는 일"이 없도록 미리 방지하는 단계예요.

CD (Continuous deployment): "완성된 요리 내보내기"

• Continuous Delivery (제공): 요리를 완성해서 '배차대'까지는 자동으로 보냅니다. 하지만 손님 식탁에 올리기 전, 주방장이 마지막으로 눈 확인을 거쳐 서빙하는 방식입니다.
• Continuous Deployment (배포): 주방장의 확인 없이도, 요리가 완성되면 즉시 서빙 로봇이 손님 식탁까지 배달하는 방식입니다.

튜터님 멘토링💬

백오피스를 기획할 때는 단순히 기능을 만드는 게 아니라, 운영자가 안정적으로 운영할 수 있는 환경을 만드는 데 초점을 둔다. 그래서 프론트나 백 모두 기획자의 기본적인 역량이 받쳐줘야하는 건 맞지만 백오피스가 운영 안정성을 더 많이 고려한다는 차이점도 정확하게 짚었다는 피드백을 주셨음. 백오피스 기획과 프론트(사용자용) 기획을 별개로 나눠서 얘기하는 경우가 많지만, 경험에 기반해서 보면 백오피스 기획 잘하면 프론트도 잘하고, 프론트 기획 잘하면 백오피스도 잘한다.

[질의응답]

Q : “잘 만들어 놓은 레퍼런스를 경험하여 레퍼런스를 흡수하는 것 만큼 빠른 학습은 없다” 라고 했는데, 백오피스 관련한 레퍼런스를 어디서 찾을 수 있을까요?

A: 백오피스는 “어떤 서비스를 운영하느냐”에 따라 특성이 완전히 달라지기 때문에, 단일 레퍼런스로 학습하기 어렵다. 100% 백오피스 서비스는 아니지만 참고할 수 있는 것들은 유투브, 블로그, 카카오톡 톡 채널 관리자 페이지가 있다.

Q: 백오피스 기획을 직접 경험해볼 수 있는 방법이 있을까요?

A: 프론트, 백 상관없이 기획안을 잘 쓰는 게 중요합니다. 프로덕트 기획안 작성이 어느정도 숙련이 되면 그 기획안을 바탕으로 어떤 백오피스 시스템이 필요한지 설계하는 단계로 넘어가면 좋을 거 같습니다.

💡부트캠프에서 지금 할 수 있는 것

1. 기획안 쓰고 튜터님께 피드백 받으러 가기 — 책을 쓰듯, 여러 번 써보고 다듬는 반복이 실력이 된다. 읽는 것과 직접 쓰는 건 다르다. 기획안도 계속 쓸 수록 실력이 는다.
2. 서비스 기획안 작성하면서 해당 서비스의 백오피스를 어떻게 기획할지 튜터님과 별도로 스터디.

Q. 랜딩 타입과 모듈 타입의 개념을 찾아보고 정리해보았는데, 이 내용이 맞을까요? A.원문에서 랜딩과 모듈을 공통 사항으로 설정하자는 말의 골자는 프론트에서 필요한 요소(랜딩 방식, 모듈 형식)를 구현할 때 이를 백오피스에서도 일관되게 관리할 수 있으면 효율적일 것이라는 것으로 해석됩니다. 랜딩 방식이나 모듈화 뿐만 아니라 전체적으로 적용되는 말이긴 한데, 현실의 상황을 100%반영한 말은 아님. 무조건 효율이 오르는 것도 아니고 반드시 따라야하는 부분도 아니다.

랜딩 = 페이지 이동

• 랜딩이라는 용어에 대한 정의는 필요에 따라 구성원들과 합의. (굳이 안해도 됨)
  
• 모듈화 = 정해진 규격에 맞춰 효율적으로 UI를 구성하는 것*
• 규격을 정해두면 새 콘텐츠가 들어올 때 사이즈만 맞춰 바로 넣을 수 있어 운영이 효율적
  • 웹/앱에 추가해야 하는 아이템이 생겨도 새로운 기획을 하지 않아도 됨
• 현실에서는 다양한 변수가 있기에 모듈화가 항상 정답은 아니다.
• 효율과 운영 목적 사이에서 균형을 맞춰야 함.

Q. 아티클에서는 현업에서 백오피스 전반적 개선이 기업의 이윤 창출에 도움이 되는 것이 아니고, 당장의 이슈가 발생할 가능성이 있기 때문에 후순위로 여겨진다고 나와있습니다. 중요도가 낮으면 계속 백로그에서 나오지 못하는 이슈들의 경우와 비슷하다고 느꼈습니다. 백오피스의 개선도 스프린트 내에서 다뤄지기 힘들 것 같은데, 현업에서는 어떤 방식으로 진행되나요?

A. 후순위로 밀리는 일이 실제로도 굉장히 잦은 게 현실. 극단적인 예시로, 서비스가 다운되는 것과 백오피스 시스템이 잘 돌아가지 않는 것 중 서비스 다운이 더 큰 문제인 것을 생각하면 이해가 쉬움. 그래서 백로그에 쌓여있는 백오피스 관련 이슈들의 우선순위를 잘 파악해서 과제로 끌어오는 것이 PM의 관점에서 중요하게 바라봐야할 부분.

Q. 백오피스 담당자의 성과 평가는 어떻게 이루어지나요?

A : 매출 직결 지표가 없다는 건 맞지만, 백오피스가 지원하는 운영 목적을 기준으로 성과 지표를 설계할 수 있다.목적이 다르면 같은 기능이라도 측정 기준이 완전히 달라진다. 백오피스 기획을 시작할 때 "이 백오피스는 무엇을 하기 위해 존재하는가"를 먼저 잡는 게 중요할 듯!

서비스 기획 숙련

[3-1]~[4-4] 실무 문서 작업, Why에 집착하기, 논리적인 커뮤니케이션

Chapter 3. 기획/PM 실무 문서 작성

[PRD - 요구사항 정의서]

• 명확하고 구체적인 요구사항 작성이 핵심.
• "빠르게, 많이, 충분히"와 같은 추상적인 표현은 지양할 것.

📄Reference Article 컬리에서 데이터 분석가로 일한다는 것

[IA - 정보구조도]

작성 목적

1. 사용자 경험 개선: 사용자에게 쉽고 빠른 구조를 만드는 것.
2. 명확한 소통: 정보 흐름 정리 → 정보의 위치 및 중요도 구분 가능.
3. 서비스 확장 시 대응: 좋은 IA는 유연하게 수정 및 추가가 가능함.

How-To?

1. 서비스 내 모든 기능 List-up.
2. 기능은 카테고리와 계층 구조를 거쳐 배치함. (카테고리⊃계층구조)
   • Tip: 메뉴 탭 categorising이 잘되어있으면 확장 작업이 용이해짐

[서비스 정책서]

숙제 및 진행으로 실습 예정.

[에러 케이스]

Like 서비스의 오답 노트 → 문제 발생 시 어떻게 처리할 것인가?

• 서비스 오류: 사용자 오류 vs 서비스 기능 오작동.
• 시스템 오류: 개발 단계에서 발생한 오류.

에러 케이스 관리 프로세스

1. 에러 케이스 정의: 예상 가능한 오류 정의.
2. 에러 발생 조건: 정의한 에러가 어떤 상황에서 발생하는 건지, 그 조건을 구체적으로 공유하여 협업 팀이 동일한 이해도를 갖게 함.
3. 에러 메시지 작성: 사용자에게 후속 액션 가이드 제공.
   • 에러 코드는 개발팀이 빠르게 대응할 때 활용됨.

[상세 기획]

[주의] 문서의 명칭에 집착 X, 목적 위주로 생각할 것!

• 기능 명세서: 기능을 상세히 설명해서 유관 부서에 뿌리는 문서
  • 기능 목적, 동작 방식, UI, 제외 사항 등
• 유저 플로우: 기능 명세서와 연결하여 각 기능이 어디서 어떻게 작동해야 하는지 정의.
• 상세 기능 명세서: 각 기능이 동작하기 위한 Input / Output / Interaction.

상세 기능 명세서의 필수 요소

• 기능 이름: 기능을 간결하고 명확하게 표현.
• 기능 설명 : 기능이 어떤 건지에 대한 설명 (당연하다고 여겨지는 것도 해석의 차이가 있을 수 있으니 간단하게 기재하는 것을 추천)
• Input: 각 기능이 처리해야 할 입력값.
• Output: 입력값 처리 후 어떤 걸 출력할 것인가?

Chapter 4. PM이 갖춰야 할 역량

[Endless Why?]

• Why → What → How 순으로 사고하기.

[커뮤니케이션]

1. 명확성 + 간결성.
2. 상대방의 관점에서 생각하기 업무 커뮤니케이션은 마치 식빵에 잼 바르는 게임처럼...그치만 두괄식으로...ㅎ

➡️ 어떻게 역량을 키워야 할까?

• 적극적 경청 (비언어적 표현도 커뮤니케이션의 일부).
• 핵심 메시지 구체화 (핵심만 먼저 두괄식으로).

[논리적 설득]

• '논리적'이란? 명확한 이유 + 근거 → 문제 해결의 근본적 접근 방식이 된다.
• 이해관계자들이 결정을 신뢰할 수 있게 함.

How?

• 주장과 근거 구분.
• 논리적 흐름 만들기.
• 단계적 접근.

인스파이어드

~ p.81

오늘 하루를 회고하며...

아 오늘 튜터님이 팀 바껴서 서운하지 않냐고 물어본 게 너무 웃겼다. 아쉽긴하지만, 너무 친해져서 긴장감이 떨어질 수 있다는 관점에서는 새로운 환경이 주어진 것이 적절한 시점의 변화라 생각한다.

아티클 카타를 할 때 마다 느끼는 거지만, 글을 읽고 핵심 내용을 나의 말로 정리하는 능력이 아직 많이 부족한 거 같다. Paraphrasing 하는 요약이 아닌 나의 인사이트가 담긴 요약을 해보려고 노력해야겠다.

말할 때도 '너무 당연한 소리 같은데', '이렇게 말해도 이해하려나' 같은 생각에 말을 장황하게 하는 버릇도 의식적으로 고쳐나가야하는 부분! 우선 간결하게 말하고, 부족한 부분을 보충설명하는 방식으로 대화하려고 노력해야 밸런스가 맞춰질 거 같다.

오늘은 꽤나 집중을 잘 한 거 같다! 몰려오는 졸음에 굴하지 않고 이겨냈다. 100점이야. 과제 서면 피드백이 오늘 나온다니까 괜히 긴장된다. 며칠 지나고 다시보니 엉망인 부분이 너무 많이 보이기 때문이지요 호호호호. 그치만? 배우려고 왔죠? 배우면 되지요.

목,금 Plan

• 대면 피드백 이후 최종 과제 회고 진행 -> TIL 기록 MUST!!
• 기획 숙련 강의 숙제 (3-3, 3-5 : 회원가입 페이지 정책 문서화 -> 기능 요구사항 설계)
• 가능하면 튜터님 피드백 or 팀원들과 공유 까지..?
• 개인 과제 발제 문서 확인 & 계획 세우기
• 개인 아티클 읽기 — STAR 자소서 , 99개 만들어 본 기획자 어쩌구...

A/B 테스트 특강 

자경 튜터님 11:00~

실험설계

• 테스트 대상은 목표에 직결되고 임팩트가 큰 대상으로 진행.
• 성공지표는 하나로 제한. 성공지표가 많으면 혼란이 온다 (성공지표 = 성공 여부에 대한 기준)
• 성공지표 + (보조지표 & 가드레일 지표)
• 가드레일 지표: 테스트 진행 시, 최악의 경우 어떤 기준으로 실험을 중단할 지에 대한 한계선을 긋는 지표.

샘플링

• 특별한 이유가 있지 않다면 무작위 할당이 되도록 설계.
• 사용자에게 할당 된 그룹이 바뀌지 않도록 주의해야한다. A그룹과 B그룹을 모두 겪는다면 사용자에게 혼란을 주고 테스트 결과도 왜곡된다.
• 샘플 사이즈 : 테스트가 유의미하게 받아드려지기 위한 모수의 기준을 세우고 진행.

실험 기간

• 실험에 왜곡된 영향을 줄 수 있는 기간(경쟁사 이벤트, 시즌 이벤트 — 월드컵, 휴가철 등등) 을 피해서 일정과 기간을 설정.

실험 해석

• P밸류를 참고해 해석해야함
• 결과는 좋은데 P밸류가 낮으면?? 테스트 기간 연장, 표본 늘리기 등 조치를 취해야 함. (어떤 조치인지는 상황에 따라서...)

A/B테스트의 특징

• Winning group에 상관없이 테스트는 여러번 반복하는 과정을 거친다.
• A/B테스트는 현재 취할 수 있는 선택지 중 더 나은 선택지를 가려내는 도구.
  • 최적화를 하는 개념. 테스트를 통해 얻은 결과 ≠ 최고의 선택
• 새로운 아이디어를 실험하거나 큰 그림을 그리는 측면은 부족함.
• 구체적이고 명확한 기능일 수록 좋은 퍼포먼스가 나옴.
• ⚠️ A/B 테스트의 결과는 일시적임.
  • 테스트를 진행한 시점에서 결과가 어떤 의미를 갖는지 해석해야한다.
  • 과거의 결과를 현재에도 적용시키는 오류를 범하지 않도록 주의하자.

서비스 기획 숙련

[1-1]~[2-3]

Chapter 1. 데이터의 이해와 분석

[로그의 개념 및 설계 기초]

• 로그: 문제 해결 및 디버깅을 할 수 있는 기록(데이터 수집 도구).

  • 문제의 원인과 발생 위치 파악 (like 블랙박스).
  • 사용자 행동 분석 및 행동 추적.
  • 비즈니스 전략 수립 (로그를 통한 추적 내용 기반).

• Log types: 가장 핵심적인 것은 Client log.

  • 보고 싶은 것, 추적하고 싶은 것에 심어놓고 이벤트를 기록함.

• 로그 설계: '무엇'보다 '왜'가 중요함.

  • 왜? PM의 좌뇌에는 목적와 필요성이 새겨져있으니까.
  • 왜? 그것이 PM의 간지니까
  • 왜? 날 그렇게 쉽게 떠났니

[데이터 분석 방법론 - 퍼널, AARRR, A/B Test]

1. 퍼널(Funnel): 사용자가 특정 목표를 도달하는 여정을 추적 → 개선 방안 도출.
2. AARRR: 각 단계별 성과 측정 및 단계별 개선점 찾기.
3. A/B Test: 자경 튜터님 특강 정리에 합침

[구글 애널리틱스 – GA4]

• 정의: 웹/앱 방문자의 행동 분석 Tool.
• 대시보드: 방문자가 어디서, 언제, 얼마만큼 유입되는지 확인.
  • DAU, MAU, WAU 측정.
  • 유입 채널 파악을 통한 마케팅 최적화.
  • 어떤 행동을 하는지 분석 (클릭, 체류시간, 이탈 등).
• 주요 용어:
  • 세션: 사용자가 사이트에 방문한 기록 (페이지 단위 X, 사이트 출입 기준).
  • 페이지 뷰(PV): 페이지 조회수.
  • UV: 중복 제외 실제 방문자 수.
  • 이탈률(Bounce Rate): 한 페이지만 보고 떠난 비율. ㅠㅠ
  • 전환율(CVR): 목표를 달성한 방문자 비율.
  • 트래픽 소스: 방문자가 어디서 왔는지.

약간 출입국 사무소 같다는 느낌을 받음. 어디서 오셨어요? 뭐하러 오셨어요? 얼마나 있다 가세요?

[GA4 활용]

참여 보고서(참여도 탭)

• 활성 사용자 당 평균 참여 시간: 1명의 평균 참여 시간.

• 활성 사용자 당 세션 수: 1명이 몇 번의 세션을 발생시켰는지.

• 세션 당 참여 시간: 한 번 방문했을 때 머문 시간. (갈수록 한 번 방문 시 활동을 많이 한다는 의미)

• 활성 사용자: 단순 방문이 아닌 이벤트를 활성화한 유저.

• 조회수: 1명이 여러 번 조회한 개별 기록.

• 이벤트: 클릭, 스크롤 ~ 구매 완료까지 앱/웹 내 모든 이벤트.

  • 사용자 행동을 이벤트로 추적.
  • 활성 사용자 당 이벤트 수 = $\frac{총 이벤트 수}{해당 이벤트의 총 사용자}$

• 방문 페이지 vs 페이지 및 화면:

  • 방문 페이지: 어떤 페이지를 방문했니?
  • 페이지 및 화면: 방문해서 뭐 했니?

Q. 세션 당 참여시간이 짧으면 보통 부정적인 신호로 받아드려지는 거 같은데, 상황에 따라 참여시간이 길어서 문제가 되는 경우도 있는지? 예를 들어서 장바구니 페이지의 세션 당 참여시간은 긴데 구매 전환율이 낮으면 사용자 흐름에 병목이 있다고 판단 할 수 있는지?

*단비 튜터님 A. * 상황에 따라 문제점으로 해석할 수 있습니다. 참여시간은 긴데 유의미한 전환이 만들어지지 않는 경우, 사용자 행동을 유도하지 못하는 원인을 파악하고 개선해야함. 이와 별개로, 다른 형태로 문제가 되는 경우는 이상치 데이터인 경우입니다. 데이터 분석가가 이상치를 처리해주는 경우도 있지만 PM도 이상치 데이터를 다룰 줄 알아야합니다.참여 시간이 짧은 게 부정적 의미로 통하는 것 같은데, 상황에 따라 다르게 해석될 수 있는지?

[데이터의 프로젝트 활용]

• 리디북스의 AI 추천 기능 도입-
  • 데이터 기반 개인화 기능,
  • 베타 테스터를 결정할 때 활용.
    • 유사한 로직(다른 고객이 구매한 책)이 효과적이었던 유저층 분석.

Chapter 2. Soft Skills

킥오프 - 공유 - 회고

• [킥오프]
  • 최종 프로젝트의 기대 사항 확인.
  • 기록! 그리고 액션 아이템 정리.
• [공유]
  • 리스크 감지 — 문제 조기 감지 및 빠른 대응.
• [회고]
  • 커뮤니케이션이 잘 됐다면 → 어떻게 잘 됐는지, 다음 프로젝트에 적용할 수 있는 것들 정리.
  • 개선점 – 원인 분석 – 개선 방안 도출

하루를 회고하며...

왜 나는 항상 목표를 달성하지 못하는가

오늘은 아침에 열정 팀원들이랑 잠시 모여 회포를 풀었다. 사실 템플스테이 예약하려고 모였는데 웹이 터져서 목적 달성은 못하고 수다만 떨다 옴... 이것이 바로 목적 잃은 미팅의 위험성..? 온 세상이 PM이야 암튼 그렇게 수다 떨다가 GPT 강의를 마저 듣고 특강까지 듣고 나니 오전 시간 끝...

전날 일정 때문에 너ㅓㅓㅓㅓㅓㅓㅓ무 피곤했다. 점심 시간에는 밥도 안 먹고 잤다. 드르렁숭숭 오후시간 집중력에 대해서는~ 음~~ 슬랙으로 잡담하느라 학습에 몰입을 못한 거 같다. 이제 떠들고 싶으면 적어놨다가 쉬는시간이나 9시 이후에 모여서 타임어택으로 수다떨어야지..

본캠 시작하고 새로 팀 편성 되었을 때가 생각난다. 사캠 멤버들끼리 맨날 슬랙으로 보고싶다하고 엄청 그리워했는데, 일주일 지나니 다들 적응해버려서 더 이상 서로를 애타게 그리워하지 않게되었더랬지 (그래서 좋았었다는 의미). 언제나 새로운 환경은 기대반 걱정반이지만, 처음엔 어색하고 데면데면한 게 당연한거니까 이번에도 잘 적응해서 역기획 플젝까지 재밌게 무사히 마칠 수 있기를 바란다! 오늘 처음 팀원들 만났는데, 다들 엄청 열심히 하는데 나만 easy한 삶을 추구하는 거 같아서 벌써부터 약간 반성하게 되더라. 그치만 각자에 맞는 페이스가 있으니, 동기부여는 받고 프레셔는 흘려보내기 ㅎ