스타트업을 다니면서 느꼈던 현실과 생각들

스타트업을 선택한 이유

일단 스타트업을 다닌 이유는 SI에서 클라이언트 개발자에서 백엔드로 이직을 하면서 네카라쿠배라는 대기업에서 일하는 경험을 하고 싶었지만 지금 당장 현실적으로는 다른 지원자에 비해 경쟁력을 가진 경험도 없었고 높은 수준의 진입장벽도 존재하기 때문에 당장 준비하기보다는 차근차근 스탭을 거쳐서 올라가겠다는 생각과 드라마 실리콘벨리를 보고 내가 몸을 담고 있는 이 스타트업이 그런 기업이 될 수 있을 것이라는 꿈을 품고 스타트업에서의 여정을 시작하게 되었다.

 

스타트업의 현실

내가 생각했었던 스타트업의 개발자는 위그림처럼 적어도 3~5명의 엔지니에가 뭉쳐서 밤새 같이 고민하고 개발하는 미래를 생각하고 시작했지만 현실은 단 두명의 개발자분들이 백엔드와 Ios를 담당하여 개발을 진행하고 있었다. 그래도 시니어 개발자분이 많은 경험을 가지고 계셨고 이런 소규모팀에서의 경험도 성장의 도움이 될 것이라는 생각에 조인을 승락하고 서울로 올라왔었다. 하지만 며칠후에 그분은 다른 스타트업으로 이직하게 되면서 혼자 남게 되었고 나는 목줄을 끌고 산책하는 개처럼 혼자서 하나의 IT 프로덕트를 끌어가는 신세가 되고 말았다.

기존에 있던 프로젝트를 유지보수하면서 많은 시행착오를 겪고 문제를 해결하면서 점점 적응되어가고 있을 무렵에 결국 첫번째 스타트업은 투자무산으로 회사운영이 어려워지고 말았고 나는 3개월만에 권고사직을 당하게 되었다. 첫 권고사직이라는 경험에 힘들었지만 지금 현실을 비탄하고 좌절하더라도 현실은 바뀌지 않기 때문에 다시 스타트업으로 이직을 준비하기 시작했다. 내가 그렇게 데이고도 스타트업을 선택한 이유가 뭐냐고 묻는다면 드라마에서나 볼법한 개발 문화에 대한 경험과 다시 한번 IT 프로덕트를 빌드해보고 싶다는 미련때문이라고 대답할 수 있을 것 같다.

하지만 이 선택도 마찬가지로 히스토리가 없는 코드들, 미흡한 문서화, 제한된 일정, 부족한 인력 등이 발목을 붙잡았지만 이러한 레거시 프로젝트를 관리하고 발전시키면서 이전에 생각했었던 개발자로서의 역활과 책임에 대해 생각이 많이 바뀌게 되었다. 이런 경험이 이글을 읽는 다른 주니어 개발자에게도 전달되면 좋을 것 같다는 생각에 글을 작성하게 되었다.

 

스타트업 입사할 때 생각하면 좋은 것들

입사해도 좋은 환경

• 성공적인 시장 검증으로 MVP 단계의 소프트웨어를 개발해야되는 경우
• MVP단계의 서비스가 잘 진행되어 고도화하기 위한 추가적인 개발 인력이 필요한 경우
• 스타트업에 있는 대부분의 인원이 초기부터 계속 같이 일하던 동료들인 경우
• 스타트업의 목표를 실현하는 과정이 구체적인지 실패했을 때의 계획은 어떻게 세웠는지? 

여기서 목표를 실현하는 과정이 구체적이라는 뜻은 이번달까지 MAU 10만, 신규 유저 10만의 목표로 구글 광고, 페이스북 광고, 바이럴 컨텐츠 기획등의 액션이 아니다. 예시로 OO서비스의 유저수를 늘리기위해 NN 플랫폼에 광고를 들어가게 된다면 건당 XX원만큼의 비용이 들어가게 된다. 평균 유저유입 비용 YY를 충족하려면 N%의 전환률을 유지해야된다고 가정하고 N일 동안 해당 전환률을 달성 못한다면 과감하게 다른 선택할 수 있는 판단을 하는 것처럼 구체적이여야 한다는 의미이다. 하지만 구체적인 과정을 계획하고 측정하면서 진행하는 것이 리소스를 많이 드는 일이고 빠르게 움직여야하는 스타트업에 맞지 않는 방식이라고 생각할 수 있다. 내가 스타트업을 경험하면서 느낀것은 흑백으로 명확하게 정할 수 있는 것보다 선택하기 어려운 회색지대가 더 많다는 것이다. 그래서 하나를 선택하려면 무엇을 버려야하는 판단을 해야하기에 측정하고 실현하는 과정을 구체화 시켜서 선택을 통해 무엇을 잃고 무엇을 얻는지 정확하게 알아야한다.

 

실패했을 때의 계획은 구체적일 필요는 없다. 지금 당장 세운 목표를 달성하기도 바쁜데 실패했을 때의 상황까지 생각한다면 이도저도 아니게 될 수 있기 때문이다. 그런데 왜 실패를 생각하는 스타트업이 좋은 환경이라고 생각한다고 이야기하냐고 묻는다면 아래와 같은 사진에 비유할 수 있을 것이다.

출처: 실리콘 벨리

소프트웨어 개발에 비유하자면 레거시가 방대해질 때 까지 품질을 제대로 관리하지못해 유지보수 비용이 새로 개발하는 것보다 큰 비용을 소모하는 프로그램을 예시로 들 수 있을 것 같다. 스타트업에서 우리의 가설이 충분히 입증될 것이라고 생각하고 열심히 달렸지만 실제 시장의 반응은 냉담할 수 있다. 이때 우리가 해야되는 선택은 좌절해야된는 시간에 소프트웨어 전체를 날릴 각오로 새로운 도전을 하는 선택밖에 없을 것이다. 그렇기 때문에 항상 실패한다는 생각을 가지고 임해야한다.

스타트업에서의 개발자의 자세

• A ~ Z 까지 알고 A ~ C 까지 고려한 개발을 하자
• 최대한 개발을 하지 않는다는 생각
• 프로덕트 중심 주의
• work life balance보다는 work life harmony를 추구하는 자세

A ~ Z 까지 알지만 A ~ C까지 고려하라는 의미는 처음부터 너무 많은 것을 고려한 디자인 패턴이나 OOP등의 클린 아키텍처 설계를 지양해야 된다는 의미이다. 이러한 패턴과 방법론이 나오게된 이유는 궁극적으로 유지보수 비용을 줄이고 기능의 변경이나 확장에 추가적으로 발생하는 리소스를 줄여 소프트웨어를 지속시키기 위해 나온 것이다. 이런 좋은 아키텍처와 설계가 과연 지금 필요한 상황의 이유가 될까? 라고 묻는다면 No라고 이야기 할 수 있을 것이다. 그렇다고 너무 앞만 본다면 고도화가 필요한 경우 큰 곤란을 겪게 될 가능성이 있기 때문에 세발자국 정도를 앞을 보고 설계한는 자세를 가지는 것이 좋다.

최대한 개발을 하지 않는다니? 개발자의 직무유기라고 생각하는 사람도 있을 것이다. 개발을 하지 않는다는 의미는 일을하지 말라는 의미가 아니라 개발을 최소화 할 수 있는 선택을 하라는 것이다. 우리가 많이 착각하는 것 중 하나가 개발자만 개발에 관여한다고 생각하지만 현실은 디자이너, 기획자, 개발자, 테스터, PM등 개발과 관련된 모든 인력이 배포될 때까지 계속 리소스를 들이게 된다. 예를 들어 고객과 이메일로 대응하면서 즉각적인 대응이 어렵다는 요구사항이 들어온다면 고객/문의 게시판을 개발하는 것보다는 카카오 채널이나 채널톡등과 같은 것들을 쓰는 활용하는 방법으로 해결하여 리소스가 최대한 덜 들이는 방향으로 간 다음 남은 리소스를 핵심 비지니스에 좀 더 초점을 실을 수 있도록 해야한다.

출처 yes24

프로덕트 중심 주의! 최대한 개발을 하지 않는다는 생각이라는 자세와 반대되는 성격의 자세라서 매우 헷갈리는 부분 중 하나라고 생각한다. 고객이 정말 바라는 것이지만 개발 난이도가 높고 많은 일정을 요구하는 기능이라서 개발하기 어렵다고 이야기 한다면 어떤 자세에 좀 더 초점을 맞춰야할까 딜레마가 올 것이다. 이러한 딜레마를 해결하기 위해서 규칙을 정하고 실행에 옮기는 것을 추천한다

나의 딜레마를 해결하는 규칙은 아래와 같다.

1. 니즈가 확실한지 검증하는 절차를 밟고 진행한다.
2. 개발하면서 발생하는 리스크보다 실행으로 통해 발생하는 이익이 더 큰지 비교해본다.
3. 최소한의 단계만 구현후 고도화 하거나 좀 더 쉽게 풀어낼 수 있는 방법을 모색해본다.

예시로는 검색 기능이 필요하다고 판단된다면 바로 검색 엔진을 개발하는 것 보다 SQL의 LIKE를 통해 검색 기능을 만들고 유저들의 반응을 살펴 본 후 검색엔진으로 고도화 시키는 방법으로 간단한 단계로 검증 후 구현하는 방식이다.

 

첫번째 스타트업에서 후회하는 것중 하나는 재택근무와 회사에서 지금 필요한 기술보다  내가 중요하다고 생각하는 기술을 먼저 공부했다는 것이다. 그렇게 생각하게 되면서 회사 업무가 나의 성장을 발목잡는 요소라 생각하였고 쉬는 순간에도 편히 쉬지 못하고  업무하는데에서는 큰 스트레스를 받으면서 진행했기에 퇴근하고 지쳐서 뻗기 일쑤였다. 아마존의 제프 베이조스 또한 "워라벨은 서로 한쪽을 희생하는 거래관계로 이루어지기 때문에 사람을 지치게 만든다. 일과 삶은 서로 공생하는 조화를 이루어야 한다"라고 이야기한 만큼 일할 때나 일이 끝나고 나서도 편한 마음을 지속하고 싶다면 우리가 가져야할 중요한 자세 중 하나라고 생각한다. 

 

나중에 일을 생각하는 방법을 바꿈으로써 나 스스로가 받는 스트레스를 줄일 수 있었고 주변 사람들로 부터 인정받을 수 있었던 것 같다. 여기서 365일 24시간 일만 생각하라는 것으로 오해할 수 있는데 그런 것이 아니라 '우리가 밥먹을 때 오늘 뭘 먹지?', '몇시에 먹을까?', '밥먹고 산책이나 할까?' 처럼 '일도 아 이문제 어떻게 푸는게 효율적일까?', '아 일하면서 이렇게하는 거 너무 비효율적인데 어떻하지?', '일하는데 이런 새로운 개념을 찾았는데 나중에 글이나 써봐야겠다'와 같이 삶에 녹아들 수 있도록 하는 것이 중요한 것 같다.

 

스타트업에서의 성장

흔히들 이야기하는 성장은 개인의 몫이고 성장할 환경을 제공해주는 것은 회사의 몫이라는 이야기를 하는데 나의 두번째 스타트업이 해당 이야기와 매우 밀접하다고 할 수 있을 것 같다. 두번째 스타트업은 여느 스타트업과 마찬가지로 문서, 코드 히스토리들은 없었고 레거시들과 안티패턴들이 가득했었지만 길게 늘어져 있는 로드맵도 무시할 수 없었기에 일단 로드맵을 우선적으로 진행하면서 점진적으로 개선해나갔다. 여기서 부족했던 부분을 메꾸기 위해 스터디도 참여하고 강의와 책도 읽고 참조하면서 개선했던 기억이 있다. 그후 이제 프로덕트도 어느정도 안정화 되었고 성장도 했기 때문에 더 큰 성장을 위해서는 회사에 리드급 엔지니어를 뽑아서 매니징을 할 수 있는 분이 필요할 것 같다고 요청했었다. 

 

하지만 회사의 입장에서는 지금 시니어 엔지니어를 뽑기에는 프로덕트에서 수익을 내고 있지 않은 것과 프로덕트가 원하는 수준만큼 도달하지 못했기 때문에 미들급 엔지니어는 충원하겠지만 시니어 급은 어려울 것 같다고 말씀을 해주셨다. 여기서 나는 여기서 좀 더 프로덕트를 디벨롭할 것인지 아니면 좀 더 규모있는 회사로 이직해서 성장할 수 있는 환경으로 갈지 고민해야 했었고 아쉽지만 결국은 후자를 선택하기로 했다. 

 

이직을 선택한 이유

• 미들급 엔지니어 인력이 충원되어도 내가 원하는 만큼의 성장할 수 있는 것이 불확실했다.
• 현재 나의 커리어가 중요한 시점이기 때문에 더 많은 시간을 투자하기에는 리스크가 너무 컸다.
• 프로덕트가 성장하고 개발팀이 확장할 것이라는 근거들이 부족했고 내게 확신을 주지 못했다.
• 데이터 컬처와도 거리가 먼 환경과 수 많은 업무 환경 개선의 시도들의 실패.

회사에서의 성장할 수 있는 환경은 도서나 강의 비용등을 제공하는 것이 아니라 회사 자체적으로 성장하고 싶은 성장할 수 있는 문화를 만드는 것이 성장할 수 있는 환경이라고 생각한다. 아쉽지만 현재 회사가 지금 필요한 환경과 내가 나아가고자하는 방향이 불일치하였기에 어쩔 수 없이 이직이라는 선택을 하게되었다.

느낀점

https://www.mobiinside.co.kr/2021/08/24/job-change-fail/

또 스타트업을 갈 것이라고 묻는다면 예스이다. 하지만 다음은 코파운더로 들어가서 초기부터 같이 디벨롭하는 것보다 성공적인 디벨롭을 하고 현재 성장할 수 있는 환경을 조성해야되는 시점에  조인을 하고 싶다. 그때까지 충분한 역량과 경험을 갖출 수 있도록 성장하는 것이 지금 나의 가장 큰 목표라고 할 수 있을 것 같다. 스타트업을 다니면서 정말 육체적, 정신적으로도 힘들고 리스크도 큰 도전이였지만 리스크가 큰 만큼 그만큼의 성장을 한 것 같고 그리고 이런 날것의 경험은 안정적인 기업에서 근무하는 것과 다른 안목을 갖게 해주는 경험이였다. 지금 스타트업을 다니는 것을 생각하고 있다면 이글을 읽고 내가 경험했던 실수들을 하지 않았으면 하는 바램이다.