이런 상황이라면
짠 코드는 돌아가는데 6개월 뒤 손대기가 무서운 사람에게 맞는다. 리뷰에서 "이건 좀 아닌 것 같은데"라는 말을 들었지만 왜인지 설명하지 못한 적이 있다면 더 그렇다. 반대로 당장 특정 언어나 프레임워크 문법이 급한 사람에게는 우선순위가 아니다.
한눈에 보기
이 책이 다루는 문제는 "문법은 아는데 왜 프로젝트는 매번 무너지는가"다. 저자들은 원인을 언어나 프레임워크 선택이 아니라 개발자의 일하는 방식에서 찾는다. 중복된 지식, 어디에나 얽힌 결합, 고쳐지지 않고 방치된 창문 깨진 코드가 문제의 뿌리다. 그래서 처방도 도구가 아니라 태도와 습관 쪽으로 향한다. DRY, 직교성, 예광탄 개발, 계약에 의한 설계 같은 원칙이 등장하지만 핵심은 하나다. 변경이 두렵지 않은 구조를 만들고, 자기 코드에 책임지는 태도를 갖는 것이다.
기존 기술서가 "무엇을 배울 것인가"를 다뤘다면 이 책은 "어떻게 판단할 것인가"를 다룬다. 정답 코드를 주는 대신 트레이드오프를 읽는 눈을 키운다. 또 개발을 건축이 아니라 정원 가꾸기로 본다. 설계도대로 한 번에 짓는 일이 아니라, 계속 자라는 것을 계속 손보는 일이라는 관점이다. 그래서 조언의 상당수가 코딩이 아니라 커뮤니케이션, 추정, 학습 습관에 걸쳐 있다. 20년이 넘도록 이 책이 읽히는 이유도 특정 기술에 묶이지 않았기 때문이다.
핵심 인사이트
- 01
DRY는 코드 복붙 금지가 아니다
DRY의 대상은 코드 줄이 아니라 "지식"이다. 같은 규칙이 코드, 문서, DB 스키마, 테스트에 각각 적혀 있으면 그게 중복이다. 예를 들어 배송비 계산 조건이 서버 코드와 프런트 검증과 운영 매뉴얼에 따로 적혀 있다고 하자. 정책이 바뀌면 세 군데를 다 고쳐야 하고, 하나를 빠뜨리는 순간 버그가 된다. 반대로 우연히 생김새만 같은 두 함수는 억지로 합치면 오히려 결합만 늘어난다. 그래서 판단 기준은 "모양이 같은가"가 아니라 "같은 이유로 함께 바뀌는가"다.
- 02
깨진 창문 하나가 프로젝트를 무너뜨린다
코드베이스는 어느 날 갑자기 썩지 않는다. 방치된 나쁜 코드 하나가 "여기선 이래도 된다"는 신호가 되면서 무너진다. 급하다는 이유로 넣은 임시 처리 한 줄에 아무도 손대지 않으면, 다음 사람도 같은 방식으로 한 줄을 얹는다. 몇 달 뒤엔 아무도 그 파일을 고치려 하지 않는 상태가 된다. 그래서 처방은 대대적인 리팩터링이 아니라 즉시성이다. 지금 고칠 수 없다면 최소한 주석이나 티켓으로 "이건 깨진 창문"이라고 표시해 둔다. 표시된 문제와 방치된 문제는 팀에 전혀 다른 신호를 준다.
- 03
완벽한 설계보다 예광탄이 낫다
요구사항이 흐릴 때 설계를 오래 붙잡는 건 어둠 속에서 조준하는 일과 같다. 예광탄 개발은 UI부터 DB까지 얇게 관통하는 최소 경로를 먼저 만들고, 그 궤적을 보며 조준을 고친다. 로그인 하나를 화면부터 저장까지 실제로 통과시켜 보면, 문서로는 안 보이던 연동 문제와 오해가 첫 주에 드러난다. 프로토타입과 다른 점은 예광탄 코드는 버리지 않고 그대로 뼈대가 된다는 것이다. 그래서 얻는 건 속도가 아니라 피드백 주기다. 틀린 방향을 3개월 뒤가 아니라 3일 뒤에 알게 된다.
- 04
직교성은 "고칠 때 겁나지 않음"의 다른 이름
직교적인 시스템에서는 한 곳을 바꿔도 다른 곳이 흔들리지 않는다. 반대로 결합이 심하면 작은 수정 하나에 영향 범위를 파악하느라 하루가 간다. 결제 로직 안에 화면 문구와 로깅 포맷이 섞여 있으면, 문구 한 줄 바꾸는 데 결제 테스트를 다시 돌려야 한다. 흔한 착각은 이걸 미적인 문제로 여기는 것이다. 실제로는 변경 비용과 테스트 가능성의 문제다. 모듈을 떼어내 단독으로 테스트할 수 있는지가 가장 빠른 자가진단이다.
- 05
책임은 코드가 아니라 약속의 문제다
저자들은 "고양이가 소스를 먹었어요" 식의 변명을 경계한다. 못 지킬 일정과 못 만들 기능을 미리 말하는 것이 실용주의다. 문제가 생겼을 때 필요한 건 사과가 아니라 대안이다. "못 합니다"보다 "이 범위를 빼면 금요일에 가능하고, 다 하려면 다음 주 수요일이다"가 협업을 만든다. 추정도 같은 맥락이다. 단일 숫자를 던지는 대신 범위와 가정을 함께 말하면 상대가 판단할 수 있다. 결국 신뢰는 정확한 예측이 아니라 정직한 갱신에서 나온다.
- 06
지식 포트폴리오는 자산처럼 관리하는 것
기술 지식은 시간이 지나면 가치가 떨어지는 자산이다. 그래서 저자들은 학습을 투자처럼 다루라고 말한다. 정기적으로 조금씩 넣고, 한 기술에 몰빵하지 않고 분산하고, 가끔 위험한 신기술에도 소액을 건다. 지금 회사에서 쓰는 스택만 6년 깊게 판 사람은 그 스택이 저물 때 대안이 없다. 반대로 매년 다른 언어를 하나씩 건드린 사람은 새 언어를 배우는 속도 자체가 빨라진다. 핵심은 무엇을 배웠느냐가 아니라 배우는 습관이 유지되고 있느냐다.
이렇게 적용한다
상황급한 배포 때문에 임시 처리 코드를 넣게 될 때
그 자리에 즉시 주석과 이슈 번호를 남겨 "의도된 임시"로 표시한다. 왜 이렇게 했는지, 어떤 조건이 되면 제거하는지를 두 줄로 적는다. 방치된 코드와 표시된 코드는 다음 사람이 받는 신호가 완전히 다르다.
상황새 기능 요구사항이 애매한 채로 스프린트가 시작될 때
전체 설계를 확정하지 말고, 가장 얇은 경로 하나를 끝에서 끝까지 관통시킨다. 화면 입력에서 저장까지 실제로 동작하는 한 줄기를 먼저 만들고 이해관계자에게 보여준다. 문서 검토보다 훨씬 빠르게 오해가 드러난다.
상황일정이 밀릴 것 같은데 말을 못 꺼내고 있을 때
"늦습니다" 대신 선택지를 두 개 만들어 간다. 범위를 줄인 안과 기한을 늘린 안을 각각 근거와 함께 제시한다. 결정을 상대에게 넘기되 판단 재료는 내가 준비하는 것이 실용주의적 책임이다.
ACTION ITEMS
오늘 바로 할 수 있는 것.
- ✓오늘 작업 중인 파일에서 같은 규칙이 두 군데 이상 적힌 곳을 하나 찾아 한 곳으로 모은다.
- ✓코드베이스에서 가장 손대기 싫은 파일 하나를 골라 이슈로 등록하고 제목에 이유를 적는다.
- ✓다음 기능을 예광탄 방식으로 쪼개, 오늘 안에 끝에서 끝까지 통하는 최소 경로를 만든다.
- ✓현재 맡은 작업의 추정치를 단일 숫자가 아니라 범위와 가정으로 다시 적어 팀에 공유한다.
- ✓이번 분기에 배울 기술 하나를 정하고 캘린더에 주 1회 60분 학습 블록을 넣는다.
- ✓가장 결합이 심하다고 느끼는 모듈 하나를 골라 단독 테스트가 가능한지 확인해 본다.
밑줄 그은 문장
“오늘의 방치는 내일의 기본값이 된다.”
이 책이 답하지 않는 것
개인과 소규모 팀의 작업 습관에 초점이 있어, 대규모 조직의 아키텍처 결정이나 마이크로서비스 운영 같은 문제는 다루지 않는다. 특정 언어의 구체적 구현법이나 최신 프레임워크 사용법을 기대한다면 맞지 않는다. 원칙 중심이라 자기 상황에 옮기는 해석은 독자 몫으로 남는다.
이 통찰의 근거가 궁금하다면?
원서·번역서 정보와 가격은 판매처에서 확인하세요.
※ 구매 링크는 제휴 활동의 일환이며, 이를 통해 일정액의 수수료를 제공받습니다. 구매자에게 추가 비용은 발생하지 않습니다.
비슷한 주제의 책
NEWSLETTER
매일 아침, 새로운 인사이트
하루의 시작을 도와줄 책 한 권의 핵심과 실천 과제를 보내드립니다.