2026 David Lee 포트폴리오 역할 표기 실패 사례 총정리

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

면접관이 프로젝트 페이지를 읽다가 가장 먼저 의심하는 순간은 화려한 결과물이 아니라 ‘그래서 David Lee가 직접 한 일은 무엇인가?’라는 질문에 답을 찾지 못할 때입니다. 팀의 성과를 개인의 성과처럼 적거나, 반대로 중요한 기여를 너무 짧게 줄이면 포트폴리오와 프로필 전체의 신뢰도가 함께 떨어집니다.

특히 2026년에는 생성형 AI와 협업 도구가 제작 과정에 깊이 들어오면서 기획자·디자이너·개발자·AI의 역할 경계가 이전보다 복잡해졌습니다. 결과 화면만 보여주는 방식으로는 전문성을 충분히 증명하기 어렵습니다. 아래 실패 사례를 통해 프로젝트 역할과 기여도를 오해 없이 표기하는 법을 살펴보세요.

실패 1. 팀 프로젝트를 혼자 완성한 것처럼 보이게 합니다

‘기획부터 출시까지 담당’이라는 문장의 함정

가장 흔한 실패는 프로젝트 소개 첫 문장에 “기획부터 디자인, 개발, 출시까지 담당했습니다”라고 쓰는 것입니다. 실제로 혼자 수행했다면 문제가 없지만, 여러 직군이 참여한 프로젝트라면 이 문장은 곧바로 과장 의심을 부릅니다. 면접에서 API 구현 방식이나 사용자 조사 표본을 질문받았을 때 답하지 못하면 다른 프로젝트의 진위까지 의심받을 수 있습니다.

포트폴리오는 단순한 작품 모음이 아니라 역량과 경험을 판단하기 위한 자료입니다. 용어의 기본 맥락은 네이버 지식백과의 포트폴리오 정의에서도 확인할 수 있습니다. 즉, 결과물을 많이 넣는 것보다 누가 어떤 조건에서 무엇을 수행했는지를 검증 가능하게 설명하는 편이 중요합니다.

예를 들어 5명이 참여한 쇼핑 앱 개편이라면 “프로젝트 총괄”이라고만 쓰지 마세요. “PM 1명, 디자이너 2명, 개발자 2명으로 구성된 팀에서 UX 리서치 설계와 결제 화면 개선을 담당”처럼 범위를 분리해야 합니다. 이렇게 쓰면 협업 성과를 훼손하지 않으면서도 David Lee의 전문 분야를 선명하게 보여줄 수 있습니다.

• 하지 말아야 할 표현: 전체 기획, 모든 디자인, 개발 총괄처럼 범위가 확인되지 않는 표현
• 권장 표현: 담당 화면, 의사결정 권한, 직접 만든 산출물과 협업 대상을 구분한 문장
• 확인 질문: 이 문장을 팀원이 읽어도 사실과 다르다고 느끼지 않을까요?
• 증빙 방법: 담당 플로, 리서치 문서, 코드 기여 범위 등 공개 가능한 자료를 역할 설명 옆에 배치

실무 팁: 역할 설명은 직함보다 동사로 쓰세요. ‘UX 디자이너’보다 ‘인터뷰 질문을 설계하고 8명을 조사해 결제 이탈 원인 3가지를 도출했다’가 훨씬 강한 증거가 됩니다.

실패 2. 기여도를 근거 없는 백분율로 표시합니다

‘기여도 80%’가 설득력을 잃는 이유

포트폴리오 프로젝트마다 기여도 70%, 80%, 100%를 붙이는 사례가 많습니다. 그러나 계산 기준이 없으면 이 숫자는 정보가 아니라 장식에 가깝습니다. 기획과 디자인, 개발의 작업량을 어떤 방식으로 환산했는지 알 수 없고, 회의 진행이나 이해관계자 조율 같은 비가시적 업무도 숫자 하나에 묻힙니다.

더 큰 문제는 여러 사람이 각자 80%라고 주장할 수 있다는 점입니다. 페이지를 검토하는 채용 담당자는 정확한 계산을 기대하기보다 지원자가 자신의 책임 범위를 정직하게 설명하는지를 봅니다. 따라서 백분율을 유지하고 싶다면 산정 기준을 밝히고, 가능하면 업무 단위 설명을 함께 제공해야 합니다.

예산 3,000만 원 규모의 웹 프로젝트를 예로 들어보겠습니다. “기여도 60%”라고만 적는 대신 “정보 구조와 와이어프레임 전량 담당, UI 디자인 12개 화면 중 7개 담당, 프런트엔드 구현에는 참여하지 않음”이라고 쓰면 판단에 필요한 정보가 생깁니다. 숫자를 빼더라도 전문성이 약해지지 않으며 오히려 검증 가능성이 높아집니다.

• 백분율을 쓴다면 업무 시간, 산출물 수 또는 책임 영역 중 어떤 기준인지 명시합니다.
• 팀 전체 작업과 개인 작업을 나란히 보여주되 같은 성과를 중복 소유하지 않습니다.
• ‘참여’, ‘관여’, ‘지원’처럼 수준이 모호한 단어 뒤에는 구체적인 행동을 붙입니다.
• 정확히 계산할 수 없다면 백분율을 과감하게 빼고 담당 범위 목록으로 대체합니다.

실패 3. 직함과 실제 행동을 뒤섞어 설명합니다

리드, 총괄, 오너라는 표현은 증거가 필요합니다

‘프로젝트 리드’라는 직함은 매력적으로 들리지만 회사마다 의미가 다릅니다. 어떤 조직에서는 일정 관리자를 뜻하고, 다른 조직에서는 최종 의사결정권자나 기술 책임자를 뜻합니다. 역할 정의 없이 직함만 강조하면 독자는 리더십의 크기를 실제보다 크게 해석하거나, 반대로 단순 진행 관리로 축소해 이해할 수 있습니다.

리더십은 직함이 아니라 선택과 책임으로 보여줘야 합니다. 요구사항이 충돌했을 때 어떤 우선순위 기준을 세웠는지, 일정이 2주 지연될 위험을 어떻게 줄였는지, 어떤 결정을 직접 승인했는지를 적어보세요. “리드 디자이너”라는 한 줄보다 의사결정 전후의 맥락이 David Lee 프로필의 전문성을 더 강하게 만듭니다.

반대로 실무 기여가 큰데도 “프로젝트 참여”라고만 쓰는 것도 실패입니다. 검색 시스템 개편에서 데이터 구조를 설계하고 핵심 기능을 구현했다면 그 사실을 작게 만들 이유가 없습니다. 겸손한 표현과 불명확한 표현은 다릅니다. 사실을 부풀리지 않되, 자신이 책임진 난이도와 영향은 정확히 밝혀야 합니다.

1. 역할명: 당시 공식 직함 또는 프로젝트 내 역할을 씁니다.
2. 책임 범위: 일정, 품질, 설계, 구현 중 무엇을 책임졌는지 밝힙니다.
3. 핵심 행동: 직접 결정하거나 제작한 내용을 동사형 문장으로 적습니다.
4. 협업 경계: 동료가 담당한 영역과 외주·파트너사의 작업을 구분합니다.
5. 검증 결과: 출시, 승인, 오류 감소 등 행동 이후의 변화를 연결합니다.

‘총괄했습니다’라는 표현 뒤에 구체적인 결정 세 가지를 붙일 수 없다면, 역할명을 더 정확한 단어로 바꾸는 편이 안전합니다.

실패 4. AI와 외부 도구의 기여를 숨깁니다

도구 사용과 전문 역량을 분리해서 보여주세요

2026년 프로젝트에서는 생성형 AI로 초안을 만들고, 노코드 도구로 프로토타입을 제작하며, 외부 템플릿이나 오픈소스를 활용하는 일이 자연스럽습니다. 문제는 도구를 사용했다는 사실이 아니라 자동 생성된 결과를 전부 자신의 수작업처럼 묘사하는 태도입니다. 질문을 받았을 때 제작 과정을 설명하지 못하면 포트폴리오의 신뢰가 급격히 낮아집니다.

그렇다고 사용한 도구를 소프트웨어 목록처럼 길게 늘어놓을 필요는 없습니다. 어떤 판단을 사람이 했고, 어떤 생산 단계를 도구가 보조했으며, 결과를 어떻게 검수했는지가 핵심입니다. 예를 들어 “AI로 카피 제작”보다 “생성형 AI로 20개 문구 초안을 만든 뒤 브랜드 가이드와 법무 기준으로 검수해 4개 안을 사용자 테스트”라고 적는 편이 좋습니다.

템플릿도 마찬가지입니다. 웹사이트 테마를 구매하는 비용은 대략 수만 원에서 수십만 원까지 다양하며, 맞춤 개발은 범위에 따라 훨씬 큰 예산이 필요할 수 있습니다. 가격 차이보다 중요한 것은 원본과 변경 범위를 밝히는 일입니다. 레이아웃은 템플릿을 사용했지만 정보 구조, 컴포넌트, 콘텐츠 전략을 직접 개선했다면 그 경계를 사례 페이지에 명시하세요.

• AI 사용: 아이디어 초안, 코드 보조, 이미지 생성 등 사용 단계를 구체적으로 표시합니다.
• 사람의 판단: 프롬프트 설계, 결과 선택, 사실 확인, 접근성 검수 과정을 설명합니다.
• 외부 자산: 템플릿, 아이콘, 오픈소스 라이브러리의 출처와 수정 범위를 확인합니다.
• 금지 사항: 라이선스를 확인하지 않은 결과물이나 고객 데이터를 AI 도구에 입력한 사례를 공개하지 않습니다.
• 면접 대비: 도구가 없어도 원리와 의사결정 기준을 설명할 수 있는지 점검합니다.

실패 5. 성과 숫자를 개인 역할과 무리하게 연결합니다

매출 상승과 전환율 개선의 인과관계를 과장하지 마세요

“리뉴얼 후 매출 200% 증가”는 눈에 잘 띄지만, 같은 기간 광고비 증가나 프로모션, 계절적 수요가 있었다면 개인의 디자인 성과라고 단정하기 어렵습니다. 프로젝트 결과를 돋보이게 하려다 인과관계를 과장하면 데이터 감각이 부족하다는 인상을 줄 수 있습니다. 숫자는 크기보다 측정 조건이 중요합니다.

성과에는 기간, 비교 기준, 데이터 출처를 함께 적어야 합니다. “전환율 30% 개선”이라면 개선 전후 수치가 2.0%에서 2.6%로 오른 것인지, 특정 버튼 클릭률이 오른 것인지 구분하세요. 그리고 David Lee가 직접 바꾼 요소와 마케팅팀·개발팀이 함께 만든 변화를 분리해야 합니다.

포트폴리오의 활용 범위는 분야에 따라 다르므로 포트폴리오 관련 개념 설명처럼 서로 다른 정의를 참고하되, 자신의 프로젝트는 독자가 재현 가능한 기준으로 작성하는 것이 좋습니다. 공개할 수 없는 내부 데이터라면 억지로 정확한 수치를 노출하지 말고 범위, 지수 또는 정성적 증거로 바꾸세요.

• 나쁜 사례: 매출 2배 달성, 사용자 만족도 대폭 증가, 운영 효율 극대화
• 좋은 사례: 출시 후 4주간 모바일 결제 완료율이 2.0%에서 2.6%로 상승
• 공동 성과 표기: 마케팅 캠페인과 결제 UX 개편이 같은 기간 진행됐음을 명시
• 비공개 데이터: 기준 시점을 100으로 둔 지수나 ‘약 15~20%’의 범위로 표현
• 대체 증거: 고객 피드백, 승인 기록, 재작업 감소, 처리 시간 단축을 활용

게시 전 이것만은 꼭 확인하세요

역할 표기 오류를 잡는 10분 검수법

완성된 프로젝트 페이지를 내부 사정을 전혀 모르는 사람의 시선으로 읽어보세요. 독자가 팀 규모, 기간, 개인 역할, 협업 범위, 성과 기준을 1분 안에 설명할 수 있다면 기본 정보가 잘 정리된 것입니다. 반대로 ‘총괄’, ‘참여’, ‘개선’처럼 해석이 넓은 단어만 기억난다면 역할 설명을 다시 써야 합니다.

가장 효과적인 방법은 문장마다 증빙 가능한지를 표시하는 것입니다. 직접 만든 파일이나 의사결정 기록이 있으면 ‘확인 가능’, 팀의 공동 기억에 의존하면 ‘공동 성과’, 추정에 가까우면 ‘수정 필요’로 분류하세요. 이 과정은 과장을 줄일 뿐 아니라 면접에서 받을 질문을 미리 발견하게 해줍니다.

마지막으로 프로젝트마다 같은 양식을 적용하되 내용까지 획일화하지 마세요. 짧은 프로젝트는 역할과 산출물 중심으로, 장기 프로젝트는 의사결정 변화와 협업 구조 중심으로 보여주는 편이 자연스럽습니다. 정확한 역할 표기는 자신을 작게 보이게 하는 장치가 아니라, 실제 전문성을 믿게 만드는 장치입니다.

1. 팀 인원과 직군이 표시되어 있는지 확인합니다.
2. 전체 프로젝트 기간과 본인 참여 기간을 구분합니다.
3. ‘우리’가 한 일과 ‘내가’ 한 일을 문장 단위로 나눕니다.
4. 담당한 화면, 기능, 문서 또는 의사결정을 구체적으로 적습니다.
5. 기여도 백분율에 계산 기준이 있는지 점검합니다.
6. 성과 수치에 기간, 비교 기준, 출처를 붙입니다.
7. AI, 템플릿, 외주, 오픈소스 사용 범위를 밝힙니다.
8. 보안 및 비밀유지계약에 어긋나는 자료가 없는지 확인합니다.
9. 팀원이 읽어도 동의할 수 있는 표현인지 검토합니다.
10. 면접에서 모든 문장의 근거를 설명할 수 있는지 소리 내어 답해봅니다.