게임 개발이란 뭘까?

게임 개발 PM으로 일을 하면서 게임 개발은 뭘까하는 고민을 종종합니다.
다른 IT 서비스 종류와 다른 업과도 비교해서 생각하기도 하는데요.

제가 생각하는 다른 서비스들의 개발할 때의 예상되는 고민은…

• 보통 앱 개발이나 웹 서비스 개발은 어떤 특징을 가지고 있지?
  • 문제를 정의하고 문제에 대해 서비스로 어떻게 해결할 것인지 접근하지 않을까?
  • 문제를 해결하지만 최종적으로는 사용자에 집중하여 해결에 접근하지 않을까?
• 이커머스(e-commerce)는 어떤 특징을 가지고 있지?
  • 구매자, 판매자를 잘 연결해줘야겠지
  • 구매자 경험, 판매자 경험도 중요하다. 두 종류의 사용자가 겪는 문제도 해결해야겠지
  • 요즘은 물류, 배송에 대한 고민도 더 많아지지 않았을까

잠깐잠깐 생각했던 내용을 정리해본 내용이어서 정확하지 않거나 막연한 내용일 수 있습니다. :)

이런 서비스들과 비교했을 때 게임의 핵심 고민은 어떤 재미를 줄 수 있을까인 것 같습니다.

• 내가(우리가) 좋아하는 게임 장르를 개발한다!
  • MMORPG를 만든다! 협동 콘텐츠! 스토리!
  • 나는 정통 FPS!
• 많은 사람들이 좋아하는 게임 콘텐츠를 개발한다!
  • 요즘 뜨는 게임 장르는 배틀로얄이니 이거랑 성장 요소를 끼워볼까?

게임 개발은 어떤 문제를 해결한다, 페인 포인트(Pain Point)를 해결한다 보다
재미있는 콘텐츠를 만드는 것이 중요하다고 생각합니다.
다만 그런 재미는 콘텐츠의 완성도 뿐만 아니라 사용자들의 게임플레이 성향, 취향 등에 따라 달라질 수 있다고 생각해요.

이런 고민을 하다가 얼핏 생각해보니 게임에서의 **”재미”**는 요식업이랑 **”맛”**이랑 비슷한 느낌이 있었습니다.
그러다가 한번 비슷한 요소들을 묶어서 그려보자는 생각이 들어서 아래와 같은 그래프를 그려보게되었어요.
(영화는 게임과 콘텐츠 산업 구조가 비슷하지 않을까해서 같이 넣어보았습니다.)

생각1: 게임, 음식점(요식업)과 영화랑 비교해볼까?

게임, 음식점, 영화 각각 비슷한 특징은 각 열(row)에 배치해보았습니다.
게임에서 버그가 발생하는 거랑 음식점에서 벌레(위생)가 나오는 것은 둘 다 치명적인 문제로 같은 층에 배치해보았습니다. 😸
(나름 재미있다고 생각한 포인트인데 쓰고 보니 별로 재미없네요 🐛 재미없으면 버그야…)

제가 생각하는 각 카테고리의 핵심은 음식점은 맛, 게임&영화는 재미로 정리해볼 수 있었습니다.
음식점을 맛이 아닌 다른 이유(사장님과의 친분, 가게 인테리어)로 갈 수 있지만
사람들이 자주 찾아오고, 단골이 생기고 다른 사람들에게도 추천할 수 있으려면 음식점은 음식의 맛이 중요하다고 보았습니다.

게임도 마찬가지로 다른 요소가 뛰어나더라도 재미가 없다면 지속될 수 없다고 생각합니다.
다른 요소들이 뒷받침해서 게임의 재미가 돋보일 수 있도록 도울 수는 있겠지만 핵심은 재미가 있어야죠.

여기서 영화는 게임, 음식점과 조금 다른 카테고리인 것 같아 점선으로 분리해두었습니다.
영화는 게임에서의 알파 테스트나 음식점에서의 신메뉴 테스트 등을 못하지 않을까? 하는 생각과
실제 사용자에게 가기 전까지의 비용이 많이 든다는 점이 다른 것 같았습니다.

지금 추가로 찾아보니까 영화 시사회 중 기술 시사회가 어느정도 알파 테스트까지는 아니더라도 베타 테스트까지는 역할을 하는 이벤트가 아닐까 싶네요.
다만 기술 시사회도 이미 어느정도 완성된 영상을 보여주는 것이라 얼리엑세스 같은 느낌에 더 가깝겠네요.
영화 프로덕션에 대한 내용은 아래 링크에서 더 보실 수 있습니다.

• https://www.kmdb.or.kr/story/152/3301
• https://m.blog.naver.com/yangbsun/222073262933

물론 게임도 실 사용자에게 가기 전까지 많은 비용이 들긴 합니다만..
게임은 영화에 비해 사용자 피드백을 받고 지속적으로 개선할 수 있는 형태이지 않을까 싶었습니다.
(예전에는 패키지 게임/CD 게임은 판매 후 패치하기 어려운 시기가 있었지만 지금은 아니니까요. 😸)

음식점도 임대하고 가게를 임대하는 데에 있어서 비용이 적지 않게 들어가지만
음식점을 오픈하고 메뉴를 바꿀 수도 있는 것이고 손님 피드백을 받아서 개선해나갈 수 있다고 보았습니다.
요즘은 공유 오피스처럼 주방도 공유 주방이 생기고 있는 시대라 초기 비용에 대한 부담도 줄일 수 있는 시대이기도 하니까요.

생각2: 게임은 흥행 산업일까?

사실 게임이 흥행 산업이라는 이야기를 많이 들어서 영화와 슬쩍 비교해본 것이긴 합니다.
(흥행이라는 말 자체가 “대중을 상대로 하여 연극·영화·서커스·쇼 등의 볼거리를 영리 목적의 사업으로서 공연하거나 상영하는 일.”이라 어원은 영화에서 비롯되었다고 볼 수 있겠네요.)

재미라는 것 자체가 “이거 재미있다더라”, “같이 보자(하자)” 등이 연결되어서 흥행이 될 수도 있고
유명한 크리에이터, 스트리머들이 좋은 리뷰를 하더라도 흥행이 부스트 될 수 있는 것 같습니다.
(장기적인 흥행 부스트가 될지는 스트리머의 인지도 및 관계, 협력에 따라 달라질 수 있겠죠)

계속 흥행을 유지하려면, 게임을 즐기는 다양한 유저들이 지속적으로 재미를 느낄 수 있도록 핵심 재미와 다양한 맛을 골고루 줘야 한다고 생각합니다.
마블(Marvel) 처럼 마블 시네마틱 유니버스를 통해 다양한 캐릭터에 대한 서사와 세계관을 보여주는 것처럼 팬들이 꾸준히 찾고 즐길 수 있는 콘텐츠를 만들어가야 하지 않을까 싶습니다.

음식점의 경우에는 다양한 손님을 만족시키기 위해 신메뉴를 개발해야겠지만 기존의 맛을 찾는 손님들도 더 맛있게 먹을 수 있는 방법을 고민해야하는 측면에서 약간 결이 다른 것 같기도하네요.

결국 어떤 곳이든 흥행을 하더라도 지속하려면 팬(Fan)이 남아서 또는 팬을 남겨서 핵심 요쇼를 계속 즐길 수 있도록 해야겠죠.

생각 마무리

엔지니어로 소프트웨어(앱, 웹서비스)를 개발하다가 처음 게임 개발에 개발 PM으로 와서 처음으로 게임 개발과 관련한 글을 써보는 것 같네요. 사실 게임 개발을 하고 계신 분들 중 은둔 고수 시니어분들이 많아서 이런 생각을 정리해서 글을 써본다는 것 자체가 뭐랄까 코끼리의 코만 만져보고 “코끼리는 뱀 같은 동물이다”는 사람이 될까 싶기도 합니다. 😇

그래도 나름 이런 생각을 하면서 우린 어떤 업계에서 살고 있을까 하는 고민도 해볼 수 있어서 재미있었습니다.
다음 고민, 공부로는 “게임 개발 알파, 베타 테스트는 뭘까”를 정리해볼까 합니다. 😏

제 생각에 정정이 필요한 내용이나 첨언이 필요한 내용이 있다면 편하게 댓글로 남겨주세요!
읽어주셔서 감사합니다. 😸

크래프톤 웨이 책 소개

• 크래프톤 웨이

크래프톤(블루홀)이라는 회사가 어떻게 시작되었고 살아왔는지 보여주는 책입니다.
경영진의 입장에서 게임 개발 회사가 성장보다는 어떻게 살아남았는지, 어떤 고민들을 했는지를 볼 수 있습니다.

책에 대한 소개는 링크에서도 보실 수 있으니 바로 감상평으로 넘어가겠습니다 😸

감상

책은 재미있게 술술 읽힌다!

시간순으로 내용이 작성되기도 했고 당시의 결정이나 고민들이 간접적으로 느껴져서 시간가는 줄 모르고 읽었습니다. (300장이 넘지만 3-4일안에 다 읽은 것 같네요)

한편으로는 경영자의 시야와 실무자, 직원 입장에서는 다르게 느꼈을 수 있겠구나하는 관점의 차이도 알 수 있었네요.

지금까지 알지 못했던 크래프톤(블루홀) 초창기 모습, 초기의 어려움을 알 수 있어 좋았다.

저는 2018년 초에 PUBG(펍지)에 입사한 사람이어서 당시 블루홀이 어떤 회사인지, 연합군은 무엇인지 사실 지금까지도 잘 알지 못했습니다. (관심이 크지 않았다고 말할 수 있겠네요.)

이 책을 보면서 회사 초기의 모습을 어렴풋이 알 수 있어서 좋았고 회사 초기 어려움들을 조금이나마 느낄 수 있어서 느낀점이 많았습니다.
(느낀점이 많다고는 했지만 모두 자세하게 나열하기는 어렵네요. ㅎㅎ)

• 블루홀의 뜻을 이제 알았고 블리자드와 연관된 것도 처음 알았네요.
• 종종 블라인드에서 크래프톤 경영진, 리더십에 대한 무책임함에 대한 이야기가 있었는데 이런 일들 때문에 그럴 수 있었겠구나 이해할 수 있었습니다.

블루홀의 비전이었던 “MMORPG 제작의 명가”는 지금 “제작의 명가”로?

책을 읽으면서 지금은 어떻지? 하면서 읽었네요. 지금 크래프톤에 있기에 그런 생각을 하면서 읽게된 것 같습니다.

우리에게 그 비전을 계속 이야기하고 있나? 어떻게 하면 모두가 그 비전을 동일하게 생각할 수 있을까?
스튜디오, 본부, 실(유닛), 팀으로 비전이 스며들어 있을까? 하는 생각이 들었습니다.

그리고 연합군이 목표했던 바를 이루고 있는가도 궁금해졌어요.
크래프톤이 퍼블리셔에게 단일팀보다 더 큰 존재가 되었는가, 경쟁우위가 생겼는가 말이죠.

책의 마지막 부분에서의 PUBG

크래프톤 웨이에는 대부분 블루홀 때의 이야기가 많았고 후반부에 PUBG, 지노 게임즈에 대한 이야기가 나옵니다.
이런 흐름만 봤을 때 책에는 지금까지 쓰여온 블루홀, 크래프톤의 시작에 대한 (경영자 시점의) 역사가 쓰여있습니다.

창한님이 크래프톤 CEO가 되고 그 이후의 길들은 또 다음 책에서 쓰여질 수 있겠네요.

마무리

저는 이 책을 회사에서 나눠주어서 볼 수 있었는데요. 나름 재미있게 보았습니다.
주변 스타트업에서 리드로 일하시거나 대표로 일하시는 분들은 다들 잘 읽었다고 하시는 것 같았는데
반대로 사측의 내용이 많다는 의견도 들었네요. 아무래도 경영자의 관점에서 풀어낸 책이어서 그럴 수 있을 것 같습니다.

두 측면에 이야기가 모두 이해가 되기도 해서 고민을 많이해볼 수 있어서 좋았던 책이었습니다.

테크니컬 리더 책 소개

• 테크니컬 리더
• Becoming a Technical Leader

원서는 1986년에 나왔고 2013년에 번역되어 국문으로 볼 수 있게되었습니다.
혁신, 동기부여, 조직화를 통한 문제 해결 리더십 라는 제목으로 소개되어있습니다.

짧은 소개

이 책에서는 앞서 짧게 소개했던 3가지(동기부여(M), 조직화(O), 혁신(I))를 통해 문제 해결 리더십에 집중합니다.
문제 해결형 리더십을 정의하고 MOI 모델을 만들어보면서 어떻게 문제를 해결해나갈지 각 장 마지막에 질문을 통해 고민해봅니다.

책 뒤에 있는 추천사에 김창준님이 적어주신 내용이 꼭 맞는 것 같습니다.

이 책은 읽는 책이 아니고 경험하는 책이다. 매 장 끝에 나오는 질문들 하나하나를 귀중히 여겨 고민해보고 직접 종이에 답을 쓰고, 믿을 만한 사람들과 그 답을 공유하고 토론하고, 또 해보라는 실험은 모조리 해보도록 노력하라.
그렇게 한다면 아마 여러분들은 나와는 매우 다른, 그러나 매우 유사한 어떤 경험을 하게 될 것이고, 이 책에게 그리고 와인버그에게 매우 고마워하게 될 것이다. - 김창준, 애자일 컨설팅 대표

물론 저는 PM으로 테크니컬 리더는 어떤 사람일까, 어떤 사람이고 싶은걸까 하고 궁금증에 읽어보아서 질문 항목을 성실히 답변해보지는 못했습니다.
다만, 질문 내용을 보았을 때 테크니컬 리더 뿐만 아니라 리더라면 고민해봐야할 내용이 많았어요.

책을 읽으면서 공부하고 이해한 내용을 중심으로 리뷰해보겠습니다.

MOI 모델?

맨 처음에는 MOI가 뭐야 했는데 사실 책 소개 앞에 이야기했던 혁신, 동기부여, 조직화였습니다 😂
하나하나 살펴보면 다음과 같네요.

• 동기부여(Motivation): 위협하거나 보상하거나, 밀거나 당겨서 관련 있는 사람을 움직이도록 만드는 일
• 조직화(Organization): 아이디어 실현이 가능하도록 만드는 구조
• 아이디어(Ideas) 또는 혁신(Innovation): 씨앗, 실현될 것의 이미지

책에서는 이 3가지에 집중해서 성공적인 테크니컬 리더로 나아가야하는 방향을 설명합니다.
각 2부(혁신), 3부(동기부여), 4부(조직화)에서 상세 내용을 다루고 각 장에서는 질문을 통해 내용들을 같이 고민해볼 수 있었습니다.

22장 변화 계획

다른 장들도 읽고 질문에 답을 해보는 것이 좋았지만 저는 22장이 기억에 남아서 따로 남겨봅니다.
(실제로 업무를 하면서 고민했던 점도 있었어요 ⭐️)

이 장에서는 혁신과 관련하여 변화에 대해 이야기합니다.
변화를 어떻게 이끌어나갈 것인가, 새로운 것에 대해 거부하는 자연스러운 현상을 어떻게 계획해서 극복할 수 있을까 등을 고민해봅니다.
책에 있는 방법을 살짝 공유해보면 다음과 같습니다.

1. 개인적 달성 목표를 세운다. 목표는 안전하고 새로운 것이며 스스로 해낼 수 있어야한다. 도달한 성과 수준을 곧바로 알 수 있어야 한다.
2. 첫날에는 성과의 기준선을 정한다. 그 다음 적어도 하루에 한번 연습하고 매일 일기에 진행 상태를 기록한다.
3. 마지막 날에는 성과를 보여줄 수 있도록 준비하고 달성을 위해 노력하면서 무슨 일이 일어났는지 이야기한다.

달성 목표, 계획을 세우는 것 자체가 어떤 것을 이루려는 방법을 배우는 것이라고 생각합니다.
어떤 변화를 위해서라면 변화하고자 하는 목표와 계획을 세우고 진행해야한다는 것을 알 수 있었습니다.
(어찌보면 되게 당연한 말인데도 정리해본적은 없다보니 새로운 것을 배운 느낌이긴하네요. 😂)

22장의 질문은 작은 기술을 매일 연습하고 기록하는 것, 지금까지 어떤 교육 과정에 참여하고 무엇을 배웠는지 등을 생각해보는 것이 있었습니다.
과거에 어떤 교육을 받았고 향후에는 어떤 교육을 받을 것인지도 질문에 있어서 계획을 세우고 공부해라 정도로 질문을 이해하긴했습니다.

이 챕터를 읽으면서 개인적인 달성 목표 매일 업무 일지(업무 회고)를 작성하는 것을 하고 있는데요.
사실 매일 일기쓰기 같은 느낌이어서 종종 피곤하면 빼먹고 몰아쓰기도 하고 있습니다.
마지막 날(매월 말일)에는 월말 회고를 계획하고 있는데 최대한 빼먹지 않고 열심히 써보려하고 있어요. 💪

테크니컬 리더: 테크니컬 리더를 위한 책

책 자체가 두껍긴 한데 테크니컬 리더가 어떤 고민을 하면서 살아가야하는지를 알려주는 책이라고 생각합니다.
질문 내용을 모두 고민하고 살기는 어렵겠지만 하나하나 실천해보면 좋은 리더로 나아갈 수 있지 않을까 싶었어요.

전에 리뷰를 작성했던 Book review: 개발 7년차, 매니저 1일차 이 책보다는 어렵다는 생각은 했습니다.
테크니컬 리더는 뭘해야하지? 어떤 고민을 하면서 살아야하지? 하는 고민을 크게 하시는 분들이라면 집중해서 읽어보기 좋을 것 같고,
리더가 된지 얼마 되지 않았다면 개발 7년차, 매니저 1일차를 입문서로 읽어보시는 것을 추천합니다. 👍

책 내용은 많았지만 제가 느꼈던 내용을 중심으로 짧게 책 리뷰를 해보았습니다.
저는 몇 가지 책갈피해둔 질문들을 리더로 일을 하면서 한번씩 되돌아보려고 합니다.
(테크니컬 리더가 아니더라도 일반적인 리더가 고민하면 좋은 것이 많아서요. 😈)

개발 7년차, 매니저 1일차 책소개

• yes24-개발 7년차, 매니저 1일차
• Oreilly-The Manager’s Path

추천

책 뒤에는 아래와 같은 사람들에게 추천한다고 되어있습니다.

• 개발자 VS 매니저 갈림길에 서있는 사람
• 개발자 관리를 체계적, 효율적으로 하고 싶은 사람
• 내 사수가 사수 역할을 못해서 내가 고생 중인 사람

정말 개발(여기서는 엔지니어링)을 해왔던 사람이 어느 날 팀을 맡았다면 어떤 것 부터 해야할지, 어떤 것을 고민하고 팀을 운영, 매니징해야하는지 하나하나 잘 설명해주었습니다.
어떤분들에게 어떤 내용들이 도움이 될지 간단하게 추천해보고자 합니다. (사실 서평처럼 써보려고 했으나 가볍게 추천한다고 보시면 될 것 같습니다. 😸 )

참고: 여기서 매니저는 “프로젝트 매니저”할 때의 매니저 보다는 팀장, 실장 등 엔지니어링 팀을 관리하는 매니저로 보시면될 것 같습니다.

주니어 엔지니어, 엔지니어링팀 팀원들을 위한 추천 장(챕터)

책에 있는 챕터 별로 매니저가 하는 일, 해야하는 일을 설명하고 있는데요.
그 중에서 주니어, 팀원들이 읽으면 좋을 만한 이야기들이 있는 장은 초반에 있는 장입니다. (+ 9 문화 개선 챕터)

• 1. IT 관리 101
• 2. 멘토링
• 3. 테크리드
• 4. 사람관리
• 9. 문화 개선

위 챕터들에서는 처음 매니저 업무를 시작하거나 어떤 커리어 패스를 고민해야하는지를 설명합니다.
1~4의 챕터들에서 많이 나오는 항목은 원온원(1 on 1) 미팅입니다.

원온원(1-on-1) 미팅

원온원 미팅은 팀장-팀원이 1:1로 업무, 개인 이슈 등 여러가지 이야기를 하고 피드백을 하는 미팅으로 이해해주시면될 것 같습니다.
이 원온원 미팅은 매니저가 주도적으로 할 수도 있지만 팀원도 같이 참여해서 어떤 이야기들을 할지 고민하고 참여해야한다는 점에서 주니어 엔지니어도 알아두면 좋을 내용이라고 생각했습니다.

주니어 엔지니어, 팀원들은 프로젝트 업무 외에도 커리어와 개인적인 일들을 매니저와 이야기할 수 있는 자리가 있어야합니다. 팀으로 같이 잘 일하기 위해서는 서로 공유해야하는 미팅이 필요하지요.
팀장, 팀원은 팀으로 일하기 위해 서로에게 신뢰를 쌓아야한다고 생각합니다. 잡담이나 티타임 정도로도 신뢰가 쌓일 수 있겠지만 팀으로 일하는데에 업무 신뢰도가 쌓이려면 조금 더 업무와 관련한 이야기를 집중해서 할 수 있는 자리가 필요하다고 생각합니다.
이러한 역할을 원온원 미팅이 할 수 있을 것으로 책에서 이야기하고 있습니다.

물론 어떻게 미팅을 진행하냐에 따라 신뢰를 잃을 수도 있겠지만요 😂

책에서는 원온원 미팅 처음을 어떻게 시작하면 좋은지, 어떻게 진행해나가면 좋을지를 짚어주어서 좋았습니다.
제가 완전히 주니어일 때 이 책을 보았다면 이런 것도 있군! 하고 팀장님에게 이야기하고 해봤으면 좋겠다고 이야기했을 것 같네요.

지금은 프로젝트 매니저로 일하고 있기에 어떻게하면 팀이 일을 잘 만들고 진행할 수 있을지를 더 많이 고민하고 있습니다. 😀

시니어 엔지니어, 팀장이 될 예정이거나 팀장인 엔지니어

사실 팀장이 될 예정인 혹은 팀장이 되었지만 어떻게 해야 할지 혼란스러운 엔지니어분들에게는 꼭 읽어보고 이런 방법도 있구나 하고 하나둘씩 적용해보았으면 좋겠습니다.
주니어 엔지니어에게 추천했던 챕터를 먼저 읽어보고 그 뒤로는 매니저 커리어 패스를 잡을 때 참고하면 좋을 것 같다는 생각을 했습니다.

추천하고 싶은 내용 중에서는 3장 테크 리드, 4장 사람관리를 추천하고 싶습니다. 엔지니어링 팀장을 맡으면서 태스크 관리나 팀원 관리에 대한 이야기가 튜토리얼로 해볼 만한 것들이 많았습니다.
예를 들면, 테크 리드의 기본 역할(주요 역할), 팀원과 관계 맺기 (신뢰 관계 구축하기) 등 매니저가 되면 어떤 것들을 신경 써야 하는지를 알 수 있는 내용들이 Getting Started와 같은 내용이라고 생각합니다.

여기서 원온원 미팅 스타일도 나열해주었는데 살펴보면 아래와 같습니다.

• 할 일 목록 점검 미팅: 업무 목표를 정리하여 논의하고 우선순위에 따라 각 업무 목표를 다룸.
• 팀원의 이야기 듣기: 팀원의 이야기를 듣는다. 다만 위로하고 불평을 듣기만 하는 자리라면 무의미해지는 것을 조심해야 함.
• 피드백 미팅: 비공식적인 피드백, 코칭 시간으로 활용. 개인 목표나 회사 내 목표 등 진행 사항을 같이 검토할 수도 있음.
• 진행보고 미팅: 프로젝트 세부 사항을 논의하는 시간이 될 수 있음. 프로젝트와 무관한 내용을 이야기하는 방법도 같이 해볼 수 있겠으나 상황에 따라 미팅 빈도를 줄이는 것도 고려해야 함.
• 인간적인 관계 강화 미팅: 팀원의 사생활 캐묻기가 아닌 팀원 개인에게 인간적인 관심을 갖고 이야기하는 것. 미래 목표를 묻는 것도 괜찮음.
• 다양한 방식으로 시도하기: 산책이나 커피, 점심을 먹으며 미팅을 할 수도 있음. 다만 민감한 주제를 이야기할 수 있도록 방음이 잘되는 회의실에서 하는 것도 고려해야 함.

여기서 마지막 조언으로 공유 문서에 미팅 노트를 작성해서 팀원들과 공유하는 것을 짚어주었습니다.
어떤 피드백을 받았는지 서로 알 수 있고 기억할 수 있는 점과 나중에 성과 평가할 때나 다른 피드백을 줄 때 기억하기 쉬운 점에서 조언을 주었습니다.

이후에는 좋은 매니저, 나쁜 매니저를 이야기하는데 이 부분도 추천하고 싶네요.

“좋은 매니저, 나쁜 매니저: 마이크로 매니저, 위임하는 매니저”를 제목으로 썼는데 정말 위임을 어떻게 해야 할까에 대한 내용은 “효율적으로 위임하기 위한 실질적인 조언”에서 볼 수 있었으니 참고하시면 좋을 것 같습니다.
맛보기로 부제들의 내용을 나열해보겠습니다. 어떻게 보면 누구나 말할 수 있는 내용일 수 있겠지만 초보 매니저로서 겪는 문제를 해결하는 데에 좋은 표지판이 될 수 있다고 생각합니다.

• 팀의 목표를 통해 어떤 세부 사항을 파악해야 하는지를 판단하라
• 팀원을 만나기 전에 시스템에서 정보를 수집하라
• 프로젝트 단계에 따라 확인할 부분을 달리하라
• 코드 및 시스템 표준을 설정하라
• 좋은 정보든 나쁜 정보든 중립적 태도로 정보를 개방하기

이후의 챕터들도 모두 참고할 만한 내용이 많으니 읽어보시면 좋을 것 같습니다.

마치며

처음으로 책을 읽고서 추천해봅니다. 사실 자기 계발서에 가까운 책이긴 합니다.
자기 계발서를 꺼려하시는 분들에게 말씀드리고 싶은 점은 매니저 튜토리얼 책으로 봐주시면 어떨까 합니다.
매니지먼트 책 중에서 엔지니어가 빠르게 읽고 적용해볼 수 있는 책이라고 생각합니다.

• 매니저로 일을 시작하면서 겪는 것이 엔지니어링 하면서 겪는 것보다 사람 관리, 팀 관리가 더 어려운 것 같습니다.
• 컴퓨터에 대한 문제는 구글링이나 스택오버플로우에 검색해보면 나오 기라도 하지.. 관리는 어떻게 하면 팀이 일을 잘하게 할 수 있을지 등 많은 것을 생각해야하기도하구요.

제가 이 책을 보고 크게 와 닿았던 것 중에 하나는

• 코딩, 개발 업무는 Quick Win이 가능하다.
  • 구현 후 빠르게 결과를 볼 수 있다는 것인데 이 이야기는 곧 빠른 피드백을 받아볼 수 있는 것
• 반면 관리(매니징)는 여러 요인으로 인해 Quick Win이 힘들다.
  • 때로는 조직의 복잡도로 인해 문제 해결이 오래 걸릴 수도 있고, 개개인의 사정이 있어 시간이 걸릴 때도 있고 등등
  • 이런 차이로 인해 엔지니어 업무를 하다가 매니징 업무로 가기 더 어렵기도 하다는 것

어렵지만 누군가 해야 하는 관리 업무를 모두가 잘 헤쳐나갈 수 있었으면 좋겠습니다. 🙏
매니저, 팀장이 되고자 하는 분들, 지금 팀장을 하고 있는 모든 분들이 이 책을 보고 매니저 업무에 도움이 되었으면 좋겠습니다.

Tech PM(Project Manager)이란 무엇일까?

지금까지 약 2년 동안 개발 PM으로 일해왔는데, 내가 상상하고 생각했던 개발 PM이 지금 하는 일과 같은가? 하는 내안의 질문이 있었다.

개발자(엔지니어)로 앱 개발하다가 개발 PM으로 전직하고나서 전직 전에 내가 생각했던 일을 하고 있는지, 내가 잘알고 있었던 것인지 되짚어보고 싶어졌다.

내가 생각했던 Tech PM부터 한번 알아보고, 내가 왔던 길과 가야할 길을 정리해보고자 한다.

Tech PM 구글에 찾아보면…

구글에 Tech PM이라고 검색해보면 그렇게 많은 내용은 나오지 않는다. 아래 링크를 보면 대략적인 기술 PM의 역할을 볼 수 있지만.. 내가 알고 있는 개발 PM의 일반적인 내용을 담고 있어서 “기술 PM이 그래서 뭐가 다른 것이지?” 하는 의문이 있었다.

https://www.wrike.com/project-management-guide/faq/what-is-technical-project-management/

링크에 있는 내용을 정리해보면 3줄 정도로 요약해볼 수 있다.

• IT 프로젝트에서 기술 지식 기반으로 프로젝트를 관리할 수 있음.
• 기본적인 프로젝트 매니저가 하는 일을 함.
• 큰 그림도 볼 줄 알아야하며 전반적인 기술 지식도 있어야 함.

결론, 소프트웨어 개발 PM으로 일하는 데에 어려움이 없을 정도로 지식이 있는 PM이면 된다.
(너무 일반적인 내용이라서 자세하게 안본 탓도 있는 것 같지만, 뭔가 딱 이거야! 하는 내용이 없었다.)
이 정도 내용으로는 내가 생각하는 기술 PM이 설명되지 않은 것 같아 더 찾아보기로 했다.

Technical PM 업무 소개서(Job Description) 보기

다른 회사의 기술 PM 업무 소개서를 보면 알 수 있지 않을까?로 시작된 조사!

https://www.indeed.com/m/jobs?q=Technical+Project+Manager

• 몇 가지 JD를 보면서 각 회사마다 원하는 바가 많이 다르다는 것을 알 수 있었다.
• Oracle, IBM 등 IT 솔루션을 판매하는 회사의 경우 내부 기술 PM이라기보다 기술 영업 PM의 느낌이 강하다.
  • 기술을 이해하며 해당 솔루션을 영업하는 업무
  • 기술적인 부분에 대해 고객과 커뮤니케이션하는 TAM(Technical Account Manager)
• IT 회사가 아니지만 기술 PM이 필요한 경우에는 내가 지금하고 있는 개발 PM과 다를 것이 없는 듯 하다.
  • 일반적인 IT 서비스 개발 PM (일반적이라는 말이 모호하긴하지만 더 좋은 표현은 못찾겠다.)

TAM(Technical Account Manager)은 또 뭐지?

그러던 중 TAM과 관련한 내용도 계속해서 나오길래, 한번 찾아보게 되었다.
https://www.buzzvil.com/ko/2018/12/26/buzzvil-people-jen-yoon-technical-account-manager/

• 버즈빌에서 TAM 업무를 하고 있는 분의 인터뷰 글.
• 연동 문서 관리 / 내외부 이슈 해결 / 프로세스 세팅 및 개선 업무를 하고 있다고 한다.

https://cloud.google.com/tam/?hl=ko

• 구글 클라우드에서 TAM 팀은 약간 컨설턴트 느낌이다.
• 다른 TAM도 마찬가지이긴 한데 구글은 B2B 관련 일이 많아 그런 것 같다.

https://aws.amazon.com/ko/careers/support/employee3/

• AWS의 TAM 업무 소개 페이지.
• TAM이 하는 업무에 대해 소개하고 지원 버튼이 밑에 있다.

Technical Program Manager도 있네?

https://www.amazon.jobs/en/jobs/990061/technical-program-manager

찾다보니 내가 하고자했던 것이 기술 프로그램 매니저였을까 하는 물음표가 생겼다.

처음에 내가 하고싶었던 일이 프로젝트 매니저였는지 프로그램 매니저였는지 모호한 상태이고, 회사마다 PM의 정의가 다르기 때문에 이 용어를 분리해서 이야기하는게 큰 의미는 없을 수 있다.
(참고 링크: “프로덕트, 프로그램, 프로젝트 매니저? 뭐가 다른가요?” )

다만 내가 원했던 일은 엔지니어 경험을 활용해서 개발팀의 전체적인 프로세스가 잘 진행될 수 있도록 돕고 싶었고, 일이 효율적으로 진행될 수 있도록하고 싶었다.

위 참고 링크에서는 프로그램 매니저, 프로젝트 매니저를 이렇게 설명한다.

• 프로그램 매니저는 제품을 어떻게 에 모든 열정을 쏟는 역할
  • 어떻게 제품을 만들지, How에 집중하는 역할로 이해했다.
• 프로젝트 매니저는 제품을 언제 에 관심이 있는 역할
  • 제품을 언제까지 만들 수 있을지, 언제 내보낼 수 있을지 When에 집중하는 역할로 이해했다.

정리해보면 전직 전에는 “어떻게 개발을 잘할 수 있을까” 같은 고민을 하면서 일하겠지? 했지만, 지금하고 있는 일은 언제 출시할 수 있을지 관리하는 프로젝트 매니저일을 하고 있는 것 같다.
(물론 전체 조직의 개발 생산성에 관심이 많아 생산성을 올릴 수 있는 도구들도 도입해보고 개발해보는 등 프로그램 매니저일도 약간은 하고 있다는 생각도 든다.)

Tech PM, 프로젝트 매니저든 프로그램 매니저든

맨처음으로 돌아가서.. 내가 하고싶어하는 Tech PM의 정의는 무엇일까 정리해보자.
이 글을 쓰기 전에 페이스북에 “여러분들이 생각하는 Tech PM(Technical Project Manager)는 어떤 모습인가요?” 질문을 올렸었는데, 회사 동료분의 말이 와닿아서 같이 정리해본다.

PM도 포함해서 사람들이 모호하게 정의한다고 생각해요. 프로그래머에게 바라는게 무엇인가요? 하는 느낌같은…? 상황, 경험과 역량에 따라 천차만별이 아닐까요?

회사마다 PM을 정의하는게 다르고 팀마다 다르고 경험과 역량에 따라 다 달라진다는 것을 한번 더 확인받은 기분이었다.

정리하다보니 더 심플해지는 것 같지만, “어떤 역량과 경험을 가지고 일하는지에 따라 PM 역할은 달라질 수 있다. Tech PM이라는 역할에 갇히지말고 역량을 키우자” 정도로 내 생각을 마무리해본다.

위에 있는 정리된 내용으로 기본적인 Tech PM 정의는 된 것 같지만, 아직 한국에서는 PM의 명칭, 역할이 명확하게 구분되어 있지 않아 딱 이거다하는 정의는 어려운 것 같다.

이정도로 생각을 마무리해본다.
다음 글에서 더 성장한 생각의 글을 쓸 수 있기를!