켄트 벡이 대답하길 1탄에서 이어집니다.


Q: 루비가 정말 자바를 대체할 앞으로의 주류 개발 언어가 될 수 있다고 생각하는지, 된다면 언제쯤으로 생각하는지, 루비에서 가장 보완해야 할 점은? (김정현님)

(참고로 루비Ruby는 최근 웹 2.0과 함께 급부상하고 있는 인기 스트립트 언어입니다)

켄트 왈, 자신 같은 사람의 대답 없이도 스스로 자신감을 가질 수 있어야 한다고 했습니다. 루비가 주류가 될 수 있겠느냐는 질문에 대해서는 확실한 답을 하지 않았던 것 같습니다. 그게 중요한 것이 아니라는 대화를 나눴던 것으로 기억합니다.

루비에 보완할 점이 뭐냐는 질문에는 "개발 환경" 이야기를 했습니다. 요지는 이렇습니다. 스몰토크는 언어와 개발환경이 아주 잘 결합되어 있다. 이클립스는 양자가 분리되어 있으나 꽤 훌륭하다. 루비도 그런 환경이 필요하다. 루비 세상 속에서 살 수 있는 환경.

참고로 워드 커닝햄도 루비를 긍정적으로 보긴 하지만 열성적 팬은 아닙니다. 그의 말에 따르면 애자일 언어 다음의 언어(Post Agile Language)가 분명히 있을 것인데 무엇이 될지는 잘 모르겠고, 또 그것이 J 언어의 방향일지도 잘 모르겠지만, 현재의 언어들에서 J언어가 떨어져있는 거리 만큼이나 차이가 있는 언어일 것이라고 합니다 -- 그는 종종 만나는 사람들에게 J 언어를 익힐 것을 권합니다.

워드나 켄트 모두 특정 언어에 종교적으로 집착하지는 않는 것 같습니다. 워드는 현재 프로젝트에서 PHP를 쓰고 있습니다. 그 역시 기뻐서 날뛸만큼 좋은 선택이라고 생각하지는 않지만 써야 하는 상황에서는 그 언어를 자기가 살기 좋은 환경으로 변형시키서 잘 씁니다. 그가 PHP로 코딩한 것을 저에게 보여줬는데 매우 놀랍습니다(여기에 대해서는 차후에).

Q: TDD의 테스트는 두가지 목적이 있는 것 같다. 하나는 디자인 시의 가이드, 또 하나는 리팩토링 때의 회귀 테스트. 전자의 경우에 나온 테스트는 리팩토링의 안전성을 보장하기에는 성글어서 문제가 될 수 있다. 그렇다면 어떻게 해야 하나? (1002군)

원래 1002군(참고로 이 친구는 제 생각에 TDD를 남에게 가르칠 수준의 사람입니다)의 질문을 그대로 인용하면:

TDD 에서의 테스트가 디자인을 위한 테스트라면, 리팩토링 스텝때 앞의 테스트를 얼마만큼 믿고 리팩토링 스텝을 밟아도 될 것인지에 대하여. 팀 작업을 하다보면, "TDD 로 한 UnitTest 를 어떻게 Regression Test 로 믿고 리팩토링을 하느냐. 리팩토링을 하려면 결국 리팩토링 전과 후의 결과를 보장할 테스트들을 훨씬 더 많이 촘촘히 만든 뒤에 리팩토링해야 하지 않냐?" 는 질문들을 받았던 기억이. 그때에는 걍 '겁나면 Regression Test 를 위한 UT 를 더 작성하죠' 라고 하긴 하는데.. 혹시 이러한 질문들이 있었는지와 그에 대한 솔루션은?

제목으로 되어 있는 질문은 제가 적당히 고쳐쓴 것인데 원래 질문자의 의도와 부합하는지는 잘 모르겠네요. 어쨌건 나름대로 흥미로운 질문이라고 생각했습니다.

켄트 말하길, 디자인, 테스트의 분리가 이상하다. 단계(phase)를 만들어 넣는 것 같다. 나는 중요한 테스트라면 처음 테스트를 만들 때 다 한다. 나중에 깨질 것 같은, 불안한 부분이 있을 때 뒤로 미루지 않는다. 그러나 리팩토링할 때 뭔가 새는 부분을 찾았다면 나는 새로운 것을 배운 것이다.

인상적인 답변입니다.

Q: 부인과 같이 책도 쓰셨는데, 부인은 어떻게 그 많은 애들도 키우면서 저술활동 및 사회활동을 하시는지, 켄트 백님은 부인을 어떻게 도와주시는지, 그리고 그것이 당신에게는 어떻게 돌아오는지 알고 싶네요. (아말감님)

이 질문의 앞부분은 신시아가 답변을 하셨고, 뒷부분은 켄트가 대답을 해줬습니다.

신시아는 "그런 일들을 다 하는 것이 별로 어렵지 않다"고 합니다. 특별히 사회활동을 하는 것은 없고 아이들 홈스쿨링을 하는 데에 시간을 많이 보내고, 가끔 켄트와 함께 강의를 하는 것 같습니다. 애들 키우는 것은, 5살 이전까지는 힘들지만 그 이후에는 훨씬 수월하다고 합니다. 그 전에는 육체적인 문제인데 이후에는 정신적인 문제라네요.

켄트에게는 "부인을 어떻게 도와주십니까?"라고 물었는데 "충분히는 못합니다(Not enough)"라고 하더군요. 겸손한 거겠죠? 하지만 자신이 꼭 해야만 하는 일, 상황이 있으면 다 한다고 합니다. 예를 들어 예전에 OOPSLA에서 신디가 다리가 부러진 적이 있었는데 켄트가 집안 일을 거의 다 했다고 합니다. "그리고 그것이 당신에게는 어떻게 돌아오는지"라는 질문에 대해서는 부적절한 질문이라고 했습니다. 자기는 그런 것을 생각하지 않는답니다. 자기가 해야할 일이라면 한다고 합니다.


Q: ... the system is riding me much more than I am riding the system의 의미는? (김민재님)

이 질문은 그 자리에서 하지는 않았습니다만 제가 답할 수 있겠습니다.

그 부분은 "내가 시스템을 타고 있는 정도보다 훨씬 더, 시스템이 나를 타고 있습니다"라고 어색하게 나마 번역할 수 있겠습니다. "탄다"는 표현은 앞서의 탈것(vehicle)과 관련이 있습니다. "...I had to accept that I was only the vehicle for the system expressing its own desire for simplicity"라고 앞에서 말하는데, 그것은 "시스템이 단순함을 향한 시스템 자신의 욕구를 표현하기 위해 나를 매체(탈것)로 삼는다는 사실을 받아들여야 했습니다"라는 의미입니다.

하지만 이런 말을 했던 것은 수년 전이고 최근에는 변화가 있는 것 같습니다.

There was a period where I fancied myself "just a channel", letting the design "emerge" that "wanted" to emerge. This perspective caused me problems because it didn't match the reality of the situation. I was doing the designing -- it was better for me to take responsibility for that and for the outcome. I bring my ideas and perspectives to designing, but there is also a lot of information "out there" to pay attention to if I want quality designs that fit the situation. (2005년 10월 12일)



바깥에 많은 정보가 있고 거기에 주의를 기울여야 하지만 결국 디자인을 하는 것은 "나"이고 그 책임은 온전히 나에게 있다는 말입니다. 사실 당시에 '나는 시스템의 매체요'에 대한 글을 쓸 때에도 약간의 장난끼가 들어가 있는 걸 볼 수 있습니다.

이 답변은 다음 질문으로 자연스럽게 이어집니다.

Q: 요즘 책임 개발(Responsible Development)이라는 표현을 종종 쓰시는데 어떤 의미인지?

이 질문은 제가 한 것입니다. 켄트의 답변을 요약하면 다음과 같습니다.

말은 컨텍스트, 시기에 따라 다르게 해야 한다. 예전에는 사람들이 XP의 실천법을 알고 있었다고 해도 행하지는 않았다. 그 때에는 익스트림 프로그래밍(Extreme Programming)이라고 하면 됐다. 이제는 많은 사람들이 그런 실천법을 대부분 실천한다. 이제는 책임감 있는 개발(Responsible Development)을 이야기해야 한다. 책임이라는 것은 무엇인가? "그 돈이 당신 돈이라면 어떻게 하시겠습니까?"(What would you do if it's your money?)라는 질문이 매우 강력하다. 몇 달 째 설계만 하던 사람에게, 그 프로젝트에 쓰이고 있는 돈이 네 돈이면 그렇게 하겠냐고 물으면 "에이 농담하십니까, 당연히 안그러죠"라고 한다.

참고로 켄트는 XPE2E 출간 이후 responsibility, accountability를 무척 강조하고 있습니다. XP라는 이름 대신 Responsible Development라고 개명하고 싶다고 느끼는 것 같습니다.

Q: BDD에 대해서 어떻게 생각하시는지 (말랭이님)

이 질문은 켄트 벡과의 만남 이후에 올려주셔서 직접 묻지는 못했습니다. 제 경험과 켄트 벡의 예전 답변을 정리해 보겠습니다.

우선 켄트는 최소한 2005년도의 반응으로 보아서는 BDD에 열광하는 것 같지는 않습니다. 오히려 그런 사람들(TDD는 갔다, BDD가 온다는 사람들)에게 점잖게 비판을 한다고 할까요? 그는 BDD가 큰 차이가 있다고 보지 않습니다.

저도 2005년 경부터 BDD에 관심을 갖고 사용해 보았습니다. BDD 프레임워크도 몇 개 직접 만들었고, 프로그래머 교육(프로그래밍 배경이 있는 사람, 없는 사람 모두)시에 BDD를 사용해보기도 했죠. 제 주변 지인들은 잘 알고 있을 겁니다. 제가 여기저기 다니면서 BDD 광고를 많이 했었죠. 지금도 2005년 루비 컨퍼런스에서 마틴 파울러(리팩토링 저자), 브라이언 매릭(테스팅 전문가), 아슬락 헬러소이(RSpec 코어 팀 멤버), 나다니엘 탈봇(루비 개발자) 등과 함께 풀장 벤치에 앉아 BDD에 대해 토론하던 일이 생생합니다.

이런 경험들을 통해 제가 느낀 것들은 다음과 같습니다:

저 역시 BDD가 TDD와 엄청나게 다른 뭔가를 준다고 생각하지는 않습니다만 거기에는 몇 가지 유용한 아이디어들이 있다고 봅니다.

Q: 서비스는 차고 넘치고 과거 시스템의 업보로 업무는 나날이 힘들어만 가고 빛은 보이지 않습니다. 이런 상황을 타개하기 위해 일선 개발자와 개발팀장으로 해야 할 일은 무엇일까요? 켄트 벡께서 저희 팀에 컨설팅을 온다면 어떤 일을 먼저 하실까요? 개선되어가고 있다는 설명가능성(accountability)은 어떻게 표현하실까요? (아무개님)

사실 이 질문은 비공개 질문입니다(그래서 익명입니다). 그리고 제가 켄트 벡을 만난 후에 이 질문이 올라와서 물어보지 못했습니다. 하지만 무척 간절하고 중요한 질문이라고 생각해서 켄트에게 이메일로 질문을 보냈습니다. 꼭 성심껏 답해달라는 부탁과 함께. 대략 열흘 쯤 후에 답변을 받았습니다. 어떤 답을 해야 할지 많이 생각해 보았다고 하네요.

저는 그 질문에 대해 깊이 생각해 보았습니다. 제 생각에는 질문하신 분이 문제를 명료히 이해하고 있는 것 같고, 이것은 좋은 시작입니다.

제가 코칭을 한다면 맨 처음 할 것은 듣기입니다. "여기서 무슨 일이 벌어지고 있지요?" 그에 대한 이야기를 듣게 되면 저는 이렇게 시작할 겁니다. 그 워크그룹(명칭으로는 팀이지만 팀원간 협력이 없으면 워크그룹)이 잘 해나가던 때에 대한 질문을 하는 거죠. 한 사람 한 사람이 모두 살아있다고 느끼고 열중하고 또 들떠있던 때 말입니다. 만약 그 그룹이 단 한번도 잘 돌아갔던 적이 없었다면, 사람들이 이제껏 속했던 다른 팀 중에서 자신이 효과적(effective)이었던 팀에 대해 물어 볼 겁니다. 그러고 나서는 그 그룹에게, 그런 경험의 교훈을 현재 상황에 적용해보라고 부탁할 겁니다. (이 과정을 감사의 질문Appreciative Inquiry이라고 합니다 -- 더 알고 싶은 경우를 위해 그 이름을 알려드립니다.) 

만약 팀이 자신들이 만드는 변화를 유지하길 바란다면, 설명가능성(accountability)에 대한 질문이 바로 핵심이라고 생각합니다. 그들이 어떻게 일하는지와 그들이 어떻게 일하고 싶은지 사이의 주요한 차이점들이 무엇입니까? 그 차이점들을 어떻게 측정할 수 있을까요? 그 팀은 어떤 외부인이나 외부 그룹에게 보고할 수 있을까요? 관리자(manager), 고객, XP 사용자 모임?

예컨대, 그 팀은 자신들의 고객을 찾아가서 이렇게 말할 수 있을 겁니다. "우리는 당신에게 더 나은 서비스를 제공하고 싶습니다. 우리는 계속 더 많은 시간을 일하고 있지만 동시에 다운타임이 계속 증가하고 있었다는 것을 알게 되었습니다. 다음 6개월 동안 우리는 다운타임을 90% 줄이고 당신의 프로젝트에 주당 30시간 일하는 것으로 시간을 줄이고 싶습니다. 당신과 매월 회의를 해서 우리의 근무 시간과 다운타임을 보고했으면 합니다. 우리는 그냥 우리가 한 것을 말씀드릴 겁니다. 우리는 변명을 하지 않을 것이고 다른 누군가를 비난하지도 않을 겁니다. 우리를 위해 이 제안을 받아들여 주실 수 있겠습니까?"

저는 질문하신 분과 그의 팀, 그리고 그 팀의 고객과 회사가 개선을 향해 노력해 나가면서 성공할 수 있기를 진심으로 바랍니다.

켄트의 변화 유지 비결을 생각케 합니다. 제가 예전에 코칭을 나가면 주로 문제에 집중을 했습니다. 문제를 느끼는 사람들(주로 개발자였죠), 그 사람들이 제대로 못하고 있는 것들, 그리고 변화에 가장 저항이 큰 사람들. 하지만 그렇게 접근하면 저도 고생이고 그 사람들도 고생입니다. 지역적 최적화(local optima)에 눈이 멀기 쉽습니다. 이제는 접근법이 좀 다릅니다. 그들 속에 잠재된 "잘 하는 것"을 살리려고 합니다. 그리고 될 수 있으면 숲을 보려고 하고 더 다양하고 많은 사람들을 개입시킵니다. 켄트가 설명한 방법과 유사한 면이 있습니다.

 

이 외에도 여러가지 재미난 이야기를 나눴는데 또 다음에 기회가 되는대로 글을 올리도록 하겠습니다.

--김창준