2014년 3월 16일 일요일

여자 개발자가 희망이다

소프트웨어 회사를 포함해서 많은 기업들이 개발자가 부족하다고 아우성이다. 이렇게 개발자가 부족하게 된 이유는 열악한 개발 환경에 따른 뛰어난 개발자들의 이탈과 저급개발자 양산 등 여러 환경, 정책적인 문제가 있지만 여자 개발자에 대한 편견과 차별도 주요한 이유라고 본다. 

여자 개발자에 대하여 여러 가지 편견이 있다. 여자 개발자는 실력이 없다, 책임감이 부족하다, 감정적이다, 언제 그만둘지 모른다는 등이다. 하지만 이러한 편견은 남성 중심적인 사고에 기인한 것이 많고, 그 동안의 개발 환경이 야근강요, 코딩 중심, 무모한 프로젝트와 같은 성격을 띄는 경우가 대부분이어서 전투력 강한 개발자를 선호하다 보니 이런 편견이 생긴 것으로 생각한다. 

필자가 경험한 바로는 여자 개발자들이 공유, 협업 문화에 좀더 잘 적응하고 아키텍트로도 더 뛰어난 경우를 많이 보아왔다. 남자, 여자 누가 더 개발자로서 우수하다고 말하는 것이 아니라 서로 다른 특성이 있으므로 이를 이해할 필요가 있다는 것이다. 

뛰어난 소프트웨어는 다양한 특성을 가진 사람들이 모여서 협업을 하고 그 다양성을 기반으로 창의적인 아이디어가 많이 나와야 탄생할 수 있다.

현재 소프트웨어 업계에 여자 개발자가 절대적으로 부족한 이유는 여러 가지가 있겠지만 일단 누구라도 일하기 힘든 환경이 큰 요인이다. 이런 환경에서 상대적으로 남자들이 더 잘 버티기 때문에 더 많이 남아 있다고 생각한다. 

현재의 기형적인 개발자 성비를 개선하는 것이 소프트웨어 업계에는 꼭 필요한 과제이고 이를 위해서는 누구라도 일하기 좋은 환경을 만드는 것이 우선일 것이다. 그러기 위해서 먼저 여자 개발자에 대한 편견과 차별을 없애야 한다. 

많은 회사들에서 크든 작든 여자 개발자에 대한 차별이 존재한다. 비공식적이지만 급여의 차이도 존재하는 회사도 있다. 승진의 기회도 다르다. 이런 이유는 여자 개발자는 결혼하거나 출산을 하면 결국 그만둘 것이라는 선입관이 존재하기 때문이다. 

소프트웨어 업계에서 여자 임원이 절대적으로 부족한 것을 보면 이런 현상을 알 수 있다. 물론, 남자와 여자가 특성적으로 완전히 동일하다고 말할 수는 없다. 차이가 있고 그러하기 때문에 서로 보완이 된다. 필자의 경험과 교육학적인 여러 도서를 보면 선천적, 후천적인 남녀의 차이는 이런 것들이 있다. 물론 필자의 개인적인 생각도 있으므로 의견이 다를 수도 있다. 

우선 남자 개발자들은 도전정신이 강하고 무모한 자산감도 가진 경우가 많다. 치열한 경쟁에 거부감이 좀더 적고, 상대적으로 체력이 뛰어나서 야근에도 잘 버틴다. 남자 개발자가 좀더 코딩을 잘한다는 의견은 입사 이전에 또는 어렸을 때부터 코딩을 경험할 기회가 좀더 남자에 많기 때문이 아닌가 생각된다. 

이러한 남자들의 특성이 현재의 열악한 개발 환경에 좀더 통할 수 있는 측면이 있는건 사실이다. 무리한 일정에 잦은 야근,  협업은 없고 혼자서 달리는 코딩이 현재 흔하게 볼 수 있는 개발 환경이다. 그리고 요즘은 많이 바뀌고 있지만 부어라 마셔라 회식 문화도 상대적으로 남자들에게 더 적합하다. 

그런 반면 여자 개발자들은 커뮤니케이션과 협업에 더 유리한 특성을 가지고 있다. 서로 경쟁하기보다는 서로 도우려는 특성도 있다. 모두 그렇다는 것이 아니고 평균적으로 좀더 그렇다는 의미다. 

남자들은 모른다고 말하는 것을 꺼려하는 경향이 있다. 그래서 끝까지 도움을 받지 않고 혼자서 해결해 보려고 한다. 하지만 여자들은 초기에 도움을 받아야 할 것을 구분해서 적절한 도움을 받는데 익숙하다. 모른다고 말하는 것에 대해서 자존심의 상처를 덜 받는다. 

이것은 소프트웨어 개발 문화 중 협업의 문화에서 매우 중요한 요소다. 혼자서 엉뚱한 방향으로 내달리지 않고 적절할 때 서로 묻고 의논하고 도와야 제대로 된 방향으로 갈 수 있다. 그런 능력이 상대적으로 여자 개발자에게 더 많이 보인다는 것이 필자의 의견이다. 이런 특성에 기인해서 여자 개발자 중에서 아키텍트로서의 능력이 더 뛰어난 경우를 많이 보았다. 

설령 뛰어난 아키텍트 재능을 가진 개발자가 있다고 하더라도 우리나라와 같은 개발 환경에서는 눈에도 잘 안띄고 실력을 발휘하기도 어렵다. 

여자 개발자들에게는 출산과 육아의 장애물이 존재한다. 우리나라에서는 출산과 육아는 개발 경력의 큰 단절이고 2,3년만 단절되면 현업 복귀가 쉽지 않은 분야이기도 하다. 실력적으로는 현업복귀가 가능해도 기업에서 꺼리는 경우도 많다. 

재택근무로도 무리 없이 일할 수 있지만 재택근무를 그렇게 효과적으로 할 수 있는 회사가 그렇게 많지 않은 것이 안타까운 현실이다. 

현재와 같이 여자 개발자들이 꾸준히 일하기 어려운 환경은 여자들에게만 불리한 것이 아니라 모든 개발자에게 불리하며 이런 특성 때문에 개발이 3D 업무라고 불린다. 

경쟁보다는 협업을 하고 혼자 달리기 보다는 공유, 토론, 의논을 적절히 하는 환경, 무모한 일정에 따른 품질 저하와 그에 따른 야근의 악순환 보다는 합리적인 프로젝트, 재택근무를 해도 개발에 전혀 지장이 없는 프로세스, 시스템 그리고 문화, 이런 환경과 문화가 여자 개발자뿐만 아니라 모두에게 필요하다. 지금같이 여자 개발자들이 살아남기 힘든 환경이 계속된다면 소프트웨어 업계 전체가 살아남기 힘들 것이다. 

이글은 ZDNet Korea에 기고한 칼럼입니다. 

외주 SW 개발의 비극

열악한 소프트웨어 외주 개발 문제는 우리나라에서 소프트웨어가 3D 취급을 받는 주요한 원인 중 하나다. 

'갑을병'으로 이어지는 외주도 모자라 '갑을병정무'까지 3,4단계 외주를 주기도 한다. 하청에 재하청이 이어질수록 열악한 댓가와 무리한 일정 그리고 부정확한 요구사항은 외주 개발을 점점 구렁텅이로 내몰고 있다.
소프트웨어 외주 개발 문제를 얘기하면 할 말이 많은 사람들이 꽤 있을 것이다. 필자는 그 중에서 접해 본 사례를 중심으로 소프트웨어 공학과개발 문화적으로 문제점을 지적해보고자 한다.

A사는 새로운 서비스를 시작하면서 서비스 개발을 야심차게 인도에 외주를 줬다가 큰 낭패를 봤다. 

지금도 왜 인도에 외주를 줬는지 궁금하지만 추측컨데 실리콘밸리 외주 형태를 흉내를 낸 것이 아닌가 생각한다. 그런데 인도 개발사는 개발 완료 후 L사에서 기대한 것과 전혀 다른 것을 전달해왔다. 프로토콜도 완전히 다른 것이고 도저히 서비스에 사용할 수 있는 상황이 아니었다. 

이런 일이 벌어진 가장 큰 이유는 스펙을 제대로 전달하지 않았기 때문이다. 인도 개발사에 전달된 스펙은 간단한 기획서 수준이었고 프로토콜도 제대로 언급하지 않았다. 게다가 인도 개발사가 소프트웨어를 완성해서 전달할 때까지 중간에 제대로 점검을 하지 않았다. 

한국 업체 같으면 억지를 부려서 잔금을 안주면서 다시 개발을 강요 했겠지만 인도 개발사는 계약대로 개발을 했고 억지는 통하지 않았다. 잔금을 안줄 수는 없었다. 결국 인도 개발사가 개발한 소프트웨어는 모두 버리고 다급하게 한국업체를 통해서 다시 개발을 했다. 돈은 돈대로 더 들고 서비스도 뒤죽박죽이 되었다. 

B사는 1년이 넘는 꽤 긴 프로젝트를 제대로 된 스펙도 없이 외주를 주고 고치기를 반복한다. 

외주 개발사에는 핵심 기능을 정리한 한 두 페이지 정도의 요구 사항 문서가 전달된다. 외주 개발사는 전체 프로젝트 기간 중 20~30% 정도 기간 안에 소프트웨어를 만들어 보여줘야 한다. 남은 70~80% 기간은 B사의 요구대로 거의 매일 소프트웨어를 수정하고 보여주기를 반복해야 한다.

외주 개발사는 해당 분야의 전문 회사라 이런 부정확한 요구사항으로도 대충 B사가 원하는 것을 이해해 개발할 수 있었다. 개발사의 PM은 수시로 고객사에 불려가 요구사항 변경 회의를 해야 했고 소프트웨어를 계속 고쳐나가기 때문에 아키텍처를 제대로 유지하기가 어려웠다. 

심지어 막판에 요구사항이 크게 바뀌어서 다 버리고 다시 만드는 일도 발생했다. 외주 개발사는 비용도 과도하게 투입해야 하고 프로젝트 관리를 제대로 하기도 어렵다. 하지만 B사가 가장 큰 고객이므로 시키는 대로 할 수 밖에 없었다. B사는 이런 식으로 프로젝트를 진행하는 것을 아직도 당연하게 생각한다.

C사와 D사는 소프트웨어 개발 외주가 제대로 진행이 안돼 외주사 개발자를 회사 내부에 앉혀 놓고 같이 개발하는 형태로 개발을 한다. 

외주 프로젝트지만 옆에서 같이 개발하지 않으면 제대로 개발이 안되기 때문에 같이 일해야 한다. 옆에 앉혀 놓고 개발한다 뿐이지 개발 방식은 다른 외주와 별반 다를 바가 없다. 요구사항은 계속 변하고 애써 작성한 코드를 버리고 고치기를 반복해야 한다. 

외주사도 이런 방식이 비효율적이라서 원하지 않지만 고객사의 우월한 지위를 꺽을 수가 없고 이렇게 일하다 보니 외주 개발 내용 외에 그냥 직원처럼 부림을 당하는 경우가 많이 발생한다. 

D사는 외주를 줬다가 소스코드가 없어져서 소프트웨어를 버려야 했다. 

D사는 소스코드를 받을 수 없는 외주 계약으로 개발을 했다. 처음 몇 년은 유지보수를 잘 했지만 몇 년 후 외주 개발사는 망해서 없어졌다. 그 과정에서 소스코드가 D사로 제대로 전달되지 않아서 최신 소스코드를 찾을 수 없는 상황이 되었다. 결국 외주 개발한 소프트웨어는 모두 버리고 다시 개발해야 하는 상황이 되었다.

E사는 개발자가 해야 할 개발자 테스트를 외주업체에 맡긴다.

개발자는 열심히 코딩만 하고 옆에 앉아서 외주개발자가 기본적인 개발자 테스트를 해준다. 속된 말로 '따까리'라는 말이 적합하다. 비싼 자사 개발자가 너무 바쁘기 때문에 그렇게 한다고는 하지만 자칫하면 잘못된 개발 습관이 쌓일 수 있다. 

또한 이렇게 해서는 코드 품질을 보장하기 어렵다. 완벽한 로직의 코드인지는 개발자 본인이 가장 잘 확인 할 수 있는데 대충 만들고 발견된 문제만 해결하는 방식이 습관화 될 수도 있다. 개발자는 완벽한 소스코드를 적는데 최선을 다해야 하는데 이런 개발자의 의무를 망각하면 프로그래밍은 기초부터 흔들리게 된다. 

위에서 살펴 볼 수 있듯 외주 문제의 주된 원인은 부실한 스펙이다. 모호한 요구사항 정도로 계약을 하게 되니 중간에 요구사항이 계속 바뀌어도 어쩔 수 없고 프로젝트 종료 기준도 모호하여 담당자 맘에 안들면 잔금을 받기도 어렵다. 소송도 종종 일어나지만 시간도 오래 걸리고 소송을 해도 해결하기 쉽지 않다. 고객이 대기업인 경우 소송을 하기도 쉽지 않다. 스펙을 제대로 적는 것은 소프트웨어를 개발하는데 있어서 가장 어려운 일이기 때문에 한마디로 설명할 수는 없다. 

소프트웨어를 직접 개발하지 않고 외주 개발을 하는 주된 이유는 다음과 같다. 직접 개발할 수는 있는데 내부 인력이 부족할 때와 특정 요소기술을 내부에서 보유하고 있지 않을 경우다. 내부에서 개발할 수 없을 만큼 잘 모를 때는 외주를 주기도 어렵다. 모르는 상태에서 대충 외주를 주면 원하는 결과를 얻기도 어렵고 분쟁이 일어나기 쉽다. 

기술력이 뛰어나거나 전문 기술을 가지고 있는 외주 개발사와 협업을 잘하는 것은 소프트웨어 생태계를 만드는데 아주 중요하다. 제대로 외주를 주기 위해서는 고객도 스펙을 제대로 적을 수 있을 만큼 잘 알아야 한다. 

부품 업체 다 망하고 나면 자동차 회사도 망하듯이 수많은 전문 소프트웨어 회사들이 망하고 나면 우리나라 소프트웨어 업계도 망하는 것이당연한 수순이다. 대만이 자전거 산업에서 세계를 호령하는 이유는 자전거 부품회사와 꾸준히 상생을 해와서 대만에는 뛰어난 자전거 부품회사가 많기 때문이다. 그에 비해서 생산비 절감에만 몰두한 우리나라 자전거 산업은 전세계 자전거 산업에서 명함도 못 내밀고 있다. 이미 많은 중소 소프트웨어 회사들이 사라졌거나 고사 상태인 지금 자전거 산업과 비슷한 미래가 예상되는 것은 안타까운 일이 아닐 수 없다. 

이제 와서 말로만 베풀듯이 상생이라고 외치는 것은 들을 때마다 거북하고 막상 그 내용도 해결책의 핵심은 아니다. 우리나라에서 소프트웨어 개발이 3D라는 인식에서 벗어나라면 이런 열악한 외주 환경이 바뀌지 않으면 안된다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.

SW를 을로 취급하는 하드웨어의 무지

필자는 펌웨어를 개발하는 등 하드웨어 팀과 같이 일하는 소프트웨어 개발자를 자주 만난다. 그런데 많은 개발자들이 하드웨어 팀과 일하기 힘들다고 하소연한다. 

회사에서 하드웨어에 더 집중하고 투자하며 소프트웨어는 보조로 생각한다고 말한다. 그렇지 않은 회사도 있지만 많은 회사들이 하드웨어를 더 중요하게 생각하고 소프트웨어는 하드웨어의 부수적인 역할로 생각하곤 한다. 

'소프트웨어' 하면 흔히 데스크톱 소프트웨어나 게임, 모바일앱을 생각한다. 하지만 이런 순수 소프트웨어, 즉 하드웨어에 종속적이지 않은 소프트웨어 비중은 일반인이 생각하는 것만큼 크지 않다. 반대로 하드웨어와 밀접한 관련이 있는 소프트웨어 비중은 의외로 크다.

자동차의 예를 들면 현재 최고급 차량의 생산 원가에서 소프트웨어가 차지하는 비중은 50%에 육박하고 있다. 그리고 2020년이 되면 고가 차량을 넘어 전체 자동차 생산 원가에서 소프트웨어 비중이 50%가 될 것이란 전망도 있다.

과거에 하드웨어로 수행하던 기능이 점점 소프트웨어로 대체되고 있고 그러면서 과거에는 불가능했던 기능이 실현 가능해져서 하드웨어 발전에도 큰 도움이 되고 있다. 

이런 소프트웨어를 펌웨어, 임베디드 소프트웨어라고 한다. 하드웨어와 간접적으로 관련 있는 소프트웨어까지 합치면 그 비율은 어마어마하다. 

이렇게 하드웨어에서도 소프트웨어 비중이 점점 증가하고 있고 하드웨어 자체 성능에도 소프트웨어가 많은 기여를 하고 있는데 이를 다른 측면으로 보면 조만간 하드웨어 경쟁력도 소프트웨어 역량이 좌지우지 하게 될 것이라는 얘기다. 그렇게 될 날이 몇년 남지 않았다. 

즉, 간단하게 얘기해서 앞으로는 소프트웨어를 잘해야 자동차도 잘 만들 수 있다는 얘기다. 

우리나라는 선진국보다 늦게 산업화되었지만 몇몇 분야에서 선진국을 따라잡았거나 앞질렀다. 자동차, 반도체, 선박, 휴대전화, 가전, 디스플레이, 플랜트 등이 그것이다. 하지만 소프트웨어 분야는 소프트웨어 선진국과 비교하여 아직 멀었다고 많은 사람들이 평가하고 있다. 그런데 이제 몇 년 후가 되면 소프트웨어 역량이 하드웨어 경쟁력을 판가름한다니 발등에 떨어진 불이 아닐 수 없다. 

우리나라는 임베디드 소프트웨어 분야에선 선진국에 더욱 뒤졌다.  이런 상황이 지속되면 그나마 따라잡고 앞지른 분야까지 내놔야 할 상황이 될 것이다. 

실제 성공한 하드웨어 중심인 회사에서 소프트웨어를 개발하는 방식을 보면 문제가 많다. 하드웨어 개발팀이 우위를 가지고 소프트웨어 팀은 시키는 대로 개발하는 방식인 경우가 많은데 그런 사례를 한번 살펴보자. 

A사는 하드웨어가 이미 설계된 상태에서 소프트웨어는 거기에 맞춰서 개발해야 한다. 

소프트웨어 개발팀 관점으로 봤을 때 하드웨어 설계에 문제가 있어도 소프트웨어가 우회 방법을 찾든지 해서 재주껏 해결해야 한다. 하드웨어 설계에 소프트웨어 개발자가 제대로 참여를 못해 이런 비효율적인 상황이 벌어진다. 그러나 A사는 하드웨어는 변경이 어렵지만 소프트웨어는 얼마든지 마음대로 변경할 수 있으니 소프트웨어를 하드웨어에 맞춰 개발하고 문제를 해결해야 한다고 한다. 

버그가 발견되면 무조건 소프트웨어 개발팀에서 문제의 원인을 찾아야 하고 하드웨어 문제도 소프트웨어 개발팀에서 해결해야 한다. 그러다보니 문제가 발생하면 욕은 소프트웨어 개발자들이 먹는다. 

기획 단계부터 소프트웨어 개발팀의 의견을 들을 기회조차 없다. 서로 다른 생각을 가진 사람들의 의견이 잘 모아질 때 창의적인 아이디어가 나오는데 하드웨어 중심적인 개발에서는 획기적이고 창의적인 아이디어가 나오지도 않는다.

B사는 모든 개발 일정이 하드웨어에 맞춰져 있다. 하드웨어 개발팀은 소프트웨어 개발팀과 개발 일정을 논의하지도 않는다. 이미 단계 별로 하드웨어 개발 및 양산 일정이 정해져 있으니 소프트웨어는 각 단계 별로 어떤 것은 1주일 어떤 단계에선 3주 안에 하드웨어에 필요한 소프트웨어를 무조건 만들어내야 한다. 

소프트웨어 개발팀은 인터페이스를 맞추거나 에뮬레이터를 통해서 미리 개발을 하고 싶지만 미리 정보를 제공 받지 못해 하드웨어 일정에 맞추느라고 항상 야근에 시달린다. 하드웨어 부서 일정이 바뀌면 소프트웨어 개발 일정도 틀어져서 일정을 조율하기가 매우 어렵다. 

C사는 소프트웨어 개발 프로세스도 하드웨어 개발 프로세스에 맞춰져 있다. 

과거에는 하드웨어를 개발할 때 한 두명의 개발자가 밤세워가며 펌웨어를 만들어주는 방식이었다. 하지만 지금은 소프트웨어 개발자가 엄청나게 늘었다. 그런데도 하드웨어 개발 프로세스에 소프트웨어를 끼워 넣는 방식은 그대로다. 

하드웨어 개발 프로세스에는 있지만 소프트웨어에는 없는 것도 있고 물론 그 반대도 있다. 소프트웨어는 알파, 베타 단계가 있지만 하드웨어는 그렇게 고쳐 나가지 않는다. 하드웨어 개발 프로세스에 억지로 소프트웨어 개발을 끼워 맞추다 보니 매우 비효율적으로 되어 있다. 용어들도 상이해서 이해하기 어렵다. 

지금은 소프트웨어 개발자들도 적응해서 프로세스를 따르고 있지만 여전히 문제가 많은 프로세스임은 명백하다. 

D사의 경우 소프트웨어 기술 책임자가 하드웨어 출신이다. 

이같은 상황은 업계에 안고 있는 가장 큰 문제이기도 하다. 소프트웨어 분야는  전문가가 아니면 정말 이해하기 어렵다. 콜라를 팔던 경영자가 TV 파는 회사의 경영자가 될 수는 있다. 하지만 비즈니스를 아무리 잘 하던 사람도 소프트웨어 조직의 기술 책임자가 될 수는 없다. 불가능하다. 

그런데 많은 회사들의 소프트웨어 부문 CTO(Chief Technical Officer)가 소프트웨어 전문가가 아니거나 CTO가 아예 없는 경우도 많다. 하드웨어 출신이 소프트웨어를 맡기도 하고 소프트웨어 출신이라고 해도 중간에 관리자로 넘어가서 이제는 소프트웨어 엔지니어가 아닌 사람이 CTO를 맡기도 한다. 

경영자에게 불도저 같은 추진력을 요구하는 회사에서 소프트웨어 전문가인 경영자들은 추진력이 부족한 것처럼 보여 많이 밀려 났고 이제는 소프트웨어 조직도 전혀 다른 분야 출신의 불도저 같은 사람이 맡는 경우도 많다. 

그런 경영자들이 추진하는 정책이라고는 고작 끊임없는 야근이다. 단기적인 성과는 날 수 있지만 아키텍처는 엉망이고 개발자들은 지치고 개발 문화는 엉망이 되었다. 소프트웨어는 소프트웨어 전문가가 맡아야 한다. 

기적적인 하드웨어에서의 성공을 회상하며 소프트웨어도 거기에 끼워 맞추려고 하면 큰 착오다. 하드웨어에서 성공했다고 그 방식으로 소프트웨어를 조금만 더 잘하면 될 것 같은 착각에 빠지기도 한다. 소프트웨어는 스타트업을 제외하고는 한두명의 천재가 밤을 세워서 잘 할 수 있는 분야가 아니다. 소프트웨어가 하드웨어의 부속이라는 생각에서 벗어나야 한다. 오히려 소프트웨어가 중심이 되는 시대가 오고 있다. 

그나마 그 동안 이룩했던 우위를 잃지 않으려면 소프트웨어가 '을'의 자리에서 벗어나 하드웨어와 동등한 관계가 만들어져야 한다.

이글은 ZDNet Korea에 기고한 칼럼입니다.