로우코드 프로젝트가 실패한 건 로우코드 때문이 아니라, 잘못된 패러다임 선택 때문이다.

출처: Dev.to

엔터프라이즈 시스템을 로우코드 플랫폼으로 출시한 사람이라면 누구나 그 흐름을 알고 있다. 처음 두 달은 황홀하다 — 끌어다 놓기, 폼, 워크플로, 대시보드가 바로 살아나고, 상사는 신이 난다. 그런데 비즈니스가 본격화되면 상황이 달라진다: 멀티‑오거니제이션, 멀티‑테넌시, 복잡한 승인 체계, 시스템 간 연동, 깊은 커스터마이징 등. 그리고 플랫폼이 등을 돌린다. 필드 하나만 바꿔도 열 곳이 부서지고, 성능은 급락하고, 확장은 벽에 부딪힌다. 결국 손수 다시 코딩하게 된다.
문제는 “로우코드”가 아니다. 선택한 패러다임이 문제다. 패러다임은 세 가지가 있으며, 각각 다른 시점에서 실패한다.

1. 폼 기반 (Airtable 스타일, 대부분의 “노코드” 도구)
   “폼의 스택” — 통합된 데이터 모델이 없다. 관계를 실제 도메인 모델링으로 표현해야 할 순간, 폼 기반은 길을 잃는다.

2. 페이지/컨트롤 기반
   로직과 데이터가 페이지마다 흩어져 있다. 시스템이 커질수록 일관성과 유지보수가 은밀히 부패한다.

3. 모델/메타데이터 기반
   도메인 모델을 먼저 만든다 — 엔터티, 필드, 관계, 동작, 권한 — UI, API, 워크플로, 권한까지 모두 모델과 메타데이터에서 파생된다. 초기 진입 장벽이 높다(모델 사고가 필요함)지만, 비즈니스가 복잡할수록 승리한다: 모델만 바꾸면 UI/API/검증이 동시에 재생성된다. 일관성은 규율이 아니라 구조 자체에 내재한다.

필요조건: 모델‑드리븐이어야 한다.

한 문장 요약: 복잡한 비즈니스는 복잡한 도메인 관계이며, 관계를 안정적으로 유지할 수 있는 것은 모델뿐이다.
모델을 바꾸어도 전체가 깨지지 않는다 — 필드와 관계는 모델에 존재하고, UI는 그 모델의 투영일 뿐이다. 폼·페이지 기반은 구조적으로 이를 구현할 수 없다.

• 실제·엄격한 확장성 — 모델‑드리븐 플랫폼은 보통 코드 수준의 확장을 허용한다(블랙박스가 아니다). 따라서 복잡한 로직을 박스 안에 가두지 않는다.
• 멀티‑테넌트·제품화 — 하나의 모델이 여러 비즈니스 라인과 고객별 변형을 지원한다. 제품을 출시하고 프로젝트를 진행한다면 기본 조건이다.
• 제어 가능한 성능 — 깔끔한 데이터 구조, 손으로 뒤섞은 폼 JSON이 아니다.

차원 비교

경험 법칙: 부서 수준의 폼과 가벼운 워크플로 → 폼 기반, 빠르고 충분함. 수년간 진화하고 확장돼야 하는 엔터프라이즈 핵심 시스템 → 폼 기반에 얽매이지 말고, 처음부터 모델 기반을 선택하라.

모든 “모델‑드리븐”이 동일한 것은 아니다. 진정한 모델‑드리븐을 판단하는 세 가지 테스트:

1. 100% 메타데이터‑드리븐인가? UI/API/권한이 모두 메타데이터에서 파생되는가, 아니면 데이터만 모델링하고 화면을 직접 만들고 있는가?
2. 전체 코드 확장을 지원하는가? 모델 위에 임의의 복잡한 로직을 작성할 수 있는가, 잠금이 걸리지 않는가?
3. 실제 규모에서 살아남았는가? 복잡한 시나리오에서도 “멋진 데모는 살아도 대량에서는 죽는다”는 상황을 피했는가?

Oinone은 한 예시다: 100% 메타데이터‑드리븐이며, 권한, i18n, 멀티‑테넌시, 데이터 감사가 프레임워크에 내장돼 있다. 또한 모놀리식↔분산 전환이 원활하다. 수십억 규모 기업의 핵심 시스템에서 운영 중이다. 오픈소스(AGPL‑3.0)이므로, 영업 자료를 믿지 말고 코드를 직접 읽어 위 세 가지 주장을 검증할 수 있다.

curl -L https://github.com/oinone/oinone-docker-shared/raw/master/oinone/docker-compose.yml -o docker-compose.yml
docker compose -p oinone up -d
# http://127.0.0.1:88 에 접속 → admin / admin

로우코드는 만능 해결책이 아니다 — 하지만 올바른 패러다임을 선택하면 프로젝트가 성장하면서 더 나아지거나 악화되는지를 결정한다.

핵심: 로우코드 패러다임은 세 가지다 — 폼 기반, 페이지/컨트롤 기반, 모델/메타데이터 기반. 단순 앱은 폼 기반에 적합하고, 복잡하고 장기적인 엔터프라이즈 시스템은 모델 기반이 필요하다. 공유된 모델만이 복잡한 관계를 유지하면서 매번 변경에 깨지지 않게 만든다.

Q: 로우코드 패러다임은 무엇이 있나요?
A: 폼 기반, 페이지/컨트롤 기반, 모델/메타데이터 기반 세 가지가 있다.

Q: 복잡한 비즈니스 시스템에 가장 적합한 로우코드 패러다임은?
A: 모델/메타데이터 기반 패러다임이 가장 적합하다.

Q: 플랫폼이 정말 모델‑드리븐인지 어떻게 판단하나요?
A: ① UI/API/권한이 모두 메타데이터에서 파생되는가, ② 코드 수준의 자유로운 확장이 가능한가, ③ 실제 대규모 환경에서 검증된 경험이 있는가를 확인한다.

이 내용이 “패러다임”에 대한 이해를 돕았다면, ⭐ 하나를 눌러 주세요. 더 많은 엔지니어가 올바른 선택을 할 수 있도록 도와줍니다.

GitHub: https://github.com/oinone/oinone-pamirs