쏘카에는 피어보너스(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” 버튼을 누르자. (쉽지 않은 일인거 알지만 해보자. 생각보다 훨씬 본인에게 도움이 될 수 있다.) 일 진행에 컨텍스트를 공유받는건 매우 중요합니다. 하지만 컨텍스트를 전달받는 것만으로 충분하다면 전달받으면 된다. 이 경우에 중요한 건 회의록입니다. 요즘 친구들 정말 회의록을 열심히 작성하고 있고, 클로바같은 좋은 회의록을 정리할 수 있는 도구들도 있다. 물론 결정이 필요하지만, 나의 소중한 시간을 절약할 수 있는 결정을 하자. 미팅에 참여하는 것이 시간 절약에 도움되는 경우도 있으니 꼭 한번은 생각해보는 것이 좋다.
생각보다 쉬울 수도 혹은 어려울 수도 있다. 하지만 앞서 이야기한 것처럼 가장 중요한 것은 시간이다.
환경이 변한다면 그 환경에서 무엇이 가장 좋을지 선택하는 것도 성장 과정에서 꼭 거쳐야 하는 단계이다.
조직에서 리더의 역할은 중요하다. 그리고 조직의 규모에 따라 리더의 중요성 역시 비례한다. 대기업의 경우 최상위 리더가 누구냐, 어떤 방향성을 가지느냐가 큰 영향력을 갖는다. 최상위 리더의 방향성을 중간 리더들이 어떻게 해석해서 실행하기 때문이다. 그러나 최상위 리더가 좋은 의도로 방향을 잡아도, 이를 실행하는 중간 리더들의 해석이 잘못되면 좋은 의도가 안좋은(개인적인 생각에 최악인) 결과가 만들어지기도 한다. 더러 이 상황이 내부 조직간의 갈등을 만들어낸다.
최고 기술 리더 – 코드의 품질을 챙기자!
제대로 된 개발자라면 좋은 코드를 작성해야 한다는 것을 이제는 누구나 당연하게 생각한다. 한번 작성한 이후에 절대 처다보지 않을 코드가 아니라면, 결국 이 코드는 내가 계속 유지보수 해야 한다. 물론 내가 아니라도 내 동료가(혹은 누군가는) 이 코드를 맡아서 계속 작업을 이어갈 것이라 더욱 유지보수가 좋은, 고치기 쉬운, 좋은 코드를 작성해야 한다. 좋은 코드는 “품질(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)과 내려놓음의 끝판왕이다.
상황에 따라 리더의 역할은 달라진다. 때문에 우리의 북극성은 어디에 있는지, 나아가고 있는 방향이 맞는지 상위 리더십과 지속적으로 소통해야 한다. 그래야지 상황을 명확하게 구성원들에게 공유하고, 무엇을 실행할지를 결정할 수 있다. 특히나 기술 조직의 리더라면 서비스를 실행하고, 기술 혁신을 통해 구성원들이 달성할 수 있도록 조율자가 되야한다. 그래야만 기술 조직의 성과가 기술 조직을 넘어 전체의 속도를 가속화할 수 있는 촉매제가 될 수 있기 때문이다.
딱 오해살만한 문구다. 새로 커리어를 시작하는 신입들이 보수적이라고? 제목이 “도전적인 신입 개발자“가 되어야 하는게 아닌가? 신입(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)“가 담보되어야 한다.
주니어 스스로가 이 과정을 버티는 힘이 도전과 성취라고 생각한다. 끊임없이 도전해야 한다. 할 수 있는 좋은 환경이면 좋겠지만, 도전은 환경을 가리지 말아야 한다. 도전을 위해 푹신푹신한 쿠션을 깔아주는 곳은 없다. 자갈밭이고 가시밭이다. 이미 편한 자리는 다른 사람들이 모두 차지했다. 척박한 그곳이 주니어가 도전을 시작할 장소다.
주니어의 리더는 주니어가 있는 곳이 자갈밭이라는 사실을 알려줘야 한다. 그리고 그 장소가 주니어가 그 다음을 위해 뛰어야 할 장소라는 것도. 물론 넘어지고 엎어질 것이다. 분명 다칠 것이다. 리더는 방향을 제시한다. 그리고 옵션을 제시한다. 하지만 선택은 주니어 몫이다. 위험하지만 짧은 길로 갈지 혹은 먼길로 안전하게 돌아갈지. 다쳤을 때 약을 발라줄 수는 있지만 다친 사람이 주니어 자신이라는 건 변함없는 사실이다.
결국 리더의 코칭을 받아들일지 말지는 주니어의 선택이다. 그리고 주니어가 리더의 방향에 맞춰 또 뛰어도 후회하지 않기 위해서는 상호 신뢰가 있어야 한다. 신뢰를 바탕으로 한 도전과 경험이 내재화되면 우리는 이걸 “성장”이라고 이야기한다. 성장은 누가 만들어주는 것이 아니다. 주니어 스스로 해내야 한다. 다만 제대로된 주니어와 리더의 신뢰는 성장의 촉진제 역할을 해줄 수 있을 것이다.
쏘카에서 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 테크서밋은 서비스 조직과 함께 우리가 어떻게 고객 중심의 이동 서비스를 제공하려고 했는지를 공유하는 자리로 만들고자 한다. 단순히 기술 중심의 행사가 아닌 기술을 통해 구현된 서비스들을 중심으로 쏘카 구성원 모두가 함께하는 세션을 핵심 축으로 두고자 한다. 물론 기술 중심의 도전 과제도 기술 기업 쏘카를 나타내는 다른 축으로 진행해보고자 한다.
아직은 모든 것들이 확실한 건 아니다. 시장 자체가 불확실하기 때문에 이런 계획 역시 실제로 실행될 수 있는지는 불투명하다. 하지만 구성원들의 열의만큼 쏘카의 성과로 이어질 것이다. 그러므로 실행될 것이다. ^^;; (희망 회로를 넘 돌렸나?)
