내일배움캠프 TIL : AI로 취준 자동화 세팅 + PM 핵심 개념 정리

 

오늘 한 것 요약

오늘은 크게 두가지를 했습니다.

1. Claude Code를 활용한 취준 자동화 시스템 세팅
2. PM 부트캠프 핵심 개념 학습 (지표/북극성 지표, 힉의 법칙, WANT vs NEED, PRD)

---

1. Claude Code 취준 자동화 세팅

왜 했냐

취업 준비를 하면서 가장 시간이 많이 드는 게 공고 탐색이랑 자소서 작성이었어요.

매일 원티드, 리멤버, 인디스워크 들어가서 공고 보고, 어떤 경험을 쓸지 고민하고, 초안 작성하는 데 반나절씩 쓰고 있었는데,

이걸 자동화하고 싶었습니다.

뭘 만들었냐

experience.md	내 경험 12개 블록으로 정리 (STAR 기법)
자소서 스킬	공고 넣으면 경험 매칭 + 초안 생성
Google Search MCP	채용 공고 자동 검색
Slack MCP	브리핑 자동 전송
자동 스케줄	매일 오전 9시 실행

브리핑 구조

매일 오전 9시에 Slack으로 이런 메시지가 옵니다.

• 원티드/리멤버/인디스워크에서 서울 IT 서비스기획/PM/PO 신입~3년차 공고 수집
• experience.md와 매칭률 계산
  • 70% 이상 → 자소서 초안 자동 생성
  • 70% 미만 → 갭 분석 + 부트캠프에서 보완할 포인트 안내

느낀 점

처음엔 '버튼 하나 누르면 다 되겠지' 했는데

원티드/사람인 같은 사이트들은 외부에서 공고를 긁어오는 걸 기술적으로 막아놨더라구요 🥲

 

Google Search API로 우회하는 방식을 쓰게 됐는데,

완벽하진 않지만 공고 탐색 + 자소서 초안까지 자동화된 것만으로도 하루 2~3시간은 아낄 수 있을 것 같습니다.

 

이 작은 프로젝트(?)를 하면서도 PM으로서의 사고방식을 시도하고, 기를 수 있었던 것 같아요.

 

① 우선순위 재정립

- 포털 사이트의 공고를 긁어오는게 막혀있는 이상

- '완벽한 자동화'보다 '지금 당장 쓸 수 있는 것'부터 만드는걸 우선순위로 잡았어요.

- PM이 MVP를 설계하는 단계에서 이런 역량이 쓰이는걸까요!

 

② 문제의 핵심 원인 파악

- 처음에는 experienct.md 파일에 있는 제 경험 블록을 활용해서 자소서를 쓰는 것까지 자동화 하려고 했는데,

결과물을 보니 jd에 나온 자격요건과 제 경험은 맞는데 묘하게 억지로 갖다 붙인 것 같다는 느낌이 들더라구요.

- 프롬프트를 수정해야 하나.. 싶었는데, 제 경험(마케터)과 PM jd 자격요건이 애초에 안맞기 때문에 이런 결과가 나온 것 같다는 핵심 문제를 파악했습니다.

- 그래서 jd 내용과 experience.md와 매칭률을 계산해서, 매칭률이 70% 이상일 경우에만 자소서 초안을 자동 생성하고,

- 그 미만인 경우에는 제 경험과 자격요건과의 갭을 분석하고, 부트캠프에서 보완할 수 있는 포인트를 안내해달라고 했어요.

- 내일 처음으로 9시에 슬랙으로 전달하게끔 세팅해뒀는데, 보고 나서 더 수정할 부분이 계속 생길 것 같습니다.

 

•  

---

2. PM 핵심 개념 학습

지표와 북극성 지표

지표	데이터로 무언가를 파악하겠다는 의도
북극성 지표	제품 성공을 측정하는 핵심 지표. 늦게 움직임
선행지표	북극성 지표 달성 전에 먼저 보이는 행동 신호

 

PM은 단순히 숫자를 보는 사람이 아니라 "어떤 사용자 행동이 장기 성장으로 이어지는가" 를 계속 찾는 사람입니다.

선행지표 → 실험 → 북극성 지표 변화 검증 → 반복

 

힉의 법칙 + 인지부하

• 선택지가 많을수록 의사결정 시간이 늘어난다
• 부하의 종류: 인지 > 시각 > 운동 순으로 까다로움
• 좋은 UX = 부하의 총량을 줄이는 것
  • 클릭 횟수(운동부하)가 늘어도 생각할 게(인지부하) 줄면 전체적으로 더 좋은 UX

토스 회원가입이 단계별로 나눠져 있는 이유

고객의 WANT vs NEED

WANT	고객이 직접 표현하는 욕망	"UI가 예뻤으면 좋겠어요"
NEED	시장에 실제로 존재하는 근본 문제	"원하는 기능을 찾지 못해 업무 흐름이 끊긴다"

 

PM = 번역가

고객의 감정적 언어(시스템 1)를 논리적 문제(시스템 2)로 번역하는 사람

 

에어비앤비 사례가 인상적이었습니다.

"값싼 침대를 원한다"는 WANT 뒤에 "현지인처럼 살아보고 싶다"는 NEED가 있었고, 그걸 발견한 순간 서비스가 완전히 바뀌었어요.

PRD (제품 요구사항 문서)

• 목적: 제품 형상을 개발팀과 공유하는 것
• PM이 초안 30% 작성 → 개발 과정에서 팀이 함께 100% 완성
• 핵심 구성요소
  1. 제품 개요
     1. 제품의 목적, 해결해야 할 문제에 대한 요약, 왜 이 문제를 해결해야 하는지
     2. 중요성을 강조할 수 있는 근거 데이터 참고
        • 몇 달간 사용성에 대한 이슈, VOC 반복적인 키워드
        • 신규 개발- 시장의 상황이나 변화, 경쟁사의 제품 성장
  2. 비즈니스 목표
     1. 비즈니스 목적 분석 : 매출 증가, 시장 점유율 확대, etc
     2. KPI : CVR, 매출 증가율, AOV, 신규 유입 비중
     3. 목표 수치 설정
  3. 핵심 고객 또는 사용자 정의
  4. 핵심 사용자 여정/사용자 스토리
     • 사용자 요구에 집중하되, 해결 방안에 집착하지 말 것
  5. 기능 요구 사항
     1. MUST HAVE
     2. SHOULD HAVE
     3. COULD HAVE
  6. 프로젝트 일정 및 배포 계획
  7. 기타 참고 문서
     • 와이어 프레임, 스토리보드, UX리서치 결과 등

---

오늘의 회고

오늘 하루 기술적인 세팅과 개념 학습을 동시에 했습니다.

서비스 기획 입문 강의도 들었는데.. 입문이라서 크게 어려운 점은 없었고

클로드 자동화 세팅이랑 현업 아티클 읽고 정리하는 데에 좀더 초점을 두었어요.

 

웹/앱 서비스도 피지컬 프로덕트 못지 않게 사용자 행동을 설계하고 유도하는 게 복잡하다는 걸 다시금 깨달았습니다.

 

예를 들어 제품 마케팅을 할 때 리텐션을 CRM이나 제품력, 재구매 프로모션 등에 의존했다면(더 많고 복잡하지만)

앱/웹 서비스의 경우 프로덕트의 잔존 가치부터 시작해서 고객의 니즈를 파악해서 끊임없이 업데이트하고, 아하 모먼트를 정의하고, 선행지표를 분석하는 것 등등.. 뭔가 결은 다르지만 복잡한건 비슷한 것 같아요.

 

그래도 더 재밌는 것 같습니다..ㅎㅎ