맞춤형 업무 시스템과 SaaS, 무엇을 선택해야 하는가

먼저 밝혀 둘 것이 있습니다. 이 글은 맞춤형 시스템을 만드는 회사가 쓰고 있습니다. 그래서 이 글이 쓸모가 있으려면 맞춤이 유리한 조건만큼 SaaS가 유리한 조건도 같은 무게로 적혀 있어야 합니다. 아래에서 그렇게 하려 했고, 읽으시면서 그 균형이 맞는지 함께 봐 주시면 좋겠습니다.

용어부터 맞추겠습니다. 이 글에서 SaaS는 우리 서버에 설치하지 않고 인터넷으로 접속해 쓰며 사용 기간만큼 요금을 내는 서비스를 가리킵니다. 사내 서버에 설치해 두고 쓰는 형태라면 여기서 말하는 SaaS와 맞춤 개발의 중간에 가깝고, 아래 축 중 이탈 비용과 유지보수 항목이 특히 다르게 적용됩니다.

비교가 어려운 이유는 가격표부터 보기 때문입니다

맞춤 개발과 SaaS 구독을 비교할 때 가장 먼저 손에 잡히는 것이 가격이고, 그래서 가장 먼저 비교하게 되는 것도 가격입니다. 문제는 두 가격이 서로 다른 것을 재고 있다는 점입니다.

구독료는 사용하는 동안 계속 나가는 값이고 대개 인원이나 사용량에 비례합니다. 맞춤 개발비는 한 번 만드는 데 드는 값이고 그 뒤에는 운영과 수정에 드는 값이 따로 붙습니다. 성격이 다른 두 숫자를 나란히 놓으면, 비교 기간을 몇 년으로 잡느냐에 따라 답이 뒤집힙니다. 기간을 정하지 않은 채 하는 가격 비교는 사실상 결론을 미리 정해 놓고 하는 계산입니다.

그리고 가격 비교로는 애초에 답이 나오지 않는 질문들이 있습니다. 우리 업무 흐름이 그 서비스에 들어가는가, 나중에 나가고 싶을 때 나갈 수 있는가, 데이터가 어디에 남는가 같은 것들입니다. 이 질문들은 가격표에 적혀 있지 않습니다.

그래서 순서를 뒤집는 편이 낫습니다. 먼저 적합도를 보고, 그다음에 비용 구조를 봅니다. 적합하지 않은 것을 싸게 사는 일은 절약이 아니기 때문입니다.

네 가지 축으로 비교합니다 — 그리고 자주 빠지는 두 항목

맞춤 개발과 SaaS는 네 가지 축에서 성격이 갈립니다. 표에는 그 네 축에 더해, 계약을 검토하는 시점에는 잘 보이지 않는 두 항목을 함께 넣었습니다. 아래 표에는 금액을 적지 않았습니다. 금액은 회사 규모와 범위에 따라 달라지지만, 아래 성질의 차이는 규모와 무관하게 유지되기 때문입니다.

여기서 자주 놓치는 항목이 「기능이 늘어나는 방식」과 「장애가 났을 때」입니다. 두 항목은 계약을 검토하는 시점에는 눈에 띄지 않다가, 실제로 그런 일이 벌어진 다음에야 체감됩니다.

SaaS가 더 나은 조건

SaaS를 계속 쓰는 것이 맞는 상황은 분명히 있고, 실제로 그런 경우가 적지 않습니다. 아래 조건 중 여러 개에 해당한다면 맞춤 개발을 검토할 이유가 약합니다.

첫째, 업무가 업계 표준에 가까울 때. 회계, 급여, 전자결재, 메일, 근태처럼 법과 관행이 형태를 이미 정해 놓은 영역이 있습니다. 이런 업무는 회사마다 다를 여지가 크지 않고, 다르게 만들면 오히려 담당자가 새로 배워야 합니다. 게다가 법이나 제도가 바뀌면 서비스 쪽에서 반영하는 경우가 많습니다. 이 반영을 직접 따라가는 일은 생각보다 부담이 큽니다.

둘째, 우리보다 그 업무를 더 많이 다뤄 본 곳이 만든 제품일 때. 널리 쓰이는 서비스에는 수많은 회사의 사용 경험이 이미 반영돼 있습니다. 우리가 처음 설계할 때는 떠올리지 못할 예외 처리가 들어 있는 경우가 많고, 그것은 돈으로 사기 어려운 종류의 축적입니다. 우리 업무가 특별하다고 느끼더라도, 실제로 갈라지는 지점이 몇 군데뿐이라면 그 몇 군데 때문에 나머지 전부를 새로 만드는 것은 비싼 선택입니다.

셋째, 지금 업무 흐름이 아직 정리돼 있지 않을 때. 맞춤 개발은 정해진 흐름을 시스템으로 옮기는 일입니다. 흐름이 아직 바뀌는 중이라면, 만드는 동안에도 요구가 계속 바뀌어 완성 시점이 흐려집니다. 이럴 때는 SaaS를 먼저 써서 업무를 한 번 표준화해 보는 편이 낫습니다. 그 과정에서 우리 흐름의 어디가 정말 다른지가 드러나고, 그때 만들면 훨씬 정확하게 만들어집니다.

넷째, 시작 시점이 중요할 때. 다음 달부터 당장 써야 하는 상황이라면 SaaS가 먼저입니다. 만드는 일에는 만드는 시간이 들고, 그 시간을 줄이려고 범위를 깎으면 결국 반쪽짜리가 나옵니다. 급할 때는 급한 방식을 쓰고, 만드는 일은 여유가 있을 때 시작하는 편이 결과가 낫습니다.

다섯째, 만든 뒤를 감당할 사람이 사내에 없을 때. 이 항목이 가장 자주 과소평가됩니다. SaaS 요금 안에는 보안 패치, 서버 관리, 브라우저 변화 대응, 기능 개선(요금제 등급에 따라 범위가 갈립니다)이 함께 들어 있습니다. 맞춤으로 만들면 이 일들이 전부 우리 몫이 되고, 누군가와 계약해서 맡기더라도 그 계약이 따로 필요합니다. 드는 것은 손만이 아닙니다. 맞춤 시스템은 만든 뒤에도 이 요청을 반영할지, 이 데이터를 어떻게 다룰지 같은 결정이 계속 필요한데, 그 결정을 내릴 사람이 사내에 아무도 없다면 시스템은 있는데 아무도 손대지 못하는 상태로 굳습니다.

정리하면, 표준 업무이고 흐름이 아직 정리되지 않았고 시작이 급하다면 SaaS가 맞습니다. 이 조합에서는 맞춤 개발이 가진 장점이 거의 작동하지 않습니다.

지금 쓰시는 서비스로 업무가 끝나고 있다면 이 글의 나머지는 읽지 않으셔도 됩니다. 아래는 그렇지 않을 때의 판단 기준입니다.

맞춤 시스템이 더 나은 조건

맞춤 개발이 맞는 상황은 업무에 우리 회사만의 규칙이 있고, 그 규칙이 사라질 예정이 없을 때입니다.

첫째, SaaS 화면 밖에서 벌어지는 일이 늘어날 때. 시스템에 입력은 하는데 실제 판단은 따로 만든 엑셀에서 하고 있다면, 그 엑셀이 진짜 업무 시스템입니다. 이 상태는 데이터가 두 곳으로 갈라지고 어느 쪽이 맞는지 아무도 확신하지 못하는 결과로 이어집니다.

둘째, 그 규칙이 우리 회사의 경쟁력일 때. 남들과 다르게 일하기 때문에 남는 이익이 있다면, 그 방식을 표준 제품에 억지로 밀어 넣는 것은 강점을 깎는 일입니다. 반대로 남들과 다른 이유가 그저 예전부터 그렇게 해 왔기 때문이라면, 그건 바꿀 대상이지 만들 대상이 아닙니다. 이 둘을 구분하는 것이 이 판단에서 가장 어려운 부분입니다. 구분이 안 될 때는 두 가지를 물어보십시오. 이 방식 때문에 고객이 우리를 고르는가, 그리고 이 방식을 그만두면 매출이나 원가에 무엇이 달라지는가. 답이 안 나온다면 경쟁력이 아니라 관성일 가능성이 큽니다.

셋째, 여러 서비스에 데이터가 흩어져 있을 때. 영업은 이 서비스, 재고는 저 서비스, 정산은 엑셀인 상태에서는 전체를 한 화면에서 볼 방법이 없습니다. 사람이 매번 옮겨 붙이는 일이 반복된다면, 그 일 자체가 시스템으로 만들 대상입니다. 고객관리 시스템을 맞춤으로 만들면 어떤 형태가 되는지, 재고·발주 시스템을 맞춤으로 만들면 무엇이 달라지는지는 각 지면에 정리돼 있습니다.

넷째, 인원이 늘어도 처리 방식은 그대로일 때. 구독료는 대체로 사람 수를 따라갑니다. 사람이 늘어도 하는 일의 구조가 같다면, 늘어나는 요금이 늘어나는 가치와 이어지지 않습니다. 이 지점이 오면 총비용의 방향이 갈리기 시작합니다.

다섯째, 데이터가 있어야 할 위치가 정해져 있을 때. 계약이나 내부 규정 때문에 데이터가 특정 환경 안에 있어야 하는 경우가 있습니다. 이 요건은 협상 대상이 아니라 전제 조건이라, 여기에 걸리면 다른 축의 비교가 의미를 잃습니다.

양쪽 조건에 모두 해당하는 회사가 오히려 흔합니다. 그럴 때는 순서를 두고 보십시오. 먼저 데이터가 있어야 할 위치가 계약이나 규정으로 정해져 있는지 봅니다. 정해져 있다면 거기서 답이 납니다. 그렇지 않다면 업무 흐름이 아직 바뀌는 중인지 봅니다. 바뀌는 중이라면 SaaS로 한 번 표준화한 뒤에 다시 보는 편이 정확합니다. 두 관문을 지나고도 갈린다면, 마지막으로 보는 축은 화면 밖에서 벌어지는 작업의 비중입니다.

“우리 업무에 맞게 바꿀 수 있습니다”는 어디까지 사실인가

SaaS의 커스터마이징은 세 층으로 나뉘고, 층마다 할 수 있는 일의 성격이 다릅니다. 영업 상담에서 “맞춤 설정이 됩니다”라는 답을 들었을 때 그것이 어느 층을 말하는지 확인하면 오해가 크게 줄어듭니다.

• 설정 층 — 항목 이름 바꾸기, 필드 추가, 결재선 지정, 권한 나누기처럼 화면에서 켜고 끄는 범위입니다. 많은 서비스가 여기까지는 제공합니다.
• 확장 층 — 서비스가 제공하는 스크립트나 앱 형태로 기능을 덧붙이는 범위입니다. 상위 요금제에서만 열리는 경우가 많고, 서비스가 크게 바뀌면 덧붙인 것을 다시 손봐야 합니다.
• 연동 층 — 외부 시스템과 데이터를 주고받는 범위입니다. 이때 필요한 것이 외부에서 데이터를 읽고 쓸 수 있게 열어 둔 통로이고, 이를 흔히 API라고 부릅니다. 제공 여부와 호출 한도가 요금제 등급에 따라 달라지는 경우가 많습니다.

막히는 지점은 대체로 정해져 있습니다. 업무의 순서 자체를 바꾸는 일은 세 층 어디서도 되지 않습니다. 승인 단계를 하나 더 넣거나 조건에 따라 흐름을 갈라야 하는데 서비스가 그 구조를 갖고 있지 않다면, 설정으로는 흉내조차 나지 않습니다. 여러 서비스에 걸친 계산도 마찬가지입니다. 한 서비스는 자기 안의 데이터만 보기 때문입니다.

그리고 확장 층에는 잘 드러나지 않는 값이 붙습니다. 붙여 놓은 기능은 서비스가 업데이트될 때마다 다시 확인해야 하고, 그 확인을 아무도 하지 않으면 어느 날 조용히 동작을 멈춥니다. 붙인 것이 많아질수록 이 부담이 커지고, 그 시점이 오면 이미 유지보수를 하고 있는 셈입니다.

“원하는 대로 만들어 드립니다”는 어디까지 사실인가

만드는 쪽의 문구도 같은 방식으로 나눠 들으셔야 공평합니다. 만드는 동안 무엇을 먼저 넣고 무엇을 뒤로 미룰지는 발주처가 정합니다. 다만 그 권한이 인도 이후에도 그대로 이어지지는 않습니다. 완성된 뒤의 수정 순서는 운영 계약의 범위 안에서 다시 정해집니다. 그래서 만드는 계약을 논의하는 자리에서 이후의 수정 요청을 어떤 범위로 받는지를 함께 확인하셔야 합니다.

「무슨 일이 생겨도 바로 대응합니다」라는 답도 나눠 들으셔야 합니다. 자동으로 감시하는 일과 사람이 원인을 분석하고 조치하는 일은 다릅니다. 감시는 시간과 무관하게 돌지만, 사람의 대응은 계약된 지원시간과 서비스 범위를 기준으로 이뤄집니다. 24시간 상주하는 관제는 빌드업웍스가 직접 수행하지 않고 전문업체와 협업하며 별도 비용이 듭니다. 운영을 맡을 때의 범위는 AWS 운영 지원 범위에 적혀 있습니다.

데이터와 소스 코드는 누구 것인가

계약 종료 시 데이터를 돌려받을 수 있는지는 어느 쪽을 고르든 반드시 확인해야 하는 항목입니다. 다만 두 방식에서 근거가 되는 것이 다릅니다.

SaaS 쪽에는 법이 정한 바닥이 있습니다. 클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률 제27조는 클라우드컴퓨팅서비스 제공자가 이용자와의 계약이 종료됐을 때 이용자 정보를 반환하고, 자신이 보유한 이용자 정보를 파기하도록 정하고 있습니다. 사업을 종료하는 경우에도 그 사실을 알리고 종료일 전까지 반환하도록 하고 있습니다.

다만 같은 조 제5항이 예외를 두고 있습니다. 제3항·제4항에도 불구하고 제공자와 이용자가 계약으로 특별히 다르게 정한 경우에는 그에 따릅니다. 그래서 법이 있다는 사실만으로 안심할 수는 없고, 약관과 계약서에 어떻게 적혀 있는지를 함께 봐야 합니다. 또한 이 법이 말하는 클라우드컴퓨팅서비스의 범위는 같은 법 제2조와 그 시행령이 정하므로, 쓰고 계신 서비스가 여기에 해당하는지는 개별로 확인이 필요합니다. 해외 사업자와 맺은 계약이라면 더욱 그렇습니다.

실무에서 더 중요한 것은 반환의 형식입니다. 데이터를 돌려받더라도 그것이 사람이 열어 볼 수는 있지만 다른 시스템에 넣을 수는 없는 형태라면, 돌려받았다는 사실만 남습니다. 계약 전에 실제로 한 번 내보내 보고 그 파일을 열어 보는 것이 가장 확실한 확인 방법입니다.

맞춤 개발 쪽에는 이런 법정 기준이 따로 없고, 대신 계약이 그 자리를 대신합니다. 빌드업웍스는 고객사 명의의 AWS 계정에 시스템과 데이터를 두지만, 소유와 이관 조건 자체는 계약에서 정합니다. “만들었으니 당연히 우리 것”이라고 가정하지 마시고 문서에서 확인하십시오. 소스 코드의 저작권, 계약 종료 후 제3자가 이어받아 수정할 권리, 넘겨받는 산출물의 목록은 각각 다른 항목입니다.

한 가지 더 있습니다. 어느 방식을 고르든 고객이나 임직원의 개인정보를 외부에 맡기는 순간 개인정보 보호법 제26조가 정한 업무 위탁이 됩니다. 이 조문은 위탁을 문서로 하도록 하고, 누구에게 맡겼는지 공개하도록 하며, 맡긴 쪽이 받은 쪽을 교육하고 감독하도록 정하고 있습니다. 맡긴다고 해서 책임까지 넘어가지는 않는다는 뜻이고, 이 점은 SaaS를 쓰든 개발을 맡기든 똑같이 적용됩니다.

실제로는 섞습니다

둘 중 하나를 고르는 대신 조합하는 편이 현실적인 경우가 있습니다. 전부 맞춤으로 만들면 표준 업무까지 떠안게 되고, 전부 SaaS로 두면 예외가 계속 쌓입니다.

가르는 기준은 단순합니다. 회사마다 다를 이유가 없는 업무는 SaaS에 두고, 우리 회사만의 규칙이 몰려 있는 업무만 맞춤으로 만듭니다. 회계·급여·메일·전자결재는 대체로 앞쪽이고, 우리 제품과 고객의 특성이 직접 반영되는 핵심 업무는 대체로 뒤쪽입니다.

이 구조를 택할 때 미리 정해 두어야 할 것은 어느 쪽 값을 맞는 것으로 볼지입니다. 같은 거래처 정보가 두 시스템에 있고 양쪽에서 수정할 수 있으면, 얼마 지나지 않아 어느 쪽이 맞는지 아무도 모르게 됩니다. 항목별로 기준이 되는 쪽을 한 곳으로 정하고 나머지는 그것을 받아 보기만 하도록 정리해 두면 이 문제가 대부분 사라집니다.

연동은 만들고 끝나는 것이 아닙니다. 양쪽 서비스가 각자 바뀌기 때문에, 어긋났을 때 누가 어떻게 알아차릴지를 만들 때 함께 정해 두어야 합니다.

시작 범위는 좁게 잡는 편이 낫습니다. 가장 아픈 업무 하나만 먼저 맞춤으로 옮기고 나머지는 그대로 두면, 판단이 틀렸을 때 되돌릴 수 있습니다. 처음부터 전면 교체로 잡으면 되돌릴 지점이 없습니다.

갈아탈 시점을 알려 주는 신호

이 비중은 감으로 재기 어렵습니다. 한 주 동안 SaaS 화면 밖에서 한 작업을, 무엇을 엑셀로 옮겼고 무엇을 사람이 다시 확인했는지까지 그때그때 적어 보시면 그 목록이 곧 판단 재료가 됩니다.

지금 쓰는 SaaS로 업무가 끝나고 있다면 바꾸지 않는 것이 맞습니다. 검토를 시작할 시점은 아래 신호가 여러 개 겹칠 때입니다.

• 시스템에 입력한 뒤 같은 내용을 엑셀에 다시 정리하는 일이 매주 반복됩니다
• 신규 담당자에게 업무를 알려 줄 때 시스템 사용법보다 예외 처리 요령을 더 오래 설명합니다
• 필요한 숫자를 보려면 여러 화면에서 내려받아 사람이 합쳐야 합니다
• 요금이 오르는 이유가 업무량 증가가 아니라 계정 수 증가입니다
• 원하는 기능을 요청했지만 언제 반영될지 알 수 없다는 답을 받았습니다
• 상위 요금제로 올려야만 열리는 기능 하나 때문에 전체 등급을 올릴지 고민하고 있습니다

이 신호들이 겹칠수록 지금 치르고 있는 값이 요금이 아니라 사람의 시간이라는 뜻입니다. 그 시간은 청구서에 나타나지 않아서 비교에서 자주 빠집니다.

우리 업무가 어느 쪽에 가까운지 짧게 확인해 보고 싶으시면 1분 업무 시스템 진단을 이용해 보십시오. 여섯 가지 질문에 답하시면 현재 상태와 어울리는 형태를 정리해 드립니다.

다음 단계

결정을 서두르지 않는 것이 이 판단에서는 대체로 유리합니다. 지금 쓰는 서비스에서 데이터를 한 번 내보내 보시고, 위에서 적어 본 목록을 함께 놓으시면 판단에 필요한 재료가 대부분 모입니다.

맞춤 개발의 범위와 비용 구조가 궁금하시면 구축 등급과 범위에서 확인하실 수 있고, 개발 서비스가 어디까지 맡는지는 AI · 앱 개발 서비스 범위에 적혀 있습니다.

맞춤 쪽으로 기울고 계시다면 아래 데모를 먼저 눌러 보시길 권합니다. 설명보다 실제 화면이 판단에 도움이 되는 경우가 많습니다. 우리 업무에 맞는 형태가 어느 쪽인지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오. 만들지 않는 편이 낫다고 판단되면 그렇게 말씀드립니다.

참고 자료

• 클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률 제27조(이용자 정보의 보호)
• 클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률 제2조(정의)
• 개인정보 보호법 제26조(업무위탁에 따른 개인정보의 처리 제한)