개발자 원칙

 

 

 박성철(컬리 풀필먼트 & 딜리버리 프로덕트 본부장), 강대명(레몬트리 CTO), 공용준(카카오 클라우드 테크니컬 디렉터), 김정(코드스쿼드 대표), 박미정(무신사 개발 실장), 박종천(몰로코 헤드 오브 솔루션스 아키텍쳐), 이동욱(네피림)(데이블 스페이스비전그룹 테크니컬 디렉터), 이동욱(향로)(인프런 CTO), 장동수(데이원컴퍼니 CTO) 이미 알고 있는 분도 있었고, 새로 알게된 분들도 있었다. 위의 CTO, 시니어 개발자 등 직책을 가진 9명이 작성한 글을 모아둔 책이다. 수필처럼 읽기 쉬운 부분도 있었고, 개념을 이해해야 되는 내용도 있었으나 전반전으로 쉽게 읽히는 책이었다.

 

 

 항상 고민하는 "나는 개발자로써, 중간관리자로써 잘 하고 있나?"의 해답을 찾고 싶었다. 이미 어느 정도 위치에 있는 9명의 원칙을 해킹하고 적용하면 어느 정도는 답이 되지 않을까 싶었다. 이 책에 나온 원칙들과 원칙들에 대한 실례는 다 중요했다. 책 내용의 원칙만을 나열하지 않았고, 내가 생각하기에 공감됐던 부분과 원칙을 발췌하여 생각을 적었다.  

 

 

 

 

 프로그래머의 삶이 사기 행각에 동원되는 것일 뿐이라는 느낌이 너무 싫어서 직접 사업을 해보기로 했습니다. 저에게 누군가 가치 있는 일을 시키지 못한다면 제가 그렇게 일할 수 잇는 회사를 만들고 다른 프로그래머들과 함께 더 가치 있는 일에 자신의 재능을 사용할 수 있게 해야 하겠다는 포부를 품게 되었습니다. - 개발자 원칙 중 -

 

 프로그래머는 기본적으로 다른 직군을 도와주는 역할을 한다. 사내 시스템을 개발한다면, 회사 동료들이 고객이고, 시스템으로 힘들거나 불편한 부분을 자동화해주거나 개선해준다. 서비스 앱을 개발한다면, 평소 어떤 문제를 불편하다고 느껴 내가 만든 서비스를 이용하는 사람들이 고객이다. 개발자가 사용하는 시스템을 개발한다면, 개발자가 고객이다. 어떤 개발을 하든지 문제를 해결하고 불편한 부분을 개선하면서 보람을 느낄 수 있어야 한다.

 

 

 

 

오류가 발생하면 소스 코드 레벨에서 이해하자, 알아낸 지식을 글로 공개하라

개구리를 해부하지 말고, 직접 만들어라. 니콜라스 네그로폰데 박사가 <<바이트>>에 기고한 글입니다. 개구리를 더 잘 이해하려면 개구리 해부보다는 개구리와 똑같다고 부를 수 있을 개구리를 직접 만들어보라는 내용입니다.

바퀴를 다시 발명하는 일은 결과보다는 과정에 더 큰 가치가 있습니다. 현실 세계에서는 과정보다 결과가 중요하고, 바퀴를 다시 발명할 기회는 좀처럼 없습니다. 기회가 오면 놓치지 말고, 기회가 없으면 만들어야 합니다.

 

 서로 다른 장의 글이지만, 모두 비슷한 이야기를 하고있다. 개발자를 위한 라이브러리나 프레임워크를 사용하다가 오류가 발생하면 기술 문서나 스택오버플로우, 구글을 찾아보기 바쁘고 해결한 뒤 간단히 공유하고 끝낸다. 프레임워크나 기술이 어떻게 동작해서 발생하는지 코드 레벨에서 찾아본 적은 없다. 나는 객체지향적으로 캡슐화된 기능의 내부를 알아야 하는지 의문이 들었다. 하지만, 역시 개발 실력을 늘리는 데엔 다른 사람의 코드를 분석하고, 만들어보는 것 만큼 확실한 건 없다.

 

 

 

 

항상 협업 모드로 작업하기

오픈 소스 문화가 가지는 가장 큰 장점은 다른 사람과 공유한다는 점입니다. 소스 코드를 공유한다는 것보다 공유하는 과정에서 사고방식, 의사소통, 설득과 토론이 더 중요합니다. 오픈 소스에는 코드를 가져다 쓰는 것을 포함하여, 기여하고 서로를 인정하는 문화가 포함됩니다.

코드 협업으로 한정해 보더라도 보다 많은 사전 지식이 필요하며, 수차례의 시행착오를 겪어야 정리되기도 합니다. 코드 협업 이외에도 다양한 역할의 프로젝트 참여자와 이슈를 정확하게 공유하고 모두가 원하는 해결을 이끌어내도록 커뮤니케이션하는 일 역시 노력이 필요한 영역입니다.

 

 시스템은 혼자 개발하는게 아니다. 개발자 사이에서는 Github의 PR에 대한 코드리뷰를 하고 승인을 받아야 기능 배포가 가능한 문화가 있다. 코드리뷰를 하는 사람을 배려하여, 반환하는 변수에 타입을 명시해주거나 commit을 기능단위로 만드는 등의 작업이 필요하다. 코드리뷰를 하는 사람은 자신의 코드 취향에 따른 리뷰를 하고 있는지 정말 기능적이나 개념적으로 개선이 있는 리뷰를 하는지 판단하여 커뮤니케이션 해야 한다. 다른 직군과 일할 때, 경력이 어느 정도 있는 개발자라면,기획서의 내용이나 고객이 요청한 기능에 대해 자신의 경험에서 나온 최선의 의견을 제시할 수 있어야 한다. 그러면 프로젝트 논의 중 깨닫는 것이나 새로운 것들을 더 얻을 수 있다.

 

 

 

제어할 수 없는 것에 의존하지 않기 원칙

 다양한 곳에 적용할 수 있는 원칙이다. 내가 제어할 수 없는 것과 제어할 수 있는 것을 구분하고 제어할 수 없는 것에 의존하지 않는 것이 필요하다. 개발에선 외부 시스템에 의존하지 않는 아키텍처를 생각할 수 있다. 예를들어, A시스템이 사용중인 어떤 식별 값을 매핑 테이블 없이 B시스템에서 사용한다. 나중에 A시스템의 식별 값 체계가 변하게 되면 더 이상 B시스템이 작동하지 않을 수 있다.

 

 

 

 

행동강령
- 일단 동작하게 만든 다음 더 좋게 만들어라
- 언제나 발견했을 때보다 깨끗하게 해놓고 캠핑장을 떠나라
- 바퀴를 새로 발명하는 일의 좋은 점은 둥근 바퀴를 얻을 수 있다는 점이다.

오늘보다 내일 일을 더 잘하는 사람이 되자, 지금 하는 일을 한 번 더 하게 되면, 그때는 훨씬 더 효율적으로 빠르게 그리고 더 좋은 결과물을 뽑아내자

 

어제보다 더 나은 사람이 되자, 어제보다 더 똑똑해지자, 어제보다 더 부자가 되자, 어제보다 더 일을 잘 해보자..

 

 

 

기술 교류하기, 제품에 주인의식 가지기, 체계적인 개발/조직 문화 경험하기, 개발/ 조직문화에 기여하기, 새로운 서비스/도메인 경험하기, 조직을 만들고, 관리자 역량 향상시키기

 

회사에서 얻어갈 것들이다.

 

 

 내 생각을 정리하자면, 개발자는 문제를 해결하고 불편한 부분을 개선하는 직업이다. 실력을 키우기 위해 코드 레벨에서 이해하는 것은 중요하다. 항상 협업하는 자세를 가져야 한다. 제어할 수 있는 것과 없는 것을 확실하게 구분하고, 어제보다 더 나은 사람이 될 수 있도록 노력한다.

 

 

 추가적으로 "GPAM(Goal, Plan, Action, Measure)과 SMART 방법론 그리고 개발자가 코드와 객체지향 수준의 원칙을 넘어 설계 원칙을 익혀야 하는 이유 등등"은 책을 읽어보고 삶에 적용해봐도 좋을 것 같다.