기획자가 코드를 배포하면, 장애는 누가 책임질까

AI로 소프트웨어를 만드는 조직의 이야기를 듣다 보면 코드 작성자의 범위가 달라지고 있다는 게 느껴진다. 제품 담당자가 직접 코드를 만들고, 여러 에이전트가 동시에 작업한다. 그러면 개발팀의 역할도 다시 물어야 한다. 누가 코드를 만들 수 있느냐와 함께, 그 결과를 고객에게 내보내는 과정에서 누가 무엇을 확인할 것인가.

제목의 질문은 사고가 난 뒤 책임질 사람을 고르자는 뜻이 아니다. 운영에 영향을 주는 변경이 생기기 전에 책임의 범위를 정해야 한다는 문제의식이다. 여기서 말하는 책임은 업무와 운영상의 역할을 뜻한다.

기획자가 만든 화면은 왜 데모와 배포가 다른가?

데모에서 잘 돌아간다는 사실과 운영에 내보내도 된다는 판단 사이에는 화면에 보이지 않는 질문이 여러 개 있다. 설명을 위한 예시로 하나의 상황을 가정해 보자. 기획자가 AI로 관리 화면을 만들었다. 데모에서는 잘 작동하고 필요한 정보도 표시된다. 근데 실제로 배포하려면 다른 질문이 생긴다.

• 권한이 없는 사람도 이 화면에서 데이터를 조회할 수 있는가
• 기존 고객 데이터의 예외 케이스를 처리하는가
• 실패했을 때 무엇을 되돌려야 하는가

화면을 구현했다는 사실만으로 이 질문들이 해결되지는 않는다. 작성자가 누구든 마찬가지다.

AI가 코드를 쓰면 검토와 승인의 역할은 없어지나?

없어지지 않는다. 작성 주체와 별개로 변경을 평가할 기준이 있어야 하고, 그 기준을 맡는 사람이 있어야 한다. 업무 요구를 정의한 사람은 어떤 사용자 문제를 해결하는지 설명하고, 검토자는 구현과 위험을 확인하며, 운영을 맡는 사람은 배포와 복구의 조건을 이해해야 한다. 한 사람이 여러 역할을 맡을 수 있다. 피해야 할 것은 어느 역할도 맡은 사람이 없는 상태다.

이런 역할 구분은 AI 때문에 갑자기 생긴 원칙이 아니다. NIST의 SSDF 1.1도 보안 개발에 필요한 역할과 책임을 정하는 일(PO.2)과 소스 코드를 검토하거나 분석하는 일(PW.7)을 별도의 실천 항목으로 다룬다. AI가 코드를 작성하더라도 조직이 이 과정을 어떻게 수행할지는 여전히 조직이 결정해야 한다는 게 내 해석이다.

모든 변경을 개발팀이 다 검토해야 하나?

아니다. 모든 변경을 개발팀 한 사람에게 몰아주는 방식은 오래 버티기 어렵다. 작은 문구 수정과 인증 정책 변경은 영향 범위가 다르다.

내 제안은 두 갈래다. 위험이 낮고 복구가 쉬운 변경은 검증된 경로로 처리하게 하고, 데이터·권한·외부 연동처럼 영향이 큰 변경에는 필요한 검토자를 붙인다. 빠른 경로를 만들려면 그 경로가 허용하는 범위도 분명해야 한다. "이 정도는 스스로 배포해도 된다"는 문장이 문서에 있어야 실제로 빠른 경로가 된다.

승인 버튼을 누르는 사람은 무엇을 봐야 하나?

승인자가 지금 보고 있는 것이 정확히 무엇인지가 화면에 드러나야 한다. 최신 코드인가, 실제 배포할 결과물인가. 그 결과물에 적용된 테스트와 보안 검사는 무엇인가. 확인하지 못한 항목은 무엇인가. 무엇을 승인하는지 모른 채 누르는 버튼은 책임을 명확하게 만들기 어렵다.

특히 승인 뒤 코드가 바뀌는 상황을 중요하게 본다. 승인한 대상이 A 버전인데 실행되는 대상이 B 버전이라면, A에 대한 판단을 B에 그대로 적용해도 되는지 확인해야 한다. 빌드 결과물의 출처를 기록하는 SLSA provenance도 결과물이 어디서 어떻게 만들어졌는지 검증 가능한 정보를 다룬다. 배포 승인에도 이처럼 대상을 정확히 식별하는 관점이 필요하다. 공급망 쪽에서 이 비용을 어떻게 계산하는지는 SLSA의 실제 비용에서 따로 다뤘다.

장애가 나면 작성자를 찾아야 하나?

작성자보다 먼저 봐야 할 것은 검증과 승인 과정에서 무엇을 놓쳤는가다. Google SRE의 포스트모템 문화는 개인의 비난보다 사고에 기여한 조건을 이해하고 재발 방지 조치를 만드는 접근을 설명한다. 이를 조직에 적용하면 작성자가 누구였는지와 함께, 어느 단계에서 그 위험이 보였어야 했는지를 살피게 된다. 사고 이후의 책임은 복구와 학습으로 이어져야 한다.

솔직히 이 원칙은 작성자가 개발자일 때도 똑같이 적용되던 것이다. 작성자의 범위가 넓어졌다고 달라질 이유가 없다.

개발팀에게 더 생기는 일

개발팀에게는 중요한 일이 하나 더 생긴다. 더 많은 사람이 소프트웨어를 만들 수 있도록 검증 가능한 실행 경로를 설계하는 일이다. 어떤 변경은 스스로 배포할 수 있고, 어떤 변경은 전문가와 함께 확인해야 하는지 누구나 이해할 수 있어야 한다. 에이전트가 운영 권한을 어디까지 가져야 하는지는 에이전트와 프로덕션 권한에서 이어서 썼다.

내가 CollabOps에서 Change와 추적성에 집중하는 이유도 여기에 있다. 누가 어떤 도구로 작성했든, 운영에 들어간 변경을 의도·코드 버전·결과물·검증 근거·승인·배포 이력으로 설명할 수 있는 구조를 만들고 있다. 저장소, 변경요청, 파이프라인, 배포 기록이 한 평면에 있으면 "무엇을 승인했는가"가 따로 조사할 일이 아니라 일하는 과정의 부산물로 남는다. 작성자의 범위가 넓어질수록, 함께 책임질 수 있는 범위도 의식적으로 설계해야 한다.