계획할 것인가, 말 것인가

요약 워드 커닝햄이 빌 베너스와 함께 화이트보드 대신 프로그래밍 언어를 사용하여 아이디어를 설계하고 소통하는 방법에 대해 이야기합니다.

소프트웨어 업계에서 워드 커닝햄은 아이디어의 원천으로 명성이 높습니다. 그는 객체 발견을 돕는 기법인 CRC 카드를 고안했습니다. 또한 소프트웨어 패턴의 발견과 문서화를 돕기 위해 웹 기반 협업 저작 도구인 위키(Wiki)를 세계 최초로 발명했습니다. 가장 최근에는 익스트림 프로그래밍(Extreme Programming, XP)의 여러 기법에 주된 영감을 준 인물로 꼽힙니다.

2003년 9월 23일, 빌 베너스는 덴마크 오르후스에서 열린 JAOO 컨퍼런스에서 워드 커닝햄을 만났습니다. Artima.com에 여러 편에 걸쳐 연재되는 이 인터뷰에서 커닝햄은 위키와 익스트림 프로그래밍의 여러 측면에 대한 통찰을 제공합니다.

[제1부: 위키를 이용한 탐험]에서 커닝햄은 협업 탐험을 위한 위키 사용과 위키 작성자와 독자 간의 균형(tradeoff)에 대해 논의합니다.

[제2부: 코드와 텍스트의 공동 소유]에서 커닝햄은 어떻게 위키를 코드 공동 소유의 모델로 설계했는지, 소유권에 대한 자부심을 위한 공동의 인센티브, 그리고 실수를 저지르는 비용을 제거함으로써 의견 충돌을 다루는 법에 대해 이야기합니다.

[제3부: 프로그램을 다듬기(Working the Program)]에서 커닝햄은 변경 비용 곡선의 평탄화, 미래 예측의 문제점, 그리고 예술가의 손에 들린 점토로서의 프로그램에 대해 논의합니다.

이 네 번째 편에서 커닝햄은 화이트보드 대신 프로그래밍 언어를 사용하여 아이디어를 설계하고 소통하는 것에 대해 이야기합니다.

익스트림 프로그래밍의 '익스트림(극한)'에 대하여 빌 베너스: 켄트 벡(Kent Beck)은 그의 저서 Extreme Programming Explained에서 이렇게 썼습니다. "전통적으로 우리는 미래를 위해 계획하고 재사용을 위해 설계하라고 배운다. 대신 XP는 오늘의 일을 오늘 해결하는 데 충실하고(테스트, 리팩터링, 소통), 미래에 복잡함이 필요할 때 그것을 추가할 수 있는 자신의 능력을 신뢰하라고 말한다." 실제로 제 경험상 미래를 예측하기란 어렵습니다. 단지 미래 예측이 어려워서가 아니라 문제 전체를 이해하는 것이 어렵기 때문입니다. 초기에는 무엇을 설계해야 할지 알 만큼 문제를 충분히 이해하지 못합니다. 코드를 구현하면서 문제 공간(problem space)에 대해 많은 것을 발견하게 되죠. 코딩은 마치 공간을 탐험하는 것과 같습니다. 코딩을 통해 탐험하면서 문제 공간에 대한 더 상세한 정보를 계속 발견하게 됩니다.

하지만 미래에 무엇이 필요할지에 대한 제 직관이나 경험을 전혀 신뢰하지 말라는 것은 좀 극단적(extreme)으로 느껴집니다. 예를 들어, 프로젝트 시작 시점에는 당장 데이터베이스가 필요 없을 수도 있습니다. 그냥 플랫 파일(flat file)을 쓸 수도 있죠. 하지만 제 경험과 직관은 결국 데이터베이스가 필요하게 될 가능성이 아주 높다고 말해줍니다. 익스트림 프로그래밍이 왜 익스트림 프로그래밍이라고 불리는지 확실친 않지만, 오늘 당장 필요하지 않으면 절대 구현하지 말라는 조언을 포함해서 그 어조가 다소 극단적이라고 느껴집니다. 실제로는 어느 정도까지 전적으로 "오늘의 일을 오늘 해결"해야 할까요? 그 조언을 어느 정도의 극한(extreme)까지 받아들여야 할까요?

워드 커닝햄: 솔직히 말해서, 이 모든 것에 대한 켄트 벡의 기여는 그와 제가 조용히 함께 발견했거나 다른 프로그래머들에게서 얻은 것들을 가져다가 극한까지 밀어붙인(taking it to the limit) 데 있다고 생각합니다. 극한까지 밀어붙이는 것이죠. 그리고 그것을 극한까지 밀어붙였을 때 실제로 말이 되고, 심지어 많은 부분이 개선된다는 사실이 바로 그것이 자연스럽게 "익스트림"이라고 불려야 하는 이유입니다. 켄트의 가장 큰 기여는 "이것만이 중요한 전부이며, 우리는 항상 이렇게 해야 한다"라고 말할 수 있을 만큼 대담했다는 점입니다.

훗날 역사가 익스트림 프로그래밍을 되돌아볼 때, 사람들은 아마 켄트가 몰랐던 13번째 실천 방법이 있었다거나, 어떤 실천 방법은 80%의 시간만 수행했어야 했다는 것을 발견할지도 모릅니다. 하지만 XP는 정답에 매우 근접해 있으며, 이는 놀라울 정도입니다. 이러한 실천 방법들을 극한으로 수행했을 때 직관에 반하는 일체감이 생긴다는 것은 정말 놀라운 일입니다.

내일 일은 내일 생각하기 빌 베너스: 특히 얼마나 앞을 내다봐야 하는지에 대한 질문을 살펴봅시다. 비유를 하나 들어보죠. 묘하게도 제가 테스트 주도 개발(Test-Driven Development)을 처음 접했을 때, 그랜마 모지스(Grandma Moses, 미국의 민속 화가)가 떠올랐습니다. 어릴 때 저는 플로라 옌테스라는 선생님께 유화를 배웠습니다. 선생님은 먼저 목탄으로 밑그림을 그리고, 그 위에 황토색(yellow ochre)을 칠하라고 가르치셨습니다. 그게 마르면 목탄을 문질러 지우고 황토색 물감으로 된 윤곽선만 남깁니다. 그 후 얇은 물감으로 넓게 붓질을 하는 '워시(wash)' 기법으로 전반적인 색과 형태를 잡게 하셨죠. 마지막으로 워시가 마르면 세부 묘사를 했습니다.

하지만 그랜마 모지스는 그렇게 그리지 않았습니다. 그녀는 말했죠. "나는 위에서부터 아래로 그립니다. 먼저 하늘, 그다음 산, 그다음 언덕, 그다음 집, 그리고 소, 그리고 사람들을 그리지요." 그녀는 전체 그림을 스케치하고 세부를 채워 넣는 식 이 아니었습니다. 캔버스 한구석에서 시작해서 점진적으로 세부를 그리며 캔버스를 가로질러 나갔죠. 테스트 주도 개발은 그랜마 모지스의 화풍을 떠올리게 합니다. 사전 설계로 큰 그림을 먼저 잡는 대신, 저는 그저 첫 번째 기능 하나만 봅니다. 테스트를 작성하고 코드를 구현합니다. 그러고 나서 다음 기능을 보고, 테스트를 쓰고, 코드를 구현하고, 리팩터링합니다. 이 과정을 반복하며 캔버스를 채워 나갑니다.

저는 몇몇 프로젝트에서 엄격한 테스트 주도 방식을 사용해 봤고, 결과는 좋았습니다. 하지만 저는 여전히 코딩 전에 미리 큰 그림을 그리는 사고를 하는 것을 좋아합니다. 그렇다면 실제로는 앞을 내다보지 말라는 XP의 조언을 어느 정도까지 따라야 할까요?

워드 커닝햄: 론 제프리스(Ron Jeffries)를 완전히 변화시킨 계기가 바로 이겁니다. 론은 온갖 종류의 프로그램을 다 짜봤기 때문에 자신이 얼마나 많이 아는지 알고 있었습니다. 그는 XP의 독단적인 광신도인데, 그 이유는 의식적으로 내일을 생각하지 않음으로써 실제로 더 나은 코드를 생산할 수 있다는 것을 발견했기 때문입니다. 그가 아는 것을 잊어버린다는 뜻이 아닙니다. 내일은 곧 오니까요. 그리고 내일이 되면 그는 "자, 이제 이걸 할 때가 됐군."이라고 말할 것입니다. 그는 "지금까지 프로젝트에서 배운 모든 것과 이 프로젝트 전에 알고 있던 모든 것을 가지고 오늘 결정을 내릴 거야. 마침내 오늘이 왔으니까."라고 말하겠죠.

내일을 걱정하는 것은 오늘 당신의 일에서 주의를 뺏는 것입니다. 내일에 대해 생각하며 보내는 시간은 오늘 무엇을 할지 생각하는 데 쓰지 못하는 시간입니다. 내일 필요할 것 같아서 코드에 남겨둔 자리는 사실 오늘의 시간 낭비이자 내일의 부채(liability)입니다. 득보다 실이 많죠.

그렇다고 생각하지 말라는 뜻은 아닙니다. 모든 것이 펼쳐져 있기 때문에 내일 생각할 수 있는 아름다운 기회가 있다는 것을 알게 될 것입니다. 내일, 당신이 가진 경험을 정말로 사용해야 할 그 시점에 도달했을 때, 구체적인 상황들이 바로 눈앞에 있다는 것을 알게 됩니다. 코드베이스는 당신이 막 작성하려는 것을 받아들일 준비가 되어 있습니다. 어디선가 변경이 필요하다면, 당신에게는 변경할 권한이 있습니다. 그리고 하루가 끝날 때쯤 당신은 그 지식을 적용한 결실을 보게 될 것입니다.

프로그램은 컴퓨터의 도움 없이 이야기를 풀어내야 하는 오늘보다 내일, 당신의 지혜를 훨씬 더 잘 받아들일 것입니다. 다시 말해, 제가 화이트보드로 가서 "내 생각엔 이게 필요할 것 같고, 이 정도면 충분해"라고 말하는 것보다, 프로젝트에 계속 머물면서 매일매일 프로그래밍하는 것이 제 경험을 설계에 녹여내는 데 더 도움이 됩니다. 프로그래밍 언어는 제 경험의 가치 있는 모든 조각을 설계에 담아내기에 화이트보드보다 더 나은 언어입니다.

빌 베너스: 프로그래밍 언어가요?

워드 커닝햄: 네, 프로그래밍 언어가요. 아니면 우리가 만든 언어나 설정 파일, 버튼의 순서 등 우리가 만드는 그 무엇이든 말이죠.

빌 베너스: 결과물(Artifact) 말이군요.

워드 커닝햄: 맞아요. 많은 사람이 통제 불능 상태가 된 프로그램을 경험해 봤을 겁니다. 아이디어가 있고 무엇을 하고 싶은지 안다고 생각하죠. 하지만 막상 그 아이디어를 넣으려다 보면, 어떻게 넣을지 알아낼 때쯤엔 아이디어를 잊어버립니다. 그들은 "이걸 하려고 할 때마다 쥐구멍으로 들어가는 것 같아(미궁에 빠지는 것 같아). 여기에 넣을 수는 있는데, 그러려면 이걸 바꿔야 하고, 저걸 바꾸려면 또 다른 걸 바꿔야 하고..."라고 말합니다. 혹은 시도했다가 그냥 터져버리죠. 바꾸기가 너무 어려운 겁니다. 프로그램이 매우 깨지기 쉬운(brittle) 상태죠. 그런 환경에서 사람들은 생각합니다. "신이시여, 다시는 이러고 싶지 않아요. 내 아이디어를 꺼내고 싶어요. 그냥 종이에 내 아이디어를 쓰고 저 쓰레기 같은 작업은 다른 사람한테 시킬래요." 하지만 그건 덜 효과적입니다. 당신이 정말 예리하고 경험이 많다면, 프로그램이 그렇게 깨지기 쉬운 상태가 되지 않도록 하는 것에 동의함으로써 그 경험을 훨씬 쉽게 발휘할 수 있습니다.

마음의 리팩터링 (Refactoring the Mind) 빌 베너스: 최근 비행기에서 기네스 팰트로와 아론 에크하트가 두 문학자 역을 맡은 포제션(Possession)이라는 영화를 봤습니다. 그들은 빅토리아 시대의 한 시인과 그의 숨겨진 연인이 주고받은 편지를 발견하고 소리 내어 읽습니다. 편지들이 너무나 아름답게 쓰여 있어서, 기술이 우리 마음에 미치는 영향에 대해 생각하게 되더군요. 18, 19세기 편지는 이메일 같지 않습니다. 현대의 편지 같지도 않죠. 현대의 서신보다 훨씬 풍부하고 사색적으로 들립니다.

글쓰기 이전 시대의 사람들은 기억력을 더 많이 사용해야 했습니다. 연습을 더 많이 했기 때문에 아마 우리보다 기억력이 좋았을 겁니다. 19세기, 만년필이 나오기 전 사람들은 잉크를 찍어 쓰는 깃펜으로 편지를 썼습니다. 페이지 아래쪽에서 실수하면 페이지 전체를 다시 써야 했죠. 그래서 백스페이스 키가 있는 시대의 사람들보다 글을 쓰기 전에 훨씬 더 많이 생각했을 겁니다. 그 당시 사람들은 종이에 옮기기 전에 머릿속으로 텍스트를 더 많이 계획하고 더 많이 담아두었죠. 저는 그런 연습이 그들이 그런 종류의 사고(thought)를 잘하게 만들었을 거라 상상합니다.

사전 계획보다 리팩터링을 강조하는 익스트림 프로그래밍은 현재의 우리 기술 맥락을 벗어나면 거의 말이 안 됩니다. 우리에겐 백스페이스 키와 텍스트를 선택할 수 있는 기능이 있습니다. 몇 번의 키보드 조작으로 텍스트를 복사하고, 지우고, 복제하고, 이동할 수 있습니다. 또한 기존 코드를 변경하는 것을 도와주는 스크립트 언어와 리팩터링 IDE도 있습니다. 이런 기술들은 우리에게 힘을 실어주지만(empowering), 대가는 없을까요? 미리 앞을 내다보고 생각할 필요가 없기 때문에, 우리는 앞을 내다보는 사고를 덜 연습하게 될 것입니다. 우리의 앞을 내다보는 사고 능력이 퇴보할까요?

워드 커닝햄: 우리가 다르게 생각하고 있는 것일 수도 있습니다. 그 차이가 더 나은지 나쁜지를 말하는 것은 훨씬 더 큰 그림을 봐야 하는 가치 판단의 문제겠죠. 저는 예전에 편지 쓰는 법을 배우려면 일단 편지를 쓰기 시작하라는 말을 들었습니다. 실수를 하면 페이지를 치워두고 다시 쓰기 시작합니다. 좀 더 쓰다가 또 실수를 하면 다시 시작합니다. 결국에는 편지를 다 쓰게 되죠. 일주일 동안 이렇게 하면, 단어를 생산하는 방식에 대한 사고방식이 바뀌어 문장 전체, 문단 전체가 펜에서 술술 흘러나오는 경지에 이르게 됩니다. 아무도 "페이지에 대한 마스터플랜을 짜라. 어떤 문단이 무엇을 할지 파악해라."라고 말하지 않습니다. 그것은 이미 그런 일을 하는 마음속의 기제를 여는 과정에 가깝습니다. 그것을 연습하는 방법은 편지를 쓰고, 실수하면 다시 쓰고 또 쓰는 것입니다. 이것은 본질적으로 인간적인 어떤 능력을 숙달해가는 점진적인 접근법입니다. 제가 지금 대화 중에 단어들을 쏟아내는 것도 바로 그 기제를 사용하고 있는 것입니다.

XP에서 우리는 한 그룹의 사람들이 고성능 팀으로서 함께 일하려면, 개인이 머릿속 한구석에서 관리할 수 있는 정보를 화면에 띄워야 한다고 말합니다. 정보가 개인의 마음에서 나와 화면에 나타나면, 그것은 우리의 집단적 사용(collective use)의 대상이 됩니다. 그리고 짝 프로그래밍(pair programming)을 하면 꽤 효율적입니다. 옆에 앉아 있으면 단서가 충분하니까요. 짝 프로그래밍은 혼자 프로그래밍할 때 머릿속 뒷편에서 일어날 수 있는 창조의 행위를 가져와서 볼 수 있는 화면에 올려놓습니다. 볼 수 있기 때문에 공유할 수 있습니다. 공유할 수 있기 때문에 확대 효과를 얻습니다. 생각하는 방법에 대한 기술(technique)이 조직 전체로 흐르게 되는데, 그렇지 않았다면 흐르지 않았을 것입니다.

활동의 대부분이 화면에서 일어나도록 고집함으로써, 우리는 개인의 활동을 집단적인 활동으로 만듭니다. 당신이 타이핑하는 것을 지켜보는 동안 당신이 무슨 생각을 하는지 제가 알 수 없다면, 우리는 짝 프로그래밍을 제대로 하고 있는 게 아닙니다. 종종 짝 프로그래밍 중에 일어나는 유일한 대화는 화면에 보이지 않았던 것에 대한 대화뿐입니다. "왜 그렇게 했어? 그게 올바른 일이라고 생각하게 된 이유가 뭐야?" 우리가 이야기해야 할 유일한 것은 화면에 명백히 드러나지 않은 것들입니다. 말없이 오래 갈수록 더 좋습니다.

제가 짝 프로그래밍에서 좋아하는 것 중 하나는 때때로 화면을 손가락으로 가리키기만 해도 상대방이 "아하" 하고는 뭔가 다르게 행동한다는 점입니다. 그저 화면 위에서 초점을 이동시키는 것만으로도 충분할 때가 많습니다. 저는 이것이 복잡한 생각을 설명하고 표현하는 프로그램 텍스트의 효율성과 큰 관련이 있다고 생각합니다. 다시 말해, 복잡한 생각은 컴퓨터 프로그램이라는 구문론적(syntactic) 요소로서 화면에 표현됩니다. 저는 컴퓨터 그래픽을 좋아하지만, 프로그래밍을 그림으로 바꾸려고 시도한 모든 시스템은 그 구문론적 요소를 잃어버렸습니다. 구문(syntax)에는 읽기에 매우 정밀하게 만드는 무언가가 있습니다. 저는 사진을 좋아합니다. 사진은 이야기를 들려줍니다. 하지만 단어(글)는 이야기를 더 잘 들려줍니다. 단어는 더 다재다능합니다. 사진보다 훨씬 더 풍부한 언어적 그림을 그릴 수 있죠.

만약 당신이 매일매일 XP 스타일로 프로그래밍한다면, 즉 당신이 하는 일이 마음속이 아니라 화면에 나타날 정도로 연습한다면, 그것이 당신 인생의 다른 일들을 어떻게 변화시킬까요? 당신은 능력을 다르게 사용하고 있는 것입니다. 생각하는 방식이 바뀌고 있는 것이죠.

빌 베너스: 미래를 걱정하는 대신 현재를 사는 것처럼 들리는군요.

워드 커닝햄: 네, 약간 '젠(Zen, 선)' 같은 느낌이 있습니다. 저는 사실 XP 스타일이 사물이 어떻게 작동하는지 훨씬 더 많은 경험을 하게 해주기 때문에 미래를 예측하는 능력을 더 좋게 만든다고 생각합니다. 우리의 예측 능력 대부분은 일종의 내부 모델링에 기반합니다. 10일에 프로그램 하나를 짜는 대신 하루에 10개의 프로그램을 짠다면, 그만큼 더 많은 경험을 얻게 되는 것이죠.

빌 베너스: 설계하는 데 시간을 쓰지 않는다면 말이죠?

워드 커닝햄: 설계하거나, 혹은 다른 누군가가 설계를 하고 싶어 해서 설계 허락을 받는 데 시간을 쓰는 것들 말이죠. 그 외에 우리가 했을 다른 일들 대신, 우리는 그저 엄청나게 많은 프로그래밍을 합니다. 그래서 무언가를 했을 때 어떤 일이 일어나는지 많이 보게 되고, 그것이 당신을 훌륭한 예측가로 만듭니다. 그래서 반(anti) 설계적인 접근법임에도 불구하고, 결과적으로 우리는 훌륭한 설계자가 됩니다.

결국 당신은 이렇게 하게 됩니다. 머릿속으로 "아! 아! 이게 어떻게 될지 알겠어!"라고 생각합니다. 하지만 그러고 나서 "음, 곧 결과가 나오겠지."라고 생각합니다. 토론할 수도 있겠지만, 결과는 금방 나올 테니까요. 무슨 일이 일어날지 보이지만, 스스로 묻습니다. "이걸 토론해서 어떻게 상황을 더 낫게 만들 수 있을까?" 우리는 함께 일하고 있고 당신은 열심히 프로그래밍하고 있습니다. 제가 "잠깐! 잠깐! 여기서 무슨 일이 일어날지 알아!"라고 말할 수도 있겠죠. 뭐, 여기서 무슨 일이 일어날지는 당신도 알고 있었습니다. 제가 무슨 일이 일어날지 말해주는 게 우리가 일을 끝내는 데 무슨 도움이 될까요? 당신은 "멈춰! 내일 우리가 할 일을 화이트보드에 그리고 싶어. 훤히 보인단 말이야."라고 말할 수도 있습니다. 글쎄요, 저도 보일지 모르지만 왜 굳이 확약을 하나요? 곧 닥쳐올 일인데요. 그러니 우리는 확실히 '지금 여기'에 있지만, 훌륭한 예측가가 될 수 있다고 생각합니다. 단지 필요 이상으로 예측에 의존하지 않으려고 주의할 뿐입니다.

다음 주 예고 1월 19일 월요일, 워드 커닝햄과의 대화 마지막 편이 연재됩니다. Artima.com의 새 기사 알림을 매주 이메일로 받고 싶으시면 Artima 뉴스레터를 구독하세요.