Chapter 3

기본 도구

  • 3.1 일반 텍스트의 힘
  • 3.2 셸
  • 3.3 파워 에디팅
  • 3.4 버전 관리
  • 3.5 디버깅
  • 3.6 텍스트 처리
  • 3.7 엔지니어링 일지

매일 쓰는 도구 이야기야. 목수에게 좋은 톱과 대패가 중요하듯, 프로그래머에게 도구를 다루는 능력은 기본 중의 기본이지. 도구에 능숙해지면 생각과 구현 사이의 거리가 줄어들거든.

저자들은 일반 텍스트(plain text)를 사랑하라고 말해. 바이너리 형식 대신 사람이 읽을 수 있는 텍스트를 기본으로 하라는 거야.

왜?

  • 보험 — 어떤 도구로든 읽을 수 있잖아. 독점 형식은 그 도구가 사라지면 데이터도 사라져
  • 활용성 — grep, sed, awk 같은 유닉스 도구로 바로 처리할 수 있지
  • 테스트 용이 — 텍스트 기반 입출력은 테스트 데이터 만들기가 쉬워
  • 차이 확인 — diff로 뭐가 바뀌었는지 바로 볼 수 있어

"텍스트는 인간이 이해할 수 있는 형태"라는 게 핵심이야. Field19=467abe는 텍스트지만 의미를 알 수 없잖아. DrawingType=UMLActivity는 텍스트이면서 의미도 통하지. 후자가 진짜 일반 텍스트야.

HTML, JSON, YAML, HTTP, SMTP — 우리가 매일 쓰는 프로토콜과 포맷 대부분이 텍스트 기반인 데는 이유가 있어.

GUI는 편리하지만 한계가 있거든. 저자들은 셸의 힘을 활용하라고 강력히 주장해.

셸이 강력한 이유:

  • 조합 가능성 — 작은 명령어를 파이프로 연결해서 복잡한 작업을 수행
  • 자동화 — 반복 작업을 스크립트로 만들 수 있지
  • 재현성 — 명령어 히스토리가 곧 문서야

"GUI로 할 수 있는 건 셸로도 다 할 수 있어. 하지만 셸로 할 수 있는 건 GUI로 다 할 수 없지."

저자들의 제안: 매주 하나씩 셸 명령어를 배워. 한 달이면 네 개, 일 년이면 쉰 개. 그때쯤이면 동료들이 마법사라고 부를 거야.

셸 커스터마이징도 강조하거든. 프롬프트, 별칭(alias), 셸 함수를 자기 작업 방식에 맞게 설정해. 자기 도구를 자기 손에 맞추는 거지.

하나의 에디터를 잘 써. IDE든 Vim이든 Emacs든 VS Code든, 하나를 골라서 깊게 파라는 거야.

에디터 유창성(fluency)의 기준:

  • 텍스트 편집할 때 손이 키보드에서 떨어지지 않아
  • 커서 이동에 마우스를 쓰지 않아
  • 단어, 줄, 블록 단위로 자유자재로 조작해
  • 다중 커서, 매크로, 코드 접기를 자연스럽게 써

유창해지는 방법: 의식적으로 연습해. 반복적인 작업을 발견하면 "이걸 더 빠르게 하는 방법이 있을까?"를 물어보고 찾아봐. 처음에는 느리더라도, 한번 배우면 영원히 시간을 벌지.

20주년 기념판에서는 특정 에디터 추천을 빼고 원칙에 집중했어. 에디터 전쟁은 무의미하다는 입장이야.

항상, 모든 것을, 버전 관리해.

코드만이 아니야. 문서, 빌드 스크립트, 설정 파일, 테스트 데이터 — 프로젝트에 관련된 모든 것을 버전 관리 시스템(VCS)에 넣어.

버전 관리의 장점:

  • 실행 취소 버튼 — 언제든 이전 상태로 돌아갈 수 있지
  • 변경 이력 — 누가, 언제, 왜 바꿨는지 기록돼
  • 협업 — 여러 사람이 동시에 작업할 수 있어
  • 자동화의 기반 — CI/CD의 출발점이야

저자들은 혼자 작업할 때도 버전 관리를 쓰라고 해. 로컬 프로젝트, 개인 설정 파일, 심지어 문서 작성까지. "버전 관리는 프로젝트의 타임머신"이라는 비유가 딱 맞지.

브랜치 전략보다 중요한 건 자주 커밋하라는 거야. 작은 단위로 자주 커밋하면 문제가 생겼을 때 원인을 빨리 찾을 수 있거든.

디버깅은 퍼즐 풀기야. 감정을 빼.

디버깅에서 가장 중요한 규칙: 비난하지 마. "이건 네가 짠 코드잖아" 같은 건 의미 없어. 버그는 발견하고 고쳐야 할 문제일 뿐이야.

디버깅 전략들:

  • 재현하라 — 버그를 재현할 수 없으면 고칠 수도 없어. "가끔 그래요"는 가장 무서운 말이지
  • 데이터를 읽어라 — 추측하지 말고 로그를 봐. 실제 데이터가 뭐라고 하는지 확인해
  • 이진 탐색 — 문제 범위를 반씩 좁혀가. git bisect가 대표적이야
  • 러버덕 디버깅 — 고무 오리한테 설명해봐. 말로 설명하다 보면 문제가 보이거든
  • 배제의 과정 — "이건 OS 문제일 리 없어" 같은 가정을 하지 마. 전부 의심해

버그를 고치면 끝이 아니야. **"왜 이 버그가 더 일찍 발견되지 않았을까?"**를 물어봐. 테스트를 추가해야 할 수도 있고, 프로세스를 개선해야 할 수도 있지.

프로그래머는 텍스트를 다루는 사람이야. 텍스트 처리 언어를 하나는 익혀두라는 조언이지.

예전 판에서는 Perl을 추천했는데, 20주년 기념판에서는 Python이나 Ruby 같은 범용 스크립팅 언어를 권해. 핵심은 특정 언어가 아니라 텍스트를 프로그래밍으로 조작하는 능력이야.

활용 사례:

  • 로그 파일 분석
  • 코드 생성 (보일러플레이트 자동 생성)
  • 데이터 형식 변환
  • 테스트 데이터 생성
  • 빌드 시스템 보조

셸 스크립트로도 충분한 경우가 많고, 복잡해지면 Python 같은 언어로 넘어가면 돼.

20주년 기념판에서 새로 추가된 절이야. 종이 노트에 일지를 쓰라는 꽤 아날로그적인 조언이지.

왜 종이인가:

  • 디지털 기기는 산만해. 앱 알림, 다른 탭 — 방해 요소가 많잖아
  • 쓰는 행위 자체가 생각을 정리해줘
  • 나중에 뒤적이면서 패턴을 발견할 수 있어

일지에 쓸 것들:

  • 오늘 뭘 했는가
  • 배운 것
  • 스케치, 아이디어
  • 회의 메모
  • 디버깅 과정에서 시도한 것과 결과

"기억력을 믿지 마라"가 핵심 메시지야. 일주일 전에 왜 그 결정을 했는지 기억나? 대부분 기억 못하거든. 적어놓으면 돼.


정리

3장 읽고 기억할 거 세 가지:

  1. 도구에 능숙해지는 건 투자야. 에디터, 셸, 버전 관리 — 매일 쓰는 것부터 마스터해
  2. 디버깅은 감정이 아니라 과학이지. 재현하고, 데이터를 보고, 범위를 좁혀가야 해
  3. 기록해. 엔지니어링 일지든 뭐든, 기억에 의존하지 마