당신의 조직에서 새 방법론이 먹히지 않는 이유
심리치료 연구에서 기념비적인(그러나 불행히도 크게 조명받지 못한) 연구(D.F. Ricks, 1974)가 하나 있습니다. 아이였을 때 뉴욕주에서 심리치료를 받은 어른들을 조사했을 때 정상적인 생활을 잘 하고 있는 건강한 사람도 있었고 그렇지 못한 사람도 있었습니다. 무엇이 이들을 가르는 중요 요인이었을까요. 어떤 방법/기법으로 심리치료를 받았느냐, 어디에서 받았느냐 등은 관련이 없었습니다.

심리치료를 한 사람이 누구였느냐가 중요했죠. 특정 심리치료사에게서 치료를 받았던 아이들은 다른 아이들에 비해 놀라운 결과를 보여주었습니다. 당시 아이들 사이에서는 그 치료사를 일컫는 별명이 있었습니다. 이름하여 슈퍼슈링크(supershrink -- 뛰어남을 뜻하는 super와 정신과의사를 일컫는 shrink의 조어).

상담학계에서 공통 요인(Common Factors) 학파로 불리우는 이멜과 웜폴드는 맥케이와 함께(McKay, Imel, Wampold, 2006) 소위 "치료자 효과"라고 불리우는 요인을 좀 더 연구했습니다. 그들의 연구에 따르면, 우울증 치료에 있어 상위 삼분의 일에 해당하는 정신과의사가 설탕약을 준 경우(플라시보 조건)가, 하위 삼분의 일에 해당하는 의사가 항우울제(이미프라민)를 준 경우보다 더 높은 치료 효과가 있었습니다. 설탕물을 받아 먹더라도 뛰어난 의사한테 가는 경우에 치료 효과가 더 높다는 놀라운 결과가 나온 겁니다.

이런 치료자 효과에 대한 연구는 2000년대 이후 많이 진행되었는데, 결과들을 보면 상담에서 어떤 기법(예컨대 인지행동치료, 로저리안, 게슈탈트 등)을 쓰느냐보다 치료자가 누구인가가 상담효과에 더 큰 영향을 준다고 거듭 밝혀졌습니다. 어떤 기법을 사용하느냐는 것은 통상 상담 결과의 분산에서 5% 이하만을 설명한다고 봅니다(최대한 높게 봤을 때). 반면 상담자간의 차이에서는 뛰어난 상담자는 평균적인 상담자보다 10배 빠른 치료효과를 보여줬습니다.

치료자 효과에 대한 관심이 생기기 시작한 것은 비교적 최근의 일입니다. 심리 상담의 효과 연구에서는 주로 이런 "치료자 효과"를 제거하고 기법, 방법론의 효과를 연구하려고 해왔습니다. 대표적인 방법이 매뉴얼을 제공하고 그걸 따라하게 하는 것이죠. 하지만, MI라고 하는 비교적 근거가 많은 상담 기법의 메타분석(70여개의 임상시험 대상) 연구에 따르면 매뉴얼이 제공된 경우 치료의 효과 크기가 그렇지 않은 경우에 비해 절반 밖에 되지 않는 것을 발견했습니다(Hettema, Steele, Miller, 2005). 저자들은 자신의 다른 연구에 근거해, 상담사가 매뉴얼을 정확히 따르면서 명시된 단계를 끝내려다가 내담자의 상태를 제대로 확인하지 못하고 단계를 마무리한 부작용이 생겼다고 예를 들고 있습니다.

이 이야기는 매뉴얼이 말하고 있는 것보다 훨씬 더 많은 것을 상담사들이 할 수 있다는 말이 될 것입니다. 마이클 폴라니는 "우리는 말할 수 있는 것보다 더 많이 알고 있다"라고 암묵지의 중요성을 이야기했죠. 사실 더 나아가서 모든 지식이 근본적으로는 암묵지라고 역설했습니다. 어떤 기법이나 방법론이 말하고 있는 것은 극히 부분적이며 오로지 그것으로만 지도를 삼기에는 위험이 클 수 있는 거죠. (제가 저번에 쓴 실수는 예방하는 것이 아니라 관리하는 것이다도 비슷한 맥락입니다)

자신이 관심있는 분야에 "만약 ~하면 ~하라"라는 널리 인정되는 규칙이 있는가, 그런 규칙들을 잘 따른다면 얼마나 성과를 낼 수 있을까 생각해 보세요. 만약 그런 규칙이 커버하는 부분이 넓다면 해당 분야는 "단순한 도메인"에 해당합니다. 소위 베스트 프랙티스가 먹히는 분야이고, 결과 예측이 가능한 분야이죠. 하지만 반대로 맥락을 가로지르는 보편적 규칙들이 별로 없다고 생각이 든다면, 결과 예측하기가 어렵고 불확실성이 높다면 해당 분야는 "복잡한 도메인"(cynefin framework에 따르면 complex domain)이 됩니다. 통상 사람 요소가 차지하는 비율이 많을수록 복잡한 도메인에 속합니다. 상담이 그렇죠. 이런 복잡한 분야일수록 어떤 특정 기법의 효과보다도 치료자 효과가 더 큰 영향을 미칠 것입니다.

그렇다면 어떻게 해야할까요? 슈퍼슈링크들을 찾고 그들을 연구하고 육성해야 합니다(여러분들 주변의 슈퍼슈링크들은 누구이고 평소 행동은 어떻게 다른가요?). 그러면서 이런 연구를 토대로 우리가 사용하는 기법과 방법론들을 더 발전시켜 나가야겠죠. 아마 그 모습은 여러 방법론들의 통합적인 모양새에 가깝지 않을까 싶습니다.

이제 소프트웨어 개발 방법론 이야기로 넘어가보죠. 상담과 소프트웨어 개발은 다른 부분이 같은 부분보다 더 많겠지만 두 분야 모두 예측이 어렵고 복잡한 도메인이라는 점에 대해서는 대부분 인정을 하지 않을까 싶습니다(아마도 소프트웨어 개발을 하는 사람들은 자신의 분야가 더 예측이 어렵고 더 복잡하다고 주장을 하실 것 같습니다만). 그렇다면 여기에서도 이런 치료자 효과가 기법/방법론 효과보다 크거나 적어도 필적하지 않을까 하는 질문을 해보면 어떨까요. (여담이긴 한데, 애자일 방법론 중 특히 스크럼에서 앞서 말한 암묵지가 필요 없는 듯이 이야기되는 경우 -- 즉 단순한 규칙들을 지키면 된다고 하는 경우 -- 를 보면 우려가 됩니다. 복잡한 영역인데 단순한 것처럼 이야기한다고 할까요?)

새 프로젝트를 진행할 때에 우리가 어떤 방법론을 쓰느냐는 문제보다도 누가 참여하는가가 훨씬 더 압도적인 문제가 아닐까요? 여러분은 어떻게 생각하시나요?

저는 이렇게 생각합니다. 예를 들어 애자일 방법론 도입을 원하는 팀장이라면 "나는 어떤 팀장인가"를 먼저 자문해봐야 하지 않을까 싶습니다. 내가 어떤 팀장인지가 전혀 바뀌지 않으면서 새 방법론만 도입한다고 무슨 효과가 있을까요. 반대로, 항우울제보다도 강력한 설탕물을 쓸 수 있는 의사처럼, 별 볼일 없어보이는 방법론일지라도 그걸 처방하는 팀장에 따라 전혀 다른 효과가 있을 겁니다.

--김창준
by 애자일컨설팅 | 2014/03/01 21:43 | 트랙백 | 덧글(7)
트랙백 주소 : http://agile.egloos.com/tb/5792529
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Commented by 깸용 at 2014/03/02 07:38
잘 읽었습니다. 암묵지 얘기는 칼폴라니 동생 마이클 폴라니 아닌가요?
Commented by 애자일컨설팅 at 2014/03/02 12:48
오자네요. 감사합니다. ^^
Commented by 안영회 at 2014/03/02 09:31
본문에 인용하신 주장, '스크럼에서는 단순한 규칙들을 지키면 된다'는 말이 암묵지를 형식지로 바꾼 효과를 의미하는 것이라면, 이는 도메인이나 프로젝트 맥락에 영향을 받지 않는 보편적인 틀을 영역에 해당하는 내용이라 생각합니다.
실제 방법론이 작동하려면 프로젝트 맥락에 맞게 역할을 설정하고, 도메인과 프로젝트 일정/진행방식/작성자와 읽는 사람을 고려하여 사용자 스토리를 쓰는 등 해당 환경에 맞게 사람이 판단하고 적용(지속적인 보완 포함)해야 하는데 이 부분을 방법론화 하는 것은 이론적으로는 가능할지 모르지만, ROI가 나지 않는 소모적인 일이 아닐까 싶습니다. 코드를 작성하는 방법을 모두 방법론화 할 수 없는 것과 같은 이치가 아닐까요?
(마치 추상 클래스를 이용하여 소프트웨어의 Dependency를 통제하는 원칙(Robert Martin)의 논문의 예시를 스크럼의 효용성에도 적용해볼 수 있다는 생각이 순간 스쳤는데...)
Commented by 애자일컨설팅 at 2014/03/02 12:55
> 본문에 인용하신 주장, '스크럼에서는 단순한 규칙들을 지키면 된다'는 말이 암묵지를 형식지로 바꾼
> 효과를 의미하는 것이라면,

네. 그 과정에서 지나치게 단순 모형화 된 경우가 많지 않나 생각합니다.

> 이는 도메인이나 프로젝트 맥락에 영향을 받지 않는 보편적인 틀을 영역에 해당하는 내용이라
> 생각합니다.

네. 절차적 지식, 다양한 에이전트의 상호작용이 중요하고, 불확실성이 높은 영역일수록 암묵지의 중요성이 높아지리라, 또 형식지 과신의 위험성이 높아지리라 생각합니다.

> 실제 방법론이 작동하려면 프로젝트 맥락에 맞게 역할을 설정하고, 도메인과 프로젝트 일정/진행
> 방식/작성자와 읽는 사람을 고려하여 사용자 스토리를 쓰는 등 해당 환경에 맞게 사람이 판단하고
> 적용(지속적인 보완 포함)해야 하는데 이 부분을 방법론화 하는 것은 이론적으로는 가능할지 모르지만,
> ROI가 나지 않는 소모적인 일이 아닐까 싶습니다. 코드를 작성하는 방법을 모두 방법론화 할 수 없는
> 것과 같은 이치가 아닐까요?

네. 동의합니다. ^^ 매뉴얼에 의존 덜하면서 높은 성과를 낼 수 있는 자율적 에이전트들을 어떻게 키울 것인가 하는 부분을 고민해야 하는 문제겠지요.

> (마치 추상 클래스를 이용하여 소프트웨어의 Dependency를 통제하는 원칙(Robert Martin)의 논문의
> 예시를 스크럼의 효용성에도 적용해볼 수 있다는 생각이 순간 스쳤는데...)

재미있는 아이디어로군요. 추상 클래스가 일종의 방법론이 되고 사람들은 그 추상 클래스 자체로는 인스턴스를 만들어 사용할 수 없다는 걸 알면 좋겠네요... ㅎㅎ
Commented by 배휘동 at 2014/03/03 13:01
이번에도 역시 좋은 글 감사합니다. 교육 분야에서도 비슷한 맥락으로 얘기할 수 있을 것 같은데...

제가 준비하고 있는 교육벤처의 서비스를 '지시사항에 따라 작성해 나가면서 꿈을 떠올리고, 꿈에 내 인생을 걸 만한지 검토할 수 있는 온라인 꿈 찾기 노트'로 정의하고 있습니다. 이 '지시사항'이 '매뉴얼'이 되지 않도록 주의해야겠네요. 추가로, 사용자가 작성한 노트를 보고 피드백을 할 수 있게 하려는데, 이 때에도 매뉴얼이 아니도록 해야겠고요.

'명시된 단계들을 따르기보다는 상대방의 상태에 집중하라'는 걸 기억하겠습니다.
Commented by 안재현 at 2014/07/18 16:30
좋은 글 감사합니다. 읽는 내내 마음이 시원했습니다.
Commented by 박대현 at 2014/07/27 23:20
좋은 글이네요. 방법론에 의지하지말고 유연하게 적용해야한다는 지난 말씀이 떠오릅니다. 그만큼 팀장으로서의 판단력이 중요한거 같네요. 팀원으로서도 고민을 해야된다고 생각합니다.
많이 배우고 갑니다.

:         :

:

비공개 덧글

< 이전페이지 다음페이지 >