bbborang 님의 블로그

7/15 데이터드리븐 VOD강의 (스크롤 압박 주의)

bbborang — Tue, 14 Jul 2026 20:17:44 +0900

요구사항 분석 및 요구사항 정의서(PRD)
Product Requirements Document = 제품 요구사항 정의서

요구사항 분석은 프로젝트나 제품 개발의 핵심 과정으로, 개발팀이 어떤 제품을 만들 것인지를 명확히 정의하는 단계

요구사항을 구체적으로 파악하고, 이를 문서화하여 각 팀(개발, 디자인, QA 등)이 동일한 목표를 가지고 작업할 수 있도록 공유
PRD는 요구사항을 체계적으로 정리한 문서로, 프로덕트 개발 과정에서의 지침서 역할을 함
이 문서가 잘 작성되면 개발 팀은 물론, 이해관계자들 간의 커뮤니케이션을 원활히 하고 프로젝트 진행이 명확해짐

요구사항 정의서(PRD) 작성 방법

제품이나 서비스에서 제공해야 할 구체적인 기능들을 나열함

기능 이름 : 기능의 이름
기능 설명 : 해당 기능이 어떤 역할을 수행하는지 설명
우선순위 : 해당 기능의 중요도 (예: 필수, 권장, 나중에 추가 가능)
구현 기준 : 기능이 어떻게 작동해야 하는지에 대한 세부적인 설명

정보 구조도(IA, Information Architecture)

"개발 기능" 정의 : 시스템, 웹사이트 또는 애플리케이션의 구조와 기능을 명확하게 정의한 문서

이 문서는 개발자, 디자이너, 그리고 다른 팀원들이 시스템이 어떻게 동작해야 하는지에 대한 공통된 이해를 가질 수 있도록 도와줍니다. 개발기능 정의서의 목적은 프로젝트의 요구 사항을 구체적으로 정의하고,

각 기능이 어떻게 구현되어야 하는지에 대한 구체적인 방향을 제시하는 것

정보 구조도 작성 방법

기능 목록 작성 : 시스템 내에서 제공할 모든 기능을 목록화
카테고리 및 메뉴 구조 설계
정보 구조도를 그리기 위해서는 기능을 논리적으로 분류하고 계층화하는 작업이 필요

카테고리화 : 각 기능을 관련 있는 그룹으로 묶습니다.
계층 구조 : 각 카테고리 내에서 세부 항목들을 어떻게 배치할지를 정합니다.

가장 중요한 정보는 상위 카테고리에 배치하고, 덜 중요한 정보는 하위 카테고리로 배치합니다.

서비스 정책서

서비스 개발이나 개선 과정에서 기능에 대한 명확한 정의와 구현 기준을 설정하여,

관련 팀들이 일관되게 작업할 수 있도록 하는 문서

작성방법 : 서비스 정책서의 목적 정의 → 정책 범위 설정 → 정책의 주요 항목 및 세부사항 작성 → 정책 문서화 및 공유 → 정기적인 검토 및 업데이트

에러케이스

에러 케이스는 서비스나 시스템에서 오류가 발생한 경우에 대해 어떤 식으로 처리할지, 어떤 메시지를 사용자에게 전달할지 등을 미리 정의해 놓은 문서입니다.

작성방법 : 에러 케이스 정의 → 에러 발생 조건 명시 → 에러 메시지 작성

Q) 상세 기획은 무엇일까요?

-> 상세 기획은 프로젝트의 구체적이고 실행 가능한 계획으로, 프로젝트의 목표, 요구 사항, 일정, 기능 설계(명세) 등을 정의하는 과정

Q) 상세 기획시 작성하는 유저 플로우, 기능 명세서란 무엇일까요?

유저 플로우 & 기능 명세서

유저 플로우 : 사용자가 서비스를 이용할 때의 전체적인 경로와 단계별 상호작용을 명확하게 정의
기능명세서 : 각 기능을 상세히 설명하는 문서
(기능의 목적, 동작 방식, UI 요소, 제약 사항 등을 구체적으로 작성하여 협업자가 정확히 이해하고 구현할 수 있도록 작성)

상세 기능 명세서 :

각 기능이 어떻게 동작해야 하는지, 입력 값, 출력 값, 상호작용을 구체적으로 정의

기능 이름 / 기능 설명 / 입력값 / 출력 값

유저 플로우 :

목표 정의 : 목표를 달성하기 위한 필수 단계를 정의
시작점 설정 : 유저 플로우의 시작점을 사용자가 서비스에 들어오는 지점으로 설정
단계 나열 : 사용자가 목표를 달성하기 위한 단계별 흐름을 나열
결정 노드와 분기점 추가 : 사용자가 선택할 수 있는 여러 경로가 있는 경우, 분기점을 추가
시각적으로 표현 : 흐름을 도식화

프론트 기획 실습(회원가입)

1. 로그인 및 회원 가입

아이디

비밀번호

자동 로그인

로그인 버튼

아이디 찾기

비밀번호 찾기

회원가입

SNS 로그인

2. 회원 가입 상세

아이디

비밀번호

보기 버튼

이름

국가코드 선택

휴대폰 번호

인증 버튼

이메일 주소

유저 동의 항목 / 내용보기

가입하기 버튼

3. 회원 가입 시 에러 메세지 노출

프론트 기획 실습(메인홈 팝업)

1. 목적

신규 사용자 및 기존 사용자에게 주요 이벤트, 프로모션, 추천 콘텐츠를 효과적으로 전달

2. 팝업 노출 조건

조건 설명

신규 사용자	최초 방문 시 노출 (앱 다운로드 후 처음으로 앱을 켠 사용자)
기존 사용자	최초 방문이 아닌 유저에게 노출
특정 이벤트 진행 시	프로모션, 신규 콘텐츠 업데이트, 미션 이벤트 진행 시 노출
재방문 사용자	7일 이상 미접속 후 방문 시 노출

3. 팝업 유형 및 목적

신규 사용자 : 회원가입 전환율 증가 유도
기존 사용자 : 콘텐츠 시청률 증대
특정 이벤트 진행 시 : 이벤트 참여 유도
재방문 사용자 : 혜택 제공하여 지속적인 재방문 유도

<상세 기능 명세>

1. 신규 사용자 가입 유도 팝업

내용 :
지금 가입하고 인기 숏폼 드라마 무료 감상!
다양한 장르의 드라마를 지금 바로 만나보세요.
[가입하고 무료 감상]

2. 신규 콘텐츠 업데이트 팝업

내용 : 신규 드라마 공개!
지금 가장 인기 있는 숏폼 드라마를 확인해보세요!
[지금 감상하기]

3. 추천 콘텐츠 팝업

내용 : 당신이 좋아할 만한 드라마!
'OOO'을 좋아한다면, 'XXX'도 좋아할 거예요.
[지금 보러가기]

백오피스 기획 실습(회원 관리)

1. 개요

목적 : 회원 데이터를 효율적으로 관리하고, 운영팀이 사용자 정보를 조회, 제어할 수 있는 백오피스 구축
핵심 기능 : 회원 검색, 계정 설정
대상 사용자 : 운영팀(관리자, CS팀 등)

2. 주요 기능 기획

회원 목록 조회 & 검색 (기본 화면)

회원 목록 리스트 → 가입된 회원 전체 조회 가능
검색 기능 → 이름, 이메일 등으로 검색 가능
회원 관리 기능 → 상태(활성/정지) 변경 및 비밀번호 초기화 가능

백오피스 기획 실습(메인홈 팝업 관리)

1. 개요

목적 : 메인홈에 노출되는 팝업 배너를 관리할 수 있는 백오피스 구축
주요 기능 : 팝업 배너 생성, 수정, 삭제, 노출 조건 설정, 클릭 수 및 성과 분석
대상 사용자 : 운영팀(마케팅, 콘텐츠 관리팀)

2. 주요 기능

1. 팝업 배너 목록 조회 & 검색

등록된 팝업 배너 목록 조회 (현재 활성화된 팝업 확인)
검색 및 필터 기능 (노출 상태, 배너 유형, 노출 기간별 검색 가능)

2. 팝업 배너 등록 & 수정 기능

배너 제목 & 설명 입력 (운영팀 참고용)
배너 이미지 업로드 (JPG, PNG, GIF 지원)
노출 기간 설정 (시작일 ~ 종료일)
배너 클릭 시 이동할 URL 설정 (내부 페이지 or 외부 링크)
노출 조건 설정 (타겟 사용자 선택, 특정 이벤트 시 노출 등)

3. 팝업 배너 노출 조건 설정

노출 조건	설명
모든 사용자	모든 방문자에게 노출
비회원 전용	로그인하지 않은 사용자에게만 표시
첫 방문자 전용	신규 사용자에게만 1회 노출
모바일 전용	모바일 웹/앱에서만 표시

Tip
1. 어드민의 고객은 운영자! → 니즈 파악 잘하기
2. 언제든 요구사항이 변경될 수 있는 점을 감안하기 → 유연하게 화면 기획하기

MVP 버전 이후 기획

1. MVP 출시 이후 데이터 분석 개요

MVP에서는 홈(Home)과 마이(My) 화면만 제공
출시 후 데이터 분석을 통해 사용자 행동 및 개선점을 도출
MVP 이후 버전에서 기능 확장 및 UX 개선을 목표로 기획 진행

2. MVP 데이터 분석 및 주요 인사이트

DAU (일일 활성 사용자 수)	10만
사용자 세션 지속 시간	평균 12분
홈 → 콘텐츠 클릭률	30%
이탈률	40%

핵심 개선 포인트

홈 화면에서 콘텐츠 클릭률이 낮음
→ 콘텐츠 추가 소싱 필요 (+ 콘텐츠 탐색 강화)
→ 추천 시스템 도입하여 유저의 취향에 맞는 콘텐츠 제공
세션 지속 시간이 짧으며 유료 회차 결제 단계에서 이탈률이 높음
→ 이벤트 코인 지급 수단 제공(오퍼월 등)

3. MVP 이후 추가될 화면 & 기능 기획

1) 콘텐츠 탐색 강화 (추천 & 검색 기능 추가)

개인화 추천: 사용자 시청 이력 기반 추천 콘텐츠 제공
검색 기능 도입: 특정 키워드로 숏폼 콘텐츠 검색 가능

2) 선물함 기능 기획

이벤트 리워드(코인, 쿠폰) 수령 및 사용 내역 확인 기능 제공
오퍼월 기능 연동하여 이벤트 리워드 지급

< 상세 기능 명세 >

추천탭 / 검색 / 좋아요 / 즐겨찾기 / 회차 리스트 / 공유하기 / 전체 보러가기

보유코인 / 잔액 / 출석체크 / 오늘의 혜택

데이터 보는 습관

데이터를 볼 때
✔️ 정확한 질문 파악
✔️ 기준 설정 및 관련 데이터를 수집 및 분석 (비교, 패턴 분석, 사용자 피드백 활용)
✔️ 객관적이고 논리적인 해결 방안 제시 (데이터 시각화, 숫자로 설명)

케이스 1 : API 속도 최적화 관련

최근 로그인 API 응답 시간이 길다는 피드백이 있는데, 얼마나 느린 건가요? 개선이 필요할까요?

1. 기준 : 최근 30일간 로그인 API의 평균 응답 시간

2. 데이터 확인 :

평균 응답 시간: 2.1초 (목표는 1초 이하)
피크 시간(오후 8~10시): 3.5초까지 증가
사용자 불만 접수 건수: 지난달 대비 20% 증가
트래픽이 몰리는 시간대에 성능 저하가 발생

3. 결론 도출 : API 요청 수 대비 서버 응답 속도 분포를 보면 캐시 사용이 부족한 것으로 보이는데, 이를 개선하면 응답 시간을 단축 가능 → 우선 캐시 적용(A/B 테스트) 후 응답 시간을 체크하는 방향으로 진행

케이스 2 : CTA 버튼 클릭률 개선 요청

CTA(구매 버튼) 클릭률이 낮아요. 색상을 바꾸면 효과가 있을까요?

1. 기준 : 최근 2주간 CTA 버튼의 클릭률

2. 데이터 확인 :

데스크톱 클릭률: 3.2%
모바일 클릭률: 1.5% (업계 평균 2.5% 대비 낮음)
A/B 테스트 결과: 기존 버튼 대비 초록색 버튼 클릭률 15% 증가

3. 결론 도출 : 모바일 사용자의 클릭률이 특히 낮은데, CTA 버튼 크기, 색상 대비를 조정하면 개선 가능해보임
아래와 같이 A/B 테스트를 진행한 후 결과를 다시 분석

기존 빨간색에서 초록색으로 변경
버튼 크기를 15% 확대

케이스 3 : 구매 전환율 문제

최근 장바구니 담기 수는 증가했는데, 최종 결제율이 떨어졌어요. 이유가 뭘까요?

1. 기준 : 지난 30일간 데이터

2. 데이터 확인 :

장바구니 담기율: 12% → 18% (6% 증가)
최종 결제율: 7% → 5% (2% 감소)
결제 단계 이탈률: 결제 페이지 로딩 시간 4초 이상 (목표는 2초 이하)
사용자 피드백: 결제 단계에서 쿠폰 코드 입력 과정이 복잡하다는 의견 증가쿠폰 코드 입력 과정이 번거로워 사용자가 이탈
결제 페이지 로딩 속도가 느려져서 이탈한 사용자 증가

3. 결론 도출 :

결제 페이지 성능 최적화 → 응답 속도 2초 이하로 단축
쿠폰 코드 자동 적용 기능 추가

케이스 4 : 사용자 불만 증가

최근 특정 기능(결제, 로그인, 상품 검색)에 대한 고객 불만이 증가했습니다. 주된 원인이 무엇인지 파악할 수 있을까요?

1. 기준 : 최근 2주간의 고객 문의 데이터

2. 데이터 확인 :

고객 불만 접수 증가율: 35% 증가
주요 불만 항목:
- 결제 실패 (40%) → 신용카드 결제 오류
- 상품 검색 문제 (30%) → 특정 키워드 검색 결과 누락
- 로그인 실패 (20%) → OTP 인증 딜레이
결제 오류의 경우, 특정 카드사에서 승인 실패율이 높아졌음 (카드사 문제 or API 응답 문제 가능성)
검색 기능은 새로운 필터 적용 이후 검색 결과 정확도가 낮아졌을 가능성
로그인 실패는 트래픽이 증가한 특정 시간대(밤 9~11시)에 OTP 요청이 몰리는 현상이 원인일 가능성이 큼

3. 결론 도출 :

결제 : 특정 카드사의 승인 오류 로그 분석 및 대응 방안 논의
검색 : 필터링 알고리즘 개선 테스트 진행
로그인 : OTP 요청 분산 처리 방안 검토 및 UX 개선

+) API 응답 속도는 앱이나 프로그램이 서버에 데이터(예: 날씨 정보, 결제 승인 등)를 요청하고,

서버가 그 요청을 처리한 뒤 다시 결과를 돌려주기까지 걸리는 총 시간(일반적으로 0.1초~1초 이내)을 뜻함.

케이스 5 : A/B 테스트 결과

새로운 로그인 페이지 A/B 테스트 결과가 나왔나요? 어떤 안이 더 좋은가요?

1. 기준 : 지난 2주간 진행된 A/B테스트

2. 데이터 확인 :

기존 로그인 페이지(A안): 전환율 18%
새로운 디자인 로그인 페이지(B안): 전환율 25% (7% 증가)
모바일 사용자 반응: B안에서 로그인이 12% 더 빠름
사용자 피드백: B안에서 로그인 버튼 위치가 더 직관적이라는 의견 다수

3. 결론 도출 : B안이 전환율이 더 높고, 사용자 반응도 좋으므로 새로운 로그인 페이지 B안으로 진행

<여기서 스스로>

- 각 케이스에서 어떤 데이터를 확인해야 하는지 직접 정리해보기!!!!

- 데이터 기반으로 어떤 결론을 도출할 수 있는지 고민해보기!!!!

목적 생각해보기

목적이 없으면 어떻게 될까요?

-> 문서는 불필요한 내용이 많아지고, 보는 사람에게 혼란을 줌
데이터 분석도 단순한 숫자 나열이 되고, 실제로 어떤 액션을 해야 할지 모호해짐

PM은 문서 작성 및 데이터 분석 시 어떤것부터 시작해야 할까요?
-> 항상 “이걸 왜 하는가?”부터 시작

1. 목적이 중요한 이유

효율성

문서를 읽는 사람(개발자, 디자이너, 마케팅 팀 등)이 쉽게 이해할 수 있도록 정리할 수 있음
데이터 분석에서도 불필요한 정보를 배제하고, 의사결정에 필요한 핵심 데이터만 제공할 수 있음

명확한 방향성

문서나 데이터 분석이 어디를 향해야 하는지 방향성이 뚜렷해짐
(목적 없이 문서를 작성하면 내용이 산만해지고, 핵심을 전달하기 어려움)
데이터 분석도 마찬가지로, 분석의 목적이 분명해야 어떤 데이터를 수집하고 어떤 방법을 사용할지 결정할 수 있음

결과물의 질 향상

문서나 분석 결과가 더 설득력 있고 효과적인 형태로 정리됨
문서는 논리적인 구조를 갖출 수 있고, 데이터 분석은 실질적인 비즈니스 가치를 제공할 수 있도록 진행됨

ex)

사용자 행동 분석 → UX 개선

"회원가입 페이지에서 2단계에서 이탈률이 50% 발생합니다. 이를 줄이기 위해 입력 필드를 줄이고, 가이드 메시지를 추가하는 것이 필요합니다."

→ 이탈률 데이터를 그냥 보는 게 아니라, 개선 방향까지 도출해야 함

A/B 테스트 → 기능 최적화

"A 디자인보다 B 디자인의 전환율이 15% 높습니다. 따라서 B 디자인을 정식 출시하는 것이 적절합니다."

→ 데이터 비교 후, 어떤 결정을 내려야 하는지 제시해야 함

비즈니스 성과 분석 → 매출 향상 전략

"VIP 고객의 재구매율은 30%이지만, 일반 고객은 10%에 불과합니다. VIP 고객 대상 리텐션 마케팅을 강화하면 매출이 증가할 가능성이 큽니다."

→ 단순히 매출 데이터를 보는 것이 아니라, 비즈니스 전략과 연결해야 함

2. PM이 목적에 맞게 문서와 데이터를 활용하는 팁

WHY(왜?) 정하기

문서를 작성하기 전에 “이걸 왜 하는가?"부터 생각하기
이 문서를 읽고 상대방이 어떤 행동을 하길 원하는가?
이 데이터를 보고 우리가 어떤 결정을 내려야 하는가?

실행 가능한 결론을 도출하기

데이터 분석 후에는 구체적인 행동 계획 도출

단순한 데이터 나열 X
"그래서 뭘 해야 하지?"에 대한 답을 포함

간결하게 핵심만 정리하기

PM 문서는 읽기 쉬워야 한다!!!

필요 없는 내용 줄이기
표나 그래프 활용해 직관적으로 정리
핵심 내용을 3줄 요약하는 연습 해보기

예시)

지라 작성 → 버그 픽스

✔ 제목은 짧고 명확하게 작성하기

❌ 검색 기능에서 특정 키워드를 입력하면 결과가 잘못 나오는 버그가 발생하며, 이를 해결해야 함
✅ [Bug] 검색 기능 키워드 입력 시 잘못된 결과 노출

-> 구구절절 문장형으로 작성하지 말라는 뜻

✔ 설명은 간결하지만 필수 정보는 포함

문제: 모바일 환경에서 검색어 입력 시 자동완성 기능이 동작하지 않음
기대 결과: 자동완성 기능이 정상 작동해야 함
재현 방법:
1. 모바일 웹에서 검색창 클릭
2. 카메라 입력
3. 자동완성이 동작하지 않음

✔ 완료 기준을 명확히 설정

❌ 검색 기능이 잘 작동하여야 함
✅ 검색어 입력 시 1초 내 자동완성 추천 목록 표시되어야 함

✔ 개발자와의 커뮤니케이션 고려

설명이 부족하면 개발자가 다시 물어봐야 함 → 필요한 정보를 빠짐없이 포함
우선순위 적절히 활용 (High / Medium / Low)

<스스로 해봐야함>

JIRA & Confluence 업무툴 사용 방법 학습하기
JIRA & Confluence 실제 화면을 보며 익히기

JIRA

JIRA : 소프트웨어 개발 및 프로젝트 관리를 위한 이슈 트래킹 및 애자일 프로젝트 관리 툴

< JIRA의 주요 기능 >

이슈 트래킹
- 개발 과정에서 발생하는 버그, 기능 요청, 작업(Task) 등을 기록하고 추적할 수 있음
애자일 보드
- Scrum 및 Kanban 방식으로 프로젝트를 관리할 수 있는 보드 제공
백로그 관리
- 제품 백로그에 할 일을 등록하고 우선순위를 조정할 수 있음
워크플로우 설정
- 작업 상태(예: To Do → In Progress → Done)를 커스텀하여 프로세스에 맞게 설정 가능.
보고서 & 대시보드
- 프로젝트 진행 상황을 시각적으로 확인할 수 있는 보고서 및 통계 제공

Confluence

Confluence❗

팀과 조직이 문서를 공유하고 협업할 수 있도록 돕는 기업용 위키(Wiki) & 협업 도구
JIRA와 연동하여 프로젝트 문서, 회의록, 제품 로드맵, 내부 문서 등을 체계적으로 관리하는 데 활용

< Confluence의 주요 기능 >

1. 문서 및 위키 기능

문서 작성 및 편집 가능 (Notion과 유사)
위키(Wiki) 기능을 제공하여 팀원 간 지식을 체계적으로 공유
협업을 위한 실시간 편집 및 댓글 기능 지원

2. JIRA와의 연동

JIRA의 이슈 및 백로그를 Confluence 문서에 직접 삽입 가능
개발 문서와 이슈를 연결하여 프로젝트 진행 상황을 쉽게 파악할 수 있음

3. 실시간 협업 및 댓글 기능

Google Docs처럼 여러 사람이 동시에 문서를 편집 가능
문서 내에서 팀원 태그(@멘션) 가능
문서에 댓글 추가 기능으로 피드백을 주고받을 수 있음

4. 강력한 검색 기능

키워드 검색을 통해 필요한 문서를 빠르게 찾을 수 있음
최근 업데이트된 문서, 태그 기능을 활용해 문서를 쉽게 정리 가능

	Confluence	JIRA
목적	문서 관리 및 협업	프로젝트 및 이슈(작업) 관리
주요 기능	문서 작성, 회의록, 보고서 작성 등	이슈 및 태스크 관리, 버그 트래킹, 스프린트 관리
연동 가능성	JIRA와 연동하여 이슈 및 프로젝트 상태 시각화 가능	Confluence와 연동하여 문서, 요구사항, 회의록 참조 가능
주요 활용 사례	제품 문서화, 사내 위키, 프로젝트 계획, 회의록 정리	Agile 프로젝트 관리, 버그 관리, 작업 추적

< JIRA와 Confluence 차이점 >

	Confluence	JIRA
문서 작성 및 관리	O	X
이슈 및 태스크 관리	X	O
워크플로우 및 승인 프로세스	X	O
Agile 보드 (칸반, 스크럼)	X	O
지식 공유 및 협업	O	X
버그 트래킹	X	O
프로젝트 진행 추적	X	O
JIRA ↔ Confluence 연동 가능 여부	O	O

< JIRA와 Confluence 작성 팁 >

1. JIRA

- 이슈 제목을 간결하고 명확하게 작성

예시)

[로그인] 이메일 입력 시 'Invalid Email' 오류 발생 (Chrome)

제목만 보고도 어떤 작업인지 파악할 수 있도록 구체적으로 작성합니다.
특정 기능, 페이지, 브라우저, 환경 등을 포함하면 유용합니다.

- 이슈 설명(Description)에 핵심 정보를 포함

예시) 버그 지라 작성

문제 요약 :

Chrome 브라우저에서 로그인할 때, 이메일을 올바르게 입력해도 'Invalid Email' 오류가 발생함.

발생 조건 :
- 환경: Windows 10, Chrome 112
재현 단계 :
1. 로그인 페이지에 접속
2. 이메일 입력 (test@example.com)
3. 비밀번호 입력 후 로그인 버튼 클릭
예상 결과 : 올바른 이메일 입력 시 정상적으로 로그인되어야 함.
실제 결과 :'Invalid Email' 오류 메시지가 표시됨.
스크린샷 : (이미지 첨부)
관련 이슈 : [JIRA-1234] - 로그인 API 수정 관련

- 이슈 유형을 정확하게 선택

예시)

Story → 새로운 기능 개발
Task → 일반적인 작업
Bug → 버그 수정
Epic → 여러 개의 Story를 포함하는 대규모 기능
Sub-task → 특정 이슈(Task, Story) 내에서 작은 단위의 작업

- 워크플로우를 일관성 있게 관리

예시)

To Do → In Progress → Code Review → Done

팀 내에서 공통된 작업 흐름을 정의하면 혼란 없이 진행 가능

2. Confluence

문서 템플릿을 활용하여 일관성 유지

예시)

문서 제목과 목차 구조를 명확하게 정리

예시)

표와 매크로를 활용하여 가독성 향상

예시)

작업 내용 : 로그인 기능 수정
담당자 : 홍길동
상태 : 진행중
JIRA 이슈 : [JIRA-5678]

작업 내용	담당자	상태	JIRA 이슈
로그인 기능 수정	홍길동	진행 중	[JIRA-5678]
대시보드 UI 개선	김철수	완료	[JIRA-5679]

커뮤니케이션 잘하기(협업 조직) - 1

PM의 역할

팀 간의 원활한 소통을 이해관계를 조정하여 최적의 결과 도출
프로젝트 목표를 공유하고, 일정 조율 및 리스크를 관리

-> 개발팀, 디자인팀, 사업팀, 지원팀(총무/HR) 등과 협업하며 각 부서의 업무 방식과 커뮤니케이션 스타일을 이해하는 것이 매우 중요

< 각 팀별 특징 및 커뮤니케이션 팁 >

1. 개발팀

개발자 특징

논리적이고 데이터 중심적인 사고방식을 선호
구체적인 요구사항 & 명확한 목표가 필요함
일정 관리가 중요하며, 무리한 일정 조율을 부담스러워함
기술적인 난이도나 구현 방식에 대한 이해가 필요할 수 있음
작은 변경이라도 전체 코드에 영향을 줄 수 있음

커뮤니케이션 팁

기획을 확정한 후 요청하는 것이 가장 효율적(잦은 변경 x)
명확한 요구사항 전달
- 기능 요청 시 구체적인 요구사항 + 이 기능이 필요한 이유(WHY)를 설명
- "이 기능이 왜 필요한가?"에 대한 설명이 있으면 개발자의 업무 몰입도가 높아짐
- 기능 정의 시, 무엇을 원하는지, 왜 필요한지, 어떻게 동작해야 하는지를 명확히 설명하는 것이 중요
JIRA & Confluence 활용
- JIRA 또는 Confluence(위키 문서)에 정리해서 전달
- 개발자는 문서 기반으로 작업하는 것을 선호 → 작업 내역, 스펙, 일정 등이 문서화되어 있어야 함
우선순위를 조율하고 개발팀과 협의하는 태도가 중요
- 일정 조율 시 기획 > 개발 > 테스트 과정을 모두 고려
- 개발 일정은 예상보다 늘어날 가능성이 있어 "빨리 해주세요"보다는 협의하는 태도 유지
개발팀은 기술적으로 불가능한 요청을 받을 때가 많으므로 요청 전, 현재 시스템에서 구현 가능한지 사전 논의가 필요

2. 디자인팀

디자이너 특징

창의적이고 감각적인 요소를 중요하게 생각함
정량적 데이터보다 시각적인 표현 & 사용자 경험(UX) 관점에서 접근
이미지, 와이어프레임, 프로토타입으로 소통하는 것을 선호

커뮤니케이션 팁

사소해 보이는 부분도 충분한 이유가 있을 수 있으므로, 피드백을 줄 때는 근거를 함께 제시
(작은 픽셀 간격, 컬러 톤, 폰트 스타일)
개인 취향이 아닌, 사용자 중심의 피드백을 주는 것이 중요
단순히 "이렇게 바꿔 주세요"보다는, 참고 이미지나 레퍼런스를 함께 제공하면 더 효과적

3. 마케팅팀

마케터 특징

마케팅팀은 "멋진 콘텐츠"보다 "성과가 나는 콘텐츠"에 집중
감각이 아닌 데이터(CTR, 전환율, ROAS, 고객 유입 수치 등)를 기반으로 판단
마케팅팀은 내부 의견보다 고객 반응에 민감

커뮤니케이션 팁

모든 피드백을 줄 때, "이게 목표 달성에 어떤 도움이 되는가?"를 고려
피드백을 줄 때도 데이터나 논리적 근거를 제시
내 취향보다는 "고객이 원하는 것인가?"를 중심으로 논의

커뮤니케이션 잘하기(협업 조직) -2

4. 사업팀

사업부 특징

매출, 비용, 시장 트렌드, 고객 반응 등을 중심으로 의사결정
사업팀은 디자인, 개발보다는 매출, 시장 경쟁력, 유저 증가 같은 OKR(KPI)에 관심이 많음
내부 논리보다 고객이 원하는 것, 시장에서 통하는 것을 우선시함
빠른 의사결정을 원하며 정량적인 데이터를 선호
사업팀은 캠페인 일정, 프로모션 기획, 제품 출시 일정을 고려

커뮤니케이션 팁

모든 피드백을 줄 때, "이게 목표 달성에 어떤 도움이 되는가?"를 고려
기술적인 용어보다는 비즈니스 가치(ROI, 성장 가능성) 중심으로 설명해야 함
시장과 고객 관점에서 논의하고 너무 많은 논의보다 일단 실행하고 데이터로 검증
일정을 미리 조율하고, 명확한 목표를 공유하기

5. HR팀

인사, 채용, 보상, 총무팀 특징

직원 전체를 고려하는 입장 : 개별 직원보다 전체 조직의 균형과 공정성을 고려하여 의사결정
내부 프로세스, 회사 규정 등을 중시함 → 즉각적인 대응보다는 정해진 절차에 따라 진행하는 것을 중요하게 생각

커뮤니케이션 팁

회사의 정책과 규정을 미리 숙지하고 조직 전체 관점에서 이야기하기
요청할 때 기존 정책이나 법적 기준을 고려한 논리적인 접근

알고 있으면 좋은 IT 용어 (1)

1. 개발 및 기술 관련 용어 (일명 판교어)

Agile (애자일)

유연하고 반복적인 개발 방식으로, 짧은 개발 주기를 통해 지속적으로 개선하는 방식

예시: “우리 팀은 Agile 방법론을 사용하여 매주 스프린트를 진행하고 있어요.”

Scrum (스크럼)

애자일의 한 방식으로, 짧은 기간(스프린트) 동안 목표를 설정하고 반복적으로 개발하는 프레임워크

예시: “이번 스프린트에서는 UI 개선 작업을 완료해야 합니다.”
-> 스크럼 예시문장인데 왜 갑자기 스프린트가 나오냐?

Sprint (스프린트)

일정 기간(보통 1~4주) 동안 특정 기능을 개발하는 애자일 개발 방식의 단위

예시: 다음 스프린트에서는 결제 시스템 기능을 추가할 계획이에요.

Backlog (백로그)

프로젝트에서 완료해야 할 작업 목록

예시: 고객 요청 기능이 백로그에 추가되었어요.

이렇게 Jira에서 백로그 추가할 수 있음

Kanban (칸반)

작업을 시각적으로 관리하는 방법으로, 진행 상태를 한눈에 볼 수 있음.

예시: 우리 팀은 Trello를 사용해서 칸반 방식으로 작업을 관리하고 있어요.

이렇게 Jira 칸반보드를 통해 진행상황을 한 눈에 볼 수 있음

프론트엔드(Frontend) & 백엔드(Backend)

프론트엔드는 사용자가 직접 보는 화면(UI) 담당 / 백엔드는 데이터를 처리하고 저장하는 서버 담당

프론트엔드 : 웹사이트에서 로그인 버튼을 누르면 로그인 창이 뜨는 기능
백엔드 : 쇼핑몰에서 사용자가 로그인하면 회원 정보 확인 & 로그인 처리 / 사용자가 장바구니에 상품을 추가하면 백엔드에서 데이터베이스에 저장

프론트엔드와 백엔드는 어떻게 협업할까?

사용자가 로그인 버튼을 클릭 (프론트엔드)
백엔드 서버에 로그인 요청을 보냄 (API 호출)
백엔드가 데이터베이스에서 사용자 정보를 확인
로그인 성공 여부를 프론트엔드로 응답
프론트엔드에서 로그인 성공 화면을 표시

→ 프론트엔드는 사용자 경험(UX/UI)에 집중

→ 백엔드는 데이터 처리와 보안에 집중

*프론트엔드와 백엔드를 모두 할 줄 아는 개발자를 풀스택 개발자라고 부름

** 앞단(Front-end) & 뒷단(Back-end)이라고 부르기도 함

알고 있으면 좋은 IT 용어 (2)

예비 PM으로서 알고 있으면 유용한 IT 용어를 학습해보자~

판교사투리~~~~~~~

클라이언트(Client) & 서버(Server)

웹 또는 앱 서비스가 동작할 때 클라이언트(Client)와 서버(Server)가 서로 데이터를 주고받는 구조

클라이언트(Client) → 사용자가 직접 조작하는 인터페이스(UI)와 요청(Request)을 담당
- 클라이언트는 사용자가 직접 사용하는 프로그램 또는 장치
- 사용자가 버튼을 누르거나 입력을 하면, 서버에 요청을 보냄
- 서버에서 데이터를 받아 화면(UI)에서 보여주는 역할
서버(Server) → 요청을 받아 데이터를 처리하고 응답(Response)을 반환하는 역할
- 서버는 클라이언트의 요청을 받아 데이터를 처리하고 응답하는 시스템
- 백엔드(Backend)에서 데이터를 관리하며, 보안 및 트래픽을 처리하는 역할 수행
- 하나의 서버가 여러 개의 클라이언트 요청을 동시에 처리할 수 있음

클라이언트와 서버는 어떻게 작동할까?

사용자가 네이버 검색창(클라이언트) 에서 "날씨" 입력 후 검색 버튼 클릭
라이언트가 네이버 서버에 "날씨" 검색 요청(Request) 전송
서버가 "날씨 검색 결과" 데이터를 응답(Response)으로 반환
클라이언트가 받은 데이터를 화면에 표시

배달 음식 주문시 클라이언트 & 서버 처리 과정

사용자가 배달의민족 앱(클라이언트)에서 치킨을 장바구니에 추가하고 결제 버튼 클릭
클라이언트가 서버에 주문 요청(Request)을 보냄
서버가 결제 확인 후, 데이터베이스에 주문 정보 저장
서버는 주문 완료 응답(Response)을 클라이언트에 전달
클라이언트는 주문 완료 페이지를 사용자에게 표시

→ 사용자는 주문이 정상적으로 접수되었음을 확인

라이브러리(Library)

특정 기능을 수행하는 코드 모음 ('도구 상자' 같은 개념)

프레임워크(Framework)

개발을 위한 기본 틀(뼈대)

오픈소스(Open Source)

소프트웨어의 소스 코드가 공개되어 누구나 자유롭게 사용할 수 있는 소프트웨어

Git(깃) & GitHub(깃허브)

Git은 코드의 변경 사항을 추적하고 관리하는 '버전 관리 시스템’
GitHub는 Git 저장소를 온라인에서 관리할 수 있는 '클라우드 서비스’

베타(Beta), 데브(Dev), 스테이지(Stage), 리얼(Real)

제품 개발 과정에서 사용되는 주요 환경

환경	설명	주요 목적
Dev (개발 환경)	개발자가 기능을 개발하고 내부 테스트를 진행하는 환경	초기 개발 및 기능 구현
Stage (스테이징 환경)	실제 서비스 환경과 유사하게 운영되며 QA 및 성능 테스트를 진행하는 환경	배포 전 최종 점검
Beta (베타 환경)	일부 사용자(클로즈드 또는 오픈 베타)를 대상으로 실사용 테스트를 진행하는 환경	사용자 피드백 수집 및 최적화
Real / Prod (실서비스 환경)	실제 사용자가 사용하는 라이브 서비스 환경	최종 배포 및 운영

API (Application Programming Interface)

소프트웨어 또는 시스템 간에 데이터와 기능을 주고받을 수 있도록 정의된 인터페이스

예시: 결제 시스템과 연동하려면 API 문서를 확인해야 합니다.

SDK (Software Development Kit)

특정 플랫폼, 운영체제, 또는 서비스에서 애플리케이션을 개발할 수 있도록 지원하는 도구 모음

라이브러리, API, 개발 도구, 문서, 샘플 코드, 가이드라인 등을 포함하며, 개발자가 특정 환경에서 더 쉽게 프로그램을 만들 수 있도록 도와줌

예시: Google Maps SDK를 이용해서 지도 기능을 추가할 수 있어요.

알고 있으면 좋은 IT 용어 (3)

예비 PM으로서 알고 있으면 유용한 IT 용어 학습해보자~~~~~~~

판교사투리~~~~~~~

반응형 웹

사용자가 어떤 기기(PC, 태블릿, 모바일 등)를 사용하든 최적의 화면을 제공하는 웹사이트 디자인 방식
(화면 크기에 따라 레이아웃이 자동으로 조정되므로, 별도의 모바일 웹사이트를 만들 필요 없이 하나의 웹사이트로 모든 기기에 대응 가능)

PC 버전

모바일 버전

데이터 및 성능 관련 용어

Latency (지연 시간)

요청을 보낸 후 응답을 받기까지 걸리는 시간

예시: API 응답 지연 시간이 500ms 이상이면 최적화가 필요해요.

Cache (캐시)

데이터를 임시로 저장하여 빠르게 접근할 수 있도록 하는 저장소

자주 사용되는 데이터를 미리 저장해 두었다가 다시 필요할 때 빠르게 제공하여, 성능을 향상시키고 지연 시간을 줄이는 역할

예시: 데이터 조회 속도를 높이기 위해 캐시를 활용해야 합니다.

A/B 테스트

두 가지 버전을 비교하여 더 나은 성과를 분석하는 실험 방법

예시: 버튼 색상을 변경하는 A/B 테스트를 진행한 결과, 전환율이 10% 증가했어요.

기획 / 마케팅 관련 용어

KPI(Key Performance Indicator, 핵심 성과 지표)

비즈니스 목표 달성을 위해 설정한 핵심 지표

예시 : 이커머스 앱의 KPI

월간 활성 사용자 수 (MAU)
전환율 (Conversion Rate)
평균 주문 금액 (AOV, Average Order Value)
고객 유지율 (Retention Rate)

OKR(Objectives and Key Results, 목표 및 핵심 결과)

목표(Objective)와 핵심 결과(Key Results)로 구성된 성과 관리 방법론

Objective(목표) : 달성하고자 하는 구체적이고 도전적인 목표
Key Results(핵심 결과) : 목표 달성을 위해 반드시 이루어야 하는 구체적인 결과

MVP

최소한의 기능을 갖춘 제품으로, 시장 반응을 확인하기 위한 초기 버전

BM(비즈니스 모델)

회사가 고객에게 가치를 제공하고, 이를 통해 수익을 창출하는 방식

(우리 회사는 어떻게 돈을 버는가?)

그로스 해킹 (Growth Hacking)

제품이나 서비스를 빠르게 성장시키기 위해 데이터 기반으로 창의적인 마케팅과 실험을 반복하는 과정

예시: Dropbox는 친구를 초대하면 추가 저장공간을 제공하는 그로스 해킹 기법을 활용했습니다.

AARRR 프레임워크

스타트업과 제품의 성장을 측정하고 최적화하기 위한 사용자 퍼널 모델

사용자가 제품을 처음 접한 후, 어떻게 활성화(Activation)되고, 유지(Retention)되며, 매출(Revenue)로 이어지고, 추천(Referral)으로 성장하는지를 분석하는 데 사용

Acquisition (획득) → 사용자가 유입됨
Activation (활성화) → 제품을 처음 사용함
Retention (유지율) → 사용자가 지속적으로 이용
Revenue (수익) → 유료 서비스로 전환
Referral (추천) → 사용자가 다른 사람을 초대

예시)

Retention(유지율)이 낮으면 Activation(활성화) 과정에서 문제가 있는지 점검해야 합니다.

퍼널 분석(Funnel Analysis)

사용자가 특정 목표(예: 구매, 회원가입, 구독)를 달성하기까지 거치는 단계별 과정 을 분석하는 기법
각 단계에서 얼마나 많은 사용자가 이탈하는지를 추적하여, 전환율을 최적화하고 성장을 극대화하는 데 활용

예시) 퍼널 분석 결과, 장바구니 단계에서 30%의 사용자가 이탈하고 있습니다.

랜딩 페이지

사용자가 광고, 검색 결과, 이메일 링크 등을 클릭한 후 도착하는 특정 웹페이지

CTA(Call To Action)

사용자가 특정 행동을 하도록 유도하는 요소

예시) “지금 가입하고 무료 혜택 받기”

이벤트

사용자가 제품(웹사이트, 앱 등)에서 하는 특정한 행동

예시) 이커머스 앱에서 "장바구니 담기" 버튼 클릭 (특정한 행동) → 이걸 이벤트라고함

DA 광고(Display Advertising, 디스플레이 광고)

웹사이트, 앱, SNS 등에 배너, 이미지, 영상 등의 형태로 노출되는 온라인 광고

광고 유형	설명	예시
배너 광고 (Banner Ads)	특정 웹사이트나 앱에서 배너 형태로 노출되는 광고	네이버 메인 상단 배너, 블로그 사이드바 배너
네이티브 광고 (Native Ads)	콘텐츠와 자연스럽게 어우러진 광고	뉴스 기사 내 추천 콘텐츠, 인스타그램 피드 광고

CRM(Customer Relationship Management)

고객과의 관계를 효과적으로 관리하여, 유지율을 높이고 비즈니스 성과를 극대화하는 전략 및 시스템

CRM의 주요 목적

고객 데이터를 체계적으로 관리 → 고객 정보, 구매 이력, 상담 기록, 피드백 등을 통합
고객 만족도 및 충성도 향상 → 맞춤형 추천, 개인화된 혜택 제공
마케팅 및 세일즈 최적화 → 자동화된 이메일, 리타겟팅 광고, 리드 관리 활용
이탈 고객 방지(Retention) → 고객 행동을 분석하여 적절한 대응 전략 수립

알고 있으면 좋은 IT 용어 (4)

업무 용어

아젠다(Agenda)

회의나 업무 진행 시 다룰 주요 주제

예시 : 오늘 회의 아젠다는 신제품 출시 전략입니다.

얼라인(Align)

목표나 방향을 조율하고 일치시키는 것

예시 : 팀 간 목표를 얼라인하여 일관된 전략을 세워야 합니다.

어레인지(Arrange)

일정, 계획 등을 조정하고 준비하는 것

예시 : 고객사 대응을 위한 미팅 어레인지 부탁드려요.

런칭(Launching)

신제품, 서비스 출시

알앤알(R&R, Role & Responsibility)

역할과 책임 분담

어사인(Assign)

특정 작업이나 역할을 할당하는 것

컴(Comm, Communication)

의사소통, 커뮤니케이션을 의미하며, 팀원 간 정보 공유와 논의를 뜻함

컨펌(Confirm)

확인 및 승인하는 것

컨센서스(Consensus)

합의, 의견 일치를 의미하며, 여러 사람의 의견을 조율해 결론을 내는 과정

디벨롭(Develop)

개발, 발전, 개선을 의미하며 제품 개발에 자주 사용

F/U (Follow Up)

후속 조치, 진행 상황 확인

예시 : 어제 논의한 건에 대해 F/U 부탁드립니다.

픽스(Fix)

최종 확정

아이데이션(Ideation)

아이디어를 창출하는 과정

라이브(Live)

서비스가 실제 운영(배포)되는 상태

레퍼런스(Reference)

참고 자료, 벤치마킹 대상

스콥(Scope)

업무 범위, 프로젝트 범위

EOD (End of Document)

문서의 끝을 나타내는 표시

TBD (To Be Determined)

추후 결정 예정

온보딩(Onboarding)

신규 사용자 또는 직원이 적응하도록 지원하는 과정

기안

공식 문서를 작성하여 승인 요청하는 것

반려

승인되지 않고 되돌려지는 상태

상신

상위 직급 또는 팀에 공식적으로 보고하거나 결재를 올리는 것

7/14 데이터드리븐 VOD강의 (용어정의)

bbborang — Tue, 14 Jul 2026 12:19:50 +0900

1. PV (Page View, 페이지뷰)

사용자가 웹사이트 또는 앱 내에서 특정 페이지를 조회한 횟수

동일한 사용자가 같은 페이지를 여러 번 새로고침해도 PV는 증가
PV는 방문자 수와 관계없이 페이지가 얼마나 많이 조회되었는지를 나타내는 지표

2. UV (Unique Visitor, 순 방문자)

특정 기간 동안 웹사이트나 앱을 방문한 중복되지 않은 개별 사용자 수

같은 사람이 여러 번 방문해도 하루 동안은 1명의 UV로 계산

3. DAU (Daily Active Users, 일간 활성 사용자)

하루 동안 특정 서비스에 방문하거나 특정 액션을 수행한 사용자 수

4. WAU (Weekly Active Users, 주간 활성 사용자)

일주일 동안 특정 서비스에서 활동한 사용자 수

DAU의 주간 버전으로, 주 단위 사용자 충성도를 측정하는 데 사용됨

5. MAU (Monthly Active Users, 월간 활성 사용자)

한 달 동안 특정 서비스에서 활동한 사용자 수

서비스의 장기적인 성장성과 사용자 유지율을 측정하는 데 중요

6. Retention Rate (리텐션율, 유지율)

특정 기간 동안 기존 사용자가 다시 서비스에 방문하는 비율

Day 1 Retention은 신규 가입자가 다음 날 다시 방문하는 비율을 의미

7. 이탈률

특정 기간 동안 서비스를 이탈한 사용자 비율

8. CTR (Click-Through Rate, 클릭률)

광고나 특정 콘텐츠를 본 사용자 중 실제로 클릭한 비율

계산법 = (클릭 수 / 노출 수) * 100

9. Conversion Rate (전환율)

특정 목표(구매, 회원가입, 다운로드 등)를 완료한 사용자 비율

계산법 = (전환 수 / 방문자 수) * 100

10. DCU (Daily Click Users, 일간 클릭 사용자)

하루 동안 특정 서비스에서 클릭을 한 사용자 수

단순히 접속한 것이 아니라, 특정 버튼, 링크, 메뉴 등을 클릭한 사용자를 측정

11. DCC (Daily Click Count, 일간 클릭 횟수)

특정 사용자가 하루 동안 클릭한 총 횟수

한 사용자가 하루에 여러 번 클릭하면 그 횟수를 모두 포함
DCU가 "클릭한 사용자 수"라면, DCC는 "사용자가 클릭한 총 횟수"

12. 세션(Session)

사용자가 사이트를 방문하여 활동하는 하나의 단위

일정 시간 동안 사용자의 활동이 없으면 세션 종료

13. 체류 시간

사용자가 웹사이트에서 머문 시간

14. Impression (임프레션, 노출 수)

사용자의 화면에 광고 또는 콘텐츠가 노출된 총 횟수

클릭 여부와 관계없이 단순히 화면에 표시된 것만으로도 카운트됨
광고, 배너, 검색결과 등 다양한 채널에서 사용됨

15. CPA (Cost Per Action)

사용자가 특정 행동(가입, 구매 등)을 하는 데 들어간 비용

계산법 = 광고비 ÷ 전환(액션) 수

16. CPC (Cost Per Click)

광고 클릭 1회당 비용

사용자가 실제로 광고를 클릭한 횟수당 비용을 지불하는 형식

계산법 = 총 광고비 ÷ 총 클릭 수

17. CPM (Cost Per Mille)

광고가 1,000회 노출될 때의 비용

광고가 1,000번 노출될 때마다 광고주가 지불해야 하는 비용을 계산하는 방식

18. CPI (Cost Per Install)

설치당 비용

계산법 = 총 광고비 ÷ 앱 설치 수 (설치 1회당 단가)

19. ARPU (Average Revenue Per User)

개별 광고주당 평균 광고 금액

20. ROI (Return On Investment)

투자 대비 수익

계산법 = [(총 수익 - 총 투자 비용) ÷ 총 투자 비용] × 100

7/13 데이터드리븐 VOD강의

bbborang — Mon, 13 Jul 2026 13:26:11 +0900

1. 데이터 드리븐 기획

사용자 행동 데이터, 시장 데이터, 성과 데이터 등을 기반으로 의사결정을 내리고 제품을 기획하는 방식

우리 서비스에서 사람들이 실제로 어떤 행동을 하는지 데이터로 확인하고
데이터를 분석해서 문제를 찾고
객관적인 근거를 바탕으로 해결책을 기획

2. 데이터 드리븐 기획이 중요한 이유

- 정확한 기획이 가능

- 고객이 원하는 것을 제대로 알 수 있음

- 비즈니스 성과 극대화

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

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

4. 데이터 드리븐 기획의 실제 사례

ex) 넷플릭스 사례

넷플릭스는 완결률, 정지 및 시작 시간, 시청 시간대, 시청 패턴(예: 일시 정지, 빨리 감기, 되감기 등) 같은 데이터를 활용해 더 효과적인 콘텐츠 전략을 세운다.

+ 시청 데이터를 분석해 성공 가능성을 예측하고 있었다. 이를 통해 어떤 구독자층이 이 콘텐츠에 관심을 가질지 정확히 파악할 수 있었고, 덕분에 새로운 시리즈를 제작하는 데 따른 창작 리스크를 줄일 수 있었다.

-> 결과적으로 오리지널 콘텐츠 성공률 80% 달했음

백오피스 : 어드민을 만든다

로그

로그는 어디에 사용할까?
1. 문제 해결 및 디버깅

2. 사용자 행동 분석

3. 비즈니스 전략 수립

+ 다양한 종류의 로그가 있지만, PM으로서 알아야 할 대표적인 로그 : 클라이언트 로그

로그는 어떻게 설계할까?

로그 설계는 단순히 "무엇을 기록할지"가 아니라 "왜 기록할지", "어떻게 기록할지"에 대한 전략적 접근이 필요합니다. PM은 이 설계를 통해 개발 팀이 실제로 필요한 데이터를 수집하고, 이 데이터를 기반으로 문제를 빠르게 파악하거나 서비스를 개선할 수 있도록 해야 합니다.

배달의 민족 로그 정의 정책

배달의 민족 로그는 클라이언트 로그를 기준으로 함.
클라이언트 로그는 다른 말로 '화면 로그'를 뜻하며 서비스 화면을 기준으로 로깅된 로그로 정의함(Ex. click, pageview)
(클라이언트 로그는 유저가 어떤 페이지를 방문했고 그 페이지에서 어떤 영역을 클릭했는지 등 유저의 '행동'에 초점이 맞춰져 있음)
로그의 로그타입(Action Type)에 따라 발생하는 로그 종류
- 1) 페이지 로그(pageview) : 유저가 인지하는 하나의 화면(view)를 '페이지'라고 하며 이 화면이 로딩 될 때 남기는 로그
- 2) 이벤트 로그 (event) : 유저의 특정 '행동(클릭 등)'시, 남기는 로그

카카오 로그 정의 정책

카카오 메이커스는 모바일 앱(Android, iOS)과 웹(Web) 환경에서 각각 로그를 수집함
유저가 어떤 경로를 통해 카카오 메이커스에 유입되었는지 기록하는 유입 로그를 수집함

(직접 URL 입력, 카카오톡 공유, 검색 엔진(네이버, 구글 등) 검색, 광고 배너 클릭 등의 유입 경로를 식별하여 저장함)

Tip : 카카오톡 더보기에서 진입한 메이커스 화면을 통해 카카오톡은 하이브리드 앱임을 알 수 있음

참고로 하이브리드 앱(Hybrid App)이란?

네이티브 앱(Native App)과 웹 앱(Web App)의 특징을 결합한 형태

데이터 시각화

GA4 : 데이터 tool

1. 데이터 시각화 목적

복잡한 데이터를 쉽게 전달 : 숫자나 텍스트보다 시각적 자료가 직관적으로 정보를 전달
데이터 기반 의사결정을 촉진 : 데이터에 대한 신뢰도를 높이고 논리적인 결론을 도출
이해 관계자 설득 : 경영진, 투자자, 팀원 등 다양한 청중에게 의사결정을 유도.

2. 데이터 시각화 유형

- 시계열 비교 : 시간에 따른 데이터 변화를 분석하는 방법

<주요 시각화 기법>

꺾은선 그래프(기본)
영역 차트 -> 변화량을 강조하여 시각적 효과 극대화
막대 그래프 -> 특정 기간별 (연도별, 월별) 데이터 비교

예시)

연도별 매출 변화 분석 → 기업의 연간 매출 데이터를 꺾은선 그래프로 시각화
날씨 변화 분석 → 1년 동안의 일별 평균 기온을 선 그래프로 표현
웹사이트 방문자 수 변화 → 월별 사용자 수 변화 추이를 분석

2. 속성 비교

여러 그룹이나 범주(카테고리) 간 차이를 분석하는 방법

-> 서로 다른 항목들이 어떻게 다르고, 어느 것이 더 크거나 작은지를 비교

<주요 시각화 기법>

막대 그래프 (기본)

파이(원) 차트 -> 전체 중에서 특정 항목이 차지하는 비율 확인

히트맵 -> 여러 범주의 데이터를 색상으로 표현하여 비교

예시)

A, B, C 3개의 브랜드가 있고, 각 브랜드의 매출을 비교

막대 그래프 사용 : 어느 브랜드의 매출이 가장 높은지 확인 가능

서울, 부산, 대구에서 하루 동안 판매된 커피 수량을 비교

파이 차트를 사용 : 어느 지역에서 커피가 가장 많이 팔렸는지 한눈에 확인 가능

고객 만족도를 1점~5점으로 나눠서, 각 점수를 받은 고객 수를 비교

히트맵을 사용 : 어느 점수가 가장 많이 나왔는지 고객 만족도 비교 가능

3. 분포 파악

어떤 형태로 퍼져 있는지(분포 특성) 분석하는 방법

-> 데이터의 중심값, 범위, 이상값(Outliers) 등을 확인

<주요 시각화 기법>

산점도 (기본)

히스토그램 -> 연속형 데이터의 빈도를 분석하는데 유용

예시)

시험 점수 분포 분석 → 히스토그램을 이용해 특정 점수대에 학생들이 얼마나 분포하는지 확인

4. 상관 분석

두 개 이상의 변수 간의 관계를 파악하는 방법

-> 한 변수가 증가할 때 다른 변수가 증가하거나 감소하는지를 분석

<주요 시각화 기법>

산점도 → 두 변수 간의 관계를 시각적으로 분석

예시)

광고비와 매출 간 관계 분석 → 산점도를 활용하여 광고비가 증가할 때 매출도 증가하는지 확인
키와 몸무게 간의 상관관계 → 산점도를 사용하여 키가 클수록 몸무게도 증가하는지 시각화

3. 데이터 시각화 기본

1. 배치 순서에 의미를 두어야 함

데이터를 배치할 때는 특정한 의미(시간 흐름, 크기 순서 등)를 고려하고 논리적인 흐름을 유지하는 것이 중요

예시)

시간 흐름을 나타내는 경우 → 연도별 매출 변화
→ 연도 순으로 배치 (2020 → 2021 → 2022)
크기 비교하는 경우 → 기업별 매출 순위
→ 가장 큰 값부터 내림차순 정렬 (예: 1위 → 2위 → 3위)

활용 팁

시간 순서: 날짜, 연도별 데이터는 반드시 시간 순으로 정렬
크기 비교: 큰 값 → 작은 값 순으로 정렬하여 가독성 증가

2. 비교 대상에 따라 적절하게 그래프나 표를 조절 + 정렬할 필요가 있음

비교하려는 대상에 따라 막대 그래프, 선 그래프, 원 그래프, 표 등을 적절히 선택해야 함
데이터의 특성에 맞게 정렬(내림차순, 오름차순 등)하여 비교하기 쉽게 만들어야 함

예시)

숫자 크기 비교 → 막대 그래프 (Bar Chart)
- 매출, 방문자 수 등 크기를 비교할 때 효과적
시간 흐름 분석 → 선 그래프 (Line Chart)
- 주가, 트래픽 변화처럼 시간에 따른 변화를 표현할 때 사용
전체 비율 비교 → 원형 그래프 (Pie Chart)
- 시장 점유율, 고객 비율 등 비율을 나타낼 때만 사용 (숫자 차이가 크면 사용하지 않는 것이 좋음)
범주형 데이터 정렬 → 표 (Table)
- 수치형 데이터가 아니라 이름, 코드 등 정렬이 필요한 경우 활용

활용 팁!!!!!

시간 변화 → 선 그래프 (예: 2020년~2023년 매출 변화)
크기 비교 → 막대 그래프 (예: 기업별 매출 비교)
비율 비교 → 원형 그래프 (예: 제품별 시장 점유율)
정확한 데이터 표시 → 표 (예: 제품별 가격 비교)

3. 수치를 비교할 때는 가로보다 세로를 추천

막대 그래프를 사용할 때 가로형보다는 세로형을 추천
사람의 시각적 인식 특성상 세로형 그래프가 수치 비교에 더 적합함
가로형 그래프는 긴 텍스트가 있을 때만 사용하는 것이 효과적

7/9 Framer 강의

bbborang — Thu, 9 Jul 2026 09:41:44 +0900

Framer에서 만들어지는 모든 것들은 Frame에서 출발한다.

stack = 특수한 frame

화이트 리스트(Whitelist) : 접근이 기본적으로 차단된 상태에서 안전하다고 검증되어 예외적으로 허용된 대상이나 승인된 목록

블랙리스트(Blacklist) : 기본적으로 모두 허용하되 문제가 되는 대상만 차단

(서로 반대되는 개념)

7/7 에이타니 AI퀴즈 오답노트

bbborang — Tue, 7 Jul 2026 11:38:21 +0900

Webflow: 설계도와 건축 구조를 세밀하게 잡을 수 있는 전문 건축 도구
Framer: 빠르게 예쁜 쇼룸을 만들고 시연하기 좋은 도구
Bubble: 내부 기능이 복잡한 업무용 시스템을 만들기 좋은 도구
Zapier: 건물을 짓는 도구가 아니라, 여러 시스템을 연결하는 자동화 배선 도구

- Framer의 강점

빠른 프로토타입 제작
Figma와 유사한 쉬운 사용성
인터랙션과 애니메이션 표현
빠른 랜딩 페이지 제작과 배포
MVP나 포트폴리오 제작

프로토타입 완성도는 보통 아이디어 스케치 수준에서 실제 작동하는 제품 수준으로 올라가는 흐름

비유하면, 카페를 만든다고 할 때:

페이퍼 프로토타입

- 종이에 “여기에 메뉴판, 여기에 주문 버튼”처럼 그려보는 단계
- 가장 빠르고 저렴하게 아이디어를 확인가능
- 실제 클릭이나 동작은 없고, 구조를 대략 확인하는 수준

와이어프레임

- 종이보다 조금 더 정리된 화면 설계도
- Figma, PPT, Keynote 등으로 화면 구조와 정보 배치를 표현
- 핵심은 예쁜 디자인이 아니라 정보 구조와 사용자 흐름
- 예: 상품 상세 페이지에서 이미지, 가격, 리뷰, 구매 버튼을 어떤 순서로 보여줄지 정하는 단계

인터랙티브 프로토타입

- 버튼을 누르면 다음 화면으로 넘어가는 등 사용자 흐름을 실제처럼 체험
- 아직 실제 서비스처럼 데이터가 저장되거나 결제가 되는 건 아닐 수 있지만, 사용자가 “이렇게 쓰겠구나”를 테스트 가능
- Framer 같은 도구가 이 단계에서 많이 활용됨

MVP

- 실제 사용자가 사용할 수 있는 최소 기능 제품
- 단순한 화면 시뮬레이션이 아니라, 핵심 기능이 실제로 작동
- 완성품은 아니지만 시장이나 사용자에게 검증할 수 있는 수준

통계적으로 유의하다는 것은,

- A안과 B안의 차이가 실제로 존재할 가능성이 높고, 단순한 랜덤 변동으로 보기 어렵다
- p-value < 0.05일 때 통계적으로 유의하다고 판단

ROI 관점이란 'Return On Investment(투자수익률)'의 관점으로,

투입한 비용이나 노력 대비 얼마나 많은 순이익(효과)을 얻었는가를 평가하는 시각을 의미

단순히 매출이나 규모의 크기가 아니라, 철저히 '가성비'와 '실제 남는 이익'을 중심으로 의사결정을 내리는 기준

A/B 테스트에서 보통 유의수준을 0.05로 둔다면,

=> 실제로 효과가 없는데도 효과가 있다고 잘못 판단할 확률을 5%까지 허용한다는 뜻

세션(Session)

사용자가 웹사이트나 앱과 상호작용하는 일정 기간 동안의 활동을 그룹화한 단위

GA4에서는 기본적으로 30분간 활동이 없으면 세션이 종료되며, 사용자의 전체적인 방문 패턴을 파악하는 데 활용

GA4를 오프라인 매장 방문 기록으로 비유하면......

세션: 손님이 매장에 한 번 방문한 것
이벤트: 방문 중에 한 행동들
예: 입장하기, 상품 보기, 장바구니 담기, 결제 버튼 누르기
전환: 그 행동들 중 비즈니스적으로 중요한 행동
예: 구매 완료, 상담 신청, 회원가입 완료

( 회원가입 완료 = 명확한 비즈니스 목표 달성이므로 전환(Conversion)으로 분류 )

피벗 : 제품의 근본적인 방향(핵심 가치 제안, 타겟 고객, 비즈니스 모델 등)을 전략적으로 변경하는 것

기능 강화 : 기존의 제품 방향성과 핵심 가치는 유지하면서 기능을 추가하거나 개선하여 제품을 발전시키는 것

SRM 검증 : 실험군/대조군 배정 비율이 설정값과 맞는지 확인

다변량 테스트 : 여러 요소 조합을 동시에 실험

조기 종료 : 실험을 계획보다 일찍 끝냄

통계적 검정력 : 효과를 발견할 만큼 표본이 충분한지 확인

SRM = Sample Ratio Mismatch (표본 비율 불일치 검증)

ㅡ> 말 그대로 표본이 원래 의도한 비율대로 나뉘지 않은 상태

7/1 서비스기획 심화과제 (User Flow & Wireframe 제작)

bbborang — Wed, 1 Jul 2026 14:35:18 +0900

User Flow

권장 도구: Miro, FigJam, draw.io, Figma

Wireframe
권장 도구: Figma, 구글 스티치

특히!!!

구글 Stitch -> 모바일 앱 디자인 / 와이어프레임 제작에 굉장히 유용한 tool 이라고 느꼈다.

프롬프트를 입력한뒤 보내면 AI가 와이어프레임을 생성해주는데

각 퍼널별로 우클릭하면 Copy as 가 나오는데

이게 진짜 대박이었다.

Copy as Code -> 구현된 와이어프레임 코드를 직접 따낼 수 있음

Copy as Figma -> 피그마로 옮겨서 내가 원하는대로 수정가능

Copy as PNG -> PNG 사진파일로 복사하기 쌉가능

6/30 서비스기획 심화강의

bbborang — Mon, 29 Jun 2026 17:05:52 +0900

노코드(No-Code)란?

코드를 몰라도 만들 수 있는 개발

프로토타입 / MVP 제작

코드 없이도 UI 목업을 만들고, 클릭 가능한 프로토타입 수준 웹사이트로 시연 가능
예: “우리 서비스 랜딩페이지”를 Framer로 만들어 A/B 테스트를 돌리거나, 가짜 가입 흐름을 만들어 사용자 반응을 미리 볼 수 있음
개발 리소스 절감: 기초 설계 단계에서 UI와 UX를 확정해두고, 나중에 실제 개발 시 큰 틀을 유지 가능

간단 개인 블로그 / 포트폴리오 페이지

개인 블로그 / 포트폴리오를 쉽게, 단기간 내 제작 가능
개발자 도움 없이도 구축 및 유지보수가 가능

* framer에서 단축키 i 누르면 insert 바로 들어갈 수 있음

( 삽입 insert의 i )

CMS -> 다른페이지로 이동 (CMS를 관리하는 페이지로 화면이 전환이 된다)

플러그인은 기본 프로그램(앱)에 '연동'하여 특정 기능을 확장하거나 추가해 주는 소프트웨어

기능 확장: 프로그램의 원래 기능만으로는 부족한 부분을 타사 서비스나 추가 모듈과 연동하여 채워줍니다.
독립성: 메인 프로그램(호스트 프로그램)에 물리적으로 완전히 합쳐지는 것이 아니라, 독립적으로 실행되면서 서로 정보를 주고받는 형태로 연동됩니다.

* 원하는 기능을 찾고싶을때

맥 = Cmd(Command) + K

윈도우 = Ctrl + K

shift 누르면 -> frame 함께 선택가능

Frame 생성 및 조작법

F 키 → Frame 도구가 활성화
부모안에 자식으로 넣고싶으면 그냥 냅다 F키 / 자식 아니고 따로따로 독립적인 요소로 하고싶으면 space 누른채로 F키 (겹쳐지더라도 따로따로 독립적으로 생성됨)
드래그로 생성 → Shift로 정사각형, Alt로 중심에서 확대
shift로 여러 요소 선택 후 Ctrl (맥 -> Cmd) + Enter → Wrap with Frame(묶기)
부모 Frame 삭제: Ctrl (맥 -> Cmd) + Delete (자식은 남김) -> 자식은 생존시킨채 부모 frame만 삭제하고싶을 경우

Z 키 → Zoom 도구 활성화
Option + 클릭 → Zoom Out
Shift + 1 → 전체 보기 (Zoom to Fit)
Shift + 2 → 선택 요소 중심 보기 (Zoom to Selection)
Shift + 3 → 100% 보기 (Zoom to 100%)
Space 누른 채 드래그 → 팬 이동

대형 프로젝트에서는 줌/팬 조작이 핵심 생산성 도구

위치 속성	설명
Absolute	자유롭게 배치 가능. 기본값. 다른 요소의 흐름에 영향 없음.
Relative	Stack이나 Grid 내부에서 흐름을 따라 배치됨. Stack의 기본 위치 속성.
Fixed	뷰포트 기준으로 고정됨 (스크롤 무시).
Sticky	뷰포트 상단에 닿으면 Fixed로 바뀌는 하이브리드형.

* Stack으로 만들 수 있는 것

내비게이션 바 (가로 Stack)
카드 리스트 (세로 Stack)
버튼 내부 텍스트 정렬
콘텐츠 섹션 사이의 일관된 간격 유지

1퍼포는 온라인 마케팅 분야에서 '퍼포먼스 마케팅(Performance Marketing)'을 줄여 부르는 말입니다. 광고가 단순히 노출되는 것에 그치지 않고, 고객의 '클릭', '구매', '가입' 등 측정 가능한 행동(성과)을 이끌어내는 데 집중하는 마케팅 기법

[배달의민족] 역기획 프로젝트 개인회고

bbborang — Fri, 26 Jun 2026 17:54:15 +0900

Keep

현재 만족하고 있는 부분

프로젝트 흐름 자체는 논리적으로 잘 이어졌던 것 같다.

아프니까 사장이다 커뮤니티 최근 82건 VOC 분석을 잘했고, 분석결과를 기반으로 신규 가게로 타겟을 잘 좁혔는데 그 맥락이 자연스러웠던 것 같다.

계속 이어갔으면 하는 부분

앞으로도 리서치 많이 하면 좋을 것 같고, 뇌피셜이 아니라 근거 자료도 적합하게 잘 찾는것을 앞으로도 계속 이어가면 좋겠다.

팀프로젝트 진행하면서 팀원들과 함께 의견을 내고, 서로 설득하는 과정을 거치며 결론을 도출해내는 과정을 통해 PM적 사고를 배울 수 있었다. 앞으로도 팀프로젝트를 통해 계속 이어나갔으면 좋겠는 부분이다.

Problem

불편하게 느끼는 부분/아쉬웠던 부분

최종 문제 정의는 신규 음식점이 노출은 받지만 신뢰를 확보하지 못해 전환이 안 된다라고 정했는데,
그런데 사실 이거는 사실 배달업계에서는 이미 잘 알려진 일반적인 내용이다.
근데 앞에 VOC 분석과 리서치 내용을 분석하면
리뷰 적응 각이 기피한다거나 저평점 시 탐색 전환이 잘 안 된다라는 되게 중요한 항목들을 다 다뤘는데?
근데 문제정의에서는 오히려 되게 뭉뚱그려서 신뢰라는 단어 딱 하나로 뭉뚱그려서 문제정의를 했던 부분이 아쉬웠다.
(하지만 막 엄청 불편하진 않았다)

개선이 필요하다고 생각되는 부분

새 기능이 기존에 있는 것에서 추가하는 것이라 현업에서 선호되는 방식이다.
따라서 문제정의에서 신뢰를 더 구체적으로 정의하고 넘어가는 게 좋지 않았을까.
(너무 '신뢰'라는 단어만으로 뭉뚱그려진 느낌 - 어떤 종류의 신뢰정보가 더 부족했는지 1단계 더 깊게)
해결방안이 정보제공에만 머물러있고, 이것이 정말 신뢰를 제공하는지 검증이 안 되었다고 한다. (튜터님 피드백)

또 생각해봐야 할 점이 " 사장님이 직접 제공하는 정보가 정말로 신뢰할 수 있는가? "
KPI 지표 추측 근거 실제 업계 벤치마크나 유사 기능 사례 비교 등을 추가하면 좋지 않았을까 (튜터님 피드백)
KPI 지표 설정 자체는 잘 됐는데, 정합성 문제가 있었다.

정합성(Consistency)은 여러 데이터나 시스템의 정보가 모순 없이 서로 일치하고 올바른 상태를 유지하는 것을 의미

-> 메인을 전체가 아니라 기능을 사용한 것으로 하는 게 더 정합성이 있다.

Try

Problem에 대한 해결책

문제정의에서 신뢰라는 단어 딱 하나로 뭉뚱그려서 표현한 것이 아쉬웠으므로
이에 대한 해결책으로는 왜 신규 가게는 신뢰를 못 받는가에서 한 번 더 들어가서 예를 들어서 어떤 종류의 신뢰 정보가 특히 부족하기 때문에 그래서 신뢰를 못 받는다라고 정리를 한 단계 더 깊게 분석해보도록 하는게 좋을 것 같다.

KPI 지표 추측 근거 실제 업계 벤치마크나 유사 기능 사례 비교 등을 추가해본다.

다음 회고 때 판별 가능한 것

KPI 지표 -> 메인을 전체가 아니라 기능을 사용한 것으로 하는 게 더 정합성이 있다고 했으므로, 다음 회고 때는 기능을 사용한 것으로 KPI 지표를 설정해보면 좋을 것 같다. (다음 회고 때 판별 가능할 것 같다)

당장 실행 가능한 것

실제 업계 벤치마크나 유사 기능 사례를 비교해본다.

(데스크리서치 무조건 많이해보기)

6/18 커리어데이

bbborang — Thu, 18 Jun 2026 09:16:31 +0900

SAR 작성법

S (상황, Situation): 직면했던 과제나 배경 설명.
A (행동, Action): 문제를 해결하기 위해 취한 구체적인 행동과 본인의 역할.
R (결과, Result): 행동을 통해 얻은 정량적/정성적 성과.

직무전환하면 반드시 물어봄

왜 PM으로 왔는가?

-> 제가 이런 역량이나 강점이 있는데, 이런건 PM일을 하는데 잘할 수 있다는 방향으로 어필!

비즈니스 언어사용

채용공고와 무관한 경력사항이 있어도 간략하게라도 작성하자

-> 사회생활경험을 어필하고싶다!

회사명 / 역할 정도만 짧게 작성하기

이력서 -> 1~2page 분량으로 정리

참고)

앵커 텍스트(Anchor Text)는 웹 문서나 게시글에서 마우스로 클릭해 다른 웹페이지나 문서 내 특정 위치로 이동할 수 있는 하이퍼링크에 표시된 클릭 가능한 텍스트

불릿 포인트(Bullet point)는 문서나 발표 자료에서 여러 항목을 나열할 때 각 항목의 앞부분에 붙이는 점(•) 형태의 기호나 그 기호로 표시된 항목을 말합니다. 우리말로는 보통 '글머리 기호'라고 부릅니다.

레슨 런(Lesson-Learn, Lessons Learned)은 업무나 프로젝트를 마친 후, 그 과정에서 얻은 '교훈'이나 '배운 점'을 뜻하는 비즈니스 용어입니다.

케이스 스터디(Case Study, 사례 연구)는 특정한 하나의 대상, 사건, 또는 조직에 대해 심층적으로 분석하고 조사하는 연구 방법이자 학습 과정입니다. 단순한 이론 습득을 넘어, 현실의 구체적 사례를 통해 문제의 원인을 파악하고 해결책을 도출하는 데 중점을 둡니다. -> 포트폴리오 기반 면접질문

이걸 왜 했어요?
WHY에 대한 질문

지표를 왜 이렇게 설정했어요?

지표설정에 대한 질문 (이또한 WHY질문)

왜 환경공학 나오셨나요? (기타질문사항)

회사의 Culture Fit 을 확인하는 사항

회사에서 불합리한 요구사항이 왔을때 어떤식으로 대처를 할건가요?

ex) 본인은 개선안 A로 해야된다고 생각을 하는데, 팀장이나 대표가 윗선들이 무조건 개선안 B로 하라고 밀어붙인다

근데 B로 하라는것에 대해서는 명확한 근거도 없고 객관적인 이유도 없다. 근데 그냥 밀어붙이는 상황

그때 너는 어떻게 할 것인가?

-> 최대한 합리적으로 답변함 (감정빼고)

데이터가 이렇게 말을 하고있기 때문이다 / 객관적인 근거로

사실은 대표님이나 팀장님 말을 따르길 바랄 수도 있고~ 아님 소신대로 말하기를 바랄 수도 있고~

=> 사실은 질문자는 이미 "답을 정하고" 물어본것

=> 이미 답은 정해져있지만 내가 그 답을 알 수가 없음 / 의중을 알 수 없는 질문

측정방법은 주로 어떤방법으로 썼나요?

GA를 쓰려고했다~

어떤 대시보드를 활용했나요?

왜 지표는 이렇게 설정했나요?

왜 수치는 20%으로 설정했나요? 20 으로 설정한 이유가 있나요? 왜 하필 20 인가요?

-> 수치설정에 대한 객관적인 근거 필요

실무 인터뷰

-> 포트폴리오 기반

80 % 포트폴리오 기반

20 % 아이스브레이킹 (기타사항들)

AI를 활용해도

하나하나씩 이게 왜 이랬지?

WHY?에 대한 질문에 대해서 미리미리 생각해놓기

PRD -> 단어 하나하나 되게 꼼꼼하게 작성하기

모든 이력서 모든 포트폴리오에 작성했던 단어에

그 단어 하나하나에 WHY?를 설명할 수 있어야함

기여도가 낮은 프로젝트는 포트폴리오에 웬만하면 넣지말자!!!

(크리티컬한 부분임)

PM에서 말하는 커뮤니케이션 역량은?

내가 가지고있는 생각과 논리를 얼마나 상대에게 효과적으로 설명할 수 있느냐?

얼마나 잘 구조화해서 말해서 상대를 설득할 수 있느냐?

(단순히 사이좋게 지내거나 화합하거나 그런게 아님)

강점 + 지원동기 -> 1분30초정도 준비해서 가져가기

핸드폰 꺼내보세요

본인이 가장 많이 쓰는 어플 뭐예요?

올리브영 / 쿠팡이요

그럼 거기 들어가세요

거기 홈화면 딱 보시고

이 홈화면에서 문제정의 3개 하시고

그것을 어떤방식으로 해결하고싶은지 말해보세요

내가 자주 쓰는 메뉴인데, 내가 자주 쓰는 카테고리인데, 왜 이렇게 폰트가 작을까?

왜 이렇게 폰트를 작게 만들어놨을까? 그 이유가 있을까?

-> 항상 스크린샷 해두고

이 화면 왜이렇게 구성했을까? 하는생각

지원동기 -> 진짜 중요 / 준비 많이 해야됨

방어기제 = 감정이 나와버린다

염소 = 엄청 떨어서 염소 ㅋㅋㅋㅋㅋ

시뮬레이션 엄청하기]\

채용사이트 (자사 사이트) -> 양질의 인재가 많이 지원함

(회사 자체 채용사이트)

잡 포털 (채용플랫폼) -> 허수지원자가 많다

공식적으로 커피챗 신청이 가능한 경우

잡 포털에서 채용공고를 봤다고하더라도, 최종지원은 웬만하면 자사 사이트에 들어가서 직접 지원하기

이런일을 합니다

이런역량이 있으면 좋아요

우대사항

-> 1번째로 나온 내용이 제일 중요하다 (1번째로 쓰여진 문장에 집중!!!!!)

B2B -> 고객 요구사항에 직접적으로 반응하는게 매우 중요함

바텀업(Bottom-up) 방식은 하위 부서의 실무진이나 개별 요소에서 시작해 아이디어와 데이터를 모으고, 이를 바탕으로 상위 의사결정을 내리거나 전체 구조를 완성하는 상향식 접근 방법을 의미합니다.

-> 밑에서부터 위로 올라가는 "상향식" 접근방법

AI를 잘활용하려면 -> 문제해결능력이 중요하다 / 어떻게 AI를 활용하는지 알아야한다

문제해결력

6/17 아티클카타

bbborang — Tue, 16 Jun 2026 23:49:11 +0900

남보라 아티클 (개인)

역량만 있어선 안 된다… IT 프로젝트가 여전히 실패하는 8가지 이유

이전과 같은 대규모 실패를 피하기 위해 범위 확장, 폭포수 방법론(Waterfall Methodology), 반복 개발을 위한 긴 타임라인, 애자일 접근 방식, 멀티위크 스프린트 등의 업무 방식을 도입해 왔다.

1. 프로젝트 관리 전문성 부족
직원들은 종종 추가 업무를 맡는다. 때로는 IT 직원이 프로젝트를 이끌어야 하는 경우도 있다.

직원들이 프로젝트 관리자(PM) 역할을 수행한다고 해서 전문 지식, 교육 또는 경험이 제대로 갖춰진 것은 아니다. 프로젝트를 관리하거나 추가 프로젝트 관리 작업을 완수하는 데 필요한 사항을 학습할 시간도 충분히 주어지지 않는다.

몬타나 대학의 CIO인 잭 로스밀러는 “조직은 아무 교육도 받지 않은 사람이 프로젝트를 운영할 수 있다고 기대한다. 또는 풀타임으로 다른 일을 하는 관리자에게 프로젝트 관리까지 맡기기도 한다”라고 말했다.

로스밀러는 자신이 속한 IT 부서에서 이러한 접근 방식을 취하면 어떤 결과를 초래하는지 알고 있다고 말했다. 그는 “과거 수백 개의 서로 다른 프로젝트가 진행돼야 했을 때, 조직은 관리자가 이를 효율적으로 관리하며 운영할 것으로 기대했다. 프로젝트 관리를 전담하는 부서가 있었다면 훨씬 더 나은 성과를 거둘 수 있었을 것이다”라고 전했다.

로스밀러는 최근 IT 부서에 프로젝트 관리자 2명을 고용해 문제를 해결하고 있다. 로스밀러는 숙련된 프로젝트 관리 전문가가 합류한 뒤 개선 효과가 나타나고 있으며, 특히 수고를 줄이고 프로젝트 배포를 더 효율적으로 하는 데 도움이 되고 있다고 설명했다.

그는 숙련된 프로젝트 관리자가 리소스를 모으고 일정을 조정하고 직원 일정을 조율하고, 모두가 같은 방향으로 나아가도록 유도하는 데 더 능숙하며, 여러 프로젝트에 걸쳐 이를 수행할 수 있기 때문이라고 말했다. 그에 따르면 프로젝트 관리자는 프로젝트가 예상 목표를 달성하기 위해 필요한 거버넌스를 구현할 수 있으며, 범위 내 비용과 일정이 늘어나지 않도록 하는 데 더 능숙하다.

2. 경영진의 지원이 거의 또는 전혀 없는 경우
IT 프로젝트를 방해하는 또 다른 문제는 최고 경영진의 무관심이다. 베테랑 프로젝트 리더들은 이러한 시나리오가 생각보다 자주 발생한다고 말했다.

프로젝트 관리 전문가이자 PMI의 북미 지역 운영 관리자인 칼라 아이뎀은 “회의나 프로젝트 현황 보고에서 경영진이 ‘왜 이 일을 하는가’라고 물은 적이 있다. 우리가 가려는 방향의 중요성을 제대로 이해하지 못한 것이다”라고 말했다.

아이뎀은 프로젝트에 비즈니스 스폰서가 있는 경우에도 경영진의 지원이 부족할 수 있으며, 이는 해당 프로젝트가 특정 부서의 우선순위일지라도 조직의 목표와는 일치하지 않음을 시사한다고 말했다.

이러한 경우에는 재조정할 필요가 있다.

그는 “경영진에게 물어봐야 할 수도 있다. ‘여러분 앞에 놓인 모든 사실을 고려할 때 이 프로젝트를 진행해야 할까요, 아니면 하지 말아야 할까요?’ 때로는 어떤 이유로 인해 진행할 수 없는 경우도 있지만, 결정을 내려야 한다”라고 말했다. 그는 경영진의 지원이 자금, 인력, 관심 자원을 확보하는 수단이기 때문에 성공에 매우 중요한 요소라고 덧붙였다.

3. 비즈니스 스폰서의 무책임
마찬가지로 프로젝트의 스폰서가 기술 프로젝트 성공에 대한 책임을 지지 않고 IT 부서에 모든 부담을 떠넘기면 프로젝트가 실패로 끝날 수 있다.

테 우는 “훌륭한 프로젝트 리더십은 비즈니스 사례를 만들어 본 사람이 스폰서가 돼 프로젝트가 현실적으로 수행되는지 확인하고, 지지자가 돼 주는 것에서 시작한다”라고 말했다.

경영진과 같은 비즈니스 스폰서는 프로젝트의 사업적인 이유를 명확히 하고, 예상되는 장점을 설정하고, 목표를 달성하기 위해 리소스를 모으는 데 중요한 역할을 한다. 또한 이들의 지원은 직원들에게 프로젝트 중요성을 알리는 신호가 되기 때문에, 신기술 채택과 관련 프로세스 변경을 촉진하는 데 도움이 된다고 테 우는 덧붙였다.

4. 비즈니스 스폰서의 참여 부족
비즈니스 스폰서는 지원과 정보를 제공하며 장애물과 병목 현상을 제거하고, 문제를 제기해 신속하게 해결할 수 있도록 돕고, 성공을 지지해 앞으로의 변화에 대한 추진력과 흥미를 높일 수 있다고 아이뎀은 말했다.

스폰서가 제 역할을 하지 않으면 이러한 이점도 사라진다. 아이뎀은 그런 일을 실제로 겪었다고 말했다.

한때 그녀는 복잡한 다중 위치 소프트웨어 구현 작업을 꾸준히 진행하고 있었다. 다음 단계를 위해 지역 부서를 한데 모아야 했고, 스폰서의 도움을 받아야 했다. 하지만 스폰서는 문제 해결에 참여하지 않았다. 일부 운영 부서는 무슨 일이 일어나는지 알 수 없었고, 일부는 왜 참여해야 하는지 이해하지 못했다.

아이뎀은 “정보가 순차적으로 전달되지 않고 일부 영역에서 반발이 있었다”라고 말하며, 이러한 상황이 프로젝트의 추진력을 위태롭게 했다고 전했다.

아이뎀은 스폰서가 다른 큰 이슈로 인해 프로젝트에서 멀어졌으며, 그 결과로 관련 지역에 프로젝트 정보를 전달하는 데 제대로 주의를 기울이지 않았다고 언급했다. 그녀는 “스폰서가 프로젝트에 집중해야 할 때 다른 우선순위가 너무 많았다. 그래서 분명히 해야 했다. 조직으로서 이 프로젝트가 최우선 순위라고 분명히 말해야 했다”라고 전했다.

프로젝트가 무산되는 것을 막기 위해 아이뎀은 후원자와 더 많은 일대일 미팅을 예약해 관계를 강화했다. 또한 프로젝트 요구 사항에 대해 더 직접적으로 소통할 수 있도록 해 후원자가 다시 집중하고 프로젝트를 이어나갈 수 있도록 했다.

5. 모든 이해관계자가 참여하지 않을 때
IT 프로젝트 관리자 크리스타 필립스는 어느 다국적 대기업이 회사 전체에 신기술을 구현했으나 진행 중인 작업을 한 부서에서 전혀 인지하지 못했던 사례를 언급했다. 특정 부서가 모든 계획 및 프로젝트 프로세스에서 제외된 사례다.

필립스는 “프로젝트 리더가 어떻게 놓쳤는지는 모르겠지만, 한 부서를 완전히 놓쳤다. 그래서 시스템이 가동됐을 때 해당 부서 직원들은 ‘이게 뭐야’라고 생각했다. 이로 인해 프로젝트의 기회를 일부 누락했다”라고 말했다.

필립스는 프로젝트 부서가 일반적으로 전체 부서를 간과할 일은 없지만, 프로젝트 프로세스에 포함해야 하는 이해관계자를 전부 식별하고 포함하지 못하는 경우도 있다고 말했다. 그러면 중요한 요구 사항, 고려해야 할 규정, 활용 기회를 놓칠 가능성이 있다. 필립스는 콜로라도 PMI의 파이크스 피크 지역 지부 회장을 맡고 있다.

6. 리소스가 충분하지 않거나 올바르지 않은 경우
일부 프로젝트 리더는 오늘날 IT 프로젝트가 실패하는 또 다른 이유로 ‘더 적은 비용으로 더 많은 성과를 내야 한다’는 기대치가 만연한다는 점을 꼽았다. 이 사고방식은 프로젝트 부서가 작업을 제시간에 완료하는 데 필요한 리소스를 부족하게 만든다.

필립스는 “모두 수익에 대해 신경을 기울이고 있다. 그 이면에는 소수의 사람이 많은 일을 하기를 기대하는 측면도 있다”라고 언급했다.

필립스에 따르면 직원이 여러 프로젝트에 동시에 배정되는 경우가 많으며, 기존 업무에 더해 프로젝트 업무까지 맡는 경우도 있다. 그렇게 되면 직원들은 업무에 집중하지 못하고 여러 방향으로 끌려 다니게 된다.

어떤 이들은 프로젝트 관리자가 성공에 필요한 비용, 인재, 시간을 과소 할당할 경우 어떤 결과가 초래되는지 잘 알고 있으면서도, 기업 리더가 비용과 작업 완료에 필요한 시간을 과소평가하거나 적절한 인재를 팀에 할당하지 않는다고 말하기도 한다(교육을 받지 않았거나 경험이 없는 직원이 업무에서 필요한 기술을 습득할 것이라고 생각한다).

노련한 프로젝트 리더들에 따르면, IT 프로젝트 관리자와 CIO는 후원자와 최고 경영진이 필요 리소스, 자원 및 일정에 대해 현실적인 정보를 얻을 수 있도록 지원해야 한다. 하지만 이는 상당히 까다로운 작업일 수 있다.

이를 위해서는 포트폴리오 관리 프로그램을 구현해 현재 진행 중인 작업에 대한 가시성을 확보하고, 리소스를 과소 할당할 수 있는 프로젝트 사일로를 허물어야 한다고 프로젝트 리더들은 조언했다.

테 우는 “포트폴리오 관리에 중점을 두면 생산성 문제는 상당 부분 해결할 수 있다. 더 적은 일을 하면서도 제대로 해내는 것, 이것이 포트폴리오 관리의 핵심이다”라고 말했다.

7. 대면 협업의 부족
테 우에 따르면 원격 근무로의 전환은 프로젝트 작업을 전 세계로 확장할 수 있는 가능성을 불러왔지만, 가상 업무 환경은 프로젝트 운영에 있어 몇 가지 문제점을 야기할 수 있다.

그는 우선 조직에서 더 어려운 문제를 해결할 때 비대면 근무 부서가 모이는 데 어려움을 겪는다는 사실을 발견했다. 그는 “모듈 작업을 처리하는 데 있어서는 가상 환경이 좋다고 생각한다. 하지만 크고 복잡한 문제를 해결할 때는 ‘줌’을 통해 할 수 있는 일이 많지 않다”라고 전했다.

그는 또한 일부 부서가 가상 업무 환경에서 유대감을 형성하는 데 어려움을 겪는 것을 봤다면서, “(비대면 근무로 인해) 인간적인 유대감을 희생하게 된다”라고 덧붙였다.

따라서 작업 시간은 더 길어질 수 있으며, 얼굴을 맞대고 일하면 한 시간에 해결할 수 있는 문제가 가상 환경에서는 90분이 걸린다고 테 우는 말했다. 또한 팀이 물리적으로 한 공간에 있을 때는 빠르고 원활하게 진행되던 핸드오프도 가상 환경에서 조율하기에 많은 시간이 소요될 수 있다.

그는 “사람들은 동일한 효율성을 얻기 위해 더 많은 시간을 소비하고 있으며, 인간 관계가 소원해지기 시작한 것 같다”라며, 특히 신입 직원들이 롤 모델이나 본받을 만한 업무 패턴을 지켜보는 것처럼 사무실에서 이뤄지는 비공식적 멘토링 및 학습 기회를 놓칠 수 있다고 지적했다.

그는 이러한 역학 관계로 인해 ‘협업과 소통을 위해 훨씬 더 많은 업무와 시간을 투자하는’ 프로젝트 관리자에게 더 많은 업무가 가중된다고 말했다. 이 문제에 대해 아직 해결책을 찾지 못했다고 그는 덧붙였다.

8. 단절된 핸드오프
프로젝트가 프로덕션으로 전환되고, 프로젝트 관리자가 자리를 옮기고, IT 이니셔티브가 가치를 발휘할 것으로 기대받는 시점이 있다.

테 우는 조직이 이 단계에 있을 경우 프로젝트와 프로젝트에 남아있는 문제가 제대로 관리되지 않으며, 이것이 책임 분담의 단절로 이어져 실패를 낳는다고 지적했다.

그는 “만약 비즈니스 사례가 한 당사자가 되고, 프로젝트 관리자가 다른 당사자를 자처하며, 프로젝트의 비즈니스 사례와는 더 멀리 떨어진, 프로젝트의 결과를 관리하는 이들이 또 다른 당사자가 된다면 연결이 얼마나 단절돼 있는지 볼 수 있다”라고 말했다.

이러한 단절은 기회를 놓치고, 잘못된 방향으로 가고, 어긋난 의사 소통으로 이어져 최종 결과물이 차선책에 그치게 할 수 있다.

그는 애자일과 데브옵스(DevOps) 방법론을 사용하는 조직에서도 단절은 발생할 수 있다고 언급하며 “이는 한 쪽에서 다른 쪽으로 물을 운반하는 다른 방법일 뿐이다. 데브옵스는 변화를 빠르게 처리할 수 있지만, 그 변화가 올바른 변화인지, 투자수익(ROI)을 충분히 제공하는지 여부를 확인하는 것은 다른 문제다”라고 설명했다.

테 우를 비롯한 전문가는 이러한 상황에 대응하기 위해, 프로젝트 작업은 물론 구현 및 채택 단계 전반에 걸쳐 프로젝트의 비즈니스 사례와 결과물을 지속적으로 연결하는 관리 역량과 강력한 프로젝트 거버넌스가 필요하다고 말했다.

1. 오늘날 IT 프로젝트 실패의 정의

과거에는 시스템이 완전히 작동하지 않는 기술적 재해를 의미했으나, 현재는 목표 시점을 놓치거나 조직이 기대한 이점(수익성, 사용자 참여 등)을 완전히 제공하지 못하는 것을 의미합니다. (KPMG 조사에 따르면 기술 임원의 51%가 디지털 혁신을 통해 성과를 얻지 못했다고 응답)

2. IT 프로젝트 실패의 8가지 주요 원인

① 프로젝트 관리 전문성 부족: 전담 PM 없이 일반 직원이나 타 부서 관리자에게 프로젝트 관리를 겸임하게 하여 거버넌스 및 리소스 조율의 효율성이 떨어집니다.
② 경영진의 지원 부족: 최고 경영진의 무관심과 이해 부족으로 인해 프로젝트 성공에 필수적인 자금, 인력, 관심 등의 자원을 확보하기 어려워집니다.
③ 비즈니스 스폰서의 무책임: 프로젝트의 사업적 타당성을 방어하고 리소스를 모아줄 스폰서가 책임을 IT 부서에만 전가할 때 실패 확률이 높아집니다.
④ 비즈니스 스폰서의 참여 부족: 스폰서가 다른 우선순위에 밀려 프로젝트에 집중하지 못하면, 부서 간 반발이나 소통 부재로 프로젝트의 추진력을 잃게 됩니다.
⑤ 이해관계자 식별 및 참여 누락: 특정 부서나 핵심 이해관계자를 계획 단계에서 제외하면, 가동 후 시스템 외면이나 중요한 요구사항 및 규정 누락 등의 문제가 발생합니다.
⑥ 리소스의 과소 할당 (비현실적 기대): ‘더 적은 비용으로 더 많은 성과’를 기대하는 분위기 속에서 인재, 비용, 시간이 부족해지고 직원들이 여러 업무에 치여 집중력을 잃습니다. (포트폴리오 관리를 통한 사일로 제거가 대안으로 제시됨)
⑦ 대면 협업의 부족 (원격 근무의 한계): 가상 업무 환경은 복잡한 문제 해결 시 소통 시간을 늘리고 인간적 유대감을 희생시키며, PM의 조율 업무 부담을 가중시킵니다.
⑧ 단절된 핸드오프 (인수인계 문제): 기획자, 프로젝트 관리자(PM), 최종 운영자 간의 책임과 소통이 단절되면 애자일이나 데브옵스를 도입하더라도 최종 결과물이 실제 ROI(투자수익률)로 이어지지 못합니다.

핵심 결론: 오늘날의 IT 프로젝트 성공을 위해서는 단순히 기술을 구현하는 것을 넘어, 숙련된 PM 배치, 경영진 및 스폰서의 적극적인 참여, 포트폴리오 관리를 통한 현실적인 리소스 배분, 그리고 비즈니스 가치와 결과물을 끝까지 연결하는 강력한 거버넌스가 필수적입니다.

1. 아티클 정보

제목 : 역량만 있어선 안 된다… IT 프로젝트가 여전히 실패하는 8가지 이유
작성자(저자) : Mary K. Pratt

2. 핵심 내용 요약

이 아티클의 주요 메시지 : 오늘날 IT 프로젝트의 실패는 시스템 마비 같은 기술적 문제가 아니라 ‘기대했던 비즈니스 가치(ROI)를 창출하지 못하는 것’으로 정의가 변했으며, 이를 해결하기 위해서는 전문 PM 도입, 경영진의 적극적 참여, 현실적인 리소스 배분 등 전반적인 거버넌스 개선이 필요하다.
핵심 키워드 : 비즈니스 가치(ROI), 실패의 재정의, 프로젝트 관리 전문가(PM), 비즈니스 스폰서, 포트폴리오 관리, 핸드오프 단절

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

읽으면서 가장 흥미로웠던 부분 : 원격 근무(가상 환경)가 모듈형 작업에는 유리할지 몰라도, 크고 복잡한 문제를 해결할 때는 오히려 소통 시간을 늘리고 인간적 유대감을 떨어뜨려 프로젝트 성공의 걸림돌이 될 수 있다는 분석이 흥미로웠다.
이전에는 알지 못했거나 새롭게 배운 내용 : 애자일(Agile)이나 데브옵스(DevOps) 같은 최신 방법론을 도입하더라도, 기획-개발-운영 간의 '핸드오프(인수인계) 단절'과 비즈니스 스폰서의 책임 방기가 발생하면 결국 속도만 빠를 뿐 알맹이 없는(수익성 없는) 프로젝트로 실패하게 된다는 점을 새롭게 배웠습니다.

4. 나의 한 문장 요약

이 아티클을 한 문장으로 요약하면? 오늘날 IT 프로젝트의 실패는 기술이 아닌 비즈니스 목표의 실종에서 비롯되므로, 경영진의 책임있는 참여와 체계적인 리소스 관리를 통해 기대했던 실제 가치를 증명해내야 한다!!!!!!