GitHub 프로필에 KOSA 검증 경력

GitHub 프로필 README를 다듬었다. KOSA 검증 경력 반영하고, 페이락 row 정정하고, Verified Career 섹션 새로 추가한 작업이다.

작업 자체는 단순 편집이지만, 손대기 전에 구조를 한 번 정리했음. GitHub 프로필은 이력서보다 먼저 열리는 경우가 많다. 채용 담당자가 후보를 검토할 때, 오픈소스 기여 요청 메일을 보내기 전에, 컨퍼런스에서 명함 받고 돌아와서. 그 흐름에서 README가 5초 안에 "이 사람이 어떤 개발자인지"를 전달하지 못하면 이미 스크롤을 내려버린다. 그래서 총괄 포지션으로 올라올수록 이력서보다 프로필 관리가 더 신경 쓰이는 지점이 생긴다. 내가 팀 단위로 무언가를 결정하는 사람이라는 걸 프로필이 먼저 보여줘야 하기 때문.

이번에 손댄 이유

KOSA 검증을 마치고 나서 경력 사항이 공식적으로 확인된 상태인데, 정작 프로필에 반영이 안 되어 있었음. 오래된 정보가 남아 있으면 신뢰도를 깎는다. "이 사람 관리 안 하는 거 아냐?" 하는 인상. 페이락 관련 row도 잘못 기재된 부분이 있어서 같이 정정했다.

Verified Career 섹션을 따로 만든 건, 일반 경력 나열과 검증된 경력을 구분해 두는 게 의미 있다고 판단해서다. 검증 여부를 명시하면 보는 사람 입장에서 추가 확인 비용이 줄어든다. 신뢰를 사전에 확보하는 방식.

README 구조를 짤 때 쓴 기준

작업하면서 기준으로 삼은 원칙을 표로 정리해 두면 나중에 다시 손댈 때 흔들리지 않을 것 같아서 내부적으로 만들어 놨음.

"개선했다"는 말은 사실 아무 정보가 없다. 무엇을, 얼마나, 어떤 맥락에서. 수치가 붙는 순간 읽는 사람이 판단을 내릴 수 있다. 총괄 레벨에서는 특히, 숫자로 결과를 이야기하는 습관이 프로필에도 그대로 드러나야 한다.

연락 경로는 생각보다 많이들 빠뜨린다. 관심 있는 사람이 README를 읽고 나서 다음 행동을 어디로 해야 하는지 모르면 그냥 닫아버린다. GitHub 이메일 노출 설정을 막아둔 채 연락처를 따로 안 적어 놓은 프로필이 꽤 많다.

<details> 토글로 구조 정리하기

길이 균형을 맞추는 데 가장 유용하게 쓴 방법이 <details> 태그다. GitHub 렌더러가 HTML 서브셋을 지원하기 때문에 가능한데, 상세 경력이나 길어지는 기술 스택 목록을 접어두면 첫 화면이 훨씬 깔끔해진다.

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

...상세 내용...

</details>

이게 단순해 보여도 실제로 체감 차이가 꽤 크다. 처음 보는 사람은 열지 않고 훑고, 관심 생긴 사람은 열어서 확인한다. 정보의 밀도와 접근성을 동시에 챙길 수 있음.

배지는 핵심 기술 스택 5-7개 정도로 제한하는 게 맞는 것 같다. 배지를 20개 늘어놓은 프로필을 보면 오히려 뭘 잘하는 사람인지 안 보인다. 산만함이 전문성을 가린다. 지금 당장 쓰고 있고, 설명할 수 있는 것만 남겨두는 쪽이 낫다.

스캔 가능성(scannability)이라는 개념이 있다. 독자가 읽기 전에 훑는 행동. README도 결국 UX 설계와 비슷하다. 소제목, 표, 코드 블록이 시각적 앵커 역할을 해서 눈이 자연스럽게 멈추는 지점을 만들어줌. 소제목 없이 텍스트만 늘어져 있는 프로필은 아무리 내용이 좋아도 읽히지 않는다.

KOSA 검증 반영은 이번 업데이트의 주된 이유였지만, 하는 김에 전체 구조를 한 번 더 정돈했다. 어차피 몇 달에 한 번은 들어와서 손봐야 하는 곳이라, 그때그때 부분만 고치기보다 훑으면서 낡은 정보 제거하고 섹션 흐름 다듬는 게 결과적으로 더 효율적이다. 다음엔 포트폴리오 링크 쪽도 좀 정리해야 할 것 같음.