기술을 어떻게 증명할까? 역량 증거 6단계 모델

Skills First는 학력이나 직함 같은 형식적 라벨보다 실제로 보여줄 수 있는 역량에 초점을 옮기는 접근입니다. 그러나 이것만으로 역량을 어떻게 평가할지 자동으로 해결되지는 않습니다.

OECD는 skills-first를 채용과 인재관리 관행을 조정해 사람을 demonstrated skills를 기준으로 평가하는 접근으로 설명합니다. 또한 적절한 assessment tools와 skill frameworks가 필요하다고 강조합니다. [1]

따라서 "Education"을 더 긴 "Skills" 목록으로 바꾸는 것만으로는 부족합니다. 왜 그 기술 주장을 신뢰할 수 있는지도 더 잘 설명해야 합니다.

두 사람이 똑같은 기술을 적더라도 실제 경험은 전혀 다를 수 있습니다.

두 전문가가 모두 다음과 같이 적었다고 가정해 봅시다.

Angular - 고급

첫 번째 사람은 과정을 수료하고 개인 프로젝트를 몇 개 만들었으며 framework의 기본을 이해합니다.

두 번째 사람은 3년 동안 production application을 개발했고 시스템 일부의 architecture를 담당했으며 Angular versions 간 migration을 수행했고 구체적인 결과를 제시할 수 있습니다.

일반적인 기술 목록에서는 둘이 매우 비슷해 보일 수 있습니다.

실제 차이를 보여주기 시작하는 것은 맥락이 있는 증거입니다.

이 모델은 모든 사람에게 하나의 보편적 점수를 주기 위한 것이 아닙니다. 직업에 따라 가능한 증거의 유형이 다르고, 모든 프로젝트를 공개할 수도 없습니다.

목적은 더 단순한 질문에 답하는 것입니다.

특정 역량을 신뢰할 수 있게 보여주는 근거가 얼마나 강한가?

가장 기본적인 단계는 사용자의 자기 선언입니다.

예:

• Angular
• Figma
• SEO
• 팀 리더십
• B2B 협상

검색과 discovery에는 유용하지만 증거로서의 힘은 제한적입니다.

아직 알 수 없는 것은:

• 어디에서 사용했는지,
• 얼마나 오래 사용했는지,
• 어느 규모에서 사용했는지,
• 어떤 책임을 맡았는지,
• 어떤 결과가 있었는지

자기 선언은 평가의 시작점이지 끝이 아닙니다.

기술을 어디에서 어떤 맥락으로 사용했는지 알게 되면 증거가 더 강해집니다.

단순히:

Angular

가 아니라:

물류 분야 SaaS application 개발에서 Angular를 2년간 사용.

아직 작업 품질 자체를 증명하는 것은 아니지만 중요한 맥락을 제공합니다.

• 실제 프로젝트,
• 사용 기간,
• 적용 영역,
• 작업 환경의 성격

이 단계에서 기술은 단순한 tag를 넘어섭니다.

다음 단계는 자기 선언과 경험을 실제 작업 산출물에 연결할 수 있을 때입니다.

직업에 따라 다음과 같을 수 있습니다.

• 동작하는 application,
• code sample,
• repository,
• interface design,
• prototype,
• report,
• analysis,
• campaign,
• article,
• documentation,
• financial model,
• photograph,
• engineering design,
• 완료된 작업 기록

산출물은 중요한 질문에 답합니다.

이 기술을 사용해서 실제로 만들어진 무언가를 볼 수 있는가?

Portfolio가 공식적인 역량 테스트라는 뜻은 아닙니다. 다만 인재 선발 연구에서는 실제 업무와 밀접한 work samples나 직무지식 테스트가 성과를 예측하는 데 유용할 수 있다고 봅니다. 결과는 맥락, 비용, 각 방법의 한계를 함께 고려해 해석해야 합니다. [2]

산출물이 있어도 한 가지 중요한 질문이 남을 수 있습니다.

이 사람이 실제로 무엇을 했는가?

특히 팀 프로젝트에서 중요합니다.

Application은 20명이 만들었을 수 있고, campaign은 8명이 진행했을 수 있으며, rebranding에는 agency, 내부 marketing, 외부 consultant가 모두 참여했을 수 있습니다.

그래서 더 강한 증거는 개인 기여를 명확히 설명하는 case study입니다.

좋은 case study는 적어도 다음을 구분해야 합니다.

• 문제 또는 목표,
• 전체 프로젝트 범위,
• 개인 책임,
• 실제 수행한 작업,
• 사용한 역량,
• 다른 사람과의 협업,
• 결과

예를 들어:

E-commerce platform을 만들었습니다.

보다:

Frontend architecture, checkout implementation, payment-flow integration을 담당했습니다. 프로젝트는 5명 팀이 진행했습니다.

이 설명이 더 유용한 이유는 팀 전체의 일을 한 사람의 성과로 주장하지 않기 때문입니다.

작업이 구체적인 결과로 이어지고 이를 모호하지 않게 설명할 수 있다면 증거는 더 강해집니다.

예:

Frontend
메인 화면 로딩 시간을 4.2초에서 1.8초로 단축.

UX
등록 flow 재설계 후 form 이탈 감소.

Marketing
비슷한 traffic quality를 유지하면서 cost per lead 감소.

Sales
새 customer segment를 열고 일정 수의 계약 성사.

Operations
며칠 걸리던 프로세스를 몇 시간으로 단축.

모든 직업의 결과를 퍼센트나 금액으로 표현할 필요는 없습니다. 프로필을 더 좋아 보이게 하려고 metric을 만들어내서도 안 됩니다.

좋은 질문은:

이 작업으로 무엇이 달라졌는가?

가장 강한 단계는 정보의 일부라도 프로필 소유자의 자기 주장과 독립적으로 확인할 수 있는 경우입니다.

예:

• 공개 프로젝트,
• contribution history가 있는 repository,
• 공개 publication,
• 프로젝트 참여 확인,
• 합법적으로 공개할 수 있는 고객 또는 동료 reference,
• 독립적으로 확인 가능한 결과,
• 실제로 관련된 공식 credential,
• 특정 작업을 확인하는 다른 출처

모든 프로젝트가 공개되어야 한다는 뜻은 아닙니다.

많은 중요한 프로젝트는 NDA, 영업비밀 또는 기타 비밀유지 의무가 적용됩니다.

따라서 공개 증거가 없다는 것은 역량이 없다는 뜻이 아닙니다.

독립 검증 가능성이 더 낮다는 의미일 뿐입니다.

1단계 - 자기 선언
Angular.

2단계 - 맥락
SaaS applications에서 Angular를 3년간 사용.

3단계 - 산출물
공개 application, repository 또는 표시 가능한 다른 work sample.

4단계 - 개인 기여
일부 module architecture, shared components, application migration을 담당.

5단계 - 결과
Optimization으로 main module startup time을 4.2초에서 1.8초로 단축. 수치는 예시입니다.

6단계 - 검증
결과와 기여는 공개 프로젝트, change history, reference 또는 다른 독립 출처로 추가 확인할 수 있습니다.

같은 단계의 증거라도 가치는 크게 다를 수 있습니다. 다음 다섯 관점이 해석에 도움이 됩니다.

1. 관련성 - 증거가 평가하려는 역량과 실제로 연결되는가?

2. 최신성 - 언제 사용한 역량이며, 이 분야에서 최근 경험이 얼마나 중요한가?

3. 기여와 책임 - 본인이 실제로 무엇을 했는지 알 수 있는가?

4. 맥락 - 규모, 복잡성, 책임, 자원, 작업 조건은 어떠했는가?

5. 검증 가능성 - 정보의 일부라도 독립적으로 확인할 방법이 있는가?

관련성

기술을 주변적으로만 사용한 프로젝트는 해당 역량이 핵심이었던 프로젝트보다 약한 증거입니다.

최신성

중요도는 분야마다 다릅니다. 일부 분야는 10년 전 경험도 매우 가치 있지만, 도구와 실무가 빠르게 변하는 분야도 있습니다.

기여와 책임

프로젝트와 팀이 클수록 전체 결과와 개인 기여를 분리하는 것이 중요합니다.

맥락

같은 결과도 규모, 일정, 자원, 책임, 문제 복잡성에 따라 의미가 달라질 수 있습니다.

검증 가능성

독립 검증은 항상 가능하지도, 항상 필수여야 하는 것도 아닙니다. 하지만 독립 출처가 결과나 기여를 확인하면 신뢰성이 높아집니다.

한 사람이 자신의 역할을 매우 잘 수행했어도 프로젝트 전체가 사업적으로 실패할 수 있습니다.

반대로 매우 성공한 프로젝트에 참여했지만 최종 성공에 대한 영향은 작을 수도 있습니다.

따라서 세 가지를 구분해야 합니다.

1. 역량
그 사람이 해당 종류의 일을 할 수 있는가?

2. 기여
실제로 어느 부분을 책임졌는가?

3. 결과
그 작업으로 무엇이 달라졌는가?

세 요소를 함께 볼 때 더 완전한 그림을 얻을 수 있습니다.

Certificate나 다른 formal credential도 유용한 증거가 될 수 있지만, 가치는 실제로 무엇을 확인하고 어떤 방식으로 획득했는지에 달려 있습니다.

예를 들면:

• training 수료,
• 정의된 learning outcomes 달성,
• 특정 assessment 통과,
• standard에 대한 지식,
• 공식 요건 충족

European Commission은 micro-credentials를 짧은 학습 경험으로 얻은 learning outcomes의 기록으로 설명하고, 유럽 접근법은 transparency와 quality를 강조합니다. [3]

Certificate를 실제 직업 환경에서 복잡한 업무를 독립적으로 수행할 수 있다는 자동 증거로 봐서는 안 됩니다.

따라서 credential은 가능한 증거 요소 중 하나이고 의미는 맥락에 따라 달라집니다.

프로젝트를 공개할 수 없다고 해서 가치 있는 경험이 사라지는 것은 아닙니다.

하지만 NDA, 비밀유지 의무, 영업비밀, 저작권, 데이터 보호 규칙은 portfolio를 보여주고 싶은 필요보다 우선합니다.

전문가는 계약, 적용 법률, 다른 사람과 조직의 권리가 허용하는 범위에서만 프로젝트를 설명해야 합니다. 고객 이름만 지운다고 충분한 것은 아닙니다. 다른 정보만으로도 프로젝트, 고객, 기술, 결과 또는 비밀 방법을 식별할 수 있기 때문입니다.

공개가 허용되는 경우에는 다음을 충분히 일반화해서 설명할 수 있습니다.

• 업종,
• 비밀정보를 포함하지 않은 문제의 성격,
• 자신의 역할과 책임,
• 사용한 역량,
• 허용 범위의 규모,
• 보호 데이터를 포함하지 않은 결과 유형,
• 충분히 일반화한 접근법

정보를 공개해도 되는지 확실하지 않다면 계약을 확인하거나 권리자의 허가를 받기 전까지 공개하지 않는 편이 안전합니다.

역량 증거 시스템을 모든 직업이 software development인 것처럼 설계해서는 안 됩니다.

Designer는 process, design decisions, prototype, 결과를 보여줄 수 있습니다.

Developer는 product, code, architecture 또는 technical responsibility를 보여줄 수 있습니다.

Marketer는 campaign, approach, responsibility, 결과 변화를 보여줄 수 있습니다.

Sales professional은 고객 기밀정보를 공개하지 않고 market segment, sales process, 자신의 역할과 결과를 설명할 수 있습니다.

Project Manager는 project scope, 작업 조직, constraints, delivery 영향 등을 보여줄 수 있습니다.

Photographer는 인공적인 KPI 없이 완성된 작업을 보여줄 수 있습니다.

원칙은 공통으로 유지하되, 증거 유형은 유연해야 합니다.

1. 역량이 실제로 어디에서 사용되었는지 확인합니다.

2. 작업 산출물이나 구체적인 실행 사례를 찾습니다.

3. 전문가의 개인 기여와 전체 팀의 작업을 분리합니다.

4. 의미 있게 설명할 수 있다면 결과를 살펴봅니다.

5. 경험의 최신성과 해결하려는 문제와의 유사성을 평가합니다.

6. 가능하고 적절하다면 독립적인 확인을 찾습니다.

이렇게 하면 평가는 프로필 keyword에서 증명된 역량과 구체적인 필요 사이의 실제 적합성으로 이동합니다.

이 모델은 정보를 구조화하고 사람의 판단을 지원하기 위한 것입니다. 채용, 후보자 거절 또는 전문 협업 시작을 자동으로 결정하는 판정으로 사용해서는 안 됩니다.

모든 역량에 6단계 증거가 필요한 것은 아닙니다.

더 유용한 방법은 중요한 기술마다 다음을 묻는 것입니다.

• 어디에서 사용했는가?
• 어떤 문제를 해결했는가?
• 구체적으로 무엇을 했는가?
• 작업 산출물이 있는가?
• 결과는 무엇이었는가?
• 비밀유지를 위반하지 않고 설명할 수 있는가?
• 나의 기여를 확인할 사람이나 정보원이 있는가?

단지:

Figma - 고급

에서:

B2B application의 onboarding flow를 설계했고 research, prototyping, usability testing, final design system을 담당했습니다

로 바꾸는 것만으로도 프로필 정보의 품질이 크게 좋아집니다.

Skills First는 "skill"이라는 단어가 단순한 tag 이상의 의미를 가질 때 가치가 있습니다.

역량이 전문가를 찾고 비교하는 주요 기준이 된다면 가능한 최선의 맥락과 연결해야 합니다.

experience -> portfolio -> individual contribution -> outcome -> verifiability.

모든 역량이 최고 단계에 도달할 필요는 없습니다.

목표는 프로필의 모든 항목에 의무적인 절차를 추가하는 것이 아닙니다.

전문가가 왜 자신의 기술 주장을 신뢰할 수 있는지 설명하고, 전문성을 찾는 사람이 더 나은 정보로 판단할 수 있게 하는 것이 목적입니다.

1. 선언보다 구체성 - 역량을 어디에서 어떻게 사용했는지 보여줍니다.

2. 팀 전체의 성공보다 개인 기여 - 자신의 작업을 조직 전체의 결과와 분리합니다.

3. 업무 목록보다 결과 - 가능하면 작업으로 무엇이 달라졌는지 보여줍니다.

4. 숫자 하나보다 맥락 - 조건 없는 metric은 잘못된 결론을 만들 수 있습니다.

5. 가능한 범위의 검증 - 독립 확인은 신뢰성을 높이지만, 없다고 해서 역량이 무효가 되지는 않습니다.

전문가 프로필은 기술 목록 뒤에 무엇이 있는지 독자가 추측하게 만들면 안 됩니다.

자기 선언은 역량을 발견하게 합니다. 증거는 역량을 이해하게 합니다.

6단계는 간단한 흐름으로 정리할 수 있습니다.

1. 할 수 있다고 말합니다.
2. 어디에서 사용했는지 보여줍니다.
3. 무엇을 만들었는지 보여줍니다.
4. 구체적으로 무엇을 했는지 설명합니다.
5. 결과를 보여줍니다.
6. 가능한 경우 독립 확인이 가능하게 합니다.

더 많은 질문에 답할 수 있을수록 자기 선언 하나에만 의존할 필요가 줄어듭니다.

그때 Skills First는 단순히 프로필 정보의 순서를 바꾸는 것 이상의 의미를 갖게 됩니다.

[1] OECD - A Skills-First Labour Market: Promoting skills-first hiring and talent management, 2026
출처 열기

[2] Sackett, Zhang, Berry, Lievens - Revisiting the design of selection systems in light of new findings regarding the validity of widely used predictors, Cambridge University Press, 2023
출처 열기

[3] European Commission - A European approach to micro-credentials
출처 열기

방법론 참고: [1]-[3]은 Skills First, 역량 평가, credential에 대한 넓은 맥락을 제공합니다. 역량 증거 6단계 모델 자체는 이 글에서 제시하는 독자적인 개념 모델이며, 해당 출판물의 연구 결과로 제시되는 것이 아닙니다.