'클릭 몇 번으로 앱 만든다?'··· 로우 코드의 가능성과 한계

지난 몇 년 동안 '로우 코드(low-code)' 개념이 주목 받았다. 애플리케이션, 특히 데이터 세트 관리와 처리를 위한 인 하우스 애플리케이션 제작에 필요한 프로그래밍을 완전히 없애거나 줄여줄 것으로 기대를 모았다.



새로운 애플리케이션을 처음부터 새로 만들 필요 없이, 개발자(그리고 어쩌면 비 개발자까지도)가 시각적 개발 환경 내에서 다양한 리소스를 조합하기만 하면 된다. 버튼 몇 개만 클릭하면 '짜잔!'하고 새로운 애플리케이션이 등장한다는 것이다.

이는 로우 코드가 많은 주목을 받은 이유였다. 실제로 많은 기관에서 기하급수적으로 늘어나는 데이터 세트를 관리하기 위한 애플리케이션을 인 하우스로 제작하는 데 상당한 어려움을 겪고 있다. 이런 조직에 로우 코드는 한 줄기 희망이며, 성가신 코딩 작업을 API, 애플릿 그리고 서비스에 떠넘기는 좋은 방법이었다. 어떤 의미에선 마치 공상 과학 영화와 같은 요소를 품고 있기도 하다. 블록을 가져다가 클릭만 하면 앱이 된다니!

정말 이렇게만 된다면, 프로그래머가 무슨 필요가 있겠는가? 이론적으로, 로우 코드는 애플리케이션 개발 자체를 기술 전문가의 영역에서 끌어내 비즈니스 애널리스트와 고객 지향적 매니저의 통제 하에 둘 수 있는 수단이 될 수 있다. 애널리스트가 생성한 플로우 차트를 로우 코드 명령어로 치환하고, 이를 다시 필요한 소프트웨어로 직접 변환할 수 있기 때문이다. 이렇게 하면 오해나 의사소통 문제도 줄고, 더 빠르고 간단하게 애플리케이션을 개발할 수 있게 될 것이다.

그러나 여기에는 문제가, 그것도 매우 심각한 문제가 하나 있다. 프로그래밍에는 기술과 경험, 그리고 특정한 마인드 세트가 요구된다. 유능한 프로그래머는 끈기와 문제해결 능력, 논리에 기반한 업무 전략, 에러에 대한 기계적인 배제, 디테일에 대한 놀라운 집중력, 그리고 십 수 가지가 넘는 변수, 루틴 등을 저글링 할 수 있는 역량을 갖추고 있다.

물론 능력에 비해 임금이 너무 적은 느낌이 드는 경우도 있지만 그것은 프로그래밍이 이만큼 고도로 집중과 역량을 필요로 하는 작업이라는 걸 이해하지 못하는 기업 탓이지 프로그래머의 잘못은 아니다. 즉, 프로그래밍은 말로는 쉬워 보여도 실제로 해보면 절대 그렇지 않은 작업이라는 것이다.

이 작업에서 코딩 파트를 제거하거나 축소한다 해도 생각한 만큼 영향이 크지는 않을 것이다. 코딩은 결국 개발 아이디어를 구현하는 것이다. 하지만 코드 상당 부분을 블록으로 대체한다 해도 결국 아이디어를 '구현'하는 역량은 필요하며 오히려 코딩할 때보다 더 고 난이도의 작업이 될 것이다.

컴퓨팅의 역사에서 예를 찾을 수 있다. 고급 언어(high-level language)가 등장했다고 해서 어셈블리 언어(assembly language) 프로그래머가 전부 실직자가 된 것도 아니고, 또 어셈블리 언어 자체에 대한 수요가 완전히 사라지지도 않았다. 오히려 기존 프로그래머가 새 언어에 맞춰 자신의 역량을 새롭게 사용하였을 뿐이다.

고급 언어는 분명 어느 정도 진입 장벽을 낮추긴 했지만, 그것이 반드시 좋은 것이라고 볼 수도 없다. 프로그래머가 많다고 소프트웨어가 더 나아진다는 보장은 없기 때문이다. 플론의 법칙(Flon's law)이 보여주듯 저 품질 프로그램을 만들기에 '가장 덜 어려운' 언어는 지금도, 앞으로도 존재하지 않을 것이다.

로우 코드 개발도 예외는 아니다. 오히려 프로그래머가 되기 위한 장벽이 더 낮아짐에 따라 소프트웨어 품질이 저하되지 않으면 다행이다. 비즈니스 애널리스트가 플로우 차트에 각종 아이템을 드래그해 '앱 제작' 버튼을 클릭한다 해도, 결국 녹록하지 않은 현실과 복잡하고 지저분한 데이터 세트 앞에 마주하면 쉽고 간편하고 깔끔한 애플리케이션 개발이라는 꿈은 난관에 부딪힐 수 밖에 없다.


로우 코드 프로세스는 일반적으로 다음과 같이 설명할 수 있는데, 이것 만으로도 많은 바를 시사하고 있다.

1. 비주얼 IDE(통합 개발 환경, integrated development environment)를 이용해 프로세스를 구상한다.
2. 각종 앱, 서비스, 라이브러리 등을 호출해 실제 작업을 한다.
3. 필요하다면 여러 요소를 통합하기 위해 약간의 코딩을 가미한다.
4. 디플로이 한다.

진짜 단순하고 기본적인 앱 제작을 제외하고서는, 아마도 3단계에서 막히게 될 확률이 높다. 이 단계에서는 로우 코드 개발자 역시 프로그래머의 도움이 필요하기 때문이다. 처음에는 SQL 쿼리 몇 개만을 추가하는 것으로 시작할 지 몰라도, 조금만 애플리케이션이 복잡해 지면 걷잡을 수 없이 일이 커질 것이다.

더 냉소적인 이들은 그래서 로우 코드 이야기가 나올 때마다 "마케팅 부서에서 과연 얼마나 좋은 소프트웨어를 만들어 낼지 정말 기대된다"며 비꼬기도 한다. 그런가 하면 로우 코드라는 개념 자체가 사실은 제대로 된 애플리케이션을 만드는 게 얼마나 어렵고 힘든 일인지를 깨닫게 하기 위해 프로그래머 스스로가 만들어 냈다는 장난스러운 이야기 하는 이들도 있다(이쯤되면 철지난 '급속 애플리케이션 개발(rapid application development)' 같은 유행어도 떠오를 것이다).

너무 한다고 생각할 수도 있지만, 이런 냉소적인 태도에는 다 이유가 있다. 기업은 오랜 경험을 통해 업무를 IT, 판매, 마케팅, 개발, PR 등 여러 부서로 세분화해 처리한다. 그래야 일이 되기 때문이다. 이처럼 분업과 전문화를 했을 때 가장 만족스러운 결과가 나왔다. 설령 이러한 분화로 인해 부서간 커뮤니케이션이 더 복잡하고 어려워 진다고 해도 말이다.

PR 담당자가 어느 날 갑자기 코딩을 할 수 없고, 개발자가 어느 날 영업을 시작하는 것도 비현실적이다. 물론 자신의 전문 분야가 아닌 곳에서 일을 하는 사람이 아예 없지는 않지만, 이 경우 결과물은 상대적으로 비효율적이다. 예외는 있을지 모르지만, 어디까지나 예외일 뿐이다. 비즈니스 애널리스트가 전문 코더보다 더 코딩을 잘 할 수 있을리 없다.

그래서 설령 로우 코드 전략을 도입한다고 해도, 개발의 실질적인 업무는 여전히 프로그래머에게 집중될 가능성이 높다. 로우 코드로 일부 애플리케이션 개발기간을 줄일 수 있을지 모르지만 사실 이 개념도 전혀 새로운 것이 아니다. 10여 년 전, 객체 지향 프로그래밍(object-oriented programming)과 라이브러리에서 시작됐다.

오늘날도 모든 프로그래머가 새로운 애플리케이션을 만들 때 옛날 코드 일부를 재사용한다. 로우 코드의 빌딩 블록이 아무리 크다 해도, 여전히 기술과 재능, 그리고 경험을 가진 개발자가 이들을 적절히 조합해 주지 않는 이상 유용하고 효과적이며, 확장성까지 갖춘 결과물이 나오기 어렵다.

따라서 기업은 로우 코드를 개발 병목 현상의 해결책으로 신뢰해서는 안된다. 로우 코드는 능숙한 코더를 도와 애플리케이션 개발의 일정 부분을 더 신속하고 깔끔하게 하는 데 도움을 주는 보조 역할만을 할 뿐, 실제 프로그래머를 대체 할 수는 없다. 로우 코드 이니셔티브 도입을 고민하는 기업, 특히 비 전문가에게 개발 자체를 일임하려던 기업은 녹록지 않은 현실에 부딪혀 적잖이 충격 받게 될 것이다.

세상에는 참으로 형편 없고, 버그투성이에, 쓸모 없는 소프트웨어가 많다. 성공적인 기업이라면 굳이 여기에 하나를 더 추가하게 될 뿐인 선택을 하지는 않을 것이다. 생산성 병목 현상이 소프트웨어를 인 하우스로 개발하는 속도가 느려서 발생하는 것이라면, 가장 근본적인 해결책은 유능한 개발자를 더 많이 고용하는 것이다. ciokr@idg.co.kr