직원들이 당신의 소프트웨어를 싫어하는 11가지 이유

테스트가 부실하다
엔터프라이즈 소프트웨어 테스트는 힘든 도전과제이다. 개발자와 나머지 직원이 동떨어져 있을 때 더 복잡한 도전과제가 된다. 꽃꽂이, 정육, 애완견 사료 제조 등 비즈니스는 다양하다. 스케줄 관리 소프트웨어나 내부 데이터베이스를 만드는 사람들은 다른 직원들이 하는 일에 대한 지식이 전무할 수 있다.

개발자가 한 주 정도 다른 직원들의 업무를 체험해보는 방법이 있지만, 트레일러 운전이나 비행기 정비 등 상당한 전문성이 요구되는 경우에는 적용하기 힘든 접근법이다. 때론 따라다니는 것만으로 충분할 수도 있다. 때론 필요한 스펙을 정확히 정리해 제시할 수 있는 유능한 직원이 있을 수도 있다.

그러나 개발자가 손을 뻗쳐 커뮤니케이션을 할 필요가 있다. 사용자에 귀를 기울이고, 사용자가 도구의 워크플로우 방해요소와 문제점을 없애는 방법을 이야기하도록 유도할 필요가 있다. 반드시 이런 채널들을 강화해야 한다. 개발자가 자신이 만든 코드를 직접 사용하지 않는 경우, 이들은 이런 코드를 실제 사용하는 사람들과 대화할 필요가 있다.

비즈니스 관행 자체
소프트웨어에 맞게 비즈니스를 바꾸거나, 반대로 비즈니스에 맞는 소프트웨어를 개발할 수 있다. 첫 번째의 경우, 많은 사람들을 재교육해야 하고, 새로운 워크플로우를 만들어야 한다. 이에 관리자는 오래된 비즈니스 관행에 부합하는 새 소프트웨어를 조달하는 경우가 많다. 그러면서 수십 년 동안의 복잡성이 그대로 반영된다. 때론 몇 십년 전 시작되어 지금은 소프트웨어에 그대로 남아있는 이상한 실무 관행에 대한 불평을 소프트웨어에 토해내는 경우들도 있다.

애석하게도 이런 경우 해결책은 없다. 소프트웨어에 구식의 좋지 않은 비즈니스 실무 관행이 방영되어 있음을 인정하는 것밖에 없다. 일부 부분이 너무 복잡해서 소프트웨어 사용을 싫어한다면, 그건 비즈니스가 너무 복잡하기 때문이다. 이를 더 큰 변화에 대한 신호로 사용해야 한다.

‘갱신(Rewrite)’ 주기가 더 길다
완벽한 리라이트(재개발)를 통해서만 개선할 수 있는 프로그램들이 많다. 필자가 알고 있는 팀 중 하나는 매년 1월 1일에 새 버전을 만들기 시작, 매년 완전히 새로운 버전의 프로그램을 만들어 사용한다. 많은 돈이 들지만, 그 동안 누적된 문제들을 해결할 수 있는 방법이다.

하지만 대부분 회사는 이렇게 할 여력이 없다. 이렇게 할 수 있는 경우에도, 다른 곳에 돈을 투자하는 결정을 내리는 경향이 있다. 이런 이유로 소프트웨어는 계속 노후화된다. 해결책은 없다. 큰 예산을 투입해 완전히 새롭게 만들도록 지원하는 방법 뿐이다. 그 전에는, 사용자는 다시 만들 수 없는 소프트웨어를 수용하는 방법밖에 없다.

노후화되는 프레임워크
소프트웨어가 갓 작성될 때, 개발자들은 새 코드에 사용할 프레임워크를 선택한다. 당시에는 현명한 선택이지만, 나중에는 현명한 선택이 되지 않을 수도 있다. 다른 회사가 해당 프레임워크를 인수한 후 신경을 쓰지 않는 문제가 있을 수 있다. 또는 프레임워크 관리가 이익을 잠식하는 것이 원인이 되어 문제가 많은 프레임워크로 바뀔 수도 있다. 오픈소스 커뮤니티에 문제가 발생할 수도 있다.

팀이 이 프레임워크에 회사의 미래를 걸기로 결정했을 당시만 하더라도 아주 좋은 프레임워크였으며, 현명한 결정이었다. 그러나 지금은 임시방편으로 유지를 하고, 또 다른 한편으로는 해커들이 보안 취약점을 찾는 그런 프레임워크가 되었다.

이런 오래 전 실수를 바로잡을 방법은 많지 않다. 더 크고, 더 나은 지원회사, 오픈소스 프로젝트를 우선시해 미래를 계획하는 시도를 할 수는 있지만, 이런 미래 예측에는 한계가 존재한다. ‘리라이트’를 고려할 수밖에 없다. 운이 좋기를 기원한다. 

추가 기능
기본 프레임워크를 만드는 회사들은 수많은 회사들의 니즈를 충족하기 위해 상상할 수 있는 모든 기능들을 구현해 제공한다. 그러나 당신의 회사는 이런 기능들 중 상당수를 사용하지 않는다. 이런 기능들 위에는 먼지만 쌓이게 되며, 더한 경우 사용자들이 이런 기능의 존재 이유에 대해 혼란스러워 할 수도 있다. 좋은 것도 너무 많으면 문제가 된다.

때론 이런 것들을 없애거나, 보이지 않는 곳으로 옮길 수 있다. 비즈니스 로직을 ‘리라이트’하는 것은 비용 효과적이지 못할 수도 있겠지만 보통 사용자들에게 제공되는 기능들을 ‘가지치기’하거나, 메뉴를 정리할 수 있는 경우가 많다.

오류 처리
워크플로우에는 항상 예외와 오류 관련 문제가 생기기 마련이다. 핵심 데이터베이스에 대한 링크에 문제가 생기는 경우가 있다. 양식에 부적절한 값이 포함되는 경우도 있다. 사용자가 이를 알도록 만들고, 사용자에게 이를 해결할 방법을 알려주는 것이 중요하다.

소규모 프로젝트에는 발생할 수 있는 오류를 파악하고, 이를 복구하도록 보장하는 ‘디버깅 주기’가 부족한 경우가 많다. 문제를 파악하기 힘들다. 오류 메시지도 없고, 이상한 번호가 붙여진 암호도 없다.

테스트와 디버깅에는 시간이 아주 큰 역할을 한다. 가장 좋은 솔루션은 사용자가 문제를 보고할 수 있도록 유도하는 보고 프레임워크를 만드는 것이다. 이런 문제들을 바로잡는 첫 번째 단계는 추적을 하고, 문서화를 하는 것이다.

부족한 예산
세계 인구의 절반에게 공급되는 방대한 ‘소비자 제품’에 투자하는 것과 동일한 개발자 시간을 투자할 기업은 많지 않다. 대형 금융기관, 다국적 기업, 제약회사과 같이 누가 봐도 돈이 많은 회사일지라도, 이렇게 철저히 개발을 할 여유 자본을 갖고 있지 않다.

사용자들에게 이런 도구들이 적은 예산으로 만들어진 도구라는 점을 일깨우는 수밖에 없다. 미흡한 소프트웨어를 사용하는 것에 대한 반대급부가 많은 보너스일지 모른다고 말이다. ciokr@idg.co.kr