XP, TDD, 그리고 바이브 코딩: Kent Beck의 Programmatic Engineer 인터뷰 일부 번역

저는 영상 요약 서비스를 거의 쓰지 않습니다.

텍스트만으로도 정보가 넘쳐나니 애초에 영상을 잘 안보기도 하고(집에 TV 없음, 유튜브는 중독 피하려고 로그아웃, 넷플릭스 가입 안 함), 또한 거장들의 Full 영상을 직접 집중해서 볼 때만 느낄 수 있는 통찰이 분명 존재한다고 믿기 때문입니다. 물론 다른 분들이 요약해준 건 감사하며 읽습니다. ㅎㅎ

얼마 전 보고 일요일에 또 본, XP(Extreme Programming)와 TDD(Test Driven Development)의 아버지 Kent Beck의 Programnatic Engineer 인터뷰에서도 중요한 통찰을 여럿 얻었습니다. NotebookLM으로 요약된 버전에서는 느끼지 못했던 것들이었죠.

흥미로운 이야기가 무척 많았지만 저는 특히 "XP와 TDD의 핵심이 무엇이고, 그걸 코딩 에이전트에게 어떻게 적용할 수 있는가"가 가장 좋았어요. 인상적이었던 몇 부분을 의역해봤습니다.

(개발 용어가 워낙 많이 나오고 번역도 없어서 누구에게나 권하긴 어렵습니다만, 켄트 벡을 좋아하시는 분들이라면 풀버전 시청을 추천드립니다)

Gergely Orosz가 질문하고 Kent Beck이 답하는 식으로 정리했습니다.

Q. XP의 핵심이 무엇인가?

다음 4가지 활동을 하는 것이다.

1. 무엇을 해야 할지 파악한다 (figuring out what to do)
2. 1을 우리가 할 수 있게 만들어주는 구조를 파악한다 (figuring out the structure will let us do it)
3. 2를 이용해 1을 구현한다 (implementing the features)
4. 3이 예상대로 동작하는지 확인한다 (making sure they work as expected)

이게 전부다. 그리고 시간을 아주 잘개 쪼개서, 매 시간마다 4가지 활동을 조금씩, 그러나 모두 한다. (Slice time really fine, and do little bit of all those activities in every slice)

(역자 주: 켄트 벡이 4가지 활동을 손가락 4개로 표현하고, 눕혀서 위아래로 쪼개는 걸 시각화해서 보여주는 게 아주 인상적이었습니다. 그리고 이 활동 모두는 AI와 함께 코딩할 때에도 굉장히 중요한 것들이죠.)

Q. 그러면 페어 프로그래밍은 XP에서 필수가 아닌 건가?

그건 잘못된 생각이다.

스토리 하나를 들려주겠다. 처음으로 XP 팀을 운영하던 시절, 우리는 자연스럽게 페어 프로그래밍을 했다. 당시 3주에 한 번씩 배포했는데 당연히 버그가 있었다.

그런데, 배포 후 발견된 버그들의 패턴을 분석해봤더니 그 모든 버그가 혼자서 개발한 코드에서 발생한 것들이었다. 거꾸로 말하면, 페어로 개발했던 코드에서는 운영 환경에서 리포트된 결함이 존재하지 않았다.

Q. 그러면 필수는 아니고, 강력하게 추천한다는 정도?

그것도 아니다. 실험하라는 거다. 원래 개발하던 대로 개발해도 된다. 단, 깨어있는 상태로.

지속적 설계, 지속적 검증, 지속적 구현, 또는 고객과의 지속적 인터랙션, 그 무엇이든 간에 그에 대한 이득을 얻고 싶다? 그런데 맨날 하던 대로 하니까 안 된다? 그러면 방식을 바꿔야지.

누가 나에게 찾아와 "켄트, 저는 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으로 만들기 위한 구현을 더 쉽게 만들려면 설계를 어떻게 바꿔야 하지?
• 그 아이디어를 언제 도입해야 할까? 지금인가, 나중인가?
• 지금 도입한다면 어느정도나? 당장 할 수 있는 만큼 조금만 할까, 더 큰 청크로 할까?

즉 테스트를 작성하기 전에, 나는 언제나 설계의 순간을 가진다. 이 기능을 위한 API가 어떤 의미를 가져야 하는가?

구현하기 전에 인터페이스에 대한 의사결정을 내리고, Red 테스트를 만들고, 나는 Red 상태를 싫어하니까, 최대한 빠르게 Green으로 만든다. Green이 되고 나면 불안함이 잠시 사라지니 생각할 여유가 생긴다. '음, 통과하긴 했지만 이게 다른 케이스에서는 안 되겠군. 구현을 더 일반화해야겠다.'

Red인가? Green으로 만든다. Green인가? 한숨 돌리고 생각한다. 이게 나의 TDD 싸이클이다.

Q. 나는 구현이 너무 뻔하게 느껴져서, 구현을 먼저 한 다음에 Red-Green 테스트를 해볼 때가 있다. 이 방식에 대해 어떻게 생각하는가?

그건 '이 구현 방식이 옳다'는 가정을 하고 있기 때문일 것이고, 그 가정이 옳을수록 당연히 테스트를 먼저 작성하는 방식의 이점은 줄어든다.

그런데 나는 언제나 이렇게 생각한다. "나는 계속해서 학습하고 경험해나갈 것이고, 지금이 내가 가장 무식한 순간이다."

즉 나는 내가 계속 학습할 거라고 가정하며, 상황이 변할 거라고 가정한다. 내가 더 많이 배워야 하고 더 많이 상황이 바뀔수록, 나는 최대한 의사결정을 뒤로 미루길 원한다. 이건 일반적인 원칙이다. 데이트를 하든 요리를 하든 똑같다.

더 많이 예측할 수 있다면, 더 큰 점프를 뛸 수 있다. 근데 내가 프로그래밍하면서 가장 사랑하는 순간은, 내가 죄다 안다고 생각하고 쭉쭉 진행하고 있었는데 갑자기 훨씬 나은 구현 방식이 있었다는 걸 깨닫는 순간이다. 나는 이런 순간을 최대한 자주 경험하고 싶다. 그래서 나는 TDD를 한다.

머릿속에 그림이 확실히 그려지고, 어떤 입력이 어떤 출력을 만들지 확신할 수 있다면 그냥 구현하면 된다. 하지만 실수를 많이 할수록, 더 많이 학습할수록, 세상이 더 예측불허하게 변할수록, 지금 당장 약속하지 않고 나중으로 미루는 게 더 유리하다.

Q. AI와 함께 코딩하면서도 예전처럼 TDD로 개발하는가?

단순하게 대답하기 어렵다.

나는 AI와의 의사소통 수단으로써, 주로 AI가 뭘 잘못했는지 알려주는 수단으로써 테스트를 활용한다. 이녀석은 자꾸만 내 테스트를 삭제하고 수정하려고 하는데 그럴 때마다 혼낸다. 내 테스트가 맞으니 제대로 하라고.

AI는 장기적으로 좋지 않은 의사결정을 할 때가 많다. 결합도를 낮추고 응집도를 높이는 것도 정말 못한다. 굉장히 명확하게 할 일을 얘기해주면 해낼 때가 있지만, 일반적으로는 설계를 잘 못한다고 봐야 한다.

그래서 나는 테스트를 굉장히 많이 준비해둔다. 이걸 AI가 뭔가 때려부수고 있진 않은지 캐치하는 수단으로 사용한다.

(역자 주: Kent Beck이 바이브 코딩에 어떻게 TDD를 쓰는지는 아래 글을 참조하세요)

AI가 잘못하고 있다는 3가지 신호 + TDD를 돕는 시스템 프롬프트 by 켄트 벡 (feat. 증강형 코딩)

켄트 벡이 바이브 코딩을 넘어 증강형 코딩을 체험하며 느낀 점들을 공유합니다.

Steady Study배휘동

Q. 테스트를 절대 고치지 마라, 테스트 통과 못하면 통과할 때까지 구현 코드만 수정해라, 같은 에이전트 룰이 대중화되면 더 편해질 것 같은데. 요즘이 2000년대에 중요했던 것들을 다시 발견하는 시기인 것 같기도 하다. 어떻게 생각하나?

계속 실험해야 한다. 가능한 모든 걸 시도해봐야 한다. 현재 뭐가 정말 최선인지 모르기 때문이다.

무엇이 '싸고' 무엇이 '비싼지'에 대한 지평이 완전히 달라졌다. 예전에 값비싸거나 어렵다고 여겨서 하지 않았던 많은 것들이 어이없을 정도로 싸졌다.

만약 자동차가 어느 날 갑자기 공짜가 된다면 어떻게 될 것 같은가? 당연히 뭔가 달라지겠지만, 그로 인한 2차적, 3차적 변화는 어떻게 될까? 아무도 예측할 수 없다. 그러니 지금은 그냥 여러가지를 시도해보는 수밖엔 없다.

Q. 50년 넘게 프로그래밍을 해왔지만 요즘이 가장 즐겁다고 했는데 무슨 뜻인가?

내 거대한 아이디어를 실현하는 게 그 어느 때보다도 쉬워졌다. 이 아이디어를 AI가 구현할 수 있을지, 어떻게 하면 구현할지 지켜보고 조정하는 게 굉장히 중독적이다. 언제 잘 될지 잘 모르고, 마법처럼 잘 될 때는 황홀하다는 면에서 슬롯머신과도 같다. 산책가거나 점심먹으러 가기 전에 이녀석을 놀게 하기 싫어서, 프롬프트 하나라도 쓰고 갈까 하는 욕망에 항상 사로잡힌다.

2년 전, 나는 "ChatGPT를 사용하는 것에 대한 저항감이 있었는데 왜 그런지 이해했다. 내가 가진 기술 중 90%는 이제 $0이 되었다. 그리고 나머지 10%는 1000배로 늘어났다. 내 기술을 재조정할 시기가 왔다." 라는 트윗을 남겼었다.

(역자 주: 당시 이 트윗이 화제가 되자 Kent가 조금 더 긴 글을 남기기도 했습니다.)

당시에는 90%가 뭐고 10%가 뭔지 아직 탐색 중이라고 했었는데 이제는 어느정도 대답할 수 있다. 담대한 비전을 가지고, 비전을 향하는 마일스톤을 설정할 수 있고, 설계를 계속 조정하며 전진하면서 복잡성을 통제하는 기술. 이게 특정 언어의 문법에 대한 지식(예: Rust에서 &, *, [를 어디에 넣어야 하는가)보다 훠어얼씬 중요한 기술이다.