1년 전에 내가 대학 등록을 취소하고 프런트 엔드 개발자 도구 공간에서 3인 스타트업에서 일할 것이라고 말했다면 나는 웃었을 것입니다.

지난 3개월은 제 사고방식을 완전히 바꿔 놓았습니다. 대기업 취업이 뭔지밖에 몰랐던 저는 스타트업을 주저하며 인턴십에 들어왔습니다. 아이디어 및 코드베이스 설정에서 배포 및 시장 진출에 이르기까지 내 회사를 시작하는 방법에 대한 명확한 청사진을 제시했습니다.

Vivid 팀이 그렇게 만들었습니다. 돌이켜보면 초기 단계의 신생 기업과 Big Tech 간의 몇 가지 주요 차이점이 모든 차이를 만들었습니다.

• 주목. Vivid에서는 제 학습에 큰 중점을 두었습니다. 작업하고 싶은 것을 선택하고, 질문하고, 배우고 싶은 모든 것에 대해 이야기하도록 격려받았습니다. 나는 Jorge가 어떻게 모노레포를 구성했는지에 관심이 있다고 언급했고, 다음날 우리는 Vite, Turborepo, pnpm 등의 기능에 대해 2시간 동안 토론했습니다. 이것이 Vivid 팀의 증거인 만큼 소규모 팀에서는 자연스럽게 관심이 쏠립니다. 내 일은 회사의 성공과 직결되어 있었기 때문에 내가 최선을 다할 수 있도록 돕는 것이 모든 사람에게 최선의 이익이었습니다.
• 배움의 폭. 초기 단계의 회사에는 구축할 확립된 코드베이스가 없습니다. 배포 스크립트 및 데이터베이스 연결 문자열과 같은 것을 당연하게 여기는 데 너무 익숙해졌는데 갑자기 이러한 것들을 설정해야 하는 사람이 되어야 한다는 것을 알게 되었습니다. 대기업에서는 하나의 주제를 매우 깊이 탐구하지만 스타트업에서는 제품의 모든 부분에 대해 발을 들여놓아야 합니다.
• 코드 품질. 스타트업은 일반적으로 나쁜 코드 품질로 평판이 나지만 Vivid에서는 확실히 그렇지 않았습니다. 수정을 위해 내 PR을 셀 수 없을 정도로 여러 번 되돌려 보내면서 모범 코드 사례에 대해 많은 것을 배웠습니다. 그 당시에는 고통스러웠지만 지금은 확실히 더 나은 엔지니어가 되었고 철저한 코드 검토의 중요성을 이해합니다.
• 재미있는! 마지막으로 Vivid에서의 인턴은 제가 직장에서 경험한 것 중 가장 즐거웠습니다. Aryaman, Jorge, Alberto는 첫 주부터 그렇게 여유로운 환경을 조성했고, 지금은 정말 좋은 친구들과 함께 해커톤 프로젝트를 진행하고 있는 것 같습니다. 다른 직장에서는 오후 5시에 퇴근하면 근질거릴 텐데 이곳에서는 언제까지나 남아서 일할 수 있어 행복합니다.

Aryaman, Jorge, Alberto를 만났던 동일한 WeWork 옥상에서 두 번째 런칭 파티를 하고 불과 몇 시간 거리에 이 게시물을 작성하면서 Vivid에 합류할 수 있는 빅 테크 제안이 있었으면 좋았을 것 같습니다. 대신 대학 4학년 때 컬럼비아로 돌아가서 네 명의 새로운 친구를 데리고 내가 배운 것을 가지고 무언가를 만들고 싶은 마음이 간절합니다.

선명한 입력

저는 Aryaman, Jorge, Alberto가 루프탑 WeWork 파티에서 Big Tech 일자리 제안을 거절했을 때 처음으로 직접 만났습니다. 그 전 주에 Aryaman과 간단한 커피 대화를 나눴을 뿐인데, 세 사람이 자신이 작업하고 있는 것에 대해 가지고 있는 흥분을 보는 것이 너무 상쾌하다고 생각했습니다.

저는 Microsoft 인턴십을 갓 마치고 여름에 Meta에서 인턴을 했습니다. 저는 Big Tech에서의 삶이 어떤 모습일지 잘 알고 있는 것 같았고, 싫지는 않았지만 스타트업에서 일하는 것이 어떨지 궁금하기도 했습니다. Vivid 팀이 내 신입생의 꿈의 제안을 포기하면서 기뻐하는 것을 보는 것은 모닝콜이었습니다. 내가 무엇을 놓치고 있는지 확인해야 했습니다.

한 달 후, 2023년 봄에 Vivid의 첫 인턴으로 합류하겠다는 제안서에 서명한 것은 놀라운 일이 아닙니다.

더 피벗

무엇을 기대해야 할지 모른 채 Vivid에서 첫 출근을 했습니다.

첫째 날, 저는 가장 큰 놀라움을 느꼈습니다. Vivid는 더 이상 Styler를 제작하지 않습니다. 불과 몇 달 전에 옥상에서 제게 시연했던 주력 제품입니다. 처음부터 회사를 구축한다는 것이 무엇을 의미하는지 직접 경험하게 되면서 매우 특별한 시기에 회사에 합류하게 되었다는 사실을 깨달았습니다.

팀이 회사의 새로운 방향을 생각해 내자 즉시 브레인스토밍 세션에 참여했습니다. 나는 아이디어가 떠돌아 다니는 속도를 빠르게 파악하고 한 아이디어를 다른 아이디어보다 더 좋게 만드는 요소를 흡수했습니다.

브레인스토밍 세션에서 얻은 몇 가지 주요 내용:

• 사람들이 정말 필요로 하는 제품을 만드는 것이 중요합니다 . 귀하의 도구가 팀의 모든 사람의 생산성을 10% 향상시키는지는 중요하지 않습니다. 어느 누구도 약간의 개선을 위해 현재 작업 흐름을 방해하려고 하지 않습니다. 오히려 200% 생산성 향상을 경험하는 엔지니어가 2~3명 있으면 도구가 훨씬 더 견고해집니다.
• 경쟁자는 아이디어를 실격시키지 않습니다. 아무리 작은 회사라도 나와 비슷한 아이디어로 작업을 시작했다면 나는 그것을 추구하지 말아야 한다고 생각했었다. 하지만 지금은 이 회사들이 해결해야 할 실제 문제가 있다는 증거로 존재한다고 봅니다.
• 장기적인 안목이 중요합니다. 나쁜 생각을 버리는 것도 마찬가지입니다. Vivid가 Styler를 버린다는 소식을 듣고 놀랐습니다. 사용자 입장에서는 탄탄한 활용 사례가 있는 잘 실행된 제품이라는 생각이 들었습니다. 이제 저는 Styler에 대한 예측 가능한 장기 목표가 없었고 피봇팅이 회사 성장에 필수적이라는 것을 이해합니다. 매몰 비용 오류에 관계없이 명확한 경로가 없는 아이디어에서 한 발짝 물러설 수 있어야 스타트업이 빠르게 움직일 수 있습니다.

아래는 Vivid 팀에 처음으로 기여한 코드의 이미지입니다!

Vivid에서 처음 2주가 끝날 무렵, React의 한 줄을 작성하는 방법을 몰랐던 상태에서 처음부터 페이지를 만들 수 있다는 자신감이 생겼습니다. 지난 12주간의 인턴십에서 얻은 것보다 더 많은 것을 배웠습니다.

생생한 동기화

내 인턴십의 두 번째 부분은 Vivid Sync에 의해 정의되었습니다. 우리는 이미 개발자에서 디자이너로 전달하는 데 상당한 마찰이 있다는 것을 알고 있었습니다. 그러나 고객과 통화하는 동안 한 엔지니어링 리더가 중요한 통찰력을 공유했습니다. 이 마찰에는 하나의 근본 원인이 있었습니다. 시간이 지남에 따라 Figma 라이브러리는 코드 리포지토리에서 벗어나기 시작하여 디자이너와 개발자 간에 일관된 잘못된 커뮤니케이션이 발생합니다.

아이디어를 처음 내놓은 지 일주일 만에 우리는 디자인 파트너를 확보하고 제품 구축을 시작했습니다. 기본적으로 Github Issues를 통해 Figma 구성 요소를 코드베이스에 연결하는 작업 관리 시스템이었습니다.

저는 다음과 같은 웹 UI를 구축하는 임무를 받았습니다.

그러나 다시 한 번 아이디어와 제품이 훌륭하다고 생각한 만큼 디자인 파트너에게 제품을 전달한 지 불과 일주일 만에 우리는 다시 처음부터 회의실로 돌아왔습니다.

브레인스토밍 Pt. 2

Vivid Sync에는 치명적인 결함이 있었습니다. 고객의 문제를 해결하지 못했습니다. 최종 사용자는 낭비되는 엔지니어링 시간을 제한하겠다는 약속에 동기를 부여받았습니다. Styler와 달리 Vivid Sync는 Figma와 Code 간에 종단 간 동기화를 생성하는 명확한 장기 비전을 가지고 있었지만 제공된 제품은 엔지니어의 시간을 절약하지 못했습니다. 유지 보수 작업을 위한 작업을 생성하여 작업합니다.

팀은 우리의 디자인 파트너를 위해 가능한 한 빨리 무엇인가를 구축하는 데 몰두했지만 돌이켜보면 처음부터 Sync의 즉각적인 부가 가치가 충분히 높지 않을 수 있다는 분명한 경고가 있었습니다.

이번에는 다가올 일에 대비했습니다. 아이디어 토론에 적극적으로 참여하는 것을 목표로 삼았습니다. 나는 가설 시트를 작성하는 방법, 경쟁적인 연구를 수행하는 방법, 특정 아이디어로 좁혀지는 발산적 사고의 썰물과 흐름을 관리하는 방법을 배웠습니다. 무엇보다 소규모 팀에서 내 의견이 얼마나 큰 영향을 미칠 수 있는지 배웠습니다.

Figma에서 코드로

내 GitHub 커밋 기록을 통해 우리가 아이디어를 구상하는 데 소요된 시간이 정확히 3주로 명확해졌습니다. 우리는 Figma 디자인을 사용 가능한 프런트엔드 코드로 변환하여 고객에게 최고의 가치를 제공하는 방향으로 바로 뛰어들기로 결정했습니다. 명확한 장기 비전이 있었고 우리는 최종 사용자의 고충을 직접 해결했으며 우리 모두는 훨씬 더 높은 수준의 확신을 가지고 있었습니다.

구축에 이르렀을 때 저는 신규 사용자 온보딩을 담당했습니다. 온보딩의 목표는 Vivid가 사용자의 코드베이스에 이미 있는 구성 요소를 사용하여 코드를 생성할 수 있도록 하는 것이었습니다.

핵심 기술 과제는 사용자의 코드 구성 요소를 가져오고 이를 해당 Figma 자산에 연결하여 Figma 자산이 사용될 때마다 코드에서 올바른 구성 요소를 호출할 수 있도록 하는 것이었습니다. 도구가 오류 없이 이러한 구성 요소를 호출할 수 있도록 구성 요소 속성도 일치해야 했습니다.

온보딩 기능에는 두 가지 다른 부분이 있습니다.

1. 깃허브 앱 . Github 앱은 리포지토리에 연결하고 REST API를 통해 연결된 리포지토리 내의 모든 .tsx 파일을 반환합니다.
2. 파이썬 마이크로서비스 . Flask로 구축된 Python 마이크로서비스는 NLP 일치 알고리즘을 사용하여 의미론적으로 코드 구성 요소를 Figma 구성 요소와 일치시킵니다.
3. 코드 순회 패키지 . 코드 순회 패키지를 사용하면 Github 앱과 Python 마이크로서비스를 함께 연결할 수 있습니다. Github 앱에서 .tsx 파일을 가져오고 Python 마이크로 서비스에서 일치하는 구성 요소를 반환했습니다.
4. 온보딩 매치 플랫폼. 마지막으로 UI를 통해 백엔드의 데이터베이스에 매치를 만들고 제출할 수 있었습니다.

재미있는 사진!