출장 기차 안에서 개발자 포트폴리오를 고쳐본 후기

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

급하게 링크를 보내야 할 때 보이는 첫인상

노트북을 열자마자 걸린 10초의 압박

출장길 기차 안에서 채용 담당자에게 개발자 포트폴리오 링크를 보내야 하는 상황이 있었습니다. 와이파이는 불안정했고, 옆자리에서는 계속 통화가 이어졌고, 저는 Andrey Vasiliev 같은 개인 포트폴리오 사이트가 실제 상황에서 얼마나 잘 버티는지 몸으로 확인하게 됐습니다.

처음 느낀 장점은 단순했습니다. GitHub, 블로그, 프로젝트 페이지가 흩어져 있지 않고 한 도메인 안에 모여 있으면 설명 시간이 확 줄어듭니다. Portfolio의 기본 의미처럼 작업물을 보여주는 묶음이라는 본질이 잘 살아야, 보는 사람도 길을 잃지 않습니다.

반대로 단점도 바로 보였습니다. 첫 화면에서 내가 어떤 software developer인지, 어떤 projects를 해왔는지 한눈에 잡히지 않으면 방문자는 메뉴를 오래 눌러보지 않습니다. 특히 모바일 화면에서는 소개 문장보다 최근 프로젝트 카드, 기술 스택, 실제 배포 링크가 먼저 보여야 했습니다.

• 좋았던 점: 개인 도메인은 신뢰감을 줍니다. 링크 하나만 보내도 블로그, 프로젝트, 개발 이력을 함께 보여줄 수 있습니다.
• 아쉬웠던 점: 오래된 글이 상단에 남아 있으면 현재 역량보다 과거 취미 기록처럼 보일 수 있습니다.
• 바로 고친 점: 첫 화면 문장을 줄이고, 최근 프로젝트 3개를 먼저 보이도록 순서를 바꿨습니다.

포트폴리오 첫 화면은 자기소개서가 아니라 안내 데스크에 가깝습니다. 방문자가 어디를 눌러야 할지 10초 안에 알아차리게 만드는 것이 핵심입니다.

프로젝트 설명은 화려한 말보다 사용 맥락이 강했다

코드보다 먼저 읽히는 것은 문제 정의

기차 좌석 테이블 위에서 프로젝트 설명을 다시 읽어보니, 제가 그동안 너무 기술명 중심으로만 써왔다는 걸 깨달았습니다. JavaScript, PHP, Linux, NoSQL 같은 키워드는 중요하지만, 그것만 나열하면 사용자가 왜 그 프로젝트를 봐야 하는지 알기 어렵습니다.

예를 들어 “Node.js 기반 대시보드”라고 쓰는 것보다 “작은 팀이 배포 상태를 한 화면에서 확인하려고 만든 Node.js 대시보드”라고 쓰는 편이 훨씬 설득력 있었습니다. developer portfolio에서 기술 스택은 재료이고, 프로젝트 설명은 요리의 맛을 설명하는 부분입니다.

저는 프로젝트마다 설명 순서를 바꿨습니다. 먼저 해결한 문제를 쓰고, 다음에 맡은 역할, 그다음에 기술 선택 이유를 적었습니다. 마지막에는 실제로 배운 점을 짧게 붙였습니다. 이 방식은 면접관뿐 아니라 협업자를 찾는 사람에게도 훨씬 친절했습니다.

1. 문제: 이 프로젝트가 왜 필요했는지 한 문장으로 적었습니다.
2. 역할: 혼자 했는지, 프론트엔드만 맡았는지, 서버와 배포까지 했는지 분리했습니다.
3. 선택: 왜 JavaScript, PHP, Zend Framework, NoSQL을 골랐는지 실무적인 이유를 붙였습니다.
4. 결과: 속도 개선, 유지보수 편의, 사용자 흐름 개선처럼 확인 가능한 변화를 적었습니다.

짧은 사용 후기가 만든 신뢰

가장 효과가 있었던 부분은 프로젝트 끝에 3~4문장짜리 사용 후기를 붙인 일이었습니다. “처음에는 검색 필터를 복잡하게 만들었지만, 실제 사용자는 상태값 3개만 반복해서 눌렀다” 같은 문장은 기술보다 현장감을 줍니다. 읽는 사람은 이 개발자가 코드를 짜고 끝낸 사람이 아니라, 사용 장면까지 본 사람이라고 느낍니다.

• 추천 형식: “처음 의도 → 실제 사용 → 고친 점 → 다음 개선” 순서로 작성합니다.
• 피해야 할 형식: “최신 기술 적용”, “성능 최적화 완료”처럼 근거 없는 표현만 반복하는 방식입니다.
• 작은 팁: 실패한 선택도 한 줄 넣으면 오히려 신뢰도가 올라갑니다.

프로젝트 설명에서 가장 강한 문장은 “무엇을 만들었다”가 아니라 “써보니 무엇이 달랐다”입니다.

개인 블로그 글이 포트폴리오의 숨은 면접관이었다

카테고리는 취향이 아니라 탐색 경로

Andrey Vasiliev 사이트처럼 개인 블로그와 프로젝트가 함께 있는 구조에서는 카테고리가 생각보다 중요합니다. books, javascript, linux, php, no-sql, zend-framework처럼 기술과 생활이 섞여 있다면, 방문자는 이 사람이 어떤 흐름으로 성장해왔는지 읽을 수 있습니다.

다만 모든 글을 같은 무게로 보여주면 산만해집니다. 저는 실제 사용 후기를 쓰듯 글 목록을 다시 보면서 “채용 담당자가 봐도 좋은 글”, “동료 개발자가 봐도 좋은 글”, “개인 기록으로 남기면 좋은 글”을 나눴습니다. 포트폴리오라는 말의 활용 범위를 생각하면, 단순 보관함보다 선별된 전시가 더 맞습니다.

특히 블로그 글은 코드 저장소에서 보이지 않는 사고 과정을 보여줍니다. Linux에서 겪은 배포 문제, JavaScript 상태 관리에서 놓친 부분, PHP 프로젝트 유지보수 경험은 모두 좋은 소재가 됩니다. 중요한 건 “나도 이 문제를 겪었다”에서 멈추지 않고 “그래서 이렇게 바꿨다”까지 쓰는 것입니다.

• javascript 글: 구현 예제보다 왜 그 구조를 택했는지 설명하면 포트폴리오 가치가 커집니다.
• linux 글: 명령어 모음보다 장애 상황과 복구 과정을 적으면 실무성이 살아납니다.
• php 글: 오래된 코드 개선 경험을 쓰면 레거시 대응 능력을 보여줄 수 있습니다.
• books 글: 읽은 책의 요약보다 실제 작업 방식이 어떻게 바뀌었는지 연결하는 편이 좋습니다.

검색 유입보다 중요한 재방문 이유

SEO만 생각하면 제목에 키워드를 많이 넣고 싶어집니다. 하지만 개인 포트폴리오 블로그에서는 검색 유입 이후가 더 중요했습니다. 방문자가 글 하나를 읽고 “이 사람 프로젝트도 봐야겠다”고 느끼게 해야 합니다.

그래서 저는 글 하단에 억지 홍보 대신 관련 프로젝트 링크를 붙이는 쪽이 좋다고 느꼈습니다. 예를 들어 NoSQL 성능 글을 썼다면 실제로 그 선택이 들어간 프로젝트로 연결하고, Zend Framework 유지보수 글을 썼다면 리팩터링 기록으로 이어주는 방식입니다. 이 연결이 자연스러울수록 사이트 전체 체류 시간이 늘어납니다.

1. 기술 글 첫 문단에 실제 문제 상황을 넣습니다.
2. 본문 중간에 코드 선택의 이유를 설명합니다.
3. 글 끝에는 관련 프로젝트나 데모로 이어지는 문장을 둡니다.
4. 오래된 글은 현재 관점의 업데이트 문장을 추가합니다.

내 포트폴리오에서 먼저 고칠 순서를 다시 세웠다

우선순위는 예쁜 디자인보다 확인 가능한 증거

기차에서 내려 숙소에 도착한 뒤, 저는 포트폴리오 수정 우선순위를 완전히 다시 잡았습니다. 처음에는 디자인을 손보고 싶었지만, 실제로는 방문자가 확인할 수 있는 증거가 더 급했습니다. 배포 링크, GitHub 저장소, 프로젝트 설명, 작성 시점이 먼저였습니다.

물론 디자인이 중요하지 않다는 뜻은 아닙니다. 다만 software projects를 보여주는 개인 사이트라면 예쁜 카드보다 “이 프로젝트가 지금도 열리는가”, “README가 살아 있는가”, “내가 어떤 결정을 했는가”가 먼저입니다. 포트폴리오의 개념을 떠올려도, 핵심은 보기 좋은 포장이 아니라 검토 가능한 결과물입니다.

실제로 제가 체감한 순서는 아래와 같았습니다. 시간이 30분밖에 없다면 1번과 2번만 해도 체감 효과가 큽니다. 반나절이 있다면 5번까지 손보는 것이 좋고, 하루를 쓸 수 있다면 블로그 글과 프로젝트 간 내부 링크까지 정리할 만합니다.

1. 첫째, 최근 프로젝트 3개를 상단에 둡니다. 방문자는 전체 연대기보다 현재 실력을 먼저 보고 싶어 합니다.
2. 둘째, 각 프로젝트에 실제 링크를 붙입니다. 데모가 없으면 저장소, 저장소가 비공개라면 화면 설명과 역할 범위를 명확히 씁니다.
3. 셋째, 기술 스택을 결과와 연결합니다. “Linux 사용”보다 “Linux 서버에서 배포 자동화를 구성했다”가 더 강합니다.
4. 넷째, 오래된 글에는 현재 기준 메모를 답니다. 예전 선택이 지금도 유효한지, 바꾼다면 무엇을 고를지 적습니다.
5. 다섯째, 연락 동선을 줄입니다. 이메일, GitHub, LinkedIn 중 가장 빠르게 확인하는 채널을 분명히 보이게 합니다.

내가 다시 고친다면 남길 것과 덜어낼 것

사용 후기 관점에서 가장 남기고 싶은 것은 작은 실패 기록입니다. 버그를 어떻게 찾았는지, 배포가 왜 꼬였는지, 디자인을 왜 단순하게 바꿨는지 같은 내용은 평범해 보여도 개발자의 판단력을 보여줍니다.

덜어낼 것은 과한 자기소개와 장식적인 문구였습니다. “끊임없이 성장하는 개발자” 같은 표현보다 “작은 팀용 배포 로그 도구를 만들고 3개월간 유지보수했다”가 훨씬 선명합니다. 포트폴리오를 보는 사람은 멋진 선언보다 다음 협업에서 예측 가능한 사람인지 알고 싶어 합니다.

• 가장 먼저 볼 것: 첫 화면에서 Andrey Vasiliev, portfolio, developer, projects라는 핵심 맥락이 자연스럽게 드러나는지 확인합니다.
• 그다음 볼 것: 프로젝트마다 문제, 역할, 기술, 결과가 빠지지 않았는지 확인합니다.
• 마지막에 볼 것: 블로그 글이 현재 역량을 도와주는지, 오래된 인상을 만들고 있지는 않은지 살핍니다.