쉬어가기[1]는 창의력을 끌어내는데 주안점을 두고 있고, 직접보기[2]는 생각을 현실화시켜 진정 원하는 것을 찾아가는데 초점을 맞추고 있다.

그리고 이제부터 살펴볼 수용하기는 변화를 권하고 받아들임으로써 개발자들에게 능동적 에너지를 불어 넣으려는 자세이다. 따라서 조직에서 권한을 쥐고 있는 윗사람들에게 크게 요구되는 자세이다.

조직에 변화를 불러 일으키려 할 때, 윗사람이 주도하는 하향식(top-down) 시도는 좋은 결과를 낳기 어렵다[3][4]. 특히나 한국처럼 수직적 위계질서가 철저한 문화에서는 윗사람의 지나가는 말 한 마디가 수십, 수백명을 고생하게 만들 만큼 파급이 크다. 심지어 조직 운명이 뒤바뀌기도 한다. 때문에 설사 올바른 말을 하더라도 확대 해석되고 준비도 없이 무조건적으로 즉시 수행하려해서 한 바탕 소동이 벌어지곤 한다.

효과적이고 지속적인 변화를 위해 윗사람에게 필요한 자세는, 변화를 겸허히 수용하고, 그런 분위기를 조성하고 문화를 만들어가는 것이다.

잠시 아쉬운 경험담을 하나 떠올려보겠다. 얼마전 수백명에 달하는 조직 구성원 전체가 모여 이것 저것을 공유하는 자리가 있었다. 그 중 임원들에게 궁금한 것을 여쭐 수 있는 시간이 주어졌고, 이런저런 이야기를 하다가 한 임원께서 조직의 변화에 대해 잠시 언급하셨다.

“조직은 쉽게 변하지 않는다. 조직이 변하길 기대하기보단 각자의 위치에서 스스로 변화시킬 수 있는 것을 찾아보아라.”

다소 차이가 있을 수 있으나 내가 이해한 의미는 이렇다. 현실의 모습을 있는 그대로 솔직히 이야기한 것이고, 남에게 바라기 앞서 스스로 변화를 시도하라는 좋은 이야기였다.

하지만 난 이 말에 적잖이 실망할 수 밖에 없었다. 왜일까? 만약 이렇게 이야기했다면 어땠을까?

“조직은 쉽게 변하지 않는다. 하지만 좋은 의견을 주면 내가 힘이 닿는데까지 그렇게 변화시킬 수 있도록 도와주겠다. 중간층에 있는 분들도 팀원들이 좋은 아이디어를 주면 최대한 반영할 수 있도록 힘써달라. 만약 내 힘이 필요하다면 누구든 도움을 요청하라. 다함께 힘이 닿는데까지 일할 맛 나는 팀을 만들어보자.”

조직은 쉽게 변하지 않는다는 사실엔 변함이 없다. 하지만 전자는 개인의 변화 의지를 크게 억누르는데 반해, 후자는 의욕을 한층 불살라줄 것이다.

중요한 것은.. 말과 격려에서 끝나면 안된다는 것이다. 불편사항을 누구든 편하게 개진할 수 있고, 개선 방법을 논의할 수 있는 장을 마련해 주어야 한다. 사람들이 쉽게 나서지 못한다면, 익명이 보장되는 토론장을 만들어주는 것이 큰 도움이 될 것이다. 애자일 회고(Retrospective) 제도[5]를 도입해 보는 것도 적극 권장한다. 그리고 이렇게해서 나온 좋은 아이디어들을 작은 것부터라도 하나씩 수용해가며 차근차근 개선되는 모습을 보여줘야 한다.

그럼 윗사람들이 주의해야할 점 몇 가지 집어보자.

‘이봐들! 개선 아이디어를 가져와봐!’ 라고 강압하는 것은 좋지 않다. 이런 명령은 실무자들이 스스로 불편사항을 찾고 자율적으로 개선해나가는 분위기에 찬물을 끼얻을 우려가 있다. 단, 익명 보장 등 조치를 취해 주었는데도 아무도 의견 개진 없이 시간만 흐른다면 한 번쯤 발동을 걸어주는 것은 필요할 수 있다.

‘얼마나 개선되었는지 보고해봐!’ 와 같은 요청은 더 큰 위험을 안고 있다. CMMI 나 SPICE 등 개발 역량 평가 모델의 더 높은 등급을 받기 위해 벌어지는 상황이 재현될 가능성이 높다. 다시 말해 수치적으로 측정 가능하고, 형식적인 변화에 치중될 우려가 생긴다. 심할 경우, 개발자들은 변화에 회의를 느끼고 더 이상 적극적으로 참여하지 않게 될 것이다.

가만히 놓아 두어도 개발자들은 알아서 쓸데 없는 일과 꼭 필요하지만 귀찮은 일 그리고 수작업 등을 줄이고 생산성을 높이는 방향으로 변화시킨다. 더 효율적인 솔루션을 찾아 시도해보고 적용한다. 물론 시행착오를 거친다. 그래서 더 안좋아지는 부분이 생기면 되돌아가거나 다른 안을 시도해보며 결국 생각할 수 있는 최선의 방식으로 수렴해간다. 제도와 권위로 가둬놓지만 않으면 팀은 좋은 방향으로 진화해 나갈 수 있다.

정리해보자.

• 윗사람은 변화를 주도하기 보다는, 변화 에너지를 불어 넣고 변화를 돕고 그 모습을 수용하자.
• 아랫사람은 능동적으로 변화에 참여하고 장단점을 몸소 체험하며 배우자.
• 상향식도 하향식도 아니다. 함께 만들어가는 변화이다.

---

References

1. 쉬어가기.. 혁신을 이끌어 내는 방법 (wegra.org)
2. 직접보기.. 혁신을 이끌어 내는 방법 (wegra.org)
3. 하향식 변화 도입에 대한 환상 (김창준, 애자일 컨설팅)
4. Bad Team Culture – 변화의 시작.. 상향식? 하향식? (wegra.org)
5. Bad Team Culture – Lessons Learned as a Last Will (wegra.org)

Lessons Learned

그간 이 팀 저 팀에서 발간(?)한 수많은 소위 Lessons Learned 라는 것을 봐온바 있다. 과제를 진행하면서 느끼고 배운 것을 정리하여 다음 과제 진행시 참고하거나 진행중인 다른 과제에서 참고할 만한 좋은 정보들이 적혀 있다. 자신이 걸어온 길을 되돌아보는 것은 좋은 경험이고, 그 결과를 정리해 놓는 것 역시 권장할 만한 일이다.

문제는 그 시점이 항상 과제가 뿌러지는 등 완전히 종료되는 시점에 일어난다는 것이다. 많은 경우 팀 자체가 뿔뿔이 흩어지거나 축소된다. 다음에 진행할 과제도 이전 과제와 성격이 달라지기 쉽다. 얻은 것이 있어도 그것을 적용해볼 상황이 못되는 것이다.

과연 이전 과제에서 깨우친 것들이 새로운 과제 새로운 팀에서 제대로 먹혀들 수 있을까? 시행착오를 거쳐보지 않은 새 팀 멤버들이 가슴 깊이 공감하고 따라줄 것인가? 배경이 다른 사람들에게도 똑같은 처방이 여전히 유효할까? 내가 얻은 결론은 정말 더 나은 개선책인가? 아니면 단지 ‘다음엔 이렇게 해봐야지’ 정도인가? 검증되지 않았고 경험해보지도 못한 방법을 새 팀 새 과제에서 시험해볼 용기는 있는가?

위와 같은 고민들도 어느 정도 영향력이 있는 윗사람들에게 해당하는 것이지, 중간 이하의 힘없는 관리자나 실무자들은 새로운 리더가 시키는데로 그냥 따를 수 밖에 없는 것이 또 현실이다.

결국 이런 식의 Lessons Learned 는 읽을 거리나 유언장 이상의 실질적 가치를 갖지 못한다.

Retrospective

Retrospective 는 Lessons Learned 의 Agile 식 표현 정도로 생각하면 좋을 것이다. 하지만 많은 차이를 안고 있음을 잊어서는 안된다. Agile 이 강조하는 iterative, responsive, incremental 같은 속성을 Lessons Learned 에 부여해보자. 짧은 간격으로 주기적으로 회고하며(iterative), 현 시점에 필요한 이슈에 대한 개선안 만들어 다음 개발 주기에 적용해보아 좋은 것을 취하고 잘못된 것은 버리거나 다른 안을 찾아본다(responsive). 팀은 과제가 진행될 수록 조금씩 조금씩 더 나은 방향으로 발전해 간다(incremental).

이미 끝나버린 과거에 대한 무책임한 회상록이 아닌, 지금 살아서 꿈틀대는 과제에 대한 진중한 고민을 경험해볼 수 있다. 바로 그 시점에 팀원들 스스로가 개선이 필요하다고 느끼는 이슈들이 다뤄지고 합의된 개선책을 시행한다는 점에서 참여율이 높아지고, 높은 성공 확률은 덤으로 얻게된다. 혹 실패한다면 바로 다음 회고 때 그 원인과 또 다른 개선안을 찾게될 것이다. 시행착오를 통해 더 많은 경험을 얻게되고, 미처 고려하지 못했던 요소들이 있음을 깨닫게 된다. 넓고 세심해진 시야는 다른 문제에 직면했을 때도 좀 더 빠르게 더 효과적인 개선안을 찾게 도와준다. 반면 Lessons Learned 방식에서는 실패한 처음 안만이 남겨질 가능성이 농후하다. 회고가 거듭될 수록 팀의 생산성이 향상됨을 느낄 수 있을 것이다.

Barriers and Ways to Overcome

다 좋고 완벽해 보이는 회고도 무턱대고 적용하려 하면 말처럼 쉽지 않음을 깨닫게 된다. 내가 지금까지 발견한 중요 요인은 3 가지 이다.

첫째, 일정에 쫓겨서 회고에 할애할 시간적 여유가 없다.

이런 답변을 많이 들었는데, 시간적 여유가 없는 것이 아니라 회고의 효과에 대한 믿음이 부족하거나 새로운 것을 시도하는 것을 꺼리는 보수적 마인드의 팀일 가능성이 높다. 이런 경우엔 분위기 조성을 위한 물밑 작업부터 시작해야 한다. 말이 통하고 깨어있는 사람들이라면 직접적인 대화로 돌파할 수 있겠다. 뜻이 맞는 팀원이 소수라도 존재한다면 솔선수범해서 더 나아지는 모습을 직접 보여줄 수도 있을 것이다. 상황이 다양한 만큼 방법도 다양할 터이니 숙고해서 도전해보자. 단, 상대를 공격하는 것은 확실한 실패 방법이니 절대 피하길 바란다.

참고로 회고에 필요한 시간은 보통 2~4주에 1시간 정도면 충분하다. 물론 처음 시작할 때는 좀 더 많은 시간이 필요할 것이지만 두세번만 해보면 익숙해지고 소요 시간도 줄어든다.

둘째, 팀원들의 참여가 저조하다.

기껏 회고를 해보자는 허락을 받았는데, 정작 모인 사람들이 꿀먹은 벙어리 마냥 침묵으로 일관한다. 회고를 처음 시도하는 조직에서는 대부분 겪게 되는 인기 코스일 것이다. 그들이 침묵하는데에는 여러 가지 이유가 있을 것이다. 무슨 얘길 하면 되는거지? 예제 같은 거 없나? 얘기한다고 정말 개선해 주나? 말 꺼내면 나보고 꺼낸 사람이 하라고 하겠지? 불평하면 괜시리 밉보일 거야.. 등등.

이런 우려를 해소하고 적극적인 참여를 유도하려면 맛을 보여줘야 한다. 사소한 것부터라도 정말 개선되는 모습을 보여주는 것이다. 첫 회의에서 아무런 아이디어가 없을 것을 대비해 문제점과 개선안까지 몇 가지를 준비해둔다. 뜻이 맞는 사람이 한 명이라도 있다면 역할극을 해보는 것도 좋다. 혼자 북치고 장구치는 것보다 훨씬 효과적으로 분위기를 이끌어 갈 수 있을 것이다. 그리고 개선안이 없더라도 불편한 사항을 자유롭게 이야기하도록 하고, 그에 대해 반박을 하거나 방어적인 모습을 보여서는 안된다. Brain storming 방식으로  문제들을 나열하고 중요도와 시급성, 파급 효과 등을 생각해 이슈를 선별해서 개선안을 모색해보자.

셋째, 팀에 부여된 권한이 너무 작다.

열심히 분위기 잡고 멋진 개선안들도 마련했다. 그런데 그 개선안들이 우리힘으로 할 수 있는 일들이 아니라면? 운영부서는 돈 들어가는 일은 절대 허락을 안해주고, 보안 부서는 개발자 편의성은 절대악으로 규정짓고, 프로세스 팀은 표준 프로세스에 어긋난 어떠한 시도도 용납하지 않고, 기획/마케팅 부서는 자신들이 바라는 모든 기능을 역시 자신들이 정한 시한까지 완수해야 한다고 못박고, 책상 앞에 앉아 있는 시간과 개발진도는 정비례한다고 철석같이 믿고 있는 임원이 군림하고 있다면?

회고는 불평불만을 토로하고 남들 뒷담화가 남무하는 장이 되던가, 소꼽장난하듯 사소한 문제들만 다뤄지는 비중없는 시간으로 전락할 것이다. 물론 작은 개선들이 차곡히 쌓여 큰 도움을 줄 수도 있을 것이고, 공동의 적을 향한 불평불만과 뒷담화는 팀원들을 단합시켜주는 효과도 있기는 하다. ^^

모든 것을 통틀어 가장 큰 장벽으로, 딱히 뾰족한 해결책도 없다. 때마침 임원 인사가 단행되어 깨어 있는 사람으로 교체되던가, 무슨 바람이 불어서 아주 권위 있는 컨설턴트의 도움을 받을 수 있다면 큰 힘이 될 것이다. 하지만 모두 다 운에 기대는 것이고.. 리더나 팀원들이 몸소 나서서 설득하고 싸우는 적극적 쟁취 방법도 물론 있다. 하지만 생태계에서 식물 급으로 취급되는 힘없는 개발팀이 얻어낼 수 있는 것은 많지 않을 것이다.

---

References

1. Retrospectives by RTC dev. teams
2. Agile Retrospective – Lessons Learned