코드보다 YAML 파일이 더 많다. 쿠버네티스 없으면 불안하고, 모든 것은 컨테이너로 해결된다.
인프라 구루(DEVOPS) 유형은 소프트웨어가 돌아가는 환경 자체를 코드로 다루는 개발자입니다. 이들에게 서버는 설정해두고 관리하는 것이 아니라, 코드로 정의하고 버전 관리하는 대상입니다. Terraform, Helm Chart, Ansible Playbook 같은 IaC(Infrastructure as Code) 도구를 자유자재로 다루며, 클라우드 콘솔에서 수동으로 클릭하는 것은 이들에게 기술 부채와 동의어입니다.
DEVOPS 유형은 애플리케이션이 배포되는 방식에 집착합니다. 로컬에서만 돌아가는 코드는 완성된 코드가 아닙니다. 스테이징, 프로덕션 환경 모두에서 동일하게 동작해야 하고, 장애 발생 시 자동으로 복구되어야 하며, 트래픽이 몰려도 자동으로 스케일 아웃되어야 합니다. 이 모든 것을 코드로 정의해두는 것이 이들의 일과입니다. 컨테이너 이미지 최적화, 멀티스테이지 빌드, Distroless 베이스 이미지 같은 개념에도 세심하게 신경 씁니다.
가끔은 단순한 개인 프로젝트에도 쿠버네티스 클러스터를 세팅하거나, 정적 웹사이트 배포에 복잡한 GitOps 파이프라인을 구축하는 오버엔지니어링을 하기도 합니다. '그냥 FTP로 올리면 되잖아요?'라는 말을 들으면 내적으로 고통을 느낍니다. 하지만 이들이 구축한 인프라는 팀 전체의 개발 경험을 완전히 바꿔놓습니다. 배포가 두렵지 않아지고, 장애 대응이 체계화되며, 개발 환경이 표준화됩니다.
DEVOPS 유형은 관찰 가능성(Observability)도 매우 중시합니다. Prometheus, Grafana, Loki, Jaeger 같은 모니터링 스택을 구성하고, 의미 있는 메트릭과 알림 규칙을 만듭니다. 장애가 발생하기 전에 이상 징후를 미리 감지하는 것이 이들의 목표입니다. SLO(서비스 수준 목표)를 정의하고, Error Budget을 관리하는 SRE적 사고방식을 자연스럽게 적용합니다.
"'내 로컬에서는 됩니다'는 더 이상 통하지 않아요. 도커로 환경을 통일하면 그 문장 자체가 사라집니다. 그게 제가 인프라에 집착하는 이유예요."
— DEVOPS 유형 개발자DEVOPS 유형이 처음 주목받기 시작한 건 애자일 개발이 확산되면서부터입니다. 개발 팀이 빠르게 코드를 작성하는 만큼 배포와 운영을 담당하는 파이프라인도 그 속도를 따라가야 했고, 이 간극을 메우는 역할이 바로 DEVOPS 유형입니다. CI/CD 파이프라인 구축, 블루-그린 배포, 카나리 릴리즈 같은 전략은 이들이 가장 자신 있는 영역입니다.
이들의 작업 환경을 보면 여러 개의 터미널 창, kubectl, terraform, helm 명령어들이 오가고, Slack에는 배포 알림 봇이 실시간으로 상태를 중계합니다. 팀원이 "배포 언제 돼요?"라고 물어볼 때쯤 이미 스테이징에 올라가 있습니다. PR 머지 → 자동 빌드 → 자동 테스트 → 자동 배포까지 이어지는 파이프라인을 완성했을 때의 성취감은 이들만이 이해합니다.
DEVOPS 유형의 약점은 가끔 지나친 자동화와 복잡한 인프라 구성으로 팀 전체가 따라오기 어려운 환경을 만들 수 있다는 점입니다. 본인은 kubectl 명령어를 자유자재로 쓰지만, 백엔드 개발자가 단순 로그 하나를 보려면 세 가지 도구를 익혀야 하는 상황이 생기기도 합니다. 문서화와 온보딩 가이드 작성에 시간을 투자하는 것이 DEVOPS 유형의 성장 포인트입니다.
커리어 측면에서 DEVOPS 유형은 수요가 가장 빠르게 성장하는 분야 중 하나에 위치해 있습니다. 클라우드 비용 최적화, 멀티 클라우드 전략, 제로 다운타임 배포, 서비스 메시(Istio, Linkerd) 운영 등 전문화할 수 있는 영역이 계속 확장되고 있습니다. AWS, GCP, Azure 각각의 자격증 취득이 커리어에 실질적인 도움이 되는 몇 안 되는 분야이기도 합니다.
DEVOPS 유형 개발자의 실제 하루를 따라가봅니다.
STRENGTHS
WEAKNESSES
Q. DEVOPS 유형은 개발도 잘 하나요?
백엔드나 프론트엔드 개발보다는 인프라, 자동화 스크립트, 파이프라인 코드에 특화되어 있습니다. Python, Bash, Go를 주로 쓰며, 애플리케이션 비즈니스 로직보다 운영 자동화 코드에 강점이 있습니다.
Q. DEVOPS와 SRE의 차이는 뭔가요?
DEVOPS는 개발과 운영의 협업 문화와 자동화에 초점을 두는 반면, SRE는 서비스 안정성 지표를 소프트웨어 엔지니어링으로 해결하는 데 집중합니다. 실무에서는 많이 겹치는 역할입니다.
Q. 쿠버네티스를 꼭 써야 하나요?
모든 서비스에 쿠버네티스가 필요한 건 아닙니다. 소규모 프로젝트라면 Docker Compose나 단순 PaaS가 더 적합할 수 있지만, 한번 쓰기 시작하면 그 강력함 때문에 계속 쓰게 됩니다.
💡 지금 바로 GitHub Actions로 작은 자동화부터 시작해보세요. PR 올릴 때마다 자동으로 린트와 테스트를 돌리는 것만으로도 팀의 코드 품질이 눈에 띄게 달라집니다.