사내 도구를 고객에게 주려는 순간, 무너지는 전제 3가지

사내에서 쓰려고 만든 도구가 잘 돌아가면 자연스럽게 이런 말이 나옵니다. "이거 그냥 팔면 되는 거 아닌가요."

저희도 같은 질문을 받았습니다. 전문가 일곱 관점으로 나눠 진단했더니 결론은 한 곳으로 모였습니다 — 그대로는 못 판다. 기능이 모자라서가 아닙니다. 사내 도구는 말하지 않은 전제 위에 서 있고, 고객에게 건네는 순간 그 전제가 한꺼번에 무너지기 때문입니다.

무엇이 무너지는지 셋으로 정리합니다. 도구를 만들어 쓰고 계신 곳이라면 그대로 대입해 보실 수 있습니다.

전제 1 — 쓰는 사람이 각자 자기 계정으로 로그인한다

사내 도구는 대개 계정 문제를 풀지 않습니다. 풀 필요가 없기 때문입니다. 직원마다 이미 회사가 사 준 구독이 있고, 도구는 그 로그인을 그대로 물려 사용합니다. 과금도, 사용량 관리도, 누가 얼마나 썼는지도 도구가 몰라도 됩니다.

고객에게 주는 순간 이 구조가 통째로 사라집니다. 우리 구독을 고객이 함께 쓰게 하는 것은 저희가 쓰는 서비스의 약관이 금지합니다. 그러면 남는 길은 고객이 자기 계정과 키를 넣는 구조인데, 이게 기능 하나 추가하는 일이 아닙니다.

• 키를 어디에 보관할 것인가 — 고객 서버인가, 우리 서버인가

• 키가 없거나 만료됐을 때 화면은 무엇을 보여줄 것인가

• 사용량이 고객 계정에서 빠져나가는데, 요금 예측은 누가 책임지는가

• 우리가 대신 넣어 준 키가 남아 있으면 그것부터 사고다

계정 하나가 과금·인증·데이터 경계를 동시에 건드립니다. 사내에서는 없던 계층이 통째로 새로 필요합니다.

여기에 설치가 겹칩니다. 사내 도구는 대개 각자 컴퓨터에 깔아 놓고 사용합니다. 옆에서 도와주면 되니까요. 고객 조직에서는 그 설치가 세 번 막힙니다 — 전산 정책에 걸리고, 키를 넣는 절차에서 걸리고, 처음 열었을 때 무엇부터 해야 하는지 몰라서 걸립니다. 사내에서는 셋 다 사람이 해결하던 문제라 도구에 그 자리가 없습니다.

그래서 "일단 깔아 보시라"로 시작하는 방식이 잘 안 됩니다. 쓰는 사람이 스스로 넘어야 할 문턱이 셋이면, 그 앞에서 대부분 멈춥니다. 사내에서는 이 셋이 문턱으로 보이지도 않습니다. 물어보면 해결되는 일이라 아무도 그것을 기록으로 남기지 않았기 때문입니다.

전제 2 — 도구가 우리 폴더와 우리 방식에 붙어 있다

두 번째가 더 깊습니다. 사내 도구가 쓸모 있는 이유는 대개 우리 일하는 방식이 그 안에 녹아 있기 때문입니다. 규칙 문서, 자주 쓰는 절차, 폴더 구조, 금지 표현 목록, 검사 스크립트. 이게 도구를 쓸모 있게 하는 실체입니다.

그런데 이것들은 고객에게 아무 의미가 없습니다. 세 가지가 동시에 일어납니다.

• 쓸모의 근원 — 우리에게는 도구를 쓸 만하게 만든 실체인데, 고객에게는 뜻 모를 잡음입니다

• 축적된 기록 — 우리에게는 자산인데, 그대로 넘기면 우리 내부가 보이는 창이 됩니다

• 손에 익은 순서 — 우리에게는 편한 흐름인데, 고객 자기 방식과 충돌합니다

특히 두 번째가 위험합니다. 우리 규칙 문서에는 실패한 사례, 고객사 이름, 내부 판단 기준이 섞여 있습니다. 도구를 그대로 넘기면 그게 같이 넘어갑니다.

그래서 갈라야 합니다. 어디서나 쓰이는 뼈대 / 업종에 맞춘 묶음 / 그 고객만의 설정 세 층으로. 이 분리를 안 하면 고객마다 우리 것을 손으로 지우게 되고, 그 순간부터 제품이 아니라 그때그때 만드는 일이 됩니다.

이 분리에는 잘 안 보이는 이득이 하나 더 있습니다. 무엇이 진짜 자산인지가 드러납니다. 뼈대만 남기고 다 걷어냈을 때 남는 것이 얼마나 되는지를 보면, 우리가 팔려던 것이 도구인지 아니면 그 안에 넣어 둔 방식인지가 그 자리에서 갈립니다.

저희 경우에는 걷어내고 나니 도구 자체는 꽤 얇았습니다. 화면과 실행기를 이어 주는 층이라, 큰 회사가 같은 걸 공식으로 내놓으면 그날로 값이 사라지는 종류였습니다. 남은 것은 그 위에 쌓아 둔 절차와, 무엇을 근거로 그렇게 판단했는지가 남는 기록이었습니다. 팔 것이 있다면 그쪽이라는 결론이 여기서 나왔습니다.

전제 3 — 쓰는 사람이 전부 믿을 수 있는 사람이다

세 번째는 있는 줄도 몰랐던 전제입니다. 사내 도구는 권한을 안 나눕니다. 모두가 모든 것을 볼 수 있고, 누가 무엇을 했는지 남기지 않아도 됩니다. 옆자리에 물어보면 되니까요.

조직이 쓰기 시작하면 이 전제가 제일 먼저 깨집니다.

• 부서가 다르면 서로 못 봐야 하는 문서가 있습니다

• 협력사 인원이 섞이면 범위를 잘라야 합니다

• 사고가 나면 누가 언제 무엇을 했는지를 사람이 아니라 기록이 답해야 합니다

• 문서마다 등급이 달라, 어떤 것은 회사 밖으로 나가면 안 됩니다

여기서 흔한 오해가 하나 있습니다. 이걸 "보안 기능 몇 개 추가"로 보는 것입니다. 실제로는 로그인·권한 범위·신원별 기록·문서 등급이 한 덩어리라, 어느 하나만 넣으면 나머지가 구멍으로 남습니다.

예를 들어 로그인만 붙이고 권한 범위를 안 나누면, 로그인한 사람이 전부 다 보는 상태가 그대로입니다. 권한까지 나눠도 신원별 기록이 없으면 사고가 났을 때 되짚을 수가 없습니다. 셋을 다 해도 문서 등급이 없으면 "이건 밖으로 나가면 안 되는 문서"라는 판단을 사람이 매번 해야 합니다. 사람이 매번 하는 판단은 바쁜 날 한 번 빠지고, 그 한 번이 사고가 됩니다. 사내에서는 그 판단이 빠져도 옆자리가 잡아 줬을 뿐입니다.

시연과 판매를 가르는 선도 여기입니다. 보여 주는 것은 이 계층 없이도 됩니다. 실제로 저희도 보여 드리는 것은 먼저 시작했습니다. 다만 고객의 진짜 자료가 들어가고 돈이 오가는 순간부터는 이 계층이 없으면 안 됩니다. 그 선을 흐리면 계약서를 쓴 다음에 계층을 만들게 되고, 그때는 이미 고객 자료가 안에 들어와 있습니다.

그래서 세 문장으로 먼저 따져 봅니다

도구를 팔 수 있는지 보려면 기능 목록을 보지 말고 이 셋을 물어보시면 됩니다.

1. 계정과 요금을 고객이 자기 이름으로 지불할 수 있는가 — 못 하면 약관에서 막힙니다

2. 우리 것을 지우면 껍데기만 남는가 — 남으면 팔 것이 없는 것이고, 안 남으면 우리 내부가 나갑니다

3. 누가 무엇을 했는지 기록이 답하는가 — 사람이 답해야 하면 조직에서는 못 버팁니다

두 번째 문장은 머리로 답하기 어렵습니다. 저희는 이렇게 재 봤습니다. 빈 폴더를 하나 만들어 도구만 그대로 복사하고, 그 안에서 우리 규칙 문서와 절차와 그동안 쌓인 기록을 전부 뺐습니다. 그 상태로 하루를 일해 봤습니다.

그러자 무엇이 우리 것이었는지가 그 자리에서 드러났습니다. 도구는 켜지는데 무엇부터 물어야 할지가 없었고, 답이 나와도 그 답이 맞는지 대조할 기준이 없었고, 어제 무엇을 정했는지 되짚을 데가 없었습니다. 그때 안 되던 것들의 목록이 곧 우리가 팔 수 있는 것의 목록이었습니다.

저희가 이 셋을 따져 봤을 때 결과는 이랬습니다. 사내 기준으로는 잘 돌아가는 도구였는데, 밖에 내놓는 기준으로 다시 채점하니 쓰는 경험은 절반을 겨우 넘는 수준, 보안은 판매 기준 미달이었습니다. 같은 물건인데 기준을 바꾸니 점수가 뒤집힌 것입니다.

일곱 관점으로 나눠 본 것이 도움이 됐습니다. 한 사람이 보면 "좋은데 몇 가지만 고치면 되겠다"로 끝나기 쉬운데, 관점을 갈라 놓으니 같은 물건에 대해 서로 다른 판정이 나왔습니다. 쓰는 경험 쪽은 "사내용으로는 좋다"였고, 보안 쪽은 "이대로는 못 판다"였습니다. 둘 다 맞는 말이고, 합쳐야 결론이 섭니다.

여기서 배운 것이 하나 더 있습니다. 자기 도구를 자기가 채점하면 대개 후하게 나옵니다. 매일 쓰는 사람은 문턱을 이미 넘은 뒤라 그 문턱이 안 보이기 때문입니다. 설치가 어렵다는 것도, 처음 열었을 때 뭘 해야 할지 모르겠다는 것도, 익숙해진 사람 눈에는 문제로 안 보입니다.

보여 주는 것과 파는 것은 준비가 다릅니다

세 전제를 세우고 나면 실무에서 곧바로 갈리는 것이 하나 있습니다. 시연은 지금 해도 되고, 판매는 안 된다는 것입니다.

보여 드리는 데 필요한 것은 짧습니다. 사내 맥락을 가린 별도 구성과, 5분 안에 끝나는 흐름 하나. 상대 회사 자료가 들어가지 않으니 권한도 감사도 필요 없습니다.

판매는 다릅니다. 돈이 오가고 고객 자료가 안으로 들어오는 순간부터 앞의 세 계층이 전부 있어야 하고, 하나라도 없으면 그건 기능 부족이 아니라 계약 위험입니다.

이 둘을 섞으면 흔한 순서 사고가 납니다. 시연이 잘돼서 계약을 먼저 쓰고, 계층은 그다음에 만드는 것입니다. 그때는 이미 상대 자료가 안에 들어와 있어 고치는 일이 아니라 옮기는 일이 됩니다.

지원까지 계산에 넣어야 합니다

한 가지 더 있습니다. 제품에는 쓰는 사람이 막혔을 때 답해 줄 사람이 붙습니다. 사내에서는 옆자리가 그 역할을 합니다. 밖에 팔면 그 자리가 조직이 되어야 합니다.

작은 회사에서 이게 결정적입니다. 인원이 넉넉하지 않은 조직이 제품 지원을 붙이면, 그 인원이 만들던 것을 못 만듭니다. 도구 하나를 팔기로 한 결정이 회사가 무엇을 만들 수 있는지를 바꿔 버립니다.

여기에도 재 보는 방법이 있습니다. 지난 한 달 동안 사내에서 이 도구 때문에 누가 몇 번 불려 갔는지 세어 보시면 됩니다. 옆자리라 세지 않았을 뿐이지 그 횟수는 이미 발생하고 있습니다. 고객이 열 곳이면 그 횟수에 열을 곱한 뒤, 옆자리가 아니라 전화와 메일로 답해야 한다는 조건을 얹으면 됩니다.

그래서 "팔 수 있는가"는 기술 질문이 아니라 조직 질문이기도 합니다. 만들 수 있느냐가 아니라, 만든 뒤에 받쳐 줄 수 있느냐입니다.

이 셋을 알고 나면 결정이 하나 남습니다

무너지는 전제를 다 세우고 나면 대개 이런 계산이 나옵니다. 껍데기(도구 그 자체)는 언제든 큰 회사가 공식으로 내놓으면 사라지고, 남는 것은 그 안에 채워 넣은 방식과 축적된 기록뿐이라는 것입니다.

그러면 선택은 둘입니다.

• 도구를 판다 — 위 세 계층을 다 만들고, 지원 조직을 갖추고, 큰 회사가 같은 걸 무료로 내놓는 날을 견딘다

• 도구가 여는 일을 판다 — 도구는 일을 여는 창구로 쓰고, 값은 그 안에 담은 방식과 결과로 받는다

정답이 하나인 문제는 아닙니다. 다만 이 셋을 세워 보기 전에 "그냥 팔면 되지 않나"로 시작하면, 계약서를 쓰고 나서 계층을 만들게 됩니다. 순서가 뒤집히면 그때부터는 고치는 비용이 만드는 비용보다 큽니다.

사내에서 잘 쓰고 계신 도구가 있으신가요. 위 세 문장을 그 도구에 대 보면 어떤 답이 나오십니까.