홍철이의 무한먹방

49일차[데이터드리븐]

홍철이의 무한먹방 — Thu, 14 May 2026 19:49:40 +0900

1. 데이터 드리븐 기획이란?

사용자 행동 데이터, 시장 데이터, 성과 데이터 등을 기반으로 의사결정을 내리고 제품을 기획하는 방식이다. 핵심은 '감'이 아니라 '근거'로 결정한다는 것.

예를 들어 "이 버튼 색을 빨갛게 바꾸면 더 잘 눌릴 것 같아"라는 감에 의존한 기획과, "A/B 테스트 결과 빨간 버튼이 파란 버튼보다 20% 더 클릭됐다"는 데이터 기반 기획은 결과의 신뢰도가 완전히 다르다.

2. 왜 중요한가?

세 가지로 정리할 수 있다.

① 정확한 기획이 가능하다. "메뉴를 숨기면 깔끔할 것"이라는 직감과 달리, 실제로 숨겨봤더니 클릭률이 30% 떨어진다면 데이터가 잘못된 결정을 막아준다.

② 고객이 진짜 원하는 것을 알 수 있다. 설문조사에서는 "이 기능 필요해요"라고 답해도, 실제 클릭률이 낮으면 진짜 니즈가 아닐 수 있다. 말이 아닌 행동을 본다.

③ 비즈니스 성과를 극대화할 수 있다. 결제 페이지 이탈률 50%를 발견하고 프로세스를 개선했더니 전환율이 15% 올랐다는 식의 구체적 개선이 가능하다.

3. 데이터 드리븐 기획 5단계

문제 정의 → 데이터 수집·분석 → 가설 수립·실험 → 결과 분석·의사결정 → 지속적 개선

Step 1. 문제 정의: "이 기능을 만들자"가 아니라 "무엇을 해결해야 하는가"부터 명확히
Step 2. 데이터 수집·분석: 사용자 행동 데이터(클릭, 체류, 이탈), 마케팅 데이터, 고객 피드백
Step 3. 가설 수립·실험: A/B 테스트로 해결책의 효과를 검증
Step 4. 결과 분석·의사결정: KPI 기반으로 평가, 입증되면 적용·실패하면 개선
Step 5. 지속적 개선: 모니터링을 멈추지 않고 다음 기획에 반영

4. 실제 사례

넷플릭스: 데이터로 콘텐츠를 만들다

넷플릭스는 완결률, 일시 정지·되감기 패턴, 시청 시간대 같은 데이터를 콘텐츠 전략에 활용한다.

대표적인 사례가 **<하우스 오브 카드>**다.

영국 원작이 인기였다는 점
원작 팬 중 케빈 스페이시·데이비드 핀처 작품을 즐겨 본 시청자가 많았다는 점
데이비드 핀처 팬은 한 번에 몰아보는 경향이 있었다는 점

이 세 가지 데이터를 결합해 제작을 결정했다. 결과적으로 넷플릭스 오리지널 콘텐츠 성공률은 80%로, 전통 TV 프로그램 평균(35%)을 압도했다.

카카오톡 검색

"검색 결과에 무엇을 보여줄지" 결정할 때 봐야 하는 지표는 각 탭(전체/채팅방/메시지/채널/오픈채팅)의 검색 버튼 클릭 수와 검색 후 유저가 실제로 클릭하는 요소다.

카카오톡 더보기

서비스 배치 순서를 정할 때 역시 클릭 데이터가 기준이 된다.

배달의민족 마이배민

주문 데이터를 기반으로 취향을 분류하고("매운맛 주문으로 배민 회원 중 상위 10%예요"), 음식을 추천하고, '배민취향' 같은 콘텐츠를 제작한다. 이때 활용되는 것이 메타데이터 — 데이터 자체가 아니라 그 데이터의 속성·맥락을 설명하는 정보다. (사진이 데이터라면 촬영 날짜·위치·카메라 모델은 메타데이터)

5. 꼭 알아야 할 데이터 분석 용어

사용자 규모

용어의미

PV (Page View)	페이지가 조회된 총 횟수 (새로고침도 카운트)
UV (Unique Visitor)	중복 제외 순 방문자 수
DAU / WAU / MAU	일간·주간·월간 활성 사용자 수

행동·전환

용어의미

Retention Rate	기존 사용자가 다시 방문하는 비율
이탈률	서비스를 이탈한 사용자 비율
CTR	(클릭 수 / 노출 수) × 100
Conversion Rate	(전환 수 / 방문자 수) × 100
DCU / DCC	일간 클릭 사용자 수 / 일간 총 클릭 횟수
세션	사용자 방문 활동의 한 단위
체류 시간	사이트에 머문 시간
Impression	노출된 총 횟수

광고·수익

용어의미

CPA	액션(가입·구매) 1건당 비용 = 광고비 ÷ 전환 수
CPC	클릭 1회당 비용 = 광고비 ÷ 클릭 수
CPM	1,000회 노출당 비용
CPI	앱 설치 1건당 비용
ARPU	사용자 1인당 평균 수익
ROI	(총 수익 - 총 투자) ÷ 총 투자 × 100

마무리하며

오늘 내용을 한 줄로 정리하면 — "감으로 기획하지 말고, 데이터로 질문하고 검증하라."

넷플릭스가 시청 패턴 데이터로 <하우스 오브 카드>를 성공시킨 것처럼, 배민이 주문 데이터로 '배민취향'을 만든 것처럼, 좋은 기획은 결국 좋은 데이터 질문에서 시작된다.

https://toss.im/simplicity-24/session/1?

Toss Design Conference | Simplicity24

Product Designer (Tools) 특별편 - Simple Questions, Big Wins

toss.im

https://simplicity-23.toss.im/sessions/12

사용자의 공감 얻으면서 제품 뜯어고치기

토스 디자인 컨퍼런스, Simplicity23

simplicity-23.toss.im

+ 데이터를 끈임없이 검증하라!!

48일차[아티클카타]

홍철이의 무한먹방 — Wed, 13 May 2026 19:25:32 +0900

1. 아티클 정보

https://yozm.wishket.com/magazine/detail/2580/

제목 : ‘불확실성’의 시대, PM의 역할과 마인드셋
작성자(저자) : 수완

2. 핵심 내용 요약

이 아티클의 주요 메시지 :
- PM의 일은 고객으로부터 학습하여 불확실성을 타개하는 것이다.
핵심 키워드 : 불확실성, 고객, 역할, 마인드셋

3. 흥미로운 점/새롭게 알게 된 점

읽으면서 가장 흥미로웠던 부분 :
- 리뷰 없는 상품의 구매 전환율에 대해 언급한 부분: 장바구니 전화율 개선 과제가 생각났음. 나도 고객이지만 정량적 데이터만으로 고객의 마음을 알기가 어려웠음. 답은 고객의 목소리를 듣는 것!
- PM은 ‘문제정의-문제탐구-해결방안탐구’ 과정을 지날 때마다, 최대한 자신의 편견과 의견을 제거하고 고객으로부터 힌트를 발견해야 한다. : 그동안 이 과정에서 난 편견과 의견을 제거했었는지 다시 생각해보게 됨
이전에는 알지 못했거나 새롭게 배운 내용 :
- PM이 갖춰야 할 3가지 마인드셋
  - 회복탄력성: 가설 검증은 '답 찾기'가 아닌 '고객 이해의 과정'. 하나의 실패에 일희일비하지 않기
  - 학습력: 성공/실패 모두에서 원인을 질문하고, 고객·시장·서비스 이해도를 누적
  - 실행력: 긴 호흡으로 끈질기게 고객 문제 해결을 추진

4. 나의 한 문장 요약

이 아티클을 한 문장으로 요약하면?
- PM은 자신의 추론과 편견을 내려놓고, 고객의 목소리로부터 답을 찾는 마인드셋을 가져야 한다.

46일차[framer]

홍철이의 무한먹방 — Mon, 11 May 2026 20:26:08 +0900

Framer 학습 기록 — 챕터 5-6, 5-7, 5-8 + '목록' 버튼 직접 만들기+영어공부

오늘은 Framer의 세 가지 주제를 학습했다. 템플릿 활용, Figma/Web에서 가져오기, Sticky/Fixed 포지셔닝. 거기에 더해 작업 중인 Airbnb 클론 프로젝트에 '목록' 버튼 컴포넌트를 직접 추가해봤다.

세 챕터를 관통하는 키워드를 먼저 적어두자면:

속도: 0에서 시작하지 않고, 템플릿·Figma 디자인을 출발점으로 삼는 법
구조: 섹션 단위로 쪼개고 Stack/Layout으로 묶는 사고방식
맥락: Fixed/Sticky처럼 "부모 구조"를 먼저 잡아야 작동하는 기능들

. . .

챕터 5-6. Framer 템플릿 — 빠르게 시작하는 법

Framer 마켓플레이스에는 무료/유료 템플릿이 있다. 무료는 'Use for free'를 누르면 내 대시보드로 바로 복사되고, 유료는 결제 후 이메일 링크로 받는다. 복사된 템플릿은 일반 프로젝트와 똑같이 자유롭게 수정 가능하다는 게 핵심.

PM 관점에서 보면 템플릿은 **"가설을 빠르게 검증하기 위한 출발점"**이다. 0에서 시작하지 않고, 비슷한 톤의 템플릿을 가져와서 빠르게 프로토타입을 만들고 사용자 반응을 보는 방식.

→ **"처음부터 완벽하게 만들지 말고, 빠르게 만들고 빠르게 고친다"**는 원칙과 잘 맞는다.

. . .

챕터 5-7. Figma & Web에서 가져오기 — 섹션 단위로 쪼개기

Figma 디자인을 Framer로 옮기는 워크플로우. 핵심은 전체를 한 번에 가져오지 말고 섹션 단위로 복사하는 것.

자주 발생하는 오류와 해결법

레이어 순서 오류 → Bring to Front
마스킹 오류 → Mask radius 조정
SVG 깨짐 → Figma에서 다시 내보낸 후 드래그 앤 드롭

반응형 작업 포인트

텍스트·버튼은 Stack으로 묶고 정렬/간격 설정
텍스트는 반드시 Fill width로 설정 (화면 줄어들 때 잘림 방지)
섹션 단위로 상위 Stack에 묶기, 전체 Frame도 Layout으로 (Gap = 0)
Breakpoints는 상위 설정이 하위로 자동 상속

→ 섹션 단위로 쪼개는 사고방식이 인상적이었다. 디버깅도 쉽고 책임 범위도 명확해진다. 디자인뿐 아니라 프로덕트 전체를 만드는 사고방식과 닮아있다.

. . .

챕터 5-8. Sticky / Fixed 포지셔닝 — 결국 부모 구조가 핵심

항목FixedSticky

동작	스크롤과 무관하게 고정	스크롤 중 특정 위치에서 잠시 고정
기준	브라우저 뷰포트	부모 프레임의 상단/하단
사용 예	상단 네비, 플로팅 버튼	사이드 카드, 섹션 헤더
부모 조건	Breakpoints Frame의 직접 자식	Stack/Grid 자식 + Overflow: Visible
주의	z-index 확인	Overflow: Visible 필수

→ 두 포지셔닝 모두 부모 요소의 구조와 설정이 핵심. 구조를 미리 안 잡아두면 "왜 안 되지?" 하고 한참 헤매게 된다. 구조부터 잡고 작업하는 습관이 중요하다.

. . .

실습. '목록' 버튼 컴포넌트 만들기

Framer Workshop의 컴포넌트 생성 기능을 활용해서, Airbnb 클론 상세페이지에 **"목록으로 돌아가는 버튼"**을 추가했다.

요구사항 정의

정상: 목록 → 상세 → 목록 버튼 → 이전 목록 페이지로
예외: 새 탭에서 상세에 바로 진입한 경우 (history 없음) → fallbackUrl로 이동

처음엔 document.referrer로 검증하려 했지만, Framer 미리보기 환경에서 referrer가 불안정해서 결국 window.history.length > 1로 판단하는 방식이 더 안정적이었다.

최종 로직

if (window.history.length > 1) {
  window.history.back()
} else if (fallbackUrl) {
  window.location.href = fallbackUrl
}

시행착오 3가지

1. 404 페이지가 뜸

원인: fallbackUrl이 기본값 /로 되어있고, referrer 체크에서 fallback으로 빠짐
해결: window.history.length 기반 체크로 수정

2. 디자인 톤 안 맞음

원인: 처음엔 검정 사각형 버튼 → 페이지의 다른 알약 모양 버튼들과 충돌
해결: 색상 #FFB3C9 핑크 + 알약 형태로 변경, 페이지의 다른 핑크 포인트들과 톤 통일

3. 반응형 레이아웃 깨짐 (← 오늘 배운 내용과 직결)

원인: 버튼이 이미지와 같은 Stack에 묶여있지 않음. 화면이 넓어지자 버튼만 왼쪽으로 떨어져 나감
해결: 오늘 배운 Layout/Stack 개념으로 이미지+버튼을 같은 Stack에 묶음

나중에 영어 때문에 원하는 회사에 지원하지 못할 수도 있을 것 같아서 영어공부를 시작함.

나에게 맞는 방식을 찾아가는 중

45일차[framer, 아티클카타]

홍철이의 무한먹방 — Fri, 8 May 2026 20:31:48 +0900

오늘의 학습 기록: 아티클 카타 + Framer 챕터 5

오전엔 비판적 사고와 PM의 AI 활용에 대한 아티클을 함께 읽고 카타했고, 오후엔 Framer로 사이트를 실제 세상에 내보내는 마지막 단계 — 도메인, 요금제, SEO, 다크 모드까지 — 를 다뤘다. 따로 보면 무관해 보이지만, 두 주제가 묘하게 한 줄에서 만난다: "좋은 결과물은 좋은 질문과 좋은 디테일에서 나온다."

Part 1. 아티클 카타

첫 번째 아티클: 비판적 사고와 조직 커뮤니케이션

핵심 논의

비판적으로 사고하고 의견을 내는 것이 회사에서 평판을 깎는 일이 되는 이유는 무엇일까? 결론은 의견 자체가 아니라 태도와 화법의 문제였다.

튜터님 피드백 정리

Q1. 비판적 사고로 반박했을 때 평판이 나빠지는 이유

"A는 틀렸고 B가 맞다"는 직접 반박이 아니라, 상대 의견에 살을 붙이는 방식으로 전달해야 함
예시 화법: "A 방향을 이해하지만 검토해보니 이러한 리스크가 예상되는데, 어떻게 보완하면 좋을까요?"
회사는 싸우러 모인 곳이 아니라 일을 잘하기 위해 모인 곳

Q2. 수직적 조직에서 상사 의견이 곧 지시가 될 때

의사결정 전에는 충분한 근거 자료(보고서 등)로 설득 시도
이미 결정된 사안에 다시 말 붙이는 건 딴지처럼 느껴질 수 있음
결정 후엔 일단 실행하고 결과로 검증되는 과정이 필요

Q3. 내가 방어적으로 듣고 있는지 점검하는 법

상대가 왜 그런 의도로 말했는지 역으로 질문해보기
상대방의 관점·의도·배경을 다시 살펴보기
"근데, 그게 아니라" 같은 반박성 언어 습관이 나오는지 객관적으로 체크
정답을 찾으려 하는지, 허점만 건드리려 하는지 자문하기

Q4. 신뢰 기반 수용 vs 무조건적 수용

구분 특징 결과

무조건적 수용	시킨 대로만 수행	실패 시 "시킨 대로 했는데"로 회피
신뢰 기반 수용	지시의 의도까지 파악, 액션 플랜 함께 고민	실패 시 공동 책임, 상대 논리를 내 논리로 재구성

두 번째 아티클: AI를 잘 쓰는 기획자는 왜 질문부터 다를까?

우리 팀 공통 인사이트

질문의 방향이 기획의 방향을 결정한다. 더 좋은 답을 요구하기 전에, 내가 어떤 전제를 깔고 질문하는지부터 점검할 것.
정리형 질문은 변화형 질문을 밀어낸다. "무엇이 다른가" 보다 "무엇이 왜 뒤집히고 있는가" 를 먼저 볼 것.
AI는 답변 엔진이 아니라 전제 점검 도구로 활용해야 함. "정리해줘" → "내가 놓친 전제를 먼저 짚어줘"
출처 확인은 링크가 아니라 제목과 날짜로. AI가 준 링크를 그대로 믿지 말고 직접 검증.
탐색 단계와 정리 단계를 분리해서 AI를 사용한다. 탐색은 넓게, 정리는 좁고 명확한 조건으로.
기획자의 경쟁력은 질문의 양이 아니라 질문의 각도에서 나온다. 어떤 질문을 하지 않고 있는지를 발견하는 사람이 좋은 기획자.

튜터님 피드백 정리

Q1. PM이 AI를 쓸 때 가장 중요한 원칙

"AI의 답변은 정답이 아니다."

비서·에이전트로 활용하되 맹신하지 말 것. AI가 제시한 내용이 우리 조직·프로젝트·프로덕트에 실제로 적용되는지 검토하는 과정이 반드시 필요함.

Q2. AI를 가장 유용하게 활용한 순간

파편화된 데이터에서 패턴 도출할 때 (앱스토어 리뷰, VOC 분석 등). 사람이 직접 분석하면 보고 싶은 것만 보는 편향이 생기지만, AI는 데이터 기반으로 빈도·비중 높은 페인포인트를 객관적으로 추출해줌.

Q3. AI 사용 시 주의할 점

AI는 질문자의 성향을 반영해 그 사람이 원하는 방향으로 답변을 유도하는 경향이 있음. 너무 매끄럽게 답할 때일수록 비판적으로 의심하고, RAG·출처 확인으로 검증할 것.

Q4. 신입 PM 시절 AI가 있었다면

개발자·디자이너와의 소통에 활용했을 것:

"이 기능에 대해 백엔드/프론트엔드/디자이너가 가장 반박할 만한 포인트는?"
"그 반박에 대응하려면 어떤 자료를 준비해야 하나?"

→ 협업 설득 자료를 준비하는 데 AI가 큰 힘이 됨.

추가 Q&A

Q. AI 더블체크 시간이 너무 길다, 어떻게 효율화할까?

초안을 AI에게 맡기지 말고, 본인이 초안을 작성한 뒤 보완점을 묻는 방식 권장
답변 시 출처·공식 자료를 함께 기재하도록 프롬프트에 명시
"방금 답변에서 오류 가능성이 가장 높거나 사실관계가 모호한 부분을 짚어 다시 검증해달라" 추가 요청
결과적으로 시간이 단축되므로 더블체크 자체를 두려워할 필요는 없음

Q. 여러 AI를 써도 같은 프레임에 갇히는 게 아닐까?

여러 AI 활용은 사고 확장에 도움이 되는 게 맞음. 다만 더 중요한 건 AI 도구를 사용하는 사람의 중심(원칙·관점). 비슷한 답이 반복된다면 AI가 사용자의 성향을 학습해 맞춤 답변을 주고 있을 가능성이 큼.

"네 답변에 오류가 없는지 검증해봐" 라고 재요청하면 다른 결과가 나올 수 있음. 내 생각과 AI 답변의 갭을 분석하는 과정 자체가 중심을 세우는 훈련.

기타 Q&A

Framer 과제가 실무에 도움이 될까?

조직마다 다르지만 작은 조직·소규모 프로젝트에서는 PM이 직접 랜딩 페이지를 구현하기도 함. 이 과제의 핵심은 반응형 UI 레이아웃 구조와 CMS 개념을 직접 경험으로 체화하는 것. 당장 안 쓰더라도 이력 소스가 됨.

현업에서 AI는 어디까지 활용되나?

사람·조직마다 천차만별. 보안상 외부 LLM 사용이 막혀 자체 LLM·RAG를 구축한 조직도 있음. 튜터의 스타트업 경험상 거의 모든 업무 검토·리뷰에 AI를 활용했고, 개발자도 Cursor·Claude Code로 뼈대를 잡는 식으로 사용. 최근 롯데 그룹은 전 임직원 1인 1 AI 에이전트 비전을 선포 — AI 활용이 곧 성과 지표가 되는 시대로 진입 중.

오늘의 카타가 남긴 한 줄

"AI에게 더 좋은 답을 요구하기 전에, 나는 어떤 전제를 깔고 질문하고 있는가?"

좋은 질문을 던지는 능력은 결국 비판적으로 듣는 능력과 짝을 이룬다. 첫 번째 아티클(비판적 사고)과 두 번째 아티클(AI 질문 설계)이 결국 같은 근육을 다루고 있었다.

Part 2. Framer 챕터 5 — 사이트를 세상에 내보내기

챕터 5는 그 사이트를 실제 세상에 내보내고 운영하는 법에 대한 이야기다. 도메인 연결, 요금제, SEO, 접근성, 다크 모드까지 — 디자인 작업이 끝난 뒤에 신경 써야 할 것들이 한꺼번에 들어 있다.

다섯 개 챕터를 관통하는 키워드를 먼저 적어두자면:

완성도: 파비콘, OG 이미지처럼 작아 보이지만 신뢰도를 좌우하는 디테일
유연성: 무료 도메인부터 커스텀 도메인까지, 상황에 맞춰 확장 가능한 구조
지속 가능성: SEO와 접근성을 처음부터 고려해야 나중에 손이 덜 간다

챕터 5-1. Site & Page Settings — 놓치기 쉬운 설정들

UTM 파라미터 유지 (Preserve URL Parameters)

마케팅 캠페인을 운영할 때 가장 중요한 건 "이 방문자가 어디서 왔는지" 추적하는 것. UTM은 URL 뒤에 붙이는 추적 코드다.

https://example.com?utm_source=instagram&utm_campaign=spring

Framer에서 Preserve URL Parameters 옵션을 켜두면, 사용자가 첫 진입 후 다른 페이지로 이동해도 UTM이 유지된다. 꺼져 있으면 페이지 이동 순간 파라미터가 날아가서 GA4 분석이 부정확해짐.

→ 마케팅 사이트라면 무조건 켜둬야 하는 옵션.

사이트 이미지 3종 세트

항목 용도 권장 사이즈

Favicon	브라우저 탭/북마크 아이콘	64×64
Social Preview (OG Image)	SNS·메신저 공유 시 썸네일	1200×630
Apple Touch Icon	iOS 홈 화면 저장 시 아이콘	180×180

세 개 다 별도 이미지 파일을 미리 준비해야 한다는 게 포인트. 특히 OG 이미지는 카카오톡·슬랙 공유했을 때 보이는 그 카드 — 있고 없고가 신뢰도 차이가 크다.

그 외 알아둘 옵션

Edit 버튼 숨기기: 에디터에게 거슬리는 그 버튼은 일반 방문자에게는 원래 안 보이지만, 작업자 입장에서 끄고 싶다면 설정 가능
비밀번호 보호: 프리미엄 플랜 한정. 출시 전 클라이언트 검토용으로 유용
자동 로컬 전환 (Localization): 브라우저 언어 설정에 따라 en-US / ko-KR 등 적절한 페이지로 자동 이동. 글로벌 사이트 운영 시 고려
커스텀 코드 삽입: Head/Body의 시작·끝에 스크립트 추가 가능. GA4, Hotjar, 챗봇 등을 붙일 때 사용. 다만 기능 충돌 가능성 있어 신중하게.

챕터 5-2. 배포 & 도메인 연결

사이트 배포의 흐름

Site Settings → Domain 탭에서 모든 게 관리된다. 배포 시 자동으로 랜덤이름.framer.app 서브도메인이 생성되고, 사이트 제목 옆 URL을 클릭하면 실시간 배포 버전을 확인할 수 있다.

도메인 연결, 두 가지 선택지

1. 무료 Framer 도메인 (myname.framer.website 등)

무료 플랜에서도 사용 가능
포트폴리오·간단한 프로젝트엔 충분

2. 커스텀 도메인 (mybrand.com 등)

유료 플랜(Basic 이상) 필요
본격 비즈니스용

커스텀 도메인 연결 3단계

1단계. Framer에서 도메인 추가

Site Settings → Domains → Add Domain
도메인 입력 후 DNS 설정 정보 받기

2단계. 도메인 등록처(가비아·고대디·카페24 등)에서 DNS 설정

A 레코드 (루트 도메인용):

Type Name Value

A	@	76.76.21.21
A	@	76.76.22.22

CNAME 레코드 (www 서브도메인용):

Type Name Value

CNAME

www

sites.framer.app

기존에 같은 레코드가 있다면 삭제 후 새로 등록. DNS 반영은 보통 수 분~수 시간, 길면 48시간까지 걸린다.

3단계. Framer에서 ✅ Connected 상태 확인

이 흐름은 Framer뿐 아니라 다른 노코드 툴(웹플로우, 슈퍼블 등)에서도 거의 동일하다. 한번 익혀두면 평생 써먹음.

챕터 5-3. Framer 요금제 — 어디까지 무료로 가능할까

무료 플랜의 범위

최대 1,000페이지
CMS 컬렉션 10개
월 1,000명 방문자
월 100MB 대역폭
무료 SSL 인증서
Framer 서브도메인 + "Made in Framer" 배지

→ 포트폴리오, Coming Soon 페이지, 가벼운 브랜드 랜딩 정도는 무료로 충분.

유료 플랜이 필요한 시점

커스텀 도메인 연결이 필요할 때
트래픽이 늘어나기 시작할 때
CMS 컬렉션이 10개를 넘을 때
스테이징(검토 후 배포) 환경이 필요할 때
폼 제출 수, 버전 기록 관리가 중요해질 때

플랜별 핵심 비교 (월간 기준)

항목 Mini Basic Pro

페이지 수	Home + 404만	1,000	10,000
CMS 컬렉션	✖	2개	10개
대역폭	10GB	50GB	100GB
폼 제출 수	50	500	2,500
저장 공간	500MB	1GB	10GB
패스워드 보호	✖	✔	✔
리디렉션	✖	✖	최대 100개
스테이징	✖	✖	✔
버전 히스토리	3일	7일	30일

협업 요금의 함정

사이트 소유자 1명은 항상 무료
에디터 추가 시 인당 과금 (₩19,998/인 — Pro 기준)
워크스페이스 내 가장 높은 플랜 기준으로 책정됨 → A 사이트가 Pro, B 사이트가 Free여도 워크스페이스 전체가 Pro 기준으로 과금

이 부분은 팀 단위로 쓸 때 비용 산정하다가 놓치기 쉬운 포인트.

정리

소규모 프로젝트 = 무료로 충분
커머스, 마케팅, 팀 기반 사이트 = Pro 이상 권장
확장을 미리 예상하고 시점을 계획하기

챕터 5-4. SEO & 접근성 — 검색에 잘 잡히고, 누구나 쓸 수 있게

이 챕터가 개인적으로 가장 인사이트 컸다. SEO와 접근성은 따로 노는 개념이 아니라, 사실상 같은 작업을 하면 양쪽이 동시에 좋아진다는 점.

시맨틱 태그 — 구조에 의미 부여

텍스트: H1~H6, paragraph로 계층 구조
프레임: header, footer, nav, main, section 같은 시맨틱 태그 직접 지정 가능
Text Style의 기본 태그 외에 개별 텍스트 레이어에도 별도 지정 가능

→ 검색 엔진은 이 구조를 보고 페이지의 위계를 이해한다. 스크린 리더도 마찬가지.

이미지·아이콘에 의미 부여

Alt Text: 이미지 프레임 → Fill 속성 아래에서 입력. 시각장애인용 스크린 리더가 음성으로 읽어줌
ARIA Label: 비시각적 그래픽이나 아이콘에 사용. 예: SNS 아이콘에 "Visit us on Instagram"

Tab Index — 키보드 사용자 배려

기본은 레이어 순서대로 Tab 이동
중요한 CTA 버튼은 Tab Index = 1로 설정해서 우선순위 부여 가능

Googlebot 설정

SEO상 노출 원치 않는 프레임(광고 영역 등)은 Googlebot → Skip 설정으로 색인 제외 가능

Site & Page Settings

Site Language: 검색 엔진과 스크린 리더에 언어 정보 제공
Reduce Motion: 사용자가 모션 줄이기 선호 시 애니메이션 자동 제거
Page Title: 60자 이내 권장
Page Description: 160자 이내 권장
자연스러운 키워드 포함 — 키워드 스터핑 ✗

URL 구조

페이지명이 곧 URL 경로 (예: /about-us)
소문자 + 하이픈으로 단어 구분 (공백은 자동 하이픈 처리)
짧고 명확한 URL이 검색·UX 모두에 유리

검색 노출 제어

개별 페이지 설정에서 "Search Engines에서 숨기기" 옵션으로 특정 페이지를 색인에서 제외 가능. 어드민·내부용 페이지에 유용.

챕터 5-5. 라이트/다크 테마 적용

핵심 개념: 컬러 스타일이 테마를 책임진다

Framer의 컬러 스타일은 하나의 스타일로 라이트/다크 모드 양쪽을 모두 정의할 수 있게 설계되어 있다.

방문자 디바이스가 라이트 모드 → 라이트 테마 자동 로딩
다크 모드 → 다크 테마 자동 로딩
한 번 잘 세팅해두면 어디서든 자동 전환

설정 방법

기본적으로 컬러 스타일은 라이트 모드만 정의되어 있다. 다크 모드는 수동으로 지정해줘야 한다.

컬러 스타일 편집 시 라이트/다크 각각 색상 지정
같은 스타일을 쓰는 모든 레이어에 자동 반영
Canvas 우측 하단에서 라이트/다크 토글하며 미리보기 가능

다이내믹 컬러 네이밍 팁

색상명은 용도 기반으로 짓는 게 좋다. 색 이름(red, blue)이 아니라 역할(background, surface, text)로.

black 900: 검정
black 000: 흰색
background: 다크 모드에선 제트블랙
background 1: 카드 배경 — 다크 모드에선 살짝 밝은 회색

이렇게 하면 다크 모드에서 색상이 뒤집혀도 의미가 깨지지 않는다.

스태틱 컬러 (Static Color)

테마와 무관하게 항상 같은 색을 유지하고 싶을 때 사용.

예: 브랜드 섹션은 항상 검정 배경 + 흰 텍스트
새 컬러 스타일 생성 시 다크 모드 값을 지정하지 않으면 자동으로 스태틱
네이밍 예시: Static/black900, Static/black000

다크 모드 설정 제거

이미 다크 모드 색상을 지정한 스타일을 다시 스태틱으로 바꾸고 싶다면: Assets 패널 → 해당 스타일 메뉴(···) → Clear Dark Style

요약 표

항목 요약

테마 연동 컬러	컬러 스타일 하나로 라이트/다크 자동 전환
다크 모드 설정	스타일 편집 시 직접 다크 모드 색상 지정
스태틱 컬러	항상 같은 색 유지, 라이트/다크 무관
적용 방식	Canvas에서 실시간 전환 미리보기 가능
초기화	Assets 패널에서 다크 스타일 제거 가능

오늘의 한 줄 기획자의 경쟁력은 질문의 양이 아니라 질문의 각도에서 나온다. 사이트 만들기든 AI 쓰기든, 결국 같은 자세에서 출발한다.

44일차[framer 과제]

홍철이의 무한먹방 — Thu, 7 May 2026 20:31:54 +0900

Framer로 에어비앤비 스타일 사이트 만들기 — 작업 기록

결과물: https://appreciative-points-868576.framer.app/popular

과제로 Framer를 이용해 에어비앤비 같은 숙소 서비스 사이트를 만들었다. AI 도움 받아가며 하루 만에 어찌어찌 완성했다. 막혔던 포인트가 꽤 많아서 다음에 또 비슷한 작업할 때 참고하려고 기록을 남긴다.

과제 목표

CMS(데이터)를 만들고 화면에 연결
목록 페이지 → 상세 페이지로 이어지는 구조
공통 레이아웃(Header/Footer) 재사용
조건에 따라 페이지 분기 (지역별, 인기 등)
SEO/공유 메타데이터 설정

1. CMS 데이터 구조 설계

가장 먼저 한 일은 데이터 구조 잡기. Framer의 CMS는 컬렉션 단위로 만든다.

Properties 컬렉션 필드:

Name (Plain Text) — 숙소 제목
Slug (Slug) — URL용
Image (Image) — 대표 사진
Location (Plain Text) — 위치
Price (Number) — 1박 가격
Summary (Plain Text) — 짧은 요약
Description (Rich Text) — 상세 설명
Region (Option: 서울/부산/제주) — 지역 분기용
isHot (Toggle) — 인기 숙소 표시용

지역 분기에 Region, 인기 숙소 분기에 isHot을 쓰는 게 핵심. 이 두 필드가 나중에 페이지 필터링에 다 활용된다.

2. Header 가운데 정렬 — Grid가 답이었다

처음에 헤더에 로고/메뉴/액션버튼을 배치했는데, "숙소·체험·서비스"가 가운데로 안 갔다. Stack의 Distribute: Space Between을 썼는데도 자꾸 로고 옆에 붙어버렸다.

원인: Space Between은 "남는 공간을 균등 분배"하는 거지 정중앙 정렬이 아니다. 자식 너비에 따라 위치가 바뀐다.

해결: Stack을 Grid로 바꾸고 3 컬럼(1fr 1fr 1fr) 으로 만든 뒤 각 자식에 Justify Self만 다르게.

로고 → Start (왼쪽)
메뉴 → Center (가운데)
액션 → End (오른쪽)

이렇게 하니까 화면 폭이 바뀌어도 항상 가운데 메뉴는 정중앙에 고정됐다. Framer에서 헤더 만들 땐 Grid가 표준 패턴이라는 걸 처음 알았다.

3. 카드 사이즈 통일 — 코드 컴포넌트와 씨름(클로드가 해결해줌)

Properties 목록 페이지를 만들었는데 카드들이 다 들쭉날쭉했다. 어떤 건 사진이 길고, 어떤 건 짧고. 사진마다 가로세로 비율이 달라서 그런 거였다.

문제 1: 코드 컴포넌트(AccommodationCard)에 이미지 영역이 height: "60%" 로 돼있었음. 부모 높이의 60%인데, 부모(카드) 높이가 들쭉날쭉하니까 이미지도 같이 흔들림.

해결: 이미지 높이를 고정 픽셀(220px)로 바꾸고, flexShrink: 0 추가.

{/* Before */}
height: "60%"

{/* After */}
height: imageHeight,  // prop으로 220px 받음
flexShrink: 0,

문제 2: 제목/요약 길이 때문에 카드 높이가 또 달라짐.

해결: WebkitLineClamp 줄 수 제한을 prop으로 노출. Name Lines = 1, Summary Lines = 2로 고정하니까 카드 높이가 통일됐다.

핵심 학습: objectFit: cover만 알면 되는 줄 알았는데, 컨테이너 높이가 변하면 그것도 무용지물이었다. 고정 높이 + flexShrink 0 + objectFit cover 3종 세트가 정답.

4. 상세 페이지 레이아웃 — flex wrap의 함정

상세 페이지에서 왼쪽엔 설명, 오른쪽엔 예약 카드를 넣고 싶었는데 자꾸 위아래로 쌓여버렸다.

원인: 컨테이너가 display: flex + flexWrap: wrap이었는데, 내부 컨텐츠 합산 너비가 컨테이너보다 크면 자동으로 줄바꿈됨. 의도한 동작이긴 하지만 좁은 화면에서 항상 wrap돼버려서 답답했다.

해결: flex → grid로 변경.

display: "grid",
gridTemplateColumns: "minmax(0, 1fr) 372px",
gap: "48px",
alignItems: "start",

minmax(0, 1fr)의 0이 핵심이다. 이게 없으면 자식이 길어졌을 때 컬럼이 안 줄어들어 레이아웃이 깨진다.

배운 점: 2단 고정 레이아웃은 flex보다 grid가 훨씬 안정적. flex는 아이템이 동적으로 늘어나는 경우에 좋고, grid는 의도한 그리드 구조를 강제할 때 좋다.

5. 목록 버튼 만들기 — 가장 오래 걸린 작업

상세 페이지에서 "목록" 버튼을 누르면 이전 페이지로 돌아가게 하고 싶었다.

제일 오래 걸렸던 부분인데..결국 실패 아몰랑

6. 조건부 페이지 — Region/isHot 필드 활용

가장 재밌었던 부분. 같은 Properties 컬렉션을 다른 필터로 보여주기.

/seoul 페이지: Properties 필터링 → Region equals "서울"
/busan 페이지: Region equals "부산"
/jeju 페이지: Region equals "제주"
/popular 페이지: isHot equals true

페이지를 4개 따로 만들 필요 없이 Collection List의 Filter만 다르게 걸면 끝.

7. 연관 숙소 섹션 — Current Item이 핵심

상세 페이지 하단에 "이 지역의 다른 숙소" 추천 섹션 만들기. 이게 가장 어려웠다.

핵심 개념: Detail Page 안에서 Collection List의 필터를 걸 때 "Current Item" 변수를 쓸 수 있다. Variable 추가 시 → Set Variable → Region 필드 선택.

필터 두 개 적용:

Region Equals → Region (Variable) — 같은 지역
Slug Not Equals → Slug (Variable) — 본인 제외

이 둘을 같이 걸어야 "본인 빼고 같은 지역 숙소만" 추천된다.

추천 카드 디자인은 따로 만들지 않고 AccommodationCard 컴포넌트를 그대로 재사용. 단, Image Height만 220 → 140으로 줄여서 본 상품보다 시각적으로 작게 보이게 했다. 이게 정보 위계상 더 자연스럽다.

8. 가운데 정렬 — Stack + Wrap + Center

추천 숙소가 2개일 때 Grid 3 컬럼이라 왼쪽으로 쏠리는 문제. 해결책은 Layout: Stack(가로) + Wrap: Yes + Distribute: Center.

이렇게 하면:

1개 → 가운데 1개
2개 → 가운데 2개
3개 → 꽉 채워서 3개
4개 이상 → 자동 줄바꿈

Grid는 셀 개수가 고정되지만 Stack은 컨텐츠 개수에 따라 자연스럽게 흐른다. 개수가 변하는 카드 그리드는 Stack이 더 유연하다.

9. SEO 동적 메타데이터

Detail Page의 SEO는 일반 페이지와 다르게 CMS 필드를 변수로 바인딩할 수 있다.

Title: {Name} | {Region} | AIRbnb
Description: {Summary}
OG Image: {Image} 바인딩

이렇게 해두면 숙소 100개여도 메타데이터가 자동으로 100개 다르게 만들어진다. 이게 정적 사이트 빌더의 진짜 매력 같다.

10. 마지막 함정 — Draft 페이지

Publish하고 새 탭에서 열어보니 인기/서울/제주/부산 탭이 작동을 안 했다. 편집기 미리보기에선 잘 됐는데.

원인: 해당 페이지들이 모두 DRAFT 상태였다. Framer에서 Draft 페이지는 Publish해도 실제 사이트에 포함되지 않는다. Preview는 Draft도 보여주니까 모르고 지나가기 쉽다.

해결: 각 페이지 우클릭 → Publish Page → 다시 사이트 Publish.

이건 진짜 모르면 한참 헤맬 함정. 항상 Pages 패널에서 DRAFT 라벨 다 사라졌는지 확인하고 게시할 것.

오늘 배운 것 정리

기술적인 것:

Framer의 CMS는 컬렉션 + 필터의 조합으로 거의 모든 분기를 만들 수 있다
Detail Page 안에서는 Current Item 변수가 핵심 도구
Layout은 상황에 따라 Grid / Stack을 갈라 써야 한다 (정형 = Grid, 가변 = Stack)
objectFit cover는 컨테이너 크기가 고정돼야 의미 있다

작업 태도:

처음부터 완벽하게 하려 하지 말고 최소 단위로 작동시킨 뒤 점점 확장
막힐 때 캡처해서 물어보면 빠르게 풀린다
Draft → Published 같은 작은 함정에서 시간 다 잡아먹힘

다음에 비슷한 거 만들 때:

CMS 컬렉션 하나만 먼저 만들기
데이터 5~10개만 입력하고 화면 연결 확인
Header/Footer 컴포넌트화
필터로 분기 페이지 만들기
코드 컴포넌트는 마지막에 손대기
Publish 전 Draft 다 풀기 ← 이게 제일 중요

코드 한 줄 못 짜는데 코드 컴포넌트도 만지고, CMS 데이터 구조도 잡고, SEO까지 설정해봤다. AI 도움 받았다고 해도 직접 손으로 만든 사이트가 진짜 동작하는 걸 보니까 뿌듯하다. 다음 과제도 이렇게 정리하면서 가야겠다.

43일차 [framer, 클로드 자동화]

홍철이의 무한먹방 — Wed, 6 May 2026 20:00:15 +0900

오늘의 학습 기록 — Framer 데이터 분석부터 Claude 자동화까지

오늘은 크게 세 갈래의 흐름이 있었다. ① Framer를 중심으로 한 데이터 수집·분석·실험의 전체 파이프라인 학습 (챕터 4-1 ~ 4-6), ② "설득당하기"의 중요성에 대한 아티클 카타, ③ Claude를 활용한 설문 응답 분석 자동화 실습.

세 가지가 따로따로처럼 보이지만, 곱씹어보면 결국 "내가 만든 것에 대한 데이터를 어떻게 모으고 → 어떻게 해석하고 → 그 해석을 어떻게 받아들일 것인가" 라는 한 흐름으로 이어진다는 게 오늘의 작은 깨달음이다.

1. 데이터 수집부터 실험까지 — Framer 기반 분석 파이프라인

이번 챕터의 6개 강의는 사실 하나의 큰 퍼널을 다룬다.

사이트 방문자 측정 (Framer Analytics)
        ↓
정밀한 행동 추적 (GA4 연동)
        ↓
데이터 해석 (GA4 분석/탐색)
        ↓
사용자 응답 수집 (Form Builder)
        ↓
응답 자동화 (Google Sheets / Webhook + Make)
        ↓
가설 검증 (VWO A/B 테스트)

각 단계를 정리하면 이렇다.

챕터 4-1. Framer Analytics — 가장 가벼운 시작

별도 설치 없이 퍼블리시만 하면 자동으로 작동한다는 점이 매력적. Unique Visitors, Page Views, Bounce Rate, Average Session Duration 같은 핵심 지표를 바로 볼 수 있고, ad blocker에도 안 막히고 GDPR도 준수한다는 게 장점.

핵심 인사이트는 "GA4처럼 복잡한 리포트가 필요 없다면 이것만으로도 충분하다" 는 점. 초기 단계에서는 도구를 늘리는 것보다 있는 데이터를 정확히 보는 게 중요하다는 걸 다시 느꼈다.

챕터 4-2. GA4 연동 — 더 깊이 들여다보기

Framer Analytics가 "방문자 수"라면, GA4는 "어떤 버튼을 눌렀는지", "어떤 경로로 들어왔는지" 를 본다. 이벤트 기반 분석이라는 차이가 핵심.

연동 자체는 단순하다.

analytics.google.com에서 GA4 속성 생성
측정 ID(G-XXXXXX) 복사
Framer → Project Settings → Analytics에 붙여넣기

더 정밀한 추적이 필요하면 GTM, dataLayer.push(), data-framer-name 속성 등을 활용할 수 있지만, 지금 단계에서는 "전환 흐름을 파악하는 훈련"이 더 중요하다는 강의의 코멘트가 가장 와닿았다. 도구를 더 깊이 쓰기 전에 기본기를 잡으라는 것.

챕터 4-3. GA4 데이터 분석 — 보고서 vs 탐색

가장 많이 헷갈리는 부분이 정리됐다.

항목 보고서(Reports) 탐색(Explorations)

성격	자동 정리된 기본 데이터	분석자가 직접 구성
용도	빠른 현황 확인	깊이 있는 분석, 가설 검증
커스터마이징	거의 불가	매우 자유로움

보고서 = 현황 요약 / 탐색 = 직접 실험하는 도구. 이 한 줄로 정리됐다.

탐색 리포트 유형 중에서는 퍼널 탐색(가입 → 온보딩 완료 → 구매) 과 경로 탐색(버튼 클릭 후 사용자 이동 경로) 이 PM 업무에서 가장 자주 쓰일 것 같다는 생각.

챕터 4-4. Form Builder — 응답을 모으는 도구

Framer 자체에 Form Builder가 있다는 게 가장 큰 발견. 외부 플러그인 없이 텍스트, textarea, email, number, phone, url, date, time, select, checkbox, radio 등 거의 모든 입력 유형을 지원한다.

특히 중요한 포인트:

input의 name 속성이 곧 분석의 단위가 된다 (시트 컬럼명도, 자동완성도, GA 추적도)
제출 후 동작은 Email / Webhook / Google Sheets 세 채널로 동시에 보낼 수 있다
스팸 방지 기능이 기본 내장

챕터 4-5. 응답 자동화 — Google Sheets + Make(Webhook)

오늘 챕터 중 실무에서 가장 즉각적으로 쓸 수 있는 내용. 두 가지 자동화 흐름을 배웠다.

A. Google Sheets 연동 (가장 간단한 자동화) Form Frame → Send to → Google Sheets 연결만 하면 끝. 응답이 실시간으로 시트에 쌓인다. input의 name이 컬럼명이 되므로 반드시 의미 있는 이름을 줘야 한다.

B. Make + Webhook (더 유연한 자동화)

Make에서 Custom Webhook 시나리오 생성 → URL 복사
Framer Form의 Send to에 Webhook URL 붙여넣기
두 번째 모듈로 Email/Gmail 추가 → 자동 응답 메일 발송

이 흐름이 강력한 이유는 "폼 제출 → 시트 저장 → 자동 메일 → AI 분석 → 슬랙 알림" 같은 체인을 무한히 확장할 수 있기 때문. 실제로 오늘 내가 실습한 자동화도 이 패턴의 일부였다. (클로드 자동화)

챕터 4-6. VWO로 A/B 테스트 — 가설을 숫자로 검증(실습은 못함)

VWO의 SmartCode를 Framer의 <head>에 붙여넣으면 시각적인 A/B 테스트가 가능하다. 다만 Framer라는 노코드 환경의 특성상 실험 적합도에 차이가 있다는 게 중요한 포인트.

실험 내용 적합도

버튼 텍스트 변경	매우 적합
배경색·텍스트 색 변경	적합
CTA 위치 변경	다소 불안정
Hero 이미지 교체	가능하지만 로딩 이슈
탭·슬라이더 변경	부적합

처음 A/B 테스트를 도입할 때 단순한 텍스트·색상 변경부터 시작하는 게 안정적이라는 가이드. PM 입장에서 "검증 가능한 작은 가설을 빠르게 돌려보는 습관"이 중요하다는 걸 다시 확인했다.

2. 아티클 카타 — '설득하기'만큼 '설득 당하기'가 중요한 이유

오늘 팀에서 함께 읽은 아티클은 말콤의 글이었다.

핵심 메시지

설득당하는 것은 지는 것이 아니다. 내가 틀릴 수 있다는 가능성을 열어두고 상대의 주장을 이해·수용하는 능력은, 개인의 성장 → 팀의 심리적 안전감 → 프로덕트의 성공 확률까지 끌어올리는 핵심 커뮤니케이션 역량이다.

설득당하기를 "성장 방법"으로 본다는 관점이 신선했다. 글에서는 이걸 "RAM이 아닌 CPU 업그레이드" 라고 표현했는데, 단순히 지식이 늘어나는 게 아니라 사고력 자체가 확장된다는 뜻으로 이해했다.

의견에 대한 세 가지 반응

반응 특징

자기방어	내 주장을 지키는 데 집중
(무조건적/신뢰 기반) 수용	상대 의견을 받아들임
비판적 사고	반론을 통해 내 생각을 다시 검토

스스로를 돌아보니 "무조건적 수용" 에 가까운 경우가 많았다. 상사의 지시이니 의문 없이 따르는 패턴, 정보 부족으로 습관적으로 수용하는 패턴이 그것이다. 신뢰 기반 수용도 본인의 전문성과 명확한 의사표시가 없으면 오히려 답답함을 줄 수 있다는 지적이 뼈아팠다.

비판적 사고에 대한 오해를 풀다

가장 인상 깊었던 부분. "비판적 사고는 상대 반론의 허점을 찾는 게 아니라, 그 반론을 통해 내 생각을 다시 검토하는 태도다."

지금까지는 비판적 사고 = 반박 잘하기로 생각했는데, 그 방향이 정반대였다. 비판의 화살이 상대가 아니라 나 자신을 향해야 한다는 것.

잘 설득당하는 사람의 3가지 특징

맥락적 사고 — 상대의 입장과 배경에서 의견을 이해하려 함
프로덕트 중심 사고 — 자존심·정치가 아닌 더 나은 결과를 위해 소통
자기 검증 태도 — 신약 부작용을 수천 번 검증하듯, 내 주장도 끊임없이 검증

한 문장 요약

내 주장과 나를 분리하고, 더 나은 프로덕트를 위해 서로의 논리를 유연하게 검토할 줄 아는 사람이 가장 빠르게 성장한다.

남은 질문들

상사의 의견이 곧 지시사항이 되는 조직 문화에서, 비판적 사고로 반박했을 때 인식이 안 좋아지지 않을까? 어떻게 풀어내야 할까?
나도 모르게 방어적인 태도로 듣고 있을 수 있는데, 어떻게 스스로 인식할 수 있을까?
신뢰 기반 수용과 무조건적 수용의 경계는 어디일까?

3. 실습 회고 — Claude로 설문 응답 자동 분석 + 슬랙 보고서

챕터 4-5에서 배운 자동화 흐름을 실제로 한번 돌려보고 싶어서, Claude에 시도해본 작업.

시나리오

"구글 시트의 설문 응답 중 아직 분석되지 않은 건들을 처리하고, '이슈등록필요 = 예'인 건들만 추려서 슬랙 #클로드-테스트 채널에 [긴급 이슈 보고]로 전송해줘"

진행 과정에서 부딪힌 것들

① 아무 응답 없음 — 이미 다 분석되어 있었다 시트를 열어보니 응답 3건 모두 [요약], [기분분석], [키워드], [이슈등록필요] 컬럼이 채워진 상태. "분석할 게 없습니다" 라고 솔직하게 알려주는 Claude의 첫 응답이 인상적이었다. 없는 작업을 만들어서 하지 않는 것도 자동화의 중요한 미덕.

② 도구 권한의 한계 "시트 셀에 직접 입력해줘"라는 요청은 현재 Google Drive 커넥터로는 불가능했다. (읽기/검색/생성/복사만 지원, 셀 직접 수정은 별도 Sheets API 커넥터 필요.) → 자동화를 설계할 때 도구의 권한 범위를 미리 파악해야 한다는 교훈.

③ 채널을 못 찾음 — 워크스페이스 연결 문제 요청한 #클로드-테스트 채널이 검색되지 않아서 한참 헤맸는데, 알고 보니 Slack 커넥터가 다른 워크스페이스에 연결되어 있었던 것. 워크스페이스를 다시 연결하고 나니 바로 채널을 찾았다. → 자동화는 "어떤 계정/워크스페이스에 연결되어 있는가"가 1순위 체크 항목.

④ 외부 발송 작업은 사용자 확인 후 진행 Claude가 슬랙 메시지 전송 직전에 "외부로 메시지를 발송하는 작업이라 사용자 승인이 필요합니다" 라고 명확히 짚어줬다. 자동화 도구를 만들 때도 되돌릴 수 없는 작업(send, publish, delete)에는 항상 한 번의 확인 단계가 필요하다는 원칙을 다시 확인.

최종 결과

이슈등록필요 = "예"인 3건의 응답을 정리해 #클로드-테스트 채널에 [긴급 이슈 보고]로 발송 완료. 보고서에는 다음을 포함했다:

분석 대상 응답 수, 이슈 비율, 심각도, 만족도 분포
각 건별 요약 (회원가입 단계 렉, 모바일 알림 미수신, 결제 오류 + 고객센터 지연)
단기/중기/장기 권장 조치
원본 시트 링크

4. 오늘의 한 줄 정리

데이터를 모으는 도구(Framer/GA4), 검증하는 도구(VWO), 자동화하는 도구(Make/Claude)를 다 배웠지만, 결국 그 데이터를 보고 "내가 틀렸을 수 있다"고 받아들일 줄 아는 태도가 없으면 도구는 의미가 없다.

41일차[framer,make특강]

홍철이의 무한먹방 — Mon, 4 May 2026 20:19:09 +0900

오늘 배운 것 — Framer CMS 컬렉션 관계와 Make AI 자동화

챕터 3-7 (Framer CMS) + AI Workflow 특강 / 학습 기록

들어가며

오늘은 두 가지를 배웠다.

Framer CMS에서 컬렉션끼리 관계를 맺고, 사용자 입력에 따라 리스트가 바뀌는 필터 UI를 만드는 법
Make로 AI 워크플로우를 짜서, Google Form 응답을 GPT가 분석하고 자동으로 Notion / Slack에 분배하는 자동화

언뜻 보면 따로 노는 주제 같지만, 정리하다 보니 결국 둘 다 "데이터를 어떻게 구조화하고, 어떻게 흐르게 할 것인가" 라는 같은 질문을 다른 각도에서 다루고 있었다. 하나는 "보여주는 쪽", 하나는 "처리하는 쪽".

Part 1. Framer CMS — 컬렉션 관계 & 필터 UI

1-1. 컬렉션 관계(Relation)란?

Framer CMS에서는 한 컬렉션이 다른 컬렉션을 참조(Reference) 할 수 있다.

대표적인 구조:

글(Posts) → 작성자(Authors)
프로젝트 → 카테고리
상품 → 브랜드

핵심은 데이터 중복 제거. 작성자 정보를 글마다 따로 입력하면 동일인이 여러 명처럼 흩어지는데, 작성자를 별도 컬렉션으로 분리하고 글에서 참조하면 한 곳에서만 관리하면 된다.

노션이나 에어테이블의 Relation이랑 거의 같은 개념. 정규화(normalization) 감각을 UI 도구에서 다시 만나는 느낌.

1-2. 글 → 작성자 연결하기

진행 순서:

Authors 라는 새 컬렉션 생성 (이름 / 프로필 이미지 / 소개 텍스트)
Articles 컬렉션에서 + Add Field → Relation 선택
필드명: author, 연결 대상: Authors

이렇게 하면 글 항목마다 작성자 선택 드롭다운이 생긴다. Reference / Multi-Reference 옵션이 있는데, 글 하나에 작성자 한 명이면 Reference, 여러 명이면 Multi-Reference.

1-3. 상세 페이지에 관계 콘텐츠 표시하기

연결만 해두면 데이터는 들어있지만 화면엔 안 나오니까, 상세 페이지에서 직접 끌어와야 한다.

텍스트 / 이미지 레이어 선택
+ Set Variable
Author → Profile Image / Name 식으로 드릴다운

핵심 포인트: 관계형 필드 안의 서브필드도 그대로 끌어올 수 있다. author.name, author.image 같은 식으로.

1-4. 카테고리별 필터링 UI

이제 사용자 입력에 따라 리스트가 바뀌는 동적 UI 차례.

데이터 준비

Categories 컬렉션 생성 (이름 필드만)
Articles에 category Relation 필드 추가
글마다 카테고리 연결

필터 UI 만드는 법

버튼/텍스트로 토글 컴포넌트 구성
컬렉션 리스트의 Filters 속성에 조건 걸기
Filters에 변수(Variable)를 넘기면 동적 필터링이 된다

1-5. Variant + Variable + Filter — 진짜 핵심

가장 실무에 가까운 부분.

카테고리 Pill 버튼을 Variant 두 가지로 만든다: Selected, Not Selected
버튼 클릭 시 Set Variable로 선택된 카테고리 값 변경
그 변수를 리스트의 Filter 조건에 연결

결과적으로 All / New / Old 같은 탭형 필터가 동작하면서, 같은 디자인을 Variant로 공유하니까 재사용성도 올라간다.

셋이 맞물리면서 "아 이게 노코드의 진짜 맛이구나" 싶었던 순간.

기능 설명

Relation Field	다른 컬렉션의 항목을 참조
필터 UI	버튼, 드롭다운 등으로 리스트 필터링
변수 기반 필터	사용자 입력값에 따라 동적 필터링
관계형 서브필드	author.name, category.name 등 드릴다운

Part 2. Make로 만드는 AI Workflow 자동화

2-1. 오늘 만든 것

Google Form에 들어온 의견을 GPT가 읽고, 해결이 필요한 이슈인지 일반 의견인지 판단해서, 자동으로 Notion DB나 Slack으로 보내주는 자동화 파이프라인.

코드 한 줄 안 쓰고 Make로 조립.

2-2. 전체 흐름

Google Form
    ↓
Google Sheet (자동 저장)
    ↓
Make (새 응답 감지)
    ↓
GPT (응답 내용 분석)
    ↓
Google Sheet (분석 결과 기록)
    ↓
Router (분기 처리)
    ├─→ 해결 필요 이슈  →  Notion DB
    └─→ 일반 의견        →  Slack

2-3. 단계별로 뜯어보기

① Google Form → Google Sheet

폼 응답이 시트에 자동으로 쌓이게 연결. Google Form 기본 기능. 자동화의 시작점.

② Make가 새 응답 감지

"Watch New Rows" 트리거. 새 행이 생기면 데이터를 들고 다음 모듈로.

시트가 일종의 큐(queue) 역할을 하는 셈.

③ GPT가 응답 분석

프롬프트를 넣어서 응답을 분류시킨다. 예시:

"다음 사용자 의견을 읽고, '이슈' 또는 '일반의견' 중 하나로 분류해주세요. 한 줄 요약도 함께 출력해주세요."

이 단계가 사실상 AI를 워크플로우에 끼워 넣는 핵심. 프롬프트만 바꾸면 분류 기준도, 출력 포맷도 마음대로 바뀐다.

④ 분석 결과를 Sheet에 다시 기록

"분류 결과", "요약" 컬럼을 따로 두고 채워준다.

왜 굳이 시트에 다시 적나 했는데 — 사람이 검토할 수 있는 로그 역할을 하더라. AI가 잘못 분류해도 시트만 보면 추적이 된다.

⑤ Router로 분기

Make의 Router 모듈이 조건에 따라 흐름을 갈라준다. GPT 결과(이슈 / 일반의견)를 기준으로 두 갈래.

if-else 문을 노드로 만든 느낌. 시각적이라 한눈에 들어옴.

⑥ 이슈 → Notion DB

해결이 필요한 의견은 Notion에 카드로 자동 등록. 제목 / 요약 / 원문 / 등록일 매핑.

⑦ 일반 의견 → Slack

보관보다는 공유 목적. 채널에 알림만.

모듈 역할

Google Form	입력 수집
Google Sheet	데이터 저장 + 로그
Make Trigger	새 응답 감지
GPT	자연어 분류 / 요약
Sheet Update	AI 결과 기록
Router	조건 기반 분기
Notion	이슈 트래킹
Slack	빠른 공유

종합 회고

두 주제를 같이 정리하다가 발견한 공통점 하나.

둘 다 결국 "데이터를 어떻게 연결하고 흐르게 할 것인가"의 문제다.

Framer CMS는 데이터의 구조를 다룬다 — 컬렉션끼리 관계 맺고, 사용자 입력에 따라 어떻게 보여줄지
Make 워크플로우는 데이터의 흐름을 다룬다 — 어디서 들어와서, 어디서 판단하고, 어디로 보낼지

그리고 둘 다 핵심 패턴이 비슷했다.

Framer CMS Make Workflow

트리거	사용자 클릭 (필터 버튼)	새 폼 응답
판단	Variable 값	GPT 분류 결과
결과	리스트 필터링	Notion / Slack 분배

→ "사용자가 뭔가를 하면, 그걸 변수에 담고, 그 변수에 따라 다른 결과를 보여준다"는 구조는 노코드 도구 전반에 흐르는 공통 언어 같다.

또 하나 — AI 워크플로우에서 가장 크게 와닿은 건 "AI 자체보다 어디에 끼워 넣느냐가 더 중요하다" 는 감각. GPT는 그냥 텍스트 분류기일 뿐인데, Form ↔ Sheet ↔ Notion ↔ Slack 사이의 판단 노드로 배치하니까 갑자기 시스템이 똑똑해졌다.

한 줄 요약

"데이터를 구조화하는 법(Framer)과 흐르게 하는 법(Make)을 같은 날 배웠다.

40일차[framer, 아티클 카타]

홍철이의 무한먹방 — Fri, 1 May 2026 20:30:50 +0900

오늘의 학습 기록 — Framer 반응형 & CMS + 아티클 카타

오늘은 Framer 강의 챕터 2-4부터 3-6까지 수강하며 실습했고, 아티클 카타도 함께 진행했다. 반응형 레이아웃부터 CMS 연결, 조건부 렌더링까지 한 번에 훑은 날.

Part 1. Framer 강의 정리

챕터 2-4. 반응형 이해하기

반응형 디자인이란? 사용자가 어떤 기기를 쓰든 콘텐츠와 레이아웃이 자연스럽게 적응하는 것. 데스크탑·태블릿·모바일 모두 일관된 경험을 제공하는 게 핵심.

왜 필요한가?

웹 트래픽의 절반 이상이 모바일에서 발생
Google SEO도 반응형 사이트를 우대
별도의 모바일 페이지를 안 만들어도 됨 → 관리 효율성
Mobile First 원칙: 처음부터 모바일 기준으로 설계 후 확장

반응형 핵심 도구 2가지

Fluid Layout (유동형 레이아웃) — 부모 프레임 크기에 따라 비율적으로 변하는 구조 (Fill, Fit, Fixed, Max Width)
Breakpoints (중단점) — 특정 뷰포트 너비 기준으로 레이아웃 재정의
- Desktop: 1200px 이상
- Tablet: 810~1199px
- Mobile: 390~809px

챕터 2-5. Fluid Layout 실습

Absolute의 문제점

텍스트 잘림 / 뷰포트 줄이면 요소 겹침 / 모바일에서 화면 벗어남
해결: Stack 레이아웃으로 전환 (Add Layout → Stack)

Stack 정렬 옵션

정렬 설명 사용 예시

Start	위/왼쪽 정렬	기본 리스트
Center	중앙 정렬	아이콘, 버튼 그룹
End	아래/오른쪽 정렬	푸터
Space Between	양 끝 + 균등 분산	네비게이션 바, 탭
Space Around	양 끝에도 간격	로고-메뉴 여백

Fill / Fit / Fixed / Max Width

속성 설명 언제 사용?

Fill	부모의 여유 공간 꽉 채움	반응형 기본
Fit	콘텐츠 맞게 자동 조절	텍스트, 아이콘
Fixed	고정 크기	로고, 버튼
Max Width	너무 커지지 않게 제한	Container

Section → Container → Content 구조 이미지나 콘텐츠에 여백 줄 때, 직접 padding 주지 말고 한 겹 더 감싸는 Frame을 만들어서 적용. 반응형에서 바깥 Frame만 조정해도 안의 콘텐츠가 자연스럽게 따라옴.

유용한 단축키

I : 삽입 패널
Cmd + K : Quick Action
Space + 드래그 : 캔버스 팬 / 중첩 방지 드래그
Shift + 1/2/3 : Zoom fit / selection / 100%
Esc : 부모 프레임으로 이동

챕터 2-6. Breakpoint를 활용한 레이아웃 최적화

적용 흐름

상단 Breakpoint Bar의 [+] 버튼 클릭
Tablet (810px), Phone (390px) 추가
각 Breakpoint마다 속성 Override → 파란색으로 표시되면 Override 상태

Override 가능한 것들

레이아웃 (Grid columns)
텍스트 크기, padding
요소 순서 (드래그)
visibility (특정 Breakpoint에서만 보이게)

Text Style도 반응형으로 Text Layer마다 개별 Override하지 말고, Text Style 자체에 Breakpoint 추가 가능.

H1 예시: Large 64px / Medium 48px / Small 34px

Preview: Cmd/Ctrl + P → 뷰포트 핸들 드래그하면 자동 전환 확인

챕터 3-1. CMS 개념 이해하기

CMS = Content Management System (콘텐츠 관리 시스템) 한 번 입력하면 여러 곳에서 자동으로 반영되는 구조. 반복 작업을 자동화하고 일관된 콘텐츠 운영을 가능하게 해줌.

비유: 디지털 파일 캐비닛

Collection = 폴더
Item = 폴더 안의 서류
Field = 서류 안의 항목 (제목, 날짜, 이미지 등)

Framer CMS 4대 핵심

개념 역할

Collection	콘텐츠를 유형별로 묶는 폴더
Field	각 콘텐츠의 속성
Item	실제 콘텐츠 단위
List / Detail Page	나열 vs 상세 보기

챕터 3-2. CMS 컬렉션 생성하기

컬렉션 이름 짓기

❌ Bad: data1, collection-abc
✅ Good: articles, team, products

기본 자동 필드

title (텍스트)
slug (URL용 고유 키워드, 필수)

주요 필드 타입

Plain Text / Formatted Text
Date / Link
Image / Gallery
Color / Toggle / Number / Option / File
Reference / Multi-Reference (다른 컬렉션 참조)

필수(required) 토글 + 설명(description)을 달아두면 협업 시 편하다.

챕터 3-3. CMS 연결하기

Collection List 삽입

I 키 → CMS → Collection List
Source에서 가져올 컬렉션 선택

기존 디자인에 수동 연결

기존 디자인을 Collection List 안으로 드래그
요소 선택 → + 버튼 → Set Variable → CMS 필드 선택
- 텍스트 → Content 속성
- 이미지 → Fill 속성

카드 하나만 디자인해도 나머지 항목에 자동 적용!

챕터 3-4. CMS 필터링/정렬 기능

Content 설정 메뉴

옵션 설명

Source	어떤 컬렉션
Sort	정렬 기준 필드
Filter	조건에 맞는 항목만
Limit To	최대 몇 개
Start Offset	앞에서 몇 개 건너뛰기

실전 활용

추천 콘텐츠만: featured(Toggle) = true
최신 3개만: Sort=date 내림차순, Limit=3
카테고리 필터: category = "News"
슬라이더 + 다음 3개 분리: Limit=3 / Offset=0 ↔ Limit=3 / Offset=3
커스텀 순서: order 숫자 필드 만들어서 직접 제어

챕터 3-5. CMS 상세 페이지 연결하기 (Dynamic Routing)

CMS 컬렉션의 각 Item마다 개별 페이지를 자동 생성하는 기능. → 매번 페이지 새로 만들지 않고, 하나의 상세 레이아웃만 만들면 끝!

생성 방법

Pages 탭 → + → New CMS Page
컬렉션 선택 → Detail Page
slug 기반으로 URL 자동 생성 (예: yourwebsite.com/articles/color-tips)

필드 → 요소 자동 매핑

Title → Text / Image → Image Layer / Date → Text

새 필드 연결 (예: 링크 버튼) 요소 선택 → 속성 → Set Variable → 필드 선택

텍스트 → content / 버튼 → link / 이미지 → fill

챕터 3-6. 항목별 스타일 & 조건부 렌더링

조건부 렌더링 = CMS 데이터 유무에 따라 표시 여부 제어 Visible 속성 → Set Variable → is set 체크

실전 예시

1️⃣ 링크 있을 때만 버튼 표시

버튼 → Visible → Set Variable → link 필드 → is set

2️⃣ 카테고리별 배경색 다르게

카드 컴포넌트를 Variant로 분기 (기본 / news / event)
Variant → Set Variable → category 필드 연결

3️⃣ 추천 글에만 뱃지 표시

featured Toggle 필드 추가
뱃지 요소 → Visible → Set Variable → featured

기능 설명

Variable → is set	필드가 비어있지 않을 때만 표시
Toggle 필드	Yes/No 상태 기반 분기
Variant 분기	카테고리/타입별 스타일 변경
조건부 visibility	콘텐츠에 따른 동적 구성

Part 2. 아티클 카타

아티클 정보

제목: 인스타 스토리 PM이 소셜앱의 본질을 다시 설계하다
저자: 이누 시스템

핵심 메시지

제품의 본질에 집중하면 핵심 가치는 흔들리지 않는다.

핵심 키워드: 소셜앱, 본질, 핵심가치, 성장 전략, PM의 역량

흥미로웠던 포인트

1. 인스타그램 스토리 출시 배경 사용자들이 "예쁘고 완벽한 사진"을 올려야 한다는 부담감 때문에 활동량이 감소하고, 유명인·크리에이터만 활발히 활동한다는 문제를 발견. 가볍게 일상의 순간을 공유할 수 있는 공간으로 스토리를 기획.

2. Retro 앱의 가치 소셜미디어의 본질에 집중한 '진짜 친구들과 일상을 나누는 공간' → 사용자의 '관심'과 '의도'를 존중하는, 사람을 위한 제품

3. Retro의 성장 전략 성장보다 리텐션이 먼저 → 그다음 성장과 구독(수익화)

새롭게 알게 된 점

새로운 기능이 2개월 만에 개발되어 A/B 테스트 없이 전 세계에 출시될 수도 있다
좋은 제품 자체보다 '좋은 제품을 꾸준히 만드는 시스템(팀·문화·구조)'이 더 중요하다
PM은 영화감독과 같다. 방향성을 잃지 않도록 미션(왜) → 전략(어떻게 이길지) → 로드맵(무엇을 언제까지) 문서화는 필수
제품 성장 요소 3가지
1. 대표할 무언가 — 정체성과 연결되는 브랜드 만들기
2. 함께할 수 있는 무언가 — 공동 활동을 유도하는 설계
3. 이야깃거리 — 단순히 좋은 게 아니라, 예상보다 훨씬 좋아야 사람들이 공유함

️ 카타 세션 인사이트

AB 테스트 없는 출시에 대해

비즈니스 생존을 위한 전략적 승부수
정성적 리서치(유저 인터뷰, 설문)는 분명 진행했을 것
완전히 새로운 개념이라 일부 테스트가 무의미했을 가능성
= 리스크를 팀이 온전히 감수하는 것. 단, 논리가 탄탄하면 빠른 대응 가능

주니어 PM의 아이디어 채택 기준

정해진 기준은 없음. 의사결정자가 좋다 판단하면 진행됨
핵심: 데이터 기반의 논리적 문서로 설득하기
전사 비전과 연결한 논리 구성이 효과적
주니어일수록 제약 없이 다양한 관점에서 의견 내기

레퍼런스 수집 방법

UI가 아니라 **"문제의 본질"**을 보라

"이 기능이 어떤 문제를 해결하기 위해 등장했는가"를 먼저 파악
인스타 스토리는 스냅챗 카피였지만, 같은 문제(참여도 감소)를 해결했기 때문에 유효했음
카카오톡 '펑' 기능도 같은 맥락
피그마 파일에 기능(피처) 단위로 분류해서 정리하는 것이 효율적
추천 플랫폼: WWIT, User Spoon

웹 3.0과 PM의 미래

시대 특징

웹 1.0	일방향 / 읽기만 가능
웹 2.0	양방향 / 사용자가 콘텐츠 업로드
웹 3.0	탈중앙화 / 개인이 데이터·콘텐츠 소유

핀테크·금융권에서 이미 웹3 기반 서비스 등장 중
장기적 관점에서 흐름을 인식하고 있어야 함
추천 도서: "읽고 쓰고 소유하다"

✍️ 한 문장 요약

좋은 제품은 본질에서 시작되고, 좋은 시스템에서 지속된다.

오늘의 회고

Framer 쪽은 반응형 → CMS → 동적 페이지 → 조건부 렌더링까지 자연스럽게 이어지는 흐름이라 한 번에 듣기 좋았다. 특히 Section → Container → Content 구조랑 Variable → is set 패턴은 앞으로 계속 쓸 것 같다.

아티클 카타에서는 "UI가 아니라 문제의 본질을 보라"는 말이 가장 와 닿았다. 평소에 레퍼런스를 많이 모으자..!

39일차[framer, 숙련과제 우사사례 특강]

홍철이의 무한먹방 — Thu, 30 Apr 2026 20:30:08 +0900

오늘의 공부 기록 | Framer 기초 + 우수사례 특강 회고

오늘은 Framer라는 노코드 웹 제작 도구의 기초를 쭉 훑었다. 챕터 1-1부터 1-7, 그리고 2-1, 2-3까지. 양은 많았는데 정리하면서 한 번 더 머리에 넣어보려고 한다.

️ Framer가 뭔지부터

Framer는 올인원 노코드 웹 제작 도구. 디자인부터 퍼블리싱, 배포까지 한 번에 되는 게 강점이다. Figma는 디자인까지만 되는데 Framer는 실제 사이트로 띄울 수 있다는 게 큰 차이.

비슷한 도구로 Webflow, Bubble 등이 있는데 Framer는 진입장벽이 낮은 편(Figma랑 UI가 비슷)이라서 노코드 입문용으로 좋다고 한다.

️ 인터페이스 & 프로젝트 구조

작업 화면은 크게 4개 영역으로 나뉜다.

Toolbar (상단) - 요소 삽입, 퍼블리싱
Left Sidebar - Pages, Layers, Assets
Right Sidebar - 선택한 요소 속성 (컨텍스트 기반)
Canvas - 실제 작업 공간

프로젝트는 Workspace → Project → Pages → Canvas → Breakpoints 계층 구조로 돼있다.

Breakpoint는 디바이스별 디자인 프레임. 데스크탑(1200px), 태블릿(768px), 모바일(375px)이 기본. 디자인 요소는 반드시 Breakpoint 안에 있어야 퍼블리시했을 때 보인다. 이거 까먹으면 안 됨.

외워두면 좋은 단축키

삽입 패널: I
Quick Action: Cmd/Ctrl + K
캔버스 팬: Space + 드래그
부모 프레임으로 이동: Esc

Frame 중심 사고방식

Framer의 핵심 개념. 모든 UI 요소가 사실상 Frame이다. 텍스트, 버튼, 이미지, 카드 다 프레임으로 구성됨.

그리고 실무 레이아웃은 거의 다 "Frame 안에 Frame" (Nesting) 구조. 이게 처음엔 좀 헷갈리는데 익숙해져야 할 핵심 개념이라고 한다.

Stack vs Grid

가장 많이 쓰는 레이아웃 두 가지.

Stack = 한 방향 정렬 (Figma의 Auto Layout, CSS의 Flexbox와 비슷)

내비게이션 바, 카드 리스트, 버튼 내부 정렬 등에 사용

Grid = 행+열 2차원 정렬

갤러리, 대시보드, 카드 그리드 등에 사용

상황StackGrid

한 방향 흐름	✅	❌
행+열 구성	❌	✅
Hero 영역	✅	❌
갤러리/대시보드	❌	✅

그리고 Fit Content / Fill Container 개념. Fit은 자식 크기에 맞춰 줄어들고, Fill은 부모 영역을 꽉 채운다. 반응형 UI 만들 때 핵심.

타이포그래피 & 스타일 시스템

텍스트는 T 키로 삽입. 클릭하면 자동 크기, 드래그하면 고정 크기.

Variable Font는 하나의 폰트에서 굵기, 기울기, 너비 등을 세부 조절할 수 있고 애니메이션까지 적용 가능. 이거 신기했다.

스타일 시스템이 왜 중요한가

버튼 색상 하나 바꾸려고 수십 개 레이어 일일이 수정? ❌
컬러/텍스트 스타일 한 번 정의해두면 → 한 번에 전체 반영 ✅

네이밍은 surface/0, content/100 같이 의미 기반으로 하면 협업/유지보수에 좋다고 한다. / 넣으면 자동으로 폴더 생성되는 것도 꿀팁.

레이아웃 템플릿

Nav, 푸터처럼 모든 페이지에 반복되는 요소를 한 곳에서 관리하는 기능. 페이지마다 복붙하지 말고 템플릿으로 만들자.

Variables를 활용하면 페이지별로 살짝 다른 UI도 만들 수 있다. (예: 어떤 페이지는 Nav 투명, 어떤 페이지는 Nav 고정)

우수사례 특강 회고

장바구니 전환율 기획서 우수사례 특강을 보고 느낀 게 많다. "내가 부족했던 게 뭔지" 명확해진 시간이었다.

1. 시각자료가 진짜 중요하다

다들 보는 사람이 한 번에 이해하기 쉽게 시각자료를 정말 잘 만들었다. 글로 길게 풀어 쓴 것보다 한 장의 잘 만든 이미지가 훨씬 강력하다는 걸 다시 느꼈다. 다음엔 시각화에 더 신경쓰자.

2. As-is / To-be 명확히 구분하기

와이어프레임에서 "현재는 이렇고, 이렇게 바뀝니다"가 한눈에 들어와야 하는데 내 자료는 그 구분이 약했다. 시각적으로 대비해서 보여주는 연습이 필요하다.

3. 한 페이지 요약에 도전

의사결정자가 시간 없을 때 한 장만 봐도 다 이해되도록. 긴 기획서를 핵심만 뽑아 한 페이지로 압축하는 능력. 다음 과제에선 꼭 시도해보자.

4. 레퍼런스 = 논리적 근거

"다른 곳도 이렇게 해요"가 아니라 "왜 이게 우리 문제에 적합한지" 논리적으로 쓰는 근거 자료로. 인용이 아니라 논증의 도구로 활용하기.

한 줄 정리

Framer 기초 문법을 쭉 훑었고, 특강을 통해 **"내용보다 전달이 먼저다"**를 다시 새겼다. 다음 과제 키워드는 시각화 / As-is·To-be / 한 페이지 요약 / 논리적 레퍼런스. 이 네 가지 꼭 적용해보자.

ps. 노트북 하나로 강의를 들으면서 실습을 하려니 너무 힘들다.. 거북목 심해진닭..

38일차[숙련 과제 피드백]

홍철이의 무한먹방 — Wed, 29 Apr 2026 20:09:02 +0900

0. 장바구니 전환율 숙련 과제 피드백

[논리적인 페르소나 추출 및 선정] 페르소나 b 추출 조건에서 평균 대신 중간값을 사용한 이유까지 명시했어요. 장기 체류 극단값이 평균을 왜곡한다는 판단 근거 또한 타당해요. 페르소나 선택 근거도 다른 페르소나를 선택하지 않은 이유와 함께 서술해서 탄탄한 논리를 쌓았어요. [명확하고 이해하기 쉬운 가설] 가설 부분을 데이터근거, 타겟조건, 제외조건(Or주의사항) 3가지 구조로 정리돼어 가설의 설정 근거와 타겟이 한눈에 명확하게 이해돼요.

[분석과 개선안과 연결되는 논리] 검색 유입 + 할인 노출/미노출간의 격차가 가설1의 직접 근거가 되고, 이 분석이 해결안 (랜덤쿠폰 배너)로 연결되는 흐름이 깔끔해요.

[디테일한 세그먼트 분석을 통한 핵심 변수 발견] "전체 평균만 보면 할인 효과가 없는 것처럼 보이지만 세분화하면 완전히 다른 양상"이라는 통찰이 이 과제의 핵심 차별화 포인트에요. 전체 +0.7%p를 보고 할인은 효과 없다고 결론 내리는 대신, 변수 교차 분석으로 +17.2%p 구간을 발굴해서 의미있는 인사이트를 냈어요.

[보완점] 가설3에서 '리뷰 클릭 시 전환율 하락' 을 제시했는데, 현재 데이터만으로는 리뷰를 봐서 망설인건지, 원래 망설이던 유저가 리뷰를 본 건지 알 수 없어요. 원래 망설이고 있던 건지를 확인하기 위해 체류시간도 함께 분석되었다면 더 논리적으로 탄탄한 가설이 될 수 있겠습니다.

1. 리뷰를 봐서 망설인 걸까, 망설여서 리뷰를 본 걸까

PM 숙련과제로 작성한 장바구니 전환율 개선 보고서에 피드백을 받았다. 가설 중 하나가 *"리뷰 클릭 시 전환율이 떨어진다 → 리뷰 탐색이 망설임으로 이어진다"*는 거였는데, 리뷰어의 지적은 한 줄이었다.

"현재 데이터만으로는 리뷰를 봐서 망설인 건지, 원래 망설이던 유저가 리뷰를 본 건지 알 수 없어요."

읽는 순간 알았다. 상관관계를 인과관계처럼 써놨구나.

같은 데이터, 두 가지 해석

내가 쓴 가설은 이런 흐름이었다.

리뷰 클릭 → 망설임 → 전환율 하락 (39.4% → 29.1%)

하지만 같은 숫자로 이렇게도 읽힌다.

원래 망설이던 유저 → 리뷰 클릭 → 어차피 전환율 낮음

전자는 리뷰 클릭이 원인이고, 후자는 리뷰 클릭이 결과 또는 동반 행동일 뿐이다. 해결방안 설계에 결정적인 차이다. 후자가 맞다면 "리뷰 클릭 시 쿠폰 노출"이라는 내가 짠 개입은 틀렸다.

어떻게 구분하지? — 제3의 변수로 통제하기

두 해석을 나누는 단서는 "원래 망설이던 유저인지"를 가늠할 변수다. 망설이는 유저라면 PDP에 더 오래 머물렀을 거다.

즉, 체류시간을 보면 된다. 다시 분석해보니 흥미로운 결과가 나왔다.

리뷰 클릭 그룹 평균 체류: 26.0초
리뷰 미클릭 그룹 평균 체류: 25.6초
차이: 0.4초 (p=0.58, 통계적으로 사실상 동일)

체류시간이 거의 같은데 전환율 격차가 -10%p? "원래부터 망설이던 유저였다"는 해석은 데이터로 지지되지 않았다. 체류 구간을 더 잘게 쪼개서 비교해도(16~25초, 26~33초) 격차는 일관되게 -9~-10%p로 유지됐다.

그렇다고 "원인"이라고는 말할 수 없다

여기서 한 번 더 배웠다. 대안 설명 하나를 통제했다고 해서 인과가 증명되는 건 아니다. 다른 변수가 작용하고 있을 수도 있고, 진짜 인과를 확인하려면 시점 데이터(리뷰 클릭이 먼저인지 장바구니 클릭이 먼저인지)나 실험이 필요하다.

그래서 가설 문장도 바꿨다.

수정 전: "리뷰 탐색이 망설임으로 이어지는 패턴"
수정 후: "리뷰 클릭이 이탈과 동반되는 행동 신호 (인과 방향은 미검증)"

"이어진다"와 "동반된다"는 한 단어 차이지만, 데이터가 보장할 수 있는 범위가 완전히 다르다.

오늘의 체크리스트

데이터로 가설을 쓰기 전에 스스로 물어볼 네 가지를 정리해뒀다.

'A 때문에 B'라고 쓰기 전에, 'B 때문에 A'도 가능한지 의심하기. 두 해석이 모두 가능하면 그건 상관관계지 인과관계가 아니다.
대안 해석을 무력화할 수 있는 제3의 변수를 찾아 통제해보기. 이번엔 체류시간이 그 역할을 했다.
언어를 데이터 수준에 맞추기. "원인"이라고 쓸지 "신호"라고 쓸지가 가설의 신뢰도를 결정한다.
확정할 수 없는 건 Open Questions에 남기기. 모르는 걸 모른다고 적는 것도 분석의 일부다.

데이터는 친절하지 않다. 같은 숫자가 정반대의 이야기를 동시에 한다. 그 사이를 비집고 들어가는 게 분석가의 일이라는 걸, 한 줄짜리 피드백으로 다시 배웠다.

2. AI 도구는 골라 써야 한다 — Gems와 NotebookLM

오늘 또 하나 알게 된 건, 내가 그동안 너무 좁게 AI를 써왔다는 사실이다. ChatGPT와 Claude만 번갈아 쓰면서 "AI 활용 잘하고 있다"고 생각했는데, Gemini의 Gems와 NotebookLM을 처음 접하고 나서 생각이 바뀌었다.

Gems는 Gemini 안에서 만들 수 있는 커스텀 어시스턴트다. 자주 반복하는 작업의 맥락과 지시문을 미리 세팅해두면, 매번 프롬프트를 새로 짤 필요가 없다. PM 업무로 치면 "회의록을 액션 아이템 중심으로 요약하는 Gem", "PRD 초안을 정해진 템플릿으로 잡아주는 Gem"처럼 작업별로 전용 도우미를 만들어 두는 식이다.

NotebookLM은 더 흥미로웠다. 사용자가 업로드한 자료(PDF, 문서, 영상 등) 안에서만 답을 찾는 도구라, 사용자 인터뷰 녹취록이나 리서치 보고서를 한 번에 넣고 "공통 페인 포인트가 뭐였지?", "이 표현이 나온 인터뷰가 어디였지?" 같은 질문을 던지기 좋다. 출처도 같이 보여주니 인용 신뢰도까지 잡힌다. 사용자 리서치 단계에서 정말 유용할 것 같다.

그동안 ChatGPT나 Claude 한두 개에 몰아서 썼던 게 살짝 부끄러웠다. 작업 종류에 따라 도구를 가려 쓰는 것 — 글쓰기·코드는 Claude나 ChatGPT, 반복 작업 자동화는 Gems, 자료 기반 리서치는 NotebookLM — 이게 훨씬 효율적인 접근이라는 걸 오늘 배웠다.