한 에세이스트가 이런 말을 했다. "사람들은 놀라움에서 배운다. 정답을 들었을 때가 아니라, 기대와 현실 사이에 간극이 생겼을 때 배운다." 커리어도 마찬가지인 것 같다. 돌아보면 내 커리어를 바꾼 건 거창한 결심이 아니라, 그 순간에는 별 의미 없어 보였던 작은 선택들이었다.
투자 세계에서 복리가 무서운 이유는 초기에는 거의 안 보이기 때문이다. 100만 원에 연 8%를 붙이면 1년 뒤에 108만 원이다. 별것 아니다. 그런데 20년 뒤에는 466만 원이 된다. 초반의 8만 원과 후반의 수십만 원은 같은 8%인데 결과가 완전히 다르다. 커리어에서의 작은 결정도 이 구조를 따른다. 당시에는 8만 원짜리 선택 같았는데, 몇 년이 지나고 보면 커리어의 방향 자체를 바꿔놓은 경우가 있다.
다섯 가지가 떠오른다.
1. Angular 대신 React를 고른 것
2020년에 처음 프론트엔드를 배울 때, 부트캠프 커리큘럼에는 Angular가 있었다. 국내 SI 업체에서 Angular를 많이 쓰니까 취업에 유리하다는 논리였다. 합리적인 이야기였다. 그런데 나는 React를 골랐다. 이유는 솔직히 별거 없었다. React 관련 한국어 자료가 더 많아서 독학하기 편할 것 같았다. 그게 전부다.
이 선택이 커리어에 미친 영향을 그때는 전혀 몰랐다. React 생태계가 폭발적으로 성장하면서 구직 시장에서의 수요가 완전히 달라졌다. Next.js, React Native, React Server Components로 생태계가 확장되면서 하나의 기술 선택이 접근할 수 있는 기회의 범위를 계속 넓혀줬다. 만약 Angular를 골랐다면 나쁜 커리어를 갖진 않았겠지만, 지금 내가 있는 자리에는 확실히 없었을 거다.
여기서 배운 게 있다. 기술 선택에서 "지금 당장의 취업률"보다 "생태계의 성장 방향"이 장기적으로 더 중요하다. 그런데 문제는 이걸 선택하는 시점에는 어느 쪽이 맞는지 알 수 없다는 거다. 나는 운이 좋았다. 다만 그 운을 만든 건 "자료가 많은 쪽을 고르자"라는 소박한 기준이었다. 학습 자원이 풍부한 기술은 커뮤니티가 활발하다는 뜻이고, 커뮤니티가 활발한 기술은 성장할 확률이 높다. 완벽한 논리는 아니지만, 꽤 쓸 만한 휴리스틱이다.
2. 아무도 안 하려던 프로젝트에 손을 든 것
입사 6개월쯤에 사내 어드민 페이지를 리뉴얼하는 프로젝트가 떨어졌다. 팀 미팅에서 "이거 누가 할래?"라고 물었을 때 아무도 손을 안 들었다. 어드민은 사용자가 사내 인원 20명뿐인 데다, 기술적으로 재미있는 게 없었다. CRUD의 반복이다. 테이블 보여주고, 필터 달고, 수정 폼 만들고. 화려한 것과는 거리가 멀었다.
3초 정도 침묵이 흐르고, 내가 "해볼게요"라고 했다. 특별한 의지가 있었던 건 아니다. 신입이니까 일을 가려서는 안 될 것 같다는 소박한 판단이었다.
그런데 이 프로젝트가 생각보다 많은 걸 가르쳐줬다. 어드민은 프로덕트 전체의 데이터 구조를 한눈에 볼 수 있는 창이었다. 유저 테이블, 주문 테이블, 결제 테이블이 어떻게 연결되는지, API가 어떤 구조로 응답을 주는지, 백엔드 개발자가 어떤 제약 조건 안에서 일하는지를 어드민을 만들면서 전부 배웠다. 고객용 프로덕트만 만들었으면 이 전체 그림을 이렇게 빨리 파악하지 못했을 거다.
그리고 하나 더. 어드민을 쓰는 운영팀 사람들과 직접 대화하면서 "사용자의 피드백을 바로 받는 경험"을 했다. "여기 이 버튼 위치 불편해요"라는 말을 듣고 다음 날 수정해서 배포하면 "오 바로 고쳐졌네요"라는 반응이 온다. 이 짧은 피드백 루프가 개발의 재미를 알려줬다. 사용자가 수십만 명인 프로덕트에서는 이런 직접적인 피드백을 받기 어렵다.
한 유명 에세이스트가 "확장되지 않는 일을 하라"고 쓴 적이 있다. 사용자 20명짜리 어드민은 확장과는 거리가 먼 일이었다. 그런데 거기서 배운 것들이 나중에 확장 가능한 프로덕트를 설계하는 데 직접적인 밑거름이 됐다.
3. 첫 블로그 글을 쓴 것
입사 1년쯤에 팀에서 겪은 API 에러 핸들링 삽질기를 블로그에 올렸다. "이걸 누가 읽겠어"라는 생각이었고, 실제로 처음 두 달은 아무도 안 읽었다. 조회수가 한 자릿수였다.
그런데 석 달쯤 지나서 검색 유입이 생기기 시작했다. 특정 에러 메시지로 검색하면 내 글이 나왔다. "axios interceptor에서 refresh token 처리할 때 무한 루프 해결" 같은, 아주 구체적인 문제를 겪고 있는 사람이 내 글에 도착하기 시작한 거다.
글을 하나 더 쓰고, 또 하나 더 쓰고, 반년이 지나자 열 개 정도가 쌓였다. 그때부터 뭔가가 달라졌다. 이직 준비를 할 때 면접관이 "블로그 글 몇 개 읽어봤는데"라는 말을 했다. 이력서에 "React 3년"이라고 적는 것과, 실제로 어떤 문제를 어떻게 풀었는지가 글로 남아있는 것은 전달력이 전혀 다르다.
복리 구조가 여기서도 작동한다. 글 하나하나는 별거 아닌데, 열 개가 쌓이면 "이 사람은 꾸준히 정리하는 습관이 있구나"라는 인상을 준다. 스무 개가 쌓이면 특정 주제에 대해 "이 블로그 한번 보세요"라고 추천받는 일이 생긴다. 글 하나의 가치가 선형이 아니라 지수적으로 올라간다. 초반에는 거의 0인데, 일정 임계점을 넘으면 급격히 올라간다.
처음 그 글을 쓸 때의 나는 이런 걸 전혀 예상하지 못했다. 그냥 삽질한 게 아까워서 적어둔 거였다.
4. 커피챗 요청을 수락한 것
어느 날 링크드인으로 메시지가 왔다. 다른 회사의 프론트엔드 개발자인데, 내 블로그 글을 읽고 궁금한 게 있어서 30분만 이야기할 수 있겠냐고. 처음에는 좀 귀찮았다. 모르는 사람이고, 퇴근 후 시간을 써야 하고, 특별히 내가 얻을 게 있을 것 같지도 않았다.
그래도 "뭐 30분이니까"라는 마음으로 수락했다.
그 30분이 꽤 유익했다. 다른 회사의 기술 스택, 팀 문화, 코드 리뷰 프로세스를 들었다. 우리 팀에서는 당연하게 쓰는 도구가 그 팀에서는 전혀 다른 것으로 대체되어 있었다. 시야가 넓어지는 느낌이었다. 상대방도 비슷하게 느꼈는지, 한 달 뒤에 또 연락이 왔고, 이번에는 세 명이서 만났다.
이게 반년 정도 이어지면서 느슨한 개발자 네트워크가 만들어졌다. 거창한 "커뮤니티"가 아니라, 가끔 기술 관련 질문을 주고받는 정도. 그런데 이 네트워크에서 이직 정보가 왔다. "우리 팀에서 프론트엔드 뽑는데, 관심 있으면 내가 추천해줄까?" 공개 채용 공고에 지원하는 것과 내부 추천을 받는 것은 서류 통과율이 전혀 다르다.
작은 결정의 복리가 여기서도 작동한다. 커피챗 한 번이 네트워크가 되고, 네트워크가 기회가 되고, 기회가 커리어의 분기점이 된다. 처음의 30분이 별것 아닌 것 같아도, 그 30분이 없었으면 그 이후의 모든 것도 없었다.
5. 클래스 컴포넌트 대신 함수형 컴포넌트를 일찍 선택한 것
이건 기술적인 이야기다. 2021년쯤, 팀에서 새 프로젝트를 시작할 때 함수형 컴포넌트와 Hooks를 기본으로 쓰자고 제안했다. 당시 팀의 기존 코드베이스는 대부분 클래스 컴포넌트였다. 시니어 한 분이 "검증된 패턴을 굳이 바꿀 필요가 있나"라고 했고, 다른 팀원도 비슷한 반응이었다.
나는 React 공식 문서에서 "새 프로젝트는 함수형 컴포넌트를 권장한다"는 문장을 근거로 밀었다. 새 프로젝트니까 기존 코드와의 호환성 문제도 없었다. 결국 "새 프로젝트만 함수형으로"라는 타협안이 나왔고, 그대로 진행했다.
이 선택이 가져온 변화는 생각보다 컸다. 함수형 컴포넌트에 익숙해지면서 커스텀 훅이라는 패턴을 자연스럽게 쓰게 됐다. 로직 재사용이 쉬워지니까 코드 구조가 깔끔해졌다. 팀원들도 한 명씩 함수형으로 넘어왔다. 6개월 뒤에는 "클래스 컴포넌트를 왜 썼지?"라는 분위기가 됐다.
그리고 React 18, 19에서 Concurrent Mode, Server Components 같은 새 기능이 나왔을 때, 이것들이 전부 함수형 컴포넌트 기반이었다. 클래스 컴포넌트로 된 코드베이스는 이 기능들을 쓰려면 먼저 마이그레이션을 해야 했다. 우리는 이미 함수형이었으니까 바로 적용할 수 있었다.
기술의 방향을 정확히 예측한 게 아니다. 공식 문서의 권장 사항을 따른 것뿐이다. 그런데 그 소박한 근거가 맞는 방향이었고, 일찍 움직인 덕에 나중에 전환 비용을 안 치를 수 있었다.
작은 선택이 큰 선택보다 중요한 이유
다섯 가지를 돌아보면 공통점이 있다. 전부 그 순간에는 "별거 아닌" 선택이었다는 거다. Angular vs React를 고를 때 한 달을 고민한 게 아니라 이틀 만에 정했다. 어드민 프로젝트에 손을 든 건 3초 만의 판단이었다. 블로그 글을 쓴 건 주말 오후의 충동이었다. 커피챗은 "뭐 30분이니까"였다. 함수형 컴포넌트 제안은 팀 미팅 중 10분짜리 논의였다.
큰 결정은 신중하게 하면서 작은 결정은 대충 넘기는 경우가 많다. 이직, 연봉 협상, 기술 스택 전환 같은 큰 결정에는 몇 주를 고민한다. 반면에 "이 프로젝트 해볼까 말까", "이 글 써볼까 말까", "이 사람 만나볼까 말까" 같은 건 감으로 정한다.
그런데 커리어의 방향을 실제로 바꾼 건 후자였다. 큰 결정은 이미 작은 결정들이 만들어놓은 경로 위에서 이루어진다. 이직 면접에서 좋은 결과를 얻은 건 블로그를 써왔기 때문이고, 블로그를 쓰기 시작한 건 어드민 프로젝트에서 삽질한 경험이 있었기 때문이고, 어드민 프로젝트를 맡은 건 아무도 안 하려던 일에 손을 들었기 때문이다.
작은 결정들이 서로를 강화하면서 복리처럼 쌓인다. 한 에세이스트가 쓴 것처럼, 초기의 노력은 하찮아 보여도 가파른 곡선의 시작점에 서 있는 거다. 그걸 당시에는 알 수 없다. 사후적으로만 보인다. 그래서 작은 선택을 할 때 너무 무겁게 생각할 필요는 없다. 대신 "일단 해보자" 쪽으로 약간의 편향을 두는 게 나쁘지 않다. 해본 결정은 복리의 재료가 되지만, 안 한 결정은 아무것도 남기지 않으니까.