어느 날 깨달았다. 최근 3개월 동안 새로 배운 게 뭐지?

생각이 안 났다. 매일 코드를 치고 있는데, 새로운 게 없었다. 이미 알고 있는 패턴으로 이미 해봤던 종류의 작업을 반복하고 있었다. 리스트 페이지, 상세 페이지, 폼 페이지. 유사한 컴포넌트를 만들고, 비슷한 API를 연동하고, 같은 방식으로 상태를 관리한다. 손이 먼저 움직여서 코드가 나오는 건 좋은 건데, 머리를 안 쓰게 된다는 뜻이기도 하다.

처음 이 느낌이 들었을 때는 나만 이런 줄 알았다. 다른 사람들은 매일 새로운 걸 배우면서 즐겁게 일하고 있는 것 같았다. SNS에서 "오늘 배운 것" 시리즈를 올리는 사람들을 보면 부러웠다. 나는 오늘 배운 게 뭐지? 잘 모르겠는데.

정체기라는 걸 인지하기까지#

처음에는 정체기인 줄도 몰랐다. 바빴으니까. 매일 티켓을 처리하고, PR을 올리고, 리뷰를 하면서 하루가 갔다. 일은 하고 있으니까 성장하고 있다고 착각했다. 근데 "바쁜 것"과 "성장하는 것"은 다른 문제다.

이걸 인지하게 된 건 채용 공고를 보다가였다. 다른 회사 프론트엔드 시니어 공고에 적힌 요구사항을 읽었는데, 내가 자신 있게 "할 수 있다"고 말할 수 있는 항목이 1년 전과 똑같았다. 1년 동안 실무를 했는데 역량이 제자리라는 느낌. 그게 무서웠다.

주변 동료들도 비슷한 시기를 겪는 것 같았다. 동기 한 명이 "요즘 재미없다"고 했을 때, 나도 같은 생각이었다. 재미가 없다기보다, 도전이 없다는 느낌. 안전지대 안에서 편하게 일하고 있는 건데, 그게 장기적으로 좋은 건지 의문이 들었다.

첫 번째 시도: 새로운 기술 공부하기#

정체기를 느끼면 보통 처음 하는 게 "뭔가 새로운 걸 공부하자"다. 나도 그랬다. Rust를 시작해봤다. 프론트엔드와는 전혀 다른 세계라서 새로운 자극이 될 거라고 생각했다.

2주 정도 열심히 했다. ownership 개념이 신선했고, 컴파일러가 에러를 잡아주는 게 인상적이었다. 근데 3주차쯤에 포기했다. 실무에서 쓸 일이 없으니까 동기 부여가 유지되지 않았다. 퇴근하고 집에 와서 피곤한데 "당장 쓸 데 없는 걸" 공부하는 게 점점 힘들어졌다.

이 경험에서 배운 건, 새로운 기술을 공부하는 것 자체는 정체기의 해결책이 아니라는 거다. 기술이 아니라 "문제"가 새로워야 한다.

두 번째 시도: 관점을 바꾸기#

같은 일을 하더라도 다른 관점에서 보면 새로운 게 보일 때가 있다.

그전까지 나는 "기능 구현"에만 집중했다. 디자인대로 만들고, 정상 동작하면 끝. 근데 같은 작업을 할 때 관점을 바꿔봤다. "이 페이지 로딩 속도를 어떻게 줄일 수 있을까?" "이 컴포넌트의 접근성은 어떤가?" "이 폼의 에러 처리가 사용자 관점에서 괜찮은가?"

리스트 페이지 하나를 만들더라도, 무한 스크롤의 성능을 최적화하려고 Intersection Observer를 파고들면 새로운 영역이 열린다. 같은 폼 페이지인데 키보드만으로 모든 동작이 가능한지 확인하면 접근성이라는 새로운 과제가 생긴다. "하는 일"이 같아도 "깊이"를 달리하면 성장할 수 있다.

이 접근은 실제로 효과가 있었다.

팀에서 성능 개선 이니셔티브를 자발적으로 시작했다. 상품 리스트 페이지의 LCP가 3초 넘어가는 걸 발견하고, 이미지 최적화부터 시작해서 코드 스플리팅, 프리페칭까지 건드려봤다. 결과적으로 1.2초까지 줄였는데, 이 과정에서 웹 성능에 대해 이전보다 훨씬 깊이 알게 됐다. 같은 회사, 같은 프로덕트에서도 새로운 도전은 만들 수 있다.

세 번째: 다른 역할 경험하기#

개발만 하다 보면 시야가 좁아진다.

기획자가 작성한 PRD를 보면서 "이 기능은 이렇게 만들면 되겠다"만 생각했었는데, 어느 날 기획자한테 물어봤다. "이 기능의 목표가 뭐예요? 어떤 지표를 올리려는 건가요?" 기획자가 설명해줬는데, 개발자인 내가 생각도 못한 비즈니스 맥락이 있었다. 이 기능은 사용자 리텐션을 위한 거고, 핵심 지표는 7일 재방문율이고, 경쟁사는 이미 이 기능을 가지고 있다는 것.

그 대화가 나한테는 꽤 충격이었다. 나는 PRD에 적힌 기능 명세만 보고 코드를 쳤는데, 그 뒤에 이런 전략이 있었다니. 이 맥락을 알고 개발하니까 의사결정이 달라졌다. "이 부분은 사용자가 빠르게 접근해야 하니까 로딩 속도가 중요하겠다", "이건 A/B 테스트를 할 수도 있으니까 플래그를 미리 넣어두자" 같은 판단을 할 수 있게 됐다. 코드를 치는 기술은 같은데, 뭘 왜 만드는지 이해하면 결과물의 질이 달라진다. 기획 미팅에도 참여하기 시작했다. 예전에는 "개발자는 기획 끝나고 들어가면 되지"라고 생각했는데, 초기 단계부터 참여하면 기술적으로 불가능한 부분을 미리 잡을 수 있고, 더 나은 대안을 제안할 수도 있다. 이건 코딩 실력과는 다른 종류의 성장이다.

글쓰기의 힘#

정체기를 돌파하는 데 의외로 도움이 된 게 기술 블로그였다.

글을 쓰려면 제대로 알아야 한다. 대충 쓰면 티가 난다. "React의 reconciliation이 어떻게 동작하는지"를 설명하는 글을 쓰려면, 내가 정확히 이해하고 있어야 한다. 모호하게 알고 있던 부분이 글을 쓰는 과정에서 드러난다. "이 부분 설명이 안 되는데?"라는 순간이 오면, 그게 내가 정확히 모르는 부분이라는 뜻이다.

그리고 글을 쓰면 "내가 이번 달에 뭘 배웠는지"가 기록으로 남는다. 정체기에 빠지면 "나는 아무것도 성장 안 했다"는 감정에 사로잡히기 쉬운데, 지난 글들을 보면 "아 그래도 이건 새로 알게 됐구나"라는 게 보인다. 성장은 느끼기보다 기록으로 확인하는 게 정확하다.

정체기는 반복된다#

솔직하게 말하면, 위의 방법들로 정체기를 "해결"한 건 아니다. 한동안 새로운 걸 배우면서 성장하는 느낌이 돌아왔다가, 또 어느 순간 비슷한 감정이 찾아온다. 정체기는 한 번 겪고 끝나는 게 아니라 주기적으로 반복되는 것 같다.

다만 처음 겪었을 때와 다른 건, 이제는 "아 이 느낌"하고 알아차린다는 거다. 무작정 불안해하는 대신 "지금 내가 편한 영역에 너무 오래 있었구나"라고 해석할 수 있게 됐다.

성장 곡선이라는 게 직선이 아니라 계단 형태라는 말이 있다. 한동안 제자리인 것 같다가 갑자기 올라가는 시기가 온다. 그 "제자리" 구간에서 포기하지 않는 게 중요한 건데, 이게 말은 쉽다. 막상 그 안에 있으면 끝이 안 보이니까.

환경을 바꾸는 것도 방법이다#

결국 정체기가 너무 길어지면 환경을 바꾸는 것도 선택지다.

나는 같은 회사에서 팀을 이동한 적이 있다. 프로덕트 A 팀에서 프로덕트 B 팀으로. 같은 기술 스택인데 도메인이 달라지니까 새로운 게 많았다. A 팀에서는 쇼핑 도메인이었고, B 팀에서는 결제 도메인이었다. 같은 React인데 고려해야 하는 것들이 완전히 달랐다. 보안, 트랜잭션 무결성, 에러 핸들링의 중요도가 다른 차원이었다.

이직하지 않고도 환경을 바꿀 수 있다는 걸 그때 알았다. 회사 내에서 팀 이동, 프로젝트 변경, 역할 확장 같은 선택지가 있는데, 의외로 많은 사람이 이걸 고려하지 않는다. "이 팀에 배정됐으니까 여기서 해야 한다"고 생각하는데, 리드에게 말하면 의외로 유연하게 대응해주는 경우가 많다.

사람을 통해 배우기#

정체기를 돌파하는 또 다른 방법은 사람이었다.

기술적으로 뛰어난 시니어의 PR을 의식적으로 읽기 시작했다. 내 리뷰 대상이 아닌 PR도. 어떤 구조로 코드를 짜는지, 변수명을 어떻게 짓는지, 에러를 어떻게 처리하는지. 같은 문제를 나라면 어떻게 풀었을지 비교하면서 읽으면 배우는 게 많다. 시니어한테 직접 "이거 왜 이렇게 하셨어요?"라고 물어보면 생각의 과정을 들을 수 있다. 코드 한 줄 뒤에 있는 판단의 근거를 아는 게 진짜 배움이다.

요즘은 약간 다른 생각도 한다. 성장에 집착하는 것 자체가 피로의 원인이 되기도 한다는 거. 매일매일 성장하고 있어야 한다는 강박. 가끔은 그냥 익숙한 일을 편하게 하는 시간도 필요한 거 아닐까. 그 기간에 체력을 비축하고, 다음 도전에 쓸 에너지를 모으는 거라고 생각하면 정체기도 나쁘지만은 않다. 아직 잘 모르겠지만.