사이드프로젝트 slecs

이커머스 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

첫 댓글 달아줘.