Book/개발자 오디세이아

15 May 2022

Reading time ~8 minutes

개요

개발자 오디세이아는 개발자의 삶을 항해에 비유한 책이다. 일을 하는 방법보다는 일을 하는 이유가 더 중요하다는 것을 강조하며 수많은 암초를 만나더라도 파도에 떠밀리지 않고 굳건히 개발을 하기 위한 마음가짐에 대해 다룬다. 이 책을 읽으며 더 나은 개발자의 삶을 살기 위해 한 번쯤 생각해 보면 좋을 구절들을 발췌해 보았다.

트러블 슈팅

분별력과 집중력 그리고 단호함

이슈의 종류는 두 가지이다. 내가 해결할 수 있는 것과 해결할 수 없는 것들
우리에게 필요한 것은 이 둘을 구분할 수 있는 실력, 그리고 해결해야 하는 일에 대한 집중력, 마지막으로 해결할 수 없는 일들을 생각에서 지워버리는 단호함이다. 공포는 확신이 부족할 때 생긴다. 따라서 내가 할 수 있는 일인지 할 수 없는 일인지를 구분하는 능력이 필요하다. 할 수 없는 일들에 매달릴 때 확신은 부족해지고, 공포와 두려움은 커질 수밖에 없다.

마지막 순간 증후군

소프트웨어 개발은 아주 커다란 바위를 옮기는 일과 같다. 큰 바위를 옮기는 일은 엄청난 노동력이 필요하므로 바위를 어디로 옮길 것인지, 어떻게 옮길 것인지에 대한 명확한 사전 계획이 수립된 후에 실제 행동에 들어가는 것이 마땅하다. 지렛대와 통나무 발판을 이용해서 매일매일 꾸준히 바위를 옮겨야 한다.
소스코드를 바위에 비유한다면 마지막 순간에 온 힘을 다한다고 해도, 아직 반도 개발되지 않은 소프트웨어가 하루아침에 완성될 수 없다. 프로젝트 초기에 시간을 낭비하다가 프로젝트를 끝내야 하는 기한이 다가오면 움직이지 않는 바위를 밀다가 자포자기 상태에 빠지는 것을 ‘마지막 순간 증후군’이라고 한다.
이런 ‘마지막 순간 증후군’에 걸릴 수밖에 없는 이유 중 하나는 제대로 된 설계 없이 무작정 바위를 밀면서 프로젝트를 시작하기 때문이다. 일단 무작정 바위를 옮겼다가 잘못된 곳으로 옮겼음을 깨닫고 바위를 다시 옮기는 경우를 일명 ‘삽질’ 혹은 ‘맨땅에 해당하기’라고 한다.
대부분 한 번 바위를 옮기고 나면, 잘못된 곳으로 옮긴 바윗덩어리를 되돌리거나 방향을 바꾸는 것은 매우 어려운 일이다. 결국 새로운 바위를 가져다가 다시 옮기게 된다.
이런 행동을 하는 이유는 첫째, 그것이 가장 쉬운 방법이기 때문이고 둘째, 경험과 이론이 부족하기 때문이다. 모자라고 경험 없는 수많은 개발자들이 머리를 맞대고 고민해 봤자, 경험 있고 이론을 갖춘 단 한 명의 개발자의 기획과 설계를 따라갈 수 없다. 어쩔 수 없다면 가능한 미리 많은 삽질, 다양한 삽질을 해보는 수밖에 없다.

지혜로운 삽질

삽질은 체험으로 배우는 가장 확실한 방법이다. 실제 해보지 않고서는 알 수 없다는 주장은 어느 정도 진실이다. 하지만, 무분별하게 맨땅에 헤딩하는 것을 예방하려면, 어느 정도 생각을 먼저 해야 한다. 단순히 무의식적으로 똑같은 삽질을 반복해 봤자 나오는 것은 흙덩어리뿐이다.
버그를 잡는다고 똑같은 코드에 printf만 넣는 것을 반복할 것이 아니라, 디버거도 써보고 다른 모듈과의 연계성도 검토해 봐야 한다. 익숙하지 않더라도 새로운 시도로써 삽질의 범위를 넓히고, 동시에 정교한 타겟팅 능력을 길러야 한다. 삽질을 가장 잘하는 사람은 한 번의 삽질로 가장 많은 땅을 팔 수 있는 사람이다. 가장 삽질을 잘하는 사람은 어느 곳에 삽을 대야 하는지 아는 사람이다. 그것은 경험과 이론이 적절히 결합되어야 가능한 경지다.

어떤 개발자가 되고 싶은가?

결과에 상관없이 주어지는 기쁨

몰입이 가능하더라도 사후 긍정적 기분을 느끼지 못한다면 그것은 좋아하는 일이 아니다. 버그를 해결하기 위해 몇 시간 쉬지 않고 매달리거나 밤을 지새워본 경험이 있을 것이다. 밤새 문제를 파고들어 결국 문제를 해결하고 맞는 새벽의 아침은 황홀하게 느껴진다. 반면 밤을 새우고도 문제가 해결되지 않는 경우 뜬 눈으로 맞이하는 새벽은 극심한 피로만을 가져다줄 뿐이다. 이렇듯 몰입이 가능하나 결과에 큰 영향을 받거나, 몰입 경험 후에 결과에 상관없이 긍정적인 기분을 느끼지 못한다면 좋아하는 일이라고 보기는 어렵다.

무지의 무지

앎의 시작은 무지를 지각하는 것에 있다. 무엇을 모르는지 모르면 아무것도 시작할 수 없다. 원인은 자신이 무엇을 모르고 있는 것인지 자문해 보고 그 대답을 찾으려는 노력을 하지 않았던 것에 있다.
어떤 일이든지 모르는 부분을 파악하고 우선적으로 알아야 할 사항들을 정하는 것이 일을 시작하는 방법이다. 오직 알아야 할 것은 무엇을 먼저 해야 하는가이다. 그리고 그 무엇을 먼저 하는 데 있어서 내가 알아야 하는 것들을 정의할 수 있어야 한다. 알아야 할 것들이 나오면, 당연히 내가 모르고 있는 것들이 나오게 된다. 그다음은 우선적인 것들부터 차근차근 알아가면 된다. 길을 찾기 위해서는 지도부터 찾아야 한다.

주도적인 사람

본인이 업무에 있어 얼마나 주도적인 사람인지 자문해 봐야 한다. 대부분의 개발자들은 스스로 일을 주도하지 못하고 내려오는 소프트웨어 명세와 업무지침에만 얽매여 있는 경향이 많다. 다른 사람의 운전 패턴에 몸이 적응하지 못해서 멀미가 나는 것처럼, 직무와 개발 업무 역시 남들이 짜놓은 판에 스스로를 맞출 수밖에 없다. 판이 바뀌면 다시 적응해야 한다.
일을 주도한다는 것은 일에 대한 자발적인 태도를 의미한다. 난로를 따듯하게 하기 위해서는 우선 장작을 넣어야 한다. 장작도 넣지 않은 채로 먼저 난로가 따듯해지기를 바랄 수 없는 것처럼 주어진 일만 하는 것이 아니라 먼저 주도적으로 일을 처리해야 하는 것이다.

고된자 vs 스고자

고된자 : 고용된 자, 수동성을 의미
스고자 : 스스로 고용하는 자
근본적으로 이는 태도의 문제다. 어떤 사람이 세 사람의 석공에게 각각 “당신은 지금 무슨 일을 하고 있습니까?” 라고 물었을 때, 첫 번째 석공은 “나는 생계를 유지하기 위해 일을 하고 있습니다.” 라고 말했고, 두 번째 석공은 “나는 이 나라에서 최고의 석공으로서 일하고 있습니다” 라고 대답했다. 마지막 석공은 “나는 사원을 짓는 일을 하고 있습니다” 라고 말했다.
위의 인용에서 첫 번째 석공이 바로 ‘고된자’이고, 세 번째 석공이 진정한 ‘스고자’에 가깝다. 두 번째 석공이 가지고 있는 자부심도 중요하지만 한 가지 냉정히 바라봐야 할 부분은 두 번째 석공은 자신의 능력적인 부분에만 매몰되어 있을 수 있다는 것이다.
‘스고자’의 핵심은 능동성이며 그 능동성은 조직에서 발현되는 것이다. 세 번째 석공은 본인이 하고 있는 직무의 큰 그림과 완벽하게 조화되어 있다. ‘스고자’의 핵심은 자기 주도성이다. ‘스고자’는 일에 지배되지 않고, 일을 지배하는 사람이다.
두 번째, 업무 리스트는 꼼꼼하게 관리하고 매일 업데이트하는 것이 좋다. 주도성을 가지고 일을 한다고 해서 능력이 갑자기 일취월장하지는 않는다. 시간상 여건상 못하는 업무는 있어도, 깜빡 놓치는 업무는 없어야 한다. 스스로 모든 일들을 관리하고 제어할 수 있다는 생각을 가지고, 실제로도 가능한 모든 일들을 최대한 자기 관리하에 두자. 자기주도성은 책임감을 가지는 것이고, 그 책임감은 일이나 회사에 대한 것이 아닌 자기 자신을 위한 것이라는 사실을 명심하자.
세 번째, 의지건 열정이건 무엇이라도 제대로 하려면 건강한 몸과 체력이 중요하다. 김태호 작가의 웹툰 <미생>에 나온 말 대로 '정신력'은 '체력'이란 외피의 보호 없이는 구호밖에 되지 않는다. 운동과 건강관리라는 절제된 자기 관리 없이는 그 어떤 것도 이루기 어렵다는 것을 명심하자.

함께 가는 길, 좋은 팀이란?

좋은 팀

팀, 프로젝트, 프로세스의 핵심은 ‘사람’이다. 기술력보다는 인간관계가 프로젝트의 성패를 결정짓는다. 프로세스를 흥하게 하는 것도 사람이고 망하게 하는 것도 사람이다.
사람을 다스린다는 것은 일을 잘 할 수 있는 여건을 조성하며 지원해주는 일, 나아가 각 개인의 강점을 이끌어내서 팀의 가치를 창출하는 것이 핵심이다. 통상적으로 관리자의 역할이란 일을 잘 할 수 있는 여건 조성에 큰 비중이 있고, 경영자는 조직원의 강점을 이끌어 내는 것에 그 역할의 비중이 크다.
개인 역시 마찬가지다. 자신을 관리한다는 것은 자신이 가장 성과를 낼 수 있는 환경을 스스로 조성하는 것이고, 개인 경영이란 자신의 강점을 이끌어내고 발전시켜 가치를 만들어 내는 것을 말한다. 프로젝트 운용에서 팀원이 재능을 충분히 발휘하여 성과를 내게 하려면 가장 자기다운 방식을 택하도록 도와주어야 한다.
적합한 사람들로 팀을 구성하는 것, 그다음 목표는 정하되 수단은 그들에게 맡겨두는 것, 이것이 프로젝트 성공의 비결이다.

프로젝트의 계획과 추정

처음 세운 계획대로 100% 진행된 프로젝트는 존재하지 않는다. 프로젝트를 시작함에 있어 가장 중요한 것은 프로젝트의 모든 핵심적인 요소들을 철저히 검토하는 것이다. 이 과정을 통해 위험 요소가 식별되고, 그에 대한 대책이 모색된다.
“잘못된 방향으로 힘차게 걷느니 절뚝거리더라도 옳은 방향으로 느릿하게 가는 것이 낫다”
초기 단계에서 목표와 요구사항을 완벽하게 정립하고 일을 시작하는 것은 불가능한 일이다. 그보다는 실제 일을 해나가며 현실적인 목표에 수렴해가고, 요구사항도 수정과 보완을 거쳐 명확해지게 되는 것이 일반적이다. 계획 자체는 언제든 무용지물이 될 수 있지만, 계획을 세우는 과정 자체는 꼭 필요하다. 계획과 목표를 세우는 과정에서 많은 검토와 분석이 이루어지고 위험 요소들이 식별되며 프로젝트의 성공 가능성이 높아지게 된다.

코드 리팩터링 - 좋은 코드

리팩터링은 코드 가독성을 높이고 코드 중복을 없애는 것에 초점을 맞춰야 한다. 훌륭한 프로그래머는 사람이 이해할 수 있는 코드를 짠다. 좋은 코드를 작성하는 요령은 다음과 같다.
- 죽은코드(전혀 사용되지 않으며 향후에도 사용되지 않을 코드들)을 삭제하는 것
- 함수명과 변수명을 잘 지어야 한다 : 이름만으로도 기능과 의도하는 바를 알 수 있도록
- 한 가지 기능만 수행하는 함수나 메서드를 작성할 것
- 주석보다 코드만으로 이해가능하도록 작성할 것
- 중복 코드를 없앨 것
- 모듈화, 계층화를 잘할 것
좋은 코드는 결국 이타적인 코드이다

의식적인 연습 - 불편함을 느끼는 능력

본인이 다소 불편하다고 느끼게 되는 지점을 찾아 그 지점이 편안하고 익숙해질 때까지 의식적으로 훈련하는 과정이 필요하다

개발자의 언어

개발자에게 필요한 언어의 기술 : 개발자들만큼 자기만의 세상에 갇혀 지내는 인간들도 흔치 않다. 컴퓨터와 프로그래밍 언어로 대화하는 개발자들은 실제 인간과의 언어소통에 서툰 경향이 있다. 실제 잘못된 의사 전달로 크고 작은 문제가 발생하는 것을 심심찮게 보곤 한다. 프로그래밍 언어는 한 문자만 잘못 사용해도 컴퓨터가 알아먹질 못한다. 소프트웨어 프로그램은 정해진 구문 규칙에 맞게 주의해서 작성해야 원하는 결과를 도출해 낼 수 있다. 기계와의 엄격한 커뮤니케이션 룰이 일상화된 개발자들이 외부 세계와의 대화에서는 모호한 표현을 빈발한다는 것은 참으로 아이러니한 일이다. 영업은 숫자로 말하고, 소프트웨어 개발자는 코드로 말한다는 우스갯소리가 있다.
개발자에게 필요한 언어의 기술은 C나 JAVA뿐만이 아니라, 상대방을 배려하고 소통하고자 하는 인간의 언어임을 잊지 말아야 한다. 톰 디마르코와 티모시 라스터가 쓴 책 <피플웨어>에서 지적했듯 업무에서 발생하는 문제들은 대부분 기본적으로 기술의 문제가 아니라 조직사회학의 문제다. 너와 나의 소통의 오류 또는 부재가 기술의 부재나 버그의 존재보다 더 심각하다. 조직 유지의 기본 바탕은 커뮤니케이션이며, 이는 서로가 어떤 언어를 사용하느냐에 달려 있다. 서로가 협업하는 데 있어 어떤 언어를 사용하느냐는 매우 중요하다. 같은 언어를 씀에도 불구하고 커뮤니케이션에는 오류가 발생하기 마련이다. 효과적인 소프트웨어 개발에 협업은 필수적이다. 다수가 함께하는 협업은 쉽지 않다. 협업을 강조하는 이유는 그만큼 협업이 어렵기 때문이다. 여러 명이 일을 하면 조정과 의사소통은 반드시 필요하다. 비용 역시 매우 크다. 개인의 전문성 결여를 보완해줄 수 있는 등의 협업이 주는 부차적인 장점을 상쇄하고도 남을 만큼 협업으로 인한 비용은 작지 않다.
개발자의 언어가 문제가 되는 때는 다른 부서와, 혹은 고객과의 의사소통을 하는 경우다. 커뮤니케이션 기술이 없다 보니, 자기 이야기만 하는 경우가 태반이다. 사람은 다른 사람과 말을 할 때 듣는 사람의 경험에 맞추어 말해야만 한다. 프론트엔드 개발자와 이야기할 때는 프론트엔드 개발자가 사용하는 말을 써야 한다. 다시 말해 테스터가 이해할 수 있는 테스트 케이스나 테스트 시나리오에 기반하여 의사소통을 해야지 자기가 수정한 코드에 대화의 맥락이 묶여 있으면 안 된다는 것이다. 영업과 이야기할 때는 영업의 언어를 사용해야 한다. 해외 출장을 가서 외국 엔지니어 앞에서 혼자 한국말로 떠들지는 않을 것이다. 상대방의 언어에 익숙하지 않다면 최대한 보편적인 언어를 사용하려고 노력해야 한다. 기계와의 커뮤니케이션이 아닌 사람과의 커뮤니케이션이 프로젝트의 성패를 가늠한다.