종종 이런 이야기를 듣습니다. "프로그래머는 너무 방어적으로 일을 하는 것 같다." 라는 말이죠.

어떤 의미일까요? 예를 들어서 소프트웨어 개발 회사에서 어떤 프로젝트를 진행을 할때 그 프로젝트의 목표를 구현 하는 일을 소위 기획이라고 합니다. 기획자들은 충분한 시간을 가지고 이 프로젝트의 진행 목적 부터 진행 중간 단계의 표현, 기능 들에 대해서 진지하게 고민합니다. 그렇게 해서 (예제로써) 약 버스를 만들기로 했습니다.

그리고 이것에 대한 내용과 스케쥴을 기획서에 작성을 해서 그 기획서를 들고 프로그래밍 조직으로 찾아가서 이야기 합니다. "이것을 언제까지 만들어주세요." 그러면 프로그래머는 기획서를 쭉 살펴보고 기획서가 너무 부실하다고 생각합니다. 기획서에 써 있는 것들이 어떤 목적으로 구현이 되는 것인지, 그리고 또 어떠한 내용인지 확실히 알 수가 없습니다. (물론 아닌 경우도 있습니다.) 그리고 이것 저것 하나씩 묻기 시작하고, 실제 구현 방법에 대해서 하나씩 생각을 해보기 시작하고 나서 대부분은 이렇게 말합니다. "그때까지는 힘들겠는데요.."  라는 말과 함께 협상을 시작합니다.

그리고 프로그래머는 구현해야 하는 기능 중에서 구현이 애매 모호하거나 시간이 오래 걸릴 것 같은 기능들을 구현이 편한 방향으로 변경을 시도합니다. 때로는 이것은 기획자의 의도와는 좀 다른 방향으로의 결과물을 불러오기는 합니다만 이미 대부분의 상황에서 기획자와 프로그래머는 "협상" 단계에 들어가 있기 때문에 기획자도 그것을 받아 들입니다.
그렇게 해서 최초 목표였던 버스는 승합차가 되어 돌아오게 됩니다. 그리고 그것은 출시 됩니다.

지난 몇년간 게임 회사에서 일 하면서 경험하고, 봐왔던 현상입니다. 기존에 다른 회사에서 일 했던 경험을 바탕으로 한다면 다른 회사 역시 대부분은 저런 흐름을 비일비재하게 겪고 있을 것 같습니다.

프로그래머들은 어째서 저런 방어적 입장을 취하는 것일까요?

공식적인 이유로는 이러한 이유들이 있습니다.

1) 기획자가 정말 무리한 일정을 가지고 온 경우, 2) 일정을 아무리 길게 잡아도 아에 불가능한 것을 요구 하는 경우. (예를 들어 기존에 사용 하고 있던 코볼의 코드를 C#으로 완벽하게 포팅 해주는 프로그램을 만들어 주세요. 와 같은), 3) 나의 일을 줄이기 위해서.  4) 기타.. 어떤 것들이 있을까요?

... 어떤 이유일까요? 사실 이런 이유는 중요한게 아닙니다. 위에서 말한 어떤 이유라고 하더라도 그것은 사실상 개별적 해결이 불가능 하기 때문입니다.

저는.. 이런 일이 발생 하는 이유가 바로 '협상' 단계가 생길 수 밖에 없는 업무 흐름 때문일 거라는 생각이 듭니다. 완전한 갑을 관계에서는 '협상' 따위는 없겠죠. (경우에 따라서는 아주 조금 있을지도 모르지만-_-) 그렇다고 해서 갑을 관계를 형성 하라는 것은 아닙니다. 같은 회사안의 조직이기 때문에 그렇게 해봐야 조직간의 분열을 더 초례 할 뿐입니다.

그렇다면 이렇게 해보는건 어떨까요?

기획자는 처음에 기획을 구상 하는 단계에서 이것의 간단한 '목표' 만을 설정합니다. 그리고 기획 회의를 진행할때 실무자 또는 실무자에게 충분한 영향을 줄 수 있는 사람을 함께 하는 겁니다.

뭐야 이게? 라고 생각하는 분들도 있을 것 같습니다만, 실제 기획을 구체화 시킬때 실제 구현자인 프로그래머가 참석해서 함께 회의를 진행한다면 '협상' 단계 따위는 오지 않습니다. 네, 물론 그 '협상' 단계가 기획 회의에서 이루어지게 됩니다. 하지만, 그 수준이 명확하게 다릅니다. 왜냐하면, 기획 회의에서는 간단한 목표만 정해져 있을뿐, 이것의 정확한 기획 결정이 이루어지기 전이기 때문입니다.

기획 회의에 프로그래머가 참여를 한다면 프로그래머는 그 기획 회의에서 내가 어떻게 방어적 입장을 취할까를 고민하지 않습니다. 말 그대로 기술적인 지식을 바탕으로 그 기획에 함께 참여하게 됩니다. 또한 기획 회의에서는 해당 작업을 해야 하는 목적 등에 대한 고민이 이루어지므로 기획서에서는 그냥 지나치는 (또는 아에 나와 있지 않은) 작업의 목적(사실상 동기)를 프로그래머와 함께 공유 할 수 있게 됩니다. 이것은 프로그래머에게 기존의 방식 보다는 조금 더 주인의식(?)을 부여 할 수 있는 방법이 아닐까 싶습니다. 실제 프로그래머들을 참석 시킬 경우 기획자가 생각하지 못하는 기술적인 지식을 이용한 좋은 방향이나 아이디어가 나오기도 합니다. 손해 볼건 없다는거죠.

또한, 프로그래머가 참여 하므로 애시당초 불가능한 기능에 대해서는 기획 회의에서 충분히 걸러 질 수 있습니다. 그리고 결정 되어지는 것들에 대하여 그 자리에서 프로그래머와 함께 스케쥴 임시 계산이 가능하므로 스케쥴 문제 역시 크게 해결 할 수 있습니다. 어차피 스케쥴 협상을 할 거라면 회의 단계에서 미리 하는데 시간을 아끼는 방법이기도 하죠.

그냥 단지 프로그래머가 기획 회의에 참여 하는 것만으로 기존의 '협상' 단계를 없애거나 최소화가 가능해지지 않을까요?

네.

뭐 그냥 그렇다구요.


posted by Yuno.org
  • 나그네 2010.03.19 16:38

    그래서 외국의 큰 기업들은... 기획자가 디자인을 하고 리드 혹은 그것을 구현할 프로그래머들에게 시간을 정하게 합니다.(꼭 리드만 참여하는게 아닙니다...) 그러니까 기획자가 3개월안에 만든다. 이런게 아니라 원하는게 있으면 그걸 구현할 사람에게 얼마가 걸리는지 물어보고 그것을 따릅니다. 프로그래머가 6개월 걸리면 6개월 기다리던지 아니면 그것을 포기하던지 둘 중에 하나인것이죠. 그리고 3개월이 정해진다고 하여도 개발 중간 중간에 바뀌는것들이 있고 (안바뀌는건 해결 불가능한 문제이죠. 물론 재미없는 게임 만들려면 시간 안에 그대로 만들 수 있습니다. ^^) 당연히 바뀐 만큼 추가 시간을 받던가 아니면 기능을 삭제 합니다.

    한국에서도 일해보고, 외국에서도 일해봤는데... 가장 큰 차이점은...

    '구현할 사람에게 얼마가 걸리는지 물어보고 그것을 따릅니다.' 였습니다.

    수고하세요~

    • Yuno.org 2010.03.20 14:47 신고

      구현할 사람에게 얼마나 걸리는지 물어보고라고 하면 너무 한쪽에 의존하게 됩니다.

      그래서 처음 기획 단계를 제외한 실제 구현 기획 회의 단계부터는 개발자가 함께 참여해서 진행 해야합니다. 스케쥴은 이때 결정이 되는거죠.

  • 피요히코 2010.03.19 18:21

    사실 실제로 프로그램을 구현하는 사람들은 개발자들이니. 실제 소요 시간을 산출할때는 그들의 의견을 따르는게(반영하는게) 옳을것 같습니다.
    뭐 거의 대부분의 경우는 일정이 픽스된 상태에서 기획도 들어가니..(제가 있는곳만 그런가요..) 개발자의 의견은 별로 중요해 보이지 않더라구요. 그러니 끊임없는 야근의 반복되고. 몸과 마음이 지친상태에서 좋은 코드가 나오기도 힘들고. 그러다 보니. 잠재적 오류들이 쌓이고. 오픈 앞두고 철야 반복에. 오픈후에도 하자보수를 해야하고. 하지만 또 다른 프로젝트에 들어가니 일은 더 많아지고. 또 야근에... 이런 반복인거 같네요..
    나그네 님이 말씀하신 것 처럼 실제 구현할 사람에게 의견을 구하고. 그 의견이 받아들여진(반영되어진) 일정대로 일을 한다면. (뭐 중간중간 생기는 변수에 대한것도 반영되는게 베스트겠죠) 개발자들도 더 책임감 있고 편안한 마음으로 일을 할수 있지 않을까 하는 생각이네요. ㅠㅠ

    • Yuno.org 2010.03.20 14:50 신고

      네 맞습니다. 하지만 의견을 구하는 단계가 이미 기획이 완료된 상태에서 한다면 결국 똑같튼 현상이 생깁니다.

      둘다 만족 할 수 있는 방법을 찾는 수 밖에 없죠 ;

      어느 쪽이 반대편을 설득 하는 단계는 준비 완료 된 후가 아닌 준비 단계에서 진행 해야 더 무난 진행이 가능 한 것 같습니다.

  • 쎄미 2010.03.19 19:23

    프로그래머가 같이 붙어서 한다고 그래도, 중간에 대책없이 막히게 되는일도 비일비재하다보니 일정을 좀 넉넉히 잡는게 습관이 되더라구요...

    • Yuno.org 2010.03.20 14:54 신고

      네 맞습니다. 그런데, 이미 프로그래밍팀을 제외한 다른 부분에서는 일정을 결정하고 프로그래밍팀과 이야기 하는게 문제죠.

      그렇게 되면 내부의 상황과는 관계 없이 방어적으로 보일 수 밖에 없습니다. 그렇기 때문에 프로그래밍팀 역시 기본 회의에 전부 참석 해야 하는 이유이기도 합니다.

    • 쎄미 2010.03.20 15:58

      일정을 넉넉하게 잡으려고하면 일을 못하는 사람이나 너무 놀려고하는거 아니냐는 말이 돌아오는게 대부분이죠...

  • ash84 2010.03.19 19:33

    제가 느낄때에는 사실은 프로그램을 개발하는 기간이라는것이 100% 추정 가능한 것이 아니기 때문에 문제입니다. 그리고 본능적으로 프로그래머는 그것을 알고 있지요. 본인 스스로도 이건 3일내에 할수 있습니다. 라고 말하면서도 불안할때가 많습니다. 그런 와중에 프로젝트나 새로운 기획은 기한이 정해진채로 떨어지기 때문에 자동적으로 방어적이 되는것이지요.

    사실 이런 부분을 최소화하려면, 프로그램을 개발하는 일에 대해서 이해할 필요가 있습니다. 그리고 그것들을 고려해서 일정을 짜고 기획자 입장에서는 그런것들을 고려해서 잘(?) 프로그래머를 설득해야 겠지요.

    • Yuno.org 2010.03.20 14:56 신고

      네 맞습니다. 그래서 '기한이 정해진 채'로 떨어지는 것을 막기 위해서라도 기본 회의 단계에서 부터 프로그래머가 참여 해야 하는겁니다.

      이러한 것을 기본 전략 기획 회의(?)에서 이야기 하지 않는다면 어쨋든 그것은 프로그래머 vs 그 외 전부 의 상황이 되어 버리는거죠.

  • Apple-Code 2010.03.19 19:39

    간단합니다. 새로운 것 == 야근

    • Yuno.org 2010.03.20 14:57 신고

      그러게요 -_-

      참고로.. 일반 SI 보다 어지간한 중간 이상의 게임 회사가 더 근무 환경이 더 좋습니다 ㄷㄷㄷㄷㄷㄷ

  • Doonee 2010.03.20 10:46

    제가 생각하는 개발자문화 개선방안은 다음과 같습니다.

    [1] 좀더 적극적이고 적절한 타협을 할줄 아는 개발자의 자세
    - 개발자, 수동적인 것 맞습니다. 왜냐하면 개발자가 능동적이고 적극적이면 스스로 그리고 주변 개발자들 상당히 피곤하게 만듭니다. 일을 스스로 만드는 결과를 초래할 수 있습니다. 그래서 그러한 수동적인 성격들을 옹호하는 건 아니구요, 조금이라도 개선된 개발자문화를 만들려면 위에서 소개해 주신 것처럼 최초회의에 참석하려는 의지를 보여야 하고, 개발자와 개발자외의 사람들에게 적절한 타협을 제시할 줄 아는 적극적인 마인드가 필요한 것 같습니다.

    [2] 능력있는 기획자를 만나는 것
    - 저는 개발 실무경력 10년이 다 되어가고, 여러군데서 여러 기획자들과 일을 해봤지만, 지금까지 사실 능력있다고 생각되는 기획자를 만난적 한번도 없습니다. 제가 경험했던 기획자는 '경영진과 개발자를 연결 해주는 다리역할 하는사람' 혹은 '베타테스터' 정도 였습니다. 베타테스트 끝나도 버그 많습니다. 그렇지만, 버그나오면 기획자 잘못이라고 할까요? 개발자에게 책임을 떠 넘기려는 분들이 많습니다. 그렇지만, 프로젝트가 잘 마무리되면 기획자는 자기가 개발 한 것처럼 보일려고 합니다. 물론 능력있고 자기역할 잘하는 기획자도 있겠지만, 아직은 못 만나봤습니다. 기획자가 다 그렇다는 건 아닙니다. 제가 만났던 사람들에 국한된 경험입니다.

    [3] 경영진의 마인드 개선
    - 가장 중요한건 위의 [1][2]번이 다 되더래도 경영진의 마인드가 개선 안되면 헛탕이죠. 불만 토로하지 말고 시키는대로 하거나 다른 좋은 마인드를 가진 회사를 찾아봐야죠.

    그리고 이건 여담인데요, 적은 급여받고 레벨업 한다치고 야근, 주말근무 자주 하시는 개발자분들... 주변의 다른 개발자들 힘들게 하는거 아시는지 모르겠네요. 경영진 입장에서는 싼값에 일을 많이 하는 직원을 선호합니다. 개발자들이 중시하는 퀄리티 라는건 안중에도 없는 경영진 많습니다. 돌아가기만 하면 개발 끝난 것처럼 생각하는 무식한 경영진 많다는겁니다. 시키는대로 일정만 맞추려고 부실공사로 건물 여러개 만들다보면 현재 직면한 잘못된 개발자문화 문제들이 반복 된다는걸 아셔야 할 겁니다.

    • Yuno.org 2010.03.20 14:59 신고

      네 맞습니다. 제일 힘든것은 [3]이죠. 어지간해서는 스트레스 받을텐데 다행히 저희 회사는 안그렇군요. (자랑)

      좋은 의견 감사드립니다 :)

  • 구차니 2010.03.20 10:47

    예상시간 추정이란게 거의 무의미할 정도로 예측불가능하기 때문이 아닐까 생각이 됩니다.
    처음써보는 혹은 써봤지만 개발에 적용하기에는 몰랐던 부분도 많고
    그로인해 파생되는 문제를 하나둘씩 해결하다 보면 기하급수적으로 시간이 지연되니 말이죠.

    머.. 자조적으로는 "다 내 개발능력이 부족한 탓이야" 라고 하지만..
    가끔 정말 일정이란걸 감안하고 그거에 맞추는걸 보면 신의 능력이 필요하지 않을까 생각이 되더라구요

    • Yuno.org 2010.03.20 15:02 신고

      네 맞습니다. 그렇기 때문에 경력자가 필요한 이유이기도 합니다. 경력자는 지금까지의 경험(소위 노하우)로 인하여 신입 보다 더 높은 적중률을 가지고 있죠.

      어쨋든, 예상이기 때문에 틀릴 수 밖에 없는건 어쩔 수 없습니다. :) 그렇게 배워 나가고 발전하는거죠 뭐 ..;

  • 글쎄요 2010.03.20 14:21

    비유를 하자면 이런거죠.
    당신이 제빵사인데 당신 생각에는 하루에 500개 정도의 빵을 구을수 있다고 생각하고 있습니다.
    그런데 갑자기 빵가게 주인이 1000개를 요구했다고 합시다.
    아니면 케잌은 처음 만들어 보는데 갑자기 케익 500개가 필요하다거나...
    그러면서 그러겠죠 정말 미안하지만 어쩔수 없다고 우리가게가 살려면 어쩔 수 없다고...
    물론 밤을 새서라도 하겠죠 (아님 그만 두던가... 하지만 제빵사라는 자존심이 하게 만들겠죠?)
    한두번이라면 상관없지만 계속 반복되거나 심지어는 이제 그것이 기준이 되어갑니다.
    그럼 당신은 틀림없이 지쳐갑니다.
    그러면서 배우게 되죠.
    내가 구을 수 있는 빵의 최대치를 200개라고 그랬다면 좀 더 여유가 있었을 것이다.
    아니면 새로운 분야는 할 수 없다. 할려면 나한테 공부할 시간을 달라고 그럴껄...
    뭐 이러면서 점점 방어적이 되어가게 된다는 거죠.

    이 시점에서 한번 생각을 해보십시요.
    다 가게가 살기 위해서 하는 일이다 라고 그럽니다만 결국 제빵사의 희생만 요구하는 겁니다.

    우리나라 개발자들의 현실도 이와 다르진 않습니다.
    괜히 3D라고 하지 않습니다. 무조건 일을 던지면 어떻게 해서든 일을 하거나 아니면 비명을 지르거나 일단 일을 던져보자는 심산이죠
    손해 볼꺼 없으니깐... 개발자 경력 약 10년 동안 얻는 결과 입니다.

    영업(기획) - PM - 개발자 : 서로 동등한 관계가 되는게 최선이겠죠
    그리고 자신들은 희생하지 않으면서 개발자의 희생만 요구하는 이런 문화도 개선되어야 합니다.
    개발자에 회의를 가지기 시작하는 일인입니다.

    • Yuno.org 2010.03.20 15:05 신고

      네 맞습니다.

      그렇기 때문에 1000개의 빵을 요구 받는 당황이 되면 안되는겁니다. 1000개의 빵을 더 구워야 한다는 결정이 내려지는 회의에 프로그래머가 있어야 하는겁니다.

      그게 최고 경영진에서 결정 되는 것이라면 프로그래머의 입장을 대변해주는 것은 CTO일 것이고, 일반 회의라면 참여한 프로그래머가 되겠죠.

      초기 결정 단계에서 이것이 녹아 들어가 있지 않는다면 모두의 희생으로 밖에 보이지 않게 되는겁니다.

      그러고 보니, 대부분의 회사가 CFO, CEO는 있지만 CTO는 없군요. 어익후-

  • ㄹㄹㄹ 2010.03.21 07:35

    문제의 본질은 연봉이나 보수죠..
    연봉 최소 5000애 야근수당 및 성과급 옵션까지 때려주면 이 글에서 언급된 내용은 온데간데없이 아주 적극적으로 일할겁니다.

    • Yuno.org 2010.03.21 11:54 신고

      꼭 그렇지는 않습니다. 급여는 절대 '만족'을 가져올 수 없습니다.

      처음 받기 시작 할때와 조금 지난 후의 사람 마음은 절대 같을 수 없거든요 :)

  • 09kim 2010.03.26 11:07

    본질적으로는.. 작업기간에 대한 예측이 어렵기 때문 아닐까요?

    작업 도중 난관에 봉착하게 되기도 하고.. 작업요청 내용이 진화하기도 하니까요.;

    그리고, 개발 공정의 끝부분에 프로그래머가 위치하기 때문에

    '일정 펑크의 원흉'으로 몰리는 경우가 허다하니 이것도 방어적인 태도를 취하는 한 요인이 될 것 같습니다.

    가령 기획서가 늦게 나왔거나, 그래픽 리소스 제작에 문제가 있었더라도

    출시 (혹은 패치) 시기에 작업을 하고 있는 건 대부분 프로그래머 이니까요.

    • Yuno.org 2010.03.26 15:52 신고

      네. 작업 기간의 완벽한 산출은 사실 불가능에 가깝습니다. 그 불가능에 가까운 산출 기간을 최대한 오차를 없애는게 기획 단계에서 개발자 회의 참여의 주 목적이기도 하죠.

      스케쥴을 비롯해서 기획 회의 단계에서 10을 A까지 완성 하기를 결정된 단계에서 프로그래머가 이후에 손을 대서 10과 A가 둘다 변경 되는 것 자체를 보정하기 위한 방법이기도 하구요.