개발자의 시간을 갉아먹는 함정들 :: 2007/09/08 12:59


신입 개발자를 위한 조언
개발자의 시간을 갉아먹는 함정들
신영진 pop@jiniya.net http://www.jiniya.net

“취미로 개발을 하는 경우와 직업적으로 개발을 하는 경우의 차이점은 무엇인가요?”라고 누가 묻는다면 필자는 아마도 시간이라고 대답할 것이다. 취미로 개발을 하는 경우에는 데드라인이 존재하지 않는다. 전적으로 개발자 자신과의 약속인 것이다. 만들다가 혹 막히거나 힘들다면 프로젝트를 중지하고 발표하지 않아도 그만이다.

하지만 무언가를 직업적으로 개발하는 경우라면 이야기가 180도 달라진다. 항상 데드라인이 존재하고, 기간이 준수되지 않는 것은 실패로 간주된다. 이처럼 중요한 것이 시간임에도 불구하고, 신입 개발자들은 이를 제대로 준수하지 못하는 경우가 적지 않다. 대부분이 함정에 쉽게 빠지기 때문이다. 그럼 그들의 시간을 갉아먹는 함정에는 어떤 것들이 있을까? 여기서 이에 대해 살펴보자.

함정의 근원은 성급함
첫 번째 함정은 설계의 함정이다. 학교에서 소프트웨어 공학 수업을 열심히 들은 신입 개발자들은 그 논리대로 설계를 무척이나 중시한다. 3개월의 개발 기간이 주어지면 두 달 이상의 시간을 설계라는 작업으로 허비하는 것이다. 열심히 노트에 주어진 기능 목록을 나열하고, 다이어그램도 그린다.

하지만 매우 고통스러운 사실은 두 달 동안 설계한 내용들이 코드를 작성하기 시작하는 순간부터 하나 둘 바뀐다는 점이다. 또한 결과물이 없는 두 달 동안 위에서는 그 사람이 일하고 있다고 생각할 수 밖에 없다. 혼자서 코끼리를 만들고 있는지, 로보트를 만들고 있는지 알 길이 없는 것이다. 설계를 검증하는 것이 무의미한 이유는 설계대로 만들지 않기 때문이다. 설계는 늘 우아하고 기품이 넘친다. 하지만 실제 코딩 스킬은 그 설계의 요구 사항을 따라가기에는 부족하다. 따라서 개발에 들어가는 순간부터 설계 명세의 절반은 제외되고 절반은 새롭게 개발된다.

두 번째는 재사용의 함정이다. 학교에서는 흔히 재사용되지 않는 코드는 정말 나쁜 코드인 것처럼 가르친다. 심지어 “심심풀이로 만든 숫자야구 게임이 우주선에 들어가는 컴퓨터에도 사용될 수 있어야 한다”는 이야기만큼이나 학교에서 가르치는 재사용의 범위는 왜곡되어 있다. 재사용이란 지금 당장 돌아가는 코드가 있을 때 생각할 수 있는 문제이다. 이미 있는 코드를 고쳐서 재사용 가능하게 만들기는 쉽지만 처음부터 재사용 가능한 것을 만드는 것은 매우 어렵다. 고참 개발자들에게 뭔가 일이 주어졌을 때 그들이 만들어내는 코드가 재사용하기 좋은 것처럼 보이는 이유는 과거 그들이 그와 같은 코드를 수도 없이 작성했기 때문이다. 반면 신입 개발자들에게는 그와 같은 경험이 없다. 따라서 재사용을 생각하기 이전에 당장 돌아가는 코드를 먼저 작성해 보는 것이 좋다. 비록 두 번 일을 하더라도 처음부터 재사용을 고려해 만들려고 하는 경우보다 시간이 적게 들 것이다.

세 번째 함정은 호환성이다. 호환성의 함정이란 자신의 코드에 지나친 호환성을 부여하려 하는 데서 비롯된다. 가장 흔하게 찾을 수 있는 것이 C/C++ 표준과 운영체제 호환성이다. 자신이 만든 코드가 어떤 C/C++ 컴파일러에서도 돌아가고 다른 운영체제에서도 잘 실행된다는 것은 무척 멋진 일이다. 또한 갈수록 그러한 것이 요구되기도 한다. 하지만 대부분의 경우 여전히 타깃 플랫폼이 존재하고 회사 내부적으로 사용하는 컴파일러가 정해져 있게 마련이다. 이런 상황에서 C/C++ 표준이나 운영체제 독립적인 코드를 운운하는 것은 생산적인 일은 아니다. 해당 운영체제나 컴파일러에서만 잘 돌아가면 일단 프로젝트 진행에는 무리가 없기 때문이다. 심지어 특정 컴파일러의 특수성 때문에 C/C++ 표준이 무시되는 경우도 있다.

필자는 늘 신입 개발자들에게 성급한 최적화만큼이나 성급한 설계, 성급한 재사용, 성급한 호환성이 나쁘다는 이야기를 한다. 대부분의 회사에서 만드는 대부분의 제품은 사용 범위가 특정 환경으로 제한된 경우가 많기 때문이다. 또한 앞에서 이야기 한 것처럼 경험이 많지 않다면 이러한 작업에 시간을 많이 투자하는 것은 결코 좋지 않다. 그러한 작업을 멋지게 끝낸다고 하더라도 그 다음 단계에서 원점으로 돌아가기 때문이다.

스폰서
글타래

  • 2주간 인기 글
  • 2주간 인기글이 없습니다.
Trackback Address :: http://jiniya.net/tt/trackback/598
  • Gravatar Image.
    홍가이버 | 2007/09/09 09:31 | PERMALINK | EDIT/DEL | REPLY

    1,2,3번 모두 강력하게(?) 공감하고 갑니다.

    • Gravatar Image.
      codewiz | 2007/09/10 12:11 | PERMALINK | EDIT/DEL

      공감된다고 하시니 마음이 좀 놓이네요..
      아무도 공감 안할까봐 엄청 걱정하고 있었습니다. ㅋㅋ

  • Gravatar Image.
    찐구닷컴 | 2007/09/10 16:58 | PERMALINK | EDIT/DEL | REPLY

    1,2번은 동감하나, 3번에 대해서는 반은 동감하지만서도 동감하고 싶지 않은 부분인거 같습니다.
    물론 회사에서 사용되는 컴파일러는 정해져 있고, 굳이 다양한 플랫폼에서 돌아가는 코드를 만들 필요가 있겠느냐는 생각은 많은 듣고 많이 하고는 있지만, 항상 최대한 표준에 맞게끔 코딩하고 그 소스가 쉽게(물론 손은 되야겠지만..) 어느 플랫폼에서도 이식 될 수 있도록 만드는 것이 고급 기술자가 아닌가 생각됩니다.

    하지만 분명 플랫폼에 종속적인 기술이 있습니다. 이런것은 어쩔 수 없이 사용할 수는 있어서,
    사용하면서도 항상 이런 것을 해결하기 위한 고민을 계속해 나가는 것이 좋지 않나 생각해보고 갑니다. ^^

    • Gravatar Image.
      codewiz | 2007/09/10 17:37 | PERMALINK | EDIT/DEL

      좋은 의견 감사합니다.
      찐구닷컴님 말씀대로 그런 노력은 상당히 중요합니다. 하지만 거기에 너무 집중해서 정작 중요한 목표를 잊어서는 안된다는 이야기를 하고 싶었습니다. 결국 가장 중요한 목표는 기간내에 소프트웨어를 개발하는 것 아니겠습니까?

      물론 이런 생각들은 전적으로 시간이라는 요소를 가장 중요하기 때문에 나온 것들입니다. 시간보다 다른 것들을 더 중요하게 생각한다면 바뀔 수 밖에 없겠죠.

  • Gravatar Image.
    microdev | 2007/09/11 12:29 | PERMALINK | EDIT/DEL | REPLY

    좋은 글 잘 읽었습니다.
    저도 3번에 대해서는 신입 개발자인 저에겐 무섭다고(?) 생각이 앞서네요^^
    개발 기술이 회사에 종속되어 가는 모습을 보면 그 또한 씁씁한 생각이 들구요
    회사에 종속되고, 개발툴에 종속되고, OS에 종속되는게 현업에서 개발하다 보면
    당연스레 되어지더라고요.. 제 느낌을 글로 옮기려니깐 풍부하지 않는 어휘력이 안도와주네요^^

    • Gravatar Image.
      codewiz | 2007/09/11 13:36 | PERMALINK | EDIT/DEL

      기술 종속성에 관해서 말씀하시는 것 같아서 거기에 대한 제 생각을 간단히 이야기 하겠습니다.

      특정 환경에 종속된다는 수동적 관점에서 생각할 수도 있지만, 반대로 특정 환경을 더 자세히 이해한다는 능동적 관점으로 볼 수도 있습니다. 이러한 능동적 관점으로 바라볼 수 있는 이유는 대부분의 기술들이 근원은 똑같고, 서로 닮아가는 형태로 발전하기 때문입니다. 때문에 한 가지 기술이나 환경에 정통한 사람이 다른 것들을 더 빨리 배울 수 있는 반면, 한번도 깊이있게 배우지 않은 사람은 다른 것들을 배우더라도 수박 겉핥기 형태로 배우는 경우가 많습니다.

      더 나아가서 문제 해결이라는 관점에서 볼 때 대부분 실무에서 발생하는 어려운 문제들은 환경과 깊이있게 연관되는 경우가 많고, 그것을 해결할 수 있는 사람은 그 환경에 대해서 많은 경험과 깊이 있는 이해를 하고 있는 사람인 경우가 대부분입니다. 결국 한 가지 환경을 정확하게 이해하는 것이 microdev님이 개발자로서 가질 수 있는 가장 큰 경쟁력이 될 겁니다.

      쓰다보니 두서없이 길어진것 같습니다. ^^

  • Gravatar Image.
    오스카 | 2007/09/12 10:37 | PERMALINK | EDIT/DEL | REPLY

    100배 공감가는 글입니다. 3번에 대해서는 다양한 의견이 있군요. 개인적으로는 글이 강조하는 시간에 대한 관점으로 접근하면 될거 같습니다. 이미 독립적인 플랫폼 코드 작성 - File IO/GUI/Render ... - 등을 위한 레이어링에 익숙한 개발자라면야 시간적 요소가 크지 않겠지만, 적응하는데 시간이 필요하다면 게다가 그게 회사 업무라면 잘 생각해 봐야 하는 문제겠지요.

    저도 '종속'이라는 단어에 대해서는 codewiz님과 같은 생각인데요, 어차피 기술의 컨셉은 크게 다르지 않습니다. 개발 툴이든 OS든 특정 도메인 플랫폼이든 각 카테고리별로 일정 수준 이상에 올라서면 그게 그거죠. 물론 세부적인 내용에 있어서는 해당 분야의 전문가가 있습니다만 예전과 다르게 그런 노하우를 습득할 수 있는 경로나 리소스가 다양하기 때문에 큰 문제는 안되더라고요.

    • Gravatar Image.
      codewiz | 2007/09/13 11:17 | PERMALINK | EDIT/DEL

      좋은 의견 감사합니다.
      저 또한 오스카님과 마찬 가지로 시간 문제라고 봅니다. 추상화에 익숙하고 다양한 플랫폼을 경험해서 그런 코드를 쉬이 만들수 있다면 그게 더 바람직하겠죠.

      원 글이 그런 의도를 좀 못 나타낸것 같네요. *^^*

  • Gravatar Image.
    지나가다 | 2007/09/13 06:46 | PERMALINK | EDIT/DEL | REPLY

    음 이런 환경을 생각해보죠.
    회사에서 bug tracking system, CVS같은 버전관리 도구, nightly build를 하고 있다면.
    신입사원에게 module A라는 task를 줄때,
    관리자나 module A관련있는 사람이 bug를 하나 열고 module A진행 상황을 tracking한다면,(물론 본인이 open하는것도 좋겠죠)
    CVS에서 code review를 해주거나
    nighlty build에서 windows build는 성공했으나, linux,RTOS에서 fail 리포트를 받는다면,

    신입사원 스스로가 앞으로 나가는 좋은 환경일것 같습니다.

    • Gravatar Image.
      codewiz | 2007/09/13 11:27 | PERMALINK | EDIT/DEL

      좋은 의견 감사합니다.
      좋은 시스템에서 일할 수 있는 개발자라면 더없는 행운이라 생각됩니다. 하지만 아직 중소 영세한 업체에서는 그런 시스템을 운영하기가 힘들죠. 물론 시스템 운영이야 어렵지 않겠지만 인력 구조 상의 문제가 가장 크다고 봅니다. 인력이 작기 때문에 복잡한 시스템이 오히려 방해가 되는 경우죠.

      그리고 또 하나 확실하게 인식해야 하는 것은 시스템은 보험적인 측면이지 능동적인 측면은 아니라는 겁니다. 버그를 찾아내고, 잘못된 코드를 복원하고 하는 문제등에 큰 도움을 줄 수 있겠지만 실질적으로 시스템이 코드를 작성하는 건 아니죠.

      저에게 시스템이 없는 환경에서 똑똑한 개발자 두 명과 일할지 잘 갖추어진 환경에서 똑똑하지 않은 개발자 스무 명과 일할지 결정하라면 전 두 명을 택할겁니다. 또한 제가 신입이라고 할 때 똑똑한 개발자 두 명 밑에서 배울지 시스템 밑에서 배울지 묻는다면 그 또한 똑똑한 개발자를 선택할 겁니다. 소프트웨어 분야만큼 맨파워가 중요한 분야도 없기 때문이죠.

      물론 좋은 시스템에서 똑똑한 개발자와 일하는게 최상이겠지요. *^^*

  • Gravatar Image.
    seansong | 2007/12/02 10:58 | PERMALINK | EDIT/DEL | REPLY

    본인이 속해있는 회사가 어떤 종류의 것이냐에 따라 맞는 말일수도 있고 틀린 말일수도 있을것 같군요.
    체계가 거의 없는 개발 프로젝트 비즈니스를 주로 하는 중.소규모 기업에서는 맞는 주장으로 볼수도 있겠습니다.

    • Gravatar Image.
      codewiz | 2007/12/02 13:09 | PERMALINK | EDIT/DEL

      좋은 의견 감사합니다.
      저 또한 seansong님의 의견에 동의합니다.

      개인적으로 어떤 지식이든 절대적인 것은 없다고 봅니다. 특수한 환경과 상황에서 놓고 본다면 사실이 될수도 있기 때문입니다. 예컨데 과거 유학을 일군 공자의 주장들이 현대에 와서는 전혀 말도 안된다고 공자를 바보 취급할 수는 없다는 이야기 입니다. 그 시절의 환경과 상황에서는 그만큼이 도달할 수 있는 최고의 결론일 수 있었기 때문이죠.

  • Gravatar Image.
    컴맹 | 2013/04/15 14:51 | PERMALINK | EDIT/DEL | REPLY

    앗싸!! 금광이다!!!!!!!
    좋은블로그를 찾았습니다.^^
    1,2,3번 모두 공감이 가고 다른 글들도 읽어봐야할 좋은 내용이 정말 많네요.^^
    잘 보고 갑니다.~~

Name
Password
Homepage
Secret