소프트웨어 개발 비용은 ‘돈’ 보다는 ‘시간’의 의미가 더 크다. 개발 비용은 크게 보면 다음 세 가지로 구분할 수 있다.

1. 도입 비용
2. 수정 비용
3. 소유 비용

각 비용을 적절히 배분해야 전체 비용이 줄어든다. 가령, 성공을 확신할 수 없는 새 제품이나 서비스를 개발하는데, 오버 엔지니어링해서 많은 도입 비용을 쓰는 사례를 들 수 있다. 또는 도입 비용을 너무 싸게 예측해서 급히 개발했는데, 시장 반응이 좋은 상황이다. 분명 개발의 훌륭함보다는 아이템의 승리다. 수정해야하는데, 팀의 빨리빨리 문화에 회의를 느낀 초기 개발자는 회사를 떠났고, 스파게티 코드만 남아 누구도 손댈 수 없는 사례도 생각해 볼 수 있다. 내 일천한 경험에 비추어 보면 이런 코드로 램프 업한 사업은 곧 망하더라(대규모 투자를 받아 팀을 리빌드한 경우는 제외).

1. 도입 비용

최초 코드를 작성하고 테스트하는 비용(시간)이다.

이하 말하는 테스트를 꼭 자동화된 테스트로 오해하면 안된다. 코드를 짜고 브라우저를 켜서 링크를 클릭하고, 폼을 전송해서 스펙대로 동작하는지 확인하는 수동 테스트도 테스트다. 자동화가 불가능한 제품이나 서비스가 있어, 코드를 수정하면 사람이 직접 제품을 들고 나가서 실 환경에서 테스트를 해야 할 수도 있다. 테스트 절차 또는 테스트 문화라고 표현하는 것이 더 맞는 말인 것 같다. 바로 최근 4 년을 몸 담았던 직장이 이랬다. 스마트폰에서 Lte와 Wi-Fi를 효율적으로 쓰는 솔루션이라 실환경에서 나가야 했다. 또, 소프트웨어는 아닌데, 그 전에 5년을 일했던 직장에서는 45nm ARM CortexA8 Applications Processor 프로젝트를 진행한 적이 있다. 개발비 100억, 개발 기간 2년, 타이밍 버그 하나에 리비전 비용 20억이 그냥 훅 간다. 후자는 하드웨어이고 비용이 워낙 커서 전담 조직이 있었지만, 전자는 언제든 고치면 되는 소프트웨어라 전 직원이 출퇴근하며 테스트를 했던 기억이 있다. 어쨌든 테스트는 그런 의미다.

취미로 만들어 혼자 쓰는 소프트웨어가 아니라면, 사업적인 요구에 의해 발생하는 비용이므로, 도입 비용은 예산으로 이미 할당되어 있다. 개발팀이 제시한 개발 계획이 6개월이라면 전 회사가 목을 빼며 6개월을 기다려 준다. 개발 결과물은 사업적인 가치로 바로 환전된다. 기존 제품이나 서비스에 기능 추가라면, 해당 기능 추가로 발생할 부가적인 수입을 기대할 것이다. 새 제품이라면 성공적인 개발과 런칭에 뒤 따르는 경제적 이득 또는 가치의 상승을 기대할 것이다.

한 가지 경계해야 할 점이 있다. 초초기 MVP(minimum viable product)가 아니라면, 수정 비용을 어느 정도는 고려하고 개발해야 한다. 유지 보수 편리성 말이다. 노련한 개발자는 프로젝트를 수행하는 과정에서 수집한 여러 가지 정보를 종합하고, 경험과 직관에 따라, 곧 뒤 따라올 수정을 어느 정도 예측한다. 어느 수준까지? SOLID, TDD? 모르겠다. 경험에 따르면 노련한 개발자는 끊임 없이 프로젝트의 관련 팀들과 소통하고, 주어진(조율된) 시간에 맞추어 그 수준을 자율적으로 조절하더라. 그들은 프로젝트가 끝나면 내 몰라라 도망칠 생각을 하는 것이 아니라, 자신이 짠 코드에 대한 책임을 지는 장인 정신을 보였다.

이 단계에서의 비용 절감은 쉽다. 가령, 웹 서비스 개발할 때, 날 코딩 대신 웹 프레임워크를 도입하면 벌써 엄청난 시간을 절약하는 것이다. 디자이너 고용 대신 테마를 사서 쓰고, SE 고용 대신 AWS를 사용하는 것 등도 예로 들 수 있다(이미 사내에 디자이너나 SE와 서버가 있는 큰 조직이라면 얘기는 다르다). 손이 빠른 개발자를 여럿 만났다. 손이 빠르다는 의미는 타이핑이 빠르다는 뜻이 아니다. 현재 기술이 흐름을 잘 파악하고 있어서 현재 요구사항에 맞는 ‘적정’ 기술 요소를 쏙쏙 결정하더라는 것이다.

2. 수정 비용

코드를 수정하고 테스트하는 비용이다. 버그 수정, 고객의 요구사항 변화에 따른 로직 수정, 시장 환경 변화에 따른 필연적 코드 수정 등을 예로 들 수 있다. 수정 비용도 사업적인 가치와 직결된다. 오류를 빨리 고치지 못하거나, 고객의 요구사항을 빨리 반영하지 못하면 고객은 금방 떠나기 때문이다. 수정 실패는 이런 결과를 초래한다.

범죄학자인 James Q. Wilson 과 George L. Kelling 은 1982 년 3월 “월간 애틀랜틱”에 ‘깨진 유리창’이라는 제목의 글을 발표했다. 그들의 ‘깨진 유리창’ 이론은 형사행정학 뿐 아니라 경영학 분야에서도 큰 호응을 얻었다.

이 이론은 깨진 유리창 처럼 사소한 것들이 사람들에게 중요한 메시지를 전달한다고 강조한다. 건물 주인이 깨진 유리창에 관심을 기울이지 않고 방치하고 있다면, 그는 절도나 문서 훼손, 폭력 등과 같은 강력범죄에 대한 대비 역시 미비할 것이다. 지나가는 사람들은 깨진 유리창을 보며 건물 주인과 주민들이 이 건물을 포기했으며, 이곳은 무법천지라는 ‘인식’을 하게 된다. 깨진 유리창이 전하는 메시지는 이런 것이다.

비즈니스 세계에 있는 당신, 이제 새로운 계산법을 익혀야 한다. 100-1=99 가 아니라 0 이다. 사소한 실수 하나가 전체를 무너뜨리기 때문이다. 그러나 깨진 유리창을 예방하고 수리할 수 있다면 100+1=200 도 가능해 진다.

그런데, 개발팀은 ‘이거 고치는데 얼마나 걸려?’ 라는 사업팀(또는 사장님)의 질문에 끊임 없이 답해야 한다. 도입 비용과 달리 코드의 양이 증가하는 절대적인 시간이 필요한 것이 아니다. 심리적인 시간이 필요하다. 개발팀은 혹시 모를 사이드 이펙트에 대한 두려움 때문에 시간을 늘려서 대답하기 마련이고, 사업팀은 어떻게 해서든 그 시간의 정당성을 입증하려고 한다(양쪽을 다 경험한 사람으로서, 이런 회의에 임할 때마다 기분이 묘해진다). 그 뿐이랴? 사업팀들 간에 개발팀을 놓고 경쟁을 벌이기도 한다.

그런데 이건 꼭 기억하자. 일 주일 걸리는 일을 한 달 걸린다고 고집 부리거나, 한 달은 되야 할 수 있는 일을 일 주일에 하라고 강요한다면, 다 같이 죽자는 얘기다. 무능한 개발자와 무식한 기획자가 모인 집단의 말로(末路)는 뻔하다.

도입 비용과 달리 수정 비용을 절감하는 것은 쉽지 않다. 쉬운 것 부터… 사이드 이펙트의 두려움이 있다면, 우선 깃 버전 관리를 도입하라 권하고 싶다(이미 쓰고 있겠지?). 경험적으로 가장 큰 비용은 소통 비용이었다. 무조건 써야 한다. 변경 요청 내용을 문서로 받거나, 사업팀/사장님/기획팀이 문서로 기술할 수 없다면 개발팀에서 문서로 기록하고 요청자와 내용의 정확성에 대해 합의하는 과정 말이다. 모두가 사는 길이고, 멀리 보면 엄청난 비용을 절감하는 방법이다. 개발팀이 왜? 라고 질문하지 마라. 스스로 무덤을 파지 마라~

3. 소유 비용

리팩터링하고 테스트하는 비용이다. 리팩터링이란 입력과 출력은 변경하지 않으면서 내부의 로직을 더 구조화하는 작업이다. 이후 수정 요청이 발생하면 더 효율적, 효과적으로 대응하기 위함이다.

소유한다는 의미는 코드 변경에 대한 두려움이 없다는 의미이고, 두려움을 버리는 가장 쉽고도 어려운 방법은 테스트 코드(자동화, 테스트 절차)를 소유하는 것이다. 한번이 어렵다. 두번은 쉽다. 남이 짠 라이브러리의 코드를 소유할 필요는 없다. 내가 짠, 팀이 짠 코드만 소유하면 된다(고백하자면 남이 짠 코드가 의심스러워 디버그 포인트를 심은 적은 있다).

다른 나라에서 일해 본 적이 없어서, 국외 상황은 모르겠다. 문제는 소프트웨어 개발에서 소유 비용은 사업적 가치와 아무런 관련이 없다는 점이다. 어쩌면 그래서 다른 단계에서 발생하는 비용에 이 비용을 슬쩍 끼워 넣으려고 하는 것일 수도 있다. 대표이사, 임원, 개발팀장 등 회사를 대표하는 분들이 소유 비용을 절대 간과하지 말았으면 좋겠다.

4. 결론

결론은 각자… (썼다가 지웠다).