IT취업 포트폴리오를 검토할 때 프로젝트 수와 사용 기술은 충분하지만 지원자가 직접 한 일이 잘 보이지 않는 경우가 있습니다. 팀에서 쇼핑몰을 만들었고 회원가입과 주문 기능을 구현했다는 설명은 있지만, 어떤 기능을 맡았는지와 개발 중 발생한 문제를 어떻게 해결했는지는 빠져 있습니다. 이 상태에서는 결과물의 규모가 커도 개인의 실력을 판단하기 어렵습니다.
좋은 포트폴리오는 완성된 작품을 모아두는 자료가 아닙니다. 목표 직무와 관련된 역할, 기술을 사용한 이유, 오류를 확인하고 수정한 과정, 수정 후 검증 결과를 보여주는 취업 자료입니다. 프로젝트 경험을 이런 기준으로 정리하면 서류에서 실력을 증명할 수 있고, 기술면접과 협업 질문에 활용할 답변 근거도 함께 만들 수 있습니다.
실력증명은 프로젝트 개수보다 개인의 역할에서 시작합니다
- 완성 화면과 기술 목록만으로는 실력을 판단하기 어렵습니다
프로젝트 첫 화면에 사용 기술의 로고를 크게 배치하고 구현 기능을 길게 나열하는 준비생이 많습니다. 이 정보는 어떤 결과물을 만들었는지 알려주지만 지원자가 각 기술을 어디에 사용했고 어느 수준까지 이해하는지는 보여주지 못합니다.
리액트를 사용했다면 화면을 구성 요소로 나눈 기준과 상태를 관리한 위치가 있어야 합니다. 스프링을 사용했다면 요청이 검증과 비즈니스 로직, 데이터 저장을 거쳐 처리되는 흐름을 설명해야 합니다. SQL을 사용했다면 조회문을 작성했다는 사실보다 어떤 조건으로 데이터를 추출하고 결과를 검증했는지가 나타나야 합니다.
- 팀 프로젝트에서는 전체 서비스와 개인의 담당 범위를 분리해야 합니다. 팀이 완성한 모든 기능을 자신의 경험처럼 소개하기보다 직접 구현한 부분과 협업을 통해 결정한 부분을 구분하는 편이 신뢰도를 높입니다.
- 기술스택에는 이름만 적지 말고 사용한 위치와 목적을 연결해야 합니다. 익숙해서 선택한 기술이라면 과장된 이유를 만들기보다 적용 후 확인한 장점과 한계를 함께 적는 것이 좋습니다.
- 완성한 기능마다 같은 분량을 배치할 필요는 없습니다. 목표 직무와 가장 가까우면서 자신이 문제를 발견하고 개선한 기능을 대표 경험으로 깊게 보여주는 편이 효과적입니다.
- 이미지 업로드 기능을 개선한 프런트엔드 사례
프런트엔드 개발자를 준비한 지원자는 프로필 이미지 업로드 기능을 구현했습니다. 파일을 선택하면 화면에 미리 보기가 나타나고 저장 버튼을 누르면 서버로 전송됐습니다. 초기 자료에는 이미지 선택과 미리 보기, 업로드 성공 화면이 정리되어 있었습니다.
하지만 크기가 큰 이미지를 선택하면 화면이 오랫동안 멈춘 것처럼 보였고, 이미지가 아닌 파일도 선택할 수 있었습니다. 업로드에 실패해도 기존 미리 보기는 그대로 남아 사용자가 저장에 성공했다고 오해할 수 있었습니다. 지원자는 처음에 서버 속도 문제라고 생각했지만 파일 크기와 형식, 요청 상태를 화면에서 관리하지 않은 것이 주요 원인이었습니다.
파일을 선택하는 단계에서 형식과 크기를 확인하고 기준을 초과하면 전송 전에 안내하도록 수정했습니다. 업로드가 진행되는 동안에는 진행 상태를 표시하고 버튼을 반복해서 누르지 못하게 했습니다. 요청이 실패하면 미리 보기와 서버 저장 상태가 다를 수 있다는 점을 안내하고 다시 선택할 수 있도록 처리했습니다.
- 기능 중심 설명: 프로필 이미지 업로드와 미리 보기 기능을 구현했습니다.
- 역할이 보이는 설명: 파일 선택과 형식 검증, 미리 보기, 업로드 진행 상태와 실패 안내를 담당했습니다.
- 실력 근거가 담긴 설명: 큰 파일과 잘못된 형식에서도 요청이 전송되는 문제를 발견해 화면에서 크기와 형식을 먼저 검증했습니다. 업로드 중 반복 요청을 막고 실패 시 저장 상태를 안내한 뒤 정상 파일, 용량 초과, 형식 오류, 서버 실패 상황을 다시 테스트했습니다.
같은 기능이지만 마지막 설명에는 사용자 입력과 요청 상태를 처리한 경험이 나타납니다. 완성 화면만 보여주던 결과물이 예외 상황을 이해하고 개선한 프런트엔드 취업 자료로 바뀐 것입니다.
- 평균 주문금액을 다시 계산한 데이터 분석 사례
데이터 분석 직무를 준비한 지원자는 쇼핑몰 주문 자료를 이용해 고객별 평균 주문금액을 계산했습니다. 처음에는 전체 결제금액을 주문 건수로 나누고 고객 등급별 결과를 그래프로 표현했습니다. 대시보드는 완성됐지만 취소와 부분 환불, 테스트 결제가 포함되어 있었습니다.
일부 주문에는 상품이 여러 개 포함되어 있어 주문번호가 중복됐고, 테이블의 행 개수를 주문 건수로 사용하면서 실제보다 분모가 커지는 문제도 있었습니다. 지원자는 처음에 평균을 계산하는 SQL 함수가 단순해서 분석 결과가 부족해 보인다고 생각했지만, 실제 보완점은 주문 한 건을 구분하는 기준과 결제 상태였습니다.
이후 주문번호를 기준으로 건수를 다시 계산하고 취소와 테스트 결제를 제외했습니다. 부분 환불은 최종 결제금액을 반영했으며, 평균값이 일부 고액 주문에 크게 영향을 받는지 확인하기 위해 중앙값도 함께 비교했습니다. 고객 등급별 주문 수가 크게 다른 점도 분석의 한계로 정리했습니다.
- 결과 나열형 정리: SQL을 이용해 고객 등급별 평균 주문금액을 분석했습니다.
- 계산 기준이 보이는 정리: 주문번호를 한 건의 기준으로 삼고 취소와 테스트 결제를 제외해 평균을 다시 계산했습니다.
- 분석 판단이 담긴 정리: 상품 단위 행을 주문 건수로 계산해 평균값이 달라지는 문제를 발견했습니다. 주문번호 기준으로 집계한 뒤 고액 주문의 영향을 확인하기 위해 중앙값을 비교하고 고객 등급별 표본 수의 차이도 함께 제시했습니다.
이 사례에서 실력을 증명한 부분은 복잡한 함수를 사용한 것이 아닙니다. 데이터 구조를 확인하고 계산 기준의 오류를 발견하며 결과를 다시 검증한 과정입니다. 분석 포트폴리오에서는 그래프의 완성도만큼 데이터의 포함 범위와 지표 정의가 중요합니다.
- 대표 프로젝트는 목표 직무에 맞게 선택해야 합니다
다양한 기술을 경험했다는 이유로 모든 결과물을 같은 비중으로 넣으면 지원 방향이 흐려질 수 있습니다. 백엔드 지원 자료 첫 부분에 디자인 프로젝트가 나오거나 데이터 분석 지원서에 화면 기능만 강조되면 채용 담당자가 어떤 역할을 원하는지 판단하기 어렵습니다.
대표 결과물은 규모가 가장 큰 프로젝트가 아니라 목표 직무의 업무를 가장 잘 보여주는 프로젝트로 선택해야 합니다. 화면 개발자는 입력과 상태 변화, API 실패 처리가 있는 결과물을, 서버 개발자는 요청과 데이터 처리, 인증과 예외 대응이 있는 결과물을 우선할 수 있습니다.
데이터 직무라면 지표 정의와 추출 조건, 해석이 있는 분석을 앞에 배치해야 합니다. QA 지원자는 테스트 설계와 오류 재현, 수정 후 재검증 기록을 중심으로 구성할 수 있습니다. 같은 프로젝트라도 지원 분야에 따라 설명의 순서와 강조점을 바꾸면 개인의 역량이 더 선명하게 나타납니다.
문제해결 기록은 결과물을 직무 경험으로 바꿉니다
- 오류를 해결했어도 과정이 없으면 면접에서 활용하기 어렵습니다
프로젝트를 진행하면서 여러 오류를 해결하지만 대부분 최종 코드만 남기고 확인 과정은 지우게 됩니다. 시간이 지나면 오류가 있었다는 사실은 기억해도 어떤 조건에서 발생했고 무엇을 확인했는지는 잊기 쉽습니다. 면접에서 가장 어려웠던 문제를 질문받으면 검색해서 수정했다는 짧은 답변으로 끝나는 이유입니다.
문제해결 기록은 모든 시행착오를 길게 작성하는 개발 일지가 아닙니다. 문제를 재현한 조건과 기대 결과, 실제 결과, 처음 확인한 정보, 선택한 수정 방법, 재검증 결과를 남기는 과정입니다.
- 오류가 발생하면 바로 코드를 바꾸기보다 발생 조건을 먼저 고정해야 합니다. 특정 입력값과 사용자 권한, 요청 순서, 실행 환경 중 무엇이 달라질 때 문제가 나타나는지 확인해야 합니다.
- 추측한 원인과 실제로 확인한 원인을 구분해야 합니다. 첫 예상이 틀렸더라도 어떤 로그와 테스트를 통해 다른 가능성을 제외했는지 설명하면 문제에 접근한 방식이 드러납니다.
- 수정 후에는 정상 기능만 실행하지 말고 문제가 발생했던 조건과 인접 기능을 다시 점검해야 합니다. 변경으로 인해 다른 기능에 새로운 오류가 생기지 않았는지도 확인할 필요가 있습니다.
- 예약 좌석이 중복 배정된 백엔드 사례
서버 개발을 준비한 지원자는 공연 좌석 예약 API를 구현했습니다. 한 명씩 예약할 때는 좌석 상태가 정상적으로 변경됐지만 두 사용자가 거의 같은 시간에 같은 좌석을 선택하면 모두 예약에 성공하는 문제가 발생했습니다.
처음에는 예약 전 좌석 상태를 조회하고 이미 예약된 경우 오류를 반환하고 있었기 때문에 문제가 없다고 판단했습니다. 하지만 두 요청이 비슷한 시각에 들어오면 모두 예약 가능한 상태를 조회한 뒤 각각 예약 정보를 저장할 수 있었습니다. 단순한 조회와 저장 사이에 다른 요청이 개입하는 상황을 고려하지 않은 것입니다.
지원자는 동시에 요청을 보내는 테스트를 만들고 요청 시각과 조회 및 저장 로그를 비교했습니다. 이후 좌석 상태가 예약 가능할 때만 변경되도록 데이터베이스 처리 방식을 수정하고, 한 요청이 성공하면 다른 요청에는 이미 예약된 좌석이라는 응답을 반환하도록 했습니다. 동시 요청 수를 바꾸어 반복 테스트하고 예약 정보와 좌석 상태가 일치하는지도 확인했습니다.
- 기능 완성 중심 설명: 공연 좌석 조회와 예약 기능을 구현했습니다.
- 문제 상황이 포함된 설명: 여러 사용자가 같은 좌석을 동시에 선택하면 중복 예약되는 문제를 발견하고 데이터 처리 방식을 수정했습니다.
- 검증 과정이 담긴 설명: 두 요청이 모두 예약 가능 상태를 조회한 뒤 저장되는 순서를 로그로 확인했습니다. 좌석 상태가 변경되지 않은 경우에만 예약이 완료되도록 처리하고 동시 요청 테스트를 반복해 하나의 예약만 성공하는지 검증했습니다.
이 경험은 좌석 예약 기능을 만들었다는 결과를 넘어 동시 요청과 데이터 일관성을 고민한 사례가 됐습니다. README에는 정상 예약 화면뿐 아니라 문제 발생 조건과 처리 전후 결과, 아직 검토해야 할 취소 및 결제 흐름까지 정리할 수 있습니다.
- 할인 쿠폰이 두 번 적용된 QA 사례
QA 직무를 준비한 지원자는 쇼핑몰 결제 기능을 테스트하면서 특정 순서로 쿠폰을 적용하면 할인금액이 두 번 반영되는 문제를 발견했습니다. 쿠폰을 선택하고 결제 단계로 이동한 뒤 이전 화면으로 돌아와 같은 쿠폰을 다시 선택하면 최종 금액에서 할인이 중복됐습니다.
처음에는 쿠폰 버튼을 여러 번 누른 것이 원인이라고 생각했습니다. 그러나 반복 클릭을 막아도 화면을 이동했다가 돌아오는 상황에서는 같은 문제가 발생했습니다. 지원자는 장바구니 상품과 쿠폰 종류, 화면 이동 순서, 로그인 상태를 나누어 재현 조건을 확인했습니다.
문제는 화면 이동 후 기존 할인 상태가 유지된 상황에서 같은 쿠폰 금액이 다시 더해지는 것이었습니다. 지원자는 사전 조건과 재현 단계, 기대 결과, 실제 결과, 결제금액 변화를 기록해 개발 담당자에게 전달했습니다. 수정 후에는 같은 쿠폰 재적용뿐 아니라 다른 쿠폰으로 변경하기, 쿠폰 취소하기, 상품 수량 변경하기도 다시 검증했습니다.
- 발견 중심 설명: 결제 과정에서 쿠폰 할인이 중복 적용되는 오류를 발견했습니다.
- 재현 과정이 보이는 설명: 쿠폰 적용 후 이전 화면으로 이동해 같은 쿠폰을 다시 선택하면 할인금액이 두 번 반영되는 조건을 확인했습니다.
- 직무 역량이 담긴 설명: 로그인 상태와 상품 수량, 쿠폰 종류, 화면 이동 순서를 나누어 재현했습니다. 수정 후에는 동일 쿠폰 재선택과 다른 쿠폰 변경, 적용 취소, 상품 수량 변경을 다시 확인해 회귀 테스트 항목으로 남겼습니다.
오류를 발견했다는 사실만으로는 QA 업무의 깊이를 보여주기 어렵습니다. 다른 사람이 같은 현상을 확인할 수 있도록 조건을 정리하고, 수정 후 영향받을 수 있는 범위까지 재검증해야 직무 경험으로 활용할 수 있습니다.
- 저장 공간 부족을 추적한 인프라 사례
클라우드 환경에 개인 서비스를 배포한 지원자는 어느 날 서버에 접속할 수 있지만 애플리케이션이 정상적으로 실행되지 않는 문제를 만났습니다. 처음에는 코드 배포가 잘못됐다고 생각해 이전 버전으로 되돌렸지만 같은 현상이 반복됐습니다.
애플리케이션 로그를 확인하려 했으나 새로운 기록이 생성되지 않았고, 시스템 상태를 점검하면서 디스크 사용량이 가득 찬 사실을 발견했습니다. 테스트 과정에서 생성된 로그 파일이 정리되지 않고 계속 쌓인 것이 원인이었습니다.
지원자는 불필요한 로그를 정리해 서비스를 복구하고 파일별 사용량을 확인했습니다. 로그 보관 기간과 파일 크기 기준을 정하고 일정한 주기로 오래된 기록이 정리되도록 설정했습니다. 이후 테스트 로그를 생성하면서 저장 공간의 변화와 서비스 상태를 다시 확인했습니다.
- 초기 자료에는 클라우드 서버에 서비스를 배포했다는 결과만 있었습니다. 장애가 발생했을 때 코드 문제라고 추측하고 배포를 되돌린 과정까지만 남아 있었습니다.
- 보완된 자료에는 애플리케이션 상태와 시스템 자원, 디스크 사용량을 순서대로 확인한 과정이 추가됐습니다. 처음 추정한 원인과 실제 원인이 달랐던 이유도 나타났습니다.
- 최종 정리에는 서비스 복구뿐 아니라 로그 보관과 점검 기준을 추가한 내용이 포함됐습니다. 일회성 해결에서 같은 문제가 반복되지 않도록 운영 방식을 개선한 경험으로 바뀌었습니다.
- 해결 사례는 한계를 포함할 때 더 신뢰할 수 있습니다
포트폴리오에서 자신의 방법이 모든 상황을 해결한 것처럼 작성하면 후속 질문에서 답변이 흔들릴 수 있습니다. 테스트한 환경과 확인한 범위를 구체적으로 밝히고 아직 검토하지 못한 부분을 구분하는 것이 좋습니다.
좌석 중복 예약을 막았더라도 결제 실패 후 좌석을 다시 열어주는 과정은 별도의 문제일 수 있습니다. 파일 업로드의 크기를 제한했더라도 느린 네트워크와 서버 저장 실패를 모두 해결한 것은 아닐 수 있습니다. 자신이 확인한 범위와 남은 과제를 나누면 경험을 과장하지 않으면서도 개선 방향을 보여줄 수 있습니다.
신입 지원자의 문제해결 경험은 완벽한 기술 해답을 제시하는 데 목적이 있지 않습니다. 문제를 발견하고 근거를 수집하며, 현재 조건에서 적절한 방법을 적용하고, 결과를 검증한 과정을 보여주는 것이 핵심입니다.
면접연결은 기록한 경험을 질문에 맞게 재구성하는 과정입니다
- 포트폴리오와 면접 답변이 서로 다른 자료가 되어서는 안 됩니다
포트폴리오를 제출한 뒤 기술면접을 별도로 준비하는 사람이 많습니다. 예상 질문의 모범 답변을 외우지만 자신의 프로젝트와 연결하지 못하면 정의를 말한 뒤 답변이 짧아집니다. 면접관은 제출 자료를 바탕으로 왜 해당 방법을 선택했는지와 다른 방법은 검토했는지를 질문할 수 있습니다.
README에 적은 문제와 해결 과정은 기술면접의 답변 재료가 되어야 합니다. 하나의 경험을 상황, 자신의 역할, 확인한 문제, 선택한 행동, 검증 결과, 남은 한계로 나누면 여러 질문에 활용할 수 있습니다.
- 기술 질문에는 개념의 정의만 말하지 말고 프로젝트에서 필요했던 이유와 적용 위치를 연결합니다. 직접 사용하지 않은 부분은 아는 범위와 추가로 확인할 내용을 구분해야 합니다.
- 문제해결 질문에는 가장 어려워 보이는 기술보다 원인을 체계적으로 좁힌 경험을 선택하는 것이 좋습니다. 어떤 정보를 확인했고 잘못된 추측을 어떻게 수정했는지 보여줄 수 있어야 합니다.
- 협업 질문에는 원활하게 소통했다는 결론보다 서로 다르게 이해한 기준과 이를 조정한 과정이 필요합니다. 문서와 테스트를 이용해 합의한 경험이 있다면 구체적인 근거가 됩니다.
- 파일 처리 오류를 기술면접 답변으로 바꾼 사례
백엔드 지원자는 게시글 첨부파일 기능에서 한글 파일명이 깨지는 문제를 해결했습니다. 포트폴리오에는 파일 업로드와 다운로드 기능을 구현했다고만 적혀 있었고, 면접 연습에서도 인코딩을 수정해 해결했다고 짧게 답했습니다.
기존 기록을 다시 살펴보니 파일은 정상적으로 저장됐지만 다운로드 응답의 파일명 처리 과정에서 일부 브라우저에서 문자가 깨졌습니다. 지원자는 저장된 파일명과 응답 헤더, 브라우저별 결과를 비교했습니다. 파일명에 공백과 한글, 특수문자가 포함된 경우를 나누어 테스트하고 응답에 전달하는 값을 수정했습니다.
- 기능 중심 답변: 게시글에 파일 업로드와 다운로드 기능을 구현했습니다.
- 원인이 포함된 답변: 한글 파일명이 일부 브라우저에서 깨지는 문제를 발견하고 저장된 이름과 다운로드 응답값을 비교했습니다.
- 면접에 활용할 답변: 서버에는 파일명이 정상적으로 저장됐지만 다운로드 응답의 파일명 처리에서 문제가 발생한다는 점을 확인했습니다. 한글과 공백, 특수문자가 포함된 파일을 브라우저별로 테스트하고 응답값을 수정한 뒤 다시 검증했습니다.
이 답변은 파일 기능을 만들었다는 사실보다 문제 발생 위치를 구분한 과정에 초점이 있습니다. 면접관이 저장 방식과 파일명 중복 처리, 보안 문제를 추가로 질문하더라도 자신이 구현한 범위와 남은 과제를 구분해 설명할 수 있습니다.
- API 응답 기준을 정리한 협업 사례
팀 프로젝트에서 프런트엔드 담당자는 모든 요청 실패를 같은 안내 문구로 표시하고 있었습니다. 백엔드에서는 데이터 없음과 인증 실패, 권한 부족을 서로 다른 방식으로 반환했지만 응답 구조가 일관되지 않아 화면에서 구분하기 어려웠습니다.
처음에는 화면에서 메시지만 바꾸면 되는 문제라고 생각했습니다. 그러나 실제 응답을 비교하면서 서버와 화면이 오류 기준을 서로 다르게 이해하고 있다는 점을 확인했습니다. 팀원들은 오류 유형과 상태 코드, 내부 오류 식별값, 사용자에게 보여줄 메시지를 나누어 정리했습니다.
백엔드에서는 공통된 응답 형식을 적용하고 API 문서에 실패 예시를 추가했습니다. 프런트엔드에서는 각 상황에 맞는 안내와 이동 경로를 연결했습니다. 이후 삭제된 데이터 조회와 로그인 만료, 권한 부족, 서버 오류 상황을 함께 테스트했습니다.
- 협업 사실만 담긴 답변: 프런트엔드 개발자와 API를 연동하며 원활하게 소통했습니다.
- 문제 상황이 포함된 답변: 오류 응답 형식이 일정하지 않아 화면에서 실패 원인을 구분하지 못하는 문제를 발견했습니다.
- 조율 과정이 담긴 답변: 실제 응답을 비교해 데이터 없음과 인증 실패, 권한 부족을 구분하고 공통 오류 형식을 제안했습니다. API 문서에 실패 응답을 추가한 뒤 담당자와 각 상황을 함께 테스트했습니다.
하나의 경험이 API 설계 질문, 협업 질문, 오류 처리 질문에 모두 활용될 수 있습니다. 중요한 것은 답변마다 새로운 사례를 만드는 것이 아니라 질문의 의도에 맞춰 같은 경험의 강조점을 바꾸는 것입니다.
- 프로젝트마다 예상 질문을 미리 만들어야 합니다
포트폴리오를 완성한 뒤에는 각 대표 프로젝트에서 질문받을 내용을 작성해 보는 것이 좋습니다. 기술을 선택한 이유, 가장 어려웠던 문제, 데이터 구조를 정한 기준, 테스트 방법, 협업 중 변경한 내용, 다시 진행한다면 개선할 부분을 중심으로 정리할 수 있습니다.
답변은 글로만 작성하지 말고 소리 내어 말해 봐야 합니다. 배경 설명이 길어져 자신의 행동이 늦게 나오지는 않는지, 팀 전체의 성과를 개인 역할처럼 말하고 있지는 않은지 확인해야 합니다. 첫 문장에서 결론을 전달하고 구체적인 사례와 검증 결과를 이어가는 방식이 이해하기 쉽습니다.
포트폴리오와 면접준비가 연결되면 예상하지 못한 질문에도 대응하기 쉬워집니다. 자신의 프로젝트를 기능 이름이 아니라 문제와 판단, 결과로 이해하고 있기 때문입니다. 제출 자료의 모든 문장은 실제 질문을 받았을 때 자신의 말로 설명할 수 있어야 합니다.
- conclusion
IT취업 포트폴리오는 프로젝트를 많이 모아두는 자료가 아닙니다. 지원자가 어떤 역할을 맡았고, 기술을 어디에 사용했으며, 발생한 문제를 어떻게 해결했는지를 보여주는 실력의 근거입니다. 완성 화면과 기능 목록만으로는 확인하기 어려운 판단 과정을 기록해야 면접에서도 활용할 수 있습니다.
현재 자신의 자료는 다음 내용을 중심으로 점검할 수 있습니다.
- 대표 프로젝트가 목표 직무와 연결되는지 확인해야 합니다. 팀 전체 결과와 개인 역할을 구분하고, 사용 기술마다 적용한 위치와 목적을 설명할 수 있어야 실력증명 자료가 됩니다.
- 오류를 해결했다는 결과만 적지 말고 발생 조건과 원인을 좁힌 과정, 선택한 방법, 수정 후 재검증한 내용을 남겨야 합니다. 처음 예상한 원인과 실제 원인이 달랐다면 그 차이도 문제해결 방식을 보여주는 근거가 됩니다.
- 각 경험을 기술 질문과 협업 질문, 개선 질문에 맞춰 말해 봐야 합니다. README에 적은 내용과 면접 답변이 연결되어야 후속 질문에서도 자신이 확인한 범위와 남은 한계를 구분할 수 있습니다.
실제 포트폴리오를 검토하면 경험이 부족해서보다 이미 수행한 일을 기능 이름으로만 정리해 강점이 보이지 않는 경우가 많습니다. 이미지 업로드 실패, 좌석 중복 예약, 잘못 계산한 평균값, 쿠폰 중복 적용처럼 프로젝트에서 지나쳤던 장면을 다시 살펴보면 구체적인 답변 재료를 찾을 수 있습니다.
개인의 역할은 실력증명의 근거가 되고, 오류를 추적한 기록은 문제해결 경험이 되며, 선택과 검증을 정리한 내용은 면접 답변으로 이어집니다. 좋은 포트폴리오는 완벽한 서비스를 보여주는 문서가 아니라 자신이 기술을 이용해 문제를 확인하고 개선한 과정을 채용 담당자가 이해할 수 있도록 전달하는 자료입니다.
