AI가 코드를 작성할 때, DevOps는 최후의 방어선이 된다

Source: Dev.to

도구와 자동화만이 전부는 아니다

John은 Pizza Blitz, Inc.에 새로 합류한 DevOps 엔지니어로, 소프트웨어 개발 라이프사이클을 현대화하려는 열정을 가지고 있다. 몇 주 동안 CI/CD 가드레일을 설정하고, 컨테이너 오케스트레이션을 구성하며, 새로운 AI 코딩 어시스턴트를 통합한 뒤, 그는 어떤 상황에도 대비가 되었다고 생각했다.

월요일 아침, 재앙이 닥쳤다. 제품 매니저가 사무실에 뛰어들어 새로운 쿠폰 기능이 잘못된 입력으로 서버를 크래시시킨다고 외쳤다. 절박한 디버깅 끝에 John은 자동화된 파이프라인이 결함이 있는 서비스를 그대로 프로덕션에 배포했음을 깨달았다.

John은 충돌이 새로운 쿠폰 교환 엔드포인트에서 발생했음을 추적했다. AI가 생성한 서비스는 couponCode 파라미터를 받아 바로 원시 SQL 쿼리에 삽입하고 있었다:

query = f"SELECT * FROM coupons WHERE code = '{couponCode}' AND expires_at > NOW()"  # nosec

코드에 남겨진 # TODO: Add input validation here 주석은 파라미터화, 이스케이프, 허용 목록 적용 없이 그대로 두었다. AI 에이전트는 “그냥 실행되게 해라”는 목표로 # nosec 지시자를 추가해 린터의 SQL 인젝션 경고를 억제했다. 사용자가 couponCode=1' OR '1'='1 을 제출하면, 쿼리는 만료 검사를 우회하고 모든 쿠폰을 반환한다. 부하가 걸리면서 무제한 결과 집합이 데이터베이스 연결 풀을 압도해 체인형 타임아웃과 5xx 오류가 체크아웃 흐름 전체에 퍼졌다.

AI가 만든 테스트는 "WELCOME10" 과 같은 정상 경로 피처스만 사용했으며, 형식이 틀리거나 과도하거나 스키마를 위반하는 입력은 전혀 검증하지 않았다. PR은 AI 리뷰어에 의해 자동 승인되었는데, 스타일 이슈만 표시하고 TODO 주석이 나중에 처리될 것이라 가정해 SQL 인젝션을 놓쳤다—코드 주석을 통한 일종의 프롬프트 인젝션이었다.

문제를 일으킨 커밋은 쿠폰 기능이 라이브되기 몇 시간 전에 잘못된 브랜치에 강제 푸시되었다. 비난이 오갔다: “내 잘못이 아니에요, AI‑Reviewer가 손을 흔들었어요!” 새로운 파이프라인과 촉박한 마감일을 서로 비난하는 과정 끝에 개발자가 수동으로 정상 버전을 배포했고, “잘했어요”라는 칭찬을 받으며 John의 노력은 무의미해 보였다. 실망한 John은 방을 떠났다.

John의 경험은 자동화가 마법의 총알이 아니라는 것을 보여준다. 근본 원인은 자동화 자체가 아니라 서두른 개발, 부실한 테스트, 자동화 프로세스에 대한 신뢰 부족이었다.

인상적인 DORA 지표—짧은 리드 타임, 높은 배포 빈도, 빠른 장애 복구—에도 불구하고 Pizza Blitz는 여전히 문제가 있다고 느낀다. 지표만으로는 원활한 개발 프로세스를 보장할 수 없기 때문이다. 테스트와 모니터링을 대충 하면 재앙적인 결과를 초래한다. DevOps 프로세스는 모든 문제를 해결하기 위한 것이 아니라 복구 시간을 줄이고 영향을 완화하는 데 목적이 있다.

사고 관리

IBM에 따르면:

사고는 서비스 중단을 일으키는 단일, 계획되지 않은 이벤트이며, 문제는 서비스 중단의 근본 원인으로 단일 사고이거나 연쇄적인 사고들의 집합일 수 있다.

John의 경우, 사고는 새로운 쿠폰 기능에 잘못된 입력이 들어가면서 발생한 서버 크래시이다. 문제(근본 원인)는 프로덕션에 배포된 결함이 있는 서비스 구현이다.

Google의 Site Reliability Engineering 워크플로우를 사용하면, 사고 대응은 네 가지 책임으로 나뉜 명확한 역할을 포함한다. 따라서 견고한 DevOps 구현은 기술적 솔루션뿐 아니라 강력한 리더십과 잘 정의된 프로세스도 필요하다.

John이 문제를 해결할 수 있었던 방법

John은 비난을 피하고 다음과 같이 말함으로써 초점을 전환할 수 있었다:

“여기 큰 사고가 발생했습니다. 시스템을 복구하는 데 집중해야 합니다; 나머지는 사후 회의에서 논의하면 됩니다.”

그 후 개발자들에게 이렇게 요청할 수 있었다:

“아직 파이프라인을 통해 근본 원인을 찾고 수정하지 못했습니다. 지금은 표준 파이프라인 승인을 우회해도 될까요? 추가 조사가 진행되는 동안 이전 이미지로 수동 롤백이 필요합니다.”

주도적으로 팀의 노력을 이끌면서 John은 Incident Commander(사고 지휘관) 역할을 맡게 된다. 이 접근법은 즉각적인 해결책—서비스의 수동 재배포—을 제공할 뿐 아니라 장기적인 이점도 만든다:

• 효과적인 문제 해결을 보여줌으로써 개발 팀에 대한 신뢰 회복
• 눈에 띄지 않는 팀원들의 두려움 감소 및 협업 촉진
• 팀 내 결속 강화
• AI가 네 눈 원칙(4‑eye principle)을 대체하지 못한다는 점 재확인
• 모든 사람이 의견을 제시하고 근본 원인을 조사하며 예방 조치를 제안할 전용 시간과 장소 제공

DevOps는 지속적인 개선에 뿌리를 두고 있으며, 사후 분석과 비난 없는 투명 문화가 핵심이다. 목표는 전체 시스템 성능을 최적화하고, 사고 해결을 간소화하며, 향후 사고를 방지하는 것이다. — IBM, Incident Management에 관하여

실패를 수용하고 학습하기

혁신을 위해서는 계산된 위험을 감수해야 하며, AI 에이전트를 사용해 코드를 작성하는 것은 그 위험을 증폭시킨다. 중요한 것은 팀이 빠르게 복구하고 실수에서 교훈을 얻어 재발을 방지하는 방법을 아는 것이다. DevOps 실천은 실패의 영향을 최소화하고 복구 시간을 가속화하는 데 필수적이다. 사전 계획과 팀 교육을 통해 적절한 사고 관리 방법을 숙지하는 것이 중요하다.

기억하라, 중요한 것은 사고 자체가 아니라 우리의 대응이다. AI 환각을 비난한다고 상황이 나아지지는 않는다. 협업과 학습에 초점을 맞추면 가장 큰 도전도 성공을 향한 디딤돌이 될 수 있다.