일을 줄이려고 도입했는데, 일이 더 생겼다

두 편으로 나눈 이야기의 첫 번째 글입니다. 두 번째 글 지금이 재밌는 이유는에서 이어집니다.

lapal lab은 상용 서비스, 그중에서도 SaaS 형태의 서비스를 여러 차례 만들고 고객사에 제안해 왔습니다. 여러 기업이 같은 제품을 함께 쓰면 개발과 운영 비용을 나눌 수 있고, 한 번의 개선이 모두에게 돌아갑니다. 공유 제품이 가진 이 가치는 지금도 분명하다고 생각합니다.

다만 도입한 뒤의 이야기는 달랐습니다. 제품 하나를 한 기업의 업무에 자리 잡게 하는 데 생각보다 많은 자원이 들었고, 일이 일을 만드는 경우도 여러 번 보았습니다. 제품이 가정한 시스템과 절차, 그리고 회사가 실제로 일하는 방식 사이에는 늘 차이가 있습니다. 그 틈을 메우는 일은 대개 사람의 몫이 됩니다. 일을 줄이려고 도입했는데, 새로 생긴 일을 챙길 사람이 필요해지는 것입니다.

연결됐다고 일이 끝나는 것은 아니었습니다

가장 먼저 떠오르는 것은 ERP와의 연동입니다. SaaS에서 승인된 건이 ERP에서는 처리가 거부되는 일이 있습니다. 이미 마감된 회계 기간에 걸린 건이 그런 예입니다. 두 시스템이 연결되어 있어도 한쪽에서 끝난 일을 다른 쪽이 받아주지 않을 수 있습니다. 그러면 누군가 어떤 건이 어디에서 멈췄는지 지켜보고, 다시 보내고, 두 시스템의 결과가 서로 맞는지 대조해야 합니다. 연동을 만들었다고 일이 끝나는 것이 아니라, 연동을 지켜보고 맞추는 일이 새로 생깁니다.

승인과 권한도 비슷했습니다. 결재선과 위임 규칙은 조직이 바뀔 때마다 달라집니다. 조직 개편으로 부서와 직책이 바뀌면 승인 설정도 함께 바뀌어야 하는데, 그때 이미 진행 중이던 건은 어떻게 할지, 위임은 어디까지 이어질지가 문제가 됩니다. 설정을 고치는 것만으로 정리되지 않고, 어떤 건을 누가 이어받을지 사람이 판단해야 하는 경우가 있었습니다.

이 밖에도 비슷한 일이 반복되었습니다. 여러 레거시 시스템에서 품목이나 거래처 같은 기준정보가 서로 맞지 않아 연결 전에 먼저 정리해야 하는 일이 있었고, 주문·WMS·TMS·ERP로 이어지는 흐름에서 일부만 처리되고 나머지가 실패했을 때 사람이 손으로 복구해야 하는 일도 있었습니다.

제품이 모든 차이를 받아들일 수는 없습니다

저희는 이것을 SaaS의 잘못이라고 보지 않습니다. 공유 제품은 업종과 도메인, 산업별 차이를 일일이 담기 어렵습니다. 모든 차이를 담지 않는 것은 공유 제품이 감수해야 하는 선택입니다. 표준화가 공유 제품의 효율을 가능하게 하는 조건이니까요.

문제는 예외가 쌓일 때입니다. 고객마다 다른 예외를 하나씩 받아들이면 공유 제품은 점점 복잡해지고, 그 복잡함은 모든 사용자에게 돌아갑니다. 어떤 고객은 보안 요건에 따라 전용 데이터베이스나 별도 인프라를 요구하기도 합니다. 이렇게 고객별로 따로 관리할 부분이 늘면 운영 부담도 함께 커집니다.

그렇다고 모든 것을 고객에 맞춰 따로 만들면 부담이 다른 곳으로 옮겨 갑니다. 처음에는 딱 맞게 느껴져도, 고객마다 다른 코드를 오래 관리해야 하고 변경이 생길 때마다 유지보수 비용이 늘어납니다. 어느 쪽으로 가도 일이 완전히 사라지지는 않았습니다.

우리가 계속 마음에 걸렸던 것

이런 경험을 거치며 도입을 판단하는 기준이 조금 달라졌습니다. 기능 목록에 무엇이 있는지보다, 도입한 뒤 새로 생기는 일이 무엇이고 그것을 누가 맡게 되는지를 먼저 보게 되었습니다.

그래서 저희가 붙들고 있는 질문은 이렇습니다. 공유 제품이 가진 효율은 지키면서, 기업마다 실제로 다른 부분을 어떻게 지원할 수 있을까. 이 문제를 오래 집요하게 고민해 왔고, lapal lab은 지금도 조직 차원에서 풀어 가는 중입니다.

최근 저희 팀은 한 가지가 달라졌다고 느끼고 있습니다. 이런 일은 기존에도 가능했지만, 지금은 그 일에 드는 시간과 비용이 눈에 띄게 줄었습니다. 무엇이 어떻게 달라졌는지는 다음 글 지금이 재밌는 이유는에서 이어서 말씀드리겠습니다.