쏘카 사무실 공간의 특별한 요소는 벽을 가득 채운 화이트보드다. 빈 공간의 대부분이 화이트보드다. 처음 이 공간을 접했던 때의 느낌은?
멋지다!!!!!!!
이 공간이 더욱 멋진 이유는 단순히 장식용 화이트보드가 아니라 보드를 가득 채우고 있던 고민의 흔적들이었다. 난무하는 선, 도형, 숫자, 등등. 그래서 더욱 Cool! 했던 것 같다.
요즘 흔하게 보고 있는 일하는 모습이다. 짧게 혹은 길게 이야기를 나눈다. 그림 그려가며 설명도 하고 토론도 하고 경청(?)도 한다. 회의실이 아니니 예약할 필요도 없다. 먼저 찜하는 사람이 임자다. 커피들고 지나가다 내려놓고 이야기를 할 수도 있다. 특히 이 복도 공간은 요즘 핫하다.
열린 공간이기 때문에 소리의 제약이 있고, 복도이기 때문에 지나가는 사람들이 수시로 있다. 누군가에게 들려도 개의치 않고, 누군가에게 보여도 개의치 않는다. 함께 논의하고 의견을 나누는 모습이 일상화 되어 좋다. 덕분에 지나가다 툭툭 대화에 끼어들기도 한다. 민폐같기도?
물론 다름을 원하는 구성원분들도 있을 수 있다. 소음이고 본인 집중을 방해하는 이유가 되기 때문이다. 통행 방해는 물론이다. 그럼에도 이해와 배려하는 마음이 있어 아직 큰 불만이 표출된 적은 없다. (굳이 찾아보지는 않았지만… 없을 것 같다.)
엔데믹, 재택 종료와 사무실 출근
4월부터 재택 종료하고 사무실을 주 업무 공간으로 사용하기 시작했다. 온라인 공간에서 주로 소통하는 “우리”가 사무실(Office)라는 오프라인 공간에서 어떤 소통 방식을 찾을지 궁금했다. 그 방식은 지시에 의해 만들어지는 것이 아니라 구성원 스스로 찾아내고 자연스런 일상이 모습이어야 한다. 하라고 해서 되는게 아니다.
요즘 느낌은 사무실이라는 공간에서 어떻게 소통할지 나름의 방법을 스스로 찾아가고 정착되는 것 같다. 공간이 풍요로운 것도 아니고, 급한 회의 진행을 위해 양해(양보)를 구하는 슬랙 메시지도 종종 본다. 그럼에도 소통하기 위한 방법과 현실에 대한 배려를 보여주는 모습이 고맙다.
팀 자리에서 의자 돌려 스크럼 진행하고, 옆 팀에서 들리는 목소리에 개의치 않는다. 회의실 밖에까지 들리던 목소리가 팀 자리에서는 조곤조곤해진다. 물론 헤드셋을 하고 배경 음악을 깔고 있는 시간이 늘어나는 건 어쩔 수 없다. 사무실에서 이어폰은 여러모로 감수해야 한다. 그리고 이것 역시 다른 동료를 위한 배려라는 생각이 든다.
사무실에서 짧은 이야기가 많다. 커피를 내리면서 서울숲의 단풍과 갑자기 추워진 날씨 이야기를 나눈다. 속썩이던 고3 아이가 무사히 수능 치뤘는지도 나눈다. 면접 이야기, 여행 이야기, 어제 술자리 이야기 등등. 사무실이라는 공간에서 이뤄지는 많은, 짧은 이야기를 통해 우리는(적어도 나는 ^^;) 동료들을 알게 되고 이해할 수 있게 된다.
일하는 공간 변화를 통해 얻고자 했던 부분은 “소통과 협업“이었다. 그리고 구성원들이 쏘카의 일하는 방식을 자율적으로 만들어가고 있다. 일하는 문화의 방향을 리더가 제시할 수 있어도 결국 문화 자체를 완성하는 몫은 구성원 스스로에게 있다. 그 관점에서 정말 구성원 분들이 대단하다고 생각되고 감사하고 고맙다.
2분기는 짧은 기간에 많은 일을 해내야만 했다. 늦은 밤은 물론이고, 주말까지 일을 해서 완성시켰다. 많은 일들이 완성된 건 구성원들의 공감, 집중, 헌신이 있었기 때문이다. 야근과 주말 특근 없이 일하는 쏘카의 모습이 좋았고, 나 스스로 유지하기 위해 노력했지만 이번에는 그 반대 방식으로 일해야 한다고 내가 이야기했다.
희생한 개인 시간에 일부 보상을 더해 대체 휴가를 부여하기로 전사 방침을 정했다. 대신 본부 구성원들에게 이번 부여된 대체 휴가는 8월 , 늦어도 9월까지는 모두 소진시켜달라고 팀장들에게 당부했다. 그리고 3분기 시작 직전에 주말 특근을 허용하지 않는다는 공지를 했다. 물론 이는 내가 담당하는 SE(Service Engineering) 본부만의 방침으로 쏘카의 모든 조직에 해당 하지는 않는다. 당연히 냉탕과 온탕을 오가는 조직장의 태도 변화를 구성원들이 곱게 받아들일리 없었다.
하반기가 되었다고 일의 양이 줄지는 않는다. 우리가 만드는 건 서비스다. 이동 플랫폼으로써 제대로 된 발걸음을 막 시작했기 때문에 새로운 시도와 확장은 당연하다. 플랫폼을 만들고 이를 유지할려면 쏘카 나름의 일하는 방식이 있어야 한다. 서비스를 빠르게 만든 2분기의 경험은 개인과 조직에게 그동안 쌓아온 역량의 최대치가 얼마인지 확인할 수 있는 기회였다. 그리고 쏘카라는 조직 관점에서 우리가 얼마나 해낼 수 있을지 그 속도를 가늠해 볼 수 있었다. “함께 리듬감있게 일하자!“라는 일하는 방식이 나온 배경이다.
리듬을 갖기 위해서는 레파토리(Repertoire)가 필요하고, 레파토리를 완성하기 위해서는 필연적으로 쉼(Break)이 필요하다. 리듬감있게 일한다는 관점에서 우리는 쉼을 먼 곳에서 찾을 필요가 없다. 나의 쉼은 가족과 함께 쉬는 것이어야 하고 일의 관점에서 동료의 쉼이어야 한다. 그 가운데 특히 주말 시간은 업무(일)과 분리된 시간이 되어야 한다.
숙련도는 쉽게 말해 일을 다루는 요령이다. 일에 진심이라면 요령은 효율성이고 시간 활용 능력이다. 시간을 잘 활용하기 위해서는 나에게 주어진 시간의 총량을 염두에 둬야 한다. 일반적으로 하루 8시간, 주간 5일이 물리적인 총량이다.
총량을 넘어 추가 시간이 필요한 경우 야근 혹은 특근을 한다. 나는 이를 “빌려”쓰는 시간이라고 생각한다. 지금의 내가 필요한 시간을 미래의 나에게서 빌리는 것이다. 내일 업무를 위해 충전할 시간을 당장의 업무에 쓰면 내일의 내가 피해를 본다. 패턴이 반복되면 피로는 누적되고 일에 대한 집중은 기대할 수 없다. 실수를 포함해 업무 품질을 이야기하기 어려워지기 마련이다.
쏘카의 이동 서비스 확장과 고도화 의지를 생각하면 시간이 부족하다. 일이 되게 만들려면 부족한 시간을 빌려야 한다. 주말 특근을 허용하지 않는다는 선언은 빌리는 시간을 주중으로 한정한다는 것이다. 돌려말하지 않고, 시간이 더 필요하면 야근하라는 것이다.
일에 아무리 좋은 미사여구를 붙혀도 일은 일이다. 일에 최선을 다했다면 야근을 했던 안했던 피곤은 피할 수 없다. 누적된 피로를 그나마 회복할 수 있는 주말과 휴일마저 매몰시키고 싶은 생각이 없다. 나 스스로도 일을 떠나 잡초를 뽑거나 낚시하면서 머리를 비운다. 못읽은 책을 읽으면서 몇 년 후 내 모습은 어떤 모습일까를 그려보기도 한다. 그리고 다시 시작하는 일상에서 업무에 집중하고 결과를 만든다. 추상적 리듬이 아닌 물리적 리듬이 여기에 있다. 이 리듬이 깨지면 몸이 망가지기 십상이다.
주변에서 몰입(flow)라는 단어가 심심치 않게 들린다. 특히 시간 총량을 넘어선 일을 하고 있거나 해야할 때! 우리는 풀리지 않는 문제를 풀기 위해서 무작정 잡고 있는 것을 몰입이라고 하지 않는다. 문제를 풀다보니 자기도 모르는 사이에 시간이 흘렀을 때를 “몰입의 시간“이라고 부른다. 그리고 이 몰입의 시간은 재미의 시간이다. 이 경험 자체가 즐겁고 재미있다. 이 재미에 누군가가 보상을 이야기하면 그 다음부터는 노동이 된다. 업무로써 몰입할 수 있는 기회를 가지는게 최선이다. 항상 이럴 수 없기 때문에 시간 관리가 필요하다. 그래서 시간의 흐름을 맺고 끊는 방법을 알아야 한다.
개인의 인생이라는 긴 여정에서 시간은 무엇보다도 중요하다. 특히 직업(Career)의 범주에서 전문가의 첫 걸음은 시간을 효율적으로 사용하는 것이다. 본인에게 주어진 24시간은 개인의 (역량을 키우는) 시간이고, 그 가운데 8시간은 일을 통해 역량을 실현시키는 시간이다. 그리고 쉼은 전진하기 위한 윤활유 역할이다. 윤활유없이 달리는 엔진은 터지기 마련이고, 우리는 이걸 번아웃이라고 부른다.
인생은 길지만 시간은 유한하다. 몰입이라는 단어에 현혹되지 말았으면 한다. 쉼을 통해 계획하고 실행하는 방안을 통해 점진적으로 성장하는 모습을 스스로 찾는 것이 개인도, 조직에도 가장 유효하다고 본다.
특근 승인을 하지 않는다고 선언한 이후에도 종종 주말에도 일의 시간을 위해 개인의 시간을 희생하는 구성원분들이 있는 것을 알고 있다. 이상이 아무리 고귀해도 현실을 무시하면 완전 헛소리에 지나지 않는다는 것도 알고 있다. 딜레마다. 그럼에도 불구하고 이를 정책(Policy)로 유지하는 이유는 분명하다. 일과 쉼이 뒤섞이면 결국 조직의 지속 가능성은 구성원의 자발적/비자발적 이탈로 유지될 수 없다고 생각하기 때문이다. 번아웃이라는 단어가 급부상한 이유가 있다.
상반기의 업무 방식이 과감하게 도전하기(Be Bold)라면, 하반기의 일하는 방식은 “함께 리듬감있게 일하기“로 이야기하고 있다. 상반기엔 구성원 모두가 정말 과감하게 도전했고 기대 이상의 성과들을 만들었다. 말이 쉽지 개개인의 희생과 노력없이 도전은 이뤄질 수 없다. 그만큼 피로가 쌓일 수 밖에 없기에, 이 방식은 지속 가능한 업무 형태로 적합하지 않다. 이에 대한 고민을 아래와 같은 방식으로 정리해봤다.
리듬감있게 일하기
한번에 되는 일은 없다!
되풀이하지 않기
현실은 멀티플(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.
국방, 안전, 항공, 우주 관련 프로젝트의 경우는 절차적 단계에 따른 제품 개발이 꼭 필요하다고 생각한다. 부실한 정보를 토대로 원전 운영 소프트웨어를 작성했다는 사실을 알게 되면… 끔찍하다. 해본 적은 없지만, 이런 고난이도 개발을 해볼 기회가 있었으면 하는 생각도 든다.
쏘카에는 피어보너스(Peer Bonus)라는 제도가 있다. 동료가 동료를 칭찬해주고 작은 금액을 보너스로 지급해주는 제도로 작은 칭찬이지만 구성원 사이의 인정을 통해 기여와 발전을 도모하기 위해 운영된 제도이다.
지난 주에 본부 구성원 한분이 피어보너스를 받았다. 전기차량 충전 잔량이 부족한 경우 다음 고객분의 예약 전에 충전하는 자동화 프로세스를 개발했고, 그동안 수작업으로 이뤄지던 업무량의 77%를 자동화 처리했다. 덕분에 고객은 전기차량을 예약했을 때 충전 걱정없이 바로 차량을 이용할 수 있게 됐고, 운영 부서는 이 부분에 신경쓰는 시간을 줄일 수 있었다. 사실 이렇게 보면 이 작업이 큰 의미를 갖는 작업일까 싶은 생각을 할지도 모르겠다.
사실 이 과제는 담당 업무를 수행했던 주니어 분들의 온보딩 과정 중 하나의 Dogfooding 프로젝트였다. 신입으로써 온전히 쏘카의 환경을 이해하고, 이 프로젝트를 마무리한다는 건 사실상 불가능에 가깝다. 그리고 제한된 기간으로 인해 대부분의 Dogfooding 프로젝트 기간에 라이브까지 이뤄지지 못하고, 실제 Dogfooding 프로젝트들이 관련 업무 팀으로 이관되어 마무리가 된다. 물론 해당 프로젝트를 담당했던 팀원 가운데 한분 정도가 대부분 해당 팀으로 배정된다.
이 프로젝트의 경우도 Dogfooding 과정에서 얼추 얼개가 맞춰진 다음 신입분과 함께 담당 팀으로 이관되었다. 하지만… 해당 팀은 쏘카내에서 카셰어링을 담당하는 팀이었고, 업무량 폭주에 Legacy의 한복판에서 맹활약하는 팀이었다. 그리고 단순히 전기차의 충전량만 검토해야 하는게 아니라 예약의 전후 관계 맥락을 제대로 풀어야 이를 라이브 할 수 있다는 것도 팀에 배정된 이후에야 주니어 개발자분이 파악할 수 있지 않았을까?
중요한건 꺽이지 않는 마음
팀 배정 이후로 해당 팀의 개발 항목에 이 항목이 있었다. 이야기했던 것처럼 쉽게 마무리가 될 수 없는 환경이었다. 주니어분이 짧은 시간에 이해도를 높일 수 있을만큼 카셰어링 환경이 만만치 않았고, 문제가 있었지만 그럼에도 운영되던 기존 시스템도 있었다. 아주 긴 시간동안 백로그가 아닌 실제 개발 진행 항목으로 계속 리스팅되고 있었다. 그리고 이번 여름에 정식으로 출시되었다.
사실 이 프로젝트는 포기할 수도 있었다. 주목도가 있는 프로젝트가 아니고, 한 사람이 너무 한 일에 매여있는 부분도 팀 운영에 부담이 되기 때문이다. 그럼에도 불구하고 Dogfooding 프로젝트부터 해왔던 담당자가 일을 마무리 짓고 싶어했고, 팀의 TL은 그 기회를 통해 주니어가 환경에 대한 이해를 통해 성장하길 바랬던 것 같다. 포기할 수도, 포기하게 만들 수도 있었다. 그럼에도 불구하고 완결성있게 마무리하고 싶은 마음이 있어서 끝냈다고 생각한다. 그리고 동료의 기분좋은 피드백이라는 좋은 결과를 만들었다.
일을 하는 동기란 무엇일까? 여러 좋은 꺼리들을 많이 이야기할 수 있겠지만, 일을 끝내겠다는 마음, 그리고 이를 지지하고 응원해주는 동료들의 존재만으로도 일에 대한 좋은 동기가 될 수 있지 않을까 싶다.
Annotates a program element that exists, or is more widely visible than otherwise necessary, only for use in test code.Do not use this interface for public or protected declarations: it is a fig leaf for bad design, and it does not prevent anyone from using the declaration—and experience has shown that they will. If the method breaks the encapsulation of its class, then its internal representation will be hard to change. Instead, use RestrictedApiChecker, which enforces fine-grained visibility policies.
Author:
Johannes Henkel
대강 내용을 보니 private method를 테스트 코드에서 참조할 수 있게 해준다.!!! 오 이런 신박한게 있었네. 자바 코드를 짤 때는 저런게 없었던 것 같은데. 나도 쓰는 것에 무던히도 안주했던 모양이다. ㅠㅠ;; 다시 코드짜러 돌아갈 시점에는 보충 공부를 꼭 해야만 적응할 수 있을 것 같다. (읽을 줄 아는걸 짤줄 아는 것으로 이야기하지 말아야겠다라는 생각도 ㅎㅎ)
당연히 해당 Annotation이 적용된 private method에 대해 테스트가 잘 적용되어 있었다. 그런데 이 구조를 보다보니 굳이 이 Annotation을 사용해야 했을까 싶은 생각이 들었다.
단상 1. 주목받으니 더 주목받게 하자!
해당 Method를 별도의 상세한 테스트 코드를 작성할만큼 주목도가 있다면 해당 로직을 method 수준으로 두는게 맞을까? 주목할만한 역할이 있다면 이를 별도의 객체(클래스)로 분리해서 관리하는게 맞지 않을까?
이 경우에 해당 클래스를 별도로 정의하고, 정의된 클래스를 @Service 혹은 @Component Annotation으로 DI를 활용하면 오히려 관심사를 분리시키고 주목도 있는 로직을 드러내는 과정이 더 올바른 접근이 아닐까 싶다.
단상 2. 굳이?
아무리 테스트라고 하더라도 Private method를 노출하는게 맞을까? Private method는 언제든 변경될 수 있는 자유도가 있어야 한다. 그런데 private method를 아무리 테스트라고 하지만 외부에 노출한다면 이 후에 변경할 때 이를 신경써야 한다. 물론 IDE가 지원해주는 refactoring 기능을 쓰면 된다고 이야기할 수 있다. 그럼에도 PR을 날리면 상당히 덩치 큰 변경점이 생긴다. PR Reviewer 입장에서 두루 살펴야 하는데 읽는데 방해가 되는 건 분명하다.
Private method에 있는 코드(로직)을 테스트할 필요가 있다면 이를 이용하는 Public method의 호출 조건을 조정해서 테스트 커버리지(Coverage)를 가져가는게 맞지 않을까? 만약 호출 조건으로 커버리지 달성이 어렵다면 전반적인 코드 구조를 다시 한번 돌아볼 기회도 될 수 있을 것이다.
단상 3. 그럼에도 불구하고!
개인적으로 이걸 쓰는 걸 추천할 만한 상황은 Public 대상을 테스트가 통합 테스트(Integration Test) 수준의 테스트 비용이 발생하는 경우다. 테스트 대상 코드에 주의할 점을 명확하게 하고 싶은데, Public 대상을 테스트할려고 할 때 1~3초가 수행된다면? 이런 상황에서 특정 상황에 대한 테스트를 추가하는 건 시간이라는 과한 비용을 수반한다.
테스트 코드를 작성하는 기본이 된 개발자
이러나 저러나 테스트를 작성하겠다는 개발자의 자세는 훌륭하다.
다만 전체 테스트들은 5분 이내로 완료될 수 있어야 한다. 단위 테스트와 통합 테스트를 모두 포함해서. 특히나 통합 테스트는 배포할 코드가 안전함을 개발자 관점에서 보장하기 위해 수행되야 한다. 떄문에 반드시 CI 과정에서 필수적으로 수행되어야 한다. 그런데 이 단계에서 십수분이 소요되면 안된다.
커피한잔하고 왔는데도, 밥먹고 왔는데도 끝나지 않은 CI를, 특히 통합 테스트가 여전히 돌고 있는 걸 경험하면 정말 테스트 코드 관리를 잘 해야 한다.
기술 기업의 핵심은 뭘까? 쏘카에 합류하면서 받은 요청 사항을 관통하는 단어가 “기술 기업”이었다. 사실 그전에는 기술 기업(Tech Company)이라는 단어는 기업을 포장하기 위한 미사 여구라고 생각했다.
쏘카를 기술 기업으로 만들어달라는 이야기를 들었을 때 의아했다. 자동차를 기반한 서비스이지만 온라인으로 비대면 서비스를 십년 가까이 제공하고 있으니 이미 기술로 사업을 진행하는 “기술 기업” 아닌가? 시장에서 기술 기업이라고 스스로 부르는 회사들 역시 많은 트래픽과 소위 최신의 혹해보이는(Fancy한) 기술들을 사용하는 것으로 그 이름을 정당화하고 있다고 생각했다. 그리고 2023년 현재 한국의 많은 기술 기업들을 바라보는 내 시선에는 큰 변화가 없다. 안타까운 지점이기도 하다.
기술 기업이란 뭘까?
나는 두 단어 자체에 이미 정의가 있다고 생각한다. 기술을 기반으로 사업을 만들어가는 기업. 어렵게 생각할건 없다.
하지만 일반인들은 다른 시각을 가지고 있는 것 같다. 대부분 전통적인 기업들(소위 굴뚝산업)을 기술 기업을 여기지 않는다. 실리콘벨리 Big Tech 기업들의 영향인지 인터넷, 유형보다는 무형의 자산(주로 Contents), 언제든 접근할 수 있는 서비스, 세상에 없던 개념 등등을 기술 기업의 조건으로 생각하는 듯 하다. 기술보다는 투자에 관심이 있기 때문이지 않을까?
나는 기술 기반의 사업을 진행하는 회사가 “기술 기업”이라고 정의한다. 나도 실리콘벨리를 빌려 한발짝 더 나아가면 기술을 통해 실현한 가치가 세상을 변화시키고 기여할지, 스스로 메시지를 명확히 가지고 있는 회사라면 내가 생각하는 확실한 기술 기업이다.
서비스를 만드는 책임자로써 나는 기술에 주목한다. 세상을 변화시키는 사업, 그리고 이걸 실체화시킬 기술이 필요하다. 때로 혁신적인 기술을 발명해내야 할 때도 있고, 존재하는 여러 기술들의 최적의 조합을 필요하기도 하다. 최종적으로 기술들이 서비스와 제품의 형태로 완성되어 고객들에게 전달되어야 사업이 진행될 수 있다.
질문해보자. 그럼 이 기술을 발명과 조합은 어떻게 이뤄지나? 결국 사람이 하는 일이다. 아이러니하게 기술 기업을 움직이는 핵심 역시 사람이다. 고 이건희 회장이 “천재 한명이 10만명을 먹여 살린다.”라는 어록을 남겼다. 당연히 인재는 분야를 막론하고 중요하다.
10만명을 먹여 살리려면 서비스, 제품을 만들어야 한다. 그리고 세상을 대상으로 팔 수 있는 물건을 만들어야 한다. 장인(Craftman)이 홀로 대장간에서 뚝딱뚝딱 만들어서는 안된다. 아이언맨처럼 자비스의 도움을 받아 혼자 멋진 슈트를 만드는 시대는 안타깝게도 영화속에만 존재한다.
사람이 핵심이다.
물건은 사람이 만들고 혼자서는 만들지 못한다. 결국에는 사람들, 즉 팀이다. 그리고 그 팀들이 조화된 곳이 회사라는 조직이 된다.
인재가 있어야 함은 물론이다. 그리고 그 인재들이 조화되는 팀이 있어야 한다. 그 팀이 회사가 변화시킬 세상에 대한 미션을 수행한다.
이 구조에서 나는 팀의 조화가 미션 수행에 가장 큰 역할을 수행한다고 믿는다. 팀의 성과(Performance)는 결국 팀을 구성하는 개개인들이 얼마나 기대되는 혹은 기여하는 일을 수행하는냐에 따라 달렸고, 이걸 “조화로움“이라고 생각한다.
기술적인 난제를 푸는 일을 할 수도 있고, 복잡도는 떨어지지만 귀찮은 일을 해야 할 수도 있다. 이런 일 저런 일, 모두 팀에게 주어진 일이다. 팀 안에서 이 일들을 모두 해결해야 하고, 가능한 최대한 성과와 효율이 높은 방향으로 일을 나누고 도와야 한다.
혹자는 개인별 역량에 따라 할 일이 달라야 한다고 이야기한다. 개인의 역량에 따라 차별하게 되면 일에 대한 쏠림이 발생한다. 대부분의 사람들이 “저는 이 일을 하고 싶습니다.”라는 말을 할 것이다. 누구나 보기 좋은, 인정받을 수 있는 일을 원하지 역량과 무관한 일하기를 원치 않을 것이다. 화장실 바닥에 떨어진 휴지를 줍는 일은 청소부의 몫이지 나와 관련 없다는 생각이 만연하게 된다. 자연스럽게 깨진 창문 이론을 팀이 맞닥들인다.
조화로운 팀이 되기 위해서는 팀 리드의 역할이 가장 중요하다. 사람의 근본 특성인 이기주의를 넘어선 이타성을 팀원들이 보여주도록 만들어야 하기 때문이다. 이 과정에서 어려운 대화는 필수다. 팀을 위해 개인의 헌신(희생이 더 적절할지도)을 부탁해야 하기 때문이다. 팀 플레이에서 가장 중요한 것은 팀의 성과이고, 팀원은 이를 위해 움직일 준비가 되어 있어야 한다. 그리고 팀 리드는 필드 코치로써 직접 보여줄 부분은 보여주고, 팀의 성과를 위해 지시할 사항은 지시해야 한다.
아버지 뭐하시노?
팀원의 헌신이 헌신으로 잘 동작할려면 불합리하지 않아야 한다. 팀 리드가 권한을 앞세워 일방적인 희생을 강요하는 경우가 한국 조직 사회에서는 비일비재하다. 이런 불합리한 상황에 대해 저항할 수 있어야 하지만… 저항은 거의 불가능하기에 이런 상황 자체가 만들어지지 않도록 해야 한다.
불합리한 상황을 최소화하기 위해서는 사람을 알아야 한다. 리드는 구성원을 알아야 하고 마찬가지로 구성원 역시 리드를 알아야 한다. 우리는 기계와 일하는게 아니라 사람과 일을 한다. 업무 역량이 “사람”으로써 팀원/팀장의 모든 것이라고 생각하는가? 아무리 좋은 역량을 가졌다한들 아이가 아프고, 집에 어려운 일이 있는데 당장 일이 손에 잡힐까? 그리고 이런 사람 붙들고 왜 일이 그전만 못하느냐라는 이야기를 해봐야 의미없다. 되려 그런 말을 하는 사람이 원망스러울 뿐.
“아버지 뭐하시노?“라는 문구를 따오긴 했지만, 팀 구성원이라면 다른 구성원의 개인 상황을 알고 있어야 한다. 그렇다고 영화처럼 강압적 방식이 아니라 상대방과의 자연스러운 대화를 통해 파악될 수 있는 수준이면 족하다. 이 과정을 통해 느슨한 연대가 만들어진다. 사람으로의 신뢰가 쌓이기 시작한다.
쉽게 이야기했지만, 전혀 쉽지 않다. 이 수준의 신뢰 관계가 맺어지기 위해서는 대화 과정에서 스스로 가드(Guard)를 내려놓는 용기가 필요하다. 나의 사적 영역 일부를 먼저 공개해야 상대방의 가드도 내려간다. 내가 열린 자세가 되지 못했는데, 상대방에게 그러라고 하는건 어불성설이다. 때문에 이런 모습을 먼저 리드가 보여줘야 한다. 높은 위치를 점하고 있는 사람이 먼저 열린 자세를 보여주고, 그 태도가 진심이라고 느끼게 되면 자연스럽게 본인의 가드를 내릴 수 있다. (개인적으로 Radical Candor와 Dare to Lead 책을 읽어보길 추천한다.)
팀을 떠나 조직 안에서의 협업은 항상 신뢰가 깔려 있어야 한다. 쉽지 않은 대화와 토론이 이어진다면 내가 그 사람을 사람으로 알고 있는가를 질문해보길 추천한다. 사람으로의 이해가 담보되지 않은 상태에서 이런 토론이 지속되면 결국 날카로운 칼에 당사자들부터 다치게 마련이다. 이런 상황이라면 한발짝 물러나 사람을 아는 과정부터 해보길 추천한다.
다만 주의할 점은 선을 넘지 말아야 한다. 아는 것이 필요하지 알아야 하기 때문에 그 사람의 사적 영역을 침범해서는 안된다. 신뢰란 쌍방의 관계이지만 그 수준은 각자가 정한다. 가드를 내리더라도 그건 내리는 사람 맘이다. 그 마음을 존중하지 못한다면 이미 쌓았던 신뢰 관계도 사라지고 만다. 남의 집 숟가락, 젓가락 숫자를 알려고 하지 마라.
리더의 자질 가운데 하나로 “경청“이라는 단어를 많이들 이야기한다. 나름 잘 들을 수 있는 준비는 되어 있다고 생각하고, 다른 구성원들과의 이야기에서도 듣기 위해 많이 노력한다.
하지만 최근 깨닫게 된 사실 하나는 나는 이야기하기에 편한 사람이 되질 못한다는 것이다. Vulnerability를 중시하고 사람들에게 가능한 편안하게 다가갈려고 했지만, 다가가는 것과 다가오는 건 천지차이임을 다시금 알게 됐다. 직급과 직책이 높아질 수록 그 사이의 계단 개수는 그 높이만큼 많아지는게 사실인 것 같다. 그러다보니 실무의 체감 온도와 내가 느끼는 온도 차는 “괴리”감을 일으킬 정도까지 차이가 이미 벌어진게 아닐까 싶은 고민도 생긴다.
그래서 6월말부터 월 1회씩 AMA(Ask Me Anything)를 진행하기로 했다. 한국 문화 특성상 본인 실명으로 과감한 이야기를 들을 수 없을 것 같아서 무기명(Anonymous)으로 질문하는 것을 허용했다. 대찬 질문들이 많았고, 즉석에서 대답해주기 어려운 질문들이었다. 몇가지 본부내 정책 변화를 시도할 예정이라는 것에 구성원의 강한 의구심 역시 피할 수 없었다. 그럼에도 이런 이야기를 들을 수 있었다는 사실에 만족한다.
조직의 의사 결정이 모든 사람들을 만족시킬 수는 없다. 불만족은 항상 지속될 것이고, 몇몇은 불만족인 상태로 유지될 것이다. 그럼에도 “변화(Change)“라는 것이 존재하고, 이 변화를 통해 제대로 서비스를 개발하기 위해 성숙한 조직으로 나아간다는 혹은 나아갈 것이라는 점이다.
항상 피드백을 강조한다. 스프린트 운영에서 데모를 통해 피드백을 받아야 한다는 것을 강조한다. 회고를 통해 1개씩은 팀이 개선되어야 한다고 강조한다. 조직을 운영하는데 있어서도 당연히 피드백이 있어야 한다. 피드백이 있어서 성장하고 성숙한 제품과 조직이 될 수 있다.
리더는 의사 결정을 내리고, 그 결정을 책임진다. 올바른 결정을 내리기 위해서는 많은 목소리를 들어야 한다. 리더가 내린 결정을 구성원들이 존중하고 함께 그 방향으로 노를 젓도록 만드는 것이 리더의 역량이다. 이렇게 되기 위해서는 물론 구성원이 말할 수 있는 환경이 만들어져야 한다. 그렇기 때문에 Vulnerability가 매우 중요하고, 이를 기반으로 한 팀 단위의 소통이 중요하다.
AMA는 이 관점에서 조직의 단계를 뛰어넘는 의사 소통 방법이지만, 전체 조직이 한 방향으로 가고 있는지 그 방향성에 어떤 다른 목소리가 있는지를 알아야 한다. 이를 바탕으로 미션을 완성하기 위한 구성원들의 노력을 제대로 엮어낼 수 있다고 본다.
앞선 글에서 OKR(Objective, Key Results)의 실행 방식을 이야기했다. 조직의 방향에 맞춰 구성원이 도전적인 목표를 설정하고 측정 가능한 결과들로써 목표 달성 여부를 명확하게 해야 한다. 방향성에 맞춘 개인의 노력들이 하나로 합쳐졌을 때 꿈(미션)에 다가설 수 있다. 각자가 제멋대로라면 잡초밭이 되겠지만, 방향성에 맞춘 구성원의 목표가 만족된다면 아름다운 정원이 탄생할 것이다.
아름다운 정원을 함께 만들어내기 위해 구성원들은 본인의 실력으로 최선을 다해야 한다. 모두가 합의한 조직의 가치를 결과물(아름다운 정원)을 통해 실현시킬 수 있다. 그리고 최선을 다한 과정과 결과는 구성원 개인의 능력을 높이기 마련이다.
실현된 결과가 있을 때 당연히 노력한 구성원 개인에 대한 보상이 있어야 한다. 우리가 사는 사회가 자본주의 아닌가? 대가없는 가치제공은 있을 수 없다. 합당한 보상이 반드시 있어야 한다. 당연히 합당한 보상을 위한 합리적인 평가가 뒷받침되야 한다.
평가와 보상
대부분 기업은 연봉제다. 나이가 아니라 능력으로 평가받는 시대다. 물론 버티는 것도 능력이라면 능력일 수 있겠다. 그만큼 사람의 능력이 중시되고 있고, 이를 금전적으로 가치 환산한 것이 어찌보면 연봉제의 핵심 개념이다. 때문에 어떻게 “가치 환산”을 할 것인지, 합당한 보상을 받기 위해 존재하는 합리적인 평가 시스템은 조직과 개인 모두에게 중요하다.
“개인”의 보상을 고려할 때, 그 사람이 “할 수 있는 일”과 그 사람이 “해내 일”이라는 두가지 관점을 살펴야 한다 .
할 수 있는 일은 그 사람의 능력이다. 능력에 대한 보상은 그 사람이 미래에 이뤄낼 가치의 현재 기대값이다. 이 기대는 저 사람이라면 이정도의 일을 당연히 해낼 것을 의미한다. 해낼 일은 상시적이고, 항시적인 기대다. “그때그때 달라요.”라는 말은 미래 가치를 산정할 때 고려할 수 없다. “항상 해낼 것이다.”라는 전제하에 미래 가치의 현재화가 이뤄진다. 그리고 이런 해낼 능력을 “역량”이라고 부른다.
반면에 해낸 일은 그 사람의 노력에 따른 결과를 의미한다. 결과는 단순히 개인의 영역에 머무리지 않고, 함께 한 조직에 어떤 영향(Impact)을 미쳤는지를 포괄해야 한다. 노력은 과거이고, 돌이킬 수 없다. 아쉽지만 결과가 항상 노력에 비례하지는 않는다.더구나 요즘은 개인보다 팀 단위의 작업으로 일의 결과가 만들어진다. 물론 외적인 불확실성이 결과의 성패에 영향을 주기에 결과에는 종종 운이 필요하며 2022년에서 2023년 사이에는 그 영향력이 매우 크다 할 수 있다.
결과는 예상 대비 상회하거나 만족하거나 혹은 미치지 못할 수 있다. 개인 노력이 결과가 만들어질 때 미치는 영향력(Influence)를 살펴보면 과거 기대치, 즉 역량이 어떻게 과정과 과정 사이에 발현되었는지를 확인할 수 있다. 역량이 적극적으로 발현되어 결과에 좋은 영향력을 미쳤는지 혹은 운빨이었는지.
보상
나는 이 두가지 관점에서 보상이 나뉘어야 한다고 생각한다. 첫째는 능력에 대한 보상이다. 능력은 지극히 개인적이다. 확인된(인정된) 능력은 좀처럼 퇴보하지 않는다. 만약 일정 수준의 일을 해낼 수 있는 능력이 이미 준비된 사람이라면 그에 합당한 보상을 하는 것이 맞다. 능력이 항시적인 것처럼 보상도 변하지 않는 보상이 되는게 맞다. 따라서 능력에 대한 보상은 연봉으로 책정되서 월급으로 따박 따박 그 사람의 통장에 꽂히는게 맞다고 본다. 개인 능력은 OKR을 통해 조직의 성장 방향에 부합해야한다. 이 부분은 역량 섹션에서 좀 더 자세히 이야기하겠다.
둘째는 노력이 반영된 결과에 대한 보상이다. 앞서 이야기한 것처럼 결과는 결과다. 그리고 현재의 대부분 결과는 팀(혹은 더 크게 조직 전체)의 노력이다. 하늘의 도움도 크게 작용한다. 그렇기 때문에 “일회성“이라는 단어가 적합하다. 마찬가지로 보상도 “인센티브(혹은 보너스)”라는 일회성 보상으로 지급되는게 맞다.
인센티브를 실행할 때 가장 주의해야할 점은 투명성이다. 투명하지 않은 인센티브는 과도한 내부 경쟁을 유발한다. 물론 경쟁해서 더 맛있는 당근을 먹는게 뭐가 나쁘냐는 사람도 있을 것이다. 분명 명심해야 할 건 회사 전체가 한팀으로 움직여도 일이 될둥말둥이다. 그런데 내가, 우리팀이 더 많은 당근을 가져가야 한다는 생각을 갖는 순간, 원팀(혹은 협업)은 물건너 간다. 이런 조직은 각자도생이거나 인생 한방이니 짧고 굵게 땡긴다라는 마인드가 당연시된다. 어느 조직을 선택할지는 언제나 개인의 몫이다. (인센티브 이야기는 개인적인 경험을 포함한 생각은 다른 글에서 좀 더 이야기해보겠다.)
투명한 인센티브 제도는 합리적으로 어느 정도를 인센티브로 받을 수 있을지를 계산할 수 있다는 것을 의미한다. 만약 조직 전체가 원팀(ONE Team)을 지향한다면 하나의 기준선에서 인센티브는 출발해야 하고 결과에 미친 영향력에 따라 변동이 발생해야 한다. 드러난 영향력은 하나의 팀으로 결과를 만들기 위해 어떤 “기여“를 했는지를 “평가“를 통해 산정된다.
기여에 대한 평가는 개인이 팀의 일원으로 혹은 팀이 목적을 달성하기 위해 보여준 태도를 중심에 둔다. 일이 되게 하기 위해 보여준 투지와 열의, 그리고 개인보다는 팀(혹은 다른 동료)를 위해 보여준 희생이 핵심이어야 한다. 그래야 개인이 아닌 팀 중심(혹은 조직 중심) 관점에서 평가의 형평성을 확보할 수 있다. 아무리 개인이 잘해도 조직이 좋은 성과를 거두지 못했다면 보상을 기대할 수 없다. 물론 이런 상황에도 인센티브를 이야기하는 분들이 있기 때문에 인센티브 지급의 첫번째 조건은 회사의 수익이 일정 수준 이상이 달성됐을 때라는 점을 분명하게 밝혀둬야 한다.
역량
사람은 “일“을 통해 성취를 얻는다. 일을 하며 성취감을 느끼는 상황은 “님이 최고입니다. 님 덕분에 일이 됐네요.” 와 같은 말을 들을 때가 아닐까 싶다. 능력을 내가 아닌 다른 사람으로부터 인정받을 때 사람은 뿌듯하다. 그리고 말 뿐만 아니라 금전적인 보상으로 돌아와야 당연한거고 또 그래야 한다.
말만으로 이 사람의 능력이 뛰어나다고 볼 수 있을까? 좀 더 들어가서 과연 사람의 능력은 어떤 잣대를 가지고 봐야하는거지? 자바로 대용량 트래픽을 처리할 수 있는 기술을 알고 있는 것으로 그 사람의 능력이 뛰어나다고 할 수 있을까? 혹은 K8S(Kubernates) 환경을 빠삭하게 알고 있는 것이 능력일까?
앞서 “일”이라는 포괄적인 단어를 사용했지만, 각자에게는 도메인과 숙련도에 따른 단계라는 것에 따라 본인의 일이 나뉜다. 그리고 일을 함께 하는 동료들이 있다. 일이 된다는 것은 개인이 도메인과 숙련도에서 펼칠 수 있는 능력과 함께 환경(동료와 시장에 대한 이해)을 함께 이해해서 결과물을 만들었다는 것이다. 의도했던 의미를 만드는 결과를 함께 잘 만들면 “덕분에”라는 이야기를 듣게 된다. 결과 기여에 필요한 도메인과 환경등에 대한 개인의 능력을 통상 “역량“이라고 부른다.
능력은 개인이 각 도메인과 환경을 다룰 수 있는 역량들의 집합체다. 대부분 역량을 이야기하면, 그 사람의 직무 역량만을 생각한다. Backend Engineer와 Web Frontend Engineer는 다르다는 것이 가장 대표적인 예이다. 기술만 갖췄다고 일이 되나? 그렇지 않다. 일을 하는 건 사람들이고, 서로 어울려 만들어낼 수 있는 능력 역시 필수다. 이런 전반의 역량들이 종합적으로 그 사람의 능력을 나타낸다.
사람이 성장한다는 것은 결국 그 사람이 가진 각각의 역량이 성장함을 의미한다. 모든 역량이 한꺼번에 성장할 수 있다면 이상적이겠다. 하지만 주어진 환경과 역할을 통해 필요한 역량이 성장하고, 항시적으로 그 성장한 역량들을 기대할 수 있을 때, 우리는 “그 사람이 그만큼의 능력을 가지고 있다.”고 말한다.
역량 평가
능력이 있음을 혹은 역량이 된다는 것을 증명해야 한다. 증명이 “평가”를 통해 인정됐을 때 합리적으로 우리는 그 사람의 능력을 인정할 수 있다. 증명의 주체는 본인이다. 자신이 자신의 역량을 뒷받침하기 위한 증명 자료들을 잘 쌓아야 한다. 모두의 인정받기 위해서는 이 증명은 객관적인 혹은 정량적인 사실에 기반해야 한다. 내가 그렇다라고 우겨봐야 남들이 인정하지 않으면 소용없다. 스스로 자신이 일정 수준에 도달했음을 정량적이고, 객관화된 자료를 바탕으로 이야기할 수 있어야 한다. “대용량 트래픽을 처리할 수 있는 기술 역량을 가지고 있다”라는 이야기는 증명에 적합하지 않다. 이를 증명하기 위한 객관화되고 정량적인 표현은 아래와 같아야 한다.
스프링 리액티브 프로그래밍을 이해하고 있고, 이를 바탕으로 어플리케이션 서버를 독자적으로 구성할 수 있으며, EKS/K8S 기반의 Scale-out 구조의 시스템을 구성해서, 부하 발생기를 통해 100,000 TPS를 p99 수준에서 500ms, 평균 200ms 수준의 Latency의 API Service를 구성한 경험이 있다.
긴 문장이긴 하지만 본인의 기술적인 이해와 활용한 방식, 그리고 이를 수치적으로 명확하게 설명했다. 이 분이라면 백엔드 엔지니어로써 대용량 트래픽을 다룰 기본 역량을 가지고 있음을 부인하지 못할 것이다. 비슷한 맥락의 예시를 하나 더 찾아보면 “에자일 방식의 개발에 익숙합니다.” 라는 말로 에자일 기반 개발 역량을 가늠하기 어렵다. 아침에 30분짜리 스크럼을 하는게 에자일 방식은 아니다.
플래닝과 회고를 통해 스토리포인트 기반 예측의 정확성을 점진적으로 개선했고, 플래닝 예측 정확성을 80% 수준으로 향상시켰다. 팀은 회고때 도출된 개선 사항을 이후 스프린트를 통해 실행했고, 연간 20건의 개선 사항 가운데 17건을 반영시켜 팀의 체질을 개선했다.
이쯤 된다면 에자일을 제대로 하고 있고, 이 역량을 누구라도 본인들 조직에 발휘해주길 바랄 것이다.
역량 발휘
그럼 증명 가능한 역량은 어떻게 발휘되어야 할까? 조직에 소속된 개인은 조직에서 가장 많은 시간을 보낸다. 따라서 역량이 발전되고 증명되는 대부분의 결과들은 조직안에서 이뤄진다. 따라서 역량은 조직에 도움이 되는 방향으로 나타나야 가장 합리적이다.
역량은 개인의 능력이라고 앞서 이야기했다. 때문에 조직과 무관하다는 주장이 있을 수 있다. 하지만 우리는 항상 “시간”을 생각해야 한다. 조직안의 개인 시간은 조직이 개인에게 조직의 목표를 위해 공헌해줄 것을 전제로 대가를 지불한 시간이다. 그 시간을 개인적으로 사용한다면 이는 이율 배반적이고 일면에서는 Abusing에 가깝다. 결국 역량의 발전은 조직의 기대를 이행하는 과정에서, 조직과 함께 발전해야 한다.
OKR과 역량
조직이 성장하고 발전하는 과정을 통해 본인이 가진 역량을 드러내거나 혹은 발전시켜야 한다. 앞선 글에서 이야기한 것처럼 조직의 발전 방향을 모두가 합의된(Aligned) 방향으로 “목표”와 “결과”로 풀어내는 것이 OKR이다.
CEO로부터 시작한 OKR이 리더와 구성원들의 OKR로 일치된 흐름을 갖는 형태로 내려와야(Top-Down) 한다. CEO를 포함한 각 구성원은 그 가운데 본인의 직군과 직무에 합당한 역량을 활용해 혹은 발전시켜 목표에 부합하는 결과를 만들어야 한다.
개인으로써 합당한 보상을 원한다면, 당연히 “현재의 나“와 차별된 “미래의 나“를 설명할 수 있어야 한다. 목표를 결과로 달성하는 과정에서 어떻게 역량이 발휘됐고, 발전됐는지를 증명해야 한다.
높은 역량 수치를 보일려면 어떻게 해야할까? 현재의 내가 당연히 할 수 있는 일을 하겠다면 그 결과는 당연한 혹은 할만할 것이다. 전혀 높지않다. 높아질 역량이 감당할만한 과감한 결과와 “도전적인 목표” 설정은 필연적이다. 정량적이고 명백한 결과는 발전된 역량 혹은 역량을 발전시키기 위한 개인의 노력을 증명한다.
우리가 OKR을 실행하는 목적은 성장이다. 조직의 성장이 자연스럽게 개인의 성장을 촉진한다. 과정을 반복하면 레리 페이지가 구글의 OKR에서 이야기했던 것처럼 조직이 성장할 것이며, 과거의 나와 다른 현재의 나, 그리고 또 한번 성장할 “미래의 나”를 함께 생각할 수 있어야 한다.
개인의 역할
개인은 OKR을 정하는데, 조직과 리더의 목표 및 결과를 확인하고 질문해야 한다. 자신은 조직의 결과를 만들어내기 위해 어떤 기여를 할 수 있는지, 그리고 기여 과정에서 “미래의 나“를 위해 어떤 역량을 발전시킬지를 확인해야 한다. 목표에 도달했을 때 어떤 정량적인 방법으로 증명할지 정리한다. 정리가 됐다면 이제 이 목표를 조직에 요구해야 한다. 조직에 기여함과 동시에 나의 성장을 이루기 위해 “기회”를 달라고 요구해야 한다. 조직의 일은 하겠다고 할 수 있는 것이 아니다. 본인이 요청하고 리더를 통해 확인되야 한다. OKR을 통해 이를 밝히고 요청한다.
OKR은 필수적으로 글로 정리되야 한다. 목표와 결과, 그리고 이에 대한 실행 방법은 긴 문장이 필요없다. 정량화된 숫자를 정의할 수 있다면, 실행 방법 역시 복잡할 이유가 없다. 의미 전달이 가능한 짧은 문장으로 적는다. 문장이 길어지면 애매모호함이 따라온다. 명확한 의미를 가지고 있는지, 헷갈림을 최소화했는지 살펴본다.
몇번을 읽어봐도 수립된 목표와 결과가 혼자의 힘으로 달성 불가능한 상황이 반드시 있다. 도움이 필요하다. 이 도움은 리더와 동료로부터 나온다. 따라서 공유는 필수다. 상위 리더에게는 반드시 공유해야 하고, 주변 동료들에게도 이를 공유해야 하는 이유다. 도움을 받아야 하는 동료에게 본인의 OKR을 도와줄 수 있는지, 혹은 자신의 OKR 달성을 위해 필요한 사항을 동료(들)의 OKR에 반영해줄 수 있는지를 확인한다. 그리고 가능한 이를 반영해둔다. 나의 역할과 동료들의 역할이 OKR을 통해 명확해진다.
동료를 돕기 위해 반영한 OKR은 종종 나의 역량 발전과 무관할 수 있다. 큰 관점(Big Picture)에서 살펴보길 추천한다. 내 역량의 발전을 지금 당장 이루지 못하지만 동료의 OKR이 달성됨으로써, 조직이 발전한다. 그리고 이 상황이되면 내 역량을 더 크게 키워볼 판이 커진다. 무엇보다도 동료를 위해 양보하고 공동의 목표를 위해 희생할 수 있는 “역량”은 더욱 멋진 “미래의 나”를 만들어줄 것이다. 확신한다.
리더의 역할
리더는 OKR과 역량의 균형추를 맞추는 역할을 해야 한다. 물론 구성원들이 Top Down으로 이어지는 흐름에 맞춘 목표를 수립했는지를 점검해주는 것이 기본이다. 실무 업무에 가까운 리더일수록 더욱 구성원들이 OKR을 수행해서 역량 발전을 이룰 기회가 포함되었는지 확인해야 한다.
구성원의 OKR이 단순히 현재 역량 수준에 머무는 수준이라면 목표가 충분히 도전적인지 재고해야 한다. 모든 역량을 발전시킬 수 없겠지만 그 가운데도 필요한 역량 발전이 OKR을 실행하는 과정에 반영되어 있지 않다면 그 부분을 지적해야 한다. 도전적인 목표를 제시하고, 역량 발전이 이뤄지도록 가이드 해야 한다. 물론 도전적인 것을 넘어 불가능한 목표라면 이에 대해서도 충분한 논의를 해야 한다. 위험을 감수하지 않는 것도 문제지만, 불가능한 도전으로 인한 좌절도 개인에게 트라우마를 남길 수 있다. 스스로 발전하기 위한 도전 목적과 역량 발휘로 성취를 이루면 개인은 성장한다고 명확하게 느낀다. 역량의 120% 수준에 도전 가능할지를 살피고, 이를 가이드하길 권한다.
리더는 이를 위한 중재자 역할을 해야 한다. 개인 혼자만의 노력으로 원하는 결과를 얻기 어렵다. 구성원의 OKR 실현을 위해서는 필연적으로 동료의 도움이 필요하며 구성원이 다른 동료에게 도움을 줄 상황도 발생한다. 도움 받을 사람 혹은 줘야 하는 사람을 알려주고, 구성원 본인이 동료와 능동적으로 이야기하도록 해야 한다. 공유는 필수다.
동기를 충분히 설명하고, 개인 본인이 주도적으로 논의하여 OKR(목표 혹은 결과)을 확장하고, 직무(기술) 역량 이외의 공통 역량(리더십, 협업 등)을 발전시킬 기회로 활용할 수 있도록 한다. 중재자로써 이 과정을 살피고, 최종적인 OKR에 피드백을 줘야 한다.
OKR의 기본 전제
글을 마무리하며 다시 OKR의 기본을 짚어보자.
조직의 방향성에 Align
도전적인 목표
공유
결과를 실행하는 과정을 통해 역량을 드러내야 한다. 그리고 제대로 된 역량 증명을 위해서는 이 3가지 기본 전제가 지켜져야 한다.
조직 방향성에 Align
역량은 조직 방향에 맞춘 결과를 실행하는 과정을 통해 나타나야 한다. 조직 구성원으로써, 조직의 발전에 자신의 역량이 제대로 쓰일 수 있음을 확인한다. 조직의 발전이 개인의 발전과 함께 이뤄져야 한다. 최종적으로 조직의 발전만큼 그만큼의 보상이 개인에게 주어졌을 때 성장의 의미를 제대로 새길 수 있다.
도전적인 목표
역량에 안주하면 개인의 성장 역시 멈춘다. 이런 태도가 만연한 조직이라면 조직의 성장 역시 멈춘다. 역량 발전이 멈춘 개인에게는 당연히 좋은 평가를 줄 수 없다. 스스로 도전적인 목표를 통해 역량 발전을 실현할 기회를 스스로 설정해야 한다. 리더는 도전 기회를 제공하기 위해 노력해야 하고, 기회를 활용해야 한다고 구성원에게 제시해야 한다. 이를 달성한, 합당한 역량 발전을 이뤄낸 구성원들에게 합리적인 보상이 돌아갈 수 있도록 해야 한다.
공유
조직의 목표를 실행하는 주체는 함께하는 “팀웍“이고, 구성원은 자신의 기여를 개인 OKR로 정의한다. 개인 OKR의 결과는 결국 팀의 결과로 이어진다. 내가 어떤 기여를 할지, 이 기여들이 어떻게 하나가 될지 알아야 하고 알려야 한다. 공유는 핵심 역할을 수행하고, 도움이 필요한 부분을 서로 각자의 기여치, OKR의 목표와 결과로 반영해야 한다. “나”와 “너”가 합쳐서 “우리”가 되어야 한다. Top-Down을 통한 조직 방향성에 대한 Align은 공유를 통해 완성되고 모두를 위한 보상으로 돌아온다.
쏘카는 OKR(Objective, Key Results)를 기반의 성과 관리 시스템을 도입중이다. “모든 사람이 자유롭고 행복하게 이동하는 세상“을 실현한다는 쏘카의 미션을 달성하기 위해 구성원 각자는 한해 어떤 목표를 가질지, 그리고 그 목표 달성을 어떤 결과로 증명할 것인지를 정한다. 간단히 설명하자면 이렇다.
목표를 세우고 결과로 증명하면 된다라는 것이 뭐 그닥 새로울 것도 없을 것 같은데 사람들이 가열차게 이야기하는 이유가 뭘까? 목표 지향적인 관리가 필요하다라는 이야기는 1950년대 피터 드러커(Peter Drucker)가 이미 MBO(Management by Objective)라는 개념을 이야기했다. 미국에서 이 개념이 잘 살아남아 인텔을 거쳐 구글로 퍼져나가면서 미국에서는 2010년대 이후부터 빅테크 기업들을 중심으로 주류의 관리 시스템이 되었다. (간단히 정리된 OKR의 역사) 역시나 OKR을 뜨겁게 만든건 구글이다.
“OKRs have helped lead us to 10x growth, many times over. They’ve helped make our crazily bold mission of “organizing the world’s information” perhaps even achievable. They’ve kept me and the rest of the company on time and on track when it mattered the most.”
Larry Page, CEO of Alphabet and co-founder of Google.
구글이 스타트업에서 빅테크로 만들어진 원동력 가운데 하나가 OKR이라고 말하고 있고, 이를 본인들 관점에서 어떻게 적용했는지를 re:Work 사이트를 통해 가이드하고 있다. 여기다 더해서 구글에 OKR을 전파한 John Doerr가 쓴 OKR 책이 베스트셀러가 되면서 더욱 더 탈력을 받지 않았을까?
하면 되는 OKR?
책도 많고, 가이드도 여기 저기 많은데 걍 하면 되는거 아닌가? 와중에 성공한 실리콘밸리의 빅테크들이 이미 OKR이 된다는 것도 증명했는데 말이다.
각자가 자신의 자리에서 회사를 위한 최선의 목표를 세우고, 증명할 결과들을 정해서 해내기만 하면 된다.
만약 위 문장이 실행하는데 말이 된다고 생각한다면… 워이~ 워이~~
정말 이렇게 생각하고, OKR을 회사에 도입할려고 했다면 절대로 하면 안된다. 99%의 확률로 망한다. OKR을 도입하기 전에 고민해야 할 내용들에 잘 정리한 글이 있다. 여기서도 잘 지적해줬지만, OKR은 다음의 3가지가 기본 요구 사항으로 전재되야 한다.
전사적 Align
도전적 목표 설정
투명한 공유
이 말들… 한국스럽다고 생각하나? 내가 느끼기에는 한국 직장인들이 일하는 방식과 어울리지 않는다. 우리는 시킨 일, 주어진 일을 잘 해내는게 미덕이다. 실패하면 매우 곤란하기 때문에 할 수 있는, 해낼 수 있는 일을 찾는 것이 일반적이지 도전은 언급하기 어려운 단어다. 각자 도생이 이미 각인된 한국 사회에서 뭔가를 공유한다는건 내 약점을 드러내는 것이나 다름없다. 과장했지만 부정할 수 없는 한국의 일하는 문화다. 이 관점에서 본다면 앞서 언급한 “워이~ 워이~~” 라고 언급한 그 실행 문장이 더 현실적인 것 같다.
경험한 OKR
라이엇에서 퇴사하기 2년전, 그러니까 본사에서 2020년부터 OKR을 적용하기 시작했다. 커진 조직을 어떻게 관리하는게 좋을 것인지에 대한 방안으로 많이 따라하는 빅테크의 방안을 도입하는 정도로 생각했다. 당연히 내세우는 가치는 맞지만 학습 안된, 문화적으로 어울리지 않는 한국 조직에 무작정 “해라!” 라는 것도 옳다고 생각하지 않았다. 다행히 각 조직별로 도입의 시점을 결정할 수 있는 권한이 주어졌다. 사이에 OKR이 어떤 사상을 가지고 있는지, 왜 미국의 빅테크 기업들은 열광하는지 어떤 방식으로 실행했는지 좀 공부했다. 물론 이 과정에서 앞서 이야기한 존 도어의 책이 큰 도움이 됐다.
OKR의 핵심이자 가장 큰 의미는 “방향성“을 일치시키는 것이 내 결론이다. 회사가 생각하는 방향과 어떻게 맞출 것인가? 그 안에서 팀이 방향성을 구현하기 위해 어떤 결과들을 만들어내야 하는가? 그리고 그 방향에 구성원들은 맞출 생각을 가지고 있는가?(혹은 어떻게 가지게 할 것인가?)
마일스톤과 90일 플랜
고민 후에 내가 찾은 시작점은 마일스톤(Milestones)과 90일 플랜(90 Days Planning)이었다. 글로벌 기술 조직의 방향성을 로컬 기술 조직에서 가늠하기 힘들었다. 때문에 역으로 “우리는 이 방향으로 가고 싶은데, 이 방향이 틀렸다면 이야기해줘.” 를 매번 확인하고 있었다. 그래서 갈 한국 조직의 방향성을 먼저 마일스톤을 통해 드러내 여러 조직과 공유했다. 방향성에 이견이 없다면 팀(리더)과 개인은 이를 본인들의 목표(Objective)로 가져가고, 이를 실현하기 위한 결과를 증명하는 방식으로 진행했다. 마일스톤이 개인별 90일 플랜으로 내려가서 개인의 목표가 된다.
90일 플랜은 조직과 일치된 목표와 명확한 결과를 가져야 한다. 무엇(What)을 왜(Why/Context) 그리고 어떤 결과로 기여할지를 분명하게 기술해야 한다. 중요한 점은 목표 달성 여부를 누구라도 알 수 있어야 한다는 것이다. 따라서 결과는 측정 가능하고 확인 가능해야 한다는 것을 매번 강조했다. “~를 하겠다.”가 아니라 “~를 N번 진행하고, 결과를 링크로 공유한다.” 혹은 “성능 테스트를 통해 1000TPS 이상이 나오도록 한다.”와 같이 구체적인 숫자를 사용해야 한다. 이것도 아니면 확인할 수 있는 증빙을 결과에 함께 링크해야 한다. 이렇게 한 분기(90일)를 보내면 누구라도 개인의 목표가 무엇이었고, 달성 여부도 알 수 있다.
라이엇에서 1년동안 이 과정을 거치면서 조직의 방향성이 개인에게 내려갈 수 있는지를 확인했다. 약간의 시간이 걸렸지만, 효과는 확실했다. 때문에 쏘카에 합류하면서 업무 도구로써 이 툴을 바로 도입시켰다. 팀 리드들과 함께 조직의 기술과 운영 문제점들을 도출하고, 이를 본부 단위 및 팀 단위의 마일스톤으로 수립했다. 그리고 마일스톤이 개인별 90일 플랜으로 내려가도록 교육했다.
물론 처음 접해본 방식이 익숙하지 않았기 때문에 시간이 걸렸다. 주기적으로 마일스톤을 체크인하고 나를 포함한 각 리드들이 먼저 90일 플랜을 작성해서 본부원 혹은 팀원들과 공유했다. 더블어 본부 마일스톤과 나의 90일 플랜을 전사 리더들에게 공유해주고, 필요한 피드백을 받았다.
결과는?
절반의 성공, 절반의 미완성이다. 마일스톤을 통해 회사가 어떤 부분에 집중하고 있는지, 그리고 팀은 회사의 방향성을 위해 어떤 부분을 달성해야 하는지까지는 전파가 이뤄졌다. 리드들이 다른 팀의 작업 내용을 서로 탐색했고, 어떤 부분을 도울지 혹은 나눌지를 이야기하기 시작한 것은 고무적이다.
다만 왜 그 목적을 달성해야하는지와 목적에 부합한 결과는 무엇인지를 개인이 정하는데는 여전히 어려움이 있다. 목표 설정에서 가장 중요한 점은 자발적으로 목표를 정할 수 있느냐이다. 아직까지는 주어진 혹은 할당된 목표가 더 많다는 것은 어쩔 수 없는… 사정상 아쉬운 부분이다.
대체적으로 결과를 정량화하기 어려워한다. 우리가 한국 사회에서 양으로 따져 결과를 세팅해본 적이 없기 때문이지 않을까 싶다. 이렇게 결과를 정하면 “왜 이걸 달성하지 못했느냐?”라는 말이 항상 따라붙으니까. 달성하지 못한 것에 대한 비난과 비판을 좋아할 사람은 세상 어디에도 없다. 인정을 받을려면 달성해야 하는거고, 달성하지 못할 바에야 “최선을 다하겠습니다”가 옳았다는건 커오면서 이미 체득한 경험이다.
피드백을 하자면…
목표는 본인이 하고 싶은, 욕심을 내고 싶은 것이면 좋다. 그리고 결과는 이 목표에 대한 과정에서 내가 해내야 하는 것들이 무엇인지를 생각한다. 90일 플랜이라는 것은 한 분기를 관통하는 OKR이다. 측정 가능한 결과는 내가 이루고 싶은 목표를 달성하기 위해 어느 만큼 가고 있는지를 측정할 수 있는 바로미터이다. 결과를 축정했을 때 목표를 이룰 수도 혹은 이루지 못할 수도 있다. 이루지 못했다고 해서 내가 성장하지 못한 것이 아니다. 개인의 입장에서 이 과정에서 나는 얼마나 성장했고, 결과를 원래 생각했던 100점짜리로 만들기 위해 나는 어느 부분을 성장해야 하는지가 더 중요하다.
목표는 욕심을 내야 한다. 할 수 있는 일이거나 매번 하는 일이라면 아무리 결과를 만들어낸다고 하더라도 어제의 당신과 오늘의 당신에 변화는 없다. 리더인 나는 당신의 성장을 원한다. 그래야 더 큰 일에 당신을 쓸 수 있으니까. 성장해야 하기 때문에 당연히 목표는 “도전적”이 되어야 한다. 그리고 도전적인 목표는 왕왕 무모하기도 하다. 그렇기 때문에 필요하다면 도움도 요청할 줄도, 받을 줄도 알아야 한다. 도움을 요청하고, 주고, 받기 위해서라도 “공유”는 절대적으로 필요하다. 90일 플랜을 작성한 이후에 리드뿐만 아니라 주변 동료들(팀을 넘어서 관련된 다른 팀이나 부서들에게도)에게도 꼭 공유하라는 이유다.
성과 평가 시스템?
90일 플랜을 실행하면서 가장 많이 들었던 질문이 평가할려고 작성하라는거 아니냐라는 것이다. OKR은 결과를 통해 목표로 향해가는 여정이자 항해라고 생각한다. 그리고 구성원의 평가는 이 항해를 함께 하는데 있어 필요한 역량을 얼마나 갖췄는지를 가늠하는 것이다. 이 관점에서 대답은 예, 아니오 모두 해당한다.
예 – 구성원이 어떤 목표를 지향하는가? 항상 안전한 항구에 머무르거나 안전한 연안으로의 항해만을 고집한다. 아무리 배를 빨리 몬다고 할지라도 그 사람이 항구를 벗어나지 않으면 의미없다. 도전적인 과제에 도전하지 않고, 자신의 역량 범위내의 목표와 결과에만 안주한다면? 결과를 항상 만족하더라도 좋은 평가는 어렵다.
아니오 – 큰 바다로의 항해는 항상 두려움이 있다. 아무리 좋은 지도를 가지고 있더라도 바람이 언제 태풍으로 바뀔지 알 수 없다. 도전하고 깨지고 만신창이가 되어 돌아올 수 있다. 무모한 목표였다고 자책할 수도 있다. 그럼에도 자신이 뭘 배웠는지, 그리고 다시 한번 기회가 주어진다면 어떤 부분들을 챙겨야 할지 도움을 받아야 할지 알게 된다면, 우린 이걸 성장이라고 이야기한다. 역량이 오를 것이고, 선원이었던 사람이 갑판장이 되고 항해사가 되고 어느 순간에는 선장이 되어 있을 것이다.
평가는 그 사람이 어떤 일을 해냈느냐도 영향을 미치지만 본질적으로 그 사람이 어떤 역량을 갖춘 사람이냐를 보는 것이다.
해야하는 OKR!
쏘카는 OKR(Objective, Key Results) 체계를 도입할려고 한다. Advisor로 이 과정에 참여하면서 어떤 방향으로 진행됐으면 하는지를 다시 한번 정리해본다.
OKR을 실행하는데 있어 가장 핵심은 앞서 언급된 다음 3가지 사항이 반드시 전제되어야 한다.
전사적 Align
도전적 목표 설정
투명한 공유
이 가운데서도 성과 관리 시스템으로써 OKR을 도입하는 가장 큰 이유는 “전사적 Align”이다. “단일 대오”를 갖추기 위해 OKR을 하는 것이다. 따라서 조직의 OKR은 반드시 Top-Down이어야 하고, 어느 방향으로 움직일지가 OKR을 통해 제시되어야 한다.
전사 레벨 OKR에서 가장 핵심적인 요소는 바로 CEO를 포함한 CXO 리더들이 잡아줄 OKR이다. CEO의 OKR은 회사의 방향을 결정하고, 그 과정을 통해 도출될 결과를 마찬가지로 측정 가능한 방식으로 제시되어야 한다. 그리고 CXO는 CEO의 결과를 목표로 설정하거나 CEO의 결과를 달성하기 위한 추가 목표들을 설정한다. CXO 역시 마찬가지로 이에 수반하는 측정 가능한 결과를 수립해야 한다. CEO를 포함한 CXO의 목표는 궁긍적으로 “미션:모든 사람이 행복하게 이동하는 세상”에 Align해야 한다. 이 목표들은 미션 달성을 위한 “장기적인 방향성“을 제시하고, 이 과정으로써의 2023년 올 한해 달성해야 할 결과를 “단기적인 방향“으로 제시해야 한다.
미션은 궁극적인 것이고, 따라서 이를 언제 달성할지는 실행하는 사람들의 의지이다. 강한 의지를 보여주기 위해서 목표와 이에 따른 결과는 당연히 도전적이어야 한다. 목표와 결과 모두 구성원들이 움직여야 할 방향이기 때문에 최상위 리더의 OKR은 모든 구성원들에게 공유되어야 한다. 물론 공유되었을 때 해석의 다름이 최소화된 형태로 전달될 수 있도록 깔끔해야한다.
단위 조직(팀) 단위 목표 및 결과 설정
단위 조직들은 CXO의 목표와 결과를 현실화하기 위한 목표를 수립해야 한다. 그리고 그 목표가 달성되었음을 어떤 결과로 증명할 수 있을지를 정량화해야 한다. 아래와 같은 것들이 팀단위 혹은 그 이상 조직의 결과 예시가 될 수 있다.
개발 조직 예시
ABC 서비스를 9월까지 MVP(Link) 기능으로 출시한다.
FE 시스템에서 6월까지 CCU 300만을 수용할 수 있도록 한다.
7월 ~ 9월간 주간 2회 이상 메인 변경을 통해 노출 조정을 실행한다.
전사 방향과 일치된 목표와 결과를 정할 때 주의할 점은 정량화된 결과들을 가져가도록 노력해야한다. 위의 예시와는 달리 아래와 같은 예시를 살펴보자.
ABC 서비스를 하반기중 출시한다.
FE 시스템에서 대박 광고에 문제없게 지원한다.
메인 변경이 가능한 어드민 시스템을 가능한 빨리 제공한다.
위의 결과를 가지고 구성원들이 본인들이 달성해야 할 목표와 결과를 결정할 수 있을까? 결국 그들도 “최선을 다하겠다.” 이외에는 할 말이 없을 것이다.
달릴 방향이 정해졌다고 하더라도, 어느 정도를 거리를 달릴지 구성원들도 가늠할 수 있어야 한다. 전사적인 Alignment가 이뤄졌을 때, 자연스럽게 일에 필요한 컨텍스트 역시 알게된다. 이 컨텍스트를 배경으로 몇 미터를 달려야 할지, 그 몇 미터를 몇 초내에 뛰면 되는지가 구성원들의 목표와 결과가 되야 한다. 이래야 미션으로 향하는 조직의 성장만큼 구성원 개개인의 성장을 생각해볼 수 있기 때문이다.
참고를 위해 만약 비개발 조직이라면 아래와 같은 결과들이 도출될 수 있을 것 같다.
목표 – 여행으로써 이동의 가치를 극대화한다.
DAU 30% 증가 및 월간 신규 가입자 20% 증가
6월 ~ 9월간 YoY ARPU 40% 증가
목표 – 카쉐어링 서비스 경험 확장을 위한 접점 확대
연계 채널 2개 확장
확장된 채널을 통한 신규 고객 유입 확대 – 전체 신규 가입 사용자중 5% 이상
신규 채널로 인한 Carnivalization 최소화 – 기존 채널 DAU 3% 이하 감소.
개발자의 워딩이어서 매우 낯설긴 하지만 결과는 측정가능해야하기 때문에 숫자가 결과에서 빠질 수 없다.
구성원의 목표와 결과 설정
우리는 미션을 완수하기 위해 한 방향으로 움직여야 한다. 물론 완수를 위해 움직일 방향은 CEO를 포함한 최상위 리더들이 설정한다. 그럼에도 이를 실행하는 역할은 개별 구성원들이다. 구성원들의 OKR은 물론 전사 방향성을 맞춰야한다. 그렇지만 무엇을 할지, 어떤 결과를 만들어 팀과 조직의 목표와 결과에 기여할지는 본인이 주도적으로 결정할 수 있어야 한다.
우리를 구성하는 최소 단위는 개인, 즉 구성원이다. 구성원이 주도적으로 본인이 스스로 원하는 바를 OKR로 설정할 수 있고, 이를 통해 개인의 성장으로 이어져야 한다. 이 과정이 동작한다면 당연히 목표와 결과는 도전적일 수 밖에 없다. 되려 리더가 말려야 하는 상황이 벌어질지도 모르겠다.
이 도전을 우리가 함께 해나간다고 느낀다면 공유는 필수적이다. 내가 하는 일을 알리고, 어려움이 있을 때 도움을 받는 것이 낯설지 않아야 한다. 또한 도움을 준 동료도 받은 동료의 성취와 성장을 응원하고 이를 통해 받은 사람뿐만 아니라 준 사람 역시 함께 인정받는 문화가 뒷받침되어야 한다.
OKR은 평가 시스템이 아니다. 조직과 개인이 같은 방향을 바라보고 성과(결과)를 만들기 위해 어떻게 Alignment를 맞추고, 이를 만들어갈지를 가이드하는 도구이자 시스템이다. 이 시스템이 어떻게 사용할지는 온전히 우리가 감당할 몫이다. 이 도구를 쓰는데 있어서 가장 바탕이 되어야 할 것은 “건강한 조직 문화“다.
쏘카는 4월 1일부터 좀 더 빠른 협업을 위해 재택에서 사무실로 일하는 공간을 변경했다. 공간의 변화로 실제 일하는 방식까지 영향을 미칠려면 “시간(Time)”이라는 요소가 영향을 받아야 한다. 공간의 변화가 그럼 어떻게 시간이라는 요소에 영향을 미칠까? 영향을 줄 수 있는 가장 큰 요소는 “회의(Meeting)”이다.
재택 환경에서 논의할 꺼리가 있다면 꼭 미팅을 잡아야 한다. 그 사람이 그 시간에 실제 만날 수 있는지 알 수 없기 때문에 캘린더를 살펴야했고, 빈시간을 찾아서 그 사람(들)의 시간을 점유해야 했다. 점유한다는 것은 결국 그 논의할 그 시간까지 기다린다는 것을 의미한다. 결정할 시간이 그만큼 늦춰지는 것이고, 일하는 속도를 늦추는 요인이다.
이번 업무 공간의 변화를 꾀하고, 2주의 시간이 흐른 이후에 아래와 같이 주요한 미팅 진행 방식의 변화를 전체 팀에 요청했다. 조직 전반으로 소통의 시간을 빠르게 가져갔으면 하는 바램도 크지만 더 큰건 개인 스스로의 “나의 시간“을 확보하길 기대했기 때문이다. 시간은 뭘로도 살 수 없다.
데일리스크럼 15분컷! – 매일 진행하는 스크럼은 이슈 사항을 빠르게 공유하는 자리가 되야 한다. 이전 재택 시절에는 고립감을 이겨내기 위해서라도 많은 이야기가 필요한 시절이었다. 일하는 공간의 변화된 현재는 짧은 소통 위주로 필요한 정보를 빠르게 소통(공유)하는게 맞다. 의도적으로 15분내에 스크럼이 완료될 수 있도록 해야 한다. 말 그대로 의도적으로. 그리고 이 부분이 실체화될려면 스크럼을 이끄는 사람이 신경써야 한다. 그 사람이 스크럼마스터든 팀 리더든. 그리고 추가로 논의할 사항들은 그 사람들끼리만 이야기하면 된다. 부디 제발 데일리스크럼을 “아침 조회“로 만들지 말았으면 한다.
스크럼 서서하기 – 15분컷(짧은 스크럼)을 달성하기 위한 방안의 하나로 스크럼은 일어서서 진행해야 한다. 실제로 라이엇 미국 본사에서 20명이상이 참여하는 스크럼할 때 한때 아주 짧은 기간 동안 바닥에 팔꿈치를 대고 이야기하는 방식으로 진행했었다. 옆에 보기에도 매우 불편한 자세였지만, 1시간 걸리던 스크럼이 딱 20분안에 마무리됐다. 물론 일주일만에 서서하는 것으로 원복됐지만 이후에도 스크럼 시간이 30분 내외로 마무리되는 효과를 냈다. 체크인, 한일, 할일, 이슈를 공유하자.
불필요한 회의없애기 – 재택과 사무실 근무의 차이는 우리가 함께 같은 공간에 있다는 것이다. 미팅 요청이 들어오거나 만들거나 하면 “제가 자리로 찾아가서 상의드릴께요.” 라는 말을 먼저 꺼내보자. 혹은 지나가는 길에 잠깐 그 사람의 책상에 들려보자. 주변 사람들에게 방해되지 않는다면 이야기하고 마무리하자. 혹은 팀 사람들이 주변에 함께 앉아있기 때문에 들을 사람들은 알아서 들을 것이다. 약간의 소음이 발생한다는 것을 주변 동료들이 이해해주고, 말하는 사람이 알고만 있으면 훨씬 빠르게 시간을 절약할 수 있다. 이런 일 하나가 “현재의 나“가 해결해서 “미래의 나“를 위한 시간을 만들어줄 좋은 기회입니다.
불필요한 회의 참석 안하기 – 관성적으로 참여 요청받는 회의들이 정말 매우 많다. 참여자를 살펴보고, 굳이 필요없다면 참석 여부에 “No” 버튼을 누르자. (쉽지 않은 일인거 알지만 해보자. 생각보다 훨씬 본인에게 도움이 될 수 있다.) 일 진행에 컨텍스트를 공유받는건 매우 중요합니다. 하지만 컨텍스트를 전달받는 것만으로 충분하다면 전달받으면 된다. 이 경우에 중요한 건 회의록입니다. 요즘 친구들 정말 회의록을 열심히 작성하고 있고, 클로바같은 좋은 회의록을 정리할 수 있는 도구들도 있다. 물론 결정이 필요하지만, 나의 소중한 시간을 절약할 수 있는 결정을 하자. 미팅에 참여하는 것이 시간 절약에 도움되는 경우도 있으니 꼭 한번은 생각해보는 것이 좋다.
생각보다 쉬울 수도 혹은 어려울 수도 있다. 하지만 앞서 이야기한 것처럼 가장 중요한 것은 시간이다.
환경이 변한다면 그 환경에서 무엇이 가장 좋을지 선택하는 것도 성장 과정에서 꼭 거쳐야 하는 단계이다.