스타트업에서의 첫 한 달은 강렬한 인상을 남깁니다. 천천히 적응할 시간도, IT 부서에서 노트북을 준비해 줄 때까지 오리엔테이션 영상을 보며 기다리는 일주일도 없습니다. 첫날부터 당신은 실제 사람들이 사용할 무언가를 만들고, 망가뜨리고, 다시 고쳐내야 합니다. 구직자들이 지원 현황을 정리할 수 있도록 돕는 도구를 만드는 회사인 Treevah에 합류한 후, 저는 이 사실을 빠르게 깨달았습니다. 초기 단계의 환경에서 보낸 30일은 그 어떤 강의실이나 대회보다 소프트웨어 개발에 대해 더 많은 것을 가르쳐 주었습니다.

쉼 없이 몰아치는 리듬

Treevah에서 업무는 당신이 적응할 때까지 기다려 주지 않습니다. 팀은 제품을 알파 단계에서 베타로, 그리고 최종적으로 프로덕션 단계로 넘기기 위해 박차를 가하고 있으며, 이는 모든 작업이 무게감을 갖는다는 것을 의미합니다. 교수님의 편지함에 넣어두고 잊어버릴 만한 임시 작업이나 과제 같은 것은 끼어들 자리가 없습니다. 기능을 배포하면, 다음 직장을 찾는 동안 마감 기한, 인터뷰, 후속 조치 등을 관리하려는 실제 사용자들에게 즉시 전달됩니다.

속도는 지칠 정도로 빠릅니다. 매일 빠르게 움직여야 하며, 업무량은 예상보다 훨씬 빠르게 쌓입니다. 마감 기한은 추상적인 개념이 아닙니다. 회사가 더 많은 구직자에게 서비스를 제공할 수 있을지, 아니면 현재 경험의 결함을 수정할 수 있을지를 결정하는 마일스톤과 직결되어 있습니다. 그 중압감은 사람을 지치게 합니다. 하지만 동시에 대기업에서는 찾기 힘든 명확함을 만들어내기도 합니다. 작업을 마치면, 내가 만든 것이 구직 활동을 더 쉽게 관리할 수 있게 된 누군가에게 어떻게 연결되는지 그 선을 명확히 그릴 수 있습니다. 이러한 주인의식은 흔치 않으며, 그 덕분에 피로조차 가치 있게 느껴집니다.

프로덕션 환경에서 더 빠르게 쌓이는 기술

이번 여름 전까지 제 에너지의 상당 부분은 대중 연설과 해커톤에 쏟아졌습니다. 두 활동 모두 압박감 속에서 즉각적으로 생각하고 아이디어를 발표하는 법을 가르쳐 주었습니다. 특히 해커톤은 몇 시간 만에 작동하는 데모를 뚝딱 만들어내는 훈련을 시켜줍니다. 하지만 심사위원에게 깊은 인상을 남기는 주말 프로젝트와, 수백 명의 실제 사용자와 맞닥뜨려 살아남아야 하는 프로덕션 코드 사이에는 분명한 차이가 있습니다.

Treevah에서 한 달 동안 웹 개발에 집중하며 그 간극을 메울 수 있었습니다. 학교 프로젝트에는 가드레일이 있습니다. 범위가 정해져 있고, 요구사항은 친절하게 제공되며, 데이터베이스 스키마가 무너지더라도 발표 슬라이드에서 적당히 설명하고 넘어갈 수 있습니다. 하지만 스타트업 내부에서는 실제 구직자들이 실제 지원 데이터를 저장하기 때문에 스키마가 반드시 견고해야 합니다. 피드백 루프는 즉각적이고 냉혹합니다. 페이지 로딩이 느려지거나 양식 저장이 실패하면, 아무도 당신의 성적에는 관심이 없습니다. 그들은 단지 소중한 기회를 놓치게 되었는지에만 관심이 있을 뿐입니다.

그러한 압박은 성장을 강제합니다. 평가 기준이 요구해서가 아니라, 한밤중에 직접 디버깅해야 하는 사람이 바로 자신이기 때문에 더 깔끔한 코드를 작성하는 법을 배우게 됩니다. 코드 리뷰 중에 더 날카로운 질문을 던지는 법을 배우게 되는데, 이는 망가진 빌드를 배포하는 것이 실제 사용자가 벽에 부딪히는 것을 의미하기 때문입니다. 이곳에서의 기회는 학교 프로젝트보다 훨씬 더 강력하게 다가옵니다. 실수의 대가가 더 크기 때문에 교훈도 더 깊이 남습니다.

버그가 일깨워주는 겸손한 현실

제가 타파하고 싶은 통념이 하나 있다면, 모든 소프트웨어 버그가 극적인 논리적 실패라는 생각입니다. 물론 그런 경우도 있습니다. 하지만 Treevah에서 마주한 많은 버그는 미칠 듯이 사소한 것들이었습니다. 그것들은 눈에 잘 띄는 곳에 숨어 제 인생의 수많은 시간을 낭비하게 만들었습니다.

두 가지 패턴이 반복되었습니다. 첫 번째는 중복된 CSS 규칙이었습니다. 여러 개발자가 여러 스프린트에 걸쳐 동일한 컴포넌트를 건드리면 스타일시트가 비대해집니다. 한 사람은 마진 유틸리티 클래스를 추가하고, 다른 사람은 컴포넌트 파일에 값을 하드코딩합니다. 각각은 틀린 것이 아니지만, 이들이 합쳐지면 레이아웃 시프트가 발생하거나 명시도 전쟁이 일어나 크롬에서는 멀쩡해 보이는 버튼이 사파리에서는 깨져 보이게 됩니다. 이를 추적하려면 우아한 알고리즘 로직을 읽는 대신, 브라우저 개발자 도구를 열고 계산된 스타일(computed styles)을 한 줄씩 훑어야 합니다.

두 번째는 요소를 부모 div 외부에서 정의하는 것이었습니다. 모달 트리거나 드롭다운이 DOM의 잘못된 노드에 추가될 수 있습니다. 화면은 거의 정상적으로 보이기 때문에 구조가 탄탄하다고 가정하게 됩니다. 그러다 z-index 충돌이 발생하거나 클릭 이벤트가 잘못된 핸들러로 버블링되면, 사용자는 갑자기 지원 양식을 가리고 있는 팝업을 닫을 수 없게 됩니다. 이것들은 컴퓨터 과학 퍼즐이 아닙니다. 빠르게 움직이다 보면 쌓이게 되는 공간적, 구조적 실수들입니다.

이 버그들 중 일부는 찾는 데 몇 주가 걸리기도 했습니다. 코드를 뚫어지게 쳐다보며 로직이 완벽하다고 스스로를 설득하다가, 아무런 결실도 없는 막다른 길로 헤매곤 했습니다. 그 좌절감은 정말 엄청납니다. 분명 뻔한 무언가를 놓치고 있다는 느낌이 들고, 실제로도 그렇습니다. 하지만 마침내 중복된 규칙이나 잘못 배치된 닫는 태그를 찾아냈을 때의 만족감은 놀라울 정도로