사가의 시대가 다시 도래하기를 기다리며

1996년 봄, 나는 내가 공동 창업했던 회사로 돌아왔다. 켄 슈와버는 인디비쥬얼 사에서 체험했던 스크럼에 대해서 상당히 많은 내용을 기록해 놓았다. 인디비쥬얼 사의 스크럼에서 가장 인상 깊었던 점은 개발팀이 한 분기에 두 개의 인터넷 제품을 인도했다는 사실도, 그 제품들 중 하나가 여러 차례 릴리스 되었다는 사실도 아니다. 그것은 스크럼을 시작하면서부터 한 주에 여덟 시간이나 하던 고위 임원들의 회의를 없애버렸다는 사실이다.

많은 기록의 목적 중에서 역사를 남기는 것만큼 재밌는 게 또 있을까 싶습니다. 옛날처럼 목숨을 걸고 해야만 하지 않는다면요. 요즘 스크럼 책을 읽고 있는데, 스크럼이 지금의 모습으로 이룩된 근저에는 켄 슈와버씨의 저 기록이 큰 실마리가 되었지 않나 하고 조금 감동을 받았습니다. 기록의 중요성은 또 말해 무엇하겠습니까만, 소프트웨어 개발에 있어서든 조직에 있어서든 기록만큼 중요한 것은 없습니다. 그것이 조직의 성장에 직접적으로 기여하기 때문입니다. 정확히 말하면 결과물을 인도하는 것 다음으로 중요한 것이겠죠.

십 년을 넘게 살아 남은 역전의 용사와 같은 조직들 내부를 들여다 보면 실상은 그리 자라지 않은 듯한 인상을 받는 일이 많습니다. 왜 그럴까요? 일전에 김창준님이 일 년짜리 경험을 열 번 반복하는 개발자에 대해 쓰신 글을 인상적으로 읽은 기억이 있는데, 조직의 경우에도 마찬가지로 대입할 수 있는 통찰입니다. 차라리 십 년짜리 경험을 쌓은 개인을 찾는 편이 더 쉬울 것 같습니다. 저도 개인의 경험이 조직의 지식으로 편입되지 않는 현실이 안타까워 개인적으로 메모를 남겨 두었던 것이 기억납니다. 그런 차원에서 친구가 작은 회사에서 기획 팀장을 맡게 되었다고 했을 때 그에게 모든 것을 기록해야 한다고 조언한 적이 있어요. 모든 팀원이 프로젝트에 대한 기록을 한 자라도 더 남길 것을 장려하려면 블랙 박스를 하나 만드는 것이 어떠냐고 말입니다. 프로젝트가 끝나야만 열어볼 수 있는 블랙 박스에 익명으로 지금의 심정을 적을 수 있도록 해서 자주 사용하게 권유하라고요. 만약 그 일이 제대로 진행되었다면, 마지막에 그 상자를 열어 보는 기분이 어떨까, 매우 각별하지 않을까, 지금도 종종 상상해보곤 합니다.

적으나마 제 경험을 나누어 볼게요. 지난 회사에서 마지막으로 진행했던 프로젝트에서 저는 여러 가지 문제를 겪으며 고생을 하다가 중도에 나오게 되었습니다. 그러면서 다짐을 했습니다. 이번 프로젝트엔 성공하든 실패하든 기록을 차곡 차곡 쌓아가서 포스트 모텀을 써보자고요. 그게 벌써 삼 년이 지났네요. 이제 프로젝트가 마무리할 때가 되었거나, 터닝 포인트가 될쯤에 서서, 지나온 길을 되돌아 보니 남아 있는 기록이 거의 하나도 없더군요. 사람이 기억하는 내용은 반드시 사멸하는 법입니다. 책임 있는 자리에 있는 사람조차도 중요한 것은 거의 아무 것도 기억해내지 못하고요. 인간이니까, 어쩔 수 없지요. 위키위키나 svn 로그를 통해 사라진 역사를 역산해 보려고 했지만, 모든 게 남아있는 것은 아니라 수월치 않았습니다. 정확히 말하면, 결정은 남아 있지만 과정은 없더라는 거죠.

환경을 바꾸려고 들기 전에 해야 할 일은 나부터 바꾸는 일일 겁니다. 비교적 의욕을 가지고 시작했고, 통계를 내보고 싶은 메트릭도 많이 있었고, 흥미도 있었지만, 결국 좌절하고 말았습니다. 흔히 개발자가 본래 다루어야 할 업무와 다르다고 여겨지는 일을 하는 것은 여유로 보여지고, 그 역량을 본래 투자되어야 할 곳으로 돌리도록 요구됩니다. 설사 이 또한 개발자의 업무라고 인정되는 환경에서 일한다 해도 제가 생각한 만큼 충분한 시간을 투자하는 것은 어려운 일이라는 결론을 얻었습니다. 팀에는 다양한 관점으로 보고 다양한 형태의 기록을 남겨줄 전문적인 테크니컬 라이터가 필요합니다. 때문에 제가 종종 꿈꾸는 '내 팀'에는 테크니컬 라이터도 한 자리를 차지하고 있습니다. 그러나 제가 항상 고민하는 건 그의 커리어 패스를 어떻게 보장해야 할까? 하는 문제입니다. 우리 팀에서 테크니컬 라이터에게 업무를 주고, 역량을 키워나간다 쳐요. 그러나 현실적으로 업계에는 그가 따라 갈 커리어 패스가 없습니다. 여러가지 이유로 그가 팀을 나가게 된다면 최악의 경우 경력을 인정받지 못하거나, 적어도 가시밭 길이 예정되어 있을 겁니다. 차마 그런 미래를 그에게 줄 수 없어, PM 밑에 두었다가 기획팀에 두었다가 합니다. 하지만 주위를 둘러보면 그렇게 안배해 놓은 인력도 급해지면 적당히 다른 곳으로 옮겨졌다가 영영 돌아오지 못하는 전직의 길을 걷더라고요.

최근에 미투데이에서 yagur님께 문서화를 전담하는 테크니컬 라이터가 필요하다는 고견을 들었는데 이 모든 이야기들이 서로 통하는 바가 있습니다. 많은 성공작과 그보다 더 많은 실패작을 만들어 내는 아주 많은 회사들이 망한 프로젝트로부터 아무런 배움도 얻지 못하는 이유는 결과는 남되 과정이 남지 않기 때문일 겁니다. 그래서 프로젝트에 사서로 참여하고, 그 결과를 드리밍 인 코드라는 책으로 쓴 스콧 로젠버그가 그토록 부러울 수가 없습니다. 사든 어쩌든, 이 책을 읽어야겠어요.

이 글은 스프링노트에서 작성되었습니다.

신고
Trackback 2 Comment 0

prev 1 2 3 4 5 ··· 28 next


티스토리 툴바