깃허브 프로필 기술 스택 정정

GitHub 프로필 README를 손봤다. 계기는 단순한데, 페이락 프로젝트 경험을 표기할 때 기술 스택이 잘못 들어가 있었다. 실제로 쓴 건 JSP/Thymeleaf/jQuery였는데, 어느 시점에 정리하다가 틀린 값이 박힌 것 같다. 회사명도 그대로 노출돼 있어서 같이 마스킹 처리했다.

작은 수정처럼 보이지만, 스택 오기재는 생각보다 리스크가 크다. 채용 과정 기술 인터뷰에서 프로필에 적힌 기술로 질문이 들어올 때, 실제로 쓴 적 없는 걸 설명해야 하는 상황이 생기면 신뢰도가 한번에 떨어진다. 특히 백엔드나 풀스택 포지션에서는 레거시 스택 경험이 오히려 강점이 될 수 있는데, 잘못된 모던 스택으로 덮어버리면 그 강점 자체가 사라진다. JSP/Thymeleaf 경험이 있다는 게 부끄러운 게 아니라, 그걸 정확하게 표기하는 게 맞다.

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

채용 담당자는 LinkedIn 다음으로 GitHub를 본다. 이력서에 GitHub 링크를 넣는 순간, 면접 전에 프로필이 먼저 노출된다고 봐야 한다. 이력서는 지원 시점에 맞춰 버전을 관리하는 경우가 많지만, GitHub 프로필은 방치되는 경우가 훨씬 흔하다. 이력서는 최신인데 프로필에 몇 년 전 스택이 박혀 있으면, 꼼꼼한 사람은 바로 눈치챈다.

협업 제안이 오는 경로도 비슷하다. DM이나 이메일이 오기 전에 상대는 이미 내 프로필을 훑는다. 5초 안에 어떤 사람인지 파악할 수 있어야 다음 액션이 일어난다.

스캔 가능성(scannability)을 기준으로 삼고 있다. 사람이 전체를 읽지 않고 훑을 때 핵심을 잡아낼 수 있느냐의 문제다. 문단으로 빽빽하게 채운 프로필은 아무도 끝까지 읽지 않는다. 그래서 구조를 계속 다듬는 게 의미 있다.

프로필 작성 시 내가 체크하는 기준은 이렇다.

• 스크롤 없이 핵심 파악 가능한가
• 경험이 추상적 표현 없이 수치로 표현됐는가
• 오래된 정보가 섞여 있지 않은가
• 연락 경로(LinkedIn, 포트폴리오)가 명확하게 노출됐는가

구조 설계: 토글과 배지 밀도

이번에 <details> 토글을 더 적극적으로 썼다. GitHub 렌더러가 HTML 서브셋을 지원하기 때문에 마크다운 안에서 HTML 태그를 쓸 수 있다. 경력 상세처럼 길어지는 섹션을 접어두면 첫인상이 훨씬 깔끔해진다.

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

| 기간 | 역할 | 주요 스택 |
|------|------|-----------|
| 20XX.XX - 현재 | 팀장 | Java, Spring Boot, PostgreSQL |
| 20XX.XX - 20XX.XX | 백엔드 | JSP, Thymeleaf, jQuery |

</details>

배지 밀도도 신경 썼다. shields.io 배지를 줄줄이 늘어놓으면 시각적으로 산만하다. 반대로 텍스트만 쓰면 밋밋하고 스캔도 잘 안 된다. 핵심 기술 스택 5-7개 정도에만 배지를 달고, 나머지는 표나 텍스트로 처리하는 게 균형이 맞는 것 같다. 배지가 외부 CDN 호출이라 로드 속도 이슈가 생길 수 있다는 트레이드오프가 있는데, 정적 이미지라 실제로는 거의 영향이 없다.

수치 기반 표현도 계속 의식한다. "성능을 개선했다", "사용자 경험을 향상시켰다" 같은 추상적 표현은 읽는 사람에게 아무것도 안 남긴다. "17.8s → 0.12s (145배)" 같은 구체적인 숫자가 들어가야 비로소 맥락이 생긴다. 수치가 없으면 차라리 적지 않는 게 낫다.

수정하면서 다시 생각한 것들

스택 오기재를 한 번 잡고 나니, 나머지 경력 항목도 다시 들여다보게 됐다. 당시 실제로 쓴 기술과 지금 내가 기억하는 기술이 다른 경우가 생각보다 있다. 프로젝트가 끝나고 시간이 지나면 기억이 단순화되는데, 코드 커밋 로그나 PR 히스토리를 보면 당시 실제 스택이 드러난다. 기억보다 기록이 정확하다.

회사명 마스킹도 간단한 작업이었지만, 어디까지 공개하고 어디서 막을지 기준을 다시 생각하게 됐다. 프로젝트명, 내부 시스템명 중에 무엇이 공개 정보고 무엇이 비공개인지는 조직마다 다르고, 퇴사 후에도 NDA 범위가 걸리는 경우가 있다. 불확실하면 안전하게 가는 게 맞다.

팀장 포지션에서 개인 GitHub 프로필을 관리하는 게 우선순위 밀리는 작업처럼 느껴질 때가 있는데, 사실 외부로 나가는 첫 번째 접점이라는 걸 생각하면 유지 비용 대비 효과는 꽤 크다. 이력서는 지원할 때 꼭 손보게 되는데, 프로필은 알림이 없으니 방치되기 쉽다. 분기에 한 번씩 들여다보는 루틴이 있으면 좋겠다는 생각이 남았다.