개발자가 되려면 어떻게 해야 할까?

개발자란

지금 여기서 말하는 개발자는 당연하지만 소프트웨어 개발자이다. 프로그래머라고도 불려지지만 일반적으로 개발자로 많이 칭한다. 사실 소프트웨어 개발자, 프로그래머, 코더 등 약간씩 의미나 뉘앙스에 차이가 있지만 여기서는 그냥 같은 의미의 말로 취급하겠다.

개발자가 되려면 컴퓨터공학과를 가야 할까?

당연히 컴퓨터공학과 계열의 학과를 가는 것이 베스트이다.
베스트인 이유는 컴퓨터공학과에서 배우는 과목에 있다. 컴퓨터 구조, 운영체제 이론, 자료구조, 컴파일러 이론, 알고리즘 등의 기초 과목은 초보 개발자일 때는 필요성을 별로 느끼지 못하겠지만 점차 수준 높은 소프트웨어를 개발하게 되면서 부딪히게 되는 수많은 문제를 해결하는데 반드시 필요한 백그라운드 지식이 될 것이다.
반면에 컴퓨터공학과를 가지 않았지만 스스로 해당 과목에 대해 연구하고 학습했거나, 내가 다루고 싶은 개발 분야가 해당 지식을 그닥 요구하지 않는다면 굳이 컴퓨터공학과를 갈 필요는 없겠다.

개발자로 취업을 할 때도 컴퓨터공학과를 나왔는지가 당락에 아주 중요한 요소는 아니다.
실제로 나도 면접관으로 수많은 지원자를 경험해 보았는데 컴퓨터공학과를 나오고 학점이 우수한 졸업생보다는 학부때 많은 것을 만들어보고 다양한 개발 경험을 쌓은 지원자를 선호했으며 실제로 이들이 실무에 훨씬 빨리 적응하고 일도 잘했던 것으로 기억한다.

다시 한번 강조하지만 전공보다는 자신의 개발 경험이 제일 중요하다. 반드시 자신이 주도하여 개발한 경험이어야 하며 좋던 나쁘던 결과물까지 완성한 경험이어야 한다. 작은 프로젝트라도 성공여부와 상관없이 끝까지 완성한 경험은 매우 중요한데 이는 마무리를 해봐야 비로소 기획 단계와 개발 단계에서 놓쳤던 부분을 깨닫게 되는 경우가 많기 때문이다.

개발자가 되고 싶은 이유

분명한 동기가 없다면 중간에 포기하고 싶을 때 극복하기가 쉽지 않다. 모든 일이 마찬가지겠지만 개발자가 된다는 것이 쉬운 길은 아니다. 정말 빠른 속도로 새로운 기술이 쏟아지고 트랜드도 수없이 바뀐다. 새로운 기술을 학습하다보면 또다른 새로운 기술이 등장한다. 연차가 쌓이고 나이를 먹어도 끊임없이 공부해야 하고 트랜드에 뒤쳐지지 않아야 한다. 이런 일련의 과정들이 스스로 즐겁지 않다면 절대 견뎌낼 수 없는 업계이다. 그러므로 매우 원초적이고 근본적인 질문이지만 자신이 개발자의 길을 가고자 생각한다면 이 질문에 대해 깊이 생각해 볼 필요가 있다.

내 경우를 되돌아 보면, 뭔가 내 머리속에 상상했던 것을 실제로 남들이 볼 수 있게 만들어 낸다는 것에 큰 매력을 느꼈던 것 같다. 만들어 내는데 공장이 필요한 것도 아니고 재료가 필요한 것도 아니다. 게다가 한번 만들면 무한대로 복제해 남들에게 보여 주고 자랑할 수 있다. 이 모든 것이 컴퓨터 한대만 있으면 가능한 일이다. 내 머릿속의 논리를 프로그래밍 언어를 통해 컴퓨터가 알아 듣고 하나 하나 수행하는 과정이 그 자체로 짜릿하고 좋았던 것 같다. 나이가 들며 많이 퇴색되긴 했지만 아직도 가끔씩 느껴지는 이런 짜릿한 감정때문에 아직 이 일을 놓지 못하고 있는 것 같다.

내가 개발자가 되고 싶어했던 이유를 잘 생각해 보고 만약 단순히 핫한 분야라서 또는 취업이 잘되는 분야라서 이 업계에 발을 들일 생각이었다면 일찌감치 접길 바란다. 결코 만만한 업계가 아니다.

만들고 싶은 것이 뭐야?

구체적으로 만들고 싶은 것이 있다면 개발자가 되기 위한 아주 좋은 동기가 될 수 있다. 개발 자체가 좋아 이 길을 가는 사람도 있지만 어떤 한 분야에 미쳐서 그것을 만들기 위해 개발을 배우는 사람도 있다.

에전에 내가 아는 어떤 분은 바둑을 정말 좋아하고 잘하는 사람이었는데 오직 최고의 바둑 프로그램을 만들고 싶다는 열정 하나로 이 분야에 뛰어들어 무척이나 열심히 노력하던 모습이 생각이 난다. 그때가 1990년대 후반이었는데 바둑은 워낙 경우의 수가 많아 체스나 장기와는 달리 제대로 만들기 어려운 게임으로 인식되던 때였다. 계속 도전했었는지는 잘 모르겠지만 이세돌을 이겨버린 알파고를 보며 어떤 생각이 들었을까 궁금하기도 하다. 내가 본 그때 그 분의 노력과 열정은 바둑 게임을 만드는 데는 실패했을지 몰라도 그때 얻은 지식과 경험은 아마 다른 쪽으로 충분한 보상이 있었으리라 생각된다.

개발자가 되려면 바둑처럼 대단한 프로그램이 아니더라도 늘 호기심을 갖고 직접 만들어 보는 습관을 들여야 한다. 프로그래밍 언어도 언어이다. 언어란 책으로만 익히는 것이 아니다. 자꾸 부딪히며 실제로 사용해 봐야 실력이 는다. 이 업계에서는 ‘백문이 불여일타’라는 말이 있다. 백번 강의를 듣거나 책을 보는 것보다 한번 직접 타이핑해가며 만들어 보는 것이 낫다는 말이다.

개발자 분야 정하기

프론트엔드 개발자

사용자가 가장 먼저 맞닥뜨리는 화면 UI를 개발하는 분야이다. 개발을 진행하며 진척되는 상황을 눈으로 확인할 수 있어서 재미있는 분야이기도 하다. 프로젝트에 따라 다르긴 하겠지만 대부분 요구되는 난이도가 높지 않아 초보 개발자와 숙련된 개발자와의 간극이 크지 않은 편이다. 그래서 개발자도 많고 연봉도 평이한 편이다.

사용 환경에 따라 웹, 모바일앱, PC 어플리케이션 개발자로 분류하기도 한다.
웹 개발은 HTML, CSS, 자바스크립트를 주로 사용하며 최근에는 이를 기반으로 사용하기 편하게 만들어진 리액트나 뷰와 같은 프레임워크를 사용하기도 한다.
모바일앱 개발은 크게 안드로이드와 IOS(Objective-C/Swift) 두 축으로 나뉘며 두 개의 환경 모두를 지원할 수 있는 리액트네이티브나 플러터도 많이 사용한다.
PC 어플리케이션 개발은 Windows API나 MFC를 사용하여 주로 개발을 하는데 사실 요즘은 거의 수요가 없다. 아주 오래된 어플리케이션의 유지보수 정도만 진행되고 있고 개발자도 별로 없어서 40대 이상의 개발자가 많이 투입되는 편이다.

백엔드 개발자

사용자에게 안보이는 영역, 주로 서버쪽 개발을 하는 분야이며 이 쪽도 많은 프레임워크가 존재한다. 과거에는 PHP, ASP 등을 많이 사용했으나 최근에는 스프링, 장고, nodejs 등 선택의 폭이 엄청 넓다.
프론트엔드와는 달리 사용 언어나 프레임워크 뿐만 아니라 데이터베이스와 통신 등에 신경써야 할 부분이 많으며 특히 서버의 성능 및 안정성을 위해 알아야 할 지식도 많이 필요하다. 그냥 할 줄 아는 것과 정말 잘 하는 것과의 차이가 엄청 큰 분야로 그 차이에 따라 연봉도 천차만별이다.

데이터, 인공지능(AI)

빅데이터 분석을 위해 데이터를 수집, 분석하고 가치있는 정보를 도출하는 작업. 인공지능 및 머신러닝 관련 기술을 사용 또는 개발하는 분야. Chat-GPT의 등장으로 최근에는 프롬프트 엔지니어라는 새로운 IT관련 직업군이 생겨나기도 했다. 프롬프트 엔지니어란 Chat-GPT와 같은 생성형 AI에게 최적의 결과물을 얻어내기 위해 대화체 명령어인 ‘프롬프트’를 작성하거나 설계하는 사람을 말한다.

게임 개발자

PC나 모바일 게임을 개발하는 개발자를 말한다. 말하기가 매우 조심스럽지만 개인적인 의견으로는 게임은 마케터와 디자이너의 역할이 중요하며 개발자의 역할은 상대적으로 적다고 생각된다. 어차피 요즘은 상용 게임 엔진을 사용하여 비슷 비슷하게 찍어 내듯 만들어 내는 게임이 대부분이라 게임 개발자도 일반적인 UI 개발자와 크게 다르지 않아 보인다.

시스템 및 보안 개발자

시스템 개발자는 운영 체제나 네트워크와 같은 시스템을 개발하는 개발자를 말하고 보안 개발자는 소프트웨어의 보안을 강화하고 취약점을 해결하는 개발자이다. 악성 코드를 분석하고 보안 프로토콜 등을 개발한다.

개발자 분야 정하기

개발자가 되기 위해 필요한 역량

학습 능력

위에서 언급했지만 끊임없이 공부해야 하는 직업이다. 새로운 기술을 학습하는 능력도 중요하지만 다른 사람이 만들어 놓은 코드를 이해하는 능력도 무척이나 중요하다. 개발을 하다보면 순수하게 모든 것을 처음부터 내가 다 만들 수는 없다. 프로젝트 중간에 합류하여 기존 프로젝트를 이해해야만 하는 경우도 있을테고 기존의 잘 만들어진 오픈 소스를 깔끔하게 우리의 프로젝트에 끼워 넣어야 하는 경우도 있을 것이다. 다른 사람의 논리를 이해하려 노력하고 좋은 점을 찾아내다 보면 시야도 넓어지고 자신의 개발 능력 향상에도 큰 도움이 될 것이다.

문제 해결 능력

개발을 하다 보면 수많은 문제에 부딪히게 되는데 어떻게든 다들 해결은 한다. 해결을 못하고 그런 일이 잦게 되면 아마 짤리겠지.
어려운 문제를 잘 해결하는 능력은 정말 중요하다. 하지만 지금 내가 얘기하고자 하는 것은 해결을 하고 못하고의 문제가 아니라 어떻게 해결하느냐의 문제이다.

충분히 생각하면 몇 줄이면 해결될 문제를 급하다고 의식의 흐름대로 코드를 때려 부어 엄청난 양의 코드와 코드의 복잡도를 높여 놓는 경우가 있다. 결과는 똑같지만 품질은 완전히 다르다. 추후 유지 보수를 생각한다면 더욱 문제이다. 급해도 정석대로 해결해야 하는 경우다.

반대의 경우도 있다. 프로젝트의 막바지에 약간의 문제가 발견되었는데 설계에 문제가 있는 것 같으니 근복적인 원인을 고쳐야 한다며 코드 전체를 흔들어 놓는 것 보다는 조금 타협하여 바람직하지 않더라도 약간의 트릭으로 막아놓고 차후 방법을 생각해 보는 것도 나쁘지 않은 선택이다.

케바케이겠지만 한정된 자원에서 최선의 결과를 만드는 것은 개발 능력과 더불어 중요한 능력이라 생각된다.

커뮤니케이션 능력

개발자의 능력 = 개발 능력 x 커뮤니케이션 능력

예전에 읽었던 책에서 본 내용인데, 개발 능력이 아무리 좋아도 커뮤니케이션 능력이 0이면 그 개발자의 능력은그냥 0이라는 것이다.
실무에서 뛰어 보면 알겠지만 개발보다 어려운 것이 사람을 상대하는 것이다. 팀끼리 협업을 하거나 개인끼리 협업을 하게 될 때 어떻게든 의견 충돌이 생길 수 있다. 이 때 프로젝트를 위한 합리적인 선택을 위해 상대방의 의견을 받아들이고 내 의견을 설득하며 서로의 의견을 절충하고 갈등을 해소해 나가는 능력은 정말 필요한 능력이다.