포트폴리오에 'AI로 만듦'만 쓰면 탈락하는 이유

요즘 개발자 포트폴리오를 보면 비슷한 문장이 자주 나온다. “Claude Code로 2주 만에 만든 서비스”, “Cursor로 혼자 개발한 풀스택 앱”, “AI 에이전트를 활용해 전체 코드를 생성”. 문장 자체가 틀린 건 아니다. AI 코딩 도구를 잘 쓰는 건 이제 분명한 능력이다. 문제는 포트폴리오에 그 한 줄만 있고 나머지가 비어 있을 때다.

이 주소에는 원래 같은 제목의 짧은 글이 있었다. 2026년 10월 기준으로 채용 쪽에서 실제로 공개한 AI 사용 가이드와 개발 조직이 AI 코드를 어떻게 다루는지를 다시 살펴보고 처음부터 새로 썼다. 몇 퍼센트가 탈락한다 같은 통계는 믿을 만한 공개 자료가 없어서 넣지 않았다. 대신 포트폴리오를 읽는 사람이 무엇을 확인하려 하는지, 그 질문에 “AI로 만들었다”라는 문장이 왜 답이 되지 못하는지를 차근차근 정리했다. 마지막에는 바로 고쳐 쓸 수 있는 프로젝트 설명 틀과 점검표를 붙였다.

포트폴리오를 읽는 사람이 실제로 확인하는 것

포트폴리오는 결과물 전시장이 아니다. 읽는 사람 입장에서는 “이 사람과 같이 일하면 어떨까”를 미리 가늠해 보는 자료다. 그래서 결과물이 얼마나 화려한지보다 아래 질문에 답이 있는지를 본다.

이 사람은 어떤 문제를 왜 풀려고 했나
여러 방법 중 무엇을 골랐고, 왜 그걸 골랐나
막혔을 때 어떻게 원인을 찾았나
결과가 정말 동작하는지 어떻게 확인했나
다시 한다면 무엇을 바꾸겠나

이 질문들은 AI가 없던 시절에도 같았다. 달라진 건 하나다. 예전에는 코드가 돌아가는 것 자체가 어느 정도 실력을 증명했다. 직접 짜지 않으면 돌아가는 앱을 만들기 어려웠기 때문이다. 지금은 AI 도구로 그럴듯하게 돌아가는 앱을 꽤 빨리 만들 수 있다. 그러니 “돌아간다”만으로는 더 이상 위 질문에 대한 답이 되지 않는다. 읽는 사람은 자연스럽게 코드 바깥에 있는 판단의 흔적을 찾게 된다.

“AI로 만들었다”만 쓰면 왜 불리한가

1. 누가 판단했는지가 사라진다

“AI로 전체 코드를 생성했다”는 문장은 읽는 사람에게 이렇게 들린다. 설계도, 선택도, 디버깅도 도구가 했다는 뜻으로 읽힐 수 있다. 실제로는 내가 요구사항을 쪼개고, 생성된 코드를 버리고 다시 시키고, 보안 문제를 잡아냈더라도 그 과정이 적혀 있지 않으면 없던 일이 된다. 포트폴리오에서 지원자의 몫이 보이지 않으면 평가할 것도 남지 않는다.

2. 면접에서 바로 확인당한다

포트폴리오에 적은 프로젝트는 면접 질문의 재료가 된다. “이 부분은 왜 이렇게 했나요?”, “인증은 어떻게 처리했나요?”, “이 쿼리가 느려지면 어떻게 하실 건가요?” 같은 질문이 나온다. 내가 이해하지 못한 채 넘어간 코드가 많을수록 이 질문에서 무너진다. AI로 빨리 만든 것보다, 빨리 만든 것을 설명하지 못하는 게 문제다.

Anthropic이 공개한 지원자 AI 사용 가이드를 보면 이 흐름이 잘 드러난다. 지원서는 초안을 직접 쓰고 Claude로 다듬으라고 권한다. 과제와 실시간 면접은 따로 허용하지 않는 한 AI 없이 하라고 한다. 실시간으로 문제를 어떻게 생각하는지 보고 싶다는 이유다. 그리고 해 본 적 없는 경험을 AI로 만들어 내는 건 허용하지 않는다고 분명히 적어 두었다. AI를 매일 쓰는 회사조차 지원자에게 확인하고 싶은 건 결국 본인의 실제 경험과 사고 과정이라는 뜻이다. 모든 회사가 같은 기준을 쓰는 건 아니지만, 채용하는 쪽이 무엇을 보려 하는지 짐작하는 데는 좋은 참고가 된다.

3. 다들 같은 문장을 쓴다

AI 코딩 도구가 흔해질수록 “AI로 빠르게 만들었다”는 차별점이 아니라 기본값이 된다. 같은 문장을 쓴 지원자가 여럿이면 그 문장은 아무것도 구분해 주지 못한다. 오히려 남들과 다른 부분, 즉 어떤 문제에 꽂혔고 어디서 고생했는지가 보여야 기억에 남는다.

4. 품질에 대한 의심을 산다

AI가 만든 코드에 대한 실무자들의 경계심은 꽤 구체적이다. 토스뱅크 ML 엔지니어가 쓴 「AI가 팀 규칙을 지키도록 하는 방법」에는 코딩 에이전트가 수정이 필요한 일부 맥락만 보고 코드를 쓰다 보니 팀의 큰 규칙을 잘 지키지 못하는 문제가 나온다. AGENTS.md 같은 문서에 규칙을 적어 둬도 세션이 길어지면 앞에서 읽은 규칙을 놓친다는 이야기도 있다. 그래서 그 팀은 파일을 쓴 직후와 작업을 끝내기 직전에 규칙을 다시 넣어 주는 장치를 직접 만들었다.

이 글이 보여 주는 건, 현업에서는 AI가 쓴 코드를 그대로 믿지 않고 검증하는 구조를 따로 만든다는 사실이다. 이런 사람들이 포트폴리오를 읽는다. “AI가 다 짰다”는 말을 들으면 자연스럽게 “그럼 검증은 누가 했지?”를 묻게 된다. 그 답이 포트폴리오 안에 있어야 한다.

그렇다고 AI 사용을 숨기라는 말이 아니다

반대로 AI를 썼다는 사실을 숨기는 것도 좋은 전략이 아니다. Anthropic 가이드도 투명하게 밝히라고 적고 있고, 코드 스타일이나 커밋 기록을 보면 어차피 드러나는 경우가 많다. 숨겼다가 면접에서 들키는 쪽이 훨씬 위험하다.

핵심은 AI를 썼다는 사실이 아니라 AI와 내가 각각 무엇을 했는지를 나눠서 보여 주는 것이다. AI 코딩 도구를 잘 쓰는 능력은 요즘 분명한 장점이다. 다만 그 능력은 “AI로 만들었다”가 아니라 “AI를 이렇게 부려서 이런 문제를 풀었고, 이런 부분은 직접 판단했다”로 보여 줘야 전달된다. 도구별 특징과 실제로 어떻게 나눠 쓰는지는 Claude Code 하네스 정리와 Cursor vs Claude Code 비교에 정리해 두었다.

AI 시대 포트폴리오에 꼭 들어가야 할 6가지

1. 문제 정의: 왜 만들었나

“할 일 관리 앱”이 아니라 “팀원 다섯 명이 매주 엑셀로 하던 업무 배분을 자동화하려고 만들었다”처럼 구체적인 상황을 적는다. 누가, 어떤 불편을 겪었는지가 보이면 그다음 선택들이 모두 설득력을 얻는다.

2. 내가 내린 결정과 이유

기술 스택, 데이터 구조, 인증 방식처럼 갈림길이 있던 지점에서 무엇을 골랐고 왜 골랐는지 적는다. AI가 제안한 방식을 받아들였다면 왜 받아들였는지, 거절했다면 왜 거절했는지가 오히려 좋은 재료다. “AI는 상태 관리 라이브러리를 추천했지만, 화면이 세 개뿐이라 기본 상태 관리로 충분하다고 판단했다” 같은 문장 하나가 기능 열 개 나열보다 많은 걸 말해 준다.

3. AI와 나의 역할 분담

어떤 부분에 AI를 썼고, 어떤 부분을 직접 했는지 짧게 나눠 적는다. 예를 들면 반복적인 CRUD 코드와 테스트 초안은 AI로 만들고, 데이터 모델 설계와 권한 처리는 직접 설계하고 검토했다는 식이다. 이 구분이 있으면 읽는 사람이 무엇을 기준으로 질문해야 할지 알게 되고, 면접도 내가 자신 있는 쪽으로 흘러간다.

4. 검증 방법

무엇으로 결과를 확인했는지 적는다. 테스트를 어디까지 썼는지, 직접 어떤 시나리오로 눌러 봤는지, 보안 쪽에서 무엇을 점검했는지 같은 내용이다. 바이브 코딩으로 만든 서비스에서 자주 빠지는 지점은 권한과 데이터 보호다. 예를 들어 Supabase를 썼다면 RLS 설정 점검표처럼 무엇을 확인했는지를 적는 것만으로도 신뢰가 확 달라진다.

5. 실패와 수정 기록

AI가 만든 코드가 어디서 틀렸고 그걸 어떻게 알아챘는지는 포트폴리오에서 가장 강력한 이야기다. 내가 도구를 맹신하지 않고 검토할 줄 안다는 증거이기 때문이다. 출시했는데 아무도 안 쓴 경험처럼 결과가 좋지 않았던 프로젝트도 원인을 분석했다면 충분히 가치가 있다. 실패를 정리하는 방식이 궁금하다면 조용히 실패한 출시 회고를 참고해도 좋다.

6. 지금 동작하는 결과물과 코드

배포 주소, 데모 영상, 저장소 링크 중 최소 하나는 있어야 한다. 링크가 깨져 있으면 앞의 설명이 모두 힘을 잃는다. 제출하기 전에 모든 링크를 로그아웃 상태에서 한 번씩 눌러 보자.

바로 쓰는 프로젝트 설명 틀

프로젝트 하나를 아래 순서로 적으면 위 여섯 가지가 자연스럽게 들어간다.

한 줄 소개: 누구의 어떤 문제를 푸는 무엇인지
배경: 왜 이 문제를 골랐는지, 기존 방식의 불편
주요 결정 2~3개: 선택지, 고른 것, 이유
AI 활용과 직접 한 일: 어디에 어떤 도구를 썼고, 무엇을 직접 설계·검토했는지
검증: 테스트 범위, 확인한 시나리오, 보안 점검
막혔던 지점: 문제, 원인을 찾은 과정, 해결
다시 한다면: 바꾸고 싶은 것과 이유
링크: 배포 주소, 저장소, 데모

예시로 4번은 이렇게 쓸 수 있다. “화면 컴포넌트와 테스트 초안은 Claude Code로 만들었다. 결제 웹훅 처리와 권한 정책은 공식 문서를 보며 직접 설계했고, AI가 만든 코드에서 권한 검사가 빠진 API 두 곳을 찾아 고쳤다.” 이 정도 문장이면 AI를 쓴 사실과 내가 판단한 부분이 함께 보인다. 물론 실제로 한 일만 적어야 한다. 예시 문장을 그대로 베끼면 면접에서 바로 드러난다.

깃허브 저장소와 README 정리법

포트폴리오 링크를 누른 사람이 가장 먼저 보는 곳은 깃허브인 경우가 많다. GitHub는 사용자 이름과 같은 이름의 공개 저장소를 만들고 README.md를 넣으면 프로필 맨 위에 그 내용이 보이게 하는 프로필 README 기능을 제공한다. 여기에 대표 프로젝트 두세 개와 각 프로젝트에서 내가 고민한 지점을 한 줄씩 적어 두면 첫인상이 달라진다.

프로젝트 저장소 쪽에서는 다음을 챙긴다.

README 첫 화면에 무엇을 하는 프로젝트인지, 어떻게 실행하는지 적기
설계 결정이나 AI 활용 범위를 따로 문서로 남기기(예: docs 폴더의 짧은 문서)
커밋 메시지를 “수정”, “update”만 반복하지 않기. 커밋 기록은 작업 과정을 보여 주는 가장 정직한 자료다
AI 에이전트 규칙 파일(AGENTS.md 같은 것)을 썼다면 지우지 말고 남기기. 내가 AI에게 어떤 규칙을 줬는지가 곧 내 기준을 보여 준다
API 키나 비밀번호가 저장소에 올라가 있지 않은지 꼭 확인하기

제출 전 점검표

프로젝트마다 “왜 만들었는지”가 첫 문단에 있는가
내가 내린 결정이 최소 두 개 이상 이유와 함께 적혀 있는가
AI가 한 일과 내가 한 일이 구분돼 있는가
검증 방법이 적혀 있는가
모든 코드에 대해 “이건 왜 이렇게 했나요?”라는 질문에 답할 수 있는가
해 보지 않은 경험이나 부풀린 숫자가 들어가 있지 않은가
링크가 모두 살아 있는가

점검표를 채우다 보면 프로젝트 설명이 길어질 수 있다. 그럴 때는 대표 프로젝트 하나만 자세히 쓰고 나머지는 짧게 줄이는 편이 낫다. 다섯 번째 항목이 가장 중요하다. 스스로 설명하지 못하는 코드가 있다면 포트폴리오에서 빼거나, 시간을 들여 이해한 다음 넣는 게 낫다. AI로 코딩할 때 생기는 숨은 비용에 대해서는 AI 코딩 생산성의 숨은 비용에서 따로 다뤘다.

면접에서 AI 활용 프로젝트를 설명하는 순서

포트폴리오를 잘 고쳐도 면접에서 말이 엉키면 소용이 없다. AI로 만든 프로젝트를 설명할 때는 아래 순서로 말하면 흐름이 깔끔해진다.

문제부터 꺼낸다. “이런 불편이 있어서 만들었다”로 시작하면 듣는 사람이 그다음 이야기를 따라오기 쉽다.
내가 정한 큰 틀을 말한다. 데이터 구조, 화면 흐름, 외부 서비스 연동처럼 프로젝트의 뼈대를 누가 정했는지 분명히 한다.
AI에게 맡긴 범위를 담담하게 말한다. 숨기지도 부풀리지도 않는다. “반복 코드와 테스트 초안은 AI로 만들었다” 정도면 충분하다.
AI가 틀렸던 순간을 하나 든다. 어떤 코드가 왜 문제였고, 어떻게 알아챘는지 말한다. 이 대목에서 검토 능력이 가장 잘 드러난다.
다시 한다면 바꿀 점으로 끝낸다. 스스로 한계를 아는 사람이라는 인상이 남는다.

이 순서로 말하려면 결국 프로젝트를 진행하면서 기록을 남겨 둬야 한다. 작업이 끝난 뒤에 기억을 더듬어 쓰면 판단의 이유가 흐려진다. 작업할 때마다 메모 앱이나 저장소의 문서에 “오늘 AI가 제안한 것, 내가 바꾼 것, 이유”를 한두 줄씩 적어 두면 포트폴리오와 면접 준비가 동시에 된다.

AI를 잘 다룬다는 걸 보여 주고 싶다면

AI 활용 능력 자체를 강점으로 내세우고 싶다면, “AI로 만들었다”보다 훨씬 구체적인 증거를 보여 줄 수 있다. 에이전트에게 준 규칙 파일, 작업을 쪼갠 방식, 생성된 코드를 검사하려고 만든 테스트나 스크립트 같은 것들이다. 앞에서 본 토스뱅크 사례처럼 AI가 규칙을 놓치는 문제를 알아채고 그걸 막는 장치를 직접 만들었다면, 그건 그 자체로 훌륭한 포트폴리오 소재다. 도구를 쓰는 사람과 도구를 다루는 사람의 차이는 바로 이런 데서 드러난다.

자주 묻는 질문

AI로 만든 프로젝트는 아예 빼는 게 나을까?

그럴 필요는 없다. AI를 활용해 짧은 시간에 동작하는 결과물을 만든 건 그 자체로 능력이다. 다만 내가 판단하고 검증한 부분이 드러나도록 설명을 보강해야 한다. 설명할 수 없는 프로젝트만 빼면 된다.

AI를 얼마나 썼는지 비율로 적어야 할까?

비율은 정확하게 재기도 어렵고, 읽는 사람에게 큰 의미도 없다. 퍼센트보다 어떤 부분에 썼고 어떤 부분을 직접 했는지 구체적으로 적는 편이 훨씬 낫다.

코딩 테스트나 과제에서 AI를 써도 될까?

회사마다 다르다. Anthropic처럼 따로 허용한다고 밝히지 않는 한 과제에서 AI를 쓰지 말라고 안내하는 곳도 있다. 안내가 없다면 지원한 회사에 먼저 물어보는 게 가장 안전하다.

바이브 코딩으로 만든 서비스도 포트폴리오가 될까?

된다. 다만 실제 사용자를 받을 수 있는 수준인지 점검한 흔적이 있어야 한다. 배포 구조나 보안 점검을 어떻게 했는지 적어 두면 좋은 재료가 된다. 실서비스 수준으로 다듬는 과정은 바이브 코딩 프로덕션 아키텍처 가이드에 정리했다.

정리하면

포트폴리오에 “AI로 만들었다”만 쓰면 탈락하기 쉬운 이유는 AI를 썼기 때문이 아니다. 그 문장이 읽는 사람이 알고 싶은 것, 즉 내가 무엇을 판단했고 어떻게 검증했는지에 대해 아무것도 말해 주지 않기 때문이다. AI 사용은 숨기지 말고, 역할을 나눠 보여 주자. 왜 만들었는지, 무엇을 골랐는지, 어떻게 확인했는지, 어디서 틀렸는지가 보이는 포트폴리오는 AI를 썼다는 사실을 오히려 장점으로 만든다. 1인 개발과 AI 도구 활용에 관한 다른 글들은 대표 콘텐츠 모음에서 볼 수 있다.