🍭 함께 자라기

P.73

테스트 주도 개발(TDD)을 잘하려면 앞에서 말한 동적인 균형 맞추기를 잘해야 한다. 이걸 잘하면 지속적으로 몰입을 경험할 수 있고 실력이 일신우일신할 수 있다.

지루함을 느끼는 경우: 실력 낮추기

작업의 난이도는 그대로 두고 실력을 낮추는 전략이다. 프로그래머의 예로 들자면, 평상시 즐겨 쓰던 보조 도구를 일부러 안 쓰는 것이다. 디버거를 늘 쓰는 경우 디버거를 안 쓰는 것이다.

이렇게 난이도와 실력이 잘 맞아 들어가기만 하면 의도적 수련이 될 수 있다.

지루함을 느끼는 경우: 난이도 높이기

실력은 그대로 두고 난이도를 높이는 전략이다. 흔하게 쓰는 방법은 자기에게 요구되는 수준을 더 높게 여기는 것이다. 하루 만에 개발하라고 주어진 업무인데 지루한 느낌이 드니 한 시간 만에 할 수 있는 방법을 고안해 보기, 평소 코드를 검토할 때 버그를 시간당 하나 찾았다면 오늘은 두 개 찾기, 익숙한 작업을 새로운 언어로 진행해 보기 등.
보통 자신의 업무를 개선하는 일로 리팩터링을 하거나 자동화 테스트를 달거나, 혹은 자신만의 도구를 개발하거나 하는 것들도 있다.

불안함을 느끼는 경우: 실력 높이기

실력을 높여 몰입 영역으로 들어가는 방법이다. 장기적으로 실력을 높이는 방법은 책을 보거나 스터디에 참가하거나 교육을 듣거나 등등. 하지만 지금 당장 불안함을 느끼고 있다면 어떻게 해야 하는가가 문제이다. 크게 보면 사회적 접근과 도구적 접근, 내관적 접근 세 가지가 가능하다.

사회적 접근은, 나보다 뛰어난 전문가의 도움을 얻는 것이다. 잘하는 사람한테 가서 짝 프로그래밍을 해달라고 부탁하거나 IRC(인터넷 체팅)에서 전문가의 도움을 얻는 것도 괜찮은 방법이다.

도구적 접근은 다른 도구의 도움을 받는 것이다. 내 능력을 확장시켜 줄 수 있는 도구들을 찾아 쓰면 된다.

내관적 접근은 비슷한 일을 했던 경험을 머릿속에서 되살려 보는 것이다. 그때 그 일을 어떻게 했는지 떠올려 보면서 비유적으로 문제를 해결한다. 보통 이런 과정을 거치면 자기효용감이 증대하면서 스스로 인식하는 자기 실력이 향상되기 쉽고, 결과적으로 몰입 영역으로 들어가기 좋다.

불안함을 느끼는 경우: 난이도 낮추기

불안함을 느낄 때 난이도를 낮춰서 몰입 영역으로 들어가는 전략이다.

간단하면서 효과적인 방법은 자신이 맡은 일의 가장 간단하면서 핵심적인 결과물, 즉 아기 버전(혹은 0.0.1 버전)을 첫 번째 목표로 삼는 것이다. 애자일에서 말하는 WTSTTCPW(What's The Simplest Thing That Could Possibly Work?, 동작할 수도 있는 가장 간단한 건 뭘까?)와 같다.

P.98

TDD 교육을 통해 사람들이 기대하는 과정은 보통 이럴 것이다.

1. TDD를 제대로 이해하고 조직에 돌아간다.
2. 나 스스로 TDD를 제대로 실천해서 객관적 성과를 낸다.
3. TDD가 좋다고 사람들을 설득한다.
4. TDD를 가르쳐 준다.
5. 모두가 TDD를 열심히 한다.
6. 좋은 성과를 낸다.

여기에서 보통 문제가 되는 부분은 3, 4, 5, 6번이다. 그리고 1과 2를 잘한다고 해서 3번 이후가 꼭 쉬어지는 것이 아니다. 하지만 교욱에서는 통상 1번에만 집중을 한다. 이럴 경우, 실무로 돌아갔을 때 흔히 접하는 문제는 예컨대 다음과 같다.

• 회사로 돌아가서 실무에 적용하려고 하는데 상사나 동료의 지원 없이 추가적으로 일을 하려니, 시간이 모자라 계속 미루게 되어 결국 적용하지 못한다.
• 팀원, 팀장들에게 전파 교육을 하려 하지만 팀원, 팀장들 가운데 몇몇은 추가 업무를 왜 하는지 필요성도 못 느끼는 상태에서 강제로 해야 한다는 스트레스를 받아서 부작용이 생긴다(그래서 결과적으로 해당 기법은 실무에 써먹을 수 없다는 평가가 나온다).
• 배운 것을 팀 내에서는 열심히 적용했으니 지원해주는 임원이 없어 확대하는 데 실패하고, 조직 내에서는 한 팀의 별난 문화로 치부되어 실행 범위가 축소된다.
• 배운 대로 팀에서 실천했더니 "다른 부서는 그런 거 없이도 잘하는데 너희는 왜 그런 거 하면서 제때 아웃풋이 안 나오냐"며 이해할 수 없다고 말하는 상사나 협력 팀의 리더와 갈등을 겪는다.
• 기술적으로 어떻게 해야 할지 모르겠는데, 주변에 물어볼 사람이 없어 인터넷 검색하느라 몇 시간씩 보낸다. 하지만 결국 원하는 정보를 찾지 못해서 적용을 포기한다.
• 회사에서는 여력이 없어 배운 것을 집에서 시도해 보려 했더니, 가족들의 여러 요구로 인해 집중할 수 없어 화를 내거나, 가족의 요구대로 하느라 내가 할 일은 시작도 못하거나, 그냥 포기하고 잠을 자게 된다.

이런 문제들은 보통 사회적 측면에 대한 것이다. 뭘 하던지 나 혼자가 아니라 항상 누군가가 등장하고, 일의 성패에 다른 사람이 관련되어 있기 때문이다.

아무리 기술적인 실천법이라고 해도 그 기술은 사회적 맥락 속에서 실천되어야 하며 그 기술의 성공을 위해서는 사회적 자본과 사회적 기술이 함께 필요하다.

하지만 안타깝게도 현실에서는 팀원들이 맘에 안 들고, 그들도 나를 맘에 들어 하지 않는 상황, 즉 사화적 맥락이 나쁜 상황에서 타개책으로 TDD의 기술적 측면에만 매몰되는 경우가 있다. 사실 그런 상황에서는 무엇을 골라도 실패가 보장되어 있다.

다시 한번 반복한다.어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요하다. 설사 나 혼자 하는 실천법이라도 해도 말이다.

TDD 도입에 실패하는 경우, 무엇이 병목이었나를 살펴보면 사람들이 TDD의 기술적 내용을 잘 몰라서보다도 TDD를 도입하는 데에 필요한 사회적 자본과 사회적 기술이 없어서가 훨씬 더 많았다. 그렇기 때문에 어떤 기술적 지식을 전달한다고 해도 그것을 사회적 맥락 속에서 가르치고 경험하게 해야 한다. 사회적 기술에는 도움받기, 피드백 주고받기, 영향력 미치기, 가르치고 배우기, 위임하기 등이 있다.