DevOps는 직군일까요, 문화일까요? (개발자가 알아야 할 진짜 DevOps)

1. "제 컴퓨터에서는 잘 되는데요?"의 종말

운영팀은 화가 납니다. "코드가 엉망이라 그렇잖아요!"

이것이 바로 '혼란의 벽'(Wall of Confusion)입니다. 개발자는 '변화(Change)'를 원합니다. 새로운 기능을 빨리 배포하고 싶어 하죠. 반면 운영팀은 '안정(Stability)'을 원합니다. 시스템이 뻗지 않기를 바라니까 변화를 싫어하죠. 이 상충하는 목표 때문에 두 팀은 항상 싸웠습니다. DevOps는 이 벽을 부수기 위해 등장했습니다. 단순히 두 팀을 합치는 게 아니라, "개발자가 운영까지 생각하고, 운영자가 개발처럼 일하는" 문화를 만드는 것입니다.

---

2. DevOps의 3가지 원칙 (The Three Ways)

DevOps의 교과서라 불리는 책 The Phoenix Project에서는 DevOps를 지탱하는 세 가지 기둥을 소개합니다.

2.1. 첫 번째 길 - 흐름 (Flow) - 개발에서 운영으로

아이디어가 코드로, 코드가 빌드로, 빌드가 배포로, 배포가 실제 고객에게 닿는 속도를 올리는 것입니다.

• 지속적 통합(CI): 코드를 하루에 100번이라도 메인 브랜치에 합칩니다.
• 지속적 배포(CD): 합쳐진 코드는 언제든지 배포 가능한 상태여야 합니다.
• 병목 제거: 수동 승인 절차, 수동 테스트 같은 장애물을 자동화로 걷어냅니다.

2.2. 두 번째 길 - 피드백 (Feedback) - 운영에서 개발로

운영 환경에서 일어나는 일을 개발자가 실시간으로 알 수 있어야 합니다.

• "새 배포 후에 에러율이 2% 올랐어요." -> 즉시 롤백하거나 수정.
• "A 기능은 아무도 안 써요." -> 개발 중단.
• 모니터링 & 로깅: ELK Stack, Prometheus 같은 도구로 시스템의 맥박을 잼.

2.3. 세 번째 길 - 지속적 학습과 실험 (Continuous Learning)

실패를 두려워하지 않는 문화를 만드는 것입니다.

• "서버 터졌네? 누구 잘못이야?" (문책 문화) -> X
• "서버 터졌네? 왜 프로세스가 이걸 못 막았지? 포스트모템(Post-mortem) 써서 고치자." (비난 없는 문화) -> O
• 카오스 엔지니어링: 일부러 운영 서버의 전원을 뽑아보며 회복력을 테스트합니다. (Netflix의 Chaos Monkey)

---

3. 도구(Tools)보다 문화(Culture)다

많은 기업이 흔히 저지르는 실수가 있습니다. "우리도 DevOps 하자! Jenkins 깔고, Docker 쓰고, Kubernetes 도입하면 되지?" 이것은 "도구 중심의 접근"이며, 실패할 확률이 매우 높습니다.

아무리 좋은 도구를 써도, 개발자가 "배포는 운영팀이 알아서 하겠지"라고 생각하거나, 운영팀이 "개발팀 코드는 믿을 수 없어"라며 결재 서류를 3단계로 만들면 아무 소용이 없습니다. 진정한 DevOps는 "You Build It, You Run It (네가 만든 건 네가 운영해라)"라는 책임감을 공유하는 것입니다. 아마존의 CTO 버너 보겔스(Werner Vogels)가 한 이 말은 DevOps의 핵심을 꿰뚫습니다. 새벽 3시에 장애 알림을 받고 깨어나는 고통을 겪어본 개발자만이 "장애가 안 나는 코드"를 짤 수 있기 때문입니다.

흔한 DevOps 안티 패턴 (Anti-patterns)

1. DevOps 팀 신설: 기존 개발팀, 운영팀은 그대로 두고 그 사이에 'DevOps 팀'을 또 만듭니다. 이제 벽이 2개가 되었습니다. (개발 -> DevOps -> 운영)
2. 도구 집착: 문화는 그대로인데 툴만 비싼 걸 씁니다. "자동화된 쓰레기 생산 라인"이 될 뿐입니다.
3. DevOps 엔지니어 채용: "서버 관리자" 구인 공고의 이름만 "DevOps 엔지니어"로 바꿔서 올립니다. Jenkins 할 줄 아는 시스템 관리자를 뽑는다고 DevOps가 되지 않습니다.

실패 사례 연구 (Case Study) - 툴은 샀지만, 문화는 못 샀다

A사는 DevOps 전환을 선언하며 비싼 CI/CD 툴을 도입했습니다. 배포 시간은 1시간에서 5분으로 줄었죠. 하지만 장애가 나면 여전히 서로를 비난했습니다.

• 운영팀: "개발팀이 에러 나는 코드 안 고치고 그냥 배포해버려요!"
• 개발팀: "운영팀이 서버 권한을 안 줘서 로그를 못 보는데 어떻게 고쳐요?" 결국 도구는 빨라졌지만, 조직은 더 싸늘해졌습니다. "배포가 쉬워지니까 쓰레기 코드도 더 빨리 배포된다"는 비아냥만 남았죠. 문화적인 합의(개발자가 운영 로그를 볼 수 있는 권한, 운영자가 개발 회의에 참석 등) 없이는 도구는 무용지물입니다.

---

4. 인프라를 코드로 (IaC: Infrastructure as Code)

과거에는 서버 한 대를 세팅하려면 운영자가 SSH로 접속해서 apt-get install nginx, vi /etc/nginx.conf... 이렇게 수동으로 명령어를 쳤습니다. 이걸 100대 서버에 똑같이 할 수 있을까요? 사람이니까 실수합니다. "아, 3번 서버에는 Java 버전을 다르게 깔았네?" -> 설정 드리프트(Configuration Drift) 발생.

이제는 인프라를 코드(Code)로 관리합니다.

• Terraform: "AWS EC2 t3.micro 3개, 로드밸런서 1개 만들어줘."
• Ansible: "모든 서버에 Nginx 1.18 깔고 설정 파일 복사해."

이렇게 코드로 작성해서 깃(Git)에 올리면 다음과 같은 이점이 생깁니다.

1. 버전 관리: 인프라 변경 이력이 다 남습니다. "누가 방화벽 열었어?" -> git blame으로 확인 가능.
2. 재현 가능성: 미국 리전에 만든 서버 설정을 그대로 복사해서 한국 리전에 똑같이 만들 수 있습니다.
3. 자동화: 클릭질(ClickOps)을 할 필요가 없습니다. 엔터 한 번이면 구축 끝.

---

5. 마무리 - 자동화된 신뢰

DevOps는 결국 "신뢰를 자동화하는 과정"입니다. 테스트 코드가 촘촘하게 짜여 있어서 "코드 수정해도 사이드 이펙트 안 생겨"라는 신뢰가 있어야 안심하고 배포할 수 있습니다. 모니터링이 확실해서 "장애 나면 1분 안에 알람 와"라는 신뢰가 있어야 밤에 잠을 잘 수 있습니다.

자동화할 수 있는 건 다 자동화하세요. 그리고 남은 에너지를 "어떻게 하면 우리 서비스가 고객에게 더 사랑받을까?"를 고민하는 데 쓰세요. 그것이 DevOps가 추구하는 가치입니다.

---

---