숨가빴던 2022년이 해넘이만 남았습니다. 많은 것들이 새로운 한해였던 것 같습니다. 서비스 엔지니어링 본부가 만들어졌고, 많은 구성원분들이 새롭게 합류했습니다. 특히 갓 사회 생활을 시작한 주니어분들의 1인분을 찾아가는 고군분투는 말 그대로 스토리였습니다. 고생하셨고, 감사합니다.
올해는 버킷이라는 이름으로 도메인(Domain) 조직이 시작됐습니다. 작게는 2명으로 시작했던 조직들이 각자의 도메인의 업무들이 자율적으로 진행될만큼 모습을 갖췄습니다. 모두의 참여와 기여 덕분입니다. 내년에는 버킷의 개념이 SE본부를 넘어 쏘카 전사 레벨의 버킷으로 조직화됩니다. 각 사업 및 운영 도메인들에서 서비스를 제공하는 구현자로써의 팀의 역할에는 변함이 없습니다.
2023년 상반기는 시기적으로 우리, 쏘카의 구성원에게 중요한 시점입니다. “여행의 이동”을 완성하고 신사업 FMS를 통해 수익 기반의 성장이 가능함을 고객과 시장에 알려야 합니다. 더불어 2022년 본격적으로 시작한 MSA/EDA 전환을 가속화해야 합니다. 이 과정을 통해 기술로써 이동의 즐거움을 고객분들께 적시에 제공할 수 있어야 합니다.
기대되는 여정이긴 하지만, 한편으로는 걱정도 됩니다. 서비스 구현하는데 이미 많은 제약 사항들이 있고, 시장의 상황도 녹록치 않습니다. 그럼에도 올해를 거치며 빌드업(Build-up)된 각 팀의 역량을 믿습니다. 노련한 TL분들과 거침없이 1인분 이상을 해주고 계신 주니어 분들, 그리고 그 사이를 접착제로 이어붙혀주시는 선배 개발자분들이 있습니다. 우리의 역량과 투지가 새로운 성장 기회를 만들어줄 것이라 믿습니다. One SOCAR로 방향성을 맞추고, 원팀의 힘을 제대로 보여줄 수 있으리라 기대해봅니다.
2023년, 기술 기업 쏘카가 제공하는 고객 가치를 우리 구성원분들과 함께 만들어 갑시다.
코딩을 할려고 마음먹을 때마다 처음 하는 일이 있다. 내가 사용하게 될 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였으면 어땠을까 하는 생각도 든다. 아예 화살표의 유혹에서 벗어날 수 있는 기회를 개발자들이 잡을수도 있을텐데. ㅋ
돈은 중요하다. 아마도 인류가 발명한 것 가운데 현재 시점에서 가장 가치를 평가받는 물건이 아닐까 싶다. 디지털 세상이 된 지금은 지폐마저 보기 힘들어졌다. 많았던 적이 없어 모르지만 일상에서 돈의 존재는 명확하며 없으면 확실히 궁핍해진다. 때문에 우리는 육체적 혹은 정신적 노동, 즉 일을 통해 이를 획득한다. 그리고 가능하면 힘을 적게 쓰고 많이 벌 기회를 찾는다.
노동의 기본 목적은 생존이지만, 이제 인간적인 삶으로 확장된다. 노동을 통해 얻어진 돈은 생계와 나아가 생활을 위해 필요하다. 먹을걸 직접 키우는 시대는 아니니까. 나의 시간을 투여해 얻은 가치를 다른 사람의 생산한 가치와 교환하기 위한 수단으로 돈이 있어야 한다. 필요한 것들이 많거나 높은 가치의 물건이 필요하다면 그만큼 많은 돈이 있어야 한다. 다른 말로 힘을 많이 써야한다, 벌어야 한다.
세대를 지나오면서도 돈의 중요도는 점점 더 올라가고 있다. 삶의 가치가 생존에서 생활로 옮겨왔기 때문이다. 생활이 생존을 압도하는 가치 변화가 확고해졌고, 생활 수준 차이가 계급으로 인식되니 더욱 더 돈이 중요해졌다. 산업의 시대를 넘어 이제 자본의 시대니만큼 중요함을 넘어 전부가 되어가는 것도 자연스러운 현상인가 싶다. 모순되지만 수단이 목적이 된 셈이다.
직업으로써 소프트웨어 엔지니어의 길을 가고 있다. 사람들에게 가치를 줄 수 있는 제품과 서비스를 내 역량을 발휘해서 제공하고 대가로 보상을 받고 있다. 물론 높은 연봉을 받으면 좋다. 내가 한 일 혹은 하는 일이 그만큼의 가치를 인정받기 때문이다. 할 일의 가치를 미리 인정받는다면 좋겠지만 미래의 나를 저당잡히고 싶진 않다. 돈은 수단이고, 길을 열심히 가기 위해 활활 태울 연료일 뿐이다. 수단을 내 삶의 목적으로 삼고 싶지 않다.
그런 면에서 이직은 반갑지 않은 변곡점이다. 직업으로써 개발자로써 개발 분야에 몸담고 있다는 건 다행이다. 그럼에도 직장이 바뀐다는 건 내 역량을 투사할 대상의 변화(Pivoting)을 의미하고, 과정 전후에 필수적으로 비용도 함께 따라왔다.
첫번째 이직: 작은 기업에서 대기업으로
“일을 왜 이따위로밖에는 못하나?”라는 스스로의 자책에 답하기 위해 아이엔소프트에서 일을 시작했다. 사회 초년생 리더의 패기가 얼마나 일을 망가트리는지를 경험한 직후였다. 제대로 일하고 싶었고, 제대로 된 제품을 만들고 싶었다. 몇년의 고생끝에 제품을 만들긴 했지만, 잘 조직된 개발팀의 필요를 뼈저리게 느꼈다. 질적으로 양적으로 커진 팀이 있어야 다음 버전을 완성할 수 있었다. 더 이상 사람들을 갈아넣기 싫었다.
하지만 쉽지 않았다. “돈을 주는 사람”이라는 말을 되풀이하는 사람과의 끝없는 언쟁이 해결될 기미도 없었다. 다 포기하고 조직화된 체계에서 일을 하는 경험을 늦게라도 갖고 싶었다. 그래야 후회하지 않을 것 같았다. 서른일곱, 늦깍이 자발적 이직을 처음 결정했다.
두번째 이직: 조직에서 사용자 중심으로
이사라는 직함과 연봉을 포기하고 네이버로 이직했다. 큰 회사로 옮기는 걸 원했던 와이프도 낮아진 연봉에 생활을 걱정했지만, 그나마 편안해진 마음을 위로로 삼았다. 옮기고 큰 조직이 어떻게 일하는지, 어떤 기술을 쓸 수 있는지를 봤다. 제품이 아닌 서비스가 어떤 방식으로 기획되고, 만들어지고, 운영되는지. 그리고 이를 위해 소위 헌신(Commitment)이 어떻게 동작되는지를 경험했다. 5년이 채 안되는 시간 사이에 사원으로 시작해서 팀장으로, 그리고 대표이사에게 안된다는 이야기를 해볼 수 있는 위치까지 도달했다.
낮았던 연봉은 회사의 성장과 서비스의 성장 그리고 역할의 책임이 커지면서 금새 이전을 상회하는 수준으로 올랐다. 그리고 매출이 아닌 서비스를 사용하는 고객 가치에 중심을 둬야한다는 생각까지 가지게 됐다. 물론 개인적인 생각이었다. 보상을 중시했다면 생각으로만 담아뒀어야 했다. 하지만 팀장으로써 이걸 실행했고, 대차게 까였다. 조직 리더가 생각하는 방향과 한참 벗어났었다. 돌이켜보면 이상이야 어찌됐든 조직 구성원으로써 하면 안됐다. 할려면 위, 옆, 아래 구성원들과 충분히 합(Alignment)를 맞췄어야 했다. 하지만 이미 조직적으로 사용자 중심의 개발을 하는 것에 대한 열망이 커진 상태였다.
세번째 이직: 한국에도 제대로 된 개발 조직
먼 퇴근길에 어느새 동반자가 된 소주 한잔을 하면서 라이엇게임즈 코리아 류석문 이사님 기사를 봤다. 네이버 처음 시절에 3개월정도 스쳐 지난 과거 경험으로, 이 분이라면 되지 않을까? 생각했다. 두병을 비워가는 즈음에 메일을 보냈고, 개발자로 지원하시라는 회신을 받았다. 면접이 마무리되는 6개월 지난 즈음 전년도 원천징수 서류를 보냈다. 딱 그 수준으로 처우 제안 메일이 왔다. 다음날 바로 동의한다고 회신했다. 최단기로 처우 협상이 완료된 케이스라고 나중에 들었고, 그렇게 라이엇에 합류했다.
그저 개발만 하고 싶었지만 팔자탓인지 원하는대로 되지 않았다. 미국”계” 회사였고, 글로벌 회사였다. 어버어버하던 시골 촌놈이 질리다못해 익숙해질만큼 영어로 이야기했다. 뻔질나게 미국 다니면서 이코노미 클래스(Economy class) 증후군도 겪었다. 일을 하는데 얼굴보면서 이야기하는게 왜 중요한지 그러면서 알았다. 무엇보다도 개발(Programming)의 종주국인 미국이 한국과 어떻게 다른지도 배웠다. 기술이 아닌 기술 문화와 프로세스의 힘이 얼마나 큰지.
그럼에도 한국팀의 역량을 제대로 보여줬다. 그 힘들다는 한국의 법적 요구 사항을 기술로 해결했고, 고객 지향의 서비스들도 만들어졌다. 이러면서 리그(League of Legends)만 서비스하는 회사가 아닌 멀티 게임 회사로 성장했다. 물론 회사의 성장과 맞물려 보상도 커졌다. 한국의 빠름(기술력)과 미국의 기술 문화 조합이 글로벌의 방향을 제때 한국 시장에 실현시킨 결과라고 생각한다. 이 경험을 제대로 된 조직으로 확장하고 싶었다. 의지와는 달리 로컬 오피스(Local Office)의 한계는 이 확장을 제한했다. 하지만 한국에 제대로 일하는 제대로된 개발 조직을 완성하고 싶었다.
그 좋은 회사를 왜 그만두냐?
완성형을 위해 쏘카로 이직했다. 이기적인 선택이다. 당장의 보상보다는 하고 싶은 일을 선택했으니.
이직을 결정 할 때마다 “그 좋은 회사를 왜 그만두냐?”는 이야기를 들었다. 조직적인 안정감과 인정 그리고 결론적으로 보상이라는 측면에서 네이버도, 라이엇도 나쁘지 않은 회사였다. 아니 좋은 회사였다. 하지만 각 시점에 이걸 넘어서는 채우고 싶은게 있었다. 다행히도 이 절박함을 채우기 위해 열심히 하는 과정에서 언제나 보상은 자연스럽게 따라왔다.
왜 이직 할려고 하나?
경력자 인터뷰의 단골 질문이다. 대부분 본인의 성장을 말한다. 좋은 이야기다. 쏘카에서는 역량을 보고, 협업의 가능성을 보고, 성장의 가능성을 본다. 서로의 기대치가 부합되면 이제 “처우”라는 현실을 논의한다. 처우협상은 인터뷰 과정을 통해 확인한 상대의 역량을 돈이라는 현실로 확인한다. 현실에서 서로에게 요구하는 기대치는 항상 다르다. 작은 차이라면 협상이 동작할 수 있다. 하지만 많은 경우, 지원자의 기대와 회사의 기대는 어마한 차이를 보인다. 더욱이 최근 이 경향은 더 뚜렷하다.
큰 차이를 직면했을 때 궁금증이 생긴다. 좋은(매우 좋은) 대우를 이미 받고 있는데 왜 이직을 하려는지? 현재 역량 대비 이미 높은 처우를 받고 있음에도, 이직을 원한다는 건 속된말로 돈값을 못했다는 것을 의미한다. 물론 환경이 바뀌면 달라질 수 있을 가능성도 약간 있지만, 과연… 1인분에 대한 의구심은 떨칠 수 없다. 특히나 리더급의 역량이 기대하는 분의 평가는 더욱 냉정해야 한다. 당연히 1인분의 역할을 해야할 뿐만 아니라 동료가 1인분을 감당할 수 있도록 만들 책임이 있기 때문이다.
이직이라는 수단을 연봉 뻥튀기 수단으로 사용하시는 분들을 요즘 너무 자주 본다. 2년도 안된 잦은 전직 경력으로 높은 처우 인상을 요구하시는 분들이다. 요즘은 이런 경향이 주니어 지원자들에게서도 나와 우려스럽다. 2년 미만 이직 이력이 있고, 경력 대비 높은 연봉을 요구하는 분은 아무리 높은 기술 역량을 갖췄더라도 드랍(Drop)한다. 회사의 미션에 공감하기 보다는 돈을 추구할 가능성이 매우 높기 때문이다.
우려스러운 건 1~3년차 신입이 이미 너무 높은 고액 연봉을 받는 경우다. 이런 경우를 연봉의 저주라고 이야기해야할까? 이런 분들을 받아줄 회사는 흔치않다. 그렇다고 본인의 자존심인 연봉을 깎을 수는 없으니 묶이게 된다. 다양한 경험을 통해 성장해야 함에도 불구하고 우물안에 갇히게 된다. 물론 다양한 경험을 해볼만큼 규모가 큰 회사라면 다행이다. 하지만 그정도 크기의 회사라면 고액 연봉을 주진 않는다. 본인의 가치를 증명하는 가장 효과적인 방법은 성장을 통해 주변에게 그리고 본인 스스로에게 자연스럽게 인식되도록 만드는 것이 최선이다. 이직해서 성장을 경험할 수 있지만, 이직한다는 것 자체가 성장을 의미하지는 않는다.
보상은 닭이 먼저냐 달걀이 먼저냐 논리와 같다. 나는 개인이 회사 구성원으로써 기여를 보여주는게 먼저라고 생각한다. 금전적 보상은 반드시 있어야 하지만 역량의 증명이 우선이다. 보상을 가장 앞에 두고 이야기하는 조직원에게는 “돈값”을 명확하게 요구해야 한다. 세상에 공짜는 없으니까.
요즘 “성장”이라는 단어를 많이 듣는다. 여기저기에서 이야기가 많다. 그리고 이 단어로 사람들을 현혹한다고 비난하는 분들도 많아졌다. 아무래도 “성장”이라는 단어가 그만큼 비중있는 단어라 중요하다거나 비난하는게 아닐까?
특히 개발 직군의 엔지니어들이 이 단어에 더 민감하다. 빠르게 발전하는 분야이다보니 새롭게 등장하는 기술 혹은 개발 패러다임(Paradigm)을 따라갈려면 끊임없이 관심을 두고 있어야 한다. 그래서 성장을 중요하게 이야기하는 목소리는 신입이나 3~5년차같은 중니어로부터 많이 나온다. 3자 관점에서 성장의 대상으로 이 친구들을 이야기하는 경우도 많고, 본인들도 중요함을 알고 있다. 뭐,.. 면접관을 하면서 직접 많이 들은 체험담이니 믿어도 된다.
반대로 비판적인 목소리는 시니어들로부터 많이 나온다. 아마도 살아온 경험의 이야기일 것이다. 시니어들이 이야기하는 비판은 성장을 앞세워 개인의 희생을 강조한 회사 이기주의를 향한다고 보는게 타당할 것이다. 실제로 성장을 빌미로 조직의 책임을 개인에게 전가한 경우도 직접 목격한 경우도 있으니 말이다.
성장은 본질적으로 지식과 경험으로 구성된다. 1차원적인 지식은 노력하면 쌓을 수 있다. 스스로 얼마만큼 시간을 투자하고 내것으로 만들려고 집중(노력)하는지에 달렸다. “수학의 정석”을 너덜너덜해질까지 반복한 친구가 있었는데, 시험 성적은 정말 좋았다. 범위가 정해진 영역에서는 노력만큼 이룰 수 있다. 개인 스스로가 이루고자 하는 얼마만큼의 의지를 가졌는지에 따라 다른 결과를 만들 수 있다.
반면에 경험은 환경을 통해 만들어진다. 환경은 다차원적이다. 개인이 만들고 싶다고 해서 만들어지지 않는다. 개인 의지와는 무관하다. 이런 환경 가운데 개인 관점에 좋은 환경도 하지만 100% 만족할 수는 없는 환경이 태반이다. 이 가운데에서 결과를 만들어내는 것이 우리의 일상이고, 이 과정이 “경험”이다. 우리 개인은 이 경험을 통해 결과를 만들어내는 것을 배운다. 더러는 좋은 결과를 만들어내기도 하지만, 또한 많은 경우 만족하지 못한다.
이 평가조차도 같은 환경안에 함께 있는 개인과 타자의 시선에 따라 서로 다르다. 하지만 흔치않지만 모두가 동의하는 좋은 결과가 아주 가끔 만들어진다. 이런 걸 보통 “성공 경험“이라 부른다. 경험이 성장한다는 건 주어진 환경에서 이런 성공을 만들어 낼 가능성을 높일 역량이 쌓인다는 것을 의미한다.
프로(Professional)는 결과로 이야기를 한다. 그 결과를 만들기 위해 어떤 경로를 선택할지를 결정하는데 경험은 큰 몫을 차지한다. 이론적으로 옳은 경로라고 하더라도 주어진 환경/상황에 따라 차선 혹은 차차선 경로가 결과를 만들어내는 맞는 선택지가 되기도 한다. 특히나 냉혹한 비즈니스(Business) 결과라면 최고가 아닌 최선을 위한 결론을 추구해야할 때도 있다. 개인이 쌓은 경험의 높이에 따라 추구할 결과마저도 달라진다. 개인이 속한 집단의 경험치에 따라 어느 수준의 결과를 목표로 추구하고, 달성할 수 있을지가 달라진다.
성장은 “인간 집단을 통해” 이뤄져야 한다. 인간은 사회적인 동물이고, 그 사회성에 “성장”은 연관성을 가질 수 밖에 없다. 이러한 구성원의 성장이 조직 혹은 그 너머 사회의 성장을 이뤄낸다고 믿는다. 사회라는 시스템에서 이뤄지는 성장은 개인은 물론, 속한 조직에도 도움이 되어야 한다. 리더라면 조직에 도움되는 구성원이 당연히 좋다. 기대치에 부합하기는 커녕 걸림돌만 되는 구성원을 좋아할 리더는 없다. 따라서 성장은 조직의 구성원으로 중요하게 생각해야 할 가치다.
구성원이 본인의 지식을 넓혀야하는 건 당연하다. 기본이 없는 상태에서 그 다음을 기대하는 건 말도 안되니까. 이 노력의 결과는 지극히 개인적이다. 본인이 해야한다. 강제할 수 없다. 강제해서도 안된다고 본다. 프로니까. 간혹 회사에서 공부할 시간을 안준다는 이야기를 듣는다. 회사는 학원도 학교도 아니다. 공부할 시간은 회사의 의무가 아니라 개인의 몫이다. 회사는 프로들의 운동장(필드, field)이다.
그럼 회사는? 구성원의 성장만 빨아먹는 존재인가? 아니다. 되려 회사는 성장을 위한 더 큰 역할을 해준다. 아니 해줘야 한다. 바로 경험을 쌓을 기회, 즉 운동장을 제공해야 한다. 경기를 통해 팀의 일원으로 결과를 이뤄내는데 공헌할 기회를 회사는 제공한다.
프로 축구를 상상해보자. 경기에서 본인이 어느 만큼의 팀플레이를 할지 이 과정을 통해, 경기 결과에 어느 만큼의 공헌을 할지를 경험한다. 경기 내내 감독과 코치, 그리고 필드 안의 주장, 동료들과 끊임없는 소통한다. 기대한(혹은 이상의) 움직임을 보여준다면, 팀전술은 제대로 실행될 수 있다. 물론 그럼에도 불구하고 경기 결과는 장담할 수 없다. 다만 승리 가능성을 높일 수 있다.
선수가 게임에 뛸 수 있는지 여부는 온전히 선수에 달렸다. 90분을 소화할 수 있는 체력이나 운동장 가운데서 상대편 골대까지 드리블하면서 돌파할 수 있는 스피드, 정확한 킥 등 여러가지 개인 역량이 고려된다. 누군가는 90분을 소화할 수도, 혹은 마지막 5분, 10분을 남기고 투입되기도 한다. 이 부분은 팀플레이어로써 팀의 판단에 의해 이뤄진다. 하지만 가장 중요한 점은 “게임에 뛸 역량을 갖추고 있는가”이다. 경기를 뛰지 못하는 건 분명 프로에게는 치명적이다.
성장을 이루는 가장 좋은 방법은 스스로에 대한 인정이다. 그리고 도움을 요청하고, 도움을 주는 것이다. 우리는 유한한 존재고, 만능이 아니다. 더구나 모든 걸 알 필요도 없다. 왜 전문 분야라는 것이 존재하겠나? 다만 모른다는 것에 대한 인정과 공감이 있어야 한다. 그리고 나의 성장뿐만 아니라 동료의 지식과 경험이 확장되어 성장이라는 이름이 될 수 있도록 도와야 한다. 팀이 성장할 수 있도록 한다는 것, 그리고 이를 위해 공헌하는 것이 조직에서 찾을 수 있는 성장 경험 가운데 가장 최선이 아닐까?
솔직함이 전제된 협력은 서로의 성장을 이끌어낼 뿐만 아니라 나와 너가 아닌 “우리“를 만든다. 닿을 수 없던 목표를 “우리”가 함께 도달할 수 있다.
어처구니 없는 질문 같지만 팀장 A를 생각해보자. A 역시 상사인 그룹장이 책임지는 팀들 가운데 한 팀장이다. A씨에게서 팀장이라는 타이틀을 빼고 본 자연인 A만 보자. 그럼 A가 속한 팀은 어느 팀일까? 이 상황이 되고보면 처음 질문이 그리 어처구니 없는 질문은 아니다.
A는 본인이 책임지는 팀(팀원들)이 있다. 하지만 역시 그룹장(상위 조직장)에게 그는 팀원이다.
팀장으로써 있던 팀일까? 아니면 그룹장의 팀원일까?
조직의 가장 말단에 있는 사람에게는 이런 애매한 상황이 발생하지 않는다. 구성원이 리더가 되면 필연적으로 이 상황을 맞닥들인다.
대부분 본인이 책임지는 팀이 자신이 속한 팀이라고 믿는다. 그룹장은 자신의 상사이다. 그러나 상사에게는 A씨 이외에도 B, C, D와 같은 그룹에 있는 팀들의 팀장들이 있다. 그럼 A에게 B, C, D는 어떤 존재일까?
예전 대기업 다니던 친구의 이야기를 들어보면 무시무시했다. 다른 팀장은 무조건 꺽어야 한다. 그래야 내가 부장을 달고, 이사를 달 수 있다. 어린 시절의 친구, 선후배는 치기어린 감정이다. 직속 상사를 보고, 직속 상사의 상사를 보는 라인을 타야한다… 이 상황의 A에게 B, C, D는 “경쟁 상대“일 뿐이다. 설령 함께하더라도 진심이 없는 껍데기뿐이다. A에게 가장 중요한 건 남이 아닌 본인의 성공이다. 우리(조직)가 아니라 나(개인)만이 존재한다. 결국 조직에 수많은 “나”들이 모여있는 것 뿐이다. 이 와중에 뛰어난 A가 많다면 조직이 생존(성공)할 것이고, 아님 망하는 거겠지.
왜 이렇게까지 하는걸까? 경쟁의 시대에서 오로지 믿을 건 “나”와 “나의 능력”뿐이라고 생각하기 때문이겠지.
경쟁이 아니라 협력이다.
회사는 달성하고자하는 목적(숭고하든 걍 돈이든)을 가지고 있다. 열심히 노력해서 입사해서 일을 한다는 건 그 목적에 함께한다는 것을 의미한다. 동료 역시 그 목적을 달성하기 위해 노력하는 사람이다. 그렇다면 그 공동의 목표를 더욱 빨리 달성할려면 어떻게? 당연히 서로 도와야 한다. 혼자 가는 길이라면 2박 3일 시간 걸릴 것이 둘이 가면 1박 2일, 서넛이 간다면 하루 안에도 그 목표에 도착할 수 있다. 그것이 함께하는 동료의 힘이 아닐까?
회사 일을 하는 A, B, C, D는 각자가 회사에서 의미있는 자리를 담당한다. 비슷한 일을 할 수도 있고, 아예 다른 일을 할 수도 있다. 비슷한 일을 한다면 높은 품질을 낼 수 있는 노하우를 공유함으로써 서로의 발전을 도울 수 있다. 다른 일을 한다면 각자 일의 부족한 부분을 전문가적인 역량으로 메워주고 채워줄 수 있다. 발전과 성장을 통해 조직은 튼튼해지고, 개인이 달성할 수 없는 더 큰 목표를 이룰 수 있다.
이런 모습을 A, B, C, D가 함께 보여준다면 이들을 경쟁자가 아닌 동료라고 부른다. 또 이들이 같은 직속 상사 아래 있으면, 우린 이들을 “팀”이라고 칭한다.
다시 원래의 질문으로 돌아가보자. “팀장”이란 역할을 가진 A는 2개의 팀에 속한다. 한 팀은 A가 리딩하는 팀이다. 또 다른 팀은 B, C, D와 함께하는 팀이다. 그 팀안에서 “팀원“으로써 그룹장의 리딩을 받는다.
개인이 속한 2개 팀 가운데 어느 팀이 더 중한지 이야기한다면? 조직의 미션/비전을 “실행“하는 관점에서 생각하면, A는 팀원으로 존재하는 “함께하는 팀“에 더 우선 순위를 둬야한다고 본다. 함께하는 과정을 통해 함께 결과를 만들기 위해 노력하는 것이다. 그리고 그 연장선에서 “리딩하는 팀“에 조직의 방향과 부합하는 방향을 제시할 수 있어야 한다.
협력과 협업을 “팀“으로써 수행할 때 우리는 더 높은 더 먼 미션을 달성할 수 있기 때문이다. 우리가 오늘만 사는 것이 아니라면 꿈꾸는 것을 이루기 위한 여정은 계속된다. 그리고 그 여정에서 의미있는 목표점을 회사라는 조직, 그리고 구성원들과 협업을 통해 만들어내는 성취 역시 인생이라는 여정을 통한 최고의 경험일 것이다.
어느새 쏘카에서의 시간이 만 1년이 됐다. 제대로 일할 수 있는 기술 조직을 만들어보겠다는 생각으로 “본사”로 이직을 했던 것이 얼마 안된 것 같은데 벌써 시간이 이만큼 지나갔다. 개인적으로도 큰 변화의 시기였고, 쏘카의 기술 조직도 그만큼의 변화의 시간을 함께 관통하고 있다.
일하는 방법부터 시작해서 조직개편, 그리고 새로운 아키텍처 를 적용하는 여정까지 하루하루가 다이나믹하게 지나갔다. 그럼에도 1년이 지난 지금까지도 아침에 일어났을 때 “출근해야지” 라는 생각이 머리속에 떠오르는 첫번째 생각인걸 보면 여전히 한 일보다는 해야할 일들이 쏘카에서는 더 많다.
쏘카는 내가 합류하던 시점에 10주년 기념식을 준비하고 있었다. “타다” 서비스의 영향이었을까? 하지만 스타트업이라는 생각이 더 들었다. 대표이사를 포함한 구성원들이 젊었고, 이루고 하는 것들이 중견 기업의 그것보다는 스타트업에 더 가깝기 때문이지 않았을까 싶다.
First day of SOCAR
개발 본부 사람들을 만나 처음 이야기했을 때 하고 싶은 것들에 대한 열망과 현재의 피로가 함께 느껴졌다. 개발을 하고 싶다. 제대로 서비스를 만들고 싶다. 엔지니어들이 원하는 것들에서 느껴진 공통점은 본인들의 업에 충실하게 제대로 일하기였다. 하지만 현실의 그들은 레거시 시스템을 벗어나지 못한 상태에서 많은 숫자의 일에 함몰되어 있었다. 요구받은 과제를 완성했지만, 지식은 쌓이지 못했다. 보람은 있지만, 자산이 되질 못했다. 개발보다는 일하는 시스템이 먼저 필요했다.
쎌(Cell)이라는 개발 방식이 운영되고 있었다. 과제 완성을 위해 필요한 PM, Engineer, QA 직군 분들이 하나의 세포처럼 유기적으로 협력하는 체계이다. 멋진 개념이긴 하지만 이 근간을 움직이는 핵심이 기획서였다. 왜 “기획서(혹은 문서)”일까? 함께 협업하는 사람이 드러나지 않았다.
시스템 이전의 시스템
일하는 시스템은 앞으로 현재 서비스 시스템을 넘어 “이동”을 담아내기 위한 새로운 서비스 개발을 위한 선행 조건이다.
합류 직후 두달동안 개발 혹은 관련된 분들을 인터뷰했다. “열망”과 “피로”를 투지와 성과로 만들 수 있는 방안을 고민했다. 그 결과로 개발 조직을 목적 조직화와 데모 중심의 스프린트 체계를 도입시켰다.
버킷(Bucket)이라는 목적 조직
목적 조직(Domain) 체계는 조직의 과제가 “남이 시킨 하는 일”이 아닌 “나의 일”이 되도록 하기 때문이다. 스스로 일의 주체가 됐을 때 흥이 난다. 최소한 덜 괴롭다. 업무 도메인의 개발 주체가 누군지가 알려지면 자연스럽게 소통이 풀린다. 업무 영역과 관련된 궁금증이 있다면 바로 찾아갈 수 있으니까.
물론 익숙치 않은 분들은 길찾는데 좀 걸릴 수 있다. 헤매는 불편함이 있지만 길을 찾아드리지 않는다. 가이드를 드리고 스스로 찾아오시길 부탁한다. 목적 조직이 목적 조직이 되기 위해서는 안에 있는 사람뿐만 아니라 도메인을 함께하는 조직 밖의 분들도 동일한 이해 선상에 있어야 하기 때문이다.
스프린트 – 100m 전속력으로 421.95번하기
프로젝트 방식이 아닌 데모 중심의 스프린트 방식으로 변경의 핵심은 업무에 대한 주기성을 갖도록 하는데 있다. 각 조직이 정의한 1주, 2주, 3주 단위 스프린트를 통해 결과를 만들어내기 위한 몰입 시간을 정의한다. 그리고 비즈니스 파트너들과도 이 주기를 통해 이야기해줄 것을 요청했다. 날짜 중심의 배포가 아니라 스프린트 중심의 배포가 될 수 있도록.
2022년 1월부터 진행된 조직 개편과 서비스 엔지니어링 본부의 바뀐 일하는 방식이 실행되어 지금 11월에 이르렀다. 우당탕탕의 시기였다. 하지만 TL(Tech Leader)/팀장님들을 주축으로 이 변화를 위해 다 같이 도전하고 있다. 또한 전사적으로 이 변화를 위해 기다려주었고, 응원해주고 있다. 그리고 함께 다 같이 하고 있다.
현상 유지? 변화를 향해 도전?
변화의 주체는 구성원들이었다. 어찌보면 변화를 원했고, 갈망했었던 딱 그 시점에 CTO님과 내가 있었다고 생각한다. 네이버와 라이엇에서도 해보지 못한 경험을 이곳 쏘카에서 제대로 할 수 있는 기회을 선사해준 동료들에게 감사할 따름이다.
이 방식이 최선이고 정답이라는 섣부른 생각은 안한다. 환경은 변화할 것이고 그 변화에 최선을 다할 수 있도록 우리 스스로도 언제든 익숙함을 떠나야 한다. 하지만 1월부터 지금까지의 과정을 봤을 때 11년의 젊은 쏘카 구성원들과 해낼 수 있을 것 같다는 생각이다.
아마도 사회 생활을 시작한 직후부터 사람을 뽑는 역할을 했던 것 같다. 정말 뭣도 모르는 상태에서 사람을 보기 시작했던 것 같다. 지금 돌이켜보면 좀 어이없다.
잘 몰랐던 소기업 시절
사실 벤처/스타트업 혹은 작은 중소 기업에게는 지원자가 지원해주는 것만으로도 감지덕지였다. 인터뷰를 통해 사람을 거른다는 것이 의미가 거의 없긴 했다. 당시에 Java, C++, Visual C++ 가지고 개발해야 했기 때문에 언어랑 도구를 사용할 줄 아는지 정도만 체크해도 충분했던 시절이었다.
질문은 안할 수 없어서… 주어진 코드를 보고 Class Diagram을 그릴 수 있는지 여부 정도? 불행히도 이 문제를 통과한 사람이 두명인가로 기억한다. 좀 써먹다가 넘 어려웠다는 걸 인정하고 포기했다. 이 질문은 내가 면접에서 사용하는 질문으로 살아남았다. 주니어에게도 시니어에게도 유용하다는건 참…
대기업, 네이버.
네이버로 옮긴 이후에도 어찌어찌해서 시니어 대상 면접관을 하게 됐다. 네이버에 지원하는 시니어들을 내가 평가해도 되나 싶긴 했지만… 영광이라고 생각했다. 기술 역량만 평가하면 된다는 이야기를 들었다. 면접은 2인 1조로 들어갔다. 네이버는 큰 회사다. 첫번째 면접에서 면접관으로 동행하는 분 역시 처음 얼굴보는 분이었다. 질문을 나눠 해야할 것 같아, 면접자분과 역할을 어떻게 나눌지 이야기를 나눠봤다. “각자 알아서 질문하자.“라는 쿨한 답을 받았다. 뭐… 잘 아는 사이도 아니니. 걍 알아서 하는 걸로. 이후에 몇번 면접을 같이 들어갔던것 같다. 변화가 있긴 했는데… 그때도 항상 내 말이 많았던 것 같다. (가물가물)
지원자에 대해 한시간 정도는 공부하고 면접에 들어간다. 지원자를 역량 평가할려면, 공부하는 건 당연하다. 이력서 읽어보는 걸로 퉁치기에는 좀… 적어도 경력과 무관한 쌩뚱맞은 질문을 던지면 안된다. 소중한 시간을 쪼개서 지원해준 지원자에 대한 예의가 아니니.
사실 내가 네이버 채용에 기여한 바는 거의 없는 것 같다. 기억상 거의 대부분 불합격 의견을 냈던 것 같다. 네이버 면접 에피소드 하나 이야기하면, 네이버 입사하기 이전 회사에서 프리랜서로 계약하고 먹튀한 학벌 좋은 친구를 면접장에서 만났다. 어디서 이름이 많이 익다 싶었는데 얼굴 보고 알았다. 허락없이 외장 하드에 복사해놓은 다른 회사 소스 코드를 당당히 본인의 자산이라고 이야기했던 분. 3개월 계약 기간동안 얼굴 편하게 비치다가 결과를 달라니 잠수타버린. 와중에 잔금을 주면 준다길래(뭔 양아치짓!) 보내줬더니 돌아온 건 쓰레기 코드였다.
제 얼굴 기억 안나냐고 여쭤봤더니 모르겠다길래 찬찬히 기억을 상기시켜드렸다. ㅋ X씹은 표정으로 앉아있던 그분 표정이 지금도 생각난다. 세상 좁다. 인생 그렇게 살면 안된다.
요즘은 네이버의 채용이 많이 바뀌었을 것 같다. 대부분 CIC 체계로 변경되서 각자 체계이기 때문에 대기업스러움보다는 되려 스타트업스러움이 더 강하지 않을까?
외국계 회사는…
라이엇으로 이직한 이후에는 입사 직후부터 바로 면접관을 했다. 막 입사한 이후부터 면접관 역할을 했기 때문에 역시 이래도 되나 싶긴 했다. 그래도 라이엇에서는 면접관별 차이가 결과에 미치는 영향을 최소화하기 위해 노력했다. 간단하게나마 문제 Pool에 대해 고민하는 미팅도 가졌으니. 그럼에도 코드 좀 짜면 면접관으로 들어가는 관행을 바꾸기에는 여력이 부족했다. 개발자가 넘 적었으니.
한번은 미국 출장 중에 본사 친구가 인터뷰 일정이 있다고 했다. 오후에 다시 만났을 때 후기와 본사의 Interviewer Training Program에 대해 물어봤다. 아주 나이스하진 않지만, 1년에 한 두번 Talent팀이 진행하는 공식 프로그램과, 각 팀 단위의 On-boarding 과정이 있다는 것이었다. 오호… 역시 본사!
나중에 본사 프로그램이 제대로 셋업된 걸 알았고, 희망하면 참여할 수 있다는 것도 알았다. 하지만 영어로 진행하는 프로그램에 굳이… 채용 TO도 없는데… 그리고 영어. 영어로 말해야 하는 외국 회사는 그래서 신중히 생각해야한다.
본사, 쏘카.
쏘카로 이직 후 가장 먼저 살펴본 부분이 채용쪽이었다. 프로세스 몇 가지 부분들의 변화가 필요했고, 변화를 실행할려면 어느 정도의 면접관들이 필요했다. 우선 내부에서 시니어들 위주로 면접관 풀을 구성했고, 이전의 경험과 면접관으로 참여할 의사를 확인했다. 간단히 면접 과정에서 하면 안되는(?) 것들 위주로만 교육했다. 이후에 코딩 테스트, 과제 중심으로 면접 과정을 정비하고 그 가운데 틀을 만들어갔다. 면접관들이 의지가 있으니 자연스러운 쏘카다운 면접 프레임이 잡혔갔다. 이건 좀 놀랍다. 더구나 현재 진행형이라는게 더욱 놀랍다!! 감놔라 대추놔라 시시콜콜 간섭하지 않았는데도 감이 열리고 대추가 매달린 느낌? (아재개그 잘 하고 싶은 욕망이 있는데… 안되는가부다.)
그럼에도 아쉬운 부분은 “본사”에서 진행하는 공식 프로그램이었다. 당장은 시니어들이 적극적이었기 때문에 잘 운영이 되고 있지만… 장기적으로는 쏘카 기술의 표상이 될 교육받은 면접관들이 적정 규모로 있어야 한다. 이 분들을 위한 교육 프로그램이 있었으면 했다.
지원자분들이 늘어남에 따라 기존 면접관 풀이 느끼는 피로도가 쌓였다. 신규 면접관에 대한 필요가 생겼고, 기존 면접관들이 신입 면접관들을 리드할만큼 기량이 쌓였다는 것도 나름 확신하게 됐다. 부담을 낮출 필요가 있지만, 지원자가 어떤 면접관을 만나느냐는 운빨이 평가로 작용하면 안된다. 면접관의 코드 역량은 신뢰할 수 있지만 평가를 따라갈 수 있는 가이드가 있어야 했다. 이걸 통해 일관성이 있어야 한다.
“본사” 공식 프로그램을 해볼 때인가!!!
꿈은 뭔가 대단한 것 같긴 했지만, 구체화해보니 “뻔하네!, 애매하네?!” 라는 생각이 들게 되긴 했다. 없는 것보다는 낫다라는 생각에 프로그램을 진행했다.
쏘카의 엔지니어 인재상 – 면접에서 찾아야 할 쏘카 엔지니어 인재상을 확인
프로그래머(엔지니어)로 산다는 것 – 엔지니어로써 가져야 할 철학과 비전
면접은 어떻게? – 전반적인 인터뷰 절차와 단계별(1차, 2차) 인터뷰에서 다뤄지는 내용
기술 인터뷰 How-to – 기술 인터뷰 과정에서 주의깊게 살펴야 할 부분들
인터뷰 에티켓– 인터뷰 진행 필수 매너
면접 문제 풀이 – 코딩 테스트 및 화이트보드 코딩 모의 실전
프로그램의 처음 시작은 우리는 누구이고, 어떤 동료와 함께 할 것인가에 대한 상을 맞췄다. 물론 계속 우리가 원하는 엔지니어의 모습을 맞추긴 했지만, 그럼에도 사람을 뽑는 역할이기 때문에 쏘카의 인재상을 한번 더 맞췄다.
다음으로 면접의 기술이다. 원하는 엔지니어어 역량을 지원자가 갖췄는지 살펴보기 위한 기술들을 공유한다. 사실 정답은 없다. 이 방법을 찾는 것도 본인들만의 노하우이고. 다만 본인들의 노하우 발견을 위한 첫걸음이 되길 바란 뿐이다. 다음으로 역할극. 지원자 입장에서 면접 질문을 풀어보는 것이다. 면접 질문이 합당한지, 그 과정에서 지원자와 면접관이 어떤 방식으로 질문과 대화를 통해 상호작용을 할지를 경험해본다.
물론 이 과정 마친 다음에 가볍게 한잔했다. 결국 새로운 면접관들도 하나의 팀이 되어야 한다. 팀 플레이 잘 할려면 서로를 좀 더 알아야 하기 때문이다. 우리는 아직 성장회사라서 잘 알고 있었고, 앞으로도 이 관계를 잘 유지할 수 있을 것 같다.
다음은?
성장하는 조직에서 핵심적인 역할을 맡아줄 사람들은 리더들이다. 기존 리더들이 역시 잘 해주고 있지만, 새로운 리더들이 나타나야하고 외부에서 좋은 리더분들을 모셔야 한다. 이 분들이 쏘카의 미래를 함게 공유하고 팀 구성원들을 위한 쏘카의 방향성을 제시하는 것이 중요하다.
지난 번에 반가운 이야기 두가지를 들었다. 두 이야기 모두 쏘카의 기술 1차 인터뷰에 대한 피드백이었다.
첫번째 이야기.
쏘카 기술 인터뷰 과정에서 진행하는 화이트보드 인터뷰가 너무 좋아 현재 재직중인 회사에 도입하셨다는 것이다. 쏘카에서 중니어 및 시니어 면접은 온라인 코딩 테스트(문제 풀이)를 하지 않는다. 대신 코드와 기술 구조를 정의할 수 있는 살펴보기 위해 화이트보드를 사용한다. 경험했던 구조를 설명을 위한 그림으로 그려낼 수 있는지, 설명할 수 있는지 살펴본다. 그리고 간단한 문제를 제시하고, 스스로 조건을 정의해서 자신이 가장 익숙한 코드로 풀어내길 요청한다. 면접관과 지원자 사이에 많은 인터랙션(서로 주고받기)는 필수다. 설명하고, 질문하고, 그림 그리고, 적는다. 토론 방식으로 진행한다.
면접관들은 토론 진행 과정을 통해, 지원자분의 기술적인 역량이 우리가 필요한 역량에 부합하는지 살핀다. 동료와의 협업과 주니어의 성장을 도와줄 수 있는지도 마찬가지로 중요한 포인트다. 이 과정을 면접관들이 꼼꼼히 기록한다. 이것이 다음 단계의 면접과 평가를 위한 기초가 된다.
화이트보드 코딩 테스트를 우리만 하는 건 아닐 것이다. 다만 우리의 방식은 면접관 분들의 많은 시간 투자가 필요하다. 면접 자체도 1시간 반에서 길게는 2시간까지 이어진다. 물론 지원자를 파악하기 위해 들어가는 사전 한 두시간은 필수다.
이 경험을 벤치마킹 해주셨다는것에 감사하다는 이야기를 꼭 전하고 싶다.
두번째 이야기.
지원자분이 1차 인터뷰에서 탈락했다. 1차 인터뷰 결과는 몇 페이지 분량으로 기록된다. 1차 기술 인터뷰 탈락자분께서 원하시면 피드백을 전달드린다. 지원자분이 우리 기대와 달랐던 부분이 어느 부분들이었는지, 발전을 위해 보완되면 좋을 부분들을 채용 담당자가 메일이나 전화로 연락드린다.
이 분께도 채용 담당자분이 정리된 자료를 바탕으로 전화로 지원자분께 탈락 결과를 말씀드렸다. 보통은 이렇게 절차가 마무리된다. 그런데 지원자분이 주니어로 다시 지원 의사를 밝혔다. 경력이 4년 이상인 분이 경력 포기나 다름없는 주니어 포지션으로 지원하다니?
면접 진행했던 분께 여쭤보니 2시간 정도 면접을 진행했고, 지원자의 역량을 파악하기 위해 많은 대화가 오갔다고 전해줬다. 과정이 지원자분께 성장할 수 있는 회사라는 경험을 준 것 같다. 바로 다음 차수의 주니어 온라인 코딩 테스트부터 진행하는 것으로 지원자분께 전달했다.
쏘카에 와서 아마 가장 먼저 손을 대고, 과정을 계속 살펴보는 부분이 면접 프로세스이다. 쏘카는 성장을 원하고, 또 해야한다. 이를 실현할려면 인재들이 필요하고, 쏘카의 성장과 어울릴 수 있는 사람인지를 평가할 수 있는 체계가 있어야 한다. 그렇기 때문에 우리의 인재상은 무엇인지 그 인재상에 도달하기 위해서 어떤 과정을 구성원들이 거치게 될지를 이야기한다.
오늘, 이 두가지 경험은 채용의 핵심에 있는 쏘카 서비스 개발 조직의 인터뷰 담당자들이 제대로 하고 있음을 증명한다. 감사하고 고마운 일이다. 개인의 성장을 통해 조직의 성장을 추구하는 일. 성장하는 쏘카는 현재는 이 방향성을 추구한다. 그리고 많은 분들의 노력 덕분에 우리는 현재 진행중이다.
추가로 이 채용 인터뷰 방식과 프로세스, 더욱 널리 퍼졌으면 좋겠다. 다른 회사에도 마찬가지로 정답이 될 수 있을지 없을지 모른다. 하지만 벤치마크 대상은 될 수 있지 않을까? 그럼 스스로에게 가장 적합한 방법을 찾을 수 있을테니. 이 과정을 통해 우리 나라에서도 제대로 된 채용 인터뷰가 정착되지 않을까? 기술쟁이로써의 첫걸음이 여기서부터 시작이라면 한국의 개발 문화가 쫌 제대로 동작하기 위한 첫걸음에 보탬이 될 수는 있을지도 모르겠다.
담소 자리에서 술자리에서 티셔츠 이야기를 자주 많이 이야기했다. 엔지니어분들이 컨퍼런스와 같은 행사에서 가장 값어치있게 여기는 구즈(Goods)는 티셔츠다. 티셔츠에 새겨진 회사, 기술, 사상의 브랜드 혹은 가치를 엔지니어들은 공감할수록 가장 긴 줄이 몰린다. 더해 공감 수치가 높아지면 높아질수록 일상복으로 거리에서 회사에서 개발자, 엔지니어로써 당당해진다.
기술 기업으로 쏘카를 생각했을 때 아쉬웠던 부분이 바로 “티셔츠”였다. 쏘카는 기술 기반의 차량 공유 서비스의 앞도적인 선두 주자로 이동을 다시 디자인하고 있다. 특히 ML/AI 분야에서는 빅데이터를 어떻게 현실의 Business에 접목할 수 있을지를 실제로 보여주고 있다. 이런 기술적인 자부심을 내보여줄 보여줄 현재 시점의 티셔츠가 없다는 것이 아쉬웠다.
이런 아쉬움, 이번에 채웠다.
짜잔!
기술 기업으로의 쏘카 아이덴티티(Identity)를 표현하는 것을 나만 좋아하는 것 같지는 않다. 다들 좋아해주시는 것 같아서 추진한 사람들 가운데 한명으로 기분좋다.
덕분에 제작 리드하신 분이 의도치 않은 사이드 이펙트로 많은 슬랙 DM에 시달리고 있으시다는…
쏘카는 기술 기업이다.
지금까지 기술을 기반으로 차량 공유 서비스를 발전시켰고, 이를 넘어 “이동을 정의“하기 위한 기술 개발과 다양한 서비스를 만들 예정이다. 이에 더해 그동안 쏘카가 축적한 차량 이동 기술을 활용해 물류와 운송 효율화를 위한 새로운 서비스도 준비중에 있다. 새롭고 누구도 가보지 못한 여정이다. 사업적인 목표를 기술로 풀어야 하는 “도전적“인 목표다.
물론 장미빛 미래만 있는 것은 아니다. 이 여정은 1년 반짝 한다고 완성할 수 있는 목표가 아닌 긴 호흡이 필요한 길이다. 우리는 많은 기술 부채를 가지고 있다는 것을 인정한다. 가시밭이다. 누군가는 빈 캔버스에서 자신만의 그림을 그리고 싶다고 이야기한다. 하지만 쏘카라는 캔버스는 빈 공간이 아니다. 11년 가까이 구성원들의 헌신이 이미 그 캔버스를 채우고 있다. 그 헌신을 바탕으로 우리는 강렬한 붉은 빛의 장미꽃을 이 캔버스에 멋지게 그려내야 한다.
구성원들이 “기술 기업, 쏘카“라는 명화를 함께 그려낼 수 있도록 도와주고, 함께 고민해주는 역할이 리더인 내가 해야할 일이 아닌가 싶다.
To Be Continued!
쏘카 테크의 도전은 쉼없이 계속될 예정이다. 새로운 기술을 도입하고, 기술 부채를 정리하고, 우리가 어떻게 일하고 성장하는 것이 가장 한국적인 기술 조직일지 고민하고 고민한다. 이 고민이 올해안에만 머무르지 않을 것이기 때문에 2022이라는 숫자를 넣었다. 그렇기 때문에 내년, 내후년에 새겨질 2023, 2024가 더욱 기대된다면 오버일까? ㅎㅎ
자율(Autonomy)이라고 이야기를 했지만… 사실 꼬치꼬치 “이렇게 하세요, 저렇게 하세요!”라는 각론에 대한 지시를 싫어한다. 개인적인 성격이다. 목적지만 정해지면 그리로 가면 되는거지. 부산가는데 꼭 천안, 대전, 대구를 거쳐갈 필요는 없다. 하지만 왕왕 천안, 대전, 대구에 목숨거시는 분들이 있더라. 모로가도 부산만 가면 된다.
포장하자면 자율적으로 일하는 방식을 좋아한다. 자율적 방식은 나의 혹은 확장하면 팀의 방식으로 일을 계획하고 진행하고 마무리하는 것이다. 어찌되었든 “일”이라는 것은 있다. 그리고 일의 종착지는 결과다. 결과를 만드는 것이 우리의 몫이라면 과정은 진행하는 사람들이 정할 수 있어야 한다.
과정이 실제 흘러갈려면 그 선택에 대한 인정 혹은 존중이 있어야 한다. 과정이 성공을 보장하지는 않는다. 다만 그 과정이 물 흐르는 것처럼 자연스럽길 원한다. 물론 대부분 장애물을 만나서 굽이치고, 심지어 몇십미터 폭포를 지난다. 이런 경험을 거치다면 보면 자연스러움이 과정에 스며들 것이다. 그래서 자연스러워질 것이다.
물론 인위적인 시스템으로 만들어진 물길도 있다. 사람이 만든 운하같은 물길처럼. 운하의 물길은 쭉 뻗어있다. 물론 이것이 가능한 이유는 이를 움직이는 체계 혹은 시스템이 있기 때문이다. 이런 물길은 만들어야 한다. 누구나 짐작하듯이 정말 큰 비용이 들어간다.
자율, 어렵다.
우리는 일을 한다. 그리고 일의 과정이 빠르게 결과를 만들어내길 기대한다. 성공이든 실패든. 이 “과정”이 자연스럽고 막힘없이 흘러간다면 인정하고 존중할 수 있다. 이것이 자율이라고 나는 생각한다.
물론 자율적으로 일한다는게 말처럼 되는 건 아니다. 언제나 어디서나 장애물은 존재한다. 장애물을 만났을 때 우리는 “결정”을 해야한다. 사실 우리의 성장 과정이나 교육 시스템은 스스로 결정을 많이 허용하지 않았다. 혹은 스스로 결정하지 않아도 원하는 결과를 얻을 수 있기 때문에. 이런 환경에서 성장한 사람들에게 스스로 결정해서 일을 하라는 건 말 그대로 도전이다.
이런 이유로 많은 사람들이 사전에 정해진 규칙을 요구한다. 혹자는 이 상황을 즐겁게 받아들이는 반면 “짜여진 시스템이 없는데 어떻게 일을 하라는 말이냐!” 라고 반문하는 분들도 많다. 특히 이런 분들 가운데 다수는 결정뒤에 따라올 미지의 결과를 상상하는 것 자체를 고통스러워한다. 물론 이런 분들을 위한 시스템을 만들 수 있다. 하지만 사람을 움직이는 시스템은 운하와 같은 물길과는 다르다. 생각하는 존재인 사람은 물과 같지 않기 때문이다. 때문에 시스템은 완벽할 수 없고, 그 체계 안에서도 우왕좌왕하기 일쑤다.
이런 고통을 극복한다고 하더라도 결정의 범위가 개인의 역량을 넘어서는 경우가 왕왕 있다. 사실 “결정한다 = 책임진다” 라고 생각한다. 조직에서 구성원 개인이 책임질 수 있는 범위는 매우 매우 제한된다. 본인이 “너가 뭔데?” 라는 질문에 당황할 수 밖에 없는데… 이때 필요한 것이 리더다.
그래서 리더는
자율 조직에서의 리더는 방향을 제시하고, 그 방향에 맞춰 구성원들이 각자가 필요한 결정을 내리도록 돕는다. 결정과 예상되는 결과에 대해서도 조언한다. 그리고 구성원의 결정을 존중하고 이를 지지해주며 최종적으로는 이를 책임진다. 이는 리더의 경험과 지혜에서 발현되는 것이다. 리더는 지식이 필요하지만 지식이 리더를 만드는 것이 아닌 이유다.
이 과정에서 리더는 결정을 돕는 사람이어야 한다. 구성원이 스스로 내린 결정하고, 스스로 책임감을 가지고 결과를 만들기 위해 행동하는 것. 이래야 구성원은 내적 동기를 가지고 행동할 수 있고, 스스로 만들어낸 결과는 스스로의 자부심을 배가시킬 수 있다.
물론 결정은 쉬운 일이 아니기 때문에 충분한 정보가 필요하다. 리더는 구성원이 충분히 정보에 접근할 수 있도록 하고, 필요한 적정 수준의 정보를 제공한다. 과도한 정보는 오히려 독이 되므로 넘치지 않도록 관리해야 한다. 이를 통해 도출된 결정이 어느 정도 합리성이 있다면 이를 존중하고, 실행될 수 있도록 뒤받침을 하면 된다. 성공은 결정하고 실행한 구성원의 몫으로, 실패는 리더가 책임진다. 이런 모습이 아름답다.
결정은 항상 누구에게나 어렵다. 대부분 이 결정을 위해 많은 신중한 토론이 있다. 리더는 이 과정을 잘 관찰해야 한다. 사람 사이의 토론은 결론없이 공회전하는 경우가 많다. 이 경우에는 합리적인 방안을 리더가 참여자들을 대신해서 결정할 수 있다. 충분한 시간의 논의와 의견 교환이 있었다면 결정을 내려야하고, 리더가 결정한다. 리더의 결정은 존중받아야 하고, 실행되어야 한다.
자율 기반의 조직이니 당연히 참여자들간의 토론을 통해 결정되어야 하는 것이 아니냐는 이야기를 듣는다. 좋은 지적이지만 토론만 하고 있을 수 없다. 우리는 결정 이후에 이어지는 실행이라는 시간을 거쳐야한다. 실행 시간 역시 결과를 결정짓는 중요한 요소다. 이 전반의 상황과 진행을 관리하는 것이 리더의 역할(권한)이고 책임이다.
간혹 자율 기반 조직에서 모두가 평등하기 때문에 동의할 수 없다고 이야기하는 사람도 있다. 예를 들어 자신이 주장이 합의된(혹은 리더가 결정한) 의견이 고객 가치에 반한다며 수긍하지 않는 경우가 있다. 예시이긴 하지만 딱 고객 가치를 무기화(Weaponize)하는 경우다.
정말 본인의 주장이 옳다고 생각한다면? 모든 조직에는 체계가 있다. 상위 리더에게 이야기하면 된다. 다만 이 주장이 조직 체계를 통해 납득되기 전까지는 리더의 의견을 존중해야 한다.
자율적이면 빨라질까?
자율적으로 의사 결정하고, 일이 진행되면 정말 빨리 진행될 것이라고 생각하나? 정말??
사실 일이 빨리 진행되는 조직은 군대가 아닐까? 왜? 지시가 위에서 떨어지고, 떨어진 지시를 실행하면 되는 조직이 군대이기 때문이다. 이 조직에서 지시에 대한 반문은 (거의)없다. 하지만 우리가 군인은 아니니까.
우리는 결정을 해야한다. 혼자 하는 결정이라도 생각을 해야한다. 우리는 호모사피엔스니까. 하물며 팀이 결정해야 하는 경우라면, 결과로 도출해야할 “가치”를 어떻게 실행할지 결정하는 과정에서 적절한 토론과 논쟁은 필연적이다. 시간은 필수다.
하지만 이 과정을 거쳐 자율에 대한 의미가 조직 전반에 공감되면… 그때 소위 속도가 나온다.
“자율적”이 되는 건 매우 어려운 도전이다. 토론과 논쟁도 어렵고, 이것들이 학습이라는 과정을 통해 내재화되어야 한다. 또한 시간은 매우 큰 변수다. “자율적”인것에 대한 기대감이 주는 중압감도 매우 크다. 시간이라는 변수와 함께. 따라서 조직의 합의와 함께 리더십으로부터의 지원이 필요하다.
자율 조직을 일단 정의했고, 실행중이다. 과연 이 결론이 이 그래프의 상향점을 향할지는… 현재 진행형을 완성형으로 만들기 위해서는 다 방면의 투자가 더 필요하다. 가보자!
