brunch

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

라이킷 45 댓글 9

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Jinho Yoo Nov 08. 2016

없는 것을 만들었다고 하지 마세요.

진실하세요.

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

“어쩔 수 없잖아요”

대기권 밖으로 궈궈~~

개발자인지라, 그것도 이젠 업계에서 경력이 되다 보니 별별 엽기 천국(?) 같은 이야기들을 전해 듣는 일도 많습니다. 오늘 소개 드릴 일들은 OECD 최고의 사기범죄 공화국의 이름을 저버리지 않을 이야기입니다. 참고로 두세 곳의 사연을 섞어서 쓴 거니 오해하지 마시기 바랍니다.

회사 A는 이제 막 시작한 회사입니다. 다행히 큰 모회사를 가지고 있습니다. 그러나 무언가 일거리가 있어서 만든 게 아니라 모회사의 오너께서 `우리도 첨단인 OOO 분야를 해야 하는 거 같아서 'A를 만들었습니다.

자, 월급 등 비용이 매달 나가는 A사는 살기 위해 일거리를 찾습니다. 가장 좋은 건 이른바 '정부 프로젝트' 나 ’대기업 프로젝트 입찰'입니다. 그러기 위해서 입찰서를 쓰는데, 고객사에서 이야기하는 전체 프로젝트 수행 기간이 총 프로젝트 기간이 딱 3개월입니다. 솔직히 A에는 개발자가 딱 1명뿐입니다, 그것도 모 회사에서 파견으로 보냈습니다. 당연히 사람이 부족하니 모 회사의 다른 자회사 몇 곳에서 개발자들이 같이 일하는 것으로 서류를 꾸몄습니다.

이런 서류를 쓰면서 A사의 경영자들은 이렇게 말합니다. “아, 이거 어차피 서류 입찰되려면 이것저것 하면 6개월은 넘어, 그러니까 미리미리 써야지.”

그런데, 그것이 정말 이뤄지고 말았습니다. 정말 입찰이 된 것입니다. 게다가 "아니 이렇게 훌륭한 소프트웨어가 있었다니… 당장 혹시 데모를 다음 주에 보여주실 수 없으신가요?" A사 경영자들은 여태 얼굴도 제대로 보지 못한 그 한 명의 개발자에게 부랴부랴 달려갑니다. "개발자님, 드디어 우리 XX프로젝트에 입찰되었어요. 이거 다음 주까지 돼요?"

개발자는 황당해하면서 이렇게 말합니다. “네? 이런 거 한다고 저한테 한 번도 말씀 안 하셨잖아요? 세상에 우리가 이런 기술 다루는 회사였어요? 아니 이걸 어떻게 다음 주까지 해요?”, “아, 죄송해요. 어쩔 수 없잖아요, 먹고살려니까요. 대신 사람 몇 사람 더 붙여 드릴게요. 부탁 좀 드려요.”

그렇게 모회사에서 3명 정도의 개발자가 더 파견되어 왔습니다. 그리고 4명이서 같이 일을 하는데 정말 미친 듯이 야근을 하고 겨우 작은 데모를 보여줬습니다.

데모를 마치고 다음날 경영진들은 개발팀들에게 고맙다는 말을 하기 위해 자리로 찾아갔습니다. 그런데 아무도 없었습니다. 그리고 책상에는 '사직서'만 덩그러니 남아 있었습니다. 연락을 해보니 개발자들 모두 경쟁사에서 높은 연봉으로 데려갔습니다. 화가 나서 이 개발자를 고소하려는 찰나에 고용노동부 감독관이 와서 ’ 노동관계법 위반'을 조사하겠다고 왔습니다. ‘퇴직금 아직 안 주셨던데, 험한 꼴 보기 싫음 주시죠?’.

이제 남은 기간이 얼마 없어서 새로 개발자를 채용하고 과거에 만든 코드와 자료를 이관하려고 했습니다. 그런데 새 개발자가 청천벽력 같은 소리를 합니다. “이거 내용 하나도 없고 그냥 화면만 짠 거예요, 게다가 그 짠 것조차 못 알아보게 되어 있어요. 이거 누가 짠 거죠? 다 다시 짜는데 제가 분석해 본 결과 1년 이상이 걸립니다.”, “안돼요, 마감이 2달 남았다고요!!”, “안녕히 계세요. 이런 말도 안 되는 곳인 줄 몰랐네요.” 이제 시한폭탄은 째깍째깍 돌아가기 시작합니다. 조만간 A사 경영진 부대표 이하는 모두 징계성 정리해고됩니다.

근데, 저거 정말 ’ 남의 회사'일인가요? (먼산을 바라볼 뿐입니다….) 찔리는 분들이 ’ 범인'일 겁니다.

진실은 우주 저 너머에.......

덮어 둔 것이라고 해도 벗겨지지 않을 것이 없고, 숨긴 것이라 해도 알려지지 않을 것이 없다

실제 앞에 사례로 보여드렸던 사태를 분석해보면 경영진은 다음의 실수를 저질렀습니다.

문제에 대한 해결책이 무엇인지는 좀 안거 같았습니다.(그러니 입찰 서류라도 썼다고 생각합니다. ) 그러나 그 해결책을 만드는데 시간과 자원이 걸린다는 것을 몰랐습니다.

“입찰하고 뭐하면 6개월 이상은 걸릴 거야”라는 것은 이해할 만했습니다. 하지만 그 6개월 동안에 실제 개발이 이뤄질 수 있는지에 대한 평가는 왜 하지 않았을까요?

어떤 선택이 되어도 (입찰이 안되든, 입찰이 되든) 어떤 이익이 돌아오도록 일을 설계하지 못했습니다. 지금 상황을 설명을 드리면 이렇습니다. 입찰이 안되면 그냥 시간 버린 것이 됩니다. 그런데 입찰이 되면 정작 제시간에 제품을 만들 수 없어서 사업비를 되물어주는 사태가 일어날 것입니다.

아직까지 사태가 이해가 안 되시는 분들이 있을 거예요. (아니라고 하지 마세요, 바로 당신) 쉽게 설명드리겠습니다.

여러분이 중국집에 가서 짜장면 한 그릇 달라고 하고 계속 앉아 있다고 가정해 보겠습니다. 그런데 나올 시간이 다 되었는데 자꾸 안 보여서 당신은 ”왜 안 나와요?”하고 카운터에 물어봅니다. 그러자 가게 주인은 ”곧 나와요"라고 합니다. 거의 30분이 넘어갈 무렵, 하도 답답해서 주방에 가봤습니다. 그런데 주방이 텅 비어 있고 그 안에서 중국집 주인이 어딘가 전화를 걸어서 ’왜 자꾸 배달이 늦냐, 빨리 보내달라'하고 있습니다.

이 광경을 생각했을 때 여러분의 느낌은 무엇인가요? 분노일까요? 낙담일까요? 실망일까요? 앞으로 이 중국집은 어떻게 될 거라고 생각하시나요?

그런데 이런 상황에 대해 주위에 이야기했을 때 반응들은 한마디로 ‘더한 것도 알아'였습니다.

“에이, 원래 우리나라에서는 모든 프로젝트는 3~4개월이면 돼요. 5년차 이하의 싼 엔지니어들이 다해요. 어차피 정부 돈은 그냥 눈먼 돈이니까요. 던져주고 모른 척하면 돼요. 품질 그거 누가 따져요?”

“원래 우리 갑님(?)들은 외국에 똑같은 솔루션이 있어도 국내 업체들한테 해달라고 해요, 갑질 하고 싶으니까요.

“경영진들은 개발이 어떻게 되들었는지 관심이 없고 물건만 나오면 돼요. 과정이야 어찌 되든 몰라요, 사람을 갈아 넣은 속이든 뭐하든. 자신들이 그저 인사고과에 좋다고만 나오면 되지 저 제품이나 서비스가 잘 되는 데에는 관심이 없어요.”

“그게 뭐? 나 이 바닥에 10년 이상 일했는데 안 그런 프로젝트가 없었어요.”

이렇게 스스로 ‘망할 중국집'으로 달려가는 거죠(주어는 누구일까요?)… 성경의 구절을 인용해봅니다. 이

“그러므로 너희는 그들을 두려워하지 말아라. 덮어 둔 것이라고 해도 벗겨지지 않을 것이 없고, 숨긴 것이라 해도 알려지지 않을 것이 없다.” - 마태복음 10장 26절

언제까지 스스로를 속이고 살아오시렵니까?

"우리 정상영업 한다니까요? " - 그걸 누가 믿어!!!!

개발(Development)과 생산(Production)의 차이를 이해하라, 그리고 소외된 당신 자신을 돌보아라.

저의 생각에는 소프트웨어 개발에 대해 이해를 못하는 경영진은 경쟁사의 편이라고 생각합니다. 즉, 우리 편이 아닌 적이라는 뜻입니다. 당신은 지금 적인 가요, 아군인가요? 한번 찬찬히 생각해봅시다.

소프트웨어 업계의 필독도서인 ‘피플웨어'의 저자들은 아래와 같이 이야기합니다. (꼭 읽어보시길 바랍니다.) 소소

개발(Development)와 생산(Production)은 다르다.

이 이야기가 무슨 뜻일까요? 피플웨어의 저자들의 이야기를 좀 더 인용해보겠습니다. 치즈버거 패스트푸드 점장이라면 효율적인 햄버거 생산을 위해 아래와 같이 조치를 취할 것입니다.

치즈버거, 치즈버거~

오작동을 없애라. 기계(인간 기계)를 최대한 원활하게 돌리다.

매장에서 빈둥거리는 직원을 엄중히 다루라.

직원을 교체 가능한 기계부품으로 취급하라.

현재 상태를 유지하라(능률을 높일 궁리를 하지 말라. 망하는 지름길이다.)

절차를 표준화하라. 모든 일은 매뉴얼대로 하라.

실험을 하지 말라. 본사 사람들이 할 일이다.

왜 이런 조치들을 취할까요? 치즈버거 만드는 것은 인간의 창조성이 필요없는 일들이기 때문입니다. 기계처럼 빨리만 돌리면 생산량이 채워지고 생산된 물건은 바로바로 팔려서 이익으로 나오기 때문입니다. 이것이 이른바 2차 산업 구조입니다.

안타까운 것은 지금 현재 한국의 교육 시스템은 이 2차 산업 시대에 적합한 사람을 길러내는 것에서 그리 변화하지 못했습니다. 정해진 대로만 살아가야 하고 표준화된 것에 의심하지 않는 사람들을 키우도록 되어 있는 것이지요. 거기다가 각 회사에서 중요한 자리까지 잘 올라오신 엘리트분들은 대부분 이러한 교육에 적합한 분들이십니다.

그러나 이러한 관점은 개발, 정확히는 지식노동과는 아주 거리가 있습니다. 피플웨어의 저자들을 위의 조치들은 지식 노동을 위해 아래와 같이 바뀌어야 한다고 합니다.

지식노동의 방식은 생산노동과 다릅니다. 이 차이를 알아야 생산성을 올릴 수 있습니다.

실수를 허용하라

창의적이고 독창적인 일은 다그친다고 되는 게 아니다.

개발자, 아니 지식 노동자는 쉽게 교체할 수가 없다. 기존에 있던 사람과 똑같은 사람은 찾아볼 수 없다.

현상 유지 상태의 프로젝트는 사망이다.

일을 끝내는데 몰두한 나머지 이 질문을 하지 못하면 끝장이다. “이것이 정말 해야 하는 일인가?”

개발(Development)과 생산(Production)은 어떻게 다른 것인가요? 그것은 생산은 기계로 대체할 수 있지만 개발은 인간만이 해야만 하는 일이라는 뜻입니다. 그리고 인간을 교체 가능한 부품이 아니라 그 하나하나가 다 귀한 보석들이라고 생각해야 한다는 것입니다. 즉 인간이 가치 있는 존재로 인정받을 때에만 할 수 있는 것이 지적 노동이고 개발입니다. 이러한 관점의 변화가 없이는 당신은 계속해서 모든 소프트웨어 개발 프로젝트에서 실패할 수밖에 없습니다. 자동차가 굴러간다고 발로 지치면서 가는 것은 자동차를 바르게 쓰는 것이 아니지요.

이것이 단순히 소프트웨어 개발자를 존중하라는 뜻일까요? 아닙니다. 이것은 개발자 외 모든 부서 사람들에게도 적용됩니다. 스스로 존중해주라는 의미입니다. 계속해서 상사의 압박에, 고객의 압박에 미처 개발도 안된 것을 되었다고 말해야 하는 바로 당신의 마음도 편하지 않을 것이기 때문입니다. 당신도 사람입니다, 심장이 뛰고 어려운 동료를 보면 돕고 싶으면서 아이들이 존경하는 아버지나 어머니일 것입니다. 그러나 정작 자신을 존중하지 못하는 혹은 존중받지 못할 상황이 벌어지면 마음이 얼마나 아프겠습니까. 당신 스스로 존중받아야 다른 사람들도 당신을 존중합니다.

여러분 자신의 가면을 쓰는 댓가로 임금을 받고 있지는 않나요? 그럼 얼마안가 여러분 인생은 불행해집니다.

이럴 때, 우리는 어떻게 해야만 할까요? 언제나 ‘어쩔 수 없잖아요’만 외치는 사람이어야 할까요?

우리는 사람이잖아요, 같이 이야기해요.

그 유명한 ‘애자일 선언’ 외에 ‘애자일 선언 이면의 원칙'에는 정말 피가 되고 살이 되는 다양한 이야기가 나옵니다. 이것들 중 한번 같이 보고 적용해볼 만한 방법들이 있어서 어떤 식으로 하면 될지 생각을 해보고자 합니다. 아마 이런 이야기를 못 들어보고 여태까지 ‘에이, 잘 아시잖아요’만 하면서 변화해본 적이 없다면 한번 이 기회에 조금 바꿔봤으면 합니다.

비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

뚜찌빠찌

가장 좋은 것은 처음 일을 벌일 때부터 개발자들과 함께 이야기를 하는 것입니다. 처음 제안서를 쓰는 순간부터 말이지요. 물론 개발자가 ‘이것도 몰라요?’라고 할 수도 있습니다. 그러나 막판에 가서 만드네 못 만드네 하면서 싸우는 것보다는 처음부터 아메리카노 2잔 같이 마시면서 이야기하는 게 더 나을 것입니다. 미리미리 오실수록 나중에 웃으면서 이야기할 수 있습니다.

그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

먼저 믿어줍시다. 못 믿을 짓 했을 때 벌해도 되요.

동료들을 감시하는 것이 아니라 동료들이 일하다가 도움이 필요하거나 잘못되었을 때 이를 도와주는 것이 관리자의 역할, 이것이 ‘보충의 원리'입니다. (최동석, 보충의 원리에 대하여)

이를 위해서는 먼저 믿을 만한 개발자들을 뽑아서 같이 일한다는 것이 전제입니다. 절대 쉽게 개발자들을 무턱대고 뽑아서는 안됩니다만 한번 채용하거나 일을 같이 하기로 했다면 철저하게 믿고 그들이 일을 하는데 필요한 지원을 해줘야 합니다. 보통 가장 필요한 것은 ‘요구사항을 명확하게 해주기', ‘필요한 리소스 구입(클라우드나 도구 등)'입니다. 이에 대해선 나중에 다시 쓸 예정입니다.

개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

이메일 백만통보다 얼굴보고 하는 이야기가 더 확실한 경우가 많습니다.

서로 만나세요. 의외로 메일이나 메신저로만 소통을 하려고 하면 안 되는 경우가 많습니다. 특히 서로 사회적 자본이 없어서 신뢰가 떨어져 있다면 반드시 얼굴을 보고 대화하시길 권합니다. (물론 이미 끝장이 나서 전혀 신뢰할 수 없다면 안 되겠지요.)

그렇다고 와서 술이나 밥만 사라는 것은 아닙니다. 앞에서 말한 대로 의사결정이 필요한 부분이라던가 실제 해당 서비스나 소프트웨어 개발에 필요한 자원이 뭔지 들어보려는 등 실제 의사소통으로 풀 수 있는 문제를 푸는 것을 말합니다.

단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.

필요없는 일을 안하는데 집중하세요.

하지 않아도 될 일을 하지 않아야 합니다. 놀랍게도 ‘무언가 열심히 하는 것'은 소프트웨어 개발이나 서비스 개발에서 거리가 아주 먼 일입니다. 오히려 ‘불필요한 일을 하지 않는다'가 최선입니다. 왜냐하면 성공확률이 30% 아래밖에 안 되는 매우 고위험성 일이기 때문입니다. 이럴 때는 ‘득점을 하기'보다는 ‘실점을 줄이는' 방식으로 일을 하는 게 더 필요합니다. 요구사항을 정하는 때부터 이러한 마음을 가지고 서로 개발을 해나가면 좋습니다.