AI 회사는 클라우드 엔지니어에게 무슨 일을 시키나: 채용공고 1,368건을 뜯어봤다

AI 회사가 어디로 가는지 알고 싶으면 보도자료보다 채용공고가 정직하다. 발표는 하고 싶은 말만 한다. 반면 채용공고는 지금 사람이 없어서 일이 안 굴러가는 자리를 그대로 보여준다. 돈을 걸어야 올릴 수 있는 글이기도 하다.

그런데 이걸 “AI 회사 채용 소식”으로만 읽으면 남의 얘기가 된다. 진짜 값은 다른 데 있다.

이 회사들이 지금 겪는 문제는 몇 년 뒤 평범한 회사의 문제가 된다. 쿠버네티스가 그랬다. 처음엔 구글만 쓰던 것이 지금은 어디에나 있다. 그래서 공고를 “어떤 능력을 원하는가” 기준으로 다시 분류해봤다.

세는 방법은 이랬다. OpenAI와 Anthropic은 채용 정보를 누구나 받아갈 수 있게 열어둬서 공고 전문을 그대로 가져왔다. 구글은 그런 창구가 없어 채용 검색 페이지를 읽었다. 2026년 9월 8일 기준이다.

① 쿠버네티스: 기본 설정이 안 통하는 순간

먼저 용어부터. 쿠버네티스는 서버 여러 대를 하나처럼 묶어, 프로그램을 어느 서버에 올릴지 자동으로 정해주는 도구다. 지금 클라우드 업계의 사실상 표준이다.

Anthropic의 Kubernetes Platform 공고에 이런 문장이 있다.

“우리는 기본값이 더 이상 동작하지 않는 규모에서 운영한다.”

무슨 뜻일까. 쿠버네티스는 보통 알아서 잘 돌아간다. 그런데 서버가 수천 대를 넘어가면 기본 동작이 오히려 발목을 잡는다. 그래서 이들은 도구를 직접 뜯어고쳐 쓴다.

고치는 부분이 공고에 구체적으로 나온다.

스케줄러를 직접 고친다. 스케줄러는 “이 프로그램을 몇 번 서버에 올릴까”를 정하는 부분이다. 기본 스케줄러는 프로그램을 하나씩 차례로 배치한다. 그런데 AI 학습은 수천 개가 동시에 떠야 시작된다. 하나라도 자리를 못 잡으면 나머지는 자리만 차지한 채 기다린다. 여러 작업이 동시에 이러면 서로 자리를 붙잡고 아무도 진행 못 하는 상태가 된다.

그래서 갱 스케줄링(gang scheduling) 이 필요하다. “전부 자리를 잡거나, 아무것도 안 잡거나” 둘 중 하나로 만드는 방식이다. 여기에 토폴로지 인식이 더해진다. 서로 대화가 잦은 작업들을 물리적으로 가까운 서버에 모아두는 것이다. 멀리 떨어져 있으면 통신하느라 시간을 다 쓴다.

관제탑도 손본다. 쿠버네티스에는 전체를 지휘하는 부분이 있다. 공고에 나오는 apiserver는 모든 명령이 거쳐가는 창구, etcd는 현재 상태를 적어두는 장부다. 서버 수가 열 배, 백 배로 늘면 이 창구와 장부가 먼저 막힌다. 공고는 이걸 “다음 병목이 우리를 찾기 전에 먼저 찾는다“고 표현한다.

여기서 중요한 지점이 있다. 보통은 AWS의 EKS나 구글의 GKE 같은 관리형 서비스를 쓴다. 관제탑을 클라우드 회사가 대신 운영해주는 것이다. 이 회사들이 하는 일은 그 대행이 한계에 부딪히는 지점의 이야기다. 대부분의 회사는 여기까지 갈 일이 없다. 하지만 규모가 커지면 누구나 만나는 벽이기도 하다.

② 용량 계획이 엑셀에서 나왔다

용량 계획은 “다음 달에 서버가 얼마나 필요할까”를 미리 재는 일이다. 지금까지 대부분의 회사에서 이건 엑셀로 하는 일이었다. 그런데 두 회사 모두 이걸 독립된 엔지니어 직무로 뽑고 있다.

Anthropic의 Capacity Engineering 공고다.

“Anthropic은 업계에서 가장 크고 빠르게 성장하는 인프라를 운영한다 — 여러 가속기 계열, 여러 CPU 계열, 여러 클라우드에 걸쳐서.”

가속기는 AI 계산 전용 칩이다. GPU가 대표적이다. 문제는 종류가 여러 개라는 것. 게다가 클라우드도 여러 곳을 섞어 쓴다. 그러니 “지금 우리가 뭘 얼마나 갖고 있는지”를 파악하는 것 자체가 일이 된다.

Infrastructure Capacity Planner 쪽은 예측 모델을 만든다. 예측 대상이 이렇다.

• 가속기 — 칩 종류별로
• CPU — 사양별로
• 스토리지 — 등급과 사용 패턴별로
• 이그레스 — 경로별로

여기서 이그레스는 데이터가 클라우드 밖으로 나갈 때 내는 요금이다. 들어올 땐 공짜인데 나갈 땐 돈을 받는다. 클라우드 요금 고지서에서 사람들이 가장 자주 놀라는 항목이기도 하다.

공고에 나오는 네오클라우드(neocloud) 라는 단어도 새겨둘 만하다. AWS·애저·구글 같은 큰 곳 말고, GPU 빌려주는 것만 전문으로 하는 신생 업체들을 가리킨다. 이런 말이 채용공고에 등장한다는 건, 클라우드를 고르는 선택지 자체가 넓어졌다는 뜻이다.

OpenAI 공고는 목적을 아예 대놓고 적었다.

“엑셀 기반 업무를 확장 가능한 소프트웨어 시스템으로 대체한다.“

지금 클라우드 비용을 엑셀로 관리하고 있다면, 그게 곧 한계에 부딪히는 방식이라는 신호다.

③ SRE가 AIRE로 갈라지고 있다

SRE(사이트 신뢰성 엔지니어링) 는 서비스가 안 죽게 지키는 일이다. 구글이 만든 개념이고 지금은 어디서나 쓴다.

그런데 Anthropic에는 AIRE(AI 신뢰성 엔지니어링) 라는 이름의 팀이 따로 있다. 런던·더블린과 미국에 자리가 열려 있다.

“AIRE는 SDK에서 출발해 네트워크, API 계층, 서빙 인프라, 가속기를 거쳐 돌아오는 모든 구간의 신뢰성을 다룬다.”

핵심 업무 첫 줄이 “LLM 서빙에 맞는 SLO를 개발한다” 이다.

SLO는 “이 정도는 지키겠다”는 약속 숫자다. 예를 들어 “응답의 99%는 0.5초 안에”처럼 정한다. 이때 흔히 쓰는 게 p99인데, 100번 요청했을 때 99번째로 느린 경우를 기준으로 삼는 것이다. 가장 느린 소수를 무시하지 않겠다는 뜻이다.

그런데 챗봇 같은 AI 서비스는 이 방식이 잘 안 맞는다. 이유가 세 가지다.

• 속도가 두 종류다. 첫 글자가 나오기까지 걸리는 시간과, 그다음 글자들이 이어지는 속도는 따로 논다. 첫 글자는 빨리 나왔는데 뒤가 뚝뚝 끊길 수 있다.
• 요청마다 일의 양이 다르다. “안녕”과 “이 논문 요약해줘”는 계산량이 수십 배 차이 난다. 같은 잣대로 재기 어렵다.
• 묶어서 처리하면 트레이드오프가 생긴다. 요청을 여러 개 모아 한 번에 처리하면 전체 처리량은 오르지만, 개별 응답은 느려진다.

그래서 숫자 하나로 약속을 잡기가 어렵다. 이름이 따로 생긴 이유로 보인다.

④ 하드웨어 관리가 소프트웨어 일이 됐다

OpenAI의 Fleet Hardware Health 공고에 이런 문장이 있다. 플릿(fleet) 은 회사가 굴리는 서버 전체를 함대에 빗댄 말이다.

“단 한 번의 하드웨어 문제가 심각한 중단을 일으킬 수 있다. 슈퍼컴퓨터가 커질수록 위험은 계속 올라간다.”

서버 한 대가 고장 나는 건 원래 흔한 일이다. 보통은 그 한 대만 빼면 된다. 그런데 AI 학습은 수천 대가 한 몸처럼 움직인다. 한 대가 이상해지면 전체가 멈춘다. 그래서 고장을 미리 찾아내는 일이 소프트웨어 엔지니어의 업무가 됐다.

Anthropic의 Datacenter Server Lifecycle 자리는 서버 한 대의 입고부터 설치·운영·수리까지 전 과정을 소프트웨어로 다룬다. 특이한 건 보안이 곁다리가 아니라는 점이다.

“플릿의 모든 장비가 신뢰되고, 증명(attested)되고, 하드웨어 단계부터 검증된 무결성 체인 위에서 동작하도록 보증하는 것이 이 일의 핵심이며, 부차적 사항이 아니다.”

증명(attestation) 은 쉽게 말해 “이 서버가 진짜 우리 서버가 맞고, 누가 몰래 손댄 적 없다”를 기계적으로 확인하는 절차다. 지금까지 대부분의 회사에서 이건 규제 대응용 서류 작업에 가까웠다. 여기서는 매일의 운영 기본기로 들어와 있다.

참고로 이 영역은 트러블슈팅 방법 자체가 바뀌는 흐름과 맞물린다. 대규모 GPU 클러스터에서 하드웨어가 에러 없이 조용히 틀린 값을 내는 문제를 다룬 연구들이 같은 시기에 쏟아졌다.

세 회사는 서로 다른 단계에 있다

여기까지가 소프트웨어 쪽이다. 물리적인 건물 쪽으로 내려가면 세 회사의 처지가 확 갈린다.

OpenAI는 짓는 중이다. Scaling 조직 114건 중 상당수가 건설 관련이다.

• Data Center Infrastructure Architect ($360K–$530K) — 전력·냉방·장비 배치를 설계하고, 디지털 트윈으로 미리 돌려본다. 디지털 트윈은 실제 건물을 컴퓨터 안에 똑같이 만들어놓고 “이 상황에서 어떻게 되나”를 시험해보는 것이다.
• Data Center Controls Network Engineer ($257K–$327K) — 여기서 말하는 네트워크는 서버 네트워크가 아니다. 냉방기와 배전반이 물려 있는 설비 제어용 통신망(OT 네트워크) 이다.
• Datacenter Networking Technician ($157K–$221K) — 텍사스 애빌린 현장에 주 5일 상주. 광케이블을 깔고 측정하는 일이다.

여기서 눈여겨볼 게 있다. 서버 네트워크와 설비 네트워크가 만나고 있다. 원래 이 둘은 담당 부서도 장비도 완전히 달랐다. 그런데 AI 데이터센터에서는 냉방이 멈추면 곧바로 서비스가 죽는다. 분리가 유지되지 않는다.

Anthropic은 새 나라에 들어가는 중이다. Compute 조직 25건에 나라 이름이 붙은 자리가 많다.

Compute Country Lead, Korea      (서울)
Compute Country Lead, Japan      (도쿄)
Compute Country Lead, Canada
Data Center Energy Lead, EMEA    (런던)
Data Center Energy Lead, Australia (시드니)

한국 자리가 있다. 공고는 부지 선정부터 건설·운영까지 이끌며 “한국에 기가와트급 컴퓨트를 가동시키는 일에 궁극적으로 책임을 진다”고 쓴다. 다른 공고에는 “Anthropic은 미국 컴퓨팅 인프라에 500억 달러를 투자하고 있다”는 문장도 있다.

구글은 이미 돌리고 있다. "data center"로 검색하면 첫 페이지 20건이 전부 현장 정비직이다. Data Center Technician II의 자격 요건이 성격을 보여준다.

• 리눅스 사용 경험, 서버 하드웨어 문제 해결 2년
• 23kg 장비를 들어 옮기고, 자주 굽히고 무릎 꿇고 사다리를 오를 수 있을 것

OpenAI의 $360K짜리 설계자와 같은 업계 이야기인데 요구하는 게 정반대다. 구글은 20년 넘게 데이터센터를 돌려온 회사다. 지금 필요한 건 설계자가 아니라 돌릴 사람이라는 뜻이다.

세 회사가 전부 칩을 만들려 하고 있다

예상과 다른 결과가 하나 나왔다. 처음엔 “구글만 자기 칩을 만들고 나머지는 사서 쓴다”고 볼 참이었다. 그런데 세어보니 셋 다 칩 인력을 뽑고 있다.

칩 만드는 일에도 단계가 있다. RTL 설계는 칩의 동작을 코드로 적는 단계다. 검증(DV) 은 그게 맞게 동작하는지 시험하는 단계다. 브링업은 처음 만들어진 칩에 전원을 넣고 살려내는 단계다.

• OpenAI 12건 — 설계·검증·패키지·브링업까지 거의 전 단계가 열려 있다. 반도체 전담 변호사까지 뽑는다.
• Anthropic 4건 — Silicon Engineer 등. 그중에 강화학습으로 칩을 설계하는 연구 자리가 있다.
• 구글 — TPU라는 자체 칩이 이미 여러 세대 양산 중이라, 반복 개발 인력이 많다.

이게 클라우드 일과 무슨 상관일까. 칩이 다양해지면 서버가 제각각이 된다. 위에서 본 용량 계획 공고가 “여러 가속기 계열”을 전제하는 이유가 이것이다. 쿠버네티스 스케줄러를 직접 고쳐야 하는 이유이기도 하다. 다 똑같은 GPU라고 가정할 수 없어진다.

셋의 공통점: 전기, 그리고 이웃

전기. 세 회사 모두 전력 담당자를 뽑는다. Anthropic 공고는 송전망·배전망 운영 회사와 규제기관을 상대로 수백 메가와트를 확보한다고 쓴다. 한국으로 치면 한국전력을 상대하는 일이다.

병목이 GPU가 아니라 전기라는 게 세 회사 공고에 공통으로 찍혀 있다.

이건 남의 얘기가 아니다. 앞으로 특정 지역에 GPU 서버가 없는 이유가 “재고 부족”이 아니라 “그 동네 전기가 모자라서”일 수 있다는 뜻이다.

이웃. Anthropic은 Community Engagement Manager, Data Centers를 텍사스·호주·캐나다에 뽑는다. 공고는 스스로 “홍보 직무도 대관 업무도 아닌 관계 직무”라며, “문제가 커지기 전에 주민들의 우려를 미리 찾아내는” 일이라고 규정한다. 구글에도 비슷한 자리가 있다. 데이터센터를 어디에 짓느냐가 실제 갈등거리가 됐다는 뜻이다.

지금 공부하는 것이 어디로 이어지나

마지막으로 하나만 강조하고 싶다.

위 네 가지 변화는 AI 회사에 가야만 만나는 게 아니다. 서버가 늘면 쿠버네티스 관제탑은 누구에게나 병목이 된다. 비용이 커지면 용량 계획은 누구에게나 엑셀을 벗어나야 한다.

이 공고들은 그 벽을 남들보다 먼저 만난 사람들의 문제 목록이다. 그래서 이직 생각이 없어도 읽을 값이 있다. 지금 클라우드를 공부하는 중이라면, 몇 년 뒤 마주칠 문제를 미리 보는 셈이다.

한국 독자에게 가장 직접적인 신호는 Compute Country Lead, Korea다. 이 자리가 채워지면 건설·전력 쪽 국내 채용이 뒤따르는 게 보통의 순서다.

⚠️ 이 글의 공고 내용은 2026년 9월 8일 각 사 공개 채용 데이터에서 직접 받은 것이다(OpenAI는 Ashby, Anthropic은 Greenhouse 공개 API, 구글은 채용 검색 페이지). 인용문은 영문 원문을 옮긴 것이다. 연봉은 공고에 적힌 미국 기준 기본급이며 주식은 별도다. 채용공고는 며칠 만에도 바뀐다. 구글은 전체 공고 수를 공개하지 않아 표에 넣지 않았고, “첫 페이지 20건”은 검색 1페이지 기준이다. AI 서비스의 응답 속도 특성이나 관리형 쿠버네티스의 한계에 대한 설명은 공고에 적힌 내용이 아니라 필자의 해석이다.

자주 묻는 질문

클라우드를 이제 막 공부하는데, 이 글의 내용을 알아야 하나요?

지금 당장 필요하지는 않습니다. 여기 나온 문제들은 서버 수천 대를 굴릴 때 생기는 것이고, 대부분의 회사는 그 규모가 아닙니다. 다만 방향을 알아두면 무엇을 깊게 팔지 정하는 데 도움이 됩니다. 예를 들어 쿠버네티스를 “쓸 줄 안다”에서 멈추지 않고 “어떻게 자리를 정하는지” 원리까지 보는 것, 클라우드 요금표에서 이그레스 같은 항목이 왜 있는지 이해하는 것입니다. 둘 다 지금 공부에 바로 얹을 수 있습니다.

AWS의 EKS를 쓰면 스케줄러를 고칠 일은 없는 것 아닌가요?

대부분 그렇습니다. 관리형 서비스는 어려운 부분을 대신 맡아주고, 그게 존재 이유입니다. 다만 어느 지점에서 그 대행이 한계에 닿는지는 알아둘 만합니다. 작업이 자리를 못 잡고 오래 기다리거나, 큰 작업이 일부만 뜬 채 멈춰 있거나, 명령을 내려도 반응이 느려지기 시작하면 그 신호입니다. 실무에서 이 증상을 만났을 때 “서비스가 이상하다”가 아니라 “규모의 한계에 닿았다”로 읽을 수 있으면 대응이 완전히 달라집니다.

갱 스케줄링이 왜 필요한지 다시 설명해주세요.

식당에서 10명이 함께 밥을 먹으러 갔다고 생각하면 쉽습니다. 자리가 6개뿐인데 6명만 먼저 앉으면, 나머지 4명은 서서 기다리고 앉은 6명도 식사를 시작하지 못합니다. 다른 일행도 같은 식으로 자리를 나눠 잡으면 아무도 못 먹습니다. AI 학습이 정확히 이렇습니다. 수천 개가 전부 자리를 잡아야 시작됩니다. 갱 스케줄링은 “10자리가 한 번에 나면 앉고, 아니면 아예 앉지 않는다”는 규칙입니다.

용량 계획은 클라우드 비용 관리(FinOps)와 같은 건가요?

겹치지만 다릅니다. 비용 관리는 이미 쓴 돈을 보고 줄이는 쪽에 무게가 있습니다. 반면 이 공고들은 앞으로 얼마나 필요할지 예측하고 나눠주는 일을 요구합니다. 게다가 엑셀 작업이 아니라 프로그램을 만드는 일입니다. OpenAI 공고가 “엑셀 기반 업무를 소프트웨어로 대체한다”고 명시한 그대로입니다.

AI 회사 인프라 일을 하려면 AI를 알아야 하나요?

모델을 만들 줄 알 필요는 없습니다. 이 글에서 다룬 직무 대부분이 모델을 직접 건드리지 않습니다. 다만 AI 작업이 다른 프로그램과 뭐가 다른지는 알아야 합니다. 왜 수천 개가 동시에 떠야 하는지, 왜 서버끼리 가까이 있어야 하는지 같은 것들입니다. 이건 클라우드 공부의 연장선에서 익힐 수 있고, 모델 학습을 배우는 것과는 다른 종류의 지식입니다.

국내에도 이런 자리가 생길까요?

건물 쪽은 이미 조짐이 있습니다. Compute Country Lead, Korea(서울)가 열려 있고, 이런 자리가 채워지면 건설·전력 쪽 국내 채용이 따르는 것이 일반적입니다. 다만 공고만으로 실제 건설 확정을 단정할 수는 없습니다. 소프트웨어 쪽은 시차를 두고 옵니다. 다만 이 글의 네 가지 변화는 AI 회사가 아니어도 규모가 커지면 만나는 문제라, 국내 대형 서비스에서도 비슷한 자리가 생길 가능성이 높습니다.