스타트업, 품질책임은 누가?
스타트업의 소프트웨어와 서비스 품질에 대한 끄적거림...
스타트업의 생존에 가장 중요한 소프트웨어의 품질에 대해서 이야기를 시작해보자.
스타트업의 모든 역량은 소프트웨어와 그것을 기반으로 한 서비스의 안정적인 동작으로 모든 것이 표현된다. 모든 소프트웨어는 단계별로 개발되고 빠르게 개발되기 위해서 기술적 부채가 쌓이게 된다.
가장 첫 버전이거나 시리즈 A의 투자를 받기 전까지는 아이디어를 빠르게 구현하는 것에 모든 것이 집중되므로 엄청난 기술적 부채로 인해서 서비스가 동작된 이후에 빠르게 소프트웨어를 거의 대부분 재개발하는 것이 매우 당연하게 된다.
아이디어가 구현되고 만들고 있는 소프트웨어의 품질요소에 대해서 누군가는 관리하고, 누군가는 체크하고, 누군가는 기술적 부채의 리소스 자산관리를 취급해야 한다.
소프트웨어 개발현장에서는 소프트웨어를 끊임없기 개발하고, 그 개발되어진 소프트웨어와 서비스에 대한 품질에 대해서고 끊임없이 체크하는 것은 정말 당연한 일이다. 그리고, 필자처럼 경험이 풍부하다고 하더라도, 실제 프로젝트의 일부분에 관여해서 프로젝트를 깔끔하게 마무리하거나 부드럽게 진행시킨다는 것은 정말 매우 어렵고 힘든 일이라고 할 수 있다.
더군다나, 대부분의 프로젝트들은 시간상의 문제나 기획상 부족한 점들이 계속 드러나게 되는데다가, 개발자의 능력 부분의 문제까지 매우 다양한 변수들이 존재한다. 이런 매우 다양한 문제점들이 발생되어지는 상태에서 소프트웨어 개발일들은 계속 진행되어진다.
대부분의 소프트웨어 공학이나 개발 방법론, 요즘 대두되고 있는 소프트웨어 시각화와 같은 이슈들의 핵심은 문제를 도출하고, 그 문제를 어떻게 해결할 것인지를 인지하고 인식하게 하는 것부터 출발한다. 그리고, 대부분 이런 문제들이 진행이 잘 안 되는 이유는 대부분의 개발 조직이 가지고 있는 시스템상의 문제이거나, 다른 이유 때문에 발생할 수 있다는 것을 미리 전제하여야 한다.
하지만, 소프트웨어의 품질 부분은 계속되는 문제를 일으키는 것은 매우 당연한 것처럼 발생되어지고, 이런 문제들은 언제나 개발 조직에게 계속되는 이슈를 제기하게 된다. 이렇게 계속되는 문제점들, 계속되는 문제 상활들에 있어서, 이러한 소프트웨어의 품질 부분에 대해서 과연 누가 책임져야 하는 것일까?
보통, 성공적인 소프트웨어 개발을 하는 경우에 몇 가지 원칙이 있다. 그것은 소프트웨어 개발을 성공적으로 만드는 매우 중요한 원칙들의 하나이다. 특히, 리더가 되는 경우에는 다음과 같은 부분들을 최대한 조절하는 것들은 매우 당연한 것이고, 이러한 것들에 대해서는 계속적인 관심을 보이게 된다. 그것을 몇 가지 살펴보면 다음과 같다.
1. 소프트웨어 개발시에 필요한 요구사항이 계속 변화하는 것을 어떻게 대응할 것인가?
2. 어떻게 하면 소프트웨어 개발자들이 특정 부분의 반복적인 작업을 어떻게 가능한 최소화 할 것인가?
3. 사용자가 요구한 기능보다 좀 더 효과적으로 소프트웨어를 개발하는 방법은 어떤가?
요구사항에 꾸준하게 대응하고, 특정 부분의 반복 작업을 방어하고, 좀 더 개선된 방향으로 소프트웨어 개발을 이끄는 것, 그것이 프로젝트 리더가 해야 할 일중 가장 중요한 일들이다.
하지만, 소프트웨어 개발시에 이러한 목적과 방향성은 많은 부분에서 가장 극심한 것은 사용자의 변덕과 요구사항의 변덕스러움이다. 심지어 별거 아니라는 이유로 화면상에 표시되는 문구와 색상을 변경하는 것을 상시 요구하는 것은 어찌 보면 매우 당연한 것일 수 있다.
물론, 이 경우에 소프트웨어 개발의 리더는 개발자들에게 이 수정 작업이 시스템과 소프트웨어의 품질을 향상시키고, 고객이나 사용자들에게 매우 의미 있다는 메시지와 신호를 계속 전달하여야 하는데, 대부분 어느 정도 시점에서 이것들을 포기하게 되는 경우가 있게 된다는 점만 주의한다면, 대부분의 개발 조직의 리더들은 이 부분에 대해서 버퍼링을 가장 확실하게 하는 편이다.
또한, ‘설계’ 작업이라는 기간 동안에 일어나는 무수한 변동들은 ‘종이’상에서와 ‘개념’상으로만 변경되는 요소이기 때문에, 가능한 이 작업과 ‘기획’ 작업이 진행되는 상황에서 가능한 많은 부분을 처리하는 것이 좋다.
소프트웨어 개발 조직의 문제와 시스템의 문제는 어떻게 인지해야 하는가?
PM이나 PL이나, 보통 경험이 풍부한 사람들은 새로운 조직이나 새로운 프로젝트, 새로운 사람들과 만나면 관련된 업무의 진행방법이나 소통방법에 대해서 초기에 협의하거나 그 단어의 의미에 대해서 긴밀하게 이야기를 나누지 않으면 매우 힘든 상황들을 경험하게 된다.
특히, 영업이나 프로젝트를 기획하는 파트에서 서비스나 소프트웨어의 개발 부분에 대한 이해능력이 조금 떨어지는 경우에는 이러한 단어의 선택이나 의미가 매우 중요해진다. 초기의 요구사항을 도출하고 그 완성 형태에 대해서 어떠한 방법으로라도 기술해야만 이 부분에 대해서 작업 후반부에 이질적인 상황이 발생하지 않는다.
소프트웨어 개발 조직이 효과적으로 동작될 때에는 이 부분에 대해서 누가 통제를 하는 것이 아니라, 시스템이 이 부분을 커버하고 있거나, 이 부분에 대해서 인지하고, 시스템이 이해당사자들에게 이 정보를 꾸준하게 제공해주는 방법을 제공해야 한다.
시스템의 요구사항과 완성 형태에 대해서 개발 조직과 이해당사자들에게 어떻게 시각화되어져서 보이며, 그 상황들에 대해서 기술하고 있는지, 그리고. 그 목적에 맞도록 개발이 진행되고 있으며, 일정이나 다른 리소스 상의 문제가 없는지에 대해서 꾸준하게 보여야 한다.
하지만, 대부분 이러한 상황들은 완성 형태에 대해서 이질적인 서로의 이해도 때문에, 그 결과를 예측하기 어려운 상황으로 빠지는 경우가 있다. 특히, 완성 형태에 대해서 구체적인 모습을 서로 간에 이해를 같이 하고 있지 않는 경우가 대부분이고, 이런 부분들 때문에, 실제 소프트웨어 개발 조직에서는 후반부에 이 문제 때문에 격론을 벌이게 된다.
보통, 이러한 완성 형태에 대해서 소프트웨어 개발 조직은 PM(Product Manager)라는 담당자가 그 부분을 통제한다. 프로덕트의 완성 형태를 생각해서 전체적인 상황을 이끄는 것이다. 하지만, 이 역할이 부재하거나, 개발자에게 이 기능이 내려가는 경우에는 소프트웨어 개발시에 시각화되는 부분이 극소로 변해버리거나, 초기에 Task하나만 존재하던 것이 막판에 서브 시스템 이상의 것으로 거대화 되는 경우가 비일비재한다.
이러한 것은 PM의 기능적인 요소가 하위나 개발 조직으로 내려가게 되면, 은연중에 개발시에 들어가는 공수나 일정에 대해서는 조금은 야박하게 평가하면서도, 눈에 띄는 기능이나 주된 기능들에 비해서 저평가되는 경우가 많다.
그리고, 기술적인 요소라고 평가를 받지 못하는 요소의 경우에도 이러한 경우가 있다. 또한, 개발자가 현재 인지하고 있는 개발의 방법이나 시스템적인 상황에 대해서 일부 유도하고 있는 방향으로 시스템 개발을 이끌면서 이러한 부분들이 극대로 평가받게 되고, 주도적이지 않거나, 신경 쓰지 않는 업무와 기능들은 작은 Task의 하나의 형태로 존재하게 되는 경우가 비일비재한다.
물론, 이러한 것들을 해결하기 위한 다양한 기법들이 있으니, 이를 차용하면 좋겠지만. 현재처럼 고속 개발과 적은 팀원들이 움직이는 개발 방법론과 환경에서는 이러한 기법들을 모두 해당 조직에서 체크하기 매우 어렵게 된다.
작은 개발팀을 지속적으로 유지시키고, 효과적인 팀으로 꾸려가려면, 가능한 기획단계에서 이런 부분에 대해서 충분하게 체크하고, 세부적인 부분에 대해서 ‘시각화’된 방법으로 개발 조직이 인지할 수 있게 해야 한다.
이 부분에 대한 전파가 잘못되거나 완성된 제품의 형태에 대해서 제대로 인지시키지 못하면, 현재의 고속 개발 방법들의 대부분은 실패하게 되거나, 의미 없게 된다. 당연한 것이겠지만. 우연하게 뛰어난 능력의 소유자이거나, 현재처럼 손쉬운 소프트웨어 개발이 가능한 시대에서는 생각 이상으로 소프트웨어를 고속으로 개발하면서, 뛰어난 품질을 유지하는 경우도 많다.
당연한 것이지만, 실제 소비자나 고객이 원하는 서비스의 형태로 나오지 않아서, 기능은 동작하지만 아무도 사용하지 않는 서비스를 만드는 경우는 당연하게도 실패한다.
소프트웨어 개발의 품잘 문제는 누가(Who) 책임져야 하는가?
위에서도 여러 가지 언급하였지만, 대부분의 문제들은 시스템에 드러나며, 그 시스템을 만들고 유지하는 내부 조직의 다양한 문제들이 악순환되면서 하나의 문화로 정착되어진 경우를 종종 볼 수 있다. 이는 대기업의 형태이건, 중소기업이나 스타트업이건 나름 내부의 형태로 어떻게든 정착되어진다. 물론, 이러한 문제들이 없는 아주 깔끔한 조직이나 프로세스가 만들어지면 얼마나 좋을까라고 생각하겠지만. 그러한 환경을 만들기 위해서 필요한 리소스는 상당히 크다는 것을 잊지 않으면 좋겠다.
언제나처럼 적당한 시스템을 만들고, 그 시스템을 보완할 수 있는 형태를 갖추는 것이 가장 효과적이라고 할 수 있다. 이 경우에 시스템을 통제하거나 통제를 하려는 사람에게 중요한 것은 ‘책임’을 지는 것이고, 그 책임에 맞추어서, 가장 최선의 시스템을 구성할 수 있게 하는 것이다.
가장 중요한 것은 시스템의 문제를 확인하고, 그 확인된 문제를 통해서, 더 진보할 수 있는 방향으로 점진적으로 변화하고 있다는 것을 이해당사자들에게 모두 전달할 수 있는 시스템이 되어야 한다. 하지만, 이러한 ‘진보’가 실패하는 경우에는 결국, 대형사고를 만들게 되고, 그 대형사고는 그러한 환경을 만들지 못했거나, 품질관리에 실패한 경우라고 생각하면 된다. 대부분의 조직들은 대형사고들이 터지면, 해당 대형사고를 통해서, 시스템이 개선될 수 있도록 고민하고, 그 해결책을 찾는 것에 상당 부분 리소스를 투입한다.
대부분의 문제들은 그 문제가 중첩되어졌거나, 그 문제를 일으킬 수밖에 없는 원인들을 알 수 있게 한다. 이미 문제가 생겼다면, 그 문제를 최대한 조직에 효과적이고 효율적인 환경을 만들 수 있는 배경지식으로 활용하는 것이 그 문제를 해결하는 첫 번째이다. 그러므로, 대형사고가 발생하거나 문제점이 발생하면, 그 문제를 올바르게 인식하는 것부터가 첫 번째 해결방법의 주된 키워드이다. 다음의 유명한 미국의 사례를 예를 들어서, 시스템적인 문제가 발생하였을 경우의 대처상황을 예시로 알아보자.
미국 공항 관제사의 졸음 근무가 벌어진 이후에 미국의 시스템이 어떻게 바뀌었는지 보자.
2011년 4월 15일 국내 방송사의 뉴스 코너에서 이야기가 나온 간단한 기사를 간단하게 소개하면 다음과 같다. ‘공항 관제사들이 한밤중에 조는 바람에 항공기가 착륙 안내를 받지 못하는 일이 빈번하게 발생하였고, 응급 항공기가 착륙 유도를 받지 못하는 사고도 있었다. 새벽 2시의 미국 네바다 주의 리노 국제공항에서 일어난 일이다.
-조종사 : 리노 관제탑, 샤이언 라이프가드 20TN항공기다.
응급환자를 태운 이 항공기는 긴급 착륙을 요청하지만 관제탑은 묵묵부담이었다. 이에 무선을 듣고 있던 다른 공항의 관제사가 대신 전화연락을 취하지만, 이 내용에도 아무런 응답이 없다.
-LA관제사 : 우리가 그 관제탐에 전화해 보겠다.
-조종사 : 중환자가 타고 있어 어쨌건 착륙을 해야겠다.
이런 관제사의 졸음으로 인한 사고가 2011년에 교신 중단이 되는 사고가 6건이나 발생하였다는 이 사고에 대해서, 당시 라우드 미 교통장관은 다음과 같이 이야기한다.
‘말도 안 되는 일입니다. 이 같은 행동을 용납하지 않겠습니다’.라는 이야기와 함께, 미 전역의 관제를 책임을 지고 있는 연방항공청의 책임자는 매우 당연하게 사퇴하게 되고, 업무의 부담과 실수를 줄이기 위해서 관제탑의 야간 근무자를 2명으로 늘리게 된다.
실수를 통해서 시스템이 개선되는 사례는 미국과 같은 선진국에서는 매우 당연한 결과이다.
이 사건의 내용을 조심히 살펴보면, 가장 중요한 것은 시스템과 프로세스에 대한 내용이며, 이러한 시스템과 프로세스를 관리하고 정책을 결정하는 일에 대한 책임감과 중요성에 대해서 얼마나 인식하고 있느냐의 문제이다.
이런 문제에 가장 큰 책임을 져야 하는 것은 그런 정책과 결정 과정을 만들고, 유지하는 사람들의 몫이라는 것이다. 물론, 이와 유사한 사례의 사고도 몇 건 더 있었다. 리노의 사건 이후에도 발생한 미국 마이애미 공항에서 관제사가 깜빡 잠드는 사례가 있었으나, 당시 12명의 관제사가 함께 근무 중이었기 때문에, 별다른 사고가 없었고, 그 문제의 관제사에게 정직처분이 내려졌다는 것이다.
앞서 이야기한 사건 때문에 FAA에서 관제시스템의 운영방식의 전반적인 재검토작업을 통해서, 관제사 노조 측은 수면부족과 과로로 인해 문제가 발생하고 있다는 점과, 야간 교대 근무일 정의 조정이 필요하다는 주장도 같이 이어졌지만, 가장 중요한 것은. 단 한 명의 야간 관제사만 근무하게 되면 대형사고를 발생시킬 수 있다는 점을 시스템에서 대응을 하지 않았고, 이를 금지하지 않았기 때문에, 미국 네바다주 리노에서는 사고가 발생할뻔한 것이다.
당연한 것이지만, 이런 경우에는 이 문제를 사전에 예측하지 못한 시스템의 총괄 책임자가 그 책임을 지는 것은 매우 당연하다.
하지만, 이러한 식의 책임을 지는 곳은 ‘시스템’을 계속 업그레이드하거나, 발전적인 방향으로 시스템을 진화시킬 수 있다. ‘문제’가 발생되는 이유와 근본적인 부분에 대한 대응책을 마련하기 때문에, 한 번의 실수를 통해서 시스템은 언제나 보완되어갈 수 있기 때문이다.
하지만, 한국에서 KTX 3중 추돌 사건이나 세월호 사건을 생각해보자.
결론만 이야기하자. 뉴스에 발표된 내용을 참고로 한다면, ‘대구역을 통과하는 서울행 KTX를 무궁화호 열차가 출발 신호보다 빨리 운행하면서 서울행 KTX측면을 접촉해 선로를 이탈시켜 하행선 KTX와 접촉한 사고’라고 공식적으로 발표가 되었다.
관제실, 기관사, 여객전무 등 ‘3각 체제’가 부실했을 가능성과 신호체계의 오류 가능성을 염두에 두었다고 한다. 하지만, 철도 운행에는 최소 4단계 이상의 안전조치가 규정되어 있으며, 중앙관제실의 자동 전산 제어시스템, 대구역 관제실의 제어시스템, 출발 신호기, 여객전무의 수신호와 무전, 기관사의 확인 및 복명의 절차와 프로세스가 있다고 한다.
그런데? 왜 사고가 발생하였을까?
가장 큰 문제는 비숙련 대체 투입인력이라는 것에 대해서 먼저 이해하고, 시스템적인 문제에 대해서 생각하자. 이와 같은 사고의 핵심이 인재에 있건, 시스템의 구조적인 문제이건, 하다못해 테러라는 이야기까지 공통점을 하나 체크하자면, 그것은 시스템에 대한 부분에 검증 부분이 허술했다고 이야기할 수 있다.
드러난 몇 가지 사실 들을 나열해본다면, ‘매뉴얼’을 무시해서 일어난 사고라고 생각할 수 있다. 지난달에 스페인에서 고속열차의 탈선사고 또한 이러한 기본적인 매뉴얼을 제대로 지키지 못했기 때문에 대부분 발생한다.
당연하지만, ‘인재’가 발생되거나 ‘인적과실’이 발생하는 경우에 가장 중요한 것은 ‘시스템’과 ‘서비스’, ‘인프라’에 그 책임을 일차적으로 물어야 한다. 그런 상황을 발생시키게 근로자를 제대로 교육하지 않았거나, 숙련된 전문인력을 제대로 배치하지 못하였거나, 관련 프로토콜의 오류나, 점검이 되어야 할 테스트 케이스가 부족해서 발생한 것이거나. 특이사항에 대한 대처가 되지 않았던 것이기 때문에, 1차적으로 ‘담당자’에게 책임을 묻기 이전에, 시스템을 관장하고 운영하는 책임자가 그 책임을 지어야 한다.
스페인 산티아고 고속열차 탈선사고와 문제점도 같이 살펴보자.
스페인 산티아고 데콤프 스텔라에서 발생한 사고 뉴스를 살펴봐도, 분명. 전적으로 기관사에게 책임이 있을 수 있지만, 이런 사고가 발생하지 않도록 많은 안전 대책 매뉴얼과 시스템이 제대로 작동하지 않았다고 평가를 해야 한다. 이런 심각한 상황에 대한 모든 책임을 ‘기관사’에게 부여하는 것은 매우 무책임한 행동 아닐까?
기사에 언급되었던 대로 시속 80킬로미터 주행구간에서 190킬로미터로 주행했다고 하는데, 만일 해당 기차 시스템에서 그런 부분을 제대로 파악해서, 시스템이 보호했다면, 이런 사고는 아예 일어나지 않았을 것 아닌가? ( 누가 해당 시스템의 구간단속 부분에 대해서 허가한 것이고, 소프트웨어 품질 요소를 평가한 것일까? )
당연한 것이지만, 현대의 최신 소프트웨어와 시스템들은 대부분 엄청 복잡하다. 당연스럽게도 인간의 한계에 대해서 제대로 인식한 형태로 디자인되어야 한다. 결론적으로 스페인 시스템은 비록 80킬로미터 제한 구간임에도 불구하고, 최대속도 200킬로미터 이하에서는 ‘인간’이 그 부분을 제어해야 하는 어처구니없이 황당한 시스템을 만들고 허가를 준 것 아닌가 한다.
결론은 간단하다. 80킬로미터 구간을 설계하고 허가한 당국도 책임을 지어야 하며, 해당 구간에서 속도를 자동으로 체크하거나 조절할 수 있는 시스템을 설계하고 만들지 못한 제작사도 책임져야 하며, 이런 전체적인 부분을 감리하지 못한 감리기관도 책임져야 하고. 더 중요한 것은 이런 상황에서 기차를 운행하게 한 관리당국 또한 책임을 져야 한다.
단언컨대 인간의 실수만으로는 사고는 발생하지 않는다. 하지만, 인간의 실수를 방어하기 위한 안전장치들이 있어야 하며, 이런 것에 대해서 시스템에 반영하지 않는 것들에 대해서는 시스템의 책임자들은 인지하고 그 안전장치들을 만들어야 한다. 하지만, 가장 안전에 신경을 많이 쓰고 있는 유럽에서 벌어진 일이기에, 도대체 이런 사고가 왜 발생하였는가는 정말 의아하다.
필자가 유럽여행 중에 느꼈던 안전에 대한 경험
필자가 유럽에 산업 계분들과 같이 시장개척단으로 유럽에서 프랑스를 갔을 때의 경험이다. 관광버스를 대여하여 운행을 하였는데, 관련 일정이 수정되면서 방문하려는 지역이 변경되었을 때에, 해당 관광버스의 운전기사는 거리가 멀어지고 운행시간이 길어진 것에 대해서 매우 난색을 표명했다.
그것은, 관광버스의 운행시간이 하루 6시간으로 제한되어 있으며, 해당 기록은 관광버스의 블랙박스를 통해서 통제받으며, 더 이상 운행할 수 없다고 하였다. 그래서, 필자의 일행들은 별도의 다른 버스를 임대하여 운행을 했던 기억이 있다.
이처럼, 안전이란 ‘프로세스’를 얼마나 철저하게 지키느냐의 관점이다.
소프트웨어 개발에서 꼭 필요한 시스템과 서비스가 없는가?
현재의 소프트웨어 개발과 관련된 프로세스들은 생각 이상으로 자동화가 되어 있고, 꽤 많은 시스템들이 공개 소프트웨어로 만들어져 있다. 현재 내가 속한 기업과 조직이 다음과 같은 환경을 갖추고 있는지 확인해보자. 아래에 나열한 시스템이 빠져있거나, 구성되어 있지 않고, 그러한 시스템을 구축하려 준비나 계획도 없는 기업이라면 해당 기업은 소프트웨어 개발에 있어서 품질이나 책임에 대해서 명확하게 구분할 능력도, 그럴 마음도 없는 기업이라고 예측하기 좋다.
하나. 소프트웨어 개발은 하는 버전 컨트롤도 하지 않는다
소프트웨어 개발회사에서 가장 귀중한 자원은 ‘소스’이다. 그 ‘소스’를 어떻게 관리하고, 대우하느냐가 가장 중요한 것이라고 생각하는 것은 매우 당연한 것이지만, 생각 이외로 이러한 ‘소스’를 제대로 된 시스템에서 관리하지 않는 기업이 많다.
‘소스’를 제대로 관리하지 않는다면, 그 ‘소스’를 개발하는 개발자들에 대한 대우나, 처우는 얼마나 엉터리 인 것인지 잘 알 수 있을 것이다. 그리고, 대부분 기업은 하나의 서비스나 설루션에 집중하는 경우가 많은데, 이러한 ‘버전 컨트롤’을 하지 않는다는 것은, 그러한 ‘지식’과 ‘경험’을 제대로 관리하지 않는다는 것이고, 결론적으로는 상품이나 서비스를 개발하는 회사가 아니라, 전형적인 ‘SI’에 집중하거나, 당장의 돈벌이에 집중하는 회사일 가능성이 매우 높다.
둘. 자동으로 빌드하고, 자동으로 테스트하는 시스템이 있는가?
대부분의 자동화가 가장 효과적으로 그 능력을 발휘하는 경우는 요즘과 같은 환경에서는 자동으로 빌드하고, 자동으로 테스트하는 환경을 구축하는 것이다. 필자가 보기에는 개발자의 업무 중의 20% 정도는 이러한 빌드와 테스트하는 시간에 상당 부분 반복적인 작업을 할당하여 사용하고 있다.
개발자들을 우대하고, 개발자들의 리소스를 귀중하게 생각하고 있다면, 개발자들이 반복적으로 투여하고 있는 업무를 어떻게든 자동화하는데 집중하는 것은 매우도 당연한 것이다.
셋. 전체적인 소프트웨어 개발을 모니터링하고 있는가?
현재의 단계, 문제가 있는 상황. 그리고. 개발자들 간의 소통과 경험들, 고객과의 업무나 지시, 요구사항들에 대한 내용들이 단편적인 종이들과 개개인의 기억에 의존하는 경우인가를 확인해보면 된다. 전체적인 모니터링을 하지 않는다는 것은, 각각의 업무에 대해서 통제도 불가능하고, 업무의 기능별 분화나, 업무들을 공동 작업하는 상황들을 만들기도 매우 어렵다.
넷. 테스터의 롤이 별도로 있거나 테스팅 환경을 구축하고 있는가?
특정한 사람이 있거나 하는 것이 아니라, 소프트웨어 개발은 개발자가 테스트를 하면, 버그를 찾기 매우 어렵다는 점이다. 자신이 코딩하였기 때문에 해당 룰로만 테스트를 진행하고, 의미 없는 테스트 시간만 허비하는 경우가 많다. 가장 잘되어있는 조직은, 크로스 체크를 하는 테스팅 규칙이거나, 테스팅의 업무의 중요성을 잘 알고 있는 경우이다.
다섯. 버그 트랙킹 시스템을 구축하고 있는가?
문서화의 척도나, 소프트웨어 개발회사의 이슈, 버그 등의 상황들을 전체적으로 관리하고 있느냐와, 관리하고 있지 않느냐의 차이는 정말 크다. 특히, 관리자의 경우 이런 문서화나 시스템이 존재하지 않게 되면, 실질적인 통계나 환경에 대한 정보보다는, 개인적인 감에 의해서, 시스템의 프로세스나 경험을 반영하는 경우가 많아지게 된다.
그리고, 개발자들 간에도 서로 간에 유의미한 대화나, 경험들이 축적되게 된다. 또한, 버그가 발생되어지고, 버그를 수정하는 과정들이 투명하게 되면서, 해당된 정보들에서 파생되는 지식과 경험들을 더 많이 얻게 된다.
이상의 과정들의 기본도 갖추고 있지 않는 회사라면, 특정 문제가 발생하였을 때에 그 원인을 추적하거나, 그 문제를 알기 위해서는 별도의 작업을 수행해야 하고, 실제 조직원들이 그 문제를 찾기도 어렵다. 대부분의 제대로 된 기업과 조직은 이러한 문제들을 방어하기 위해서 프로세스나 업무를 시각화하려고 하는 것이고. 그 시도를 통해서, 프로세스를 개선하려 한다.
마지막으로 소프트웨어 개발의 책임은 누가 질 것인가?
소프트웨어 개발에 있어서, 성공적인 소프트웨어가 개발되어지는 것 이외에, 실패를 하게 되었을 때에 소프트웨어 개발에 대한 책임은 누가 져야 하는가? 결국, 책임은 이해당사자들 모두가 지게 되지만, 가장 큰 책임을 지게 되는 것은, 그 소프트웨어의 프로덕트를 요구했으나, 제대로 된 제품을 받지 못하게 된 고객이 가장 큰 책임을 지게 될 것이다.
제대로 된 시기나 제대로 된 제품이나 서비스를 받지 못하게 되는 것이 가장 큰 책임이다. 대부분의 소프트웨어들은 이런 고객들에게 최대한 서비스나 제품들이 효과적으로 개발되고 수행되고, 서비스되는 가에 대해서 끊임없이 경고하고, 정보를 제공해주는 방법들을 얼마나 많이 시각화하느냐에 집중되어져 있다.
소프트웨어의 개발시에 시각화는 이런 부분들을 전반적으로 포괄하고 있다. 소프트웨어의 품질은 꾸준하게 요구사항에서 발생되어질 문제와 최종 제품의 모습을 어떻게 상상하고, 그것을 대응할 것인가에 대해서 계속적인 활동을 하는 것이다.
소프트웨어 방법론이나 필요한 수많은 기능들과 체크하는 방법들은 이러한 것들을 어떻게 게 효과적으로 진행하면 가능한 것인가에 대한 수많은 테스트 자료일 뿐이다.
최종적으로 이야기하자면, 소프트웨어 개발이 실패한다면, 그것에 대한 책임은 그 소프트웨어를 개발한 모든 사람에게 있는 것이라는 점이다. 가장 훌륭한 소프트웨어 개발 조직은 똑같은 실패를 다시 경험하지 않는 것이다.
문제가 있는 상황을 인지하고, 그 상황을 해결하고, 그 상황을 변화시키려는 조직은 언제나 유기적이고, 유동적으로 그 문제를 해결할 수 있게 한다. 다만, 내가 속한 조직이 그러한 방향으로 진화하고 있는 조직인지? 그러한 문화나 방향성을 이해하고 있는 조직인지에 대해서는 또 다른 고민을 하게 할 것이다.
소프트웨어 개발의 가장 근본적인 원칙은 ‘특정 형식에 얽매이는 행위야 말로 삽질이다’라는 말로 이번 이야기의 마무리 말로 정리하겠다.
