내가 한 일인가, 팀이 한 일인가? 포트폴리오에서 자신의 기여를 정직하게 설명하는 방법

가치 있는 제품, 캠페인, 구축, 프로세스의 대부분은 팀으로 만들어집니다.

따라서 최종 결과만 보여주는 것으로는 특정 전문가가 실제로 어떤 역할을 했는지 알 수 없습니다.

포트폴리오를 평가하는 사람에게 다음 두 표현의 차이는 큽니다.

"구매 완료 과정의 재설계에 참여했습니다"

와

"조사를 주도하고, 새로운 구매 완료 흐름을 설계하고, 프로토타입을 만들고, 사용성 테스트를 진행했습니다. 실제 구현은 별도의 클라이언트 개발 팀이 담당했습니다."

는 같은 의미가 아닙니다.

두 번째 설명은 다른 사람의 기여를 낮추지 않으면서 실제 역량을 평가할 수 있게 합니다.

이 문제는 직업 포트폴리오에만 있는 것이 아닙니다.

학술 출판에서는 CRediT - Contributor Role Taxonomy 같은 체계가 사용됩니다. 이 표준은 14가지 기여 역할을 설명하며, 작업의 각 부분을 실제로 누가 담당했는지 더 투명하게 보여주기 위해 만들어졌습니다. CRediT는 한 사람에게 여러 역할을 부여하거나 하나의 역할을 여러 사람에게 부여할 수 있습니다. 또한 기여자가 자신에게 지정된 역할을 검토하고 확인할 기회를 갖도록 권고합니다. [1]

CRediT는 주로 연구와 학술 출판을 위한 것입니다. 직업 포트폴리오의 표준은 아닙니다. 하지만 더 넓게 적용할 수 있는 중요한 원칙을 보여줍니다. 모호하게 "프로젝트에 참여했습니다"라고 쓰는 대신 실제로 어떤 기여를 했는지 명확하게 밝히는 것입니다.

좋은 팀 프로젝트 설명은 다음 여섯 가지 정보로 구성할 수 있습니다.

1. 프로젝트 맥락
2. 팀 구성과 범위
3. 자신의 책임
4. 구체적인 행동과 의사결정
5. 작업 산출물 또는 증거
6. 결과와 그 결과의 귀속 방식

긴 보고서를 만드는 것이 목적은 아닙니다. 가장 중요한 모호함을 없애는 것이 목적입니다.

먼저 팀이 실제로 무엇을 하고 있었는지 설명하세요.

다음 항목을 간단히 제시하면 충분합니다.

• 문제 또는 목표
• 제품이나 서비스의 종류
• 대략적인 규모
• 중요한 제약
• 필요하다면 수행 기간

예시:

프로젝트 목표는 B2B 애플리케이션의 구매 과정을 단축하는 것이었습니다. 제품은 여러 유럽 시장에서 운영되었고 기업 고객을 대상으로 했습니다.

이렇게 하면 독자는 개인의 기여를 평가하기 전에 배경을 이해할 수 있습니다.

모든 사람의 이름을 적을 필요는 없습니다.

많은 경우 다음 정도면 충분합니다.

팀: 제품 관리자, 사용자 경험 디자이너, 클라이언트 개발자 2명, 서버 개발자 2명, 품질 담당자 1명.

이 정보 하나만으로도 전체 프로젝트 설명의 해석이 달라집니다.

독자는 결과가 혼자 만들어진 것이 아니라 전문가가 명확한 책임 분담 안에서 일했다는 점을 알 수 있습니다.

가장 중요한 부분입니다.

모호하게,

"클라이언트 쪽을 작업했습니다"

라고 쓰는 대신 다음처럼 구체적으로 적으세요.

"결제 모듈 아키텍처, 구매 완료 과정 구현, 결제 API 연동, 이 영역의 변경 사항에 대한 코드 검토를 담당했습니다."

오해의 여지가 있다면 자신이 하지 않은 일도 밝히는 것이 좋습니다.

"서버 계층과 결제 제공업체의 서버 측 연동은 별도 팀이 담당했습니다."

이렇게 쓴다고 포트폴리오가 약해지지 않습니다. 오히려 더 신뢰할 수 있게 됩니다.

직함만으로는 기여 내용을 알 수 없습니다.

시니어 사용자 경험 디자이너도 어떤 프로젝트에서는 전체 조사 과정을 주도하고, 다른 프로젝트에서는 최종 화면만 준비할 수 있습니다.

구체적인 역량과 연결되는 행동을 보여주세요.

• 솔루션 아키텍처를 설계했다
• 조사를 수행했다
• 프로세스 흐름을 설계했다
• 데이터를 분석했다
• 구현의 핵심 부분을 작성했다
• 캠페인 전략을 만들었다
• 협상을 주도했다
• 팀 간 의존성을 조정했다
• 출시 전에 솔루션을 검증했다

특정 결정을 왜 내렸는지 설명할 수 있는 사례가 특히 가치 있습니다.

프로젝트를 공개할 수 있다면 작업 산출물은 주장한 기여를 실제 작업과 연결하는 데 도움이 됩니다.

예를 들면:

• 제품 화면
• 인터페이스 일부
• 프로토타입
• 코드 일부
• 공개 저장소
• 보고서
• 다이어그램
• 출판물
• 캠페인 자료
• 사진
• 문서 또는 안전하게 공개 가능한 일부

산출물이 모든 것을 증명할 필요는 없습니다. 목적은 독자가 실제로 무엇이 만들어졌고 그것이 설명한 기여와 어떻게 연결되는지 이해하도록 돕는 것입니다.

자신의 기여를 과장할 위험은 결과를 설명할 때 가장 큽니다.

프로젝트 이후 회사의 전환율이 25% 상승했다고 해서 한 사람이 전환율을 25% 올렸다는 뜻은 아닙니다.

같은 기간 다음 요소도 변했을 수 있습니다.

• 가격
• 상품 구성
• 마케팅
• 사용자 경험
• 인프라
• 계절성
• 유입 경로
• 다른 팀원의 작업

결과는 실제로 근거를 제시할 수 있는 수준의 확실성으로만 설명하세요.

1. 직접 책임
"제가 담당한 단계를 자동화해 이 프로세스의 소요 시간을 12분에서 4분으로 줄였습니다."

자신의 행동과 결과의 관계가 직접적이고 근거를 제시할 수 있을 때 사용하세요.

2. 공동 결과
"팀과 함께 사용자 초기 이용 과정을 다시 설계했습니다. 출시 후 완료율이 18% 상승했습니다."

결과가 여러 사람의 작업으로 만들어졌을 때 사용하세요.

3. 더 큰 변화에 대한 기여
"더 넓은 구매 과정 개선의 일부로 구매 완료 과정 재설계를 담당했습니다. 전체 프로그램 출시 후 회사는 전환율 상승을 기록했습니다."

자신의 영역이 여러 요인 가운데 하나일 때 사용하세요.

4. 프로젝트 맥락으로서의 결과
"프로젝트 종료 후 매출이 40% 증가했습니다. 제 담당 범위는 클라이언트 측 아키텍처와 구매 완료 과정 구현이었습니다."

프로젝트 전체 결과는 알지만 그중 얼마가 자신의 작업 때문인지 판단할 충분한 근거가 없을 때 사용하세요.

여러 사람이 참여한 프로젝트라면 좋은 설명은 두 질문에 동시에 답해야 합니다.

팀은 무엇을 제공했는가?

그리고

각 사람은 무엇을 담당했는가?

예시:

프로젝트: 물류 애플리케이션의 첫 버전
팀: 사용자 경험 디자이너, 클라이언트 개발자, 서버 개발자
공동 결과: 시험 운영을 위한 작동 가능한 첫 제품 버전
사용자 경험 디자이너: 조사, 사용자 여정, 프로토타입, 인터페이스 설계
클라이언트 개발자: 클라이언트 측 아키텍처, 웹 애플리케이션 구현
서버 개발자: API, 데이터 모델, 연동

이런 설명은 팀과 개별 전문가 모두를 더 강하게 보여줍니다.

프로젝트에 따라 참여 수준을 간단히 표시하는 것이 도움이 됩니다.

주도 역할 - 해당 영역을 이끌고 핵심 의사결정을 담당했다.
공동 책임 - 한 명 이상의 사람과 책임을 나누었다.
지원 역할 - 해당 영역을 지원했지만 주 담당자는 아니었다.

CRediT도 기여자 역할에서 비슷한 구분을 사용합니다. [1]

핵심 원칙은 단순합니다. 책임 수준이 이해 가능해야 합니다.

중요한 공동 프로젝트에서는 자신의 기여 설명이 다른 참여자가 이해하는 역할 분담과 명백히 충돌하지 않는지 확인할 가치가 있습니다.

CRediT는 기여자가 자신에게 지정된 역할을 검토하고 확인할 수 있도록 권고합니다. [1]

직업 포트폴리오에서 모든 문장을 정식으로 승인받을 필요는 없습니다. 실용적인 규칙은 더 단순합니다. 실제로 다른 사람이 주도한 작업의 책임을 자신의 것으로 주장하지 마세요.

자신의 기여를 설명하는 것과 저작권 귀속을 결정하는 것을 혼동해서는 안 됩니다.

폴란드 저작권법에 따르면 저작권은 원칙적으로 저작자에게 귀속되며 공동저작자에게는 공동으로 귀속됩니다. 고용 관계 안에서 만들어진 저작물의 경우 법률과 고용관계가 정한 범위에서 사용자가 재산권을 취득할 수 있습니다. [2]

실무에서는 다음 세 질문을 따로 생각해야 합니다.

나는 프로젝트 제작에 참여했는가?
특정 요소의 저자 또는 공동저자인가?
그 자료를 내 포트폴리오에 공개할 권리가 있는가?

첫 질문에 "예"라고 답한다고 해서 나머지 두 질문의 답이 자동으로 정해지지는 않습니다.

모든 프로젝트를 공개하거나 자세히 설명할 수 있는 것은 아닙니다.

폴란드의 부정경쟁 방지법은 비밀로 관리되고 경제적 가치가 있는 특정 기술적, 기술 관련, 조직적 및 기타 정보를 포함한 영업비밀을 보호합니다. [3]

따라서 기밀 프로젝트에서 고객명만 삭제하는 것으로는 충분하지 않을 수 있습니다. 다른 세부사항을 통해 보호된 정보가 드러날 수 있습니다.

더 안전한 원칙은 다음과 같습니다.

적용 법률, 계약, 취득한 동의, 기타 보유 권리에 따라 실제로 공개할 수 있는 내용만 설명하세요.

프로젝트 설명에는 보통 팀 전체의 개인 데이터가 필요하지 않습니다.

GDPR은 적법성, 목적 제한, 데이터 최소화 등을 요구합니다. 즉 개인정보는 해당 목적에 필요한 범위로 제한해야 합니다. [4]

팀을 다음과 같이 설명하면 충분하다면:

사용자 경험 디자이너 1명, 클라이언트 개발자 2명, 서버 개발자 1명, 품질 담당자 1명

동료의 이름, 사진, 이메일 주소나 기타 개인정보를 공개할 필요는 없습니다.

특정 사람의 추천문, 발언, 이미지, 기타 데이터를 공개하려면 적절한 법적 근거와 허용되는 사용 범위를 확인하세요.

협업 조건이 경험을 일반적인 수준에서 설명하는 것을 허용한다면 다음과 같은 내용을 고려할 수 있습니다.

• 고객을 식별하지 않는 문제 유형
• 자신의 역할
• 사용한 역량의 범주
• 책임 유형
• 충분히 일반화한 의사결정 과정
• 공개가 허용되는 범위의 결과

기밀 자료를 대신하기 위해 가상의 화면, 데이터, 결과를 만들지 마세요.

특정 정보를 공개해도 되는지 확실하지 않다면 확인될 때까지 공개하지 않는 편이 더 안전합니다.

작은 표현 차이만으로도 책임 수준을 명확하게 전달할 수 있습니다.

저는 ...을 담당했습니다 - 자신의 범위를 명확하게 지정합니다.
저는 ...을 주도했습니다 - 특정 영역의 방향이나 실행에 대한 책임을 나타냅니다.
저는 ...을 공동으로 만들었습니다 - 결과에 여러 사람이 참여했음을 보여줍니다.
저는 ...을 지원했습니다 - 지원 성격의 기여를 정직하게 설명합니다.
저는 ...을 한 팀의 일원이었습니다 - 개인 참여와 팀 전체 결과를 구분합니다.
프로젝트 출시 후 회사는 ...을 기록했습니다 - 전체 효과를 자신의 것으로 주장하지 않고 결과를 맥락으로 보여줍니다.

실제 범위가 공동 작업이었다면 자동으로 "제가 했습니다"라고 표현하지 마세요.

1. 여러 사람이 수행한 프로젝트를 한 사람이 한 것처럼 표현한다.

2. 사업 결과를 보여주지만 자신의 작업 범위를 설명하지 않는다.

3. 실제로 모두 사용하지 않았는데도 제품 전체의 기술을 자신의 역량으로 적는다.

4. 최종 시각 디자인, 코드, 전략을 보여주면서 자신이 실제로 만든 부분을 설명하지 않는다.

5. 프로젝트를 이해하는 데 필요한 핵심 기여자를 생략한다.

6. 근거를 제시할 수 없는 자신의 작업과 결과 사이의 인과관계를 암시한다.

프로젝트
무엇을 만들고 있었고 어떤 문제를 해결하려 했는가?

팀
어떤 역할들이 프로젝트에 참여했는가?

나의 책임
어떤 영역을 개인적으로 담당했는가?

나의 행동과 판단
구체적으로 무엇을 했거나 주도했는가?

협업
어떤 요소를 다른 사람과 함께 만들었는가?

작업 산출물
법적으로 무엇을 보여줄 수 있는가?

결과
프로젝트는 무엇을 달성했고 내 기여는 그 결과와 어떻게 연결되었는가?

제약
비밀유지나 타인의 권리 때문에 공개할 수 없는 요소가 있는가?

스스로에게 일곱 가지 질문을 해보세요.

1. 독자는 팀 규모를 알 수 있는가?

2. 내가 정확히 무엇을 담당했는지 명확한가?

3. 다른 사람이 한 일을 내 성과로 주장하지 않았는가?

4. 결과를 적절한 주의 수준으로 설명했는가?

5. 사용한 자료를 법적으로 공개할 수 있는가?

6. 불필요한 개인정보나 기밀정보를 공개하지 않았는가?

7. 외부 사람이 이 설명만 보고 내가 실제로 어떤 역량을 사용했는지 이해할 수 있는가?

답이 명확하다면 프로젝트 설명은 단순한 흥미로운 이야기가 아니라 역량의 증거로 기능하기 시작합니다.

가장 좋은 프로젝트 설명은 다음 둘 중 하나를 고를 필요가 없습니다.

"내가 했다"

와

"팀이 했다."

두 사실을 동시에 보여줄 수 있습니다.

팀이 구체적인 결과를 만들었고, 나는 특정 부분, 의사결정, 실행을 담당했다.

이 정도의 정확성이 있으면 다른 사람의 공로를 빼앗지 않고도 전문가를 평가할 수 있습니다.

포트폴리오는 가장 큰 주장을 경쟁하는 공간이 되어서는 안 됩니다.

가치는 보는 사람이 다음을 이해할 수 있을 때 커집니다.

무엇이 만들어졌는지, 누가 작업했는지, 자신이 무엇을 담당했는지, 개인적으로 무엇을 했는지, 어떤 결과를 자신의 기여와 합리적으로 연결할 수 있는지.

정확한 설명은 성과를 약하게 만들지 않습니다.

오히려 자신의 책임을 이해하고, 다른 사람과 협업하며, 작업 결과를 정직하게 제시할 수 있다는 것을 보여줍니다.

[1] CRediT - Contributor Role Taxonomy, NISO
출처 열기

[2] 폴란드 저작권 및 관련 권리법 - 제8조부터 제12조, ELI
출처 열기

[3] 폴란드 부정경쟁 방지법 - 제11조, 2026년 공표 통합본
출처 열기

[4] 규정 (EU) 2016/679 - GDPR 제5조, EUR-Lex
출처 열기

방법론 참고: CRediT는 연구와 학술 출판에서 기여자의 역할을 표시하는 표준입니다. 이 글에서는 투명한 기여 귀속의 사례로 활용하지만, 직업 포트폴리오의 표준으로 제시하지는 않습니다. 프로젝트 설명의 여섯 요소와 결과와의 관계를 설명하는 네 가지 방식은 이 자료에서 제안하는 편집 모델입니다.