태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

SW 산업의 부실한 계약문화(개발문화 시리즈9)

2013/12/20 22:29 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





이번 개발문화 이야기는 '계약 문화'다. 

 

나는 개발자지만 여러 차례 계약의 경험이 있다. 특히 한국, 일본, 미국의 계약 문화를 두루 경험해봤다. 회사 설립 관련된 계약도 해보고 프로젝트 계약도 많이 해봤다. 그러면서 나라별로 계약 문화에 많은 차이가 있음을 알게 되었다. 어찌 보면 계약만의 문제는 아닌 것 같다. 일상의 약속, 구두 계약에서도 비슷한 현상이 벌어진다. 

 

한국에서는 선비정신과 의리문화 영향인지 몰라도 돈에 관해서 직접적으로 말하기를 꺼려하는 경향이 있다. “좋은 게 좋은 것”이라는 말이 있듯 서로 좋은 얘기만 하려고 한다. 계약 조건에 대해서 꼼꼼하게 점검하고 따지면 너무 깐깐하다는 얘기를 듣기도 한다. 

 

하지만 미국의 개발문화는 좀 달랐다. 나도 처음에는 이질감을 많이 느꼈다. 개인적으로 친한 관계라 하더라도 계약을 할 때는 냉정할 정도로 철저했다. 어색할 정도로 금액에 대한 얘기도 까다롭고 꼼꼼했다. 잘못될 경우에 대한 얘기도 철저히 언급을 해서 친분에 금이 갈 것 같은 생각이 들었다. 

 

내가 경험한 미국인과의 계약이 그랬던 것이지 전체를 대표하는 것은 아니다. 어쨌든 결과적으로 그런 철저한 계약은 일이 잘되든 잘못되든 문제의 소지가 별로 없었고 인간관계도 해치지 않았다. 한국에서 약속이나 계약이 틀어지면 인간관계까지 깨지는 경험을 해봤는데 그와는 사뭇 달랐다. 

 

그 뒤로도 한국에서 계약을 여러 번 했지만 한국 문화를 거스르기는 어려웠다. 하지만 나름대로 정확하게 하고 문제의 소지를 없애기 위해서 노력을 하고 있다. 

 

한국의 계약 문화가 계약 자체만의 문제라기 보다는 사회 전체적인 여러 관습들의 복합체라서 혼자서 바꾸기는 어렵다. 칼럼에서 이를 한방에 해결할 수 있는 기가 막힌 방법을 제시해 줄 것으로 생각하면 기대가 너무 큰 것 같다. 그래도 문제의 인식이 문제 해결의 출발이다. 무엇이 문제인지 같이 생각해보자. 

 

첫째, 계약 전에 일 시작하기 

계약을 하기도 전에 일을 시작하는 것은 비일비재하다. 이유는 여러가지가 있다. 계약 절차가 복잡해서 늦어진다고 핑계를 대기도 하고 담당자가 미리 꼼꼼하게 챙기지 않아서 늦어지기도 한다. 그래도 빨리빨리 문화는 여전해서 일단 일을 먼저 시작하자고 한다. 

 

가끔은 일부러 계약을 늦추기도 한다. 어차피 계약은 될 것이라고 하지만 계약이 늦어지면 불리한 쪽은 외주사이고 나중에는 계약 조건을 꼼꼼히 따지기도 어려워진다. 계약금도 제때 받지 못하기도 하고 프로젝트가 아예 취소되기도 한다. 지급을 늦출수록 이자만큼 이익이기 때문에 일부러 늦추는 회사도 있지만 신뢰관계의 손실과 이자만큼의 이익중 어느 것이 진짜 회사에 이익인지는 생각해볼 필요가 있다. 

 

이런 현상은 프로젝트 뿐만 아니라 스타트업들에서도 벌어진다. 의리로 애매하게 시작해서 회사가 잘되면 서로 생각이 달라져서 문제가 되기도 한다. 이때 보통 손해를 보는 쪽은 개발자들이다. 화장실 들어갈 때와 나올 때 달라지는 것이기 때문에 화장실 들어가기 전에 확실히 정해야 한다. 

 

둘째, 범위를 정하기 않고 계약하기 

 

얼마 전 미국의 한 개발자가 자신의 일을 외국 개발자에게 적은 금액에 외주를 주고 자신은 취미생활을 한 사례가 화제가 되었다. 이런 일이 우리나라에서 가능할까? 쉽지 않을 것이다. 이런 일이 가능 하려면 내부 개발이라도 스펙이 명확하고 투명하게 개발이 되어야 한다. 

 

이런 에피소드를 그냥 우습게만 생각할 것은 아니다. 한명의 개발자도 외주를 제대로 줄 수 있는데, 우리나라에서는 수백억짜리 프로젝트가 스펙도 제대로 정하지 않고 진행되는 경우가 있다. 일정과 금액이 이미 정해진 상태에서 소프트웨어 개발 프로젝트를 진행하면서 스펙을 정하게 되면 초기 예상보다 범위와 비용이 훨씬 늘기도 한다. 1천억원짜리 프로젝트에 3천억원이 투입되었다는 한 SI회사의 하소연을 들은 적도 있다. 
과거에 같이 일했었던 실리콘밸리의 개발자에게 들은 얘기다. 과거에 국내 대기업의 외주 프로젝트를 진행한적이 있는데 스펙도 없이 대충 프로젝트를 시작해서 자신이 스펙을 자세히 적어서 보여줬다고 한다. 그런데 담당자는 스펙을 보지도 않고 진행과정에서 공유를 해도 관심을 갖고 확인도 하지 않았다고 한다. 

 

그러다가 소프트웨어 완성 후에 원하는 것이 아니라고 기능변경을 계속 요청했다고 한다. 어이가 없어서 그뒤로 한국과는 프로젝트를 안한다고 한다. 한국에서는 비일비재한 일이지만 미국인에게는 납득이 안되는 상황이다.

 

이것은 이미 사회적으로도 큰 문제라서 스펙을 정하는 프로젝트와 구현하는 프로젝트를 나눠서 발주하는 '분할발주'를 추진하고 있다. 분명히 필요한 제도지만 이것이 법률화 된다고 하더라도 공공분야에 국한된 것이고 스펙을 제대로 정하는 것도 쉽지 않아서 잘 정착될지는 미지수다. 

 

고객이 전문성이 떨어지고 의무를 다하지 않고 우월적인 지위를 남용하는 문화가 팽배해서는 법률로 문제를 해결하기는 쉽지 않다. 

 

셋째, 모호하게 계약하기 

수많은 중소기업과 외주 개발사를 괴롭히는 문제다. 계약서에 제대로 된 스펙을 포함하지 않고 계약을 하는 경우가 매우 흔하다. 이런 현상은 내부개발을 할 때도 발생한다. 하지만 내부개발 시에는 서로 얘기를 하면서 조정해 나가고 점진적으로 개발을 잘 해내기도 한다.

 

하지만 외주 프로젝트는 같은 방식으로 진행하면 내부 개발보다 문제가 몇 배 더 커진다. 모호한 스펙은 서로 다르게 생각하게 하고 개발한 결과가 예상과 다르면 소송으로 이어지기도 한다. 

 

스펙을 대충 정하고 개발을 시작한 후 발주사가 원하는대로 언제든지 기능 변경을 요구하면서 개발하는 방식도 이와 비슷하다. 발주사는 아무 때나 기능 변경을 강요하고 외주사는 어쩔 수 없이 들어줘야 하는 경우가 많다. 

 

원래는 계약을 한 줄만 바꿔도 재계약을 해야 하지만 우리나라에서는 상상하기 쉽지 않은 일이다. 프로젝트 완료 후 검수조건이 모호한 것도 마찬가지다. 명확한 조건에 의해서 검수를 하는 것이 아니라 담당자 개인 취향에 맞지 않으면 검수에 실패하기도 한다. 

 

모호한 스펙은 여러가지 패턴이 있지만 보통 유저인터페이스나 기능 보다 기능이 아닌 요구사항에서 더 큰 문제가 발생한다.

 

비기능은 일반적으로 자세히 언급하지 않기 때문에 누락되기 쉽고 문제가 되면 시스템을 다 버리고 다시 만들어야 할 정도로 큰 이슈들이 발생하기도 한다. 비기능 요구사항에는 성능, 보안성, 안정성, 가용성, 이식성, 유지보수성, 확장성, 표준, 제약사항 등 셀 수 없을 정도로 많고 프로젝트마다 중요한 부분이 다르다. 

 

표현방법이 문제가 되기도 한다. ~을 지원한다, 효율적이어야 한다, 편리해야 한다 등과 같이 측정이 불가능한 문구들은 언제든 문제가 된다. 보는 사람에 따라 다르게 해석되는 문구들은 없어야 한다. 스펙을 명확하게 적는 주제는 너무 방대해서 여기서 다 설명하기는 어렵다. 

 

넷째, 계약은 서류일뿐 

 

이런 환경이라면 수많은 프로젝트가 소송에 휩쓸리고 일을 할 수 없어야 한다. 물론 분쟁에 휩싸여서 문닫은 회사도 많지만 모든 문제가 소송으로 이어지지는 않는다. 프로젝트 결과에 대해서 발주사와 외주사가 서로 다르게 생각하거나 계약 내용을 제대로 이행하지 않은 경우에도 소송대신 다른 방법으로 해결하기도 한다. 

 

접대로 풀기도 하고 인간관계를 이용해서 해결하기도 한다. 프로젝트의 실패가 발주사 담당자의 피해로 이어질 수 있기 때문에 유야무야 성공한 프로젝트로 탈바꿈하기도 한다. 이러다보니 계약에 문제가 있어도 나중에 풀면 된다는 생각으로 계약을 대충 진행하기도 한다. 

 

이러한 문화적인 문제들이 계속 이어지는 것은 소프트웨어 개발 문화뿐만 아니라 역량 향상에도 문제가 된다. 수많은 중소기업과 외주사를 괴롭히는 요인이다. 이런 문화를 빠르게 개선하는 뾰족한 방법은 없는 것 같다. 

 

법적인 뒷받침도 필요하고 다 같이 문화를 바꾸려는 노력이 필요하다. 다같이 공멸하느냐 토양을 개선해서 같이 상생하느냐의 중요한 문제다. 자칫 하소연으로만 들릴 수도 있지만 이런 불합리를 바꾸려고 노력하는 사람도 많다. 그런 노력에 조금이라고 힘이 보태지기를 바란다.


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

저작자 표시 비영리 변경 금지

전규현 개발문화 개발문화, 계약

Trackback Address: http://allofsoftware.net/trackback/331 관련글 쓰기

SW개발, 맥가이버식 전문가가 위험한 이유(개발문화 시리즈8)

2013/12/12 20:35 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed


이번 개발문화 이야기는 '전문가문화'다. 

 

어떤 개발자가 국내 유수의 소프트웨어 기업에 취업하려고 한다고 가정 해보자. 개발자가 수백명에 달하는 이 회사에 지원을 하면서 본인을 다음과 같이 소개한다고 보자. 

 

“저는 빌드 전문가입니다. 빌드 기술 연구와 실무 경험이 5년이나 됩니다.” 

 

그럼 이 개발자는 취업에 성공할 수 있을까? 모든 회사가 상황은 아니지만 이 개발자가 주장하는 “빌드 전문가”라는 것에 대해서 제대로 이해하고 그 가치를 높게 평가할 회사가 그렇게 많지는 않을 것이다. 오히려 이렇게 생각하는 개발자도 있을 수도 있다. 

 

“빌드 전문가? 그게 그렇게 어려운 건가? 나는 비주얼스튜디오나 이클립스에서 버튼하나 누르면 그냥 빌드가 다 되는데 전문가가 필요한가? 그냥 프로젝트에 투입할 수 있는 프로그래머나 뽑아주면 좋겠네” 

 

그럼 소프트웨어가 아닌 다른 분야는 어떨까? 

 

여기 집을 만들고 있다. 그런데 어떤 사람이 “저는 설계도 할 줄 알고 목수, 미장에 벽돌도 잘 쌓아요. 제게 맡겨주면 제가 다할 수 있습니다”고 얘기한다고 하자. 

 

어떤 생각이 드는가? “정글의 법칙”에서 집을 잘 지을 수는 있어도 내가 사는 집을 맡기기에는 불안하다. 하나 하나가 얼마나 전문성이 있고 어려운 일인지 일반인도 잘 알기 때문이다. 설령 다 할 줄 아는 사람이 있어도 설계를 잘하는 사람에게 벽돌도 쌓으라고 하면 비용도 더 많이 들고 비효율적이라는 것은 쉽게 이해한다. 

 

여기 운동선수를 뽑으려고 한다.

 

한 지원자가 “저는 농구, 축구, 야구 모두 잘합니다”고 주장한다. 프로선수를 뽑는데 이 선수를 채용하겠는가? 초등학교에는 이런 천재가 존재한다. 하지만 프로세계에서는 어림도 없다. '농구의 신' 마이클 조던도 야구선수로는 별볼일 없다는 것을 잘 알 것이다.

 

좀더 범위를 좁혀서 프로 축구선수를 뽑는다고 하자. 지원자가 공격, 수비, 골키퍼를 모두 잘한다고 주장하거나 프로 야구선수가 투수, 포수, 1루수, 유격수, 외야수, 지명타자까지 다할 수 있다고 하면 최고라고 생각하지는 않을 것이다.

 

그런데 소프트웨어 현장에서는 모든 것을 다 잘하는 만능선수를 선호하고 한 분야의 전문가에 대해서는 이해도 낮고 인기도 없다. 

 

소프트웨어는 앞에서 언급한 다른 분야에 비해서 덜 복잡하고 쉬운 분야가 아니다. 인류가 만든 가장 복잡한 지식산업이라고 하는 것이 소프트웨어다. 영화를 만들어도 카메라, 조명, 작가 등 전문가로 나뉘어져 있지만 소프트웨어는 이에 못지 않은 전문분야가 있다. 

 

다시 빌드로 돌아가보자. 빌드는 생각보다 전문성이 필요한 분야다. 빌드 전문가가 개발자가 아닌 것은 아니다. 보통 개발자로 성장하다가 빌드 분야에서 더욱 연구를 많이 하고 실무를 통해서 전문가가 된 개발자이다. 

 

작은 규모의 회사에서는 개발자가 짬짬히 해볼 수 있는 일이지만 규모가 커질수록 일은 점점 기하급수로 늘어가며 비용도 많이 들어가고 사고의 위험도 커진다. 

 

큰 회사에는 빌드팀이 별도로 있을 뿐만 아니라 여러 빌드 전문가들이 빌드 자동화와 효율을 높이기 위해서 노력한다. 빌드가 자동화되면 개발팀이 얻는 혜택은 대단히 크다. 빌드 전문가가 없다면 개발팀은 이런 혜택을 누릴 수 없고 비용은 더 많이 들어간다.

 

소프트웨어에서 이렇게 전문성이 필요한 분야가 매우 많다. 대부분 잘 알고 있는 QA분야를 비롯해서 테크니컬 라이팅, DB관리자, 데이터분석가, 테크니컬 마케팅, 국제화 전문가, UX전문가, 번역가, 아키텍트 등 다양하며 도메인 및 특정 기술 분야마다 매우 다양한 전문가가 있다. 회사마다 필요한 전문분야도 다르다. 

 

물론 뛰어난 소프트웨어 개발자는 여러 분야에 대해서 두루 잘 알지만 하나하나의 전문가가 되기는 어렵다. 그 중에서 한 두가지 분야의 전문가는 될 수가 있다. 

 

그럼 왜 이렇게 전문가에 대한 인식이 낮고 전문가가 제대로 대접을 받지 못할까? 

 

주된 이유는 우리나라에서는 프로젝트 규모가 크나 작으나 가내수공업식으로 개발을 하는 곳이 많기 때문이다. 물론 잘하고 있는 회사도 많으므로 모든 회사가 그렇다는 것은 아니다. 그런데 의외로 개발자는 수천명인데 속을 보면 수많은 가내수공업팀이 있는 경우도 있다.

 

장인정신하면 도자기가 떠오르기도 하지만 수백년전 우리나라 전통도자기는 전문가를 키우지 않아서 산업화에 실패했다. 한명의 도공이 도자기 생산 프로세스 모든 것을 담당했다. 예술성은 뛰었났을지언정 효율적인 생산은 하지 못했다. 

 

하지만 임진왜란때 수백명의 도공을 납치해간 일본은 도자기 생산과정을 수십가지로 나눠서 각각의 전문가를 키워서 산업화에 성공했다. 도자기 성형만 하는 사람, 유약만 만드는 사람, 색을 내는 염료만 연구하고 만드는 사람 등 수십가지의 전문가가 있다. 

 

현대의 도자기 산업과 별반 다를 것이 없다.

 

이렇게 전문가를 키우지 않는 문화는 현대까지 이어진 것일까? 회사가 작을 때는 한 개발자가 많은 일을 해야 하므로 만능 개발자를 선호하고 그런 개발자가 회사를 키우는데 원동력이 됐다. 

 

그런데 회사 규모가 엄청나게 커졌는데도 여전히 그런 만능 개발자만 선호하고 개발자가 똑같이 개발 과정의 모든 일을 해야 하는 경우가 많다. 

 

물론 개발자는 여러 분야의 일을 다 할 수는 있지만 전문가보다 잘할 수는 없다. 개발자는 자신이 전문가인 분야가 따로 있다. 대충 할 줄 아는 사람과 전문가는 하늘과 땅 차이다. 개발하는 제품의 품질에서도 차이가 발생한다. 

 

이런 일이 발생하는 이유는 소프트웨어 전 개발과정의 전문성을 제대로 이해하는 사람이 회사에 없기 때문이다. 그래서 전문가라고 하더라도 막상 취업을 해서는 자신의 전문성과는 전혀 관계가 없는 일을 하게 될 가능성이 매우 높다. 

 

주변에서 이런 경우는 매우 많이 본다. 이미지 프로세싱을 10년 가까이 해서 한국으로 채용되어 온 인도 개발자를 만난 적이 있다. 한국회사는 자신의 전문분야의 일을 할 수 있게 해주겠다고 약속을 했지만 현재 일반 UI개발을 몇 년째 하고 있다고 한다. 이번 계약이 끝나면 바로 인도로 돌아가고 싶다고 한다. 

 

만능개발자만 100명있는 개발조직보다는 개발자는 80명만 있고 20명은 각 분야의 전문가로 구성한 조직이 훨씬 개발 효율이 높고 제품의 품질도 올라갈 것이다. 

 

회사의 규모에 맞게 적절한 전문가를 채용하고 키워야 한다. 작은 규모에서 시작해서 성장하는 회사라면 회사가 커가는 적절한 시점에 전문분야로 분리해야 한다. 

 

우리가 흔히 알고 있는 전문분야도 있고 소프트웨어 전문가가 아니면 모르는 전문분야도 있다. 필요한 전문분야도 회사마다 다를 수도 있다. 영업만 이해하는 경영자가 개발팀을 구성하면 만능개발자가 바글바글한 조직이 될 가능성이 높다. 

 

조직을 전문화하고 효율적으로 만들려면 이를 이해하고 이끌 수 있는 CTO급의 개발자가 꼭 있어야 한다. 

 

여러 전문가가 효율적으로 협업하려면 프로세스도 중요하고 무엇보다 성숙한 개발문화가 필요하다. 성숙한 개발문화를 이 글에서 다 설명할 수는 없다.

 

현재 필자가 개발문화에 대해서 컬럼을 두달 넘게 쓰고 있지만 화두만 던지는 것이지 배울 수는 없다. 화두를 가지고 깨닫고 적용하여 경험을 통해서 전진해야 한다. 

 

CTO급 개발자가 필요하다고 했지만 가내수공업식 개발환경에서 성장한 개발자는 아무리 오래 개발을 했고 뛰어나다고 하더라도 소프트웨어 전문성에 대해서 다 알기는 어렵다. 성숙한 개발문화와 전문화된 조직에서 다양한 경험을 한 개발자가 도움이 될 것이다. 

 

당장은 개발자가 한 분야의 전문가가 되었다고 하더라도 회사에 어필하기 쉽지는 않을 수 있다. 소프트웨어 문화가 점점 성숙되고 전문가에 대한 이해도가 증가할수록 전문가에 대한 대우는 좋아질 것이고 맥가이버식 만능개발자보다 더 인기가 많아지는 때가 올 것으로 생각한다.



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



저작자 표시 비영리 변경 금지

전규현 개발문화 개발문화, 만능개발자

Trackback Address: http://allofsoftware.net/trackback/330 관련글 쓰기

회의 많았던 SW 개발 회사의 비극(개발문화 시리즈7)

2013/12/04 16:30 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



이번 개발문화 이야기는 '회의 문화'다. 

 

회의 문화는 IT 분야에만 국한된 얘기가 아니다. 이미 많은 논의가 있었고, 회의 문화가 개선된 회사들도 많다. 그러나 변화가 필요한 회사들도 아직 많다. 

 

회의가 많은 회사는 망한다는 속설도 있는데, 하루종일 회의하느라 정작 일은 퇴근 시간 지나서야 할 수 있다고 하소연하는 고참 개발자나 팀장들을 많이 봤다. 회의를 많이 하는 증상이 있는 회사는 회의 자체의 문제보다 근본적으로 해결해야 할 문제들이 따로 있을 가능성이 높다. 

 

회의를 하는 방식 자체보다는 근본적인 원인에 대해서 얘기를 해보고자 한다. 

 

첫째, 우리나라 회사들은 재택근무가 쉽지 않다. 이것은 여러 문화의 결과이기도 하다. 업무지시를 서로 만나서 해야 하고 얼굴을 봐야만 얘기가 되는 상황이라면 재택근무로 일하기 어렵다. 

 

지금 같이 일하고 있는 동료들이 모두 집에서 일한다고 생각하면 어떻게 될지 상상을 해보자. 전혀 일이 진행되지 않거나 효율이 너무 떨어진다면 다시 한번 생각해봐야 한다. 

 

회의를 통해서 해결하는 안건의 상당수는 만나지 않고 시스템을 통해서 온라인으로 충분히 의논할 수 있는 것들이다. 물론 회의를 통해서 해결하는 것이 효율적인 안건들도 있다. 이런 안건도 만나서 난상토론을 하기 보다는 이슈를 다 정리한 후에 공유하고 몇가지 핵심 결정사항만 회의를 통해서 해결하면 된다. 

 

굳이 만나서 해결할 필요도 없고 전화나 화상회의로도 충분히 가능하다. 내용은 이미 공유되어 있고 핵심 사항만 의논하고 결정하면 되기 때문에 시간도 얼마 걸리지 않는다. 그리고 일하는 과정이 시스템을 통해서 투명하게 공유가 되면 굳이 만나서 회의를 해야 할 일은 대폭 줄어들게 된다. 

 

SI 프로젝트를 진행하다 보면 고객이 개발자의 출석체크를 한다는 얘기도 있다. 모아 놓고 일을 하지 않으면 일이 제대로 진행 되지 않는다고 생각하고 안보이면 제대로 일을 하고 있다고 믿지도 못하는 것이다. 이 또한 투명하게 일이 진행되지 않는 것이 주요 원인 중 하나다. 

 

재택근무 대신 모여서 일을 한다고 해도 재택근무가 가능한 형태로 일을 해야 더 효율적이다. 현재 재택근무가 불가능하다면 근본 원인을 생각해보자. 

 

둘째, 경영진에 보고하는 회의가 비효율적이다. 

 

주간회의와 같은 형태로 주기적으로 정리를 해서 한주간의 업무를 부서별로 취합, 정리해서 보고를 하는 형태의 회의는 우리나라에서 아주 흔하게 볼 수 있다. 다른 분야에서는 어떨지 모르겠지만 소프트웨어 분야에서 이런 형태의 보고회의는 많은 문제를 유발한다. 이런 회의가 없어야 한다는 것은 아니다. 

 

그러나 이런 회의는 준비과정에 많은 시간이 걸리고 대부분의 회사에서 개발자를 겸하고 있는 개발팀장들의 시간을 많이 소모한다. 그리고 취합되고 정리되는 과정에서 많은 핵심정보는 사라지고 예쁘게 꾸며진다. 경영진은 적나라한 개발현황은 보고 받지 못하고 화장이 잘 된 보고를 받게 된다. 

 

앞에서도 얘기했지만 모든 개발과정은 시스템을 통해서 투명하게 공유되어야 하고 경영진은 이 시스템들을 통해서 개발 진행상황을 직접 볼 수 있어야 한다. 경영진이 약간의 노력을 보여주는 것도 필요하지만 시스템이 경영진이 필요한 보고서를 실시간으로 만들어 낼 수 있어야 하고 우선적으로 개발문화가 투명하게 바뀌어야 한다.

 

경영진은 실시간으로 모든 개발상황을 파악할 수 있어야 하고 시스템을 통해 이슈 관련 논의에 직접 참여해야 한다. 앉아서 보고를 받고 구도로 지시하는 방식으로는 너무 비효율적이고 느리다. 회의시간에는 중요한 이슈 몇가지만 논의하면 된다. 시스템에 있는 정보를 굳이 다시 보고를 받을 필요는 없다. 

 

회의에 관련해서 몇가지 이슈를 섞어서 얘기를 했지만 이 또한 여러 개발 문화와 얽혀있다. 공유가 부족하면 수시로 만나서 물어봐야 하기 때문에 회의가 많아진다. 문서화를 싫어하니 정리한 후에 간단히 결정만 해도 될 회의를 만나서 얘기로 다 풀어야 한다. 

 

시스템을 통해서 논의를 했으면 자동으로 공유가 되는데 만나서 논의한 내용은 기록에도 남지 않는다. 나중에 딴 소리를 하기도 하고 다른 사람들이 내용을 모르니 똑같은 사안을 또 물어본다. 시스템에 개발 현황이 투명하게 공개가 안되니 일일이 만나서 공유해야 한다. 

 

뭐든 빨리 빨리 해결하려고 하니 일단 이슈가 생기면 시간이 약간 더 걸리더라도 효율적인 시스템을 이용하지 않고 즉시 만나서 해결하려고 한다. 문서를 작성하고 공유하는 것에 습관이 안돼 있으면 회의를 하면서도 기록을 하지 않고, 그렇다보니 결정사항을 추적하는 것도 쉽지 않다.

 

이처럼 이제부터 회의문화를 개선해보자고 회의 방법만 고쳐본들 별로 나아지는 것을 없을 것이다. 재택근무가 마치 옆에서 일하는 것처럼 효율적으로 가능할 정도로 근본 원인을 하나씩 개선해야 한다. 그러려면 프로세스, 기반시스템도 바뀌어야 하지만 무엇보다 전반적인 개발문화가 바뀌어 나가야 한다. 

 

그래야 회의 문화도 조금씩 개선이 되고 회의 횟수와 시간도 줄며 좀더 효율적인 회의문화가 정착 될 것이다.


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



저작자 표시 비영리 변경 금지

전규현 개발문화 개발문화, 회의

Trackback Address: http://allofsoftware.net/trackback/329 관련글 쓰기

SW개발과 규칙의 두얼굴 (개발문화 시리즈6)

2013/11/26 22:25 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



이번 개발문화 이야기는 '규칙 준수 문화'다. 

 

우리 주변에서 규칙을 무시하는 현상을 자주 볼 수 있듯 소프트웨어 개발에 있어서도 규칙을 준수하지 않는 일은 자주 벌어진다. 물론 규칙을 정말 상세히 정하고 모든 사람이 규칙에 따라 소프트웨어를 개발한다고 더 잘되는 것은 아니다. 

 

계속 강조하지만 규칙은 최소한으로 정해야 하고 성숙된 개발문화에 의한 개발이 더 효율적이다. 그래도 규칙은 지켜야 하며 지킬 수 있고 지켰을 때 개발 효율이 최대화 되는 규칙을 만들어야 한다. 그럼 규칙을 무시하는 현상이 자주 벌어지는 이유를 살펴보자. 

 

첫째, 규칙을 지키지 않는 개발자들이 있다. 

 

보통 회사의 최고 개발자들에게서 종종 벌어지는 현상이다. 소수의 개발자들에게 목을 메고 있는 회사들은 그런 개발자들이 어떤 방식으로 개발을 하던지 그냥 놔두는 경우가 많다. 물론 핑계는 있다. 규칙을 따르면 짧은 기간 안에 개발을 끝낼 수가 없고 자신들이 최고이기 때문에 누가 도와줄 수도 없다고 한다. 

 

그러면서 프로세스를 따르지도 않고 문서도 안 만들면서 내용을 공유하지도 않는 경우가 많다. 이런 회사에서 규칙은 평범한 개발자들만 따라야 하는 형식적인 것이 되기 쉽다. 이런 과정에서 특정 개발자에 대한 종속성은 계속 커지고 개발 문화는 후퇴하게 된다. 결국 규칙은 있지만 실상은 주먹구구식으로 개발을 하는 것과 비슷하게 된다. 

 

둘째, 규칙이 너무 복잡하고 많은 경우이다. 

 

큰 회사일수록 자주 벌어지는 현상이다. 규칙이 회사 역량에 비해서 너무 많고 자세한 경우다. 세계적인 방법론을 흉내낼 때 종종 나타나며, 문제가 벌어질 때마다 규칙을 계속 추가하다 보면 규칙이 너무 많아지게 된다. 이런 조직은 관료화되어 규칙자체가 목적으로 변질된다. 원래 목적인 '소프트웨어를 가장 빠르고 효율적으로 개발하자'는 원칙과 거리가 먼 규칙을 지키기 위해서 앞뒤 가리지 않게 된다. 

 

결국 개발자들은 이런 규칙을 다 따르고는 도저히 개발이 안되므로 형식적으로 흉내만 내고 피해 다니는 요령을 키우게 된다. 개발 효율성은 오히려 주먹구구식 개발보다 떨어지곤 한다. 규칙은 꼭 필요한 것으로 최소화하고 개발문화와 절묘한 조화를 이뤄야 한다. 

 

셋째, 경영자들이 규칙을 무시하는 현상이다. 

 

가장 큰 문제 중 하나는 규칙을 정해 놓고 경영자들이 무시하는 것이다. 경영자들은 프로세스를 무시하고 아무 때나 요구사항을 뒤집고 자신이 전문이 아닌 기술적인 결정에 관여하기도 한다. 우리나라에서는 제왕적인 경영자가 워낙 많아 법은 있지만 왕은 지키지 않아도 된다고 생각한다. 

 

작은 회사들은 이런 경영자의 통찰력과 빠른 판단이 회사를 성장시키는데 큰 도움이 된다. 하지만 회사가 커지고 전문화되면 얘기가 달라진다. 소프트웨어 개발 과정에서 벌어지는 전문적인 분야에 대해서 한 경영자가 전문가보다 잘 알 수는 없다. 자칫 개발 과정에서 경영자의 개인적인 취향을 강요하는 현상이 벌어질 수도 있다. 

 

우리나라에서는 규칙과 법을 초월해야 더 막강한 권한을 가졌다고 생각하는 경향이 있어서 이런 일들이 더 자주 벌어지는 것이 아닐까 생각한다. 

 

결론은 꼭 지킬 수 있는 최소한의 규칙을 만들고 따르는 것이 중요하다. 대부분의 회사에서 소프트웨어 개발 프로세스는 너무 복잡하다. 산출물도 너무 많고 경직되어 있다. 중간에 승인절차가 너무 많은 경우도 수두룩하다. 

 

회사 성격에 따라서 필요한 프로세스가 다르기 때문에 획일적으로 말하기는 어렵지만 프로세스가 좀더 효율적으로 간단해질 필요는 있다. 그러면서 꼭 필요한 규칙은 만들어야 한다. 

 

예를 들어 보자. 코딩 컨벤션이 정해져 있다면 자신의 코딩 스타일과 달라도 따라야 하는 것이다. 공유도 규칙으로 강제화하기는 매우 어렵다. 소스코드 커밋(Commit)시 메시지는 몇줄 이상 남기고 소스코드에 주석은 몇줄에 한번씩은 남겨야 한다는 식으로 규칙을 정하면 형식에 치우칠 우려도 있고 자칫 효율이 더 떨어질 수 있다. 

 

서로 리뷰를 하면서 자연스럽게 개선해나가면 되는데 리뷰를 안하는 것이 문제가 된다. 그래서 리뷰는 일주일에 두번씩 한다고 하거나 소스코드 커밋(Commit)시 70% 이상은 리뷰를 해야 한다는 구체적인 규칙을 정해 놓으면 또 효율성은 떨어진다. 

 

아주 단편적인 몇가지 예만 들었지만 뭔가 안된다고 자꾸 규칙을 늘리면 규칙을 피해가는 부작용이 또 발생하므로 적절하게 균형을 맞춰서 개발문화를 성숙시키는데 더 노력해야 한다. 자칫하면 말도 안되는 규칙만 점점 늘게 된다. 규칙에 의한 제한보다는 '권장', '독려', '포상' 등이 더 효율적이다. 

 

이렇게 원래 목적과 점점 거리가 먼 규칙이 자꾸 늘어가는 이유는 효율적인 개발문화 환경에서 개발을 해본 적이 없는 사람들이 자꾸 규칙을 만들기 때문이다. 아무리 소프트웨어 이론을 많이 안다고 해서 효율적인 개발 규칙을 만들 수는 없다. 

 

가장 좋은 방법은 그런 경험이 많은 개발자들은 회사에 합류시켜서 성숙된 문화를 받아들이는 것이다. 문화를 글로 배울 수 없듯이 경험자들의 도움을 받는 것이 좋다. 기억해야 할 것은 규칙으로 결코 소프트웨어 개발 문제를 해결할 수 없으며 성숙된 개발문화를 형성하는데 더 노력을 해야 한다는 것이다.


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



저작자 표시 비영리 변경 금지

전규현 개발문화 개발문화

Trackback Address: http://allofsoftware.net/trackback/328 관련글 쓰기

서열문화가 SW산업 망친다. (개발문화 시리즈5)

2013/11/19 14:16 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



이번 개발문화 이야기는 '서열이 지배하는 조직문화'다. 

 

우리나라는 옛날부터 서열을 매우 중요시 한다. 사람들이 모이면 서로 나이를 비교하고 서열을 정한다. 회사에서도 대리, 과장, 부장이 되려고 열심히 일한다. 직급에 따라 업무가 달라지고 급여도 서열에 비례한다. 물론 많은 변화가 있어 왔지만 뿌리깊게 자리 잡은 서열문화의 뿌리는 여전히 튼튼하다.

 

소프트웨어 산업에서도 서열 문화는 조직 문화에 많은 영향을 주었고 그로 인해서 많은 문제와 생산성 저하를 불러일으켰다. 소프트웨어 개발자도 직급에 따라 서열화 되며 주로 윗사람이 일을 시키고 아랫사람은 시키는 대로 일하는 형태가 많다.

 

이러한 수직적인 조직문화는 수평적인 조직 문화에 비하여 소프트웨어 개발에는 적합하지 않다. 자율성과 창의성이 강조되는 소프트웨어 개발 현장에서 수직적인 조직문화는 자칫 창의력을 저해하고 수동적인 마인드를 형성할 수 있다. 

 

내 경험에 의하면 소프트웨어 개발에 적합한 효율적인 조직은 수평적인 조직이다. 각자 역할을 나눠서 일을 하지만 상하관계는 아니다. 업무도 그렇게 수평적으로 전문화된다. 역할은 프로젝트 규모에 따라 세분화되기도 하고 크게 몇 개로 나뉘기도 한다. 

 

큰 프로젝트에서는 아주 많은 역할로 나뉜다. 소프트웨어 아키텍터, 프로그래머, 프로젝트 매니저, 프로덕트 매니저, 리스크 매니저, 빌드 엔지니어, 테크니컬 라이터 등 여러 역할이 있지만 이들은 상하 관계가 아니다. 전문화된 일을 하는 것이다.

 

그런데 수직적인 조직문화를 가진 소프트웨어 회사에서는 이들 역할과 비슷한 이름을 사용한다고 하더라도 수직적인 관계는 그대로 유지가 된다. 윗사람이 시키고 아랫사람은 지시에 따르는 스타일로 일을 한다. 그리고 전문적인 역할 구분 없이 윗사람이 모든 것을 결정할 권한을 갖는 경우가 많다.

 

개발자는 신참이나 고참이나 모두 소프트웨어 엔지니어다. 고참이 되면 그냥 시니어 엔지니어가 되는 것이다. 과장, 부장이나 연차에 따라 책임, 수석이 되는 것은 서열 중심의 조직에서 나타나는 현상이다. 물론 회사 대표 개발자에게는 수석 사이언티스트(Chief Scientist), 펠로우 엔지니어(Fellow Engineer) 등 특별한 타이틀이 있을 수 있지만 모두 소프트웨어 엔지니어다.

 

그 외에도 태크니컬 스티어링 커미티(Technical Steering Committee)나 아키텍트 그룹(Architect Group) 등의 조직이 있을 수 있지만 능력과 경험에 따른 역할의 구분이지 이들을 윗사람으로 생각하지는 않는다. 

 

부서간 커뮤니케이션에서도 서열은 많은 영향을 미친다. 합리적인 결정보다 서열에 의한 결정이 종종 발생한다. 대리급 개발자가 영업부서의 부장에게 직급으로 눌려서 합리적인 결정을 못하기도 한다. 이렇게 서열문화는 생산성을 떨어뜨리고 개발자의 전문성 향상을 저해한다. 

 

최근에 몇몇 젊은 회사에서 서열 파괴 시도를 하고 있다. 직원들간 직급을 모두 없애고 서로 이름을 부르며 나이와 상관없이 모두에게 존칭을 사용하는 것이다. 이러한 시도는 상당히 긍정적으로 평가한다. 물론 부작용이 없는 것은 아니다. 연공서열을 파괴 했을 뿐이지 나이 어린 사람이 또 윗사람이 되어서 서열화가 되는 경우도 발생한다.

 

결국 서열을 없애고 조직을 수평화시키는건 제도만으로 완성되는 것이 아니다. 조직이 전문화되고 전문가를 우대하는 문화도 정착이 되어야 한다. 각자 역할에서 전문가로 성장할 수 있고 관리자를 넘보지 않아도 대우를 받으며 일할 수 있어야 한다. 

 

소프트웨어 산업은 특수성이 강하다. 엄청나게 복잡한 지식산업이면서 예술성이 강하다. 서열에 의한 역할분담이나 지시에 의한 업무 진행은 소프트웨어 개발에 적합하지 않다. 서열보다는 각자의 특성, 실력에 따라서 수평적으로 일을 나눠서 하는 수평적인 조직문화가 필요하다. 

 

수평적인 조직이라도 다 같이 똑 같은 일을 하는 것은 아니다. 일반적으로 고참은 더 어려운 일을 하고 리뷰도 많이 한다. 대우도 서열보다는 실력에 의해서 차별화 되어야 한다. 그러려면 모든 개발이 투명화 되어 모든 개발자의 실력과 성과가 만천하에 드러나야 한다. 

 

결국 서열을 없애고 수평적인 조직을 만들기 위해서는 개발 방식 자체도 바뀌어야 한다. 조직뿐만 아니라 프로세스, 시스템도 모두 바뀌어야 한다. 제도만 바꿔서는 실패할 가능성이 크다. 모든 문화는 서로 얽혀 있어서 하나만 바꾼다고 될 일은 아니다. 연관된 모든 문화를 같이 바꿔야 하고 꾸준히 투자해야 한다. 

 

가장 중요한 것은 경영진의 마인드이다. 그래야 꾸준히 변화의 추진력을 얻을 수 있다. 변화는 1,2년에 마무리되는 것이 아니고 회사가 지속되는 한 끊임없이 투자를 해야 하는 것이다. 


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



저작자 표시 비영리 변경 금지

전규현 개발문화 개발문화

Trackback Address: http://allofsoftware.net/trackback/327 관련글 쓰기

SW개발의 8:2 법칙, 그리고 불편한 진실 (개발문화 시리즈4)

2013/11/18 10:44 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




이번 개발문화 이야기는 '가내 수공업식 개발문화'다. 즉, 8:2 법칙에 관한 이야기다.  소프트웨어 개발에 있어 시스템과 개발자에 의존하는 비율이 8:2정도가 되어야 한다는 것이다. 

 

그럼 다른 분야는 어떨까? 예술적일수록 시스템에 의존하는 비율이 낮고, 체계화되고 규모가 클수록 시스템 비율이 높아져서 인력에 대한 유연성은 증가한다. 

 

소프트웨어 개발에 있어 가장 중요한 요소는 사람이다. 즉, 개발자이다. 그런데 전적으로 개발자에게 의존하는 개발방식은 효율도 떨어지고 리스크도 높다. 특히 소수 인력에 의존하는 방식은 가내수공업 형태를 벗어나지 못한다.

 

비단 소프트웨어 분야 뿐만이 아니다. 전통 도자기 등 시스템화로 인해 산업화를 못 이루고 맥이 끊겨 사라져버린 분야가 얼마나 많은가? 임진왜란 때 수많은 도공을 납치해간 일본은 도자기 생산을 체계화해서 산업화에 성공했다. 유럽 수출을 시작으로 부를 쌓아서 선진국이 되는 발판을 마련했다. 

 

회사 규모가 크나 작으나 회사 시스템에 대한 의존도가 매우 낮고 개별 개발자에 의존하는 회사는 개발자들을 효율적으로 활용하지도 못한다. 개발자들이 퇴사하면 큰 타격을 입고 새로운 개발자가 들어와도 효율적으로 일하는데 많은 노력과 시간이 필요하다. 

 

개발자들이 실력에 맞는 일을 적절하게 골고루 나눠 하지 못하고 한쪽으로 치우치기 일쑤고 고급 개발자들이 소방수역할을 하는 경우가 많다. 회사 규모는 큰데 여전히 가내수공업 형태를 못 벗어난 결과다. 

 

이런 현상은 회사가 시스템을 효율적으로 갖추지 못해서 벌어진다. 회사 시스템이란 개별 직원과 대비되는 회사의 전반적인 체계를 말한다.소프트웨어 회사 또는 소프트웨어를 개발하고 있는 모든 회사라면 갖춰야 할 시스템은 다음의 4가지가 있다. 

 

조직, 프로세스, 문화, 기반시스템이다. 

 

4가지를 잘 갖추고 있다면 특정 개발자에게 의존하는 리스크는 줄고, 개발자들도 더 효율적으로 일할 수 있다. 개발자가 이직을 해도 빠른 시간 안에 적응이 가능한다. 이것은 개발자와 회사 모두에게 이익이 된다. 

 

이렇게 되려면 소프트웨어 개발이 시스템에 의존하는 비율이 80%정도는 되어야 한다. 나머지 20%는 도저히 시스템으로 커버가 어려운 부분이다. 하지만 대부분의 회사는 8:2가 아니라 2:8 또는 1:9이기 때문에 문제다.

 

개인 회사이거나 아주 작은 회사도 지속적으로 성장하려면 시스템에 의존하는 비율을 0%에서 시작하여 20%, 50%, 80%로 차츰 높여가야 한다. 

 

특정 개발자가 빠져 나가면 대부분의 개발 경험과 지식도 함께 빠져나가게 되는 경우 회사는 매우 불안한 상황에 놓인다. 이런 상황을 개발자가 의도적으로 만든 것은 아니다. 회사의 시스템이 워낙 부실하기 때문이다. 

 

이런 상황이라면 개발자도 워낙 바빠서 그런 상황에 신경 쓸 겨를이 없다보니, 상황은 더욱 악화된다. 단기적으로는 개발자 가치가 올라가서 더 좋을 것 같다. 하지만 장기적으로 보면 이런 환경에서 개발자는 적절한 성장 기회를 얻지 못한다. 아키텍처는 신경 쓰지도 못하고 여기저기 불려다니면서 재미없고 힘든 문제 해결에 주로 투입된다. 개발자 본인에게도 장기적으로는 손해다. 

 

여기에는 몇 가지 논란이 있을 수 있다. 

 

첫째, 그럼 개발자는 교체 가능해야 하는 부품인가? 

 

회사가 시스템을 갖춰야 하는 이유는 개발자를 교체 가능하도록 하기 위한 것이 아니다. 리스크를 줄이고 좀더 효율적으로 개발하기 위해서이다. 개발 중에는 교체가 쉽게 되는 일이 있고, 어려운 일이 있다. 교체가 쉽게 되는 일까지 회사 핵심개발자들의 시간을 많이 빼앗으면 안된다. 회사 핵심 개발자들은 좀더 중요한 일을 해야 한다. 

 

그러려면 쉬운 일들, 과거에 해놓은 일들을 다른 사람이 할 수 있는 시스템이 필요하다. 이런 상황에서는 핵심 개발자가 퇴사해도 유지보수에 큰 문제가 없다. 하지만 미래의 중요한 프로젝트에 타격을 입기 때문에 개발자들의 가치는 결국 커진다. 물론 아주 작은 회사는 상황이 다르다. 

 

둘째, 시스템을 아주 잘 갖추고 있는 대기업이 소프트웨어 개발을 더 잘해야 하는 것 아닌가? 

 

시스템은 회사의 상황과 역량에 알맞게 적절히 갖춰야 한다. 하지만 큰 회사들은 여기서 큰 불균형을 이루는 경우가 많다. 프로세스를 과도하게 복잡하게 하고 사용하기도 힘든 비싼 시스템들을 구축해 사용을 하기는 하지만 효율성 측면에서의 개발문화는 한참 뒤쳐져 있다. 

 

이런 상황에서 프로세스는 형식적으로 흐르고 비싼 시스템은 장식물에 그치는 경우가 많다. 개발효율로 따지만 주먹구구보다 더 못한 경우도 있지만, 보험의 성격이 있어서 쉽게 포기하지도 못한다. 

 

소프트웨어 회사가 갖추어야 할 시스템, 즉, 조직, 프로세스, 문화, 기반시스템은 교과서에 딱 정해져 있는 것은 아니다. 회사 규모, 성격 등에 따라서 계속 바뀌어 나가야 한다. 부족해도 문제고 과도해도 안된다. 

 

개발자 혼자 회사를 하면 혼자서 모든 것을 다해야 하지만, 10명, 30명, 100명으로 늘 때마다 조직 구성이 달라져야 한다. 하지만 많은 회사들이 큰 규모에 비해서 이런 구분 없이 개발자에게 너무 많은 일을 맡기고 있는 경우가 많다. 

 

보통은 회사가 커지면서, 테스트, 빌드, 시스템관리, 기술지원, 고객지원, 영업지원 등과 같은 일들은 전문조직으로 분리해야 한다. 어려운 점은 적절한 시점에 적절한 규모로 조직을 변화시켜야 한다는 것이다. 

 

그럼, 프로세스는 어떤가? 여기에도 극과 극이 있다. 명시적인 프로세스가 아예 없거나 너무 복잡한 경우도 많다. 프로세스는 최대한 단순하고 자유도를 높이면서도 핵심적인 요소들은 빠지지 않도록 해야 한다. 이 또한 회사의 역량이 높아감에 따라서 계속 바뀌게 된다. 

 

많은 회사들이 열악한 개발 문화와 낮은 역량을 비싼 기반시스템이 해결해 줄 것으로 착각한다. 꼭 필요한 기반시스템도 있지만 오히려 해가 되는 경우가 훨씬 더 많다. 소수의 필수 시스템을 제외하고는 적절한 시점에 필요하면 사용하면 된다. 꼭 비싼 시스템이 아니라도 상관없다. 개발자당 연 사용료가 수백, 수천만원하는 종합선물세트 시스템을 구축해 놓고 극히 일부 기능만 쓰는 경우도 많다. 툴로는 결코 문화나 역량을 극복할 수 없다. 

 

반대 경우도 문제인건  마찬가지다. 필수 기반시스템 하나 없이 주먹구구로 개발하는 회사라면 좋은 오픈소스 기반시스템들이 있으므로 잘 선택한뒤 제대로 가이드를 받아 사용하면 된다. 과도한 경우보다는 개선하기가 쉽다. 

 

회사 규모에 맞게 안정적이며 꾸준히 역량을 향상하면서 개발을 하려면 개발자에게만 책임을 지울 것이 아니라 회사가 더 많은 것을 갖추고 있어야 한다. 그러기 위해서 꾸준한 투자와 변화는 필수다. 작년과 올해 조직, 프로세스가 똑같고 변화를 위해 투자를 한 것이 하나도 없다면 회사는 책임을 회피하고 있는 것이다.

 

리스크를 줄이고 개발자가 보다 효율적으로 일할 수 있는 환경을 만들려면 회사가 80%를 갖출 수 있도록 노력해야 한다.


본 칼럼은 ZDNet Korean에 기고한 글입니다.



저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/326 관련글 쓰기

SW개발과 빨리빨리 문화의 저주(개발문화 시리즈3)

2013/11/02 22:05 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



이번에 다룰 개발문화 이야기는 '빨리빨리 문화'다. 

 

일을 빨리 하자는게 나쁜 건 아니다. 오히려 이런 '빨리빨리 문화' 덕분에 우리나라가 짧은 기간에 성장했을지도 모른다. 더 짧은 시간에 똑 같은 일을 해낼 수 있다는 것은 경쟁력이 있는 것이다. 우리는 그동안 많은 산업분야에서 '빨리빨리 문화'의 혜택을 입었고, 관련 노하우도 많다. 

 

그런데, 이런 '빨리빨리 문화'가 소프트웨어 분야에서는 독이 되는 경우가 많다. 실제로 독이 되는 경우를 많이 보았다. 시제품은 빨리 만드는데 본제품을 완성하는데는 시간이 훨씬 오래 걸리며 품질도 떨어지고 시간이 흐를수록 유지보수가 무척 어려워져서 제품을 포기하는 경우도 흔하다. 상황을 수습하지 못해, 회사의 종말로 이어질 때도 있다. 

 

유독 왜 소프트웨어 분야에서 '빨리빨리 문화'가 문제가 되는 것일까?  원인은 세가지로 요약할 수 있다. 

 

첫째, 소프트웨어는 훨씬 복잡하다. 다른 분야에는 미안하지만 소프트웨어는 가장 복잡한 지식산업이다. 빨리 개발해야 한다고 열심히 코딩부터 시작해서 으쌰으쌰 개발하면 아키텍처는 뒤죽박죽 되고 개발 기간도 오래 걸린다. 그렇다고 차근차근 모든 설계서를 만들고 설계서대로 개발하면 좋겠지만 그렇게 하면 웬만한 프로젝트를 마무리는데 10년쯤 걸릴 것이다. 절묘한 절충이 가장 어렵다. 

 

둘째, 소프트웨어는 예술이다. 소프트웨어 아키텍처를 만들어 가는 과정은 예술과 비슷하다. 예술은 재촉한하거나 야근을 한다고 해서 빨리, 더 좋은 결과가 나오는 것은 아니다. 수많은 요구사항과 비즈니스 전략 등을 종합하여 가장 적합한 아키텍처를 만드는데 시간이 부족하면 부실한 아키텍처가 되고 개발에 들어갔거나 유지보수시 이를 바꾸려면 비용은 100배, 1000배가 더 든다. 

 

셋째, 소프트웨어는 생명체와 같다. 소프트웨어는 건축에서 개념을 가져온 것도 많고 실제 비슷한 것도 많다. 하지만 빌딩은 일단 완공되면 100년동안 기본 구조가 거의 안바뀌지만 소프트웨어는 보통 출시되도 계속 성장한다. 소프트웨어는 출시 후부터 초기 개발비용보다 약 4배의 돈이 더 드는 것으로 알려져 있다. 하지만 아키텍처가 부실하다면 4배가 아니라 40배의 비용을 더 들이고도 업그레이드 및 유지보수가 어려울 수 있다. 

 

그럼, '빨리빨리 문화'가 문제니 차근차근 천천히 개발을 해야 할까? 그건 전혀 아니다. 수많은 성공한 글로벌 소프트웨어 회사들은 천천히 개발을 해서 성공한 것이 아니다. 소프트웨어 개발의 최대 미덕은 소프트웨어를 빨리 개발하는 것이다. 소프트웨어 개발을 조금이라도 느리게 하는 모든 방법론, 규칙, 제약, 프로세스는 잘못된 것이다. 

 

'빨리빨리 문화'가 소프트웨어 개발을 오히려 더 느리게 하고 다른  문제들도 일으키기 때문에 문제라는 것이다. '빨리빨리 문화'는 소프트웨어 개발 프로젝트에서 다음과 같은 것들을 유발한다. 

 

-프로젝트 지식, 정보, 자료 공유의 부재 
-부실하고 확장성이 떨어지는 아키텍처 
-특정 개발자에게 종속됨 
-수많은 중복된 코드 
-개발자의 인간다운 삶과 성장 포기 
-점점 증가하는 유지보수 비용 

 

이런 현상은 개발 방법론과는 상관없이 벌어진다. SRS(Software requirements specification) 형태로 스펙을 제대로 쓰던 TDD를 하던 이는 모두 소프트웨어를 빨리 개발하기 위한 방법이다. 문서작성, 코드리뷰, 프로세스 등 모든 것은 소프트웨어를 빨리 개발하려는 것인데 이런 것들이 개발을 느리게 하니 그냥 개발하자고 하는 것은 완전히 착각이다. 

 

물론 이런 방법들이 소프트웨어를 빨리 개발하는데 도움이 되려면 뛰어난 아키텍트도 필요하고 회사의 개발문화 성숙도도 높아야 한다. 

 

빌딩을 빨리 만들겠다고 벽돌부터 서둘러 쌓아야 한다고 생각하는 사람은 없을 것이다. 기초공사와 설계가 잘되어야 어떤 방식으로든 빌딩을 빨리 만들 수 있다. 소프트웨어도 견고하고 확장성이 있는 아키텍처가 있어야 요구사항 변경에 대응이 잘되고 협업이 용이하며 개발 기간을 단축하고 비용도 절약할 수 있다. 

 

사실 무리한 일정 압박이 아키텍처에 큰 문제를 일으킨다는 것을 개발자 대부분은 잘 알고 있다. 그럼에도 '빨리빨리 문화'를 가속화시키는 주범은 따로 있다. 바로 경영자와 고객이다. 

 

대부분의 경영자에게 단기 성과는 생존 문제다. 회사 오너라면 조금 낫지만 많은 경영자들은 2년, 3년 단기 계약을 한다. 그 기간 안에 가시적인 성과를 내지 않으면 재계약이 어려워질 수 있다. 소프트웨어에 대한 깊은 이해도 부족하지만 미래를 고려할 시간은 더욱 없다. 6개월, 1년안에 성과를 내는 것이 가장 중요한 경영자는 영업이 가장 중요하고 단기 매출에 집착하며 아키텍처는 신경 쓸 여유가 없다. 

 

제대로 된 CTO가 있다면 CEO가 그렇게 마음대로 할 수는 없지만 우리나라에서는 CTO가 제대로 역할을 하기 어렵다. 

 

고객도 문제다. 우리나라 고객들은 이중적이다. 우리나라 개발사에는 버그를 당장 내일 고쳐줄 것을 요구하지만 글로벌 회사는 6개월 후에 고쳐주는 것을 고마워한다. 글로벌 회사는 아무리 얘기를 해도 빨리 고쳐주지 않는 다는 것을 알기 때문이다. 

 

우리나라 고객들은 개발자가 고객 회사에 들어와서 일해주기를 원한다. 스펙을 제대로 정리하고 효율적인 커뮤니케이션을 통해서 개발하는데 익숙하지 않기 때문에 옆에 앉혀놓고 종을 부리듯이 개발하기를 원한다. 

 

국내에서는 그런 고객의 입맛에 맞춰줘서 성공한 사례가 꽤 있다. 이런 문화는 국내 시장의 진입장벽이 되기도 한다. 그렇게 해서 우리나라에서는 1위에 등극했지만 이를 바탕으로 글로벌 시장으로 나아가는데는 큰 문제가 있다. 

 

개발문화가 비효율적이고 아키텍트의 역량이 떨어져서 세계 시장에서 패하는 경우가 많다. 그럼 외국 고객은 어떨까? 다는 아니지만 대부분 버그를 내일 고쳐 준다고 하면 의아하게 생각한다. 특히 매우 중요한 시스템이라면 이런 개발사의 신속한 대응은 오히려 개발사에 대한 신뢰를 떨어뜨리기도 한다. 

 

우리나라 개발사끼리는 이러한 고객 요구사항에 서로 잘 맞춰주겠다고 진흙탕싸움을 하고 있기 때문에 모두 다 힘들어지고 그 폐해는 고스란히 개발자에게 돌아간다. 개발자는 인간다운 삶을 포기해야 하기도 하고 그런 개발 환경에서는 개발자로서 성장하기도 힘들어진다. 

 

'빨리빨리 문화'가 바뀌기 어려운 것은 사실이다. 고객도, 경영자도, 개발자도 바뀌어야 한다. 내가 어떻게 세상을 바꾸겠는가? 하지만 세상을 바꾸는 첫걸음은 내가 바뀌는 것이다. 내가 바뀌는 것의 시작은 깨닫는 것이다. 지금은 당장 나만 바뀌면 나만 손해를 볼 것이다. 

 

하지만 내가 바뀌고 동료가 바뀌지 않으면 '빨리빨리 문화'는 영원히 바뀌지 않을 것이다. 회사에서 아키텍처의 중요성을 깨닫고 아키텍트를 키우고 영업과 개발의 균형을 유지하는데 노력하고 급하게보다는 제대로 빨리 개발하기 위한 방법들을 강구해야 한다. 

 

기반시스템, 방법론, 프로세스 모두 적절히 필요하다. 다른 여러가지 개발문화의 성숙도를 높여가는 것도 '빨리빨리 문화'를 고치는데 도움이 된다. 결국 우리가 바꿔 나가야 한다. 

 

'닭이 먼저냐 달걀이 먼저냐' 이슈와 비슷하지만 개발문화 성숙도 문제를 깨닫는 것만으로도 의미가 크다. 문화란 글이 아니라 경험을 통해서 배워야 하고 경험자에게 배워야 시행착오를 줄일 수 있다. 꾸준히 관심을 가지고 익히는 자세가 필요하다.



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



저작자 표시 비영리 변경 금지

전규현 개발문화 개발문화

Trackback Address: http://allofsoftware.net/trackback/325 관련글 쓰기

부실한 공유문화를 지배하는 개발자의 심리 (개발문화 시리즈2)

2013/10/17 20:22 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




본 글은 CNet 코리아에 기고한 칼럼입니다. (http://www.cnet.co.kr/view/25939)


본격적으로 소프트웨어 개발 문화에 대해서 얘기해보자.  첫번째는 ‘공유의 문화’다.


 회사마다  차이는 있지만  소프트웨어  회사에서  부실한  공유 문화는  많은  부작용의  원천이다. 여러 사람과 정보를 공유하는 것에 따른 장점은 여러가지다.  다양한 시각을 가진 이들의 의견이 반영되면서 프로젝트 리스크가 감소되는 건 물론 개발자는 자신이 해왔던 과거업무의 속박에서 벗어날 수 있다.


반대로 공유문화가 부실한 회사는 왜곡된 의사결정으로 프로젝트 리스크가 커지고, 아키텍쳐나 제품은 뒤죽박죽이 되는 경우가 많다. 개발자는 자신이 과거부터 해온 일들에 발목이 잡혀 고참이 되도 유지보수에 바쁘고 신참에게 일 시키기도 어렵다. 본인 스스로 고급개발자로 성장하기 어려운 구조라고 하겠다.


개발자가 수백명, 수천명인 회사나 개발자가 10명인 회사나 효율적인 공유없이 각자 일하는 것은 매한가지이다. 개발자가 수천명인 회사내부에서는 팀이 수백개가 아니고 회사가 수백개 있는 것 같은 현상이 벌어지기도 한다. 팀 내부 인원끼리는 서로 내용을 좀 아는데 다른 팀과는 공유가 매우 어렵다. 이를 개선하고자 개발 프로세스를 점점 복잡하게 만들기도 하지만 문화와 균형을 이루지 않은 개발 프로세스는 형식적으로 작동해서 효율도 떨어지고 개발자들에게는 짐이 될 뿐이다.


 겉으로는 공유를 주장하면서도 속으로는 공유를 꺼리는 개발자가 은근히 많다. 개발 내부의 아키텍처 문제나 골치 아픈 이슈들을 숨기고 시한폭탄으로 놔두는 경우도 있고, 바쁘다는 핑계로 또는 다른 사람은 이해하지 못할 정도로 어렵다는 이유를 대고 정보를 꼭 쥐고 있는 경우도 있다.


 전반적으로 공유문화가 부실하게 된 것은 현재 개발자들의 책임은 아니다. 원래 문화라는게 우리의 선조, 선배들이 만들어 놓은 것을  따르면서 아주 약간씩 바뀌는 것이다. 개발문화도 그렇다. 지금까지 선배들이 그런 환경에서 그렇게 일해 왔기 때문에 그런 문화가 형성되었고 우리도 거기에 적응해서 일하고 있는 것이다.


 문화가 바뀌기 어려운 이유는 나 혼자 노력해서는 안되기 때문이다. 다른 사람들은 공유를 위해서 노력하지 않고 나 혼자 애를 쓰면 나만 두배로 손해를 본다. 이는 ‘죄수 딜레마’와 비슷하다.


두 명의 사건 용의자가 체포되어 서로 격리되어 심문을 받으면 서로 간의 의사소통은 불가능하다. 이들은 자백 여부에 따라 다음의 선택이 가능하며 용의자들은 이를 알고 있다.


둘 중 하나가 배신하여 죄를 자백하면 자백한 사람은 즉시 풀어주고 나머지 한 명이 10년을 복역해야 한다.

둘 모두 서로를 배신하여 죄를 자백하면 둘 모두 5년을 복역한다.

둘 모두 죄를 자백하지 않으면 둘 모두 6개월을 복역한다.

 이 경우 서로를 믿고 협동하면 서로 이익이 되지만 대부분 서로 배신을 선택함으로써 나쁜 결과를 초래한다. 공유문화도 마찬가지다. 혼자서 공유한다고 애를 써도 다른 사람이 공유를 하지 않으면 혼자 고생만 하는 것이기 때문에 결국 서로 공유를 하지 않음으로써 서로 손해를 보는 결과를 선택한다는 것이다.


 공유문화는 소프트웨어 개발에 너무 중요하기 때문에 포기할 수는 없다. 그렇다고 노력하지 않고 효율적인 공유문화를 가질 수는 없다. 그냥 흘러가는 대로 놔두면 ‘죄수딜레마’는 어김없이 찾아온다. 개발자 입장에서는 능동적이고 주도적으로 공유문화를 만들어가기 어렵다. 일단은 습관이 되지 않은 상태에서 공유를 하려면 매우 어렵고 혼자만 공유를 잘하면 개발에 있어서 자신에 대한 의존도가 떨어지기 때문에 고민을 하기도 한다.


반대로 공유를 안하면 자신에 대한 의존도는 높아지지만 본인이 한 일에 발목이 잡혀서 성장이 어렵다. 여기까지 생각하는 개발자는 그리 많지 않다. 경영진이나 개발자나 모두 서로를 위해서 필요성을 깨닫고 제도적으로 의식적으로 오랫동안 각고의 노력을 해야 한다. 일단 문화가 자리잡고 나면 의식하지 않아도 저절로 공유를 하게 된다.


그러면 이제부터 많은 사람들이 왜 노력을 해도 공유에 실패를 하는지 2% 차이는 무엇인지 알아보자.


 첫째, 말로 하는 것보다 글로 적는데 익숙해져야 한다.


말로 대화하면서 개발하는 것이 더 효율적이라고 믿는 사람이 많지만 필자는 글로 적는 것이 더 효율적이라고 믿고 있다. 말은 오해도 많고 매번 다른 사람에게 다시 설명해야 하고 시간이 지나면 잊어버린다. 글로 써야 많은 사람에게 공유가 되고 리뷰가 가능하며 도움을 받을 수 있다. 글로 하는 커뮤니케이션은 기본적으로 공유의 준비가 다 되어 있는 것이다.


대화는 가장 비싼 수단이며 휘발성이 강하다. 대화가 아니면 해결하기 어려운 꼭 필요할 때와 대화가 가장 효율적일 때만 사용해야 한다. 글을 쓰는데 익숙하지 않은 개발자는 무조건 장황하게 쓰거나 개발자만 아는 어려운 용어를 사용해서 다른 사람이 이해하기 어렵게 만든다. 또 외계인의 언어처럼 도저히 이해가 안되는 문장구조를 사용하기도 한다.


처음부터 글쓰는 것은 거부하기도 한다. 개발문서는 소설처럼 감동을 줘야 하는 것이 아니기 때문에 잘만 훈련하면 개발자도 충분히 잘 쓸 수 있다. 신입 때부터 문서를 작성하는데 익숙해지면 된다. 그런 기회 없이 이미 고참이 되었다면 지금이라도 시작하면 된다. 깨닫는 것이 어렵지 지금이라도 노력하면 충분히 가능하다.


 둘째, 과도한 프로세스는 오히려 독약이다.


 대기업에서 많이 벌어지는 일인데, 현재 역량이나 문화수준을 훨씬 뛰어넘는 과도한 시스템과 프로세스를 도입해서 강요하곤 한다. 이런 경우 겉으로는 규칙을 지키고 비싼 시스템을 착실히 쓰는 것 같지만 속을 보면 형식적으로 따르고 흉내만 내서 효율은 오히려 더 떨어진다. 이런 일이 벌어지는 이유는 스스로의 역량이나 문화 수준을 과대평가 하기 때문이기도 하다.


제대로 된 CTO의 부재도 한몫 한다. 실전 경험이 부족한 SW 프로세스팀은 밑져야 본전 식으로 프로세스를 복잡하게 만들고 많은 문서를 요구하곤 한다. SW 프로세스팀도 이렇게 밖에 할 수 없는 많은 고충이 있다. 많은 문서 중에서 프로젝트에 실질적으로 필요한 문서는 한두개에 불과한 경우가 대부분이지만 회사에서는 나머지를 쉽게 포기하지 못한다. 이러다 보니 개발자들은 문서 따로 개발 따로 진행을 하고 문서는 개발에 별 도움도 안되고 공유의 목적으로도 의미가 없게 된다. 이런 식으로 문제가 발생하면 프로세스를 더 복잡하게 만드는 악순환이 진행된다.


 해결책은 스스로의 역량과 문화 수준을 정확하게 진단하는 것이다. 그리고 거기에 걸맞는 시스템, 프로세스를 도입해야 한다. 역량에 비하여 프로세스가 단순한 것은 큰 문제가 안되지만 반대의 경우는 더 비효율적이다. 지금처럼 과도한 프로세스를 계속 발전시키면 악순환에서 벗어나지 못하고 결국에는 10배 비효율적으로 개발을 해야 한다. 결코 프로세스로 모든 것을 해결할 수 없다는 것을 명심하자.


 셋째, 개발자 보고 알아서 잘 해보라고 하면 안된다.


 풀뿌리식으로 개선이 될 수 있는 사안이 아니다. 시스템과 프로세스도 필요하고 경영진의 의지와 후원이 절대적이다. 가장 중요한 것은 공유문화를 이끌 리더가 필요하다는 것이다. CTO급의 인물이 있어서 흐지부지 되기 쉬운 공유 문화 개혁에 꾸준한 추진력을 실어줄 수 있어야 한다. 역량 수준에 따라서 여러가지 시스템도 필요하다.


이슈관리시스템, 형상관리시스템, 코드리뷰도구, 위키, 지식관리시스템, 정보포털 등 여러가지가 있지만 모두 필요한 것은 아니다. 그리고 꼭 비싼 제품이 좋은 것은 아니다. 회사의 규모와 개발하는 소프트웨어의 성격에 따라서도 적절한 시스템이 다르다.


전문가의 도움을 받아서 가장 효율적인 프로세스와 시스템을 도입하는 것이 좋다. 프로세스와 시스템이 있다고 다 되는 것은 아니다. 임직원들의 마인드를 바꾸기 위해서 노력도 해야 하고 공유에 익숙하지 않은 직원들에게 효율적인 공유방법을 꾸준히 교육을 시키고 코칭을 해야 한다. 이는 매우 오래 걸리는 일이고 그래서 내부에 공유 문화 리더가 필요한 것이다.


 넷째, 나중에 몰아서 공유하면 실패한다.


 일기를 몰아서 쓰듯이 공유도 몰아서 하면 실패한다. 공유를 위해서 문서를 만들고 시스템에 기록을 하는 것이 목적이 되면 안된다. 이것들은 소프트웨어를 개발하는 과정이고 이렇게 개발을 해야 가장 빨리 효율적으로 개발할 수 있기 때문에 문서를 만들고 공유를 하는 것이다.


공유를 위해서 숙제를 하듯이 정리를 해서 시스템에 지식을 올리고 공유하는 것보다 매 순간 필요한 것들을 즉시 등록하는 것이 좋다. 공유할 것, 물어 볼 것, 의논해야 할 것들을 일단 적당한 시스템에 올려 놓고 진행을 하는 것이다. 그러면 자연스럽게 과정이 공유가 된다. 즉, 공유는 개발의 과정이고 일부이지 산출물, 부산물들이 아니다.


공유를 위해서 산출물을 만들어야 한다고 생각하는 순간 공유는 실패하고 산출물도 제대로 만들어 질리가 만무하다. 이렇게 만들어진 문서는 나중에 유지보수 시에도 활용도가 뚝 떨어진다. 공유목적으로도 실패한 것이다. 개발과정이 자연스러운 공유의 과정이 되도록 해야 한다.


 다섯째, 모든 사람이 다 너무 바쁘면 안된다.


 모든 개발자가 호떡집에 불난 것 같이 바쁜 회사가 많다. 가끔은 신입 개발자는 한가하고 고참들이 더 바쁜 경우도 있다. 이런 회사는 대부분 공유에 실패한다. 불 끄느라고 정신이 없어서 나머지는 눈에 들어오지도 않는다. 시니어 엔지니어가 될수록 시야도 넓어지고 생각도 많이 하고 여기저기 관여도 많이 해야 하기 때문에 정신없이 바쁘면 안된다.


손이 바쁘면 뇌는 느려진다. 코딩하느라고 바쁜 신입 개발자는 많아도 큰 문제가 없지만 고참들은 창의적인 생각도 많이 하고 타부서의 프로젝트도 파악하고 회사의 비즈니스도 알아야 하기 때문에 충분한 시간적 여유가 있어야 한다.고참 개발자는 공유를 가장 많이 하기도 하고 공유의 수혜자이기도 하다. 모든 사람이 모든 정보를 다 알 수는 없다. 자신의 레벨에서 공유하고 알아야 할 정보가 다르다. 고참 개발자의 손이 한가해지려면 이전에 공유를 잘 해왔어야 한다. 즉, 공유의 선순환이 필요하다.


 여섯째, 보안보다 공유가 우선이다.


 소프트웨어는 설계도면이 핵심이 아니다. 구성원들의 지식 공동체가 핵심이며 문서, 시스템, 경험, 지식의 복합체가 소프트웨어 회사 기술의 실체이다. 대부분의 SW회사는 HW분야에서 설계도면 빼돌리 듯 기술을 빼돌릴 수가 없다. 우리나라에서는 빈약한 공유문화 속에서 소수의 개발자가 거의 모든 정보를 독점하기 때문에 종종 기술을 빼돌리는 일이 벌어진다. 이런 상황에서는 보안을 아무리 강조해도 기술이 새나가는 것을 막을 수는 없다.


드물게 보안이 더 중요한 SW회사도 있기는 하지만 극소수에 불과하다. 보안에 대한 과도한 우려 때문에 공유를 너무 불편하게 하는 회사가 의외로 많다. 보안이 별 이슈도 아닌 회사도 공유에 거부감이 있는 직원의 주장에 넘어가서 공유를 포기한 회사도 많다. 훌륭한 오픈소스가 판치는 마당에 소프트웨어 회사에서는 숨길 것이 그렇게 많지 않다. 특수한 분야의 몇몇 회사를 제외하고는 모든 직원에게 모든 정보를 오픈해도 별 문제가 안된다. 보안을 과도하게 강조하여 공유에 제약을 가하기 시작하면 공유는 반쪽짜리가 되어서 효율은 엄청나게 떨어지게 된다.


 공유문화라는 것이 단어는 다들 잘 알고 있으면서 잘 안되는 대표적인 개발문화이다. 경험해보지 않으면 무엇을, 어떻게, 얼마나 자세히, 누구에게 공유하는데 잘 감이 잡히지 않는다. 위 여섯가지 가이드도 실전 적용을 해보고 자세히 들어가보면 아리송한 부분들이 많을 것이다. 그래도 시작이 반이라고 일단 시작을 해보자. 너무 큰 욕심은 경계하자.


회사에서는 꾸준히 투자를 해야 하며 처음에는 제도적으로 시작을 했다가 점점 습관화를 해 나가야 한다. 오래 걸리는 일이니 너무 근시안적으로 보지 말고 꾸준히 노력해야 한다.


저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/324 관련글 쓰기

왜 적은 인원으로 빨리 개발하나…개발문화의 비밀 (개발문화 시리즈 1)

2013/10/01 21:16 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




우리나라에서 소프트웨어 개발이 3D 취급을 받는 이유는 여러가지다. 끝을 모를 야근과 낮은 대우 등도 포함되겠지만 좀더 근본적인 이유는 따로 있다.  낮은 생산성 때문이다. 소프트웨어를 개발해서 회사가 돈을 많이 벌고 세계적으로 성공하는 소프트웨어가 많이 나온다면 생산성의 핵심인 개발자에게 당연히 높은 대우를 해주게 마련이다.


하지만 우리나라에서는 크게 성공한 소프트웨어 회사가 많지 않다. 그리고 소프트웨어 회사의 수익률이 별로 높지 않기 때문에 소프트웨어 개발자에게 좋은 대우를 해줄 수 없다. 결국 이런 소프트웨어 개발에 대한 낮은 대우를 극복하기 위해서는 성공하는 소프트웨어, 성공하는 회사가 많이 나와야 한다.


 그럼 성공하는 소프트웨어 회사와 그렇지 못한 회사를 가르는 결정적인 차이는 무엇일까? 판단의 요소는 기술적인 것 외에도 많다. 좋은 아이디어, 적절한 타이밍, 경영, 마케팅 등이 더 중요하지만 이런 것들은 내가 논할 주제는 아니다. 나는 같은 조건에서도 성공하기도 하고 실패하기도 하는 차이가 무엇인지 알아보고자 한다. 성공하는 회사의 특징을 가진 회사가 많다면 성공하는 소프트웨어가 더 많이 나오고 우리나라에서도 소프트웨어 개발이 좀더 좋은 대우를 받을 수 있을 것이다.


 하지만 회사마다 제품이 다르고 환경이 달라서 직접적인 비교는 매우 어렵다. 같은 제품을 만드는 회사라도 다른 요소로 인해서 성공과 실패가 갈렸을 수도 있다. 그런데 필자가 알고 있는 비교하기 좋은 사례가 하나 있어 이를 소개한다.


미국의 유명한 글로벌 소프트웨어 업체가 하나 있다. 이 회사는 여러 나라에 지사를 설립했다. 물론 한국에도 지사를 설립해서 개발자를 채용했다. 한국에서 채용한 개발자들은 본사의 서비스를 지역화(Localization)하거나 한국에 특화된 서비스를 개발했다. 미국 본사에서는 한국에서도 소프트웨어를 개발할 때 본사의 프로세스를 따르도록 종용했으나 한국 개발자들은 이를 따르지 않았다. 한국의 개발자들이 보기에 본사 프로세스는 너무 복잡해 보였다.


이와 관련해 처음에는 본사와 한국 개발자들간 충돌이 있었으나 상황은 곧 바뀌었다고 한다. 본사에서 한국 개발자들의 놀라운 개발 속도에 깜짝 놀라서 더 이상 본사의 프로세스를 강요하지 않았다. 초기에는 척척 빠른 속도로 개발을 하다보니, 모든 상황이 좋았다고 한다. 그런데 몇 년이 지나자 완전히 상황이 또 바뀌었다고 한다. 개발이 너무 느려진 것이다. 그 당시 본사는 호주에도 지사가 있었는데, 한국 지사와 비슷한 일을 하고 있었다.


한국 지사는 호주 지사보다 10배 가까운 개발자를 보유하고 있었고, 개발자들이 야근을 거듭해도 호주지사의 개발속도를 따라가지 못했다고 한다. 자세히 파헤쳐보면 더 많은 사연들이 있겠지만 맥락만 봐도 우리나라에서 소프트웨어를 개발하는 방식의 낮은 생산성을 짐작하게 한다.


 물론 모든 회사가 문제가 있다는 것이 아니다. 우리나라에도 좋은 개발문화를 가진 회사가 많다. 상대적으로 그렇지 않은 회사가 많기 때문에 제기하는 문제로 이해해 줬으면 하는 바람이다.


나는 한국지사의 개발자들이 본사의 개발 프로세스를 따르지 않은 것이 문제의 주된 원인이라고 생각하지 않는다. 이렇게 대응한 한국의 개발자들을 비난하려는 것이 아니다. 한국 개발자들은 몸에 베어 있는 개발문화 때문에 본사 프로세스를 따르기도 쉽지 않다. 그런 개발문화와 습관을 익히게 된 우리의 개발 환경이 문제인 것이다.


한국에서 개발을 하다가 실리콘밸리 소프트웨어 회사에 취직을 한 개발자 중에는 개발 문화와 프로세스에 적응하는데 힘들어하는 사람들이 많다. 하지만 문화란 원래 작은 부분이 큰 부분에 흡수되듯이 한 개인은 모든 사람이 공통으로 행동하는 개발문화에 흡수되기 마련이다. 반대로 실리콘밸리의 아무리 뛰어난 개발자라도 우리나라에 오게 되면 꼼짝없이 한국식 개발문화에 적응해야 한다. 본인의 방법으로는 더 이상 어찌해볼 수 없는 상황이 된다.


필자는 한국적인 개발문화부터 실리콘밸리의 개발문화와 관료화된 거대 개발프로세스까지 직간접적으로 다양한 경험을 한 덕에 이를 서로 비교할 수 있다. 그래서 앞으로 효율적인 개발문화에 대해서 구체적으로 얘기를 해보고자 한다.


문화란 한 사회의 구성원들의 주요한 공통된 행동 양식이다. 개발문화는 소프트웨어를 개발하는 구성원들의 공통된 생각과 행동 양식이다. 프로세스처럼 명문화되어 있지는 않지만 대체로 그렇게 행동을 하는 것을 말한다. 우리나라의 개발문화는 형편없다고 주장하려는 것이 아니다. 우리나라의 문화가 더 훌륭한 부분도 있고 장점도 많다. 사실 문제가 되는 부분은 2%에 불과할 수도 있다.


이런 결정적인 결과의 차이를 만들어내는 주요 개발문화의 차이를 비교해보자.


개발 프로세스와 개발문화는 서로 보완적이며 개발문화 없이 효율적인 개발프로세스를 만들기 어렵다. 개발문화가 있다고 개발 프로세스가 필요 없는 것도 아니다. 반대로 아무리 정교한 개발 프로세스가 있어도 개발문화가 뒷받침되지 않으면 개발프로세스는 방해만 될 뿐이다. 그만큼 개발문화는 개발 프로세스보다 중요하다.


그럼 이런 차이를 만드는 개발 문화에는 어떤 것들이 있을까? 지금은 하나씩 나열만 해보고 다음 회부터 각각의 사항에 대해 좀더 자세히 풀어볼까 한다.


첫째, 공유 문화의 부족이다.


사실 우리나라에도 공유문화가 없는 것은 아니다. 하지만 결정적인 차이가 있다. 그 차이를 앞으로 얘기해보겠다.


둘째, 빨리빨리 문화다.


장기적인 고려 없이 무조건 빨리 하는 것은 단기적으로는 빠른 성과를 낼 수 있어도 장기적으로는 몇배 더 느려진다. 다른 산업분야에서는 톡톡히 효과를 봤어도 소프트웨어는 워낙 복잡한 지식 산업이라 빨리빨리 문화가 종종 큰 문제를 야기한다.


셋째, 전문가 vs. 만능 개발자이다.


소프트웨어 산업에서는 전문가에 대한 인식이 떨어진다. 뭐든지 잘하는 만능 개발자를 선호하며 그러다 보니 뛰어난 개발자도 본연의 업무인 개발에 집중하지 못하고 다른 일에 휘둘리다보니 회사는 효율이 떨어지고 개인의 캐리어는 발전하지 못한다.


넷째, 사람 중심 vs. 시스템 중심이다.


다른 분야도 마찬가지이지만 사람 중심의 개발은 리스크를 증가시키며 대체도 어렵게 만든다. 대체 못하는 개발자는 회사와 개발자 서로가 서로의 발목을 잡는 상황이 된다.


다섯째, 규칙 준수 문화 부족이다.


사회 전반의 문제지만 소프트웨어 회사에서는 규칙을 무시하는 사람들이 많다. 특히 조직의 윗선에서 이러한 현상이 더 심각해진다.


여섯째, 서열 중심 문화이다.


전통적으로 수직적인 조직문화가 소프트웨어 개발에는 문제가 된다. 어떻게 해야 이를 극복할 수 있을지 알아보겠다.


일곱째, 낙후된 토론 문화이다.


요즘은 토론 위주의 교육에 신경을 많이 쓰면서 개선되고 있지만 여전히 토론문화는 많이 부족하다.


우선 생각나는 것은 이 정도이며 앞으로 이것들을 포함하여 개선해야 할 여러 개발문화 대해서 하나하나 구체적으로 얘기를 해보고자 한다. 새로운 내용이 있으면 계속 추가해 나갈 계획이다.


그런데 이런 얘기를 시작하면 종종“우리도 해봤는데 안되더라는 얘기를 많이 듣는다. 우리도 공유해보려고 했는데 잘 안 안된다. 우리와는 안맞는다, 그렇게 피해의식을 가진 선배개발자들이 많아서 새로운 시도가 처음부터 막히는 경우가 많다. 대부분은 잘못 시도했거나 의지가 부족해서 실패한 경우가 많다. 이렇게 피해의식이 가득찬 회사는 바뀌기 어렵고 그 끝은 뻔하다. 그렇지 않고 개발문화를 조금씩 바꿔가고 싶은 사람들에게는 도움이 되길 바란다.


개발문화는 조직 전체를 바꿔야 하는 것이기 때문에 한명의 개발자가 몸부림친다고 쉽게 바뀌지는 않는다. 경영자나 중간관리자가 움직여줘야 한다. 회사를 움직일 수 있는 경험과 힘이 있어야 변화를 시켜 나갈 수 있다. 이런 분들에게도 많이 공유가 되면 좋겠다.


워낙 광범위한 주제이기 때문에 독자 여러분들과 많은 의견을 나누면서 얘기를 발전시켜나가면 좋겠다. 구체적인 얘기가 시작될 다음 칼럼에도 많은 관심 부탁드린다.


CNET 코리아에 기고한 칼럼입니다. (http://www.cnet.co.kr/view/25148)



저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/323 관련글 쓰기
  1. Blog Icon

    비밀댓글입니다

  2. 경영자나 상위관리자 레벨에서 변화해야한다는데 공감이가네요. 우리나라와같이 탑다운의 중앙집권적인 기업구조에선 특히나....

생각의 폭을 넓혀야 한다.

2013/09/09 06:00 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



우리나라에서 Global Software가 많이 탄생하지 않는 이유 중 하나는 개발자의 생각의 넓이가 좁기 때문이다. 물론 우리나라에도 뛰어난 아키텍트들도 있지만 생각이 넓이가 좁고 단편적이고 지엽적인 생각에 갇힌 개발자들도 매우 많다.


뛰어난 아키텍트라면 소프트웨어의 Scalability를 항상 생각한다. 물론 모든 상황에서 모든 Scalabiltity를 생각하는 것은 아니다. 비즈니스 계획 및 전략을 고려하여 가능성을 모두 검토한다.


지금보다 고객이 100배로 늘어난다면?

지원하는 국가 및 언어가 100배로 늘어난다면?

다뤄야할 데이터가 100배, 10,000배로 늘어난다면?

소스코드의 크기가 100배로 늘어난다면?

개발자가 100배로 늘어난다면?

고객과의 거리가 100배, 10,000배로 늘어난다며?


아키텍처는 이런 Scalability를 충분히 고려해서 설계를 해야 한다. 또한 프로세스를 자동화 해야 한다. 이렇게 여러분야에서 100배씩 늘어간다면 복잡도는 수천, 수만배 복잡해지는데 자동화를 하지 않으면 그 배수만큼 고스란히 비용이 발생한다.


여기서 국내 소프트웨어 회사와 글로벌 소프트웨어 회사의 차이가 많이 발생한다. 여러분도 다 아시는 국내 포탈회사는 아직도 많은 부분을 수동에 의존하고 있고 물론 고객도 그렇게 수동으로 관리된 컨텐츠를 좋아하고 있다. 그러다 보니 글로벌 시장에서 경쟁은 점점 어려워지고 있다. 로컬 1등 기업을 될 수 있어도 글로벌 유망 기업은 되기 어려운 이유 중 하나이다. 


많은 개발자들은 제품 초기에 아무런 비즈니스 전략 없이 대충 만들어 놓았다가 비즈니스가 잘되면 더 어려워지는 경우가 흔다. 개발자들이 생각의 폭을 좀더 넓혀야 한다.


image by ASA Goddard Photo and Video


저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/322 관련글 쓰기
소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

외국에서 팔리는 소프트웨어 만들기 위한 소프트웨어 국제화 (1)

가장 먼저 소프트웨어 국제화에 대한 이야기로 글을 시작하려고 한다. 오래 전부터 소프트웨어 세계에는 국경이 없었다. 거의 모든 사람들은 수십 나라에서 개발된 다국적 소프트웨어를 사용하고 있다. 앱을 하나 개발해서 앱스토어에..

나쁜 프로그래머가 되는 18가지 방법

소프트웨어 개발자는 끊임없이 변화하면서 성장한다. 스스로 길을 잘 찾아서 성장하는 경우도 있고, 좋은 환경에서 개발을 하다 보니 자연스럽게 실력이 향상되기도 한다. 하지만 열악한 환경에서 열심히 일만하다가 개발자로서의 실력은..

빈 줄도 지워서는 안된다.

SVN을 쓸까? Git를 쓸까? 주제로 얘기를 하면 논쟁이 심하다. 하지만 이보다 더 중요한 것은 SVN이나 Git와 상관없이 어떻게 하면 여러 개발자들과 협업이 잘 되도록 코딩을 하느냐다. 많은 개발자들은 혼자서 또는 소수..

55세 개발자가 막내인 개발팀

얼마전 미국 소프트웨어 회사인 P사의 호주 지사에서 일하고 있는 엔지니어를 만나서 얘기를 나눴다. P사는 본사가 캘리포니아에 있고 전체 개발자 수는100여명이다. 그리 크지 않은 회사지만 20년동안 꾸준히 성장을 해왔고, 소..

개발자간 공유 문화 정착이 힘든 이유

소프트웨어를 개발하는데 있어서 가장 중요한 문화 중 하나는 '공유’ 문화라고 할 수 있다. 소프트웨어 개발 속도를 향상하고 비용을 절감하며 프로젝트 성공 확률을 높이는 중요 요소다. 뿐만 아니라 개발자들의 실력을 향상하고 개..

야근, “악의 균형”

어떤 경영자는 “우리 회사 개발실은 밤이나 주말이나 불이 켜져 있다”고 자랑을 한다. 6개월간 개발자들이 집에도 못 들어가면서 프로젝트를 하고 있는 것을 자랑스럽게 얘기하기도 한다. 오랜 야근으로 이혼에 이르게 된 개발자를..