2026년, 취준생이 만들면 좋은 프로젝트 vs 의미 없는 프로젝트

현업 테크 리드로서, 요즘 취준생 포트폴리오를 보면프로젝트 안에 AI 기능 하나쯤 들어가 있는 게 더 이상 특별하지 않습니다.그래서 이제는“AI를 썼느냐 안 썼느냐”보다는,AI 기능이 들어가 있는 프로젝트를 어떻게 만들었는지가 더 중요해졌습니다.다르게 말하면,이제는 AI 기능이 포함된 프로젝트를 기본 전제로 놓고 평가하는 분위기에 가깝습니다.거두절미하고, 체크리스트를 확인하여 서류통과 여부 확인하기!지금 진행 중이거나 이미 만든 프로젝트를 떠올리면서아래 질문에 한 번만 솔직하게 답해보셔도 좋겠습니다.이 프로젝트를 왜 만들었는지 한 문장으로 설명할 수 있는가프로젝트 안에서 AI 기능이 맡고 있는 역할이 명확한가AI 기능이 없다면 프로젝트의 핵심 가치가 크게 줄어드는가기능 구현 말고, 어떤 고민과 선택을 했는지 설명할 수 있는가README에 결과보다 과정과 판단이 드러나는가여기서 몇 개가 막히면,그 프로젝트는 기술 스택과 무관하게기업 입장에서 평가하기 애매한 상태일 가능성이 큽니다.결론부터 말하면 이렇습니다이제 취준생 프로젝트에서AI 기능은 ‘있으면 좋은 옵션’이 아니라,자연스럽게 포함돼 있기를 기대하는 요소에 가깝습니다.다만 중요한 건,AI 기능이 프로젝트의 중심 문제를 실제로 돕고 있는지입니다.그래서 같은 AI 기능이 들어가 있어도어떤 프로젝트는 좋아 보이고,어떤 프로젝트는 여전히 '장난감'처럼 보입니다.의미 없는 프로젝트는 보통 이런 특징을 가집니다1. AI 기능이 프로젝트와 따로 놉니다메인 흐름과 크게 상관없는 요약 기능있어도 없어도 큰 차이가 없는 추천 기능“요즘 많이 쓰니까” 붙인 AI 기능기능 자체가 잘못된 건 아닙니다.다만 이런 경우,AI는 프로젝트를 돋보이게 하기보다억지로 갖다가 붙인느낌이 되기 쉽습니다.2. AI를 쓴 이유가 분명하지 않습니다“AI를 써서 더 좋아졌어요”라는 설명만 있고,어떤 점이 어떻게 달라졌는지가 빠져 있는 경우가 많습니다.기업 입장에서는 자연스럽게 이런 질문이 나옵니다.규칙 기반으로는 왜 안 됐는지AI를 쓰면서 얻은 게 뭔지대신 감수한 단점은 없는지이 질문에 답이 안 나오면프로젝트는 기술 데모처럼 보이기 쉽습니다.3. AI 기능의 한계가 전혀 드러나지 않습니다AI가 항상 잘 동작하는 것처럼 설명된 프로젝트는오히려 신뢰도가 떨어집니다.잘 안 맞는 케이스는 뭐였는지정확도가 흔들리는 상황은 언제였는지비용이나 응답 속도 이슈는 없었는지이런 얘기가 하나도 없으면실제로 써본 프로젝트인지 의심을 받기 쉽습니다.반대로, AI 기능이 들어가 있어도 좋은 프로젝트는 이렇습니다1. AI가 핵심 문제를 직접 건드립니다좋은 프로젝트는“이 문제는 AI 없이는 풀기 애매하다”는 전제가 깔려 있습니다.그래서 AI 기능이장식이 아니라 문제 해결의 일부로 자연스럽게 들어갑니다.2. AI를 하나의 구성 요소로 다룹니다AI를 만능처럼 설명하지 않습니다.입력은 무엇인지출력은 어디에 쓰이는지실패했을 때 시스템은 어떻게 반응하는지이런 설명이 있으면프로젝트가 훨씬 실무적인 인상을 줍니다.3. 선택의 이유가 남아 있습니다모든 선택이 정답일 필요는 없습니다.중요한 건,왜 이 방식을 골랐는지다른 선택지는 뭐였는지지금 다시 만든다면 바꾸고 싶은 부분은 뭔지이게 정리돼 있으면AI 기능이 들어간 프로젝트는유행이 아니라 사고의 결과물로 보입니다.그래서, 프로젝트를 하나 더 만들기 전에이제는AI 기능이 포함된 프로젝트를 하나쯤은 갖고 있는 게 자연스럽고,그 자체로 불리하지도 않습니다.다만 프로젝트 개수를 늘리기 전에,AI 기능이 왜 필요한지 다시 정리하고프로젝트 안에서 맡은 역할을 분명히 하고그 선택의 이유를 남기는 게 먼저입니다.이 차이로같은 기술을 써도 프로젝트 평가는 크게 갈립니다.마무리로 한 가지 덧붙이면,이 기준을 알고 있어도 혼자 적용하기 어렵다는 이야기를 많이 들었습니다.혹시 계속 서류에서 떨어지는 분, 이력서나 프로젝트 조언받고 싶으신 분은커피 한잔값에 봐드리도록 하겠습니다.필요하신 분만 참고하시면 됩니다.[ 온라인 멘토링 링크 ] AI가 발전해도 기업에서는 사람을 뽑을 수 밖에 없습니다.지원자가 아무리 많아도,기업 입장에서는 제대로 일할 뽑을 사람이 없다고 합니다.이력서와 프로젝트만 잘 써도 쉽게 합격합니다.

[Tech Lead 관점] - 신입 개발자 이력서에서 제일 먼저 보는 3가지

채용하는 입장에서 말해볼게요.“실력이 중요하죠.” 맞아요. 근데 그 실력을 보기 전에, 이력서에서 먼저 걸러지는 포인트가 있습니다. 제가 이력서 열자마자 습관처럼 확인하는 것 딱 3가지만 정리해볼게요.결론부터 말하자면, 우리 회사 들어와서, "사고칠거 같냐? 아니냐?" 를 기준으로 잡습니다.그걸 판단하기 위해서 다음 3가지를 가장 먼저 봅니다. 1) 구조 & 가독성 — 코드 보기 전부터 이미 점수 난다이력서 파일을 열자마자 제일 먼저 보는 건 기술 스택이 아니라 구조예요. 제목/섹션/프로젝트가 한눈에 정리돼 있으면, 그 자체로 “일 잘하겠다”는 인상을 줍니다.반대로, 글이 길고 흐름이 없으면 이런 생각이 먼저 들어요.“실무에서도 정리 없이 던지고 끝내는 스타일이면 어떡하지?” 체크 포인트프로젝트는 무슨 문제 → 내가 한 일 → 결과 순서가 제일 읽기 좋음“열심히 했습니다/많이 배웠습니다” 같은 문장 줄이고, 사실(근거)로 대체 2) 프로젝트에서 “내가 뭘 했는지”가 선명한가신입 이력서에서 정말 많이 보는 문장이 있습니다.“팀 프로젝트로 웹 서비스 개발”이 문장 자체는 틀린 말이 아닌데, 정보가 거의 없어요. 실무 입장에서는 “그래서 본인은 뭘 했는데?”가 바로 떠오릅니다. NO : 기능 나열만 있음로그인/회원가입 구현OK : 문제 + 선택 + 결과가 보임JWT 기반 로그인 구현. 토큰 만료로 인증 오류가 자주 발생해 refresh token 구조로 개선했고, 재로그인 빈도를 줄였다(예: 관련 이슈/로그 감소 등 근거가 있으면 더 좋음). 체크 포인트역할/담당 범위를 1~2줄로 먼저 못 박기가능하면 결과를 숫자/지표로(속도 개선 %, 오류 감소, 트래픽 규모 등) 3) 기술 스택 ‘많음’이 아니라, 기술 이해도가 느껴지는가기술 스택을 잔뜩 적어두면 좋아 보일 것 같지만… 솔직히 말하면, 스택이 10개 넘어가면 오히려 신뢰가 떨어질 때가 있어요.대신 이런 걸 봅니다.왜 그 기술을 썼는지 설명할 수 있는지어떤 트러블이 있었고 어떻게 해결했는지하나라도 깊게 써본 흔적(설계/트러블슈팅/성능/테스트 등)이 있는지팁“써봤어요”보다 “이 상황에서 이 이유로 선택했고, 이런 trade-off가 있었다”가 훨씬 강합니다.체크 포인트기술 스택은 ‘나열’보다 프로젝트 문장 안에 녹이기자신 없는 기술은 과감히 빼고, 자신 있는 2~4개를 더 탄탄하게깊게 한 경험이 없으면 “학습/개인 실습”으로 분리 표기 마무리 — 신입에게 기대하는 건 ‘완성도’가 아니라‘태도와 근거’신입에게 완벽한 실력을 기대하진 않아요. 대신, 정리할 줄 아는 사람, 배운 걸 자기 말로 설명하는 사람, 같이 일할 때 불안하지 않은 사람을 찾습니다.이력서는 “저 이런 사람이에요”를 보여주는 첫 대화고요. 그래서 프로젝트가 화려하냐보다, 읽히냐/설명되냐/근거가 있냐가 먼저입니다.취업을 하고 싶은 분은,인프런의 "취업용 프로젝트 4주 챌린지"도 한 번 참고해보세요. —