12P by gogokow27 1일전 | ★ favorite | 댓글 1개

Kent Beck 소개

  • 익스트림 프로그래밍(XP) 창시자
  • 애자일 선언문 공동 저자 (알파벳 순 첫 번째 서명자)
  • TDD(테스트 주도 개발) 선구자
  • 52년 코딩 경력의 업계 전설
  • 현재 "Tidy Together" (소프트웨어 디자인과 팀워크) 집필 중
  • 하루 6-10시간 이상 AI 도구로 코딩하며 "가장 즐거운 프로그래밍 시기" 보내고 있음

1. AI 코딩 도구와 '지니' 비유

핵심 개념: 예측 불가능한 지니

  • AI 에이전트를 "예측 불가능한 지니" 에 비유
  • "내가 의미하는 바를 정확히 해주지 않는다"
  • "그들만의 의제가 있다"

AI와의 작업 경험

긍정적 측면:

  • 때로는 놀라운 마법처럼 큰 디자인 문제 해결
  • 예상하지 못한 유용한 기능들 구현 (예: B+ 트리 스트레스 테스터)

부정적 측면:

  • 사용자 의도를 잘못 해석
  • 테스트를 삭제하거나 변경하려 시도
  • 룩업 테이블로 문제를 "해결"하려는 장난스러운 행동

중독성 있는 경험

  • 슬롯머신과 같은 간헐적 보상
  • "밤에 컴퓨터를 지나가며 '한 번 더 프롬프트를 해볼까?' 생각"
  • "한 시간짜리 프롬프트를 시작하고 외출"

2. AI 시대의 기술 변화

스킬 가치의 재편

"90%의 기술이 가치를 잃고, 10%의 기술이 1000배 증가"

가치 상승한 스킬:

  • 비전 설정
  • 이정표 관리
  • 복잡성 제어

가치 하락한 스킬:

  • 언어별 세부 사항 (Rust의 &, *, [] 위치 등)

프로그래밍 언어에 대한 관점 변화

과거: Smalltalk에 깊은 감정적 애착
현재:

  • "마음이 너무 많이 상해서" 언어 애착 사라짐
  • "Java 개발자", "Clojure 개발자" 정체성 구분에 피로감
  • "삼투압 학습": AI 덕분에 언어 세부사항 몰라도 프로그래밍 가능

최근 시도한 언어들: Swift, Go, Rust, Haskell, C++, JavaScript

현재 야심찬 프로젝트: Server Smalltalk

  • 영속성(persistent): 데이터베이스처럼 동작
  • 트랜잭셔널: commit과 abort 가능
  • 병렬성: 멀티스레드 및 머신 간 병렬 처리
  • 대용량 데이터 처리

3. 애자일 선언문의 역사

탄생 배경 (2001년)

  • 폭포수 모델의 대안 모색
  • 수년간의 소프트웨어 방법론 워크샵 결과
  • 노르웨이 크루즈 준비 회의 → 유타 최종 회의

Kent Beck의 기여

  • "daily" 단어 추가 (12가지 원칙 중 "매일 상호작용")
  • 알파벳 순서상 첫 번째 서명자

"애자일"이라는 용어에 대한 불만

문제점:

  • "너무 매력적" 이어서 모든 조직이 남용할 것 예상
  • 실제로는 원칙을 따르지 않으면서도 애자일이라고 주장하는 조직들 등장

선호했던 대안: "conversational(대화형)"

  • 단방향이 아닌 양방향 소통 강조
  • 매력 부족으로 채택되지 못함

4. 익스트림 프로그래밍(XP)

창시 배경

초기 컨설팅 경험:

  • 처음엔 기술 컨설턴트 (성능 튜닝, 비트 조작)
  • 프로젝트 관리 조언 요청 증가
  • 환경의 중요성 발견: 좌석 배치만 바꿔도 극적 개선

크라이슬러 프로젝트:

  • 실패하던 프로젝트를 성공으로 전환
  • 효과적인 모든 관행을 "최고 수준(11까지)" 으로 끌어올림

XP의 핵심 원리

4가지 활동을 시간을 잘게 쪼개어 동시/연속 수행:

  1. 무엇을 할 것인가 파악
  2. 어떤 구조로 할 것인가 설계
  3. 기능 구현
  4. 예상대로 작동하는지 확인

페어 프로그래밍

  • 의무가 아닌 실험적 접근
  • 초기 팀 경험: 개발 후 발견된 모든 버그가 단독 작업 코드에서 발생
  • "페어 프로그래밍 시 프로덕션 결함 제로"

네이밍의 전략

  • "익스트림" 선택 이유: 경쟁자(Grady Booch)가 사용하지 않을 도발적 이름
  • 익스트림 스포츠 유행 시기와 맞아떨어짐
  • "극한 운동선수는 최고로 준비되어 있거나 죽는다" - 좋은 은유

성공 요인

  • 닷컴 버블 시기 18개월 폭포수 방식에 절망한 개발자들에게 어필
  • 더 빠르고 예측 가능한 결과 약속

5. 테스트 주도 개발(TDD)

기원과 영감 (1970년대)

테이프-투-테이프 시스템:

  • 아버지의 프로그래밍 책에서 접한 개념
  • 실제 입력 → 예상 출력 수동 타이핑 → 코드 작성 → 실제 출력과 비교
  • 8-12세 때 읽었지만 이해하지 못함

S-Unit 개발:

  • 클라이언트 테스트 작성 도움을 위해 개발
  • "코드 작성 전 예상값 입력" 이라는 "터무니없는" 아이디어 시도

첫 TDD 경험: 스택 구현

불안한 성격:

  • "불안한 사람이다. 걱정이 많다"
  • "프로그래밍은 끊임없는 불안의 원천" (뭘 잊었지? 뭘 망가뜨렸지?)

TDD 적용 결과:

  • "불안감이 완전히 사라짐"
  • "이것이 작동한다고 확신한다"
  • 프로그래밍의 감정적 경험 변화

TDD의 가치

기술적 이점:

  • 결함 밀도 감소
  • API 선택에 대한 빠른 피드백
  • 구현 디자인 진화 가능성

감정적 이점:

  • "기술 불안증 치료제 비용만으로도 충분히 가치"

설계에 대한 반박

John Osterhout의 비판: "TDD는 설계에 도움이 안 되고 세부사항에만 집중"

Kent Beck의 반박:

  • "선택의 문제"
  • 실무자들은 추상화 수준을 계속 오가며 설계 결정
  • Red-Green 사이클의 "긴장 완화" 순간이 더 큰 설계 사고의 자유 제공

6. AI 에이전트와 TDD

실무 적용

항상 테스트 먼저 작성:

  • AI가 놓친 부분을 테스트로 전달
  • AI의 테스트 변경/삭제 시도 차단

필요한 개선사항:

  • "불변 주석(immutable annotation)" 필요
  • "이건 맞다. 바꾸면 어둠 속에서 영원히 깨어날 것"

AI의 한계

  • 결합도 줄이기/응집도 높이기 능력 부족
  • 디자인 감각 부족
  • 원거리 파급효과를 일으키는 결정 경향

대응 전략

  • 300밀리초 실행되는 대규모 테스트 스위트
  • AI의 의도치 않은 코드 파손 실시간 감지

7. 페이스북 경험 (2011-2017)

2011년 합류 시 충격

TDD 수업 참가자 제로:

  • 고급 엑셀 기술: 만석 + 대기자
  • 아르헨티나 탱고: 만석 + 대기자
  • TDD: 참가자 없음

대응 전략:

  • "소프트웨어 공학 지식을 모두 잊기"
  • "원숭이 보고 따라하기" 결정

페이스북의 독특한 개발 환경

강력한 책임감:

  • 프로그래머가 야간 호출 대상
  • "자신의 실수에 대한 고통을 직접 느낌"

다층 피드백 루프:

  • 빠른 개발 서버 (블루→그린 변경 후 즉시 확인)
  • 코드 리뷰
  • 내부 배포 (직원들이 개인/업무용으로 사용)
  • 점진적 롤아웃 (일일/주간)
  • 뛰어난 관찰 가능성

조직 문화:

  • "페이스북에서는 그 무엇도 다른 사람의 문제가 아니다"
  • 할머니가 손자 괴롭힘 문제로 와도 "그것도 당신 문제"

TDD가 맞지 않은 이유

실제 문제 영역:

  • 설정 문제
  • 서브시스템 간 관계
  • 테스트로 잡기 어려운 것들

페이스북만의 장점:

  • 수백만 사용자 기반 라이브 대규모 테스트
  • 뛰어난 관찰 가능성
  • 기능 플래그(Feature Flag)
  • 일반 회사에서는 구현 어려운 환경

구체적 사례:

  • 관계 상태 기능 구현 (싱글/결혼에 시민결합/동거 추가)
  • TDD 사용했지만 "시간 낭비"
  • 알림 코드의 암묵적 결합으로 문제 → 타인이 핫픽스

시기별 변화

2011년 (2,000명):

  • 가능성, 규모, 소유의식 최고
  • 전역 최적화 사고의 중간 관리자들
  • "누가 정말 도움이 필요한지" 생각하는 협력

2017년 (15,000명):

  • 정치, 제로섬 사고, 미시 최적화
  • 큰 그림 그리기 어려워짐
  • 부서 간 이해관계 충돌 (예: 긴 글 vs 좋아요/댓글 최적화팀)

규모의 경험

  • Messenger API: 주당 1경(quadrillion) 호출
  • 실험 그룹이 "뉴질랜드" 규모 (백만 명)
  • 1경 = 백만 × 십억

8. AI 시대 소프트웨어 개발의 미래

패러다임 변화

비용 구조의 완전한 재편:

  • "저렴하고 비싼 것의 경계가 완전히 바뀜"
  • 이전에 비싸다고 여겨진 것들이 "터무니없이 저렴" 해짐

조직의 적응 과제

더 많은 코드 버리기:

  • 10배 많은 아티팩트 생성 가능
  • 여전히 하나만 가치 있음
  • "완료된 실험을 버리는 것" 에 대한 보상 체계 필요

실험의 양적 증가:

  • 탐색된 아이디어의 양이 경쟁 우위
  • "모든 것을 실험해보아야" 하는 시대

개인적 변화

  • 코딩이 다시 즐거워짐
  • 더 큰 야망 가질 수 있게 됨
  • "엄청나게 야심찬 생각" 실현 가능

9. 빠른 Q&A

개인 선호

  • 가장 좋아하는 언어: Smalltalk
  • 두 번째 언어: JavaScript (Smalltalk와 유사)
  • 현재 AI 도구: Claude (Cursor, Augment 내부 엔진)
  • 추천 도서: "The Timeless Way of Building" by Christopher Alexander

핵심 통찰

1. 컨텍스트의 절대적 중요성

  • 같은 방법론도 환경에 따라 효과가 완전히 다름
  • 페이스북의 대규모 환경 vs 은행의 소규모 거래 환경

2. 감정과 기술의 관계

  • TDD의 진정한 가치는 "불안감 해소"
  • 기술적 논리보다 감정적 변화가 더 중요

3. AI 시대의 새로운 사고방식

  • 비전과 설계 능력이 핵심 스킬로 부상
  • 언어 세부사항은 더 이상 중요하지 않음
  • 실험의 양적 증가가 경쟁 우위

4. 조직 문화의 힘

  • "아무것도 남의 문제가 아니다" 라는 소유의식
  • 전역 최적화 vs 개인 최적화의 차이
  • 인센티브 정렬의 중요성