by
Aug 06. 2019
개인의 '성장'과 회사의 '성장'
'성장'에 갈증을 느끼는 사람을 위하여(개발자 편)
커뮤니티를 운영하면서
많은 사람들을 만나곤 합니다.
점심 약속이나 저녁 약속, 다양한 스타트업에 있는 사람들,
그리고 이직을 꿈꾸는 사람들
그리고 성장에 목말라하는 사람들
그리고 하나같이 '성장'에 목말라 있었습니다.
문득 그런 생각을 했습니다. 대기업에 근무하고 있다고 하더라도 회사의 성장과 개인의 성장은 매우 별개라는 사실, 스타트업에서 근무하는 회사가 성장하더라도 또 그 안에 소속된 개인과의 성장과는 또 매우 별개라는 사실. 이 두 가지가 시사하는 바를 토대로 개인이 갈증을 느끼는 여러 가지 이유에 대해서 분석하고 공유해 보면 좋겠단 생각이 들었습니다.
어떻게 하면 '성장' 할 수 있을까요?
개인의 성장, 그리고 회사의 성장, 그리고 개발자로서 성장에 대해서 어떤 관점들을 가지고 가면 좋을지에 대해서 생각을 던져보려고 합니다.
회사의 '성장'이 꼭 개인의 '성장'이 아니다.
첫회사는 나름대로 큰 회사였습니다. 조직이 있었고, 체계가 있었고, 그리고 여러 가지 일이 쪼개져 있었습니다. 그러다 보니 맡은 업무들이 명확한 부분이 있었습니다. 다만 자신의 일이 아닌 타 업무에 대해서는 알고 싶어도 접근하기 어려운 구조를 가지고 있었죠.
반면 스타트업에 다니는 주니어 친구들이 경험하고 싶어 하는 것 중에 하나는 '체계'입니다. 커뮤니티에서 고민들을 늘어보면, 늘 체계가 있는 곳에서 제대로 배워보고 싶다는 의견들이 많았는데요. 체계가 있는 곳에서는 자신이 해야 할 일이 정해져 있는 곳이 많다는 것입니다. 그렇게 해야 할 일이 정해져 있는 것에는 분명한 장점이 있지만 그만큼의 단점이 있습니다. 물론 일의 양이 케바케라는 문제도 있지만, 자기의 일을 묵묵히 수행할 수 있으면 더 이상의 많은 개발을 필요로 하지는 않는다는 것입니다. 일의 양이 정해져 있다 보면, 그 일을 수행하면 더 이상 할 일이 없습니다. 굳이 일을 더 만들 필요도 없습니다. 그러다 보니 새로운 것들을 배우고 싶은 입장에서는 매우 지루한 시간들이 되기 마련입니다.
제 첫 직무는 인사팀이었습니다. 인사 DB를 볼 수 있고, 현업에서 인사에 관련된 흐름을 볼 수 있다니, 너무 기대가 되었습니다. 이 기대가 유지되었던 것은 딱, 6개월이었습니다. 4개월째가 되었을 때, 대부분의 인사 팀 조직의 개발팀이 여유롭다는 소리를 들었지만, 실제로 이렇게 할 일이 많지 않을 것이라곤 예상을 못했죠. 물론 시기적 부분도 있었고 추후에는 차세대 프로젝트를 하게 되면서 그 할 일의 대 부분이 뒤로 밀렸지만, 일단 유지되고 있는 시스템에 있어서 대부분 잘 굴러가는 조직에서 할 일은 거의 없었습니다. 내면에서는 '개발'을 하고 싶고 '경험'을 쌓고 싶다는 생각이 들었습니다.
그리고 정말 운이 좋게도 6개월 뒤에 개발만을 하는 경영팀 산하 조직으로 들어가게 되었지만, 만약 그렇지 않았다면 개발을 많이 경험하지 않은 채 운영만 하다 끝났을지도 모르는 일입니다. 계속 그 인사업무만 했다면 뭔가 설계해볼 기회고 주어지지 않았을 테니까요. 그만큼 큰 기업에서는 기회가 모두에게 공평하게 주어지지 않습니다. 그리고 시스템을 운영하는 입장에서는 때로 점점 뒤처지고 있다는 생각이 드는데요. 그 불안감이란 이루 말할 수 없죠. 운영을 해본 입장에서는 일이 편한 것이 마냥 일이 편한 게 아니라는 것을 느낄 수 있습니다.
이런 경험에 비추어 큰 회사에 다닌다고 해서 개인의 성장이 보장된 것은 아닙니다. 능력도 천차만별이고, 조직은 어떻게든 뽑힌 인력을 기준으로 회사를 경영하고 꾸려 가야 하기 때문입니다. 그럼에도 불구하고 큰 회사에 경험되는 부분들이 있는 것은 사실입니다. 조직이 성장하게 되었을 때, 회사가 커졌을 때 어떤 식으로 일을 분배하고 처리할 것인지, 일하는 방식, 조직화된 문화, 그런 전체적인 맥락들은 배울 수 있을 것입니다. 이런 부분을 비추어 회사의 성장과 개인의 성장을 분리시켜 생각할 필요가 있습니다.
업무적인 '성장'의 한계
요새 '도메인' 주도 설계라는 DDD에 대한 개념이 다시 부각되고 있습니다. 그만큼 기술에 대해서 '설득' 하고 논리적인 구조로 접근하는 것도 중요하지만, 업종의 이해, 업종 전문가에 대한 생각을 기반으로 설계에 집중해야 개발을 번복하지 않게 된다는 것인데요. 보통 회사에서 업무라고 하면 개발자의 입장에서는 기술의 습득이 포함되겠지만, 업종에 대해서 이해하는 것입니다.
첫 회사의 특성상 엔지니어링이라는 회사에서 하는 일이 무엇인지, EPC라는 것은 무엇인지. 회사가 플랜트 회사를 유지하기 위해 운영하기 위해 알아야 할 업종 지식에 대한 지속적인 학습과 꾸준한 업종에 대한 현황과 세미나들을 듣게 될 기회가 많았습니다. 그만큼 개발 기술에 대하여는 조금 부족하더라도 업종 지식만큼은 각각 전문적인 영역들을 가지고 가고 있었고 그 업종 지식 만으로도 먹고사는 것에 지장이 없겠다는 생각이 들었는데요. 그만큼 개발의 관점 이외에 도메인의 중요성을 일을 하면서 많이 체감하게 되었습니다.
하지만, 업무를 반복하게 되고 하는 일이 숙달되다 보면, 개발자로서 과연 성장이 어디서 오는지에 대한 질문이 다시 맴돌게 됩니다. 경영과 관련된 시스템을 다양하게 만들었습니다. CEO 블로그, 해외 소통을 위한 블로그, 내부 조직도, 혁신과제, 강연 시스템, 상담센터, 사우 협의 블로그, 내부 포탈 및 관리 화면, 자산관리, 모니터링 통계, 지식 정보 공유 관리 등등 사내 경영과 관련된 시스템들을 운영하고 개발하고 어떤 부분은 부분으로 참여하기도 하고 또 메인으로 참여하기도 하면서 구조에 익숙해져 갔는데요. 이런 업무적으로 할 수 있는 일들이 늘어나더라도, 여전히 서비스 환경은 열악하고, 흔히 말하는 레거시 시스템들에 둘러 쌓여있었고, 주변에 개발자들은 점차 최신의 기술을 적용하고 찾아가고 있었고, 큰 회사에서는 굳이 잘 굴러가고 있는 시스템을 최신화시킬 이유가 없었기 때문에 '유지'에 집중했습니다.
예전 실용주의 프로그래머라는 책을 매우 인상 깊게 보있었는데요. 그 챕터 중에 끓는 물에 개구리를 넣는 장면이 나옵니다. 간단히 말해 끓는 물에 개구리를 넣으면 개구리는 죽을 것을 바로 눈치채고 그 물을 뛰어넘어 도망치지만, 물을 서서히 끓이면 개구리는 눈치채지 못하고 죽게 된다는 내용인데요. 인생의 교훈이 담겨있었습니다. 분명한 건 개발자로서 도메인도 중요하지만 기술을 못 따라가면 그럼 개구리꼴이날 것이 분명하다는 것입니다. 스트럿츠와 스프링, 이 두 가지 기술로도 분명 먹고는 살 수 있었지만, 진보하는 프런트 기술과 과연 경쟁할 수 있을지 늘 의문이었고, 그래서, 스타트업으로 가서 시장에서 필요로 하는 것들을 배우기로 했습니다.
“8년 차 개발자, 스타트업 회고(1년 3개월)”
스타트업에서 배운 내용들입니다. 분명한 건, 짧은 시간이지만 스타트업에서 얻을 수 있는 많은 경험이 있다는 것이었고, 새로운 기술에 대해서 적응하는 시간이었습니다.
'기술'의 성장만이 답일까?!
업무적인 부분에 한계를 느끼고, 기술에 대해 다양하게 경험했다고 해서 '성장'에 대한 갈증이 멈추었는가 보면 또 그러하진 않습니다.
요새 폴리글랏 프로그래밍이라는 단어에 꽂혔습니다. 프로그래머가 하나의 언어에 안주하지 않고 계속 새로운 패러다임을 추구하고 여러 언어를 자유롭게 구사한다는 뜻인데요. 언어에 구애받지 않는 개발자! 멋진 뜻입니다.
사실은 하나의 언어만 잘하기도 어려운 세상에서 괜스레 분산 투자는 폭망입니다.
그렇다고는 하지만 여전히 다른 언어를 공부하고 관심을 갖는 일은 개발자로서는 마땅히 흥미 있고 재밌는 일입니다.
첫 언어는 c > cpp > mfc > window mobile이었습니다. 윈도 계열이 재미있어서, 첫 프로젝트도 mfc로 진행했고, 아마 그쪽에 취업을 하게 될 줄 알았는데요.
첫 번째 회사였던 음성인식 설루션 회사를 거쳐 두 번째 회사에서는 자바 언어였습니다. 강제로 언어 체인지를 당한 것이죠. 사실 전공자 입장에서는 이런 일들이 많이 일어나게 되는데요. 인생은 뭐 어찌 될지 복불복입니다.
Swing으로 Pos 시스템 구현을 회사 신입사원 교육 때 프로젝트로 시작을 해보면서, 그 뒤로 급작스레 자바와 웹에 대한 개념을 뒤늦게 익히면서 어찌 보면 업무에 따라서 언어적인 기술 스탯도 계속 변화된 경우입니다.
JAVA > STRUTS > SOAP > SPRING > SPRING BOOT 이런 형태로 자바의 경우는 경험들이 바뀌어 왔는데요.
어느 정도 다양한 프레임워크들을 쓰다 보면, 각기 장점이 있고, 그것을 쓰는 용도와 의미가 있다는 생각들을 하게 됩니다. 이런 부분으로 다양함을 경험하는 것은 의미가 있습니다.
새로움만 쫓아가기엔 기술의 성장 속도가 너무 빠른 부분도 있고, 또 현재에 안주해서 같은 것만 보고 있기엔 재미가 없으니 말이죠.
보통 회사가 안정되면 위험한 시도는 하지 않습니다. 모두 갈아 없는 건 매우 위험한 일이죠. 그래서 금융의 경우는 아주 오래된 언어들을 종종 마주하곤 합니다. 물론 큰 기업들에서 한두 개쯤은 모셔놓은 곳들이 있습니다. 갈아엎고 싶은 개발자의 입장에서는 매우 답답한 부분이지만, 때론 받아들여야 하는 순간도 오게 되죠. 이렇게 받아들이는 것도 일종의 노력이 들어가는 일입니다.
이런 레거시를 경험하다 보니 기술을 찾게 되었는데요. 이런 기술을 찾아가고 쫓다 보면 기술만으로의 한계도 느끼게 됩니다. 기술은 언제나 바뀌는 것이라는 생각이 저변에 깔리게 되고 그 때문인지, 그 기술이 나의 것이 아니라 남이 만들어 놓은 좋은 기술을 빌려 쓰는 입장으로 바라보게 됩니다.
프런트의 입장에서는 엥귤러인가 뷰인가 리 엑트 JS 인가의 고민들을 하게 되고, 안드로이드는 기존을 유지할 것인가 코틀린으로 갈아탈 것인가를 고민하게 되고, 아이폰은 기존 ObjectC를 쓸지 또 스위프트로 갈아탈 것인지를 고민하는 것입니다.
시간은 유한하고 회사의 일은 그대로인데 새로운 기업에서 바라는 인재상은 계속 과거에 머물러 있지 않고 이미 저 먼 미래에 있습니다. 이런 부분이 개발자들에게 조급함을 주기도 하지만, 실상은 내실이 더 중요한 경우가 많습니다.
결론은 기술의 성장도 중요하지만 어떤 프래임워크를 선택하고 구성하는 부분 이외에도 가져야 하는 많은 고민들이 있습니다. 하나의 서비스를 완성시키기 위해서는 서비스의 론칭시점, 고객의 특성의 이해, 시장의 반응, 앱인지 웹인지 어떤 플랫폼을 선택할지에 대한 선택 등등 그 외에도 에 대한 고민의 시간이 어쩌면 더 늘어나야 한다는 것입니다.
다 때가 있다
큰 회사에 오래 있다 보면 무뎌집니다. 그래서 가끔은 스타트업 조직에 맞지 않는 사람이 큰 기업에서 낙하산처럼 내려와 조직과 잘 맞지 않고 삐걱된 경험을 하신 부분들을 볼 수 있는데요. 확실한 것은 문화적 차이와 경험적 차이, 그리고 해야 하는 관점적 차이가 여전히 존재하기 때문에 이 갭을 줄이기 위해서는 상호 간의 많은 노력이 필요합니다. 조직의 매우 초기에는 사실 성과나 일 중심으로 아웃풋이 나올 수 있게 만들 조직이 필요하고, 추후 조직이 커졌을 때는 그만큼의 관리 역량을 갖춘 큰 기업을 경험한 분이 필요합니다. 시점적인 차이로 미리 마찰을 겪게 되는 부분인데요. 팀장 혹은 팀원을 뽑을 때는 장기적 관점도 바라보아야 하지만, 단기적 성장을 어떤 식으로 끌고 갈지 그리고 앞으로 장기적으로는 어떻게 해야 할지에 대한 단기, 중기, 장기적 플랜을 다르게 구성해야 합니다.
'관리' 포인트와 조직의 성장
스타트업에 있을 때, 조직의 리더가 해야 하는 부분이 무엇 일지에 대한 생각을 많이 해보았습니다. 역지사지의 입장이었는데요. 회사를 유지하기 위해서 자금도 끌어와야 하고 투자자도 상대해야 하고, 사람들도 관리해야 하고, 개발자에게 개발을 맡기기 위해 시간도 투자해야 했습니다. 전 개발자 입장에서 이 시간을 단축시켜드리기 위해서 의사소통 비용을 줄이기 위해서 되도록 화면을 직접 수정해서 보여드리는 방식으로 이해를 도왔는 데요. 대부분은 보기 전에 이해하기가 힘들기 때문에 보고 난 뒤에 재작업이 일어나는 경우가 많아서, '백문이불여일견'이라는 표현도 있지만, 보는 것이 훨씬 빠릅니다. 보여드리고 일을 진행한 경우가 많았습니다.
그 전 회사에서는 기획이 나오면 수정은 거의 기대하기 힘들었는데요. 그만큼 큰 회사와 작은 회사는 일의 속도나 수정 이슈 등 대응해야 하는 항목과 이슈들이 다릅니다.
그리고 이번 프리랜서, 프로젝트를 통해서는 조직을 리딩 하는 것에 대해서 경험을 해보았는데요.
확실히 혼자 이모저모를 할 때와 남의 밑에서 시키는 일만 할 때, 그리고 일을 배분하고 프로젝트를 수행할 때 가져야 할 역량은 확실히 큰 차이가 있었습니다.
회사가 성장하기 위해서는 서비스도 만들어야 하고 조직 구성원이 각각에 주어진 역할에 대한 이해도 필요하고, 그리고 앞으로의 비전 공유와 어떤 일을 왜 하는지에 대해서 서로가 강력한 공감이 바탕이 되어야 한다고 생각합니다. 아마 기업이 커져갈수록 이런 조직이 하나라는 느낌보다는 점점 잘게 쪼개어지는 것들을 경험하게 되겠지만, 성장에는 성장통이 따르고, 결과적으로는 같은 공간에 다른 조직이라는 이해관계가 서로 설득되고 받아들여지고 또 그것이 하나의 이해로 나아갈 때 거국적 성장이 일어나게 되는 게 아닌 가 싶네요.
'프로젝트 리더'로써의 성장
이 프로젝트 리딩의 경험으로 크게 깨달은 것은 모두가 나와 같지는 않다는 것이고, 시각을 공유한다는 것은 훨씬 더 어려운 일이라는 것입니다. 그리고 왜 마이크로 매니징이라는 단어가 나왔는지 알게 되었고, 일을 진행시키기 위해서는 설득이 가장 중요한 기반이 된다는 점을 알게 되었는데, 어쩌면 '당연히 하겠지'라는 생각은 버리는 게 좋다는 것을 깨닫게 되었고 눈높이를 맞춘다는 것은 당연한 것은 없다는 걸 인지하고 시작해야 비로소 같은 시각에 도달할 수 있다는 것을 배웠습니다.
'큰 그림' 그리고 '작은 그림'
대학교 학부 때는 경영에 관심이 많았습니다. 그래서 컴퓨터 공대생이었음에도 불구하고 경영학과 수업들을 듣고, 중급회계, 경영학 원론과 같은 수업들을 들었는데요. 그때 미시 경제와 거시 경제와 같은 것들도 관심을 가지고, 다양한 주식과 주가, 코스피와 코스닥 지분의 구성에 대한 많은 공부를 했던 것 같습니다.
그때부터 숲을 본다는 것과 나무를 본다는 것, 이 차이점을 이해하기 위해 많은 생각을 했는데요.
개발자의 입장에서도 비단 이런 전체를 보는 시각은 필수적이라고 생각합니다.
커뮤니티를 운영하는 장점 중에 하나는 다양한 이슈 트래킹이 자연스럽다는 점입니다. 구인구직 공고를 보면 어떤 기술에 대한 시장의 니즈가 커져간다는 것을 볼 수 있습니다. 스타트업 업계의 대화 동향을 토대로 시장이 다양한 시도들을 하고 있고 망한 업종들도 트래킹 할 수 있죠. 없어지는 시장, 새로운 시장에 대해서 관찰하게 됩니다.
한 때 개발자를 선택했을 때는 10년만 '열심히' 이런 생각을 한적도 있습니다. 금융도 '10년' 본다라는 소리도 많았지만, 그만큼 개발자의 수명이 짧다는 사실을 인지하고 있었고, 그럴 각오로 이 시장을 선택한 부분도 있습니다. 다행스럽게도, 시장의 니즈는 계속 증가하고 있고 개발자의 필요는 넘치고 있습니다. 아마 10년 정도는 더 연장할 수 있을 듯싶네요. 부모님 세대는 개발자라는 직군이 이해되지 않아서 그저 '전산실' 수준으로 이해하고 있지만, 확실한 것은 앞으로는 그 수준으로 전락할 일은 없다는 것입니다. 다만 앞서 삶아진 개구리 이야기를 했지만 그 뒤에는 생각한 대로, 시장에서 쓸모 없어질 수도 있습니다. '건설'시장의 몰락, '중공업'의 몰락, '게임' 시장의 몰락, '자동차' 시장의 몰락 우린 다양한 몰락을 경험해왔고, 아마 개발 전성기도 언제든 몰락할 수 있으니 말이죠. 이건 업계에 한정된 이야기가 아닙니다. 변화는 전제를 깔아야 합니다. 크게 보았을 때 업태는 완전하게 변할 것이고, 그 흐름에 끼지 못하면 고립되는 것은 자명합니다.
큰 그림을 보는 관점으로 시장의 작은 움직임들에 대해서 '선택' 해야 합니다. 기술은 계속 진보하기 때문에 업이 무너져도 기술자들은 사실 죽진 않습니다. 이 것이 시사하는 바는 계속 '도전'하더라도 손해 볼 것이 없다는 것입니다.
거시적으로 바라보고, '새롭게' 도전해야 한다고 봅니다. 충분하게 협상된다면 말이죠.
개인이 '성장' 한다는 것
KPI라는 말을 들어보신 적이 있으신가요.
Key Performance Indicator 핵심 성과 지표라는 말입니다. 조직도 이런 성과에 대한 지표를 설정하고 달성할 필요가 있겠지만, 큰 기업에서는 매년 이 지표를 개인이 설정하게 합니다. 그리고 그것에 자신 스스로가 점수를 매기게 하는데요. 회사마다 다른 평가 문화가 있지만, 이런 평가라도 하지 않는다면, 아마 고 성과자를 가르기 어려울 것입니다. 스스로를 증명하는 일. 재미있게도 프로젝트에 나가서, PM 이신 분이 만든 PPT를 보고 꽤나 놀랐습니다. 그분은 4년 연속 고 평가자였는데요. 개발 실력은 이것에 비례하진 않았습니다. 하지만 전 이 부분에서 깨닫게 된 부분이 있는데, 자기 어필의 중요성과 문서화에 대한 '가치'입니다.
개인의 성과를 조직은 어떻게 측정할 수 있을까요? 아마 작은 기업도 고민하는 부분이고 큰 기업도 고민하는 부분입니다.
초기의 성과의 상관관계는 눈에 보입니다. 아웃풋의 속도입니다. 누가 봐도 빠르게 개발하는 사람이 고 성과자입니다. 조직이 작을 때는 이 부분은 매우 명확하게 보입니다. 따라서 잘하는 사람과 그렇지 않은 사람이 갈라지고 평가하기도 편합니다. 하지만 조직이 커질수록 이 경계는 모호해집니다. 모두 주어진 일이 비슷하고 처리하는 수준도 서서히 평준화되어갑니다. 결과적으로는 문서화를 잘하는 사람과 한 해 동안 무엇을 해왔는지를 더 잘 설득하는 사람에게 유리한 포인트가 생각입니다. 그리고 '정치'라고 부르는 윗사람의 마음을 더 잘 맞추는 사람에게 성과가 가게 됩니다. 보통은 이 것을 견제하는 장치가 없을 때 '정치판'이 된다는 현상이 일어나게 되는데요. 그래서 평가 시스템이라는 부분은 회사의 성장과 조직의 성장에 지대한 개연성을 가지게 됩니다.
개인의 성장은 기술에 대해서 진보했을 때, 사회적으로 유명한 콘퍼런스에서 발표를 하거나 인지도가 올라갔을 때, 혹은 이미 인지도 있는 회사에 이직함으로써 그 능력을 인정받게 되었을 때 등등 다양한 스스로의 시준과 가치로 산정하지만, 회사가 평가를 할 때는 회사의 업무에 한정되고, 회사를 얼마나 개선시키고 진보시키고, 또 이 업무적으로 얼마나 혁신을 주었는지 등등의 지표를 토대로 평가하기 때문에 이 평가에 있어서는 잔혹합니다. 누군가는 고평가, 누군가는 저평가를 받기 마련인 거죠.
회사가 평가하는 개인은 다르고, 개인도 스스로의 평가 척도를 설정하거나 성과를 찾기 위해 부단히 애를 써야 한다는 부분을 말씀드렸는데요.
성장을 위해서는 '자기부정' 스스로 더 진보하기 위해 계속 새로운 성장 목표점을 찍어야 할 필요가 있습니다.
회사가 '성장' 한다는 것
개인만이 성장한다고 해서 끝이 아닙니다. 회사가 망하면, 개인도 끝이죠. 그래서 회사의 관점으로 회사를 '성장'시켜야 합니다.
르노 프로젝트에 들아갔습니다. 여러 가지 인사, 재무, 이연처리 등을 해야 하는 프로젝트였는데요.
주어진 기간은 2달 반 남짓, 개발해야 하는 사람은 PM과 저 두 명, 가산에 위치한 곳이었는데, 유배지 같은 느낌이 들었습니다. 아 회사가 날 버리려나 보다.... 처음에 든 생각이었는데, 문득 이 어그러진 프로젝트를 완성해본다면 내게 어떤 이득이 있을지를 생각해 보았습니다.
이미 한 명의 개발자가 와서 한 달 만에 도망쳤다는 그곳, 내가 완성시키면 회사에서 날 좀 다르게 보지 않을까
보통은 거의 원칙을 가지고 야근을 잘하지 않습니다. 야근은 업무에 도움이 되지 않는다는 생각인데요. 이번 프로젝트는 예외를 두기로 했습니다. '완성'이 목표다. 2달 동안 만들어야 하는 페이지 분량은 약 30개, 설계, 개발 시간과 큰 대 메뉴 기반으로 6개 내외의 자잘한 화면들을 만들어야 하는 상황이었습니다. 그나마 다행인 것은 PM이 테이블을 60프로 정도 이미 설계를 끝냈다는 점이었고 열심히 개발하면 완성은 할 수도 있겠다는 점을 감안해서, 야근 계획을 세우고, 일을 시작하게 되었는데요.
DBA 분의 서포트, PM의 개발적 도움으로 이 기간 내 프로젝트를 오픈했을 때의 경험은 이루 말할 수 없네요.
하루에 2페이지씩 만들고(보통 찍어낸다고 표현하는데 딱 그 모양입니다.) 검증하고, 테스트하고 완성. 결과적으로는 회사에서는 이 프로젝트에 대한 보상으로 고과를 주었지만, 다른 부서로 이동해서 또 다른 업무를 하게 되었을 때는 또 정말 새로움으로 시작하는 느낌을 받았습니다.
회사가 '성장' 할 때 기쁨도 있지만, 그 성장의 기쁨이 같이 만족할만한 보상으로 돌아오지 않을 때는 '실망'도 찾아온다는 것을 느낄 수 있었습니다.
회사는 어떤 '성장'을 해야 할까?
커뮤니티에서는 EXIT을 위한 개발, EXIT을 위한 팀빌딩, 투자만이 목적인 스타트업들도 종종 보게 됩니다. 물론 더 큰 관점의 경우도 있지만, 현 시국에서 투자받고 EXIT을 못하면 그 기업의 부채가 고스란히 자신의 '책임'이 될 수 있는 대표 입장에서는 기업을 EXIT 하고 싶은 마음은 정말 공감되는 일입니다. 하지만 이렇게 '엑시트'만을 추구하게 되는 경우, 팀원들이 낙동강 오리알이 되는 사례들이 있습니다. 모두가 하나의 목표를 바라보고 왔다고 느꼈는데, 이 지향점이 끝나버리는 시점입니다. 이 번아웃이 가져오는 파급은 팀의 폭발, 수많은 이직, 분열 등등 다양한 효과들을 가져옵니다. 팀빌딩이 잘 된 경우는 팀원들 간의 조합 때문에 함께하는 그 느낌이 성장의 동력이 되는 경우가 많습니다. 결과적으로 '돈'을 위한 목표였나 싶은 아쉬움들이 있는 것이죠. 물론 성공적으로 엑시트를 시키고 서비스가 더 좋은 사람들 에게 넘기워져서 더 성장하게 하는 게 좋을 수도 있지만, 자식 같은 심정으로 바라보기 때문에 이런 한계가 생기는 데요.
그래서 기업이 성장을 꿈꿀 때는 EXIT 전략 이외에도 다양한 전략들이 필요합니다. 시리즈 투자를 비롯한, 스톡옵션이나 인재영입 등등 기업에 맞는 인재들을 포섭하고 성장시키고 기업이 더 큰 역량을 가지도록 하는 것입니다.
때로 기업의 복지들을 보면 호칭 평준화, 자택 근무, 애자일 방식 도입, 지라, 지라컨 플루언스, 트렐로, 잔디, 슬랙 등의 협업 도구 도입, git, svn 등의 형상 관리 등을 토대로 다양한 협업 방식들을 가지고 있다는 것을 장점으로 내세우고 있지만, 실상 이런 도구만으로는 한계가 있습니다. 실제로 이런 도구들은 일을 잘할 수 있게끔 도와주는 역할인 것이지, 이런 도구에 능숙하다고 해서 개발을 잘하는 것은 아니기 때문입니다. 기업은 이런 작은 툴체인을 관리하는 역량도 중요하지만, 무엇을- 어떻게- 왜 이 콘셉트에 대해서 이해하고 접근해서 일을 도모해야 합니다.
무작정 일을 계속 벌리고 늘리는 것이 능사가 아니고, 현상 유지를 계속한다고 문제가 해결되지도 않습니다.
때와 시점에 따라서 조직의 규모와 역량에 따라 그 스케일을 키워나가고, 딱 그 시점에 필요한 개발들을 하면서 전체적인 그림들을 완성해 나가야 합니다.
결국 개인의 성장도 이 회사의 성장과 같은 흐름이 된다면 매우 좋겠죠. 주기적인 소통과 비전 공유 그리고 회사가 가고자 하는 방향들에 대해서 조직원들이 깊은 공감이 있다면 아무래도 훨씬 더 자연스러운 진행이 될 것이라고 생각합니다.
디자이너와 협업 해보기
전통적인 기업에서는 의외(?)로 디자이너와 협업을 하게 될 경우가 별로 없었습니다. 이유는 기획 회의전에 뛰어난 기획(?)자에 의해 대부분 해야할 일과 일정들이 정해져서 내려올 뿐 더러 디자이너가 이미 퍼블리싱을 해서 파일을 던져 주었기 때문인데요. 스타트업에서 퍼블도 하고 프론트도 하고 백엔드도 하는 개발자 입장에서는 참 배부른 소리로 보이긴 하지만, 매우 편했습니다.
그 반면 퍼블리싱이 되지 않은 순수 디자인에 대해서는 늘 버벅 거림이 존재했습니다. 그래서 개발자와 디자이너 사이에는 이 PSD 파일 간의 좌충우돌이 나오기 마련이었는데요. 보통은 개발자가 포토샾을 가지고 있는 확률을 매우 적습니다. 대부분은 디자이너가 파일을 쪼개어서 준다던지, 사이즈를 고려하고 넘겨주는 경우가 많아서 개발자 입장에서 그런 고민이 적어지기 마련인데요. 만약 개발자와 일을 많이 해보지 않은 디자이너의 경우는 디자인을 하고 파일을 넘기는 일에 집중하기 때문에 의사소통의 비용이 추가로 발생하기 마련입니다.
이런 이유로 디자이너와 소통하면서 일하는 것에 대하여 고민하며, 커뮤니티에서 팀빌딩을 해보기도 하고, 생각의 차이를 이해하기 위해 많은 노력을 했는데요. 제플린이라는 도구를 만나고(물론 모든 것을 해결해주지는 않습니다만) 디자이너와 소통이 원할해지고, 조금은 쉽게 소통할 수 있는 구조가 만들어지지 않았나 싶네요.
추후 스타트업에서 프로젝트를 진행할 때는, 이 제플린을 공유하면서, 프로젝트를 진행함으로써, 퍼블리싱에 대해서도 처리하게 되는 과정을 경험하게 됩니다.
기획자와 소통하며 일하기
탑다운 방식의 의사 소통을 통해 일을 할 때와 나름대로 수평적인 조직에서의 의사소통을 통해서 일을 할 때는 분명한 차이가 존재합니다. 두 상황을 경험한 뒤에 이 온도차에 대한 이해가 확실히 느껴지는데요. 탑다운에 적응된 경우는 문제가 있어도 이 문제를 말하지 않습니다. 문제를 말하면서 생기는 여러 상황들이 매우 불편해 지기 때문인데요. 수평적으로 의사소통이 가능할 수록, 합리적인 의심과 제안은 훨씬 더 큰 폭으로 수용되게 됩니다.
그리고 그 과정에서 추후 일어날 문제들을 미연에 막을 수 있다는 것이 이 소통의 장점인데요. 오히려 문제를 말하지 않다가 나중에 큰 개발비용으로 돌아오는 경우도 있습니다.
따라서 여러가지 조직을 경험해 볼 수만 있다면 다양한 조직에서 상황에 따라 일하는 경험도 업무적 유연성을 늘릴 수 있다고 생각합니다.
개발자로써 '성장'에 대해 생각하는 부분
첫 회사로부터 지금까지 다양한 회사와 다양한 프로젝트, 좋은 사람들을 만나왔습니다. 그 때마다 이런 부분이 스스로가 발전했으면 좋겠다 싶은 내용들을 나열해 볼까 합니다. 아마 이 부분에 있어 공감되는 부분들이 나름있지 않을까 생각해보네요.
개발자로서의 미래 (성장 로드맵 - 멘토가 필요하다)
개발을 잘했으면 좋겠다(실수 없는 코딩)
설계문서를 잘 만들었으면 한다(보통은 몇몇 회사는 ERD를 쓰지 않기도 하고 해당 분석에 대해 생각하기 어려운 곳도 많습니다)
툴체인에 대해서 궁금하다(협업 도구의 사용과 관련된 니즈들이 있습니다)
좋은 사람들과 협업을 해보고 싶다(혼자 일하다보면 다른 사람과의 개발 의사소통을 통해 자신의 위치와 방향을 확인해보고 싶은 순간들이 오게 됩니다)
REST 개발 ( 개발방식이 백엔드와 프론트가 구분되지 않았던 시점에서는 이런 방식의 개발 방식을 경험해 보고 싶었습니다)
좀 더 진보된 프레임워크 (모델1도 경험해보고, JSTL도 경험해보고, CGI도 경험해보니, 과거로 돌아가기는 너무 어렵습니다.)
최근에 사용하는 프론트 프레임 워크 경험 (JSP, PHP과 같이 과거의 것들을 사용하는 방식과 엥귤러, 리엑트와 같은 프론트 개발방식이 너무나 달라서, 해당 방식에 대한 경험과 실무들이 성장의 방향으로도 느껴졌네요.)
수평적 의사 소통 방식(수직적으로 시킨일을 수행하는 역할의 조직에서는 더 나은 방식의 업무를 제안할 수 없습니다. 상호 소통이 가능한 의사 소통 방식이 성장을 가져오리라고 생각했습니다)
실무 경험과 설계 구조, 협상의 노하우(업무에 대한 범위를 산정하고 이것을 조율하는 과정이 어쩌면 또하나의 성장 요인으로 생각했습니다.)
역할의 증대 (개발의 범주를 넘어서는 일정 조율이나 다양한 커뮤니케이션 스킬도 성장의 관점이라고 봅니다.)
메소드 네이밍 (이름 정하는건 아직도 어렵네요)
개발 환경 세팅(주어진 곳에서 개발하는 것만 하는 경우도 많습니다. 개발 환경 세팅도 일종의 성장 동력으로 보았습니다)
서버 환경(개발만 하다보면, 인프라 영역과는 무관한 경우가 많은데, 서버 환경 구성 부분도 어느 정도는 직접 할 수 있는 범주를 성장의 관점으로 보았습니다.)
트래픽 처리 (공부하고 있는 부분이지만, 대량의 트래픽 처리를 처리할 수 있는 부분도 성장의 관전 포인트 입니다.)
이 이외에도 여러가지 개발과 관련된 관점들이 있겠지만, 업무라는 것을 하다보면, 너무나 일상적으로 변모되는 순간이 옵니다. 주어진 일을 처리하고, 할 수 있는 일을 하게 되는 그 관성을 뛰어 넘기 위해서는 가끔 적당한 긴장감과 텐션이 유지되어야 한다고 생각합니다.
맺음말
