프로젝트 경험 정리: 화면 · commit · 테스트 · 성과 근거 모으기

··설명 약 7분·작성: 해비·블로그 소개

프로젝트 경험을 설명하기 전에 어떤 근거 자료부터 준비해야 하나요?

화면 캡처는 특정 화면 상태, commit은 변경 내용, PR은 논의와 검토 기록, 테스트 로그는 그 환경에서 수행한 검증, 배포 URL은 확인 당시 접근 상태를 보여 줍니다. 각각 입증하는 범위가 다릅니다. commit이 있다는 이유만으로 테스트 통과나 팀 협업이 입증되지는 않습니다.

적용 조건·범위: '테스트를 추가했다'와 '회귀가 줄었다'도 다릅니다. 전자는 코드와 실행 기록으로 확인할 수 있지만 후자는 같은 조건의 전후 결함 자료가 필요합니다. 성능 비교는 기기·브라우저·데이터·측정 절차를 맞추고 여러 실행의 편차도 남깁니다. 미측정이면 수치를 쓰지 않습니다.

공식 문서 참고: Pro Git: 커밋 이력에서 작성 정보와 변경 내용 확인 · GitHub Actions: 워크플로 실행 상태·실패 단계·실행 로그 확인

프로젝트 경험 정리: 화면 · commit · 테스트 · 성과 근거 모으기

프로젝트 경험 정리 근거를 모으는 방법 주제 일러스트

커리어·포트폴리오 · 6 / 19

기억에 의존하지 않고 프로젝트 설명에 사용할 근거 자료를 먼저 수집합니다.

상단에서는 이 주제의 판단 기준을 가상 사례와 완성 예시로 연습합니다. 이전 회차의 문서는 필요 없습니다. 하단의 TaskFlow 누적 적용에서는 같은 기준으로 자신의 포트폴리오 자료를 이어서 만듭니다. TaskFlow는 학습용 프로젝트 사례이며 예시 경력·성과를 자신의 사실로 사용하지 않습니다.

이번 글에서 배우는 내용

  • evidence log 개념
  • 화면 캡처와 실제 동작 근거
  • Git commit / PR / issue 근거
  • 테스트 결과와 CI 기록
  • 배포 URL과 운영 상태
  • 성능·접근성·오류 개선 전후 근거
  • 기술 선택 문서와 비교 실험
  • 개인 기여와 팀 결과 구분
  • 공개 금지 정보와 익명화 기준

선수 지식

코드·화면·문서가 주장과 어떤 관계인지 이해하면 됩니다. Git 명령을 새로 실행할 필요는 없고 기존 기록을 읽는 실습입니다.

목차

  1. 주장을 지지하는 증거의 범위
  2. 독립 실습과 완성 예시
  3. 자주 발생하는 문제와 해결
  4. 학습 완료 체크리스트
  5. TaskFlow 누적 적용
  6. 완료 체크포인트
  7. 다음 학습

주장을 지지하는 증거의 범위

화면 캡처는 특정 화면 상태, commit은 변경 내용, PR은 논의와 검토 기록, 테스트 로그는 그 환경에서 수행한 검증, 배포 URL은 확인 당시 접근 상태를 보여 줍니다. 각각 입증하는 범위가 다릅니다. commit이 있다는 이유만으로 테스트 통과나 팀 협업이 입증되지는 않습니다.

‘테스트를 추가했다’와 ‘회귀가 줄었다’도 다릅니다. 전자는 코드와 실행 기록으로 확인할 수 있지만 후자는 같은 조건의 전후 결함 자료가 필요합니다. 성능 비교는 기기·브라우저·데이터·측정 절차를 맞추고 여러 실행의 편차도 남깁니다. 미측정이면 수치를 쓰지 않습니다.

증거 카드에는 주장·자료 위치·대상 버전·확인 방법·관찰 결과·본인 역할·한계·공개 가능 범위를 적습니다. 실제 주소나 파일이 없으면 가짜 링크를 만들지 말고 수집 전이라고 기록합니다. 회사 자료는 익명화 전에 공개 권한을 확인합니다.

독립 실습과 완성 예시

‘모든 기기에서 정상이며 회귀 오류가 줄었다’는 문장에 모바일 캡처 1장과 테스트 코드만 붙어 있습니다. 과한 주장을 낮추고 필요한 후속 확인을 적어 보세요.

풀이와 판단 근거

완성 답안: ‘해당 모바일 화면 상태의 캡처를 남겼고 테스트 코드를 작성했다. 다른 기기 동작, 테스트 실행 통과, 회귀 감소는 아직 확인하지 않았다.’

이후 실제 실행 로그가 확보되면 ‘해당 버전·환경에서 지정한 검사를 실행했다’까지 확장할 수 있습니다. 결과가 좋아 보여도 검증 범위를 넘어 일반화하지 않습니다.

완성된 가상 증거 카드 E-DEMO-01

아래 관찰과 결과는 문서 작성법을 위한 가상 조건이며 실제 테스트 로그가 아닙니다.

  • 대상: 개인 TaskFlow의 작업 입력 폼, 가상 수정 전·후 두 상태
  • 환경: 같은 데스크톱 브라우저, 화면 폭 390px와 1280px, 배율 100%, 같은 긴 입력 문구
  • 수정 전 관찰: 390px에서 입력 칸과 추가 버튼이 한 줄을 유지해 버튼 일부가 영역 밖으로 나감. 1280px에서는 보임.
  • 본인 행동: 좁은 폭에서는 입력 줄을 세로 배치하고 버튼이 컨테이너 폭 안에 머물도록 CSS를 수정했다고 가정.
  • 수정 후 가상 결과: 두 폭에서 버튼과 입력 칸이 영역 안에 보임. 두 폭에서 같은 입력으로 다시 확인했다고 가정.
  • 허용할 문장: ‘개인 TaskFlow 입력 폼의 좁은 화면 배치를 수정하고, 지정한 두 폭에서 가로 넘침이 사라진 것을 확인했다.’
  • 한계: 다른 브라우저·실기기·화면낭독기·모든 문구 길이는 미확인. 성능·생산성·회귀 감소는 측정하지 않음.
  • 자료 표기: E-DEMO-01은 교육용 ID이며 실제 파일·commit·URL이 제공되었다는 뜻이 아님.

자주 발생하는 문제와 해결

  • 나중에 기억날 것이라 생각
  • 수치만 적고 측정 방법이 없음
  • 팀 결과를 개인 성과로 표현
  • 고객/회사 내부 자료를 그대로 공개

개인 프로젝트와 실무 경험은 분리합니다. 팀 작업은 내가 맡은 범위와 팀 전체 결과를 따로 쓰고, 근거가 없는 수치·기간·실행 결과는 추가하지 않습니다. 비공개 자료는 익명화만으로 공개 권한이 생기지 않으므로 허용 범위를 먼저 확인합니다.

학습 완료 체크리스트

  • 자료가 증명하는 범위와 주장 범위가 일치합니다.
  • 실행 전·실패·성공·미측정을 구분했습니다.
  • 증거의 버전과 공개 범위를 기록했습니다.
선택 실습: 포트폴리오 문서 이어 만들기

이 선택 연습은 TaskFlow 개발 경험을 이력서·포트폴리오 자료로 정리하는 과정입니다. 예시 경험은 자신의 실제 근거로 바꿔 작성합니다.

이번에는 career/evidence-log.md 문서를 작성·보완합니다.

TaskFlow 누적 적용

시작 방법: 과정대로 이어가는 독자는 이전 글: 2026 개발자 취업 포트폴리오: AI 시대에 보여줘야 할 프로젝트 기준의 기록을 유지하고 이번 문서를 추가·보완합니다. 이번 결과물은 career/evidence-log.md입니다. 중간부터 읽는다면 아래 작성 표와 완성 예시를 새 문서에 옮겨 현재 보유한 자료부터 연결합니다. 없는 근거나 미작성 문서는 그대로 표시하며, 이전 과정을 이수한 것처럼 채우지 않습니다.

이전 체크포인트: career-step-05-project-shortlist. 직전 문서 career/project-shortlist.md와 앞선 자료를 유지합니다.

현재 결과물 상태: 앞선 5편의 career 문서를 보관한 상태에서 이번 문서를 추가합니다. 기존 파일은 유지하며 이번 추가·수정 파일은 career/evidence-log.md입니다. 중간부터 읽는 독자는 위 독립 예시로 작성법을 익힌 뒤 직전 문서의 필요한 사실을 가져오면 됩니다.

아래는 작성 방법을 보여 주는 가상 완성 문서입니다. 실제 독자의 실행·취업·협업 이력을 증명하지 않습니다. TaskFlow는 개인·학습 프로젝트이며 본인이 수행한 체크포인트와 저장소 상태만 반영하세요. 예시의 미확인은 작성 누락이 아니라 확인되지 않은 사실을 표시한 완성 상태입니다.

Before → 적용 → After

Before: TaskFlow 오류를 크게 줄였고 모든 기기에서 안정적으로 동작한다.

적용: 관련 사실과 근거 범위를 대조하고, 이번 회차의 기준으로 문장을 수정합니다.

After: 현재 수집한 자료가 지지하는 화면·버전·검증 범위까지만 쓴다. 실행 로그와 전후 결함 자료가 없으므로 자동 테스트 통과나 회귀 감소를 주장하지 않는다.

전체 파일·코드 보기

career/evidence-log.md

# TaskFlow 증거 기록 — 가상 작성 예시
증거 ID: E-DEMO-01 (교육용, 실제 실행 기록 아님)
프로젝트 유형: 개인·학습 프로젝트
대상: 작업 입력 폼의 좁은 화면 배치
환경: 같은 데스크톱 브라우저, 390px·1280px, 배율 100%, 같은 긴 입력 문구
Before: 390px에서 추가 버튼 일부가 컨테이너 밖으로 나감
본인 행동: 좁은 폭에서 입력 줄을 세로 배치하는 CSS 수정
After: 두 폭에서 입력 칸과 버튼이 영역 안에 보였다는 가상 관찰
허용 주장: 지정한 두 폭에서 가로 넘침을 수정하고 재확인
근거 위치: E-DEMO-01 교육용 서술; 실제 제출 시 본인 자료와 버전을 연결해야 함
미확인: 다른 브라우저·실기기·보조기술
측정하지 않음: 성능 향상·생산성·회귀 감소
공개 범위: 개인 샘플 데이터만 사용한다는 가정

결과 확인

저장한 문서를 다시 열고 위 학습 완료 체크리스트를 적용합니다. 이전 문서의 프로젝트 유형·역할·검증 상태와 충돌하면 사실 원본부터 수정합니다. 예시 문장의 작성 완료와 실제 프로젝트 검증 완료는 다른 상태입니다.

직접 작성할 결과물: career/evidence-log.md 증거 카드

질문: ‘개선했다’는 문장에 어떤 비교 자료가 있어야 하나요?

작성 예시(가상): 가상 E-DEMO-01: 같은 브라우저·입력에서 390px과 1280px의 가로 넘침을 비교한 기록. 다른 브라우저·실기기·성능 개선은 미확인으로 남깁니다.

스스로 점검: 주장마다 증거 경로, 생성일, 본인 기여, 검증 환경, 공개 가능 여부를 적습니다. 스크린샷만으로 동작·접근성·인과 효과를 증명하지 않습니다.

다음 학습: 07편에서는 확인한 카드만 케이스 스터디 문장의 근거로 인용합니다.

완료 체크포인트

career-step-06-evidence-log

다음 학습

07편 「개발자 포트폴리오 케이스 스터디 작성법: 문제 · 역할 · 선택 · 결과」로 이어집니다. 이번 문서의 사실과 미확인 항목을 다음 회차 입력으로 사용합니다.

이 글이 도움이 되었나요?

조회 중

읽음 기록

읽음 — / 전체 19개 · 필수 19개

이 글을 쓴 해비

웹사이트를 제작·운영하고, 개인 서비스와 자동화·AI 도구를 만듭니다. 직접 만들며 배운 내용과 문제 해결 과정을 BlogFlow에 기록합니다.

새 글 받아보기

RSS 리더에서 BlogFlow의 새 글을 확인할 수 있습니다.

RSS 피드 구독하기

댓글 남기기