SR1. 개발 문화와 리더십

디지털 트랜스포메이션 잘 안 되나요?
개발 조직 키우는 리더십부터 체크해야

342호 (2022년 04월 Issue 1)

Article at a Glance

소프트웨어가 세상을 삼키고 있다. 많은 기업이 살아남기 위해 디지털 트랜스포메이션에 박차를 가하지만 들이는 노력만큼 성과를 내지 못하는 것이 현실이다. 그 배경에는 개발 전문 리더십의 부재가 있다. 개발 리더가 팀을 이끌어 좋은 개발 문화를 조성하려 노력할 때 높은 성과를 거둘 수 있다. 좋은 개발 조직을 만들기 위해 개발 리더들은 다음 3가지 역할에 집중해야 한다.

1. 시장 반응에 민첩하게 대응하는 애자일 방식과 개발 중인 제품을 직접 써보는 ‘도그 푸딩(Dog Fooding)’ 등을 활용해 프로젝트를 성공적으로 이끌어야 한다.

2. 깊은 기술 지식을 바탕으로 어떤 기술을 활용하고 설계할지, 내부 개발 프로세스는 어떻게 정리할지 등 조직의 기술적인 부분을 관리해야 한다.

3. 조직에 맞는 개발자를 채용하고 개발자들이 지속적으로 성장할 수 있도록 도와야 한다.



인터넷 웹브라우저를 처음 만든 미국의 유명 소프트웨어 개발자 마크 앤드리슨은 2011년 월스트리트저널에 “왜 소프트웨어가 세상을 먹어 치우고 있는가?”1 라는 칼럼을 썼다. 소프트웨어 혁명이 일어날 것이라고 주장한 그의 칼럼은 당시 큰 반향을 일으켰다. 그의 예견은 들어맞았다. 약 10년이 흐른 지금 소프트웨어 세상이 완전히 도래했다는 사실에 그 누구도 반박하기 어렵다.

최근 기업들이 박차를 가하는 디지털 트랜스포메이션의 중심에는 소프트웨어가 있다. 소프트웨어는 기업의 프로세스를 정비하고 데이터 수집을 통한 효과적인 의사결정을 돕는다. 또 기업이 기술 기반으로 빠르게 시장에 대응할 수 있게 한다. 스타트업도 예외가 아니다. 스타트업은 세 가지 특징을 가진다. 애자일한, 즉 시장에 대한 빠른 반응, 데이터 기반 의사결정, 마지막으로 아날로그 시장에 제약되지 않는 디지털 확장을 통해 엄청난 규모로 성장하는 ‘J커브’ 성장이다. 이 세 가지는 모두 디지털, 즉 소프트웨어 없이는 불가능하다.

그러나 많은 회사가 디지털 트랜스포메이션에 들이는 노력만큼 성과를 내지는 못하고 있다. 여러 이유가 있겠지만 핵심은 개발 문화와 리더십의 문제 때문이라고 본다. 디지털 트랜스포메이션을 위해서는 네 가지 역량이 필요하다. 프로세스, 데이터, 기술, 변화 역량이다. 이런 역량을 만들어 내는 바탕이 바로 개발 문화와 리더십이다.

027


좋은 개발 조직이란 무엇인가

문화란 무엇일까? 문화는 한 집단이 비슷하게 생각하고 행동하는 기본 생활양식이다. 마주치면 인사를 하거나 식사 중에 크게 떠들지 않는 것도 문화 중 하나다. 회사에도 문화가 있다. 너무 늦은 시간에 회의를 시작하지 않고 e메일을 받으면 당일에 답변하는 것도 업무 문화라고 볼 수 있다.

물론 나라마다 사회 문화가 다르듯이 회사마다 업무 문화도 다르다. 개발 인력을 보유한 기업이라면 개발 문화도 다를 수밖에 없다. 우리 문화가 우리나라를 동방예의지국으로 만들었듯좋은 개발 문화를 갖춘 회사가 좋은 소프트웨어를 만들 수 있다. 특히 좋은 개발 문화는 우수한 개발자 채용 혹은 양성에 도움이 된다. 개발 인재가 회사를 떠나지 않고 근속하는 유인이 되기도 한다.

좋은 소프트웨어 개발 문화를 만드는 데 가장 중요한 요소는 단연 개발 리더십이다. 문화는 모두 같이 만드는 것이지만 무엇보다 리더의 관심과 노력이 제일 중요하다. “나에게 나무를 자를 6시간을 준다면 나는 먼저 도끼를 날카롭게 하는 데 4시간을 쓰겠다”라는 링컨 대통령의 말처럼 개발 리드가 해야 할 가장 중요한 일은 좋은 개발 조직, 곧 좋은 개발 문화를 만드는 것이다.

그렇다면 좋은 개발 조직이란 무엇일까? 좋은 개발 문화, 개발 전문 리더십과 더불어 좋은 개발 조직을 만들기 위해 리더가 갖춰야 할 5가지를 제시한다.

1. 비전으로 얼라인(align)하기

얼라인이란 모두가 한 주제에 대해 비슷한 생각을 갖는 것이다. 그렇다면 회사 구성원 모두가 얼라인해야 하는 것은 무엇일까? 바로 비전이다. 회사가 가는 방향, 즉 비전에 얼라인돼 있지 않으면 글로벌 경쟁에서 뒤처질 수밖에 없다. 구성원이 각자 맡은 일만 하는 탓에 이런 조직은 빠르게 성장하기 어렵다.

2. 다양한 가능성 열어놓기

모두가 비전에 얼라인했다고 끝이 아니다. 회사가 가는 방향에 대해서는 동의했더라도 디테일에 대해서는 다양한 가능성을 열어놔야 새로운 창조가 가능하다. 모두가 앞사람의 어깨를 잡고 한 줄로 걸어가는 것만큼 비효율적인 일도 없다. 다양한 상상을 하면 더 놀라운 일들을 이룰 수 있다. 얼라인만큼 중요한 것이 다양성이라는 점을 꼭 기억해 주길 바란다.

3. 한계 정하지 않기

과거 마이크로소프트의 가장 큰 적은 누구였을까? 흥미롭게도 마이크로소프트 스스로였다. 마이크로소프트가 이뤄온 것들이 변화에 걸림돌이 됐고 현재 CEO인 사티아 나델라가 과감히 혁신에 도전하면서 새로운 마이크로소프트로 탈바꿈한 것이다. 나델라 CEO는 과거 적대적이었던 오픈소스에 대한 입장을 우호적으로 바꾸고 모바일을 과감히 포기하면서 클라우드에 공격적으로 투자했다.2 최근에는 액티비전블리자드 같은 대형 게임 회사를 인수하는 등 과감한 혁신을 이어가고 있다.

소프트웨어를 기반으로 한 기술 기업이라면 스스로 한계를 정해서는 안 된다. 머신러닝으로 알파고가 이세돌을 이기고 테슬라 등 많은 기업이 사람보다 운전을 잘하는 자율 주행 자동차를 만들고 있다. 과거에는 개발자 수백 명이 온라인 서비스 하나를 만들었다면 지금은 수많은 서비스형 소프트웨어(SaaS)가 나오면서 소수 인력만으로도 쉽게 개발할 수 있게 됐다. 이처럼 10년 전에 상상하던 일이 5년 전에 이뤄지고 5년 전에 불가능했던 일이 지금 가능해지는 것이 현재 소프트웨어를 기반으로 한 기술 시장이다. 스스로 한계를 정하고 도전하지 않는다면 도태될 수밖에 없다.

4. 목표에 집중하는 애자일

급변하는 시장에서 살아남는 가장 좋은 방법은 시장과 함께 움직이는 것이다. 빠르게 시장에 제품을 출시하고 사용자 반응에 맞춰 개선하면서 좋은 제품을 만들어낼 수 있다. 애자일 방법론이 도움이 된다. 애자일 방법론이란 굉장히 작은 기능, 즉 최소한의 기능을 기존에 존재하는 다양한 솔루션을 이용해 최대한 빠르게 개발하는 방식이다. 제품을 빠르게 출시해 사용자들의 실제 반응을 보고 기능 개선 혹은 추가하며 제품을 시장 상황에 맞게 완성하는 것이다. 애자일을 적용할 때 주의해야 할 점은 단순히 빠르게 개발하는 것이 아닌 시장의 반응에 빠르게 대응하는 것임을 명심해야 한다.

5. 확장 가능한 스케일

바야흐로 글로벌 시대다. 모든 것이 네트워크로 연결되고 서비스 하나가 전 세계에 영향을 미치기도 한다. 혼자서 모든 것을 다 할 필요 없이 주변을 이용하고, 또 협력해야 하는 시대가 열린 것이다. 소프트웨어의 핵심이 바로 이 확장 가능한 스케일이라고 본다. 문 걸어 잠그고 혼자 만들기보다 전 세계와 같이 만들어 갈 때 제품의 성공 가능성이 높아진다.

앞서 제시한 요건들을 갖춘 좋은 개발 조직의 예로는 아마존이 있다. 아마존은 혁신 문화를 바탕으로 지난 30년간 급성장하며 놀라운 성과를 달성하고 있다. 아마존 혁신 문화의 4가지 요소는 다음과 같다.

① 고객에게 집착하라. 고객 입장에서 모든 것을 계획하고 업무를 정리하라.

② 장기적으로 사고하라. 비전을 가지고 꾸준히 진행하라.

③ 발명하고 싶다면 실패를 각오하라. 실패 없는 혁신은 불가능하다.

④ 오랫동안 사람들에게 이해받지 못할 것을 각오하라. 새로운 시도 없이는 혁신이 불가능하다.

아마존이 경험한 가장 큰 실패로는 2014년 출시한 스마트폰 파이어폰(Fire Phone)이 꼽힌다. 그러나 아마존은 이 실패를 바탕으로 스마트 스피커 에코(Echo)와 음성 비서 서비스 알렉사(Alexa)를 만들었다. 이는 곧 아마존의 인공지능, 곧 머신러닝의 발전으로 이어졌다. 글로벌 시장 조사 업체인 스태티스타(Statista)에 따르면 2020년 4분기 기준 알렉사가 장착된 아마존 에코는 글로벌 스마트 스피커 시장에서 28.3%의 점유율을 차지하며 출시 이후 인공지능 스피커 시장점유율 1위를 지키고 있다.3 고객 중심이라는 비전 아래 실패를 각오하며 끊임없이 혁신한 결과다.

좋은 개발 조직을 만들기 위한 개발 리더십

소프트웨어 개발은 크게 4가지 요소로 이뤄진다. 사람, 기술, 제품, 프로세스다. 좋은 사람들이 뛰어난 기술로 탁월한 제품을 만들고 이 모든 과정을 좋은 프로세스가 받쳐주는 것이다. 인재 채용과 기술에 대한 의사결정, 제품 출시 일정 등 모든 것은 프로세스에 따라 진행된다. 평판이 안 좋은 조직은 이 4가지 요소가 모두 망가져 있을 때가 많다. 하지만 하나씩 개선해 나간다면 다시 좋은 조직으로 탈바꿈할 수 있다. 물론 그 시작은 사람, 그중에서도 리더에게 달려 있다. 리더가 변하면 구성원, 나아가 기술과 제품의 변화까지 이끌어내기 수월하다. 좋은 개발 조직을 만들기 위해 개발 리더의 변화가 중요한 이유다.

029


개발 리더십, 특히 소프트웨어 개발 리더십은 일반적인 비즈니스 리더십과 다른 면이 많다. 소프트웨어 개발 리더십의 경우 복잡한 기술, 제품, 조직과 프로세스까지 관리해야 하기 때문에 요구되는 사항이 많은 편이다. 따라서 모든 것을 잘하는 개발 팀장, 곧 소프트웨어 개발 리더가 되기란 사실상 불가능하다. 분산 리더십을 고려해야 하는 이유다. 한두 가지 잘하는 일에 집중하면서 다른 일은 동료들과 협업하는 쪽이 훨씬 현실적이며 효율적이다. 더군다나 요즘같이 대규모 사용자를 지원하는 대용량 서비스의 경우 시스템의 난이도와 제품 복잡도가 높아 소수 리더만으로는 작업이 불가능한 수준에 이르렀다. 여기에 글로벌 서비스까지 더해진다면 더욱 많은 리더의 협업이 필요하다.

분산 리더십을 위해 소프트웨어 개발 리더의 역할을 나눈다면 다음과 같이 분류할 수 있다. 제품 개발 리소스나 일정 등을 관리하는 프로젝트 리드, 기술을 결정하는 테크니컬 리드, 개발자들이 행복하게 일하도록 돕는 피플 매니저, 전체 업무 과정을 계속해서 개선하는 프로세스 매니저, 새로운 기술을 연구하고 분석해 더 좋은 기술로 나아가도록 돕는 아키텍트, 실제 개발 실무도 함께 수행하는 엔지니어 등이다. 이 중에서도 개발 리더들은 다음 3가지 역할에 집중하는 것이 좋다.

030


1. 성공을 이끄는 프로젝트 리드

일반적인 소프트웨어 서비스는 고객 여정(customer journey)부터 고려한다. 예를 들어 금융 서비스 앱 토스는 고객이 어떻게 토스 앱을 처음 사용하고 이후 앱을 통해 어떤 일을 하는지 등 모든 고객 여정을 분석해 가설을 설계한다. 그리고 실제 앱을 이용하는 사용자들의 행동 데이터를 모두 수집해 가설을 검증하면서 사용자들에게 편리한 방향으로 지속적인 업데이트를 한다. 중요한 기능 변경 역시 A/B 테스팅을 거친다. 모든 사용자에게 바로 변경 내용을 적용하지 않고 일부 사용자들에게 먼저 적용하는 것이다. 기존의 방식과 새로운 방식을 적용한 사용자들을 각각 A 그룹과 B 그룹으로 나눠 그 결과를 데이터 기반으로 면밀히 분석한다. 결과를 토대로 변경 사항을 전체 적용하거나 추가 개선하는 등 의사결정을 내린다.

프로젝트 리드는 이 모든 과정을 명확하게 이끌어 나가야 하며 A/B 테스팅 등의 개발 방식과 개발 문화가 모든 프로세스에 잘 반영될 수 있도록 도와야 한다. 일반적인 프로젝트와 달리 소프트웨어는 개발 도중 모든 작업 내용을 갈아엎을 수 있다. 출시 이후에도 지속적으로 업데이트해 줘야 한다. 따라서 폭포수 방식으로 모든 계획을 세워 한 단계씩 진행하기보다 애자일 방식으로 빠르게 시장 반응을 보고 대응하는 것이 좋다.

이런 맥락에서 소프트웨어 업계는 최소기능제품(MVP, Minimum Viable Product)을 주목하고 있다. 모든 기능을 다 만드는 것이 아닌 최소한의 기능만 구현해 출시한 뒤 사용자들의 반응을 보고 추가하는 방식이다. 예를 들어 게임의 10%만 만들어 출시한 뒤 이용자들의 반응이 좋으면 나머지 부분을 빠르게 개발해 출시한다. 적은 시간과 비용을 들인 최소기능제품은 리스크를 최소화하고 시장 변화를 빠르게 따라가는 데 유용하다.

물론 개발 시간 최소화만이 능사가 아니다. 애자일의 핵심은 시장 반응을 보면서 빠르게 개발하는 것인데 이때 ‘빠르게’란 ‘낭비가 최대한 없게’라고 해석하면 된다. 무조건 시간을 줄이기보다 낭비하는 시간을 없애기 위해 노력해야 한다. 개발 프로젝트의 효율을 떨어뜨리는 5가지 주요 요소가 있다. 프로젝트 리드는 팀원 모두가 이 5가지에 주의하도록 개발 문화를 조성해야 한다.

① 불필요한 코드

개발했는데 출시하지 않는 기능이 대표적이다. 예를 들어 오래된 운영 체제인 Windows XP까지 지원하기로 하고 열심히 개발했는데 개발 일정 막바지에 Windows XP 지원을 하지 않기로 결정한다면 그동안 작성한 코드는 무용지물이 된다.

② 개발 과정에서의 지연

한쪽 기능은 만들었는데 다른 쪽 기능이 완성되지 않아 기다리는 경우다. 예컨대 게임에 채팅 기능을 추가할 때 서버 개발은 끝났는데 클라이언트 개발이 지연돼 기다려야 한다면 전체적인 개발 효율이 떨어질 수밖에 없다.

③ 불명확한 요구 사항

요구 사항을 매번 다시 확인해야 하거나 개발을 완료했는데 요구 사항이 적용되지 않는 일이 종종 발생한다. 예컨대 고객에게 메시지로 공지사항을 보내는 기능을 개발해달라는 요청이 들어왔다고 가정해보자. e메일로 공지사항을 보내도록 개발했는데 e메일이 아닌 SMS로 보내야 한다고 재요청이 들어온다면 일을 두 번 해야 하는 셈이다. 처음부터 명확히 요구 사항을 전달해 이런 비효율적인 일이 발생하지 않도록 해야 한다.

④ 내부 정치

직원들의 업무 생산성 향상을 위해 e메일 시스템을 개선할 때 IT 조직에서 오래된 인터넷 브라우저(Internet Explorer)만 지원할 수 있다고 고집을 피운다면 어떨까? e메일 시스템 개선은 반쪽으로 끝나고 말 것이다. 내부 조직 간의 이해관계가 아닌 사용자를 중심으로 효율적인 결정을 내려야 한다.

⑤ 느린 내부 소통

내부 문서 정리가 안 돼 있고 커뮤니케이션 프로세스도 없다면 시스템 운영 중 문제가 생겼을 때 빠르게 해결하기 어렵다. 해결 방법을 알고 있을 만한 개발자 수십 명에게 e메일을 보내거나 옛날 e메일을 뒤져 겨우 해결하는 상황도 벌어질 수 있다. 최적화된 내부 소통 프로세스를 구축해 적절한 정보가 빠르게 공유될 수 있도록 해야 한다.

마지막으로 개발 프로젝트를 성공시키기 위해 중요한 요소가 하나 더 있다. 바로 ‘도그 푸딩(Dog Fooding)’이다. 개발 업계에서 사용하는 용어로 ‘개밥을 먹어본다’, 즉 만들고 있는 제품을 직접 써 본다는 뜻이다. 개발자가 직접 만들고 있는 제품에 만족하지 않으면 시장에 내놓을 수 없다는 의미로 해석할 수 있다.

도그 푸딩이 개발 문화로 자리 잡으려면 대표와 각 리더 모두 솔선수범해야 한다. 필자가 블리자드 미국 본사 리드 소프트웨어 엔지니어로 재직할 당시 ‘디아블로 3’ 게임 출시를 앞두고 있었다. 리더들을 모아놓고 개발 상황을 점검하다 마이크 모하임 당시 블리자드 대표는 회의를 멈추고 질문을 던졌다. 리더들 중 실제 디아블로 3 게임을 끝까지 해보고 재밌다고 느낀 사람이 얼마나 되느냐고 물은 것이다. 바쁜 업무 일정 탓에 실제 게임을 해본 리더는 거의 없었다. 모하임 대표는 게임 출시 일정을 미루기로 결정했다. 모든 리더가 게임을 해보고 재밌다고 느끼면 출시하겠다고 공표한 것이다. 이처럼 만든 제품을 실제로 써보고 출시하는 도그 푸딩은 매우 중요하다. 그래야 고객에게 사랑받는 제품을 지속적으로 만들어낼 수 있다. 블리자드가 미국 3대 게임사로 성장한 배경에는 이런 노력이 중요한 역할을 했다고 본다.

2.기술 주도 테크니컬 리드

시장과 기술은 빠르게 변한다. 만들어야 할 소프트웨어 제품이 달라지고 이를 구현하는 기술 역시 계속 발전하고 있다. 달리는 말 위에서 움직이는 과녁을 맞히는 상황에 비유할 수 있다. 이런 특수성 때문에 소프트웨어 프로젝트를 진행할 때는 방향과 속도를 모두 신경 써야 한다. 올바른 방향으로 나아가기 위해 지속적으로 조정해야 하지만 그러면서도 개발 속도를 빠르게 유지해야 한다. 이 역할은 테크니컬 리드의 몫이다.

테크니컬 리드는 조직의 기술적인 부분을 관리하는 역할이다. 어떤 기술을 활용하고 설계할지, 내부 개발 프로세스는 어떻게 정리할지 등을 고민한다. 예컨대 최소기능제품을 개발할 때 테크니컬 리드는 어떻게 하면 기존의 여러 기술을 조합해 빠르게 제품을 만들 수 있을지 고민해야 한다. 다만 한 번 쓰고 말 기술인지, 아니면 유지•보수하며 계속 사용할 기술인지 명확한 판단을 내려야 한다. 건축에 비유하자면 모델하우스처럼 한 번만 쓰고 말 용도인지, 추후 증축이나 재건축까지 고려할 건물인지 판단하는 것이다.

일회적으로 쓸 기술이라면 안정성만 생각하면 된다. 하지만 계속 유지•보수하며 쓸 계획이라면 결정을 내리기 전에 그 기술이 현재 시장에서 잘 사용되고 있는지, 혹은 미래에도 계속 지원될 수 있을지 미리 알아봐야 한다. 또 그 기술을 잘 알고 있는 적절한 개발자가 내부에 있는지, 이 기술로 제품 기능을 확장할 때 현재 만들어 놓은 것을 최소한으로 수정해 확장 가능한지 등 여러 부분을 고려해야 한다.

지금처럼 변화무쌍한 환경에서는 테크니컬 리드의 역량이 더욱 중요하다. 끊임없이 새로운 문제를 마주하기 때문이다. 확실히 알고 잘할 수 있는 부분은 전체 일정에서 명확하게 처리할 수 있지만 문제는 잘 모르는 영역에서 터지곤 한다. 가령 아무도 만든 적 없는 제품을 만든다거나 한 번도 다뤄보지 않은 기술을 써야 할 때가 있다. 이때 테크니컬 리드는 구성원들이 모르는 기술이나 영역을 잘 다룰 줄 알아야 한다.

테크니컬 리드가 챙겨야 할 구체적인 항목은 다음과 같다. 일반적으로 스타트업의 기술력을 평가할 때 활용하는 항목으로 이를 모두 갖췄을 때 좋은 개발 조직이라고 볼 수 있다.

① 개발 역량이 있는지?

② 프로젝트 관리 능력이 있는지?

③ 제품 출시 후 운영 능력이 있는지?

④ 제품의 확장성이 좋은지?
단일 장애점4 이 있는지?

⑤ 보안은 잘되고 있는지?

⑥ 어떤 플랫폼을 쓰고 있는지?
클라우드는 어떻게 활용하는지?

⑦ 미래에 생길 수 있는 위험 요소는 없는지?

미국 유명 개발자 조엘 스폴스키(Joel Spolsky)가 만든 ‘조엘 테스트’도 좋은 개발 환경을 갖추고 있는지 점검할 때 유용하다. 이 내용들 역시 테크니컬 리드가 모두 챙겨야 한다.

① 모든 개발자의 소스 코드 작업을 추적하고 병합할 수 있는 소스 코드 관리 시스템을 사용하고 있습니까?

② 소스 코드에서 한 번에 제품을 만들어낼(Build) 수 있습니까?

③ 매일 소스 코드로 제품을 만들어(Build)
보고 있습니까?

④ 오류(Bug) 추적 시스템을 운영하고
있습니까?

⑤ 코드를 새로 작성하기 전에 오류를 수정합니까?

⑥ 개발 일정을 업데이트하고 있습니까?

⑦ 개발을 위한 제품 기능 명세서를 작성하고 있습니까?

⑧ 조용한 작업 환경에서 일하고 있습니까?

⑨ 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?

⑩ 제품 테스트를 위한 전문 테스터를 별도로 두고 있습니까?

⑪ 프로그래머 채용 인터뷰 시 개발 역량을
확인하기 위한 코딩 테스트를 실시합니까?

⑫ 다양한 사람을 통해 제품의 사용 편의성을 확인하는 무작위 사용 편의성 테스트를 수행하고 있습니까?


034


3. 행복을 만드는 피플 매니저

다시 강조하지만 기술은 정말 빠르게 변한다. 10년 전에 썼던 기술을 계속 사용한다면 경쟁자에게 뒤처질 가능성이 높다. 개발자들의 성장에 관심을 기울여야 하는 이유다. 개발 리더는 개발자들이 업무를 잘 수행하면서도 행복을 느끼고 또 지속적으로 성장할 수 있도록 도와야 한다. 안정성이 검증된 기존의 기술을 이용해 빠르게 개발해야 하는 상황이더라도 개발자가 새로운 기술에 도전하길 원한다면 이를 용인해 주는 문화가 필요하다. 개발 인재를 채용하는 것뿐만 아니라 구성원이 우수한 개발자로 성장하도록 돕는 것 역시 매우 중요하다는 사실을 리더는 꼭 명심해야 한다.

대부분의 개발자는 현재 주어진 업무를 잘해내고 싶어 한다. 또 직장에서 행복하게 지내길 원한다. 그러나 앞으로의 성장에 대해서는 의외로 관심을 갖지 않는 모습이다. 소프트웨어 업계는 호락호락하지 않다. 시장과 기술의 변화 속도가 매우 빠르다. 글로벌 업체들이 단숨에 한국에 진출해 시장 판도를 바꿔놓기도 한다. 결국 성장하지 않으면 뒤처지는 것이 이 업계의 숙명임을 팀원들에게 명확히 인지시켜야 한다.

성장에 대한 팀원들의 관심을 이끌어내고 싶다면 ‘5년 후 질문’을 사용해 보길 바란다. 이 질문에 대해 개발자 스스로 고민함으로써 자연스레 성장에 관심을 가질 수 있다.

① 5년 후에도 이 회사가 있을까?

② 5년 후에 이 회사를 다니고 있을까?

③ 5년 후에 이 회사에서 무엇을 하고 있을까?

일대일 면담 또한 좋은 개발 문화를 만들기 위해 매우 중요한 활동이다. 무릇 리더라면 팀원 면담을 주기적으로 진행해야 한다. 2주에 1번 정도를 권장하지만 1달에 1번이라도 좋다. 팀원이 현재 행복하게 업무를 잘 수행하고 또 성장하고 있는지, 이를 위해 리더가 무엇을 도와줄 수 있는지에 대해 30분에서 1시간 정도 이야기 나누면 된다. 단, 모든 면담을 기록하고 이를 반영하는 것은 팀원의 몫이다. 본인의 성과와 행복, 성장에 스스로 관심을 가져야 하며 리더는 이를 위해 팀원이 활용할 수 있는 최고의 리소스일 뿐이다.

구성원의 성장을 돕는 것만큼 채용에도 공을 들여야 한다. 개발자 채용의 핵심은 우수한 인재를 뽑는 것이 아닌 회사와 맞지 않는 사람을 뽑지 않는 것이다. 훌륭한 개발자 10명을 놓치더라도 조직과 맞지 않는 사람 1명을 채용하지 않는 것이 훨씬 중요하다. 조직 문화는 모든 구성원이 함께 만드는 것이기에 단 한 사람이 쉽게 망가뜨릴 수 있기 때문이다.

채용 후 효과적인 온보딩도 매우 중요하다. 특히 속도가 생명인 스타트업에서 온보딩이 더욱 중요하다. 온보딩의 목표는 조직과 업무를 빠르게 파악해 혼자 업무를 수월히 해내도록 돕는 것이다. 어디서 필요한 정보를 얻고, 누구에게 어떤 도움을 요청할지, 혼자 할 수 있는 업무는 무엇인지 등 모든 정보를 투명하게 공개해 신규 입사자가 빠르게 업무에 적응할 수 있는 환경을 조성해야 한다. 노션(Notion)이나 슬랙(Slack) 등 정보를 쉽게 공유할 수 있는 협업 도구를 상황에 따라 적절히 활용하면 된다.

많은 기업이 개발자 채용에 어려움을 겪는다. 개발 인재를 채용하기 위해 멋진 비전과 높은 보상을 내세우는 것도 좋지만 매력적인 리더 역시 중요하다. 특히 규모가 작은 스타트업이라면 높은 보상을 줄 만한 여건이 안 될 수 있다. 결국 대표 본인 혹은 기술 리더의 매력으로 개발자들의 호감을 사야 한다. 매력적인 리더가 되려면 앞서 설명한 것처럼 프로젝트를 성공적으로 이끌고, 기술을 잘 관리하며, 팀원의 성장과 행복에 기여해야 한다. 좋은 개발 조직, 개발 문화를 만들기 위해 리더가 전심전력할 때 개발자들이 성장하고 또 외부에 있는 개발 인재들 역시 모여들 것이다.

개발 전문 리더십이 필요하다

소프트웨어가 세상을 삼키고 있다. 많은 기업이 살아남기 위해 디지털 트랜스포메이션에 박차를 가하지만 현실은 녹록지 않다. 그 배경에는 개발 전문 리더십의 부재가 있다. 개발 리더가 팀을 이끌어 좋은 개발 문화를 조성하려 노력할 때 높은 성과를 거둘 수 있다. 소프트웨어 역량은 실력 있는 개발자 1∼2명을 더 채용한다고 높아지는 것이 아니기 때문이다. 미래 변화를 예측하고 회사가 나아갈 방향을 명확히 정리한 뒤 소프트웨어 역량이 중요하다고 판단되면 개발 전문 리더십과 개발 문화에 과감히 투자해야 한다. 물론 단번에 모든 것을 만들 순 없다. 미래 청사진을 그리고 하나씩 갖춰 나가다 보면 점점 높아지는 소프트웨어 역량과 기업 가치를 체감할 수 있을 것이다.


박종천 몰로코 헤드 오브 솔루션스 아키텍처 soubau@hotmail.com
필자는 30여 년 동안 한국과 미국 실리콘밸리를 오가며 개발자로 일했다. 한글과컴퓨터 개발자로 시작해 블리자드 미국 본사 리드 소프트웨어 엔지니어, 넥슨 플랫폼본부 부본부장, 삼성전자 무선사업부 상무를 거쳐 현재 글로벌 머신러닝 테크 기업 몰로코에서 헤드 오브 솔루션스 아키텍처로 일하고 있다. 그동안 쌓은 노하우를 개발자 커뮤니티에 풀어놓고자 기술, 개발, 조직 문화를 주제로 강연과 컨설팅 활동도 병행하고 있다. 주요 저서로는 『개발자로 살아남기(2022)』가 있다.
동아비즈니스리뷰 350호 Smart Worcation 2022년 08월 Issue 1 목차보기