이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 개발팀에서 보안 리뷰가 출시 직전에만 몰리는 문제가 있었습니다. 저는 팀장님께 위협 모델링을 설계 단계에서 먼저 진행하는 방식을 제안했습니다. 처음에는 '시간이 더 걸린다'는 반응이었는데, 실제로 한 기능 설계 세션에서 인증 토큰 저장 방식에 취약점이 될 수 있는 패턴을 미리 발견하면서 팀 내 인식이 바뀌었습니다. 또 코드 리뷰 체크리스트에 OWASP Top 10 항목 중 자주 나오는 패턴을 5개로 추려서 붙였습니다. 리뷰어가 매번 보안 지식을 갖추고 있지 않아도 체크리스트 기반으로 확인할 수 있게 만든 것입니다. 실제로 SQL 인젝션 취약점이 될 수 있는 코드 패턴이 리뷰 단계에서 잡혔습니다. 보안을 별도 게이트로 두는 것보다 개발 흐름 안에 자연스럽게 녹이는 것이 팀 저항도 낮고 실질적으로 작동한다는 걸 그 경험에서 확인했습니다.
보안 SDLC를 조직 안에서 실제로 작동시키려면 개발자가 보안을 자신의 일로 인식하게 만드는 것이 기술적인 도구보다 먼저입니다. "보안은 보안팀의 일"이라는 인식이 남아 있으면 프로세스를 아무리 잘 설계해도 실행 단계에서 우회가 생깁니다. 개발팀 내에서 보안 인식을 높이기 위해 짧은 위협 시나리오 워크숍을 스프린트마다 포함시켰고, 개발자가 직접 자신의 코드에서 위협을 찾는 방식으로 진행했습니다.
보안 챔피언(Security Champion) 역할을 팀 안에 두어서 외부 보안팀 의존 없이 팀 내부에서 보안 관행이 유지되도록 구조를 만들었습니다. 보안 관련 이슈가 발생했을 때 비난보다 원인 분석을 먼저 하는 심리적 안전감이 보안 문제를 숨기지 않고 공유하게 만드는 조건이었습니다.
보안 문화는 도구가 아니라 사람에서 시작됩니다. 보안 챔피언 구조가 팀 주도 보안 관행을 지속하게 만든 기반이었습니다.
보안 SDLC를 챔피언하는 가장 효과적인 방법 중 하나는 개발자가 별도 행동을 하지 않아도 보안 검사가 자동으로 이루어지도록 파이프라인에 내장하는 것입니다. 정적 분석(SAST)과 의존성 취약점 스캔(SCA)을 CI 파이프라인에 추가해서 빌드 단계에서 보안 이슈가 자동으로 감지되도록 구성했습니다.
시프트 레프트(Shift Left) 원칙이 보안 검사를 배포 직전이 아니라 코드 작성 단계로 당기는 설계 철학입니다. 초기에는 너무 많은 경고가 발생해서 개발자가 무시하는 문제가 생겼고, 이를 해결하기 위해 위험도 기준으로 critical 이상만 빌드를 블로킹하는 방식으로 조정했습니다. 이 설정 변경 후에 실제 수정율이 올라갔고, 보안 게이트가 방해물이 아닌 안전망으로 인식되기 시작했습니다.
자동화된 보안 게이트가 보안 챔피언의 실질적인 레버리지입니다. 시프트 레프트 구현이 SDLC 보안 내재화의 핵심 기술 수단이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.