소스를 내보낸 프로젝트에는 이식성 테스트가 필요합니다

소스 코드를 내보냈다는 것은 파일을 받았다는 뜻일 뿐입니다. 원래 AI 앱 빌더가 사라진 뒤에도 프로젝트를 빌드하고, 시작하고, 사용자를 인증하고, 운영 데이터를 읽고, 배포할 수 있다는 증거는 아닙니다. 이식성은 판매 계약서의 체크 항목이 아니라 인수 테스트로 다뤄야 합니다.

생성된 애플리케이션을 여러 번 넘겨받아 본 경험상, 깔끔한 저장소만 보고는 믿지 않습니다. 비용이 크게 드는 실패는 보통 눈에 보이는 애플리케이션 코드 밖에 숨어 있습니다. 공급업체 서비스로 가는 런타임 요청, 다른 사람의 테넌트에 등록된 인증 콜백, 버전 관리에 한 번도 들어가지 않은 데이터베이스 정책, 관리형 대시보드에만 있는 배포 설정이 그렇습니다. 팀이 내보낸 결과물과 여러분이 통제하는 계정의 문서화된 외부 서비스만으로 작동 상태를 재현할 수 있을 때만 프로젝트는 이식 가능합니다.

소스를 내보낸 프로젝트도 빌더에 의존할 수 있습니다

소스를 내보낸 프로젝트가 독립적으로 실행되려면 빌드와 런타임에 필요한 모든 의존성을 빌더 밖에서 사용할 수 있고, 문서화되어 있으며, 이전 가능하고, 적법하게 사용할 수 있어야 합니다. 이는 «저장소가 컴파일된다»보다 훨씬 엄격한 기준입니다. 빈 컴퓨터에서 작동하는 운영 릴리스에 이르는 모든 과정을 포괄하며, 여기에는 ID, 데이터, 예약 작업, 시크릿, 네트워크 규칙, 복구가 포함됩니다.

서로 다른 세 가지 주장이 자주 뒤섞입니다. 소스 접근은 파일을 검사할 수 있다는 뜻입니다. 빌드 독립성은 빌더를 호출하지 않고 아티팩트를 만들 수 있다는 뜻입니다. 런타임 독립성은 그 아티팩트가 빌더 없이도 실제 요청을 계속 처리한다는 뜻입니다. 공급업체는 첫 번째 조건은 충족하면서 나머지 두 조건은 충족하지 못할 수 있습니다.

이 차이는 계약에 직접 영향을 줍니다. 계약서가 «소스 내보내기»를 약속한다면 React 디렉터리, 패키지 매니페스트, README를 받을 수 있지만, 여전히 독점 SDK나 호스팅 게이트웨이가 필요할 수 있습니다. 대신 운영 결과를 요구하세요. 고객이 소유한 계정을 사용해, 권한 있는 엔지니어가 깨끗한 환경에서 인수된 릴리스를 빌드하고 실행할 수 있어야 합니다.

테스트 전에 경계를 정하세요. 관리형 서비스가 있다고 해서 자동으로 이식성 실패는 아닙니다. 대부분의 중요한 애플리케이션은 클라우드, 결제 처리업체, 이메일 제공업체, ID 서비스를 사용합니다. 핵심은 그 의존성을 의도적으로 선택했고, 자체 계약으로 이전하거나 교체할 수 있는지입니다. 별도로 계약할 수 없는 숨은 공급업체 서비스와 여러분의 클라우드 계정에 있는 문서화된 PostgreSQL 데이터베이스는 다릅니다.

외부 구성 요소마다 소유자, 용도, 교체 경로, 장애 시 동작이라는 네 항목을 둔 의존성 등록부를 만드세요. «소유자»는 비밀번호를 아는 사람이 아니라 법적 계정 소유자입니다. «교체 경로»는 마이그레이션 절차, 재구현 가능한 인터페이스, 또는 서비스를 계속 쓰겠다는 명시적 결정일 수 있습니다. «장애 시 동작»에는 서비스를 사용할 수 없을 때 사용자가 무엇을 보게 되는지 기록합니다. 판매자가 이 항목을 채울 수 없다면, 내보내기 결과는 위험을 가격에 반영할 만큼 충분히 설명되지 않은 것입니다.

가장 좋은 첫 테스트는 단순합니다. 빌더 계정 접근을 끊고 애플리케이션을 실행해 보세요. 스테이징 사본에서 토큰을 해제하고, 네트워크 경계에서 알려진 도메인을 차단한 뒤 무엇이 실패하는지 살펴보세요. 모든 파일을 읽는 것부터 시작하지 마세요. 런타임 증거는 주입된 설정과 컴파일된 패키지가 만드는 호출을 포함해 코드 검토가 놓치는 의존성을 찾아냅니다.

실제 워크플로를 실행하며 애플리케이션 추적하기

대표적인 워크플로를 실행하는 동안 DNS, 아웃바운드 연결, 브라우저 요청, 백그라운드 작업을 관찰하면 런타임 콜백이 드러납니다. 홈 페이지가 로드된다는 사실만으로는 충분하지 않습니다. 로그인, 비밀번호 복구, 파일 업로드, 검색, 결제 전환, 이메일 발송, 예약 작업, 관리자 작업, 제품이 실제로 판매하는 AI 기능을 실행하세요.

아웃바운드 트래픽을 기록하는 새 스테이징 네트워크에서 애플리케이션을 실행하세요. 의존성 등록부에 적힌 목적지만 허용합니다. 환경이 허용한다면 목록 밖 트래픽은 기본적으로 거부하는 정책으로 시작하세요. 차단된 요청마다 물어야 합니다. 필수인가요, 선택 사항인 텔레메트리인가요, 업데이트 확인인가요, 문서화되지 않은 제어 영역 호출인가요?

일부 의존성은 서버에 전혀 닿지 않으므로 브라우저 개발자 도구도 중요합니다. 저장소를 지우고 새 세션을 사용한 뒤 Network 패널을 살펴보세요. 요청 호스트, 실패한 사전 요청, WebSocket 연결, 로드된 스크립트, 리디렉션을 확인합니다. 서버 저장소가 완결돼 보이더라도 프런트엔드가 빌더 API를 직접 호출할 수 있습니다. 서비스 워커도 이전 동작을 보존할 수 있으므로 테스트를 반복하기 전에 등록을 해제하세요.

Unix 계열 소스 트리에서는 다음 검색으로 유용한 첫 목록을 얻을 수 있습니다.

grep -R -n -E 'https?:|wss?:|fetch[(]|axios|WebSocket|grpc|callback|webhook' .

출력은 path/to/file:line:matching text 형태가 됩니다. 패키지 메타데이터의 도메인이 런타임 호출을 증명하지는 않으므로, 생성된 잠금 파일은 애플리케이션 코드와 별도로 검토하세요. 반대로 검색 결과가 깨끗하다고 독립성이 증명되는 것도 아닙니다. 환경 변수가 호스트를 조합할 수 있고, DNS 별칭이 호스트를 숨길 수 있으며, 바이너리 의존성이 자체 요청을 만들 수 있습니다.

공급업체 용어, SDK 가져오기, 환경 변수 접두사를 각각 따로 검색하세요. 그런 다음 잠금 파일을 검사해 패키지가 공개 레지스트리에서 해석되는지 비공개 공급업체 레지스트리에서 해석되는지 확인합니다. 캐시된 성공은 여기서 오해를 부를 수 있습니다. 격리된 테스트 환경의 언어 패키지 캐시를 지우고, 문서화된 레지스트리 자격 증명만으로 다시 빌드하세요.

스케줄러 경계를 넘을 만큼 충분히 오래 백그라운드 동작을 추적하세요. 웹 프로세스가 정상으로 보여도 큐 소비자가 실패하고, 예약 보고서가 멈추고, 웹훅 재시도가 쌓일 수 있습니다. 정상 스케줄을 기다리면 테스트가 느려질 경우 작업을 수동으로 실행하세요. 각 아웃바운드 통합에 대해 목적지, 요청 방식, 인증 유형, 응답 분류, 재시도 규칙, 사용자에게 보이는 결과를 기록합니다.

«그 콜백은 텔레메트리일 뿐입니다»라는 말을 검증 없이 받아들이지 마세요. 이를 차단하고 워크플로를 다시 실행하세요. 선택 사항인 텔레메트리는 빠르게 시간 초과되거나 사용자의 작업에 영향을 주지 않고 실패해야 합니다. 로그 호출이 요청 트랜잭션 안에 있어 무해한 분석 서비스 장애가 저장 실패로 바뀌는 경우를 본 적이 있습니다. 위험을 결정하는 것은 이름표가 아니라 코드 경로입니다.

독점 SDK에는 제거 또는 라이선스 경로가 필요합니다

독점 SDK는 독립적으로 확보하고, 이를 대상으로 빌드하고, 적법하게 실행하며, 비즈니스가 감당할 수 있는 일정에 맞춰 교체할 수 있을 때만 허용할 수 있습니다. 내보낸 결과에 래퍼 소스가 있다고 해서 그 뒤의 SDK, 프로토콜, 호스팅 엔드포인트, 모델을 사용할 권리가 생기는 것은 아닙니다.

매니페스트와 소스 가져오기에서 모두 의존성을 목록화하세요. JavaScript는 잠금 파일과 함께 package.json을 검사합니다. Go는 go.mod와 체크섬을 검사합니다. Flutter는 잠금 파일과 함께 pubspec.yaml을 검사합니다. Git 저장소, 비공개 레지스트리, 로컬 경로, 아카이브에서 가져오는 패키지를 기록하세요. 빌더 소유 구성 요소가 흔히 숨는 위치입니다.

의심스러운 패키지마다 다음 네 가지 구체적인 질문에 답하세요.

1. 고객 소유의 새 빌드 에이전트가 정확히 그 버전을 내려받을 수 있는가?
2. 빌더 계약이 끝난 뒤에도 라이선스가 운영 사용을 허용하는가?
3. 패키지가 고객이 직접 계약할 수 있는 서비스를 호출하는가?
4. 인터페이스가 교체할 만큼 작고, 그 인터페이스는 테스트되어 있는가?

고객 소유 조직에서 만든 자격 증명으로 콜드 빌드를 수행하세요. 개발자의 전체 설정 디렉터리를 테스트 컴퓨터에 복사하지 마세요. 그러면 캐시된 패키지, 암묵적인 레지스트리 설정, 개인 토큰까지 가져오게 되어 테스트 목적이 사라집니다. 올바른 빌드 절차는 문서화된 도구 체인 버전으로 시작하고, 추가 자격 증명은 각각 명시합니다.

도구 체인이 지원한다면 소프트웨어 자재 명세서를 생성하되, 이를 이식성 판정으로 혼동하지 마세요. SBOM은 구성 요소를 나열하지만, 원격 계정을 누가 통제하는지나 패키지가 외부로 호출하는지는 거의 알려주지 않습니다. 저장소가 선언한 내용과 빌드된 아티팩트에 들어 있는 내용을 대조하는 데 사용하세요.

독점 클라이언트가 좁은 어댑터 뒤에 있다면 지금 어댑터에 대한 계약 테스트를 작성하세요. 알려진 요청을 넣고 정규화된 응답을 검증한 다음, 네트워크 엔드포인트를 차단한 상태에서도 같은 테스트를 실행합니다. 실패는 명확하고 제한적이어야 합니다. 독점 호출이 뷰 구성 요소, 라우트 처리기, 데이터 모델 전반에 흩어져 있다면 계약 전에 리팩터링 비용을 산정하세요. 문제의 규모는 SDK의 코드 줄 수가 아니라 호출 지점 수와 의미적 결합도에 따라 커집니다.

팀은 구매 전에 모든 독점 의존성을 교체하라고 권하는 경우가 많습니다. 안전하게 들리지만 구매자가 계속 사용할 서비스를 교체하느라 몇 주를 낭비할 수 있습니다. 더 나은 원칙은 확보하거나 계약할 수 없는 의존성은 제거하고, 받아들일 의존성은 분리하며, 나머지는 이전 비용을 붙이는 것입니다. 이식성이란 외부 서비스가 전혀 없는 애플리케이션이 아니라 선택권을 통제하는 것입니다.

인증은 소스 트리보다 넓은 범위에 있습니다

고객이 ID 테넌트, 리디렉션 등록, 서명 키, 사용자 식별자, 이메일 템플릿, 복구 절차를 통제할 때만 인증을 깔끔하게 옮길 수 있습니다. 애플리케이션 코드는 보통 이 시스템의 한 부분만 담고 있습니다.

실제 경유지로 로그인 경로를 그리는 것부터 시작하세요. 브라우저가 애플리케이션에 연결되고, 애플리케이션은 ID 공급업체로 리디렉션하며, 공급업체는 등록된 콜백으로 돌아오고, 백엔드는 자격 증명을 교환하거나 검증합니다. 각 경유지의 소유자와 설정 위치를 기록하세요. 빌더 조직을 통해서만 접근할 수 있는 콘솔이 있다면 인수 전에 이전 또는 교체를 요구해야 합니다.

관리형 인증은 특히 까다로운 데이터 문제를 만듭니다. 애플리케이션의 사용자 테이블은 이메일 주소나 내부 영구 ID 대신 공급업체별 주체를 저장할 수 있습니다. 새 ID 테넌트가 다른 주체를 발급하면 행을 내보내도 도움이 되지 않습니다. 계정 매칭, 중복 처리, 비밀번호 사용자, 소셜 로그인 사용자, 다중 인증 등록, 잠긴 계정, 이메일 주소가 바뀐 사용자를 테스트하세요.

OpenID Connect는 sub 클레임을 발급자 범위 안에서만 고유하며 재할당되지 않는 식별자로 정의합니다. 발급자가 중요합니다. sub만으로 전 세계에서 이식 가능하다고 간주하면 테넌트 변경 뒤 잘못된 애플리케이션 레코드가 연결될 수 있습니다. 발급자와 주체를 함께 저장하고 비교한 뒤, 이전을 위한 명시적 매핑을 설계하세요.

테스트에는 최소 네 계정이 필요합니다. 일반 사용자, 관리자, 비활성 사용자, 두 번째 인증 요소를 가진 사용자입니다. 고객 소유 테넌트로 ID 설정을 옮기거나 새로 만들고, 스테이징 데이터베이스 사본을 복원한 뒤 로그인 성공과 접근 거부를 확인하세요. 로그아웃, 토큰 갱신, 비밀번호 재설정, 초대 수락, 세션 만료도 테스트합니다. 팀은 정상 로그인 경로는 기억하지만, 전환 후에야 깨진 복구 기능을 발견하곤 합니다.

저장소에서 리디렉션 URI, 클라이언트 ID, 발급자 이름, 쿠키 도메인, 대상 값, 서명 키 참조를 검색하세요. 시크릿은 저장소 밖에 두되, 배포 문서에는 이름, 소유자, 생성 단계, 교체 단계, 필요한 형식을 기록합니다. 예시 환경 파일에는 실제 값을 넣지 않고 계약 내용을 식별해야 합니다.

AUTH_ISSUER=
AUTH_CLIENT_ID=
AUTH_CLIENT_SECRET=
AUTH_CALLBACK_ORIGIN=
SESSION_SIGNING_KEY=

나중에 이전할 수 있다는 이유만으로 공유 빌더 테넌트를 영구적인 방식으로 받아들이지 마세요. ID 이전은 모든 활성 사용자와 모든 권한 가정에 영향을 줍니다. 계약 전에 통제권을 이전하거나, 교체를 비용이 산정되고 테스트된 거래 조건으로 만드세요.

데이터베이스 이식성에는 동작과 운영도 포함됩니다

스키마, 확장 기능, 행 수준 정책, 트리거, 객체 스토리지, 큐, 백업, 연결 규칙이 데이터베이스 밖에 있으면 데이터베이스 덤프만으로는 부족합니다. 데이터베이스 이식성이란 데이터를 복원하고, 이를 보호하고 변경하는 동작까지 재현할 수 있다는 뜻입니다.

문서화된 메이저 버전의 빈 고객 소유 PostgreSQL 인스턴스에서 시작하세요. 저장소 마이그레이션을 순서대로 적용합니다. 프로젝트에 마이그레이션이 없고 공급업체가 만든 스키마 덤프를 가져와야 한다면 결함으로 기록하세요. 덤프는 오늘의 상태를 담을 수 있지만, 다음 릴리스가 그 상태를 어떻게 안전하게 바꾸는지는 설명하지 못합니다.

복원된 스키마를 운영 또는 스테이징과 비교하세요. 테이블, 열, 유형, 제약 조건, 인덱스, 시퀀스, 뷰, 함수, 트리거, 활성화된 확장 기능, 역할, 권한 부여, 행 수준 보안 정책을 확인합니다. 많은 마이그레이션 도구는 역할과 공급업체 수준 설정을 빠뜨립니다. 복원된 역할에 시퀀스나 함수 권한이 없어 관리자 작업이 실패하는데도 애플리케이션은 기본 읽기 테스트를 통과할 수 있습니다.

그다음 통제된 왕복 과정으로 데이터 경로를 검증하세요.

1. 공개 애플리케이션 워크플로를 통해 레코드를 만듭니다.
2. 공유가 허용되어야 하는 경우 두 번째 권한 있는 사용자로 읽습니다.
3. 권한 없는 사용자가 읽거나 변경할 수 없음을 확인합니다.
4. 애플리케이션을 통해 업데이트하고 삭제합니다.
5. 데이터베이스를 또 다른 깨끗한 인스턴스로 복원하고 읽기를 반복합니다.

이 순서는 애플리케이션 코드, 권한 정책, 생성 값, 복구 가능성을 함께 테스트합니다. 직접 SQL로 행 수만 세어서는 이런 동작을 다룰 수 없습니다.

행이 업로드 파일을 가리킨다면 객체 스토리지를 데이터베이스 경계의 일부로 다루세요. 버킷, 객체 메타데이터, 접근 규칙, 수명 주기 규칙, URL 생성 설정을 내보냅니다. 기본 파일이 빌더 소유 버킷에 남아 있으면 객체 키로 가득 찬 복원된 데이터베이스는 쓸모가 없습니다. 검색 인덱스와 벡터 저장소도 마찬가지입니다. 이전할지 다시 구축할지 결정하고, 재구축 절차를 증명하세요.

작은 덤프 하나로 성공이나 실패를 판단하지 마세요. 긴 텍스트, null, 비ASCII 문자, 대형 객체, 일광 절약 시간 전환 전후의 타임스탬프, 대표적인 관계를 포함한 스테이징 규모 사본을 사용하세요. 꾸며낸 벤치마크는 필요하지 않습니다. 허용된 중단 시간 안에 이전이 끝나고 이후에도 애플리케이션이 동작한다는 증거가 필요합니다.

백업을 한다는 주장은 복원이 있어야 합니다. 누가 백업 일정을 잡는지, 사본은 어디에 있는지, 누가 복호화할 수 있는지, 보존 방식은 무엇인지, 백업 실패를 어떻게 감지하는지 확인하세요. 작성된 지침으로 격리된 계정에 하나를 복원합니다. 빌더만 복원 버튼을 누를 수 있다면 독립적인 복구 계획이 아니라 서비스 기능일 뿐입니다.

CI 파이프라인이 없으면 제품 지식도 빠진 것입니다

재현 가능한 지속적 통합이 없는 내보낸 저장소는 구매자가 도구 버전, 빌드 순서, 테스트, 아티팩트 패키징, 데이터베이스 마이그레이션 시점, 릴리스 관문을 다시 찾아내게 만듭니다. 판매자의 내부 파이프라인을 그대로 이전할 수 없더라도, 그 지식은 결과물의 일부입니다.

파이프라인 정의, 컨테이너 빌드 파일, 도구 버전 파일, 테스트 명령, 린트 규칙, 마이그레이션 명령, 인프라 정의를 찾으세요. 그런 다음 실제 배포 로그와 비교합니다. 문서에는 단순한 웹 빌드만 적혀 있지만, 관리형 플랫폼이 조용히 설정을 생성하고, 서버 구성 요소를 주입하고, 모바일 번들을 빌드하거나, 데이터베이스 마이그레이션을 실행하는 경우가 많습니다.

고객 소유 CI 계정에서 최소 파이프라인을 재구성하세요. 고정된 리비전을 체크아웃하고, 선언된 도구 체인을 설치하고, 의존성을 가져오고, 테스트를 실행하고, 변경 불가능한 아티팩트를 만들며, 아티팩트 ID를 기록해야 합니다. 테스트 중 배포는 수동으로 해도 되지만, 스테이징에 도달하는 아티팩트는 파이프라인이 만든 아티팩트여야 합니다.

간결한 인수 로그는 다음과 같은 형태를 쓸 수 있습니다.

revision: 4f2c9ab
toolchain: declared versions loaded
dependencies: cold install passed
tests: unit and integration passed
artifacts: web, server, mobile
migrations: dry run passed
staging: health and workflow checks passed

값은 달라지겠지만 모든 줄에는 사람의 기억이 아니라 기계 출력이나 연결된 내부 기록이 있어야 합니다. 인수 증거와 함께 로그를 보관하세요.

필요하지 않다면 판매자의 비밀 배포 체계를 요구하지 마세요. 결과를 재현하기에 충분한 지침과 설정을 요구하세요. 이식 가능한 파이프라인은 같은 필수 단계를 수행하고 릴리스 통제를 약화하지 않는 한 다른 CI 제품을 대상으로 해도 됩니다.

모바일 애플리케이션에는 서명 자산, 패키지 식별자, 스토어 계정, 푸시 알림 자격 증명이 추가됩니다. 소스 빌드는 이런 항목 없이도 에뮬레이터에서 실행될 수 있어 쉽게 놓칩니다. 배포 계정의 고객 소유권을 확인하고 인증서 교체 절차를 문서화하세요. 서버와 웹 애플리케이션은 릴리스 연습에 도메인 검증, TLS 인증서 발급, DNS 변경, 캐시 무효화를 포함합니다.

파이프라인 테스트는 제공받은 커밋을 다시 빌드하는 것으로 끝나지 않고, 변경으로 끝납니다. 눈에 보이지만 무해한 수정을 하고, 롤백 가능한 데이터베이스 마이그레이션을 추가해 빌드한 뒤 스테이징에 배포하고 검증한 다음 롤백을 실행하세요. 이는 한 번 생성되어 체크인됐지만 다시 생성할 수 없는 아티팩트를 찾아냅니다.

언어 도구 체인뿐 아니라 빌드에 쓰이는 운영체제 패키지도 고정하세요. 네이티브 모듈은 빌더 이미지에 우연히 있는 라이브러리를 대상으로 컴파일될 수 있습니다. 새 러너에서는 애플리케이션 테스트가 시작되기도 전에 실패하거나, 더 나쁘게는 동작이 다른 아티팩트를 만들 수 있습니다. 컨테이너 정의나 동등한 기계 판독 가능한 빌드 설명에 패키지 이름과 버전을 기록하세요.

CI 로그에 시크릿을 남기지 않으면서도 파이프라인이 고객 통제 저장소에서 이를 가져올 수 있음을 증명하세요. 테스트는 짧은 수명의 스테이징 자격 증명을 만들고, 문서화된 방식으로 주입하며, 소스를 편집하지 않고 교체해야 합니다. 지원 직원이 공급업체 대시보드에 시크릿을 붙여 넣어야 한다면 설정 메모 안에 숨기지 말고 그 의존성을 기록하세요.

클린룸 배포에서 호스팅 가정이 드러납니다

빌더를 모르는 팀이 내보낸 결과물, 선언된 서비스, 문서화된 지침만 사용해 고객 소유 환경에서 시스템을 시작할 수 있다면 클린룸 배포는 이식성을 증명합니다. 계약 인수 전에 시간 제한과 이슈 로그를 두고 실행하세요.

의도한 운영 모델에 맞는 환경을 선택하세요. 관리형 플랫폼에서 원시 가상 머신으로 옮기면 관련 없는 작업이 생기고, 이식 가능한 프로젝트도 망가진 것처럼 보일 수 있습니다. 컨테이너, PostgreSQL, 객체 스토리지, 예약 작업, 시크릿, 부하 분산 같은 필수 요소는 맞추되, 문서화되지 않은 공급업체 마법을 재현하지는 마세요.

애플리케이션에 쓰기 가능한 로컬 디스크, 고정 포트, 고정 세션, 신뢰하는 프록시 헤더, 리전 이름, 주입된 호스트 이름, 플랫폼별 환경 변수에 대한 가정이 있는지 검사하세요. Twelve-Factor App은 설정을 환경에 저장하고 백엔드 서비스를 연결된 리소스로 다룰 것을 권합니다. 이 원칙은 여전히 유용하지만 환경 변수만으로는 소유자, 형식, 생성 방법이 문서화되지 않습니다. 각 변수에 운영 기록을 연결하세요.

상태 확인은 직접 테스트할 가치가 있습니다. 마이그레이션이 끝나거나 필수 의존성이 연결되기 전에 성공을 반환하는 프로세스는 오케스트레이터 뒤에서 재시작 루프에 들어갈 수 있습니다. 호스팅 시스템이 지원한다면 라이브니스와 레디니스를 분리하세요. 데이터베이스, 객체 저장소, 큐를 하나씩 멈춘 뒤 상태 코드, 로그, 재시도 동작, 서비스가 돌아온 뒤의 복구를 관찰합니다.

애플리케이션이 여러 인스턴스를 어떻게 다루는지도 확인하세요. 메모리 내 세션, 로컬 업로드 디렉터리, 프로세스 로컬 작업 잠금은 하나의 관리형 인스턴스에서는 동작하지만 확장 후에는 실패합니다. 인스턴스 두 개를 시작하고, 같은 사용자의 요청을 둘 다 거치게 하며, 동시 작업 워커를 실행하세요. 세션이 유지되고, 파일을 계속 사용할 수 있으며, 예약 작업이 멱등적으로 설계되지 않았다면 두 번 실행되지 않는지 확인합니다.

시작만큼 종료도 주의 깊게 관찰하세요. 요청과 백그라운드 작업이 활성화된 상태에서 종료 신호를 보냅니다. 프로세스는 새 작업 수락을 중단하고, 이미 가져온 작업은 완료하거나 안전하게 되돌리고, 연결을 닫은 뒤 호스트의 유예 시간 안에 종료해야 합니다. 관리형 빌더는 새 호스트에 없는 긴 시간 제한이나 재시도로 갑작스러운 종료를 감췄을 수 있습니다.

로그와 지표에도 호스팅 가정이 들어 있습니다. 애플리케이션이 구조화된 이벤트를 문서화된 목적지에 기록하고, 필요한 경우 시크릿과 개인 데이터를 제거하며, 실패한 워크플로를 진단할 충분한 정보를 노출하는지 확인하세요. 표준 출력이나 다른 고객 통제 수집처가 필요한 증거를 보존한다면 독점 대시보드는 선택 사항입니다.

리전과 데이터 위치에 관한 주장은 설정 증거가 필요합니다. 애플리케이션, 데이터베이스, 백업, 로그, 객체 스토리지가 실행되는 위치와 데이터를 받는 외부 서비스를 기록하세요. 웹 프로세스의 리전 선택기로는 인증이나 분석 서비스가 다른 곳으로 데이터를 보낼 때 데이터를 해당 국가에 보관할 수 없습니다. 계약은 이런 위치 변경을 누가 승인하는지도 명시해야 합니다.

Koder.ai는 소스 내보내기, 배포와 호스팅, 사용자 지정 도메인, 스냅샷, 롤백을 지원합니다. 독립 실행을 위해 내보낸 Koder.ai 프로젝트를 평가한다면 같은 클린룸 기준을 적용하세요. 여러분이 소유할 환경에서 내보낸 React, PostgreSQL을 사용하는 Go, Flutter 구성 요소를 테스트하고, 계속 사용하기로 선택한 서비스는 문서화하세요.

통과 및 실패 조건을 계약에 넣으세요

계약은 이식성을 관찰된 동작으로 정의하고, 인수 환경을 나열하며, 시정 책임을 배정하고, 최종 대금 지급이나 종속이 확정되기 전에 실패를 고칠 충분한 시간을 보장해야 합니다. 모호한 소유권 문구는 아무도 배포할 수 없는 애플리케이션을 구해주지 못합니다.

«소스 코드»라는 제목의 문단 하나에 의존하지 말고 인수 매트릭스를 첨부하세요. 각 행에는 기능, 테스트 절차, 기대 결과, 증거, 책임 주체, 심각도를 적어야 합니다. 콜드 빌드, 런타임 네트워크 호출, ID 이전, 데이터베이스 복원, 파일 스토리지, 백그라운드 작업, CI, 클린 배포, 모니터링, 백업 복원, 작은 변경, 롤백을 다루세요.

제3자가 관찰할 수 있는 통과 기준을 사용하세요. «치명적인 독점 의존성 없음»은 논쟁을 부릅니다. «빌더 소유 자격 증명을 해제하고 빌더 도메인을 차단한 상태에서 스테이징 애플리케이션이 워크플로 A부터 F까지를 완료한다»는 테스트할 수 있습니다. 팀이 승인된 관리형 서비스를 실패로 오인하지 않도록 허용된 의존성을 이름과 계정 소유자로 정의하세요.

소스와 운영 자료를 고정된 리비전으로 제공하도록 요구하세요. 잠금 파일, 마이그레이션, 빌드 정의, 가능한 경우 인프라 설정, 환경 변수 목록, 의존성 등록부, 데이터 내보내기, ID 이전 계획, 런북, 라이선스 고지, 고객 소유의 서명 또는 배포 자산이 포함됩니다. 제외 항목은 명시적으로 기록하세요. 침묵이 인수를 뜻해서는 안 됩니다.

심각도는 비즈니스 영향으로 정하세요. 선택적인 분석 이벤트 하나가 빠진 것은 로그인 중단과 같지 않습니다. 유용한 체계는 빌드나 핵심 워크플로를 막는 차단 문제, 중요한 기능이나 복구 경로를 없애는 주요 결함, 문서화된 우회 방법이 있는 경미한 결함을 구분합니다. 보편적인 일정을 억지로 만들지 말고, 이 수준에 인수와 시정 날짜를 연결하세요.

테스트 데이터와 테스트 수행자도 정의하세요. 판매자는 빈 데이터베이스와 일반 권한 검사를 우회하는 관리자 계정으로 이식성을 시연하는 경우가 있습니다. 고객 직원이 문서화된 절차를 수행하도록, 대표적인 사용자, 역할, 파일, 백그라운드 작업을 요구하세요. 시크릿은 합성값을 쓰되, 관계와 예외 상황은 현실적으로 유지합니다.

비용도 증거 패킷에 포함해야 합니다. 내보낸 릴리스를 실행하는 데 필요한 별도 청구 서비스와 판매자가 밝힌 최소 요금제, 데이터 반출 비용, 비공개 레지스트리 구독을 기록하세요. 이 테스트가 모든 미래 청구서를 예측할 필요는 없습니다. 독립적이라고 한 내보내기가 계약 체결 뒤 피할 수 없는 공급업체 계약을 드러내지 않도록 막아야 합니다.

즉시 이전할 수 없는 서비스에는 협조 의무를 넣으세요. 판매자가 키를 교체하거나, ID 내보내기를 승인하거나, 도메인을 이전하거나, 최종 데이터 스냅샷을 제공해야 할 수 있습니다. 행동과 책임자를 이름으로 적으세요. 운영 환경이 중단된 상황에서는 «합리적인 지원»을 강제하기 어렵습니다.

시정 후와 최종 내보내기 후에 테스트를 반복할 권리를 보존하세요. 생성 프로젝트는 빠르게 바뀌며, 지난달 리비전에서 검증된 수정이 어제 추가된 새 의존성에 대해서는 아무 의미가 없습니다. 인수 기록에 테스트한 커밋과 아티팩트 해시를 고정하세요.

에스크로 조항이 이 작업을 대신하게 두지 마세요. 에스크로는 조건이 충족된 사건 뒤 파일을 제공할 수 있지만, 최신 빌드 지침, 자격 증명 소유권, 검증된 복구 경로가 없는 파일은 너무 늦게 도착해 도움이 되지 않을 수 있습니다. 양측이 아직 협조할 수 있을 때 운영 독립성이 갖춰져야 합니다.

두 번째 팀이 원래 빌더의 특별한 도움 없이 인수된 릴리스를 빌드하고, 실행하고, 변경하고, 배포하고, 복구할 수 있을 때 계약하세요. 그보다 못한 것은 해결되지 않은 마이그레이션 프로젝트가 붙은 소스 보유일 뿐이며, 계약 가격에도 그 작업이 반영되어야 합니다.