GitHub 프로필 README를 채용 담당자 시선으로 풀 리디자인

프로필 README를 처음 만든 건 몇 년 전인데, 그때 올려둔 채로 거의 안 건드렸다. 어느 날 다른 개발자 프로필 몇 개를 보다가 내 거랑 비교가 됐고, 솔직히 좀 부끄러웠다. 기술 스택 리스트만 잔뜩 나열돼 있고 어떤 걸 잘하는 사람인지 전혀 안 보였음. 채용 담당자 입장에서 보면 5초 만에 이탈할 만한 구성이었다.

그래서 이번에 처음부터 다시 썼다. 방향은 하나였다 - 운영 시스템과 AI 영역에서 실제로 뭘 했는지를 빠르게 파악할 수 있게.

왜 GitHub 프로필이 이력서보다 먼저 보이나

채용 흐름을 생각해보면, 링크드인 → GitHub 순서로 오거나, 기술 커뮤니티에서 이름을 보고 바로 GitHub을 찾아오는 경우가 많다. 이력서는 지원 후에 보는 거고, 프로필은 그 전에 본다. 즉 첫 번째 필터가 GitHub인 셈이다.

근데 이걸 아는 개발자도 정작 자기 프로필은 방치하는 경우가 많음. "코드가 곧 포트폴리오"라는 말도 맞긴 한데, 레포 목록만 보고 그 사람의 강점을 파악하는 건 채용 담당자 입장에서 꽤 어렵다. 레포 30개 중 어떤 게 실력을 대표하는 건지, 사이드 프로젝트인지 실무 재현인지, 혼자 한 건지 협업인지 - 이걸 직접 눌러보면서 판단하기엔 시간이 없다. 그래서 핀포인트로 읽을 수 있는 요약본이 있어야 한다.

5초 규칙이라는 게 있다. 방문자가 페이지에 진입한 후 5초 안에 핵심을 못 잡으면 그냥 닫는다. 웹 랜딩페이지 최적화에서 자주 쓰는 개념인데, GitHub 프로필도 마찬가지다. 스크롤을 내려야 뭘 하는 사람인지 보이는 구조는 이미 진 거다. 사람들이 페이지를 처음 볼 때 F자형이나 Z자형으로 시선이 흐른다는 아이트래킹 연구 결과가 있는데, 상단 좌측에 가장 중요한 정보가 와야 하고 아래로 내려갈수록 선택적으로 읽을 수 있는 구조여야 한다는 게 핵심이다. 이 흐름을 역행하는 레이아웃은 아무리 내용이 좋아도 읽히지 않는다.

이번 리디자인에서 실제로 바꾼 것

가장 먼저 한 건 정보 제거였다. 있는 걸 추가하는 것보다 불필요한 걸 걷어내는 게 더 어렵다. 기술 스택 배지를 10개 넘게 나열해두면 읽는 쪽에서 뭘 핵심으로 봐야 할지 모른다. 핵심 스택 5-7개 선에서 끊는 게 맞다고 생각해서 정리했음. 나머지는 <details> 토글 안으로 넣었다.

수치 기반 표현도 신경 썼다. "성능을 개선했다"는 표현은 아무 정보도 없다. "17.8s → 0.12s" 같은 구체적인 수치가 들어가야 읽는 사람 머릿속에 실제 규모감이 생긴다. 숫자가 없는 성과 기술은 자기소개서 클리셰랑 다를 게 없음. 수치를 붙일 수 없는 성과는 쓰지 않는 쪽으로 기준을 세웠다.

오래된 정보에 대해서도 생각해봤다. 3년 전 기술 스택이 그대로 적혀 있으면 지금도 그게 주력인 것처럼 읽힌다. 업데이트가 안 된 프로필은 그 사람이 지금 뭘 하는지 알 수 없다는 신호이기도 하고, 꼼꼼하지 못하다는 인상을 줄 수도 있다. 방문한 시점 기준으로 정확한 정보를 보여주는 것 자체가 신뢰의 일부임. 그래서 분기에 한 번이라도 점검하는 루틴을 넣었음.

연락 경로도 위쪽에 뒀다. 아무리 잘 만든 프로필이어도 연락할 방법을 못 찾으면 의미가 없다. LinkedIn, 포트폴리오 URL - 이 두 가지는 fold 위에 놓는 게 맞다. 이걸 하단에 두는 개발자가 생각보다 많은데, 연락하려다가 스크롤 내리다가 그냥 닫는 경우도 있을 거라고 생각함.

Markdown으로 할 수 있는 것들

GitHub 렌더러가 HTML 서브셋을 지원하기 때문에 순수 Markdown에서는 못 쓰는 레이아웃 기법을 일부 쓸 수 있다. 그중 실용적인 게 <details> 태그다. 길이가 긴 경력 상세나 프로젝트 설명을 접어두고 필요한 사람만 펼쳐볼 수 있게 처리할 수 있음.

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

...상세 내용...

</details>

이 구조의 장점은 두 타입의 방문자를 동시에 커버한다는 거다. 5초 스캐너와, 진지하게 보는 사람 둘 다. 상단을 압축하되 상세는 숨기지 않고 선택적으로 접근 가능하게 두는 방식이라 정보 손실 없이 첫인상을 관리할 수 있다. 다만 <details> 안에서 일부 Markdown 문법이 깨지는 경우가 있어서 렌더링 확인은 꼭 해봐야 함.

배지 선택도 고민했다. shields.io 같은 서비스로 기술 배지를 만들면 시각적으로 정돈돼 보이는데, 과하면 역효과가 난다. 배지를 20개 붙여놓으면 뭘 진짜 잘하는지 모르겠는 사람처럼 읽힌다. 반대로 텍스트만 있으면 밋밋하고. 카드 배치와 배지 수의 균형이 시각적 밀도와 정보량 사이의 트레이드오프인데, 핵심 스택 5-7개 정도에서 끊는 게 지금까지 본 프로필 중 가장 깔끔해 보였다.

배치 원칙도 있다. 같은 정보라도 테이블로 정렬하면 훨씬 읽기 쉽고, 중앙 정렬 레이아웃은 프로필 특성상 잘 맞는다. 다만 테이블을 남용하면 소스가 복잡해지고 유지보수가 힘들어지는 면이 있어서, 진짜 비교가 필요한 데이터일 때만 쓰는 게 낫다고 생각함. 레이아웃을 위한 테이블은 오히려 마크다운 가독성을 해친다.

이번 작업을 하면서 정리된 게 하나 있다. 프로필도 제품이라는 거다. 코드를 배포하고 나서 UX를 반복적으로 개선하듯, README도 방문자 관점에서 계속 다듬는 게 맞다. 총괄 팀장 포지션이라면 특히 - 내가 뭘 잘 만드는 사람인지보다, 어떤 문제를 주도적으로 풀 수 있는 사람인지가 읽혀야 한다. 그 포지셔닝이 명확하게 되는 구조인지를 기준으로 앞으로도 계속 손볼 것 같음.