.jpg)
로우코드는 소프트웨어가 갈수록 중요해지는 지금 상황에서 상당한 주목을 받고 있는 기술이다. 모든 사람을 개발자로 만들어 줄 수 있다는 기대감도 생겨나고 있다. 하지만 그런 기대를 충족시킨 사례는 아직까지 존재하지 않는다.
[보안뉴스 문정후 기자] 로우코드 솔루션과 플랫폼들은 코딩에 대한 깊은 이해 없이도 유용한 소프트웨어를 만들 수 있게 해 준다. 아직 시장에서의 평가는 갈리는 편이다. 하지만 2025년까지 70%의 새 애플리케이션들이 로우코드 플랫폼을 통해 개발될 거라는 예측이 나올 정도로 인기가 높아지는 건 사실이다. 아직까지는 로우코드의 장점들이 크게 평가되고 있는 것으로 보인다.
로우코드 솔루션들은 최근 몇 년 동안 크게 향상됐다. 그럼에도 비판적인 의견들이 사그라들지 않고 있는데, 거기에는 이유가 있다. 이른 바 ‘시민 개발자’의 활동을 왕성하게 하고, 그에 따라 개발자가 짊어진 부담감을 나눠 갖는 데에 장점이 있는 건 사실이지만 한계 역시 분명하기 때문이다. 로우코드로 모든 애플리케이션을 만들 수는 없다는 것이다. 아니, 로우코드로 만들 수 있는 애플리케이션은 정해져 있다고 봐야 한다.
그렇다는 건 로우코드로 할 수 있는 일이 있고, 할 수 없는 일이 있다는 뜻이다. 아무 회사나 로우코드를 도입해 시민 개발자를 육성할 수 없다. 상황에 따라 로우코드가 유용할 것인지 아닌지 잘 판단해야 한다. 로우코드를 도입하게 되는 시나리오들을 몇 가지로 정리해 보면 다음과 같다.
시나리오 1 : 개발자가 확연히 부족할 때
현재 세계에서 가장 ‘귀하신 몸’은 단연 개발자들이다. 어느 조직에서나 개발자 한 명이라도 더 모시려고 애를 쓰고 있다. 하지만 유능한 개발자의 수는 한정되어 있고, 따라서 개발자가 부족한 상태로 사업을 꾸려가야 하는 기업들이 대부분이다. 이런 상황에서라면 비개발자들에게 로우코드를 제공해 어느 정도 개발자를 영입한 것과 같은 효과를 노릴 수 있다, 라고 생각한다면 오산이다.
로우코드를 도입해 일반 개발 작업에 일반 직원들을 참여시키려면 오히려 개발자가 더 필요하다. 로우코드를 통해 만든 소프트웨어들은 전문 개발자들의 검사를 반드시 거쳐야 하기 때문이다. 게다가 전문 개발자의 총괄 없이 개개인이 소프트웨어를 마구 개발해 봐야 쓸모 없는 결과들만 나올 확률이 많다. 하나로 관통하는 전체적인 전략 아래 개발이 진행되어야 한다. 로우코드는 문제 해결의 한 방법이지, 모자라는 개발자를 보충하라고 존재하는 게 아니다.
시나리오 2 : 사업 성장이 너무나 빠를 때
사업 성장의 초기 단계에서 로우코드는 꽤나 강력한 가속을 걸어줄 수 있다. 낮은 비용을 가지고, 급한 서비스를 빠르게 개발해 보충할 수 있기 때문이다. 하지만 위에서 언급했듯이 로우코드에는 한계가 존재한다. 로우코드 애플리케이션들은 말 그대로 사업 초기에 급한 필요를 충족시키기 위해 사용될 때 적절할 뿐, 끝까지 유지될 만한 건 아니다. 언젠가는 전문 개발자가 정식으로 개발한 애플리케이션으로 대체되어야 한다.
시나리오 3 : 사업에 꼭 필요한 소프트웨어를 새로 개발해야 할 때
소프트웨어에 대한 의존도가 높은 사업을 하고 있다면, 그리고 사업에 필수적인 소프트웨어를 새로 개발해야 하는 상황에서라면 로우코드는 절대로 피해야 한다. 사업에 필수적인 소프트웨어라면 안정적인 확장성과 유연성이 보장되어야 한다. 각종 상황에 대처할 수 있어야 하기 때문이다. 중요한 소프트웨어일수록 시민 개발자가 아니라 전문 개발자에게 맡기는 게 안전하다.
시나리오 4 : 각 부서들에 독자적인 개발 능력을 부여하고 싶을 때
IT와 관련이 없는 여러 사업 부서들에 독자적인 개발 능력을 부여하고, 이를 통해 테크놀로지 흡수력과 적응력을 높이고 싶을 때라면 로우코드가 제격이다. 로우코드는 개발이라는 것을 처음 익히는 사람들에게 매우 친절한 플랫폼이다. 초심자들이 IT에 흥미를 갖게 하는 데에 알맞다. 다만 위에서 강조했던 것처럼 이렇게 개발을 익힌 ‘시민 개발자’들에게 중요한 프로젝트를 맡기지 않는다는 전제가 깔려 있어야 한다.
균형의 중요성
로우코드가 처음 나왔을 때 개발자 인력 부족을 해결해 줄 궁극의 해결책인 것처럼 광고됐었던 것이 사실이다. 하지만 적어도 지금까지는 이게 제대로 실현되지 않고 있다. 아니, 그런 광고 메시지들이 과장되었다는 것이 계속해서 증명되는 중이다. 로우코드는 전혀 그런 목적을 가진 플랫폼이 아니다. 제대로 된 사용처가 있어야 빛을 발하는 기술이다. 그러므로 로우코드에 대해 알아보기 전에 제일 먼저 여러 가지 질문을 스스로에게 할 필요가 있다.
1. ‘시민 개발자’가 될 만한 직원들이 몇 명이나 있는가? 그 ‘시민 개발자’를 감독할 개발자들의 수와 역량이 어떠한가?
2. 핵심 소프트웨어를 만들어야 하는가, 아니면 부수적인 소프트웨어가 필요한가?
3. 로우코드로 제작하려고 하는 소프트웨어가 나중에 핵심 소프트웨어로 성장할 가능성이 얼마나 되는가?
4. 회사의 성장 속도가 어떠하며, 가까운 미래에 어떤 성장 가능성을 가지고 있는가?
모든 솔루션들이 그렇지만, 로우코드 역시 만능 해결책이 될 수 없다. 개발자의 부족 문제를 해결하기 위한 기술도 아니다. 시민 개발자를 거느려야 할 필요와 명분이 분명한 곳에서만 한정적으로 가치를 발휘할 수 있다. 그러니 시장에 어떤 로우코드가 존재하는지 알아보는 것보다 우리 회사가 로우코드를 적절히 활용할 수 있는 상황인지를 더 면밀히 검토해야 한다.
글 : 마이크 메이슨(Mike Mason), CTO, Thoughtworks
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 로우코드 솔루션과 플랫폼들은 코딩에 대한 깊은 이해 없이도 유용한 소프트웨어를 만들 수 있게 해 준다. 아직 시장에서의 평가는 갈리는 편이다. 하지만 2025년까지 70%의 새 애플리케이션들이 로우코드 플랫폼을 통해 개발될 거라는 예측이 나올 정도로 인기가 높아지는 건 사실이다. 아직까지는 로우코드의 장점들이 크게 평가되고 있는 것으로 보인다.
[이미지 = utoimage]
로우코드 솔루션들은 최근 몇 년 동안 크게 향상됐다. 그럼에도 비판적인 의견들이 사그라들지 않고 있는데, 거기에는 이유가 있다. 이른 바 ‘시민 개발자’의 활동을 왕성하게 하고, 그에 따라 개발자가 짊어진 부담감을 나눠 갖는 데에 장점이 있는 건 사실이지만 한계 역시 분명하기 때문이다. 로우코드로 모든 애플리케이션을 만들 수는 없다는 것이다. 아니, 로우코드로 만들 수 있는 애플리케이션은 정해져 있다고 봐야 한다.
그렇다는 건 로우코드로 할 수 있는 일이 있고, 할 수 없는 일이 있다는 뜻이다. 아무 회사나 로우코드를 도입해 시민 개발자를 육성할 수 없다. 상황에 따라 로우코드가 유용할 것인지 아닌지 잘 판단해야 한다. 로우코드를 도입하게 되는 시나리오들을 몇 가지로 정리해 보면 다음과 같다.
시나리오 1 : 개발자가 확연히 부족할 때
현재 세계에서 가장 ‘귀하신 몸’은 단연 개발자들이다. 어느 조직에서나 개발자 한 명이라도 더 모시려고 애를 쓰고 있다. 하지만 유능한 개발자의 수는 한정되어 있고, 따라서 개발자가 부족한 상태로 사업을 꾸려가야 하는 기업들이 대부분이다. 이런 상황에서라면 비개발자들에게 로우코드를 제공해 어느 정도 개발자를 영입한 것과 같은 효과를 노릴 수 있다, 라고 생각한다면 오산이다.
로우코드를 도입해 일반 개발 작업에 일반 직원들을 참여시키려면 오히려 개발자가 더 필요하다. 로우코드를 통해 만든 소프트웨어들은 전문 개발자들의 검사를 반드시 거쳐야 하기 때문이다. 게다가 전문 개발자의 총괄 없이 개개인이 소프트웨어를 마구 개발해 봐야 쓸모 없는 결과들만 나올 확률이 많다. 하나로 관통하는 전체적인 전략 아래 개발이 진행되어야 한다. 로우코드는 문제 해결의 한 방법이지, 모자라는 개발자를 보충하라고 존재하는 게 아니다.
시나리오 2 : 사업 성장이 너무나 빠를 때
사업 성장의 초기 단계에서 로우코드는 꽤나 강력한 가속을 걸어줄 수 있다. 낮은 비용을 가지고, 급한 서비스를 빠르게 개발해 보충할 수 있기 때문이다. 하지만 위에서 언급했듯이 로우코드에는 한계가 존재한다. 로우코드 애플리케이션들은 말 그대로 사업 초기에 급한 필요를 충족시키기 위해 사용될 때 적절할 뿐, 끝까지 유지될 만한 건 아니다. 언젠가는 전문 개발자가 정식으로 개발한 애플리케이션으로 대체되어야 한다.
시나리오 3 : 사업에 꼭 필요한 소프트웨어를 새로 개발해야 할 때
소프트웨어에 대한 의존도가 높은 사업을 하고 있다면, 그리고 사업에 필수적인 소프트웨어를 새로 개발해야 하는 상황에서라면 로우코드는 절대로 피해야 한다. 사업에 필수적인 소프트웨어라면 안정적인 확장성과 유연성이 보장되어야 한다. 각종 상황에 대처할 수 있어야 하기 때문이다. 중요한 소프트웨어일수록 시민 개발자가 아니라 전문 개발자에게 맡기는 게 안전하다.
시나리오 4 : 각 부서들에 독자적인 개발 능력을 부여하고 싶을 때
IT와 관련이 없는 여러 사업 부서들에 독자적인 개발 능력을 부여하고, 이를 통해 테크놀로지 흡수력과 적응력을 높이고 싶을 때라면 로우코드가 제격이다. 로우코드는 개발이라는 것을 처음 익히는 사람들에게 매우 친절한 플랫폼이다. 초심자들이 IT에 흥미를 갖게 하는 데에 알맞다. 다만 위에서 강조했던 것처럼 이렇게 개발을 익힌 ‘시민 개발자’들에게 중요한 프로젝트를 맡기지 않는다는 전제가 깔려 있어야 한다.
균형의 중요성
로우코드가 처음 나왔을 때 개발자 인력 부족을 해결해 줄 궁극의 해결책인 것처럼 광고됐었던 것이 사실이다. 하지만 적어도 지금까지는 이게 제대로 실현되지 않고 있다. 아니, 그런 광고 메시지들이 과장되었다는 것이 계속해서 증명되는 중이다. 로우코드는 전혀 그런 목적을 가진 플랫폼이 아니다. 제대로 된 사용처가 있어야 빛을 발하는 기술이다. 그러므로 로우코드에 대해 알아보기 전에 제일 먼저 여러 가지 질문을 스스로에게 할 필요가 있다.
1. ‘시민 개발자’가 될 만한 직원들이 몇 명이나 있는가? 그 ‘시민 개발자’를 감독할 개발자들의 수와 역량이 어떠한가?
2. 핵심 소프트웨어를 만들어야 하는가, 아니면 부수적인 소프트웨어가 필요한가?
3. 로우코드로 제작하려고 하는 소프트웨어가 나중에 핵심 소프트웨어로 성장할 가능성이 얼마나 되는가?
4. 회사의 성장 속도가 어떠하며, 가까운 미래에 어떤 성장 가능성을 가지고 있는가?
모든 솔루션들이 그렇지만, 로우코드 역시 만능 해결책이 될 수 없다. 개발자의 부족 문제를 해결하기 위한 기술도 아니다. 시민 개발자를 거느려야 할 필요와 명분이 분명한 곳에서만 한정적으로 가치를 발휘할 수 있다. 그러니 시장에 어떤 로우코드가 존재하는지 알아보는 것보다 우리 회사가 로우코드를 적절히 활용할 수 있는 상황인지를 더 면밀히 검토해야 한다.
글 : 마이크 메이슨(Mike Mason), CTO, Thoughtworks
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
