개발자가 안된다고 했을때의 진짜 이유

최근 20년 사이에 우리나라의 개발자 역할 중에 무슨 제품을 만들지  또는  무슨 기능을 만들지에 기획역할이 빠져나간  경우가 많은 것 같다.  특히 인터넷 비지니스에는 웹 기획자 라는 이상한 직군이 있어서,  기획은 기획자라는 사람이 하고, 개발자는 개발만 하는 것 같다.

기획자, 개발자, 비주얼 디자이너 역할이 분리되어 있는 조직에서는 기획자와 개발자의 갈등, 개발자와 디자이너의 갈등, 기획자와 디자이너의 갈등이 있다.  HCI 에서도 오래전에 이런 이슈들이 컨퍼런스에 다루어졌는데, 여전히 현업에서는 갈등이 있다.

개발자, 기획자, 비쥬얼 디자이너들은 서로간의 갈등을 줄이고 협업을 잘 하기 위해 많은 고민을 하고, 그런 고민들이 여러 블로그글에서 논의되기도 한다.

내 생각에 기술은,  개발자는 무엇인가를 가능하게 한다. 마법사 처럼 말이다.

그래서 기획자나 비주얼 디자이너는 보통 개발자에게는 뭔가를 가능하게 요구한다

“이런 기능을 만들어주세요.”

“이거 다음에 이거 나오게 해주세요”

“이거 해주세요”  등등

가끔 개발자가 이런 대답을 하는 경우가 있다

“이건 안되요”

“이건 힘들어요”

기획자나 디자이너는 기술을  모르니 그런가보다 하고 넘어가는 경우도 있고, 정말 안될까 하고 의심을 하기도 한다. 그런데 기술을 모르니 개발자가 안된다고 하면 안되는 것이다.

그런데 과연 안된다고 얘기하는 개발자의 진짜 마음 무엇일까?

내 경험으로 봤을때 개발자가  안된다고 했을때  진짜 이유는 다음 3가지 중의 하나라고 본다.

1. 할줄 모른다

2. 시간이 부족하다

3. 하기 싫다

 

 1. 할줄 모른다. 

개발자는 듣기 싫어하는 얘기겠지만, 내 경험으로는 이 경우가 제일 많았다.

물론 OS 나 사용하는 플랫폼의 기술 스펙 자체가 안되는 경우가 있다.   하지만 자기가 할줄 모른다고  안된다고 얘기해서는 곤란하다.

세상에 안되는 것이 어디있겠는가?  그걸 내가 지금 당장은 알지 못하거나, 진짜 어렵다고 해도 다만 시간이 많이 걸리거나 꼼수를 부려야 할 뿐이다. 플랫폼의 스펙이 지원하지 않는 경우에도 꼼수를 부리는 경우도 있는데, 많은경우 시간이 지나면 그런 꼼수들도 플랫폼에서 기본으로 들어가게 되거나 가능하게 하는 기술이 나오기도 한다.

웹은 원래 connection-less 라서 세션 개념이 없고 정적인 문서였다.  정적인 웹 페이지를 동적으로 만들어 내기 위해서는  CGI  방식이 있었고, 오라클 같은 DB는 세션을 가지고 있었는데, 웹서에 연결해서 디비를 호출하면 매번 로그인하고, 검색하고 로그아웃을 했었다.     C로 만든 CGI가 매번 포크되고, 매번 디비센션을 맺는 것을 없애기 위해 96년도엔가 우리 대리님은 그걸 처리해주는 데몬을 만들었다(회사에서 우수논문상을 받기도 했다).  97년인가 98년도에 지금은 망했지만 넷스케잎사는 커넥션을 무는 라이브와이어라는 솔루션을 내 놓았고, 웹서버 상에서 인터츠리터되어 속도가 빨라진 PHP 나 ASP, JSP  같은 것도 나왔고, 로드밸린딩를 해주는 솔루션도 나왔다.

불가능하거나 기존 기술로 꼼수를 부리다가 시간이 지나면 해결해주는 새로운 기술이 나오기도 하지만, 현재의 기술상에서 딱 맞는 기술이 없으면 꼼수일 수도 있지만 필요한 것을 해낼 수도 있다. 마치 원시시대에도 뭔가를 먹었고, 지금도 뭔가를 먹는 그런 사람들의 니즈가 바뀌지 않고, 도구만 바뀌듯이 말이다.  할 수 있는 것으로 하는 것은 그냥 하는 것이다.

그럼에도 불구하고 개발자가 “안된다” “어렵다” 라고 얘기하는 것은, 어찌 보면 기술자 문외한에게 선언적으로 답을 하는 경향이 있는 것은 아닌가 싶다.

 

개발자가 영업사원은 아니지만,  “내가 아는 한 모르겠다. 그 분야의 잘 하는 사람을 찾아보겠다” 등의 방식으로 얘기하면 어떨까 싶다.

기획자나 PM은 이런 말을 들으면 그 분야에서 잘 아는 기술자를 찾아서 붙여 주는 것이 좋다.

예전에 내가 모시던 부장님은 개발 경험이 적은 개발팀장이셨는데, 개발자가 잘 모른다고 하면 그 분야에서 가장 잘 아는 사람을 대라고 하고, 그 사람들을 데려 오시거나 안되면 컨설팅 형식으로도 데려오서 문제를 해결 하셨는데, 어찌 보면 관리자라는 사람은 문제를 해결할 사람을 찾아서 데려오는 것도 중요한 역할인 것 같다.

 

2. 시간이 부족하다

그 시간에 맞추지 못할것 같으니 안된다고 얘기하는 경우도 많은 것 같다.

얼마나 일을 잘하느냐는 그것을 해내는 것 자체가 아니라 그 일의 품질이 좋고, 빨리 한다는 것도 포함된다.

할줄은 알고 잘 하는데 시간이 부족하다면, 그건 진짜 시간이 부족한 것이다. 작업 양을 조절하거나 순서를 바꿔야 한다.

진짜 구현이 안되는 것이 아니라 시간에 못 맞춘다는 의미이다.

그러나 아예 할줄 모르거나, 잘 할줄 모르는데 시간이 부족하다면, , 잘 아는 사람을 데려오거나, 진짜 개발기간을 늘리거나 우선선위를 바꾸면 된다.

 

그런데 고참 개발자나 개발 관리자들은  “안된다” 는 대신 “시간이 부족하다”고 얘기하는 경우가 있는 것 같다.

할줄 모른다고 하기는 쪽팔리고, 할수는 있을 것 같지만 공부를 해야 하거나  꼼수를 많이 부려야 하니 일정 이슈로 돌리는 경우이다.  솔직히 얘기해줘야 대책을 세울 수 있다.  잘 모르는지, 아니면 할 짓이 많은 지 말이다. 잘 모르면 잘 하는 사람을 붙이거나 잘 안되는 부분을 해결해줄 수도 있고,  시간이 있으면 교육을 보낼 수도 있다.

할줄 몰라서 안된다고 하면 , 만들어서 보여 주면 되지만,  시간이 많이 걸린다고하면 대신 해줄 수가 없다.  결국 기간을 늘리거나  사람을 더 넣어줄 수 밖에 없다.  물론 목표일정으로 평가하는 방법이 효과적일 때도 있다.

 

 

3. 하기 싫다 

개발자가 기획자나 PM, 비쥬얼 디자이너 사이에 뭔가 갈등이 있거나 , 자기 평가에 별로 관련이 없어서인 경우도 있는 것 같다. 실제로는 할줄 알지만 하기 싫어서 인 경우이다.

기술자가 안된다고 하면 안되는 것이지만, 된다는 것을 안다면, 이건 정말 사람 관계가 풀어져야 한다.  결국 사람이 하는 일이다.

관계가 안풀어지면 조직관리상의 보쓰에게 이 사람 기여를 평가하게 하거나, 그 사람의 보쓰를 인게이지 하는 것도 방법이다.

사람이 하는 일이라,  감정을 풀어야 하고, 안풀어지면 남은 방법은 사람을 바꾸는 수 밖에 없는 것 같다.  프로는 감정과 상관없이 해야할 일을 해야 한다고 하는데, 사람사는 일이 꼭 그렇겠는가.

그런데 이건 알기가 쉽지 않다.   기술적인 것이라면 할줄 모르는지, 시간이 많이 걸리는지 딱 보면 아는데, 하기 싫은지는 감정인지라 쉽게 알 수 있는 것은 아니다.

 

***

이 글을 쓴 이유는 기획자나 비주얼디자이너. PM 입장에서 개발자가 “안된다. 힘들다” 라고 했을때, 진짜 개발자의 이유(진짜 기술스펙이 안되는 것인지, 못하는 것인지, 시간이 없는 것인지, 하기 싫은 것인지)를 알아서 그 문제의 원인을 해결기 위함이다.

그러나 이 문제를 해결하기 위해서는 문제 자체인 개발자가 안된다고 한 그것이 진짜 안되는지를 아는 것이 필요하다.

그런데 기획자,비주얼디자이너,PM이 기술자일 수는 없다. 그러면 뭐하러 분업을 하겠는가 !

개발자가 자기의 상태를 솔직해 얘기해주는 것이 가장 쉬운 방법이다. 물론 하기 싫은 것을 얘기하는 사람은 별로 없지만 말이다.

 

개발자가 안된다고 했을때 진짜 이유에 대해 얘기했지만, 사실 개발자 뿐만 아니라 비주얼 디자이너,  기획자에게도 적용되는 것 같다. 하기 싫어서 어렵다고 얘기하는 경우도 없지는 않다.

비주얼 디자이너의 경우,  산출물이 개발자 처럼 된다 안된다는 식이 아니니 하기 싫으면 오래 걸린다라고 말할 수도 있다.

기획자의 산출물은 된다/안된다도 아니고, 오래 걸린다라고 말하기 뭐하고, 뭐라 변면할 게 없는 것 같다.

 

내가 아는  회사의 직원들은 하기 싫거나 동의하지 못할때 이런 표현을 한다 “저는 잘 모르겠습니다.”

결국 문제는 기술력의 문제가 아니라  다 사람 문제이고, 역할간의 “신뢰” 나 “커뮤니케이션” 문제인것 같다.

개발자가 하고 싶다면, 위의 3가지는 아무 문제가 안된다. 할줄 모르면 방법을 찾고, 시간이 없으면 더 열심히 하기 때문이다.

인터렉션 디자이너나 프로젝트 매니저는 이게 얼마나 중요한 것이고, 비전은 무엇이고, 사용자 가치와 사업 가치가 무엇인지에 대해 얼마나 개발자의 공감을 샀는지 되돌아볼 필요가 있다.   모든 사람이 만들고 싶은 제품을 만들 수는 없지만 개발자도 만들고 싶고 (기술력만 높은 개발자가 만들고 싶은 것을 만들면 꽝 될 수 있다^^) , 사용하고 싶은 제품을 만드는 느낌이라면 위의 세가지 문제는 문제가 안되는 것 같다.

 

다 사람 문제이고, 신뢰 문제이고, 열정과 절실함의 문제이다.

 

 

Related Post




  • Jae-Kwang Lee

    자칫하면 이 글이 기획자나 혹은 PM에게 안좋은 선입관을 줄 수 있겠다는 생각이 듭니다.

    현재 기술이나 스펙으론 개발이 어렵고 시간 투자 대비 효용성이 떨어지거나 혹은 머리를 쥐어짜며 지저분한 방식의 꼼수를 사용하면 해결 가능한 문제에 대해 “할줄 모른다”라고 표현하는 건 어폐가 있지 않을까요.

    물론 개발자들이 이를 단순히 ‘안된다’라고 말하는 커뮤니케이션 방식에도 문제는 있지만, 아무래도 표현 자체가 오해의 소지를 줄 수 있기에 개발자로써 기분이 썩 좋지는 않네요.

    국내 개발자들이 이런 방어적인 포지션을 취하게 된 원인에는 대부분의 프로젝트가 이미 일정이 Fix된 상황에서 Waterfall 방식으로 진행 되기 때문에 dobiho님이 말씀하신 3가지 경우처럼 표현하는 경우가 많지 않을까 생각합니다. 된다고 답하면 일정에 쪼여가며 철야를 해서라도 결과물을 내야하는 것이 현실이니까요.

    • 네, 불편한점을 일부러 들춰내야 그만큼 클 수 있다는 생각도 있었구요,

      그래서 혹시나 기획자나 PM이 이런글을 읽고 오도를 하지않을까 하는 걱정이 없었던 것은 아니었지만, 기술이 아니라 결국 팀웍이나 “신뢰”의 문제라는 얘기를 하고 싶었습니다.

      기술자의 산출물이 있다/없다가 좀 명확해서 예를 든 것인데, 디자이너, 마케터, 영업, 경영자나 모두 같은 문제라고 봅니다.

      “바보야 문제는 경제야” 처럼 얘기해보면, “문제는 신뢰야” 인 것 같아요

      의견 감사합니다

  • Won YongBong

    좋은 글 잘 읽었습니다.

    제가 보통은 답글을 잘 쓰지 않습니다. 하지만 dobiho님의 글은 많은 분들이 읽고 또 좋은 글이라서 공감을 이끌어 내기에 어쩔수 없이 짧은 글이나마 적고자 합니다.

    글에서 언급하신 것처럼 개발자들의 소통방식에 문제가 있다는 것은 충분이 이해합니다.

    하지만 그 문제는 대다수의 개발자들이 소통방식에 대해 충분한 교육과 이해가 부족하기 때문에 나타나는 현상이라고 생각합니다. 또한 앞에서 Jae-Kwang Lee 님이 말씀하신 것처럼 현재 우리나라의 SW개발 과정에 문제가 있기 때문이기도 합니다.

    그러한 현상을 dobiho님께서 독자들에게 충분히 이해시키지 않은 상태에서 개발자들은 이러이러하게 소통하니까 거기에 대해서 이러이러하게 대처하고 개발자들은 이러이러하게 다루어야 한다는 어감으로 글을 쓰시는 것은 개발자들에 대한 편견을 심어 줄수가 있을것 같습니다.

    저는 dobiho님께서 팩트 위주(기왕이면 case study 방식)로 개발자들이 다른 직군분들과 원활하게 소통할 수 있는 방법론적인 글을 써 주시기를 부탁드립니다. 그러면 소통의 부재로 지금도 개발의 외딴섬에서 홀로 고군분투하고 있을 많은 개발자들에게 많은 도움이 될수 있을것 같습니다.

    • 네. 좋은 의견이네요. ‘개발자의 커뮤니케이션 스킬’ 이런게 있으면 좋겠네요. 저는 겉으로 표현되는 것 뒤에 “의미” 가 있다는 얘기를 하고 싶었어요. 어럽게 댓글 달아주셔서 감사합니다.

  • _

    평법한 개발자입니다.
    기획의 이야기를 거절할때 의 제 경험으론 1, 2번보다는 3번이 압도적으로 많은데, 제가 열정이 없어서 그런다고 진단하신다면 좀 억울한게 나름 기준이 있습니다.

    1. 시간대비 효용성
    2. ux적인 관점
    3. 복잡도 대비 효용성

    개발자이신지 기획자이신지는 잘모르겠습니다만, 기획자의 기획은 대체로 유용하다고 생각하시나요? 기획자가 개발자들에게 가치를 재대로 설명 하던가요?

    • _

      > 기획자,비주얼디자이너,PM이 기술자일 수는 없다. 그러면 뭐하러 분업을 하겠는가 !

      뭐 공부하기 싫으시다면 제가 뭘 강제할수 있는건 아닙니다만, 뭐가 가능한지모르는 사람이 좋은 기획을 할 수 있을까요?

      • 기술은 뭔가를 가능하게 해주니, 기술이 가능한 것을 먼저 보고 사람들에게 필요한 것을 제공할 수도 있고, 사람들에게 필요한 가치를 먼저 생각하고 기술이 그걸 구현하는 경우도 있더라구요.

        개발자 출신의 기획자나 기술을 잘 이해하는 기획자의 단점은, 구현 방법을 알기 때문에 개발자를 더 닥달할수도있고, 개발자는 이해를 더 받으려고할 수도 있고, 상상력이 줄어들 수도 있구요, 마치 디자인패턴언어 때문에 개발자의 설계능이 떨어질지 모른다는 우려와 비슷하죠

        기획자는 사용자와 시장에 가치있는 것에 대해 현재나 기술의 가능성과 상관없이 꿈을 꾸는 것이 필요한것 같아요. 안그러면 구현할 수있는 개발자가 잠깐 기획하면 되지 않을까싶어요

        뭐가 가능한지 잘 알아서 그것에 맞게 기획하는 기획자보다는 사람들에게 필요한 것에 대해 마구마구 상상해주는 기획자도 필요한 것 같아요. 그런 다음에 현실로 내려와서 꿈을 사용자에게 제공하기 위해서 가능한 부분을 살피고, 현재 기술로 안되는 것은 꼼수로 쓰고, 뭐 그런게 아닐까 싶어요

        현실에서 기획자나 영업하는 사람들과 부닥치면서 살고 있겠지만, 가끔은 잠깐 떨어져서 생각해보는 것도 좋은 것 같더라구요

    • 어떤 한사람이 아니라 멀리서 보는 시각이라서 너무 대립각을 세우지는 않으셔도 될 것 같아요.

      기획은 잘 하고 있나? 비주얼 디자인은 잘 하고 있나? 개발은 잘 하고 있나? 그럼 영업은 잘 해오고 있나? 사장님은 잘 하고 있나?

      이렇게 가면 일이 아니라 사람이 힘들어지는 상황으로 가게 되는 것 같아요. 각자 최고를 향해 부단히 노력하겠지만, 서로 속 마음을 잘 이야기하는 것도 중요한 것 같아요

      의견 감사합니다.

  • 박재관

    투입공수에 대한 정확한 비용인식을 윗선에서 해준다면 해결될 문제로 보이고.
    현실적으로는 각자의 위치에서 “헌신”이 필요한 문제기에 강요할순 없다고 생각되어집니다.
    고객을 생각하며 늘 고민하는 개발자 올림




Scroll Up