효과적이고 건설적인 저작물 리뷰와 저자 공동 수련 (Writer's workshop)

리뷰

회사의 개발 프로세스 중 "리뷰" 라는 것이 있다. 개발자는 개발 단계별로 설계 문서, 요구사항 분석 문서 등을 작성한다. 그리고, 관계자 혹은 팀원들을 모아서 자신의 설계에 헛점은 없는지, 더 나은 방법은 없었는지 등을 "검증받는"데, 이것을 "리뷰" 라고 부른다.

실제 상황

최근, 모 프로젝트 ("가"라고 하자) 의 상세 설계 문서 리뷰를 했다.

리뷰 과정 중 몇가지 지적사항이 나왔으며, 크게 두 가지 면에서 리뷰자 A 와 개발자 B 간에 의견차가 존재했다. 의견차를 조율하는 과정에서 목소리가 커지기도 했지만 결국은 보다 나은 방향으로 결론은 내려졌다. 결과만 놓고 보면 소기의 목적을 달성한 리뷰라고 할 수 있다.

내가 여기서 짚고 넘어가고자 하는 것은 리뷰 결과 더 나은 설계 결정이 내려졌다는 긍정적인 결과가 아니라 토의의 과정이다. 서로 다른 의견을 개진하고 서로의 기분이 상하지 않도록 토론하는 방법이다.

B 는 A 의 의견 개진 과정에서 '잘못을 문책당한다' 혹은, '공격받고 있다'는 느낌을 받았을 것이다. 또한 A 는 자신의 의견에 대한 B 의 반응과 변론이 '답답' 하거나 '틀리'다는 느낌을 받았을 것이다.

사실 B 가 이 회의를 위해 했던 준비 - 상세 설계 문서의 작성 - 는 내가 봐도 좀 미흡했다. 그 부분에 대한 지적은 B 도 부끄럽지만 당연한 것으로 받아들였을 것이다. B 를 위해 변명을 하자면, 아마도 6주가 넘는 코딩 없는 문서작업과 구체적으로 만질 수 있는 것이 없는 추상적인 작업에 지친 상태에서 설계 문서를 작성해서인지도 모르겠다.

몰론 "가" 프로젝트의 상세 설계 리뷰였던 해당 리뷰는 나름대로 건설적인 결과를 도출해 내어, 원 설계자가 구상했던 것 보다 더 나은 설계가 결과적으로 만들어지게 되어서 소기의 목적을 충분히 달성한 리뷰였다.

리뷰의 진행 패턴

내가 지금 일하고 있는 팀의 최근 2년간의 리뷰들 - 80% 이상이 B 의 저작물에 대한 리뷰 - 의 경향과 online 리뷰의 패턴을 한번 생각해 보았다.

발표자는 자기가 생산한 저작물을 발표하고, 리뷰어들은 그 발표를 들으면서 자기의 생각과 다른 부분을 이야기한다.  여기서, 대부분의 (나를 포함한) 리뷰어들은 "이 부분은 틀렸습니다" 라는 이야기를 한다. (물론, 틀린 부분을 틀리다고 이야기하는 것이라면 어쩔 수 없다. 그 부분은 정답이 있는 부분이기 때문이다) 혹은 "이 부분은 왜 그렇게 하셨나요?" 혹은 "이렇게 하는 것이 더 좋지 않을까요?" 라는 이야기를 한다.

그러면, 개발자는 그에 대해 "방어"를 시작한다. 그리고, 충분한 설명이 이루어지지 않았다고 생각한 질문자는 자신의 의견을 뒷받침하는 이야기를 한다. 개발자는 질문자의 의견에 또 반박을 하고, 질문자는 또 그 개발자의 의견에 반박을 한다.

여기서, 질문자는 개발자가 보지 못하고 놓친 부분이 분명히 있다고 믿고 있음에 틀림없다. 개발자는 방금 개진된 질문자의 방법과 자신의 방법을 머릿속으로 열심히 비교하기 시작하지만 깊이 생각할 여유가 없어 허둥대기 시작한다. 마치, 아래 블로그에서 묘사된 프로젝트 결과 발표의 한 장면과도 같다 :

모 개발자가 몇 달에 걸쳐 개발한 것을 발표하고 의견 수렴을 하는 자리. 같은 회사 다른 부서에서 여러 사람이 왔다. 발표는 순탄했다. 마지막 질문 답변 시간. "저건 왜 저렇게 하셨나요? 그렇게 해서 성능이 제대로 나오겠어요?" 개발자가 보기엔 질문하는 사람이 멍청해 보인다. 내가 얼마나 고생해 만들었는데 설마 그런 걸 고려 안 했으리라고. "아뇨, 당연히 나옵니다." 또 다른 질문. "아까 그 부분은 이렇게 개선하면 어떨까요?" 이젠 얼굴이 상기되기 시작한다. "아뇨, 지금 방식이 더 좋습니다. 왜냐하면..." 열기가 뜨거워지면서 좀 더 본격적인 비판도 나온다. "처음부터 개발 방향이 잘못된 건 아닌가요?" 눈 앞이 캄캄해지고 가슴 속에서 뜨거운 뭔가가 올라온다. 한 30분쯤 흘렀을까? 그 개발자는 나름 모든 질문에 선방했다고 생각하던 차, 누군가 손을 들고 말한다. "우리는 도대체 왜 불렀습니까?"

누가 문제였을까? 우선 개발자는 이제껏 잘못된 교육을 받았다. 이런 자리에는 피드백을 받는 것이 목적이 아니고 내 작품이, 그리고 나 자신이 성공적이라는 것을 증명해 내야 한다고 무의식 중에 믿어왔다. 다른 경험을 할 기회가 별로 없었다. 또 개인적으로는 자신감이 부족하고, 자존감도 낮았을 것이다. 통상 이런 사람일수록 다른 사람의 비판에 굉장히 감정적으로 대응한다. 마음에 여유가 없기 때문이다. 오히려 고수일수록 사소한 시비에 말리지 않는다. 또한 참관자들 입장에서도 고칠 점이 있다. 좀 더 긍정적이고 친근한 방식으로 피드백을 주지 못했다. 이런 자리는 발표자와 제품의 약점을 찾아내는 것이, 그리고 그렇게 해서 내가 똑똑하다는 사실을 증명하는 것이 목적인 게임이라고 은연 중에 생각한다.

-- 출처 : IBM Developer Works : 저자 워크숍

이와 같은 장면이 계속적으로 거의 모든 리뷰시마다 반복이 되고, 리뷰는 마치 다수의 리뷰어가 한사람의 발표자를 꾸짖는듯한 분위기로 흐른다. (나 역시 다수의 리뷰어의 입장이 되어서 한명의 발표자를 "공격했던" 적도 있다. 반성해야지. 또한 위 발췌 내용에서의 개발자가 마치 나를 보는 것 같아서 식은땀이 난다.)

그럴 수 밖에 없는가?

그런데 리뷰의 분위기가 이처럼 되는 것은 어찌보면 필연적인 것인지도 모른다. 지금 현재 하는 것과 같은 방식의 리뷰를 계속한다면 말이다.

왜냐하면 첫째, 리뷰라는 것의 개념부터가 이와 같은 문제를 안고 있다. 나에게만 그렇게 인식되고 있는지는 모르지만, 적어도 나에게 리뷰는 "개발자가 실수로 잘못하거나 혹은 놓친 부분들을 바로잡는 절차", "개발한 코드나 문서가 오류가 있는지 타인에게 검증받는 절차" 로 인식되어 있기 때문이다. (물론, 지식 전파 등의 목적은 논외이다)

리뷰를 그와 같은 개념으로 생각한다면, 리뷰에서 자신이 실수한 부분을 지적받고, 놓친 부분을 보충받는 것이 당연한 것이다.

또한, 현재의 리뷰 문화(문화라고 해 두자)에서는 리뷰어가 개진한 의견을 발표자가 곰곰이 생각할 시간적 여유가 주어지지 않는다. 발표자는 질문자가 제시한 방법을 자신의 방법과 제대로 비교할 시간을 갖기도 전에 그를 전적으로 수용하거나 혹은 반박해서 자신의 방법이 옳다는 것을 그 자리에서 보여야만 한다. 그러나 안타깝게도 그만한 지적 순발력을 가진 사람은 축복받은 몇몇에 지나지 않을 것 같다.

그리고, 현재의 리뷰 문화에서는 발표자에게 직접 질문을 한다. 그와 같은 상황에서는 질문자들이 발표자에게 "답을 요구"하는 상황이 되어 자칫 잘못하면 발표자로 하여금 "공격받고 있다" 는 느낌을 갖게 하거나, 혹은 "방어해야 한다" 는 생각을 하게 만들기 쉬운 구도이다.

즉, 물론, 건설적이고 개발자나 리뷰어 모두 해피한 토론의 장이 되는 리뷰도 종종 있는 것은 사실이지만, 현재의 리뷰 시스템으로는 참가자들이 항상 깨어있지 않는 한 본질적으로 /그럴 수 밖에 없/는 위험을 안고 있는 것이다.

그럼 어떻게 하라고?!

아마, 내가 다니는 회사처럼 peer review 가 정착되어 있는 회사에서 개발을 하는 사람이라면 거의 누구나가 이와 같은 문제를 겪었을 것이고, 잘은 몰라도 사내의 다른 팀들의 리뷰에서도 이같은 상황이 연출되고 있음에 틀림없다고 짐작한다.

우선, 리뷰의 정의부터 "더 나은 저작물을 만들기 위한 모임" 으로 다시 해야겠다.

그리고, 이와 같은 리뷰의 대안으로써, 위 발췌부분에서 출처를 언급한 "Writer's workshop" 이라는 "저자 공동 수련" 이라는 방법론을 팀내에서 도입해 봤으면 한다. 구체적인 수행 방법은 아래 링크를 참조하자 :

http://www.ibm.com/developerworks/kr/library/dwclm/20081230/

저자 공동 수련 방법론이 정답일까?

이 방법론의 팀내 도입에 따른 문제점은 없을까?

우선 리뷰어로 지정된 사람들 모두가 리뷰하기 위한 자료를 숙지하고 있어야 할 것이며, 이에 따르는 팀원들의 시간이라는 상당히 큰 비용이 들 것이다.

또한, 현재 팀원들의 구성을 볼 때, 자신감을 가지고 자신의 의견을 이야기할만한 사람이 적다는 것이 문제점이다. 자칫 이같은 공동 수련이 공동 수련이 아니라 한 사람 혹은 두 사람만의 수련이 될 가능성이 크다는 점이다.

또한 이 "공동 수련" 방법에서는 함께 모인 자리에서는, 즉, 공동 수련을 하는 자리에서는 저자와의 토론이 불가능하다는 점이다. 따라서 따로 저자가 자신의 생각을 설명하는 시간이 필요하다.

그리고, 저작물의 질 또한, 리뷰어로 지정된 모든 사람이 읽고 이해할 수 있을 정도로 친절한 저작물이 되어야만 한다는 것이다. 따라서, 저작물을 만드는 데 보다 더 많은 노력이 들 것이다. 현재의 리뷰에서는 저자의 설명이 없으면 이해가 어려울 수 있는 부분이 많이 남겨진 문서나 코드가 리뷰의 대상이 되고 있어 곧바로 공동 수련에 사용할 만한 수준의 문서나 코드가 아닌 경우가 많다.

마치면서

글쓰는 연습도 할 겸, 평소 생각해 오던 문제도 정리해 볼 겸, 반추의 시간을 가지면서 생각도 정리해 볼 겸, 겸사 겸사로 이 글을 썼다. 제대로 된 결론도 내지 않고 문제 제기와 어렴풋한 해결책 정도만을 날림으로 적은 글이지만, 나름대로 오랜 시간이 걸려서 적은 글이다. 쓸데없이 양만 많은 글이 아닌가 싶기도 하다 -_-;;;

실례에 나왔던 B 는 부끄럽지만 나 자신이다. 또한 팀내에서 진행된 많은 리뷰들 중 가장 시끄러웠고 의견이 분분했던 리뷰들도 돌이켜보면 다 내가 했던 리뷰들이다. 즉, 팀내 다른 구성원의 리뷰는 큰 소음이나 상이한 의견 없이 잘 넘어갔는데 유독 내가 하는 리뷰들이 약간 소란스러운 경우가 많았다는 이야기이다.

그렇다면, "문제는 나에게 있을까?" 라는 질문을 해 보지 않을래야 않을 수 없다.

과연 문제는 나에게 있나? 내가 저작물을 다른 사람이 이해하기 어려운 형태로 만드는 것일까? 내가 발표를 잘 하지 못하는 것일까? 내가 생각하고 있는 것을 잘 표현하지 못하는 것일까? 그럴지도 모르겠다.

한번쯤 설계 등의 문서를 만들때 생각의 방향을 달리 하여 기술하는 방법을 찾아 보아야 하겠다.

실례로 든 리뷰가 끝나고 느낀 것이지만, 나이가 들면서 내가 하는 사고가 일정 패턴으로 경직되기 시작하고, 여러가지 근거를 제대로 댈 수 없는 고정관념들에 점차 많이 사로잡혀 간다는 것을 느낀다. 순간적으로 판단하고 대처하는 지적 순발력이 저하되어 간다. 머리가 굳어가고 있는 것이다. 모든 일을 함에 있어서 항상 "이래야만 할까?" 를 한번 더 생각해 보도록 해야 겠다.

Think outside the box 라는 말이 있다. 말은 쉽지만 실천하기는 정말 어려운 것 같다. To be in another's shoes 라는 말도 있다. 그것 또한 실천하기는 정말 어렵다. 내가 고정된 내 사고 방식으로 만든 문서를 다른 사람이 읽을 때에는 어떻게 읽혀질 것인가를 가늠하기란 참으로 어렵다. 어렵지만 계속 연습해야지, 그렇지 않으면 몇년 후, 젊고 철없던 시절에는 무려 경멸씩이나 했던 고지식한 어른이 되어 있는 내 모습을 발견하게 될까 두렵다.

참고 링크에서 소개하는 책 "Writers' Workshops & the Work of Making Things" 는 현재 절판된 책으로써, 국내에서는 구할 수 없다. 링크를 걸어 둔 아마존에 가도 몇몇 seller 만 판매할 뿐이다. 그러나 저자의 홈페이지(http://www.dreamsongs.com/) 를 방문하면 저자의 final typeset version 을 pdf 로 구할 수 있다.