TOC
참고
본 내용은 단위 테스트의 기술을 읽고 정리한 내용입니다.
책의 내용과 함께 개인적인 의견과 생각, 학습을 담아 작성하였습니다.
들어가며
- 조직 내 사람들의 습관을 바꾸는 일은 기술적인 문제보다는 심리적인 요인이 더 크다.
- 사람들은 변화를 꺼리고 변화는 언제나 두려움과 불확실성, 의심을 동반한다.
- 어려움을 어떻게 이겨낼 수 있을지 살펴보자.
변화의 바람을 일으키는 과정
조직에서 변화를 이끌어 내려면?
- 역할을 받아들여라.
- 숨지 말고 적극적으로 변화를 주도하라.
- 바꾸려는 시도 전에 조직 내 사람들을 미리 설득하라.
까다로운 질문에 대비
변화를 만들려면 철저한 준비가 필요하다.
- 포럼, 블로그, 메일링 리스트에서 정보 얻기
- 여러 동료와 함께 의논해 보기
내부 설득
흐르는 강물을 거슬러 오르는 연어는 힘이 들 수밖에 없다.
- 조직 내에서 무언가를 바꾸어 보려고 해도 혼자서만 변화를 추진한다면 그 길은 무척이나 외롭고 고독할 것이다.
- 나를 응원해 줄 지지자와 반대자를 구분하라.
지지자 후보
이들에게 계획중인 일에 대한 의견을 구하라.
- 보통 새로운 것을 먼저 시도하는 사람들
- 변화할 준비가 된 사람들
- 변화를 시도했지만 실패를 경험했던 사람들
지지자에게 조언을 구할 때
다음과 같은 부분들에 대해 조언을 받을 수 있다.
- 변화를 시도해 보기에 적합한 팀
- 변화에 긍정적인 팀이나 동료
- 변화를 시도할 때 주의해야 할 요소나 인물
지지자를 진정으로 만들기
- 지지자들이 스스로 역할을 잘 수행할 수 있도록 미리 준비시켜라.
- 지지자에게 먼저 손을 내밀어 변화의 여정에 함께할 수 있도록 하라.
- 지지자들이 힘든 변화의 여정에서 핵심 역할을 잘 해낼 수 있도록 하라.
반대자를 이해하기
사람들이 변화를 거부하는 이유는 다양하다.
- 직업 안정성에 대한 불안 때문에, 또는 현재 방식이 편해서.
- 반대자들에게도 여정을 함께할 수 있는 기회를 주는 것이 좋다.
- 오히려 변화를 이끄는 권한과 역할을 맡기고 주축이 되게 하라.
- 이들 스스로가 조직 내에서 중요한 역할을 하고 있다고 느끼게 하라.
변화의 시작점을 찾아라
변화를 시작할 수 있는 지점을 찾아라.
성공한 사례들을 보면 꾸준한 시도와 과정을 거친다는 공통점이 있다.
작은 팀부터 시작하기
시작하기 적합한 팀은 뭘까?
- 규모가 작고, 중요도가 낮은 팀
- 위험이 적은 프로젝트를 진행하고 있는 팀
주의
팀 내 구성원이 새로운 방식으로 일하는 것과 새로운 기술을 배우는 것에 열려 있어야 한다!
- (아이러니하게도) 경력이 적은 주니어 개발자일수록 변화를 쉽게 받아들이고, 경력이 많은 시니어 개발자일수록 자신의 방식에 익숙하여 변화를 쉽게 받아들이지 못한다.
- 경험이 풍부하면서도 변화에 열린 리더, 그리고 주니어 개발자들로 구성된 팀은 변화를 기꺼이 받아들일 가능성이 크다.
프로젝트의 실행 가능성 검토하기
- 너무 많은 것을 욕심내지 않도록 주의하라.
- 난이도가 높은 프로젝트를 성공적으로 이끌려면 풍부한 경험이 필요하다.
코드와 테스트 결과를 사내 교육 도구로 활용하기
- 코드 리뷰와 함께 테스트 리뷰를 시행하라.
- 다른 사람들의 코드와 테스트를 리뷰하면서 테스트에서 무엇을 중요하게 보는지 테스트 작성과 TDD 접근 방식에 대해 팀원들이 알게 할 수 있다.
리뷰에서 몇 가지 팁
- 리뷰는 화상 회의 프로그램이 아니라 직접 대면해서 진행하라.
- 대면 리뷰에서는 비언어적인 방식으로 더 많은 정보가 전달된다.
- 더 빠르고 효과적으로 학습할 수 있다.
- 처음에는 커밋으로 올라오는 모든 코드를 한 줄 한 줄 리뷰하라.
- 누군가 "이 코드는 리뷰할 필요가 없다고 생각했다."라고 말하는 문제를 예방할 수 있다.
- 리뷰를 진행할 때는 한 명을 더 참여시켜라.
- 이 사람은 코드 리뷰를 어떻게 진행하는지 배울 수 있다.
- 팀원들의 코드 리뷰 능력을 키워 더 많은 책임을 맡겨라.
성공으로 가는 길
- 변화를 시작하는 데에는 2가지 선택지가 있다. 상향식(bottom-up) 과 하향식(top-down) 이다.
- 일을 진행하는 과정에서의 노력이 경영진의 관심과 지원으로 이어질 수 있도록 설득하라.
- 외부 전문가의 도움을 받아야 할 시점을 현명하게 판단하라.
- 성과를 가시화하는 것과 명확하고 측정 가능한 목표를 설정하는 것 역시 중요하다.
- 장애물을 파악하고 이를 피하는 것도 중요하다.
- 꼭 필요한 싸움을 선택하는 것이 필요하다.
게릴라 방식: 상향식
- 작은 팀에서 먼저 시작해서 성과를 내라.
- 이를 통해 다른 사람들에게 가치를 설득하라.
- 보통 톱니바퀴처럼 반복되는 기존 방식에 지친 팀이 시작한다.
경영진이 알게 할지, 모르게 할지
경우에 따라 아래의 게릴라 방식으로 나뉜다. 정답은 없다.
- 개발자들이 먼저 제안 후 경영진이 이를 지지
- 경영진과 협력하여 진행
- 개발자들이 먼저 도입 후 경영진이 뒤따라 진행
- 경영진이 모르는 사이에 일을 은밀하게 진행 가능
- 때로는 이것이 변화의 바람을 일으킬 유일한 방법
- 별다른 방법이 없고 혁신이 반드시 필요하다고 확신한다면 그냥 실행에 옮겨라.
경영진 설득하기: 하향식
- 관리자가 먼저 변화 이끌어 조직 전체가 점진적으로 그 방향으로 움직이는 방식
- 중간 관리자가 변화의 이점을 깨닫고 변화를 실천하며 혁신을 주도하는 방식
실험을 이용한 기회 창출
파일럿 프로젝트
대규모 조직에서 단위 테스트를 도입하는 효과적인 방법
특정 팀만 선정해서 실험적으로 도입하기
- 사전에 합의되어야 한다.
- 실험 대상은 실제 프로젝트의 극히 일부로 제한한다.
- 지나치게 극단적이거나 위험하지 않도록 한다.
- 단순한 연습이 아니라 실제로도 의미 있는 결과를 제공해야 한다.
- 실험에서 도출된 결과는 실제 운영 환경에서 활용될 수 있어야 한다.
- 작성 후 잊히는 코드가 되어서는 안 된다.
왜 실험일까?
'실험'이라는 표현이 주는 의미는 무엇일까?
- 이 작업은 일시적이다.
- 성공적으로 끝나지 않는다면 문제 없이 얼마든 기존으로 돌아갈 수 있다.
- 실험 기간이 정해져 있다. (언제 끝나는지 명확히 알 수 있다.)
- 전체 조직에 미치는 영향이 작다. (심리적 부담의 저하로 이어진다.)
- 변화는 한시적이므로 반대자의 목소리도 줄어들 수 있다.
실천하기
- 여러 실험 옵션 중에서 내 아이디어가 선택되지 않을 수 있음을 염두에 두자.
- 실험이 잘 되면 시도해본 방식이 원래 내 문제를 해결해주어 지속하고 싶어질 수 있다.
- 실험이 마음에 들지 않아도 일시적이니 곧 다시 나의 시간이 온다.
실험과 성과 측정
- 실험을 시작하기 전과 끝난 후에는 반드시 성과 지표를 기록하라.
- 이 지표는 목표로 삼은 개선 사항과 직접적으로 관련되어야 한다.
외부 전문가에게 도움받기
사내 직원보다 외부에서 초청한 테스트 전문가가 더 도움이 될 때가 있다.
자유로운 의견 제시
- 사내 직원 입장에서는 말하기 어려운 부분도 언급 가능
- 예를 들면, 코드 품질이나 가독성에 대한 비판적인 의견
풍부한 경험
- 외부 컨설턴트는 반대자들과의 의견 충돌과 대립에 대한 경험이 풍부하다.
- 까다로운 질문에 대한 답을 제시하고, 변화를 효과적으로 이끌기 위한 전략에 능하다.
전문성
- 컨설턴트는 이 일에만 집중하며 전문적으로 작업을 수행한다.
- 회사의 다른 직원은 각자 본업에 더 신경을 쓰는 동안 말이다.
진행 상황 가시화
가시화의 중요성
- 새로운 변화를 만들어가는 과정에서는 이를 효과적으로 어필하는 것도 중요하다.
- 진행 상황과 상태를 지속적으로 가시화하는 것이 필요
- 화이트보드나 포스터를 복도나 탕비실 등 사람들이 자주 다니는 곳에 비치하라.
- 데이터는 달성 목표와 관련된 것이어야 한다.
가시화할 사항들
- 마지막으로 실행한 빌드에서 얼마나 많은 테스트가 통과했고 실패했는지
- 어떤 팀이 자동화된 빌드 프로세스를 실행하고 있는지
- 목표에 따라 스크럼 번다운 차트나 테스트 코드 커버리지 보고서를 게시
- 문의 사항이 있을 때는 빠르게 답변할 수 있도록 담당자 연락처를 함께 게시
- 현재 빌드 상태, 실행 중인 작업, 실패한 작업 등
가시화의 효과
현재 변화를 겪고 있는 그룹
- 차트가 업데이트될 때마다 성취감과 자부심을 느낀다.
- 공개 게시 효과로 인해 과정을 완수해야 한다는 부담감을 느낀다.
- 성과를 다른 그룹과 비교하며 경쟁심이 자극된다.
- 더 큰 동기 부여를 얻고 스스로도 더 많은 노력을 기울인다.
과정에 참여하지 않은 그룹
- 관심과 호기심을 불러일으킨다.
- 자연스럽게 대화를 유도한다.
- 원한다면 변화에 동참할 수 있는 기회를 제공한다.
구체적인 목표, 성과 지표, KPI 설정
만약 목표가 없다면?
- 성과를 측정하거나 다른 사람들에게 성과를 전달하기 어렵다.
- 문제가 생겼을 때 쉽게 없어질 수 있는 애매한 형태로 남는다.
후행 지표(lagging indicator)
단위 테스트는 지속적 배포(CD)와 관련이 있는데, 일반적으로 다음 DevOps 지표를 사용하는 걸 추천한다.
배포 주기: 얼마나 자주 성공적으로 배포하는지변경 리드 타임: 새로운 기능 요청이 운영 환경에 반영되기까지 걸리는 시간운영 중 발견된 버그/변경 실패율: 시간 단위로 운영 환경에서 발생한 실패수 측정평균 복구 시간: 운영 환경에서 문제가 발생했을 때 복구에 걸리는 시간
이들을 후행 지표라고 한다.
- 조작하기는 어렵지만 대부분 쉽게 측정 가능
- 실험 결과를 왜곡하지 않고 정확히 평가하는 데 유용
선행 지표(leading indicator)
올바른 방향으로 가고 있는지 더 빠르게 확인하고 싶을 때 활용하라.
- 일상적으로 관리할 수 있는 요소를 의미
- 코드 커버리지, 테스트 수, 빌드 시간 등
- 조작이 쉬운 편
- 그래서 후행 지표와 함께 활용하라.
지표 분류 및 그룹
선행 지표는 두 그룹으로 나뉜다.
- 팀 단위: 팀마다 개별적으로 관리할 수 있는 지표
- 개발 관리 단위: 여러 팀 간 협업이 필요하거나 각 팀의 지표를 종합한 지표
지표의 사용 목적에 따라 다음과 같이 분류한다.
- 진행 상황: 계획의 진행 상태를 명확히 하고 의사 결정을 확실히 하는 지표
- 병목 현상 및 실행 결과: 병목 현상과 그에 따른 실행 결과를 해결하는 지표
- 품질: 운영 환경에서 발생하는 버그를 줄이는 지표
- 기술: 팀 내부 혹은 팀 간 지식 격차를 점진적으로 해소하는 지표
- 학습: 조직이 스스로 학습하는 조직으로서 행동하고 발전해 나가는지 평가하는 지표
정성적 지표
대부분은 숫자로 측정할 수 있는 정량적 지표이지만, 이런 정성적 지표도 있다.
- 테스트가 코드에서 발생하는 버그를 잡아낼 수 있을 것이라는 확신은 어느 정도인가?
- 코드가 의도한 대로 작동한다고 생각하는가?
추세선을 주목하라
중요한 것은 숫자가 아닌 추세선(trend line)
- 숫자에 현혹되지 말라.
- 추세선이야말로 더 나아졌는지 보여주는 진짜 지표이다.
길 위의 돌부리
성공으로 가는 길에는 항상 장애물이 있다.
- 대부분의 장애물은 조직 내에서 발생한다.
- 일부는 기술적인 문제일 것이다. 이는 적절한 해결책은 찾으면 쉽게 극복이 가능하다.
- 조직 문제는 세심한 주의와 때로는 심리적인 접근이 필요하다.
처음에는 어렵다
- 무언가 일이 잘 풀리지 않는다고 느낄 수 있지만 쉽게 포기하지 말라.
- 새로운 프로세스에 적응하고 문제를 해결하는 데는 시간이 필요하다.
- 시작은 어려울 수 있지만 꾸준히 지속해야 한다.
- 계획대로 되지 않더라도 일정 기간은 지원해 주겠다는 경영진 약속을 미리 받아두는 것도 중요하다.
실패로 가는 길
추진력 부족
변화를 지속적으로 이끌어 가는 데는 대가가 따른다.
- 다른 사람들을 가르치고 도와주어야 한다.
- 조직 내부에서는 변화를 위한 정치적인 싸움까지 해야 한다.
- 본업에 할애할 시간이 줄어드는 것은 당연하다.
- 시간 투자가 필요하다는 점을 받아들여야 한다.
- 외부 인력을 투입하는 것이 추진력을 확보하는 데 큰 도움이 될 수 있다.
내부 지원 부족
경영진의 소극적인 태도는 눈에 잘 띄지 않는 반대이다.
- 조직이 변화를 원치 않을 때는 지원을 해주는 것처럼 한다.
- 하지만 변화를 지속하기 미미하도록 시간을 적게 준다.
- 자연스럽게 변화를 막는 전략이다.
- 자신이 반대 세력과 맞닥트렸다는 사실을 깨달아야 한다.
- 반대하는 경영진에게 자원이 부족해 어렵다고 말한다면, 하지 말라는 대답만 듣는다.
- 경영진을 설득해서 관점을 관철시켜야 한다.
임시 구현과 첫인상
충분한 단위 테스트 지식 없이 도입하려고 할 때는 이것만은 반드시 기억하라.
"경험이 있는 사람을 참여시키고 이 책의 가이드를 따라라."
- 상황에 맞는 변화를 배우는 데는 많은 시간이 걸린다.
- 잘못된 시도는 조직 내 신뢰를 잃을 수 있다.
- 이로 인해 파일럿 프로젝트가 중단될 위험이 있다.
- 시간을 최대한 활용하고 가능한 모든 위험 요소를 없애야 한다.
- 좋은 테스트를 작성하는 방법을 모른다면 책을 읽거나 컨설턴트를 고용하는 편이 낫다.
- 코드가 테스트 가능하도록 만드는 방법을 모르는 경우도 그렇다.
- 이미 존재하는 테스트 방법을 다시 만드는 데 시간을 낭비해서는 안 된다.
팀원이 협조적이지 않을 때
시도하고자 하는 일에 팀원이 협조적이지 않을 때는 성공이 거의 불가능하다.
- 기존 업무와 새로운 프로세스의 병행은 매우 힘들다.
- 팀원들 반응이 미적지근하더라도 최소한 방해는 하지 않도록 해야 한다.
- 팀원들과 새로운 변화에 대해 이야기 하는 시간을 가져 보는 것이 좋다.
- 내가 어떤 노력을 하고 있는지 설명하고, 질문에 답변하는 것이 도움이 된다.
- 팀원 지지를 당연하게 여기지 말라. 상황을 정확히 판단하라.
변화에 영향을 미치는 요인
- 누군가에게 어떤 행동을 하도록 설득할 때, 따라주지 않는다면 매우 답답할 수 있다.
- 그럴 때 이걸 생각하라.
우리가 보는 모든 행동은 그 행동이 일어나도록 세상이 완벽하게 설계된 결과다. 즉, 어떤 사람이 무언가를 하고 싶어 하거나 할 수 있는 능력 외에도 그들의 행동에 영향을 미치는 다른 요인들이 존재한다는 뜻이다. 하지만 우리는 흔히 이 두 가지 요인만을 생각한다.
인플루엔서(김영사, 2011) 中
행동에 영향을 미치는 요인
어떤 사람이 특정 행동을 할 때 행동에 영향을 미치는 요인이 있다.
- 개인의 역량
- 필요한 기술이나 지식을 충분히 갖추고 있는가?
- 개인의 동기
- 올바른 행동에서 만족감을 느끼는가?
- 잘못된 행동을 피하려는 의지를 가지고 있는가?
- 가장 어려운 상황에서도 자기 통제를 할 수 있는가?
- 사회적 능력
- 나와 다른 사람들이 그 사람에게 필요한 도움이나 정보, 자원을 중요한 순간에 제공할 수 있는가?
- 사회적 동기
- 주변 사람들이 올바른 행동을 하도록 적극적으로 격려하는가?
- 잘못된 행동은 억제하려 하고 있는가?
- 나와 다른 사람들이 좋은 본보기가 되기 위해 솔선수범하고 있는가?
- 환경적 조건
- 행동을 더 쉽게 하고 안전하게 할 수 있도록 공간이나 예산 같은 환경적 요소를 잘 갖추고 있는가?
- 그 행동을 지속적으로 유지할 수 있도록 돕는 신호나 알림 같은 보조 장치가 충분히 마련되어 있는가?
- 보상 체계
- 올바른 행동을 했을 때 명확한 보상(급여, 보너스 등)이 제공되고 있는가?
- 단기적인 보상이 장기적인 목표와 부합하며, 바람직한 행동을 지속하는 데 기여하고 있는가?
상황이 원하는 대로 풀리지 않는 이유를 파악하는 간단한 체크리스트라고 생각하자.
요인은 복합적일 수 있다
행동에 영향을 미치는 요인이 한 가지 이상일 수 있다.
- 행동을 바꾸려면 관련된 모든 요인을 함께 바꿔야 한다.
- 한 가지만 바꾸어서는 행동이 바뀌지 않는다.
까다로운 질문과 답변
- 내가 만드는 변화가 누군가의 개인적 손해가 될 수 있음을 전제로 한다.
- 질문 의도를 파악한 후에는 그 문제를 직접적으로든 간접적으로든 반드시 해결해야 한다.
- 그렇지 않으면 보이지 않는 반발이 계속 남아 있을 것이다.
시간 소요에 대한 질문
단위 테스트를 도입하면 현재 프로세스에서 얼마나 더 많은 시간을 차지할까요?
- 일정 관리에서 핵심적인 역할을 맡는 사람들이 묻는다.
- 물어보는 사람에 따라 포커스는 달라진다.
- 팀 리더는 매니저에게 설명할 거리를 찾는다. (제품의 일부일 수 있다.)
- PM이나 고객이 묻는다면 전체 제품 범위에 대한 시간 소요를 물어본다.
- 관심의 범위가 달라지면 답변도 달라져야 한다.
단위 테스트에 대한 어필
- 단위 테스트를 작성하며 특정 기능 구현에는 시간이 2배는 소요될 수 있다.
- 하지만 QA 공수가 줄어들며 전체 제품 출시 일정은 오히려 빨라질 수 있다.
- 나아가 품질과 유지보수성의 향상도 기대할 수 있다.
- 총 시간은 결국 균형을 맞추게 된다는 점을 경영진에게 어필하라.
성공 여부를 이 기준으로 판단해보자.
- 팀이 각 개발 단계에 소요한 시간
- 프로젝트가 고객에게 배포되기까지 전체 소요 시간
- 배포 후 고객이 발견한 버그 수
단위 테스트와 QA 업무의 상관관계
단위 테스트 때문에 QA 업무가 사라질까?
- 단위 테스트가 작성되면 QA 업무는 오히려 더 흥미로워진다.
- 반복적인 UI 디버깅 대신 실제 시나리오에서 더 복잡한 논리적인 버그를 찾는 데 집중할 수 있기 때문이다.
- 단위 테스트는 첫 번째 방어선 역할을 하고, QA는 두 번째 방어선인 사용자 수용 테스트를 맡는다.
- QA가 더 중요한 문제에 집중할 수 있으면 더 나은 애플리케이션을 만들 수 있다.
단위테스트가 만능은 아니다
테스트가 있음에도 왜 여전히 QA를 진행하면 버그가 발견될까?
- QA 팀이 있든 없든 여전히 버그는 발생한다.
- 단위 테스트는 빠른 피드백과 쉬운 유지 보수를 가능하게 한다.
- 하지만 애플리케이션 전반에 대한 완전한 신뢰도는 주지 않는다.
- 애플리케이션의 다양한 계층에서 테스트를 여러 단계 함께 실행하는 것이 중요하다.
테스트 자체의 버그
테스트 자체에 버그가 없다는 것을 어떻게 확인할 수 있을까?
- 테스트는 실패해야 할 때 실패하고, 통과해야 할 때 통과하도록 작성해야 한다.
- TDD를 도입하면 이러한 부분을 놓치지 않을 수 있다.
디버거와 테스트
디버거로 코드가 잘 작동하는 것을 확인했는데, 왜 테스트가 필요할까?
- 디버거는 멀티 스레드 기반 코드를 다룰 때는 큰 도움이 되지 않는다.
- 단위 테스트를 통해 코드에 문제가 생겼을 때 이를 알려 줄 수 있도록 준비해야 한다.
- 대부분의 결함은 코드 자체에서 발생하는 것이 아니라 사람들 간의 소통 오류나 끊임없이 변경되는 요구 사항, 애플리케이션 도메인에 대한 지식 부족으로 발생한다.
TDD에 대한 인식
TDD는 어떻게 받아들여야 할까?
- TDD는 하나의 개발 방식일 뿐이다.
- 필자는 개인적으로 TDD의 가치가 크다고 본다.
- 또한 여러 사람이 이미 TDD로 생산성과 효율을 얻었다고 여긴다.
- 일부 사람은 코드를 작성한 후에 테스트를 추가하는 방식으로도 충분하다고 생각한다.
- 결국 선택의 영역이다.
총평
테스트와 개발을 넘어
이번 장은 단지 테스트에 국한된 것이 아니라, 미지의 무언가를 실무로 가져오려는 그 변화를 잘 이끌어내는 노하우에 대해서 소개했습니다. 그런만큼 안전하면서도 효과적으로 변화를 도입하고 힘을 받게 하는 스킬을 알려줘서 도움이 되었다고 느낍니다.
비단 테스트, 그리고 개발의 영역을 넘어 조직에서 일하는 비즈니스 구성원이라면 도움이 될만한 챕터였다고 생각합니다. 마치 처세술 같더라고요.
그냥 다 옮겨적은 것 같아요
그래서 이번 장은 특히 길었습니다. 내용을 이해하고 거를만한 게 아니라, 다 필요한 내용들이었습니다. 옮겨적으면서 머리에 많이 남기려고 했던 것 같네요.
작게 시작하여 성과를 누적하기
파일럿 프로젝트를 읽으며 실용주의 프로그래머에서 언급되었던 예광탄 기법과 프로토타입 기법이 생각났습니다. 큰 변화를 위해서 one-flow를 만들어보는 과정이 중요하다는 사실을 강조했죠. 0에서 1을 만드는 것이 역시 중요하다고 느낍니다.
기억에 남는 내용
사람을 움직여라
변화를 이끌어내는 과정에서 동료든, 상급자든, 진실된 공감과 이해, 그리고 참여와 지원을 확보해야 함을 강조하고 있습니다. 지지자는 더더욱 강력한 지지자로, 반대자는 오히려 권한과 책임과 역할을 주어 은근슬쩍 내 편으로. 아무튼 간에 내 사람으로 만들고 나를 밀어줘야 변화를 이끄는 게 가능하다는 거죠.
이 점에서 가장 기억에 남는 내용은 지지자 후보들에게 계획중인 일에 대해 의견을 구하라는 것입니다. 사전에 나의 계획과 변화에 힘을 실어줄 배경을 만들라는 거죠. 이건 정말 중요하다고 생각합니다. 새겨 들을게요.
진행 상황을 공유하라
큰 조직에서 일부만 파일럿 프로젝트를 진행하며 결과를 공공연하게 공유하는 것은 모두에게 자극이 되는 일입니다. 이 내용을 언급하며 공개적인 곳에 성과를 냄으로써 지켜야 하겠다는 부담과 동기부여를 받게 된다고 설명했는데, 공감이 많이 됐습니다.
제가 글또 수료 회고에서 공개선언 효과에 대해 썼던 내용이 생각납니다. 물론 그 선언한 주체가 나인지, 외부요인인지는 다를 수 있겠지만, 아무튼 나의 목표와 현황이 공개되어 있음에 가지는 동기는 꽤 큽니다.
한 가지 이유만 있는 게 아니다
요인은 복합적일 수 있다. 어떤 일이 더뎌질 때는 표면적인 한 두 가지 이유 때문이 아닐 수도 있음을 관철하는 내용이었습니다. 행동을 바꿀 때는 관련된 모든 내용을 바꾸라는 팁을 줬죠.
어떤 일을 분석할 때 정말 눈에 보이는 이유가 다인지 다시 한 번 검토하고 더 깊은 이유를 찾아보는 것에도 힘써야 하겠습니다.
단위 테스트의 효용
이 책에서 내내 강조하는 것이 단위 테스트의 효용이지만, 저는 아직까지도 단위 테스트의 작성이 개발 시간을 많이 늘린다는 사실이 두려워 겁 먹고 있던 것이 사실입니다. 하지만, 단위 테스트에 대한 어필 부분에서 그 딜레이는 확실히 인정하고, 다만 장기적으로 가지는 효용에 대해서 더 어필해주었습니다.
단위 테스트가 익숙해지고, TDD도 적용할 수 있을만큼 많이 실력이 늘어난다면 더할 나위 없을 것입니다. 실무에 적용해보려는 시도를 조금 더 해보겠습니다.
마치며
1개 장을 작성하면서 가장 많이 내용을 정리하고, 또 총평을 남긴 것 같습니다.
여기까지 보신 분이 계시다면, 긴 글 읽어주셔서 감사드립니다.
