이력서 첫 화면에 Kubernetes와 AWS를 적어 두었는데, 실제 공고에서도 자주 요구하는지 궁금했던 적 있으신가요?
최근 30일 동안 인프라·DevOps 공고 32건을 세어 봤습니다. 회사 수는 24개였습니다. 가장 자주 보인 기술은 Kubernetes, AWS, Python이었고, 각각 16건에서 나타났습니다.
이번 글에서는 기술 목록을 나열하는 데서 멈추지 않고, 이직을 준비하는 사람이 이력서에서 무엇을 먼저 보여줄지 정리해 보겠습니다.
| 기술 | 공고 수 | 회사 예시 |
|---|---|---|
| Kubernetes | 16건 | 딥오토, 로앤컴퍼니, 몰로코, 베스핀글로벌, 베슬에이아이 |
| AWS | 16건 | 더즌, 딥오토, 로앤컴퍼니, 베스핀글로벌, 빗썸 |
| Python | 16건 | 고영테크놀러지, 데이원컴퍼니, 딥오토, 라인플러스, 몰로코 |
| CI/CD | 9건 | |
| Terraform | 9건 | |
| GCP | 8건 | |
| Azure | 7건 | |
| Linux | 7건 | |
| Go | 5건 | |
| GitHub Actions | 5건 |
Kubernetes, AWS, Python이 같은 수로 가장 위에 있습니다. 어느 하나만 앞선다기보다 컨테이너 운영, 클라우드 환경, 자동화에 필요한 언어가 함께 반복된 모양입니다.
이 표를 이력서 순서에 그대로 옮길 필요는 없습니다. 자신이 실제로 맡은 업무와 가장 가까운 기술을 앞에 두는 것이 먼저입니다.
Kubernetes를 요구한 회사 예시에는 딥오토, 로앤컴퍼니, 몰로코, 베스핀글로벌, 베슬에이아이가 있습니다.
이력서에 Kubernetes만 적으면 사용 범위를 알기 어렵습니다. 클러스터를 운영했는지, 배포를 담당했는지, 장애나 리소스 문제를 다뤘는지에 따라 경험의 깊이가 달라집니다.
기술 이름 뒤에 실제 책임을 붙여 보세요.
위 내용을 모두 했다는 뜻은 아닙니다. 실제로 맡은 일만 남기면 됩니다.
“Kubernetes 사용”보다 “Kubernetes 환경에서 배포와 장애 대응을 담당”처럼 쓰면 어떤 일을 맡겼을 때 대응할 수 있는지가 먼저 보입니다.
AWS를 요구한 회사 예시에는 더즌, 딥오토, 로앤컴퍼니, 베스핀글로벌, 빗썸이 있습니다.
AWS도 서비스 이름을 길게 적는 것만으로는 경험의 범위가 잘 드러나지 않습니다. 어떤 시스템을 운영했고, 배포와 모니터링을 어디까지 맡았는지가 중요합니다.
이력서에서는 AWS를 사용한 환경, 본인이 책임진 운영 범위, 그 과정에서 바꾼 점을 이어 쓰면 좋습니다.
예를 들어 실제 경험에 맞춰 다음처럼 적을 수 있습니다.
“AWS 환경에서 서비스 배포와 모니터링 운영을 담당했습니다.”
비용, 장애, 확장, 권한, 배포 중 무엇을 다뤘는지는 본인이 한 일에 따라 달라집니다. 해 보지 않은 업무를 덧붙이지 않는 것이 중요합니다.
AWS를 단순히 사용한 것인지, 인프라 운영까지 맡은 것인지 구분해서 적으면 다음 질문도 줄어듭니다.
Python을 요구한 회사 예시에는 고영테크놀러지, 데이원컴퍼니, 딥오토, 라인플러스, 몰로코가 있습니다.
인프라·DevOps 공고에서 Python은 애플리케이션 개발만 뜻하지 않을 수 있습니다. 운영 자동화, 배포 도구, 점검 스크립트, 데이터 처리처럼 반복 작업을 줄이는 용도로도 사용됩니다.
따라서 “Python 가능”으로 끝내기보다 실제로 무엇을 자동화했는지 적는 편이 좋습니다.
회사 인프라를 운영한 경험이 없어도 개인 프로젝트나 팀 프로젝트에서 직접 만든 결과물이 있다면 설명할 수 있습니다. 다만 본인이 하지 않은 운영 경험을 보태서는 안 됩니다.
Kubernetes, AWS, Python 다음으로 CI/CD와 Terraform이 각각 9건에서 보였습니다. GCP는 8건, Azure와 Linux는 각각 7건이었습니다. Go와 GitHub Actions는 각각 5건에서 나타났습니다.
이 목록은 인프라·DevOps 업무가 하나의 기술만으로 끝나지 않는다는 점을 보여줍니다. 클라우드 환경을 구성하고, Linux에서 서비스를 운영하고, Terraform으로 인프라를 관리하고, CI/CD나 GitHub Actions로 배포하는 식으로 경험이 이어질 수 있습니다.
이력서에서는 기술을 흩어 놓기보다 실제 업무 흐름으로 묶어 보세요.
예를 들어 실제 경험에 맞춰 다음처럼 적을 수 있습니다.
“AWS 환경에서 Terraform으로 인프라를 관리하고, GitHub Actions를 이용해 배포 자동화를 운영했습니다.”
이 문장을 그대로 쓰라는 뜻은 아닙니다. 실제로 한 경험에 맞춰 고쳐야 합니다. 중요한 것은 기술을 많이 나열하는 것보다 어떤 순서로 사용했는지를 보여주는 것입니다.
경력 표기는 5~7년 이상이 10건으로 가장 많았습니다. 3~4년 이상과 표기 없음은 각각 7건이었고, 8년 이상은 4건이었습니다. 신입·무관과 1~2년 이상은 각각 2건이었습니다.
이번 기록에서는 중간 이상 경력을 요구하는 공고가 많이 보였습니다. 그래서 인프라·DevOps로 옮기려는 사람은 기술 이름보다 책임의 범위를 앞에 두는 편이 좋습니다.
5~7년 이상이나 8년 이상을 요구하는 공고를 보는 사람이라면 운영한 시스템의 범위, 장애가 발생했을 때 맡은 판단, 배포와 운영 기준을 만든 경험을 먼저 보여줄 수 있습니다.
3~4년 이상을 요구하는 공고라면 직접 운영한 환경과 반복 업무를 줄인 경험을 앞에 두는 방식이 좋습니다.
신입·무관 공고를 보는 사람이라면 연차 대신 프로젝트에서 배포, 자동화, 모니터링을 어디까지 직접 해 봤는지를 적을 수 있습니다.
이번 표본은 최근 30일의 인프라·DevOps 공고 32건입니다. 회사 수는 24개입니다. 전체 개발 채용 시장의 기술 요구를 뜻하지 않습니다.
같은 회사가 여러 공고를 냈다면 같은 기술이 반복해서 보일 수 있습니다. 따라서 Kubernetes, AWS, Python이 각각 16건이라는 수치를 회사 수로 읽어서는 안 됩니다.
이번 편은 원티드 한 곳과 비교한 결과가 아닙니다. tailf가 회사 채용 페이지에서 모은 인프라·DevOps 공고의 기술 요구를 센 기록입니다.
측정 시각은 2026-10-10 16:16 KST입니다. 공고가 바뀌면 결과도 달라질 수 있습니다.
현재 tailf가 확인하는 회사는 352개이고, 열린 공고는 2081건입니다. 이번 글에서는 그중 인프라·DevOps 공고 32건만 봤습니다.
이 숫자만으로 특정 기술을 배워야 한다고 말할 수는 없습니다. 다만 이직을 준비하면서 어떤 기술부터 공고와 대조하고, 이력서 어느 부분을 고칠지 정하는 기준으로는 사용할 수 있습니다.
앱 없이 오늘 할 수 있는 일부터 적겠습니다.
이력서 첫 화면에서 Kubernetes, AWS, Python, CI/CD, Terraform 중 실제로 사용한 기술을 확인해 보세요. 기술 이름만 남아 있다면 바로 뒤에 운영한 대상, 맡은 책임, 해결한 문제를 붙이세요.
그다음 관심 있는 공고의 기술 요구를 보면서 두 기술이 한 업무 흐름에서 이어졌는지 확인해 보세요. AWS와 Kubernetes를 함께 사용했다면 두 이름을 따로 적는 데서 끝내지 말고, 실제로 어떤 환경에서 배포와 운영을 맡았는지 프로젝트 설명에 보여주세요.
경력이 많아질수록 기술 이름보다 운영 범위와 판단을 앞에 두는 편이 좋습니다. 경력이 짧다면 연차 대신 배포 자동화, 점검 스크립트, 프로젝트 운영 경험을 앞에 둘 수 있습니다.
tailf는 로그인이 없고 잠금화면에는 한 줄만 보입니다. 쓰는 기술 두 개를 고르면 지난 30일 공고 수를 가입 없이 세어 줍니다.
다음 화의 주제는 매일 모이는 채용 데이터가 고르므로 특정 회사나 직무를 약속하지 않습니다. 그때도 공고에서 반복해서 보인 요구와 이력서에서 먼저 보여줄 경험을 함께 정리하겠습니다.
봐 줬으면 하는 회사가 있으면 댓글로 남겨 주세요.