Continue reading ‘기술 기업의 핵심’ »]]>

기술 기업의 핵심은 뭘까? 쏘카에 합류하면서 받은 요청 사항을 관통하는 단어가 “기술 기업”이었다. 사실 그전에는 기술 기업(Tech Company)이라는 단어는 기업을 포장하기 위한 미사 여구라고 생각했다.

쏘카를 기술 기업으로 만들어달라는 이야기를 들었을 때 의아했다. 자동차를 기반한 서비스이지만 온라인으로 비대면 서비스를 십년 가까이 제공하고 있으니 이미 기술로 사업을 진행하는 “기술 기업” 아닌가? 시장에서 기술 기업이라고 스스로 부르는 회사들 역시 많은 트래픽과 소위 최신의 혹해보이는(Fancy한) 기술들을 사용하는 것으로 그 이름을 정당화하고 있다고 생각했다. 그리고 2023년 현재 한국의 많은 기술 기업들을 바라보는 내 시선에는 큰 변화가 없다. 안타까운 지점이기도 하다.

기술 기업이란 뭘까?

나는 두 단어 자체에 이미 정의가 있다고 생각한다. 기술을 기반으로 사업을 만들어가는 기업. 어렵게 생각할건 없다.

하지만 일반인들은 다른 시각을 가지고 있는 것 같다. 대부분 전통적인 기업들(소위 굴뚝산업)을 기술 기업을 여기지 않는다. 실리콘벨리 Big Tech 기업들의 영향인지 인터넷, 유형보다는 무형의 자산(주로 Contents), 언제든 접근할 수 있는 서비스, 세상에 없던 개념 등등을 기술 기업의 조건으로 생각하는 듯 하다. 기술보다는 투자에 관심이 있기 때문이지 않을까?

나는 기술 기반의 사업을 진행하는 회사가 “기술 기업”이라고 정의한다. 나도 실리콘벨리를 빌려 한발짝 더 나아가면 기술을 통해 실현한 가치가 세상을 변화시키고 기여할지, 스스로 메시지를 명확히 가지고 있는 회사라면 내가 생각하는 확실한 기술 기업이다.

서비스를 만드는 책임자로써 나는 기술에 주목한다. 세상을 변화시키는 사업, 그리고 이걸 실체화시킬 기술이 필요하다. 때로 혁신적인 기술을 발명해내야 할 때도 있고, 존재하는 여러 기술들의 최적의 조합을 필요하기도 하다. 최종적으로 기술들이 서비스와 제품의 형태로 완성되어 고객들에게 전달되어야 사업이 진행될 수 있다.

질문해보자. 그럼 이 기술을 발명과 조합은 어떻게 이뤄지나? 결국 사람이 하는 일이다. 아이러니하게 기술 기업을 움직이는 핵심 역시 사람이다. 고 이건희 회장이 “천재 한명이 10만명을 먹여 살린다.”라는 어록을 남겼다. 당연히 인재는 분야를 막론하고 중요하다.

10만명을 먹여 살리려면 서비스, 제품을 만들어야 한다. 그리고 세상을 대상으로 팔 수 있는 물건을 만들어야 한다. 장인(Craftman)이 홀로 대장간에서 뚝딱뚝딱 만들어서는 안된다. 아이언맨처럼 자비스의 도움을 받아 혼자 멋진 슈트를 만드는 시대는 안타깝게도 영화속에만 존재한다.

사람이 핵심이다.

물건은 사람이 만들고 혼자서는 만들지 못한다. 결국에는 사람들, 즉 팀이다. 그리고 그 팀들이 조화된 곳이 회사라는 조직이 된다.

인재가 있어야 함은 물론이다. 그리고 그 인재들이 조화되는 팀이 있어야 한다. 그 팀이 회사가 변화시킬 세상에 대한 미션을 수행한다.

이 구조에서 나는 팀의 조화가 미션 수행에 가장 큰 역할을 수행한다고 믿는다. 팀의 성과(Performance)는 결국 팀을 구성하는 개개인들이 얼마나 기대되는 혹은 기여하는 일을 수행하는냐에 따라 달렸고, 이걸 “조화로움“이라고 생각한다.

기술적인 난제를 푸는 일을 할 수도 있고, 복잡도는 떨어지지만 귀찮은 일을 해야 할 수도 있다. 이런 일 저런 일, 모두 팀에게 주어진 일이다. 팀 안에서 이 일들을 모두 해결해야 하고, 가능한 최대한 성과와 효율이 높은 방향으로 일을 나누고 도와야 한다.

혹자는 개인별 역량에 따라 할 일이 달라야 한다고 이야기한다. 개인의 역량에 따라 차별하게 되면 일에 대한 쏠림이 발생한다. 대부분의 사람들이 “저는 이 일을 하고 싶습니다.”라는 말을 할 것이다. 누구나 보기 좋은, 인정받을 수 있는 일을 원하지 역량과 무관한 일하기를 원치 않을 것이다. 화장실 바닥에 떨어진 휴지를 줍는 일은 청소부의 몫이지 나와 관련 없다는 생각이 만연하게 된다. 자연스럽게 을 팀이 맞닥들인다.

조화로운 팀이 되기 위해서는 팀 리드의 역할이 가장 중요하다. 사람의 근본 특성인 이기주의를 넘어선 이타성을 팀원들이 보여주도록 만들어야 하기 때문이다. 이 과정에서 어려운 대화는 필수다. 팀을 위해 개인의 헌신(희생이 더 적절할지도)을 부탁해야 하기 때문이다. 팀 플레이에서 가장 중요한 것은 팀의 성과이고, 팀원은 이를 위해 움직일 준비가 되어 있어야 한다. 그리고 팀 리드는 필드 코치로써 직접 보여줄 부분은 보여주고, 팀의 성과를 위해 지시할 사항은 지시해야 한다.

아버지 뭐하시노?

팀원의 헌신이 헌신으로 잘 동작할려면 불합리하지 않아야 한다. 팀 리드가 권한을 앞세워 일방적인 희생을 강요하는 경우가 한국 조직 사회에서는 비일비재하다. 이런 불합리한 상황에 대해 저항할 수 있어야 하지만… 저항은 거의 불가능하기에 이런 상황 자체가 만들어지지 않도록 해야 한다.

불합리한 상황을 최소화하기 위해서는 사람을 알아야 한다. 리드는 구성원을 알아야 하고 마찬가지로 구성원 역시 리드를 알아야 한다. 우리는 기계와 일하는게 아니라 사람과 일을 한다. 업무 역량이 “사람”으로써 팀원/팀장의 모든 것이라고 생각하는가? 아무리 좋은 역량을 가졌다한들 아이가 아프고, 집에 어려운 일이 있는데 당장 일이 손에 잡힐까? 그리고 이런 사람 붙들고 왜 일이 그전만 못하느냐라는 이야기를 해봐야 의미없다. 되려 그런 말을 하는 사람이 원망스러울 뿐.

“아버지 뭐하시노?“라는 문구를 따오긴 했지만, 팀 구성원이라면 다른 구성원의 개인 상황을 알고 있어야 한다. 그렇다고 영화처럼 강압적 방식이 아니라 상대방과의 자연스러운 대화를 통해 파악될 수 있는 수준이면 족하다. 이 과정을 통해 느슨한 연대가 만들어진다. 사람으로의 신뢰가 쌓이기 시작한다.

쉽게 이야기했지만, 전혀 쉽지 않다. 이 수준의 신뢰 관계가 맺어지기 위해서는 대화 과정에서 스스로 가드(Guard)를 내려놓는 용기가 필요하다. 나의 사적 영역 일부를 먼저 공개해야 상대방의 가드도 내려간다. 내가 열린 자세가 되지 못했는데, 상대방에게 그러라고 하는건 어불성설이다. 때문에 이런 모습을 먼저 리드가 보여줘야 한다. 높은 위치를 점하고 있는 사람이 먼저 열린 자세를 보여주고, 그 태도가 진심이라고 느끼게 되면 자연스럽게 본인의 가드를 내릴 수 있다. (개인적으로 와 책을 읽어보길 추천한다.)

팀을 떠나 조직 안에서의 협업은 항상 신뢰가 깔려 있어야 한다. 쉽지 않은 대화와 토론이 이어진다면 내가 그 사람을 사람으로 알고 있는가를 질문해보길 추천한다. 사람으로의 이해가 담보되지 않은 상태에서 이런 토론이 지속되면 결국 날카로운 칼에 당사자들부터 다치게 마련이다. 이런 상황이라면 한발짝 물러나 사람을 아는 과정부터 해보길 추천한다.

다만 주의할 점은 선을 넘지 말아야 한다. 아는 것이 필요하지 알아야 하기 때문에 그 사람의 사적 영역을 침범해서는 안된다. 신뢰란 쌍방의 관계이지만 그 수준은 각자가 정한다. 가드를 내리더라도 그건 내리는 사람 맘이다. 그 마음을 존중하지 못한다면 이미 쌓았던 신뢰 관계도 사라지고 만다. 남의 집 숟가락, 젓가락 숫자를 알려고 하지 마라.

다음에는 기술 기업, 쏘카의 사람과 조직에 대해 이야기할 예정이다.

Continue reading ‘OKR과 역량 평가 – 합리적인 보상이란?’ »]]>

앞선 글에서 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은 공유를 통해 완성되고 모두를 위한 보상으로 돌아온다.

건투를 빈다.

– 끝 –

Continue reading ‘Tech vs. NonTech’ »]]>

조직에서 리더의 역할은 중요하다. 그리고 조직의 규모에 따라 리더의 중요성 역시 비례한다. 대기업의 경우 최상위 리더가 누구냐, 어떤 방향성을 가지느냐가 큰 영향력을 갖는다. 최상위 리더의 방향성을 중간 리더들이 어떻게 해석해서 실행하기 때문이다. 그러나 최상위 리더가 좋은 의도로 방향을 잡아도, 이를 실행하는 중간 리더들의 해석이 잘못되면 좋은 의도가 안좋은(개인적인 생각에 최악인) 결과가 만들어지기도 한다. 더러 이 상황이 내부 조직간의 갈등을 만들어낸다.

최고 기술 리더 – 코드의 품질을 챙기자!

제대로 된 개발자라면 좋은 코드를 작성해야 한다는 것을 이제는 누구나 당연하게 생각한다. 한번 작성한 이후에 절대 처다보지 않을 코드가 아니라면, 결국 이 코드는 내가 계속 유지보수 해야 한다. 물론 내가 아니라도 내 동료가(혹은 누군가는) 이 코드를 맡아서 계속 작업을 이어갈 것이라 더욱 유지보수가 좋은, 고치기 쉬운, 좋은 코드를 작성해야 한다. 좋은 코드는 “품질(Quality)” 높은 코드를 의미한다. 그럼 코드의 품질은 어떻게 바라봐야 할까? 가장 좋은 개발자의 코드 품질은 동료들에 의해 평가되는 것이 가장 좋다고 생각한다. 하지만 이 방법은 지극히 정성적이다. 사람마다 바라보는 시선이 다르기 때문에 코드를 리뷰하는 사람이 누구냐에 따라 호불호가 갈린다.

지속 가능한 코드와 같은 좋은 코딩 문화를 정착시키기 위해서는 이를 계량화시킬 필요가 있다. 다행히 테스트 코드(Test Code)라는 지속 가능한 코드를 작성하기 위해 필수적인 요소가 있고, 이를 계량화시킬 수 있는 나 와 같은 도구들이 있다. 이 도구들을 활용해 테스트가 어느 정도의 메인 코드(Main Code or Business Code)를 커버하는지를 나타내는 테스트 커버리지(Test Coverage)값을 정량적인 품질 지표로 사용할 수 있다.

2010년대 당시 한국의 소프트웨어 개발은 서비스 중심이라기 보다는 SI(System Integration) 중심이었고, 품질을 이야기할 기반조차 없었다. 개발자들 스스로도 좋은 코드보다는 시간에 맞추는 코드에 급급했다. 최고 기술 리더는 적어도 한국을 개발을 선도하는 기업이니만큼 제대로 개발하고, 제대로 서비스가 만들어지는 “문화“를 만들고 싶었다. 정량화는 개발자들이 코드 품질을 객관화하고, 좋은 코드 품질 문화를 쉽게 받아들이고 빠르게 실행할 수 있는 수단이라고 생각했다. 그리나 아직은 코드 품질 개념은 개발자들에게조차 낯선 개념이었다. 보다 확실한 정착이 필요했기에 서비스 배포(Release) 조건에 “테스트 커버리지 80% 이상“이라는 조건을 설정했다.

문제는 평가다

코드 품질이 자연스럽게 평가와 맞물렸다. 테스트 커버리지가 일정 수준을 넘어야 출시할 수 있다는 제도는 서비스 출시의 선결 조건으로 무조건 커버리지가 그 이상이어야 한다는 강제 조항으로 변질되었다. 무슨 일이 있더라도 커버리지는 그 이상을 맞춰야했고, 자연스럽게 개발자의 코딩 역량 역시 코드 커버리지가 좌우하게 됐다.

어느 순간 커버리지의 취지는 없어지고 80%라는 숫자만 남았다. 어찌됐던 서비스는 출시되어야 하고, 출시를 하기 위해서는 80%가 넘어야 했다. 2010년 초반의 자바(Java) 기반 테스트 프레임워크(Framework)는 현재(2023년) 대비 효율성이 높지 않았다. 의미없는 함수 쪼개기와 단위 테스트가 난무하기 시작했다. 품질높은 코드에 대한 고민은 사라지고, 일정을 맞추기 위한 테스트 코드들이 등장했다. 지속 가능한 코드를 위해 쓰여야하는 테스트 코드가 의미없이 생산되어 결국 쓰레기 코드가 되는 어처구니 없는 상황이 만들어졌다.

대기업 조직은 서비스 기획과 개발이 별도의 사일로 형태였다. 몇십 페이지의 기획서가 개발에 전달되고, 개발은 한땀한땀 이를 구현해야 했다. 단위 테스트를 고려하지 않은 코드도 당연히 있기 때문에 예정된 출시일에 80% 기준을 맞추지 못하는 경우도 있다. 결과는 출시일 연기. 코드 품질이라는 이름으로 출시 연기가 당연시되자 기획 조직에서는 이를 곱게 볼리가 없었다.

개발의 논리는 품질을 높여야 서비스 유지보수가 좋다는 것이다. 출시 연기는 당연하다는 논리가 시니어, 주니어를 떠나서 개발 조직 저변에 깔렸다. SI에서 볼 수 없던 일과 생활의 양립(Work and Life Balance)와 같은 그동안 한국에서 볼 수 없던 요소들이 기술 조직에서 문화적 요소로 강조됐다. 출시일을 지키기면서 제대로 된 코드를 작성하기 위한 노력들이 희미해졌다. 문제가 더욱 심각해졌다. 시선에 가시가 돋혔다.

스스로 무너지다.

잦은 서비스 출시 지연과 말도 안되는 서비스 품질에 대한 책임을 지고 최고 기술 책임자는 물러났다. 억지로 테스트 코드를 작성해야했던 개발자들은 환호했고, 제대로 개발할려고 노력했던 개발자들은 퇴사했다. 직전까지 작성하던 테스트는 관리되지 않았고, 억지로 작성했던 테스트 코드들은 삭제되었다. 코드 리뷰에서 테스트 코드가 추가되어 있으면, 테스트 작성할 시간에 서비스 피처를 더 개발하라는 피드백이 돌아왔다. 이후 오랫동안 테스트와 TDD는 금기어가 되었다. 서비스 출시의 주도권은 서비스 조직으로 넘어갔다.

이 상황에서 다음의 의문이 있다.

• 왜 개발자들은 지속 가능한 코드가 아닌 테스트된 코드를 작성했을까?

• 왜 개발자들은 서비스 출시일에 출시를 못했을까?

• 왜 개발자들은 “80%”의 문제에 이의제기하고 개선하지 못했을까?

제대로 된 기술 조직과 리더를 반겼던 개발자들은 스스로 무너졌다. “품질”이라는 이름으로 흥했던 기술 조직이 “품질”로 발목이 잡혔다. 코드 품질을 평가까지 연동시켜 개발자들에게 각인시킬려던 리더의 선한 의지는 “개발 조직”만 생각하는 편협함으로 폄하되었다. 기술 조직(Tech)과 비기술 조직(NonTech)의 대립으로까지 묘사되는 상황이다.

지속 가능한 코드가 아닌 테스트된 코드

커버리지를 높이기 위해 작성하는 테스트는 지속 가능한 좋은 코드를 짜는데 도움이 못된다. 특히 커버리지를 높이기 위해서 아래 그림처럼 코드를 함수로 쪼개고, 분리된 함수에 단위 테스트를 적용하는 방식이 사용되기도 했다. 이런 단위 테스트는 커버리지를 높이지는 몰라도 해당 코드를 통해 가해지는 상태 변경이 이후 코드에 어떤 영향을 미치는지 관리하는데 도움이 안된다.

커버리지 자체를 위한 테스트는 이후 리팩터링(Refactoring)을 진행할 때 거추장스러운 방해물이 된다. 예를 들어 위 그림의 코드에서 만약 if 문을 통채로 들어내면 어떻게 될까? 사려깊은 개발자라면 사라지는 영역에 존재하는 함수가 참조를 되짚어 관련된 코드도 같이 정리해주겠지만, 종종 쓰이지 않는 코드(Dangling Code)와 테스트로만 남겨진다.

물론 이런 류의 테스트를 작성하는 분들도 이 테스트가 본인의 코드 작성 역량을 올리는데 별 도움이 안된다는 것을 안다. 그렇기 때문에 이건 무의미한 작업이다. 점차 테스트에 대한 회의론을 만든다. 실제로 이런 무지성 테스트 작업 때문에 테스트 무용론에 적극 옹오했던 분들도 있었다.

무지성 테스트의 용도는 하나다. 서비스 출시를 위한, 커버리지로 대표되는 품질을 맞춰야했다. 이걸 맞추지 못하면 서비스를 출시할 수 없었다. 서비스를 출시할 수 없다면, 그동안 작업한 내용들에 대한 정당한 평가를 받을 수 없다. 결론적으로 평가다.

커버리지는 정량적으로 테스트가 코드를 어느 정도 담보하는지를 측정한다. 측정은 다시 서비스 출시와 평가로 자연스럽게 이어졌다. 평가 면담에서 98%이상의 커버리지를 본인의 성과라고 이야기하는 개발자들도 있었다. 물론 이정도의 커버리지라면 훌륭하다. 이 노력이 개발자의 코딩 역량을 올려줄 것이라는 추정은 매우 합리적이다. 하지만 제대로 된 코드를 작성하는지는 다분히 정성적(Quality, not Quantity)이다. 정성적인 면을 실제 증명하는 건 서비스의 변화 요청에 얼마나 빠른 대응을 보여줄 수 있느냐이다. 그리고 동료들과의 코드 협업(Pair Programming, Online Code Review)에서 긍정적 영향을 미쳤느냐이다. 코드를 판단하는 건 결국에는 동료 개발자들의 묷이다. 정량적인 커버리지가 정성적인 개발자 역량을 판단한다는 레버로 동작된다는 것이 잘못됐다.

지연된 서비스 출시

서비스는 항상 타이밍이다. 시간이라는 요소가 서비스를 넘어 사업에 미치는 영향은 크다. 따라서 특정 시기를 놓쳐 출시되는 서비스는 최초 단계의 의미를 상실한다. 매출의 큰 부분을 책임지는 사업 담당자라면 서비스의 출시 일정은 필수로 챙겨야 할 핵심 점검 사항이다. 이 시기를 놓치면 서비스 자체가 해도 그만 안해도 그만이 되버리는 경우도 있다. 이건 조직의 규모를 떠나 모두 중요하다.

이 중요성이 제대로 인식되지 못하는 경우가 있다. 사일로화된 조직들이 협업을 하는 경우다. 특히, 각 사일로 조직이 서로 두꺼운 벽을 치고 있다면 중요성을 인식하는게 더 어렵다.

대기업 개발자들은 개발 조직이라는 사일로(Silo)에 갇혀있었다. 품질 높은 개발이 우선이고, 이를 통해 자신은 자신의 사일로 안에서 평가받는다. 다른 사일로에서 결과로 평가를 받는게 아니다. 우리 개발 조직(사일로)의 평가는 프로젝트의 코드 커버리지가 80%를 초과해야 하는 것이다. 어떻게든 달성한 후에 프로젝트가 릴리즈되야 한다. 혹은 릴리즈 할려면 초과해야한다.

대기업은 대기업이다. 돈이 많다. 한두주 정도 출시를 늦춘다고 망하지 않는다. 이정도 지연이면 야근이나 주말 근무를 하지 않아도 된다. 품질 높은 코드와 일과 삶의 균형(Work and Life Balance)를 위해 이정도는 가능하다는 생각을 했을 수도 있다. 대기업이니까.

대기업의 사업 담당자는 답답할 수 밖에는 없다. 서비스 관련 기능 개발은 얼추되는 것 같지만 “코드 품질” 문제로 예정된 출시일을 못 맞춘다고 하니. 그렇다고 이걸 맞추기 위해 개발자들이 야근이라도 해서 이걸 맞추는게 아니라 출시 일정이 뒤로 밀린다. 어느 정도 밀리는 건 감수되는 상황이겠지만, 특정 상황은 앞서 이야기한 것처럼 프로젝트의 의미가 사라진다. 이런 상황이 되풀이되면 “품질 좋은 코드”의 의미에 대한 강한 의구심을 가질 수 밖에 없다.

이의 제기와 개선 도출

프로세스에 이런 문제가 있었음에도 불구하고, 해당 이슈에 대한 개선 방안이 도출되지는 못했다. 분명 이런 문제가 있다는 것을 중간 리더들은 알았을텐데, 왜 이 문제를 리더십에서 해결하지 못했을까? 어딘가에서 막힌 건 분명하다. 막혔기 때문에 결국 최고 기술 리더의 선한 의도가 조직의 실행 담당자(개발자, 엔지니어)들에게는 왜곡되었다.

가장 큰 이유는 심각성에 대한 인식의 차이가 있었다. 사업 조직에서는 일정대로 돌아가지 않는 프로젝트들에 대한 불만이 있었다. 하지만 개발 조직에서는 이를 그 정도로 심각하게 받아들이지 않았다. 개발 조직 구성원에 대한 평가는 결국 개발 조직에서 이뤄지는 것이고, 본인들은 좋은 평가를 받기 위해서는 사일로의 최상단에 있는 리더의 의사 결정을 최대한 실행하는 것이었으리라. 하지만 사일로가 몇개라도 결국은 회사다. 그리고 비즈니스고 매출과 이익이다. 그러나 개발 조직 구성원들은 이 부분 역시 각자가 신경써야만 한다는 것을 제대로 인식하지 못했다. “품질 좋은 코드“를 추구했을 뿐.

이어지는 이슈는 조직의 획일성과 경직성이다. 대기업의 반열에 올라오면서 말그대로 대기업 방식의 상명하복 조직 문화가 제대로 만들어지기 시작했다. 윗선에서 지시한 일에 대해 “이건 아닌 것 같다.”라는 말은 들어보지 못한 것 같다. 이런 경직된 상황에서 현장의 문제를 위로 전달하는 것은 상상하기 힘들다.

기술 조직과 비기술 조직의 충돌

기술 조직과 비기술 조직의 충돌 문제는 대기업에서만 일어나는 일이 아니다. 조직의 규모가 일정 수준 이상이 되면 언제든 발생할 수 있다. 특히 기술 조직이 사일로 형식으로 분리되어 있다면 특히나 더 높은 가능성을 갖는다. 이런 조건은 스타트업(Start-up)이 시리즈 B, C와 같은 조직 확장 단계에 들어갔을 때 형성된다. 이 단계는 기술을 담당하는 C레벨(CTO)을 모시기 마련이고, CTO의 성향에 따라 충돌로 인한 화재가 발생한다.

스타트업에서 서비스 검증을 마쳤다면 본격적으로 이용자를 늘리고, 핵심 서비스를 중심으로 다양한 영역으로 확장을 모색한다. 이를 뒷받침하기 위한 기술 역량을 확보해야한다. 개발 인원이 늘어나는 것은 당연하다. 이때부터 개발은 지속 가능성을 염두에 두고 이뤄져야 한다. 지속 가능성은 당연히 “품질” 높은 코드와 시스템을 요구한다. 이 상황에서 기술에 치우진 리더의 결정이 있다면, 바로 충돌 상황이 만들어진다. 타이밍이 무엇보다도 중요한 스타트업의 입장에서는 기술을 우위에 두는 판단으로 출시 일정이 영향받는다면 심각한 타격을 입는다. 자본력을 갖춘 기업의 입장에서 한두번의 충돌은 값비싼 수업료로 받아들일 수 있지만, 스타트업에게는 바로 생존의 문제로 직결된다. 그렇기 때문에 빠르게 성장할려는 기업의 기술 리더의 책임은 더욱 중요하다. 단순히 기술만 보는 것이 아니라 사업과의 균형추를 지속적으로 맞춰가야 한다.

소는 누가 키우나?

기술의 지향점은 단순히 기술 자체에 머물면 안된다. 조직의 구성원들이 모두 만들고 운영하는 서비스를 이용자에게 제공하는 역할이 “기술”이어야 한다. 서비스를 위한 기술들이 발전되어야 하고, 높은 품질의 코드 역시 이 과정의 한 요소이다.

서비스를 지향하는 기술은 시장의 빠른 검증이 가능하도록 해야한다. 이를 위한 기본 전제는 빠른 서비스 출시다. 고객에게 빠르게 전달하기 위해 무엇에 집중해야하는지, 구성원들이 서로 빠르게 소통할 수 있는 프로세스가 있어야 한다. 기획 측면에서도 고객에게 완전한 것이 아니라 쓸 수 있는 것을 우선해야 한다. 고객에게 제공할려는 가치와 생존 가능한 서비스의 핵심은 무엇인지를 구성원들이 빠르게 소통하고 그 결과물이 구현 과정을 통해 제공되야 한다.

핵심으로 제공된 서비스는 빠르게 개선(Refine)될 수 있어야 한다. 서비스로써의 생존 가능성이 확인됐다면, 그 다음은 이를 빠르게 개선하는 것이다. 빠른 개선이 동작되면서 서비스의 품질을 해칠지 않게 하기 위해서는 테스트 자동화나 배포와 인프라에 대한 자동화등이 뒷받침되야 한다. 개발자가 변화에 능동적인 코드를 만들어야 하고, 이를 서비스 환경에 빠르고 안전하게 배포할 수 있어야 한다. 변화를 두려워해서는 안된다. 고객에게 전달할 새로운 가치로써 이를 반기고 자신있게 진행할 수 있어야 한다.

핵심은 스피드

디지털 전환(Digital Transformation)은 서비스를 제공하는 모든 조직의 핵심이다. 오프라인에 국한된 사업 영역은 이제 없다라고 봐도 무방하다. 이용자 혹은 소비자의 일상이 이미 디지털을 통해 온라인에서 이뤄지고 있기 때문이다. 이와 같은 시장 환경에 대응하기 위해서는 온라인을 통한 서비스 제공 역량을 갖춰야하고, 이용자를 서비스에 붙잡아둬야 한다. 이미 디지탈화된 사용자들은 본인에게 가장 큰 가치를 제공해주는 제공자로 언제든 이동한다. 특히나 연령대가 낮아지면 낮아질수록 서비스 전환에 따른 부담감이 적다. 변화된 시장 환경에 대응하는데 필요한 건 속도(Speed)다.

기술 조직의 지향점은 그렇기 때문에 속도다. 서비스를 제공하는데 있어 이 속도를 보장하고, 기존보다 속도를 높이기 위한 방안을 찾는 것이 기술 조직이 수행해야 할 역할이다. 운영중인 서비스의 품질을 담보한 상태에서 전체 조직의 새로운 시도를 안전하게 제공해야 할 역할을 기술 조직이 담당하기 때문이다. 때문에 품질이라는 요소는 속도라는 지향점을 향하게 하는 구성 요소라고 생각된다.

TL/리더가 중요하다

이 상황에서 가장 중요한 역할은 기술 리더(Tech Lead)다. 기술의 지향점을 명확하게 구성원들에게 전달하고, 그 방향에서 “우리”는 회사가 지향하는 고객 가치를 어떻게, 어느 시점에 전달할지 합일점을 만들어내는 역할이기 때문이다. 그리고 이 지점이 기술로 만들어질 수 있도록 선두에서 리드해야 한다. 때문에 기술과 리더십을 필요하다. 특히나 리더십의 경우는 배운다고 배울 수는 없다. 리딩(Leading)은 조직에 대한 헌신(Commitment)과 내려놓음의 끝판왕이다.

상황에 따라 리더의 역할은 달라진다. 때문에 우리의 북극성은 어디에 있는지, 나아가고 있는 방향이 맞는지 상위 리더십과 지속적으로 소통해야 한다. 그래야지 상황을 명확하게 구성원들에게 공유하고, 무엇을 실행할지를 결정할 수 있다. 특히나 기술 조직의 리더라면 서비스를 실행하고, 기술 혁신을 통해 구성원들이 달성할 수 있도록 조율자가 되야한다. 그래야만 기술 조직의 성과가 기술 조직을 넘어 전체의 속도를 가속화할 수 있는 촉매제가 될 수 있기 때문이다.

TL/리더분들의 화이팅을 기원한다.

– 끝 –

Continue reading ‘쏘카에서의 1년’ »]]>

어느새 쏘카에서의 시간이 만 1년이 됐다. 제대로 일할 수 있는 기술 조직을 만들어보겠다는 생각으로 “본사”로 이직을 했던 것이 얼마 안된 것 같은데 벌써 시간이 이만큼 지나갔다. 개인적으로도 큰 변화의 시기였고, 쏘카의 기술 조직도 그만큼의 변화의 시간을 함께 관통하고 있다.

일하는 방법부터 시작해서 조직개편, 그리고 새로운 아키텍처 를 적용하는 여정까지 하루하루가 다이나믹하게 지나갔다. 그럼에도 1년이 지난 지금까지도 아침에 일어났을 때 “출근해야지” 라는 생각이 머리속에 떠오르는 첫번째 생각인걸 보면 여전히 한 일보다는 해야할 일들이 쏘카에서는 더 많다.

쏘카는 내가 합류하던 시점에 10주년 기념식을 준비하고 있었다. “타다” 서비스의 영향이었을까? 하지만 스타트업이라는 생각이 더 들었다. 대표이사를 포함한 구성원들이 젊었고, 이루고 하는 것들이 중견 기업의 그것보다는 스타트업에 더 가깝기 때문이지 않았을까 싶다.

개발 본부 사람들을 만나 처음 이야기했을 때 하고 싶은 것들에 대한 열망과 현재의 피로가 함께 느껴졌다. 개발을 하고 싶다. 제대로 서비스를 만들고 싶다. 엔지니어들이 원하는 것들에서 느껴진 공통점은 본인들의 업에 충실하게 제대로 일하기였다. 하지만 현실의 그들은 레거시 시스템을 벗어나지 못한 상태에서 많은 숫자의 일에 함몰되어 있었다. 요구받은 과제를 완성했지만, 지식은 쌓이지 못했다. 보람은 있지만, 자산이 되질 못했다. 개발보다는 일하는 시스템이 먼저 필요했다.

쎌(Cell)이라는 개발 방식이 운영되고 있었다. 과제 완성을 위해 필요한 PM, Engineer, QA 직군 분들이 하나의 세포처럼 유기적으로 협력하는 체계이다. 멋진 개념이긴 하지만 이 근간을 움직이는 핵심이 기획서였다. 왜 “기획서(혹은 문서)”일까? 함께 협업하는 사람이 드러나지 않았다.

시스템 이전의 시스템

일하는 시스템은 앞으로 현재 서비스 시스템을 넘어 “이동”을 담아내기 위한 새로운 서비스 개발을 위한 선행 조건이다.

합류 직후 두달동안 개발 혹은 관련된 분들을 인터뷰했다. “열망”과 “피로”를 투지와 성과로 만들 수 있는 방안을 고민했다. 그 결과로 개발 조직을 목적 조직화와 데모 중심의 스프린트 체계를 도입시켰다.

버킷(Bucket)이라는 목적 조직

목적 조직(Domain) 체계는 조직의 과제가 “남이 시킨 하는 일”이 아닌 “나의 일”이 되도록 하기 때문이다. 스스로 일의 주체가 됐을 때 흥이 난다. 최소한 덜 괴롭다. 업무 도메인의 개발 주체가 누군지가 알려지면 자연스럽게 소통이 풀린다. 업무 영역과 관련된 궁금증이 있다면 바로 찾아갈 수 있으니까.

물론 익숙치 않은 분들은 길찾는데 좀 걸릴 수 있다. 헤매는 불편함이 있지만 길을 찾아드리지 않는다. 가이드를 드리고 스스로 찾아오시길 부탁한다. 목적 조직이 목적 조직이 되기 위해서는 안에 있는 사람뿐만 아니라 도메인을 함께하는 조직 밖의 분들도 동일한 이해 선상에 있어야 하기 때문이다.

스프린트 – 100m 전속력으로 421.95번하기

프로젝트 방식이 아닌 데모 중심의 스프린트 방식으로 변경의 핵심은 업무에 대한 주기성을 갖도록 하는데 있다. 각 조직이 정의한 1주, 2주, 3주 단위 스프린트를 통해 결과를 만들어내기 위한 몰입 시간을 정의한다. 그리고 비즈니스 파트너들과도 이 주기를 통해 이야기해줄 것을 요청했다. 날짜 중심의 배포가 아니라 스프린트 중심의 배포가 될 수 있도록.

2022년 1월부터 진행된 조직 개편과 서비스 엔지니어링 본부의 바뀐 일하는 방식이 실행되어 지금 11월에 이르렀다. 우당탕탕의 시기였다. 하지만 TL(Tech Leader)/팀장님들을 주축으로 이 변화를 위해 다 같이 도전하고 있다. 또한 전사적으로 이 변화를 위해 기다려주었고, 응원해주고 있다. 그리고 함께 다 같이 하고 있다.

현상 유지? 변화를 향해 도전?

변화의 주체는 구성원들이었다. 어찌보면 변화를 원했고, 갈망했었던 딱 그 시점에 CTO님과 내가 있었다고 생각한다. 네이버와 라이엇에서도 해보지 못한 경험을 이곳 쏘카에서 제대로 할 수 있는 기회을 선사해준 동료들에게 감사할 따름이다.

이 방식이 최선이고 정답이라는 섣부른 생각은 안한다. 환경은 변화할 것이고 그 변화에 최선을 다할 수 있도록 우리 스스로도 언제든 익숙함을 떠나야 한다. 하지만 1월부터 지금까지의 과정을 봤을 때 11년의 젊은 쏘카 구성원들과 해낼 수 있을 것 같다는 생각이다.

출근이 기다려진다.