작은 프로젝트 기록을 포트폴리오 글로 바꿔본 과정

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

메모 더미에서 포트폴리오 주제를 골라낸 첫날

완성작보다 먼저 본 것은 작업 흔적이었습니다

포트폴리오를 새로 정리하려고 폴더를 열었을 때 가장 먼저 느낀 감정은 뿌듯함보다 난감함에 가까웠습니다. 화면 캡처, 회의 메모, 피그마 링크, 깃허브 커밋, 노션 회고가 여기저기 흩어져 있었고, 무엇을 대표 프로젝트로 보여줘야 할지 바로 판단하기 어려웠습니다.

저는 그래서 결과물이 예쁜 프로젝트부터 고르지 않았습니다. 대신 설명할 수 있는 변화가 있는 프로젝트를 먼저 찾았습니다. 포트폴리오는 단순 작품 모음이 아니라는 점에서, 포트폴리오의 기본 의미를 다시 확인해보는 것도 도움이 됐습니다.

실제로 골라보니 작은 프로젝트가 더 강한 사례가 되기도 했습니다. 기능은 단순했지만 문제 정의, 수정 이유, 사용자 반응이 남아 있던 작업은 블로그 글로 풀어냈을 때 훨씬 읽히는 힘이 있었습니다.

• 선택 기준 1: 처음 문제와 마지막 결과의 차이가 분명한가
• 선택 기준 2: 내가 맡은 역할을 한 문장으로 설명할 수 있는가
• 선택 기준 3: 실패나 수정 과정이 기록으로 남아 있는가
• 선택 기준 4: 포트폴리오 방문자가 1분 안에 맥락을 이해할 수 있는가

작은 프로젝트라도 의사결정의 흔적이 남아 있다면, 큰 프로젝트보다 더 좋은 포트폴리오 글감이 됩니다.

프로젝트 기록을 읽는 사람의 질문으로 다시 나눴습니다

내가 한 일보다 독자가 궁금한 일부터 배치했습니다

처음에는 프로젝트를 시간순으로 쓰려고 했습니다. 기획을 하고, 디자인을 하고, 개발을 하고, 배포했다는 흐름은 쓰는 사람에게는 자연스럽지만 읽는 사람에게는 밋밋하게 느껴졌습니다. 그래서 질문을 바꿨습니다. “나는 무엇을 했나?”가 아니라 “처음 보는 사람은 무엇이 궁금할까?”였습니다.

이 방식으로 다시 보니 본문 구조가 달라졌습니다. 프로젝트 이름 다음에 사용 기술을 길게 적기보다, 왜 이 작업을 시작했는지 먼저 보여주는 편이 훨씬 이해가 빨랐습니다. 특히 블로그 독자는 채용 담당자처럼 짧은 시간 안에 핵심을 파악하려고 하므로 문제, 선택, 결과의 순서가 중요했습니다.

저는 각 프로젝트 메모를 아래처럼 다시 쪼갰습니다. 이 과정에서 중복 문장은 줄고, 포트폴리오에 남길 문장과 개인 회고로만 보관할 문장이 자연스럽게 갈렸습니다.

1. 상황: 어떤 불편이나 목표가 있었는지 2문장으로 압축했습니다.
2. 역할: 기획, 디자인, 개발, 운영 중 내가 직접 책임진 부분만 적었습니다.
3. 판단: 왜 그 도구와 방식을 선택했는지 근거를 남겼습니다.
4. 결과: 수치, 반응, 배운 점 중 검증 가능한 내용을 골랐습니다.

좋았던 점과 아쉬웠던 점을 같은 비중으로 다뤘습니다

후기 형식으로 쓰다 보니 장점만 쓰면 광고처럼 보이고, 단점만 쓰면 작업 전체가 약해 보였습니다. 그래서 각 프로젝트마다 좋았던 점 하나와 아쉬웠던 점 하나를 짝으로 배치했습니다. 예를 들어 “빠르게 출시했다”는 장점 옆에는 “초기 접근성 점검이 부족했다”는 단점을 붙였습니다.

• 장점: 빠르게 의사결정한 이유를 함께 쓰면 설득력이 생깁니다.
• 단점: 단순 후회가 아니라 다음 개선 기준으로 연결해야 합니다.
• 팁: “열심히 했다”보다 “무엇을 줄이고 무엇을 남겼다”가 더 잘 읽힙니다.

노션 초안에서 블로그 본문으로 옮기며 바꾼 것들

포트폴리오 페이지와 블로그 글의 역할을 분리했습니다

처음 만든 초안은 노션 포트폴리오에 가까웠습니다. 링크와 캡처가 많고, 문장은 짧았으며, 프로젝트마다 형식도 제각각이었습니다. 그런데 블로그에 올리려면 검색으로 들어온 독자도 맥락을 이해해야 합니다. 그래서 내부 기록처럼 보이는 표현을 줄이고, 처음 읽는 사람을 위한 설명을 추가했습니다.

가장 크게 바꾼 부분은 첫 문단이었습니다. 이전에는 “A 프로젝트를 진행했습니다”라고 시작했지만, 수정 후에는 “예약 과정에서 사용자가 가장 자주 이탈한 지점은 날짜 선택 화면이었습니다”처럼 문제 상황부터 열었습니다. 이 한 문장만 바꿔도 프로젝트가 왜 필요한지 바로 드러났습니다.

또한 포트폴리오라는 단어를 반복해서 넣기보다, 문맥 안에서 자연스럽게 사용했습니다. 검색 최적화를 의식하더라도 같은 키워드를 과하게 반복하면 글이 딱딱해집니다. 저는 포트폴리오, 프로젝트, 블로그 키워드를 각 섹션의 핵심 문장에만 배치했습니다.

• 노션에 남긴 것: 상세 회의록, 내부 링크, 긴 작업 로그
• 블로그로 옮긴 것: 문제 정의, 해결 과정, 결과 수치, 배운 점
• 삭제한 것: 독자가 알 필요 없는 팀 내부 약어와 반복 캡처
• 추가한 것: 처음 보는 사람도 이해할 수 있는 배경 설명

포트폴리오 글은 모든 기록을 보여주는 자리가 아니라, 기록을 읽을 수 있는 이야기로 편집하는 자리입니다.

실제 작성하면서 느낀 장단점과 수정 팁

좋았던 점은 면접 답변까지 같이 정리된다는 것이었습니다

프로젝트를 블로그 글로 바꾸는 작업의 가장 큰 장점은 생각보다 실용적이었습니다. 글을 쓰다 보면 “왜 그렇게 했나요?”, “다른 선택지는 없었나요?”, “성과를 어떻게 확인했나요?” 같은 질문에 미리 답하게 됩니다. 실제로 저는 이 과정을 거친 뒤 포트폴리오 발표를 준비할 때 훨씬 덜 막혔습니다.

특히 개인 블로그에 올릴 글은 PDF보다 문장을 더 친절하게 써야 합니다. 덕분에 제 프로젝트를 모르는 사람에게 설명하는 연습이 됐습니다. 내가 익숙한 일도 독자에게는 낯설 수 있다는 사실을 계속 의식하게 된 점이 좋았습니다.

• 장점: 프로젝트 맥락이 정리되어 면접 답변 준비가 쉬워집니다.
• 장점: 검색 유입을 통해 포트폴리오가 더 오래 노출될 수 있습니다.
• 장점: 작업 습관과 문제 해결 방식을 자연스럽게 보여줄 수 있습니다.

아쉬운 점은 시간이 예상보다 많이 든다는 점입니다

반대로 단점도 분명했습니다. 포트폴리오 블로그 글은 단순 업로드가 아니라 편집 작업에 가깝습니다. 캡처를 고르고, 문장을 다듬고, 공개해도 되는 정보인지 확인하는 데 시간이 꽤 걸렸습니다. 회사나 클라이언트 프로젝트라면 더 조심해야 했습니다.

저는 민감한 수치와 이름을 모두 걷어낸 뒤, 상황을 일반화해서 썼습니다. 예를 들어 실제 매출이나 내부 지표 대신 “문의 전환율”, “반복 문의 감소”처럼 의미는 남기되 세부 숫자는 숨기는 방식입니다. 다른 맥락의 포트폴리오 설명을 참고하면, 분야에 따라 보여줘야 할 증거의 방식이 달라진다는 점도 이해하기 쉽습니다.

• 주의: 고객사명, 내부 지표, 미공개 화면은 반드시 공개 가능 여부를 확인합니다.
• 수정 팁: 수치가 어렵다면 전후 변화, 사용자 반응, 반복 업무 감소처럼 대체 근거를 씁니다.
• 문장 팁: “참여했습니다”보다 “무엇을 결정했고 왜 바꿨는지”를 씁니다.

퇴근 후 3일 동안 쪼개 쓰니 현실적으로 가능했습니다

하루에 끝내려 하지 않고 작업을 나눴습니다

처음에는 토요일 하루를 통째로 비워서 포트폴리오 글을 완성하려 했습니다. 하지만 막상 해보니 집중력이 금방 떨어졌고, 뒤로 갈수록 문장이 성의 없어졌습니다. 그래서 저는 작업을 3일로 나눴습니다. 하루 60~90분 정도만 잡으니 부담이 확 줄었습니다.

첫날에는 프로젝트 후보 3개를 고르고, 둘째 날에는 하나를 골라 본문 구조를 잡았습니다. 셋째 날에는 문장과 공개 범위를 다듬었습니다. 이 방식이 좋았던 이유는 하루가 지난 뒤 다시 읽을 때 어색한 문장이 훨씬 잘 보였기 때문입니다.

비용도 거의 들지 않았습니다. 노션, 구글 문서, 깃허브, 개인 블로그 관리자 화면만으로 충분했습니다. 유료 웹빌더나 디자인 도구를 쓰면 더 보기 좋게 만들 수 있지만, 처음 한 편을 완성하는 데 꼭 필요한 것은 아니었습니다. 포트폴리오 개념을 더 넓게 보고 싶다면 지식백과의 포트폴리오 항목처럼 여러 분야의 쓰임을 살펴보는 것도 좋습니다.

1. 1일 차 70분: 프로젝트 후보를 고르고 관련 자료를 한 폴더에 모았습니다.
2. 2일 차 90분: 문제, 역할, 선택, 결과 순서로 초안을 작성했습니다.
3. 3일 차 60분: 공개 불가 정보와 반복 문장을 걷어냈습니다.
4. 추가 20분: 제목, 설명, 태그를 검색 의도에 맞게 조정했습니다.

제가 잡은 최소 기준은 시간 4시간, 비용 0원, 프로젝트 1개였습니다

완벽한 포트폴리오 블로그를 목표로 잡으면 시작이 늦어집니다. 저는 최소 기준을 아주 작게 잡았습니다. 프로젝트 1개, 본문 1편, 수정 2회만 통과하면 공개하기로 했습니다. 이 기준 덕분에 계속 손만 대다가 미루는 상황을 피할 수 있었습니다.

• 필요 시간: 초안 90분, 편집 120분, 최종 점검 30분 정도가 현실적입니다.
• 필요 비용: 기존 블로그를 사용한다면 0원으로 시작할 수 있습니다.
• 권장 분량: 한 프로젝트당 3,000자 안팎이면 맥락과 결과를 함께 담기 좋습니다.
• 공개 기준: 링크가 열리고, 핵심 화면이 보이며, 내가 한 일이 5문장 안에 설명되면 충분합니다.

저에게 가장 효과가 컸던 숫자는 “3일”이었습니다. 하루 만에 끝내려는 욕심을 내려놓고 3일로 나누자, 포트폴리오 글은 훨씬 덜 무겁고 더 선명한 작업이 됐습니다.