신입 개발자의 포트폴리오를 처음 열었을 때 프로젝트가 세 개 이상이고 사용 기술도 다양하지만, 어떤 역량을 가진 지원자인지 바로 파악하기 어려운 경우가 있습니다. 화면 캡처와 기능 목록은 많아도 왜 이 서비스를 만들었는지, 본인이 맡은 역할은 무엇인지, 구현 과정에서 어떤 문제를 해결했는지가 잘 보이지 않기 때문입니다. 결과물의 분량은 충분하지만 평가자가 확인해야 할 정보의 순서가 정리되지 않은 것입니다.
실제로 백엔드 직무를 준비한 한 지원자는 쇼핑몰, 게시판, 일정관리 서비스까지 세 개의 결과물을 제출했습니다. 그러나 모든 프로젝트가 사용 기술, 기능 목록, 실행 화면 순서로만 구성되어 있었고 오류 처리나 데이터베이스 설계 이유는 빠져 있었습니다. 기술면접에서는 여러 기능 가운데 어떤 부분을 직접 설계했는지 설명하지 못했고, 팀 전체의 성과와 개인의 역할도 구분하지 못했습니다. 프로젝트가 부족한 것이 아니라 지원자의 판단과 행동이 자료 안에서 보이지 않았던 사례입니다.
신입 개발자 포트폴리오는 완성된 서비스를 자랑하는 전시 자료만은 아닙니다. 채용담당자가 프로젝트의 목적과 역할을 빠르게 이해하고, 실무자가 구현 과정에 관해 질문할 수 있도록 근거를 제공해야 합니다. 프로젝트정리, README, 기술면접 준비가 서로 연결되지 않으면 결과물이 많아도 내용이 얕아 보일 수 있습니다. 반대로 익숙한 주제의 프로젝트 하나라도 문제 발견, 선택 기준, 수정 행동, 검증 결과가 명확하면 직무 역량을 구체적으로 보여줄 수 있습니다.
프로젝트정리가 기능 목록에 머물면 개인 역량이 보이지 않습니다
- 서비스 목적과 담당 역할부터 구분해야 합니다
프로젝트를 정리할 때 가장 먼저 사용 기술을 나열하는 경우가 많습니다. 그러나 기술 이름만으로는 지원자가 어떤 문제를 해결하기 위해 해당 도구를 사용했는지 알기 어렵습니다. 프로젝트 첫 부분에는 서비스가 해결하려는 문제, 주요 사용자, 핵심 기능, 본인의 담당 범위를 먼저 제시하는 편이 좋습니다.
팀 프로젝트라면 전체 서비스와 개인 역할을 구분해야 합니다. 팀이 회원가입, 상품, 주문, 결제 기능을 모두 구현했더라도 지원자가 주문 API와 재고 처리를 담당했다면 해당 부분을 중심으로 설명해야 합니다. 다른 팀원의 기능까지 자신의 경험처럼 작성하면 면접에서 구체적인 질문을 받았을 때 답변이 흔들릴 수 있습니다.
- 프로젝트 목적은 거창한 창업 아이디어처럼 작성할 필요가 없습니다. 사용자가 겪는 불편과 이를 어떤 기능으로 줄이려 했는지를 한두 문장으로 설명하면 됩니다. 일정관리 서비스라면 단순한 일정 등록보다 여러 일정의 우선순위와 마감 상태를 한 화면에서 확인하도록 구성했다는 목적이 더 명확합니다.
- 담당 역할은 기능명만 적지 말고 설계와 구현 범위를 함께 보여줘야 합니다. 주문 기능 담당이라는 표현보다 주문 생성 API, 재고 검증, 주문 상태 변경, 오류 응답 설계를 맡았다고 작성하면 실제 기여도를 판단하기 쉬워집니다.
- 백엔드 프로젝트는 기능보다 데이터 흐름이 필요했습니다
백엔드 직무를 준비한 A 씨는 스프링 부트 기반 쇼핑몰 프로젝트를 제출했습니다. 자료에는 회원가입, 로그인, 상품 조회, 장바구니, 주문, 결제 기능이 순서대로 적혀 있었습니다. 하지만 면접관이 주문 요청 이후 데이터베이스에 어떤 순서로 정보가 저장되는지 묻자 컨트롤러, 서비스, 리포지토리를 거쳐 저장된다는 구조만 설명했습니다.
추가 질문은 결제에는 성공했지만 재고 차감에 실패하면 어떻게 처리할 것인지였습니다. A 씨는 해당 상황을 테스트하지 않았고 주문 저장과 재고 변경의 처리 범위도 정리하지 않았습니다. 기능 목록에는 주문과 결제가 모두 완성된 것처럼 보였지만 실패 상황을 고려한 설계는 확인하기 어려웠습니다.
이후 A 씨는 주문 요청, 사용자 인증, 상품 확인, 재고 검증, 주문 저장, 결제 처리, 오류 응답의 흐름을 다시 정리했습니다. 재고가 부족하거나 존재하지 않는 상품을 요청했을 때의 결과도 테스트했습니다. 주문 저장 이후 재고 변경에 실패하면 데이터가 일치하지 않을 수 있다는 점을 확인하고 처리 범위를 수정했습니다.
- 기능을 나열한 기록: 주문과 결제 기능을 구현했습니다.
- 구현 범위를 보여주는 기록: 주문 생성 전 재고를 확인하고 주문 정보와 주문 상세 데이터를 저장하도록 구성했습니다.
- 판단 과정까지 담은 기록: 주문 저장 후 재고 차감에 실패하면 주문 데이터만 남을 수 있는 상황을 확인했습니다. 주문 생성과 재고 변경을 하나의 처리 범위로 조정하고, 재고 부족 예외가 발생했을 때 전체 작업이 되돌아가는지 테스트했습니다.
프로젝트의 기능 수는 달라지지 않았지만 정리 방식은 완전히 바뀌었습니다. 면접관이 질문할 수 있는 지점이 생겼고, 지원자도 자신의 코드와 테스트 결과를 근거로 설명할 수 있게 되었습니다.
- 데이터 결과물은 그래프보다 계산 기준이 먼저였습니다
데이터 분석 직무를 준비한 B 씨는 온라인 쇼핑 데이터를 활용해 재구매율과 고객별 구매금액을 시각화했습니다. 대시보드의 디자인은 깔끔했고 그래프도 다양했지만 재구매 고객을 구분한 조건과 취소 주문 처리 방식은 적혀 있지 않았습니다. 결과 수치는 보였지만 어떻게 계산했는지 재현하기 어려운 자료였습니다.
모의면접에서 첫 구매 후 어느 기간 안에 다시 주문해야 재구매로 판단했는지 질문하자 B 씨는 전체 분석 기간에 추가 주문이 있으면 포함했다고 답했습니다. 같은 날 여러 번 발생한 주문과 취소된 거래도 별도로 처리하지 않았습니다. 시각화 기술은 보여주었지만 지표의 신뢰도를 결정하는 기준이 빠져 있었습니다.
B 씨는 첫 구매일, 추가 주문일, 취소 여부를 나누고 재구매 판정 기간을 30일과 60일로 구분해 다시 계산했습니다. 기간이 길어질수록 비율이 높아지는 특성을 비교하고 다른 서비스와 수치를 비교할 때는 동일한 기준이 필요하다는 한계도 기록했습니다.
- 수정 전 자료는 월별 재구매율이 상승했다는 결과를 강조했습니다. 보완 후에는 데이터 추출 조건, 제외 기준, 계산식, 판정 기간에 따른 차이가 함께 들어갔습니다. 그래프를 만든 기술보다 분석 기준을 결정한 경험이 선명해졌습니다.
- 프로젝트정리는 좋은 결과만 보여주는 과정이 아닙니다. 데이터가 부족했던 부분, 기준에 따라 결과가 달라지는 지점, 해석할 때 주의해야 할 한계를 함께 적어야 결과물의 신뢰도를 높일 수 있습니다.
- 문제와 검증의 순서가 깊이를 만듭니다
익숙한 주제의 프로젝트가 부족해 보이는 이유는 주제가 흔해서만은 아닙니다. 게시판이나 쇼핑몰이라도 입력값 검증, 권한 처리, 동시 요청, 오류 응답, 데이터 일관성을 어떻게 다뤘는지 보여주면 충분히 깊이 있는 자료가 될 수 있습니다. 반대로 독특한 서비스를 만들었더라도 화면과 기술 목록만 있다면 구현 역량을 판단하기 어렵습니다.
프로젝트를 다시 정리할 때는 문제 상황, 원인 확인, 해결 방법, 검증 결과의 순서를 활용할 수 있습니다. 여기에는 성공한 수정만 넣을 필요는 없습니다. 처음 선택한 방법이 예상대로 작동하지 않았던 이유와 다른 방법으로 변경한 판단까지 기록하면 지원자의 사고 과정이 더 구체적으로 드러납니다.
직무에 따라 강조할 내용도 달라야 합니다. 백엔드는 요청과 저장, 인증, 예외 처리의 흐름을 보여주고, 프런트엔드는 상태 변화와 API 실패 시 사용자 경험을 정리해야 합니다. 데이터 분야는 추출 조건과 지표 해석을, QA는 재현 단계와 수정 후 검증을, 인프라는 장애 구간을 좁힌 순서를 중심으로 구성하는 것이 좋습니다.
README가 불친절하면 좋은 프로젝트도 확인하기 어렵습니다
- README는 평가자가 따라가는 안내서입니다
README를 프로젝트 소개 한두 줄과 기술 배지로만 채우는 경우가 있습니다. 하지만 평가자는 코드를 전부 실행하거나 모든 파일을 읽을 시간이 없을 수 있습니다. README만 보더라도 무엇을 만든 프로젝트인지, 어떻게 실행하는지, 어떤 구조로 동작하는지, 지원자가 무엇을 담당했는지를 파악할 수 있어야 합니다.
잘 정리된 README에는 프로젝트 목적, 주요 기능, 사용 기술과 선택 이유, 시스템 구조, 설치와 실행 방법, 환경변수 안내, 담당 역할, 문제해결 사례, 테스트 방법이 포함될 수 있습니다. 모든 항목을 길게 작성하기보다 평가자가 다음 정보를 어디에서 확인할 수 있는지 안내하는 것이 중요합니다.
- 실행 방법은 단순한 설치 명령만 적지 말고 필요한 버전, 환경변수, 데이터베이스 연결, 실행 순서를 함께 알려줘야 합니다. 민감한 인증정보를 그대로 공개하지 않으면서 예시 파일이나 필요한 변수 이름을 제공하는 방식이 좋습니다.
- 주요 기능에는 화면 캡처만 넣기보다 입력과 처리 결과를 함께 보여주는 것이 좋습니다. 백엔드라면 API 요청과 응답 예시를, 프런트엔드라면 정상, 로딩, 실패 상태를, 데이터 프로젝트라면 원본 데이터 조건과 결과 지표를 연결할 수 있습니다.
- 프런트엔드 결과물은 정상 화면만 보여주고 있었습니다
프런트엔드 직무를 준비한 C 씨는 여행 일정관리 서비스를 만들었습니다. README에는 메인 화면, 일정 등록, 일정 수정 화면이 이미지로 정리되어 있었고 사용한 라이브러리도 자세히 나열되어 있었습니다. 그러나 서버 응답이 늦어질 때 표시되는 화면과 일정 저장이 실패했을 때의 처리 방식은 확인할 수 없었습니다.
첫 기술면접에서는 일정 저장 요청 중 사용자가 버튼을 여러 번 누르면 어떻게 되는지 질문받았습니다. C 씨는 정상적으로 저장되는 상황만 테스트했기 때문에 중복 요청 가능성을 설명하지 못했습니다. 저장에 실패한 뒤 입력한 내용이 유지되는지도 확인하지 않았습니다.
면접 이후에는 API 요청 상태를 로딩, 성공, 실패로 나누고 요청 중에는 버튼을 비활성화했습니다. 실패 시에는 사용자가 입력한 일정 내용을 유지하고 오류 원인에 따라 안내 문구를 구분했습니다. README에도 정상 화면만 넣지 않고 로딩, 실패, 재시도 상태를 순서대로 추가했습니다.
- 화면 중심 소개: 일정 등록과 수정 화면을 구현했습니다.
- 사용자 흐름이 포함된 소개: 일정 저장 요청 중에는 중복 제출을 막고 완료 후 목록을 갱신하도록 처리했습니다.
- 실패 대응까지 보여주는 소개: API 요청 중에는 저장 버튼을 비활성화하고 서버 오류가 발생하면 입력값을 유지했습니다. 사용자가 내용을 다시 작성하지 않고 재시도할 수 있도록 상태 흐름을 수정했으며 정상, 로딩, 실패 화면을 README에 비교해 정리했습니다.
C 씨의 자료는 화면 수가 늘어난 것이 아닙니다. 정상적인 기능만 보여주던 소개에 실패 상황과 사용자 판단을 추가하면서 프런트엔드 직무에 필요한 상태 처리 경험이 드러나기 시작했습니다.
- 클라우드 프로젝트는 구축 방법보다 장애 기록이 부족했습니다
클라우드 엔지니어를 준비한 D 씨는 가상 네트워크와 서버를 구성하고 웹 애플리케이션을 배포했습니다. README에는 사용한 클라우드 서비스와 아키텍처 그림이 있었지만 외부에서 서버에 접근하는 경로와 보안 설정의 목적은 설명하지 않았습니다. 실습 도중 SSH 접속 오류도 여러 번 경험했지만 해결된 뒤에는 별도로 기록하지 않았습니다.
모의면접에서 외부 접속이 되지 않을 때 무엇부터 확인할 것인지 묻자 보안그룹을 점검하겠다고 답했습니다. 보안그룹이 정상일 때 다음으로 살펴볼 항목은 설명하지 못했습니다. 서버를 구축한 결과는 있었지만 장애 범위를 좁히는 과정은 준비되지 않았습니다.
D 씨는 동일한 접속 오류를 다시 재현했습니다. 클라이언트 네트워크, 공인 IP, 라우팅, 보안그룹의 인바운드 규칙, 서버 방화벽, SSH 서비스 상태, 인증키 권한 순서로 확인했습니다. 각 단계에서 무엇을 판단하려는지와 나타날 수 있는 오류를 README의 운영 기록에 추가했습니다.
- 처음 작성한 문서는 클라우드 서버 구축과 배포 완료를 강조했습니다. 수정한 문서에는 외부 네트워크부터 서버 내부까지 접속 경로가 추가되었고, 장애 발생 시 확인해야 할 순서도 포함됐습니다.
- 인프라 직무에서는 완성된 구조도뿐 아니라 문제 발생 시 어느 구간부터 확인하는지가 중요합니다. 오류 해결 기록은 실수를 드러내는 내용이 아니라 장애 대응 사고방식을 보여주는 근거가 될 수 있습니다.
- 읽는 순서와 정보의 밀도를 조정해야 합니다
README에 많은 정보를 넣는다고 항상 좋은 것은 아닙니다. 프로젝트 목적보다 설치 명령이 먼저 나오거나, 기술 배지가 화면 대부분을 차지하거나, 긴 회고가 핵심 기능보다 앞에 배치되면 중요한 정보를 찾기 어렵습니다. 평가자가 위에서 아래로 읽으면서 자연스럽게 프로젝트를 이해할 수 있도록 순서를 정해야 합니다.
처음에는 프로젝트한 줄 소개와 핵심 기능을 보여주고, 다음으로 아키텍처와 데이터 흐름, 담당 역할, 기술 선택 이유를 배치할 수 있습니다. 이후 문제해결 사례와 테스트 결과를 보여주고 마지막에 실행 방법과 추가 자료를 안내하는 방식이 가능합니다. 프로젝트의 성격에 따라 실행 방법을 앞에 둘 수도 있지만 정보의 우선순위는 분명해야 합니다.
이미지와 표도 필요한 곳에만 사용해야 합니다. 화면 캡처가 비슷한 기능을 반복해서 보여주거나 코드 전체를 이미지로 넣으면 핵심을 파악하기 어렵습니다. 하나의 이미지가 어떤 판단을 돕는지 확인하고 설명이 필요한 부분에는 짧은 문장을 함께 붙이는 것이 좋습니다.
README는 코드를 대신하는 문서가 아니라 코드를 이해하도록 안내하는 문서입니다. 프로젝트를 처음 보는 사람이 목적과 흐름을 파악하고, 실행하거나 코드를 확인하며, 기술면접에서 질문할 지점까지 찾을 수 있다면 자료의 활용도가 높아집니다.
기술면접과 연결되지 않으면 작성한 경험을 설명하기 어렵습니다
- 모든 문장은 추가 질문을 만들 수 있습니다
포트폴리오에 사용한 기술과 성과를 적으면 면접관은 해당 내용을 근거로 질문할 수 있습니다. 성능을 개선했다고 작성했다면 측정 방법과 개선 전후 수치를 확인할 수 있고, 보안을 강화했다고 적었다면 어떤 위험을 줄였는지 물을 수 있습니다. 근거 없이 강한 표현을 사용하면 추가 질문에서 답변이 끊길 가능성이 큽니다.
자료를 완성한 뒤에는 각 문장 옆에 어떤 질문이 나올 수 있는지 적어 보는 것이 좋습니다. 기술을 선택한 이유, 다른 대안, 구현 과정의 어려움, 실패한 방법, 테스트 기준, 결과의 한계를 설명할 수 있어야 합니다. 답변은 일반적인 정의보다 자신의 코드와 기록에서 출발해야 합니다.
- 데이터베이스 인덱스를 적용했다고 적었다면 조회 조건, 실행 계획, 적용 전후 결과, 쓰기 비용 증가 가능성을 설명할 수 있어야 합니다. 인덱스의 정의만 외우면 해당 프로젝트에서 왜 필요했는지 보여주기 어렵습니다.
- 협업 경험을 강조했다면 팀원과 원활하게 소통했다는 결론보다 의견 차이가 발생한 상황과 합의 기준을 정리해야 합니다. 지원자의 행동과 그로 인해 달라진 결과가 있어야 역할을 판단할 수 있습니다.
- 성능 개선 문장이 백엔드 면접에서 흔들렸습니다
백엔드 직무에 지원한 E 씨는 포트폴리오에 주문 조회 성능을 크게 개선했다고 작성했습니다. 기술면접에서 어떤 데이터와 조건으로 측정했는지 질문받자 정확한 수치를 기억하지 못했고, 인덱스를 적용하면 조회가 빨라진다는 일반적인 설명만 제시했습니다. 성과 문장은 강했지만 이를 뒷받침할 기록이 없었습니다.
면접 이후 E 씨는 주문 데이터 수, 사용자별 조회 조건, 정렬 기준을 다시 확인했습니다. 사용자 ID와 주문 상태를 조건으로 조회할 때 실행 계획이 어떻게 나타나는지 살펴보고 복합 인덱스를 적용하기 전후의 응답 시간을 같은 환경에서 비교했습니다. 데이터 변경 시 추가 비용이 발생할 수 있다는 한계도 함께 정리했습니다.
- 성과만 강조한 표현: 인덱스를 적용해 조회 성능을 크게 개선했습니다.
- 검증 조건을 포함한 표현: 사용자별 주문 목록 조회 쿼리의 실행 계획을 확인하고 조회 조건에 맞는 복합 인덱스를 적용했습니다.
- 면접 질문까지 고려한 표현: 사용자 ID와 주문 상태를 반복적으로 조회하는 패턴을 기준으로 복합 인덱스를 검토했습니다. 동일한 데이터와 요청 조건에서 적용 전후 실행 계획과 응답 시간을 비교했으며, 쓰기 비용을 고려해 모든 칼럼에는 적용하지 않았습니다.
수정된 문장은 처음보다 화려하지 않을 수 있지만 어떤 질문을 받아도 코드와 측정 결과를 근거로 설명할 수 있습니다. 포트폴리오의 신뢰도는 강한 표현보다 검증 가능한 정보에서 만들어집니다.
- QA 지원자는 발견한 오류의 전달 과정을 설명하지 못했습니다
QA 직무에 지원한 F 씨는 프로젝트 소개에 다수의 결함을 발견하고 품질을 개선했다고 작성했습니다. 면접에서는 가장 중요했던 결함과 위험도 판단 기준을 질문받았습니다. F 씨는 회원가입 오류를 발견했다고 답했지만 발생 환경, 재현 절차, 기대 결과, 실제 결과, 수정 후 확인 여부를 순서대로 설명하지 못했습니다.
기존 테스트 자료에는 성공과 실패 여부만 표시되어 있었고 다른 사람이 같은 현상을 재현하는 데 필요한 정보가 부족했습니다. F 씨는 특정 모바일 브라우저에서 휴대전화 인증 후 이전 화면으로 이동하면 인증 상태가 초기화되는 문제를 다시 정리했습니다. 환경과 사전조건을 분리하고 다섯 단계의 재현 절차와 사용자 영향을 기록했습니다.
- 기존 답변은 오류를 찾아 개발팀에 전달했다는 결과에 머물렀습니다. 보완된 답변에는 사용자가 회원가입을 다시 시작해야 하는 영향과 이로 인한 이탈 가능성을 고려해 우선순위를 제안한 과정이 포함됐습니다.
- 수정 배포 이후 동일한 브라우저만 확인하지 않고 다른 모바일 환경과 기존 가입 과정도 테스트했습니다. 발견, 전달, 수정, 재검증의 흐름이 갖춰지면서 QA 업무에 관한 구체적인 면접답변이 만들어졌습니다.
- 포트폴리오와 답변은 같은 근거를 사용해야 합니다
기술면접을 별도의 예상 답안으로 준비하면 프로젝트에 적힌 내용과 실제 답변이 달라질 수 있습니다. 문서에는 주도적으로 설계했다고 적었지만 면접에서는 팀원이 정한 구조를 따라 구현했다고 설명하거나, 성능 개선을 강조했지만 측정 기록은 없는 문제가 생길 수 있습니다. 포트폴리오와 답변의 근거가 일치해야 합니다.
프로젝트별로 핵심 질문을 만들어 보는 것이 좋습니다. 왜 이 주제를 선택했는지, 어떤 역할을 맡았는지, 가장 어려웠던 문제는 무엇이었는지, 왜 해당 기술을 사용했는지, 처음 방법의 한계는 무엇이었는지, 결과를 어떻게 검증했는지를 정리할 수 있습니다. 질문마다 README의 어느 부분과 코드의 어느 위치를 근거로 사용할지도 확인해야 합니다.
면접에서 모든 세부 코드를 기억할 필요는 없습니다. 다만 중요한 선택과 문제해결 과정은 자신의 말로 설명할 수 있어야 합니다. 정확하지 않은 수치를 만들어 내기보다 측정 조건과 확인하지 못한 한계를 솔직하게 구분하는 편이 신뢰를 높일 수 있습니다.
기술면접 준비는 포트폴리오를 완성한 뒤 새롭게 시작되는 작업이 아닙니다. 프로젝트를 정리하고 README에 판단 근거를 남기는 순간부터 답변 재료가 만들어집니다. 자료와 답변이 같은 경험을 가리킬 때 지원자의 역할과 성장 과정을 일관되게 전달할 수 있습니다.
- conclusion
신입 개발자 포트폴리오가 부족해 보이는 이유는 프로젝트 수나 사용 기술이 적어서만은 아닙니다. 서비스 목적, 개인 역할, 문제 상황, 선택 기준, 수정 행동, 검증 결과가 연결되지 않으면 많은 기능을 구현해도 지원자의 역량을 판단하기 어렵습니다. 화면과 기술 이름을 추가하는 것보다 평가자가 어떤 순서로 경험을 이해할지 먼저 생각해야 합니다.
현재 자료를 점검할 때는 첫 화면만 보고도 프로젝트의 목적과 담당 역할을 알 수 있는지 확인해 보는 것이 좋습니다. README에 실행 방법과 데이터 흐름이 있는지, 오류를 해결한 과정이 결과만으로 축약되지 않았는지, 기술 선택 이유와 한계를 설명할 수 있는지도 살펴봐야 합니다. 각 문장에 추가 질문이 들어왔을 때 코드와 테스트 결과를 근거로 답할 수 있는지가 중요한 기준입니다.
실제 포트폴리오를 검토하면 프로젝트가 적어서보다 팀 전체 결과와 개인 경험이 구분되지 않아 약해 보이는 사례가 적지 않습니다. 기능은 많지만 정상 작동만 보여주거나, 성능 개선을 적었지만 측정 조건이 없거나, 협업을 강조했지만 자신의 행동이 빠진 경우도 있습니다. 새로운 결과물을 만들기 전에 기존 프로젝트에서 평가하기 어려운 부분을 찾아야 합니다.
백엔드라면 요청과 저장, 예외 처리의 흐름을 정리하고, 프런트엔드라면 로딩과 실패 상태의 사용자 경험을 보여줄 수 있습니다. 데이터 분야는 추출 조건과 지표 해석을, QA는 재현 단계와 수정 후 검증을, 클라우드는 장애 범위를 좁힌 순서를 기록해야 합니다. 이러한 내용이 README와 기술면접 답변에 같은 근거로 이어질 때 평범했던 프로젝트도 신뢰할 수 있는 취업 자료로 바뀝니다.
