GitHub 프로필 README를 이커머스 경력 중심으로 정확하게 정비

GitHub 프로필 README를 다시 손봤다. 이번 업데이트의 핵심은 두 가지였음. 대전 표기를 전부 걷어냈고, "둘이서" 류의 표현을 이커머스 PG 플랫폼 맥락에 한정해서 정정했다. 작업 자체는 짧았는데, 손대면서 개발자 프로필 문서를 어떻게 관리해야 하는지에 대해 다시 생각하게 됐음.

개발자 프로필은 이력서와 읽히는 방식이 다르다. 이력서는 지원자가 제출하고 읽는 사람도 의도를 갖고 집중해서 보지만, GitHub 프로필은 상대가 별다른 준비 없이 착지하는 경우가 대부분이다. 채용 담당자가 레퍼런스 체크 중에 한 번 훑거나, 오픈소스 프로젝트에서 기여자가 누구인지 확인하려고 잠깐 들어오거나. 어느 맥락이든 5-10초 안에 인상이 결정되고, 그 짧은 창에 "이 사람이 어떤 도메인에서 뭘 했는지" 전달되지 않으면 프로필 문서가 있어도 없는 것과 비슷하다.

팀장급이 되고 나서 이걸 더 실감하게 됐다. 주니어일 때는 프로젝트 개수나 커밋 잔디 자체가 어필 포인트가 됐는데, 지금은 "어떤 도메인에서 어떤 규모의 문제를 어떻게 해결했는가"가 훨씬 중요함. 스택 배지 20개 나열보다 도메인과 성과를 명확히 보여주는 게 실질적인 신뢰를 준다. 상대가 팀장급 개발자를 볼 때 기대하는 것도 달라지기 때문에, 프로필이 아직 주니어 포맷에 머물러 있으면 오히려 역효과가 날 수 있다.

이번 정정이 필요했던 이유

"둘이서"라는 표현은 원래 특정 개발 컨텍스트에서 협업 방식을 설명하려고 쓴 문구였다. 그런데 맥락 없이 읽히면 전체 경력이 소규모 투맨샵 정도로 비쳐질 수 있었음. 실제로 해당 경험은 이커머스 PG 플랫폼 개발에 국한된 이야기라, 그 범위를 명확히 한정해두는 게 맞았다. 오해를 살 수 있는 표현은 넓게 읽히기 전에 좁혀두는 게 낫다.

대전 표기도 비슷한 맥락이다. 지역 정보 자체가 문제가 아니라, 지금 경력 방향과 무관한 정보가 프로필 상단에 자리를 차지하면 읽는 사람의 시선을 흘려보내게 된다. 프로필 상단은 가장 비싼 공간임. 거기에 놓이는 정보는 "이 사람이 누구인가"를 가장 빠르게 전달해야 하는 것들이어야 한다. 그 기준을 충족하지 못하는 항목은 과감히 빼는 게 맞다.

사소한 수정처럼 보이지만, 이런 디테일 정정이 쌓이면 프로필 전체의 정확도가 달라진다. 좋은 프로필은 한 번의 대형 리뉴얼로 완성되는 게 아니라, 이런 작은 수정을 꾸준히 하면서 조금씩 실제 경력에 가까워지는 과정이다. 분기에 한 번이라도 훑어보면서 현황과 맞지 않는 항목을 걷어내는 게 유지 방식으로는 맞는 것 같음. 큰 리뉴얼을 기다리다가 결국 손을 못 대는 것보다, 발견한 시점에 바로 고치는 게 낫다.

프로필 구조 설계 기준

지금까지 운용해온 기준을 표로 뽑아보면 이렇다.

수치 기반 표현이 생각보다 어렵다. "성능 개선", "효율화", "최적화" 같은 단어는 쓰기 편하지만 사실상 아무 정보도 전달하지 않음. "17.8s → 0.12s"처럼 쓰면 규모감이 바로 잡히는데, 이 방식이 가능하려면 작업 당시 수치를 측정해서 어딘가에 남겨둬야 한다는 전제가 있다. 사후에 기억으로 복원한 수치는 쓰지 않는 게 낫다. 틀리면 신뢰를 다 까먹음.

최신 상태 유지도 관리 비용이 생각보다 든다. 방치하면 1-2년 지난 스택이나 종료된 프로젝트가 그대로 남아 있게 됨. 오래된 정보가 섞여 있으면 최신 정보의 신뢰도도 같이 떨어진다. 독자 입장에서는 "프로필 관리도 안 하는 사람"으로 읽힐 수 있는데, 그게 기술 역량보다 먼저 인상에 박히면 곤란함.

섹션 구조는 스캐닝(scanning) 관점에서 설계해야 한다. 독자들이 문서를 읽는 게 아니라 훑는다는 걸 전제로 해야 함. 소제목, 강조, 배지 같은 시각 요소가 시선을 유도하는 역할을 하고, 그 흐름대로 핵심이 놓여 있어야 한다. 글을 순서대로 읽어야만 이해되는 구조는 프로필에 맞지 않음.

마크다운 구현 쪽 메모

토글 구조는 <details> 태그로 처리했다. GitHub 마크다운 렌더러가 HTML 서브셋을 지원하기 때문에 가능한 방식인데, 상세 경력이나 긴 프로젝트 설명을 접어두기에 좋음. 스크롤 없이 핵심만 보고 싶은 사람과 상세히 들여다보고 싶은 사람 둘 다 커버할 수 있다.

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

...상세 내용...

</details>

주의할 점은 <summary> 텍스트가 사실상 클릭 유도 역할을 한다는 거다. "상세 보기" 같은 제네릭한 텍스트보다 "이커머스 PG 플랫폼 개발 이력" 처럼 내용을 예고하는 표현이 훨씬 클릭을 끌어낸다. 그리고 접힌 상태에서도 스캐닝이 되도록 토글 바깥에 핵심 키워드를 남겨두는 게 좋음. 토글 안에만 내용이 있으면 열어보기 전까지 아무것도 전달이 안 된다.

배지는 숫자를 제한하는 게 맞다. 추가하다 보면 자꾸 늘어나는데, 10개 넘어가면 눈이 분산됨. 지금은 핵심 스택 5-7개만 상단에 노출하고 나머지는 본문 텍스트로 처리하는 방식을 유지 중. 배지는 시각 자극이 강해서, 많아질수록 정작 중요한 텍스트 정보가 묻히는 효과가 생긴다. 트레이드오프를 간단히 정리하면:

• 배지 많음: 기술 스택 한눈에 파악은 되는데, 시각적으로 요란해져서 글 내용이 묻힘
• 배지 적음: 깔끔하지만 스택 파악을 위해 글을 읽어야 함
• 토글 많음: 프로필이 간결해 보임, 대신 실제 내용을 읽는 사람이 줄어듦
• 토글 적음: 정보가 노출되지만 스크롤이 길어짐

어느 쪽이 맞냐는 결국 누구를 기준으로 설계하느냐에 달려 있다. "채용 담당자가 30초 훑는다"를 기준으로 하면 배지를 줄이고 상단 텍스트에 집중하는 구조가 맞고, "협업 상대가 기술 검토한다"를 기준으로 하면 상세 내용을 토글로 숨기되 접근 가능하게 두는 게 맞음. 두 가지를 동시에 잡으려면 계층 구조가 필요하다. 상단은 압축, 하단이나 토글 안에 상세. 지금 방향은 그 쪽으로 잡고 있다.