주니어 개발자 1년 성장 현실적 방법

입사 첫 날 브랜치를 날렸다

git merge를 잘못해서 develop 브랜치를 통째로 날린 게 내 커리어의 시작이었다. 사수가 27분 만에 복구해줬는데, 그 27분이 체감상 3시간이었다. 얼굴이 빨개져서 모니터만 쳐다봤다. 옆자리 선배가 "괜찮아, 나도 첫 달에 프로덕션 DB 날릴 뻔했어"라고 했는데, 위로인지 경고인지 지금도 모르겠다.

7년 차가 돼서 돌아보면, 그때 나한테 해주고 싶은 말이 좀 있다. 근데 사람마다 상황이 다르니까, 이게 정답이라기보다는 내 경험에서 나온 이야기 정도로 들어주면 좋겠다.

남의 PR을 읽기 시작하면 달라진다

1년 차 때 코드 리뷰를 성적표처럼 생각했다. Approve 뜨면 기뻤고 Request changes 뜨면 하루가 우울했다. (지금 생각하면 진짜 순진했다.) 근데 진짜 변곡점은 내가 다른 사람 PR을 읽기 시작하면서였다.

시니어 PR을 하루에 하나씩만 읽어봐라. 왜 그 구조를 택했는지, 왜 그 네이밍인지, 왜 그 라이브러리를 골랐는지. 처음엔 70%는 이해 안 된다. 3개월 정도 하니까 코드 스타일이 확 바뀌더라.

나는 사수 PR 읽다가 커스텀 훅으로 로직 분리하는 패턴을 처음 배웠다. 그 전까지 컴포넌트 하나에 340줄을 때려넣고 있었으니까. useEffect 안에 fetch 로직, 에러 핸들링, 상태 업데이트를 전부 쑤셔넣은 코드를 지금 보면 아찔하다.

에러 메시지를 끝까지 읽어라

농담이 아니다. 1년 차 개발자 대부분은 에러 메시지를 읽지 않고 바로 구글에 복붙한다. 나도 그랬다. 빨간 글씨 뜨면 반사적으로 복사해서 검색창에 붙여넣었다.

근데 에러 메시지의 마지막 두 줄에 답이 있는 경우가 진짜 많다. TypeError: Cannot read properties of undefined가 뜨면, 어떤 변수가 undefined인지부터 추적해봐라. 왜 undefined인지를 따라가면 5분 안에 해결되는 문제가 태반이다.

한번은 30분 동안 스택오버플로우를 뒤졌는데, 돌아와서 에러 메시지를 다시 읽어보니 답이 두 번째 줄에 있었다. 그때 좀 허탈했다. 이 습관 하나가 디버깅 속도를 체감상 3배로 만들어줬다.

질문하는 법이 커리어를 바꾼다

"이거 왜 안 돼요?"는 최악의 질문이다. 사수 입장에서 저 질문을 받으면 "뭘?", "어떻게 안 되는데?", "뭘 해봤는데?" 다 물어봐야 한다. 나도 1년 차 때 이런 질문을 하도 해서 사수 한숨 소리를 꽤 들었다. 솔직히 그때 나한테 좀 짜증났을 것 같기도 하다.

"X를 하려고 Y를 시도했는데 Z 에러가 납니다. 문서에서 A를 확인했는데 제 상황과 다른 것 같습니다" — 이렇게 정리하면 두 가지 좋은 일이 생긴다. 절반은 정리하는 과정에서 답을 찾게 되고, 나머지도 답변자가 맥락을 바로 잡을 수 있다.

(이걸 "러버덕 디버깅"이라고도 하던데, 오리한테 설명하든 사람한테 설명하든 정리하는 과정 자체가 힘이 있다.)

질문 잘하는 주니어는 시니어가 먼저 챙기게 된다. 사내 정치가 아니라, 도움을 주기 쉬운 사람한테 자연스럽게 손이 가는 거다.

사이드 프로젝트보다 회사 코드를 파라

1년 차 때 주말마다 사이드 프로젝트를 했다. 투두 앱 3개, 날씨 앱 2개, 반쯤 만든 블로그 1개. "포트폴리오 쌓아야 해"라는 강박 때문이었다. 돌이켜보면 그 시간에 회사 코드를 더 깊이 팠으면 두 배는 빨리 성장했을 것 같다.

레거시 코드가 왜 그렇게 짜여 있는지 이해하는 게, 투두 앱 10개보다 낫다. 투두 앱은 "이미 답을 아는 문제를 푸는 것"이고, 레거시 이해는 "현실 세계의 복잡성을 마주하는 것"이다.

회사 코드에서 "이건 왜 이렇게 짰지?" 싶으면 git blame으로 커밋 히스토리를 따라가봐라. 그 코드가 어떤 제약 조건 하에서 나왔는지 알 수 있다. 3년 전에 3명이 밤새 짠 핫픽스 코드가 지금까지 살아있는 경우도 있다. 그 맥락을 이해하면 코드가 달리 보인다.

매일 10분이면 된다

나는 매일 퇴근 전 10분 동안 오늘 배운 걸 노션에 적었다. "오늘 useMemo가 참조 동등성을 유지해주는 이유를 알게 됐다" 같은 한 줄이라도 좋다. "TypeScript에서 as const 쓰면 리터럴 타입으로 좁혀진다는 걸 배웠다" 같은 것도.

6개월 뒤에 그걸 다시 읽으면 "이런 기초도 몰랐구나" 하는 깨달음이 온다. 번아웃 올 때 이 노트를 읽으면 좀 위안이 된다.

(근데 솔직히 매일 꾸준히 적은 건 아니다. 한 달에 15일 정도? 그래도 효과는 있었다.)

70%면 일단 올려라

1년 차 때 PR 올리기 전에 세 시간을 고민했다. 변수명 열 번 바꾸고, 쓸데없는 추상화 하고, 결국 원래보다 더 복잡한 코드를 만들어냈다. 7년이 지난 지금 깨달은 건, 70%만 되면 일단 리뷰를 요청하는 게 맞다는 거다.

"아직 완성 아닌데 방향 맞는지 확인 부탁합니다"라고 써놓으면 된다. 방향이 틀렸으면 빨리 아는 게 이득이다. 100% 만들고 "이 방향 아닌데요" 피드백 받으면 그게 진짜 지옥이다. 나는 이걸 두 번이나 겪었다. 3일치 작업을 통째로 버린 적도 있다.

그때 나한테 딱 하나만 말해줄 수 있다면, "지금 못하는 게 당연하니까 더 많이 틀려라"라고 하겠다. git merge 잘못해서 브랜치 날리던 사람이, 지금은 후배한테 git 쓰는 법을 알려주고 있다.