채용 혹한기에서 살아남기: 취업에도 ‘전략’이 필요합니다

요즘IT2025년 5월 9일About 2 min

채용 혹한기에서 살아남기: 취업에도 ‘전략’이 필요합니다 관련

요즘 이력서 멘토링을 해보면, 신입의 통과율은 대략 1~5% 수준 정도로 느껴져요. 실제로 어떤 분은 100군데를 지원해서 한 군데 겨우 통과했다고도 하고, 80군데 지원했는데 한 군데 연락이 왔다거나, 50군데 지원에 단 한 번의 답장도 못 받았다는 이야기도 들었습니다. 그만큼 모두에게 힘든 시장이라는 걸 말하고 싶어요. 계속 탈락하거나 연락을 받지 못하면 자존감이 떨어지고 위축될 수밖에 없지만, 지금은 대부분의 지원자가 비슷한 어려움을 겪고 있다는 점을 기억해 주세요. 절대 여러분만의 문제가 아닙니다. IT 업계에 26년 동안 있으면서, 호황기와 혹한기 사이클을 여러 번 겪었습니다. 이 시기도 결국 지나갈 거예요.

지난 3월, 요즘IT는 디스코드 멤버들을 위해 한날 작가님과 함께 ‘2025년 취업·이직 준비 가이드’라는 주제로 웨비나를 열었습니다. 예상보다 뜨거운 반응 속에 진행된 이 자리에서는 채용 시장의 분위기부터, 이력서 작성 실전 팁까지 진솔한 이야기가 오갔습니다. 아쉽게 참석하지 못한 분들을 위해, 그날의 핵심 내용을 정리해 콘텐츠로 다시 전해드립니다.

한날 작가(이하 생략):

안녕하세요, 이번 웨비나에 함께하게 된 한날입니다. 저는 현재 ‘푸딩 캠프’라는 서비스를 운영 중이고요. 개발은 99년부터 시작해 지금까지 꾸준히 활동하고 있으며, 현재는 1인 개발과 운영을 병행하고 있습니다. 요즘IT에는 매달 꾸준히 글을 게재하며 여러분을 만나고 있습니다.

<FontIcon icon="fas fa-globe"/>요즘IT 한날 작가 페이지

앞선 글에서는 구직 과정에서 가장 중요한 서류, ‘이력서’ 작성 전략을 다루어 보았습니다. 이번 글에서는 포트폴리오와 스펙 전략, 그리고 우리의 경쟁자 AI에 대해 짚어볼게요.

승부는 ‘이력서’로, 포트폴리오는 이력서를 ‘보조하는 자료’

자, 이제 포트폴리오 이야기로 넘어가 볼게요.

포트폴리오는 한 마디로 말해 ‘보조 자료’예요. 무엇보다 기억해야 하는 건, 결국 이력서로 승부를 봐야 한다는 점입니다. 채용 담당자는 이력서를 먼저 보고, 이력서를 통해 궁금증이 생겼을 때 비로소 포트폴리오를 열어봐요.

가끔 이력서로 자신을 명확하게 표현하기 어렵다고 생각하는 분들이 있죠. 그래서 이력서는 조금 힘없고 어색하게 쓰면서, 포트폴리오에만 힘을 잔뜩 실어 준비하는 경우가 있어요. 그런데 포트폴리오는 안 보면 그만이지만, 이력서는 반드시 보게 됩니다.

그래서 중요한 건 이력서부터 확실히 준비하는 거예요. 포트폴리오는 ‘이력서에서 표현하지 못한 내용을 담는 자료’가 아니라, ‘이력서를 보고 이 사람에 대해 더 깊이 알고 싶을 때’, ‘이력서에 적힌 내용을 실제 작업물로 확인하고 싶을 때’ 활용하는 자료입니다.

포트폴리오가 완벽히 준비되지 않았다고 해서 취업 활동 자체를 미룰 필요는 없어요. 일단 이력서부터 철저히 작성하고, 포트폴리오는 보조 자료로 준비해 두면 됩니다. 다만 가끔 포트폴리오 제출을 필수로 하는 회사가 있으니, 필요할 때 제출할 수 있도록 간단하게라도 만들어 두면 좋아요.

80%가 하는 실수: ‘프로젝트’만 소개하지 마세요

포트폴리오에서 자주 하는 실수가 하나 있어요. 제가 본 포트폴리오 거의 80%에서 발견한 문제인데요. 바로 포트폴리오에서 ‘프로젝트’를 소개하는 데 급급하다는 점입니다. 다시 말해, 포트폴리오에 자기 자신이 아니라 참여한 프로젝트 자체를 주인공처럼 소개하는 경우가 많아요.

하지만 기억하세요. 포트폴리오의 주인공은 어디까지나 나 자신이어야 합니다. 아무리 포트폴리오에서 프로젝트를 세세하게 소개해도, 보는 사람이 그 프로젝트를 깊이 있게 이해하고 싶어 하지도 않고, 사실상 관심도 크지 않아요.

정작 중요한 것은 ‘그래서 당신이 이 프로젝트를 왜, 어떻게 했는데?’라는 질문입니다. 앞서 이력서에서 강조했던 것과 같습니다. 특히 신입이나 주니어급의 포트폴리오는 대부분 비슷할 수밖에 없어요. 경력이나 경험이 짧아서 차별화가 어렵기 때문이죠.

그래서 포트폴리오에서도 결국 핵심은 ‘왜(Why)’예요. 즉, 같은 문제를 접했을 때 사람마다 문제를 정의하는 방식이나 해결 방법이 다르다는 점을 살려야 합니다. 포트폴리오는 단순히 스크린샷을 찍어 올리고 프로젝트 기능을 나열하는 것이 아니에요. ‘나 자신’의 시각과 생각, 문제를 정의하고 풀어가는 태도를 명확히 보여주는 것이 진짜 포트폴리오입니다.

소스 코드나 내부 문서가 꼭 필요한 것도 아닙니다

사전 질문 중에 이런 내용이 있었어요.

“이전 직장에서 했던 프로젝트를 보안상 포트폴리오에 담을 수 없습니다.”

사실 이건 전혀 문제가 되지 않아요. 꼭 소스 코드나 내부 문서를 가져와서 보여줘야만 하는 게 아니거든요. 내가 했던 프로젝트에 다음과 같이 접근하면 충분합니다.

“이런 프로젝트가 있었고, 이런 문제가 있었습니다. 저는 여기에 대해 이런 식으로 문제 정의를 했고, 저의 이러한 기술과 역량을 발휘해 문제를 해결했습니다. 그 결과 이전 상태(before)에서 이렇게 개선된 상태(after)가 되었습니다.”

이렇게 문제-해결 과정-결과의 흐름으로 쓰면 되는 거예요. 소스 코드나 내부 문서가 없어도 전혀 상관 없어요.

물론 디자이너의 영역은 제가 정확히 알지 못해서 말씀드리기 어렵지만, 개발, PM이나 서비스 기획 분야에서는 보안상의 이유로 자료가 없어도 전혀 문제가 되지 않습니다. 화면 캡처나 스크린샷이 포트폴리오의 전부가 아니라는 걸 기억하세요.

링크보다는 ‘포트폴리오’ 안에서 승부 보기

또, 포트폴리오에 자신의 소개 페이지 링크를 많이 넣는데, 저는 포트폴리오 역시 이력서와 마찬가지로 하나의 문서 안에서 승부를 보는 것을 권장합니다.

포트폴리오를 읽다가 다시 링크를 눌러 URL로 이동하게 되면, 보는 사람의 맥락과 집중력이 쉽게 끊깁니다. 예를 들어 URL을 눌러 새 웹 브라우저 탭이 열렸는데, 마침 다른 사람이 불러서 잠깐 회의를 다녀왔다고 해볼까요? 돌아왔을 때 채용 담당자는 이 웹페이지가 왜 열렸는지 기억하지 못할 것입니다. 결국 아무 고민 없이 페이지를 닫아버릴 수도 있겠죠. 이렇게 되면 나를 충분히 어필할 기회가 사라집니다.

그래서 가급적이면 문서 안에서 모든 내용을 다 정리하고 끝내는 게 좋아요. 특히 개발자의 경우 깃허브(GitHub) 페이지 링크를 넣곤 하는데, 아무 맥락 없이 덜렁 링크만 걸어 놓는 사례가 많습니다. 링크를 눌렀더니 갑자기 영어로 된 복잡한 설명서가 나온다거나, 뜬금없는 개발 서버 구축 안내 페이지가 나오는 식으로요. 솔직히 말씀드리면 이건 상대방에게 미안할 정도로 역효과예요. 보는 이의 입장에서는 오히려 혼란만 가중되고, 나에 대한 관심이 떨어질 가능성이 큽니다.

만약 꼭 외부 웹페이지로 이동시켜야만 한다면, 클릭하여 링크로 들어온 순간부터 미술관의 안내자 ‘도슨트(docent)’처럼 친절하게 안내해줘야 해요. 가령, “어서 오세요, 채용 담당자님. 지금부터 A 프로젝트를 소개하겠습니다. 이 프로젝트는 어떤 것이고, 제가 어떤 역할로 참여했고, 이력서나 포트폴리오 문서에서 말씀드린 그 부분이 바로 이 소스 코드입니다.” 하는 식으로 구체적이고 친절한 안내가 있어야 합니다. UI에 녹여내든, READ ME 문서를 써서요.

하지만 다시 강조하자면, 가장 좋은 방법은 링크나 외부 페이지로 보내지 않고 포트폴리오 문서 자체에서 끝까지 승부를 보는 것입니다.

데모 시연은 되도록이면 영상으로

그 다음, 포트폴리오를 위한 데모 페이지를 운영하고, 채용 담당자가 직접 체험하도록 하는 경우가 있습니다. 하지만 현실적으로 채용 담당자들은 이런 체험을 거의 하지 않아요. 여러분만 해도, 이용 약관도 없는데다 누가 운영하는지도 모르는 웹사이트에 굳이 회원 가입하고 로그인해서 서비스를 이용하고 싶은가요? 아마 아닐 겁니다. 채용 담당자 역시 마찬가지죠.

게다가 회원 가입이나 로그인 기능 자체가 제대로 작동하지 않는 경우도 많고, 마침 채용 담당자가 스마트폰으로 접속했는데 반응형이 안 돼서 제대로 보이지 않을 수도 있습니다. 저 역시 강의나 강연에서 라이브 코딩이나 라이브 시연은 잘 하지 않고, 미리 준비한 영상을 사용하니까요.

여러분의 프로젝트도 마찬가지예요. 정말 매력적인 프로젝트라면 굳이 체험을 요구하는 대신 간접적으로 프로젝트를 경험할 수 있는 짧은 소개 영상을 준비하는 편이 훨씬 효과적입니다. 이 영상을 통해 서비스의 모든 과정을 보여주기보다는, 내가 직접 기여한 가장 매력적인 장면을 간결하게 보여주는 것이 좋아요. 핵심과 매력을 처음부터 바로 전달하는 거죠.

프로젝트는 ‘나’를 가장 잘 설명하는 1~2개면 충분합니다

포트폴리오 안에 들어갈 프로젝트는 많지 않아도 괜찮습니다. 보통은 한두 개 정도로 충분해요. 실제로 채용 담당자들도 포트폴리오가 많다고 해서 모두 다 살펴보지 않습니다. 그러니 개수보다는 한두 개의 프로젝트로 ‘나’를 제대로 전달하는 데 집중하세요.

보통 지원자분들이 불안해지거나 탈락 경험이 많아질수록 포트폴리오 개수를 계속 늘리곤 합니다. 그 불안한 마음은 이해하지만, 사실 포트폴리오에는 최신 프로젝트 한두 개만 있어도 충분합니다. 바로 그 한두 개의 프로젝트를 통해 ‘내가 어떤 문제를 어떻게 바라보고 해결하는 사람인지’를 제대로 보여줄 수만 있다면요. 그것으로 충분히 효과적인 포트폴리오가 됩니다.

스펙 전략: 블로그, 토이 프로젝트, 부트캠프, 그리고 콘퍼런스와 세미나

다음으로는 스펙 전략에 대해 이야기해볼게요. 스펙도 전략적으로 쌓아야 합니다.

블로그 운영은 필수일까요?

특히 블로그에 대해 많이들 질문하는데요. 예전에는 블로그를 열심히 운영하면 “이 친구 참 성실한 사람이구나”, “문서화나 꼼꼼함에 강점이 있겠네” 라는 기대를 갖던 시기가 있었어요.

그런데 요즘은 몇 가지 이유로 블로그에 대한 채용 담당자의 기대치가 많이 떨어졌습니다.

첫째, 표절이 너무 많아요. 남의 글을 그대로 베껴 쓰는 경우가 정말 흔합니다.

둘째, AI가 대신 작성한 글도 많아서 신뢰하기 어렵습니다.

셋째, 실무자 입장에서 봤을 때 그리 특별하지 않은 글들이 대부분이에요. 예를 들면 “무언가 설치하는 법”이나 “Hello World 작성법”과 같은 기본적인 튜토리얼입니다. 이런 정보가 가치가 없다는 건 아니지만, 너무 많은 사람들이 이미 다뤘기 때문에 변별력이 떨어질 수밖에 없죠.

그래서 블로그를 운영할 생각이라면, 내 블로그 전체를 훑어보게 하겠다는 목표보다 ‘내 블로그에 있는 특정 글을 읽게 하겠다’라는 목표로 접근하는 것이 더 효과적입니다.

아니면 아예 취업 스펙으로 생각하지 않고, 나 자신의 학습 효과를 높이기 위한 목표로 접근하는 것이 좋아요. 실제로 글을 쓰면서 학습하면 더 효율적으로 학습된다는 연구도 있으니까요.

다시 말해, 블로그 자체보다 ‘블로그를 운영하는 나’라는 사람의 브랜딩 관점에서 전략을 세우는 게 더 효과적입니다.

제 경험을 하나 말씀드리자면, 제가 원래 게임 업계에서 커리어를 쌓았는데, 인터넷 업계로 성공적으로 전직할 수 있었던 계기도 결국 제 블로그였어요. 제 블로그의 글들을 보고 인터넷 업계 사람들이 저를 흥미롭게 생각하게 되었고, 결국 그 관심이 제안으로 이어져 성공적으로 전환하게 됐습니다.

그러니까 블로그는 “그냥 운영한다”보다는 확실한 전략을 갖고 운영하는 게 좋아요. 내 전문성과 관심사를 제대로 드러낼 수 있는 특정 글을 중심으로 접근하고, 그렇게 블로그를 통해 나 자신만의 브랜드를 만드는 거죠.

부트캠프와 토이 프로젝트는 ‘목적’을 위해

이번에는 부트캠프와 토이 프로젝트 이야기를 해보겠습니다.

부트캠프나 토이 프로젝트를 시작할 때는 목적과 목표를 뚜렷하게 잡는 것이 중요해요. 저 역시 부트캠프 비슷한 프로그램을 운영하고 있는데요. 제가 운영하는 프로그램만 해도 약 3개월입니다. 다른 곳들은 보통 5~6개월이죠. 결코 짧지 않은 시간이에요.

많은 분이 ‘경험을 쌓겠다’ 또는 ‘새로운 걸 배우겠다’는 좋은 마음가짐으로 시작합니다. 하지만 그런 막연한 목표만 가지고 보내기에는 너무 긴 시간이죠. 그보다는 조금 더 힘들더라도 미리 속도를 내서 학습을 하고, 남는 시간을 뚜렷한 목적과 목표를 실현하는 데 투자해보는 걸 추천합니다.

제가 추천하는 가장 효과적인 목표는 바로 ‘프로젝트를 출시하고 운영하는 것’입니다. 사실 프로젝트를 개발하는 과정만으로 내가 이력서에 담고 싶은 주제를 명확히 녹이는 건 생각보다 쉽지 않습니다. 우리가 주로 부트캠프나 토이 프로젝트에서 하는 프로젝트는 대개 복잡하지 않기 때문이죠.

실제로 프로젝트를 출시해보고 운영하면 이야기가 달라집니다. 운영 과정에서 내가 어떤 사람인지, 어떤 사고와 판단을 하는지 보여줄 기회가 정말 많아지거든요.

예를 들어 설명하면 이렇습니다. 내가 A 기능을 개발하려고 했는데, 사용자들은 B 기능을 더 원해요. 이때는 어떻게 결정할까요? 단순히 ‘개발하기 쉬운 기능을 해야지’가 아니라, ‘나는 이런 가치를 중요하게 생각하고, 사용자들의 접근성을 중요하게 여기니까 B 기능을 선택할 거야’라는 식으로 내 생각과 가치관이 분명히 드러날 겁니다.

사용자를 모으는 방법도 마찬가지예요. 사용자 모집 방식이나 홍보 전략을 결정할 때도 사람마다 판단과 접근 방식이 완전히 다릅니다. 이렇게 프로젝트를 출시하고 운영하는 과정에서는 내가 누구인지, 왜 그런 결정을 내리는지가 자연스럽게 나타납니다.

그래서 저는 출시와 운영을 적극 권장해요. 토이 프로젝트나 포트폴리오를 준비하는 수많은 사람 중 실제로 프로젝트를 출시해서 운영하는 사람은 아직 적거든요. 이 자체만으로도 충분히 변별력이 생깁니다. 물론 나중엔 이것도 기본 스펙이 될지도 모르는 안타까운 현실이지만요.

또 한 가지 중요한 것이 있어요. 프로젝트의 주요 단계마다 내가 판단하고 의사결정을 내린 ‘왜(Why)’를 기록으로 반드시 남기세요. 시간이 지나면 당시 생각과 느낌이 흐릿해지고, 논리적으로 재구성하거나 사후 평가를 하게 되거든요. 당시의 감정과 결정 과정을 그대로 기록하면 훗날 이력서에 내가 어떤 사람인지를 생생하게 담아낼 수 있을 겁니다.

콘퍼런스와 세미나는 한 번 할 때 ‘깊이’ 참여하세요

마지막으로 추천하는 스펙 쌓기 전략 중 하나는 콘퍼런스나 세미나에 ‘참여자(발표자)’로 나서는 것입니다. 단순한 참석자가 아니라, 직접 발표를 하면서 적극적으로 참여하는 거죠.

크든 작든 여러 모임에 나가서 발표를 꾸준히 하다 보면, 내 브랜딩을 자연스럽게 할 수 있습니다. 가령 이력서를 열 군데 넣는다고 가정해 볼까요? 그럼 열 곳마다 나를 일일이 소개해야 하지만, 만약 모임에서 한 번 발표를 하면 참석자 수십 명에게 나를 한 번에 알릴 수 있죠. 게다가 발표 경험이 많아지면 면접에서도 자연스럽게 도움이 됩니다.

발표를 처음 시작하면 대개 하드 스킬이나 개인의 경험을 주제로 합니다. 하지만 꾸준히 하다 보면 점차 자신만의 이야기가 뚜렷하게 드러나게 돼요. 지금 제가 이렇게 여러분께 이야기하는 것도 저만의 경험과 생각을 하나의 스토리로 전하는 거잖아요. 마찬가지로 많이 발표할수록 나만의 명확한 스토리가 생기고, 이 스토리를 내 이력서에 담는 것도 훨씬 쉬워집니다.

발표자로 참여하는 게 아직 부담스럽다면, 스태프나 운영진으로 참여하는 것도 좋습니다. 그것도 부담된다면 간단한 자원봉사자로 참여해서 네트워킹 효과를 최대한 얻는 것도 좋은 방법입니다.

콘퍼런스나 세미나는 단순히 참석하는 것보다 한 번을 가더라도 깊게 참여하는 게 여러분의 브랜드를 만드는 데 훨씬 효과적입니다.

최고의 경쟁자, AI

마지막으로 최근의 중요한 화두이자 여러분께 조금 안타까운 현실도 짚어볼게요. 바로 여러분의 경쟁자가 다름 아닌 AI라는 사실입니다.

위기는 맞습니다

지금 AI에 대해 정말 많은 이야기가 나오고 있죠. 제 주변의 CTO나 리더급, 심지어 CEO도 자주 하는 이야기입니다. 특히 CEO들은 요즘 투자자에게서 이런 요청을 자주 듣는다고 해요.

“기존에 사람이 하던 업무를 AI가 대신 처리할 수 있는 구조나 방식을 만들어 보세요.”

실제로 저만 해도 혼자 일하지만, AI와 코딩을 할 때 마치 주니어 개발자(약 3~5년 차)와 협업하는 느낌으로 작업하고 있습니다. AI를 활용하는 경험이 쌓이다 보니, 과거에라면 실제로 3~5년 차 주니어 개발자를 채용했을 상황에서 지금은 한 달 10만 원도 안 드는 AI와 협력하는 선택을 하게 됩니다.

그래서 저는 AI가 가져오는 변화가 단순히 과장된 얘기라고 생각하지 않습니다. 개인적으로 지금 이 상황은 개발자들에게 상당한 위기임이 분명하다고 느껴져요. 현실적으로, 이제 여러분의 경쟁자는 동료 지원자가 아니라 바로 AI가 될 가능성이 커지고 있습니다.

‘AI 네이티브’가 되는 법을 고민하기

과거에 신입이나 주니어에게 맡겼던 작업을 이제는 AI가 몇 분 만에 처리할 수 있는 시대가 되었습니다. 지금 중요한 건, 여러분이 AI가 대신 할 수 있는 작업을 똑같이 수작업으로 하는 것이 아니라, 그 작업을 AI에게 정확하고 효과적으로 시킬 수 있는 능력을 갖추는 것입니다.

즉, ‘AI 네이티브(AI Native)’가 되는 게 중요합니다.

구체적으로 어떻게 해야 할지 저도 아직 명쾌한 답은 없습니다. 어떤 접근법이 가장 좋을지는 저 역시 계속 고민하고 있거든요. 하지만 한 가지 확실한 것은, 여러분이 지금 활발히 등장하는 새로운 기술들(예를 들어, 바이브 코딩이나 커서(Cursor), 윈드서프(Windsurf), MCP 등)을 적극적으로 따라가고, 활용할 수 있도록 익숙해져야 한다는 점입니다.

특히 신입과 주니어분들은 AI를 ‘나 대신 코드를 짜주는 도구’로 활용하기보다, ‘학습의 과정을 압축적으로 경험하는 도구’로 활용하는 것이 더 효과적입니다. AI가 작성해주는 코드의 수준이 아주 높은 것은 아닙니만, 평균적으로 약 3년 차 정도의 역량을 지니고 있다고 볼 수 있어요. 대신 AI는 특정 분야가 아니라 거의 모든 분야를 폭넓게 아는 다양한 경험을 갖춘 3년 차 개발자에 가깝습니다.

가령 테스트 코드를 작성할 줄 모른다면, AI에게 테스트 코드 작성을 요청하고, 그 코드를 기준으로 연습하는 거죠. 테스트 코드는 보통 사수나 멘토 없이 혼자 배우기 어렵잖아요. 그때 AI를 활용하면, 간접적으로 사수나 멘토 역할을 대신할 수 있는 것입니다.

물론 경험이 풍부한 사수나 멘토가 곁에 있다면 가장 이상적이겠지만, 현실적으로 그런 지원이 부족한 상황이라면, AI를 적극적으로 활용해보세요. 지금은 AI 네이티브가 되는 것이 선택이 아니라 필수인 시대입니다.

AI를 ‘통제’하고 ‘관리’할 줄 알아야 합니다

시니어 개발자의 입장에서 볼 때도, 이제는 단순히 “이 주니어가 하던 걸 그냥 AI한테 맡겨야겠다” 같은 형태가 아니라, 좀 더 나아가서 “AI를 활용하고 관리하는 일을 이 주니어가 맡을 수 있겠구나. 그동안 나는 다른 더 중요한 일에 집중해야겠다.” 이렇게 생각하며 협업하는 방식으로 가야 합니다.

왜냐하면, 제가 경험한 바로는 AI가 작성하는 코드의 수준이 아무리 좋아도 경력 5년 차 수준을 넘지 못하거든요. 아직까지는 그렇게 뛰어난 코드를 기대하기 어렵습니다. 그래서 결국엔 사람이 AI가 작성한 코드를 꼼꼼히 리뷰하고 관리해야 하는데, 이 과정도 상당히 피곤하고 번거롭습니다.

따라서, 만약 신입이나 주니어가 AI가 작성한 코드를 능숙하게 관리하고, 주도적으로 통제할 수 있다면, 그런 사람을 회사에서도 선호하게 될 겁니다. 이제는 AI를 활용하고 관리하는 능력이 중요한 스펙이자 경쟁력이 되는 시대입니다. 다시 한 번 강조할게요. AI 네이티브가 되는 것은 이제 선택이 아니라 필수입니다.

요즘 취업하는 이들은 무엇이 필요할까?

이것으로 한날 작가님이 준비한 강연은 모두 끝났습니다. 하지만, 이어진 질의응답 시간에도 무척 많은 질문이 쏟아졌습니다. 주요 질문과 작가님의 답변을 모아봤습니다.

Q. 비전공자 또는 재학생이라서 포트폴리오가 충분하지 않거나 완성되지 않은 경우, 방향과 목표를 어떻게 잡아야 할까요?

비전공자 또는 재학생이라서 포트폴리오가 충분하지 않거나 아직 완성되지 않은 분들이 많습니다. “담을 내용이 부족한데 어떻게 쓰면 좋을까요?” 하는 고민이죠. 비슷한 질문들도 실제로 많았는데요.

포트폴리오가 충분하지 않다는 고민은 두 가지로 나눌 수 있을 것 같아요.

첫째, 프로젝트 수 자체가 너무 적다는 고민, 둘째, 프로젝트는 있지만 이걸로 나를 잘 표현하기 어렵다는 고민입니다.

두 경우 모두 중요한 건 수가 아니라 깊이입니다. 앞에서도 말했듯이, 프로젝트는 한두 개만 있어도 충분합니다. 프로젝트 수가 적다면 그 한두 개의 프로젝트를 정말 나답게 풀어내는 데 집중하면 됩니다.

마지막으로, 포트폴리오가 아직 준비되지 않았다고 해서 지원을 미룰 필요는 없습니다. 포트폴리오는 어디까지나 보충 자료입니다. 일단 이력서부터 명확히 작성하고 지원하세요. 포트폴리오는 이후 추가로 준비해도 충분합니다.

Q. 웹 개발자에서 게임 개발자로 직무를 전환하려고 하는데, 어떤 준비를 추가로 하면 좋을까요?

만약 내가 백엔드 개발자로 전직을 준비한다면, 당연히 이 분야의 하드 스킬에 대한 능력을 보여줘야 합니다. 그런데 아직 관련 경력이 없는 경우라면 어떻게 할까요?

이럴 때는 “나는 이 분야를 빠르게 학습할 수 있는 사람이다”, “내가 했던 이전 업무와 백엔드 개발 사이에 이런 유사점이 있어서 금방 적응할 수 있다”는 점을 강조하는 것이 효과적입니다.

또한, 직무를 바꾸는 상황에서는 당장 구체적인 업무 수행은 숙련도가 부족할 수밖에 없지만, 이전 직무에서 내가 어떤 방식으로 일했는지, 어떤 소통을 했는지, 협업 능력과 소프트 스킬은 얼마나 뛰어난지를 잘 설명하는 것이 중요합니다. 즉, 현재 기술적 숙련도는 부족하지만 빠르게 학습하고 적응할 수 있다는 점을 설득력 있게 어필하는 것이 좋습니다.

비IT 직종에서 IT 직종으로 이직하는 경우도 많습니다. 예를 들어, 마케팅 분야에서 3년간 일했던 분이 프론트엔드 개발자로 전직을 할 때를 생각해볼까요? 이 분은 프론트엔드 개발자로서는 분명히 신입입니다. 하지만 사회생활 경험만큼은 이미 3년 차 경력자인 것이죠. 아예 직장 경험이 없는 신입과는 분명히 적응력과 조직 문화 이해도에서 큰 차이가 있을 수밖에 없습니다.

이런 경우에는 정직하게 “이 분야에 대해서는 신입이지만, 사회생활 경력 덕분에 빠르게 적응할 수 있다”고 자신 있게 말하세요. 그런 부분을 적극적으로 어필하면서, 스스로도 “나는 이미 일정 수준의 경력을 갖춘 사람이다”라는 점을 잊지 말고 계속 기억하세요.

오히려 스스로 “나는 신입이고 초보자야”라는 생각에 갇혀 위축되면, 그 위축된 모습이 이력서와 면접에서도 드러나게 됩니다. 자신감을 가지고 내가 가진 경험과 강점을 명확히 전달하세요.

Q. 포트폴리오의 디자인 요소는 얼마나 중요한가요? 직무마다 다를까요?

우선, 포트폴리오의 디자인 요소가 중요하냐는 질문이 꽤 많은데요.

직무마다 다르다고 할 수 있습니다. 예를 들어 디자이너라면, 당연히 포트폴리오 자체의 디자인적 요소가 매우 중요하겠죠. 왜냐하면 포트폴리오 디자인이 디자이너의 기본 소양과 역량을 보여주는 핵심이기 때문입니다.

하지만 개발자 직군이라면 꼭 그렇지 않습니다. 실제로 개발자의 포트폴리오는 디자인 요소가 거의 없고, 흰 화면에 텍스트 서술과 몇 개의 이미지나 차트만 간략히 첨부되는 경우도 많아요. 다시 말해, 디자인 직군이 아니라면 포트폴리오에서 디자인 요소는 큰 비중을 차지하지 않습니다.

Q. 재직 중 포트폴리오 업데이트는 어느 주기로 하면 좋을까요?

재직 중에 포트폴리오를 계속 업데이트하고 준비하는 분들도 많은데요. 솔직히 말하면, 재직 중에는 포트폴리오를 억지로 업데이트하기보다는 회사 업무 속에서 내가 기여할 수 있는 의미 있는 부분들을 찾아 기록해두는 것이 훨씬 효과적인 것 같습니다.

예를 들어, 프론트엔드 개발자의 경우 최근 AI를 활용한 작업들이 많잖아요. MCP와 피그마(Figma)를 연동해 디자인 결과물을 컴포넌트 코드로 자동 변환할 수 있는 기술을 직접 익혀서 회사에 도입하고, 그 과정과 성과를 기록해 두는 거죠. 그리고 그 경험과 지식을 동료들과 공유하면 더욱 좋겠죠.

백엔드 개발자라면, 입사한 신규 직원이 회사에 처음 들어와 로컬 호스트에서 ‘Hello World’ 띄우는 과정이 기존엔 6시간씩 걸렸던 것을 자동화하거나 문서화해 30분 만에 가능하게 개선한 사례를 만드는 것도 좋습니다.

실제로 이렇게 회사에서 구체적이고 분명한 성과를 낸 경험은 형식적인 포트폴리오보다 훨씬 더 강력한 이력이 됩니다. 회사 내부에서 의미 있게 기여할 수 있는 부분을 찾고, 이를 잘 기록해두는 것이 가장 좋은 포트폴리오 준비 방법입니다.

Q. 이력서에 Why, How, What 순으로 쓰는 예시를 하나 더 들어주세요.

이런 경우가 있었어요. 제 개발자 멘티가 속한 회사의 마케팅 팀은 웹 사이트에서 특정 이벤트가 발생할 때마다 슬랙(Slack) 채널로 알림을 받았대요. 마케터들은 이 알림 메시지를 매번 마우스로 복사해, 내용들을 다시 분류하고 정리하는 작업을 반복하고 있었습니다.

이걸 본 멘티가 “이건 좀 아니다”라는 생각이 들어 자동화를 적용했다고 합니다. 슬랙 메시지를 자동화해 노션(Notion)에 기록하고, 다시 구글 스프레드시트로 자동 연동해 메시지를 체계적으로 분류하게 만든 거죠. 그 결과 마케팅 팀이 이전에 매일 1시간씩 수작업하던 업무가 10분 만에 완료되었다고 합니다. 이 사례를 처음 이력서에 작성할 때, 이 개발자분은 이렇게 표현했습니다.

Why: 수동으로 작업하며 비효율 문제가 발생
How: 슬랙 메시지를 노션, 구글 스프레드시트와 연동해 자동화
What: 작업 시간 단축(1시간 → 10분)

하지만 여기서의 ‘Why’는 정확히 말하면 문제의 현상일 뿐, 진짜 ‘Why’는 아니에요. 이 현상은 회사의 모든 개발자가 보고 있었지만, 왜 이분만 행동에 나섰는지가 중요합니다. 그래서 이분과 다시 이야기하면서 진짜 ‘Why’를 명확히 했습니다. 예를 들어 다음과 같이요.

Why: 저는 사람들이 제대로 인지하지 못한 채 흘러가는 정보, 즉 정보의 비대칭 상태가 업무에서 큰 문제를 만든다고 생각합니다. 그래서 팀 내에서 정보가 제대로 기록되지 않고 흘러가는 것을 보면 불안하고 불편함을 느낍니다. 그런 이유로 저는 이 상황을 문제로 인지했고, 반드시 해결하고 싶었습니다.
How : 슬랙 메시지를 노션과 구글 스프레드시트로 연동해, 정보를 놓치지 않고 체계적으로 기록, 분류하도록 자동화했습니다.
What : 그 결과 마케팅 팀에서 매일 1시간 걸리던 작업을 10분 만에 해결할 수 있게 되었습니다.

이렇게 하면 이 사람이 왜 문제로 인지했는지, 왜 행동에 나섰는지가 명확히 드러나죠.

Q. 경력기술서는 이력서, 포트폴리오랑 어떤 차별점을 둬야 할까요?

경력기술서는 이력서와 포트폴리오와는 목적 자체가 다릅니다. 이력서는 지원자의 핵심 역량과 스토리를 명확히 전달하는 문서로 가장 중요하니 비할 바가 아닙니다.

경력기술서는 말 그대로 ‘경력’을 중심으로 내가 어떤 회사에서, 어떤 직책으로, 어느 기간 동안, 어떤 직무를 맡았는지 간략하게 기술하는 문서입니다. 예를 들어 이렇게 쓸 수 있겠죠.

“저는 A 회사에서 프론트엔드 개발자로 2020년 1월부터 2022년 12월까지 근무했습니다. 여기서 A 프로젝트와 B 프로젝트를 진행했습니다. 이후 B 회사에서 2023년 1월부터 현재까지 C 프로젝트를 담당하고 있습니다.”

반면 포트폴리오는 경력기술서보다 더 구체적이고 상세한 내용을 담습니다. 포트폴리오를 통해 내가 맡았던 프로젝트에서 ‘왜(Why)’ 그 일을 했고, ‘어떻게(How)’ 작업을 수행했으며, 결과적으로 ‘무엇(What)’을 이루었는지를 훨씬 현실적이고 구체적으로 보여줍니다.

즉, 경력기술서는 객관적이고 간단한 경력 요약이라면, 포트폴리오는 내가 참여한 구체적인 업무와 프로젝트 성과를 중심으로 나라는 사람을 더 자세히 보여주는 자료입니다.

Q. 이력서와 포트폴리오의 문장은 어떻게 쓰면 좋을까요? 간결한 편이 좋을까요?

네, 간결한 편이 좋습니다. 그런데 여기서 중요한 부분이 있어요. 문장만 간결해야지, 담아야 할 내용을 빼먹어서 부족하면 안 됩니다. 꼭 전달해야 할 정보는 충분히 담되 문장을 구성할 때 불필요한 표현을 줄이는 것이죠.

사실 ‘간결하게’라는 표현보다는 제가 더 정확히 권하고 싶은 방식이 있어요. 바로 ‘형용사와 부사를 최대한 배제하는 것’입니다.

우리는 글을 쓸 때 무의식적으로 형용사나 부사를 자주 사용합니다. 왜냐하면 이렇게 쓰는 게 편하거든요. 하지만 형용사나 부사는 결국 매우 모호한 표현이 됩니다. 예를 들어보죠. ‘굉장히 어려웠다’, ‘매우 빨라졌다’ 같은 표현은 읽는 사람이 구체적으로 어떤 상황인지 잘 이해할 수 없습니다. 여기서 ‘굉장히’, ‘매우’ 같은 부사들은 구체적으로 무엇을 의미하는지 명확하지 않아요.

예를 들면 “사람들이 허겁지겁 밥을 먹었다” 대신 “사람들은 적막 속에 조용히, 빠르게 밥을 먹고 있었다”처럼, 형용사를 빼고도 상황이 머릿속에 구체적으로 그려지도록 묘사하는 식이죠.

이력서와 포트폴리오도 같은 방식으로 쓰세요. ‘대단히 어려웠다’, ‘굉장히 빨라졌다’ 대신, “API 응답 시간이 2000ms에서 800ms로 줄었다”처럼 구체적인 동사와 숫자로 표현하는 것이 좋습니다.

마치며: 요즘 취업 어려운데 살아남을 수 있을까요?

마지막 질문에 대한 작가님의 답으로 글을 마무리합니다. IT 업계에서 취업과 이직을 준비하는 모든 분을 요즘IT가 진심으로 응원합니다.

A. 지금 채용 혹한기는 맞습니다. 그래도 최근 한두 달 사이, 경력자를 중심으로 채용과 이직 소식이 조금씩 들리고 있습니다. 저 역시 작년 한 해 동안은 전혀 외부 제안이 없었는데, 올해 들어서는 협업이나 프로젝트 참여 관련해서 세 번이나 제안을 받았어요. 정부 과제나 투자 자금이 조금씩 풀리면서, 경력자부터 채용 시장이 조금씩 움직이기 시작하고 있다는 신호일 수도 있겠습니다.

요즘 이력서 멘토링을 해보면, 신입의 통과율은 대략 1~5% 수준 정도로 느껴져요. 실제로 어떤 분은 100군데를 지원해서 한 군데 겨우 통과했다고도 하고, 80군데 지원했는데 한 군데 연락이 왔다거나, 50군데 지원에 단 한 번의 답장도 못 받았다는 이야기도 들었습니다.

그만큼 모두에게 힘든 시장이라는 걸 말하고 싶어요. 계속 탈락하거나 연락을 받지 못하면 자존감이 떨어지고 위축될 수밖에 없지만, 지금은 대부분의 지원자가 비슷한 어려움을 겪고 있다는 점을 기억해 주세요. 절대 여러분만의 문제가 아닙니다. 지금은 시장 전체가 힘든 시기니까요.

IT 업계에 26년 동안 있으면서 호황기와 혹한기 사이클을 여러 번 겪었습니다. 이번 혹한기가 분명 좀 더 길고 힘겹게 느껴지는 것이 사실이지만, 시장은 늘 호황과 불황을 반복하는 사이클이 존재합니다. 얼마 전까지 시장이 유난히 좋았기 때문에 지금 혹한기가 더 어렵게 느껴질 수 있지만, 이 시기도 결국 지나갈 거예요.

이번 사이클에는 큰 변수가 또 하나 있습니다. 앞서 말한 AI라는 새로운 경쟁자의 등장입니다. 그래도 다행히 AI는 지금 우리가 영향을 미칠 수 있는 부분이 있습니다. 따라서 특별히 관심을 가지고 AI를 접해 보았으면 좋겠습니다. 우리 모두 파이팅해요.

채용 혹한기에서 살아남기: 취업에도 ‘전략’이 필요합니다