DevOps·SRE 엔지니어 이력서 작성법 - 담당자는 다룬 도구보다 신뢰성과 배포가 어떻게 달라졌는지를 봅니다

여기서 말하는 DevOps·SRE 엔지니어는 서비스가 돌아가는 인프라와 배포 과정을 만들고 서비스가 멈추지 않게 지키는 엔지니어입니다. 이 직군에는 맡는 일의 비중이 조금씩 다른 직함이 여럿 있습니다. SRE는 서비스의 신뢰성 목표를 정하고 반복되는 운영 작업을 코드로 줄이는 일에 중점을 둡니다. 플랫폼 엔지니어는 사내 개발자가 쓰는 배포·인프라 환경을 하나의 제품처럼 만듭니다. 클라우드 엔지니어는 클라우드 인프라를 구성하고 운영하는 일이 중심이고, DevOps 엔지니어라는 직함은 주로 CI/CD와 인프라 자동화를 맡는 자리에 붙습니다. 하는 일이 많이 겹쳐 한 직군으로 묶이지만 아래에서 다루는 경험 가운데 무엇을 중요하게 보는지는 직함과 자리마다 다릅니다. 이 직무의 이력서는 AWS, Kubernetes, Terraform, ArgoCD, Prometheus 같은 도구 이름과 "CI/CD 파이프라인 구축", "Kubernetes 클러스터 운영", "서비스 안정적 운영" 같은 문장으로 채우기 쉽습니다. 도구 이름은 공고의 자격 요건과 맞춰 보는 데 필요합니다. 하지만 같은 도구를 쓴 지원자끼리는 이 문장으로 차이가 나지 않습니다. 이 직무는 일이 잘될수록 눈에 띄는 사건이 줄어든다는 점도 이력서를 쓰기 어렵게 만듭니다. 장애가 없었던 한 해와 배포가 매번 무사히 끝난 한 분기는 따로 기록해 두지 않기 쉽습니다. 그러면 이력서에는 "안정적으로 운영했다"는 한 줄만 남습니다. 담당자가 확인하려는 것은 그 안정이 어떤 숫자였고 지원자가 무엇을 바꿔서 만들었는지입니다.

신뢰성을 어떤 지표로 정했는지

"서비스를 안정적으로 운영했다"는 담당자가 검증할 방법이 없는 문장입니다. 일부 공고는 안정성을 지표로 정하고 관리하는 일을 업무로 적습니다. 크래프톤의 Sr. AI DevOps Engineer 공고는 SLI와 SLO, SLA를 직접 정의하는 일을 업무로 적었고, Google SRE Book의 SLI, SLO, Error Budget 개념을 실제 조직에 도입해 본 경험을 우대 사항으로 꼽았습니다. 무신사의 Cloud Engineer (Foundation Platform) 공고는 SLA/SLO 기반으로 서비스 신뢰성을 관리하는 일을 업무로 두었습니다. 토스의 두 SRE 공고는 Stability, Scalability, Availability, Latency 같은 지표를 고도화하거나 개선하는 일을 업무로 적었습니다. SLI는 서비스 상태를 재는 지표이고(예: 전체 요청 중 성공한 요청의 비율), SLO는 일정 기간(예: 30일) 동안 그 지표가 지켜야 할 목표치입니다. 이력서에는 어떤 서비스에 어떤 SLI를 골랐는지, 목표를 얼마로 정했는지, 그 뒤 실제 수치가 어떻게 달라졌는지를 적습니다. 목표를 정한 근거도 함께 적으면 좋습니다. 결제처럼 실패가 곧바로 손해가 되는 서비스와 사내 관리 도구는 같은 목표를 둘 이유가 없기 때문입니다. 오류 예산(Error Budget)은 SLO가 허용하는 실패의 양입니다. 보통 예산을 다 쓰면 새 기능 배포를 멈추고 안정성 작업부터 하는 규칙을 함께 둡니다. 이런 규칙을 개발팀과 합의해 운영해 봤다면 합의 과정과 실제로 배포를 멈춘 사례를 함께 적습니다. SLI를 재는 일은 혼자 할 수 있지만, 목표와 배포를 멈추는 규칙은 개발팀, 제품팀과 합의해야 하기 때문입니다. SLO를 정식으로 운영하지 않는 회사에 있었다면 다른 숫자를 쓸 수 있습니다. 월간 가용성, 장애 건수, 장애를 알아채기까지 걸린 시간, 평균 복구 시간(MTTR)이 그런 숫자입니다. 맡은 기간의 처음과 끝을 나란히 적으면 "안정적으로 운영했다"가 검증할 수 있는 문장이 됩니다.

배포가 얼마나 빠르고 안전해졌는지

DevOps 엔지니어가 만드는 것 가운데 상당 부분은 사내 개발자가 쓰는 환경이고, 배포 파이프라인이 대표적입니다. 그래서 파이프라인을 만들었다는 사실보다 그 파이프라인을 쓰는 개발팀의 배포가 어떻게 달라졌는지가 중요합니다. 우아한형제들의 플랫폼엔지니어링(배포시스템) 공고는 배달의민족 전사 서비스가 매일 수백, 수천 번 배포될 수 있도록 배포 플랫폼을 개발하고 운영하는 자리입니다. 수백 개 이상의 마이크로서비스가 쓰는 표준 배포 파이프라인을 플랫폼화하고 개발자 경험을 개선하는 일, 블루/그린·카나리 같은 안전한 배포 전략을 설계하는 일이 업무에 있습니다. 페이타랩의 DevOps(SRE) Engineer 공고는 CI/CD 파이프라인을 개선해 개발자가 배포에 쓰는 시간과 부담을 줄이는 일을 업무로 적었습니다. 카카오뱅크의 DevOps 엔지니어 공고는 CI/CD 파이프라인과 애플리케이션 모니터링 시스템을 연동해 배포 전략을 구현해 본 경험을 우대했습니다. 배포를 바꾼 경험은 DORA 지표로 적으면 비교하기 쉽습니다. DORA 지표로 흔히 꼽는 것은 배포 빈도, 코드 변경이 서비스에 반영되기까지 걸리는 시간, 배포가 장애나 롤백으로 이어진 비율, 배포로 생긴 장애에서 복구하기까지 걸리는 시간 네 가지입니다. 여기에 빌드 시간과 롤백에 걸리는 시간을 더할 수 있습니다. 파이프라인을 쓰는 팀이나 서비스가 몇 개였는지도 함께 적어야 규모가 보입니다. 배포 전략을 바꿨다면 무엇을 기준으로 진행하거나 되돌리게 했는지를 씁니다. 카나리 배포를 도입했다는 문장보다, 새 버전을 트래픽 몇 %에 먼저 적용하고 어떤 지표가 기준을 넘으면 자동으로 되돌리게 했는지를 적은 문장이 지원자의 설계를 보여 줍니다.

콘솔에서 하던 작업을 얼마나 코드로 옮겼는지

인프라를 코드로 관리하는 IaC도 이 직무 공고에 자주 나옵니다. 기업 채용 분석의 DevOps·SRE 공고 가운데 절반이 IaC 경험을 자격 요건이나 우대 사항, 업무에 적었습니다(2026년 10월 분석 기준). 안랩의 [신입/경력] DevOps 엔지니어 공고는 Terraform·Ansible 같은 IaC 도구로 인프라를 구축하고 관리한 경험을 XDR 클라우드 분야의 자격 요건으로 요구했습니다. 무신사의 Foundation Platform 공고는 Terraform과 Terragrunt로 모든 인프라를 코드로 관리하고 코드 리뷰와 Git 기반 워크플로로 변경을 관리하는 일을 업무로 적었습니다. NHN의 인프라 데브옵스 엔지니어 공고는 IaC 기반으로 인프라 형상을 관리하고 신규 리전을 구축하는 일을 주요 업무로 밝혔습니다. Terraform을 써 봤다는 문장만으로는 어디까지 코드로 옮겼는지 알 수 없습니다. 전체 인프라 가운데 얼마를 코드로 옮겼는지, 새 환경(개발·스테이징·신규 리전)을 만드는 데 걸리는 시간이 어떻게 달라졌는지를 적습니다. 인프라 변경이 코드 리뷰를 거치도록 했는지, 누군가 콘솔에서 바꾼 설정과 코드가 어긋나는 문제를 어떻게 막았는지도 이 경험의 깊이를 보여 줍니다. 권한과 비밀 정보도 코드로 관리하는 대상입니다. 무신사 공고는 IAM 권한 관리와 방화벽 설정을 주요 업무로 꼽았고, 우아한형제들 공고는 전사 컨테이너 레지스트리의 보안 취약점 대응을 업무로 두었습니다. 클라우드 계정과 클러스터의 권한을 코드로 정리했다면 그 범위를 적습니다. 비밀번호나 API 키를 Vault나 AWS Secrets Manager 같은 전용 저장소로 옮긴 일, 배포 파이프라인에 이미지 취약점 검사를 넣은 일도 어디까지 적용했는지를 함께 적습니다. 반복 운영 업무를 자동화한 경험도 같은 방식으로 적습니다. 데이원컴퍼니의 클라우드 인프라 운영 공고는 월간 점검과 배포 체크리스트 같은 반복 업무를 스크립트와 AI 도구로 자동화하는 일을 업무로 소개했습니다. 자동화한 업무가 무엇이었는지, 그 일에 쓰던 시간이 한 주나 한 달에 얼마에서 얼마로 줄었는지를 적으면 됩니다. AI 도구로 운영을 자동화한 경험을 묻는 공고도 있습니다. NHN 공고는 AI를 활용한 시스템 운영과 개발 경험을 자격 요건으로 들었고, 크래프톤 공고는 Claude Code CLI나 Codex CLI 같은 AI 코딩 에이전트로 자동화한 경험을 우대합니다. 이런 경험을 적을 때는 AI에 맡긴 일과 함께 AI가 낸 결과를 배포 전에 어떻게 검증했는지까지 적어야 운영을 책임진 사람의 경험이 됩니다.

장애를 다루는 체계를 무엇으로 바꿨는지

장애 한 건의 원인과 재발 방지 조치를 적는 방법은 백엔드 개발자 이력서 작성법에서 볼 수 있습니다. DevOps·SRE 이력서에서는 한 단계 더 나아가 장애를 알아채고 대응하고 되돌아보는 체계를 어떻게 바꿨는지가 중요합니다. 크래프톤 공고는 온콜 장애 대응 경험과 사후 분석으로 개선한 경험을 자격 요건으로 요구하고, Runbook 자동 실행 체계를 구축하는 일을 업무로 적었습니다. 토스의 Server Developer (Commerce - SRE) 공고는 장애 때 비상 대응과 Post-mortem을 주도하고 재발 방지 시스템을 마련하는 일을 업무로 적었습니다. 비상교육의 DevOps/AI Platform 엔지니어 공고는 알림 규칙 설정과 대시보드 구성, 인시던트 기록과 재발 방지책 수립 참여를 업무에 두었습니다. 이 체계를 바꾼 경험은 이런 숫자로 적을 수 있습니다.

• 하루 알림 건수와 그중 실제로 조치가 필요했던 알림의 비율
• 전체 장애 가운데 사용자 문의보다 먼저 발견한 장애의 비율과 알아채기까지 걸린 시간
• 포스트모템을 몇 건 썼고 거기서 나온 개선 조치를 몇 건 끝냈는지
• 손으로 하던 대응 절차 가운데 자동으로 실행되게 바꾼 범위
• 온콜 인원과 순번 방식, 한 사람이 한 달에 받는 호출 수

알림 정리는 특히 적을 만한 경험입니다. 알림이 너무 많으면 온콜 엔지니어가 알림을 무시하게 되고 그러다 진짜 장애를 늦게 알아채게 됩니다. 무엇을 기준으로 알림을 줄였는지와 줄인 뒤 놓친 장애가 있었는지를 함께 적으면 판단의 근거가 보입니다. 장애 원인을 찾는 데 쓰는 관측 체계를 직접 만들었다면 그것도 따로 적습니다. 크래프톤 공고는 Prometheus, Grafana, ELK, OpenTelemetry 가운데 여러 개를 구축하고 운영해 본 경험을 요구했고, 비상교육 공고는 로그 수집과 분석 파이프라인 운영을 업무로 두었습니다. 지표와 로그, 분산 추적을 붙인 서비스가 몇 개였는지, 그 뒤 장애 원인을 찾기까지 걸린 시간이 어떻게 달라졌는지를 적습니다.

비용과 용량을 숫자로 관리했는지

클라우드 비용은 이 직무에서 금액으로 결과가 남는 몇 안 되는 영역입니다. 페이타랩 공고는 AWS 리소스의 사용량과 비용 지표를 모니터링하고 Terraform·Helm으로 인프라를 코드화해 불필요한 비용을 줄이는 일을 업무로 적었습니다. 비상교육 공고는 비용 모니터링과 리소스 최적화 경험을 우대합니다. 비용을 줄였다면 월 비용이 얼마에서 얼마가 됐는지와 무엇을 바꿨는지를 씁니다. 사용량에 비해 크게 잡힌 인스턴스 크기 조정, 예약 인스턴스나 Savings Plans 같은 약정 할인, 스팟 인스턴스 활용, 오토스케일링 설정, 쓰지 않는 리소스 정리가 흔한 방법입니다. 그 사이 트래픽이 늘거나 줄었다면 요청 한 건당 비용을 함께 적어야 절감 폭을 제대로 비교할 수 있습니다. 그리고 비용을 줄이는 동안 응답 시간과 가용성이 그대로였다는 점도 적습니다. 서비스를 느리게 만들어 얻은 절감은 담당자에게 좋은 결정으로 보이지 않습니다. 용량 관리도 비용과 함께 다루는 일입니다. 무신사의 Foundation Platform 공고는 대형 이벤트와 시즌성 트래픽 급증에 대비해 사전 프로비저닝을 자동화하고 Karpenter, keda 기반의 자원 관리 체계를 만드는 일을 업무로 두었고, 트래픽 급증 환경에서 안정적으로 운영해 본 경험을 자격 요건으로 요구했습니다. 용량을 미리 늘려 둔 경험은 다음 절의 행사 대비처럼 예상 트래픽과 실제 최대치, 그때 늘려 둔 자원을 함께 적습니다.

장애가 나지 않은 일도 적을 수 있습니다

DevOps·SRE 엔지니어가 한 일 가운데 가장 이력서에 적기 어려운 것은 아무 문제 없이 끝난 일입니다. 큰 할인 행사를 장애 없이 넘긴 일이나 Kubernetes 클러스터의 버전을 서비스 중단 없이 올린 일은 끝나고 나면 "무사히 끝났다"는 사실만 남습니다. 이런 일은 결과만 적으면 운이 좋았던 경우와 구분되지 않습니다. 그래서 준비한 과정을 함께 적습니다. 행사라면 예상 트래픽을 어떻게 추정했는지, 부하 테스트에서 어떤 부분이 먼저 한계를 넘었는지, 그 부분을 어떻게 고쳤고 자원을 언제 얼마나 늘려 두었는지를 씁니다. 결과는 실제 최대 트래픽과 그때의 오류율로 남깁니다. 클러스터 업그레이드나 이전이라면 중단 없이 진행하기 위해 어떤 순서를 정했는지, 문제가 생기면 어디까지 되돌릴 수 있게 준비했는지, 몇 개 클러스터와 서비스를 옮겼는지를 씁니다. 이런 일을 업무나 우대 사항으로 적은 공고도 있습니다. NHN 공고는 무중단 운영 절차 설계를 주요 업무에 포함했고, 비상교육 공고는 무중단 배포 환경을 구축하고 운영해 본 경험을 우대합니다.

자리에 따라 요구하는 역량이 다릅니다

같은 DevOps·SRE 직무로 묶여도 공고마다 무게를 두는 역량이 다릅니다. 기업 채용 분석의 DevOps·SRE 공고를 보면(2026년 10월 분석 기준) 서비스나 플랫폼을 직접 개발하는 자리, 클라우드 인프라 운영이 중심인 자리, 회사가 자체 클라우드 플랫폼을 운영하는 자리가 함께 있습니다. 직접 개발하는 자리는 다시 서버 애플리케이션을 개발하는 자리와 운영 도구를 개발하는 자리로 나뉩니다. 토스의 두 SRE 공고(토스뱅크 Site Reliability Engineer, Server Developer (Commerce - SRE))는 Java/Kotlin과 Spring Framework 개발 경험을 찾습니다. 우아한형제들의 배포시스템 공고도 Java/Kotlin으로 Spring Framework 기반 애플리케이션을 개발해 본 경험을 자격 요건으로 적었습니다. 이런 공고는 서버 애플리케이션을 개발하는 역량을 보므로, 운영 경험과 별도로 Java/Kotlin 서비스를 개발하고 운영한 경력을 적어야 합니다. 카카오뱅크의 DevOps 엔지니어 공고는 표준 CI/CD 파이프라인과 CLI 도구를 GitLab CI와 Go로 개발하는 일을 업무로 두었고, 하나의 서비스를 1년 이상 개발하고 운영해 본 경험을 요구했습니다. 카카오뱅크의 쿠버네티스 엔지니어 공고는 Kubernetes Operator를 개발해 본 경험을 우대합니다. 이런 공고라면 직접 개발한 운영 도구가 무엇을 하는지, 어떤 언어로 만들었는지, 몇 개 팀이 쓰는지를 적습니다. 운영이 중심인 자리는 작은 조직일수록 범위가 넓어집니다. 데이원컴퍼니 공고의 업무에는 GCP 인프라 운영과 함께 운영 DB에 반영되는 DDL/DML 쿼리의 검토와 실행, 계정 권한 관리, ISMS 감사 대응 지원까지 들어 있습니다. 이런 자리에 지원한다면 DB 변경이나 감사 대응을 겸한 경험도 함께 적습니다. NHN 공고는 OpenStack 기반의 NHN Cloud IaaS를 배포하고 운영하는 자리입니다. 회사가 직접 클라우드를 만들어 고객에게 파는 곳이라, 퍼블릭 클라우드를 쓰는 쪽이 아니라 클라우드를 제공하는 쪽의 운영 경험을 봅니다. 이 공고는 OpenStack이나 KVM 같은 가상화 환경을 이해하고 운영해 본 경험을 자격 요건으로 요구했습니다. 이런 자리라면 가상화 계층이나 클라우드 서비스 자체를 운영한 경험을 따로 적습니다.

DevOps·SRE와 가까운 다른 직무도 있습니다

DevOps·SRE와 함께 인프라를 맡지만 다른 직무에 가까운 공고도 있습니다. 펄어비스의 네트워크 엔지니어 공고는 L2·L3·L4 네트워크 장비와 방화벽·VPN 같은 보안 장비를 구축하고 운영한 경험을 요구하고, L3에서는 BGP를 필수로 적었습니다. DBA 공고로는 하이브 DRIMAGE 공고가 SQL Server와 MySQL 운영 경험을 합쳐 3년 이상을 요구했고 펄어비스 공고는 T-SQL과 SQL Server 운영 역량을 요구했습니다. 토스의 Systems Engineer (GPU) 공고는 GPU 클러스터를 베어메탈부터 구축하고 전력, 냉각, 랙 같은 환경을 고려해 증설하는 시스템 엔지니어 자리입니다. 고객사의 인프라를 설계하는 자리도 있습니다. 메가존클라우드의 AWS Solutions Architect 공고는 온프레미스와 클라우드를 함께 쓰는 하이브리드 인프라 설계, 신규 서비스의 PoC, 클라우드 마이그레이션을 업무로 두었습니다. 삼일PwC의 System Engineer 공고는 고객사 IT·보안·운영 조직과 기술 논의를 하고 설계 대안을 제시해 이해관계자를 설득하는 일을 담당 업무로 밝혔습니다. 보안이나 프로그램 관리의 비중이 큰 자리도 있습니다. 쿠팡의 Senior DevOps Engineer (SPIR/OC) 공고는 보안·프라이버시 서비스를 운영하는 자리로, 5년 이상의 정보 보안 경험이나 사이버보안에 관심을 두고 쌓은 5년 이상의 DevOps 경험을 요구합니다. 무신사의 Technical Program Manager (Infra) 공고는 여러 조직이 함께하는 인프라 프로그램을 이끄는 자리로, 기술 직무를 포함한 7년 이상의 경력과 5년 이상의 기술 프로그램 또는 프로젝트 관리 경험을 요구합니다. 이런 공고에 지원한다면 DevOps·SRE 경험과 별도로 그 공고가 요구하는 전문 영역의 경험을 나눠 적습니다. 네트워크 장비를 다뤘다면 장비 종류와 라우팅 프로토콜을, 데이터베이스를 운영했다면 DBMS 종류와 운영 기간을 적어야 요건과 맞춰 볼 수 있습니다. 고객사 인프라를 설계하는 자리라면 설계한 아키텍처와 함께 고객이 무엇을 결정하도록 도왔는지를 씁니다. 보안 비중이 큰 자리라면 다룬 보안 영역과 기간을, 프로그램 관리 자리라면 이끈 프로그램의 규모와 참여한 조직 수를 적습니다.

같은 경력을 이렇게 적으면

• 약한 문장: Kubernetes 기반 CI/CD 파이프라인 구축

• 강한 문장: 수동 승인 뒤 스크립트로 배포하던 서비스 12개를 GitLab CI와 ArgoCD 기반 GitOps로 옮기고 Argo Rollouts로 카나리 배포를 붙였습니다. 서비스 하나를 배포하는 데 걸리는 시간이 평균 40분에서 8분으로 줄었고, 팀 전체의 배포 횟수는 주 15회에서 주 60회로 늘었습니다. 새 버전을 트래픽 10%에 먼저 적용하고 5xx 오류 비율이 기준을 넘으면 이전 버전으로 자동으로 돌아가게 해 롤백 시간을 20분에서 2분 이내로 줄였습니다.

• 약한 문장: 서비스 모니터링 및 장애 대응

• 강한 문장: 결제 API에 30일 기준 성공 응답 비율 99.9%를 SLO로 정하고, 서버 지표마다 걸려 있던 알림을 오류 예산 소진 속도(burn rate) 기준 알림으로 바꿨습니다. 온콜 담당자를 호출하는 알림은 하루 120건에서 주 3~4건으로 줄었고, 나머지는 업무 시간에 처리하는 티켓으로 돌렸습니다. 큰 장애를 알아채기까지 걸린 시간은 평균 15분에서 3분이 됐습니다.

• 약한 문장: Terraform 기반 인프라 관리

• 강한 문장: 콘솔에서 손으로 만들던 AWS 리소스의 약 80%를 Terraform 모듈로 옮겼고, 코드로 옮긴 리소스는 모든 변경이 코드 리뷰를 거치게 했습니다. 새 스테이징 환경을 만드는 데 걸리는 시간이 이틀에서 40분으로 줄었습니다. 콘솔에서 바뀐 설정을 매일 찾아 알리는 점검도 붙였습니다.

• 약한 문장: AWS 비용 최적화

• 강한 문장: 월 4,200만 원이던 AWS 비용을 서비스별 사용량 기준으로 분석했습니다. 과하게 잡힌 인스턴스 크기를 줄였고, 배치 작업은 스팟 인스턴스로 옮겼습니다. 6개월 동안 월 비용이 29% 줄었고, 같은 기간 트래픽이 15% 늘어 요청 한 건당 비용은 38% 줄었습니다. p95 응답 시간과 가용성 목표는 그대로 지켰습니다.

• 약한 문장: 대규모 트래픽 이벤트 대응

• 강한 문장: 연말 할인 행사 트래픽을 평소의 4배로 잡고 행사 2주 전에 부하 테스트를 했습니다. 데이터베이스 연결 수가 가장 먼저 한계를 넘는다는 것을 찾아, 파드가 늘어도 연결 수가 DB 한도를 넘지 않도록 파드당 연결 풀 크기를 줄이고 RDS Proxy를 거치게 했습니다. 행사 시간대에 맞춰 노드와 최소 파드 수를 미리 늘려 두는 예약 작업도 만들었습니다. 행사 당일 최대 초당 요청 1만 8천 건을 오류율 0.1% 아래로 처리했습니다.

강한 문장에는 무엇을 바꿨는지, 그 결과 배포와 장애, 비용이 어떻게 달라졌는지, 그리고 지원자가 정한 기준이 들어 있습니다. 같은 도구를 썼더라도 강한 문장에서는 지원자가 서비스의 신뢰성을 책임지고 바꿔 왔다는 점이 드러납니다.

실서비스를 운영해 본 적이 없다면

신입이거나 인프라가 매니지드 서비스 몇 개로 끝나는 회사에 있었다면 위의 숫자 가운데 상당수가 없을 수 있습니다. 트래픽이 작으면 용량 문제가 생기지 않고, 장애가 드물면 대응 체계를 만들 기회도 적습니다. 제목에 [신입/경력]을 단 안랩의 DevOps 엔지니어 공고는 XDR 클라우드 분야의 자격 요건으로 Kubernetes 환경에서 서비스를 배포하고 운영한 경험, IaC 도구로 인프라를 구축하고 관리한 경험, CI/CD 파이프라인을 구축하거나 운영한 경험을 적었습니다. 세 가지 모두 개인 프로젝트로도 만들 수 있는 경험입니다. 이력서에는 아래 같은 기록을 적을 수 있습니다.

• 작은 클러스터를 GitOps로 구성하고 왜 그렇게 구성했는지 설계 문서와 함께 공개한 기록
• Terraform으로 환경 전체를 지웠다가 다시 만드는 데 걸리는 시간
• 파드나 노드를 일부러 중단시켰을 때 예상과 달리 깨진 부분과 그것을 고친 설정
• 부하 테스트로 어느 정도의 요청에서 무엇이 먼저 한계를 넘는지 찾은 결과
• 직접 구성한 모니터링과 알림, 그리고 알림을 보내는 기준과 그 기준을 정한 이유
• 인프라 오픈소스 도구에 낸 기여

회사에 있으면서 만들 수 있는 경험도 있습니다. 서비스에 SLO를 처음 정하고 장애 뒤 포스트모템을 쓰는 습관을 들이는 일, 콘솔 작업을 IaC로 옮기는 일, 배포 빈도와 복구 시간을 재기 시작하는 일, 클라우드 비용을 정리하는 일은 조직이 작을수록 한 사람이 주도하기 쉽습니다. 반대로 실서비스 온콜에서 내린 판단, 규모 있는 비용 절감, 여러 팀이 합의한 신뢰성 목표는 개인 환경에서 만들 수 없습니다. 이런 경험이 없다면 개인 프로젝트를 부풀려 채우기보다 직접 만든 숫자를 정확하게 적는 편이 낫습니다.

운영 숫자는 회사 도구 안에 남아 있습니다

이 직무의 숫자는 대부분 회사 도구 안에 있습니다. 가용성과 알림 건수는 모니터링 화면에, 배포 횟수와 롤백 기록은 배포 시스템에, 비용은 클라우드 청구서에 남습니다. 포스트모템 문서는 사내 위키에 있습니다. 회사를 옮기면 이 도구에 다시 들어가기 어렵습니다. 그래서 이력서를 쓸 때쯤이면 사용한 도구 이름과 "안정적으로 운영했다"는 기억만 남아 이력서에도 도구 이름과 "안정적으로 운영했다"는 표현만 쓰게 됩니다. 배포 개선이나 비용 절감 작업이 끝난 날, 또는 포스트모템을 하나 마친 날 작업 전후의 숫자를 개인 기록으로 남겨 두는 것이 좋습니다. 무엇을 바꿨는지, 배포 시간이나 알림 건수, 비용이 얼마에서 얼마가 됐는지, 어떤 기준을 정했는지 정도를 몇 줄로 적으면 됩니다. 회사의 설정이나 내부 구성은 빼고 결과 숫자와 판단만 남깁니다. 회사 밖에 적어도 되는 숫자인지는 보안 규정에서 먼저 확인합니다. GridResume 커리어 기록에 이렇게 남겨 두면 이력서를 쓸 때 신뢰성과 배포에 관한 숫자가 들어간 문장을 바로 만들 수 있습니다.

정리하면

DevOps·SRE 엔지니어 이력서에 들어가야 할 것은 다섯 가지입니다.

• 서비스의 신뢰성을 어떤 지표와 목표로 정했고 실제 수치가 어떻게 달라졌는지
• 개발팀의 배포가 얼마나 빨라지고 안전해졌는지
• 인프라와 권한, 반복 업무를 얼마나 코드로 옮기고 자동화했는지
• 장애를 알아채고 대응하고 되돌아보는 체계를 무엇으로 바꿨는지
• 비용과 용량을 어떤 숫자로 관리했는지

도구 이름만 적으면 이력서는 기술 목록에 그칩니다. 그 도구로 바꾼 숫자와 지원자가 정한 기준을 함께 적어야 DevOps·SRE 엔지니어의 경력으로 보입니다.