쉬어가기[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)

STEN [1] 에서 재미난 설문을 하고 있다. 아직 진행중이지만 상황을 대략 파악할 정도는 나온 듯 싶다.

“국내 프로젝트에서 애자일을 도입했다가 실패했다면 그 이유는 무엇인가?”

1. 국내의 전반적인 소프트웨어 개발 프로세스 성숙도가 낮기 때문 (19.0%)
2. 과도한 애자일 프랙티스를 경험이 부족한 상태에서 여러가지를 동시에 적용하려 하기 때문 (25.4%)
3. 애자일한 개바 프로젝트에서 테스팅을 어떻게 해야할지 잘 모르기 때문 (9.5%)
4. 애자일 개발의 사상이나 이의 도입에 따른 개발 문화의 변화에 대한 고려없이 테크닉만으로 접근하기 때문 (44.4%)
5. 기타 (1.6%)

나는 4번을 찍었다. 물론 다른 이유들도 많다. 예를 들어 팀원 & 조직 전체가 변화의 필요성에 대해 공감한 상태에서 진행하느냐도 포함될 수 있다. 그리고 어느 하나의 이유보다는 여러 가지가 복합적이다.

나도 애자일 도입을 외치지만, 수많은 경험을 통해 아주 신중하게 접근해야 함은 뼈저리게 느끼고 있다. 어설프게 접근했다가는 ‘해봤는데.. 별 효과 없더라.’라는 부정적 인식만 남기기 쉽기 때문이다. 그리고 이는 소위 heavyweight 개발 프로세스 등 SE 가 지금껏 저질러왔던 과오이다. 애자일에서도 똑같은 일이 반복된다면 개발 문화를 개선할 수 있는 기회가 언제 다시 올 지 예측하기 어렵다.

---

References

1. STEN (Software Test Engineer Network)

‘쉬어가기.. 혁신을 이끌어내는 방법 [1]‘ 에서는 개발자들에게 쉬어갈 수 있는 시간을 제공함으로써 창의와 혁신을 이끌어는내는 이야기를 해보았다. 이번에는 ‘직접보기’라는 주제로 비슷한 이야기를 해보려 한다.

‘직접보기’ 가 필요한 이유는 아래의 그림을 보고 생각해보자. 이 그림이 말하고자 하는 원목적은 완전히 동일하진 않지만, 실물을 보지 않고 커뮤니케이션 했을 때의 문제를 효과적으로 말해주고 있다.

정리하면 고객이 원하는 것을 각 사람/조직마다 다르게 이해하고 있으며 심지어 고객 스스로도 자신이 무엇을 필요로 하는지 알지 못한다 것이다.

시장 조사를 토대로 고객의 needs 를 모두 만족시킨 제품의 출시 후 반응이 그리 좋지 않은 수많은 사례들을 잘 설명할 수 있는 논리이기도 하다.

혁신적인 제품을 잘 만들어내기로 유명한 애플(Apple)사의 경우, 신제품을 만들 때 시장 조사를 아얘 하지 않는 것으로도 유명하다(You Can’t Innovate Like Apple [2]). 시장에 존재하지 않는 제품에 대해 물어봐야 가치 있는 대답을 구하기 어렵기 때문이다. 대신 스스로 계속해서 실제품 수준의 프로토타입을 수없이 만들어보면서 직접 만져보고 써보며 자신들이 정말 이 제품을 원하는가를 판단한다. 그 결과 애플의 제품들은 종종 시장에서 당연히 필요하다고 생각하는 기능이 빠지기도 하고 이미 더 나은 제품들이 수두룩한데~ 라고 평가절하되곤 한다.

이미 만들어진 제품에 대해서는 다르다. 직접 사용해본 사용자들의 피드백은 소중하다. 애플 리테일 스토어가 중요한 역할을 수행하는데, 리테일 스토어의 직원들은 고객이 와서 들려준 이야기들을 놓치지 않고 본사로 보고하게 되어 있다. 그래서 스티브 잡스는 아이디어 도둑(유명 마케터 이해선 대표의 메시지 [3])이라는 말이 나오기까지 했다.

고객의 소리를 듣는 방식에 있어 두 경우가 다르다고 이야기했지만, 사실 그 원리는 동일하다. 바로 제품을 직접 만져보고 사용해본 사람들의 소리를 듣는다는 것이다.

이는 사실 애자일, 전통 할 것 없이 거의 모든 소프트웨어 개발 방법론에 중요하게 다루는 주제이고, 결론 또한 항시 동일하다. 짧은 반복 주기로 매 주기마다 동작 가능한 제품을 내놓고, 이를 고객에게 보여주고 피드백을 받는다. ‘당신이 말한 것을 우리는 이렇게 이해했는데, 이것이 정말 당신이 원했던 것이오?’ 를 확인하는 가장 중요한 절차인 것이다. 진정 공존을 원한다면 이 과정에서 쓸데없는 과장과 화려한 프리젠테이션은 없어져야 한다. 그리고 프로젝트 진행에 관련된 주요 인력들이 다 참석하는 것이 좋다. 고객, 프로젝트 리더, 영업 담당자, 주요 개발자들 등이 포함된다. 이들이 자주 모여 현실을 냉정하게 보고 허물없는 이야기를 하다보면 다음과 같은 반응들을 심심치 않게 목격할 수 있을 것이다.

1. 내가 말했던 건 이게 아니었어요. 이러저런 모습을 상상했었는데요. 다음 릴리즈땐 이렇게 고쳐봐주세요.
2. 내가 의도했던게 이게 맞긴 한데.. 직접 써보니 좀 이상하군요. 다른 아이디어가 있을까요?
3. 이 부분은 제 생각과 다르긴 하지만.. 솔직히 지금이 더 좋아 보이는군요. 이대로 갑시다.

직접 보기는 서로의 생각을 확인하고 공유할 수 있는 가장 좋은 방법이며, 다음 방향을 결정짓기 위한 논의를 시작하기 위한 믿음직한 베이스가 되어준다.

또한 개발자들에게는 자신들의 창의력과 열정을 어필할 수 있는 절호의 기회가 되기도 한다. 직접 구현하면서 가장 먼저 써보게 되는 개발자들은 가장 빠르게 피드백을 줄 수 있는 훌륭한 고객인 셈이다. 이해한 요구사항대로 구현했을 시 불편한 부분이 있거나 더 나은 안이 떠오르면 릴리즈 전에 그 아이디어를 정리해두자. 가능하다면 직접 구현해서 보여주는 것이 가장 좋다. 직접 사용해본 고객과 말이나 문서 정도로만 본 고객은 확연히 다른 반응을 보인다.

이런식으로 개발자들의 능력을 인정받고 발언권을 강화해두는 것이 조직 전체의 커뮤니케이션과 생산성 향상, 제품 혁신에 긍정적인 영향을 줄 것이다. 개발자들은 기본적으로 창의적인 인력들이며, 이에 더해 현실적이다. Sci-fi 영화에나 나올 법한 허무 맹랑한 꿈을 꾸지도 않고, 일부러 과장하려는 경향도 적다. 먼 과거와 달리 골방의 괴짜들이 모여 있는 집단도 아니다. 윗사람들보다 신세대이며 소비의 주체라는 장점도 있다.

결론?

조직은 제품을 직접 보고 함께 이야기하는 문화를 정착시킴으로써 많은 것을 얻을 수 있다. 단, 어설프게 릴리즈 압박용으로만 오용하지 않도록 주의하자. 상향식 변화는 실패할 것이며, 하향식 변화는 성공한 것 처럼 보일 것이다. ^^ [4]

[updated]

사례를 몇 가지 추가해보기로 하였다.

• Developing Torchlight [5] – Runic Games 사에서 Torchlight 라는 게임을 제작하는 방식을 이야기한다. 그들은 짧은 주기로 항시 play 가능한 게임을 만들어 개발자, QA 팀, 심지어 그드의 가족, 친구들까지 초대해서 게임을 즐기게 했다고 한다. 시장에서의 성공 여부는 아직 판가름하기 이르지만 기대를 가지고 지켜보고 있다.
• 와우 성공 요인은? [6] – 초창기 와우 개발을 이끌었던 블리자드의 수석 PD 인 셰인 다비리 를 인터뷰한 내용이다. 초창기 가장 어려웠던 점 중 하나는 블라지드로써는 낯선 장르였던 MMORPG 의 비전을 경영진에 설득하는 것이었다고 한다. 직접 만들어 알파 버전을 보여주니, 절대 성공할 수 없다고 말하던 사람마저 하루 아침에 자신의 편이 되었다 한다.
• Eclipse [7] 와 Jazz/RTC [8] – 오픈소스 개발 환경 프로젝트 중 역사상 가장 성공적인 프로젝트 중 하나인 Eclipse 와 그 개발 과정에서 얻은 노하우까지 툴에 녹이고 있는 Jazz/RTC 프로젝트도 좋은 예가 될 수 있다. 이들은 1년 주기의 정식 릴리스 사이에 6주 정도의 간격으로 다수의 안정적인 Milestone 버전을 내놓는다. 그리고 이전 릴리스 대비 어떤 기능이 개선되었는지 알기 쉽게 보여주는 New & Noteworthy 를 함께 알려주어서 사용자들이 정식 릴리스를 기다리지 않고도 새로운 기능들을 빠르게 접해볼 수 있다. Milestone 버전은 충분히 안정적이기 때문에 critical 한 프로젝트가 아니면 큰 부담 없이 새 milestone 을 테스트해본다. 이런 방식으로 사용자 커뮤니트의 빠른 피드백을 유도해 지속적으로 다음 릴리스에 반영해나간다.
• Mobile SecondLife [9] – 내가 참여해 진행하다 중단된 프로젝트다. 과제 초창기부터 개발진에서는 도저히 성공 가능성이 없다고, 이걸 누가 쓰겠냐며 과제의 의미를 찾지 못하고 있었다. 링크의 데모는 연구 성격의 개념적 시연이어서 상당히 제한적인 환경에서만 동작 가능했다. 이를 바로 상품화하려 하니 현실적인 제약들 때문에 흥미로운 개념들의 거의 모두를 다 들어낼 수 밖에 없었다. 남은 것만으로는 정말 시도할 가치가 없는 과제였다. 하지만 그 목소리가 경영진에까지 전파되지는 못했다. 수개월간의 고생 끝에 만들어진 베타 버전을 임원에게 시연한 바로 다음날 과제는 바로 중단되었다.

---

References

1. 쉬어가기.. 혁신을 이끌어내는 방법 (wegra.org)
2. You Can’t Innovate Like Apple (Pragmatic Marketing)
3. 유명 마케터 이해선 대표의 메시지 (제레미의 TV 2.0 이야기기)
4. Bad Team Culture – 변화의 시작.. 상향식? 하향식? (wegra.org)
5. Agile Approach in Game Development (wegra.org)
6. 와우 성공 요인은? 전 수석 PD 셰인 다비리 인터뷰 (Inven Communications)
7. Eclipse (Eclipse Foundation)
8. Jazz/RTC (IBM Rational)
9. Mobile SecondLife (Samsung)

조직의 변화에 대해 이야기할 때, 상향식(bottom-up), 하향식(top-down) 운운하면서 서로 책임을 회피하는 경향이 심하다는 느낌이다.

상향식은 조직의 아랫사람들부터 변화의 물결이 일어 결국 윗사람들까지 동참시키는 경우이고, 하향식은 반대로 윗사람의 의지에 의해 아래까지 변화를 일으키는 방식이다.  어느 방식이 더 나은 선택이 될 것인가? 만약 어느 한쪽을 운운하는 사람은 변화도입에 대한 전문성이 부족하거나(하향식 변화 도입에 대한 환상[1] – 김창준), 혹은 자신의 책임을 회피해보려는 시도를 하고 있다고 볼 수 있을 것이다.

하향식 변화 도입에 대해선 위 김창준씨의 글을, 상향식 변화 도입에 대해서는 일전에 내가 작성해둔 글 – Show Me The Magic[2]을 참고하면 좋을 것이다. 그리고 그 둘의 결론 역시 Show Me The Magic 에 잘 나타나 있다.

그럼에도 이 글을 적는 목적은, 조직에서 자신의 위치, 자신의 역할에 대한 자각의 필요성을 느껴서이다.

내가 변화시켜보려 했던 팀에서 가장 큰 문제들은 바로 하급 관리자가 조직의 머리에 해당하는 사람들의 논리를 대변한다는 것이었다. 대략 8 단계로 이루어진 조직 피라미드의 밑에서 3번째에 위치한 사람들에 해당하는 이야기이다.

아래에서 3번째이면 말단 관리자, 즉 아래에서부터 올라가 최초로 ‘관리자’라는 타이들을 달아볼 수 있는 직급이다. 이 계층의 구성원들이 ‘먼저 다른 사람들을 다 설득시키고 나한테 오라’, ‘정말 좋으면 내가 참여 안해도 다들 하겠지’ 라는 말을 하고, 뒷짐진채 ‘자! 재주껏 나를 설득해봐!’ 라는 자세를 취한다. 그러면서 ‘역시 상향식 변화는 안되’라고 말하는 모습을 보며 ‘당신이 현 조직에서 윗사람에 해당한다고 생각합니까?’라는 말이 목구멍까지 올라왔지만 참은 적도 몇 번 있다. ^^

그 계층에서부터 공감대를 형성하고 의지를 다져 변화를 이야기해야 비로서 ‘상향식 변화의 첫 발을 내딛었다’ 라고 할 수 있다. 아랫 사람들의 목소리를 전파해줄 수 가장 낮은 위치의 사람들이 그 위치에 올라서자마자 이런 마음자세로 돌변한다면, 그 조직은 절대 변화할 수 없다. 그렇다면 하향식 변화를 기대해야 할까? 그것 역시 환상이다[1].

이 글을 읽는 분들은 자신이 조직에서 어느 위치에 있는지, 그 위치에서 어떤 역할을 해주어야 더 나은 조직으로 변화할 수 있을지 찬찬히 생각해보았으면 한다.

---

References

1. 하향식 변화 도입에 대한 환상 (애자일 이야기, 김창준)
2. Bad Team Culture – Show Me The Magic (wegra.org)