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

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

 

6장 : 학습 과정의 구성

더 깊이 파고들어라

 

 

상황

 당신은 빠듯한 마감 기한과 수많은 도구가 사용되는 복잡한 소프트웨어 프로젝트의 세계에 살고 있다. 당신의 고용주들은 모든 역할마다 전문가를 넉넉히 고용하는 사치를 누릴 여유가 없다. 당신은 각종 도구들을 겨우 지금 하는 작업을 완료하는 데 필요한 정도로만 배우고 있다. 우선 오늘의 작업에 사용할 언어나 라이브러리에 관련된 튜토리얼을 한 움큼 고른다. 그리고 시간을 들여 거기에 내재된 이슈를 이해하지도 않은 채 이런 결정을 내리고, 튜토리얼에 함께 제공된 장난감 예제를 그냥 복사해다 써 버린다. 이런 방식은 당신이 여러 분야로 손을 뻗칠 수 있는 한도까지는 먹혀들 것이다. 당신은 새로운 기술 분야에 뛰어들어서 아주 빨리 해결책을 찾아내는 능력을 지녔다. 당신은 자기가 맡은 부분이 동작하는 데 필요한 것만 공부하려, 그 나머지는 팀의 다른 멤버들에게 의존하고 있다. 예를 들면 당신은 서버 쪽 자바 개발자인데, 사용자 인터페이스가 어떻게 구성되는지는 거의 또는 완전히 모르고 있다. 

문제

 당신은 자기 코드를 유지보수하면서도 계속 난관에 봉착하는데, 당신이 공부했던 튜토리얼들이 실은 필요한 절차도 대충 건너뛰었으며 복잡한 이슈를 단순화했었다는 사실이 드러났기 때문이다. 수많은 도구들에 대한 피상적인 지식만 있다면, 미묘한 버그가 발생하거나 깊은 지식이 필요한 일을 할 때 늘 어쩔 줄 몰라 허둥대야 한다는 것을 알게 되었다. 기존 웹 서비스를 확장한 몇 주 정도의 경력을, 상호 운용적이며 고도의 확장성을 갖춘 대규모 시스템 유지보수 중에 나온 이슈에 대해 깊이 있게 아는 것과 구분하지 않았기 때문에, 사람들은 종종 당신의 이력서에 오해의 소지가 있다고 비난한다. 더 나쁜 상황은, 당신의 지식이 너무나 피상적이라서, 어떤 계기나 누군가 때문에 시험에 들기 전까지는 자기가 아는 바가 얼마나 없는지 자각조차 못하는 것이다. 

해결책

 도구나 기술분야, 각종 기법 같은 것을 깊이 파고드는 법을 배워라. 왜 그런 식으로 되어 있는지 알게 될 때까지 지식의 깊이를 더해가라. 여기서 깊이라 함은 세부적인 설계보다는 그런 설계에 이르게 한 요인을 이해하는 것을 의미한다. 예를 들어 타입 이론에 대해서는 다른 사람들이 이야기하는 얘기를 뜻도 모르고 흉내내기보다 이해하려고 노력하는 일처럼 말이다. 
 어떤 분야에 깊이 있는 지식을 가졌다는 사실은 당신에게 자신감을 주며, 바닥을 쓸어라 패턴의 적용 방식을 결정할 때 안내자 역할을 한다. 이것은 새로운 팀에 들어갔을 때 어떤 역할을 맡아야 빠른 시일 안으로 팀에 도움이 될 수 있을지 보여주기 때문이다. 더 중요한 것은, 이런 지식의 깊이가 새로운 분야에 도전할 때 기댈 언덕이 되어주며 앞으로 나아갈 힘을 부여한다는 것이다. 
 어떤 기술 분야를 깊이 파고들 때 얻을 수 있는 또 다른 이점은, 당신이 작업하고 있는 시스템의 물 밑에서 무슨 일이 일어나고 있는지 설명할 수 있게 된다는 것이다. 이런 깊이 있는 지식은 채용 면접 때 자기가 만든 소프트웨어도 의미 있게 설명하지 못하는 다른 지원자들 사이에서 당신을 돋보이게 해 줄 것이다. 그들은 전체 중의 작은 일부분만을 이해하고 있기 때문이다. 일단 팀의 일원이 된 이후에, 내키는 대로 돌무더기를 쌓는 사람들과 대성당을 짓는 사람들을 구분하는 것은 이 패턴을 실천했는지 여부다. 어떻게 이를 구분할까? 대성당을 짓는 사람은 바로 팀에서 디버깅하고, 역컴파일 하고, 리버스 엔지니어링을 하는 사람들이며, 당신이 사용하는 기술 분야에 대한 명세서, RFC 같은 것을 읽는 사람들이다. 이런 사람들은 자기 관점에 변화를 경험했으며, 사용하는 도구에 대해 숙련되게 이해하고 있다. 
튜토리얼을 읽을 때는, 복사해서 갖다 쓸 코드를 찾지 말고 새로 습득한 지식을 마음속 어디에 두면 좋을지 찾도록 하라. 당신의 목표는 그 개념의 역사적인 맥락이 어떤 것인지, 그것이 다른 무언가의 특별한 경우에 해당하는지 이해하는 것이 되어야 한다. 당신이 학습 중인 주제의 이면에 혹시 어떤 전산학적 개념이 깔려 있을지, 그리고 그 개념과 당신이 사용 중인 구현본 사이에는 어떤 절충이 이루어졌는지 알아보라. 이처럼 심도 있는 지식으로 무장하고 나면, 나중에 문제에 맞닥뜨렸을 때 처음의 튜토리얼 수준은 넘어설 수 있을 것이다. 

우리네 이야기.

 맞다. 정곡을 찔렸다. 라이브러리나 모듈을 사용할 때에는 공식문서와 블로그, 그리고 유튜브 영상을 통해 사용법을 익힌다. 그리고 빠르게 프로젝트에 적용한다. 보다 깊이 있는 공부를 해야 함을 알고 있지만 그러지 못한다. 왜 그럴까? 책에 나왔듯 시간적인 여유의 문제도 있겠다만 마음의 문제인듯하다. 그래서 요즘에는 글로 기술의 장단점을, 제작자가 의도한 개념을 정리한다. 물리적인 프로세스를 두어 조급한 마음을 잠시나마 묶어둔다. 그럼에도 공식문서를 꼼꼼하게 읽기란 어려운 일이다. 이럴 때에 종종 깃헙 이슈 탭의 글을 읽어보곤 한다. 글쓴이와 라이브러리 제작자 간의 소통을 따라가다 보면 제작자의 관점을 엿볼 수 있고 양방향 소통을 하기에 단방향 소통인 공식문서보다 재미있다.

 

익숙한 도구들

 

 

상황

모든 프로젝트가 새로 배워야 할 것들로 가득하다. 새로운 팀 멤버들, 새로운 팀 내 역할, 새로운 사업 분야, 새로운 기법, 그리고 새로운 기술 분야.

문제

이런 흐름의 가운데서 그 무언가는 예전처럼 남아 있어야 한다. 그게 아니라면 당신도 공부하느라 바쁠지 모른다. 어떻게 고객에게 뭔가를 보장해줄 수 있는가? 어떤 기능을 제거하려면 얼마만큼의 시간이 걸릴 거라고 얘기할 때, 고객이 그 말에서 확신을 얻으려면 무슨 근거가 있어야 할 것이다.

해결책

익숙한 도구들을 선별해서 거기에 집중하라. 이상적인 경우라면 이런 도구들을 쓸 때 당신은 더 이상 문서를 볼 필요도 없다. 모든 모범 사례와 우연히 발견한 팁들, FAQ 같은 것을 머릿속에 담아 두고 있는지 블로그나 위키 등 배운 것을 기록할 장소로 선택한 곳에 써놓았을 것이다. 이런 지식으로 무장했을 때에, 이전에 없었거나 아직까지 검토되지 않은 부분으로 리스크를 한정시키면서 업무에 대해 믿을만한 추정치를 제시할 수 있게 된다. 
이런 도구들이 익숙하다고 해서 항상 다른 사람들에게까지 추천해야 하는 것은 아니다. 때로는 일을 하기에 가장 알맞은 도구와 당신에게 가장 익숙한 도구가 다를 수도 있다. 그럴 때는 당신 개인의 생산성이 팀 전체의 생산성보다 중요한지 결정해야 한다. 이 도구들을 써서 어떤 문제를 해결할 수 있는지, 그리고 또 그것 때문에 무슨 다른 문제가 생기는지 잘 알고 있다. 그 결과로 당신은 이 도구들을 어디에 쓰지 말아야 하는지도 알게 되었다.
정말 어려운 일은 도구 상자의 많은 부분을 버려야 할 때 생긴다. 가끔 당신의 도구들은 구식이 되어 버리기도 하고, 더 좋은 대체품이 나타나기도 할 것이다. 드물게는 당신이 '최첨단'에 대해 정통한 결과, 전에 알던 도구를 소용없게 만들어 버리는 무언가를 발명할 수도 있다. 
친숙한 도구를 가지고 있지만 시대에 맞춰서 떠나보내고 새로운 것을 습득하는 것이 필요하다. 장담하건데 당신이 견습생때 쓰던 도구들은 숙련공이 되고 나서는 더 이상 소용이 없다. 때가 되면 당신이 즐겨 쓰는 도구들은 모두 폐물이 될 것이다. 당신의 경력이 성공적이려면, 익숙한 도구들을 쉽게 얻고 쉽게 버리는 법을 배워야 한다. 이런 목표를 이루기 위해 무엇을 배워야 할지 정하는 것은 숙련공으로 이행하는 동안 모든 견습생이 마주쳐야 하는 도전 중 하나다. 
당신에게 익숙한 도구의 목록을 적어보라. 그 항목이 다섯 개가 안 된다면, 도구 상자의 빈 곳을 메워줄 도구들을 찾아보라. 그 도구들은 이미 쓰고 있었지만 충분히 잘 알지 못하는 도구일 수도 있고, 다른 새로운 도구가 될 수도 있다. 어느 경우든, 그 도구를 학습할 계획을 세우고 오늘부터 실천하라. 이미 많은 도구를 가진다면 이를 신중하게 조사해보라. 더 나은 도구가 있거나 구식 도구를 들고 있다면 즉시 그 도구를 교체하라. 

나의 도구 상자

SRE 직군으로서 어떤 도구를 상자에 담아야 할까? 인프라 운영 능력? 모니터링 시스템? 원하는 서비스를 만들 수 있는 백엔드와 프론트엔드 기술? 다 담고 싶지만 폭이 넓다. 우선 지금 업무에 필요한 도구를 담고 A부터 Z까지 익혀보자. 그러고 나면 그다음 도구들로 쉽게 확장할 수 있지 않을까?