한 문장에서 객체, 뷰, 권한, Agent까지: AI Builder 생성 체인
AI Builder에서 중요한 것은 한 문장을 페이지로 바꾸는 것이 아니라, 비즈니스 요구를 객체, 필드, 뷰, 워크플로, 권한, 자동화, Agent 도구로 분해하는 것입니다.
결론부터 말하면: 좋은 AI Builder는 한 문장을 몇 개의 페이지로 바꾸는 것이 아니라, 하나의 비즈니스 요구를 객체, 필드, 뷰, 워크플로, 권한, Agent 도구로 분해해 실행 가능하고 변경 가능하며 통제 가능한 애플리케이션 명세로 만든다.
“한 문장으로 애플리케이션 생성”은 강력하게 들리지만 오해를 만들 수 있습니다.
사용자가 프롬프트로 몇 개의 페이지를 만든다고 생각한다면, 많은 코드 생성 데모와 본질적으로 다르지 않습니다. 중요한 질문은 AI Builder가 비즈니스 요구를 실행 가능하고, 변경 가능하며, 거버넌스 가능한 애플리케이션 메타데이터로 어떻게 분해하는가입니다.
예를 보겠습니다.
공급업체 위험 관리 애플리케이션을 만들어줘. 공급업체, 자격, 견적, 구매 주문, 납품, 품질 이슈를 관리해야 하고, AI가 자격 만료, 비정상 견적, 납품 위험을 감지해야 해. 핵심 자재 공급업체가 고위험이면 구매 매니저 승인을 거치게 해줘.
독자가 알고 싶은 것은 이 문장이 플랫폼에 들어간 뒤 무슨 일이 일어나는가입니다.
첫 단계: 페이지가 아니라 비즈니스 객체 그래프 생성
AI Builder는 먼저 비즈니스의 명사를 찾아야 합니다.
이 예시는 하나의 공급업체 테이블이 아닙니다. supplier, supplier_qualification, quotation, purchase_order, delivery_record, quality_issue, supplier_risk, approval_task 같은 관련 객체 묶음입니다.
이 단계가 중요합니다. 큰 테이블 하나만 있으면 어떤 납품, 어떤 견적, 어떤 자격이 위험을 만들었는지 설명하기 어렵습니다. 객체가 명확하면 위험은 증거와 연결되고, 승인은 이유와 연결되며, Agent도 근거를 설명할 수 있습니다.
두 번째 단계: 필드와 관계에 비즈니스 의미 부여
낮은 품질의 생성기는 필드를 폼 입력으로 봅니다. 좋은 Builder는 필드를 비즈니스 의미로 봅니다.
자격 객체는 단순 첨부파일이 아닙니다. 자격 유형, 인증 번호, 시작일, 만료일, 검토 상태, 검토자, 연결된 공급업체, 핵심 자격 여부가 필요합니다.
견적 객체도 금액만이 아닙니다. 자재, 수량, 단가, 유효기간, 과거 평균 대비 편차, 운송과 서비스 포함 여부, 연결된 구매 요청이 필요합니다.
관계도 중요합니다. 공급업체는 여러 자격, 견적, 주문, 납품, 품질 이슈를 가집니다. 위험 기록은 이러한 증거로 되돌아갈 수 있어야 합니다.
이 계층이 잘 생성되어야 이후 AI 분석은 모델의 추측이 아니라 객체 관계 기반 설명이 됩니다.
세 번째 단계: 역할별 뷰 생성
엔터프라이즈 애플리케이션은 모두에게 같은 테이블을 보여주지 않습니다.
| 역할 | 뷰 |
|---|---|
| 구매 담당자 | 내 공급업체, 보완 필요 자격, 견적 비교 |
| 구매 매니저 | 고위험 공급업체, 승인 대기, 핵심 자재 위험 |
| 품질 담당자 | 최근 품질 이슈, 반복 결함, 개선 상태 |
| 법무 / 컴플라이언스 | 자격 공백, 계약 위험, 블랙리스트 |
| 경영진 | 위험 분포, 공급업체 집중도, 구매 의사결정 추세 |
이는 Low-code의 뷰 설정과 비슷합니다. AI Builder의 가치는 요구사항에서 합리적인 시작점을 생성한다는 데 있습니다.
네 번째 단계: 권한과 액션 경계
권한은 AI Builder 데모에서 자주 빠지지만, 전문 플랫폼을 구분하는 핵심입니다.
이 공급업체 애플리케이션에서는 구매 담당자가 공급업체 프로필은 관리하지만 품질 결론은 수정할 수 없고, 품질 담당자는 품질 이슈를 닫을 수 있지만 구매 주문을 승인할 수 없으며, 구매 매니저는 고위험 구매를 승인할 수 있어야 합니다. 일반 사용자는 민감한 재무 정보를 볼 수 없어야 하고, AI는 위험을 제안할 수 있지만 공급업체를 자동 차단할 수 없어야 합니다.
이것은 페이지의 세부 동작이 아니라 런타임 규칙입니다.
Agent가 “고위험 공급업체를 찾아 구매를 중단해”라는 요청을 받아도 이 액션 경계 안에서 동작해야 합니다.
다섯 번째 단계: 워크플로, 자동화, SLA
정적인 객체만으로는 부족합니다. 애플리케이션은 일을 앞으로 밀어야 합니다.
프로세스는 신규 공급업체 등록, 자격 업로드, AI 완전성 검사, 견적 비교, 구매 주문 생성, 납품 기록 반영, 위험 감지, 승인, 개선 또는 대체 공급업체 제안, 감사 기록이 남는 위험 종료를 포함할 수 있습니다.
자동화도 요구사항에서 생성되어야 합니다.
- 자격 만료 30일 전 알림;
- 핵심 자격 만료 시 신규 구매 차단;
- 납기 준수율이 기준 이하일 때 위험 생성;
- 동일 품질 이슈 반복 시 검토 작업 생성;
- 고위험 승인 지연 시 구매 매니저 알림.
이것이 애플리케이션 생성이지 페이지 생성이 아닙니다.
여섯 번째 단계: Agent 도구 생성
AI-native 애플리케이션의 마지막 계층은 Agent 도구입니다.
플랫폼은 모델이 데이터베이스에 직접 접근하게 하는 대신 통제된 도구를 생성해야 합니다. 공급업체 위험 조회, 견적 비교, 위험 원인 설명, 검토 작업 생성, 고위험 구매 승인 시작, 월간 공급업체 위험 보고서 생성 등이 여기에 포함됩니다.
각 도구에는 입력, 출력, 권한, 감사가 필요합니다.
사용자가 “이 공급업체에 아직 주문해도 되나?”라고 물으면 Agent는 공급업체, 자격, 납품, 품질, 견적을 확인하고 근거와 함께 답해야 합니다. 중요한 액션은 플랫폼 액션을 통해 실행되어야 합니다.
좋은 Builder는 생성 계획을 보여준다
AI Builder는 신뢰를 만들어야 합니다. 조용히 모든 것을 생성해서는 안 됩니다.
생성할 객체, 주요 필드, 관계, 뷰, 적용될 권한, 실행될 자동화, Agent가 호출할 수 있는 도구, 사람의 확인이 필요한 액션을 보여줘야 합니다.
사용자가 확인한 뒤 애플리케이션을 생성합니다. AI Builder는 블랙박스가 아니라 협업하는 애플리케이션 아키텍트입니다.
ObjectStack 생성 체인
ObjectStack의 AI Builder는 자연어를 애플리케이션 명세로 바꾸고, 그 명세가 런타임을 구동하게 해야 합니다.
자연어 요구 → 비즈니스 객체 → 필드와 관계 → 뷰와 폼 → 권한 경계 → 워크플로 자동화 → Agent 도구 → 감사 런타임
한 문장으로 애플리케이션을 만드는 것은 마법이 아닙니다. 진짜 가치는 그 문장이 어떤 메타데이터 계층에 반영되어야 하는지, 그리고 그 계층들이 어떻게 실행 가능한 비즈니스 시스템을 만드는지 아는 데 있습니다.