사이드프로젝트 slecs

GitHub 프로필을 카드 그리드와 경력 인증으로 개선

목차

GitHub 프로필 README를 또 갈아엎었다. 이번엔 카드 6장짜리 2×3 그리드와 Verified Career 섹션을 새로 붙였는데, 생각보다 손이 많이 갔다.

계기는 단순했다. 채용 측에서 연락이 왔을 때 프로필 링크를 보냈더니 "README가 비어있네요"라는 말을 들었다. 당시엔 핀된 레포 몇 개에 기대고 있었는데, 그게 전부라고 생각한 거다. 핀된 레포는 코드는 보여줘도 '이 사람이 어디서 뭘 했는지'는 안 보여준다. GitHub 프로필은 이력서보다 먼저 열리는 경우가 꽤 많아서, 5초 안에 읽혀야 한다는 기준을 그때부터 가져가고 있다.

카드 그리드와 Verified Career 섹션을 고른 이유

카드 레이아웃은 정보를 격자로 쪼개서 시선을 정렬해주는 효과가 있다. 한 줄짜리 나열보다 스캐닝이 빠르고, 모바일에서도 덜 무너진다. 2×3으로 간 건 6개 이상 올라가면 오히려 읽지 않게 되더라는 경험 때문이다. 카드 하나당 '기술 영역 하나'라는 원칙을 잡고, 배지는 카드당 3~4개로 제한했다.

Verified Career 박스는 스택 인증 배지를 모아두는 공간이다. 추상적인 "XX에 능숙합니다" 식 표현 대신, 외부 인증이나 수치 기반 성과를 한 곳에 모았다. "개선했다"보다 "17.8s → 0.12s (145배)"처럼 쓰는 게 신뢰도 면에서 확실히 다르다. 읽는 사람이 검증할 수 없는 형용사보다, 검증 가능한 수치가 낫다.

<details> 토글로 밀도 조절

GitHub README에서 길이를 줄이면서 정보량은 유지하는 방법 중 가장 실용적인 게 <details> 태그다. GitHub 렌더러가 HTML 서브셋을 지원하기 때문에 가능한데, 보통 마크다운 환경에서는 안 되는 경우가 많아 GitHub 전용 기법이라고 봐도 된다.

<details>
<summary>경력 상세 보기</summary>

| 기간 | 역할 | 주요 작업 |
|------|------|-----------|
| 2023 - 현재 | 총괄 팀장 | 인프라 자동화, 서비스 안정성 개선 |

</details>

이 구조의 장점은 첫 스크롤에 보이는 정보와 펼쳐서 보는 정보를 나눌 수 있다는 점이다. 채용 담당자는 요약만 보고 연락할지 판단하고, 기술 협업 상대는 상세를 열어볼 거라는 가정 아래 두 계층으로 나눴다.

주의할 점은 <details> 안에 마크다운 블록을 쓸 때 빈 줄 처리다. <summary> 태그 다음에 빈 줄 없이 마크다운을 쓰면 렌더링이 깨진다. 빈 줄 하나를 꼭 넣어야 테이블이나 코드 블록이 제대로 보인다.

README를 관리하는 실제 기준

프로필 README는 한 번 만들어 두면 방치하기 쉬운데, 오래된 정보는 신뢰를 갉아먹는다. 마지막 업데이트가 3년 전인 배지나 링크가 깨진 포트폴리오를 달아두면 차라리 없는 게 낫다.

내가 지금 쓰는 기준은 이렇다.

요소 기준
한눈에 읽힘 스크롤 없이 핵심 파악 가능
수치 기반 형용사 대신 측정 가능한 수치
최신 상태 분기에 한 번은 훑어서 stale 제거
연락 경로 명확 LinkedIn·포트폴리오·이메일 중 최소 2개

배지 선택도 생각보다 중요한데, 너무 많으면 산만하고 너무 없으면 밋밋하다. 핵심 기술 스택 5~7개 정도가 균형점이라고 느낀다. 지금 내 프로필 기준으로는 언어 2개, 인프라 2개, 주요 프레임워크 2개 구성이다. 그 외엔 <details> 안에 숨겼다.

세부 내용을 숨기고 핵심만 보여주는 원칙은 README뿐 아니라 이력서나 포트폴리오 페이지에도 그대로 적용된다. 결국 읽는 사람의 인지 부하를 줄이는 문제인데, 개발 문서나 API 레퍼런스도 같은 원리다. 계층 구조로 쪼개고, 위 계층에서 흥미를 끌어야 아래를 열어본다.

이번 개편으로 프로필 구조 자체는 어느 정도 안정됐다고 보고, 앞으로는 콘텐츠 갱신 주기를 규칙화하는 게 숙제다.

댓글 0

첫 댓글 달아줘.