2007년 7월 24일 화요일

닭이 먼저입니다.

오늘 문득 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) 정확한 스케줄링(또는 이를 위한 노력)에 의해 이루어진다면 얼마든지 좋은 품질의 제품을 만들어 낼 수 있습니다.

쉽지 않은 일이지요? 하지만 저는 좋은 개발자 없는 회사가 성공한 곳을 본 적이 없고, 수퍼 개발자 혼자서 뭘 해낸 곳도 본적이 없습니다(잠깐의 성공을 이야기하는 것이 아닙니다. 고객에게 지속적으로 인정을 받는 것을 의미합니다.).

이야기를 써놓고 보니 달걀이 먼저냐, 닭이 먼저냐 하는 것인데 답은 간단합니다.
"닭이 먼저입니다."

댓글 4개:

  1. 무엇보다 Sean님이 있었기에 가능한 일이라고 생각합니다. 절대 아부는 아닙니다만(그렇게 보이는걸?), 좋은 개발자, 좋은 환경을 보유하고 있더라도 능력있는 PM, 대화가 통하는 고객이 있었고 그들을 설득했기 때문에 결과가 좋아진 것은 아닐까요?

    프로젝트의 문제점을 찾고 해결하신 것 자체가 가장 필요한 능력이 아닌가 싶습니다.



    예전에 제가 다니던 회사도, 내부인력 부족으로 프리랜서에게 일을 맡겼는데 결과는 완전 실패였습니다. 물론 가장 큰 원인은 조직의 내부에 있었지만 그 외에 Sean님이 지적하신 문제가 발생했던 겁니다.



    저는 형편없는 실력으로 직업에 '소프트웨어 개발자'라고 쓰는 사람입니다만, 좋은 개발자를 키우고, 좋은 환경을 만들려는 노력을 하지 않는 리더가 많은것 같습니다.



    좋은 글 감사합니다.

    그럼 좋은 하루 되세요.

    답글삭제
  2. @지나가는사람 - 2007/07/24 11:53
    ^^ 글 남겨 주셔서 감사합니다.



    어떤 일이든, 사람만큼 중요한 자원은 없습니다. 우선순위로 본다면 자본과 동급이라고 생각합니다.



    좋은 하루 되세요 ^^ (이미 하루가 다 갔네요)

    답글삭제
  3. 안녕하세요. 항상 블로그 잘 보고 있습니다. 글 남기기는 처음이네요 ^^

    대학에서 소규모 팀프로젝트를 할때에도 절실히 느끼는 점인데.

    실무에 계신 sean 님은 오죽하셨을까 하는 생각해봅니다.



    앞으로도 좋은 글 부탁드리겟습니다 ^^

    답글삭제
  4. @Kwangswei - 2007/07/28 19:01
    요즘은 새롭게 집필에 들어간 책 때문에 포스트를 올릴 시간을 잘 못내지만, 없는 시간은 없는대로 글을 올리려 합니다.



    자주 놀러와 주세요~ ^^

    답글삭제