[프로그래머의 길, 멘토에게 묻다] - 11

앞으로의 포스팅은 책에서 소개하는 패턴 언어 중 마음에 드는 구절을 소개하는 방식이 될 것이다.

 

부숴도 괜찮은 장난감

 

 

상황

경험이란 성공할 때만큼은 아니겠지만 실패로부터도 쌓인다.

문제

당신은 실패가 용납되지 않는 환경에서 일하고 있다. 하지만 실패는 종종 무언가를 배울 수 있는 가장 좋은 방법이 된다. 오직 과감한 일을 하고, 실패하고, 그 실패로부터 학습하고, 또다시 시도하는 것, 우리는 그렇게 해야만 어려운 문제에 맞닥뜨렸을 때 성공해 내는 사람으로 성장할 수 있다.

해결책

업무 때에 비슷한 도구를 사용하되 업무 때 구축하는 시스템 범위에는 들지 않는 토이 시스템을 설계하고 구현하여 실패해 볼 수 있는 여지를 만들어라. 만약에 경험이란 것이 성공뿐 아니라 실패로부터도 얻어진다고 하면, 당신에게는 실패해 볼 수 있는 다소 개인적인 공간도 필요하다. 공 세 개로 저글링 할 줄 아는 사람이 다섯 개짜리 저글링을 전혀 시도하지 않으면 그는 결코 한 단계 더 올라서지 못할 것이다. 연습을 하면 힘들지만 이룰 것이다. 소프트웨어도 이와 마찬가지다. 하지만 저글러가 다섯 개짜리를 공연에서 시도하지 않듯 개발자도 마음 놓고 실수할 수 있는 안전한 장소가 필요하다.
견습생이 만들 장난감은 생활과 관련이 있어야 하고 실제로 쓸모도 있어야 한다. 예를 들면 나만의 위키, 캘린더, 주소록 같은 것이다. 기존 프로그램으로도 대체될 수 있겠지만 이런 프로젝트들이야 말로 실패가 용인되는 장소다. 당신의 새로운 아이디어를 실험해볼 수 있으며, 그 결과가 실패일 수 있다. 하지만 상처 입을 사람은 당신뿐이다. 이런 장난감들을 만들 때마다 새로운 것을 배울 수 있다. 그리고 자신이 실제로 사용하기에 더 깊게 이해할 기회가 된다. 
당신의 장난감이다. 회사가 바뀌어도 가져갈 수 있다. 또한 장난감이기에 재미있어야 한다. 처음 열정 후에도 재미있게 지속해야 한다. 이 패턴은 가장 뒤떨어진 이가 돼라와 비슷한 면이 있지만 가장 뒤떨어진 이가 되라 패턴은 당신이 성장할 수 있는 팀을 찾는 일을 설명한 패턴이었다. 부숴도 괜찮은 장난감은 당신의 한계를 넘은 곳에 발을 디디고 혼자 힘으로 완전한 소프트웨어 프로젝트를 하나 구축해볼 기회를 의도적으로 만드는 데 더 중점을 두었다고 할 수 있다. 이 패턴은 또한 흰 띠를 매라와 무지에 맞서라 패턴과 관련되기는 하지만, 이미 습득한 지식을 한쪽으로 밀쳐두는 것과는 다소 거리가 있다.

사이드 프로젝트

프로젝트는 재미있다. 혼자서 할 수도 있지만 마음에 맞는 친구들과 진행하기를 좋아한다. 프로젝트를 진행하며 목적성이 생기기 마련이다. 예를 들자면 학습, 출시, 수익. 친구들과 함께 진행할 경우에는 목표에 대한 생각을 맞춰야 할 필요성이 있다. 혼자 진행한다면 어떨까? 정말 하고 싶은 일을 해볼 수 있을 것이다. 다만 봐주는 사람이 없기에 동기부여를 잘해야 할 필요성이 있다. 책에서와 같이 업무와 연관된 기술을 사이드 프로젝트에 적용해본다면 실력 상승이 곧 업무의 질을 높이는 일이 될 테니 즐겁지 않을까?
우테코를 진행하며 통학시간을 아끼기 위해 방이동에 위치한 비버 하우스라는 곳에 머물렀다. 처음에는 혼자 살던 것이 터틀도 오고 유안도 와서 셋이 같이 지냈을 때가 잠시 있었다. 개발자 셋이 모이면 프로젝트를 한다는 말이 있던가? (몹시) 가벼운 프로젝트를 진행했고 덕분에 리액트를 다루는 실력이 늘었던 경험이 있다. 배운 것을 부담 없이 적용해볼 공간이 필요하다가 핵심이다.

---

 

소스를 활용하라

 

 

상황

오픈소스의 세계에 처음 입문한 사람들은 종종 자기가 올린 질문에 "소스를 써라 루크"라는 답변이 돌아오는 경험을 한다. 이는 소프트웨어에 대한 기본적인 진실을 말해 준다. 결국 코드가 최종 결정자라는 것이다. 프로그래머의 의도란 코드가 그 의도를 제대로 반영하지 못한다면 공허한 것이 되어 버린다. 시스템을 진정으로 이해한다는 것은 오로지 코드를 읽어 보아야만 가능하다. 

문제

공부하고 모방할 좋은 사례가 없다면, "연습 연습 또 연습" 패턴은 스스로 자각하지 못하는 나쁜 습관을 더욱 굳히는 결과만 가져올 것이다. 다른 사람의 신발을 신고 걸어보지 않는다면, 당신은 모든 신발 속에는 돌멩이가 들어 있는 거라 믿게 될 수도 있다. 그렇다면 주변에 좋은 코드와 나쁜 코드를 구별할 만한 사람이 없는 환경에서, 당신이 짜 놓은 코드가 제대로 짠 것인지를 어떻게 알 수 있을까?

해결책

다른 사람들의 코드를 찾아서 읽어라. 당신이 매일 사용하는 도구나 애플리케이션부터 시작해보라. 견습생으로서 당신을 주저하게 만드는 것 중 하나는, 당신이 의존하는 도구들을 만든 사람들은 왠지 당신과 다를 것 같고 더 특출 날 거라고 믿는 일이다. 그 사람들의 코드를 읽고서 당신은 그들처럼 프로그래밍하는 방법을 배우게 되었고, 더 중요하게는 당신을 둘러싼 인프라를 만들어 낸 사고 과정이 어떤 것이었는지 이해하게 된다. 오픈소스 프로젝트를 들여다볼 때는 가장 최신 버전의 소스를 다운로드해서, 과거 이력을 조사하고 차후의 진행을 따라갈 수 있도록 하라. 소스들을 분석하고 그렇게 짠 이유를 파악하라. 그 이유를 파악하기 위해서는 짜인 코드를 리팩토링 하는 방법이 있을 수 있다. 이러면 프로젝트에 대한 이해가 높아질 뿐 아니라 자신이 그것을 구현할 수 있다는 사실도 확인된다. 그리고 더 나은 방법을 찾는다면 이 또한 프로젝트에 기여하는 좋은 방법인 것이다. 간혹 의구심이 드는 코드를 발견하면 개발한 사람의 의도를 다시 생각해보고 내가 모르는 게 있는지, 그들이 모르는 게 있는지를 생각해보라. 당신의 장난감에 구현해본 내용을 적용하는 게 가치 있을지 생각해보라.
코드 리뷰나 짝 프로그래밍을 통해 다른 사람의 코드를 읽고 내 코드를 읽게 하며 서로에게서 배우는 환경이 만들어진다. 이 같은 그룹은 유능한 프로그래머들을 배출하는 경향이 있다. 실제 개발자는 코드를 짜는 시간보다 읽는 시간이 더 많다. 그런데 학교는 처음부터 만드는 게 더 낫기에 이를 무시하고 만들기를 중요시하는 경향이 있다. 하지만 일과 시간 대부분을 차지할 읽기에 대한 능력을 기르는 것은 중요하다. 코드를 읽다 보면 관용적인 표현이나 의도를 꿰뚫어 보는 능력을 키울 수 있다. 이는 팀에서 더욱 중요한 일을 할 수 있도록 해줄 것이다. 왜냐하면 기존 코드가 무슨 일을 하는지 몰라서 새로 작성하지 않고 이미 작성한 코드를 가지고 작업할 수 있기 때문이다. 
소프트웨어 개발의 문제는 교사가 부족하다는 점인데 여러 사이트에서 오픈소스 프로젝트가 확산된 덕분에 잘하는 사람으로부터 배울 수 있는 기회가 늘어났다는 점이다. 또한 이런 오픈소스는 요구사항에 대응해가며 성장한다. 코드가 진화하는 방식을 공부해가며 당신은 실제 여러 프로젝트를 해보지 않아도 설계 단계에서 내리는 결정이 어떤 영향을 미치는지 더 잘 이해할 수 있게 된다. 즉 이는 가르침을 받지 않고서도 배우는 능력이다. 프로그래밍 능력을 테스트하는 가장 좋은 방법 중 하나는, 프로그래머에게 30페이지 정도의 코드를 건네주고서 그 사람이 얼마나 빨리 그 코드를 통독하고 이해하는지를 보는 것이다. 빌 게이츠의 말이다. 이는 코드에서 신속히 지식을 흡수할 수 있는 사람들은 머지않아 더 우수한 프로그래머가 된다는 의미기도 하다. 이때까지 태어난 모든 프로그래머가 작성한 코드 한 줄 한 줄이 모두 그의 스승이기 때문이다.

오픈소스에서 코드 읽기까지

오픈소스. 뭔가 갈망이 있다. 개발하는 친한 PK라는 친구는 여러 오픈소스에 기여하고 최근에는 ELM이라는 프로그래밍 언어의 한글 문서화에도 기여하고 있다. 이야기를 듣고 찾아봤을 때에 "재미있겠다"라는 생각이 들었다. 나가서 술 마시고 놀기만 좋아하다가 오픈소스에 기여하는 게 재미있을 것 같다는 생각을 하다니. 신기하다. 우테코 과정이 끝나면 도전해보고 싶다.
코드 읽기. 중요하다. 당장 주니어 개발자로 팀에 배정된다면 무수히 많은 기존 코드를 만나게 될 것이다. 도메인을 파악, 로직을 파악, 테스트를 파악. 이러다 보면 시간이 금방 가겠지. 정확하고 빠르게 코드 읽는 능력이 필요하다. 이를 위해서는 더 많이 보고 익혀야겠지. 그래서 오픈소스에 기여하라고 책이 이야기를 하나보다.