시리즈 · AI시대의 주니어 생존법
3회 · AI시대의 주니어 생존법 3 - IT 채용시장에서의 고용이란
이 시리즈는 여러 해 동안 주니어를 채용하고 제품을 만들어 온 한 실무자의 경험을 바탕으로, AI 시대의 주니어 개발자에게 요구되는 역량과 성장 방향, 채용 현장의 질문을 차례로 살펴봅니다. 마지막 3편에서는 제 경우 개발자 면접에서 무엇을 묻고 어떤 답에서 가능성을 보는지, 그리고 주니어가 자신의 경험을 채용의 언어로 어떻게 보여줄 수 있는지 이야기하겠습니다.
저는 금융 자금세탁방지 분야의 창립 멤버 중 한 명으로 약 10년간 CTO로 일했고, 현재는 회사명을 공개하지 않은 B2C 플랫폼 조직에서 제품화와 CTO 전략 업무를 이끌고 있습니다. 따라서 아래의 개발자 채용 기준은 스타트업과 중소기업에서 제가 직접 참여한 채용에 국한됩니다. 대기업 공채, 빅테크, 연구직, 게임, 데이터, 보안 등 다양한 직군과 개발 분야를 대표하는 보편적 정답은 아닙니다.
제가 말하는 주니어 개발자는 신입부터 경력 3년 정도까지입니다. 이 시기에는 완성된 기술 목록보다 어떤 문제를 선택했고, 어디까지 밀어붙였으며, 실패에서 무엇을 바꿨는지가 더 많은 것을 보여줍니다.
이제 스킬 목록만으로는 판단하기 어렵다
과거 이력서에는 Java, Spring, React, AWS 같은 기술 목록이 큰 비중을 차지했습니다. 지금도 기초 기술은 필요하지만, AI가 예제와 초안을 즉시 제공하는 환경에서는 “사용해 봤다”는 문장만으로 숙련도를 구분하기 어렵습니다. 같은 저장소 안에서도 한 기능은 직접 작성하고 다른 기능은 AI가 거의 전부 만들 수 있기 때문입니다.
그래서 저는 기술 이름보다 프로젝트의 흐름을 묻습니다. 왜 그 문제를 골랐는지, 요구사항을 어떻게 줄였는지, 어떤 구조를 선택했고 무엇을 포기했는지, 테스트와 배포는 어디까지 했는지 확인합니다. 코드를 완성하지 못했더라도 판단 과정이 구체적이면 배울 수 있는 사람이라는 신호가 됩니다.
반대로 화려한 데모가 있어도 모든 답이 “AI가 해줬다”로 끝나면 판단하기 어렵습니다. AI를 쓴 사실이 문제가 아니라, 본인이 입력과 검증, 선택에 어떤 책임을 졌는지가 보이지 않기 때문입니다. 바이브코딩 경험은 결과 화면보다 그 뒤의 시행착오를 설명할 때 가치가 있습니다.
제가 개발자 면접에서 꼭 묻는 세 가지
최근 AI 기술 트렌드를 어떻게 따라가고 있습니까
제가 원하는 것은 제품 이름 암기나 뉴스 요약이 아닙니다. 최근 알게 된 도구를 실제 작업에 적용해 보았는지, 이전 방식과 무엇이 달랐고 어떤 한계를 발견했는지 묻습니다. AI 기술 트렌드를 안다는 것은 새 모델의 점수를 외우는 일이 아니라, 변화가 자신의 개발 과정에 미치는 영향을 실험하는 일입니다.
예를 들어 Claude Code와 OpenAI Codex를 비교했다면 “둘 다 써봤다”보다 컨텍스트 구성, 도구 권한, 계획과 실행, 실패 복구 방식의 차이를 말할 수 있어야 합니다. OpenAI Codex 같은 코딩 에이전트도 이름보다 보안·품질 체크포인트를 어떻게 구성했는지가 중요합니다.
혼자서 서비스를 어디까지 만들어 보았습니까
개인 프로젝트는 완주 여부만 평가하지 않습니다. 아이디어를 요구사항으로 바꾸고, 화면과 데이터를 설계하고, Git으로 이력을 관리하고, 클라우드에 배포해 보고, 실제 사용자의 반응을 받은 구간이 어디까지인지 봅니다. 처음부터 상용화까지 모두 경험한 주니어는 드뭅니다. 중요한 것은 막힌 지점과 그 이유를 정확히 아는 것입니다.
좋은 답에는 선택과 포기가 있습니다. 시간이 부족해 결제를 제외했다거나, 운영 비용 때문에 특정 인프라를 바꿨다거나, 보안 위험을 발견해 공개 범위를 줄였다는 설명입니다. 이런 판단은 튜토리얼을 그대로 따라 만든 결과와 자신이 책임진 프로젝트를 구분해 줍니다.
팀으로 만든 프로젝트에서 당신의 경계는 어디였습니까
팀 프로젝트에서는 “저희가 만들었습니다”라는 표현을 개인의 행동으로 풀어 달라고 요청합니다. 본인이 제안한 것, 직접 구현한 것, 동료와 충돌한 것, 리뷰를 받고 바꾼 것, 운영 중 대응한 것을 구분해야 합니다. 팀 전체 결과를 개인 성과처럼 말하지 않고도 자신의 기여를 구체적으로 설명할 수 있습니다.
저는 의견 충돌 자체보다, 초기 경험만으로 자신의 판단을 확정하고 타인의 제약을 듣지 않는 태도를 경계합니다. 실제로 작은 조직의 임원진은 주니어의 자기주장이 지나치게 강하면 젊은 시기의 아집으로 굳을 위험이 있다고 보는 경우가 많습니다. 비슷한 역량의 후보라면 굳이 그 위험을 감수하지 않으려는 분위기도 있습니다. 제 경우에도 근거를 제시하되 상대의 제약을 이해하고, 결정된 방향을 실행할 수 있는지를 중요하게 봅니다.
과거 프로젝트의 자세가 미래를 보여준다
면접에서 과거 프로젝트를 자세히 묻는 이유는 정답을 검사하기 위해서가 아닙니다. 지원자가 실제로 경험한 일은 세부로 들어갈수록 맥락과 감정, 판단의 흔적이 남고, 이것이 중요한 채용 판단 자료가 됩니다. 장애 원인을 처음에는 무엇으로 의심했는지, 로그에서 무엇을 확인했는지, 누구에게 언제 도움을 요청했는지 같은 질문은 암기한 모범답안으로 채우기 어렵습니다.
실패한 프로젝트도 좋은 평가 자료가 됩니다. 일정 산정이 왜 틀렸고, 범위를 어떻게 줄였으며, 다시 한다면 어떤 검증을 앞당길지 설명하면 됩니다. 실패를 다른 사람의 탓으로만 돌리거나 배운 점을 추상적으로 말할 때보다, 자신의 판단 오류를 구체적으로 다룰 때 신뢰가 생깁니다.
기술 질문도 이 맥락에서 이어집니다. Git 브랜치 전략을 외웠는지보다 충돌을 어떻게 해결했는지, AWS 서비스를 몇 개 아는지보다 비용과 권한을 어떻게 제한했는지, 테스트 종류를 나열하는지보다 어떤 실패를 막기 위해 테스트를 썼는지 묻습니다. 국내 웹 기술 변천사처럼 유행하는 스택은 계속 바뀌지만, 제약을 읽고 선택을 설명하는 능력은 남습니다.
착함과 자기주장을 채용 기준으로 말하는 법
작은 조직에서는 인성이 중요합니다. 솔직히 말하면 제가 보는 기준에는 “착한가”, “자기주장이 지나치게 강하지 않은가”도 들어갑니다. 작은 팀은 한 사람의 태도가 전체 협업 비용에 미치는 영향이 크고, 가르치고 조율하는 데 쓸 수 있는 시간도 제한되어 있기 때문입니다. 다만 이것을 말 잘 듣는 사람이나 반대하지 않는 사람을 뽑는다는 뜻으로 쓰고 싶지는 않습니다.
제가 보고 싶은 행동은 더 구체적입니다.
- 모르는 것을 숨기지 않고 적절한 시점에 질문합니다.
- 사실과 의견을 구분하며, 반대할 때 근거를 제시합니다.
- 결정 전에는 치열하게 논의하고, 결정 후에는 팀의 선택을 실행합니다.
- 동료의 공을 가져가지 않고 자신의 실수를 수정합니다.
- 고객과 팀에 미칠 위험을 발견하면 불편하더라도 공유합니다.
자기주장이 있다는 사실과 협업을 해치는 것은 같은 말이 아닙니다. 제가 피하려는 것은 주장 자체가 아니라, 근거가 바뀌어도 입장을 고치지 않는 아집입니다. 반대로 조용하고 예의 바르다는 이유만으로 좋은 동료가 되는 것도 아닙니다. 그래서 개발자 면접에서는 성격을 추측하기보다 과거 상황에서 실제로 어떻게 행동했는지 묻습니다.
지원자도 회사를 같은 기준으로 평가할 수 있습니다. 질문을 환영하는지, 코드 리뷰가 있는지, 장애의 책임을 개인에게 돌리는지, 잘하는 사람에게 업무가 무제한으로 몰리는지 물어보는 편이 좋습니다. 채용은 회사가 사람을 일방적으로 고르는 시험이 아니라, 서로의 성장 조건과 위험을 확인하는 계약입니다.
채용을 준비하는 주니어가 남겨야 할 증거
주니어는 거대한 서비스를 만들 필요가 없습니다. 작은 제품 하나라도 다음의 증거를 남기면 면접 대화가 달라집니다.
- 문제와 대상 사용자를 한 문장으로 정의한 문서
- 해야 할 일과 하지 않을 일을 구분한 요구사항
- 주요 기술 선택과 포기한 대안을 기록한 결정 로그
- AI에 준 지시, 실패한 결과, 수정 과정을 보여주는 작업 기록
- 테스트와 배포, 운영 중 발견한 문제와 후속 조치
- 팀 프로젝트라면 역할 분담, 리뷰, 갈등과 합의의 기록
GitHub의 커밋 수나 잔디만 채우라는 뜻이 아닙니다. 결과를 재현하고 자신의 판단을 설명할 수 있는 최소한의 흔적이면 됩니다. 소프트웨어 3.0 시대에는 사람이 직접 입력한 코드의 양보다 사람과 AI가 함께 만든 시스템을 얼마나 이해하고 통제했는지가 더 중요한 증거가 될 수 있습니다.
포트폴리오에는 완성된 화면뿐 아니라 아직 해결하지 못한 문제도 적어보기를 권합니다. 무엇을 모르는지 정확히 말할 수 있는 사람은 질문할 준비가 된 사람입니다. 회사 입장에서도 완벽한 척하는 지원자보다 학습의 다음 단계를 아는 지원자를 신뢰하기 쉽습니다.
정답은 없지만 응원할 이유는 충분하다
이 시리즈는 제 경험을 하나의 정답으로 제시하려는 글이 아닙니다. 제가 일한 조직의 규모와 산업, 채용 시점이 달랐다면 기준도 달라졌을 것입니다. 어떤 회사는 깊은 알고리즘 역량을 우선하고, 어떤 회사는 특정 도메인 지식이나 안정적인 운영 경험을 더 중요하게 봅니다.
다만 한 가지는 분명합니다. AI 때문에 주니어에게 기회가 사라지기만 하는 것은 아닙니다. 과거에는 인프라와 구현 비용 때문에 시도조차 어려웠던 제품을 이제는 혼자 시작할 수 있고, 낯선 기술을 빠르게 실험하며 자신의 판단을 증명할 수 있습니다. 시작 비용이 낮아진 만큼 완성도와 책임의 기준이 높아졌을 뿐입니다.
면접에서 모든 질문에 답할 필요도 없습니다. 모르면 모른다고 말하고, 무엇을 확인하겠는지 설명하면 됩니다. 한 번의 채용 결과가 개발자로서의 가능성을 확정하지도 않습니다. 프로젝트를 끝까지 따라가며 질문하고, 기록하고, 실패를 고치는 사람은 결국 자신만의 프로젝트 수행력을 만듭니다.
AI 시대의 주니어 개발자 여러분을 응원합니다. 도구가 만드는 속도에 주눅 들기보다 그 속도를 이용해 더 많은 문제를 경험하고, 자신의 선택을 설명할 수 있는 개발자로 성장하기를 바랍니다.
댓글 없음:
댓글 쓰기