포트폴리오 완성 단계에서 이력서·프로젝트 소개·근거 자료는 어떻게 묶나요?
마지막 목표는 서류 수를 늘리는 것이 아니라 프로젝트명·유형·기간·역할·기술·선택·구현·검증·결과·한계를 일관되게 맞추는 것입니다. TaskFlow는 개인·학습 프로젝트이며, 본인이 실제 수행하고 확인한 단계만 최종 사례에 포함합니다. 선택 과정을 모두 거쳤다고 쓰거나 다른 분기의 기술을 한 저장소에 전부 사용했다고 합치지 않습니다.
공식 문서 참고: MIT: 포트폴리오에서 목표·본인 기여·결과와 과정 보여 주기 · GitHub: README에 프로젝트 목적·시작 방법·관련 문서 연결
TaskFlow 포트폴리오 완성: 이력서 · GitHub · 케이스 스터디 · 면접 자료 연결
커리어·포트폴리오 · 19 / 19
이력서·프로젝트 소개·근거 자료를 서로 일치하는 하나의 지원 패키지로 묶습니다. 상단에서는 가상 자료로 연결 기준을 연습하고, 하단에서는 앞선 과정의 문서를 모아 제출 목록을 완성합니다.
상단에서는 이 주제의 판단 기준을 가상 사례와 완성 예시로 연습합니다. 이전 회차의 문서는 필요 없습니다. 하단의 TaskFlow 누적 적용에서는 같은 기준으로 자신의 포트폴리오 자료를 이어서 만듭니다. TaskFlow는 학습용 프로젝트 사례이며 예시 경력·성과를 자신의 사실로 사용하지 않습니다.
이번 글에서 배우는 내용
- 기본 이력서 원본
- 공고별 맞춤 이력서
- 경력기술서
- 포트폴리오 사이트
- 대표 프로젝트 케이스 스터디
- GitHub Profile README
- 대표 repository README
- 프로젝트 증거 카드
- 코딩테스트 복기 기록
- 과제전형 제출 체크리스트
- 기술면접 노트
- 인성면접 경험 카드
- 오퍼 검토 체크리스트
- 기술 블로그 대표 글
선수 지식
이력서·포트폴리오·근거 문서의 역할을 알면 됩니다. 독립 실습은 아래 가상 자료만으로 할 수 있고, 누적 과정은 앞선 18개 문서를 사용합니다.
목차
- 한 사실 원본에서 제출 문서를 파생하기
- 독립 실습과 완성 예시
- 자주 발생하는 문제와 해결
- 학습 완료 체크리스트
- 19개 누적 문서의 연결
- 10분 제출 검수와 다음 갱신
- TaskFlow 누적 적용
- 완료 체크포인트
- 다음 학습
한 사실 원본에서 제출 문서를 파생하기
마지막 목표는 서류 수를 늘리는 것이 아니라 프로젝트명·유형·기간·역할·기술·선택·구현·검증·결과·한계를 일관되게 맞추는 것입니다. TaskFlow는 개인·학습 프로젝트이며, 본인이 실제 수행하고 확인한 단계만 최종 사례에 포함합니다. 선택 과정을 모두 거쳤다고 쓰거나 다른 분기의 기술을 한 저장소에 전부 사용했다고 합치지 않습니다.
사실 원본은 증거 기록과 케이스 스터디로 관리합니다. 이력서는 짧게, 사이트는 탐색하기 쉽게, README는 실행·한계를 찾기 쉽게, 면접 노트는 설명 깊이를 바꾸어 파생합니다. 문장 길이는 달라도 사실은 같아야 합니다.
지원처가 요구한 자료만 제출합니다. 맞춤 이력서·허용된 포트폴리오·요청된 경험서는 제출 후보이고, 지원 결과 기록·개인 면접 회고·오퍼 비교·보상 메모는 개인 보관용입니다. career 폴더 전체를 ZIP으로 보내지 않습니다. 공개용 근거에도 비밀값·고객 자료·비공개 면접 문제를 넣지 않습니다.
독립 실습과 완성 예시
가상 E-DEMO-01에는 개인 CSS 배치 수정, 같은 브라우저·100% 배율·390px와1280px 확인, 다른 환경 미확인이 적혀 있습니다. 그런데 이력서는 ‘팀 운영 성능 50% 향상’, 면접 노트는 ‘모든 기기 접근성 통과’, 사이트는 ‘개인 배치 수정’이라고 되어 있습니다. 어떤 문서를 어떻게 고쳐야 할까요?
풀이와 판단 근거
| 문서 | 발견한 불일치 | 완성 교정안 |
|---|---|---|
| 이력서 | 팀·운영·성능50% 근거 없음 | 개인 입력 폼의 좁은 화면 배치를 수정하고 지정한 두 폭에서 확인 |
| 면접 노트 | 모든 기기·접근성 통과 근거 없음 | 같은 브라우저 두 폭에서 넘침 확인, 다른 기기·보조기술 미확인 |
| 사이트 | 범위는 맞지만 조건 부족 | 개인 배치 수정과 두 폭 조건·증거·한계 연결 |
다수 문서에 반복된 주장이 사실이 되는 것은 아닙니다. 사실 원본의 범위를 기준으로 파생 문서를 고칩니다. 근거가 새로 생기면 원본을 먼저 갱신하고 나머지 문서도 같은 버전으로 맞춥니다.
자주 발생하는 문제와 해결
- 각 주장 옆에 실제 확인 가능한 자료를 연결합니다.
- 예
- 구현 화면 → screenshot
- 변경 과정 → commit / PR
- 품질 검증 → test / CI
- 실제 공개 상태 → deployment URL
- 기술 선택 → 비교 기록
- 오류 해결 → issue / debugging log
- 개선 전후 → Before/After
- 근거가 없는 수치나 효과는 최종 문서에서 제거합니다.
개인 프로젝트와 실무 경험은 분리합니다. 팀 작업은 내가 맡은 범위와 팀 전체 결과를 따로 쓰고, 근거가 없는 수치·기간·실행 결과는 추가하지 않습니다. 비공개 자료는 익명화만으로 공개 권한이 생기지 않으므로 허용 범위를 먼저 확인합니다.
학습 완료 체크리스트
- 파생 문서의 주장과 사실 원본을 대조하여 오류를 수정했습니다.
- 19개 누적 문서의 이름과 연결이 일치합니다.
- 제출 후보와 개인 보관 자료를 구분했습니다.
- 문서 연습 완료를 실제 제출·합격으로 표현하지 않았습니다.
19개 누적 문서의 연결
기준 폴더는 처음부터 사용한 career/입니다. 폴더를 새로 옮기지 않고 다음 문서를 유지합니다. 이 목록은 독자가 작성할 문서 구조이며 다운로드 파일 묶음이 제공되었다는 뜻은 아닙니다.
career/
01 skills-matrix.md
02 frontend-roadmap.md
03 job-matrix.md
04 gap-plan.md
05 project-shortlist.md
06 evidence-log.md
07 case-study.md
08 github-readmes.md
09 portfolio-structure.md
10 resume-bullets.md
11 career-description.md
12 tailored-application.md
13 coding-test-plan.md
14 take-home-plan.md
15 technical-interview.md
16 behavioral-stories.md
17 offer-checklist.md
18 blog-visibility.md
19 final-package.md
06 evidence-log.md → 07 case-study.md를 사실 기준으로 삼고, 08~12 제출 문서와 15~16 설명 문안을 대조합니다. 13~14는 전형 준비, 17은 개인 오퍼 판단, 18은 기술 기록 계획이며 모든 파일을 지원처에 제출하지 않습니다.
10분 제출 검수와 다음 갱신
- 공고 핵심 업무와 제출 형식을 확인합니다.
- 맞춤 이력서 버전과 대표 프로젝트 순서를 맞춥니다.
- 요청된 문서만 선택하고 개인 보상·지원 기록은 제외합니다.
- 모든 외부 링크를 로그인하지 않은 상태에서도 확인합니다.
- PDF 줄바꿈·텍스트·페이지·링크를 확인합니다.
- GitHub 공개 범위와 README 계약을 확인합니다.
- 포트폴리오를 모바일·키보드로 확인합니다.
- 개인정보·고객 자료·비밀값이 없는지 확인합니다.
- 파일명과 제출본 버전을 고정합니다.
- 실제 제출한 경우에만 제출 시각과 버전을 지원 기록에 남깁니다.
10분은 이미 검토한 문서의 마지막 확인을 위한 편집 제안이며 전체 검증 시간을 보장하지 않습니다. 오류가 있으면 제출을 서두르지 말고 해당 근거부터 고칩니다.
가상 지원 기록의 완성 예시: 대상=가상 공고 X, 문서=X-v01, 단계=문안 연습, 실제 제출일=해당 없음, 실제 질문·결과=해당 없음, 관찰한 개선점=이력서의 성능 수치 삭제 및 개인 프로젝트 표기 통일. 피드백이 없는 결과의 원인은 추측으로 적지 않습니다.
선택 실습: 포트폴리오 문서 이어 만들기
이 선택 연습은 TaskFlow 개발 경험을 이력서·포트폴리오 자료로 정리하는 과정입니다. 예시 경험은 자신의 실제 근거로 바꿔 작성합니다.
이번에는 career/final-package.md 문서를 작성·보완합니다.
TaskFlow 누적 적용
시작 방법: 과정대로 이어가는 독자는 이전 글: 개발자 기술 블로그 상위 노출 전략: 검색 유입과 글 홍보 기준의 기록을 유지하고 이번 문서를 추가·보완합니다. 이번 결과물은 career/final-package.md입니다. 중간부터 읽는다면 아래 작성 표와 완성 예시를 새 문서에 옮겨 현재 보유한 자료부터 연결합니다. 없는 근거나 미작성 문서는 그대로 표시하며, 이전 과정을 이수한 것처럼 채우지 않습니다.
이전 체크포인트: career-step-18-blog-visibility. 직전 문서 career/blog-visibility.md와 앞선 자료를 유지합니다.
현재 결과물 상태: 앞선 18편의 career 문서를 보관한 상태에서 이번 문서를 추가합니다. 기존 파일은 유지하며 이번 추가·수정 파일은 career/final-package.md입니다. 중간부터 읽는 독자는 위 독립 예시로 작성법을 익힌 뒤 직전 문서의 필요한 사실을 가져오면 됩니다.
아래는 작성 방법을 보여 주는 가상 완성 문서입니다. 실제 독자의 실행·취업·협업 이력을 증명하지 않습니다. TaskFlow는 개인·학습 프로젝트이며 본인이 수행한 체크포인트와 저장소 상태만 반영하세요. 예시의 미확인은 작성 누락이 아니라 확인되지 않은 사실을 표시한 완성 상태입니다.
Before → 적용 → After
Before: career 폴더의 모든 문서와 개인 오퍼 메모를 묶어 보내고 서로 다른 성과 문장을 유지한다.
적용: 관련 사실과 근거 범위를 대조하고, 이번 회차의 기준으로 문장을 수정합니다.
After: E-DEMO-01의 개인 CSS 범위로 주장을 통일하고 제출용과 개인 보관용을 구분한다. 요청된 자료만 골라 공개 상태·링크·PDF·버전을 확인한다.
전체 파일·코드 보기
career/final-package.md
# 최종 지원 패키지 — 가상 작성 예시
기준: 개인·학습 TaskFlow의 E-DEMO-01
대표 문제: 입력 폼의 좁은 화면 넘침
역할: CSS 배치 대안 선택과 수정
가상 확인: 같은 브라우저·입력·100% 배율, 390px·1280px
미확인: 다른 브라우저·실기기·보조기술
제외 주장: 팀 운영·전면 접근성 통과·성능50%
제출 후보:
- 맞춤 이력서: resume-bullets.md에서 검증된 내용으로 파생
- 포트폴리오: portfolio-structure.md의 구조와 공개 허용 자료
- 케이스 스터디: case-study.md
- 프로젝트 경험서: 요청 시 career-description.md
- GitHub·블로그: 실제 공개 확인한 주소만 제공
개인 보관:
- job-matrix.md / gap-plan.md / tailored-application.md의 지원 기록
- coding-test-plan.md / take-home-plan.md
- technical-interview.md / behavioral-stories.md의 비공개 메모
- offer-checklist.md
정합성 확인: 이력서·사이트·면접 문안의 개인/역할/두 폭/미확인 범위를 일치시킴
실제 자료 상태: 본인 자료·주소·PDF 확인 전
결정: 교육용 패키지 설계 완료, 실제 제출 준비 완료와 구분
실제 지원 상태: 제출·연락·계약 체결 없음
결과 확인
저장한 문서를 다시 열고 위 학습 완료 체크리스트를 적용합니다. 이전 문서의 프로젝트 유형·역할·검증 상태와 충돌하면 사실 원본부터 수정합니다. 예시 문장의 작성 완료와 실제 프로젝트 검증 완료는 다른 상태입니다.
직접 작성할 결과물: career/final-package.md 제출 목록
질문: 같은 프로젝트가 이력서·사이트·GitHub·면접 노트에서 다른 사실로 쓰이지 않았나요?
작성 예시(가상): 가상 TaskFlow 패키지: 개인 프로젝트, 두 폭에서 레이아웃 수정, 다른 브라우저 미확인이라는 문장을 모든 제출물에 동일하게 둡니다. 실제 링크·PDF·저장소는 독자 자료로 교체합니다.
스스로 점검: 각 항목의 제출 대상·최종 수정일·공개 권한·링크 응답·역할·검증 상태를 대조합니다. 교육용 예시는 실제 지원 완료로 표기하지 않습니다.
다음 학습: 이후 실제 지원 결과를 기록하고 새 근거가 생길 때만 원본과 파생 문서를 함께 갱신합니다.
완료 체크포인트
career-step-19-final-package
다음 학습
실제 지원 → 관찰한 전형 결과 기록 → 필요한 학습 → 새 근거 수집 → 지원 패키지 갱신을 반복합니다. 피드백 없는 불합격 이유는 추측으로 확정하지 않습니다.
이 글이 도움이 되었나요?
읽음 기록
읽음 — / 전체 19개 · 필수 19개
새 글 받아보기
RSS 리더에서 BlogFlow의 새 글을 확인할 수 있습니다.