상현이는 최신 코어 2 듀오 CPU가 장착된 PC를 새로 구입한 기념으로 C# 프로그램을 하나 작성했습니다.
4바이트 짜리 int 데이터를 Java로 작성된 프로그램에 TCP/IP를 이용하여 보내는
간단한 프로그램('클라이언트'라고 합시다.)이지요. Java로 작성된 프로그램 역시
패킷을 받아 패킷에 담긴 데이터를 콘솔에 출력하기만 하는 단순한 프로그램('서버'라고
합시다.)이고요. 서버는 옛날에 구입한 센트리노 CPU가 장착된 노트북에 설치되었습니다.
상현이는 순식간에 코드를 작성해서 컴파일을 마쳤습니다. 그리고
클라이언트와 서버 프로그램을 띄우고 클라이언트에서 118(10진수)을 보냈습니다.
그런데 믿을 수 없는 일이, 아니 믿고 싶지 않은 일이 일어났습니다. 서버에서는
1979711488(10진수)를 출력한 것입니다.
무슨 일이 일어난 것일까요? (힌트: 118과 1979711488를 16진수로 바꿔 보세요)
오늘 문득 3년전에 하던 프로젝트가 생각났습니다. Kick Off 한지 3달이 지난 LCD 공장 CIM 프로젝트에 소방수로 잠깐 들어갔다가 약 10개월 정도 더 묵여있던 프로젝트입니다.
당시 제가 일하던 회사는 제품 개발 부서와 개발된 제품을 현장에 들고 나가서 엔지니어링을 하는 부서가 나뉘어져 있었습니다. 제품도 상당히 많고, 그 제품의 수만큼 엔지니어(주:개발자)들도 많았지요. 현장에서 일하는 엔지니어들은 고객과 대화하는 능력과 고수준의 개발 능력, 그리고 엄청난 체력을 필요로 했습니다.
그런데 그 프로젝트에는 하필, 우리 회사 엔지니어 수가 모자라서(PL급 1명) 상당 수의 외주 개발자들을 뽑아 써야 하는 상황이 되어 버렸습니다. CIM 분야에 대한 Domain Knowledge를 교육하고 제품을 엔지니어링하기 위한 각 기술을 익히는 데에만 최소 수개월이 걸리는데, 수준을 알 수 없는 개발자를 '일단' 선발해서 투입한 겁니다.
그래서 프로젝트가 설계단계부터 삐걱거리기 시작하고 제품 개발팀에 있던 제가 3~4주 지원을 하는 소방수로 선발된 것입니다.
아뿔싸, 한달만 지원하면 다시 돌아올 수 있을 거라 생각했던 것은 그야말로 '모르는 소리'였습니다. 3개월이 지났는데도 개발자들은 프로젝트를 하기 위한 기초 지식(LCD 공정, 개발에 필요한 메시지 버스 등)도 모르고 있었습니다. (제가 갔을 때는 뭔가를 열심히들 하고 있었지만 그게 뭐였는지는 지금도 모릅니다.)
한달이 지나자 '지원'을 하러갔던 저는 PL이 되어 설계와 스케줄링, 개발자들의 교육과 프로젝트의 진행 임무가 얹혀진 지게를 메게 되었습니다. 하루에 12시간만 더 있었으면 하는 생각을 가졌던 유일한 시기였습니다.
시간이 지나도 좀처럼 나아지지 않는 개발자들, 내가 들어가기 전에 파악했던 요구사항은 완전히 무용지물이었다는 사실(모든 요구사항과 프로세스를 새로 분석해야 했습니다.), 한번도 웹 유저 인터페이스 연동 경험이 없는 제품을 웹 인터페이스를 올려야 한다는 기술적 위험, 무엇보다 이 짐을 같이 지고 나갈 수 있는 사람이 없다는 외로움이 가슴을 짓눌러왔습니다.
( 더 황당한 사실은, 당시 저는 처음 접해본 Java, JSP를 3~4년차 사용했다고 하는 분들이 저한테 물어가며 개발을 했던 것입니다.)
다른 개발자들은 저녁 8시 반이나 9시면 집에 가야 한다고 짐을 싸는데, 저는 그럴 수 없었습니다. 하루 종일 설계만 해도 시간이 모자라는데, 개발자 교육에, 코드 검사(당하는 입장에서는 자존심 상하지만, 품질을 유지하기 위해선 필요합니다. 이 업무는 나중에 영입한 전문가께서 계속 해주셨습니다.), 또 제가 맡은 블럭의 개발을 해야했기 때문이죠.
집에 가면 12시~1시, 잠깐 눈붙이고 출근하기 위해 5시 반에 일어나 6시에 통근 버스를 탔습니다. 이 기간에 몸무게가 5Kg정도 빠졌습니다.
제가 프로젝트에 합류한지 한달 반이 지났을 무렵, 하던 일을 잠시 멈추고 커피 한잔 마시면서 프로젝트를 돌아봤습니다. 무엇이 문제일까, 그 문제를 고치면 더 나아질 수 있을까?
결론은 다음과 같았습니다.
1. 내가 소비하는 시간의 70%는 개발자의 교육과 코드 품질 관리에 소모된다.
우리 회사의 엔지니어 두사람이면 이 시간을 완전히 절약할 수 있을 것이다.
다행히 품질 관리는 곧 합류할 전문가가 담당해 줄 것이다.
2. 지난 한달 반동안 현재 같이 일하는 개발자들은 기술적으로도,
대화 능력도 나아진 것이 없다.
문제는 데려올 본사 엔지니어가 없기 때문에 외주를 줬다는 것입니다. 그래서 저는 전방위 로비(?) 시작했습니다. 그 내용은 말씀드릴 수 없지만 갑측의 프로젝트 담당자 분과 우리 회사의 PM님으로 하여금 인력 교체를 결심하도록 말입니다.
프로젝트 기간의 2/5가 지나간 상황에서 도박과 다름 없는 결정이었지만, 결국 다섯 명을 내보내고 면접을 통해 다른 뛰어난 개발자 네 명을 영입하는 데 성공했습니다. 개발자 교육에는 1주일 정도가 걸렸습니다. 메시지 버스는 지지고 볶는 사이 이미 라이브러리로 만들어 놨기 때문에 특별한 교육이 필요 없었고, LCD 공정과 공장 자동화를 이해하는데 1주일 정도가 소요된 것이죠.
프로젝트는 빠른 속도로 예정된 스케줄을 따라 잡았고, 거짓말처럼 얼마 후에는 5시에 퇴근할 수 있었습니다. 조금 일이 있으면 7시에 퇴근했고요. 저는 시간이 남아서 클러스터링 되어 있는 OS, WAS, DBMS,그리고 우리 제품의 성능을 감시하는 TCP/IP 기반의 리소스 모니터를 처음 써본 Perl 언어로 개발했습니다. (프로젝트는 아주 좋은 케이스로 남아 갑의 담당자 분은 고과를 후하게 받았다는 후문입니다. 회사 입장에서는 프로젝트의 성공으로 유사 프로젝트를 여러 건 수주하게 됐고요.)
이야기는 이렇게 해피 엔딩으로 끝납니다.
소프트웨어 개발.. 1) 충분히 좋은 개발자를 2) 충분한 수로 확보하고, 3) 정확한 스케줄링(또는 이를 위한 노력)에 의해 이루어진다면 얼마든지 좋은 품질의 제품을 만들어 낼 수 있습니다.
쉽지 않은 일이지요? 하지만 저는 좋은 개발자 없는 회사가 성공한 곳을 본 적이 없고, 수퍼 개발자 혼자서 뭘 해낸 곳도 본적이 없습니다(잠깐의 성공을 이야기하는 것이 아닙니다. 고객에게 지속적으로 인정을 받는 것을 의미합니다.).
이야기를 써놓고 보니 달걀이 먼저냐, 닭이 먼저냐 하는 것인데 답은 간단합니다.
"닭이 먼저입니다."
요즘 주변에 취업 준비하시는 후배들이 많네요. 다니던 직장을 그만두고 새로운 곳을 알아보는 분들도 많고요. 제가 첫 직장을 구하기 위해 면접을 보러다니던 때가 생각나는 군요.
CTI(Computer Telephone Integration) 개발을 하는 회사(이제는 연 매출이 거의 400억 가까이 되는군요.)였는데, 다른 지원자들을 제쳐두고 저만 따로 하루 먼저 불러 면접을 봤습니다. 이력서가 인상적이었다고 합니다.
좋은 분위기에서 면접이 시작되고, 면접관의 질문에 막힘없이 대답을 해 나갔습니다. 면접을 잘 마치는가 싶었는데, 면접관께서 질문 있으면 해보라고 하시더군요. '이럴 수가! 난 대답만 준비해왔는데, 어쩌란 말이야! 뭔가 멋진 질문을 해야해!' 라는 내면의 외침이 올라왔습니다. 그래서 한 질문이라는 것이...
저, 면접관님께서는 회사 생활에 얼마나 만족하고 계십니까?
