다른 쪽에서 온 파견: 정렬된 인센티브
Source: Dev.to
Introduction
이 글은 Dispatch From the Other Side 시리즈의 세 번째 포스트입니다.
이전 글 링크
처음 들었을 때부터 찰리 멍거의 인센티브에 관한 명언이 계속 마음에 남았습니다:
“인센티브를 보여줘, 그러면 결과를 보여줄게.”
이 말은 제가 계속 마주하던 상황을 설명해 주었습니다. 개발 팀이 보안 이슈를 무시한 것이 무관심 때문이 아니라, 그들이 어떻게 측정되는지에 대한 합리적인 반응이었기 때문입니다.
이것이 바로 지난 글에서 탐구한 레버리지 접근 방식이 가치 있는 이유입니다. 팀에게 작업 방식을 바꾸라고 요구하기보다, 준수 비용을 낮추는 것이죠. 일반적인 경우가 쉬워지면 대부분의 팀이 그 방식을 선택하게 됩니다.
대조적인 접근
제가 함께 일했던 취약점 관리 팀이 낮은 위험도의 발견 사항에 대해 개발 팀에 연락했지만, 아직 해결책이 없어 프로덕션에 반영되지 못하도록 차단했습니다. 보안 팀은 알려진 취약점을 제거하는 것으로 측정되었고, 개발 팀은 작동하는 소프트웨어를 배포하는 것으로 측정되었습니다. 이 긴장을 해결하지 않은 채 두고 보면, 신뢰는 어떤 놓친 취약점보다도 더 빨리 무너집니다.
점진적으로 기준 올리기
개발 팀은 보안 이슈를 해결할 시간이 제한되어 있습니다. 저는 “완벽이 선을 막는 것”보다 천천히 기준을 올리는 쪽이 더 성공적이라는 것을 보았습니다. 공식 규칙 집합에 새로운 클라우드 오탐지 규칙을 도입하기 전에, 개발 팀에게 피드백을 요청했습니다. 이를 통해 팀은 준비 시간을 갖게 되고, 시행 전에 동의를 얻을 수 있었습니다.
감시보다 파트너십
때때로 문제를 발견하는 사람은 많지만, 이를 해결할 권한이 있는 사람은 적습니다. 저는 개발 팀에 부담을 주기보다 보안 구성 문제를 직접 고치는 풀 리퀘스트를 제출했습니다. 몇 차례 후, 팀은 더 일찍 저를 끌어들여 위험한 옵션을 아예 제거할 방법을 찾으려 했습니다. 이런 접근은 파트너십으로 전환시켜 주며, 여러분이 그들의 성공에 투자하고 있음을 보여줍니다.
품질의 한 차원으로서 보안
보안은 전체 품질의 한 차원에 불과합니다. 팀은 운영 위험과 보안 위험을 동시에 관리합니다. 보안 패치가 충분히 테스트되지 않거나 서두르면 시스템 가용성에 영향을 줄 수 있습니다. 보안 부채는 기능 부채, 운영 부채, 아키텍처 부채와 경쟁합니다—단독으로 존재하지 않습니다. 여러 이해관계자 그룹이 개발 팀에게 동일한 문제에 대한 시정 조치를 요구하는 경우를 많이 보았습니다.
인센티브 정렬
인센티브가 맞물리면 신뢰가 따라옵니다. 이러한 변화는 보안을 적대적인 관계에서 파트너십으로 전환시키고, 도구 개선만으로는 해결되지 않는 문제에 대한 영향을 크게 늘립니다.
앞으로의 전망
생성 AI가 소프트웨어 구축 방식을 가속화함에 따라 인센티브 격차가 더 벌어질 수 있습니다. 중요한 질문은 보안이 그 변화에 맞춰 진화하느냐인데, 이것이 바로 마지막 글에서 다룰 내용입니다.