본문으로 건너뛰기
⚙️ 공학·기술

📦MLOps 엔지니어

프로덕션 환경에서 기계 학습 모델을 교육, 배포, 모니터링 및 관리하는 시스템을 구축합니다.

다른 이름: Machine Learning Operations Engineer · ML Platform Engineer

검토 2026-08·미디어 크레딧

이 페이지 공유

핵심 정보

2010년대 후반대중화된 용어
숨겨진 기술 부채, 2015주요 논문
~$130,000~$210,000미국 유료 밴드
모델 드리프트핵심 관심사
쿠버네티스공통 플랫폼
ISO/IEC 42001거버넌스 표준

An MLOps engineer makes machine-learning systems dependable after the prototype. Data scientists may train a model in a notebook; the MLOps engineer builds the reproducible pipelines, feature stores, deployment environments, monitoring and rollback paths that let it operate safely for real users. The job sits between data science, software engineering, cloud infrastructure and risk management.

The role emerged when companies discovered that a good offline model is not the same as a useful product. Data changes, code changes, costs rise, a model can degrade quietly, and a prediction may need explanation or review. Google researchers described this accumulation of dependencies and maintenance work as “hidden technical debt” in machine-learning systems in 2015; the industry later adopted MLOps as a shorthand for operating that debt deliberately.

MLOps is well paid because it requires breadth and because many organizations are trying to deploy AI faster than their operating practices mature. Generative AI has increased demand for evaluation, observability and access controls. It also automates parts of the job—pipeline templates, configuration and diagnostics—so the durable skill is designing reliable systems and deciding what evidence is sufficient to trust a model.

직업 속으로

MLOps는 모델이 프로덕션과 충돌해도 살아남게 하는 규율이다. 바뀌는 데이터·불완전한 라벨·클라우드 비용·소프트웨어 배포, 그리고 실패를 설명하거나 멈춰야 하는 사람을 함께 다룬다.

노트북 너머

오프라인 벤치마크를 이긴 모델은 아직 제품이 아니다. MLOps 엔지니어는 학습을 재현 가능하게 만들고, 데이터·코드 버전을 기록하며, 서빙용으로 패키징하고, 모니터링과 롤백 경로를 만든다. 성공은 자주 보이지 않는다. 몇 달 뒤에도 실험이 반복되고, 깨진 소스가 예측을 오염시키기 전에 잡히며, 고객에게 답한 모델이 정확히 무엇인지 팀이 안다. 국내 대규모 서비스에서는 트래픽 폭주·피처 지연·야간 배치 실패가 그 ‘보이지 않는 성공’을 시험한다. 데모 정확도보다 장애 시 설명 가능성이 신뢰를 만든다. 피처 지연·라벨 누수·야간 배치 실패는 벤치마크에 안 보이지만 고객에게는 바로 보인다. 국내 대규모 트래픽 서비스에서는 비용 폭발과 개인정보 로그가 동시에 터질 수 있어, 관측 가능성과 접근 통제가 배포 체크리스트에 들어간다.

모델 문해력을 갖춘 시스템 역할

일은 데이터 엔지니어링·소프트웨어 배달·클라우드 인프라에, 학습-서빙 스큐나 무의미한 평가를 알아챌 만큼의 머신러닝을 더한 것이다. 어떤 엔지니어는 여러 연구팀을 위한 공유 플랫폼을 짓고, 어떤 엔지니어는 단일 제품 배포를 소유한다. 쿠버네티스·오케스트레이션·레지스트리는 도구이지 공예가 아니다. 공예는 무엇이 추적 가능해야 하는지, 무엇을 근거로 모델을 릴리스할지 정하는 일이다. 한국 대기업 AI 조직에서는 보안·개인정보·온프레미스 제약이 클라우드 네이티브 교과서와 다른 설계를 강제한다. 온프레미스·폐쇄망·보안 심의는 클라우드 네이티브 교과서를 수정하게 만든다. 플랫폼 팀은 셀프서비스와 가드레일 사이에서 제품을 설계하고, 제품 팀은 한 모델의 SLO를 지킨다. ‘쿠버네티스를 안다’와 ‘모델을 책임지고 멈출 수 있다’는 다른 문장이다.

사람들이 들어오는 길

대부분은 MLOps 학위가 아니라 소프트웨어·플랫폼·데이터·ML 엔지니어링에서 들어온다. 설득력 있는 포트폴리오는 전체 수명주기를 보여 준다. 버전된 데이터, 반복 가능한 학습, 평가, 배포, 모니터링, 실패 모드 설명. 고용주가 프레임워크 배지 모음보다 이를 중시하는 이유는 프로덕션이 데모에 없는 의존성을 쌓기 때문이다. 국내에서는 클라우드 자격과 함께, 실제 서비스 장애 회고·비용 최적화·한국어 NLP 파이프라인 경험이 차별점이 된다. 포트폴리오에는 학습 재현뿐 아니라 롤백·카나리·데이터 계약 위반 시나리오가 있어야 한다. MLOps 직함이 없는 공고에도 데이터·ML·플랫폼 엔지니어로 숨은 경우가 많다. 한국어 NLP·추천·광고 파이프라인 경험이 면접에서 빠르게 통한다.

LLM이 넓히는 운영면

생성형 AI는 스캐폴딩·설정·진단을 빠르게 하지만, 검색 저장소·프롬프트·도구·권한·평가셋·추론 비용이라는 운영면을 더한다. 역할은 고립된 예측기 배포에서 AI 시스템 거버넌스로 이동 중이다. 자동화는 처리량을 올리지만, 허용 가능한 오류·데이터 접근·롤백 조건을 결정하지는 않는다. 한국 금융·공공·플랫폼은 환각·개인정보 유출·설명 책임을 이유로 평가 게이트와 승인 기록을 더 두껍게 깐다. LLMOps는 새 유행어라기보다, 기존 MLOps에 정책과 비용이 붙은 확장이다. LLMOps는 프롬프트 관리·평가셋·도구 권한·토큰 비용·환각 모니터링을 운영면에 추가한다. 금융·공공은 설명·감사 추적을 요구하고, 소비자 서비스는 속도 경쟁을 한다. 자동화는 실험 횟수를 늘리되, 허용 오류의 정책은 사람이 서명한다.

일이 갈라지는 방식

같은 직함 아래 흔한 다섯 갈래 — 전문 분야, 일터, 커리어 경로.

사내 공유 플랫폼

ML 플랫폼 엔지니어

여러 모델 팀을 위한 학습·레지스트리·배포·컴퓨트 서비스를 재사용 가능하게 만든다.

프로덕션 모델 시스템

ML 신뢰성 엔지니어

파이프라인·추론·데이터 의존성에 관측·장애 대응·신뢰성 공학을 적용한다.

파운데이션 모델 응용

LLMOps 엔지니어

검색·평가·프롬프트·도구 사용·비용 통제를 언어모델 제품 주변에 운영한다.

데이터 인프라

데이터·피처 플랫폼 엔지니어

학습과 서빙이 의존하는 신선도·품질·리니지 계약을 소유한다.

규제·고영향 사용

책임 있는 AI 운영 전문가

승인 기록·평가 게이트·모니터링으로 모델 배포를 거버넌스에 연결한다.

나라마다 다르게 읽히는 이유

같은 일이라도 진입 관문·지위·일상이 다릅니다. 각 언어 독자가 실제로 찾는 맥락으로 다시 썼습니다.

미국 — 플랫폼 규모와 주식

대형 클라우드·프론티어 모델 랩·데이터 집약 기업이 가장 깊은 플랫폼 일을 제공한다. 보상에 주식이 크게 들어가지만, 채용은 선행 프로덕션 엔지니어링 깊이를 기대한다.

한국 — 제품 론칭과 기업 AI

네이버·카카오·통신·제조 대기업이 스타트업과 나란히 AI 역량을 쌓는다. 한국어 제품·클라우드·거버넌스를 잇는 엔지니어가 특히 쓸모 있다. 대기업은 온프레미스·보안 심의가 배포를 늦추고, 스타트업은 빠른 실험과 불안정한 관측이 공존한다. MLOps라는 직함이 아직 혼재되어 데이터 엔지니어·ML 엔지니어 공고에 녹아 있는 경우도 많다.

일본 — 엔터프라이즈 통합

MLOps는 기존 기업 시스템에 모델을 연결하고 신중한 변경 관리·신뢰성을 맞추는 일이 된다. 외국계는 클라우드 네이티브를, 국내 프로젝트는 더 신중한 속도를 보일 수 있다.

독일 — 산업·프라이버시 제약

제조·자동차·규제 부문이 데이터 리니지·배포 통제·프라이버시를 중심에 둔다. 퍼블릭 클라우드만이 아니라 하이브리드 시스템이 흔하다.

영국 — 금융과 연구 허브

런던 금융·테크는 감사 가능한 모델 운영을 원하고, 대학·스타트업이 연구 인력을 공급한다. 모델 리스크 통제가 아키텍처를 일찍 규정할 수 있다.

싱가포르 — 지역 AI 플랫폼

은행·공공·다국적 HQ가 여러 시장에서 모델을 운영할 팀을 원한다. 데이터 레지던시·벤더 선택·지역 지연이 설계에 들어간다.

이 일에서 태도가 중요한 이유

운영 환경에서 성능이 떨어지는 머신러닝 모델은 에러 메시지를 띄우지 않는다. 그저 조용히 나빠질 뿐이며, 그래서 눈에 띄지 않는 모니터링 작업을 대하는 MLOps 엔지니어의 태도가 정상 작동과 조용한 실패 사이의 유일한 방벽이 된다.

모델 드리프트는 조용히, 요란하지 않게 실패한다

서버가 다운되는 것과 달리, 현실과 어긋나기 시작한 모델은 계속 자신감 있어 보이는 예측값을 내놓으면서도 조용히 틀려간다. 아무도 신호를 보내지 않은 채 입력 데이터가 조금씩 바뀌었기 때문이다. 이를 알아채려면 마감이 걸리지 않은 대시보드를 지켜보는 습관이 필요하며, 이런 유지보수 작업은 출시 압박 아래 가장 먼저 뒷전으로 밀린다. 모니터링을 선택 사항으로 취급하는 엔지니어는 실제로 시스템이 언제 실패하는지 알지 않기로 스스로 선택하는 것과 같다. 국내 스타트업의 짧은 개발 주기 속에서 이 선택은 특히 자주 반복된다.

재현성을 지키지 않으면 사고는 풀 수 없는 문제가 된다

마감에 쫓겨 데이터 버전 관리를 건너뛰거나, 라벨링되지 않은 실험 코드로 그대로 배포하거나, 설정값을 코드에 하드코딩해버리는 지름길은 여섯 달 뒤 발생한 장애를 완전히 진단 불가능하게 만들 수 있다. 어떤 코드와 데이터, 파라미터가 그 문제의 모델을 만들어냈는지 아무도 재구성할 수 없기 때문이다. 꼼꼼한 버전 관리의 가치는 그것이 팀이 짐작이 아니라 실제 근본 원인을 찾아낼 유일한 수단이 되는 그 순간까지는 눈에 보이지 않으며, 그 순간이 오기 전까지는 이 습관을 지키는 사람도 지키지 않는 사람도 겉보기에 똑같아 보인다.

자신이 만들지 않은 실패를 그대로 물려받는다

데이터 과학자는 노트북에서 훈련한 모델을 넘기고 다음 프로젝트로 넘어갈 수 있지만, 그 모델이 새벽 2시 운영 환경에서 망가지면 호출을 받는 사람은 MLOps 엔지니어이며, 원래 훈련 코드를 누가 썼든 그 실패를 해결하는 것은 이제 이 엔지니어의 몫이다. 다른 팀, 심지어 다른 사람이 만든 문제를 그 작성자에게 책임을 떠넘기지 않고 온전히 떠안는 태도는 다른 어떤 엔지니어링 직군보다 이 직업이 유독 더 많이 요구하는 자세이며, 이 자세가 없으면 팀 사이의 책임 떠넘기기가 장애 복구보다 먼저 시작된다. 결국 시스템이 살아나는 속도는 누가 잘못했는지를 따지는 데 걸리는 시간이 아니라, 누가 먼저 고치기 시작하는지에 달려 있다.

압박 속에서도 무너지지 않는 태도

구호가 아니라, 실제 업무가 요구하는 다섯 가지 구체적 자세입니다.

롤백 경로 없이는 배포를 거부한다

빠르게 출시하라는 압박이 있어도 새 모델 버전을 배포하기 전에 실제로 테스트된 롤백 메커니즘이 존재하는지 먼저 확인한다. 롤백 경로가 없다는 것은 평범한 나쁜 모델을 장기간 이어지는 서비스 장애로 바꿔버리는 결정적 요인이며, 이 확인 절차를 건너뛰는 일이 없도록 스스로 규율을 지킨다. 이 확인이 형식적인 체크리스트 항목으로만 남지 않도록 실제로 되돌리기 버튼을 눌러보는 것까지 습관으로 삼으며, 그 버튼이 실제로 작동하지 않는 순간을 배포 전에 발견하는 것이 이 습관의 진짜 값어치다.

모니터링을 핵심 결과물로 취급한다

모델이 그럴듯하게 작동하는 것처럼 보이면 무한정 미뤄지곤 하는 후속 작업이 아니라, 최초 출시 자체의 일부로 알림과 드리프트 감지 체계를 함께 구축한다. 모니터링이 없는 모델은 그것이 실패하는 순간을 아무도 알아채지 못하는 모델과 다를 바 없다는 것을 알기 때문이며, 이 인식이 없는 팀은 장애가 고객의 항의로 처음 드러나는 상황을 반복해서 겪는다. 대시보드를 만드는 시간은 항상 다음 기능 개발보다 우선순위에서 밀리기 쉽다.

알고 있는 한계를 숨기지 않고 문서로 남긴다

자신감 있는 출시 서사를 원하는 관계자 앞에서 데모가 덜 인상적으로 보일 수 있어도, 모델이 잘 처리하지 못하는 부분을 명시적으로 적어둔다. 운영 중 새로운 실패 양상이 발견될 때마다 그 문서를 다시 열어 갱신하는 습관도 함께 지키며, 이 문서가 없으면 같은 한계에 다음 팀원이 몇 주씩 부딪히게 된다. 이 정직한 기록이 결국 다음 버전을 더 빠르게 만드는 지도가 된다.

새벽 파이프라인 장애의 근본 원인을 먼저 찾는다

그저 다시 실행해 알림을 멈추게 하기 전에, 파이프라인이 실제로 왜 실패했는지 진단한다. 재시작 후 다행이라고 넘기는 대응은 데이터 손상이나 설정 오류를 감춘 채 더 불편한 시간에, 더 나쁜 모습으로 되돌아오게 만들 수 있기 때문이며, 그 재발은 대개 원인을 미뤄둔 그 사람이 없는 시간에 벌어진다. 졸린 눈으로도 로그를 끝까지 읽어내는 것이 이 태도의 전부다.

'일단 출시하자'는 압박에 근거로 대응한다

제품팀이 더 빠른 배포를 밀어붙일 때 조용히 물러나 그 불안정성을 나중에 개인적인 실패로 떠안는 대신, 구체적인 기술 부채와 신뢰성에 관한 근거를 제시하며 대응한다. 이 근거 제시가 이루어지는지 아닌지가 팀 전체의 장기적 안정성을 좌우하며, 근거 없이 물러서는 습관이 반복되면 나중에는 그 누구도 반대 의견을 진지하게 듣지 않게 된다. 데이터로 뒷받침된 반대는 감정적인 저항과는 완전히 다른 무게를 가진다.

진짜와 가짜를 가르는 순간

이력서용 표현과 실제 수행이 갈라지는 상황들입니다.

3주에 걸쳐 조용히 나빠지는 모델

성능이 어느 하루도 특별히 경보를 울릴 정도는 아닐 만큼 서서히 저하된다. 누군가 이것을 실제로 알아채는지, 그리고 얼마나 빨리 알아채는지는 최초 배포 당시 모니터링이 형식적인 체크박스가 아니라 진짜 관심을 갖고 설계되었는지에 전적으로 달려 있으며, 발견이 늦어질수록 그 사이 잘못된 예측에 기반한 결정이 쌓여간다. 3주 뒤에야 알아챈 팀은 이미 3주 치 잘못된 결과를 되돌려야 한다.

관계자가 평가 단계를 건너뛰자고 요청할 때

마감 압박 속에서 관계자가 전체 평가 절차 없이 데모 수준의 모델을 그대로 배포하자고 제안한다. 평가 원칙을 굽히지 않고 그 위험을 비전문가도 판단할 수 있는 말로 설명하는지가, 이 직업이 가진 실질적인 영향력이 실제로 쓰이는지 버려지는지를 가르며, 이 순간을 넘기지 못하면 다음에도 같은 압박이 더 쉽게 반복된다. 한 번 양보한 기준은 다음번에 지키기가 훨씬 더 어려워진다.

새벽 2시 파이프라인 장애

자동화된 파이프라인이 야간에 멈춘다. 알람을 멈추기 위해 즉시 재시작하는 것과, 실제 원인을 찾을 때까지 깨어 있는 것 사이의 선택이 다음 주에 같은 장애가 똑같이 반복되는지 아닌지를 결정하며, 이 선택은 피곤함이 가장 클 때 가장 자주 시험받는다. 다음 날 아침 회고에서 이 선택은 결과로만 조용히 드러난다.

사후 분석이 자신의 과거 지름길을 지목할 때

사고 회고에서 몇 달 전 시간 압박 속에 스스로 내렸던 설정 결정이 근본 원인으로 드러난다. 그 사실을 회고 보고서에 수동적이고 주체 없는 문장으로 흐리는 대신, 분명하게 자신의 이름으로 적어내는지가 직업적 정직성의 구체적인 시험이 되며, 이 정직함이 쌓여야 팀 전체가 같은 실수를 반복하지 않는다. 이름을 밝히는 데는 용기가 필요하지만 그 용기가 결국 팀의 시간을 아껴준다.

"소명"이 해가 되는 지점

'AI에 대한 열정'과 무급 온콜

AI 제품을 만드는 국내외 스타트업들은 사명과 중요성을 강조하는 언어로 MLOps 엔지니어를 채용한 뒤, 무급 초과근무 없이는 유지될 수 없을 만큼 작은 팀에 24시간 상시 대기 순번을 부과하는 일이 흔하다. 작은 플랫폼 팀이 훨씬 큰 조직이 만든 모델의 온콜을 대신 떠안으면서, 원인이 자기 팀보다 훨씬 상류에 있는 실패의 책임까지 흡수하는 구조도 반복된다. 야간 대기를 정식 근무가 아니라 열정의 증거로 포장하는 관행은 빠르게 성장하는 AI 기업일수록 더 흔하며, 스톡옵션이 실질적 보상 대신 제시되는 경우도 드물지 않다.

직업 프로필

548472658684
  • AI 내성54
  • 보수84
  • 진입장벽72
  • 자율성65
  • 수요86
  • 영향력84

AI에 얼마나 노출되어 있나?

46 / 100

보통의

템플릿, 구성 및 1차 진단은 자동화 가능성이 높지만 모델을 고유한 조직에 통합하려면 시스템 설계, 평가 및 책임 있는 위험 결정이 필요합니다. AI는 엔지니어당 생산량을 늘리는 동시에 운영 규율이 필요한 시스템의 수와 복잡성을 확대할 가능성이 높습니다.

AI와 미래 →

이 직업을 보는 일곱 가지 관점

자주 묻는 질문

MLOps 엔지니어는 어떤 일을 하나요?
MLOps 엔지니어는 기계 학습 실험을 반복 가능하고 모니터링되는 서비스로 전환합니다. 데이터 및 교육 파이프라인을 구축하고, 모델을 패키징하고, 클라우드 또는 엣지 환경에 배포하고, 버전을 추적하고, 성능을 모니터링하고, 롤백 절차를 생성합니다. 소규모 팀에서는 애플리케이션 코드를 작성할 수도 있습니다. 대규모 팀에서는 많은 데이터 과학 팀을 위한 공유 플랫폼을 운영합니다.
MLOps는 데이터 과학과 어떻게 다릅니까?
데이터 과학자는 일반적으로 문제 프레이밍, 데이터 분석 및 모델 개발에 중점을 둡니다. MLOps는 시간이 지남에 따라 모델을 재현, 배포 및 관찰할 수 있도록 만드는 데 중점을 둡니다. 구별이 절대적이지는 않습니다. 강력한 팀은 평가 및 데이터 품질을 위해 협력하는 반면, MLOps 엔지니어는 배포 후 모델이 어떻게 실패할 수 있는지 이해하기 위해 충분한 ML 지식이 필요합니다.
MLOps를 위해서는 석사 학위가 필요합니까?
아니요. 컴퓨터 과학, 공학 또는 데이터 중심 학위가 일반적이지만 실용적인 소프트웨어, 클라우드 및 데이터 플랫폼 경험은 고급 연구 자격증보다 더 중요할 수 있습니다. 새로운 모델을 구축하는 역할은 대학원 공부를 선호할 수 있습니다. ML 플랫폼을 운영하는 역할은 일반적으로 생산 엔지니어링, 인프라 및 신중한 실험을 높이 평가합니다.
MLOps 엔지니어는 어떤 프로그래밍 언어를 사용하나요?
Python은 대부분의 ML 생태계에서 사용되기 때문에 일반적입니다. SQL은 데이터 작업에 필수적인 반면 Docker, YAML 및 코드형 인프라 구성은 일상적인 도구입니다. 일부 플랫폼 팀에서는 Go, Java, Scala 또는 TypeScript도 사용합니다. 중요한 기능은 하나의 언어에 대한 충성도가 아니라 파이프라인을 테스트, 버전 관리 및 관찰 가능하게 만드는 것입니다.
모델 드리프트란 무엇입니까?
모델 드리프트는 환경, 사용자 행동, 입력 또는 결과가 변경되기 때문에 배포된 모델의 유용성이 떨어지는 것을 설명합니다. 작년 패턴으로 훈련된 사기 모델은 새로운 사기를 놓칠 수도 있습니다. 입력 분포, 예측 품질 및 비즈니스 결과를 모니터링하면 눈에 띄지 않는 감소가 해로운 결정으로 변하기 전에 팀이 드리프트를 발견하는 데 도움이 됩니다.
MLOps는 DevOps와 동일합니까?
MLOps는 자동화, 버전 제어, 지속적인 전달, 공유 소유권 등 DevOps 아이디어를 차용하지만 데이터 및 모델 문제를 추가합니다. 애플리케이션 코드는 변경되지 않더라도 훈련 데이터는 변경되므로 모델이 변경될 수 있습니다. 팀은 데이터세트 버전을 관리하고, 모델 동작을 평가하고, 실험을 관리하고, 예측 품질과 서버 상태를 모니터링해야 합니다.
MLOps 엔지니어의 수입은 얼마인가요?
보상은 국가와 회사에 따라 다릅니다. 미국의 주요 기술 및 금융 시장에서 숙련된 MLOps 엔지니어는 일반적으로 6자릿수 중반 현금 및 자산 범위에 속하며, 유럽 및 아시아 급여는 현지 밴드 및 복리후생 구조를 사용합니다. 클라우드, 분산 시스템, 책임 있는 AI 경험을 통해 급여는 올라가지만 직위는 표준화되지 않았습니다.
생성적 AI가 MLOps 엔지니어를 대체할까요?
구성, 코드 및 문서를 생성하여 일상적인 설정 작업을 줄일 수 있습니다. 평가를 정의하고, 데이터 권한을 관리하고, 모델 액세스를 제어하고, 오류를 조사하거나 시스템이 사용자에게 해를 끼칠 때 책임을 져야 할 필요성이 제거되지는 않습니다. 생성 모델은 또한 새로운 운영 위험을 추가하여 이를 측정하고 관리할 수 있는 사람에 대한 수요를 증가시킵니다.

이 랭킹 퍼가기

이 코드를 블로그나 사이트에 붙여넣으세요 — 랭킹은 항상 최신으로 유지됩니다.

비교하기…

비슷한 직업

같은 분야만이 아니라 여섯 점수 프로필이 가까운 직업입니다.

계속 탐색하기

공학·기술 분야의 다른 직업

💻

소프트웨어 엔지니어

현대 사회를 움직이는 코드를 작성하고 테스트하고 유지보수하는 직업이며, AI가 자기 일상 업무를 자동화하는 모습을 가장 먼저 지켜보는 직업 중 하나다.

AI 내성 35
🤖

AI 연구원

기계 지능을 뒷받침하는 알고리즘을 설계하고 검증하는 직업으로, 이제는 자기 자신의 연구 과정 상당 부분을 자동화하려는 경쟁이 벌어지는 분야이기도 하다.

AI 내성 50
🛰️

항공우주공학자

지상을 벗어나는 항공기, 로켓, 우주선을 설계하고 분석하고 인증하며, 추측의 여지가 없는 안전 여유를 다루는 직업이다.

AI 내성 74
🌉

토목공학자

강과 바위와 중력을 다리, 도로, 맑은 물로 바꾸는 직업 — 임호테프 이래 문명을 떠받쳐온 조용한 하중지지의 업.

AI 내성 72
🔌

반도체 엔지니어

컴퓨터, 휴대폰, 무기 등 거의 모든 전자기기 내부의 트랜지스터를 설계하고 제조하며, 지구상 극소수 공장만이 다룰 수 있는 초정밀 장비를 다룬다.

AI 내성 60
🦾

로봇공학 엔지니어

물리적 세계를 감지하고 판단하고 행동하는 기계를 설계하는 사람으로, 진짜 난제는 지능이 아니라 언제나 세계 그 자체였다.

AI 내성 65
🔐

사이버보안 전문가

디지털 공격을 찾아내고 예방하며 대응함으로써 시스템, 데이터, 사람을 지킨다.

AI 내성 63
🌬️

재생에너지 엔지니어

재생 가능한 자원을 신뢰할 수 있는 전기로 전환하는 풍력, 태양열, 저장 및 그리드 시스템을 설계, 구축 및 개선합니다.

AI 내성 72