(꿀위키 펌) 비개발자 출신 사장이있는 IT회사의 유형

HYEONG HWAN, MUN/ 2월 4, 2015/ 미분류/ 19 comments

https://blog.lael.be/post/796

.

이 문서를 작성한 이유

비 개발자 대표는 자격이 없다는 말을 하고싶은것이 아니다. 기본적으로 회사는 같이 일하는 개발자, 디자이너, 기획자 등을 어떻게, 혹은 누구를 사용하냐에 따라 프로젝트 일정이 달라진다. 이 부분은 현장에서 제 목소리를 내지않고있는 개발자들을 위해 만들어졌으며, 아마 대부분은 공감을 하고 있으리라 믿는다(공감이 안되거나 추가적인 의견이 있는경우 항목에 추가해주세요) 개발자를 이해하지 못하는 회사는 개발자의 업무만족도나 능력에 관계없이 개인적인 성과, 의욕을 떨어뜨려서 생산력을 저하시킨다. 성공한 IT계열 스타트업들의 회사대표의 대부분이 개발자(NHN, 다음, 카카오, 구글, 애플, 트위터, 페이스북 기타 등등)인것만 봐도 어느정도 관계성이 없다고 할 수 없다 이 페이지는 궁극적으로 업무현장에서 개발자와의 커뮤니케이션이 원활하게 되었으면 하는 마음에서 작성되었다

Context Switching 이란?

일을 하다보면 새로운 일을 해야한다며 별 중요하지도 않은 이야기를 들고오거나, 회의를 해야한다고 일하고 있는 사람을 방해하는 경우가 있다. 이 때 원래하던일(A)에서 새로운일(B)사실 중요하지 않은로 완전히 넘어가기 위해 머릿속에 머릿속에 필요한 정보들을 채우고 유기적으로 연결시켜 맥락을 완성하는데 필요한 시간을 컨텍스트 스위칭이라고 하며 한업무에서 다른 업무로 완전히 넘어가 일을 시작하는데 필요한 시간이 20분이라고 한다. 그러니 일하고있는 사람을 방해할 때 마다 20분의 시간이 소모되는셈, 개발자인 경우엔 이 비용이 더 높을 수가 있는데 개발자의 머릿속에서는 수십개의 변수명과 중요한 API의 클래스명, 메서드명 그리고 코딩순서와 알고리즘, 시스템 구성에 대한 추상적 그림 등등 여러가지 필요한 정보들을 생성해놓고 코딩을 하며 몰입을 하기 때문에 누군가의 방해를 받으면 이러한 정보들이 한순간에 날아가 버린다, 왜냐면 사람의 워킹메모리는 컴퓨터의 RAM과 같기 때문, 그러니 제발 정말 필요한 경우 아니면 말걸지 말고 점심시간이나 커피타임에 말을 해주길 바람, 하루 8시간일하는데 그 시간을 낭비하고 싶지않다. (누군가의 분노가 느껴진다!!)

비 개발자 관리자를 만나면 겪게 되는 일들

  • 개발자와 같이 일할 때는 유지보수성을 높이기 위해서 서비스의 내부구조를 바꿔야 한다고 하면 이해를 하지만, 비개발자인 경우에는 왜 그런일을 해야하는지 이해시키기가 쉽지 않다 사실 이해를 못한다.
    • 예를 들어 같은 기능을 개발하더라도 내부구조를 바꾸기전에 10일이 걸린다면 바꾼후에는 3일정도 걸린다.
    • 물론 잘 돌아가는 서비스의 내부구조를 바꾸거나 새로만드는건 신중해야하지만 말도 안되는 형태로 만들어놓은 경우에는 앞으로의 서비스를 위해서라도 100% 바꾸는게 낫다 형말들어
  • 자꾸 와서 어떻게 한거냐고 물어본다.
    • 말하면 이해하나? 하루 8시간 일하는데 이해도 못할거 설명하느라 1시간을 낭비한다.
  • 매일 찾아와서 어디까지 됬냐고 물어본다.
    • 하루종일 백엔드로 고생한 개발팀인데도 불구하고 UI에서 바뀐게 없다며 일을 하고 있는거냐며 핀잔을 준다.
    • 사실 개발자가 아닌 사람은 UI가 되면 다 된것처럼 보인다. UI보다 백엔드 작업이 더 많은게 당연한건데 이걸 이해하지 못한다. 그럼 결국 고통받는것 밖엔 방법이 없는가

경험이 없는 비개발자 대표

  • 프로젝트 일정을 낙관적으로 정해버려서 개발자를 당황시킨다.
    • 스스로 멋대로 일정을 정하고 난 뒤 “어때? 이정도 일정이면 되지?? (찡긋)” 하며 자신의 어깨를 으쓱한다.
    • 심할경우 1 ~ 2주로 정하는 경우도 있다함.. (개발자가 아니기 때문에 Back-end 작업량이 어느정도나 많은지 가늠을 못한다)
    • 그냥 게시판 정도인데.. 이정도면 되잖아?? 너 그정도밖에 안되? 정말 이말을 살면서 10번은 더들은거같다.
  • 개발프로세스에 대해 공부를 안하려고 한다,
    • 사실 필요성 자체를 못느끼고 그런것엔 관심도 없다. 나는 항상 멋진 아이디어를 제조하는 한국의 스티브잡스일 뿐이고 개발자는 그냥 제품이나 만들면 된다.
  • 개발중간에 기획이 바뀐다는것의 의미를 모른다.
    • 강남에 128층빌딩을 짓고 있는데 이 건물을 수원으로 옮기고 싶다는 의견을 제시한다. (비유)
      • 가끔 이상한 소리를 개발자에게 진지하게 말하는데 이해시키기가 쉽지 않다. (개발지식도 없는데 고집까지 있으면 최악)
    • 설계와 프로젝트의 근간을 흔드는 경우임에도 불구하고 자신의 눈에는 별 것 아닌것처럼 보이기 떄문에 항상 개발자와의 트러블이 있다.
    • 기획은 바꾸지만 일정은 전혀 바꾸지 않는다 크게 바뀐것도 아닌데 호들갑을 치는 개발자를 보며 나는 왜 이런 멍청한애를 뽑았나 라는 생각을 하며 엘리트 프로그래머는 분명히 내가 바꾼 기획안을 제 시간내에 멋지게 해낼 수 있으리라 생각한다.
  • 디자이너의 중요성을 모른다.
    • 최신 트렌드나 타깃계층을 생각하지도 않고 오로지 내 눈에 맞는 시안을 만들라고 떼를 쓴다.
    • 디자인은 항상 바뀌어야한다는 법칙 자체를 이해를 못하고, 디자인은 한번 만들면 끝이라고 생각을해서 회사내에 디자이너를 두려고 하지 않는다.
    • 혹은 디자이너에게 디자인도 하고 경리도 하고 이벤트도 준비하며 커피도 타오고 프로그래밍(응?)도 시키고, 디자인 시안이 나오면 디자이너의 업무는 끝이라고 생각해서 디자인 외 일을 시키고 싶다.
  • 개발자는 열정이 있기 때문에 어느정도 고생을 해도 된다.
    • 무릇 개발자란 밤 12시에 퇴근해서 밤의 정수를 마시는것이 미덕이라고 생각한다.
  • 개발자는 키보드에 앉아있는 공장직원일 뿐이다.
    • 개발자가 일에 집중하고 있을 때 방해하는것이 머릿속으로 그려온 코드의 흐름을 깨는일인지 모르고 있고 이것이 어느정도의 생산성저하를 불러오는지 모른다.

경험이 많은 비개발자 대표

  • 일정을 정하기 전에 반드시 개발자에게 먼저 의견을 물어본다.
    • 너무 일정이 길다고 생각은 들지만 일단 개발자를 신뢰하기로 한다. 그리고 나서 일정을 줄이기 위해선 어떤것이 필요한지 다시 한번 물어본다.
    • 일정을 조정해야 겠다고 생각한 경우 기획에서 불필요한 것이 있는지 점검하고 개발자와 일정과 기능구현범위를 합의한다.
  • 개발프로세스의 중요성을 그간의 경험을 통해서 잘 알고있다.
    • 애자일스크럼, TDD같은 용어를 들어본 적이 있고, 관련 컨퍼런스나 세미나에 참관하는 것을 즐겨한다.
    • 개발자에게 일정이 지연되는 이유는 무엇이었는지 현재 회사의 프로세스는 어떤지 물어본 적이 있다.
  • 개발중간에 기획이 바뀐다는것이 얼마나 어려운지 잘알고 있다.
    • 진행중인 프로젝트에 인터스텔라와 인셉션 등 여러가지 아이디어를 추가하고 싶지만, 일단 핵심적인 기획에만 집중하기로 하고 다음 고도화작업때 추가적인 아이디어를 제시해봐야겠다고 생각한다.
    • 짧은 단위의 기획과 데모버전을 반복해서 시스템을 발전시키는 경우가 가장 좋은 모델이라고 배운적이 있다.
    • 정말 기획을 바꿔야 겠다고 생각한 경우에는 일정을 어느정도 미룬다.
  • 디자이너의 중요성을 잘 알고있다
    • 내 자신의 주관적인 디자인 감각보다는 현재 트렌드는 어떤지 우리 프로젝트의 주 타깃은 누구인지를 고려할 줄 안다.
    • UIUX라는 단어를 알고 있다.
    • 좋은 UI와 UX가 나오기 위해선 디자이너가 꾸준히 감각을 길러야 한다고 생각하기 때문에, 프로젝트가 끝나 일이 없을땐 색감을 연구하거나 기타 영감을 줄 수 있는 활동을 하기를 권장한다.
    • 자신의 디자인 감각과 직관을 믿지 않는다. 나는 소유자이지 사용자가 아니다.
  • 야근은 생산성을 저하시킨다고 생각한다.
    • 2배의 시간을 들인다고 2배의 퀄리티가 있는 제품이 나오지 않는다는것을 알고 있다. (100명을 투입해서 100배 빠르게 제품이 완성되는건 아니잖아? 혹은 엄마가 10명이라고 애가 한 달만에 나오지 않잔아?)
    • 야근을 시켜봤자 저녁먹고 일하면 실제 일을 하는시간은 3~4시간 밖에 안되는데 이것때문에 다음날의 8시간을 망치고 싶진않다.
    • 물론 시스템의 장애가 있을경우엔 반드시 시켜야한다.
  • 그간 개발자와 커뮤니케이션을 많이 해보았기 때문에 일에 집중하고 있는 개발자를 건드리지 않는다.
    • 필요한 회의는 미리 시간을 정해서 약속을 잡는다.
    • 추가적인 업무를 부탁할때는 Trello나 JIRA를 이용하거나 물리적인 칸반보드에 필요한 내용을 추가하고, 다음날 아침 혹은 퇴근시간 전에 이야기를 한다.
    • Context switching 이란 단어를 소프트웨어 조직관리에 관한 책에서 본적이 있다.
    • 개발자를 이해하기 위해서 여러 관련서적을 찾아보고 읽은 적이 있다.

 

19 Comments

  1. 이와 같은 루틴은 모든 전문 기술 보유 을과, 미보유 갑 사이에서 벌어진다. 아트건 영상이건 심지어 PT건 간에.
    말도 안되는 일정 우겨서 야근에 주말 출근으로 만들어 내면, 자기 리더십과 추진력이 엄청 뛰어난 줄 안다.
    보상이나 제대로 주면 양반이다.

  2. 마지막 추가.
    이러한 내용을 읽게 해 주거나, 알려줘도 본인이 그런사람이라고 인지하지 못한다.

  3. 페이스북 공유글 링크타고 왔습니다. 좋은 글 잘 읽었습니다.

    1. 감사합니다. 의외로 공감하는 사람이 많다는 것이 약간 슬프네요

  4. 정말 좋은 글 잘 읽었습니다.
    저는 개발자 출신의 기획인데,
    저도 참고할만한 부분이 굉장히 많네요.
    그리고 비개발출신의고집센 제 전 상사에게 꼭 보여주고 싶습니다.

  5. 결론적으로 공감합니다.. 하지만 비개발자들의 생각일수도 있을 것 같아서 글을 남겨봅니다.

    개발자와 같이 일할 때는 유지보수성을 높이기 위해서 서비스의 내부구조를 바꿔야 한다고 하면 이해…
    > 해당 부분 이해합니다. 하지만 사업을 영위하고 공격적으로 펼치기 위해서는 시간이 매우 중요하다고 생각합니다.
    > 관련 이런 부분을 이해하고 합의/협의점을 찾으려고(혹은 함께 찾아주려고) 노력하는 개발자는 얼마나 되는가? 라고 질문하고 싶습니다.
    > 물론 개발비용은 줄어들고, 개발기간도 함께 줄어드는 비합리적인 흐름이지만, 자신의 고집과 경험만을 고집하며 너무 쉽게 “아~ 이거 싹 갈아엎어야 합니다.” 라고 답변하는 개발자를 너무 많이 보았습니다.

    개발자와 커뮤니케이션을 많이 해보았기 때문에 일에 집중하고 있는 개발자를 건드리지 않는다.
    > 집중하라고 초기에 일정을 물어보고 그냥 있으면…일을 몰아서 하는 개발자들도 많이 있습니다. 프로젝트가 진행될수록 코드가 처음과 다르게 막 진행을 하다보니..엉망이 되기도 하죠. 그리고 야근을 하기 시작하죠…그것도 회사 입장에서 다 돈인데 말이죠.

    소통 가능한 개발자(!)
    > 소통이 가능한 개발자를 찾기는 더욱 어렵습니다. 어떻게 설명하기 참…어려운 부분인데…단편적으로 프로젝트를 진행하면서 서로 소통을 하면서 “안되면 되게하는” 것보다 “그냥 안되는!” 식으로 대화가 자주 되곤 합니다.

    1. 좋은 사람 찾기란 참 어려운 것 같아요.
      연봉 많이 받는 사람이 꼭 좋은 사람은 아니더라구요.

    2. 공감합니다.. 소통가능한 개발자 찾기도 매우 어렵죠..

  6. 배움의 길을 열어주는 좋은 글이네요. 저도 좋은 기획자가 되겠습니다. 감사합니다.

    1. 이 글에서 배움의 길을 찾으셨다니 대단하신분 같아요

  7. 잘 봤어요.. 나도 말이나 글을 코드처럼 체계적으로 쓰고 할 수 있으면 참 좋겠네요.. ㅎㅎ 사람마다 컴파일러가 달라서 그 사람에 맞춰 컴케하기가 어려워요 ㅎㅎ

    1. 모든 것이 그렇지만, 글도 많이 쓸수록 잘써지는 것 같습니다.

  8. 프로젝트 일정을 낙관적으로 정해버려서 개발자를 당황시킨다.

    개발자 출신 대표일때도
    일정을 낙관적으로 보기도 합니다.

    특히 대표가 수퍼 개발자일경우에는 …

  9. 잘 읽었습니다.

    저도 프론트엔드로 8년간 일하면서 비슷한 글을 쓴 적이 있는데, 지금은 경험상 경력이 중요하지 개발자 출신은 큰 상관 없다고 생각합니다. 왜냐면 그동안 겪었던 최악의 대표 두 명이 개발자였거든요.

    자리가 사람을 만든다고, 아무리 기술적으로 이해하고 있어도 대표가 되면 달라지더군요. 위에서 언급된 문제점들… 안해야지 하면서 똑같이 반복합니다. 결국 성격이거든요. 특히 10명이 넘어 본격적인 매니징이 시작되면 치장한거 다 벗겨내고 사람이 그대로 드러납니다. 주목 받아야 하는 스타일, 혼자 다 하는 스타일, 직원과 경쟁하려는 스타일, 본문 처럼 잘 모르는 스타일, 소심한 스타일 등.

    리드 개발자에게 대표가 와서 일일이 참견하는 것 만큼 기분나쁜 것도 없죠. 영업과 경영만 공부해도 빠듯한데 기술적 디테일의 차이가 점점 커지게 되고, 그 와중에 개발 욕심이 크면 오히려 기술적 발전을 가로막는 독이 되죠.

    대표는 멋내기 보다는 가라앉는 배를 어떻게 살릴 것인가 결정해야 하는 순간이 왔을때 맨발로 뛰고, 모두에게 미움받고, 진흙에서 구를 수 있어야 합니다. 스타트업일수록 이런 경험자가 정말 중요하죠, 특히 경영과 영업에서.

    가장 이상적인 건 CTO를 거쳐서 직접 경영을 해본 분 에릭 슈미트나, COO 세릴 센드버그의 백업을 받는 주커버그가 아닐까 합니다. 문제는 나이가 많던 적던, 경력이 어쨌던 그런 사람을 만난다는 것이 매우 힘들다는 것이겠죠.

  10. 이글은 널리 보급되아야합니다

  11. 크 어쩜 이런 사이다 글을 작성하셨는지 ..! 너무 속이 시원합니다

Lael Moon에 답글 남기기 응답 취소

작성하신 댓글은 관리자의 수동 승인 후 게시됩니다.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
*
*