[PM 회고록] PM과 개발자 사이: 학부생 프로젝트에서 마주친 위기와 성장의 기록 (with Agile)

📕 목차

1. Introduction
2. Communication
3. Motivation
4. Architecture Assessment
5. Conclusion

---

1. Introduction

 

📌 Motive

올 한 해, 학부생 프로젝트의 PM(이자 백엔드이자, 이것저것 개발자인..)을 맡으면서, 프로젝트 시작 전에 소프트웨어 공학 시간에 배운 애자일 방법론을 적용하자고 팀원들을 설득했었다.

사전 준비를 철저히 하기 위해, 애자일에 대해 정말 많은 공부를 하고 관련 글들을 참조했고, 심지어 교수님과 현직 개발자 분들께 자문을 구하기도 했다.

그러나, 그럼에도 불구하고 수많은 우여곡절이 있었다.

 

그 중에서 가장 굵직한 스토리에 대해서는 한 명이라도 도움이 될 수 있도록 꼭 적어놓고 싶었다. (미리 이야기하지만, 수치적으로 표현 가능할 만큼 극적인 변화를 가져오진 못 했다.)

지금부터 적을 내용들은 이론에 기반한 원론적인 이야기가 아닌, 직접 경험하고, 그 과정에서 느낀 점들에 대해 적어보려고 한다.

 

내가 대단한 리더쉽이나 경험을 가진 특출난 인물이 아니기에, 오히려 평범한 사람들에겐 좀 더 와닿지 않을까...^^

명쾌한 해답은 제시하지 못 하지만, 내가 방황한 모습을 보면서 본인만의 새로운 전략을 시도해봐도 좋을 것 같다.

 

📌 Background

[Software Engineering] 보다 경험적인 Agile Scrum에 대하여

올해 초에 애자일과 관련된 포스팅을 몇 번 올렸던 적이 있는데, 우리는 위 포스트에서 나온 대로 프로젝트를 진행했다.

멤버 구성은 웹 프론트 2, iOS 2, 백엔드 3, 디자인 2을 포함해서 9명이었다.

 

하지만 애자일의 이념과는 다른 점이 정말 많았는데, 초기에 파악한 우리 팀의 강점과 약점은 다음과 같았다.

• 강점
  • 직위나 계급, 연봉 따위가 없으므로, 진정 모두가 동등한 관계
• 약점
  • PM이 개발을 겸하고 있다.
  • PM 역할을 처음 수행해보는 사람이 역할을 맡은 상태.
  • 팀 전원이 애자일에 대해 미숙한 상태. (그나마 한 명이 소마에서 경험은 해봤었다.)
  • 웹 프론트 팀은 이미 졸업한 취준생
  • 서로 아예 모르거나, 안면 정도는 익힌 상태
  • 디자인 팀이 프로젝트에 완전히 속해 있기 보다는, 이해 관계가 일치한 동업자에 가까운 느낌
  • 협업 경험이 대부분 미숙함
  • 비록 나머지 인원들은 모두 4학년이지만, 학교 수업, 과제, 시험 등으로 인한 작업 불가능한 시기가 존재함.

 

강점보다 약점이 확연히 많음에도, 애자일을 도입하고자 했던 이유는 단 한 가지였다.

애자일이라 주장하는 국내 회사와 달리, 직위나 인사팀 따위가 존재하지 않는 지금이야 말로 진정한 수평적 문화를 실천해볼 수 있는 기회일 것이라 생각했기 때문이었다.

 

그러나, 지금에서야 깨달은 사실은 나는 애자일 도구들을 도입하는 것에는 성공했을지라도, 문화를 바꾸는 것에 실패했다는 점이었다.

애자일에 대해 논하는 글이 아니기 때문에, 이게 무슨 소리인지는 아래에서 간략하게만 다룰 예정.

 

그저 해결 방법을 논하는 과정에서, 왜 이런 생각과 선택을 했는지에 대해 이해를 돕기 위한 배경 설명이었다.

 

📌 Project Delay

문제는 애자일을 성공적으로 도입했냐, 아니냐가 아니었다.

가장 큰 문제는 iOS팀의 개발 속도가 내가 처음 예상한 기간에 비해 너무 뒤쳐진다는 부분에 있었다.

 

엥, 이거 그냥 개발자 탓 하시는 거 아닌가요? 🤔. 그런 내용 아닙니다..

설령 사실일지라 하더라도, "난 잘했는데, 사람들이 안 따라와주더라~"같은 글을 쓸 이유가 없지 않은가.

 

원래 계획이라는 게 예정대로 돌아가지 않는다지만, 1달에서 길어봐야 2달을 예상했던 인증 도메인 구현에 3달이 소모되면서, 더 이상 낙관적으로 볼 수 없는 상황이 되었었다.

물론 PM으로서 질책도 했고 문제 상황을 인지시켜주기도 했지만, iOS팀이 노력하지 않았기 때문에 발생한 문제라고는 생각하지 않았기에, 이 이상은 스트레스만 줄 뿐 상황을 개선할 수는 없다고 판단했다. 

 

그렇다면 나는 PM으로서 어떤 역할을 수행해줄 수 있을까?

그러기 위해선 문제점을 파악하고, 개선하기 위한 구체적인 전략을 필요로 했다.

 

---

2. Communication

 

📌 Design Team

가장 처음 주목한 부분은 디자인 팀과 프론트 팀의 의사 소통 문제였다.

프론트 팀은 UI를 제작하기 위해 Figma를 참고하고, 그 과정에서 질문 거리 등을 Figma 댓글로 남겨두었었다.

 

이 방식은 문제점이 많았다.

• iOS팀이 작업하는 시간대와 디자인 팀이 작업하는 시간대는 불규칙적이고, 서로 잘 맞지도 않은 경우가 대다수였다.
• 디자인 팀이 답변을 누락하거나, 잊어먹는 경우도 많았는데, iOS 팀 입장에선 그저 답변을 기다리는 방법 말고는 없었다.
• 디자인 팀이 UI를 수정하기 전인지, 도중인지, 끝났는 지 상태를 알 수가 없었다.
• 이미 다른 팀원이 질문한 사항을 중복 질문하는 경우가 많았다.

 

그래서 노션에 질문과 답변을 위한 페이지를 아예 따로 만들어주었다.

질문에 대한 상태를 추적할 수 있도록 카테고리를 세분화하고, 노션을 활용함으로써 Figma보다 훨씬 상세하게 정보 전달이 가능하다는 이점을 취할 수 있었다.

 

그리고 디자인 팀에게는 UI의 version에 따라, 이전 UI를 보존해주길 요청했다.

이는 정말 중요한데, 갑자기 작업하던 UI가 수정되어 있으면 프론트 개발자 입장에선 상당히 난처해질 수 있었다.

 

📌 Error Log

그 다음으로 원인으로써 진단한 부분은 개발하면서 발생한 기술 부채나 에러에 대한 관리가 이루어지지 않고 있다는 점이었다.

그저 스크럼 리뷰 회의에서 QA를 하다가 발견한 문제를 깃헙 이슈에 추가하는 정도만 하고 있었을 뿐.

개발 도중에 인지했던 이슈는 개발자 개인이 잘 기억하고 있다가, 처리해야 하는 정도의 수준이었다.

 

https://en.wikipedia.org/wiki/Time_management

그래서 이번엔 아이젠하워 매트릭스를 도입하여, 이슈를 다음과 같이 구분했다.

1. 긴급하고 중요한 것 (주로 hotfix)
2. 긴급하진 않지만 중요한 것 (주로 infra, 핵심 domain)
3. 긴급하지만 중요하진 않은 것 (주로 기능)
4. 긴급하지도 중요하지도 않은 것 (자잘한 UI 오류 등)

 

다만, 깃헙 이슈를 등록하고, 다시 노션으로 들어와 태그를 설정한다는 것이 여간 귀찮은 일이 아니었다.

그래서 깃헙 이슈에서 카테고리를 설정할 수 있게 만들어주었으나, 팀원들이 긴급도와 중요도를 판단하는 것에 어려움을 느껴 관두게 되었다.

 

📌 Why hasn't the efficiency improved?

위 방법은 나름 효과적이었다.

(현직 개발자 분들께는, 무슨 학부생 프로젝트를 이렇게까지 관리하냐는 이야기도 들었지만 😅)

 

이전에 비해, 의사소통은 보다 원활하게 이루어지기 시작했고, 프론트와 디자인 팀의 마찰도 많이 줄어들었다.

그리고 PM으로서, 각 팀의 현재 상황을 보다 상세하게 관찰하고, 스프린트 우선순위를 유동적으로 조정할 수 있는 기준점을 제시해주었다.

 

하지만 여전히 iOS 팀에서 작업이 지연되는 현상은 여전했다.

 

---

3. Motivation

 

📌 Big Picture?

내가 살아가는 모습, 삶을 대하는 태도를 보고 영감을 얻는 사람은 많이 봤지만, 그렇다고 내가 리더쉽이 출중함을 의미하지는 않는다.

이건 내가 더 잘 알고 있는 문제점이었다.

특히나 팀 운영 경험이라고는 운동부, 군대, 멱살잡고 끌고가던 대학 프로젝트 정도밖에 없는 내게, "수평적 문화"라는 건 너무나도 이상적인 개념일 수밖에 없었다.

 

그래서 여전히 문제가 개선되지 않는 모습을 보고, '내가 명확하게 비전을 제시해주지 못 하고 있는 건가?'라는 의문도 들었다.

갑자기 이게 무슨 소린가 싶겠지만, 아무리 해도 진전이 되질 않아서 스트레스 받던 내게 친구가 해주었던 말이 있었다.

 

"너만 너무 프로페셔널해서 생기는 문제야."

 

위로해주기 위한 말이었겠지만, 이 말을 나는 다른 관점에서 프로젝트 상황을 바라보게 해주는 계기가 되었다.

 

개발이 너무 좋아서 이 길이 아니면 죽겠다는 마인드로 임하는 사람은 나 이외에 1명 정도가 다였다.

특히, 다른 팀에 비해 경험이 부족해, 자신감이 떨어져 있는 iOS팀에게 동기 부여를 해주는 것은 내게 중요한 숙제였다.

단순히 졸업을 위해서, 이 일을 맡았기 때문에 같은 이유가 아니라, 이 프로젝트가 자신의 것이 되도록 만들어야 했다.

 

실제로 이 문제로 한 차례 한 팀원과 다툼이 있었는데, 그의 주장은 이러했다.

1. "프로젝트 런칭"이 최우선 목표라 했으나, PR 리뷰 등을 중시하거나, 백엔드 개발이 iOS 개발보다 한참을 앞지른 상황에서 동시성 제어와 같은 추가 문제를 고려하는 점은 "학습"을 최우선하는 것으로 보인다. → 이걸 확실히 해달라.
2. 기술의 결정은 가장 못 하는 팀원에 기준을 맞춰야 한다. 동시성 제어를 위해 분산 락같은 기술을 도입해도 팀원이 이해하지 못 한다면, 거기에 어떤 의미가 있는가?

이 외에도 다른 이야기가 많이 오고 갔지만, 지금 내용과는 관련 없는 내용이므로 패스.

 

하지만 이건 MVP에 대한 정의가 서로 달랐기 때문에 발생한 오해다.

• 리뷰를 중시하는 것은 발생 가능한 버그를 최소화하기 위해서다.
  • 다만, 오해의 소지가 있을 수 있었던 것은 내가 "리뷰하면서 배우는 것이 있다"라는 말을 했기 때문일 수도 있다.
  • 이는 단순히 오류 검증 외에도, 리뷰를 열심히 하면 개인적으로도 남는 것이 많다는 의도였는데, 의미가 잘못 전달되었던 것 같다.
• 백엔드 개발이 앞서 있다고, iOS 개발을 돕는 것은 근본적인 해결책이 되지 않는다.
  • 백엔드 개발은 거의 내가 다 작업했고, 거기서 iOS 개발까지 돕는다는 것은 프로젝트를 나 혼자 하는 것이나 다름없다. (그런데 결국 방학 기간에 iOS 작업 몇 개를 내가 처리하긴 했다.)
• (2)의 주장은 기술 부채는 고려하지 않고 일단 런칭을 하자는 주장이지만, 내게 있어 MVP라는 것은 그저 굴러가는 무언가가 아니다. 적어도 핵심 기능은 문제 없이 동작한다.

 

위 사안은 팀원 전체에 내 입장과 상황을 명백하게 전달했고,

이후로 프로젝트의 방향성과 관련해서 더 이상의 의문은 제기되지 않았다.

 

하지만 당연히 이게 작업 속도를 개선시켜주지는 못 했다.

 

📌 Reward

방학 기간에는 뒤쳐진 작업 속도를 극한으로 끌어올리기 위해 극단적인 방법을 택했다.

스프린트 기간에 많은 태스크를 내주는 대신에, 기준 치 이상의 스프린트 달성률에 도달하면 밥을 사주었다.

(이걸 거의 5주 정도 했으니, 사비로 150,000 + α원 정도 턴 셈이다.)

 

이건 양날의 검이나 마찬가지라, 내기를 제시하면서도 걱정이 크긴 했다.

단기적으로는 달성률을 끌어올리는 데 도움이 될 수 있겠지만, 보상에 익숙해지면, 보상이 없어졌을 때 작업 진행도가 떨어질 수도 있기 때문이었다.

 

그럼에도 계속해서 작업이 지연되어 눈치를 받던 iOS 팀이, 이렇게라도 스스로 무언가를 이룸으로써 성과를 얻어 자신감을 얻는다면 장기적으로 효과가 있을 것이라 판단했다.

 

75%가 적어보이는가? 거의 5주 가까이 4일만에 태스크 15개 씩 쳐냈다.

예상대로 보상을 통해 달성률을 끌어 올리는 것은 성공적이었다. (역시 가장 확실한 동기 부여는 돈인가....)

 

그러나 이 쯤에서 무언가 이상하다고 생각했는데, 적어도 이렇게 많은 작업과 스프린트달성률을 채우는 기간 동안만큼은

프로젝트 진행률 또한 비례적하게 상승했어야 당연한 일이었다.

 

그런데, 프로젝트가 지연되는 것은 여전했다.

물론 극한으로 굴렸기 때문에 겨우겨우 방학 기간 끝물에 예정된 도메인을 완성하긴 했지만, 상당수의 디테일은 모두 버리고 진행한 상태였다.

 

여기서 내가 문제 원인을 잘못 파악하고 있음을 깨달았다.

챕터 4로 넘어가기 전에, 하나만 더 짚고 넘어가자.

 

📌 Eat Pray Coding

가장 오판은 공사를 철저하게 구분해야 한다는 내 태도가 아니었을까 싶었다.

 

비즈니스를 위한 관계에 사적인 모임과 뒷풀이를 가지는 것이 작업에 지대한 공헌을 하기란 어렵다고 생각했기 때문이다.

애초에 '뒷풀이'라는 것은 모두가 원해야 진행할 수 있는 거지, 한 명이라도 원치 않은데 강제로 데려가는 것은 옳지 않다고 생각했다.

 

하지만, 사람은 감정의 동물이고, 모두가 나처럼 비즈니스를 위해서라면 원수하고도 웃으며 마주보며 앉아있을 수는 없다는 게 현실이다.

 

애자일에서는 누구나 의견을 제시할 수 있도록 편한 분위기를 조성해주는 문화가 존재한다.

그러나, 기획 회의는 물론 스크럼 리뷰 회의에서 조차 그 누구도 프로젝트 진행에 대한 별다른 불만을 표출하지 않는 것이 상당히 스트레스였다. (없을 리가 없음에도 불구하고)

심지어 "여러분들이 이야기 해주시는 게 오히려 절 돕는 일이예요"라고 말했지만, 상황은 여전했다.

 

그러다 팀원 중 한 명과 마찰이 생긴 후에야 속에서 쌓아둔 이야기를 줄줄이 쏟아내는데, 내 입장에선 상당히 당혹스러운 상황이었다.

괜히 상황을 더 심각하게 만들지 않기 위해서 충분히 반박할 수 있던 내용들에 대해서도 다 사과를 하고 넘어가니, 이번엔 내가 스트레스로 번아웃이 오기 직전까지 몰렸었다.

 

그러다 내기로 인해 iOS 팀과 자주 식사를 하고, 그 과정에서 이전 동아리 대표 - 부원 관계로 조심스러워 하던 팀원조차 편하게 의견을 내놓는 것을 보고, 그제서야 내 생각이 짧았음을 인지하게 되었다.

 

너무 잦은 회식과 강요는 분명히 팀원에게 부담을 줄 여지가 존재한다.

하지만 그렇다고 나처럼 너무 모든 관계를 비즈니스로 대하면, 당췌 거리를 좁힐래야 좁힐 수가 없는 상황에 직면하게 될 수도 있다. (리더쉽이 출중한 사람이라면, 뭔가 좀 더 달랐을까?)

 

함께 먹고, 기도하고, 코딩하라.

그래야 팀원들이 보다 자유롭게 의견을 제시하고, 그 의견을 수용함으로써 프로젝트가 건강하게 흘러가기 시작한다.

 

---

4. Architecture Assessment

 

📌 What's the problem?

이전에 에러가 체계적으로 관리되지 않는 문제는 분명히 해소했었다.

그리고 작업 속도 또한 충분한 보상을 주어, 극단적으로 향상시키기도 했다.

그럼에도 작업은 왜 자꾸 지연되었던 것일까?

 

아래에 프로젝트 계획 회의의 안건을 보면, 이유를 알게 될 수도 있다.

분명 주마다 엄청난 태스크를 쳐내고 있지만, 문제는 태스크의 대부분이 이슈 핸들링이었다.

 

그렇다. 진짜 문제는 이슈가 너무 많이 발생한다는 점이었다.

기능 하나를 구현하면 이슈가 나오고, 그 이슈를 해결하면 또 이슈가 발생하는 게 문제였다.

 

여기엔 다음과 같이 추측을 해볼 수 있다.

• PM이 기능에 대한 충분한 설명을 해주지 못했다. (이건 추측이 아니라 사실. 그도 그럴게 작업량이 너무 많아서, 더 이상 세세한 문서를 만들 정도의 여유가 존재하질 않았다.)
• iOS팀이 부주의했고, 실력이 미숙하기 때문.

 

전자는 내 몸을 두 개로 나누지 않는 이상, 물리적인 한계로 더 이상 개선할 수 없는 영역이었다.

그렇다고 후자를 원인으로 지목하는 건, PM으로서 옳은 일도 아니었고, 애자일 원칙에도 맞지 않았다.

 

여기서 주목해야 할 점은 신기능을 개발하는데, 기존 기능에서 문제가 발생한다는 점이었다.

그래서 iOS팀의 코드를 전부 뜯어보면서 살펴보면서 그 원인을 깨달았는데, 코드에 어떠한 설계의 흔적이 존재하지 않는다는 점이었다.

그렇기 때문에 기존 코드에 새로운 코드를 덧씌우고, 컨벤션을 정했으나 그때그때 상황에 따라 대처하는 식으로 개발이 진행되므로 이슈가 겉잡을 수 없이 전파되기 시작한 문제였다.

 

백엔드는 이러한 문제를 사전에 방지하고자, 이미 처음부터 모든 개략적인 아키텍처 설계를 모두 만들고 시작했었다.

하지만 iOS팀에는 이러한 설계를 제시하거나, 도와줄 사람이 없었단 점이었다.

 

📌 Adopting Clean Architecture

[iOS] Clean Architecture 쉽게 이해해보기

그저 공부하라고 독촉할 수도 있었겠지만, 이제와서 이론부터 개인적으로 모두 공부하고, 그걸 프로젝트에 반영하기 위해 리팩토링을 한다는 것은 말도 안 되는 일이었다.

심지어 두 명이 서로 같은 수준의 이해 지식을 가지고 있어야 한다는 전제까지 뒤따라 붙어야 하니, 이건 더 이상 작업의 합리성을 납득시키거나 하는 영역의 문제가 아니었다.

 

그래서 개강 이후 4주 정도를 매일같이 모각코를 하면서 클린 아키텍처에 대한 교육을 실시했다.

이론을 가르친 이후에는 토이 프로젝트로 직접 아키텍처를 설계하고, 구현하는 작업을 수반했다.

 

물론, 클린 아키텍처를 도입해서 얻는 이점같은 건 공감조차 되지 않았을 것이다.

죽을 것 같다며 우는 소리를 내면서도, iOS팀은 나를 믿어주고 끝까지 따라왔고 프로젝트에 부분적으로나마 클린 아키텍처를 반영하는데 성공했다. (웹 소켓을 도입하기 위해, 가장 필요한 부분만 도입했다.)

 

너무 짧은 기간이었기에 완벽하게 이론을 주입시키지도 못 했고, 클린 아키텍처를 기반으로 설계하고 구현하는 것을 다소 어려워해 개발 속도 자체는 떨어졌다.

하지만 더 이상 이슈가 다른 이슈를 파생하는 문제가 현저하게 줄어들었다.

또한 명확한 설계를 기반으로 작업이 진행되니, PR 리뷰어로서 봐야 할 부분들이 명확해지게 되어, 리뷰의 퀄리티와 속도가 많이 올라갔다는 것이 확실히 구분되기 시작했다.

 

---

5. Conclusion

 

📌 Poop Umbrella

실리콘밸리의 프로덕트 매니저 vs. 한국의 기획자

PM을 겸하게 되면서, 프로젝트 시작 전에 정말 많이 참고했던 블로그였다.

(정작 문제 해결은 PM이 아니라, 개발자로서 하게 되었지만 😅)

 

실리콘밸리에서는 PM을 "똥 우산을 받쳐든 사람"이라고 부른다고 한다.

프로젝트 일정을 맞추기 위해 온갖 잡 일은 다하고, 개발도 다 하고, 일정을 맞추기 위해 팀원은 쪼아야 하다보니 미움도 가장 많이 사고, 공생 관계에 가까운 디자인팀은 문제가 생겨도 함부로 쪼지도 못 한다.

그렇다고 진짜 PM분들처럼 직함이 있거나, 월급이 나오는 것도 아니지 않나. ㅜ

억울함을 호소할 곳도 없으니, 진짜 다 엎어버릴까 생각한 적도 있었다.

 

그렇지만 스스로 생각해도 PM으로서, 개발자로서, 그리고 한 명의 사람으로서 많이 미숙했었다고 생각한다.

난 애자일을 나름 이해했다고 생각하고 패기롭게 도입하고자 했으나, 정작 그 문화를 함께 이끌어야 할 팀원들에게 충분히 설명하는 과정을 가볍게 여겨 실패하게 되었다.

 

이 글을 읽는 사람도 많이 없을 것이고, 그로 인해 도움이 될만한 사람이 있을 거라 보긴 더더욱 힘들겠지만

그럼에도 자아 성찰 및 자기 반성의 느낌으로 글을 남겨본다.