보통 회사는 3년 차 5년 차 10년 차 등의 기준으로 개발자를 나눕니다 3년 차는 무엇이든 문제없이 만들 수 있는 개발자를 의미합니다 간단한 요구사항을 주었을 때 어떻게든 만들어내고 문제가 생겨도 어떻게든 해결할 수 있는 사람입니다

5년 차 개발자는 3년 차 때의 시행착오를 극복한 사람입니다 자기가 되는대로 만든 프로그램에 스스로 데여보고선 '아 이렇게 하면 안되는구나'를 깨닳은 사람입니다 단순히 프로그램을 만들 수 있는 것뿐 아니라 어떤 방식이 문제를 일으킬 수 있는지를 이해하고 이를 피할 수 있는 능력을 갖춘 사람을 뜻합니다 즉 무엇이 되고 무엇이 안 되는지를 명확히 아는 개발자입니다

7년 차가 되면 어떻게 개발해야하는지 스스로의 기준이 생겨있는 사람입니다 이건 이렇게 저건 저렇게 해야하고 왜 그래야하는지를 잘 아고 있습니다 적어도 자신의 개발 영역에 한해서는 모르는것이 없고 모르는 부분이 있더라도 어떻게 해결해야 하는지 알고 있습니다

개인적으로 7년차 수준이 넘어야 전문가라고 부를 수 있다고 생각합니다

10년차 개발자는 팀을 이끌고 프로젝트를 총괄하는 역할을 할 수 있습니다 큰 프로젝트를 구축하고 관리할 수 있습니다 목표가 주어지면 몇명의 개발자가 어느정도 시간을 투여하여 개발할 수 있는지 측정할 수 있습니다

연차는 경력의 척도일 수 있지만 그보다는 실제 능력이 중요합니다 만약 당신이 모집요강에서 말한 경력을 가지고 있지 않아도 그에 준하는 실력을 가지고 있다면 충분히 지원할 수 있습니다 자기소개서와 면접을 통해 자신이 충분한 능력을 가지고 있다는걸 어필할 수 있다면 문제없이 입사할 수 있습니다 반대로 연차만 채우고 그에 걸맞는 실력을 갖추지 못했다면 이직이나 승진은 쉽지 않을 것입니다

개발자 지망생이라면 3년 차 모집 요강에 주목할 필요가 있습니다 만약 당신이 학교에서 배운 지식을 바탕으로 회사에서 시키는 일 정도는 스스로 해낼 수 있다면 3년 차 개발자에 지원해도 좋습니다 이는 회사에도 큰 이익입니다 회사는 3년 차 연봉을 기대하며 채용하지만 신입 개발자 수준의 연봉을 주고 그 이상의 성과를 얻을 수 있기 때문입니다 물론 이 경우 성과를 증명하면 연봉은 빠르게 올라갈 것입니다

또 한 가지 팁을 드리자면 2년 차 개발자를 뽑는 모집 요강이 간혹 보입니다 이는 신입 개발자를 뽑고 싶지만 수준이 떨어지는 지원자가 너무 많을 것을 우려해 2년 차로 적어 놓은 것일 가능성이 큽니다 신입 개발자가 어느 정도 기본기를 갖췄다면 이런 요강에 지원하는 것도 좋은 방법입니다

마지막으로 모집 요강에 나오는 필요 기술에 대해 너무 걱정할 필요는 없습니다 예를 들어 "MySQL Oracle Postgres 경험 우대"라고 적혀 있다고 해서 이 모든 데이터베이스를 경험해야 한다는 의미는 아닙니다 그중 하나라도 깊게 다뤄본 경험이 있다면 지원해도 충분합니다 이처럼 기술 요구사항은 기본적인 숙련도를 갖출 수 있느냐를 묻는 것이지 모든 기술을 경험해봤는지를 묻는 것은 아닙니다

가장 좋은 방법은 내가 목표로 삼는 프로그램을 스스로 구현해 보는 것입니다 예를 들어 카카오톡과 같은 메신저 프로그램을 혼자 만들어보거나 내가 좋아하는 게임을 직접 개발해보는 것 혹은 YouTube 같은 동영상 스트리밍 사이트를 구현해보는 것이 좋은 예입니다 이런 프로젝트에서 내가 기술적으로 집중한 부분이 있다면 그것을 포트폴리오에 잘 담아보는 것이 중요합니다

만약 스레드 동기화에 대한 자신이 있다면 카카오톡을 구현하면서 대규모 사용자들이 동시에 메시지를 보낼 때 문제가 생기지 않도록 처리하는 방법을 시험해볼 수 있습니다 천 명 이상의 사용자가 동시에 메시지를 보낼 때 발생하는 문제를 시뮬레이션하고 그 문제를 어떻게 해결했는지 과정을 기록하는 것도 훌륭한 포트폴리오 자료가 될 것입니다

포트폴리오에서는 문제가 생겼을 때 해결하는 과정이 들어있어야합니다 개발자는 당연히 해결해야 할 문제를 당연히 해결하는 사람이기 때문에 포트폴리오는 문제 해결 과정을 보여줄 수 있어야 합니다 예를 들어 대규모 메시지 전송 문제를 일부러 발생시키고 그 문제를 어떻게 분석하고 해결했는지 구체적으로 기록해야 합니다

포트폴리오를 만들 때 유의할 점은 지나치게 참신한 프로젝트를 만들려고 해선 안된다는 점 입니다 전에 없던 방식의 프로젝트는 서비스 기획 방향에서 평가할 내용이지 개발자로서 평가할 내용은 아닙니다 신기한 프로젝트를 만들려 하지 말고 당연하면서도 어려운 프로젝트를 만들려고 해야합니다

공동 프로젝트는 웬만하면 피하는 것이 좋습니다 대학생의 공동 프로젝트는 한두 명이 대부분의 작업을 맡고 나머지 팀원들은 발표나 문서 정리에만 관여하는 경우가 많습니다 이때까지 학부생 여럿이서 만든 프로젝트가 제대로 굴러간걸 본적이 없습니다 제대로 참여하지 않은 프로젝트를 높은 기여도로 참여했다고 속여서는 안됩니다 혹은 참여도가 낮은 점을 일부러 감추려고 해서도 안됩니다 면접관은 공동 프로젝트에서 각 팀원이 프로젝트에 기여한 비중을 철저히 검증하게 됩니다 이 검증과정에서 경험 많은 개발자의 눈을 속일 수는 없습니다 공동 프로젝트에서 참여 비중을 속인 경우 면접에서 절대 통과할 수 없습니다

가장 좋은 방식은 혼자 프로젝트를 완성하는 것입니다 처음에는 여러 명이 함께 시작했으나 나머지 사람들이 중간에 그만두고 혼자 남아 프로젝트를 끝냈다면 그 과정은 자신의 실력뿐만 아니라 책임감과 근성까지 증명할 수 있는 훌륭한 경험이 됩니다

위 설명대로 만든 핵심 프로젝트 두세가지와 나머지 작은 프로젝트를 잘 정리하여 깃헙에 올려두면 됩니다 그리고 내가 무엇을 만들었는지 무엇에 집중했는지 이 프로젝트를 하면서 어떤 고생을 했는지 github Readme 나 Notion등에 정리하면 됩니다

사실 2차 면접은 1차 면접처럼 실력을 평가하는 자리가 아닙니다 2차 면접은 1차 면접에서 본 평가가 정확한지 확인하는 절차라고 볼 수 있습니다 1차 면접관이 지원자를 통과시킨 이유가 타당한지를 2차 면접관이 검증하는 것입니다

2차 면접에서 가장 중요한 것은 1차 면접에서 했던 답변을 기억하고 일관되게 대답하는 것입니다 1차 면접과 2차 면접 사이에 시간이 오래 지나면 1차 면접에서 무슨 답변을 했는지 기억이 나지 않을 수 있습니다 그렇기 때문에 2차 면접을 준비할 때는 1차 면접에서 했던 답변을 다시 한번 숙지하고 예상 질문에 대해 준비하는 것이 중요합니다

또한 1차 면접에서 답하지 못한 질문이 있다면 그 부분을 보완하여 2차 면접에서 다시 묻는 경우에 대비해야 합니다 이때는 그 질문에 대한 답변을 준비해 두는 것이 당락에 큰 영향을 미칠 수 있습니다

2차 면접에서는 지원자가 회사에 적합한 사람인지를 판단하는 것이 핵심입니다 이는 단순히 기술적인 실력만을 평가하는 것이 아니라 이 지원자에게 얼마나 비용을 들여도 되는지를 고려하는 자리입니다 예를 들어 지원자가 우리 회사에서 몇 년 차로 일할 수 있을지 혹은 다른 지원자와 비교했을 때 어느 정도의 가치를 가지는지를 평가하게 됩니다

정리하자면 1차 면접은 개발자로서의 실력을 평가하는 자리이고 2차 면접은 지원자의 실력과 회사의 상황을 종합적으로 고려하여 채용 여부를 결정하는 자리입니다 따라서 1차 면접을 통과했다면 어느 정도 실력이 검증된 것이고 2차 면접에서는 운이 작용할 가능성도 있습니다

만약 1차 면접에서 통과하지 못했다면 실력이 부족한 부분을 보완할 필요가 있지만 2차 면접에서 탈락했다면 운이 좋지 않았다고 생각하고 더 많은 도전을 해보는 것이 좋습니다

반면 첫 번째 질문에는 답변을 잘했지만 이어지는 질문에 답하지 못했다면 면접은 쉽게 진행된 것처럼 느껴질 수 있습니다 면접 질문 자체에는 대답을 했고 계속 쉬운 질문만 받았기 때문에 면접을 잘 봤다고 생각하게 됩니다 그러나 면접이 이렇게 진행되면 면접관은 면접자가 깊이 있는 지식을 갖고 있지 않다고 판단하게 됩니다 이런 경우에는 면접이 잘 진행된 것처럼 느껴지지만 실제로는 면접에서 좋은 평가를 받지 못합니다

면접을 정말 잘 본 경우 내가 많이 부족하다는 느낌이 들 수 있습니다 질문에 답을 하지 못해 고생한 시간들을 떠올리며 "내가 이 정도밖에 안되나?"라고 생각하게 될 수 있습니다 하지만 이때야 말로 면접을 제대로 본 것이며 면접이 끝났을 때 피로감이 크게 느껴질 수 있습니다

반대로 면접에서 제대로 대답하지 못할 경우 면접관은 더 이상 어려운 질문을 하지 않으며 남은 시간 동안 적당히 쉬운 질문을 던집니다 그래서 면접이 편안하게 끝나고 잘봤다고 생각지만 나중에 탈락한 결과를 보고 당황하게 됩니다

인터넷에서 면접 후기를 보면 다 자신의 느낌을 기반으로 후기가 적혀있습니다 그러고선 자기가 왜 떨어졌는지 왜 붙었는지 모르겠다는 이야기가 많습니다

면접이 끝났을 때 힘들고 지친 느낌이 든다고 해서 면접을 잘못 봤다고 생각할 필요는 없습니다 오히려 이런 기분이 들 때가 면접을 잘 본 증거일 수 있습니다

이러한 질문은 사실 합격과 불합격을 가르는 중요한 요소가 아닙니다 면접관은 이 질문을 통해 극단적인 대답을 하는 지원자를 걸러내고자 합니다 예를 들어 "무슨 일이든지 열심히 하겠다"거나 "부당한 지시를 받으면 회사를 그만두겠다"와 같은 극단적인 대답은 피해야 합니다 적당한 대답은 "부당한 지시라면 그 이유를 설명하고 상사를 설득해 보겠다" 정도로 충분합니다

결국 기본적인 상식을 바탕으로 진솔하게 대답하면 큰 문제는 없습니다 중요한 것은 지원자가 지나치게 과장하거나 극단적인 태도를 보이지 않는 것입니다

많은 면접 후기를 보면 지원자들은 CS 기술 면접에서 실수한 것보다 이러한 일상적인 질문에 제대로 대답하지 못한 것을 후회하는 경우가 많습니다 그러나 개발자 면접에서 가장 중요한 것은 기술적 실력입니다 개발자는 실력이 곧 태도이기 때문입니다

따라서 면접에서 태도와 관련된 질문을 받았을 때는 평소의 경험을 바탕으로 상식적이고 논리적인 대답을 준비하면 됩니다

첫째, 내가 개발에 얼마나 열정적이고 열심히 공부해왔으며 어떤 역량을 가지고 있는지를 보여주는 것입니다 개발 분야에서 내가 어떤 부분에 집중했고 무엇에 관심을 두었으며 어떤 기술들을 공부했는지 구체적으로 적는 것이 중요합니다 이를 통해 내가 개발자로서 얼마나 준비되어 있는지 스스로의 학습과 경험을 어떻게 쌓아왔는지를 드러내야 합니다

둘째, 자기소개서는 포트폴리오를 읽고 싶도록 만들어져야 합니다 자기소개서는 단순히 나를 소개하는 문서가 아니라 포트폴리오를 평가받기 위한 안내서 역할을 해야 합니다 내가 어떤 프로젝트를 진행했으며 이를 통해 어떤 성과를 얻었는지 그 과정에서 얼마나 열의를 다했는지를 적절히 담아야 합니다

회사의 선임 개발자가 당신의 자기소개서와 포트폴리오를 검토할 것입니다 이들은 회사에서 가장 바쁜 사람들입니다 내가 제출한 자기소개서와 포트폴리오를 성실하게 읽어줄거로 생각하지 마십시오 내 자기소개서와 포트폴리오를 끝까지 진지한 자세로 읽고 싶도록 해야합니다 시간을 들여 당신의 결과물을 제대로 평가하려면 자기소개서에 포트폴리오의 핵심 내용이 잘 녹아 있어야 합니다 자기소개서는 포트폴리오를 효과적으로 홍보하는 광고지와 같은 역할을 해야 합니다

가장 중요한 것은 자기소개서를 읽는 사람이 자연스럽게 질문을 떠올릴 수 있도록 하는 것입니다 "이 사람은 어떤 기술을 열심히 배웠구나" "이 프로젝트에서 어떤 부분을 주도했을까?" "이 문제를 해결하기 위해 어떤 접근을 했을까?" 등의 질문이 떠오를 수 있도록 구체적으로 작성해야 합니다 면접관이 자기소개서를 보고 당신의 경험과 열정을 기반으로 질문할 수 있어야 합니다 그 질문을 바탕으로 자신의 열정과 기술력을 더 깊이 있게 설명할 수 있다면 그 자기소개서는 성공적인 자기소개서라고 할 수 있습니다

글이 잘 써있을 필요는 없습니다 개발자는 글쓰는 사람들이 아니므로 수준높은 필력을 요구하지 않습니다 단지 자기가 어떤 고생을 해서 공부하고 포트폴리오를 만들었는지 쓰여있어야합니다 대부분 고생해서 공부하고 포트폴리오를 준비한 사람들은 이런 내용이 자기소개서에 자연스럽게 녹아들어있었습니다

따라서 자기소개서는 나의 기술적 능력과 열정을 자연스럽게 드러내는 문서로 만들어야 합니다 이를 통해 면접관이 당신에게 더 많은 질문을 하고 당신의 역량을 더 깊이 있게 파악할 수 있도록 유도하는 것이 중요합니다

종종 개발을 잘하던 사람이 좋다는 기업에 들어갔다가 정작 기업 문화에 적응하지 못해 다시 취업 준비를 하는 경우를 볼 수 있습니다 특히 금융권에 입사한 사람들이 이런 현상을 보입니다 어지간한 실력이 없으면 금융권에 입사할 수 없지만 금융권에서 자기가 원하는 개발 을 할 수 없기 때문에 뒤늦게 아직을 고민하곤 합니다 반대로 학생 때 개발에 열정을 쏟았던 사람이 개발 회사에 입사한 후 실제 업무가 적성에 맞지 않아 힘들어하는 경우도 있습니다 그냥 좋은 회사에 다니고 싶을 뿐인데 하루 종일 코드를 보고 설계이야기를 하는 환경에 질려하는 사람들도 있습니다 개발이 목적인지 아니면 좋은 회사에 취업하는 것이 목적인지 스스로에게 묻고 이에 대한 답을 먼저 찾아야 합니다

그 다음으로 중요한 것은 연봉입니다 우리나라는 자본주의 사회이고 실력이 좋은 사람에게 더 많은 보상을 주는 것이 일반적입니다 연봉이 높은 회사일수록 좋은 인재들이 모이는 경향이 있으며 그만큼 실력 있는 동료들과 함께 일할 수 있는 기회도 많아집니다 더 많은 것을 배울 수 있는 환경이 만들어지는 것입니다

물론 워라밸(Work-Life Balance) 개발 스타일 업무 환경 등도 중요한 고려 요소일 수 있습니다 하지만 아직 일도 시작하기 전에 어떤 스타일이 나에게 맞는지 알 수 없습니다 자기가 무엇을 좋아하는지는 실제로 일을 해보기 전까지는 알 수 없습니다

따라서 연봉을 기준으로 선택하는 것이 현명한 방법입니다 좋은 개발자들이 있을만한 환경으로 들어가는 것이 우선입니다 많은 것을 배울 수 있는 환경에 들어가서 이후에 자신에게 맞는 개발 환경을 찾으면 됩니다

그렇다면 왜 개발자들은 학벌을 중요하게 생각하지 않을까요? 그 이유는 개발자의 실력을 평가할 수 있는 수단이 충분히 많기 때문입니다 먼저 코딩 테스트를 통과하는 기본적인 능력이 중요합니다 또한 면접을 통해 면접자의 실력을 평가하는 것이 다른 직종에 비해 비교적 수월합니다 더 나아가 면접자가 제출한 포트폴리오나 과제를 통해 실력을 검증할 수 있는 방법도 있습니다 이러한 이유로 개발자가 되고자 하는 사람은 학벌이나 전공에 상관없이 개발 실력을 쌓아나가면 충분히 도전할 수 있습니다

그렇다고 해서 학벌이 전혀 필요 없다는 것은 아닙니다 좋은 환경에서 뛰어난 사람들과 함께 경쟁하고 성장한 경험은 분명 가치가 있습니다 실제로 학벌이 좋은 학교의 학생들은 취업 상담을 받을 때 자신이 하고 있는 것이 무엇인지 더 명확하게 알고 어떤 방향으로 나아가야 할지 구체적으로 묻는 경우가 많습니다 반면 학벌이 좋지 않은 학교에서는 학생들이 아무런 준비 없이 "무엇을 해야 할까요?"라고 묻곤 합니다 어떤 환경에서 공부하는 것이 자기 발전에 유리한지는 더 설명하지 않아도 알 수 있을 것입니다

결국 개발자로서 중요한 것은 학벌이 아니라 자신의 실력과 노력을 얼마나 쌓아가느냐입니다

개발자의 역량은 예상치 못한 문제를 해결하는 데 있습니다 예를 들어 사용자가 급격히 늘어날 때 발생하는 성능 저하 문제를 해결하거나 데이터의 양이 급증했을 때 이를 효율적으로 처리하는 기술적 해결책을 제시할 수 있어야 합니다 화면이 복잡해지면서 생기는 속도 저하를 개선하는 것 역시 개발자의 중요한 역할입니다 이러한 문제 해결 능력은 공모전에서 수상하는 것과는 큰 연관이 없습니다 공모전은 시연하고 끝나기 때문에 완벽하게 돌아가는 프로그램이 아니라 돌아가는 거 같은 정도까지만 만들어도 문제가 없습니다

또한 많은 경우 공모전에서는 아이디어만 제시하고 외주 개발에 맡기는 것이 더 효율적일 수 있습니다 아이디어를 가진 사람이 직접 개발하지 않고 외주 개발을 통해 결과물을 만들어내는 것이 공모전에서 더 좋은 성과를 내는 방법이 될 수 있다는 것입니다 이렇듯 공모전은 오히려 개발보다는 기획이나 디자인 측면에서 접근하는 것이 더 유리한 경우가 많습니다

공모전에서는 여러 사람이 팀을 이루어 프로젝트를 진행하는 경우가 많습니다 하지만 현실에서 다수의 사람이 참여한 프로젝트가 성공적으로 완성되는 경우는 많지 않습니다 큰 프로젝트에서는 작업을 적절히 분배하는 것이 중요한데 이를 잘 해내기 위해서는 경험과 능력이 필요합니다 그러나 공모전에서는 팀원 간의 역할 분담이 미숙한 경우가 많고 그로 인해 소수의 핵심 인원이 대부분의 작업을 수행하는 경우가 흔합니다 이러한 이유로 단순히 공모전에 참여한 이력은 개발자 면접에서 큰 가치를 인정받기 어렵습니다

개발자로서 역량을 증명하고 싶다면 공모전에 참여하기보다는 스스로 원하는 프로젝트를 만들어보는 것이 훨씬 효과적입니다 자신이 만든 프로젝트에서 기술적 도전 과제를 해결하고 이를 통해 얻은 경험을 포트폴리오에 담는 것이 더 나은 방법입니다 혼자서 프로젝트를 진행하면서 기술적으로 깊이 있는 접근을 시도하고 그 결과를 잘 정리하여 포트폴리오에 담는 것이 개발자로서 자신의 실력을 증명하는 데 가장 좋은 방법입니다

국비 지원 교육 제도는 개발 업계에 큰 도움이 되지 않는다고 생각합니다 이 제도를 통해 혜택을 받는 이들은 대부분 실력 없는 강사들입니다 국비 지원 교육 학원에서는 대부분의 강사가 그저 자리를 유지할 수 있을 정도의 실력을 갖추고 있을 뿐입니다 반면, 실력 있는 강사들은 그들의 가치를 인정받지 못하고 동일한 보상을 받기 때문에 이 제도에서 손해를 봅니다 이러한 환경에서는 강사들이 더 잘 가르치려는 노력을 하지 않게 됩니다

이러한 문제는 학생들에게도 영향을 미칩니다 학생들은 보다 질 높은 교육을 받을 기회를 박탈당하고 있으며 이는 결국 IT 산업 전반에도 악영향을 미칩니다 우리는 개발을 잘하는 사람뿐만 아니라 개발을 잘 가르치는 사람도 필요합니다 하지만 국비 지원 교육 제도가 지속되는 한 우수한 강사가 등장하기는 매우 어렵습니다

현재 우수한 강사로서 인정받는 분들은 주로 회사나 정부기관에서 강의를 하거나 온라인에서 강의를 판매하고 있습니다 이런 분들의 이론적인 강의는 매우 훌륭합니다 하지만 코딩은 이론뿐만 아니라 실전 감각이 중요합니다 그래서 옆에서 왜 문제가 발생했고 어떻게 해결해야 하는지 설명해줄 수 있는 사람의 역할이 매우 중요합니다 국비 지원 교육 제도는 이러한 역할을 제대로 수행하지 못하게 하고 있는 상황입니다

그렇기에 저는 누군가에게 개발을 배우고 싶다면 국비 지원 교육을 먼저 추천하지만 그 교육을 통해 개발을 배웠다고 하면 신뢰하지는 않습니다

일반적인 개발자 인턴십은 회사 직원 입장에도 부담이 될 수 있습니다 바빠 죽겠는 상황에서 인턴이 할만한 일을 만드는것도 쉬운게 아니기 때문입니다 개발자 인턴은 회사나 인턴 자신에게 모두 큰 도움이 되지 않는 경우가 많습니다

이런 상황은 채용 면접관들도 잘 알고있습니다 그래서 다른 회사 인턴 경험이 있다고 해서 딱히 어드벤티지를 주지는 않습니다

하지만 취업 연계형 인턴십은 다릅니다 취업 연계형 인턴십은 실제로 회사에서 인력을 채용하기 위한 과정의 일부이기 때문에 교육과 실무 경험을 제공받을 수 있습니다 이러한 인턴십은 개발자로서 성장할 수 있는 좋은 기회이므로 가능하다면 꼭 참여하는 것이 좋습니다

인턴이 아니더라도 이와 비슷한 채용 연계 프로그램들이 있습니다 예를 들어 삼성의 소프트웨어 멤버십이나 배달의 민족의 우아한 테크코스 같은 프로그램은 매우 우수한 개발자 양성 프로그램입니다 이와 같은 프로그램에 참여한 사람들은 대체로 실력이 뛰어난 경우가 많습니다 만약 이러한 프로그램에 참여할 기회가 주어진다면 반드시 참여하길 권장합니다 많은 것을 배울 수 있을 뿐만 아니라 취업 시에도 큰 이점을 제공할 것입니다

결론적으로, 일반적인 인턴십은 실무 경험을 얻기에는 제한적일 수 있지만 취업 연계형 인턴십이나 개발자 양성 프로그램에 참여하는 것은 큰 도움이 될 것입니다

단순히 새로운 기술을 공부하는 것만으로는 충분하지 않습니다 공부한 내용을 실무에 적용하기 위해 동료들을 설득하는 과정도 중요합니다 운영 중인 프로젝트에 새로운 기술을 도입하는 것은 위험이 따르기 마련입니다 안전하게 적용할 수 있도록 철저히 준비하고 설득하는 과정이 필요합니다 이 과정은 단순한 기술 습득을 넘어 커뮤니케이션 능력을 키울 수 있는 기회이기도 합니다

새로운 기술을 공부하고, 그 기술을 내 프로젝트에 적용하며, 이를 성공적으로 동료들에게 설득하는 경험은 포트폴리오에 진취적인 개발자로서의 증명을 남길 수 있는 좋은 기회입니다 기술을 적용하는 것만큼이나 동료들과 공유하고 협업하는 과정에서 얻게 되는 학습도 매우 중요합니다

따라서, 현직 개발자는 단순한 학습에서 그치지 않고, 자신이 학습한 내용을 실무에 적용하고, 그 과정에서 발생하는 다양한 문제를 해결하며 실력을 키우는 것이 가장 효과적인 공부 방법입니다

저는 두 번에 걸친 개발자 채용 시장의 변화를 경험했습니다 첫 번째는 IT 버블이 있었던 시기였고, 두 번째는 쿠팡과 같은 기업들이 주도했던 개발자 채용 전쟁이 있던 때였습니다 이 두 번의 파고가 올 때마다 개발자에 대한 수요는 폭발적으로 증가했고, 기존 개발자들의 몸값은 크게 올랐습니다 개발자가 부족하다는 이야기가 매일같이 나왔었습니다 IT 버블때는 국비지원 교육으로 IT 개발자를 양성했고 최근 개발자 붐에는 개발자 부트캠프가 여럿 등장했습니다 하지만 이 파고가 지나간 후에는 개발자에 대한 수요가 급격히 줄어들었습니다 수요는 줄고 그동안 양성된 신규 개발자들은 낮은 대우를 받게 됩니다

IT 버블 이후, SI 개발자에 대한 처우는 크게 나빠졌습니다 과도한 근무 환경으로 인해 폐를 절단한 개발자가 뉴스에 보도되기도 했습니다 이 현상은 결국 수요와 공급의 법칙에 따라 이루어진 것입니다 우리나라에서는 특정 분야에 인력이 부족하다고 하면 그 인력을 과잉 생산하는 경향이 있습니다 특히 개발자는 어느 정도의 기초적인 역량만 있으면 빠르게 양산할 수 있는 직군입니다 여기에 정부 차원에서 제공한 무료 개발 강의들이 더해져 저렴한 인력들이 대거 시장에 공급되었습니다 그 결과 저가의 개발 인력들은 매우 낮은 대우를 받을 수밖에 없었습니다

지금도 비슷한 상황입니다 새로운 개발 인력들이 급격히 늘어나면서 취업 자체가 힘들어진 상태입니다 솔직히 말해 지금 개발자로 취업을 준비하는 사람들에게는 신중히 생각하라고 말하고 싶습니다 하지만 이미 개발자로서 일을 하고 있는 사람이라면 굳이 그만둘 필요는 없다고 생각합니다 이미 자리를 잡은 개발자라면 꾸준히 노력해서 검증된 실력을 가지면 그만큼 좋은 대우를 받을 수 있습니다 꾸준히 노력해서 때를 기다리다가 다시 IT 붐이 일게되면 큰 이득을 얻을 수 있을겁니다

실력 있는 개발자에 대한 수요는 여전히 존재합니다 역사적으로 보아도 뛰어난 실력을 가진 개발자는 언제나 좋은 대우를 받게 됩니다 지금이 일시적인 한파일 뿐 꾸준히 실력을 쌓아간다면 미래에는 다시 기회가 찾아올 것입니다

두 번째로 중요한 것은 CS(Computer Science) 면접 준비입니다 구글에서 개발자 면접 질문을 검색하면 좋은 자료들을 찾을 수 있습니다 답변을 무조건 외우는 것이 아니라 질문에 대한 답을 제대로 이해하기 위해 꼼꼼히 공부하는 것이 중요합니다 예상 질문에 대한 답변을 검색해서 검색 첫페이지에 나오는걸 전부 눌러서 봅니다 그렇게 눌러서 본 페이지 안에 모르는 내용이 있으면 또다시 검색해서 찾아봅니다 페이지에서 하는 설명이 잘 이해가 안되면 페이지 내용 자체를 긁어다가 chatGPT에 붙여넣고 추가 설명을 해달라고 하면 이해하는데 도움이 될겁니다 이렇게 계속해서 더이상 필요한 검색 내용이 나오지 않을 때 까지 반복하여 꼬리에 꼬리를 무는 공부를 해야합니다 면접에서 면접관이 질문을 하고 이에 대한 답변을 하면 답변에 이어지는 질문을 계속 합니다 면접관은 이런식으로 질문해서 더이상 답변을 못할 때 까지 질문을 이어가게 됩니다 10개의 질문에 대해 전부 대답하더라도 한번도 이어지는 질문에 대답을 못하면 통과하기 어렵습니다 반대로 10개의 질문에 대부분 대답하지 못해도 두세가지 질문에 대해 이어지는 질문 답변을 이어갈 수 있다면 좋은 평가를 받을 수 있습니다 최고의 답변은 하나의 질문으로 면접시간을 전부 사용하는 겁니다

마지막으로, 개인 프로젝트를 준비하는 것도 중요합니다 내가 만들고자 하는 프로그램을 실제로 작성해보고, 그 프로그램이 서비스로 제공될 때 발생할 수 있는 문제를 가정해보는 것이 필요합니다 예를 들어, 만든 게임에 갑자기 많은 사용자가 접속했을 때 어떤 문제가 발생할지를 미리 생각해보고 테스트하는 과정을 거쳐야 합니다 이러한 문제를 스스로 진단하고 해결하는 능력을 기르는 것이 중요합니다

이러한 준비 과정은 지금까지 크게 변하지 않았으며, 앞으로도 마찬가지일 것입니다 다만 ChatGPT와 같은 도구를 활용하면 이 모든 준비 과정을 더 쉽게 해낼 수 있습니다 예를 들어 CS 면접을 준비할 때 이해가 되지 않는 부분을 ChatGPT에게 물어보며 도움을 받을 수 있습니다 또한 이전에는 혼자서 만들기 어려웠던 서비스를 ChatGPT의 도움을 받아 제작하고 문제를 해결할 수도 있습니다

한 가지 조언을 더하자면 프로젝트에서 나온 내용이 CS 면접 질문과 자연스럽게 연결되도록 준비하는 것이 좋습니다 내가 만든 프로젝트에서 어떤 부분에 집중했고 그 과정을 통해 어떤 기술을 익혔는지 설명할 수 있도록 준비한다면 면접에서 더 좋은 결과를 얻을 수 있을 것입니다 또한 면접에서 내가 준비한 내용을 제대로 설명할 수 있도록 프로젝트 포트폴리오를 잘 정리해두는 것이 필요합니다

신입 개발자에게 요구되는 사항들은 오랜 시간이 지나도 크게 변하지 않았습니다 10여년 동안 채용시장에서 있으면서 면접자도 되고 면접관도 되어봤습니다 그 동안 개발자에게 필요한 능력은 거의 비슷했습니다 다만 시장의 수요나 교육 환경에 따라 실력이 부족한 사람을 뽑기도 하고 반대로 뛰어난 실력자들만 선발하는 경우도 있습니다 하지만 근본적으로 신입 개발자가 준비해야 할 것들은 변하지 않았으며 앞으로도 크게 달라지지 않을 것이라고 생각합니다

현재의 트랜스포머 기반 인공지능 모델은 결국 앞서 주어진 문장을 바탕으로 그 다음에 나올 말을 예측하는 방식입니다 이 모델은 인터넷에 존재하는 방대한 양의 글을 학습하여 다음에 나올 말을 예측합니다 이런 말이 적혀있으면 뒤에 이런 말이 이어지는게 자연스러울거라고 계산한 단어들을 적어나갑니다 이런 방식은 인간의 직관적인 생각과 행동은 충분히 대처할 수 있습니다 하지만 복합적인 사고를 대신하지는 않습니다

최근 나온 chatGPT o1 모델은 사람에 가까운 지능을 가지고 있다고 평가합니다 이렇게 높은 지능을 가지게 된 이유는 기존 gpt 모델을 여러번 돌리는 것입니다 이는 마치 자신이 말하는 내용이 맞는지 스스로 검토하는 것과 비슷합니다 이러한 검수 과정이 인간의 논리적 사고처럼 완전한 것은 아닙니다

개인적으로 o1 모델을 테스트해보았습니다 아직은 현재 수준의 인공지능이 인간의 지성을 뛰어넘는 수준에 도달했다고 생각하지는 않습니다 인공 지능은 여전히 틀린 참조나 잘못된 확신을 완전히 피하지 못합니다 이는 인공지능의 한계 중 하나입니다 따라서 지적인 대화를 나누는 것처럼 보이지만 실제로는 진정한 지적 능력과는 거리가 있다는 생각합니다

현재의 인공지능은 인간과 유사한 지적 대화를 나눌 수 있는 듯하지만, 그 속에는 본질적인 차이가 존재합니다 AI가 인간을 완전히 대체할 수 있는 날은 더 기다려야한다고 봅니다

첫째, 취업 시장에는 이미 개발자가 너무 많습니다 개발자가 전공에 상관없이 돈을 많이 번다는 소문이 퍼지면서, 작년과 재작년에 많은 사람들이 개발자 채용시장에 진출했습니다 하지만 최근 금리가 오르면서 수많은 벤처기업이 문을 닫았게 되었습니다 사람을 더 뽑지 않는 수준이 아니라 원래 회사다니던 개발자까지 구직 시장에 나오게 되었습니다

개발자가 부족하다고 해서 많이 양산되다가 또 개발자가 남아서 몸값이 줄어드는 이런 현상은 약 10년 주기로 반복됩니다 이전에도 개발자가 부족하다고 해서 국비지원 교육이 나오고 또 개발자가 부족해서 코딩 부트 캠프가 나왔습니다 개발자가 부족하다고 해서 몸값이 오르고, 또 몸값이 오르니까 많은 개발자가 양산되고, 양산된 개발자 때문에 몸값이 줄어드는 상황이 반복되고 있습니다 금리가 내려가고 벤처기업이 다시 활발히 생겨야 개발자 취업이 수월해질 것입니다 아마 다시 개발자가 좋은 대우를 받으려면 몇년은 더 있어야 할 것입니다

둘째, ChatGPT와 같은 도구의 등장으로 신입 개발자가 대체되고 있습니다 기업들은 이제 신입 개발자를 뽑기보다는 ChatGPT를 더 효과적으로 활용하는 방향으로 가고 있습니다 신입 개발자로 대체되지 않으려면, ChatGPT를 이용해 효율을 높일 수 있는 수준의 개발자가 되어야 합니다 어느 정도 실력을 갖춘 개발자라야 괜찮은 기업에서 들어가서 좋은 조건으로 일할 수 있습니다

물론, 소프트웨어 전공자라면 개발자가 되기 위해 열심히 공부하는 것이 맞습니다 하지만 다른 전공자가 개발자가 되기 위해 공부하는 것은 신중히 고민해야 할 부분입니다

그렇다고 비전공자가 하는 개발 공부가 도움이 되지 않는 것은 아닙니다 개발을 교양으로 공부해두면 다른 업무에 매우 잘 활용할 수 있습니다 실제로 다른 분야에서 인재를 채용할 때 Python이나 chatGPT 활용 능력이 강점이 되기도 합니다

자신이 하고자 하는 바가 명확하다면, 이제는 AI가 프로그래밍을 도와주기 때문에 약간의 공부만으로도 원하는 바를 쉽게 구현할 수 있을 것입니다

개발자는 단순히 코드를 작성하는 사람이 아닙니다 개발자는 문제를 해결하고, 요구 사항을 분석하며, 전체 시스템의 프로세스를 설계하는 역할을 합니다 코딩은 이러한 과정의 일부에 불과합니다 AI가 반복적인 작업을 자동화해준다고 해서 개발자의 가치를 대체할 수는 없습니다 오히려 프로세스 설계 능력이 점점 더 중요한 시대가 되어가고 있습니다

단순히 코딩만을 하는 개발자는 AI의 도움으로 인해 역할이 축소될 수 있습니다 그러나 복잡한 시스템 설계와 창의적인 문제 해결 능력을 갖춘 개발자에 대한 수요는 더 높아질 것입니다 과거에도 개발자의 생산성을 높이는 기술들이 등장했지만 그로 인해 개발자의 수요가 줄어든 적은 없습니다 예를 들어... 기존에는 프로젝트를 세팅하고 웹서버를 띄우는게 매우 번거롭고 어려운 일이었습니다 이를 도와주는 스프링 프레임워크나 AWS와 같은 서비스들이 나와서 개발자들이 더 쉽게 작업할 수 있게 되었습니다 스프링이나 AWS가 나와서 개발자 수요가 줄었을까요? 오히려 원하는 프로그램을 더 저렴하게 만들 수 있어서 개발자 수요가 폭증했습니다

또한, ChatGPT와 같은 AI 도구는 신입 개발자들에게도 기회를 제공합니다 과거에는 혼자서 서비스를 개발하는 것이 매우 어려웠으나, 이제는 AI의 도움을 받아 스스로 프로젝트를 진행하고 실력을 쌓을 수 있습니다 이를 통해 중급 이상의 개발자로 성장하는 시간도 크게 단축될 수 있습니다

결국 AI 때문에 개발자의 필요성은 사라지지 않을 것입니다 개발자의 역할이 재정의될 수는 있습니다 단순한 코드 작성자가 아니라 시스템 설계와 창의적인 문제 해결 능력을 갖춘 전문가가 되어야할 것입니다

첫째. 평소에 시스템이 정상적으로 작동하는 상태를 기록하는 시스템을 만들어야합니다 예를 들어 평소 접속자는 몇 명인지, 메모리나 CPU 사용량은 어느 정도인지 등을 기록하고 조회하는 시스템이 필요합니다 가능하면 많은 데이터들이 누적되는게 좋습니다 이런 시스템이 있으면 문제가 발생했을 때 즉각적으로 알 수 있게 됩니다

이와 같은 데이터를 기록해두면 문제가 발생했을 때뿐만 아니라 상위 관리자가 "이게 정상적인 상태가 맞는가?"라고 물었을 때도 정확히 답할 수 있습니다 만약 사전에 준비된 데이터가 없다면 정상 여부를 판단하는 데 오랜 시간이 걸릴 수 있으며, 결과적으로는 관리자의 신뢰를 얻기 어렵게 될 것입니다

시스템 부하가 없다면 실시간으로 감지하고 기록하는 프로세스도 좋고 사후 분석을 위한 데이터를 누적하여 하둡등으로 분석하는 것도 좋습니다

둘째. 프로젝트의 상태를 간단하게라도 조회할 수 있는 통계를 제공하는 것도 필수적입니다 상위 관리자는 언제든지 프로젝트의 상태를 확인할 수 있어야 하며, 개발자 자신도 더 깊이 있는 정보를 실시간으로 모니터링할 수 있어야 합니다 이를 위해 배치 작업이나 모니터링 시스템을 상시 가동하는 것이 좋습니다

중요한 기능이 배포될 때는 평소 상태에 대한 더 정교하게 파악해두어야 합니다 새로운 기능이 추가되면 이전에 없던 테스트를 진행하면서 원래는 발견되지 않았던 버그가 드러나는 경우가 많습니다 이때 중요한 것은, 이 버그가 원래 있던 것인지, 아니면 새롭게 추가된 기능으로 인해 생긴 것인지 명확히 구분하는 것입니다 평소의 상태에 대한 명확한 데이터가 없다면 이러한 판단이 어려워지고 문제 해결에 큰 차질을 빚을 수 있습니다

프로젝트가 안정적으로 운영되기 위해서는 평소의 상태를 명확히 기록하고 관리자가 신뢰할 수 있는 데이터를 제공하는 것이 중요합니다 이러한 사전 준비가 있다면, 문제가 발생하더라도 신속하게 대응할 수 있으며 더 큰 문제를 예방할 수 있을 것입니다

첫 번째로 해야할 일은 프로젝트를 글로 잘 정리하는 것입니다 무엇을 만드는건지 상세하게 잘 정리해야 어떻게 만들어야하는지 확실하게 파악할 수 있습니다 그냥 글로 적는것도 괜찮고 UML을 그리는것도 좋습니다 UML을 이용하여 객체간 관계를 잘 정리할 수 있다면 아무리 큰 프로젝트도 어렵지않게 작업할 수 있습니다 하지만 무엇보다 중요한 것은 UML을 그리느냐 그리지 않느냐가 아닙니다 프로젝트의 주요 기능을 명확하게 정리할 수 있다면 어떤 수단을 사용해도 괜찮습니다

두 번째로 중요한 것은, 큰 프로젝트를 여러 작은 단위로 쪼개는 것입니다 프로젝트가 커질수록 관리의 복잡도는 기하급수적으로 증가합니다 이때 중요한 점은 가능한 독립적인 모듈로 분리하는 것입니다 독립된 모듈로 묶어서 추상화를 하게 되면 복잡도가 대폭 줄어듭니다 저는 개인적으로 API 형태로 분리하는 것을 추천합니다

API로 만들면 해당 모듈을 다른 프로젝트에서 가져다 쓰기 좋습니다 아무리 객체지향적으로 잘 만든 객체라도 재사용하는건 쉽지 않습니다 내가 만든 객체를 내 다른 프로젝트 혹은 다른 사람이 사용하는건 대단히 어렵습니다 하지만 API는 규약만 알면 누구나 가져가서 쓸 수 있기 때문에 재사용이 용이합니다

API로 만들기로 했다면 API 프로젝트 안에서는 강박적으로 객체지향을 고집하지 않아도 됩니다 필요한 기능을 만들다 보면 각 객체간의 추상성을 해치는 작업을 어쩔 수 없이 하게 됩니다 추가할 기능이 A객체에 만들어야하는지 B객체에 만들어야하는지 애매한 경우가 있습니다 A,B 어떤 객체안에 만들어도 각 객체간의 역할을 넘어서기도 하고 그렇다고 C객체를 따로 만들자니 시간도 오래걸리고 객체가 늘어날 수록 프로젝트 복잡도가 증가하여 관리 비용이 상승합니다 이럴때는 걍 A,B 객체 중 아무 객체에서 필요한 기능을 구현합니다 어차피 많이 쓰는 API라면 나중에 리뉴얼을 하게 됩니다 나중에 시간이 가서 API 리뉴얼이 필요하면 그때 잘 설계해서 수정하는게 효율적입니다 말단 설계에 까지 객체지향을 고집하는건 어렵다고 생각합니다

모든 기능을 너무 자잘하게 API로 나누는 것은 비효율적일 수 있습니다 API로 분리할 때는 프로젝트의 스펙을 글로 정리해보고 한 문단으로 끊어지는 단위가 적당한 기준이 될 수 있습니다 중요한 것은 적절한 분리와 관리를 통해 프로젝트가 지나치게 복잡해지는 것을 막는 것입니다

결국 프로그램은 데이터의 흐름을 다루는 작업이고 이 흐름을 언어로 명확히 표현할 수 없다면 프로젝트 진행에 문제가 생길 수밖에 없습니다 따라서 프로젝트의 본질을 이해하고 이를 명확히 정리하는 능력이 중요합니다 큰 프로젝트일수록 전체적인 흐름과 구조를 이해하고 이를 명료하게 표현할 수 있는 것이 성공의 열쇠입니다

처음 큰 프로젝트를 맡게 되면 부담이 클 수 있지만 이러한 원칙을 지키며 차근차근 나아간다면 성공적으로 완수할 수 있을 것입니다

가장 먼저 고려할 수 있는 방법은, 문제가 되는 데이터가 왜곡되었을 때 그 데이터를 바로잡기 위한 별도의 프로그램을 만드는 것입니다. 당장 서비스중인 프로그램인 경우 당장 문제를 해결하지 못하면 안되기 때문입니다. 일단 프로그램을 주기적으로 돌려 문제를 임시로 해결하고, 천천히 버그의 근본 원인을 분석하면 됩니다. 대충 땜빵쳐 놓고 실제로 고치는건 나중에 하는겁니다. 이렇게 시간을 벌면서 문제를 해결하는 과정은, 불가피한 상황에서 유용한 전략이 될 수 있습니다.

때로는 아예 처음부터 다시 만드는 방법도 고려할 수 있습니다. 경험상, 처음부터 다시 만든 프로젝트에서 기존의 버그가 사라지는 경우를 여러 번 겪었습니다. 처음부터 만드는건 매우 번거롭고 오래걸리는 일입니다. 하지만 생각보다 오래 걸리지는 않을겁니다. 처음 만들 때보다는 금방 완성할 수 있습니다. 처음 만들 때보다 시간이 덜 걸리는 이유는, 이미 그 프로젝트의 구조가 머릿속에 자리 잡고 있기 때문입니다. 처음부터 다시 만들기를 두려워하지 말고, 오히려 더 빠르고 효율적인 해결책이 될 수 있다는 점을 염두에 두는 것이 좋습니다.

그러나 버그가 도저히 해결되지 않거나, 해결에 시간이 걸릴 것으로 예상된다면, 공지를 통해 문제의 발생 사실을 알리고 사과문을 올리는 것도 하나의 방법입니다. 문제를 정확하게 알리고 해결 시간을 명시해두면, 사용자와의 신뢰를 지킬 수 있습니다. 기능 자체를 일시적으로 막아두고 버그를 수정한 후 다시 배포하는 것도 고려해볼 만한 방법입니다.

이러한 상황은 개발자로서 자존심이 상할 수 있는 일입니다. 하지만, 실제 서비스에서는 제한된 시간 내에 반드시 결단을 내려야 할 때가 있습니다. 문제가 발생한 범위를 명확하게 규정하고, 더 이상 피해가 확산되지 않도록 선을 긋는 것이 바로 개발자의 중요한 역할 중 하나입니다.

버그가 발생했다면, 가장 먼저 해야 할 일은 그 버그가 어떤 문제를 일으키고 있는지 전파하고, 영향 범위를 명확히 하는 것입니다. 어떤 원인으로 인해 버그가 발생했으며, 그로 인해 어떤 영향을 받았는지, 이를 해결하는 데 얼마나 시간이 걸릴 것인지를 투명하게 소통하는 것은 책임 있는 개발자의 자세입니다.

우리가 돈을 받고 일하는 개발자라면, 이런 책임과 절차를 반드시 지키며 버그 해결에 임해야 합니다.