brunch

매거진 왜 우리 소프트웨어는 안나와요

라이킷 6 댓글 4

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Jinho Yoo Sep 16. 2016

‘소프트웨어 개발은 반복/반복/반복이다’ 이후

가슴 아픈 피드백들을 받아서 이에 대해 정리해보겠습니다.

이 글은 소프트웨어를 만들려고 하는 경영자, 정치인, 비영리 재단 등 소프트웨어 비 전문가들을 위해 쓰는 글입니다

글을 올린 이후 많은 댓글들이 몰려왔습니다. 우선 진심으로 감사드립니다. 인터넷에 올린 글을 이렇게 여러분들이 많은 관심을 가져주셔서 감사했습니다. 그리고 몇몇 내용들에 대해서는 업데이트를 해야 하는 부분이 있어서 이렇게 이어지는 글을 적습니다.

소프트웨어나 서비스의 경우 계속해서 업데이트를 해가면서 반복 개발해야 한다는 것이 핵심적인 내용이었습니다. 그리고 이 시리즈는 이른바 ‘사장님’, ‘기관장님' 보시라고 쓰는 글입니다. 그런데 정작 그쪽에는 잘 공유가 안 되는 분위기여서 안타깝습니다. 어찌해야 할지 아이디어 주시거나 관련된 분들에게 전달해주시면 참 감사하겠습니다.

일반 사연들에 대한 정리

우선 반복 개발을 할 수 없는 상황들에 대한 댓글들이 붙었습니다. 아래와 같은 경우입니다.

상황 1: 게임기 타이틀처럼 DVD나 ROM에 구우면 모조리 끝나는 경우. 특별히 Hardware와 같이 나가야 하는 Software의 경우에는 변경이 매우 어렵다.

상황 2: 고객이 정확하게 요구사항을 정확하게 설정하고 기간도 제한적이라 한 번에 성공해야 하는 경우. 레고처럼 잘 끼워 맞춰야 하는 경우가 없지 않다.

상황 3: 개발을 진행하다가 보면 ‘앗, 잘못 만들었다'하는 경우가 있다. 이럴 때 어떻게 해야 할까?

상황 1: 이런 경우에는 개발 와중에는 대부분 반복 일정 잡기를 합니다. 실제 게임이 돌아가는 것도 봐야 하고 또 QA도 해야 하기 때문에. 언제나 막판에는 QA에 집중합니다. 그렇게 문제들을 다 잡아 내고 출시합니다. 그리고 DLC (DownLoadable Contents)라는 방식을 이용할 수도 있습니다. 인터넷 서버에 계속 Update 할 수 있는 Contents 내용들을 다 올려놓고 정기적으로 Update 하는 방식이죠. 결국 이런 방법들이 나오는 이유가 반복 개발로 최대한 현장의 문제에 빨리 대응하기 위한 도구들입니다. 그리고 물론 개발팀원들의 역량이 아주 높아야 합니다.

참고: Google의 Firebase의 경우에는 이러한 상황을 대비하기 위해 원격에서 Configuration을 바꾸는 기능을 내장하고 있더군요.

상황 2: 의외로 이러한 경우가 많다는 이야기를 전해주던 지인이 있었습니다. 제 생각에는 행복하다면 행복한 경우라고 생각했습니다. 고객이 ‘왜-무엇을-어떻게'해야 하는지 다 알고 있다는 의미로 보였거든요. 제가 접해본 경우에는 이런 경우 대부분 ‘기한의 압박'이 있었습니다. 게다가 기한이 ‘비현실적'인 경우 대가도 크게 돌아오는 경우가 많았지만 행복하지는 않았었습니다. 성숙한 개발팀과 고객이 아니라면 쉽지 않을 것입니다. 그런데 문제는 미성숙한 개발팀과 고객이 만나는 경우입니다. (부들부들)

너무 쪼임당하면 '찐하게' 나오지만.... 힘들어요...

상황 3: 언제나 모든 일을 진행하다 보면 ‘의외의 상황'이 일어날 수 있습니다. 앞의 글에서 소프트웨어 개발은 일종의 ‘탐험'이라고 이야기했습니다. 즉 탐험을 하다 보면 의외의 경우를 발견할 수 있고 이에 대해서 마음의 준비를 해야 한다는 의미입니다.

만약 이런 상황을 만나면 아래의 사항들을 꼭 분석하고 모든 구성원들이 이에 대해서는 다 알고 있어야 한다고 생각합니다.

전체 개발 진행 이력을 점검해본다. 그 이력 중에 언제 모든 것을 다시 개발해야 한다라는 것을 알게 되었을까?

그 순간의 상황을 더 나눠보자. 어떤 일이 일어났을까?

그런 상황을 제일 처음 누가 제기했는가?

그 사람은 그 상황을 어떻게 알게 되었을까? 그 사람은 어떤 교육을 받거나 훈련을 받았기에 그러한 상황을 알 수 있었을까?

언제나 개발을 하다 보면 모든 상황을 다시 봐야 하는 상황이 꼭 벌어집니다. 처음에 파악한 상황과 완전히 달라지기 때문입니다. 이러한 변화에 대해 받아들일 준비를 하고 개발하는 것과 그렇지 못하고 개발을 진행하는 것은 큰 차이가 납니다. 시간을 이미 많이 버린 때일 수도 있지만 잘못된 설계를 계속 이끌고 가다가 더 힘든 경우를 당할 수 있다면 과감히 문제를 열어 놓고 이야기하는 게 맞습니다. 그렇게 할 수 없다면 제대로 된 제품이 나오기는 어려울 것입니다.

현실적으로 보면 Microsoft조차 핵심 기술을 몇 차례에 걸쳐서 ‘갈아엎기'를 했습니다. 대신 매 단계마다 ‘완결된 제품'을 출시했습니다. 그리고 갈아엎기를 했더라도 훌륭한 문서들과 예제들을 충분히 공급했습니다. 자금의 출혈은 있었습니다. 하지만 그 출혈을 감수하고라도 제대로 된 제품을 꾸준히 내어 놓은 덕에 1975년 이래 지금까지도 살아남았습니다.

사실 진화가 뭐 그런거죠......

'그들은 듣지 않아'

그러나 사실 이것보다 더 많이 가슴이 아팠던 댓글은 이런 것이었습니다.

그들은 듣지 않아요. 그게 한국식 매니지먼트입니다. 빨리 망작을 만들고 손 털고 나가고 ‘아몰랑'해서 챙길 것 챙겨야 하는데 그러지 말라면 말이 됩니까?

왜 이런 반응이 왔을까요? 왜 많은 사람들에게 한국의 조직장 들은 왜 저런 ‘괴물'로 불리는 것일까요? 사실 이것은 제 글의 범위를 넘습니다. 한 가지 확실한 것은 사람들이 이른바 '장'들에 대한 신뢰가 매우 낮다는 것입니다. 혹시 '장'이 되면 자신의 욕망을 실현하기 위해 조직을 마구잡이로 이용해도 된다고 생각하고 있기 때문이 아닐까요? 최동석 님의 ‘조직은 무엇을 위한 수단인가?’라는 글에는 아래와 같이 나옵니다.

우리는 지금 큰 오해를 하고 있습니다. 우리는 권력을 가진 지배자가 자신의 개인적 욕망을 실현하기 위해 조직 전체를 지배하는 것이 당연한 것으로 받아들이고 있다는 말입니다. 아주 잘못된 조직 인식입니다. 이 때문에 온 국민은 불합리한 제국주의적인 조직문화에 갇혀 버렸고, 속절없이 고통당하고 있습니다. 이제 우리는 조직운영 메커니즘을 완전히 뒤집어엎어야 합니다. 결론을 말씀드리면, 분권화된 자율적인 조직(Decentralized Autonomous Organization)으로 변화시켜야 한다는 말입니다.

지금 이 글을 읽는 조직의 장분들께서는 어떻게 생각하십니까? 사실 이 연재를 하겠다고 했을 때 제일 많이 들었던 말이 '그들은 듣지 않아'였습니다. 이 글을 읽으시는 독자 여러분 생각은 어떠십니까? 여러분의 모습은 어떠한가요?