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분을 남기고 투입되기도 한다. 이 부분은 팀플레이어로써 팀의 판단에 의해 이뤄진다. 하지만 가장 중요한 점은 “게임에 뛸 역량을 갖추고 있는가”이다. 경기를 뛰지 못하는 건 분명 프로에게는 치명적이다.

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

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

– 끝 –

팀장님은 어느 팀 소속인가요?

Posted by on

팀장의 팀은 어느 팀인가?

어처구니 없는 질문 같지만 팀장 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년

Posted by on

어느새 쏘카에서의 시간이 만 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년의 젊은 쏘카 구성원들과 해낼 수 있을 것 같다는 생각이다.

출근이 기다려진다.

면접관(면접하는 사람)을 위한 교육

Posted by on

아마도 사회 생활을 시작한 직후부터 사람을 뽑는 역할을 했던 것 같다. 정말 뭣도 모르는 상태에서 사람을 보기 시작했던 것 같다. 지금 돌이켜보면 좀 어이없다.

 

잘 몰랐던 소기업 시절

사실 벤처/스타트업 혹은 작은 중소 기업에게는 지원자가 지원해주는 것만으로도 감지덕지였다. 인터뷰를 통해 사람을 거른다는 것이 의미가 거의 없긴 했다. 당시에 Java, C++, Visual C++ 가지고 개발해야 했기 때문에 언어랑 도구를 사용할 줄 아는지 정도만 체크해도 충분했던 시절이었다.

질문은 안할 수 없어서… 주어진 코드를 보고 Class Diagram을 그릴 수 있는지 여부 정도? 불행히도 이 문제를 통과한 사람이 두명인가로 기억한다. 좀 써먹다가 넘 어려웠다는 걸 인정하고 포기했다. 이 질문은 내가 면접에서 사용하는 질문으로 살아남았다. 주니어에게도 시니어에게도 유용하다는건 참…

 

대기업, 네이버.

네이버로 옮긴 이후에도 어찌어찌해서 시니어 대상 면접관을 하게 됐다. 네이버에 지원하는 시니어들을 내가 평가해도 되나 싶긴 했지만… 영광이라고 생각했다. 기술 역량만 평가하면 된다는 이야기를 들었다. 면접은 2인 1조로 들어갔다. 네이버는 큰 회사다. 첫번째 면접에서 면접관으로 동행하는 분 역시 처음 얼굴보는 분이었다. 질문을 나눠 해야할 것 같아, 면접자분과 역할을 어떻게 나눌지 이야기를 나눠봤다. “각자 알아서 질문하자.“라는 쿨한 답을 받았다. 뭐… 잘 아는 사이도 아니니. 걍 알아서 하는 걸로. 이후에 몇번 면접을 같이 들어갔던것 같다. 변화가 있긴 했는데… 그때도 항상 내 말이 많았던 것 같다. (가물가물)

지원자에 대해 한시간 정도는 공부하고 면접에 들어간다. 지원자를 역량 평가할려면, 공부하는 건 당연하다. 이력서 읽어보는 걸로 퉁치기에는 좀… 적어도 경력과 무관한 쌩뚱맞은 질문을 던지면 안된다. 소중한 시간을 쪼개서 지원해준 지원자에 대한 예의가 아니니.

사실 내가 네이버 채용에 기여한 바는 거의 없는 것 같다. 기억상 거의 대부분 불합격 의견을 냈던 것 같다. 네이버 면접 에피소드 하나 이야기하면, 네이버 입사하기 이전 회사에서 프리랜서로 계약하고 먹튀한 학벌 좋은 친구를 면접장에서 만났다. 어디서 이름이 많이 익다 싶었는데 얼굴 보고 알았다. 허락없이 외장 하드에 복사해놓은 다른 회사 소스 코드를 당당히 본인의 자산이라고 이야기했던 분.  3개월 계약 기간동안 얼굴 편하게 비치다가 결과를 달라니 잠수타버린. 와중에 잔금을 주면 준다길래(뭔 양아치짓!) 보내줬더니 돌아온 건 쓰레기 코드였다.

제 얼굴 기억 안나냐고 여쭤봤더니 모르겠다길래 찬찬히 기억을 상기시켜드렸다. ㅋ  X씹은 표정으로 앉아있던 그분 표정이 지금도 생각난다. 세상 좁다. 인생 그렇게 살면 안된다.

 

요즘은 네이버의 채용이 많이 바뀌었을 것 같다. 대부분 CIC 체계로 변경되서 각자 체계이기 때문에 대기업스러움보다는 되려 스타트업스러움이 더 강하지 않을까?

 

외국계 회사는…

라이엇으로 이직한 이후에는 입사 직후부터 바로 면접관을 했다. 막 입사한 이후부터 면접관 역할을 했기 때문에 역시 이래도 되나 싶긴 했다. 그래도 라이엇에서는 면접관별 차이가 결과에 미치는 영향을 최소화하기 위해 노력했다. 간단하게나마 문제 Pool에 대해 고민하는 미팅도 가졌으니. 그럼에도 코드 좀 짜면 면접관으로 들어가는 관행을 바꾸기에는 여력이 부족했다. 개발자가 넘 적었으니.

한번은 미국 출장 중에 본사 친구가 인터뷰 일정이 있다고 했다. 오후에 다시 만났을 때 후기와 본사의 Interviewer Training Program에 대해 물어봤다. 아주 나이스하진 않지만, 1년에 한 두번 Talent팀이 진행하는 공식 프로그램과, 각 팀 단위의 On-boarding 과정이 있다는 것이었다. 오호… 역시 본사!

나중에 본사 프로그램이 제대로 셋업된 걸 알았고, 희망하면 참여할 수 있다는 것도 알았다. 하지만 영어로 진행하는 프로그램에 굳이… 채용 TO도 없는데… 그리고 영어. 영어로 말해야 하는 외국 회사는 그래서 신중히 생각해야한다.

 

본사, 쏘카.

쏘카로 이직 후 가장 먼저 살펴본 부분이 채용쪽이었다. 프로세스 몇 가지 부분들의 변화가 필요했고, 변화를 실행할려면 어느 정도의 면접관들이 필요했다. 우선 내부에서 시니어들 위주로 면접관 풀을 구성했고, 이전의 경험과 면접관으로 참여할 의사를 확인했다. 간단히 면접 과정에서 하면 안되는(?) 것들 위주로만 교육했다. 이후에 코딩 테스트, 과제 중심으로 면접 과정을 정비하고 그 가운데 틀을 만들어갔다. 면접관들이 의지가 있으니 자연스러운 쏘카다운 면접 프레임이 잡혔갔다. 이건 좀 놀랍다. 더구나 현재 진행형이라는게 더욱 놀랍다!! 감놔라 대추놔라 시시콜콜 간섭하지 않았는데도 감이 열리고 대추가 매달린 느낌? (아재개그 잘 하고 싶은 욕망이 있는데… 안되는가부다.)

그럼에도 아쉬운 부분은 “본사”에서 진행하는 공식 프로그램이었다. 당장은 시니어들이 적극적이었기 때문에 잘 운영이 되고 있지만… 장기적으로는 쏘카 기술의 표상이 될 교육받은 면접관들이 적정 규모로 있어야 한다. 이 분들을 위한 교육 프로그램이 있었으면 했다.

지원자분들이 늘어남에 따라 기존 면접관 풀이 느끼는 피로도가 쌓였다. 신규 면접관에 대한 필요가 생겼고, 기존 면접관들이 신입 면접관들을 리드할만큼 기량이 쌓였다는 것도 나름 확신하게 됐다. 부담을 낮출 필요가 있지만, 지원자가 어떤 면접관을 만나느냐는 운빨이 평가로 작용하면 안된다. 면접관의 코드 역량은 신뢰할 수 있지만 평가를 따라갈 수 있는 가이드가 있어야 했다. 이걸 통해 일관성이 있어야 한다.

“본사” 공식 프로그램을 해볼 때인가!!!

꿈은 뭔가 대단한 것 같긴 했지만, 구체화해보니 “뻔하네!, 애매하네?!” 라는 생각이 들게 되긴 했다. 없는 것보다는 낫다라는 생각에 프로그램을 진행했다.

  • 쏘카의 엔지니어 인재상 – 면접에서 찾아야 할 쏘카 엔지니어 인재상을 확인
  • 프로그래머(엔지니어)로 산다는 것 – 엔지니어로써 가져야 할 철학과 비전
  • 면접은 어떻게? – 전반적인 인터뷰 절차와 단계별(1차, 2차) 인터뷰에서 다뤄지는 내용
  • 기술 인터뷰 How-to – 기술 인터뷰 과정에서 주의깊게 살펴야 할 부분들
  • 인터뷰 에티켓– 인터뷰 진행 필수 매너
  • 면접 문제 풀이 – 코딩 테스트 및 화이트보드 코딩 모의 실전

프로그램의 처음 시작은 우리는 누구이고, 어떤 동료와 함께 할 것인가에 대한 상을 맞췄다. 물론 계속 우리가 원하는 엔지니어의 모습을 맞추긴 했지만, 그럼에도 사람을 뽑는 역할이기 때문에 쏘카의 인재상을 한번 더 맞췄다.

다음으로 면접의 기술이다. 원하는 엔지니어어 역량을 지원자가 갖췄는지 살펴보기 위한  기술들을 공유한다. 사실 정답은 없다. 이 방법을 찾는 것도 본인들만의 노하우이고. 다만 본인들의 노하우 발견을 위한 첫걸음이 되길 바란 뿐이다. 다음으로 역할극. 지원자 입장에서 면접 질문을 풀어보는 것이다. 면접 질문이 합당한지, 그 과정에서 지원자와 면접관이 어떤 방식으로 질문과 대화를 통해 상호작용을 할지를 경험해본다.

물론 이 과정 마친 다음에 가볍게 한잔했다. 결국 새로운 면접관들도 하나의 팀이 되어야 한다. 팀 플레이 잘 할려면 서로를 좀 더 알아야 하기 때문이다. 우리는 아직 성장회사라서 잘 알고 있었고, 앞으로도 이 관계를 잘 유지할 수 있을 것 같다.

다음은?

성장하는 조직에서 핵심적인 역할을 맡아줄 사람들은 리더들이다. 기존 리더들이 역시 잘 해주고 있지만, 새로운 리더들이 나타나야하고 외부에서 좋은 리더분들을 모셔야 한다. 이 분들이 쏘카의 미래를 함게 공유하고 팀 구성원들을 위한 쏘카의 방향성을 제시하는 것이 중요하다.

다음 “본사”의 교육은 리더십이다!

가자~~