이전에는 상상할 수 없는 일이 벌어지고 있습니다.
프로그래머(개발자)가 꿈인 아이들이 많아지고 있다는 것.
(지금까지의 경험으로는 도시락 싸들고 따라다니며 뜯어말리고 싶지만) 그만큼 IT와 프로그래머에 대한 사회적인 인식이 많이 긍정적으로 바뀌었다는 반증이겠지요.
요 근래 개발자 몸값 인플레이션을 거치면서 대기업의 개발자가 아니더라도 몸값이 많이 올라간 것도 많은 영향을 끼쳤을 것이고, 전공을 하지 않더라도 도전하고 어느 정도의 성공을 이루는 사람이 많아진 것도 영향을 끼쳤을 것이라고 생각합니다.
그렇다면 (이전과 비교하여) 두터워지고 있는 개발자 시장에서 좋은 개발자란 과연 어떻게 정의할 수 있을까요? 좋은 개발자가 되기 위한, 그리고 찾기 위한 나름의 이야기를 해보려고 합니다.
너무 당연한 이야기이지만 일단 개발자는 컴퓨터를 잘 다뤄야 합니다.
OS나 하드웨어에 대한 이해도가 얇은 상태의 개발자가 많다는 것을 부쩍 많이 느끼는 요즘입니다. 전공자라 할지라도 이제 학교에서 이런 것에 대한 교육이 많이 줄어든 탓인지 개발자가 직접적으로 대화하는 상대인 컴퓨터에 대한 이해가 많이 부족한 상황이 많이 보입니다.
하드웨어가 워낙 발달하고, 컴파일러가 강력해져서 세세한 메모리 관리나 bit 단위의 계산은 몰라도 되는 때가 왔다고는 하지만 그래도 그것을 알고 다루는 것과 모르고 다루는 것의 차이는 어마어마한 레벨의 격차가 있다고 생각합니다.
(라떼 시절에는 윈도우95 버전은 95번 재설치해봐야 이해하고, 윈도우98은 98번이라는 농담이 있었죠. 그런 농담 던지던 분들이 윈도우2000 이 나왔을 때의 멘붕이란..)
그리고 두 번째로는 프로그램 언어를 활용하는 능력입니다.
위에도 이야기했듯이 요즘은 프로그램 언어나 컴파일러가 워낙에 강력해서 raw 레벨의 코드까지 손댈 일이 극히 적지만, 그렇다는 것은 raw를 이해하는 개발자가 거의 없다는 의미도 됩니다. 이게 어떻게 왜 동작하는지에 대한 표면적인 이해도나 공식처럼 사용하는 각 프로그래밍 언어의 라이브러리나 api 가 아닌, 최소한의 로직의 동작 원리를 이해하고 설명할 수 있는 정도가 되어야 할 것입니다.
오픈소스도 물론 훌륭하고 많이 검증되어 있기 때문에 자유롭게 사용하는 것은 당연하겠지만, 그 원리를 알고 사용하는 것과 그냥 가져다 쓰는 것은 오픈소스라 할지라도 내 것이 되었는가 아닌가에 대한 큰 차이가 발생할 것입니다.
위의 두 개는 기본 소양이라 하였지만, 개발자라면 당연히 있어야 할 것들이고 차이가 있다 하더라도 시간이 (많이) 지나면 그 차이의 간극이 메워지는 성향의 것들이라 생각합니다.
그렇기에 세 번째부터가 이 글을 쓰게 된 궁극적인 이유입니다.
세 번째 좋은 개발자의 기준은 스스로에게 주어진 비즈니스와 그 상황에 대한 이해도와 유연성입니다.
“최근 프로그래밍(or 아키텍처)의 유행은 이거니까 난 이거만 학습할 거야.” 는 절대 안 됩니다. 내가 가게 될 곳, 일하고 있는 곳은 유행을 따르지 않을 수도 있지요. 스스로가 상황을 고를 수 있다면 상관없겠지만, 직장인은 그러한 상황을 거의 만들 수 없다고 생각합니다. 상황을 만드는 것은 일반적이지 않은 상위 몇% 의 직장인에게 해당되는 이야기이니까요. 당당한 것은 좋지만 자기 스스로의 현 위치를 아는 것도 중요합니다. 이전 글에서도 이야기했지만 나에 대한 평가를 내가 내리는 것은 사회에서 아무런 의미가 없습니다.
조직에 속해서 개발을 하다 보면 탄탄한 설계를 추구하는 조직도 있을 것이고, 생존을 위한 속도를 우선시하는 조직도 있을 것입니다.
변화에 대응할 수 있는 구조, 명확한 정의를 가진 모듈과 라이브러리, 사이드 이펙트를 최소화시킬 수 있는 로직들은 모든 개발자가 열광하는 정답과도 같은 것입니다. 개발자적 욕심으로는 무조건 탄탄한 설계와 영원히 흔들리지 않고, (기능적으로) 지워야 할 일도 없는 것을 만들고 싶어 할 것이고요. 그런데 전 지구 상의 개발자 그 누구에게 물어봐도 이런 경험을 해 본 사람은 아무도 없을 것입니다.
레거시 코드는 무조건 옳지 않고, 무겁고, 비효율적이기 때문에 최신 유행을 따라야만 성공적인 개발일까요?
주어진 비즈니스 상황을 이해하지 못한 채로 개발 유행만을 좇는 것은 개발자 스스로에게도 엄청난 낭비이자 오버 스펙이며, 아집과 불합리한 욕심일 뿐입니다.
개발자는 무언가를 바꾸는 사람이 아닙니다. 문제를 발견하고 해결하는 사람이지요. 문제는 다른 사람(직종)이 찾아줄 수도 있지만, 해결은 오롯이 개발자의 몫이 됩니다. 당면 과제의 해결을 위해 전체(시스템, 아키텍처)를 바꾸는 것은 개발자에게 흔히 주어지는 상황이 아니기 때문에 현재 주어진 상황에서의 해결을 모색해야만 합니다.
주어진 상황은 개발적인 또는 프로그램 코드나 시스템의 상황만을 의미하는 것이 아닙니다. 지금 내가 만들고 있는 것의 비즈니스(시장) 상황을 의미합니다. 내가 만든 생산품은 결국 시장에서 고객에게 평가받는 것이지 학교에서 학점을 받는 것처럼 개발을 완료하고 이수하는 검사받는 것이 절대 아닙니다.
레거시 코드와 시스템을 보고 한숨만 쉬며 불평불만을 쏟아내더라도 지금의 나에게 주어진 미션은 현 상황에서의 해결이지 새로운 것을 만들어서 교체하는 것이 절대 아닙니다. 그렇기에 현재 상황을 이해함에 반드시 따라와야 하는 것은 유연성인 것입니다. 빠르게 내가 할 수 있는가 없는가를 파악하여 누군가의 도움을 받거나 도움을 받을 수 없다면 해결을 위한 학습을 시작해야 합니다. 그리고 그것은 내가 해보지 않은 영역일 수도 있기 때문에 그동안 내가 해오던 것의 힘을 빌려 유연하게 대처해야 할 것입니다.
해결을 위한 타 직종(기획자, 디자이너)과의 ‘원활한’ 커뮤니케이션은 “정말 좋은” 개발자의 영역이기 때문에 “좋은” 개발자의 영역에서는 그리 중요하지 않다고 생각합니다.
네 번째는 개발자로서의 방향성, 목표를 가지고 있는지의 여부입니다.
위에서 이야기한 것처럼 개발자는 누군가에게 필요한 걸 만들어내기만 하면 되는 그런 것이 아닙니다. 나는 개발자로서 무엇을 할 것이고 궁극적인 목표가 무엇일까를 생각해보아야 합니다. 난 프론트 엔드 개발자가 될 거야, 난 앱 개발자가 될 거야의 작은 방향성을 말하는 것이 아닙니다. 개발자라는 직업을 선택한 사람으로서 난 어디까지 올라가고 싶은가입니다.
거창하게 모두가 아는 이름만 들으면 해당 플랫폼이나 시스템에서 유명한 사람이 되고자 목표를 잡으라는 것이 아닙니다. 지금 내가 이 직업을 선택함으로써 만족의 기준을 어디까지로 정할 것이냐에 대한 이야기입니다. 개발자로서 돈을 많이 벌고 싶은 것, 개발자로서 누가 들어도 알만한 회사에 가고 싶은 것. 이러한 것도 중요한 방향성과 목표인 것입니다.
위의 네 가지 중에 두 가지 정도만 인지(라도)하고 있는 개발자라면 좋은 개발자라고 생각합니다.
물론 경험이 많은 개발자 분들은 느낌적인 느낌으로 다 알고 계시는 내용이고, 위의 이슈로 인하여 한번 이상 누군가와 부딪쳐본(!) 후에 살짝이나마 이해하고 계실 거라 생각합니다.
우리나라에서 IT 개발자라는 직군이 생긴지는 오래되었지만, 최근의 급격한 사회적 변화 속에서 조금씩 틀이 잡혀가고, 사회적인 인식도 변화하면서 각자 개개인의 방향성을 가지고 유기적으로 활동하는 개발자 분들이 늘어나고 있음을 체감하는 요즘입니다.
위의 네 가지를 요즘 개발자를 준비하는 분들이나 주니어 개발자 분들에게 이야기하면 고인물, 꼰대, 가스라이팅 하는 거냐 등의 말을 많이 듣게 됩니다.
새로운 세대가 이런 생각을 갖는 것은 그들이 틀리거나 잘못된 것이 아닌 이전 세대의 잘못이기 때문에 그들의 생각이 나무라거나 탓할 생각은 절대 없습니다.
그런 과도기적인 세대의 한 명으로서 언젠가 그들이. “아 그때 들었던 (기분 나쁜) 이야기가 이런 거였구나.”라고 느끼기만 한다면 나름 보람차게 욕을 먹었다고 생각합니다. ^^
뭐든지 시키는 것을 다 하는 (노예) 개발자가 되어야 한다는 이야기가 아닙니다.
어린아이들의 장래 희망이 될 정도의 직업군이 되었다면 직업에 대한 자부심과 책임감을 강하게 가져야 할 때가 되었다는 것입니다.
44
