어떤 엔지니어가 되고 싶은가요?
(이미지 출처 - https://www.itarian.com/patch-management.php)
경험이 쌓여가며, 어떤 엔지니어가 되고싶은지 변하는것 같습니다. 젋었을 때는 (아직도 젊..은거겠죠?) 기술에 대한 욕심이 가득했고, 요즘은 또 다른 생각이 들곤 합니다. 이에 대해 (여전히 병아리인) 엔지니어가 느낀점을 간단히 적어봅니다.
경험이 쌓여가며, 어떤 엔지니어가 되고싶은지 변하는것 같습니다. 젋었을 때는 (아직도 젊..은거겠죠?) 기술에 대한 욕심이 가득했고, 요즘은 또 다른 생각이 들곤 합니다. 이에 대해 (여전히 병아리인) 엔지니어가 느낀점을 간단히 적어봅니다.
위에서 부터 중요한 우선순위. (ORDER BY priority DESC)
1. Time to market 이 짧은
2. 적정 기술을 사용하며 다른 엔지니어를 늘 고려하는
3. 경험이 풍부한
(1) Time to markget
어느날 Admin 이 필요하거나, 프로토타입이 필요한 경우 다른 엔지니어에게 말했을 때, 3일만에 돌아가는 무언가를 가져오는 엔지니어와, 2주째 Vue 니, React 니 최신 버전에선 뭐가 다르고 비교해가며 Webpack 세팅해 가는 엔지니어 중 누구와 일 하고 싶은지 결정하려면, 저는 바로 전자와 일하고 싶다고 말하겠습니다. (부끄럽지만, 저는 과거에 후자였습니다.)
저는 도메인에서 빠르게 가치를 만들어내길 원하지, 리서치를 하느라 마켓을 놓치는 엔지니어가 되고 싶지 않습니다. 장점과 단점을 비교하는건 좋지만, 그 비용을 들여 만들어낸 결과가 비즈니스에 직접적인 영향을 주지 못한다면, 무의미한 것 같습니다. 인생은 짧고, 세상에 쓸모있는 무언가를 만들기에도 시간은 벅찹니다. 결과물이 기능이 없어 보잘 것 없거나, 또는 세상에 나오지도 못할 무언가에 시간을 쏟고싶지 않습니다.
거꾸로 말해, 속도를 잃지 않으면서 기술적으로 완벽함을 더 추구하려면 미리 준비하는 수 밖엔 없습니다. 소프트웨어의 미덕은 재활용이며, 본인 손에 익숙한 연장을 주말과 저녁 시간을 들여 준비해 놓는다면 회사 업무에서 속도를 내면서 기술적으로도 (본인이) 원하는 만큼의 완성도를 얻을 수 있을겁니다. 예로, 간단한 Admin 을 만든다고 해도 사내라면 LDAP, AD 등을 붙일 수 있고, 사용자에 따라 권한이 다를수 있을겁니다. 본인이 원하는 언어와 프레임워크로 예상되는 것들을 미리 준비하고, 필요할때 요구사항에 맞추어 약간의 커스터마이징만 들어갈 수 있다면 많은 시간을 아낄 수 있을겁니다.
이런 연습들은 실제 필요한 기술과 겉으로는 멋지지만 효용은 그렇지 않은 기술들을 구분하게 해주고, 자산이 되어 모이고 모이면 본인이 직접 서비스를 (스타트업을) 빠르게 만들때도 큰 도움이 됩니다. 저는 요즈음, 제가 스타트업을 한다면 사용할 기술을 구분해 놓고 그렇지 않은 것들과 다른 비중을 두고 익히며 생각하고 있습니다. (예를 들어, 서비스가 어느정도 까지 클때 까지는 AWS RDS, EC 만 쓰고 다른 스토리지는 혼자 관리하기 부담이므로, 어느정도의 사용자 까지는 Websocket 이 필요하다면 EC Pubsub 으로 커버할거야. 그런데, 만약 나중에 Websocket Broker 를 바꿔치기 하려면 Infra Layer 코드를 어느정도로 추상화 해야 하는지 등)
(2) 적정기술과 협업
소프트웨어는 중요도가 높아질수록 = 비즈니스적인 가치가 올라가면서, 다른 엔지니어와 협업할 확률이 올라갑니다. 또는 내가 해당 회사에서 근무하는 것 보다 소프트웨어가 더 오래 존재할 수 있습니다. 따라서 범용적인 언어와, 프레임워크를 선택하면 협업할 사람을 (확률적으로) 구하기 쉽습니다. 본인 팀의 85% 가 Java 엔지니어이며, 시스템중 75% 가 Java 로 되어있고 본인도 Java 에 익숙한데, 특별한 이유가 없이 한달 전 부터 배우기 시작한 Golang 을 고르지 않길 권장합니다. (수퍼-울트라-하이퍼 성능이라거나.. 그러나 요즈음은 머신을 더 넣어 비용을 태웁니다만.)
저는 언어가 도구임을 명확히 인지하고 있으며, 필요에 맞는 언어를 골라 써야 한다고 주장했었습니다. 그러나 머신의 성능이 올라가고 Scale-out 이 너무도 쉽게 가능해짐에 따라, 개발 비용과 유지보수 용이성이 더 큰 문제가 된 세상에서는 엔지니어를 구하기 쉬운 언어와 프레임워크를 선택하는게 낫지 않나 싶습니다. 재개발만 하다 1년 보낸 회사도 많이 봤으며, 새로운 엔지니어가 올 때 마다 이 언어에서 저 언어로 엎어 치는 경우도 많이 봤습니다.
Time to market 을 추구하다 보면 때로는 (기술) 부채가 많아질 수 있습니다. 이는 모든 회사가 겪는 과정이며 피해갈 수 없습니다. 구글 마저도 코드의 70%가 매년 재작성된다고 이야기 합니다. 그러므로 우리가 취할 수 있는 하나의 스탠스는, 속도를 낮추지 않되 비용이 허락하는 한도내 에서 나중에 문제가 될 수 있는 부분엔 조금 더 많은 애정을 쏟는 수 밖엔 없는것 같습니다.
(3) 경험
마지막으로, 다양한 경험으로부터 주변 엔지니어에게 도움이 될 수 있는 조언을 줄 수 있는 그런 엔지니어가 되고 싶습니다. 회사의 규모와 도메인에 따라 겪는 문제와 해결 방법이 다르긴 하나, 기술적으로는 비슷한 문제를 겪는 경우가 많습니다. 예로, “그건 그렇게 하면 나중에 이런 문제가 생길텐데 이렇게 해보는 것은 어때요?” 라거나.
다만 경험은 어떤 회사냐에 따라 정말 다를 수 있으므로, 제가 선택할 수 있는 한도 내에서는 경험이 축적되어 자산이 될 수 있는 길을 택해 왔습니다. 예로 AWS 를 사용하는 회사로 이직한다던지 등. (저는 더 많은 회사가 클라우드로 옮겨올 것으로 보고 있습니다. 금융권 회사들도요. 그리고 개인적으로는 GCP 를 더 좋아합니다.)
정리하자면,
사실 이 3가지는 모두 엮여있을지 모릅니다. 경험이 풍부하다면 적정기술을 판별하기도 (비교적) 쉬울수 있고, 어떤 것이 중요한지 가려내 Time to market 을 빠르게 가져갈 수 있습니다. 그리고 나이를 더 먹고, 다양한 일들을 겪으며 위 내용의 순위나 목록이 충분히 바뀔 수 있을것 같기도 합니다.
그러나 현재는 위 내용처럼 엔지니어가 ‘비즈니스 가치’ 를 만들어 내는 역할임을 굳게 믿고 있으며 ‘좋은 제품’ 이외의 다른 것들에 먼저 눈이 간다면 염불보다 잿밥에 관심이 많은것은 아닌가 하고 자신을 되돌아 보고 있습니다.
취업고민 즉문즉답 온라인 클래스
클래스 더보기
함께 보면 좋은 에세이
에세이 더보기