neozest : neo+zest

  업계에서 일한 시간이 하나둘씩 쌓이다 보니 나의 앞길을 어떻게 꾸려나가야 할지도 고민이지만, 업계 후배들에게 어떤 식으로 나의 고민과 경험을 전달해야 할지, 어떤 식으로 일을 하는 것이 개인과 업의 성장을 돕는 것일지 고민하는 시간이 많아지고 있다. 그러한 고민을 하는 사람들이 많아서일까 길벗에서 관련 책을 시리즈로 내고 있다. 

 스태프 엔지니어에 대한 책이 새로 나와서 읽어봐야지 하던 차에 길벗 리뷰어 프로그램이 있어 신청해서 출판사로 부터 책을 받아 읽게 되었다. (이 시리즈에서 처음으로 내돈내산이 아닌 책이다.)

 나는 해외에서 개발자로 8년정도 근무한 경험이 있는데, 내가 근무했던 회사들에도 스태프 엔지니어라는 직함은 최근 생겼다. 함께 일했던 친구들도 이제는 꽤 많이 스태프 엔지니어라는 직함을 달고 있다. 보통 Senior Engineer 이후 Principal Engineer로 가는 트랙이었는데, 몇년전부터 Staff Engineer라는 직함을 단 친구들이 생겼다. Principal은 왠지 약간의 학술적, 연구적 느낌이 드는 편인데, Staff는 약간 Tech Leader 성격이 느껴지는 명칭이다.

 정확한 업계의 명칭과 역할에 대한 깔끔한 공감대가 없다 보니 스태프엔지니어란 무엇이며, 어떤 역할을 해야하고, 그 역할을 수행하기 위해 어떤 것을 고려해야 하는지부터 이 책은 시작한다. 이어 스태프 엔지니어라는 직책을 얻기 위한 방법과 심지어 이직까지 소개한다. 이후 14인의 현직 스태프 엔지니어 인터뷰를 통해 앞에서 다룬 내용들이 현실에서는 어떻게 이루어지는지를 공유해주고 있다.

 책을 읽으면서 이 책의 저자는 전형적인 이과 타입이라는 생각이 들었다. :)  각 챕터들이 도입부가 있는데, 도입부에서 다루고자 하는 내용의 요약이 모두 들어 있다. 이후 본론에서는 세부 항목을 상세히 다룬다. (차례에서 이 깊이까지 목차가 정리된 것이 아니라서 좀 아쉽다. 한단계더 깊이 들어간 차례가 있으면 한번 읽고난 후 차례를 보면서 다시 생각해 보는데 편했을 것 같다.) 예를 들어 "엔지니어링 전략의 작성(p.70)" 부분을 보면 이 단락의 구조가 다음과 같이 이루어진다는 것을 알 수 있다.

• 엔지니어링 전략의 작성
  
  • 언제 그리고 왜 필요한가(p.71)
  • 설계 문서 5개 작성하기(p.72)
  • 설계 문서 5개로 전략 수립하기(p.74)
  • 전략 5개로 비전 수립하기(p.76)

따라서 이 책을 한번 빠르게 읽으면서 저자의 의도를 이해했다면 각 챕터별 중간 제목을 읽어가면서 나름의 생각으로 저자의 주장에 찬성/반박하면서 읽는 것도 재미있게 이 책을 즐길 수 있는 방법중 하나일 것 같다. 나는 몇몇 챕터를 읽는 동안 저자의 주장에 동조하기 어려워서 '그럼 너라면 **** 이런 경우 어떻게 하는게 맞는 것 같냐?'라는 질문을 던지면서 저자의 반박을 생각하면서 읽었는데, 재미있었다. 

  개발자가 년차가 높아지면 기술 관리자(Engineering Manager) 또는 팀 리더(Team Technical Leader) 의 새로운 역할을 맡게 될 수 밖에 없다. 이건 내가 겪은 바에 따르면 우리나라를 비롯하여 서구권도 마찬가지이다. 하지만 '반백의 개발자'라는 로망이 있을 수 밖에 없는 엔지니어의 습성은 늘 관리자 트랙에 대해 잘못된 오해를 불러 일으킬 수 밖에 없다. 스태프 엔지니어의 R&R은 이를 극복하여 이 책의 부제처럼 '관리트랙을 넘어선 기술 리더십'을 만들어 가기 위한 업계의 고민과 그에 대한 해결방안으로 보인다. 이 책은 그 고민들의 갈피를 잡아줄 내용들로 구성되어 있다. 사실 이런 책들은 다른 기술 서적처럼 구체적인 답들을 제공해 준다라기 보다는 업계의 동료들이 나와 비슷하게 이런 고민을 하고 있고, 나와 비슷하게 이런 방식으로 해결하고자 하고 있구나 하는 공감대를 제공해 주는 게 가장 큰 가치라 생각한다. 

 이 책에서 가장 마음에 와닿았고 도움이 된 부분은 챕터 2 '스태프 엔지니어로 활동하기' 부분이었다.  전체 9가지의 세부 챕터로 이루어 지는데, 기술 리더십을 가지려면 어떻게 해야 하는지에 대한 다방면의 접근 방식이었다. 특히 현업 개발에 치이고 있을 때 기술 리더로써 좀 더 중요한 일에 집중하면서, 팀 전체의 기술 품질을 향상시키고, 지휘권을 가진 상위 상사(임원이나 상위 매니저)들과 협력하기 위해 그의 리더십을 따르면서, 구성원이 여유를 가질 수 있는 공간을 마련해 주기 위한 네트워크를 형성하는 방법.. 각각이 현업에 있는 시니어들에게 다시금 자신의 역할과 자신에게 기대되는 수행 능력을 되짚어준다고나 할까? 2.6 챕터의 '절대 틀리지 않는 방법' 같은 경우도 무척이나 실용적인 방법을 되짚어 준다.

  번역은 무난한 편이었다. 살짝 아쉬운 부분이 군데군데 있긴 한데, 번역이 잘못되어 있다기 보다는 이런 기술 에세이를 번역할 때의 어려움과 번역자의 고민이 느껴졌다. 서구권 개발/업무 문화를 기반으로 쓰여진 내용일 경우 이를 배경 맥락이 없는 국내 독자들에게 전달하려다 보니 우리 글로는 조금 어색한 부분들도 있지 않았나 생각했다. 앞에서 인용한 문구의 경우도 기술과 아키텍쳐에 대한 이해와 같은 수준으로 발전시킨다기 보다는 "본인이 가질 수 있는 기술적인 신념(종교)에 대해 실용주의적 관점과 아닐 수도 있다는 불가지론적 관점을 동등하게 가져야 한다. (사실 본인이 가진 기술적 신념을 맞다고 보고 그 효력을 어떻게 얻어낼 것인지를 더 고민하는 실용주의 관점과, 그것이 본질적으로 틀릴 수도 있다고 바라보는 불가지론적 관점을 가지고 기술과 아키텍쳐를 바라보아야 한다.)" 가 좀 더 적절한 해석이 아닐까? (뒤에 이어진 문장은 'This can feel like a paradox, but it's the line you'll need to walk every day.'인데, '결국 상반되는 pragmatism과 agnosticism 두가지 관점이 매일 일상속에서 겪어야 할 여정이다'라는 번역을 떠올렸다.)

이 책에서 눈에 들어온 문장들 몇개를 정리해본다.

• 자신의 네트워크가 자신에 대한 솔직한 피드백을 얻는 가장 중요한 방법(p.124) : 인맥의 정의를 제대로 설명했다고 본다. 이해 당사자들은 제대로 전달해 주지 못하는 솔직한 피드백을 줄 수 있는 사람. 그 피드백으로 자신의 성장을 조정할 수 있는 사람이 제대로 된 인맥을 가지고 있다고 생각.
• 임원과  의사소통할 때는 대부분 계획, 상태 보고, 어긋난 일 해결 세가지 중 하나. (p.132)
• SCQA형식: 현상황(Situation)-> 문제점(Complication)->의문점(Question)->해결책(Answer) (p.133)
• 스태프 엔지니어가 된다는 것은 생각의 범위를 넓히는 것.... 협업으로 전체 팀의 기술 및 소셜 스킬을 발전시켜야 한다.(p.220)
• 향후에는 어떤 모습일까, 어떤 문제를 해결해야 할까, 어떤 목표를 이룰 수 있을까? (p.268)

이 책의 내용을 잘 소화하려면 주석에 달린 링크 글도 찾아가 읽어보는 것이 좋겠다. 틈나는대로 구글 번역기와 함께 링크들을 읽었는데, 나는 특히 40년 경력에 대한 글(https://lethain.com/forty-year-career/)이 너무 좋았다. Junior>Senior>Staff로 이어지는 여정 속에서 각 단계별로 중요한 기준점들이 다를 수 있는데, 이 링크글에서는 나름의 깨달음을 얻었다고 할까? 이런 주옥같은 글들이 각주에 많이 소개되어 있다.

✔ 원문 초안은 웹으로 공개되어 있다.: https://staffeng.com/guides/

✔  책 읽으면서  잘못 인쇄된 부분도 찾아 보고했다; 66쪽 각주 오류. 13번 각주는 https://lethain.com/productivity-in-the-age-of-hypergrowth 이다. 다음 인쇄본에 반영된다고 한다.

 같은 출판사에서 나온 <Geek>은 애플 컴퓨터의 역사라면 <안드로이드 뜻밖의 역사>는 안드로이드 창세기이다.

재미있게 일으면서 안드로이드의 성공에 대해, 빅테크의 전쟁에서 잘 알려지지 않은 모습을 많이 알게 되었다.

p7 안드로이드의 멋진 점 한 가지는요. 거의 모두가 이런 일을 전에 해봤다는 거예요. 나는 이미 실수해 봤고, 그 실수로부터 배운 게 있는 일을 하고 있어요. 모두가 그렇죠

p20. 우리 대부분은 안드로이드를 만들기 전에 수많은 실패를 겪었어요. 상황이나 시기나 다른 무언가가 성공하는데 들어맞지 않았죠... 그렇지만 우리는 계속 시도했고, 각각의 실패로부터 배웠고, 거기에서 얻은 지식을 안드로이드를 개발하는데 적용했습니다.

p.51  구글은 똑똑한 엔지니어는 어떤 종류의 프로그래밍 작업이든 할 수 있다는 믿음을 가지고 있었다.  

p.81 (SD카드를 키웠다 뺏다 하는 테스트) ... 로봇을 이용해 폐쇄 루프를 만들었고, 그 덕분에 시스템이 확실히 동작할 때까지 모든 버그를 추적할 수 있었다.

p.86 내가 커피를 흘릴 확률은 내가 움직이는 속도에 비례한다. 실행속도에도 그만한 절충이 따른다.

p.94.  전원이 어디에 쓰이고 있는지 알 수 있도록 계측 instrumentation 기능을 추가한 것이다.... 문제가 어디에 있는지 알게 되자 그 문제를 해결할 수 있었다.

p.105  루빈은 어려운 결정을 해서 조직이 재빨리 실행에 옮길 수 있도록 하려는 경향이 있었다. (앤디루빈이 안드로이드의 기본 언어를 자바로 결정하는 과정)

p.106. 누군가 그걸 좋아했기 때문이 아니라 플랫폼이 성공하려면 타당했기 때문이고, 팀이 거기에 적응한 것이다.

p.138 우리는 정말 좋은 솔루션에 투자하는데 우선순위를 두지 않았습니다. 그냥 바로 시작해서 결과를 내놓고 그걸 반복할 수 있다고 증명하자였어요.

p.146 가상 GPU를 만든 접근 방식은 안드로이드가 초기에 취한 제품대 플랫폼 접근 방식의 예이다. 플랫폼 접근 방식은 첫 출시 이후로도 확장할 수 있는 소프트웨어 레이어를 만드는  것.... 1.0을 만들면서 신속하고 실용적인 결정을 내렸다. 

p.176 팀은 일을 어떻게 해야 하는지에 관해 회의를 하거나 위원회를 열거나 논쟁을 벌이는데 시간을 많이 쓰지 않았다. 그래서 누군가가 해법을 단숨에 만들어 내면 일이 거기서부터 진행되었다. "한다고 하고 그냥 하는 사람은 많지 않아요. 사람들 간에 많은 토론이 벌어지지만 그 일을 하는 사람이 착수하게 되는 거죠." "안드로이드에서 가장 존경받는 건 그냥 뭔가를 이뤄 내는 누군가죠"

p.178. 안드로이드는 성능을 얻거나 출시일을 맞추기 위해 절충을 하는 것으로 유명했지만, 팀은 특정 제품 기능을 위해 어설픈 해킹을 하기보다는 범용적인 플랫폼 기능을 만드는데 우선순위를 두었다.

p.226 디자이너로서 업무는 제품이 무엇을 상징하는지 소통하는 것

p.335 누군가 문제를 발견하면 해법을 강구해 냈다. 그것도 아주 빨리.

p.337  다른 회사들은 사람들이 한 일을 보고 채용하고 그 일을 더하라고 한다. 구글은 어떤 사람인지 보고 채용하고 그들에게  필요한 일은 뭐든 하라고 한다. 그 사람이 과거에 한 일은 그들이 무엇을 할 수 있는지 보여주는 훌륭한 예이지만, 구글이 보기에는 그들이 할 수 있는 일로 그들을 제한할 필요는 없었다.

p.368 히로시는 어떻게 돌아가는지 이해하기 위해 나와 함께 세부 업무에 기꺼이 뛰어들었어요.... 성실하게 일하면서 정확한 질문을 하기에 충분한 기술적 지식도 갖추려면 어떻게 해야 할까요? 그게 그가 여기에서 일하는 이유죠.

p.373 다양한 하부 팀 사이의 차이점을 다루는 것. 개성을 잘 엮는 일. 엄청나게 재능 있는 사람들로 구성된 작은 팀이 큰 팀을 이길 거라는 점.... 그러나 재능과 에너지가 있으면 대인 관계와 아키텍처에서 충돌이 날 수 있습니다. 그 부분을 내가 잘 중재했죠.

p.377 나는 m1, m2 등 몇 가지 초기 이정표를 만들었는데, '각 이정표마다 무엇을 끝낼 수 있을까요?'라는 질문을 던졌습니다.

p.381  아무개는 모 팀 소속이에요라고 하지 않았어요. 도움이 필요하면 뭐든 요청했고 할 수 있는 사람은 누구나 뛰어들었죠

p.391  플랫폼이 되는데 집중했죠. 제대로 된 앱이 없고 순수한 플랫폼만 만든다면  악순환을 끊지 못하죠. 사람들이 필요로 하는 걸 만들지 않을 거고요. (Be는 틀에 박혀서  논쟁만 했다는 맥락.)

p.401 혁신에 열려있고 시도하는데 개방적인 문화를 나는 좋아했어요... 그러한 접근방식에는  장단점이 있어요. 확실히 전에 이런 일을 해본 사람들은 무엇을 해야 하는지 압니다.

p.411 내가 그렇게 똑똑한 엔지니어라고 생각하지 않아요. 하지만 기를 쓰고 일하죠. 그저 열심히 건강에 해로울 정도로 오래 일해서 경험 부족을 보충했어요.

p.434 애플은 소비자 브랜드다. 구글이나 MS처럼 기술, 엔지니어, 엔지니어링 자체를 중시하는 회사가 아니라 기술을 가지고 만들어진 소비자 제품을 중시하는 회사다. 매끈하고 세련되고 일관된 모습을 세상에 선보이는 것이 소비자 브랜딩 접근 방식의 일부이다.

p.456 현실에서 사용하는 앱을 작성하는 일은 사용자에게 더 많은 기능을 제공할 뿐 아니라 플랫폼 개발자가 앱 개발자 점에서 플랫폼을 이해해서 향후 버전에는 더 나은 API와 기능을 넣는데 도움이 된다. 고쳐야 할 버그를 찾는데도 도움이 된다.

p.487 우리는 기술적인 것에 의해 움직여 왔는데, 기술적인 기초는 있으니 이제는 진짜 시장이 이어받게 해야 했어요. (넥서스 원과 드로이드 마케팅을 바라보는 개발자 관점)

p.493 기술과 기기는 사업과 판매가 향하는 방향을 따라갑니다. 실은 마케팅과 판매 전략이 주도해서 도약할 수 있고, 기기가 더 좋아지는 것.

p.502 팀 크기가 작다는 것은 프로젝트를 끝내기 위해 모두가 엄청나게 열심히 일해야 함을 의미했지만, 더 효율적이 되어야 한다는 뜻이기도 했다.

p.503  한 사람이 위에서 이런 결정을 내리면 팀과 제품은 목표를 향해 전진하게 됩니다. 그게 결정이고 설사 옳지 않은 결정이라 해도 결정이 내려졌으면 앞으로 나아가야죠. 움직이지 않는다면 조종할 수 없어요.