원글 : 왜 소프트웨어 개발은 예상보다 2~3배 더 오래 걸리는가?

소프트웨어 개발은 참 어렵다.

원글에도 나와있지만, 예상보다 늦어지는 경우가 대부분이다. 그것도 개발자들을 갈아 넣으면서…

속초에서 부산까지 걸어간다는 아주 명확하면서도 직관적인 문제 정의로 글을 이어나가서 소프트웨어 개발의 어려움과 빈번하게 생기는 문제 발생을 잘 은유하였다.

하지만, 사실 소프트웨어 개발을 해 본 사람이라면 이런 개발 과정의 어려움은 프로젝트 매니저(PM)의 단순한 경험 부족이라는 것을 알 수 있다.

만일, 부산에 도착한 뒤 거나하게 회 한상과 소주를 마시고, 다음날 속초까지 다시 걸어간다고 한다면 어떤 계획을 세울 것인지 생각해보면 된다.

이번에는 지도를 꼼꼼하게 살펴보고 일정을 짤 것이다. 충실한 계획과 충분한 일정을 잡아서 출발한다. 그러면 속초까지 도보여행은 계획된 일정에 맞을 가능성이 높아진다.

자.. 그러면 왜 소프트웨어 개발에 있어 예정된 일정보다 2~3배 늦어지는 인가?

사실 소프트웨어 개발에서 속초에서 출발해서 부산까지 도보로 걸어간다는 식의 프로젝트는 존재하지 않는다. 심지어 지도까지 주어지는 경우가 있을까? 이렇게 구체적이고 명확한 요구사항이 있는 경우가 없다.

소프트웨어 개발은 개발자가 취미로 뚝딱거리는 경우를 제외하고는 발주자가 있다. 이런 면에서 빗대어 보면 건축과 비슷하다. 설계와 시공을 하는 건축업자들이 건물을 올리는 경우는 거의 없다. 대부분 건축 의뢰인이 있는 것과 같다.

건축은 땅과 의뢰인의 요구사항으로 시작한다. 대지 50평에 단층 건물로 3식구가 살 30평 주택을 건축해 주세요. 이정도가 의뢰인의 요구사항이라고 하면, 먼저 설계도면을 만든다.

디자인과 건축 자재를 고려해서 목조주택, 벽돌조 주택, 콩크리트 주택, 스틸 골조 주택, 컨테이너 주택 등이 재시될 것이고 의뢰자와 상담을 통해서 요구사항을 확인한다.

방은 몇개가 필요한지, 화장실의 갯수와 형태는 어떤지, 주방과 거실은 분리할 것인지, 창문의 갯수와 크기는 어떨지, 집의 방향은 남향인지 등등..

요구사항에 맞춰 설계를 진행한다. 다양한 설계도면이 나오고 의뢰자와 상담을 해서 결정한다.

설계도면에 따라 땅파기, 기초공사, 골조 올리기, 인테리어, 조경 순으로 건물을 건축하게 된다.

이 과정중에 의뢰인의 마음이 변하여 요구사항을 바꾸면 어떻게 될까?

기초공사를 마치고 골조를 올리고 있는데.. 갑자기 주택을 2층으로 만들고 싶어요 라고 한다면 과연 수용이 될까?

목조 건물을 거의 다 만들었는데.. 요즘 콩크리트가 유행이라고 건물 외벽만 콩크리트로 바꿔달라면 그렇게 시공이 될까?

아마도 건축업자는 절대로 안된다고 할 것이다. 만일 2층으로 건축하려면 설계부터 다시 해야 한다고..

자.. 소프트웨어 개발로 돌아가자.

소프트웨어 발주자도 뭔가 생각이 있을 것이다.

처음에 사내 직원들간의 소통을 위한 메신저를 만들어 달라고 한다.

기존의 슬랙, 잔디, 텔레그램 등의 상용제품이 있지만, 그것들로는 해결되지 않는 모호한 기능이 필요하다고 한다.

사용자 수는 어느정도 인지, 전송할 수 있는 파일 최대 크기는 어느정도인지, 주고받은 메시지는 언제까지 저장해야 하는지, 메시지를 검색할 필요가 있는지, 소통을 하는 그룹의 형태는 어떠한지, 관리 권한은 어찌할 것인지.. 등등 수 많은 구체적인 요구사항을 확인한다.

스크래치부터 개발할 수도 있지만 대부분 요구사항을 수용할 수 있는 프레임워크, 라이브러리를 활용해서 개발한다.

요구사항을 확인해서 데이터베이스는 nosql 방식의 Cassandra를 사용하고, 모바일 앱 개발은 Flutter를 선택한다.

기반 프레임워크 기능을 확인하고 개발 환경을 확정한다. 상세설계서가 작성되고 테스트 목록도 작성이 된다.

자 이제부터 개발 시작이다. 이때, 발주자에게 6개월이면 개발할 수 있어요. 라고 말 할 수 있다.

3개월 동안 열심히 소프트웨어 개발을 해서 메시징 시스템의 몇가지 기능은 시범적으로 동작을 하기 시작한다. 아주 심플한 기본 화면에 문자들이 주고 받아지고 있는 것이 화면에 보인다. 가끔 에러를 내뿜고 죽기도 하지만, 기능 검증은 할 수 있는 상황이다.

발주자가 개발 진행사항이 궁금해하여 테스트 버전을 보여준다.

이제부터가 시작이다.

발주자의 표정이 좋지 않다. 내가 생각한 소통은 이런 것이 아니었다고 말한다.

문자 주고 받는 것은 카카오톡으로 되는데.. 이걸 왜 개발하고 있냐고 한다. 요구사항 검토때에 이미 예시 화면을 몇 번이나 보여줬었다.

발주자의 말을 다시 잘 들어보니.. 요즘 메타버스가 유행이란다. 귀여운 3차원 캐릭터가 화면에서 돌아다니고 서로 대회도 나누는 것이 원했던 것이라고 한다.

프로젝트 매니저는 당황한다. 아.. 메타버스 플랫폼으로 바꾸겠습니다. 라고 개발 계획을 확 바꾼다.

개발하고 있던 플랫폼에 유니티 프레임워크를 올린다.

문제는 개발자 중에 유니티에 익숙한 사람이 없다. 급하게 유니티 개발자를 수습해서 기존 개발 내용을 넣어서 통합할 것인지 고민을 한다…

한 달 동안 유니티와 메시징 시스템을 통합해서 화면에서 3D 캐릭터가 돌아다니고 서로 채팅을 할 수 있게 된다.

화면에 보이는 캐릭터의 모습은 모두 똑같다. 캐릭터 디자인에 신경 쓸 시간이 없다.

이미 개발자 2명은 몇 일동안 집에도 못가고 밤샘 작업 중이다. 개발팀 내에서는 대화가 사라진지 오래다.

발주자가 갑자기 찾아왔다. 똑같이 생긴 캐릭터가 돌아다니는 화면을 보더니 또 표정이 않좋다.

내가 원한 것은 이런게 아닌데…

요즘 인공지능으로 캐릭터가 말도 한다던데.. 뭐라드라? GPT3 라던가?

….

과연 이 소프트웨어 개발 프로젝트가 끝나기는 할 것인가?

소프트웨어 개발 프로젝트 기간이 예상보다 2~3배 늦어지는 이유는 요구사항이 계속 바뀌기 때문이다.

원래 속초에서 부산까지 보도여행이었다면, 그대로 진행되면 된다.

중간에 바다를 건너는 수영을 하거나, 비행기에서 낙하산을 들고 뛰어내리지는 않아야 한다.

그래서, 경영자가 소프트웨어를 알아야 한다. 좀더 나아가면 인공지능 기술을 알아야 한다.

엉뚱한 경영 선택 실수를 하지 않으려고 한다면…

첨언1. 소프트웨어 개발 관련 은유법을 썼는데.. 이해가 안된다면 다시 건축 비유로 돌아가자. 건물을 다 지었는데.. 의뢰자가 건물을 약간.. 10cm 정도만 왼쪽으로 옮기자고 한다면 어쩔 것인가? 소프트웨어 개발에서는 비일비재하다.

첨언2. 원글은 Quora 의 영문을 한글로 번역하면서도 적절한 은유와 예시를 들어서 한국인 성인이라면 잘 이해할 수 있게 쓴 글이다. 존경한다.