자세히 보기

Mary Branscombe
Contributing writer

‘잘 써야 혁신 보약’··· 로우코드 관리 조언 8가지

기업 내 ‘앱 공백’을 메우기 위해 사용할 수 있는 로우코드 및 노코드 도구가 부상하고 있다. 가트너에 따르면 2023년이면 ‘시민 개발자’가 전문 개발자보다 4배나 많아질 전망이다.

대부분의 조직들은 이미 적어도 1개의 로우코드 도구를 사용하고 있다. 머지않아 코드를 작성하지 않고 앱을 개발하는 것이 이메일과 스프레드시트 등의 비즈니스 스킬처럼 보편화될 것이라고 포레스터(Forrester)는 전망했다.

하지만 개발 속도가 빨라지면 위험도 커진다. 셀프서비스와 로우코드로 인해 자율성이 증가하면서, 거버넌스가 주요 IT 고려사항이 되었다고 가트너가 밝혔다.

바람직한 거버넌스 구조가 아직 확립되지는 않았지만 IT 리더들이 로우코드 관리 문제에 대한 해결을 시도하고 나섰다. 포레스터의 수석 분석가 존 브라틴세빅은 “많은 사람들이 기술 업무를 수행할 수 있도록 하는 동시에 어느 정도 정돈된 방식이 마련되기를 추구하고 있다”라고 밝혔다.

로우코드 플랫폼은 생산성 개선, 비용 절감, 비즈니스와 IT 사이의 관계를 개선하는 문화적 변화를 가져온다. 제대로 한다면 로우코드는 조직이 디지털 문제 해결의 문화를 통해 비즈니스 전환이 항상 약속했던 지속적인 개선을 달성하는 데 도움이 될 수 있다. CIO가 실험과 셀프서비스를 저해하지 않고 위험을 완화하는 실용적인 방식에 대한 조언을 살펴본다.

셰도우 IT에서 벗어나라
로우코드 접근법이 성공하기 위해서는 IT 리더가 이를 비승인 IT로써 처리해서는 안 되며 CIO가 이를 잠재적인 부담으로 보아서도 안 된다고 가트너의 VP 분석가 제이슨 웡이 말했다.

그는 “시민 개발의 목적은 IT와 비즈니스 사이에서 합의하고 시민 개발자가 참여하고 기여하도록 하는 것이다. 그들에게 가장 적합한 도구가 무엇인지 이해해야 한다”라고 말했다.

로우코드 및 노코드 플랫폼은 앱을 시각적으로 개발하는 방법만을 제공하는 것이 아니다. 그것들은 액세스와 리소스를 중앙에 집중시키고 이것들이 사용되는 방식을 추적한다. 이 때문에 IT는 누가 어떤 데이터 소스에 액세스하고 그 데이터가 통합된 앱 및 자동화 흐름을 공유하도록 할 수 있는 방법에 관한 정책을 수립할 수 있다.

세부적인 역할 기반 액세스 컨트롤을 통해 IT는 해당 분야와 기록 수준까지 특정 종점과 데이터 테이블에 대한 액세스를 관리하여 개발 환경에 대한 적절한 액세스를 제공할 필요가 있다.

또한 사용할 수 있는 커넥터와 엔드포인트에서 그들이 취하는 조치를 관리할 수 있어야 한다. 예를 들어, 고객 지원가 트윗을 읽을 수 있지만 게시할 수 없는 앱을 구축하도록 지원할 수 있다. 또는 전사적으로 로우코드 사용자가 기록을 업데이트하지만 절대로 그 무엇도 삭제하지 않도록 설정할 수도 있다.

통제와 자율성의 균형을 맞추라
시민 개발자와 관련해 통제와 자율성의 적절한 균형을 맞추는 것이 중요하다. 보안이 부실해서는 안 되지만, 거버넌스와 액세스 프로세스가 너무 부담스러워도 곤란하다. 후자의 경우라면 사람들은 셰도우 IT로 회귀할 것이다.

이를 위해 계획이 필요할 것이라고 브라틴세빅이 밝혔다. 그는 “엄청나게 복잡하지는 않지만 이 모든 것을 고려해야 하며 환경에 따라 다르다. 거버넌스를 설정할 수 있으려면 데이터가 핵심이다. 각 기업에게 어떤 데이터가 있고 무엇이 민감한지가 중요하다”라고 말했다.

외부적으로 공유된 데이터에 데이터 유출 보호를 적용하고 시민 개발자들이 이메일 또는 PII 복사 등 준법감시를 위반할 수 있는 자동화 또는 워크플로를 구축하는 경우 경고하는 정책을 마련해야 한다.

시민 개발자는 플랫폼 선택에 대한 자율성도 있어야 한다. 비즈니스가 단일 로우코드 플랫폼으로 표준화하도록 강제하는 것은 실수라고 웡이 경고했다. 비즈니스 사용자가 도구를 선택할 권한이 없다면 시민 개발은 불가능하다는 설명이다. 대신 거버넌스 프레임워크에 의지하고 이런 사용자가 다른 도구를 선택하는 경우 어느 정도 지원을 기대할 수 있는지 확실히 밝히라고 웡이 말했다. 

그는 “할 수 있는 일의 범위가 있다. 안전한 구역이 있다. 공동 개발을 원하는 경우 공동 개발 및 지원이 가능한 것들이 있다. 단 도구 선택에 자율성을 부여하면 IT가 해당 플랫폼에 대한 교육을 제공하기는 어려울 것이다”라고 덧붙였다.

적절한 전략적 접근방식을 선택하라
조직의 시민 개발 문제를 위한 적절한 전략 모델을 수립하는 것도 핵심이다. 

포레스터는 3가지 공통적인 접근방식을 확인했다. 첫 번째는 프로세스 개선 경험이 있고 IT가 승인했지만 비즈니스 부서에 속해 있으며 비즈니스 임원에게 보고하는 사람들로 구성된 작지만 자율성이 있는 팀이다. 소규모 팀을 활용하는 이 전략적 접근방식은 매우 민첩하지만 확장되지는 않는다고 브라틴세빅이 설명했다. 

두 번째 접근방식은 셀프서비스다. 여기에서는 누구든 해당 플랫폼의 정책과 경계에 기초하여 로우코드 도구로 개발할 수 있다. 브라틴세빅은 “누구보다는 대상을 통제하는 것이다. 누구든 될 수 있지만, 대상은 플랫폼의 속성과 이에 제공하는 데이터 액세스에 의해 제한된다”라고 말했다.

세 번째는 가장 성숙한 접근방식이다. 애자일팀과 광범위한 민주화를 연합된 모델로 결합하고 전문가 조직이 로우코드 플랫폼을 관리하며 경계를 구현하고 부서와 사업부의 팀 또는 개인뿐 아니라 셀프서비스 로우코드 개발자를 지원한다.

이 모델에서는 특정 앱이 개발되는 방식이 사용 사례, 사용되는 데이터, 관련된 개발자의 경험에 따라 다르다고 브라틴세빅이 설명했다. 

그는 “보안 개발 라이프사이클의 진행 정도가 다를 수 있으며, 프리뷰에 대한 요건이 다를 수 있고, 특정 데이터 소스를 사용하기 전에 누군가와 협력해야 할 수 있다. 이 성숙된 모델은 더 복잡하지만 대부분의 범위에 적용되는 것이기도 하다. 데이터를 통제하고 개발 프로세스를 통제하지만 실용적으로 수행한다”라고 말했다.

적절한 IT 지원을 제공하라
거버넌스와 정책 외에 CIO는 리소스와 지원을 제공해야 한다. 가트너의 웡은 “생산성과 성공적인 결과를 위해 시민 개발자에 대한 IT의 태도가 매우 중요하다”라고 말했다.

이를 위해 가트너는 시민 개발자가 워크플로와 자동화를 생성할 수 있는 ‘녹색’ 안전 구역, 시민 개발자가 전문 개발자와 협력하여 더욱 강력한 애플리케이션을 개발하는 ‘노란색’ 지원 구역, IT 감독과 승인이 필요해 IT의 통제 하에 유지되는 ‘빨간색’ 위험 구역으로 분리된 거버넌스 프레임워크로 시민 개발을 구성하라고 조언했다.

예를 들어, 전문가 조직은 API와 사용자 정의 구성요소를 구성하거나 로우코드 및 전통적인 개발 환경에서 작업하는 프로 개발자를 통해 퓨전 팀을 지원할 수 있다. CoE는 아마도 근무 시간 중에 쿼리(Query) 표현 작성 등 더 복잡하거나 필수적인 작업을 위해 시민 개발자를 위한 학습 리소스와 전문적인 도움을 제공할 수도 있다.

이런 종류의 협업과 지원이 로우코드와 비승인 IT를 구별 짓는다. 웡은 “비승인 IT의 경우 개인들이 감독을 벗어나 자신의 판단에 따라 행동한다. 시민 개발에서는 사용자가 이런 도구를 사용했다고 질책을 받는 것에 대한 두려움이 없도록 이를 개방하는 것이 중요하다. 그들은 필요에 따라 학습할 수 있다. 그들은 단지 필요한 것을 배우고 상황에 따라 학습할 수 있도록 심층적으로 참여해야 하며, 커뮤니티, 다른 고급 사용자, IT에 도움을 요청할 수 있어야 한다”라고 말했다.

적절한 API와 커넥터를 확보하라
성공을 위해 IT는 선제적으로 커넥터를 제공하고 내부 데이터 액세스를 위한 탄탄한 API를 구성해야 한다.

API 플랫폼 포스트맨(Postman)의 수석 에반젤리스트 킨 레인은 “API가 잘 정의되어 있고 관리 계층 또는 카탈로그가 있으며 이런 로우코드/노코드 솔루션에 의해 손쉽게 연결되어야 한다”라고 말했다.

또한 생산 시 API가 사용되는 곳을 추적하여 외부 API의 비용을 처리하고 내부 API를 제공하는 시스템에 적절한 리소스를 제공해야 한다. API처럼 작동하는 모든 것이 탄탄한 백엔드에 의해 생성되는 것은 아니다. 레인은 “잘 설계된 RESTful API가 API를 구성한다고 생각하지만 사실은 그렇지 않다. CSV가 있는 FTP 위치는 API로 여겨지며, 스프레드시트가 중요하다”라고 밝혔다.

그리고 구형 시스템에서 정보를 가져다 로우코드 앱과 자동화 워크플로에 적용하기 위해 점차 사용이 확대되고 있는 RPA를 잊지 않아야 한다. 예를 들어, 스캔 된 PDF에서 데이터를 추출하는 것을 자동화하는 RPA 워크플로를 수립함으로써 IT는 시민 개발자가 도움이 되는 비즈니스 앱을 개발하도록 도울 수 있다.

검토와 지표를 잊지 말라
각자의 문제를 해결하고 있는 비즈니스 사용자는 높은 가용성, 비즈니스 지표, 공식적인 검토에 관해 생각할 가능성이 낮다. 이를 위한 도구가 포함되어 있는 로우코드 플랫폼은 거의 없지만 프로세스를 완료하는 데 소요되는 시간 등의 지표는 성능을 추적하고 추가적인 개발을 위한 기회를 분석하는 정기 검토를 도입할 수 있기 때문에 도움이 될 수 있다.

잘못된 프로세스를 자동화하면 나쁜 결과를 더 신속하게 얻게 되기 때문에 지표와 검토도 비즈니스 프로세스를 검증하는 기회를 제공한다. 프로세스 마이닝 도구를 사용하여 비효율성이나 일부 팀이 수행하고 있을 수 있는 추가적인 작업을 발견하고 실제로 프로세스에 참여하고 있는 직원이 문제에 대한 미봉책을 적용하는 앱을 개발하는 대신에 이를 간소화할 수 있는 기회를 제공한다.

필요에 따라 작업을 진전시키라
로우코드 플랫폼의 분석 및 모니터링 도구는 API 사용량을 추적할 수 있을 뿐 아니라 더 높은 계층의 노란색 또는 빨간색 지원 구역으로 이동할 필요가 있는 앱에 관해 알려준다고 가트너가 설명했다.

너무 인기가 많아서 추가적인 IT 지원이 필요한 앱이 되는 혁신적인 아이디어는 비즈니스 혁신의 조짐이라고 웡이 말했다. 이를 지속 가능하게 하는 것이 IT의 일이다.

실제로 이 진행 방식은 긴장을 유발할 수 있으며, 오리지널 로우코드 개발자는 IT가 도구를 관리하는 것에 대해 우려할 수 있다. 또 IT팀은 직접 개발하거나 지정하지 않은 앱을 지원하는 것에 대해 우려할 수 있다. 비즈니스와 IT 사이의 협업의 문화는 양쪽의 의혹을 방지하는 데 도움이 될 것이다.

혁신의 문화를 조성하라
로우코드 실험으로 인해 IT팀이 대응해야 하는 앱이 너무 많이 생성된다고 걱정할 수 있지만 이 전략이 효과가 있도록 충분한 모멘텀을 모으지 않는 것이 더욱 긴요한 문제다. 로우코드 정책으로부터 도움을 받을 수 있는 많은 비즈니스 사용자들이 스스로를 ‘개발자’라고 생각하지 않기 십상이라고 브라틴세빅이 지적했다.

그는 “기술적인 사고를 하는 많은 비즈니스인들이 기술적인 업무나 비승인 IT를 수행하고 있다. 하지만 그 일을 하는 사람들조차도 거버넌스 플랫폼이 있는 공식적인 프로그램을 반드시 신뢰하는 것은 아니다”라고 말했다.

많은 조직들이 교육, 멘토링, 지원을 제공하는 내부 해커톤으로 관심을 불러 일으키고 초기 앱의 핵심을 개발할 수 있다. 또한 얼리어답터로써 성장하고 있을 수 있는 문제 해결자들을 찾을 수 있 있다. 지속적인 개선 또는 특별 프로젝트가 수반된 역할의 일환으로 이미 비승인 IT를 이용하고 있는 사람들이 챔피언에 오를 주요 후보자이며, IT가 작업을 시작할 시간이 없었던 앱을 요청했었다면 더욱 그렇다.

로우코드를 통해 업무 양상이 크게 발전할 수 있으며, 비즈니스 및 최전방 직원들이 더욱 기술적인 역할을 위한 전문지식을 얻을 수 있다. 이것을 미래의 디지털 인력을 개발하는 것으로 생각하고, 직원들이 이를 달성할 수 있도록 지원하고 보상할 준비를 해야 한다. 

로우코드 프로그램이 확장되지 못하는 이유 중 하나는 직원들이 일상 업무의 일환으로서가 아니라 추가적인 업무로써 수행할 것이라는 기대치이며, 기업 문화에서 지속적인 개선을 중시하지 않는 경우 더욱 그렇다.

또한 변화 관리의 인간적인 측면에 대응해야 한다. 본래의 시민 개발자가 다른 직무로 이동하고 그들의 동료 또는 대체 인력이 그 앱을 담당하는 데 관심이 없다면 어떻게 될까? 아니면 그들이 관심이 있고 앱의 목적과 배경을 전달하기 위해 적절히 문서화되어 있다면 어떻게 될까?

한편, 모든 로우코드 앱이 영원이 유용하지는 않을 것이라고 웡이 말했다. 그 누구도 나서서 책임을 지지 않는다면 이렇게 가정해야 한다. 그렇게 유용하지 않았기 때문에 없애야 한다. 처음부터 구현 비용이 너무 낮은 경우에는 문제가 그리 크지 않다.

로우 코드를 기회로 생각하되 필수적이라는 점을 기억하라고 브라틴세빅이 말했다.

“완벽하지는 않을 것이다. 문제가 있을 것이며, 실수를 하겠지만 조직 전반에 걸쳐 앱을 개발하고 있는 사람들을 연결되고 자동화되며 합리적인 방식으로 조율하고 모든 것을 운에 맡기는 대신에 적절한 기초를 세울 수 있는 기회다”라고 그는 말했다. dl-ciokorea@foundryco.com

Mary Branscombe
Contributing writer

Mary Branscombe is a freelance journalist who has been covering technology for over three decades and has written about everything from programming languages, early versions of Windows and Office and the arrival of the web to consumer gadgets and home entertainment.

Her work has appeared in the Financial Times, The Sunday Times and the Guardian as well as several technology publications including The Register, CIO.com, InfoWorld, ComputerWorld, ZDNet, The New Stack, Ask Woody, TechRadar Pro, Tom’s Hardware, PC Advisor, and a long list of others. She founded and edited IT Expert magazine, which covered IT consultancy for the small business market.

Mary holds an M.A., Literae Humaniores from the University of Oxford and an M.Sc., Intelligent Knowledge Based Systems from the University of Essex.

이 저자의 추가 콘텐츠