반응형

정보보안 쪽에서 일하고 있다. 보안 이벤트를 분석하고 대응하는 게 주 업무다.

전환을 생각하게 된 건 이 일이 싫어서가 아니다. 업계를 보다가 든 생각 때문이었다.

클라우드가 일반화되고 AI가 들어오면서 개발·인프라·보안, 심지어 기획과 디자인까지 경계가 빠르게 흐려지고 있다. 예전 같으면 각자 자기 영역만 알아도 됐지만 지금은 그렇지 않다. 인프라를 모르면 보안 설계를 못 하고, 보안을 모르면 인프라를 제대로 못 짠다.

이 상황에서 한 우물만 파면 고인다는 느낌이 들었다. 보안 하나만, 혹은 인프라 하나만 붙들고 있으면 몇 년 뒤에 갈 수 있는 자리가 좁아진다.

그래서 지금 가진 도메인을 버리지 않으면서 넓힐 수 있는 방향을 찾았다. Cloud + Security. 플랫폼 엔지니어 혹은 DevOps 엔지니어다. 보안 배경이 마이너스가 아니라 차별점이 되는 몇 안 되는 자리이기도 하다.

마침 근거가 될 만한 게 하나 있었다.

팀에 공용 서버가 한 대 있었는데, 팀원들이 각자 만든 자동화 도구를 거기 올릴 때마다 배포 방식을 매번 따로 고민해야 했다. 나도 IOC를 자동으로 수집해서 Splunk에 적재하는 파이프라인을 만들어 올리는 입장이었고, 그 반복이 계속 거슬렸다.

그래서 Docker API를 이용해 셀프서비스 배포 플랫폼을 하나 만들었다. 소스랑 Dockerfile만 주면 알아서 빌드하고 컨테이너를 띄우는, 웹 UI로 되는 물건이었다. 팀원들이 자기 도구를 그걸로 올리기 시작했다.

방향은 정해졌고 시작점도 있었다. 문제는 이게 완전한 직무 전환이라는 거다. 보안 경력은 보안 경력이지 DevOps 경력이 아니다. "DevOps 3년 이상"이라고 적힌 공고 앞에서 내 경력은 0년이다.

그래서 질문이 이렇게 바뀐다.

연차를 못 늘린다면, 무엇을 채워야 서류가 통과되는가?

로드맵은 우선순위를 안 알려준다

"DevOps 로드맵"은 검색하면 얼마든지 나온다. Docker, Kubernetes, Terraform, Ansible, Jenkins, Prometheus, Istio, Helm, ArgoCD, Vault, Consul, Kafka…

다 하라고 한다. 다 할 시간은 없다. 재직 중이고, 학습에 쓸 수 있는 건 주 10~15시간이다.

필요한 건 목록이 아니라 순서였다.

그래서 로드맵 대신 실제 채용 공고를 보기로 했다. 이유는 단순하다. 로드맵은 누군가의 의견이지만, 공고는 회사가 돈을 걸고 쓴 요구사항이다.

접근 방법

네 단계로 잡았다.

  1. 국내 채용 포털에서 관련 공고를 최대한 수집
  2. 중복·이미 본 것 제거
  3. 각 공고를 내 프로필과 대조해 채점
  4. 채점 과정에서 나온 "부족한 항목"을 전부 모아서 센다

핵심은 4번이다. 공고 하나만 보면 그 회사 사정이지만, 50건을 모아놓고 세면 패턴이 나온다.

손으로 할 일이 아니라서 도구를 만들었다.

Claude Code 기반으로 포털별 검색 CLI를 하나씩 붙였다. 사람인·원티드·점핏·LinkedIn과 채용 애그리게이터 한 곳까지 다섯 개다. 전부 공개 검색 엔드포인트만 쓰기 때문에 인증도 API 키도 필요 없다. TypeScript로 짜고 Bun으로 돌린다.

수집한 공고는 seen_jobs.json에 URL과 회사+직무 조합으로 쌓아두고 다음 실행 때 걸러낸다. 같은 공고가 포털 두 곳에 올라오는 경우가 흔해서 URL만으로는 부족했다.

채점이 제일 오래 걸리는 부분인데, 여기도 자동화했다. 공고를 5개씩 묶어 19개 에이전트에 병렬로 던지고, 각 에이전트가 실제 공고 URL을 열어 본문을 읽은 뒤 5개 축으로 점수를 매기고 부족한 항목을 최대 3개까지 뽑아 JSON으로 돌려준다. 제목만 보고 판단하지 못하도록 "본문을 못 가져오면 채점하지 말고 만료로 처리하라"는 규칙을 넣었다. 실제로 구글 채용 페이지 6건은 자바스크립트 렌더링이라 본문을 못 읽어서 미채점으로 남겼다.

마지막 집계는 파이썬 스크립트 몇 줄이다. 94건에서 나온 갭을 전부 모아 빈도를 세고, 낮은 점수 공고일수록 가중치를 주는 방식으로 정렬했다.

수집 대상은 포털 5곳, 검색어는 26개를 썼다.

플랫폼 엔지니어 / DevOps 엔지니어 / 인프라 엔지니어 / 클라우드 엔지니어
AI 플랫폼 엔지니어 / DevSecOps / 쿠버네티스
Platform Engineer / DevOps Engineer / Site Reliability Engineer

결과는 이랬다.

단계 건수
수집 455
중복·기존 확인분 제거 후 신규 222
실제 공고 본문을 열어 채점 94
지원 사정권 (45점 이상) 51

채점은 5개 축으로 했다. 기술 스택 일치도, 경력 일치도, 업무 성격 적합도, 근무지, 커리어 방향 일치도. 그리고 공고마다 "부족한 것"을 최대 3개까지 뽑게 했다.

여기서 규칙 하나를 강하게 걸었다.

보안 경력을 DevOps 연차로 환산하지 않는다.

이게 없으면 스스로에게 후한 점수를 주게 된다. "보안도 인프라 만졌으니 2년쯤은 쳐줄 수 있지 않나" 같은 생각은 서류 심사에서 통하지 않는다. 정직하게 0년으로 뒀다.

결과 — 갭 3개가 압도적이었다

51건에서 나온 갭을 세어봤다.

갭 등장 그중 자격요건
프로덕션 규모 Kubernetes 운영 39건 37건
Terraform / IaC 35건 32건
관측성 스택 (Prometheus·Grafana·OTel) 33건 30건
MLOps / GPU 인프라 7건 7건
Service Mesh (Istio) 6건 3건
SRE (SLO·에러버짓) 4건 3건

1~3위와 4위 사이가 5배 이상 벌어진다. "여러 갭 중 셋"이 아니라 사실상 하나의 병목이다.

오른쪽 열이 더 중요하다. Kubernetes 39건 중 37건, Terraform 35건 중 32건이 우대사항이 아니라 자격요건이었다. 우대는 없어도 지원이 되지만 자격요건은 다르다.

확인된 것 두 가지

하나. 기반은 이미 있었다

Docker, Linux, Go, Python, GitHub Actions, AWS 기본 서비스는 51건 전체에서 단 한 번도 갭으로 잡히지 않았다. 빠진 건 그 위에 얹히는 오케스트레이션 → 프로비저닝 → 계측 세 층이었다.

이건 생각보다 중요한 발견이었다. 처음부터 다시 배워야 하는 게 아니라 위쪽 세 층만 올리면 된다는 뜻이기 때문이다.

둘. 피할 수 있는 갭과 없는 갭이 나뉜다

MLOps(7건)와 Istio(6건)는 특정 회사군에만 몰려 있었다. AI 인프라 회사, 대형 핀테크 같은 곳들이다. 회사를 골라서 피할 수 있는 갭이다. 상위 3개는 피할 수 없다.

그래서 학습 목록에서 MLOps와 Istio를 뺐다. 시간이 유한하면 안 할 것을 먼저 정해야 한다.

반전 — 점수가 높은 공고가 갈 수 있는 공고는 아니었다

정렬해놓고 보니 이상한 게 있었다.

2위(75점)로 올라온 공고를 열어봤다. 자격요건에 이렇게 적혀 있었다.

  • 프로덕션 환경 Kubernetes 클러스터 운영 및 트러블슈팅 경험
  • Terraform 등을 활용한 인프라 자동화 구현 경험

둘 다 없다. 그것도 우대가 아니라 필수로. 서류에서 걸릴 게 뻔한 공고가 2위에 있었다.

원인을 보니 채점 기준에서 "커리어 방향 일치도"가 30% 가중치를 갖고 있었다. 전직 지원자에게 이 축은 역설적으로 작동한다.

커리어에 가장 도움 되는 자리일수록 → 요구 수준이 높고 → 갈 확률은 낮다

내가 만든 점수는 "가고 싶은 정도"를 재고 있었고, "갈 수 있는 정도"는 안 재고 있었다.

그래서 근무지처럼 점수와 무관하게 작동하는 통과/탈락 게이트를 하나 추가했다.

판정 조건
PASS 연차 충족 + 필수요건 미보유 1개 이하
STRETCH 연차가 요구치의 절반 이상 또는 필수 미보유 2개
BLOCKED 요구 연차가 실경력의 2배 초과 또는 필수 미보유 3개 이상

적용하니 상위 26건 중 실질 지원 대상이 7건으로 줄었다.

솔직히 말하면 놀라지는 않았다. 이 정도일 줄 알았다는 쪽에 가깝다.

Kubernetes를 프로덕션에서 운영해 본 적이 없고, Terraform은 손도 안 댔고, 클라우드도 EC2와 S3를 쓴 정도지 운영이라고 부를 만한 경험은 아니었다. 그런 상태로 지원 가능한 자리가 26개나 될 리 없다.

오히려 숫자로 보고 나니 정리가 됐다. 막연히 "부족하겠지"라고 느끼는 것과 "필수요건 3개가 비어서 19건이 걸린다"고 아는 건 다르다. 앞의 것은 불안이고 뒤의 것은 할 일 목록이다.

그래서 무엇을 할 것인가

갭 3개를 각각 강의로 메우면 대략 167시간이다. 그리고 다 듣고 나도 이력서에는 여전히 "학습 수준"이라고 쓸 수밖에 없다. 강의 수료증은 운영 경험이 아니다.

그래서 접근을 바꿨다.

세 갭을 동시에 관통하는 프로젝트를 하나 만든다.

재료는 있다. 회사에서 만든 Docker API 기반 배포 플랫폼이다. 회사 코드는 당연히 못 가져온다. 대신 같은 문제를 개인 프로젝트로, 다른 기술로 다시 푼다.

  1. Terraform으로 인프라를 코드화 → Terraform 갭
  2. 런타임을 Docker에서 Kubernetes로 이전 → K8s 갭
  3. Prometheus로 계측하고 SLO 정의 → 관측성 갭

그러면 이력서 한 줄이 이렇게 바뀐다.

기존

Docker API 기반 셀프서비스 배포 플랫폼을 설계·구축

목표

Terraform으로 프로비저닝하고 Kubernetes에서 운영하며 Prometheus로 SLO를 추적하는 셀프서비스 배포 플랫폼을 설계·구축

같은 프로젝트인데 세 갭이 전부 "학습 수준"에서 "만들어서 운영해 봄"으로 바뀐다.

경력 연수는 못 늘린다. 결과물은 만들 수 있다.

연재 예고

10주 계획을 세웠고, 각 단계를 여기에 기록하려고 한다. 특히 잘 된 것보다 깨진 것을 쓸 생각이다.

노드를 drain 하면 Pod가 어디로 가는지, state 잠금 없이 동시에 apply 하면 뭐가 망가지는지, 정책이 배포를 막으면 어떤 에러가 나오는지 같은 것들.

공고들이 요구한 것도 결국 그거였다. 어떤 공고는 자격요건에 대놓고 "Kubernetes 트러블슈팅 경험"이라고 썼고, 다른 공고는 "네트워크 트러블슈팅이 이 일에서 가장 어려운 부분"이라고 적어놨다.

정상 동작을 만드는 것과 고장을 고쳐본 것은 다른 능력이다.

다음 편은 프로젝트 첫 코드 얘기다. Kubernetes도 Terraform 인프라도 아니고, 비용 알럿부터 짰다. 왜 그랬는지, 그리고 그 알럿을 확인하는 스크립트가 첫날부터 어떻게 거짓말을 했는지 쓴다.

시리즈: 보안에서 플랫폼으로

  • [0편] 보안에서 DevOps로 전직 — 공고 455건 분석해보니 갭은 3개였다 ← 현재 글
저작자표시 비영리 동일조건 (새창열림)