[책] 개발자 원칙 / 테크리더 9인 공저

 

개발자 원칙을 읽었다. 

워낙 핫하던 책이라 한 번 읽어봐야지 생각하고 있었는데, 마침 동네 도서관에 장서가 있어 대여할 수 있었다 ^___^ 

 

공감가는 내용도 많고, 내가 항상 고민하고 있는 내용도 있었다. 또, 그런 고민거리들을 먼저 생각하고 해결해나간 사람들의 이야기를 들을 수 있어 많은 도움이 되었다. 이를 통해 좋은 인사이트를 많이 얻을 수 있었다. 

 

 

1. 오류를 만날 때가 가장 성장하기 좋을 때다 

오류를 만나는 일은 개발자에게 즐겁지 않은 일입니다. 하지만 백엔드 엔지니어로서 저는 "백엔드 엔지니어의 실력은 얼마나 많은 오류와 장애를 만나고 이를 해결했는지 여부에 따라 갈린다" 라고 말합니다. 
첫 번째 원칙은, '오류가 발생하면 소스 코드 레벨에서 이해하자' 입니다. 검색하여 해결책을 얻는 것에서 한 발 더 나아가서 해당 툴의 소스코드를 확인하는 것으로 관련 에러가 왜 발생하는지, 해결하려면 어떻게 해야하는지 같은 깊은 지식을 얻을 수 있습니다. 파생되거나 비슷한 문제를 예방할 수도 있게 됩니다. 이것이 바로 제가 소스 레벨에서 오류를 확인하라 주장하는 이유입니다.
두 번째 원칙은, 알아낸 지식은 글로 공개하라는 겁니다. 소스 레벨에서 이해한 내용을 결과물로 남기는 것이 중요합니다. 블로그에 정리하거나, 오픈소스에 기여하여 결과물을 남깁니다. 또, 가급적이면 결과물을 공개해 다른 사람의 조언을 들을 기회로 삼아보시길 바랍니다. 

- 저자 강대명 님

 

강대명 님의 파트를 읽으면서는 감탄의 연속이었다. 레디스 오픈소스의 오류를 코드 레벨까지 확인하여 오픈소스의 버그임을 알아내어 레디스 컨트리뷰터가 된 일화나, 네이글 알고리즘의 동작 방식을 이해하고 TCP 서버의 설정을 수정한 일화는 정말.. 대단하다는 생각만이 들었다. 

 

나는 나를 기술을 익힐 때 "왜?" 라는 질문을 던지는 사람이라고 소개한다. "왜" 그런지를 알아야 제대로 이해할 수 있고, 다음에 같은 문제를 만났을 때 잘 해결할 수 있다고 믿기 때문이다. 하지만 저자의 글을 읽다보면 나의 "왜?" 는 정말 미약한 수준이었구나.... 싶을 정도로 깊은 수준으로, 한 걸음 더 들어갈 수 있다는 걸 깨달았다. 

 

오류를 만나거나 이슈가 발생하면, 왜 그런지 관련 자료를 찾아보고, 소스 코드를 확인하고, 오픈 소스에 기여하고, 블로깅을 하자. "왜?" 라는 질문에 항상 집중 할 수 있도록 하자. 

 

 

2. 남을 향한 자존심을 버리고, 나를 향한 자존감 채우기

학창 시절을 떠올려보면 늘 나보다 잘 하는 똘똘한 친구가 있었습니다. 같은 사람인데 나는 왜 이렇게밖이 못 할까 하며 자존심이 상하기도 합니다. 학교에서뿐만이 아닙니다. 천재들은 사회에도 있습니다. 내가 일주일 고민한 문제를 몇 시간 만에 해결합니다. 나는 열심히 걸어서 가까스로 목적지에 가깝게 다가갔는데, 홀연히 택시 타고 온 누군가가 결승점에 먼저 도달할 때 느끼는 감정과 비슷합니 다. 그런 상황이 벌어질 때마다 나를 지키고 분연히 일어나고 성장하려면 자존심을 키워서 다른 사람과 비교하지 말고, 자존감을 키워서 과거의 자신과 비교해야 합니다.

- 저자 김 정 님

 

내 입으로 말하긴 뭐하지만 학창시절부터 줄곧 중상위권의 성적을 유지하는 사람이었다. 거만한 소리지만 대다수의 일은 노력하면 그만큼 결과가 왔다. 코딩도 그럴 줄 알았다. 학원 초반에 별(*)찍기 10문제를 숙제로 내줬는데, 정말 하루 온종일 붙잡고 있었는데 3문제를 겨우 풀었다. 그 날의 자괴감, 내가 잘 할 수 있을까? 하는 무한한 불안감은 지금도 생생히 기억한다. 수강하는 내내 옆자리에서 강의를 듣는 사람이 나보다 이해도 빠르고, 내가 몇 시간을 끙끙댄 문제를 금방 풀어내는 모습을 보며 자존심이 상하기도 했다. 취업을 하면 다 해결될 줄 알았는데, '진짜 개발자' 가 되기 위해 필요한 건 왜 이렇게도 많은지? '네카라쿠배 이렇게 일한다'? 한동안 그런 것들을 좇으며 조바심을 많이 냈다. 그 덕에 공부도 많이 하긴 했다만, '정말 필요해서' 공부했다기 보다는 '이렇게 안하면 안될 것 같아서' 어쩔 수 없이 했던 것이다.

 

이제는 안다. 그런 비교는 나를 좀먹는 것이란 걸. 비교하는 대상을 다른 사람으로 향하지 말고, 스스로의 내면을 향하도록 해야 한다. 과거의 나와 현재의 나, 나 자신과 비교할 때 자신만의 속도로 성장할 수 있다.나의 커리어로 돌아보면, 작년의 나는 허덕였을 일을 지금은 하고 있다. 아니, 당장 1주일 전에 짜둔 코드도 오늘 리팩토링을 했다.

 

타인을 향한 자존심을 버리고, 나에게 집중하여 자존감을 세우자. 나에게 맞는 방법으로 작은 성취들을 꾸준히 만들어 나가자. 책에서 소개한 GTD 방식이나, SMART한 목표 설정을 통해 지속적인 성취감을 느끼도록 해보자.

 

1. Get - Things - Done 으로 태스크를 분리하여 일을 처리하되, 큰 일보다는 작은 일 부터 해치우는 방식.

2. 구체적인 Specific 목표를 달성하는 기준 Measurable을 정하라. 이는 달성가능하며 Achievable, 업무와 관련이 있어야 한다 Relevant. 목표에는 목표시간 Time-boxed이 있어야 한다. 

 

 

3. 이직의 이유

고민 끝에 두 가지 기준을 세웠습니다. 첫째, 일과 사람의 관점에서 그 동안의 경험보다 더 넓은 영역을 경험할 수 있는 곳. 둘째, '기술'이라는 영역에 국한되지 않고 관리 경험을 쌓을 수 있는 곳. 내가 리더십을 발휘해야 팀의 규모가 커지고, 그만큼 관리하는 일의 범위가 커질 때 어떻게 팀원들이 그리도 팀이 성과를 낼 수 있게 할까를 고민하고 실행하는 역할에 도전하고 싶었습니다. 
그리고 '기술' 관점에서만 의사결정을 돕는 것이 아닌 서비스 및 프로젝트 관점에서 목표를 달성하는 데 필요하는 모든 영역에서 필요한 일을 찾아내고 적합한 의사결정을 내릴 수 있게 하는 역할도 수행해서 성장의 기회를 삼고 싶었습니다. 

- 저자 박미정 님

 

많은 개발자의 이직 사유 중 하나는, '성장 욕구' 이다. 여기서 말하는 '성장'이란 무엇인가? 성장의 범위는 굉장히 넓다.사람마다 처한 환경이 다르기 때문에, 원하는 성장의 결이 다를 수 있다.

 

'성장' 이라고 하면 가장 먼저 떠오르는 것은 '기술'에 관한 것이다. 기술적인 교류를 통한 성장이나, 건강한 개발 문화, 개방적인 조직 문화 등을 통한 성장도 있다. 기술 뿐 아니라 서비스/도메인에 대한 성장도 있다. 하나의 서비스/도메인에 대한 전문성, 제품에 대한 주인의식을 들 수 있다. 기존에 하던 도메인에서 벗어나, 아예 새로운 서비스/도메인을 경험하는 도전 역시 성장의 한 종류이다. 

 

나 역시 회사를 떠나는 이유는 "이 회사에서 배울 수 있는 건 다 배워서" 인 게 베스트라고 생각한다. 책의 저자 중 한 분인 이동욱(향로) 님은 이를 "한 회사를 졸업하기에 적절한 시기" 라는 표현을 했는데, 아주 적절한 표현이라 공감이 갔다. 

 

이전에도 한 번 말했지만, 나는 놀랍게도 요즘 회사 일이 재미있다. 하루가 다르게 챌린징한 일이 튀어나오는데, 하나씩 해결해나가는 재미가 있다. 물론 힘들 때가 많지만.. 그래도 내가 감당할 수 있을 만한 난이도라 어떻게든 잘 해보고 싶다는 마음이 생긴다. 한편으로는 이번 프로젝트가 끝나면 정말 이 회사에서 배울 건 다 배울 것 같다는 생각도 든다. 물론 계속 배울 것들은 생기겠지만, 어느 정도는 컴포트 존의 영역에 들어와 있을 것 같다. 이제는 그 다음 스텝으로 넘어가도 될 것 같은 그런 영역에. 

 

 

4. 제어할 수 없는 것에 의존하지 않기

제어할 수 있는 것과 제어할 수 없는 것을 구분한 뒤 제어할 수 없는 것을 멀리하고, 제어할 수 있는 것에 집중 하면 됩니다. 외부의 요소, 이미 발생한 사건, 결정권이 없는 일 등은 제어할 수 없습니다. 이들에 의존해선 안 됩니다. 제어할 수 있는 것들에만 의존하도록 해야 합니다. 소프트웨어를 설계한다면 제어할 수 있는 속성에 항상 의존하게 설계해야하며, 현실 세계의 문제라면 현재의 사전과 환경을 어떻게 하면 더 유리하게 바라볼 수 있는지 고민하고 행동으로 옮겨야 합니다.

- 저자 이동욱(향로) 님

 

"프로그래머에게 요구되는 것은 100점이 아닌 80~90점짜리 프로그램을 기한 내에 완성하는 일이다." 일정과 퀄리티 중 한 쪽을 포기하라는 이야기가 아니라, "어떻게 하면 아무리 급해도 항상 80~90점짜리 소프트웨어를 개발할 수 있는지"가 중요하다는 말이다. 그러기 위해서는 프로그래밍을 하며 마주하는 수많은 선택의 길에서, 현재 상황에 더 적합한 코드를 판별하는 기준과 원칙을 가지고, 그에 입각하여 결정하는 것이 중요하다. 

 

DRY, YAGNI, KISS 는 널리 알려진 원칙이다. 나도 익히 들어왔고 그렇게 하기 위해 노력하고 있다. 

1. DRY: Do not Repeat Yourself (같은 기능을 반복하지 마라)

2. YAGNI: You Ain't Gonna Need It (기능이 필요하기 전까지는 미리 만들지 마라)

3. KISS: Keep It Simple Stupid (단순하라)

 

그리고 저자가 보다 강조하는 한 가지 원칙은, '제어할 수 없는 것에 의존하지 않기' 이다. 이는 내가 좋아하는 제 5 도살장의 문구와도 맞닿아 있다. 

 

하느님, 저에게 허락하소서.

내가 바꾸지 못하는 것을 받아들이는 평정심과

내가 바꿀 수 있는 것을 바꾸는 용기와

늘 그 둘을 분별할 수 있는 지혜를.