찰진 회의를 위한 알티베이스의 노력

오늘 프로젝트 요구사항 수집 회의가 제 생각에 제법 잘 진행되서 이곳에 적어보려합니다. 알티베이스의 회의 문화 뿐 아니라 개발 문화에 대해서 어느정도 설명되는 일화라고 생각이 됩니다. 세부사항은 빼고 간단히 말씀드리겠습니다.

어떤 오래된 이슈가 있습니다. 제품 전체에 영향을 미치면서도 다양한 해결방법들이 개발된 상태입니다. ‘다양한’이라는 표현에서 알 수 있듯이 뾰족한 해결책은 없는 문제입니다. 오랫동안 이 이슈가 지속되어왔고 이번 기회에 통합적으로 해결해보고자 요구사항을 수집하기 시작했습니다. 일차적으로 글로 요구사항을 수집했습니다. 처음에는 늘 그렇듯이 애매모호한 요구사항들이 개발자들의 독특한(?) 문체로 기록되었습니다. 우리는 ‘빠른’, ‘효율적인’, ‘멀티코어에서’, ‘다양한’ 이런 단어들이 문장에 들어가면 전가의 보도같은 만능 솔루션이 된다는걸 잘 알고 있습니다. (개발자의 남다른 글쓰기 문화에 대해서도 한번 글을 써봤으면 좋겠다는 생각이 드네요. 아마 아주 다양한 사례들을 쓸 수 있을것 같습니다.)

어쨌든 저는 요구사항들을 보고 다음과 같은 메일을 보냈습니다.

“프로젝트 요구사항에 대한 리뷰 회의를 하겠습니다. 현재 개별적으로 수집된 요구사항들이 명확하지 않습니다.”

그리고 회의 시작전 저는 다음 질문에 대한 해답을 얻겠다는 다짐을 했습니다.

“문제가 무엇이고 프로젝트의 목표는 무엇인가? 우리는 문제를 옳바르게 이해하고 있는가? 우리가 문제라고 생각한 것이 진정한 문제인가? 우리가 생각한 문제의 원인이 진짜 원인이 맞는가? 우리가 제시한 요구사항이 문제 해결에 정말 필요한 요구사항인가? 요구사항중에 우선적으로 해결되야할 것은 무엇이고, 부가적인 요구사항은 무엇인가?”

요구사항을 제시한 분들이 모두 모였고, 각 사람이 돌아가며 자신이 제시한 요구사항을 다시 설명했습니다. 역시 각자의 기준과 관점에 따라 다르게 해석할 수 있는 사항들이 발견되었습니다. 그래서 우선 요구사항에 대해 각자의 기준을 맞춰야했습니다. 예를 들어 ‘빨라야한다’라는 요구사항은 결국 아무것도 요구하지 못합니다. 현재의 해결책이 그분에겐 느리지만 다른 누군가에게는 충분히 빠른 것일 수 있기 때문입니다. 또 ‘멀티코어에서 빨라야한다’도 아무런 의미가 없는 말입니다. 얼마나 어떻게 빨라야하는지 기준이 없기 때문입니다. ‘CPU갯수에 따라 선형적인 성능 증가가 있어야 한다’나 ‘초당 10만번 이상의 처리’, ‘10us 이하의 응답속도’와 같이 정확한 기준을 제시해야합니다. 그래야 개발된 솔루션이 요구사항에 맞는지 확인할 수 있습니다.

이렇게 모든 요구사항에 대해 모든 사람이 동일한 기준을 가지고 이해할 수 있도록 토론을 했습니다. 또한 진정한 문제가 무엇인지, 지금까지의 솔루션은 어떤 문제를 해결했고, 어떤 원인으로 현재의 문제가 발생했는지에 대해 시니어 개발자의 설명을 들었습니다. 그렇게 문제를 이해하고 요구사항에 대해 동일한 기준을 가지고나니 정작 중요한 요구사항을 간과하고 있었고, 제시된 요구사항들에 대해 수정이 필요하다는 것을 알았습니다. 만약 이런 회의가 없었다면 개발한 솔루션이 정말 필요한 해결책이 아닐 수도 있었을 것입니다.

회의가 끝나고 저는 회의 결과를 문서로 만들면서 사실상 솔루션의 디자인이 끝났음을 깨달았습니다. 모두가 문제를 정확하게 파악하고나니 (역시 개발자답게) 자연스럽게 해결책에 대한 이야기가 오고가서 저 혼자 고민할 필요없이 자연스럽게 여러 사람의 지혜가 모아져 개발 방향을 잡을 수 있었기 때문입니다. 남은 일은 실질적으로 문제를 해결할 알고리즘을 선정하고 요구사항에 맞게 인터페이스를 도출하는 일뿐이었습니다. 결국 생각했던 것보다 개발 기간을 단축할 수 있었고, 정말 다른 개발자들에게 도움이 되는 솔루션이 될것이라는 희망이 생겼습니다. 저는 제가 혼자서 기획한 것보다 더 좋은 솔루션을 만들 수 있어서 좋고, 회사는 정말 필요한 솔루션을 개발할 수 있어서 좋은 일입니다. 무엇보다도 저는 보람을 느끼고 행복해져서 좋았습니다.

지금 일하러 갑니다

옛날옛날 제가 대한민국 모처의 던전에서 전투(일)할때의 경험입니다. 회의 시간에 들어올땐 마음대로 들어왔겠지만 나갈땐 안되지요. 관계자도 아닌데 전체 공지메일을 받아서 눈치보며 참석한 사람들이 대부분이었습니다. 회의시간동안 여긴 어딘지 난 누군지 모른체 책상밑에 전화기만 멀뚱멀뚱보고 나오는 일이 많았습니다. 정확한 목표가 없이 시작된 회의는 당연히 말꼬리잡기와 감정싸움으로 채워지고, 다음 회의 시간을 잡는 것으로 끝났었습니다. 그리고 막내가 배포한 회의록이 회의 결과의 전부였습니다. 이걸 회의를 위한 회의를 한다고 말하기도 하지요.

그 던전에서 저는 앞으로 내가 회의를 이끌게되면 어떻게 회의를 해야할지 고민을 했었습니다. 그리고 오늘 이 원칙에 따라 회의를 했습니다. 대단한건 아니지만 소개해보겠습니다.

• 회의의 목표에 대해 단정적인 명제로 설명한다.

• 이 설명에 따라 공지를 본 사람은 자신이 관계자임을 스스로 판단해서 자발적으로 참석하도록 한다.

• 회의가 끝날땐 반드시 대답이 되어야할 질문을 미리 준비한다.

• 모든 참석자가 돌아가면서 준비된 질문에 대답한다.

우리 회사는 직급이 없고 서로를 ‘누구누구님’으로 호칭하며 나이도 묻지 않는 문화를 가지고있습니다. 이런 평등하고 자유로운 알티베이스의 개발 문화가 이런 대수롭지 않은 원칙하에서도 결론을 내는 회의를 할 수 있게 해주었습니다. 사실은 어떤 원칙을 가지고 있느냐가 중요한게 아닐것입니다. 어떤 분위기에서 회의를 하느냐가 더 중요할 것입니다. 개발자가 행복하려면 우선 사람으로써 행복한 일터에서 개발해야합니다. 그러면 개발자로써도 행복해질 수 있습니다. 사람이 사람답게 일하는 회사에서 개발자도 행복을 느끼며 개발할 수 있습니다. 저는 이 글을 보시는 모든 분께 던전을 클리어하시고 사람이 사는 곳으로 나오시길 권합니다.

이로써 행복에 대한 별것없는 글을 마치고 C프로그래밍 노하우에 대한 글을 연재할 계획입니다. 많이 읽어주시길 부탁드립니다.