공개 프로젝트와 비공개 프로젝트, 포트폴리오 설득력은 어디서 갈릴까

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

성과가 큰 프로젝트일수록 보안 때문에 자세히 공개하기 어렵고, 공개 가능한 작업은 오히려 자신의 핵심 역량을 충분히 보여주지 못하는 경우가 많습니다. 그렇다면 채용 담당자나 잠재 고객은 무엇을 근거로 실력을 판단할까요? 이번 인터뷰에서는 디지털 제품과 서비스 분야의 포트폴리오를 검토해 온 프로젝트 커뮤니케이션 컨설턴트 한지후 씨에게 공개 프로젝트와 비공개 프로젝트를 함께 설계하는 방법을 물었습니다.

핵심은 기밀 자료를 많이 보여주는 데 있지 않습니다. 제한된 정보 안에서도 문제의 구조, 자신의 판단, 협업 범위, 검증 방식과 결과를 명확히 연결하면 충분히 강한 포트폴리오를 만들 수 있습니다. 반대로 화면과 수치를 풍부하게 넣었더라도 본인의 기여를 분리해 설명하지 못하면 설득력은 쉽게 떨어집니다.

공개 범위와 설득 범위는 왜 같지 않을까

Q. 비공개 프로젝트는 포트폴리오에 넣지 않는 편이 안전한가요?

A. 완전히 제외하는 것이 항상 안전하거나 유리한 선택은 아닙니다. 실무 경력이 쌓일수록 핵심 프로젝트에 고객 정보, 내부 지표, 출시 전 기능, 계약상 비밀유지 조항이 포함될 가능성이 커집니다. 이를 모두 빼면 실제 역량보다 얕은 경험만 남을 수 있습니다. 중요한 것은 ‘공개할 것인가’라는 이분법보다 어떤 수준까지 추상화하면 경험의 가치와 보안을 동시에 지킬 수 있는가를 판단하는 일입니다.

포트폴리오는 단순한 작품 모음이 아니라 목적에 따라 자료를 선별하고 구성한 기록입니다. 용어의 일반적인 의미는 포트폴리오에 관한 지식백과 설명에서도 확인할 수 있습니다. 따라서 원본 화면을 공개하지 못한다고 해서 프로젝트 경험 자체가 사라지는 것은 아닙니다. 원본 대신 문제의 맥락과 의사결정의 근거를 보여주는 방식으로 자료의 역할을 바꾸면 됩니다.

예를 들어 금융 서비스의 고객 이탈 개선 프로젝트라면 회사명, 실제 화면, 정확한 거래액을 숨길 수 있습니다. 대신 ‘가입 후 첫 행동으로 이어지는 비율이 낮았다’, ‘정성 인터뷰와 행동 로그를 함께 분석했다’, ‘우선순위가 높은 세 구간을 수정했다’처럼 문제와 접근법을 설명할 수 있습니다. 성과도 정확한 숫자 대신 기준 대비 개선 폭, 전후 변화의 방향, 검증 기간으로 표현하면 판단에 필요한 정보가 남습니다.

• 공개 가능: 담당 역할, 문제 유형, 사용한 방법, 의사결정 기준, 배운 점
• 조건부 공개: 익명화한 화면, 범위로 표시한 성과, 재구성한 사용자 흐름
• 비공개 유지: 고객 실명, 원본 데이터, 내부 전략 문서, 접근 권한이 필요한 링크
• 사전 확인: 근로계약서, 비밀유지계약, 클라이언트 계약, 회사의 외부 발표 기준

“보안을 지킨다는 것은 설명을 포기한다는 뜻이 아닙니다. 사실을 감추는 대신, 공개 가능한 사실 사이의 인과관계를 더 정확하게 보여줘야 합니다.”

Q. 공개 여부를 결정할 때 가장 먼저 확인할 기준은 무엇인가요?

A. 먼저 자료의 소유권과 공개 권한을 구분해야 합니다. 자신이 제작에 참여했다는 사실과 결과물을 자유롭게 게시할 권리는 같지 않습니다. 이미 회사 공식 채널에 공개된 화면이라도 내부 실험 결과나 미발표 수치를 덧붙이면 문제가 될 수 있습니다. 반대로 화면을 전혀 쓰지 않고도 업종, 문제 범주, 자신의 행동을 익명화해 설명할 수 있는 경우가 많습니다.

1. 계약서와 사내 정책에서 외부 공개 금지 범위를 확인합니다.
2. 회사명, 제품명, 고객 정보, 화면, 수치를 각각 분리해 공개 가능성을 판단합니다.
3. 공개 근거가 불명확한 자료는 사용하지 않고 대체 표현을 설계합니다.
4. 동료나 고객의 기여가 포함되었다면 본인의 역할만 명시하고 공을 독점하지 않습니다.
5. 최종 게시 전 이해관계자 또는 담당 부서에 확인할 자료를 따로 표시합니다.

결과 화면과 의사결정 증거 중 무엇이 더 강한가

Q. 화면을 많이 보여주지 못하면 포트폴리오가 빈약해 보이지 않나요?

A. 시각 자료가 적으면 첫인상이 약해질 수는 있지만, 평가자가 궁금해하는 것은 화면의 수보다 그 화면이 왜 그렇게 만들어졌는지입니다. 완성 화면 열 장을 나열하고 “사용성을 개선했습니다”라고 적는 것보다, 핵심 화면 두 장에 문제 가설과 변경 이유를 붙이는 편이 전문성을 더 선명하게 보여줍니다. 특히 경력직 포트폴리오에서는 미적 완성도만큼이나 제약 속에서 선택한 기준이 중요합니다.

비공개 프로젝트에서는 실제 UI를 그대로 캡처하기보다 구조를 단순화한 다이어그램, 텍스트 기반 사용자 흐름, 정보가 제거된 와이어프레임을 활용할 수 있습니다. 다만 원본을 재현한 자료라면 반드시 ‘보안을 위해 재구성한 예시’라고 밝혀야 합니다. 실제 산출물과 설명용 재구성물을 구분하지 않으면 작은 오해가 전체 프로필의 신뢰를 해칠 수 있습니다.

평가자는 사례를 보며 “이 사람을 우리 프로젝트에 투입하면 어떤 판단을 맡길 수 있을까?”를 상상합니다. 그러므로 각 자료에는 장식이 아니라 질문에 대한 답이 있어야 합니다. 문제 발견 자료는 왜 이 문제가 중요했는지, 실험 자료는 무엇을 확인하려 했는지, 결과 자료는 어떤 기준으로 성공과 실패를 판정했는지 설명해야 합니다.

• 문제 증거: 익명화한 사용자 불편 유형, 운영 병목, 행동 흐름의 단절 지점
• 판단 증거: 여러 대안 중 하나를 선택한 기준과 포기한 대안
• 실행 증거: 담당 업무, 협업 상대, 일정과 기술적 제약에 대응한 방식
• 검증 증거: 테스트 방법, 관찰 기간, 성공 기준, 예상과 달랐던 결과
• 학습 증거: 다음 배포나 후속 프로젝트에 실제로 반영한 변화

Q. 성과 수치를 공개할 수 없을 때는 어떻게 써야 하나요?

A. 임의의 숫자를 만들거나 모호한 성공 표현으로 덮어서는 안 됩니다. 먼저 정확한 절댓값 대신 비율, 범위, 기준 대비 변화처럼 공개 가능한 단위를 검토합니다. 예컨대 “월 매출이 3억 원 늘었다”를 쓸 수 없다면 승인받은 범위 안에서 “핵심 전환 지표가 두 자릿수 비율로 개선됐다”라고 표현할 수 있습니다. 이때 측정 기간과 자신의 기여 범위를 함께 밝혀야 과장으로 읽히지 않습니다.

숫자 자체도 전혀 공개할 수 없다면 검증 절차를 구체적으로 쓰는 방법이 있습니다. “좋은 반응을 얻었다”보다 “출시 전 사용성 테스트에서 반복적으로 관찰된 이탈 원인을 분류했고, 수정 후 동일 과업을 다시 측정했다”가 훨씬 낫습니다. 성과의 크기를 말하지 못하더라도 무엇을 어떻게 확인했는지는 역량의 증거가 됩니다.

1. 지표의 이름과 공개 가능 여부를 먼저 나눕니다.
2. 절댓값을 비율이나 범위로 바꿔도 기밀성이 유지되는지 확인합니다.
3. 프로젝트 전체 성과와 본인이 직접 만든 변화를 분리합니다.
4. 관찰 기간이 짧거나 표본이 작았다면 그 한계도 함께 적습니다.
5. 승인을 받지 못한 수치는 미련 없이 제외하고 검증 과정으로 보완합니다.

“수치를 감춘 사례보다 위험한 것은 수치의 조건을 감춘 사례입니다. 기간, 표본, 기여 범위가 없으면 큰 숫자도 믿기 어렵습니다.”

팀의 성과와 나의 기여를 어떻게 분리할까

Q. 협업 프로젝트에서 개인 기여도를 퍼센트로 적는 것이 좋을까요?

A. ‘기여도 70%’ 같은 숫자는 간단하지만 무엇을 의미하는지 불명확합니다. 기획, 디자인, 개발, 데이터 분석처럼 서로 다른 업무를 하나의 비율로 합치면 검증하기도 어렵습니다. 포트폴리오에서는 퍼센트보다 소유한 의사결정, 직접 수행한 작업, 동료와 합의한 영역을 문장으로 나누는 편이 정확합니다.

예를 들어 “온보딩 개편에 60% 기여”라고 쓰기보다 “행동 로그 분석과 사용자 인터뷰 설계를 맡았고, 발견한 이탈 원인을 바탕으로 정보 구조 초안을 제안했다. 최종 UI는 제품 디자이너와 공동으로 결정했으며 개발 우선순위는 PM과 엔지니어가 함께 조정했다”라고 작성해 보세요. 읽는 사람은 어떤 질문을 본인에게 해야 하는지 즉시 알 수 있습니다.

특히 David Lee처럼 개인 이름을 전면에 둔 포트폴리오 사이트에서는 모든 프로젝트가 한 사람의 단독 작업처럼 보이기 쉽습니다. 프로젝트 카드와 상세 페이지에 팀 구성, 역할, 참여 기간을 일관된 위치에 표시하면 오해를 줄일 수 있습니다. 프로필에 적힌 전문 분야와 각 프로젝트에서 증명한 행동도 서로 연결되어야 합니다.

포트폴리오가 분야에 따라 여러 의미로 사용된다는 점은 포트폴리오의 또 다른 용례와 정의에서도 살펴볼 수 있습니다. 개인 사이트에서는 그중에서도 선별과 증명의 기능이 중요합니다. 모든 작업을 보관하는 창고가 아니라, 자신이 맡을 수 있는 문제의 범위를 보여주는 편집물로 접근해야 합니다.

Q. 인터뷰 형식의 프로젝트 설명은 어떻게 구성하면 좋을까요?

A. 실제 면접에서 받을 법한 질문을 상세 페이지의 소제목으로 사용해 보세요. “어떤 프로젝트였나요?”보다 “왜 이 문제를 먼저 풀었나요?”, “의견이 충돌했을 때 무엇을 기준으로 결정했나요?”, “결과가 예상과 달랐던 부분은 무엇인가요?” 같은 질문이 좋습니다. 질문이 구체적일수록 답변도 행동과 근거 중심으로 바뀝니다.

각 답변은 상황, 판단, 행동, 결과, 한계의 순서로 쓰되 모든 항목을 억지로 같은 길이에 맞출 필요는 없습니다. 판단이 핵심인 사례는 비교한 대안을 길게 쓰고, 실행 속도가 강점인 사례는 일정과 조정 과정을 자세히 보여주세요. 이렇게 하면 여러 프로젝트가 같은 템플릿을 복사한 듯 보이지 않고 각 사례의 고유한 난도가 드러납니다.

• 상황: 누가 어떤 문제를 겪었고 왜 해결할 필요가 있었는가?
• 판단: 어떤 정보를 근거로 우선순위를 정했는가?
• 행동: 본인이 직접 수행하거나 결정한 일은 무엇인가?
• 결과: 무엇이 달라졌으며 어떤 방식으로 확인했는가?
• 한계: 검증하지 못한 부분과 다음 단계는 무엇인가?

화면을 숨긴 예약 서비스 사례는 어떻게 살아났나

Q. 비공개 프로젝트 하나를 처음부터 끝까지 바꾼 사례를 들려주세요.

A. 제품 디자이너 A씨는 숙박 예약 서비스 개편 프로젝트를 대표 사례로 쓰고 싶어 했습니다. 그러나 계약상 서비스명, 운영사, 실제 예약 화면, 매출과 전환율을 공개할 수 없었습니다. 처음 만든 상세 페이지에는 흐리게 처리한 화면 네 장과 “예약 경험 개선에 기여했다”는 설명만 남았습니다. 화면은 알아보기 어려웠고, 문장은 누구에게나 적용될 만큼 추상적이었습니다.

첫 단계에서는 공개할 자료를 늘리지 않고 프로젝트의 질문부터 바꿨습니다. “어떤 화면을 만들었는가?”를 “사용자가 객실을 선택한 뒤 결제를 중단하는 이유를 어떻게 좁혔는가?”로 바꿨습니다. 이어 A씨가 직접 맡은 업무를 확인하니 행동 로그 검토, 고객센터 문의 분류, 예약 단계의 정보 구조 설계, 사용성 테스트 진행이 핵심이었습니다. 반면 가격 정책과 결제 시스템 개발은 다른 팀의 책임이었습니다.

A씨는 원본 화면을 삭제하고 공개용 흐름도를 새로 만들었습니다. 흐름도에는 실제 브랜드 색상이나 문구를 쓰지 않고 ‘객실 선택→조건 확인→정보 입력→결제’라는 단계만 표시했습니다. 그리고 고객센터 문의를 그대로 인용하는 대신 의미가 같은 유형으로 묶어 ‘취소 조건을 늦게 발견함’, ‘추가 비용의 적용 시점을 이해하기 어려움’, ‘객실 옵션을 다시 비교하기 어려움’이라고 설명했습니다.

1. 문제 정의: 결제 직전 이탈을 단순한 가격 저항으로 보지 않고 정보 확인의 단절로 재정의했습니다.
2. 자료 수집: 행동 흐름과 문의 유형을 교차해 반복되는 혼란 지점을 찾았습니다.
3. 대안 비교: 한 화면에 모든 조건을 넣는 안과 단계별로 필요한 조건을 노출하는 안을 비교했습니다.
4. 실행: 예약 조건의 노출 순서와 객실 비교 복귀 동선을 설계했습니다.
5. 검증: 익명화한 테스트 과업으로 조건 발견 시간과 잘못 이해한 항목을 관찰했습니다.
6. 한계 공개: 장기 재구매 효과는 프로젝트 기간 안에 확인하지 못했다고 명시했습니다.

Q. 최종 포트폴리오 페이지에서는 무엇이 달라졌나요?

A. 상단에는 “예약 화면 개편” 대신 “결제 직전의 정보 불안을 줄인 예약 흐름 재설계”라는 한 문장을 배치했습니다. 그 아래에 업종, 참여 기간, 팀 구성, 담당 범위를 표시하고, 보안을 위해 화면과 수치를 재구성했다는 고지도 넣었습니다. 독자는 비공개라는 사실을 먼저 이해한 뒤 사례를 읽기 때문에 자료가 부족하다고 오해하지 않았습니다.

중간에는 문제 흐름도, 세 가지 문의 유형, 두 대안의 비교, 최종 결정 기준이 차례로 이어졌습니다. 정확한 전환율은 공개하지 않았지만 “수정 전후 동일 조건의 테스트에서 취소 조건을 찾지 못한 참여자가 감소했다”고 썼고, 테스트 인원과 운영 수치는 계약상 비공개라고 밝혔습니다. 성과를 부풀리지 않으면서도 무엇이 검증되었는지 판단할 수 있는 문장이 되었습니다.

페이지 마지막에는 성공담 대신 후속 판단을 남겼습니다. A씨는 조건 정보를 앞당겨 보여주는 것이 단기 과업 성공에는 도움이 됐지만, 실제 예약 완료와 취소율에 미치는 장기 효과는 별도 관찰이 필요하다고 적었습니다. 또한 다시 진행한다면 모바일의 작은 화면에서 조건 간 우선순위를 개인화하는 실험을 설계하겠다고 제안했습니다. 이 한계와 다음 행동 덕분에 사례는 완벽한 결과를 자랑하는 기록이 아니라 다음 프로젝트에서도 재현할 수 있는 문제 해결 방식으로 읽혔습니다.

• 대표 문장은 산출물보다 해결한 사용자 문제를 앞에 둡니다.
• 비공개 사유와 재구성 여부는 자료가 등장하기 전에 알립니다.
• 팀 성과와 개인 행동을 서로 다른 문장으로 씁니다.
• 공개할 수 없는 수치 대신 측정 방법과 확인된 변화의 방향을 제시합니다.
• 검증하지 못한 항목을 밝히고 다음 실험으로 연결합니다.

A씨는 면접에서도 화면의 세부 색상보다 문제를 좁힌 과정에 관한 질문을 더 많이 받았습니다. 마지막 질문은 “같은 문제를 다시 맡는다면 무엇부터 확인하겠느냐”였고, A씨는 장기 취소율과 조건별 이탈을 연결해 관찰하겠다고 답했습니다. 공개하지 못한 화면은 끝내 보여주지 않았지만, 그 화면을 만들기까지의 판단은 오히려 이전보다 또렷하게 전달됐습니다.