실패한 프로젝트도 강점으로 바꿀 포트폴리오라면

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

출시가 취소된 서비스, 목표 수치를 달성하지 못한 캠페인, 중간에 방향이 바뀐 개발 프로젝트도 포트폴리오에 넣을 수 있을까요? 결과만 보면 망설여지지만, 채용 담당자가 확인하려는 것은 성공 여부만이 아니라 불확실한 상황에서 어떤 판단을 내렸는지입니다. 실패를 변명하지 않으면서 역량의 증거로 바꾸는 방법을 프로젝트 리뷰 전문가와의 문답으로 풀었습니다.

실패한 프로젝트를 공개해도 괜찮을까요?

Q. 성공 사례만 넣어야 안전하지 않나요?

인터뷰이 박선율 프로젝트 리뷰 컨설턴트: 포트폴리오는 상장이나 수상작 모음이 아닙니다. 일반적인 포트폴리오의 개념처럼 자신의 활동과 역량을 보여주는 자료에 가깝습니다. 따라서 목표에 미달한 프로젝트도 문제를 발견하고 대응한 과정이 선명하다면 충분히 포함할 수 있습니다.

다만 모든 실패가 좋은 사례는 아닙니다. 담당 업무가 불분명하거나, 실패 원인을 전부 외부 환경에 돌리거나, 아직 공개할 수 없는 고객 정보가 핵심인 프로젝트라면 제외하는 편이 낫습니다. 반대로 본인이 내린 결정과 그 근거, 수정 행동, 이후 업무에 적용한 변화가 연결된다면 성공 사례보다 깊은 인상을 줄 수 있습니다.

예를 들어 전환율 목표가 8%였지만 실제 결과가 5.4%였다고 가정해 보겠습니다. 단순히 “목표를 달성하지 못했다”고 쓰면 약점만 남습니다. 그러나 유입 경로별 이탈을 분석해 모바일 결제 단계의 문제를 찾았고, 다음 실험에서 입력 항목을 줄여 이탈률을 낮췄다면 분석력과 학습 속도를 보여주는 프로젝트가 됩니다.

• 포함하기 좋은 실패: 판단 근거와 후속 개선이 남아 있는 사례
• 보완이 필요한 실패: 결과는 있으나 본인의 기여 범위가 모호한 사례
• 제외해야 할 실패: 보안·계약 위반 가능성이 있거나 타인을 비난해야만 설명되는 사례

“실패를 공개하는 용기보다 중요한 것은, 실패를 다시 사용할 수 있는 지식으로 바꿨다는 증거입니다.”

프로젝트 실패 원인은 어디까지 솔직하게 써야 하나요?

Q. 솔직함과 자기 비판의 경계가 궁금합니다

박선율: 솔직함은 자신을 깎아내리는 태도가 아니라 당시 확인할 수 있었던 정보와 놓친 정보를 구분하는 능력입니다. “시장 조사를 제대로 하지 못했습니다”처럼 넓게 고백하면 독자는 실제 문제를 알 수 없습니다. “기존 고객 인터뷰 6건에 의존해 신규 고객의 가격 저항을 검증하지 못했습니다”라고 써야 판단의 빈틈이 보입니다.

원인은 개인, 팀, 환경의 세 층으로 나눠 설명하면 균형을 잡기 쉽습니다. 개인 층에는 본인이 놓친 가정이나 부족했던 기술을, 팀 층에는 의사결정 구조와 협업 문제를, 환경 층에는 예산·일정·정책 변화 같은 제약을 적습니다. 이때 다른 팀원을 특정하거나 평가하지 말고, 자신이 통제할 수 있었던 범위를 중심으로 서술해야 합니다.

Q. 실패를 포장한다는 인상을 피하려면요?

긍정적인 표현으로 덮기보다 불리한 사실을 먼저 짧게 인정하십시오. 이어서 원인 분석과 행동을 보여주면 됩니다. “출시 일정이 3주 지연되었습니다. 초기 요구사항에서 예외 처리 범위를 정의하지 않은 것이 주요 원인이었고, 이후 요구사항 문서에 예외 조건과 승인자를 추가했습니다”처럼 쓰면 방어적인 인상을 줄일 수 있습니다.

1. 사실: 무엇이 목표에 미달했는지 수치나 일정으로 밝힙니다.
2. 원인: 당시의 가정 중 무엇이 틀렸는지 적습니다.
3. 책임: 본인이 바꿀 수 있었던 지점을 분리합니다.
4. 행동: 문제를 확인한 뒤 실제로 취한 조치를 설명합니다.
5. 재사용: 배운 내용을 다음 프로젝트에 어떻게 적용했는지 연결합니다.

“완벽주의 때문에 늦어졌다”처럼 장점으로 들리는 실패를 고르는 방식은 피하는 것이 좋습니다. 독자는 잘 꾸민 답보다 구체적인 제약 속에서 선택한 흔적을 더 신뢰합니다.

실패 사례는 어떤 순서로 구성해야 읽히나요?

Q. 프로젝트 페이지의 권장 구조가 있나요?

박선율: 실패 사례는 사건 순서대로 길게 기록하기보다 기대와 실제의 차이를 먼저 보여줘야 합니다. 프로젝트 이름 다음에 기간과 역할만 적고 곧바로 배경 설명을 시작하면 방문자는 실패의 의미를 이해하기 어렵습니다. 첫 화면에서 목표, 실제 결과, 본인의 책임 범위를 한 번에 확인하게 하십시오.

권장 흐름은 ‘목표 → 관찰된 결과 → 원인 가설 → 검증 방법 → 수정 행동 → 이후 변화’입니다. 이 구조는 디자이너, 개발자, 마케터, 기획자 포트폴리오에 모두 적용할 수 있습니다. 다만 직무에 따라 증거가 달라집니다. 디자이너는 사용자 테스트 기록과 화면 변경 전후를, 개발자는 장애 원인과 재발 방지 장치를, 마케터는 채널별 지표와 예산 재배분 근거를 제시하는 식입니다.

별도의 David Lee 프로필 페이지가 있다면 실패 사례 안에서 경력 전체를 반복하지 마십시오. 프로젝트 페이지에는 당시의 직책과 실제 권한만 표시하고, 전체 이력은 프로필로 연결하는 편이 좋습니다. 또 다른 분야에서 사용되는 포트폴리오 용어 설명도 참고할 수 있지만, 개인 사이트에서는 작품의 양보다 맥락과 선별 기준이 더 중요합니다.

• 상단 요약: 기간, 팀 규모, 역할, 목표, 최종 결과를 5줄 이내로 배치합니다.
• 핵심 장면: 결과가 예상과 달라졌음을 처음 인지한 시점을 설명합니다.
• 판단 기록: 선택 가능한 대안과 실제 선택 이유를 함께 적습니다.
• 증거 자료: 차트, 테스트 기록, 회고 문서 중 공개 가능한 것만 사용합니다.
• 현재의 시선: 같은 조건이라면 무엇을 먼저 검증할지 한 문단으로 답합니다.

프로젝트가 실패한 날짜보다 중요한 것은 판단이 바뀐 순간입니다. 독자가 그 전환점을 찾느라 페이지를 헤매지 않게 하십시오.

수치가 부족하거나 비공개라면 무엇을 증거로 삼나요?

Q. 매출과 전환율을 공개할 수 없는 프로젝트도 있습니다

박선율: 숫자를 공개하지 못한다고 해서 근거까지 포기할 필요는 없습니다. 절대값 대신 변화율이나 범위를 사용할 수 있고, 그것도 어렵다면 의사결정 전후의 상태를 비교할 수 있습니다. 예를 들어 “월 매출 3억 원”을 밝힐 수 없다면 “개선안 적용 후 재구매율이 이전 분기 대비 두 자릿수 비율로 상승했다”고 표현하고, 회사의 공개 기준에 맞춰 수치를 비식별화했다는 주석을 붙이십시오.

정량 지표가 아예 없는 초기 프로젝트라면 정성 증거를 구조화해야 합니다. 사용자 인터뷰에서 반복된 문제의 빈도, 내부 리뷰에서 반려된 이유, 테스트 참가자가 과업을 완료하는 과정에서 보인 행동처럼 관찰 가능한 사실을 기록합니다. “반응이 좋았다”보다 “사용성 테스트 참여자 5명 중 4명이 도움말 없이 핵심 과업을 완료했다”가 훨씬 구체적입니다.

Q. 실패를 시각화할 때 주의할 점은요?

그래프의 축을 과도하게 잘라 작은 변화를 크게 보이게 하거나, 성공한 일부 기간만 선택하면 신뢰가 떨어집니다. 목표선과 실제 수치를 함께 표시하고 측정 기간, 표본 수, 데이터 출처를 가까운 위치에 적으십시오. 직접 측정한 데이터와 팀에서 제공받은 데이터를 구별하는 것도 중요합니다.

• 절대값 비공개: 기준 시점을 100으로 둔 지수나 증감률로 표현합니다.
• 표본이 작음: 인원과 모집 조건을 밝히고 일반화하지 않습니다.
• 성과 측정 전 종료: 산출물보다 검증한 가정과 중단 기준을 제시합니다.
• 팀 공동 성과: 전체 결과와 개인 기여를 서로 다른 문장으로 구분합니다.
• NDA 적용: 화면을 임의로 흐리기 전에 공개 가능한 서술 범위를 담당자에게 확인합니다.

특히 포트폴리오 프로젝트를 익명화할 때 업종, 사용자 규모, 지역, 출시 시점을 함께 적으면 회사가 추정될 수 있습니다. 공개할 정보 하나하나뿐 아니라 정보를 조합했을 때 식별되는지까지 살펴야 합니다.

한 사례를 완성하는 데 필요한 시간과 비용은 얼마일까요?

Q. 현실적으로 어느 정도를 투자해야 하나요?

박선율: 자료가 정리되어 있다면 실패 프로젝트 한 편을 구성하는 데 약 8~12시간이 필요합니다. 자료가 흩어져 있거나 팀의 공개 승인을 받아야 한다면 15~20시간까지 잡는 편이 안전합니다. 처음부터 디자인하지 말고, 90분 동안 자료를 모은 뒤 2시간 안에 텍스트 초안을 작성하십시오. 증거가 없는 부분이 드러난 다음에 시각 자료를 만드는 순서가 효율적입니다.

개인 도메인과 웹 빌더를 이미 사용하고 있다면 추가 비용 없이 게시할 수 있습니다. 새 도구가 필요할 경우에도 유료 템플릿, 차트 제작 서비스, 문장 교정 서비스를 모두 결제할 필요는 없습니다. 먼저 기존 사이트의 구성 요소로 발행하고, 모바일 가독성이나 로딩 속도처럼 실제 문제가 확인될 때 비용을 쓰는 편이 합리적입니다.

외부 피드백은 같은 직무의 동료 1명과 해당 직무를 잘 모르는 사람 1명에게 받는 구성이 좋습니다. 동료는 판단의 전문성을 확인하고, 비전문가는 설명의 이해도를 점검합니다. 두 사람에게 “이 프로젝트가 왜 실패했는가”, “작성자가 직접 바꾼 것은 무엇인가”, “다음 프로젝트에서 달라진 점은 무엇인가”라는 세 질문을 주고 15분씩 읽게 해보십시오.

1. 자료 수집 1.5~3시간: 목표 문서, 회고, 지표, 작업 기록을 모읍니다.
2. 초안 작성 2~4시간: 약 1,500~2,500자 분량으로 판단 과정을 씁니다.
3. 증거 정리 2~5시간: 차트 1~2개와 핵심 화면 3~5개만 선별합니다.
4. 검토와 익명화 1.5~3시간: 수치, 고객명, 내부 화면의 공개 범위를 확인합니다.
5. 게시 후 점검 1시간: 모바일 화면과 링크를 확인하고 30일 뒤 문의 반응을 살핍니다.

예산은 0원부터 10만 원 이내, 작업 기간은 평일 저녁 기준 1~2주면 충분합니다. 처음부터 사례 다섯 편을 만들기보다 실패 프로젝트 한 편을 10시간 안팎으로 완성하고, 공개 후 받은 질문을 반영해 30일 뒤 한 차례 수정하는 일정이 가장 현실적입니다.