개발 공고는 코로나 이전의 74%, AI 공고 비중은 사상 최고 6.3%

이직 시장을 한 번 열어 보신 분들은 비슷한 감각을 갖고 계실 겁니다. 공고 수 자체는 확실히 줄었는데, 남아 있는 공고의 요구사항은 오히려 늘어나 있습니다. "AI 기반 테스트 도구 경험", "LLM 활용 자동화 경험" 같은 문구가 QA 공고에도 붙기 시작합니다. 팀원과 1:1을 하면 "지금 뭘 배워야 하냐"는 질문이 나오는데, 답할 근거가 마땅치 않습니다.

여기서 리드가 취할 수 있는 태도는 셋입니다. 첫째, 시장이 어렵다고 인정하고 현 업무에 집중하자고 말합니다. 둘째, AI 관련 학습을 팀 OKR에 넣습니다. 셋째, 숫자를 먼저 확인하고 어느 방향이 실제로 수요가 있는지 확인한 뒤 우선순위를 정합니다.

결론부터 말씀드리면, 8월 24일에 나온 두 개의 자료가 셋째를 할 수 있게 해 줍니다. 요지는 두 문장으로 정리됩니다. 소프트웨어 개발 직군 공고는 코로나 이전 수준의 74% 근처에 머물러 있지만 저점에서는 뚜렷하게 회복했고, AI 관련 공고 비중은 2022년 직전 최고치의 두 배에 가까운 수준까지 올라왔습니다. 이 두 숫자를 나란히 놓으면 팀원에게 할 말이 생깁니다.

1. 8월 24일에 나온 숫자들

1-1. Indeed Hiring Lab의 8월 스냅샷

Indeed Hiring Lab이 2026-08-24 18:27 UTC(KST 2026-08-25 03:27)에 공개한 "US Labor Market Snapshot — August 2026"의 수치를 원문 그대로 옮깁니다.

지표	원문 수치	기준 시점
전체 채용공고 지수(JPI)	"101.8" (2020년 2월 1일 대비 +1.8%)	as of August 14, 2026
신규 공고	"97.2" (2020년 2월 대비 약 -3%)	동일
JPI 월간 변화	"0.2%"	as of August 14
JPI 전년 대비 변화	"-2.9%"	동일
Software Development 공고	"74.4"	동일
Software Development 저점	"61.1 in May 2025"	2025년 5월
AI 관련 공고 비중	"6.3%" (직전 최고 "3.3% in 2022")	2026년 8월
게시 임금 상승률	"2.5%"	year ending July 2026
실질 임금(민간, 전년비)	"-0.4%"	Q2 2026
실업률	"4.1%"	July 2026
공석/실업자 비율	"1.0" (4개월 연속)	June 2026

미국 데이터라는 점은 분명히 짚어 두겠습니다. 한국 QA 채용 시장에 그대로 대응하지 않습니다. 다만 도구 벤더와 프레임워크 생태계가 미국 시장을 따라가기 때문에, 요구 스킬의 이동 방향을 읽는 데는 유효한 선행 지표라고 봅니다.

1-2. 74.4와 6.3%를 붙여 읽기

74.4는 전체 지수 101.8과 대비하면 초라합니다. 전체 시장은 코로나 이전을 회복했는데 소프트웨어 개발 직군만 26% 낮은 자리에 있습니다. 그런데 저점인 61.1에서 74.4까지는 약 22% 올라온 것이기도 합니다. Indeed의 표현은 "demand for these roles has rebounded over the past year or so"입니다.

한편 AI 관련 공고 비중 6.3%는 2022년 정점 3.3%의 거의 두 배입니다. 인포그래픽 문구는 "AI-related postings have climbed to 6.3%, well past their prior peak of 3.3% in 2022"입니다.

제 해석으로는 이 조합이 말하는 바는 "AI가 개발 일자리를 없애고 있다"가 아닙니다. 전체 파이가 줄어든 상태에서 파이 안의 배분이 이동하고 있다는 것입니다. 이 차이가 중요한 이유는 대응이 완전히 다르기 때문입니다. 파이가 없어지는 것이면 직군을 옮겨야 하고, 배분이 이동하는 것이면 그 안에서 위치를 옮기면 됩니다.

2. 개인 생산성은 오르고 팀 협업은 아니다

2-1. 같은 날 나온 두 번째 자료

같은 8월 24일 Stack Overflow 블로그에 Gleb Tsipursky의 기고 "Responsible AI adoption needs developer workflow design"이 올라왔습니다. 1차 조사가 아니라 오피니언이고, 인용된 수치는 모두 재인용이므로 그 점을 감안해 읽어야 합니다.

그중 QA 관점에서 가장 쓸모 있는 두 문장입니다.

• "84% of respondents use or plan to use AI tools, while more developers distrust AI accuracy than trust it. The leading frustration involves outputs that look almost right but require extra debugging." (원 출처는 survey.stackoverflow.co/2025)
• "Stack Overflow's survey also found that agents indicate gains in individual productivity but not team collaboration."

그리고 2024 DORA 연구를 인용한 부분이 있습니다. "higher AI adoption correlated with improvements in documentation quality, code quality, and review speed, while also identifying possible negative effects on software delivery performance."

2-2. "거의 맞아 보이는데 디버깅이 더 든다"

QA 리드 입장에서 가장 익숙한 문장이 "outputs that look almost right but require extra debugging"입니다. 저희도 AI가 생성한 Appium 테스트를 리뷰해 본 적이 있습니다. 문법은 완벽했고, import도 맞았고, 셀렉터 전략도 그럴듯했습니다. 문제는 검증 단계였습니다. 화면 전환 후 요소가 존재하는지만 확인하고, 그 요소에 표시된 값이 맞는지는 확인하지 않았습니다. 케이스는 초록색으로 통과하는데 아무것도 검증하지 않는 테스트였습니다.

이 종류의 결함이 위험한 이유는 리뷰 통과율이 높기 때문입니다. 읽으면 맞아 보입니다. 그래서 저는 AI 생성 테스트에 대한 리뷰 기준을 따로 두는 편이 낫다고 봅니다.

확인 항목	사람이 쓴 테스트	AI가 쓴 테스트
문법·컴파일	자주 틀림	거의 안 틀림
셀렉터 안정성	편차 큼	그럴듯하나 실측 필요
단정문(assertion)의 실질	대체로 있음	존재 확인만 하는 경우가 많음
실패 시 메시지 품질	편차 큼	일반적 문구로 채워짐
테스트 의도의 문서화	커밋 메시지에 있음	없거나 생성된 주석뿐

이 표에서 굵게 표시한 줄이 리뷰 체크리스트의 1번이 되어야 합니다. "이 테스트를 일부러 깨뜨리면 실패하는가"를 한 번 확인하는 것으로 충분합니다.

2-3. 도입 지표를 라이선스 수로 세지 않기

기고문이 제안하는 프레임은 NIST의 네 기능("Govern, Map, Measure, and Manage")과 OWASP 생성형 AI 위험 목록("prompt injection, sensitive information disclosure, supply-chain weaknesses, improper output handling, and excessive agency")입니다. 이걸 그대로 스타트업 QA 조직에 적용하기는 무겁습니다.

제가 실제로 쓸모 있다고 보는 건 훨씬 단순합니다. "개인 생산성은 오르지만 팀 협업은 아니다"라는 관찰이 사실이라면, 도입 성과를 개인 단위로 측정하는 순간 지표가 부풀려집니다. 그래서 측정 단위를 팀으로 올려야 합니다.

흔히 쓰는 도입 지표	문제	대체
라이선스 활성 사용자 수	쓰기만 하면 올라감	수용된 AI 산출물 비율
생성된 테스트 케이스 수	품질과 무관	생성 케이스 중 6개월 내 결함 검출 건수
개인별 커밋·PR 증가량	리뷰 부담이 동료로 이전	팀 전체 리뷰 대기 시간
체감 만족도 설문	신규성 효과	AI 산출물 교정에 쓴 시간

3. 그래서 팀에 무엇을 배우게 할 것인가

3-1. 두 숫자에서 도출되는 우선순위

AI 관련 공고 비중이 6.3%라는 건 아직 93.7%는 AI를 명시하지 않는다는 뜻입니다. 저는 이 지점을 팀원에게 솔직하게 말하는 편이 낫다고 봅니다. AI 스킬만 쌓으면 된다는 신호가 아닙니다. 기존 역량이 여전히 대부분이고, AI 관련 역량이 차별화 요소로 빠르게 부상하는 중이라는 신호입니다.

그래서 학습 우선순위를 이렇게 잡았습니다.

순위	역량	근거	우리 팀 현재 수준
1	파이프라인·CI 이해 (실패 원인 규명)	AI 도구가 늘수록 검증 병목이 커짐	1~2명만 가능
2	AI 산출물 검증 능력 (테스트의 테스트)	"almost right" 문제의 직접 대응	전원 부족
3	프롬프트·컨텍스트 설계	Roblox의 exemplar 사례처럼 성과가 컨텍스트에서 나옴	개인차 큼
4	도메인 지식 문서화	AI에 먹일 컨텍스트의 원재료	암묵지로만 존재
5	신규 AI 테스트 도구 사용법	도구는 6개월마다 바뀜	후순위

5번을 마지막에 둔 것이 의도적입니다. 도구 사용법은 가장 눈에 잘 보이는 학습 항목이고 가장 빨리 진부해집니다. 4번을 3번보다 아래에 두었지만 실제로는 4번이 3번의 전제입니다.

3-2. 1:1에서 쓸 수 있는 질문 세트

숫자를 공유하는 것만으로는 대화가 진행되지 않습니다. 저는 아래 순서로 물어봅니다.

[ AI 스킬 관련 1:1 질문 순서 ]

1. 최근 한 달 안에 AI 도구가 만든 산출물을 검토한 적이 있나요?
   → 없다면: 노출 자체가 없는 상태. 학습보다 노출 기회 배정이 먼저입니다.
   → 있다면: 2번으로.

2. 그때 무엇을 고쳤나요? 구체적으로 어느 줄이었나요?
   → "전반적으로 다듬었다"는 답: 검증 기준이 없는 상태입니다.
   → 특정 단정문/셀렉터를 지목: 이미 검증 역량이 형성되고 있습니다.

3. 그 수정을 다음 사람이 반복하지 않게 하려면 어디에 적어야 할까요?
   → 이 질문이 개인 학습을 팀 자산으로 전환시키는 지점입니다.

4. 지금 배우고 싶은 것과, 팀에 필요한 것이 다르다면 어디가 다른가요?
   → 여기서 나오는 간극이 다음 분기 학습 계획의 실제 입력값입니다.

3번 질문이 핵심입니다. Roblox 발표에서 수용률을 55%에서 70%까지 올린 수단이 exemplar 문서화였다는 점과 같은 이야기입니다. 개인이 고친 내용이 문서로 남지 않으면 팀 수준은 올라가지 않습니다.

3-3. 학습 시간을 확보하는 현실적인 방법

QA 4~6명 규모에서 학습 시간을 따로 떼어내기는 어렵습니다. 저는 별도 시간을 만들지 않고 기존 작업에 붙이는 방식을 씁니다.

# 목적: 학습을 별도 일정으로 만들지 않고 기존 리뷰 흐름에 붙입니다.
# 운영: 주 1회 30분. 안건은 그 주에 실제로 있었던 것만.
ai_review_ritual:
  주기: 매주 목요일 30분
  참석: QA 전원 + 원하는 개발자
  안건:
    - 이번 주 AI 생성 산출물 1건 골라 화면 공유
    - 규칙: 잘 된 것 말고 "고친 것"만 다룬다
    - 고친 이유를 한 문장으로 적고 exemplar 문서에 추가
  산출물:
    - team-docs/ai-review-exemplars.md 에 항목 1~3개 추가
  금지사항:
    - 도구 소개·데모 시청 (이건 학습이 아니라 정보 소비입니다)
    - 결론 없이 끝내기 (문서 항목 0개면 그 회차는 실패로 기록)

금지사항 두 줄이 실효를 만듭니다. 이런 자리는 방치하면 도구 데모 감상회가 됩니다. 문서 항목 개수를 성공 조건으로 못 박으면 대화가 구체적인 곳으로 내려갑니다.

4. 함정 셋

4-1. 첫 번째 함정: 미국 데이터를 한국 시장으로 그대로 읽는다

증상은 팀원에게 "개발 공고가 74.4까지 회복했다"고 말했다가 신뢰를 잃는 것입니다. Indeed JPI는 미국 Indeed 게시물 기준 지수입니다. 원인은 지수의 모집단을 확인하지 않은 것입니다. 대응은 인용할 때 반드시 "미국 Indeed 기준"을 붙이고, 절대 수준이 아니라 방향성만 인용하는 것입니다.

4-2. 두 번째 함정: 재인용 수치를 1차 데이터로 말한다

증상은 "Stack Overflow 조사에서 84%가 AI를 쓴다"고 인용했는데 출처를 물었을 때 답이 막히는 것입니다. 위 기고문이 인용한 84%는 2025년 조사 결과입니다. 2026년 조사는 개시 공지만 있고 결과는 아직 발표되지 않았습니다. 원인은 기고문의 발행일과 데이터의 조사연도를 혼동한 것입니다. 대응은 수치를 인용할 때 조사연도를 함께 적는 것입니다.

4-3. 가장 비싼 함정: 학습을 개인 숙제로 넘긴다

증상은 6개월 뒤에도 팀 역량이 그대로인 것입니다. 각자 강의를 듣고 각자 도구를 만져 보았지만 공유된 판단 기준은 생기지 않았습니다. 원인은 학습 성과를 개인 단위로 정의한 것입니다. "개인 생산성은 오르지만 팀 협업은 아니다"라는 관찰이 학습에도 적용됩니다.

가장 비싼 함정이라고 부르는 이유는 되돌리는 데 다시 6개월이 걸리기 때문입니다. 대응은 학습의 산출물을 처음부터 팀 문서로 정의하는 것입니다. 개인이 무엇을 알게 되었는지가 아니라, 팀 문서에 무엇이 추가되었는지로 셉니다.

함정	증상	원인	대응
미국 데이터 직역	인용 후 신뢰 상실	지수 모집단 미확인	"미국 Indeed 기준" 병기, 방향성만 인용
재인용을 1차로 말함	출처 질문에 막힘	발행일과 조사연도 혼동	조사연도 병기 (예: SO 2025 조사)
학습을 개인 숙제로	6개월 후 팀 역량 정체	성과를 개인 단위로 정의	산출물을 팀 문서 항목 수로 정의

5. 도입 평가

항목	도입 난이도	유지보수 비용	팀 학습곡선	판단
시장 수치 팀 공유 (분기 1회)	낮음 (2시간)	낮음	낮음	즉시
AI 산출물 리뷰 체크리스트	낮음 (1일)	낮음 (분기 갱신)	낮음	즉시
주 1회 30분 리뷰 리추얼	낮음	중간 (진행 담당 필요)	중간	즉시
exemplar 문서 운영	중간	중간 (방치되면 죽음)	중간	2주 후
도입 지표를 팀 단위로 전환	중간	낮음	높음 (합의 필요)	병행
JD·평가기준 개정	높음 (인사 협의)	낮음	높음	다음 분기

exemplar 문서의 유지보수 비용을 중간으로 잡은 이유는 기술이 아니라 관성입니다. 이런 문서는 3주째에 죽습니다. 주 1회 리추얼과 묶어서만 살아남습니다.

6. 권할 만한 경우 / 권하지 않는 경우

권할 만한 경우

• 1:1에서 "뭘 배워야 하나"라는 질문을 받은 적이 있는 리드
• AI 도구 도입은 했는데 팀 역량 변화가 체감되지 않는 팀
• 다음 분기 학습 OKR을 짜야 하는 상황 — 위 우선순위 표가 초안이 됩니다
• JD를 다시 쓸 예정인 조직 — 6.3%라는 수치가 요구사항 수위 조절의 근거가 됩니다

권하지 않는 경우

• 팀에 AI 도구 노출 자체가 아직 없는 경우 — 학습 계획보다 노출 기회 배정이 먼저입니다
• 이번 분기 릴리스 일정이 이미 위태로운 팀 — 주 1회 30분도 부담입니다. 다음 분기로 미루십시오
• 시장 수치를 팀 불안 자극에 쓸 우려가 있는 경우 — 이 숫자는 방향을 정하는 데 쓰는 것이고, 압박에 쓰면 역효과가 확실합니다
• 인사·평가 권한이 없는 상태에서 JD부터 손대려는 경우 — 순서가 반대입니다

이번 주에 그대로 쓸 체크리스트

[ 리드가 이번 주에 할 것 ]
□ 위 Indeed 표에서 3줄만 골라 팀 채널에 공유한다 (74.4 / 61.1 / 6.3%)
□ 공유 시 반드시 "미국 Indeed 기준, 방향성 참고용"을 함께 적는다
□ AI 산출물 리뷰 체크리스트 1번 항목만 먼저 만든다
   → "이 테스트를 일부러 깨뜨리면 실패하는가"
□ 다음 1:1 4건에 위 질문 4개를 그대로 넣는다
□ team-docs/ai-review-exemplars.md 파일을 빈 상태로 만들어 둔다

[ 2주 뒤에 확인할 것 ]
□ exemplar 문서에 항목이 3개 이상 쌓였는가
□ 쌓이지 않았다면 이유가 시간인가 기준 부재인가를 구분한다
□ 기준 부재라면 리추얼을 늘리지 말고 체크리스트를 먼저 고친다