GitHub 프로필을 미니멀하게 재설계해 첫인상 개선

GitHub 프로필 README를 뜯어고쳤다. 한 줄로 요약하면 미니멀 럭셔리 리디자인 — 있던 것의 70%를 들어냈고 핵심만 남겼음.

작업 자체는 단순한데, 왜 지금이냐고 하면 — 최근 오픈소스 컨트리뷰션 제안이나 협업 연락이 오가는 루트가 LinkedIn보다 GitHub가 더 많아졌다는 걸 체감해서다. 예전엔 이력서나 LinkedIn이 먼저였는데, 요즘은 레포를 먼저 보고 프로필로 타고 오는 흐름이 꽤 된다. 결국 GitHub 프로필이 사실상 첫인상 역할을 하고 있는데 관리가 소홀했다.

왜 정보를 줄이는 게 더 잘 팔리는가

채용 담당자나 협업 상대가 프로필을 보는 평균 시간이 5초 내외라는 건 직관적으로도 이미 알고 있는 사실이다. 문제는 그걸 알면서도 "더 많이 보여줘야 더 잘 보이겠지" 하는 함정에 빠진다는 점. 나도 한동안 그랬음. 쓰고 있는 언어, 인증, 프로젝트, 블로그 링크, 방문자 카운터까지 다 올려뒀는데 정작 내가 어떤 개발자인지는 안 읽혔다.

정보 과잉은 스캔 불가능 상태를 만든다. 사람이 빠르게 정보를 소비할 때는 Z패턴이나 F패턴으로 시선을 이동하는데, 텍스트 밀도가 높으면 첫 줄 읽고 이탈한다. 이력서 레이아웃 연구에서도 반복적으로 나오는 결론이 "덜어낸 버전이 기억에 더 남는다"임. README도 마찬가지다.

그래서 이번에 적용한 원칙은 단순했음: 프로필을 처음 보는 사람이 스크롤 없이, 3개 이하의 정보 덩어리로 "이 사람이 뭘 하는 개발자인지"를 파악할 수 있어야 한다.

개선한 구조를 정리하면 이렇다.

수치 기반 표현은 생각보다 효과가 크다. "성능을 대폭 개선했다"와 "쿼리 응답 시간을 17.8초에서 0.12초로 줄였다"는 문장의 무게가 완전히 다름. 전자는 읽히지 않고, 후자는 기억된다. 이미 갖고 있는 수치를 어떻게 꺼내서 쓰느냐가 포인트지, 수치를 새로 만들 필요는 없다.

<details> 토글 구조 - 적절히 써야 하는 이유

GitHub 마크다운 렌더러는 HTML의 서브셋을 지원한다. 그 덕분에 <details> / <summary> 조합이 GitHub에서 네이티브 토글처럼 동작함. 경력 상세나 프로젝트 설명 같은 긴 정보를 접어두는 데 유용하다.

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

### 현재 역할
총괄 팀장 - 서비스 아키텍처 및 인프라 운영

### 주요 성과
- 쿼리 응답 시간 17.8s → 0.12s (캐싱 레이어 + 인덱스 재설계)
- 배포 파이프라인 자동화로 릴리즈 주기 2주 → 3일

</details>

다만 주의할 점이 있음. 토글 안에 코드 블록이나 표가 들어갈 경우 렌더링이 깨지는 케이스가 있다. </summary> 뒤에 빈 줄을 하나 반드시 넣어야 하고, 닫는 </details> 앞에도 빈 줄이 있어야 마크다운이 제대로 파싱된다. 이거 몰라서 처음에 표가 일반 텍스트로 뜨는 걸 한참 디버깅했음.

배지 선택도 트레이드오프가 있다. shields.io 같은 서비스로 커스텀 배지를 잔뜩 달면 시각적으로 화려해 보이지만, 배지가 20개 넘어가는 순간부터 시선이 흩어진다. 핵심 기술 스택 5-7개를 명확하게 노출하는 게 낫다. 주력 언어, 자주 쓰는 프레임워크, 인프라 스택 정도. 거기서 더 궁금하면 레포 들어가서 보면 된다.

프로필 관리는 코드처럼 주기적으로

README를 한 번 잘 써두면 끝이 아니다. 오래된 정보가 섞여 있는 프로필은 오히려 신뢰를 낮춘다. "2020년에 Vue 2 했다"가 2026년 프로필에 버젓이 있으면 최신 상태 파악이 어렵고, 읽는 사람도 어느 정보를 믿어야 할지 모르게 됨.

분기에 한 번 정도 재검토하는 루틴을 만들기로 했음. 체크 포인트는 단순하게.

• 현재 맡고 있는 역할과 기술 스택이 정확히 반영되어 있는가
• 수치 기반 성과 중 업데이트가 필요한 항목이 있는가
• 연락처 링크가 살아있는가 (LinkedIn URL 바뀌는 경우도 있다)
• 핀 고정 레포가 현재 가장 보여주고 싶은 작업물인가

GitHub Stats 카드나 트로피 배지 같은 위젯 계열은 이번에 전부 걷어냈다. 방문자 카운터도 마찬가지. 이런 요소들은 "나 GitHub 열심히 해요"를 보여주고 싶은 심리에서 나오는데, 실제로 채용이나 협업 결정에 영향을 주는 정보는 아님. 잔디 이미지 하나 들어가면 레이아웃 무게 중심이 거기로 쏠려서 정작 중요한 텍스트가 묻힌다.

70%를 들어낸다는 게 처음엔 불안했는데, 막상 결과물 보면 훨씬 읽힌다. 덜어내는 게 더 어렵고, 더 오래 생각해야 하는 작업이라는 걸 이번에 다시 확인했음.