[도서 리뷰] 개발자 원칙
이 좋은 걸 개발자만 읽고 있었네
개발자 원칙 (2022.012. | 골든래빗 | 박성철 외 8명 공저 | 22,000원)철저히 제목에 속아버렸다. 현업에 당장 쓸 만한 ‘클린 코드’나 개발자로서 스펙을 증진시키는 꿀팁을 다루는 줄 알았던 이 책은 개발자를 위한 기술서가 아니라 개발자라는 직업을 가진 인생 선배들의 다정한 조언이 가득 담긴 자기계발서였다. IT 도서를 기획·편집하는 입장에서 소스나 훔쳐볼까 하고 펼쳤다가 정독해버린 김에 리뷰까지 남겨보려 한다.
이 책을 읽는 동안 가장 기억에 남는 문장은 다음 두 문장이다.
자신의 버전은 자기 스스로 올려야 합니다.
(...)
소프트웨어는 v1.0.0이 시작점입니다.
오류를 만날 때가 가장 성장하기 좋을 때입니다.
이 책의 궁극적인 목표는 개발자로서 자신만의 원칙이 있는 게 일과 삶에 얼마나 효율적인지 그리고 자신의 원칙은 무엇인지를 공유하는 것이다. 9명의 테크 리더 중 누군가는 원칙이 단 하나였고 누군가는 손가락을 꼽아야 할 만큼 많았는데, 모두가 빠지지 않고 언급하는 게 있다면 바로 목표와 방향 설정이었다. 즉, 이들이 하는 모든 말을 어떤 직업으로 치환해도 먹힌다는 뜻이다.
물리학에서 속도의 정의는 속력x방향입니다.
어쩌다 8년이나 IT 출판계에 고여버린 에디터로서 이들의 언어를 내 언어로 번역하며 읽다 보니 치열하게 일하는 사람의 모습은 직종불문 닮아간다는 걸 새삼 깨닫게 된다.
흥미로웠던 건 개발자들이 모인 만큼 자기계발도 방법론과 버전을 붙여서 한다는 것이었다. 목표 달성을 위한 방법론 중 하나가 GPAM(Goal, Plan, Action, Measure)이었는데, 소프트웨어를 개발하기 위해 기능을 쪼개고, 문제를 발견하고, 해결하고, 회고하는 그들의 업무 방식과도 닮아 있다. 이는 방법론으로 정의할 수 있는 그들의 언어가 있기 때문이지 사실 모든 직업이, 모든 삶이 마찬가지다. ‘목표 → 계획 → 행동 → 회고’는 너무 당연해서 오히려 놓치기 쉬운 모든 것의 기반이다.
나만의 원칙은 결정을 빠르게 한다.
뭣도 모르고 사전 찾아 가며 문장을 고치던 1-2년 차엔 원칙이랄 것도 없었다. 원칙을 세울 만한 토양도 없었기 때문이다. 애매하게 머리 크기 시작한 3-5년 차엔 ‘내’가 ‘원칙’이었다. 내가 어려우면 어려운 거고, 내가 읽고 싶으면 재밌는 거고, 재미 없으면 다시 쓰는 게 맞다고 여겼다. 설득도 해보고 싸움도 해보고 밤샘도 해봤지만 막상 패를 까뒤집으면 결론은 늘 같았다. “내가 맞을 수도 있고 상대가 맞을 수도 있다.”
표지 디자인 하나로 멱살 잡고 싸워봤자 독자가 표지 예쁜 책을 고르는 건 아니었다. 카피 하나로 몇날 며칠을 씨름해도 누구에게도 눈에 띄지 않고 먼지 쌓인 책장 장식품이 되는 일도 비일비재했다. 원칙이 없으면 이 지난하고 정답 없는 길을 굳이 돌아서 가야 한다는 걸 늦게 깨달았을지도 모르겠다. 그때서야 중점으로 둔 키워드가 ‘독자’였다.
개발자 ver → 프로덕트 중심주의
편집자 ver → 독자 중심주의
프로덕트 하나를 만들기 위해 UX 디자이너는 데이터를 와장창 수집하고 끊임없이 분석한다. 시장 분석, 경쟁사 분석, 사용자 분석, 기능 분석 등등. 이 과정이 필요한 이유는 ‘내가 보기엔 좋아 보이는데?’를 피하기 위해서다. UX 도서에 반드시 등장하는 문장이 있다면 “디자이너는 사용자가 아니다.”이다. 마찬가지다. “담당자는 독자가 아니다.”
물론 기능적인 부분에서는 담당자가 전문가여야 한다. 문장은 어느 정도로 짧아야 하고, 카피는 어떻게 써야 내용 전달이 명확하고, 목차는 어떻게 구성해야 하고… 하지만 책의 전개 방향을 기획하는 데 있어서는 현장을 아는 저자, 예비 독자의 의견을 귀담아듣는 것이 좋다. 실제로 분야에 따라 담당자가 저자만큼 전문가일 수도 있다. 하지만 ‘내가 더 잘 안다’라고 생각하는 순간 저자와 독자의 의견은 들리지 않아 오만해지고, 교만해지고 원고를 오래 잡다 보면 야근과 야식을 반복해 비만해진다. 고집과 아집은 복부를 오동통하게 만들고 마는 것이다.
아 되면 되는 거 아니냐고개발자 ver → 쓸모 있는 소프트웨어를 만들자
편집자 ver → 쓸모 있는 글을 만들자.
‘쓸모 있다’를 정의하는 내 기준은 ‘불필요한 게 없다’이다. 앞서 ‘독자 중심’을 제대로 두었다면 필요한 게 무엇이고 불필요한 게 무엇인지 아주 조금 명확해진다. 개발자에게 클린 코드가 필요하듯이 출판 기획 편집자에게도 클린 컨텍스트가 필요하다. 클린 컨텍스트는 오롯이 기획이 중심에 있다. 기획이 독자 중심으로 잘 이루어졌다는 전제에. 불필요한 내용을 덜고 덜어야 한다.
9명의 테크 리더 중 김정 대표의 ‘나의 메이저 버전을 업그레이드하는 마이너 원칙들’을 소프트웨어 배포 과정처럼 정리해 둔 게 무척 인상깊다.
v0.1.0 두리번거리면서도 속력과 방향을 자주 확인하기
v0.2.0 낯선 방식으로 해결하기
v0.3.0 개구리를 해부하지 말고 직접 만들기
vo.4.0 남을 향한 자존심을 버리고 나를 향한 자존감 채우기
v0.5.0 결과를 향하면서 과정을 기록하기
v0.6.0 의도한 실수를 반복하면서 작은 부분을 개선하기
v0.7.0 기준을 정하기 전에 여러 답을 찾아서 공유하기
v1.0.0 배포하기 그리고 다음 버전 준비하기
하드 스킬뿐만 아니라 소프트 스킬까지 배포 과정에 포함되어 있다. 특히 남이 한 v0.5.0으로 먹고살면서 스스로는 이 프로세스를 늘 빼먹는다는 게 내심 찔렸다. 그래서 미루지 않고 이 리뷰를 쓰는 중이다. 쓰는 게 귀찮아 다음엔 네이버 클로바라는 문명의 이기를 활용해볼까 싶다.
이들이 읽었던 인생 책을 실은 것도 인상깊었다. 한 사람의 글을 읽으면서 이 사람을 닮아 가고 싶다고 느낄 때쯔음 “그럼 이 책을 사”라고 디미는데 얼결에 거부감도 없이 사버리게 된다. 그렇게 투자인 척 시발비용을 써버렸다.
다음 리뷰는 최대한 빠른 시일 내에 이 두 권의 책 중 한 권이 되길 바라며 <개발자 원칙>을 현직 개발자뿐만 아니라 개발에 관련해 발가락이라도 담그고 있다면 가벼운 마음으로 펼치시길 권해드린다.
누가 물어보면 이해하기 쉽게 설명할 수 있어야 진정으로 아는 겁니다.
그렇지 못하다면 알고 있다고 착각했던 겁니다.
(...)
알고 있고 익숙한 것을 확인하는 가장 좋은 방법은
배경지식이 없는 사람에게 새로운 개념을 설명하는 겁니다.
그리고 알면서도 안 하려고 흐린 눈으로 기록하는 걸 무시해왔던 나에게도, 배워서 남주는 게 남는다는 걸 다시 한번 깨우쳐 준 이 책에 별 5개를 헌정드린다.
잘 봤습니다~ ^^7
