이 글은 흔한 스타트업 vs 대기업 장단점 비교가 아니다. 그런 건 검색하면 넘쳐난다. 나는 스타트업에서 일하고 있고, 대기업에 다니는 동기들이랑 정기적으로 만나면서 서로의 일상을 비교할 기회가 많다. 거기서 느낀 걸 구체적인 상황 위주로 쓴다.

미리 말하면, 어느 쪽이 더 좋다는 결론은 없다. 어느 쪽이 "지금의 나"한테 더 맞는가는 있을 수 있다.

월요일 아침 9시#

대기업에 다니는 동기 A의 월요일. 출근해서 메일을 확인한다. 지난 금요일에 올린 PR에 리뷰 코멘트가 3개 달려있다. 한 개는 시니어의 아키텍처 피드백, 한 개는 QA의 테스트 관련 질문, 한 개는 다른 팀 개발자의 API 호환성 확인 요청. 아침 10시에 스프린트 미팅이 있고, 오후에는 기획자와 디자이너와의 회의. 이번 스프린트에서 맡은 건 결제 플로우의 특정 에러 처리 로직 개선. 전체 결제 시스템 중 일부분이다.

스타트업에 다니는 나의 월요일. 출근해서(사실 재택이다) 슬랙을 열면 주말에 대표가 올린 메시지가 있다. "이번 주에 신규 기능 하나 출시하고 싶은데 가능한가요?" 기능 기획서는 노션에 반 페이지 정도 적혀있다. 디자인은 피그마에 러프하게 잡혀있고, 세부사항은 만들면서 결정해야 한다. 프론트엔드, API 연동, 배포까지 내가 한다. 코드 리뷰는 CTO한테 한 번 받는 정도.

이 두 월요일 중 어느 쪽이 좋냐는 취향의 문제다. 어떤 사람은 A의 월요일이 안정적이고 체계적이라 좋다고 느끼고, 어떤 사람은 내 월요일이 자유롭고 빠르다고 느낀다. 다만 내 월요일에는 "이 기능의 기획이 맞는지"부터 고민해야 하는 무게감이 있고, A의 월요일에는 "내가 맡은 부분이 전체 시스템에서 어떤 의미인지" 한눈에 안 보이는 갈증이 있다.

배포라는 행위#

이게 진짜 다르다.

스타트업에서 배포는 간단하다. main 브랜치에 머지하면 Vercel이나 자체 파이프라인을 통해 프로덕션에 반영된다. 급하면 핫픽스를 바로 올린다. 지난달에 사용자가 신고한 버그를 발견하고 15분 만에 수정해서 배포한 적이 있다. 이 속도감은 짜릿하다.

대기업은 다르다. 동기 B한테 들은 배포 프로세스. 코드 머지 후 QA 환경에 배포. QA팀 검증 (13일). 스테이징 환경 배포 후 추가 검증. 배포 승인 요청 (리드, 매니저, 필요시 보안팀). 정해진 배포 윈도우에 프로덕션 반영 (주 12회). 모니터링 기간.

같은 크기의 버그를 고치는 데 스타트업은 1시간, 대기업은 1주일이 걸릴 수 있다. 근데 대기업의 이 프로세스가 존재하는 이유가 있다. 사용자가 수천만 명이니까. 배포 하나가 잘못되면 장애의 영향 범위가 어마어마하다. 스타트업은 사용자가 수백 명이니까 뭔가 터져도 빠르게 롤백하면 된다.

Pragmatic Engineer의 Gergely Orosz가 이런 맥락에서 흥미로운 이야기를 한다. 대기업의 프로세스가 엔지니어 개인에게는 답답할 수 있지만, 시스템의 안정성을 유지하기 위한 합리적인 트레이드오프라는 거다. 그리고 대기업에서 이 프로세스를 경험한 엔지니어가 스타트업으로 가면, "왜 이런 안전장치가 없지?"라고 느끼기도 한다고.

나도 겪었다. 핫픽스를 15분 만에 배포한 게 짜릿하다고 했는데, 그 핫픽스가 다른 버그를 만든 적이 한 번 있었다. 금요일 저녁이었고, 주말에 대표한테서 연락이 왔다. 프로세스가 없으면 빠르지만 위험하고, 프로세스가 있으면 안전하지만 느리다. 어느 쪽이든 댓가가 있다.

영향의 범위#

스타트업에서 내가 만든 기능이 다음 날 바로 사용자한테 도달한다. 내가 짠 코드가 매출에 직접적으로 영향을 준다. 지난번에 온보딩 플로우를 개선했더니 가입 전환율이 12% 올랐다. 이 숫자를 대표가 전체 슬랙 채널에 공유하면서 고맙다고 했다. 이 연결감이 스타트업의 가장 큰 매력이라고 생각한다.

대기업의 동기 C는 다른 종류의 영향을 경험한다. C가 속한 팀이 담당하는 API를 통해 하루에 수억 건의 요청이 처리된다. C가 작성한 코드가 직접적으로 만지는 범위는 전체 시스템의 작은 부분이지만, 그 부분이 수천만 사용자에게 닿는다. 규모의 임팩트.

이 차이는 이력서에도 반영된다. 스타트업 이력서에는 "결제 시스템 전체 설계 및 구현", "신규 서비스 0부터 출시"처럼 넓은 범위가 적힌다. 대기업 이력서에는 "일 1억 건 처리 시스템의 성능 30% 개선", "500명 규모 조직의 공통 라이브러리 유지보수"처럼 깊이와 규모가 적힌다.

어떤 이력서가 더 좋냐는, 다음에 가려는 곳이 어디냐에 따라 다르다.

기술적 성장의 방향#

스타트업에서 2년을 보내면서 배운 것들을 나열하면 이렇다. Next.js로 프로덕션 서비스 운영, 결제 연동, 인증 시스템 구축, 간단한 백엔드 API 작성, AWS 기본 인프라 관리, 그리고 약간의 데이터 분석. 넓다. 프론트엔드 개발자인데 백엔드도 치고 인프라도 만졌다. 뭐든 조금씩 할 수 있게 됐다.

대기업 동기들이 같은 기간 동안 배운 건 좀 다르다. 대규모 트래픽 처리 경험, 모니터링과 장애 대응 체계, 복잡한 레거시 코드 리팩토링, 팀 간 협업 프로세스, 기술 문서화, 코드 리뷰 문화. 깊다. 특정 영역에 대한 깊은 이해가 생겼다.

이걸 Pragmatic Engineer에서는 이렇게 설명한다. 스타트업은 breadth(폭)을 주고, 대기업은 depth(깊이)를 준다. 둘 다 필요한 건데, 동시에 얻기는 어렵다.

내 경우를 솔직하게 말하면, 넓게 배운 건 좋은데 어느 것도 깊지 않다는 불안이 있다. "프론트엔드 전문가"라고 하기엔 백엔드도 치느라 프론트엔드를 깊게 못 팠고, "풀스택"이라고 하기엔 각 영역이 얕다. 반대로 대기업 동기는 "프론트엔드 전문가"로서의 깊이는 있는데, "이 팀 밖에서도 할 수 있을까?"라는 불안을 갖고 있다.

연봉과 보상#

솔직한 부분. 기본 연봉만 보면 대기업이 높은 경우가 많다. 특히 한국에서는. 네이버, 카카오, 라인 같은 곳의 개발자 연봉은 같은 연차의 스타트업 개발자보다 높은 편이다.

스타트업은 스톡옵션이나 지분으로 보상하는 경우가 있다. "지금은 연봉이 낮지만 회사가 잘 되면 큰 보상이 돌아온다"는 구조. 솔직히 이 약속이 실현되는 확률은 높지 않다. 스타트업의 대다수는 실패하거나, 성공하더라도 스톡옵션의 가치가 기대만큼 크지 않은 경우가 많다.

그렇다고 스타트업이 재정적으로 무조건 불리한 건 아니다. 초기 멤버로 합류해서 회사가 성장하면, 연봉 인상 속도가 대기업보다 빠를 수 있다. 직급 체계가 유연하니까 능력에 따른 보상이 더 직접적이기도 하다. 근데 이건 "그 회사가 잘 되면"이라는 전제가 붙는다.

내 주변만 봐도, 스타트업에서 스톡옵션으로 큰 돈을 번 사람은 소수다. 반면 대기업에서 안정적인 연봉을 받으면서 꾸준히 저축하고 투자한 사람들은 확실한 자산을 쌓고 있다. 물론 이건 표본이 작아서 일반화하기 어렵다.

사내 정치와 문화#

스타트업에는 정치가 없다고 생각하면 오산이다. 10명짜리 회사에도 정치는 있다. 다만 형태가 다르다.

대기업의 정치는 구조적이다. 승진을 위한 가시성 확보, 팀 간 리소스 경쟁, 조직 개편에 따른 줄 서기. 시스템이 크니까 시스템 안에서의 위치가 중요하다. 동기 D가 한 말이 인상적이었다. "기술적으로 좋은 일을 해도, 윗사람한테 보이지 않으면 평가에 반영이 안 된다. 기술보다 보고 능력이 중요한 순간이 있다."

스타트업의 정치는 관계적이다. 대표와의 관계, 의사결정 과정에서의 발언권, 초기 멤버와 나중에 합류한 멤버 사이의 보이지 않는 위계. 조직이 작으니까 개인 간의 관계가 전체 분위기를 좌우한다. 대표와 사이가 좋으면 편하고, 안 좋으면 답이 없다. 대기업에서는 팀을 옮길 수 있지만, 10명짜리 스타트업에서는 피할 곳이 없다.

어느 쪽이든 정치를 완전히 피할 수는 없다. 다만 종류가 다르고, 본인이 어떤 종류의 스트레스에 더 강한지를 아는 게 도움이 된다.

워라밸이라는 환상#

대기업이 워라밸이 좋고 스타트업이 나쁘다는 건 반은 맞고 반은 틀리다.

대기업 중에도 야근이 일상인 곳이 있고, 스타트업 중에도 칼퇴하는 곳이 있다. 회사마다 다르고 팀마다 다르다. 다만 경향성은 있다.

대기업은 프로세스가 있으니까 일의 예측 가능성이 높다. 이번 스프린트에 할 일이 정해져 있고, 추가 요청이 들어오면 "다음 스프린트에 넣죠"라고 할 수 있다. 스타트업은 이런 경계가 모호하다. 대표가 "이번 주에 이것도 할 수 있나요?"라고 하면 거절하기 어렵다. 야근을 강요하는 게 아니라, 할 일이 많고 사람이 적으니까 자연스럽게 일이 늘어난다.

나는 이걸 "야근이 아니라 일을 많이 하는 것"이라고 표현하는 게 더 정확하다고 느낀다. 누가 시켜서 남아있는 게 아니라, 할 일이 남아있으니까 하게 되는 거다. 이게 어떤 사람한테는 보람이고, 어떤 사람한테는 착취다.

경력 3년차에서 보는 관점#

나는 프론트엔드 2년차다. 이 시점에서 스타트업과 대기업을 바라보는 내 관점은 이렇다.

지금 스타트업에서 얻고 있는 폭넓은 경험은 대체하기 어렵다. 회사 전체의 제품을 내가 만들고 있다는 감각, 내 코드가 매출에 직접 닿는 경험, 비개발 직군과 밀접하게 일하는 경험. 이건 대기업에서 주니어일 때 얻기 힘들다.

반면에 부족하다고 느끼는 것도 있다. 대규모 트래픽을 다뤄본 적이 없다. 체계적인 코드 리뷰 문화를 경험하지 못했다. 시니어 개발자한테 가까이서 배울 기회가 적다. CTO가 있지만, CTO도 바쁘니까 멘토링보다는 각자 알아서 하는 분위기다.

그래서 내 현재 결론은, 지금은 스타트업이 맞고 다음 직장에서는 다른 환경을 경험해도 좋겠다는 거다. 이건 일반적인 조언이 아니라 나한테 해당되는 판단이다. 시스템 설계나 대규모 서비스 운영에 관심이 많은 사람이라면 처음부터 대기업이 더 맞을 수 있다. 반대로 0에서 1을 만드는 게 좋은 사람이라면 스타트업이 계속 맞을 수 있다.

결국 "어디가 좋냐"는 질문보다 "지금 내가 뭘 배우고 싶냐"가 더 유효한 질문이다. 그리고 그 답은 시간이 지나면 바뀐다. 바뀌는 게 자연스러운 거다. 한 곳에서 평생을 보내야 한다는 강박 없이, 각 단계에서 가장 많이 배울 수 있는 곳을 고르면 된다.