기업 내의 자그마한 개발 팀이 각종 소비자 앱 및 서비스에 익숙해진 현업 이용자들의 눈높이에 부응하기란 어렵다. 최종 사용자들의 타당한(?) 불평에 어떻게 대응해야 할까?
사람들이란 일부 시간에 모든 소프트웨어를 싫어하고, 일부 소프트웨어는 늘 싫어한다고 말한 위인이 있었던가? 아마 링컨이 그렇게 말했던 듯하다. 다행히 '모든 '소프트웨어를 '항상' 싫어할 수는 없다.
클릭과 키스트로크의 적합한 조합을 발견한 후에는 대부분이 마법처럼 일을 하기 때문이다. 하지만 머리카락을 잡아당기고 욕을 하는 등 나쁜 결과로 이어지는 경우도 있다. 특히 기업 내부에서 자체 개발한 소프트웨어에 대해 그렇다.
사실 기업 맞춤형 소프트웨어 프로젝트에 대한 불만에는 불공평한 측면이 있다. 소비자가 일상 생활에 사용하는 주요 소프트웨어와 서비스에는 수많은 개발자들이 참여해 일을 한다.
이를테면 신용카드 청구 부분에만 한 팀 전체가 매달린다. 사람들의 클릭률을 1% 높이는 방법을 찾기 위해서는 한 건물의 직원 전부가 매달리기도 한다. 그런데 이런 눈높이가 소규모 기업 프로젝트에도 적용되곤 한다.
많은 기업은 개발자가 소수이거나, 심지어 단 한 명이다. 그나마도 다른 몇 가지와 씨름하면서 짬을 내어 소프트웨어 프로젝트를 수행한다. 그런데 기업의 최종 사용자들은 대형 쇼핑몰이나 소셜 미디어 수준의 매끄러운 품질을 내부 회계 소프트웨어에 대해서도 기대한다.
소프트웨어 개발은 어렵다. 그런데 이렇게 고객이 같은 공간에 있는 경우라면 더 어려워진다. 이들이 당신의 코드를 싫어하면, 당신은 그것을 깊이 느낄 수 있다. 사내 당구 대항전에 불러주는 이가 없다면 좀더 절실히 느끼게 될 것이다.
여기 최종 사용자가 당신의 소프트웨어를 싫어하는 11가지 이유에 대해 설명한다. 일부는 쉽게 고칠 수 있는 문제지만, 상당수는 ‘규모의 차이’에서 비롯된 결과다. 다시 말해, 더 간결하고 세련되게 완성시키기 위한 자원을 가지지 못한 소규모 팀이라면 본질적인 한계가 있다.
반발과 개입이 가능하다
초등학교 동창과 대화를 나누거나, 자녀의 축구 경기의 결과를 알고 싶은가? 그렇다면 몇 안되는 대형 소셜 미디어 사이트에 로그인하고, 이들의 규칙을 따르는 방법 밖에 없다.
단순한 ‘좋아요’ 버튼 대신 더 정교한 방식으로 감정을 표현하고 싶거나, 다른 형식으로 더 긴 비디오를 업로드하고 싶을 수도 있지만, 이렇게 할 수 없다. 주요 플랫폼은 규칙과 사용 조건을 규정해 놓고 있고, 사용자는 여기에 자신을 적응시켜야 한다.
그러나 소규모 엔터프라이즈 프로젝트는 이런 힘을 갖고 있지 않다. 기업 사용자들은 클릭으로 포장된 서비스 약관에 얽매이지 않는다. 이들의 팀장은 누군가의 부하 직원이다. 그리고 조직의 위계 구조로 인해 혼란이 초래될 수 있다.
즉 기업 소프트웨어 개발 프로젝트에서는 힘의 역학관계가 아주 다르다. 사용자는 주어진 것을 고분고분 사용할 필요가 없다. 대형 소셜 플랫폼을 이용하려면 그들이 정한 규칙을 따라야 한다. 그러나 로컬 소프트웨어의 경우, 반발이 가능하다. 결국 ‘디테일’을 따지기 시작할 것이다.
느리다
모든 엔터프라이즈 소프트웨어가 느린 것은 아니다. 개발 팀이 많은 기능을 추가하지 않은 일부 레거시 소프트웨어는 새 하드웨어에서 아주 빠르게 작동할 것이다. 그러나 새 기능들을 배포했을 때 갑자기 느려지는 경우가 많다.
개발자들이 절충해야 할 것 중 하나가 ‘속도’이다. 기능들에 대한 수요, 요구가 증가하면 반응성과 성능에 문제가 생기는 경우가 많다. 규모가 큰 팀은 모든 것을 다시 새롭게 디자인할 수 있지만, 작은 팀은 그렇게 할 수 없다.
유일한 해결책은 사용자 경험에 부정적인 영향을 줄 일부 기능 요청을 거부하는 것이다. 새 SQL 쿼리에 복잡한 JOINS가 많다면, 더 단순한 것을 강력히 요구하는 것이다. 새 버튼에 느린 AJAX 호출이 많이 필요하다면, 이를 거부하는 것이다. 결국 속도를 향상하려는 노력은 또다른 사용자 불만으로 이어지기 쉽다.
구식으로 보인다
나이 든 컴퓨터 프로그래머들은 ‘그린 스크린’ 시대의 결제 소프트웨어를 사용하는 상점을 방문하기 좋아한다. 향수를 떠올리기 때문이다. 애니메이션 GIF도 없고, 색상을 전혀 사용하지 않았다. 25x80 그리드의 흑백 행렬로 구성된 스크린을 갖고 있다. 장점은 응답 시간이 정말 빠르다는 것이다. 멋진 아이콘이나 화려한 스크린이 네트워크를 방해하는 일이 없기 때문이다.
그러나 여전히 ‘그린 스크린’이다. 상사는 좋아할 수도 있다. 큰 투자가 필요 없는데, 잘 작동하기 때문이다. 회계나 재무 부서도 좋아할 것이다. 개발 투자 비용을 신속히 회수했기 때문이다.
그러나 최종 사용자 중 일부는 불평을 털어놓기 시작할 것이다. 파워 유저는 다양한 화면을 효과적으로 이용할 수 있는 펑션 키를 기억하고 있겠지만, 보통 사용자는 어떤 것이 메뉴인지, 어떻게 해야 메뉴를 불러낼 수 있는지 모를 수도 있다.
상사가 멀쩡히 작동하는 구식 소프트웨어를 그대로 두라고 지시할 수 있다. 그러면 이 소프트웨어가 정말 효율적이라는 점을 사용자에게 상기시킨다. 펑션 키의 기능을 기억하지 못하는 사람들을 돕기 위해 ‘치트 시트’를 인쇄해 배부한다.
또 다른 해결책은 그럴듯해 보이지만, 실상은 숨겨진 그린 스크린 세션에 전송되는 명령어를 생성하는 그래픽 쉘을 빌드하는 방법이다. 내부를 바꾸지 않은 상태에서 멋진 외관을 추가하는 방법이다. 물론 그래픽 쉘 작업을 추가해도 여전히 구식이라는 불평은 이어질 것이다. 보안이 과도하다
보안 관련된 부분이 너무 적어 문제가 되는 사내 프로젝트가 있고, 반대로 지나치게 많아 문제가 되는 사내 프로젝트가 있다. 회사의 규모가 크지 않아 제대로 된 보안 팀을 지원하지 못할 수도 있다. 이 경우 극도로 경계하는 방법을 사용하게 된다.
누군가 바이러스가 든 USB 플래시 드라이브를 삽입하는 바람에 모든 사람들이 사용하는 기능이 망가졌다고 가정하자. 그러면 USB 포트를 차단한다. 누군가 바이러스를 다운로드 받는 경우, 다운로드 자체를 금지하게 될 것이다. 결국 이 소규모 팀은 요청을 거부하고, 가장 깨끗한 기능들만 지원하게 된다.
이는 쉬운 해결책 될 수 없다. 사용자들은 이렇게 가혹한 규칙에 불만을 느낄 것이다. 그러나 직원 기록이 유출될 때 가장 먼저 놀랄 사람도 이러한 직원 사용자들이다. 민감한 데이터를 중심으로 더 안전한 시스템을 적용해서, 사용자에게 일정 수준 유연성을 제공하는 방법이 최선이다.
테스트가 부실하다
엔터프라이즈 소프트웨어 테스트는 힘든 도전과제이다. 개발자와 나머지 직원이 동떨어져 있을 때 더 복잡한 도전과제가 된다. 꽃꽂이, 정육, 애완견 사료 제조 등 비즈니스는 다양하다. 스케줄 관리 소프트웨어나 내부 데이터베이스를 만드는 사람들은 다른 직원들이 하는 일에 대한 지식이 전무할 수 있다.
개발자가 한 주 정도 다른 직원들의 업무를 체험해보는 방법이 있지만, 트레일러 운전이나 비행기 정비 등 상당한 전문성이 요구되는 경우에는 적용하기 힘든 접근법이다. 때론 따라다니는 것만으로 충분할 수도 있다. 때론 필요한 스펙을 정확히 정리해 제시할 수 있는 유능한 직원이 있을 수도 있다.
그러나 개발자가 손을 뻗쳐 커뮤니케이션을 할 필요가 있다. 사용자에 귀를 기울이고, 사용자가 도구의 워크플로우 방해요소와 문제점을 없애는 방법을 이야기하도록 유도할 필요가 있다. 반드시 이런 채널들을 강화해야 한다. 개발자가 자신이 만든 코드를 직접 사용하지 않는 경우, 이들은 이런 코드를 실제 사용하는 사람들과 대화할 필요가 있다.
비즈니스 관행 자체
소프트웨어에 맞게 비즈니스를 바꾸거나, 반대로 비즈니스에 맞는 소프트웨어를 개발할 수 있다. 첫 번째의 경우, 많은 사람들을 재교육해야 하고, 새로운 워크플로우를 만들어야 한다.
이에 관리자는 오래된 비즈니스 관행에 부합하는 새 소프트웨어를 조달하는 경우가 많다. 그러면서 수십 년 동안의 복잡성이 그대로 반영된다. 때론 몇 십년 전 시작되어 지금은 소프트웨어에 그대로 남아있는 이상한 실무 관행에 대한 불평을 소프트웨어에 토해내는 경우들도 있다.
애석하게도 이런 경우 해결책은 없다. 소프트웨어에 구식의 좋지 않은 비즈니스 실무 관행이 방영되어 있음을 인정하는 것밖에 없다. 일부 부분이 너무 복잡해서 소프트웨어 사용을 싫어한다면, 그건 비즈니스가 너무 복잡하기 때문이다. 이를 더 큰 변화에 대한 신호로 사용해야 한다.
‘갱신(Rewrite)’ 주기가 더 길다
완벽한 리라이트(재개발)를 통해서만 개선할 수 있는 프로그램들이 많다. 필자가 알고 있는 팀 중 하나는 매년 1월 1일에 새 버전을 만들기 시작, 매년 완전히 새로운 버전의 프로그램을 만들어 사용한다. 많은 돈이 들지만, 그 동안 누적된 문제들을 해결할 수 있는 방법이다.
하지만 대부분 회사는 이렇게 할 여력이 없다. 이렇게 할 수 있는 경우에도, 다른 곳에 돈을 투자하는 결정을 내리는 경향이 있다. 이런 이유로 소프트웨어는 계속 노후화된다. 해결책은 없다. 큰 예산을 투입해 완전히 새롭게 만들도록 지원하는 방법 뿐이다. 그 전에는, 사용자는 다시 만들 수 없는 소프트웨어를 수용하는 방법밖에 없다.
노후화되는 프레임워크
소프트웨어가 갓 작성될 때, 개발자들은 새 코드에 사용할 프레임워크를 선택한다. 당시에는 현명한 선택이지만, 나중에는 현명한 선택이 되지 않을 수도 있다. 다른 회사가 해당 프레임워크를 인수한 후 신경을 쓰지 않는 문제가 있을 수 있다.
또는 프레임워크 관리가 이익을 잠식하는 것이 원인이 되어 문제가 많은 프레임워크로 바뀔 수도 있다. 오픈소스 커뮤니티에 문제가 발생할 수도 있다.
팀이 이 프레임워크에 회사의 미래를 걸기로 결정했을 당시만 하더라도 아주 좋은 프레임워크였으며, 현명한 결정이었다. 그러나 지금은 임시방편으로 유지를 하고, 또 다른 한편으로는 해커들이 보안 취약점을 찾는 그런 프레임워크가 되었다.
이런 오래 전 실수를 바로잡을 방법은 많지 않다. 더 크고, 더 나은 지원회사, 오픈소스 프로젝트를 우선시해 미래를 계획하는 시도를 할 수는 있지만, 이런 미래 예측에는 한계가 존재한다. ‘리라이트’를 고려할 수밖에 없다. 운이 좋기를 기원한다.
추가 기능
기본 프레임워크를 만드는 회사들은 수많은 회사들의 니즈를 충족하기 위해 상상할 수 있는 모든 기능들을 구현해 제공한다.
그러나 당신의 회사는 이런 기능들 중 상당수를 사용하지 않는다. 이런 기능들 위에는 먼지만 쌓이게 되며, 더한 경우 사용자들이 이런 기능의 존재 이유에 대해 혼란스러워 할 수도 있다. 좋은 것도 너무 많으면 문제가 된다.
때론 이런 것들을 없애거나, 보이지 않는 곳으로 옮길 수 있다. 비즈니스 로직을 ‘리라이트’하는 것은 비용 효과적이지 못할 수도 있겠지만 보통 사용자들에게 제공되는 기능들을 ‘가지치기’하거나, 메뉴를 정리할 수 있는 경우가 많다.
오류 처리
워크플로우에는 항상 예외와 오류 관련 문제가 생기기 마련이다. 핵심 데이터베이스에 대한 링크에 문제가 생기는 경우가 있다. 양식에 부적절한 값이 포함되는 경우도 있다. 사용자가 이를 알도록 만들고, 사용자에게 이를 해결할 방법을 알려주는 것이 중요하다.
소규모 프로젝트에는 발생할 수 있는 오류를 파악하고, 이를 복구하도록 보장하는 ‘디버깅 주기’가 부족한 경우가 많다. 문제를 파악하기 힘들다. 오류 메시지도 없고, 이상한 번호가 붙여진 암호도 없다.
테스트와 디버깅에는 시간이 아주 큰 역할을 한다. 가장 좋은 솔루션은 사용자가 문제를 보고할 수 있도록 유도하는 보고 프레임워크를 만드는 것이다. 이런 문제들을 바로잡는 첫 번째 단계는 추적을 하고, 문서화를 하는 것이다.
부족한 예산
세계 인구의 절반에게 공급되는 방대한 ‘소비자 제품’에 투자하는 것과 동일한 개발자 시간을 투자할 기업은 많지 않다. 대형 금융기관, 다국적 기업, 제약회사과 같이 누가 봐도 돈이 많은 회사일지라도, 이렇게 철저히 개발을 할 여유 자본을 갖고 있지 않다.
사용자들에게 이런 도구들이 적은 예산으로 만들어진 도구라는 점을 일깨우는 수밖에 없다. 미흡한 소프트웨어를 사용하는 것에 대한 반대급부가 많은 보너스일지 모른다고 말이다.
