[TIL] 애자일, 그리고 단계별 PM의 역할

오늘 학습 키워드  
- 애자일(Agile)과 워터폴(전통 개발방식) 차이  
- 애자일 프레임 워크(스크럼, 칸반 보드)  
- 스크럼 운영 방식과 핵심 개념과 프러덕트 단계별 PM 역할(기획, 디자인, 개발, QA, 릴리즈)  

배운 점

오늘은 애자일 개발 방법론과 실제 업무 적용 방법을 명확하게 정리했다. 기존 Google PM Certificate 과정에서 영어로 접했던 개념을 이번에는 새로운 강의를 통해 다시 복습하여 이해도를 높였다.

워터폴 방식은 각 단계를 순차적으로 거치는 전통적인 방식이라면, 애자일은 스프린트라고 불리는 짧은 개발 주기(보통 2주 등)로 작업을 반복·개선하는 방식이다. 이로 인해 제품을 점진적으로 출시하고 고객의 피드백을 바로 반영하는 것이 핵심이다.

애자일에서 중요한 문서 중 하나인 1-pager(원페이저)는 프로젝트의 시작점에서 팀원이 빠르게 공감하고 목표·가설·검증 전략·솔루션·성과 측정 방법 등을 한눈에 공유할 수 있게 해준다. 이 문서는 디자인, 개발 등 여러 직군의 원활한 협업의 출발점이 되는 역할을 한다.

애자일 워크플로우는 1-pager로 시작해, lo-fi(예를 들면 와이어프레임), 개발자 tech check, hi-fi(디자인에 완성도를 높인), 디자인 리뷰, 그리고 실제 개발 단계를 차례로 밟게 된다. 각 단계마다 피드백과 검토를 거쳐 완성도를 점진적으로 높이고, 리스크를 줄이는 구조다.  
완벽을 지향하기보단 빠른 가설과 검증, 즉 MVP 단위로 프로젝트를 운영하고 고객 피드백을 빠르게 반영해야 함을 깨달았다.

애자일이 항상 좋은 것은 아니며, 명확한 요구사항과 변경이 거의 없는 프로젝트(예: 정부사업 등)는 워터폴이 오히려 적합할 수 있다. 반면 피드백과 변화에 민감해야 하는 프로젝트에는 애자일이 유리하다.  
팀원 간 빠른 소통이 문서보다 중요한 점, 방법론(스크럼, 칸반, XP 등)마다 적용 상황이 다르다는 점도 다시 새겼다.

스크럼 프레임워크 내부에서는  
- 제품의 작업 목록(프러덕트 백로그) 작성,  
- 짧은 목표 설정(스프린트 플래닝),  
- 매일 진행 상황 공유(데일리 스크럼),  
- 스프린트 종료 후 리뷰·회고  
과 같은 단계의 구체적인 운영 방식이 있다.  
애자일 프로젝트 관리 툴(예: Jira)에서는 이슈타입(EX: 에픽, 스토리, 스토리포인트 등)이 있어 실제로 어떻게 업무를 분할·관리하는지도 파악 할 수 있다.

나 역시 이전 직장에서 데일리 스크럼을 경험해봤는데, 내부에서 충분한 목표 공유 없이 "업무보고" 느낌으로 소극적으로 흘러간 탓에 애자일의 본질에 맞지 않게 운영됐던 경험을 되짚었다. 앞으로는 모두가 애자일의 목적과 원칙에 대한 이해를 바탕으로 '보고'가 아닌 '협업·공유·전략수립의 시간'으로 만들어야 성공적인 프로젝트를 이끌 수 있다는 점을 느낀다.

그렇다면, 칸반을 사용하는 프로젝트와 스크럼을 사용하는 프로젝트의 예시는 무엇이 있을까?  
칸반은 반복적인 일정(스프린트)을 두지 않고, 일의 흐름을 시각적으로 관리하는 방식이다. 운영/유지보수, 고객센터(티켓 처리), 잦은 우선순위 변경이 필요한 작업이 적합하다. 예를 들어, IT 서비스 운영팀, 콜센터 업무, 지속적인 배포 등에는 칸반이 잘 어울린다.  
스크럼은 명확한 목표와 기간을 두고 '반복적으로 일정량의 일을 끝내야 하는' 프로젝트에 적합하다. 예를 들어, 신제품 개발, 기능 개선, 신속한 시장 테스트 등이 대표적이다.

두번째로는 각 프러덕트 개발 단계별 PM의 역할에 대해서 알아 보았다. PM은 프러덕트 개발 전 단계에 걸쳐 각 전문 분야와 협업하지만, 모든 과정에서 팀의 목표를 명확히 세우고 공유하는 역할을 맡는다.

먼저 기획 단계에서는 프로젝트의 배경부터 목표, 문제 정의, 해결 방안과 가설 수립, 검증 방법을 구체적으로 정리하고 문서화해야 한다. 그 목적은 개발자와 디자이너 등 동료들이 어떤 문제를 풀고자 하는지 명확히 이해하고, 요구사항을 놓치지 않게 하는 것이다. 이를 위해 기능정의서, 요구사항 명세서, 와이어프레임 외에도 테크 스펙, QA 문서 등 다양한 형식이 쓰일 수 있다. 그리고 생각보다 문서화는 대단히 중요하다.

디자인 단계에서는 PM이 기획 의도를 디자이너에게 충분히 공유하고, 디자인 관련 이슈가 생기면 신속히 조율해야 하며, 일정 관리도 중요하다는 것을 확인했다.

개발 과정에서도 PM은 기획과 디자인 내용을 정기적으로 공유하고, 개발 중 발생하는 이슈에 빠르게 대응하며, 필요한 경우 우선순위를 조정해야 한다. 개발 일정 관리 역시 PM의 주요 업무다.

QA 단계에서는 QA 엔지니어가 없다면 PM이 직접 테스트 케이스를 작성하기도 하고, 있다면 의도를 충분히 공유해 QA가 실제 테스트가 잘 이루어지도록 지원한다. 버그나 이슈가 발생하면 우선순위를 정해 관련자들과 공유해야 한다.

가장 인상 깊었던 내용은 릴리즈(출시) 이후의 역할인데, PM이 제품이 실제로 배포된 후에도 문제 없이 서비스가 잘 되고 있는지, 데이터는 정상적으로 수집되는지, 장애나 버그가 없는지 직접 모니터링하고, 문제 발생 시 빠르게 롤백 요청도 해야 한다는 점이다. 또한, 실사용자 데이터를 분석해 사용자 반응을 모니터링하고, 이 인사이트를 바탕으로 후속 과제를 도출하는 것이 PM의 중요한 과제임을 새삼 느꼈다.

각 단계마다 PM의 업무 내용이 조금씩 다르긴 하지만, 전 과정에서 팀이 목표를 잃지 않도록 조율하고, 끊임없이 소통하며, 일정과 우선순위를 관리하는 것이 핵심이라는 점을 정리했다.