3년차 스타트업 개발자, 다시 시작한다면?

내가 걸어온 길

나는 AI Associates를 만드는 스타트업의 초기 프론트엔드 개발자로 합류해, 2년 8개월간 고군분투했다. 매출 0원에서 정기적인 매출까지, 그리고 나 홀로 프론트엔드 개발에서 주니어를 리딩하기까지 다양한 여정이 있었다. 만약 시간을 되돌려 그때의 나에게 조언할 기회가 생긴다면, 나는 이 이야기들을 해주고 싶다.

숲을 선택하라

가장 먼저, 꼭 필요하지 않은 이상은 어느 정도 성숙한 생태계를 골라라.

기술의 힙함보다 안정성이 너의 수면 시간을 보장해 줄 것이다. 그리고 "6개월 뒤 이 코드를 누가 유지보수할까?" 라는 질문을 스스로에게 던져봐라. 그 질문 하나가 너의 기술 선택을 더 단단하게 만들어 줄 것이다.

기능 구현, 일단 만들지 않으려면

기능 요구사항을 받고 바로 vscode를 켜는 대신, 잠시 멈춰 설계를 먼저 진행해라.

데이터의 여정을 그려봐라.

그림판도 좋다. 이 기능을 위해 필요한 데이터는 무엇이고, 어디서 와서 어디로 흐르는지 그려보는 거다. 이를 통해 기능의 시작점과 끝점을 명확히 정의하고, 이 시나리오를 검증할 작은 unit test를 먼저 작성해봐라.

이게 바로 모두가 네 코드를 믿게 할 수 있는 코드 신뢰도의 첫 걸음이다. 이 기능은 요구사항을 충족한다는 걸 증명할 테스트부터 만드는 습관은 너의 코드와 식은땀을 견고하게 지켜줄 것이다.

컴포넌트를 현명하게 쪼개라.

데이터 흐름에 맞춰 컴포넌트를 어떻게 쪼갤지, 각자의 역할과 책임이 무엇일지 그려봐라. 이때 단일 책임 원칙(SRP) 를 떠올려라.

하나의 코드 청크는 되도록 하나의 책임만 져야 테스트도, 유지보수도 쉬워진다는 걸 그때 알았더라면 수많은 리팩토링의 밤을 피할 수 있었을 것이다.

테스트하기 쉬운 코드를 작성해라.

'테스트하기 쉽다'는 말의 핵심은 테스트하려는 대상, 즉 SUT(System Under Test)를 명확히 분리하는 데 있다.

복잡한 비즈니스 로직을 React 컴포넌트에서 분리해 순수 함수(vanilla typescript)로 만들면, 진입점과 출구점이 명확해져서 놀라울 만큼 테스트가 간결해질 것이다.

가장 먼저 실패하는 상황부터 설계해라.

로딩 중일 땐 어떻게 보일지, API 에러 발생 시 사용자에게 무엇을 보여줄지 디자이너와 치밀하게 고민하고 코드를 시작해라.

해피 케이스만 생각하고 달리다 넘어지는 것보다 훨씬 안정적이다. 그리고 나는 잔뜩 망가져버리게 된다.

코드를 넘어, 제품과 고객을 보기

개발자로서의 너의 가치는 코드가 아니라, 코드를 통해 만들어낸 '제품의 가치'로 증명된다.

모든 요구사항에 "쌉가능"을 외치지 마라.

고객이 A 기능이 필요해요라고 말할 때, 바로 개발 계획부터 세우지 마라. 대신 그 기능으로 어떤 문제를 해결하고 싶으신가요?라고 딱 한 번만 더 물어봐라.

그 질문 하나가 너의 야근을 줄여주고 제품의 방향을 바로잡아 줄 것이다.

사용자의 세상으로 들어가라.

그들이 우리 제품을 어떤 맥락에서, 어떤 타이밍에 활용할지 상상해야 한다.

인터뷰는 우리가 던진 질문에 답을 가두기 쉽다. 그들의 업무 과정을 관찰하고 진짜 문제를 이해하려고 노력해라.

동료와 '함께' 진짜 팀으로 일하기

결국, 모든 일은 사람이 한다. 기술보다 사람이 더 어렵다.

나보다 잘하는 사람을 분석해라.

자괴감에 빠지는 대신, 그들이 왜 잘한다고 느껴지는지 관찰하고 기록해라.

어떤 타이밍에 어떻게 질문하는지, 왜 그렇게 행동했는지 직접 물어봐라. 그들의 장점을 흡수하는 것이 가장 빠른 성장 전략이다.

그리고 보면 대부분 다른 사람들에게 질문함으로 장점을 미칠듯이 흡수하는 걸 볼 수 있을것이다.

나와 다른 동료를 이해해라.

목표나 욕심의 크기가 다르다고 답답해하지 마라. 먼저 그들의 목표를 진심으로 들어주고 공감해라.

그리고 그들이 궁금해할 때 너의 목표와 생각을 공유해라. 신뢰는 거기서부터 시작된다.

피드백은 '기대치'에 대한 설명이다.

만족스럽지 못한 결과물에 "이거 별로네요"라고 말하는 건 싸우자는 것과 같다. 대신 "나는 이러이러한 이유로 이 정도 수준의 결과물을 기대했다"고 명확히 설명해라.

그리고 왜 그 수준에 도달하기 어려웠는지 함께 이야기하며 간극을 좁혀나가라.

선을 긋지 마라.

"이건 백엔드 담당인데요" 같은 싸가지 없는 소리는 하지 마라. 프론트엔드에서 데이터가 어떻게 필요한지를 먼저 구체적으로 그려서 제안해라.

함께 풀어야 할 문제이지, 네 문제가 아닌 것은 없다.

주니어의 성장을 이끌며 '함께' 성장하기

이제 너는 누군가의 사수다. 너의 성장은 팀의 성장과 함께 간다.

과감하게 오너십을 위임해라.

네가 그랬듯, 주니어도 큰 코드의 주인이 되었을 때 가장 빠르게 성장한다.

기능 기획부터 배포, 그리고 장애 대응까지 직접 경험하게 해줘라.

다만, 안전망이 되어줘라.

주니어가 프로덕션 에러를 내고 식은땀을 흘릴 때, 너의 역할은 무너지되 고립되지는 않도록 돕는 것이다.

에러가 터졌을 때 질책하기보다, 함께 화면을 보며 원인을 분석하고 해결하는 과정을 공유해줘라. 그게 진짜 살아있는 교육이자 든든한 안전망이 되어줄 것이다.

결론: 그럼에도 불구하고

이 모든 경험을 거쳐 지금의 내가 되었다. 자만하지 마라.

너무 일에 매몰되지 말고, 너 자신과 가족, 건강을 먼저 챙기는 마음의 여유를 가져라.

네가 당연하게 생각해왔던 모든 것에 "왜?"라는 질문을 던져 근거를 찾는 습관을 들여라.

훌륭한 사람들이 이미 닦아놓은 길을 책을 통해 빠르게 학습해라.

마지막으로, 나를 나보다 더 훌륭한 사람들 사이에 의식적으로 파묻어둬라.

이 글이 과거의 나에게 보내는 '셀프 멘토링'이었던 것처럼, 미래의 나를 이끌어줄 또 다른 멘토를 적극적으로 찾아 나서라. 그리고 언젠가 너 역시 그들처럼, 누군가의 성장을 이끌어주는 사람이 되어라.