원문은 nlqdb.com/blog에서 처음 게시되었습니다.

이제 모든 로우코드 (low-code) 플랫폼에는 AI 레이어 (AI layer)가 탑재되어 있습니다. 앱을 설명하면 사용자의 스키마 (schema)에 맞춰 화면을 구성(scaffold)합니다. 영어로 질문하면 SQL을 작성합니다. 에이전트 (agent)를 지정하면 가드레일 (guardrails) 내에서 계획을 세우고, 도구를 호출하며, 데이터를 쿼리 (query)합니다. 이는 실제로 일어나고 있는 일이며 매우 훌륭합니다. 컴포넌트를 드래그하고 쿼리를 연결하느라 오후 내내 걸리던 작업이 이제 프롬프트 (prompt) 하나로 해결됩니다.

빨라진 것은 도구를 만드는 과정이다

하지만 무엇이 빨라졌는지 주목하십시오. 바로 도구를 만드는 과정 (building the tool) 입니다. 결과물은 여전히 목적지입니다. 즉, 사람이 열고, 로그인하고, 읽는 내부 앱 (internal app)입니다. AI는 "대시보드가 필요해"에서 "대시보드가 생겼어"까지의 경로를 단축했습니다. 하지만 데이터 질문에 대한 해답이 당신이 만드는 대시보드라는 전제에 대해서는 의문을 제기하지 않았습니다.

많은 경우, 정답은 대시보드가 아닙니다. 데이터 질문은 이미 출시 중인 제품 _내부_에 존재합니다. "이 고객에게 최근 5개의 주문 내역을 보여줘", "이 계정은 이번 분기에 얼마를 지출했나"와 같은 질문들 말입니다. 솔직한 결과물은 별도의 관리자 앱이 아니라, 사용자가 이미 머물고 있는 페이지 내에 인라인 (inline)으로 렌더링된 답변입니다. 혹은 질문자가 사람이 아닐 수도 있습니다. 매 요청마다 프로그래밍 방식으로 데이터베이스를 프로비저닝 (provision)하고, 데이터를 쓰고, 쿼리해야 하는 에이전트일 수 있으며, 이 과정에는 UI가 전혀 개입하지 않습니다. 이들 중 그 어느 쪽도 만들어진 도구를 원하지 않습니다. 그들이 원하는 것은 백엔드 프리미티브 (backend primitive)입니다.

빌더인가, 백엔드 프리미티브인가

그것이 바로 갈림길입니다. 빌더(builder)는 — 설령 AI로 강화된 빌더라 할지라도 — 인간이 그 결과물을 조립하고 운영할 것이라고 가정합니다. 반면 백엔드 프리미티브 (backend primitive)는 아무도 그러지 않을 것이라고 가정합니다. 즉, 하나의 요소를 임베딩하거나 하나의 API를 호출하고, 영어로 된 목표를 전달하면, 타입이 지정된 행(typed rows)을 돌려받는 방식입니다. (nlqdb에서 우리는 의도적으로 두 번째 방식을 택했습니다. 제품이나 에이전트가 프로비저닝(provisions)하고 소유하는 Postgres 상에서 영어가 SQL로 컴파일되며, 차이점 미리보기(diff-previewed)를 작성하고, 먼저 조립할 앱도 필요하지 않습니다. 이것이 바로 우리가 드래그 앤 드롭 캔버스(drag-drop canvas)를 제공하지 않는 정확한 이유입니다. 그것은 다른 작업입니다.) 결과물이 팀이 실행할 독립적인 도구일 때는 빌더가 승리하며, 정답이 제품 내에 포함되어야 하거나 질문자가 코드일 때는 프리미티브가 승리합니다.

교훈: AI 기능이 기존 워크플로 (workflow)를 10배 더 빠르게 만든다면, 그것이 워크플로를 빠르게 만든 것인지 아니면 *결과 (outcome)*를 빠르게 만든 것인지 확인하십시오. 내부 도구를 더 빠르게 구축하는 스캐폴딩 (scaffolding)은 진정한 승리입니다. 하지만 당신에게 실제로 필요했던 것이 당신의 앱 내에 있는 정답이거나, 에이전트가 스스로 구축하는 데이터베이스였다면, 가장 빠른 빌더는 여전히 당신에게 필요하지 않은 무언가를 만들고 있는 것입니다.