소프트웨어 엔지니어링에 작별을 고하는 친구(?)의 글을 읽으며
공감 120%의 글이다. 제목은 Say Goodbye to Software Engineering (And Why Software Projects Never End) 직역하면 소프트웨어 엔지니어링에 작별을 고한다, 그리고 왜 소프트웨어 프로젝트가 끝이 없어야 하는지에 대하여
저자의 이름은 DZone 기사로 접했을 뿐 모르는 사람이다. 하지만, DZone 게시판에 나눈 필담[1]을 근거로 친구로 칭하기로 했다.
프로젝트는 언제 끝나는가?
싸이먼은 먼저 프로젝트 관리의 바이블 PMBOK를 인용한다.
"A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end." — PMBOK
그리고, 날카롭게 그 맹점을 설명한다. 프로젝트의 일시적인 특성으로 인해 명확한definite 시작과 끝end이 있다며 정의한 부분이 틀렸다는 주장이다. 나는 싸이먼에게 100% 동의하는 부류다. 그렇지 않는 이들도 있을 것이다. 아쉽게도 그들 대부분은 팝잇 구독자는 아닐 가능성이 높다. 대체로 학습하지 않는 이들, 관계가 내용보다 훨씬 중요하다 생각하는 이들, 다른 생각은 수용하기보다 배격하는 일이 익숙한 이들은 PMBOK 정의가 편안할 가능성이 높고, 그런 이들이 팝잇 구독자는 아닐 가능성이 높다.
싸이먼은 프로젝트가 명확한 시작과 끝이 있기 어렵다는 근거로 소프트웨어 프로젝트가 다른 엔지니어링 프로젝트와 다루는 대상이 달라 언제가 끝인지 눈에 보이지 않는다고 설명한다. 다리 공사가 끝났는지 여부는 누가 봐도 명확하지만, 연주가 언제 끝나는지 혹은 그림을 언제 완성이라고 할지는 직접 작업하는 이가 아니면 명확히 말할 수 없다는 사실을 근거로 풀어놓는다.
소프트웨어 엔지니어링이란 표현의 허점
글 말미를 보면 싸이먼은 소프트웨어에 엔지니어링은 어울리지 않는다고 결론짓는다. 그의 글을 통해 받은 영감으로 소프트웨어와 하드웨어 이분법을 새롭게 정의해본다. 기존에 엔지니어링으로 다뤘던 다른 모든 분야를 하드웨어라고 부르기도 한다. 그러면, 소프트웨어는 그들과 다르다. 싸이먼 말대로 물리적 법칙이 그대로 적용되지 않는다. 그래서, 엔지니어링 대상이 소프트웨어라면 다른 접근이 필요하다. 그 중 한가지 예는 전에 내가 쓴 글에 있다.
시스템은 유기체인데, (개발을 해보지 않은 그들은) 그 사실을 모른다
유기적인 측면에 초점을 맞추면 객체지향의 선구자 Grady Booch 역시 그의 저서에서 생물학 내용을 인용한 부분이 떠오른다. 세포증식의 오묘함. 반면에 싸이먼은 생물학보다는 음악과 미술(how about being a software composer? Or software artist?)이 소프트웨어 프로젝트에 더 어울린다고 보는 듯하다. 요즘 프로젝트 관리(혹은 제품 관리)를 하는 내 일상만 봐도 확실히 (공학적 직업인보다는) 연출가Producer에 가깝다는 인상을 받는다.
하여 싸이먼의 다음 결론에 나도 100% 동의한다.
The reason for this is simple: developing software is not engineering — or if it is, it’s a new type of engineering that needs new ways of controlling it.
다른 관점으로 풀어보기
이제 필자가 싸이먼과 다른 관점으로 같은 문제에 대한 다른 맛을 선사하겠다. 먼저 소프트웨어 분야는 상대적으로 신생분야다. 흔히 비유하는 분야가 건축인데, 피라미드와 만리장성이 만들어질 때 소프트웨어 분야에는 어떤 노하우가 있었을까? 말도 안되는 비교다. 소프트웨어 분야는 산업으로는 신생아에 해당한다. 반면에 비약적으로 성장하고 있어, 다른 세대의 사고를 하는 동시대인이 한 곳에 존재한다. 역동적인 대한민국에 촛불시민혁명세력과 자유(한국)당과 신군부세력이 같은 하늘에서 버젓이 숨을 쉬고 자기 이야기를 내어놓는 아이러니와 같은 현상이다.
전업 오픈소스 개발자가 있고, 원격으로 프로젝트를 해내는 사람들이 도처에 있는 반면에 대기업 CIO 대부분이 소프트웨어에 대해 완전무지에 가까운 현실이 공존하는 시대에 살고 있다. 100% 재택근무를 국경을 넘어서서 하는 일이 확산되고 있는 2018년이지만, 불과 며칠전에도 임원이 나서 솔루션 우선 無전략을 발표하는 민망하기 짝이 없는 일을 자랑스럽게 신문 기사로 내건 유명 기업이 있을 정도다.
정리하면, 소프트웨어 분야에서 점차 지는 해와 뜨는 해가 있다. 여러분이 만일 납기 준수가 소프트웨어 프로젝트에서 중요한 일이라 생각한다면 빨리 은퇴를 고려할 필요가 있다. 그리고, WBS를 사용하고 있거나 작업 항목을 엑셀로 관리하고 있고, 거기 완료일이 써 있다고 해도 마찬가지 결론을 내릴 수 있다. '차세대'라는 공룡이 아직 살아 있긴 하지만, 5년 후에도 지구상에 존재할지 확신하기 어렵다.
디지털 변신의 시작은 소프트웨어 흡수하기
비슷하지만 약간 다른 관점으로 동시대의 다른 세대 공존 현상을 설명할 수 있다. 디지털 변신 혹은 전환Digital Transformation이란 말을 들어보았는가? 위키피디아에 따르면, 디지털 기술 응용에 따른 모든 변화 양상을 말하는데 그게 쉽지 않기에 필자가 아래와 같은 시행착오기를 쓰고 있기도 하다.
방금 뽑은 소제목은 내가 쓰고도 마음에 쏙 든다. :)
디지털 변신의 시작은 소프트웨어 흡수하기
인터넷 기업이 아닌 전통 기업이라면 의례 외주 개발을 했다. 개발 전문 업체에 전산화를 의뢰했다. 전산화라는 말이 암시하는 바대로 사람이 할 수 있지만 전산으로 바꾸는 것이다. 수작업을 자동으로 한다고 해서 자동화라고 표현하기도 한다. 하지만, 지금도 그런가? 눈을 제대로 뜨고 세상을 유심히 살펴 보라. 당신의 데이터베이스 테이블과 조직이나 업계의 관계망 안에서 보지 말고...
이제 사람이 할 수 없는 전산 업무가 너무나도 많다. 방대한 레코드량 탓에 인간이 계산할 수 있는 범위를 넘어선 것들이 너무 많다. 그리고 요즘 자동화라고 한다면, 종이 대신 전산 입력을 하는 것을 말하기 보다는 손님이 직접 무언가를 할 수 있도록 모바일 화면이나 키오스크를 제공하는 셀프서비스를 말하는 경우가 더 늘고 있다. 아직도 눈치 못챈 사람들이 있겠지? 전통 기업의 일 즉, 업의 본질이 바뀌었다. 디지털을 흡수해야 한다. 디지털 공간과 기기 안에서 우리 업이 수행되는 방식은 소프트웨어라는 매개체를 통한다.
그런대도 외주 개발을 맡긴다는 의미는 무슨 뜻인가?
다음 5년 후에도 살아남는 방법
만일 여러분 회사 시스템이 전면 재구축(다른 말로 차세대 프로젝트)을 해야 하는 상황이라면 5년 이후에 여러분 회사가 업계에 남아 있지 못할 수도 있다고 생각하는 편이 좋다. 심각하다는 말이다. 최대한 빨리 시스템을 소비자(혹은 사용자)에게 디지털 경험을 줄 수 있는 방향으로 개선해야 한다. 리팩토링 해야 하고, 모든 처리를 모바일에서 할 수 있도록 전면 재고가 필요하다. 만일 그러기 위해서 안타깝게도 차세대를 해야 한다면 목표는 필자가 제시해 줄 수 있다.
차세대 프로젝트 안할 수 있게 차세대 프로젝트 하기
덤으로 혹시 납기 준수에 대한 필자의 비판에 의문이 드는 분을 위한 글이다. 필자가 완료 일자를 고무줄처럼 무시하자는 말을 하고픈 것은 아니다. 계획은 영어로 Plan과 Plannng으로 표현할 수 있는데, 의미는 꽤 다르다. 오래된 계획Plan을 그대로 지키려는 우물속 우직함보다 목표에 맞춰 그날그날 바뀐 상황에 대처하는 기민함Planning이 필요하다는 의미다. 애자일 옹호자들 사이에서 스프린트Sprint 같은 어휘와 회고가 쓰이는 이유로 부연할 수 있다. 목표를 위해 단거리 달리기처럼 힘껏 달려보고Sprint, 적절한 계획과 수행이었는지 재고Retrospection해보는 것이다. 자연스럽지 않나?
이 글을 통해 단 한분이라도 더 상식적으로 행동하는 소프트웨어 관련 인구가 늘기를 바라는 마음에 일부에게 상처를 줄 수 있는 글이겠으나 과감이 공개한다.
주석
[1] DZone 댓글에서 소통한 이력
https://dzone.com/articles/say-goodbye-to-software-engineering-and-why-softwa