이번 주에 Magic Cloud 대시보드 전체를 교체했습니다. 46,000줄의 Angular — HTML, TypeScript, 그리고 CSS — 코드가 사라졌고, 그 자리에는 기존의 것보다 더 많은 기능을 수행하는 15,500줄 규모의 React 애플리케이션이 들어섰습니다.

코딩에 20시간을 썼습니다. 제 스스로의 리뷰, 테스트, 그리고 욕설을 포함해 총 30시간이 걸렸습니다.

이 작업을 수작업으로 할 때 비용이 얼마나 드는지 저는 정확히 알고 있습니다. 왜냐하면 이미 수작업으로 해본 적이 있기 때문입니다. 2021년에 저는 이 동일한 대시보드를 전통적인 방식으로 다시 작성했습니다. 시니어 개발자 한 명이 한 달 반 동안 작업했습니다. 그 후 제가 넘겨받아 몇 달 동안 더 작업했습니다. 도메인을 완벽하게 숙지한 숙련된 개발자 두 명이 투입된 3개월짜리 작업이라고 부를 수 있겠네요.

이 비교가 바로 이 글을 쓸 가치가 있는 유일한 이유입니다. 누구나 AI가 많은 코드를 빠르게 작성했다고 주장할 수 있습니다. 하지만 동일한 요구사항을 가지고, 동일한 저자가, 동일한 애플리케이션을 두 번 구축하면서, 오직 도구(tooling)만 변수로 두어 비교할 수 있는 사람은 거의 없습니다.

The new Magic Cloud dashboard, showing KPI cards, the MCP agent banner and the Chatbot Wizard

대조표 (The ledger)

코드 라인 수 비교에 대해 한 말씀 드리자면, 이는 사람들이 당연하게 지적할 만한 수치입니다. Angular는 단일 컴포넌트를 .ts 파일, .html 템플릿, 그리고 .scss 스타일시트로 분리합니다. 반면 React는 이 세 가지를 하나의 .tsx 파일로 통합합니다. 기존의 TypeScript와 새로운 TypeScript를 직접 비교하는 것은 저 자신을 부정직하게 치켜세우는 일이 될 것이기에, 양쪽 모두 마크업(markup), 로직(logic), 스타일링(styling)을 모두 포함하여 계산했습니다. 46,000줄 대 15,500줄입니다.

의존성(dependency) 라인은 보기보다 훨씬 중요합니다. 애플리케이션 전체가 React, React-DOM, React Router, CodeMirror, SignalR, marked, 그리고 DOMPurify 위에서 실행됩니다. 이것이 전체 서드파티(third-party) 접점입니다. 상태 관리 라이브러리(state management library), 컴포넌트 라이브러리(component library), CSS 프레임워크(CSS framework), 빌드 플러그인 동물원(build plugin zoo) 같은 것은 없습니다. 의존성 목록이 한 문장 안에 들어갈 정도라면, 업그레이드는 더 이상 특별한 이벤트가 아닙니다.

실제로 어떻게 실행되었는가

저는 Claude를 활용했습니다. 대부분의 작업은 Fable이 담당했고, 더 많은 사고가 필요한 부분은 Opus가 담당했습니다. 모델이 본질적으로 거의 모든 코드를 작성했습니다. 제 역할은 돌보는 것이었습니다. 결과물을 검증(sanity-check)하고, 브라우저에서 테스트하며, 자신 있게 틀린 것들을 잡아내고, 다음에 무엇을 만들지 결정하는 것이었습니다.

이 과정을 성공하게 만든 루프(loop)는 "기능을 설명하고 기도하는 것"이 아니었습니다. 그것은 다음과 같았습니다: 기존 Angular 화면을 스크린샷 찍고, 새 화면을 만들고, 새 화면을 스크린샷 찍고, 그것들을 비교하여 차이를 수정하는 것입니다. 검증은 소스 코드(source code)가 아닌 렌더링된 페이지(rendered pages)를 대상으로 이루어졌습니다. 이 차이는 매우 중요한데, 왜냐하면 오래된 Angular 소스 코드를 읽는 모델은 오래된 Angular의 실수까지 충실하게 재현할 것이기 때문입니다. 화면이 실제로 무엇을 하는지 바라보는 모델은 화면이 실제로 하는 것을 구축할 것입니다.

아래는 그 루프를 통해 화면별로 나온 결과물입니다. 흥미로운 주장은 30시간 만에 "코드"를 만들어냈다는 것이 아니라, 30시간 만에 "이만큼의 작동하는 소프트웨어"를 만들어냈다는 점이기 때문입니다.

로그인

The Magic login screen with backend selector, magnetic link and Google sign-in

대시보드는 어떤 Magic 백엔드(backend)와도 통신하므로, 가장 먼저 필요한 것은 어떤 백엔드인지 결정하는 것입니다. 백엔드 선택기(backend selector)는 사용자가 로그인했던 모든 클라우드렛(cloudlet)을 기억하고 각각에 대해 별도의 JWT를 유지하므로, 백엔드를 전환한다고 해서 다시 로그인할 필요는 없습니다.

비밀번호 필드 아래에는 Angular 버전에는 결코 없었던 두 가지 기능이 있습니다. Magnetic link는 이메일로 임시 로그인 링크를 전송하며, 이는 비밀번호 없는 로그인 (passwordless login) 역할을 겸합니다. 이 기능은 백엔드에 SMTP가 실제로 구성되어 있는 경우에만 나타나는데, 그렇지 않은 경우 기능을 제공하는 것이 막다른 길(dead end)이 되기 때문입니다. Continue with Google은 백엔드에 등록된 제공업체를 대상으로 OIDC를 통해 로그인합니다. 이 두 기능 모두 포팅(port) 과정에서 새롭게 구축된 것이지, 기존 코드를 가져온 것이 아닙니다.

대시보드 (Dashboard)

랜딩 화면은

트리(tree)는 전체 백엔드 파일 시스템을 탐색합니다. 파일은 탭(tabs) 형태로 열리며, 한 번에 여러 개를 열 수 있습니다. 각 탭은 수정 여부(dirty)를 추적합니다. 무언가를 변경하는 즉시 탭과 헤더의 경로 옆에 점이 나타나며, 다른 곳으로 이동하려고 하면 변경 사항을 버릴 것인지 묻습니다. 에디터는 이전 대시보드에서 포팅(port)된 Hyperlambda 모드로 실행되므로, 슬롯 호출(slot invocations)이 올바르게 색상화되며, Ctrl+Space를 누르면 백엔드의 실제 어휘(vocabulary)를 기준으로 자동 완성됩니다. 슬롯 목록은 연결된 서버로부터 가져오며 백엔드별로 캐싱(cache)됩니다. 이는 서로 다른 플러그인을 가진 두 개의 클라우드렛(cloudlets)이 서로 다른 슬롯을 알고 있기 때문입니다. 위 스크린샷에 나타난 팝업은 이 특정 클라우드렛이 알고 있는 log.* 슬롯들을 나열하고 있습니다.

파일 실행 기능은 이전보다 더 스마트해졌습니다. 만약 파일이 실제 HTTP 엔드포인트(endpoint)라면 — 즉, .get.hl, .post.hl 등으로 끝나고 /modules/ 또는 /system/ 아래에 위치한다면 — IDE는 이를 인자(arguments)와 함께 엔드포인트로 호출하여 상태 코드(status code)와 응답 헤더(response headers)를 보여줍니다. 엔드포인트가 아닌 파일들만 직접 평가(evaluate)됩니다. 파일을 업로드하거나 다운로드할 수 있고, /etc/www/에서 HTML, XML, 이미지, JavaScript, CSS를 즉시 미리 보기 할 수 있으며, 어떤 선택 항목이든 F1을 눌러 AI에게 그것이 무엇을 하는지 물어볼 수 있습니다.

Playground (플레이그라운드)

The Hyperlambda Playground with a data.read example and its result pane

아무것도 먼저 저장하지 않고도 서버에서 실행되는 Hyperlambda입니다. 왼쪽에는 입력(input), 오른쪽에는 결과(result)가 표시되며, F5를 눌러 실행합니다. 슬롯이 실제로 무엇을 반환하는지 알고 싶을 때 사용하는 연습장(scratchpad)이며, 연습한 내용이 보관할 가치가 있다고 판단되면 스니펫(snippets)으로 저장합니다.

SQL Studio (SQL 스튜디오)

SQL Studio with a query written against the chinook database

동일한 세 가지 선택기(selector)에 대한 두 개의 탭: 데이터베이스 유형(database type), 연결 문자열(connection string), 데이터베이스(database).

SQL 탭은 구문 강조(syntax colouring) 기능이 있는 쿼리 에디터로, 실제 테이블과 컬럼에 대한 Ctrl+Space 자동 완성, 저장된 스니펫(snippets), .sql 가져오기, 결과의 CSV 내보내기, 그리고 부주의한 쿼리가 수행할 수 있는 작업을 제한하는 세이프 모드(Safe mode) 토글을 제공합니다. 텍스트의 일부를 선택하면 선택된 부분만 실행됩니다.

Designer 탭은 제가 가장 조용히 작업하면서도 가장 자랑스럽게 생각하는 부분입니다. 이 탭은 데이터베이스의 모든 테이블을 카드 형태로 렌더링하며 — 기본 키(primary keys), 컬럼 유형(column types), Null 허용 여부(nullability), 그리고 그 아래에 명시된 외래 키(foreign keys)를 보여줍니다 — DDL을 작성하지 않고도 테이블을 추가하고, 컬럼을 추가하며, 관계를 연결할 수 있게 해줍니다. 또한 직접 작성하는 것을 선호한다면 단일 테이블 또는 데이터베이스 전체에 대한 DDL을 제공하기도 합니다.

The SQL Studio Designer tab rendering chinook tables as schema cards with foreign keys

Databases

The Databases screen listing SQLite databases with table counts

SQLite 데이터베이스를 생성하고, 백업하며, 업로드된 백업에서 복구하고, 더 이상 필요 없는 데이터베이스를 삭제할 수 있습니다. 그리고 두 번째 탭에서는 외부 MySQL, PostgreSQL 및 SQL Server 인스턴스에 연결할 수 있습니다. 대시보드의 다른 모든 기능은 해당 인스턴스들을 로컬 데이터베이스와 완전히 동일하게 취급합니다.

Generator

The Generator screen with chinook tables selected and CRUD options

데이터베이스를 지정하고 테이블을 선택하기만 하면, 완전한 CRUD 백엔드를 작성해 줍니다. 각 테이블에 대해 POST, GET, PUT, DELETE를 제공하며, 원한다면 페이징 (paging), 정렬 (sorting), 집계 (aggregates), 중복 제거 (distinct) 및 검색 (search) 엔드포인트도 포함됩니다. 어떤 역할 (roles)이 무엇을 호출할 수 있는지, 쓰기 작업이 로그에 기록될지, GET 응답을 얼마나 오래 캐싱 (cached)할지, 그리고 기존 파일이 덮어쓰여질 수 있는지 등을 선택할 수 있습니다. 두 번째 탭은 사용자 정의 SQL 문을 별도의 엔드포인트로 감싸줍니다 (wraps).

이 부분이 스키마 (schema)를 단 몇 초 만에 보안이 적용된 API로 변환해 주는 핵심이며, 백엔드 작업에 시간이 거의 소요되지 않는 이유입니다.

엔드포인트 (Endpoints)

The Endpoints screen with modules expanded showing HTTP verb badges