채용공고 데이터로 내 커리어 방향을 분석해 본 과정: 검색어 표본에서 JobKorea Native Filter까지

08 Sep 2026

왜 커리어를 데이터로 분석했나

커리어 방향을 정할 때 흔히 하는 방법은 다음과 같다.

지금까지 해온 기술을 보고 잘 맞아 보이는 직무를 추천한다.
앞으로 유망할 것 같은 직무를 고른다.
자격증이나 학위를 추가하면 갈 수 있을 것 같은 직무를 찾는다.
몇 개의 채용공고를 보고 시장 전체가 그런 것처럼 판단한다.

문제는 이런 방식이 대부분 추론과 인상에 의존한다는 점이다.

나는 약 11년의 IT 경력 중 네트워크·시스템·보안과 애플리케이션 개발을 모두 경험했고, 최근에는 Java/Spring, Python, 데이터 처리, LLM/RAG/Agent 기반 업무 시스템을 개발하고 있다.

이런 경력은 Backend, AI Application, Security, IAM, AppSec, IT Audit, IT Risk, GRC 등 여러 방향으로 설명할 수 있다. 그래서 AI에게 단순히 “내게 어떤 직업이 좋은가”라고 묻는 대신 다음 질문으로 바꾸었다.

실제 채용시장에서 내 경력을 가장 많이 인정하면서, 보상은 높이고 구조적인 운영·온콜·야간·주말 책임은 줄일 수 있는 직무는 무엇인가?

그리고 이 질문은 가능한 한 실제 채용공고 데이터로 확인하기로 했다.

첫 번째 실패: 검색어로 직군별 40개를 맞춰 수집했다

처음에는 다음과 같은 분석용 직군을 임의로 만들었다.

Backend / AI Backend
IAM / Auth
Product / AppSec
Cloud Security / Security Platform

그리고 JobKorea에서 여러 검색어를 사용한 뒤 각 직군마다 40건씩 채워 160건의 표본을 만들었다.

예를 들면 다음과 같은 검색어였다.

Backend
- 백엔드 개발자
- Java Spring 백엔드
- AI 백엔드

IAM
- IAM
- SSO
- 통합인증
- 인증 인가

AppSec
- AppSec
- Application Security
- 개발보안
- 시큐어코딩

겉보기에는 균형 잡힌 데이터처럼 보였지만 분석 방법 자체에 문제가 있었다.

문제가 된 이유

첫째, Backend_AI, IAM_Auth, Product_AppSec은 JobKorea가 제공하는 직군이 아니라 분석을 위해 임의로 만든 분류였다.

둘째, 검색 결과에는 잡음이 많이 섞였다. 실제로 Backend 표본 안에 다음과 같은 공고도 들어왔다.

K8S Cloud 운영 개발자
자동매매 프로그램 개발
CCTV/IP Camera 펌웨어 개발

셋째, 각 분류를 강제로 40개씩 채웠기 때문에 실제 시장 규모를 알 수 없었다.

Backend 시장이 1,000건이고 IAM이 30건이어도
수집 결과는 각각 40건이 된다.

이 데이터로는 다음 질문에 답할 수 없다.

어느 직무의 채용시장이 더 큰가?
실제로 지원 가능한 공고가 얼마나 되는가?
IAM이나 AppSec이 Backend보다 더 좋은 시장인가?

따라서 검색어 기반 160건 표본은 커리어 의사결정용 데이터에서 제외했다.

이 작업에서 가장 중요했던 교훈은 다음이다.

분류 결과가 데이터 수집 여부를 결정하면 안 된다. 먼저 모집단을 수집하고, 직무 분류는 그 다음에 해야 한다.

두 번째 방법: JobKorea가 실제 제공하는 필터를 모집단으로 사용

다음 분석부터는 검색어를 사용하지 않았다.

브라우저 자동화로 JobKorea 검색 화면의 실제 필터 구조와 내부 값을 확인했다.

JobKorea에는 다음과 같은 상위 필터가 존재했다.

직무
지역
경력
기업형태
학력
고용형태
조건추가

AI·개발·데이터 아래에는 다음과 같은 JobKorea 자체 세부 직무가 있었다.

백엔드개발자
프론트엔드개발자
웹개발자
앱개발자
시스템엔지니어
네트워크엔지니어
DBA
데이터엔지니어
데이터사이언티스트
보안엔지니어
소프트웨어개발자
AI/ML엔지니어
블록체인개발자
클라우드엔지니어
IT컨설팅
QA
AI/ML연구원
데이터분석가
프롬프트엔지니어
AI보안전문가
MLOps엔지니어
AI서비스개발자

여기서 현재 경력 및 장기 커리어와 연결되는 JobKorea native 직무만 선택했다.

Primary Pool 조건

지역
- 서울 전지역

경력
- 경력

고용형태
- 정규직

기업형태
- 대기업
- 30대그룹사
- 매출1000대기업
- 중견기업
- 외국계기업
- 코스피
- 코스닥
- 해외상장

직무
- 백엔드개발자
- 시스템엔지니어
- 데이터엔지니어
- 보안엔지니어
- 소프트웨어개발자
- AI/ML엔지니어
- 클라우드엔지니어
- AI보안전문가
- MLOps엔지니어
- AI서비스개발자

연봉 5,000만원 이상 같은 조건은 사용하지 않았다.

이유는 높은 연봉을 지급하는 회사도 공고에 연봉을 공개하지 않는 경우가 많아, 연봉 공개 여부로 모집단을 자르면 오히려 좋은 회사를 제거할 수 있기 때문이다.

이 native filter를 실제 브라우저에서 적용한 결과 182개의 공고가 남았다.

182건의 상세 JD를 전부 확보

목록만 분석하면 기술 요구사항이나 실제 업무를 알 수 없기 때문에 182건의 상세페이지를 모두 수집했다.

초기에는 JobPosting JSON-LD가 있는 공고만 읽었는데 결과가 다음처럼 나왔다.

전체 공고        182
JSON-LD 확보      36
JSON-LD 없음     146

146건을 버리면 데이터가 크게 왜곡되므로 Chromium으로 실제 페이지를 렌더링하고 다음 순서로 fallback을 구성했다.

JSON-LD
   ↓ 없거나 description이 지나치게 짧음
렌더링된 DOM
   ↓
공고 iframe
   ↓
모집요강/지원자격 구간 추출

최종적으로 다음 상태까지 확보했다.

공고            182 / 182
상세 레코드      182 / 182
본문 200자 이상  182 / 182
누락                0

또 하나의 오류: 페이지 전체 텍스트를 JD로 사용하면 안 된다

상세본문을 확보한 뒤 처음 분류했을 때 K8S Cloud 운영 개발자가 IAM/Auth로 분류되는 이상한 결과가 나왔다.

원인을 확인해보니 공고 본문뿐 아니라 페이지 주변의 추천공고, 회사정보, 관련 콘텐츠 텍스트까지 함께 들어가 있었다.

따라서 다시 다음 규칙으로 정제했다.

직무 분류 규칙

공고 제목을 최우선으로 사용한다.
제목이 일반적인 경우에만 상세 JD를 보조적으로 사용한다.
JD는 담당업무, 지원자격, 자격요건, 우대사항 등의 모집 구간만 사용한다.
추천공고·사이드바·회사소개 등의 주변 텍스트는 제외한다.
분류가 애매하면 강제로 특정 직무에 넣지 않는다.

이 수정 후 K8S Cloud 운영 개발자는 정상적으로 Cloud/Platform 계열로 분류되었다.

임의의 10점 점수를 만들지 않았다

이번 분석에서는 다음과 같은 방식의 점수를 만들지 않았다.

Backend 8.5점
IAM 9점
AppSec 8점

가중치를 어떻게 정하느냐에 따라 결과가 마음대로 바뀌기 때문이다.

대신 공고마다 관찰 가능한 변수를 분리했다.

경력 적합성

요구경력
현재 직접경력으로 충족 가능한가
인접경력으로만 설명 가능한가
직접 도메인 경력이 별도로 필요한가

기술 증거

현재 실제 업무에서 설명 가능한 기술이 JD에 몇 개 등장하는지를 기록했다.

Java
Spring
Python
SQL / RDBMS
Linux
Docker
CI/CD
SSO / 인증·인가
LLM
RAG
AI Agent
CISSP 등

이 숫자는 “합격확률”이 아니다.

단지 현재 경력기술서에 근거를 제시할 수 있는 요구사항 수다.

업무구조 위험

다음 요소도 별도로 분류했다.

LOW
- 제품/서비스 개발 중심
- 구조적인 운영책임 신호 없음

MEDIUM
- 운영
- 유지보수
- 시스템 관리
- SI 구축
- 고객 대응 등의 요소 존재

HIGH
- 고객사 상주
- 파견
- 24x7
- 온콜
- 교대근무
- 구조적인 야간/주말 대응

정제한 182건에서 나온 직무 분포

이 숫자는 한국 전체 IT 시장의 비율이 아니다.

서울 + 경력 + 정규직 + 우량 기업형태 + 선택한 JobKorea native IT 직무라는 모집단 안에서의 분포다.

분석 후 직무군	공고 수
Security	30
Cloud / Platform	29
AI Application	24
기타 Software	20
IT Consulting / PM	18
Support / Operations	15
분류 불충분·혼합	13
AppSec	12
Backend	11
IAM / Auth	4
Data Engineering	4
AI Security	2

가장 먼저 눈에 띈 것은 IAM과 AI Security 공고가 생각보다 매우 적었다는 점이다.

이것만으로 시장이 작다고 단정할 수는 없지만, 적어도 “IAM/Product Security가 압도적으로 좋은 다음 커리어”라는 가설을 데이터가 강하게 지지하지는 않았다.

더 중요한 결과는 공고 수가 아니라 업무구조였다

182건의 업무구조 위험을 분류하면 다음과 같았다.

LOW       71 / 182 = 39.0%
MEDIUM   105 / 182 = 57.7%
HIGH       6 / 182 =  3.3%

즉 대기업·중견·상장·외국계 등으로 회사 필터를 먼저 걸었는데도 절반 이상에서 다음과 같은 요소가 발견됐다.

운영
유지보수
구축
SI delivery
시스템 관리
고객 지원

따라서 좋은 커리어를 찾기 위해서는 회사 규모만 필터링해서도 안 된다.

내가 원하는 것은 많은 회사에 지원하는 것이 아니라 다음 조건을 동시에 만족하는 회사다.

높은 보상
+ 기존 경력 인정
+ 낮은 구조적 운영책임
+ 낮은 온콜/야간/주말 위험
+ 40~50대까지 이어질 경력자산

Backend를 버려야 한다는 근거는 없었다

AI가 코딩을 빠르게 대체하고 있기 때문에 처음에는 Backend 자체에서 빨리 벗어나야 하는지 고민했다.

하지만 실제 공고를 보면 AI Application 역할에서도 기존 개발 역량이 계속 사용됐다.

반복적으로 등장한 것은 다음 조합이다.

Java / Spring
Python
SQL / RDBMS
Linux
Docker / CI-CD
LLM / RAG / AI Agent

즉 AI 시대의 애플리케이션 개발은 Backend를 없애기보다 Backend 위에 AI 기능을 추가하는 형태가 많이 보였다.

따라서 현재까지의 데이터에서는 다음 가설이 더 적절했다.

Backend 경력은 버릴 자산이 아니라, AI·Security·Governance 중 어떤 도메인으로 이동하더라도 가격을 높여주는 기반 자산이다.

Product Security / AppSec도 생각보다 쉬운 전환은 아니다

Security를 개발자와 잘 맞는 다음 경력이라고 생각하기 쉽다.

하지만 실제 AppSec 공고는 다음과 같은 직접 경험을 별도로 요구하는 경우가 많았다.

Secure SDLC
SAST / DAST / SCA
소스코드 보안검토
취약점 분석
Threat Modeling
보안 테스트

즉

Backend 5년 + 과거 보안경력

을 기업이 자동으로

AppSec 5년

으로 인정한다고 볼 수 없다.

그래서 AppSec은 여전히 좋은 전문화 후보이지만 직접 Secure SDLC/AppSec 증거를 추가한 뒤 시장에서 검증해야 하는 방향으로 정리했다.

가장 예상 밖의 발견: 기술경력을 인정하는 IT Audit 시장

엔지니어링 182건과 별개로 IT Audit / IT Risk / GRC 공고도 교차검증했다.

처음에는 IT감사로 이동하려면 직접 ITGC·감사 경력이 반드시 필요할 것으로 예상했다.

실제로 그런 공고가 존재한다.

하지만 다른 형태의 공고도 확인됐다.

기술경력을 feeder로 인정하는 IT Audit

일부 증권사 IT Audit 공고는 다음과 같은 경력을 지원자격으로 인정했다.

개발
운영
인프라
정보보안

그리고 다음 기술통제 이해를 요구했다.

시스템 아키텍처
네트워크
서버
DB
정보보안
로그 분석
형상관리
접근통제

CISA와 CISSP는 우대조건으로 연결됐다.

이런 JD는 “감사 신입으로 리셋”하는 직무와 다르다.

11년 IT 기술경력
      ↓
Technology Audit / IT Risk

로 기존 기술경력을 변환하는 Bridge Role에 가깝다.

또 다른 금융사 IT감사 공고에서도 다음 중 하나를 인정하는 사례를 확인했다.

IT감사 직접경력
CISA/CIA/ISMS-P 등 자격
IT 또는 정보보호 장기 경력

따라서 “기술경력에서 Audit/Risk로 직접 이동하는 시장이 존재하는가?”라는 질문에는 이제 존재한다고 답할 수 있다.

다만 이런 공고가 시장에 얼마나 반복적으로 등장하는지는 더 추적해야 한다.

GRC를 하나의 직무로 보면 안 된다

실제 공고를 비교하면서 GRC 내부에서도 진입장벽이 크게 다르다는 것을 확인했다.

대략 다음처럼 구분해야 했다.

유형	관찰된 진입 특성
Technical IT Audit	일반 IT 기술경력을 인정하는 공고가 존재
IT Planning + Internal Control	개발/IT 경력을 활용하는 Bridge가 존재
Security Audit	보안 경력 + 점검/감사 경험을 요구하는 경우가 많음
Security Policy	내부점검/인증대응 직접경력을 요구하는 경우가 있음
Privacy Governance	개인정보보호 직접 장기경력을 요구하는 상위 포지션이 많음

따라서

Audit = GRC = Privacy = Security Policy

처럼 하나로 묶어 비교하면 잘못된 결론이 나온다.

특히 현재 경력에서는 Privacy Governance보다 기술형 IT Audit / Technology Risk가 더 자연스러운 Bridge가 될 가능성이 확인됐다.

CISA, PMP, AWS 자격증은 역할이 다르다

공고를 보면서 자격증도 이름 자체와 실무 요구를 분리해서 봤다.

엔지니어링 공고에서는 AWS 자격증보다 AWS 실제 경험이 더 중요한 경우가 많았다.

따라서 AWS 자격증을 취득하더라도 목적은 자격증 개수를 늘리는 것이 아니라 실제 AWS 설계·구축 경험을 만들기 위한 보조수단이어야 한다.

반면 CISA는 IT Audit, IT Risk, Security Audit, Security Governance 쪽에서 직접 우대조건으로 반복 등장했다.

따라서 현재 해석은 다음과 같다.

CISA
→ Audit / IT Risk / Security Governance 시장과 직접 연결

PMP
→ IT기획 / PM / Governance 선택지 확장

AWS Certification
→ Cloud 실무 증거를 보조

CKA / CCIE
→ 현재 목표시장에서는 우선순위가 낮음

자격증이 경력을 대신해주지는 않는다.

중요한 것은 그 자격증이 실제 목표 JD에서 어떤 경력과 함께 요구되는가다.

회사 평균연봉도 그대로 사용하지 않았다

커리어 분석에서 연봉 데이터는 매우 중요하지만 공개 데이터의 함정도 크다.

회사 평균연봉은 다음과 같지 않다.

회사 평균연봉 = 내가 받을 연봉

직군, 직급, 성과급, 계약연봉 구조가 모두 다르기 때문이다.

그래서 회사 평균연봉은 최종 연봉예측에 사용하지 않고 회사 보상수준의 proxy로만 사용하기로 했다.

실제 최종 지원 후보에서는 다음 순서로 확인해야 한다.

공고에 공개된 position salary band
같은 회사·유사 직급의 시장 데이터
회사 전체 평균연봉
실제 면접/오퍼 데이터

결국 가장 정확한 개인 데이터는 실제 지원 결과와 실제 오퍼다.

지금까지의 커리어 가설

현재까지 확보한 데이터만 놓고 보면 과거의 다음 가설은 약해졌다.

Backend를 빨리 버린다.
Product Security 또는 IAM을 다음 직무로 확정한다.
Cloud 자격증을 차례대로 취득한다.

대신 다음 가설이 더 강해졌다.

1. Technical IT Audit / IT Risk

단, 반드시 다음 조건을 만족하는 공고만 본다.

개발/인프라/보안 등 일반 IT 경력을 인정
+ 감사 신입 리셋 없음
+ 구조적 온콜/야간 책임 낮음
+ 보상 상승 가능

2. IT Planning + Internal Control / Audit Bridge

기존 IT 구현 경험을 유지하면서 통제·감사 직접경력 한 줄을 만드는 방향이다.

3. Security Audit / Technical Security Governance

CISSP 및 과거 보안경력이 강점이지만 직접 점검·감사·인증경력은 별도로 확인해야 한다.

4. 좋은 Backend / AI Application

좋은 제품회사에서 보상과 WLB가 충분하다면 계속 경쟁시킨다.

즉 커리어 전환 자체가 목적이 아니다.

같은 시간에 더 높은 보상을 받고, 지금까지 만든 경력자산을 더 오래 활용할 수 있는가가 목적이다.

분석하면서 폐기한 데이터도 기록해야 한다

데이터 분석에서는 성공한 결과만 남기면 안 된다.

이번 작업에서는 다음 데이터를 의사결정 근거에서 제외했다.

검색어 기반 160건 표본

임의 직군을 먼저 정의함
검색 결과가 모집단이 됨
각 분류를 40건으로 강제함
시장규모를 왜곡함

따라서 폐기했다.

Governance/Audit 68건 1차 stratified sample

IT Risk/Audit, Security GRC, Privacy, Security Review를 별도 검색해 68건을 수집했지만 품질검사에서 IT_RISK_AUDIT 표본 대부분에 Privacy 신호가 나타나는 비정상 패턴을 확인했다.

상세페이지의 본문 구간이 충분히 정제되지 않아 페이지 주변 텍스트가 섞인 것으로 판단했다.

따라서 이 68건의 집계 수치는 현재 커리어 결론에 사용하지 않는다.

다만 이 실패 덕분에 Governance 분석도 엔지니어링 표본과 동일하게 다음 품질 규칙이 필요하다는 것을 확인했다.

제목 우선 직무 판정
모집요강 구간만 추출
주변 콘텐츠 제거
실제 IT 통제/감사 문맥 확인
공고별 수동 spot check

아직 분석이 완전히 끝난 것은 아니다

현재 끝난 것은 다음 범위다.

[완료]
JobKorea native filter 구조 확인
좋은 회사 후보군 필터 정의
182개 공고 모집단 확보
182개 상세 JD 100% 확보
본문 오염 교정
직무군 재분류
경력/기술 Match 분석
운영·상주·온콜 위험 분석
실제 IT Audit/GRC 공고 교차검증
잘못된 표본 폐기 및 QA

반면 다음은 아직 추가 데이터가 필요하다.

[진행 필요]
Governance/Audit native/정제 표본 재구축
회사별 실제 재무안정성
position-level 연봉 데이터
실제 WLB/온콜 구조 검증
지원 → 서류 → 면접 → 오퍼 결과 축적

따라서 이번 결과는 커리어 방향을 확정하는 최종 모델이 아니라, 잘못된 가설을 제거하고 2027년 지원전략을 설계하기 위한 1차 실증 분석이다.

다음에는 실제 지원 결과를 데이터로 만들 계획이다

공고 데이터만으로는 기업이 내 경력을 실제로 어떻게 평가하는지 알 수 없다.

앞으로는 지원할 때마다 다음을 기록할 계획이다.

회사
직무
지원일
직무 특성
필수경력 충족 여부
직접경력 gap
사용한 이력서 버전
서류 합격/탈락
면접
오퍼
제시 연봉

20~30건만 쌓여도 단순한 AI 추천보다 훨씬 가치 있는 개인 데이터가 된다.

그때부터는 다음과 같은 질문에 답할 수 있다.

Backend보다 IT Audit에서 실제 서류 합격률이 높은가?
CISA 취득 전후로 Audit/Risk 반응이 달라지는가?
어떤 회사군이 11년 전체 IT 경력을 가장 잘 인정하는가?
높은 연봉을 주는 회사에서 어떤 경력 표현이 통하는가?

결국 커리어 분석에서 가장 중요한 데이터는 시장 평균보다 내가 시장에 실제로 던졌을 때 받은 응답일 가능성이 높다.

정리

이번 분석에서 가장 크게 배운 것은 특정 직무가 유망하다는 사실이 아니었다.

커리어 분석도 일반 데이터 분석과 똑같이 sampling frame과 data quality가 먼저라는 점이었다.

검색어로 원하는 결과를 모은다
→ 가설을 증명하기 쉽지만 편향된다.

실제 서비스의 native filter로 모집단을 만든다
→ 데이터를 먼저 확보하고 나중에 분류할 수 있다.

상세본문 전체를 사용한다
→ 주변 페이지 텍스트 때문에 오분류된다.

JD 구간만 정제한다
→ 직무와 요구조건을 더 안정적으로 비교할 수 있다.

그리고 현재 시점의 커리어 가설은 다음 한 문장으로 정리할 수 있다.

기존 Backend·보안·인프라 경력을 버리지 않고, 그 전체 기술경력을 높은 보상과 낮은 운영책임으로 변환해주는 Technology Audit / IT Risk / IT Planning-Control 직무와 좋은 Backend·AI 제품직을 실제 시장에서 병렬 검증한다.

이 결론도 고정하지 않을 생각이다.

앞으로 실제 채용공고와 실제 지원 결과가 쌓이면 다시 데이터로 수정할 것이다.