> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Publish가 프로덕션 데이터베이스를 업데이트하는 방법

> 앱을 게시할 때 Replit이 개발 데이터베이스의 스키마 변경 사항을 프로덕션과 비교, 검증, 적용하는 방법을 알아보세요.

Replit이 관리하는 데이터베이스를 사용하는 앱을 게시하면, Replit이 프로덕션 데이터베이스를 개발 데이터베이스와 일치하도록 대신 업데이트합니다. 마이그레이션을 직접 작성하거나 실행할 필요가 없습니다. 게시하는 동안 Replit은 다음을 수행합니다.

1. 개발 데이터베이스와 프로덕션 데이터베이스의 스키마를 비교합니다.
2. 프로덕션을 개발과 일치시키는 데 필요한 SQL을 생성합니다.
3. 열 이름 변경처럼 모호한 부분을 해결하도록 요청합니다.
4. 프로덕션 데이터베이스의 복사본에 대해 SQL을 검증합니다.
5. 앱 빌드가 끝난 후, 새 버전이 라이브로 전환되기 전에 프로덕션에 SQL을 적용합니다.

> [!NOTE]
>
> 이는 Replit이 앱을 위해 관리하는 데이터베이스에만 적용됩니다. 게시된 앱이 Supabase, 직접 만든 Neon 프로젝트, Amazon RDS 같은 외부 데이터베이스에 연결되어 있다면 Publish는 해당 데이터베이스를 변경하지 않습니다. 대신 해당 제공업체의 마이그레이션 워크플로를 사용하세요.

## 1단계: Replit이 변경 사항 감지

게시는 **Provision** 단계로 시작합니다. 개발 스키마가 프로덕션과 다르면 Publish 창에 **Development database changes detected**가 표시되고 마이그레이션 생성이 시작됩니다.

![Development database changes detected가 표시된 Publish 창](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/changes-detected.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=9213aa45a2b15109f3cffc451fb7efdf)

게시할 때는 테이블, 열, 인덱스, 제약 조건, 뷰, enum, 시퀀스, 행 수준 보안 정책이 마이그레이션됩니다. 일부 객체는 이전되지 않습니다. [지원되지 않는 데이터베이스 객체](https://docs.replit.com/ko/help/troubleshooting/databases.md#unsupported-database-objects)를 참고하세요.

## 2단계: 모호한 변경 사항에 대한 질문에 답하기

일부 스키마 변경은 두 가지 다른 의미일 수 있습니다. Replit이 의도를 판단할 수 없으면 **Detected potential conflicts, please review**라는 메시지와 함께 일시 중지하고 선택을 요청합니다. 옵션을 선택하고 **Submit**을 선택하세요.

### 이름 변경인가요, 새로 만든 건가요?

같은 테이블에서 열 하나가 제거되고 다른 열이 추가되면, Replit은 기존 열의 이름이 변경된 것인지 묻습니다.

* **Yes, rename column**은 기존 데이터를 새 이름으로 유지합니다.
* **No, create new column**은 빈 열을 추가하고 기존 열을 데이터와 함께 삭제합니다.

![제거된 열을 새로 추가된 열로 이름 변경해야 하는지 묻는 프롬프트](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/rename-column-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=fe35615b66e1cc80a57b0198926d5406)

테이블, enum, 시퀀스, 뷰, 스키마에서도 같은 질문이 나타납니다.

![제거된 테이블을 새로 추가된 테이블로 이름 변경해야 하는지 묻는 프롬프트](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/rename-table-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=f3bfb9ba5604a051e845ae3617e42270)

> [!WARNING]
>
> 실제로는 이름 변경이었던 항목에 **create new**를 선택하는 것이 게시 중에 프로덕션 데이터를 잃는 가장 흔한 원인입니다. 확실하지 않다면 게시를 취소하고 Agent에게 무엇이 변경되었는지 물어보세요.

### 데이터가 있는 테이블의 고유 제약 조건

프로덕션에 이미 행이 있는 테이블에 고유 제약 조건을 추가하면, Replit이 제약 조건이 확인할 행의 수를 알려줍니다.

* **Add the constraint as-is**는 기존 행 중 하나라도 제약 조건을 위반하면 마이그레이션이 실패합니다. 그 후 데이터를 수정하고 다시 게시할 수 있습니다.
* **Remove all rows, then add the constraint**는 먼저 테이블을 비웁니다. 다른 테이블이 외래 키로 이 테이블을 참조하는 경우에는 이 옵션이 제공되지 않습니다.

![이미 행이 있는 테이블에 고유 제약 조건을 추가하는 방법을 묻는 프롬프트](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/unique-constraint-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=0a399148516559f9f2711cc335254df2)

## 3단계: 생성된 SQL 검토

모든 질문에 답하고 나면, 창에 Replit이 실행할 정확한 SQL과 함께 **Generated migrations to apply to production database**가 표시됩니다. 계속하기 전에 읽어보세요.

![Publish 창에 표시된 생성된 마이그레이션 SQL](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/generated-migrations.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=d8737c76546c059cdfcf0adead1e9e29)

다음 두 가지 신호는 마이그레이션에 추가적인 주의가 필요함을 알려줍니다.

* **데이터 손실 경고.** 프로덕션에 행이 있는 테이블에서 데이터를 제거할 수 있는 변경이 있으면 창이 주황색으로 바뀌고, 영향을 받는 각 테이블이 행 수와 함께 나열됩니다. 다음과 같은 변경이 이를 발생시킵니다.
  * 열 또는 테이블 제거 또는 재생성
  * 열의 타입 또는 값 필수 여부 변경
  * 필수 열 추가
  * 인덱스 및 제약 조건 추가 또는 재생성
* **다운타임 알림.** 변경 사항이 현재 실행 중인 앱 버전과 호환되지 않으면, 변경 도중 사용자가 데이터베이스에 쓰지 못하도록 Replit이 마이그레이션을 적용하기 전에 실행 중인 앱을 중지합니다. 자세한 내용은 \*\*What's happening?\*\*을 펼쳐 확인하세요.

![영향을 받는 테이블과 다운타임 알림을 나열하는 주황색 데이터 손실 경고가 표시된 마이그레이션](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/data-loss-warning.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=fc53902e5f2c4db51429cfc04f0e2746)

> [!NOTE]
>
> 경고 목록에는 프로덕션에 행이 있는 테이블만 포함됩니다. 빈 테이블에 대한 `DROP TABLE`은 경고를 표시하지 않으므로, 창이 주황색이 아니더라도 SQL을 읽어보세요.

## 4단계: Replit이 마이그레이션 검증

Replit은 프로덕션 데이터베이스의 임시 복사본을 만들고 그 위에서 SQL을 실행합니다. 창에는 \*\*Validating database migrations...\*\*가 표시된 후 **Database migrations validated successfully**가 표시됩니다.

![데이터베이스 마이그레이션이 성공적으로 검증되었음을 보여주는 Publish 창](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/validated.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=7127c8d7f2e63d87be279b5a0fff4e69)

복사본에서 SQL이 실패하면 창에 데이터베이스 오류와 함께 **Migrations failed validation, please review**가 표시되며 세 가지 해결 방법이 제공됩니다.

| 옵션 | 동작 |
| - | - |
| **Ask Agent to investigate and fix the development schema** | Agent가 실패한 SQL과 오류를 읽고, 개발 스키마를 프로덕션의 읽기 전용 보기와 비교하여 개발 쪽을 수정합니다. 프로덕션은 변경되지 않습니다. 완료되면 다시 게시하세요. |
| **Cancel deployment and retry once your schema conflicts are resolved** | 게시를 중단합니다. 프로덕션에는 아무 변경도 없습니다. |
| **Copy your development database schema & data to production** | 프로덕션 스키마 **및 데이터**를 개발 데이터로 교체합니다. [데이터 복구](https://docs.replit.com/ko/features/data-and-storage/data-recovery.md)로만 되돌릴 수 있습니다. 보존할 만한 프로덕션 데이터가 없는 앱에만 사용하세요. |

![세 가지 해결 옵션과 함께 마이그레이션 검증 실패를 보여주는 Publish 창](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/validation-failed.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=0ece6685e16081c9d3525121441ee5a0)

> [!NOTE]
>
> [Databricks Lakebase](https://docs.replit.com/ko/connectors/warehouses/databricks.md) 데이터베이스를 사용하는 앱은 이 검증 단계를 건너뜁니다. 창에서 승인하기 전에 생성된 SQL을 직접 검토하도록 안내합니다.

![Lakebase에서는 프리뷰 검증을 사용할 수 없다는 안내가 표시된 Publish 창](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/lakebase-skipped.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=b6ad241f4884be8f6d085d53511e7beb)

## 5단계(선택 사항): 마이그레이션된 복사본에서 앱 미리 보기

검증이 성공하면 **Create preview deploy**를 선택하여 마이그레이션된 프로덕션 복사본을 대상으로 앱을 빌드할 수 있습니다. 빌드가 끝나면 **View preview**를 선택하여 엽니다.

![프리뷰 배포를 빌드하는 중인 Publish 창](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/preview-building.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=18d331eba4d12dd001b6084d20481bac)

![View preview 및 Approve and publish 버튼이 있는 Publish 창](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/preview-ready.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=1ed89987ab33ff747694a9460681cc4a)

프리뷰를 사용하여 스키마 변경이 영향을 주는 앱의 부분을 직접 클릭해 보세요. 프리뷰는 복사된 데이터를 사용하므로 그곳에서 하는 어떤 작업도 프로덕션에 영향을 주지 않습니다. 프리뷰는 생성 후 **2시간** 뒤에 만료됩니다. 더 많은 시간이 필요하면 새로 만드세요.

## 6단계: 승인 및 게시

계속하려면 **Approve and publish**를 선택하세요. Replit은 검토한 정확한 SQL을 게시 요청과 함께 전송하므로, 여러분이 본 내용이 그대로 실행됩니다.

그런 다음 게시는 나머지 단계를 거쳐 진행됩니다. 마이그레이션은 **앱 빌드가 끝난 후 새 버전이 승격되기 전에** 실행됩니다.

1. 보안 검사
2. 빌드
3. 프로덕션에 데이터베이스 마이그레이션 적용
4. 새 버전 번들링 및 승격

Replit이 이 시점에 마이그레이션을 적용하므로, 앱의 빌드 명령이나 시작 코드는 데이터베이스 스키마를 절대 변경해서는 안 됩니다. 배포 빌드 명령이나 서버의 진입점에 `drizzle-kit push`, `db:push`, `CREATE TABLE IF NOT EXISTS` 문을 추가하지 마세요. 이들은 위의 검토와 검증 과정 밖에서 게시할 때마다 실행됩니다.

> [!WARNING]
>
> 승인하면 Publish 창에서 마이그레이션을 철회할 수 없습니다. 게시 후 스키마 변경을 되돌려야 한다면, 개발 환경에서 반대 변경을 수행하고 다시 게시하거나 [데이터 복구](https://docs.replit.com/ko/features/data-and-storage/data-recovery.md)를 사용하세요.

Publish 창을 사용하는 대신 Agent에게 다시 게시하도록 요청했는데 개발 스키마와 프로덕션 스키마가 다르면, 다시 게시가 차단되고 마이그레이션을 검토하도록 Publish 창으로 안내됩니다.

## 프로덕션을 수동으로 변경하기

일회성 수정의 경우 Database 창에서 프로덕션에 직접 SQL을 실행할 수 있습니다. 데이터베이스 전환기에서 **Production**을 선택한 다음 SQL 콘솔을 사용하세요. [데이터로 작업하기](https://docs.replit.com/ko/features/data-and-storage/work-with-your-data.md#run-sql-commands)를 참고하세요.

Replit은 스키마 파일이 아니라 항상 실제 데이터베이스를 비교하므로, 수동 변경은 다음 게시의 비교에 포함됩니다. 개발 환경에는 없는 열을 프로덕션에 직접 추가하면, 다음 게시에서 해당 열을 삭제하도록 제안합니다.

## 다음 단계

* [개발 및 프로덕션 데이터베이스](https://docs.replit.com/ko/features/data-and-storage/development-and-production.md): 두 데이터베이스가 어떻게 다른지 이해합니다.
* [데이터 복구](https://docs.replit.com/ko/features/data-and-storage/data-recovery.md): 개발 또는 프로덕션 데이터를 복원합니다.
* [지원되지 않는 데이터베이스 객체](https://docs.replit.com/ko/help/troubleshooting/databases.md#unsupported-database-objects): Publish가 마이그레이션할 수 없는 객체입니다.