스키마 설계(PHP 배열)가 AI 에이전트에게 가장 저비용인 구조인 이유

AI에게 WordPress의 폼(Form)을 수정해 달라고 요청했을 때, 처음에 깨달은 점이 있습니다.

"Contact Form 7의 폼을 수정해 줘"라고 부탁하면, AI는 막힙니다.

설정이 데이터베이스(DB)에 들어있기 때문에 AI에게는 보이지 않습니다. 스크린샷을 전달하고, 관리 화면의 조작 절차를 설명하며, AI가 내놓은 절차를 보면서 직접 조작합니다. 이것은 AI와의 "협업"이 아니라, AI를 "검색 엔진 대용"으로 사용하고 있는 것뿐입니다.

폼이 코드로 되어 있지 않으면 AI 에이전트에게 "보이지 않는 벽"이 됩니다.

AI 에이전트의 비용은 두 종류가 있다

AI를 이용한 개발 비용을 생각할 때, 두 가지 축이 있습니다.

① 토큰 비용 (Token Cost)

입출력 토큰 수. 긴 설명을 제공할수록, 복잡한 출력이 반환될수록 비용이 상승합니다.

② 스킬 비용 (Skill Cost)

AI에게 상황을 설명하는 수고. "이 GUI 도구의 이 버튼을 누르고, 이 설정을 바꾸고..."라는 설명은 AI에게 전달되기 어렵고, 인간 측의 설명 비용이 높아집니다.

GUI 폼 빌더(Form Builder)는 두 가지 비용이 모두 높습니다. DB에 저장된 설정은 AI에게 보이지 않으므로, 스킬 비용 측면에서 "스크린샷 + 조작 절차 설명"이 필요합니다. 출력 또한 "절차서"가 되므로 토큰 비용도 증가합니다.

폼이 코드라면 두 가지 모두 낮아집니다.

폼이 코드일 때 비용이 낮아지는 이유

HXFE에서는 폼을 PHP 배열로 정의합니다.

$schemas['contact'] = [
'id' => 'contact',
'to' => 'admin@example.com',
...

이 스키마를 AI에게 전달하며 "전화번호 필드를 추가해 줘"라고 부탁하면:

[ 'key' => 'tel', 'type' => 'tel', 'label' => '전화번호' ],

단 한 줄의 코드가 반환됩니다.

입력 (스킬 비용): 스키마를 전달하기만 하면 됩니다. 조작 절차를 설명할 필요가 없습니다.

출력 (토큰 비용): 차분이 명확한 한 줄의 코드입니다. 절차서가 아닙니다.

리뷰: git diff로 확인할 수 있습니다. 무엇이 바뀌었는지 한눈에 알 수 있습니다.

이 사이클이 AI와의 협업 비용을 계속해서 낮춰줍니다.

HXFE의 생태계가 비용을 더욱 낮춘다

"HXFE를 처음 사용하는 AI"라도 정확한 코드를 낼 수 있는 구조가 있습니다.

hxfe-code-first-forms/
├── llms.txt ← AI 에이전트용 API 사양 요약
├── ai-reference.md ← 스키마 키 목록 · 사용 예시 · 주의 사항 · lint 경고 목록
...

이러한 파일들을 AI 코딩 도구가 읽음으로써 HXFE의 스키마 사양을 사전에 파악할 수 있습니다.

llms.txt는 API 요약입니다. 필드 타입 · 스키마 키 · 버전 이력이 정리되어 있습니다.

ai-reference.md는 더욱 상세한 사양서입니다. 사용 예시 · lint 경고 목록 · 주의 사항이 적혀 있습니다. AI가 코드를 생성할 때 자주 발생하는 실수(subject 누락 · honeypot 필드 생략 등)를 사전에 방지할 수 있습니다.

CLAUDE.md는 Claude Code를 위한 개발 컨텍스트입니다. "이 프로젝트는 무엇인지 · 어떤 방침으로 개발할 것인지"가 적혀 있습니다.

이러한 것들이 있음으로써 AI에 대한 설명 비용이 더욱 낮아집니다. "HXFE 스키마에 전화번호를 추가해 줘"라고 말하는 것만으로 정확한 코드가 반환됩니다.

에러 로그도 AI가 읽을 수 있는 형태로 설계했다

v1.4.0에서 에러 로그 기능을 추가했는데, 이 부분도 저비용 운용을 의식했습니다.

SMTP 에러 · Webhook 에러 · reCAPTCHA 에러를 데이터베이스가 아닌 wp-content/hxfe-logs/의 텍스트 파일에 기록합니다.

[2026-06-13 10:00:00] SMTP_ERROR | form:contact | wp_mail() failed — To: admin@example.com | Subject: 문의
[2026-06-13 10:01:00] WEBHOOK_ERROR | form:contact | HTTP 500 | URL: https://hooks.zapier.com/...

이 로그를 AI에게 전달하며 "이 에러의 원인과 대처법을 알려줘"라고 요청하면 즉시 답변이 돌아옵니다.

데이터베이스에 들어있다면, SQL로 추출하여 AI에게 전달하는 번비(手間)가 발생합니다. 텍스트 파일이라면, 그대로 복사해서 붙여넣기만 하면 됩니다.

"AI가 읽을 수 있는 형태로 에러를 기록한다"라는 설계가 운영 비용을 낮춥니다.

저비용으로 운영할 수 있는 에코시스템

HXFE를 사용한 개발·운영 사이클을 정리하면 다음과 같습니다:

개발 시:

스키마(Schema)를 AI에게 전달 (수십 줄의 PHP 코드)
"이 필드를 추가해줘", "이 조건 분기(Condition Branch)를 바꿔줘"라고 지시
돌아온 코드를 리뷰하고 적용
git diff로 변경 사항 확인

운영 시:

에러 로그를 AI에게 전달
"이 에러의 원인을 알려줘"라고 질문
대처법을 코드로 전달받음

버전 업데이트 시:

변경 로그(Changelog)를 AI에게 전달
"이 버전의 변경점에 맞춰서 스키마를 업데이트해줘"라고 지시
차이(Diff)를 확인하고 적용

모든 흐름이 "코드를 전달한다 → 코드가 돌아온다"라는 일관된 흐름으로 이루어져 있습니다. GUI 툴처럼 "화면을 설명한다 → 절차를 받는다 → 직접 조작한다"와 같은 우회 과정이 발생하지 않습니다.

"AI와 함께 개발한다"는 전제로 도구를 선택하기

2026년 현재, AI 에이전트(AI Agent)를 사용한 개발이 당연해지고 있습니다.

이 전제하에 WordPress의 에코시스템을 선택하면 자연스러운 답이 나옵니다.

폼(Form)은 코드로 정의한다 → AI가 직접 다룰 수 있음
설정은 DB가 아닌 파일로 관리한다 → AI가 직접 읽을 수 있음
에러는 텍스트로 기록한다 → AI에게 전달하기 쉬움

HXFE는 이러한 방향으로 설계된 WordPress 폼 플러그인입니다. AI 에이전트와의 협업을 전제로 했을 때, "PHP 배열로 폼을 정의한다"라는 선택이 얼마나 합리적인지는 사용하면서 점차 깨닫게 될 것입니다.

AI 서비스에 대한 의존 리스크를 낮추는 설계

2026년, AI를 둘러싼 환경은 급격하게 변화하고 있습니다.

Claude, ChatGPT, Gemini 등의 AI 서비스가 갑자기 플랜을 변경하거나 가격을 인상함
Claude Fable 5 등 최신 모델이 국가나 지역에 따라 이용 제한을 받음
"AI를 풀 활용하여 개발·공개했지만, AI 서비스의 변경으로 인해 업데이트를 할 수 없게 되었다"라는 사례도 나타나기 시작함

AI에 의존한 개발 흐름은 AI 서비스의 변화에 휘둘릴 리스크가 있습니다.

HXFE는 이 리스크에 대해 구조적인 해답을 가지고 있습니다.

폼의 정의는 PHP 코드입니다. AI 서비스가 바뀌어도 폼은 계속 작동합니다.

Claude → ChatGPT → Gemini 등 어떤 AI로 갈아타더라도, PHP 배열은 그대로 전달할 수 있습니다.
AI 서비스를 사용할 수 없게 되더라도, 기존의 폼은 전혀 영향을 받지 않습니다.
llms.txt, ai-reference.md는 AI 서비스와 상관없이 읽을 수 있는 표준적인 텍스트 파일입니다.

"AI와 협업할 수 있다"는 것과 "AI에 의존하지 않는다"는 것은 모순되지 않습니다. HXFE는 그 양립을 목표로 설계되었습니다.

관심이 있다면 시도해 보세요.