2019-09-09에세이

비전공 개발자가 전공자보다 정말 불리할까?

이번 포스팅에서는 많은 분들이 질문해주신 컴퓨터 공학을 전공하지 않은 개발자가 과연 전공자에 비해 불리한가에 대해서 한번 이야기해보려고 한다.

어떻게 보면 예민한 주제일수도 있지만 주변에 이와 같은 질문을 주시는 분들도 꽤 있는데다가, 심지어 컴퓨터 공학을 전공하지 않았다는 이유로 자기 자신을 낮게 평가하시는 분도 계셨다. 필자는 이런 것들이 어떤 특정 개인에게 국한된 것이 아니라고 생각되어 이에 대한 필자의 생각을 조심스럽게 한번 적어보려고 한다.

이 포스팅은 비전공 개발자가 많은 분야인 백엔드, 프론트엔드, 모바일 앱 개발자 등에 대해서 이야기할 예정이다. 어플리케이션 레이어보다 더 로우한 레이어에서 개발을 하는 분야는 애초에 비전공자가 들어가기 힘든 분야이기 때문이다.

필자는 지난 1년 간 꽤 많은 사람의 면접을 진행했었는데, 그 중에는 컴퓨터 공학 전공자도 있었고 IT와 전혀 관련없는 전공을 가지신 분도 있었으며, 대학교를 갓 졸업한 신입부터 경력이 10년 넘은 시니어 개발자까지 다양한 사람들이 있었다.

일단 결론부터 말하자면 경력은 경우에 따라 고려되는 경우가 있겠지만, 사실 전공 자체는 컴퓨터 공학 전공이든 파리 뒷다리 분해학 전공이든 그게 그렇게 중요한 건 아니라고 생각한다. 다만 컴퓨터 공학을 전공한 사람이 전공하지 않은 사람에 비해서 여러모로 유리한 점이 있다는 것 또한 사실이기에, 컴퓨터 공학 전공이라는 타이틀 자체가 어떤 이점을 가지고 있는 지는 한번쯤 생각해봄직 하다.

또한 본인이 컴퓨터 관련 학과를 졸업하지 않았다면, 막연한 두려움을 가지기 보다는 내가 전공자와 어떤 차이가 있는지를 명확하게 인지하고 그에 따른 공부를 하면 그만이다. 대학교에서 가르치는 과목이라고 해서 독학하지 못할 것도 없기 때문이다. 그리고 컴퓨터 공학을 전공 했다고 해서 전공자들이 무슨 넘사벽 계층도 아니고, 공부하면 충분히 앞지를 수 있다.

참고로 필자는 인서울 4년제 대학교를 나오지도 않았으며, 컴퓨터 공학 전공도 아니다. 필자는 학점은행제인 동국대학교 전산원에서 멀티미디어 공학을 전공했지만 전공 선택 과목으로 대부분 컴퓨터 공학과의 과목을 선택해서 수강했기 때문에 전공과 비전공의 애매한 경계에 걸쳐있는 혼종이라고 할 수 있다.(원래 멀티미디어과 커리큘럼 자체가 잡캐 양성소다)

그래서 필자는 혼종의 입장에서 컴퓨터 공학을 전공하신 분들의 고민도 들어보고 비전공이신 분들의 고민도 들어볼 수 있었는데, 이에 대한 몇가지 생각을 이번 포스팅에서 한번 적어보려고 한다.

회사에서는 전공보다 실력을 본다

사실 모두 알다시피 개발자와 같은 전문기술직은 학력보다는 실력이 최우선으로 우대된다. 게다가 개발자들의 실력은 천차만별이라 좋은 대학교의 컴퓨터 공학과를 졸업한 10년차 개발자라고 해도 프로그래밍 실력은 형편 없을 수도 있고, 반대로 대학을 안가고 고등학교만 졸업한 신입 개발자라고 해도 엄청난 실력을 가진 개발자일 수도 있는 게 이 쪽 세계의 특징이다.

하지만 많은 사람들이 대학을 가라고 하는 데는 다 이유가 있다. 대학을 가서 더 깊은 공부를 해라 뭐 이런 이유도 있겠지만 사실은 좀 더 현실적인 이유 때문에 추천을 하는 것이다.

이 이유를 알기 위해서 우리는 입사 지원자가 아니라 채용 담당자의 입장에서 생각해볼 필요가 있다.

엄마가 대학을 가라고 했던 이유

사실 필자도 대한민국에서 살면서 그 놈의 지긋지긋한 인서울 대학에 대한 집착을 많이 겪어본 터라, 학력주의사회에 대한 어느 정도 염증을 가지고 있는 사람이다. 하지만 사람들이 학력이나 전공이 중요하다고 말할 수 밖에 없는 이유는 따로 있다. 바로 채용 담당자가 나의 이력서만 보고 얻을 수 있는 정보는 굉장히 단편적이기 때문이다.

이력서에 적혀있는 정보는 단편적이고 진위 여부도 알기 힘들다

자, 우리가 새로운 개발자를 뽑는 채용 업무를 맡았다고 생각해보자. 참고로 작은 기업에서는 이 업무를 해당 업무를 하는 실무자에게 맡기기도 하기 때문에 여러분의 경력과 상관없이 상황에 따라서 언제든지 맡을 수 있는 업무이다.

우리는 이제 채용 담당자로써 하루에도 수십 통 또는 수백 통 씩 쏟아지는 입사지원자들의 이력서를 살펴보고 이 중에서 2차 기술 면접을 진행할 사람을 필터링 해야한다. 이력서에 적힌 정보는 여러 가지가 있겠지만 지원자의 경력과 기술 스펙 정도가 제일 핵심 정보가 될 것이다.(성별과 얼굴을 보시는 분은 없을거라 믿는다)

어쨌든 입사 지원자의 이력서를 보고 우리가 알고 싶은 것은 이 사람이 회사가 요구하는 최소한의 실력을 만족하는 사람인지에 대한 것이다. 조금 더 냉정하게 말하자면, 면접관으로 들어갈 팀원들의 리소스를 투자하면서 이 지원자를 더 자세히 알아보고 싶은 가치가 있는 것인지 고민하는 것이다.

그리고 이 단계에서 이력서라는 몇 장의 종이 쪼가리만 보고 이 사람의 가치관이나 성격 같은 것을 알기는 힘들기 때문에 일반적으로 기술 스펙을 중점으로 확인하게된다.

지원자가 시니어일 경우는 경력을 보고 이 분이 지금까지 어떤 길을 걸어왔는지 대략 유추해볼 수 있지만, 신입이나 주니어의 경우는 경력이라고 할게 거의 없기 때문에 경력에서는 실력에 대한 정보를 거의 얻을 수 없는 경우가 많다.(물론 신입이라도 가끔 눈에 확 띄는 굇수 분들이 있긴 하다)

그렇다면 다음으로 볼 수 있는 것이 이력서에 첨부된 블로그나 깃허브인데, 이 마저도 없는 경우에는 무엇을 보고 이 사람의 실력을 유추해볼 수 있을까?

이런 상황에서는 사실 학교와 전공을 볼 수 밖에 없다. 이 지원자의 실력을 판가름할 수 있는 정보가 더 이상 없기 때문이다. 물론 이후 기술 면접을 진행하면 좀 더 상세히 알 수 있겠지만, 기술 면접 자체도 기존 팀원들의 리소스를 어느 정도 잡아먹는 일이기 때문에 무작정 모든 지원자의 기술 면접을 진행할 수도 없는 노릇이다.

그래서 사람들이 학력 또는 전공도 나름 중요하다고 하는 것이다. 즉, 내가 아무것도 가지고 있지 않은 상황에서 최소한의 보험이라고 할 수 있다.

내 실력을 증명하는 것이 중요하다

우리가 방금 위에서 예시로 보았던 상황을 다시 되짚어보면 회사에게 중요한 것은 이 사람이 회사에 입사해서 일을 할 수 있는 최소한의 실력이 되는가이지, 학교나 전공 자체가 아니다. 고졸이든 인서울대학 컴공을 졸업했든 부트캠프를 수료했든 실력이 좋은 개발자는 어디서든 모셔가기 마련이다.

자, 만약 다음과 같은 두 사람이 있다면 회사는 어떤 사람을 선택할까?

SKY 컴퓨터 공학과를 졸업했지만 깃허브도 없고 어떤 프로젝트를 진행했었는지도 알 수가 없다.

고졸이지만 오픈 소스인 유명 프레임워크의 핵심 컨트리뷰터이다.

조금 극단적인 예시긴 하지만 아무래도 2번 개발자가 선택될 확률이 더 높을 것이다. 결과적으로 회사가 원하는 개발자는 일을 잘하는 개발자이지 단순히 좋은 학교의 컴퓨터 공학과를 졸업한 개발자는 아니기 때문이다.

당연히 학벌 이외에 실력을 검증할만한 요소가 없는 1번 개발자보다는 오픈 소스에 컨트리뷰팅을 함으로써 실력이 어느 정도 검증된 2번 개발자를 선택하는 것이 회사 입장에서도 리스크가 적다. 그러나 만약 2번 개발자의 실력을 유추할 수 있는 무언가가 없었다면 그때는 1번 개발자가 선택될 확률이 높다.

즉, 내 실력을 증명할 수만 있다면 학력이나 전공은 뒤집을 수 있다는 것인데, 이때 회사가 원하는 실력이 어떤 것인지 파악하는 것이 중요하다. 어떤 회사는 특정 프레임워크에 해박한 사람을 원할 수도 있고, 어떤 회사는 프레임워크는 그냥 와서 공부하면 되지만 탄탄한 기초 지식이 있어야한다고 하는 등 회사마다 또는 그 회사가 처한 상황마다 원하는 인재의 기술 스펙은 달라질 수 있기 때문이다.

결과적으로 우리는 전공 여부나 학벌과 관계없이 이 스펙만 맞춰주면 되는 것이다. 근데 회사에서 원하는 기술 스펙과 실력만 맞춰도 취업에 지장이 없다면, 컴퓨터 공학 전공자가 비전공자에 비해서 유리한 점은 없는걸까?

아니, 솔직히 말해서 그렇지는 않다. 실력만 있다면 전공 여부는 중요하지않다라는 말이 비전공자가 더 유리하다라는 말은 아니기 때문이다.

전공자가 비전공자에 비해 유리한 점

컴퓨터 공학을 전공한 사람은 어쨌든 간에 4년 정도 전문적인 커리큘럼을 통해 컴퓨터에 대한 공부를 꾸준하게 해온 사람이다. 그래도 4년 동안 교육을 받은 사람들인데 비전공자와 아무런 차이가 없다면 거짓말일 것이다. 하지만 전공자와 비전공자 간의 차이는 프로그래밍 실력 자체는 아니다.

요즘에는 짧은 기간 안에 부트캠프를 수료하신 분들도 최신 트렌드 기술을 사용하여 어플리케이션을 훌륭하게 만들어 내시는 분들이 많기 때문이다. 그렇다면 회사가 컴퓨터 공학을 전공한 사람에게 기대하는 것은 무엇일까?

지피지기면 백전백승이다

참고로 필자가 지금 이 이야기를 하는 이유는 전공자가 이런 면에서 더 유리하기 때문에 이 부분은 그냥 포기하라는 의미로 하는 말이 아니다.

포스팅의 서두에서 한번 이야기 했지만, 내가 비전공 개발자라면 전공자들에 비해서 어떤 점이 부족한지 알고 있어야 그 점을 보완할 수 있다. 그래야 공부의 방향도 잡을 수 있고 나만의 강점을 만들 수도 있기 때문에 우선 필자가 생각했을 때 컴퓨터 공학 전공자가 가지는 장점에 대해서 한번 이야기 해보려고 한다.

컴퓨터 공학과는 코딩을 배우는 곳이 아니다

솔직히 말해서 둘 다 신입인 경우에는 전공이든 비전공이든 프로그래밍을 하는 실력 자체에는 큰 차이가 없다고 생각한다. 물론 이 기준은 일반적으로 어플리케이션 레이어에서 비즈니스 어플리케이션을 개발하는 개발자를 이야기하는 것이다. 애초에 이보다 더 로우한 레이어의 분야는 비전공자가 들어갈 틈 자체가 넓지 않다.

여기서 많은 분들이 오해하시는 부분이 있는데, 컴퓨터 공학을 전공했으면 당연히 프로그래밍도 비전공자보다 잘할 것이라고 생각하는 것이다. 하지만 컴퓨터 공학도가 학교에서 배우는 것은 함수형 프로그래밍이나 Git을 사용한 버전 관리나 Flux 패턴 같은 것이 아니다. 어디까지나 컴퓨터 공학도가 궁극적으로 추구하는 것은 프로그래밍보다 더 근본적인 컴퓨터 시스템의 원리와 구조적인 사고를 하는 방법이다.

가령 OS 과목을 수강하게 되면 배우는 것 중에서 프로세스 스케줄링(Process Scheduling)라는 것이 있다. 프로세스 스케줄링은 단일 프로세서 시스템에서 여러 개의 프로세스를 어떤 방식으로 실행해야 효율적으로 프로세스를 처리할 수 있을 지에 대한 이론과 알고리즘을 의미한다. 이때 SJF, FCFS, RR 등 여러가지 알고리즘을 배우게 되는데, 사실 왠만큼 로우 레벨로 내려가지 않는 이상 일반적인 어플리케이션을 만들 때 이런 개념을 활용해야 경우는 드물다.

필자도 위 개념을 학교에서 배웠기 때문에 알고는 있었지만 실제로 사용해본 적은 한번도 없고, 대신 Node.js의 이벤트 루프를 이해할 때 약간의 도움은 되었던 것 같다.

컴퓨터 공학과에서 배우는 학문은 이런 느낌이다. 즉, 컴퓨터 공학과를 졸업했다고 해서 바로 비즈니스 어플리케이션을 잘 만드는 것은 약간 거리가 있다는 것이다. 비즈니스 어플리케이션을 잘 만드려면 MVC, MVVM, Flux와 같은 상태 관리 방법이나, 디자인 패턴, 적절한 개발 방법론 등 여러가지 요소가 필요한데 이런 건 학교에서 따로 알려주지 않는다.

심지어 면접보러가서 Git이라는 걸 처음 알았다는 사람도 있었다. 그래서 컴퓨터 공학을 전공한 사람들도 졸업 후 다시 학원에 들어가서 배우는 경우도 왕왕 있다.

컴퓨터 공학을 전공한 사람이 비전공인 사람보다 프로그래밍 실력 자체가 그렇게 월등하게 높지 않다면, 전공자가 비전공자에 비해 유리한 점은 도대체 무엇일까?

기초 지식이 탄탄할 확률이 높다

바로 컴퓨터에 대한 기초 지식을 보유한 사람의 비중이 높다는 것이다. 이때 필자가 말하는 기초 지식은 자료구조, 알고리즘, 네트워크, 수학, 암호학 등 컴퓨터 관련 기술의 근본을 이루는 지식을 말하는 것이다. 사실 이런 지식이 중요하다고 하는 사람도 있고 아닌 사람도 있지만, 필자는 초반에는 몰라도 경력이 쌓이면 쌓일 수록 이런 지식들이 빛을 발한다고 생각한다.

사실 요즘에는 워낙 좋은 프레임워크들도 많은데다가 대부분의 기술들이 사용하기 쉽게 추상화되어 있기 때문에 기초 지식을 모르더라도 프로그램을 만드는 데는 큰 지장이 없다. 하지만 이런 최신 트렌드는 2~3년 만에 패러다임이 완전히 바뀌기도 하는 등 굉장히 빨리 변화하기 때문에 이렇게 쏟아져 나오는 기술을 빠르게 따라갈 수 있는 개발자가 시장에서 양질의 경쟁력을 가질 수 밖에 없다.

이런 새로운 기술들은 얼핏 보면 굉장히 혁신적이고 새로운 개념인 것 같지만, 대부분의 경우 기존에 존재하던 개념을 기반으로 발전한 것들이 많다. 그렇다는 얘기는 결국 기반 기술 자체는 크게 변하지 않는다는 것이다.

예를 들어 HTTP/1.1에서 HTTP/2로 바뀐 것은 얼핏 보면 많은 기능이 추가되었기 때문에 기존과 전혀 다른 새로운 무언가라고 생각할 수 있지만, 결국은 기존의 HTTP 프로토콜에서 이미 사용하고 있던 TCP 커넥션을 좀 더 효율적으로 사용할 수 있게 바뀐 것이다. 이때 기반 기술에 대한 키워드는 TCP가 될 것이다.

Docker 또한 기존에 이미 존재하던 VM 등이 사용하던 가상화 기법이 너무 무거우니까 가상머신마다 각각 Guest OS 레이어를 올리는 것이 아니라 어플리케이션 구동에 필요한 부분만 떼어내서 공통으로 사용할 레이어로 올리고 그 위에 프로세스 레이어만 분리하자는 개념에서 출발한 것이다. 이때 기반 기술에 대한 키워드는 가상화, 레이어에 대한 개념 정도가 될 것이다.

기존의 가상화 기법과 Docker의 차이는 결국은 이 레이어를 어떻게 쌓느냐이다

즉, 이렇게 완전히 새로운 패러다임인 것 같은 기술도 그 밑바닥에는 기존의 기반 기술들이 자리잡고있다. 그렇기 때문에 이런 기반 지식들을 어느 정도 알고 있는 사람은 기반 지식을 모르는 사람보다 새로운 기술이 나왔을 때 학습 곡선을 상대적으로 완만하게 그려나갈 수 있다는 것이다.

그러나 이러한 기반 지식이 없다면 새로운 기술이 나올 때마다 해당 프레임워크의 사용법만을 공부하거나, 다른 개발자들이 이미 정리해놓은 정보들을 통해 학습할 수 밖에 없다. 이런 학습 방식은 이해라기 보다는 암기에 가깝기 때문에 몇 달 뒤에 비슷한 기술이 또 출시되면 같은 루프를 반복하며 학습해야한다.

즉, 컴퓨터 관련 학과를 졸업한 사람은 4년 동안 학교 생활을 어떻게 했던 간에 이런 기초 지식을 학교에서 대부분 배우긴 했다는 것이고, 대체로 이런 기반 지식을 활용해 새로운 기술에 높은 적응력을 보일 가능성이 높다. 이런 이유로 많은 개발자들이 이런 적응력과 잠재력을 컴퓨터 관련 학과를 졸업한 신입이나 주니어에게 기대하게 되는 것이다.

내 실력을 키우고 어필하자

4년 동안 학교에서 구르면서 기초 지식을 좋든 싫든 강제로라도 배워서 나온 전공자에 비해서 비전공자는 학원이나 부트캠프를 통해 짧은 기간동안만 프로그래밍을 배운 경우가 많기 때문에 전공자에 비해 상대적으로 기초에 대한 지식이 적을 수 밖에 없다.

이는 학원이라는 교육 기관의 특성 상 짧은 기간 안에 수강생을 프로그래밍이 가능한 인재로 만들어 내기 위해 발생한 어쩔 수 없는 결과이다. 학원의 경우 대부분 6개월에서 9개월 정도의 학습 기간을 가지는데, 사실 이렇게 짧은 기간 안에 컴퓨터에 대한 기초 이론부터 가르쳐서 취업을 시킨다는 건 거의 불가능한 미션이기 때문이다.

물론 부트캠프를 수료하신 몇몇 분들의 이야기를 들어보면 비록 짧은 기간이지만 그 기간 내내 오전 8시부터 밤 10시까지 프로젝트를 진행하는 소름돋는 스케줄을 소화해낸다고 한다.(다들 열정이 대단하시다)

하지만 아무래도 전공자와 비교 했을 때 절대적인 학습 시간의 차이는 있을 수 밖에 없고, 학원에서 가르치는 것은 코딩 또는 특정 프레임워크의 사용법이지 컴퓨터의 기초 개념이 아니기 때문에 연차가 쌓일 수록 이런 기초 지식의 부재로 인해 새로운 지식을 학습하는 것에 부담을 느끼고 경쟁에서 밀리는 경우가 왕왕 보인다.

그러나 실제로 취업하고 있는 수많은 비전공 출신 개발자 분들을 보면 컴퓨터 공학을 전공하지 않은 개발자들이 시장에서 경쟁력을 가지고 있다는 것 또한 분명히 사실이다.

위에서 이야기했듯이 개발자라는 직업은 결국 실력이 깡패기 때문에 내 실력을 얼마나 잘 어필할 수 있냐가 중요한 포인트다. 필자도 일단 이력서에는 멀티미디어 공학이라고 찍혀있기 때문에, 면접을 볼 때 비록 컴퓨터 공학을 전공하지는 않았지만 필자만의 장점이 있다는 점을 어필하고는 한다.

블로그와 깃허브는 중요하다

블로그는 채용 담당자 입장에서 굉장히 도움이 많이 되는 정보이다. 이 사람이 평소에 생각하는 것과 관심있는 기술, 공부하는 방법, 문제를 해결했던 경험 등을 정제된 형태의 데이터로 한 눈에 볼 수 있는 창구이기 때문이다.

비전공 개발자는 이력서를 통해 채용 담당자에게 내 실력을 인증할 수 있는 데이터가 전공자에 비해 상대적으로 부족하기 때문에 이렇게 적극적으로 자신의 실력과 프로그래밍에 대한 관심을 어필할 수 있는 수단을 사용하는 것이 좋다.

또한 많은 기업들이 내가 알고 있는 지식을 남에게 공유하는 행위에 대해서 긍정적으로 생각하고 있기 때문에 블로그를 꾸준히 작성하면 분명히 도움이 된다. 도저히 뭘 써야할 지 감이 안온다면 자신이 재밌게 읽었던 외국 포스팅의 번역부터 시작해보자. 필자 같은 경우는 크게 두가지 주제를 가지고 글을 쓰는 편인데, 하나는 지금 이 포스팅처럼 그냥 필자의 생각을 적는 것이고, 다른 하나는 기술 관련 포스팅이다.

특히 기술 관련 글을 작성할 때는 잘못된 지식을 전하지 않으려는 두려움 때문에라도 강제로 엄청난 리서칭을 하게 될 수 밖에 없고, 그 리서치 결과를 글로 정리하는 과정에서 다시 한번 정제되기 때문에 그냥 읽기만 하는 것보다 오히려 더 공부가 되고 기억에도 오래 남는 경향이 있다.

또한 이렇게 자신의 생각을 글로 정리해서 적는 행위 자체는 논리력 향상에 굉장히 많은 도움을 준다고 한다. 말로 하면 어느 정도 논법이 맞지 않아도 들어줄만 하지만 이렇게 글을 작성할 때 논법과 주제가 흐려지기 시작하면 그냥 딱 봐도 굉장히 어색한 글이 되버리기 때문이다. 개발자에게 논리력이 얼마나 중요한 요소인지는 굳이 말하지 않아도 다들 알고있으리라 생각한다.

그리고 깃허브는 두 번 말하면 입 아플 정도로 엄청 중요하다. 하지만 잔디를 꾸준히 심지않는 빈 계정과 다름 없는 상태에서는 별로 임팩트가 없기 때문에 사이드 프로젝트를 하던 오픈 소스에 기여를 하던 꾸준히 커밋을 하는 것을 추천한다. 솔직히 어떤 사람의 깃허브 계정을 봤을 때 진한 초록색 잔디가 가득 심어져 있다면 오 대박 쩌는걸이라는 감탄사가 나올 수 밖에 없다.

필자의 깃허브 잔디. 빡빡하진 않지만 적어도 `얘가 뭔가를 하고 있구나` 정도는 알 수 있다

게다가 깃허브 레파지토리를 살펴보거나 어떤 프로젝트에 스타를 찍었는지를 보면 최근 어떤 기술에 관심을 가지고 있는 지도 알 수 있다. 하지만 무엇보다 제일 큰 장점은 이 사람이 작성한 코드를 직접 볼 수 있다는 것에 있다. 코딩을 시작한지 얼마 안된 사람일수록 자신의 코드를 공개된 장소에 오픈한다는 것을 부끄럽다고 생각할 수 있지만, 생각보다 남들이 여러분의 코드를 그렇게까지 자세히 분석하고 점수 매기지는 않으니까 그냥 작은 걸 만들더라도 왠만하면 Public으로 깃허브에 올리자.

깃허브 레파지토리를 보면 어떤 기술에 관심이 있는지 대략 알 수 있다

최근에는 코드스테이츠와 같은 부트캠프에서도 수강생들에게 블로그나 깃허브 계정을 생성하는 것을 추천하고 있는 걸로 봐서 취업에 이런 것들이 도움이 된다는 사실을 수강생들에게도 알려주고 있는 것 같다.

나만의 전문성을 확보하자

개발자는 현실의 다양한 문제를 컴퓨터를 통해 해결하는 사람들이다. 이때 현실의 문제란 어떤 단일 카테고리의 문제가 아니라 굉장히 다양한 카테고리의 문제라는 것을 잊어서는 안된다. 소프트웨어는 의료, 금융, 예술 등 다양한 분야에서 사용되고 있고, 결국 그 소프트웨어도 개발자가 만드는 것이다.

이때 이런 다양한 분야의 문제를 해결하기 위해서는 컴퓨터 관련 지식 뿐만 아니라 다른 분야의 지식도 함께 요구될 수 밖에 없다. 자신이 만드는 프로그램이 어떤 일을 하는지도 모르면서 좋은 프로그램을 만들 수는 없지 않을까?

비전공 개발자는 자신의 원래 전문 분야가 있는 사람들이 많기 때문에 이 점을 잘 살려보면 자신만의 특별한 무기가 될 수도 있다고 생각한다. 어쨌든 개발자로 일을 하고 있다는 것은 개발에도 어느 정도 전문성을 가지고 있다는 것이기 때문에, 자신의 원래 전문 분야가 있던 사람은 전문 분야가 최소 2개 이상이라는 것이기 때문이다.

만약 더존과 같은 회계관리 프로그램을 만드려면 개발자도 어느 정도 회계에 대한 지식이 있어야 하고, Logic Pro X와 같은 오디오 편집 프로그램을 만드려면 개발자도 오디오와 음악에 대한 지식이 있어야 하기 때문이다. 그러나 4년 동안 컴퓨터 공학만을 공부한 사람의 경우에는 따로 찾아서 공부하지 않는 이상 다른 분야의 지식을 습득하기 쉽지 않기 때문에 다른 전공을 공부하고 개발자가 된 사람은 이 점에서 나름 강점을 가지고 있다.

오디오와 음악에 대한 지식이 없다면 Logic Pro X와 같은 프로그램은 만들 수 없다

필자 같은 경우는 예전에 연예 기획사에서 사운드 엔지니어로 일을 했었기 때문에 오디오와 레코딩에 지식을 가지고 있다. 또한 어릴 때부터 꾸준히 음악 교육을 받았기 때문에 음악에 대한 지식도 어느 정도 가지고 있다.

그래서 필자는 Web Audio API와 같은 생소한 API를 꽤나 단기간에 이해할 수 있었고, 이 API에서 제공해주는 오실레이터의 프로퍼티들을 조절하여 원하는 악기의 소리를 만들어 낼 수도 있었다. 이런 음악과 오디오 이론에 대한 지식은 컴퓨터 공학과 마찬가지로 하나의 전문 분야이기 때문에 반짝 공부한다고 단기간에 습득할 수 있는 것은 아니다.

많은 비전공 개발자 분들은 컴퓨터 공학에 대한 지식이 전공자보다 부족하다고 생각하기 때문에 자신이 부족한 개발자라고 생각하지만, 조금만 다르게 생각해보면 컴퓨터 공학 지식은 부족할지 몰라도 다른 분야에 대한 전문 지식을 가지고 있는, 오히려 더 특별한 능력의 소유자들이라고도 할 수 있다.

물론 지금 회사에서 맡고 있는 일이 자신의 전공과 전혀 다른 일이라면 딱히 도움은 안되겠지만, 필자는 오히려 자신의 전공을 살려서 틈새 시장을 노려볼 수도 있지 않나라는 생각을 해보게 된다.

그래도 컴퓨터 기초 지식은 중요하다

하지만 전공이든 비전공이든 어쨌든 개발자는 개발자이고, 개발자의 기본적인 능력은 컴퓨터에 대한 이해에서부터 출발하는 것이기 때문에 이 점을 무시할 수는 없다.

필자가 위에서 이야기했듯이 컴퓨터 공학을 전공한 사람이 비전공자에 비해서 강점을 가지는 부분은 바로 컴퓨터에 대한 기초 지식이다. 하지만 이런 기초 지식은 당장 취업에 도움이 되는 게 아니기 때문에 학원에서는 비중있게 가르쳐 주지 않고, 이론의 비중 또한 높기 때문에 독학으로 하기엔 너무 재미가 없다.

그러나 필자는 개인적으로 다른 건 몰라도 자료구조, 알고리즘, 네트워크 이 3개는 왠만하면 공부를 하는 것이 좋다고 생각한다. 이 3가지 과목은 실무에서 알게 모르게 도움이 많이 된다.

자료구조

예를 들어 어떤 상품들의 정보를 서버로부터 받아와서 클라이언트에 저장해야하는 상황이라고 생각해보자. 이때 각각의 상품들은 정수 자료형으로 표현되는 ID 값을 가지고 있다.

{
  "goods": [
    {
      "id": 1,
      "name": "맥북프로"
    },
    {
      "id": 22,
      "name": "청바지"
    },
    {
      "id": 100,
      "name": "말린 오징어"
    }
  ]
}

자, 서버로부터 응답이 이렇게 내려온다고 생각해보자. 이때 우리는 이 데이터를 어떻게 가공하고 저장할 것인지 선택해야한다. 지금 필자는 대충 3가지 정도를 떠올렸다.

그냥 저대로 배열 안에 담아 놓고 쓴다.

상품 ID를 인덱스로 사용해서 새로운 배열에 담는다.

맵을 사용한다.

이 중에서 각 방법이 어떤 장점이 있고 어떤 단점이 있을까? 1번 방법은 서버에서 내려준 응답 상태의 구조를 그대로 사용하기 때문에 추가적인 이터레이션을 돌지 않아도 된다. 대신 어떤 특정 상품에 접근하고 싶다면 매번 배열을 탐색해야하기 때문에 O(n)의 시간 복잡도가 소요될 것이다.

2번 방법은 어떨까? 이 방법은 상품의 ID를 배열의 인덱스로 사용하기 때문에 값에 대한 접근을 O(1)만에 할 수 있다고 생각할 수 있지만, JavaScript에서는 아니다. 이 경우 배열에 들어가는 원소는 Object 자료형이므로 원시 자료형처럼 원소들이 동일한 자료형으로 평가되지 않는다. 결국 저 배열은 리스트로 생성될 것이고, 리스트는 특정 원소에 접근하기 위해 Head부터 차례대로 탐색해야하므로 접근 시간은 결국 O(n)이다.

이에 대한 자세한 내용은 JavaScript 배열(Array)의 발전과 성능에 대해서 자세히 알아보기 포스팅을 참고하자.

게다가 저 배열이 리스트가 아니라 실제 배열이라고 하더라도 문제는 여전히 존재한다. 상품의 ID는 대부분 데이터베이스에서 사용하는 Primary Key일 것이기 때문에 새로운 상품이 데이터베이스에 추가될수록 할당되는 ID의 값도 점점 증가할 것이다. 그러면 메모리에 할당해야하는 배열의 길이도 점점 길어질 것이라는 사실을 예상 해볼 수 있다. (배열은 메모리에 연속적으로 할당된다)

그래서 이런 경우라면 필자는 3번 방법을 사용할 것 같다. ID는 상품을 구분하는 고유한 값이기 때문에 중복될 가능성이 없다고 봐도 무방하다. 즉 그냥 맵에다가 데이터를 막 때려박아도 충돌이 날 가능성이 없다는 것이다. 맵의 특성 상 접근 자체도 O(1)으로 해결할 수 있고, 늘 서버로부터 받아온 상품 만큼만 메모리를 할당하면 되므로 합리적이다.

배열에 대한 이해가 없다면 잘못된 선택을 할 수도 있다

지금 이 예시는 굉장히 간단한 예시지만 실무에서 충분히 자주 접하는 상황이다. 기본적으로 배열이라는 자료구조가 메모리에 어떻게 할당되는지, 배열과 맵의 장단점이 무엇인지, 이 자료구조에서 값에 어떻게 접근하는지와 같은 자료구조에 대한 기본적인 지식이 없다면 저 3가지 보기 중에 현재 상황에 적합한 답을 찾기 힘들 것이다.

알고리즘

알고리즘의 경우에는 하노이의 탑같은 문제를 푸는 방법을 외우라는 것이 절대 아니다. 알고리즘은 단순히 어떤 문제를 풀기 위한 방법을 외우는 것이 아니라 어떤 문제를 효율적으로 풀기 위한 방법을 찾는 것이다. 주어진 행렬 안에서 가장 큰 정사각형을 찾는 문제를 푸는 것이 중요한 게 아니라, 내가 삼중 for문으로 작성한 코드에서 어떻게 하면 for문을 하나라도 줄일 수 있을 지를 고민하는 것이 중요한 것이다.

최소한 자신이 작성한 코드가 어느 정도의 시간 복잡도를 가졌는지는 계산할 수 있어야 한다. 필자가 방금 위의 예시에서 배열의 요소에 접근하는데 소요되는 시간복잡도와 리스트의 요소에 접근하는데 소요되는 시간복잡도를 계산한 것도 알고리즘의 범주 안에 속한다.

또한 알고리즘은 굉장히 넓고 방대한 분야이기 때문에, 어떤 것부터 시작해야 하는지 감이 오지 않을 수도 있다. 그럴 때는 정렬과 탐색부터 한번 도전해보는 것을 추천한다. 기본적인 정렬 알고리즘인 Bubble, Merge, Quick 같은 알고리즘이나 탐색 알고리즘인 Binary Search와 같은 알고리즘은 꽤 직관적이기 때문에 이해하기도 그렇게 어렵지 않다.

또한 이런 알고리즘을 공부하다보면 자연스럽게 자료구조와도 엮이기 때문에 자료구조와 알고리즘을 함께 공부하는 것을 추천한다. 프로그래머스와 같은 알고리즘 문제 사이트에서 문제를 푸는 것도 물론 재밌고 좋지만, 이런 문제는 기초라기보다 응용 문제에 가깝기 때문에 기초적인 개념을 먼저 잡고나서 도전하는 것을 추천한다.

그리고 이런 사이트들은 다른 사람들이 이 문제를 어떻게 풀었는지 볼 수 있는 기능을 제공하는 경우가 많은데, 많은 분들이 극단적으로 코드 라인을 줄이는 것에 초점을 맞추고 있는 것 같아서 그런 코드를 보고 공부하는 것을 딱히 추천하고 싶지는 않다. 아마 그런 사이트에서 그렇게 코드 라인을 줄여서 작성하시는 분들도 실무에서까지 그렇게 작성하시진 않을 것이다.

네트워크

네트워크의 경우, 웹이나 앱 개발자인 이상 대부분 클라이언트와 서버가 통신하는 기능을 만질 수 밖에 없다. 특히 웹의 경우는 네트워크 위에서 개발하는 것이라고 봐도 무방할 정도로 네트워크와 밀접한 관련이 있기 때문에 네트워크에 대한 기본적인 지식은 필수다. 또한 웹 어플리케이션을 개발하다보면 네트워크와 관련된 다양한 문제들이 발생하는데, 네트워크에 대한 기본적인 지식이 없다면 해결하기 힘든 경우가 많다.

아마 프론트엔드 개발자가 겪는 대표적인 네트워크 이슈로는 CORS(Cross-Origin Resource Sharing) 위반을 예로 들 수 있을 것 같다. 이 이슈는 a.com이 b.com처럼 서로 다른 오리진을 가진 곳으로 리소스를 요청하는 경우 보안을 침해할 가능성이 있기 때문에 브라우저가 서버의 응답을 무시해버리는 이슈다.

클라이언트는 본 요청을 서버로 보내기 전에 Preflight라는 예비 요청에 사용하고 싶은 커스텀 헤더와 메소드 등을 담아서 미리 보내게 되는데 이때 서버가 이 예비 요청을 받고 응답 헤더 내에 Access-Control-Allow-Origin라는 키를 사용하여 올바른 값을 내려주지 않는다면 CORS 위반이 되어 통신을 할 수 없는 이슈가 발생하는 것이다.

CORS의 통신 과정

이때 이런 일련의 통신 과정과 보안에 대한 기본적인 개념이 없다면 인터넷에 많이 나와있는 해결책인 Access-Control-Allow-Origin: *을 운영환경에서 사용하여 서버의 보안을 망가트릴수도 있다. 게다가 이 문제를 주로 접하는 것은 프론트엔드 개발자이지만 실질적인 해결은 백엔드 쪽에서 해줘야 하기 때문에 뭐가 문제인지 모른다면 혼자 부여잡고 끙끙대다가 아예 해결을 못할 수도 있다.

마치며

필자가 이 포스팅을 작성하게 된 이유는 자신이 비전공 개발자라는 이유로 자신을 낮게 평가하는 분들 때문이었다. 필자는 부트캠프나 학원을 다녀본 적이 없기 때문에 모든 것을 공감하지는 못하지만, 부트캠프나 학원 출신 개발자 분들이 전공에 대한 선입견 때문에 답답한 감정을 느꼈다고 하는 이야기를 들으면 기분이 좋지는 않았다.

전공 여부를 가지고 뭐라고 하는 사람들도 문제지만, 본인들 스스로도 그 프레임에 갇혀서 내가 비전공이라 그런가라는 이야기를 하는 경우가 종종 있기에, 필자는 그럴때마다 그냥 개발자는 개발자일 뿐이다라고 얘기를 해주고는 한다.

사실 학원에서 6개월 동안 공부한 개발자가 학교에서 4년 동안 공부한 개발자에 비해 컴퓨터에 대한 기초 지식이 모자른 것은 어찌보면 당연하다. 그러나 어떠한 개발자에 대한 평가는 컴퓨터에 대한 지식만으로 평가되는 것이 아니라는 사실을 잊지 않았으면 좋겠다.

그리고 포스팅의 주제 상 어쩔 수 없이 전공과 비전공이라는 단어를 많이 사용했지만, 개발에 있어서 전공자냐 비전공자냐는 절대 중요한 게 아니다. 그냥 개발자는 개발자일 뿐이고 컴퓨터 이론에 특화된 개발자와 다른 분야의 지식도 함께 섭렵한 개발자처럼 각 개발자마다의 특징만 있을 뿐이다.

만약에 누군가가 여러분에게 컴공 출신 개발자는 역시 잘하네, 역시 비전공자 출신은 안돼 같은 말을 한다면 그건 그 사람의 마인드 셋이 잘못된 것이지, 여러분이 잘못된 것이 아니다. 하지만 위에서 설명한대로 4년 동안 컴퓨터 공학 공부를 하고 졸업한 사람들에 비교했을 때, 그렇지 않은 사람들이 컴퓨터에 대한 기초 지식이 부족한 것은 사실이기에 기초에 대한 공부는 꾸준히 하는 것이 좋을 것 같다는 생각이 든다.

IT 시장의 스펙트럼은 굉장히 넓고, 각 분야에서 요구되는 개발자들의 스펙도 그만큼 다양하다. 그 말인 즉슨, 전공 여부와 상관없이 여러분이 가진 능력들을 잘 조합해서 자신만의 무기로 만들면 시장에서 충분히 경쟁력을 가질 수 있다는 소리다. 꾸준히 공부하고 재밌게 코딩하다보면 일은 알아서 잘 풀릴 거라고 생각하자.

이상으로 비전공 개발자가 전공자보다 정말 불리할까? 포스팅을 마친다.