프로세스

모든 일의 과정은 중요합니다. 좋은 프로세스는 든든한 결과를 만듭니다.

무엇을 하든 무엇을 만들든 프로세스는 언제나 있습니다. 계획이란 말을 써서 계획안에 들어있기도 하구요. 업무나 일 등에도 존재합니다. 단지, 모르거나 인식하지 못하거나 필요없다고 생각할지도 모르고요. 그래도 항상 어디에나 존재합니다. 이 프로세스는 다양하기도 하고 비슷하기도 합니다. 

어떤 사람들은 이렇게 말합니다. 프로세스가 중요해? 다른 말로 과정이 중요해? 결과가 좋으면 되지! 하지요. 네. 반은 맞고 반은 틀렸다해야할까요? 여하튼, 프로세스는 드러나지도 않고 인기도 없고 많은 사람들에게 회자되지 않는 것이라고 생각합니다. 대부분 '과정' 정도로만 이해하고 있습니다. 네! 뭐, 틀린말은 아닙니다. 프로세스 안에는 분명히 과정이 존재하니까요. 그것도 많은 부분을요. 

하지만, 프로세스도 과정만 있는 것은 아닙니다. 그 안에는 여러가지 의사 결정사항들이 있습니다. 그리고 의사결정을 하려면 무엇이 필요하죠? 뭔가 판단할 수 있는 기준이나 지표가 필요합니다. 또한 프로세스는 가만히 있는 것이 아니라 절차라는 활동도 필요합니다. 이 모든 것들이 프로세스를 구성하고 정의하죠. 그래서 단순히 과정이라고 치부하기에는 뭔가 부족한 것이 있습니다. 

저는 프로세스를 만들고 그것을 관련 부서에게 알리고 지킬 수 있도록 합니다. 현업에 맞지 않으면 변경하여 개선합니다. 또한 우리가 협의한 프로세스를 성실하게 준수하고 있다라고 누군가에게 공식적으로 인정을 받는 일(인증)들도 해왔습니다. 소프트웨어의 프로세스는 사람들이 하기 때문에 여간 어려운 일이 아닙니다.

왜냐구요?

첫번째 사람들은 자기마다의 자신의 일에 대한 프로세스가 있습니다. 기존 방식대로 하면 되는데 굳이 다른 것을 해서 모니터링까지 받아야하니 맘에 들지 않죠. 업무 효율성도 떨어질 것 같고 하지 않았던 일들 특히 산출물(대부분 문서입니다.)까지 만들어야 하니 여간 못 마땅해 합니다. 처음에는 적응하느라 힘들지만 좀 지나면 그러니까 성숙(?)해지면 꽤 괜찮아집니다. 그렇지 못할때가 있으면 제안하고 협의하면서 바꾸면 됩니다. 좀 더 나은 방법으로 말이죠. 

두번째로 사람들이 쓰는 언어, 단어들의 정의나 개념이 각자 약간씩 차이가 있기 때문입니다. '기획' 이란  말을 아시죠? '기획'이란 말은 어디에서 왔을까요? 누구는 일본에서 쓰이던 단어라고 하구요. 영어로도 딱히 맞는 단어가 없습니다. 'Plan' 정도가 될 법한데, 우리 말로는 대부분 '계획'이라고 인식하고 사용합니다. 구글번역에서는 'Plan' 이고 파파고에서는 'Planning' 이라고 번역을 합니다. 어떤 분은 '기획'을 '계획'과 동일하게 생각하시는 분이 있고 어떤 분은 다르게 생각합니다. 그러니까 '기획'이라는 말이 '계획'을 하기 전에 하는 어떤 활동이라고도 하구요. 이렇게 다르게 생각하고 있어요. 이런 차이를 극복하기 위해서 새롭게 정의하고 활동하게 하는 것이 '프로세스'를 업으로 하는 사람들의 업무 중 하나입니다. 

활동도 마찬가지겠죠. 프로세스에는 여러 활동들로 구성되는데 이러한 활동들도 협의하여 재 정의합니다. 그리고 그 활동을 했는지 안했는지 확인을 하죠. 활동의 활동(검증하는 활동)을 더 합니다. 좀 더 이야기하자면 확인하는 활동과 활동한 결과물의 대한 검증활동도 합니다. '계획'이란 활동했으면 '계획' 자체의 활동을 했는지, 그리고 '계획'한 활동의 결과물인 '계획서'에 대한 검토 활동을 한다는 것이지요. 그래서 보통, 사람들이 싫어합니다. 나 자신의 치부를 보여줄 수 있는 거니깐요. 잘 한거면 몰라도 못한건 시정하라고 하니까 싫죠. 업무가 늘어나는 겁니다. 보통 잘한 건 이야기하지 않습니다. 못한 건만 끄집어 내서 말할 때가 많습니다. 저도 개인적으로 좀 그렇습니다. 잘한 건 잘했다고 말해주었으면 하고 말입니다. 하지만, 저도 막상 심사활동을 하면 지적하는 것이 우선입니다. 아무래도 비용이라는 핑계를 대야할 것 같습니다. 모든 것은 비용입니다. 잘했다고 칭찬할 시간에 못한 것을 알려줘야 무사히 주어진 시간안에 또는 빠른 시간안에 활동을 마무리할 수 있으니까요. 또한 우리의 목표는 하고자 하기로 한 기준대로, 과정대로 맞게 지켰는지가 중요하기 때문입니다. 60점 이상이 합격이면 61점을 맞건 90점을 맞건 둘 다 합격인 것과 동일합니다. 90점 짜리 합격 만들겠다고 시간을 더 투자하면 그만큼 비용이 더 듭니다. 

어쩌다 확인 및 검증활동까지 얘기했네요. 네, 프로세스는 세우고 만드는 것도, 여러 활동도 있지만 지키는 활동, 지키게 하는 활동도 있다고 말씀드리고 싶었습니다. 우리가 생각하는 '과정'이라는 것은 알고보면 생각보다 더 넓은 영역을 가진 것이고 나 혼자가 아닌 여럿이 하는 일에서는 서로간의 합의한, 때론 계약한 '프로세스' 라는 것입니다. 

그럼, '프로세스'는 왜 해야하냐구요? 그건 당연히 좋은 결과를 내기 위함입니다. 더 나아가 우리가 지속적으로 원하는 결과를 만들기 위함입니다. 의자 하나를 만든다고 합시다. 자신이 의자를 만든다고 할때, 어떤 과정으로 해야할지 상상해 봅시다. 분명히 여러 과정들(계획, 설계, 자재구입, 샌딩, 절단, 조립, 채색 등)이 있을 겁니다. 또 다른 의자를 만든다고 칩시다. 이번에도 지난 번에 했던 과정대로 하기로 했습니다. 그런데 이번에는 그 세부 과정 중에 샌딩을 안하고 만들었다면 어떤 일이 일어날까요? 의자는 만들었지만 꺼끌꺼끌한 의자가 나왔을 겁니다. '샌딩'이 절단된 나무를 매끄럽게 해주는 것인데 이 절차를 빼먹었기 때문이죠. 이렇듯 사람들은 문서로 표시하건 머리속으로 생각하건 어떤 일련의 과정을 생각하고 지켜서 결과물을 만듭니다. 이 과정이 표준화 또는 일반화되면 어느 정도의 품질을 보장하는 결과물을 얻을 수 있습니다. 물론 무엇을 만드느냐에 따라 그 과정은 다를 수 있습니다. 저는 SW분야에 있기 때문에 SW를 만드는 과정을 알고 있습니다. 글을 쓰시는 분들은 글을 쓰는 과정을 잘 아시겠죠.

소프트웨어 프로세스 예시.

'프로세스'라 하면 좀 어렵고 딱딱하고 막연한 활동이라 할 수 있지만, '과정'인데 기준과 절차, 그리고 합의하고 준수하는 활동이라고 하면 좀 더 쉽게 받아 들일 수 있을 겁니다. 따라서, 무언가 좋은 것을 만들고 싶다면 과정을 자세히 나누어보고 생각해보는 것이 필요합니다. 그렇게 해서 만들어진 과정은 좋은 품질을 만들어 낼수 있는 역량을 갖추게 하거든요. 물론 결과가 안 좋을 수도 있습니다. 여러가지 요인들이 있겠지만 무엇보다 세부 프로세스를 역순으로 돌아가면서 짚어보세요. 어디를 빼먹었는지 아니면 어디를 제대로 하지 않았는지, 등 들여다보시면 정확하게 무엇이 잘못되었는지 알 수 있을 겁니다. 이런 과정 자체도 프로세스의 세부 활동 중에 하나인 것을 알면 더욱 좋겠습니다.