프로의 원칙 - 개발자 원칙

 

보통 많은 분들이 공저한 책에 많은 기대치를 걸지 않는 편입니다. 

 

커피에 비유해서 이유를 설명해보겠습니다. 제가 좋아하는 책의 유형은 에스프레소에 가까운 진하고 좀 씁쓸한 맛이 있더라도 그 향을 꽤 오랜 시간 음미할 수 있는 책을 좋아합니다.

 

이 정도의 책이 되려면 단독 저자라 해도 책의 구조부터 문장까지 잘 짜야 가능합니다. 그리고 책 후반부까지 일관성을 잃지 않고 꾸준히 임팩트를 내줘야 가능합니다.

 

하지만 많은 분들이 공저한 책에서는 구조적으로 이런 일관성과 깊이 두 가지를 만족시키지 못하는 경우가 많습니다. 각 저자에게 부여된 서술 분량과 저자의 사고방식이 다르니 당연합니다.

 

그렇지만 이 책은 각각의 저자가 색깔이 다르면서도 전체적으로 일관성과 깊이를 적절히 가져가고 있습니다. 자기계발서라 그럴 수도 있지만, 자기계발서 중에서도 공저 한 책들 보면 아쉬운 경우도 보이기도 합니다. '원칙'이라는 키워드를 토대로 일관성을 지키기 위해 노력해서 그런건지도 모르겠습니다.

 

무튼 이 책은 공저자인 책에서 가장 맞추기 어려운 과제를 수행해냈습니다.

 

이 책이 재미있는 점은 자기계발서임과 동시에 간간히 개발지식을 얻을 수 있다는 점입니다.

마치 김치전에서 통통한 살이 오른 오징어만 빼먹는 그런 느낌이랄까요?

 

예를 들어 다음과 같은 부분이 있습니다.

어떤 기능을 구현할 때, 보통 정확한 기능을 제공한다는 가정에서, 속도가 빠를수록 좋다고 생각합니다. 그래서 더 빠른 속도를 가진 구현이 더 좋다고 생각하는 경우가 대부분입니다. 그런데 이게 암호처럼 보안이 중요한 분야에서는 비교 속도가 균등하지 않으면 문제가 발생합니다. 예를 들어 abcdefg라는 문자열이 있다고 할 때, 사용자가 b로 시작하는 문자열을 입력하면, 첫 글자가 다르기 때문에 바로 실패라고 응답합니다. 그런데 이게 어느 정도 긴 문자열이고 반복을 많이 한다면, 실패로 응답하는 시간을 측정해서 암호를 추측할 수 있게 됩니다. 예를 들어 입력한 문자열이 abcdeff라면 첫 문자가 b일 때보다 abcdef까지 같은 문자열일 때 틀렸다는 응답이 더 늦을 겁니다. 이렇게 맞은 문자 개수마다 응답 시간이 다르면 입력한 값이 어디까지 같은지 유추할 수 있게 됩니다. 따라서 비교가 성공하든 실패하든, 같은 시간에 응답을 주는 방법으로 구현해야 타이밍 공격에 안전한 코드가 될 수 있습니다.

개발자 원칙 67~68p

전문적인 개발책에서는 이런 지식을 한도 끝도 없이 다루기 때문에 질리기 마련입니다. 하지만 이 책에서는 매번 등장하는 건 아니고 가끔씩 등장하기 때문에 흥미를 잃지 않고 볼 수 있는 장점이 있는 듯 합니다.

 

책을 읽으며 가져가려고 하는 원칙은 GPAM과 제어할 수 있는 일에 집중하기 였습니다.

 

최근에 진행했던 프로젝트에서 번아웃으로 완전히 넉다운 되었기 때문입니다. 이제 마무리 되었으니 좀 쉬면서 마음을 다잡아야하는데, 이 원칙을 실천해보면 도움을 받을 수 있겠다는 생각이 들었습니다. 

 

책에 대해서 칭찬을 많이 했지만, 아쉬운점이 없는 건 아닙니다. 특별한 오타는 없지만, 띄어쓰기나 조사어 등이 어색할 때가 보입니다. 사소하지만 이런 게 아주 가끔 책을 읽는데 방지턱처럼 걸리게 만드는 느낌을 주었습니다. 이 책도 베타리딩을 해서 이런 걸 좀 잡아줬다면 어땠을까 하는 아쉬움이 남습니다.

 

하지만 이 책에서 저자들이 강조했듯 기한 넘기는 100점짜리 프로덕트보다는 기한 내에 8~90점 프로덕트 내는게 좋다는 원칙으로 따져볼 때 이 정도라면 개발자 원칙에 충실하지 않았나 싶습니다. 

 

 

밑줄긋기

p.37

내적 동기를 개발하고 고양하는 데 관심이 있는 사람이라면 금전적인 보상처럼 외부에서 통제되는 체제에 집중해서는 안 된다.

 

- 에드워드 디씨

 

p.38

동기를 관리할 때 또 신경 써야 하는 것은 에너지입니다. 일하다보면 헌신적으로 일하던 분들이 번아웃으로 하고 싶은 일을 더 하지 못하고 이탈하는 안타까운 경우를 많이 봅니다. 스탠포드 대학 조나단 레바브 교수의 <이스라엘 가석방 심리 결과> 연구는 유명한데, 가석방 심사를 하는 판사가 충분히 휴식하거나 식사 후 배가 부를 때는 가석방 승인율이 높지만, 그렇지 않을 때는 급격하게 낮아지는 현상이 이 연구로 밝혀졌습니다. 공정해야 하는 판결이 이렇게 에너지에 따라서 전혀 다른 결과를 보이는 것처럼 사람은 에너지에 따라 다르게 판단하고 행동합니다. 따라서 동기를 관리하는 사람은 자신의 에너지도 관리하고 지나치게 에너지를 소진하지 않으려고 노력합니다. 동기는 단순히 있고 없고 하는 것이 아닌 크기가 있는 양입니다.

 

에너지 관리는 단순히 에너지를 소진하지 않으려고 걱정하며 조심하는 소극적인 방식이 아닌, 회복탄력성을 키우고 에너지 그릇을 키우는 적극적인 방식이 좋습니다.

 

p.40

지식근로자는 스스로 성과의 방향을 설정해야 하기 때문에, 자신에게 어떤 성과가 기대되고 있는지 그리고 자신에게 그러한 성과가 기대되고 있는 이유가 무엇인지를 이해하지 않으면 안 된다.

 

- 피터 드러커

 

p.44

"뛰어난 팀 없이 뛰어난 소프트웨어는 얻을 수 없다. 그리고 대부분의 소프트웨어 팀은 역기능가정 같이 움직인다."

 

존 맥카시

 

p.53

'오류'를 만나는 일은 개발자에게 즐겁지 않은 일입니다. 하지만 백엔드 엔지니어로서 저는 "백엔드 엔지니어의 실력은 얼마나 많은 오류와 장애를 만나고 이를 해결했는지 여부에 따라 갈린다"라고 말합니다. 2002년부터 개발을 시작하면서, 저는 항상 팀이나 회사에서 가장 많은 오류를 만드는 사람이었고, 경험하는 사람이었다고 생각합니다. 그리고 그런 장애가 저를 더 성장시켜주었다는 생각이 듭니다. 오류를 만날 때 좌절하지 않고 끝내 해결하고 어떻게 더 나은 개발자로 나아갈 수 있었는지 저만의 두 가지 원칙을 소개해보겠습니다.

 

첫 번째 원칙은 '오류가 발생하면 소스코드 레벨에서 이해하자'입니다. 

 

p.55

서비스를 운영하다보면 많은 툴을 사용하고, 많은 에러를 마주치게 됩니다. 이때 해당 오류를 스택오버플로에서 검색하면 대부분은 손쉽게 해결책을 얻을 수 있습니다. 하지만 단순히 여기서 끝내버리면, 실제로 깊은 지식을 얻기가 어렵습니다. 한 발 더 나아가서 해당 툴의 소스 코드를 확인하는 것으로 관련 에러가 왜 발생하는지 해결하려면 어떻게 해야 하는지 같은 깊은 지식을 얻을 수가 있습니다. 파생되거나 비슷한 문제를 예방할 수도 있게 됩니다. 이것이 바로 제가 소스 레벨에서 오류를 확인하라 주장하는 이유입니다.

 

두 번째 원칙은 알아낸 지식을 글로 공개하라는 겁니다. 소스 레벨에서 이해한 내용을 이해했다면, 결과물로 남기는 것이 중요합니다. 사람의 기억력을 믿을 수 없고, 때로는 제대로 이해했다고 생각하지만 제대로 이해하지 못했을 수도 있습니다. 그래서 저는 이해한 내용을 블로그에 정리하거나, 오픈 소스에 기여하여 결과물을 남깁니다. 블로그나 오픈 소스에 자신의 코드나 기술적인 내용을 공개하기가 꺼려지는 분이 있을 겁니다. 개발자로서 성장하는 데 좋은 정보를 뇌에 입력하는 것도 좋지만, 제대로 이해하고 있는지 확인받는 것도 중요합니다. 아예 모르는 것보다 잘못 아는 것이 더 위험합니다. 그러므로 가급적이면 결과물을 공개해 다른 사람들의 조언을 들을 기회로 삼아보시길 바랍니다.

 

p.65

트리 구조로 바뀐다면 어떤 문제가 발생할까요? 트리 구조는 리스트보다 검색은 더 빠르겠지만, 데이터의 추가/삭제는 훨씬 느립니다. 데이터 추가 시에 트리의 밸런스를 유지해야 하기 때문에, 데이터 추가 속도가 느리게 되는 겁니다. 그렇다면 데이터가 적을 때는 도리어 트리 구조를 유지하는 비용이 더 들어 성능이 더 느려지지 않을까요? 반면 선형 리스트는 새로운 데이터를 가장 앞에 저장하기 때문에 삽입이 빠르지만, 선형 리스트 안에서는 순차 탐색을 하므로 검색 속도가 느립니다. 

 

p.66

대부분의 블로그나 자료를 보면 자바 8 이후 HashMap은 트리를 사용한다고 되어 있습니다. 하지만 코드를 직접 확인한 결과 데이터가 8개 이하일 때는 선형 리스트를, 그 이상일 때는 트리를 사용하는 하이브리드 형태였습니다.

 

제대로 된 정보를 확인하는 최선의 방법은 소스 코드를 확인하는 겁니다. 그래야 기본 지식이 탄탄한 개발자로 성장할 수 있습니다. 누가 알겠습니까? 면접장에서 자바 8에서 변화된 HashMap의 구조를 설명하라는 질문을 받게 될런지요?

 

p.67-68

어떤 기능을 구현할 때, 보통 정확한 기능을 제공한다는 가정에서, 속도가 빠를수록 좋다고 생각합니다. 그래서 더 빠른 속도를 가진 구현이 더 좋다고 생각하는 경우가 대부분입니다. 그런데 이게 암호처럼 보안이 중요한 분야에서는 비교 속도가 균등하지 않으면 문제가 발생합니다. 예를 들어 abcdefg라는 문자열이 있다고 할 때, 사용자가 b로 시작하는 문자열을 입력하면, 첫 글자가 다르기 때문에 바로 실패라고 응답합니다. 그런데 이게 어느 정도 긴 문자열이고 반복을 많이 한다면, 실패로 응답하는 시간을 측정해서 암호를 추측할 수 있게 됩니다. 예를 들어 입력한 문자열이 abcdeff라면 첫 문자가 b일 때보다 abcdef까지 같은 문자열일 때 틀렸다는 응답이 더 늦을 겁니다. 이렇게 맞은 문자 개수마다 응답 시간이 다르면 입력한 값이 어디까지 같은지 유추할 수 있게 됩니다. 따라서 비교가 성공하든 실패하든, 같은 시간에 응답을 주는 방법으로 구현해야 타이밍 공격에 안전한 코드가 될 수 있습니다.

 

이렇게 오픈소스에 패치를 내려고 한 덕분에 저는 타이밍 공격을 확실하게 이해할 수 있었습니다. 덤으로 타이밍 공격에 대응하는 코드를 작성하는 방법도 익히게 되었습니다. 게다가 제가 수정 제안한 코드가 패치에 반영되어 개발자 세상을 미력하게나마 더 이롭게 하는 영향도 누릴 수 있었습니다. 

 

p.83

소프트웨어 제품은 아직 설계와 제작과 관련된 표준이 없습니다. 소프트웨어 산업이 채 100년도 안 된 짧은 역사를 가졌기 때문이기도 하지만 소프트웨어 제품 개발을 작가가 소설을 쓰듯이 자유(아무런 제약없이 결정하고 만든다는 의미입니다)롭게 그리고 민첩하게 만들면 모든 문제가 해결된다는 근거 없는 주장을 종교처럼 받드는 사람들의 영향이 크다고 생각합니다. 심지어 요즘에는 소설 작가도 전문 소프트웨어를 사용하고 소설도 갖추어야 하는 형식이나 구조 구성이 있습니다. 따라서 '소설을 쓰듯이 자유롭게'라는 표현은 맞지 않습니다.

 

p.104-105

만들려는 소프트웨어가 가용성을 갖췄다는 것을 증명할 수치적 조건을 정의해야 합니다. "평균 무고장 시간 - Mean Time Between Failure, MTBF, 평균 수리 시간 - Mean Time To Repair, MTTR은 얼마인가요?"라는 질문에 답할 수 있어야 합니다. 현대의 소프트웨어는 대부분 웹을 기반으로 제공되기 때문에 가용성은 특히나 더 중요합니다. 제품 초기라면 평균 무고장 시간은 100일, 평균 수리 시간은 12시간 정도로 설계해야 합니다.

 

p.122

배워야 할 지식을 저처럼 현재 업무랑 관련된 것에 50%, 앞으로 관련될 것에 30%, 관련없지만 관심 있는 것에 20% 정도만 시간을 투자해 보세요. 개발자에게 성장은 멈춰 있는 약속 장소가 아니라, 계속해서 움직이는 사냥감에 가깝습니다. 두리번거리며 준비하다보면, 회사 업무가 나와 상관없이 변화하더라도 기회가 될 겁니다.

 

p.160

'분명히 개선이 필요하다고 스스로 생각하는 개발/조직 문화 안에서, 그리고 동료 및 상사로부터 개선에 대한 의지를 확인하지 못한 상황에서 나는 한 걸음 더 성장할 수 있을까? 나의 개발/조직 문화에 대한 기여 욕구를 무시할 수 있는 것일까?'라는 질문에 답하기 위한 고민의 시간을 보내고, 그 결과 다른 환경으로 도전을 결심했습니다. 퇴사 이후 새로운 직장을 찾는 면접 과정에서 저는 다른 직군과의 협업 과정, 커뮤니케이션 개선점, 그리고 면접관들의 개발/조직 문화 개선 경험에 대해 유독 질문을 많이 했습니다.

 

p.161

대기업에서 스타트업으로 다시 대기업으로 이직하고 경험하면서, 기술과 사람 그리고 조직에 대한 성장 기회와 경험이 차곡차곡 쌓였습니다. 다음으로 저에게 찾아온 성장에 대한 갈증은 지금까지와는 결이 조금 달랐습니다. '개발자는 무엇인가?, 수많은 개발자 중에서 박미정이라는 개발자는 무엇을 잘하는 개발자인가?'라는 질문이 계속되었습니다. 이쯤에서 그 해답을 찾았습니다. 기술이라는 범주 안에 갖혀서 스스로를 정의하기 보다 '서비스를 만들고 성장시키는 일이 즐거운 사람', '서비스를 위해 기술이라는 도구를 잘 다루는 사람'으로 저를 정의했습니다. 그래서 훗날 책을 집필할 때 저를 '서비스/프로덕트 만들기를 좋아하는 프로그래머'라는 한 줄로 소개하기도 했습니다.  

 

p.182~183

그저 해야 할 일을 정리하는 것만으로도 나쁘지 않은 목표를 얻을 수 있습니다. 일단 현재 상황을 파악하고 할 일을 적어보세요(꼭 적어야 합니다). 최대한 현재 상황을 먼저 단순하게 파악해보고 필요하다면 정보를 더 구합니다. 제 강연과 책에서도 이야기했지만 할 일을 적고 나서 우선 순위를 정하면 됩니다. 가장 먼저 처리할 일은 중요하면서 시급한 일이지만, 중요한 일이 시급해지지 않도록 미리미리 목표와 계획을 잡아 해결해 나아가야 합니다.

 

목표를 세웠는데 실천 계획을 어떻게 세워야 할지 모르겠나요? 목표를 한 번에 해결하려고 들면 안 됩니다. S.M.A.R.T를 고려해서 작게 잘라서 목표에 한 걸음씩 다가가도록 실천해나가야 합니다. 그러면 목표가 더 명확해지고 구체적인 계획 방법도 떠오르게 됩니다.

 

성장이나 이직에 관심이 많을테니 다음과 같은 목표를 세웠다고 가정해보겠습니다.

 

- 지금 하는 일을 계속하기

- 현재 팀에서 다른 일을 해보기

- 회사 내 다른 팀에서 다른 일을 해보기

- 회사 내에서 다른 직군으로 이동해보기

- 다른 회사에서 다른 일을 해보기

 

이어서 각각에 대해서 장단점을 분석해 계획을 세워보면 됩니다. 계획을 꼭 혼자서 세울 필요는 없습니다. 직장에서는 동료나 관리자와 세울 수도 있습니다. 마음이 열린 관리자라면 분석을 도와줄 수도 있을 겁니다. 다른 회사로 이직하는 옵션이라면 싫어하겠짐나 회사에서 더 행복해지고 더 성과를 내고 더 성장하는 계획을 세우는 조직원을 돕는 것이야 말로 관리자가 존재하는 이유입니다.

 

계획을 세우고 나서 평가 방법을 세웁니다. 평가 방법을 세우다 보면 이 목표가, 계획이, 실천이 최선인가를 조금 먼 발치에서 바라볼 수 있습니다. 보이지 않았던 것들이 보이게 됩니다. 지금 자리에서 최선을 다 하기로 목표를 세웠는데 더 나은 성장을 하려면 이직을 해야겠다는 결론이 날 수도 있고, 그 반대일 수도 있는 거죠.

 

준비 없이 실천하면 불로 향하는 불나방 꼴이 납니다. 목표한 바를 차근차근 달성하는 계획과 실천 평가를 잊지 마세요. 

 

p.192~193

"단순함은 문제 해결에 이르는 가장 빠른 길이다."

 

- 워드 커닝햄

 

어떤 분야건 지속적으로 발전하려면 목표와 방향 설정이 중요합니다. 하지만 감당하기 어려운 양의 기술이 존재하는 복잡한 개발 세계에서 무엇을 목표로, 어떤 방향으로 나아갈지 정하기란 매우 어렵습니다. 이럴 때 일단 '프로덕트 잘 만들기'를 목표로 삼길 제안합니다. 프로덕트가 만들어지는 과정을 초기 단계부터 잘 이해하는 개발자가 되곘다고 결심하는 것이죠. 주의할 점은 코드를 잘 짜는 것이 목표가 아니고 코드가 동작하는 제품, 즉 프로덕트 잘 만들기가 목표라는 점입니다.

 

"이거 너무 쉽고 당연한 말 아닌가요?"라는 생각이 들 겁니다. 맞습니다. 일부러 프로덕트를 잘못 만들려는 사람은 없습니다. 하지만 주변을 잘 살펴보면 프로덕트가 생략된 목표를 설정한 사례는 많습니다.

 

1. "스프링 프레임워크를 공부해야겠다. 내일부터 온라인 강의를 들어야지."

2. "모바일 개발에서 주목받는 플러터 프레임워크를 공부하겠어."

 

둘 다 성장을 위해 충분히 선택할 수 있는 목표입니다. 하지만 같은 목표여도 프로덕트가 목적일 때는 실제로 만들 대상이 구체적으로 명시되어야 합니다.

 

1. "간단한 API 서버를 스프링 기반으로 만들어보겠어."

2. "플러터로 여행 기록용 모바일 어플을 만들어보겠어."

 

프로덕트 잘 만들기라는 목표는 얼핏 뻔해 보이지만, 실제 프로덕트를 목표로 삼는 계획과 그렇지 않은 계획은 적지 않은 결과의 차이를 만들어냅니다. 실제로 프로덕트를 만드는 상황에 최대한 노출하면 설계의 결함을 발견하거나, 문제 해결을 위해 계획하지 않았던 기술이 필요함을 알게 됩니다. 우리는 실제 상황을 예상보다 훨씬 알지 못하기 때문에 무언가를 만들어보며 깨닫는 경우가 많습니다. 이뿐만 아니라 프로덕트가 목표라면 기술 선택의 순간에 더 깊은 고민을 하게 됩니다. 새로운 언어나 도구를 사용하려고 하다가도 제품에 더 적정한 기술을 고민하고, 팀 단위 작업이라면 함께 할 동료들이 마주칠 상황도 고려하게 됩니다. 또 더 나아가 자신이 일할 조직이나 향후 회사의 결정까지 영향을 미치기도 합니다.

 

p.203

단순하게 예제를 실행시키고 얻은 지식과, 끊임없이 판단과 피드백을 반복하며 제품을 만들어본 경험은 폭과 깊이가 다를 수밖에 없습니다. 소프트웨어 이외의 많은 분야에서도 현장 경험은 중시되지만, 직접 현장에 참여하지 않고 관련 역량을 쌓기는 어렵습니다. 현장 경험을 위해 담당 업무를 변경하거나, 이직을 해야 할 수도 있습니다. 하지만 소프트웨어 개발이라면 이야기가 다릅니다. 개발자라면 이직을 하거나, 회사에서 진행 중인 프로젝트에 참여하지 않아도 다양한 방법으로 프로덕트를 만드는 경험을 습득할 수 있습니다. 깃허브에서 수많은 프로젝트를 살펴볼 수 있고, 멀리 떨어져 있는 다른 분야의 개발자들과도 팀을 이루어 프로덕트를 만들어볼 수 있습니다. 그뿐만 아니라 웹에 공개된 수많은 기술 명세, 존경할 만한 이들의 지혜가 담겨 있는 블로그와 강의, 수많은 채널에서 개발을 주제로 활동하는 커뮤니티와 이들이 진행하는 세미나도 있습니다. 

 

p.210-211

제가 가장 애정하는 원칙은 "제어할 수 없는 것에 의존하지 않기"입니다. 이 원칙을 <실용주의 프로그래머>에서 처음 알게 되었습니다.

 

"현실 세계의 변화와 설계 사이의 결합도를 줄여야 한다. 전화번호를 식별자로 사용하는가? 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라."

 

<실용주의 프로그래머> 중

 

자신이 제어할 수 없는 현실 세계 속성을 사용하는 경우를 알아봅시다. 예를 들어 주민등록번호를 데이터베이스 테이블의 PK로 사용하는 경우입니다. 주민등록번호는 대한민국이라는 국가에서 발행한 유일값이므로 신뢰할 수 있지 않겠냐라고 주장할 수 있겠지만, 실제로 주민등록번호를 사용하려면 한 번의 변화와 크나큰 제약을 고려해야 합니다.

 

- 변환 : 1975년 주민등록번호 체계가 변경되었습니다.

- 제약 : 2014년 주민등록번호의 무분별한 수집이 금지되었습니다.

 

2014년에 법으로 주민등록번호의 무분별한 수집이 금지되면서, 그간 주민등록번호를 주요 키로 사용하던 시스템들은 비즈니스 로직 구현을 뒤로 하고 주민등록번호와의 의존성을 끊는 시스템 업데이트를 먼저 진행할 수밖에 없었습니다. 절대 변하지 않을 것이라 믿고 의존했던 속성이었지만, 제어할 수 없는 외부의 속성이었기에 이런 일이 발생한 겁니다. PK를 직접 만든 키로 설정했다면, 법이 바뀌어도 큰 수고를 들이지 않고 변화에 대응할 수 있었을 겁니다. 이처럼 제어할 수 없는 것에 의존하면 변화에 민감한, 흔들리기 쉬운 소프트웨어가 됩니다. 반대로 프로그래머는 설계를 하는 데 있어 외부에 의존하는 영역을 줄일수록 큰 변화에도 쉽게 흔들리지 않는 견고한 소프트웨어를 개발할 수 있습니다. 

 

p.214

정리하면 다음과 같습니다.

 

- 제어할 수 없는 값에 의존하는 코드들을 최대한 멀리한다.

- 주요 비즈니스 로직은 모두 제어할 수 있는 값만 의존하게 해 테스트 코드 작성이 쉬운 형태로 구성한다.

 

p.224

회사의 매출, 영업이익 등은 지금 당장 제가 제어할 수 없는 영역인데, 당장 해결이 안 되는 영역을 원망해봐야 변하는 것은 없습니다. 그보다는 제어할 수 있는 '어떻게 하면 이 상황을 긍정적으로 해석할 수 있을까'를 고민하고 행동으로 옮겨야 합니다. 물론 회사가 부족할 때 함께 해준 팀원들에 대해 정말 감사한 마음을 갖고, 점진적으로 충분한 보상을 해줘야 하는 것은 당연합니다.

 

p.235

"작은 효율성에 대해서는, 말하자면 97% 정도에 대해서는 잊어버려라. 섣부른 최적화는 모든 악의 근원이다."

 

- 도널드 카누스

 

p.243-245

"바퀴를 다시 발명하지 마라"라는 격언이 있습니다. 이 격언에서 말하는 바퀴는 단순한 바퀴가 아닙니다. 재발명할 필요도 없고, 재발명할 수도 없는 '원형적인 물체'에 대한 상징으로서의 '바퀴'입니다. 그러나 대부분 개발자가 만들어야 하는 코드는 그런 원형적인 수준의 절대 바퀴가 아닙니다. 그럼에도 불구하고 개발자들은 이 격언을 절대 교리처럼 받들고 글자 그대로 충실하게 실천합니다. 바퀴를 다시 발명하는 행위를 금기시하고, 이미 만들어진 바퀴를 찾아 헤매고 있습니다.

 

바퀴를 다시 발명하는 일을 쓸모없다고 굳게 믿는 개발자에게 자바스크립트의 대부이자 JSON의 창시자인 더글라스 크락포드의 말 "바퀴를 새로 발명하는 일의 좋은 점은 둥근 바퀴를 얻을 수 있다는 점입니다"와 함께 UNIX 셸의 역사를 들려주고 싶습니다. 

 

처음으로 널리 사용된 UNIX 셸은 스티븐 본이 1977년 만든 본 쉘입니다. 그 이후 vi의 발명가로 유명한 빌 조이가 1978년 C쉘을, 데이비드 콘이 1983년 상업용 콘 셸을 만들었습니다. 이후에도 수많은 셸이 만들어졌고, 브라이언 폭스가 1989년에 만들어서 리눅스의 기본 셸로 자리잡은 본 어게인 셸과 폴 폴스태도가 1990년에 만든 Z셸은 지금까지도 널리 사용됩니다. 

 

어디선가 한 번쯤은 이름을 들어봤을, 위키백과에 등재된 전설적인 개발자들이 격언을 충실히 따르느라 바퀴를 재발명하지 않았다면 우리는 지금도 켄 톰슨이 1971년에 만든 V6 셸을 쓰고 있을지도 모릅니다. 

 

바퀴를 다시 발명하는 일의 또 다른 좋은 점은 바퀴를 더 잘 알게 된다는 점입니다. 처음부터 잘 굴러가는 완벽하게 둥근 바퀴를 만들려고 하지 마세요. 일단 굴러가는 바퀴를 만들어야 합니다. 굴러간다고 그만두면 안됩니다. 어떻게 하면 더 잘 굴러갈지 끊임없이 고민해야 합니다. 바퀴를 계속 만들다 보면 애초에 바퀴가 필요 없었다는 사실을 깨닫게 될 수도 있고, 세상이 깜짝 놀랄 영원히 굴러가는 바퀴를 만들게 될 수도 있습니다. 대부분은 기존에 쓰던 바퀴와 큰 차이가 없거나 더 나빠졌을 겁니다. 그럼에도 불구하고 바퀴에 대해서 더 잘 알게 됐다는 것은 분명합니다.

 

모든 것을 다시 발명할 필요는 없습니다. 지금의 나를 지탱하는, 미래의 나를 지탱할 기술이라면 한 번쯤은 시도해볼 만한 가치가 있습니다.