개발자 여러분~ 문서 만들기 싫죠?

흔히들 소프트웨어를 개발하는데 문서를 만드느라고 시간이 더 오래 걸린다고 생각합니다. 문서가 필요한 것은 알고 있는데, 만들기는 싫다고들 합니다. 이러한 생각을 깨기 전에는 문서의 필요성에 대해서 이해하기가 어렵습니다. 

소프트웨어를 개발하는데 문서를 만들어서 더 오래 걸렸다면 잘못된 것입니다.

필요도 없는 문서를 잔뜩 만들고 있거나, 문서를 작성하는 실력이 없어서 낑낑대고 시간만 잡아먹는 경우 일겁니다. 두번째 경우야 그러면서 실력이 늘 수도 있지만, 필요 없는 문서를 잔뜩 만들고 있다면 정말 헛고생하고 있는 겁니다.

문서를 만드는 이유는 소프트웨어를 더 빨리 만들기 위해서 입니다.

거꾸로 문서도 안 만들고 어떻게 더 빨리 만들 수 있냐고 반문하고 싶습니다.

모든 내용을 머리 속으로 모두 기억하고 있다?
2명 이상이 개발을 할 경우 모든 정보는 대화로 공유하나?
모든 것을 혼자서 결정할 수 있나? 리뷰는 안 하나?
이런 궁금증이 생깁니다.

결론은 혼자 모든 것을 마음대로 결정해도 좋고 

협업 없이 혼자서 개발을 하고
천재일 경우는 가능하네요.

이런 경우가 아니라면 크든 작든 문서가 필요할 것입니다.

간단한 문서만 있어도 되는데 장황하게 많은 문서를 만든다면 오히려 이것이 잘못된 것일 겁니다.

충실하고 자세한 문서가 필요한데 문서가 없거나 너무 간단하다면 개발이 더 오래 걸릴 겁니다. 

이 판단이 프로젝트마다 다르다는 겁니다.

그래서 모든 프로젝트에서 기계적으로 모든 문서를 만들어내라고 하면 비효율적이 아닐 수 없습니다. 그리고 이를 프로젝트 기간이나 투입인원에 따라서 또 기계적으로 정할 수 없는 노릇입니다. 결국 경험 있는 프로젝트 팀에서 결정할 일입니다.

프로젝트에 꼭 필요한 문서를 최소한으로 만들고 유지하는 것이 올바른 방법입니다.

Track me, if you can

"요구사항 추적"이라는 말을 들어 보셨을 겁니다.

요구사항, 기능, 컴포넌트(클래스), 파일, 함수들의 연관관계를 추적하여 특정 요구사항에 관련된 컴포넌트나 소스코드들을 추적하고, 거꾸로 함수가 바뀔 때 이 변경에 영향을 받는 요구사항을 알아낼 수 있습니다.

왠지 근사해 보입니다.

실제로 요구사항을 추적하려고 노력하는 회사를 종종 보게 됩니다. 하지만 요구사항을 추적할 필요도 없는 작은 소프트웨어이거나 엉터리로 하고 있는 경우가 대부분입니다. 아니 100%입니다.

요구사항 추적이라는 것이 말만 근사해 보이지, 대부분의 역량으로는 거의 불가능합니다. 또 요구사항 추적툴 없이 엑셀파일에 끄적거려서는 할 수 없는 일입니다. 

요구사항 추적은 사람의 생명을 다루는 소프트웨어이거나 엄청난 비용과 테스트가 불가능한 우주선을 만들 때나 사용하면 됩니다. 이 경우는 감히 비용대비 효과를 논하기가 어려우니까요.

우리가 접하는 대부분의 소프트웨어는 요구사항 추적이 필요 없습니다. 실제로 요구사항 추적이 대단히 어려울 뿐만 아니라 요구사항 추적을 해서 얻는 것이 별로 없습니다. 요구사항 추적을 해보신 분들은 아시겠지만, 실제로 어설픈 문서라도 만들어 놓고 써본 적도 별로 없을 겁니다. 또, 요구사항이나 컴포넌트가 변경이 되어도 요구사항 추적 문서를 갱신하는 것은 대단히 어렵습니다. 오히려 방해 요소가 됩니다.

대부분의 소프트웨어는 요구사항 추적을 하지 않아도 별 문제없을 만큼 작거나 테스트로 충분히 커버가 됩니다.

단 하나, 고객이 요구사항 추적 문서를 꼭 원할 경우 설득을 해보고 안되면, 엉터리 문서라도 만들어 주는 것이 좋겠죠. 이때는 어차피 요구사항 추적 문서를 활용하기 위한 것이 아니니 최소한으로 간단하게 만드는 것이 좋을 겁니다.

이렇게 문서를 꼭 만들어야 하는 상황이 아니라면 근사해 보인다고 괜히 요구사항을 추적해볼 필요는 없습니다. 추적한다고 추적이 되는 것이 아니니까요. 그런 노력을 테스트를 제대로 하는데 들이는 것이 훨씬 더 효율적입니다.

과거의 개발자 vs. 미래의 개발자

개발자는 2가지의 상반된 가치를 가지고 있습니다.

하나는 과거의 가치
또 하나는 미래의 가치입니다.

"이 사람들 나가면 과거에 개발해 놓은 것 어떡하지?"라는 생각이 들면 과거의 가치를 가진 개발자이고

"이 사람들 나가면 미래에 개발은 누가 하지?"라는 생각이 들면 미래의 가치를 가진 개발자입니다.

과거의 가치를 가진 개발자들은 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식은 머리 속에 있기 때문에 자신이 과거에 만들어 놓은 소프트웨어를 인질 삼아서 회사와 인질극을 벌이고 있는 것과 같습니다. 이렇게 된 원인이 상당부분 회사에 있다고 하더라도, 개발자의 가치는 인질범과 별반 다를 바가 없습니다. 기존 소프트웨어를 망칠까봐 대우해줄 수 밖에 없습니다.

미래의 가치를 가진 개발자들은 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수 할 수 있도록 충분히 문서화를 해 놓았고, Peer review를 통해서 이미 많은 지식이 전달된 상태입니다. 이러한 개발과정을 거쳐서 본인은 분석, 설계 능력을 더욱 향상시켰고, 신기술들에 대한 연구에 집중하여 미래에는 과거의 제품들 보다 한 단계 높은 수준의 제품들을 만들어 낼 것입니다. 이러한 개발자들이 진정한 영웅이라고 할 수 있습니다.

인질범이 되겠습니까? 영웅이 되겠습니까? 이는 본인의 의지에 달려있습니다.

안타까운 것은 고참 소프트웨어 개발자 중에는 영웅보다 인질범이 더 많다는 겁니다. 물론 이 개발자가 인질범과 다를바가 없다는 것을 본인도 모르고 회사도 모르는 경우가 태반이지만 말입니다.

개발자들이 바글바글한 외딴섬에 떨어진다면

개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까?

Language 기초를 다시 가르칠까요?

UML을 가르칠까요?
문서 작성법을 훈련 시킬까요?
개발방법론을 가르칠까요?
팀워크를 키워줄까요?
OOP를 가르칠까요?

어떻게 하시겠습니까?

나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 

즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement engineering을 제대로 알고 잘 작성한 스펙문서는 별로 접해보지 못했습니다. 또한 그로 인해서 프로젝트나 제품에서는 수많은 문제들이 야기되고 있었습니다.

물론 스펙을 제대로 쓰기만 한다고 소프트웨어를 잘 개발할 수 있는 모든 준비가 된 것은 아닙니다. 스펙을 쓰는 것은 이제 소프트웨어 제대로 된 소프트웨어 개발에 한 걸음 내디딘 것 뿐입니다. 거꾸로 스펙도 쓰지 않고 소프트웨어를 어떻게 개발하냐고 반문할 수 있습니다. 즉, 무엇을 개발할지도 모르고 여럿이서 소프트웨어를 어떻게 개발하냐는 것입니다. 또 영업이나 고객은 정확하게 무슨 제품이 나올지도 모르고 기다리냐는 것입니다.

하지만, 이에 대한 반론을 얘기하는 사람도 꽤 됩니다. 기존에 제대로 된 스펙 없이도 훌륭한 제품을 많이 탄생했고, 성공한 제품도 꽤 된다고 얘기합니다.  물론 예외는 항상 있습니다. 저도 몇몇 그런 사례를 알고 있습니다.

정확하게 따지면, 그렇게 성공한 제품은 별로 많지는 않습니다. 그리고 초창기에 제품의 크기가 작거나 고객 수가 작을 때는 멋진 제품이었으나 매출이 늘고, 소프트웨어 규모가 커지면서 망가진 제품도 꽤 많습니다. 즉, 스펙의 부실로 혼동에 빠져서 실패한 제품이 꽤 됩니다.

제대로 된 스펙도 없는 제품이 성공할 확률은 잘 작성된 스펙을 토대로 개발하고 유지보수 되는 제품의 성공확률의 1/10도 안될 겁니다. 

소프트웨어 개발자라면 스펙이 왜 중요하고, 스펙을 잘 적기 위해서 배우고 많은 노력을 기울여야 한다는 것을 알아야겠습니다.

PS) 가끔 우리나라가 소프트웨어 업계에서는 섬처럼 느껴지곤 합니다.

개발자는 억울하다.

회사에서 제대로 배우고 성장할 기회를 갖지 못한 채 혼자서 북치고 장구치고 밤새가면서 개발하여 회사를 성장시켜놨는데 이제는 골치덩어리 개발자가 되어 버렸습니다.

이제는 문서도 안 만들고, 프로세스도 지키지 않으며, 정보를 꽉 쥐고 내놓지 않으려는 "꼴통개발자"로 보이기 십상입니다. 실제로 한참 후배들은 그런 고참개발자를 "꼴통" 또는 "철밥그릇"이라고 부릅니다.

당장은 그런 고참 개발자가 없으면 회사가 안 돌아 갈 것 같으니까, 잡아두고 있지만, 프로세스를 정비하고 시스템을 구축하여 정보가 공유되고 후배들이 그들을 대신할 수 있으면 언제 든지 내쳐질 것 같습니다.

살기 위해서는 소스코드와 업무지식을 내 놓지 않고 꽉 쥐고 있어야 하는데, 점점 쉽지 않아집니다.

이렇게 된 가장 큰 이유는 회사의 소프트웨어 개발에 투자가 필요하다는 것에 대한인식 부족 때문입니다.

소프트웨어 회사는 개발자들이 알아서 제품 만들고 영업이 팔고 그렇게 하면 쉽게 운영이 될 것 같지만, 소프트웨어 회사들이 갖춰야 할 기본 체계와 투자를 해야 한다는 것을 모르고 있는 것 같습니다. 사실 개발자 혼자라도 얼마든지 제품을 만들어 낼 수 있습니다. 그래서 너무 쉽게 보였는지도 모릅니다. 즉 겉으로 보여지는 모습만 보고 소프트웨어를 제대로 개발하고 개발자들을 훈련시키고 성장시키기 위해서는 얼마나 많은 투자를 해야 하는지 모르는 겁니다.

그 결과 회사는 외형적으로 성장을 했는데, 개발자들은 성장하지 못하고 커진 회사의 외형을 뒷받침을 못하니 천덕꾸러기 개발자가 되고 맙니다. 원래 회사는 적절한 시기에 적절한 투자를 꾸준히 해 나가야지 경기가 안 좋다고 잠시 미루고 매출이 떨어졌다고 잠시 미루고 이렇게 투자의 시기를 놓치면 그 손해는 배가 됩니다. 개발자들에 대한 교육 및 회사의 개발 체계에 대한 투자가 늦어지면 손해가 배가 아니고 몇 갑절이 될 수도 있습니다. 반대로 적절한 시기에 개발자들을 교육하고 성장시키면서 회사의 개발 시스템을 발전시켜나가면 몇 배의 성장도 할 수 있습니다. 

물론 이러한 투자가 성공을 담보하지는 않습니다. 적어도 비즈니스적인 성공의 발목을 잡지 않게 됩니다. 지금도 수많은 소프트웨어 회사들이 내부의 개발 실패와 비효율적인 개발 시스템으로 발목을 잡히고 있습니다. 그러면서도 개발이 잘못되고 있다는 것을 쉽게 알아차리지 못하고 있습니다. 늦었더라도 내부에 대한 투자를 멈추면 안됩니다.

커뮤니케이션 오류

소프트웨어 프로젝트를 진행하다 보면 수많은 커뮤니케이션의 오류를 발견하게 됩니다.

문서화 되지 않은 수많은 의견과 결정들에 대한 오해와 대화를 하면서 발생하는 표현의 오류는 한 두개가 아닙니다. 이는 비단 프로젝트에서 뿐만 아니라 일상생활에서도 벌어지는 현상이지만, 일상생활에서의 커뮤니케이션 오류는 그렇게 심각하지 않을 수 있지만, 프로젝트에서의 커뮤니케이션 오류는 심각한 손실을 초래하기 때문에 조심할 필요가 있습니다.

따라서 프로젝트를 진행하면서 오가는 대화나 기록은 명확해야 합니다. 미사여구보다는 직설적인 화법으로 핵심을 정확하게 말해야 합니다. 또 하나의 문장은 사실, 의견, 추축, 가정, 결정 또는 정보일 수 있습니다. 그런데, 현재 하고 있는 말이 사실인지 의견이지 명확하게 하지 않으면 수많은 오해가 발생합니다.

특히, 의견이나 추측을 사실처럼 얘기하면 다른 사람들은 이를 바탕으로 계획을 세울 수도 있습니다. 또 경영진은 잘못된 결정을 내려서 큰 손해를 보게 될 수도 있습니다. 그리고 가정으로 이미 확인된 사실처럼 얘기하면 프로젝트는 큰 리스크를 안게 됩니다. 

따라서 프로젝트에서는 구체적으로 가정과 종속관계를 파악하는 활동을 하게 됩니다. 프로젝트를 진행하면서 확인되지 않은 사실이나 결정해야 할 것들 및 종속되어 있는 항목을 찾아서 리스크관리를 해야 하기 때문입니다. 이러한 하나하나가 프로젝트의 리스크라는 것을 생각하지 못하면 지뢰밭을 걷는 것과 같습니다.

이러한 커뮤니케이션 오류를 제거하려면 이 문장이 사실인지 의견인지를 정확하게 구분하여 적는 것이 좋습니다. 특히 누구의 의견이라고 적을 수도 있고, 누구의 결정이라고 표현할 수도 있습니다. 그리고 가정은 언제 확인하고 해결이 될지 계획까지 적는다면 누구나 해당 내용이 확인이 필요한 가정사항이고 상황에 따라서 프로젝트의 위험 요소라는 것을 쉽게 파악할 수 있습니다. 이렇게 직설적이고 확실한 표현이 삭막하게 들릴 수는 있지만, 프로젝트를 진행하는데 있어서는 더 좋은 표현법입니다.

연인에게 이러한 표현법은 안되겠지요? 

당신을 사랑하는데 이 표현이 사실, 의견, 추측, 가정 또는 결정일까요? 이를 구분해서 말한다면 따귀맞기 십상이겠네요.

이거 팔면 돈 되겠는데!

오래 전 여러 기업을 거느린 그룹들이 기가 막힌 아이디어를 생각해 내게 됩니다.

여러 종류의 회사를 거느리고 있었고, 회사들의 전산시스템을 구축하였습니다. 

그 당시 여러 군소 회사들에 비하여 상당히 선진화된 MIS 시스템 등을 보유하게 되었고, 구축 과정을 통해서 경험 있는 소프트웨어 엔지니어들을 보유하게 됩니다.

물론 이를 구축하는데 돈을 많이 썼지요.

그러다가 문득 "이거 팔면 돈 되겠는데!"라는 생각을 하게 됩니다.

상당히 다양한 회사를 보유하고 있기 때문에 우리나라에 이와 비슷한 회사가 널렸다고 생각하고 이 소프트웨어를 조금씩 수정해서 팔면 큰 투자를 하지 않고 돈을 쉽게 벌 수 있을 것으로 생각합니다.

이러한 아이디어가 전세계 유래를 찾아보기 힘든 대형 SI회사를 탄생하게 만들었고, 우리나라의 비극적인 소프트웨어 산업구조를 초래한 시작이 됩니다.

일단 소프트웨어를 조금씩 수정하면 다른 회사도 쓸 수 있다고 생각한 것이 가장 결정적인 오류의 시작입니다. 애초에 그러한 확장성에 대한 개념도 없이 만들어진 소프트웨어가 그렇게 쉽게 다른 회사에서 사용될 수 있다고 생각한 것 자체가 그 당시 얼마나 소프트웨어에 대해서 무지했는가를 보여줍니다.

그 결과 소프트웨어 개발에 대한 전문성이 떨어지고 사업에 대한 전문성만 보유한 SI회사들이 대한민국 소프트웨어 산업계를 좌지우지 하면서 저가 수주의 온상이 되고 수많은 유망 소프트웨어업체를 사라지게 만든 장본인이 되었습니다. 다행히 SI회사와 시장이 겹치지 않는 회사들은 살아남았죠.

SI회사들이 이것이 돈이 안된 다는 것을 일찍이 깨달았지만, 특유의 생존력을 바탕으로 변화를 거듭해서 현재의 산업구조에서 살아남는 독특한 형태로 진화했지요.

지금은 소프트웨어 업계에 SI회사의 존재가 당연시 되는 기형적인 사고가 고착이 되어서 고객들도 SI회사가 없는 세상은 상상하지도 못할 겁니다. 이미 권력화된 SI회사의 파워는 이러한 기형적인 구조를 조금씩 개선해보고자 하는 법률의 개정도 가로막는 것이 문제가 됩니다. 실력으로 산업을 이끌어서 큰 회사나 작은 회사나 서로 Win-win을 해야지 힘을 이용해서 나만 살고자 하는 자세는 결국 대한민국의 소프트웨어 산업 자체를 고사시키고 말 겁니다. 

이대로 가다간 대한만국 소프트웨어 시장의 큰 파이는 외국업체에게 넘겨주고, 말 잘 듣는 공공기업의 치다꺼리나 하는 작은 파이만 먹게 되는 날이 오게 될 것입니다.

이미 소프트웨어 개발에 대한 Global 경쟁에서 뒤쳐진 대한민국 소프트웨어 산업의 미래는 암울하기만 합니다. 지금도 넘치는 아이디어와 혈기를 가진 똑똑한 소프트웨어 개발자들이 마구 배출되고 있는데, 그들을 받아들일 소프트웨어 산업은 척박하기만 하고, 그들에게 전해줄 알짜배기 경험을 전달해줄 선배 개발자들도 그리 많지 않습니다. 그 선배들도 그렇게 별로 배우지 못했으니까요. 이제는 유능한 인재들이 소프트웨어 업계로 오려고 하지도 않습니다. 나만 살자가 아니고 다같이 죽을 수도 있는 상황이 되었습니다.

SI회사의 변화를 기대하기에는 너무 늦은 것 같습니다. 그들은 그들 자체적으로 또 살아남기 위해서 진화를 거듭할 것입니다. 다만 다같이 공멸하지 않기 위해서는 Win-win도 좀 생각해달라는 겁니다. 

작은 회사들은 스스로의 활로를 모색해야 합니다. 시장을 피해 다니거나 외국으로 가거나 해야겠지요. 어느 하나 쉬운 것이 없지만, 어쩔 수 없죠. 이미 이렇게 되어 버린 걸요.