개발자로 살아남기를 읽고

들어가며

30년 이상의 개발 경력을 가진 저자의 "개발자로 살아남기"는 단순한 기술 서적이 아닌, 개발자로서의 전체적인 커리어와 삶의 방향성을 제시하는 책입니다.

이 책의 가장 큰 특징은 다음과 같습니다:

1. 실전 경험 기반: 저자의 30년 개발 인생에서 얻은 실질적인 교훈과 인사이트를 담고 있습니다.
2. 균형잡힌 시각: 기술적 역량뿐만 아니라 매니지먼트, 비즈니스 역량까지 포괄적으로 다룹니다.
3. 실용적인 조언: 추상적인 이야기가 아닌, 현장에서 바로 적용할 수 있는 구체적인 조언을 제공합니다.

특히 계획을 세우고 실패하는 과정에서 단순히 '나의 의지가 부족했다'라고 생각하고 또다시 계획을 실패하는 과정을 수없이 겪었던 저로서는, 결심이 아닌 프로세스를 개선함으로써 계획을 실패하지 않도록 해야겠다는 깨달음을 얻었습니다.

이 책은 "이 상황에서는 어떻게 해야 할까?"하는 고민이 들 때마다 꺼내 보면서 조언을 구할 수 있는 훌륭한 길잡이가 될 것입니다.

프롤로그 개발자 30년을 넘어서

• 성장'은 역량이 늘어난다는 뜻입니다. 사람의 '역량'이란 무엇일 까요? 첫 번째는 지식, 두 번째는 숙련도, 마지막은 경험입니다.

• 첫 번째 지식은 공부를 해야 쌓입니다. 지식을 쌓는 공부는 혼자서 하는 영역입니다. 물론 일하면서도 지식을 쌓을 수는 있지만, 근본적으로 본인이 하지 않으면 쌓을 수 없다는 측면은 같죠.

• 두 번째 숙련도는 같은 일을 여러 번 오래 반복해야 쌓을 수 있습니다. 결국 프로그래밍, 프로젝 트, 소통, 협업을 해봐야 숙련도가 높아집니다. 얼마나 열심히 하냐에 따 라 공부와 숙련에 드는 시간이 짧아질 수 있습니다.

• 반면 경험을 쌓는 데 드는 시간은 단축하기가 어렵습니다. 경험은 성공과 실패를 해봐야 하고, 이런 사람 저런 사람도 만나봐야 합니다. 다행인 것은 강연이나 책으로 다른 사람 경험을 간접 습득하면 시간을 줄일 수 있습니다. 왜 많은 사람 이 책을 강조하는지 이제 알겠죠?

• 항상 지식과 숙련도를 고민하고, 특히 간접 경험을 적극적으로 받아들 여 경험을 쌓으면 앞서 언급한 커리어패스를 더 빠르게 밟아나아갈 수 있습니다. 기억하세요. 지식, 숙련도, 경험

PART 1 엔지니어링 역량

• 현업에서 개발할 때는 구현 대상인 제품을 제대로 파악해야 합니다. 주어진 스펙대로만 개발만 하는 게 아니라 사용자 입장에서 제품을 생각하 고 아이디어를 보태야 합니다. 그러려면 좋은 사용자가 되어야 합니다.

• 자신이 만드는 제품을 직접 써보면서 더 좋은 제품을 만들고자 하는 욕구가 있어야 더 좋은 개발자로 발전합니다. 그래서 경쟁 제품도 많이 써 봐야 합니다. 다양한 제품들을 써보면 제품을 이해하고 시장도 이해할 수 있습니다. 그래야 내가 만드는 제품에 내 의견을 불어넣어 재밌게 개 발할 수 있습니다.

• 프론트엔드 개발자라고 해서 프론트엔드만 알면 안 됩니다. 백엔드를 조금이라도 개발할 줄 알아야 합니다. 개발은 협업의 연속입니다. 원활히 협업하려면 알아야 합니다. 프론트엔드 개발자가 백엔드 개발자에게 안 되는 걸 무조건 해달라고 하면 어떻게 되겠습니까? 분란만 나겠죠? 초 당 10만까지만 받을 수 있는 시스템인데 '나는 당신 사정은 모르겠고 당 장 천만 받아줘' 라고 하면 안 됩니다. 풀스택 개발자까지는 안 되더라도 프론트엔드, 백엔드, 데이터베이스, 머신러닝, 클라우드, 안드로이드/os 전반에 대한 지식이 있어야 합니다.

• 출시는 일정 주기로 하는 것이 제일 안전합니다. 예를 들어 2주에 한 번 씩 정기적으로 출시하면 지속적으로 시장 반응을 확인하기 좋고, 안정성 확보에도 도움이 됩니다. 물론 출시에는 항상 위험이 따르니 다시 원상태 로 빠르게 복구하는 롤백 계획도 세워져 있어야 합니다

• 애자일이 원활히 동작하려면 적극적인 소통이 중요합니다. 시킨 일만 하는 수동적인 자세로는 불가능하다고 해도 과언이 아닙니다. 소통은 모든 방향에서 원활히 이뤄져야 합니다. 특히나 스타트업은 빠르게 움직이 기 때문에 소통이 제때 이뤄지지 못하는 문제점이 있습니다. 그래서 요즘 은 커뮤니케이션 매니저라는 역할도 생겨났습니다. 보통은 프로젝트 매니저와 조직장들이 원활한 소통 환경을 만들어야 하는데 업무가 너무 많 다 보면 당장의 업무에만 집중하게 되거든요. 소통에 문제가 있다고 느껴 지면 바로 결정권자와 이야기를 나눠보는 것이 좋습니다.

PART 2 매니지먼트 역량

• 제품의 범위를 줄여야 합니다. 기능을 100%가 아니라 80~90%만 넣어 출시하는 겁니다. 최소기능 제품을 출시하고 지속적으로 기민하게 업데이트하는 개 발 방법론이 애자일입니다. 이때 핵심 기능을 빠뜨리는 일이 없어야 합니 다. 품질과 경쟁력에 영향을 미쳐 자칫 위험에 처할 수도 있습니다.

• 훌륭한 개발자는 절대 엔지니어링 역량만 가지고는 될 수 없습니다. 매니지먼트 역량이 꼭 필요하고 이 매니지먼트 역량의 바탕은 바로 소프트 스킬 Soft Skill 입니다. 소프트 스킬 중에서도 제일 기본인 다섯 가지 기술을 알아보겠습니다.

• 첫째 소통 communicaton 입니다. 소통이 원활하지 않으면 일 이 원활하게 돌아가지 못합니다.

• 둘째 협업입니다. 혼자서 프로그램을 만들던 시대는 끝났습니다. 일을 주고받으며 함께 일해야 합니다. 소통과 협업은 비슷하면서도 다릅니다.

• 셋째 긍정적인 자세 positive atitude 입 니다. 일을 할 때 사람마다 자세와 마음가짐이 다르게 마련입니다. 일이 될 거라고 믿는 긍정적인 자세와 안 될 거라고 보는 부정적인 자세가 큰 차이를 만듭니다.

• 넷째 프로 의식 work ethitc입니다. 자신의 일이라고 생각하 고, 최선을 다하는 자세입니다.

• 마지막은 리더십(leadership) 입니다. 프로젝트를 리딩하는 능력, 다른 사람을 관리하는 능력, 기술을 결정하는 능력이 여기에 해당합니다.

• 계획을 세우는 이유는 완벽하게 준수하기 위해서가 아닙니다. 성공을 위해 세우는 겁니다. 그러므로 계획을 세워두고 상황에 맞게 수정하고 대비해야 합니다. 계획을 세우고 3일만 지나도 상황은 바뀝니다. 그럼 다시 계획을 세워야 합니다. 원래부터 계획은 세우고 고치고 다시 세우고 고치기를 반복해야 하는 겁니다.

• 핵심은 '우선순위 정하기'입니다. 우선순위의 기몬은 밥한가 밥하시 많은가?, '중요한가 중요하지 않은가?'에 있습니다. 앞서 얘기한 '중요한 데 할 수 있는가 없는가'와 비슷하게 들립니다만, 약간 다른 측면에서 보 는 겁니다. 급한 거는 바로 느껴지지만 중요도는 잘 느껴지지 않습니다.

PART 3 비즈니스 역량

• 이전에 어느 회사를 다녔느냐는 중요하지 않습니다. 그 회사 에서 무슨 일을 했고, 어떤 성공과 어떤 실패를 경험했는지가 중요합니 다. 특히, 지원자의 이력에 굉장히 크게 성공한 프로젝트가 있고, 그 프로 젝트에 포함된 사람이 엄청나게 많았다면, 더욱 자세하게 물어봐야 합니 다. 아주 크게 성공한 프로젝트에 아주 많은 사람이 참여했다면, 사실 그 사람은 아무것도 하지 않았을 가능성도 있습니다. 한 사람의 과거 경력을 회사를 기준으로 봐서는 안 됩니다. 또한 좋은 회사들을 짧게 다녔다면, 위험할 가능성이 있습니다.

• 개발자는 어떤 자리, 어떤 회사를 목표로 해서는 안 됩니다. '어떤 사람 이 돼야겠다, '무엇을 해야겠다'를 목표로 삼아야 합니다. 어떤 회사에 지원하는 이유는 그곳에 하고 싶은 일이 있어서여야 하지, 꼭 특정 회사 특정 포지션을 고집해서는 안 됩니다.

• 지원 동기를 묻는 질문에는 답변을 아주 잘해야 합니다. 직전 직장과 비슷한 회사에 지원한다면 이직 이유가 사람 때문이라고 보게 됩니다. 하는 일과 사용하는 기술이 비슷하다면 자연스럽게 그리 생각하게 되는 거 죠. 면접관 생각이 여기까지 미치게 되면 지원자와 지원자를 이직하게 만 든 사람 중에 누가 문제일까를 고민하게 됩니다. 이전 직장에서 충돌이 있었다는 이야기를 하면 면접관은 불안하게 생각합니다. 만약 이런 이유 로 이직을 준비한다면, 회사를 옮기는 것보다 현재 직장 내에서 문제를 어떻게 해결할지 고민해보시는 게 좋습니다. 회사를 옮겼는데도 비슷한 문제가 또 발생할 수 있기 때문입니다. 이직 사유의 모범 답안은 이미 정 해져 있습니다. 이직할 회사의 서비스나 기술에 흥미를 보이는 겁니다.

PART 4 개발자로 살아남기 30년

• 시간을 돈이라고 생각하세요. 매일 86,400원을 받는다고 생각해보세 요. 그런데 이 돈은 저녁이 되면 사라집니다. 뭘 하든 저녁이 되면 사라지다니! 안 될 일입니다. 철저하게 계획을 세워 써야겠다는 생각이 번쩍 드 시죠? 시간을 효율적으로 써야겠다 싶을 겁니다. 효율보다는 생산성이 더 중요합니다. 중요한 일을 잘하는 게 중요합니다. 속도보다 방향이 중요합 니다. 시간을 아껴 써서 뭔가를 빨리 해내는 방식이 아니라, 정해진 시간 안에서 무엇을 어떤 방향으로 어떻게 할지 고민하는 방식입니다.

• 계획은 사장과 관리자만 세우는 것이 아닙니다. 상사가 계획을 세우 고 아랫사람이 그대로 따르는 시대는 지났습니다. 최대한 본인의 시간, 계획, 목표에 몰입하길 바랍니다. 회사가 세운 큰 계획 안에서 여러분은 실무단 계획을 세울 수 있는 자유가 있습니다. 하루 단위를 넘어 1주일 1달, 1년 단위로 계획을 세우고 중요하게 생각하는 일을 적어보세요. (회 사와 팀 계획은 혼자 세우는 게 아니므로) 회사 차원에서의 큰 계획 말고 개인이 할 수 있는 계획을 세우면 됩니다.

• 하나를 빨리 끝내고 다 음 것을 하는 게 낫습니다. 몰입 상태에서 방해받지 않도록 사람들과 미 리 조율하세요. 물론 함께 일하며 그 어떤 방해도 받지 않는 것은 불가능 합니다만 그럼에도 서로가 몰입해서 일할 수 있게 배려해야 합니다. 이는 관리자 입장에서도 굉장히 중요합니다. 몰입해야 계획대로 일을 진행할 수 있으니 관리자는 쓸데없는 일로 몰입을 방해해서는 안 됩니다. 또한 몰입 근무를 도와주는 환경을 만들어야 합니다.

• 시간 관리는 자신의 삶에 대한 확신, 자존감과 연결됩니다. 확신과 자존감이 서 있으면 휴식을 몰입해 즐기는 여유가 저절로 생깁니다. 회사에 서는 자신이 하는 일을 좋아하고, 같이 일하는 사람을 좋아하고, 업무 자 체도 좋아해야 시간 관리가 잘 됩니다. 그렇지 않으면 업무뿐 아니라 결 국 인생에도 좋지 못한 영향을 미칩니다.

결론

이 책은 개발자로서의 커리어를 시작하는 주니어부터, 팀을 이끄는 시니어 개발자까지 모두에게 유용한 인사이트를 제공합니다. 특히 기술적 성장과 함께 조직에서의 성장을 고민하는 개발자들에게 꼭 추천하고 싶은 책입니다.