2020년은 어쩌면 인류가 살아오며 겪은 전례 없는 힘든 한 해였을 것이다.전세계를 강타한 코로나19는 우리가 그동안 습관화해온 수많은 일들을 단 1년 만에 바꿔 놓았다 해도 과언이 아니다.개발자들의 생태계 또한 많은 변화가 있었다. 이번 기고에서는 코로나19가 지배한 올 한 해 동안 어떤 개발 언어가 가장 수요가 많았는지를 살펴보고 2021년의 IT 산업 전망도 함께 짚어 보겠다.◇ 개발 언어 부분, 2020년에 수요가 가장 많았던 상위 5개 언어는전 세계적으로 사용되는 개발 언어는 약 700개 정도라고 한다. 하지만 현재 산업에
컴퓨터 관련 전공자가 아니지만 졸업 후에 개발자로 진출하는 이들이 있다. 대학에서 컴퓨터 관련 학과를 전공하고 개발자로 나선 이들은 전공 관련 배경지식 습득 및 다양한 실습환경을 경험하고 진로를 결정한다. 그런데 졸업 후에 개발자로 나선 비전공자들과 같은 대우를 받아야 하는가. 이를 주제로 개발자들 사이에서 논쟁이 벌어지고는 한다. ‘컴퓨터 관련 학과 출신 인력이 그만큼 대우를 받아야 한다’는 의견도 있고, ‘막상 개발 관련 업무를 맡아서 진행하면 전공자든 비전공자든 별 차이가 없다’라든가 혹은 ‘비전공자가 더 나을 때도 있다’라는
야근 좋아하는 직장인은 없을 것이다. 시간 외 수당을 받는다 해도 거의 대부분은 야근을 하고 싶어 하지 않는다. 그런데, 당연히 야근을 한다는 주위의 인식을 받는 직군이 있다. 정보통신기술(ICT) 관련 직군, 그중에 소프트웨어 개발자 직군이다.2018년에 ‘ICT업종은 재계의 요구를 수용해 주 52시간 근무의 예외로 한다’는 발표가 있어서 논란이 된 적도 있다. 여기서 주목할 부분은 ICT 업종이 예외인 이유가 ‘재계의 요구를 수용해’라는 부분이다.그나마 시간이 한참 지난 후, 올해 초에 정부에서 소프트웨어 분야의 주 52시간제
개발자의 경력 부풀리기는 오래전부터 거론된 이슈지만 여전히 개선되지 않고 있다. 이 주제는 모든 개발자들에 대해서 일반적으로 적용되는 이야기는 아니다. 하지만, 시장의 일부에서 개선되지 않은 채 발생하는 문제점에 대해서 다루고자 한다. 경력 부풀리기가 좋다 나쁘다에 대한 이야기만 하려는 것은 아니다. 사실과 다른 경력 부풀리기는 당연히 해서는 안 되는 일이다. 모든 채용 공고에서는 경력에 대한 허위 사실이 발견되면 징계나 해고를 하겠다고 언급한다. 법원 판결로도 경력 사칭은 그 자체로 신의칙의 중대한 위반이므로 시효를 주장할 수 없
직장생활을 하다 보면 누구나 이직에 대해서 생각하는 시점이 찾아온다. 그렇다면, 개발자들이 이직을 고려하게 되는 시점은 언제일까.연봉 문제도 당연히 고려하는 요소이다. 하지만 오늘 주제와는 약간 벗어났기 때문에 그 부분은 제외하고 이야기하려고 한다.모든 직장인들이 그렇겠지만 이직을 고려할 때에는 직장 내에서의 다양한 문제들로부터 시작되는 경우가 대부분이다.지난번에도 다룬 내용인데 전체 개발자들 중에 구직활동 혹은 이직 활동을 활발하게 하는 비율은 약 16%다. 그 외에 약 60%의 개발자들은 현재의 직장에서 옮기고 싶은 마음이 특별
개발자 채용이 정말 어렵다.우리나라에 IT산업이 시작된 이후 이렇게 개발자 채용이 어려웠던 적이 있었나 싶다. 현재 국내의 산업이 모바일과 인터넷을 접목시키지 않고서는 확장이나 성장이 어려울 만큼 급변하기 때문에 개발자에 대한 수요가 폭발적으로 늘었다는 이야기다. 아마 앞으로도 개발자의 수요는 더욱 늘어날 것으로 생각한다.기업의 규모와는 상관없이 대기업은 대기업이라서, 중소기업은 중소기업이라서, 스타트업은 스타트업이라서 개발자가 필요한 상황이 되다 보니 필요한 인력이 충분히 공급되지 못하는 상황이다. 그나마 대기업은 필요에 따라 개
이번 기고에서는 미뤄 둔 이야기를 꺼내 볼까 한다. 헤드헌터들의 개발자에 대한 포지션 제안 접근 방법이다.직업이라는 것이 생겨난 이후로 채용을 위해 무수히 많은 방식들이 시도되어 왔다. 또한 채용을 전문으로 하는 직군 또한 오래전부터 생겨났다. 바로 헤드헌터라고 불리는 직군이다.헤드헌터는 기업이 요구하는 인재와 직장을 필요로 하는 인재를 맺어주는 아주 중요한 역할을 하는 사회 구성원이다. 하나의 채용을 성사시키기 위해 수없이 많은 사람들을 찾아야 하며, 그 한 명 한 명이 가진 재능과 이력 또한 볼 줄 아는 눈이 필요하다. 전문적인
ATS(Applicant Tracking System)는 지원자 추적 시스템이라는 채용 및 채용 요구 처리 시스템이다. 채용 담당자가 모든 지원자의 이력서를 하나하나 모두 읽을 수 없기 때문에 기업에서 원하는 스펙과 스킬을 가진 지원자의 이력서를 스캔해 기준에 맞지 않는 지원자는 사전에 거르는 작업을 하게 된다. 즉 기업에서 원하는 기준에 부합되는 지원자의 이력서만 ATS에서 걸러진 후에 채용 담당자에게 전달된다는 말이다.해외 IT 기업의 채용 시스템은이러한 채용 시스템은 국내에서는 아직 자리잡지 않고 있으나 마이크로소프트, 구글,
채용이라는 단어를 들었을 때 아마도 대부분은 채용 전문 서비스 사이트 등을 통해 사람을 구하는 모습을 생각할 것이다.사람을 구한다는 건 조직 내부에 필요한 인력이 없기 때문에 외부에서 찾는 경우가 대부분이기 때문이다. 하지만 채용은 외부 인력 자원을 찾아서 내부로 조달하는 것만을 의미하는 것은 아니다. 왜냐면 내부 채용이라는 것도 존재하기 때문이다. 이 경우는 주로 어느 정도 규모가 갖춰져 있고 ‘승진’이나 ‘인사이동’이라는 용어를 더 자주 사용하기 때문에 채용과는 거리가 멀다고 생각할 수 있다.채용을 하는 모든 기업의 목표는 하나
요즘 IT 기업에서 개발자 모시기가 하늘에 별 따기다.채용 관련 서비스를 하다 보니 많은 채용 담당자나 기업의 대표들을 만날 기회가 자주 있는데 "어디 개발자 없는가"라는 이야기를 빠지지 않고 듣게 된다.주위에 지인들이나 알음알음으로 개발자들도 아실 텐데, 왜 채용 하기가 그렇게 힘든 걸까? 신경 쓰지 않았을 때는 참 많이도 보이던 개발자들이 채용을 하려면 보이지 않는 이유는 뭘까? 기린, 용, 해태, 봉황, 여자 친구 같은 상상 속의 존재라서? 오늘은 그 이유를 한번 알아볼까 한다.도대체 개발자들은 어디에 있나요? 개발자들은 사실
IT 개발자라면 이직이나 취업 시 코딩테스트에 대한 고민은 한번쯤 해 봤으리라 생각한다. 개발자를 채용하는 기업에서도 코딩 테스트에 대해 적지 않은 고민을 하는 것으로 알고 있다. 소위 네카라(네이버, 카카오, 라인)로 불리는 IT대기업은 개발자 채용 시 코딩테스트가 필수인 경우가 많다. 국내 뿐만 아니라 개발자들의 최종 목표 또는 끝판왕이라고 할 수 있는 구글 역시 코딩테스트를 치르지 않고서는 개발자로 취업할 수 없다고 알려져 있다. 이런 배경으로 국내외 전세계 IT 기업들은 개발자 채용 시 코딩테스트를 통과의례처럼 생각하고 있다
이번 기고는 9월 25일자 [우리가 모르는 개발자 생태계] 개발할 때 깃(Git)을 써야 하는 이유와 관련된 내용이므로 함께 읽어보기를 권한다.제목에서 깃허브(Github)를 특정한 것은 별다른 이유라기 보다는 단지 가장 많이 사용하는 깃 서비스가 깃허브이기 때문이다. 특별히 애정을 갖거나 광고의 목적이 아님을 우선 밝혀 두고싶다. (개인적으로 필자는 깃랩(Gitlab)을 더 많이 사용하고 있다.)개발자들의 성지라고 불리는 깃허브? 아직도? 왜?깃허브가 개발자들 사이에서 차지하는 위치와 마이크로소프트에 인수 된 이후에 어떤 변화가
언젠가부터 깃(Git)은 개발 프로젝트에 없어서는 안 될 필수요소가 됐다.앞서 기고한 프론트엔드 개발자와 백엔드 개발자의 차이에서 말한 것과 같이 프로젝트라는 것이 개발자 한 명으로 이뤄지는 것이 아니고 다수의 인원이 하나의 팀을 이뤄 진행한다. 그러다 보니 모두가 함께 모여서 일을 할 수 있는 큰 책상의 역할을 해줄 도구가 필요하다. 그 역할을 해 주는 것이 깃이다.이 깃을 좀 더 사용하기 편리하게 다듬고 개선해서 서비스하는 것이 깃허브(Github), 깃랩(Gitlab) 혹은 빗버킷(Bitbucket)과 같은 서비스이다. 이러한
개발자로서, 프로젝트 관리자로서, 프로덕트 오너로서, 20여년간 IT에서 일하며 느낀 ‘잘하는 개발자’에 대해 얘기해보려 한다.이전 기고에서도 다뤘지만 이번 글에서는 자주 목격한 바 있는 ‘아주 변화가 빠른 스타트업에서 개발 조직이 변화되어 가는 과정’을 통해 이야기하겠다.아이템을 발굴하고, 스타트업을 시작하여 서비스/상품을 만드는 시작점을 보면 이렇다. ▲아웃소싱을 통해서 ▲개발자 한 명 정도 구해서 ▲동업자로서 혹은 상당한 지분의 CTO와 같이 시작 등이다. 대부분 위와 같은 경우로 구분을 하는데, 개인적으로는 ‘아웃소싱을 통해
지난 기고에서 개발을 모르는 채용 담당자가 개발자를 뽑을 때의 상황에 대해 소개했다. 이번 기고에서는 조금 더 채용 포지션을 구체화해 이야기하겠다.기업에서 새로운 웹서비스나 모바일 애플리케이션 서비스를 준비하려면 개발자는 반드시 필요하다. 그 과정에서 서비스 기획자, UI/UX 디자이너, 웹 디자이너, 프론트엔드, 벡엔드 혹은 풀스택(Full-Stack), 서버 엔지니어 등의 인원을 필요로 하게 된다.그중에서 프론트엔드(Front-End) 개발자와 백엔드(Back-End) 개발자의 차이에 대해서 이야기하겠다. 기업이 IT 개발자를
기업마다 저마다의 사정은 각각 다르겠지만 적지 않은 기업에서 개발 경험이 없거나 개발을 잘 모르는 채용담당자들이 개발자를 뽑는 상황이 생기곤 한다.전문적인 IT기업에서 개발 경력이 오래된 팀장급이나 프로젝트 담당자가 필요한 인원을 충원하기 위해 채용 담당을 하는 경우엔 큰 어려움 없이 회사가 필요로 하는 인원을 채용할 수 있다. 하지만 내부에 전문적인 IT 기술 인력이 없는 기업에서 새로운 프로젝트를 진행하기 위해 회사가 꼭 필요로 하는 스킬을 가진 개발자를 뽑는 일은 결코 쉬운 일이 아니다.혹은 서너 명이 모여서 시작하는 스타트업
기업의 채용담당자나 기업 대표 중 60%는 IT 개발자 채용 후 후회한 적이 있다고 한다. 원하는 스펙에 맞는 개발자를 어렵게 찾아서, 여러 번의 인터뷰를 거쳐서 채용을 했는데, 후회한다? 왜 이런 일이 생기는 걸까? 어디서부터 잘못된 걸까? 이 문제에 대한 이야기를 해 볼까 한다.개발자 채용의 첫 단계는 내부 조직의 요구에서부터 시작한다. 어느 회사 어느 개발 파트의 업무량이 증가해서 추가 업무를 담당할 개발자가 필요하거나, 기존 개발자의 이직/퇴직으로 인한 대체 인력이 필요한 경우도 있다. 새로운 사업을 준비하기 위한 준비 단계