<div id="readability-page-1" class="page"><div><h2 id="미리-말씀드립니다">미리 말씀드립니다.</h2>
<p>이 글은 제가 스타트업 멤버, 대기업 주관 SI 프로젝트, 중견 기업의 외주 인력으로 일하면서 느꼈던 <del>인사이트</del> 주관적 관점입니다.<br>
저는 대기업에 <strong>정직원으로</strong>다녀본 적이 <strong>없습니다.</strong> 따라서 이 글은 편협하고 편견에 차 있을 가능성이 높을 것이라는 것을 미리 말씀드립니다.</p>
<h2 id="단점들">단점들</h2>
<h2 id="대기업-출신-매니저">대기업 출신 매니저</h2>
<p>스타트업은 아주 작은 단위로 시작하는 경우가 많습니다.<br>
창업자 혼자, 혹은 공동창업자 정도로만 시작했다가 조직이 커지면서 점점 인력이 늘어나게 되는데요.<br>
이 과정에서 스타트업이 가장 많이 하는 실수는 "대기업 출신 매니저"를 고용하는 거에요. 보통은 PM 출신이죠.<br>
스타트업 대표님 입장에서는 "큰 기업의 업무를 관리해 봤으니 우리처럼 작은 기업을 관리하는 데는 문제가 없을꺼야" 라고 생각하시는 것도 충분히 이해가 갑니다.<br>
하지만 여기에서는 고려해야 하는 점들이 몇 개 있습니다.</p>
<hr>
<h2 id="프로세스가-달라요">프로세스가 달라요.</h2>
<p>대기업은 일이 분업화되어 있습니다. 아주 작은 부분까지 어떤 포지션의 직원이 하는지 나누어져 있고 그에 맞는 프로세스도 확립되어 있습니다.<br>
모든것이 확정되어 있는 상황에서 잘 동작하는지 확인하는 PM 으로써의 역할을 잘 하던 사람이라도, 매일매일 프로세스를 "만들어야" 하는 유연한 상황에 익숙하지 않을 경우가 많을 것이라 생각합니다.<br>
업무가 복잡하지만 고정된 상황을 관리하던 사람이 상대적으로 단순하지만 유연한 상황을 관리해야 하는 일을 무조건 잘하리라 생각하지 않아요.</p>
<h2 id="사실-대기업-pm들은-코딩과는-거리가-멀어요">사실 대기업 PM들은 코딩과는 거리가 멀어요.</h2>
<p>일부를 보고 전체를 평가하는 것은 어리석다고 생각합니다만, 제가 봤던 많은 분들은 실무가 아니라 관리에 촛점을 맞추고 계셨어요. 관리에 특화된 분들은 코딩과는 거리가 멉니다.<br>
굳이 코딩이라고 표현한 이유는, 개발이라는 단어는 바운더리가 넓어서 코딩, 설계, 기획, 디자인, 관리 .. 등을 모두 포함하는 개념이라고 생각해서에요.<br>
코딩과 거리가 멀다는 건, 실제 코드를 작성하면서 생기는 애로사항들을 이해하지 못한다는 의미고, 작은 스타트업에서 아주 사소한 것까지 챙겨야 하는 포지션으로는 그다지 적합하지 않은 것 같아요.</p>
<p><del>개인적으로는 "개발자로 입사하셨지만 코드는 한 줄도 작성해 본 적 없고 사람들 닥달하고 문서 작업하고 보고하고 회의하시면서 경력을 쌓은 PM"도 본 적이 있어서 더욱 개인적인 경험이 반영된 것 같기도 합니다.</del><br>
물론 코딩도 잘 하시고, 기획, 디자인 혹은 사업적인 측면도 잘 고려하시는 분들도 계시겠지만, 대기업 출신이라고 이 모든 것을 다 잘하시리라는 기대는 버리는 게 낫습니다.</p>
<h2 id="금액의-단위">금액의 단위</h2>
<p>돈이 상대적으로 없고 규모가 작으므로 스타트업이라고 부를 꺼에요. 시작하자마자 직원이 천명 정도 된다면 이미 스타트업이라고 부를 수는 없지 않을까요.<br>
일반적으로 대기업에서 집행하는 비용과 스타트업에서 쓰는 비용은 다를 수밖에 없어요. 하지만 큰 기업에서 커리어를 쓰는 사람은 스타트업이 한 달 쓰는 비용을 "그정도쯤이야" 라고 생각하기 쉽죠.</p>
<blockquote>
<p>대표님 : "이번 건으로 인해 손해가 2억 정도 생겼어요."<br>
PM : "그정도쯤이야 뭐 큰 돈도 아닌데 괜찮지 않아요?"</p>
</blockquote>
<blockquote>
<p>PM : "오라클을 도입합시다!"<br>
경영지원팀 : "비용이 얼마나 할까요?"<br>
PM : "코어당 천만원 정도에요. DBMS 서버니까 1년에 8천만원 정도입니다."<br>
대표님 : "오라클을 써야 하는 이유가 있는 건가요? 대안이 없을까요?"<br>
PM : "제가 사용해 본 게 오라클밖에 없어서 다른 것은 잘 모르겠습니다."</p>
</blockquote>
<p>앞으로 벌어도 뒤에서 다 까먹을 것 같네요.</p>
<h2 id="전체를-다-보기에는-힘들다">전체를 다 보기에는 힘들다.</h2>
<p>대기업은 말 그대로 사람이 많다는 의미고, 부서가 나누어져서 피라미드 구조를 이루고 있는 경우가 많죠.<br>
PM도 하나의 프로젝트를 매니지먼트한다는 의미이지 회사 전체를 생각하면서 프로젝트를 관리한다는 뜻이 아닙니다.<br>
즉, 자신이 맡은 프로젝트에 대해서는 빠삭하고 경험이 많은 사람도 이를 전사적 차원에서 바라보는 훈련이 된 사람은 별로 없을 꺼에요. 대기업에서 전사적 차원으로 바라보고 의사결정을 하는 사람이 되려면 이미 머리가 하얀 분이셔야 할 테니까요.<br>
프로젝트의 PM이라고 해도 상사가 있고, 상사의 허락만 있으면 되기 때문에 상사가 어떤 이유로 인해서 어떤 결정을 내렸는지까지는 체험해 보지 못한 케이스가 많습니다.</p>
<h2 id="페이퍼워크">페이퍼워크</h2>
<p>대기업 출신, 혹은 대기업과 일해본 사람들은 다들 알고 있을 꺼에요.<br>
코드 한 줄 고쳤는데 문서를 여섯 개 만들어야 하는 현실을요.<br>
요구사항 명세서, wbs, 테스트 결과서 ... 회사마다 부르는 이름은 다를지라도 뭔가를 작성해야 하는 건 똑같습니다.<br>
이 문서들이 필요한 이유는 보고서 결재 라인마다 필요한 문서가 다르기 때문인데요.<br>
부장님은 요구사항 명세서, wbs 는 PM, 테스트 결과서는 상무님, 성능 보고는 옆부서 인프라팀.. 이런 식이라 그렇습니다.</p>
<p>반면 정작 문서를 작성해야 하는 현업 개발 직군들에게는 죽을 맛입니다. 정말 바쁜데 문서까지 만들어야 하거든요.</p>
<p>PM분들도 날로 먹는 건 아니라서, 각종 문서들을 취합해서 정리하는 것이 업무죠.<br>
이게 당연한 것으로 배웠기 때문에 왜 의미없는 페이퍼워크가 필요한지에 대해서 진지하게 고민하는 사람은 별로 못 봤습니다.<br>
아무도 안 보는 문서는 대체 왜 필요한가요?<br>
게다가 오늘 써도 내일 내용이 바뀌는데, 종일 문서만 만들다가 야근하실 건가요?<br>
<del>대표님께서 문서 작업을 좋아하신다면 최고의 관리자일 수도 있습니다.</del></p>
<h2 id="장점">장점</h2>
<h2 id="인맥">인맥</h2>
<p>첫번째로는 인맥을 연결하는 데 좋습니다.<br>
큰 기업에 있었다는 건 검증된 사람들을 많이 만나봤고 많이 알고 있다는 이야기도 됩니다.<br>
채용, 투자 등으로 외부 인맥이 필요할 때는 대기업 출신이 아주 큰 도움이 됩니다.</p>
<h2 id="투자">투자</h2>
<p>두번째로는 투자받기가 좋다는 겁니다.<br>
"N사 출신의 CTO가 있음"<br>
이 말만으로도 투자자들에게 점수를 따는 데 꽤 큰 점수를 주는 투자자 분들도 계시는 걸 종종 봤어요.</p>
<h2 id="결론">결론</h2>
<p>대기업 출신이 무조건 나쁘다고 말하는 것이 아닙니다. 그건 억지죠.<br>
이 글은 제가 그간 겪었던 대기업 출신 인사분들의 특징이 대략 이렇다는 것이지 모든 대기업 사람이 스타트업에 부족하다는 뜻은 절대 아닙니다.</p>
<p>말씀드리고 싶었던 건 "대기업 출신이라고 뭐든 다 잘하는거 아니다. 상황에 맞는 사람을 고르는 게 필요한거다" 였습니다.<br>
대기업과 반대로 작은 기업만 전전하던 사람들이라고 갑자기 안하던 일을 잘하게 되는 기적같은 게 일어날 리는 없습니다.</p>
<p>스타트업에서 인사권을 가지고 계신 분들은 <strong>어디 출신인가보다는 이 사람이 우리에게 필요한 스킬과 경험을 가진 사람인가</strong>에 조금 더 포커스를 주는 건 어떨까요?</p></div></div>

고은연

미리 말씀드립니다.
이 글은 제가 스타트업 멤버, 대기업 주관 SI 프로젝트, 중견 기업의 외주 인력으로 일하면서 느꼈던 인사이트 주관적 관점입니다.
저는 대기업에 정직원으로다녀본 적이 없습니다. 따라서 이 글은 편협하고 편견에 차 있을 가능성이 높을 것이라는 것을 미리 말씀드립니다.
단점들
대기업 출신 매니저
스타트업은 아주 작은 단위로 시작하는 경우가 많습니다.
창업자 혼자, 혹은 공동창업자 정도로만 시작했다가 조직이 커지면서 점점 인력이 늘어나게 되는데요.
이 과정에서 스타트업이 가장 많이 하는 실수는 "대기업 출신 매니저"를 고용하는 거에요. 보통은 PM 출신이죠.
스타트업 대표님 입장에서는 "큰 기업의 업무를 관리해 봤으니 우리처럼 작은 기업을 관리하는 데는 문제가 없을꺼야" 라고 생각하시는 것도 충분히 이해가 갑니다.
하지만 여기에서는 고려해야 하는 점들이 몇 개 있습니다.
프로세스가 달라요.
대기업은 일이 분업화되어 있습니다. 아주 작은 부분까지 어떤 포지션의 직원이 하는지 나누어져 있고 그에 맞는 프로세스도 확립되어 있습니다.
모든것이 확정되어 있는 상황에서 잘 동작하는지 확인하는 PM 으로써의 역할을 잘 하던 사람이라도, 매일매일 프로세스를 "만들어야" 하는 유연한 상황에 익숙하지 않을 경우가 많을 것이라 생각합니다.
업무가 복잡하지만 고정된 상황을 관리하던 사람이 상대적으로 단순하지만 유연한 상황을 관리해야 하는 일을 무조건 잘하리라 생각하지 않아요.
사실 대기업 PM들은 코딩과는 거리가 멀어요.
일부를 보고 전체를 평가하는 것은 어리석다고 생각합니다만, 제가 봤던 많은 분들은 실무가 아니라 관리에 촛점을 맞추고 계셨어요. 관리에 특화된 분들은 코딩과는 거리가 멉니다.
굳이 코딩이라고 표현한 이유는, 개발이라는 단어는 바운더리가 넓어서 코딩, 설계, 기획, 디자인, 관리 .. 등을 모두 포함하는 개념이라고 생각해서에요.
코딩과 거리가 멀다는 건, 실제 코드를 작성하면서 생기는 애로사항들을 이해하지 못한다는 의미고, 작은 스타트업에서 아주 사소한 것까지 챙겨야 하는 포지션으로는 그다지 적합하지 않은 것 같아요.
개인적으로는 "개발자로 입사하셨지만 코드는 한 줄도 작성해 본 적 없고 사람들 닥달하고 문서 작업하고 보고하고 회의하시면서 경력을 쌓은 PM"도 본 적이 있어서 더욱 개인적인 경험이 반영된 것 같기도 합니다.
물론 코딩도 잘 하시고, 기획, 디자인 혹은 사업적인 측면도 잘 고려하시는 분들도 계시겠지만, 대기업 출신이라고 이 모든 것을 다 잘하시리라는 기대는 버리는 게 낫습니다.
금액의 단위
돈이 상대적으로 없고 규모가 작으므로 스타트업이라고 부를 꺼에요. 시작하자마자 직원이 천명 정도 된다면 이미 스타트업이라고 부를 수는 없지 않을까요.
일반적으로 대기업에서 집행하는 비용과 스타트업에서 쓰는 비용은 다를 수밖에 없어요. 하지만 큰 기업에서 커리어를 쓰는 사람은 스타트업이 한 달 쓰는 비용을 "그정도쯤이야" 라고 생각하기 쉽죠.
대표님 : "이번 건으로 인해 손해가 2억 정도 생겼어요."
PM : "그정도쯤이야 뭐 큰 돈도 아닌데 괜찮지 않아요?"
PM : "오라클을 도입합시다!"
경영지원팀 : "비용이 얼마나 할까요?"
PM : "코어당 천만원 정도에요. DBMS 서버니까 1년에 8천만원 정도입니다."
대표님 : "오라클을 써야 하는 이유가 있는 건가요? 대안이 없을까요?"
PM : "제가 사용해 본 게 오라클밖에 없어서 다른 것은 잘 모르겠습니다."
앞으로 벌어도 뒤에서 다 까먹을 것 같네요.
전체를 다 보기에는 힘들다.
대기업은 말 그대로 사람이 많다는 의미고, 부서가 나누어져서 피라미드 구조를 이루고 있는 경우가 많죠.
PM도 하나의 프로젝트를 매니지먼트한다는 의미이지 회사 전체를 생각하면서 프로젝트를 관리한다는 뜻이 아닙니다.
즉, 자신이 맡은 프로젝트에 대해서는 빠삭하고 경험이 많은 사람도 이를 전사적 차원에서 바라보는 훈련이 된 사람은 별로 없을 꺼에요. 대기업에서 전사적 차원으로 바라보고 의사결정을 하는 사람이 되려면 이미 머리가 하얀 분이셔야 할 테니까요.
프로젝트의 PM이라고 해도 상사가 있고, 상사의 허락만 있으면 되기 때문에 상사가 어떤 이유로 인해서 어떤 결정을 내렸는지까지는 체험해 보지 못한 케이스가 많습니다.
페이퍼워크
대기업 출신, 혹은 대기업과 일해본 사람들은 다들 알고 있을 꺼에요.
코드 한 줄 고쳤는데 문서를 여섯 개 만들어야 하는 현실을요.
요구사항 명세서, wbs, 테스트 결과서 ... 회사마다 부르는 이름은 다를지라도 뭔가를 작성해야 하는 건 똑같습니다.
이 문서들이 필요한 이유는 보고서 결재 라인마다 필요한 문서가 다르기 때문인데요.
부장님은 요구사항 명세서, wbs 는 PM, 테스트 결과서는 상무님, 성능 보고는 옆부서 인프라팀.. 이런 식이라 그렇습니다.
반면 정작 문서를 작성해야 하는 현업 개발 직군들에게는 죽을 맛입니다. 정말 바쁜데 문서까지 만들어야 하거든요.
PM분들도 날로 먹는 건 아니라서, 각종 문서들을 취합해서 정리하는 것이 업무죠.
이게 당연한 것으로 배웠기 때문에 왜 의미없는 페이퍼워크가 필요한지에 대해서 진지하게 고민하는 사람은 별로 못 봤습니다.
아무도 안 보는 문서는 대체 왜 필요한가요?
게다가 오늘 써도 내일 내용이 바뀌는데, 종일 문서만 만들다가 야근하실 건가요?
대표님께서 문서 작업을 좋아하신다면 최고의 관리자일 수도 있습니다.
장점
인맥
첫번째로는 인맥을 연결하는 데 좋습니다.
큰 기업에 있었다는 건 검증된 사람들을 많이 만나봤고 많이 알고 있다는 이야기도 됩니다.
채용, 투자 등으로 외부 인맥이 필요할 때는 대기업 출신이 아주 큰 도움이 됩니다.
투자
두번째로는 투자받기가 좋다는 겁니다.
"N사 출신의 CTO가 있음"
이 말만으로도 투자자들에게 점수를 따는 데 꽤 큰 점수를 주는 투자자 분들도 계시는 걸 종종 봤어요.
결론
대기업 출신이 무조건 나쁘다고 말하는 것이 아닙니다. 그건 억지죠.
이 글은 제가 그간 겪었던 대기업 출신 인사분들의 특징이 대략 이렇다는 것이지 모든 대기업 사람이 스타트업에 부족하다는 뜻은 절대 아닙니다.
말씀드리고 싶었던 건 "대기업 출신이라고 뭐든 다 잘하는거 아니다. 상황에 맞는 사람을 고르는 게 필요한거다" 였습니다.
대기업과 반대로 작은 기업만 전전하던 사람들이라고 갑자기 안하던 일을 잘하게 되는 기적같은 게 일어날 리는 없습니다.
스타트업에서 인사권을 가지고 계신 분들은 어디 출신인가보다는 이 사람이 우리에게 필요한 스킬과 경험을 가진 사람인가에 조금 더 포커스를 주는 건 어떨까요?

스타트업에 큰 기업 출신이 무조건 좋을까?

댓글