선언적 프로세스

서론

앞에 글에서 "소프트웨어 개발 프로세스"에 대해, 두 가지로 나누어 이야기 했습니다. 명시적 프로세스와 경험적 프로세스이죠.

명시적 프로세스는 계획에 의해 명료한 단계를 거쳐서 결과를 얻어 낼 수 있습니다. 커뮤니케이션은 문서로 하죠. 다만, 요구사항과 구현기술에 변화가 거의 없어야 합니다. 하지만 대부분 소프트웨어 프로젝트는 지속적으로 변화의 요소가 유입됩니다. 그러니 명시적 프로세스 보다는 경험적 프로세스가 유리합니다.

하지만 우리와 우리가 속한 조직은 명시적 프로세스가 맞다는 선입견을 가지고 있습니다. 어떤 일을 하는데 계획을 세워야 하고, 그 계획대로 일을 해야 한다는 강박을 가지고 있습니다. 반드시, 결과는 문서로 남아야 한다고 생각합니다. 이 부분에서 황당한건, 그렇다고 폭포수 모델을 적극적으로 도입하지도 않는다는 겁니다. 요구사항의 변화는 어쩔 수 없다는 건, 경험으로 익혔기 때문이죠. 

 

애매한 상황이지만, 뭔가 중구난방으로 일이 진행되는 것보다 프로세스가 있어야 한다고 판단한다면, 적어도 두가지는 필요하다고 생각합니다. 첫째, 프로세스는 측정가능해야 합니다. 변화를 준다면, 그 결과로 돈을 더 많이 벌게 되었다는 걸, 확인할 수 있어야 합니다. 둘째, 병목구간을 찾을 수 있어야 합니다. 엘리 골드랫의 "제약이론"에 따르면, 병목이 아닌 구간에서 개선 시도는 아무런 의미가 없습니다. 끈임없이 병목을 찾아서 해소할 수 있는 방법이 프로세스 내에 있어야 합니다. 

개발 프로세스 역사

1970년대 부터 "폭포수 모델"을 쓰기 시작했다고 했는데요. 그럼 그 이전에는 어떤 방식으로 프로젝트를 진행했을까요? 

 

UP(Uninfied Process)라는 개발 프로세스를 설명하는 <UML과 패턴의 적용>이라는 책에서 크레이그라만은 1950년대에 "진화적, 반복적, 점진적 개발"방식을 사용했다고 이야기 합니다.  미국 항공우주국에서 진행했던 "머큐리 계획"(1958년~1963년)에서 사용할 소프트웨어에 이런 개발 방식을 사용했는데요. "머큐리 계획"은 소련의 유인 우주비행 기술을 앞지르기 위해서 진행했던 프로젝트라고 하니, 아마 안정적이지만 실패가능성도 낮은 개발 프로세스가 필요하지 않았을까 짐작해봅니다. 

 

미국 우주왕복선 비행제어 시스템은 4주 단위 주기로 17회 반복해서 개발한 프로젝트라고 합니다. 미국 국방부는 1970년대 후반부터 1980년대 초반까지 폭포수 모델을 썼지만 1987년에 사실상 폭포수 모델을 버렸다고 서술하고 있습니다. 

 

우주 항공 프로젝트나 미국 국방부 프로젝트라면, 사실상 요구사항이 정해져 있을 것 같은 프로젝트이고, 대규모 프로젝트인데, "폭포수 모델"을 사용하지 않았다는 건, 의외죠. 

 

사실, 애자일을 해보면 어떻겠냐는 이야기를 꺼내면 가장 많이 돌아오는 답변은 "대규모 프로젝트"에서 정말 쓸만한 프로젝트냐는 겁니다. ( 솔직히 대규모 프로젝트인지 의심이 가는 규모의 일을 하는 회사에서도 관리자들은 그렇게 말하더군요. ) 그리고, 안정적인 "폭포수 모델"을 버리고 왜 생소한 방식을 사용하려냐는 이야기도 듣게 되죠. 

 

하지만, 사실 우리가 "폭포수 모델"을 선호하는 건, 프로젝트의 규모나 안정성 문제가 아닌것 같다는 생각을 하게 됩니다. 그냥 그게 익숙해서가 아닐까 싶군요. 

 

다음을 보시죠. 

 

기존 관리자들이 은퇴하고 새로운 세대가 그 자리를 물려받을 만큼 긴 시간인 30년이 흐른 뒤에야 비로소 공장의 배치가 바뀌었다. 
에릭 브린율프슨, 앤드루 맥아피 <제2기계시대>

 

증기기관으로 공장을 돌리던 시대에는 증기기관의 동력이 모든 공장에 전달되도록 기계배치를 했다고 합니다. 그러니 기술이 발달되고 전기모터가 공장에서 쓸 수 있게 상황이 바뀌었지만, 전기 모터를 사용해서 이득을 얻을 만한 기계 배치로 공장의 기계배치를 바꾸는 데는 30년이 걸렸다는 군요. 왜냐면, 증기기관 시대에 공장 분위기를 배웠던 관리자들은 그게 당연한 것이었기 때문입니다. 그냥 그게 익숙하니 그렇게 한 겁니다. 

 

1960년대(과학자가 별의별 시험을 다 하는 게 허용됐던),행동 과학자 몇 명이 천정에 바나나 한 송이를 달아둔 방에 접사다리 한 개만 가져다 두고 5마리 원숭이를 가둔후 행동을 지켜봤다. 접사다리만 올라가면 바나나를 먹을 수 있다는 걸 모두 금방 알아챘지만, 누구라도 그 근처만 가면 차가운 얼을 물벼락을 맞도록해뒀다. 어떤 결과를 낳았는지 짐작이 갈 거다. 성난 원숭이 떼, 머지않아, 접사다리 근처에는 어떤 원숭이도 가지 않게 됐다.

무리 중 하나를 물벼락을 맞은 경험이 없는 신참으로 교체했다. 두 말할 것 없이 오자마자 접사다리부터 기어오르려고 했다. 그러자 다른 모든 원숭이가 달려들어 신참을 쥐어 팼다. 신참은 왜 맞아야 했는지는 몰랐지만 이거 하난 빨리 배웠다. 접사다리 근처에는 가지 말 것, 차차 원래 무리의 원숭이를 신참으로 교체했고, 마침내 물벼락을 맞아본 원숭이는 하나도 남지 않게 됐지만, 누구라도 접사다리 근처만 가면 여전히 다짜고짜 몰매를 놨다.
"항상 그렇게 해왔으니까요" "낙타 표기식 이름"쓰기를 지키거나, 여러 규범을 지키는 것이 그런것 아닌가.
닐 포드 <능률적인 프로그래머>

 

이건, 원숭이들만의 상황은 아닌것 같습니다. 

폭포수 모델의 요구사항

<UML과 패턴의 적용>에서는 폭포수 모델에서 정의된 요구사항이 실제 사용되는지 여부를 조사한 도표를 제시합니다. ( 책에는 '피처'라는 용어를 사용하고 있군요. ), 피처를 "요구사항"으로 바꾸어서 도표를 다시 그려보았습니다. 

제가 "중요한 요구사항", "덜 중요한 요구사항","필요없는 요구사항" 이렇게 세가지로 구간을 나누어보았는데요. 흥미롭게도 20:80 법칙에 맞게 구성되는 것 같습니다. 다시말해서, 중요한 요구사항의 20%를 구현하면 프로젝트의 80%를 완성한 결과를 볼 수 있는 거죠. 

 

만약, 명시적프로세스로 이 프로젝트를 진행한다면, 사용자는 100%구현을 해야 요청한 결과를 볼 수 있지만, 경험적 프로세스로 요구사항을 작게 나누어서 "반복적"인 주기로 작업을 진행했다면, 20% 중요한 요구사항이 구현된 시점에 프로젝트의 기능 80%이상이 작동하는 화면을 볼 수 있게 되는 거죠. 

 

여기서, 스티브 잡스와 포드가 했던 발언을 언급할 차례입니다. 

Customers cannot tell you what they need
스티브 잡스 - [링크]

"고객은 뭘 원하는지 얘기해주지 않는다. 만약 고객이 원하는 걸 만들었다면 더 빠른 도스터미널을 만들었을 것이다"라고 스티브잡스가 말했다고 합니다.  재미있는건, 포드도 비슷한 말을 했다는 겁니다. 

 

사람들에게 무엇을 원하느냐고 내가 물으면, 아마 그들은 더 빠른 말이 필요하다고 답할 겁니다.
헨리 포드

사용자의 요구사항은 근본적으로 불완전할 수 밖에 없습니다. 기술적 이해가 부족하기 때문에 무얼 할 수 있는지 무얼 할 수 없는지 정확하게 제시하기 힘들거든요. 게다가 관념적으로 필요한 기능을 정리하는 것과, 사용해 보고 정리하는 건, 다른 차원의 문제입니다.  그러니 "필요없는 요구사항"이 45%나 차지하게 되는 거겠죠. 

 

이제 합리적인 질문을 해야할 시간입니다.

"요구사항을 모두 완수하는 것"과 "고객이 원하는 제품을 만드는 것" 이 두 가지 중에 회사에 이득이 되는 건, 어느 쪽일까요? 궁극적으로는 고객이 원하는 제품을 만드는 쪽이 맞습니다. 다만 상황상 요구사항을 모두 완수하는 쪽이 맞는 경우도 있긴 할 겁니다. 외주로 프로젝트를 발주받아서 하는 회사일 경우는 요구사항을 모두 충족하는 쪽이 유리하니까요. 

그러나, 회사내 정치적 환경 때문에 "요구사항 충족"쪽을 택하는 건, 그리 바람직한 선택은 아닌것 같습니다. 어쨌든 작업의 결과로 회사는 돈을 벌어야 하니까요. 

기술적 문제

소프트웨어 프로젝트를 시작할때 프로젝트 구현에 필요한 기술을 모두 구비한 채 시작하는 경우는 얼마나 될까요? 사실 그런 경우는 그리 많지 않습니다. 

예를 들어서 임베디드 분야에 프로젝트를 생각해 볼까요? 특정 제품을 만들기 위해서는 하드웨어팀과 소프트웨어 팀이 같이 움직이게 되는데요. 하드웨어 팀은 소프트웨어가 올라갈 하드웨어를 개발하고 동시에 소프트웨어 개발이 시작되는 경우가 비일비재합니다. 그렇게 되면, 소프트웨어 개발이 어느 정도 진행된 후에도 하드웨어를 다시 만들어야 하는 경우가 있거든요. 들어가는 부품이 단가가 맞지 않아서, 좀 싼걸 넣는 다든지, 필요한 부품인데, 처음엔 필요없는 줄알고 뺐다던지, 그런 경우도 생기고요. 또한 가끔 하드웨어 팀 개발자의 실수로 회로 작성이 잘못되어서 SoC(System On Chip)에 엉뚱한 쪽으로 신호가 연결되어 오작동하는 경우도 발생합니다. 소프트웨어 개발자도 SoC 제조사가 제공한 메뉴얼을 읽어봐야 할 수도 있고요. 예전에 잘 쓰든 소프트웨어 모듈인데, 특정 SoC에서는 돌아가지 않는다면, 인터넷에서 소스코드를 찾아서 해당 CPU에 맞게 재빌드하거나 또는 다시 개발해야 하는 경우도 생깁니다. 

마치 갯벌 위에 집을 짓는 것과 같은 느낌을 받는 상황이 되는 거죠. 

 

그럼, 웹 어플리케이션을 개발하는 분야는 어떨까요? 물론 우리나라는 주로 스프링 프레임워크를 많이 사용하기 때문에 자바와 스프링 프레임워크를 사용하는 점까지는 비슷할 수도 있지만, 스프링 프레임워크는 지속적으로 진화하는 프레임워크라서 계속 공부해야 합니다.  프론트엔드 분야도 마찬가지죠. 잘나가는 프레임워크들이 모두 진화중에 있습니다.  몇년전 상당히 잘나가던 앵귤라는 하위 호환성을 배제하고 2.0 버전을 내놓기 시작하면서, 많은 개발자들이 혼란속에 빠졌죠. 리엑트 역시 컴포넌트 클래스로 개발하던 기존 방식을 함수형 프로그래밍 방식으로 변화시키고 있고요. 

 

결국, 어떤 소프트웨어 개발 분야라고 해도, 이미 알고 있는 기술과 지식으로 프로젝트를 끝까지 수행하는 경우는 드뭅니다. 이는 소프트웨어 엔트로피를 감소시켜야 하는 프로젝트 관리자 입장에서는 거대한 리스크가 되죠. 

 

소프트웨어 개발은 소프트웨어 엔트로피를 감소시켜가는 과정입니다. 그렇게 하기 위해서는 요구사항과 기술의 변화를 잘 관리하는 게 중요한데요. 안타깝게도 선언적 프로세스에서 그걸하기는 너무 힘든 면이 있습니다. "변화"를 인정하지 않는 프로세스인데, "변화"가 일반적인 소프트웨어를 만들어야 하거든요.  결국, 엄청난 문서 작업으로 그걸 해결해나가게 되는 겁니다.