Cursor, Bolt와 같은 AI코딩 서비스는 노코드를 어떻게 바꾸었나

대표이미지

"엥? 이제 와서?" 라고 생각하실지도 모르겠습니다. 얼마 전부터 새로운 프로젝트를 시작하면서 처음으로 Cursor와 Bolt를 체험했습니다. 신기술을 다루는 글을 쓰는 사람치고는 너무 늦은 시작이지요. 사실 이렇게 늦게 된 데에는 이유가 있습니다. 저는 1인 개발을 지향하는데 사실 1인 개발로 만들 수 있는 프로그램은 한계가 있고, 그 한계는 대부분 현존하는 노코드 툴로도 충분히 구현 가능하다고 생각했기 때문입니다. 그런데 아무래도 그 생각이 틀렸던 모양입니다.

결론부터 말하자면 AI 툴의 발전은 노코드 툴의 입지에는 거의 영향을 주지 못할 거라 생각합니다. 반대로 로우코드 툴의 입지에는 큰 영향을 주리라 생각합니다. 로우코드의 신봉자인 제가 정체성의 혼란을 느낄 정도로요.

노코드에 미래는 있는가?

정작 사용하는 사람들 사이에서도 이 용어는 종종 혼용되지만, 노코드와 로우코드 사이에는 꽤 명확한 차이가 있습니다. 기본적으로 두 방식은 UI와 드래그 앤 드롭 방식으로 캔버스에 컴포넌트를 채우는 방식으로 프로그램을 작성합니다. 이때 컴포넌트의 내부까지가 UI를 이용해서 채우는 경우 노코드 방식, 컴포넌트의 내부를 코드로 제작하게 된다면 로우코드 방식이라고 할 수 있습니다.

그렇기 때문에 노코드와 로우코드는 타겟 유저가 각 툴의 특징보다도 오히려 극명하게 갈라집니다. 노코드 툴은 코딩 지식이 전혀 없는 기획자가 선호하고 로우코드는 코딩 지식은 있지만 코딩에 필요한 시간을 절약하고 싶은 개발자가 선호하는 방향으로 말입니다.

그렇기 때문에 노코드 툴에 있어서 AI 코딩 툴의 등장은 전혀 위협이 되지 않습니다. 애초에 그들의 타겟 유저는 코딩을 할 수 없기 때문이죠. 오히려 노코드 툴에서 가장 번거롭고 손이 많이 가는 이미지 생성 작업에 있어서는 AI 툴로 만들어낸 이미지를 사용할 수 있다면 시너지 효과가 발생할 수도 있기 때문에 노코드 업계에서는 AI의 발전을 환영하고 있다고 생각합니다.

로우코드에 미래는 있는가?

문제는 로우코드 진영입니다. 개발자들이 로우코드를 선호하는 이유는 레이아웃 구성 등의 자잘한 요소에 신경 쓰지 않고 핵심적인 부분만을 개발하는 것으로 개발 효율성을 증가시키는 것이 목적인데, AI 코딩 툴을 사용하게 되면 AI가 자동으로 레이아웃 등의 요소를 구성해 주는 만큼 로우코드의 이점을 그대로 제공하기 때문입니다. 심지어 컴포넌트라는 형태로 덩어리로 제공되는 로우코드 툴과 달리 AI가 만들어낸 레이아웃은 코드 형식이기 때문에 훨씬 자유롭게 편집이 가능하다는 점에서 코딩이 가능한 유저에게 있어서 AI 코딩툴은 로우코드의 완전한 상위 호환이라고 할 수 있습니다.

로우코드 툴의 선두주자인 FlutterFlow에서는 이 문제를 상당히 빠른 시점에서 인식한 것으로 보입니다. AI 코딩 툴이 나오기보다 훨씬 전부터 AI를 사용한 코드 작성 툴을 제공하기 시작했기 때문입니다. 당시에 저는 그 업데이트를 보고 "ChatGPT에 물어보고 그렇게 출력된 코드를 붙여넣으면 되지 굳이 이걸 로우코드 시스템 내에 내장할 필요가 있을까?" 라고 생각했는데요. FlutterFlow는 알고 있었던 것 같습니다. 로우코드라는 포지션 자체가 앞으로 AI 툴의 발전으로 위험해질 수 있다는 것을 말입니다.

하지만 그러한 FlutterFlow의 선견지명에도 불구하고 사실 로우코드의 미래는 밝지 않아 보입니다. FlutterFlow의 AI 툴은 Cursor, Bolt와 같은 곳을 바라보고 있는 것은 분명합니다. 하지만 Cursor나 Bolt는 백지 상태에서 각 프로그래밍 언어로 컴포넌트를 구성해 나갑니다. 그렇기 때문에 AI는 프로그래밍 언어를 학습하기만 하면 모든 구성요소를 만들고 컨트롤할 수 있습니다.

한편 FlutterFlow와 같은 로우코드의 AI 툴은 프로그래밍 언어만을 학습해서는 안 됩니다. 그에 더해서 FlutterFlow의 특유의 프레임워크나 컴포넌트를 완벽하게 구사하고 나아가서는 컴포넌트를 넘어선 요소까지 수정할 수 있는 기능을 가져야 합니다.

알기 쉽게 요리로 비교하자면 Cursor나 Bolt의 AI 툴이 각각의 재료를 가지고 인터넷상에 있는 레시피를 바탕으로 요리를 한다면 로우코드의 AI 툴은 기존에 판매되고 있는 밀키트를 분해하고 재조합해서 자신만의 레시피로 요리를 만들어야 하는 셈이지요. 과연 이게 가능할까요? 그리고 가능하다고 하더라도 사용자들은 그렇게 한정적인 상황에서 밖에 못쓰는 레시피를 선호할까요?

결론

저는 로우코드 툴을 참 좋아합니다. 이건 제가 반쪽짜리 개발자이기 때문입니다. 자유도가 너무 부족한 노코드, 해야 할 일이 너무 많은 스크래치 개발, 그 사이의 갈증을 딱 채워 주던 것이 로우코드 툴이었기 때문입니다.

하지만 이제 아이러니하게도 로우코드 툴 자체가 반쪽짜리 툴이 될 위기에 놓여있습니다.
반쪽짜리 개발자가 좋아하는 반쪽짜리 툴... 나름대로 재미있는 결말이지만 유쾌한 결말은 아니군요.

로우코드 진영의 통렬한 반격을 기대하며 글을 마무리하겠습니다.