개발자 원칙

*개요

 회사 AWS 자격증을 따기 위해서 약 10만 원어치 책을 샀더니 1권의 책을 증정해 준 책이 개발자 원칙 책입니다. 각 CTO급 개발자 리더분들의 자신만의 스토리를 담아낸 책입니다. 이중에 박미정, 박종천, 이동욱(향로)님은 꾸준히 접하고 있었기에 요즘에 어떤 생각을 하시는지 기대가 되었습니다. 또한 잘 알지 못하는 다른 분들의 생각을 엿볼 수 있는 기회였습니다.

 

 

책을 읽고 가장 인상 깊었던 장동수님과 김미정 님의 글을 정리해 보겠습니다.

 

달리는 기차의 바퀴를 갈아 끼우기(09) - 장동수

 좋은 코드는 유연성이 있습니다. 그러나 유연성이 있고 어려운 코드보다는 유연성이 없더라도 쉬운 코드가 더 좋은 코드입니다. 유연성에는 추상화가 필요합니다. 유연성을 위해서 시작한 추상화가 재사용성과 잘못 만나면 '추상화의 함정'에 빠지게 됩니다. 개발자들만 걸리는 직업병이자 난치병입니다. SOLID는 도구일 뿐 목표가 아닙니다. 클린 코드도 부수효과일 뿐 목표가 아닙니다.

 

 초보 개발자라면 'Make it work'만으로도 벅찰 겁니다. 그 시기를 지나 막 중급으로 올라설 때면 어떤 일이든 시간만 충분히 주어진다면 'Make it work'를 지나 'Make it better'를 고민해야 합니다. 그러나 고민이 지나쳐서 집착이 되면 오히려 역효과가 나타납니다. 그래서 'Make it work'한 다음에 'Make it better' 하는 것이 중요합니다. 혹시라도 기회가 주어지면 먼저 굴러가는 바퀴를 만들어야 합니다. 더 잘 굴러가는 바퀴를 만드는 것은 그다음입니다. 굴러가는 바퀴를 만드는 일이 지금의 밥값을 하는 일이라면, 더 잘 굴러가는 바퀴를 다시 발명하는 과정은 미래의 몸값을 만드는 일입니다.

 

 기술 부채와 항상 함께 등장하는 단어가 레거시입니다. 개발자들만큼 레거시를 부정적인 의미로 사용하는 집단이 또 있을까요? 레거시는 죄가 없습니다. 레거시는 해결해야 할 기술적인 과제인 '기술 부채'도 포함하고 있지만, 많은 문제를 해결한 그리고 해결할 유용한 '기술 자산'도 포함하고 있습니다. 여건이 된다면 당장 가용한 리소스를 모두 투입해서 기술 부채를 청산하는 게 최선이지만, 대개는 새로운 기능을 추가하는 일이 먼저입니다. 기술 부채를 관리 가능한 수준으로 유지하면서 기술 자산인 새로운 기능을 늘려나가야 합니다. 앞에서도 언급한 것처럼 관리 가능한 부채는 자산의 일부입니다.

 

 단언컨대 기술 부채가 없는 개발은 불가능합니다. 큰 마음먹고 한 번에 탕감할 순 있겠지만, 금세 새로운 부채가 쌓입니다. 처음부터 새로 만들어도 기술 부채를 피할 수 없습니다. 기술 부채를 절대 허용하지 않겠다는 욕심이 더 큰 기술 부채를 만듭니다... 동작하는 코드만을 추구하고 더 좋은 코드를 외면하면 기술 부채가 쌓일 수밖에 없습니다. 그렇다고 더 좋은 코드만을 추구하고 도작하는 코드를 외면하면 비지니스를 유지할 수 없습니다. 재정적인 부채는 자산의 일부입니다. 적절하게 관리할 수 있다면 기술 부채도 '자산'의 일부가 될 수 있습니다.

 

 

이직, 분명한 이유가 필요해(05) - 김미정

 일을 하면서 주인의식을 가질 수 있는 길은 내가 만드는 제품의 의사결정에 참여하는 겁니다. 작은 스타트업을 선택한 이유는 주인의식이었습니다. 면접 과정 그리고 별도의 티타임에서 팀이 어떻게 의사결정을 내리고 반영되는지 묻고 듣는 시간을 넉넉히 활용했습니다. 

 

 개발자는 경험이 쌓일수록 필요한 기능을 개발하는 역할에서 필요한 일을 찾아내는 역할로 시야를 확장해가야 합니다. 어떠한 변화가 찾아와도 어느 정도 일을 해낼 수 있는 규모와 체계 속에서 스스로 기회를 발견할 수 있는 환경을 원했습니다. 공개적인 자료, 면접 과정의 체계 그리고 면접관들과 대화를 통해 조직의 개발/조직 문화를 파악하고 나서 이직할 회사를 최종 결정했습니다.

 

 이 조직에서 저는 단순한 의미의 '개발'이 아닌 '개발을 통해 일'을 하는 주체로서 자리 잡기 시작합니다. 이 시기에는 개발/조직 문화 개선에 기여하고 싶다는 생각이 들었습니다. 기여에 대한 의지가 생겼단 것은 달리 말하면 기존 개발/조직 문화의 분명한 개선점을 인지하고 있다는 말이기도 합니다. '분명히 개선이 필요하다고 스스로 생각하는 개발/조직 문화 안에서, 그리고 동료 및 상사로부터 개선에 대한 의지를 확인하지 못한 상황에서 나는 한 걸음 더 성장할 수 있을까? 나의 개발/조직 문화에 대한 기여 욕구를 무시할 수 있는 것일까?', 퇴사 이후 새로운 직장을 찾는 면접 과정에서 나는 다른 직군과의 협업 과정, 커뮤니케이션 개선점, 그리고 면접관들의 개발/조직 문화 개선 경험에 대해 유독 질문을 많이 했습니다.

  

  '개발자는 무엇인가?', '수많은 개발자 중에서 박미정이라는 개발자는 무엇을 잘하는 개발자인가?'라는 질문이 계속되었습니다. 기술이라는 범주 안에서 갇혀서 스스로를 정의하기보다 '서비스를 만들고 성장시키는 일이 즐거운 사람', '서비스를 위해 기술이라는 도구를 잘 다루는 사람'으로 저를 정의했습니다. 훗날 책을 집필할 때 저를 '서비스/프로덕트 만들기를 좋아하는 프로그래머'라는 한 줄로 소개하기도 했습니다. 베트남에서 서비스와 도메인에 대한 유형을 넘어서 새로운 나라 그리고 문화 속에서 서비스를 만들어가는 개발자로서 경험의 폭을 대폭 넓혔습니다.

 

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

 

 

*느낀점

 장동수 님의 패스트캠퍼스에 있는데 요즘 강의를 듣고 있는 입장에서 익숙했습니다. 요즘 기술적으로 자료와 강의가 많은 시대를 살아가고 있습니다. 많은 패턴들과 신기술들이 하루하루 쏟아져 나오는 세상에서 개발자는 어떤 원칙을 가지고 일을 해야 하는지 실전 내용을 핵심적으로 배웠습니다. 가장 중요한 것은 가장 먼저 작동하는 기능을 만드는 것입니다. 더 나은 방식은 그 이후에 고민해도 되며 만약 추상화를 너무 많이 고민한다면 좋은 설계보다는 일단 작동하는 기능을 만드는 것이 낫습니다. 또한 레거시를 너무 부정적으로 인식했던 모습을 되돌아봤습니다. 지금의 신기술도 미래에서는 레거시입니다. 레거시 자체가 나쁜 것이 아니고 이 또한 자산의 일부로서 계속 발전시키고 관리해야 할 대상입니다. 

 

 김미정 님은 이미 여러 칼럼을 많이 쓰시고 계셔서 이전부터 많이 읽었습니다. 이 책을 통해 어떠한 철학을 가지고 회사들을 이직하셨는지 흐름을 알 수 있었습니다. 항상 목표를 가지고 퇴직을 하신 후 다시 취업을 하셨던 것이 인상적이었습니다. 주인의식을 가지고 기술에 국한하지 않고 어떻게 프로덕트와 서비스를 성장시킬 수 있을지 고민하는 자세를 배웠습니다. 또한 커뮤니케이션과 개발/조직 문화에 지속적으로 관심을 가지고 개선하려는 점에서 나 또한 회사에서 좋은 문화를 가지도록 개선할 수 있는 방법은 무엇인지 고민해 보게 됐습니다.

 

 이 책의 대부분 CTO급 개발자들은 필드에 오래 있으면서 기술을 강조하기보다 프로덕트에 많은 관심을 가지고 있었습니다. 다양한 패턴과 공식들은 좋은 도구이지만 결코 목적이 될 수 없습니다. 개발 내용이든 커뮤니케이션이든 현재 상황에서 개선할 수 있는 부분들을 발견하고 주도적으로 처리하는 자세를 가져야겠다는 도전이 되었습니다. 저는 스스로를 기술력뿐 아니라 비지니스 문제해결을 도전하는 개발자로 정의하고 싶습니다. 회사의 다양한 프로세스들 중에 문제가 되는 부분들을 주도적으로 개선하여 회사에 기여하고 싶습니다. 개발은 회사의 문제와 목표를 해결하기 위한 도구입니다. 개발 그 자체가 아닌, 좀 더 시야를 넓혀서 회사의 방향성과 목표를 같이 탐구하고 발전시키는 팀원이 되고 싶습니다.