Continue reading ‘협업의 속도를 위한 경계’ »]]>

상반기의 업무 방식이 과감하게 도전하기(Be Bold)라면, 하반기의 일하는 방식은 “함께 리듬감있게 일하기“로 이야기하고 있다. 상반기엔 구성원 모두가 정말 과감하게 도전했고 기대 이상의 성과들을 만들었다. 말이 쉽지 개개인의 희생과 노력없이 도전은 이뤄질 수 없다. 그만큼 피로가 쌓일 수 밖에 없기에, 이 방식은 지속 가능한 업무 형태로 적합하지 않다. 이에 대한 고민을 아래와 같은 방식으로 정리해봤다.

1. 리듬감있게 일하기
2. 한번에 되는 일은 없다!
3. 되풀이하지 않기
4. 현실은 멀티플(Multiple)

리듬감있게 일하기

지속 가능성을 염두에 뒀을 때, 상반기 과감한 흐름이 조직의 DNA로 이어질 수 있는 방안을 생각했다. 고민을 바탕으로 하반기 일하는 핵심 키워드로 “함께”와 “리듬감”을 뽑았다.

“함께”라는 단어는 알겠지만, “리듬감”은 뭘 말하는지 모르겠다는 질문이 많았다. 보통 리듬은 일정하게 반복되는 주기성 혹은 패턴을 의미한다. 우리는 스프린트 방식(2~3주 단위의 반복적 개발 방식)으로 일한다. 팀의 역량(Capacity)에 따라 일정 양(Volume)의 일을 반복한다. 자연스럽게 리듬있게 일하고 있는거 아닌가? 하지만 음악에도 변주가 있듯이 스프린트 그 기간 안에서 벌어지는 일의 양과 성격이 매번 다를 수 밖에 없다.

그럼에도 리듬감있게 일하기 위해 가장 필요한 것은 실행의 단위를 갖는 것이다. 이미 스프린트가 있기 때문에 이 스프린트가 명시적으로 유지되어야 한다. 2주 혹은 3주 단위의 스프린트 단위로 함께하는 동료 혹은 팀들이 의식적으로 일을 진행해야 한다. “새로운 요구 사항이 계속 나오고, 2~3일마다 배포하고 있는데 스프린트가 무슨 의미가 있냐?” 라는 질문 할 수 있다. 이런식으로 라이브 배포를 하고 있으면 스프린트의 의미가 없다….

이런 이야기까지 나오는 건 계획(Planning)할 수 없기 때문이다. 예측할 수 있다면, 적어도 스프린트에 할 일을 구체화하고 실행할 수 있지 않을까? 물론 예측 못한 일들이 마구 나온다는건 분명 잘못된 시그널이다. 방향과 지도 없이 헤메고 있을 가능성이 높다. 바로 잡으려면 방향을 잡고, 우리가 알고 있는 지식과 경험으로 지도를 그려야 한다. 높은 산꼭대기가 아니더라도 언덕 위에 올라가면 하루, 이틀의 길을 예측할 수 있다. 거기부터 시작해야 한다. 예측을 시작해야 무엇에 집중할지 결정할 수 있게 된다. 그럼 스프린트에 진짜로 뭘 만들어야할지 제대로 알게 된다. 2~3일마다 배포해서 얻는 결과보다 더 큰 가치를 타켓팅할 수 있게 된다.

2023년의 시장 환경은 한 분기 단위의 예측성 조차 보장하기 힘들만큼 급변했던 것 같다. 상반기를 어렵게 넘겼지만, 하반기 역시 녹록하지 않다. 그럼에도 “리듬감있게 일하자!”라는 배경에는 리더로서 최소한 2개 혹은 그 이상 스프린트의 예측성을 각 개발팀에 보장해주기 위함이다. 당장 시작할 다음 스프린트를 예측할 수 있다면, 개발을 담당하는 각자는 플래닝을 통해 코딩에 집중할 시간을 가질 수 있지 않을까 싶다. 물론 이 정도 스프린트의 시간으로 일이 완성되지 않는다. 과정은 반복되고, 서비스는 답이 정해진 게임이 아니다.

한번에 되는 일은 없다!

완결된 목표는 한번 “으쌰!”한다고 완성되지 않는다. “무엇을 만들자!“가 선언되고, 제품/기능/서비스로 실체화 되는데 시간이 걸린다. 특히 명제가 갖는 가치와 무게가 높고 무거울수록 더 많은 시간이 필요하다. 완성되기 전까지 우리는 “무엇”의 완벽한 실체를 알 수 없다. 그래서 우리는 점진적인 완성을 향해가는 개발 방법론을 사용한다.

시간에 따른 점진적인 완성이 동작하기 위해서는 소통이 있어야 한다. 우리가 파악한 정보는 무엇이며, 이를 바탕으로 검증할 대상을 정해야 한다. 정해진 대상을 스프린트를 통해 구체화시키고 데모를 통해 확인한다. 결과물은 나아갈 방향을 검증하고, 새롭게 정보가 추가된다. 그리고 다음 스프린트에서 최종 목표를 위해 뾰족하게 할 내용을 정의한다. 이 반복을 통해 우리는 목표(Goal)를 향해 차근차근 다가간다. 그리고 충분히 고객과(End User)과 관련자(Stakeholder)를 만족시킬 수 있다는 판단이 들 때 우리는 출시(Release)를 통해 “무엇“의 가치가 실체화되는지 확인한다.

적절한 수준의 정보가 있어야 스프린트를 제대로 진행할 수 있다. 음식은 너무 날 것이라도 문제를 일으키지만 너무 삭아도 안된다. 스프린트를 위한 정보 역시 마찬가지다. 참여자가 충분히 해석하고 공감할 수준이면 충분하다. 구현 단계의 생산자(Maker)들이 해석하고 분해해서 우리가 이 기간에 검증할 내용이 무엇인지 정의한다. 해석과 분해를 위해 추가적인 정보가 필요할 수 있다. 충분하지 않다면 충분하지 않다는 것 자체를 받아들이자! 상황을 받아들이고 그 상황에 맞추어 어떤 시도를 해볼지 결정하는게 좋다. 그리고 결과를 만드는 일에 스프린트 기간 동안 집중해보자. 아니 해야한다. 그리고 해석된 결과가 데모를 통해 공유하고 우리가 충분히 고객과 관련자들에게 다가가고 있는지 확인하자.

되풀이하지 않기

되풀이하지 않기 위해 각 단계에 따른 완전성(Completeness)을 추구해야 할 때도 있다. 만들 S/W 제품을 목표(Goal)로 보고 진행되는 “제품 기획 – 디자인/설계 – 개발/QA”를 단계에 따른 서비스 개발 파이프라인이라고 정의하자.

기획 단계에서 완벽한 사업 내용을 문서로 작성한다. 이 가치를 얻는데 필요한 기능들을 A~Z까지 깨알같이 정의된 산출물이 만들어진다. 디자인 단계는 화면에 어떤 요소들이 위치하는지 픽셀 단위의 오차도 허용하지 않는 피그마로 작성된다. 물론 개발을 위한 방대한 Component – Class – Sequence Diagram(State Diagram)이 깔끔하게 준비되는 경우도 있다. 방대한 정보가 역시 산출물로 만들어진다. 마지막으로 개발/QA가 코드로 Goal을 완성시킨다. 멋지다!

이점에서 제품 완성을 위해 주어진 시간은 단계로 구분된다. 각 단계의 결과물이 예상 시간 범위에 완료되면 이상적일 것이다. 하지만 세상은 완벽하지 않고, 사람의 마음은 갈대와 같다. 고객의 마음 역시 그자리에 그대로 있으라는 보장이 없다. 여기에 소위 배포일이 찍혀있는 Time-to-market 상황이라면? 어느 한 단계의 고민이 길어지면 부담은 고스란히 다음 단계로 전이된다. 개발을 위한 정보 전달이 늦어지면 늦어질수록 결국 짧은 시간에 개발과 QA를 마쳐야 한다. 줄어든 시간은 담당자들에게 심리적인 압박으로 작용하여 스트레스로 사람들을 지치게 만든다.

파이프라인에 정보가 흘러야 한다. 일을 시작할려면 필요한 정보가 있어야 한다. 앞선 이야기처럼 현재 단계를 위한 모든 정보가 있으면 좋다. 25년 개발 경험을 되돌아봤을 때 일 시작 전 모든 정보가 준비된 경우는 없었다. 심지어 SI를 했던 때도. 또한 주어진 정보라도 근거가 잘못됐거나 해석의 오류가 발생하는 경우도 빈번했다. 그래서 “못한다, 님(남)탓이다.“라고 이야기해야 할까? 만약 이런 이야기를 하고 있다면 단계라는 벽에 스스로 갇힌 것과 다름없다. 시간이 가장 귀중한 자원이다.

흐르게 할려면 막힌 부분을 열어야 한다. 정보 역시 마찬가지다.  정보가 흘러가면 모든 단계의 주체들이 뭘 할 수 있을지 고민할 수 있다. 고민하면 준비할 수 있고, 준비되면 추가된 정보를 통해 목표에 다가가는 시간을 아낄 수 있다. 때문에 각 단계의 벽을 여는 것이 가장 중요하다. 단계를 소유하는 조직들이 벽을 스스로 허물어야 한다. 파이프라인에 참여하는 모든 조직들이 단계의 벽을 낮추고 한 팀처럼 동작해야 정보가 흐르고 점진적으로 목표를 향해 나아갈 수 있다.

벽을 낮추고 여는 핵심 역할을 단계의 리드들이 해줘야 한다. 물론 파이프라인을 책임지는 리더 역시 이 부분을 독려해야 한다. 모두가 확고한 의지를 가질 수 없기 때문에 리더십과 문화가 이를 뒷받침해야 한다. 한 두사람의 의지만으로 파이프라인에 물을 흐르게 만들 수 없다.

물론 정보가 완전하지 않기 때문에 엉뚱한 일을 할 수 있다. 누구는 이를 비효율이고 낭비라고 이야기한다. 틀린 말이 아니다. 그렇기 때문에 낭비적인 요소를 최소화하기 위해 빠른 방향 전환을 할 수 있어야 한다. 추가 정보로 틀렸음을 알게되면 빠르게 인정하고 방향을 수정해서 움직여야 한다.

이때 파이프라인의 어느 구간이 닫히는 경우가 있다. 비난이 원인이다. “잘못된 판단”을 하지 않으면 좋겠지만 완전하지 않은 정보를 바탕으로 판단할 수 밖에 없으니결과가 목표와 다른 일은 언제든 발생한다. 이를 용납 못하고 비난이 난무하는데 이를 리더십에서 제어하지 못한다면? 그럼 이 방법은 조직에 맞지 않다. 조직에 맞는 다른 방법을 찾는게 옳다.

현실은 멀티플(Multiple)

담당자가 참여하는 파이프라인이 하나라면 다행이다. 하지만 대부분 팀들이 할 일들이 참 많다. 회사의 꿈이 완성형이 아닌 진행형 상태라면 개인이 혹은 팀이 참여하는 서비스 파이프라인이 하나일 수 없다. 현실은 멀티플이다.

멀티플이라는 그림을 놓고보면 숨이 턱 막힌다. 한번에 두개 세개의 작업을 현실에서 어떻게 하지??? 불가능하다. 사람 머리가 두개가 아닌 이상 특정 순간에 하고 있는 일은 하나다.

컴공 전공이라면 비슷한 그림 한번쯤 보지 안았을까 싶다. 운영 체제(Operating system)를 공부했다면 바로 생각날 것이다. 여기에서 여러 작업을 처리하는 방법, 특히 CPU(Core)가 하나인 경우에 타임 쉐어링이라는 방식이 있다. 사실 여러 작업이 동시 처리되게 보이도록 만든것이지 실제 처리는 1개만 하는 것이다. 단, 계산(Computation)이 지속되도록 CPU에 작업을 지속적으로 부여한다. 만약 계산을 위해 데이터가 필요한 순간이면 그 작업을 잠시 보관하고, 계산할 다른 작업을 올려 진행한다. 물론 작업 전환이 공짜로 이뤄지는 건 아니다. 이전 작업을 이어 수행하기 위한 정보를 안전하게 보관시키고, 다음 작업 실행 상태 정보를 CPU가 바로 수행해야 한다. 운영 체제가 수행하는 이와 같은 일련의 작업 전환을 “컨텍스트 스위치(Context Switch)“라고 부른다. 이 작업 역시 CPU에 의해 실행되기 때문에 공짜가 아닌것이다. 그리고 작업 전환이 많을수록 정작 CPU는 해야할 일보다는 이 전환만 열심히 하고 있을 수 있다.

현실의 멀티플 역시 같은 맥락이다. 당면해서 처리할 충분한 정보가 있다면 그 일에 집중한다. 진행을 위해 정보가 더 필요하거나 선작업이 끝나는 것을 기다려야하는 상황이라면 다른 작업의 일부를 진행하면 된다. 물론 여기도 작업 전환 비용이 발생한다. 전에 내가 어디까지 했는지 기억도 추스려야하고, 문서나 코드도 다시 훑어야한다. 상황 자체가 이전과 판이하게 달라졌다면 당시자들을 만나 충분한 상황 공유를 받아야한다. 이전 작업이 너무 빡셌다면 다음 작업을 위해서 쉬는 것 역시 번아웃을 막기위해 필요하다.

지금까지의 논리로 보면 우리가 일하는 방식은 컴퓨터와 비슷해야 효과적일 수 있다는 것이 역설적이다. 다만 인간은 수만대의 기계를 합친 것에 비교할 수 없다. 똑똑함을 넘어선 인간의 지혜와 통찰이라는 요소가 이 차이를 만든다. 그리고 이 요소들이 십분 발휘될 수 있는 지점이 계획 수립, 즉 플래닝이라고 생각한다.

플래닝을 통해 확정된 것과 미확정 요소를 공유하고, 스프린트에 확인할 대상을 찾아야 한다. 여러 제품 혹은 서비스를 함께 챙겨야한다면 상관관계와 선후를 파악해야 한다. 이 부분이 종합되면 스프린트에 수행할 태스크의 우선 순위를 매길 수 있다. 물론 미확정 요소를 확정 단계로 만들어야하고, 이렇게 파악된 컨텍스트를 참여자 모두가 확인할 수 있도록 열린 커뮤니케이션이 공유의 형태로 유지되어야 한다. 강조해서 주의/당부하고 싶은 건 정보가 무기화되는 것이다. 누군가가 정보를 자신을 위해 사용한다고 참여자들이 모두 느낀다면 안하니만 못한 일이 되버린다.

-끝-

PS.

국방, 안전, 항공, 우주 관련 프로젝트의 경우는 절차적 단계에 따른 제품 개발이 꼭 필요하다고 생각한다. 부실한 정보를 토대로 원전 운영 소프트웨어를 작성했다는 사실을 알게 되면… 끔찍하다. 해본 적은 없지만, 이런 고난이도 개발을 해볼 기회가 있었으면 하는 생각도 든다.

Continue reading ‘사무실에서 나의 시간을 확보하는 첫걸음’ »]]> 쏘카는 4월 1일부터 좀 더 빠른 협업을 위해 재택에서 사무실로 일하는 공간을 변경했다. 공간의 변화로 실제 일하는 방식까지 영향을 미칠려면 “시간(Time)”이라는 요소가 영향을 받아야 한다. 공간의 변화가 그럼 어떻게 시간이라는 요소에 영향을 미칠까? 영향을 줄 수 있는 가장 큰 요소는 “회의(Meeting)”이다.

재택 환경에서 논의할 꺼리가 있다면 꼭 미팅을 잡아야 한다. 그 사람이 그 시간에 실제 만날 수 있는지 알 수 없기 때문에 캘린더를 살펴야했고, 빈시간을 찾아서 그 사람(들)의 시간을 점유해야 했다. 점유한다는 것은 결국 그 논의할 그 시간까지 기다린다는 것을 의미한다. 결정할 시간이 그만큼 늦춰지는 것이고, 일하는 속도를 늦추는 요인이다.

이번 업무 공간의 변화를 꾀하고, 2주의 시간이 흐른 이후에 아래와 같이 주요한 미팅 진행 방식의 변화를 전체 팀에 요청했다. 조직 전반으로 소통의 시간을 빠르게 가져갔으면 하는 바램도 크지만 더 큰건 개인 스스로의 “나의 시간“을 확보하길 기대했기 때문이다. 시간은 뭘로도 살 수 없다.

1. 데일리스크럼 15분컷! – 매일 진행하는 스크럼은 이슈 사항을 빠르게 공유하는 자리가 되야 한다. 이전 재택 시절에는 고립감을 이겨내기 위해서라도 많은 이야기가 필요한 시절이었다. 일하는 공간의 변화된 현재는 짧은 소통 위주로 필요한 정보를 빠르게 소통(공유)하는게 맞다. 의도적으로 15분내에 스크럼이 완료될 수 있도록 해야 한다. 말 그대로 의도적으로. 그리고 이 부분이 실체화될려면 스크럼을 이끄는 사람이 신경써야 한다. 그 사람이 스크럼마스터든 팀 리더든. 그리고 추가로 논의할 사항들은 그 사람들끼리만 이야기하면 된다. 부디 제발 데일리스크럼을 “아침 조회“로 만들지 말았으면 한다.
2. 스크럼 서서하기 – 15분컷(짧은 스크럼)을 달성하기 위한 방안의 하나로 스크럼은 일어서서 진행해야 한다. 실제로 라이엇 미국 본사에서 20명이상이 참여하는 스크럼할 때 한때 아주 짧은 기간 동안 바닥에 팔꿈치를 대고 이야기하는 방식으로 진행했었다. 옆에 보기에도 매우 불편한 자세였지만, 1시간 걸리던 스크럼이 딱 20분안에 마무리됐다. 물론 일주일만에 서서하는 것으로 원복됐지만 이후에도 스크럼 시간이 30분 내외로 마무리되는 효과를 냈다. 체크인, 한일, 할일, 이슈를 공유하자.
3. 불필요한 회의없애기 – 재택과 사무실 근무의 차이는 우리가 함께 같은 공간에 있다는 것이다. 미팅 요청이 들어오거나 만들거나 하면 “제가 자리로 찾아가서 상의드릴께요.” 라는 말을 먼저 꺼내보자. 혹은 지나가는 길에 잠깐 그 사람의 책상에 들려보자. 주변 사람들에게 방해되지 않는다면 이야기하고 마무리하자. 혹은 팀 사람들이 주변에 함께 앉아있기 때문에 들을 사람들은 알아서 들을 것이다. 약간의 소음이 발생한다는 것을 주변 동료들이 이해해주고, 말하는 사람이 알고만 있으면 훨씬 빠르게 시간을 절약할 수 있다. 이런 일 하나가 “현재의 나“가 해결해서 “미래의 나“를 위한 시간을 만들어줄 좋은 기회입니다.
4. 불필요한 회의 참석 안하기 – 관성적으로 참여 요청받는 회의들이 정말 매우 많다. 참여자를 살펴보고, 굳이 필요없다면 참석 여부에 “No” 버튼을 누르자. (쉽지 않은 일인거 알지만 해보자. 생각보다 훨씬 본인에게 도움이 될 수 있다.) 일 진행에 컨텍스트를 공유받는건 매우 중요합니다. 하지만 컨텍스트를 전달받는 것만으로 충분하다면 전달받으면 된다. 이 경우에 중요한 건 회의록입니다. 요즘 친구들 정말 회의록을 열심히 작성하고 있고, 클로바같은 좋은 회의록을 정리할 수 있는 도구들도 있다. 물론 결정이 필요하지만, 나의 소중한 시간을 절약할 수 있는 결정을 하자. 미팅에 참여하는 것이 시간 절약에 도움되는 경우도 있으니 꼭 한번은 생각해보는 것이 좋다.

생각보다 쉬울 수도 혹은 어려울 수도 있다. 하지만 앞서 이야기한 것처럼 가장 중요한 것은 시간이다.

환경이 변한다면 그 환경에서 무엇이 가장 좋을지 선택하는 것도 성장 과정에서 꼭 거쳐야 하는 단계이다.

– 끝 –

Continue reading ‘보수적인 신입 개발자’ »]]>

딱 오해살만한 문구다. 새로 커리어를 시작하는 신입들이 보수적이라고? 제목이 “도전적인 신입 개발자“가 되어야 하는게 아닌가? 신입(Junior)은 패기가 넘친다. 모든게 새롭다. 그리고 일을 완성시키고 싶다. 그렇기 때문에 신입의 업무 스타일은 보수적이다.

일을 완성하고 싶다.

신입이라 함은 이제 막 직업으로써 개발일을 시작한 사람이다. 이제부터 경력을 하나씩 쌓아나가야 한다. 시작하는 첫걸음부터 꼬이고 싶지 않다. 못한다는 이야기를 적어도 나는 혹은 내 일에서는 듣고 싶지 않다. 풀어보면 가장 실패하고 싶지 않은 사람이 바로 막 사회 생활을 시작한 주니어이지 않을까?

실패하지 않기 위해 가장 필요한 건 시간이다. 신입에게 경험이란 없다. 그렇기 때문에 불확실성을 예비할 시간을 생각한다. 이 부분은 신입들과 스프린트 플래닝(Sprint Planning)을 해보면 가장 극명하게 알 수 있다. 회사 온보딩 과정 혹은 학교나 부트 캠프를 통해 해봤을 법한 내용이라도 업무에서는 1.5배 정도의 시간을 플래닝 포커(Planning Poker)에서 예상한다. 물론 포커에서 의견 불일치도 나온다. 짧은 시간을 예측한 친구가 있더라도 포커를 반복하다보면 가장 긴 시간으로 수렴하는 경우가 다반사다.

경험있는 시니어의 리딩이 없다면 정말 귀신같이 포커에서 예상한 시간만큼 걸리는 것 같다. 물론 시간이 걸린 이유를 짚어보면, 사소한 기술 문제나 서비스 환경의 이해 부족이 한 역할을 한다. 때문에 간극을 매워줄 수 있는 리딩이 가능한 시니어(혹은 리더)가 중요하다.

그럼 신입의 이런 플래닝은 어떻게 해야할까? 주니어들을 모를 수 밖에 없다며 이정도 시간이면 된다고 알려줘야 할까? 개인적인 의견이지만, 최선은 신입의 플래닝을 존중해주는 것이다. 할 일에 대한 본인 추정이 그렇다고 하면 존중하자. 그리고 스프린트를 통해 본인의 작업 시간을 실제 측정해보도록 해야 한다. 측정되지 않은 추정은 의미가 없다. 특히나 이 측정은 주니어에게 매우 큰 의미가 있다. 측정을 통해 본인의 추정이 얼마나 정확했는지를 알게 되기 때문이다. 신경을 좀 더 쓴다면 어느 지점/문제에서 가장 많은 시간을 쓰고 있는지를 파악할 수도 있다. 이 과정은 1회성이 아니라 일정 기간(여러 스프린트 이상) 반복적으로 진행되어야 한다. 그래야 추정과 측정의 반복을 통해 시간 예측의 정확도를 올려야 한다.

시니어라도 주니어(특히 신입)의 플래닝에 시니어가 지나치게 개입하면 안된다. 간혹 가르칠려고 하는 경우도 있다. 적절한 시니어의 가이드는 추정의 정확성을 높이는 좋은 피드백이 되지만 되려 간섭으로 동작하는 경우도 다반사다. 주니어가 이를 내재화하기 위해서는 스스로 알아가는 과정이 최선이다. 험한 현실로부터 적절한(최대가 아닌) 안전판 역할이 시니어가 해야할 몫이다.

스프린트 회고를 통해 팀이 발전하는 것과 마찬가지로 주니어도 스스로를 알아감을 통해 나의 역량이 얼마인지, 그리고 이를 통해 어느 정도 팀에 공헌을 할 수 있을지 스스로 파악하는 시간을 가져야 한다. 앞서 이야기한 추정과 측정의 차이가 얼마나 발생했는지, 발생의 원인은 무엇인지, 통제 혹은 수정 가능한지, 통제할 수 없는 영역이라면 이 부분을 대비하기 위해 어떤 부분들을 더 챙기면 좋을지 고민해야 한다.

본인의 노력으로 개선할 수 있는 부분이 도출되면 이를 목록화해보길 권한다. 모든 것들을 한번에 개선할 수 없다. 중요한 건 그 가운데 하나를 실행하는 것이다. 개선 방향으로 실행해보고, 어느 정도의 개선 결과를 만들어내는지 살펴보자. 가장 중요한 건 실행하는 것이고 결과를 확인하는 것이다. 그래야 이 과정에서 발전하는 “나”를 볼 수 있고, 그것이 노력에 대한 스스로의 보상이다.

하지만 추정과 측정 차이의 큰 문제는 통제 불가능한 “외부”에서 온다. 예상과 다른 계획되지 않은 많은 일들이 중간에 치고 들어온다던지, 너무 많은 기대를 받아서 기대에 부응하기 위해 항상 야근과 주말 근무를 염두에 두고 플래닝을 한다든지… 이런 문제는 현실적으로 주니어 스스로 해결할 수 없다. 끙끙 속앓이를 할 것이 아니라 문제를 수면 위로 올려야 한다. 시니어와 의논하거나 혹은 TL 혹은 팀장과 이 내용을 가지고 이야기를 해야 한다. 이야기를 해도 속시원한 해결책이 없는 경우가 많다. 하지만 나를 제외한 다른 동료들에게도 이 부분을 공유하고 알게하는 것이 중요하다. 예를 들어 프로젝트의 일감이 많다는 부분이 인식됐다면 팀이 추구하는 목표를 MVP 방식으로 전환할 수도 있다. 혹은 아예 출시 일정을 연기해서 팀이 일에 쫓기는 것이 아니라 온전히 일을 소유할 수 있는 방식을 추구할 수도 있을 것이다.

이렇게 할 수 있냐는 질문을 던질지 모른다. 모르겠다. 그럼에도 팀에 문제를 공유하는 것이 먼저다. 그리고 이 과정을 시니어와 리더들이 도와야한다. 충분한 대화가 있어야 한다. 주니어는 대화를 요청하고, 시니어는 들어야 한다. 그래야 제대로 된 안전판 역할을 할 수 있다.

“못해요”를 못한다.

주니어 입장에서 주어진 모든 과제들이 새롭다. 부트 캠프나 인턴 과정을 거치면서 “실전 경험”을 쌓았다고 하지만, 결국 이건 연습이다. 하지만 회사 일은 하나 하나가 이력서라는 실전 기록으로 남겨진다. 더구나 주어진 업무 역시 누구나 하는 그런 개발이 아니라 현실 서비스다. 회사가 고객에게 제공하려는 서비스는 다른 회사의 서비스와 다르다. 알고리즘이 다르고, 방식이 다르고, 기술이 다르다. 겪어보지 않은 새로운 세상이다. 주니어 입장에서는 하나 하나가 재미있고 도전적이다. 재미도 있고, 처음 시작하는 인생 이력서에 기록될 첫 한줄이 될 것이기 때문에 열심히 노력한다.

앞서 이야기한 스프린트 플래닝을 통해 여러 해야할 본인의 “일들”을 정하거나 할당받는다. 하지만 쉽게 해결되지 않는다. 내가 해야할(혹은 하겠다고 한) 일이기 때문에 고집이 생긴다. 분명 좋은 방안이 있을텐데… 데일리 스크럼(Daily Scrum)에서는 지라 보드를 열어놓고 열심히 하고 있다고 이야기한다.

동료가 해당 작업의 진척 상황을 질문한다. 그 작업은 지금 골머리썩고 있는 이슈만 해결하면 금방이다. 곧 해결된 것 같다고 이야기한다. 스프린트 데모에 맞출 수 있을까? 야근에 특근이다. 이젠 자존심 문제다.

가상의 이야기일 것 같지만 현실에서 자주 발생한다. 시니어와 구별되는 주니어라는 단어가 존재하는 이유이기도 하다. 경험해보지 못했기 때문에 “문제 해결 방법”을 모르는 건 당연하다. 더구나 “해결”에 대한 경험도 이제 막 시작이다. 그렇기 때문에 “내가 못했다.“라는 이야기는 하기 싫고 듣기는 더욱 싫다. 이건 자존심 상하는 이야기다. 사람을 사람답게 만드는 감정 가운데 하나가 “자존심” 아닐까?

팀 작업에서 항상 시간이 최우선이다. 주어진 시간안에 의미있는 결과가 만들어지도록 하는 것이 리드의 역할이다. 물론 그 시간안에 팀 구성원 모두 최선을 다해 기여해야 결과물이 만들어진다. 여기에서 팀의 최상과 개인의 최상은 서로 다를 수 있음을 팀 구성원들이 알아야 한다. 우리가 팀으로 일할 때는 팀의 목표가 먼저여야 한다. 하지만 팀의 목표가 우선이기 때문에 개인이 소외(무시)되는게 당연하다는 논리는 위험하다. 이런 논리는 자칫 성과지상주의를 유도하고, 팀을 와해시킨다.

무엇보다도 중요한 건 팀원 개개인이 열린 자세를 갖는 것이다. 리드는 지속적으로 팀의 목표를 공유하고, 이를 구성원들이 열린 자세로 받아들이도록 해야 한다. 그리고 내가 해결할 문제가 아닌 팀의 문제로써 이슈를 공유하고, 건설적인(Positive, not Negative) 피드백이 만들어질 수 있어야 한다. “내(구성원)가 주도적으로 해결한다.“라는 자존감이 형성되야 한다. 이것이 가능하도록 건강한 팀 분위기(Team Health)를 조성하고 만들어내는 것이 리드의 역할이다.

다시 주니어 문제로 돌아가보자. 주니어는 자존심을 걸고 자신의 문제 해결 능력을 보여주고 싶다. 리드는 주니어 구성원이 자존심이 아닌 자존감을 발현할 수 있도록 해야 한다. 주니어가 자신이 부닥친 문제를 본인의 해결 노력과 함께 공유할 수 있어야 한다. 다시 강조하지만 문제가 있다는 사실을 스스로 공유(이야기)하는 것이 가장 중요하다. 그리고 리더를 포함한 동료들의 피드백과 시간이라는 제약 조건을 놓고, 팀 목표를 위한 다음 스텝을 본인이 결정한다. 개인에게 최상의 결정이 아닐 수 있다. 그럼에도 스스로의 의사 결정을 통해 팀 목표에 기여할 수 있으며, 결과물은 스스로에게 해냈다라는 만족감을 준다.

이것을 구현하는 것이 리더의 역할이다. 과정이 이뤄지기 위해서는 먼저 팀원 사이의 신뢰 구축이 먼저다. 주니어 구성원이 적어도 리더를 신뢰할 수 있어야 한다. 그래야 문제에 대한 공유가 이뤄진다. 다음으로 팀의 목표와 미션에 대한 합의(Alignment)가 있어야 한다. 그래야 제약 조건(시간)을 염두에 둔 의사 결정에서 팀의 목표(Common Goal)를 위한 결정을 할 수 있다. 물론 결과가 공짜로 만들어지지 않는다. 모두의 헌신이 있어야 가능하다. 당연히 노력에 대한 감사가 뒤따라야 한다. 그리고 이 과정의 반복되어야 한다. 그래야 주니어도 서서히 “못해요! 막힌 부분을 어떻게 하는게 좋을까요?“를 이야기하면서 최선의 팀 목표를 향해 함께 나아갈 수 있다.

하고싶은 일과 해야할 일.

몇 년 전 토익(TOEIC – Test of English for International Communication) 점수를 가지고 와이프와 내기를 했다. 영어 영어 하던 시절이었는데, 본인이 얼마나 하는지 아느냐면서 핀잔을 주길래 대강 이정도는 되지 않을까? 하면서 내가 점수를 이야기했다. 와이프가 그럴리가 없다며 시험 함 보라고 했다. 단 조건은 연습없이 보기! 20년전에 한번 시험쳤던 시험이 토익이었는지 토플(TOEFL – Test of English as a Foreign Language)이었는지 기억도 나질 않는 상황이었으니 처음보는거랑 크게 틀리지 않았다. 뭔 정신인지 몰랐지만 호기롭게 기출 문제지 한번 보지않고 시험장에 들어섰다. 듣기 평가는 그닥 어렵지 않았는데, 나머지 독해 문제에 크게 놀랬다. 첫째로는 문제가 정말 많고, 둘째는 지문이 왜 이리 긴걸까? 이 짧은 시험 시간에 이해하고 푼다고? 결국 마지막 10문제쯤은 찍기 신공을 발휘했다.

사실 우리의 현실 상황도 앞서 언급한 토익과 다르지 않다. 한 스프린트를 시작할때도 많은 일감들(Tasks)을 이미 가지고 있다. 관련된 일감들을 줄 세우고, 우선 순위에 맞춰 착착 진행시켜야 한다. 그래야 주어진 시간안에 일들을 마무리할 수 있다. 와중에 어떤 일은 시간이 걸리는 일이고, 어떤 일은 매우 어려워보이며, 다른 일은 동료의 작업을 위해 반드시 필요한 일이다. 이렇게 보니 일감은 서로 다른 난이도와 긴 지문의 토익 시험 문제와 비슷하다. 역시 풀어야할 정말 많은 시험 문제들처럼 일감들도 넘쳐난다.

시험을 망쳤다고 생각했을 때 더 짜증나는 건, 몰라서 틀린 경우보다는 아는 문제를 틀린 경우이다. 특히나 시간 관리에 실패해서 아는 문제조차도 틀린 경우는 화가 난다. 앞서 토익의 경우에도 생각없이 치를 수 있는 시험이 아니었다. 높은 점수를 낼려면 그만큼 연습이 필요한 시험이다. 사실 International Communication을 위해 이정도 빠르기로 지문을 읽을 필요가 있을까 싶긴 하다. 하지만 만약 점수를 생각한다면 지문 읽는 방법을 터득해야 한다. 아니 오히려 그 많은 문제들을 어떤 순서로 풀지도 알아야 한다. 문제 순서대로 풀다가는 제대로 망할 수 있다.

주니어의 일감 산정은 어찌보면 토익 문제 풀이와 유사하다. 우선 순위를 매겨본 경험이 없기 때문에 재미있거나 도전적인 일에 우선 매달린다. 하지만 이 일에 매달리다보면 정작 필요한 일을 제때 하지 못하는 경우가 왕왕 발생한다. 필요한 일이 어렵지도 않은데, 왜 일을 마치지 못했느냐라는 이야기를 들으면 아는 문제를 놓친 것처럼 화가 난다. 시험이라면 찍기라도 하면 될텐데…

현실은 시험이 아니다. 미리 연습할 수는 없지만, 경험을 통해 이를 보완할 수 있다. 이 부분을 보완해 줄 수 있는 사람이 시니어고 경험있는 리더다. 문제의 선후 관계를 짚어주고, 필요하다면 어떤 일이 팀에 혹은 본인에게 잘 맞을지에 대한 의견을 줄 수 있다. 이 의견을 참고해서 결국은 본인이 일을 수행하는 우선 순위를 매겨야 한다. 그리고 실행해야 한다. 놓치는 일이 없이, 선후 관계와 우선 순위에 따라 플래닝을 통해 예상한 일감들을 놓치지 않기 위해 노력을 다해야 한다. 시험 문제 가운데 찍지도 못한 문제가 짜증을 불러일으키는 경우가 현실에서 나오면 안된다.

우선 순위는 단순히 어떤 일을 먼저 할 것이냐의 문제가 아니다. 많은 일감을 해결할 수도, 혹은 중요한 문제를 해결할 수도 있다. 결국에는 내가 “해냈느냐?, 혹은 1인분 이상을 했느냐?”에 대한 성취를 결정한다. 성취가 제대로 이뤄지지 않는다면 짜증이 쌓일 뿐이다. 이 짜증이 발현되는 건 내가 아닌 남 혹은 팀을 비난하거나 일이 넘 많다는 불만이다. 시험 못봤을 때 짜증과 다르지 않다.

리더는 적절한 분량의 일이 주니어에게 돌아가도록 플래닝에서 신경써야 하지만 정해진 일감들의 우선 순위를 주니어가 제대로 잡고 있는지 점검을 해야 한다. 자칫 필(Feel)받는 일에 집중하다 전체 일감의 시간 관리에 실패할 수 있기 때문이다. 그리고 만약 시간 부족이 예상된다면 그 가운데에도 데모를 통해 보여줄 중요 가치 일감이 뭔지, 주니어와 소통해야 한다. 이런 부분들이 잘 동작될 때 가치있는 일에 집중하고, 제대로 성취를 느낄 수 있다.

주니어를 리딩한다는 것

좋은 말로 하면 경험의 내재화, 직설적으로 표현하면 GG치지 않도록 관리하는 것이랄까? 어렵다. 하지만 몇 년의 기간을 이겨내면 지식(Knowledge)이 지혜(Wisdom)가 된다. 그리고 일상에서 머리가 아닌 마음으로 일하기 시작한다면 이제 주니어라는 고비를 넘어서는게 아닐까 싶다. 과정에서 주니어가 이야기할 수 있는 분위기가 필요하다. 그리고 열린 태도로 문제를 대할 수 있어야 한다. 이것들이 가능할려면 “상호 신뢰(Mutual Trust)“가 담보되어야 한다.

주니어 스스로가 이 과정을 버티는 힘이 도전과 성취라고 생각한다. 끊임없이 도전해야 한다. 할 수 있는 좋은 환경이면 좋겠지만, 도전은 환경을 가리지 말아야 한다. 도전을 위해 푹신푹신한 쿠션을 깔아주는 곳은 없다. 자갈밭이고 가시밭이다. 이미 편한 자리는 다른 사람들이 모두 차지했다. 척박한 그곳이 주니어가 도전을 시작할 장소다.

주니어의 리더는 주니어가 있는 곳이 자갈밭이라는 사실을 알려줘야 한다. 그리고 그 장소가 주니어가 그 다음을 위해 뛰어야 할 장소라는 것도. 물론 넘어지고 엎어질 것이다. 분명 다칠 것이다. 리더는 방향을 제시한다. 그리고 옵션을 제시한다. 하지만 선택은 주니어 몫이다. 위험하지만 짧은 길로 갈지 혹은 먼길로 안전하게 돌아갈지. 다쳤을 때 약을 발라줄 수는 있지만 다친 사람이 주니어 자신이라는 건 변함없는 사실이다.

결국 리더의 코칭을 받아들일지 말지는 주니어의 선택이다. 그리고 주니어가 리더의 방향에 맞춰 또 뛰어도 후회하지 않기 위해서는 상호 신뢰가 있어야 한다. 신뢰를 바탕으로 한 도전과 경험이 내재화되면 우리는 이걸 “성장”이라고 이야기한다. 성장은 누가 만들어주는 것이 아니다. 주니어 스스로 해내야 한다. 다만 제대로된 주니어와 리더의 신뢰는 성장의 촉진제 역할을 해줄 수 있을 것이다.

– 끝 –

Continue reading ‘Money Making’ »]]>

돈은 중요하다. 아마도 인류가 발명한 것 가운데 현재 시점에서 가장 가치를 평가받는 물건이 아닐까 싶다. 디지털 세상이 된 지금은 지폐마저 보기 힘들어졌다. 많았던 적이 없어 모르지만 일상에서 돈의 존재는 명확하며 없으면 확실히 궁핍해진다. 때문에 우리는 육체적 혹은 정신적 노동, 즉 일을 통해 이를 획득한다. 그리고 가능하면 힘을 적게 쓰고 많이 벌 기회를 찾는다.

노동의 기본 목적은 생존이지만, 이제 인간적인 삶으로 확장된다. 노동을 통해 얻어진 돈은 생계와 나아가 생활을 위해 필요하다. 먹을걸 직접 키우는 시대는 아니니까. 나의 시간을 투여해 얻은 가치를 다른 사람의 생산한 가치와 교환하기 위한 수단으로 돈이 있어야 한다. 필요한 것들이 많거나 높은 가치의 물건이 필요하다면 그만큼 많은 돈이 있어야 한다. 다른 말로 힘을 많이 써야한다, 벌어야 한다.

세대를 지나오면서도 돈의 중요도는 점점 더 올라가고 있다. 삶의 가치가 생존에서 생활로 옮겨왔기 때문이다. 생활이 생존을 압도하는 가치 변화가 확고해졌고, 생활 수준 차이가 계급으로 인식되니 더욱 더 돈이 중요해졌다. 산업의 시대를 넘어 이제 자본의 시대니만큼 중요함을 넘어 전부가 되어가는 것도 자연스러운 현상인가 싶다. 모순되지만 수단이 목적이 된 셈이다.

직업으로써 소프트웨어 엔지니어의 길을 가고 있다. 사람들에게 가치를 줄 수 있는 제품과 서비스를 내 역량을 발휘해서 제공하고 대가로 보상을 받고 있다. 물론 높은 연봉을 받으면 좋다. 내가 한 일 혹은 하는 일이 그만큼의 가치를 인정받기 때문이다. 할 일의 가치를 미리 인정받는다면 좋겠지만 미래의 나를 저당잡히고 싶진 않다. 돈은 수단이고, 길을 열심히 가기 위해 활활 태울 연료일 뿐이다. 수단을 내 삶의 목적으로 삼고 싶지 않다.

그런 면에서 이직은 반갑지 않은 변곡점이다. 직업으로써 개발자로써 개발 분야에 몸담고 있다는 건 다행이다. 그럼에도 직장이 바뀐다는 건 내 역량을 투사할 대상의 변화(Pivoting)을 의미하고, 과정 전후에 필수적으로 비용도 함께 따라왔다.

첫번째 이직: 작은 기업에서 대기업으로

“일을 왜 이따위로밖에는 못하나?”라는 스스로의 자책에 답하기 위해 아이엔소프트에서 일을 시작했다. 사회 초년생 리더의 패기가 얼마나 일을 망가트리는지를 경험한 직후였다. 제대로 일하고 싶었고, 제대로 된 제품을 만들고 싶었다. 몇년의 고생끝에 제품을 만들긴 했지만, 잘 조직된 개발팀의 필요를 뼈저리게 느꼈다. 질적으로 양적으로 커진 팀이 있어야 다음 버전을 완성할 수 있었다. 더 이상 사람들을 갈아넣기 싫었다.

하지만 쉽지 않았다. “돈을 주는 사람”이라는 말을 되풀이하는 사람과의 끝없는 언쟁이 해결될 기미도 없었다. 다 포기하고 조직화된 체계에서 일을 하는 경험을 늦게라도 갖고 싶었다. 그래야 후회하지 않을 것 같았다. 서른일곱, 늦깍이 자발적 이직을 처음 결정했다.

두번째 이직: 조직에서 사용자 중심으로

이사라는 직함과 연봉을 포기하고 네이버로 이직했다. 큰 회사로 옮기는 걸 원했던 와이프도 낮아진 연봉에 생활을 걱정했지만, 그나마 편안해진 마음을 위로로 삼았다. 옮기고 큰 조직이 어떻게 일하는지, 어떤 기술을 쓸 수 있는지를 봤다. 제품이 아닌 서비스가 어떤 방식으로 기획되고, 만들어지고, 운영되는지. 그리고 이를 위해 소위 헌신(Commitment)이 어떻게 동작되는지를 경험했다. 5년이 채 안되는 시간 사이에 사원으로 시작해서 팀장으로, 그리고 대표이사에게 안된다는 이야기를 해볼 수 있는 위치까지 도달했다.

낮았던 연봉은 회사의 성장과 서비스의 성장 그리고 역할의 책임이 커지면서 금새 이전을 상회하는 수준으로 올랐다. 그리고 매출이 아닌 서비스를 사용하는 고객 가치에 중심을 둬야한다는 생각까지 가지게 됐다. 물론 개인적인 생각이었다. 보상을 중시했다면 생각으로만 담아뒀어야 했다. 하지만 팀장으로써 이걸 실행했고, 대차게 까였다. 조직 리더가 생각하는 방향과 한참 벗어났었다. 돌이켜보면 이상이야 어찌됐든 조직 구성원으로써 하면 안됐다. 할려면 위, 옆, 아래 구성원들과 충분히 합(Alignment)를 맞췄어야 했다. 하지만 이미 조직적으로 사용자 중심의 개발을 하는 것에 대한 열망이 커진 상태였다.

세번째 이직: 한국에도 제대로 된 개발 조직

먼 퇴근길에 어느새 동반자가 된 소주 한잔을 하면서 라이엇게임즈 코리아 류석문 이사님 기사를 봤다. 네이버 처음 시절에 3개월정도 스쳐 지난 과거 경험으로, 이 분이라면 되지 않을까? 생각했다. 두병을 비워가는 즈음에 메일을 보냈고, 개발자로 지원하시라는 회신을 받았다. 면접이 마무리되는 6개월 지난 즈음 전년도 원천징수 서류를 보냈다. 딱 그 수준으로 처우 제안 메일이 왔다. 다음날 바로 동의한다고 회신했다. 최단기로 처우 협상이 완료된 케이스라고 나중에 들었고, 그렇게 라이엇에 합류했다.

그저 개발만 하고 싶었지만 팔자탓인지 원하는대로 되지 않았다. 미국”계” 회사였고, 글로벌 회사였다. 어버어버하던 시골 촌놈이 질리다못해 익숙해질만큼 영어로 이야기했다. 뻔질나게 미국 다니면서 이코노미 클래스(Economy class) 증후군도 겪었다. 일을 하는데 얼굴보면서 이야기하는게 왜 중요한지 그러면서 알았다. 무엇보다도 개발(Programming)의 종주국인 미국이 한국과 어떻게 다른지도 배웠다. 기술이 아닌 기술 문화와 프로세스의 힘이 얼마나 큰지.

그럼에도 한국팀의 역량을 제대로 보여줬다. 그 힘들다는 한국의 법적 요구 사항을 기술로 해결했고, 고객 지향의 서비스들도 만들어졌다. 이러면서 리그(League of Legends)만 서비스하는 회사가 아닌 멀티 게임 회사로 성장했다. 물론 회사의 성장과 맞물려 보상도 커졌다. 한국의 빠름(기술력)과 미국의 기술 문화 조합이 글로벌의 방향을 제때 한국 시장에 실현시킨 결과라고 생각한다. 이 경험을 제대로 된 조직으로 확장하고 싶었다. 의지와는 달리 로컬 오피스(Local Office)의 한계는 이 확장을 제한했다. 하지만 한국에 제대로 일하는 제대로된 개발 조직을 완성하고 싶었다.

그 좋은 회사를 왜 그만두냐?

완성형을 위해 쏘카로 이직했다. 이기적인 선택이다. 당장의 보상보다는 하고 싶은 일을 선택했으니.

이직을 결정 할 때마다 “그 좋은 회사를 왜 그만두냐?”는 이야기를 들었다. 조직적인 안정감과 인정 그리고 결론적으로 보상이라는 측면에서 네이버도, 라이엇도 나쁘지 않은 회사였다. 아니 좋은 회사였다. 하지만 각 시점에 이걸 넘어서는 채우고 싶은게 있었다. 다행히도 이 절박함을 채우기 위해 열심히 하는 과정에서 언제나 보상은 자연스럽게 따라왔다.

왜 이직 할려고 하나?

경력자 인터뷰의 단골 질문이다. 대부분 본인의 성장을 말한다. 좋은 이야기다.  쏘카에서는 역량을 보고, 협업의 가능성을 보고, 성장의 가능성을 본다. 서로의 기대치가 부합되면 이제 “처우”라는 현실을 논의한다. 처우협상은 인터뷰 과정을 통해 확인한 상대의 역량을 돈이라는 현실로 확인한다. 현실에서 서로에게 요구하는 기대치는 항상 다르다. 작은 차이라면 협상이 동작할 수 있다. 하지만 많은 경우, 지원자의 기대와 회사의 기대는 어마한 차이를 보인다. 더욱이 최근 이 경향은 더 뚜렷하다.

큰 차이를 직면했을 때 궁금증이 생긴다. 좋은(매우 좋은) 대우를 이미 받고 있는데 왜 이직을 하려는지? 현재 역량 대비 이미 높은 처우를 받고 있음에도, 이직을 원한다는 건 속된말로 돈값을 못했다는 것을 의미한다. 물론 환경이 바뀌면 달라질 수 있을 가능성도 약간 있지만, 과연… 1인분에 대한 의구심은 떨칠 수 없다. 특히나 리더급의 역량이 기대하는 분의 평가는 더욱 냉정해야 한다. 당연히 1인분의 역할을 해야할 뿐만 아니라 동료가 1인분을 감당할 수 있도록 만들 책임이 있기 때문이다.

이직이라는 수단을 연봉 뻥튀기 수단으로 사용하시는 분들을 요즘 너무 자주 본다. 2년도 안된 잦은 전직 경력으로 높은 처우 인상을 요구하시는 분들이다. 요즘은 이런 경향이 주니어 지원자들에게서도 나와 우려스럽다. 2년 미만 이직 이력이 있고, 경력 대비 높은 연봉을 요구하는 분은 아무리 높은 기술 역량을 갖췄더라도 드랍(Drop)한다. 회사의 미션에 공감하기 보다는 돈을 추구할 가능성이 매우 높기 때문이다.

우려스러운 건 1~3년차 신입이 이미 너무 높은 고액 연봉을 받는 경우다. 이런 경우를 연봉의 저주라고 이야기해야할까? 이런 분들을 받아줄 회사는 흔치않다. 그렇다고 본인의 자존심인 연봉을 깎을 수는 없으니 묶이게 된다. 다양한 경험을 통해 성장해야 함에도 불구하고 우물안에 갇히게 된다. 물론 다양한 경험을 해볼만큼 규모가 큰 회사라면 다행이다. 하지만 그정도 크기의 회사라면 고액 연봉을 주진 않는다. 본인의 가치를 증명하는 가장 효과적인 방법은 성장을 통해 주변에게 그리고 본인 스스로에게 자연스럽게 인식되도록 만드는 것이 최선이다. 이직해서 성장을 경험할 수 있지만, 이직한다는 것 자체가 성장을 의미하지는 않는다.

보상은 닭이 먼저냐 달걀이 먼저냐 논리와 같다. 나는 개인이 회사 구성원으로써 기여를 보여주는게 먼저라고 생각한다. 금전적 보상은 반드시 있어야 하지만 역량의 증명이 우선이다. 보상을 가장 앞에 두고 이야기하는 조직원에게는 “돈값”을 명확하게 요구해야 한다. 세상에 공짜는 없으니까.

Continue reading ‘Autonomy – 자율, 자율조직이란?’ »]]> 자율(Autonomy)이라고 이야기를 했지만… 사실 꼬치꼬치 “이렇게 하세요, 저렇게 하세요!”라는 각론에 대한 지시를 싫어한다. 개인적인 성격이다. 목적지만 정해지면 그리로 가면 되는거지. 부산가는데 꼭 천안, 대전, 대구를 거쳐갈 필요는 없다. 하지만 왕왕 천안, 대전, 대구에 목숨거시는 분들이 있더라. 모로가도 부산만 가면 된다.

포장하자면 자율적으로 일하는 방식을 좋아한다. 자율적 방식은 나의 혹은 확장하면 팀의 방식으로 일을 계획하고 진행하고 마무리하는 것이다. 어찌되었든 “일”이라는 것은 있다. 그리고 일의 종착지는 결과다. 결과를 만드는 것이 우리의 몫이라면 과정은 진행하는 사람들이 정할 수 있어야 한다.

과정이 실제 흘러갈려면 그 선택에 대한 인정 혹은 존중이 있어야 한다. 과정이 성공을 보장하지는 않는다. 다만 그 과정이 물 흐르는 것처럼 자연스럽길 원한다. 물론 대부분 장애물을 만나서 굽이치고, 심지어 몇십미터 폭포를 지난다. 이런 경험을 거치다면 보면 자연스러움이 과정에 스며들 것이다. 그래서 자연스러워질 것이다.

물론 인위적인 시스템으로 만들어진 물길도 있다. 사람이 만든 운하같은 물길처럼. 운하의 물길은 쭉 뻗어있다. 물론 이것이 가능한 이유는 이를 움직이는 체계 혹은 시스템이 있기 때문이다. 이런 물길은 만들어야 한다. 이 들어간다.

자율, 어렵다.

우리는 일을 한다. 그리고 일의 과정이 빠르게 결과를 만들어내길 기대한다. 성공이든 실패든. 이 “과정”이 자연스럽고 막힘없이 흘러간다면 인정하고 존중할 수 있다. 이것이 자율이라고 나는 생각한다.

물론 자율적으로 일한다는게 말처럼 되는 건 아니다. 언제나 어디서나 장애물은 존재한다. 장애물을 만났을 때 우리는 “결정”을 해야한다. 사실 우리의 성장 과정이나 교육 시스템은 스스로 결정을 많이 허용하지 않았다. 혹은 스스로 결정하지 않아도 원하는 결과를 얻을 수 있기 때문에. 이런 환경에서 성장한 사람들에게 스스로 결정해서 일을 하라는 건 말 그대로 도전이다.

이런 이유로 많은 사람들이 사전에 정해진 규칙을 요구한다. 혹자는 이 상황을 즐겁게 받아들이는 반면 “짜여진 시스템이 없는데 어떻게 일을 하라는 말이냐!” 라고 반문하는 분들도 많다. 특히 이런 분들 가운데 다수는 결정뒤에 따라올 미지의 결과를 상상하는 것 자체를 고통스러워한다. 물론 이런 분들을 위한 시스템을 만들 수 있다. 하지만 사람을 움직이는 시스템은 운하와 같은 물길과는 다르다. 생각하는 존재인 사람은 물과 같지 않기 때문이다. 때문에 시스템은 완벽할 수 없고, 그 체계 안에서도 우왕좌왕하기 일쑤다.

이런 고통을 극복한다고 하더라도 결정의 범위가 개인의 역량을 넘어서는 경우가 왕왕 있다. 사실 “결정한다 = 책임진다” 라고 생각한다. 조직에서 구성원 개인이 책임질 수 있는 범위는 매우 매우 제한된다. 본인이 “너가 뭔데?” 라는 질문에 당황할 수 밖에 없는데… 이때 필요한 것이 리더다.

그래서 리더는

자율 조직에서의 리더는 방향을 제시하고, 그 방향에 맞춰 구성원들이 각자가 필요한 결정을 내리도록 돕는다. 결정과 예상되는 결과에 대해서도 조언한다. 그리고 구성원의 결정을 존중하고 이를 지지해주며 최종적으로는 이를 책임진다. 이는 리더의 경험과 지혜에서 발현되는 것이다. 리더는 지식이 필요하지만 지식이 리더를 만드는 것이 아닌 이유다.

이 과정에서 리더는 결정을 돕는 사람이어야 한다. 구성원이 스스로 내린 결정하고, 스스로 책임감을 가지고 결과를 만들기 위해 행동하는 것. 이래야 구성원은 내적 동기를 가지고 행동할 수 있고, 스스로 만들어낸 결과는 스스로의 자부심을 배가시킬 수 있다.

물론 결정은 쉬운 일이 아니기 때문에 충분한 정보가 필요하다. 리더는 구성원이 충분히 정보에 접근할 수 있도록 하고, 필요한 적정 수준의 정보를 제공한다. 과도한 정보는 오히려 독이 되므로 넘치지 않도록 관리해야 한다. 이를 통해 도출된 결정이 어느 정도 합리성이 있다면 이를 존중하고, 실행될 수 있도록 뒤받침을 하면 된다. 성공은 결정하고 실행한 구성원의 몫으로, 실패는 리더가 책임진다. 이런 모습이 아름답다.

결정은 항상 누구에게나 어렵다. 대부분 이 결정을 위해 많은 신중한 토론이 있다. 리더는 이 과정을 잘 관찰해야 한다. 사람 사이의 토론은 결론없이 공회전하는 경우가 많다. 이 경우에는 합리적인 방안을 리더가 참여자들을 대신해서 결정할 수 있다. 충분한 시간의 논의와 의견 교환이 있었다면 결정을 내려야하고, 리더가 결정한다. 리더의 결정은 존중받아야 하고, 실행되어야 한다.

자율 기반의 조직이니 당연히 참여자들간의 토론을 통해 결정되어야 하는 것이 아니냐는 이야기를 듣는다. 좋은 지적이지만 토론만 하고 있을 수 없다. 우리는 결정 이후에 이어지는 실행이라는 시간을 거쳐야한다. 실행 시간 역시 결과를 결정짓는 중요한 요소다. 이 전반의 상황과 진행을 관리하는 것이 리더의 역할(권한)이고 책임이다.

간혹 자율 기반 조직에서 모두가 평등하기 때문에 동의할 수 없다고 이야기하는 사람도 있다. 예를 들어 자신이 주장이 합의된(혹은 리더가 결정한) 의견이 고객 가치에 반한다며 수긍하지 않는 경우가 있다. 예시이긴 하지만 딱 고객 가치를 무기화(Weaponize)하는 경우다.

정말 본인의 주장이 옳다고 생각한다면? 모든 조직에는 체계가 있다. 상위 리더에게 이야기하면 된다. 다만 이 주장이 조직 체계를 통해 납득되기 전까지는 리더의 의견을 존중해야 한다.

자율적이면 빨라질까?

자율적으로 의사 결정하고, 일이 진행되면 정말 빨리 진행될 것이라고 생각하나? 정말??

사실 일이 빨리 진행되는 조직은 군대가 아닐까? 왜? 지시가 위에서 떨어지고, 떨어진 지시를 실행하면 되는 조직이 군대이기 때문이다. 이 조직에서 지시에 대한 반문은 (거의)없다. 하지만 우리가 군인은 아니니까.

우리는 결정을 해야한다. 혼자 하는 결정이라도 생각을 해야한다. 우리는 호모사피엔스니까. 하물며 팀이 결정해야 하는 경우라면, 결과로 도출해야할 “가치”를 어떻게 실행할지 결정하는 과정에서 적절한 토론과 논쟁은 필연적이다. 시간은 필수다.

하지만 이 과정을 거쳐 자율에 대한 의미가 조직 전반에 공감되면… 그때 소위 속도가 나온다.

“자율적”이 되는 건 매우 어려운 도전이다. 토론과 논쟁도 어렵고, 이것들이 학습이라는 과정을 통해 내재화되어야 한다. 또한 시간은 매우 큰 변수다. “자율적”인것에 대한 기대감이 주는 중압감도 매우 크다. 시간이라는 변수와 함께. 따라서 조직의 합의와 함께 리더십으로부터의 지원이 필요하다.

자율 조직을 일단 정의했고, 실행중이다. 과연 이 결론이 이 그래프의 상향점을 향할지는… 현재 진행형을 완성형으로 만들기 위해서는 다 방면의 투자가 더 필요하다. 가보자!

Continue reading ‘현실에서의 재택 근무’ »]]> 지난 3월 초에 재택 근무에 대해 간단히 글을 적었는데, 어느새 원격 근무를 5월 중반까지 해오고 있다. 회사 전체적으로는 2월말부터 원격 근무를 시작했으니 어느 덧 만 3개월을 다 채워가고 있다. 이 정도의 기간을 재택으로 지내다보니 얼추 이런 근무 형태도 할만하다는 생각이 든다. 업무만 봤을 때 해야할 일들이 거의 적절하게 진행되고 있는 느낌이긴 하니까.

재택 근무의 일상을 정리해보면.

출장을 못가다보니 본사쪽과 일은 지속적으로 챙겨야 한다. 슬랙으로 이야기가 잡다하게 길어질 것 같으면 아침에 콜을 잡지만, 그렇지 않은 경우에는 커뮤니케이션 하는 타이밍을 잘 잡아서 끊어지지 않게 해야한다. 말 그대로 이야기 줄기가 끊어지면 잊혀진다. 끊어진 걸 다시 이어 붙이려면 어렵기도 하고 투자해야할 시간도 많이든다.

그래서 아침 기상 시간은 재택 전과 비슷하게 6시 반이나 7시 사이를 유지한다. 전날 보내 둔 메시지에 대한 답글을 확인하고, 우리쪽 채널에 올라온 요청들이 있는지를 휴대폰으로 확인한다. 일상 다반사가 항상 바쁜 건 아니지만, 답을 얻어야 하거나 논쟁중인 사안이 있다면 후다닥 노트북 앞에 앉는다. 지금 내가 이야기를 던져야지 그 친구들이 답한다. 본사쪽은 오후 4시 근방이라 아직 일하고 있을 시간이다. 30분, 한시간 가량 본사 친구들과 이야기를 하고, 우리가 챙겨야 할 사항들이 있다면 관련 팀 채널에 내용을 전달한다.

출근 준비

8시 즈음에 시작하는 뉴스를 본다. 전에는 다음 뉴스에서 주로 새소식을 들었다면 재택 이후에는 YTN이다. 종종 쉬는 시간에도 가까이에 있는게 TV다 보니 정말 자주 보는 것 같다. 어제 발생한 코로나 이슈들을 중심으로 이야기를 듣는다. 참 세상 개념없는 인간들이 많다라는 걸 이번 사태를 겪으면서 다시금 확인한다. 국내, 국외 모두.

이쯤되서 와이프가 아침먹으라고 힘찬 소리를 들려주신다. 온라인 수업으로 등교해야만 하는 딸네미가 허우적 거린다. 처음 온라인으로 수업이 진행될 때만해도 짜증 대마왕이었다. 하지만 최근에는 동영상 스트리밍도 안정화된 것 같고, 한번 들은 수업을 다시 들어야하는 경우는 없어진 것 같다. (LG, MS 에저 화이팅!) 재택하면서 딸과 같이 밥먹는 시간이 많아졌다는 건 정말 좋다. 물론 전에도 아침은 매번 같이 먹긴 했지만 6시 반에 먹어야만 하는 아침밥이 딸에게 기분좋은 식사는 아니었을테니까. 온라인 수업 시간의 아침밥 먹는 시간은 8시에서 8시 반이다. 이정도만 되도 거의 짜증이 없었다. 전에는 왜 7시 반까지 등교하라고 한거지? 걍 9시까지 등교하라고 해도 충분할 것 같은데. 학교와서 책상에 코박고 잘께 뻔한 걸.

밥 든든하게 먹고 출근 준비한다. 양치하고 면도하고 샤워하고. 단장하고 근무복으로 갈아입는다. 이제 준비 완료!

완전 아재스럽다. 그렇다고 꽃중년도 아니니 걍 스킵. 을 보고 아이디어를 얻은 건 아니다. -_-;;; 하지만 넘 편하면 Naive해지는 건 어쩔 수 없이 부장님에게 동의. 전에도 이렇게 입었는데 걍 근무복이라고 생각하자. 사실 미팅하다보면 난닝구(메리야쓰???)부터 잠옷, 샤워 가운까지 다양하게 등장한다. ㅎㅎ; 일만 잘하면 되지, 복장은 편한 스타일대로 입는거지 뭐.

출근해서 업무 시작

회사에 출근했을 땐, 커피 머신에서 내려먹거나 바리스타분께 부탁드려 한잔 먹는게 습관이었는데, 그 습관 버리기 힘들다. 재택에서는 내가 바리스타.

이렇게 내린 커피는 전자렌지의 도움을 받아서 오후까지 먹는다. 물론 그 사이에 믹스도 두봉지쯤은 달달하게 타 먹지만. 막 내린 커피들고 이제 출근한다. 아드님께서 학교로 가버린 이후에는 아들 방이 내 근무처다. (탱큐~ 아들!) 좀만 제대로 된 공간이었다면 더 좋았을걸 하는 아쉬움도 있긴 하지만. 거실 한켠에서 쪼그려서 일하던 때보다는 한결 낫다. 9시 반에서 10시 사이에 자리에 앉아서 이제 본격적으로 근무를 시작한다.

오전 근무는 밤새 온 이메일들을 정리하고, 어제 퇴근 이후에 한국쪽에서 이야기된 내용들을 살펴보는 것으로 시작한다. 대부분 슬쩍 훝어보고 지나가지만, 간간히 참견해야할 내용들이 이메일로 온 경우가 있다. 필요한 것들에 대해서만 회신한다. 메일과 슬랙 훑어보는게 끝나면 이제 아침 데일리전에 해야할 코드 작업이나 할당 작업들을 한다. 데일리에서 공유할 내용들 대부분은 어제 해두긴 했지만 간간히 미진하거나 마무리 못한 꺼리가 있다. 아침 이 시간이 집중이 잘 되기 때문에 나름 일할만 하다. 마무리가 됐다면 Jira Ticket을 Done으로 marking한다.

데일리(Daily)

오전 근무의 하이라이트는 데일리(Daily)다. 에자일을 고집하는 분들이나 전문가들이 이야기하는 Daily는 아니다.Jira 보드 놓고 한일/할일 혹은 넋두리를 한다. 어찌보면 딱 아침 조회다!! ㅎㅎ

11시가 되면 5~7명쯤 개발팟 인원들이 행아웃에서 모인다. 가장 연장자 분이 BGM을 깔아놓으면 사람들이 모일동안 감상의 시간을 갖는다. 얼추 참석자들이 모이면 진행자가 순서대로 Jira 보드에서 담당자를 선택하면 업무 이야기를 공유한다. 오늘 할일이나 어제 겪었던/논의했던 이슈나 Blocker들에 대해 이야기한다. 진도를 많이 빼신 분은 Backlog에서 할만한 일이나 Sustaining꺼리를 물어본다. 동료가 봐줬으면 하는 걸 이야기하면 그걸 도와주거나 아님 팟 리드가 처리되어야 할 꺼리를 백로그에서 뽑는다. 두루두루 이야기하고, 마지막으로 팟 리드가 어떤 일들이 있으면 챙겼으면 좋겠다는 것으로 마무리한다.

형식을 보면 에자일식은 아니고 칸반 스타일인가? 오피스에서 모여서 이야기할 때는 15분안에 끝내는게 목표였고, 대부분 그 시간안에 마쳤던 것 같다. 하지만 온라인으로 진행하면서 전체 시간이 좀 오래 걸린다. 이건 꼭 데일리 뿐만 아니라 거의 모든 회의들이 오피스 미팅룸에서 모여서 하던 것보다는 전체적으로 길어졌다. 한번에 여러 사람이 한꺼번에 이야기할 수 없다는 제한이 있기 때문이기도 하고 같이 얼굴 맞대고 이야기할 기회가 없다보니 다들 한 두마디씩 더 하는 것 같다. ^^;

Work & Break in the afternoon

정리하고 데일리에서 나온 것들 가운데 바로 F/U해야할 꺼리를 봐주고 하다보면 12시다. 12시라고 꼭 밥 시간은 아니다. 하지만 2시간 정도 일했으니 쉬는 시간이 맞긴 하다. 닫혔던 방문 열고 거실로 나가서 가족들과 잠깐 이야기도 하고 새로 나온 코로나 확진자 수도 확인한다. 최근에는 거의 자리수가 한자리 수라서 다행이라는 생각이 든다. 하지만 백신과 확실한 치료제가 나오기 전까지는 끝나도 끝난게 아니라는거.

내가 때를 챙기지 않더라도 따님 덕분에 1시 되기 전에는 거의 점심을 먹는 편이다. 물론 삼시세끼를 다 챙기느라고 와이프 고생이 많다. 와중에 나는 미팅중, 딸은 온라인 수업중이라 와이프만 쥐죽은듯이 거실이나 침실에서 꼼짝도 못한다. 얼떨결에 갇힌 신세가 되버렸다. 원래 집에서 낮시간은 와이프의 공간과 시간이었는데, 난데없이 딸과 내가 이걸 빼앗아버렸으니…

점심 먹고, 커피 한잔 후 다시 문닫고 업무 복귀. 데일리를 빼고 하루에 보통 1~2개의 미팅이 있다. 한국팀과 미팅은 거의 한시간을 꼬박 채운다. 참석하는 사람도 좀 많은 편이고 사람당 두서너 마디 이야기가 돌고나면 훌쩍 1시간을 채우는게 다반사다. 미팅 끝나고, 메일이나 슬랙 메시지 보내다보면 두시간쯤이 훌쩍 간다. 거북 형상으로 목이 뻣뻣해질 때쯤이면 거의 3시 근방이다. 쉴때다.

오후에는 한두번쯤은 아파트 주위를 3~4번쯤 돈다. 3월부터 거의 빼먹질 않았다. 덕분에 시간이 이렇게 가고 자연이 이렇게 변해가는걸 눈으로 본다. 그 전에는 제대로 느끼지 못했던 새로움이다. 그러고보니 겨울의 끝자락에 이 생활을 시작해서 이제 여름으로 접어든다.

산보에서 복귀 후 다시 일을 시작한다. 대강 요 무렵이면 집안일의 갱킹이 들어온다. 5시나 6시 근방이면 쓰레기를 버리거나 분리 수거에 관련된 업무 요청이 들어온다. 잘 보여야 후환이 없기 때문에 정 급하지 않으면 바로 처리해야 한다. 그래도 이 시간 타임이 가장 일을 많이 하는 시간대다. 2~3시간 연속으로 몰입해서 일할 수 있는 시간이 많다. 최근 2~3주 사이에는 코딩 이외의 다른 행정 업무들이 많아서 이런 시간을 갖기가 어려웠는데, 대강 마무리해서 다시 코딩에 복귀하고 있다. 이렇게 중간에 쉬어버린 시간이 많으면 예열에도 시간이 오래 걸린다. -_-;;; (몸은 못 속이나?)

퇴근

6시 반이나 7시쯤되면 따님이 “퇴근했어?“고 물어본다. 상황따라 약간씩 잔업이 있긴 하지만 대부분은 그 시간 즈음이면 슬랙 채널에 “퇴근합니다.” 라고 이야기한다. 슬랙 알람은 7시가 지나면 자동으로 Off된다. 바꿀 수도 있지만 굳이 그러지않는다. 일단 해야만 하는 일들은 처리했고, 해야할 일들은 Calendar에 적어두거나 Ticket으로 정리해뒀다. 이제 정말 놓친 일들이나 내가 하고 싶은 것들을 한다.

오후 내내 놓친 뉴스를 좀 보기도 하고, 못읽은 책을 읽는다. 책을 읽는다고 이야기를 해봐야 하루에 한시간 남짓이 될까말까다.

와이프와 딸과 저녁먹고, 최근 재미있는 드라마나 예능 보면서 이야기를 나눈다. 이전에는 가족과 이야기하는 시간이 평균 30분 넘을까 말까였다면 재택 이후로는 적어도 1시간 이상이 되니까 고건 참 바람직하다. 특히 딸과의 대화 시간이 많이 늘어난 건 개인적으로 기쁜 일이다.

재택. 하다보니.

일하는데 있어서 몇가지 보이는 것들이 있긴하다. 일단 준비된 재택 근무를 하기 위해서는 필요한 것들이 많다. 그 가운데서 가장 큰 문제는 가족으로부터의 동의와 협조가 무엇보다도 필수적이라는 것이다. 집에서 일하는 것에 대한 가족의 인식과 협조가 없다면 재택은 불가능하다. 특히 현재의 재택 상황을 봤을 때 더욱 그렇다.

챙김이 필요한 육아를 본인이 병행해야하는 상황에서의 재택은 불가능하다. 차라리 휴가를 내는게 본인의 정신 건강을 위해서 낫다.

커뮤니케이션에서 진심이 보여야 한다. 그래서 온라인 화상 통화에서 얼굴은 가급적 보여줘라. 정장을 입고 있으라는 이야기가 아니다. 말 그대로 얼굴을 보여주라는 것. 대화에서 표정과 제스처는 생각 이외로 많은 것들을 전달한다. 이건 수화에서 왜 표정이 중요한 역할을 하는지와 어찌보면 같은 맥락일 것이다. 한국팀은 그래도 본사 친구들과 콜을 많이 해서 기본적으로 얼굴을 보여줄 것이라고 생각했는데 이외로 거의 보여주지 않는다. 보여주지 못한다면 못하는 그것 자체에 문제가 있다. 육아 관련 예외를 빼고 나머지는 이유가 안된다.

명확한 근무 시간을 명확히 하고 알려야 한다.  본인을 위해서도 협업하는 동료들을 위해서도. 종종 재택이라고 근무 시간을 본인들의 작의적으로 정해버리는 경우가 있다. 근무 시간을 정하는 이유는 협업을 위해서다. 당연히 한국 상황만 놓고 본다면 9시부터 6시 사이를 근무 시간으로 정한 이유는 그 시간이 보편적으로 연락 가능하고 협업이 가능한 시간임을 모두가 암묵적으로 동의하기 때문이다. 메신저 뒤에 숨어서 페이크치다 걸리면 쪽팔린다. 재택이라고 하더라도 근무 시간이 변경된 건 없다. 가능하면 지켜야 하고 못지키면 이야기해서 협업에 방해되지 않도록 알려야 한다.

부재는 알려라. 오피스 공간에서 근무를 선호하는 이유는 고개 돌리면 동료가 옆에 있고, 이야기할 수 있기 때문이다. 온라인으로 일을 하는 경우에도 마찬가지 환경이 되야 한다. 오피스에도 자리 비운다면 자리 비운다고 동료에게 이야기한다. 마찬가지로 행동하면 된다. 재택이라고 다르지 않다.

팀을 생각해야 한다. 재택은 공간적으로 팀을 배제한다. 혼자있는데 뭔, 팀… 때문에 더욱 더 개인화된다. 같은 공간에 팀이 모여있는 공기와 자신만의 공간에서 느끼는 공기는 당연히 틀리다. 팀이 팀으로 느껴지는 이유는 공간적인 이유가 크다. 하지만 재택은 이를 분리한다. 이런 거리감을 인위적으로 줄일 수 없다. 강제로 줄여봐야 파열음만 난다. 스스로 팀원이어야 한다. 자발적으로 팀의 상황을 이해하고 팀의 발전을 위해 기여해야 한다. 정해진 일만 하겠다면 재택과 맞지 않는다. 아니 되려 팀 플레이 자체가 맞지 않는거 아닐까도 싶다.

••••••

재택은 팀 플레이를 시험한다고 보여진다. 공간으로 분리된 상황에서 개인이 팀이라는 인위적인 공동체를 유지할 수 있을 것인가? 이 과정에 스스로 있기도 하고, 결과가 어떻게 나올지 기대된다. 본사에서도 실패했고, 때문에 공간을 중심으로 팀을 유지하는 것이 현재 정책이었다. 이제까지 나도 이에 동감했고, 크게 바뀌지 않았다.

하지만 기대 이외의 결과를 보고 싶다. 당장 재난 형국을 넘어서기 위해서도, 그리고 먼 미래를 위해서도 ^^;

Continue reading ‘Pair Programming을 위한 준비 사항’ »]]> 간만에 짝 프로그래밍(Pair Programming)을 해보고 있다. (이후부터는 그냥 페어 프로그래밍)

이 방법을 에자일과 XP 책들을 읽으면서 “아, 이런 방법도 있구나~” 하고 배웠다.  그러고 보면 이 시절에 페어 프로그래밍과 TDD를 포함해 새로운 지식들이 넘쳐나던 시절이었다.  어줍잖은 자신감으로 진행했던 프로젝트의 실패와 더불어 회사의 자금 사정 악화로 경제적으로 빈궁한 시절이었다. 하지만 실패를 곱씹는 과정에서 챙긴 지적 호기심은 이후에 참 많은 도움이 됐다.

사설이 길었지만 페어 프로그래밍을 실제로 시작한 건 네이버에서 일하기 시작한 이후다.  그것도 시작은 하다가 아예 공중 분해된 프로젝트를 진행할 때!!! (우연일지 필연일지 모르겠지만 망한 프로젝트에서 개인적으로 건져지는게 많은 듯…)  당시의 “나”라는 사람은 에자일(Agile)과 TDD라는 선진 문물에 신기해하면서 제대로 개발자의 궁색을 갖추는 중이었다.  아무래도 역량 부족.  페어의 정당한 짝꿍이라기에는 부족한 관전자일 수 밖에 없었다.  (이런 찌질함이었음에도 불구하고  라는게 참… )

그 시절 이후로 시간이 많이 지났다. 제대로 개발하기 위한 몇 년의 시간이 있었고 때아닌 질풍같은 시간이 휩쓸고 지난 이후 현재의 자리에 있게 됐다.  잘 하는건 아니지만 나름 백엔드 개발에 대해서는 나름 코딩을 할 수 있다는 생각도 있고.  ^^;

최근에 시작한 새로운 프로젝트가 있어서 함께 하는 친구와 페어로 진행하고 있다.  진행하면서 느낀 “제대로 하기 위해 이런 것들이 꼭 필요하겠구나?” 하는 생각이 들어 정리해본다.

1. 서로를 존중해야 한다.

한 컴퓨터를 가지고 두 사람이 붙어 작업하는 것을 페어의 원칙이다.  세상에는 동일한 인간이 존재할 수 없다.  일란성 쌍둥이라고 하더라도 인격은 다를 수 밖에 없다. 특히나 프로그래머들의 경우에는 자신만의 이고(Ego)를 가진 사람들이 흔하다. 그렇기 때문에 긱스(Geeks)들이 널리고 널린 분야다.

둘이 하는 작업이다. 서로 양보하지 않고 부디친다면 충돌은 피할 수 없다.  기술에 대한 논쟁의 충돌은 환영할만한 일이다. 그러나 말이 전도되어 감정적인 언어가 이야기 사이에 끼어들면 폭망한다.

특히나 대화를 매개로 한 두 사람의 공동 작업에 나이나 직위가 끼어들지 않도록 해야한다. 권위주의가 대화에 개입하면 제대로 된 말이 이뤄지지 못한다.

2. 적극적으로 대화를 한다.

같이 작업을 하는 친구가 부끄럼쟁이지만 술만 먹으면 이야기를 또 나름 하는 친구다.  물론 실력도 출중하다. 그래서 페어를 할 때 이야기를 많이 한다. 말빨에 관련해서는 나도 밀리지는 않는 사람이기 때문에 또한 이야기를 많이 한다.

코드가 생긴 모양새나 왜 이렇게 코딩을 해야하는지에 대해 이야기하는 그 시간은 개인적으로 행복한 시간이다. (되려 게임하는 것보다도 이 시간이 더 재미있는 것 같기도 하다.)  특히 어떤 방식의 코드의 구조가 좋은지, 잘 읽히는 코드를 작성하기 위한 서로의 생각을 이야기는 정말 좋다. 너가 옳다 내가 옳다 이야기를 많이 하지만 결론적으로 각자 방식에서 장점을 취한다.  애도 아닌데 뭐가 결국 올바른지 몇 마디 말을 주고 받다보면 자연스럽게 알게 된다.  이런식의 대화가 길어지다보면 결국 쌓이는 건 지식이다.

3. 대등한 기량이면 더욱 좋다.

개발 능력이 되도록이면 비슷한 편이 좀 더 페어를 하기에 이점이 있다는게 개인적인 생각이다. 이전에 주니어 친구와 페어를 해봤다. 하지만 페어가 아니라 한 사람은 훈계를 하고 있고, 한 사람은 그 이야기를 주눅든 상태로 듣고 있었다. 아무래도 성질이 드러웠던 모양이다. -_-;;  이 시간이 물론 의미가 없는 건 아니다.  그렇다고 “두 사람 모두에게 발전적인 시간이었냐?” 라는 질문에는 “글쎄???” 라는 답변이 나올 것이다.

페어 프로그래밍도 일하는 방법 가운데 하나이다. 일을 하는 누구라도 일이 생산적이길 희망한다.  앞서 이야기한 것처럼 페어 과정의 토론은 서로의 성장에 큰 도움이 된다.  하지만 이것이 어느 일방의 가르침이라면 어떨까?  가르침을 받는 입장에서는 1:1 과외를 받는 특전일 수 있다.  일방적인 강의를 대학때에도 많이 들었다. 하지만 금방 잊혀지더라는 것이 개인적인 진리라고 본다.

4. 코드는 돌아가면서 작성한다.

내가 작성하는 코드를 누가 옆에서 혹은 뒤에서 쳐다보는 경험은 해보지 않은 사람에게는 매우 낯선 광경이다.  하지만 관찰 대상의 입장과 관찰자의 입장에서 이 광경은 모두 흥미롭다.  관찰 대상의 관점에서 본다면 코드 작성 과정과 툴 사용 과정들을 보여줘야한다.  그만큼 숙달된 조교의 솜씨를 강제한다. 관찰자의 관점에서 역시 다른 사람의 코딩하는경쾌한 키보드 소리를 듣거나 겁내 빠른 툴 사용을 위한 단축키 신공을 눈으로 볼 수 있다.

서로가 보여주고 보는 과정은 코드를 작성하는 본인의 자세를 그대로 까발린다.  얼마나 직관적으로 코드를 작성해나가는지? 술술술 코드를 적어나가는지를 볼 수 있다.  물론 이 과정에서 본인의 코딩 습관도 방청객에게 생얼굴로 보여준다.

관찰자는 민낯에서 얻는 것이 많다.  내가 작성하는 코드 대비 어떤 방식으로 다른 친구는 코드를 작성하는지 혹은 코딩 스타일은 어떤지를 배울 수 있다.  따라서 누구 하나가 독점적으로 키보드를 독차지하는 건 불합리하다.  종종 의자에 붙히는 엉덩이의 주인을 바꾸자.

5. 표준을 정하고 지킨다.

개발자는 코드를 작성한다. 하지만 인간인 이상 개성이 있고, 그 개성이 코드에 묻어나기 마련이다.  지금 작업하는 친구와 의미있는 페어를 하지만 이후에는 다른 친구와도 이런 의미있는 시간을 가져야 한다.  다른 친구의 만남에서 어떻게 상호 절충을 해야할까?  그리고 이런 상호 절충을 계속해야 하는 건가?

이것보다는 “표준안“이라는게 있는게 좋다. 왜 공통의 표준안을 따라야 하는가?  배려심이다.  자신이 작성한 코드를 다른 사람이 편안하게 읽을 수 있도록 혹은 다른 친구가 편안하게 수정할 수 있도록 맞춰주면 정말 좋아하지 않을까?

다른 이야기지만 내부 공유 시간에 나온 JS Framework에 대한 코딩 컨벤션을 무조건 체크하기 위해 lint를 사용했고, 하자는 의견이 있었다.  좋은 움직임이고 자바에 대해서도 이런 툴을 적용해보기로 했다.  표준안이 없다면 정립된 Defacto를 따르고, 그걸 팀의 현실에 맞춰 조정해나가는게 좋지 않을까 싶다.

6. 시간을 맞춘다(혹은 정한다)

이번 페어를 하면서 같이 하는 친구에게 미안한 점은 함께 진행할 수 있는 시간이 길지 않다는 것이다.  상대적으로 참석해야할 미팅이 많다보니 하루에 길게 진행하더라도 2시간 이상은 진행이 어려웠던 것 같다.  서로 시간을 할애해주지 않는건 내가 저지른 실수이긴 하지만 민폐다.

제대로 한다면 하루에 2시간 정도의 시간을 정해두고 페어를 하는게 좋다고 생각한다. 페어를 통해 공통적으로 해야할 일들, 예를 들어 핵심적인 내부 구조를 잡는다던지 서로 알고 있어야 할 업무 로직을 작성해야하는 일을 함께 하는게 좋다. 그리고 이외의 시간에 각자 작업한 부분을 코드 작성하고 이후에 각자 리뷰하면 일도 나름 효과적으로 할 수 있지 않을까 생각한다.

여기까지 정리해봤다. 아마도 가장 중요한 건 “서로에 대한 존중과 이해“일 것이다.  만약 이걸 갖추고 있지 않으면 절대로 페어를 하지 않는게 좋다.  무시하고 시기하고 결국에는 쌈난다.  본인이 다른 사람을 존중할 줄 안다면 그럼 바로 페어를 해봐라.  존중과 이해 다음에 본인이 갖춰야 할 점이 바로 “실행“이다.

오늘 하루도 좋은 일이 있으시길~~~~

Continue reading ‘개발자의 missing commitments에 대해.’ »]]> 한다고 한것들(commitments)을 못했을 때(missing)의 것들을 어떻게 받아들여야 할지 애매해서 좀 찾아봤는데 재미있는 링크를 찾았다.

Agile team missing commitments regularly and complaining about no trust

어떻게 보면 개발자들이 똘똘 뭉쳐서 에자일이라는 것을 해석해버리면 이런 식도 될 수 있겠구나 하는 생각도 든다.

질문의 요지는 스프린트 4개를 하는 동안 개발자들이 40~60% 정도를 빵구를 내고 있다. 하지만 MVP를 만들어낼때까지 4개의 스프린트가 남았음에도 불구하고 개발자들은 현재 상황에 대해 안이하다.  개발자들은 스토리가 거의 완성됐고 좀만 더 하면 된다고 이야기를 한다. 하지만 스토리는 완성되지 않았기 때문에 결국 스토리 완성은 다음 스프린트로 연장됐다. 따라서 계속 MVP에서 보여줘야 할 내용들은 줄어들 수 밖에는 없다. 스펙을 짤라야 하기 때문에.

럼 가장 많은 Vote를 받은 답변의 요지를 정리해본다. 답변에서는 3개의 Noop을 이야기한다.

4개 스프린트에서 스토리는 어느 정도(40 ~ 60%) 진행이 된거다.

하다만 스토리는 완성되지 않은 스토리다. 따라서 진행율은 0%다.  

스토리를 임의대로 자르고 붙혀서 이만큼 했다라고 이야기하는 것 자체가 작위적이다.  스토리를 정할 때 우리는 완결성을 부여한다.  “주어진 조건 아레서 어떤어떤 방식으로 동작해야하고 그 기능은 이렇게 검증한다” 라고 스토리를 써내려간다. 그런데 조건을 맘대로 변경하고, 동작을 변경하고, 검증 방식을 임의대로 자르고 붙혀서 우리는 잘 하고 있어.. 라고 이야기하는건 옳지 않다.  특히 정직할 수 밖에 없는 기계를 대상으로 작업하는 개발자가 이런 기계적이지도 못한 자세를 보인다는건 극히 잘못된 거다.

일은 거의 다 되어간다.

완결되지 않은 일은 백로그에 있는 다른 일들과 동급이다.  다만 다음 스프린트에서 높은 우선 순위를 가질 뿐

에자일 개발에서 스프린트는 백로그에 있는 것들 가운데서 이번 스프린트에서 해야할 일들을 뽑아서 진행해야한다.  지난 스프린트에서 다 못한 일들을 스프린트에 스프린트를 걸치게 하면서 개발하는건 제대로 된 에자일 프로세스가 아니다.  따라서 완결하지 못했다면 해당 스프린트에서 한 일은 없는 것이다. 단정적인 표현이지만 이것이 맞는 이야기다.  만약 이 규칙을 지키지 않는다면 에자일을 하는게 아니다.

에자일 개발 프로세스에서 스프린트는 중요한 의미를 갖는다.  한 스프린트는 집중해서 처리할 일들을 집중해서 처리하자는 암묵적 규칙 아래서 운영된다.  따라서 이 스프린트에 진행할 일들을 선정했다면 개발팀은 온전히 그 일에 집중해야 한다.  스프린트를 진행중인데 다른 일들이 급하다고 치고 들어온다면?  원칙에 따르면 “이게 급해요!!” 라고 치고 들어온 일들은 당연히 하면 안된다. 온전히 백로그에 잘 모셔둬야 한다. 스프린트에 집중헤야 할 일에 집중하는 것.  그것이 에자일에서 강조하는 스프린트의 운영 규칙이다.

누구나 한번쯤 응급실에 가본 경험이 있을 것이다. 다른 사람의 아픔보다는 자신의 아픔을 의사가 간호사가 먼저 돌봐주어야 한다고 우긴다.  고함 소리도 들리고 왜 의사가 오지  않는지 깽판을 치기도 한다.  하지만 의사는 자신의 우선 순위에 따라 움직이고 또 그래야만 한다.  같은 공간에 있지만 이미 치료를 시작한 환자가 있다면 그 환자의 치료가 끝날때까지 기다려야 한다.  당신이 죽을 정도라면 아마 응급실에 들어오자마자 의사가 바로 당신에게 달려들 것이다.

스프린트의 운영 역시 이와 유사한 측면이 있다. 스프린트를 통해 진행하기로 결정된 사항들에 대해 개발팀(응급실의 의사)는 이해 관계자들의 이해를 바란다. 이해 관계자들 역시 자신의 고통을 백로그에 담아두면서 기다림의 시간을 갖는다.  따라서 스프린트를 진행하는 개발자들은 해야할 일을 스토리를 통해 명확하게 정의해야 한다. 그리고 그 일의 완성을 위해 최선을 노력을 해야한다. 시간을 가지고 장난질을 하면 안된다.

이유가 뭐냐고 물어보면 개발팀을 못믿는거냐고 되려 받아친다.

서로 니 잘못이니 내 잘못이니 따지면 폭망이다. 왜 이렇게 예측(Planning)이 개판인지 물어보는게 바람직하다.

서로 잘잘못을 따지는 전투 행위로 들어가면 남는 건 상처밖에 없다.  상호 신뢰는 모든 일의 근간이다. 맞던 틀리던 험단과 힐란이 난무하면 신뢰는 무너진다. 결국에는 폭망에 이른다. 일을 시작했다면 되게 해야한다. 비난보다는 건설적인 견지에서 현상을 살펴볼 필요가 있다.  이 문제의 건설적인 관점은 왜 스토리가 스프린트에 완성되지 않는지를 따져보는 것이다. 특히 한번이 아닌 4번이나 제대로 스토리를 완성시키지 못했다는 사실에 집중해야 한다.

반복적으로 스프린트의 스토리를 완결하지 못했다는 것은 백로그에 존재하는 스토리의 규모를 제대로 예상하지 못한다는 것이다. 전후 관계가 명확한 스토리가 이런 꼬라지를 보인다면 더욱 더 개발 기간의 예측이 올바르지 못하다는 것을 뜻한다.   이 사실에 개발팀 공감해야 한다. 이 공감을 바탕으로 제대로 된 플래닝을 하기 위해 필요한 것이 뭔지를 고민해야 한다. 예를 들어 새로운 데이터베이스를 사용하기 때문에 혹은 새로운 언어를 사용해야 하기 때문일 수도 있다.  그렇다면 해당 분야의 고수를 초빙해서 플래닝에 도움을 요청하는 것도 좋은 대안이 될 수 있다.  만약 조직의 프로세스 혹은 권한 등이 문제라면 이를 잘 아는 주요 인사를 플래닝에 함께 참석시켜 예측을 해보는 것도 다른 방편이 될 수 있다.

가장 중요한 점은 최선을 다한 결과임에도 불구하고 동일한 문제가 반복적으로 들어난다면 열린 마음으로 이를 직시해야 하는 것이다. “믿고 맡겨주세요”와 같은 허왕된 문구는 정치인들이나 하난 말장난이다.  프로페셔널의 세계에서 문제는 객곽적인 사실로 보고 판단해야 한다. 그리고 그 안에서 개선할 부분이 있다면 인정하고 고쳐나가면 된다.

누구도 실수를 할 수 있다. 하지만 두번 실수를 하지 않는 것이 바로 프로다.