이 책은 SMS, 전화를 API로 제공하는 twilio의 창업자이자 CEO인 제프 로슨이 2021년에 쓴 Ask Your Developer의 번역서다. 당시 트위터에서 추천하는 내용이 많이 보여서 원서를 구매했지만 결국 읽지 못하고 있었는데 다행히 번역서가 나오게 되어 읽게 되었다.

"Ask Your Developer"라는 말은 twilio가 상장하기 전에 샌프란시스코 옥외 광고를 하면서 사용했던 문구이다. twilio가 많이 쓰이지만, 내부에서 문자나 전화를 걸 때 사용하므로 서비스 전면에 드러나지 않기 때문에 twilio가 뭔지 궁금하다면 당신에 회사의 개발자에게 물어보면 알 거라는 의미가 담겨있다.

또한 개발자가 사업에 훌륭한 파트너라는 의미가 담겨 있는데 소프트웨어로 혁신하려는 회사라면 "개발자에게 묻기"라는 사고방식을 가져야 하고 그게 어떤 의미인지를 설명하는 게 이 책의 핵심이다.

제프 로슨이 CEO이지만 개발자이기도 하고 twilio를 운영하면서 많이 고민했기 때문인지 내 생각과 비슷한 부분도 많고 정리도 잘 되어 있어서 아주 재미있게 읽었다. 이 책은 아마 개발자와 협업해야 하는 경영진이나 리더들이 읽어보라고 썼을 거 같은데 소프트웨어 조직에 있다면 재밌게 볼 수 있을 것 같다. 책의 의도가 그래서이긴 하지만 모든 내용이 개발자로 귀결되기 때문에 다른 직종의 사람은 읽으면서 불편할 수 있겠다는 생각은 들었다. 서비스를 만드는 데 필요한 많은 직종의 사람 중에서 개발자만이 중요하다고 말하는 것은 아니라고 생각하기에 이 책의 내용에 동의하고 있다.

1부 왜 그 어느 때보다 지금 개발자가 중요한가

하루아침에 소프트웨어는 아웃소싱 대상에서 벗어났다. 이제 소프트웨어 경쟁적 우위를 점하기 위한 원천이다.

디지털 시대에 승승장구하고 싶으면(도전자든 타이틀을 방어하는 챔피언이든) 소프트웨어를 만드는 사람처럼 생각해야 한다. 소프트웨어를 만든다고 꼭 개발자를 말하는 것은 아니다. 문제에 직면했을 때 다음과 같이 질문을 던지는 사람이라면 누구나 소프트웨어 피플이다. "소프트웨어로 이 문제를 어떻게 해결할 수 있을까?" 소프트웨어 피플이 된다는 건 기술이 아니라 사고방식의 차원이기 때문이다.

1부에서는 디지털 시대가 되면서 소프트웨어의 중요도가 무엇이 달라지고 있는지를 설명한다.

소프트웨어를 만드는 회사가 되고 싶다면 조직 전체의 사고방식을 바꾸는 것부터 시작해야 한다.

제3의 소프트웨어 황금기에는 누릴 수 있는 것도 많지만 중요한 질문거리도 있다. 개발자와 회사의 리더는 어떤 마이크로서비스를 서드파티에서 구매하고, 어떤 마이크로서비스를 자체적으로 만들지 계속해서 결정한다.

고객을 직접 상대하는 소프트웨어는 꼭 만들어라. 왜냐면 차별화된 경험은 구매할 수 없기 때문이다. 그건 직접 구축하지 않고는 길이 없다.

다른 회사보다 경쟁력을 가지려면 소프트웨어를 잘 만들어야 하는데 SaaS 서비스를 이용할 수도 있고 이젠 클라우드 시대에 점점 그런 부분이 가속화 되지만 고객에게 차별화된 경험을 제공하려면 직접 구축해야 한다고 이야기하고 있다.

2부 개발자를 이해하고 동기부여 하기

2부에서는 제프 로슨이 과거 창업을 하고 아마존이 AWS로 클라우드 시대를 만들던 초기에 AWS에서 일하면서 배운 과정과 그 뒤 창업한 과정을 설명한다. 책 내내 많이 나오지만, 많은 생각이 아마존에서 배운 경험을 바탕으로 하고 있고 AWS라는 엄청난 결과물이 있어서인지 그때의 경험이 제프 로슨에게 크게 영향을 끼친 것으로 보인다.

바로 사업가와 개발자가 제대로 협업하게 만드는 열쇠는 사업가가 해결책이 아닌 문제를 공유하는 것이라는 사실이다.
매트는 내게 어떤 코드를 작성하라고 말하지 않았다. 자신이 어떤 종류의 앱을 원하는지도 몰랐다. 장황한 설명서를 쓰지도 않았다. 그저 'X를 하면 멋지지 않을까요?' 아니면 'Y를 할 수 있는 방법이 있을까요?'라고 말했다.

이 책은 사실상 소프트웨어에 대한 내용이 아니다. 그보다는 사람에 대한 것이다. 고객의 니즈를 듣고 대답하기 위해 함께 일해야 하는 소프트웨어 개발자와 기업가에 관한 것이다.

나는 실리콘밸리를 방문하러 온 전 세계의 경영진에게 다음과 같이 강력하게 조언한다. 개발자들과 함께 문제를 공유하라. 해결책이 아니라.

무언가 요구할 때 문제 상황을 공유하라고 한다. 이는 꽤 공감하는 부분인데 보통 해결책, 그러니까 어떤 문제를 해결하기 위해서 방법을 찾다가 "A가 필요하다"같은 해결책을 얘기하기 마련인데 이것보다는 A가 필요한 원인이 무엇인가부터 다시 얘기해야 하고 나도 이런 접근을 더 좋아하는 편이다. 이건 기업가와 개발자뿐 아니라 개발자와 개발자 사이에서도 많이 발생하는 일이다.

이런 난제를 해결하려면 기업이 먼저 코드가 창의적이라는 것을, 많은 개발자가 실은 창의적인 문제해결사라는 것을, 그러니 그렇게 대접받아야 한다는 것을 이해하는 것부터 시작해야 한다.

이게 바로 소프트웨어를 빨리 개발하지 못하는 어려움을 겪는 이유다. 개발은 언제나 사측이 원하는 것보다 오래 걸리는 것처럼 보인다. 채드 에츨(일명 재지 채드)은 이런 일이 매니저가 개발 초반에 문제를 정의할 때 개발자를 배제하고 어떤 솔루션을 구축해야 할지 지시만 하는 잘못된 프로세스에서 비롯한 자연스러운 결과로 본다.

개발자라는 직군의 사람을 회사에서 어떻게 다루어야 하는지도 설명하고 있다.

기업은 직원들에게 공평한 대접을 받고 있다고 느끼는 수준까지만 보상해야 한다. 공평함의 기준을 충족시키고 나면 직원들은 자율성, 숙련도, 목적처럼 일을 하는 진짜 이유에 집중한다.

자율성의 본질은 내린 결정을 신뢰받는 것이다. 만약 누군가가 자신의 결정에 거부권을 행사할 수 있으면 별로 자율적이지 않다는 뜻이다.
... 중략 ...
팀원이 신뢰받고 있다고 느끼기를 바라는 현명한 리더는 팀원의 결정을 뒤집으려는 유혹에 저항하면서, 오히려 지나치다 싶을 정도로 자율성을 강조한다고 나는 생각한다.
... 중략 ...
개발자들에게 자율성을 부여함으로써 업무를 잘 해내리라 믿고, 도구를 제공하는 동시에 약간의 테두리와 규칙을 설정하는 게 좋다. 이렇게 하면 규모가 큰 조직에서는 자율성을 완전히 보장하는 것보다 훨씬 효율적이다.
... 중략 ...
자율성은 사실 개발자가 이리 뛰고 저리 뛰면서 내키는 대로 하도록 손 놓고 있는 게 아니라 규칙을 기반으로 한다. 테두리가 없으면 팀원은 어떻게 결정을 해야 할지 알 수 없고, 리더는 계속 사후에 비판하게 된다. 규칙을 정하면 역설적으로 경계 안에서 사람들이 자유롭게 움직일 수 있다.

자율성에 대해서는 많이 공감하면서도 제프 로슨이 자율성을 엄청나게 강조하고 이를 지키기 위해서 노력한다는 것을 느낄 수 있었고 나도 자율성을 중요하기 시작하지만 이렇게까지 할 수 있다고? 하는 생각도 많이 들었다.(내심 twilio 직원이 이 책을 읽을 때 어떤 기분일지 궁금하기도 했다. 공감할지? 아닐지)

목표관리를 어떻게 할지를 놓고 엄청난 에너지를 소모하는 기업들이 널렸다! 때로는 목표 관리를 설정하는 데 시간이 너무 오래 결려서 완료될 때쯤에는 목표와 관련성이 없어지거나 헛다리를 짚게 되기도 한다.

가장 좋은 보상 계획은 직원들이 공평하다고 느끼면서 그들의 관심을 보상에서 일로 옮기는 것이다.

내 신념은 이렇다. 보상이 커야 동기가 커진다는 믿음으로 상황을 흐리지 말고 그 대신 직원에게 넉넉히 임금을 지불해서 공평하다는 느낌을 주자. 특히 창의적인 직군에서는 말이다.

목표와 보상은 참 어려운 일이지만 전반적으로 동의를 많이 하게 되었다. 결국 스타트업이란 건 일을 좋아하는 사람들이 많이 있는 편이고(모든 사람이 그럴 수는 없다) 그 때문에 다른 것보다 일에 집중하게 해야 한다고 생각한다. 책에서도 많이 나오지만, 오히려 반대로 하는 회사들이 엄청나게 많고 나도 많이 겪어봤다.

3부 개발자를 성공으로 이끄는 법

3부에서는 개발자에게 어떤 환경을 제공해야 하는지를 주로 얘기한다.

내가 말하는 학습은 야심 찬 직원들이 자발적으로 수행하는 과외 활동이 아니라, 기업의 구조와 문화 안에 내재돼 있는 것을 뜻한다. 엄혹한 실정에서 배우는 실습을 통한 학습을 의미한다.

마음 깊숙한 곳에선 성공을 위해선 목소리가 큰 사람이나 직급이 가장 높은 사람의 말이 아니라 최고의 대답이 필요하다는 것을 당신도 알고 있을 것이다. 리더는 정치가 아니라 지식과 진실이 이기기를 바란다. 리더는 팀이 지속적으로 학습하기를 바라고, 미래의 리더가 당신보다 뛰어나기를 바라고, 일선에서 고객을 상대하는 팀이 누구보다 현명하기를 바란다.

열린 학습 환경은 조직이 모든 답을 갖고 있지 않음을 받아들이고, 불확실성에 익숙하며, 매일 조금씩 나아지고자 노력하는 환경을 말한다. 이는 경직되기보다 융통성 있고, 사람들이 끊임없이 진실을 찾는 문화를 만드는 것을 의미한다.

열린 환경은 문제를 공유함으로써 사람들에게 자율권을 주는 곳이다. 그저 거대한 문제를 던져 놓고 사람들에게 빠져 죽든 헤엄치든 알아서 하라고 하는 게 아니다. 리더인 당신에게 여전히 결과에 대한 책임이 있으므로 물에 그냥 빠뜨리는 건 그다지 좋은 방법이 아니다. 오히려 열린 환경은 (a)테두리와 (b)지원책을 제공한다.

이 열린 학습 환경이라는 말이 꽤 인상적이었다. 학습 환경을 만든다는 것은 생각보다 어려운 일이고 현실에서는 (어떤 이유로든) 모든 사람이 비슷한 정도로 성장에 관심이 있고 항상 적극적인 것은 아니기 때문에 실제로 조직에서 이런 환경을 만들때의 문제들에 대해서도 생각이 났지만, 목표나 지향점으로는 공감하고 있다.

"이곳에선 소크라테스식 문답법을 사용합니다. 제가 누구를 지정해 질문하면 그 학생이 대답합니다. 그냥 강의를 하면 될 것을 왜 이렇게 할까요? 제 질문을 통해 여러분이 자신을 가르치는 법을 배울 것이기 때문입니다."

미션을 맡기는 건 단기간의 성과보다는 학습을 위한 것이다.

나는 트윌리오의 목표가 자율적이고, 진실을 추구하고, 올바른 결정을 내리는 리더 집단을 만드는 것이라고 생각한다.

twilio에서는 Hatch라는 수습 프로그램을 통해서 개발자를 트레이닝시키는데 여기서 정규직 전환율이 90%에 달한다고 해서 Hatch라는 프로그램의 내용도 꽤 궁금해졌다. 자세히 설명하진 않지만, Hatch라는 프로그램의 특성 자체로 twilio가 추구하는 문화에 더 어울리는 사람이 더 잘 지원할 수 있게 하고 여기서 뽑힌 사람들이 정규직으로 들어와서 twilio의 문화가 잘 자리 잡는다는 생각이 들었다.

나는 직원들이 본질적 동기를 느끼고 성공하기 위해 달려가기를 원치 않는 비즈니스 리더를 본 적이 없다. 하지만 보통 기업의 구조는 직원들의 원초적 동기를 빼앗게끔 설계되어 있다. 조직도는 직원과 고객을 분리시키고, 의사결정 과정은 직원이 무력감을 느끼게 만들며, 성공은 고객에게 봉사하는 것이 아니라 조직에서 살아남는 것이 된다. 거의 모든 기업이 규모를 확장하면서 이런 운명에 어느 정도 굴복하고 만다.

아마존에서 경험을 통해 배워온 대로 twilio도 작은 팀을 많이 구성해서 회사를 운영하고 있다. 그 작은 팀에 자율성을 부여하고 그 리더가 팀을 이끌게 하고 있다.

단언컨대 소규모팀을 확장하는 데 가장 중요한 마지막 부분은 당연히 리더십이다. 소규모팀의 팀원들이 임무에 집중하고, 자율적으로 힘든 결정을 내리고, 고객에게 서비스를 신속하게 제공하는데 헌신하기를 바란다면 리더의 역할이 중요하다. 우리는 이런 리더를 '단일 스레드(single threaded)' 리더라고 부른다. 아침에 일어나면서 어떻게 해야 팀의 성과를 올릴 수 있을까, 이 한가지만 생각하기 때문이다.

어쩌면 최고에 못 미치는 결정이 나올 수도 있다. 하지만 결정을 폐기하는 것의 대가와 리더에 대한 신뢰를 폐기하는 것의 대가를 비교해 보라. 그 결정으로 인해 회사가 망하거나 고객에게 지속적으로 피해를 입힐 것 같으면, 그렇다. 경영진이 개입하는 것이 옳다. 문제는 종종 경영진이 중요하지 않은 하찮은 결정에 개입하는 것이다. 이를 '바이크쉐딩(bikeshedding)'이라고 한다.
바이크쉐딩은 비전문가인 책임자가 정말 중요한 결정에 필요한 맥락을 잘 몰라서 하찮은 세부사항에 엄청난 에너지를 소비하는 경향을 의미한다.

팀 리더가 자연스레 상부에 권한을 넘기기도 한다. 결정이 올바른지 확인하기 위한 차원이지만, 어려운 결정을 내릴 때는 상사에게 결정해 달라고 부탁하기 쉽다. 하지만 이건 책임을 회피하는 행동이며, 리더에게 자율권을 부여하는 문화를 형성하는데 좋지 않다. 경영진으로서 나는 대답보다 질문을 더 많이 한다.

소규모 팀을 많이 구성하면서 자율성에 관해서 많이 고민한 것을 알 수 있었다. 실제로 이렇게 해야 일을 더 제대로 하고 잘할 수 있다는 점에 동의한다. 이 책은 경영진과 개발자 혹은 각 팀의 관계에 많이 집중되어 있지만 현재 소규모 팀을 리드하고 있다 보니 비슷한 고민을 많이 하게 되었다. 나는 어느 정도로 자율성을 주고 있고 어디까지 개입할 것인지 현재도 많이 고민하고 있는데 훨씬 큰 조직을 운영하는 제프 로슨도 더 많은 자율성을 주기 위해 노력하는 부분에 다시 좀 돌아보게 되었다.

소규모 자율적 팀이 많아져서 곧 규모를 확장해야 할 때 생기는 한가지 문제는 팀의 업무를 어떻게 조정할까 하는 것이다. 팀이 많을수록, 팀의 자율성이 클수록 협력하기가 어려워지는데 많은 경영진이 이를 불만스러워한다. 사실 일이 잘 풀리지 않으면 경영진이 해답이라면서 "협업을 더 잘해야 합니다."라고 소리치는 경우가 다반사다. 그럴싸한 말이다.
... 중략 ...
나는 이를 '더 나은 협력의 오류'라고 부른다. 소규모팀은 협력을 덜 필요로 한다. 스타트업과 마찬가지로 고객 및 미션과 관련된 소수의 주변 사람들에게만 시간과 관심을 쏟으면 되기 때문이다. 물론 의미 있는 작업을 수행하려면 팀들이 서로 작용해야 한다.
... 중략 ...
그러므로 팀 간의 관계를 '서비스 계약'으로 공식화하는 것이 중요하다. 각 팀을 각기 다른 스타트업으로 가정해 보라. 다른 팀과 거래한다는 건 프로덕트가 잘 정의돼 있고 가격이 잘 합의됐다는 의미다.

하지만 회사 내부에서는 이 모든 게 느슨하다. 만약 모든 팀이 '이것이 우리가 하는 일이고, 이렇게 하면 우리와 함께 할 수 있다'고 공식적으로 정리해서 다른 팀에 노출하면 협업 비용이 절감된다. 이것이 팀 간 상호작용을 표준화하면서 프로세스를 이해하기 쉽고 확장 가능하도록 만드는 방식이다.

나는 협업을 개선하는 것이 목표가 되어선 안된다고 생각한다. 이보단 협업을 줄이는 것이 목표가 되어야 한다.

재미있는 생각이라고 생각했다. 협업 개선이란 말을 나도 종종 하는 편인데 협업 자체를 없앨 수 있는지를 고민해 보는 건 중요한 지점이라고 생각한다.

첫째, 고객이 인간화된다. 개발자들은 요구사항 문서가 아니라 고객이 무엇을 필요로 하는지, 왜 필요로 하는지 그들의 입으로 직접 들을 수 있다. 그러면 문서로 변환되는 과정에서 사라지기도 하는 표현의 깊이나 수사가 그대로 전해질 가능성이 높다.

둘째, 개발자로 하여금 일의 중요도와 들어가는 시간을 계산해 직감적으로 결정을 내리게 한다. 프로덕트 매니저는 전체 계획상 별로 중요한 것 같지 않다며 '잔액을 숨기는' 기능을 후순위로 미룰지도 모른다. 솔직히 그게 맞을 수도 있다. 하지만 이 기능을 만드는 데 90일이 아니라 90분밖에 안 걸린다는 걸 알면 마음이 바뀌지 않을까? 난 그럴 거라고 생각하낟. 개발자는 보통 이를 빨리 계산할 수 있으므로 직감적으로 가장 이득이 되는 아이디어를 고를 수 있다.

기능을 구현하는 개발자가 고객의 목소리를 직접 듣게 하는걸 매우 강조하고 있다. 과거에 고객지원을 돌아가면서 해본다거나 하는 시스템에 있었던 적도 있는데 정말 나에겐 괴로운 시간이라 좋아하진 않고 앞으로도 싫을 것 같긴 하지만 개발자가 정말 문제가 뭔지를 이해하는 것은 중요하다고 생각한다. 앞에서 해결책보다 문제를 공유하라는 것처럼 종이에 만들어진 기획서만 보는게 아니라 실제로 무슨 문제인지를 이해하면 더 쉽고 좋은 해결책이 나올 수도 있다고 생각하고 이전 경험에서도 문제를 이해하고 나니 훨씬 짧은 시간의 문제를 해결할 수 있었던 경험도 있는 편이다.

팀이 고객의 위치에서 생각하는지 알아보기 위해 내가 즐겨 사용하는 방식은 회사를 돌아다니며 개발자들에게 어떤 고객 문제를 해결하고 있는지 물어보는 것이다. 그들이 어떤 기능을 개발하고 있는지 말해 주면 나는 그 기능이 어떤 고객 문제를 해결하는지 물어본다. 대답을 못 하면 그건 그 팀이 고객과 충분히 접촉하지 못하고 있다는 뜻이다.

요즘 수많은 회사가 어떤 형식으로든 애자일적인 접근방법을 사용하고 있기 때문에 애자일에 관해서도 설명하고 애자일 적용으로 인한 문제도 얘기하고 있다. 나도 여전히 애자일은 무척 좋아하지만, 국내에는 애자일의 잘못된 적용으로 인해서 애자일이란 말 자체도 싫어하는 사람들도 꽤 있을거라고 생각한다.

일부 회사는 개발자들에게 이와 똑같은 짓을 하고 있다. 그들은 창의적 인재를 고용한 뒤 네모난 공장에 집어넣고 칸반 보드에서 포스트잇을 뜯으면서 상상력이라곤 찾아볼 수 없는 소프트웨어 프로그램을 쏟아 내게 만든다. 사람들은 훌륭한 개발자를 고용하기 힘들다고 가끔 불평하는데, 그러면 나는 개발자를 조립라인 노동자처럼 취급하면 분명 구하기 힘들거라고 대답한다.

애자일 그 자체는 개발자에게 나쁘지 않다. 사실, 아주 좋다. 하지만 애자일을 실행하는 사람들이 개발자가 사업에 지속적으로 참여하고 개발을 자신에게 주어진 과제가 아닌 협업으로 여길 수 있도록 주의를 기울여야 한다.

애자일 선언문의 가치는 완전히 동의하지만, 그로 인한 절차나 규칙은 크게 신경 쓰지 않는 편이긴 하다. 사실 그 규칙을 만들려고 시간 쓰는것 조차 별로 좋아하지 않고 (내가 보통 그렇듯이) 대충 두루뭉술하게 하는 편인데 이 책에서도 비슷한 얘기를 하고 있어서 반가웠다.

일부 회사는 강사나 컨설턴트, 엄격한 규칙과 절차를 잔뜩 갖추고 애자일을 전면적으로 실행하기보다는, 납득이 되는 몇 가지 원칙만 고수하고 나머지는 폐기한다. "형식적인 방법론을 사용하지 않은 지 오래 되었어요." 브레이커의 공동 설립자이자 CTO인 레아 컬버는 이야기 한다.

마지막 장은 "인프라 구조에 투자하라"는 얘기가 나왔는데 지금 하는 일과도 연관이 있어서 더 반가웠다. 아무래도 인프라를 갖추려면 비용이 많이 들기 때문에 경영진이 봐야 할 이 책에서 인프라의 중요성을 강조하기 위함이라고 생각한다. 여기서 인프라 구조는 서버 같은 인프라 비용을 얘기하는 게 아니라 인프라팀 혹은 플랫폼 팀처럼 회사의 개발자가 일을 더 잘할 수 있도록 지원하는 개발자 조직을 얘기하고 있다.

페이스북에서 이는 척 로시(Chuck Rossi)라는 남자에게서 시작됐다. 척은 2008년 페이스북의 첫 '릴리스 엔지니어'로 고용되었다.
로시는 개발자가 더 빨리 소프트웨어를 구축할 수 있는 플랫폼 및 프로세스를 제공하는 동시에 고객과 회사를 처참한 결과로부터 보호할 수 있는 보호막을 갖추어, 개발자가 빠르게 움직여도 너무 큰 손해가 발생하지 않도록 했다.

제이슨은 이를 '비포장도로' 대 '포장도로'라고 부르는데, 우리가 선택한 툴을 사용하면 포장도로에서 운전하는 것처럼 가는 길이 편할 거라는 뜻이다. 하지만 본인이 원한다면 비포장도로를 선택해 덤불을 헤치고 흙길을 달려도 괜찮다.

인프라 엔지니어야말로 전체 개발팀을 더욱 효율적으로 만든다. "플랫폼이 힘을 배가시킵니다." 제이슨은 말한다.

특히 비포장도로/포장도로의 비유는 인상적이라서 나도 써먹어야겠다는 생각이 들었다. 비용처럼 보이지만 실제로는 몇 개로 이득을 얻을 수 있는 투자라고 강조한다.