감사를 위한 소스 코드 생성 vs 런타임 전용 노코드

감사를 위해 자가 호스팅하거나 검토해야 할 때 이 선택이 중요한 이유

팀이 벤더의 클라우드에서 도구를 실행하고 내부를 들여다볼 필요가 없다면 많은 노코드 플랫폼은 비슷하게 느껴집니다. 하지만 자가 호스팅을 하거나 감사를 통과해야 하는 순간부터 차이가 드러납니다. 여기서 소스 코드 생성과 런타임 전용 노코드의 선택은 단순한 선호를 넘어서 일정, 비용, 위험에 영향을 줍니다.

팀이 성능, 이식성, 보안 검토를 중요하다고 말할 때 보통 실무적으로 의미하는 것은 다음과 같습니다:

• 성능: 사용자가 기다리지 않고 실제 작업을 수행할 수 있는지, 사용량 증가에 따라 시스템이 반응성을 유지하는지
• 이식성: 규칙에 맞춰 앱을 옮길 수 있는지, 재구축 없이 이전이 가능한지
• 보안 검토: 무엇이 실행되는지, 데이터가 어떻게 처리되는지, 실제로 어디에 무엇이 배포되는지 증빙할 수 있는지

자가 호스팅과 감사는 규제된 데이터가 조직을 떠날 수 없다는 제약, 코드 검토 또는 에스크로 수준의 접근을 요구하는 고객 계약, 네트워킹·아이덴티티에 대한 내부 규칙, 패치할 수 없는 제3자 런타임 제한, 특정 클라우드나 온프레 환경으로의 배포 요구사항 같은 제약을 동반하는 경우가 많습니다.

플랫폼이 닫힌 런타임 안에서만 실행된다면 내부에서 무슨 일이 일어나는지 증명하기 어려울 수 있습니다. 이는 감사 주기 연장, 보안팀의 릴리스 차단, 또는 반복적으로 갱신해야 하는 예외 처리로 이어지는 일이 잦습니다.

이식성 문제는 지역을 옮기거나 벤더를 바꾸거나 다른 회사 인프라와 연결해야 할 때 뒤늦게 드러납니다. 성능 문제는 기본 서비스를 튜닝할 수 없을 때도 똑같이 고통스럽습니다.

AppMaster 같은 소스 코드 생성 플랫폼을 사용하면 대화는 “우리 런타임을 신뢰하세요”에서 “여기 코드와 배포가 있습니다”로 바뀝니다. 자가 호스팅이나 감사를 반드시 통과해야 하는 팀에게 이 차이는 프로젝트의 출시에 중요한 영향을 줄 수 있습니다.

두 접근 방식, 쉽게 설명하기

사람들이 소스 코드 생성 vs 런타임 전용 노코드를 비교할 때 실제로 묻는 질문은 하나입니다: 앱을 만든 뒤 실제로 어디서나 실행할 수 있는 코드가 생기는가, 아니면 앱을 계속 실행하려면 특별한 엔진(런타임)을 임대해야 하는가?

소스 코드 생성

소스 코드 생성은 플랫폼이 시각적 모델(데이터 테이블, 화면, 워크플로)을 실제 애플리케이션 코드로 변환한다는 뜻입니다. 생성된 코드는 다른 소프트웨어처럼 컴파일하고 배포할 수 있습니다.

AppMaster의 경우 생성된 코드는 백엔드 서비스에 Go, 웹 앱에 Vue3, 네이티브 모바일 앱에 Kotlin/SwiftUI를 사용합니다. 앱 로직은 Data Designer나 Business Process Editor 같은 도구에서 디자인한 내용으로부터 만들어집니다.

실무적 트레이드오프는 핵심 동작을 바꾸려면 보통 새 버전을 생성하고 배포해야 한다는 것입니다. 표준 릴리스 프로세스와 분명한 감사 증거를 얻는 대신, 새 빌드 없이 즉시 프로덕션 수정을 할 수는 없습니다.

런타임 전용 노코드 플랫폼

런타임 전용 플랫폼은 앱을 자체 런타임 안에 유지합니다. 런타임은 벤더의 엔진으로, 앱 구성을 해석해 서버(또는 컨테이너)에서 실행합니다.

이 모델에서는 대부분의 로직이 소스 코드로서가 아니라 플랫폼에 저장된 구성(configuration)으로 존재합니다. 일상적인 편집은 런타임이 새 구성을 즉시 읽기 때문에 빠르게 느껴질 수 있습니다.

핵심 트레이드오프는 단순합니다: 생성된 코드 플랫폼은 일반 소프트웨어처럼 배포하고 감사할 수 있는 코드베이스를 제공하는 반면, 런타임 전용 플랫폼은 빠른 변경을 쉽게 할 수 있지만 깊은 사용자 정의나 실행을 위해 벤더 런타임에 의존하게 만듭니다.

성능: 무엇을 측정하고 무엇이 영향을 주는가

성능은 하나의 숫자가 아닙니다. 대부분의 비즈니스 앱에서 속도는 데이터베이스, API, 백그라운드 작업, UI 네 가지에 달려 있습니다. 이 중 하나라도 느리면 전체 제품이 느리게 느껴집니다.

런타임 전용 노코드 플랫폼은 종종 앱과 서버 사이에 추가 계층을 둡니다. 이 계층이 도움이 될 수 있지만 오버헤드를 더할 수도 있습니다. 고정된 타임아웃, 제한된 백그라운드 작업, 혹은 ‘모든 경우에 맞춘’ 스케일링 규칙을 마주할 수 있습니다. 많은 경우 기본 서비스를 튜닝할 수 없기 때문에 제약이 생깁니다.

소스 코드 생성 vs 런타임 전용 노코드를 비교할 때 큰 차이는 표준 애플리케이션 스택에 얼마나 근접한가입니다. 플랫폼이 실제 백엔드(예: Go 서비스와 PostgreSQL 데이터베이스)를 생성한다면 색인 추가, 느린 엔드포인트 프로파일링, 워커 확장, 캐싱 조정 등 엔지니어가 이미 사용하는 도구와 습관을 그대로 적용할 수 있습니다.

평가 시에는 측정 가능한 체크에 집중하세요:

• 평균이 아닌 부하 상태에서의 API 지연(p95, p99)
• 데이터베이스 쿼리 시간과 안전하게 인덱스를 추가할 수 있는지 여부
• 백그라운드 작업: 재시도, 스케줄링, 최대 실행 시간
• UI 반응성: 첫 화면 로드 시간, 느린 목록, 무거운 폼
• 예상 트래픽에서의 리소스 비용: CPU와 메모리

또한 스케일링과 장시간 실행 워크플로에 대해 직접 물어보세요. 30분짜리 임포트를 해도 해킹 없이 실행할 수 있나요? 무거운 작업을 큐에 넣고 실패 후 안전하게 재개할 수 있나요?

예: 티켓을 야간에 동기화하는 지원팀 앱. 런타임 전용 시스템에서는 동기화가 실행 한도에 걸려 중간에 실패할 수 있습니다. 생성된 코드라면 동기화를 워커로 실행하고 진행 상황을 DB에 저장해 충돌 후에도 깨끗하게 재개할 수 있습니다.

이식성: 이동, 내보내기, 그리고 통제 유지

이식성이란 앱을 다시 작성하지 않고도 필요한 곳으로 옮길 수 있다는 뜻입니다. 클라우드 제공자와 리전 선택, 네트워크 규칙(VPC, 프라이빗 서브넷, 허용 목록) 준수, 우선순위 변경 시 떠날 수 있는 현실적 방법을 포함합니다.

런타임 전용 노코드에서는 이식성이 종종 “우리 계정에서 실행할 수 있다” 또는 “내보내기 기능이 있다”로 끝납니다. 플랫폼이 여전히 닫힌 런타임을 필요로 하면 업그레이드, 버그 수정, 호환성에 대해 그 런타임에 묶이게 됩니다. 이는 잠금(lock-in)입니다: 데이터는 복사할 수 있어도 벤더 없이 앱을 실행할 수 없기 때문에 벗어나기 어렵습니다.

소스 코드 생성과 런타임 전용을 비교할 때 이식성은 보통 무엇을 가져가서 독립적으로 실행할 수 있는가로 귀결됩니다. 플랫폼이 실제 백엔드와 프런트엔드 코드를 생성한다면 보통 다른 환경으로 배포할 수 있습니다. 예를 들어 AppMaster는 AppMaster Cloud, 주요 클라우드, 또는 소스 코드 내보내기를 지원합니다.

커밋하기 전에는 마이그레이션에서 자주 문제를 일으키는 세부사항을 확인하세요: 전체 및 증분 내보내기 방식, ID와 관계 보존 여부, 개발/스테이징/프로덕트 환경 처리 방식, 백업 위치와 복구 속도, 어떤 배포 대상을 지원하는지, 플랫폼 업데이트를 누가 제어하는지 등입니다.

자가 호스팅은 또한 업무를 귀사 팀으로 옮깁니다. 제어권은 얻되 모니터링, 패치, 스케일링, 사고 대응을 책임져야 합니다. 이러한 비용을 초기에 계획하고 “자가 호스팅 가능”을 단순한 기술 체크가 아닌 운영적 결정으로 다루세요.

보안 검토와 감사: 무엇을 증명해야 하는가

보안 검토가 실패하는 흔한 이유는 단순합니다: 팀이 증거를 제공하지 못합니다. 감사 담당자는 단순히 벤더가 안전하다고 약속하는 것을 원하지 않습니다. 그들은 검증하고 재현할 수 있는 증거를 원합니다.

일반적인 요청은 소스 코드 접근(또는 제공 불가 사유), 의존성 목록과 버전, 프로덕션에서 실행되는 정확한 바이너리를 만드는 빌드·배포 단계, 변경 이력(누가 언제 무엇을 변경했는지), 취약점 처리 절차(CVE 처리, 패치 일정, 테스트) 등입니다.

런타임 전용 플랫폼에서는 증거가 다르게 보이는 경우가 많습니다. 벤더의 보안 보고서, 플랫폼 인증서, 구성 변경 로그를 받을 수 있습니다. 하지만 앱이 벤더 런타임 안에서 실행된다면 코드 수준의 통제를 보여주거나 빌드를 재현하거나 전체 애플리케이션에 대해 정적 분석을 수행하기 어려울 수 있습니다. 일부 감사에는 이것으로 충분하지만 다른 감사에는 장애가 됩니다.

생성된 소스 코드가 있으면 리뷰 작업은 더 익숙하게 느껴집니다. 이를 일반 소프트웨어 프로젝트처럼 다룰 수 있습니다: SAST 도구 실행, 인증·데이터 접근 로직 검토, 시크릿 관리 검증 등. AppMaster 사용 팀은 백엔드와 프런트엔드 코드를 생성하고 필요시 내보내 내부 검토와 자가 호스팅을 진행할 수 있어 “코드를 보여달라”는 요청이 막다른길이 아니라 해결 가능한 요구가 됩니다.

패칭은 차이가 분명해지는 지점입니다. 런타임 전용 환경에서는 런타임 패치를 벤더에 의존합니다. 코드 생성 환경에서는 여전히 CVE를 추적하지만 의존성을 업데이트하고 재생성·재배포하면서 릴리스 간 어떤 것이 변경되었는지 명확한 기록을 유지할 수 있습니다.

비교할 보안 및 컴플라이언스 기본 항목

소스 코드 생성과 런타임 전용 노코드 플랫폼을 비교할 때 기본 항목부터 시작하세요. 이 항목들이 귀사 환경에서 안전하게 앱을 운영하고 일반적인 보안 검사를 통과할 수 있는지를 결정합니다.

자격 증명과 시크릿

시크릿이 어디에 저장되는지(데이터베이스, 환경 변수, 관리형 볼트)와 누가 읽을 수 있는지를 확인하세요. 시크릿을 앱 정의와 분리하고 회전을 지원하며 API 키를 시각적 워크플로나 클라이언트 사이드 코드에 저장하지 않는 구성을 선호하세요.

데이터베이스 비밀번호, JWT 서명 키, 웹훅 시크릿, 서드파티 토큰 같은 항목의 회전도 테스트하세요. 회전에 다운타임이나 여러 곳의 수동 편집이 필요하면 현실적 위험이 됩니다.

접근 제어와 감사 추적

단순히 ‘관리자’와 ‘사용자’만 있는 것이 아니라 명확한 역할과 권한이 필요합니다. 인증 설정 변경, 코드 내보내기, 민감한 데이터가 포함될 수 있는 로그 보기, 통합 편집 같은 고위험 동작에 주목하세요.

감사 로그는 공식 감사 이전에도 중요합니다. 누가 언제 어디서 무엇을 변경했는지 답할 수 있어야 합니다. 이상적으로는 로그를 귀사 로깅 시스템으로 내보낼 수 있고 변조로부터 보호되어야 합니다.

데이터 처리 및 복원력

플랫폼이 전송 중(TLS)과 저장 중(디스크 또는 DB 암호화 옵션) 데이터를 어떻게 보호하는지 비교하세요. 백업이 얼마나 자주 실행되는지, 어디에 저장되는지, 복원이 어떻게 테스트되는지, 포인트 인 타임 복구가 가능한지 자세히 살피세요.

간단한 테스트로 사고 시나리오를 따라가 보세요. 노트북 분실, 키 유출, 잘못된 배포 후 복원 등 상황에서 명확한 절차와 책임자가 있는지 확인하세요.

서드파티 통합

통합은 조용히 귀하의 컴플라이언스 범위를 확장할 수 있습니다. 결제(Stripe), 이메일/SMS, 메시징(Telegram), AI 서비스는 민감한 데이터를 받을 수 있습니다. 어떤 데이터가 전송되는지, 필드를 마스킹할 수 있는지, 문제가 생겼을 때 얼마나 빨리 통합을 비활성화할 수 있는지 확인하세요.

짧은 비교 체크리스트:

• 시크릿 저장과 회전
• 관리자 동작을 포함한 역할 기반 접근 제어와 감사 로그
• 전송 중 및 저장 중 암호화, 백업 및 복원 옵션
• 통합 및 데이터 공유에 대한 통제
• 네트워크 규칙(VPC, 방화벽, 프라이빗 서브넷)에 맞는 자가 호스팅 가능성

자가 호스팅 가능한 노코드 플랫폼(AppMaster 등)을 평가 중이라면, 빌드 전에 이 질문들을 조기에 던지세요. 시크릿, 접근, 데이터 처리 규칙을 나중에 고치기보다 처음부터 정해 두는 것이 훨씬 쉽습니다.

단계별: 자가 호스팅 플랫폼을 평가하는 방법

자가 호스팅과 감사를 통과해야 한다면, 단순히 빌더를 고르는 것이 아닙니다. 향후 몇 년간 앱을 어떻게 운영·검사·유지할지를 선택하는 것입니다. 좋은 평가는 데모가 아니라 작은 통제된 실험처럼 보입니다.

우선 비관용 항목(Non-negotiables)을 적으세요: 데이터가 반드시 어디에 있어야 하는지(데이터 거주성), 누가 서버를 운영하는지, 필요한 가동 시간, 감사자가 무엇을 요구할지 등입니다. 여기서 전체 소스 코드가 내보내져야 하는지, 벤더 호스팅 런타임으로도 괜찮은지 결정을 내립니다.

다음으로 실제 사용자 흐름을 매핑하세요. 로그인, 레코드 검색, 파일 업로드, 승인 워크플로처럼 가장 부하나 위험을 유발하는 3~5개 흐름을 선택하세요. 성능에 영향을 줄 수 있는 곳(느린 쿼리, 큰 목록, 통합)을 적어두세요.

그다음 귀사 환경에서 소규모 검증을 실행하세요. 자가 호스팅 노코드 플랫폼이라면 인프라(또는 스테이징 클론)에 배포해 백업, 모니터링, 스케일링을 확인하는 것입니다. 소스 코드 생성과 런타임 전용을 비교한다면 결과물이 실제로 얼마나 이식 가능한지 이 단계에서 검증하세요.

모두를 정렬시키는 간단한 순서:

• 요구사항 확인: 자가 호스팅, 감사 요구, 데이터 거주성
• 핵심 흐름 재현 및 병목 측정
• 귀사 인프라에 소규모 파일럿 배포 및 기본 부하·장애 복구 검사
• 가벼운 보안 리뷰 수행: 역할, 시크릿 처리, 로깅, 패치 프로세스
• 책임 결정: 누가 의존성 업데이트, 사고 처리, 변경 승인 등을 담당할지

마지막으로 발견한 내용을 문서화하세요. 결정, 위험, 증거(설정, 테스트 결과, 리뷰 노트)를 한 페이지로 정리해 두면 특히 노코드 보안 감사 때 시간을 절약할 수 있습니다.

AppMaster가 후보군에 있다면 한 가지 추가 검증 포인트를 넣으세요: 선호하는 클라우드로 배포할 수 있는지, 소스 코드를 내보낼 수 있는지 확인하고 생성된 것을 내부 리뷰 프로세스로 검증하세요.

팀들이 자주 범하는 실수

팀들은 종종 데모를 얼마나 빨리 만들 수 있는지에 따라 플랫폼을 선택하고, 자가 호스팅이나 보안 리뷰가 필요해졌을 때 곤경에 처합니다. 프로토타입과 배포 가능하고 감사 가능한 앱 사이의 갭에서 대부분의 문제가 드러납니다.

한 가지 오해는 ‘노코드’가 ‘보안 작업 불필요’라는 뜻이 아니라는 것입니다. 접근 제어, 로깅, 백업, 시크릿 처리, 사고 계획은 여전히 필요합니다. 감사자가 데이터 흐름, 저장 위치, 로직 변경 권한에 대해 물으면 “노코드 툴을 사용했다”는 답은 충분하지 않습니다.

또 다른 실수는 까다로운 요구사항을 너무 늦게 테스트하는 것입니다. 자가 호스팅, 내보내기, 코드 리뷰가 필수라면 첫 주에 검증하세요, 수개월 빌드 후가 아니라. 성능도 마찬가지로 플랫폼이 피크 부하를 처리할 수 있다고 가정하지 말고 증거를 확보하세요.

나중에 재작업이 발생하는 이유는 대개 다음 몇 가지에서 비롯됩니다: 벤더가 전적으로 ‘관리한다’고 가정하고 귀사 소유 범위를 정의하지 않음, 대부분 앱을 만든 뒤에 자가 호스팅·내보내기 테스트를 함, 업그레이드 및 깨지는 변경이 어떻게 전달되는지 묻지 않음, 통합 한계를 늦게 발견(결제, 메시징, SSO, 내부 시스템), UI 속도만 보고 런타임 제약과 감사 요구를 무시함.

예: 한 팀이 내부 지원 포털을 구축했는데 런타임이 사설 네트워크에 배포될 수 없다는 사실을 나중에 알게 되고, 감사는 전체 로직 검토를 요구합니다. 이제 그들은 재구축하거나 위험을 받아들여야 합니다. 소스 코드 생성 플랫폼을 비교 중이라면 작은 파일럿에 필수 통합과 실제 배포 경로를 포함해 테스트하세요. AppMaster 같은 소스 코드 생성 플랫폼이라면 실무적 질문은 “귀사 보안팀이 생성된 코드를 검토할 수 있고 운영팀이 원하는 곳에서 실행할 수 있나?”가 됩니다.

커밋하기 전 빠른 체크리스트

귀사 팀이 자가 호스팅해야 하고 감사를 통과하거나 벤더 리뷰를 받아야 한다면 번쩍이는 데모만으로는 부족합니다. 빌드 후 귀사가 소유하고 실행하며 증명할 수 있는 것을 확인하는 것이 가장 빠른 방법입니다.

소스 코드 생성 vs 런타임 전용 노코드를 비교할 때 유용한 짧은 체크리스트:

• 소스 코드와 재빌드: 전체 소스 코드를 내보내어 귀사 파이프라인에서 재빌드하고 동일한 결과물을 재현할 수 있나?
• 배포 제어: 대상 환경(AWS, Azure, Google Cloud, 온프레)에 런타임에 묶이지 않고 배포할 수 있나?
• 감사 증거: 감사자에게 무엇을 보여줄 수 있나: 의존성 목록, 버전 이력, 요구사항에서 릴리스까지의 변경 추적?
• 운영 기본: 다른 서비스처럼 모니터링, 로그, 알림을 운영할 수 있나?
• 보안 위생: 시크릿 저장·회전 방식, 역할과 접근 제어, 보존·삭제 규칙은 어떤가?

실용적 테스트는 작은 내부 앱(관리자 패널 등)을 골라 일반 프로세스대로 리포지토리 접근, 빌드, 배포, 로깅, 기본 보안 리뷰를 진행하는 것입니다. AppMaster가 후보라면 파일럿에 “소스 생성 및 필요 시 내보내어 자가 호스팅” 경로를 포함하세요. 약속이 아닌 실제 경로를 검증해야 합니다.

예시 시나리오: 코드 감사와 자가 호스팅이 필요한 팀

중견기업이 내부 고객 지원 포털을 원합니다. 상담원이 티켓, 고객 프로필, 주문 내역을 조회합니다. 데이터가 민감해 앱은 공개 인터넷에서 접근할 수 없는 사설 네트워크 내부에서 실행되어야 합니다.

보안팀의 규칙도 엄격합니다: 출시 전에 보안 리뷰를 통과해야 합니다. 이는 프로덕션에서 어떤 코드가 실행되는지, 어떤 서드파티 컴포넌트가 포함되는지, 시크릿이 어떻게 저장되는지, 업데이트는 어떻게 관리되는지 등을 보여줘야 합니다.

이 지점에서는 소스 코드 생성 vs 런타임 전용 노코드의 선택이 선호가 아니라 실무적 결정이 됩니다. 런타임 전용 플랫폼에서는 보통 벤더 런타임을 블랙박스처럼 보고 벤더가 제공하는 통제를 중심으로 리뷰가 진행됩니다. 반면 소스 코드 생성 플랫폼(AppMaster처럼 백엔드·웹·모바일 코드를 생성하는 플랫폼)을 사용하면 앱을 내보내 일반 코드베이스처럼 자가 호스팅과 감사를 진행할 수 있습니다.

결정 포인트는 단순합니다:

• 내보내기 요구: 전체 소스 코드를 얻어 직접 빌드할 수 있나, 아니면 벤더 런타임에 묶여 있나?
• 감사 증거: 코드를 제공할 수 있고 재현 가능한 빌드 프로세스와 명확한 환경 설정을 제시할 수 있나?
• 부하 하의 성능: 앱이 피크 티켓 볼륨, 검색 쿼리, 동시 세션을 견딜 수 있나?

작은 파일럿이 실무를 단순화합니다. 예를 들어 “상담원이 티켓을 열고 고객 기록을 보고 템플릿 회신을 보낸다” 같은 실제 워크플로를 선택해 엔드투엔드로 구축하고 사설 환경에 배포해 핵심 화면과 API를 부하 테스트하고 미니 보안 리뷰(인증, 권한, 로깅, 시크릿, 의존성 가시성)를 실행해 감사자에게 제시할 수 있는 것을 문서화하세요.

다음 단계: 파일럿을 골라 요구사항으로 검증하세요

결정을 내릴 때는 슬라이드가 아니라 실제 파일럿으로 판단하세요. 소스 코드 생성과 런타임 전용 노코드를 비교하는 팀에게 확실성을 빠르게 얻는 방법은 실제로 운영·지원할 무언가를 만드는 것입니다.

먼저 귀사가 반드시 소유해야 할 것을 적으세요. 어떤 팀은 인프라(앱이 실행되는 위치)만 제어하면 충분하고, 어떤 팀은 인프라와 코드(검토·재빌드·아카이브 대상) 둘 다 제어해야 합니다. 이 한 가지 선택이 테스트할 플랫폼을 결정합니다.

평가 프로젝트는 작지만 허구가 아니어야 합니다. 좋은 파일럿은 몇 가지 역할, 실제 데이터 모델, 비즈니스 규칙 몇 가지를 포함한 내부 도구입니다.

간단한 파일럿 계획:

• 최소 범위 정의: 화면 3~5개, 역할 2개, 핵심 워크플로 1개
• 실제 데이터 모델링(테이블, 관계, 제약) 및 샘플 데이터 임포트
• 승인, 검증, 권한을 반영하는 규칙 2~3개 추가
• 실제 운영하려는 방식(자가 호스팅 또는 선택한 클라우드)으로 배포
• 미니 감사 실행: 보안 리뷰 노트, 빌드 단계, 재현 가능한 증거 수집

소스 코드 생성이 필수라면 파일럿 중 한 가지를 더 테스트하세요: 파일럿 중간에 요구사항을 변경해 보세요. 새 필드를 추가하거나 권한 규칙을 바꾸고 워크플로를 조정하세요. 플랫폼이 깔끔하게 재생성되는지 확인하는 것입니다.

파일럿을 실행하는 구체적인 방법을 원한다면 AppMaster (appmaster.io)는 완전한 애플리케이션을 구축하고 여러 환경에 배포하거나 자가 호스팅을 위해 실제 소스 코드를 생성할 수 있도록 설계되었습니다. 중요한 것은 데모가 아니라 수집한 증거입니다: 무엇이 생성되는지, 빌드를 반복할 수 있는지, 감사자가 검토할 수 있는 것이 무엇인지가 핵심입니다.

파일럿이 끝나면 귀하가 소유해야 하는 범위를 제공하고 내부 검토를 통과하며 요구사항 변경 시에도 유지보수가 가능한 플랫폼을 선택하세요.