[내일배움캠프 PM 7기] TIL 2일차 — "사용자를 좁힐수록 서비스가 선명해진다"

내일배움캠프 사전캠프 TIL | 국비지원부트캠프 | 국비지원교육 | 내일배움카드교육 | PM취업 | 국비무료교육

 

---

오늘은 어제보다 훨씬 머리가 아팠어요.

 

어제는 PM 직무에 대한 정의를 잡는 날이었다면, 오늘은 제가 만들 서비스의 뼈대를 직접 세우는 날이었습니다.

타겟 유저를 정의하고, 페르소나를 만들고, 만다라트로 서비스를 확장하는 작업을 처음으로 해봤는데

생각보다 훨씬 어려웠지만 재미있었습니다.

---

✔️ 오늘의 SQL 학습

스프린트 챌린지와 병행해서 SQL 강의도 챕터 4까지 수강했습니다.

평소 엑셀을 잘 다루는 편이라고 생각해서 크게 어렵게 생각하지 않았는데

생각보다 좀 복잡했고, 아무래도 엑셀이 더 편하다보니..

 

엑셀로 하면 더 빨리 할 수 있는거 아니야?? 이런 생각이 계속 들더라구요

물론 이것도 더 편해지면 엑셀보다 빨라지겠지만요

 

1주차 : SQL 기본 구조 (SELECT / FROM)

SQL은 데이터베이스에게 요청을 보내는 언어로, 이 요청을 Query(쿼리)라고 부릅니다.

SELECT 컬럼1, 컬럼2
FROM 테이블명
WHERE 조건

• SELECT *: 모든 컬럼 조회
• AS 또는 큰따옴표: 컬럼에 별명 지정
• WHERE: 조건 필터링 (=, <>, >, >=, <, <=)
• BETWEEN, IN, LIKE: 범위·목록·패턴 필터링
• AND, OR: 여러 조건 동시 적용

*에러가 떴을 때는 에러 코드보다 왜 에러가 났는가를 먼저 읽는 습관이 중요!

---

2주차 : 집계 함수 + GROUP BY + ORDER BY

집계 함수: 엑셀의 SUM, AVERAGE, COUNT, MIN, MAX와 동일하게 사용 가능

SELECT COUNT(order_id), AVG(price), SUM(quantity)
FROM food_orders

 

GROUP BY: 카테고리별로 나눠서 연산할 때 사용

 

SELECT cuisine_type, AVG(price)
FROM food_orders
GROUP BY cuisine_type

 

ORDER BY: 결과를 오름차순/내림차순 정렬

SELECT *
FROM food_orders
ORDER BY price DESC  -- 내림차순

 

완성된 SQL 기본 구조 (순서 중요!)

 

SELECT 컬럼
FROM 테이블
WHERE 조건
GROUP BY 그룹 기준
ORDER BY 정렬 기준

---

3주차 : 문자 가공 + 조건문 (IF / CASE)

문자	가공	함수
REPLACE	특정 문자 교체	REPLACE(addr, '서울특별시', '서울')
SUBSTRING	문자 일부 추출	SUBSTRING(addr, 1, 2)
CONCAT	문자 결합	CONCAT(city, ' ', district)

조건문: 조건에 따라 다른 값을 반환할 때

-- IF 문
SELECT IF(조건, 참일 때 값, 거짓일 때 값)

-- CASE 문 (여러 조건)
SELECT CASE
    WHEN 조건1 THEN 값1
    WHEN 조건2 THEN 값2
    ELSE 기본값
END

 

*(꿀팁) Data Type 오류:

- 숫자처럼 생겼지만 문자로 저장된 컬럼은 연산 전에 타입 변환이 필요

- DBeaver에서 컬럼명 옆 ABC(문자) / 123(숫자) 표시로 확인할 수 있음

 

4주차 : Subquery + JOIN

 

가장 어려웠던 파트..

 

Subquery: 여러 번의 연산을 한 번의 SQL문으로 수행할 때 사용하고, 쿼리 안에 쿼리를 넣는 구조

SELECT *
FROM (
    SELECT cuisine_type, AVG(price) AS avg_price
    FROM food_orders
    GROUP BY cuisine_type
) AS subquery
WHERE avg_price >= 10000

 

복잡한 연산을 단계별로 쪼개서 생각하고, 안쪽 쿼리부터 작성하는 것이 핵심!

 

JOIN: 필요한 데이터가 서로 다른 테이블에 있을 때 연결해서 조회

 

SELECT a.order_id, a.price, b.pay_type, b.vat
FROM food_orders AS a
LEFT JOIN payments AS b ON a.order_id = b.order_id

• LEFT JOIN: 왼쪽 테이블 기준, 오른쪽에 데이터 없어도 포함
• INNER JOIN: 양쪽 테이블에 모두 있는 데이터만 포함

JOIN은 처음엔 개념이 잘 안 잡혔는데, "엑셀에서 VLOOKUP으로 두 시트를 합치는 것"이라고 생각하니 바로 이해되더라구요

 

---

✔️ 스프린트 챌린지 2일차 : 타겟 사용자 & 페르소나 & 만다라트

먼저, 타겟 사용자를 정의하기 전에 생각해본 것들

타겟 사용자를 왜 좁혀야 할까?

 

마케팅에서 제품 PMF와 페르소나를 뾰족하게 잡는 것과 비슷한 맥락.

모든 사람을 타겟으로 하면 문제가 분산되고, 결국 어떤 기능을 먼저 만들어야 하는지 방향이 잡히지 않아요.

특정 사용자로 좁히면 그 사람이 겪는 문제를 깊이 이해할 수 있고, 기능·화면·메시지 모두를 그 사람 중심으로 설계할 수 있습니다.

 

PM이 타겟 사용자를 설정하는 건 결국

"우리가 가장 잘 해결할 수 있는 문제를 가진 사람"을 먼저 찾는 작업이라는 생각이 들더라구요

 

---

1단계: 타겟 사용자 정의

• 도메인: 이커머스 / 커머스 플랫폼 (패션·뷰티)
• 타겟 사용자
  • 할인 행사 시즌에 적극적으로 쇼핑하지만, 결제 직전 단계에서 가격 구조의 복잡함으로 인해 이탈하는 20~30대 여성

• 선택한 이유
  • 세일 기간에 장바구니를 채우는 행동은 구매 의지가 분명히 존재하는 상태
  • 문제 정의: 최종 결제로 이어지지 않는 이유는 결제 직전 단계에서 마주하는 가격 구조의 불투명함 때문일 것이다
  • 쿠폰 적용 조건, 옵션별 가격 차이, 배송비 조건 등이 결제 단계에서 한꺼번에 드러나면서 사용자는 처음 기대했던 금액과 실제 결제 금액 사이의 괴리를 경험하고 이탈
    → 이 문제는 구매 의지가 높은 사용자일수록 더 큰 실망감과 불신으로 이어지며, 반복될 경우 플랫폼 신뢰도 저하 및 이탈로 연결될 수 있음
• 근거
  앱스토어 리뷰와 제 경험(실제 경험+현업 경험)을 기반으로 아래 인사이트를 도출했습니다.
  • 에이블리 리뷰: "디지털·문구 카테고리에서 대표가격을 낮게 설정해두고, 실제 옵션 선택 시 가격이 두 배 이상 뛰는 사례가 많다"
  • 크림 리뷰: "첫회원 5,000원 쿠폰을 기대하고 가입했으나 30만 원 이상 결제 조건으로 사실상 사용 불가"
  • 본인 경험: 세일 기간 장바구니에 다수 상품을 담은 후, 총결제금액 확인 시점에 예상보다 높은 금액으로 인해 이탈한 경험
    실결제 금액과 기대한 금액과의 괴리가 생기면 이탈하는건 당연한 소비자 심리이기에..

에이블리 앱 스토어 리뷰

크림 앱스토어 리뷰

 

---

2단계: 페르소나 설정

페르소나는 타겟 사용자를 "한 명의 구체적인 인물"로 표현하는 도구입니다.

 

타겟이 "20~30대 여성"이라면, 페르소나는 "26세 중소기업 마케터 박서연, 블프 때 찜해둔 옷을 결제하려다 쿠폰 조건이 복잡해서 이탈했다"처럼 구체적이어야 해요. (더현대 서울이 처음 생길 때 페르소나를 구체화한 걸로 유명했죠 !!)

 

페르소나가 있어야 기능 하나를 설계할 때도 "이 사람이라면 어떻게 반응할까"를 상상하며 판단할 수 있다. 팀 논의가 추상적으로 흘러갈 때 페르소나를 꺼내들면 다시 사용자 중심으로 대화를 되돌릴 수 있다는 점도 인상적이었습니다.

 

총 3명의 페르소나를 설정했습니다.

 

	박서연	최지은	이다현
나이	26세	31세	23세
직업	중소기업 마케터 2년차	대기업 기획팀 4년차	대학교 4학년
상황	무신사/에이블리 세일 시즌 결제 시도	올리브영 스킨케어 세트 구매 시도	지그재그/에이블리에서 계절 옷 탐색
Pain Point	쿠폰 조건 복잡, 예상 금액과 실제 금액 괴리	기획전 할인가 vs 실결제 금액 불일치	옵션 선택 후 가격 상승, 예산 초과 예측 불가
니즈	쿠폰 최적 조합이 자동 적용된 최종 금액 미리 보기	배송비 무료 조건 등 남은 조건 명확한 안내	상품 탐색 단계부터 배송비 포함 총금액 표시

 

세 명 모두 결제 직전 이탈이라는 같은 문제를 겪지만, 이탈 원인과 상황이 조금씩 달라서 서비스 기능 방향을 잡을 때 다양한 관점을 제공해줄 것 같습니다.

 

---

3단계: 만다라트 작성

만다라트는 하나의 문제를 중심으로 8가지 영역을 확장하며 서비스의 뼈대를 잡는 도구입니다.

중심 테마를 커머스 (결제 직전 이탈 문제) 로 설정하고, 8개 영역을 채웠어요.

 

만다라트를 작성하면서 가장 어려웠던 건 수익구조 영역이었습니다.

PM은 사용자 문제 해결뿐 아니라 비즈니스 지속 가능성까지 고려해야 한다는 걸 다시 한번 체감했어요.

 

 

---

 

오늘의 회고

 

오늘 타겟 사용자를 정의하면서 흥미로웠던 점이 있었어요.

 

처음엔 단순 '검색이 불편하다'는 방향으로 가려다가,

여러 번 질문을 던지면서 결국 '결제 직전, 가격 구조의 불투명함으로 인한 이탈' 이라는 더 구체적인 문제로 좁혀졌습니다.

 

마케터로 일할 때도 항상 "왜 전환이 안 되지?"를 고민했는데, 오늘 PM 관점에서 같은 질문을 다시 들여다본 느낌이었어요.

당시엔 광고 메시지나 타겟팅을 바꾸는 방식으로 접근했다면, 이제는 서비스 자체의 구조와 UX를 바꾸는 방향으로 사고하는 첫 시도를 하게 된 것 같습니다.

 

사실 제가 선택한 문제는 이미 너무도 general/broad 하고 이미 너무도 많이 정의되었으나..

 

좁힐수록 오히려 해결책이 선명해진다는 것, 이게 PM이 문제를 정의하는 방식이라는 것을 배우기엔 충분했던 것 같아요.

내일은 오늘 잡은 타겟과 페르소나를 바탕으로 실제 화면 흐름(유저 플로우)을 그려볼 예정입니다.