‘포트폴리오는 예쁘면 된다’가 블로그를 망치는 순간

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

예쁜 화면만 남긴 포트폴리오 블로그의 첫 번째 실패

보는 사람은 디자인보다 판단 근거를 찾습니다

포트폴리오 블로그를 만들 때 가장 자주 나오는 말이 있습니다. ‘일단 예쁘게 보이면 반은 간다’는 말입니다. 틀린 말은 아니지만, 이 말을 그대로 믿으면 프로젝트의 실체가 사라진 포트폴리오가 되기 쉽습니다.

채용 담당자, 협업 제안자, 클라이언트가 궁금해하는 것은 단순히 화면이 세련됐는지가 아닙니다. 이 사람이 어떤 문제를 발견했고, 어떤 선택을 했으며, 결과를 어떻게 설명할 수 있는지를 봅니다. 네이버 지식백과의 포트폴리오 용어 설명에서도 포트폴리오는 단순 모음이 아니라 성과와 역량을 보여주는 자료로 이해할 수 있습니다.

Susie Kim 같은 개인 포트폴리오 블로그라면 더더욱 ‘보기 좋은 전시’에서 멈추면 손해입니다. 블로그는 작품을 올리는 진열장이면서 동시에 사고 과정을 보여주는 기록 공간입니다. 예쁜 썸네일 하나보다 프로젝트를 끝까지 밀고 간 이유 한 문장이 더 오래 남을 때가 많습니다.

• 실패 패턴 1: 완성 화면만 보여주고 문제 정의를 생략합니다. 결과는 좋아 보여도 왜 만들었는지 알 수 없습니다.
• 실패 패턴 2: 사용한 툴 이름만 나열합니다. Figma, React, Notion 같은 단어는 많지만 본인의 판단은 보이지 않습니다.
• 실패 패턴 3: 모든 프로젝트를 같은 톤으로 소개합니다. 규모와 난이도가 다른데 문장이 비슷하면 신뢰도가 떨어집니다.
• 실패 패턴 4: 실패한 시도와 수정 과정을 숨깁니다. 오히려 그 부분이 실무 감각을 보여주는 핵심인데도 말입니다.

포트폴리오 블로그에서 디자인은 문을 여는 역할을 합니다. 하지만 독자가 머무르게 하는 것은 ‘왜 그렇게 만들었는가’에 대한 설명입니다.

그래서 첫 화면을 고칠 때는 색상보다 먼저 질문을 바꿔야 합니다. ‘어떻게 보일까?’보다 ‘무엇을 믿게 만들까?’를 묻는 순간, 포트폴리오 블로그의 방향이 훨씬 선명해집니다.

‘프로젝트가 작아서 쓸 게 없다’는 오해가 글을 비게 합니다

작은 프로젝트일수록 사고 과정이 더 잘 보입니다

많은 사람이 작은 프로젝트를 포트폴리오에 올리기 망설입니다. 규모가 작고, 유명한 브랜드와 협업한 것도 아니고, 사용자가 수만 명인 서비스도 아니라서 가치가 낮다고 생각합니다. 하지만 포트폴리오 블로그에서 중요한 것은 프로젝트의 크기보다 설명의 밀도입니다.

예를 들어 개인 일정 정리 페이지를 만들었다고 해봅시다. 겉으로는 간단한 사이드 프로젝트처럼 보입니다. 그러나 왜 기존 캘린더 앱으로 충분하지 않았는지, 어떤 사용 흐름에서 불편함을 느꼈는지, 기능을 줄이기 위해 무엇을 포기했는지를 쓰면 이야기는 달라집니다.

작은 프로젝트는 오히려 작성자가 직접 판단한 흔적을 드러내기 좋습니다. 큰 프로젝트에서는 팀의 결정과 본인의 기여가 섞이지만, 작은 작업은 문제 발견부터 결과 검토까지 한 사람의 사고가 뚜렷하게 이어집니다.

1. 문제 발견: 내가 불편했던 상황을 한 문장으로 적습니다. ‘일정이 많았다’가 아니라 ‘마감이 겹칠 때 우선순위를 한눈에 볼 수 없었다’처럼 씁니다.
2. 제약 조건: 시간, 기술, 데이터, 디자인 리소스의 한계를 밝힙니다. 제약을 말하면 결과가 더 현실적으로 보입니다.
3. 선택 이유: A 대신 B를 택한 근거를 씁니다. 이 부분이 실무형 포트폴리오의 핵심입니다.
4. 수정 전후: 처음 만든 화면과 바꾼 화면의 차이를 설명합니다. 이미지가 없어도 문장으로 충분히 비교할 수 있습니다.

쓸 게 없는 게 아니라 질문이 없는 경우가 많습니다

블로그 글이 짧아지는 이유는 소재 부족보다 질문 부족인 경우가 많습니다. ‘무엇을 만들었나’만 묻기 때문에 두세 문단에서 끝나는 것입니다. 대신 ‘무엇을 버렸나’, ‘무엇을 배웠나’, ‘다시 한다면 무엇을 바꿀까’를 물으면 글감이 자연스럽게 늘어납니다.

• 이 프로젝트를 시작하기 전 가장 불명확했던 부분은 무엇이었나요?
• 작업 중간에 가장 많이 흔들린 결정은 무엇이었나요?
• 처음 예상과 실제 결과가 달랐던 지점은 어디였나요?
• 독자나 사용자가 오해할 수 있는 부분은 무엇이었나요?

이 질문에 답하는 방식으로 Susie Kim 포트폴리오 블로그를 채우면, 프로젝트 규모와 상관없이 글의 설득력이 살아납니다. 작은 프로젝트를 작게 보이게 만드는 것은 결과물이 아니라 설명 방식입니다.

성과 숫자만 붙이면 전문적으로 보인다는 착각

숫자는 맥락 없이 쓰면 오히려 의심을 부릅니다

‘전환율 30% 증가’, ‘조회수 2배 상승’, ‘작업 시간 50% 단축’ 같은 문장은 포트폴리오에서 강력해 보입니다. 하지만 근거 없이 숫자만 박아두면 독자는 바로 의심합니다. 언제 측정했는지, 기준이 무엇인지, 본인의 기여가 어디까지인지 보이지 않기 때문입니다.

특히 개인 블로그에서는 과장된 성과 표현이 쉽게 티가 납니다. 숫자를 쓰고 싶다면 비교 기준, 기간, 측정 방식을 함께 제시해야 합니다. ‘좋아졌다’보다 ‘어떤 조건에서 어떻게 달라졌는지’를 보여줘야 SEO에도, 신뢰에도 유리합니다.

포트폴리오라는 말은 분야에 따라 의미가 조금씩 달라집니다. 예컨대 금융 영역에서는 자산 구성의 의미로도 쓰이는데, 다른 맥락의 포트폴리오 정의를 보면 ‘구성’과 ‘선택’이라는 관점이 공통적으로 드러납니다. 개인 포트폴리오 블로그도 결국 무엇을 선택해 보여줄지의 문제입니다.

• 나쁜 예: 사용자 만족도 상승. 무엇을 기준으로 상승했는지 알 수 없습니다.
• 조금 나은 예: 설문 응답 18명 기준, 탐색이 쉬워졌다는 응답이 11명에서 15명으로 늘었습니다.
• 나쁜 예: 작업 효율 2배 개선. 측정 단위가 없어 과장처럼 보입니다.
• 조금 나은 예: 반복 입력 항목을 줄인 뒤 동일 업무 기록 시간이 평균 12분에서 7분으로 줄었습니다.

숫자가 없을 때는 관찰 기록으로 보완합니다

모든 프로젝트에 정량 성과가 있는 것은 아닙니다. 학생 프로젝트, 개인 실험, 초기 사이드 프로젝트에서는 숫자가 없을 수 있습니다. 이때 억지로 성과를 꾸미면 오히려 역효과가 납니다.

숫자가 없다면 관찰 기록을 쓰면 됩니다. 사용자가 어느 화면에서 멈췄는지, 어떤 문구를 헷갈려 했는지, 본인이 어떤 기준으로 개선안을 냈는지 설명해보세요. 실무자는 완벽한 지표보다 정직한 판단 과정을 더 높게 볼 때가 많습니다.

성과가 작아도 괜찮습니다. 다만 측정하지 않은 것을 측정한 것처럼 쓰는 순간, 포트폴리오 블로그 전체의 신뢰가 흔들립니다.

1. 숫자를 쓸 때는 기준 시점을 함께 적습니다.
2. 비교 대상이 없다면 ‘관찰’과 ‘가설’로 표현합니다.
3. 팀 프로젝트라면 본인의 담당 범위를 분리합니다.
4. 성과보다 배운 점이 큰 프로젝트는 배운 점을 전면에 둡니다.

결국 숫자는 장식이 아니라 증거입니다. 증거로 쓰려면 출처와 조건이 필요하고, 장식으로 쓰면 금방 빈틈이 보입니다.

‘내 역할은 다 했어요’가 팀 프로젝트를 약하게 만듭니다

역할 나열보다 협업의 마찰을 보여줘야 합니다

팀 프로젝트를 포트폴리오 블로그에 쓸 때 흔한 실수는 ‘기획 담당’, ‘UI 디자인 담당’, ‘프론트엔드 담당’처럼 역할만 적고 끝내는 것입니다. 이 방식은 깔끔하지만 설득력이 약합니다. 실제 협업 역량은 역할명보다 문제 상황에서 어떻게 조율했는지에 드러납니다.

예를 들어 디자인과 개발 일정이 충돌했을 때 어떤 기준으로 기능을 줄였는지, 팀원의 의견이 갈렸을 때 어떤 자료를 근거로 결정했는지, 피드백이 늦어졌을 때 어떻게 일정을 재조정했는지 써야 합니다. 이런 문장은 포트폴리오를 단순 결과물 모음에서 일하는 사람의 기록으로 바꿉니다.

‘내 역할은 다 했다’는 문장은 방어적으로 들릴 수 있습니다. 반대로 ‘내가 맡은 범위에서 병목을 줄이기 위해 한 일’을 쓰면 훨씬 전문적으로 보입니다. 블로그 독자는 완벽한 팀워크 신화를 기대하지 않습니다. 현실적인 조율 능력을 보고 싶어 합니다.

• 피해야 할 표현: 팀원과 원활히 소통했습니다. 너무 포괄적이라 기억에 남지 않습니다.
• 바꿔 쓸 표현: 화면 정의가 늦어지는 구간을 줄이기 위해 우선순위 표를 만들고, 핵심 플로우 3개를 먼저 확정했습니다.
• 피해야 할 표현: 개발 파트를 담당했습니다. 담당 범위가 흐릿합니다.
• 바꿔 쓸 표현: 로그인 이후 대시보드 진입 흐름과 오류 메시지 처리를 구현했고, QA에서 발견된 예외 케이스 6개를 수정했습니다.

팀 프로젝트에서도 ‘나’를 선명하게 남기는 법

팀 프로젝트 글에서 가장 중요한 균형은 팀의 성과를 존중하면서도 본인의 기여를 흐리지 않는 것입니다. 전체 결과를 모두 자신의 공로처럼 쓰면 불편하고, 반대로 너무 겸손하게 쓰면 평가자가 판단할 재료가 부족합니다.

추천하는 방식은 ‘프로젝트 전체 목표 → 내가 맡은 문제 → 내가 한 판단 → 결과와 배움’ 순서입니다. 이 구조를 쓰면 협업의 맥락과 개인의 역할이 동시에 보입니다. Susie Kim 포트폴리오처럼 개인 브랜드를 쌓는 블로그에서는 특히 이 균형이 중요합니다.

1. 프로젝트 목표를 한 문장으로 씁니다.
2. 내 담당 범위를 기능, 화면, 문서, 리서치 등으로 구체화합니다.
3. 작업 중 생긴 갈등이나 제약을 하나만 고릅니다.
4. 내가 제안하거나 수정한 결정을 설명합니다.
5. 결과가 부족했다면 다음에 바꿀 기준까지 적습니다.

이렇게 쓰면 ‘팀에 묻힌 사람’이 아니라 ‘팀 안에서 판단한 사람’으로 읽힙니다. 포트폴리오 블로그의 힘은 바로 그 지점에서 생깁니다.

블로그 글을 일기처럼 쓰면 검색도 설득도 놓칩니다

일상 블로그와 포트폴리오 글은 문장 목적이 다릅니다

Susie Kim 사이트는 포트폴리오와 일상 블로그를 함께 담는 공간입니다. 그래서 자연스럽고 개인적인 톤은 장점이 될 수 있습니다. 다만 프로젝트 글까지 순수한 일기처럼 흘러가면 검색 유입과 설득력을 동시에 놓칠 수 있습니다.

예를 들어 ‘정말 힘들었지만 재미있었다’는 문장은 사람 냄새가 납니다. 하지만 그 문장만으로는 어떤 역량을 보여주는지 알기 어렵습니다. 감정은 출발점으로 두고, 정보와 판단으로 확장해야 블로그 콘텐츠가 됩니다.

검색 사용자는 대체로 구체적인 문제를 들고 들어옵니다. ‘포트폴리오 프로젝트 작성법’, ‘개인 블로그 포트폴리오’, ‘프로젝트 회고 쓰는 법’처럼 검색합니다. 따라서 글 안에는 독자가 찾을 만한 표현이 자연스럽게 들어가야 합니다.

• 일기형 문장: 이번 프로젝트는 생각보다 어려웠고 많이 배웠습니다.
• 블로그형 문장: 이번 프로젝트에서 가장 어려웠던 부분은 사용자가 첫 화면에서 다음 행동을 바로 고르도록 정보 우선순위를 정하는 일이었습니다.
• 일기형 문장: 디자인을 여러 번 고쳤습니다.
• 블로그형 문장: 초기 화면은 버튼이 많아 보였기 때문에 핵심 행동을 하나로 줄이고, 보조 기능은 하단 링크로 이동시켰습니다.

개인적인 톤을 살리면서 SEO를 넣는 방법

SEO를 의식한다고 해서 문장이 딱딱해질 필요는 없습니다. 오히려 자연스러운 경험 문장 안에 검색 키워드를 넣는 편이 좋습니다. ‘포트폴리오 블로그를 운영하면서 느낀 점은’처럼 말하면 키워드와 개인성이 함께 살아납니다.

중요한 것은 키워드를 반복해서 밀어 넣는 것이 아니라, 독자의 질문에 답하는 위치에 배치하는 것입니다. 제목, 첫 문단, h2 소제목, 목록 항목, 메타 설명에 핵심 키워드가 자연스럽게 흩어져 있으면 충분합니다.

1. 첫 문단에는 글의 문제 상황과 핵심 키워드를 함께 넣습니다.
2. 소제목은 감상보다 검색 의도를 반영합니다.
3. 목록에는 독자가 바로 적용할 수 있는 행동을 씁니다.
4. 마지막 문단은 인사말 대신 다음 행동을 떠올리게 만듭니다.

포트폴리오 블로그는 사적인 기록과 공개 문서의 중간에 있습니다. 이 특징을 이해하면 ‘나만의 이야기’와 ‘검색되는 글’ 사이에서 균형을 잡을 수 있습니다.

‘많이 올리면 언젠가 보겠지’라는 운영 실수

글 수보다 연결 구조가 먼저입니다

블로그를 시작하면 게시글 수를 늘리는 데 집중하기 쉽습니다. 물론 꾸준히 쓰는 것은 중요합니다. 하지만 포트폴리오 블로그에서는 많은 글보다 서로 연결되는 글의 구조가 더 중요할 때가 많습니다.

프로젝트 글이 20개 있어도 독자가 다음에 무엇을 봐야 할지 모르면 이탈합니다. 반대로 글이 5개뿐이어도 대표 프로젝트, 회고, 사용한 도구, 배운 점이 서로 연결되어 있으면 사이트 체류 시간이 길어집니다. 검색 엔진도 이런 내부 연결을 통해 페이지의 관계를 이해합니다.

운영 실수는 대개 글을 독립된 섬처럼 발행하는 데서 시작됩니다. 새 글을 올릴 때마다 이전 글과 연결할 지점을 찾아야 합니다. ‘이 글을 읽은 사람이 다음에 궁금해할 것은 무엇일까?’라는 질문이 내부 링크 전략의 출발점입니다.

• 대표 프로젝트 글: 가장 보여주고 싶은 결과와 문제 해결 과정을 담습니다.
• 과정 기록 글: 리서치, 기획, 디자인, 개발, 회고 중 한 단계를 깊게 다룹니다.
• 도구 사용 글: Notion, GitHub, 웹빌더 등 실제 작업 흐름을 설명합니다.
• 실패 사례 글: 잘못된 판단과 수정한 이유를 솔직하게 정리합니다.
• 업데이트 글: 시간이 지난 뒤 개선한 부분과 기준 변화를 남깁니다.

게시 빈도보다 독자가 이동할 길을 만듭니다

운영 초반에는 ‘주 3회 업로드’ 같은 목표가 동기부여가 됩니다. 하지만 품질을 유지하지 못한 채 발행만 늘리면 블로그 전체의 인상이 흐려집니다. 포트폴리오를 보러 온 독자는 모든 글을 시간순으로 읽지 않습니다. 필요한 증거를 빠르게 찾습니다.

따라서 카테고리가 없어도 글 안에서 길을 만들어야 합니다. 대표 글에는 관련 프로젝트 회고를 연결하고, 회고 글에는 사용한 도구나 개선 기록을 연결합니다. 카테고리보다 문맥형 링크가 더 자연스러울 때도 많습니다.

1. 새 글을 쓰기 전에 기존 글 중 연결할 글 2개를 고릅니다.
2. 본문 중간에 자연스러운 문장으로 이전 글을 언급합니다.
3. 비슷한 프로젝트는 차이점을 분명히 씁니다.
4. 대표 프로젝트 글은 주기적으로 업데이트합니다.
5. 조회가 많은 글은 첫 문단과 설명 문구를 다듬습니다.

포트폴리오 블로그 운영은 글을 쌓는 일이면서 동시에 길을 놓는 일입니다. 독자가 한 글을 읽고 바로 나가지 않도록, 다음 판단 재료를 눈앞에 두는 방식이 필요합니다.

신뢰를 깎는 문장 습관은 작은 표현에서 시작됩니다

겸손한 척하는 표현도 평가를 어렵게 만듭니다

포트폴리오 글에서 과장은 문제지만, 지나친 겸손도 문제입니다. ‘별건 아니지만’, ‘부족하지만’, ‘그냥 만들어봤습니다’ 같은 표현은 작성자의 부담을 줄여줄 수는 있어도 독자에게는 판단을 흐리게 만듭니다. 열심히 만든 프로젝트를 스스로 낮춰 소개하면 평가자도 그 가치를 크게 보지 않습니다.

반대로 모든 문장을 자신감 있게만 쓰면 또 다른 위험이 있습니다. ‘완벽하게 해결했습니다’, ‘최고의 사용자 경험을 만들었습니다’ 같은 표현은 근거가 없다면 공허합니다. 좋은 포트폴리오 블로그 문장은 겸손과 과시 사이가 아니라 사실과 해석 사이에 있습니다.

예를 들어 ‘처음이라 많이 부족했습니다’ 대신 ‘처음에는 입력 흐름이 길어 사용자가 중간에 멈출 가능성이 컸고, 이를 줄이기 위해 필수 항목을 6개에서 3개로 줄였습니다’라고 쓰면 됩니다. 이 문장은 부족함을 인정하면서도 개선 능력을 보여줍니다.

• 지우면 좋은 말: 별건 아니지만, 허접하지만, 그냥, 대충, 운 좋게, 어쩌다 보니
• 대체하면 좋은 말: 초기 버전에서는, 제한된 시간 안에서, 우선순위를 정해, 검증이 부족했던 부분은
• 조심할 말: 완벽한, 최고의, 압도적인, 혁신적인, 누구나 만족하는
• 보강할 말: 관찰 결과, 테스트 과정에서, 다음 버전에서는, 이 선택의 이유는

전문 용어는 설명 없이 쌓지 않습니다

전문성을 보여주고 싶어 용어를 많이 쓰는 경우도 흔합니다. 하지만 UX, IA, MVP, API, CMS 같은 단어가 설명 없이 이어지면 독자는 피로해집니다. 전문 용어는 아는 사람에게는 당연하고, 모르는 사람에게는 장벽입니다.

좋은 방식은 용어를 쓰되 바로 옆에 본인의 작업과 연결하는 것입니다. ‘MVP를 만들었다’보다 ‘핵심 기능만 남긴 MVP 형태로 시작해, 실제 사용 흐름을 먼저 확인했다’가 낫습니다. 용어가 주인공이 아니라 판단을 설명하는 도구가 되어야 합니다.

1. 전문 용어는 한 문단에 너무 많이 넣지 않습니다.
2. 처음 등장한 용어는 쉬운 말로 한 번 풀어씁니다.
3. 도구 이름보다 그 도구로 해결한 문제를 먼저 말합니다.
4. 자신 없는 표현은 숨기지 말고 검증 계획으로 바꿉니다.

독자는 어려운 말을 이해하려고 포트폴리오 블로그에 들어오지 않습니다. 이 사람이 실제 문제를 어떻게 다루는지 빠르게 확인하려고 들어옵니다.

문장 습관은 작아 보이지만 사이트 전체의 인상을 만듭니다. 같은 프로젝트도 표현을 어떻게 고르느냐에 따라 ‘아직 정리가 안 된 기록’이 되기도 하고, ‘같이 일해볼 만한 사람의 증거’가 되기도 합니다.

플랫폼과 평가 기준은 계속 바뀌니 기록 방식도 고정하면 안 됩니다

검색 노출보다 오래가는 것은 업데이트 가능한 구조입니다

포트폴리오 블로그를 한 번 만들어두고 그대로 방치하면 시간이 지나면서 정보가 낡습니다. 사용한 도구의 화면이 바뀌고, 채용 공고에서 요구하는 역량 표현도 달라지고, 개인의 관심 분야도 이동합니다. 그래서 Susie Kim 포트폴리오 같은 개인 사이트는 처음부터 업데이트를 전제로 설계하는 편이 좋습니다.

특히 검색 환경은 계속 변합니다. 어떤 키워드가 잘 노출되는지, 독자가 어떤 문장에 반응하는지, 프로젝트를 평가하는 기준이 무엇인지는 고정되어 있지 않습니다. 이 글의 기준도 2026년 현재 개인 포트폴리오 블로그를 운영하는 상황에 맞춰 쓴 것이며, 시간이 지나면 일부 표현과 우선순위는 달라질 수 있습니다.

그래서 마지막으로 점검할 것은 화려한 디자인이나 긴 글이 아니라, 나중에 고칠 수 있는 구조입니다. 글의 발행일, 업데이트 문장, 프로젝트 상태, 사용 기술, 배운 점을 분리해두면 수정이 쉬워집니다.

• 업데이트 날짜: 중요한 프로젝트 글에는 마지막 수정 시점을 적어 신뢰를 높입니다.
• 프로젝트 상태: 진행 중, 종료, 개선 예정처럼 현재 상태를 구분합니다.
• 기술 스택 변화: 더 이상 쓰지 않는 도구는 ‘당시 사용’이라고 표시합니다.
• 성과 문구: 오래된 숫자는 측정 기간을 함께 남겨 오해를 줄입니다.
• 링크 점검: 외부 링크와 배포 링크가 살아 있는지 주기적으로 확인합니다.

다음 수정 때 바로 볼 수 있는 운영 표를 남깁니다

포트폴리오 블로그는 완성물이 아니라 운영물입니다. 한 번 잘 써둔 글도 면접 시즌, 이직 준비, 프로젝트 업데이트, 검색 유입 변화에 따라 고쳐야 합니다. 따라서 글마다 아래처럼 간단한 운영 표를 남겨두면 다음 수정이 훨씬 쉬워집니다.

블로그 운영자가 놓치기 쉬운 점은 ‘지금 멋진 글’보다 ‘나중에 고치기 쉬운 글’이 오래간다는 사실입니다. 포트폴리오를 설명하는 기준은 계속 바뀌고, 프로젝트를 보는 사람의 기대도 달라집니다. 그러니 글을 닫힌 결과물로 두지 말고, 다음 업데이트가 자연스럽게 이어질 수 있는 열린 기록으로 남겨두는 편이 좋습니다.

참고로 포트폴리오의 의미를 더 넓게 확인하고 싶다면 지식백과의 포트폴리오 항목처럼 다른 분야의 정의를 살펴보는 것도 도움이 됩니다. 결국 좋은 포트폴리오 블로그는 결과물을 모으는 장소를 넘어, 선택의 기준이 계속 갱신되는 개인 작업실에 가깝습니다.