komin
45
2018-03-25 15:12:06 작성 2018-03-25 15:18:05 수정됨
39
11104

개발자를 찾던 스타트업 대표의 개발팀 정리 결과



예전에 개발자를 구한다고 글 한번 올린 적 있는 스타트업 대표입니다. 그간 많은 일이 있었지만 요약하자면 솔직히 그 분 땜에 회사가 발칵 뒤집어 졌고 댓글단 몇몇 분들이 저를 비난했었으나 결론적으론 '그 급여조차 아까운 인간'이 해당 개발자였던 것입니다. 경력 15년이 넘고 관리자까지 했던 사람이 최소한의 기본도 지키지 않아 능력있고 성실한 회사 팀원 전체가 엄청 열받았었습니다. 수습하느라 다들 자기 일 제쳐놓고 몇 달을 붙어있었으며 우리 회사 올해 1/4분기는 그렇게 날아갔다고 보시면 됩니다. 그 과정이 참으로 지난하고 드라마틱 했으나 결과만 간략히 써 보려 합니다.


'왜 몰랐냐? 니가 븅스니다'라고 하신다면 할 말이 없고요, 그 말도 절반 사실입니다. 제가 소스코드를 모르는 사람이니 사실 봐도 모를 수 밖에 없고 제가 일 터지고 맴의 상처를 받아 여기저기 털어놓고 보니 비개발자 출신 뿐 아니라 개발자 출신 대표 조차 백엔드나 풀스택 개발자의 실력 혹은 능력을 판별하는데 1년 이상 걸릴 수 밖에 없에 없다고 하네요. 플젝 1~2개를 해 봐야 명확해 진다고. 그리고 사람 믿고 뽑았는데 처음부터 의심의 눈초리로 감시할 순 없잖겠습니까. 


이미 일은 타 터졌고 무튼 사고(?) 내용에 대해 간단하게 얘기하면

1) 용역사 납품 기한을 지키지 않았음. (아씨 진짜 ㅈ뗄뻔함 ㅠ).

2) 퇴사 시 제대로 인수인계를 진행하지 않음.

3) 그리고 이 모든 것은 개발 실력이 똥인 탓이었고 소스코드를 열어보니 DB엉망이었음.


솔직히 오키 게시판은 우리회사 개발팀들이 전부 보고 있는 걸 알기 때문에 상세하게 쓰긴 어렵고요.

제가 개발자와 맺은 계약이 용역계약이 아니라 근로계약이기 때문에 딱히 민사를 진행할 생각도, 진행하고 싶지도 않고요. 말할 수 없이 빡이 쳤지만 되돌릴 수 없는 결과이므로 순조롭게 퇴사 절차를 진행했습니다. 


이번 일을 계기로 저는 사내 개발팀 자체를 없애고 필요할 때마다 프리랜서나 개발팀으로 움직이는 업체와 용역 계약을 체결해서 최소한의 결과물은 보장받아야 겠다는 생각이 들었습니다. 용역 계약은 민사로나마 보장받을 수 있는데 근로계약은 그것도 매우 어렵고요, 저도 이번 사건을 계기로 주변에 괜찮은 분들소수 알게 되어 외부 계약으로 체결하려고 합니다. 아무튼 이번 일 때문에 사업 방향도 깔끔해 지고 팀워크는 사실 더 좋아진 것 같습니다. 


혹시 저와 같은 비개발자 출신 스타트업 대표님들을 위해 개발자 주의 사항을 세줄 요약 하려 합니다.


3줄, 아니 3가지 요약:

1) 경력(년수)과 개발 실력은 비례하지 않는다.

2) 경력이 12년 이상인데  2년 이상 다닌 회사가 없는 개발자는 의심해 볼 것 - 레퍼런스 체크 필수.

3) 사내 서비스든 외부 용역 대행 개발이든 자신의 개발코드, 일정 및 현재 상황 등을 공유하지 않으면 절대 '괜찮겠지'하고 내버려 두지 말고 최대한 빨리 조치를 취할 것 - 제가 대표가 직원을 의심하면 안 된다, 팀은 곧 믿음과 신용이다 생각하고 이걸 안 해서 값비싼 수업료를 냈다고 생각합니다. 


혹시 다른 능력있는 개발자 분들이 비개발자 대표들이 개발팀 혹은 개발자를 제대로 관리할 수 있는 팁이 있다면 공유 좀 해주시면 도움이 되지 않을까 싶네요. 깃허브를 우찌저찌 활용해라, 어떤저떤 조짐이 보이면 조심해라 등등등이요. 

제대로 팀 청소 끝냈으니 올해는 대박날게요. 개발자나 개발 관련 고민있을 때 종종 눈팅하고 있습니다. 건강하세요.


3
3
  • 댓글 39

  • 스텁
    839
    2018-03-25 15:24:48

    코딩 테스트만 도입해도 많이 걸러질수 있을거라 생각합니다. 요즘은 아마 돈받고 코딩테스트 해주는 서비스도 많을거에요.

    2
  • komin
    45
    2018-03-25 15:34:54


    @스텁

    아쉽게도 3년 전엔 그런 서비스가 별로 없었네요. 요즘은 많이 생겼더라고요. 그리고 SI사업, 솔루션 개발이나 독특한 서비스 개발할 게 아니라면 굳이 사내 개발팀을 둘 필요가 없습니다,가 제 의견이고요. 지금까지와 다른 방향으로 저희 사업 방향이 정리되어서 개발자를 안 뽑기로 했습니다. 첨에 일 터졌을 땐 다소 괴로웠으나 나중에 정리되고 보니 솔직히 우린 모두 '신이 우릴 도왔다'라고 밖엔 생각되지 않을 정도로 폭풍이 지나가고 모든 것이 바로 잡혀 있었습니다..................................


    To all.

    돈 주고 하는 코딩 테스트도 그 사람의 개발팀 관리자로서의 업무 실력을 전부 보장해 주진 않으니 두 군데 정도 레퍼런스 체크를 반드시 해 보시길 강력 추천합니다.

    0
  • kenu
    43k
    2018-03-25 15:39:18

    이슈트래커는 무엇을 쓰고 계신가요?

    http://yona.io 추천합니다.

    1
  • 스텁
    839
    2018-03-25 16:14:43 작성 2018-03-25 16:27:36 수정됨

    특별한 솔루션이 아니였다 하시니 그냥 워드프레스같은 기존 솔루션의 커스터마이징이셨던걸까요? 그렇다면 사내개발팀까지 보유할 내용은 아닌게 맞을거 같습니다. 제목은 개발자라서..개발자라면 코딩 테스트도 방법중 한가지라서 말씀드린건데 팀리드나 테크리드는 코딩 테스트 보다는 제대로 된 CTO가 있어야 할거 같습니다. 

    요즘 국내만이 아니라 해외까지해서 선발 과정 표준이 레퍼런스 체크/코딩 테스트/포트폴리오등등이니 다 하시면 제일 좋겠죠

    0
  • 세브라이드
    1k
    2018-03-25 16:28:41

    @스텁

    요새 기술력 좋은 하청업자들 많아요. Node, 파이썬, 리액트 등... 최신 스택으로 무장한 하청업체도 있음...


    개인적으로 좋은 기획자가 있으면 좋은 개발품질이 나온다고 생각해요.

    좋은 기획자는 일정관리부터 품질컨트롤까지 정말 디테일하게 들어가거든요. 그런 기획자 한명 있으면 개발에 대해서 하나도 몰라도 개발 업무가 컨트롤이 되요.(직접개발이든, 하청이든)

    문제는 대한민국 땅에서 좋은 기획자를 찾는게 어렵죠... 실리콘 밸리서도 좋은 기획자가 없어서 이런 유머가 나오는 판국이니...ㅜㅜ

    0
  • 시인들
    1k
    2018-03-25 16:36:14

    알 수가 없음 절때 네버 죽어도!!

    0
  • 스텁
    839
    2018-03-25 17:11:32 작성 2018-03-25 19:18:49 수정됨

    세브라이드 하청업자도 좋은 하청업자 많고 개발자도 좋은 개발자 많은데 다만 나쁜 하청업자도 많고 나쁜 개발자도 많은게 지금 문제이신거 같습니다. 좋은개발자만 있고 좋은 하청업자만 있다면야...ㅎ

    기획자라는 용어는 참 오래전부터 사용되던 용어라서...기획자던 PO던 리드던 아키텍트이던 트렌드를 안 따라가는데도 개인적인 역량으로 모든걸 해결할수 있는 내공이라면 모를까 요즘은 그냥 애자일 및 TDD가 뭔지 아는 관리자(?) 라면 크게 문제는 없지 않을까....요? 라는 생각입니다 ㅎ 링크는 저도 재밌게본 유툽영상이였네요 근데 발음상 실리콘밸리는 아닌거같습니다

    0
  • unthinkall
    1k
    2018-03-25 17:29:07
    저는 가급적이면 비개발 출신 대표님들이 개발팀 꾸린다고 하면 반대하는 입장입니다.
    비개발 출신 대표님들이 실패하시는 모습이 많이 봤고 그 이유는 사실 대표님에게 있다고 봐야됩니다.
    안목이 있다고 해도 아주 어려운데 안목이 없다면 거의 십중 팔구는 제대로된 개발팀을 구성하기가 불가능에 가깝고 더군다나 개발팀 운영조차 제대로 되지 않습니다.
    제대로된 개발인력이 들어와도 운영문제로 퇴사할 가능성도 높거든요.
    일단 굳이 해야한다면 외주형식도 고려해 볼 수는 있지만 사실 그것도 무조건 정답이라고 볼 수는 없습니다.
    세상에 1+1=2같은 공식이 있다면 어려울게 없겠지요
    상황에 따라 대처하는 것이 내공이니까요.
    소프트웨어 장인이라는 책을 추천드리고 싶습니다

    1
  • 스텁
    839
    2018-03-25 17:40:59 작성 2018-03-25 17:47:06 수정됨

    음..지금 이전글을 보고 왔는데요... 그 연차 많으신 개발자분이 연봉 3천으로 입사하신거 같은데..맞나요? 경력 12년이 연봉 3천이면....레퍼런스를 떠나서......그냥 문제가 있는 상황인거 같습니다. 댓글단 몇몇분들이 비난을 했다는 내용이 이건가 보네요. 연봉3천이면 관리자급을 바라시면 안되는거 같습니다. 좀 고급스럽게 말해서 마켓 밸류가 그게 아니라서...ㅎ 예상된 재난이였던거 같네요

    0
  • 즈루시
    11k
    2018-03-25 19:35:26 작성 2018-03-25 19:46:17 수정됨

    경력 12년에 연봉 3천에 오케이한 사람이 특이해요. (아무리 이해하려고 해도 안되는급)

    어디서 뻥튀기 경력 4-5년 뭍히고 들어온 늙다리 대리급 만나신거 아니면... 최소 과장급 일텐데

    쨋든 비싼 수업료 치루셨고 값진 경험하셨네요 대박나시길 바라겠습니다.

    저같은 경우엔 경력직 이직때 3개월 인턴(?)을 제의하더라구요 그럼 그 3개월 프리계약하고 그때 서로 판단하자고 했었습니다. 이 방법도 나쁘지 않을것 같습니다. 당장 정규직보단 프리로 어느정도 실력 파악하고 정규직 전환을 염두하시는것도 좋을것 같아요.

    그리고 경력 12년이 어떤 컨텐츠로서 12년인지도 잘 분석하셔야합니다 지금 하고 있는 사업과 연관성 혹은 기술적으로 도움이 되는 점이 있는지 면접때 최대한 파악하셔야죠. 아예 다른 장르로의 전직급이라면 몰라도 낮은 금액에 컨펌할 이유가 하등 없습니다. 만약 제 친구가 사업하는 친구고 연봉 3천에 12년차 개발자를 구했다고 하면 백프로 의심하라고 하겠습니다. 혹은 말이 안된다 라고 할거구요. 앞에 1이 빠져야 맞다구요.


    ※ 싼맛에 개발자 찾진마세요 시장 가격에 준하지 않는 저렴한 물건이 있을땐 다 뭔가 사정(하자)이 있습니다.


    0
  • zepinos
    18k
    2018-03-25 19:56:54

    몇 가지 시사하는 점, 생각하게 만드는 점 등...알찬 내용이 가득하네요.


    제 소신을 간단히 피력하자면,


    1. 자체 개발팀보다 외주를 믿지 말라. 관공서, 대기업조차 장기적으론 좋은 결과를 보장받지 못한다.

    2. 오픈소스가 소프트웨어 개발사에 미친 영향처럼, 회사 내 오픈소스 문화를 정착시키지 못하면 언젠간 망한다.

    3. 회사만의 규칙이라는 것과 각 개발마다의 자율성 보장이라는 상반된 것 중 어느것 하나는 선택해야 한다. 나는 규칙 쪽이 더 맞다고 생각한다.


    입니다.


    제 경험은 둘째치고, 아주 아이러니하게도 어제 친구들 만나고 왔는데, 모 시설관리하는 공단 직원 놈인데...이 쪽도 외주 개발, 소프트웨어 납품으로 엄청 피를 보고 있는데(우리 세금...) 최근에 공공기관 자체 개발인력으로 구성된 전산팀에서 개발하는 방식으로 바뀐 뒤...제품 품질이 극대화 되었다는 이야기를 들었습니다. 사실 제대로 된 외부 개발업체 찾는 것 자체가 좋은 개발자를 찾아 직원으로 모셔오는 것 이상으로 힘듭니다.


    하지만, 어렵게 직원을 데려오더라도 혹은 외주 개발사를 찾아서 개발을 하더라도 관리가 투명하게 이루어지지 않으면 쉽게 눈속임을 시도하고 책임을 지지 않아도 된다고 생각하는 경향이 있습니다. 외주 업체의 개발 일정을 꼼꼼히 체크할 수 없다면, 결국 모 아니면 도 라고 생각합니다. 내부 개발팀이 있다면 yona 같은 간단한 솔루션부터 Phabricator, GitHub, Jira&BitBucket 와 같은 여러가지 내용을 포함한 솔루션을 도입하는 것을 적극 권합니다. 물론 불편하하겠죠. 하지만, 투명하게 드러나는 코드와 이를 이용한 코드 리뷰와 결과에 대한 간단한 기록 등으로 비전공자 관리자도 뭔가 이루어져 가고 있다는걸 눈으로 보게 할 수 있고, 이러한 것이 상호신뢰로 이어진다고 생각합니다. 개인적으론 모든게 무료인 Phabricator 설치형을 추천합니다. ^^;;;


    마지막으로 회사의 개발방향을 정하는 부분이 될 수 있는데, 예를 들어 외주 업체가 매우 기술력이 좋아(라고 위에서 표현되어 있지만 동의하지 않습니다) Node.js 혹은 Python with Django 로 개발을 했습니다. 이것도 사실 회사에서 개발팀이 개발해도 실험적이라고 할 수 있는데, 외주 개발에서 이런 식으로 개발했는데 어떤 이유로 더 이상 그 회사가 유지보수를 할 수 없게 된다면요? (물론 그 업체가 너무 잘나가서 기존 인력이 더 이상 유지보수를 할만큼 한가하지 않게 되는 것도 포함됩니다) 그래서 개발자 수급이 쉬운 언어 선택 같은 것도 매우 중요합니다. 당연히 내부 개발팀을 운영할 때 가지게 되는 장점 역시 이 부분도 포함되는데요...저는 이 장점이 매우 크다고 생각합니다.


    예전에 여기 게시판에서 제가 SI 하던 시절에는 Class 내의 Method 조자 정렬해서 VCS 에 반영하도록 강제했다고 언급했다가 "완전 꼰데" 취급 받았던 적이 있습니다. 위에서 언급한 두번째 부분과 세번째 부분에 연관된 내용이라고 생각하는데, 바뀐게 거의 없는데 간혹 Method 위치 변경, 띄어쓰기 변경 등으로 인해 전체 코드가 매우 많이 바뀐 것처럼 보이게 되는 현상으로 인해 해당 소스를 올린 사람의 개발량에 대한 착각을 불러 일으키거나 디버깅이 어렵게 되는 일이 벌어졌기 때문입니다. 이게 뭐가 문제냐고 생각이 된다면...솔직히 말씀드리면 개발만 할 줄 안다고 생각할 수 밖에 없구요...소스코드를 관리해야할 리더급만 되어도 이런 경험들 있으실 겁니다. 그런데 외주 개발에 의존해 소스 코드만 납품 받는다면? 괜히 SI 에서 개발 완료 후 일부 인력이 SM 까지 연장되어서 들어가는게 아니죠.




    어쨌든, 많은 고심 끝에 내리신 결정일테고 모든 경우에 하나의 답만이 정답은 아닐 수 있습니다. 저 역시 주변에서 비슷한 사례를 두 어개 현재 진행형으로 겪고 있습니다. 하나는 배우자, 하나는 동서...다 쉽지 않더라구요. 아무쪼록 좋은 결과 있으시길 기원합니다.

    3
  • kinkin1009
    3
    2018-03-25 21:36:39

    3) 사내 서비스든 외부 용역 대행 개발이든 자신의 개발코드, 일정 및 현재 상황 등을 공유하지 않으면 절대 '괜찮겠지'하고 내버려 두지 말고 최대한 빨리 조치를 취할 것 - 제가 대표가 직원을 의심하면 안 된다, 팀은 곧 믿음과 신용이다 생각하고 이걸 안 해서 값비싼 수업료를 냈다고 생각합니다. 


    ㅡㅡㅡㅡ

    이거 200000% 공감합니다

    믿음과 신뢰와 지원을 배푸니 만만하게 보고 이용하는 인간들이 넘 많더군요.

    직원에 대한 생각을 완전 다시 하게 되었습니다.



    1
  • 스텁
    839
    2018-03-25 22:08:03 작성 2018-03-25 22:22:40 수정됨
    소프트웨어디벨롭먼트 베스트 프랙티스로 검색해보면 사람에 대해 그렇게 불신안하며 하는 여러방법론이 많습니다 소프트웨어는 우리만 개발해온게 아니라서요 ㅠ
    0
  • 로보넥스
    2018-03-25 22:11:26

    결과를 보기전엔 알 수가 없습니다.

    2000년 당시에는 알 수가 있었는데

    요즘엔 가짜들이 너무나 완벽한 무장을 하고 있어서

    인터뷰 한두시간으로는 파악불가입니다.


    그러나 첨언한다면,

    진짜 프로그래머는 똑똑해 보이지 않습니다.

    화려한 기술용어를 남발한다면 가짜일 가능성 농후.

    스스로 만드는 것을 좋아해야 진짜가 되지

    남의 것을 배워서 입신한 자는 없습니다.


    얼굴을 보면 지난 성패를 알 수 있드시

    말하는 것을 볼 때, 겸손한 자세로 일관하면

    실력이 없는 겁니다. 항상 이기면서 산 사람들은

    겸손해야 할 이유가 없습니다.


    그러나 이제는 가짜들의 위장술도

    완벽해져서 알 수가 없게 되었습니다.

    코딩테스트가 유일한 해결책인데

    판별자가 아주 진짜여야 합니다.

    가짜는 가짜를 뽑기 때문이죠.

    알고리즘을 보지 않고 몇가지 패턴을 사용했는지를

    볼 겁니다. 패턴만 달달 외우고 있는 가짜가 당첨~

    특히 코드리뷰를 해야함을 주장하면 100프로 가짜.


    0
  • komin
    45
    2018-03-25 22:17:04 작성 2018-03-25 22:25:30 수정됨

    입사 초기 3천으로 시작한 연봉은 1년 즈음 인센티브까지 포함하면 3.7 이상은 갔고 1년 이후 부터 6개월에 한번씩 업글해서 최종적으론 4.5천 정도까지 올랐습니다. 그리고 초기 부족한 현금액은 스톡옵션(사실상 받아 봐야 아는 부분이긴 하겠지만)으로 보완했고 약속 지켰습니다(본인이 먼저 퇴사해서 그렇지).


    개발환경이나 언어에 대한 걸 쓰면 회사를 들킬 것 같아서 생략합니다 ㅠ 1년쯤 지나서 어떤 일이 있었는지 써 볼게요. 지금은 정리된지 몇 주 안 돼서 지인들이나 직원들이 알아볼 것 같네요.


    개발자가 나이 40 넘고도 조직에 남아 있으려면 관리직을 해야 하고 이게 싫어서 급여를 좀 깍이더라도 스타트업에 가서 직접 서비스 해 보고 싶어하는 분들이 많지는 않지만 종종 있기도 합니다. 정말 개발이 너무 좋고 실력도 받쳐주는데 이걸 원해서 하는 사람이라면 레퍼런스 체크해 보면 바로 알 수 있습니다. 꼭 해보세요. 아니면 지인 추천일 경우입니다.


    그렇지만 대표 입장에서 제 솔직한 의견을 얘기하면 (솔루션, 하드웨어 등이 아닌) 서비스를 구현하는 스타트업 개발자는 연차나 스킬이 방대하면 오히려 역효과가 날 수 있습니다. 스타트업 서비스는 피보팅해 보고 린하게 조금씩  그리고 빨리 변경 혹은 추가 하는 서비스가 맞는데 이 정도면 똑똑한 신입들도 불가능하지 않습니다. 연차 높아봐야 코드 짤 시간에 하염없이 설계만 하고 있습니다. 비유가 좀 안 맞긴 한데 호미로 막을 걸 가래로 막아야 하는 상황이 된다고나 할까요? 돌이켜 보면 이건 개발 뿐만이 아니라 다른 직무도 마찬가지인 듯 합니다. 그로쓰해킹이나 퍼포먼스 마케팅 해야 할 직무에 마케팅 전략 짜는 시니어 들어오면 분석도 못해보고 마케팅 망합니다.


    누굴 탓하겠습니까? 다 제 수업료였습니다 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ


    0
  • 로보넥스
    2018-03-25 22:26:34

    3천을 4.5천으로 만들어 주면서도 실력을 몰라봤다면

    그건 회사가 문제네요. 실력자를 받아들일 수 있는 시스템이

    아닐 겁니다..

    혹은 모함이 아닐까요?

    가짜들의 반란..

    0
  • komin
    45
    2018-03-25 22:38:26 작성 2018-03-25 22:39:26 수정됨

    결론만 말씀드리면

    1) 기존 연봉 보다 깍고 들어온 걸 감안해서 최대한 맞춰주려고 매년 노력한 회사측의 성의였고

    2) 개발팀 KPI 측정 할 수 있는 사람이 본인 혼자 뿐이었으니 이후 팀원들이 추가 되긴 했지만 책임자급은 본인 이니 뭐든 숨기기 쉬웠을 거라 추정됨(무튼 역설적으로 팀원들이 충원되었으므로 들통난 거고).

    3) 기존회사들 SI 하면서 받는 압박과(누가 갈궈야 밤새서라도 해내는 수동적인 사람들이 사실 인간사회에는 대부분인 듯)  스스로 회사내 자체 개발을 하면서 받는 압박 자체가 다른 것 같고 결국엔 나이들면 경력이란 반비례하는 체력에 대비하여 코딩력+자기관리+팀관리까지 갖추어져야 함.


    그리고 제 주관적인 의견인데,

    요즘 오픈소스가 워낙 잘 되어 있고 개발환경이나 언어 트렌드가 많이 변해서 좀만 똘똘하므는 웹/앱은 주니어들이 훨씬 잘함. 시니어가 필요한 건 문서나 관리 때문인 거 같음.

    0
  • komin
    45
    2018-03-25 22:45:50

    그리고 그간 있었던 일과 주의점 등은 여기다 안 쓰고 개인 블로그에 쓰는 게 나을 듯 합니다. 제가 얻은 팁은 개발자들 보단 창업자들에게 필요한 것 같네요. 


    오키님들 좋은 밤 되세요.

    0
  • 로보넥스
    2018-03-25 22:56:16

    고민님>


    00년부터 일하면서 사장님들 학습효과에 대하여

    정말 지긋지긋 봤습니다.

    고민님은 아직 10%도 못오셨어요.

    죽일놈이 영웅으로 보였다가 죽일놈이 되었다가를

    반복하실 겁니다 앞으로..

    1
  • 협군
    5k
    2018-03-26 01:14:27

    결론만 말씀드리자면 6~7천 줘야 하는 사람을 찾는데 3천에 누군가 해준다 하니 덥석 물었고 사기를 당했다는 말이네요? 

    별로 우습지도 않네요. 스타트업 기준 3천이면 신입 개발자 연봉입니다. 네임밸류 없는 스타트업은 제대로된 신입도 3천은 줘야 오는데 말이죠.

    그리고 2년이상 한 회사와 재직안해본 사람으로서 당해보고도 위와같이 판단하신거 보면 내부 개발자 없이 외주 진행하면 어떤 사태가 발생하는지 모르는 것 같네요.



    2
  • zepinos
    18k
    2018-03-26 02:10:27 작성 2018-03-26 02:13:34 수정됨

    첫 본문이나 제가 댓글 달기 전까지는 저도 좀 호의적인 눈으로 바라봤습니다만, 그 이후 달린 댓글들을 보니 약간은 비우호적인 쪽으로 생각이 기우네요.


    저 역시도 회사생활한지 20년 가까이 되어 가고, 대부분의 경력을 개발자로서 일해 왔으며 관리 업무가 극히 적어도 괜찮은 회사(게임서버 개발 쪽을 선호했던 이유)나 보조해줄 사람이 있는 회사(게임클라 팀장이 서버팀까지 같이 맡아준 경우)에서 최근까지 일하다가 현재는 (집에서 가까운게 최고지만) 역시나 개발만 열심히 할 수 있는 환경을 찾아 현 직장에 입사해서 일하고 있습니다.

    그런데, 지금 회사에 입사하면서도 연봉을 많이 깎았다고 생각하진 않습니다. 예전부터 경력관리 등의 실수로 기대하는 급여 수준을 받고 있다고 생각하진 않았지만, 지금 회사가 집과 가까운 편(전동킥보드 타고 15분이면 사무실 도착도 가능)이고 공무원 소리 들을 정도로 안정적인 회사(전 직장 급여체불, 체당금, 파산 콤보)여서 생각했던 금액보다 많이 낮추긴 했지만...우리 회사 공채신입 수준의 급여를 받고 다니라면...사실상 불가능하죠. 저의 경우 딸린 식구도 많은 것도 한 몫 하지만요. 그래도 어쨌든 급여에 대해서 연차 대비 현실화 시켜주려고 하셨던 부분은 높게 사야 하는게 당연하지만, 상식 밖의 급여 수준도 가능하다고 굽히고 들어온 사람의 결과물조차 제대로 확인하지 못하고 급여가 올라갔다는 부분, 그리고 그 사이 동료 개발자들이 늘어났다는 점을 봐선, 회사 규모도 그리 작다고 할 수 없을텐데 하위 직원들의 상위자 평가 등을 통해서라도 해당 직원에 대한 평가를 간접적으로 내릴 수 있었을텐데, 결국 하시는 말씀을 보면 회사 내 소통이 거의 이루어지지 않고 있는게 아닌가 의심이 됩니다.


    더 안타까운건, "똑똑한 신입들도 불가능하지 않습니다. 연차 높아봐야 코드 짤 시간에 하염없이 설계만 하고 있습니다." 라고 하신 부분입니다. 지금 제가 다니고 있는 회사에도 많은 개발자가 있고, 과거에도 많은 개발자들이 거쳐갔습니다. 이 중에는 학벌도 매우 좋은 사원들도 많았고, 병역특례를 통해 공채나 수시채용으로 채용할 때보다 훨씬 더 높은 스펙의 개발일을 하는 "똑똑한 신입" 급이 많았다고 들었습니다. 그들이 만든 코드로 지금도 1억명이 넘는 전세계 사용자에게 서비스를 제공하고 있는데, 문제는 제가 담당하고 있는 코드에 앞서 언급한 인력이 제일 많이 거쳐간 코드이고, 회사 내에서도 가장 "기술부채" 가 많이 쌓여있는 코드라고 알려져 있습니다. 저 역시 아직까지 현역 개발자(SW Developer)라고 생각하고 있고, 이번 연봉협상 기간에도 현재 맡고 있는 자그마한 직책도 내려놓고 순수 개발만 하고 싶다고 회사에 강력하게 요구한 상태이긴 하지만, 개발 속도가 정말 똑똑한 신입보다 더 많이 받는 금액만큼 비례해서 빠르냐고 한다면...그건 아니라고 생각합니다. 하지만, 정말 빠르지 않을까요? 저는 제 동료직원들(다 저보다 어립니다)에게 제 경력은 하나의 분야를 그 기간동안 깊게 파고들어간 것이 아니라 1년씩 나눠서 그 연차만큼 다른 각도로 파고들어본 것이라고 이야기합니다. 그건 다른 시니어 개발자들도 마찬가지라고요. 하나의 제품(현 회사에선 제품이라는 표현을 하는 소스들이 수십개 존재합니다)을 개발할 때 어떤 방법이 효율적인지 더 빨리 알아채고, 경험을 해봤거나 유사경험으로 성공 가능성이 더 높은 방향을 알고, 결과를 내기 위한 최적의 조건을 알아내는데 이러한 경력이 가장 중요하다고 피력하고 있습니다. 안타깝게도 현 회사 역시 작년에 신입공채를 통해 괜찮은 젊은 개발자들을 받아들였지만, 제 입장에서 볼 때에는 똘똘할 뿐이지 아직은 일을 "책임지고" 맡길 수 없습니다. "기술부채" 가 어마어마하게 쌓일 것이 눈에 보이거든요. 이 기술부채를 그럼 어떻게 미리 알 수 있고, 어떻게 미리 피해갈 수 있을까요? 이런 간단한 것조차 모르시기에 감히 제가 테클을 거는 겁니다. 모르시니 "똑똑한 신입들도 불가능하지 않습니다. 연차 높아봐야 코드 짤 시간에 하염없이 설계만 하고 있습니다." 라고 발언하신다구요. 아쉽지만, 제대로 된 시니어 개발자가 "하염없지 않게" 일을 하는걸 못보신 것이 그릇된 판단을 하게된 원인이라고 생각이 되네요. 물론 제 생각도 정답이 아니고 그릇된 생각일 수도 있지만요...


    마지막으로, 아직도 C++ 창시자인 비야네 옹을 위시하여 많은 개발자들이 현역 개발자이고 한국에서도 제가 처음 일할 때 30대 초반되면 관리자 되어야 한다...라고 말했던 것이 현재에는 계속 그 시기가 늦어지고 있습니다(제가 거기 선봉장입니다. 현재 만 40 입니다만, 비관리자입니다). 저 역시 한 해 한 해 체력이 떨어져가고 있겠지만, 개발은 아쉽게도 체력으로 하는게 아닙니다. 맨날 야근하고 밤샐 겁니까? 하루 8시간 근무 시간동안 쉼 없이 개발만 하고 있을꺼라 생각합니까? 아쉽게도, 그런 개발자 중에 잘 하는 개발자를 본 적도 없고, 저보고 채용 의사가 있냐고 물으면...저는 절대 뽑지 않습니다. 심지어 하루에 한 시간만 코딩에 집중해도 성공이라고 말하는 제 신념 상, 야근을 계속하면 관리자(회사 경영자 포함) 잘못이라고 생각하지 개발자가 노력한다고 생각하지 않습니다. 말씀하시는 내용 중 일부는 전혀 개발팀이라는 조직과 개발자라는 사람들의 기본적인 생리를 모르시는게 아닌가 싶네요. 물론 흔히 말하는 찍어내는 개발자라면 이야기가 다르겠습니다만...


    아모쪼록 원하시는 개발 결과물을 받고 사업 번창하시길 빕니다. 하지만...내부 개발팀이 꼭 필요해질 때에는 좀 다른 시각으로 개발자들을 바라보고 생각하셨으면 좋겠습니다.


    2
  • ggugers
    516
    2018-03-26 08:02:57

    3천 ㅠㅠ 

    신입사원 뽑으셔서 개발팀 맞긴 결과네요

    0
  • 더미
    12k
    2018-03-26 09:54:35

    중요한건 

    비현실적인 금액에는

    비현실적인 사람만 옵니다.

    스톡옵션이요? 그런건 의미없습니다.


    그리고 똑똑한 신입도 세상에 많긴한데

    우리 회사엔 안 옵니다. 절대 네버.

    그건 회사에 대한 지나친 만용이죠.


    0
  • 7i
    1k
    2018-03-26 10:14:15

    요즘 스타트업은 12년짜리 경력자 한명으로 회사의 사활을 걸만큼 대단한 중책을 맡기히는건가요
    백업도 없고 대책도 없이 대표님이 좀 무책임한거 아닌가 싶습니다.

    12년차 경력자가 디비를 엉망으로 만들수밖에 없을만큼 사양변경이 있었는지, 스케줄이 빡빡했는지
    당사자의 이야기도 들어봐야 할 문제인거 같습니다.


    저는 영세한 스타트업 대표님들에게 부탁드리고 싶습니다.
    대표님은 투자를 많이 받아서 사원들이 좀더 편안하고 좋은 코드가 나올수 있는 윤택한 환경에서
    개발을 할수 있도록 해주시는겁니다.

    개발자 한 두명에게 모든 책임을 전가하시는거로 밖에 안보입니다.

    0
  • byeworld
    2k
    2018-03-26 15:49:12 작성 2018-03-26 15:51:14 수정됨

    어제 자려는데 이 글 보고 잠이 오지 않더군요.. 

    본문에서는 위험할 수 있는 결론을 내리시더니

    댓글에서는 내려서는 안되는 결론에 이르셨습니다.

    (길게 댓글을 작성하는 중에 협군님과 제피노스님이 댓글이 달렸더군요. )


    지금 내리신 결론과 마인드로 직원들과 일하시면 얼마 안가서 업체 생존을 고민해야 합니다.

    그런 생각과 마인드를 알게된다면 현재 있는 사람중에 남는 사람이 없게 될 수 있습니다.

    결속력이 좋아졌다구요? 착각하지 마십시오.

    회사 대표가 화가 나있고 기분을 풀어야하니 그런 것일 수 있습니다.

    지금은 회사 내의 급박한 상황이니 대표에게 고개를 숙이는 것 뿐일 수 있습니다. 


    제 댓글은 저녁에 올려드리겠습니다.  


    추. '똘똘'?

    회사 망하고 싶으면 그런 단어 쓰십시오. 유사한 것으로 '빠릿빠릿'이 있습니다. 

    2
  • zepinos
    18k
    2018-03-27 19:12:44

    byeworld 님의 댓글이 기대됐는데, 아직 올리시지 않았네요. 잊어버리신 듯 합니다. ^^;;;


    0
  • 스텁
    839
    2018-03-27 20:46:54 작성 2018-03-27 20:51:39 수정됨

    개발자에 대한 불신은 이렇게 쌓여가는군요. 그 단계를 설명들은것 같습니다.

    개발이란 몸값싼 신입 데려가다 갈구면 되고 개발자가 한달걸릴거 같다고 말하면 그거 그냥 복붙하면 되는거 아니야? 라고 갈구면 항상 결과물은 나오던데? 라고 생각하는 현업/매니저/사장님들의 탄생과정 같기도 합니다.

    하지만 그 단계를 듣고보니 사장님이 처한 상황 및 지식 단계에서는 아마 이것이 최선의 결과였던것 같습니다.

    한국을 모르는 외국인이 한국이 좋다는 말만 듣고 관광 왔다가 바가지 택시를 타고선 와..한국은 참 나쁜곳이군 생각해도 할말은 없을것 같습니다. 그 외국인은 영원히 한국은 못된 나라라고 생각하고 자기나라에 돌아가서 동네방네 한국의 안좋은 점을 말하고 다니겠죠. 안타깝습니다. 한국의 아름다움을 알려주지 못한것 같아서요.

    개발자들은 평생 공부하는데 그들을 관리하는 관리자도 공부 필요합니다. IT 스타트업이면 개발자 관리뿐만 이 산업을 알기 위해서도 개발 공부가 아니라 IT전반에 대해서도 필요하구요.

    비난만 받고 가는것 같다라고 억울하게 생각하실거 같아 댓글 아끼려다 다른 관점에서 생각도 하셨으면 해서 저도 다음 이야기 궁금해서 들렸다가 마지막 적습니다.

    2
  • daaaa1
    12
    2018-03-28 00:53:32

    코드를 보는 눈을 키우시면되요. 개발자 비개발자가 중요한게 아니라 내가하는 사업이면 내가 코드를 볼 줄 알아야지. 배울생각 하시는게 힘들죠물론.,. IT기업 사장이 IT를 모르고 아이디어만 갖고있다..이젠 그런 얄팍한거 안먹히고, 망한회사 특징은 사장이 코드볼줄 모르는회사가 산더미처럼 많죠.. 직접 다 만들라는 말이 아닙니다. 당구로치면 배워서 길은알아야지 브롬달이 잘치는지 못치는지 알죠,, 말만 많으면 말만하다 끝납니다.

    0
  • bluewas88
    181
    2018-03-28 11:11:01

    우선 년봉3천에 12년차 개발자를 뽑고서 개발,리딩,관리를 원하셨던게 제일 큰 문제 같습니다.


    위에분들이 언급했지만 터무니없는 금액에 오는 개발자는 우선 의심을 했었어야 한다고 봅니다.


    그리고 년차높은 개발자보다 똘똘한 초급개발자가 낫다고 판단하셨는데 일례로 이런일이 있었습니다.


    서비스의 속도문제가 발생하여 십수명의 개발자가 몇개월간 찾아보았으나 해결하지 못하여(해당업체는 제니퍼도 사용하고 있었음)


    장비문제로 판단하여 몇억을 투자하기로하였는데 1명의 개발자가 하루정도 시간을 투자하여 해당문제를 해결하였습니다.


    그 십수명의 개발자보다 문제를 해결한 개발자가 코딩실력이 뛰어나서일까요?


    단순히 코딩능력보다 년차높은 개발자들의 경험과 문제해결능력을 보는 안목도 키우셔야겠네요.


    0
  • 저기봐라
    764
    2018-03-28 12:51:25

    개발하고 유지보수 하는사람 신경안쓰고 나몰라라 할거면 막만들어도 상관 없지만

    10년 이상 회사내 코어 소스로 활용하시려면


    새로 들어오는 개발자의 소스 적응을 위한 가독성,

    필요 기능 확장 쉽게 하기 위한 확장성 등 

    초기설계가 많이 중요합니다

    0
  • 스타
    3k
    2018-03-28 23:16:03 작성 2018-03-28 23:38:00 수정됨

    멀쩡한 그정도 경력의  개발자가 3000만원짜리에 갈 이유도 없고 더군다나 거기다 스타트업에 갈 이유도 없을 듯 합니다.

    무궁한 발전이 있으시길...

    0
  • 김모씨
    2k
    2018-03-29 02:22:47

    쓰인거 보면 팀장급 인력을 구하신거 같은데요. 최소 차장. 부장급인거 같습니다. 

    저도 이제 과장급인데 정규직 제시하는데서 4200 부터 시작합니다. . 

    근데 팀장급인력이 그정도 가격이라.. 

    정말 전망이 있었던 스타트업이 아니라면.  가격 =  성능이라고 봅니다. 

    괜히 분석설계 담당, 개발담당이 따로 있는게 아니겠죠. 

    머 년차에 맞게 일을 못할수 도 있지만. 그건 본문처럼 일정관리 산출물 관리의 문제라고 보고요. 

    분석 설계 리딩이 가능한 AA  가 얼마짜리일까요. 

    싼게 비지떡입니다. 

    0
  • byeworld
    2k
    2018-03-29 13:51:57 작성 2018-03-29 15:51:59 수정됨

    저런.... 

    안타까운 생각이 드는군요..

    자려다가 이 글을 보고나서 잠이 오질 않아 글을 남깁니다. 

    좋은 개발자도 많지만, 그렇지 않은 개발자도 많은 것은 사실입니다. 

    그 개발자가 잘못한 것도 있겠으나, 

    본인이 잘못한 부분에 대해 제대로 인지하고 있는지, 

    그리고 상당히 위험한 생각과 결론을 내리고 있지 않은가 싶은 부분도 있습니다. 

    기분도 많이 상했을테고, 안좋은 생각들도 많을것으로 생각됩니다. 

    하지만, 

    내리신 요약 결론보다 그 주변에 쓰여진 글이나 답글들에 위험하거나 

    잘못된 생각들이 보여서 안타깝군요.. 

    어떤 판단에 기초해 또다른 판단을 하는 

    '이렇게 했다면, 이렇게 해야지..'식의 생각은

    왠지 자기 원하는 걸로만 채워질 것 같아 도움이 되지 않을 것 같은 생각이 듭니다. 

    본인이 한 것, 그 분이 한 것, 본인이 했어야 했던것으로 나눠서 보는 것이 더 낫지 않은가 싶습니다. 


    ===========

    1) 경력(년수)과 개발 실력은 비례하지 않는다.

    2) 경력이 12년 이상인데  2년 이상 다닌 회사가 없는 개발자는 의심해 볼 것 - 레퍼런스 체크 필수.

    3) 사내 서비스든 외부 용역 대행 개발이든 자신의 개발코드, 일정 및 현재 상황 등을 공유하지 않으면 

    절대 '괜찮겠지'하고 내버려 두지 말고 최대한 빨리 조치를 취할 것 - 제가 대표가 직원을 의심하면 안 된다, 

    팀은 곧 믿음과 신용이다 생각하고 이걸 안 해서 값비싼 수업료를 냈다고 생각합니다. 

    ===========


    내리신 요약 결론.. 

    1)번은 맞다생각하고, 제 의견을 남깁니다. 


    2)번 경력 레퍼런스.. 

    2년 이상 다닌 회사가 없다고 의심할 필요는 없습니다.

    하지만, 이력서 받고 경력 증빙 받으셨나요? 

    이력서 어느정도, 어느 수준까지 확인하셨는지요?

    그리고 이력서에 근무한 회사가 어떤 회사인지도 확인하셨나요?

    수행한 업무나 프로젝트에 대해서는 어느 정도까지 확인하셨나요?

    이런 것들은 본인의 몫이겠지요. 

    중간에 보니 '린'을 언급하시던데, 

    얼마나 자주 회의를 하고, 테스트를 하셨나요? 

    (1년이상 몰랐다는 것은 린이건 애자일이건 XP건 무엇으로도 변명이 안될겁니다.)

    그 과정에서 확인하지 못한 것도 잘못이 아닌가 싶습니다. 



    3) 개발코드, 일정 및 현재 상황 등을 공유 

    저는 이 부분이 개발자의 능력이고 개발팀의 능력이라고 보는지라...

    개발자가 아니라 소스코드를 몰라서 그냥 맡겨놨다고 하시는데, 

    소스 코드가 아니더라도 진행 상황이나 상태의 공유, 파악이 없었다는 부분에서 안타까운 생각이 듭니다. 

    올리신 내용에서 채용했던 분이 관리자까지 했던 사람이라고 하시는데 

    진행 상황이나 상태의 공유가 안됐다는 건 심각하게 볼 필요가 있는 부분입니다. 

    결과물에 대한 테스트 등은 하셨어야하는데 싶습니다. 

    테스트를 하고 체크목록을 만들어서 관리하는 여러 기법들이 있는데 안타까운 생각이 듭니다.

    소스를 모르시더라도 진행 상황이나 상태를 알 수 있는 것들은 많이 있습니다. 

    스타트업이니 산출물을 중요하게 여기지 않았을 것으로 생각되는데, 

    개인이 아닌 팀 프로젝트일수록 중요하게 됩니다. 


    본인이 할 수 있었거나 했어야 하는 부분들을 놓친 것은 없는지, 

    그렇다면 앞으로는 더 정교한 확인을 통해 나은 사람을 구하고 

    더 나은 관리를 할 수 있는 것이 아닐까 싶습니다. 

    내리신 요약 결론 부분은 위와 같은 생각이 듭니다. 


    다음은 그 외에 드는 생각들입니다. 

    지난 글이 있던데 혹시 그 분인가요? 월 200을 부른다? 

    그 시점에 의심해야 사안입니다. 

    벤처 붐 시기에 4000받던 사람이 3000받고 가는 거야 볼 수 있었지만, 

    요즘에 절반도 안되는 금액에 스타트업을 간다? 절대 일어날 수 없습니다.

    소득대체가 안되는데 감당할 수 있는 수준이 아닙니다. 

    (사람의 생활과 소비 패턴이라는 것이 있는데 소득은 급격하게 줄어 들 수 있지만, 

    소비는 급격하게 줄어들 수 없습니다. ) 

    최종적으로는 4000넘게 주셨던데, 맨 처음부터 4000으로 구했으면하는 생각이 드는군요.. 


    15년이 넘는 경력에 스타트업을 선택하는데 그 정도 금액으로 깎고 들어가는 사람은 없습니다. 

    과거 벤처붐으로 하이리스크 하이리턴으로 도전을 선택했던 시절도 있었지만, 

    주인정신이나 도전정신을 외치며 벤처행을 선택했던 사람들이 겪은 것은 

    리스크를 극복해도 그만큼의 하이리턴은 없더라는 것이었죠.. 

    '머슴은 주인의 몫을 받을 수 없다.'와 같은 경험들이 적잖게 퍼졌고, 

    과거 벤처창업을 하고 개발자들을 대했던 분들의 행위(?)로  

    직원들에게 보상이 제대로 이뤄지지 않는다는 것과 스타트업을 선택하면 

    얼마나 위험할 수 있는가룰 많은 사람들이 경험했고 다른 사람들에게 전해졌습니다. 

    결국 벤처를 선택했던 동기들이나 직장 동료들은 몇몇 기업을 거쳐 

    보상이 이뤄졌던 소수 회사들을 향하더군요.. 


    위험한 생각이라고 드는 부분들은 요약결론부분이 아닌 다른 부분들입니다. 

    [사내 개발팀을 없애고 외주을 한다.]는 것은 위험한 생각이 듭니다. 

    보니까 지난 글에서 외주에서 받았다가 품질이 안좋았다는 말씀을 하시는데, 

    또 그렇게 될 겁니다.


    차를 가지고 설명할까요? 

    아마 외주업체는 다 된다고 말할겁니다. 스포츠카 슈퍼카도 만들 수 있다고 할껍니다. 

    하지만, 겉에만 스포츠카처럼 만들고 속은 경차일껍니다. 

    아니 스쿠터나 바이크 엔진 들어있을 수도 있습니다. 

    그런데 그 속을 어떻게 알죠? 

    '이거 쌩~하고 안나가요.' 하면 '꾹 밟으면 됩니다.'할껍니다. 

    '에어백이 안터져요.'하면 '각도를 맞추면 터집니다.'할껍니다. 


    그나마 나은 업체는 기능만 작동하면 되게 만듭니다. 

    이미 겪으신거 같은데, 아웃소싱 외주사들은 '되기만 하면 되는..'에 맞춰져 있습니다. 

    '[잘] 작동하는', '[더] 잘 작동하는'에는 맞춰져 있지 않습니다. 


    그런 좋은 성능의 프로그램을 만들수 있는 능력 있는 업체가 

    자기 능력으로 다른 업체가 돈벌게 해 줄 이유가 뭔가요? 

    같은 서비스라면 자기네가 영업뛰어서 자기이익을 극대화 하지 

    자기 이익 줄이고 남이 돈벌게 할 이유가 없죠. 비즈니스지 봉사활동이 아닙니다. 


    위에 다른 분이 쓰셨듯, '품질관리'가 되려면 제품개발하고 관리 하는 팀을 가지고 있어야 합니다.


    ----

    1) 기존 연봉 보다 깍고 들어온 걸 감안해서 최대한 맞춰주려고 매년 노력한 회사측의 성의였고

    2) 개발팀 KPI 측정 할 수 있는 사람이 본인 혼자 뿐이었으니 이후 팀원들이 추가 되긴 했지만 책임자급은 본인 이니 뭐든 숨기기 쉬웠을 거라 추정됨(무튼 역설적으로 팀원들이 충원되었으므로 들통난 거고).

    3) 기존회사들 SI 하면서 받는 압박과(누가 갈궈야 밤새서라도 해내는 수동적인 사람들이 사실 인간사회에는 대부분인 듯)  스스로 회사내 자체 개발을 하면서 받는 압박 자체가 다른 것 같고 결국엔 나이들면 경력이란 반비례하는 체력에 대비하여 코딩력+자기관리+팀관리까지 갖추어져야 함.

    ----

    댓글에 결론부분중에서... 

    1)은 그 분의 결과물에 대한 평가가 아니라 아니군요.. 

    처음부터 4000으로 사람을 구했으면... 

    2)는 내용에 따라서는 본인의 책임을 남에게 미루는 것이 될 수 있습니다.

    3)에서 [압박]과 관련해서 

    자유롭게 놔줘야하는 사람과 아닌 사람이 있습니다. 

    관리자의 능력은 1.그걸 구분해서 대응하는 능력 2.관리가 불가능한 사람은 미리 걸러내는 능력 아닌가 싶고, 

    적지않은 SI, 아웃소싱업체들은 압박만 강조해서 '돌아가기만 하는'프로그램 양산구조로 흘러가고 있습니다. 성능이나 품질은 무시되기 쉽습니다. 

    그리고 [경력]관련해서 

    경력이 늘수록 코딩력이 낮아지지는 않습니다. 

    경력이 쌓인다고 개발 생산성이 월등해지는 것은 아니지만 일정 한도까지는 나아집니다. 

    체력이 중요한 것은 SI업계처럼 연장근로 중노동에 의한 생산환경에서 벌어지는 것이지

    체력이 떨어진다고 개발능력이 낮아지지는 않고, 경험에 의한 더 효율적으로 개발을 할 수 있게되어 

    떨어지는 체력으로도 생산성이 일정수준 이상 유지하게 됩니다. 

    경력이 중요한 것은 분석과 설계능력입니다. 

    그 중에 분석이나 파악 등에서 경력이 크게 작용한다고 생각합니다. 

    설계는 그 사람이 가진 지식의 영향도 크므로 경력에 비해 뛰어난 사람도 많습니다. 

    개념상으로 훌륭하고 좋아도 실제 적용에서는 문제점이 있을수 있는데 이렇때 경험은 크게 작용합니다. 


    경력자, 고급 개발자의 가치는 그 사람의 생산성보다 

    다른 사람의 생산성을 높이는데 가장 큰 가치가 있다는 것이 개인적 생각입니다. 

    쉽게 보이지 않는 능력이고, 앞의 분석, 설계 능력도 포함되는 거 같습니다.

    이런 분들이 진짜 가치있는 분들이지만, 쉽게 자기 지식 떠벌리거나 하진 않습니다. 

    오히려 묵묵히 결과를 만들어내며, 다른 사람 돕는데 인색하지도 보상을 바라지도 않습니다. 

    그냥 생산성만 보면 고급 한 명보다 초급 두세명 쓰면 나을거 같은 생각을 하는 사람들 있던데, 

    초급은 두세명 그 이상을 써도 이런 능력은 따라오지 못합니다. 


    ------------

    오픈소스가 워낙 잘 되어 있고 개발환경이나 언어 트렌드가 많이 변해서 좀만 똘똘하므는 웹/앱은 주니어들이 훨씬 잘함. 시니어가 필요한 건 문서나 관리 때문인 거 같음.

    ------------

    해서는 안되는 생각이라고 드는 부분입니다. 


    기본적으로 라이센스에 대한 개념이구요.

    [잘 되어 있는 오픈소스]는 그냥 잘하는 정도의 개발자가 만든 프로그램이 아닙니다. 

    그것을 이해하는 것만으로도 초급단계는 쉽게 넘어설 수 있습니다.

    똘똘? 보도방들이 그런 사람 많이 찾죠. '똘똘', '빠릿빠릿' 

    그런 추상적 용어를 사용해서 평가를 하시면 안됩니다. 

    그렇게 보이는 것은 포장능력입니다. 빛이 난다고 모두 보석은 아닌 것입니다. 

    또한 주변의 빛나는 것으로 인해 빛이 나는 것일 수도 있는 것입니다.

    심지어 자기 빛나보이려 다른 사람 가리는 사람도 있습니다. 

    구체적으로 무엇을 할 수 있고, 무엇을 해봤는지 조건과 체크리스트를 정교하게 하십시오. 

    주니어는 주니어일 뿐입니다. 

    그 중에 호랑이 새끼, 미운오리(=백조)가 있을 수 있지만, 아직 성장하기 전입니다.. 


    요약하면

    1. '이래야 되는 거 아니야' 식의 결론에 기대어 판단을 하지 마십시오.('회사에서 성의를 보여야 하는거 아니야?' 등..)

    - 몇 몇 이중잣대도 보입니다.  

    2. 품질, 성능 등을 기대하시려면 개발팀을 가지고 있어야 합니다. 

    3. 코딩을 몰라도 알수 있는 방법, 관리기법 들은 있습니다.

    어떤 말로도 1년이 넘도록 몰랐다는 것은 너무 큰 잘못입니다.

    4. 고급 개발자의 능력이나 경험의 가치는 프로그램을 많이 만들어내는 능력(찍어낸다라고..)이 아니라 

    분석, 설계능력과 다른 사람들의 능력 향상에 그 가치가 있습니다. (미리 알기가 어려워서 그렇지.. )

    5. 오픈소스의 가치를 함부로 평가하지 마십시오. 

    [잘 만들어진 오픈소스]는 월등하거나 뛰어나신 분들의 노력의 결과물입니다. 그것을 이해하고 활용하는 것은 결코 쉬운 수준의 것이 아닙니다. 

    6. '똘똘' 같은 단어 쓰지 않는게 좋습니다. 포장에 현혹됩니다. (빛난다고 모두 보석은 아닙니다.)


    너무 긴 거 같아 이만 줄입니다. 


    추. 쓰면서 생각이 많아지다보니 늦었습니다. 죄송합니다. 

    추2. 사람을 구하시건, 외주를 하시건 그 조건을 좀 더 정교하게 하시는 것이 좋다 생각듭니다. 

    추3. @zepinos 실망입니다. 저따위 무명 듣보잡 개발자에게 기대를 하시다니요..

    1
  • extreme
    721
    2018-03-29 14:31:11

    사람을 잘못 뽑으면 힘들다, 개발자 실력을 내가 검증하기 어렵다는 점까지는 충분히 동의됩니다. 그리고 화나서 쓰신 것도 감안하며 읽었고요. 근데,

    "스타트업 서비스는 피보팅해 보고 린하게 조금씩  그리고 빨리 변경 혹은 추가 하는 서비스가 맞는데 이 정도면 똑똑한 신입들도 불가능하지 않습니다."

    이 말이 얼마나 자신이 한 얘기들에 모순적인지 알고 쓰신건가요? 굉장히 화나는 글이네요.

    점진적인 개발을 했다면, 일이 이 지경이 되도록 모를리가 없는데 대체 얼마나 오래동안 방치해뒀길래 일이 그 지경이 되고서야 알았는지 묻고 싶네요. 린하다는건 내 맘대로 아무때나 뭐 바꿀 때나 쓰는 용어가 아니에요.


    0
  • yeori
    541
    2018-03-29 16:23:18


    필요할 때마다 프리랜서나 개발팀으로 움직이는 업체와 용역 계약을 체결해서 최소한의 결과물은 보장받아야 겠다는 생각이 들었습니다


    회사의 비즈니스 모델이 IT와 무관하다면 그때그때 외주를 줘도 상관없지만 IT기술과 인력이 핵심인 회사라면 똑같은 문제를 또 겪으실 겁니다. 더 자주 겪을듯 하네요.

    문제가 발생했을때 법적 책임을 물을 대상이 필요해서 외주를 주는 식이라면 사업하기 많이 힘들지 않나 싶고, 용역쪽이 개인이라 돈 없다고 배째라고 나오면 뭐...

    1
  • 이또한지나가리라23
    3
    2018-03-30 19:05:07

    죄송한 말씀이지만 본인의 무능력을 다른 사람에게 전가하는 것처럼 보입니다.

    1
  • 초무쿤
    2k
    2018-03-30 20:47:24 작성 2018-03-31 04:20:07 수정됨

    내용을 더적으면 위에 zepinos님이 적으신 내용고가 중복안거 같아서 내용은 생략합니다.

    결국은 국가의 방위를 용병을 썼는데 나라가 망할뻔했다. 근데 용병이 엄청 자렴한 용병이고. 

    그래서 다음부터는 용병집단에게 의뢰를 해야겠다 뭐 이런 말씀이신데..

    좀 냉정한 이야기지만

     위에 글 이해 않되시는거면 사업하시는거 돈지랄하지 않는 이상은 상당히 힘들거로 봐집니다.

    그리고 사업내용을 잠깐 보니 스타트업은 아니고 그냥 외주개발사인득 보입니다만. 외주 받아서 또 외주를 주시면 ㅋㅋ

    슬픈 이야기지만 15년전 벤처시절이랑 지금스타트업? 이랑 명칭만 바꼈지 별루 달라진게 없어서 안타깝네요


    0
  • sinho0689
    117
    2018-07-25 05:36:03 작성 2018-07-25 05:48:25 수정됨

    하시는 분야가 찍어내는 분야인지, 자체 솔루션 개발인지(뭐 서비스에서 매출 나오기 전까지는 SI는 당연하겠지만;;) 아니면 비중이 어떻게 되는지는 잘 모르겠습니다만..

    일단 저도 비슷한 고민을 하고 있는 사람으로써 의견 공유하겠습니다

    일단 저는 개발자출신 사장(4년차입니다)이라는걸 알고 읽어주시면...


    1) 경력(년수)과 개발 실력은 비례하지 않는다.

    => 맞긴 한 것 같습니다. 1년차 친구도 프레임워크 잘 다루는 친구가 있고, 학교 과제만 하다가 온 친구가 있습니다. 여기서 중요한건

    처음에 면접을 볼때, 개발 분야에 재미가 있는지가 1순위, 본인이 이 업계에 대해서 어떻게 생각하는지.. 약간 철학적으로 일단 물어봅니다. 왜냐면, 이 생각을 했다는거 자체가 본인이 연구한게 있으니까 나오는거라고 생각하거든요

    그리고 본인이 프로젝트를 빨리 끝내고 좋게 만들기 위한 노력들을 해봤는가

    실제 프로젝트에서(학교던 개인이던 팀프로젝트건) 어떤 기술과 생각을 가지고 개발을 해서 문제가 뭐였고 해결은 어떻게 했는가. 그리고 도출된 결과물은 무엇인가??

    마지막으로 본인 장단점, 스트레스 푸는 방법(이거 엄청 중요합니다. 모범답안은 운동합니다;; 술먹는다고 하면 대부분 자격미달이더라구요). 기타 또 면접을 붙던 아니던 밥먹이던지 면접보면서 피자라도 먹으면서 계속 물어봅니다;; 한명한명이 회사의 존폐를 가르기 때문에...

    키워볼까 생각도 했지만 떡잎은 대충 정해져 있더라구요. 인턴처럼 뽑았다가 써보기도 하고, 개인플레이인 사람들 뽑았을때 커뮤니케이션 툴 추천해주고 내가 직접 솔선수범해서 자료공유하고 해도 결국 안할사람들은 안한다는;; 

    (ex> 최신기술을 어떻게 연구를 해봤다, 적용을 시켜봤다 & 실제로 적용결과가 어떻게 되었다 등등..) 


    그런데 관리능력은 확실히 경력이 있어야 될 것 같긴 해요.. 위의 질문에 어느정도 검증이 되었다는 가정하에.. 

    아니면 대표님께서 능력이 조금 떨어져도 관리가 될만큼 체크리스트, 메뉴얼을 문서화시켜서 미리 짜두시는게 좋을 것 같습니다.

    사람을 너무 믿는건 상호간에 별로 좋지는 않은 것 같더라구요(신용, 믿음 문제가 아니라 서로 피곤해지느걸 방지하기 위해서입니다)

    사람만 믿고 알아서 해주겠지 하면 나중에 상황 시뮬레이션을 돌려볼수가 없습니다. 이미 지나간 뒤니까요

    개발자가 나갔을때, 새로 들어왔을때, 정착과정, 중간개발과정, 배포, 테스팅등등을 계속 시뮬레이션해서

    문서화를 시켜놔야 되더라구요;; 결국은 뭐 주말에 안놀고 계속 시스템화 하는거죠;;

    저희도 내부 코드관리는 리뷰 한달에 한번으로 그냥 퉁치고;; 모든 프로젝트는 프레임워크+검증된 라이브러리로 쓰라고 합니다. 최소 퀄리티 보증이죠

    나머지 기능테스트는 테스트케이스 도출에 더 신경을 씁니다. 결국 OXOX 체크를 더 잘 해야지... 


    이상한소리를 많이 적기는 했지만...

    말씀드리고 싶은 결론은, 관리까지 필요한거라면 연차에 연연해하지 말고,

    위에서 언급한 기본 소양+입사자 본인이 생각하는

    커뮤니케이션 방법 및 활용 Tool, 관리 방법 및 활용 Tool, 메뉴얼 작성 방법 및 활용 Tool, 고객사 소통 방법및 활용 Tool(메일, 메신저등 전화를 회피하고 업무에 집중할 수 있게 해주는 방법), CTO급을 뽑는다면 기술사업계획서도 써야되니.. 사실 사업계획서는 너무 많이 바란 것 같네요 ㅎㅎ;; 

    그래서 결국은 기본스킬+머릿속에서 시뮬레이션 잘 되는 분, 그리고 상대방 입장을 헤아릴 줄 아는분인가 아닌가가 중요한 것 같습니다. 상대방 입장을 헤아릴 줄 알면 관리방법도 같이 의논하다보면 나오더라구요


    2) 경력이 12년 이상인데  2년 이상 다닌 회사가 없는 개발자는 의심해 볼 것 - 레퍼런스 체크 필수.

    요새는 레퍼런스도 뻥튀기가 많아서 검증 불가입니다. 외주 맡겨놓고 본인이 참여했다고 하는 경우가 많아서;; 졸업생들도 외주맡겨서 해놓고 졸작이라고 내는마당에 회사는 오죽하겠어요 ㅋㅋ 그렇다고 코드 보여주세요 하면 회사내부보안때문에 없다고 하면;;

    그래서 그나마 개인 프로젝트나 오픈소스 참여한 이력이 있으면 해당 github commit 이력과 코드를 보고 또 보시는걸 추천합니다.. 사실 오픈소스 참여한 이력은 거의 없구요. 개인 프로젝트에서 저장용으로 올려놓은거 말고, 진짜로 몇백/몇천 commit씩 하신 분들이 있어요 그러면 코드를 어떻게 얼마나 어떤 패턴으로 짰는지, 그리고 commit 메시지 쓴 내용 보면 그 사람의 성격(?)을 알 수 있습니다.


    그게 안되신다면.... 어렵지만 차라리 멘토풀을 구해서 면접을 대신 봐달라고 하는게 낫습니다;;

    알고리즘 문제 풀어서 기술면접 검증하는 사이트도 있긴 하지만.. 저도 실제로 알고리즘 대회 수상한 친구 데리고 와봤는데, 프레임워크 구조를 이해를 못합니다. 그리고 문제가 빨리빨리 해결이 안되니까 알고리즘 푸는 습관이 나와서 그런지 금방 흥미를 잃고 그냥 안되는데요 라고 하더라구요.

    내가 찾아서 문제 던져주고 영어로 이메일 물어보니까 답변 해주는데 그걸 안물어봐요;;
    정부에서 ICT 멘토링 풀이 있으면 전문가분에게 좀 부탁하는게 좋을 것 같네용..
    (사실 슈퍼 프로그래머분들, CTO님들은 바빠서 이런거 안하기 때문에..... 아시는 개발자출신 사장님들에게 부탁하는게 더 나을수도 있습니다) 

    3) 사내 서비스든 외부 용역 대행 개발이든 자신의 개발코드, 일정 및 현재 상황 등을 공유하지 않으면 절대 '괜찮겠지'하고 내버려 두지 말고 최대한 빨리 조치를 취할 것 - 제가 대표가 직원을 의심하면 안 된다, 팀은 곧 믿음과 신용이다 생각하고 이걸 안 해서 값비싼 수업료를 냈다고 생각합니다. 

    Github Push 되면 슬랙이나 이메일로 다 날라오게 하시구요, commit message 정확하게 적으라고 하시고... 주별 목표, 데드라인, 해결방법, 문제 해결하면서 조사 및 참고 레퍼런스(세세하게는 아니지만)

    이정도는 경영진에게 알려줄 수 있다고 생각합니다.

    어차피 계획은 깨지라고 있는걸 알지만, 본인이 최선의 해결책을 찾기 위해서 조사를 했다는것에 대한 반증이니까요.

    리서치도 안해보고 삽질 많이했으니까 돈(월급등) 달라고 할때가 제일 짜증나죠;; 그런 정보공유의무가 없는 사람들은 솔직히 같이 일 안하는게 스트레스 안받을 것 같습니다. 저도 투명하게 운영하려고 어디가면 나 어디가서 몇시간 걸린다. 뭐 이유있어서 출근 늦게한다.(사장이 안나오면 다 노는줄 알아서;;) 하다못해 밤새서 못자면 나 밤새서 좀만 자다옴ㅇㅇ 톡으로 보냅니다.

    일부터 사업계획서 쓴거 보여주기도 하죠. 이거 읽어보고 말이 되는 것 같냐고 ㅋㅋ


    그리고 사실 대화 많이하는거 좋은건 아닌 것 같습니다;; 다들 바쁜거 알기 때문에 일단 대화의 주제를 메신저나 회의록(저희는 구글엑셀 활용합니다)에 적어놓은 상태에서 얘기 빨리 하는게 낫죠;; 6시에 가려면 와서 농담 할시간도 없습니다;;

    그리고 제일 중요한건 다른 사람이 뭘하는지 까먹는다는거 자체가 신뢰가 계속 떨어진다는겁니다. 저번 회의때 목표, 방법, 데드라인 다 정했는데 또 물어본다는게 눈치주는거 같잖아요 ㅎㅎ;


    뭐 이렇게 해도 본인이 끝났다고 나 뭐하냐고 물어보는 경우는 잘 없습니다만.. 빨리 끝내면 능력이 좋으니까 빨리 끝냈다고 생각하는게 좋습니다. 그런 친구들한테는.. 너가 너를 믿을 정도로 다 했니?? 아니면 진짜 다 했으면 나좀 도와달라고 ㅠㅠ 하면서 자료조사나 QA업무하고 하면 실제로 노는사람은 거의 없더라구요;;

    다 했다는 말 조심하셔야됩니다! 본인이 다 한거랑, 요구사항 및 QA항목에 다 맞게 해서 다 한거랑 다르거든요;; 결국은 조그만 회사에서는 대표가 개발은 몰라도 QA업무는 무조건 조금이라도 하셔야되지 않을까 싶네요

    왜냐면 QA가 끝나면 출시건 납품이건 고객에게 인도되기 때문에 저는 개발만큼 중요하다고 생각하거든요! 반대로 말하면, QA가 허드렛일이라고 생각하는 개발자가 있으면 뽑지 않아야 합니다. 본인이 만들기는 했으되, 책임을 지지는 않겠다는거니까요


    외부개발을 의뢰하신다고 하니 QA업무구축에 신경을 많이 쓰시면 그나마 커머가 되지 않을까 싶습니다. 그리고 외부 계약하실때 자체 솔루션이라면, 개발진을 위한 문서화+내부개발진 문의시 문서 추가 수정에 대한 계약도 하셔야 합니다(업무 완료시 90% 지급하고, 3개월정도 후에 10%를 지급하세요. 아니면 이행보증보험계약을 하셔도 되구요-보험료를 내야하지만;)

    기획 잘하면 되긴 하는데... CTO가 없이 기획자를 뽑아야 된다면 반드시 개발자 출신이어야 한다고 봅니다.(사실 이 사람이 CTO죠;) 단순히 UI/UX 잘 짜는 분이 아니구요. 어떤 Tech가 최적인지, 각 솔루션 활용시 시간비용, 인력수급문제, 개발난이도, 러닝커브등등을 다 고려해야 하니까요


    그리고 내부 개발팀 없어도 된다고 하셨는데;; 외주를 맡겨도 적은규모의 내부 개발팀(팀의 단위가 몇명인지는 잘 모르겠지만..)은 있어야 외주 검증을 할 수 있습니다.

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.