SFIA 9 skills 역량 체계, 작은 QA 팀 적용법

3줄 요약

SFIA 9(2024년 10월)가 단일 스킬이던 테스팅을 기능·비기능·프로세스 셋으로 나누면서, 테스팅 관련 스킬은 10종 53칸이 되었습니다.
행동 요인 12종 84칸을 더한 137칸 격자를 5명에게 적용하면 판정이 110개가 되는데, 코어 3스킬만 쓰면 15개로 줄어듭니다.
역량표를 만들 계획이라면 스킬 목록을 늘리기 전에 사람 수를 곱해 판정 개수부터 세어 보시면 됩니다.

기기 두 대까지는 아무 문제가 없었습니다. 그래서 저는 테스팅이 하나의 능력인 줄 알았습니다. 성능 테스트를 잘하는 사람이면 기능 테스트도 잘할 것이고, 기능 테스트를 오래 한 사람이면 업무 흐름 검증도 어렵지 않을 것이라고 생각했습니다. 채용 공고를 쓸 때도 "테스트 설계 경험 3년 이상"이라고 한 줄로 적었습니다.

SFIA도 오랫동안 그렇게 보고 있었습니다. 8판까지는 TEST라는 스킬 하나가 거의 모든 종류의 시스템·소프트웨어 테스팅을 덮고 있었습니다. 그런데 SFIA 재단은 9판 릴리스 노트에서 이 구조가 만든 문제를 직접 지적했습니다. 하나로 묶어 두면 "모든 테스팅이 비슷하고, 한 영역에 능숙하면 다른 영역에도 똑같이 능숙하다"는 잘못된 인상을 준다는 것입니다.

그 문장을 읽고 우리 팀 역량표를 다시 그려 봤습니다. 스킬을 셋으로 늘리는 데는 5분이 걸렸고, 그 격자를 5명에게 적용하려다 손을 놓았습니다.

1. 팀 규모별로 격자를 어디까지 여는가

먼저 결과 표를 놓고 시작하겠습니다. 아래는 제가 계산을 마친 뒤 정한 기준이고, 이후 섹션이 각 행의 근거입니다.

조건	여는 범위	한 사람당 항목	5명 기준 판정 수	갱신 주기
QA 3명 이하, 자동화 없음	코어 3스킬만	3	15	연 1회
QA 4~6명, 자동화 초기	코어 3 + 행동 3	6	30	반기 1회
QA 7~12명, 전문화 시작	코어 3 + 선택 3 + 행동 4	10	50	반기 1회
QA 13명 이상, 직군 분화	관련 10 + 행동 12	22	110	분기 1회

우리 팀은 두 번째 행입니다. 코어 3스킬은 TEST(기능), NFTS(비기능), PRTS(프로세스)이고, 행동 3은 협업·의사결정·학습개발로 골랐습니다. 5명에게 적용하면 30개 판정입니다. 반기 1회면 1인당 6개를 두 번, 한 해에 60번 판단하면 됩니다. 이 정도는 1:1 시간 안에 소화됩니다.

행동 요인 셋을 그렇게 고른 데도 이유가 있습니다. 협업은 QA가 개발·기획과 걸쳐 일하는 특성상 판정 근거가 매주 쌓입니다. 의사결정은 릴리스를 막을지 말지 판단한 이력으로 확인됩니다. 학습개발은 자동화 초기 단계 팀에서 가장 크게 갈리는 지점이라 넣었습니다. 나머지 아홉 개가 덜 중요해서 뺀 것이 아니라, 근거를 반기마다 모을 자신이 없어서 뺐습니다.

이 표를 그대로 쓰면 안 되는 조건

세 가지 조건에서는 위 표가 어긋납니다. 첫째, 침투 테스팅이나 접근성 평가처럼 규제가 요구하는 영역이 있으면 인원과 무관하게 그 스킬을 열어야 합니다. 규제 대응은 팀 크기로 조절할 수 있는 것이 아닙니다. 둘째, 외주 인력을 쓰고 계약서에 역량 기준을 적어야 한다면 상세 격자가 필요합니다. 셋째, 인사 평가와 연동할 계획이라면 항목 수를 늘리는 대신 근거 수집 방법을 먼저 정해야 합니다. 판정 근거가 없는 항목은 늘려 봐야 인상 평가가 될 뿐입니다.

2. 셋으로 나눈 근거와 그 대가

SFIA 9의 테스팅 릴리스 노트는 세 스킬이 서로 다른 지식 기반을 요구한다고 설명합니다. 요약하면 이렇습니다.

스킬	코드	무엇을 보는가	필요한 배경 지식
기능 테스팅	TEST	명세된·명세되지 않은 기능 요구사항	소프트웨어와 시스템 구조
비기능 테스팅	NFTS	성능·보안·확장성 등 품질 속성	클라우드·네트워크 등 구현 환경
프로세스 테스팅	PRTS	문서화된·문서화되지 않은 업무 흐름	해당 업무 도메인

이 구분이 실무에서 갈리는 지점을 릴리스 노트가 사례로 들고 있습니다. 상용 패키지를 도입하는 프로젝트에서는 기능이 이미 표준화돼 있으므로 기능 테스팅의 비중이 낮고 프로세스 테스팅이 결정적입니다. 반대로 여러 고객사에 파는 표준 제품을 만들 때는 미래 고객의 업무 흐름을 알 수 없으니 프로세스 테스팅이 성립하지 않고 기능 테스팅이 중심이 됩니다. 클라우드로 옮기는 작업이면 기능과 프로세스는 그대로이므로 비기능 테스팅만 크게 늘어납니다.

여기까지는 납득이 갑니다. 저희도 커머스 도메인이라 결제·정산 흐름을 보는 일과 API 응답을 보는 일은 다른 사람이 더 잘합니다. 문제는 그다음입니다.

분할이 소규모 팀에 넘기는 비용

스킬이 셋으로 늘면 평가 항목도 셋이 됩니다. 5명이면 15개입니다. 여기까지도 괜찮은데, SFIA는 테스팅 관련 스킬을 이 셋으로 끝내지 않습니다. 릴리스 노트가 "테스팅 관련"으로 함께 소개하는 스킬이 일곱 개 더 있습니다. 사용자 인수 테스팅, 서비스 인수, 품질 보증, 품질 관리, 방법론·도구, UX 평가, 침투 테스팅입니다.

전부 실제로 QA가 하는 일입니다. 저희만 해도 사용자 인수 테스팅은 기획자와 함께 매 스프린트 돌리고, 방법론·도구는 자동화 프레임워크를 고르고 유지하는 사람이 맡고 있으며, 품질 보증은 프로세스를 손볼 때마다 누군가 하고 있습니다. 목록을 보면서 "이건 우리가 안 하는데"라고 지울 수 있는 항목이 거의 없었습니다. 그래서 역량표를 만들다 보면 자연스럽게 열 개가 됩니다. 저도 그렇게 열었습니다.

덧붙이면 방법론·도구는 SFIA가 명시적으로 주의를 붙여 둔 스킬입니다. 테스트 도구를 일상 업무에서 쓰기만 하는 사람에게는 이 스킬이 필요하지 않고, 도구를 고르고 설정하고 최적화하는 책임을 지는 사람에게만 해당한다는 것입니다. 이 구분을 모르면 도구를 쓰는 전원에게 이 항목을 붙이게 되고, 표는 다섯 줄이 늘었는데 아무 판단도 달라지지 않습니다.

3. 격자를 다 그렸더니 137칸이었습니다

스킬마다 정의된 레벨 범위가 다릅니다. SFIA는 "현실에서 그 레벨로 관찰되지 않는" 조합을 아예 정의하지 않기 때문입니다. 공식 스킬 페이지에서 하나씩 확인한 값입니다.

스킬	코드	정의된 레벨	칸 수	SFIA 9 변경
기능 테스팅	TEST	1~6	6	이름 변경, 전 레벨 개정
비기능 테스팅	NFTS	1~6	6	신설
프로세스 테스팅	PRTS	1~6	6	신설
사용자 인수 테스팅	BPTS	2~6	5	이름 변경
품질 보증	QUAS	2~6	5	레벨 2 추가
품질 관리	QUMG	2~7	6	레벨 2 추가
방법론·도구	METL	2~6	5	레벨 2 추가
UX 평가	USEV	2~6	5	레벨 5 개정
서비스 인수	SEAC	3~6	4	레벨 3 추가
침투 테스팅	PENT	2~6	5	레벨 2 추가

합이 53칸입니다. 코어 3스킬만 세면 18칸이고 나머지 일곱 개가 35칸을 차지합니다.

행동 요인 쪽이 더 큽니다

SFIA 9는 행동 요인을 강조하는 방향으로 개정됐고, 이 요인들은 스킬과 달리 레벨 1부터 7까지 빠짐없이 정의됩니다. 협업, 의사소통, 개선 지향, 창의성, 의사결정, 디지털 마인드셋, 리더십, 학습개발, 계획, 문제해결, 적응력, 보안·프라이버시·윤리로 열두 개입니다. 12 곱하기 7이면 84칸입니다.

스킬 53칸에 행동 84칸을 더하면 137칸입니다. 저는 스킬 쪽만 보고 있었기 때문에 이 숫자를 보고 한참 앉아 있었습니다.

# SFIA 9 테스팅 관련 스킬의 정의 레벨 칸 수 (공식 스킬 페이지 실측, 2026-09-07 확인)
SKILLS = {
    "TEST": (1, 6), "NFTS": (1, 6), "PRTS": (1, 6),   # 코어 3종
    "BPTS": (2, 6), "QUAS": (2, 6), "QUMG": (2, 7),
    "METL": (2, 6), "USEV": (2, 6), "SEAC": (3, 6), "PENT": (2, 6),
}
skill_cells = sum(hi - lo + 1 for lo, hi in SKILLS.values())   # 53
behav_cells = 12 * 7                                           # 행동 요인은 전 레벨 정의 → 84

print(f"스킬 칸 {skill_cells} + 행동 칸 {behav_cells} = 격자 {skill_cells + behav_cells}칸")

# 사람 수를 곱한 판정 개수. 한 사람은 항목마다 레벨 하나를 받습니다
for n in (4, 5, 6):
    full = n * (len(SKILLS) + 12)      # 스킬 10 + 행동 12 = 22항목
    core = n * 3                        # 코어 3스킬만
    print(f"QA {n}명 → 전체 {full}개 / 코어만 {core}개")

사람 수를 곱하면 감당이 갈립니다

한 사람은 스킬마다 레벨 하나를 배정받습니다. 그러니 판정 개수는 격자 칸이 아니라 항목 수에 인원을 곱한 값입니다. 스킬 10개와 행동 12개를 다 쓰면 항목이 22개이고, 5명이면 110개입니다. 코어 3스킬만 쓰면 15개입니다.

110과 15는 성격이 다른 숫자입니다. 110개를 반기마다 판정하려면 연 220번인데, 근거를 모으는 시간까지 세면 1:1 시간을 통째로 여기에 써야 합니다. 저희는 1:1 주기를 주 1회 25분으로 유지하고 있는데, 이 시간을 역량 판정으로 채우면 원래 목적이 사라집니다.

더 큰 문제는 판정의 질입니다. 항목이 22개가 되면 근거가 있는 항목과 없는 항목이 섞이는데, 표 위에서는 둘이 똑같이 숫자로 보입니다. 근거 없이 적은 숫자가 절반을 넘어가는 순간 표 전체의 신뢰가 무너지고, 그다음 갱신 때 아무도 그 표를 열지 않게 됩니다. 항목을 줄이는 것은 편하려고 하는 일이 아니라, 남은 항목마다 근거를 확실히 달기 위한 조치입니다.

4. 줄이면서 걸린 세 곳

레벨 시작점이 스킬마다 다른 것

표에서 보이듯 SEAC는 3레벨부터, 대부분은 2레벨부터, 코어 3종만 1레벨부터입니다. 처음에는 이것을 표 오류로 봤습니다. 신입에게 서비스 인수 항목을 비워 두는 게 이상해 보였기 때문입니다.

SFIA의 설명은 반대였습니다. 스킬이 높은 레벨에서 시작한다는 것은 그 아래에 선행 조건이 되는 다른 스킬과 행동이 있다는 뜻입니다. 서비스 인수 3레벨로 가는 길은 서비스 인수 1~2레벨을 거치는 게 아니라 다른 스킬을 통과하는 것입니다. 그래서 비어 있는 칸을 채우려 들면 안 되고, 그 사람의 성장 경로를 다른 스킬에서 찾아야 합니다.

아는 것과 하는 것을 한 칸에 적으려는 것

두 번째로 걸린 곳입니다. 팀원 한 명이 성능 테스트 이론에 아주 밝은데 실제로 부하 테스트를 설계해 돌린 적은 없었습니다. NFTS를 몇 레벨로 적을지 한참 고민했습니다.

SFIA는 이 둘을 분리하라고 안내합니다. 레벨은 지식의 양이 아니라 그 지식으로 무엇을 하는가를 나타내고, 지식은 별도의 척도로 적으라는 것입니다. 인지·실무·숙련·전문의 4단계 척도를 예시로 제시하고 있고, 두 축은 서로 독립이라고 명시합니다. 지식이 전문가급이어도 자율성과 영향력이 없으면 SFIA 레벨은 낮게 나옵니다. 반대도 성립합니다.

그래서 저희 표는 칸을 레벨 / 지식 두 값으로 적기로 했습니다. 위 팀원은 NFTS 2 / 숙련이 됐습니다. 한 칸에 밀어 넣으려 했을 때보다 다음 분기에 무엇을 시킬지가 훨씬 분명해졌습니다.

# 팀 역량표 최소 형태 — 코어 3스킬 + 행동 3, 한 사람당 6줄
# level: SFIA 레벨(그 책임 수준으로 실제 수행한 근거가 있는 값만)
# knowledge: 인지 / 실무 / 숙련 / 전문  (레벨과 독립)
# evidence: 판정 근거. 비어 있으면 그 줄은 아직 판정된 것이 아닙니다
member: K
reviewed: 2026-09-07
skills:
  TEST: { level: 4, knowledge: 숙련, evidence: "결제 회귀 스위트 설계·자동화 주도" }
  NFTS: { level: 2, knowledge: 숙련, evidence: "부하 시나리오 리뷰 참여, 단독 설계 이력 없음" }
  PRTS: { level: 3, knowledge: 실무, evidence: "정산 배치 E2E 케이스 단독 작성" }
behaviours:
  COLL: { level: 4, evidence: "개발 스쿼드 2개 걸친 테스트 일정 조율" }
  DECM: { level: 3, evidence: "릴리스 중단 판단 2건, 근거 기록 남김" }
  LADV: { level: 4, evidence: "신규 입사자 온보딩 문서 개정 주도" }

관리자가 되어야 올라간다는 오해

세 번째는 제가 아니라 팀원이 먼저 물은 것이었습니다. 5레벨 이상은 테스트 매니저가 되어야 하는 것 아니냐는 질문이었습니다.

릴리스 노트의 FAQ가 이 질문에 직접 답하고 있습니다. 상위 레벨로 가는 데 팀 관리가 필수는 아니고, 테스팅 활동을 계획·주도하고 조직의 정책과 표준에 기여하는 것으로도 올라갈 수 있다는 것입니다. 직함과 무관하다고 못 박고 있습니다.

이 답이 있는 것과 없는 것은 차이가 큽니다. QA 4~6명 규모에서는 매니저 자리가 하나뿐이라, 승진 경로가 그 자리 하나로만 보이면 나머지 사람들의 성장 계획이 막힙니다. 자동화 프레임워크 표준을 만들고 조직에 퍼뜨리는 일로도 5레벨 근거가 된다는 것을 표로 보여줄 수 있으면 1:1 대화의 성격이 바뀝니다.

5. 시작하기 전에 확인해야 할 두 가지

라이선스가 필요합니다

SFIA는 무료로 열람할 수 있지만 모든 사용은 라이선스 하에 있습니다. 개인의 경력 개발과 대부분의 사내 인력 관리 용도는 무료이고, 아래 항목은 별도의 유료 라이선스가 필요합니다.

용도	비용
개인 경력 개발	무료
사내 인력 관리·역량 개발 (대부분)	무료
제품·서비스 판매나 마케팅에 사용	유료
외부 인증·자격 부여에 사용	유료
채용 서비스 상품으로 제공	유료
대규모 조직에서 사용	유료
계열사 포함 타 조직에 자료 재배포	유료
다른 언어로 번역해 배포	유료

저희처럼 사내 역량표로만 쓰면 무료 구간에 들어갑니다. 다만 재단 사이트의 내용을 그대로 복사해 사내 위키에 올리는 것은 재배포에 해당할 수 있으니, 원문을 옮기지 말고 링크를 걸고 우리 말로 요약해 두는 편이 안전합니다. 채용 공고에 "SFIA 4레벨 이상"이라고 적는 것이 어디에 해당하는지는 확인된 근거를 찾지 못했으므로, 그렇게 쓸 계획이라면 재단에 문의하는 편이 낫습니다.

지금 만들면 언제까지 쓰는가

SFIA 9는 2024년 10월에 나왔고 재단은 3년 주기로 갱신합니다. SFIA 10은 현재 의견 수렴 단계이며, 발행 시점을 잠정적으로 2027년 2분기에서 2028년 1분기 사이로 밝히고 있습니다. 범위가 확정되지 않아 날짜도 확정이 아니라고 명시돼 있습니다.

이 말은 지금 만든 표를 최소 1년 반은 쓴다는 뜻입니다. 동시에 SFIA 9가 8판 대비 스킬 26개를 추가하고 60개 레벨을 새로 정의했다는 것도 기억해 둘 만합니다. 다음 판에서도 비슷한 규모로 움직인다면, 스킬을 열 개 열어 둔 표는 개정 때 열 곳을 고쳐야 하고 세 개짜리 표는 세 곳만 고치면 됩니다. 이것도 항목을 적게 여는 이유 중 하나입니다.

판단 항목	코어 3스킬	관련 10스킬 + 행동 12
도입 난이도	낮음. 스킬 설명 3개를 읽으면 시작 가능	높음. 22개 항목의 레벨 정의를 팀이 공유해야 함
유지보수 비용	5명 기준 반기 30개 판정	5명 기준 반기 110개 판정
팀 학습곡선	1:1 한 번으로 설명 가능	별도 워크숍 필요, 판정 기준 합의에 시간 소요
차기 판 개정 시	고칠 곳 3군데	고칠 곳 22군데

6. 이번 주에 할 수 있는 것

표를 만들기 전에 세어 보는 일부터 하시면 됩니다. 아래 순서면 30분 안에 끝납니다.

# 1) 우리 팀 인원과 열 스킬 개수로 판정 개수를 먼저 계산합니다
python3 -c "
n, skills, behav = 5, 3, 3          # 인원, 스킬 항목, 행동 항목
per = skills + behav
print(f'1인당 {per}개 · 전체 {n*per}개 · 반기 1회면 연 {n*per*2}회 판정')
print(f'판정 1건당 5분이면 연 {n*per*2*5/60:.1f}시간')
"

# 2) 그 숫자가 1:1 시간 안에 들어가는지 봅니다
#    안 들어가면 스킬을 줄이지 말고 '항목'을 줄이십시오. 코어 3스킬은 유지합니다

# 3) 근거를 못 적는 항목은 표에서 뺍니다
#    evidence 칸이 비는 항목은 판정이 아니라 인상입니다

정리하면 저는 세 가지를 정했습니다. 코어 3스킬만 열고, 칸마다 레벨과 지식을 따로 적고, 근거를 못 쓰는 항목은 만들지 않는 것입니다. 스킬을 열 개로 늘리는 것은 팀이 7명을 넘고 성능·보안 담당이 갈라질 때 다시 보기로 했습니다.

반대로 볼 여지도 있습니다. 항목이 적으면 사람 간 차이가 잘 드러나지 않아 평가 도구로는 무디고, 나중에 늘릴 때 과거 판정과 비교가 어려워집니다. 그래도 저는 적게 여는 쪽을 택했습니다. 판정 근거를 모으지 못해 표가 방치되는 것이, 항목이 적어 해상도가 낮은 것보다 나쁘다고 보기 때문입니다. 저희 팀은 작년에 만든 역량표를 두 번 갱신하고 멈춘 적이 있고, 그때 멈춘 이유가 정확히 항목 수였습니다.

이 글의 숫자는 SFIA 9 기준이고 확인일은 2026년 9월 7일입니다. 레벨 범위는 개정될 수 있으니 표를 만들기 전에 해당 스킬 페이지를 한 번 더 보시기 바랍니다.

경력을 공식 문서로 증빙하는 방법은 고용24 통합경력증명서로 QA 경력을 증빙하는 글에 있습니다.

이 블로그 검색

하루 로그