개발자가 애자일 방법론을 악용하는 시나리오

지금까지 나온 개발방법론은 100개가 넘는다. 대부분 잠깐 동안의 유행으로 사라지고 남아 있는 것은 몇 개 없다. 개념적으로는 존재하지만 개발방법론이라고 하는 것은 실제로는 존재하지 않는다고 보는 것이 더 정확하다. 그러니 어떤 개발방법론을 사용할 것인가 하는 것을 의논하는 것은 이미 바람직한 상황이 아니다. 이전 기사에서 프로젝트관리시스템이 필요 없다고 하는 것과 비슷하다. 있으나 없으나 별로 변할 것도 없다. 돈과 시간만 낭비하기 딱 좋다. 잘나가는 회사는 특정한 방법론이라는 것을 따라 하지도 않거니와 상식적이고 합리적인 수준에서 잘 개발할 수 있다. 그런 것을 전문가의 특징인 암묵적 지식이라고 한다.

잘 되는 회사에서는 현재 개발관행을 바꿀 필요도 없지만 하여튼 뭔가 안되니까 방법론이라도 바꿔보자는 발상을 당연히 하게 된다. 혹은 개발자들의 호기심에서 시작하기도 한다. 혹은 경영진이 바뀌면 뭔가 해야 하니까 합리화하기 좋은 상용 아이템이기도 하다. 방법론 외에도 프로세스를 도입해 보자 혹은 조직을 바꿔보자 같은 것도 마찬가지이다. 메뉴만 변했지 몇 십 년이 지나도 전형적으로 반복되는 케케묵은 아이템들이다. 이렇게 쉽고 뻔히 눈에 보이는 방식으로 좋은 결과를 기대하는 것은 복권당첨을 바라는 것과 같다. 이런 식으로 쉽게 내가 잘 할 수 있다면 "개나 소"의 범주에 들어간다. 구글이나 애플이 방법론이나 프로세스를 잘 사용해서 성공한 것이 아니다. 선수들의 역량이 높아서 성공하는 것이다. 이런 주변 것들은 성공과는 인과관계가 없는 행위이다.

국내에서는 CMMI 같은 프로세스로 한때 비법인 양 소란을 떨었지만 지금쯤이면 대부분 돈과 시간만 낭비했다는 것을 깨달았을 것이다. 그 당시는 아무리 얘기해도 유행을 깨뜨리기는 불가능하다. 그래도 회사 홍보에 사용한 좁쌀만한 이익은 있었을지 모른다. 개발방법론은 오래된 이슈이고 지금 한국에서는 애자일 중에서도 수 많은 다른 애자일 방법론은 거들떠 보지도 않고 유독 “Scrum방법론”에 광신하고 있다. 시금치가 몸에 나쁜 것은 아니지만 특별히 좋을 것도 없다. 애자일을 사용하려는 사람들이면 일단 유튜브나 인터넷에서 “Agile is dead” 라는 것을 검색해 보기 바란다. 항상 그렇듯이 성공사례도 없는 것은 아니다. 하지만 애자일 관련 장사꾼의 소리는 가짜 뉴스이니 배제하고 들어야 한다.

경영진이 결정했던, 혹은 개발자들이 주장했던 아직 살아 남은 애자일 Scrum 방식을 도입하기로 했다고 하자. 여기서부터 어떤 일이 벌어지는지가 이 기사의 주제이다. 처음에는 아주 아름답게 보인다. 전통적인 문제인 요구사항이 변하는 상황을 잘 대처하는 것이 중요하다는 정의로움을 내 세우며 시작한다. 똑 같은 소리가 이미 1960년도에 소프트웨어 업계의 가장 큰 걱정거리였다. 지금까지 계속되는 논쟁거리이기도 하다. 전혀 새로운 상황이 아니지만 하여튼 이제 마음 잡고 잘 개발해 보겠다고 하는 데 말리기 어렵다. 이제 고생 끝 행복 시작이라고 생각하기도 한다. 이런 인간의 단순한 무지와 집착에 대해서는 경험해 보기 전에는 어떤 충고도 먹히지 않는다.

이제 시작이다. 기존의 폭포수 방법론에서 요구되던 코딩 전의 문서를 작성하기도 싫은데 Scrum에서는 진행하면서 조율한다는 것이 너무 행복하다. 지금까지도 요구사항 문서를 제대로 적은 적이 없었지만 그것보다도 훨씬 더 적게 적어도 된다. 심지어는 무엇을 개발할 지 비전 정도만 있는 상태에서 코딩을 시작하는 용감무쌍한 경우도 있다. 사실 이 세상의 99.9%의 소프트웨어 회사는 어떤 형태이든 반복적인 방법론(Iteration)을 사용한다. 하여튼 마치 폭포수 모델을 아는 것처럼 얘기하지만 분석->설계->구현->테스트로 진행하는 것을 폭포수모델이라고 착각한다면 반대로 Scrum을 제외한 모든 방법론은 폭포수 모델일 것이다. “착하게 살라”는 실현 불가능한 교훈 한마디 듣고 세상 사는 법을 깨달은 것 같은 착각이다. 

모든 것의 핵심은 내용의 충실도 이다. 하여튼 이런 엉터리 폭포수모델 조차도 하기 싫으니 더 자유로운 세상인 Scrum 놀이터에서 놀아보자는 설렘으로 시작한다. 이력서에 자랑스럽게 한 줄 추가할 수도 있다. 갑자기 내 역량이 높아진 것 같이 착각한다. 이런 경력이 취직에 도움이 된다는 국내 소프트웨어 업계가 한심스럽다. 필자 같으면 Jira라는 이슈관리시스템에서 Scrum View를 이용해 한 두 시간 놀아보면 이력서에 한 줄 적을 수 있다. 이게 무슨 의미가 있는지 모르겠지만 하여튼 국내 현실은 그렇다.

일단 Scrum을 시작은 했고 앞 단에서 미리 할 일이 적으니 코딩 시작은 빠르다. 어차피 계속되는 조율 작업이 있을 텐데 앞 단에서 시간을 많이 들일 필요가 없다고 생각한다. 그래도 시작하면 뭔가 구체적인 일 할 항목이 있어야 하는데 충실할 리가 없다. 우리는 Scrum이니 걱정할 것 없다. Scrum 방식답게 해야 할 일을 Daily 회의에서 구체화하든지 새로 만들든지 해서 일 할 이슈 항목을 만들어 낸다. 그리고 통상 2주마다 있는 스프린트 종료 시 구동되는 제품을 만들어 내야 하니 그에 필요한 항목을 정리한다. 그 외는 Backlog라는 창고에 쌓아둔다.

그런 상태에서 다음 날 모두 다시 만난다. 매일 만나야 되니 당연히 많은 개발자들이 필요한 대규모 개발의 경우에는 불가능하다. 이 Daily 회의에서 어제 무슨 일을 했고 오늘은 무슨 일을 할 것이고 계획에 변경이 있는지를 전광석화처럼 확인하고 15분 만에 회의를 끝낸다. 이런 통상 15분짜리 Daily 회의가 매일 진행된다. 그게 Scrum의 원칙이다. 이 회의는 Standup Meeting이라고 해서 서서 해야 한다는 웃기는 규칙도 있다.

그런데 행복할 줄 알았던 개발자의 입장에서 보면 매일 보고를 하면서 진행한다는 것이 지옥일 수 있다. 일용직 인부의 할당량을 검사하는 것이나 다름 없다. 그러니까 방식을 변경하기 시작한다. 매일 만나는 것은 의미가 없으니 일주일에 한번 만나자고 하면 일단 개발자는 모두가 찬성한다. 관리자는 관리가 어려워 지니 당연히 싫다. 하지만 모든 개발자들이 우겨대면 방법이 없다. 이렇게 Daily 회의가 Weekly 회의로 일단 변경된다. 그러면 또 규칙을 어긴 문제가 생기니 우리는 효율성을 위해 필요할 때마다 따로 만나서 조율한다고 그럴듯한 변명거리는 미리 만들어 놓는다.

이렇게 시간이 흘러 2주 만의 스프린트가 종료되면서 뭔가 구동할 수 있는 것이 나와야 한다. 그러면 고객 혹은 기획자 등 소위 Stakeholder라고 하는 사람에게 Demo를 시연해야 한다. 그게 스크럼의 가장 중요한 원칙이다. 그런데 계획한 대로 2주 마다 나오지 못하는 경우도 있고 Stakeholder가 시간을 낼 만큼 한가한 사람이 아닐 수도 있다. Stakeholder가 없으면 개발자들이 하고 싶은 대로 진행한다. 당연히 모든 것들이 개발자들이 편한 방식으로 진행한다. 진행하면 할 수록 귀찮은 존재가 되는 Stakeholder의 참견을 배제할 수 있도록 열심히 노력한다.

요구사항이 최초에도 대충 정해서 시작했는데 이렇게 되면 제품은 산으로 가기 시작한다. 이것을 Fake Agile이라고 한다. 보통 Scrum 팀의 규모를 2명에서 5명 정도가 적당하다고 하는데 그럼 6명은 안 되는 것인가? 그러니 또 9명까지는 괜찮다고 하는 사람도 있다. 이런 숫자 노름부터가 웃기는 규칙이다. 2명으로 한다면 Scrum 팀 수가 많아져 Stakeholder는 여기저기 뛰어 다니느라 시간이 없을 것이다. 팀을 9명으로 한다면 15분의 Daily회의도 어렵고 관리하기가 어려울 것이다. 이렇게 하든 저렇게 하든 우스꽝스러운 규칙들에서 문제가 생긴다.

국내 환경에서 통상 그렇듯이 Stakeholder가 그렇게 상세하게 검토할 시간이 없기 때문에 설렁설렁 끝까지 간다. 그래서 5번째가 되었던 10번째가 되었던 마지막 Sprint까지 그냥 간다. 어떤 경우는 Stakeholder가 한번도 보지 않을 수도 있다. 개발 중인 중간 제품을 시간을 내서 사용해 보고 싶어하는 Stakeholder는 거의 없다. 10번의 Sprint를 진행하면서 매번 중복된 것을 시연해 보고 검수한다는 것은 정말 지겨운 일이다. 마지막까지 가면 그 때는 심각한 상황이니 Stakeholder가 자세히 들여다 본다. 잘못된 지적과 새로운 요구사항들이 쏟아져 나온다. 폭탄이다. 국내 SI 사업이 진행하는 관행과 동일하다. 이전의 가짜 폭포수모델보다 더 열악한 상황으로 갈 수 있다. 시작은 대충하고 중간에 Stakeholder의 충실한 검수 과정도 없고 개발자들은 마지막에 폭탄이 터질 때까지는 편하게 삶을 즐길 수 있다.

그 때까지 윗사람에게 보고는 적당히 둘러 댈 수 있다. 결국 윗사람 들에게 추궁 당하는 것은 마지막 한 번뿐이다. 항상 다음 Sprint에서 잘 할 수 있다고 계속 뒤로 미룬다. Scrum이 원래 그런 것이니 이의를 제기할 수도 없다. 물론 처음부터 이런 상황을 고의로 하지는 않는다. 그렇다면 범죄자이지 개발자가 아니다. 하지만 환경이 그렇게 만들고 진행하다 보면 얼마든지 합리화를 할 수 있다.

결국은 Scrum이라고 해서 시작하지만 중요한 본질은 다 사라지고 껍데기 한두 개만 남은 가짜가 된다. 가짜가 생존할 수 있는 이유는 다수인 개발자들이 편하게 변형되었기 때문이다. 개발자들의 관리를 타이트하게 하려고 만든 Scrum이 변질된 가짜 Scrum의 우산 아래 마지막 순간까지는 편하게 개발을 할 수 있다는 것이 딜레마이다.

필자가 꼭 보고 싶은 것은 Scrum의 원칙인 매 Sprint마다 Stakeholder가 참여해서 심각하게 시연하고 검토를 하고 협의를 해야 한다는 것이다. 이런 고객 참여가 Fake Agile인지 아닌지를 판별하는 가장 핵심 지표이다. 그런데 보통의 소프트웨어 제품들이 Scrum 처럼 진행 중에 요구사항을 변경하거나 결정해도 되는 제품은 드물다. 당연히 홈페이지 제작할 때는 Scrum방식이 나쁘지 않다.

위의 시나리오가 Scrum을 할 때 통상적으로 벌어지는 시나리오이다. Scrum을 제대로 수행하고 있다면 필자가 진심으로 존경을 표할 것이다. 그런 팀이 있다면 계속해서 Scrum을 하기 바란다. 현실은 기존의 가짜 폭포수방식보다 훨씬 어렵다. 솔직히 개발자로서의 입장에서 보면 제대로 된 Scrum은 절대 하고 싶지 않다. 생각만 해도 회사에 가기도 싫어진다. 그러니 누가 억지로 Scrum을 시킨다면 수 많은 편법을 동원하려는 것은 고통을 싫어하는 인간의 본능일 것이다.

소프트웨어 회사에서 프로젝트관리시스템(PMS)은 필요 없다

국내 소프트웨어 회사에서 프로젝트 관리를 심각하게 고려하는 경우는 목마른 사람에게 소금물을 주는 암담한 경우가 거의 대부분이다. 프로젝트 관리(Project Management, PM)를 하려면 프로젝트관리 시스템(Project Management System, PMS)이 필요하다 라고 생각하는 것은 단세포적인 논리이다. 오버 스펙인 도구를 사용하는 부작용이 더 클 수도 있다. 소프트웨어 개발을 잘 하겠다는 것과, 프로젝트관리를 잘 하겠다는 것과, PMS 도구를 사용하겠다는 세가지 목표는 상관관계가 크지 않다.

먼저 국내 소프트웨어 업계 상황을 살펴보면 가장 PMS가 잘 구축되어 있는 회사는 대기업 시스템통합(SI) 회사이다. 잘 되어 있다는 표현은 "효율적으로 사용된다"라는 의미를 내포하고 있기 때문에 옳은 표현이 아니고 거대한 PMS라고 하는 것이 옳다. 거대하다 못해 짓눌리는 느낌이 든다. 필자가 이전에 블로그에 게시한 전세계의 SW 개발 Outsourcing 상황에 대한 기사에서 베트남의 SI 회사들이 인도회사와 함께 글로벌 고객들을 상대로 하는 Outsourcing 시장의 최고의 강자이다. 그런데 국내 소프트웨어 회사들은 그런 베트남 SI 회사에 프로젝트를 발주할 수 있는 역량도 없고 반대로 국내 SI 회사들은 다른 외국의 고객들로부터 프로젝트를 수주할 수도 없는 역량인 것이 소프트웨어 업계의 현실이다. 극히 소수가 시도했다고 해도 다 실패로 끝났다. 철저한 국내용 SI 생태계인 것이다. 

국내에서도 외주 개발이 성공적으로 끝난 경우는 필자의 경험상 거의 없다. 열악한 외주개발 생태계는 개선 없이 몇십년이 그대로 유지되고 있는 것이다. 필자가 글로벌이라고 표현할 때는 중국과 동남아시아는 제외한다. 이런 후진국형 시장은 특수한 관계와 특수한 계약에 의해 고객을 인위적으로 만들 수는 있지만 글로벌 시장에서의 성공과는 전혀 상관이 없다. 예를 들어 국내회사의 외국 지사에 판매한 것을 법적으로는 글로벌 매출로 주장하여 정부의 지원금도 받아가지만 필자는 인정하지 않는다.

물론 외주개발 생태계만 열악한 것이 아니다. 회사내의 개발도 다를 리가 없다. 다만 프로젝트가 계약관계에 의해 수행되지 않기 때문에 소송이 걸리지도 않고 잘 나타나지 않기 때문이다. 다행인 것은 아무리 역량이 떨어진다고 해도 어차피 똑같은 국내회사들끼리의 경쟁이다. 외국 경쟁 제품은 배타적인 국내 정책과 국내 고객의 과다한 Customization 요구에 포기하는 경우가 대부분이다. 외국에는 팔 수도 없고 외국제품도 들어오기 어려운 동네잔치인 것이다. 수십년을 정부의 막대한 금전적인 지원 하에 소프트웨어 업계가 그렇게라도 생존할 수 있었다는 것은 다행이다. 글로벌 사용자가 국내 사용자보다 더 많은 국내 소프트웨어 제품은 필자가 오래 동안 컨설팅을 수행했던 소프트웨어 회사만이 유일한 경우인 것이 20년간 관찰한 결과이다.

다시 프로젝트 이슈로 돌아와서 프로젝트관리(PM)는 건설시공과 같이 하드웨어를 만드는 산업에서는 매우 중요하다. 그래서 프로젝트관리시스템(PMS)도 성능 좋은 고가의 제품을 사용한다. 하지만 건설에서도 지식산업인 건물 설계는 PMS와는 아무 관계가 없다. 노동산업인 시공에는 PMS가 필수적이다. 소프트웨어를 지식산업으로 개발한다면 PMS는 거의 필요가 없고 노동산업과 같은 상황이라면 PMS가 중요할 수 있다. 

필자가 실리콘밸리에서 근무했던 회사들은 모두 세계 1, 2위의 글로벌 회사들이었다. 그런데 프로젝트관리가 중요했다는 생각을 해 본 적도 없고 프로젝트 관리자가 누구였고 무슨 일을 했는지 조차도 기억이 나지 않는다. 나의 인사평가에 관련한 적도 없고 뭔가 진척 사항 정도만 가끔 알려주었다는 정도 희미하게 기억난다. Bookkeeping 정도의 역할로만 기억할 뿐이다. 엑셀 정도의 도구만 사용했다. 마이크로소프트의 엑셀 개발팀도 자체 엑셀로 프로젝트관리를 했었다. 즉 프로젝트관리에는 회계의 예를 들면 회사의 전략을 결정하는 회계사(Accountant)의 역할부터 기록만 담당하는 부기담당자(Bookkeeper)의 역할까지 다양한 역할이 있다.

PMS를 도입해서 개발을 잘해보겠다는 회사가 있으면 걱정부터 든다. 얼마나 열악한 환경이면 PMS를 도입해서 관리를 해야 한다는 생각이 들까?  회사가 노동산업 형태로 만들어져 버렸다면 그 때의 유일한 단기 해결책은 노동인력관리이며 그 때는 PMS가 필요할지 모른다.. 하지만 건축 설계사나 모차르트를 관리한다고 좋은 디자인이나 음악이 나올 수는 없다. 관리는 전형적인 노동산업에 필수적인 요소일 뿐이다. 지식산업에서는 관리가 아닌 Bookkeeping하는 도우미 정도의 역할로 충분하다. 노동산업적인 관리를 시작하면 의욕이 떨어지고 직원들은 부품처럼 움직이게 된다. 건설 현장의 인부를 생각하면 된다.

이런 부작용에도 불구하고 소프트웨어 개발에 관리가 필요하다는 것은 그 만큼 열악한 환경에 처했다는 얘기이고 목말라 쓰러져가는 사람에게 소금물 주기와 같다. 물론 소금물을 준다는 사실조차 모르는 상황에서 희망적인 결과를 바라고 시작하겠지만 결과는 명백하다. 열정도 사라져 생산성도 낮은 무기력한 삶이 지속될 뿐이다. 한번 열정을 잃어 버리면 희망이 아주 작게 변한다. 노예들의 희망은 해방되는 것이 아니라 금으로 만든 쇠줄을 가지는 것이라는 속담도 있다. 훌륭한 제품을 만드는 것이 목적이 아니라 안정된 급여만 보장 된다면 편히 살아가는 것으로 목적이 변하게 된다. 그러면 더 관리가 필요하게 된다. 소금물 마시기와 같은 악순환이 계속된다.

눈 앞의 문제를 해결하기 위해 단기적인 관리가 필요함과 동시에 그런 상황이 된 근본적인 원인을 파악하고 해결책을 마련해야 한다. 국내 소프트웨어 업계는 이런 면에서 지금까지 수십 년을 허송세월 했다. 또 다른 부수적인 관리의 목적은 투명성의 문제와도 직결되어 있다. Black Box 속에서 직원들이 무슨 일을 하는지도 모르는 상황에서 회사에 대한 충성도나 프로페셔널로서의 책임감이나 자존심도 없다면 관리는 매우 중요해 진다. 이는 근본적인 프로젝트관리의 목적과는 벗어난 다른 문제이며 이미 희망적인 환경은 아니다. 책임감과 역량이 충분하다면 관리는 알림에 대한 수동적인 Bookkeeping 정도의 관리만으로도 충분하다. 하지만 반대의 경우는 능동적으로 감시와 참견을 해야 하는 세밀하고 많은 관리가 필요하다.

작은 관리가 되었던 큰 관리가 되었던 관리를 하려면 관리할 정확한 항목이 필요하다. 건설 시공현장에서 관리가 가능한 이유는 건물 설계도가 있기 때문이다. 설계도가 없이는 공사 시작도 할 수 없고 인부관리가 불가능하다. 관리의 필수적인 조건은 규모가 크든 작든 관리할 항목이 있어야 한다는 것이다. 관리할 항목도 없는 상태에서 요새는 또 수시로 변하는 상황에 적합한 애자일이라는 방법론을 들고 나올 수 있는데 이는 말장난에 불과하다. 관리와 애자일은 원칙적으로 상충되는 용어이다.

애자일을 관리와 관련하여 간략하게 소개해 보자. 폭포수모델을 본 적도 없는 사람들이 폭포수 모델의 단점 때문에 애자일을 시도해 보겠다는 코미디 같은 일이 벌어지기도 한다. 폭포수모델과 애자일의 논쟁은 소프트웨어가 생겨나면서부터 격렬하게 벌어진 60년의 지속적인 논쟁거리였고 요새 유행하는 Scrum도 적어도 1987년의 논문 혹은 그전에 이미 소개된 오래된 개념이다. 애자일 방법론 중에서 이전에 한때 유행했지만 사라진 것이 Pair Programming으로 유명한 XP 방법론이고 지금 유행하는 것은 Scrum 방법론이다. 애자일이나 DevOps같은 유행이 나라를 구할 수 있다면 다 하겠지만 지금까지 유행이 나라를 구했다는 소리는 들어 본 적이 없다. 반대로 유행이 나라를 망치는 경우는 많다. 

Scrum은 그냥 소수의 팀이 필요에 따라 수행하는 하나의 방법일 뿐이다. 이미 애자일 창시자들도 애자일은 죽었다고 선언한 상황에서 지금 현재 이 순간에 국내에서 유행하고 있다고 하는 것이 정확한 표현이다. 미래에 어떻게 될지는 알 수 없다. 스크럼은 소수의 팀(편의상 최대로 잡아서 10명 이하의 규모라고 해 두자)이 고객의 요구사항이 불확실할 경우에 고려해 볼만한 방법에 불과하다. 비법으로 착각하여 너무 큰 의미를 부여하지 않았으면 좋겠다. 이미 수십년 되는 개념이다. 건물이나 자동차를 애자일로 개발할 수는 없다. 정확한 분석과 설계가 성공의 핵심인 것은 극소규모 개발이 아닌 이상 소프트웨어의 공통점이다. 작은 규모의 개발이라고 해도 최소한도의 분석과 설계가 없이는 어떤 방법론도 사용할 수는 없다.

결국 관리를 하려면 요구사항이든, 스펙이든, 일정이든, 인력이든, 리스크가 되었던 뭔가 시작점이 있어야 한다. 구름 잡는 비전이나 열정만으로 시작해야 할 일이 없다. 인력은 있는데 당장 할 일이 없으니 알아서 사전공부를 하거나 다른 일을 한다. 그래도 뭔가 하고는 있으니 바쁘고 정신 없다고 한다. 다 계획이 없어서 벌어지는 현상이다. 설상가상으로 할 일도 없고 책임감마저도 없다면 어떤 현상이 벌어질지는 명백하다. 

계획 없는 관리는 불가능하다. 폭포수나 애자일이나 정도의 차이는 있지만 마찬가지이다. 필자가 보아온 국내의 현실은 폭포수는 물론이고 스크럼을 수행하기에도 충분하지 않은 분석과 설계를 하는 것이 현실의 상황이다. 템플릿이나 프로세스 흉내는 내지만 질적인 문제에서는 항상 부족하다. 세계적인 프로젝트 관리시스템인 Primavera를 가져다 준 들 관리할 항목이 없이 관리할 수 있는 방법은 없다. 건물 설계도가 없으면 시공을 할 수 없는 것과 동일하다. 시간과 돈만 낭비할 뿐이다.

세계적인 유행 따라 인공지능을 하든 블록체인을 하든 무엇을 해도 잘하고 못하는 것은 관리의 문제는 아니다. 관리는 역량에 따라 적절한 수준으로 맞추면 된다. 실리콘밸리의 글로벌 회사와 같이 되도록이면 관리를 적게 해도 되는 상황이 가장 바람직한 상황이다. 프로젝트 관리를 잘해서 훌륭한 소프트웨어 회사가 되었다는 얘기는 들어본 적이 없다. 이미 잘 안 되는 회사에서 현상유지 하는 정도의 목표가 현실적이다. 진정한 이해도 못하는 폭포수니 애자일이니 하는 용어에 현혹되지 말기 바란다. 기본적으로 분석과 설계를 적절히 한 상태에서는 방법론도 중요하지 않고 관리도 중요하지 않다. 프로젝트관리니 방법론이니 하는 얘기는 이미 회사가 안되기 때문에 생겨난다. 그리고 점점 더 깊은 구렁 속으로 빠지기 쉽다.

소프트웨어 개발이 잘 안 되는 근본 원인은 적절한 분석과 설계의 부족이다. 그런 상태에서는 PMS와 같은 도구는 의미도 없고 백약이 무효다. 개발자의 코딩 역량은 그 후의 문제이다. 천재 개발자들이 겨우 한번 만들었다고 해도 아키텍처가 망가진 상태에서는 미래의 유지보수가 모두를 괴롭히기 시작한다. 전형적인 국내 SI나 제품의 현상이다. 진정한 이해 없이 무조건 PMS를 도입하기 보다는 먼저 무엇이 중요한 가를 진정으로 깨닫는 것이 중요하며 회사에서는 리더들의 전적인 책임이기도 하다. 

국제화 #2 - "소프트웨어 국제화"가 왜 어려운가?

마케팅과 같은 비기술분야 사람들은 여러 나라를 지원하는 기능을 "소프트웨어 글로벌화"라는 추상적인 용어를 사용하지만 그건 비전문가들이 알아듣기 쉬우라고 사용하는 용어이고 이 분야의 기술적인 용어로는 정확하게는 Internationalization(국제화)와 Localization(지역화)라는 고유명사를 사용한다.. Internationalization을 약자로 I18n이라고 하고 Localization을 L10n이라고 한다. 

필자가 소프트웨어 국제화/지역화에 몸을 담게 된 계기는 1990년 초에 Sun Microsystems(지금은 Oracle)의 국제화 부서에서 일하면서였다. Sun의 Unix OS인 Solaris 전체를 국제화한 부서였다. 세밀하게는 국제화와 지역화의 두 단계로 나누어져 있는데 난이도로 말하면 국제화가 지역화의 100배쯤 어렵다. 국제화를 제대로 한다는 것은 전 세계의 언어뿐 아니라 문화까지도 알고 있어야 가능하기 때문이다. 썬마이크로시스템즈, 마이크로소프트, 애플과 같은 미국 회사의 국제화는 항상 미국본사에서 수행하고 각 나라의 지역화 업무는 각 나라의 지사에서 국제화의 결과로 정해진 규칙에 따라 시키는 대로 수행하는 것이다. 즉 한글화를 했다고 해도 국제화를 이해한 것은 아니다. 사실은 국제화를 해 본 적도 없다는 것이 정확한 표현이다. 설계도에 따라 건물을 시공했다고 해서 설계를 이해하는 것은 아닌 것과 같다.

국제화 자체가 방대한 주제인 만큼 국제화의 모든 기술을 설명한다는 것 자체가 많은 시간이 걸리는 일이다. 국제화에 수십 년의 경험을 가진 전문가들이 존재한다. Sun에서 일할 때 같이 Consortium으로 일했던 여러 회사의 동료들이 아직도 Unicode를 포함한 국제화 분야에서 일하고 있기도 하다.

국제화를 하기 위해서는 알아야 하는 다른 나라의 문화들 중 몇 개만 예로 들어 보자.

•       일본어와 중국어 문장에는 빈칸도 없고 마침표 “.” 를 사용하지 않는다

•       “01/02/03” 이 몇 년 몇 월 몇 일을 의미하는가? 나라에 따라 다르다.

•       독일에서 숫자 “12.456,789” 는 무엇인가?

•       프랑스에서 노트북 가격이 “1  199,01  EUR” 라고 적혀 있는데 저렴한 것처럼 보이니 사야 하나?

•       다음과 같은 사람 이름이 있다. 누구인지는 웹에서 검색해 보면 나온다. 성과 이름이 무엇인가?

•       Sheikha Manal bint Mohammed bin Rashid Al Maktoum

•       Victoria Mary Augusta Louise Olga Pauline Claudine Agnes

•       여권에 적힌 이름이 한 단어밖에 없다. “Pal” 이라는 인도 사람인데 성인가 이름인가?

이 예는 다른 나라 문화의 극히 일부분을 보여 주는 것이고 이런 분류체계만 수 백 개의 카테고리가 있다.

국제화를 제대로 한다는 것은 이런 모든 경우들을 나라별, 언어별, 지역별로 제대로 표현되도록 해야 하는 것이다. 국제화를 제대로 하기는 거의 불가능할 만큼 어렵다.

지금 사용하는 언어 코드체계인 Unicode도 전세계 모든 나라의 언어를 포함하는 합집합으로 만들어 놓은 것이다. Microsoft, Sun, Apple등이 회원이었던 Unicode Consortium에서 모든 나라의 언어들을 모아서 최초로 정리하는데도 많은 시간이 걸렸고 몇 십 년이 지난 지금도 계속 진화하고 있을 정도로 국제화는 변화한다.

국제화에 필요한 수 백 개의 분류 항목 중 오래 전에 POSIX와 X/OPEN의 표준이라고 정해 놓은 6개가 있다. 문자타입, 시간형식, 숫자형식, 정열방법, 화폐단위, 메세징 이다. 이 6개가 가장 기본적인 것이긴 하지만 그 외에도 많은 중요한 비표준인 분류가 있고 또 새로 생겨나기도 했다. 결국 국제화를 제대로 하기 위해서는 이런 모든 분류항목을 고려해 보고 어떻게 할 것인지를 결정해야 한다.

눈에 보이는 화면이나 번역했다고 국제화를 한 것이 아니다. 그렇더라도 역시 가장 중요하고 사용자가 즉시 부딪치는 것이 화면에 보이는 것이다. 이를 메세징(Messaging)이라고 한다.  이번 포스트는 국제화에 대한 소개 단계이기 때문에 모든 사람들이 쉽게 이해하는 메세징에 대해 간단한 소개만 한다.

메세징에는 각 나라 언어에 따른 번역이 따른다. 즉 "Open" 이라는 버튼이 있으면 한국에서는 "열기" 로 번역을 해야 한다. 다섯 언어를 제공해야 한다면 다섯 언어로 번역을 해야 한다.  당연히 "Open"이라는 영어 원문과 "열기" 라는 한글 번역본이 어딘가에 존재하게 된다. 통상적으로 각 나라의 "언어팩" 이라고 불리는 패키지에 그 나라 번역결과가 포함되어 있다. 리눅스나 마이크로소프트의 윈도즈를 설치하다 보면 각 나라의 언어팩을 원하는 대로 언제든지 추가 설치할 수 있다는 것을 알 수 있다.

메세징에서 개발자들의 가장 원초적인 생각은 번역 결과물을 소스코드에서 분리하여 관리하겠다는 것이다. 옳은 생각이긴 하나 이런 분리 방식은 50년 이전부터 여러 언어를 지원하기 시작한 최초의 시점부터 실행되어온 방법으로 너무 당연하다. catgets 와 같은 표준 방식이 그들 중 하나이다.

어떤 방법을 사용하든 결국은 "메세지 아이디"(msgid)와 "메세지 번역결과"(msgstr)의 쌍을 포함하는 "메세지 카탈로그"라는 목록을 언어별로 관리해야 한다. 이를 위해서는 순진한 개발자들의 머리에서 고안된 수 많은 방법이 있다. 가장 간단한 세가지 예를 들면 msgid가 영어 원문, 심볼이름, 숫자로 된 경우이다.

·         open=열기

·         1=열기

·         ID_OPEN=열기

여기에 예로 나열한 방법들을 사용하여 메세지를 번역하고 소프트웨어가 제대로 구동되면 국제화가 되었다고 생각할 수 있으나 이는 시작에 불과하다. 이제부터 메세징의 진정한 문제가 시작된다. 특히 소프트웨어가 규모가 커지고 여러 나라를 지원해야 할 필요가 있으면 문제는 기하급수적으로 커진다. 즉 제품이 잘 팔리기 시작하면 문제가 나타나기 시작한다. 소스코드의 변경에 따른 필연적인 msgid의 변경으로 이어져 과거에 번역해 놓은 결과가 수정, 삭제, 추가 되는 과정에서 100개의 언어를 지원해야 한다만 악몽이 시작된다. 아직 이런 악몽을 겪지 않았다면 아직은 소규모의 소프트웨어이다. 글로벌 소프트웨어가 되기 위한 첫 단계에 신고식처럼 큰 장애물이 있는 것이다. 국내에서만 팔겠다면 국제화는 걱정할 필요가 없다. 하지만 아무리 제품전략이 좋고 훌륭한 개발자가 있어도 이 국제화 기술 하나가 잘못 채택되면 글로벌 소프트웨어를 만들 수 없다. 필자의 20년 국내 경험상 국제화 메세징 기술은 국내 소프트웨어 회사가 글로벌 회사에 비해 적어도 20년 이상 뒤떨어진 분야이다. 국제화 교육이 있기도 하지만 그것은 입문자를 위한 소개 코스에 불과하다.

국제화는 구현의 문제가 아니고 구조적인 아키텍처의 문제이다. 적어도 글로벌 소프트웨어가 목표라면 누구나 생각할 수 있는 단순한 방법으로 과연 글로벌 소프트웨어를 만들 수 있을까 하는 의심을 해 보는 것이 좋다. 구체적으로 소프트웨어의 생존주기에 벌어지는 일을 고려하고, 소프트웨어 규모가 커지고, 지원해야 할 언어가 100개로 증가하면 어떻게 할까 하는 전략을 생각해 봐야 한다. 한 번 잘못 시작된 국제화 아키텍처는 제대로 만들기가 어렵다. 거의 모든 소스코드에 영향을 미치는 대규모 수정이기 때문에 시간과 비용이 들 뿐 아니라 현재 진행되던 개발에 영향을 미치는 "브랜치와 머지" 문제가 발생하기 때문에 쉽게 할 수도 없다. 현실적으로 이미 잘못된 메세징 방식은 변경하기가 어렵다. 새로운 버전을 개발할 때 제대로 하는 것이 현실적인 권장 사항이다. 이런 문제를 시행착오 경험으로 배우려면 회사가 잘 되어야 한다. 그런데 그 때 알게 되면 늦는다는 딜레마가 있다. 처음부터 전문가의 조언을 받는 것이 좋다.

국제화 분야의 하나인 메세징도 겉으로는 모든 개발자가 할 수 있을 것처럼 쉬워 보이지만 극히 고도의 전략과 기술이 필요한 전문 분야이다. 처음에 잘못하면 미래의 발전을 꽉 막아버리는 중요한 기술이다. 앞에서 언급했듯이 글로벌 회사의 한국지사에서 수행하는 소프트웨어 지역화는 매우 단순한 개발이나 번역작업이기 때문에 이는 고도의 전문성이 필요한 국제화와는 다르다.

메세징만 해도 깊고 방대한 주제이기 때문에 여기서는 이 정도로 소개하고 글로벌 회사들이 사용하는 방법에 대해 깊이 있게 서서히 소개하기로 한다. 

국제화 #1 - 유럽 개인정보보호법(GDPR)과 글로벌 소프트웨어

GDPR(General Data Protection Regulation)은 EU가 제정한 현존하는 가장 강력한 개인정보보호법이다. 2016년 5월부터 2년간의 유예를 거쳐 2018년 5월25일 발효되었다. 발효 즉시 몇 시간 지나지 않아 페이스북과 구글이 소송을 당했다. GDPR의 벌금액은 상상을 초월한다. 가벼운 위반 사항은 1000만 유로(125억)나 회사매출의 2%, 무거운 위반사항은 2000만유로(250억)나 회사매출의 4%중 큰 금액이 최대 벌금액일만큼 심각한 법이다. 지금까지는 적당히 개인 정보에 대한 법을 무시해 왔다면 지금부터는 장난이 아니다.

지금까지 대부분의 소프트웨어 회사들이 도덕적 해이로 혹은 기술상의 어려움으로 개인정보보호에 소홀히 해온 것이 사실이다. 그래서 개인 정보 DB가 해킹도 당하고 범죄자들에게 이용당하기도 했다. GDPR과 같은 강력한 법령은 당연히 장단점이 있기 마련이다. 불편성과 안전성의 트레이드오프이다. 근래에 웹에 접속할 때 매번 Cache 규정에 대한 응답을 하도록 귀찮게 구는 것이 바로 GDPR의 영향 때문이다. 사용자에게도 불편을 초래하지만 소프트웨어 개발사에게는 엄청난 부담이 된다.

이름이나 전화번호와 같은 개인정보는 물론이고 심지어는 서버에 개인 패스워드까지도 보관했던 과거도 있었다. 잊어버린 패스워드를 이메일로 보내주는 코미디 같은 시절도 오래 전의 얘기가 아니다. 그래서 필자는 조금이라도 위험성이 있거나 엉성한 사이트에는 모든 사람이 알아도 무방한 패스워드를 사용하거나 아예 회원 등록을 하지 않는다. 혹시 암호화 기술을 모르는 독자들을 위해 간단하게 설명하자면 로그인 패스워드는 해시(hash)라는 기술로 원복 불가능한 암호화 방식으로 저장하며 사용자가 입력한 패스워드와 값이 일치하는 지만 확인하여 접속을 허용한다. 이런 방식에서 DB에 패스워드가 직접 저장되지는 않지만 당연히 프로그래머라면 그 과정에서 아주 쉽게 한두 줄의 코딩으로 얼마든지 패스워드를 훔쳐낼 수가 있다. 그래서 필자의 패스워드는 몇 가지 등급으로 나누어 훔쳐가도 무방한 패스워드를 사용하는 사이트도 많다. 특히 중국의 사이트에서 그렇게 한다. 구글과 같은 글로벌 업체들의 경우 적어도 프로그래머가 장난을 치지는 않을 것이라는 믿음을 가지고 사용하는 수 밖에 없다.

가장 중요한 로그인 패스워드마저도 이런 기술의 무지나 의도적인 해킹에 노출되어 있는데 일반적인 개인 정보는 더욱 위험할 수 밖에 없다. 인터넷에 수집되는 정보에는 상상을 초월할 정도로 개인의 사생활 정보가 노출된다. 편리함을 위하여 필수적인 정보들이 수집되기 때문이다. 이런 모든 개인정보들을 보호하기 위한 것이 GDPR이다. GDPR 규정은 너무 방대하기 때문에 전문 컨설팅을 받아야 할 정도로 복잡하고, 조항도 많고, 이해하기도 힘들다. 그 중에는 당연히 입력된 개인정보를 암호화해서 숨기기 위한 Tokenization이나 Pseudonymisation과 같은 암호화 기술도 언급된다. 많은 소프트웨어 제품의 경우에 암호화에 필요한 패스워드를 프로그램에 포함하는 엉터리 암호화 흉내는 무지한 대중을 상대로 홍보용으로 사용되어 오기도 했지만 GDPR에는 당연히 허용될 수 없다. 이제는 더 이상 눈 가리고 아웅하는 식의 가짜 암호화 방식은 사용될 수 없는 상황이 된 것이다. 너무나 당연한 결과이다.

여기서는 GDPR 규정 자체를 설명하는 것은 불가능하고 각자 알아서 연구할 일이지만 GDPR로 인한 전세계 소프트웨어 회사들의 동향을 소개하려고 한다. 먼저 GDPR의 대상이 되는 경우는 EU 국가 중의 국민이 한 명 이라도 개인 정보를 입력하고 저장되는 소프트웨어 패키지나 웹사이트이다. 그러므로 기본적으로 글로벌 소프트웨어라고 말하는 모든 소프트웨어가 대상이 된다.

구글과 페이스북이 2년의 유예기간을 포함하여 수년간 준비를 했음에도 불구하고 발효 즉시 소송을 당할 정도로 준수하기 어렵다. 애플과 아마존도 추가적인 소송대상에서 벗어나지 못했다. 발효 후 1년이 지난 지금까지 10만개 정도의 소송이 생긴 것으로 보고되어 있다. 어떤 소프트웨어 회사들은 아예 EU에서의 접속을 차단하고 사업을 중지하기도 했다. 전세계 행동기반 온라인 광고 유럽 매출이 2018년 5월 25일 발효 즉시 25~40%가 감소했다. 벌금을 내느니 차라리 유럽고객을 차단하는 것이 좋다고 생각했기 때문이다.

GDPR은 이제 발효 후 1년이 지난 태동 단계인 만큼 지금은 거대 기업들부터 순차적으로 고발과 소송이 진행되고 있지만 언젠가는 EU 국가에 사용자가 있는 모든 소프트웨어 회사들이 소송의 대상이 될 것이다. 한 번에 완벽한 준수는 어렵지만 점진적으로 개발해 나가고 있는 것이 현실이다. 작은 회사의 경우일수록 조금 더 시간 여유가 있겠지만 언젠가 자기 차례가 돌아오기 전까지 준비를 해 놓아야 한다. 악의에 찬 고객 한 명이 고발을 할 정도로 쉬우니 피해갈 생각은 하지 않는 것이 좋다.

그런데 국내 회사들의 상황은 어떤가? 전세계에서 난리인 GDPR이라는 용어를 아는 사람도 국내에는 많지 않다. 전세계에 전자제품을 수출하는 대기업들은 이미 준비를 해서 대웅하고 있지만 대부분의 국내 소프트웨어 회사들에게는 GDPR은 관심의 대상이 아니다. 대부분 Active-X 사용, 주민등록 번호, 공인인증서, 은행과의 연계 등 국내인이 아니면 거의 사용 불가능한 국내용 소프트웨어이기 때문이다. 국내 온라인 사이트는 외국인 특히 유럽인을 상대로 사업을 하는 경우가 거의 없다. 이런 상황에서 글로벌 소프트웨어를 추구하겠다는 회사들에게는 GDPR은 생각지도 못했던 큰 짐이다..

GDPR은 소프트웨어 요구사항 분석 과정에서 명시된 소프트웨어 국제화(Internationalization)와 안전성(Security) 요구사항 중의 하나이면서 가장 중요한 항목으로 추가 되었다. 필자가 늘 얘기하듯이 영원히 국내에서만 판매하겠다는 소프트웨어라면 값비싼 국제화나 GDPR을 걱정할 필요가 없다. 하지만 나중에 필요한 때가 되면 국제화 개발이나 GDPR을 준수하겠다는 순진한 생각은 전략도 없이 아무 때나 조그만 기능하나 추가하면 되겠지 라는 큰 착각이다. 그렇게 간단하다면 구글이나 페이스북이 수년간 못했을 리 없다. 소프트웨어의 뼈대라고 하는 아키텍처의 중요성이 국제화와 GDPR 준수의 핵심이다. 아키텍처를 변경한다는 것은 재개발이나 마찬가지일 만큼 방대하고 어렵다. 대부분의 회사는 아키텍처가 중요하다는 인식을 했을 때는 이미 늦었다.

GDPR에 대한 국내 소프트웨어 회사들의 인지도나 관심 혹은 실제 행동여부로 보면 과연 글로벌 진출을 하겠다는 의지나 역량이 있는 것인지 의심이 간다. 그러지 않아도 어려운 소프트웨어의 글로벌화에 거대한 장벽이 하나 더 생긴 것이다. 전세계에서 몇 십 년 동안 연구되어온 소프트웨어 국제화라는 거대한 주제도 국내에서는 개발자들 한두 명의 머리에서 나온 자화자찬의 방식으로 진행해서는 글로벌에서 이미 이삼십 년 전에 버려진 경쟁력 없는 방식의 재현이 되기 쉽다. 자연 진화의 필연적인 시행착오의 결과이다.

필자가 경험한 거의 모든 국내 소프트웨어 회사들은 그런 자연진화론적 방식으로 진행되어 왔다. 이미 글로벌 기술보다 이십 년 이상 뒤떨어진 국제화 방식으로 글로벌 경쟁력이 생기기도 어려운데 GDPR이라는 거대한 장벽까지 생겼으니 소프트웨어의 글로벌 진출이 더 어려워진 것은 엄연한 사실이다. 국내에서만 사업을 하겠다면 이 복잡한 것 필요 없이 마음 편하다. 하지만 “진정으로 깨달았을 때는 관속에 들어가기 하루 전”이라는 속담도 있지만 글로벌화를 주장한다면 이제부터라도 과연 소프트웨어 글로벌화가 무엇인지 혹은 구체적으로 수십 개의 국가나 언어를 지원하기 위해 지금 충분한 아키텍처가 고려되어 있는지에 대한 심각한 고찰이 필요할 때다.

분석 #10. 잘못된 국내 Outsourcing 계약 방식과 글로벌 계약 방식

이 기사는 일전에 게재한 기사인 “분할발주의 허구와 진실” 과 바로 앞 기사인 베트남의 Outsourcing 회사에 관한 기사와 연관되어 있다. 국내 개발 Outsourcing 생태계의 도전적인 숙제이자 염원이기도 한 “분할 발주”도 하고 싶고 글로벌 고객을 상대로 개발 Outsourcing 비지니스도 하고 싶겠지만 열정과 의지만으로 되는 것은 아니고 그를 수행할 수 있는 기본 역량부터 있고 다양한 고객을 상대할 수 있는 경험도 있어야 한다.

대부분의 국내 회사는 거의 미신과 같은 국내의 기존 관행에 몇십년을 젖어 있었기 때문에 우물안 개구리의 문제점을 눈치 채기도 어렵다. 이 기사를 읽어도 눈치 챌 수 있는 사람은 극히 소수일 것이다. 꿈속에서 사는 삶이 있고 현실의 삶이 따로 있는데 이런 추상적인 문제에서는 계속 꿈속에서 사는 것이 통상적이다. 영화 매트릭스에서 얘기한 빨간 약을 먹으면 계속 행복한 환상의 세계에서 살고 파란 약을 먹으면 고통스러운 진실과 마주한다는 것과 같다. 현실에서는 진실을 모르는 것이 더 좋은 경우가 더 많다. 어느 쪽을 택할 지는 순전한 각자의 선택이다.

먼저 소프트웨어 외주 개발 계약의 방식부터 간단히 살펴보자. 필자의 저서와 블로그에서 여러 번 언급했듯이 계약에는 Time and Material(T&M)과 Turn-key 의 두 가지 방식이 있다.

T&M은 인력의 노동시간(Time)으로 비용을 지불하는 방식이다. 발주자나 인력 업체나 간단하다. 인력을 어떻게 사용할지는 발주자가 알아서 관리한다. 계약한 숫자의 인력만 제대로 공급해주면 법적인 소송의 여지도 없다. 주로 개발 앞쪽의 분석 단계에서 사용된다. 산출물에 대한 객관적인 기준을 정할 수 없는 경우에는 T&M 방식이 가장 좋다. 정확하게 말하면 인력의 시간외에 실제 들어가는 장비나 물품((Material)이 포함한다.

반면에 Turn-key 방식은 서로 약속한 제품을 미리 정해진 가격(Fixed Price)과 일정에 개발해 주기로 하는 것이다. 즉 한 사람이 개발하건 10명이 개발해 주건 상관할 필요가 없다. 예를 들어 책상을 주문했는데 몇 명이 만들 건 상관이 없다. 원하는 제품을 만들어 주면 되는 것이다. 자동차를 주문해도 마찬가지이다. 몇 명이 만들었는지도 모르고 알 필요도 없다. 그런 자유가 있는 반면에 책임도 크다. Turn-key 방식은 약속한 물품을 제 일정에 배달하지 못하면 당연히 피해 보상등 법적 소송의 문제가 발생한다.

소송에서 시시비비를 판단하려면 제품에 대한 정확한 스펙(SRS)이 있어야만 가능하다. 정확한 스펙을 작성하는 것이 얼마나 어려운 지는 그 동안 필자가 누누히 설명했다. 정밀도의 문제와 같다. 1센티를 따지는 스펙과 1밀리미터를 따지는 스펙은 양과 질에서 차이가 난다. 소프트웨어도 홈페이지 만드는 정밀도와 금융 소프트웨어를 만드는 정밀도가 다르다. 간단한 홈페이지 프로젝트는 적당한 계약에 애자일 방법론도 좋고 주먹구구식으로 개발해도 큰 문제가 없다. 문제가 있으면 별 피해 없이 고치면 된다. 금융 소프트웨어는 1분만 다운되어도 피해보상 소송이 빗발치니 처음부터 문제 없도록 개발해야 한다.

스펙에 대해서는 여러 곳에서 충분히 설명했기 때문에 여기서 생략하고 Turn-Key 계약에 스펙보다 더 핵심인 인수테스트(Acceptance Test Plan, ATP)를 추가로 소개한다. 회사마다 용어가 약간 다를 수 있으나 가장 혼란 없이 이해하는 용어인 ATP를 사용하기로 한다.

위에서 말한 T&M 방식의 계약에는 인력 공급 내용만 있지 산출물은 정해지지 않았기 때문에 검증할 인수 조건이 없다. 쉽게 말해 일당으로 비용이 계산되는 일용직 고급 근로자라고 보면 적절하다. 통상적으로 분석이나 설계 작업과 같이 하루에 수천불 가격인 매우 비싼 직업이다. 개발의 첫 단계에서는 계약에 명시할 스펙도 없고 인수 조건도 나올 수 없다. 이런 비싼 고급 전문가를 잘 사용하고 관리하는 것은 전적으로 발주자의 역할이다. 전문성이 높은 분석가나 아키텍트인 만큼 대부분은 발주자를 리드하고 주도해서 일을 할 수 있는 능력이 있다. 그런 능력 때문에 비싼 값을 지불한다.

Turn-Key 방식의 핵심이 스펙이라고 이전에 필자가 계속 말해 왔는데 일부만 사실이다. 진짜 핵심은 인수조건이다. 인수테스트로 대표되는 인수조건이 핵심이다. 하지만 인수테스트만 가지고는 개발을 할 수 없기 때문에 개발할 내용을 설명하는 스펙이 필요한 것이지 법적인 상황에서는 스펙보다는 ATP로 시비를 가린다. 근본적으로 ATP를 통과하면 계약은 종료된 것이고 ATP 중에 하나라도 실패하면 계약이 종료되지 않은 것이다. 개발사가 폭포수 모델로 개발하건, 애자일방식으로 개발하건 반복적모델로 개발하건 상관이 없다. 100개가 넘는 시중의 개발방법론, 또 수만개는 되는 다양한 종류의 템플릿 중에 어떤 것을 사용하건 상관할 필요가 없다. 그냥 약속한 일정에 ATP를 통과한 물품을 배달하기만 하면 된다. 이상적인 상황이라면 중간에 서로 대화를 할 필요도 없다. 배달 날자까지 기다렸다가 인수를 하든지 피해보상 소송을 하든지 둘 중의 하나이다. 이 부분은 명백한 흑백논리가 적용된다. 예를 들어 ATP에 포함된 10,000개의 테스트 케이스 중에서 1개라도 실패하면 실패한 것이다.

Turn-key 계약의 인수조건은 아주 명백하지만 아무나 이렇게 하기 어려운 두가지 이유가 있다. ATP에 포함되는 테스트 케이스를 만들기 어렵다. 국내에서 ATP를 이용해서 계약을 한 회사는 필자는 본 적이 없다. 대부분은 엉성한 스펙만으로도 몇 백억짜리 프로젝트도 계약 한다. 성공하면 기적이다.

누가 테스트 하느냐에 따라서 ATP에 들어가는 테스트 케이스의 개수는 10배도 더 차이가 난다. 회사의 내부에서 제품도 잘 알고 늘 테스트 해 오던 사람들이 하는 경우와 외부의 인력이 테스트 할 경우에 테스트 케이스의 숫자가 10배 정도의 차이가 날 수 있다. 전혀 모르는 사람에게 스펙을 적어 줄 때도 마찬가지이다. 내부 인력이라면 10 페이지 적으면 되는 양을 외주 계약을 위해서는 100 페이지를 적어야 하는 경우가 전혀 이상한 것이 아니다. 필자에게 “스펙이나 ATP를 얼마나 자세히 적어야 됩니까?” 라는 질문을 많이 하는데 고객과 상황에 따라 다르다는 답 밖에 없다. 이런 상황에 따른 유연성이 진정한 소프트웨어 공학의 영역이다. 건강에 좋은 음식이 사람에 따라 다른 것과 마찬가지이다. 만약 누가 정형화된 답을 준다면 그것은 이론이며 가짜 소프트웨어 공학인 것이다.

우여 곡절 끝에 많은 시간을 들여서 외부 사람들을 위한 방대한 ATP 테스트 케이스를 작성했다고 가정하자. 그렇다고 개발업체만 믿고 계약 마지막 날에 완성이 될 것이라고 기다리기에는 불안하다. 100만원에 1주일짜리 프로젝트라면 그렇게 해도 괜찮겠지만 100억에 1년 걸리는 프로젝트를 하는데 그렇게 할 수는 없다. 그래서 ATP는 완료 평가의 척도는 되지만 중간에 개발이 제대로 진행되는지 확인하기 위해서는 다른 방법이 필요하다. 그래서 Design Review, Integration Test, 몇 번의 Iteration등 중간 중간에 진행 상황을 검증할 수 있어야 한다. 물론 여기에서도 몇 명이 개발하는지는 중요하지 않다. 천재 1명이 개발하든 초급개발자 100명이 개발하든 그건 개발업체의 선택이다.

정확한 스펙과 ATP도 없이 수행하는 Turn-key 계약은 근본적으로 거대한 위험성을 내포하고 있다. 성공할 가능성은 없다고 보면 된다. 나중에 그냥 서로 눈감고 대충 넘어가거나 소송으로 가거나 둘 중의 하나이다. 거대한 제품을 개발했는데 인수를 거절해서 소송이 벌어진 경우도 있다. 정확한 스펙과 ATP 없이 계약하려고 하니까 뭔가 안전장치를 만들어야 하고 담당자는 책임도 회피해야 하니 투입할 인력을 명시하게 된다. 더군다나 발주자가 확인할 수 있는 장소에 상주하도록 요구한다. 그러다 보니 Turn-key 계약에 액수, 일정, 인력까지 명시하는 것이다. 상식적으로 말이 안되지만 담당자가 책임을 회피하기 위해서는 가장 쉬운 방법이 인력이다. 그러니 원래 어려운 원격 개발은 이래저래 더 어렵다.

그래서 T&M 방식도 아니고 Turn-key 방식도 아닌 비상식적인 계약이 그동안 국내에서 멀쩡하게 사용되어 왔다. 그럴 수 밖에 없는 근본적인 원인은 스펙의 부정확성, ATP의 부족이나 부재, 그리고 중간에 Monitoring 할 수 있는 역량이 부족하기 때문이다. 국내에서는 이런 식의 계약에도 거부감을 느끼지 못하겠지만 이런 비상식적인 계약은 소프트웨어 선진국의 정상적인 상황에서는 존재할 수 없다. 발주자인 갑의 역량부족으로 인해서 생긴 계약의 횡포일 뿐이다. 이 모든 문제를 해결하려면 ATP를 작성할 수 있는 역량이 있어야 하는데 ATP를 만들기 위해서는 정확한 스펙이 있다는 가정하에서만 가능하다.

진정한 Turn-key로 계약하고 관리할 수 없는 회사에서 과연 훌륭한 소프트웨어를 만들어 낼 수 있을까? 없다고 생각한다. 전략 없는 숙련공들의 혼란스러운 개발이 될 수 밖에 없다. 스펙을 개발 도중에 변경하는 일도 빈번하고 따라서 회의나 번잡스러운 일이 많아지고 관리비용이 엄청나게 추가된다. 개발보다는 관리에 더 집중하기 쉽다. 그래서 관리를 잘해 보겠다고 또 새로운 시스템을 도입하거나 PMO니 하는 얘기가 나오는데 방향을 잘못 잡는 것이다. 합리화 하기 위한 방법으로 실리콘밸리의 영웅담 같은 얘기는 꼭 인용한다. 악순환이 계속된다. 대부분의 문제는 관리로 해결될 수 있는 문제가 아니기 때문이다. 좌절한 개발자가 중간에 사라지는 것도 늘 보는 현상이고 납기 지연은 너무 당연하다. 종종 나오는 뉴스가 알만한 큰 프로젝트들이 지연되었다는 기사이다.

국내는 인간 관계로 적당히 실패를 덮어 버릴 수 있다. 그러나 그럴 수 없는 국제간의 심각한 계약을 한다고 생각해 보면 ATP를 작성할 수 있는 역량이 없으면 T&M 방식으로 계약하는 방법 밖에 없다. 글로벌 회사에서는 발주자나 개발업체나 둘 다 엉성한 Turn-key 계약은 할 수 있는 근거도 없고 그런 위험하고 무책임한 계약은 하지도 않는다.

거의 모든 국내 소프트웨어 관련 소송은 이 부류에 속한다. 소송 당사자들은 국내 관행대로 했는데 왜 소송을 당했는지를 이해하지 못한다. ATP와 같은 객관적인 평가 기준이 없으니 자신들 유리한 대로 해석하고 서로 상대방만 비난한다. 개발업체는 몰상식한 악덕 발주자를 만나서 억울하다고 하고 발주자는 회사에 손해를 끼친 엉터리 개발업체라고 분에 차있다. 처음부터 사기를 치려고 하지 않았다면 대부분의 경우 둘 다 50% 씩 잘못이다. 이 모두 ATP만 있었다면 소송에 갈 필요도 없다.

분할 발주, 원격 개발, 탄력있는 근무 시간등 아주 듣기 좋은 말들이다. 정부가 강제로 계약에 관련된 이런 정책을 법제화 하려고 하는 것은 좋지만 생태계가 준비되지 않은 상태에서는 더 큰 문제를 불러 올 수 있다. 근본적인 이해 없이 눈 앞의 증상만을 치료해 보고자 하는 단세포적인 정책은 또 다른 문제를 불러온다. 극히 조심해야 한다.

스펙이나 ATP 작성 역량은 계약을 위한 역량뿐은 아니고 소프트웨어를 제대로 개발하기 위해 꼭 필요한 역량이다. 이런 기초 체력 없이 소프트웨어 강국이 되려는 생각은 허황된 망상에 불과하다. 그냥 국내에서 국내 고객을 위해 국내용 소프트웨어를 개발하는 정도로 만족해야 한다. 그것도 하나의 훌륭한 성공이다. 많은 시간과 경험이 필요한 이런 역량을 교육으로 해결하겠다는 생각을 하는 사람들도 많이 봤는데 태권도를 이론 교육으로 가르치려는 것과 같다. 이는 학교에서는 절대 가르칠 수 없는 현실의 문제이고 바로 진정한 소프트웨어 공학 역량이다.