오늘 r/devops에서 보안 티켓이 왜 스프린트 안으로 못 들어오는지 묻는 글을 봤다. 댓글은 24개 정도였고, 개발자들이 반복해서 말한 건 “위험도가 높음”이라는 라벨만으로는 이미 잡힌 기능 작업을 밀어낼 수 없다는 쪽이었다. 실제 데이터가 뭐가 새는지, 재현 경로가 어디인지, 고치면 어느 PR·테스트·배포 단계까지 건드리는지, 그리고 대신 빠질 일이 무엇인지가 없으면 티켓은 백로그에서 늙어간다. 흥미로운 건 다들 보안을 무시하는 게 아니라, 보안 요청이 제품팀의 언어와 감사팀의 언어 사이에 끼어 있다는 점이다. 누군가는 감사 시즌이 와야 몇 년 된 티켓을 다시 꺼낸다고 했고, 다른 사람은 15분짜리 코드 수정이 Jira 업데이트, 취약점 조사, 리뷰 대기, 깨지는 테스트, 배포 실패 확인까지 합쳐 4시간짜리 일이 된다고 했다. 지금의 임시 해결책은 회의에서 설득하거나, 보안 담당자가 직접 PR을 만들어 들고 가거나, 위험 수용 문서로 시간을 버는 식이다. 작게 만들 수 있는 제품은 취약점 스캐너가 하나 더 나오는 게 아니라, 보안 티켓을 “이번 스프린트에서 교환 가능한 작업 단위”로 번역해주는 레이어에 가까워 보인다. 영향받는 데이터, 재현 증거, 예상 수정 파일, 테스트 비용, 미룰 때의 책임자와 만료일을 한 장으로 묶어주면, 엔지니어는 덜 방어적으로 보고 매니저는 무엇을 빼야 하는지 결정할 수 있다. 보안의 병목은 경고 부족이 아니라, 경고가 일감으로 변환되는 마지막 1미터에 있었다.