솔직히 말해봅시다. 지난 20년간 우리가 외쳤던 DevOps는 성공했나요?
실리콘밸리에서 15년을 구르면서 Staff 직함 달 때까지, 제가 본 건 '문화의 승리'가 아니라 '고통의 총량 보존'이었습니다. 개발팀과 운영팀의 벽을 허물자고 시작했지만, 결국 남은 건 인프라까지 떠안게 된 개발자의 번아웃 아니면, YAML 파일만 하루 종일 쳐다보는 SRE의 고립뿐이었으니까요.
최근 Honeycomb의 Charity Majors가 쓴 글을 읽으며 무릎을 탁 쳤습니다. "DevOps는 딱 하나의 목표(One Job)가 있었는데, 그걸 실패했다"는 겁니다. 뼈아픈 지적이지만, 이걸 인정해야 우리도 살고 시스템도 삽니다. 오늘은 그 실패의 원인을 분석하고, 우리가 어떻게 해야 PagerDuty 알람 없이 퇴근할 수 있을지 이야기해 보려 합니다.
1. DevOps의 유일한 목표: '단일 피드백 루프'의 실패
DevOps 운동의 본질은 거창한 툴체인이나 화려한 CI/CD 파이프라인이 아닙니다. 핵심은 딱 하나였습니다.
개발자(Dev)와 프로덕션(Prod)을 연결하는 단일 피드백 루프를 만드는 것.
내가 짠 코드가 실제 사용자에게 닿았을 때 어떤 일이 벌어지는지, 개발자가 실시간으로 느끼게 하는 것. 이게 목표였습니다. 하지만 현실은 어떤가요? 우리는 여전히 두 개의 단절된 세계에 살고 있습니다.
실패의 원인은 엔지니어의 게으름 때문이 아닙니다. 도구(Tool)가 후졌기 때문입니다. 지금까지의 도구들은 비즈니스 로직 짜기도 바쁜 개발자들에게 인프라의 복잡성을 너무 날것 그대로 노출했습니다. 그러니 개발자는 프로덕션을 멀리하고, 운영은 방어적으로 변할 수밖에 없었죠.
2. 우리가 갇혀 있는 '가짜 루프' (The Dev Loop)
대부분의 개발자가 하루를 보내는 루틴을 봅시다. 여러분이 Cursor나 Claude 같은 AI 코딩 툴을 쓰든, Vim을 쓰든 본질은 같습니다.
- Build (만들고)
- Test (테스트 돌리고)
- Learn (결과 확인하고)
이 사이클을 무한 반복하다가, 초록색 불(Pass)이 들어오면 머지(Merge)합니다. 그리고 "내 할 일은 끝났다"며 퇴근하죠.
문제는 여기서 얻는 '배움(Learn)'이 반쪽짜리라는 겁니다. 테스트 통과는 그저 "내 로직이 내 컴퓨터(혹은 스테이징)에서는 안 터진다"는 사실만 알려줍니다. 비즈니스 가치가 생성되는 시점은 코드가 머지될 때가 아니라, 배포되어 사용자가 클릭하는 순간입니다.
하지만 우리는 배포 버튼을 누르는 순간 눈을 감아버립니다. 그 뒤는 '운영팀의 영역'이라며 선을 긋죠.
3. 고통받는 '진짜 루프' (The Ops Loop)
반면, 저 같은 SRE나 플랫폼 엔지니어들이 겪는 루프는 전혀 다릅니다. 우리는 골키퍼입니다.
- Alert (호출받고)
- Triage (원인 파악하고)
- Fix (땜질하고)
이 루프는 항상 반응적(Reactive)입니다. 새벽 2시에 장애가 터지면, 우리는 이게 어제 배포된 김 대리의 코드 때문인지, 갑자기 몰린 트래픽 때문인지, 아니면 AWS 리전 장애인지 모르는 상태에서 로그를 뒤집니다.
개발자는 "테스트 다 통과했는데 왜요?"라고 묻고, 운영자는 "트래픽 패턴이 이상해요"라고 답합니다. 서로 다른 언어를 쓰는 겁니다. 이 지연(Latency)과 단절이 바로 비효율의 핵심이자, 우리가 주말에도 슬랙을 확인해야 하는 이유입니다.
4. AI 시대의 새로운 위협: 'Code Slop'
여기에 AI가 기름을 부었습니다. 이제 주니어 개발자도 AI를 써서 엄청난 속도로 코드를 생산합니다. 좋은 일 같죠? 하지만 업계에서는 이를 '코드 슬롭(Code Slop)', 즉 검증되지 않은 잉여 코드의 범람이라고 부르기 시작했습니다.
- Good News: AI 덕분에 개발 속도가 빨라졌고, 모니터링 도구도 똑똑해졌습니다.
- Bad News: 감당할 수 없을 만큼 많은 코드가 프로덕션으로 쏟아집니다.
과거에는 사람이 짜는 속도가 병목이었기에 자연스럽게 배포 속도가 조절되었습니다. 이제는 댐이 무너진 것과 같습니다. 이 상황에서 기존처럼 "배포하고 기도하기(Deploy and Pray)" 전략을 쓴다면? 시스템 가용성 99.99%는 고사하고 매일 밤 장애 회고(Post-mortem)를 쓰게 될 겁니다.
5. 생존 전략: 배포는 끝이 아니라 시작이다
살아남으려면, 그리고 DevOps가 실패한 그 지점을 연결하려면 루틴을 바꿔야 합니다. 코드를 작성하는 것만큼이나 '코드가 배포된 직후'를 보는 것이 중요합니다.
Action Item: Observability(관찰 가능성)의 내재화
막연하게 "모니터링 강화하세요" 같은 소리가 아닙니다. 구체적으로 다음 루틴을 만드세요.
- 배포 직후 15분: 내가 배포한 기능의 트래픽, 에러 레이트, 레이턴시를 직접 확인하세요. 대시보드를 보는 게 아니라, 내가 건드린 그 API의 지표를 봐야 합니다.
- 도구의 통합: Grafana나 Datadog, Honeycomb 같은 도구를 운영팀 전유물로 두지 마세요. 개발자가 PR을 날릴 때 해당 변경 사항이 영향을 줄 수 있는 지표 링크를 같이 첨부하는 문화를 만드세요.
- 피드백 루프 닫기:
Deploy -> Observe -> Learn. 배포 후 로그와 지표를 통해 "아, 사용자들이 이 버튼을 이렇게 많이 누르는구나" 혹은 "이 쿼리가 DB에 부하를 주는구나"를 깨달아야 합니다.
마치며
테스트 코드를 100% 작성했다고 자만하지 마세요. 사용자는 우리의 상상력을 뛰어넘는 방식으로 시스템을 망가뜨립니다.
진정한 엔지니어링의 희열은 로컬 테스트 통과가 아니라, 내가 만든 시스템이 수만 명의 트래픽을 견뎌내고 비즈니스 가치를 만들어내는 걸 눈으로 확인할 때 옵니다. 20년간 끊어져 있던 그 고리를 연결하는 건, 결국 화려한 도구가 아니라 "내가 짠 코드는 내가 끝까지 본다"는 엔지니어의 태도입니다.
오늘 배포한 그 코드, 로그 한번 더 확인하고 퇴근하시죠. 그래야 오늘 밤 푹 잘 수 있습니다.
