지인이 트위터를 통해서 SKT가 아이폰을 도입하지 않은 이유라는 기사를 알려 주었습니다. 기사를 읽어 봤는데, 기사에 이런 말이 나오더군요.
SK텔레콤 내부에서는 ‘6개월이면 국산이 아이폰을 따라 잡는다’, ‘다른 스마트폰으로 차별화한 전략을 가져가자’ 등의 목소리가 힘을 받았다.
SKT는 삼성과 잘 공조해서 갤러시S를 런칭했고 아이폰의 공습을 잘 막아냈죠. 하지만 지인은 이 기사를 읽고 다른 점을 지적했습니다. 즉 이런 시각이 소프트웨어 개발을 쉽게 생각하는, 변하지 않는 IT업종의 관점이라고 말하더군요. 지인의 말에 수긍이 갔습니다. 특히 하드웨어 개발이나 도입에 익숙한 경영자들은 소프트웨어 개발을 참 쉽게 생각합니다. 쉬운 일일 수도 있고 쉽지 않을 수도 있죠. 그런데 경영자들은 왜 이런 시각을 갖게 되었을까요?
전 그 이유를 이렇게 생각합니다. 하드웨어에 익숙한 경영자들이 소프트웨어도 하드웨어처럼 쉽게 개발할 수 있는 일상품(Commodity)이라고 생각하는 데, 이런 인식의 뿌리가 있지 않을까요? 그런데 경영자들은 소프트웨어도 하드웨어처럼 개발할 수 있다고 생각하게 되었을까요?
source: 그 원인은 트위터에서 지인과 나눈 이야기로 정리해 보겠습니다. 소프트웨어의 특성인 비가시성 등이 일상품(Commodity)로 가게 하는 데 어려움이 있습니다. 우리가 소프트웨어 엔지니어링이라고 부르는 게 과연 공학인가란 측면이 있죠. 제가 최근에 번역한 ‘고약한 문제 합당한 해결’이란 책에서 이점을 깊이 파고 드는데요.
소프트웨어 엔지니어링은 공학이기보다 공학이고 싶은 우리 분야의 열망 내지는 기예(Craft)라고 합니다. 사실 공학이라 부를려고 하면 공학이 의지하는 과학이 있어야 하는데요. 전산과학이 과연 소프트웨어 엔지니어링의 근본원리를 제공하냐 하면 그게 의문입니다.
소프트웨어 개발 시 알고리즘, 자료 구조, 이산수학… 이런 걸 차용하는데요. SWEBOK이란 소프트웨어 엔지니어링 체계를 보면 이런 것들이 논리적 근거로써 충분하지 않다는 점이 있습니다. 예를 들어 요구사항 관리에서 한 문장에 하나의 요구사항만 적으라고 하는 게 일종의 원칙인데요.
이게 경험적으로 맞는 것 같은데, 이 원칙(?)이 왜 합당한지 설명해 주는 백그라운드가 없죠. 응집성을 높이고 결합도를 줄여라도 설계의 원칙인데 이것에 대한 백그라운드가 무엇인지도 의문이죠. 제가 ‘고약한 문제 합당한 해결’의 역자 서문에서 언급했듯이 소프트웨어 관련 기술이 눈부시게 발전했지만요. 소프트웨어 엔지니어링이 다른 공학과 완전히 같은 수준이라고 언급하기에 어려운 점이 있는 것 같습니다. 물론 언젠가 그렇게 되겠죠.
소프트웨어 엔지니어링이 공학에 가까운 그 무엇이고 우리도 그렇게 이야기하는 데에서, 경영자와 소프트웨어 엔지니어와 간극이 생기는 것 같습니다. 즉 경영자 입장에서 소프트웨어 엔지니어링이 공학이면 소프트웨어도 공학적 원리를 적용해서 일상품(Commodity)화할 수 있지 않냐인데, 여기서 현실과 이상, 그리고 열망 사이에 괴리가 있고, 결국 하드웨어 공학적 접근법에 익숙한 경영자가 몇 개월이면 소프트웨어의 역량을 극복할 것이라는 경영적 의사결정의 오류를 보이게 되죠. 경영자의 잘못된 의사결정에, 어떻게 보면 우리도 공범자일 수도요.
그렇다면 소프트웨어 공학이란 무엇이냐,는 의문이 드실 겁니다. 이것에 대한 제 생각을 조금 더 말씀드리자면요. 사실 소프트웨어 개발은 기예라고 폄하하기에는 그렇고, 그렇다고 공학을 넘어서는 그 무엇이라고 하기에 어려운 게 있습니다. 특히 콘웨이의 법칙이라고 하는 게 있죠. 4개의 팀으로 나눠서 컴파일러를 개발한다면 4단계로 나뉘는 컴파일러가 만들어진다는 것 말입니다. 이점 때문에 아키텍처를 잡을 때 아키텍처를 개발할 조직을 고려하지 않으면 아키텍처가 제대로 구실을 못하죠. 이런 걸 생각하면, 사회 공학적인 측면도 있고요.
그리고 소프트웨어에 있는 비가시성 때문에 큰 조직에서 여러 조직에 걸쳐 소프트웨어를 개발한다면, 의사소통 채널에 대한 강력한 통제와 리더십으로 개발을 이끌 아키텍트나 프로젝트 관리 조직이 필요한데, 이런 것은 사실 하드웨어적 공학과 조금 다른 문제죠. 이런 소프트웨어의 경계인으로서 측면이, 어려운데요. 이런 것을 소프트웨어 공학이라는 말로 담아내다 보니, 우리는 경영자와 의사소통하기 참 어려워지는 것 같습니다.