프로그래머의 길, 멘토에게 묻다 는 사회초년생 때 구매했던 책인데, "초보 프로그래머" 를 아직도 탈출하지 못했다는 자괴감이 들 때마다 종종 다시 펼쳐보곤 한다. 좋은 멘토에 대한 갈증이 있다면, 그리고 개발자 경력의 초반을 설계하는 데 고민이 든다면 한 번쯤 읽어보기를 추천한다. 이번에는 이 책을 읽고 생각나는 구절들을 몇 가지 소개해보고자 한다.
무지를 드러내라
2장 잔을 비우다 中
소프트웨어 장인은 고객이나 동료와 맺은 튼튼한 관계를 통해서 평판을 쌓아간다. 무언의 압력에 굴복해서 사람들이 듣고 싶어 하는 얘기를 해주는 것은 튼튼한 관계를 쌓는 데 좋은 방법이 아니다. 사람들에게 진실을 말하라. 그들이 무엇을 원하는지 이제 당신이 이해하기 시작했고, 그것을 해낼 방법을 배워 가는 중이라고 알려주어라. 아는 척 하기보다는 당신이 얼마나 잘 배울 수 있는지를 가지고 안심시켜라.
...
무지를 드러내는 가장 확실한 방법은 질문하는 것이다. 이것은 말처럼 쉽지 않은데, 특히 질문 받는 쪽에서 당신이라면 당연히 알 거라고 생각하는 경우에는 더욱 그렇다. 물론 당신은 자존심에 상처 입지 않고 어느 정도 우회해서 필요한 지식을 얻을 수도 있다. 하지만 가장 가깝게 질러가는 길을 택함으로써 숙련공으로 가는 여정이 단축될 수 있다.
이 부분은 갓 취업에 성공한 신입사원 시절에는 크게 공감하지 못했던 것 같다. 내가 그 어떤 것도 안다고 생각하지 않았기 때문에 오히려 질문하기 쉬웠으며, 사수들도 먼저 다가와서 알려주고 싶은 지식들을 거리낌없이 나눠주셨던 기억이 있다. 당시 팀에서 사용했던 Angular, RxJS, 그리고 웹 개발 생태계에 대해 적응할 기간을 넉넉하게 주셨고, 실무에 적응함과 동시에 기술을 익힐 시간이 주어졌다. 그러나 개발 경력 만 3년차가 넘은 지금, 쉽사리 내가 사실 이렇게 기본적인 것도 모른다는 것을 드러내기란 쉽지 않아진 것 같다. 일례로, 나는 아직도 백엔드 어플리케이션을 개발하고 데이터베이스를 제대로 다뤄본 적이 없다. HTTPS를 직접 설정해본 적도 없다. OSI 7계층을 설명하는 데 아직도 애를 먹는다. DFS, BFS, DP 등 기본적인 알고리즘들을 구현해보라고 하면 식은 땀부터 난다. 단순 CS 지식에서 벗어나더라도, 프론트엔드 진영에는 수많은 메이저 기술들이 있으며, 팀마다 사용하는 스타일들도 제각각이다. 따라서 실무를 할 때도 모르는 것들이 수두룩하게 나오곤 한다. 단순 React 생태계만 들여다보아도 상당한 양의 기술들이 존재한다. 남들은 다 알고 있는 기술들인 것 같고, 나만 뒤쳐지고 있다는 생각이 안 들 수가 없다.
이 책에서는 무지를 드러내는 것이 학습의 속도를 높이고 고객의 신뢰를 얻는 가장 빠른 길이라고 소개한다. 연차가 올라갈 수록 쉽지 않아질 터이니, 지금이라도 빨리 실수를 하고 무지를 통해 학습하는 습관을 기를 것을 강조한다. 체면과 자존심을 세워서 얻는 것이 생각보다 많지 않다는 것을 배워가는 요즘 더 다가오는 구절이었다.
예술보다는 기예
3장 긴 여정을 걷다 中
한 사람의 장인으로서, 예술적 표현에 탐닉하기보다는 다른 이들의 필요를 충족시키는 무언가를 만드는 것이 먼저다. 자신의 기술로 생계를 꾸려야 할 장인에게 굶주림이란 실패다. 자기 솜씨를 뽐내거나 이력서에 한 줄 추가하려 하기보다는 고객의 관심을 우선해서 최선을 다해야 할 것이고, 그러면서도 소프트웨어 개발 공동체에서 통하는 최소한의 기준은 지켜야 할 것이다. 긴 여정을 걸어간다는 것은 이렇게 상충하는 두 조건을 잘 조화시켜야 함을 의미한다.
...
아름다운 작품을 만들고자 하는 열망이 너무 큰 나머지 프로페셔널한 소프트웨어 개발에서 멀어지고 현실의 사람들에게 유용한 무언가를 만들지 못하게 된다면, 당신은 장인의 길에서 벗어난 것이다.
소프트웨어 개발은 예술보다는 공예에 가깝다고 한다. 이것을 사회초년생 때는 이해하기 힘들었다. 빅테크 기업들의 채용공고에 들어가 있는 역량들과, 실제 실무에서 맞닥뜨리는 경험들이 너무 상이했던 것이다. 일례로 좋은 회사의 채용 공고나 기술 컨퍼런스 발표에는 테스트코드 작성 및 자동화 경험, 레거시 기술 스택 전환 경험, 성능 측정 및 최적화, 오픈소스 기여 경험과 같은 것들이 자주 등장한다. 단순히 "배너 기능을 고도화해서 매출을 3배 개선했어요" 라는 것은 다소 시시한 일로 치부되고, 대신 "기술스택을 최신의 것으로 성공적으로 마이그레이션했어요" 라는 것은 아름다운 어플리케이션을 만들어 본 대단한 경험으로 보여지는 것이다. 따라서 사회초년생 땐 소프트웨어 장인정신이란 이런 것이라고 오해를 하곤 했었다. 개발자라는 것은 회사를 먹여살리는 사람이라기보다는 아름답고 완성도 높은 어떤 고상한 것을 추구하는 사람이라는 오해였다.
그런데 이것에 맞춰 커리어를 개발하려고 보면, 실무와 조금 동떨어진 생각을 하게 되곤 한다. 우리 회사의 레거시 코드는 테스트코드를 작성하기에는 관심사분리가 되어 있지 않은데, 기능 개발보다는 리팩토링을 먼저 해야 하는 것이 아닐까? 레거시 코드의 기술 스택은 요즘 유행하는 스택과 거리가 있는데, 조금 무리해서라도 인기 있는 기술로 마이그레이션할 필요가 있지 않을까? 이번 프로젝트의 요구사항은 그저 배너에 들어가는 스펙 하나를 바꾸는 것 뿐이지만, 전체적인 배너 화면의 초기 로딩 속도를 대폭 개선하면 이력서에 한 줄 더 추가할 수 있지 않을까? 레거시한 시스템을 보기가 힘든데, 모든 걸 멈추고 시스템을 다시 설계해야 하지 않을까? 등의 것들이다.
이런 오해들은 최근 스타트업 불황기를 겪으면서, 그리고 두 번째 회사로 이직하면서 상당히 많이 풀렸다. 예술을 추구하는 것은 좋지만, 그보다 중요한 것은 사람들에게 유용한 무언가를 만들어내는 부분이라는 것이다. 제품과 기술을 개선한다는 것도 결국, 이것이 되면 우리 회사와 서비스에 어떤 임팩트가 있을까를 고민하기 위한 과정이어야 할 것이다. 본인이 재직했던 두 번째 회사는 개발자 수도 적고 서비스를 기술적으로 고도화하는 것이 다소 중요하지 않은 회사였지만, 스타트업 혹한기 때 흑자를 내고 역대 최고 연매출을 찍는 스타트업이었다. 반면 스타트업 호황기 때 소프트웨어 개발에 무조건적인 투자를 했던 기업들이 이제는 구조조정을 하는 모습들을 종종 목격하게 된다. 개발팀 규모를 키우고 투자했던 것만이 구조조정의 이유는 아니겠지만, 회사의 이윤 추구라는 가치를 창출하는 것이 중요해지고 있는 지금, 개발은 "예술보다는 기예"라는 이 책의 구절이 더 실감나게 다가온다. 긴 여정을 걸어가기 위해서는 상충되는 여러 가치를 적절한 수준으로 유지하는 것이 중요한 까닭이겠다.
부숴도 괜찮은 장난감
5장 끊임없는 학습 中
당신은 실패가 용납되지 않는 환경에서 일하고 있다. 하지만 실패는 종종 무언가를 배울 수 있는 가장 좋은 방법이 된다. 오직 과감한 일을 하고, 실패하고, 그 실패로부터 학습하고 또 다시 시도하는 것. 우리는 그렇게 해야만 어려운 문제에 맞닥뜨렸을 때 성공해 내는 사람으로 성장할 수 있다.
...
애디는 학습에 도움을 얻고자 부숴도 괜찮은 장난감 패턴을 사용했다. 이 패턴을 사용해서 만들 시스템은, 견습생의 생활과 관련이 있으면서 실제로 쓸모도 있어야 한다. 예를 들면 당신만의 위키나 캘린더, 주소록. 또는 간단한 틱택토 게임을 만드는 것이다. 당신의 프로그램은 아마 해결해야 하는 문제에 비해 과하게 만들어졌을 것이며, 기존 프로그램으로 쉽사리 대체될 수 있을 것이다. 하지만 이런 프로젝트들이야말로 실패가 용인되는 장소다. 여기서 당신은 새로운 아이디어와 기법을 시험해볼 수 있으며, 그 결과가 참담한 실패로 끝날 수도 있다. 하지만 그 실패로 상처 입을 사람이라고는 당신 자신뿐이다.
돈을 받고 일하는 프로 개발자라면 기술적 호기심을 무턱대고 회사의 소스코드에 적용해본다던지 하는 무모한 짓은 하지 않을 것이다. 실패가 용납되지 않는 대표적인 환경이 회사기 때문이다. 하지만 실패를 통해 성장하고자 한다면, 이 책에서 제시하는 "부숴도 괜찮은 장난감"을 스스로 만들어보는 편이 많은 도움이 될 것이다. 자신의 업무에 도움이 될 만한 기술들로 마음껏 오버엔지니어링할 수 있는 프로젝트를 해보는 것이다. 프로젝트의 결과물은 언제든 부술 수 있기 때문에, 과감하게 새로운 기술을 도입해볼 수도 있고 회사에서는 해보지 못한 대규모 리팩터링도 해볼 수 있다. 본인은 이 패턴을 이용해 회사에 도입해보고 싶은 기술들을 사이드프로젝트에 적용하면서 공부했던 경험이 있다. 큰 프로젝트에 들어가기 전 개인적으로 소규모 해커톤에 참여하게 되었는데, 이때 평소에 관심있던 Tanstack Query, shadcn/ui와 같은 기술 스택들을 전부 적용해서 만들어보게 된 것이다. 이 과정에서 깨지면서 학습한 결과 나름 제한된 시간 안에 밀도있는 사용경험을 확보할 수 있었고, 신규 프로젝트에서 좀더 자신있게 기술 도입에 대한 이야기를 꺼낼 수 있게 되었다. 물론 이 장난감들은 본래 의도대로 재미있어야 하고, 우연히 사용자들이 생겨서 유지보수에 대한 책임감이 생긴다면, 부숴도 괜찮은 새 장난감을 찾아나서야 한다고 볼 수도 있다.
저자는 추천하는 장난감으로 개인 위키 프로그램을 추천한다. 기본적으로 텍스트 파일을 볼 수 있는 기능이 들어가야 할 것이고, 시간이 지나면서 HTTP와 파싱, 캐싱, 검색, 데이터베이스, 동시성 등을 배우게 될 것이다. 만약 검색엔진에 관심이 있다면 위키에 랭킹 알고리즘이나 태깅과 관련된 실험을 해볼 수 있겠다. 기술적인 호기심이 생기는 어떤 주제든 유연하게 적용해보고, 맘에 안 들면 부술 수도 있다. 시중에 이미 충분히 검증된 좋은 프로그램들이 많기 때문이다. 공감되는 부분이라 본인도 신년에는 부숴도 되는 장난감으로 블로그를 직접 구축해보고자 한다. 가장 기본적인 기능부터 댓글, 좋아요, 태그, 텍스트 편집기까지 확장할 수 있는 기능들이 무궁무진하다. 만약 만들었는데 퀄리티가 아쉽다면 그냥 기존에 잘 쓰던 티스토리를 그대로 유지하면 될 것이다.
이 책을 재미있게 읽는 방법
이런 자기계발서 류의 책은 사실 처음부터 끝까지 한번에 완독한다면 의외로 기억에 남는 것이 얼마 없을 수도 있다. 저자 역시 이 책은 본래 위키로 쓰인 글이기에, 순서대로 읽힐 것이라고 생각하지 않았다고 한다. 앞에 나오는 패턴들이 뒤의 패턴들을 참조하고 있기도 하고, 뒤쪽의 패턴 역시 마찬가지다. 따라서 웹사이트를 서핑하듯이 좀더 능동적으로 읽을 때 진도가 술술 나갈 것이다. 본인은 목차를 보고, 지금의 상황에서 가장 재미있을 만한 토픽/장을 정해서 읽기 시작하는 편이다. 이 책에서는 마치 웹사이트들이 앵커 태그를 통해 링크로 연결되어 있듯이, 앞 또는 뒤편에 나올 내용들을 저자가 제시해주는 대로 연결지어 보는 편이 권장된다. 따라서 핸드북을 보듯이, 관심 있는 주제를 골라 능동적으로 읽을 때 좀더 집중력있게 읽혔다. 만약 일정 경력 이상의 중급 개발자라면, 저자는 소프트웨어 장인 을 함께 읽어보는 것도 권장하고 있다.
Reference
데이브 후버 ・ 애디웨일 오시나이, ⌜프로그래머의 길, 멘토에게 묻다⌟, O'RELLY, 2010
'Book' 카테고리의 다른 글
| [HTTP 완벽 가이드] 7장 캐시 (1) | 2022.07.24 |
|---|
