이 일은 언제 끝나나요?
일을 추정하는 방법은?
주의: 이 글에 해당하는 내용은 소프트웨어 개발에 대해 다루는 것입니다, 다른 분야에 적용하기에는 부족한 방식임을 밝힙니다. 그리고 간단한 도구 만드는 수준이 아니라 좀 큰 프로젝트성 일을 하는 경우를 다루고 있습니다.
이 제품이 나올 수는 있는 건가?
"그냥 9월 말까지 나왔으면 좋겠어. 그 이후에는 다른 일정도 많고 어려울 것 같아." 중간에 팀의 리더가 나가는 일로 어쩔 수 없이 그 일을 맡은 A 씨는 이런 주문을 받았습니다. 그런데 기존 팀 안의 사람들의 얼굴을 보니 그냥 '갸우뚱'한 표정이었습니다. 왜 이러는 걸까요?
우선 말로 그냥 이야기 나눈 제품의 내용은 그리 어렵지 않았습니다. "뭐 저 정도 구현하는데 얼마 안 걸릴 것 같네?"라는 생각이 들 정도였지요 그런데 실제 그럴까요?
추산에 대한 마음 자세
추산하는 우리의 마음의 자세를 '정확하게 추산해서 딱 그만큼의 자원만 투자하겠다'가 되면 안 됩니다. 그럼 어떻게 해야 할까요? 우리가 가져야 하는 자세는 '어디까지 오차가 있을 것이고 이 오차를 우리가 감당할 수 있는 정도인지 아닌지 알아보겠다'라는 자세가 되어야 합니다.
왜 그렇게 될까요? 미래는 어차피 가본 사람이 없습니다. 즉 어떠한 경우라도 '틀릴'것이라는 것입니다. 특별히 불분명한 것들이 산더미처럼 쌓여 있는 소프트웨어 개발에 대해서는 확답을 한다는 것은 불가능합니다.
사실 건축이나 영화업계에서도 이런 이유들 때문에 아래와 같은 방법들을 고안해내고 연구도 많이 되고 있습니다. 물론 그런다고 저대로 다 되는 게 아니지요.
Dealing with uncertainty in the Hollywood Movie industry
Another paper about movie industry
Managing Uncertainty (in Architecture industry)
세상에 쉬운일이란 없네요..가장 중요한 것: 우리에게 얼마나 자원이 있나요?
언제나 문제는 우리가 가진 자원입니다. 시간이든 돈이든 제한이 된 상황에서 우리는 일을 해야 하고 할 수밖에 없습니다. 이런 제한이 먼저 명확한지 확인해야 합니다. 아주 가끔 이런 것들 무제한으로 주어주겠다는 경영자들이 있는데 저라면 오히려 겁이 나서 나옵니다. 정상적으로 사업을 운영하는데 시간과 돈이 제한되지 않은 것은 자본주의 사회에서 없는 게 정상이기 때문입니다. (오픈소스 프로젝트라면 몰라도)
며칠 단위로 일정을 추산할 수 있나요?
자, 앞의 이야기로 돌아와 봅시다. 현재 A는 그저 '어떤 일을 하자'라는 것 빼고는 뭐 아무것도 없습니다. 이렇게만 되어서는 이 일이 당장 할 수 있는 일인지도 감이 없습니다. 지금 그렇다면 이 일이 언제쯤 될 수 있을지 예상할 수 있을까요?
매우 위험: 1년 단위 일정 추산만 가능할 거 같다.
즉 지금 상태로 우리가 일정을 추산한다면 어떨까요? 1년 단위로는 가능할 겁니다. 즉, 올해 끝날지 아닐지 정도는 가능할 겁니다. 예를 들어 이렇게 하는 겁니다. "자세히는 모르겠지만 내년 8월이나 다음 해 8월 정도 가능한 상황입니다."
"아니 그런 엉터리가 어디 있어요?!"라고 상대방은 말할지도 모르겠습니다. 그런데 이게 또 생각해 보면 말이 됩니다.
의외로 이 바닥의 신화가 있는데, 천재 개발자에게 어떤 크기의 일이든 요청하면 "이 일은 며칠까지 할 수 있을 것입니다."라고 즉시 답이 나온다는 것입니다. 그런 건 없습니다. 척 보고 진실을 말할 수 없죠.
월 단위, 일 단위로 할 만큼 명확한 정보가 없는 상황입니다. 즉 이 상태로 한다면 사실상 99% 틀린 추정입니다. 어차피 틀릴 거면 더 '크게' 틀리는 게 낫습니다. 감수할 피해의 크기를 크게 각오하고 가자는 것이니까요.
아마 이러면 상대방은 "아니 말이 돼요?"라는 반응이 나오는 게 99% 일 겁니다. 이게 중요합니다. 이런 경우 "이게 어떤 일이냐면~"이라면서 상황에 따라서는 분노가 섞인 반응을 하면서 더 많은 정보를 쏟아낼 것입니다. 우리는 이 정보가 중요합니다. 이 정보들을 기반으로 한 단계 더 자세한 추정을 해볼 수 있기 때문입니다.
상대방에게, "이 일의 크기에 대해 아직 우리가 추정하기 어렵다"라는 것을 간접적으로 알려줄 수 있습니다. 이때, 상대방이 계속 정보를 더 주며 자세한 추정을 도와주지 않는다면 굳이 이 상대방과 일을 해야 할지 말아야 할지 스스로 답을 하실 수 있을 것입니다.
어느 트위터에서 가져온 그림인데, 이 그림을 보면 어떤 사용자 스토리 하나에 대해서 초기일수록 아는 것이 없고 끝에 가야 모든 것을 알게 된다는 것을 보여주고 있습니다. (이 그래프의 과학적인 근거가 있는 건 아닙니다. 트위터 계정 주의 직관입니다.)
조금 덜 위험한 단계: 월 단위, 일 단위로 일정을 잡아보자
위와 같은 상황에서 한 단계 더 들어가 봅시다. 우리가 원하는 목표는 일정을 '월 단위, 일 단위'로 예측을 해보려면 무엇을 해야 할까요? 더 많은 정보를 얻어야 합니다. 그럼 어떻게 정보를 더 얻어야 할까요? 무언가 진행해야 가능합니다. 이 사실을 무시하면 아무것도 되지 않습니다. 그럼 어떻게 진행해야 할까요? 우리는 이미 많은 방법을 알고 있습니다.
프로토타이핑(Prototyping) 하기: 시간을 제한 (1주일 혹은 하루)하고 막무가내로 가장 핵심적인 것만 구현해봅니다. 그러면서 많은 문제들, 요구사항의 허점들을 찾습니다. 프로토타이핑은 꼭 코드가 아닐 수도 있습니다. 종이로라도 무언가 만들어져야 하는 것을 그려보는 겁니다. 가능한 완결될 것이야야 합니다.
짧은 시간이라도 진행하기: 프로토타이핑은 무언가 '완성된'것을 만드는 것이라면, 이건 뭐 지금 생각하는 대로 , 알고 있는 대로 요구사항을 정리해서 에픽/스토리 등으로 일을 정리해서 1주일이라도 한번 만들어 보는 겁니다. 완성되지 않아도 됩니다.
이 모든 방법들의 끝에는 회고를 통해서 이러한 것들을 찾아내야 합니다.
* 처음 우리가 생각했던 것과 많이 달라진 것들은 무엇입니까?
* 처음 생각한 구조나 방법들이 들어맞았나요?
* 지금 뭔가 비효율적인 부분들이 보인다면 이것들을 어떻게 해결할 수 있을까요?
이렇게 해서 얻어낸 지식들을 가지고 일정을 추산해냅니다. 물론 한 번에 몇 달 안에 이 일이 끝나리라 것을 잡아낼 수는 없습니다.
만약 스크럼을 이용하고 있다면, 모든 일들의 Story points를 최대한 매겨보세요. 이를 이용해서 1주일이라도 일을 해보면 이 일에 대한 팀의 개발 속도를 알게 될 것입니다. 이를 기반으로 나머지 일들을 정리해보면 몇 개의 스프린트로 나눌 수 있을 것이고 이것을 가지고 '월 단위'까지는 추산이 가능할 겁니다.
만약 칸반을 이용하고 있다면, 모든 일들의 Story points나 티셔츠 크기 등으로 일의 크기를 추산해보세요 이를 이용해서 1주일이라도 일을 해보면 이 일에 대한 팀의 개발 속도를 알게 될 것입니다. 이를 기반으로 매일 /매주/몇 주 단위로 무언가 내보낼 주기를 정해보실 수 있을 겁니다.
가장 중요한 건, 일의 속도. 그러니까 주당 몇 개의 일 / 혹은 몇 Points를 팀이 뽑아내는지를 측정해보는 겁니다. 이것을 가지고 현재 있는 일의 개수 등을 이용해서 추정해볼 수 있을 겁니다.
하루, 이틀, 일 단위로 일정 추산이 될까?
유니콘이라고 있지요, 직접 본 사람도 없는데 누군가는 봤다는 이야기만 무성한... 정말 쉽지 않고 설사 그렇게 해오는 사람이 있다면 의심을 해보시길 원합니다. 거의 되는 경우가 없습니다.
일정 추산해보니 마감을 넘겨요!
이럴 때, 방법은 일의 양을 줄이는 게 다입니다. 기능을 줄이거나 더 단순하게 만드는 거죠. 그게 불가능하다고요? 뭐 해도 안될 거를 그럼 해볼 수 있는 사람들을 찾아보시든가요. 이런 경우 대부분 결국 아무도 할 수 없는 일이었다는 게 프로젝트의 후반에서야 깨닫게 되더라고요.
왜 이걸 하기 어려울까?
그냥 바로 뭔가 과정없이 되는 마법은 없습니다.그냥 하면 안 돼?
"아니 뭐 이렇게 어렵게 해서 일정을 내? 당장 말하지 못해?", "경험 있는 사람이라면 적어도 며칠 안에 된다고 이야기는 하고 알려줘야 하나요?", "아니 내일까지 다 해야 한다고요?"..... 뭐 제가 아는 한 별별 성마른 반응들은 각오하고 있습니다.
다시 한번 이야기 하지만, 우리가 초기일수록 일에 대한 정보를 알 수가 없다는 것을 인정해야 추산이 가능합니다. 정보가 없는데 무조건 절벽으로 뛰어내리라는 리더를 따르는 것은 죽으라는 명령입니다. 그러나 우리의 마음은 늘 해오던 방식으로 돌아갑니다. 정신도 '관성'이 있거든요.
아무리 급하게 아무리 몰아친들, 일은 그 생긴 대로 돌아간다는 사실을 우리는 인정해야 합니다. 그 일이 어떻게 생겼는지 모른다면 함부로 그 일에 대해서 말하면 안 되는 겁니다. 누군가의 삶을 다 모르는 상태에서 함부로 누군가를 평가하는 일을 하지 말아야 하는 것처럼 어리석은 일이 되는 겁니다.
그럼에도 불구하고 자꾸 몰아친다면, 이것은 한마디로 '무당질'이 되는 겁니다. 무당이 제 멋대로 혹은 자신의 이익을 위해 사람을 조종하는 일이 되지요. 혹세무민에 빠지면 나라가 어찌 된다? 여러분의 그 일도 그대로 될 겁니다. 이성을 유지하세요.
일이 어떤지 재면서 아무것도 안 하는 거 아님?
결과로 이 질문에 대한 답을 할 수 있을 거 같습니다. 진짜 아무것도 안 하면서 안될 이유만을 말하는 자들이 세상에 없는 건 아니거든요. 최대 2주 정도 프로토타입을 진행하도고 일정을 추산하지 못하는 엔지니어들이라면 진지하게 같이 일을 하는 것을 고민해야 할 수 있습니다. 다만, 이른바 요구사항이 더 늘어나지 않을 때 이야기입니다.
결론
다른 일과 달리 소프트웨어를 만드는 일은 실수를 줄여가는 거지 결코 완벽하게 준비해서 성공하는 일이 아닙니다. 게다가 매번 같은 일은 거의 없기 때문에 최대한 짧은 단거리로 핵심적인 것들을 만들어 보기 전에는 일정을 추정하기 매우 어렵습니다.
추산을 위해 시간을 쓰는 것을 아까워하지 마세요. 물론 한 번에 그 모든 것을 다 알 수는 없지만 지도 조차 그리지 않고 탐험을 할 수는 없습니다. 항공사진을 찍는다 생각하고 시간을 최대한 알차게 쓰세요. 만약에 이런 시간조차 아깝다면 혹시 이 일을 진행하는데 마음속에 다른 문제가 없는지도 고민해야 합니다.
이 모든 길이 무언가 이루는 과정중입니다."일이란 먹을 음식과 함께 매일의 의미를 찾는 행위이고, 돈과 함께 인정을 추구하는 행위이며, 무기력함이 아닌 경이로움을 찾는 행위이다."
“[Work] is about a search…for daily meaning as well as daily bread, for recognition as well as cash, for astonishment rather than torpor,”
by <Working>의 저자 Studs Terkel
