GitHub에서 배포하는 것은 이미 해결된 문제처럼 들립니다.

저장소(repo)를 클론(Clone)합니다. 스택(stack)을 감지합니다. 이미지를 빌드(Build)합니다. 컨테이너(container)를 실행합니다. SSL을 추가합니다. 트래픽을 라우팅(Route)합니다.

그 하위 레이어(lower layer)가 중요합니다. VibeNest에서는 첫날부터 그 모든 것을 대체하려고 시도하지 않습니다. 첫 번째 배포 경로는 이미 많은 지루한 인프라(infrastructure)—앱 리소스, 빌드, 컨테이너, 라우팅, SSL, 로그, 재시작—를 처리하고 있는 Coolify 위에 구축되어 있습니다.

플랫폼에서 확인한 프로젝트들에 따르면, 이 방식이 상당수의 저장소를 성공적으로 통과시킵니다. 대략 20-30%는 기본 제공 경로(out-of-the-box path)를 통해 처리될 수 있습니다.

나머지는 대개 사소한 이유로 실패합니다.

"Kubernetes가 어렵다"와 같은 이유가 아닙니다. 오히려 다음과 같은 이유들입니다:

• 저장소가 모노레포(monorepo)인데 잘못된 폴더가 배포됨
• Nixpacks가 그럴듯한 빌드 방식을 선택했지만, 올바른 방식은 아니었음
• 앱은 5000 포트에서 리스닝(listen)하고 있는데, 프록시(proxy)는 3000으로 라우팅함
• .env.example에는 DATABASE_URL이라고 되어 있지만, 프로덕션(production)에는 아직 데이터베이스가 없음
• 정식 환경 변수(env var) 대신 DB URL 별칭(alias)이 사용됨
• 브랜치(branch)는 master인데, 배포는 main에서 대기열에 추가됨
• 저장소에 Git LFS가 필요하지만, 빌드 과정에서 포인터 파일(pointer files)만 클론됨
• 앱이 부팅되어 한 번은 통과하지만, 이후 크래시 루프(crash-loops)에 빠지거나 메모리 부족(out of memory)이 발생함

이것이 바로 VibeNest가 자동화하려는 레이어입니다: "컨테이너가 생성되었다"와 "이 앱이 실제로 첫 사용자들에 의해 사용 가능하다" 사이의 간극 말입니다.

1. 지루한 배포부터 시작하기

첫 번째 단계는 의도적으로 평범하게 진행됩니다.

저장소가 단순하다면 Coolify가 배포를 완료합니다. 빌드 팩(build pack), 포트(port), 환경(environment), 런타임(runtime)이 이미 명확할 때 VibeNest가 영리하게 굴 필요는 없습니다.

진정한 가치가 있는 작업은 저장소가 거의 배포 가능한 상태이지만, 프로덕션의 가정이 로컬(local)의 가정과 일치하지 않을 때 시작됩니다.

2. 무엇을 배포할지 결정하기

GitHub 저장소가 항상 하나의 앱인 것은 아닙니다.

프론트엔드(frontend), API, 워커(worker), 문서 사이트(docs site), 봇(bot), 테스트 프로젝트 또는 여러 개의 중첩된 앱을 포함할 수 있습니다. 따라서 배포 전에 VibeNest는 서비스 경계(service boundaries)와 빌드 증거(build evidence)를 찾습니다:

• Dockerfile / docker-compose<br>- package.json, workspaces, pnpm/yarn/npm signals<br>- requirements.txt, pyproject.toml<br>- go.mod, Cargo.toml, composer.json<br>- .sln / .csproj (닷넷 프로젝트용)<br>- 저장소 트리 내의 프레임워크 및 런타임 힌트<br><br>목표는 더 어렵게 추측하는 것이 아닙니다. 목표는 잘못된 추측의 수를 줄이는 것입니다: 잘못된 기본 디렉터리, 잘못된 서비스, 잘못된 빌드 패키지, 잘못된 시작 명령어.<br><br>3. 포트는 자체적인 실패 유형이다<br><br>가장 짜증나는 배포 실패 중 하나는 앱이 실행되고 있지만 접근할 수 없는 경우입니다.<br><br>코드상에서는 종종 무해하게 보입니다:<br><br>const port = process.env.PORT || 5000<br><br>하지만 프로덕션 환경에는 여러 포트가 관련되어 있습니다:<br><br>- 앱이 실제로 바인딩되는 포트<br>- Docker 또는 Nixpacks에 의해 노출되는 포트<br>- 배포 설정에 저장된 포트<br>- 프록시가 라우팅하는 포트<br><br>만약 이들이 일치하지 않으면, 살아있는 것처럼 보이는 컨테이너와 502 오류를 반환하는 공개 URL을 얻을 수 있습니다.<br><br>따라서 VibeNest는 소스 힌트, Docker 메타데이터, 런타임 로그, PORT 사용 여부, 그리고 현재 Coolify 라우팅 구성을 비교합니다. 한 가지 실제 문제 유형에서는 ports_exposes를 변경하는 것만으로는 충분하지 않기 때문에 프록시 레이블이 오래되어 앱을 단순히 재배포하는 대신 다시 생성해야 합니다.<br><br>그것은 화려한 일은 아닙니다. 이것은

시스템은 "이 앱에는 BOT_TOKEN이 필요합니다" 또는 "이 앱에는 OPENAI_API_KEY가 필요합니다"라고 말할 수 있습니다. 시스템이 임의로 생성해서는 안 됩니다. 시스템은 동작을 멈추고 소유자에게 물어봐야 합니다.<br><br>그 경계는 중요합니다. 비밀값(secrets)을 임의로 만들어내는 배포 어시스턴트는 명확하게 실패하는 어시스턴트보다 더 나쁩니다.<br><br>5. 복구는 마법이 아니라 제한적입니다<br><br>배포가 실패했을 때, VibeNest는 단순히 영원히 재시도하지 않습니다.<br><br>복구 경로는 의도적으로 제한되어 있습니다:<br><br>- 증거가 확실할 때는 결정론적 수정(deterministic fixes)이 먼저 실행됩니다.<br>- LLM은 저장소 증거, 빌드 로그, 런타임 로그, 컨테이너 상태를 통해 알 수 없는 실패를 진단할 수 있습니다.<br>- 제안된 모든 수정 사항은 지원되는 작업 중 하나여야 합니다.<br>- 시스템은 커밋당 적은 양의 시도 예산(attempt budget)을 가집니다.<br>- 사용자가 트리거한 배포는 예산을 초기화하며, 모니터링 복구는 영원히 루프를 돌지 않습니다.<br><br>지원되는 수정 사항의 예시는 다음과 같습니다:<br><br>- 기본 디렉토리(base directory) 변경<br>- 빌드 팩(build pack) 변경<br>- Node/Python/.NET 버전 설정<br>- 내부 포트(internal port) 설정<br>- 플랫폼 환경 변수(env var) 설정<br>- Postgres 연결<br>- 브랜치(branch) 변경<br>- 정적 출력 디렉토리(static output directory) 설정<br><br>그리고 시스템이 조용히 수행해서는 안 되는 것들의 예시는 다음과 같습니다:<br><br>- 개인 비밀값(private secrets)을 임의로 생성하기<br>- 무작위 포트를 계속 시도하기<br>- 소유자 없이 파괴적인 변경을 수행하기<br>- 저장소가 비공개(private)이거나 Git LFS 할당량 초과 실패를 숨기기<br>- 메모리 부족(out-of-memory) 앱을 환경 변수 문제인 것처럼 가장하기<br><br>그 차별점이 바로 제품입니다.<br><br>6. 빌드 이후에는 런타임 신호가 중요합니다<br><br>빌드가 성공(green build)했다고 해서 앱이 건강한 상태인 것은 아닙니다.<br><br>VibeNest는 런타임 측면도 모니터링합니다: Coolify 리소스 상태, 재시작 루프, 런타임 로그, 퍼블릭 URL 프로브(probes), 빌드 로그 정체, OOM(out-of-memory) 신호, 그리고 반복되는 복구 플랩(recovery flaps).<br><br>이 지점에서 플랫폼은 다음의 차이점을 학습합니다:<br><br>- 빌드가 실패함<br>- 부팅 후 컨테이너가 충돌(crash)함<br>- 앱은 실행 중이지만 도달할 수 없음(unreachable)<br>- 라우트(route)가 오래됨(stale)<br>- 저장소를 클론(clone)할 수 없음<br>- 앱의 리소스가 부족하게 할당됨(under-provisioned)<br><br>서로 다른 실패에는 서로 다른 대응이 필요합니다. "배포를 다시 실행하세요"라는 조언은 이전의 실패가 일시적(transient)이었을 때만 유용합니다.<br><br>실제 목표

저는 "AI가 당신의 앱을 배포합니다"라는 약속이 적절한 약속이라고 생각하지 않습니다.

더 유용한 약속은 다음과 같이 더 작고 구체적입니다:

배포 가능한 상태에 가까운 GitHub 저장소(repo)를 가져와서, 지루한 인프라 경로(infrastructure path)를 실행하고, 일반적인 프로덕션 불일치(production mismatches)를 감지하며, 안전한 것들은 수정하고, 나머지 부분은 개발자가 다음 결정을 내릴 수 있을 만큼 충분히 명확하게 설명하는 것입니다.

그것이 바로 우리가 VibeNest로 만들고 있는 것입니다.

더 자세한 기술적 분석:

https://vibenest.net/blog/self-healing-deployment-platform

GitHub에서 앱을 배포할 때, 보통 무엇이 가장 먼저 문제를 일으키나요: 빌드 팩(build pack), 기본 디렉터리(base directory), 포트(port), 환경 변수(env vars), 데이터베이스 설정(database setup), 아니면 런타임 메모리(runtime memory)인가요?