🤔 Chapter 3: 기본 도구

도구는 여러분의 재능을 증폭한다. 도구가 더 훌륭하고 여러분이 더 사용법에 능숙해질수록 여러분의 생산성은 더 높아질 것이다.
일반적으로 사용하는 기본 도구들로 시작하라. 점차 경험을 쌓고 특별한 요구 사항을 만나면서 이 기본 세트에 다른 도구를 추가하게 될 것이다. 언제나 일을 하는 데에 더 나은 방법이 없는지 살펴봐라. 사용하는 도구로 다룰 수 없는 문제를 마주쳤다는 생각이 들면, 도움이 될 만한 다른 것이나 더 강력한 것을 찾아보아야 한다는 것을 명심하라. 필요에 따라 도구를 취하도록 하라.

도구들의 사용법을 배우는 데에 시간을 투자하라. 언젠가는 별다른 자각 없이도 손가락이 키보드 위를 움직이면서 텍스트를 조작하고 있나는 사실을 발견하고 놀라게 될 것이다.

🍭 Topic 16. 일반 텍스트의 힘

실용주의 프로그래머로서 우리의 기본 재료는 나무나 쇠가 아니라 지식이다. 우리가 수집하는 요구 사항은 지식이고, 우리는 그 지식을 설계와 구현, 테스트, 문서로 표현한다. 그리고 우리는 지식을 저장하는 최고의 포맷이 일반 텍스트라고 믿는다. 일반 텍스트를 사용하면 수작업으로든 프로그램으로든 동원 가능한 거의 모든 도구로 지식을 다룰 수 있게 된다.

🥕 일반 텍스트란?

일반 텍스트는 인쇄 가능한 문자로 이루어지고, 정보를 전달하기에 적합한 형식을 갖추어야 한다. 쇼핑 목록처럼 간단할 수도 있다.

• 우유
• 양파
• 커피

정보를 전달한다는 부분이 중요하다. 다음은 쓸모없는 일반 텍스트다.

awpojawda'apkwqwd''wqd;wda;awd

우리가 만드는 일반 텍스트는 사람이 이해할 수 있어야 한다.

Tip 25. 지식을 일반 텍스트로 저장하라.

일반 텍스트가 형식이 없는 텍스트를 의미하는 것은 아니다. HTML, JSON, YAML 등은 모두 일반 텍스트다. HTTP, SMTP, IMAP 등 인터넷에서 사용되는 핵심 프로토콜도 대부분 일반 텍스트다. 이렇게 일반 텍스트가 널리 쓰이는 이유는 다음과 같다.

• 지원 중단에 대한 보험
• 기존 도구의 활용
• 더 쉬운 테스트

🥕 최소 공통분모

자율적으로 서로 데이터를 교환하면서도 거칠고 위험한 인터넷을 여행하는 블록체인 기반 지능형 에이전트의 미래 시대에도 텍스트 파일은 어디에나 존재하고 여전히 살아남을 것이다.
여러분은 모든 참가자가 하나의 공통 표준을 사용해서 소통하도록 해야 한다. 일반 텍스트가 바로 그 표준이다.

🍭 Topic 17. 셀 가지고 놀기

텍스트 파일을 다루는 프로그래머에겐 명령어 셀이 작업대다. 셀 프롬프트에서 모든 종류의 도구를 불러다 쓸 수 있다. 셀에서 응용 프로그램인 디버거, 브라우저, 에디터, 유틸리티를 실행할 수 있다. 파일을 검색할 수 있고, 시스템의 상태를 조회할 수 있으며, 출력을 필터링할 수 있다.

GUI의 장점은 WYSIWYG(What You See Is What You Get) 즉 여러분이 보는 것이 여러분이 얻는 것이라는 점이지만, 단점은 WYSIAYG(What You See Is All You Get) 즉 여러분이 보는 것이 여러분이 얻는 전부다. GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다. 실용주의 프로그래머는 오직 코드만 쏟아 내거나, 객체 모델만 개발하거나, 문서만 작성하거나, 빌드 과정 자동화만 하지는 않는다. 이 모든 일을 다 한다. 이 모든 일을 다 한다. 하지만 GUI 환경에서 이런 작업을 하는 도구의 사용 범위는 보통 그 도구가 사용되리라고 예상되는 작업에 한정된다.

Tip 26. 명령어 셀의 힘을 사용하라.

셀에 익숙해지면 여러분의 생산성이 급상승할 것이다.

🍭 Topic 18. 파워 에디팅

여러분이 원한다면 에디터를 몇 개 사용하든 상관없다. 다만 각각의 에디터에 유창해지도록 노력해야 한다.

Tip 29. 에디터를 유창하게 쓸 수 있게 하라.

왜 에디터에 유창해지는 것이 중요할까? 유창해지는 것의 가장 큰 이점은 더는 에디터 사용법을 생각하지 않아도 된다는 것이다.
뭔가를 생각하는 것에서 에디터 화면에 그게 뜰 때까지 거리가 확 줄어든다. 생각이 자유롭게 흐를 것이고 프로그래밍에 큰 도움이 될 것이다.

🥕 어떤 것이 "유창"한 것인가?

어느 정도 에디터를 써야 유창하다고 볼 수 있을까?

• 텍스트를 편집할 때 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용을 선택하라.
• 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법 단위로 커서를 이동하라.
• 변경한 코드의 들여쓰기를 자동으로 맞춰라.
• 여러 줄의 코드를 명령 하나로 주석 처리했다가 다시 주석을 해제하라.
• 실행 취소를 여러 번 했다가 취소한 명령을 재실행 기능으로 다시 수행하라.
• 에디터 창을 여러 구역으로 쪼개라. 그리고 각 구역 사이를 이동하라.
• 특정 줄 번호로 이동하라.
• 여러 줄을 선택한 후 가나다순으로 정렬하라
• 문자열로, 또 정규 표현식으로 검색하라. 이전에 검색했던 것을 다시 검색하라.
• 선택 영역이나 패턴 검색을 이용하여 일시적으로 여러 개의 커서를 만든 다음, 동시에 여러 곳의 텍스트를 편집하라.
• 현재 프로젝트의 컴파일 오류를 표시하라.
• 현재 프로젝트의 테스트를 실행하라.

이 과제들을 마우스나 트랙패드 없이 모두 수행할 수 있는가?
여러분이 현재 사용하는 에디터로는 수행 불가능한 것이 몇 가지 있다고 할지도 모르곘다. 그렇다면 에디터를 바꿀 떄인 것은 아닐까?

🥕 유창해지기

우리도 여러분이 명령어를 모두 외우리라 기대하지는 않는다. 대신 우리는 더 실용적인 접근 방법을 제안한다. 여러분의 삶을 편하게 해 주는 명령어를 배워라.

먼저 여러분이 에디터를 사용하는 모습을 관찰하라. 무언가 같은 일을 반복하는 것을 발견한ㄹ 때마다 이렇게 생각하는 습관을 들여라. "분명 더 나은 방법이 있을 텐데." 그리고 더 나은 방법이 있는지 찾아보라.

유용한 기능을 새로 찾았다면 이 기능을 여러분이 몬이 기억하도록 만들어야 한다. 그래야 반사적으로 사용할 수 있다. 우리가 아는 유일한 방법은 반복이다. 여러분의 새로운 초능력을 활용할 기회를 의식적으로 찾아다녀라.
하루에도 몇 번씩 사용할 수 있다면 이상적이다. 대략 1주일 정도 후면 무의식적으로 사용할 수 있을 것이다.

에디터 성장시키기

사용 중인 에디터에서 명백한 한계에 봉착한다면 필요한 기능을 추가하는 확장 기능을 찾아보라. 그런 기능이 필요한 사람은 아마 여러분만이 아닐 것이고, 운이 좋다면 누군가가 해결책을 만들어 놓았을 것이다.

한 걸음 더 나아가라. 사용하는 에디터의 확장 기능 언어를 파해쳐 보라. 여러분이 늘 하는 반복적인 일을 자동화할 방법을 연구해 보라. 한 두 줄만으로 가능할 경우가 많다.

🍭 Topic 19. 버전 관리

버전 관리 시스템은 일종의 거대한 "실행 취소" 키와 같다. 프로젝트 전체에 걸쳐서 코드가 실제로 컴파일되고 실행되던 지난주의 평화로운 시절로 돌려줄 수 있는 타임머신이다.

🥕 소스 코드부터 시작

버전 관리 시스템은 소스 코드나 문서의 모든 변경 사항을 기억한다. 바르게 설정된 버전 관리 시스템이 있으면 소프트웨어의 이전 버전으로 언제든지 되돌아갈 수 있다.

버전 관리 시스템이 관리하는 파일들을 중앙 저장소에도 복제해 두면 자료를 장기간 보관하기에 탁월한 도구가 된다.

버전 관리 시스템을 사용하면 둘 이상의 사용자가 동일한 파일들을 동시에 작업할 수 있다. 심지어 하나의 파일을 동시에 수정할 수도 있다. 파일을 저장소로 다시 보낼 떄 시스템이 수정 사항들을 합쳐 준다.

Tip 28. 언제나 버전 관리 시스템을 사용하라.

언제나, 혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도, 나중에 버리기로 한 프로토타입일지라도, 심지어 여러분이 작업하는 것이 소스 코드가 아닐지라도, 모든 것을 버전 관리 아래 둬라.

🥕 브랜치 사용하기

프로젝트의 어느 시점에나 브랜치를 만들 수 있다. 브랜치에서 작업한 내용은 다른 브랜치로부터 격리되지만, 작업한 브랜치를 나중에 다른 브랜치로 병합할 수도 있다. 여러 사람이 하나의 브랜치에서 함께 작업할 수도 있다.

버전 관리에서 브랜치와 테스트 구조는 공통점이 있다. 둘 다 수천 명의 외부인들이 어떻게 하는 게 맞다고 잔소리를 한다는 거다. 그리고 그들의 조언은 대체로 의미가 없다. 왜냐하면 그들이 진짜로 말하고 있는 거는 "나한테는 이게 괜찮았어"이기 때문이다.
그라ㅓ므로 여러분의 프로젝트에서 버전 관리 시스템을 사용하라. 그리고 업무 흐름에서 문제가 생기면 해결책을 찾아보라. 경험이 좀 더 쌓인 후에 여러분의 사용 방식을 검토하고 조정하는 것을 잊지 말라.

🥕 프로젝트 허브로서의 버전 관리

중앙 저장소가 있으면 프로젝트 업무 흐름을 원활하게 해 주는 수많은 확장 기능을 이용할 수 있다. 저장소 시스템은 대부분 오픈 소스이므로 여러분이 직접 설치하고 운영할 수 있다. 하지만 저장소 관리가 여러분 회사의 핵심 업무는 아니므로 웬만하면 외부 서비스 이용을 추천한다.

특정 브랜치에 푸시(push)를 하면 시스템을 빌드하고, 테스트를 수행한 다음, 테스트가 성공하면 새로운 코드를 서비스에 배포한다.

🍭 Topic 20. 디버깅

🥕 디버깅의 심리

디버깅은 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.
다른 사람의 버그를 발견한 후, 그 버그를 만들어 낸 부정한 범죄자를 비난하는 데에 시간과 노력을 쏟을 수도 있다. 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중해야 한다.

Tip 29. 비난 대신 문제를 해결하라.

버그가 여러분의 잘못인지 다른 사람의 잘못인지는 중요치 않다. 어쨌ㄷ거나 그 버그를 해결해야 하는 사람은 여러분이다.

🥕 디버깅 사고방식

Tip 30. 당황하지 말라.

여러분이 버그라고 생각하는 증상의 원인이 무엇일지 진짜로 생각해 보는 것이 정말 중요하다.
버그를 목격하거나 버그 신고를 보는 순간이 첫 반응이 "그건 불가능해."라면 여러분은 두말할 필요 없이 틀렸다. "하지만 정말 그럴 리가 없는다."로 시작하는 생각의 흐름에 신경 세포 하나도 낭비하지 말라. 왜냐하면 명백히 그런 일은 일어날 수 있으며, 실제로도 일어났기 때문이다.

디버깅할 때 근시안의 함정에 주의하라. 표면에 보이는 증상만 고치려는 욕구를 이겨 내라. 실제 문제는 여러분 눈앞에 있는 것에서 몇 단계 떨어져 있고, 또 다른 여러 가지와 연관되어 있을 확률이 다분하다. 겉으로 드러난 특정 증상만 고치려고 하지 말고, 항상 문제의 근본 원인을 찾으려고 노력하라.

🥕 실마리 찾기

버그를 살펴보기 전에 일단 작업 중인 코드가 경고 없이 깨끗하게 빌드되는지부터 확인하라. 우리는 늘 컴파일러의 경고 수준을 최고로 높게 맞춘다.

어떤 문제건 해결을 하려면 관련 자료를 모두 모아야 한다. 불행히도 버그 보고는 정밀과학이 아니고, 우연에 의해 오도되기 쉽다. 우리는 우연한 사건들을 디버깅하느라 시간을 낭비할 여유가 없다. 일단 정확하게 관찰해야 한다.

• 처음에 받은 자료 이상을 얻기 위해서 버그를 보고한 사용자를 인터뷰할 필요도 있따.
• 경계 조건과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다. 그것도 체계적으로 할 필요가 있다.

🥕 디버깅 전략

버그 재현하기

버그를 고치는 첫걸음으로 가장 좋은 것은 그 버그를 재현할 수 있게 만드는 것이다. 무엇보다, 재현할 수 없다면 어떻게 그 버그를 고쳤다는 것을 확인할 수 있겠는가?

하지만 여러 단계를 거쳐야만 비로소 버그를 재현할 수 있다면 좀 부족하다. 우리는 "명령 하나"로 재현할 수 있기를 바란다. 버그가 출현하는 시점까지 열다섯 단계를 거쳐야 한다면 버그 수정은 훨씬 어렵다.
그래서 디버깅의 가장 중요한 규칙은 이것이다.

Tip 31. 코드를 고치기 전 실패하는 테스트부터.

버그가 발생하는 상황을 다른 것들로부터 분리하다 보면 어떻게 고쳐야 할지에 대한 통찰력을 얻기도 한다. 테스트를 작성하는 행위가 해결책을 알려주는 것이다.

🥕 미지의 세계에 온 프로그래머

버그를 분리한다는 이야기는 다 좋다.

Tip 32. 그놈의 오류 메시지 좀 읽어라.

이상한 결과

프로그램이 죽은 것이 아니라 결과가 이상한 상황이면 어떻게 해야 할까?
디버거를 붙인 다음 여러분의 실패하는 테스트를 이용하여 문제를 재현하라. 무엇보다 먼저 디버거에 잘못된 값이 나타나느지부터 확인하라. 디버거에서 호출 스택 위아래로 어떻게 이동하고, 스택의 지역 변수를 어떻게 확인하는지 숙지하라.

까끔은 영원히 스크롤 해야 할 것 같은 긴 스택 트레이스를 만날 때가 있다. 이런 때는 스택 프레임의 일일이 조사하는 것보다 더 빠른 방법이 있다. 바로 "이진 분할"을 하는 것이다.

🥕 이진 분할

거대한 스택 트레이스가 눈앞에 있다. 여러분은 이 중에 정확히 어떤 함수에서 문제가 되는 값을 엉망으로 만들었는지 찾아내려 한다. 검색을 시작하기 위해 여러분은 중간 즈음에서 스택 프레임을 하나 골라서 값이 정상인지 확인한다. 정상이라면 그 위의 프레임들을 확인해야 하고, 아니라면 그 밑의 프레임들을 확인해야 한다. 다시 이진 분할을 반복한다.

이진 탐색이 가능해지는 것도 여러분이 프로젝트에 좋은 버전 관리 시스템을 사용할 때 얻을 수 있는 많은 혜택 중 하나다. 사실 많은 버전 관리 시스템은 한 발짝 더 나아가서 이 과정을 자동으로 수행한다. 테스트 결과에 따라 문제가 처음 발생한 릴리스를 자동으로 찾아 준다.

🥕 놀라운 구석

어떤 버그로 놀라게 될 때, 애지중지 믿고 있던 진실들을 재평가해야만 한다.
뭔가 잘못될 때 놀라는 정도는 실행되는 코드에 갖는 신뢰와 믿음의 정도에 비례한다. 그렇기 때문에 예상치 못한 놀라운 실패를 대면했을 때 자신이 세운 가정이 적어도 하나는 잘못되었다는 것을 받아들여야 한다. 버그와 관련된 루틴이나 코드나 제대로 작동하는 걸 "안다"고 해서 대충 얼버무리고 지나치지 말라. 그것을 증명하라. 이 맥락 안에서, 이 데이터로, 이 경게 조건하에서 증명하라.

Tip 34. 가정하지 말라. 증명하라.

놀라운 버그를 마주쳤을 때, 단순히 그걸 고치는 것을 넘어서 왜 이 문제가 더 일찍 발견되지 않았을까 생각해 봐야 한다. 버그를 미리 잡을 수 있도록 단위 테스트나 다른 테스트를 수정할 필요가 있었는지 고민해 보라.

버그를 수정하는 김에, 혹시 이것과 동일한 버그가 있을 법한 다른 코드가 있는지 살펴보자. 바로 지금 그것들을 찾아서 고쳐야 한다. 어떤 일이 일어났든지 간에 똑같은 일이 다시 발생하면 그 시살을 알 수 있도록 하라.

이 버그를 고치는 데 시간이 오래 걸린다면 왜 그런지 자문하라. 무엇을 하면 다음번에는 이 버그를 좀 더 쉽게 고칠 수 있을까? 더 나은 테스트 훅을 만들어 넣거나, 로그 파일 분석기를 작성할 수도 있겠다.

마지막으로, 버그가 누군가의 잘못된 가정으로 발생했다면 이 문제를 전체 팀과 함께 토론하라. 한 사람이 오해했다면 다른 사람들도 그럴 수 있다.

🍭 Topic 21. 텍스트 처리

유닉스와 맥을 사용하는 개발자들은 명령어 셸의 능력을 즐겨 활용하는 경우가 많은데, 여기에 awk나 sed와 같은 도구를 결합하여 사용하기도 한다. 좀 더 체계적인 도구를 선호하는 사람들은 파이썬이나 루비 같은 프로그래밍 언어를 더 좋아한다.

이런 언어들은 중요한 기반 기술이다. 이들을 사용해서 유틸리티를 뚝딱 만들어 낼 수도 있고, 아이디어를 프로토타입해 볼 수도 있다.

Tip 35. 텍스트 처리 언어를 익혀라.

🍭 엔지니어링 일지

우리도 일지를 사용한다. 회의에서 메모할 때나 작업하는 내용을 써 놓을 때, 디버깅하다가 변수의 값을 적어 놓을 때, 무엇을 어디 두었는지 기록을 남길 때, 엉뚱한 생각을 기록할 떄, 아니면 때로는 그냥 낙서를 할 때 일지를 쓴다. 일지를 쓰면 좋은 점이 크게 세 가지 있다.

• 기억보다 더 믿을 만하다.
• 진행 중인 작업과 직접적인 관계가 없는 발상을 일단 쌓아 놓을 수 있는 곳이 생긴다. 그러면 위대한 발상을 잊어버릴 걱정 없이 지금 하는 일에 계속해서 집중할 수 있다.
• 무언가를 쓰기 위해 하던 일을 멈추면 여러분의 뇌고 기어를 바꾼다. 누군가에게 이야기를 하는 것과 비슷하다. 하던 일을 되돌아보기에 알맞은 기회가 생기는 것이다. 메모를 시작하자마자 메모의 주제인 여러분이 방금 전까지 하던 일을 실은 말도 안 된다는 것을 깨닫게 될 수도 있다.

엔지니어링 일지를 남겨 보라. 파일이나 위키말고 종이를 사용하라. 글씨를 쓰는 것은 키보드를 두드리는 것과는 다른 무언가 특별한 것이 있다. 일단 한 달만 써 보고 어떤 이득을 얻었는지 살펴보라.
적어도 훗날 여러분이 성공해서 유명해졌을 때 회고록을 쓰는 데에 도움이 될 것이다.