📚 어떤 책인가?
"10년이 가도 변치 않을 업의 지혜"라는 부제가 인상적인 이 책은 테크 리더 9인이 말하는 더 나은 개발자로 살아가는 원칙과 철학을 다룬다.
9명의 저자가 각자 생각하는 개발자 원칙에 대한 이야기를 풀어낸 책으로, 읽는 내내 다양한 감정을 불러일으켰다. 아직 이해하기 어려운 내용도 있었고, 당장 시도해보고 싶은 내용도 있었으며, 깊은 깨달음을 주는 파트에서는 감탄하며 읽기도 했다.
👾 개발자란 무엇일까요?
책에서 9명의 저자들에게 공통으로 던진 질문과 답변을 담고 있다. 질문은 다음과 같다:
- 개발자란, 좋은 개발자란 무엇일까요?
- 개발자가 되어서 언제가 가장 즐거웠나요?
- 이 일을 계속하게 되는 원동력이나 에너지는 어디서 얻나요?
본문에 들어가기 전의 맛보기 같은 파트였지만, 이 부분을 읽으면서 새로운 관점을 배우고 많은 생각을 할 수 있었다. 특히 이 책을 읽을 때쯤 나도 개인적으로 비슷한 고민들을 하고 있어서 더 흥미롭게 읽었던 것 같다.
내가 가지고 있던 고민
당시 나는 "현업에 있는 내 모습은 어떤 모습일까?"라는 고민을 하고 있었다. 좀 더 구체적으로 말하면 아래와 같다.
현업에 갔을 때 나는 무엇을 원동력으로 삼아 공부하고 성장할 수 있을까?
사실 여태껏 왜 내가 개발자가 되고 싶은지, 어떤 개발자가 되고 싶은지에 대한 기준이 없었다. 애초에 나는 나 자신이 그런 기준이 없어도 괜찮은, 호불호가 없는 사람이라고 생각했었기 때문에 이런 상황에 대해 불만이나 문제의식을 가지고 있지도 않았다.
하지만 다행히도 우테코에 들어와서 이 생각이 바뀌었다. 레벨 2 동안 솔라와 원온원을 통해 문제 상황을 인식하고 개선시켰다. 내가 개발자라는 직업을 선택하고 싶은 이유, 나의 성향, 어떤 환경에서 일하는 것을 선호하는 사람인지에 대한 생각을 정리했다. 즉, 내가 이루고 싶은 목표를 구체화하고 원동력 삼을 수 있게 되었다.
그런데 여기서 또 새로운 고민이 생겼다. 이 고민은 우테코 레벨2를 마무리하는 글쓰기 미션에서 받은 동료 크루 미미의 질문으로부터 시작됐다.
"현업에 가서 노랑은 어떤 모습일까요?" 이제 막 취업 전까지의 1차 목표를 세운 입장에서, 내가 달성한 목표(내가 원하는 환경에 취업)를 이룬 뒤에는 어떻게 될지 잘 상상이 되지 않았다. 그런데 마침 이 책에서 나보다 훨씬 먼저 길을 걸어간 선배 개발자들이 무엇을 원동력으로 삼고 있는지를 말해주고 있었다. 미리 미래에 대한 힌트를 얻는 느낌이었다.
선배들의 답변 중 기억하고 싶은 내용들
9명의 선배 개발자들이 전해준 답변 중에서 특히 인상 깊었던 내용들을 정리해보고 싶다. 각각의 답변이 나에게 어떤 의미로 다가왔는지도 함께 담아보려 한다.
1. 개발자란, 좋은 개발자란 무엇일까요?
개발자(developer)라는 단어는 부동산 개발에서 차용한 단어입니다. 아무것도 없는 황무지를 개간해서 멋진 생활 공간으로 만드는 것처럼, 소프트웨어 시대 그리고 인터넷/모바일/AI라는 황무지에 필요한 물건이나 구조를 만드는 사람을 소프트웨어 개발자로 부릅니다.
그런 관점에서 좋은 개발자는 그 소프트웨어 제품이나 구조에 ‘좋은’ 가치를 더하는 데 시간을 들이는 사람입니다. … 그러한 저마다의 가치를 이루기 위해서 계속 노력하는 사람은 다 좋은 개발자입니다.
- 공용준 선배와의 인터뷰
오호 개발자가 부동산 개발에서 차용한 것이라니, 몰랐던 사실이다. 단어의 기원으로부터 직관적인 이해를 할 수 있어서 좋았다. 또한 좋은 개발자의 의미에 대해서, 각자가 정의한 가치를 이루기 위해 노력하는 사람이라고 설명했다. 결국 내가 어떻게 생각하는지가 중요하겠구나.
좋은 개발자라면 역시나 성과를 내고, 성장을 하고, 이런 과정에서 행복을 느낄 수 있어야 합니다. … 우리 대부분은 직장에서 하루 중 제일 많은 시간을 보냅니다. 이곳에서 행복을 느끼는 것이 삶의 만족을 위해서 중요한 일입니다.
- 박종천 선배와의 인터뷰
성과와 성장을 내고 행복을 느끼는 것. 현업 개발자가 아닌 지금의 나로서도 충분히 느낄 만한 것이라서 좋았다. 지금 내가 하고 있는 게, 직장인으로서의 개발자일 때도 쭉 이어지는구나 생각했다. 다만 직장인 개발자가 되면 "성과"라는 부분이 좀 더 커질 것 같다.
개발자는 크게 ‘직업이 아닌 개발자’와 ‘직업으로서의 개발자’로 나뉜다고 봅니다. 이 둘 사이에는 ‘하고 싶은 것을 하는 것’과 ‘해야 하는 것을 하는 것’이라는 큰 차이가 있다고 생각합니다. … ‘적절한 시기에 적합한 도구로 고객의 문제를 해결하는 개발자’를 좋은 직업 개발자라고 생각합니다.
- 이동욱(향로) 선배와의 인터뷰
역시 '직업이 아닌 개발자'와 '직업으로서의 개발자'로 따로 나눌 만큼 둘의 차이는 크구나. 그런데 오히려 '직업으로서의 개발자'의 목표가 좀 더 명확한 것 같다. 직업으로서의 개발자도 나름의 재미가 있을지도?
2. 개발자가 되어서 언제가 가장 즐거웠나요?
언제부턴가 일을 시작할 때 할 일에 어떤 의미가 있고 어떤 영향을 미치는지 찾고 확인하는 습관이 생겼습니다. 그것이 명확해지면 더 몰입해서 일하게 되고 얻는 기쁨도 큽니다. 아무리 찾아도 보이지 않으면 그런 요소를 만들어 넣기도 합니다. 의미 있는 가치를 만드는 것이 즐겁습니다.
- 박성철 선배와의 인터뷰
배우고 싶은 마인드다.
3. 이 일을 계속하게 되는 원동력이나 에너지는 어디에서 얻나요?
자신이 쓸모 있는 사람이라는 것을 확인하는 게 즐겁습니다. 그래서 하게 되는 일에 쓸모를 찾으려 노력하고 더 쓸모 있을 수 있는 기회를 선택합니다. … 각자의 삶은 스스로 정의하고 만들어가야 하는 것이고 일도 삶의 중요한 일부이므로 그래야 합니다.
- 박성철 선배와의 인터뷰
… 그런 의미에서 저에게 있어서 ‘삶은 호기심’이라고 생각합니다. … 이렇게 새로운 기술이 계속 나오고 세상이 바뀌는 것이 두려울 수도 있겠지만, 반대로 호기심을 충족시켜 주는 모험이 될 수 있습니다.
- 박종천 선배와의 인터뷰
업계에서 한 자리 하는 선배님들의 원동력과 에너지도 참 다양하구나!
📜 개발자 원칙
책에서 소개하는 9개의 개발자 원칙 중에서 특히 재밌게 읽었던 2가지를 소개하고 싶다. 각각 다른 이유로 인상적이었는데, 하나는 당장 실천해보고 싶은 구체적인 방법을 제시해 줬고, 다른 하나는 오랜 경험에서 우러나오는 깊이 있는 통찰을 보여줬다.
02) 오류를 만날 때가 가장 성장하기 좋을 때다
"오류를 만날 때가 가장 성장하기 좋을 때다. 성장 발판으로 삼아보자."
- 강대명, 레몬트리 CTO
핵심 내용
백엔드 엔지니어의 실력은 얼마나 많은 오류와 장애를 만나고 이를 해결했는지 여부에 따라 갈린다는 관점에서 시작하는 이 챕터는, 오류를 만날 때 좌절하지 않고 더 나은 개발자로 나아갈 수 있는 두 가지 원칙을 제시한다.
1. 오류가 발생하면 소스 코드 레벨에서 이해하자
토이프로젝트의 버그를 해결하다가 레디스 오픈소스의 오류를 발견하고 레디스 컨트리뷰터가 되었던 저자의 경험담이 나온다.
서비스를 운영하다 보면 많은 툴을 사용하고, 많은 에러를 마주치게 됩니다. 이때 해당 오류를 스택오버플로에서 검색하면 대부분은 손쉽게 해결책을 얻을 수 있습니다. 하지만 단순히 여기서 끝내버리면, 실제로 깊은 지식을 얻기가 어렵습니다. 한 발 더 나아가서 해당 툴의 소스 코드를 확인하는 것으로 관련 에러가 왜 발생하는지 해결하려면 어떻게 해야 하는지 같은 깊은 지식을 얻을 수가 있습니다.
2) 알아낸 지식을 글로 공개하자
가급적이면 결과물을 공개해 다른 사람의 조언을 들을 기회로 삼아보시길 바랍니다.
저는 오류를 만나거나 이슈를 만날 때 가능하면, 왜 그런지 관련 자료들을 찾아보고, 소스 코드를 확인하고, 오픈 소스에 기여하는 것을 빼먹지 않았으면 좋겠습니다.
저자는 마지막에 좋아하는 책 <학문의 즐거움>의 구절을 인용하며 이렇게 말한다. 정말 멋진 말이라 여기에도 옮겨 적는다!
배우는 일, 그것은 즐겁다.
생각하는 일은 더 즐겁다.
창조하는 인생이야말로 최고의 인생이다.
읽으면서 느낀 점
처음 읽을 때는 솔직히 "말이 쉽지, 정말 똑똑한 사람만 가능한 방법 아니야?"하고 약간 삐뚤어진 시선으로 읽었다..ㅋㅋㅋ 프레임워크/라이브러리의 코드를 뜯어보고, 오류를 발견하고, 오픈소스 컨트리뷰터가 되고, 블로그로 정리해서 공유하고… 이런 일련의 과정들이 너무 나와는 다른 세상 사람 같아 보였다.
그런데 저자가 소개한 사례 중에 Java 8 업데이트 후의 개선 사항을 직접 눈으로 확인하기 위해 HashMap 구조를 뜯어본 이야기가 있었다. 이 부분을 읽고 "이정도면 나도 할 수 있겠는데?"라고 다시 생각을 고쳐먹었다. 지레 겁먹을 일은 아니었다.
지금까지 내가 소스코드 레벨에서 문제를 해결하려는 시도가 별로 없었을 뿐이지, 이에 대한 문제의식을 가지고 연습하다 보면 이 부분에서도 새로운 재미를 찾을 수 있겠다는 생각이 들었다. 실제로 주변 크루 중 모코가 라이브러리를 열심히 뜯어보면서 공부하다가 주석에 오류가 있는 것을 발견해서 오픈소스 컨트리뷰터가 된 사례도 있었다. 또 xv6 오픈소스를 개선시키는 것을 과제로 받아서 해본 경험도 생각났다. 정말 어려웠고 머리가 아팠지만, 그만큼 도전적인 과제여서 재밌었고 많이 배울 수 있었다.
정말 멋있는 학습 방법이고, 앞으로 꼭 적용해봐야겠다.
09) 달리는 기차의 바퀴를 갈아 끼우기
"(가능하면 좋은 코드를) 많이 읽고,
(어제보다 좋은 코드를) 많이 쓰고,
(AI를 포함한 동류들과 함께) 많이 생각하고 토론하세요."
- 장동수, 수수한기술 대표
9번째 원칙의 저자인 장동수 님이 20여 년 동안 코딩하는 개발자로, 10여 년 동안 개발 조직의 관리자로 일하면서 체득한 것들을 3개의 행동 강령으로 정리한 내용이다. 와우, 이게 오래 일한 경력자의 짬바인가. 하나같이 뻔하지 않으면서 새롭고, 공감까지 되는 내용들이었다. 그리고 그걸 풀어내는 설명도 너무 좋았다. 이 부분은 책에 등장한 내용을 중심으로 정리했다.
3가지 행동 강령
- Make it work, then make it better - 일단 동작하게 만든 다음 더 좋게 만들어라
- Always leave the campground cleaner than you found it - 언제나 발견했을 때보다 깨끗하게 해 놓고 캠핑장을 떠나라
- The good thing about reinventing the wheel is that you can get a round one - 바퀴를 새로 발명하는 일의 좋은 점은 둥근 바퀴를 얻을 수 있다는 점이다
그중 첫 번째 행동 강령이 내 입장에서 가장 와닿았다.
Make it work, then make it better
“일단 동작하게 만들라(Make it work)”의 의미를 이해하는 것은 어렵지 않습니다. ... “더 좋게 만들어라(Make it better)”는 고민해 볼 만한 꺼리가 있습니다. ... 좋은 코드에 대해서 거의 모든 책에서 공통적으로 제시하는 조건이 있습니다. 바로 가독성(readable), 성능(performance), 유연성(flexible)입니다.
가독성에 대한 인사이트들
- 가독성이 좋은 코드는 관행(convention)을 잘 따릅니다.
어떤 관행을 따를지는 충분한 시간을 들여서 고민하고 논의하여 정해야 합니다. 관행을 결정했다면 따라야 합니다. - 일관성 있는 코드가 읽기 좋습니다.
일관성은 없지만 사전적 의미에 더 잘 맞는 변수 이름보다는 뜻이 안 맞더라도 규칙이 일관된 변수 이름이 좋습니다. - 반복, 재귀, 대칭을 적절하게 잘 활용하면 코드에 리듬감이 생깁니다.
대부분 음악은 앞 소절을 들으면 다음 소절을 예측할 수 있습니다. 좋은 음악은 100% 예측대로 흘러가진 않지만 예측에서 벗어난 부분 덕분에 더 아름답게 들립니다. - 코멘트가 없는 코드가 읽기 좋습니다.
그러나 원칙에 집착한 나머지 꼭 필요한 코멘트조차 남기지 않으면 곤란합니다. 다른 개발자가 다른 시점에 다른 목적으로 코드를 해석하는 데 필요한 컨텍스트는 꼭 필요한 코멘트입니다. 대부분의 경우 코멘트보다는 테스트 케이스가 더 유용합니다. - 짧은 코드가 읽기 좋습니다.
함축적(implicit)인 코드보다는 명시적(explicit)인 코드가 읽기 좋습니다.
성능과 유연성에 대한 균형 잡힌 시각
- 성능은 매우 중요한 조건이지만, 대부분의 경우 우선순위가 높지 않습니다(중요도와 우선순위를 헷갈리면 안 됩니다.)
성급한 최적화의 폐해에 대한 수많은 격언이 있습니다. - 좋은 코드는 유연성이 있습니다.
그러나 유연성이 있고 어려운 코드보다는 유연성이 없더라도 쉬운 코드가 더 좋은 코드입니다.
"추상화의 함정"에 대한 경고
- “추상화의 함정” : 막 중급에서 벗어나 고급으로 올라서려는 개발자들에게 자주 발생하는 직업병이자 난치병
- if문을 극단적으로 배제한다.
- Factory를 과도하게 사용한다.
- 클린코드와 SOLID를 숭배합니다.
- SOLID는 도구일 뿐 목표가 아닙니다.
- 클린 코드도 부수효과일 뿐 목표가 아닙니다.
더 좋은 코드란?
"더 좋은 코드라면 가독성, 성능, 유연성 모두 중요합니다. 그중에서 하나를 골라야 한다면, 두 말할 것도 없이 가독성입니다. 더 좋은 코드와 잘 동작하는 코드 중에서 하나를 골라야 한다면, 잘 동작하는 코드입니다."
AI 시대에 대한 현실적인 통찰
확장판에 추가된 내용에는 "출간 후 2년, 그다음 이야기"라는 주제로 각 저자의 원칙에 대해 덧붙이는 말이 들어 있었다. "AI 시대, 어떤 개발자가 될 것인가?"에 대한 내용이 주를 이루고 있다. 이 부분에서도 장동수 저자님의 이야기가 큰 감명을 주었다.
"코딩 AI가 시니어에게 유리한가 주니어에게 유리한가? 개발자를 4가지 부류로 나눠서 생각해 보자.
- AI를 잘 활용하는 시니어
- AI를 활용하지 못하는 시니어
- AI를 잘 활용하는 주니어
- AI를 활용하지 못하는 주니어
AI를 잘 활용하는 시니어 개발자가 가장 좋은 결과를 만들겠지만, 가성비 때문에 AI를 잘 활용하는 주니어 개발자도 여전히 기회가 있습니다. AI를 활용하지 않는 시니어는 제한적인 기회가 남아 있겠지만, 그마저도 점점 줄어들 것이고 AI를 활용하지 못하는 주니어에게는 기회가 없을 것입니다."
"가성비 때문에 AI를 잘 활용하는 주니어 개발자에게 여전히 기회가 있다"는 말이 참 현실적이고 한 편으로는 희망적으로 느껴졌다..ㅋㅋㅋ 확실히 요즘엔 AI를 잘 다루는 것 자체가 능력이구나. 더 적극적으로 AI 도구들을 활용해야겠다.