AMA와 Anonymous 질문

리더는 의사 결정하고 구성원과 소통해야 한다. 스스로도 소통의 필요를 느껴 작년 6월부터 AAA(Ask Anakin Anything) 세션을 진행해오고 있다. 무엇이든 리더가 듣는게 중요하기에 구성원이 목소리를 내도록 무기명(Anonymous) 질문을 받았다. 말해야 들을 수 있고, 들어야 회사나 조직의 운영에 반영시킬 수 있기 때문이다.

무기명 질문의 임팩트는 대단했다. 첫 AAA 60분 시간에 100개가 넘는 무기명 질문이 들어왔다. 최선을 다해 질문들에 대해 답했다. 거친 시기를 지나고 있었기 때문에 말 그대로 질문도 거칠었다. 뾰족한 답을 주기 어려운 질문들도 있었고, 말꼬리 잡기도 있었다. 본부 수준을 넘어선 회사 정책이나 방향에 대한 질문은 즉답을 주기 어려웠다. 일부분은 경영진과 상의 후에 결과를 만들기도 했지만 그 자리에서 “됩니다.” 혹은 “해결하겠습니다.” 라는 속 시원한 답을 주지 못헀다. 그러다보니 이후에도 AAA 세션에서 Anonymous로 거친 질문이 이어졌다.

무기명 질문에 대해 우려의 시선이 적지 않았다. 욕 먹을게 뻔한데 구태여 AAA를 해야하는지, 적어도 무기명 질문을 없애야 한다는 의견도 있었다. 사실 현타가 왔던 적이 몇 번 있었다. 그럼에도 불구하고 필요하고 지금까지 계속 하는 이유는 변함없다. 듣기 위해서. 추측이 아닌 불만 그 자체, 그리고 강도를 알아야 한다. 비난이라 하더라도 구성원이 이걸 표현하는 건 회사와 조직을 생각한다는 증거다. 최악은 아무 질문도 없는 것이다.

무기명 질문에 대해서는 나름 기대치가 있다. 언젠가는 구성원들이 Anonymous가 아닌 본인 이름으로 질문하지 않을까? 본인들이 자신 이름을 걸고 질문해도 될 만큼의 심리적인 안정이 아닌 안전을 느끼는 시점을 생각한다. 조직장이라는 계급이 만든 수직 구조에서는 많이 이야기하는 수평적 커뮤니케이션을 기대하기 힘들다. 일반 직급 직원 입장에서는 “안전(Safety)”하다고 스스로 느껴야 안전한 것이다. 괜찮다고 오라고 해봐야 그럴 수 없기 때문에 다가가야 하고, 다가가는 역할은 리더의 큰 몫이라 생각한다.

그리고 이번 달 진행한 AAA 세션에서 무기명 질문이 딱 1개 였다. 물론 5분 전체 공유 사항이 “교육”에 대한 내용이었기 때문에 민감도가 낮은 것도 이유라고 생각한다. 그럼에도 각자가 자신의 이름으로 질문을 해준 것에 고맙고 감사하다.

작년 말과 올해 1, 2월에 걸친 AAA 세션에서 질문의 방향과 강도에 대한 일부 변화가 느껴졌다. 전반적으로 무기명 질문이 감소했고 질문의 방향 역시 건설적이었다.

다만 절대적인 질문 수가 주는 건 개인적으로 아쉽다. 해결되지 않는 질문 해봐야 의미없다라는 구성원들의 생각이 있기 때문일거라고 추측은 해본다. 이 부분은 이래저래 아쉬운 부분이다.

조직은 고착화되면 안된다. 지금을 움직이는 정의된 프로세스가 있어야 한다. 그리고 변화하는 환경 요소들이 입력되어 다음 단계의 프로세스가 등장해야 한다. 리더를 포함한 조직 구성원들의 소통이 정체되는 순간 프로세스의 발전은 멈추고 조직이 일하는 역동성 역시 그 지점에 멈춘다. 아직 쏘카는 정체기를 추구하기에는 더 큰 성장이 필요하다. 더 큰 성장을 이루기 위해서라도, 리더인 나도 소통의 장을 열기 위한 노력을 멈추면 안된다. 다짐이다.

– 끝 –

ps. 김영한님을 모셔보려 했으나, 일단 불발. 하지만 구성원들이 원하시니 기회는 계속 찾아보는 것으로.

리더십 단상

본인이 아무리 능력 좋아도 본인이 실행할게 아니면 결정자가 아닌 조언자가 되어야 한다. 실제 일하는 사람이 내가 아니라면 “나라면 말이지…” 라는 표현은 함부로 할 말이 아니다. 설령 내가 그 사람의 상관이라도 마찬가지다. 그저 관리(Management)를 하면 된다. 낭떠러지로 떨어지지 않게 가드레일 수준의 관리일지 아니면 자전거가 넘어지지 않게 뒤에서 잡아주는 마이크로 방식일지만 정하면 된다. 마이크로 매니징을 하더라도 결국엔 내 손을 자전거에서 놔야 하는 것처럼 스스로 일을 진행할 수 있어야 한다.

섣부른 혹은 지나친 관리는 되려 관리받는 사람을 망친다. 넘어지는게 걱정되서 그런다면 그냥 빨리 넘어지게 두자. 넘어져 무릎이 깨지고, 손이 까져봐야 자전거도 타게 된다. 빨리 실패하고 툭툭 털고 일어날 수 있도록만 응원해주면 된다. 그렇다고 코가 깨지면 아예 자전거 안탈 수 있으니 이건 조심하자.

나를 타인에게 주입하지말고 그냥 이해하기만 해도 좋다. 공감까지라면 최선이겠지만, 사실 공감 매우 어렵다. 주변에 말을 들어볼려고 하지도 않고 비교하고 탓하면서 공감 운운하는 사람 여럿 봤지만 공감 아니다. 대부분 들어주는 것만으로도 충분하고, 그 때의 그 사람을 기억해주기만 하자. 그리고 지나는 길에 “요즘은 어때요?” 라는 질문이면 충분할 것 같다.

리더는 실행해서 완결짓는 사람이고, 그래서 점 못찍으면 본인 잘못 인정해야 한다. 여전히 열심히 하고 있다는 끝나지 않는 무한 진행형은 리더로써 할 이야기가 아니다. 마침이 있는 일정을 가지고 있고, 동료들에게 지도를 가지고 설명해야 한다. 험난한 과정은 항상 있는 것이고, 숨기면 안된다. 그리고 함께 헤쳐나가는 동료들에게 감사와 존중의 마음을 표현해야 한다. 그러나 결과 만드는데 동참못하고 이상이 이렇네 저렇네 떠드는 구성원은 가능한 빨리 배제해야 한다. 썩을 가능성이 높거나 이미 썪었을 수 있다.

리더십 교육을 매번 신임 리더들에게 해주고 있지만, 언제나 이론과 실제는 다르다. 아프지만 현실이다. 그리고 현실은 언제나 가장 바쁠때 제대로 체감하는 것 같다.

 

2024년에 대한 짧은 생각

2023년을 바쁘게 보내고 나니 어느새 2024년이다. 많은 일이 있었고, 개발 조직을 넘어 이일 저일에 관여하며 정말 바쁜 한해를 보냈다. 그리고 2024년을 쏘카의 또다른 도전에 함께하며 스스로 기대치를 정리해본다. 내년 이 맘때에 한 해를 돌아보고 만족감으로 이 글을 다시 읽었으면 하는 바램이다.

  • 거칠었던 2023년
  • 도전을 성장으로. 그리고 쏘카의 엔지니어 인재상
  • 쏘카2.0 – 더 큰 도약을 위한 기초 공사
  • 사람 그 자체로의 사람
  • 리더

쏘카는 상장 이후 수익성을 담보하기 위해 노력하던 중 2023년 중반 급격한 변침을 했다. 예측하기 힘든 시장 상황이라 기존 시스템의 효율을 높이고, 안정성을 우선했지만 격랑의 환경에서 쏘카의 가치를 입증하기에 충분치 않음을 자각했다. “자유롭고 행복한 이동을 실현하기 위해 과연 우리는 어떤 방향성을 가져야 할까?”의 답을 탐색하는 여러 시도를 바탕으로 “쏘카 2.0″을 추진하기로 결정했다.

 

거칠었던 2023년

2023년에 얼마나 거칠었을까? CPO님이 정리한 프로젝트 자료를 토대로 진행한 프로젝트 수를 분기별로 세어봤다.

새로운 탐색을 시작한 2분기부터 확실히 진행하고 완료한 프로젝트 건수가 늘었다. 덕분에 쏘카2.0의 방향성을 수립할 수 있었다. 또한 쏘카 엔지니어링 조직의 근육도 이전에 비해 더 탄탄해졌다.

도전을 성장으로. 그리고 쏘카의 엔지니어 인재상

숫자는 쏘카 엔지니어링 조직 역량이 발전하고 있음을 말한다. 확신없던 기대가 얼추 맞아 들어 기뻤다. 이정도 탄탄함이라면 쏘카의 더 큰 가능성을 꿈꿔볼 수 있다는 자신감이 들었다.

기대 이상으로 발전한 역량의 원동력은 구성원 자신이다. 각자가 쓰나미 같이 다가오는 과제를 단순히 일이 아니라 도전 목표로 받아들이고, 본인의 가치 실현 계기로 활용했기 때문이다. 대다수의 엔지니어 분들이 우리가 추구하는 바를 “문화(Culture)”로 생각하고 있다는 행복 회로를 돌려본다. 절대적인 시간이 필요한 순간에 야근과 특근으로 본인 시간을 희생해준 “투지”가 결과를 만들어냈다.(ps1)

물론 구성원 혼자만의 노력으로 된 건 아니다. 앞에서 땡겨주고, 뒤에서 밀어준 혹은 좌절하고 있는 어깨를 토닥여준 리드(팀장 혹은 TL)들이 있다. 리드들이 보여준 헌신에 깊은 감사를 표한다. 일이 되게 만든 1등 공신일 뿐만 아니라 주니어들이 그 이상의 몫을 해낼 수 있는 환경을 만들었기 때문이다. “실패의 책임은 구성원이 아닌 리드가 진다.“라는 조직의 모토를 적극 수용해줬다. 덕분에 방어적인, 실패가 두려워 한 발자국도 안 움직이는 복지부동 조직이 아니라 넘어져도 툭툭 털고 일어날 수 있는 조직이 됐다.

이 과정에서 고민하고 신경을 쓴 부분은 인재상이다. 인재상에 맞춰 구성원들이 움직이고 있는가? 혹은 인재상에 구성원들이 스스로 능력을 맞춰 갈 수 있을까? 그리고 구성원이 적극적으로 호응했을 때 구성원의 업(커리어 – Career) 관점에서 도움이 될까?

단순한 바램은 구성원들이 시간을 그저 흘러가도록 내버려두지 않았으면 한다. S/W 엔지니어로써 그 시간만큼 혹은 그 이상 발전을 기대한다. 투자다. 그리고 쏘카의 일원인 동안에는 적어도 인재상의 상승 곡선을 타고 올라갈 수 있는(혹은 그 이상이 될 수 있는) 기회를 제공하고 싶다. 일을 강요가 아닌 기회로 도전하고, 역량 발전이라는 값어치를 얻는 환경을 만드는 것이 리더십의 역할이 아닐까 싶다. 이것이 구성원과 쏘카 모두 함께 성장하는 길이다.

쏘카2.0 – 더 큰 도약을 위한 기초 공사

가능한 많은 기회가 있었으면 한다. 이 관점에서 쏘카의 2024년은 많은 도전 과제가 있다. 그리고 그 중심에는 “쏘카 2.0“이 있다. (관련 기사) 쏘카 2.0의 핵심은 단기 카셰어링과 플랜(월 단위 차량 대여)를 통해 차량 운영 효율을 극대화시켜 차량 가치(LTV – Life Time Value)를 높이고, 스테이를 포함한 여러 이동 서비스를 여정 플랫폼으로 담아내 고객 가치를 높이는 두 축을 완성하는데 있다. 쏘카가 가장 잘하고 있는 카셰어링의 장점을 극대화하고, 이동 수단으로써 차량을 포함한 고객의 여정을 쏘카를 통해 이야기하려 한다. 2026년까지 쏘카가 실현할 전략이다.

간략히 표현했지만 그림에 담긴 여러 의미 요소들을 완성하는 것은 만만치 않다. 쏘카의 차량 운영 시스템은 견고하게 현재를 지탱하고 있다. 그리고 2.0 전략의 성공 여부는 쏘카의 카셰어링이 지렛대로써 얼마만큼 효과를 발휘할 수 있는지에 달렸다. 더 큰 효과 발휘를 위해서는 효율성을 지금보다 끌어올려야 한다. 차량 LTV 증가는 규모의 경제를 실현함과 동시에 차량 운영 과정의 불편 요소들을 얼마나 개선할 수 있는가에 달렸다. 특히 차(Vehicle)라는 실물의 품질 담보는 정말 어렵다. 그만큼 도메인 자체가 어렵기 때문에 이해와 합의 과정이 담보되야 한다. 소통(Communication)이 엔지니어링을 통한 현장 중심, 사람 중심의 운영 효율화를 만드는 핵심이다.

쏘카 10주년을 통해 천명한 스트리밍 모빌리티는 고객 이동을 끊김없이 연결하겠다는 선언이다. 이어 2022년부터 KTX를 시작으로, 스테이(Stay – 쏘카스테이)와 쏘클(전기자전거)로 이동 서비스를 확장했다. 이미 쏘카는 차량 데이터를 기반으로 “이동”에 관련된 국내 최대 데이터를 보유하고 있고, 이를 바탕으로 고객 여정의 지점과 지점을 확장된 서비스로 연결하길 희망한다. 여기에 더해 축적된 데이터는 선택을 돕는 수단이 될 것이다. 고객은 여정을 쏘카안에서 즐겁게 계획하고 실행할 수 있어야 한다. 또한 즐거움이 가격뿐만 아니라 편리함과 편안함이길 기대한다.

KTX – 쏘카 – 스테이(숙박)“를 이용하면서 가성비를 체감하긴 했지만 아직 서비스로써 편리함과 편안함을 만족시키기 위해서는 더 많은 노력이 필요함을 느꼈다. 고객 여정을 서비스를 통해 담아낼 수 있어야 하고, 이동 플랫폼을 통해 다양한 이동(혹은 휴식) 수단을 최소한의 수고를 통해 고객에게 전달해야 한다.  엔지니어링 역량으로 달성해야 할 지점이다.

여정을 서비스로 이용하는 고객으로부터 “편리하다.“는 이야기를 듣고 싶다. 다양한 꺼리를 통해 “재미있다.“는 이야기 역시 듣고 싶다. 당장은 욕심이겠지만 쏘카 2.0을 완성하는 2026년까지는 이 맥락을 완성해야 하는 것이 나를 포함한 쏘카 엔지니어링 조직이 달성해야 할 목표이다.

사람 그 자체로의 사람

사실 하나하나가 쉽지 않다. 제대로 된 엔지니어링 관점의 구현은 더욱 도전적이다. 매우!!! 이걸 해내기 위해서는 모두의 헌신과 노력이 필요하다. 시간이 필요한 순간에는 야근해야 하고, 그보다 더 시간이 필요하면 주말 근무를 해야 필요한 곳에 점을 찍을 수 있다.(ps1) 라이브(Live – Production Release)라는 완결점이 찍히지 않았다면 아무리 많은 노력을 쏟았더라도 의미를 상실한다. 그렇기 때문에 완결점은 구성원들에 의해 찍혀야 한다는 점을 올해도 강조할 것이다.

완결점을 찍는 당사자들 역시 참여하는 구성원들이다. 마찬가지로 서비스를 기획하고 만들어가는 역할 역시 참여하는 구성원 모두의 몫이다. 완결점이 어떤 모습일지, 시작하는 지금엔 알 수 없다. 고객 가치를 최우선으로 놓고, 어떤 형식의 마침표가 합당한지 치열한 고민과 도전을 통해 형상화해야 한다. 서비스 엔지니어링에서 마침표는 끝이 아닌 시작이고, 쉼표이다. 이 지점에서 다음 항해는 어디로 떠날지 다시 한 번 고개들고 살펴보자.(ps2)

노력하는 쏘카의 구성원 역시 사람이다. 사람이 사람과 만나 조직으로 일을 하고 성취를 만든다. 이 와중에 기대하는 바는 도파민이 아닌 세로토닌을 통해 행복감을 구성원들이 느끼길 바란다. 함께 우리가 만든 서비스를 즐겁게 이용하는 고객님을 보고 싶다. 그렇기 때문에도 일의 의미가 중요하다. 단순히 “님들이 이 일을 해야 합니다.”가 아닌 쏘카 2.0 맥락을 모두 같은 선상에서 이해하는 것이 중요하다. 그래야 참여가 이뤄질 수 있다. 헌신과 노력을 이야기했지만 스스로 참여에 의한 것이 아니라면 돈을 받고 하는 노동에 불과하다. 세로토닌이 주된 호르몬이 되려면 의미와 가치를 함께 공유하는 것이 우선이어야 하고, 어찌보면 이것이 리더십의 일이 아닐까 싶다.

올해 입사한 갓 신입 직원부터 지난 2년을 거치면서 잘 성장해준 주니어 엔지니어, 이들을 뒷받침하면서 앞으로 나아가도록 돕는 TL과 팀장이 있다. 최종적으로 나와 함께 그룹장들이 엔지니어링 본부를 구성하고 있다. 재미있게 일을 하면 좋지만, 언제나 세상 좋은 이야기만 있을 수 없다.

쓴소리 전에 사람을 사람으로 알아야 한다고 종종 이야기한다. 그 사람이 겪는 어려움이 업무와 관련된 문제일 수 있지만 그 너머의 다른 곳에 이유가 있을 수 있다. 회사라는 공간에 모인 사람들이 업무를 통해 결과를 만들기 위해 집중해야 한다. 하지만 사람이 집중하지 못하는 이유는 수도 없다.단순히 집중하지 못하거나 성과를 내지 못하는 것만으로 쓴소리가 합리화 되지 않는다. 사람을 알아야 한다.

사람을 알았다면 상사와 동료의 이야기가 쓴소리 대신 피드백이 될 수 있다. 발전과 동기 부여의 이야기가 될 수 있다. 본부장인 나 역시 팀장/TL들에게 피드백을 주기도, 받기도 한다. 특히 올해 한 팀장으로 받은 피드백은 나 스스로를 곱씹게 만들었고, 발전의 기회를 제공했다. 함께 일하는 동료이기 때문에 알아야 하고, 이해와 공감을 바탕에 둔 피드백은 사람을 발전하게 만든다.

리더

쏘카에서 내 역할은 리더다. 본부 내부 교육 세션등을 통해 리더의 역할은 “방향”을 제시하는 것이라고 이야기한다. 구성원들에게 방향을 이야기 전에 먼저 가늠해야한다. 때문에 지도(Map)가 필요하다. 최대한 맞는 지도를 그려야 하기 때문에 가능한 높은 곳에서 멀리 봐야 한다. 무엇보다도 목표 지점이 뒷산 꼭대기인지 아니면 알프스를 넘어야만 하는지 알아야 한다. 내가 가지고 있는 장비와 물자가 무엇이고 얼마만큼인지 알아야 한다. 현재의 우리 현실을 기반으로 평가한 제약 사항과 위험 요소들을 현실직시해야 돌아갈지 뚫고 지나갈지 판단할 수 있다. 방향과 지도가 준비됐다면 이제 경로를 잡는다.(선택한다.) 움직이기 시작하면 조직이 지도상에서 어디쯤인지 수시로 확인해야 한다.

엔지니어링 본부의 OKR과 Milestones 문서가 방향과 경로가 포함된 지도가 되길 희망한다. 당연하게도 지도가 100% 맞다고 확신할 수 없다. 뭔 일이 자꾸 터지니… 그럼에도 현실 덤블을 헤쳐나가면서 우리의 지향하는 방향과 위치가 합당하게 쏘카 2.0을 향해 나아가고 있는지를 알 수 있게 하리라. 그래야 실무에서 움직이는 여러 팀의 노력이 합쳐져 올바른 결과를 만들어 낼 수 있으니 말이다.

– 끝 –

ps1. 쏘카는 일정 시간을 넘어서는 야근과 주말 특근에 대해 대체 휴일을 통해 쉼을 보장하는 제도를 갖추고 있다. 물론 최선을 다하는 것에 변함이 없지만, 쉼 역시 쏘카의 중요한 가치임에는 변함없다.

ps2. 서비스는 중단없는 연속이다. 그렇기 때문에 리듬이 필요하고 서비스 개발에서 마침표는 이 리듬감을 완성한다고 생각한다. 일을 하는데 있어서 리듬감의 필요에 대한 생각을 링크의 글에서 정리해뒀었다.

쏘카의 흔한 일하는 모습

쏘카 사무실 공간의 특별한 요소는 벽을 가득 채운 화이트보드다. 빈 공간의 대부분이 화이트보드다. 처음 이 공간을 접했던 때의 느낌은?

멋지다!!!!!!!

이 공간이 더욱 멋진 이유는 단순히 장식용 화이트보드가 아니라 보드를 가득 채우고 있던 고민의 흔적들이었다. 난무하는 선, 도형, 숫자, 등등. 그래서 더욱 Cool! 했던 것 같다.

요즘 흔하게 보고 있는 일하는 모습이다. 짧게 혹은 길게 이야기를 나눈다. 그림 그려가며 설명도 하고 토론도 하고 경청(?)도 한다. 회의실이 아니니 예약할 필요도 없다. 먼저 찜하는 사람이 임자다. 커피들고 지나가다 내려놓고 이야기를 할 수도 있다. 특히 이 복도 공간은 요즘 핫하다.

열린 공간이기 때문에 소리의 제약이 있고, 복도이기 때문에 지나가는 사람들이 수시로 있다. 누군가에게 들려도 개의치 않고, 누군가에게 보여도 개의치 않는다. 함께 논의하고 의견을 나누는 모습이 일상화 되어 좋다. 덕분에 지나가다 툭툭 대화에 끼어들기도 한다. 민폐같기도?

물론 다름을 원하는 구성원분들도 있을 수 있다. 소음이고 본인 집중을 방해하는 이유가 되기 때문이다. 통행 방해는 물론이다. 그럼에도 이해와 배려하는 마음이 있어 아직 큰 불만이 표출된 적은 없다. (굳이 찾아보지는 않았지만… 없을 것 같다.)

엔데믹, 재택 종료와 사무실 출근

4월부터 재택 종료하고 사무실을 주 업무 공간으로 사용하기 시작했다. 온라인 공간에서 주로 소통하는 “우리”가 사무실(Office)라는 오프라인 공간에서 어떤 소통 방식을 찾을지 궁금했다. 그 방식은 지시에 의해 만들어지는 것이 아니라 구성원 스스로 찾아내고 자연스런 일상이 모습이어야 한다. 하라고 해서 되는게 아니다.

요즘 느낌은 사무실이라는 공간에서 어떻게 소통할지 나름의 방법을 스스로 찾아가고 정착되는 것 같다. 공간이 풍요로운 것도 아니고, 급한 회의 진행을 위해 양해(양보)를 구하는 슬랙 메시지도 종종 본다. 그럼에도 소통하기 위한 방법과 현실에 대한 배려를 보여주는 모습이 고맙다.

팀 자리에서 의자 돌려 스크럼 진행하고, 옆 팀에서 들리는 목소리에 개의치 않는다. 회의실 밖에까지 들리던 목소리가 팀 자리에서는 조곤조곤해진다. 물론 헤드셋을 하고 배경 음악을 깔고 있는 시간이 늘어나는 건 어쩔 수 없다. 사무실에서 이어폰은 여러모로 감수해야 한다. 그리고 이것 역시 다른 동료를 위한 배려라는 생각이 든다.

사무실에서 짧은 이야기가 많다. 커피를 내리면서 서울숲의 단풍과 갑자기 추워진 날씨 이야기를 나눈다. 속썩이던 고3 아이가 무사히 수능 치뤘는지도 나눈다. 면접 이야기, 여행 이야기, 어제 술자리 이야기 등등. 사무실이라는 공간에서 이뤄지는 많은, 짧은 이야기를 통해 우리는(적어도 나는 ^^;) 동료들을 알게 되고 이해할 수 있게 된다.

일하는 공간 변화를 통해 얻고자 했던 부분은 “소통과 협업“이었다. 그리고 구성원들이 쏘카의 일하는 방식을 자율적으로 만들어가고 있다. 일하는 문화의 방향을 리더가 제시할 수 있어도 결국 문화 자체를 완성하는 몫은 구성원 스스로에게 있다. 그 관점에서 정말 구성원 분들이 대단하다고 생각되고 감사하고 고맙다.

– 끝 –

주말 특근을 승인하지 않습니다.

2023년 3분기를 시작하면서 작심하고 본부에 공지한 내용이다.

앞으로 장애 대응을 제외한 일체의 주말(휴일 포함) 특근을 승인하지 않을 예정입니다.

2분기는 짧은 기간에 많은 일을 해내야만 했다. 늦은 밤은 물론이고, 주말까지 일을 해서 완성시켰다. 많은 일들이 완성된 건 구성원들의 공감, 집중, 헌신이 있었기 때문이다. 야근과 주말 특근 없이 일하는 쏘카의 모습이 좋았고, 나 스스로 유지하기 위해 노력했지만 이번에는 그 반대 방식으로 일해야 한다고 내가 이야기했다.

희생한 개인 시간에 일부 보상을 더해 대체 휴가를 부여하기로 전사 방침을 정했다. 대신 본부 구성원들에게 이번 부여된 대체 휴가는 8월 , 늦어도 9월까지는 모두 소진시켜달라고 팀장들에게 당부했다. 그리고 3분기 시작 직전에 주말 특근을 허용하지 않는다는 공지를 했다. 물론 이는 내가 담당하는 SE(Service Engineering) 본부만의 방침으로 쏘카의 모든 조직에 해당 하지는 않는다. 당연히 냉탕과 온탕을 오가는 조직장의 태도 변화를 구성원들이 곱게 받아들일리 없었다.

하반기가 되었다고 일의 양이 줄지는 않는다. 우리가 만드는 건 서비스다. 이동 플랫폼으로써 제대로 된 발걸음을 막 시작했기 때문에 새로운 시도와 확장은 당연하다. 플랫폼을 만들고 이를 유지할려면 쏘카 나름의 일하는 방식이 있어야 한다. 서비스를 빠르게 만든 2분기의 경험은 개인과 조직에게 그동안 쌓아온 역량의 최대치가 얼마인지 확인할 수 있는 기회였다. 그리고 쏘카라는 조직 관점에서 우리가 얼마나 해낼 수 있을지 그 속도를 가늠해 볼 수 있었다. “함께 리듬감있게 일하자!“라는 일하는 방식이 나온 배경이다.

리듬을 갖기 위해서는 레파토리(Repertoire)가 필요하고, 레파토리를 완성하기 위해서는 필연적으로 쉼(Break)이 필요하다. 리듬감있게 일한다는 관점에서 우리는 쉼을 먼 곳에서 찾을 필요가 없다. 나의 쉼은 가족과 함께 쉬는 것이어야 하고 일의 관점에서 동료의 쉼이어야 한다. 그 가운데 특히 주말 시간은 업무(일)과 분리된 시간이 되어야 한다.

숙련도는 쉽게 말해 일을 다루는 요령이다. 일에 진심이라면 요령은 효율성이고 시간 활용 능력이다. 시간을 잘 활용하기 위해서는 나에게 주어진 시간의 총량을 염두에 둬야 한다. 일반적으로 하루 8시간, 주간 5일이 물리적인 총량이다.

총량을 넘어 추가 시간이 필요한 경우 야근 혹은 특근을 한다. 나는 이를 “빌려”쓰는 시간이라고 생각한다. 지금의 내가 필요한 시간을 미래의 나에게서 빌리는 것이다. 내일 업무를 위해 충전할 시간을 당장의 업무에 쓰면 내일의 내가 피해를 본다. 패턴이 반복되면 피로는 누적되고 일에 대한 집중은 기대할 수 없다. 실수를 포함해 업무 품질을 이야기하기 어려워지기 마련이다.

쏘카의 이동 서비스 확장과 고도화 의지를 생각하면 시간이 부족하다. 일이 되게 만들려면 부족한 시간을 빌려야 한다. 주말 특근을 허용하지 않는다는 선언은 빌리는 시간을 주중으로 한정한다는 것이다. 돌려말하지 않고, 시간이 더 필요하면 야근하라는 것이다.

일에 아무리 좋은 미사여구를 붙혀도 일은 일이다. 일에 최선을 다했다면 야근을 했던 안했던 피곤은 피할 수 없다. 누적된 피로를 그나마 회복할 수 있는 주말과 휴일마저 매몰시키고 싶은 생각이 없다. 나 스스로도 일을 떠나 잡초를 뽑거나 낚시하면서 머리를 비운다. 못읽은 책을 읽으면서 몇 년 후 내 모습은 어떤 모습일까를 그려보기도 한다. 그리고 다시 시작하는 일상에서 업무에 집중하고 결과를 만든다. 추상적 리듬이 아닌 물리적 리듬이 여기에 있다. 이 리듬이 깨지면 몸이 망가지기 십상이다.

주변에서 몰입(flow)라는 단어가 심심치 않게 들린다. 특히 시간 총량을 넘어선 일을 하고 있거나 해야할 때! 우리는 풀리지 않는 문제를 풀기 위해서 무작정 잡고 있는 것을 몰입이라고 하지 않는다. 문제를 풀다보니 자기도 모르는 사이에 시간이 흘렀을 때를 “몰입의 시간“이라고 부른다. 그리고 이 몰입의 시간은 재미의 시간이다. 이 경험 자체가 즐겁고 재미있다. 이 재미에 누군가가 보상을 이야기하면 그 다음부터는 노동이 된다. 업무로써 몰입할 수 있는 기회를 가지는게 최선이다. 항상 이럴 수 없기 때문에 시간 관리가 필요하다. 그래서 시간의 흐름을 맺고 끊는 방법을 알아야 한다.

개인의 인생이라는 긴 여정에서 시간은 무엇보다도 중요하다. 특히 직업(Career)의 범주에서 전문가의 첫 걸음은 시간을 효율적으로 사용하는 것이다. 본인에게 주어진 24시간은 개인의 (역량을 키우는) 시간이고, 그 가운데 8시간은 일을 통해 역량을 실현시키는 시간이다.  그리고 쉼은 전진하기 위한 윤활유 역할이다. 윤활유없이 달리는 엔진은 터지기 마련이고, 우리는 이걸 번아웃이라고 부른다.

인생은 길지만 시간은 유한하다. 몰입이라는 단어에 현혹되지 말았으면 한다. 쉼을 통해 계획하고 실행하는 방안을 통해 점진적으로 성장하는 모습을 스스로 찾는 것이 개인도, 조직에도 가장 유효하다고 본다.

특근 승인을 하지 않는다고 선언한 이후에도 종종 주말에도 일의 시간을 위해 개인의 시간을 희생하는 구성원분들이 있는 것을 알고 있다. 이상이 아무리 고귀해도 현실을 무시하면 완전 헛소리에 지나지 않는다는 것도 알고 있다. 딜레마다. 그럼에도 불구하고 이를 정책(Policy)로 유지하는 이유는 분명하다. 일과 쉼이 뒤섞이면 결국 조직의 지속 가능성은 구성원의 자발적/비자발적 이탈로 유지될 수 없다고 생각하기 때문이다. 번아웃이라는 단어가 급부상한 이유가 있다.

– 끝 –

협업의 속도를 위한 경계

상반기의 업무 방식이 과감하게 도전하기(Be Bold)라면, 하반기의 일하는 방식은 “함께 리듬감있게 일하기“로 이야기하고 있다. 상반기엔 구성원 모두가 정말 과감하게 도전했고 기대 이상의 성과들을 만들었다. 말이 쉽지 개개인의 희생과 노력없이 도전은 이뤄질 수 없다. 그만큼 피로가 쌓일 수 밖에 없기에, 이 방식은 지속 가능한 업무 형태로 적합하지 않다. 이에 대한 고민을 아래와 같은 방식으로 정리해봤다.

  1. 리듬감있게 일하기
  2. 한번에 되는 일은 없다!
  3. 되풀이하지 않기
  4. 현실은 멀티플(Multiple)

 

리듬감있게 일하기

지속 가능성을 염두에 뒀을 때, 상반기 과감한 흐름이 조직의 DNA로 이어질 수 있는 방안을 생각했다. 고민을 바탕으로 하반기 일하는 핵심 키워드로 “함께”와 “리듬감”을 뽑았다.

“함께”라는 단어는 알겠지만, “리듬감”은 뭘 말하는지 모르겠다는 질문이 많았다. 보통 리듬은 일정하게 반복되는 주기성 혹은 패턴을 의미한다. 우리는 스프린트 방식(2~3주 단위의 반복적 개발 방식)으로 일한다. 팀의 역량(Capacity)에 따라 일정 양(Volume)의 일을 반복한다. 자연스럽게 리듬있게 일하고 있는거 아닌가? 하지만 음악에도 변주가 있듯이 스프린트 그 기간 안에서 벌어지는 일의 양과 성격이 매번 다를 수 밖에 없다.

그럼에도 리듬감있게 일하기 위해 가장 필요한 것은 실행의 단위를 갖는 것이다. 이미 스프린트가 있기 때문에 이 스프린트가 명시적으로 유지되어야 한다. 2주 혹은 3주 단위의 스프린트 단위로 함께하는 동료 혹은 팀들이 의식적으로 일을 진행해야 한다. “새로운 요구 사항이 계속 나오고, 2~3일마다 배포하고 있는데 스프린트가 무슨 의미가 있냐?” 라는 질문 할 수 있다. 이런식으로 라이브 배포를 하고 있으면 스프린트의 의미가 없다….

이런 이야기까지 나오는 건 계획(Planning)할 수 없기 때문이다. 예측할 수 있다면, 적어도 스프린트에 할 일을 구체화하고 실행할 수 있지 않을까? 물론 예측 못한 일들이 마구 나온다는건 분명 잘못된 시그널이다. 방향과 지도 없이 헤메고 있을 가능성이 높다. 바로 잡으려면 방향을 잡고, 우리가 알고 있는 지식과 경험으로 지도를 그려야 한다. 높은 산꼭대기가 아니더라도 언덕 위에 올라가면 하루, 이틀의 길을 예측할 수 있다. 거기부터 시작해야 한다. 예측을 시작해야 무엇에 집중할지 결정할 수 있게 된다. 그럼 스프린트에 진짜로 뭘 만들어야할지 제대로 알게 된다. 2~3일마다 배포해서 얻는 결과보다 더 큰 가치를 타켓팅할 수 있게 된다.

2023년의 시장 환경은 한 분기 단위의 예측성 조차 보장하기 힘들만큼 급변했던 것 같다. 상반기를 어렵게 넘겼지만, 하반기 역시 녹록하지 않다. 그럼에도 “리듬감있게 일하자!”라는 배경에는 리더로서 최소한 2개 혹은 그 이상 스프린트의 예측성을 각 개발팀에 보장해주기 위함이다. 당장 시작할 다음 스프린트를 예측할 수 있다면, 개발을 담당하는 각자는 플래닝을 통해 코딩에 집중할 시간을 가질 수 있지 않을까 싶다. 물론 이 정도 스프린트의 시간으로 일이 완성되지 않는다. 과정은 반복되고, 서비스는 답이 정해진 게임이 아니다.

한번에 되는 일은 없다!

완결된 목표는 한번 “으쌰!”한다고 완성되지 않는다. “무엇을 만들자!“가 선언되고, 제품/기능/서비스로 실체화 되는데 시간이 걸린다. 특히 명제가 갖는 가치와 무게가 높고 무거울수록 더 많은 시간이 필요하다. 완성되기 전까지 우리는 “무엇”의 완벽한 실체를 알 수 없다. 그래서 우리는 점진적인 완성을 향해가는 개발 방법론을 사용한다.

시간에 따른 점진적인 완성이 동작하기 위해서는 소통이 있어야 한다. 우리가 파악한 정보는 무엇이며, 이를 바탕으로 검증할 대상을 정해야 한다. 정해진 대상을 스프린트를 통해 구체화시키고 데모를 통해 확인한다. 결과물은 나아갈 방향을 검증하고, 새롭게 정보가 추가된다. 그리고 다음 스프린트에서 최종 목표를 위해 뾰족하게 할 내용을 정의한다. 이 반복을 통해 우리는 목표(Goal)를 향해 차근차근 다가간다. 그리고 충분히 고객과(End User)과 관련자(Stakeholder)를 만족시킬 수 있다는 판단이 들 때 우리는 출시(Release)를 통해 “무엇“의 가치가 실체화되는지 확인한다.

적절한 수준의 정보가 있어야 스프린트를 제대로 진행할 수 있다. 음식은 너무 날 것이라도 문제를 일으키지만 너무 삭아도 안된다. 스프린트를 위한 정보 역시 마찬가지다. 참여자가 충분히 해석하고 공감할 수준이면 충분하다. 구현 단계의 생산자(Maker)들이 해석하고 분해해서 우리가 이 기간에 검증할 내용이 무엇인지 정의한다. 해석과 분해를 위해 추가적인 정보가 필요할 수 있다. 충분하지 않다면 충분하지 않다는 것 자체를 받아들이자! 상황을 받아들이고 그 상황에 맞추어 어떤 시도를 해볼지 결정하는게 좋다. 그리고 결과를 만드는 일에 스프린트 기간 동안 집중해보자. 아니 해야한다. 그리고 해석된 결과가 데모를 통해 공유하고 우리가 충분히 고객과 관련자들에게 다가가고 있는지 확인하자.

되풀이하지 않기

되풀이하지 않기 위해 각 단계에 따른 완전성(Completeness)을 추구해야 할 때도 있다. 만들 S/W 제품을 목표(Goal)로 보고 진행되는 “제품 기획 – 디자인/설계 – 개발/QA”를 단계에 따른 서비스 개발 파이프라인이라고 정의하자.

기획 단계에서 완벽한 사업 내용을 문서로 작성한다. 이 가치를 얻는데 필요한 기능들을 A~Z까지 깨알같이 정의된 산출물이 만들어진다. 디자인 단계는 화면에 어떤 요소들이 위치하는지 픽셀 단위의 오차도 허용하지 않는 피그마로 작성된다. 물론 개발을 위한 방대한 Component – Class – Sequence Diagram(State Diagram)이 깔끔하게 준비되는 경우도 있다. 방대한 정보가 역시 산출물로 만들어진다. 마지막으로 개발/QA가 코드로 Goal을 완성시킨다. 멋지다!

이점에서 제품 완성을 위해 주어진 시간은 단계로 구분된다. 각 단계의 결과물이 예상 시간 범위에 완료되면 이상적일 것이다. 하지만 세상은 완벽하지 않고, 사람의 마음은 갈대와 같다. 고객의 마음 역시 그자리에 그대로 있으라는 보장이 없다. 여기에 소위 배포일이 찍혀있는 Time-to-market 상황이라면? 어느 한 단계의 고민이 길어지면 부담은 고스란히 다음 단계로 전이된다. 개발을 위한 정보 전달이 늦어지면 늦어질수록 결국 짧은 시간에 개발과 QA를 마쳐야 한다. 줄어든 시간은 담당자들에게 심리적인 압박으로 작용하여 스트레스로 사람들을 지치게 만든다.

파이프라인에 정보가 흘러야 한다. 일을 시작할려면 필요한 정보가 있어야 한다. 앞선 이야기처럼 현재 단계를 위한 모든 정보가 있으면 좋다. 25년 개발 경험을 되돌아봤을 때 일 시작 전 모든 정보가 준비된 경우는 없었다. 심지어 SI를 했던 때도. 또한 주어진 정보라도 근거가 잘못됐거나 해석의 오류가 발생하는 경우도 빈번했다. 그래서 “못한다, 님(남)탓이다.“라고 이야기해야 할까? 만약 이런 이야기를 하고 있다면 단계라는 벽에 스스로 갇힌 것과 다름없다. 시간이 가장 귀중한 자원이다.

흐르게 할려면 막힌 부분을 열어야 한다. 정보 역시 마찬가지다.  정보가 흘러가면 모든 단계의 주체들이 뭘 할 수 있을지 고민할 수 있다. 고민하면 준비할 수 있고, 준비되면 추가된 정보를 통해 목표에 다가가는 시간을 아낄 수 있다. 때문에 각 단계의 벽을 여는 것이 가장 중요하다. 단계를 소유하는 조직들이 벽을 스스로 허물어야 한다. 파이프라인에 참여하는 모든 조직들이 단계의 벽을 낮추고 한 팀처럼 동작해야 정보가 흐르고 점진적으로 목표를 향해 나아갈 수 있다.

벽을 낮추고 여는 핵심 역할을 단계의 리드들이 해줘야 한다. 물론 파이프라인을 책임지는 리더 역시 이 부분을 독려해야 한다. 모두가 확고한 의지를 가질 수 없기 때문에 리더십과 문화가 이를 뒷받침해야 한다. 한 두사람의 의지만으로 파이프라인에 물을 흐르게 만들 수 없다.

물론 정보가 완전하지 않기 때문에 엉뚱한 일을 할 수 있다. 누구는 이를 비효율이고 낭비라고 이야기한다. 틀린 말이 아니다. 그렇기 때문에 낭비적인 요소를 최소화하기 위해 빠른 방향 전환을 할 수 있어야 한다. 추가 정보로 틀렸음을 알게되면 빠르게 인정하고 방향을 수정해서 움직여야 한다.

이때 파이프라인의 어느 구간이 닫히는 경우가 있다. 비난이 원인이다. “잘못된 판단”을 하지 않으면 좋겠지만 완전하지 않은 정보를 바탕으로 판단할 수 밖에 없으니결과가 목표와 다른 일은 언제든 발생한다. 이를 용납 못하고 비난이 난무하는데 이를 리더십에서 제어하지 못한다면? 그럼 이 방법은 조직에 맞지 않다. 조직에 맞는 다른 방법을 찾는게 옳다.

현실은 멀티플(Multiple)

담당자가 참여하는 파이프라인이 하나라면 다행이다. 하지만 대부분 팀들이 할 일들이 참 많다. 회사의 꿈이 완성형이 아닌 진행형 상태라면 개인이 혹은 팀이 참여하는 서비스 파이프라인이 하나일 수 없다. 현실은 멀티플이다.

멀티플이라는 그림을 놓고보면 숨이 턱 막힌다. 한번에 두개 세개의 작업을 현실에서 어떻게 하지??? 불가능하다. 사람 머리가 두개가 아닌 이상 특정 순간에 하고 있는 일은 하나다.

컴공 전공이라면 비슷한 그림 한번쯤 보지 안았을까 싶다. 운영 체제(Operating system)를 공부했다면 바로 생각날 것이다. 여기에서 여러 작업을 처리하는 방법, 특히 CPU(Core)가 하나인 경우에 타임 쉐어링이라는 방식이 있다. 사실 여러 작업이 동시 처리되게 보이도록 만든것이지 실제 처리는 1개만 하는 것이다. 단, 계산(Computation)이 지속되도록 CPU에 작업을 지속적으로 부여한다. 만약 계산을 위해 데이터가 필요한 순간이면 그 작업을 잠시 보관하고, 계산할 다른 작업을 올려 진행한다. 물론 작업 전환이 공짜로 이뤄지는 건 아니다. 이전 작업을 이어 수행하기 위한 정보를 안전하게 보관시키고, 다음 작업 실행 상태 정보를 CPU가 바로 수행해야 한다. 운영 체제가 수행하는 이와 같은 일련의 작업 전환을 “컨텍스트 스위치(Context Switch)“라고 부른다. 이 작업 역시 CPU에 의해 실행되기 때문에 공짜가 아닌것이다. 그리고 작업 전환이 많을수록 정작 CPU는 해야할 일보다는 이 전환만 열심히 하고 있을 수 있다.

현실의 멀티플 역시 같은 맥락이다. 당면해서 처리할 충분한 정보가 있다면 그 일에 집중한다. 진행을 위해 정보가 더 필요하거나 선작업이 끝나는 것을 기다려야하는 상황이라면 다른 작업의 일부를 진행하면 된다. 물론 여기도 작업 전환 비용이 발생한다. 전에 내가 어디까지 했는지 기억도 추스려야하고, 문서나 코드도 다시 훑어야한다. 상황 자체가 이전과 판이하게 달라졌다면 당시자들을 만나 충분한 상황 공유를 받아야한다. 이전 작업이 너무 빡셌다면 다음 작업을 위해서 쉬는 것 역시 번아웃을 막기위해 필요하다.

지금까지의 논리로 보면 우리가 일하는 방식은 컴퓨터와 비슷해야 효과적일 수 있다는 것이 역설적이다. 다만 인간은 수만대의 기계를 합친 것에 비교할 수 없다. 똑똑함을 넘어선 인간의 지혜와 통찰이라는 요소가 이 차이를 만든다. 그리고 이 요소들이 십분 발휘될 수 있는 지점이 계획 수립, 즉 플래닝이라고 생각한다.

플래닝을 통해 확정된 것과 미확정 요소를 공유하고, 스프린트에 확인할 대상을 찾아야 한다. 여러 제품 혹은 서비스를 함께 챙겨야한다면 상관관계와 선후를 파악해야 한다. 이 부분이 종합되면 스프린트에 수행할 태스크의 우선 순위를 매길 수 있다. 물론 미확정 요소를 확정 단계로 만들어야하고, 이렇게 파악된 컨텍스트를 참여자 모두가 확인할 수 있도록 열린 커뮤니케이션이 공유의 형태로 유지되어야 한다. 강조해서 주의/당부하고 싶은 건 정보가 무기화되는 것이다. 누군가가 정보를 자신을 위해 사용한다고 참여자들이 모두 느낀다면 안하니만 못한 일이 되버린다.

-끝-

PS.

국방, 안전, 항공, 우주 관련 프로젝트의 경우는 절차적 단계에 따른 제품 개발이 꼭 필요하다고 생각한다. 부실한 정보를 토대로 원전 운영 소프트웨어를 작성했다는 사실을 알게 되면… 끔찍하다. 해본 적은 없지만, 이런 고난이도 개발을 해볼 기회가 있었으면 하는 생각도 든다.

중꺽마: Dogfooding 프로젝트부터 라이브까지

쏘카에는 피어보너스(Peer Bonus)라는 제도가 있다. 동료가 동료를 칭찬해주고 작은 금액을 보너스로 지급해주는 제도로 작은 칭찬이지만 구성원 사이의 인정을 통해 기여와 발전을 도모하기 위해 운영된 제도이다.

지난 주에 본부 구성원 한분이 피어보너스를 받았다. 전기차량 충전 잔량이 부족한 경우 다음 고객분의 예약 전에 충전하는 자동화 프로세스를 개발했고, 그동안 수작업으로 이뤄지던 업무량의 77%를 자동화 처리했다. 덕분에 고객은 전기차량을 예약했을 때 충전 걱정없이 바로 차량을 이용할 수 있게 됐고, 운영 부서는 이 부분에 신경쓰는 시간을 줄일 수 있었다. 사실 이렇게 보면 이 작업이 큰 의미를 갖는 작업일까 싶은 생각을 할지도 모르겠다.

사실 이 과제는 담당 업무를 수행했던 주니어 분들의 온보딩 과정 중 하나의 Dogfooding 프로젝트였다. 신입으로써 온전히 쏘카의 환경을 이해하고, 이 프로젝트를 마무리한다는 건 사실상 불가능에 가깝다. 그리고 제한된 기간으로 인해 대부분의 Dogfooding 프로젝트 기간에 라이브까지 이뤄지지 못하고, 실제 Dogfooding 프로젝트들이 관련 업무 팀으로 이관되어 마무리가 된다. 물론 해당 프로젝트를 담당했던 팀원 가운데 한분 정도가 대부분 해당 팀으로 배정된다.

이 프로젝트의 경우도 Dogfooding 과정에서 얼추 얼개가 맞춰진 다음 신입분과 함께 담당 팀으로 이관되었다. 하지만… 해당 팀은 쏘카내에서 카셰어링을 담당하는 팀이었고, 업무량 폭주에 Legacy의 한복판에서 맹활약하는 팀이었다. 그리고 단순히 전기차의 충전량만 검토해야 하는게 아니라 예약의 전후 관계 맥락을 제대로 풀어야 이를 라이브 할 수 있다는 것도 팀에 배정된 이후에야 주니어 개발자분이 파악할 수 있지 않았을까?

중요한건 꺽이지 않는 마음

팀 배정 이후로 해당 팀의 개발 항목에 이 항목이 있었다. 이야기했던 것처럼 쉽게 마무리가 될 수 없는 환경이었다. 주니어분이 짧은 시간에 이해도를 높일 수 있을만큼 카셰어링 환경이 만만치 않았고, 문제가 있었지만 그럼에도 운영되던 기존 시스템도 있었다. 아주 긴 시간동안 백로그가 아닌 실제 개발 진행 항목으로 계속 리스팅되고 있었다. 그리고 이번 여름에 정식으로 출시되었다.

사실 이 프로젝트는 포기할 수도 있었다. 주목도가 있는 프로젝트가 아니고, 한 사람이 너무 한 일에 매여있는 부분도 팀 운영에 부담이 되기 때문이다. 그럼에도 불구하고 Dogfooding 프로젝트부터 해왔던 담당자가 일을 마무리 짓고 싶어했고, 팀의 TL은 그 기회를 통해 주니어가 환경에 대한 이해를 통해 성장하길 바랬던 것 같다. 포기할 수도, 포기하게 만들 수도 있었다. 그럼에도 불구하고 완결성있게 마무리하고 싶은 마음이 있어서 끝냈다고 생각한다. 그리고 동료의 기분좋은 피드백이라는 좋은 결과를 만들었다.

일을 하는 동기란 무엇일까? 여러 좋은 꺼리들을 많이 이야기할 수 있겠지만, 일을 끝내겠다는 마음, 그리고 이를 지지하고 응원해주는 동료들의 존재만으로도 일에 대한 좋은 동기가 될 수 있지 않을까 싶다.

@VisibleForTesting을 활용에 대한 단상

간만에 개발에 대한 글을 써본다.

코드를 잠깐 봐볼까 싶다가 @VisibleForTesting이라는 Annotation을 봤다. 사실 처음보는 Annotation이라 뭐하는 놈인가 싶은 생각이 들어서 찾아봤다.

Annotation Type VisibleForTesting

  •  
    @GwtCompatible public @interface VisibleForTesting
    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 CandorDare to Lead 책을 읽어보길 추천한다.)

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

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

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

To be continued…

말할려면 어떻게든 들어야 한다.

리더의 자질 가운데 하나로 “경청“이라는 단어를 많이들 이야기한다. 나름 잘 들을 수 있는 준비는 되어 있다고 생각하고, 다른 구성원들과의 이야기에서도 듣기 위해 많이 노력한다.

하지만 최근 깨닫게 된 사실 하나는 나는 이야기하기에 편한 사람이 되질 못한다는 것이다. Vulnerability를 중시하고 사람들에게 가능한 편안하게 다가갈려고 했지만, 다가가는 것과 다가오는 건 천지차이임을 다시금 알게 됐다. 직급과 직책이 높아질 수록 그 사이의 계단 개수는 그 높이만큼 많아지는게 사실인 것 같다. 그러다보니 실무의 체감 온도와 내가 느끼는 온도 차는 “괴리”감을 일으킬 정도까지 차이가 이미 벌어진게 아닐까 싶은 고민도 생긴다.

그래서 6월말부터 월 1회씩 AMA(Ask Me Anything)를 진행하기로 했다. 한국 문화 특성상 본인 실명으로 과감한 이야기를 들을 수 없을 것 같아서 무기명(Anonymous)으로 질문하는 것을 허용했다. 대찬 질문들이 많았고, 즉석에서 대답해주기 어려운 질문들이었다. 몇가지 본부내 정책 변화를 시도할 예정이라는 것에 구성원의 강한 의구심 역시 피할 수 없었다. 그럼에도 이런 이야기를 들을 수 있었다는 사실에 만족한다.

조직의 의사 결정이 모든 사람들을 만족시킬 수는 없다. 불만족은 항상 지속될 것이고, 몇몇은 불만족인 상태로 유지될 것이다. 그럼에도 “변화(Change)“라는 것이 존재하고, 이 변화를 통해 제대로 서비스를 개발하기 위해 성숙한 조직으로 나아간다는 혹은 나아갈 것이라는 점이다.

항상 피드백을 강조한다. 스프린트 운영에서 데모를 통해 피드백을 받아야 한다는 것을 강조한다. 회고를 통해 1개씩은 팀이 개선되어야 한다고 강조한다. 조직을 운영하는데 있어서도 당연히 피드백이 있어야 한다. 피드백이 있어서 성장하고 성숙한 제품과 조직이 될 수 있다.

리더는 의사 결정을 내리고, 그 결정을 책임진다. 올바른 결정을 내리기 위해서는 많은 목소리를 들어야 한다. 리더가 내린 결정을 구성원들이 존중하고 함께 그 방향으로 노를 젓도록 만드는 것이 리더의 역량이다. 이렇게 되기 위해서는 물론 구성원이 말할 수 있는 환경이 만들어져야 한다. 그렇기 때문에 Vulnerability가 매우 중요하고, 이를 기반으로 한 팀 단위의 소통이 중요하다.

AMA는 이 관점에서 조직의 단계를 뛰어넘는 의사 소통 방법이지만, 전체 조직이 한 방향으로 가고 있는지 그 방향성에 어떤 다른 목소리가 있는지를 알아야 한다. 이를 바탕으로 미션을 완성하기 위한 구성원들의 노력을 제대로 엮어낼 수 있다고 본다.

변화를 만들고, 변화에 동참할 수 있는 환경을 만들겠다!