Yoo HeehyeonYoo Heehyeon

소프트웨어 개발에서 보안은 오랫동안 걸림돌처럼 취급됐다. 빠르게 배포하려는 개발 조직과, 리스크를 줄이려는 보안 조직이 부딪히는 구조였기 때문이다. DevSecOps는 이 마찰을 줄이기 위해 나온 접근이다. 단순히 보안 도구를 더 붙이는 이야기가 아니라, 개발 흐름 자체를 바꾸는 방식에 가깝다.

1. 전통적 모델의 한계점

기존 폭포수 모델이나 초기 애자일 환경에서는 보안 검수가 개발 막바지, 그것도 배포 직전에 몰리는 경우가 많았다. 흔히 Right-Side Security라고 부르는 방식이다. 문제는 이 시점의 수정 비용이 너무 크다는 데 있다.

개발이 거의 끝난 뒤 발견된 취약점은 단순 코드 수정으로 끝나지 않는 경우가 많다. 아키텍처 수준 변경이 필요한 상황도 자주 나온다.

대표적인 경우는 이렇다.

• 이미 데이터베이스 스키마와 API 설계가 끝난 상태에서 암호화 방식의 결함 발견
• 세션 기반 인증으로 구현을 마쳤으나, 모바일 확장을 위해 토큰(JWT) 기반으로 전면 재설계 필요
• 네트워크 분리가 고려되지 않은 채 배포되어, 내부망 이동(Lateral Movement) 취약점 발견

이런 문제는 코드 몇 줄 고치는 수준으로 안 끝난다. 설계를 다시 열어야 하고, 그만큼 비용과 일정이 한꺼번에 깨진다.

2. Shift-Left: 보안의 좌측 이동

Shift-Left는 보안 검증 시점을 SDLC의 왼쪽, 즉 기획과 개발 단계로 끌어오는 개념이다. 유행어처럼 들릴 수 있지만, 실제로는 비용 구조 때문에 나올 수밖에 없는 선택에 가깝다.

IBM System Science Institute 연구에서도 결함 수정 비용은 단계가 뒤로 갈수록 크게 늘어난다.

• 설계 단계: 1x
• 개발 단계: 6.5x
• 테스팅 단계: 15x
• 운영(배포) 단계: 100x

그래서 보안 이슈는 개발자가 코드를 쓰는 순간이나, 커밋 직전처럼 가장 이른 지점에서 잡는 게 가장 싸다.

3. DevSecOps의 3대 요소

CI 파이프라인에 보안 도구를 붙인다고 DevSecOps가 완성되지는 않는다. 아래 세 가지가 같이 돌아가야 의미가 생긴다.

3.1. 문화(Culture)

핵심은 "보안은 보안팀 일"이라는 인식을 버리는 데 있다. 개발자도 보안 책임을 같이 지는 구조가 되어야 한다. 이때 보안팀은 통제자보다 조력자에 가깝게 움직여야 한다. 개발자가 보안 기준을 지키기 쉬운 환경을 만드는 쪽이 훨씬 효과적이다.

3.2. 자동화(Automation)

사람 손을 많이 타는 보안 절차는 결국 우회된다. 배포마다 담당자가 수동 점검하는 구조라면 속도부터 무너진다.

그래서 자동화가 필요하다.

• SAST(정적 분석): 코드 작성 시점에 문법적 결함 탐지
• SCA(구성 분석): 오픈소스 라이브러리 취약점 자동 점검
• DAST(동적 분석): 실행 중인 애플리케이션 대상 모의 해킹

3.3. 측정(Measurement)

보안도 결국 측정돼야 관리된다. 취약점 개수, MTTR, 배포 성공률 같은 지표를 봐야 어디가 막히는지 보인다.

결국 DevSecOps는 속도와 보안을 둘 중 하나만 택하는 구조를 거부한다. 목표는 느린 보안이 아니라, 보안이 기본값으로 녹아 있는 빠른 개발이다.