일을 통해 성장하기

대부분의 개발자가 직업으로서 만족하는 것들 중 하나는 일 자체가 학습을 요하고, 성장한다는 느낌과, 이것 자체게 큰 가치가 있다고 여기는 것으로 보인다.

그러나 대부분 개인 능력으로서의 성장은 측정하기 어렵다. 대부분 성장은 느낌이나 기분에서 끝나기도 한다. 그래서 오늘 성장했냐는 질문을 받을 때, 쉽게 대답할 수 없다.

대부분의 사람들은 잠자는 시간 이외의 삶을 일과 함께 한다. 일을 통해 성장하는 것이 가장 좋은 시나리오일 것이다.

하지만 이는 쉽지 않은 방법이다. 세미나나 컨퍼런스를 다녀보면,업무 외 새로운 지식이나 취미 활동에이를 갈고 있는 이들을 자주 본다.

나 또한 회사에서 충족하지 못하는 기회를 찾기 위해 업무 외부 활동에 관심을 많이 두는 편이었다.

그러나 현실은 이슈 혹은 티켓 단위로 업무를 받아 포인트를 매겨 처리하는 소프트웨어 종사자 일 뿐이었다.

어느 순간 게을러져 블로그 활동도 하지 않고, 하던 일만 반복하게 되면서 매너리즘에 빠지기도 했다.

나에게 할당된 컨베이어벨트 위 작업물이 오면, 빠르게 처리를 하고, 보고를 하고, 넘길 뿐이었다.

이런 환경에서 성장을 찾기란 매우 어렵다. 혹시나 이 글을 읽는 당신도 똑같지 않은가?

지금까지 나는 성장을 감각으로 여겼다.

머리가 지끈거리고,어깨가 뻐근한 그 감각. 이해하지 못해 답답하고,말 그대로 지끈거린다는 표현이 딱 맞았다.

지난 약 반년 간, 내가 속한 조직에서 일하면서 감각으로만 느끼던 성장에 대한 관점을 완전히 바꾸었다.

우리가 일하는 방식은 다음과 같다.

스프린트 플래닝 시 제품 목표에 따라, 인디케이터를 할당받거나 논의한다. 한 주 업무를 시작하기 전,일의 방향성을 담은 인디케이터를 정한다.

인디케이터는 팀장이 정할 수도 있고, 개인이 정할 수도 있는데, 개인의 능력에 맞는적절한 인디케이터를 정해야 하며, 직책자와 리뷰를 해야 한다.

그리고 각 개인은 인디케이터를 통해 테스트케이스 뽑는다. 여기서 테스트케이스는 QA 조직이 있는 조직에서 뽑는 테스트케이스와는 조금 다르다.

프로그래밍을 하는 개발자라면 개발한 기능이 Pass인지, Fail 인지를 판단하는 역할을 하면서도, 레벨링의 요소를 가지고 있기도 하다.

레벨링은 Poor, Normal, Good으로 정한다. 레벨링은 개발자의 과몰입을 막는 네비게이션의 역할을 하기도 한다.

또한 레벨링은 구성원 간 컨센서스를 이루어야 한다. 서버 개발과 같이 해야 할 프론트엔드 업무를 나혼자만 Good을 정해 달려갈 수는 없다.

레벨링은 조직의 목표를 만족하면서도, 최소한의 기능을 만족하고 이후에 기능을 발전시킬 수 있다.

만약 기획자라면 업무를 평가하는 요소로서의 테스트케이스를 지정해야 한다. 반드시 평가 요소가 정량적일 필요는 없지만, 어느 정도는 측정 가능해야 하고, 동료들에게 평가받을 수 있어야 한다.

개인의 업무 결과는 코드 리뷰를 통해 드러난다.

코드리뷰는 임원, 직원 할 것 없이 모두가 참여한다.

우리가 하는 코드 리뷰는 일반적인 회사에서 하는 리뷰나, 문법 체크이나 컨벤션 체크하는 그런 리뷰가 아니라, 지식을 확장시키는 용도로 하나의 아고라와 같은 모습이다.

코드리뷰에서는 갑작스러운 토론이 벌어지기도 하고, 감당못할 아이디어와 피드백이 쏟아진다. 누군가의 삽질을 웃으면서 보기도 하고, 동료의 소중한 지식을 쉽게 얻어가기도 한다.

스스로 인디케이터를 설정하고,테스트케이스의 레벨링을 만들고, 이를 통과하기위해 노력하고, 측정하고, 지식을 확장하는 반복되는 행위를 반년 간 한 덕분에나는 성장하고 있다.

지표를 통해 확인할 수도 있다. 입사 후 두 번의 스프린트의 테스트케이스를 통과하지 못하고, 인디케이터의 수준도 형편없었지만,

지금은 내가 설정한 인디케이터의 수준과 제품의 품질, 업무 시간을 조절하고 다른 학습하려는 욕심까지 생겼다. 그리고 코드 리뷰 덕분에 도메인 지식은 단 수 개월 만에 압축 성장했다.

성장... 안하고 살아도 된다. 괜히 스트레스 안 받아도 되고, 누구나 겪지는 않아도 될 거라 생각한다. 적당히 시간 보내면 넷플릭스에 재미있는 콘텐츠 만들어주는데, 그거 보면서 살면 되지 않나.

그러나 단 한 가지는 확실하다. 누군가는 생산하고, 만들고, 이끌어가고… 다른 누군가는 이끌려간다.

지금이야 수요와 공급의 불균형으로, 고용 시장에서 개발자가 우위에 있어 보이겠지만, 언제까지 이 현상이 유지될까.

프로그래밍의 진입 장벽이 낮아지고, 부트캠프가 많아지고, 수많은 노코드 도구나 자동화 도구가 만들어지고 있다. 내가 하지 않더라도, 시대정신으로 인해, 누군가는 멋진 작업들을 하고 있을 것이다.

만약 둘 중 하나를 선택해야한다면, 나는 이끌어가는 쪽을 택하고 싶다. 이는 어둡고 컴컴한 깊은 산속에서 호랑이를 마주쳤을 때,손에 걸리는 돌덩어리를 쥐어잡는 본능과도 같다.

우리는 매주 금요일에 코드리뷰를 하는데,전 구성원이 돌아가면서 몇 가지 항목의 KPI를 브리핑한다. 올해 주요 KPI 항목 중 가장 마지막 항목이자, 중요한 항목은 Site Developer이다.

Site Developer는 두 가지 축으로 나뉘는데 , 현대적인 기술적인 측면에서의 전문가가, 모빌리티 도메인에서의 전문가가 되는 것 그래서 모빌리티 리더가 되는것이 목표이다.

우리는 위 두 가지 측면에서 시장을 리딩하는 제품을 만들면서 성장하고 있다.

운좋게도 나는 개발자로서 커리어를 시작하자마자 좋은 멘토를 만났다. 그리고 6년 만에 다시 만나, 최고의 기술 리더와 모빌리티 분야의 리더인 동료들과 함께 일을 하고 있다.

내가 속한 팀을 외부 채널로만 접한다면, 좋은 평가가 없는게 당연하다. 아쉽게도 요즘의 추세는 이름이 알려진 갖춰진 회사에서 일하는게 대세이고, 그것도 좋은 선택이라고 생각한다.

하지만 개발자로 직장 생활을 해봤다면 알겠지만, 규모있는 제품을 밑바닥 인프라 설계 레벨부터 접해보면서 특히 좋은 동료들과 성장까지 해볼 수 있다는 건 자주 있는 기회가 아니다.