[넋두리 4] 10. 개발자도 직장인이더라
기업 IT를 대표하는 개발과 보안의 반목
기업의 IT를 대표하는 두 부서를 들자면 개발조직과 보안조직이라고 할 수 있다. 그리고 많은 사람들이 익히 알고 있듯 이 두 조직은 대체로 사이가 좋지 않은 편이다. 기업 IT를 책임져야 하는 두 조직의 사이가 나쁘다는 것은 기업에게도 분명 해가 되는 일이다. 어찌해 이런 문제가 생기게 된 것일까?
대부분 국내 IT개발 프로젝트는 아래와 같은 세 가지 특징을 동일하게 가지고 있다.
1. 개발기간은 짧고 예산은 부족
많은 경우 요구되는 사항에 비해 개발기간이 짧다. 게다가 기간을 짧게 산정한 만큼 예산도 적게 배정된다. 따라서 충분한 수의 개발자를 동원하기도 어렵다. 개발자들의 혼을 갈아 넣어 프로젝트를 수행한다는 표현이 생겨난 대표적인 원인이다.
2. 많은 경우 보안검토는 테스트 단계에서 요청
IT사업의 경우 일반적으로 두 번의 보안성검토를 요구한다. 기획 단계와 테스트 단계다. 기획 단계에서는 요구되는 보안요건들을 미리 선별하여 개발 요구사항에 반영하기 위함이고, 테스트 단계에서는 기획 단계에서의 요구사항들이 제대로 반영되었는지 그리고 혹시 누락된 것은 없는지 확인하기 위함이다.
하지만 짧은 개발기간을 이유로 개발 조직이 기획 단계의 보안성 검토를 협의하지 않고 생략하는 경우가 흔히 발생한다. 그 결과 테스트 단계에서 수많은 보안요건들이 미반영된 문제점들과 취약점들이 우수수 도출되게 되며, 이의 조치를 둘러싸고 개발조직과 보안조직의 의견 대립이 시작되면서 본격적인 갈등 관계가 생겨난다.
3. 취약점 조치 미완료 상태로 서비스 개시
기업 내 조직 간의 갈등은 대부분 힘이 센 쪽 즉 직급 높은 쪽이 이긴다. 그리고 보안조직보다 IT(개발) 조직의 우두머리가 힘이 센 경우가 많다. 설령 그렇지 않더라도 "서비스를 빨리 출시하라"는 대표이사의 지시와 같은 명분을 등에 업으면 많은 취약점과 문제점에도 불구하고 서비스는 개시된다. 말 그대로 '선 개시 후 조치'가 되는 셈이다. 그렇다고 서비스 개시 이후에 취약점과 문제점이 모두 조치된다는 보장은 없다.
이런 악순환이 반복되는 것은 보안조직에게는 힘들고 불쾌한 일이다. 불안하고 취약한 상태로 개발된 시스템이 외부에 서비스되고 있어 위협을 느끼기 때문이다. 따라서 불만이 누적되게 되고, 개발자들에게 개발보안과 같은 소양을 키우도록 요구하게 된다. 보안조직이 나서지 않아도 되도록 알아서 잘해주길 바라는 것이다. 하지만 개발자들도 할 말이 많다. 개발자라고 취약점을 만들고 싶어서 만드는 것도 아닐뿐더러 그들도 나름 해야 할 것들이 많기 때문이다.
개발자들에게 요구되는 소양을 열거해 보면 의외로 제법 많음을 알 수 있다.
<그림 1. 개발자에게 요구되는 기본 소양>그림 1에 나열한 것들이 개발자에게 요구되는 기본 소양에 해당된다고 볼 수 있다. 이중 노란색으로 표현한 것들은 대외 환경에 따라 계속해서 변하는 것들이다. 예를 들어 개발언어의 경우 오래전 C 혹은 C++을 이용하던 시대에서 Java, 4GL 시대를 지나 지금은 이름도 생소한 Kotlin, Python 같은 언어를 사용하고 있다. 개발언어가 변하면 개발자들은 당연히 새로운 언어를 다시금 익히고 공부해야만 한다. 기술의 발전에 따라 변해가는 개발환경을 계속 새로 배우고 익혀야 한다는 것은 쉽지 않은 일이고 그것을 해야 하는 것이 개발자다.
그림 1에서 (+)를 표시해 놓은 것들은 개발자가 직장인으로서 진급하고자 한다면 키워야 하는 업무능력들이다. 개발자 역시 직장인이다. 개발자도 진급하고 싶고 더 많은 연봉을 받고 싶음은 인지상정일 것이다. 그러기 위해서는 개발만 잘해서는 안된다. 업무분석을 잘해야 하고, DB설계 능력도 갖춰야 하고, 더 많은 사업을 수주할 수 있도록 제안서 작성 능력도 뛰어나야 하고, 문서작성도 잘해야 하고, 고객과의 소통도 잘해야만 한다. 그래야 진급해서 팀장도 되고 본부장도 되고 임원도 되고 가족에게 자랑스러운 자식이자 아빠이자 엄마가 될 수 있다. 그냥 개발만 잘해서는 뛰어난 개발자일 뿐이지 팀장이나 본부장은 될 수 없는 것이 우리네 직장생활이다.
여기에 보안을 추가로 더 갖추라고 요구하는 것이다. 흔히 말하는 개발보안이다. 개발보안의 소양에는 그림 2와 같은 것들이 포함될 수 있다.
<그림 2. 개발보안 요구 소양>먼저 관련 법에서 요구하는 사항들이 구체적으로 무엇인지 법령을 이해해야 한다. 산업별로 여러 법들이 존재하므로 개발을 진행하는 기업의 산업군에 따라 살펴야 하는 법도 다르다. 그리고 취약점을 이해해야 한다. 왜 취약하다고 하는지 이해해야 왜 조치가 필요한지 받아들일 수 있기 때문이다. 그렇다고 아무렇게나 조치해서도 안된다. 안전한 보안이 가능하도록 보안코딩이 이루어져야 한다. 사용해서는 안 되는 취약한 코딩 명령어가 무엇인지, 어떤 함수를 쓰라고 권고하는지 알아야만 한다.
그래도 침해사고는 발생한다. 그리고 사고가 발생하면 개발자들은 보안조직과 함께 사고 대응에 나서야만 한다. 보안조직은 사고를 미연에 방지하지 못했다는 죄로, 개발자들은 해커의 해킹에 속절없이 뚫린 서비스를 개발했다는 죄로 말이다.
개발조직은 보안조직에 대해 이렇게 표현한다. "문제를 던지고 지적질만 하는 무책임한 놈들"이라고.
보안조직은 개발조직에 대해 이렇게 표현한다. "미리 협의할 줄도 모르고 지 얘기만 하는 놈들"이라고.
사실 따지고 보면 IT전문 기업을 제외한 일반 기업의 경우 내부에서 힘없기로 둘째가라면 서러울 조직들끼리 사이좋게 지내도 모자랄 판인데 이 모양 이 꼴이다. 하지만 찬찬히 시간을 가지고 들여다보면 이해할 수 있다. 개발자들도 충분히 힘들고 어렵다는 것을. 안전하게 잘 개발하고 싶지만 그것이 참 쉽지 않은 일이란 것을. 개발자들도 익히고 배워야 할 것들이 참 많음을. 결정적으로 그들도 나와 우리와 똑같은 직장인일 뿐이라는 것을 말이다.
관련 글: [넋두리 3] 12. [판의 개혁] 개발보안의 미래 https://brunch.co.kr/@sunwoodowoo/79
관련 글: [넋두리 2] 8. 좋은 개발보안이란 무엇인가! https://brunch.co.kr/@sunwoodowoo/42
