2026 개발자 취업 포트폴리오: AI 시대에 보여줘야 할 프로젝트 기준

• 채용시장 단정 대신 확인 가능한 근거
• 첫 화면에는 목적과 확인 경로
• 기능마다 정상·예외·복구를 묶기
• AI 사용 기록은 맡긴 범위와 수정 이유
• 하나의 결정으로 설명 연습
• 기존 프로젝트를 보완할 순서
• 완성 여부를 확인하는 방법

채용시장 단정 대신 확인 가능한 근거

완성 화면만으로는 어떤 부분을 직접 구현했고 어떤 조건을 확인했는지 알기 어렵습니다. 그래서 이 글은 구현 결과 옆에 판단과 검증 근거를 함께 배치하는 방식을 제안합니다. AI 도구의 사용 여부, 커밋 수, 프로젝트 개수만으로 지원자의 역량을 단정하지 않습니다.

예를 들어 “AI로 만든 쇼핑몰”이라는 소개는 작업 범위를 설명하지 못합니다. 화면 초안을 생성했는지, 데이터 흐름까지 맡겼는지, 오류를 직접 수정했는지 구분해야 합니다. 직접 재현하지 못한 오류나 실제로 측정하지 않은 개선률을 추가하면 문장은 강해 보여도 질문에 답하기 어려워집니다.

첫 화면에는 목적과 확인 경로

위치	담을 내용	상품 검색 프로젝트 예시
첫 문장	사용자와 해결하려는 상황	상품을 여러 조건으로 좁혀 찾는 목록
역할	개인/팀 작업과 본인 범위	개인 학습, 검색 UI와 상태 처리
확인 경로	누를 순서와 기대 결과	검색→정렬→빈 결과→초기화
근거	코드·테스트·이슈 연결	검색 조건 초기화 테스트와 수정 커밋
한계	연결하지 않은 영역	주문·결제·실사용자 성과는 검증 안 함

표의 예시는 가상의 연습 프로젝트입니다. 본인의 사실에 맞게 바꾸세요. README의 설치 안내에는 지원 환경·실행 명령·필요한 설정 이름을 적되, 실제 비밀 값은 포함하지 않습니다. 검토자가 직접 실행하기 어렵다면 공개 데모와 짧은 동작 설명을 함께 제공합니다.

기능마다 정상·예외·복구를 묶기

상품 목록 기능을 보여준다면 카드가 표시되는 장면만 찍지 말고 같은 화면이 달라지는 조건을 보여줍니다. 아래 표는 작은 검색 기능에 적용할 수 있는 검증 계획입니다. 모든 프로젝트에 장바구니나 로그인 기능을 추가하라는 뜻은 아닙니다.

상황	기대 동작	남길 증거
검색 결과 있음	조건을 만족하는 항목만 표시	사용한 가상 데이터와 화면
결과 없음	빈 상태와 초기화 경로 제공	없는 검색어로 실행한 결과
요청 실패	입력 조건 유지·재시도 제공	테스트용 실패 응답과 화면
연속 요청	오래된 응답이 최신 화면을 덮지 않음	응답 순서를 바꾼 검증
키보드 사용	입력·이동·실행 가능	직접 사용한 키와 발견 이슈

관찰 결과와 기대 결과가 다르면 버그 기록으로 남깁니다. “테스트 완료” 한 줄 대신 어떤 조건에서 무엇이 달랐고 어떻게 다시 확인했는지 적으면, 결과와 한계를 동시에 설명할 수 있습니다.

AI 사용 기록은 맡긴 범위와 수정 이유

작업: 검색 폼 초안 작성
AI에 제공한 자료: 가상 상품 필드와 공개된 요구사항
받은 제안: 검색어와 필터 결과를 각각 상태로 저장
직접 검토: 결과가 원본 데이터·검색어로 계산 가능함을 확인
최종 결정: 검색어만 상태로 두고 결과는 계산
확인: 검색 변경·초기화·빈 결과 동작을 실제 실행
남은 범위: 대용량 데이터의 성능은 측정하지 않음

위 문장은 작성 예시이며 실제 수행 결과가 아닙니다. 자신의 변경 내역으로 대체한 뒤, 수정한 코드와 연결해야 합니다. AI에게 검토를 한 번 더 요청했다는 사실만으로 테스트를 실행한 것이 되지는 않습니다.

도구 사용 허용 범위는 제출 과제나 조직의 안내를 먼저 따릅니다. 허용되지 않은 자료를 제공하거나 맡기지 않은 일을 자신의 행동으로 적지 않습니다. 구현 도움을 받은 범위와 최종 판단을 구분하면 이후 기술 질문에도 설명이 이어집니다.

하나의 결정으로 설명 연습

“상태 관리가 복잡해서 라이브러리를 사용했다”에서 멈추지 말고, 어떤 상태를 어디서 쓰는지 적어 봅니다. 검색어는 현재 화면에만 필요한지, 공유 URL에 남겨야 하는지, 서버가 원본을 관리하는 데이터인지부터 구분합니다.

설명 질문	좋은 답에 필요한 내용
왜 선택했나요?	당시 제약과 해결할 문제
다른 방법은요?	비교한 대안 한 가지와 제외한 이유
직접 한 일은요?	파일·함수·결정 범위
어떻게 확인했나요?	입력 조건·기대 결과·실제 결과
아직 안 된 부분은요?	확인하지 못한 환경과 다음 작업

본인이 작성한 설명을 읽으며 위 다섯 질문에 답해 보세요. 일반적인 도구 장점만 반복된다면 자신의 상황과 연결되는 문장이 부족한 것입니다. 기술 설명은 학습 로드맵의 해당 단계와 대조해 보완할 수 있습니다.

기존 프로젝트를 보완할 순서

• 첫 실행이 막히는 오류와 깨진 링크부터 해결합니다.
• 중요한 사용자 흐름 하나에 정상·실패·복구 상태를 추가합니다.
• 판단 근거가 남지 않은 구현 한 가지를 코드와 함께 설명합니다.
• README에서 설치 방법과 확인 경로를 따라 해 봅니다.
• 이력서에는 가장 설명할 수 있는 변화 2~3개만 남깁니다.

동일한 설명을 여러 프로젝트에 복사하지 마세요. 한 프로젝트는 데이터 요청 안정성, 다른 프로젝트는 폼 접근성처럼 실제 구현 범위가 다를 때 각각의 근거를 보여주면 됩니다. 없는 차이를 만들기 위해 새 기능을 추가할 필요는 없습니다.

완성 여부를 확인하는 방법

다른 사람이 배포 링크에서 목표 기능을 찾고, 문서에서 본인 역할을 이해하며, 코드에서 그 설명의 위치를 확인할 수 있으면 제출 자료의 기본 연결이 갖춰진 것입니다. 이는 문서의 확인 기준이며 채용 평가나 합격 결과를 보장하지 않습니다.

공식 자료와 확인 범위

공식 자료 확인일: 2026년 9월 13일. 아래 문서는 기술·문서 작성·측정 기능의 근거입니다. 학습 순서와 작성 예시는 이 글의 편집 제안이며 채용 합격률이나 회사의 평가 기준을 입증하는 통계가 아닙니다.

• GitHub README 안내
• React 컴포넌트와 상태 설계
• W3C 접근성 기초 점검

다음 학습

• 이력서로 압축하는 방법
• 지원 준비와 조건 비교
• 과제 대비 연습