아래 스크린샷에 보이는 앱을 구축하는 데는 단 7분이 걸렸습니다.

단순한 목업(Mockup)이 아닙니다. JWT 인증(Authentication)으로 뒷받침되는 로그인 화면, 역할 기반 보안이 적용된 CRUD API를 통해 읽기 및 쓰기를 수행하는 클라이언트 관리자, 그리고 SMTP를 통해 실제 메시지를 발송하는 이메일 탭이 포함되어 있습니다. 백엔드는 데이터베이스를 생성된 CRUD 엔드포인트(Endpoints)로 감싸고, 이메일 발송 엔드포인트를 위해 Hyperlambda Generator에 영어 문장 하나를 전달하여 제작되었습니다.

저는 이전에도 이와 같은 빌드 결과물에 대한 증거를 게시한 적이 있으므로, 이 글은 또 다른 기록을 나열하려는 것이 아닙니다.

이 글은 보통 놓치기 쉬운 그 7분 중의 특정 부분에 관한 것입니다.

데이터베이스는 지루한 부분이었습니다

빌드 과정 중 데이터베이스가 최신 상태여야 하는 부분은 전혀 없었습니다.

CRUD 생성기는 스키마(Schema)가 어디에서 왔는지 상관하지 않습니다. 생성기는 메타데이터(Metadata) — 테이블(Tables), 컬럼(Columns), 타입(Types), 키(Keys) — 를 읽으며, 지구상의 모든 Microsoft SQL Server 데이터베이스는 정확히 이를 노출합니다. 이 데모의 데이터베이스는 엔드포인트가 생성되기 불과 몇 초 전에 만들어졌습니다. 여러분의 데이터베이스는 20년의 역사, 3세대의 개발자, 그리고 비즈니스가 실제로 어떻게 작동하는지를 인코딩하는 외래 키(Foreign Keys)를 담고 있을 것입니다.

동일한 메타데이터. 동일한 생성기. 동일한 7분.

그것이 핵심입니다. 데모는 항상 새로운 데이터베이스에서 실행되는데, 이는 데모에 재현성(Reproducibility)이 필요하기 때문입니다. 하지만 기계는 오직 스키마만을 볼 뿐이며, SQL Server 기반의 여러분의 ERP는 그 어떤 데모보다 더 나은 스키마를 가지고 있습니다. 풀스택 앱의 어려운 부분인 '비즈니스를 올바르게 모델링하는 것'은 여러분이 이미 수년 전에 끝낸 부분입니다.

구축된 내용

정문(Front door). 플랫폼의 내장 인증(Built-in auth)을 통한 JWT 인증 — 앱 어디에도 인증 라이브러리, 비밀번호 해싱(Password hashing) 코드, 세션 배관(Session plumbing) 작업이 필요하지 않았습니다.

The login screen — JWT authentication handled by the platform, zero auth code in the application

고객 관리자. 검색, 추가, 수정, 삭제, 그리고 고객별 메모 — 모든 작업은 생성된 CRUD 엔드포인트 (endpoints)를 통해 전달되며, 각 엔드포인트는 로직이 실행되기 전 역할 (role)에 따라 권한이 제어됩니다.

The client manager — search, status badges and per-client notes over generated CRUD endpoints

그리고 테이블 투영 (table projection)이 아닌 단 하나의 엔드포인트: 플랫폼의 SMTP 연동을 통해 고객에게 이메일을 작성하여 발송하는 기능입니다. 해당 엔드포인트는 단 한 문장의 영어로 설명되었고 몇 초 만에 생성되었습니다 — 애플리케이션에는 메일 제공자 자격 증명 (credential)이 전혀 없으므로, 애플리케이션이 이를 접할 일도 없습니다.

The Emails tab — a generated endpoint looks up the client and dispatches through platform SMTP

레시피 (The recipe)

네 가지 단계.

데이터베이스 연결. 표준 .NET 데이터 제공자 (data provider)를 통해 마법처럼 SQL Server와 통신합니다 — 이는 단지 하나의 클라이언트일 뿐이며, 데이터베이스 내부에 설치되는 것이나 스키마 (schema) 변경은 전혀 없습니다.

테이블 래핑 (Wrap the tables). CRUD 생성기가 스키마를 읽고 엔드포인트(endpoints) — 읽기, 생성, 업데이트, 삭제, 카운트 — 를 방출하며, 인증 (authentication) 및 역할 기반 액세스 제어 (role-based access control)가 이미 연결되어 있습니다.

CRUD가 할 수 없는 기능 기술. "이 고객의 이메일 주소를 찾아 메시지를 보내줘"라는 한 문장이면, Hyperlambda Generator가 이를 작동 가능한 역할 제어 엔드포인트로 변환합니다.

프론트엔드 서빙. API를 서빙하는 것과 동일한 시스템이 정적 파일 (static files)을 서빙하므로, 앱의 HTML, CSS, JavaScript는 작성되는 즉시 라이브 상태가 됩니다. 하나의 호스트, CORS 문제 없음, 별도의 배포 없음.

전체 워크스루 (walkthrough) — 범위 제한된 데이터베이스 사용자, 읽기 전용 시작, MCP를 통한 에이전트 연결 — 는 별도의 문서로 작성되어 있습니다: Create an AI Agent From Your SQL Server or MySQL Database, Step by Step.

에이전트가 필요하지 않습니다

이번 빌드는 MCP를 통해 AI 에이전트(AI agent)를 거쳐 실행되었지만, CRUD 래퍼(wrap) 자체에는 에이전트가 필요하지 않습니다. 대시보드의 백엔드 생성기(Backend Generator)는 클릭 몇 번만으로 동일한 작업을 수행합니다. 데이터베이스를 선택하고, 테이블을 체크하고, 어떤 역할(role)이 무엇을 호출할 수 있는지 선택한 다음, 생성(Generate)을 클릭하면 됩니다.

The Backend Generator — pick a database, tick tables, choose roles, and generate the CRUD API from the dashboard

생성된 엔드포인트(endpoints)와 적용되는 규칙은 동일하며, 대화는 필요하지 않습니다. 에이전트는 편의를 위한 도구일 뿐, 의존 대상이 아닙니다.

"하지만 제 데이터베이스는 레거시(legacy)입니다"

레거시란 구식이라는 뜻이 아니라, 핵심적인 역할을 수행하고 있다는 의미입니다. 저는 Supabase for SQL Server and MySQL에서 이 논거를 상세히 설명했지만, 여기서는 짧게 요약하겠습니다.

범위가 제한된(scoped) 데이터베이스 사용자를 통해 연결하므로, 플랫폼은 DBA가 부여한 권한 이상의 작업을 절대 수행할 수 없습니다. 읽기 전용(read-only)으로 시작할 수도 있으며, 이는

질문해야 할 가치가 있는 질문

이제 질문은 귀사의 조직이 SQL Server 기반 시스템을 현대화할 여력이 있느냐가 아닙니다. 질문은 그중 하나를 보안이 적용된 API와 작동하는 앱으로 감싸는 것이 여전히 하나의 '프로젝트'인지, 아니면 그저 '오후 시간' 정도의 작업인지에 관한 것입니다.

Magic은 github.com/polterguy/magic에서 MIT 라이선스 기반의 오픈 소스(open source)로 제공되며, 문서는 docs.ainiro.io에서 확인할 수 있습니다.