회사에서 빠르게 성장하는 법

스타트업에서 자주 언급되는 말이 있다. 사람은 선형적으로 성장하고, 회사는 기하급수적으로 성장한다. 회사가 너무 빨리 크면 내가 페이스를 따라가지 못해 힘들고, 너무 완만하게 크면 지루해진다. 결국 개인이 의식적으로 성장 속도를 끌어올리는 장치를 만들어 두어야 한다.

1. 피드백 사이클을 짧게 만든다

성장은 피드백의 빈도에 비례한다. 사이클이 짧은 것부터 나열하면 다음과 같다.

주기	방법
매일·매주	자기 회고 (가장 짧은 피드백 루프)
주/격주	리더와의 1on1 피드백
분기	사내·외 멘토 3~5명에게 연락해 조언 구하기
반기·연	정기 리뷰 (제도가 없으면 자청해서 받기)

멘토는 멀리 있는 구루보다 나보다 한두 단계 앞서 있으면서 잘한다고 알려진 사람이 현실적인 조언을 준다.

2. 나는 드라이버인가, 병목인가

처음에는 모든 일을 조금씩 하다가 점점 많은 일을 맡게 되고, 어느 순간 내 역량을 넘어서는 시점이 온다. 이때 나는 조직을 앞으로 끌고 가는 드라이버인지, 일을 막고 있는 병목인지 스스로 물어야 한다. 병목이라면 위임·자동화·역량 확장 중 무엇이 필요한지 판단한다.

3. 업무 난이도를 스스로 올린다

같은 일을 반복하면 성장이 멈춘다. 주어진 과제에 다음을 하나씩 얹어 보면 자연스럽게 난이도가 올라간다.

품질: 테스트 코드 작성, 성능 프로파일링
구조: 공통 모듈 만들기, 익숙하지 않은 라이브러리로 바꿔 보기
자동화: CI/CD 붙이기, Docker 이미지로 테스트 환경 구성, 반복 운영 작업 자동화, 모니터링 붙이기
문서화: 소스 코드에서 바로 빌드되는 문서, API 문서, 문서화 사이트
사람: 팀원에게 가르치기 (설명할 수 있어야 진짜 아는 것)

4. 이직은 '도망'이 아니라 '목표'일 때

퇴사하고 싶을 때가 아니라 가고 싶은 회사가 생겼을 때 옮긴다.
짧은 주기의 잦은 이직은 면접에서 불리하게 작용할 수 있다.
판단 기준은 개발에 집중할 수 있는 환경인지, 업무 비중이 내가 가려는 방향과 맞는지다.
경험은 평소에 프로젝트 단위로 정리하고 결과를 수치로 남겨 둔다. 경력이 짧아도 설명할 수 있는 성과가 경쟁력이 된다.
지원 동기는 어느 회사에나 붙는 이유가 아니라 그 회사여야 하는 이유를 찾을 때 설득력이 생긴다.
채용 과정에서 지원자의 시간과 컨디션을 배려하는지는 그 회사의 일하는 문화를 미리 보여 주는 신호다.

5. 묻고, 나누고, 참여한다

성장이 빠른 주니어에게는 공통된 습관이 있다.

습관	실천
왜를 묻는다	코드와 결정마다 왜 이렇게 했는지 묻는다. 이유를 모르고 따라 하면 같은 상황이 조금만 바뀌어도 다시 막힌다
알아서 하지 말고 알아보고 한다	짐작으로 진행하기 전에 먼저 찾아보고, 그래도 모르면 묻는다. 선배 입장에서는 귀찮게 묻는 후배가 혼자 엉뚱하게 진행하는 후배보다 훨씬 낫다
배운 것을 공유한다	블로그, 사내 세미나, 발표, 책. 방식은 무엇이든 좋고 꾸준함이 중요하다. 나눈 것보다 더 큰 것이 돌아온다
잘하는 사람이 많은 곳에 참여한다	오픈소스 기여, 스터디, 커뮤니티 활동에 적극적으로 끼면 기회가 생긴다. 함께할 사람이 주변에 없으면 컨퍼런스, 밋업, 연합 동아리, 온라인 커뮤니티로 범위를 넓힌다
묻기 전에 조사한 범위를 보여 준다	「어디까지 찾아봤고 무엇이 막혔는지」를 함께 말하면 답이 빠르고 정확해진다
복붙하지 않고 원리를 본다	가져온 코드가 왜 동작하는지, 기존 코드와 어떻게 맞물리는지 이해한 뒤 쓴다
실수는 절차로 막는다	문제의 원인을 되짚고, 같은 실수가 반복되지 않도록 확인 절차를 만든다
디버깅은 범위를 좁혀 간다	정상 동작을 먼저 정의하고, 확인 범위를 한 단계씩 좁힌다
후배를 가르친다	질문에 성실히 답하고 스터디·프로젝트를 이끌면 설명하다 막히는 곳에서 내 빈틈이 드러난다. 도움받은 사람이 다시 후배를 돕는 선순환이 생긴다

같은 물고기도 어항에서는 작게, 강에서는 크게 자란다는 코이의 법칙처럼, 성장의 크기는 환경과 곁에 있는 사람을 따라간다. 믿어 주고 인정해 주는 사람들 곁을 고르고, 나도 그런 환경이 되어 준다.

스스로에게 "나는 어떤 사람과 일하고 싶은가"를 물어보고, 그런 사람이 되는 것이 출발점이다. 함께 일하고 싶은 동료에게는 공통점이 있다.

일을 받으면 그냥 하지 않고 의미와 중요도를 먼저 따진다.
생각을 말이나 글로 분명히 드러내 주변이 짐작하지 않아도 된다.
하나하나 지시를 기다리지 않고 필요한 권한·자원을 스스로 요청한다.
맡기로 한 일은 끝까지 책임진다.
실패하면 노력에 만족하지 않고 배운 것을 다음 일에 반영한다.
단점이 없는 사람보다 뚜렷한 장점을 꾸준히 갈고닦는 사람이다.

6. 나에게 누적되는 것

AI가 코드와 글을 대신 만들어 주는 환경에서는 도구 이름이 아니라 어떤 도구를 쓰든 나에게 쌓이는 역량을 기준으로 커리어를 설계한다. 도구를 성과로 바꾸는 판단, 행간을 읽고 당위성을 증명하는 일이 쌓여야 "왜 당신이어야 하나"에 답할 수 있다.

원칙	뜻	실천
새 기술은 깎아내리기보다 써먹는다	허점을 찾는 사람보다 빨리 적응해 업무에 쓰는 사람이 기회를 잡는다	결과물 품질을 걱정하기 전에 그 위에 무엇을 얹을지 고민한다
본캐에 수렴하는 부캐	부캐는 취미가 아니라 본업을 단단하게 만드는 두 번째 정체성이다(글쓰기, 어학, 자격증)	직무 역량 기준을 다시 읽고 키울 항목을 고른다. 영어를 잘하는 ML 연구자처럼 본캐와 만날 때 강점이 생긴다
1년에 100일 프로젝트 두 개	일 년 내내 빡빡하게 달리는 것은 지속할 수 없다	목표가 분명한 것을 100일 안에 끝내 릴리즈하고, 혼자 못 하는 부분은 위임하거나 함께할 사람을 모은다
온도계가 아니라 온도 조절기	상황을 보고하는 데서 멈추지 않고 바꾼다	일의 목적부터 정리해 판을 짜고, 겉으로 보이는 정보 대신 사람을 만나 행간을 확인한다

7. 코드 밖까지 보는 시야

주니어와 시니어의 차이는 코드 실력보다 코드가 돌아가는 환경과 서비스 전체를 얼마나 고려하느냐에서 크게 난다.

시니어가 고려하는 것	내용
실행 환경	컨테이너, 로드 밸런서, 샤딩 같은 인프라 구조가 코드 동작에 영향을 준다
하위 호환성	배포 중에는 여러 버전의 서버·클라이언트가 공존한다. API와 DB 스키마는 필드 추가는 안전하지만 삭제·변경은 기존 사용처를 깬다
일반화의 정도	확장 방향이 불확실하면 섣불리 추상화하지 않고, 나중에 쉽게 걷어낼 수 있게 결합도를 낮춘다
도메인 지식	기획과 도메인을 깊이 알면 잠재 위험을 미리 없애고, 기획자와 대화할 때 의견에 설득력이 생긴다

8. 첫 과제를 진행하는 법

신입 파일럿 프로젝트나 처음 맡은 기능처럼 혼자 끝까지 가는 과제에서 통하는 원칙이다.

핵심부터 설계하고 넓힌다. 핵심 엔티티와 관계만 먼저 정하고 검토를 거쳐 범위를 키운다.
경험자에게 설계를 검토받는다. 논리적으로만 설계하면 성능·운영 제약을 놓친다.
필수와 선택을 나눈다. 남은 기간으로 작업량을 추산하고 필수 기능부터 끝낸다.
진행 상황을 누구나 보는 곳에 적는다. 피드백이 빨라지고 일정이 분명해진다.
낯선 기술은 핵심 개념부터. 학습 시간을 과소평가하기 쉽다. 원리를 먼저 잡고 세부는 구현하며 익힌다.
규모에 맞는 가벼운 도구를 고른다. 요구를 넘는 도구는 기간과 학습 부담만 키운다.
리뷰 지적을 기준으로 단계적으로 고친다. 여러 번의 DB 조회를 하나로 합치는 식의 피드백이 다음 설계의 기준이 된다.

9. 성과를 증명하는 법

성과는 들인 시간이 아니라 결과로 평가받는다. 결과는 처음부터 증명할 수 있게 설계해야 남는다.

원칙	실천
측정 방법을 먼저 정한다	작업을 시작할 때 무엇으로 성공을 판단할지, 필요한 로그와 A/B 실험을 함께 설계한다. 측정할 수 없는 작업은 성과로 증명되지 않는다
목표는 단순하게	근거는 데이터로 복잡해도 목표는 한 문장이다. 무엇(What)은 위에서 합의하고, 어떻게(How)는 실무자가 정한다
말이 아니라 문서로	아이디어와 결정은 메신저가 아니라 문서로 남겨 근거로 쓴다
범주를 나눠 채운다	프로젝트 영향력, 엔지니어링 역량, 협업·사람, 방향 설정·리더십처럼 범주를 나누고 연차에 맞는 수준과 비교해 빈 범주를 의식적으로 채운다
평소에 기록한다	평가 시기에 몰아 쓰지 않고 일이 끝날 때마다 숫자(성능, 커버리지, 리뷰 수)와 함께 적는다. 중간 피드백을 요청해 평가 전에 고친다
보이지 않는 일도 성과로	불편한 프로세스를 고친 일, 발표·문서화·멘토링 같은 협업 기여도 성과다. 필요하지만 성과가 불분명한 일은 측정 가능한 형태로 바꿔서 추진한다

10. 좋은 프로그래머의 징표

징표	모습
먼저 실험한다	새 언어·도구를 가볍게 시도해 본다
코드와 자아를 분리한다	더 나은 대안이 나오면 자기 설계를 버린다. 리뷰 지적을 방어하지 않고 검토한다
명세의 의도를 읽는다	요구사항을 글자 그대로가 아니라 누가 왜 정했는지까지 이해한다. 실제 사용자의 이야기를 직접 듣는다
동작하는 코드도 다시 본다	새 기능을 넣기 전에 기존 설계를 점검하고 단순하게 만든다
기본기를 존중한다	당장 안 쓰는 분야의 원리도 공부하고, 다른 분야의 전문성을 존중한다
플랫폼 관례를 따른다	모든 환경에 같은 방식을 강요하지 않는다
도구를 만든다	반복 작업은 스크립트·벤치마크·프로파일러로 자동화한다
내 코드부터 의심한다	컴파일러·라이브러리를 탓하기 전에 자기 코드를 먼저 점검한다. 막히면 잠시 떨어져 원인을 논리적으로 좁힌다

핵심 정리

피드백 주기를 짧게, 멘토는 가까운 선배로.
일이 많아질수록 드라이버인지 병목인지 점검한다.
업무에 테스트·자동화·문서화·교육을 얹어 난이도를 올린다.
이직은 끌림(pull)으로, 밀림(push)으로 하지 않는다.
왜를 묻고, 알아보고 묻고, 배운 것을 나누고 가르치며, 잘하는 사람들 곁에 선다.
도구가 아니라 나에게 쌓이는 역량을 기준으로, 본캐를 키우는 부캐와 100일 프로젝트를 고른다.
코드가 돌아가는 환경, 하위 호환성, 도메인까지 시야를 넓힌다.
첫 과제는 핵심부터 설계하고, 필수부터 끝내고, 진행을 공개한다.
성과는 측정 방법을 먼저 정하고, 범주별로 평소에 기록한다.

버그 제보