프로세스 개선

권한을 가진 사람의 책무는 쓸모 없는 전통을 제거하고 새로운 전통을 만드는 것이다. 아무 것도 변하지 않는 조직은 일터가 아니라 살아있는 박물관이다.

The responsibility of people in power is to continually eliminate useless traditions and introduce valuable ones. An organization where nothing ever changes is not a workplace but a living museum.

스콧 버쿤(Scott Berkun), The Years Without Pants: WordPress.com and the Future of Work

소프트웨어 개발에는 프로세스가 있습니다. 새로 작성한 코드를 저장소에 반영하기 전에는 반드시 동료 리뷰를 받아야 한다든지, 버그 수정 시에는 반드시 테스트 케이스를 추가해야 한다든지 하는 예가 그렇습니다. 이런 프로세스는 합리적인 이유가 있습니다. 동료 리뷰를 통해 코드의 품질을 높일 수 있고, 테스트 케이스를 추가하여 회귀 버그를 줄일 수 있기 때문입니다.

어떤 프로세스는 이유도 모르고 그저 전통이기 때문에 반복하고 있습니다. 이슈 트래커에서 누구나 확인할 수 있는 버그 수정 진척도를 매일 엑셀 문서로 만들어서 보고해야 한다든지, 코드 리뷰 후에 아무도 읽지 않는 코드 리뷰서를 별도로 작성해서 저장소에 올리는 일 등이 있습니다. 제가 지어낸 낸 사례가 아니라 모 대기업의 실제 사례입니다.

이런 일을 왜 하느냐고 물어보면 돌아오는 대답은 한결 같습니다.

원래 이렇게 한다. 다른 회사들도 다 이렇게 한다. (그리고 위에서 시키는 거니깐 어쩔 수 없다.)

소위 말해 전통입니다. 이유는 잘 모르겠지만, 나는 그렇게 하라고 배웠고 지금까지 해오고 있으니 너도 하라는 겁니다. 하지만 기존에 하던 대로만 해서는 아무런 발전도 할 수 없습니다. 천공카드가 인류가 발명한 최고의 저장매체라고 생각하고 기술의 진보를 멈췄다면, 우리 모두는 종이에 구멍 뚫어가며 프로그래밍하고 디버깅하는 시대에 살고 있을 겁니다.

천공카드

우리가 당연하게 생각하는 전통도 처음 시작은 혁명적인 아이디어였습니다. 일례로, 우린 8시간이 적절한 노동 시간이라고 생각합니다. 그런데 이 8이라는 숫자는 대체 어디서 나온 걸까요? 왜 6시간도 10시간도 아닌 8시간이 되었을까요? 산업 혁명 이후 18세기 후반이 되면 기업들은 이윤을 극대화하기 위해 공장을 일주일 7일, 하루 24시간 풀가동하기 시작합니다. 당연히 노동자들도 이에 맞춰 일을 하게 되었고, 하루 10-16시간씩 일을 하는 게 일반적이었습니다.

당시 영국의 로버트 오웬(Robert Owen)은 이런 방식이 지속 가능하지 않다고 보고 업무 시간을 하루 8시간으로 제한하자는 캠페인을 벌입니다. 그는 “8시간 노동, 8시간 놀이, 8시간 휴식”이라는 슬로건을 내걸었습니다. 하지만 실제로 8시간 근무를 도입한 건 20세기초 포드입니다. 1914년 포드는 근무 시간을 8시간으로 줄이고, 임금을 2배로 높이는 획기적인 조취를 했는데, 놀랍게도 2년 만에 이익이 2배로 늘어납니다. 이 사례는 이후 다른 기업들도 8시간 근무를 도입하는 계기가 되었습니다.

8시간 노동, 8시간 놀이, 8시간 휴식

8시간 근무는 20세기초 당시 공장 노동자들의 생산성을 극대화하기 위해 나온 아이디어입니다. 그런데 100년이 지난 지금 공장 노동자도 아닌 소프트웨어 개발자가 여전히 8시간 근무를 강요 받고 있습니다. 야근과 주말근무로 점철된 국내에서야 8시간도 감지덕지라고 생각할 수 있곘지만, 공장 노동자의 생산성을 극대화하기 위한 노동 시간과 대표적인 지식 노동인 소프트웨어 개발이 같을 수 있을지 의문이 듭니다. 하지만 왜 8시간 일해야 하냐고 물으면 똑같은 답을 들으실 겁니다.

원래 이렇게 한다. 다른 회사들도 다 이렇게 한다.

어떤 전통이든 시작할 때는 혁명적인 아이디어였고, 시간이 흘러 상황과 맥락이 변하면서 더 이상 유효하지 않게 됩니다. 소프트웨어 개발에 사용하는 기술이나 프로세스는 말할 것도 없습니다. 소프트웨어 산업의 짧은 역사를 생각하면 우리가 가지고 있는 전통은 대부분이 길어야 30-40년, 짧게는 5-10년밖에 되지 않은 혁명적인 아이디어들입니다. 그리고 새로운 아이디어로 빠르게 교체되고 있습니다. 이런 역사를 생각해보면 길어야 경력 10년 남짓의 개발자들이 전통을 운운하는 것이야 말로 우스운 일이 아닐 수 없습니다.

프로세스에 정답은 없습니다. 상황과 맥락에 따라 똑같은 프로세스가 좋은 프로세스일 수도 있고, 나쁜 프로세스일 수도 있기 때문입니다. 하지만 변하지 않는 프로세스는 나쁜 프로세스입니다. 상황과 맥락은 항상 변하기 때문입니다. 여러분은 일터로 출근하시나요? 아니면 박물관으로 출근하시나요?

One thought on “프로세스 개선

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s