OKKYCON 2018 Real TDD 후기
코알못 기획자가 왜 TDD 컨퍼런스에 갔나
회사 지원을 받아 오키 컨퍼런스(Real TDD)에 다녀왔습니다.
코드를 1도 모르는 기획자 나부랭이가 왜 갔는지, 그리고 무얼 느꼈는지 전달드립니다.
(본 내용은 사내 공유용으로 작성했던 내용 중 일부를 편집한 내용입니다)
제 책장 중 소프트웨어 공학(이라기 보단 애자일 관련) 관련 칸의 사진입니다. 테스트주도개발 책을 꽤 오래전에 샀지만, 읽을 엄두가 안 났습니다. 다른 책들은 그래도 코드 보단 글의 량이 많은데, TDD는 코드에 대한 내용이다 보니 책 대부분이 코드로 구성되어 있습니다. 그래도 저자 서문만 보고도 엄청난 감동을 받았던 책이기 때문에 언젠가 개발을 배운 후에 제대로 읽어볼 계획입니다.
1. 기획자가 왜 TDD에 관심을 갖나
이전에 사내 세미나 자료의 주제도 ‘전문성 연구’ 였듯이 전 어떻게 전문가가 될 것인가에 관심이 많습니다. 소프트웨어쪽은 전문성연구가 굉장히 많이 되고 있는 것으로 알고 있습니다. 전문성을 높이기 위해 개발자들이 발견한 엔지니어링 프렉티스를 기획 영역으로 가져와(전이하여) 수련하면 도움이 될 거라 생각하기 때문에 관심이 많은 겁니다.
TDD 서문(저자의 글)에 보면 켄트가 이렇게 표현하는 구절이 있습니다.
TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다. “일주일 간 종이에다 설계한 다음 코드를 테스트 주도로 개발한다면 이것도 TDD인가?” 물론 TDD다. 결정과 그에 대한 피드백 사이의 간격을 인지하고 또 의식적으로 제어했기 때문이다.
TDD 번역하신 강규영님도 블로그에서 위 내용에 대해 얘기한 적이 있고, 김창준님도 팟캐스트에서 저 부분을 언급한 적이 있었습니다. 레드-그린-리팩토 뭐 이런 걸 얘기하는 게 아니라, 의사결정과 피드백 사이를 인식하고 제어하는 것이 TDD라는 것이죠.
작년에 Tech HR 컨퍼런스에 참석했었는데, 배민의 김범준 CTO님이 연사로 나왔었습니다. 쉬는 시간에 범준님께 이런 질문을 했었습니다. (사실 좀 다른 맥락에서 질문한 거긴 하지만요)
기획에서 피드백을 더 빠르게 얻고 가치있는 재고를 더 빨리 확보하는 방법이 있을까요?
범준님은 이렇게 대답했습니다. “저희는 테스트케이스드리븐으로 합니다. 기획단계에서 테스트케이스를 뽑는데 이런 게 도움이 되지 않을까요?"
여러모로 TDD를 기획에 적용할 수 있을 것 같은 느낌적인 느낌은 있는데, 확신도 없고 사례도 없어서 어떤 힌트를 찾기 위해 이번 TDD 컨퍼런스에 참석했던 겁니다.
2. 그래서 힌트를 얻었나?
아쉽게도 컨퍼런스에서 얻은 힌트는 없습니다. 좀 더 생각을 숙성시키고 TDD를 잘하는 분들을 관찰하면서 천천히 답을 찾을 생각입니다.
다만, 컨퍼런스와 별개로 사내에서 UX 스터디를 하면서 해당 책에 나온 것들에서 얻은 약간의 힌트는 있었습니다. UI를 설계하는 단계에서만 생각해보면,
페르소나를 잘 정의해두면 피드백의 기준이 됩니다.
의사결정(이렇게 ui를 설계해야지)을 프로토타입하고 이를 정의된 페르소나에 통과시켜봄으로써 굉장히 빠르게 피드백을 받을 수 있고, 그 간격을 제어할 수 있습니다.
범준님이 얘기했던 테스트케이스드리븐도 좀 깊게 생각해보면 좋은 힌트들이 나올 것 같습니다.
테스트케이스가 기획을 주도하면 어떻게 될지 상상해보면요
1. 특정 피처가 통과해야 하는 테스트케이스를 먼저 작성합니다.
2. 테스트케이스가 작성되는 순간 스펙이 결정되니 해야 될 게 명확해집니다.(사실 이게 잘 정의되면 유저스토리가 잘 정의된다고도 보여지고요.)
3. given/when/then 같이 정의할 수 있으면 TDD로도 잘 연결될 거 같고요.
4. 테스트케이스만 만족하는 기획을 하게 되니까 최소주의 기획이 될 것 같습니다.
물론 요구사항만 전담하는 사람이 있고, UX 담당이 따로 있고, 세분화된 경우에는 잘 동작할 것 같습니다.
하지만 훨씬 더 중요한 기획(흔히들 상위기획이라고 부르는) 단계에서는 적용이 어려워보입니다.
전 이 영역에 적용할 방법을 계속 찾고 있거든요. 아직 잘 모르겠습니다. 특히나 최소주의-테스트를 만족하는 만큼의 프로덕션 코드와 같은 의미로- 기획을 하는 게 맞는지도 잘 모르겠습니다.
확실한 건, 어떤 상황에서도 피드백은 중요하고, 피드백없이는 성장할 수 없고, 나아질 수 없다는 것을 알기 때문에 어떻게 의사결정과 피드백 사이를 제어할지 답을 찾기 위해 계속 고민할 예정입니다.
본 글은 컨퍼런스 당일날 썼고, 다음날 아침에 지하철에서 리팩토링하고 있는 중에 이런 생각이 들었습니다.
비즈니스를 잘 관통하는 좋은 질문들로 TDD와 비슷한 효과를 낼 수 있지 않을까
TDDBE 에서도 짝프로그래밍이 TDD와 비슷한 효과를 낸다고 한 걸 본 거 같은데, 기획 역시 페어로 하게 되면 TDD비슷한 효과를 낼 수 있지 않을까
3. 컨퍼런스에서 얻은 것
개발자 세미나에 자주 참석해서인지는 모르겠지만, 대체로 개발직군이 타 직군에 비해 공부를 많이하는 것 같습니다. 오픈소스커뮤니티도 그렇고, 스택오버플로우 같은 커뮤니티도 그렇고 공부 열심히 하고 나누는 것이 부럽다는 생각을 자주 하는데, 오늘도 역시나 그렇게 느꼈습니다. 정말 부럽습니다.
오늘 세션들 중에서 ‘테알못 신입은 어떻게 테스트를 시작했을까’란 세션이 인상깊었습니다. 총 경력 10개월의 신입 개발자가 발표를 했었는데요. 사내 세미나에서도 얘기했지만 경력 기간은 실력과 상관관계가 거의 없습니다. 오늘 다른 세션에서도 얘기가 나왔지만, 1년차와 10년차 개발자의 설계에 대한 언급이 있었는데, 10개월 경험하신 분이 이런 발표를 하신다는 게 놀랍더군요.
근데, 이 분의 회사를 보고 이해는 가더라고요. 이규원님이 CTO로 있는 회사였는데, 작년에 Tech HR에서 이규원님 채용 세션 듣고, 되게 흥미로웠거든요. 아니나 다를까 오늘 마지막 세션이 이규원님 세션이었는데, 흔한 신입이 특별한 신입이 될 수 있게 만드는 능력이 있으시더군요.
항상 느끼는 거지만 패널토의가 진또배기고, 얻는 게 가장 많은데도 불구하고 대다수의 분들이 안 듣고 그냥 가시더라고요. 안타까웠습니다.
패널토의에서 나온 내용 중 일부만 공유드리면,
개인 레벨에서 TDD는 삶의 만족도를 높여줍니다. 피드백을 자주 받을수록 직무탈진에 빠지지 않게 되는데, TDD는 피드백을 강력하게 주니깐요.
TDD를 조직에 적용할 때 주니어가 시도하기 더 좋습니다. 시니어가 TDD하자고 얘기하면 사람들이 방어적이 되지만, 주니어가 그러면 덜 방어적이 되니깐요.
TDD 도입 시에도 TDD처럼 도입하라고 얘기해주셨는데, 진짜 인사이트 깊은 내용이라고 생각합니다. 애자일 도입이 실패하는 이유도 반애자일적으로 도입하기 때문이니깐요.
TDD가 작은 스텝으로 조금씩, 점진적인 방법이니까, TDD 적용 역시 작게 쪼개서 적용하길 권하더라고요. 대신, TDD에선 테스트 순서가 굉장히 중요한데, 첫 테스트는 작지만 핵심적인 걸 적용해야 한다고 합니다.
TDD를 통해 배운 것, 그러니까 TDD가 나를 성장시키고 깨달음을 주는 스승이라는 양완수님 말이 인상깊었습니다. 제가 이해하는 TDD(의사결정과 피드백 간극 제어)라면 당연히 그렇게 될 거라 생각하니깐요. TDD 세계가 진짜 궁금합니다.
저야 스프링을 잘 모르지만, 이규원님이 세미나 중에 자바 개발자들은 너무 ‘기승전스프링’이라고 표현하시더라고요. 도메인 모델 안에 프레임웍을 떡칠하면 안 된다라는 의미에서요. 저야 잘 모르긴 하지만, 의존성 측면에서 공감가는 표현이었습니다.
4. TDD하기 어려운 이유에 대한 나름의 답
제가 개발자가 아니어서 그렇겠지만 ‘아니 이 좋은 TDD를 개발자들은 왜 안 할까’라는 의문이 있었습니다. 오늘 컨퍼런스에서 느낀 건 그냥 사람의 차이라고 생각이 되더라고요. 아무리 좋은 방법이 있다고 한들 개인이 해야만 하는 거니깐요.
최근에 박웅현 CD의 여덟 단어 책을 다시 보면서 느낀 게 있는데,
흔히들 TDD는 도구가 아니라 기술이란 표현을 합니다. 도구는 당장 주어지면 쓸 수 있는 것이지만, 기술은 수련 없이는 사용하기 어렵습니다. 안다고 쓸 수 있는 게 아니란 거죠.
그럼 왜 기술을 습득하지 않는가를 봐야 하는데, 이 기술은 몰라도 당장 먹고 사는 데 문제가 없기 때문에 동기가 낮습니다. 돈오를 해야 점수를 할 텐데, 필요성이 떨어지니 돈오하기 위한 노력을 기울이지 않겠죠.
돈오할 수 있는 환경과 개인들의 노력이 없으면 아무리 좋다고 한들 그게 무엇이든 안 되리라 봅니다.
TDDBE에서도 도반을 찾으라고 했듯이 혼자 하긴 어려울 거 같습니다.
돈오하더라도 점수하는 과정에서 귀찮음과 싸우고 참아야하는 거니까요. 생각해 보면 기획에 도움될 프렉티스를 제가 꾸준히 수련하며 사용하고 있나를 보면, 저도 초기에 시도하다 포기한 것들이 많은데 그래서이지 않을까요. 같이 할 사람이 그래서 중요한가 봅니다.
창준님이 패널 토의에서 그런 TDD 도입과 관련된 얘기를 해주실 때, 애자일 환경을 얘기하시더라고요. 워드와 켄트가 일하다 나온게 TDD이고, 그건 애자일 환경이었기 때문에(더 많은 협력과 피드백을 추구하다 보니) 가능했다고요. 그니까, 애자일 환경에서 더 잘 될 텐데, 애자일 팀이 잘 없으니 TDD도 안 되는 거 아닐까 하는 생각이 들었습니다.
그럼에도!! 오늘 컨퍼런스를 통해 느낀 건 더더욱 TDD를 해야 한다는 점(개인차원의 발전을 위해서)
이상입니다. 난해하게 공유드려서 읽기 어려우실 것 같긴합니다.
개인적으론 굉장히 유익하고 생각할 꺼리를 많이 얻어왔습니다.
글로 전하는 게 한정적이기 때문에 아쉽지만 이정도로 공유를 마칩니다.
덧. 아이고. 다 써놓고 보니, TDD를 듣고 와서 공유 하는 글을 작성하면서!!
이 글이 통과해야 할 테스트(DOD나 AC 의미로)를 먼저 생각해 보지 않았군요. 바보!!!
덧. 물리학자들이 문과들이 자꾸만 상대성이론과 양자역학을 멋대로 해석하는 것에 스트레스를 느낀다고 하더라고요.(엄밀함을 추구하는 그들이, 너와 나는 상대적이라던가, 슈뢰딩거 고양이를 이상하게 적용하는 거 보면 괴롭긴 할 듯)
마찬가지로 코드를 모르는 기획자가 이해하는 TDD이기 때문에 개발자분들이 보시기에 엄밀하지 않을 수 있습니다. 제가 잘 몰라서 그런 거니 이해 부탁드립니다.
