최근 몇 년간 IT 업계에는 많은 변화가 있었다. 빅테크 기업들의 대규모 감원 소식이 연이어 들렸고, 생성형 AI가 부상하면서 “개발자 일자리가 사라지는 것 아니냐”는 불안감도 커졌다. 하지만 현장에서 채용 담당자들과 이야기해보면, 실력을 갖춘 엔지니어에 대한 수요는 여전히 강하다는 반응이 일관되게 나온다. 문제는 ‘엔지니어 수요’가 아니라 ‘어떤 엔지니어냐’다. 같은 개발자라도 선택받는 사람과 그렇지 않은 사람 사이에는 분명한 차이가 있다. 이 글에서는 그 차이를 구체적으로 살펴보고, 지금 당신이 무엇을 준비해야 하는지를 이야기한다.
엔지니어 수요, 실제로는 어떤 상황인가
2022~2023년의 테크 레이오프는 많은 사람에게 충격을 주었다. 하지만 감원의 맥락을 들여다보면, ‘개발자가 필요 없어졌다’기보다 ‘팬데믹 시기에 과도하게 채용한 인원을 조정했다’는 해석이 더 정확하다. 실제로 감원이 집중된 영역은 광고·커머스 관련 프로덕트나 내부 운영 조직이었고, 인프라·보안·AI·데이터 영역의 엔지니어는 그 시기에도 구인 공고가 이어졌다.
국내 시장도 비슷하다. 대형 인터넷 기업들이 신중한 채용 기조를 유지하는 한편, 핀테크·헬스케어·B2B SaaS 스타트업들은 꾸준히 시니어급 엔지니어를 찾고 있다. 스타트업뿐 아니라 제조·금융·물류 등 이른바 ‘전통 산업’에서도 디지털 전환 수요로 인해 개발자 채용이 늘고 있다. 다만 이 수요는 예전처럼 “코딩만 할 줄 알면 쉽게 자리를 잡을 수 있었던” 시절과는 다르다. 지금은 더 높은 기준이 적용된다.
결론적으로 엔지니어 수요 자체는 건재하지만, 그 수요는 점점 더 특정 역량을 가진 사람들에게 집중되고 있다. ‘충분히 잘하는 개발자’의 기준선이 올라간 것이다. 이 상황에서 살아남는 방법은 기준선을 넘는 것이다.
AI 시대에 개발자의 역할은 사라지지 않는다, 단 재편된다
생성형 AI가 코드를 작성하는 시대가 왔다. GitHub Copilot을 비롯한 다양한 코딩 보조 도구들이 실제 업무에 쓰이고 있고, 간단한 기능 구현이나 보일러플레이트 코드를 생성하는 데는 꽤 효과적이다. 그렇다면 개발자는 필요 없어지는 걸까? 현장의 목소리는 반대다.
AI 도구는 코드를 ‘생성’하지만, 그 코드가 올바른지, 프로덕션 환경에서 안전한지, 성능 요건을 충족하는지를 판단하는 것은 사람의 몫이다. AI가 생성한 코드를 검토하고 수정하고 통합하는 능력, 즉 엔지니어링 판단력은 오히려 더 중요해졌다. AI를 잘 쓰는 개발자와 그렇지 않은 개발자 사이의 생산성 격차는 벌어지고 있으며, 이는 곧 AI를 도구로 활용할 줄 아는 엔지니어가 더 경쟁력 있다는 의미다.
실제로 채용 공고에서 ‘AI 도구 활용 경험’을 우대사항으로 명시하는 기업이 늘고 있다. Copilot, Cursor, Claude 같은 도구를 일상적으로 쓰면서도, 결과물의 품질을 스스로 통제할 수 있는 개발자를 원한다. 단순히 도구를 쓰는 사람이 아니라, 도구를 비판적으로 활용할 수 있는 엔지니어를 원하는 것이다.
선택받는 개발자의 공통점
오랫동안 현장에서 개발자 커리어를 살펴보면 선택받는 사람들에게 반복적으로 나타나는 패턴이 있다. 기술 스택보다 더 근본적인 것들이다.
- 문제를 정의하는 능력: 주어진 요구사항을 그대로 구현하는 것을 넘어, 왜 이 기능이 필요한지, 어떤 문제를 해결하는지를 이해하고 더 나은 방식을 제안할 수 있는 사람. 이런 개발자는 팀에서 프로덕트 관련 논의에도 기여할 수 있다.
- 코드 이상의 커뮤니케이션: 기술적인 내용을 비개발자에게 설명하거나, PR 리뷰에서 맥락을 명확히 전달하거나, 장애 상황을 빠르게 공유하는 능력. 개발팀이 클수록 이 역량의 비중이 커진다.
- 학습 속도와 방향성: 새로운 기술을 빠르게 익히는 것보다, 무엇을 배워야 하는지를 스스로 파악하는 능력. 트렌드를 좇기보다 자신의 영역에서 깊이를 쌓으면서 필요한 것을 선별하는 판단력이 중요하다.
- 운영 감각: 코드를 배포하는 데서 끝나지 않고, 실제 서비스가 어떻게 동작하는지, 모니터링과 로그를 어떻게 해석하는지, 장애 시 어떻게 대응하는지를 아는 것. 풀스택이 아니어도 기본적인 운영 관점을 갖춘 개발자를 기업은 선호한다.
이 중 어느 하나도 단기간에 만들어지지 않는다. 하지만 방향을 알고 의식적으로 성장하면 2~3년 안에 눈에 띄는 차이를 만들 수 있다.
포트폴리오와 이력서, 실제로 통하는 방식
개발자 채용에서 이력서와 포트폴리오의 역할은 여전히 크다. 하지만 많은 사람이 효과가 낮은 방식으로 시간을 쏟고 있다. 흔한 실수 몇 가지를 짚어본다.
첫째, ‘기술 스택 나열’로 채워진 이력서다. React, TypeScript, AWS, Docker… 이런 목록은 거의 모든 지원자가 가지고 있다. 채용 담당자의 눈길을 끄는 것은 기술 목록이 아니라 “그 기술로 무엇을 해결했는가”다. 이력서의 각 항목에는 맥락(왜), 행동(어떻게), 결과(무엇이 달라졌는가)가 담겨야 한다.
둘째, 토이 프로젝트로만 구성된 포트폴리오다. 물론 토이 프로젝트도 가치 있다. 하지만 실제 사용자가 있는 서비스, 오픈소스 기여 경험, 회사에서 담당했던 실질적인 기술 과제를 보여줄 수 있다면 훨씬 강한 인상을 남긴다. 토이 프로젝트라면 “왜 이걸 만들었고, 어떤 기술적 판단을 했고, 무엇을 배웠는가”를 README에 담아야 한다.
셋째, 지원하는 회사 또는 직무에 대한 맞춤 없이 동일한 이력서를 보내는 경우다. 핀테크 스타트업에 지원할 때와 대형 이커머스에 지원할 때 강조해야 할 경험과 기술이 다르다. 공고를 꼼꼼히 읽고, 그 회사가 실제로 겪고 있을 문제와 내 경험을 연결하는 작업이 필요하다.
지금 당장 시작할 수 있는 3가지 행동
막연하게 ‘더 잘해야지’라는 생각보다, 지금 당장 실행할 수 있는 것들을 구체적으로 제안한다.
- 본인의 강점 영역을 하나 정하고, 그 분야에서 외부에 설명 가능한 수준까지 파고든다. 블로그 글이든 발표든 PR 리뷰 코멘트든, 자신의 이해를 외부화하는 연습을 하면 실력도 같이 올라간다. ‘설명할 수 없으면 아직 모르는 것’이라는 관점을 갖는다.
- 현재 다니는 회사(또는 사이드 프로젝트)에서 최소 하나의 ‘개선 스토리’를 만든다. 느렸던 쿼리를 최적화했거나, 반복 작업을 자동화했거나, 장애 대응 방식을 개선했거나. 숫자로 표현할 수 있으면 더 좋다. 이 스토리가 다음 이직 때 핵심 무기가 된다.
- 개발자 커뮤니티나 스터디에 꾸준히 참여한다. 정보 습득 이상으로, 업계 흐름을 피부로 느끼고 레퍼런스를 쌓는 창구가 된다. 채용은 종종 공고보다 네트워크를 통해 먼저 흘러들어온다.
이 세 가지 중 하나라도 지금 실행하고 있지 않다면, 오늘 시작할 수 있다. 큰 결심이 필요한 일이 아니다. 하나의 글을 쓰거나, 하나의 개선 티켓을 올리거나, 하나의 커뮤니티 채널에 참여하는 것으로 충분하다.
커리어는 계획보다 방향이 중요하다
많은 사람들이 커리어 계획을 세우는 데 에너지를 쏟는다. 3년 후에 어느 회사, 5년 후에 어떤 직급. 하지만 기술 업계의 변화 속도는 그런 장기 계획이 자주 빗나가게 만든다. 더 중요한 것은 방향이다. 나는 어떤 문제를 푸는 엔지니어가 되고 싶은가. 어떤 팀에서, 어떤 방식으로 일하고 싶은가.
방향이 있으면 기술을 선택하는 기준이 생기고, 기회를 평가하는 눈이 생기고, 어려운 상황에서도 흔들리지 않는 기준점이 생긴다. 반대로 방향 없이 트렌드만 좇으면 항상 남을 따라가느라 지치고, 정작 중요한 것을 놓친다.
지금 시장에서 선택받는 개발자들의 공통점은 최신 기술을 모두 아는 사람이 아니다. 자신이 하는 일의 의미를 알고, 팀과 함께 문제를 해결하며, 꾸준히 성장하는 사람들이다. 화려한 스펙보다 이런 방식으로 일하는 사람을 채용 담당자들은 기억하고, 결국 선택한다.
커리어의 방향을 정하고, 거기에 맞는 구체적인 행동을 지금 시작하는 것. 그것이 불확실한 시장 속에서도 선택받는 엔지니어가 되는 가장 현실적인 방법이다.
누스쿨에는 비슷한 고민을 가진 개발자들과 실제 현장 경험을 나누는 멘토들이 있다. 커리어 방향을 함께 점검하거나, 이직·취업 준비를 구체화하고 싶다면 누스쿨 커뮤니티에서 대화를 시작해보자. 혼자 고민하는 것보다, 비슷한 길을 걸어본 사람의 이야기 하나가 훨씬 빠른 답을 줄 때가 많다.
💬 댓글 0