산업공학을 전공한 연구원/엔지니어지만, S(oftware)직군으로서 역할을 부여 받고나서 고민도 많고 공부할 것도 많아졌다.

그러던 중 우연히 추천 받은 스티브 맥코넬의 <Professional 소프트웨어 개발>. (국내 번역본의 제목. Professional만 유독 영어로 한 편집자의 의중을 모르겠음. 선물 감사합니다. 심정현 책임님!)

저자인 스티브 맥코넬을 간략히 설명하자면, S/W 유명서적인 <Code Complete>의 저자이자, 90년대 말미에는 빌 게이츠에 비견되던 S/W Guru 이다. 홈페이지 링크 (IEEE Software에 그의 글이 기고되던 시절 'S/W계의 앨빈 토플러'라는 별명이 따라다닐 정도였다고 함.)

<Professional 소프트웨어 개발>은 스티브 맥코넬이 IEEE Software 誌의 Best Practice 칼럼과 From the Editor 칼럼에 기고한 글을 묶어 출판된 의 개정판이다. 이 책은 초판이 2003년에 발행되었기 때문에, 급변하는 S/W 업계 입장에서보면 10년이나 된 '고전'이다. 모바일 SW 플랫폼이나 Facebook, Twitter 같은 Social Media 등에 대한 트렌디한 이야기는 없지만, 10년 전, 심지어 30년 전부터 해결되지 않은 S/W에 대한 편견과 개발 시의 문제점, S/W Engineering의 필요성, S/W 자격과 S/W 개발자 양성의 방법론에 대한 고찰은 '무당이 작두 타고 신들린 듯'한 통찰력을 보여줬다.

이 책에서 가슴에 콕콕 박힌 몇 부분을 정리해 보았다.

소프트웨어는 소프트하지 않다. 소프트웨어는 바꾸기 쉽다는 점에서 '소프트'하다고 알려져 있다. 그러나 소프트웨어 시스템이 점점 더 복잡해짐에 따라, 소프트웨어는 고치기 쉽다는 믿음은 소프트웨어 개발에 있어 오히려 해악이 되어버렸다. 유연성과 확장성을 고려하여 해결할 수 있는 범주를 넘어선 요구사항 변경이나 사양 변경이 당연하다고 느끼는 고객들이 이에 해당한다.

업계 연구원들은 같은 업계에서 경쟁하는 조직들 사이의 생산성에 10 대 1의 차이가 평균적으로 발생하고, 최고 600 대 1까지 차이가 난다는 것이 연구에서 밝혀졌다.

프로세스를 중시한다고 '사칭'하는 조직의 경우 우수한 조직을 본 받고 벤치마킹하는 것을 본인들의 사명으로 여긴다. NASA의 소프트웨어공학 연구실 같은 우수 프로세스 기반 조직을 조사하고, 짧은 관찰을 통해 이 회사가 엄청난 분량의 자료를 만들고, 회의를 자주 한다는 사실을 알아낸다. 프로세스 사칭 조직은 이들처럼 많은 문서를 많들고 회의를 자주해야한다고 주장한다. NASA의 소프트웨어공학 연구실에서는 문서와 회의를 특정 프로세스를 수행함으로 생기는 '어쩔수 없는 부 작용'이라고 여기고 있는데 말이다.

화물 숭배 소프트웨어공학(Cargo Cult S/W Engineering)을 하는 조직의 엔지니어는 "전부터 항상 이런 식으로 해 왔어!" 또는 "우리 회사 지침에서 이런 방식으로 하래."라는 말로 자신의 행동을 정당화한다. 일이 말이 되든 안되든 자신이 익숙한 방식으로 일하고 싶어하다. 왜? 그게 비효율 적이더라도 엔지니어 본인에게는 편하기 때문이다.

우리는 간혹 프로젝트가 성공, 실패 했을 때 프로세스가 어떠했는지, 책임자아 어떤 사람이었는지에 대해 긴 시간 논의한다. 어떤 스타일의 프로세스, 책임자가 중요한게 아니라 전체 개발자와 관리자의 능력 수준을 향상 시키는 길을 찾기위해 논의하고 시간을 쏟아야 한다. 그렇게 되면, 어떤 개발방식이든 누가 개발하든 상관없이 프로젝트 성공 확률은 올라간다.

소프트웨어 인력시장의 수요에 비해서 교육 인프라의 성장이 더딘 상황이기 때문에 최소한 과반수 이상의 소프트웨어 개발자가 소프트웨어 비전공자들로 채워져 있는 것이 현실이다. 이러한 상황에서 프로그래밍을 넘어선 컴퓨터 과학, 이를 뛰어넘는 소프트웨어 공학을 적용하도록 소프트웨어 개발자에게 '요구하지 못하는 상황'이 몇 년 째 지속되고 있다. 그들은 소프트웨어 공학 학부생 만큼의 전공 수준도 갖고 있지 않지만, 명함에는 소프트웨어 엔지니어라고 쓰여져 있다.

소프트웨어가 어려운 이유는 복잡성(Complexity), 일치성(Conformity), 변화가능성(Changeability), 비가시성(Invisibility) 때문이다.

나는 혁신적인 기술이 출현할 때마다, 그 때를 "소프트웨어 골드러시"의 시작으로 본다. 소프트웨어 개발은 고위험, 고수익이라는 특징이 있다. 하지만, 캘리포니아의 골드러시가 끝났듯, 이제 소프트웨어는 '새로움'만으로 승부할 수 없는 체계적이고, 위험도가 낮고, 자본과 노동집약적인 산업이 되었다. 얼마나 빨리 출시하느냐는 것보다 신뢰성, 조작성, 유용성에 더 역점을 둔다.

위에 정리한 Quotes외에도 전문적인 내용도 많고, 현황과 전망을 나타낸 여러 수치와 그래프들도 많이 포함되어 있었다.

 

개인 적으로는 S/W라는 것에 대해서 여러모로 이 책이 자극에 되어줬다. 아래와 같은 사람들은 꼭 봤으면 싶다.

  • S/W Engineering과 Computer Science의 차이가 뭔지 잘 모르겠는 사람.
  • Software 개발자, 프로그래머, 코더의 차이가 뭔지 잘 모르겠고, 본인이 어떤 포지션인지 헷갈리는 SW 업종 종사자
  • S/W Engineering Process가 왜 필요하고 중요한지 궁금한 사람
  • S/W 로 앞으로 계속 커리어를 쌓고자하는 사람

그나저나 30년 전이나, 지금이나 S/W 산업도 Top 5% 빼곤 다 거기서 거기라는 저자의 의견... 충격이다.

 

Fine. xthy.

 

[맨 위로]