기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 목표
<a name="objectives"></a>

DevSecOps 메커니즘과 관련된 설계 결정은 자주 독립적으로 이루어지므로 플랫폼 사용자 및 기타 이해관계자에게 다운스트림 문제가 발생할 수 있습니다. 기존 사용자 스토리 개발에서 개발자는 사용자의 입장에서 구현할 기능과 주어진 기간 내에 구현하는 가장 좋은 방법을 결정해야 합니다.

개발자는 일반적인 [two-way-door 방식으로](https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/) 기능과 사용자 스토리를 개발하는 데 익숙합니다. 그러나 DevOps 및 DevSecOps 메커니즘은 훨씬 더 높은 수준의 증폭 및 영향을 미칩니다. 이러한 메커니즘은 일반적으로 전체 조직에 영향을 미치며 종종 단방향 문을 나타냅니다. 조직 사용자의 요구 사항을 충족하지 않는 방식으로 설계된 경우 채택에 대한 저항이 있습니다. 따라서 결국 메커니즘을 다시 빌드해야 할 수 있으며, 이로 인해 상당한 개발 지연과 신뢰 상실이 발생할 수 있습니다.

이 가이드는 이러한 기능을 설계하고 배포할 때 개발자에게 추가적인 전술적 지침을 제공하여 이러한 메커니즘의 사용자와 이해관계자가 겪는 구현 문제를 완화하기 위한 것입니다.

이 가이드의 권장 사항을 구현한 후에는 다음을 올바르게 식별할 수 있어야 합니다.
+ 메커니즘이 다양한 코드 권한 소스를 지원하는 방법
+ 메커니즘이 다양한 환경 배포 전략을 지원하는 방법
+ 환경 배포 상태를 관리하는 방법
+ 사용성에 초점을 맞춘 방식으로 적절한 보안 제어를 구현하는 방법