스크럼으로 안전한 소프트웨어 개발하기

초록

본 논문은 기존 스크럼 프로세스를 그대로 유지하면서 보안 활동을 체계화하는 “Secure Scrum”을 제안한다. 보안 이슈를 식별·표시하고, 구현·검증 단계에 연계하도록 S‑Tag와 S‑Mark 개념을 도입해 비전문가 팀도 보안 요구를 인식·처리할 수 있게 한다. 현장 실험 결과, Secure Scrum을 적용한 팀이 표준 스크럼보다 높은 보안 수준의 제품을 산출하였다.

상세 분석

Secure Scrum은 스크럼의 핵심 원칙—자율성, 협업, 반복적 인크리멘트—을 훼손하지 않으면서 보안 활동을 전 과정에 스며들게 하는 메커니즘을 제공한다. 가장 핵심적인 요소는 ‘S‑Tag’와 ‘S‑Mark’이다. S‑Tag는 보안 관련 우려(위협, 공격 벡터, 보안 원칙 등)를 설명하는 별도 백로그 항목이며, S‑Mark는 해당 보안 우려가 적용되는 제품 백로그 아이템(사용자 스토리) 위에 시각적으로 표시한다. 이를 통해 보안 이슈는 제품 백로그, 스프린트 백로그, 일일 스크럼 전반에 걸쳐 지속적으로 가시화된다.

식별 단계에서는 이해관계자와 개발자가 각 사용자 스토리의 ‘손실 가치’를 추정하고, 이를 기반으로 위험 순위를 매긴다. 손실 가치는 기능이 공격당했을 때 발생할 금전적·평판적 손실을 의미하며, 정량화가 가능하도록 USD·EUR 등 통화 단위로 표현한다. 위험 순위와 손실 가치를 결합해 보안 우선순위를 도출하고, S‑Tag와 S‑Mark를 통해 백로그에 반영한다.

구현 단계에서는 스프린트 계획 시 S‑Mark가 붙은 스토리를 작업 단위(task)로 분해하고, 각 작업에도 S‑Mark를 부여한다. 이렇게 하면 개발자는 자신의 작업이 어떤 보안 우려와 연결되는지 실시간으로 인식한다. 또한, 외부 보안 전문가가 필요할 경우 S‑Tag에 대한 설명을 보강하거나, 별도의 컨설팅 작업을 S‑Mark가 붙은 새로운 태스크로 생성해 기존 스크럼 흐름을 방해하지 않는다.

검증 단계는 ‘정의된 완료(Definition of Done, DoD)’와 연계된다. 보안 검증이 같은 스프린트 내에서 수행 가능하면 해당 검증 절차를 작업의 DoD에 포함시켜야 한다. 검증에 전문 지식이나 외부 리소스가 필요해 즉시 수행이 어려운 경우, 검증 전용 태스크를 별도로 생성하고 S‑Mark와 원래 S‑Tag를 연결한다. 이렇게 하면 보안 검증이 누락되지 않고 추적 가능하게 된다.

Secure Scrum은 기존 스크럼에 새로운 역할이나 별도 백로그를 도입하지 않는다. 모든 보안 활동은 기존 제품·스프린트 백로그와 DoD에 자연스럽게 녹아들어 팀의 일상적인 워크플로우를 유지한다. 이는 스크럼 팀이 이미 익숙한 도구와 회의를 그대로 사용하면서도 보안 인식을 높일 수 있게 한다는 점에서 실용적이다.

실험에서는 두 팀을 비교했는데, 한 팀은 표준 스크럼만 적용하고 다른 팀은 Secure Scrum을 적용했다. 결과는 Secure Scrum 팀이 보안 취약점 수가 현저히 적고, 보안 테스트 커버리지가 높았으며, 전체 개발 속도는 크게 저하되지 않은 것으로 나타났다. 이는 보안 활동을 초기 단계에서 가시화하고, 스프린트 내에서 지속적으로 검증함으로써 비용 효율적인 보안 강화가 가능함을 시사한다.

전체적으로 Secure Scrum은 보안 요구를 정량화하고, 시각적 표시와 작업 연계 메커니즘을 통해 비전문가도 보안 문제를 인식·해결하도록 돕는다. 또한 외부 전문가와의 협업을 최소한의 관리 오버헤드로 지원함으로써, 기존 스크럼 프로세스를 크게 변형하지 않고도 보안 수준을 향상시킬 수 있는 실용적인 프레임워크라고 평가할 수 있다.