좋은 소프트웨어 엔지니어가 되려면?

최근 많은 분들이 소프트웨어 엔지니어로의 커리어를 시작하고 계신 것 같습니다. 저희 회사(하이퍼커넥트)에도 최근에 들어오신 신입분들이 많습니다. 이분들은 모두 열정적이고 일도 열심히 하시지만, 스몰톡을 하다 보면 많은 분들이 성장 방향성에 대해 고민하고 계셨습니다. 왜냐하면 코딩만 열심히 한다고 해서, 좋은 엔지니어로 빠르게 성장한다고 할 수 없기 때문입니다.

그렇다면 어떻게 하면 더 좋은 엔지니어가 될 수 있을까요? 물론 이 문제엔 정답이 없다고 생각합니다. 저도 경력이 그렇게 길지는 않기에, 충분히 좋은 대답을 할 수도 없을 것 같고요. 그럼에도 가끔 신입 분들께 저의 경험과 생각을 이야기해드리면, 그분들께 나름 도움이 되는 것 같기도 합니다.

이 글에서는 제가 더 좋은 엔지니어가 되기 위해 고민했던 흔적들을 공유해 보려 합니다. 특별한 내용은 없을 수 있지만, 제 고민의 흔적이 누군가에게 조금이라도 인사이트가 될 수 있기를 바라는 마음으로 적어보았습니다.

일의 타율을 높이기

일을 하다 보면 “어떻게 하면 좋은 코드를 작성할까”, 또 “어떻게 하면 빠르게 할까”에 과몰입하는 경우가 많습니다. 저도 많이 그랬고요. 하지만 진짜 중요한 것은 조직과, 우리 서비스를 사용하는 고객 입장에서 진짜 필요한 코드를 작성하는 것입니다. 아래는 일의 타율 관점에서 그려본 다이어그램입니다.

지금까지 했던 업무들이 정말 “실제로 필요한 작업”이 맞았는지 되돌아봅시다. 우리는 생각보다 불필요한 일을 많이 했고, 또 필요한 일이지만 하지 않은 것들도 많습니다. 여기서 “일”은 넓게 보면 기능 기획이나 시스템 디자인부터, 작게 보면 코드 단위까지 포함될 수 있습니다.

저만 하더라도 위 다이어그램에서 항상 두 원이 겹치게 일한다고 할 수는 없습니다. 과거에는 두 원이 겹치는 부분이 훨씬 적었던 것 같고요. 그래도 최대한 자주 스스로에게 “내가 하고 있는 것이 진짜 필요한 일이 맞는가?”라는 질문을 던져보고 있습니다.

예시를 하나 들어보자면, 최근에 ML 백엔드 시스템을 새롭게 설계한 일이 있었습니다. 해당 시스템은 트래픽이 꽤 많은 서비스에 적용될 예정이었습니다. 이런 상황에 “트래픽이 많은 서비스”라는 키워드에 집중했다면, 높은 트래픽에도 대응할 수 있는 시스템을 만들고자 시간을 허비했을 수 있습니다. 하지만 요구사항에 대해 조금 더 고민해 본 결과, “신규 가입 유저만을 대상으로 동작해도 된다” 라는 결론을 내렸습니다. 진짜 필요한 일은 “높은 트래픽에 대응 가능한 시스템”이 아니었고, “신규 유저에게만 돌아가면 되는 시스템” 이었죠. 신규 유저만 대상으로 하면 예상 트래픽이 훨씬 낮아졌고, 따라서 문제의 난이도가 같이 낮아졌으며, 작업 코스트를 낮출 수 있었습니다. 덕분에 “불필요한 일”을 안하게 될 수 있었습니다.

반대로 실제로 해야 하는데 하지 않는 업무들도 많습니다. 대표적으로는 문서화를 꼽을 수 있을 것 같네요. 문서화 이외에도 프로젝트를 시작하기 전에 진행하는 Pre-mortem이나, 프로젝트 이후의 회고와 같은 것들도 중요하지만 잘 챙기지 않는 예시입니다. 또한 엔지니어링에서 Failover(장애 극복) 설계도 서비스의 완성도를 위해 중요하게 고려해야 하는 것이지만, 놓치는 경우가 많습니다. 사람은 기본적으로 자신의 관심사만 몰입하고, 관심사가 아닌 것에는 소홀한 특징이 있습니다. 따라서 어떤 작업의 메인이 되는 부분은 잘 챙기지만, 예외 케이스와 같은 비관심사에는 신경을 덜 쓰게 되는 것 같습니다. 내 관심사가 아닌 것들 중에 꼭 해야하는 것들이 빠진게 없는지 체크하는 습관을 들이면 더 꼼꼼하게 엔지니어링을 할 수 있다고 생각합니다.

하드 스킬 기르기

엔지니어에게 하드 스킬은 아주 중요합니다. 이 부분은 이미 모든 엔지니어 분들이 체감하고 있겠죠. 하지만 하드스킬을 어떻게 기를지에 대해서는 약간 막막할 수 있습니다. 공부로 익히는 것과 실제로 코드를 작성하는 것에는 간극이 있으니까요. 저의 관점과 노하우를 공유해 봅니다.

코드 읽기

일단 저는 소프트웨어 엔지니어라면 최대한 많은 코드를 읽는 게 1순위, 다음으로는 최대한 많이 코드를 작성 해보는 게 2순위로 중요하다고 생각합니다. 학교에 있을 때보다 회사에 있으면 좋은 점은, 다양한 코드를 많이 접할 수 있다는 것입니다. 여기서 “좋은 코드”가 아니라 “다양한 코드” 라고 표현하는 이유는, 별로 안 좋은 코드라도 많이 읽어보는게 하드스킬을 기르는데 도움이 되기 때문입니다. “A 레퍼지토리에서는 이렇게 구현했는데, B에서는 이렇게 구현했구나. A처럼 작성하면 이런 경우에 대해서는 조금 안좋은 면이 있어”라고 느끼며 성장할 수 있습니다. 이렇게 꼭 코드를 작성하지 않더라도, 여러 코드를 읽고 비교해가며 머리 속에서 더 나은 코드를 시뮬레이션할 수 있습니다. 그러면 코드 작성 실력도 자연스럽게 길러질 수 있죠.

저는 학생 때부터 코드를 많이 읽고자 노력했는데, 학생 신분으로는 회사 코드를 읽을 수 없으니 대신 오픈소스를 정말 많이 읽어봤습니다. 당시 저는 XpressEngine, CodeIgniter와 같은 PHP Web Framework를 정말 많이 뜯어봤던 기억이 있습니다. (오래됨 주의). 이런 framework 말고도 다양한 언어의 정말 다양한 라이브러리들도 많이 읽었습니다. 오픈소스를 한참 읽던 시기에 코딩 실력이 비약적으로 올라갔던 경험을 했던 것 같네요.

하이퍼커넥트에 들어온 이후에도 정말 많은 코드를 읽었습니다. 저는 제가 속한 팀의 코드 뿐만 아니라, 다른 팀과 조직의 코드도 꽤 많이 읽었다고 자부합니다. 대표적인 사례로는 제가 DDD (Domain Driven Design)에 대해 공부한 이후, DDD 패턴을 실제로는 어떻게 사용하는지가 궁금해진 적이 있습니다. 다만 제가 속한 팀의 레포지토리들에는 해당 패턴이 적용된 코드가 없어서, 다른 팀의 레포지토리를 뜯어보면서 어떻게 DDD를 적용했는지를 살펴봤습니다. 그 결과로, 큰 시간을 들이지 않고 빠르게 적용 방법을 파악했고, 팀에 정착시킬 수 있었습니다. 이처럼 무작정 코드를 짜기 앞서서, 코드 읽기를 통해 남들이 겪은 시행착오를 빠르게 흡수할 수 있다고 생각합니다.

개발 도서와 스터디

책도 개발 스킬을 기르는데 많은 도움이 됩니다. 개발 관련 서적은 한 권을 진득하게 파는 것보다는, 최대한 다양한 책을 읽어보는 것이 좋다고 생각합니다. 아무래도 개발 구루들은 Ego가 강하다 보니, 자기 확신에 가득차서 “더러운 코드는 짜면 안되고, 이런 코드는 나쁜 코드다” 라고 이야기하는 책도 많습니다. 하지만 늘 그렇듯 코드에 정답은 없고, 책에서 이야기 하는 것이 현재 내 상황에서는 좋은 방법이 아닐 수도 있습니다. 개발 서적에서 이야기하는 많은 내용 중에, 우리에게 필요한 것만 잘 뽑아내는 것 또한 중요합니다. 종종 서적들 사이에서 충돌되는 내용도 나오는데, 그럴때마다 어떤 방법론이 지금 내 상황에 더 나은 선택일지도 판단을 하며 읽어야합니다. 따라서 저는 한권을 진득하게 읽기보단, 이해가지 않는 내용이 나오더라도 일단 빠르게 읽는 방향을 더 선호합니다. 아직 주니어 개발자라면, 자신에게 도움이 될만한 내용들만 책에서 추출해내고, 내 것으로 만드는 습관도 빨리 만들수록 좋다고 생각합니다.

어떤 책을 읽으면 좋을지는 저의 개인 노션 페이지 도서 목록 에 정리해두고 있으니, 참고하셔도 좋을 것 같습니다.

책 읽는게 잘 안된다면 스터디도 하나의 방법입니다. 물론 책 한권을 읽는다고 코드 퀄리티가 급격하게 좋아지는건 아닙니다. 다만 스터디를 계기로 삼아 좋은 코드가 무엇인지에 대한 고민을 시작해 볼 수 있다는 점에서, 주니어 엔지니어라면 꽤 괜찮은 방법이라고 생각합니다.

페어 프로그래밍

두 사람이 한 화면을 보면서 같이 코드를 작성하는 페어 프로그래밍 또한 빠르게 하드 스킬을 늘릴 수 있는 방법입니다. 저도 입사 초기에 페어 프로그래밍을 하면서 다른 동료의 좋은 개발 습관을 많이 체득한 것 같고, 지금은 신입 엔지니어 분들과 종종 페어 프로그래밍을 하면서 저의 노하우를 전달드리곤 합니다.

페어 프로그래밍을 잘 활용하고 있지 않은 조직이라면, 한번 시도해보자고 건의 해보세요. 신입 개발자라면 노하우가 많은 시니어 엔지니어들에게 많은 것을 배울 수 있을 것이고, 경력이 있는 개발자라면 페어 프로그래밍을 통해 팀의 신입 개발자를 빠르게 성장시킬 수 있을 것이라고 확신합니다!

트위터, 링크드인

저는 잘 활용하진 않지만, 트위터(X)나 링크드인을 통해서 개발관련 지식을 얻고 계신 분들도 많은 것 같습니다. 하이퍼커넥트에서도 많은 분들이 좋은 트위터 글을 슬랙에 자주 공유해주고 계십니다. 기술 트렌드를 익히고, 유능한 엔지니어의 통찰력을 얻는 방법으로 트위터도 괜찮다고 생각합니다.

소프트 스킬 기르기

소프트 스킬 도한 하드 스킬 못지않게 중요한 역량이고, 이 또한 많은 분들이 체감하고 있을 것이라 생각합니다. 그럼 소프트 스킬은 어떻게 기를 수 있을까요?

피드백 받기

우선 저는 피드백 받기를 통해 소프트 스킬을 꽤 많이 길렀다고 생각합니다. 피드백 받기는 매니저와의 1 on 1 이나, 동료와의 커피챗 시간을 적극적으로 활용하면 좋습니다. 1 on 1 시간에 매니저가 피드백을 잘 주지 않는다면, 피드백을 달라고 먼저 이야기하는 것도 좋다고 생각합니다. 상처가 되지는 않을까 생각하느라, 매니저가 피드백을 주지 못하고 있을 수도 있으니까요. 동료들에게 피드백을 받는 것도 가능만 하다면 아주 유용합니다. 물론 나와 같은 레벨의 동료나, 심지어 나보다 연차가 적은 사람에게 피드백을 받는 것이 어색할 수 있는데요, 그럼에도 더 다양한 관점에서의 피드백을 받을 수만 있다면 더 빠르게 성장할 수 있다고 생각합니다. 피드백을 받는 것에 익숙해졌다면, 피드백을 반대로 주는 것도 좋습니다. 다른 사람들의 피드백 포인트를 생각하다보면, 그대로 자신에게도 적용할 부분이 있으니까요.

소프트 스킬 관련 도서

도서를 통해 소프트 스킬을 기르는 것도 꽤 좋은 방법이라고 생각합니다. 소프트 스킬은 하드 스킬과 달리, 시대가 지나도 대부분 유효합니다. 마키아밸리의 군주론과 같은 책은 아직도 잘팔리죠. 그만큼 커뮤니케이션이나 리더십과 관련된 좋은 책들이 많습니다. 소프트 스킬 관련된 서적도 저의 개인 노션 페이지 도서 목록 에 정리해두고 있으니, 참고해 주셔도 좋을 것 같습니다.

컨텍스트 스위칭 비용 줄이기

새로 오신 분들과 스몰톡을 하다보면 “컨텍스트 스위칭이 생각보다 힘드네요” 라는 이야기를 많이 듣습니다. 실제로 어려운게 맞죠. 컨텍스트 자체를 줄이는 것이 더 좋겠지만, 현실은 그렇지 않은 경우가 많습니다. 이런 경우에 제가 우선적으로 권하고 싶은 것은, “내가 최대 몇 개의 컨텍스트까지 감당이 가능한지 파악하기”입니다. 저의 경우에는 컨텍스트가 2개까지는 효율이 거의 떨어지지 않는 것 같고, 3개부턴 약간 떨어지고, 4개부터는 꽤 힘들어집니다. 물론 연차가 쌓일 수록 오버헤드 비용이 조금씩 줄어드는 것 같긴 합니다.

아무튼 다시 돌아와서 나의 최대 효율 컨텍스트 개수를 먼저 파악하고, 이 숫자를 바탕으로 매니저와 이야기해보길 추천드립니다. 보통 스프린트 플래닝 같은 미팅을 통해서 업무를 정할 텐데요. 컨텍스트가 2개가 한계라면, 스프린트 기간 동안에는 최대 2개의 업무 컨텍스트만 가져가도록 팀과 이야기를 해보세요. 생각보다 컨텍스트 숫자는 조정 가능한 경우가 많습니다.

만약 조정이 어렵다면, 타임 블로킹을 활용해보세요. 업무를 스케쥴링하면 생각보다 도움이 됩니다. 또 슬랙은 바로 답장해야 한다는 고정관념도 가끔은 버리세요. 슬랙 메시지는 즉각적일 필요가 없습니다. 어쩌피 미팅하고 있으면 슬랙 답장 못합니다. 코딩하느라 슬랙 답장 조금 늦게 써도, 질문 올린 사람은 기다릴 수 있습니다. 코딩에 집중해야 한다면 MacOS의 집중모드를 짧게 켜고 일하는 것도 방법일 수 있습니다. 진짜 급한 온콜 같은 것은 전화가 오니 가끔은 슬랙을 잊으세요!

다른 동료의 장점을 흡수하기

하이퍼커넥트에 입사하고 당시에 저는 “와 이렇게 똑똑한 사람이 많다고?”라고 느꼈습니다. 좋은 동료가 많은 환경에서 일하고 있다면, 환경을 최대한 이용해야 한다고 봅니다. 그저 같이 일을 하는 것을 넘어서, “이 사람은 이런 부분은 참 잘하는 것 같다”라고 생각이 되면 그 장점을 최대한 흡수하고자 하면 더 빠르게 성장할 수 있다고 믿습니다.

저도 입사 직후에 회사에서 일을 잘하는 분들의 장점을 많이 흡수하고자 했습니다. 그중 가장 많이 흡수하고자 했던 부분은, 주도적으로 일하고자 하는 태도(Proactive)였습니다. 놀랍게도 일을 잘하는 사람들은 모두 주도적인 태도로 일했고, 저도 영향을 받아서 더 주도적으로 일할 수 있도록 많은 노력을 했던 것 같습니다. 저의 사례를 들자면, 입사한지 몇 달 되지도 않았는데 우리 회사 제품에 대한 여러 아이디어나 의견을 제시하기도 했고, OKR을 당시 팀에 도입하자고 주장하기도 했습니다. 또 비슷하게 입사 초반에 직접 저의 Job Description을 작성해서 제안하기도 하고, 자발적으로 다수의 사내 세미나에서 발표를 하기도 했고, 사내 테크블로그를 작성하기도 했습니다.

태도적인 측면 이외에도 다른 스킬도 많이 흡수하려 노력하고 있습니다. 대표적인 것이 글쓰기입니다. 사내에서 유별나게 글을 잘 쓰시는 분들이 많으신데, 이런 분들이 쓰신 글은 빠짐없이 읽으며 많이 체화하려 노력했습니다. 이분들의 글을 보면서 저도 글을 자주 쓰고자 했고, 실제로 제가 쓴 글의 퀄리티를 보면 신입때와 비교했을 때 많이 좋아진 것 같다고 느끼고 있습니다. 회사에서 일을 잘하시는 분들의 또 다른 특징은, 다른 조직의 사람들과 라포를 쌓으면서 일을 만들어내는 능력입니다. 이런 부분들도 많이 흡수하고자 노력했고, 저도 코로나 이후로는 다른 조직의 동료분들과 밥도 많이 먹으며 꽤 친해졌습니다. 라포를 쌓아두니 가끔 서로 오해할만한 상황이 있더라도, 잘 풀 수 있는 효과가 있다고 많이 느낍니다.

팀의 약점을 보완하기

동료의 장점에 대한 이야기를 했는데요. 사실 모든 사람은 단점도 가지고 있습니다. 완벽한 사람은 없죠. 팀도 마찬가지입니다. 어떤 팀은 A를 잘하지만 B를 못할 수 있습니다. 다른 팀은 B를 잘하지만 A가 아쉬울 수 있죠. 저는 본인이 속한 팀이나 조직의 강점이 무엇이고 약점이 무엇인지도 알아야 한다고 생각하고, 이 약점을 어떻게 보완할지도 꾸준히 고민해야 한다고 생각합니다.

제 사례를 이야기해 보려 하는데, 제가 팀에 합류했던 시절의 팀의 장단점을 먼저 이야기해보자 합니다. 당시 제가 속한 팀은 속도가 매우 빠르고 오너십이 강한 사람들로 이루어졌습니다. 하지만 팀 전체적인 성향이 그렇게 꼼꼼하게 엔지니어링 하지는 않았죠. (물론 팀 규모도 작았고, 새로운 팀이라 더 그랬던 면도 있습니다). 이런 상황에 팀의 약점을 보완하기 위해서는 제가 꼼꼼하게 엔지니어링 하는 것이 필요하다고 느꼈습니다. 물론 제 성향이 어느정도 꼼꼼한 편이기도 했지만, 팀의 약점을 보완하기 위해서 조금 더 꼼꼼하게 엔지니어링 하려는 노력도 들였죠. 덕분에 지금은 속도와 꼼꼼함을 모두 보유하고 있는 팀이 되었다고 생각합니다.

또 다른 예시로, 작년에는 조직 차원의 약점을 보완하고자 고민하기도 했습니다. 당시 저는 제가 속한 조직 (AI Lab)의 약점이 “채용 브랜딩”이라고 생각했습니다. 하이퍼커넥트 AI는 정말 좋은 조직이지만, 이 사실을 아는 사람이 너무 적다고 느꼈습니다. 더 좋은 채용 브랜딩이 되면 앞으로 채용에도 유리해질 뿐만 아니라, 제 커리어에도 도움이 될거라 생각했습니다. 이런 고민과 함께 제가 채용 브랜딩에 기여할 수 있는 것들을 찾아나섰습니다. DEVIEW 2023 발표, 다수의 테크블로그 작성, AI 공채 프로젝트 진행과 같은 것들은 이 측면에서 진행했던 것들입니다. “다른 사람들이 잘 못하지만 제가 잘할 수 있는 부분에서 더 기여하고 싶다” 라는 마음과 함께 기여하다보면, 더 많은 성과를 내는 엔지니어가 될 수 있다고 생각합니다.

스스로 동기부여하기

앤드루 그로브의 하이 아웃풋 매니지먼트에서 매니저의 역할은 2개 밖에 없다고 합니다. 1) 동기부여 주기, 2) 교육하기. 물론 약간의 과장이 있지만, 그만큼 두 개가 중요하다고 할 수 있죠. 여기서 저는 동기부여에 집중하고 싶습니다. 강하게 동기부여된 사람은 정말 빠르게 성장할 수 있습니다. 일단 빠르게 배울 것이고, 더 챌린징한 일을 찾아 나설 것이고, 그러다 보면 더 좋은 성과가 나고, 그럼 다시 동기부여가 올라가죠. 그래서 매니저의 역할로 팀원의 동기부여를 꼽는다고 생각해요.

다만 정말 좋은 동기부여는 남이 해주는 게 아니라, 스스로 동기부여 되는 것이라고 생각합니다. 좋은 엔지니어라면 모두 강하게 몰입한 경험이 있을 것이라고 생각합니다. 저도 강하게 몰입했을 때 정말 빠르게 성장하는 기분이 들었습니다. 회사에서 강하게, 또 꾸준히 동기부여 되어있다면 정말 빠른 성장을 경험할 수 있다고 생각합니다. 그럼 어떻게 스스로 동기부여가 되게 할까요?

저의 방법 중 첫 번째는 “하고 싶은게 있다면 매니저에게 적극 어필하기” 입니다. 기본적으로 사람은 하고 싶은 것을 할 때 강하게 동기부여됩니다. 따라서 하고 싶은 것을 할 수 있다면 해야 합니다. 물론 그 일이 회사와 align이 맞아있지 않다면 당장은 못할 수도 있습니다. 하지만 내가 무엇을 하고 싶은지 일단 매니저가 잘 알아야, 최대한 비슷한 업무라도 드릴 수 있을 겁니다. 혼자 생각했을 때는 안될 것 같다고 느끼더라도, 막상 이야기해보면 잘 풀리는 일들도 많습니다. 솔직하게 본인의 생각을 매니저에게 전달하는 것이 중요합니다.

피드백 주기를 짧게 가져가는 것 또한 좋은 방법입니다. 특히 내가 잘하고 있는 게 있다면, 칭찬을 받아아 합니다. 만약 내가 잘한 게 있는데 매니저가 칭찬을 안해준다면, 1) 칭찬을 해달라고 하거나, 2) 셀프 자랑이라도 해보세요. 저는 회사에서 셀프 자랑을 정말 많이 하는 편에 속합니다. 챌린징한 엔지니어링 프로젝트를 성공적으로 끝냈다면, 저는 거의 항상 사람이 많은 슬랙 채널에 성과 자랑글을 작성합니다. 이 부분은 내 성과를 어필한다는 측면도 있지만, 열심히 한 내 자신에게 보상(Self reward)을 주는 측면에서도 도움이 된다고 생각합니다. 요즘은 많은 회사들이 미국 문화를 따라가고 있는 것 같고, 겸손함을 지향하기보다는 성과 자랑에 대해 권장하는 문화로 바뀌어 가고 있는 것 같습니다. 만약 이런 문화를 갖고 있는 회사에 다니고 있다면, 적극적으로 셀프 자랑을 해보는 것도 좋다고 생각합니다. 만약 셀프 자랑이 쑥스러워서 너무 어렵다면, 매니저에게 칭찬 좀 해달라고 이야기 해보는 것도 시도해 볼법한 방법입니다.

좋은 영향력 발휘하기

엔지니어의 결과물에는 눈에 보이는 코드나 비즈니스 지표 말고도, 다른 동료들에게 주는 영향력(influence)도 있습니다. 학교나 회사 생활을 하면서 공부나 일을 정말 열심히 하고 잘하는 사람을 보면, 자극이 되어서 함께 열심히 한 경험이 있지 않나요? 좋은 소프트웨어 엔지니어라면, 다른 엔지니어들에게 좋은 영향력도 주어야 한다고 생각합니다.

그럼 어떻게 좋은 영향력을 발휘할까요? 가장 쉽게 시작할 수 있는 방법은, 자신이 가장 잘할 수 있는 것을 극한으로 끌어올려서 보여주기라고 생각합니다. 누구나 본인만의 강점을 가지고 있습니다. 강점은 코딩 속도가 될 수도 있고, 방대한 기술 지식이 될 수도 있으며, 매번 솟아나는 창의력이 될 수도, 혹은 식을 줄 모르는 열정이 될 수도 있겠죠. 저는 꼭 경력이 많은 엔지니어만이 다른 엔지니어들에게 영향력을 행사한다고 생각하지 않습니다. 심지어 인턴이라도 저는 충분히 좋은 영향력을 발휘할 수 있다고 생각합니다. 실제로 저도 많은 신입분들께 자극을 받기도 했고요.

코딩 속도가 강점이라면 한번 미친듯한 속도를 보여줘 보세요. 방대한 기술 지식이 강점이라면, 꾸준히 사내에 교육 세션이나 세미나를 열어보는 것이 방법일 수 있죠. 창의력이 강점이라면 회사 제품을 개선할 만한 아이디어를 끊임없이 제안해 볼 수 있을 겁니다. 열정이 강점이라면 정말 지치지 않고 계속 끊임없이 도전하는 정신을 보여주면 됩니다. “나는 주어진 일을 잘 하면 돼” 라는 생각에서 멈추지 않고, “어떻게 하면 다른 동료 엔지니어들에게 더 영향력을 발휘하고, 또 동기부여를 줄 수 있을까?” 에 대해서도 꾸준히 고민한다면, 더 많은 영향력을 발휘하는 엔지니어가 될 수 있다고 생각합니다. 매니저나 리더십 레벨만 영향력에 책임이 있다고 생각할 필요가 없습니다. 연차에 상관없이 누구나 좋은 영향력을 발휘하는 엔지니어가 될 수 있습니다.

신뢰할 수 있는 엔지니어가 되기

팀에 중요한 업무가 있다고 합시다. 여러분이 매니저나 의사 결정권자라면, 어떤 엔지니어에게 일을 맡길 것 같나요? 기술적으로 뛰어난 사람? 경력이 많은 사람? 저라면 신뢰할 수 있는 사람에게 일을 맡길 것 같습니다.

그럼 어떤 사람을 신뢰할까요? 저는 신뢰는 기본적으로 역량과 성과에서 온다고 생각합니다. 하드 스킬과 소프트 스킬이 뛰어나고, 그 스킬을 바탕으로 일을 잘 수행해 나간다면 신뢰가 조금씩 쌓이겠죠. 다만 역량과 업무 성과가 전부는 아니라고 생각합니다. 빠르게 성장하고, 팀플레이를 잘하며, 주변 동료들에게 좋은 영향력을 주고, 스스로 동기부여되는 사람이라면 더 신뢰할 수 있겠죠. 반대로 다른 동료들과 트러블이 잦거나, 정치적인 행동을 한다면 신뢰하기 어렵겠죠.

더 많은 기회를 얻기 위해서는 신뢰를 쌓아야 합니다. 아무리 역량이 뛰어나도 신뢰받지 못하면 기회조차 얻지 못할 가능성이 커집니다. 신뢰는 기본적으로 꾸준히 쌓아야 하는 것이지만, 특히 어려운 시기에 더 많이 쌓을 수 있다고 생각합니다. 어려운 시기엔 대부분의 사람들이 힘들어하거나 포기할 텐데, 이 시기에 끝까지 최선의 결과를 내기 위해 노력하는 사람은 더 신뢰하게 될 수밖에 없죠. 저도 이런 점에서는 아직 많이 부족하다고 느끼는데, 회사에서 신뢰를 잘 쌓아가는 분들을 보시면 저도 많이 배우게 되는 것 같네요. 어떤 행동을 할 때, 나의 행동이 다른 사람들에게 신뢰를 쌓게 할지, 혹은 잃게 할지 아닌지 고민해 보세요. 또 회사에서 신뢰받고 있는 사람들은 평소에 어떻게 일하고 말하는지도 파악하고 배워보세요. 어쩌면 빠르게 신뢰를 얻어서 더 많은 기회를 얻게 될 수 있습니다.

맺으며

제목을 거창하게 지었는데, 사실 좋은 엔지니어가 되기 위한 특별한 방법 같은 것은 없다고 생각합니다. 주어진 일을 하는 것을 넘어서 조금 더 잘할 수 있는 방법을 고민하고, 고민을 바탕으로 조금 더 나은 방향으로 일하다 보면 점진적으로 더 좋은 엔지니어가 된다고 생각합니다. 물론 저도 아직 갈 길이 멀다고 생각하긴 합니다. 다른 누군가가 저에게 “당신은 좋은 소프트웨어 엔지니어인가요?” 라고 물어본다면 그 질문에 답을 할 수 있을지는 잘 모르겠습니다. 하지만 “좋은 엔지니어가 되어가고 있는 것 같다” 라고는 이야기할 수 있을 것 같습니다.