개발자에게 물어보세요

만들거나 혹은 죽거나

디지털 시대에 승승장구하고 싶으면 소프트웨어를 만드는 사람처럼 생각해야 한다. … 문제에 직면 했을 때 다음과 같이 질문을 던지는 사람이라면 누구나 소프트웨어 피플이다. “소프트웨어로 이 문제를 어떻게 해결할 수 있을까?” 소프트웨어 피플이 된다는 건 기술이 아니라 사고방식의 차원이기 때문이다.

스티브 잡스가 2007년에 아이폰에 도입한 사고 프로세스의 핵심도 ‘소프트웨어’다. 아이폰에 최초로 도입 한 소프트웨어 키보드는 업데이트가 가능하다. (물리적인 배열이나 인터랙션 등) 반면에 하드웨어 키보드는 필요할 때든 아니든 항상 그 자리에 있어야하고, 버그가 있거나 개선하고자 해도 업데이트가 불가능하다.

핵심 경험과 작업 흐름을 주 단위로 이터레이션 할 수 있으면 어떤 일이 벌어질까? 이것이 소프트웨어적 사고방식이 작동하는 모습으로, 이는 물리적 실체를 디지털화한 다음 문제해결에 소프트웨어적 사고방식을 적용하는 데서부터 시작한다.

👉

소프트웨어의 간단한 역사 (Sass → Cloud → API 의 흐름이 너무 잘 정리되어 있다)

설치형 소프트웨어: 처음에 기업들은 중앙 컴퓨터를 가동 했고, 소프트웨어는 플로피 디스크나 CD에 담겨 판매됐다. 이 당시 소프트웨어는 주로 회계, 자원관리 등 내부 운영을 위한 소프트웨어였다.

Software as a Service, Sass의 등장 (Salesforce). 세일즈포스 페이지에서 양식을 간단하게 작성하고 곧바로 전 부서에 소프트웨어를 가동하면 그만이었다. 소프트웨어에 버그가 있어서 업데이트를 해야 하거나 소프트웨어 판매사가 새 버전의 앱을 소리 소문 없이 출시했다 하더라도 IT 직원이 전 직원의 책상에 일일이 새 버전을 설치할 필요가 없었다. 그런 수정과 업그레이드는 저절로 이루어졌다. 바깥에 있는 클라우드에서 말이다. 또 다른 변화는 사업 모델을 둘러싸고 일어났다. 소프트웨어가 더 이상 필요하지 않으면 잡지를 끊는 것처럼 구독을 중단했다.1999년 세일즈포스가 사업을 시작했을 때 많은 사람들이 베니오프가 정신이 나갔다고 생각했다. 어느 누가 무슨 이유로 소프트웨어에 돈만 내고 소장은 하지 않는단 말인가? 혹시라도 인터넷이 다운되면 어떻게 할 것인가? … 하지만 베니오프는 인터넷이 진일보해 안정화될 것을 알았다. 초고속 인터넷이 표준이 되면서 세일즈포스는 도약했고, … 가장 큰 소프트웨어 회사 중 하나로 성장했다.

Infrastructure as a Service, Iass (AWS). 아마존은 거대한 데이터센터를 만들어 앱 자체가 아니라 개발자나 타 회사가 앱을 만들 때 사용할 수 있는 구성요소 building blocks를 판매하려고 했다. 이렇게 하면 모든 개발자와 회사가 웹 스케일의 인프라 구조에 대한 아마존의 전문 기술을 이용할 수 있을 터였다. … AWS로의 전환은 더 이상 비싼 하드웨어를 구매하지 않아도 될 뿐 아니라, 이 모든 하드웨어를 관리하는 거대한 상근 IT 부서 역시 고용할 필요가 없음을 의미했다. AWS가 미친 다른 영향은 즉시 눈에 보이는 건 아니었다. 하나는 AWS가 신규 기업을 설립하는 비용을 거의 0원에 가깝게 끌어 내렸다는 점이다. … 창업 비용이 낮아지는 것은 스타트업이 크게 늘어남을 의미한다. 또한 스타트업들이 상품을 훨씬 빨리 내놓을 수 있다. 전통적 세계에서는 조직 꼭대기에 있는 CIO나 CFO와 같은 사람들이 IT 관련 결정을 내렸다. 수년의 작업 기간과 수백만 달러가 투입되는 부담스러운 사안이었기 때문이다. 하지만 AWS의 경우 수많은 고객이 평범한 개발자였다. 덕분에 회사가 인프라를 구매하는 방식에 개발자들이 훨씬 많은 영향력을 행사하게 되었다.

API Economy. 2000년대 아마존은 코드와 엔지니어를 거대한 단일체 (monolithic mess)에서 소규모팀과 작은 코드 조각들로 나누었다. 개별 서비스가 보통 한 가지만 전문적으로 담당하게 되면서 이는 ‘마이크로서비스’라고 불리기 시작했다. 이 마이크로서비스들은 코드 파일도, 웹사이트도 아닌 웹을 토대로 한 API로 배포되었다. API는 한 코드가 다른 코드와 대화할 수 있도록 만들어 주는 잘 정의된 인터페이스다. 하지만 또 다른 문제가 있었다. 각 서비스의 효율성을 어떻게 측정하고, 해당 사업이 어디에 돈을 쓰는지 어떻게 확인해야 할까? 한 팀이 만 대의 서버에서 서비스를 운영한다면 그건 좋은 걸까, 아니면 끔찍하게 비효율적인 걸까? … 그래서 아마존은 내부에서도 이런 서비스를 이용하는 데 비용을 매기기 시작했다. 내부 서비스가 내부 고객에 의해 널리 사용되고 빠르게 성장할 때 더 많은 예산을 투입하기 마련이다. 여기서 이야기는 훨씬 더 흥미로워진다. 왜 이런 마이크로서비스를 전부 내부에서 개발한단 말인가? 왜 사내 개발자들이 다른 회사에서 사도 되는 마이크로서비스 개발에 온 힘을 바친단 말인가? 곧 사람들은 마이크로서비스를 만들어 다른 회사에 팔면 사업이 된다는 사실을 깨닫기 시작했다. … 우리는 저마다 정말 해결하기 힘든 문제를 떠안고 솔루션을 코딩하느라 몇 년의 시간을 보냈고, 이제는 다른 사람들에게 그 서비스를 제공하고 있다. 우리의 서비스는 블랙박스다. 고객들은 서비스가 어떻게 작동하는지 알지도 못하고 신경 쓰지도 않는다. … 소프트웨어 개발 팀을 꾸릴 때, 팀의 개발자, 설계자, 기술 리더들이 기본적으로 요구하는 부분이 바로 어떤 영역을 직접 만드는 게 적합한지 정해 달라는 것이다.

제 이름은 제프고 개발자에요

통신 시스템과 상호작용할 수 있는 소프트웨어를 만드는 일은 알고 보니 말도 안 되게 어려운 도전이었다. … 하지만 그 세계를 파고 들며 정말 얼마나 힘든지 깨달으면서 우리는 훨씬 더 고무되었다. 축적된 세계가 다루기 힘들수록, 이를 단순화하고 고객경험을 개선할 기회는 더욱 커졌다.

사업가와 개발자가 제대로 협업하게 만드는 열쇠는 사업가가 해결책이 아닌 문제를 공유하는 것이라는 사실이다. 매트는 내게 어떤 코드를 작성하라고 말하지 않았다. 자신이 어떤 종류의 앱을 원하는지도 몰랐다. 장황한 설명서를 쓰지도 않았다. 그저 ‘X를 하면 멋지지 않을까요?’ 아니면 ‘Y를 할 수 있는 방법이 있을까요?’라고 말했다. 그는 소프트웨어에 까막눈이었고, 이게 결국 신의 한 수였다. 그가 문제를 해결해 달라고 부탁하는 바람에 내가 더욱 몰두하게 됐기 때문이다.

코드는 창의적이다

배를 만들고 싶으면 사람들을 불러서 목재를 모으고 하나하나 지시하면서 일감을 나누기보다는 무한한 대양을 동경하게 만들라. <앙투안 드 생텍쥐베리>

많은 개발자들이 다음 말을 신념으로 여긴다. “엔지니어링은 세상에서 가장 창의적인 직업 중 하나라고 생각합니다.” 아마존의 최고기술책임자 버너 보겔스의 이야기다. “매일 새로운 무언가를 만들어 내잖아요. 엔지니어링은 굉장히 창의적인 직업이에요.

훌륭한 프로덕트 매니저는 개발자가 고객의 욕구에서 관심을 돌리는 게 아니라 오히려 고객의 문제를 잘 이해할 수 있도록 돕는다. 프로덕트를 사용하는 사람과 만드는 사람 사이에 층이 많으면 많을수록 상황은 나빠진다.

해당 사업이 가지고 있는 가장 복잡하고 두려운 문제를 분명히 파악한 뒤 사내에서 ‘솔루션을 요청’해 보라. 모든 해결책이 옳거나 따라야 할 가치가 있는 건 아니지만, 거대한 문제의 틀을 제시하면 개발자에게 고용주와 동일한 문제를 고민하는 기회를 주게 된다.

좋든 싫든 우리는 모두 자신의 아이디어와 사랑에 빠진다. 오너십을 고취시키는 데, 자신만의 솔루션을 떠올려 보라고 하는 것보다 더 좋은 방법이 있을까?