brunch

You can make anything
by writing

C.S.Lewis

by Roaster Kay Feb 18. 2016

이슈트래커는 두 번 찌른다

몇 년 전부터 애자일 방법론이 대두되면서, 예전에는 단지 선언 내지 담론에 멈추어 있었던 애자일은 어느 새 도구나 액션 아이템이 되어 우리 곁으로 다가왔습니다. 점점 많은 회사들이 애자일 기법을 도입하고 있으며, 이것이 곧 앞서가는 개발 문화를 지닌 개발사임을 은연중 내포하는 홍보 수단이 되기도 합니다. 하지만 제가 개인적으로 겪어 본 애자일 방법론은 생각처럼 잘 작동하지 않았습니다. 애자일 전도사들의 주장에 따르면 애자일을 잘못 이해하고 잘못 써서 그렇다고 하고, 제 개인적인 의견으로는 애자일 방법론 자체가 굉장히 호도되고 오용되기 쉬운, 다시 말해 인간이 모여 생활하는 공동체가 근원적으로 다루기 힘든 행동 강령을 기반으로 하고 있다고 믿습니다. 마르크스가 제안한 공산주의 경제사상을 보세요. 사상이 추구하는 바는 놀랍도록 명백하고 이상적이지만, 실제 구현체가 이 세상에 출현한 적은 단 한 번도 없습니다! 앞으로도 꾸준히 강조할 사실이지만, 개개인이 처한 상황이나 심리 상태, 이로 인한 휴리스틱 등 미시적 요인을 배제한 조직문화 이론은 반드시 실패합니다. 이런 엉성한 주장이 반복해서 나온다는 것 자체가, 현대 산업의 속성을 아직도 애덤 스미스 시대의 도그마로 재단하는 습관을 못 버렸다는 증거이기도 합니다.


무튼 애자일은 그 섹시한 자태만큼이나 잘못 이해되기 쉬우며, 오해의 대가는 큽니다. 즉, 잘 해 보겠다고 도입한 방법론이 구성원을 더 빨리 지치게 하고 프로젝트를 망가뜨리는 수단이 되기도 한다는 뜻입니다.  그중에서 애자일 좀 도입해 보겠다고 하면 높은 확률로 가장 먼저 들어오는 녀석인 이슈트래커 이야기를 해 보려 합니다.


당최 이슈트래커가 왜 애자일이랑 엮여 마치 여고생들이 짝으로 화장실을 드나들듯 따라다니는지 애자일 예찬론자들에게나 저에게나 황당한 일이긴 합니다만, 아마도 애자일 방법론 중 하나인 스크럼(scrum)을 시각화하는 데 가장 편리한 도구이기 때문이 아닐까 추측해 봅니다. 실제로 가장 널리 쓰이는 몇몇 이슈트래커는 그네들의 UI에 스크럼 용어를 그대로 노출시키기도 합니다. 어찌 됐건 지네들이 애자일 방법론을 적극적으로 도입하고 있다는  회사치고 이슈트래커를 안 쓰는 회사를 찾아보기가 힘들 지경이므로, 일단은 이 불편한 동거를 눈감아주기로 합시다.


그런데 각 구성원이 이슈트래커를 받아들이는 입장이나 온도차가 다르다는 사소한 사실이 이 작고 귀여운 툴에 허리케인을 몰고 옵니다. 우선 현존하는 이슈의 개수는 물론이고, 각종 현란한 차트로 진행률을 보여주(ㄴ다고 믿게 만드)는 대시보드가 관리자의 눈에 들어오는 순간, 이 관리자는 반지의 저주에 걸린 골룸마냥 이슈 개수로 저글링을 하는 데 집착하며 번다운 차트를 찬양하기 시작합니다. 뒤따르는 건 개발자들입니다. 처음에는 팀 내에서 역량 평가가 낮은, 그래서 뭔가를 증명해야 하는 압박에 사로잡힌 멤버가 우선 이슈를 잔뜩 쪼개어(divide) 정복하기(conquer) 시작합니다. 시시한 작업을 위대한 과업으로 포장시키고, 관리자의 칭찬이 뒤따르는 마법을 눈으로 목격한 다른 동료들이 안 따라갈 수는 없겠죠? 결국 티켓의 개수는 다음 연봉 협상 때 내 월급을 올려 줄 중요한 추진력이 될 테니까요. 그래서 이슈 트래커를 성과에 반영해서는 안 된다고 주장하고, 실제로 그렇게 하는 회사도 많지만 그럼 뭐하나요, 개발자들은 마냥 그렇게 홀려 있을 텐데요 :-P


이뿐만이 아닙니다. 이슈가 진토 되어 넋이라도 있고 없을 지경으로 잘게 쪼개다 보면, 어느 새 림보에 빠지는 개발자도 생각 이상으로 흔합니다. 내가 지금 하고 있는 작업이 전체 프로젝트에 기여하는 바가 무엇인지는 까먹은 채 이슈를 잡는 슈팅게임에만 몰두한다는 것이죠. 우스운 일이긴 하지만, 여러분이 회사에서 하는 일이 결과적으로 프로젝트에 아무 도움이 안 되는 상황은 매우 자주 일어납니다. 그리고 지나치게 파편화된 작업 목록은 각기 조그마한 스칼라 값을 갖고 있을 뿐, 이 값들이 서로 다른 방향으로 어우러져 만들어내는 벡터를 보여주지는 않습니다.


이슈트래커를 멍청하게 활용하기 매뉴얼의 마지막 장은 이슈트래커를 최종 보고자료로 활용하는 겁니다. 시장의 흐름이나 고객의 동향을 살피기에도 정신이 없는 사업부나 오너의 눈에, 이슈트래커만큼 사기를 치기 쉬운 툴을 찾는 것도 드뭅니다. 비록 각각의 이슈는 크고 작음이 존재하나, 발행된 티켓의 수가 이렇게나 많기 때문에 결국 어느 정도 표준 분포를 그릴 수밖에 없다는 달달한 멘트까지 곁들이면 안성맞춤이죠. 이미 해결된 이슈를 이름만 조금씩 바꾸어 여러 개 만들고 일괄 해결하기, 다음 스프린트로 이슈 미루기, 반드시 우선 처리해야 하는 리팩터링이나 크리티컬 이슈 해결을 뒷전으로 미룬 채(얘네들은 본질적으로 여러 개의 이슈로 나누어지기 극도로 어렵기 때문입니다), 쌓인 똥 위에 다른 똥을 얹어 해결했다가 나중에 좀비떼처럼 부활시키기 등, 제가 굳이 일일이 나열하지 않아도 여러분이 상상하거나 겪을 수 있는 어뷰징의 사례는 무한하게 많습니다. 최고경영자가 프로젝트 진척상황을 보며 안도의 한숨을 내쉬는 동안, 프로젝트는 병들어 죽어갑니다. 이러한 어뷰징이 후일 몇 배로 큰 대가를 지불하는 것은 물론이요, 회사의 존폐도 위험하게 만들 수 있다는 사실을 모르는 사람은 아무도 없을 겁니다. 그런데 왜 이런 일이 일어나는 것일까요? 간단합니다. 관리자도 결국 월급을 받는 인간이고, 경영자에게 프로젝트 지연이나 위험성을 미리 알리면 자칫 무능한 관리자로  낙인찍히는 게 두려운 것이지요. 실패를 용인하지 않는 경영사와의 콜라보라면 그 효과는 극대화될 겁니다.


애자일이든 스크럼이든 이슈 트래커든 나발이든간에, Fail-Fast의 덕목을 강조하지 않는 방법론은 없습니다. 하지만 왜 이런 도구가 실상은 작은 실패를 감추어 큰 실패로 나아가는 도구가 될까요? 답은 간단합니다. 이 도구를 쓰는 사람의 심리에 대한 고찰을 전혀 하지 않기 때문입니다. 자기계발서에서 죽어라 떠들어도 따라 할까 말까 한 행동강령을 각양각색의 인간이 모여 사는 조직에 강요해 봤자, 결국 개인은 현재 조직문화에서 자신의 이익(연봉이나 평판, 때로는 개인의 안락함)이 극대화될 수 있는 행동을 고수하게 마련입니다. 그리고 그 결과는 보통 처참할 확률이 높습니다.


지금도 많은 개발사들이 단지 편의성을 위해, 혹은 종래의 경영 방침을 버리지 않고도 애자일을 흡수할 목적으로 도구의 힘을 빌립니다. 그리고 곧 카고 컬처로 변질됩니다. 모 후보의 대선 구호처럼, 사람이 전부입니다. 좀 더 특정하자면, '사람의 심리'가 전부입니다.

작가의 이전글 이 *카골드 같은 코드
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari