Zoho Creator 판단 기준 — 커스텀 앱을 만들 때와 만들지 말 때

표준 제품으로 안 되는 업무가 있습니다. 그때 선택지는 셋입니다. 업무를 제품에 맞추거나, 다른 제품을 찾거나, 직접 만들거나.

Zoho Creator는 세 번째 선택지를 낮은 비용으로 여는 로우코드 도구입니다. 화면과 데이터 구조를 만들고 워크플로를 붙여 업무용 앱을 만듭니다.

문제는 이 도구가 있으면 만들고 싶어진다는 것입니다. 만들기 쉬운 것과 만드는 게 맞는 것은 다릅니다. 잘못 만든 앱은 유지보수 부담이 되어 몇 년을 따라다닙니다.

이 글은 만들 때와 만들지 말 때를 가르는 기준을 정리합니다. 개발 방법이 아니라 의사결정에 관한 글입니다.

1. 먼저 표준 기능으로 되는지 확인하십시오

커스텀 앱 요청의 상당수는 표준 기능을 모르거나 설정을 안 해 본 경우입니다. 만들기 전에 이것부터 확인하십시오.

확인 순서는 이렇습니다. 첫째, 기존 모듈의 커스텀 필드와 레이아웃으로 표현할 수 있는가. 둘째, 커스텀 모듈로 만들 수 있는가. 셋째, 워크플로와 자동화로 처리할 수 있는가.

세 가지로 안 되는 경우에만 Creator를 검토합니다. 이 순서를 건너뛰면 CRM 안에 있어야 할 데이터가 별도 앱으로 나가고, 리포트를 합치는 데 다시 비용이 듭니다.

실무 경험상 커스텀 앱 요청의 절반 이상은 두 번째 단계에서 해결됩니다. 커스텀 모듈은 표준 객체와 연결되고 표준 리포트에 들어가므로 거의 항상 더 나은 선택입니다.

2. 만들어도 되는 업무의 세 조건

첫째, 데이터 구조가 표준 객체와 겹치지 않아야 합니다. 고객·거래·연락처를 다시 만드는 앱은 거의 항상 잘못된 설계입니다. 그 데이터는 CRM에 있어야 합니다.

둘째, 사용자가 특정됩니다. 전사 모든 사람이 쓰는 핵심 업무는 표준 제품에 맡기는 편이 낫습니다. 특정 부서, 특정 역할이 쓰는 주변 업무가 Creator에 적합합니다.

셋째, 규칙이 안정적이어야 합니다. 매달 규칙이 바뀌는 업무를 앱으로 고정하면 앱을 고치는 일이 본업이 됩니다.

세 조건을 모두 만족하는 전형적인 예는 현장 점검 기록, 설비 이력 관리, 사내 신청·승인 절차, 협력사 제출 양식 같은 것들입니다.

3. 만들지 말아야 할 네 가지 신호

첫째, '엑셀을 그대로 옮기고 싶다'는 요청입니다. 엑셀의 자유도를 앱으로 재현하면 복잡도가 폭증합니다. 무엇을 표준화할지 먼저 정해야 합니다.

둘째, 회계·세무처럼 규정에 묶인 업무입니다. 규정이 바뀌면 앱을 고쳐야 하고, 책임 소재도 명확하지 않습니다.

셋째, 담당자 한 명만 이해하는 로직입니다. 그 사람이 나가면 앱이 블랙박스가 됩니다. 만들더라도 로직을 문서로 남기는 조건을 붙이십시오.

넷째, '일단 만들어 보고 쓰면서 고치자'는 접근입니다. 앱은 데이터를 쌓기 때문에 나중에 구조를 바꾸기 어렵습니다. 최소한의 데이터 구조는 만들기 전에 확정해야 합니다.

4. 플랜 구조가 설계를 제한합니다

Creator의 플랜은 앱 개수와 자동화 한도로 나뉩니다. 공식 가격 페이지 기준 Standard는 앱 1개, Professional과 Enterprise는 앱 무제한입니다.

자동화 한도는 사용자당 월 기준으로 Standard 90회, Professional 300회, Enterprise 600회 수준으로 안내됩니다. API 데이터 소스는 Standard 5개에서 Enterprise 30개까지입니다.

Enterprise는 여기에 사용자당 일 200회(최대 일 20,000회) 클라우드 함수 호출과 앱당 250개 포털 권한 세트를 제공한다고 안내됩니다.

설계 전에 이 한도를 확인하십시오. 자동화를 많이 쓰는 앱을 Standard에서 만들면 몇 주 안에 한도에 걸립니다. 한도를 먼저 보고 설계를 맞추는 편이 나중에 플랜을 올리는 것보다 쌉니다.

5. 외부 사용자를 붙일 것인가

Creator의 실질적인 가치 중 하나는 포털입니다. 협력사, 고객, 현장 인력처럼 정식 사용자 라이선스를 주기 어려운 대상에게 제한된 화면을 열어 줄 수 있습니다.

전형적인 활용은 협력사 제출 양식, 고객 요청 접수, A/S 신청, 현장 점검 보고입니다. 메일과 엑셀로 주고받던 것을 폼으로 바꾸면 데이터가 처음부터 정형으로 들어옵니다.

다만 포털을 여는 순간 고려할 것이 늘어납니다. 인증 방식, 권한 범위, 개인정보 수집 동의, 그리고 외부에서 보이는 화면의 완성도.

포털 권한 세트에도 플랜별 한도가 있으므로 외부 사용자 규모를 먼저 추정하십시오. 협력사 200곳에 각각 다른 권한을 주는 설계는 한도와 관리 부담 양쪽에서 문제가 됩니다.

6. CRM과의 연결을 먼저 설계하십시오

Creator로 만든 앱이 CRM과 끊어져 있으면 두 개의 진실이 생깁니다. 같은 고객 정보가 두 곳에 있고 서로 다른 값을 가집니다.

연결 설계의 원칙은 단순합니다. 고객·연락처·거래의 원본은 CRM에 두고, Creator 앱은 그 참조를 가집니다. 앱에서 고객을 새로 만들지 않습니다.

연결 방향도 정하십시오. 어느 쪽이 쓰고 어느 쪽이 읽는지, 동기화 주기는 어떻게 되는지, 충돌이 나면 어느 쪽이 이기는지.

이 설계가 없으면 6개월 뒤 '어느 쪽 숫자가 맞느냐'는 질문이 나오고, 그때는 이미 양쪽에 데이터가 쌓여 있어 정리에 큰 비용이 듭니다.

7. 만들기 전에 정할 여섯 가지

앱을 만들기로 결정했다면 착수 전에 다음 여섯 가지를 문서로 정하십시오.

첫째, 이 앱이 해결하는 문제 한 문장. 둘째, 데이터 구조 — 어떤 객체가 있고 무엇이 필수인가. 셋째, 사용자와 권한 — 누가 무엇을 볼 수 있는가.

넷째, CRM과의 연결 — 무엇을 참조하고 무엇을 자체 보관하는가. 다섯째, 자동화 목록과 예상 실행 횟수. 여섯째, 유지보수 담당자와 변경 요청 처리 방식.

여섯 번째가 가장 자주 빠지고 가장 자주 문제가 됩니다. 만든 사람이 유지보수 담당이 아니면 첫 변경 요청에서 멈춥니다.

8. 만든 뒤의 운영

앱은 만든 시점이 아니라 6개월 뒤에 평가해야 합니다. 평가 기준은 세 가지입니다.

첫째, 실제로 쓰이는가. 주간 활성 사용자 수를 보십시오. 만들어 놓고 안 쓰는 앱이 생각보다 많습니다.

둘째, 데이터가 쌓이는가. 입력은 되는데 조회와 리포트가 없으면 그 앱은 기록 보관소일 뿐입니다. 판단에 쓰이지 않는 데이터는 가치가 없습니다.

셋째, 변경 요청이 처리되는가. 요청이 쌓이기만 하면 사용자는 우회 경로를 만들고, 결국 엑셀로 돌아갑니다. 처리 주기를 정하고 지키십시오.

9. 확인되지 않은 것

Creator 플랜별 정가는 지역과 통화에 따라 다르게 표시되므로 이 글에서 확정 금액을 적지 않았습니다. 계약 통화 기준 공식 페이지에서 확인하십시오.

플랜별 한도 수치는 공식 가격 페이지 기준으로 확인한 것이며 제품 개편으로 변경될 수 있습니다. 설계 착수 전에 재확인하십시오.

포털 사용자에 대한 별도 과금 여부와 조건은 플랜과 계약에 따라 달라질 수 있으므로 별도 확인이 필요합니다.

Creator와 CRM 간 연동의 구체적인 구현 방식과 API 소모는 구현 방법에 따라 달라집니다. 이 글은 설계 원칙을 다룹니다.

만들 때와 만들지 말 때

커스텀 모듈은 표준 객체와 연결되고 표준 리포트에 들어갑니다 — 가능하면 거의 항상 더 나은 선택입니다

플랜별 한도 (공식 가격 페이지 기준)

자주 묻는 질문

Q. 커스텀 모듈과 Creator 앱 중 무엇을 골라야 하나요?

데이터가 고객·거래와 연결되어야 하면 커스텀 모듈입니다. CRM 안에 있어야 리포트와 권한이 함께 굴러갑니다. 데이터 구조가 완전히 다르고 외부 사용자가 붙어야 하면 Creator입니다. 애매하면 커스텀 모듈을 먼저 시도하십시오.

Q. 자동화 한도에 걸리면 어떻게 되나요?

플랜별 월 한도가 정해져 있어 초과하면 실행이 제한됩니다. 설계 단계에서 예상 실행 횟수를 계산하십시오. 레코드 건당 자동화를 여러 개 거는 설계는 한도를 빠르게 소진합니다. 하나의 자동화에서 여러 처리를 묶는 편이 효율적입니다.

Q. 협력사에 포털을 열어 주려면 무엇을 준비해야 하나요?

인증 방식, 권한 범위, 개인정보 수집·이용 동의, 외부 화면의 완성도 네 가지입니다. 여기에 포털 권한 세트의 플랜별 한도를 확인하십시오. 협력사마다 다른 권한을 주는 설계는 한도와 관리 부담 양쪽에서 문제가 됩니다.

Q. 이미 만든 앱이 안 쓰이고 있습니다. 어떻게 해야 하나요?

먼저 원인을 구분하십시오. 입력이 번거로워서인지, 결과가 판단에 쓰이지 않아서인지, 변경 요청이 처리되지 않아서인지. 세 번째가 가장 흔합니다. 요청 처리 주기를 정하고 두세 건만 처리해 보면 사용률이 회복되는 경우가 많습니다.

이 글이 다루지 않는 것

이 글은 Zoho Creator로 커스텀 앱을 만들지 말지 판단하는 기준을 다룹니다. 앱 개발 방법, Deluge 스크립트 작성법, 화면 설계 기법은 다루지 않습니다. 플랜별 정가는 지역·통화별 표기 차이로 확정 표기를 보류했으며 공식 페이지에서 확인해야 합니다.

함께 읽으면 좋은 글

이 글은 P2 비교와 선택 시리즈의 일부입니다.

• Zoho CRM 에디션 선택 — 기능이 잠기는 지점 (P2)
• Zoho Analytics로 흩어진 데이터를 하나의 대시보드로 (P3)
• Zoho API 크레딧 계산법 — 연동 설계 전에 (P3)

출처

• Forrester, The State Of Business Buying, 2024 (2024.12) — forrester.com/press-newsroom
• 6sense, 2025 B2B Buyer Experience Report (2025.11) — 6sense.com
• Gartner B2B 구매자 조사 (2025.05 발표, 632명) — gartner.com/en/newsroom
• Salesforce, State of Sales 6th·7th Edition (2024.07 / 2026.02) — salesforce.com
• Zoho One 가격 페이지 및 FAQ (2026.09.12 확인) — zoho.com/one/pricing
• Zoho Agents 가격 페이지 — zoho.com/agents/pricing
• Zoho 가격 변경 공지 페이지 — zoho.com/price-change-notice.html
• Nucleus Research, Zoho ROI 조사 (2025.02) — zoho.com 게시 자료

본문의 원화 환산은 1 USD = 1,380원, 기준일 2026년 9월 12일을 적용했습니다. 요금과 약관은 변경될 수 있으므로 계약 전 공식 페이지에서 재확인하십시오.