ERP 개발자 세금: NetSuite, Acumatica 및 Fishbowl와 통합이 ‘온보딩 악몽’인 이유
Source: Dev.to
The Problem
Stripe, GitHub, Shopify, 또는 Salesforce에 대한 통합을 구축한 개발자에게 물어보면, 보통 좋은 경험이라고 말합니다.
- 중앙 개발자 포털에 앱을 한 번만 등록합니다.
- 단일 Client ID와 Shared Secret을 받습니다.
- 앱은 플랫폼 전체 생태계에서 인식됩니다.
- 새로운 고객이 가입하면 간소화된 OAuth 동의 흐름을 통해 진행합니다.
깨끗하고 현대적이며 잘 작동합니다.
이제 NetSuite, Acumatica, Fishbowl과 같은 주요 ERP 업체와 통합한 경험이 있는 개발자에게 물어보세요. 고통스러운 표정을 보게 될 준비를 하세요. 분산형, 인스턴스‑별 온보딩, 즉 **“ERP 개발자 세금”**이라 불리는 차원에 오신 것을 환영합니다.
이 단일 문제가 ERP 생태계에 진입하는 개발자들에게 가장 큰 좌절감을 줍니다. 이는 온보딩 전환율을 떨어뜨리는 고전적인 워크플로를 만들고, SaaS 기업이 고객 비밀 정보를 대규모로, 민감하게 보관하도록 강요합니다.
존재 이유
근본적인 문제는 기술 역량이 아니라 생태계 철학의 차이입니다.
- ERP 세계 vs. 현대 PaaS: ERP 플랫폼은 주로 분산된, 로컬 주권 모델로 작동합니다.
- 중앙 “Developer Center” 부재: Acumatica, NetSuite, Fishbowl용으로 개발할 때, 통합을 한 번만 등록할 수 있는 장소가 없습니다. 애플리케이션은 각 설치마다 낯선 존재가 됩니다.
결과
- “원클릭” 설정이 없음.
- 사용자를 통합 인증 화면으로 안내하는 전역 “Connect to NetSuite” 버튼이 없음.
- 등록이 수동이며 인스턴스별로 이루어집니다. 새로운 고객마다 온보딩 절차를 반복해야 합니다.
플랫폼별 워크플로우
| 플랫폼 | 관리자 작업 | 결과 |
|---|---|---|
| NetSuite | Admin (standard users lack permission) navigates to Integration Records, creates a new record for your app, copies the generated Consumer Key and Secret, and pastes them back into your onboarding flow. | You now store a unique NetSuite secret for that customer. |
| Acumatica | Admin goes to Connected Applications (SM303010), registers your app by name, and receives a unique Client ID and Shared Secret scoped to that Acumatica site/tenant. | Another unique credential set to manage. |
| Fishbowl (desktop) | Admin logs into the physical server, opens Integrated Apps, clicks Approve for your specific appID after your app sends an initial request (which is blocked until approval). | Session‑token based, requiring manual approval per customer. |
결과: NetSuite 통합을 사용하는 고객이 500명이라면, 500개의 고유한 자격 증명 세트를 관리하게 됩니다. 이 분산된 혼란은 운영 악몽이며, 전환을 방해하고, 주요 보안 위험이 됩니다.
실제 영향
- Support overload: 각 고유한 자격 증명 세트를 저장하고, 교체하고, 문제를 해결해야 합니다.
- Onboarding friction: 클라이언트는 길고 복잡한 PDF(“Guide to Getting Started with our NetSuite Integration”)를 받습니다.
- Security concerns: 수천 개의 비밀을 하나의 데이터베이스에 저장하면 고가치 표적이 됩니다.
일반 개발자 불만
- “왜 앱을 등록하고 QuickBooks Online에서 하는 것처럼 클라이언트가 승인하도록 할 수 없나요?”
- “제 클라이언트의 IT 관리자가 OAuth 설정을 3일째 시도하고 있습니다. 어떻게 지원할 수 있나요?”
- “저는 이 로컬 설정을 자동화하려고 NetSuite SDN 비용을 직접 내고 있는데도 여전히 터무니없습니다.”
Why ERP Platforms Don’t Adopt a Global Model
Security Sovereignty & Liability
- ERP 데이터는 기업이 보유한 가장 민감한 자산입니다.
- 분산된 등록 방식을 통해 ERP 공급업체는 다음과 같이 말할 수 있습니다: “통합 핸드쉐이크가 완전히 귀사의 인스턴스 내에서 이루어졌으며, 문제가 발생하면 명시적으로 허용한 사람은 귀사입니다.”
- 이는 책임을 직접 고객의 CFO에게 전가합니다.
Private‑Cloud / On‑Prem Challenges
- 많은 ERP 구성 요소가 온‑프레미스(Fishbowl) 또는 프라이빗 클라우드(Acumatica, NetSuite 프라이빗 제공)에서 설치됩니다.
- 글로벌 OAuth 모델은 각 요청마다 모든 인스턴스—대개 깊은 기업 방화벽 뒤에 위치—가 중앙 권한에 “전화”하도록 요구합니다.
- 규제 산업(헬스케어, 금융, 방위)에서 운영되는 기업들은 일반적으로 해당 트래픽을 차단합니다.
Aurinko의 접근 방식
우리는 ERP가 작동하는 방식을 바꾸려는 것이 아니라 개발자들의 부담을 줄이는 데 초점을 맞추고 있습니다.
- 분산된 테넌트 OAuth 등록을 하나의 관리 레이어 뒤에 통합합니다.
- 결과적인 인증 흐름을 간소화하여 개발자는 일관된 API 하나만 사용하면 되고, 각 ERP 인스턴스는 여전히 자체 로컬 자격 증명을 유지합니다.
- 도구(대시보드, 비밀 회전, 감사 로그) 를 제공하여 SaaS 기업이 방대한 민감 자격 증명 데이터베이스를 직접 관리할 필요를 없앱니다.
목표: 수백 개의 고유한 클라이언트 시크릿을 관리하는 대신, 가치‑추가 기능 개발에 집중하도록 돕는 것입니다.
TL;DR
- 최신 SaaS 플랫폼은 원클릭, 전역 OAuth 경험을 제공합니다.
- ERP 플랫폼은 인스턴스‑별, 수동 자격 증명 생성을 강제합니다.
- 이로 인해 개발자는 운영, 보안, 전환 측면에서 막대한 어려움을 겪게 됩니다.
- Aurinko는 각 ERP의 주권을 존중하면서도 관리 중앙화를 구현하는 솔루션을 구축하고 있어, “ERP 개발자 세금”을 크게 단순화합니다.
현재 파편화된 고객 기반에서 100개 이상의 고유한 Client ID와 Secret을 다루고 있다면, 우리 플랫폼이 어떻게 도움이 될 수 있는지 이야기 나누고 싶습니다.
oper Tax,
we’d love to hear how you’re handling it today—let’s talk and see if we can make the process a little less manual for everyone.
[Read more about Aurinko's Dynamic API](#)