<div id="readability-page-1" class="page"><div><p><img src="https://velog.velcdn.com/images/joosing/post/fb19f170-39ae-4242-8605-1e5fe7ab2116/image.png"></p>
<p>회사를 떠나며 그 동안 해왔던 일들을 글로 정리하고 동료들에게 가르쳐 주는 일을 2개월 가량 했습니다. 인수인계 과정을 진행해 나가며 동료들이 제 공백을 잘 매꾸어 줄 수 있겠단 생각이 들었습니다. 그런데 몇 일 전 문득 매니지먼트에 대한 일들이 생각났습니다. 이 일들은 인수인계가 가능한 건지, 동료들이 이런 공백들 역시 잘 매워 줄 수 있을지 스스로에게 질문하게 되었습니다. 그리고 이곳에서 매니지먼트와 관련해 제가 잘 했다고 생각하는 것들, 반대로 잘하지 못한 것들, 그렇지만 필요했고 내가 성장하고 싶은 목표가 되어준 것들에 대해 생각하게 되었습니다.</p>
<h2 id="1-같은-푯대-바라보기">1. 같은 푯대 바라보기</h2>
<p>주니어 시절에는 잘 몰랐습니다. 시니어 개발자로 한 걸음 한 걸음 나아가다 보니 팀에서 이것이 무척 중요함을 절실히 느낍니다. 바로 ‘같은 푯대 바라보기’입니다. 팀원들이 같은 푯대를 바라보지 못하는 상황은 여러가지가 있을 수 있습니다. 먼저 푯대를 세우기만 하고 대화와 설득을 통해 공감하는 과정이 결여된 경우입니다. 어떤 한 사람이 푯대를 꽂고 저기로 달려가자고 외친기만 한다고 모두가 그리로 최선을 다해 달려갈 수 있는 것은 아닙니다. 팀원들이 그곳을 잠시 바라보게 할 수는 있지만 금새 시선을 다른 대로 빼앗길 수 있습니다. 계속해서 푯대만 꽂고 달리라고만 한다면 이탈자가 생길것이고 더러는 영혼 없이 타의에 의해 적당히 깃발로 달려가는 수동적인 팀원만 남게 될지 모릅니다. 다른 경우도 있습니다. 팀원들이 조금 긴 줄로 발을 묶고 달리는 상황을 상상해 볼까요? 그런데 팀원 각자 자신이 가고 싶은 푯대를 향해 달리면 어떻게 될까요? 각자 어딘가로 달려가는 듯 하지만 결국 서로에게 묶여 아무대도 가지 못하고 팀은 우왕좌왕 삐걱거리게 될 겁니다. 여기서 각자 꽂은 여러 깃발은 팀의 일이 이것저것으로 분산되어 지나치게 분주한 상황을 뜻할 수도 있고, 어떤 면에서는 팀원 각자가 공동의 목표 보다 개인의 이익에 집중하는 모습일 수도 있습니다. 정리하면 팀이 같은 푯대를 바라보기 위해서는 팀원들이 공감하는 푯대가 필요합니다. </p>
<h2 id="2-목표를-향해-나아가기">2. 목표를 향해 나아가기</h2>
<p>푯대(목표)를 꽂았고 모두가 공감했다면 이제 나아가야 합니다. 조직이 목표를 향해 나아간다는 건 ‘목표’를 이루는데 도움이 되는 ‘일’을 한다는 것입니다. 여기서 일을 한다는 것은 다시 두 가지로 나누어 생각해 볼 수 있습니다. 하나는 도움이 되는 일을 찾는 행위이고, 다른 하나는 찾은 일에 자원(시간, 사람 등)을 할당하여 일이 되게 하는 일입니다. 일을 찾아 계획만 세워서는 아무 일도 일어나지 않습니다. 반대로 전략 없이 아무 일에 자원을 할당하면 목표를 향해 나아갈 수 없습니다. 목표를 향해 나아가는데 필요한 일을 찾고 그 일에 자원을 할당하는 일, 우리는 이 두 가지를 함께 해야 합니다. 이 일에 구멍이 생기면 조직은 목표를 향해 나아가지 못하고 표류할 것이 분명합니다.</p>
<h2 id="3-중요한-일-먼저">3. 중요한 일 먼저</h2>
<p>목표를 향해 나아가는 길에는 수 많은 유형의 일들이 생깁니다. 신규 기능 개발, 운영 중인 시스템 버그, 도저히 보고 둘 수 없는 코드 리팩토링, 고객의 문서화 요청, 투자사 발표자료 준비 등등 온갖 일들이 하루에도 몇 가지씩 불쑥 불쑥 일어납니다. 우리는 이 중에 중요한 일을 선택해서 먼저할 수 있어야 합니다. 이유는 우리는 제한된 자원 아래에서 일하고 있기 때문입니다. 우리에게 주어진 시간도 사람도 분명히 제한적인데 우리에게 요구되는 일들은 종종 우리가 가진것이 무한한 듯 다가옵니다. 우리는 홍수 처럼 쏟아지는 일들 가운데 중요한 일을 선별해서 우리의 계획을 재 정렬할 수 있어야 합니다. 외부에서 우선순위 없이 요청한 일이 우리를 잠식하게 두어서는 안됩니다. 우리는 중요한 일을 식별하고 그것을 먼저하도록 전략적인 선택을 할 수 있어야 합니다.</p>
<h2 id="4-불확실한-것을-확실하게">4. 불확실한 것을 확실하게</h2>
<p>소프트웨어 프로젝트는 불확실한 덩어리로 시작했다가 점점 확실한 것을 만들어 가는 과정이라고 표현할 수 있을 것 같습니다. 프로젝트 초기에는 사용자가 진짜 필요로 하는 것이 무엇인지 희미합니다. 사용자 조차도 때때로 자신이 필요로 하는 것을 정확히 알지 못하는 단계라고 할 수 있습니다. 불확실한 것은 비단 사용자의 요구 뿐만은 아닙니다. 특정 구현을 위해 이런 설계를 가져가면 우리의 요구를 버텨낼 수 있을지, 특정 기술을 적용하면 최적의 구현을 이끌어 낼 수 있을지 불확실합니다. 우리는 이러한 불확실성을 점점 확실한 것으로 만들어가는 일을 해야합니다. 사용자가 뭘 원하는지 모르겠다면 질문해야 합니다. 질문하고 듣고 얻은 인사이트를 문서화해서 기록해 두어야 합니다. 기록해야 공유할 수 있고 우리 모두에게 확실한 것이 됩니다. 그리고 한 번으로 그치면 안됩니다. 듣고 얻은 인사이트를 프로토타입으로 만들어 사용자에게 보여주고 피드백을 받는 과정도 필요합니다. 피드백을 받아 고치고 피드백을 받아 고치는 과정이 반복되기도 합니다. 기술적인 것들도 크게 다르지 않습니다. 우리의 아이디어가 진짜 구현 가능한 것인지 작게 실험해 보고 결과를 볼 수 있습니다. PoC(Proof Of Concept)라는 프로세스를 반복해서 진행하다보면 우리의 아이디어, 설계, 기술이 우리의 요구를 만족할 수 있을지 점점 확신을 가질 수 있습니다. 우리는 이렇게 제품 개발 전 단계에서 불확실한 것을 조금씩 더 확실한 것으로 만들어 가는 매니지먼트를 해야합니다.</p>
<h2 id="5-윤활유">5. 윤활유</h2>
<p>제품을 개발하면 필연적으로 여러 역할의 사람이 함께 일을 하게 됩니다. 기획자, 디자이너, 서버 개발자, UI 개발자, 고객 등 다양한 이해 관계자들이 한데 뭉쳐 프로젝트가 굴러갑니다. 이때 각자의 역할을 맡은 사람들은 각자의 배경과 각자의 전문 분야가 있습니다. 각자 자기가 맡은 일에 베스트라고 하더라도 각자만 잘해서는 프로젝트가 부드럽게 굴러가지 않습니다. 각 부분을 담당하는 사람들 사이에는 메시지(요청과 응답)라고 하는 것을 끊임없이 주고 받으며 협력해야 하는데 아쉽지만 사람 사는 세상은 잘 설계된 프로그램 요소들 처럼 자연스럽게 메시지가 교환되지 않습니다. 더러는 자기 일에만 지나치게 몰두하기도 하고, 도움이 필요한데 혼자 끙끙대기도 합니다. 우리는 서로가 메시지를 주고 받으며 협력할 수 있는 자연스러운 장을 마련해야 합니다. 그리고 그 협력의 장 안에서 서로 다른 배경을 가진 사람들의 서로 다른 언어의 껍데기가 아니라 그 안에 담긴 핵심 내용이 잘 오가도록 조율하는 역할도 필요합니다. 마치 자동차 기어에 윤활유가 필요하듯 팀에도 이런 역할이 필요합니다. </p>
<h2 id="6-사용자-관점">6. 사용자 관점</h2>
<p>개발팀에는 우리가 불편해지면 고객이 편해진다는 말이 있습니다. 고객이 편한 서비스를 만들기 위해서는 사용자 관점에서의 많은 고민이 필요합니다. 그러나 많은 경우 자기의 관점을 내려놓고 사용자 관점에서 생각하는 것은 자연스러운 일이 아닙니다. 의지가 필요하고 노력이 필요합니다. 조직에는 이런 역할을 하는 사람이 필요합니다. 개발 조직 중심의 사고를 이어갈 때 사용자 중심의 생각으로 전환할 수 있는 파장을 일으킬 사람이 필요합니다. 때때로 갈등이 생길 지라도 그렇게 하는 사람이 필요합니다. 왜냐하면 사용자는 필요하지 않은 제품에 가치를 지불하지 않기 때문입니다. 조직은 가치를 만들어 내지 못하면 살아남을 수 없고 존재의 이유도 없어집니다. 피터드러커의 매니지먼트라는 책에서 ‘기업의 목적은 단 한 가지, 고객을 창조하는 것’이라고 했습니다. 우리는 우리의 제품이 가치있기 때문에 사용하는 고객을 창조해야 하며, 그것을 위해 사용자 관점으로 제품을 바라보는 매니지먼트가 무엇보다 더 필요합니다.</p>
<h2 id="7-사람의-따뜻함">7. 사람의 따뜻함</h2>
<p>사실 앞의 6가지가 모두 잘 되더라도 우리에게 함께 일하는 사람을 존중하고 배려하는 마음, 친절한 태도가 없다면 모두 무용지물이 될지도 모릅니다. 모든 것 보다 사람의 따뜻함이 프로젝트에 필요한 것이 확실합니다. 모든 매니지먼트 테크닉이 뛰어나더라도 사람을 함부로 대한다면 훌륭한 동료들과 오래도록 함께 하기는 힘들 것입니다. 어릴적 자주 들었던 이야기 하나가 생각납니다. 해와 구름이 누가 나그네의 외투를 벗게할 수 있을지 서로의 힘을 겨루던 이야기입니다. 사람의 따뜻함은 자연스럽게 동료 스스로 성장하도록 돕는 힘이 됩니다. 반대로 대화는 없이 깃발 꽂기에만 여념이 없거나 불친절하고 강압적인 자세로 사람을 대하기 시작하면 동료는 겉옷을 더욱 껴입게 될 뿐입니다. </p>
<h2 id="마치며">마치며</h2>
<p>아쉽지만 위에 기록한 것 모두가 저의 현재의 모습은 아닙니다. 돌아보면 제가 잘 했다고 생각되는 것도 있고 잘하지 못해 아쉬움이 남는 부분도 있습니다. 다만 이 모든 것들이 이제 새로운 곳에서 새로운 저의 푯대가 될 것입니다. 더 나은 모습의 동료가 되고 싶습니다.</p></div></div>

Joo's Work

JooSing

회사를 떠나며 그 동안 해왔던 일들을 글로 정리하고 동료들에게 가르쳐 주는 일을 2개월 가량 했습니다. 인수인계 과정을 진행해 나가며 동료들이 제 공백을 잘 매꾸어 줄 수 있겠단 생각이 들었습니다. 그런데 몇 일 전 문득 매니지먼트에 대한 일들이 생각났습니다. 이 일들은 인수인계가 가능한 건지, 동료들이 이런 공백들 역시 잘 매워 줄 수 있을지 스스로에게 질문하게 되었습니다. 그리고 이곳에서 매니지먼트와 관련해 제가 잘 했다고 생각하는 것들, 반대로 잘하지 못한 것들, 그렇지만 필요했고 내가 성장하고 싶은 목표가 되어준 것들에 대해 생각하게 되었습니다.
1. 같은 푯대 바라보기
주니어 시절에는 잘 몰랐습니다. 시니어 개발자로 한 걸음 한 걸음 나아가다 보니 팀에서 이것이 무척 중요함을 절실히 느낍니다. 바로 ‘같은 푯대 바라보기’입니다. 팀원들이 같은 푯대를 바라보지 못하는 상황은 여러가지가 있을 수 있습니다. 먼저 푯대를 세우기만 하고 대화와 설득을 통해 공감하는 과정이 결여된 경우입니다. 어떤 한 사람이 푯대를 꽂고 저기로 달려가자고 외친기만 한다고 모두가 그리로 최선을 다해 달려갈 수 있는 것은 아닙니다. 팀원들이 그곳을 잠시 바라보게 할 수는 있지만 금새 시선을 다른 대로 빼앗길 수 있습니다. 계속해서 푯대만 꽂고 달리라고만 한다면 이탈자가 생길것이고 더러는 영혼 없이 타의에 의해 적당히 깃발로 달려가는 수동적인 팀원만 남게 될지 모릅니다. 다른 경우도 있습니다. 팀원들이 조금 긴 줄로 발을 묶고 달리는 상황을 상상해 볼까요? 그런데 팀원 각자 자신이 가고 싶은 푯대를 향해 달리면 어떻게 될까요? 각자 어딘가로 달려가는 듯 하지만 결국 서로에게 묶여 아무대도 가지 못하고 팀은 우왕좌왕 삐걱거리게 될 겁니다. 여기서 각자 꽂은 여러 깃발은 팀의 일이 이것저것으로 분산되어 지나치게 분주한 상황을 뜻할 수도 있고, 어떤 면에서는 팀원 각자가 공동의 목표 보다 개인의 이익에 집중하는 모습일 수도 있습니다. 정리하면 팀이 같은 푯대를 바라보기 위해서는 팀원들이 공감하는 푯대가 필요합니다. 
2. 목표를 향해 나아가기
푯대(목표)를 꽂았고 모두가 공감했다면 이제 나아가야 합니다. 조직이 목표를 향해 나아간다는 건 ‘목표’를 이루는데 도움이 되는 ‘일’을 한다는 것입니다. 여기서 일을 한다는 것은 다시 두 가지로 나누어 생각해 볼 수 있습니다. 하나는 도움이 되는 일을 찾는 행위이고, 다른 하나는 찾은 일에 자원(시간, 사람 등)을 할당하여 일이 되게 하는 일입니다. 일을 찾아 계획만 세워서는 아무 일도 일어나지 않습니다. 반대로 전략 없이 아무 일에 자원을 할당하면 목표를 향해 나아갈 수 없습니다. 목표를 향해 나아가는데 필요한 일을 찾고 그 일에 자원을 할당하는 일, 우리는 이 두 가지를 함께 해야 합니다. 이 일에 구멍이 생기면 조직은 목표를 향해 나아가지 못하고 표류할 것이 분명합니다.
3. 중요한 일 먼저
목표를 향해 나아가는 길에는 수 많은 유형의 일들이 생깁니다. 신규 기능 개발, 운영 중인 시스템 버그, 도저히 보고 둘 수 없는 코드 리팩토링, 고객의 문서화 요청, 투자사 발표자료 준비 등등 온갖 일들이 하루에도 몇 가지씩 불쑥 불쑥 일어납니다. 우리는 이 중에 중요한 일을 선택해서 먼저할 수 있어야 합니다. 이유는 우리는 제한된 자원 아래에서 일하고 있기 때문입니다. 우리에게 주어진 시간도 사람도 분명히 제한적인데 우리에게 요구되는 일들은 종종 우리가 가진것이 무한한 듯 다가옵니다. 우리는 홍수 처럼 쏟아지는 일들 가운데 중요한 일을 선별해서 우리의 계획을 재 정렬할 수 있어야 합니다. 외부에서 우선순위 없이 요청한 일이 우리를 잠식하게 두어서는 안됩니다. 우리는 중요한 일을 식별하고 그것을 먼저하도록 전략적인 선택을 할 수 있어야 합니다.
4. 불확실한 것을 확실하게
소프트웨어 프로젝트는 불확실한 덩어리로 시작했다가 점점 확실한 것을 만들어 가는 과정이라고 표현할 수 있을 것 같습니다. 프로젝트 초기에는 사용자가 진짜 필요로 하는 것이 무엇인지 희미합니다. 사용자 조차도 때때로 자신이 필요로 하는 것을 정확히 알지 못하는 단계라고 할 수 있습니다. 불확실한 것은 비단 사용자의 요구 뿐만은 아닙니다. 특정 구현을 위해 이런 설계를 가져가면 우리의 요구를 버텨낼 수 있을지, 특정 기술을 적용하면 최적의 구현을 이끌어 낼 수 있을지 불확실합니다. 우리는 이러한 불확실성을 점점 확실한 것으로 만들어가는 일을 해야합니다. 사용자가 뭘 원하는지 모르겠다면 질문해야 합니다. 질문하고 듣고 얻은 인사이트를 문서화해서 기록해 두어야 합니다. 기록해야 공유할 수 있고 우리 모두에게 확실한 것이 됩니다. 그리고 한 번으로 그치면 안됩니다. 듣고 얻은 인사이트를 프로토타입으로 만들어 사용자에게 보여주고 피드백을 받는 과정도 필요합니다. 피드백을 받아 고치고 피드백을 받아 고치는 과정이 반복되기도 합니다. 기술적인 것들도 크게 다르지 않습니다. 우리의 아이디어가 진짜 구현 가능한 것인지 작게 실험해 보고 결과를 볼 수 있습니다. PoC(Proof Of Concept)라는 프로세스를 반복해서 진행하다보면 우리의 아이디어, 설계, 기술이 우리의 요구를 만족할 수 있을지 점점 확신을 가질 수 있습니다. 우리는 이렇게 제품 개발 전 단계에서 불확실한 것을 조금씩 더 확실한 것으로 만들어 가는 매니지먼트를 해야합니다.
5. 윤활유
제품을 개발하면 필연적으로 여러 역할의 사람이 함께 일을 하게 됩니다. 기획자, 디자이너, 서버 개발자, UI 개발자, 고객 등 다양한 이해 관계자들이 한데 뭉쳐 프로젝트가 굴러갑니다. 이때 각자의 역할을 맡은 사람들은 각자의 배경과 각자의 전문 분야가 있습니다. 각자 자기가 맡은 일에 베스트라고 하더라도 각자만 잘해서는 프로젝트가 부드럽게 굴러가지 않습니다. 각 부분을 담당하는 사람들 사이에는 메시지(요청과 응답)라고 하는 것을 끊임없이 주고 받으며 협력해야 하는데 아쉽지만 사람 사는 세상은 잘 설계된 프로그램 요소들 처럼 자연스럽게 메시지가 교환되지 않습니다. 더러는 자기 일에만 지나치게 몰두하기도 하고, 도움이 필요한데 혼자 끙끙대기도 합니다. 우리는 서로가 메시지를 주고 받으며 협력할 수 있는 자연스러운 장을 마련해야 합니다. 그리고 그 협력의 장 안에서 서로 다른 배경을 가진 사람들의 서로 다른 언어의 껍데기가 아니라 그 안에 담긴 핵심 내용이 잘 오가도록 조율하는 역할도 필요합니다. 마치 자동차 기어에 윤활유가 필요하듯 팀에도 이런 역할이 필요합니다. 
6. 사용자 관점
개발팀에는 우리가 불편해지면 고객이 편해진다는 말이 있습니다. 고객이 편한 서비스를 만들기 위해서는 사용자 관점에서의 많은 고민이 필요합니다. 그러나 많은 경우 자기의 관점을 내려놓고 사용자 관점에서 생각하는 것은 자연스러운 일이 아닙니다. 의지가 필요하고 노력이 필요합니다. 조직에는 이런 역할을 하는 사람이 필요합니다. 개발 조직 중심의 사고를 이어갈 때 사용자 중심의 생각으로 전환할 수 있는 파장을 일으킬 사람이 필요합니다. 때때로 갈등이 생길 지라도 그렇게 하는 사람이 필요합니다. 왜냐하면 사용자는 필요하지 않은 제품에 가치를 지불하지 않기 때문입니다. 조직은 가치를 만들어 내지 못하면 살아남을 수 없고 존재의 이유도 없어집니다. 피터드러커의 매니지먼트라는 책에서 ‘기업의 목적은 단 한 가지, 고객을 창조하는 것’이라고 했습니다. 우리는 우리의 제품이 가치있기 때문에 사용하는 고객을 창조해야 하며, 그것을 위해 사용자 관점으로 제품을 바라보는 매니지먼트가 무엇보다 더 필요합니다.
7. 사람의 따뜻함
사실 앞의 6가지가 모두 잘 되더라도 우리에게 함께 일하는 사람을 존중하고 배려하는 마음, 친절한 태도가 없다면 모두 무용지물이 될지도 모릅니다. 모든 것 보다 사람의 따뜻함이 프로젝트에 필요한 것이 확실합니다. 모든 매니지먼트 테크닉이 뛰어나더라도 사람을 함부로 대한다면 훌륭한 동료들과 오래도록 함께 하기는 힘들 것입니다. 어릴적 자주 들었던 이야기 하나가 생각납니다. 해와 구름이 누가 나그네의 외투를 벗게할 수 있을지 서로의 힘을 겨루던 이야기입니다. 사람의 따뜻함은 자연스럽게 동료 스스로 성장하도록 돕는 힘이 됩니다. 반대로 대화는 없이 깃발 꽂기에만 여념이 없거나 불친절하고 강압적인 자세로 사람을 대하기 시작하면 동료는 겉옷을 더욱 껴입게 될 뿐입니다. 
마치며
아쉽지만 위에 기록한 것 모두가 저의 현재의 모습은 아닙니다. 돌아보면 제가 잘 했다고 생각되는 것도 있고 잘하지 못해 아쉬움이 남는 부분도 있습니다. 다만 이 모든 것들이 이제 새로운 곳에서 새로운 저의 푯대가 될 것입니다. 더 나은 모습의 동료가 되고 싶습니다.

회사를 떠나며, 매니지먼트에 대한 회고

댓글