노코드 툴 개발의 한계

subtitle

커스터마이징이 어려운 이유와 그 현실적인 대안

노코드 툴의 한계

최근 외주 개발 프로젝트에서 노코드 툴을 커스터마이징하는 것에 대한 한계를 뼈저리게 느꼈다.

아임웹으로 쇼핑몰 사이트를 구축했고, oopy를 활용해 노션에 플로팅 목차 컴포넌트를 추가한 경험을 통해, 노코드 툴은 "간단한 요구사항을 빠르게 구현할 수 있는 도구" 이상의 역할을 기대하기 어렵다는 결론에 도달했다.

노코드 툴, 내가 쓰는 건 괜찮지만 외주 개발엔 ‘최악’

내가 직접 운영할 서비스를 만들 때는, 노코드 툴이 제공하는 기능의 범위 안에서 기획을 조정할 수 있다. 그런데 외주 프로젝트처럼 내가 아닌 클라이언트의 요구사항에 맞춰야 하는 상황에서는 이야기가 달라진다.

특히 디자인이 특정 노코드 툴을 고려하지 않고 만들어졌다면, 그걸 노코드 툴에 맞춰 구현하는 건 말 그대로 ‘지옥’이다. 이럴 바에는 오히려 장바구니, 회원가입, 구매 등 핵심 기능이 갖춰진 Headless 커머스 API를 활용하고, 프론트엔드는 직접 개발하는 편이 장기적으로 훨씬 낫다.

또는, 디자인 방향 자체를 사용하려는 노코드 툴의 제약 안에서 다시 구성해줄 것을 디자이너에게 요청하는 것도 현실적인 방법이다.

나의 경우, 급하게 들어온 개발 건이었고 디자인이나 기능을 봤을 때 아임웹으로 충분히 커버가 가능하다고 생각했다. 하지만 그것은 내 착각이었다. 애초에 아임웹을 염두로 두지 않은 디자인이라 커스터마이징에 어려움을 겪었다. 쉬운 작업도 아임웹의 기본 동작이나 스타일을 오버라이드해야 했기에 작업 속도는 배가 되었다.

CSR때문에 스타일이 깨졌다가 적용되는 것을 최대한 막기 위해 header에서 스타일 먹여서 일단 숨기고 모든 자바스크립트 동작이 끝난 뒤에 보여준다든지, MutationObserver를 사용해서 상태가 바뀔 때마다 UI를 다시 업데이트해줘야한다든지, 데이터나 엘리먼트가 hydration될 때까지 기다리는 로직이 들어가는 등 쇼핑몰 CMS나 로그인/회원가입, 장바구니, 결제 등의 기능을 사용할 수 있었지만 화면단에서의 작업이 너무나 복잡하게 구현될 수밖에 없었다.

노코드 툴을 커스터마이징하는 것은 왜 어려울까?

일단 노코드 툴은 이름처럼 ‘노코드’이다. 노코드를 코딩하려고 했기 때문에 이런 사달이 나는 것이다.

노코드 툴을 커스터마이징하려면, 기본적으로 다음과 같은 제약을 감수해야 한다:

•

기존 엘리먼트와 스타일만을 사용해야 한다(ex. 노코드 툴에서 제공하는 네이버페이 버튼)

•

직접 DOM을 조작하거나 CSS를 오버라이드해야 하는 경우가 많다

•

외부 스크립트 삽입 시, 구조나 스타일 변경에 취약하다

예를 들어, oopy에서 구현한 노션 플로팅 목차는 노션 레이아웃이 바뀌면 동작이 깨질 수 있다.

아임웹 역시 마찬가지다. 아임웹이 내부에서 사용하는 모듈의 버전이 바뀌거나 클래스 네이밍이 변경되면, 기존에 적용한 커스터마이징이 갑자기 무용지물이 되기도 한다.

가장 큰 문제: ‘예측 불가능성’

노코드 툴은 자체적인 업데이트나 변경사항을 사전에 예고해주지 않는다.

내가 만든 코드가 어디서 깨졌는지 추적하기도 어렵고, 깨졌다는 사실조차 사용자 피드백으로 알게 되는 경우도 많다.

페이지가 5~6개 이상만 되어도, 스타일과 동작을 커스터마이징한 코드가 상당히 복잡해진다. 이때 노코드 툴의 내부 변경으로 인해 특정 부분이 깨지면, 그 원인을 찾고 고치는 데 엄청난 시간이 소요된다.

반면, 직접 개발한 프로젝트라면 내가 명시적으로 버전을 올리거나 코드를 수정하지 않는 이상 구조는 변하지 않는다. 즉, 노코드 툴은 내가 통제할 수 없는 외부 요인에 의존하는 개발 환경이라는 점에서 위험하다.

노코드 툴을 기반으로 커스터마이징을 하는 건, 언제 꺼질지 모르는 땅 위에서 달리는 것과 같다.

디자인과 기능 요구사항이 단순하거나, 내가 도구의 제약을 잘 이해하고 있는 경우라면 노코드 툴은 유용하다. 하지만 클라이언트 요구사항이 많고, 디자인 자유도가 높은 외주 프로젝트라면 노코드 툴은 마지막 선택지가 되어야 한다.

제안

혹시라도 노코드 툴 사용이 불가피한 상황이라면 다음과 같은 전략을 고려해볼 수 있다:

툴의 한계에 대한 명확한 커뮤니케이션: 프로젝트 초기에 디자이너 및 클라이언트에게 도구의 제약을 충분히 설명하자.

유지보수를 고려한 최소한의 커스터마이징: 노코드 툴의 엘리먼트를 최대한 그대로 쓰는 것을 기본 원칙으로 삼자.

기능 요구사항 정리 후 적합성 검토: 요구사항이 정해진 후에 도구를 고르는 것이 순서다. 도구에 맞춰 기획을 바꾸는 건 최후의 수단이다.