첫 회사는 10명 규모의 스타트업이었다. 프론트엔드 개발자는 나 혼자. 코드 리뷰해줄 사람도, 아키텍처를 논의할 사람도 없었다. 구현은 할 수 있는데, 이게 맞는 방향인지 확인할 길이 없었다. "이 코드가 좋은 코드인지 모르겠다"는 불안이 항상 있었다.

사수가 있으면 좋겠다는 생각을 많이 했다. 하지만 없다고 성장을 멈출 수는 없었다.

코드 리뷰를 대체하는 것들#

혼자서도 코드 리뷰의 효과를 얻는 방법이 있었다.

시간 차 셀프 리뷰. PR을 올리고 바로 머지하지 않는다. 다음 날 아침에 다시 본다. 하루만 지나도 코드가 다르게 보인다. "이 변수명이 왜 이러지?", "이 로직 너무 복잡한데?" — 어제의 나는 당연하다고 생각했던 것이 오늘은 어색하다.

오픈소스 PR 읽기. TanStack Query, Zustand 같은 라이브러리의 PR과 이슈를 읽었다. 메인테이너들이 어떤 기준으로 코드를 리뷰하고, 어떤 패턴을 선호하는지 보인다. 실력 있는 개발자의 코드 리뷰를 간접 체험하는 셈이다.

커뮤니티 코드 리뷰. 프론트엔드 디스코드, 오픈 카카오톡 방에서 코드 리뷰를 부탁했다. 처음에는 부끄러웠는데, 의외로 기꺼이 봐주는 사람이 많았다. 내 코드를 남에게 보여주는 것 자체가 성장의 기회다.

방향을 잡는 방법#

사수가 없을 때 가장 힘든 건 "뭘 공부해야 하는지 모르는 것"이다. 사수가 있으면 "이번 분기에는 이걸 해보자"라고 방향을 제시해주는데, 혼자면 무한한 선택지 앞에서 방황한다.

로드맵을 따라가지 않는다. 프론트엔드 로드맵에 나열된 기술을 순서대로 공부하는 건 비효율적이다. 실무에서 마주치는 문제를 해결하면서 공부하는 게 훨씬 효과적이다. "이번 주에 성능 최적화가 필요하니까 Lighthouse를 파보자", "이미지 로딩이 느리니까 lazy loading을 배우자" — 문제가 공부의 방향을 정해준다.

블로그와 뉴스레터를 읽는다. 매일 아침 15분, 기술 블로그 RSS를 훑어본다. 모든 글을 정독하는 게 아니라, 제목만 읽으면서 "이건 지금 내 프로젝트에 써볼 수 있겠다" 싶은 것만 북마크한다. 일주일에 한두 개 정도 깊이 읽으면 충분하다.

컨퍼런스 발표 영상을 본다. FEConf, 인프콘, React Conf 같은 컨퍼런스 발표를 본다. 현업에서 어떤 문제를 어떻게 해결하는지, 업계의 흐름이 어디로 가는지 파악된다.

외부 멘토 찾기#

사수가 없다고 멘토가 없는 건 아니다. 형태가 다를 뿐이다.

온라인 멘토링 플랫폼. 프로그래머스, 인프런, ADPList 같은 곳에서 멘토를 찾을 수 있다. 월 1~2회 30분 통화만으로도 방향 확인이 된다.

밋업과 컨퍼런스. 직접 가서 사람을 만나는 게 제일 좋았다. 발표 후 질문하거나, 네트워킹 시간에 대화를 걸었다. "저 혼자 프론트엔드 하고 있는데, 이런 상황에서 어떻게 하시나요?" — 이 한마디로 시작된 대화에서 많이 배웠다.

블로그 글의 저자에게 연락하기. 글을 읽고 도움이 됐으면, 저자에게 감사 메일이나 트윗을 보냈다. 놀라울 정도로 많은 사람이 답장해준다. 거기서 이어진 대화가 멘토링이 되기도 했다.

혼자여서 좋은 점도 있다#

역설적으로, 혼자라서 빠르게 성장한 부분도 있다.

모든 결정을 내가 했다. 기술 선택, 아키텍처 설계, 배포 전략 — 전부 내 판단이었다. 사수가 있었으면 따라했을 결정을 직접 내리면서, 판단의 결과를 몸으로 겪었다. 잘못된 선택의 대가를 직접 치르니까 배움이 깊었다.

주인 의식이 강해졌다. "이 코드는 내 책임"이라는 인식이 있으니까 대충 못 한다. 코드 리뷰어가 잡아줄 거라는 안전망이 없으니까 스스로 꼼꼼해진다.

사수 없이 성장하는 건 분명 비효율적이다. 사수가 5분 만에 알려줄 수 있는 걸 혼자서 이틀 삽질하는 경우가 있으니까. 하지만 그 삽질이 쌓이면, 어떤 환경에서도 문제를 해결할 수 있는 자생력이 생긴다.