취업용 GitHub는 프로젝트 근거를 확인할 수 있도록 어떻게 정리하나요?
Profile README는 누구이며 어떤 작업을 볼지 안내하고, 저장소 README는 그 프로젝트의 목적·실행·검증·한계를 안내합니다. profile의 pinned 항목은 대표 저장소나 gist를 빠르게 찾게 합니다. 채용 평가를 보장하는 장식이 아닙니다.
적용 조건·범위: GitHub 계정과 저장소의 차이를 이해하면 됩니다. 계정이 없어도 로컬 README 초안을 작성할 수 있으며 공개 업로드는 이 글의 완료 조건이 아닙니다.
본문 근거: Profile README 공식 안내 · 고정 항목 공식 안내
취업용 GitHub 정리: Profile README · 저장소 README · pinned repository

커리어·포트폴리오 · 8 / 19
GitHub를 단순 코드 저장 공간이 아니라 프로젝트 근거를 빠르게 확인할 수 있는 공개 프로필로 정리합니다.
상단에서는 이 주제의 판단 기준을 가상 사례와 완성 예시로 연습합니다. 이전 회차의 문서는 필요 없습니다. 하단의 TaskFlow 누적 적용에서는 같은 기준으로 자신의 포트폴리오 자료를 이어서 만듭니다. TaskFlow는 학습용 프로젝트 사례이며 예시 경력·성과를 자신의 사실로 사용하지 않습니다.
이번 글에서 배우는 내용
- Profile README 역할
- GitHub profile의 pinned repositories
- 저장소 README 기본 구조
- 프로젝트 목적·실행 방법·기술 선택·검증·링크
- repository description/topics
- demo URL과 screenshot
- issue/PR/history가 보여 주는 작업 과정
- 불필요한 generated file·secret·임시 파일 정리
- archived/private repository 표기 기준
- README 장식보다 탐색성과 근거를 우선
선수 지식
GitHub 계정과 저장소의 차이를 이해하면 됩니다. 계정이 없어도 로컬 README 초안을 작성할 수 있으며 공개 업로드는 이 글의 완료 조건이 아닙니다.
목차
프로필과 저장소 README의 역할
Profile README는 누구이며 어떤 작업을 볼지 안내하고, 저장소 README는 그 프로젝트의 목적·실행·검증·한계를 안내합니다. profile의 pinned 항목은 대표 저장소나 gist를 빠르게 찾게 합니다. 채용 평가를 보장하는 장식이 아닙니다.
GitHub 공식 문서에 따르면 사용자명과 같은 이름의 공개 저장소, 루트의 내용 있는 README.md가 있어야 Profile README가 표시됩니다. 관리형 사용자 계정에서는 이 기능을 사용할 수 없습니다. 프로필의 Customize your pins에서 저장소와 gist를 합해 최대 6개를 선택하고 Save pins로 저장합니다. 꼭 최대 개수를 채울 필요는 없습니다. Profile README 공식 안내, 고정 항목 공식 안내.
저장소 description/topics는 주제를 간단히 표현하고, demo와 캡처는 현재 동작·촬영 상태를 구분합니다. archived는 유지보수 상태를 설명하며 private 저장소는 방문자가 볼 수 있다고 안내하지 않습니다. 생성 파일은 프로젝트 정책에 따라 관리하고 비밀값을 단순히 화면에서 지웠다고 과거 이력까지 안전하다고 단정하지 않습니다.
독립 실습과 완성 예시
가상 저장소의 README에는 배지와 기술 이름만 있고 실행·검증 상태가 없습니다. 독자가 목적과 현재 상태를 바로 이해하도록 소개를 다시 써 보세요.
풀이와 판단 근거
완성 소개 예시: ‘TaskFlow는 입력과 상태 흐름을 학습하는 개인 프로젝트입니다. 현재 공개용 README를 작성 중이며 이 문서에는 실제 저장소 실행을 확인한 명령만 추가합니다. 데모와 테스트 결과는 확인 전이므로 제공하지 않습니다. 설계 판단은 케이스 스터디, 검증 자료는 증거 기록에서 구분해 관리합니다.’
실제 저장소에 적용할 때는 package.json의 스크립트와 lockfile을 읽어 패키지 매니저·설치·실행·검증 명령을 기록합니다. 존재하지 않는 npm test를 관성적으로 넣지 않습니다. 새 환경에서 재현하지 않았다면 그 한계를 표시합니다.
실행 안내의 완성 예시
가상 저장소의 제공 계약이 ‘Node.js 24, pnpm 11.19.0, pnpm-lock.yaml, dev·lint·build 스크립트, test 스크립트 없음’이라고 주어졌다고 가정합니다. 이 조건을 확인한 README는 다음처럼 작성합니다. 이 명령을 이번 글에서 실제 실행했다는 뜻은 아닙니다.
환경: Node.js 24 / pnpm 11.19.0
설치: pnpm install --frozen-lockfile
로컬 확인: pnpm dev
확인 주소: 터미널이 출력한 로컬 주소
정적 검사: pnpm lint
빌드: pnpm build
자동 테스트: test 스크립트가 없어 제공하지 않음
명령 실행 결과: 이 문서 예시에서는 실행하지 않음
독자는 자기 저장소의 계약이 다르면 명령도 바꿔야 합니다. build 성공은 접근성·실사용자 동작의 전체 검증을 뜻하지 않습니다.
자주 발생하는 문제와 해결
- 배지가 목적 설명을 가리면 소개를 먼저 둡니다.
- README에 없는 명령을 추측해 적지 말고 실제 스크립트를 확인합니다.
- 비공개 저장소와 미확인 demo를 누구나 볼 수 있는 근거로 안내하지 않습니다.
개인 프로젝트와 실무 경험은 분리합니다. 팀 작업은 내가 맡은 범위와 팀 전체 결과를 따로 쓰고, 근거가 없는 수치·기간·실행 결과는 추가하지 않습니다. 비공개 자료는 익명화만으로 공개 권한이 생기지 않으므로 허용 범위를 먼저 확인합니다.
학습 완료 체크리스트
- Profile README와 저장소 README의 목적을 구분했습니다.
- 사용자명 저장소 조건과 고정 항목의 역할을 이해했습니다.
- 실제 실행 확인 전 명령을 통과한 것처럼 적지 않았습니다.
선택 실습: 포트폴리오 문서 이어 만들기
이 선택 연습은 TaskFlow 개발 경험을 이력서·포트폴리오 자료로 정리하는 과정입니다. 예시 경험은 자신의 실제 근거로 바꿔 작성합니다.
이번에는 career/github-readmes.md 문서를 작성·보완합니다.
TaskFlow 누적 적용
시작 방법: 과정대로 이어가는 독자는 이전 글: 개발자 포트폴리오 케이스 스터디 작성법: 문제 · 역할 · 선택 · 결과의 기록을 유지하고 이번 문서를 추가·보완합니다. 이번 결과물은 career/github-readmes.md입니다. 중간부터 읽는다면 아래 작성 표와 완성 예시를 새 문서에 옮겨 현재 보유한 자료부터 연결합니다. 없는 근거나 미작성 문서는 그대로 표시하며, 이전 과정을 이수한 것처럼 채우지 않습니다.
이전 체크포인트: career-step-07-case-study. 직전 문서 career/case-study.md와 앞선 자료를 유지합니다.
현재 결과물 상태: 앞선 7편의 career 문서를 보관한 상태에서 이번 문서를 추가합니다. 기존 파일은 유지하며 이번 추가·수정 파일은 career/github-readmes.md입니다. 중간부터 읽는 독자는 위 독립 예시로 작성법을 익힌 뒤 직전 문서의 필요한 사실을 가져오면 됩니다.
아래는 작성 방법을 보여 주는 가상 완성 문서입니다. 실제 독자의 실행·취업·협업 이력을 증명하지 않습니다. TaskFlow는 개인·학습 프로젝트이며 본인이 수행한 체크포인트와 저장소 상태만 반영하세요. 예시의 미확인은 작성 누락이 아니라 확인되지 않은 사실을 표시한 완성 상태입니다.
Before → 적용 → After
Before: 기술 배지 20개와 실행 여부를 모르는 demo 링크를 붙인다.
적용: 관련 사실과 근거 범위를 대조하고, 이번 회차의 기준으로 문장을 수정합니다.
After: 개인 학습 프로젝트라는 소개와 확인된 실행·검증 범위를 먼저 안내한다. 열리지 않거나 아직 만들지 않은 주소는 링크로 제공하지 않는다.
전체 파일·코드 보기
career/github-readmes.md
# GitHub README 초안 묶음 — 가상 작성 예시
## Profile README 문안
개인 프로젝트로 화면·상태·검증 기록을 학습합니다.
대표 후보는 TaskFlow이며 본인 판단과 확인 가능한 근거를 정리 중입니다.
회사 운영·팀 협업 경력으로 소개하지 않습니다.
공개 링크는 권한과 접근 확인 후 실제 주소를 연결합니다.
## TaskFlow 저장소 README 문안
목적: 입력과 상태 흐름을 설명하는 개인 학습
주요 내용: 본인이 구현한 범위만 기능 목록에 반영
기술 선택: case-study.md의 대안과 제약 설명
가상 환경 계약: Node.js 24 / pnpm 11.19.0 / pnpm-lock.yaml
설치·실행: pnpm install --frozen-lockfile → pnpm dev
검사 명령: pnpm lint / pnpm build
자동 테스트: 가상 계약에 test 스크립트 없음
검증 상태: 실행 결과 미확인, 통과 주장 없음
데모: 이 문서 실습에서는 제공하지 않음
자료 연결 계획: evidence-log.md와 case-study.md
한계: 실제 저장소용 README로 제출하기 전 명령·주소 검증 필요
## 고정 후보
TaskFlow 1개 우선 검토. 공개 권한 확인 전 실제 고정 작업은 하지 않음.
결과 확인
저장한 문서를 다시 열고 위 학습 완료 체크리스트를 적용합니다. 이전 문서의 프로젝트 유형·역할·검증 상태와 충돌하면 사실 원본부터 수정합니다. 예시 문장의 작성 완료와 실제 프로젝트 검증 완료는 다른 상태입니다.
직접 작성할 결과물: career/github-readmes.md 저장소 점검표
질문: 처음 보는 채용 담당자가 저장소를 열어 프로젝트를 재현할 수 있나요?
작성 예시(가상): Profile README에는 역할·대표 저장소 링크를, TaskFlow README에는 목표·실행 방법·예시 화면·검증 범위·알려진 문제를 적습니다. 고정 저장소는 실제 공개 가능한 대표 작업만 선택합니다.
스스로 점검: 개인 프로필과 저장소의 링크를 각각 열고 실행 명령, 환경 변수 예시, 비밀값 노출 여부를 확인합니다. GitHub의 프로필 README·고정 항목 기능은 공식 문서를 기준으로 점검합니다.
다음 학습: 09편에서는 같은 프로젝트 정보를 사이트 홈·목록·상세로 연결합니다.
완료 체크포인트
career-step-08-github
다음 학습
09편 「개발자 포트폴리오 사이트 구성: 홈 · 프로젝트 목록 · 상세 페이지」로 이어집니다. 이번 문서의 사실과 미확인 항목을 다음 회차 입력으로 사용합니다.
이 글이 도움이 되었나요?
읽음 기록
읽음 — / 전체 19개 · 필수 19개
새 글 받아보기
RSS 리더에서 BlogFlow의 새 글을 확인할 수 있습니다.