TIL

회고

📅 작성일: 2026-06-15 | 이름: 박제이

STEP 1. 프로젝트 핵심 요약 (Fact)

• 프로젝트명: 바통(BATONG) — 소기업 인수인계 태스크 관리 서비스 MVP

• 나의 역할: 서비스 기획 전반 (PRD 작성, 기능명세서, 사용자 리서치 분석, 공식 통계 분석, PPT 문서화, Figma Make 인수자 화면 프롬프트 작성, 시연 대본 작성)

• 내가 담당한 핵심 지표/가설: 소기업(50인 미만) 인수인계 만족도가 2.1점(5점 만점 기준, 전체 규모 중 최저)에 머물고 있는 것은 자료의 부재가 아니라 프로세스의 부재 때문이다. 인계자가 주차별 태스크·진행률·Q&A를 체계적으로 관리하면 인계자의 반복 교육 부담이 줄고 인수자의 정보 과부하와 질문 부담이 감소하여, 현재 51.1%의 인계자가 즉흥·구두 중심으로 진행하는 인수인계 방식이 표준화된 체계로 전환될 것이다.

• 사용한 도구: Claude, Figma Make, DBeaver

STEP 2. PM 역량 한 조각 발굴 (Action)

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

문제 정의의 출발점은 "왜 인수인계가 실패하는가?"였다.

처음에는 자료가 없어서라고 생각하기 쉽다.
그런데 리서치를 파고들수록 정반대의 사실이 나왔다.
소기업에도 업무 문서, 엑셀, 노션, 드라이브 등 인수인계 자료는 이미 존재한다.
문제는 그 자료가 '보관'만 될 뿐, '활용'되지 않는다는 것이었다.

여기서 핵심 인사이트를 잡았다: "자료는 있지만, 교육은 없다."
무엇을 어떤 순서로 학습해야 하는지, 어디까지 이해했는지,
어떤 업무가 완료됐는지를 관리하는 체계가 없기 때문에
인계자는 매번 같은 설명을 반복하고, 인수자는 정보 과부하에 빠진다.

이 구조적 문제를 데이터로 뒷받침하는 수치도 찾아냈다.
인계자의 51.1%는 자료가 있어도 "즉흥적으로 진행"한다고 답했고,
인계자의 46.7%는 인수자의 이해 수준을 파악하기 어렵다고 했으며,
인수자의 30.6%는 질문 자체에 부담을 느끼고 있었다.

이 세 가지 수치가 맞물리는 지점에서 가설이 완성됐다.
태스크 체계 + 진행률 가시화 + 질문 시스템을 하나의 서비스로 묶으면
세 가지 문제를 동시에 해소할 수 있다.

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

가장 고민했던 선택은 '왜 50인 미만인가'를 납득 가능하게 증명하는 것이었다.

단순히 "소기업이 인수인계가 부족하다"는 건 인상적인 주장이지, 근거가 아니다.
규모별 데이터를 비교해서 50인 미만이 유독 문제가 집중된 집단임을
숫자로 보여야 했다.

결과적으로 찾아낸 근거는 네 가지였다.
표준 커리큘럼 보유율 7% — 전체 규모 중 최저.
즉흥·구두 중심 인수인계 비율 66% — 전체 규모 중 최고.
인수인계 만족도 평균 2.1점 — 전체 규모 중 최저.
낮은 만족도 응답 비율 73% — 전체 규모 중 최고.

모든 지표에서 최악이었다. 이건 표본이 작아서 생긴 우연이 아니라
HR 전담 인력 자체가 없는 구조적 특성에서 비롯된 결과였다.

이 데이터를 확보하고 나서야 타깃 설정이 "50인 미만이 가장 문제가 크다"는
감이 아니라 근거가 되었다.
데이터가 없으면 선택이 되고,
데이터가 있으면 전략이 된다는 걸 이번에 실감했다.

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

이번 프로젝트에서 내가 맡은 파트 중 하나는 기능명세서였다.
개발자 출신이라 기능명세서 자체는 낯설지 않았지만,
팀원분들에게는 달랐다.

"기능명세서를 어떻게 써야 하는지 모르겠어요", "이게 맞는 형식인가요?"라는 말이 많이 나왔고
처음 접하는 분들은 뭘 어디까지 적어야 하는지, 화면 단위로 나눠야 하는지도 어려워하셨다.

이 상황에서 내가 한 건 내가 아는 것을 최대한 풀어서 설명하는 것이었다.
기능명세서는 개발자가 구현할 수 있을 만큼 구체적이어야 한다는 것,
클릭 시 어떤 상태로 바뀌는지, 예외 케이스는 무엇인지까지 담아야 한다는 것.
그 기준을 먼저 공유하고 나서 각자 작성한 내용을 같이 검토하며 보완해나갔다.

내가 현업에서 당연하게 써왔던 방식이 누군가에게는 전혀 낯선 영역이라는 걸 실감했다.
알고 있는 것과 설명할 수 있는 것은 다르다.
이번 경험이 그 차이를 좁히는 계기가 됐다.

STEP 3. Lesson Learn & Next Step

이번 프로젝트에서 가장 성장한 부분:

암묵적으로 알고 있던 문제를 수면 위로 끌어올리는 과정

인수인계가 문제라는 건 많은 사람이 느끼지만 아무도 건드리지 않는 영역이었다.
"다들 그냥 그렇게 하는 거 아닌가?"라고 넘어가기 쉬운 문제였다.

이번 프로젝트에서는 그 암묵적인 불편함을 실제로 설문조사하고,
공식 통계 데이터를 찾아서 수치로 증명하는 과정을 거쳤다.
"다들 힘들다고 느낀다"는 감에서 멈추지 않고,
"인계자 51.1%가 즉흥적으로 진행하고, 만족도는 2.1점이며,
이게 50인 미만에서 가장 심각하다"는
측정 가능한 진단으로 만들어낸 것이다.

문제가 크다는 걸 아는 것과, 그게 얼마나 큰지를 증명하는 것은 완전히 다른 작업이다.
막연히 존재하던 문제에 이름과 숫자를 붙이는 경험이 이번 프로젝트에서 가장 의미 있었다.

가장 아쉬웠거나 다음엔 다르게 해보고 싶은 부분:

이번 프로젝트에서 나는 기능명세서 작업에 집중하느라
문서화 작업에 많이 참여하지 못했다.
특히 한 팀원분이 회의 내용, 결정 과정, 논의 흐름을 하나하나 꼼꼼하게 기록해두셨는데,
그 덕분에 나중에 전체 흐름을 되짚을 때 혼선이 없었다.

나는 평소 중요하다고 판단한 것만 기록하는 편이었는데,
중요한 것만 남기면 맥락이 사라진다는 걸 그때 실감했다.

앞으로는 흐름을 기록하는 습관을 기르고자 노력해야겠다.

다음 프로젝트에 가져가고 싶은 나만의 원칙:

1. 흐름을 기록하는 습관을 들이자: 중요한 것만이 아니라,
전체 맥락이 담기도록 기록한다.

2. 내가 아는 것을 잘 설명해보자: 알고 있는 것과 설명할 수 있는 것은 다르다.
익숙한 것일수록 더 의식해서 풀어 설명한다.

TIL - PM이 알아야 할 Figma 활용법

참고 아티클

• AI in Product Management | Figma
• UX for Product Managers | Figma
• How the Figma PM team builds products | Figma Blog

핵심 개념

Figma는 PM에게 단순한 디자인 툴이 아니다. PRD가 길어지고 피드백이 느려지며 정렬이 늦어지는 전통적인 워크플로우의 한계를 극복하기 위해, PM은 Figma를 통해 아이디어를 실제 프로토타입으로 빠르게 전환할 수 있다.

PM을 위한 Figma 핵심 활용 포인트

1. FigJam으로 리서치 & 아이데이션

FigJam을 통해 유저 저니 맵핑, 비동기 브레인스토밍, 리서치와 디자인 작업을 하나의 공유 공간에 연결할 수 있다.

2. Figma Make로 빠른 프로토타이핑

유저 인터뷰 노트를 FigJam에 붙여넣고 AI로 정리 → Figma Make로 클릭 가능한 프로토타입 생성 → Figma Slides로 스테이크홀더 리뷰까지 연결되는 흐름이 핵심이다. 모든 결정이 원본 리서치와 연결되어 트레이서빌리티가 확보된다.

3. 피드백은 문서가 아닌 프로토타입으로

문서나 스펙에만 의존하지 말고, 공유 프로토타입에서 여러 방향과 플로우를 테스트하면 팀 전체가 훨씬 빠르게 얼라인된다.

실무 팁

PM은 AI를 지름길이 아닌 enabler로 활용해야 한다. 품질, 단순성, 사용자 경험을 최우선으로 두고 AI를 제품에 통합하는 것이 중요하다.

오늘 적용해볼 것

PPT 문서화 작업 전에 FigJam으로 전체 플로우를 먼저 시각화해보고, 팀원과 공유해서 빠른 피드백 루프 만들기

회고

어제 기능명세서와 PRD 제출을 완료하고 앞으로의 계획을 세웠다. 남은 작업은 PPT 제작과 개발 결과물을 받은 후 수정안 작성이며, 우선 문서화를 먼저 한 뒤 PPT 제작에 들어가기로 했다.

오전에 기능명세서를 보완한 후, 오후에 개발 튜터님께 피드백을 받는 시간을 가졌다. 튜터님께서 1기부터 함께해오셨는데, 지금까지 본 기능명세서 중 가장 잘 쓴 것 중 하나라는 칭찬을 해주셨다. 현업 경험을 살려 주도적으로 작성했지만, 사실 좋지 않은 피드백을 받으면 어쩌나 하는 걱정이 있었는데, 결과적으로 좋은 피드백을 받아 정말 다행이었다. 믿고 맡겨주신 팀원분들 감사함니다!

우선순위와 선택순위 페이지를 나눠서 작성했는데, 튜터님께서 모든 페이지를 구현할 수 있고 DB 연결도 가능할 것 같다고 하셨다. 추가로 AI 기능을 넣어보면 좋겠다는 제안도 해주셨고, 개발 공수가 크게 들지 않는다고 하셨다. 현업에서 협업할 때는 AI API가 지금만큼 발달하지 않아 써본 경험이 없었고 어렵게 느껴졌는데, 생각보다 어렵지 않다는 말을 듣고 앞으로의 프로젝트에서 AI를 적극 활용해봐야겠다는 생각이 들었다.

TIL - 기능 명세서 잘 작성하는 법

📎 참고 아티클

• 7년차 PM이 알려주는 기능명세서 잘 쓰는 방법 (브런치)
• 개발자에게 사랑받는 기능 명세서 작성 가이드 - 실무용 (EdrawSoft)

기능 명세서란?

개발자가 구현해야 할 기능과 그 동작 방식을 상세하게 기술한 문서.
단순히 개발자와의 소통 도구가 아니라, 기획 → 개발 → 테스트 전 단계에 영향을 미치는 핵심 문서다.
잘못 작성하면 프로젝트 전체가 뒤틀릴 수 있다.

"기능 명세서를 잘 작성하는 사람은 글을 많이 쓰는 사람이 아니라, 기능을 가장 쉽게 이해시키는 사람이다."

잘 쓰는 법 핵심 3가지

1. 명확하게 쓰기

• 모호한 표현은 개발자가 잘못 이해하는 원인이 된다.
• 나쁜 예: "사용자는 게시물을 작성할 수 있다"
• 좋은 예: "사용자는 제목, 본문, 카테고리를 입력한 후 '작성' 버튼을 클릭하여 게시물을 작성할 수 있다"
• 기능의 입력 / 출력 / 동작 방식을 구체적으로 기재할 것

2. 우선순위 정하기

• 모든 기능이 같은 중요도를 가지지 않는다.
• 핵심 기능(로그인, 결제 등)을 먼저 정의하고, 부가 기능(통계, 대시보드 등)은 후순위로
• 필수 화면 / 선택 화면을 구분하고, 각각에서도 우선순위를 매기면 더 체계적

3. 협업으로 완성하기

• 기능 명세서는 혼자 쓰는 문서가 아니다.
• 기획자, 디자이너, 개발자가 함께 검토하고 의견을 반영해야 완성도가 높아진다.
• 작성 중간에 팀원들과 공유하고 수정하는 과정이 필수

실무 팁

• 텍스트만 나열하지 말고, 다이어그램이나 Figma 시각화를 함께 첨부하면 이해도가 훨씬 높아진다
• 기능을 유닛 테스트 가능한 단위로 쪼개면 개발자가 바로 구현에 들어갈 수 있다 (제대로 된 명세서는 100개 이상의 명세가 나오기도 함)
• 불필요한 기능은 과감히 제거하기 → MVP라면 더더욱
  
  
  
  
  
  

  회고

  팀 과제 최초 야근의 날.. 오늘은 목표했던 PRD와 기능 명세서를 제출하는 날이었다. 문서화 능력자 분이 PRD 작성을 맡아주셨고, 나는 이전 실무에서 기능 명세서 작성 경험이 있어 기능 명세서를 주로 맡아 작업을 진행했다.

MVP이기 때문에 최소한의 기능만 선택해서 결과물이 빠르게 나올 수 있도록 목표를 잡고 기능 명세서를 작성했다. 필수 화면단과 선택 화면단을 나누었고, 각각에서도 우선순위를 정해 보기 편한 구성을 최우선으로 생각했다.

오후에 킥오프 회의를 했을 땐 튜터님께 긍정적인 피드백을 받아서 기분이 좋았다! 확실히 인수인계 아이디어는 좋은 것 같다. (팀원 최고!) 다만 B2B 서비스라 영업이 중요할 것 같고, 반드시 이득이 된다는 걸 어필하는 과정이 필요하다고 하셨다. 정량적인 데이터를 많이 내세워야겠다는 생각을 했다.

이후 기능 명세서를 작성하느라 11시까지 야근을 했다... 내가 생각한 방향대로 작성하다 보니 어쩌다 주도하게 됐는데, 팀원분들이 너무 잘 따라주셔서 정말 감사했다.. 감사합니다..

TIL

사무직 중 온보딩 3개월 이상 걸리는 업종/직무

📰 인수인계 적정 기간 - 스텝하우 "IT, 컴플라이언스, 재무 등 전문성이 높은 업무는 최소 2개월 이상 권장" "중간관리자·핵심 프로젝트 담당자는 최소 4주 이상, 실질적으로는 훨씬 더 걸림"

공통적으로 오래 걸리는 이유 3가지

1. 암묵지 — 문서화가 안 돼 있다

"하던 사람만 아는 일"이 많고, 구두로만 전달되다 보니 후임자가 재구성하는 데 시간이 걸린다.

📰 중소기업 인수인계 자동화 전략 - 스텝하우 "구두 전달이나 메신저 공유에 의존한 업무 지식은 시간이 지날수록 누락되고 왜곡된다. 기록이 없거나 파편화된 경우 새 담당자가 업무 흐름을 재구성하는 데만 며칠이 소요된다."

2. 주기성 — 한 사이클을 직접 겪어야 안다

회계는 결산, 인사는 연봉협상·평가 시즌, 영업은 계약 갱신 등 계절성이 있어 3개월~1년은 돼야 전체 그림이 보인다.

3. 관계 자산 — 사람이 곧 업무다

영업·구매·법무는 외부 이해관계자와의 관계가 업무 핵심인데, 이건 문서로 전달이 안 된다.

수치 근거

• 신규 입사자 30%가 90일 이내 퇴사
• 조기 퇴사 시 1인당 손실 비용 2,000만원 이상
• 체계적 온보딩 경험 시 생산성 70% 이상 개선
• 체계적 온보딩 경험 시 3년 이상 재직률 58% 증가
• 인사담당자 80.5% → 신입 조기 퇴사가 조직 분위기에 부정적 영향

📰 신입사원 3명 중 1명 조기 퇴사 - 클래스101 비즈니스 📰 신입사원 온보딩 프로그램 가이드 - 모카클래스

회고

오늘도 기나긴 회의를 했다. 결국엔 방향성이 하나로 잡힌 것 같아 뿌듯했다.. 긴 회의가 헛되지 않았던 것 같아서 너무 좋았다.

사실 나는 팀원끼리 파트를 나눠서 각자 조사하고 작성하는 방식이 회의의 질도 높이고 더 효율적이라고 생각해왔기 때문에, 첫 방향성을 잡는 과정이 너무 길어지다 보니 전체 회의가 오래 이어져 조금 루즈하다는 생각이 들기도 했다..

그래도 오늘은 정량적 근거 / 경쟁사(벤치마킹) 사례 / 유저 설문조사, 이렇게 3가지로 나누어 정리를 했고 나름 괜찮게 진행된 것 같다.

PRD도 방향성을 함께 잡아갔고, 이제 기능 명세서만 잘 잡으면 될 것 같다! 기능 명세서는 사실 상세 기능을 짜려니 막막했는데, 팀원분이 피그마로 시각화를 해주셔서 기능에 대한 그림이 조금씩 그려지는 것 같다. (최고!) 목요일 제출을 목표로 달려가보자!

추가로 우리 팀원들 전부 적극적이시고, 다들 의견도 부드럽게 잘 말해주셔서 너무 좋다.. 경청도 다들 잘 해주시는 것 같고. 배울 점이 많은 분들과 함께하게 되어 크나큰 영광.. 의지 불태우자..

TIL

식음료 B2B 에듀테크 도메인 리서치 - 3가지 방향성 검토

① 방향 제외 이유: 예비 창업자 개인이 타깃이라 B2C에 가깝다.

② 방향 검토 결과: B2B 성격이 가장 강하나, 대형 프랜차이즈는 이미 자체 교육 시스템을 보유하고 있고 내부 데이터 접근이 어렵다.

③ 방향 최종 선택: 점주가 직접 직원을 교육하는 구조. 페인포인트가 명확하고 기존 솔루션이 미흡하다.

대형 프랜차이즈는 자체 시스템을 갖고 있다

📰 맥도날드 햄버거대학에서 가르치는 것은? - 매일산업뉴스 📰 스타벅스 아카데미센터 가보니 - 비즈니스포스트 📰 University of SUBWAY® - App Store 📰 버거킹 알바 후기 - 네이트판

프랜차이즈 교육이 외부에서 접근하기 어려운 이유

• 교육 콘텐츠 = 영업비밀: 실제 교육 내용, 레시피, 운영 노하우는 공개되지 않음
• 이수율·효과 데이터 비공개: 교육이 실제로 잘 되고 있는지 외부 검증 불가
• 자체 시스템 이미 보유: 맥도날드·스타벅스 수준의 대형 프랜차이즈는 새로운 솔루션 도입 유인 낮음

가맹사업법에 따라 교육의 존재 여부와 개요는 정보공개서에 의무 공시하나, 실제 콘텐츠와 운영 데이터는 공개 의무 없음. 📰 가맹사업거래의공정화에관한법률 - 법제처

소상공인 공략 - 페인포인트 : 매뉴얼 3층 구조

소상공인의 직원 교육 문제는 단순히 "교육을 안 한다"가 아니라, 3단계로 쌓인 구조적 어려움이다.

핵심 페인포인트 요약 자영업자들은 교육의 내용도, 방법도, 기간도, 담당자도 모른 채 매번 처음부터 혼자 감당하고 있으며, 해결책("매뉴얼")은 알지만 만들 엄두를 못 내고 있다.

실제로 효과가 검증된 교육 방법, 업종별 온보딩 자료, 피드백 루프 시스템은 16개 게시물 어디에도 존재하지 않는다.

우리가 디벨롭할 수 있는 방향- 배민외식업광장 PM으로서의 제안

배민외식업광장은 현재 사장님 본인을 위한 정보 (세무·지원사업·법률)만 제공한다. 직원을 어떻게 교육할지는 완전히 비어있는 영역이다.

📰 배민외식업광장에서는 뭐해요? - 배민 스토리 📰 배민외식업광장 장사캘린더 PM 후기 - 우아한형제들 기술블로그

회고

나는 뭔가 개인 과제를 할 때보다 팀 과제를 할 때 더 열심히 하게 되는 것 같다. 혼자 하는 것보다 함께하는 게 더 의지도 되고, 같이 으쌰으쌰할 수 있어서 그런가?

회의를 엄청 오래 해서 힘들긴 했지만, 첫 단추를 끼우는 과정은 너무너무 중요하기 때문에.. 모든 팀원이 한 방향을 바라보는 게 1순위라고 생각한다.

오늘의 회고는, 회의할 때 "그러면 이건 마무리 짓고 다음으로 갈까요?"라는 말을 많이 했었는데, 아무래도 시간이 촉박하다 보니 조금 성급해지는 것 같아 다음 회의 때는 자제해 보려고 한다.

기능 명세서가 빨리 나와야 한다는 게 마음을 더 조이게 만드는 것 같다. 회사에 다닐 땐 기능 명세서를 거의 2주 잡고 했었는데.. 근데 이건 MVP니까 좀 다르려나..? 그리고 그땐 AI 도움 없이 내가 하나하나 다 짰었으니까 시간은 그때보단 확실히 줄 것 같다.

꼬꼬무 생각으로는, 목요일까지 기능 명세서랑 PRD를 완성하면 다음 주는 문서화와 PPT에만 집중할 수 있지 않을까..? 시간 분배를 잘해야겠다는 생각이 든다.

팀원들 모두 적극적으로 참여해 주시고, 리서치 정리해 주신 것들을 보면서 "아, 나도 이런 식으로 정리했으면 좋았을 텐데.." 하며 많이 배운 시간이었다.

📅 작성일: 2026-04-26 | 이름: 박제이

STEP 1. 프로젝트 핵심 요약 (Fact)

• 프로젝트명: 배달의 민족 성장 전략 역기획, 장보기의 새로운 혁신

• 나의 역할: 퀵커머스 데스크 리서치, 문제 분석 및 문제 정의, PPT 프롬프트 문서화, 발표 대본 작성

• 내가 담당한 핵심 지표/가설: B마트 월 방문자 563만 명 중 약 70%(394만 명)가 명확한 구매 목적 없이 탐색하다 이탈하는 문제를 발견했고, 이 탐색 비용이 높은 구간에 레시피 기반 장바구니 자동 구성 기능(B쑝)을 제공하면 구매 전환율이 0.3~1.2%p 상승해 월 약 42만 건의 추가 주문 전환이 발생할 것이다.

• 사용한 도구: Claude, Gemini

STEP 2. PM 역량 한 조각 발굴 (Action)

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

배민의 다양한 성장 전략 후보 중 퀵커머스를 선택한 근거를 명확히 하는 것에서 시작했다.
단순히 "시장이 크다"는 주장이 아니라,
퀵커머스가 이미 수익성이 검증된 영역(EBITDA 흑자 전환)이자
배민 전체 전략과 직접 맞닿아 있다는 점을 데이터로 뒷받침했다.

문제 정의의 핵심 근거는 UX 구조 분석이었다.
B마트의 현재 플로우(앱 진입 → 카테고리/검색 → 상품 탐색 → 장바구니)는
"살 것을 이미 아는 사람"에게 최적화된 구조다.
요리 목적으로 장보는 사용자는 이 구조 안에서 재료 수만큼 탐색을 반복해야 하며,
이는 구조적으로 탐색 피로와 구매 흐름 단절을 만들어낸다.

이를 바탕으로 핵심 가설을 세웠다:
"상품 탐색 중심 UX가 요리 목적 사용자의 구매 전환을 막고 있으며,
레시피 기반 장바구니 자동 구성 기능(B쑝)을 제공하면
탐색 과정이 단축되어 월 약 42만 건의 추가 전환이 발생할 것이다."

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

가장 고민했던 선택은 '유저 리뷰 리서치 없이 UX 구조 분석만으로 문제 정의를 완성해도 되는가' 였다.
결론적으로 UX 구조 분석만으로 충분하다고 판단했고, 그 근거는 세 가지였다.

첫째, UX 구조 자체가 이미 객관적 증거다.
"검색→담기→뒤로가기의 반복"이라는 플로우는 특정 사용자의 불만이 아니라
서비스 구조에서 발생하는 보편적 마찰이다. 유저 리뷰는 "불편하다"는 감정을 보여주지만,
UX 분석은 "왜 구조적으로 불편할 수밖에 없는지"를 설명한다.
후자가 더 설득력 있는 근거다.

둘째, 문제 정의의 목적은 공감 획득이다.
면접관이나 팀원이 "맞아, 나도 그렇게 느꼈어"라고 반응할 수 있을 만큼 보편적인 사용자 경험을 짚어낸다면,
리뷰 리서치는 보강 수단이지 필수 조건이 아니다.

셋째, B쑝의 실현 가능성은 국내외 사례로 뒷받침했다.
네이버 플러스 스토어(의도 기반 상품 추천)와
Uber Eats Cart Assistant(레시피 이미지 입력 → 장바구니 자동 생성)는
이 구조가 이미 실제 서비스에서 작동하고 있음을 보여주는 직접적 근거였다.

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

특별히 갈등이 있었던 건 아니었지만, 이번 프로젝트에서 내가 스스로 설정한 목표가 있었다.
팀원 전체가 항상 같은 방향을 바라보게 하는 것.

이를 위해 회의 중간중간 흐름을 요약하며
"지금 이런 방향으로 논의가 되고 있는 게 맞죠?"라고 방향성을 명시적으로 확인했다.
팀원의 발언이 현재 목표와 다른 방향으로 흘러가는 것 같을 때는
"그 의견도 중요한데, 우리가 지금 잡고 있는 목표에 맞춰 가면 어떨까요?"라는 방식으로 리디렉션했다.

이 과정에서 가장 중요하다고 느낀 건 경청이었다.
팀원의 말을 끝까지 듣고 의도를 파악해야만, 그 사람이 목표에서 벗어나고 있는 건지 아니면
다른 방식으로 같은 목표를 향하고 있는 건지를 구분할 수 있었다.
경청 없이는 방향 조율 자체가 불가능하다는 걸 몸으로 배운 프로젝트였다.

STEP 3. Lesson Learn & Next Step

이번 프로젝트에서 가장 성장한 부분:

경청을 통한 팀 방향성 통일

이전 팀 프로젝트에서는 내 의견을 관철하는 데 집중하다 보니 팀과 하나 되는 느낌을 받지 못했다.
이번엔 의도적으로 팀원의 말을 먼저 끝까지 듣고,
"지금 이렇게 말씀하신 거 맞죠?"라고 내 방식으로 재정리해 드리는 방식을 택했다.

이 방식은 두 가지 효과가 있었다. 말한 당사자는 자신이 제대로 이해받았다고 느끼고,
나머지 팀원들은 혼란 없이 같은 맥락을 공유하게 됐다.
결과적으로 각자 다른 파트를 리서치해 왔음에도 문서 전체가 한 사람이 쓴 것처럼 연결성 있게 완성됐고,
팀 분위기도 좋아 프로젝트를 빠르게 마무리할 수 있었다.

경청은 배려가 아니라 방향성을 만드는 PM의 기술이라는 것을 배웠다.

가장 아쉬웠거나 다음엔 다르게 해보고 싶은 부분:

해결방안 → 근거 역순 작업과 시간 분배 실패

중간에 프로젝트 목표를 한 번 바꾸면서 시간이 부족해졌고,
그 압박 속에서 해결방안(B쑝)을 먼저 정해두고 문제 분석과 문제 정의로
근거를 역으로 끼워 맞추는 방식으로 흘러갔다.
결과물은 완성됐지만, 논리가 아닌 결론에서 출발했다는 찜찜함이 남았다.

다음 프로젝트에서는 전체 파트를 한 번씩 훑고 가는 시간을 초반에 반드시 확보해,
문제 정의 → 해결방안의 순서가 뒤집히지 않도록 할 것이다.

다음 프로젝트에 가져가고 싶은 나만의 원칙:

1. 충분한 데스크 리서치로 말의 힘을 얻는다. :  설득은 열정이 아니라 근거에서 나온다.
2. 팀원의 말을 경청하고, 아는 내용도 다시 상기시켜 방향성을 확실히 한다.
    : 팀이 같은 곳을 보게 만드는 것도 PM의 역할이다.

목표 : 사용자의 선호나 행동에 기반하여 적절한 아이템을 제안 활용 케이스 : 사용자 스스로 원하는 바를 정확히 알지 못한 경우

좋은 추천이란?

• 사용자가 필요로 하거나 좋아할 만한 것을 개인화하여 제공
• 다양한 선택지 제시
• 적절한 지면에 적절한 시점에 제공
• 왜 추천받았는지 이해할 수 있도록 설명함
• 목표 지표를 개선해야함

좋은 추천은 돈이 되어야한다.

추천에 필요한 기본 요소

아이템 추천 알고리즘 유저

추천의 과정

유저 정보 전달 -> 추천 결과 생성 -> 추천 결과 전달 -> 추천 지면 노출 -> 유저 피드백 전달

• 유저 정보 전달 : 로그인/비로그인 여성/남성 등등
• 추천 결과 생성 : 회사 내 자체 생성 or 외부 솔루션 사용

  1) 전문가 추천
    ㄴ 장점 : 초기데이터가 부족한 상황에서도 추천 가능,
            전문가의 지식을 바탕으로 신뢰성 추천
    ㄴ 단점 : 전문가의 운영 리소스를 고려,
            전문가에 따라 추천의 품질 편차가 날 우려
    ㄴ 언제 쓰는가? 데이터 부족
  

2) 랭킹 기반 추천 ㄴ 장점 : 검증된 아이템, 구현 쉬움 ㄴ 단점 : 개인화 부족, 신규 아이템 추천 어려움 ㄴ 언제 쓰는가? 보장된 추천을 빠르게 제공

3) 콘텐츠 기반 추천 : 아이템의 특징을 기반으로 추천 ㄴ 장점 : 사용자 취향을 명확하게 반영, 신규 아이템 추천 가능 ㄴ 단점 : 추천 다양성 떨어짐, 추출 어려운 경우 퀄리티 떨어짐 ㄴ 언제 쓰는가? 신규 사용자, 아이템 일 때

4) 협업 필터링 추천 : 사용자의 행동 패턴을 분석해서 추천 ㄴ 장점 : 정보가 없어도 추천 가능, 개인화 성능이 좋음, 새로운 아이템 발견 가능성 놓음 ㄴ 단점 : 콜드스타트, 대규모 데이터에서는 성능 저하 ㄴ 언제 쓰는가? 사용자 수가 많고 추천할 아이템이 다양한 경우

5) 하이브리드 추천 : 내가 본 아이템 + 유사한 아이템을 좋아하는 사람들 + 나의 개인적 선호도를 함께 고려함 ㄴ 장점 : 세밀한 개인화 추천 가능 ㄴ 단점 : 여러 알고리즘으로 시스템 개발/관리 복잡 ㄴ 언제 쓰는가? 다양한 추천 전략이 필요할 때

 - 추천 노출
     홈 : 다양한 사용자의 니즈를 충족시켜야 함
        첫 방문 고객: 랭킹 기반 추천
        이 후 방문 : 개인화 추천
    상세 페이지 : 만족하지 못했다면 빠른 대체재 제공
                만족 했다면 비슷한 상품을 제공(콘텐츠 기반 추천)
    장바구니 : 더 많은 상품을 담아야함, 무료 배송비 구간을 넘겨야 함
    추천 영역 타이틀 : 컨셉을 잘 설명해주는 타이틀

• 제목 : Yozm IT 이커머스에서 ‘리뷰’ 경험이 중요한 이유
• 작성자(저자) : 수완

2. 핵심 내용 요약

• 이 아티클의 주요 메시지 : 이커머스의 구매 제약 요소를 보완하는 방법으로는 상세 페이지 내 주요 특성 제공과 리뷰 필터 등이 있고 그 중 공감과 유사 경험을 끌어낼 수 있는 리뷰가 주요 방법이라고 할 수 있다.
• 핵심 키워드 : 직접 평가, 직접 경험, 리뷰

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

• 읽으면서 가장 흥미로웠던 부분 : 고객의 공감을 끌어내기 위해 여러 이커머스가 다양한 방법들을 통해 직접 경험과 평가를 보완하고 있다는 점이 흥미로웠다.
• 이전에는 알지 못했거나 새롭게 배운 내용 : 리뷰에 대해 깊게 생각해보지 못했었는데 리뷰가 상품 구매 장벽을 낮춰주고 유사경험을 제공한다라는 점이 공감이 되었다.

4. 나의 한 문장 요약

고객이 원하는 진짜 정보는 리뷰에 있고 어떤 리뷰가 더 나은 정보를 제공할 지 고민해보자

TIL

•    AI (Artificial Intelligence)
•    머신러닝 (Machine Learning)
•    딥러닝 (Deep Learning)
    → 딥러닝 ⊂ 머신러닝 ⊂ AI

F1-Score

정밀도(Precision)와 재현율(Recall)을 함께 고려하는 지표 특히 데이터 불균형(imbalanced data) 상황에서 많이 사용 됨

F1 = 2 \cdot \frac{Precision \cdot Recall}{Precision + Recall}

Precision (정밀도) → 모델이 “맞다”고 한 것 중 실제로 맞은 비율 Recall (재현율) → 실제로 맞는 것 중 모델이 맞춘 비율

용도) • Precision만 높이면 → 보수적으로 예측 (놓치는 경우 많음) • Recall만 높이면 → 과하게 예측 (틀리는 경우 많음) → F1은 이 둘의 균형을 하나의 값으로 표현

회고

오늘은 AI 기획/데이터 특강을 들었다. 평소 AI 기획에 관심이 많아서 흥미롭게 들었다. 이젠 지피티가 없는 문제 도출과 기획은 상상도 할 수 없다.. 실무에서는 AI를 활용 해 어떻게 프로젝트를 완성해 가는 지 들을 수 있어서 좋았다. 강의를 들으며 내가 저 프로젝트에 참여한다면 어느 부분을 중점으로 둘까..역시 또 데이터를 엄청 파고들겠지? 라는 생각을 하며..

오후엔 저번 과제 구두 피드백 시간을 가졌다. 확실히 내가 열정적으로 했던 데이터 분류 부분에서는 칭찬을 받았고, 집중을 잘 못했던 핵심 문제 정의 부분에서는 근거가 부족하다는 피드백을 받았다. 데이터 분류를 명확하게 했기 때문에, 그에 맞춰 핵심 문제를 정의하고 근거를 도출했으면 더 좋았을 텐데 5 Whys나 매트릭스 같은 주어진 프레임워크에 맞추려다 보니 오히려 집중도가 흐려졌던 것 같다. 피드백 이후, 프레임워크를 100% 활용하지 않아도 되는지 질문했고, 근거만 명확하다면 괜찮다는 답변을 받았다. 조금 더 전문성을 기르고, 문제 정의와 근거 도출에 대한 경험을 쌓은 뒤에 프레임워크를 활용하고 싶다는 생각이 들었다. 튜터님의 자세한 피드백에 너무 감사했고 더더욱 열정과 의지가 불태워졌다..!

후엔 팀원들과도 서로 과제물과 피드백들을 서로 공유하고 회고하는 시간을 가졌었는데 팀원들 대부분 나와 같은 방향성으로 과제를 풀어갔었던 게 기억에 남았고 신기했다. 다음주부터 시작 될 팀 과제가 기대된다!

우선 이번주 과제부터 잘하자..ㅜ

정량적 데이터 : 숫자로 표현할 수 있는 데이터 정성적 데이터 : 주관적인 데이터 ex)느낌,의견,태도,경험 지표: 데이터에서 중요한 정보를 뽑아낸 결과, 데이터를 바탕으로 의미를 부여한 것

챕터 1-1 숙제 : PM 공고를 찾고 데이터 영량이 왜 중요하게 여겨지는 지 고민하기

나는 SI, 웹에이전시 쪽에 관심이 있어서 그쪽 공고를 중점으로 보았다.

챕터 1-2 데이터 중요성

정확한 의사결정을 하고 신뢰성있는 판단을 가능하게 함. ex) 나 오늘 너무 추워 vs 오늘 영하 10도라서 너무 추워

1, 의사결정의 근거 제공

객관적인 사실을 기반으로 의사결정을 내릴 수 있게 해준다. ex) 배달 앱에서 “배달 지연” 문제를 다루는 경우 몇 명이 불만을 제기 했는지, 배달원이 부족한지, 음식 준비 시간이 길어지는지 등등 실제적인 데이터를 파악해서 문제를 도출하고 해결책을 찾아갈 수 있다.

2.성과 측정 및 개선 기회 제공

데이터를 통해 성과를 측정하면 목표 달성 여부를 명확하게 알 수 있고, 개선점도 찾을 수 있다. 모든 개선의 기초에는 데이터가 있다.

3. 사용자 경험 향상

사용자의 행동 패턴과 니즈를 파악할 수 있다. -> UX 최적화 가능

4. 비즈니스 성과 예측 및 전략 수립

과거의 데이터를 바탕으로 미래의 비즈니스 성과 예측 가능, 시장의 트랜드과 소비자 행동을 분석 해 효과적 전략 수립 가능

챕터 1-2 숙제 : 모바일 앱에서 사용자들이 가입을 완료한 후, 실제 결제나 서비스 이용까지 이어지지 않는 경우가 많아 서비스를 개선하고자 합니다. 어떤 데이터를 살펴보고 활용하면 좋을지 생각해 보세요.

챕터 1-3 로그 설계 기초

1.로그(Log)란?

소프트웨어나 시스템에서 발생하는 이벤트나 동작을 기록한 정보 ex) 블랙박스

2.로그의 용도

• 문제 해결 및 디버깅 시스템의 로그를 분석하면 오류가 발생한 지점 파악 가능함. 로그에서 에러 코드와 실패한 API 요청에 대한 정보를 확인한 후, 결제 시스템의 버그를 수정 함

리디북스 서비스 장애 복구 후기

• 사용자 행동 분석
• 비즈니스 전략 수립

3.로그의 종류

PM이 알아야 할 대표적인 로그 클라이언트 로그 라이언트 로그 사용자 장치(예: 웹 브라우저, 모바일 앱 등)에서 발생하는 이벤트를 기록한 로그

4.로그 설계 방법

1. 로그 설계 목표 정의 로그의 목적과 필요성을 정의함. 프로젝트에서 로그가 해결하고자 하는 문제를 명확히 파악하는 것이 중요

2. 로그 항목 정의 및 설계 중요한 데이터 포인트를 파악하고, 이를 로그로 기록할 수 있도록 설계. 개발팀과 협업하여 어떤 데이터를 어떤 방식으로 기록할지 명확히 해야 함.

3. 로그 전송 및 테스트 개발에서 로그를 전송한 후, 실제 시스템에 로그를 심기 전에 테스트 환경을 설정하여 로그가 정상적으로 기록되고 전송되는지 확인함.

챕터 1-3 숙제 : 첨부된 스파르타 코딩클럽 웹페이지에서 클릭로그로 정의 할 수 있는 항목들을 적어보세요

챕터 1-4 데이터 분석 방법

1. 데이터 분석

문제 정의 → 데이터 수집 → 분석 수행 → 결과 해석 및 인사이트 도출 → 결과 적용

2.데이터 분석 방법론

퍼널 분석 (Funnel Analysis)

1. 목표 정의
2. 단계 정의
3. 이탈률 분석
4. 문제점 식별 및 개선책 제시

AARRR 프레임워크 사용자의 행동을 5단계로 나누어 분석하고, 각 단계에서의 성과를 측정하는 프레임워크

1. Acquisition (사용자 유입) : 사용자가 어떻게 제품이나 서비스를 알게 되었는지.
2. Activation (활성화) : 사용자가 첫 경험에서 긍정적인 반응을 보였는지 (예: 회원가입, 첫 거래).
3. Retention (사용자 유지) : 사용자가 지속적으로 돌아오는지.
4. Revenue (수익) : 사용자가 실제로 결제를 하거나 수익을 창출하는지.
5. Referral (추천 및 공유) : 사용자가 다른 사람에게 서비스를 추천하는지.

A/B 테스트 A/B 테스트란? 두 가지 이상의 변수를 실험하여 어느 버전이 더 나은 성과를 내는지 비교하는 실험적 방법

1. 변수 정의 : 테스트할 두 가지 이상의 버전을 정의
2. 그룹 분할 : 사용자 집단을 두 그룹으로 나누고, 각 그룹에 다른 버전을 노출
3. 결과 측정 : 테스트가 끝난 후, 각 그룹의 성과를 비교하여 어떤 버전이 더 나은 결과를 가져왔는지 분석
4. 결과 적용 : 더 나은 성과를 보인 버전을 적용하고, 지속적으로 개선

챕터 1-4 숙제 강의안에서 설명된 내용의 퍼널 분석 표를 직접 작성해 보세요.

• 단계 1에서 1000명이 방문
• 단계 2에서 800명이 회원가입 페이지에 진입 (20% 이탈)
• 단계 3에서 400명이 폼을 작성 (50% 이탈)
• 단계 4에서 200명이 회원가입을 완료 (50% 이탈)

• 전체 전환율: 20% (1000 → 200)
• 가장 큰 이탈 구간: → 2 → 3 단계 (회원가입 페이지 → 폼 작성) → 50% 이탈

챕터 1-5 구글 애널리틱스

구글 애널리틱스(Google Analytics)란? 웹사이트나 앱 방문자의 행동을 분석하는 도구

1. 구글 애널리틱스에서 할 수 있는 것

웹사이트에 얼마나 많은 사람이 방문했는지

• DAU, 일일 활성 사용자
• MAU, 월간 활성 사용자

방문자가 어디서 왔는지

• 구글 검색(SEO), 페이스북, 인스타그램, 광고, 이메일 등
• 어떤 채널에서 가장 많은 방문자가 오는지 파악하여 마케팅 최적화 가능

사람들이 내 사이트에서 어떤 행동을 하는지

• 어떤 페이지를 많이 보는지, 어디서 이탈하는지, 어떤 버튼을 클릭하는지

구매 전환율 (Conversion Rate) 측정

2. 구글 애널리틱스에서 자주 사용하는 용어 세션 페이지뷰 순 방문자 이탈률 전환율 트래픽 소스

챕터 1-6 구글 애널리틱스 활용

참여 보고서란? 사용자가 사이트에서 얼마나 적극적으로 활동했는지를 분석하는 보고서

개요

사이트에 방문한 사용자가 얼마나 오래 머물렀고, 어떤 행동을 했는지를 확인

이벤트

사용자의 모든 행동(클릭, 스크롤, 페이지 이동, 구매 등)을 "이벤트(Event)"로 추적

자동으로 수집되는 이벤트 (GA4 기본 이벤트)

페이지 및 화면

사용자가 웹사이트나 앱에서 어떤 페이지(화면)를 가장 많이 방문했고, 얼마나 오래 머물렀는지를 분석

• 홈페이지 조회수(15,000) 대비 회원가입 클릭(500)이 적다면? → 가입을 유도하는 요소 추가 필요
• 상품 페이지 체류 시간(3분 30초)이 길다면? → 사용자가 제품에 관심이 많으므로, 더 많은 트래픽을 유도하면 매출 증가 가능

방문 페이지

사용자가 웹사이트에서 처음 방문한 페이지

** 방문페이지와 페이지 및 화면의 차이 **
방문페이지는 웹사이트를 처음 방문한 페이지를 분석하고 (유입률)
페이지 및 화면은 방문한 모든 페이지에서의 행동을 분석함 (컨텐츠 개선)

챕터 1-7 프로덕트에서의 데이터 활용

리디북스 도서 추천(AI 도서 추천)

사용자의 도서 구매, 조회 등 데이터를 기반으로 개인화된 도서를 추천

1. 도서 추천 사용자 선정 - 장르별로 구매가 발생하는 섹션에 점수를 매겨 순위 매김
2. 추천 페이지 설정 - 서점의 주요 구매 경로확인 후 Page View 비중과 구매 비중 비교
3. KPI 설정 - GA 데이터로 데이터 로깅
4. 론칭 후 지표 확인 - 구매전환율 확인

챕터 2-1 시작 단계(킥오프)

킥오프란?

프로젝트의 첫 단계로, 프로젝트가 공식적으로 시작되는 순간

프로젝트의 목표, 범위, 일정, 예산 등 핵심적인 사항들을 팀과 이해관계자들에게 명확히 전달하고, 프로젝트의 성공적인 진행을 위한 기반을 마련 -> 프로젝트에 참여하는 모든 사람들이 같은 목표를 향해 나아가도록 유도하는 중요한 의사소통의 순간

킥오프 미팅의 핵심 요소 프로젝트 목표 프로젝트가 완료된 후 무엇을 달성하고자 하는지를 명확히 정의하는 부분 예시) 신규 제품의 출시로 시장 점유율을 5% 증가시킨다.

프로젝트 범위 프로젝트에서 다루게 될 작업과 다루지 않을 작업을 명확히 구분하는 부분 예시) 포함된 작업 : 웹사이트 디자인 및 개발, UX/UI 테스트, 사용자 교육 자료 제작. 제외된 작업: 서버 유지보수, 고객 지원 서비스 제공, 모바일 앱 개발.

일정 주요 마일스톤과 기한

팀 구성 각 팀원의 역할과 책임

커뮤니케이션 방법 예시)

• 회의 : 매주 월요일 오전 10시 진행되는 주간 회의
• 도구 : 슬랙을 통한 일상적인 소통, 이메일로 주요 의사결정 사항 전달
• 보고서 : 프로젝트 진척 상황은 매주 금요일 오후 5시에 이메일로 보고

리스크 및 이슈 미리 인지하고 대처 방안을 마련하는 것이 중요

기대 사항 프로젝트의 이해관계자들이 원하는 결과물이 무엇인지에 대한 명확한 설명

킥오프의 중요성

1. 명확한 목표 설정
2. 예상되는 리스크 및 문제 예방
3. 팀 간 협업 촉진
4. 이해관계자와의 기대 일치

참고 아티클 : 서비스 기획자의 뷰티컬리로 확장하기

킥오프의 진행 방법

사전 준비

1. 목표 설정
2. 참석자 선정
3. 자료 준비 tip! 2-3일 전에 자료를 미리 팀원들에게 배포하기
4. 미팅 목적 정리

미팅 진행

1. 프로젝트 개요 및 목표 공유
2. 프로젝트 범위 및 일정 소개
3. 팀 구성 및 역할 설명
4. 리스크 관리 및 문제 해결 방안 논의
5. 커뮤니케이션 계획 및 도구 소개
6. 질문과 의견 수렴

미팅 후

• 미팅 기록 공유
• 액션 아이템 정리

챕터 2-2 진행중 단계(공유)

공유

공유는 단순히 정보를 주고받는 것이 아니라, 필요한 정보를 필요한 사람에게 정확히 전달하는 과정

공유의 중요성

정보의 공유는 프로젝트가 제대로 진행되고 있는지 확인하고, 발생할 수 있는 문제를 미리 파악하며, 팀원 간 협력을 촉진하는 중요한 역할을 함

• 리스크 관리
• 의사결정 효율화
• 기대 일치
• 문서화 및 추적

공유를 잘하기 위한 방법

이메일, 슬랙, 트렐로, JIRA 등 다양한 커뮤니케이션 도구로 각 채널의 특성에 맞게 정보를 정리하고 전달하는 것이 중요

주기적인 미팅 및 업데이트

정기적인 회의나 업데이트 세션을 통해 팀원들이 프로젝트 진행 상황을 이해하고, 각자의 진행 상태를 공유함. 주간 회의, 일일 스크럼, 월간 리뷰 등을 통해 정보를 효율적으로 교환함

필요한 정보만 공유

목표에 맞는 정보만 제공

챕터 2-3 마무리 단계(회고)

회고란?

팀의 작업 과정, 의사소통, 도전 과제, 성공적인 점 등을 되돌아보고 어떻게 더 나아갈 수 있을지에 대한 아이디어를 나누는 시간

회고가 중요한 이유

학습과 개선

• 실패에서 배우기 : 잘못된 결정이나 실패한 부분을 회고하면서 실수에서 교훈을 얻고, 다음 프로젝트에 더 나은 결정을 내릴 수 있는 기회를 가질 수 있음.
• 성공을 반복하기 : 무엇이 잘 되었는지, 성공적인 전략이나 방법은 무엇이었는지를 파악함으로써, 좋은 결과를 계속해서 반복하고 모범 사례를 만들어 감.

협업의 질 향상 및 동기 부여

효율성 항상

회고 하는 법

• 진행 과정 돌아보기
• 구체적인 문제점 분석
• 개선을 위한 아이템 도출

1. ML 엔지니어 / 데이터 사이언티스트와의 협업
2. AI 기획 프로세스 경험
3. AI를 통한 비즈니스 임팩트

AI가 하나의 도메인으로 부상함 -> AI PM을 채용하는 추세가 늘어남

아직 과도기이긴 함.. 실제 컬리에서도 ai pm부서가 1-2달 뒤 사라짐..ㅜ

프로젝트 예시) 카카오와 다음의 콘텐츠들은 어떻게 분류되고 있을까? (ifkakao 개발자 컨퍼런스 2019)

과거 - 수집 관리 시스템 + human power! 개선 후 - 자동 수집 시스템 -> 너무 많은 정보량 -> 자동 분류가 필요해짐

문제 정의 : 콘텐트 자동 분류가 필요해짐 해결 : 머신러닝을 이용한 자동 분류 시스템 사용

• 기간별 콘텐츠 경향이 쉽게 파악됨
• 유저 취향에 맞는 콘텐츠가 제공됨

머신러닝과 딥러닝 • 머신러닝 → 사람이 특징을 설계 + 모델이 학습 • 딥러닝 → 모델이 특징까지 포함해서 전부 학습

데이터 수집

자체 데이터 수집/제작 : 크롤링,플랫폼을 통한 직접 수집 및 제작 데이터 구매 : 데이터 제공업체를 통한 구매, 특정 산업군의 기업에서 구매 협력 및 파트너십 : 연구 협력, 산업 파트너쉽 등을 통한 데이터 확보

1. 원천 데이터 수집
2. 파이프라인 설계 및 자동화
3. 수집 주기,형식,저장 방식 결정
4. 데이터 품질 검증

데이터 전처리

1. 노이즈 제거/이상값 처리 - 오류 데이터 극단값 (Outlier)등 모델 학습에 방해가되는 데이터를 제거하거나 보정
2. 결측치 처리 - 비어있는 값을 평균·중앙값으로채우거나,해당 샘플을 제거하는 방식으로 처리
3. 형태소 분석 + 불용어 제거
4. 라벨링 기준 합의 - 라벨링을 하는 사람마다 기준이 다르면 학습 데이터에 노이즈가 생김. 기준이 모호하면 모델 성능이 직접 훼손 됨
5. 라벨(Label) 부여 - 각 데이터에 정답 카테고리를 붙히는 작업. 지도학습의 핵심 자료

모델 학습

모델이란? 데이터를 학습하여 만들어진 '판단 능력을 갖춘 알고리즘'

Input(입력데이터) -> 
Model(학습된 판단능력, 수학적 함수의 집합) -> Output(예측,결과)

모델은 고정된 소프트웨어가 아니라, 계속 성장하는 유기체이다.

1. 입력(Input) - 어떤 데이터를 넣어줄 것인가? 무엇을 학습시킬지를 먼저 설계함

2. 추론(Inference) - 모델이 결과를 내는 과정 실시간으로 입력을 받아 결과를 내보내는 단계. Latency(응답속도)와 정확도의 균형이 중요함

3. 최적화(Optimization) - 피드백을 통해 모델을 개선 실제 사용 데이터와 피드백으로 모델을 재학습 KPI와 연결된 개선 사이클을 설계

학습을 위한 데이터셋 분할 훈련(약 70%) + 검증 (약 15%) + 테스트 (약 15%)

예측/평가

평가지표 : Accuracy(정확도), Precision(정밀도), Recall(재현율) F1-Score(정밀도와 재현율의 조화 평균)

학습 셋 구축과정

사례 참고 -> 현황 파악 뼈대 만들기 -> 카테고리 구체화 -> 학습 셋 구축

-> ML Model 타당성 겁증 -> 카테고리 통합, 제외

스마트한 학습 셋 관리 방법

• 학습 셋 어드민 구축
• 히스토리 관리
• 색을 통한 학습셋 운영 효율화

• 제목 : 커머스 사례로 보는 인풋 지표와 아웃풋 지표
• 작성자(저자) : 김민우

2. 핵심 내용 요약

• 아웃풋 지표는 인풋 지표가 작용한 결과롤 나타나는 지표이다.

• 인풋을 개선하면 아웃풋 역시 개선됨

• 아웃풋과 연관된 다양한 인풋요소들을 파악해 개선요지를 찾고, 설사 완벽하지 않더라도 계속 가설을 검증해가면 성과를 개선해 나가자

• 핵심 키워드 : 지표, 아웃풋, 인풋

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

읽으면서 가장 흥미로웠던 부분 :

• 수식으로 명확히 표현이 안되는 인풋이 존재하고 그것이 수식으로 표현되는 인풋보다 중요할 수 있다.
• 지표를 설정하는 것은 성과를 내기 위함이다. 지표의 엄밀함이 떨어지더라도, 사업 성과에 도움이 될 수 있다면 그 지표는 유용한 것이다.

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

• 구매 건수, 건당 구매 금액, 구매 고객 수 등 다양한 인풋을 구하기 위한 계산법
• 지표를 설정하는 기술도 중요하지만 더 중요한 것은 팀을 한 군데에 집중하도록 만드는 것이다. 팀 구성원들이 납득할 수 있게 스토리텔링을 잘 짜고 팀원 모두가 이 지표에 집중해서 실행하게 만드는 영향력, 리더십이 필요하다.

4. 나의 한 문장 요약

다양한 인풋요소를 조사하고 개선요지를 찾아서 아웃풋을 개선해 나가자

• 제목 : 서비스 기획자가 꼭 알아야 할 ‘핵심 지표’ 가이드
• 작성자(저자) : 소재민

2. 핵심 내용 요약

• 이 아티클의 주요 메시지 : 제품 지표를 퍼널 기준으로 비지니스의 큰 흐름을 이해하고 문제를 파악하자
• 핵심 키워드 : 정략적 데이터, 퍼널, 유저여정

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

• 읽으면서 가장 흥미로웠던 부분 : 광고 -> 클릭 -> 방문 -> 전환 의 흐름 속에서 단계가 넘어갈 때 마다 어디서 문제가 생기는지 파악해본다는 점이 흥미로웠다. 이러한 흐름들이 서로 관계성이 있다는 점을 중심으로 글을 읽었다.
• 이전에는 알지 못했거나 새롭게 배운 내용 : CTR, CVR과 같은 용어들 개념 정리가 잘 되어있어서 좋은 인사이트가 되었다.

4. 나의 한 문장 요약

• 이 아티클을 한 문장으로 요약하면? 지표를 통해 사용자 행동을 쪼개서 보면 어디를 개선해야 할지가 보인다

• 제목 : 프로젝트 관리자(PM)의 가장 중요한 덕목
• 작성자(저자) : 정철환

2. 핵심 내용 요약

• 이 아티클의 주요 메시지 : PM의 핵심 역할은 납기, 품질, 비용이라는 서로 충돌하는 요소들 사이에서 상황에 맞게 우선순위를 판단하고 균형을 맞추는 것이다.
• 핵심 키워드 : 트레이드오프, 우선순위 판단, 균형

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

• 읽으면서 가장 흥미로웠던 부분 :

  프로젝트에서 납기, 품질, 비용이 모두 중요하지만 동시에 만족시키기 어렵다는 구조가 인상적이었다. “다 잘하는 것”이 아니라, 하나를 선택하면 다른 하나에 영향을 줄 수밖에 없는 상황이라는 점이 흥미로웠다.

  또한 프로젝트 성격에 따라 기준이 완전히 달라질 수 있다는 점도 흥미로웠다. 일정이 절대적인 프로젝트에서는 납기가 가장 중요하고, 완성도가 중요한 프로젝트에서는 품질이 더 중요한 기준이 된다. PM은 정답을 찾는 사람이 아니라 기준을 정하는 사람에 가깝다.

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

  PM의 역할을 단순 관리가 아니라 “의사결정”으로 본 점이 새로웠다. 기존에는 일정 관리나 커뮤니케이션 중심의 역할이라고 생각했는데, 실제로는 무엇을 선택하고 무엇을 포기할지 결정하는 역할이 더 크다.

  또한 프로젝트 결과가 실행 문제만이 아니라 우선순위 설정에서 갈릴 수 있다는 점도 인상적이었다. 기준이 명확하지 않으면 팀의 방향이 흔들리고 결과물의 완성도도 낮아질 수 있다.

4. 나의 한 문장 요약

• 프로젝트의 성공은 모든 것을 잘하는 것이 아니라, 무엇을 우선할지 결정하는 데서 시작된다.

  또한 PM은 실행을 관리하는 사람이 아니라, 상황에 맞는 기준을 정의하고 팀이 그 방향으로 움직이게 만드는 역할이다.

• 제목 : [우아한형제들] 개발자가 생각하는 좋은 PM 나쁜 PM

• 작성자(저자) : 배민공통프로덕트실 김영한님

2. 핵심 내용 요약

• 이 아티클의 주요 메시지 : 누구든지 단순히 시키는 업무를 나의 일로 받아들이기 쉽지않다. 내 마음을 쓰는 진짜 나의 일을 하게끔 만드는 PM이 좋은 PM이다.
• 핵심 키워드 : 동기유발

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

• 읽으면서 가장 흥미로웠던 부분 : PM은 업무 고민을 가장 먼저 시작하기 때문에 PM은 개발자에게 요구를 하게 됨 그렇게 되면 개발자 입장에선 단순히 누군가가 시켜서 하는 일이 되어버림. 좋은 PM은 단순히 시키는 업무를 나의 일로 받아들이게끔 함 좋은 PM -

1. 문제를 먼저 제시함. 문제에서 해결을 유도하는 흐름으로 접근한다. 결국 개발자가 의견을 먼저 제시하고 개선해 갈 수 있겠다는 생각이 들게 하자.
2. 왜 해야하는지 설명함. 설명은 데이터 기반으로 고객 관점과 비지니스 가치의 관점에서 설명하여 설득력을 높힘
3. 피드백 사이클을 잘 만들어냄. 참여자 모두가 기획에 참여하고 있는 거 같은 느낌을 준게한다. 나쁜 PM - 혼자서 다하고 설명이 부족한 PM. 좋은 PM은 이미 일정관리와 우선 순위와 대안까지 다 파악했지만 굳이 물어보고 논의하여 개발자가 같이 참여한 느낌을 만들어준다.

• 이전에는 알지 못했거나 새롭게 배운 내용 : 단순하게 화면에 보이는 UI가 아닌 그 속의 정책들을 미리 다 파악할 것, 서비스 정책을 이해해야 서비스의 개선도 심도있고 좋을 퀄리티의 개선안이 나온다.

4. 나의 한 문장 요약

• 이 아티클을 한 문장으로 요약하면? 업무 프로세스와 도메인 정책을 제대로 잘 이해하고 모두에게 설명할 수 있게끔 인사이트를 갖춘 후에 프로젝트 팀원들이 누군가가 시킨 일이 아닌 자기의 일처럼 느낄 수 있게끔 환경을 만들어 준다면 좋은 PM이 될 수 있다.

• 제목 : 일상을 연결한다는 기쁨
• 작성자(저자) : Yeda

2. 핵심 내용 요약

• 이 아티클의 주요 메시지 : 회사에서 하는 일이 세상과 어떻게 연결되는지 이해하고 많은 사용자에게 도움이 되는 서비스를 만들자
• 핵심 키워드 : 새로운시도, 세상과의 연결

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

• 읽으면서 가장 흥미로웠던 부분 : 이 글을 읽기 전에도 당근의 방향성이 ‘좁은 지역 기반의 연결’ 이라는 점을 사용자 입장에서 느끼고 있었다.실제로 앱을 사용하면서도 그 흐름이 보였는데, 당근 PM의 목적이 사용자에게 그대로 전달될 정도로 실행되고 있다는 점이 흥미로웠다.

• 이전에는 알지 못했거나 새롭게 배운 내용 : 일의 의미를 이렇게 정의할 수도 있다는 점이 인상적이었다. 일을 단순한 생계 수단이 아니라 즐거움이 될 수도 있고, 나를 성장시키는 과정이 될 수도 있으며, 지속 가능하게 만들기 위해서는 일의 특성을 이해해야 한다는 흐름으로 이어진다. 또한 일은 힘든 것, 삶은 좋은 것처럼 분리하는 것이 아니라 일 자체를 즐거운 것으로 바라볼 수 있다는 관점이 새로웠다. 이 글에서는 내가 하는 일이 세상과 잘 연결되어 있을 때 그 일이 즐겁게 느껴질 수 있다 고 말한다. 기존에는 일과 삶을 분리해야 덜 힘들 것이라고 생각했었는데 다르게 보면 일 자체를 긍정적으로 바라보는 방식도 가능하다고 느꼈다. 나도 내배캠을 즐거운 마음으로 임해봐야겠다는 생각이 들었다.

4. 나의 한 문장 요약

• 이 아티클을 한 문장으로 요약하면?

세상의 필요와 나의 쓸모가 연결되는 지점을 찾자. 또한 회사를 선택할때도 그 회사에서 내가 하는 일이 세상과 어떻게 연결되는지 보고 많은 사용자에게 도움이 되는 서비스를 만드는 PM이 되어보자

• 제목 : PM 커뮤니케이션 스킬
• 작성자(저자) : 찬진
• 링크 : https://brunch.co.kr/@e40334d0eb6f49e/5

2. 핵심 내용 요약

• 이 아티클의 주요 메시지 : 충분한 *커뮤니케이션을 *통해 *명확함 *찾기
• 핵심 키워드 : 짚고 넘어가기

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

• 읽으면서 가장 흥미로웠던 부분 : 팀원들이 회의 자체에 대해 부정적으로 인식하고 있을 때, 단순히 회의를 개선하려 하기보다 가장 생산적이었던 회의는 무엇이었는지를 질문하는 접근이 흥미로웠다. 이 질문을 통해 팀원 각자가 생각하는 좋은 회의의 기준을 먼저 파악하고, 그 기준을 기반으로 회의를 설계하게 된다.
• 이전에는 알지 못했거나 새롭게 배운 내용 : “침묵은 동의가 아니라 동의하지 않는 것으로 해석한다”는 부분이 인상적이었다. 기존에는 회의 중에 별다른 의견이 나오지 않으면 의견을 완전히 이해하지 못했거나 동의하지 않지만 말하지 않았을 수도 있다. 결국 침묵은 합의가 아닌 리스크가 남아있는 상태로 남는다. 이것을 “침묵은 동의하지 않음”이라는 원칙을 적용하게 된다면 자신들의 우려를 표현하게 될 것이다.

4. 나의 한 문장 요약

• 이 아티클을 한 문장으로 요약하면?

자신에 대한 확신을 가지고 명확한 태도로 임한다면 좋은 커뮤니케이션이 될 것이다.

사과는 목표를 실행하지 못한 나 자신에게 주는 것.. 내일은 목표를 완수해보자 !

TIL

앞으로 강의에 대한 내용은 전부 따로 포스팅할 예정이다. 그 외에 TIL들을 작성해 보고자 한다.

아티클 카타란?

아티클 카타(Article Kata)는 글쓰기에서 반복 훈련을 통해 구조와 표현을 체득하는 연습 방식을 의미 여기서 카타(Kata)는 Kata에서 온 개념으로, 원래는 무술에서 정해진 동작을 반복하며 몸에 익히는 훈련 방식이다.

• 읽은 내용을 바탕으로 핵심 포인트를 작성
• 반드시 자신의 언어로 정리
• 길거나 복잡하게 작성할 필요 없이, 명확하게 정리하는 것이 목표

지금의 나에게 꼭 필요한 훈련..내일부터 첫 시작이니 제대로 해 볼 생각이다.

회고

강의를 들으면서도 블로그 포스팅에 대한 고민 때문에 집중이 잘 안됐다.
강의를 듣다가도 “이 부분은 어떻게 포스팅하지?”라는 생각이 계속 들었고,
글로 표현한다는 것에 있어 어려움을 많이 느낀 하루였다.

내가 배운 것, 이것을 표현하지 않으면 남들은 내가 무엇을 했는지, 무엇을 알고 있는지 알 수 없다.
표현을 잘하면 내가 아는 것보다 더 좋아 보일 수도 있고, 그렇지 않을 수도 있다고 생각한다.

튜터님께 이 부분에 대해 조언을 구했다.

1. GPT로 글쓰기 도움을 받고 있는데 포스팅에서 티가 많이 나는지
2. 강의보다 포스팅에 시간을 더 쓰고 있는데, 마음에 들지 않아도 시간 안에 끝내는 게 좋은지

이에 대한 답변은

• AI가 작성한 초안을 꼭 다시 읽어보면서 내 말투로 변환하는 연습을 해보세요.
• 시간이 많이 소요된다면, 지금 단계에서는 정해둔 시간 내에 작업을 완료하는 것을 목표로 하고, 이후에 수정하는 것을 추천합니다.

사실 서비스 흐름에 대한 하드 스킬도 중요하지만,
지금 나에게는 그보다 내가 약점으로 삼아왔던 부분,
커뮤니케이션 능력과 글을 정리하고 쓰는 능력을 초반에 더 키우고 싶은 마음이 크다.

그래서 추천 도서인 『회장님의 글쓰기』도 집중력이 떨어질 때마다 틈틈이 읽고 있다.

지피티의 도움을 받고 싶지만,
내가 질문을 논리적으로 잘해야 원하는 답변을 얻을 수 있다는 걸 알고 있어서
“질문을 잘하는 법부터 배워야 하나?”라는 생각도 계속 들게 된다.

생각이 계속 꼬리에 꼬리를 물고 이어진다.

사실 이런 부분도 튜터님께 질문하고 싶지만,
어떻게 질문해야 할지 정리가 되지 않아 아직 보류 중이다.

지금은 지피티와 함께 내 생각을 정리하는 과정을 거친 뒤,
더 효과적으로 질문하는 방향으로 가보려고 한다.

ChatGPT로 창의력 300% 발휘하기

(1) 이미지 생성

이미지 생성 방식도 구조가 있다.

기존에는 DALL·E 모델을 사용했고
이미지를 diffusion 방식으로 생성했다.

최근에는 4o image generation 방식이 사용되며
→ 자기회귀(Autoregressive) 방식으로
→ 픽셀을 순차적으로 생성한다.

자기회귀 (Autoregression, AR)란? 과거 데이터 값을 이용해서 현재 값을 예측하는 방법

이미지 프롬프트 구조

(2)Sora 로 영상 제작하기

Sora란? 텍스트를 기반으로 영상을 생성할 수 있는 AI 모델

프롬프트 예시 1)A narrow suspension bridge stretches across a vast canyon in the mountains. Mist surrounds the area, pierced by soft rays of the morning sun. Below the bridge, a wild river rushes through the chasm, and on both sides of the cliffs, massive waterfalls cascade down with thunderous force. The roar of water echoes in the background.

영상 프롬프트 템플릿

[카메라 움직임]

[렌즈 화각]

[카메라 앵글]

[톤 / 색감]

프롬프트 예시 2) 숲 속을 걸어가듯 보여주는 풍경 영상

• Camera Angle: eye-level
• Lens Type (Focal Length): 70mm lens
• Camera Movement: slow horizontal pan
• Tone & Color Palette: cool tone == A tranquil video of a dense morning forest, with mist drifting between tall pine trees. The focus is on stillness and serenity, with gentle light filtering through the leaves and no signs of movement or life.

숙제)

• 해바라기가 있는 풀밭에서 뛰어노는 말티즈 이미지를 사실적으로 생성해 봅시다.
• ChatGPT로 생성한 이미지를 활용해 Sora로 뛰어노는 말티즈 비디오를 제작해봅시다.

[결과물] 기엽당..