누구나 빠르게 성장하고 싶다. 얼른 신입 티를 벗고 1인분을 하고 싶고, 어떤 개발적인 문제든 능숙하게 해결하는 슈퍼 개발자가 되고 싶고, 다른 팀원들의 신뢰와 인정을 받고 싶고, 높은 연봉을 받고 싶다. 하지만 당연하게도 이런 사람은 그리 많지 않다. 전체 개발자 중에 손에 꼽는 사람만이 가파르고 지속적인 성장을 통해 돋보이는 수준의 성취를 이룰 수 있을 것이다.
그럴 수밖에 없는 이유는, 성장이 정말 어려운 일이기 때문일 것이다. 나는 성장을 더 많은 역할을 수행할 수 있게 되는 것이라고 생각한다. 새로운 역할을 수행할 수 있으려면 새로운 지식을 익히고, 새로운 종류의 고민을 하고, 익숙하지 않은 업무로 인해 새로운 실패를 맛보고, 실패를 인내하고 극복해야 한다. 이 과정은 많은 노력과 인내를 필요로 하는데, 충분한 의지나 의욕을 가진 사람은 드물다.
성장은 분명 어려운 일이지만, 누군가는 주변보다 훨씬 더 빠르게 성장한다. 이는 성장에도 '요령'이 있기 때문이다. 같은 양의 시간만큼 노력했더라도 그 시간 동안 무엇을 공부했고, 무엇을 고민했고, 어떤 경험을 쌓았느냐에 따라 성장의 정도는 천차만별이 될 수 있다.
그렇기 때문에, 성장에 목마른 사람에게 가장 중요한 것은 시간을 효율적으로 사용하는 것이다. 시간을 어떻게 활용해야 효율적인 걸까?
세상에는 다양한 종류의 개발자가 있다. 직군만 하더라도 네이티브 앱 / 웹 / 서버 / DevOps / 데이터 엔지니어링 등이 있고, 커리어 트랙도 크게 매니저/디렉터/CTO 트랙과 스페셜리스트 트랙으로 나뉜다. 같은 직군과 직책의 사람이더라도 회사의 상황과 개인의 성향에 따라 모두 조금씩 다른 역할을 수행하고 서로 다른 장단점을 가진다.
욕심이 많은 우리는 당연히 네이티브 앱과 웹과 서버와 DevOps와 데이터 엔지니어링을 모두 잘하고 싶다. 모든 분야가 흥미로워 보인다. 하지만 현실적으로 이 모든 분야에서 전문성을 갖추는 건 불가능하다. 시간이 부족하기 때문이다. 세상에는 어마어마하게 많은 개발 지식이 존재하고, 앞으로도 수많은 기술과 패턴, 개념이 쏟아져 나올 것이다. 이를 모두 공부하는 것은 한 사람의 인생을 쏟아부어도 불가능하다. 커리어 트랙에 대해서도 마찬가지다. 기술적으로도 뛰어나고 커뮤니케이션도 훌륭히 수행할 수 있어서 스페셜리스트 역할과 CTO 역할을 둘 다 수행할 수 있는 사람이 존재할 수는 있다. 하지만 능력이 충분하더라도 현실적으로 둘 다 수행할 수 있는 시간이 없을 것이다. 아무리 열심히 일해도 하루에 24시간 이상 일할 수는 없기 때문이다.
결국 우리는 선택과 집중을 해야만 한다. 우리는 무한한 가능성 속에서 어떤 지식을 습득할 것인지, 어떤 역할을 맡을 것인지 선택하기를 강요받는다.
이러한 선택의 순간에 만족스러운 결정을 내리기 위해서는 좋은 기준, 즉 목표가 필요하다. 개발 지식을 익히는 것 자체가 재미있는 개발자는 그 시점에 가장 흥미로운 개발 경험을 할 수 있는 선택지를 고를 것이다. 현재 커리어를 밀고 나가고 싶은 개발자는 현재 커리어에 가장 도움이 되는 선택지를 고를 것이다. 반면 커리어를 전환하고자 하는 개발자는 상반된 선택지를 고를 수도 있다. 어쨌든 중요한 건 선택의 기준이 되는 자신만의 목표를 가지는 것이다. 목표는 그 사람의 선택, 그 사람의 시간, 그 사람의 노력에 더 많은 의미를 부여한다.
'나는 어떤 개발자가 되고 싶은가?' 빠르게 성장하고 싶다면 반드시 이 질문에 대한 자신만의 답을 가지고 있어야 한다. 원하는 성장의 방향성이 없다면 성장의 효율이 떨어지고, 심지어 성장이 무엇인지 정의할 수도 없게 된다. 이 질문에 대한 답을 가진 사람과 그렇지 않은 사람은 선택이 누적되면 누적될수록 어마어마한 성장 차이를 보이게 될 것이다.
목표를 이루기 위해서는 두 가지 요소가 필요하다. 첫 번째는 좋은 계획을 수립하는 것이고, 두 번째는 계획을 올바르게 수행하는 것이다. 회고는 이 두 가지를 실천하는 데에 필수적이다.
우선 계획을 세우는 측면에 대해 이야기해보자. 계획을 세우려면 우선 현재 상황과 목표에 대한 구체적인 이해를 해야 한다. 내가 목표하는 개발자가 되기 위해 어떤 능력을 갖추어야 하는지를 알고, 내가 지금 갖추고 있는 능력이 어느 정도인지를 인지해야만 그 차이를 메꾸기 위한 계획을 세울 수 있다. 하지만, 자신이 얼마만큼의 능력을 갖추고 있는지를 객관적으로 알아내기란 매우 어렵다. 개발 지식의 측면에서는 그나마 알기 쉽지만, 자신의 소프트 스킬을 가만히 앉아서 수치화하는 것은 거의 불가능에 가깝다.
회고는 자신을 객관적으로 이해하는 데에 큰 도움을 준다. 회사에서 다양한 프로젝트와 상황을 마주하는 과정에서 자기도 모르는 자신의 장단점이 자연스럽게 드러난다. 이를 그 시점에서 인지하기는 어렵지만, 시간이 지나고 넓은 시야로 자신의 행동을 되돌아보면 충분히 캐치해낼 수 있다. 이를 통해 자신에 대해 조금씩 알아가게 되고, 이를 기반으로 더 좋은 계획을 세울 수 있다.
다음은 올바른 계획의 실행과 관련된 측면이다. 당연하게도, 계획을 세운다고 해서 항상 모든 것이 계획대로 흘러가지는 않는다. 의지와 시간이 부족해서 계획을 제대로 못 따라갔을 수도 있고, 제어할 수 없는 외부 변수로 인해 상황이 달라졌을 수도 있다. 이 때문에 상황에 맞게 계획을 보완하고 수정해줘야 한다.
회고는 계획을 보완하고 수정하기에 최적의 방법이다. 계획의 실행은 나무를 보는 것이고, 회고는 숲을 보는 것이다. 계획을 우직하게 실행하다 보면 현재 상황을 잘 파악하기가 힘들다. 가끔은 멈춰서서 지도를 펼치고, 지금 자신이 어디에 서 있는지 인지하고, 목표 지점을 다시 확인하는 작업이 필요한 법이다. 회고는 정확히 이런 역할을 한다. 회고를 통해 현재 상황을 파악하고, 계획이 얼마나 순조롭게 실행되고 있는지를 판단할 수 있다. 그리고 현 상황에 맞춰 계획을 보완할 수 있다.
위에서 어떤 목표를 설정했든 간에, 나는 신입과 주니어가 가져야 하는 최우선 목표는 1인분을 하게 되는 것이라고 생각한다. 즉, 시니어의 도움 없이도 혼자 프로젝트에 참여해서 개발을 진행할 수 있는 능력을 갖춰야 한다. 이는 1인분을 하는 게 모든 커리어의 시발점이기 때문이다. 혼자서는 개발을 할 수 없고 다른 사람의 케어가 필요하다는 것은 개발자라면 응당 갖춰야 할 지식과 능력을 아직 갖추지 못했다는 뜻이다. 이러한 상황에서 다른 방향으로 성장하겠다는 것은 어불성설이다.
1인분을 한다는 목표를 이루는 가장 효율적인 방법은 '지금 몰라서 가장 불편한 지식을 익히는 것'이다. 그 이유는 지식을 체화하는 속도에 있다.
개발 지식은 단순히 알고 있다고 내 것이 되는 게 아니다. 필요한 순간에 필요한 지식을 떠올리고, 지식과 지식을 연관짓고, 지식을 활용해도 되는 상황인지 아닌지를 판단할 수 있어야 내 것이라고 할 수 있다. 이렇게, 지식을 자유자재로 활용할 수 있게 되는 것을 나는 지식의 체화라고 부른다. 지식은 체화했을 때만 비로소 가치를 가진다.
회사 프로젝트는 지식을 체화하기에 가장 좋은 환경이다. 회사에서 진행하는 프로젝트만큼 다양한 요구사항이 존재하는 토이 프로젝트는 없다. 다양한 요구사항은 기술을 다각도로 응용할 수밖에 없는 상황을 제공하여, 개발자로 하여금 기술에 대해 깊은 이해를 가지도록 강제한다. 또한 회사 프로젝트에 배운 것을 잘못 적용하면 보통 시니어가 리뷰를 통해 잘못된 부분을 지적해주기 때문에 지식의 활용 방법을 더욱 빠르게 익힐 수 있다.
강조하고 싶은 한 가지 포인트는 회사의 코드베이스를 공부하는 것이다. 여기서 말하는 코드베이스에는 개발팀이 사용하는 기술 뿐만 아니라 회사의 도메인과 비즈니스 로직, 그리고 히스토리까지 포함된다. 회사의 코드베이스는 회사의 비즈니스 로직을 작성하는 데에 최적화된 일종의 프레임워크라고 생각할 수 있다. 이를 모른다면 기능을 개발하는 데에 어려움을 겪고, 다른 팀원에게 기대야만 하는 상황이 자꾸만 발생한다. 예를 들어 해당 도메인의 히스토리를 몰라 지금 고친 코드가 어떤 곳까지 영향을 미칠지 제대로 파악하기 어렵거나, 서버 구조를 잘 몰라 배포를 할 줄 모를 수 있다. 이런 상황에서는 결국에는 다른 팀원의 손을 빌리게 된다. 이는 성장의 기회를 크게 제한한다. 이런 상황에서 벗어나기 위해, 회사의 코드베이스를 이해하는 데에 많은 노력을 기울이자.