---
name: JD와 팀내 정의의 5단계 직무역량 설계안
author: doyoonear
status: active
related:
  - "[팀 내 기존 평가기준](../지원자평가/09-07-서비스기획-신입-실무역량-3단계-평가기준.md)"
  - "[좋은 과제 아이디어 미팅](../../../회의록/26-09-03-meeting02.md)"
  - "[대시보드 구조와 배포](../../기술설계/09-07-대시보드-구조와-배포.md)"
---

# JD와 팀내 정의의 5단계 직무역량 설계안

## 두 기준은 독립적으로 구성하고 단계의 의미를 맞춥니다

JD 기반과 팀 내 정의 기반 분류를 아래 다섯 단계로 탐색하는 설계안입니다. JD는 기업이 요구하는 업무에서 출발하고, 팀 내 기준은 제출물에서 확인하려는 네 가지 역량에서 출발합니다. 단계가 같아도 두 분류의 항목 수나 내용이 일대일로 대응할 필요는 없습니다.

```text
직무역량 대분류 → 직무역량 세부분류 → 구체적 업무 → 관찰 행동 → 관찰 사례
```

단계 | 답하는 질문 | 작성 기준
--- | --- | ---
직무역량 대분류 | 어떤 큰 역량 영역인가요? | 여러 업무를 포괄하는 영역을 구분합니다.
직무역량 세부분류 | 영역 안에서 무엇을 구별해 살펴보나요? | 업무의 목적과 판단 대상을 나눕니다.
구체적 업무 | 실제로 무엇을 수행하고 남기나요? | 작업 대상과 산출물이 드러나는 업무를 적습니다.
관찰 행동 | 그 업무를 수행할 때 무엇을 확인하나요? | 여러 상황에 적용할 수 있는 수행 기준을 적습니다.
관찰 사례 | 제출물의 어디에서 어떻게 드러나나요? | 상황과 문장·표·화면·수치 조건 등 구체적인 흔적을 함께 적습니다.

사용자는 두 분류의 5단계 구성과 행동별 2~10개 사례 작성을 요청했습니다. 이 문서의 세부 항목은 그 요청에 따른 제안이며, 9월 3일 회의에서 확정한 평가표와는 구분합니다. 실제 업무성과를 얼마나 잘 예측하는지는 후속 검토가 필요합니다.

## JD는 기존 업무를 유지하고 관찰 기준을 제안합니다

[기존 JD 3단계 데이터](../../../../dashboard/classification/depth3-data.json)의 6개 대분류·24개 세부분류·74개 업무와 SP 코드, 공고 인식 수를 유지합니다. 대시보드의 단계 라벨만 공통 명칭으로 바꿉니다.

4·5단계는 각 업무와 산출물의 의미를 바탕으로 새로 작성합니다. [JD 관찰기준 JSON](09-09-JD-기반-5단계-관찰기준-제안.json)을 별도로 관리하여 기존 JD 데이터와 새 제안을 구분합니다. 팀 내 기준을 JD의 빈칸에 복사하지 않습니다.

공고 인식 수는 기존 자동 규칙이 100건에서 찾은 업무 관련 문구의 근거 후보 수입니다. 새 관찰 행동이나 사례에 이 수치를 복제하지 않습니다. 원문별로 새 행동의 명시 여부를 대조한 작업은 수행하지 않았으며, 0건 업무에도 업무 의미에 따른 관찰 기준을 제안합니다.

표본에는 다양한 경력과 PM/PO 역할이 섞여 있습니다. 예산·전략·벤더 관리·장애 대응 같은 업무는 신입이 제공 자료로 작성할 수 있는 비교표, 검토안, 보고 초안에서 관찰하도록 구체화합니다. 실제 조직의 최종 의사결정이나 실행 책임을 신입에게 일괄 요구하지 않습니다.

## 팀 내 기준은 네 역량에서 업무와 수행 기준을 다시 나눕니다

[기존 원문](../지원자평가/09-07-서비스기획-신입-실무역량-3단계-평가기준.md)의 출발점인 문제 정의, 우선순위, 문서 작성과 생각 표현, 논리성을 대분류로 유지합니다. 그 아래는 업무 목적과 산출물을 기준으로 다시 구성합니다.

- 문제 정의에서는 사용자와 상황을 정리하고 핵심 문제, 원인 후보, 해결 범위를 정의하는 업무를 다룹니다.
- 우선순위에서는 자료를 선택하고 대안을 비교하여 실행 순서와 보류 조건을 결정하는 업무를 다룹니다.
- 문서 작성과 생각 표현에서는 결론과 상세 자료를 구성하고 정책·화면·실행 정보를 다른 사람이 사용할 수 있게 전달하는 업무를 다룹니다.
- 논리성에서는 주장과 근거를 연결하고 사실·가설·추정을 구분하며 반대 가능성과 후속 검증을 검토하는 업무를 다룹니다.

예를 들어 ‘포함 범위 설정’과 ‘제외 범위 설정’은 같은 업무 안에서 범위의 경계를 정하는 관찰 행동으로 묶을 수 있습니다. 관찰 사례에서는 신규 가입자의 최초 설정은 포함하고 기존 사용자 화면은 제외하는 식으로 실제 판단을 보여줍니다.

[팀 내 5단계 JSON](09-09-팀내-정의-기반-5단계-직무역량-제안.json)을 새 분류의 정본으로 관리합니다. 기존 68개 행동과 원문 사례는 원문 파일에 그대로 보존하고, 새 관찰 행동의 `sourceIds`로 연결합니다. 새 트리의 TC 코드와 기존 TEAM 코드는 구별합니다. 기존 TEAM 항목 링크와 검색은 연결된 새 관찰 행동을 찾는 데 사용합니다.

## 제안한 항목 수는 업무 범위에 따라 다릅니다

기준 | 대분류 | 세부분류 | 구체적 업무 | 관찰 행동 | 관찰 사례
--- | --- | --- | --- | --- | ---
JD 기반 | 6 | 24 | 74 | 103 | 256
팀 내 정의 기반 | 4 | 12 | 25 | 31 | 130

JD에는 행동마다 2~3개 사례가 있습니다. 팀 내 기준에는 행동마다 3~6개 사례가 있으며, 기존 원문 사례 68개와 새 사례 62개를 포함합니다. 단계별 수는 서로 맞추지 않고 각 출발점의 범위에 따라 정했습니다.

팀 내 ‘문제 정의’의 한 경로는 다음과 같습니다.

```text
문제 정의
→ 해결 목표와 작업 경계 정의
→ 대상·기능별 포함 및 제외 범위표 작성
→ 개선에 포함할 대상과 기능을 제외 대상과 나란히 명시해 작업 경계를 설명합니다.
→ 국내 지점의 시간 단위 예약 확정 알림은 포함하고,
   월 단위 사무실 계약과 해외 지점 결제는 제외한 범위표를 작성합니다.
```

## 사례의 수보다 행동과의 구체적인 연결을 확인합니다

각 관찰 행동에는 최소 2개, 최대 10개의 사례를 둡니다. 사례의 수는 업무의 폭과 구별할 상황에 따라 정합니다. 같은 문장의 대상만 바꾸거나 같은 판단을 반복해 수를 채우지 않습니다.

사례는 다음 중 필요한 차이를 보여줍니다.

- 사용자의 상태나 서비스 상황이 달라질 때 판단이 어떻게 드러나는지 보여줍니다.
- 정상 흐름과 오류·예외 조건을 구별합니다.
- 같은 행동이 문장, 비교표, 화면 또는 기록에 어떻게 나타나는지 보여줍니다.
- 자료가 충분한 경우와 확인할 정보가 남은 경우를 구별합니다.

모든 사례는 가상 과제의 관찰 예시입니다. 수치·기간·인력 조건은 예시의 조건이며 실제 기업이나 지원자의 성과를 뜻하지 않습니다. 팀 내 원문 사례는 원문 출처를 표시하고, 추가 사례는 새 제안으로 표시합니다.

## 화면은 다섯 단계와 근거를 함께 탐색하도록 바꿉니다

- 하나의 분류 메뉴와 JD·팀 내 전환 버튼을 유지합니다.
- 두 화면에 같은 다섯 단계 라벨과 실제 항목 수를 표시합니다.
- 대분류와 세부분류를 펼쳐 업무 목록을 보여주고, 업무별 관찰 행동과 사례는 접어서 탐색합니다.
- 검색은 모든 단계와 사례를 대상으로 하며 검색된 항목의 상위 경로를 함께 보여줍니다.
- 기존 비교 리포트는 상단에 유지하고 팀 내 링크·문구는 재구성한 항목에 맞춥니다.
- JD 원자료, 기존 팀 내 원문, 새 설계안과 두 JSON을 출처로 연결합니다.
- 와이어프레임, 회의 결정, 실제 서비스의 평가 가중치와 점수는 변경하지 않습니다.

## 구조와 내용은 별도로 검토합니다

구조 검증에서는 JD 6·24·74개 항목과 통계 보존, 양쪽 5단계, 코드의 고유성, 모든 업무의 행동 존재, 행동별 사례 2~10개, 기존 TEAM 68개 근거의 추적 여부를 확인합니다. 검색·코드 이동·원문 링크·오프라인 실행은 자동 테스트와 브라우저에서 확인합니다.

내용 검토에서는 업무와 행동의 포함 관계, 행동과 사례의 연결, 가상 조건의 구체성, 문서 전달력과 논리적 타당성의 구분을 확인합니다. 자동 테스트 통과만으로 평가기준의 타당성을 확정하지 않습니다.

## 구현 순서

- [x] 두 출발점의 항목과 사례를 독립적으로 작성하고 JSON으로 저장했습니다.
- [x] 원자료 보존과 5단계 구조·사례 수·출처 연결 검증을 추가했습니다.
- [x] 트리 렌더링, 검색, 코드 이동, 비교 리포트와 출처 표시를 갱신했습니다.
- [x] 빌드·테스트·브라우저와 문장 검토 결과를 확인했습니다.

2026년 9월 9일 기준 Node 테스트 74개와 Python 테스트 14개를 통과했습니다. 원본 화면과 배포 산출물을 네트워크 없이 열어 320·390·768·1440px에서 각각 43개 브라우저 점검을 통과했습니다. 모든 단계의 항목 이동과 포커스, 이전 TEAM 코드, 검색, 전체 펼침·접기, 뒤로·앞으로 이동, 브라우저의 주소 상태 저장이 제한될 때의 대체 동작을 확인했습니다.

콘텐츠는 JD 103개 행동·256개 사례와 팀 내 31개 행동·130개 사례를 각각 독립 검토했습니다. 중복 제거의 행 수, 서비스 정상 판정의 범위, 사용자 문제를 뒷받침하는 관찰 근거, 팀 내 문제 설명의 범위를 보완했습니다. 기존 원문 사례는 수정하지 않았습니다. `humanizer`와 프로젝트 문장 기준으로 새 설명의 의미·수치·출처를 다시 확인했습니다.

새 제안은 기존 원문과 별도 파일로 관리하므로, 제안 수정 시 기존 JD 통계와 팀 내 원문을 다시 작성할 필요가 없습니다. 커밋·PR 게시·main 반영은 이번 요청의 작업 범위에 포함하지 않습니다.