- XP와 TDD의 아버지 켄트 벡의 Programnatic Engineer 인터뷰에서 내게 인상적이었던 몇 부분을 요약
- 켄트 벡 좋아하시는 분들은 풀버전 영상 시청 추천
Q. XP의 핵심이 무엇인가?
다음 4가지 활동을 하는 것이다.
- 무엇을 해야 할지 파악한다
- 1을 우리가 할 수 있게 만들어주는 구조를 파악한다
- 2를 이용해 1을 구현한다
- 3이 예상대로 동작하는지 확인한다
이게 전부다. 그리고 시간을 아주 잘개 쪼개서, 매 시간마다 4가지 활동을 조금씩, 그러나 모두 한다.
Q. 그러면 페어 프로그래밍은 XP에서 필수가 아닌 건가?
처음으로 XP 팀을 운영하던 시절, 3주에 한 번씩 배포했는데 당연히 버그가 있었음.
'배포 후 발견'된 버그들의 패턴을 분석해봤더니 그 모든 버그가 혼자서 개발한 코드에서 발생한 것들이었음. 거꾸로 말하면, 페어로 개발했던 코드에서는 운영 환경에서 리포트된 결함이 존재하지 않았음
Q. 그러면 필수는 아니고, 강력하게 추천한다는 정도?
그것도 아님. 실험하라는 것. 원래 개발하던 대로 개발해도 된다. 단, 깨어있는 상태로.
지속적 설계, 지속적 검증, 지속적 구현, 또는 고객과의 지속적 인터랙션, 그 무엇이든 간에 그에 대한 이득을 얻고 싶다? 그런데 맨날 하던 대로 하니까 안 된다? 그러면 방식을 바꿔야 함.
누가 나에게 찾아와 "켄트, 저는 TDD를 하지 않아요." 라고 하면 나는 이렇게 답한다. "어쩌라고?"
현재 본인 코드에서의 결함 밀도와 설계 의사결정에 대한 피드백 수준에 만족하고 있다면 상관없음. 하지만 만족하지 않는다면, 페어든 TDD든 시도해보라는 것.
Q. 말 나온 김에, TDD를 왜 만들었나?
나는 걱정이 많고 불안해하는 사람이고, 나에게 프로그래밍은 끊임없는 불안의 원천이었다. 내가 뭘 까먹었지? 내가 뭘 망가뜨렸지?
그런데 TDD로 개발하면 이 불안함이 사라짐. 실패할 만한 테스트 케이스가 더 생각나지 않는다? 그러면 내 프로그램이 동작함을 확신할 수 있다. 조금이라도 불안함이 생긴다? 그냥 다음 테스트 케이스를 작성하면 된다.
물론 결함 밀도 줄이기, 설계 의사결정에 대한 피드백 빨리 얻기, 구현 설계를 진화시키기 등 TDD의 기술적 이득도 많다. 하지만 프로그래밍에 대한 불안함으로부터 해방되었다는 것, 프로그래밍이 주는 감정적 경험이 완전히 전환되었다는 것. 이게 나에겐 가장 중요하다. 이게 내가 TDD를 만든 이유다.
Q. TDD를 하면 좋은 설계가 끼어들 틈이 없다는 John Ousterhout의 비판에 대해서는 어떻게 생각하나?
(역자 주: John Ousterhout는 명저 Philisophy of Software Design의 저자이며, 몇 달 전 Programmatic Engineer 팟캐스트에 나와 TDD에 대한 비판적 시각을 보여주기도 했습니다)
그가 오해한 면이 있다. 그건 그냥 의사결정의 결과다. 만약 TDD를 그저 Red-Green의 반복으로만 취급한다면 당연히 거기엔 설계가 끼어들 틈이 없다.
TDD 실천가로서 나는 항상 추상화의 수준을 오가며 작업한다. 예를 들어:
- 지금은 Red 상태다. 다음 테스트 케이스를 성공시키려면(Green) 어떻게 구현해야 하지?
- 뭔가 어렵네. 왜 어렵지?
- Green으로 만들기 위한 구현을 더 쉽게 만들려면 설계를 어떻게 바꿔야 하지?
- 그 아이디어를 언제 도입해야 할까? 지금인가, 나중인가?
- 지금 도입한다면 어느정도나? 당장 할 수 있는 만큼 조금만 할까, 더 큰 청크로 할까?
즉 테스트를 작성하기 전에, 나는 언제나 설계의 순간을 가진다.
구현하기 전에 인터페이스에 대한 의사결정을 내리고, Red 테스트를 만들고, 나는 Red 상태를 싫어하니까, 최대한 빠르게 Green으로 만든다. Green이 되고 나면 불안함이 잠시 사라지니 생각할 여유가 생긴다. '음, 통과하긴 했지만 이게 다른 케이스에서는 안 되겠군. 구현을 더 일반화해야겠다.'
Red인가? Green으로 만든다. Green인가? 한숨 돌리고 생각한다. 이게 나의 TDD 싸이클이다.
Q. 나는 구현이 너무 뻔하게 느껴져서, 구현을 먼저 한 다음에 Red-Green 테스트를 해볼 때가 있다. 이 방식에 대해 어떻게 생각하는가?
그건 '이 구현 방식이 옳다'는 가정을 하고 있기 때문일 것이고, 그 가정이 옳을수록 당연히 테스트를 먼저 작성하는 방식의 이점은 줄어든다.
그런데 나는 언제나 이렇게 생각한다. "나는 계속해서 학습하고 경험해나갈 것이고, 지금이 내가 가장 무식한 순간이다."
즉 나는 내가 계속 학습할 거라고 가정하며, 상황이 변할 거라고 가정한다. 내가 더 많이 배워야 하고 더 많이 상황이 바뀔수록, 나는 최대한 의사결정을 뒤로 미루길 원한다. 이건 일반적인 원칙이다. 데이트를 하든 요리를 하든 똑같다.
더 많이 예측할 수 있다면, 더 큰 점프를 뛸 수 있다. 근데 내가 프로그래밍하면서 가장 사랑하는 순간은, 내가 죄다 안다고 생각하고 쭉쭉 진행하고 있었는데 갑자기 훨씬 나은 구현 방식이 있었다는 걸 깨닫는 순간이다. 나는 이런 순간을 최대한 자주 경험하고 싶다. 그래서 나는 TDD를 한다.
머릿속에 그림이 확실히 그려지고, 어떤 입력이 어떤 출력을 만들지 확신할 수 있다면 그냥 구현하면 된다. 하지만 실수를 많이 할수록, 더 많이 학습할수록, 세상이 더 예측불허하게 변할수록, 지금 당장 약속하지 않고 나중으로 미루는 게 더 유리하다.
Q. AI와 함께 코딩하면서도 예전처럼 TDD로 개발하는가?
단순하게 대답하기 어렵다.
나는 AI와의 의사소통 수단으로써, 주로 AI가 뭘 잘못했는지 알려주는 수단으로써 테스트를 활용한다. 이녀석은 자꾸만 내 테스트를 삭제하고 수정하려고 하는데 그럴 때마다 혼낸다. 내 테스트가 맞으니 제대로 하라고.
AI는 장기적으로 좋지 않은 의사결정을 할 때가 많다. 결합도를 낮추고 응집도를 높이는 것도 정말 못한다. 굉장히 명확하게 할 일을 얘기해주면 해낼 때가 있지만, 일반적으로는 설계를 잘 못한다고 봐야 한다.
그래서 나는 테스트를 굉장히 많이 준비해둔다. 이걸 AI가 뭔가 때려부수고 있진 않은지 캐치하는 수단으로 사용한다.
(역자 주: Kent Beck이 바이브 코딩에 어떻게 TDD를 쓰는지는 이 글을 참조하세요)
Q. 테스트를 절대 고치지 마라, 테스트 통과 못하면 통과할 때까지 구현 코드만 수정해라, 같은 에이전트 룰이 대중화되면 더 편해질 것 같은데. 요즘이 2000년대에 중요했던 것들을 다시 발견하는 시기인 것 같기도 하다. 어떻게 생각하나?
계속 실험해야 한다. 가능한 모든 걸 시도해봐야 한다. 현재 뭐가 정말 최선인지 모르기 때문이다.
무엇이 '싸고' 무엇이 '비싼지'에 대한 지평이 완전히 달라졌다. 예전에 값비싸거나 어렵다고 여겨서 하지 않았던 많은 것들이 어이없을 정도로 싸졌다.
만약 자동차가 어느 날 갑자기 공짜가 된다면 어떻게 될 것 같은가? 당연히 뭔가 달라지겠지만, 그로 인한 2차적, 3차적 변화는 어떻게 될까? 아무도 예측할 수 없다. 그러니 지금은 그냥 여러가지를 시도해보는 수밖엔 없다.
Q. 50년 넘게 프로그래밍을 해왔지만 요즘이 가장 즐겁다고 했는데 무슨 뜻인가?
내 거대한 아이디어를 실현하는 게 그 어느 때보다도 쉬워졌다. 이 아이디어를 AI가 구현할 수 있을지, 어떻게 하면 구현할지 지켜보고 조정하는 게 굉장히 중독적이다. 언제 잘 될지 잘 모르고, 마법처럼 잘 될 때는 황홀하다는 면에서 슬롯머신과도 같다. 산책가거나 점심먹으러 가기 전에 이녀석을 놀게 하기 싫어서, 프롬프트 하나라도 쓰고 갈까 하는 욕망에 항상 사로잡힌다.
2년 전, 나는 "ChatGPT를 사용하는 것에 대한 저항감이 있었는데 왜 그런지 이해했다. 내가 가진 기술 중 90%는 이제 $0이 되었다. 그리고 나머지 10%는 1000배로 늘어났다. 내 기술을 재조정할 시기가 왔다." 라는 트윗을 남겼었다.
I've been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant.
The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.
-- Kent Beck 🌻 (@KentBeck) April 18, 2023
(역자 주: 당시 이 트윗이 화제가 되자 Kent가 조금 더 긴 글을 남기기도 했습니다.)
당시에는 90%가 뭐고 10%가 뭔지 아직 탐색 중이라고 했었는데 이제는 어느정도 대답할 수 있다. 담대한 비전을 가지고, 비전을 향하는 마일스톤을 설정할 수 있고, 설계를 계속 조정하며 전진하면서 복잡성을 통제하는 기술. 이게 특정 언어의 문법에 대한 지식(예: Rust에서 &, *, [를 어디에 넣어야 하는가)보다 훠어얼씬 중요한 기술이다.