Swizec Teller 님의 블로그를 의역/요약한 글입니다.

---

정말 오랜만에 아는 사람을 만났을 때 “내가 알던 그 사람이 맞아?” 싶은 경험, 다들 한 두번씩 있죠?

3년 전, 저는 흔히 말하는 “좀비 스타트업”의 개발자였습니다. 회사는 성장이 더뎠고 매니저들은 쉬운 문제를 애써 어려운 문제인 것처럼 둔갑 시켜서 가져오는 상황이었어요. 저도 회사가 정체 됐다는 게 다 체감이 되는데 말이죠. 스트레스만 받고 있었어요.

그러다 이직을 했고, 하키 스틱 성장 (유료 고객 수 20x 성장, aka. J 커브)을 경험했습니다. 그때의 경험을 되돌아보니 전 3년 만에 완전히 다른 개발자가 되어 있었어요. 이 회고록이 누군가의 커리어에 도움이 되길 바랍니다.

이직 시그널: 문제 창조 중 ⚒️

보통 심심하면 쉬운 문제를 굳이 굳이 다른 방식으로 접근해서 더 어렵게 풀려고 합니다. 물론 당시에는 재밌어요. 다만, 근본적으로 도전적인 환경에서 어려운 문제를 해결하는 것과 다릅니다.

제가 모두를 위한 “폼 생성기”를 만든 경험이 딱 그 예시에요. 당시 저는 폼이 서비스 곳곳에 쓰이고 있고 매번 유사한 폼을 만드는 코드를 작성하는 게 비효율적이라고 느꼈습니다. 그래서 폼을 정의하는 필드, 조건 등을 넘겨주면 자동으로 서비스에 맞는 폼을 찍어낼 수 있는 생성기를 만들었습니다. 만약 쓸데없이 복잡하게 문제를 어렵게 만들고 있다면, 도망가세요. 사용자에게 가치를 주는 문제를 해결하는 곳에서 당신의 시간과 능력을 보내는 게 낫습니다.

엔지니어가 성장하는 방법 📈

당시에는 몰랐지만 모두의 “폼 생성기”를 만들고 있다는 것 자체가 이직 시그널이었습니다. 2달 뒤 저는 이직 했고 “시니어 엔지니어로 성장하는 방법”에 대한 글을 썼습니다.

제가 생각한 시니어 엔지니어가 본인의 성장이 정체된 것 같다고 느끼는 이유는 다음과 같습니다.

• 실제로 성장이 정체 되는 시기에 들어섰다

• 해결하는 문제가 더 이상 새롭지 않고, 코드 퀄리티는 완벽하진 않지만 괜찮은 정도에서 발전이 없다. 완벽함을 추구할 시간 따위는 없으며, 회사의 요구를 충족시키려고 사용하는 기술 스택이 정해져 있다.

• 아주 아주 아아아아아주우우우우 가끔 어려운 문제를 접한다

이 시기에 들어서면 스스로에게 이 질문을 던져야 해요. “5년의 경험을 쌓을 것인가, 1년의 경험을 5번 반복할 것 인가?”

시니어 엔지니어로 성장하는 방법은 여러가지입니다.

1. 매니저

2. 컨설턴트/창업

3. 더 큰 문제를 해결하고 있는 더 큰 회사로 이직

4. 새로운 기술 스택에 주니어로 시작하기

매니징은 아예 다른 업이고, 창업은 필요한 기술 셋이 다르며, 주니어로 여기저기 경험하는 건 시간이 지날수록 지루해질 겁니다. 결론은 더 큰 문제를 해결하고 있는 더 큰 회사로 이직 하기!

S 커브의 시작점에 합류하기 🎢

회사는 S 커브를 그리며 성장합니다. 성장이 처음에는 더디다가, 특정 계기로 확 튀고, 다시 올라온 그곳에서 정체되는 사이클의 무한 반복입니다. 언제 회사에 합류하는지가 중요해요. 가능하면 확 성장하기 전에 합류하는게 좋습니다.

보통 확 성장하기 전의 진입 단계에서 Product Market Fit (PMF)를 찾습니다. 이때는 마치 시장이 연료인 제트 로켓에 올라탄 기분이에요. 시장에 맞추려고 최대한 빠르게 제품을 만들어내는데 바쁩니다.

특정 구간에 들어서면 정체가 시작됩니다. 로켓의 연료가 떨어지고 기존에 해왔던 방식이 더 이상 시장에서 통하지 않음을 인지합니다. 이때 한숨 돌리면서 기술 부채를 해결하고 새로운 방식을 모색합니다. 새로운 로켓에 탑승하는 방법은 새로운 제품을 내놓거나, 다른 시장으로 확장하거나 여러가지지만 이건 회사가 알아서 찾아내야 합니다.

개발자인 당신은 이 S 커브의 시발점에 합류할 수 있도록 노력해야 합니다. 사내의 다른 팀으로 이동이어도 상관없어요.

하키 스틱 성장 경험을 통해 얻은 것 🏑

3년 전 저는 하루하루 의미 없는 기술 문제를 이러 저리 뒤집어가며 풀고 있었습니다. 방향성은 회사가 알아내길 기다리면서 말이죠. 그러다 “일을 이정도로 하면 죽겠는데?” 싶은 회사로 이직을 했고 하키 스틱 성장률을 경험했습니다. 세세하게 적진 않았지만 성장 과정에서 각각의 경험은 하나의 작은 책으로 적을 수 있을 정도입니다.

• 코어 웹앱을 다시 만들었고, 1개 지역에서 배포하던 소프트웨어를 10개 넘는 지역으로 확장 시켰습니다

• 7명이던 개발 인원을 25명으로 늘렸고 5개 정도의 팀으로 성장 시켰습니다. 그 과정에서 200명이 넘는 사람과 면접을 진행했고 고객사 역시 20 곳 정도에서 400 곳이 넘도록 확장시켰습니다.

• 개발 문화도 성숙해졌습니다. “구글 엔지니어는 이렇게 일한다” 책에 나오는 내용을 실제로 적용 시켜보았으며 값진 경험이 되었습니다. 확장 가능한 코드 리뷰, 병목 되지 않는 팀 만들기, 코딩 기준 잡기 등 여러가지를 도입했습니다

• 한 달의 한 번 겨우 하던 배포 사이클을 하루에도 여러 번 배포할 수 있는 구조로 변경했고, 피처 플래그를 도입했으며, PM들이 개발자들을 단순 코딩 몽키가 아닌 동업자로 대하도록 문화를 조성했으며, 개발자들도 이해 관계자들을 더 잘 이해하도록 교육했고, 이슈 발생 시 기본 대응 메뉴얼을 도입하고 어디가 문제인지 쉽게 모니터링 할 수 있도록 기반을 다졌습니다. 책 “유니콘 프로젝트”에서 언급하는 대부분의 경험을 직접 한 것 같아요.

엔지니어링은 단순히 코드를 잘 짜는 것 그 이상이다 ⌨️

좋은 개발자라면 누구나 다 아는 말일 겁니다. 하지만, 글로 아는 것과 직접 경험하는 것은 천지차이 입니다.

제가 하는 업무 중 코드 짜는 게 오히려 쉬운 쪽에 속해서 이제 절 어떤 직책으로 정의 지어야 할지도 모르겠네요.

---

개발 과정에서 비효율을 찾아 개선하는 게 개발자 경험을 향상 시키는 첫 단추라고 생각하지만 개발자 경험을 챙기는 것도 시기가 중요한 것 같아서 Swizec님의 주장도 공감이 됩니다. 로켓 성장을 하기 전에 그럴만한 회사를 찾아서 합류하는 게 사실 더 어려운 것 같아요 😅

원글: https://swizec.com/blog/i-m-a-different-engineer-than-i-was-3-years-ago/