빈가게 게시판 24(월) 8시 빈가게 제안서(아무거나 작은거라도) 회의
2011.01.27 02:49
저자 워크숍
dWkorea | Aug 13 2010 | Tags: column agile | Comments (0) | Visits (477)
2008년 12월 30일
뭐 하러 우릴 불렀수?
모 개발자가 몇 달에 걸쳐 개발한 것을 발표하고 의견을 수렴하는 자리. 같은 회사 다른 부서에서 여러 사람이 왔다. 발표는 순탄했다. 마지막 질문 답변 시간. "저건 왜 저렇게 하셨나요? 그렇게 해서 제대로 성능이 나오겠어요?" 개발자가 보기엔 질문하는 사람이 멍청해 보인다. 내가 얼마나 고생해서 만들었는데 설마 그런 걸 고려 안 했으리라고. "아뇨, 당연히 나옵니다." 또 다른 질문. "아까 그 부분은 이렇게 개선하면 어떨까요?" 이젠 얼굴이 상기되기 시작한다. "아뇨, 지금 방식이 더 좋습니다. 왜냐하면..." 열기가 뜨거워지면서 좀 더 본격적인 비판도 나온다. "처음부터 개발 방향이 잘못된 건 아닌가요?" 눈 앞이 캄캄해지고 가슴 속에서 뜨거운 뭔가가 올라온다. 한 30분 쯤 흘렀을까? 그 개발자는 나름 모든 질문에 선방했다고 생각하던 차, 누군가 손을 들고 말한다. "우리는 도대체 왜 불렀습니까?"
누가 문제였을까? 우선 개발자는 이제껏 잘못된 교육을 받았다. 이런 자리에는 피드백을 받는 것이 목적이 아니고 내 작품이, 그리고 나 자신이 성공적이라는 것을 증명해 내야한다고 무의식 중에 믿어왔다. 다른 경험을 할 기회가 별로 없었다. 또 개인적으로는 자신감이 부족하고, 자존감도 낮았을 것이다. 통상 이런 사람일수록 다른 사람의 비판에 굉장히 감정적으로 대응한다. 마음에 여유가 없기 때문이다. 오히려 고수일수록 사소한 시비에 말리지 않는다. 참관자들 입장에서도 고칠 점이 있다. 좀 더 긍정적이고 친근한 방식으로 피드백을 주지 못했다. 이런 자리는 발표자와 제품의 약점을 찾아내는 것이, 그리고 그렇게 해서 내가 똑똑하다는 사실을 증명하는 것이 목적인 게임이라고 은연 중 생각한다.
PLOP
나는 수년 전에 플랍(PLOP, Pattern Language of Programs)이라는 컨퍼런스에 참가할 수 있었다. 1994년 처음 열렸고 그 이후 해마다 열렸던 나름 유서 깊은 컨퍼런스로, 이 컨퍼런스를 통해 소프트웨어 개발에 패턴 문화가 퍼질 수 있었다고 해도 과언이 아니다.
내가 특히 주목했던 점은 플랍의 문화였다. 매우 독특한 문화가 있었는데, 그것은 여러 자매 플랍 컨퍼런스를 통해 세계에 퍼져나가게 되었다. 일본에서도 이 문화와 프로세스를 궁금히 여겨 일찌기 사절단 몇 명이 플랍에 참석해 문물을 배워왔다. 하지만 흥미롭게도 한국에서는 이 플랍의 문화, 패턴이 만들어지는 과정에 대해서는 별 관심이 없었고 단지 그 최종 결과물이라 할 수 있는 서적화된 패턴 모음집에만 시선을 뒀던 것 같다.
나는 언제나 사람들의 사회적 동역학과 과정에 대해 큰 관심을 갖고 있었다. 대학 다닐 때 어느날 밤인가 회의를 효과적으로 하는 책(마이클 도일과 데이비드 스트라우스 공저의 How to Make Meetings Work란 책이다)을 보고는 가슴이 두근거려 잠을 제대로 잘 수 없었다. 누운 채로 머릿속에서 시뮬레이션을 해봤다. 다음날 나는 후배들을 데리고 회의를 소집했다. 내가 책에서 본 그대로 진행해 봤다. 어랏! 정말 먹히는 것 아닌가. 마지막에 사람들에게 소감을 물었다. "형, 정말 회의가 효율적으로 진행되는 것 같아요, 대단해요!" 나는 응대했다. "얌마, 원래 이렇게 하는 거야."
이런 나로서는, 플랍에 대한 막연한 실체를 느끼고는 정말 너무도 궁금했다. 어떻게 그 과정이 이루어질까? 사람들간의 인터액션은? 구체적으로 이 순서 다음엔 어떻게 해야 하지? 자리 배치는? 대학교 다닐 때부터 동경해왔던 컨퍼런스다. 그러다가 꿈에 그리던 플랍에 가게 된 것이다. 마침내.
그곳에서 나는 리처드 가브리엘(Richard Gabriel), 가이 스틸(Guy Steele), 워드 커닝햄(Ward Cunningham) 같은 컴퓨터계의 영웅들, 패턴의 유명 저자들과 얼굴을 마주 보고 앉아서 종일 치열한 지적 토론을 할 수 있었다. 온종일. 내게는 상당히 충격적인 경험이었다. 천재들이 토론하는 모습을 목전에서 보고, 내가 그 토론에 참여한 것도 충격적이긴 했지만(지적 토론을 해보면 그 사람이 얼마나 똑똑한지 그야말로 정직하게 느낄 수 있다), 그 사람들이 컨퍼런스를 진행하는 방식과 그 문화 자체에 더 큰 경이감을 느꼈다.
플랍 이야기를 꺼낸 것은 내가 이제까지 겪었던 문화와 플랍에서 겪은 문화의 차이점 때문이다. 플랍에서는 달랐다. 그 사람들은 자기가 하는 것을 발표회가 아니라 워크숍(workshop)이라고 했다.
저자 공동 수련
워크숍은 외래어로 국립국어원의 표준국어대사전에서는 "공동 수련"으로 순화해서 쓸 것을 권하고 있다. 맘에 든다. 공동 수련이라.
플랍에서는 라이터즈 워크숍(Writers' Workshop)이라는 행사가 일종의 핵을 이루는데(그 외에도 다양하고 독특한 행사가 많다), 그 말을 옮기면 "저자 공동 수련"이 된다(멋지다. 하지만 너무 낯설게 느껴져서 이 글에서는 일단 저자 워크숍으로 쓰겠다).
이제부터 설명하려는 이 저자 워크숍이라는 것은, 여러 사람의 의견을 통해 저작물을 개선하려는 경우에 모두 적용할 수 있다. 어떤 종류의 저작물이건 가능하다. 저자 워크숍을 통해 문두에 예를 들었던 제품 의견 수렴회를 대체할 수도 있고, 시인들이 모여 자신의 시를 갈고 닦을 수도 있으며, 논문 준비하는 학생들이 자기 논문을 개선할 수도 있고, 화가들이 그림을 개선할 수도 있으며, 당연히 개발자들이 자기들의 소스 코드를 개선할 수도 있다. 뭐든지 개선이 가능하면 된다.
저자 워크숍은 19세기 말, 아이오와 대학에서 시작되었다. 이 워크숍은 매우 성공적이어서, 예를 들면 이곳 출신 퓰리처상 수상자만 16명이 될 정도다. 아이오와 대학의 저자 워크숍은 빠른 속도로 저자 커뮤니티 사이에 번져나갔고, 현재는 초중급 작가들이 자신의 실력을 빠르게 높일 수 있는 매우 효과적인 방법 중 하나로 알려져 있다.
하나의 전문 분야에서 무엇인가가 대성공을 이루면 당연히 다른 분야에서 그것을 도용하게 되어 있다. 리처드 가브리엘(시인이면서 프로그래머다)이 문학 쪽에서 이 저자 워크숍을 훔쳐왔다. 그래서 소프트웨어 패턴으로 저자 워크숍을 하게 되었고, 나아가서는 소프트웨어 쪽만 아니라, 마케팅 캠페인, 요리, 비즈니스 기획, 음악, 인테리어, 헤어 스타일 등 다양한 분야에 걸쳐 적용되었다.
플랍 컨퍼런스에서 저자 워크숍을 진행하는 모습(사진 출처)
어떻게 진행하는가?
저자 워크숍에는 저자, 중재자(moderator), 참가자, 세 가지 역할이 존재한다.
저자는 워크숍에서 실제 리뷰할 저작물을 만든 사람이다. 중재자는 워크숍을 원활하게 진행하는 사람이다. 참가자는 스스로 저자는 아니지만 워크숍에 참가하는 사람이다. 저자(여러 명)와 중재자만으로 워크숍을 할 때 가장 효과적이다. 자신의 저작물이 따로 없고, 그것을 리뷰한다는 생각이 없으면 워크숍 그룹 내 신뢰 형성이 상대적으로 쉽지 않다고 한다.
좌석은 원으로 둥그렇게 앉고 가운데에 테이블 같은 장애물이 없는 것이 좋다. 참가자가 있다면 그 사람들은 외부 원에 두고 내부 원에 저자들과 중재자가 앉도록 하는 것을 권하기도 한다. 차후에 설명하겠지만 저자가 '벽 위의 파리' 역할을 할 때에는 내부 원에서 빠져나와 외부 원에 앉는 것도 좋다.
참가 인원은 전체 100명이 넘을 수도 있지만, 하나의 워크숍 그룹은 통상 20명을 넘지 않는다(내 경험으로는 되도록 숫자가 열 명을 넘지 않는 것이 좋은 것 같다). 인원수가 많으면 여러 워크숍 그룹으로 나눠 병렬 진행을 한다. 한 그룹에서 많으면 저작물 열 개를 순차적으로 리뷰한다. 짧은 경우 한 두 시간만에 끝나고 길 때에는 종일, 며칠에 걸쳐 진행하기도 한다. 그러는 사이 하나의 워크숍 그룹은 계속 함께 토론을 진행하며(그룹을 옮기는 것은 예외적이다), 그 사람들 사이에 강한 유대감과 신뢰가 형성된다.
전체 진행 순서는 다음과 같다.
1. 글을 읽는다.
2. 저자를 환영한다.
3. 저자가 일부분을 읽는다.
4. 요약
5. 긍정적 피드백
6. 개선 제안
7. 저자의 질문
8. 저자에게 감사하기
이 과정을 시작하기 전에는 물론 저작물이 준비되어 있어야 한다. 완성품보다는 작업 진행 중인 것이 좋고, 그렇다고 일단 해보고 버릴 작정인 초안은 맞지 않는다.
1. 글을 읽는다
되도록 워크숍 직전에 글을 읽는 것이 좋다. 너무 많이 준비하거나 너무 적게 준비하거나 하는 걸 막고, 머리 속에 아직 그 느낌이 생생하게 살아있는 상태에서 진행하기 위해서다. 읽을 때에는 논평하고 싶은 것을 저작물 자체에 표기를 해두는 것이 좋다.
2. 저자를 환영한다
플랍과 저자 워크숍에는 선물 문화가 있다. 저자 워크숍에서 리뷰를 하는 작품의 저자는 자신의 미완성 저작물을 다른 사람들이 읽을 수 있는 기회를 선물하고, 다른 사람은 저자에게 그 작품을 개선할 아이디어들을 선물하는 셈이다. 그래서 플랍 컨퍼런스에서는 각자 자기가 가져온 작은 선물을 서로 교환하기도 한다. 이 때에 중재자가 저자의 경험 등을 소개할 수도 있다.
3. 저자가 일부분을 읽는다
저자는 자신이 쓴 글에서 통상 핵심이라고 생각하는 단락이나 섹션 하나를 소리내어 읽는다. 경우에 따라 한 쪽을 읽기도 하고, 소스 코드라면 주석문을 읽을 수도 있다. 특별한 요청 사항이 있다면 이 때에 이야기한다.
이제부터는 저자는 침묵해야 한다. 저자 워크숍에서는 '벽 위의 파리'가 된다고 한다. 7번 단계가 될 때까지 저자는 정말 벽 위에 파리가 돼서 사람들에게 말을 걸 수가 없다. 사람들 역시 저자에게 말을 걸 수 없다. 예를 들면, 저자의 얼굴을 쳐다보면서 "저기요, 여기 이 부분이 이해가 안되는데요..."하는 말을 하면 안 된다. 저자라는 인격체를 되도록 언급하지 않고, 작품 자체를 언급하는 것이 필요하고, 필요하다면 그냥 "저자"라고 이름하는 것이 낫다. 저자는 사람들이 자기 작품을 오해한다는 생각이 들어도 절대 해명하려고 하면 안 된다. 파리이니까. 저자에게 있어 이 워크숍의 가장 큰 의미는 현재 진행 중인 작품에 대한 온전한 반응을 정확히 보는 것이다. '아, 사람들이 이 부분을 이렇게 오해하는구나'라고 느끼고 필요하다면 메모해 두면 된다.
4. 요약
리뷰의 출발은 가장 기본적인 피드백에서 시작한다. 이 작품을 과연 뭐라고 느끼는가? 어쩌면 이 작품의 장르가 무엇인가에 대한 대략적인 이야기부터 구체적 독자층이 누구인가에 대한 상세한 이야기까지도 가능하다.
그 다음에는 본격적으로 요약이 시작된다. 되도록 중립적이고 관찰자적인 입장에서 논평한다. 지금 단계에서는 가치 판단을 하면 안 된다. 좋다 나쁘다란 말이 나오면 안 된다. 간접적으로라도. 대신 그 작품 자체를 정확하게 요약하도록 노력한다. 몇 사람이 돌아가면서 자기가 나름대로 받아들인 이 작품의 요약을 이야기한다.
5. 긍정적 피드백
비판은 우선 긍정적 피드백으로 시작한다. 리뷰하는 사람 입장에서 어떤 부분이 특별히 좋았는지, 다른 부분은 바뀌더라도 이 부분만큼은 그대로 남았으면 하는 것은 무엇인지 등을 이야기한다. 중재자는 이 단계에서 사람들이 "긍정적 피드백"이란 이름 하에 부정적 피드백을 주는 일이 일어나지 않도록 각별한 주의를 기울여야 한다.
피드백은 글의 배치, 짜임새에 대한 것, 제목의 적절성, 특정한 문장이나 낱말 사용 등 어느 것이든 가능하다. 되도록 맘에 드는 부분을 콕 찝어서 이야기해주는 것이 좋다. 직접 그 부분을 읽어줘도 좋다.
6. 개선 제안
여기에서 어떻게 보면 부정적인 피드백이 나올 수도 있다. 하지만 거기에서 끝나면 안 된다. 개선 제안이 되어야 한다. 이것이 좋지 않다로 끝나면 그건 개선 제안이 아니다. 이렇게 하면 더 좋겠다로 해야 한다. 그리고 그 제안은 구체적이어야 한다. "이것이 맘에 안 드니 어떻게든 고쳐야 한다"는 좋은 예가 아니다. 그리고 다음과 같이 작품을 주체로 두고 이야기하는 것이 좋다. "이 부분을 이렇게 고치면 이런 면에서 작품이 더 좋아질 것 같다."
그리고 작품 자체를 부정하면 안 된다. 작품을 일종의 생명체로 보고, 이 생명체가 건강하게 자라나면 어떤 모양일까, 자신의 잠재성을 온전히 표출하려면, 그 잠재성을 끌어올리려면 어떤 모양새가 되어야 할까를 상상해야 한다. 그래서 출발점이 되는 씨앗 자체를 인정하는 한에서 개선 제안을 하도록 한다.
이 때에도 물론 저자는 가만히 있어야 한다. 갑자기 소리를 내거나 벌떡 일어서거나 해서는 안 된다. 중재자는 필요하다면 저자를 대신히 그를 옹호할 수 있다.
7. 저자의 질문
이제 저자가 입을 연다. 무슨 말을 할 것인가? 질문을 한다. 무슨 질문? 자신이 잘 이해 못한 부분을 명확히 이해하기 위한 질문. 예를 들어 6번 개선 제안 단계에서 누가 이렇게 바꾸면 좋겠다고 말을 했다. 어떻게 바꾸면 좋겠다는 것인지가 애매하다. 그러면 질문한다. 하지만 질문의 형식을 빌어 해명하면 안된다. 예를 들어, "아까 모 리뷰어께서 어쩌구를 저쩌구로 바꾸라고 하셨는데, 그렇게 바꾸면 글의 구조가 완전히 깨져버리거든요?" 이건 아니다.
8. 저자에게 감사하기
마지막으로 리뷰어들은 저자에게 이런 작품을 미리 접할 수 있는 기회를 준 점에 대해 감사를 하고, 박수를 쳐주며 작품이 더 나아지도록 노력해 달라고 하는 마지막 격려를 해준다.
그 이후
이렇게 전체 과정이 끝나면 저자는 필요를 느낀다면 다른 자리에서(컨퍼런스는 며칠에 걸쳐 진행되므로) 개인적으로 해명할 수도 있다. 하지만 명심하자. 저자에게 가장 가치있는 정보는 사람들이 이런 부분에서 이렇게 오해한다는 정직한 반응이니까.
저자가 파리가 된 동안 수집한 정보는 자신이 취사선택한다. 이 부분은 온전히 저자의 자유에 따른다. 그렇게 자기 작품에 도입할지 말지 결정하여, 어떤 경우 컨퍼런스가 끝나기 전에 다시 한 번 (개정된 작품으로) 워크숍을 하기도 한다. 저자 자신이 상상했던 것 이상으로 좋은 작품이 나온다.
이런 워크숍을 거쳐 재탄생한 작품들을 플랍에서는 종종 책 형태로 출간해 왔다. 현재까지 열 권이 넘는 책이 이 컨퍼런스를 통해 출간되었다.
전혀 새로운 느낌
나는 이 저자 워크숍을 직접 기획, 진행해 본 적이 몇 번 있다. 2007년 7월에 p-camp에서 IT 종사자들 대상으로 진행했다. 당시 워크숍을 경험한 사람들은 매우 신선하고 유쾌한 경험이었다고 입을 모았으며, 특히 저자들의 경우 자신이 작품이 정말 좋아지는 경험을 했다며 가장 큰 만족도를 보였다.
생각해 보라. 우리 주변에서 자기 작품을 공유하고 나서 그 작품이 실제로 더 좋아지고, 저자 자신의 기분이 더 유쾌해지는 경우가 얼마나 희소한지.
올해에는 유치원 선생님들을 대상으로 워크숍을 진행했고 매우 성공적이었다. 학부모 대상으로 발표회를 하기 위해 저작물을 만들어야 했는데, 교사 20여 명이 저자 워크숍을 여러 번 하면서 자신들의 저작물을 놀라울 만큼 개선할 수 있었다. 마음에 상처 받는 일 없이. 윗 사람 한 두 명의 지시에 따라 개선한 것도 아니고, 교사들의 동료 리뷰(peer review)를 통해서. 그 때 이후로 저자 워크숍은 유치원에서 일종의 문화와 습관이 된 것 같다.
저자 워크숍을 나름대로 짧게 설명해 보았다. 이것만으로 충분하지는 않을 것이다. 분명 진행하다 보면 문제점을 만나기도 할 것이다. 그럴 때 권하는 것은 워크숍 경험이 있는 사람에게 진행을 요청하고, 필요하다면 리처드 가브리엘의 책(Writers' Workshops & the Work of Making Things)을 참고하라는 점이다.
그리고 저자 워크숍의 최고 볼륨을 경험하고 싶은 독자들에게는 패턴 언어 진영의 활동을 연구해 볼 것을 권한다. 이 저자 워크숍을 패턴과 합치면 곱하기의 힘이 나온다. 패턴에 대해서는 다음번에 기회가 되면 또 다른 글로 설명하겠다.
내가 이 글을 통해 독자들에게 하고 싶은 이야기는 이것이다. '다른 길'들이 존재한다는 것. 그리고 최종 결과물뿐 아니라 우리의 사회적 과정, 사람들간의 동역학에도 관심을 가져 달라는 것. 그리고 저자 워크숍을 퍼뜨려 달라는 것.
행운을 빈다.
김창준 현재 애자일컨설팅 대표로 있으며 주로 소프트웨어 개발 조직의 생산성과 인간성 모두를 증진하기 위해 컨설팅, 코칭, 교육 등을 하고 있으며 특히 지난해부터 "애자일 코치"를 키우는 AC2라는 코칭 과정을 진행 중이다. 애자일이야기라는 블로그를 운영하고 있다.
프린트해오실 분도 게시판에 일단 달아주세요~