16. 보안팀과 개발팀이 덜 부딪히는 방법에 대해 생각해 본 적이 있습니다

보안·개인정보 업무를 하다 보면
개발팀과 함께 일할 일이 많습니다.

서로 입장이 다르다 보니
긴장감이 생길 때도 있고,
“보안은 늘 안 된다고만 한다”는 말을 들을 때도 있습니다.

저도 일을 하면서
부딪히는 순간과 잘 풀리는 순간을 둘 다 경험했고,
그 과정에서 조금씩 정리하게 된 생각들을
한 번 적어보고 싶었습니다.

타이밍을 놓치면, 같은 말도 더 무거워진다

보안 요구사항을 언제 얘기하느냐에 따라
받아들이는 무게가 달라집니다.

• 기획 초기나 설계 단계에서 이야기할 때와
• 개발이 거의 끝난 뒤,
  릴리즈 직전에 이야기할 때의 반응은
  당연히 다를 수밖에 없습니다.

그래서 가능하면

• 큰 구조와 원칙은 초반에
• 세부적인 보완 사항은 중간중간

이야기를 나누려고 합니다.

물론 이상적인 타이밍만 골라서 얘기하기는 어렵지만,
최소한 “이건 초반에 한 번 같이 보자” 싶은 항목들은
미리 개발팀과 공유해 두는 편이
서로에게 덜 피곤했습니다.

“안 된다” 대신 “이 방향은 어떨까요”를 먼저 꺼내기

솔직히 말해서
보안 관점에서 보면 불안한 부분은 항상 보이기 마련입니다.

이걸 바로
“이건 안 됩니다”로 시작하면
대화가 빠르게 막힙니다.

저도 시행착오를 겪으면서
가능하면

• 안 되는 이유를 설명하기 전에
• 어떤 방향으로 바꿔볼 수 있을지
  대안을 먼저 제시하는 쪽이
  훨씬 대화가 잘 풀린다는 걸 느꼈습니다.

완벽한 대안이 아니더라도
같이 수정해 나갈 수 있는 초안 정도라도 들고 가면
“막는 사람”이 아니라
“같이 방법을 찾는 사람”으로 보이게 되는 것 같습니다.

속도와 안전 사이의 기준을 같이 정해 두기

개발팀 입장에서는
출시 일정과 비즈니스 요구가
가장 큰 압박으로 다가올 수밖에 없습니다.

보안팀 입장에서는
사고와 규제 리스크가 크게 보입니다.

결국 둘 사이에서 어느 정도 선을 그을 것인지
기준을 같이 정해 둔 경우에는
갈등이 조금 덜했습니다.

예를 들면

• 어떤 유형의 이슈는
  반드시 해결되어야 출시 가능한지
• 어떤 이슈는
  출시 후 일정 기간 안에 개선하는 것을 전제로 허용할 수 있는지

이런 기준을 사전에 한 번이라도 맞춰두면
막판에 갑자기 싸움이 나는 상황은 줄어듭니다.

“왜 이걸 요구하는지”를 설명해 보기

보안 요구사항이
단순히 “점검에서 지적받지 않기 위해서”만
나오는 것처럼 보이면
개발팀 입장에서는 공감하기 어렵습니다.

그래서 저도 요구를 전달할 때 가능하면

• 실제로 있었던 사고 사례나
• 비슷한 유형의 리스크를
  함께 설명하려고 합니다.

“이 요구사항은 이런 유형의 문제를 막기 위해 나온 것이고,
우리 서비스에서는 이 부분에 해당될 수 있다”

라는 정도만 공유해도
대화의 온도가 조금 달라졌습니다.

서로의 언어를 조금씩 배워가기

개발팀과 보안팀은
같은 화면과 같은 시스템을 보면서도
쓰는 언어가 다릅니다.

개발팀은 성능, 구조, 유지보수 관점에서,
보안팀은 리스크와 규제 관점에서 보는 편입니다.

서로의 언어를 조금씩이라도 배워두면
오해가 줄어듭니다.

보안 쪽에서

• 코드나 인프라 구조를 어느 정도 이해하려고 노력하고

개발 쪽에서도

• 최소한의 보안·개인정보 기본 개념을 알고 있다면

같은 말을 두세 번 반복해야 하는 상황이 줄어듭니다.

저도 아직 배우는 중이지만,
개발자분들이 쓰는 표현과 논리를 조금씩 익혀 가는 과정이
생각보다 도움이 많이 됐습니다.