Growth Developer를 읽고

 

요근래 커뮤니티나 아티클을 읽어보면 성장에 관한 글이 많습니다.

때문에 많은 분들이 성장에 대한 고민이 많은데요.

저 역시도 방향을 어떻게 수립해야 하는지, 어떻게 접근하면 좋을지 많은 고민을 했던 때에 접하고 도움받았던 책입니다.

 

책은 크게 다섯 가지로 나누어 꾸준히 성장하는 개발자가 되는 방법을 넌지시 알려줍니다.

마음가짐, 문제해결, 개발, 협업, 차별화가 그 다섯인데요.

하나씩 차례대로 살펴보겠습니다.

 

마음가짐

첫 번째로 가져야할 마음가짐은 `문제의 원인은 바로 나에게 있다`입니다.

문제의 원인을 외부에서 찾으려하는 마음가짐 대신, 내부에서 출발하면 빠르게 문제의 본질에 도달할 수 있다고 일러줍니다.

이 책을 접하기 전, 도널드 고즈와 제랄드 와인버그의 `대체 뭐가 문제야`를 읽었던 터라 더 다가왔던 구절입니다.

 

두 번째는 자신감입니다.

이는 `당신은 선배보다 낫다`의 구절로 표현되는데요.

기술이 점차 발전해감에 따라 당신은 선배보다 더 많은 경험을 할 것이고, 더 나은 개발자가 될 것이니 자신감을 충분히 가지라는 뜻입니다.

 

세 번째는 의지와 행동력입니다.

야생에서 살아남기 위해서는 먼저 살아남겠다는 각오와 행동력이 필요하듯, 저자께서도 이 소프트웨어 세계에서 꾸준히 성장하며 살아남기 위해서는 단호한 결의와 노력이 필요하다고 언급합니다.

 

네 번째는 소극적이지 말라입니다.

더 이상 우리는 아이가 아닙니다. 변화를 만들기 위해선 나서서 무언가를 해야합니다. 그리고 그것을 두려워하지 말아야 합니다.

 

다섯 번째는 네 번째와 궤를 같이하는 느낌인데요, 더 적극적이고 열정적으로 참여하라입니다.

뭐든 더 얻어가기 위해선 열정적으로, 적극적으로 임하는게 중요하다는 내용입니다.

 

문제해결

꾸준히 성장하는 개발자가 되려면 문제해결력을 길러야 합니다.

이를 위해서 다음과 같은 구체적인 예시를 통해 문제해결력을 기르는 방법을 알려줍니다.

 

먼저 문제가 발생했을 때, 그 문제를 재현할 수 있어야 합니다.

문제의 답을 구했다하더라도 문제 상황을 재현하지 못한다면 그 답은 문제상황의 적절한 답이 아닐 수 있습니다.

문제를 제대로 이해한게 아닐 수 있기 때문입니다.

 

두 번째는 문제를 풀기 위한 기술입니다. 문제가 먼저여야지 기술이 먼저여선 안 된다는 뜻입니다.

요즘 자주 언급되는 `신기술을 경험하려 노력하기보다 상황에 적절하게 문제를 풀어냈는가`가 생각났습니다.

 

세 번째는 서비스 상태에 대한 직감입니다.

처음 봤을 땐 좀 애매했는데요. 프로젝트를 많이하고 서비스를 운영하면서 장애가 발생할 가능성이 없는지, 이런 직관력을 기르라는 느낌을 받았습니다.

 

네 번째는 문제를 외면하지 말라입니다.

마음가짐에 언급되었던 적극성과 궤를 같이하는데요. 문제가 발생했음을 두려워하지 말고 적극적으로 해결하는 것이 더 중요합니다.

 

다섯 번째는 고장률 제로라는 목표의 함정입니다.

서비스의 목표는 고장이 발생하지 않는 것이 아닌, 고장을 빠르게 감지하고 재발하지 않게 해결하는 것입니다.

고장률 제로라는 목표는 소프트웨어라는 특성상 의미가 없기 때문에, 추상적이기보단 더 구체적인 것들을 목표로 설정하라고 조언합니다.

 

개발

역시 개발자는 개발을 잘해야겠죠? 세 번째는 개발에 관한 내용으로 이 단원에선 개발을 위한 킥을 조언합니다.

 

첫 번째로 메모리 관리를 신경써라고 언급합니다.

결국 소프트웨어는 컴퓨터의 자원을 가져다가 무언가를 연산하거나 기억하도록 하기 때문에, 이런 본질적인 것들을 좀더 신경쓰면 좋다고 언급합니다.

통상적으로 요즘 언어들은 적절한 전략을 가진 가비지 컬렉터들이 해제를 대신 해주기 때문에, 내가 지금 작성하고 있는 변수가 어디에 할당되며 어느정도의 생명주기를 가지고 메모리 단에서 어떤 영향을 끼칠 것인가 정도를 더 생각하며 개발해야 한다고 합니다.

 

두 번째는 생명 유지 활동과 리팩토링입니다.

리팩토링을 다이어트에 비유해주셨는데요, 프로그램의 생명주기에 있어서 그 생명이 자주, 크게 아프지 않게 하려면 리팩토링을 통해 적절히 다이어트를 해주어야 한다고 합니다.

또한 다이어트처럼 리팩토링도 기간을 정해두고 하는 것이 아닌, 꾸준하게 우리와 함께하는 것이며 항상 염두에 두고 있어야 함을 알려줍니다.

 

세 번째는 고장지점은 분산하고 관리지점은 집중하라입니다.

단일 장애지점이라는 용어를 들어보셨을텐데요. 이는 분산시키고 관리지점, 즉 변경이 잦은 부분은 한 곳에 모아두라는 의미입니다.

 

네 번째는 하나의 프로세스에서 출발하라입니다.

MSA도 처음엔 모놀리식이었듯, 처음부터 복잡하고 거대한 소프트웨어를 설계하는 것은 품이 많이 드니, 하나의 프로세스에서부터 출발하는 것이 좋은 접근법이 될 수 있다는 의미입니다.

 

다섯 번째는 표준화를 위해선 사례를 공부하라입니다.

표준화는 수많은 구체과 예시들로부터 특징, 특성만을 추출한 것이므로 추상적인 개념의 이해가 어렵다면, 구체적인 것부터 접근해 보라는 의미입니다.

 

협업

성장하는 개발자의 네 번째 덕목은 협업입니다.

정말 중요한 소프트스킬이고 이력서 내용이나 자기소개서의 항목으로도 자주 등장하는데요.

이 단원에서는 협업을 잘 하기 위한 저자의 조언이 등장합니다.

 

첫 번째는 눈높이에 맞게 단어를 선택하라입니다.

여기서 제 뼈를 때리는 문장이 있는데요, "내 가치를 어려운 단어를 동료 앞에서 늘어놓는 것으로 증명하지 마라"입니다.

거대한 문제를 해결하기 위해선 협력이 필요하고 협력하는 과정에선 소통이 필요하고 소통하는 과정에선 눈높이를 맞추는 과정이 필요하다고 저자는 설명합니다.

 

두 번째는 일정은 협의하는 것이다입니다.

개발 일정을 산정함에 있어서 `모른다, 해봐야 안다`고 답하기 보다 `사전조사가 필요한데, 3일 정도가 소요됩니다. 최악의 경우 시간이 길어질 수 있지만 조사 완료 후 피드백드리겠습니다`와 같이 정확한 일정 산정이 어려운 경우, 그 대처와 마음가짐을 조언합니다.

 

세 번째는 누구나 빌드할 수 있어야 한다입니다.

이 내용은 다음 저자가 말하는 다음 문장으로 충분히 설명될 것 같습니다.

`오늘 아침에 새로운 프로그래머가 팀에 합류했다면 그 개발자 스스로 개발환경을 구축하고 소스를 내려받고 자신의 PC에서 구동할 수 있어야 하며 오늘 오후에는 본인이 작업한 내용을 빌드하고 테스트하고 심지어 배포까지 할 수 있어야 한다.`

 

네 번째는 동기식으로 일할 것인가? 비동기식으로 일할 것인가?입니다.

우리의 뇌는 복잡한 연산을 빠르게 처리하지만 출력 장치인 손과 입은 그렇지 못하다는 사례를 들며 효율적인 소통 방식을 선택할 것을 조언합니다.

 

다섯 번째는 좋은 개발팀에서 일하고 싶다면입니다.

저자의 관점에서 좋은 개발팀이라 부를만한 특성들을 몇 개 알려주십니다. 이는 다음과 같습니다.

• 자유를 보장하기보다 절제된 통제 속에서 주어지는 자율적인 참여로 하여금 나의 잠재력을 이끌어낼 수 있는 곳
• 어떠한 불이익없이 반대의견을 자유롭게 낼 수 있는 곳
• 모두가 참여하는 의사결정이 아닌 의사결정권자가 명확하게 존재하는 곳
• 제품에 대한 애정과 야심이 있는 곳
• 어제보다 더 나아지고자 하는 미래지향적 상승 의지가 느껴지는 곳

 

차별화

마지막입니다. 개발자로서 다른 개발자와 차별점을 가질 수 있는 예시들에 대해서 설명합니다.

어떠한 것들이 당신을 개발자로 하여금 한층 더 나아갈 수 있게 만드는가, 그런 요소들에 대한 내용입니다.

 

첫 번째는 고객과 사용자의 차이를 아는 것입니다.

고객이 사용자일 순 있지만 항상 사용자가 고객일 수는 없다는 것을 명심하라고 조언합니다.

외에도 사용자들의 피드백을 수용하는 자세는 좋으나 무분별하게 수용하는 것을 경계하라고 조언합니다.

 

두 번째는 취미개발자입니다.

개발을 일이 아닌 취미로도 가지게 되면 앞으로의 커리어나 인생에 더 도움이 될 수 있다고 합니다.

작은 성공을 맛보든 피드백을 받든 과정에서 끝나지 않고 결과를 만들어낸다면, 이를 바탕으로 더 나아갈 수 있기 때문에 권장합니다.

 

세 번째는 인터페이스를 중요시하라입니다.

인터페이스가 서로 다른 두 지점이 연결되도록 하듯 항상 병목지점이 될 수 있는 부분들에 대해서 더 고민을 기울인다면 더 좋은 개발자가 될 수 있다고 조언합니다.

 

네 번째는 제안서를 써라입니다.

코드를 작성하기 전에 먼저 자신의 생각을 글로 풀어낼 수 있다면 어느조직에서나 인정받는 개발자가 될 수 있다고 조언합니다.

생각을 명문화하는 과정에서 그 생각의 가치를 어림해볼 수 있고, 또 정리할 수 있기 때문에 저자는 생각을 글로 표현하기를 권장합니다.

 

마무리

백엔드 부서에 합류한지 얼마 되지 않았을 때, 갈팡질팡하던 제게 도움이 되어줬던 책입니다.

어떤 마음가짐을 가지고 개발자란 직업에 임해야할지 도움이 되어주었고 어느 방향으로 나아가야할지 일러줬던 것 같습니다.

성장하기 위해 노력하고 있다고 생각하지만 두려움이 드시는 분들이 한 번 읽어보시면 좋을 것 같습니다.

 

감사합니다~