초기 스타트업에서 엔지니어로 일한다는 것은

들어가기 전에

이 글은 제가 작성한 것이 아닌, basecase captial의 창업자 Alana Goyal이 작성한 Demystifying the role of a founding engineer 라는 글의 번역본입니다. 실제로 제가 초기 스타트업에서 일하면서 겪었던 내용들을 거의 다 포함하고 있는 아주 좋은 글이어서 번역해보았습니다. 다만 아쉽게도 현재는 작성자가 글을 내려 더 이상 인터넷에서 찾아볼 수 없게 되었는데요. 제가 이 글을 읽고 번역해서 올려봐야겠다고 마음을 먹었던 때가 2022년 8월이었고, 그때 번역을 위해 복사했던 내용이 남아있어 그 글을 토대로 올려봅니다. 제가 작성한 글이 아니기 때문에 저작자의 요청이 있으면 언제든지 이 글도 없어질 수 있습니다. LLM 모델들이 번역에 도가 튼 2025년이지만, 이 번역본은 원문 내용과 함께 저의 경험과 주관을 담은 100% 손번역 버전입니다. 스타트업의 초기 엔지니어 (Founding Engineer) 뿐만 아니라, 스타트업에 재직하고 계신 모든 분께 도움이 될 만한 내용이라고 생각합니다. 혹은 이런 경제 혹한기에 스타트업으로 건너오시려는 분이라면 더더욱이요! 이 글을 통해 본인이 스타트업에 맞는지, 혹은 어쩌면 전혀 맞지 않는지 판단하실 수 있으리라 생각합니다.

초기 스타트업의 초기 엔지니어 (Founding Engineer) 로 일한다는 것은

지난 분기에 포트폴리오 회사들의 채용을 돕기 위해 114명의 엔지니어를 만나고, 그 중 86명을 투자사에 소개시켜주고, 최종적으로 6명 정도의 채용을 마무리하는 과정에서 스타트업에서 일하는 것은 어떤 건가요? 라는 질문을 수없이 받아왔습니다. 그중에서도 가장 답하기 어려웠던 것은 바로 스타트업에 합류한 초기 엔지니어 (Founding Engineer) 의 역할이 무엇인가에 대한 질문이었습니다.

스타트업의 초기 멤버 혹은 초기 엔지니어로 합류하는 일은 짜릿하고, 도전적이며, 큰 보상을 얻을 수 있는 경험입니다. 그러나 초기 스타트업에서 엔지니어가 어떤 업무를 담당해야 하는지 명확히 정의한 회사는 거의 없고, 이런 모호함과 신비로움은 유능한 엔지니어가 초기 스타트업에 합류하겠다는 결정을 내리기 어렵게 만듭니다. 특히, 체계가 잘 갖춰진 대기업에서 초기 스타트업으로 오려는 분에겐 더욱 치명적이죠. 그래서 이 글에서 스타트업의 초기 엔지니어란 무엇이고, 어떤 역할을 하는지, 그리고 어떤 역량을 가지고 있으면 초기 스타트업에서 일하는데 도움이 되는지, 초기 스타트업 이후의 커리어 패스에 대해 몇 개의 실제 사례와 함께 설명드리려고 합니다.

스타트업의 초기 엔지니어 (Founding Engineer) 란?

초기 엔지니어의 역할에 대해 명확히 정의하기 위해 실제로 초기 스타트업에서 일하고 있는 엔지니어들에게 직접 물어봤습니다. 그리고 아래와 같이 꽤 일관성있는 답변들을 얻었습니다:

“스타트업의 초기 엔지니어는 회사의 엔지니어링 팀의 기술적, 문화적 토대를 만드는 사람입니다. 또한 다음에는 어떤 사람을 채용해야 하는지에 대한 기준도 세우죠. 그리고 초기 엔지니어는 체계적이지 않은 환경에서 여러 역할을 맡는 (wearing multiple hats) 것에 익숙합니다. (예를 들어 프론트엔드, 백엔드, DevOps, 고객 지원을 동시에!) 그러므로 초기 엔지니어가 되기 가장 적합한 사람은 사실 창업자의 역량을 가진 사람이죠.” - Shin Kim (Eraser)

“초기 엔지니어는 엔지니어링 팀의 토대를 만드는 사람입니다. 토대를 만드는 것이란, 제품의 핵심 아키텍쳐를 설계하고 적용하며, 팀의 문화를 만들어나가는 사람이죠. 동시에 제품의 품질과 출시 속도 사이에서 끊임없이 고민하면서, 좋은 채용 절차도 만들어가야 합니다.” - Gabriel Spencer-Harper (Meticulous)

“스타트업의 이상적인 초기 엔지니어는 의견이 분명하고, 독립적으로 일할 수 있으며 동시에 다른 동료들의 결정을 존중하고, 아주 빠르게 변화하는 환경에서 계속 적응하며 일할 수 있는 엔지니어입니다. 초기 엔지니어는 팀을 만들고, 이끌 수 있어야하며 동시에 복잡한 제품의 어려운 기술적 결정을 내릴 수 있어야 합니다.” - Nico Ferreyra (Default)

위의 답변들에서 볼 수 있듯이 초기 엔지니어는 회사의 기술적, 문화적인 토대를 만드는 사람들입니다. 회사마다 조금씩 다르긴 하지만 보통 초기 엔지니어는 회사가 생긴지 1년 이내에 채용되는 1-3번째 엔지니어들이죠. 서론이 길었으니 초기 엔지니어의 역할에 대해 더 자세히 얘기해보겠습니다.

초기 엔지니어 (Founding Engineer) 의 역할

엔지니어링

당연하게도 초기 엔지니어는 코드를 작성할 줄 알아야 합니다. 아주 많은 코드를 빠르게요. 제품 출시 일정이 다가올수록 초기 엔지니어의 역할이 더 중요해지는데, 제품의 출시 일정을 어떻게든 준수해서 고객들이 제품의 다양한 기능을 한 개라도 더 많이, 빨리 써볼 수 있도록 만들어야 하기 때문입니다. 동시에 초기 엔지니어들은 제품에서 적어도 몇 년간은 사용될 핵심적인 아키텍쳐를 설계하고 결정해야 합니다. 이 과정에서 제품의 개발 속도와 코드 품질도 동시에 신경써야하죠. 진짜로요. (역주: 스타트업에서는 흔히 개발 일정을 준수하겠다고 품질과는 매우 거리가 먼 스파게티가 등장하곤 합니다. 이 글에서는 그러한 종류의 잘못된 선택이 아닌, 진짜 품질과 속도 사이의 균형을 이야기한다고 생각합니다) 때로는 기술 부채를 만들면서 개발 속도를 올려야할 때도 있고, 반대로 어떤 모듈은 일주일을 써서라도 높은 수준의 코드 품질을 쟁취해야할 때가 있는데, 이런 경우에는 왜 이 코드는 시간을 많이 들여 개발해야 하는지에 대한 설명과 설득도 잘 할 수 있어야 합니다. 또한 초기 엔지니어는 제품 배포와 관련된 지식 (주로 DevOps 지식) 에도 능통해야 합니다. 왜냐면 제품을 처음부터 끝까지 만들어야하고, 개발 사이클과 배포 사이클을 구성해야하며, 배포된 이후에는 제품이 안정적으로 돌아가는지, 성능 문제는 없는지 계속 살펴볼 수 있어야 하기 때문이죠.

제품 기획

초기 엔지니어는 개발 뿐만 아니라, 초기 제품의 기획이나 방향성에 대해서도 많은 고민을 기울여야 합니다. 그러기 위해서는 제품의 잠재적인 고객들과 대화도 나눠야하고, 제품의 사용 사례 분석 및 실제 테스트도 해봐야하며, 수없이 많은 좋아보이는 기능들 속에서 어떤 것이 가장 빠르게, 혹은 늦게 개발되어야 하는지에 대한 우선순위를 정할 수 있어야 합니다. 많은 경우 초기 엔지니어는 정석적인 요구사항 문서나 스펙이 없는 채로 제품을 개발하게 됩니다. 이런 일에 당황하면 안 됩니다. 이미 현실 사례 중 Stripe (미국의 핀테크 회사) 가 창업 후 몇 년간 엔지니어들이 직접 제품을 관리하게 만든 사례가 유명합니다. 프로덕트 디자이너를 채용하기 전까지, 초기 엔지니어가 피그마에 들어가서 모든 파일을 헤집고 다니는 게 어색한 일이 되어선 안 됩니다.

고객 지원

초기 엔지니어는 다른 일을 하면서 동시에 제품의 고객들을 지원하는 데도 꽤 많은 시간을 써야합니다. 정신을 차려보면 이미 고객사 Slack의 공유 채널이나 Discord 서버, 혹은 트위터에서 고객들의 질문에 답변하고, 버그와 피드백을 수집하고 있을 거예요. 또한 24/7 울리는 PagerDuty 알림 소리에도 이미 적응이 완료된 상태일 겁니다. 장애를 해소하는 것 이외에도 초기 엔지니어는 제품의 전체 모니터링과 상태를 확인할 수 있는 인프라를 구축하고, 고객 지원 (CS) 프로세스와 on-call 프로세스를 수립할 수 있어야 합니다.

인사 (People)

또한 초기 엔지니어는 채용과 회사의 문화 설정에도 기여해야 합니다. 초기 엔지니어는 보통 팀원 발굴, 면접, 연봉 협상 등 초기 멤버를 채용하기 위한 모든 일에 투입됩니다. 그리고 그런 동료들과 소소하게는 “점심 뭐 먹을까요?”, “팀 워크샵 활동으론 뭐가 좋을까요?” 부터 “면접 프로세스는 어떻게 운영할까요?”, “우리 회사에서 의사 결정은 어떤 방식으로 이루어져야 할까요?” 처럼 큰 결정까지도 내릴 수 있어야 합니다. 초기 엔지니어는 동료들의 여러 질문에 매일 답변해야할 책임이 있습니다. 답변은 말로 직접 할 수도, 혹은 간접적인 행동과 태도로 보여줘야 할 수도 있습니다.

사업

마지막으로 초기 엔지니어는 사업의 모든 측면에 노출됩니다. IR, 세일즈, 어떤 것이든 될 수 있죠. 물론 초기 엔지니어가 직접 투자 유치를 마무리하거나 발표 자료를 만들진 않습니다. 하지만 누구에게든 회사의 제품과 비전에 대해 자신있게 말할 수 있어야 합니다. 초기 엔지니어는 창업자가 제품을 시장에 출시하기 위한 모든 일을 도와주어야 합니다. 또한, 뛰어난 초기 엔지니어는 “좋은 연락” 을 잘 하는 사람입니다. 전 직장 동료들, 학교 동기들, 친구들을 잠재 고객으로, 투자자로, 혹은 동료로 만들기 위해서요. 많은 역할 중 이것이 초기 엔지니어의 가장 짜릿한 역할입니다. 이 지점까지 오면 엔지니어가 가진 역량 이상의 것에 노출되고, 심지어 해내야하기 때문이죠. 초기 엔지니어로서 이러한 일이 매일 일어나는 곳에 존재하는 것만으로도 많은 것을 배울 수 있게 됩니다.

무엇이 뛰어난 초기 엔지니어 (Founding Engineer) 를 만드는가?

초기 엔지니어라는 포지션은 누구에게나 적합한 포지션이 아닙니다. 이런 역할에 어울리는 특정한 종류의 사람에게만 어울리는 역할이죠. 초기 엔지니어는 기술적으로 아주 특출나야하며, 심지어 다른 영역에서도 뛰어난 성과를 낼 수 있을만큼 다재다능해야 합니다. 초기 엔지니어는 다양한 경험을 가진 사람들이 될 수 있지만, 그들이 공통적으로 가지면 좋을만한 특징은 아래와 같습니다.

풍부한 경험

컴퓨터 공학 학위 소지자가 모두 뛰어난 소프트웨어 엔지니어가 되지 않는다는 것을 이제 우리 모두가 알고 있습니다. 배움의 많은 부분은 학교가 아닌 실무에서 이루어집니다. 이런 이유로, 뛰어난 초기 엔지니어는 적어도 2년에서 4년 (사람에 따라 5년에서 10년) 정도의 소프트웨어 엔지니어 경험이 있는 사람입니다. 물론, 이러한 경험은 다른 방식으로도 축적될 수 있습니다. 예를 들어 중학생 때부터 다양한 사이드 프로젝트나 오픈 소스 프로젝트에 참여했다거나, 고등학생 때부터 IT 기업에서 인턴을 했다거나 하는 방식으로요. 인생의 어느 시기에, 어떤 식으로 경험을 쌓았던지에 상관없이 뛰어난 초기 엔지니어들은 자신있게 모호한 문제를 해결하며, 대규모 시스템을 구축하고, 성능과 안정성, 품질 높은 코드 세 가지를 모두 챙길 수 있어야 합니다.

주인의식

뛰어난 초기 엔지니어는 주인의식을 갈망합니다. 단순 업무 뿐만 아니라, 사내 해커톤이나 신규 입사자 적응 프로그램, 혹은 아무도 건드리지 않는 사내의 기술 부채를 처음부터 끝까지 청산하는 역할도 맡곤 하죠. 회사의 어떤 일이든 스스로 자원해서 처음부터 끝까지 마무리하는 것을 즐기는 사람이라면, 초기 엔지니어가 될 자질이 충분할 뿐만 아니라 업무에서 즐거움도 느낄 수 있을 겁니다.

모호함도 괜찮아요

뛰어난 초기 엔지니어는 모호함에 익숙할 뿐만 아니라, 편안함마저 느낍니다. 스타트업의 제품은 요구사항이나 디자인이 명확하지 않고, 무엇을 만들지조차 잘 정의되지 않은 경우가 많습니다. 당연하게도 어떤 기술이나 언어로 만들어야 하는지도 정의되어있지 않죠. 뛰어난 초기 엔지니어는 이런 모호함 속에서도 언제, 무엇을 질문해야 가장 효율적일지 알며, 반대로 어떨 때는 질문 대신 합리적인 가정을 바탕으로 제품을 만들어야 하는지 잘 알고 있습니다. 잘 정의되지 않은 프로젝트를 구체화하는 능력이 있다면, 초기 엔지니어와 잘 맞을 확률이 높습니다.

다재다능

위에서도 언급되긴 했지만, 뛰어난 초기 엔지니어는 여러 역할을 맡는 (wearing multiple hats) 데 익숙해야 합니다. 하루 단위, 심지어 시간 단위로 이루어지는 많은 양의 context switching에 능숙해야합니다. 어떤 날에는 몇 시간의 프로그래밍 후 몇 건의 고객 인터뷰를 처리하고, 마지막으로는 기술적 브레인스토밍이나 아키텍쳐 회의까지 처리해야하죠. 회사의 사업 영역에 따라, 초기 엔지니어의 역할은 엔지니어에서 더 멀어질 수도 있습니다. 예를 들어 Scale AI에서는 초기 엔지니어들이 몇날 며칠을 사람들에게 데이터 라벨링을 교육하는데 소비했습니다. 이런 류의 다양함을 즐기는 사람이라면, 초기 엔지니어가 되어서 심심할 날은 없을 것입니다.

빠른 일처리

마지막으로, 뛰어난 초기 엔지니어는 다른 사람보다 훨씬 빨리 일합니다. 많은 창업가들은 특출난 직원들에게도 1인분이 아닌 3인분을 해내라고 이야기합니다. 뛰어난 초기 엔지니어는 창업자들의 이런 이야기를 오히려 환영하며, 살인적인 기한을 지켜야한다는 압박 속에서도 늘 해냅니다. 뛰어난 코드를 작성 즉시 배포해서 제품이 변화하는 것을 보고 싶은 엔지니어라면, 뛰어난 초기 엔지니어가 되었을 때 기쁘게 일할 수 있다는 증거입니다.

위의 다섯 가지 자질을 당장 갖고 있지 않더라도, 엔지니어들이 현재 자신의 역할을 어떻게 느끼고 있는지 스스로를 돌아보는 것은 아주 좋은 경험입니다. 만약 다음에 무엇을 해야할지 확실하게 느껴지지 않는다면, 위에 열거된 자질을 키우는 방향으로 일을 해봐야하는 것이 아닐지 스스로를 점검하고 되물어보세요. 만약 여러분이 초기 스타트업의 엔지니어가 되고 싶다면, 여러 경험들 속에서 위의 자질이 길러졌는지 점검해보는 것도 좋은 방법입니다.

초기 엔지니어 (Founding Engineer) 의 미래 커리어 패스는?

초기 엔지니어는 수많은 역할을 수행할 수 있는 엔지니어이므로, 이들의 미래 커리어 또한 다양한 방향으로 펼쳐질 수 있습니다.

창업자 (Founder)

많은 초기 엔지니어들은 결국 자기 회사를 차리러 갑니다. 창업가가 되기 위해서 준비해야할 것은 어떤 방식으로든 준비할 수 없는 경우가 많습니다. 그나마 스타트업의 초기 엔지니어로 합류하는 것이 창업자가 되기 위한 가장 밀접한 경험을 줄 수 있습니다. 초기 엔지니어가 되어 제품을 처음부터 끝까지 직접 만들고, 함께할 동료들을 모으고, 첫 번째 고객을 찾는 일과 동시에 초기 엔지니어는 창업자와 직접적으로 교류하며 많은 것을 배울 수 있습니다. 뛰어난 초기 엔지니어는 창업자가 어떤 영역에서는 뛰어나고, 어떤 영역은 취약한지 빠르게 알아내어 이러한 경험을 추후에 직접 창업할 때의 교훈으로 삼아냅니다. 초기 엔지니어로의 경험을 갈고 닦아 창업자가 된 경우는 꽤 많습니다. basecase (글쓴이가 일하는 VC) 의 경우만 보더라도, BaseTen의 공동 창업자 두 명은 이전에 Gumroad의 초기 엔지니어였습니다. Supergrain의 창업자는 Vurb의 초기 엔지니어였습니다. 그 외에도 Replit의 창업자는 Codeacademy의 초기 엔지니어였고, Gumroad의 창업자는 Pinterest의 초기 엔지니어였고, OpenAI의 공동창업자 Greg Brockman 또한 Stripe의 초기 엔지니어였습니다.

엔지니어링 리더 (CTO or VPE)

뛰어난 초기 엔지니어들이 엔지니어링 리더십 포지션으로 승진하는 일은 꽤 흔한 일입니다. 특히 빠르게 성장하는 스타트업이라면 더더욱 그렇죠. 기술적인 문제를 해결하는 것을 즐기는 초기 엔지니어는 CTO의 길로, 인사 관리나 멘토링에 관심이 있는 초기 엔지니어는 VPE로 성장할 수 있죠. basecase 포트폴리오사 중 하나 예시를 들어보자면, Bigeye의 Director of Engineering인 AJ Ribeiro는 원래 초기 엔지니어 중 한 명이었습니다.

Individual Contributer (Staff Engineer or Chief Architect)

회사의 규모가 확장됨에 따라, 제품이 풀고자 하는 문제를 기술적으로 가장 뾰족하게, 동시에 확장성있게 풀어낼 엔지니어를 찾아내는 것은 무엇보다도 중요한 일이 됩니다. 이런 역할을 맡을 사람을 찾을 수 있는 가장 좋은 방법은 바로 초기 엔지니어 중 한 명을 살펴보는 것입니다. 초기 엔지니어는 방대한 기술적 지식과 제품에 대한 지식, 역량을 모두 동원하여 회사의 핵심 인재가 되곤 합니다. 직급으로는 Staff Engineer나 Chief Architect로 부를 수 있죠. 프로그래밍을 사랑하고, 다른 사람의 지시 없이 자율적으로 행동할 수 있으며, 매일매일 가장 어려운 기술적 문제를 푸는 걸 즐기는 엔지니어들은 뛰어난 IC가 될 수 있습니다. 예를 들어, HashiCorp의 전 창업자이자 CEO, CTO였던 Mitchell Hashimoto는 CEO를 4년 간 맡고, 그 이후 CTO를 5년 간 맡은 다음 다시 IC로 돌아갔습니다.

Product Manager

초기 엔지니어들이 고객과 좀 더 가까워지는 Product Manager가 되는 것도 흔한 일입니다. 초기 엔지니어의 제품 이해도와 고객 이해도를 합치면, 초기 엔지니어는 제품팀의 유력한 첫 번째 채용 후보자가 될 수 있습니다. 한 가지 예로, Scale AI의 초기 엔지니어인 Leigh Marie Braswell은 입사 후 첫 번째 Product Manager로 역할을 변경했습니다. 그가 초기 엔지니어로 일할 때, 점점 제품 자체에 빠져드는 자기 자신을 발견했고, 그리고 그런 제품을 기획하는 것이 그가 진정으로 원하는 것이란 걸 깨달았기 때문이죠.

Venture Capitalist (VC)

위에 나열된 커리어 패스 중 가장 적은 확률이긴 하지만, 초기 엔지니어는 뛰어난 벤처 투자자나 엔젤 투자자가 되기도 합니다. 초기 엔지니어는 동료들을 통해 거대한 인적 네트워크를 만들어내기도 합니다. 보통 어떤 회사의 마피아 라고 부르는 그것이죠. (역주: 페이팔 마피아, 첫눈 마피아 등) 초기 엔지니어가 매일매일 새로운 제품을 시도해보고, 고객들과 만나본 경험은 이들이 벤처 투자자가 되었을 때 큰 도움이 되며, 이를 통해 꽤나 고품질의 투자나 인수 건을 만들어낼 수 있습니다. 게다가, 초기 엔지니어 출신 벤처 투자자는 창업자에게 여러 조언을 제공해 투자사가 PMF을 찾는 과정을 돕고, 초기 엔지니어를 채용하는 과정을 도와줄 수 있죠. 위에서 등장했던, Scale AI의 초기 엔지니어면서 Product Manager가 되었던 Leigh Marie는 그 후 엔젤 투자를 시작했고, 결국 Founders Fund에 합류하기도 했습니다.

초기 엔지니어로서 쌓았던 경험은 추후에 어떤 포지션이 되고 싶은지 명확히 정했는지, 정하지 않았는지와 상관없이 다양한 방식으로 경력과 경험을 가속화하는 데 필요한 기술과 경험을 제공할 수 있습니다.

마치며

스타트업의 초기 엔지니어로 합류하는 것은 확실히 특별한 경험입니다. 창업 이전에 초기 회사 경험이 필요해서 합류했든, 엔지니어링 이외의 일까지 해보고 싶어 합류했든, 아니면 그저 잘 될 것같은 스타트업의 로켓에 올라타고 싶어 합류한 것이든, 초기 엔지니어들이 특별한 경험을 하고 있다는 건 변함없는 사실입니다. 이 글을 읽은 여러분이 스타트업에 합류한 사람일 수도, 아닐 수도 있지만 그러한 결정과 역할을 수행하는 데 있어 약간의 통찰을 제공하길 바라며, 여러분의 생각이 정리되는 데 도움을 주길 바랍니다.

(역주) 글을 재밌게 읽으신 소프트웨어 엔지니어 중에 스타트업에서 치열하게 일해보고 싶은 분이 계신가요? zephtys123@gmail.com 으로 간단한 자기소개를 보내주세요. 어쩌면 맞는 자리가 있을 수도 있어요!