대화로 업무 시스템 바꾸기: 필드, 워크플로, 뷰, 자동화
AI Builder의 진짜 제품 가치는 지속적인 대화형 개선에 있다. 필드, 워크플로, 뷰, 권한, 자동화를 메타데이터 계층에서 안전하게 진화시킬 수 있다.
결론부터 말하면: 대화로 시스템을 바꾸는 진짜 가치는 “말하면 바뀐다”는 데 있지 않다 — 추가된 모든 필드, 변경된 워크플로, 조정된 권한이 검토 가능하고 되돌릴 수 있는 메타데이터 계층에 안착한다는 데 있다. 바꾸기에 빠르고, 바꾸기에 안전하다.
업무 시스템은 출시 이후부터 진짜 일이 시작됩니다.
고객지원 책임자는 필드를 하나 더 추가하고 싶어 합니다. 영업 총괄은 단계를 바꾸고 싶어 합니다. 재무팀은 승인 단계를 추가하고 싶어 합니다. 법무팀은 리스크 규칙을 조정하고 싶어 합니다. 운영팀은 대시보드를 하나 더 원합니다. IT는 권한을 더 엄격하게 만들고 싶어 합니다. 전통적인 소프트웨어 개발에서는 이 모든 것이 요청 티켓이 되고, 산정, 일정 조율, 개발, 테스트, 배포를 거칩니다.
AI Builder에서 가장 기대할 수 있는 점은 이런 변화의 상당 부분을 “요청 제출”에서 “대화로 수정”으로 바꾸는 것입니다.
하지만 정확히 말해야 합니다. 대화형 수정은 AI가 시스템을 마음대로 바꾼다는 뜻이 아닙니다. 자연어가 설명 가능하고, 확인 가능하며, 되돌릴 수 있는 메타데이터 변경 계획을 생성한다는 뜻입니다.
독자가 걱정하는 것
로우코드 플랫폼 사용자의 관점에서 “대화로 앱을 바꾼다”는 말은 편리하게 들리지만 위험하게도 들립니다.
자연스럽게 이런 걱정이 생깁니다.
- AI가 잘못된 객체를 수정하지 않을까?
- 새 필드가 기존 폼에 영향을 주지 않을까?
- 워크플로 변경이 이미 승인 중인 문서에 영향을 주지 않을까?
- 권한 변경으로 민감한 데이터가 노출되지 않을까?
- 자동화가 잘못된 알림을 보내지 않을까?
- Agent가 권한 밖의 작업을 실행하지 않을까?
- 변경 후 롤백할 수 있을까?
그래서 AI Builder를 설명하는 글은 “한 문장으로 앱을 바꾼다”에서 멈추면 안 됩니다. 핵심은 플랫폼이 한 문장을 어떻게 통제된 변경으로 바꾸는지입니다.
변경 유형 1: 필드 추가
사용자가 말합니다.
고객에 “갱신 리스크” 필드를 추가해 주세요. 옵션은 낮음, 중간, 높음입니다. 고위험 고객은 고객 성공 매니저의 보드에 표시해 주세요.
전문적인 AI Builder는 이를 즉시 실행하지 않아야 합니다. 먼저 변경 계획을 생성해야 합니다.
| 변경 항목 | 계획 |
|---|---|
| 객체 | customer 수정 |
| 필드 | enum 필드 renewal_risk 추가 |
| 폼 | 고객 상세 및 편집 페이지에 표시 |
| 뷰 | ”High-risk renewal customers” 보드 추가 |
| 권한 | 고객 성공 매니저는 편집 가능, 영업은 읽기 전용 |
| 자동화 | 리스크가 높음으로 바뀌면 담당자에게 알림 |
| Agent | 고객 요약에서 이 필드를 참조할 수 있게 함 |
사용자가 확인한 뒤에야 플랫폼은 메타데이터를 변경해야 합니다.
이는 단순히 “열을 하나 추가”하는 것과 다릅니다. 필드는 데이터베이스뿐 아니라 애플리케이션 런타임 전체에 들어갑니다.
변경 유형 2: 워크플로 수정
사용자가 말합니다.
비용 청구 금액이 3,000을 넘으면 먼저 직속 관리자가 승인하고, 그다음 재무 관리자가 승인하게 해 주세요. 연결된 프로젝트 예산이 부족하면 예산 책임자의 확인도 필요합니다.
이 문장에는 조건, 승인 노드, 상태, 알림, 예외, 감사가 포함됩니다.
Builder는 다음을 생성해야 합니다.
- 금액 조건.
- 직속 관리자 승인 노드.
- 재무 관리자 승인 노드.
- 예산 부족 판단.
- 예산 책임자 승인 노드.
- 반려 및 추가 자료 요청 경로.
- 승인 의견과 타임스탬프 감사.
동시에 영향 범위를 알려야 합니다. 이 새 워크플로는 새로 제출되는 비용 청구에만 적용되는지, 이미 승인 중인 청구에도 영향을 주는지 설명해야 합니다. 실행 중인 인스턴스에 영향을 준다면 마이그레이션이 필요한지도 알려야 합니다.
이는 로우코드 플랫폼에서 매우 중요한 전문적인 세부 사항입니다. 워크플로는 캔버스에 그렸다고 끝나는 것이 아닙니다. 이미 실행 중인 프로세스 인스턴스와도 함께 동작해야 합니다.
변경 유형 3: 뷰 생성
뷰는 대화형 생성에 특히 잘 맞습니다. 사용자는 보고 싶은 것은 잘 알지만, 필터와 정렬을 어떻게 설정해야 하는지는 모르는 경우가 많기 때문입니다.
사용자가 말합니다.
프로젝트 매니저를 위해 “이번 주 고위험 프로젝트” 뷰를 만들어 주세요. 예상 지연 일수 기준으로 정렬하고, 내가 담당하는 프로젝트만 보여 주세요.
플랫폼은 다음을 생성해야 합니다.
- 객체: 프로젝트.
- 필터: 리스크 등급이 높음이며 이번 주 마일스톤에 영향을 줄 가능성이 있음.
- 권한: 현재 사용자가 담당하거나 참여하는 프로젝트만 표시.
- 정렬: 예상 지연 일수 내림차순.
- 필드: 프로젝트명, 담당자, 마일스톤, 리스크 원인, 다음 조치.
- 표시: 리스트 또는 보드.
좋은 Builder는 이어지는 요청도 받아들여야 합니다.
“최근 회의 결정 사항” 열도 하나 추가해 주세요.
이때 페이지를 다시 만드는 것이 아니라 뷰 메타데이터를 수정해야 합니다.
변경 유형 4: 권한 조정
권한은 대화형 수정에서 가장 신중하게 다뤄야 하는 부분입니다.
사용자가 말합니다.
영업 담당자는 자신이 맡은 고객만 볼 수 있고, 지역 매니저는 자기 지역의 고객을 볼 수 있으며, 경영진은 모든 고객을 볼 수 있습니다.
이 문장은 명확해 보이지만, 플랫폼은 권한 매트릭스를 생성하고 보여줘야 합니다.
| 역할 | 레코드 범위 | 필드 범위 | 실행 가능한 작업 |
|---|---|---|---|
| 영업 | 자신이 맡은 고객 | 원가와 민감한 계약 조항 숨김 | 후속 조치 생성, 활동 업데이트 |
| 지역 매니저 | 자기 지역 고객 | 집계 금액 조회 가능 | 담당자 지정, 리스크 확인 |
| 경영진 | 모든 고객 | 요약 조회 가능, 반드시 수정 가능할 필요는 없음 | 리포트 조회, 내보내기는 승인 필요 |
Agent 쿼리도 같은 권한을 상속해야 합니다. 영업 담당자가 “고위험 고객은 누구인가요?”라고 묻는다면, 시스템은 그 담당자가 볼 수 있는 고객만 반환해야 합니다.
AI는 권한 설정을 도울 수 있지만, 권한 설정을 가볍게 느껴지게 해서는 안 됩니다.
변경 유형 5: 자동화와 Agent 작업 생성
사용자가 말합니다.
매주 월요일 아침, 고위험 고객을 고객 성공 매니저에게 요약해 주고 담당자에게 후속 조치 작업을 만들어 주세요.
플랫폼은 이를 다음으로 나누어야 합니다.
- 예약 트리거.
- 고위험 고객 조회.
- 담당자별 그룹화.
- 내부 요약 생성.
- 후속 조치 작업 생성.
- 자동화 실행 로그 기록.
- 실패 시 관리자 알림.
또한 작업 위험을 구분해야 합니다.
- 내부 요약: 낮은 위험.
- 작업 생성: 낮음에서 중간 위험.
- 고객 리스크 등급 변경: 중간 위험, 확인 필요.
- 고객에게 이메일 발송: 높은 위험, 승인 또는 수동 발송 필요.
대화형 자동화의 핵심은 “더 많은 일을 자동으로 한다”가 아닙니다. 자동화할 수 있는 작업과 반드시 확인해야 하는 작업을 구분하는 것입니다.
좋은 대화형 Builder에 필요한 4가지 제품 세부 사항
첫째, 변경 계획을 보여줘야 합니다. 사용자는 플랫폼이 어떤 객체, 필드, 뷰, 워크플로, 권한, 자동화를 변경하려는지 알아야 합니다.
둘째, 영향 범위를 보여줘야 합니다. 특히 권한, 워크플로, 자동화에서는 어떤 역할, 어떤 데이터, 어떤 실행 중 인스턴스가 영향을 받는지 설명해야 합니다.
셋째, 미리보기와 롤백을 지원해야 합니다. 변경 전에는 미리 확인할 수 있어야 하고, 변경 후에는 이전 버전으로 돌아갈 수 있어야 합니다.
넷째, 감사를 남겨야 합니다. 누가 변경을 요청했는지, AI가 어떻게 설명했는지, 사람이 확인했는지, 시스템이 최종적으로 무엇을 바꿨는지 기록해야 합니다.
이 네 가지가 없다면 “대화로 앱을 바꾸기”는 위험한 블랙박스가 됩니다.
ObjectStack의 가치
ObjectStack은 애플리케이션 구조를 메타데이터 계층에 두기 때문에 대화형 애플리케이션 개선에 잘 맞습니다.
필드, 뷰, 워크플로, 권한, 자동화, Agent 도구는 코드 곳곳에 흩어져 있지 않습니다. 생성, 설명, 수정, 버전 관리, 감사가 가능한 업무 구조입니다.
업무 사용자는 자연어로 변경을 설명합니다. 플랫폼은 변경 계획을 생성합니다. 관리자나 업무 owner가 이를 확인합니다. 그다음 런타임은 새 메타데이터에 따라 동작하고, Agent도 동일한 객체, 권한, 작업 경계를 상속합니다.
이것이 대화로 업무 시스템을 바꾸는 핵심입니다. AI가 임시로 기능 하나를 고쳐 주는 것이 아닙니다. 업무 시스템이 업무 언어로 지속적으로 형태를 바꿀 수 있게 되면서도, 로우코드 플랫폼이 가져야 할 거버넌스를 유지하는 것입니다.