OKR과 역량 평가 – 합리적인 보상이란?

Posted by on

앞선 글에서 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: 목표와 핵심 결과

Posted by on

쏘카는 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를 맞추고, 이를 만들어갈지를 가이드하는 도구이자 시스템이다. 이 시스템이 어떻게 사용할지는 온전히 우리가 감당할 몫이다. 이 도구를 쓰는데 있어서 가장 바탕이 되어야 할 것은 “건강한 조직 문화“다.

OKR과 맞물려 평가는 어떤 방식으로 이뤄지면 이상적일지 다음 글에서 다뤄보고자 한다.

TO BE CONTINUED…

사무실에서 나의 시간을 확보하는 첫걸음

Posted by on

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

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

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

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

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

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

– 끝 –

Tech vs. NonTech

Posted by on

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

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

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

지속 가능한 코드와 같은 좋은 코딩 문화를 정착시키기 위해서는 이를 계량화시킬 필요가 있다. 다행히 테스트 코드(Test Code)라는 지속 가능한 코드를 작성하기 위해 필수적인 요소가 있고, 이를 계량화시킬 수 있는 Clover나 SonarQube와 같은 도구들이 있다. 이 도구들을 활용해 테스트가 어느 정도의 메인 코드(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/리더분들의 화이팅을 기원한다.

– 끝 –

보수적인 신입 개발자

Posted by on

딱 오해살만한 문구다. 새로 커리어를 시작하는 신입들이 보수적이라고? 제목이 “도전적인 신입 개발자“가 되어야 하는게 아닌가? 신입(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)“가 담보되어야 한다.

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

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

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

– 끝 –

왜 테크서밋(Tech Summit)인가?

Posted by on

쏘카에서 2022년 테크 서밋(SOCAR Tech Summit 2022)를 지난 10월에 진행했다. 값진 경험이었고, 늦었지만 이를 정리해본다.

테크 서밋이 뭔가?

테크 서밋을 한국어로 써보면 “기술의 최고점”이라는 뜻일까? 한번도 우리 나라말로 뭘까 생각해본 적이 없네. 거대한 느낌이다. 그래서인지 이런 행사는 항상 대단한 느낌이었다. 느낌만 그런게 아니라 실상 국내 대표 테크 서밋인 D2(네이버)나 If-Kakao(카카오) 행사를 보면 규모와 참여 인원이 놀랍다. 작게는 몇십, 많게는 천여명 가까이 되는 사람들 앞에서 이야기하는 기술은 최고점이라 불릴만큼 대단한거 아닐까?

테크 서밋과 유사한 행사 형태가 컨퍼런스(Conference)다. 둘의 차이가 뭘까 궁금했는데, 그간의 경험으로 나는 다음과 같이 구분한다. 서밋은 회사 구성원(혹은 특정 집단) 중심의 집중화된 행사인 반면, 컨퍼런스는 참여자(정확히는 발표자)를 특정하게 국한하지 않는다. 다녀봤을 때, QCon이 대표적인 컨퍼런스라고 생각한다. D2, If-Kakao의 경우는 주관사(네이버 혹은 카카오)에서 다수의 발표를 진행하고, 더해서 외부 발표자를 받는 형식이다. 이렇다보니 자사의 기술(력)을 홍보하는 자리가 많다. 물론 이건 행사를 주관하는 회사의 당연한 권리라고 생각한다. 그리고 이만한 지식 공유의 장을 열어주는 것 자체가 매우 감사한 일이다.

이렇게 보면 서밋은 구성원들의 공유의 장이다. 이를 회사라는 영역을 넘어, 보다 많은 사람들에게 본인들의 경험과 지식을 나누는 행사로 확장된 것이 D2 같은 행사라고 본다.

왜 필요하지?

왜 쏘카에서 테크 서밋이지? 네이버나 카카오처럼 규모가 있는 것도 아니고. 걍 오버엔지니어링(Over-engineering)아냐?

옆팀은 뭐하지?!

좋은 말로 포장하면 몰입과 집중의 이면이랄까? 쏘카의 서비스 개발 조직은 2022년을 시작하면서 목적(Domain) 조직으로 변경을 단행했다. 무모한 도전이었지만, 상반기를 넘어서면서 “목적“이라는 것에 충실한 형태로, 조직이 시스템적으로 동작했다. 물론 이건 기대 이상의 성취다. 목적 중심으로 구성원들의 몰입과 집중이 동작한다는 것을 의미하기 때문에.

하지만 이 역시 부수 효과(Side Effect)를 동반한다. 바로 팀 중심으로 시야가 좁아지는 현상이다. 스프린트 중심의 데모(혹은 결과) 중심으로 팀이 운영되기 때 “나” 혹은 “(소속)팀”의 업무/기술/사람에 집중할 수 밖에 없다. 매일 매일 내코가 석자다. 당연히 팀을 벗어난 외부에서 벌어지는 일들은 관심에서 멀어진다. 물론 이 현상을 예상해서 월간 본부 타운홀을 뒀지만 생각보다 참여가 어렵다. 매일 바쁘게 움직이면서 시간을 쪼개 타운홀 발표를 준비에 당장 팀의 비용이 드는게 사실이었다. 그러다보니 영향력있는 내용이 공유되지 못하고 넘어가는 경우도 발생했다.

중요한 기술 시도 내용들이 조직 전체적으로 공유되지 못하고, 구성원들이 알지 못하는 경우가 발생하다보니 서밋, 즉 공유의 장이 필요하다고 느꼈다. 필요한 사람들이 알아서 찾는 공유가 아닌, 전체 구성원들이 모두 알 수 있는 공유 방법이 요구되는 시점이었다. 쏘카에서 테크 서밋이 필요한 가장 첫번째 이유다. 하루를 통으로 비우고 우리 쏘카의 도전과 성장 이야기를 들어볼 시간이 필요했다.

또다른 경험

본인의 역량을 외부에 드러내는 방법에는 여러가지가 있다. 엔지니어라면 당연히 그 첫번째 수단은 코드라고 생각한다. 좋은 코드를 만들고, 그리고 코드가 좋은 서비스로 사용자를 만나야 한다. 물론 이것만으로도 어찌어찌 조직에서는 가치를 인정받을 수 있다. 하지만 정말로 가치를 인정받고 싶다면 그 가치를 수면위로 드러내야 한다. 일을 하는데 있어서 재야의 “숨은” 고수는 없다. 일을 한다면 당연히 가치를 받아야 하고, 가치를 드러나지 않고는 인정이 따라오지 않는다. 기술적인 접근 방법, 일을 하는 방법, 혹은 서비스 자체의 가치가 있다면 수면위로 올려 알려야 한다. 알리는 것 역시 훌륭한 엔지니어로써의 자질이다. 그리고 이것이 공유의 의미다.

공유 경험 가운데 끝판왕은 발표다. 특히나 많은 사람들이 모인 공간에서의 발표는 특별한 경험이다. 정해진 시간에 전달할 내용을 또렷하게 전달될 수 있도록 말해야 한다. 열린 공간이지만 수많은 사람들의 시선이 나에게 집중되어 옴짝달싹할 수 없다. 등뒤로 커다란 발표 슬라이드가 펼쳐져 있지만 나는 볼 수 없다. 떨리는 말소리를 부여잡고, 흘러가는 타이머를 살피며 한땀한땀 준비한 슬라이드 자료를 선명한 목소리로 이야기를 마쳤을 때의 성취감은 대단하다. 그리고 해낸 자신감은 발표자 본인에게 다음 도전에 대한 용기를 심어준다.

물론 사전 준비는 많은 시간과 에너지가 필요하다. 의지만 가지고 얻어질 수 없다. 준비과정에서 많은 분들이 참여해서 슬라이드를 같이 검토하고, 사전 리허설 통해서 발표 내용을 같이 검토했다. 공간의 차이는 발표하는 어투와 뉘앙스, 그리고 제스처등 기존과는 다른 많은 준비를 요구한다. 이런 과정 역시 본인들의 다음을 위한 좋은 자양분이 될 것이라 생각한다.

외부가 아닌 우리 스스로

공유나 성장이라는 측면만 본다면 되려 외부 행사에 참가하는 것만으로도 충분한 의미가 있는거 아닌가? 물론 이 측면만 본다면 틀린 말도 아니다. 아니 되려 기회가 된다면 쏘카 테크서밋에서 언급된 내용들 가운데 충분히 어필될만한 내용들이 많다. 하지만 쏘카의 테크서밋이 필요한 이유는 O2O(Offline to Online) 기반 비즈니스를 기술로 실현하는 도메인의 특성과 성장하는 과정의 도전을 담아내야 하기 때문이다.

쏘카는 네카라쿠배가 아니다. 네이버나 카카오만 두고 보더라도 규모의 면에서 기술 방향이나 완결성도 다른다. 이 다름을 인정했을 때 그들의 행사에서 이야기될 수 있는 주제는 제한적이다. 되려 이 다름에서 내가 집중할려고 하는 것은 성장하는 기업 쏘카의 “도전”이다. 지금까지도 그렇지만 적어도 앞으로 2~3년은 지속적인 도전이 필요하다. 그래야 성장 곡선의 파고를 넘어설 수 있다.

하지만 도전은 멋지지만은 않다. 멋지기는 커녕일 것이다. 모노리딕(Monolithic) 시스템 기반의 서비스를 유지하면서, MSA/EDA 체계로 전환하고 서비스를 확장시키는 여정은 기술 부채(Tech Debt)를 어느 수준으로 관리할 수 있는지에 성패가 달린다. 기술 부채를 관리한다는건 빼는 것만 의미하지 않는다. 플러스도 의미한다. 그렇기 때문에 더욱 도전이다. 이 경험을 공유하는 우리 자리가 필요하다. 이 공간과 시간을 통해 기술로서 이동을 서비스화하는 구성원 모두의 노력이 공유되고, 그 다음 과정의 성장을 위한 촉매제가 된다고 본다. 쏘카의 테크서밋이 필요한 이유다.

2022년 쏘카 테크서밋

2022년의 테크서밋은 “성장하는 기술 기업 쏘카”라는 주제어로 준비했다. 8월 말부터 기획을 시작해서, 한달 반의 준비를 했다. 외부 에이전시에 맡기기 보다는 이것조차 하나의 경험이라, 내부 인원만으로 해보자는 다소 무모한 도전을 했다. 값진 경험이긴 했지만, “이거 실화냐?” 싶은 생각이 들었다. 하루 행사고, 외부 사람들을 초대하지 않은 순수한 내부 행사로 진행했지만 준비하고 챙길 사항들이 너무 많았다.

2022년을 관통하면서 구성원분들께 강조했던 내용들을 추려 “#성장하기, #호기심, #새로운시도, #배움, #사고치기“를 핵심 키워드로 놓고 발표 주제를 추렸다. 가뜩이나 바쁜 3분기에 각 주제별 발표를 준비해주시는 분들 역시 수고를 해줬다. 보름을 남긴 시점에 자료 준비가 얼추 마무리(시작)됐고, 리뷰와 리허설을 거쳐 본행사가 시작됐다.

키노트를 맡아주신 이민석 교수님이 주니어들이 많은 쏘카 구성원들에 딱 어울리는 발표를 해주셨다. 이 자리를 빌어 다시 한번 감사의 말씀을 드린다.

모두 열심히 준비해준 덕분인지 9개의 세션들이 모두 무탈하게 진행됐다. 치열했던 두달간에 걸친 대장정의 본게임을 이렇게 마무리했고, 촬영된 동영상 편집 후 이렇게 최종적으로 2022년의 테크서밋 일정을 마무리했다. 그 사이에 행사 준비부터 영상 편집까지를 모두 같이 해낸 동료들에게 감사하다라는 말을 전한다. 더블어 테크서밋에 대한 뒷이야기를 따로 쏘카 블로그를 통해 준비중이라는 떡밥까지 던져본다.

2023년의 계획

쏘카의 2023년은 카쉐어링 서비스를 넘어 다양한 이동 서비스를 확장하는데 주력한다. 이 과정을 제대로 구현하기 위해서는 2022년에 점진적으로 적용한 EDA 기반 확장 방안이 일반화될 것을 기대한다. 그리고 더욱 적극적인 방법으로 구현될 것이다. 아키텍처의 변화가 각 서비스 구현단에 적용되면서 나오는 여러 성과들을 기대해본다. 그리고 이 과정들을 통해 많은 교훈들(Lesson and Learn)이 존재할 것으로 예상하고 있다. 부디 제발!! ㅎㅎ

쏘카의 2023 테크서밋은 서비스 조직과 함께 우리가 어떻게 고객 중심의 이동 서비스를 제공하려고 했는지를 공유하는 자리로 만들고자 한다. 단순히 기술 중심의 행사가 아닌 기술을 통해 구현된 서비스들을 중심으로 쏘카 구성원 모두가 함께하는 세션을 핵심 축으로 두고자 한다. 물론 기술 중심의 도전 과제도 기술 기업 쏘카를 나타내는 다른 축으로 진행해보고자 한다.

아직은 모든 것들이 확실한 건 아니다. 시장 자체가 불확실하기 때문에 이런 계획 역시 실제로 실행될 수 있는지는 불투명하다. 하지만 구성원들의 열의만큼 쏘카의 성과로 이어질 것이다. 그러므로 실행될 것이다. ^^;; (희망 회로를 넘 돌렸나?)

올해 가을 행사에서 다양한 분들과 세션에서 만나뵐 수 있기를 기대한다.

-끝-

2022년을 마무리하고 다시 도전합니다.

Posted by on

숨가빴던 2022년이 해넘이만 남았습니다. 많은 것들이 새로운 한해였던 것 같습니다. 서비스 엔지니어링 본부가 만들어졌고, 많은 구성원분들이 새롭게 합류했습니다. 특히 갓 사회 생활을 시작한 주니어분들의 1인분을 찾아가는 고군분투는 말 그대로 스토리였습니다. 고생하셨고, 감사합니다.

올해는 버킷이라는 이름으로 도메인(Domain) 조직이 시작됐습니다. 작게는 2명으로 시작했던 조직들이 각자의 도메인의 업무들이 자율적으로 진행될만큼 모습을 갖췄습니다. 모두의 참여와 기여 덕분입니다. 내년에는 버킷의 개념이 SE본부를 넘어 쏘카 전사 레벨의 버킷으로 조직화됩니다. 각 사업 및 운영 도메인들에서 서비스를 제공하는 구현자로써의 팀의 역할에는 변함이 없습니다.

2023년 상반기는 시기적으로 우리, 쏘카의 구성원에게 중요한 시점입니다. “여행의 이동”을 완성하고 신사업 FMS를 통해 수익 기반의 성장이 가능함을 고객과 시장에 알려야 합니다. 더불어 2022년 본격적으로 시작한 MSA/EDA 전환을 가속화해야 합니다. 이 과정을 통해 기술로써 이동의 즐거움을 고객분들께 적시에 제공할 수 있어야 합니다.

기대되는 여정이긴 하지만, 한편으로는 걱정도 됩니다. 서비스 구현하는데 이미 많은 제약 사항들이 있고, 시장의 상황도 녹록치 않습니다. 그럼에도 올해를 거치며 빌드업(Build-up)된 각 팀의 역량을 믿습니다. 노련한 TL분들과 거침없이 1인분 이상을 해주고 계신 주니어 분들, 그리고 그 사이를 접착제로 이어붙혀주시는 선배 개발자분들이 있습니다. 우리의 역량과 투지가 새로운 성장 기회를 만들어줄 것이라 믿습니다. One SOCAR로 방향성을 맞추고, 원팀의 힘을 제대로 보여줄 수 있으리라 기대해봅니다.

2023년, 기술 기업 쏘카가 제공하는 고객 가치를 우리 구성원분들과 함께 만들어 갑시다.

단축키

Posted by on

코딩을 할려고 마음먹을 때마다 처음 하는 일이 있다. 내가 사용하게 될 IDE에서 제공하는 단축키(Shortcut) 외우기. 다시 코딩을 시작하자 마음먹었던 네이버 입사 첫시절에도 그랬고, 라이엇 입사 초기에도 마찬가지였다. 이쁘게 정리된 단축키 목록을 모니터 옆에 붙혀뒀다. 이렇게 보면 아재 감성 충만하다. 나중에 알게됐지만 “Cmd + ?” 키가 단축키 목록이었다는… 일주일 정도는 지하철 출퇴근 길에 진심으로 외웠다. 필요하면 찾으면 됐지만, 그 찾는 시간조차 (과격한 표현으로) 짜증났다.

단축키를 본인 나름으로 커스텀(Customize) 셋팅으로 맞추는 분들도 있지만, 가능하면 순정(??) 그대로 사용한다. 그래도 처음에는 나름 개인화 작업을 했는데, 문제가 있었다. 첫째는 노트북이나 PC가 바뀔때마다 일일히 셋팅해줘야 한다. 물론 설정 export/import로 대부분 해결되지만 암튼 해야한다. 두번째, 어찌보면 가장 결정적인 문제인데 다른 개발자와 단축키를 가지고 이야기를 할 때 문제가 된다. 다른 친구한테 “이렇게 이렇게 수정해줘.” 라고 이야기할 때 가장 쉬운 방법이 단축키 뭘 눌러서 입력해 하는 거다. 근데 나만의 단축키라면 그 친구 IDE에서 이게 동작할리없지… SI 시절에 단축키를 커스텀으로 썼는데, 간단한 코드 수정이 전화상으로 이렇게 힘든 일인걸 세삼 알았다. 그 이후로는 순정만 쓴다. 세상을 바꿀게 아니라면 내가 바뀌는게 맞지.

아이언맨도 동굴에서 단축키를 적용했다는 걸 보면… ㅎㅎ

진심 깝깝한 순간

코딩 과정을 보면서 정말 깝깝함이 찾아오는 순간이 있다. IntelliJ 혹은 Eclipse 같은 IDE를 쓰는 분이 진심어린 자세로 마우스로 기능을 찾아가는 경우다. 한땀한땀 메뉴 트리를 탐색하거나 이쁘게 나열된 버튼을 누르는… 빌드(Build)나 실행(Run), 메소드 드릴다운(Drill Down)하거나 참조 영역을 찾아내는 “정말 흔하게 사용하는 기능들”을 이런 방식으로 사용하면 속에서 천불이 난다.

한번은 신입분이랑 간만에 페어(Pair Programming/Coding)를 한 적이 있었다. 따로 온보딩이나 이런게 있었던 건 아니라서 세상 좋은 말로 코딩을 시작했다. 초반에는 내가 키보드를 잡았고, 기존 코드를 IntelliJ를 사용해서 설명하면서 코드 추가를 진행했다. 한시간쯤 이후에 키보드를 신입분에게 넘겼다.

어라 마우스를 쓰네? 근데 탐색이나 파일 열기등 기본적인 동작인데도 왜 마우스를 쓰지?

IntelliJ를 써보지 않았는지를 먼저 물었다. 대부분 이클립스 위주로 학생들이 사용하던 시절이었기 때문에 그럴 수 있었다. 개발자는 왜 키보드에서 손을 덜 떼는게 중요한지, 그래서 단축키를 써야한다고 이야기해줬다. 그리고 개발자의 최고 편집기는 vi(m)이라는 진심도 이야기했다. 몇 일 기능 추가할 일이 있어서, 신입과의 페어는 계속됐다. 키보드를 주고 받았는데, 그 친구가 잡을때마다 자꾸 마우스를 썼다. 낭낭한 목소리로 이야기를 해줬는데도 계속 마우스를 쓴다…

마우스 쓰지 말란 말이야!

살면서 이정도로 소리쳐본적이 없었다. 근데 이정도 이야기했으면 말귀를 알아들었어야지! 단축키의 의미는 충분히 설명해줬는데, 이건 마우스 쓰겠다는건데… 참다참다 화가 폭팔했다.

대차게 신입을 깠다. 내가 설명해준 거 이야기해보라고 하고. 선배들이랑 같이 일을 할거면 내일까지 기본 단축키 다 외워서 오라고. 화난 목소리에 정색을 섞어서 이야기를 하니 사무실이 갑자기 조용해졌다. 웅성웅성했다. (덧글: 많은 분들이 이 글을 읽어주셔서 사과는 바로 그날 했습니다. 물론 사과 후 왜 이렇게 분위기 어색한 분위기를 만들었는지 도움이 될거라는 이야기도 해줬습니다. 그렇다고 혼난 신입분도 이 기억을 잊지 못한다는건 압니다. 다만 단축키를 저보다는 질쓰고 있다고 이야기하시니 만족합니다.)

이랬던 신입이 1년이 지난 어느 즈음에 “어 토니님, 마우스 쓰시네요?” 라는 이야기를 하면서 지나갔다. 많이 컸네!!!

개발자, IDE에서 마우스를 쓰면 안된다.

개발자가 IDE를 쓰는 이유는 코딩하기 위해서다. 머리속에 있는 아이디어를 코드로 타이핑치면서 내려간다. 가능한 그 사이에 방해가 없이 써 내려가는게 좋다. 페어를 하는 경우에도 마찬가지다. 둘 사이의 이야기를 우선 적어내려가는게 먼저다. 그리고 이걸 리팩토링한다. 당연히 단위 테스트가 곁들여지면 더욱 키보드에서 손이 떠날 일이 줄어든다. 이 사이에 두 손이 키보드에 머무는 위치가 변함없어야 가장 효과적이다. 사실 키보드의 화살표를 누르기 위해서 오른손 위치를 변경하는 것조차 낭비다.

키보드 위의 두손이 자연스럽게 아이디어를 기록하는 이 모습이 될려면 IDE 안에서 이뤄지는 것들이 키보드만으로 처리되야 한다. 여기에 흐름이 끊기지 않을려면 코딩 이외의 동작들, 예를 들어 찾기, 탐색, 일괄 변경 등은 과정 역시 한 호흡으로 이뤄지는게 최선이다. 이럴려면 연마해야하는 것이 단축키고 참아야 하는 것이 마우스다. 무엇보다도 큰 유혹은 마우스다. 하지만 타이핑을 치는 과정에서 마우스를 쓰게 되면 흐름이 끊긴다. 키보드를 오른손(혹은 왼손)이 떠나서 한참을 방황 후 다시 자리를 잡는데까지 오래 걸린다. 장황한 표현이긴 하지만 실제로 키보드를 다시 칠 수 있는 위치에 오기까지 오래 걸린다. (한번 측정해보면 안다.) 그리고 이걸 참고, 제대로 양손 위치 고정을 이룰려면 단축키를 외우고 익숙해져야 한다.

장황했지만 무엇보다도 현실은 시간이다. 앞서 이야기한 것처럼 일상처럼 사용하는 기능을 찾아서 실행하기 위해 굳이 시간을 낭비할 필요가 뭐 있나? 빠르게 실행하고, 결과를 확인하고, 필요하다면 수정까지 가장 짧은 시간안에 해결하야지. 실제로 앞서 이야기한 마우스를 쓸때 버려지는 시간들을 단축키를 통해 모아보면 개인별 생산성에 꽤 많은 영향을 준다. 이건 개발자만의 이야기가 아니다. 각종 그래픽 툴을 사용하는 디자이너의 경우에도 협업 가능한 수준의 UI/UX를 만들어낼 때 단축키를 활용하는 사람과 아닌 사람의 결과물 생성 속도는 어마한 차이가 있다. 그래서 실무형 디자이너분들 가운데 포토샵이나 Figma의 단축키들을 모르는 분은 없을 것이다.

협업의 첫걸음

화면이 휙휙 움직이면서 갑자기 문제가 해결되거나 일괄적으로 Refactoring이 이뤄지고, 순식간에 commit까지 이뤄지는 걸 옆에서 구경하고 있으면 세상 신기하다. 와!! 이렇게 빠르게 코드가 완성될 수 있다고? 간지 쩐다!

하지만 누군가는 이런 번잡함이 싫어서 굳이 마우스 사용한다고 이야기할 수 있겠다. 본인만의 작업 스타일이 있으니 강요하지 말라고. 물론 그 결과물이 혼자만의 결과물이고, 그 시간이 본인의 시간이라면 당연히 강요받아서는 안된다. 그렇게 할 수 있다. 아니 해야한다. 전적으로 그 사람의 시간이기 때문에.

하지만 팀 작업에서는 이럼 안된다. 본인의 결과가 협업의 일부를 구성한다면 절대로 이런 가치관은 안된다. 나의 개인적인 취향이 다른 사람의 퇴근 시간을 늦춰서는 안된다. 구성원의 한 사람인 나의 업무 속도를 향상시킬 수 있는 방법이 있는데도 하질 않는다? 그건 좀 심하게 나가자면 고의로 팀의 생산성을 떨어트리는 행위다. 개발자로써 단축키는 협업을 위한 배려이기도 하다.

Editor는 vi(m)!

vi가 최선이다!!! 맥에 vim이 기본 설치(당연히)되어 있어서 매우 좋다. 근데 Original vi였으면 어땠을까 하는 생각도 든다. 아예 화살표의 유혹에서 벗어날 수 있는 기회를 개발자들이 잡을수도 있을텐데. ㅋ

그래서 요즘도 가끔 코딩하는 분들 뒤에 슬그머니 가본다. 단축키는… 편집기는… ㅎㅎㅎㅎ

– 끝 –

Money Making

Posted by on

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

왜 이직 할려고 하나?

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

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

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

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

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

성장이란 뭘까?

Posted by on

요즘 “성장”이라는 단어를 많이 듣는다. 여기저기에서 이야기가 많다. 그리고 이 단어로 사람들을 현혹한다고 비난하는 분들도 많아졌다. 아무래도 “성장”이라는 단어가 그만큼 비중있는 단어라 중요하다거나 비난하는게 아닐까?

특히 개발 직군의 엔지니어들이 이 단어에 더 민감하다. 빠르게 발전하는 분야이다보니 새롭게 등장하는 기술 혹은 개발 패러다임(Paradigm)을 따라갈려면 끊임없이 관심을 두고 있어야 한다. 그래서 성장을 중요하게 이야기하는 목소리는 신입이나 3~5년차같은 중니어로부터 많이 나온다. 3자 관점에서 성장의 대상으로 이 친구들을 이야기하는 경우도 많고, 본인들도 중요함을 알고 있다. 뭐,.. 면접관을 하면서 직접 많이 들은 체험담이니 믿어도 된다.

반대로 비판적인 목소리는 시니어들로부터 많이 나온다. 아마도 살아온 경험의 이야기일 것이다. 시니어들이 이야기하는 비판은 성장을 앞세워 개인의 희생을 강조한 회사 이기주의를 향한다고 보는게 타당할 것이다. 실제로 성장을 빌미로 조직의 책임을 개인에게 전가한 경우도 직접 목격한 경우도 있으니 말이다.

성장은 본질적으로 지식과 경험으로 구성된다. 1차원적인 지식은 노력하면 쌓을 수 있다. 스스로 얼마만큼 시간을 투자하고 내것으로 만들려고 집중(노력)하는지에 달렸다. “수학의 정석”을 너덜너덜해질까지 반복한 친구가 있었는데, 시험 성적은 정말 좋았다. 범위가 정해진 영역에서는 노력만큼 이룰 수 있다. 개인 스스로가 이루고자 하는 얼마만큼의 의지를 가졌는지에 따라 다른 결과를 만들 수 있다.

반면에 경험은 환경을 통해 만들어진다. 환경은 다차원적이다. 개인이 만들고 싶다고 해서 만들어지지 않는다. 개인 의지와는 무관하다. 이런 환경 가운데 개인 관점에 좋은 환경도 하지만 100% 만족할 수는 없는 환경이 태반이다. 이 가운데에서 결과를 만들어내는 것이 우리의 일상이고, 이 과정이 “경험”이다. 우리 개인은 이 경험을 통해 결과를 만들어내는 것을 배운다. 더러는 좋은 결과를 만들어내기도 하지만, 또한 많은 경우 만족하지 못한다.

이 평가조차도 같은 환경안에 함께 있는 개인과 타자의 시선에 따라 서로 다르다. 하지만 흔치않지만 모두가 동의하는 좋은 결과가 아주 가끔 만들어진다. 이런 걸 보통 “성공 경험“이라 부른다. 경험이 성장한다는 건 주어진 환경에서 이런 성공을 만들어 낼 가능성을 높일 역량이 쌓인다는 것을 의미한다.

프로(Professional)는 결과로 이야기를 한다. 그 결과를 만들기 위해 어떤 경로를 선택할지를 결정하는데 경험은 큰 몫을 차지한다. 이론적으로 옳은 경로라고 하더라도 주어진 환경/상황에 따라 차선 혹은 차차선 경로가 결과를 만들어내는 맞는 선택지가 되기도 한다. 특히나 냉혹한 비즈니스(Business) 결과라면 최고가 아닌 최선을 위한 결론을 추구해야할 때도 있다. 개인이 쌓은 경험의 높이에 따라 추구할 결과마저도 달라진다. 개인이 속한 집단의 경험치에 따라 어느 수준의 결과를 목표로 추구하고, 달성할 수 있을지가 달라진다.

성장은 “인간 집단을 통해” 이뤄져야 한다. 인간은 사회적인 동물이고, 그 사회성에 “성장”은 연관성을 가질 수 밖에 없다. 이러한 구성원의 성장이 조직 혹은 그 너머 사회의 성장을 이뤄낸다고 믿는다. 사회라는 시스템에서 이뤄지는 성장은 개인은 물론, 속한 조직에도 도움이 되어야 한다. 리더라면 조직에 도움되는 구성원이 당연히 좋다. 기대치에 부합하기는 커녕 걸림돌만 되는 구성원을 좋아할 리더는 없다. 따라서 성장은 조직의 구성원으로 중요하게 생각해야 할 가치다.

구성원이 본인의 지식을 넓혀야하는 건 당연하다. 기본이 없는 상태에서 그 다음을 기대하는 건 말도 안되니까. 이 노력의 결과는 지극히 개인적이다. 본인이 해야한다. 강제할 수 없다. 강제해서도 안된다고 본다. 프로니까. 간혹 회사에서 공부할 시간을 안준다는 이야기를 듣는다. 회사는 학원도 학교도 아니다. 공부할 시간은 회사의 의무가 아니라 개인의 몫이다. 회사는 프로들의 운동장(필드, field)이다.

그럼 회사는? 구성원의 성장만 빨아먹는 존재인가? 아니다. 되려 회사는 성장을 위한 더 큰 역할을 해준다. 아니 해줘야 한다. 바로 경험을 쌓을 기회, 즉 운동장을 제공해야 한다. 경기를 통해 팀의 일원으로 결과를 이뤄내는데 공헌할 기회를 회사는 제공한다.

프로 축구를 상상해보자. 경기에서 본인이 어느 만큼의 팀플레이를 할지 이 과정을 통해, 경기 결과에 어느 만큼의 공헌을 할지를 경험한다. 경기 내내 감독과 코치, 그리고 필드 안의 주장, 동료들과 끊임없는 소통한다. 기대한(혹은 이상의) 움직임을 보여준다면, 팀전술은 제대로 실행될 수 있다. 물론 그럼에도 불구하고 경기 결과는 장담할 수 없다. 다만 승리 가능성을 높일 수 있다.

선수가 게임에 뛸 수 있는지 여부는 온전히 선수에 달렸다. 90분을 소화할 수 있는 체력이나 운동장 가운데서 상대편 골대까지 드리블하면서 돌파할 수 있는 스피드, 정확한 킥 등 여러가지 개인 역량이 고려된다. 누군가는 90분을 소화할 수도, 혹은 마지막 5분, 10분을 남기고 투입되기도 한다. 이 부분은 팀플레이어로써 팀의 판단에 의해 이뤄진다. 하지만 가장 중요한 점은 “게임에 뛸 역량을 갖추고 있는가”이다. 경기를 뛰지 못하는 건 분명 프로에게는 치명적이다.

성장을 이루는 가장 좋은 방법은 스스로에 대한 인정이다. 그리고 도움을 요청하고, 도움을 주는 것이다. 우리는 유한한 존재고, 만능이 아니다. 더구나 모든 걸 알 필요도 없다. 왜 전문 분야라는 것이 존재하겠나? 다만 모른다는 것에 대한 인정과 공감이 있어야 한다. 그리고 나의 성장뿐만 아니라 동료의 지식과 경험이 확장되어 성장이라는 이름이 될 수 있도록 도와야 한다. 팀이 성장할 수 있도록 한다는 것, 그리고 이를 위해 공헌하는 것이 조직에서 찾을 수 있는 성장 경험 가운데 가장 최선이 아닐까?

솔직함이 전제된 협력은 서로의 성장을 이끌어낼 뿐만 아니라 나와 너가 아닌 “우리“를 만든다. 닿을 수 없던 목표를 “우리”가 함께 도달할 수 있다.

– 끝 –