이커머스 PG 플랫폼 경력 강조로 GitHub 프로필 개선
목차
GitHub 프로필 README를 다시 손봤다. 이커머스 PG 플랫폼 작업 - 2인 팀으로 2개월 치 임팩트를 제대로 드러내도록 수정했고, 한국어 폰트 처리랑 팀 표기 오류도 이참에 정정했음.
사실 README 업데이트는 미루기 좋은 작업 중 하나다. 급하지 않으니까. 그런데 막상 오래된 프로필을 보면 "이거 보고 연락하고 싶겠나?" 싶은 생각이 든다. 채용 담당자든 오픈소스 협업 상대든, GitHub 프로필은 이력서보다 먼저 보는 경우가 많고, 첫 5초 안에 인상이 굳는다. 그 5초를 날리면 나머지 내용은 읽지도 않는다.
왜 이번에 손을 댔나
원인은 단순했다. 경력에서 가장 무게 있는 작업이 프로필에 제대로 안 보였다. 이커머스 PG 플랫폼 작업은 팀 규모나 납기 압박 기준으로 봐도 비중이 컸는데, README에서 묻혀 있었다. 어디선가 "개발자 프로필에서 팀 사이즈와 기간 조합이 임팩트 체감을 가장 빠르게 전달한다"는 말을 본 적 있는데, 실제로 그렇다. "PG 플랫폼 개발"이라고만 쓰는 것과 "2인/2개월"을 병기하는 건 읽히는 무게가 다르다.
팀 표기 오류도 그냥 뒀다가 이번에 고쳤다. 작은 것 같지만, 틀린 정보가 하나 있으면 나머지 내용 전체의 신뢰도가 떨어진다. 프로필은 정확도가 생명이다.
README 구조를 어떻게 다듬었나
이번 수정에서 지킨 원칙을 정리하면 이렇다.
| 요소 | 기준 |
|---|---|
| 한눈에 읽힘 | 스크롤 없이 핵심 파악 가능 |
| 수치 기반 | "개선했다"보다 "17.8s → 0.12s (145배)" |
| 최신 상태 | 오래된 정보는 신뢰를 낮춤 |
| 연락 경로 명확 | LinkedIn, 포트폴리오 링크 노출 |
수치 기반 표현은 습관을 들이는 게 어렵지, 한 번 익숙해지면 자연스럽게 나온다. 추상적인 "성능 개선"보다 숫자가 붙은 문장이 더 짧고 더 강하게 읽힌다. 구체적일수록 과장처럼 안 보이는 역설도 있다.
불필요한 정보 제거는 생각보다 손이 많이 간다. 뭘 뺄지 결정하는 게 뭘 넣을지보다 어려운 경우가 많음. 이번에도 섹션 몇 개를 통째로 날렸다. 오래됐거나, 지금 하는 일과 연결이 약한 것들.
스캔 가능성(scannability)은 구조 문제다. 아무리 좋은 내용이라도 덩어리째 쌓아두면 읽기 싫어진다. 소제목, 테이블, 불릿 리스트를 적절히 섞어야 눈이 따라간다.
<details> 토글 - 밀도를 조절하는 방법
길이 조절에서 가장 유용하게 쓴 건 <details> 태그다. GitHub 렌더러가 HTML 서브셋을 지원하기 때문에 쓸 수 있는 방식인데, 기본 뷰는 깔끔하게 유지하면서 상세 정보는 접어두는 데 딱 맞다.
<details>
<summary>경력 상세 보기</summary>
...상세 내용...
</details>
트레이드오프는 있다. 접혀 있으면 검색 크롤러가 내용을 얼마나 인덱싱하는지 불확실하고, 모바일에서 토글 UX가 좀 어색할 때도 있다. 그래도 핵심 요약은 위에 다 노출하고 부가 정보만 접는 식으로 쓰면 단점이 크게 부각되지는 않는다.
배지 선택도 비슷한 논리다. 너무 많으면 산만하고, 너무 없으면 밋밋하다. 직접 써본 결론은 핵심 기술 스택 5-7개 정도가 시각적 밀도와 정보량의 균형점인 것 같다. 배지를 고를 때는 "이게 없으면 내 스택이 설명 안 되나?"를 기준으로 걸러내면 편하다. 그 기준으로 걷어내면 생각보다 많이 남지 않는다.
한국어 폰트 처리는 이미지 기반 뱃지나 SVG를 쓸 때 간헐적으로 깨지는 문제가 있어서 확인 후 정리했다. GitHub 렌더링 환경이 시스템 폰트에 의존하는 부분이 있어서, 한글이 포함된 텍스트는 렌더 결과를 직접 확인하는 게 낫다.
프로필을 다 고치고 나서 드는 생각은, 이런 작업을 분기에 한 번 정도는 훑어보는 게 맞겠다는 것. 지금 하는 일, 쓰는 기술, 연락 방법 - 세 가지만 최신 상태면 나머지는 부가적이다. 그 세 가지가 흐릿하면 잘 꾸민 README도 힘을 못 쓴다.
댓글 0
첫 댓글 달아줘.