AI 대체 직업, 소프트웨어 테스터는 정말 위험할까?

3줄 요약

AI 노출지수를 볼 때 우리는 내 직업이 상위 목록에 있나 없나부터 확인합니다. 등급 하나로 내 자리를 판정할 수 있다고 전제하는 셈입니다.
ILO 2025 지수에서 소프트웨어 테스터·QA가 들어가는 ISCO-08 2519는 Gradient 3에 평균 0.55인데, 이 칸의 과업 5개는 0.350·0.396·0.6625·0.665·0.6775로 두 덩어리로 갈려 있습니다. 평균 ±0.05 안에 드는 과업은 0개이고, 가장 가까운 과업까지도 0.1123 떨어져 있습니다.
등급 대신 과업별 시간 비중을 세십시오. 이 칸에서 점수가 높은 문서·정책·실행 3개 과업이 내 시간의 43% 아래로 내려가면, 같은 칸에 있어도 가중평균은 Gradient 3 구간 밖으로 내려갑니다.

Gradient 4 목록 열세 개를 처음 봤을 때 저는 안심했습니다. 자료입력원, 타이피스트, 회계·부기 사무원, 콜센터 판매원. 소프트웨어 쪽은 웹·멀티미디어 개발자 하나뿐이었고 테스터는 없었습니다. 그래서 창을 닫았습니다.

며칠 뒤 다시 열어 본 건 다른 이유였는데요, 테스터가 ISCO 코드 어디에 들어가는지 확인해 보려던 참이었습니다. 2519번 칸을 열었더니 과업 다섯 줄이 전부 테스트 이야기였습니다. 계획 문서화, 환경 구성, 요구사항 대비 확인, 실행과 결과 문서화, 정책과 스크립트. 제가 매일 하는 일이 그대로 적혀 있었습니다.

문제는 그 칸이 Gradient 3이었다는 것보다, 칸에 붙은 평균값이 제 일 어디에도 대응하지 않는다는 쪽이었습니다. 다섯 과업의 점수를 늘어놓고 나서야 알았거든요.

1. 직업 칸의 평균 0.55는 그 칸의 어떤 과업도 가리키지 않습니다

먼저 이 칸이 정말 QA의 칸인지부터 확인해야 합니다. 추측으로 시작하면 뒤의 계산이 전부 무의미해집니다.

2519가 QA·테스터 칸이라는 근거

ISCO-08 단위그룹 2519의 공식 설명문에는 이렇게 적혀 있습니다. "the group includes those professionals specializing in quality assurance, including software testing." 그리고 이 칸에 들어가는 직업 예시로 Quality assurance analyst (computers), Software tester, Systems tester 세 개를 듭니다.

칸 이름은 "Software and applications developers and analysts not elsewhere classified"입니다. 이름만 보면 개발 직군의 잔여 칸처럼 읽히지만, 실제 내용물은 품질보증입니다.

이 논문이 분석에 쓴 4자리 단위그룹은 423개입니다(군인 직군과 과업 정보가 없는 칸은 제외했다고 표 주석에 적혀 있습니다). 그 안에 테스트 전담 칸은 없고, QA는 251 소분류의 "그 밖의" 칸에 묶여 있습니다. 노출지수 기사에서 "소프트웨어 개발자는 Gradient 3"이라는 문장을 보고 자기 얘기로 읽으면, 실제로는 2512를 보고 2519를 판단한 것이 됩니다. 두 칸은 평균은 비슷하지만 뒤에서 보듯 분포가 전혀 다릅니다.

과업 다섯 개와 평균이 앉은 자리

ILO는 과업 단위 점수를 별도 페이지로 공개했습니다. 0은 자동화 불가, 1은 사람 없이 완전 수행 가능이라는 척도입니다.

ISCO-08 2519 과업	2025 점수	논문 구간 표기
(a) 테스트 계획 수립·문서화	0.665	Medium
(b) 테스트 준비용 SW·HW 설치와 OS 구성	0.350	Low
(c) 요구사항·지침 대비 정상 동작 확인	0.396	Low
(d) 테스트 실행·분석·결과 문서화	0.6625	Medium
(e) 테스트 정책·절차·스크립트 수립·구현	0.6775	Medium

다섯 개가 0.35~0.40 두 개와 0.66~0.68 세 개로 갈립니다. 그 사이 0.396에서 0.6625까지 0.2665 구간에는 과업이 하나도 없습니다. 그리고 칸의 평균 0.5502가 그 빈 구간 안에 들어앉아 있습니다. 구간 중점은 0.52925이고 평균은 58% 지점입니다.

# ILO 2025 과업 점수로 2519 칸의 평균·표준편차를 재현합니다
import statistics as st

scores = [0.665, 0.350, 0.396, 0.6625, 0.6775]   # (a)~(e)
mu = sum(scores) / len(scores)
sd = st.stdev(scores)                              # 논문은 표본표준편차를 씁니다

near = [x for x in scores if abs(x - mu) <= 0.05]  # 평균 ±0.05 안의 과업
gap = min(abs(x - mu) for x in scores)             # 평균에서 가장 가까운 과업까지

print(f"평균 {mu:.4f} / 표준편차 {sd:.4f}")        # 0.5502 / 0.1627
print(f"평균 근처 과업 {len(near)}개, 최단거리 {gap:.4f}")  # 0개, 0.1123

논문 부록표의 2519 행은 평균 0.55, 표준편차 0.16입니다. 위 재계산값 0.5502·0.1627과 맞습니다. 값 자체가 틀린 게 아니라, 이 분포에서 평균을 대표값으로 읽는 독법이 틀립니다.

2. 이웃한 여덟 칸 중 2519만 유독 넓습니다

평균이 비어 있는 게 이 지수 전체의 성질인지, 2519만의 성질인지를 갈라야 합니다. 251·252 소분류와 대조군 하나를 같이 놓고 봅니다.

표준편차 0.163은 소프트웨어 칸 중 가장 큽니다

ISCO-08	직업	과업 수	평균	표준편차	최소~최대	등급
2511	시스템 분석가	7	0.490	0.049	0.435~0.562	Gradient 2
2512	소프트웨어 개발자	8	0.527	0.071	0.450~0.655	Gradient 3
2513	웹·멀티미디어 개발자	5	0.605	0.081	0.480~0.667	Gradient 4
2514	응용 프로그래머	5	0.571	0.083	0.465~0.685	Gradient 3
2519	테스터·QA	5	0.550	0.163	0.350~0.678	Gradient 3
2521	DB 설계·관리	6	0.568	0.084	0.435~0.665	Gradient 3
2529	DB·네트워크 기타	8	0.487	0.057	0.415~0.600	Gradient 2
4132	자료입력원	5	0.700	0.029	0.662~0.738	Gradient 4

2519의 표준편차는 시스템 분석가의 3.3배, 소프트웨어 개발자의 2.3배, 자료입력원의 5.6배입니다. 점수 폭도 0.328로 표 안에서 가장 넓습니다.

왜 이 칸만 넓은지는 과업 목록을 다시 보면 짐작이 갑니다. 다섯 줄 중 셋이 문서와 정책과 스크립트를 만드는 일이고, 둘이 환경을 세우고 실물을 확인하는 일입니다. 생성형 AI가 닿는 정도가 두 무리 사이에서 크게 갈립니다. 옆 칸들의 표준편차는 0.029에서 0.084 사이에 머뭅니다.

편차가 좁은 칸에서는 평균이 실제로 대표값입니다

자료입력원 칸은 과업 다섯 개가 전부 0.662~0.738 안에 모여 있습니다. 평균 ±0.05 안에 다섯 개 전부가 들어옵니다. 이 칸에서 "평균 0.70"은 개별 과업을 거의 그대로 대신합니다.

소프트웨어 개발자 칸은 여덟 개 중 네 개가 평균 근처에 있어 절반이 대표됩니다. 2519만 0개입니다. 같은 지수, 같은 척도, 같은 등급 체계인데 평균이라는 말의 쓸모가 칸마다 다릅니다.

이 구조는 얼마 전에 정리했던 채용 도구 타당도 평균과 하한이 뒤집히던 계산과 같은 모양입니다. 평균 순위와 하한 순위가 다르면, 어느 쪽을 쓰느냐가 판단을 바꿉니다.

3. 등급은 평균이 아니라 평균과 표준편차로 같이 정해집니다

등급 이름만 보면 평균 하나로 잘린 것처럼 보입니다. 정의식을 보면 아닙니다.

정의식 다섯 줄

등급	조건
Gradient 4	평균 ≥ 0.6 그리고 평균 − 표준편차 ≥ 0.5
Gradient 3	0.5 ≤ 평균 < 0.6 그리고 평균 + 표준편차 ≥ 0.5
Gradient 2	0.4 ≤ 평균 < 0.5 그리고 평균 + 표준편차 ≥ 0.5
Gradient 1	평균 < 0.4 그리고 평균 + 표준편차 ≥ 0.5
Minimal Exposure	평균 < 0.5 그리고 평균 + 표준편차 > 0.4

Gradient 4만 조건이 다릅니다. 다른 등급은 평균에 표준편차를 더해서 위쪽을 보는데, Gradient 4는 평균에서 표준편차를 빼서 아래쪽을 봅니다. 편차가 크면 못 들어간다는 뜻입니다.

논문이 Gradient 4를 "일관성"으로 정의한 것은 의도한 설계입니다. 과업 대부분이 고르게 높아야 그 직업 전체가 자동화 압력을 받는다고 본 것이고, 저도 그 판단에 동의합니다. 다만 그 설계는 편차가 큰 칸을 한 등급 아래로 밀어 놓기만 할 뿐, 그 칸 안에서 무슨 일이 벌어지는지는 등급 이름에 남기지 않습니다. 실제 노출 직업 112개 중 Gradient 4는 13개뿐인데, 그중 여덟 개가 사무직 대분류에 속하고 셋이 금융 관련 직업입니다.

2519가 Gradient 4에 못 들어간 이유

# 논문의 등급 정의를 그대로 옮겨 판정을 재현합니다
def grade(mu, sd):
    if mu >= 0.6 and mu - sd >= 0.5:      return "Gradient 4"
    if 0.5 <= mu < 0.6 and mu + sd >= 0.5: return "Gradient 3"
    if 0.4 <= mu < 0.5 and mu + sd >= 0.5: return "Gradient 2"
    if mu < 0.4 and mu + sd >= 0.5:        return "Gradient 1"
    if mu < 0.5 and mu + sd > 0.4:         return "Minimal Exposure"
    return "Not Exposed"

print(grade(0.5502, 0.1627))   # Gradient 3
print(0.5502 - 0.1627)         # 0.3875 — Gradient 4 하한 0.5에 한참 못 미침
print(0.5502 + 0.1627)         # 0.7129 — 위쪽은 Gradient 4 평균선을 넘김

2519의 등급 판정용 하한(평균 − 표준편차)은 0.3875이고 상한(평균 + 표준편차)은 0.7129입니다. 상한만 보면 Gradient 4 문턱인 0.6을 넘고, 하한만 보면 Gradient 1 구간에 들어갑니다. 한 칸이 세 등급에 걸쳐 있는데 라벨은 하나만 붙습니다.

여기서 등급 라벨이 하는 일은 정보를 요약하는 게 아니라 버리는 쪽에 가깝습니다. 0.3875와 0.7129를 "Gradient 3"이라는 이름 하나로 바꾸면서 폭 0.3254가 사라집니다.

4. 모든 과업에 같은 가중치가 걸려 있습니다

이 지수가 과업 점수를 직업 점수로 올리는 방법은 단순 평균입니다. 논문도 그 사실을 각주에 적어 두었습니다. ISCO-08에도 폴란드 분류에도 과업별 빈도나 중요도 정보가 없어서 "all tasks are weighted equally"라고 밝힙니다.

실제 QA 팀에서 다섯 과업의 비중은 같지 않습니다

제가 있는 팀만 봐도 그렇습니다. 테스트 정책과 스크립트를 쓰는 데 시간을 대부분 쓰는 사람이 있고, 릴리스 앞두고 환경 세팅과 확인에만 붙어 있는 사람이 있습니다. ILO 계산은 이 둘에게 같은 0.55를 매깁니다.

가정한 비중을 넣어 다시 계산했습니다. 아래 비중은 제가 만든 값이고 논문에서 나온 게 아닙니다.

역할 (가정)	(a) 계획	(b) 환경	(c) 확인	(d) 실행	(e) 정책	가중평균	평균 대비	들어가는 구간
균등 가중 (ILO 기본값)	.20	.20	.20	.20	.20	0.5502	—	Gradient 3
QA 리드	.35	.05	.10	.15	.35	0.6263	+0.0761	Gradient 4 문턱
자동화 담당	.10	.10	.10	.35	.35	0.6101	+0.0599	Gradient 4 문턱
릴리스 검증 담당	.10	.15	.35	.35	.05	0.5233	−0.0269	Gradient 3
수동 테스트 담당	.10	.35	.40	.10	.05	0.4475	−0.1027	Gradient 2
입사 3개월차	.05	.50	.30	.10	.05	0.4272	−0.1230	Gradient 2

같은 직업 코드를 달고 있는 다섯 명이 0.4272에서 0.6263까지 흩어집니다. 폭 0.1992는 Gradient 3 구간 전체 폭 0.1보다 두 배 가까이 큽니다.

경계가 어디서 갈리는지

# 고노출 3과업(a·d·e)이 차지하는 시간 비중 p에 따른 가중평균
hi = (0.665 + 0.6625 + 0.6775) / 3   # 0.66833
lo = (0.350 + 0.396) / 2             # 0.37300

for target in (0.4, 0.5, 0.6):
    p = (target - lo) / (hi - lo)
    print(f"가중평균 {target} → 고노출 3과업 비중 {p*100:.2f}%")
# 0.4 → 9.14% / 0.5 → 43.00% / 0.6 → 76.86%

문서·정책·실행에 쓰는 시간이 43%를 밑돌면 Gradient 3 아래로 내려가고, 77%를 넘으면 Gradient 4 평균선에 닿습니다. 사람마다 다르고 분기마다 다른 값입니다.

43%라는 경계가 실무에서 어느 정도인지 감을 잡아 두면 쓸모가 있습니다. 주 40시간 기준으로 17.2시간입니다. 테스트 계획서를 쓰고 자동화 스크립트를 짜고 결과 리포트를 만드는 데 주 17시간을 쓰는 사람은 제 팀에서는 드물었습니다. 릴리스가 몰린 주에는 환경 세팅과 확인 쪽으로 시간이 쏠리니, 같은 사람이라도 분기 안에서 비중이 달라집니다.

한 가지 짚을 것은 위 계산이 정확히 등급 판정은 아니라는 점입니다. 등급은 평균과 표준편차를 같이 보는데, 비중을 바꾸면 표준편차도 같이 움직여서 계산이 복잡해집니다. 표의 마지막 칸은 가중평균이 어느 구간에 떨어지는지만 표시한 것이고, 논문의 등급을 다시 매긴 것이 아닙니다.

집단 평균을 개인 판정에 쓸 때 생기는 문제는 1만 시간의 법칙을 팀원 배정 근거로 검산했던 글에서도 같은 형태로 나왔습니다. 그때는 상위 집단의 집단 내 편차가 집단 간 차이의 두세 배였습니다.

5. 지수 자체가 2년 만에 옮겨 갔습니다

2025년판은 2023년판의 갱신본입니다. 같은 기관이 같은 대상을 다시 재서 숫자가 바뀌었습니다.

2023년판과 2025년판

항목	2023년판	2025년판
최고 노출 구간 고용 비중	2.3% (automation)	3.3% (Gradient 4)
그 아래 구간 합계	29.2% (augmentation 13% + big unknown 16.2%)	20.5% (Gradient 1~3)
직업 수준 평균 점수	0.30	0.29
분류 틀	3구간	4단계 등급 + Minimal + Not Exposed

아래 구간 합계가 8.7%p 줄었습니다(논문 본문은 9%p로 반올림해 적었습니다). 저자들은 2023년 사무 과업 점수가 일부 0.9까지 올라간 것을 "overly optimistic assessment"로 평가하고 하향했다고 적었습니다.

분류 틀 자체가 바뀌었으니 두 판의 칸을 1:1로 대응시킬 수도 없습니다. 2023년에 "big unknown"이던 직업이 2025년에 Gradient 2가 됐다면 그게 상승인지 하락인지 말하기 어렵습니다.

전체 그림도 같이 적어 둡니다. 세계 고용의 24%가 네 등급 중 하나에 들어가고, 최고 등급인 Gradient 4는 3.3%입니다. 고소득국은 34%, 저소득국은 11%로 소득 수준에 따라 세 배 차이가 납니다. Gradient 4 안에서는 여성 4.7% 대 남성 2.4%로 갈립니다.

점수를 매긴 사람이 누구였는가

폴란드 재직자 1,640명에게 자기 대분류 안에서 무작위로 고른 과업 35개씩을 보여 주고 0~100 척도로 자동화 가능성을 매기게 한 게 출발점입니다. 그렇게 과업 2,861개를 덮었고, 정제 후 1,535명·데이터 포인트 52,558개가 남았습니다.

응답자 관련 수치 두 개가 눈에 걸립니다. 과업의 91.5%에 대해 응답자는 자기 일에서 비슷한 과업을 해 본 적이 없다고 답했습니다. 그리고 생성형 AI를 "한 번도 써 본 적 없다"는 응답이 50.1%였습니다.

논문은 이 한계를 숨기지 않습니다. 추정치가 "upper threshold"이며 기술이 완전히 도입됐을 때의 값이라고 적고, "these new estimates reflect 'exposure' to GenAI and not the actual impact on employment"이라고 명시합니다. 2025년 초 시점의 "static snapshot"이라는 표현도 씁니다.

그러니까 이 숫자를 "몇 년 뒤 내 직업이 없어질 확률"로 읽는 건 저자들이 하지 말라고 적어 둔 일입니다.

6. 팀원 다섯 명의 과업 비중을 세는 20분

정리하면 제가 팀에서 실제로 쓰기로 한 건 등급이 아니라 그 아래 다섯 줄입니다. 등급은 대화의 출발점으로만 씁니다.

지수를 버리자는 얘기는 아니고요, 과업 단위 점수가 통째로 공개돼 있어서 그 자체로 팀 대화의 재료가 됩니다. 버려야 하는 건 그 위에 얹힌 등급 이름 하나입니다.

지금 상태에서 쓸 수 있는 것과 없는 것

쓰임	이 지수로 되나	이유
과업별로 어디가 먼저 바뀔지 순서 매기기	됨	과업 단위 점수가 공개돼 있고 5개 편차가 커서 순서가 뚜렷함
팀 학습 계획에서 무엇을 먼저 익힐지 고르기	됨	고노출 과업이 문서·정책·스크립트 쪽이라 대상이 구체적
개인의 대체 위험 판정	안 됨	과업 가중치가 균등이라 사람별 비중이 반영되지 않음
연봉·직무 협상 근거	안 됨	노출은 고용 영향 예측이 아니라고 저자가 명시
채용 규모 결정	안 됨	2년 만에 구간 합계가 8.7%p 움직인 정태 스냅샷

20분짜리 절차

팀원 한 명당 4분이면 됩니다. 저는 지난주 1:1에서 이 순서로 돌려 봤는데요, 생각보다 사람마다 답이 달라서 그 자체가 대화거리가 됐습니다.

□ 1분 — 다섯 과업 (a) 계획 / (b) 환경 / (c) 확인 / (d) 실행 / (e) 정책을 소리 내어 읽는다
□ 2분 — 지난 4주 실제 시간을 다섯 칸에 100 기준으로 나눠 적게 한다 (기억 말고 캘린더·티켓 기준)
□ 30초 — (a)+(d)+(e) 비중을 더한다
□ 30초 — 합이 43% 미만이면 '아래', 77% 이상이면 '위', 사이면 '가운데'로 표시한다
□ 이때 '위'가 안전하다거나 '아래'가 위험하다는 뜻이 아니다. 어느 과업부터 도구가 닿는지의 순서일 뿐이다

# 팀원별 비중을 넣어 한 번에 계산합니다. 비중 합은 1.0으로 맞추십시오
S = {"a": 0.665, "b": 0.350, "c": 0.396, "d": 0.6625, "e": 0.6775}

def 개인점수(w):                       # w 예시: {"a":.35,"b":.05,"c":.10,"d":.15,"e":.35}
    assert abs(sum(w.values()) - 1) < 1e-9, "비중 합이 1이 아닙니다"
    mu = sum(w[k] * S[k] for k in S)
    band = "위" if mu >= 0.6 else ("아래" if mu < 0.5 else "가운데")
    return round(mu, 4), band

팀 = {"리드": {"a":.35,"b":.05,"c":.10,"d":.15,"e":.35},
      "자동화": {"a":.10,"b":.10,"c":.10,"d":.35,"e":.35},
      "수동": {"a":.10,"b":.35,"c":.40,"d":.10,"e":.05}}
for 이름, w in 팀.items():
    print(이름, 개인점수(w))          # 리드 (0.6263,'위') 자동화 (0.6101,'위') 수동 (0.4475,'아래')

한 가지는 분명히 해 두고 싶습니다. (b) 환경 구성과 (c) 요구사항 대비 확인이 0.35와 0.396으로 낮게 나온 건 그 일이 덜 중요하다는 뜻이 아니고요, 폴란드 응답자들이 생성형 AI로 대신하기 어렵다고 본 과업이라는 뜻입니다. 낮은 점수를 저평가로 읽으면 표를 거꾸로 쓰는 셈이 됩니다.

저는 이 표를 팀 위키에 올리면서 등급 칸을 아예 지웠습니다. 남긴 건 과업 다섯 줄과 점수, 그리고 각자가 적은 비중뿐인데요. 등급을 남겨 두면 다음 분기에 누군가 그 이름만 보고 판단할 것 같아서요.

채용 시장 쪽 변화는 개발자 채용 공고에서 AI 공고 비중을 정리한 글에서 보실 수 있습니다.

이 블로그 검색

하루 로그