저장 프로시저 vs 시각적 워크플로: 로직은 어디에 있어야 하나?

이 결정이 실제로 의미하는 것\n\n비즈니스 로직은 무엇이 허용되는지, 다음에 무엇이 일어나야 하는지, 실제 사람이 시스템을 사용할 때 시스템이 무엇을 해야 하는지를 결정하는 규칙들의 집합입니다. 데이터 자체가 아니라 동작입니다: 누가 무엇을 할 수 있는지, 어떤 조건에서, 어떤 부수 효과와 함께 이루어지는지입니다.\n\n따라서 저장 프로시저 vs 시각적 워크플로 논쟁은 이러한 규칙을 어디에 두어야 변경하기 쉽고 깨지기 어렵고 프로세스 소유자가 명확하게 이해할 수 있는지에 대한 문제입니다.\n\n대부분 팀은 논리를 둘 수 있는 세 가지 ‘집’으로 수렴합니다:\n\n- 데이터베이스에(저장 프로시저, 트리거, 제약조건): 규칙이 데이터 가까이에서 실행됩니다. 빠르고 일관성 있을 수 있지만, 비DB 전문가가 변경하기 어려울 수 있습니다.\n- 시각적 워크플로에(드래그앤드롭 프로세스 빌더): 규칙이 단계와 결정으로 표현됩니다. 프로세스가 변할 때 읽고, 검토하고, 조정하기가 더 쉬운 경우가 많습니다.\n- 커스텀 코드에(서비스, 앱, 스크립트): 규칙을 프로그래밍 언어로 작성합니다. 최대 유연성을 제공하지만 변경에는 더 많은 엔지니어링 절차와 테스트가 필요합니다.\n\n선택은 일상적 속도와 장기 유지보수에 영향을 줍니다. 잘못된 곳에 로직을 두면 배포가 느려지고(변경마다 해당 DB를 아는 한 사람만 필요), 에러가 늘고(여러 곳에 규칙이 중복), 디버깅이 고통스러워집니다(누구도 왜 레코드가 거부됐는지 모름).\n\n대부분 시스템에는 여러 종류의 비즈니스 로직이 섞여 있습니다. 흔한 예로는 검증(필수 필드, 허용 범위), 승인, 가격·할인, 알림, 접근 규칙 등이 있습니다.\n\n실용적인 사고 방식은 이렇습니다: 데이터베이스는 데이터 무결성 보호에 뛰어나고, 시각적 워크플로는 비즈니스 프로세스를 표현하는 데 좋으며, 커스텀 코드는 규칙을 깔끔하게 모델링하기 어려울 때 유리합니다. AppMaster 같은 플랫폼은 중간 지점에 강하게 위치합니다: 데이터를 모델링한 다음 읽기 쉬운 시각적 로직으로 프로세스를 구현해 규칙이 여러 앱에 흩어지는 일을 막을 수 있습니다.\n\n## 최적화 대상: 무엇을 보호하려 하는가\n\n이건 단순한 취향 문제가 아닙니다. 보호하려는 대상: 데이터, 시스템을 변경하는 사람들, 변경 속도입니다.\n\n### 중요한 결과들\n\n프로젝트에서 가장 중요한 결과를 규정하세요. 대부분 팀은 다음 항목들을 혼합하여 균형을 맞춥니다:\n\n- 정확성: 규칙은 부하가 걸려도 매번 동일하게 실행되어야 합니다.\n- 명확성: 새로운 사람이 추측 없이 무슨 일이 일어나는지 이해할 수 있어야 합니다.\n- 속도: 필요할 때 로직은 빠르고 데이터에 가까이에서 실행되어야 합니다.\n- 감사 가능성: 누가 언제 무엇을 변경했는지 증명할 수 있어야 합니다.\n- 변경 빈도: 요구사항이 주간 단위로 바뀔 것으로 예상되는가, 연간 단위인가?\n\n이 다섯 가지를 모두 최대로 만들기는 드물습니다. 로직을 데이터베이스 쪽으로 밀면 정확성과 속도가 좋아질 수 있지만 SQL에 익숙하지 않은 사람들에게는 명확성이 떨어질 수 있습니다.\n\n### 누가 로직을 변경할 것인가(얼마나 자주)\n\n누가 일상적으로 변경을 담당할지 솔직히 보세요. 운영팀이 매주 조정해야 하는 규칙을 DBA가 저장 프로시저를 배포해야만 바꿀 수 있게 해서는 안 됩니다. 반면에 돈에 영향을 주는 규칙은 검토 없이 편집 가능한 상태로 두어서는 안 됩니다.\n\n변경 마찰을 기준으로 생각하세요. 요구사항이 자주 바뀌면 업데이트가 안전하고 가시적이며 빠르게 배포 가능한 장소를 원합니다. 시각적 워크플로 도구(예: AppMaster의 Business Process Editor)는 비즈니스 담당자와 엔지니어가 저수준 코드를 편집하지 않고도 로직에 대해 협업할 때 잘 맞습니다. 변경이 드물고 규칙이 중요한 경우 높은 마찰을 받아들이는 것이 허용될 수 있습니다.\n\n소유권을 압박 테스트할 수 있는 빠른 질문들:\n\n- 새벽 2시에 문제가 생기면 누가 호출되는가?\n- 규칙을 패치해야 한다면 얼마나 빨리 해야 하는가?\n- 변경에 승인이 필요하거나 서류 기록이 필요한가?\n- 여러 앱이 같은 규칙에 의존하는가?\n- 로직이 주로 데이터 형성인가, 비즈니스 결정인가?\n\n초기에 제약을 생각하세요. 일부 산업은 엄격한 접근 제어, 직무 분리, 상세한 로그를 요구합니다. 또한 데이터 접근 제한을 고려하세요: 특정 서비스만 특정 필드를 봐야 한다면 로직이 안전하게 실행될 수 있는 위치에 영향을 줍니다.\n\n## 로직이 저장 프로시저에 있어야 할 때\n\n저장 프로시저는 데이터베이스 내부에서 실행되는 로직 조각입니다. PostgreSQL에서는 SQL로(때로는 PL/pgSQL 같은 DB 전용 언어로) 작성됩니다. 앱이 행을 가져와 루프 돌리고 다시 변경을 쓰는 대신 데이터베이스가 데이터가 있는 곳에서 작업을 수행합니다.\n\n간단한 규칙: 주된 역할이 데이터를 보호하고 대량 데이터 작업을 수행하는 것이라면 데이터베이스에 로직을 두세요. 사람들이나 시스템을 조율하는 역할이면 다른 곳이 더 낫습니다.\n\n### 저장 프로시저가 빛나는 경우\n\n저장 프로시저는 어떤 앱이나 통합이 데이터베이스에 접근하더라도 항상 참이어야 하는 규칙에 적합합니다. 잘못된 데이터를 막는 가드레일을 생각하세요.\n\n또한 한 문장으로 수천 행을 안전하고 빠르게 업데이트할 수 있는 집합 기반 업데이트에 뛰어납니다. 합계 계산이나 고정 할인 공식 적용처럼 순수히 데이터에 관한 간단한 계산도 왕복 횟수를 줄이고 결과를 일관되게 유지한다면 여기에 둘 수 있습니다.\n\n예: 주문이 paid로 표시될 때, 프로시저가 원자적으로 주문 상태를 업데이트하고 재고를 감소시키며 감사 행을 기록할 수 있습니다. 어느 단계가 실패하면 전체 변경이 롤백됩니다.\n\n### 저장 프로시저가 위험해지는 경우\n\n저장 프로시저는 앱 코드보다 테스트하고 버전 관리하기 어려울 수 있습니다, 특히 팀이 데이터베이스 변경을 실제 릴리스처럼 다루지 않는다면 더 그렇습니다. 로직이 앱에서 “숨겨져” 있어 나중에야 결합도를 발견하게 될 수도 있습니다.\n\n디버깅도 까다롭습니다. 오류는 사용자가 무엇을 했는지에 대한 문맥이 부족한 데이터베이스 메시지로 나타날 수 있습니다. 새 팀원은 규칙이 앱과 DB에 나뉘어 있기 때문에 고생할 수 있고, 데이터베이스 로직은 온보딩 시 쉽게 놓치기 쉽습니다.\n\n시각적 도구로 대부분 로직을 처리한다면 저장 프로시저는 데이터에 가깝게 실행되어야 하는 작고 안정된 핵심에만 예약하세요. 나머지는 읽고 추적하고 변경하기 쉬운 곳에 두세요.\n\n## 로직이 시각적 워크플로에 가장 잘 맞을 때\n\n시각적 워크플로는 체크리스트처럼 읽을 수 있는 단계별 프로세스 로직입니다: 무언가가 발생하면 이 행동을 순서대로 실행하고 명확한 결정 지점을 둡니다. 이들은 무거운 계산보다는 작업이 사람, 시스템, 시간 사이를 어떻게 이동하는지에 관한 경우에 적합합니다.\n\n공유된 이해가 중요할 때 이들이 빛을 발합니다. 제품, 운영, 지원, 엔지니어링이 모두 프로세스가 어떻게 작동하는지 합의해야 한다면 시각적 워크플로는 규칙을 가시화합니다. 이 가시성이 종종 “시스템이 고장났다”와 “프로세스가 지난주에 바뀌었다”의 차이를 만듭니다.\n\n워크플로는 승인·검토, 라우팅, 알림·리마인더, 시간 기반 단계(예: 2일 기다렸다가 에스컬레이션), 통합(Stripe 호출, 메시지 전송, CRM 업데이트)에 보통 적합합니다.\n\n예: 고객이 환불을 요청합니다. 워크플로는 주문 연령을 확인하고 임계값을 넘으면 매니저로 라우팅하고 승인되면 재무에 알리고 고객에게 업데이트를 보냅니다. 각 단계는 이해관계자가 가리키고 논의하기 쉬운 평이한 언어로 표현되어 승인이 쉬워지고 새 팀원이 “왜” 그런지 이해하는 데 도움이 됩니다.\n\nAppMaster의 Business Process Editor 같은 도구는 이런 종류의 로직에 맞게 설계되어 있습니다: 경로, 조건, 부수 효과(메시지, API 호출, 상태 변경)를 DB 스크립트를 파고들지 않고도 볼 수 있습니다.\n\n워크플로가 스파게티가 되는 것을 막으려면 작고 읽기 쉽게 유지하세요. 각 워크플로에 하나의 결과만 두고, 단계와 분기 이름을 명확히 하며, 깊게 중첩된 결정을 제한하고, 주요 선택을 로깅해 나중에 “왜 이 일이 발생했나?”를 답할 수 있게 하세요.\n\n워크플로가 복잡한 데이터 처리를 하거나 많은 테이블을 건드리기 시작하면 일부 로직을 다른 곳으로 옮겨야 한다는 신호입니다. 시각적 워크플로는 전체 오케스트라가 아니라 지휘자 역할을 가장 잘 수행합니다.\n\n## 커스텀 코드가 적절한 도구인 경우\n\n커스텀 코드는 앱의 일부로 실행되는 함수, 서비스, 작은 라이브러리 등으로 작성하고 유지하는 로직입니다. 가장 유연한 옵션이기 때문에 기본값으로 사용해서는 안 되며 목적을 가지고 사용해야 합니다.\n\n커스텀 코드는 저장 프로시저나 드래그앤드롭 워크플로에서 안전하게 표현하기 어려운 로직에 자리를 내어줘야 합니다. 도구를 문제에 맞추기 위해 억지로 사용하고 있다면 코드가 더 명확하고 유지보수하기 쉽습니다.\n\n코드를 선택해야 할 강한 신호들:\n\n- 문제 자체가 알고리즘적이다(가격 규칙, 경로 계획, 스코어링, 매칭, 사기 검사)며 예외 처리가 많다.\n- 특이한 통합이 필요하다(특수 인증, 복잡한 재시도, 엄격한 멱등성 규칙을 가진 파트너 API).\n- 성능에 민감하다(대량 처리, 무거운 계산, 세심한 캐싱)며 세밀한 제어가 필요하다.\n- 동일한 로직을 웹, 모바일, 배치 작업 등 여러 곳에서 복사 없이 공유해야 한다.\n- 실수 비용이 클 때 강력한 자동화 테스트가 필요하다.\n\n코드는 소유권을 명확히 하는 것도 돕습니다. 팀이 변경 검토, 테스트 유지, 동작 문서화를 책임지면 여러 워크플로에 흩어진 로직보다 관리가 쉬워집니다.\n\n예: 주문 이력, 사기 신호, 배송 상태, 시간 창을 고려하는 환불 결정 엔진은 코드로 두는 편이 낫습니다. 승인 단계는 시각적 워크플로에 남겨두고 실제 결정 로직은 단위 테스트와 버전 관리가 있는 코드로 관리하세요.\n\n비용은 현실적입니다. 커스텀 코드는 엔지니어링 시간, 코드 리뷰, 지속적인 유지보수가 필요합니다. 변경은 워크플로 편집보다 더 오래 걸릴 수 있고 배포 프로세스가 요구됩니다. AppMaster는 시각적 로직과 모듈로 일반적인 부분을 커버해 코드 필요량을 줄여주며, 진정 필요한 경우 소스 코드를 내보내어 확장할 수 있게 해줍니다.\n\n## 재사용 가능한 단계별 프레임워크\n\n팀들은 가장 유용한 부분을 건너뛰는 경우가 많습니다: 규칙을 명확히 쓰고, 그 규칙의 동작 방식에 맞는 집을 선택하는 것입니다.\n\n새 로직이 나타날 때마다 이 프레임워크를 사용하세요:\n\n- 규칙을 한 문장으로 작성하고 라벨을 붙이세요. 만약 제약(고유성, 합계 일치 등)이라면 데이터 규칙입니다. 단계와 전달(승인, 대기, 알림)이라면 프로세스 규칙입니다. 복잡한 수학이나 변환이면 계산 규칙입니다.\n- 누가 얼마나 자주 편집하는지 물어보세요. 비기술자가 주간으로 변경해야 한다면 SQL이나 코드 릴리스에 숨기지 마세요. 드물게 바뀌고 매번 강제되어야 한다면 데이터베이스가 더 강력한 후보입니다.\n- 실패 영향과 필요한 감사 흔적을 확인하세요. 실수가 금전 손실, 컴플라이언스 문제, 고치기 어려운 데이터를 초래할 수 있다면 명확한 로깅과 엄격한 제어가 가능한 장소를 선호하세요.\n- 위치와 경계를 선택하고 정의하세요. 입력, 출력, 오류를 명확히 하세요. 예: “주어진 order_id에 대해 allowed_refund_amount를 반환하거나 명확한 이유 코드를 반환한다.” 그 경계는 로직이 여기저기로 새는 것을 방지합니다.\n- 한 계층은 얇게 유지하세요. 어디를 대부분 ‘둔하게’(dumb) 둘지 결정해 규칙 중복을 피하세요. 보통 선택은: DB는 얇게(데이터 무결성만), 워크플로는 얇게(오케스트레이션만), 코드도 얇게(글루만)입니다.\n\n경험적 규칙: 데이터 규칙은 데이터에 가깝게, 프로세스 규칙은 워크플로 도구에, 계산 규칙은 테스트와 버전 관리가 쉬운 곳에 두세요.\n\nAppMaster 같은 플랫폼을 사용하면 데이터베이스를 가드레일(테이블, 관계, 기본 제약)로 두고 비즈니스 프로세스 편집기에서 “누가 다음에 무엇을 하는가”를 표현하며 진짜로 필요한 경우에만 커스텀 코드를 예약할 수 있습니다.\n\n## 혼란스러운 시스템을 만드는 흔한 실수\n\n지저분한 시스템은 한 가지 나쁜 선택 때문에 생기지 않습니다. 로직이 흩어지거나, 숨겨지거나, 복사되어 결국 아무도 시스템이 실제로 무엇을 하는지 확신하지 못할 때 발생합니다.\n\n중복은 고전적인 문제입니다: 같은 규칙이 두 곳에 존재하지만 시간이 지나며 서로 달라집니다. 예: DB는 $500 초과 환불을 승인 기록이 없으면 거부하도록 되어 있는데, 워크플로는 다른 한도를 확인해 결제로 요청을 보내는 경우입니다. 둘 다 “작동”하다가 엣지 케이스에서 지원팀이 미스터리 버그를 만나게 됩니다.\n\n숨겨진 규칙도 문제입니다. 트리거, 저장 프로시저, DB에서의 빠른 수정은 UI나 워크플로를 만드는 사람들에게 보이지 않을 수 있습니다. 규칙이 워크플로나 API 근처에 문서화되어 있지 않으면 변경은 추측이 되고 테스트는 시행착오가 됩니다.\n\n과도하게 커진 워크플로는 다른 종류의 문제를 만듭니다. 수십 개의 분기를 가진 긴 드래그앤드롭 체인은 아무도 건드리고 싶어하지 않는 취약한 산물이 됩니다. AppMaster 같은 도구에서는 블록을 추가하기 쉬워 계속 쌓이지만, 경계가 명확하지 않으면 오늘의 속도가 나중의 혼란으로 바뀝니다.\n\n너무 많은 두 가지 실수는 장기적인 고통을 초래합니다:\n\n- 데이터베이스에 너무 많은 것: 모든 정책 변경이 마이그레이션 프로젝트가 되어 작은 제품 수정조차 DB 릴리스를 기다려야 함.\n- 앱 코드에 너무 많은 것: 기본 데이터 규칙(필수 필드, 허용 상태, 고유 제약)이 잊혀져 가져오기나 관리자 도구, 미래 통합을 통해 나쁜 데이터가 들어옴.\n\n간단한 습관이 대부분을 예방합니다: 각 규칙을 하나의 주요 장소에 두고 규칙이 어디에 있는지 그리고 왜 그곳에 있는지 적어두세요. “어디서 강제되는가?”를 10초 안에 대답할 수 없다면 이미 혼란 비용을 지불하고 있는 것입니다.\n\n## 빠른 확인: 2분 안에 결정하기\n\n규칙을 어디에 두는 것이 정확성, 가시성, 변경 용이성 측면에서 가장 유지하기 쉬운지 선택하세요.\n\n먼저 한 질문으로 시작하세요: 이 규칙이 데이터 정확성에 관한 것인가, 즉 우회될 수 없어야 하는가? 그렇다면 데이터베이스에 가깝게 두세요. 단계, 승인, 알림에 관한 것이라면 워크플로 계층에 두세요.\n\n빠른 체크리스트:\n\n- 데이터 정확성을 강제하는가(음수 재고 방지, 중복 “active” 레코드 차단)? 데이터베이스로 기울이세요.\n- 많은 테이블을 건드리고 집합 기반 업데이트가 필요한가(많은 행)? 데이터베이스로 기울이세요.\n- 누가 언제 무엇을 승인했는지 인간이 읽을 수 있는 감사 기록이 필요한가? 워크플로로 기울이세요.\n- 비엔지니어가 주간/월간으로 변경해야 하는가? 워크플로로 기울이세요.\n- 외부 서비스(결제, 메시징, AI)를 호출하는가? 애플리케이션이나 워크플로로 기울이세요, DB가 아님.\n\n이제 실패에 대해 생각하세요. 실패할 수 있는 규칙은 사람이 복구할 수 있는 방식으로 실패해야 합니다.\n\n안전한 재시도와 명확한 오류 메시지가 필요하다면 상태를 추적하고 예외를 단계별로 처리할 수 있는 오케스트레이션 계층을 선호하세요. 시각적 워크플로 도구는 각 단계가 명시적이고 로그를 남기기 쉬워 이 부분을 더 쉽게 만들어 줍니다.\n\n실용적 타이브레이커:\n\n- 누군가가 나중에 새 앱을 작성해도 시스템이 올바르게 유지되어야 한다면 데이터베이스에서 강제하세요.\n- 운영팀이 읽고 검토하도록 만든 프로세스라면 시각적 워크플로에 두세요.\n- 복잡한 통합, 무거운 계산, 특수 라이브러리가 필요한 경우 커스텀 코드를 사용하세요.\n\n예: “환불 금액은 원결제 금액을 초과할 수 없다”는 정확성 문제이므로 데이터 근처에서 강제하세요. “$500 초과 환불은 매니저 승인이 필요하고 승인되면 Telegram으로 알림을 보낸다”는 워크플로입니다. AppMaster에서는 승인 체인을 Business Process Editor에 두고 엄격한 제약은 데이터 모델에 둡니다.\n\n## 예시 시나리오: 승인 있는 환불\n\n실무에서 흔한 케이스는 일정 금액 이상일 때 매니저 승인이 필요하고 알림과 깔끔한 감사 기록이 따라오는 환불입니다.\n\n먼저 하나의 진실 소스(source of truth)를 정의하세요: 금액과 명확한 상태 필드(예: requested, needs_approval, approved, rejected, processing, paid, failed)를 가진 단일 Refund 레코드. 시스템의 모든 부분이 서로 다른 장소에 병렬 상태를 두지 않고 이 같은 필드를 읽고 쓰게 하세요.\n\n### 데이터베이스에 있어야 할 것\n\n돈과 데이터 일관성을 보호하는 규칙은 데이터에 가장 가깝게 두세요.\n\n제약조건(그리고 때로는 저장 프로시저)을 사용해 캡처된 결제 금액보다 많은 환불을 할 수 없게 하거나, 이미 전액 환불된 주문에 환불을 시도하지 못하게 하거나, 같은 주문에 대해 두 개의 활성 환불 요청을 생성하지 못하게 하거나, 환불 승인 후 핵심 금액을 변경하지 못하게 하세요.\n\n또한 원자적 업데이트를 여기 둡니다: 환불 요청이 생성될 때 Refund 행을 쓰고 하나의 트랜잭션에서 Order 합계를 업데이트하세요. 어느 한 쓰기가 실패하면 부분적으로 업데이트되지 않아야 합니다.\n\n### 시각적 워크플로에 가장 적합한 것\n\n승인 단계는 프로세스이지 데이터 보호가 아닙니다. 요청을 적절한 매니저로 라우팅하고, 결정을 기다리고, 상태를 업데이트하고, 리마인더를 보내고, 요청자에게 알리는 일은 시각적 워크플로에 적합합니다.\n\n간단한 흐름 예: 요청 생성 -> 금액이 한도를 초과하면 상태를 needs_approval로 설정 -> 매니저에게 알림 -> 승인되면 approved로 설정 -> 요청자에게 알림 -> 24시간 내 응답 없으면 리마인더 전송.\n\nAppMaster 같은 도구에서는 이것이 Business Process로 명확하게 매핑됩니다. 상태 변경에 반응하고 이메일, SMS, Telegram 메시지를 트리거할 수 있습니다.\n\n### 커스텀 코드에 있어야 할 것\n\n결제 공급자는 규칙이 항상 깔끔하게 들어맞지 않는 엣지 케이스를 가집니다. 수수료가 있는 부분 환불이나 다중 캡처 결제, 웹훅 조정(공급자는 "paid"라는데 앱은 "processing"인 경우), 타임아웃 시 멱등성 및 재시도 처리 같은 공급자 특화 로직은 커스텀 코드에 두세요.\n\n핵심은 커스텀 코드가 자체 상태를 발명하지 않게 하는 것입니다. 커스텀 코드는 Refund 레코드를 읽고 공급자 작업을 수행한 뒤 다음 상태와 확인된 금액을 다시 기록해 데이터베이스가 모두가 신뢰하는 원장으로 남게 해야 합니다.\n\n## 다음 단계: 선택을 유지하게 만들기\n\n좋은 결정은 6개월 후에도 지켜져야 의미가 있습니다. 목표는 “이 로직을 어디에 둘지” 선택을 쉽게 보고, 테스트하기 쉽고, 우연히 우회하기 어렵게 만드는 것입니다.\n\n간단한 로직 맵을 만드세요: 주요 규칙과 각 규칙의 거주지를 짧게 정리한 목록을 유지하고 규칙이 바뀔 때 업데이트하세요. 규칙 이름, 어디에 있는지(데이터베이스, 워크플로, 커스텀 코드), 이유(한 문장), 무엇을 읽고 쓰는지, 누가 변경을 승인하는지 포함하세요.\n\n경계(boundaries)를 비타협적으로 적으세요. 예: “데이터베이스는 X를 보장한다”와 “워크플로는 Y를 강제한다.” 예시: DB는 환불 레코드가 주문 없이 존재할 수 없음을 보장하고, 워크플로는 $500 초과 환불은 매니저 승인이 필요함을 강제합니다.\n\n변경하기 전에 테스트를 계획하세요. 큰 테스트 플랜은 필요 없습니다. 규칙이 바뀔 때마다 다시 실행할 몇 가지 케이스만 있으면 됩니다:\n\n- 해피 패스(예상 입력, 예상 결과)\n- 실패 경로(누락 데이터, 잘못된 상태, 중복 요청)\n- 동시성(두 사람이 동시에 같은 동작을 트리거할 때)\n- 보안(사용자가 단계를 건너뛰거나 직접 엔드포인트를 호출하려고 시도할 때)\n\n소유권과 검토 규칙도 정하세요. 누가 저장 프로시저를 편집할 수 있는지, 누가 워크플로를 편집할 수 있는지, 무엇이 동료 검토가 필요한지 결정하세요. 이것이 많은 시스템이 건강을 유지하거나 “아무도 왜 이것이 작동하는지 모르는” 상태로 빠지는 지점입니다.\n\n무코드 드래그앤드롭 워크플로를 사용하면서도 진짜 백엔드 구조를 포기하고 싶지 않다면 AppMaster( appmaster.io ) 같은 플랫폼이 실용적인 중간 지점이 될 수 있습니다: 데이터를 모델링하고 Business Process Editor에서 프로세스를 표현하고 요구사항이 바뀔 때 재생성하고 배포하세요.\n\n하나의 영향력 큰 규칙을 골라 매핑하고 경계를 추가하고 세 가지 테스트 케이스를 작성하세요. 그 한 가지 습관이 대부분의 로직 확산을 막습니다.