기술 분야에 진입하기 위한 모든 로드맵은 특정 언어를 선택하라고 말합니다. Python을 배우고, JavaScript를 배우고, 몇 가지 프로젝트를 만든 뒤 지원하라는 식이죠. 그래서 우리는 지루한 일을 직접 수행하여 실제로 채용 공고에서 무엇을 요구하는지 확인했습니다. 우리는 1,077개의 기술 기업을 추적하고 있으며, 현재 이 기업들은 총 15,265개의 채용 직무를 열어두고 있습니다. 우리는 모든 직무를 전수 조사하여 어떤 기술이 가장 많이 등장하는지 집계했습니다.

로드맵의 약속대로 Python이 승리했습니다. 하지만 그다음부터 목록은 언어에 관한 것이 아니게 됩니다. 현재 기술 분야에서 두 번째로 많이 요구되는 기술은 또 다른 언어가 아닙니다. 바로 클라우드 (Cloud)입니다.

15,265개의 채용 공고 중 3,842개에서 AWS가 언급되었습니다. 이는 4개 중 1개 꼴입니다. Kubernetes는 5개 중 1개에 포함되어 있습니다. Kubernetes를 요구하는 직무가 React, Java, TypeScript 또는 Go를 요구하는 직무보다 더 많습니다. 어떤 부트캠프(Bootcamp)도 전면에 내세우지 않는 이 계층(Layer)이 시장을 조용히 지탱하고 있으며, 이 수요가 사라지지 않는 데에는 이유가 있습니다. 이것은 업무 중 AI에게 맡겨두고 떠날 수 없는 부분이기 때문입니다.

4개 중 1개의 채용 직무가 AWS를 요구합니다

다음은 15,265개의 채용 직무에서 각 기술이 언급된 횟수를 기준으로 집계한 상위 목록입니다:

기술 (Skill)	채용 직무 수	점유율
Python	5,799	38%
...

(Go에는 "Golang"으로 태그된 직무가 포함됩니다. 채용 공고는 보통 여러 기술을 명시하므로, 점유율의 합계가 100%가 되지는 않습니다.)

이 12개 중 6개가 클라우드 및 인프라 (Cloud and Infrastructure) 관련 기술입니다: AWS, Kubernetes, Google Cloud, Docker, Azure, Terraform. 가장 흔한 클라우드 기술보다 더 자주 요구되는 언어는 Python 단 하나뿐입니다. 다른 모든 언어는 그 아래에 위치합니다. Java보다 Kubernetes를 요구하는 공고가 더 많으며, 순수 JavaScript보다 Terraform을 요구하는 공고가 더 많습니다. 만약 당신이 얼마나 많은 문을 열 수 있는지에 따라 순수하게 기술 순위를 매긴다면, 상위권은 대부분 배관 작업(Plumbing)과 같은 기반 기술들로 채워질 것입니다.

이것은 하나의 직무가 아닙니다. 모든 직무에 해당합니다.

당연한 반응은 "좋아, 그럼 DevOps 엔지니어가 되겠어"일 것입니다. 하지만 그것이 이 교훈의 핵심은 아닙니다.

15,265개의 채용 공고 중 단 1,140개, 즉 약 13개 중 1개만이 DevOps, SRE, 플랫폼(platform), 클라우드(cloud), 시스템(systems)과 같은 인프라 전담 역할입니다. 만약 인프라가 별도의 독립된 차선이었다면, 수요는 딱 그 정도에 그쳤을 것입니다. 하지만 모든 역할의 4분의 1에서 AWS가 등장하고, 5분의 1에서는 Kubernetes가 등장합니다. 즉, 나머지 5분의 4의 수요는 인프라 직함에 포함되어 있지 않습니다. 그 수요는 누군가의 클라우드에 있는 클러스터 내 컨테이너(container)로 결과물을 배포하기를 기대하는 일반적인 백엔드(backend), 풀스택(full-stack), 데이터(data) 직무에 결합되어 있습니다.

누가 채용을 하고 있는지를 봐도 동일한 현상을 확인할 수 있습니다. Kubernetes를 운영하는 기업들을 뽑아 채용 중인 역할별로 분류해 보면, 이들은 특정 산업군에 국한되지 않습니다.

• AI 연구소 (AI labs). OpenAI, Anthropic, Cohere.
• 핀테크 및 결제 (Fintech and payments). Stripe, Robinhood, Adyen.
• 데이터 플랫폼 (Data platforms). Snowflake, Databricks, MongoDB.
• 개발 도구 및 클라우드 (Dev tools and cloud). GitLab, DigitalOcean, Canonical.
• 보안 및 관측성 (Security and observability). Zscaler, Datadog.

제품은 다르지만, 고객도 다르고, 배관(plumbing, 기반 구조)은 같습니다. 결제 회사의 백엔드 역할과 AI 연구소의 백엔드 역할은 당신이 클라우드 환경에 익숙해야 한다는 점을 제외하면 거의 공통점이 없습니다. 이것이 바로 인프라 유창성(infra fluency)이 그 어떤 단일 프레임워크(framework)보다 가치 있는 이유입니다. React는 프론트엔드(frontend)에 대한 베팅이고, Rust는 시스템(systems)에 대한 베팅이지만, 인프라 계층은 이 모든 곳에 동시에 스며듭니다.

왜 에이전트(agent)에게 그냥 맡겨둘 수 없는가

이 부분은 구직자라면 눈을 번쩍 뜨고 주목해야 할 대목입니다. 왜냐하면 일반적인 걱정은 그 반대 방향으로 흐르기 때문입니다. 만약 AI가 코드를 작성하는 데 능숙해지고 있다면, 왜 굳이 이 계층(layer)을 배워야 할까요? 에이전트(agent)가 알아서 처리해주지 않을까요?

에이전트가 처리할 수 있습니다. 그것은 문제가 아닙니다. 진짜 문제는 에이전트가 잘못 처리했을 때 어떤 일이 벌어지느냐 하는 것입니다.

AI가 React 컴포넌트를 작성하다가 실수하면, 버튼이 작동하지 않을 뿐이고 다시 시도하면 됩니다. 하지만 AI가 인프라 변경(infrastructure change)을 작성하다가 실수하면, 그 실패 모드(failure mode)는 차원이 다른 수준의 재앙이 됩니다. 2025년 7월, Replit 내부의 한 AI 에이전트는 코딩 실험 도중 동결(freeze)하라는 명시적인 지시를 무시하고 라이브 데이터베이스를 삭제했으며, 그 후 데이터를 복구할 수 없다고 보고했습니다. 복구는 가능했고 소유자가 데이터를 되찾긴 했지만, 그 과정을 다시 한번 읽어보십시오. 에이전트는 아무도 요청하지 않은 변경을 수행했고, 그 손상을 되돌릴 수 있는지 여부에 대해서도 틀린 판단을 내렸습니다.

2026년 4월, PocketOS라는 작은 SaaS 기업의 일상적인 업무를 수행하던 코딩 에이전트가 자격 증명(credentials) 문제에 부딪혔고, 스스로 코드베이스에서 발견한 과도한 권한의 액세스 토큰(access token)을 사용하여 약 9초 만에 프로덕션 데이터베이스와 백업을 삭제해 버렸습니다. 회사는 며칠 뒤 데이터를 복구했습니다. 여기서 시사하는 핵심적인 디테일은 실제 과실이 어디에 있었느냐 하는 점입니다. 해당 토큰은 결코 그 정도의 권한을 가져서는 안 되었으며, 백업은 보호 대상과 동일한 볼륨(volume)에 저장되어 있어서도 안 되었습니다. 이 두 가지 모두, 설정을 제대로 이해하고 있는 사람이라면 에이전트가 접근하기도 훨씬 전에 잡아냈을 법한 문제들입니다.

그것이 바로 이 이야기의 핵심 논지입니다. 가치는 명령어를 입력하는 데 있지 않습니다. 에이전트가 당신보다 더 빠르게 입력하기 때문입니다. 가치는 계획을 살펴보고 이 토큰의 범위(scope)가 너무 넓다거나, 저 한 줄이 사이트를 다운시킬 것이라는 점을 알아채는 사람이 되는 데 있습니다. 과거에 인프라를 안다는 것은 YAML을 암기하여 작성할 수 있다는 것을 의미했습니다. 이제 그것은 실행되기 전에 잘못된 계획을 잡아낼 수 있다는 것을 의미합니다. 이는 들리는 것보다 배우기 쉬운 일이며, 여기에 숨겨진 좋은 소식입니다. 즉, 6개의 도구를 마스터할 필요가 아니라, 빠르고 자신만만하며 때로는 매우 틀리기도 하는 기계를 감독할 수 있을 만큼 클라우드, 컨테이너, 그리고 약간의 코드형 인프라 (Infrastructure-as-Code, IaC)를 충분히 이해하면 된다는 것입니다.

구직 중이라면 의미하는 바

이러한 역할은 시니어(Senior) 쪽으로 치우쳐 있으며, 그에 걸맞은 급여를 받습니다. 급여가 공개된 전담 인프라 직무 중 평균 범위는 약 $161k에서 $233k 사이이며, 대략 5개 중 3개는 시니어(Senior)로 분류되어 있습니다. (주의 사항: 급여 테이블의 최상단은 인프라가 아닌 AI 및 ML 분야이므로, 이를 잭팟이 아닌 강력한 하한선으로 간주하십시오.) 이곳은 주니어(Junior)의 문턱도 좁습니다. 현재 수십 개의 엔트리 레벨(Entry-level) 인프라 직함만이 열려 있으므로, 경력 초기 단계라면 첫날부터 SRE 직함을 쫓기보다는 일반적인 백엔드(Backend) 이력서에 클라우드와 컨테이너 기초를 추가하는 것이 전략입니다.

그런 다음 도구가 분류하게 두십시오. 당신이 이미 사용 중인 AI 에이전트(Claude, Cursor 또는 무엇이든 열려 있는 것)를 MCP를 통한 Remoet에 연결하고, 원하는 조건을 요청하십시오. 예를 들어, Python과 AWS를 사용하면서 미드 레벨(Mid-level) 채용이 열려 있는 기업이나, React를 사용하면서 Kubernetes를 운영하는 기업 등을 요청할 수 있습니다. 에이전트는 각 기업의 실제 태그 수준 스택을 읽고 당신에게 최종 후보 명단을 전달합니다. 당신의 스택과 진정으로 겹치는 10개 또는 15개의 기업을 Star 표시해 두면, 해당 기업들이 새로운 공고를 올릴 때마다 일주일에 한 번 이메일을 받게 됩니다. 에이전트가 영혼을 갉아먹는 중간 과정을 처리해 줍니다. 물론, 감독은 당신이 해야 합니다.

이 데이터가 불확실한 부분

저희는 저희가 수치를 과장하기보다 여러분이 이 수치를 신뢰하기를 바랍니다. 따라서 수치가 유동적일 수 있는 부분은 다음과 같습니다.

기술 스택 수치는 각 채용 공고에서 자동 감지된 태그를 기반으로 산출되었습니다. 따라서 AWS를 명시한 역할은 AWS를 어딘가에 언급한 역할일 뿐, 반드시 AWS 전문가 채용을 의미하는 것은 아닙니다. 이 표는 정확한 인원수(headcount)가 아니라 "수요가 어디에서 나타나는가"로 읽어야 합니다. 태그가 놓치는 부분도 있습니다. 무언가를 조용히 사용하면서 문서화하지 않는 팀은 위음성(false negative)으로 처리되므로, 인프라 수치는 실제보다 높기보다는 낮을 가능성이 큽니다.

두 가지 공포스러운 사례는 실화이지만, 둘 다 통제 불능의 AI(rogue-AI)에 관한 우화는 아니며 그렇게 읽히기를 원치도 않습니다. 두 회사 모두 데이터를 복구했으며, 두 경우 모두 근본적인 원인은 인간에게 있었습니다. 즉, 개발(dev)과 운영(prod) 환경의 분리 미비, 과도한 범위의 토큰(token), 보관해서는 안 될 장소에 보관된 백업 등이 원인이었습니다. 이는 주의 사항이라기보다 오히려 핵심을 찌르는 지점입니다. 에이전트(agent)는 트리거(trigger, 방아쇠)였을 뿐이며, 시스템을 이해하는 사람이 없었다는 점이 근본 원인이었습니다.

마지막으로, 이 데이터는 2026년 7월 1일 기준의 스냅샷이며, 전체 경제가 아닌 저희가 파악한 시장의 일부(자금을 조달받은 1,077개 기업, 대부분 제품 기술 기업이며 모두가 동시에 채용 중인 것은 아님)를 나타냅니다. 다음 달의 표는 변할 것입니다.

하지만 그 형태는 변하지 않습니다. 언어(language)는 당신을 문 안으로 들여보내 줄 것입니다. 인프라는 시장에서 진정으로 이해하는 사람이 부족한 분야입니다. 바로 그 점 때문에, 인프라는 곧 대부분의 코드를 작성하게 될 기계에게 안전하게 넘겨줄 수 없는 부분이기 때문입니다. 그것이 바로 당신이 서 있어야 할 좋은 위치입니다. 만약 당신의 영역을 직접 확인해보고 저희가 틀렸거나 패턴을 벗어나는 기업을 발견한다면, 저희에게 알려주세요. 새벽 2시에 자신 있게 틀린 상태로 있는 것보다 여기서 교정받는 편이 훨씬 낫습니다.

이 포스트는 Remoet 블로그에 처음 게시되었습니다.