나쁜 프로그래머가 되는 18가지 방법

소프트웨어 개발자는 끊임없이 변화하면서 성장한다. 스스로 길을 잘 찾아서 성장하는 경우도 있고, 좋은 환경에서 개발을 하다 보니 자연스럽게 실력이 향상되기도 한다. 하지만 열악한 환경에서 열심히 일만하다가 개발자로서의 실력은 점점 잃어가는 경우도 있다. 아무리 사회가 어떻고, 회사가 열악하다고 불평을 해봤자 남는 것은 자신의 개발자로서의 실력밖에 없다. 

이번 글에서 나쁜 프로그래머가되는 18가지 방법을 소개한다. 물론 본의 아니게 주변의 환경이 나를 이렇게내모는 경우도 있지만 이를 반대로 해보는 노력을 해보자. 내가 대단한 사람이라서 이런 얘기를 하는 것은 결코 아니다. 나도 독자들과 똑같은 개발자로서 18가지 중에서 잘 안되는 항목도 있다. 단지 20년 넘게 개발을 하면서 느끼는 바를 공유하고자 함이다. 

1. 익숙한 기술만 고집한다
대부분의 사람들은 변화를 싫어한다. 익숙한 것을 사용할 때 업무의 효율도 높다. 하지만 지식노동자인 개발자는 익숙한 기술만 고집한다면 한계에 다다른다. 물론 환경이 그렇게 만들기도 하고, 다른 분야의 기술을 익힐 만한 시간과 여유가 없는 경우도 많다. 그러다 보면 새로운 기술이 필요한 상황에서도 익숙한 기술을 고집하는 고집쟁이가 되기도한다. 

2. 공유를위해 노력하지 않는다
현재 내가 하고 있는 일은 나만 안다. 내가 퇴사하면 당장 이 일은 마비된다. 지금은 내가 하는 일에 다들 관심들이 별로 없지만 내가 없는 빈자리는 매우 클 것이다. 내 업무에 관련된 지식의 90%는 내 머리속에 있다. 주변의 다른 개발자들도 비슷한 상황인데 굳이 내가 깃발들고 공유를 위해 나설 필요가 있을까?  

3. 후배에게 시키지 않고 직접 처리하는 것이 속편하다
후배들이 많이 있지만 실력도 부족하고 일을 시키면 답답하다. 내가 하면 한시간이면 할 수 있는 일을 신입사원을 시키면 하루종일해도 못끝낼 뿐만 아니라 신입사원이 해놓은 것을 검토하고 고치고 가르치는데 몇시간이 소모된다. 그러니 차라리 내가 빨리 끝내버리는 것이 낫다. 그래서 우리 회사는 신입 개발자보다 고참 개발자가 훨씬 바쁘다. 

4. 후배나 동료들이 작성한 소스코드를 봐주지 않는다
회사에서 코드리뷰를 하라고는 하는데, 내 할 일이 바빠서 다른 사람 코드를 봐줄 시간이 없다. 나 뿐만 아니라 다들 이런 상황이다 보니 코드리뷰는 유야무야되었다. 과거에도 코드리뷰를 몇번해 봤지만 바쁜 와중에 잠깐시간내서 봐주기는 했는데 제대로 봐주지도 못했다. 그냥 코딩 스타일을 가지고 트집을 잡는 정도다. 그러다보니 이제 코드리뷰는 모두들 꺼려 한다. 

5. 남이 내 코드를 보는 것을 꺼려 한다 리뷰가 활성화된 조직에서는 지위고하를 막론하고 소스코드를 리뷰한다. 고참의 소스코드를 신입사원이 리뷰하고 지적할 수도 있다. 이런 거북함이 싫고, 귀찮고, 바쁘다. 내가 작성한 코드는 충분히 정상동작하는데굳이 다른 사람이 내 코드를 보고 지적을할 필요가 있을까? 개발할 시간도 부족하다. 

6. 문서화를 꺼려한다
문서작성은 무조건 싫다. 귀찮기도하고 잘 작성하지도 못한다. 하지만 회사에서 꼭 문서를 만들고 개발을 하라고는 한다. 그러면서 개발시간은 턱없이 부족하게 준다. 그래서 문서는 개발 다 끝나고 형식적으로 문서를 만든다. 한달동안 개발하고 나면 문서는 하룻밤 세워서 대충 문서를 만든다. 물론 이렇게 만든 문서를 나중에는 보지도 않는다. 

7. 커뮤니케이션 스킬 향상에 관심이 없다 
개발자는 프로그래밍을 잘하면 되지 커뮤니케이션 스킬은 별로 중요하지 않다고 생각한다. 개발자가 아닌 다른 사람들은 기술에 대해 잘 이해하지 못해서 기술에 대한 대화를 하기가 어렵다. 설명을 해도 잘 이해 하지 못한다. 난 컴퓨터와의 커뮤니케이션은 잘 되는 것 같다.

8. 책임지고 자신의 일을 마무리하지 않는다. 벌려만 놓는다
나는 개발을 엄청나게 빠르게 한다. 남들이 일주일 걸려서 하는 일도 나는 하루, 이틀이면 해치운다. 대신 완성도는 좀 떨어진다. 동작하도록 만드는 것은 나의 일이지만 귀찮은 버그를 잡는 일은 후배들을 시킨다.나는 새로운 일을 좋아하지 버그 잡는 것은 싫다. 

9. 소스코드가 주석 하나 없이 깨끗하다
항상 주석 같이 읽기 쉬운 소스코드를 주장하면 주석 하나 없이 깨끗하게 코딩을 한다. 하지만 후배들은 주석이 없으면 이해하기 어렵다고 불평이다. 하지만 프로젝트 일정이 항상 너무 촉박해서 소스코드에 주석을적을 시간이 없다. 

10. 소스코드가 읽기 난해하다
내 소스코드는 정상동작하지만 읽기는 어렵다. 워낙 바빠서 소스코드를 읽기 쉽게 정리할 수가 없다. 한 파일이 너무 크기도 하고 함수 이름도 난해하다. 내 소스코드는 최적화가 많이 되어서 짧은 코드로 어려운 로직을 기가 막히게 처리한다. 내 소스코드를 분석해 본 사람은 감탄을 할 것이다. 

11. 낮에는 집중해서 일하지 않고 주로 밤에만 일한다
회사가 낮에는 집중해서 개발할 수 없는 환경이다. 회의도 많고 시끄럽다. 그래서 밤에만 일을 하다 보니, 낮에는 여건이 되도 개발이 잘 안 된다. 밤에만 일하는 것이 완전히 습관이 되었다. 밤에 개발하는 것이 썩나쁘지는 않지만 나이를 먹어 갈수록 내 생활이 없어지는 것 같아서 걱정이다. 

12. 소프트웨어 공학에는 관심이 없다 
오로지 코딩, 코딩, 코딩만 잘하면 된다. 알고리즘, 알고리즘, 알고리즘은 관심이 많다. 소프트웨어공학이란말은 많이 들어 봤지만 이게 뭔지 설명하라고 하면 애매하다. 

13. 영어는 잘못하지만 공부할 시간은 없다 
원래 영어는 잘못했고 당장 영어공부를 따로 하지 않아도 개발을 하는데 큰 문제는 없다. 가끔 인터넷에서개발 관련 검색을 할 때는 주로 한글사이트만 검색한다. 스택오버플로우(Stack overflow)도 영어로 되어 있어서 잘 안 본다. 외국 소프트웨어 회사에 취업을 하고 싶어도 영어 때문에 포기했다. 

14. 기초, 원리는 잘 모르고 응용만 하려고 한다
시스템의 원리나 깊은 지식은 잘 모른다. 필요한 알고리즘이 있어도 원리는 잘 모르지만 인터넷에서 다운받아 그냥 사용하는 데는 큰 지장이 없다. 바빠서 따로 공부할 시간은 없다. 학교 다닐 때 전공수업 공부 열심히 할 걸 그랬다. 

15. 카피&패이스트(Copy & Paste)는 나의 무기 
소스코드 복사하는 것이 일상이다. 다른 프로젝트에 비슷한 기능이 있으면 복사해서 사용한다. 공통모듈을만들려면 여러 사람하고 얘기하고 조율을 해야 하는데 시간도 없고 내가 깃발들고 나서기는 싫다. 복사가 훨씬 빠르다. 소스코드를 복사해서 써도 지적하는 사람이 없다. 

16. 수학을 못한다. 관심도 별로 없다 
학교다닐 때부터 수학은 관심이 없었다. 잘 하지도 못한다. 소프트웨어를 개발하는데 수학이 왜 필요한가? 코딩만 잘하면 되지. 어려운 알고리즘은 인터넷을 조금만 뒤지면 라이브러리가 다 있다. 

17. 변변한 취미가 하나도 없다 
지난번 건강검진에서 의사가 술을 줄이고 운동을 하라고 했지만 매일 야근에 운동은 꿈도 못꾼다. 그나마 가끔 시간이 날 때 친구, 동료들과 술을 마시는 것이 유일한 낙이다. 숙취 때문에 다음날 일은 망친다. 

18. 개발밖에 모른다
회사가 어떻게 돌아가는지 잘모른다. 회사의 전략이나 경영 상황은 잘 모른다. 그런데 관심을 가질 시간이 별로 없다. 나는 회사일 신경 안 쓰고 내가 좋아하는 개발이나 평생하면 좋겠다. 

나는 소프트웨어 개발자는 참 좋은 직업이라고 생각한다. 물론 본인이 일 자체를 즐긴다면 정말 좋다. 말들도 많지만 대우도 그리 나쁘지 않고 성취도도 높다. 하지만 열악한 환경에서 일하는 수많은 개발자들은 그렇게 느끼지 못하고 있다. 물론 좋은 환경에서 일한다면 만족도도 높아지겠지만 개발자가 오랫동안 즐겁게일하는데 제일 중요한 것은 본인 스스로의 실력이다. 나쁜 개발자가 되는 방법을 한가지씩 지워가면서 좋은 개발자가 되는 노력을 해보자.

이 글은 ZDNet Korea에 기고한 글입니다.

여자 개발자가 희망이다

소프트웨어 회사를 포함해서 많은 기업들이 개발자가 부족하다고 아우성이다. 이렇게 개발자가 부족하게 된 이유는 열악한 개발 환경에 따른 뛰어난 개발자들의 이탈과 저급개발자 양산 등 여러 환경, 정책적인 문제가 있지만 여자 개발자에 대한 편견과 차별도 주요한 이유라고 본다. 

여자 개발자에 대하여 여러 가지 편견이 있다. 여자 개발자는 실력이 없다, 책임감이 부족하다, 감정적이다, 언제 그만둘지 모른다는 등이다. 하지만 이러한 편견은 남성 중심적인 사고에 기인한 것이 많고, 그 동안의 개발 환경이 야근강요, 코딩 중심, 무모한 프로젝트와 같은 성격을 띄는 경우가 대부분이어서 전투력 강한 개발자를 선호하다 보니 이런 편견이 생긴 것으로 생각한다. 

필자가 경험한 바로는 여자 개발자들이 공유, 협업 문화에 좀더 잘 적응하고 아키텍트로도 더 뛰어난 경우를 많이 보아왔다. 남자, 여자 누가 더 개발자로서 우수하다고 말하는 것이 아니라 서로 다른 특성이 있으므로 이를 이해할 필요가 있다는 것이다. 

뛰어난 소프트웨어는 다양한 특성을 가진 사람들이 모여서 협업을 하고 그 다양성을 기반으로 창의적인 아이디어가 많이 나와야 탄생할 수 있다.

현재 소프트웨어 업계에 여자 개발자가 절대적으로 부족한 이유는 여러 가지가 있겠지만 일단 누구라도 일하기 힘든 환경이 큰 요인이다. 이런 환경에서 상대적으로 남자들이 더 잘 버티기 때문에 더 많이 남아 있다고 생각한다. 

현재의 기형적인 개발자 성비를 개선하는 것이 소프트웨어 업계에는 꼭 필요한 과제이고 이를 위해서는 누구라도 일하기 좋은 환경을 만드는 것이 우선일 것이다. 그러기 위해서 먼저 여자 개발자에 대한 편견과 차별을 없애야 한다. 

많은 회사들에서 크든 작든 여자 개발자에 대한 차별이 존재한다. 비공식적이지만 급여의 차이도 존재하는 회사도 있다. 승진의 기회도 다르다. 이런 이유는 여자 개발자는 결혼하거나 출산을 하면 결국 그만둘 것이라는 선입관이 존재하기 때문이다. 

소프트웨어 업계에서 여자 임원이 절대적으로 부족한 것을 보면 이런 현상을 알 수 있다. 물론, 남자와 여자가 특성적으로 완전히 동일하다고 말할 수는 없다. 차이가 있고 그러하기 때문에 서로 보완이 된다. 필자의 경험과 교육학적인 여러 도서를 보면 선천적, 후천적인 남녀의 차이는 이런 것들이 있다. 물론 필자의 개인적인 생각도 있으므로 의견이 다를 수도 있다. 

우선 남자 개발자들은 도전정신이 강하고 무모한 자산감도 가진 경우가 많다. 치열한 경쟁에 거부감이 좀더 적고, 상대적으로 체력이 뛰어나서 야근에도 잘 버틴다. 남자 개발자가 좀더 코딩을 잘한다는 의견은 입사 이전에 또는 어렸을 때부터 코딩을 경험할 기회가 좀더 남자에 많기 때문이 아닌가 생각된다. 

이러한 남자들의 특성이 현재의 열악한 개발 환경에 좀더 통할 수 있는 측면이 있는건 사실이다. 무리한 일정에 잦은 야근,  협업은 없고 혼자서 달리는 코딩이 현재 흔하게 볼 수 있는 개발 환경이다. 그리고 요즘은 많이 바뀌고 있지만 부어라 마셔라 회식 문화도 상대적으로 남자들에게 더 적합하다. 

그런 반면 여자 개발자들은 커뮤니케이션과 협업에 더 유리한 특성을 가지고 있다. 서로 경쟁하기보다는 서로 도우려는 특성도 있다. 모두 그렇다는 것이 아니고 평균적으로 좀더 그렇다는 의미다. 

남자들은 모른다고 말하는 것을 꺼려하는 경향이 있다. 그래서 끝까지 도움을 받지 않고 혼자서 해결해 보려고 한다. 하지만 여자들은 초기에 도움을 받아야 할 것을 구분해서 적절한 도움을 받는데 익숙하다. 모른다고 말하는 것에 대해서 자존심의 상처를 덜 받는다. 

이것은 소프트웨어 개발 문화 중 협업의 문화에서 매우 중요한 요소다. 혼자서 엉뚱한 방향으로 내달리지 않고 적절할 때 서로 묻고 의논하고 도와야 제대로 된 방향으로 갈 수 있다. 그런 능력이 상대적으로 여자 개발자에게 더 많이 보인다는 것이 필자의 의견이다. 이런 특성에 기인해서 여자 개발자 중에서 아키텍트로서의 능력이 더 뛰어난 경우를 많이 보았다. 

설령 뛰어난 아키텍트 재능을 가진 개발자가 있다고 하더라도 우리나라와 같은 개발 환경에서는 눈에도 잘 안띄고 실력을 발휘하기도 어렵다. 

여자 개발자들에게는 출산과 육아의 장애물이 존재한다. 우리나라에서는 출산과 육아는 개발 경력의 큰 단절이고 2,3년만 단절되면 현업 복귀가 쉽지 않은 분야이기도 하다. 실력적으로는 현업복귀가 가능해도 기업에서 꺼리는 경우도 많다. 

재택근무로도 무리 없이 일할 수 있지만 재택근무를 그렇게 효과적으로 할 수 있는 회사가 그렇게 많지 않은 것이 안타까운 현실이다. 

현재와 같이 여자 개발자들이 꾸준히 일하기 어려운 환경은 여자들에게만 불리한 것이 아니라 모든 개발자에게 불리하며 이런 특성 때문에 개발이 3D 업무라고 불린다. 

경쟁보다는 협업을 하고 혼자 달리기 보다는 공유, 토론, 의논을 적절히 하는 환경, 무모한 일정에 따른 품질 저하와 그에 따른 야근의 악순환 보다는 합리적인 프로젝트, 재택근무를 해도 개발에 전혀 지장이 없는 프로세스, 시스템 그리고 문화, 이런 환경과 문화가 여자 개발자뿐만 아니라 모두에게 필요하다. 지금같이 여자 개발자들이 살아남기 힘든 환경이 계속된다면 소프트웨어 업계 전체가 살아남기 힘들 것이다. 

이글은 ZDNet Korea에 기고한 칼럼입니다. 

외주 SW 개발의 비극

열악한 소프트웨어 외주 개발 문제는 우리나라에서 소프트웨어가 3D 취급을 받는 주요한 원인 중 하나다. 

'갑을병'으로 이어지는 외주도 모자라 '갑을병정무'까지 3,4단계 외주를 주기도 한다. 하청에 재하청이 이어질수록 열악한 댓가와 무리한 일정 그리고 부정확한 요구사항은 외주 개발을 점점 구렁텅이로 내몰고 있다.
소프트웨어 외주 개발 문제를 얘기하면 할 말이 많은 사람들이 꽤 있을 것이다. 필자는 그 중에서 접해 본 사례를 중심으로 소프트웨어 공학과개발 문화적으로 문제점을 지적해보고자 한다.

A사는 새로운 서비스를 시작하면서 서비스 개발을 야심차게 인도에 외주를 줬다가 큰 낭패를 봤다. 

지금도 왜 인도에 외주를 줬는지 궁금하지만 추측컨데 실리콘밸리 외주 형태를 흉내를 낸 것이 아닌가 생각한다. 그런데 인도 개발사는 개발 완료 후 L사에서 기대한 것과 전혀 다른 것을 전달해왔다. 프로토콜도 완전히 다른 것이고 도저히 서비스에 사용할 수 있는 상황이 아니었다. 

이런 일이 벌어진 가장 큰 이유는 스펙을 제대로 전달하지 않았기 때문이다. 인도 개발사에 전달된 스펙은 간단한 기획서 수준이었고 프로토콜도 제대로 언급하지 않았다. 게다가 인도 개발사가 소프트웨어를 완성해서 전달할 때까지 중간에 제대로 점검을 하지 않았다. 

한국 업체 같으면 억지를 부려서 잔금을 안주면서 다시 개발을 강요 했겠지만 인도 개발사는 계약대로 개발을 했고 억지는 통하지 않았다. 잔금을 안줄 수는 없었다. 결국 인도 개발사가 개발한 소프트웨어는 모두 버리고 다급하게 한국업체를 통해서 다시 개발을 했다. 돈은 돈대로 더 들고 서비스도 뒤죽박죽이 되었다. 

B사는 1년이 넘는 꽤 긴 프로젝트를 제대로 된 스펙도 없이 외주를 주고 고치기를 반복한다. 

외주 개발사에는 핵심 기능을 정리한 한 두 페이지 정도의 요구 사항 문서가 전달된다. 외주 개발사는 전체 프로젝트 기간 중 20~30% 정도 기간 안에 소프트웨어를 만들어 보여줘야 한다. 남은 70~80% 기간은 B사의 요구대로 거의 매일 소프트웨어를 수정하고 보여주기를 반복해야 한다.

외주 개발사는 해당 분야의 전문 회사라 이런 부정확한 요구사항으로도 대충 B사가 원하는 것을 이해해 개발할 수 있었다. 개발사의 PM은 수시로 고객사에 불려가 요구사항 변경 회의를 해야 했고 소프트웨어를 계속 고쳐나가기 때문에 아키텍처를 제대로 유지하기가 어려웠다. 

심지어 막판에 요구사항이 크게 바뀌어서 다 버리고 다시 만드는 일도 발생했다. 외주 개발사는 비용도 과도하게 투입해야 하고 프로젝트 관리를 제대로 하기도 어렵다. 하지만 B사가 가장 큰 고객이므로 시키는 대로 할 수 밖에 없었다. B사는 이런 식으로 프로젝트를 진행하는 것을 아직도 당연하게 생각한다.

C사와 D사는 소프트웨어 개발 외주가 제대로 진행이 안돼 외주사 개발자를 회사 내부에 앉혀 놓고 같이 개발하는 형태로 개발을 한다. 

외주 프로젝트지만 옆에서 같이 개발하지 않으면 제대로 개발이 안되기 때문에 같이 일해야 한다. 옆에 앉혀 놓고 개발한다 뿐이지 개발 방식은 다른 외주와 별반 다를 바가 없다. 요구사항은 계속 변하고 애써 작성한 코드를 버리고 고치기를 반복해야 한다. 

외주사도 이런 방식이 비효율적이라서 원하지 않지만 고객사의 우월한 지위를 꺽을 수가 없고 이렇게 일하다 보니 외주 개발 내용 외에 그냥 직원처럼 부림을 당하는 경우가 많이 발생한다. 

D사는 외주를 줬다가 소스코드가 없어져서 소프트웨어를 버려야 했다. 

D사는 소스코드를 받을 수 없는 외주 계약으로 개발을 했다. 처음 몇 년은 유지보수를 잘 했지만 몇 년 후 외주 개발사는 망해서 없어졌다. 그 과정에서 소스코드가 D사로 제대로 전달되지 않아서 최신 소스코드를 찾을 수 없는 상황이 되었다. 결국 외주 개발한 소프트웨어는 모두 버리고 다시 개발해야 하는 상황이 되었다.

E사는 개발자가 해야 할 개발자 테스트를 외주업체에 맡긴다.

개발자는 열심히 코딩만 하고 옆에 앉아서 외주개발자가 기본적인 개발자 테스트를 해준다. 속된 말로 '따까리'라는 말이 적합하다. 비싼 자사 개발자가 너무 바쁘기 때문에 그렇게 한다고는 하지만 자칫하면 잘못된 개발 습관이 쌓일 수 있다. 

또한 이렇게 해서는 코드 품질을 보장하기 어렵다. 완벽한 로직의 코드인지는 개발자 본인이 가장 잘 확인 할 수 있는데 대충 만들고 발견된 문제만 해결하는 방식이 습관화 될 수도 있다. 개발자는 완벽한 소스코드를 적는데 최선을 다해야 하는데 이런 개발자의 의무를 망각하면 프로그래밍은 기초부터 흔들리게 된다. 

위에서 살펴 볼 수 있듯 외주 문제의 주된 원인은 부실한 스펙이다. 모호한 요구사항 정도로 계약을 하게 되니 중간에 요구사항이 계속 바뀌어도 어쩔 수 없고 프로젝트 종료 기준도 모호하여 담당자 맘에 안들면 잔금을 받기도 어렵다. 소송도 종종 일어나지만 시간도 오래 걸리고 소송을 해도 해결하기 쉽지 않다. 고객이 대기업인 경우 소송을 하기도 쉽지 않다. 스펙을 제대로 적는 것은 소프트웨어를 개발하는데 있어서 가장 어려운 일이기 때문에 한마디로 설명할 수는 없다. 

소프트웨어를 직접 개발하지 않고 외주 개발을 하는 주된 이유는 다음과 같다. 직접 개발할 수는 있는데 내부 인력이 부족할 때와 특정 요소기술을 내부에서 보유하고 있지 않을 경우다. 내부에서 개발할 수 없을 만큼 잘 모를 때는 외주를 주기도 어렵다. 모르는 상태에서 대충 외주를 주면 원하는 결과를 얻기도 어렵고 분쟁이 일어나기 쉽다. 

기술력이 뛰어나거나 전문 기술을 가지고 있는 외주 개발사와 협업을 잘하는 것은 소프트웨어 생태계를 만드는데 아주 중요하다. 제대로 외주를 주기 위해서는 고객도 스펙을 제대로 적을 수 있을 만큼 잘 알아야 한다. 

부품 업체 다 망하고 나면 자동차 회사도 망하듯이 수많은 전문 소프트웨어 회사들이 망하고 나면 우리나라 소프트웨어 업계도 망하는 것이당연한 수순이다. 대만이 자전거 산업에서 세계를 호령하는 이유는 자전거 부품회사와 꾸준히 상생을 해와서 대만에는 뛰어난 자전거 부품회사가 많기 때문이다. 그에 비해서 생산비 절감에만 몰두한 우리나라 자전거 산업은 전세계 자전거 산업에서 명함도 못 내밀고 있다. 이미 많은 중소 소프트웨어 회사들이 사라졌거나 고사 상태인 지금 자전거 산업과 비슷한 미래가 예상되는 것은 안타까운 일이 아닐 수 없다. 

이제 와서 말로만 베풀듯이 상생이라고 외치는 것은 들을 때마다 거북하고 막상 그 내용도 해결책의 핵심은 아니다. 우리나라에서 소프트웨어 개발이 3D라는 인식에서 벗어나라면 이런 열악한 외주 환경이 바뀌지 않으면 안된다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.

고객이 SW를 망친다

우리나라는 고객이 소프트웨어와 개발사를 망치는 경우가 많다. 외국 소프트웨어 회사와는 다른 잣대로 우리 소프트웨어 회사를 대하는 이중성 때문에 우리나라 소프트웨어 회사는 더욱 어려움을 겪는다. 물론 이런 현상이 꼭 고객 탓만은 아니다. 

우리나라 소프트웨어 회사들이 미래는 생각하지 않고 당장 눈앞의 이익만 쫓다 보니 고객들은 여기에 길들여진 측면도 있다.

이렇게 고객이 소프트웨어 환경을 망치고 있는 실제 사례들을 알아보자. 

A사 고객들은 참을성이 없다. 

소프트웨어에 버그가 발견되면 당장 고쳐달라고 막무가내 식으로 요구한다. A사는 팩키지 소프트웨어를 만들기 때문에 개별 고객의 요구사항을 다 들어주지는 않는다. 하지만 이렇게 무리한 요구를 하는 고객이 많기 때문에 당장 고쳐주지 않을 수 없다. 

이렇게 계획되지 않는 급한 수정을 핫픽스(Hotfix)라고 한다. A사는 특정 몇몇 고객 때문에 핫픽스를 과도하게 많이 만드느라 계획된 개발 일정에 지장이 생겼고 소스코드도 지저분해졌다. 

하지만 A사 고객들도 외국 소프트웨어를 사용하면서는 그런 무리한 요구를 하지 않는다. 외국 소프트웨어 회사들은 대부분 그런 요구는 들어주지도 않기 때문이다. 

B사는 소프트웨어 버그로 인해서 개발자가 고객사에 방문 사과를 한적이 있다. 

B사 고객들은 소프트웨어 버그가 발견되면 개발자를 죄인 취급한다. 가끔은 심각한 버그가 발생하면 개발자의 방문사과를 요구한다. 이런 말도 안되는 요구에 B사는 상황을 쉽게 모면해 보려고 개발자에게 고객을 방문해서 사과할 것을 지시했다. 

개발자는 어쩔 수 없이 사과 방문을 했고 개발자로서 회의를 느꼈다. 사실 버그 없는 소프트웨어는 없고 버그가 개발자만의 책임도 아니다. 개발에 참여한 모든 사람의 공동 책임인데 아직도 버그의 모든 책임은 개발자에게 있다고 생각을 하는 경향이 있다. 

자동차를 타면서 문제가 발생하면 자동차 만든 사람이 와서 사과를 하라고 하는 경우는 없다. 개발자에게 버그에 대한 사과를 요구하는 일은 대한민국에서만 벌어지는 현상이 아닐까? 

C사는 개발자들이 고객 옆에서 개발을 해야 한다. 

C사는 솔루션 회사다. 자사 솔루션을 이용해서 고객 요구대로 커스트마이징해서 개발을 해준다. 그런데 주로 고객들은 자사 담당자 옆자리에서 개발을 할 것을 요구한다. 사실 개발자들은 다니는 회사에서 개발하는 것이 훨씬 더 효율적이다. 여러 동료의 도움을 받을 수도 있고 환경도 더 좋다. 

그런데 고객이 방문해서 개발을 할 것을 강력하게 요청하기 때문에 어쩔 수가 없다. 스펙도 정하지 않고 옆에 앉혀 놓고 이러쿵저러쿵내키는대로 요구사항을 말하면서 소프트웨어를 개발한다. 요구사항이 많이 바뀌어서 지우고 다시 만들기를 수없이 반복했다. 

물론 외국 경쟁회사는 이런 요구에 콧방귀도 안뀌기 때문에 C사는 이런 방문 개발 방식을 강점으로 내세워서 국내 시장에서 상당한 성공을 이뤄냈다. 하지만 성장은 한계에 다다랐고 과거의 방식을 버려야 더 점프를 할 수 있다는 것을 알아도 방식을 바꾸기에는 너무 늦어버렸다. 고객보다도 개발자들이 이 방식에 익숙해져서 내부 개발문화를 바꾸지 못하는 것이 더 큰 걸림돌이 되고 있다. 

D사도 고객사에 방문해서 개발을 해야 한다. 

하지만 이유가 약간 다르다. 고객이 보안을 너무 강조하다 보니까 고객사에 방문해서 개발할 수 밖에 없다. 고객사에서 아무것도 가지고 나올 수 없다. 개발은 모두 고객사에서 해야 하고 고객사를 나올 때는 몸밖에 빠져나올 수 밖에 없다. 사실 이 회사도 외국 소프트웨어 회사와는 이렇게 일하지 않는다. 고객의 이중성은 여기서도 드러난다. 

E사는 유지보수 비용을 제대로 받지 못했다. 

E사는 솔루션 회사인데 납품 후에도 지속적인 유지보수 비용이 들어간다. 버그 수정 및 기능 개선이 꾸준히 이루어진다. 하지만 고객은 무상 유지보수를 요구해서 유지보수 비용을 제대로 받지 못한다. 심지어는 버그를 고치는데 왜 돈을 받냐는 주장을 하기도 한다. 

E사의 고객들도 외국의 소프트웨어를 쓸 때는 군말 없이 유지보수 비용을 지불한다. 외국 소프트웨어를 쓸 때는 패키지 소프트웨어라 하더라도 워런티 계약을 따로 한다. 워런티 비용은 소프트웨어마다 다르지만 매년 소프트웨어 구매 비용의 10%~50%를 지불한다. 

1년간 아무런 요청을 하지 않아도 비용은 지불해야 한다. 3년간 워런티 계약을 하지 않다가 4년째 문제가 발생해서 지원을 요청하려면 4년치 워런티 비용을 모두 지불해야 한다. 이렇게 외국의 소프트웨어 회사에는 유지보수 비용을 지불하지만 대한민국의 소프트웨어 회사에는 매우 인색한 것이 현실이다. 

F사 고객이 말도 안되는 문서를 수십 종 요구한다. 

F사는 SI회사다. 대부분은 실제 소프트웨어 개발에 꼭 필요한 문서는 아니다. 단지 고객이 제시하는 방법론에서 필요한 문서일 뿐이다. F사는 실제로는 고객 프로세스대로 소프트웨어를 개발하지도 않는다. 그런 식으로는 소프트웨어를 주어진 시간에 개발할 수 없기 때문이다. 

개발은 그냥 평소대로 하면서 문서만 추가로 따로 만든다. 문서를 반복적으로 만들어내다보니 너무 번거로워서 나중에는 문서를 자동으로 생성하는 프로그램을 만들기도 했다. 이렇게 만들어진 문서는 프로젝트 도중에도 프로젝트 후에도 아무도 보지 않는다. 

그냥 검수를 통과하기 위한 조건일 뿐이고 검수 시에도 소프트웨어와 문서가 일치하는지 확인할 방법도 없다. F사는 고객의 이러한 과도한 문서 요구에 프로젝트 비용이 훨씬 많이 들어가고 정작 개발할 시간이 줄어 들고 있다고 하소연을 하고 있다. 

G사는 패키지를 수정해달라는 고객의 요구로 인해서 회사가 어려워졌다. 

G사 고객들은 패키지 소프트웨어를 바꿔달라는 요구가 많다. G사도 이런 고객의 요구사항에 빠르게 대응하다 보니 소스코드가 여러 벌이 생겼다. 소스코드도 그냥 복사를 해서 고객별로 관리를 해서 시간이 흐를수록 개발 속도는 점점 늦어졌다. 기능 하나를 수정해도 여러 벌의 소스코드에 적용을 해야 했다. 

이렇게 소스코드를 통합(Merge)하는 시간이 점점 길어졌고 나중에는 개발하는 시간보다 소스코드 통합에 더 많은 시간이 소요되었다. 결국 G사는 문을 닫았다. 이는 고객 탓만은 아니고 눈앞의 이익만 쫓는 G사의 무분별한 단기 대응도 문제였다. 

요즘 정부도 민간도 소프트웨어 환경을 개선해보고자 많은 노력을 기울이고 있지만 정작 돈을 내고 있는 고객들은 바뀌지 않고 있다. 물론 고객만의 탓은 아니다. 수십 년간 우리나라 개발회사들에 길들여진 것뿐이다. 

이렇게 소프트웨어 환경이 망가지면 결국 고객들도 손해를 본다. 우리나라 소프트웨어 회사들이 많이 망가지고 나면 제대로 쓸만한 국산 소프트웨어가 줄어들고 울며 겨자먹기 식으로 비싸고 문화도 잘 맞지 않는 외국의 소프트웨어를 써야 한다. 

법으로 바꿀 수 있는 것은 바꿔야 한다. 사실 별 뾰족한 답도 없는 문제지만 결국 고객을 바꾸는 것은 개발사들이다. 계획적인 개발을 하려고 해도 경쟁사에서 고객 밀착형 서비스를 한다고 하면 경쟁에서 밀리고 만다. 

결국 이런 소프트웨어 품질보다 노예식 개발을 장점으로 내세우는 전략은 모두를 다 망치는 일이라는 것을 인식하자. 특히 시장을 주도하는 선두 주자들부터 소프트웨어 환경을 건전하게 바꾸어 나가면 고객의 우리나라 소프트웨어에 대한 이중적인 인식을 바꾸는 것이 불가능하지는 않을 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

CMMI는 회사를 망칠 수도 있다

필자는 최근 소프트웨어와 시스템 공학 역량의 성숙도를 평가하는 CMMI(Capability Maturity Model Integration)를 적용하여 오히려 어려워진 H사 직원 S씨를 만났다. 

그동안 SI회사 등 여러 곳에서 CMMI를 적용하였던 회사의 직원들을 많이 만나봤지만 SI회사도 아닌 이 회사의 사례는 독특해 칼럼에서 소개할까 한다. 

CMMI를 폄훼하려는 의도가 있는 것은 전혀 아니니 오해는 하지 말아주기 바란다. CMMI에 대한 오해와 서투른 기대를 경계하자는 것이다. 이는 CMMI 뿐만 아니라 수많은 방법론에도 똑같이 해당한다. 

H사는 최근 촉망받는 분야의 서비스를 하는 회사다. 직원이 100명 가까이 되는 작지 않는 회사지만 개발에 관련된 변변한 문서가 하나도 없다. 스펙, 설계서 뿐만 아니라 문서는 전무하다 시피하다. 개발 프로세스라고 할 만한 것도 없다보니, 주먹구구식으로 개발을 하고 있었다. 

고참 개발자라고 하는 사람들도 코딩만 꽤 할 줄 알았지 개발 프로세스가 뭔지도 모르고 협업에는 별로 관심도 없는 상태였다고 한다. 

이에 H사 대표는 이대로는 안되겠으니 컨설팅을 받아봐야겠다고 생각 했다. 그래서 선택한 컨설팅 회사가 CMMI를 전문적으로 컨설팅하는 국내 회사인 P사였다. 

P사는 CMMI 레벨3를 적용하자고 제안했고 직원들은 회사 내부에서 관련 교육을 받았다. 외부에 나가서도 수차례 교육을 받았다. P사는 회사의 기존 프로세스와 그나마 있었던 문서를 분석해서 CMMI 레벨3 기준으로 개발 프로세스를 만들고 수십가지의 문서 탬플릿을 만들어서 제안했다. 

실제 프로젝트에 이 프로세스와 문서 탬플릿을 적용하기 시작했는데 교육을 받기는 했지만 요구하는 수많은 문서를 만들어내기는 보통 어려운 일이 아니었다. 또 촉박한 프로젝트 일정에 문서까지 추가로 만드는 것은 죽을 맛이었다고 한다. 이에 개발자 및 사업부에서는 반발이 매우 심했고, CMMI를 적용하느라 몇개 프로젝트는 포기를 해야 하는 상황까지 발생했다고 한다. 

이런 상황에서 개발자들이 선택한 방법은 어처구니는 없는 것이었다. 문서에 적어야 하는 기능의 개수를 줄이기 시작한 것이다. 

기능하나에 서로 연결해서 작성해야 하는 문서가 많아서 전체 문서 양이 매우 많았다. 예를 들어 실제로는 500개 기능인 프로젝트에서 문서에는 100개만 적으면 문서 개수가 많아도 전체 작성해야 하는 문서의 양은 줄어들게 된다. 그렇게 해서 요구하는 문서와 프로세스를 따랐다고 한다. 정해진 일정에 요구하는 문서를 만들어 내려면 어쩔 수 없다고 한다. 

CMMI를 적용한 프로젝트에 참여했던 S씨는 해당 프로젝트에서 20여가지 문서를 만들었지만 실제 프로젝트에 쓰인것은 SRS와 WBS 문서 2개 밖에 없다고 했다. 나머지 20여가지 문서는 컨설팅 회사에서 요구하기 때문에 만들었을 뿐이라고 한다. 프로젝트 중간이나 프로젝트가 끝난 후에도 나머지 문서들은 볼일이 없을 것이라고 한다. 

H사는 그 뒤로 개발역량 향상은 커녕 CMMI의 직접적인 영향을 아니겠지만 매우 어려운 상태에 놓이게 되었다. 

이론적으로 CMMI를 통해 SW공학의 성숙도를 측정하고 역량을 향상할 수 있다. 하지만 오해와 잘못된 적용 방식이 국내에서는 큰 문제가 되고 있다. 역량 수준이 한참 못미치는데 억지로 요구하는 수준에 맞추기 위해서 문서를 만들어내고 프로세스를 따르는 것이다. 그렇게 해서는 역량이 향상될리 없다. 이런 일이 빈번하여 한국이 블랙리스트에 올랐다는 소문도 파다하다. 

CMMI가 필요한 분야도 있다. 대표적인 분야가 국방일 것이다. 국방 프로젝트는 1달러짜리 나사를 사기 위해서 프로세스와 문서를 적용하여 50달러를 투입해야 할 때도 있는 프로젝트다. 민간 프로젝트와는 성격이 다른 중요도가 있는 프로젝트이다. 

그 외에도 CMMI 인증이 필요한 프로젝트가 있다. 역량이 안되더라도 비즈니스 목적으로 CMMI를 적용하는 것은 그럴 수도 있다고 생각한다. 개발에는 별로 도움이 안되고 영업에는 도움이 될 것이다. 

하지만 순수하게 소프트웨어 개발 역량을 높이기 위해서 단기간에 CMMI를 적용하는 것은 별로 좋은 방법이 아니다. 실전적인 방법으로 내실을 다지는 것이 더 낫다. 

적당할 예 일지는 모르겠지만 타이거 우즈가 CMMI 레벨5 수준으로 골프를 친다고 가정하자. 타이거 우즈는 CMMI 레벨5로 골프를 치기 위해서 골프 스윙시 25가지의 절차와 고려사항을 눈깜짝할 사이에 적용해서 공을 친다. CMMI 레벨5에서는 그 25가지의 절차를 잘 분석해 놨다. 

나는 주말골퍼인데 코치가 그 25가지 절차를 따르면 타이거우즈처럼 골프를 칠수 있다고 한다. 1년을 그렇게 연습한다고 타이거 우즈처럼 골프를 칠 수 있을까? 타이거 우즈는 이미 성숙도가 높고 몸에 완전히 베어 있어서 25가지의 절차를 아무렇지도 않게 수행할 수 있지만 나는 그렇게 할 수가 없다. 

그것을 따라하다가는 오히려 골프를 더 못치게 된다. 현재 상황에서 필요한 것을 하나씩 배우는 것이 훨씬 낫다. 또한 대부분의 실용적인 소프트웨어 개발 현장에서는 그 수준까지는 필요하지도 않다. 

사대주의도 아니고 바다건너의 멋진 모델에 현혹되는 사례가 유난히 우리나라에는 많은 것 같다. 실리콘밸리에서 오래 개발한 개발자들에게 물어봐도 CMMI는 관심도 없고 주변에 적용한 회사는 본적도 없다고 한다. 그만큼 실전적이고 실용주의적인 개발을 지향하는 곳이라면 성숙된 개발 문화와 개발 본연의 역량 향상에 힘을 쓴다. 뛰어난 아키텍트 발굴도 그 일환이다. 

이는 비단 CMMI만의 이야기가 아니다. 수많은 방법론도 마찬가지다. 그자체로는 훌륭할지는 몰라도 적절한 곳에 적용을 해야 하며 우리 회사에서 필요한 것인지는 잘 생각해봐야 한다. 

필자는 좀더 효율적으로 개발을 하기 위해서는 성숙된 개발문화를 정착하기 위해 노력해야 한다고 생각한다. 실용적이고 실전적이지 않은 모든 절차와 프로세스는 짐이 될 뿐이다.

이글은  ZDNet Korea에 기고한 칼럼입니다.

SW 산업의 부실한 계약문화(개발문화 시리즈9)

이번 개발문화 이야기는 '계약 문화'다. 

나는 개발자지만 여러 차례 계약의 경험이 있다. 특히 한국, 일본, 미국의 계약 문화를 두루 경험해봤다. 회사 설립 관련된 계약도 해보고 프로젝트 계약도 많이 해봤다. 그러면서 나라별로 계약 문화에 많은 차이가 있음을 알게 되었다. 어찌 보면 계약만의 문제는 아닌 것 같다. 일상의 약속, 구두 계약에서도 비슷한 현상이 벌어진다. 

한국에서는 선비정신과 의리문화 영향인지 몰라도 돈에 관해서 직접적으로 말하기를 꺼려하는 경향이 있다. “좋은 게 좋은 것”이라는 말이 있듯 서로 좋은 얘기만 하려고 한다. 계약 조건에 대해서 꼼꼼하게 점검하고 따지면 너무 깐깐하다는 얘기를 듣기도 한다. 

하지만 미국의 개발문화는 좀 달랐다. 나도 처음에는 이질감을 많이 느꼈다. 개인적으로 친한 관계라 하더라도 계약을 할 때는 냉정할 정도로 철저했다. 어색할 정도로 금액에 대한 얘기도 까다롭고 꼼꼼했다. 잘못될 경우에 대한 얘기도 철저히 언급을 해서 친분에 금이 갈 것 같은 생각이 들었다. 

내가 경험한 미국인과의 계약이 그랬던 것이지 전체를 대표하는 것은 아니다. 어쨌든 결과적으로 그런 철저한 계약은 일이 잘되든 잘못되든 문제의 소지가 별로 없었고 인간관계도 해치지 않았다. 한국에서 약속이나 계약이 틀어지면 인간관계까지 깨지는 경험을 해봤는데 그와는 사뭇 달랐다. 

그 뒤로도 한국에서 계약을 여러 번 했지만 한국 문화를 거스르기는 어려웠다. 하지만 나름대로 정확하게 하고 문제의 소지를 없애기 위해서 노력을 하고 있다. 

한국의 계약 문화가 계약 자체만의 문제라기 보다는 사회 전체적인 여러 관습들의 복합체라서 혼자서 바꾸기는 어렵다. 칼럼에서 이를 한방에 해결할 수 있는 기가 막힌 방법을 제시해 줄 것으로 생각하면 기대가 너무 큰 것 같다. 그래도 문제의 인식이 문제 해결의 출발이다. 무엇이 문제인지 같이 생각해보자. 

첫째, 계약 전에 일 시작하기 
계약을 하기도 전에 일을 시작하는 것은 비일비재하다. 이유는 여러가지가 있다. 계약 절차가 복잡해서 늦어진다고 핑계를 대기도 하고 담당자가 미리 꼼꼼하게 챙기지 않아서 늦어지기도 한다. 그래도 빨리빨리 문화는 여전해서 일단 일을 먼저 시작하자고 한다. 

가끔은 일부러 계약을 늦추기도 한다. 어차피 계약은 될 것이라고 하지만 계약이 늦어지면 불리한 쪽은 외주사이고 나중에는 계약 조건을 꼼꼼히 따지기도 어려워진다. 계약금도 제때 받지 못하기도 하고 프로젝트가 아예 취소되기도 한다. 지급을 늦출수록 이자만큼 이익이기 때문에 일부러 늦추는 회사도 있지만 신뢰관계의 손실과 이자만큼의 이익중 어느 것이 진짜 회사에 이익인지는 생각해볼 필요가 있다. 

이런 현상은 프로젝트 뿐만 아니라 스타트업들에서도 벌어진다. 의리로 애매하게 시작해서 회사가 잘되면 서로 생각이 달라져서 문제가 되기도 한다. 이때 보통 손해를 보는 쪽은 개발자들이다. 화장실 들어갈 때와 나올 때 달라지는 것이기 때문에 화장실 들어가기 전에 확실히 정해야 한다. 

둘째, 범위를 정하기 않고 계약하기 

얼마 전 미국의 한 개발자가 자신의 일을 외국 개발자에게 적은 금액에 외주를 주고 자신은 취미생활을 한 사례가 화제가 되었다. 이런 일이 우리나라에서 가능할까? 쉽지 않을 것이다. 이런 일이 가능 하려면 내부 개발이라도 스펙이 명확하고 투명하게 개발이 되어야 한다. 

이런 에피소드를 그냥 우습게만 생각할 것은 아니다. 한명의 개발자도 외주를 제대로 줄 수 있는데, 우리나라에서는 수백억짜리 프로젝트가 스펙도 제대로 정하지 않고 진행되는 경우가 있다. 일정과 금액이 이미 정해진 상태에서 소프트웨어 개발 프로젝트를 진행하면서 스펙을 정하게 되면 초기 예상보다 범위와 비용이 훨씬 늘기도 한다. 1천억원짜리 프로젝트에 3천억원이 투입되었다는 한 SI회사의 하소연을 들은 적도 있다. 
과거에 같이 일했었던 실리콘밸리의 개발자에게 들은 얘기다. 과거에 국내 대기업의 외주 프로젝트를 진행한적이 있는데 스펙도 없이 대충 프로젝트를 시작해서 자신이 스펙을 자세히 적어서 보여줬다고 한다. 그런데 담당자는 스펙을 보지도 않고 진행과정에서 공유를 해도 관심을 갖고 확인도 하지 않았다고 한다. 

그러다가 소프트웨어 완성 후에 원하는 것이 아니라고 기능변경을 계속 요청했다고 한다. 어이가 없어서 그뒤로 한국과는 프로젝트를 안한다고 한다. 한국에서는 비일비재한 일이지만 미국인에게는 납득이 안되는 상황이다.

이것은 이미 사회적으로도 큰 문제라서 스펙을 정하는 프로젝트와 구현하는 프로젝트를 나눠서 발주하는 '분할발주'를 추진하고 있다. 분명히 필요한 제도지만 이것이 법률화 된다고 하더라도 공공분야에 국한된 것이고 스펙을 제대로 정하는 것도 쉽지 않아서 잘 정착될지는 미지수다. 

고객이 전문성이 떨어지고 의무를 다하지 않고 우월적인 지위를 남용하는 문화가 팽배해서는 법률로 문제를 해결하기는 쉽지 않다. 

셋째, 모호하게 계약하기 
수많은 중소기업과 외주 개발사를 괴롭히는 문제다. 계약서에 제대로 된 스펙을 포함하지 않고 계약을 하는 경우가 매우 흔하다. 이런 현상은 내부개발을 할 때도 발생한다. 하지만 내부개발 시에는 서로 얘기를 하면서 조정해 나가고 점진적으로 개발을 잘 해내기도 한다.

하지만 외주 프로젝트는 같은 방식으로 진행하면 내부 개발보다 문제가 몇 배 더 커진다. 모호한 스펙은 서로 다르게 생각하게 하고 개발한 결과가 예상과 다르면 소송으로 이어지기도 한다. 

스펙을 대충 정하고 개발을 시작한 후 발주사가 원하는대로 언제든지 기능 변경을 요구하면서 개발하는 방식도 이와 비슷하다. 발주사는 아무 때나 기능 변경을 강요하고 외주사는 어쩔 수 없이 들어줘야 하는 경우가 많다. 

원래는 계약을 한 줄만 바꿔도 재계약을 해야 하지만 우리나라에서는 상상하기 쉽지 않은 일이다. 프로젝트 완료 후 검수조건이 모호한 것도 마찬가지다. 명확한 조건에 의해서 검수를 하는 것이 아니라 담당자 개인 취향에 맞지 않으면 검수에 실패하기도 한다. 

모호한 스펙은 여러가지 패턴이 있지만 보통 유저인터페이스나 기능 보다 기능이 아닌 요구사항에서 더 큰 문제가 발생한다.

비기능은 일반적으로 자세히 언급하지 않기 때문에 누락되기 쉽고 문제가 되면 시스템을 다 버리고 다시 만들어야 할 정도로 큰 이슈들이 발생하기도 한다. 비기능 요구사항에는 성능, 보안성, 안정성, 가용성, 이식성, 유지보수성, 확장성, 표준, 제약사항 등 셀 수 없을 정도로 많고 프로젝트마다 중요한 부분이 다르다. 

표현방법이 문제가 되기도 한다. ~을 지원한다, 효율적이어야 한다, 편리해야 한다 등과 같이 측정이 불가능한 문구들은 언제든 문제가 된다. 보는 사람에 따라 다르게 해석되는 문구들은 없어야 한다. 스펙을 명확하게 적는 주제는 너무 방대해서 여기서 다 설명하기는 어렵다. 

넷째, 계약은 서류일뿐 

이런 환경이라면 수많은 프로젝트가 소송에 휩쓸리고 일을 할 수 없어야 한다. 물론 분쟁에 휩싸여서 문닫은 회사도 많지만 모든 문제가 소송으로 이어지지는 않는다. 프로젝트 결과에 대해서 발주사와 외주사가 서로 다르게 생각하거나 계약 내용을 제대로 이행하지 않은 경우에도 소송대신 다른 방법으로 해결하기도 한다. 

접대로 풀기도 하고 인간관계를 이용해서 해결하기도 한다. 프로젝트의 실패가 발주사 담당자의 피해로 이어질 수 있기 때문에 유야무야 성공한 프로젝트로 탈바꿈하기도 한다. 이러다보니 계약에 문제가 있어도 나중에 풀면 된다는 생각으로 계약을 대충 진행하기도 한다. 

이러한 문화적인 문제들이 계속 이어지는 것은 소프트웨어 개발 문화뿐만 아니라 역량 향상에도 문제가 된다. 수많은 중소기업과 외주사를 괴롭히는 요인이다. 이런 문화를 빠르게 개선하는 뾰족한 방법은 없는 것 같다. 

법적인 뒷받침도 필요하고 다 같이 문화를 바꾸려는 노력이 필요하다. 다같이 공멸하느냐 토양을 개선해서 같이 상생하느냐의 중요한 문제다. 자칫 하소연으로만 들릴 수도 있지만 이런 불합리를 바꾸려고 노력하는 사람도 많다. 그런 노력에 조금이라고 힘이 보태지기를 바란다.

이글은 ZDNet에 기고한 칼럼입니다.

SW개발과 빨리빨리 문화의 저주(개발문화 시리즈3)

이번에 다룰 개발문화 이야기는 '빨리빨리 문화'다. 

일을 빨리 하자는게 나쁜 건 아니다. 오히려 이런 '빨리빨리 문화' 덕분에 우리나라가 짧은 기간에 성장했을지도 모른다. 더 짧은 시간에 똑 같은 일을 해낼 수 있다는 것은 경쟁력이 있는 것이다. 우리는 그동안 많은 산업분야에서 '빨리빨리 문화'의 혜택을 입었고, 관련 노하우도 많다. 

그런데, 이런 '빨리빨리 문화'가 소프트웨어 분야에서는 독이 되는 경우가 많다. 실제로 독이 되는 경우를 많이 보았다. 시제품은 빨리 만드는데 본제품을 완성하는데는 시간이 훨씬 오래 걸리며 품질도 떨어지고 시간이 흐를수록 유지보수가 무척 어려워져서 제품을 포기하는 경우도 흔하다. 상황을 수습하지 못해, 회사의 종말로 이어질 때도 있다. 

유독 왜 소프트웨어 분야에서 '빨리빨리 문화'가 문제가 되는 것일까?  원인은 세가지로 요약할 수 있다. 

첫째, 소프트웨어는 훨씬 복잡하다. 다른 분야에는 미안하지만 소프트웨어는 가장 복잡한 지식산업이다. 빨리 개발해야 한다고 열심히 코딩부터 시작해서 으쌰으쌰 개발하면 아키텍처는 뒤죽박죽 되고 개발 기간도 오래 걸린다. 그렇다고 차근차근 모든 설계서를 만들고 설계서대로 개발하면 좋겠지만 그렇게 하면 웬만한 프로젝트를 마무리는데 10년쯤 걸릴 것이다. 절묘한 절충이 가장 어렵다. 

둘째, 소프트웨어는 예술이다. 소프트웨어 아키텍처를 만들어 가는 과정은 예술과 비슷하다. 예술은 재촉한하거나 야근을 한다고 해서 빨리, 더 좋은 결과가 나오는 것은 아니다. 수많은 요구사항과 비즈니스 전략 등을 종합하여 가장 적합한 아키텍처를 만드는데 시간이 부족하면 부실한 아키텍처가 되고 개발에 들어갔거나 유지보수시 이를 바꾸려면 비용은 100배, 1000배가 더 든다. 

셋째, 소프트웨어는 생명체와 같다. 소프트웨어는 건축에서 개념을 가져온 것도 많고 실제 비슷한 것도 많다. 하지만 빌딩은 일단 완공되면 100년동안 기본 구조가 거의 안바뀌지만 소프트웨어는 보통 출시되도 계속 성장한다. 소프트웨어는 출시 후부터 초기 개발비용보다 약 4배의 돈이 더 드는 것으로 알려져 있다. 하지만 아키텍처가 부실하다면 4배가 아니라 40배의 비용을 더 들이고도 업그레이드 및 유지보수가 어려울 수 있다. 

그럼, '빨리빨리 문화'가 문제니 차근차근 천천히 개발을 해야 할까? 그건 전혀 아니다. 수많은 성공한 글로벌 소프트웨어 회사들은 천천히 개발을 해서 성공한 것이 아니다. 소프트웨어 개발의 최대 미덕은 소프트웨어를 빨리 개발하는 것이다. 소프트웨어 개발을 조금이라도 느리게 하는 모든 방법론, 규칙, 제약, 프로세스는 잘못된 것이다. 

'빨리빨리 문화'가 소프트웨어 개발을 오히려 더 느리게 하고 다른  문제들도 일으키기 때문에 문제라는 것이다. '빨리빨리 문화'는 소프트웨어 개발 프로젝트에서 다음과 같은 것들을 유발한다. 

-프로젝트 지식, 정보, 자료 공유의 부재 
-부실하고 확장성이 떨어지는 아키텍처 
-특정 개발자에게 종속됨 
-수많은 중복된 코드 
-개발자의 인간다운 삶과 성장 포기 
-점점 증가하는 유지보수 비용 

이런 현상은 개발 방법론과는 상관없이 벌어진다. SRS(Software requirements specification) 형태로 스펙을 제대로 쓰던 TDD를 하던 이는 모두 소프트웨어를 빨리 개발하기 위한 방법이다. 문서작성, 코드리뷰, 프로세스 등 모든 것은 소프트웨어를 빨리 개발하려는 것인데 이런 것들이 개발을 느리게 하니 그냥 개발하자고 하는 것은 완전히 착각이다. 

물론 이런 방법들이 소프트웨어를 빨리 개발하는데 도움이 되려면 뛰어난 아키텍트도 필요하고 회사의 개발문화 성숙도도 높아야 한다. 

빌딩을 빨리 만들겠다고 벽돌부터 서둘러 쌓아야 한다고 생각하는 사람은 없을 것이다. 기초공사와 설계가 잘되어야 어떤 방식으로든 빌딩을 빨리 만들 수 있다. 소프트웨어도 견고하고 확장성이 있는 아키텍처가 있어야 요구사항 변경에 대응이 잘되고 협업이 용이하며 개발 기간을 단축하고 비용도 절약할 수 있다. 

사실 무리한 일정 압박이 아키텍처에 큰 문제를 일으킨다는 것을 개발자 대부분은 잘 알고 있다. 그럼에도 '빨리빨리 문화'를 가속화시키는 주범은 따로 있다. 바로 경영자와 고객이다. 

대부분의 경영자에게 단기 성과는 생존 문제다. 회사 오너라면 조금 낫지만 많은 경영자들은 2년, 3년 단기 계약을 한다. 그 기간 안에 가시적인 성과를 내지 않으면 재계약이 어려워질 수 있다. 소프트웨어에 대한 깊은 이해도 부족하지만 미래를 고려할 시간은 더욱 없다. 6개월, 1년안에 성과를 내는 것이 가장 중요한 경영자는 영업이 가장 중요하고 단기 매출에 집착하며 아키텍처는 신경 쓸 여유가 없다. 

제대로 된 CTO가 있다면 CEO가 그렇게 마음대로 할 수는 없지만 우리나라에서는 CTO가 제대로 역할을 하기 어렵다. 

고객도 문제다. 우리나라 고객들은 이중적이다. 우리나라 개발사에는 버그를 당장 내일 고쳐줄 것을 요구하지만 글로벌 회사는 6개월 후에 고쳐주는 것을 고마워한다. 글로벌 회사는 아무리 얘기를 해도 빨리 고쳐주지 않는 다는 것을 알기 때문이다. 

우리나라 고객들은 개발자가 고객 회사에 들어와서 일해주기를 원한다. 스펙을 제대로 정리하고 효율적인 커뮤니케이션을 통해서 개발하는데 익숙하지 않기 때문에 옆에 앉혀놓고 종을 부리듯이 개발하기를 원한다. 

국내에서는 그런 고객의 입맛에 맞춰줘서 성공한 사례가 꽤 있다. 이런 문화는 국내 시장의 진입장벽이 되기도 한다. 그렇게 해서 우리나라에서는 1위에 등극했지만 이를 바탕으로 글로벌 시장으로 나아가는데는 큰 문제가 있다. 

개발문화가 비효율적이고 아키텍트의 역량이 떨어져서 세계 시장에서 패하는 경우가 많다. 그럼 외국 고객은 어떨까? 다는 아니지만 대부분 버그를 내일 고쳐 준다고 하면 의아하게 생각한다. 특히 매우 중요한 시스템이라면 이런 개발사의 신속한 대응은 오히려 개발사에 대한 신뢰를 떨어뜨리기도 한다. 

우리나라 개발사끼리는 이러한 고객 요구사항에 서로 잘 맞춰주겠다고 진흙탕싸움을 하고 있기 때문에 모두 다 힘들어지고 그 폐해는 고스란히 개발자에게 돌아간다. 개발자는 인간다운 삶을 포기해야 하기도 하고 그런 개발 환경에서는 개발자로서 성장하기도 힘들어진다. 

'빨리빨리 문화'가 바뀌기 어려운 것은 사실이다. 고객도, 경영자도, 개발자도 바뀌어야 한다. 내가 어떻게 세상을 바꾸겠는가? 하지만 세상을 바꾸는 첫걸음은 내가 바뀌는 것이다. 내가 바뀌는 것의 시작은 깨닫는 것이다. 지금은 당장 나만 바뀌면 나만 손해를 볼 것이다. 

하지만 내가 바뀌고 동료가 바뀌지 않으면 '빨리빨리 문화'는 영원히 바뀌지 않을 것이다. 회사에서 아키텍처의 중요성을 깨닫고 아키텍트를 키우고 영업과 개발의 균형을 유지하는데 노력하고 급하게보다는 제대로 빨리 개발하기 위한 방법들을 강구해야 한다. 

기반시스템, 방법론, 프로세스 모두 적절히 필요하다. 다른 여러가지 개발문화의 성숙도를 높여가는 것도 '빨리빨리 문화'를 고치는데 도움이 된다. 결국 우리가 바꿔 나가야 한다. 

'닭이 먼저냐 달걀이 먼저냐' 이슈와 비슷하지만 개발문화 성숙도 문제를 깨닫는 것만으로도 의미가 크다. 문화란 글이 아니라 경험을 통해서 배워야 하고 경험자에게 배워야 시행착오를 줄일 수 있다. 꾸준히 관심을 가지고 익히는 자세가 필요하다.

이글은 ZDNet Korea에 기고한 글입니다.