1. 누구인가
Gerald M. Weinberg (1933 ~ 2018). 미국의 컴퓨터 과학자, 저술가, 컨설턴트, 교사. 친근하게 Jerry라 불렸다.
// 커리어
1950s 후반 → IBM 입사, 초기 메인프레임 시대의 프로그래머
1960s 초반 → NASA Project Mercury 작업
(미국 최초 유인 우주선, 운영체제/추적 시스템 쪽)
1960s 후반 → 독립 컨설턴트로 전향
1971 → 『The Psychology of Computer Programming』 출간
인생 노선이 "소프트웨어 사회학자"로 굳어짐
1970s~2018 → 50년에 걸쳐 50권 이상의 저서, 수많은 워크숍·강연
주요 워크숍: PSL (Problem Solving Leadership),
AYE (Amplifying Your Effectiveness)2. 시대적 맥락
1971년의 소프트웨어 업계 분위기는 다음과 같았다고 한다.
- 프로그래밍은 수학적·논리적 활동으로만 다뤄지던 시기
- 코드 품질 = 알고리즘 효율, 정확성. 사람·팀·커뮤니케이션은 거의 논의되지 않음
- 1968년 NATO 컨퍼런스에서 "Software Crisis"라는 단어가 처음 등장
- Fred Brooks의 『The Mythical Man-Month』는 1975년에서야 나옴
이런 분위기에서 Weinberg는 1971년에 프로그래밍은 본질적으로 사람의 활동이다 라는 주장을 책 한 권 분량으로 풀어낸다. 지금 들으면 당연해 보이지만 당시엔 업계에서 꽤나 도발적이었다고 한다. 그가 던진 질문 예시는 다음과 같은데,
- 코드 리뷰는 왜 사람과 사람 사이의 일인가
- 왜 어떤 팀은 같은 인원으로 더 많이 만들고, 어떤 팀은 그렇지 못한가
- 프로그래머의 자아(ego)는 코드 품질에 어떻게 영향을 주는가
이 질문들이 이후 Peopleware, Extreme Programming, Agile 같은 흐름의 정신적 기원이 된다.
3. 핵심 사상
3-1. Egoless Programming
가장 자주 인용되는 그의 개념이지만, 단순히 코드 비판에 상처받지 말자 같은 자기계발 슬로건이 아닌, 찰에서 출발한 주장이다.
자기 코드와 자아를 동일시하는 프로그래머는 자기 코드에서 버그를 못 본다.
Psychology of Computer Programming에서 그는 코드 리뷰 사례들을 인용하며, 자기 코드를 내 것으로 보지 않는 사람일수록 결함을 더 잘 잡아낸다고 정리한다. 그래서 그의 처방도 실용적이다.
- 작성자/리뷰어 모두에게 이건 우리 코드라는 1인칭 복수 프레임을 만들 것
- 리뷰 코멘트는 사람이 아닌 코드에 대한 진술로 적을 것
- 팀이 함께 표준을 정해두면 내 스타일 vs 네 스타일 충돌이 줄어듦
오늘날의 PR 리뷰 문화, 페어 프로그래밍, blameless postmortem 같은 개념의 직접적인 뿌리디.
3-2. 소프트웨어 = Sociotechnical System
Weinberg가 평생 반복한 주장은 짧게 말하면 이거다.
기술 문제처럼 보이는 것의 대부분은 사람 문제다. 사람 문제처럼 보이는 것의 대부분은 시스템 문제다.
여기서 시스템은 "사람 + 도구 + 조직 + 일하는 방식"의 묶음이다.
- 코드 품질을 올리려면 코드만 손대지 말고, 코드가 만들어지는 환경(리뷰 프로세스, 회의 구조, 인센티브)을 같이 봐야 한다
- 한 사람의 영웅적 노력보다 시스템의 작은 구조 변경이 더 큰 효과를 낸다
3-3. General Systems Thinking
An Introduction to General Systems Thinking에서 그는 시스템을 다루기 위한 휴리스틱을 모은다. 몇 개만 꼽으면,
- Composition Law - 부분의 합은 전체가 아니다 (부분들 사이의 관계가 시스템의 본질)
- Decomposition Law - 전체는 부분으로만 환원되지 않는다
- Square Law of Computation - 나이브하게 짜면 계산량은 입력 크기의 제곱으로 늘어난다 (왜 알고리즘을 신경 써야 하는지에 대한 시스템적 답)
핵심 메시지는 문제를 부분의 합이 아니라 부분들의 관계로 보라는 것이다. 디버깅, 아키텍처, 조직 설계 어디에든 적용되는 메타 도구로 자주 인용된다.
3-4. Satir Change Model in Software
Weinberg는 가족 치료 분야의 심리학자 Virginia Satir에게서 변화 모델을 빌려와 소프트웨어 조직 맥락에 옮긴다. 5단계 모델은 다음과 같다.
1) Late Status Quo - 익숙한 옛 방식, 슬슬 한계가 보임
2) Foreign Element - 새로운 무언가가 들어옴 (도구·사람·사건)
3) Chaos - 익숙한 패턴이 안 먹히고 성과가 일시 하락
4) Transforming Idea - 새 방식을 이해하는 결정적 인사이트
5) New Status Quo - 새 패턴이 익숙해지고 안정화새 도구나 프로세스 도입 시 일시적으로 생산성이 떨어지는 구간(3단계 Chaos)을 실패가 아니라 변화의 정상 과정으로 보게 해주는 프레임이다. 후일 애자일 코치들이 자주 가져다 쓴다.
3-5. Rule of Three
Secrets of Consulting에서 가장 유명한 한 줄이다.
계획에서 잘못될 수 있는 일 세 가지를 떠올리지 못한다면, 그 계획보다 당신의 사고에 문제가 있다.
같은 책의 형제 룰은 다음과 같다.
- 세 가지 해석 - 어떤 데이터든 최소 세 가지 해석을 떠올려보라. 첫 번째 해석이 보통 가장 그럴듯해 보이지만, 그래서 가장 위험하다
- 세 가지 가능성 - 누군가의 행동이 이해 안 갈 때, 그가 그렇게 행동할 수 있는 이유 세 가지를 떠올려본다
4. 『Secrets of Consulting』의 여러 법칙들
-
Law of Raspberry Jam
영향력은 잼과 같다. 넓게 펴 바를수록 얇아진다. → 모두를 도우려고 하면 아무도 제대로 못 돕는다. 컨설팅·코칭의 범위 설정에서 자주 인용
-
Marvin's First Great Secret of Consulting
클라이언트가 무슨 말을 하든, 거기엔 항상 문제가 있다. → 표면 요구사항과 실제 문제는 거의 항상 다르다는 환기. 제품팀의 사용자 인터뷰에도 그대로 적용
-
Rudy's Rutabaga Rule
1번 문제를 해결하면, 2번이 승진해서 새 1번이 된다. → 끝없는 문제 사이클에 대한 정직한 인정. "우선순위"는 영원하지 않다는 리마인더
-
The Hard Law
그들이 당신을 고용하지 않았다면, 그들의 문제를 풀려 들지 마라. → 부탁받지 않은 도움의 위험성. 코드 리뷰 외 영역으로 코멘트가 새어나갈 때 자주 떠올리게 됨
5. 가볍게 시도해 볼만한 것
1) 1인칭 복수 프레임 적용
[Before] 너 여기 왜 이렇게 짰어?
[After] 여기 이 분기, 이런 입력이 들어오면 어떻게 동작하면 좋을까요?- 사람을 가리키는 대명사("너", "이 사람")가 없는가
- "왜"보다 "어떻게 / 무엇을"이 더 많이 쓰였는가
- 리뷰 후 같은 사람과 다음 작업을 같이 하고 싶은가
2) 진행 중인 작업에 Rule of Three 적용
지금 잡고 있는 작업 하나를 고른다. 잘못될 수 있는 일 세 가지를 적어본다. 세 개가 잘 안 떠오르면, 그 자체가 신호다.
[작업] 새 기능 X 배포
1) 데이터 마이그레이션이 실패하면 롤백은 가능한가? 시간은?
2) 이 기능을 우회 경로로 쓰던 기존 사용자에게 어떤 부수 효과가 생기나?
3) 트래픽 피크 시간대에 대한 부하 시뮬레이션은 해봤나?세 가지가 너무 쉽게 나오면 더 깊은 세 가지를 다시 떠올려보고, 안 떠오르면 계획 자체를 다시 검토한다.