진정한 디지털 전환을 위한 개발않음의 중요성
한번 개발에 범용의 문제를 해결해 엄청난 효과를 봐야한다
메이코더스는 컴퓨터공학 기반의 창업자들이 만든 회사다. 가장 잘하는 것을 뽑으면 데이터분석, 웹개발, 모델링, 시각화, 무슨무슨 엔드 개발 등이 나온다. 초기에는 이런 기능들만으로 먹고 살았고, 이후에는 이 지식 위에서 기획을 했고, 서비스를 개발했고, 판매를 했고, 실적을 만들었다.
2022년 상반기 투자 시장이 얼어붙으면서 개발자 묻지마 채용이 끝났다느니, 옥석 가리기에 들어갔다느니 하는 소리가 들려오지만 이상하게도 개발 문의를 하는 지인들은 점점 더 많아진다. 아마도 모든 산업의 부분에서 디지털전환(DX, Digital Transformation)이 과제로 주어졌기 때문인데다, 메이코더스가 크로스보더 DX를 지향하며 수출 활동의 여러 부분에서 효율성을 만든 것을 인상 깊게 봤기 때문일 거다.
그런 문의가 있을 때마다 답변은 이렇다.
"굳이 개발을 해야하나요?"
거절을 위한 말이 아니다. 반대로 비디지털전환 영역도 중요하다는 것을 얘기하기 위함이다. 메이코더스의 효율성은 의외로 여기에서 나온다. 모델링이 되고, 정형화된 형태로 기입하고, 데이터로 관리하는 디지털 영역으로의 완전한 전환이 아니라, 일부만 전환하고 손으로 움직이고 발로 뛰는 비디지털 영역을 보존하는 데서 효율성이 발생한다는 말이다.
예를 들어 우리는 사람들과 채팅으로 정형화되지 않은 문장을 타이핑하며 일을 처리하기도 하고, 수출신고 중 패턴화가 되지 않는 부분은 하나하나 기입해서 완료한 후 결과값을 받아와 다시 DB에 넣는 작업도 한다. 사내 작업 관리를 위해 외부 SaaS를 도입하지만, 굳이 유료 버전의 세세한 기능까지 안쓴다. 이렇게 생활하다보니 가끔 디테일한 기능에 대해 목마름이 발생해도 더 고민하지 않고 수동으로 해결한다.
개발력이 제일 비싸다
개발조직임에도 불구하고 비개발요소를 중시하게 된 배경에는 효율성 문제가 있었다. 이 효율성은 시간과 기획력에 우선 해를 끼치고, 결정적으로 예산에 포괄적으로 해를 끼친다. 창의적이고 집착하는 기획자가 잠깐 옆길로 새 흔하지 않게 발생하는 문제를 디테일하게 고민하면서 시간을 쏟을 수는 있다. 물론 디자인도 할 수 있다. 심지어 깨알같이 재밌을 수도 있다.
그런데 이게 개발 단계가 됐을 때 문제가 발생한다. 기획이나 디자인과 달리 개발은 코드를 그린다고 보여지지 않는다. 이런 디테일한 것을 개발하는 것은 범용의 개발보다 난해하다. 훨씬 난이도가 높거나 더러운 코드를 만들어내기 때문이다. 기획을 하다 ~한 경우 이런이런 처리, ~한 경우 이런저런 처리, ~한 경우 저런요런 처리가 문득 머리를 스친다. 그럴 때는 영향을 받는 고객 수를 생각해야한다. ~한 경우가 각각 한 달에 2~3명의 고객에게만 해당한다면? 빼도 되는 경우인 것이다.
관리기능의 경우는 더 한다. 관리자가 1명인 어드민 기능인데 개인이 일하는 방식을 그대로 심기 위해 세세한 모델링을 고민한다. 이런 경우는 정말 개발을 하지 말아야 한다. 관리자가 바뀌면, 해당 개발은 그야말로 무.. 혹은 있어도 악의 기운만 풍기는 마이너스가 되기 때문이다. 각자 생각나는 사례가 하나씩은 있을 것이다.
예산을 관리하는 입장이 되면 정말 최악의 선택임을 알 수 있다. 분명 큰 돈을 써서 개발을 했는데 효과가 없다. 유지보수 비용도 엄청나게 증가한다(이 비용 때문에 망한 스타트업도 많다). 가장 큰 문제는 그 돈을 쓰고 더 해결해야하는 문제를 해결 못하게 되는 기회 비용들이다.
개발비가 비싼 이유?
엄청 큰 돈을 벌어다 줘야 해서
언제 개발을 하는가. 한 번의 개발이 범용의 문제를 해결해 엄청난 효과를 발휘할 때 개발을 한다. 적어도 수 천개의 데이터가 해당 코드를 타면서 작동해야할 때, 한 번이 아니라 짧은 주기로 반복되는 문제, 회사 내에서도 한 두 명의 문제가 아니라 대다수의 문제가 될 때 해결을 위한 개발을 한다. 잘 된 개발 한 번은 수 십 명분의 인건비를 절감하거나, 더 많은 고객을 끌어 매출을 확 올리는 길로 회사를 이끈다.
우리는 이렇게 고른 범용의 문제를 풀 때도 공통으로 발생하는 케이스만 빠르게 처리하기 위해 개발을 고심한다. 흔하지 않게 발생하는 케이스는 별 에러 없이 지나갈 수만 있도록 만든다. 주된 속도를 빠르게 하기 위해서는 몇날 며칠 고민하지만, 흔하지 않게 발생하는 케이스를 빠르게 만들려는 노력은 시간이 남지 않는 한 하지 않는다.
요컨대, 디테일한 문제까지 디지털 전환하기 위해 노력하지 않는다는 말이다.
디지털 전환이 화두가 되면서 업무 전체 프로세스를 어떻게 효율화할 수 있는지 얘기가 나온다. 이미 하고 있는 비디지털 방식이 비효율적이라는 전제가 깔려 있는 것 같다. 전제를 바꾸어 본다. 지금 돌아가는 산업의 방식은 수 십 년에 걸쳐 사람들이 찾아놓은 디지털 직전의 효율성들이다. 최대한 이용하는 것이 어떨까.전체 업무 프로세스를 그림으로 도식화하면서 문제 지점들을 생각해보지 말고 딱 떠오르는 하나의 범용의 문제부터 정의하면 좋겠다. 컴퓨터공학 1학년 때 배우는 문장은 "Common case fast"이다.
