온라인 앱 개발 코드: 실용 가이드

온라인 앱 개발 코드는 데이터베이스 스키마를 작동하는 비즈니스 애플리케이션으로 바꾸는 시각적 구성, 수식 및 선택적 스크립트의 혼합입니다. 일반적인 로우 코드 빌드는 데이터 모델, 인터페이스, 로직, 통합이라는 네 가지 계층을 거치며 모두 로컬 설치 없이 브라우저를 통해 노출됩니다. 성숙한 팀은 생성된 코드와 직접 작성한 코드를 혼합하여 반복적인 80%에는 시각적 도구를 사용하고 진정으로 고유한 20%에는 소스 코드를 사용합니다.

• 온라인 앱 개발을 위한 로우 코드 및 노 코드 플랫폼은 상용구(라우팅, 인증, CRUD 화면, 배포)를 구성으로 대체하지만 로직을 완전히 제거하는 경우는 거의 없습니다. 여전히 규칙, 유효성 검사 및 계산을 정의합니다.
• 모든 애플리케이션의 4개 계층(데이터, 인터페이스, 로직, 통합)은 무엇을 구성할지, 무엇을 코딩할지 결정하는 데 적합한 정신적 모델입니다.
• 생성된 코드와 직접 작성한 코드는 반대되지 않습니다. 성숙한 팀은 반복적인 80%를 위한 시각적 도구와 진정으로 고유한 20%를 위한 소스 코드를 사용하여 이를 혼합합니다.
• 첫 주에 내린 데이터 모델링 결정은 나중에 취소하기가 가장 어렵습니다. 따라서 단일 양식을 만들기 전에 테이블과 관계를 디자인하십시오.
• 공급업체 의존성은 실질적인 트레이드오프(trade-off)입니다. 호스팅된 플랫폼에서 더 빨리 출시할수록 해당 플랫폼의 데이터 내보내기 옵션 및 가격에 더 많이 의존하게 됩니다.
• 4D(4th Dimension)는 관계형 데이터베이스 엔진, 양식 디자이너 및 자체 프로그래밍 언어를 단일 환경에 결합하는 이 분야에서 오랫동안 확립된 옵션입니다.

”온라인 앱 개발 코드”가 실제로 의미하는 것

온라인 앱 개발 코드는 클라우드 호스팅 빌더가 애플리케이션을 정의하는 데 사용하는 지침을 설명합니다. 일부는 사용자가 입력하고 대부분은 사용자 구성에서 플랫폼에 의해 생성됩니다. 이 문구는 초보자가 종종 혼동하는 세 가지 별개의 항목, 즉 사용자가 만드는 시각적 정의(테이블, 필드, 양식, 워크플로), 해당 정의 내에 작성하는 표현식 및 수식, 플랫폼이 사용자를 대신하여 생성하거나 해석하는 기본 소스 코드를 다룹니다.

세 가지 중 어떤 것을 다루고 있는지 이해하는 것이 작업의 이식성이 결정되기 때문에 중요합니다. 브라우저에서 함께 드래그하는 양식 레이아웃은 플랫폼 메타데이터로 저장됩니다. 일반적으로 다른 제품으로 들어 올릴 수 없습니다. 표준 표현 언어로 작성하는 공식은 원칙적으로 이식성이 더 높지만 구현 방식이 충분히 다르기 때문에 자동으로 번역되는 경우는 거의 없습니다. 직접 작성한 소스 코드는 이식성이 가장 뛰어나고 유지 관리 비용이 가장 많이 듭니다.

실질적인 결과: 구성에 포함된 앱이 많을수록 출시 속도가 빨라지고 이동이 더 어려워집니다. 그것은 우연이 아니라 의도적으로 하는 절충안입니다.

노코드 앱 개발 vs. 로우코드 vs. 기존 코딩

코드 없는 온라인 앱 개발은 편집기를 전혀 열지 않는 사람들을 대상으로 합니다. 목표는 드롭다운, 조건 및 간단한 수식을 통해 표현된 논리를 사용하여 사전 정의된 구성 요소로 조립된 완전한 앱을 만드는 것입니다. 로우 코드는 한 단계 더 나아간 것입니다. 즉, 동일한 시각적 구성 요소에 더해 요구 사항이 구성 요소가 제공하는 수준을 초과할 경우 실제 코드로의 탈출구가 됩니다. 전통적인 개발은 빈 저장소와 프레임워크 선택으로 시작됩니다.

실제로 중요한 구별은 라벨이 아니라 천장이 어디에 있는지입니다. 넉넉한 수식 언어와 API 커넥터를 갖춘 코드 없는 도구는 소규모 비즈니스 애플리케이션을 먼 길로 이끌 수 있습니다. 약한 스크립팅 레이어가 있는 로우 코드 도구는 조인된 테이블 전체에 걸쳐 사용자 지정 계산이 필요한 순간 ​​중단될 수 있습니다.

관련 항목: Claris FileMaker Pro — 단일 파일의 데스크톱, 웹, 모바일용 맞춤형 앱이 필요한 팀을 위한 장기 실행 관계형 데이터베이스 플랫폼입니다..

세 가지 질문으로 카테고리를 구분하는 것이 유용합니다.

1. 조건부 논리를 표현할 수 있습니까? 플랫폼이 선형 “X일 때 Y를 수행합니다” 규칙만 지원한다면 복잡한 비즈니스 규칙은 결국 이를 깨뜨릴 것입니다.
2. 외부 시스템에 연결할 수 있습니까? REST API, 웹후크 및 데이터베이스 커넥터는 앱이 고립되어 있는지 여부를 결정합니다.
3. 데이터를 외부로 가져올 수 있습니까? CSV 내보내기는 기본 사양(table stakes)입니다. 문서화된 API 또는 직접 데이터베이스 액세스가 귀하를 보호합니다.

이 세 가지 질문에 모두 ‘예’라고 대답하는 플랫폼은 훨씬 적은 설정으로 기존 스택의 기능을 대부분 수행합니다. 세 번째 질문에 ‘아니요’라고 대답하는 플랫폼은 약속하기 전에 리스크 비용을 고려해야 하는 위험입니다.

모든 앱 빌드의 4개 계층

모든 비즈니스 애플리케이션은 구축 방법에 관계없이 동일한 4개 계층으로 구성됩니다. 이를 분리하면 구성하는 내용과 작성하는 내용이 명확해집니다.

쇼핑하는 경우: Zoho Creator — 더 넓은 Zoho 제품군에 연결되고 앱당 가격이 아닌 사용자당 가격으로 제공되는 로우 코드 앱 빌더입니다..

레이어 1: 데이터 모델

테이블, 필드, 데이터 유형, 키 및 관계가 기초를 형성합니다. 4D와 같은 관계형 플랫폼에서는 여기에는 기본 키가 있는 테이블을 정의하고, 관계를 통해 테이블을 연결하고, 필드 유형을 신중하게 선택하는 작업이 포함됩니다. 숫자여야 하는 텍스트 필드는 나중에 정렬 및 계산 문제를 일으킬 것입니다. 스프레드시트 스타일 플랫폼에서는 동일한 결정이 열 유형 및 연결된 레코드로 나타납니다.

데이터 모델링은 경험이 가장 큰 성과를 거두는 곳입니다. 처음부터 고객/주문/품목 구조를 적절하게 정규화하면 10,000개의 레코드와 이를 가리키는 12개의 양식이 있는 후 비대해진 테이블을 분할하는 마이그레이션 문제를 피할 수 있습니다.

레이어 2: 인터페이스

양식, 목록 보기, 세부 정보 페이지 및 대시보드가 인터페이스 계층을 구성합니다. 비주얼 디자이너를 사용하면 마크업을 작성하지 않고도 필드를 배치하고 데이터 소스에 바인딩하고 유효성 검사 규칙을 정의할 수 있습니다. 여기의 코드는 선언적입니다. 화면에 표시되어야 하는 내용을 설명하고 플랫폼이 이를 렌더링합니다.

인터페이스 작업은 반복적인 부분(페이지 매기기, 검색, 반응형 레이아웃, 빈 상태)이 자동으로 처리되기 때문에 코드 없는 도구가 가장 빛나는 곳입니다. 단점은 특이한 레이아웃이나 브랜드가 높은 디자인이 디자이너의 구성 요소 집합의 한계에 도달할 수 있다는 것입니다.

레이어 3: 논리

논리는 “앱 개발을 위한 코드”가 문자 그대로 되는 곳입니다. 계산, 검증, 승인 라우팅, 예약된 작업 및 상태 전환에는 모두 지침이 필요합니다. 플랫폼은 이를 다양한 방식으로 표현합니다.

• 수식 필드는 읽기 또는 쓰기 시 다시 계산되는 다른 필드의 값을 계산합니다.
• 이벤트 핸들러는 레코드가 생성, 업데이트 또는 삭제될 때 실행됩니다.
• 워크플로 규칙 조건과 작업을 연결하며, 종종 시각적 빌더를 사용합니다
• 스크립팅 언어는 위에서 표현할 수 없는 모든 것을 처리합니다.

유용한 경험 법칙: 비즈니스 규칙을 예외 없이 한 문장으로 기술할 수 있으면 시각적 규칙이 이를 처리합니다. 세 개의 “unless” 절이 있는 단락이 필요한 경우 스크립팅 레이어가 필요합니다.

관련 항목: Knack — 포털, 디렉토리 및 내부 도구를 목표로 하는 코드 없는 데이터베이스 빌더로, 사용자당 요금 대신 정액 요금이 적용됩니다..

레이어 4: 통합

통합은 앱을 이메일, 결제 처리자, 회계 시스템 및 기타 데이터베이스에 연결합니다. 대부분의 플랫폼은 공통 서비스를 위한 사전 구축된 커넥터와 그 밖의 모든 서비스에 대한 일반 HTTP 요청 작업을 제공합니다. 인증(API 키, OAuth 토큰)은 일반적으로 플랫폼에서 관리되므로 정말 까다로운 작업을 제거합니다.

통합 신뢰성에 주목할 가치가 있습니다. 오전 2시에 자동으로 실패하는 커넥터는 커넥터가 없는 것보다 더 나쁩니다. 따라서 재시도 논리, 오류 로깅 및 실패한 작업을 재생하는 방법을 찾으십시오.

코드가 실제로 존재하는 곳

로우 코드 애플리케이션의 코드는 네 가지 위치에 나타나며 이를 알면 온라인 앱 개발 코드에 소요되는 노력을 정직하게 평가하는 데 도움이 됩니다.

우리의 선택: Airtable — 자동화, 보기 및 공유 가능한 인터페이스를 갖춘 실제 관계형 데이터베이스 위에 있는 간단한 스프레드시트 인터페이스입니다..

표현식과 수식이 가장 일반적입니다. 품목의 송장 총액을 계산하고, 할인 등급을 적용하고, 소수점 이하 두 자리로 반올림하는 공식은 한 줄 필드에 입력된 경우에도 실제 논리입니다.

이벤트 스크립트는 레코드 수명 주기 이벤트에서 실행됩니다. 4D에서 이는 양식 이벤트, 트리거 및 메소드에 연결할 수 있는 내장 프로그래밍 언어의 영역입니다. 브라우저 기반 플랫폼에서는 이에 상응하는 것이 일반적으로 JavaScript 스니펫 또는 서버 측 함수입니다.

API 및 웹훅 페이로드는 JSON을 구성하고, 필드를 매핑하고, 응답을 처리한다는 의미에서 작성하는 코드입니다. 통합 작업이 프로그래밍이 되는 곳입니다.

맞춤 구성요소 및 확장 프로그램은 가장 깊은 수준입니다. 즉, 플랫폼에서 호출하는 재사용 가능한 위젯 또는 서버측 함수를 작성하는 것입니다. 거기에 가는 시민 개발자는 거의 없고, 그럴 필요도 거의 없습니다.

정직한 프레이밍: 코드가 필요 없으므로 웹 서버, 로그인 시스템 또는 데이터베이스 드라이버를 작성할 필요가 없습니다. 그렇다고 해서 규칙과 데이터에 대해 정확하게 생각할 필요가 없어지는 것은 아닙니다. 정밀도는 실제 기술이며 플랫폼 간에 그대로 적용됩니다.

플랫폼 선택 방법: 기준 체크리스트

플랫폼 선택은 대부분의 프로젝트가 성공하거나 실패하는 부분이며 마케팅 페이지는 거의 유용하지 않습니다. 이러한 기준에 따라 후보자를 평가하고 상황에 따라 가중치를 부여합니다.

기준	확인해야 할 사항	왜 중요한가
데이터 모델 깊이	키와 관계가 있는 관계형 테이블인가요, 아니면 단순 목록인가요?	복잡한 데이터를 관리 가능한 상태로 유지하는지 확인
논리 천장	수식 언어, 이벤트 핸들러, 스크립팅 탈출 해치	다른 곳에서 다시 빌드해야 하는 지점을 설정합니다
통합 옵션	기본 커넥터, 일반 HTTP, 웹후크, 인증 처리	앱이 연결될지 아니면 격리될지 결정
데이터 이동성	문서화된 API, CSV 내보내기, 직접 데이터베이스 액세스	플랫폼 변경 시 출구 경로
호스팅 모델	공급업체 클라우드, 자체 호스팅 또는 온프레미스	규정 준수 및 제어 요구 사항
가격 형태	사용자별, 레코드별, 앱별 또는 플랫	사용량 증가에 따른 예측 가능성
학습 곡선	프로그래머가 아닌 사람이 첫 번째 작업 양식을 출시할 시간	귀하의 팀이 실제로 채택할 수 있는지 여부

소규모 팀의 IT 빌더에게는 두 가지 기준이 더 중요합니다. 데이터 이동성은 공급자가 제품을 바꾸거나 가격을 인상하는 것으로부터 귀하를 보호합니다. 논리 천장(logic ceiling)은 이번 분기에 구축한 앱이 내년에도 여전히 적합한지 여부를 결정합니다.

기존 관계형 데이터가 있고 자체 호스팅을 선호하는 팀의 경우 4D는 수직 비즈니스 소프트웨어 분야에서 오랜 역사를 지닌 데이터베이스 엔진, 양식 디자이너 및 프로그래밍 언어를 하나의 제품으로 제공하는 특정 틈새 시장을 차지합니다. 온라인 앱 개발을 위한 브라우저 전용 경험을 원하고 관리할 서버가 없는 팀의 경우, 더 적은 코드가 필요한 Bubble 또는 Airtable 스타일 도구와 같은 호스팅 플랫폼이 더 적합합니다. 어느 쪽도 보편적으로 옳지 않습니다.

현실적인 빌드 시퀀스

인터페이스로 시작하는 것은 진행되는 것처럼 보이기 때문에 초보자가 가장 흔히 저지르는 실수입니다. 더 나은 순서:

1. 엔티티를 나열합니다. 귀하의 비즈니스가 거래하는 이름(고객, 작업, 송장, 부품)과 이들 간의 관계를 기록합니다.
2. 테이블 및 키를 정의합니다. 각 테이블에 기본 키를 할당하고 레코드가 관련되는 방식을 결정합니다. 양식이 존재하기 전에 이 작업을 수행하십시오.
3. 엔터티별로 목록 보기 및 세부 정보 양식을 만듭니다. 기본 CRUD 루프가 엔드 투 엔드로 작동하도록 만듭니다.
4. 값 목록 및 유효성 검사를 추가합니다. 조회 테이블 관련 드롭다운은 소스에서 잘못된 데이터를 방지하므로 나중에 정리하는 것보다 훨씬 저렴합니다.
5. 논리 레이어. 계산, 이벤트 핸들러, 워크플로 규칙을 추가하고 각각을 개별적으로 테스트합니다.
6. 통합은 마지막에 연결하세요. 외부 시스템은 예측하기 가장 어려운 부분입니다. 안정적인 커널에 추가하면 디버깅하기가 더 쉽습니다.
7. 내보내기 일정을 예약하세요. 남길 수 없는 수천 개의 기록이 생기기 전에 데이터를 사용 가능한 형식으로 추출할 수 있는지 확인하세요.

1단계와 2단계는 데이터베이스 개발자의 본능이 결실을 맺고 시민 개발자가 2차 의견을 통해 가장 많은 혜택을 받는 단계입니다. 30분 동안 도면을 검토하면 몇 주 동안의 편집 시간을 절약할 수 있습니다.

일반적인 실수와 이를 피하는 방법

테이블보다 양식을 먼저 만드는 것. 양식을 다시 작성하는 데 비용이 적게 듭니다. 다이어그램은 그렇지 않습니다. 순서가 중요합니다.

플랫폼의 기본값을 요구 사항으로 처리합니다. 기본 필드 유형, 기본 권한 및 기본 명명 규칙이 시작점입니다. 검토해 보세요.

권한 모델 무시. 어떤 레코드를 누가 볼 수 있는지는 최종 설정 단계에서 결정할 것이 아니라 설계 단계에서 결정해야 하는 사항입니다 특히 행 수준 보안은 업그레이드가 어렵습니다.

코드가 없다고 가정하면 유지 관리가 필요하지 않습니다. 통합이 변경되고, 비즈니스 규칙이 바뀌고, 플랫폼이 획기적인 변경을 제공할 때 앱에 업데이트가 필요합니다. 이를 위한 예산을 세우십시오.

테스트 내보내기를 건너뜁니다. 첫 주 내에 전체 내보내기를 실행합니다. 이로 인해 사용할 수 없는 결과가 발생한다면 여전히 대처 비용이 적게 들 때 플랫폼에 대한 가장 중요한 사실을 배운 것입니다.

출처 및 추가 자료

• 모바일 앱 개발 — Wikipedia: 모바일 앱 개발은 개인용 디지털 단말기(PDA…

자주 묻는 질문

온라인으로 앱을 구축하려면 코딩 방법을 알아야 하나요?

아니요, 상당수의 내부 비즈니스 앱은 그렇지 않습니다. 코드 없는 플랫폼은 프로그래밍 없이 데이터 저장, 양식 및 간단한 규칙을 처리합니다. 관련되어 있지만 다른 기술인 구조화된 규칙 기반 용어로 생각해야 합니다. 요구 사항에 여러 테이블에 대한 복잡한 계산이나 특이한 통합이 포함되는 순간 스크립팅 레이어가 중요해집니다.

노코드와 로우코드의 차이점은 무엇인가요?

노코드는 시각적 구성 요소와 간단한 수식을 사용하여 빌더가 작성한 소스 코드 없이 완전한 애플리케이션을 목표로 합니다. 로우 코드는 동일한 시각적 빌딩 블록과 구성 요소가 표현할 수 없는 요구 사항에 대한 실제 코드로 전환할 수 있는 수단을 제공합니다. 실질적인 차이점은 확장 가능성(ceiling)에 있습니다. 로우 코드 애플리케이션은 기존 스택으로 마이그레이션하기 전에 더 커질 수 있습니다.

플랫폼을 전환하면 앱과 데이터를 내보낼 수 있나요?

데이터 내보내기는 일반적으로 CSV 또는 문서화된 API를 통해 가능하지만 애플리케이션 로직은 거의 전송되지 않습니다. 양식 레이아웃, 작업 흐름 규칙 및 수식은 플랫폼별 메타데이터로 저장됩니다. 결정하기 전에 내보내기 형식을 확인하고 테스트하세요. 데이터는 이식 가능한 것으로 취급하고 앱 정의는 그렇지 않은 것으로 취급합니다.

작동하는 비즈니스 앱을 구축하는 데 얼마나 걸리나요?

목록 보기, 세부 양식 및 기본 유효성 검사가 포함된 단일 엔터티 애플리케이션은 대부분의 플랫폼에서 오후 한나절이면 구축하여 실행할 수 있습니다. 관계, 역할 기반 권한 및 하나 또는 두 개의 통합이 포함된 다중 테이블 애플리케이션은 일반적으로 몇 주가 소요되는 프로젝트입니다. 복잡성은 화면 수가 아니라 데이터 모델과 규칙에서 비롯됩니다.

로우코드는 비즈니스 데이터에 충분히 안전한가요?

보안은 플랫폼의 권한 모델, 호스팅 방식, 자체 구성에 따라 달라집니다. 평판이 좋은 공급업체가 암호화, 인증 및 인프라 패치를 처리합니다. 귀하의 책임은 행 수준 액세스 규칙, 역할 할당 및 통합을 통해 데이터를 노출하지 않는 것입니다. 규제 대상 데이터의 경우 시작하기 전에 공급업체의 규정 준수 문서와 호스팅 옵션을 확인하세요.

이런 식으로 앱을 구축하려면 먼저 무엇을 배워야 하나요?

먼저 데이터 모델링(테이블, 키, 관계, 정규화)을 알아보세요. 변경하기 가장 어려운 레이어이자 그 위의 모든 것에 가장 큰 영향을 미치는 레이어입니다. 인터페이스 구축과 수식 작성은 점진적으로 익히기가 더 쉽습니다. 관계형 데이터베이스에 대한 배경 지식은 여러분이 접하게 될 모든 로우 코드 플랫폼에 그대로 적용됩니다.

다음으로 갈 곳

온라인 앱 개발 방식을 배우는 가장 빠른 방법은 귀하나 동료에게 실제로 필요한 하나의 작은 실제 앱을 구축하고 4개 계층을 모두 거치는 것입니다. 스키마로 시작하여 목록 및 세부 정보 보기를 작동시키고 하나의 계산을 추가한 다음 하나의 외부 서비스를 연결하세요. 이 단일 패스는 자신의 상황에서 절충점에 직면하도록 강요하기 때문에 어떤 비교 기사보다 더 많은 것을 가르쳐줍니다.

관계형 데이터베이스에 이미 익숙한 개발자의 경우 시각적 디자이너와 전체 프로그래밍 언어(4D가 오랜 예임)를 모두 제공하는 플랫폼을 탐색하는 것은 구성이 끝나고 코드가 시작되는 위치를 확인하는 데 유용한 연습입니다. 다른 모든 사람들에게는 위의 기준표가 출발점이 됩니다. 두세 가지 후보 플랫폼을 정직하게 평가하고, 내보내기를 테스트하고, 2년 후에 희망하는 수준보다 확장 가능성이 더 높은 플랫폼을 선택하십시오.