이 아티클은 <비전공자가 개발자로 일하는 방법> 시리즈의 5화입니다. 


개발자라는 직업에 대한 관심이 정말 높은 시기다. 심지어 한 회사에서 개발자 연봉이 다른 직군에 비해 훨씬 높다는 기사가 나가면서, 상대적인 박탈감을 느끼는 사람들도 많을 것이다. 그런데 이런 분위기는 10년 전과 비교하면 정말 다른데, 내가 처음 개발을 공부할 당시만 하더라도 대다수 사람들은 개발을 대표적인 3D 직업으로 생각했었다.

이런 변화는 ‘과연 개발이라는 분야는 영원한 관심을 받을 수 있을까?’라는 자연스러운 질문으로 이어진다. 부모 세대만 하더라도 하나의 직업으로 평생을 일할 수 있었지만, 요즘은 더 이상 한 직업으로 평생 일할 수 없는 시대가 아니라고 한다. 세상은 너무나 빠르게 바뀌고 어제까지 있었던 직업은 오늘은 존재하지 않고, 어제 없었던 직업이 오늘 새로 생겨나기도 한다.

ⓒ 셔터스톡


그리고 개발 기술이 끊임없이 발전하면서 정말 개발에 대한 진입 장벽이 낮아지고 있다. 많은 사람이 개발자가 되고 싶어하면서 정말 교육 자료들도 인터넷에 넘쳐난다. 굳이 경제학의 수요와 공급 곡선을 들먹이지 않더라도, 언제까지 이런 트렌드가 이어질 거라고 막연하게 믿는 것은 순진한 생각이다. 그리고 ML/AI 기술이 발전하면서, 단순하고 반복적인 업무부터 점점 인공지능에 대체되고 있다. 앞서 이야기한 것처럼 개발 기술은 진입 장벽이 낮아지고, 높은 개발자 연봉 덕분에 개발이라는 업무도 자동화의 주요 대상이 되어가고 있다. 만약 나만의 전문 지식과 기술을 가지고 있는 것이 아니라면 자동화 기술에 대체되어 갈 것이다.

비전공 개발자가 가진 강점

이렇게 치열해지는 개발자 시장에서 비전공자로서 업무에 탁월한 성과를 낼 수 있는 방법에는 어떤 것이 있을까? 개발자로서 당연히 기본적인 개발 실력은 갖추는 것이 필요하겠지만, 개발자 업무가 단순히 개발 작업만 있다고 생각하는 것은 굉장히 근시안적인 시각이다.

개발자들은 기본적으로는 디자이너와 기획자와 함께 일하게 되고, 직급이 올라갈수록 개발 작업이 비지니스에 미치는 역할을 설명하거나, 채용 등의 관련 업무도 굉장히 중요해지게 된다. 그리고 업계마다 주로 활용하는 기술이나 테크닉이 다르기 때문에 개발자들이 가지는 기술도 저마다 다르다.


커뮤니케이션 능력
이런 관점에서 커뮤니케이션 능력은 컴퓨터 공학 비전공자로서 가질 수 있는 큰 장점이다. 물론 모든 비전공자가 커뮤니케이션 능력이 뛰어난 것은 아니고, 모든 전공자가 커뮤니케이션 능력이 떨어지는 것은 또 아니다. 하지만 의외로 대학교에서 4년간 공부해 온 것은 한 사람에게 큰 영향을 미친다. 나는 그 기간 동안 받은 대부분의 과제와 시험이 작문이었고 토론으로 구성된 수업을 들었다. 덕분에 졸업 후, 커뮤니케이션 능력이 남았다. 아마 문과 전공을 가진 비전공자라면 비슷한 종류의 경험이 있을 것이다.

만약 본인의 커뮤니케이션 능력이 팀 내 다른 개발자들보다 뛰어나다고 느껴진다면, 타 부서와 협업할 때 적극적으로 나서보는 것이 좋다. 각 팀만의 고유한 언어가 있다. 개발자, 기획자, 디자이너, 세일즈, 마케팅팀은 서로 다른 언어를 쓰기 때문에, 다른 사람이 알기 쉽게 설명할 수 있는 능력은 정말 중요하다. 조금 더 나아가서 말을 하지는 않지만 비언어적으로 이해할 수 있는 각 팀의 우선 순위나 요구사항 등을 알아차릴 수 있다면 훨씬 수월하게 업무를 할 수 있다.


도메인 지식
다른 업무 경력을 가진 채로 개발자로 전향을 한다면 컴퓨터 공학 전공자들과 비교할 수 없는 강점 중 하나가 도메인 지식이다. 만약 해당 분야와 관련된 개발 업무를 할 수 있다면 다른 사람이 놓치기 쉬운 것을 잡아낼 수 있다. 물론 다른 팀과의 커뮤니케이션이 훨씬 쉬워지는 것은 덤이다.

그리고 특히 한 분야에 다년 간의 경력이 있다면, 가능하면 해당 업계의 개발자로 전향하는 것이 기존 경력을 가장 인정 받을 수 있는 방법이기도 하다. 많은 분이 경력 전환을 할 때 기존 연봉을 포기하는 것에 어려움을 겪는데, 기존 업계에서 직무를 바꾼다면 어느 정도는 기존 연봉을 유지한 채로 경력을 전환할 수 있다.

ⓒ 셔터스톡


강점으로 승부하자
만약 개발 능력만으로도 충분히 회사 내에서 성과를 낼 수 있고, 그러기를 원한다면 그렇게 경력을 쌓는 것도 나쁜 일은 아니다. 하지만 내가 가진 모든 것을 내려놓고 경쟁을 하는 것은 현명하지 않다고 생각한다. 최대한 내가 가진 역량과 강점을 제대로 파악하고, 매니저와의 정기적인 커뮤니케이션을 통해, 내가 가진 강점이 단순히 개발 능력만이 아니고 다양한 방면에서 회사와 팀에 알리는 것이 중요하다.

개발자 이후의 경력

이것은 내 개인적인 경험이기도 한데, 내가 가진 다양한 강점을 이용해 팀에 기여하기 위해 노력을 했고, 그 과정에서 팀원과 매니저에게 긍정적인 피드백을 받기도 했다. 하지만 ‘과연 개발이 내가 가진 강점을 모두 이용해 가장 잘 할 수 있는 일인가’라는 질문이 계속 머릿속을 맴돌았다.

뿐만 아니라, 나는 원래 창업과 같은 비즈니스 활동에 관심이 많아 회사를 다니면서도 크게 개발 업무랑 관련이 없는 데이터 분석 업무도 도맡아서 하기도 했는데, 개발 경력을 살리면서 조금 더 사업 운영과 직접 관련이 있는 일을 해보고 싶다는 생각을 했다. 그래서 현재는 세일즈 엔지니어(솔루션 아키텍트)로 일을 하고 있는데 굉장히 만족하고 있다.

물론 개발자로 처음 경력을 전환하자마자 이런 고민을 시작하는 건 추천하지 않는다. 가능하면 처음 3~5년 정도는 개발이라는 분야에 흠뻑 취해보기를 권하고, 그 안에서 새로운 것을 배우며 내 손으로 무엇인가를 만들어나가는 즐거움을 느껴보는 것이 정말 중요하다. 비전공자라는 배경이 사람들을 다소 조급하게 만드는 경향이 있는데, 개발 업무의 특성이 다른 일에서는 찾기 힘든, 무엇인가를 창조한다는 점에서 기본적으로는 너무도 즐거운 일이다. 여기에 흠뻑 한 번 빠져봐야 이후의 커리어를 발전시켜 나가는 데도 도움이 된다.

아래에서는 개발자로 경력을 어느 정도 쌓은 이후에 고려해볼 수 있는 직무들을 살펴보자.


세일즈 엔지니어
세일즈 엔지니어는 프리 세일즈(Pre-Sales)라고도 불리고, 세일즈 팀에 속하면서 고객에게 제품의 기술적인 면을 소개하고 설명하는 업무를 한다. 세일즈만으로 판매할 수 있는 제품들도 있겠지만, 기술적으로 복잡한 경우에는 세일즈가 고객사에서 들어오는 모든 질문에 답변하는 것이 불가능하기 때문에 IT 기업은 세일즈와 세일즈 엔지니어가 한 팀으로 일하는 것이 일반적이다.

세일즈 엔지니어의 업무에 대해 제대로 이해하려면 우선 세일즈 조직이 어떻게 일하는지 알 필요가 있다. 싱가폴에서 미국계 세일즈 조직에서만 업무를 해봤기 때문에, 세일즈 조직에 대한 설명은 이를 바탕으로 한다. 세일즈 프로세스는 크게 사업 개발(Business Development), 영업(Sales), 사후 관리(Post-Sales) 이렇게 세 가지로 나뉜다. 사업 개발은 다양한 경로를 통해 제품에 관심을 보인 고객에게 전화나 이메일 등으로 연락해서 고객의 기본적인 관심이나 제품 구매 의사를 파악한다. 이렇게 확보된 고객들을 리드(lead)라고 부르는데, 이런 리드는 영업팀에서 전달받아 관리한다. 그리고 고객이 제품 구매를 하게 되면 지속적인 재구매를 위해 다음 팀으로 넘어가 사후 관리가 이어진다.

세일즈 엔지니어는 이 단계에서 영업 활동에 전담하는 엔지니어를 말한다. 간혹 사업 개발 단계에서 함께 미팅이나 전화에 들어가기도 하는데 흔하지는 않고, 영업 단계에서 세일즈 담당자가 기술적인 설명이 필요하다고 요청하는 경우 기술적인 부분을 설명하는 세션을 진행하는 것이 일반적이다. 만약 여러 사람을 만나고 기술적인 내용을 쉽게 설명하는 데 어려움이 없다면 고려해보면 좋다.


서포트 엔지니어
서포트 엔지니어는 위에서 사후 관리에 해당하는 업무를 한다. 여기서 사후 관리는 제품을 설치하거나 Salesforce와 같은 SaaS 계열의 클라우드 제품 설정 작업을 돕는 일이다.

이후 고객이 제품을 사용하는 중에 문제가 있거나, 새로운 기능이 나와 교육이 필요한 경우 등에도 참여한다. 회사 내에서는 실제로 제품을 개발하는 엔지니어링팀 다음으로 제품을 많이 써보게 되는 팀으로, 해당 제품에 대해 가장 기술적으로 깊게 이해해야 한다. 따라서 해당 포지션에 일하기 위해서는 실제 해당 제품을 사용한 경험이나 프로그래밍 경험이 필요하다.

많은 고객과 다양하게 일하기 보다는, 적은 수의 사람과 장기적인 관계를 쌓아나가는 것이 좋다면 서포트 엔지니어에 도전해보면 좋다. 꾸준히 기술적인 업무를 하게 되기 때문에, 잠깐 다른 조직을 경험해보고 싶을 때 큰 위험 없이 도전했다가 개발자로 돌아갈 수 있다는 장점도 있다.


아키텍트
아키텍트는 위의 두 직무와 전혀 다른 직무라기 보다는, 업계/업체에 따라서 다른 의미로 쓰이는 경우가 많다. 해당 포지션의 면접을 본다면 자세히 내용을 확인하는 작업이 필요하다. 어떤 경우에는 프리세일즈를 의미하고, 다른 경우에는 서포트 엔지니어를 의미하고, 개발 조직에서는 시니어 포지션의 개발자를 의미하기 때문이다.

ⓒ 셔터스톡


테크니컬 프로덕트/프로젝트 매니저
마지막으로 개발자로서 경력 전환을 고려해볼 수 있는 포지션으로는 테크니컬 프로덕트 매니저가 있다. 이 포지션도 다양하게 불리는데 Technical Product Owner, Technical Product Manager, Technical Project Owner, Technical Project Manager가 모두 같은 직무를 가리킨다. 여기서 테크니컬이라는 부분은 보통 비지니스 쪽 프로덕트 매니저와 비교하기 위해 붙이는데, 규모가 크지 않은 조직은 이 두 포지션 간의 구분이 없이 그냥 프로덕트 매니저라고 부르기도 한다.

이름에서 알 수 있듯, 기존의 기획자 역할을 대체로 수행한다고 생각하면 되는데, 조금 더 전문화해 제품이나 프로젝트별로 결정권을 가지는 최종 결정자의 역할을 한다고 이해하면 좋다. 단, 단순히 결정만 내리는 역할은 아니고 디자인, 마케팅, 세일즈 팀 등 다양한 팀의 의견을 수렴해, 새로 추가되어야 하는 기능의 우선 순위를 정하고 해당 기능의 일정을 관리하는 역할을 수행한다.

만약 다양한 업무를 동시에 처리할 수 있고, 커뮤니케이션 능력이 뛰어나고, 필요한 업무를 적절히 위임할 수 있다고 스스로 판단한다면 도전해보면 좋다.



▶ <비전공자가 개발자로 일하는 방법> 시리즈 보러 가기



글ㅣ마르코
필자는 역사학도 출신 개발자로 대학 졸업 후 무역상사에 입사했으나 직장 상사들처럼 살고 싶지 않아서 퇴사 후 개발을 공부했다. 한국에서  개발자로 3개의 스타트업을 다녔고, 이후 프리랜싱, 개인 사업 등 다양한 일을 하다가 상해를 거쳐 싱가폴에서 개발자로 일했다.  현재는 IT영업 업무를 하면서 관련 글을 쓰고 있다. (https://brunch.co.kr/@imagineer)