소프트웨어공학은 한 나라의 소프트웨어 업계의 개발문화를 반영하고 있는 현실이다!

글로벌 소프트웨어를 꿈꾸다 ㅣ 글로벌 소프트웨어를 꿈꾸다 시리즈
김익환 지음 / 한빛미디어 / 2010년 9월

소프트웨어공학은 교과목 중에서도 이론이 특히나 어렵고 딱딱한 분야였다. 구체적이고 다양한 사례를 접하기 힘들었기 때문이었던것 같다. 소프트웨어 개발에 있어서 생산성과 효율성은 극대화하고 프로젝트 진행과정에 있어서의 리스크를 최소화하기 위한 방법론들이라 생각했다. 즉, 자료구조와 같은 학문으로 그 이론이 변하지 않는 분야라 생각해왔던 것이다. 그런데 이 책에서는 전혀 다른 관점을 제시한다. 소프트웨어공학이 한 나라의 소프트웨어 업계의 개발문화를 반영하고 있는 현실이라는 것이다.

한국에서 소프트웨어 개발자라고 하면 SI업체에서 십중팔구는 밤낮없는 프로그래머를 떠올린다. 프로그래머가 개발자의 전부일까? 아니다. 프로그래밍 실력은 기본기에 불과하다. 여러분은 평생을 프로그래머로 살것인가? 이는 벽돌공과정을 이수하고 건축가가 설계한 도면을 보면서 평생 벽돌을 쌓아서 건물을 짓는것과 다르지 않을 것이다. 한국에서의 소프트웨어 개발자는 수명이 짧다고들 한다. 왜 그럴까? 규모가 작은 기업에서는 간혹 분석, 설계, 구현을 한명의 개발자가 다하는 상황이 벌어진다. 슈퍼개발자이다. 가내수공업이다. 왜 이런현상이 비일비재할까? 혁신에는 고통이 따르지만 더 큰 성공과 생존을 위해서 반드시 필요하다. 필자는 이를 솔개의 모습을 예로 들고 있다. 문서는 무조건 작성해라. 단 정말 중요한 문서인 SRS는 모범적인 샘플은 없다. 국내의 소프트웨어 업계는 기피업종의 하나가 되었다. 왜 그럴까? 개발자의 평균연령도 20대나 30대에 불과하다.

소프트웨어 개발자라면 왜 이런현상들이 일어났고 주변에서 왜 그렇게 이야기 하는지 정답아닌 정답을 얻을 수 있습니다. 속시원한 해결책은 못줄 수 도 있습니다. 단, 경영자 측면에서는 적어도 프로젝트가 성공할 확률을 확실히 증가시켜줄 것 입니다.

이슈관리시스템과 소스관리시스템에 대한 많은 관심이 생겼다. 소스관리시스템은 고가의 상용제품도 있지만 오픈소스인 SVN도 있다. 대기업에서도 SVN을 사용한다. 나도 다른 프로젝트에 참여시 이클립스 기반에서 SVN을 사용했었다. 그당시에는 서버를 운영해 단순하게 소스파일들을 업로드 하거나 다운로드 받는 형태로 사용했다. 업로드시 변경사항이 있는지 두개의 소스파일을 자동으로 비교해주는 기능이 신기하기만 했다.
이슈관리시스템에 등록하는 이슈의 정의는 간단했다. 제품에 관해 회사에서 대화의 대상이 되는 거의 모든 것이다. 이슈는 매순간마다 끊임없이 발생하고 이러한 이슈를 항상 등록해야 한다. 이 이슈관리시스템은 초기도입 후 정착되기까지 적지않은 시간이 걸리지만 도입효과는 엄청나다. 과거 이슈에 대한 모든 데이터를 저장하고 있으며, 다양한 통계를 제공한다. 회의가 줄어들어 시간도 절약된다. 모든 임직원의 평가를 할 수 있는 중요한 데이터를 제공하며 대화, 모니터링과 간접결재의 기능도 제공하고 있다. 관리와 개발 모두의 위험요소가 줄어든다. 필터링 없이 모든 이슈가 등록된다면 쓰레기장이 될까? 전혀 그렇지 않다. 오히려 필터링이 정보의 손실을 가져온다. 또한, 경영자는 이슈관리시스템을 가끔 보고 댓글을 달아주면서 사용하면 된다. 이 효과는 놀랍다고 한다.

다음은 정말 중요한 내용들이다. 실은 책에 있는 모든 내용이 다 중요해보였다.
필자는 경영자에게 다음의 고정관념을 버리라고 하고 있다. 하드웨어 마인드를 버려라. 소프트웨어는 아무나 개발할 수 있다는 생각을 버려라. 관리자나 영업이 개발자를 좌지우지 하지 않게 하라. 빠른 개발의 경영전략을 버려라. 일정을 협상하지 마라. 2% 부족한 것을 간과하지 마라. 조급한 생각을 버리고 장기적인 해결책을 마련해라. 개발자에게는 자신의 마인드를 바꾸라고 하고 있다. 자신의 능력을 정확히 알고 행동해야 한다. 급할수록 천천히 가야 한다. 처음부터 제대로 배워야 한다. 항상 자신을 변화시키려고 노력해야 한다.
실리콘밸리에서 근무하는 소프트웨어 개발자의 직장 평균 재직기간은 2년이 안된다고 한다. 잦은 이직에도 회사의 운영에 영향을 미치지 않는다고 한다. 그러나 한국은 다르다. 핵심 개발자가 이직한다면 그 프로젝트를 포기해야 할지도 모른다. 즉! 인력 교체에 대한 준비가 항상 되어 있어야 한다. 그리고 개발자가 선수로서 잘 뛸 수 있도록, 개발에만 집중할 수 있도록 회사차원에서 많은 지원을 해주어야 한다. 결국 경영자의 통찰력과 판단, 회사차원에서의 지원이 절실하다는 것을 알 수 있다.
소스코드의 공유와 개발문서 작성을 피하는 것은 재앙의 시작이며 훗날 심각한 문제를 가져올 수 있다.
개발자가 되려면 사람관리를 하는 관리자는 하지 말라고 한다. 개발자의 권위는 기술력에서 나오기 때문이다.
경영자는 영업팀과 개발팀의 의견을 잘 조율해야만 한다. 그렇지 않으면 급하게 만들고 유지보수도 잘 안되는 최악의 제품이 탄생할 것이다.
정말 빨리 제품을 개발하고 싶다면 문서부터 만들어야 한다.
3-way 머지, 2-way 머지는 머지데이를 정해서 하지 말고 수시로 해라. 특히 3-way 머지는 완전 자동화가 가능하다. 두 코드가 충돌나는 경우에나 서로 의논을 해야 하므로 인간의 두뇌가 필요하다.
필자는 향후 10년간 IT업계의 핵심분야가 될 스마트폰은 소프트웨어 공학을 경험할 좋은 기회라고 한다. 모바일 생태계를 통제하던 이동통신사에서 그 힘이 플랫폼으로 넘어왔고, 플랫폼 힘의 원동력은 엔드유저를 위한 콘텐츠이다. 이 콘텐츠 개발은 소프트웨어 개발자가 주역이 된다. 이 특히 세계시장을 겨냥한 스마트폰 개발은 큰 규모는 아니면서도 여러 플랫폼에서 수많은 버전관리, 다국어 지원이 필수적이다. 이를 통해 소프트웨어 공학의 여러측면을 다양하게 경험할 수 있을것이라고 한다.

정말 기억에 남는 내용은 "대다수가 현혹 된 미신"이었다. 각 미신에 대한 상세한 해설은 정말 가슴에 와 닿는다.
경영진이 갖고 있는 미신 - 스펙 문서 작성하느라 개발일정을 못 맞추는 것이 아닙니까? 개발일정이 늦어지면 개발자를 추가로 투입하지요. 우리가 개발할 수 없으면 외주를 주도록 합시다.
고객이 갖고 있는 미신 - 자세한 요구사항은 나중에 정합시다. 소프트웨어의 좋은 점은 변경이 가능하다는 생각.
개발자가 갖고 있는 미신 - 빨리 코딩을 시작합시다. 그래서 빨리 끝냅시다.제품을 만들 때까지는 테스트를 못한다. 소프트웨어 공학을 적용할 시간이 없다.

IT산업을 소프트웨어 분야와 나머지 분야로 구분짓고 싶다. 정말로 독창적이고 가장 논리적이고 지식집약적이고 복잡한 분야이기 때문이다. 나는 개발을 불특정 다수가 사용할 예술작품을 완성하는 과정이라고 정의하고 싶다. 이책을 읽으면서 나의 꿈이 명확해 졌다. 스티븐잡스처럼 백발이 성성한 진정한 의미의 개발자가 되고 싶다. 어떤 제품이라도 전체 개발 프로세스를 이해하고, 코딩은 아르바이트생이 구현할 수 있을 정도로 프로그램 설계를 잘하고, 일하기 싫어하는 프로그래머도 즐겁게 일을 할 수 있도록 격려하는 프로젝트 관리자가 되고 싶다.

가까운 미래에 미국의 실리콘밸리에 정착된 개발문화가 한국에도 자리잡기를 희망합니다 :)