개발자로 거듭나기⋯ 네 가지 기본 소양을 기억하세요

개발자라면 어떤 기초 지식을 습득해야 할까? 좋은 개발자가 되려면 어떤 사고 방식을 갖춰야 할까? 개발자를 꿈꾸는 당신을 위한 조언이 여기 있다. 한글과컴퓨터, 블리자드, 넥슨, 삼성전자, 그리고 유니콘 기업 몰로코의 박종천 개발자가 올해 30년을 맞아 발자취를 되돌아보며 개발자 지망생에게 작은 조언을 건냈다. 수많은 글과 멘토들이 말했을 법한 말들이지만, 알면서도 잊고 실천하기는 더 어려운 그 이야기를 들어보자 _편집자 주

개발자 기본은 영어입니다. 그다음은 수학과 물리입니다. 코딩 교육이 붐이라 초등학생도 코딩을 배웁니다. 의문이 듭니다. ‘초등학생에게 코딩을?’ 터도 안 닦고 건물을 올리겠다는 말처럼 들립니다. 먼저 수학과 물리, 그중에서도 수학을 잘 알아야 합니다. 기본을 잘 만들고 나서야 프로그래밍 언어를 공부하고, 자료구조, 알고리즘, 운영체제, 하드웨어를 공부하면 됩니다.

알아야 하는 지식이 너무 많군요. 개발자는 평생 공부하는 직업입니다. 공부가 싫으면 다른 길을 고민하는 편이 시간 낭비를 줄이는 방법입니다. ‘나는 웹 개발자니까 하드웨어는 몰라도 돼’, ‘나는 운영체제는 몰라도 돼’ 이런 자세는 안 됩니다. 만든 프로그램을 쌩쌩 돌게 하려면 하드웨어를 알아야 합니다. 하드웨어 이론뿐만 아니라 예를 들어 안드로이드 앱을 개발한다면 제일 잘 팔리는 최신 삼성 갤럭시와 샤오미 홍미노트를 직접 만져보고 소프트웨어를 동작시키고 실생활에서 사용해보며 하드웨어 기능과 특징과 성능을 익혀야 합니다. 안드로이드 운영체제 버전별 기능(특징)도 알아야 하죠. 다방면으로 알아야 제대로 지식을 쌓을 수 있습니다.

다시 강조하지만 빠르게 세상이 변하므로 새로운 하드웨어, 새로운 운영 체제, 새로운 프로그래밍 언어를 빠르게 익힐 수 있는 능력을 갖추는 데 집중해야 합니다. 다음은 제가 주니어 개발자들에게 ‘개발에 대한 기본 지식이란 무엇인가’를 설명할 때 제시하는 목록입니다. 이 정도는 알아야 합니다.

현업은 기본 위에서 이뤄집니다. 예를 들어 자동차를 운전하려고 바퀴나 엔진을 직접 만들지는 않습니다. 핸들, 깜빡이, 엑셀, 브레이크, 차 크기, 바퀴 유무와 신호체계만 알면 운전할 수 있습니다. 개발도 마찬가지 입니다. 기본 지식을 잘 안다고 제로 베이스부터 모든 걸 직접 만들어 쓰는 게 아닙니다. 하지만 모든 소프트웨어는 기본 위에서 작동합니다. 기본을 알면 아키텍처가 달라집니다. 아키텍처는 소프트웨어 품질의 근본입니다. 정렬, 스택, 힙, 스레드, 네이티브 코드, 모델-뷰-컨트롤러 아키텍처(MVC) 등 표에서 언급된 내용을 공부해보세요. 이 정도는 알아야 소프트웨어 기본 지식을 갖췄다고 할 수 있습니다.

게임 개발자가 꿈이라면 기본 지식만으로 텍스트 기반의 게임을 만들어보세요. 예를 들어 화면에 글자 A가 왔다 갔다 하는 게임 말입니다. 유니티나 언리얼 같은 강력한 게임 엔진을 사용해 화려한 3D 그래픽 게임을 만들어보고 싶겠지만, 2D 텍스트 기반으로 게임을 만들어보세요. 그러면 기본 지식을 점검하고 활용할 수 있어 유용합니다.

대개는 상사가 일을 시키면 ‘네 알겠습니다’하고 곧바로 일을 합니다. ‘크리티컬 싱킹’이라는 말이 있습니다. 우리말로는 ‘비판적 사고’ 정도로 번역할 수 있습니다. 크리티컬 싱킹은 주어진 일의 앞뒤를 생각하는 습관 입니다. ‘왜 이 일을 해야 될까?’, ‘이 일을 하다가 말면 어떻게 될까?’, ‘어떤 방식으로 일하는 게 최선일까?’ 문제의 상하좌우까지 고민하는 사고 방식을 습관으로 들이면 모든 일을 더 깊이 들여다볼 수 있습니다.

두 사람에게 같은 난도의 일을 주고 1년을 일하게 한다고 해봅시다. 둘 다 갓 대학을 졸업한 신입 직원이고 현재 역량이 같다고 합시다. 그러니까 둘 다 채용되었겠죠. 1년이 지나고 보면 둘의 역량은 같을까요? 차이가 난다면 ‘크리티컬 싱킹’이 그 차이를 만든다고 생각합니다. ‘삽을 들고 가서 열 번 땅을 파고 독을 묻은 다음에 돌아와라’하고 시켰을 때 그대로 하면 숙련도는 올라갑니다. 하지만 지식이나 경험은 잘 쌓이지 않습니다. 반면 ‘왜 10번만 파야 되지?’, ‘왜 삽으로 파야 하지?’, ‘곡괭이로 파면 안 되나?’, ‘꼭 파야 하나?’, ‘독을 왜 묻지’ 이런 질문을 하고 더 좋은 방법을 고민하면 어떻게 될까요? 관리자 입장에서는 전자가 편합니다. 시키는 대로 하니까요. 후자는 뭐 하나만 시키면 맨날 물어봅니다. 그래서 귀찮습니다. 그런데 1년이 지난 다음에도 전자한테는 여전히 설명을 길게 해줘야 합니다. ‘동쪽으로 열 걸음 가서 땅을 열 번 파고 독을 묻어라.’ 그런데 후자한테는 ‘김치를 잘 보관해봐’라고 하면 끝입니다. 땅을 파는 대신에 김치 냉장고를 구비해 보관할지도 모릅니다. 크리티컬 싱킹 습관이 들어 있으면 그 사람이 감당하는 업무 스케일이 계속 커지게 됩니다.

소프트웨어를 개발하면서 왜why, 어떻게how, 무엇what을, 누가who, 언제when까지 출시해야 하는지를 종합적으로 고려해야 합니다. ‘어떻게’에 매몰되면 좁은 영역에서 해결책을 얻을 수는 있지만 종합적인 관점에서 최고 혹은 최선의 해결책을 얻지 못합니다. 크리티컬 싱킹은 종합적인 관점에서 해법을 구하는 습관입니다. 같은 시간을 투자해도 상대적으로 더 큰 성장을 이끌어냅니다.

혹자는 ‘그거 주인의식의 다른 말 아닙니까? 회사의 주인도 아닌데 시킨 것만 잘하면 되지 주인의식을 가질 수 없어요’라고 말합니다. 네, 맞습니다. 회사에 대해 주인의식을 가질 필요는 없습니다. 대신 나에 대한 주인의식을 가져보세요. 이직을 하든, 창업을 하든 과거에 내가 한 일이 오늘의 나를 만듭니다. 화장품 하나도 성분을 보고 사는 시대입니다. 개발자를 채용하면서 어떤 프로젝트에 참여했는지가 아니라 어떤 기여를 했는지 확인하는 시대입니다. ‘그냥 시킨 것만 했어요’라고 대답하지 않으려면 나에 대한 주인의식, 즉 크리티컬 싱킹이 필요합니다. 그런 기여가 결국 나를 자연스럽게 성장시킨다는 거죠. 주인의식은 부차적인 겁니다. 주는 나의 성장인 거죠. 그래서 저는 말합니다. ‘프로젝트에서 최대한 오너가 되어라.’

게임 하나에 분야별 다양한 개발자가 필요하다고 언급했습니다만, 사실 개발자는 그래픽도 볼 줄 알아야 되고, 데이터베이스, 도구도 많이 알아야 합니다. 소스 관리 도구라든지 비주얼 스튜디오, 유니티, 언리얼 같은 엔진도 알아야 합니다. 무엇까지 알아야 하냐고요? 프로젝트를 성공적으로 개발하는 데 필요한 모든 겁니다. 당연히 사전에 모든 걸 알 수는 없습니다. 꾸준히 공부하는 수밖에 없습니다.

그렇기에 특정 언어나 도구와 사랑에 빠지면 안 됩니다. 사랑에 빠지면 최적의 언어와 도구를 선택하지 못합니다. 기술은 빨리 변합니다. 프로젝트라는 과업 달성과 1~2년 후를 고려해서 선택해야 합니다. ‘나는 정말 훌륭한 앵귤러JS 개발자야.’ 5년 전에는 환영받았겠지만 지금은 리액트나 뷰가 대세입니다. 앵귤러JS에만 머물러 있다면 새로운 직장을 찾기 어려 울 겁니다. 도구도 마찬가지입니다. 15년 전에는 비주얼 스튜디오와 이클립스가 양대 산맥이었습니다. 지금은 인텔리제이 같은 도구가 선택지를 넓혀줍니다. 현업에 바쁘더라도 6개월 주기로 새로운 기술과 도구를 확인하고 공부하는 기간을 갖길 바랍니다.

개발자의 도구는 역할과 프로젝트마다 달라져야 합니다. 게임 클라이언트 개발자라면 유니티와 C# 혹은 언리얼과 C++를 알아야 합니다. 서버 개발자라면 자바나 닷넷이나 파이썬을 알아야 합니다. 도구는 어떤 자동화 프로세스를 채택하느냐에 따라 달라질 겁니다. 기술 흐름을 조망하고 큰 흐름을 계속 따라가야 합니다. 지금까지 자바로 서버를 개발했다면 다음 프로젝트에 Go 언어를 사용하는 건 어떤가요? 스택오버플로 2020년 개발자 리서치 결과에 따르면 Go 언어는 배우고 싶은 언어 4위, 미국에서 연봉이 높은 언어 2위에 올랐습니다. 오케스트레이션 시스템인 쿠버네티스, 컨테이너 시스템인 도커, 리뉴얼한 드롭박스에 사용되었죠. 젯브레인즈에서도 비슷한 리서치 결과를 발표했죠. TIOBE와 깃허브에서 발표하는 프로그래밍 언어 순위(흐름)를 참고해도 좋습니다. 여러 리서치 결과를 참고하면 더 객관적으로 흐름을 파악할 수 있습니다.

동향 파악도 크리티컬 싱킹과 연결됩니다. 다음 제품을 만드는 데도 쓸모가 있는지 생각하면서 기술을 채택해야 합니다. 다음에도 유용한 기술이면 이직할 때 매력 포인트가 되어줄 겁니다.

가정을 하나 해봅시다. 신기술을 적용하고 싶은데 상사가 옛 기술을 쓰라고 하면 어떻게 해야 할까요? 크리티컬 싱킹이 습관화된 분이라면 설득의 묘미를 발휘할 겁니다. “포트란으로 짜면 당장은 제가 개발할 수 있지만, 향후 제가 퇴사한 뒤에는 개발자를 구하지 못해 유지보수가 어려울 겁니다. 한 달만 더 주면 Go 언어로 만들 수 있습니다.” 여러분이 관리자라면 어떻게 하겠습니까? 저 같으면 한 달을 더 주겠습니다. 이렇게 상사를 설득하면 본인에게도 이득입니다. 이직 전선에서 포트란 개발 이력은 전혀 도움을 주지 못하는 반면, Go 언어 개발 이력은 도움을 줄 겁니다.

새로 취업한 회사에서 사장되는 기술로 개발하라고 지시를 내리면 어떻게 해야 할까요? 진지하게 빠른 탈출을 고려하든가, 다른 기술을 관철시켜야 하겠죠? 전자는 본인을 위한, 후자는 본인과 회사 모두를 위한 선택지입니다. 그저 시킨 대로 사장될 기술을 사용한다면 모두에게 불행을 가져다줄 겁니다. 그렇다고 모든 개발에 신규 기술만 고집할 필요는 없습니다. 향후 5년 이상 유지할 서비스라면 최대한 미래를 고려해 선택하고, 1년 미만 혹은 유지보수 정도의 목적에는 기존 기술을 쓰면 됩니다.

왜 5년이냐고요? 딱 5년일 필요는 없습니다. 어떤 분야에서 무슨 일을 하고 싶냐에 따라서 기준이 달라집니다. 잠시 IT에서 5년이라는 시간을 생각해볼까요? 리액트, Vue.js, 파이토치, 쿠버네티스, GCP, 플러터, 코틀린, Go 언어. 5년 전에는 지금처럼 개발자에게 대중적으로 사용되는 기술이 아니었습니다. 아예 그 당시에 없던 기술도 있죠. 하지만 지금은 각 분야에서 내노라하는 대표 주자가 되었습니다. 5년 전과 지금이 다르듯 지금과 5년 후도 다를 겁니다. 제가 지속적인 공부를 반복해 강조하는 이유입니다.

프론트엔드 개발자라고 해서 프론트엔드만 알면 안 됩니다. 백엔드를 조금이라도 개발할 줄 알아야 합니다. 개발은 협업의 연속입니다. 원활히 협업하려면 알아야 합니다. 프론트엔드 개발자가 백엔드 개발자에게 안 되는 걸 무조건 해달라고 하면 어떻게 되겠습니까? 분란만 나겠죠? 초당 10만까지만 받을 수 있는 시스템인데 ‘나는 당신 사정은 모르겠고 당장 천만 받아줘’라고 하면 안 됩니다. 풀스택 개발자까지는 안 되더라도 프론트엔드, 백엔드, 데이터베이스, 머신러닝, 클라우드, 안드로이드/iOS 전반에 대한 지식이 있어야 합니다.

한 가지를 깊게 파서 잘하는 I자형 인재가 각광받던 시절이 있습니다. 변화가 빠른 지금은 적어도 하나는 깊게, 나머지는 골고루 잘 아는 T자형 인재가 각광받고 있습니다. T자를 넘어 요즘에는 π(파이)자형 인재라는 말도 나왔습니다. 하나가 아니라 두 가지에서 전문성이 있어야 한다는 이야깁니다. 프론트엔드 개발자만 π자형 인재가 되어야 하는 게 아닙니다. 백엔드 개발자도 프론트엔드 개발을 할 줄 알아야 합니다. 100세 코딩과 30년 커리어패스 중 무엇을 로망하더라도 한 가지만 잘해서는 달성할 수 없습니다. 부전공을 선택하세요. ‘프론트엔드 개발을 잘하지만 머신러닝도 깊게 익혀두자’, ‘임베디드 개발자지만 백엔드도 익혀두자’ 이렇게 말입니다. 시작은 I자형 인재입니다. T자형을 거쳐 π자형 인재로 차근차근 나아가면 됩니다. π자형 인재가 되려면 눈물 나게 노력해야 합니다. 정말 힘듭니다.

공부는 할 때 해야 합니다. 개발 초기 10년에 공부하는 것과 중간 10년에 공부하는 것은 속도가 다릅니다. ‘1년 안에 느는 영어가 당신의 모든 영어다.’ 제가 미국에서 일할 때 한국에서 막 건너온 개발자께 하던 말입니다. 신기하게도 미국에서 10년 살고, 20년 살아도 처음 1년 동안 배운 영어가 전부입니다. 왜냐면 1년이 지나면 사는 데 지장이 없어집니다. 맥 도날드에 가서 햄버거를 사 먹을 수 있고, 미국 친구들이 무슨 얘기하는 지 대충 알아듣고, 회사에서 소통에 문제가 없습니다. 손짓 발짓도 되니까요. 1년이 지나면, 언어가 안 통해도 일이 됩니다. 그러고는 영어가 늘지 않게 됩니다. 그래서 처음 1년, 말이 안 통하는 가장 힘든 첫 1년 동안 집중해 영어를 공부해야 합니다. 개발자 커리어패스 30년 중에서 처음 10년, 모르는 게 가장 많은 시기에 최대한 많이 깊게 공부하세요. 기본 지식이 선입견이 되고, 나이 먹게 되면 새로운 걸 받아들이는 속도가 느려집니다. 그래서 개발 경력 초기에 공부하시라 재차 강조해봅니다.