2. 프로덕트 개발 : 이해관계자 + 애자일(이론/실전) + 프로덕트 개발 과정

PM은 단순히 화면 기획만 담당하는 역할이 아니라는 걸 이제는 어느 정도 알고 있을 거라 생각한다.

다양한 이해관계자들과 협업하며 제품을 출시하고, 이후 개선까지 이어가는 조율자에 더 가깝다.

최근 IT 업계에서는 애자일(Agile) 방식이 보편화되면서,

PM은 빠르게 실행하고 반복적으로 개선하는 중심 역할을 맡게 되었다.

이번 글에서는 ‘PM과 협업하는 이해관계자’, ‘애자일은 무엇이고 왜 중요한가’,

‘스크럼은 어떻게 동작하는가’, 그리고 ‘실제 프로덕트 개발 흐름’을 중심으로 정리했다.

 

1. Product Manger 직무 이해 → 를 보고 이 글을 본다면 이해가 더 잘 될 것이다.

 

 

---

 

 

1. 프로덕트 개발은 이해관계자간 협업이 필수다

• 디자이너는 디자인만 하고, 개발자는 개발만 하고 PM은 기획만 한다?
• 당근 사례에서도 개발자, 디자이너, PM이 서로의 영역에 자유롭게 의견을 제안하는 문화가 중요하게 언급된다
  개발자도 UX 아이디어를 제안하고, PM도 개발 방향에 대해 의견을 낼 수 있는 환경이 좋은 협업의 핵심이라는 것이다
  
  • 출처 : 당근 개발자, 디자이너, PM 이렇게 협업합니다
• 즉, 좋은 프로덕트 개발은 '같은 목표를 공유'하고, '사용자 문제를 함께 고민'하며, '서로의 제약 조건을 이해'하는 것에 더 가깝다

 

2. PM 협업 능력의 중요성

• PM은 직접 구현 보다는 의사결정과 정렬에 더 가까운 역할이다
  • 왜 이 기능이 필요한지
  • 사용자 문제는 무엇인지
  • 어떤 방식이 가장 효율적인지
  • 지금 우선순위가 맞는지
  • 리소스를 어디에 써야 하는지
    → 다양한 직군과 함께 설득하고 합의하는 능력이 필요하다
• 토스 사례에서도 POS(Product Operations Specialist)는 데이터를 기반으로 고객 니즈를 분석하고, PM·디자이너·개발자·법무·QA·제휴사 등과 긴밀하게 협업한다고 설명한다
  • 출처 : 토스 제품팀은 어떻게 일할까 | 토스 POS 인터뷰

 

3. 애자일(Agile)이란?

• 완벽하게 다 만든 뒤 출시하는 방식 X → 빠르게 만들고, 빠르게 검증하고, 계속 개선하는 방식
  • ↔ 워터폴(Waterfall) 방식 : 요구사항 정의 → 설계 → 디자인 → 개발 → 테스트 → 배포
    ※ 워터폴 방식은 초기 요구사항 변경에 대응하기 어렵고, 개발 후반으로 갈수록 수정 비용이 커질 수 있다
    but, 시장과 사용자 요구사항은 계속 변함 → 이 문제를 개선하기 위해 등장한 것이 애자일이다
• 애자일 핵심
  • 작은 단위로 빠르게 만들고
  • 사용자 반응을 확인하고
  • 반복적으로 개선하는 방식
    → 즉, 시장 반응을 빠르게 캐치하고 반영하여 점진적으로 발전하는 형태의 서비스를 제공한다
• 여기어때 사례에서도 애자일 도입 이유를 
  
  • 출처 : 여기어때가 갑자기 ‘애자일’ 하자고 했다

 

4. 애자일은 단순히 빨리 만드는 것만이 목적은 아니다

• 속도 자체가 아니라 → 불확실성을 줄이며 사용자에게 맞는 방향을 빠르게 검증하는 것이다
• 컬리 사례에서도 애자일은 단순히 빠르게 만드는 것이 아니라,
  '핵심 기능 중심 개발', '우선순위 기반 개발', '낭비 최소화'를 강조한다
  
  • 출처 : 스크럼, 입고팀이 애자일하게 일하는 법
• 즉, 애자일은 → 무조건 일정 단축, 야근 증가, 빠른 출시 강박 X
• 오히려 잘못 적용하면 → 품질 저하, 기술 부채 증가, 팀 피로도 증가, 재작업 증가로 이어질 수 있다

※ 회사와 프로젝트 특성에 따라 워터폴과 애자일을 혼합해서 사용하는 경우도 많다

 

 

5. 스크럼(Scrum)이란?

• 애자일을 실무에서 실행하기 위한 대표적인 프레임워크
  → 짧은 주기로 목표를 정하고 반복 개선하는 운영 방식
• 보통 2주 정도를 하나의 스프린트(Sprint)로 운영한다
  ex. 이번 2주 목표 설정 → 필요한 작업 선정 → 개발 진행 → 매일 진행 상황 공유 → 결과 리뷰 → 회고 → 다음 스프린트 진행

 

6. 주요 스크럼 구성

1. 스프린트(Sprint) : 짧은 개발 주기 → 보통 1~2주 단위(이번 기간 안에 무엇을 완성할 것인가)
2. 백로그(Backlog) : 해야 할 일 목록
   → 기능 개선, 버그 수정, 운영 개선, 사용자 요청 등이 쌓인다(PM은 백로그 우선순위를 상시 관리한다)
3. 데일리 스크럼(Daily Scrum) : 매일 짧게 진행하는 공유 미팅
   → '어제 한 일', '오늘 할 일', '막히는 문제'에 대해 공유(팀이 목표 달성을 위해 같이 작전(일정)을 맞추는 것)
   ※ 컬리 사례에서도, '상사에게 보고하는 자리가 아니라 원팀으로 조율하는 자리'라고 강조한다
   • 출처 : '데일리 스크럼'을 더 잘하기 위한 생각
4. 회고(Retrospective) : 이번 스프린트에서 '뭐가 좋았는지', '뭐가 문제였는지', '어떻게 개선할지'를 돌아보는 과정

 

7. 사용자 맥락 이해 → 좋은 제품(우아한형제들 '구름톡' 사례)

• 출발점 : 웹툰을 같이 보는 경험을 만들자
• 이후 과정
  • 사용자는 어떤 타이밍에 반응할까
  • 어떤 위치에 댓글을 달고 싶을까
  • 감상을 방해하지 않으려면?
  • 댓글은 언제 보여야 자연스러울까
    → 위 과정을 거치며 구체화
• 초기 방향(B안)을 실제 테스트해보니 사용자 경험 문제가 발견됐고,
  결국 방향을 다시 수정했다는 점이 인상적이다
  → 내 생각에 좋아보이는 기능 X, 실제 사용자가 어떻게 느끼는가 O
• 출처 : 웹툰도 같이 봐요: 만화경 구름톡

 

8. 좋은 PM → 문제 재정의 능력(배민 '선물하기' 사례)

• 출발점 : 단순 VOC*(Voice of Customer) → '선물을 거절하기 어렵다'
• 이후 과정
  • 반복되는 사용자 불편 관찰 후, 문제 다시 정의
    • 기존에도 거절 기능은 존재함
  • 사용자 맥락 분석
    • 사용자 입장에서 심리적 부담이 존재할 수 있다고 판단
  • 실제 니즈 확인
    • '사용자는 왜 거절을 불편해할까?'
  • 백로그 과제화
    • 기존 방식은 배민에 로그인을 해야 거절 가능했음
  • 우선순위 설득
    • 단기적인 사용자 유입보다 사용자 경험 개선을 우선으로 두고 접근
  • 지표 설정
    • 목표 지표 : 거절을 원하는 사람이라면 등록 후 거절보다 등록 전 거절을 선호할 것
    • 가드레일 지표 : 거절의 전체 수치는 늘지 않을 것
    • 모니터링 지표 : 고객센터로 거절 방법을 문의하는 사람이 감소할 것
  • 개선 후 효과 측정
    • 등록 후 거절 60% 감소
    • 고객센터 문의 66% 감소
• 이 사례로, PM은 '사용자 문제를 발견하고 조직을 움직여 해결하는 역할'이라는 점을 느낄 수 있다

* VOC(Voice of Customer/고객의 소리) : 서비스/제품에 대한 고객의 의견·불만·제안 데이터

 

 

9. 일정 산정과 문서화의 중요성(당근 사례)

• 일정 산정의 중요성
  • 당근의 블로그를 보면, QA 이후 수정 기간을 과소평가하면 사용자 경험 개선 기회를 놓친다고 설명한다
  • 실무에서는 항상 '예상치 못한 이슈', '추가 아이디어', 'QA 피드백', '환경별 버그', '이해관계자 요청'이 발생한다
    그래서 일정 산정은 단순 계산이 아니라, '리스크 예측', '협업 비용 고려', '수정 가능성 고려', 'QA 기간 확보'까지 포함된다
  • 즉, 일정 자체보다 '왜 이 일정이 필요한지 설명할 수 있어야 한다'
• 문서화의 중요성
  • 잘 된 문서화는 협업 비용을 줄인다
    • 당근 블로그에서도 'PRD', '실험 문서', 'QA 문서', '회고 문서' 등을 지속적으로 기록한다고 설명한다
  • 좋은 문서는 단순 기록용이 아니라, '왜 만드는지', '어떤 문제를 해결하는지', '성공 기준은 무엇인지', '어떤 제약이 있는지'를 팀 전체가 동일하게 이해하게 만드는 것이다
    즉, 팀 전체가 같은 규칙과 목적을 가지도록 문서화를 하면 협업 비용 절감 효과를 얻을 수 있다
• 출처 : 당근 개발자, 디자이너, PM 이렇게 협업합니다

 

10. 심리적 안정감 ↔ 협업 생산성

• 위 현업 아티클에서 굉장히 자주 언급되는 이야기가 있는데 바로 '심리적 안정감'이 현업 생산성에 영향을 준다는 것이다
  • 자유롭게 의견 제안 가능
  • 일정 산정 압박 감소
  • 실패 공유 가능
  • 역할 경계 완화
  • 개선 제안 가능
    → 위와 같은 문화가 있어야 좋은 제품이 나온다는 것이다
• 애자일도 결국, 빠르게 검증하고 수정하는 문화가 가능해야 제대로 동작한다(유저 피드백을 반영하여 개선하니까)
• 즉, 실패 공유 자체가 불가능한 조직에서는 애자일 프로세스만 흉내내게 되는 경우도 많다

 

11. 결론 - 프로덕트 개발의 핵심

• 프로덕트 개발은
  • 기능 많이 만들기
  • 빠르게 출시하기
  • 화면 설계 잘하기
    → 만으로 설명되지 X
• 실제로 중요한 것은
  • 사용자 문제를 이해하고
  • 우선순위를 판단하며
  • 팀과 협업하고
  • 빠르게 검증하고
  • 반복 개선하는 것
• PM은 그 중심에서
  • 문제를 정의하고
  • 목표를 정렬하고
  • 실행을 조율하며
  • 결과를 책임지는 역할

 

---

 

 

인사이트

 

관련 아티클을 통해 실제 현업 사례를 다양하게 볼 수 있어 좋았다.

결국 중요한 건 사용자 맥락을 얼마나 깊이 이해하는지,

그리고 다양한 직군과 얼마나 효과적으로 소통(문서화 포함)하고 협업할 수 있는지였다.

 

또 애자일에 대해서는 나 역시 단순히 빠르게 프로젝트를 출시하고

보강하는 방식 정도로 이해하고 있었는데,

실제로는 단순 속도 경쟁이 아니라 불확실성을 줄이며

사용자 문제를 더 빠르게 검증하기 위한 방식이라는 점을 다시 정리할 수 있었다.