우리회사는 벤처다.
뭐 나름 코스닥에 상장되어 있긴 하지만 그나마 우회 상장인데다가 수폐인의 말을 빌리자면 '개잡주' 인 그런 쬐끄만 회사다.
이런 회사에는 고질병이 있다. 바로 '관리'다.
수폐인의 회사 같은 대기업 (다케시마 후원 기업으로 루머가 돌고 있는 모 일본계 기업) 이야 그룹사 차원에서 회사 운영 시스템이 갖추어져 있다. 회사는 시스템이 운영하고 인간은 단지 시스템의 부속이 되어 돌아가는거다.
비인간적으로 보이지만 사실 이건 아주 효율적인 방안이다. 시스템 매뉴얼에 따라서 동작하기 때문에 백업 인력, 문서관리, 신규 인력 충원, 잉여 인력 퇴출, 업무의 재배치 등이 체계적으로 동작한다.
매뉴얼 사회 일본을 보고 베껴먹은 '관료주의' 의 장점이다.
괜히 대기업에서 사내 메신저나, 사내 업무 시스템을 따로 갖추고 있는게 아닌거다. 심지어 그런 시스템만 개발해서 먹고 사는 회사도 있을 정도다. 더존 같은 경우에는 그걸 전문으로 해서 국내에서는 아는 사람은 다 아는 회사로 성장했다.
우리 같은 벤처는 이런 시스템화가 이루질수가 없는 구조다. 왜? 당연히 비용 문제 때문이다.
지는 중기업이라고 뻥치는 수폐인 회사는 적자가 나도 그룹차원의 지원이 있을 수 있다. (사실 완전 흑자일테지만. 매출을 비교하면 우리 회사 따위는 상대도 되지 않는다) 그런 고로 비용을 들여서 업무 관리 시스템을 도입하고 당장에 효율은 떨어지는 백업 시스템. 백업 인력을 갖출 수 있다.
쬐끄만 회사? 당연히 그런게 있을리 있나. 당장 적자나면 자본 잠식에 들어가는 구조를 가진 시가총액 300억 미만, 총 직원 80명 미만의 회사에서 한사람이면 매출 및 개발에 지장이 없는데 백업 인력까지 둘리가 없다.
백업 인력으로 신입사원 한명만 뽑으면 인건비가 3~4천이 증가하는데 1~2천에 목숨 걸며 영업해야 하는 입장에서 가능한 일이 아닌거다.
기껏 잘해봐야 상호 크로스 백업 정도다. 크로스 백업하니 백업인력이 있는거 아니냐고? 당연히 아니지.
다시 한번 강조하지만 인건비는 비싸다. 우리같은 IT 업계에서는 인건비가 원가의 대부분을 차지 할 정도로 비중이 높다. 고로 '최소한'의 인력만을 운영해야만 장기간 이어지고 있는 불경기를 버틸수 있는거다.
그런고로 대부분의 IT 회사의 개발자 인력들은 과도한 업무에 시달린다. 괜히 IT 는 노가다판, 4D 산업(3D + Don't sleep) 이라는 말이 나오는게 아닌거다.
적어도 우리나라 개발자들에게 정시출근 정시 퇴근은 판타지 세상 이야기다. (물론 나야 퇴근이 늦는만큼 출근도 늦지만.ㅡㅡ) 주 40시간 법정 근무시간만 일하는 개발자는 내가 장담하건데 우리나라에는 '없다' 라고 잘라 말할수 있다.
그런 고로 개발자, 특히 우리같은 쬐끄만 회사 개발자들은 업무가 많다. 즉 내꺼 하기도 바빠 죽겠구만 이미 다른 사람이 하고 있는것 까지 백업 받으라고 하면 당연히 '아 네' 하고 받는 경우는 거의 없고 건성건성이 되는거다. 결국 당장에 내 일이 아니니까. 물론 안 할 수 없다는걸 알고 있으니 백업을 받기야 하지만 잘 될 리 없다.
결국 이러다 보면 시스템, 매뉴얼에의해 동작하는 대기업과는 달리 우리같은 중소 벤처 기업은 '개인의 경험'에 의해 동작하게 된다.
이러다보니 아주 치명적인 리스크가 발생하는데 어떤 업무를 담당하고 있는 인력이 갑자기 모종의 사유로 빠져 버리면 그 업무를 대체 할 수 있는 인력이 없다는거다. 또 필요한 업무를 담당하고 있는 인력이 아무리 마음에 안들어도 어떻게 할 수 가 없다.
수폐인이 계속 자기한테 '부장인줄 알았다'는 멘트를 던진, 우리가 불만이 많은 모 팀장을 자르라고 하는데 사실 이사람은 대체 인력이 없다. 팀장급 인사도 없을 뿐 아니라 사내에 svn 과 trac 등 업무 관리 시스템을 자기 혼자 잡고 있기 때문에 아무리 불만이 있어도 대체 인력이 없기 때문에 자를수가 없다.
(게다가 특별한 사유 - 정확한 법적 근거 - 없는 해고는 불법이다. 물론 벤처에서야 경영상 정리 해고와 그냥 해고가 구분이 잘 안되지만)
같은 이유로 문서화 역시 잘 이루어지지 않는다.
어차피 내가 하는거고 앞으로도 내가 할게 보이는데다가 만들어서 크로스 백업 인력입네 하고 줘봐야 보지도 않을 문서 따위 정성들여, 시간을 투자하여 만들리 없는거다.
게다가 개발자들은 거의 대부분 치명적인 문제를 안고 있는데 바로 '표현력 부족'이다. 나야 내가 만들었으니 당연한 것도 새로운 인력이 투입되서 보기엔 '이건 뭥미?!' 가 되는거다.
똑똑하고 아는게 많은거랑 잘 가르치는 거랑은 완전히 다른 능력이다. 그리고 대부분의 개발자들은 타인에게 내 생각을 전달하는 능력이 부족하고 그걸 문서로 만드는 능력은 더 부족하다.
기껏 열심히 만들어 봐야 결국은 지만 볼 수 있는 문서만 만들게 되는데 그래서야 문서를 만드는 의미가 없다. 그냥 자기 다이어리에 찍찍 그리는게 더 편하다.
확신하건데 모든 개발자들은 선임이 만들어 놓은 '교육자료' '매뉴얼' '설계서' 따위를 받아보고 추가적인 질문, 자료 검색, 표시되어 있지 않은 참고자료 참조 등이 필요치 않았던 적은 단 한번도 없을거다.
그런 자료를 받고 욕하지만 막상 자기가 자료를 만들때가 되면 결국 똑같은 짓을 하고 있는거다. (사실 만들어 놓기나 하면 다행이다.)
그리고 프로젝트 이외의 업무나 기술적인 노하우 등을 문서로 만들라고 하면 사실 이건 개발자들에겐 불가능한 미션에 가깝다. 자기의 깨달음을 언어로 표현한다는것은 예수나 공자, 석가모니, 소크라테스 정도의 성인도 직접적으로 설명하지 못하고 '비유'라는 방법을 통해 서술했다.
Media RTP 통신에서 음질을 들어 보고 '아... 이건 Payload 가 전부 수신되지 않는 것 같네', '아... 이건 Packet 수신 속도가 10ms 정도 느린것 같아.' '아... 이건 Packet 이 중간에 누락 되는것 같네' 라는 노하우를 어떻게 문서로 설명하나?
그냥 많이 들어보고 많이 해보는 수 밖에 없는거다.
그리고, 애초 읽는 놈이 뭘 어떻게 알고 있고 어느 수준일지 어케 알고 거기 맞춰 문서를 쓴단 말인가? 한글도 모르는 영미권 개발자를 앉혀놓고 한글 문서를 들이밀어봐야 삽질인거다.
물론 그렇다고 문서화가 불필요하다는건 아니다. 최대한 많이 문서화 하여 최대한 많은 자료를 축적할 필요가 있다. 대기업이라고 처음부터 그런게 있었을리 없다.
계속해서 매뉴얼화, 시스템화를 지향하고 노력했기 때문에 그렇게 된거다.
하지만 돈과 시간에 쪼들리는 우리같은 중소 벤처가 대기업 따라 하려다가는 가랑이 찢어지기 마련이지.
직원들이 조금(사장 입장에서)만 고생하면 천만원 흑자가 나는데 미쳤다고 연봉 3~4천 만원짜리 백업 인력을 투입한단 말인가? 투입하는 순간에 적자로 돌아서는데?
그런식으로 회사를 운영하면 사실 기존 직원들에도 좋을게 없다. 일단 빡센 회사라도 회사가 안망해야 월급이 나올게 아니냔 말이다. 백업 인력이라고 필요 인력의 1.5배를 유지하다가 부도가 나는 어이없는 회사에 누가 다닐까?
물론 우리나라야 이해의 범주를 넘어서서 이제 여유가 좀 있어 신규 인력 충원을 좀 해도 될 것 같은데 그냥 이득을 위해서 쥐어짜는게 일상이라 그게 문제지만.
뭐. 쥐어짜이다보면 진짜 짜증나고 힘들지만 그렇다고 해서 방만하게 직원들 요구사항 다들어주면서 경영했다가는 망하기 딱좋은거다.
아뭏튼 결론은 누군가는 자르기 힘들다는 거다.
그 밑에 오늘도 기본적인 통신 모델 fixed length header, variable length body 를 '기존에 그렇게 안되 있다' 라면서 짜증나게 하던 누군가는 좀 짤랐으면 좋겠지만... 내가 말해서 짜르면 나중에 TTS가 그인간이 짤리는 바람에 업무가 늘었다며 나를 원망하겠지.ㅡㅡ
고로 폐인아. 내가 그인간을 짜르고 대체 인력을 너를 꽂아주마.현재 대체 불가능한 인력인 누군가가 나이들어보인다고 했다고 소심하게 삐져서 안오고 버티지 말고 얌전히 복마전으로 입성해라.
