프로젝트 개인 회고

📅 작성일: 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. 내가 아는 것을 잘 설명해보자: 알고 있는 것과 설명할 수 있는 것은 다르다.
익숙한 것일수록 더 의식해서 풀어 설명한다.