[칼럼]좋은 IT의 시작은 '프로그램 소스'부터

IT는 서버, 네트워크, 프로그램 및 사람과 같은 구성요소가 복합적으로 작용하여 사용자에게 서비스를 제공하게 된다. IT의 구성요소 중에 하나라도 결함이 발생하게 되면, 이것은 IT서비스의 중단이나 품질저하 또는 보안 사고 등을 유발할 수 있다.

IT의 구성요소 중, 특히 ‘프로그램’은 사용자와의 직접적인 접촉을 담당하고 있으며, 사용자의 요청을 처리하고, 다른 IT구성요소와 커뮤니케이션을 하는 중요한 역할을 수행한다.

사용자가 IT조직의 담당자를 접촉하지 않고 프로그램과 직접 대화(?)하는 경우, IT조직은 이러한 대화에 끼어들 여지가 없다. 오직 사용자와 프로그램간의 무언의 접촉만이 존재할 뿐이다. 사용자 입장에서도 본인이 요청한 결과를 프로그램이 제때 제공만 해준다면 프로그램이 다른 IT구성요소와 어떤 행위를 하는 지에 대해서는 알 수도 없고, 또 참견할 이유가 없다.

프로그램을 만든 IT조직 역시, 사용자가 특별한 불만을 제기하지 않는다면 사용자와 프로그램간의 커뮤니케이션이 잘 되고 있는 것으로 믿게 된다. 이러한 믿음은 프로그램을 사용자가 사용하는 운영환경에 출시하기 전에 충분하게 테스트를 했다고 IT조직이 믿는데(또는 믿고 싶은데) 근거한다.

정말 프로그램들은 믿을만한가?

사용자들도 자신들이 사용하는 프로그램이 안전한 방법으로 처리되어 결과를 제공하는 것으로 믿고 싶어한다. 그러나 IT에 종사하는 사람들은 IT조직의 수준에 따라 프로그램 신뢰도가 천차만별이라는 것을 알고 있으며, 함량 미달의 프로그램들로 인한 문제점들을 직간접적으로 경험해 오고 있다.

■누더기 프로그램의 출현

국내 대부분의 IT조직들은 개발자 이외에는 프로그램 소스를 들여다 보지 않는 경향이 있다. 프로그램에 대한 테스트조차도 만들어진 프로그램을 이것 저것 클릭해보면서 사용자 입장에서 ‘작동’되는 지를 확인하는 데 그치는 경우가 많다.

오래 사용돼 온 프로그램들 중에는 사용자 입장에서 작동은 되지만 처리 속도가 유달리 느리거나 뭔가 이상하다는 느낌을 주는 프로그램들이 있다. 특히 사용자 업무의 잦은 변경으로 빈번하게 프로그램 수정이 일어난데다, 개발자가 자주 바뀐 경우 미심쩍은 프로그램이 발생할 가능성이 높다.

이런 프로그램의 소스를 들여다보면 ‘누더기’ 프로그램임을 발견할 수 있다. 누더기 프로그램이란 장황하게 긴 프로그램 소스 목록을 가지고 있다. 이에 개발자는 어떤 의도로 소스를 만들었는지를 타 개발자가 이해하기 어렵고, 이런 이유로 후임 개발자는 프로그램의 전체적인 맥락을 파악해서 수정하는 것이 아니라 임시방편으로 전임 개발자의 기존 소스에 덧대는 방식으로 유지해 온 프로그램들을 지칭한다.

■누더기 프로그램의 이면

누더기 프로그램은 IT조직의 바람직하지 못한 개발 관행의 폐해를 고스란히 담고 있다. 프로그램은 개발자의 개인 소유가 아님에도 불구하고, 프로그램을 만든 개발자 이외에는 프로그램을 이해하기가 매우 어렵다. 개발자가 평생 자신이 만든 프로그램을 돌보는 것이 아니라면 기본적으로 프로그램은 인수인계가 가능해야 한다.

그러나 상당수 IT조직에서는 프로그램을 개발하면서 지켜야 하는 개발 원칙이 없거나 불분명한 경우가 많다. 프로그램 소스의 한 줄 한 줄은 나름의 이유가 존재한다. 개발원칙과 같은 서로의 약속이 없다면 수 백 줄 이상으로 자라나게 되는 프로그램 소스에 대해, 어떤 요구사항을 기반으로 개발자가 소스를 만들어낸 것인지를 파악하는 것은 매우 어렵다. 후임 개발자가 퇴직한 개발자들을 계속 귀찮게 하는 것도 이러한 상황 때문에 발생한다.

■개발 자원과 시간의 부족

IT조직 내에 누더기 프로그램을 탄생하게 만드는 이런 상황은 당연히 개발자의 잘못이 아니다. 해당 프로그램을 담당하는 개발자 이외에는 프로그램 개발 프로세스 내에서, 프로그램 소스를 열어서 검토할 수 있는 능력을 가진 사람을 배치하지 못하는 IT조직의 비용 문제가 그 원인 중 하나다.

타인이 만든 프로그램 소스를 검토하기 위해서는 충분한 개발 경력을 갖춘 개발자가 필요하다. 그러나 이런 개발자를 프로그램 소스를 검토하는 데 전적으로 투입하는 것은 과다한 투자라고 생각하는 경향이 IT조직에 존재한다.

시간이 부족한 것도 누더기 프로그램의 존재를 유지하게 만드는 원인이다. 적정한 수준을 가지는 프로그램을 만들기 위해 소요되는 시간을 무시하고 철야를 불사하며 개발자를 밀어붙이는 IT조직에서는 양질의 프로그램을 기대할 수 없다.

■개발 프로세스의 한계

IT조직의 프로그램 개발 프로세스는 ‘사용자요청->승인->소스코딩->테스트->승인->운영이관’의 순서를 기본으로 한다. IT조직의 규모나 특성에 따라 프로그램 개발 프로세스를 좀더 복잡하게 또는 요약된 형태로 운영된다.

프로그램 개발 프로세스를 얼핏 보면 역할 및 책임이 분리돼서 프로그램이 잘 관리되는 것처럼 보이지만, 실제로는 소스코딩 이후의 전 단계에 있어, 프로그램 소스의 내용은 개발자 혼자만이 독점하고 있는 경우가 많다.

승인이나 테스트 과정의 검증은 프로그램의 정상적인 작동에만 초점을 맞추어서 확인하는 관계로, 프로그램 소스 자체의 품질을 들여다 보는 ‘디테일’까지는 접근하지 못하고 있다는 것이다.

■프로그램 소스와 보안

프로그램 소스는 IT조직이 가지고 있는 보안의 ‘아킬레스건’이다. 대부분의 IT조직은 보안을 강화하기 위해 서버, 네트워크 및 데이터베이스 부분의 보안솔루션 도입에 투자를 집중하고 있다. 하지만 개발자가 프로그램 내부에 나쁜 의도의 소스를 삽입하는 경우와 같이 프로그램 소스 차원에서의 악의적인 행위에 대해서는 특별한 대응방법이 없는 실정이다.

보안 측면에서 프로그램 소스 차원의 악의적인 행위를 차단하기 위해서는, 개발자가 작성한 프로그램을 소스 수준까지 들여다 보고 한 줄 한 줄의 소스가 정당하다는 것을 확인한 이후에만 운영환경에서 사용할 수 있도록 허용해야 한다.

하지만 국내 IT조직은 대부분 프로그램 소스를 들여다 보고 있지 않고 있으며, 더 심각한 문제는 개발자에게 개발환경과 운영환경 모두를 접근할 수 있도록 허용하고 있다는 점이다. 나쁜 의도를 가진 개발자에게 이러한 상황은 완전 범죄를 보장해준다.

나쁜 의도를 가진 개발자는 사용자가 프로그램 화면상에서 볼 수 있는 부분을 프로그래밍한 다음, 사용자들에게는 특별한 리액션이 없고 몰래 작동하는 프로그램 소스를 추가로 프로그래밍할 수 있다. 개발자는 혹시라도 프로그램 소스 검토를 할까 봐 승인 받을 때는 사용자가 요청한 부분만 포함된 프로그램소스에 대해서 승인 요청을 할 수 있다.

개발환경과 운영환경 모두를 접근할 수 있는 개발자는 승인 이후에 몰래 작동하는 프로그램 소스가 포함된 다른 버전의 프로그램을 운영환경에 올리면 그만이다. 누가 알겠는가? 추후에라도 승인 프로그램이 운영환경의 프로그램과 동일한 것이라는 것을 검증하는 IT조직은 거의 드물기 때문에 이러한 시도가 적발될 가능성은 거의 없다.

■프로그램 소스 검토의 혜택

IT조직은 누더기 프로그램이나 보안의 문제를 해결하기 위해서는 프로그램 소스 검토 활동을 일상 활동으로 정착시켜야 한다. 프로그램 소스 검토 활동을 수행할 여유 개발자가 없다면 옆의 동료 개발자가 검토하도록 하는 방법이라도 적용할 필요가 있다.

프로그램 소스 검토 활동이 일상화 되면 IT조직은 누더기 프로그램 제거와 보안 문제의 해결뿐만 아니라 여러 가지 추가적인 이득을 얻을 수 있다.

첫 번째는 프로그램 개발자의 개발 능력이 급격하게 향상된다.

사실 개발자는 혼자서 터득한 방법으로 프로그램을 만들어왔다. 그러나 다른 개발자의 프로그램 소스를 검토하는 과정에서 본인이 해왔던 프로그램 기법이 완전하지 않다는 것을 깨닫게 되고 다른 개발자의 좋은 프로그래밍 기법을 벤치마킹 하게 된다.

두 번째는 프로그램 자체의 품질 수준이 높아진다.

제조업의 경우, 과거 장인의 능력에 의존해서 제품을 만들던 시절에는 장인의 반발로 인해 장인이 만든 제품을 다른 사람이 평가하는 활동이 불가능했다. 장인이 독자적으로 만든 제품은 장인의 컨디션에 따라 품질이 들쭉날쭉 할 수 밖에 없었고 이것은 제품의 전반적인 품질을 저하시키는 원인이 되었다. 국내 제조업의 경우, 제품에 대한 품질 평가를 독립적으로 평가하기 시작하면서부터 제품의 품질이 좋아지기 시작했고 현재는 글로벌 최고 수준을 유지하고 있다.

IT조직이 동료나 제3자에 의한 프로그램 소스 검토 활동을 정착시킨다면 양 쪽의 건전한 긴장 관계로 인해 프로그램의 품질 수준이 현격하게 높아지는 것을 경험하게 된다.

세 번째는 프로그램의 장애가 줄어든다.

프로그램 소스 검토 활동이 일상화되면, 여러 개발자를 거친 프로그램일지라도, 프로그램 소스에 대한 설명이나 로직이 명쾌해지기 때문에 프로그램의 수정을 자신 있게 할 수 있다. 프로그램 수정이 일어나는 부분이 다른 프로그램이나 IT구성요소에 어떤 영향을 미치는지를 파악하기 쉽기 때문에, 프로그램으로 인한 오류나 장애가 현격하게 줄어든다.

■프로그램 소스에 대한 관심 필요

국내 IT조직들이 IT수준을 높이기 위해 많은 노력을 하고 있다는 것을 알고 있다. 하지만 그런 노력들 속에는 프로그램 소스에 대한 관심이 포함되어 있지 않다는 것을 느끼고 있다.