개발자 포트폴리오를 프로젝트 일지로 한 달 써봤더니

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

포트폴리오를 작품 목록이 아니라 작업 현장처럼 바꿔봤습니다

처음 바꾼 것은 소개 문장이 아니라 기록 방식이었습니다

개발자 포트폴리오를 오래 붙잡고 있으면 이상하게 더 화려한 화면부터 고치고 싶어집니다. 저도 처음에는 색상, 카드 배치, 프로젝트 썸네일을 만지작거렸는데, 한 달 동안 실제로 운영해보니 방문자가 오래 보는 곳은 예쁜 첫 화면보다 프로젝트가 어떻게 만들어졌는지 보이는 기록 쪽이었습니다.

그래서 개인 포트폴리오를 단순한 결과물 전시장처럼 두지 않고, 작은 프로젝트 일지처럼 운영해봤습니다. Andrey Vasiliev 같은 개인 개발자 사이트라면 software, design, creative works가 함께 섞일 수 있으니 완성작만 나열하기보다 문제 정의, 선택한 기술, 실패한 시도, 다음 수정 방향을 짧게 붙이는 방식이 더 자연스럽습니다. 포트폴리오라는 말 자체의 기본 의미는 Portfolio 용어 설명에서도 확인할 수 있지만, 웹에서는 결국 ‘내가 어떤 일을 어떤 기준으로 해내는 사람인가’를 보여주는 구조가 중요했습니다.

제가 적용한 방식은 거창하지 않았습니다. 기존 프로젝트 설명 아래에 작업 배경과 판단 근거를 추가했고, README에만 있던 내용을 블로그 문체로 풀어냈습니다. 특히 JavaScript, PHP, Linux처럼 카테고리가 분명한 글은 기술 이름을 앞에 세우되, 독자가 궁금해할 실제 사용 장면을 먼저 배치했습니다.

• Before: 프로젝트명, 사용 기술, 데모 링크만 표시했습니다.
• After: 왜 만들었는지, 어떤 제약이 있었는지, 다음에 무엇을 고칠지까지 적었습니다.
• 가장 효과가 컸던 부분: 실패 기록을 숨기지 않았을 때 오히려 설명의 신뢰도가 올라갔습니다.
• 덜 효과적이었던 부분: 너무 긴 개발 회고는 포트폴리오 첫 화면에서는 잘 읽히지 않았습니다.

팁: 포트폴리오의 첫 문장은 “저는 무엇을 합니다”보다 “이 프로젝트에서 어떤 문제를 풀었습니다”가 더 빨리 읽힙니다.

한 달 동안 써보니 프로젝트 설명의 무게중심이 달라졌습니다

방문자는 기술 스택보다 판단 과정을 먼저 확인했습니다

처음에는 developer portfolio에서 가장 중요한 것이 기술 스택이라고 생각했습니다. React를 썼는지, Node를 붙였는지, PHP와 Zend Framework 경험이 있는지 같은 항목을 앞에 두면 충분하다고 봤습니다. 그런데 직접 운영해보니 기술명만 나열한 프로젝트는 검색 유입에는 도움이 될 수 있어도, 실제로 사람을 설득하는 데에는 한계가 있었습니다.

반대로 “왜 이 구조를 골랐는지”, “어떤 부분을 줄이고 어떤 부분을 남겼는지”를 적은 글은 더 오래 읽혔습니다. 예를 들어 작은 JavaScript 도구를 소개할 때도 단순히 기능을 설명하기보다, 브라우저에서 바로 확인해야 했던 이유, 의존성을 줄인 이유, 나중에 유지보수할 때 생길 문제를 함께 적으니 프로젝트가 더 선명해졌습니다. 독자는 완벽한 결과물보다 현실적인 선택을 할 줄 아는 개발자를 보고 싶어하는 듯했습니다.

이때 도움이 된 것은 설명을 세 층으로 나누는 방식이었습니다. 첫 문단은 비개발자도 이해할 수 있게, 두 번째 문단은 협업자가 판단할 수 있게, 세 번째 문단은 개발자가 검증할 수 있게 구성했습니다. 포트폴리오의 정의를 넓게 보면 결과물 묶음에 가깝지만, 실제 개인 사이트에서는 포트폴리오의 일반적 의미보다 한 단계 더 나아가 ‘작업 방식의 증거’가 되어야 했습니다.

1. 첫 줄: 이 프로젝트가 해결한 문제를 한 문장으로 씁니다. “간단한 메모 앱”보다 “브라우저에서 빠르게 저장되는 개인 작업 메모 도구”가 낫습니다.
2. 중간 설명: 사용 기술을 나열하지 말고 선택 이유를 붙입니다. JavaScript를 썼다면 속도, 배포, 접근성 중 무엇 때문인지 밝혀야 합니다.
3. 마지막 문단: 아직 부족한 점을 씁니다. 검색, 캐시, 예외 처리, 모바일 레이아웃처럼 다음 개선점이 보이면 프로젝트가 살아 있는 느낌을 줍니다.

장점은 선명했지만 손이 많이 가는 단점도 있었습니다

이 방식의 가장 큰 장점은 포트폴리오가 검색 엔진에도, 사람에게도 조금 더 친절해진다는 점이었습니다. “developer”, “projects”, “software” 같은 핵심 키워드를 억지로 반복하지 않아도 프로젝트 설명 안에서 자연스럽게 녹아들었습니다. 특히 블로그 카테고리가 books, linux, php, no-sql처럼 나뉘어 있다면 각 글이 개인의 관심사와 작업 범위를 보여주는 작은 증거가 됩니다.

다만 단점도 분명했습니다. 매번 프로젝트를 올릴 때마다 설명을 길게 쓰려면 시간이 듭니다. 바쁜 주에는 “일단 링크만 올리자”는 유혹이 생기고, 그 순간부터 다시 예전의 빈약한 포트폴리오로 돌아가기 쉽습니다. 그래서 저는 모든 프로젝트에 같은 분량을 요구하지 않고, 핵심 프로젝트만 깊게 쓰는 식으로 기준을 낮췄습니다.

• 추천 분량: 핵심 프로젝트는 900~1200자, 보조 프로젝트는 300~500자 정도가 적당했습니다.
• 추천 구성: 문제, 접근, 기술 선택, 결과, 다음 개선점 순서가 가장 안정적이었습니다.
• 주의할 점: 모든 글을 성공담으로 만들면 오히려 인위적으로 보였습니다.
• 검색 팁: 제목에는 개발자 포트폴리오, 프로젝트, software 중 하나를 자연스럽게 넣고 본문에서는 반복을 줄였습니다.

실제로 써보니 좋은 포트폴리오는 “저 잘합니다”가 아니라 “이런 조건에서 이렇게 판단했습니다”에 가까웠습니다.

모든 프로젝트를 깊게 쓰기 어려운 상황도 분명히 있었습니다

비공개 작업과 오래된 기술은 다른 방식으로 다뤄야 했습니다

한 달 동안 운영하며 가장 애매했던 부분은 비공개 프로젝트였습니다. 클라이언트 이름을 밝힐 수 없거나 내부 코드가 포함된 작업은 화면 캡처와 저장소 링크를 공개하기 어렵습니다. 이럴 때 억지로 내용을 숨긴 채 “대규모 시스템 개발 참여”라고만 쓰면 아무 의미가 없습니다. 대신 범위를 줄여서 맡은 역할, 해결한 병목, 사용한 기술 판단만 남기는 편이 훨씬 낫습니다.

오래된 기술도 마찬가지였습니다. PHP나 Zend Framework처럼 요즘 트렌드의 중심에서 조금 떨어져 보이는 기술은 감추기보다 맥락을 붙이는 것이 좋았습니다. 예를 들어 “레거시 유지보수 경험”이라고 쓰는 대신, 기존 구조를 깨지 않고 배포 안정성을 높인 경험, Linux 서버에서 로그를 추적해 문제를 좁힌 경험처럼 구체화하면 오래된 기술도 강점이 됩니다. 단, 지금도 사용 가능한 방식인지와 단순 과거 경험인지는 분명히 나눠 적어야 합니다.

또 하나의 예외는 디자인과 creative works가 섞인 프로젝트입니다. 개발자 포트폴리오라고 해서 코드만 보여주면 사이트의 실제 성격이 좁아집니다. Andrey Vasiliev처럼 개인 프로젝트와 디자인 작업이 함께 있는 사이트라면, 시각적 결과물은 감각을 보여주고 기술 설명은 신뢰를 보완하는 식으로 균형을 잡는 편이 좋았습니다.

• 비공개 프로젝트: 회사명 대신 산업군, 역할, 해결한 문제를 씁니다.
• 오래된 기술: 유행 여부보다 유지보수, 안정화, 마이그레이션 경험을 강조합니다.
• 디자인 작업: 예쁜 결과보다 어떤 제약 안에서 선택했는지를 설명합니다.
• 작은 토이 프로젝트: 학습 목적과 배운 점을 솔직히 쓰면 충분합니다.

제가 계속 유지하려고 남긴 작은 운영 규칙

포트폴리오를 프로젝트 일지처럼 쓰는 방식은 모든 사람에게 맞지는 않습니다. 빠르게 취업용 PDF를 만들어야 하는 사람, 아직 공개 가능한 프로젝트가 거의 없는 사람, 회사 보안 규정 때문에 작업 내용을 밝히기 어려운 사람에게는 부담이 될 수 있습니다. 그런 경우에는 전체를 바꾸기보다 대표 프로젝트 2개만 먼저 손보는 편이 현실적입니다.

저는 앞으로도 모든 글을 완벽하게 쓰기보다, 방문자가 판단할 수 있는 단서를 조금씩 늘리는 방향으로 운영하려고 합니다. 개발자 포트폴리오는 한 번 만들고 끝나는 페이지가 아니라, 프로젝트가 쌓일수록 더 정확해지는 개인 작업 기록에 가까웠습니다. 다만 숫자 성과를 과장하거나, 실제로 참여하지 않은 범위까지 적는 순간 신뢰는 바로 무너집니다.

1. 한 달에 한 번 대표 프로젝트 설명을 다시 읽고 오래된 표현을 고칩니다.
2. 새 프로젝트를 올릴 때 문제 정의 한 문장과 다음 개선점 한 문장을 반드시 추가합니다.
3. 기술명을 쓸 때 단순 나열 대신 선택 이유를 함께 적습니다.
4. 공개가 어려운 작업은 결과물이 아니라 판단 과정 중심으로 익명화합니다.