모든 것엔 적정선이 있기 마련이다. 가끔 프로젝트를 진행하다보면 개발자로 인하여 프로젝트가 망가지는 케이스를 심심찮게 볼 수 있다. 이 모든 건 사실 기획레벨에서 개발에 대한 지식이 부족하여서이겠지만, 그래도 개발 멤버들이 반성해야될 부분도 많다. 개발미스로 프로젝트가 망가지는 건 크게 두가지로 분류할 수 있다. 개발력이 프로젝트에 비해 딸려서거나, 그 반대로 프로젝트에 비해 개발력이 과도해서이다.
0
1. 자주 지각하는 개발자
지각은 왜 하는 것일까. 살펴본 결과 몇가지 케이스가 있었다.
개발은 협업적인 측면도 강하지만, 협업할 포인트만 정확히 짚어내면 기본적으로는 개인의 일에 가깝다. 즉, 모듈과 모듈와 연결고리만 정확하게 정의한다면 나머지는 개발자 개인의 일이 된다. 이렇다보니 개발자는 협업에 대한 기본을 망각하기 쉽다. 회사 전체에 대한 개념 없이 '내 할일만 하면 끝이지'란 마인드가 생기는 경우가 있다. 이것이 지각이 만연하게 되는 첫번째 이유다.
한편, 다른 원인으로는 자기관리의 미숙이 있다. 일정한 기상시간을 유지못한다던가, 반대로 일정한 퇴근시간을 유지못하여 누가 시키지도 않은 밤샘작업후에 이틀간 결근을 한다던가 하는 케이스도 웃지 못할 케이스도 많다. 지나치게 일에 열중하여 자신의 페이스를 유지못하는 것은 일을 잘하는 것이 아니라 일을 내팽겨치는 것이다. 결코 이런 케이스에 '너무 열심히 하면 그럴 수도 있지. 다들 본받아요' 라는 메세지를 던져주면 그 회사는 곧 아무도 나오지 않는 회사가 될 것이다.
지각이란 전염되는 측면이 강하다. 필자가 본 한 회사에서는 개발팀장이 자주 지각하더니 성실한 인턴조차 곧 전부 지각하는 현상을 보였다.
사실 이 기저에 깔린 문제는 지각을 용인하는 문화에 있다. 개발물이라는 것은 대체되지 않는다. A, B 기획자가 사장에게 기획발표를 했을때, A발표자가 지각했다면 패널티를 적용하여 B의 기획안을 채택할 수 있다. 그러나 A개발자가 DB모듈, B개발자가 웹모듈을 개발하여 개발발표를 하였을 때 B개발자가 회의에 늦었다고 해서 웹 모듈을 빼고 제품을 출시할 수는 없다. 이러다보니 회사에서는 개발자의 지각에 대해 관대해지기 쉽상이다. 그리고 개발자는 자신의 지각에 대한 변명으로 창의적 회사 분위기를 운운하지만, 사실 생각해보면 지각만큼 회사 분위기를 좀먹는 케이스도 없다.
물론 몇몇 회사의 경우 아예 출퇴근 관리를 개인에게 맡기는 경우도 있다. 특히 연구소와 같은 곳은 지각에 관대해도 큰 문제가 없다. 그러나 반드시 명심해야할 것이 하나 있다. 이런 조직의 경우 대다수 상당히 해고가 자유롭다는 것이다.
창의적인 문화로 칭송받는 세계적 대기업인 A사의 예를 들어보자. 특정한 일을 던져주고, 몇월 몇일까지 해결하라고 한 다음, 실패할 경우 인력을 교체한다던가 개인에게 강력한 패널티를 준다. 문제만 해결할 수 있다면 몇시에 출근하든 몇시에 퇴근하든 신경쓰지 않는다. 급여는 상당히 높다. 언론엔 창의적 회사로 소개된다 (그리고 물론 대학생들도 그걸 믿는다). 그러면 이제 이 회사의 어두운면을 보자. 구성원 대다수는 비정규직이다. 언제 어떻게 짤릴지 모르니 무조건 열심히 하는 수 밖에는 답이 없다. 회사에 들어오고 싶어하는 사람들도 줄을 서 있다. 회사가 사람을 키운다거나 그런 환상은 갖지 않는다. 싹수가 보이는 성실한 인력을 채용할 필요 없다. 좋은 대학의 박사과정을 뽑아서, 필요한 것을 시킨다음, 능력이 고갈되면 회사를 그만두게 하면 된다. (삼성의 경우 성실한 인재를 우선으로 채용한다. 그러나 구글의 경우엔 이미 포지션에 딱 맞는 인재를 영입하는 것이 자신의 인재방침이라고 공공연하게 밝혔다.)
지각 문제를 해결하는 딱히 좋은 방법은 없다. 지각이라는 것은 경고를 아무리 준다고 해도 고쳐지지 않는 습관인 경우가 대다수이다. 벌금제를 채택하면 회사 분위기도 안좋아진다. 해고 외에 좋은 방법을 찾아내긴 어려울 것이다.
0
2. 일정관리 안되는 개발자
'지난주 까지 개발하기로 했는데, 왜 아직도 안되었죠?'
'아 거의 다 되었는데 - 지금 이 모듈만 붙이면 됩니다. 다음주 화요일까지는 될겁니다'
이건 그냥 안된거다. 80%가 되었던 20%가 되었던 안된것은 마찬가지다. 개발을 하다보면 급작스런 이슈사항이 발생할 수 있다. 그러나 그에 대해 사전 보고가 올라가지 않았고, 당일에서야 미안하다면서 머리를 긁적이는 개발자. 프로젝트를 망치는 일 순위다. 그러나 잘 들어보면 역시 이유가 있다. '지금 서버에 깔려있는 우분투와 지금 쓰고있는 라이브러리가 충돌해서' 라던가, '제가 XX를 YY인줄알았는데 잘 못 생각했네요' 라던가. 그러나 다음주 화요일이 되면, 또다시 새로운 이슈가 발생할 것이고, 개발은 역시 늦어질 것이다. 이는 프로젝트 관리나 기획의 문제라기보단 개발자 개인의 문제 요소다. 보통 이런 개발자들은 자신이 아는 기술 대신에 새로운 기술을 도입하려다가 회사를 망하게 하는 경우가 많다.
통계적으로 개발자는 자신의 능력을 실제 능력보다 40% 정도 과장하여 생각한다고 한다. 이것은 감안하여 개발스케쥴을 짜야 한다. 그러나 어떤 개발자는 자신의 능력을 100% 200% 과장하여 생각하는 경우도 있다. 이것 또한 해결 방법은 없다. 프로젝트 일정은 끝없이 지연될 것이다. 최대한 빨리 프로젝트를 그만두는 것이 상책이다.
0
3. 트래픽, 보안에 신경쓰는 개발자
Paypal 에서 이런이런 보안을 채택했다고 해서 자신이 개발하는 서비스에도 이런 저런 보안 모듈 넣치 않으면 소비자 신뢰가 깨질 것이라는 환상갖는 개발자. 역시 있다.
언제나 적정기술이 중요하다. 만약에 가진 돈이 백만원밖에 없다면, 천만원짜리 금고를 사는 바보는 없을 것이다. 그러나 이용자가 얼마나 될지도 모르는 서비스에 보안때문에 이삼일씩이나 소비하는 개발자는 많다. 일정관리가 안된다면 이 이삼일은 일주일로 늘 것이다. 더 큰 문제는 이런 필요없는 코드때문에 향후 개발속도가 더 느려진다는 것에 있다. 예를들어 개발중인 프로젝트의 통신모듈에 SSL을 붙였다고 생각해보자. 앞으로 이 프로젝트는 패킷을 잡아서 디버깅을 하기 위해서는 일일이 SSL을 뺀 후, 수정하고, 다시 SSL을 붙이는 작업을 반복해야 할 것이다. 이런 작업은 유져가 늘어난 다음 해도 충분하다. 카카오톡 역시 보안이 추가 된 것은 이미 크래킹방법이 널리 퍼진 이후였다.
서버가 해킹을 당하면 기획자는 진심으로 기뻐하며 보도자료를 내면 된다. 만약 출시하는 서비스가 기존에 없던 새로운 서비스라면, 이보다 더 확실한 광고효과는 잘 없을 것이다. 카카오톡의 패킷 스니핑은 네이버 뉴스의 톱도 차지했다. 그러나 유져는 그 누구도 그것때문에 카카오톡의 신뢰성을 떨어뜨리지 않았다.
트래픽도 마찬가지다. 트래픽의 기본은 '맞은 다음 해결한다' 이다. 사용자가 얼마나 될지도 모르는데 애시당초 분산서버 며 캐쉬며 고민 할 필요 없다. 심지어 요즘 클라우드 서비스들은 클릭 한번에 프로세스 늘려주고, 캐쉬달아주지 않던가. 만약에 대기업이라면 분산서버도, 보안도 중요하다. 그러나 스타트업계는 빠르게 만들고, 소비자에게 보여주고, 피드백 받아서 수정하는 것보다 중요한 미덕은 없다. 그 외에 모든 것은 잊어버려야 한다. 보안이나 트래픽때문에 코드 한 줄이라도 쓸데없는데에 낭비되어선 안된다. 디버깅에 걸리적거리기만 할 뿐이다.
어떤 분은 myspace 의 예로 트래픽 관리의 중요성을 말할 지도 모르겠다. 그러나 myspace가 실패한 이유는 트래픽을 맞아서가 아니라 맞은 트래픽 문제에 대한 해결을 실패했기 때문이다. 트래픽 맞은 다음에 해결하면 된다. ( 이는 기획력의 차이일 수도 있다. 왜 Facebook이 학교별로 가입자를 오픈하였는지 잊지 말자. )
0
4. 확장성에 신경쓰는 개발자
대기업에서 뭔가 만든다면 트래픽, 보안뿐 아니라 확장성에도 신경써야한다. 프로젝트가 쉽사리 접히지 않기 때문이다. 그러나 스타트업계에선 확장성은 필요없다. 데모만들고, 서버 돌려보는 것이 가장 중요한 일이다. 그러다가 트래픽 몰리면 한밤중에 서버 내리고 모듈 교체하면 된다. 필자가 참여했던 한 프로젝트의 경우, php-mysql 을 쓰고 있었는데 개발팀장은 cubrid DB확장까지 고민하면서 프로그램을 짜고 있었다. 결국 사용자가 100명도 넘지 못했던 이 상용 웹 서비스는 빠르게 pivot 할 수 있는 기회를 잡을 수 있는 대신에 쓸데없는 개발리소스만 잔뜩 투입된채 우울한 시간을 보내야만 했다.
0
5. 너무 오래된 기술의 사용
개발자 한명이 추가로 투입되었다고 치자. 기존 소스를 어떻게 빨리 따라갈 수 있을까? 방법은 표준화를 하는 것이다. 이를 위하여 많은 모델들이 나와있다. MVC가 대표적 방식이다.
얼마전에 고벤쳐에서 필자가 직접 발표를 하기도 했었다. 지금 시대가 2012년인데 아직도 php를 쓰는 개발자가 많다. 물론 SNS사이트나 백엔드서비스와 같이 페이지 숫자가 많지 않은 방법엔 빠르고 간단하게 개발할 수 있는 php가 좋다. (필자도 다이어트헬퍼라는 앱 개발의 백엔드는 php를 사용하였다). php의 모듈 분리가 정확하게 될 경우는 상당히 인상적인 퍼포먼스를 보인다. 회사의 최고개발자가 php에 상당히 능숙하며, 소규모 개발팀을 운영하고 있다면 php는 좋은 선택이다.
그러나 요즘 신규로 출시되는 대다수의 서비스들 - C2C 마켓플레이스등 - 의 개발외주에서 php를 쓴다는 것은 납득하기 어렵다. 웹서비스 개발외주를 주었더니 코드 유지가 안된 분이 상담해오면 소스는 100% php로 되어있다. MVC툴도 적용되지 않는다. 이 경우 딱히 해줄 말이 없다. '코드 전부 갈아엎으세요. 외주 개발비 버렸다 치고 처음부터 다시하세요' .
0
6. 너무 앞선 기술의 사용
한 VC인터뷰에서 면접관이 물었다 한다. '요즘 가장 핫한 개발언어는 무엇인가' 쩔쩔매는 면접자에게 면접관이 말했다. '얼랭이지. 자넨 그것도 모르면서 VC하겠다고 하나?'
안좋은 케이스의 대표적 예로 너무 앞선 기술을 쓰려는 개발자나 기획자가 있다. 최근 얼랭에 대한 이야기가 나온다고 그걸 심각하게 도입하려는 기획자나 개발자는 자기 만족 이외에 아무것도 얻을 수 없을 것이다. 대체 그 코드를 누구에게 넘겨줄 것인가. 대표이사이자 최대주주이자 CTO이자 모든 개발을 혼자 하는 슈퍼프로그래머 정도 쓸 수 있을 것이다. 아니면 대기업정도. 남들 다 쓰는 Python, ruby, Obj-C, Java 써서 개발하면 된다. 한국 Go 언어(구글에서 개발한 언어)의 선구자는 먹고살고 또 여유시간있는 NHN이나 삼성전자 개발자들이 맡으면 된다.
남들이 쓰지 않는 기술은 아무리 좋더라도 쓰지 않는게 좋다. 그리고 가장 핫한 언어는 2002년이나 2012년이나 C언어다. ( Java도 Obj-C도 C 에 대한 이해 없이 쓸 수 있을지 의문이다. Ruby도 마찬가지다. )
안정성에 관한 문제도 마찬가지다. 어떤 개발팀의 한 개발자는 알파버젼의 리눅스를 쓰다가 서비스 릴리즈 한달여를 남기고 컴퓨터가 먹통이 되어 포맷해야되는 상황이 발생하였다. 자신의 일을 독립적으로 해야하며 상부통제는 개발문화에 반대된다던 이 개발자는. Git 서버에 업로드하라는 상부 지시도 무시한 채 열심히 개발하다가 소스를 모두 날려버렸다. 서비스 개발은 무기한 연장되었다. 이러한 일이 반복되자 회사는 결국 프로젝트를 포기했다. 책임없는 개발자의 전형적 모습이다. 농담일거 같은가? 최근 한 스타트업에서 발생한 실화 사건이다.
0
그렇다면 반대로 프로덕트를 살리는 좋은 개발자는 어떤 모습일까.
무엇보다 프로덕트를 제 시간에 맞춰 빨리 만드는 개발자다. 새로운 기술 적용한다고 시간 보내지도 않고, 너무 낡은 기술을 사용하지도 않는다. 기술들은 Git, WebFramework, Redmine 류의 ticket 시스템정도면 충분하다. 새로운 기술을 도입하기보단 이미 확실한 기술들을 조합하여 라이브러리를 구축한다. 형상관리툴은 github 에서 해결하고, 서버는 amazon ec2 정도 사용하면 충분하다. 이런걸 조합하여 목표까지 가장 빠른 개발 방식을 택하면 된다.
스타트업계 개발의 핵심은 encapsulation 과 code-reuse로 인한 빠른 개발이다. 성능의 최적화나 보안은 신경쓰지 않아도 된다 (어차피 기획되는 제품의 90%는 아무도 사용하지 않는다).
코드의 예를 한 번 보자.
만약 obj-c 에서 sqlite3 에 있는 메일 데이타를 가지고 온다고 생각해보자. 어떤 개발자는 sqlite3 라이브러리와 '?' 마크를 이용하여 일일이 데이타를 빼낼 것이다. 변수 설정하고, 일일이 테이블 확인하고, 바인딩해서 데이타 가져온다. 이는 가장 확실한 성능을 보일수 있지만 스타트업계에서 사용하기엔 좋지 않은 방법이다. 어떤 개발자는 코어데이타를 사용하여 코딩할 것이다. 그나마 나은 방법이라고 할 수 있다. 그러나 필자가 가장 추천하는 스타트업계의 코딩은 KVC를 이용한 encapsulation 이다. 다음은 실제로 필자가 DB에서 데이타를 가지고 오기 위하여 사용한 코드이다.
| NSString *sql=[NSString stringWithFormat:@"SELECT * from messages where mailbox=%d", mailbox];
Mail *mail=[[Mail alloc] init]; NSArray *arr=[sqliteDb selectWithQry:sql object:mail]; |
프로그램에선 이렇게만 처리하면 라이브러리 레벨에선 DB칼럼 타입을 조사하고, DB필드명을 조사한다음 이에 맞는 데이터를 DB에서 가져오고, Mail Object를 필요한 수만큼 NSCopyingProtocol 을 사용하여 copy한다. 그 후에는 DB칼럼명과 동일한 오브젝트 변수명에 Key-Value를 이용하여 데이타를 입력한다. 라이브러리가 복잡한 대신, 어플리케이션의 코드량은 단 세줄로 끝나게 된다 (where 구문만 없다면 단 한줄로 처리할수도 있다. SQL도 내부에서 해결하면 되니까.). sqlite3 api를 사용하여 수십라인을 허용하는 것보다 훨씬 빠른 방법이다.
소켓 통신모듈은 어떨까. 어차피 뽑아져나오는 데이타가 동일하다면 아이폰-안드로이드-서버의 동시개발을 위하여 JNI의 도입을 검토할 수도 있다. 만약 아이폰과 서버는 C, 안드로이드는 Java를 채택하기로 했다면 최대한 소켓 규격을 표준화시키고 여기저기서 데이타 필드를 낭비하면서 강력한 Code Reuse를 하여 개발 스케쥴을 당겨야한다.
개인적으로 스타트업계의 기술과 대기업의 기술 방식은 상당히 차이가 있다고 본다. 스타트업계의 경우 성능을 돈으로 해결하는 프로세스가 맞다고 보며, 대기업의 경우는 인력을 돈으로 해결하는 것이 맞는 프로세스다. 대기업은 사람을 데리고올 수 있고, 마케팅이 확실하며, 제품에 신뢰를 잃지 않는 것이 중요하다. 그러나 스타트업은 신뢰를 잃지 않는게 중요한 것이 아니라, 실제로 제품을 만들고, 이런 제품이 있다는 것을 알리고, 제품이 돌아간다는 것을 보여주는 데에 모든 역량을 집중한다는 것이 옳다. 그 다음은, 그 다음에 생각해야한다. 한번에 여러 생각을 하면 단 한가지도 제대로 돌아가지 않는다.
100명이 들어올지도 모르는 사이트에 10만명이 들어오면 이런저런 비지니스를 하겠다고 떠드는 기획자가 많다. 개발자도 비슷한다. 100명이 들어올지도 모르는 사이트에 10만UV를 대비하여 분산서버기술을 고려하여 제품을 설계할 필요는 없다. 한달에 만원짜리 서버 네대 늘려도 한달에 오만원이다. 자원을 낭비하라. 대신에 시간을 절약하라. 프로젝트를 살릴려면 빠르게 진도를 뽑아서 '되고 있구나' 라는 인식을 심어주어야한다. 그리고 그 가속도로 개발을 진행시켜야 된다.-by 보통개발자
- 보통 개발자, 글의 원문과 저작권은 jokeya.blog.me 에 있습니다.
