안녕하세요 괴짜 개발자 namedboy 입니다. 😎
스타트업에서 일을 하다 보면 짧은 시간 동안 많은 일을 한꺼번에 경험하게 됩니다.
그중 하나가 바로 결정 권한이 아닐까 싶은데요.
작은 규모의 조직에서는 한명 한명이 할 수 있는 것들이 제한되는 것보다 다양한 의견을 내고 들으며 그에 따른 다양한 시도를 할 수 있도록 권한을 가지는 것이 더 큰 시너지 효과를 내기 때문일 것 같습니다.
물론 큰 규모의 조직에서도 요즘은 다양한 시도를 하고 있고 그것에 맞게 신입사원인데도 불구하고 많은 권한을 가지게 되기도 합니다.
하지만 그게 모든 회사에 적용되지는 않지요. 뉴스나 기삿거리가 된다는 것은 그만큼 그 일이 사람들에게 희소가치가 높기 때문일 겁니다. 작은 규모에서는 당연한 일들이 규모가 큰 조직에서는 가십거리의 일인 것이죠.
큰 조직에서 시도한다는 것은 그게 그들에게는 일종의 돌파구일 수도 있다는 생각도 듭니다.
어쨌든 많은 권한을 가지는 경험을 통해 배우게 되는 것들이 스타트업에서의 장점이 아닐까 생각합니다. 또 내가 더 성장하고 앞으로의 인생을 개척하는 데 도움이 되는 부분들도 분명히 있고요.
개발자의 입장에서 생각해보면 이러한 결정 권한들은 어떻게 성장하고 싶은지 그리고 어떤 배경을 가지냐에 따라 약이 되기도 독이 되기도 합니다. 어떤 상황에서 약이 되고 어떤 상황에서 약이 되는지 한번 볼까요?
기본적으로 개발자는 할 수 있는 일의 범위를 원하는 만큼 넓힐 수 있는 직군입니다. 처음에야 당연히 제품의 기능 개발만 하게 되겠지만 개발자 자신이 원한다면 기획에 참여할 수도 있고 제품의 기능 테스터 또는 제품의 전체를 책임지는 사람이 될 수도 있죠.
보통 아이디어가 제품이 되기까지는 아래 과정을 거치게 됩니다.
아이디어 → 기획 → 디자인 → 개발 → 완성 + 공개
여기서 개발을 좀 더 확장 시켜 보면 아래처럼 됩니다.
요구사항 분석 → 요구사항에 맞는 기능 정의 → 기능 개발 → 테스트 → 제품에 적용 또는 배포
물론 이 내용은 너무나도 교과서적인 내용이고 실제 업무는 조금 다를 수도 있습니다. 명확한 부분은 회사가 의도한 기능을 사용자가 쓸 수 있도록 개발을 한다는 것이죠. 사용자가 있기 때문에 편의성이 제공되어야 하고 제품이 제대로 동작하기 위해 버그가 없어야 합니다. 개발 영역에 한해서 생각한다고 해도 꽤 많은 일들을 하게 됩니다. 이러한 이유로 많은 방법론이 생기고 제품을 개발하는 방식이 발전해 왔습니다.
스타트업 혹은 작은 규모의 조직에서는 이 모든 것들을 할 시간이 없기 때문에 여러 가지 이유로 요구사항 분석이 제대로 되지 않거나 혹은 테스트가 제대로 되지 않거나 하면서 시행착오를 많이 겪게 됩니다. 그렇게 회사의 전체 프로세스가 만들어지고 지켜야 할 규칙과 방식들이 생겨나죠.
문제는 이 프로세스나 규칙들을 정할 권한이 대학을 막 졸업한 신입 개발자에게 주어졌을 때입니다. 이게 제가 생각하는 독이 되는 케이스입니다.
신입의 경우 많은 부분을 배워야 합니다. 실제로 업무를 놓치는 경우도 많고 잘 모르기도 합니다. 그 때문에 업무를 장기적으로 생각해서 계획을 세우는 것이 어렵고 당장 해야 하는 일들을 쳐내기에도 바쁩니다. 그럼 프로세스나 규칙들도 큰 관점에서 보고 만들지 못합니다. 애초에 아는 부분도 적지요. 잘못된 규칙이나 프로세스가 만들어지기 쉽고, 그러면 결국 맞지 않은 옷을 입은 것처럼 고민에 빠지게 됩니다.
정작 실력은 키우지 못했기 때문에 이직은 꿈도 못 꾸고 회사에서는 시간이 부족하니 개인의 실력보다는 요구사항을 먼저 말할 수밖에 없는 상황이 만들어집니다. 신입 개발자는 어떤 분야를 선택할지 고민하면서 전문가로 성장해야 하는데 그런 고민은 전혀 하지 못한 채 경력 개발자가 됩니다. 나 자신의 전문 분야가 무엇인지도 모른 채 말입니다.
결국 더 성장하기 위해 퇴사를 하게 됩니다. 빠르게 퇴사했다면 모르겠지만 1년이상의 경력이 쌓였다면, 퇴사해도 제대로 된 경력을 쌓지 못했으니 이직도 힘들어지고 비슷한 수준의 작은 규모의 회사로 입사하게 됩니다. 회사 입장에서도 실력을 떠나 신입은 부담스럽지만 작은 규모의 회사라도 경험을 해본 경력자라면 나름대로 반겨주기 때문입니다. 이제 시작하는 회사로 다시 들어가는 개발자분은 또다시 비슷한 경험을 비슷하게 합니다. 결국 배우는 것이 없이 경력만 늘어나게 되는 거죠.
다만 어쩌다 운 좋게 괜찮은 경력자를 만나게 되면 실력 있는 경력 개발자로 성장하기도 합니다.
하지만 늘 그렇듯이 좋은 케이스는 굉장히 드물고 개인에게도 정말 어려운 도전이 됩니다.
그래서 가능하면 신입 분들의 경우 꼭 경력자가 있는 회사로 가시길 권하고 싶습니다.
반대로 경력자는 어떨까요?
사실 경력 개발자들도 전체 프로세스나 규칙에 대한 고민은 많이 하지 않습니다. 실제로 그런 고민을 하는 것이 잘 맞지 않는 분들도 있고요. 그 때문에 프로세스나 규칙이 만들어지지 않은 작은 규모의 회사에서 하나씩 만들어가는 것을 좋아하는 분이 아니라면 가지 않습니다. 가더라도 어느 정도 만들어진 상태의 회사를 가게 되죠. 프로세스나 규칙이 어느 정도 만들어진 회사라면 회사의 규모 또한 아주 작은 상태가 아닙니다. 이미 여러 개발팀이 존재하거나 매출을 만들기 위한 전체 프로세스가 이미 정해진 상태이기도 하죠.
여기서 독이 되는 케이스는 프로세스나 규칙이 이미 잘 구성된 상태의 회사만 다니시던 분이 그런 것들이 전혀 없는 바닥부터 시작하는 회사에 입사하게 되는 경우입니다.
보통 이름난 대기업에서 다니던 분이 작은 규모의 회사에 입사하게 되는 경우입니다. 이미 만들어진 것들을 하다가 이제는 내가 만들고 싶다는 생각이 들어서 이직을 하게 되는 경우인데 문제는 아무런 준비 기간 없이 이직하게 되었을 때 발생합니다. 이름난 대기업에서 하는 것들은 보통은 작은 규모의 회사에서는 통하지 않기 때문이죠. 제가 생각하는 제일 최악의 케이스는 개발 능력은 뛰어나지만, 협업에 대한 개념이 없고 매니징을 전혀 해보지 않은 10년 이상의 개발자분들이 작은 규모의 회사에서 매니저의 역할로 일을 하게 될 때 나타나는 것 같습니다.
매니징과 개발은 전혀 다른 영역이고 개발자가 매니저가 되기 위해서는 또 다른 영역의 문제들을 맞닥뜨리게 됩니다. 가장 기본적인 부분은 커뮤니케이션이죠. 개발자 출신이기 때문에 개발자와 얘기하는 것은 어렵지 않지만 개발한 결과물을 수치로 만들고 그 수치를 기반으로 대표를 설득하는 것은 전혀 다른 새로운 도전이기 때문입니다. 특히나 큰 기업에서의 일하는 방식이 전혀 다른 작은 규모의 스타트업이나 기업들에서 적응하면서 매니징 + 개발을 하는 것은 정말 어렵습니다. 한 명이 할 수 있는 일의 크기가 아니기 때문이죠.
이제 시작하는 스타트업이나 작은 규모의 조직으로 이직을 하고자 하시는 고 경력자분들은 “내가 매니징을 잘 할 수 있는가?”에 대한 고민을 한 번쯤 해보고 어떤 방법이든 시도해보고 준비하는 시간을 가지는 것이 최악의 케이스를 피하는 길이라고 생각합니다.
개발자라는 측면에서 결정 권한이 얼마나 주어지는지에 따라 개인에게는 어떤 영향을 주는지 한번 생각해보고 정리해봤습니다.
말도 많고 탈도 많은 스타트업 업계에서 일하시는 분들이 모두 원하는 목적을 이루며 탈 없이 지내셨으면 좋겠네요.