로우코드와 노코드를 도입하기 전에 물어야 할 세 가지 질문

로우코드와 노코드의 도입률이 빠르게 증가하고 있다. 개발 지식 없이도 앱을 만들 수 있다니 너무나 당연한 현상이다. 하지만 아무나 개발자가 될 수 있다는 그 엄청난 약속에 쉽게 현혹되어서는 안 된다. 어느 신기술이나 그렇지만 한계가 분명하기 때문이다.

소프트웨어나 앱 개발에 대한 이해도를 높이려면 공부를 많이 해야 했다. 소프트웨어 개발사를 창립할 수 있어도, 만들어지는 제품들은 개발자가 만들었고, 창립자들은 도통 이해할 수 없었다. 그래서 믿을 만한 프로그래머를 고용하거나 주구장창 IT 분야 컨설턴트를 찾아가서 상담을 받아야만 했다. 그런데 지난 몇 년 동안 로우코드와 노코드라는 기술과 플랫폼들이 등장하면서 코딩 비전문가들에게 한 줄기 서광이 비치기 시작했다. 각고의 학습 과정 없이도 앱을 구성하고 실험할 수 있게 된 것이다.

로우코드와 노코드 플랫폼의 인기는 급상승하는 중이다. 가트너(Gartner)가 조사한 바에 의하면 2020년 이러한 플랫폼들을 통해 만들어진 애플리케이션은 약 25%였다. 2025년에는 이 수치가 70%에까지 이를 것으로 가트너는 예상하고 있다.

프로그래밍에 대해서는 아는 바가 없는 상태로 프로젝트와 사업을 관리해야 하는 입장에서 로우코드와 노코드 기술 관련 소식을 무시하기는 힘들다. 이미 다양한 산업에서 성공 스토리가 나오고 있기도 하다. 소프트웨어 엔지니어들이 모자라기도 하니, 귀가 번쩍 뜨일 수밖에 없는 게 바로 이 로우코드와 노코드다. 그러나 주의해야 한다. 세상에 공짜는 없으니까. 프로그래밍 공부를 하지 않고도 프로그래머가 될 수 있다니, 곧이 곧대로 믿기가 힘들 정도다. 반가운 소식이지만 분명 어디엔가 지불해야 할 것들이 있을 거라는 찜찜함도 존재한다. 

그렇기 때문에 애플리케이션 개발 사업을 이제 막 시작했으면서 로우코드와 노코드 플랫폼에 대해 적극적으로 알아보려는 입장에서 반드시 물어야 할 질문들이 있다. 필자는 그 중 세 가지를 나누고자 한다.

1) 고객들에게 제공하려는 것이 무엇인가? 정확히 어떤 경험을 고객들에게 주려고 하는가? 이미 시장에는 로우코드와 노코드를 사용해 이룰 수 있는 다양한 가능성들이 제시되어 있고, 더 많은 것들이 나타날 것이다. ‘로우코드와 노코드로 이런 걸 개발할 수 있다’는 약속들이 무궁무진해지고 있다는 것이다. 여기에 휩쓸리면 안 된다. 어느 신기술이나 다 그렇지만 로우코드와 노코드라고 해서 만능 해결책인 것은 아니다. 머릿속으로 그려만 오던 꿈의 애플리케이션이 IT 지식 제로인 상태에서 클릭 몇 번으로 완성되지는 않는다. 

심지어 로우코드와 노코드가 같은 것도 아니다. 이 둘은 애플리케이션 개발에 있어 완전히 다른 두 가지 방법론을 뜻한다. 로우코드와 노코드를 묶어서 말하는 건 엄밀히 말해 틀린 것이라고 볼 수 있다. 둘 중에 노코드는 좀 더 한계가 분명하다. 아무래도 전혀 코딩을 하지 않고 애플리케이션을 만드는 것이니 만큼 한계가 있을 수밖에 없다. 노코드로 만든 애플리케이션을 보다 광범위하게 활용하려면 전문 개발자와 엔지니어가 손을 봐야 한다. 극단적으로 말해 노코드만 믿고 소프트웨어 개발사를 차릴 수는 없다.

여기서 로우코드와 노코드의 단점 하나를 짚고 넘어가야 한다. 로우코드나 노코드로 만든 애플리케이션은 ‘개성’ 혹은 ‘차별성’이라는 측면에서 큰 약점을 가질 수밖에 없다. 노코드와 로우코드 플랫폼에서 제공하는 요소들을 활용해 레고처럼 조립하는 방식으로 애플리케이션을 개발하는 건데, 플랫폼의 사용자들 이 같은 요소 – 즉 같은 재료 -를 활용하다보니 어느 정도는 대동소이해질 수밖에 없다. 매우 보편적인 결과물이 나올 공산이 크다는 것이다. 

2) 사업을 어느 정도나 진행한 상태인가? 이는 다시 말해 현재의 사업 규모가 어느 정도 되느냐를 묻는 질문이라고 할 수 있다. 초기에는 사업 규모도 작고, IT 기술이나 지식이 크게 많이 필요하지 않을 수 있다. 조직 내 자원으로도 충분히 일을 진행할 수도 있다. 아직 사업 규모가 크지 않고 예산도 넉넉하지 않아 개발자를 고용할 여력이 되지 않을 수 있는데, 이럴 때 로우코드나 노코드 기술이 중요한 역할을 할 수 있다. 완성된 애플리케이션을 만들거나, 로우코드/노코드로는 잘 되지 않는 부분만 파트타임 개발자에게 맡긴다면 비용을 아낄 수 있다.

3) 현재의 디지털 아키텍처가 직접 구축한 것인가, 서드파티 솔루션을 구매하거나 외주 전문가에게 맡겨서 나온 것인가? 즉, 빌드(build)인가, 바이(buy)인가? 사업 운영에 있어 가장 중요한 것 중 하나는 운영의 안정성을 유지하는 것이다. 그러려면 핵심이 되는 시스템들 중 일부는 자동화로 안정적으로 운영하는 것이 좋다. 그러면서도 이 핵심 시스템들은 진화해야 하는데, 그건 사업이라는 게 계속 커지기 때문이다. 그러면서 다양한 기능들이 추가되고, 시스템과 트래픽, 데이터의 양도 늘어난다. 

이런 미래를 앞두고 있을 때 우리 아키텍처가 직접 구축한 것인지 아니면 어디서 사온 것인지를 알아보는 건 중요하다. 서드파티가 아키텍처를 맡았다면, 사실 확장성이라는 측면에서 불리할 때가 많다. 서드파티 업체들도 사업을 해야 하기 때문에 고객사인 당신이 확장을 할 때마다 추가 요금을 요구할 것이기 때문이다. 아키텍처 유지를 위해 내야 하는 비용이 커진다는 뜻이다. 

그러니 어느 조직이나 언젠가는 아키텍처를 독자적으로 구성해야만 한다. 이럴 때 한두 개발자가 모든 부서들의 업무를 위한 애플리케이션들을 개발하고, 그것을 이어붙여 거대 아키텍처를 구성하기는 힘들다. 이럴 때 각 부서별로 로우코드나 노코드 플랫폼에서 자신들의 업무 특성을 반영한 프로토타입을 스스로 만들면 상당히 도움이 된다. 개발 가이드라인 등을 IT 팀에서 미리 정해 알려주고, 나중에 미세 조정을 통해 손을 보면 시간과 노력을 아낄 수 있다. 물론 훗날 규모가 일정 수준 이상 커지면 클라우드 등의 전문 아키텍처로 넘어가야 하겠지만, 그 기간까지 로우코드와 노코드가 꽤나 도움이 될 수 있다.

로우코드와 노코드는 적절한 맥락 안에서 활용되어야 진정한 가치와 힘을 발휘한다. 그러려면 로우코드와 노코드를 이용하려는 입장에서 할 수 있는 일과 할 수 없는 일을 미리 조사해서 도입해야 한다. 어디선가 좋다는 풍문만 듣고 덥썩 물면 돈만 쓰고 기대했던 효과는 거두지 못하게 된다. 로우코드와 노코드가 어디에 강점이 있으며, 그 강점이 지금 우리 조직의 상황에 맞는지를 객관적으로 비교하는 것이 중요하다.

출처:https://www.boannews.com/media/view.asp?idx=112707

이 게시글이 문제가 될 시, 삭제하겠습니다