오늘 한 일
오늘 오전에는 튜터님들이 내주신 과제인 “나의 경험을 글로 작성하기”를 쭉 작성해보았다.
글을 쓰면서 단순히 내 경험을 나열하는 데서 끝내지 않고, 면접관이 반박하거나 추가 질문할 만한 지점도 함께 정리했다. 그리고 그 질문에 어떻게 답할지 말하는 연습도 했다.
오후에는 프로젝트 매니지먼트 강의를 이어서 들었다. 어제와 오늘은 주로 애자일, 스크럼, 지표 설정, 프로덕트 개발 과정별 PM의 역할에 대해 배웠다.
1. 내가 알고 있던 애자일은 진짜 애자일이 아니었을 수 있다
오늘 애자일 강의를 들으면서 여러 회사의 애자일 사례와 데일리 스크럼 관련 아티클을 읽었다.
솔직히 보면서 이런 생각이 들었다.
진짜 저렇게 애자일하게 일하고, 데일리 스크럼을 운영하는 회사가 있구나.
내가 경험했던 애자일은 사실 이런 모습에 가까웠다.
- 스크럼에서 토론만 하고 결론이 나지 않음
- 상급자에게 숙제 검사 받는 느낌
- 일방적인 업무 전파
- 무겁고 경직된 분위기
- 계속되는 업무 부담
- 팀원들이 공감할 목표가 없음
- 일의 우선순위가 모호함
이런 경험 때문에 나에게 애자일은 그동안 “자주 모여서 진행 상황을 말하는 것” 정도로 느껴졌던 것 같다.
하지만 오늘 다시 정리해보니, 애자일은 단순히 회의를 자주 하는 방식이 아니었다.
애자일은 고객의 요구사항이 계속 변할 수 있다는 전제에서, 프로젝트를 작은 단위로 나누고, 매 단위마다 결과물을 만들며, 그 과정에서 계속 학습하고 조정하는 방식이다.
즉 애자일의 핵심은 빠른 회의가 아니라 변화에 민첩하게 대응하며 더 나은 결과물을 만들어가는 프로세스다.
2. 데일리 스크럼은 보고 시간이 아니라 팀의 방향을 맞추는 시간이다
오늘 읽은 글을 통해 스크럼도 다시 이해하게 되었다.
스크럼은 프로젝트를 애자일하게 운영하기 위한 방법론 중 하나다.
그중 데일리 스크럼은 하루 단위로 팀의 진행 상황을 점검하고, 오늘 무엇을 할지 맞추는 짧은 사이클이다.
중요한 것은 데일리 스크럼이 단순히 “어제 뭐 했고, 오늘 뭐 할 건지 보고하는 시간”이 아니라는 점이다.
데일리 스크럼의 목적은 다음에 가깝다.
- 팀이 같은 목표를 다시 확인한다.
- 각자가 오늘 무엇을 해야 하는지 명확히 한다.
- 방해 요소와 문제를 빠르게 발견한다.
- 발견된 장애물을 실제 행동으로 연결한다.
- 팀이 스스로 일을 관리할 수 있도록 돕는다.
즉 데일리 스크럼은 상급자에게 진행 상황을 검사받는 시간이 아니라, 팀이 자율적으로 목표를 달성하기 위해 서로의 상태를 맞추는 시간이어야 한다.
이 차이를 이해하니 내가 이전에 느꼈던 답답함도 설명됐다.
목표가 없고, 우선순위가 불분명하고, 단순 보고만 반복되는 스크럼은 애자일이 아니라 피로한 회의가 될 수밖에 없다.
참고한 글:
- 컬리 기술블로그 — 인바운드 스쿼드 스프린트 이야기
https://helloworld.kurly.com/blog/inbound-squad-sprint-1/ - 컬리 기술블로그 — 데일리 스크럼에 대한 생각
https://helloworld.kurly.com/blog/daily-scrum-thinking/ - Reddit — Why Agile mostly fails in the real world
https://www.reddit.com/r/agile/comments/1ltowq6/why_agile_mostly_fails_in_the_real_world/
3. 애자일은 도구이고, 핵심은 프로덕트에 집중하는 팀을 만드는 것이다
강의를 들으면서 이런 생각이 들었다.
데일리 스크럼을 한다고 해서 자동으로 애자일한 팀이 되는 것은 아니다.
데일리 스크럼, 스프린트, 회고 같은 도구는 중요하다.
하지만 더 중요한 것은 팀이 정말 프로덕트의 목표에 집중하고 있는지, 그리고 각자의 일이 그 목표와 연결되어 있는지다.
스크럼을 매일 해도 팀원들이 왜 이 일을 하는지 모른다면 애자일하지 않다.
반대로 회의 형식이 완벽하지 않아도, 팀이 고객 문제를 빠르게 발견하고 학습하며 개선하고 있다면 더 애자일에 가까울 수 있다.
그래서 오늘 내가 이해한 애자일은 이것이다.
애자일은 회의 방식이 아니라, 팀이 같은 목표를 향해 짧은 주기로 학습하고 조정하는 방식이다.
4. 지표에도 역할이 있다: 목표 지표, 가드레일 지표, 모니터링 지표
오늘 강의에서 또 인상 깊었던 부분은 지표를 나누는 방식이었다.
우아한형제들 기술블로그 사례를 통해 다음 세 가지 지표 개념을 배웠다.
- 목표 지표: 이번 과제를 통해 반드시 개선해야 하는 핵심 지표
- 가드레일 지표: 개선 과정에서 떨어지면 안 되는 지표
- 모니터링 지표: 반드시 달성해야 하는 것은 아니지만 함께 보면 좋은 지표
이 구분이 좋았던 이유는, PM이 지표를 볼 때 “좋아지는 숫자 하나”만 보면 안 된다는 것을 보여주기 때문이다.
예를 들어 어떤 기능을 개선해서 클릭률은 올라갔지만, 구매 전환율이 떨어졌다면 정말 좋은 개선이라고 볼 수 없다.
또 새로운 영역을 강조하면서 기존 핵심 기능 사용성이 떨어졌다면, 그 역시 위험하다.
그래서 PM은 목표 지표만 잡는 것이 아니라, 무엇이 좋아져야 하고, 무엇은 절대 나빠지면 안 되며, 무엇을 참고로 관찰할지를 함께 설계해야 한다.
참고한 글:
- 우아한형제들 기술블로그
https://techblog.woowahan.com/14484/
5. 프로덕트 개발 과정별 PM의 역할이 조금 더 선명해졌다
그동안 PM의 역할을 “프로덕트의 방향성과 전략을 수립하고 성공을 책임지는 사람”이라고 들었지만, 조금 막연하게 느껴졌다.
그런데 오늘 강의에서는 프로덕트 개발 과정별로 PM이 어떤 역할을 하는지 나누어 설명해주었다.
기획, 디자인, 개발, QA, 출시 단계별로 PM이 해야 할 일이 다르다는 점이 좋았다.
이 내용을 들으며 이전 스타트업에서 일했던 방식이 많이 떠올랐다.
어떤 부분은 내가 경험했던 업무와 비슷했고, 어떤 부분은 “일은 원래 이렇게 해야 하는 거였구나” 싶었다.
6. 기획 단계에서 PM이 해야 할 일
기획 단계에서 PM은 단순히 “이번 달에 만들 기능”을 정하는 사람이 아니다.
문제의 목적, 범위, 우선순위, 협업 방식을 정리해야 한다.
당근의 개발 협업 관련 글을 보면서 특히 인상 깊었던 것은, 의견을 자유롭게 낼 수 있는 구조였다.
참고한 글:
- 당근 기술블로그 — 당근마켓 IT 개발 협업
https://about.daangn.com/blog/archive/%EB%8B%B9%EA%B7%BC%EB%A7%88%EC%BC%93-it-%EA%B0%9C%EB%B0%9C-%ED%98%91%EC%97%85-pm-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%94%94%EC%9E%90%EC%9D%B4%EB%84%88/
이 글을 보면서 이전 회사 프로젝트가 왜 힘들었는지도 조금 더 명확해졌다.
당시에는 개발 마감 일정이 먼저 정해져 있었고, 모든 사람이 그 일정에 맞춰 움직여야 했다. 오픈 초반이라 한 달에 한 번 업데이트를 하려고 했지만, 왜 한 달에 한 번이어야 하는지에 대한 설명은 충분하지 않았다.
실제로 한 달 안에는 기획서, 디자인, 개발, QA가 모두 끝나야 했다.
그러다 보니 사용자를 위한 기능을 만들기보다는 한 달 안에 배포 가능한 기능을 고르는 방식이 되기 쉬웠다.
이 경험을 돌아보니, 일정이 중요한 것이 아니라 왜 이 기능을 지금 만들어야 하는지에 대한 합의가 먼저 필요했다는 생각이 든다.
7. 디자인 단계에서 PM이 해야 할 일
디자인 단계에서 PM은 디자이너에게 화면을 맡기고 끝나는 사람이 아니다.
사용자 문제와 목표가 화면에 제대로 반영되고 있는지 함께 확인해야 한다.
배달의민족 만화경 서비스 사례를 보면서 좋은 협업이 어떤 모습인지 느꼈다.
참고한 글:
- 우아한형제들 기술블로그 — 만화경 서비스 협업 사례
https://techblog.woowahan.com/6803/
이 사례에서 인상 깊었던 것은 아이디어를 제안하고, 함께 고민하고, 동료가 더 편하게 일할 수 있도록 툴까지 만들어주는 방식이었다.
디자인 단계의 PM은 “이 화면 예쁘다/안 예쁘다”를 말하는 사람이 아니라, 사용자의 흐름과 제품 목표가 화면 구조에 잘 반영되도록 돕는 사람이어야 한다.
8. 개발 단계에서 PM이 해야 할 일
개발 단계에서 PM에게 중요한 것은 팀이 동일한 이해 수준을 갖도록 만드는 것이다.
왜 이 기능을 만드는지, 어떤 문제를 해결하려는지, 성공 기준은 무엇인지가 공유되지 않으면 제품은 엉뚱하게 만들어질 수 있다.
개발자는 “이걸 왜 만드는 거지?”라고 생각하면서도 일정 때문에 구현만 하게 될 수 있다.
또는 더 좋은 의견을 낼 수 있는데, 맥락을 충분히 이해하지 못해서 말할 기회를 놓칠 수도 있다.
그래서 PM은 개발 단계에서 기획서를 넘기고 끝나는 사람이 아니라, 팀이 같은 문제를 같은 방식으로 이해하고 있는지 계속 확인하는 사람이어야 한다.
9. QA 단계에서 PM이 해야 할 일
QA 단계는 단순히 버그를 찾는 시간이 아니다.
사용자가 실제로 기능을 사용할 때 문제가 없는지 마지막으로 확인하는 단계다.
이전에 개발자로 일하면서 QA 기간이 충분하지 않아 힘들었던 경험이 많았다.
기획, 디자인, 개발이 지연되면 결국 QA 기간이 줄어드는 경우가 많았고, 그 부담은 출시 직전에 몰렸다.
그래서 PM은 QA를 일정의 끝에 남는 시간으로 두면 안 된다.
처음부터 QA에 필요한 시간을 확보하고, 어떤 시나리오를 반드시 검증해야 하는지 정의해야 한다.
특히 중요한 것은 정상 케이스뿐 아니라 예외 케이스까지 확인하는 것이다.
사용자는 우리가 예상한 대로만 행동하지 않기 때문이다.
10. 출시 단계에서 PM이 해야 할 일
출시 단계에서는 모든 직군이 긴장할 수밖에 없다.
내가 참여한 기능이라면 누구나 한 번씩 직접 테스트해보게 된다.
사용자보다 먼저 버그를 발견했다면 그나마 다행이지만, 출시 후 사용자가 먼저 문제를 발견하면 서비스 신뢰도에 영향을 줄 수 있다.
그래서 PM은 출시 전에 다음을 확인해야 한다.
- 핵심 사용자 시나리오가 정상적으로 동작하는가?
- 주요 지표를 측정할 수 있는 로그가 준비되어 있는가?
- 장애나 버그 발생 시 대응 플로우가 있는가?
- CS팀이나 운영팀이 알아야 할 변경 사항이 공유되었는가?
- 출시 이후 어떤 지표를 먼저 볼 것인가?
출시는 끝이 아니라 시작이다.
PM은 기능이 배포된 뒤 실제로 목표한 행동 변화가 일어나는지 확인해야 한다.
오늘의 한 줄
애자일은 매일 회의하는 방식이 아니라, 팀이 같은 목표를 향해 짧은 주기로 학습하고 조정하는 방식이다.
PM은 기획부터 출시까지 모든 단계에서 팀이 같은 문제를 이해하고, 같은 목표를 향해 움직이도록 만드는 사람이다.
앞으로 적용할 것
앞으로 팀 프로젝트나 실무를 할 때는 아래 질문을 계속 확인하고 싶다.
- 지금 우리가 하는 회의는 보고인가, 목표를 맞추는 시간인가?
- 이 기능을 왜 지금 만들어야 하는가?
- 팀원들이 이 기능의 목표와 성공 기준을 같은 수준으로 이해하고 있는가?
- 목표 지표, 가드레일 지표, 모니터링 지표가 구분되어 있는가?
- QA 기간과 주요 검증 시나리오가 충분히 확보되어 있는가?
- 출시 이후 어떤 지표로 성공 여부를 확인할 것인가?
오늘 배운 애자일과 PM 역할은 단순한 방법론이 아니라, 팀이 더 나은 제품을 만들기 위해 어떻게 함께 일해야 하는지에 대한 기준에 가까웠다.
