2025년 10월 27일·7분
데이터베이스가 대부분의 애플리케이션 코드보다 오래 가는 이유(그리고 왜 중요한가)
데이터베이스는 종종 수십 년 동안 유지되는 반면 앱은 재작성됩니다. 데이터가 오래가는 이유, 마이그레이션 비용, 안전하게 진화하는 스키마 설계 방법을 알아보세요.
데이터베이스는 종종 수십 년 동안 유지되는 반면 앱은 재작성됩니다. 데이터가 오래가는 이유, 마이그레이션 비용, 안전하게 진화하는 스키마 설계 방법을 알아보세요.
몇 년 동안 소프트웨어와 일해봤다면 같은 이야기가 반복되는 걸 보셨을 겁니다: 앱은 재설계되고, 재작성되고, 리브랜딩되거나 완전히 교체되지만 데이터베이스는 조용히 계속 운영됩니다.
회사는 데스크톱 앱에서 웹 앱으로, 그다음 모바일로, 이후 새 프레임워크로 만든 “v2”로 이동할 수 있습니다. 그럼에도 고객 기록, 주문, 청구서, 제품 카탈로그는 종종 같은 데이터베이스(또는 그 직계 후손)에 그대로 남아 있고, 때로는 10년 전에 만들어진 테이블도 남아 있습니다.
간단히 말하면: 애플리케이션 코드는 인터페이스와 동작이고 자주 바뀝니다. 데이터베이스는 기억이고, 비즈니스가 의존하는 역사를 담고 있기 때문에 바꾸기가 위험합니다.
비기술적 비유: 매장을 리모델링할 수는 있지만(새 선반, 새 계산대, 새 간판), 재고 기록과 영수증을 버릴 필요는 없습니다. 리모델링은 앱이고, 기록은 데이터베이스입니다.
이 패턴을 인지하면 의사결정 방식이 달라집니다:
다음 섹션에서는 데이터베이스가 오래 남는 이유, 데이터 이동이 코드보다 어려운 이유, 그리고 여러 번의 앱 재작성에도 데이터베이스가 안전하게 진화하도록 설계·운영하는 실무적 방법을 다룹니다.
애플리케이션은 제품처럼 느껴지지만, 제품이 무슨 일이 있었는지 기억하는 곳은 데이터베이스입니다.
쇼핑 앱은 다섯 번 다시 디자인될 수 있지만 고객들은 자신의 구매 이력이 남아 있기를 기대합니다. 지원 포털은 벤더를 바꿀 수 있지만 티켓, 환불, 약속 기록은 일관되게 유지되어야 합니다. 이러한 연속성은 고객, 주문, 청구서, 구독, 이벤트 그리고 그들 간의 관계에 저장된 데이터에 있습니다.
기능이 사라지면 사용자는 불만을 가지지만, 데이터가 사라지면 신뢰, 수익, 법적 근거를 잃을 수 있습니다.
앱은 종종 소스 컨트롤과 문서로 재구성할 수 있지만, 실제 세계의 역사는 재실행할 수 없습니다. 작년 결제를 ‘다시 실행’하거나, 고객이 특정 시점에 동의했음을 정확히 재구성하거나, 언제 무엇이 배송되었는지를 정확히 기억으로 복원할 수는 없습니다. 타임스탬프가 누락되거나 고아 레코드가 있거나 합계가 불일치하는 부분적 손실만으로도 제품 신뢰도가 떨어질 수 있습니다.
대부분의 데이터는 존재 기간이 길어질수록 더 유용해집니다:
이 때문에 팀은 데이터를 부산물이 아니라 자산으로 취급합니다. 새 앱 재작성은 더 나은 UI를 제공할 수 있지만 수년 간의 역사적 진실을 대체하진 못합니다.
시간이 지나면 조직은 데이터베이스를 공통의 기준점으로 표준화합니다: 데이터베이스에서 내보낸 스프레드시트, 그 위에 구축된 대시보드, 재무 프로세스의 대조, 정기적으로 사용되는 ‘정상’ 쿼리들.
이것이 데이터베이스 장수의 감정적 중심입니다: 애플리케이션이 계속 바뀌더라도 모두가 의존하는 기억이 데이터베이스가 되는 것입니다.
데이터베이스는 드물게 ‘한 애플리케이션만’ 소유됩니다. 시간이 지나며 여러 제품, 내부 도구, 팀의 공유 진실 소스가 되는 경향이 있습니다. 이런 공유 의존성이 데이터베이스가 앱 코드보다 오래 남는 큰 이유입니다.
한 세트의 테이블이 다음을 제공하는 경우가 흔합니다:
각 소비자는 다른 언어로 구축되고, 서로 다른 일정으로 배포되며, 다른 사람들이 유지보수할 수 있습니다. 애플리케이션을 재작성할 때 자체 코드는 빠르게 적응할 수 있지만, 여전히 모두가 의존하는 동일한 기록을 읽고 보존해야 합니다.
통합은 흔히 특정 데이터 모델(테이블 이름, 컬럼 의미, 참조 ID, 레코드가 무엇을 나타내는지에 대한 가정)에 ‘묶여’ 버립니다. 비록 통합이 기술적으로 API를 통해 이뤄지더라도, 그 API는 종종 하부의 데이터베이스 모델을 반영합니다.
그래서 데이터베이스 변경은 한 팀의 결정이 아닙니다. 스키마 변경은 내보내기, ETL 작업, 리포팅 쿼리, 그리고 메인 제품 저장소에조차 없는 다운스트림 시스템으로 파급될 수 있습니다.
버그가 있는 기능을 배포하면 롤백하면 됩니다. 공유 데이터베이스 계약을 깨뜨리면 청구, 대시보드, 리포팅이 동시에 중단될 수 있습니다. 위험은 의존자 수만큼 곱해집니다.
이것이 ‘임시’ 선택(컬럼 이름, enum 값, NULL의 기묘한 의미 등)이 끈질겨지는 이유이기도 합니다: 너무 많은 것들이 조용히 그것들에 의존하고 있습니다.
안전하게 관리하는 실질적인 전략이 궁금하면 /blog/schema-evolution-guide 를 참조하세요.
애플리케이션 코드는 조각별로 교체될 수 있습니다. UI를 교체하거나 서비스를 교체하거나 기능을 API 뒤에 숨기면서 새로 구축할 수 있습니다. 문제가 생기면 배포를 롤백하거나 트래픽을 이전 모듈로 돌리거나 옛 코드와 새 코드를 병행해서 실행할 수 있습니다.
데이터는 같은 유연성을 주지 않습니다. 데이터는 공유되고 상호 연결되어 있으며 보통 매 순간 정확해야 합니다—‘다음 배포 후에 대체로 맞춰지는’ 것으로는 충분치 않습니다.
코드를 리팩터링할 때는 지침을 바꾸는 것입니다. 데이터를 마이그레이션할 때는 비즈니스가 의존하는 것(고객 기록, 거래, 감사 추적, 제품 이력)을 바꾸는 것입니다.
새 서비스는 일부 사용자에게만 테스트할 수 있습니다. 데이터 마이그레이션은 모든 것을 건드립니다: 현재 사용자, 과거 사용자, 역사적 행, 고아 레코드, 몇 년 전 버그로 생성된 이상한 일회성 항목까지.
데이터 이동은 단순한 “내보내기와 가져오기”가 아닙니다. 보통 다음을 포함합니다:
각 단계는 검증을 필요로 하고, 대규모 데이터셋이고 오류의 결과가 크면 검증에는 시간이 많이 걸립니다.
코드 배포는 자주 가능하고 되돌리기 쉽습니다. 데이터 커버오버는 수술과 같습니다.
다운타임이 필요하면 비즈니스 운영, 지원, 고객 기대치를 조율해야 합니다. 무중단(near-zero downtime)을 목표로 한다면 이중 쓰기(dual-writes), 변경 데이터 캡처(CDC), 정교한 스테이지 복제 등을 사용하며, 새 시스템이 느리거나 잘못된 경우를 대비한 계획도 필요합니다.
롤백도 다릅니다. 코드 롤백은 쉽지만 데이터 롤백은 백업 복원, 변경 재생, 혹은 일부 쓰기가 ‘잘못된’ 장소에서 일어났음을 수용하고 조정해야 할 수 있습니다.
데이터베이스는 역사를 축적합니다: 이상한 행, 레거시 상태, 부분적으로 마이그레이션된 행, 아무도 기억하지 못하는 우회 처리 등이 생깁니다. 이 엣지 케이스는 개발 데이터셋에서는 잘 나타나지 않지만 실제 마이그레이션에서 즉시 드러납니다.
이 때문에 조직은 종종 코드 재작성(심지어 여러 번)을 선택하면서도 데이터베이스는 그대로 두는 것입니다. 데이터베이스는 단순한 의존성이 아니라 안전하게 바꾸기 가장 어려운 대상입니다.
애플리케이션 코드를 바꾸는 건 주로 새로운 동작을 배포하는 것입니다. 문제가 생기면 배포를 롤백하거나 기능 플래그로 관리하거나 빠르게 패치할 수 있습니다.
스키마 변경은 다릅니다: 이미 존재하는 데이터의 규칙을 재형성하며, 그 데이터는 수년치일 수 있고 불일치하며 여러 서비스와 리포트가 의존할 수 있습니다.
좋은 스키마는 거의 고정되지 않습니다. 도전 과제는 역사적 데이터를 유효하고 사용 가능하게 유지하면서 스키마를 진화시키는 것입니다. 데이터는 ‘재컴파일’될 수 없으므로 모든 오래된 행, 심지어 아무도 기억 못하는 엣지 케이스까지 다음 버전으로 가져가야 합니다.
이 때문에 스키마 진화는 기존 의미를 보존하고 이미 저장된 것을 강제 재작성하지 않는 방향을 선호합니다.
추가적 변경(새 테이블, 새 열, 새 인덱스)은 보통 이전 코드를 계속 작동시키면서 새 코드가 새로운 구조를 활용하게 합니다.
깨뜨리는 변경—컬럼 이름 변경, 타입 변경, 한 필드를 여러 개로 분리, 제약 강화—은 보통 다음 전반에 걸친 동기화가 필요합니다:
주된 앱을 업데이트하더라도 잊힌 리포트나 통합이 조용히 옛 형태에 의존할 수 있습니다.
“그냥 스키마를 바꾸자”는 말은 수백만 개의 기존 행을 온라인 상태로 유지하면서 마이그레이션해야 하는 상황에서 간단하게 들릴 뿐입니다. 고려할 점:
NOT NULL 컬럼의 값을 백필(backfill)하기ALTER 작업 중 길게 걸리는 락이나 타임아웃 피하기많은 경우 다단계 마이그레이션을 수행합니다: 새 필드 추가 → 이중 쓰기 → 백필 → 읽기 전환 → 나중에 옛 필드 제거.
코드 변경은 되돌릴 수 있고 격리 가능한 반면, 스키마 변경은 영구적이고 공유됩니다. 일단 마이그레이션이 실행되면 그것은 데이터베이스 역사에 포함되며 모든 향후 제품 버전은 그 결정을 받아들여야 합니다.
애플리케이션 프레임워크는 빠르게 순환합니다: 5년 전 ‘모던’하다고 느꼈던 것이 지금은 지원되지 않거나 채용이 어려운 기술이 될 수 있습니다. 데이터베이스도 변하지만 핵심 개념과 일상 기술은 훨씬 느리게 이동합니다.
SQL과 관계형 개념은 수십 년 동안 놀랄 만큼 안정적이었습니다: 테이블, 조인, 제약, 인덱스, 트랜잭션, 쿼리 플랜 등. 공급업체는 기능을 추가하지만 사고 모델은 익숙하게 유지됩니다. 이 안정성 덕분에 팀은 앱을 새로운 언어로 재작성하더라도 동일한 데이터 모델과 쿼리 접근 방식을 유지할 수 있습니다.
신규 데이터 제품조차 이러한 익숙한 쿼리 개념을 보존하는 경우가 많습니다. 리포팅, 문제 해결, 비즈니스 질문에 잘 맞기 때문입니다.
기본이 일관되기 때문에 주변 생태계도 세대를 건너 지속됩니다:
이 연속성은 ‘강제 재작성’을 줄입니다. 채용이 어려워져 앱 프레임워크를 버릴 수는 있어도, 데이터를 다루는 공통 언어로서 SQL을 버리긴 드뭅니다.
데이터베이스 표준과 관례는 공통 기준을 만듭니다: SQL 방언은 동일하지는 않지만 대부분의 웹 프레임워크보다 서로에 가깝습니다. 이 때문에 앱 레이어가 진화하는 동안 데이터베이스를 안정적으로 유지하기가 더 쉽습니다.
실무적 영향은 간단합니다: 팀이 앱 재작성을 계획할 때 기존의 데이터베이스 기술, 쿼리 패턴, 운영 관행을 그대로 유지할 수 있어 데이터베이스는 여러 세대의 코드를 초월하는 안정적인 기반이 됩니다.
대부분의 팀은 데이터베이스를 좋아해서 계속 사용하는 것이 아닙니다. 작동하는 운영 습관을 구축했기 때문에 계속 사용하는 것입니다—그 습관은 어렵게 얻은 것입니다.
데이터베이스가 프로덕션에 들어가면 회사의 ‘항상 켜져 있는’ 기계의 일부가 됩니다. 사람들은 새벽 2시에 페이지를 보내고, 감사가 묻고, 새로운 서비스는 결국 그 데이터베이스와 대화해야 합니다.
1~2년 후팀은 보통 다음과 같은 안정된 리듬을 갖습니다:
데이터베이스를 교체하면 실제 부하에서 그 모든 것을 다시 배워야 합니다.
데이터베이스는 거의 ‘설정 후 잊기’가 아닙니다. 시간이 지나며 팀은 신뢰성 지식을 축적합니다:
그 지식은 대시보드, 스크립트, 사람들의 머릿속에 존재합니다. 앱 코드를 재작성해도 동작을 보존할 수 있지만 데이터베이스를 교체하면 동작, 성능, 신뢰성을 동시에 재구축해야 합니다.
보안과 접근 제어는 중심적이고 장기간 유지됩니다. 역할, 권한, 감사 로그, 비밀 교체, 암호화 설정, 누가 무엇을 읽을 수 있는지는 규정 준수 요구와 내부 정책에 맞춰 정렬됩니다.
데이터베이스를 바꾸면 접근 모델을 다시 만들고, 제어를 재검증하며, 민감한 데이터가 여전히 보호된다는 것을 비즈니스에 다시 증명해야 합니다.
운영 성숙도는 위험을 낮춰 데이터베이스를 유지하게 합니다. 새 데이터베이스가 더 나은 기능을 약속하더라도, 오래된 데이터베이스는 ‘계속 가동되고 복구 가능하며 문제가 생겼을 때 이해 가능한’ 역사라는 강력한 자산을 가집니다.
애플리케이션 코드는 새로운 프레임워크나 더 깔끔한 아키텍처로 대체할 수 있습니다. 하지만 컴플라이언스 의무는 ‘무슨 일이 있었는지, 언제, 누가 승인했는지, 고객이 그 순간에 무엇을 보았는지’에 묶여 있습니다. 그래서 데이터베이스는 종종 재작성에서 움직일 수 없는 물체가 됩니다.
여러 산업에서는 인보이스, 동의 기록, 재무 이벤트, 지원 상호작용, 접근 로그에 대해 최소 보존 기간을 요구합니다. 감사자는 보통 “앱을 재작성해서 잃었다”는 이유를 받아들이지 않습니다.
팀이 더 이상 일상적으로 사용하지 않는 레거시 테이블이라도, 필요 시 그것을 제공하고 어떻게 생성되었는지 설명할 수 있어야 합니다.
차지백, 환불, 배송 분쟁, 계약 문제는 특정 시점의 스냅샷에 의존합니다: 당시의 가격, 사용된 주소, 수락된 약관, 특정 분의 상태 등.
데이터베이스가 그런 사실들의 권위 있는 원천이라면, 그것을 교체하는 것은 단순한 기술 프로젝트가 아니라 증거를 변경할 위험이 있습니다. 그래서 팀은 기존 데이터베이스를 유지하고 그 주위에 새 서비스를 쌓는 경우가 많습니다.
어떤 레코드는 삭제할 수 없고, 어떤 레코드는 추적 가능성을 해치는 방식으로 변환할 수 없습니다. 만약 정규화를 풀거나 필드를 병합하거나 컬럼을 삭제하면 감사 추적을 재구성할 능력을 잃을 수 있습니다.
이 긴장은 특히 개인정보 보호 요구가 보존 요구와 충돌할 때 명확합니다: 선택적 익명화나 가명화가 필요하면서도 거래 이력을 온전히 유지해야 하는 경우가 있습니다. 이러한 제약은 데이터에 가장 가깝게 존재합니다.
데이터 분류(PII, 재무, 건강, 내부 전용)와 거버넌스 정책은 제품이 진화해도 안정적으로 유지되는 경향이 있습니다. 접근 제어, 리포팅 정의, ‘단일 진실 소스’ 결정은 종종 BI 대시보드, 재무 내보내기, 규제 보고서, 사고 조사 등 여러 도구가 공유하기 때문에 데이터베이스 수준에서 시행됩니다.
재작성을 계획 중이라면 컴플라이언스 리포팅을 1순위 요구사항으로 다루세요: 필요한 보고서, 보존 일정, 감사 필드를 스키마에 손대기 전에 인벤토리화하세요. 간단한 체크리스트가 도움이 됩니다 (참조 /blog/database-migration-checklist).
대부분의 ‘임시’ 데이터베이스 결정은 부주의로 내려지지 않습니다—런칭 데드라인, 급한 고객 요청, 새로운 규제, 엉망인 가져오기 과정 같은 압박 속에서 내려집니다. 놀라운 점은 그 결정들이 얼마나 드물게 되돌려지느냐입니다.
애플리케이션 코드는 빠르게 리팩터링되지만 데이터베이스는 오래된 소비자와 새 소비자를 동시에 계속 제공해야 합니다. 레거시 테이블과 컬럼이 남는 이유:
심지어 필드를 ‘이름 변경’해도 종종 옛 필드를 유지하게 됩니다. 흔한 패턴은 새 열(예: customer_phone_e164)을 추가하고 phone을 무기한 유지하는 것입니다. 야간 내보내기가 여전히 phone을 사용하기 때문입니다.
우회책은 스프레드시트, 대시보드, CSV 내보내기에 박혀 들어가며—이것들은 거의 생산 코드처럼 다뤄지지 않습니다. 누군가가 ‘Finance가 마이그레이션할 때까지’ deprecated 테이블을 조인하는 수익 리포트를 만들고, 그러면 재무의 분기 프로세스가 그것에 의존하게 되어 해당 테이블을 제거하는 것이 비즈니스 위험이 됩니다.
이것이 폐기된 테이블이 몇 년 동안 생존하는 이유입니다: 데이터베이스는 단지 앱을 서비스하는 것이 아니라 조직의 습관을 서비스합니다.
임시 고정값으로 추가된 필드—promo_code_notes, legacy_status, manual_override_reason 같은—는 종종 워크플로우에서 결정 포인트가 됩니다. 사람들이 결과를 설명하기 위해 사용하기 시작하면(“우리는 이 주문을 ... 이유로 승인했다”) 더 이상 선택사항이 아닙니다.
팀이 마이그레이션을 신뢰하지 못하면 섀도우 복사본을 유지합니다: 중복된 고객 이름, 캐시된 합계, 폴백 플래그 등. 이러한 추가 컬럼은 무해해 보이지만 경쟁하는 진실 소스를 만들고 새로운 의존성을 생성합니다.
이 함정을 피하려면 스키마 변경을 제품 변경처럼 다루세요: 의도 문서화, 사용처 표시, 제거 전 소비자 추적. 실용적 체크리스트는 /blog/schema-evolution-checklist 를 참조하세요.
여러 세대의 앱을 견디는 데이터베이스는 내부 구현 세부사항이 아니라 공유 인프라로 취급되어야 합니다. 목표는 모든 미래 기능을 예측하는 것이 아니라 변경을 안전하고 점진적이며 되돌릴 수 있게 만드는 것입니다.
애플리케이션 코드는 재작성될 수 있지만 데이터 계약은 재협상하기 어렵습니다. 테이블, 컬럼, 키 관계를 미래의 시스템과 팀이 의존할 API로 생각하세요.
**추가적 변경(additive change)**을 선호하세요:
미래의 재작성 실패는 데이터가 없어서가 아니라 모호해서 발생하는 경우가 많습니다.
의도를 설명하는 명확하고 일관된 이름을 사용하세요(예: billing_address_id vs addr2). 가능한 곳에는 제약(PK, FK, NOT NULL, 유니크, 체크)을 통해 규칙을 인코딩하세요.
테이블/컬럼 주석이나 내부 핸드북의 짧은 실무 문서처럼 스키마 근처에 가벼운 문서를 추가하세요. ‘왜’가 ‘무엇’만큼 중요합니다.
모든 변경은 앞으로 나아갈 경로와 되돌릴 경로를 가져야 합니다.
자주 발생하는 애플리케이션 반복 동안 데이터베이스 변경을 더 안전하게 유지하는 한 가지 실용적 방법은 배포 워크플로에 ‘계획 모드’와 롤백 규율을 내재화하는 것입니다. 예를 들어 팀이 내부 도구나 새 앱 버전을 Koder.ai에서 구축할 때, 스키마를 안정적 계약으로 취급하고 스냅샷과 롤백 스타일 관행을 사용해 우발적 변경의 영향 범위를 줄일 수 있습니다.
스키마를 안정적 계약과 안전한 진화로 설계하면 애플리케이션 재작성은 일상적인 이벤트가 되고, 위험한 데이터 구조 구출 작업이 되지 않습니다.
데이터베이스 교체는 드물지만 불가능하지 않습니다. 그것을 성공적으로 해내는 팀은 ‘더 용감한’ 것이 아니라, 수년 전부터 데이터를 이식 가능하게 만들고, 의존성을 가시화하며, 애플리케이션을 특정 엔진에 덜 결속되게 준비해 왔습니다.
내보내기를 일회성 스크립트가 아니라 1급 기능으로 취급하세요.
결합이 강할수록 마이그레이션은 재작성으로 변합니다.
균형 잡힌 접근 권장:
새 서비스를 빠르게 구축할 때(예: React 관리자 앱 + Go 백엔드 + PostgreSQL) 이식성과 운영 명확성을 기본으로 하는 스택을 선택하면 도움이 됩니다. Koder.ai는 널리 채택된 원칙에 의존하고 소스 코드 내보내기를 지원하여 애플리케이션 레이어가 일회성 도구에 잠기지 않게 합니다.
데이터베이스는 종종 핵심 앱 이상의 것을 구동합니다: 리포트, 스프레드시트, 예약 ETL 작업, 제3자 통합, 감사 파이프라인 등.
다음 정보를 담은 실무 문서를 유지하세요: 무엇이 읽고 쓰는지, 빈도, 깨지면 어떤 일이 발생하는지. /docs의 간단한 페이지에도 소유자와 연락처를 적어두면 놀라운 문제를 예방합니다.
공통 신호: 라이선스 또는 호스팅 제약, 고칠 수 없는 신뢰성 문제, 필요한 컴플라이언스 기능 부족, 극단적 우회가 필요한 확장 한계.
주요 위험: 데이터 손실, 의미의 미묘한 변화, 다운타임, 리포팅 편차.
더 안전한 접근법은 일반적으로 병렬 운영(parallel run) 입니다: 데이터를 지속적으로 마이그레이션하고 결과(건수, 체크섬, 비즈니스 메트릭)를 검증하며 트래픽을 점진적으로 이동하고, 신뢰도가 높아질 때까지 롤백 경로를 유지하세요.
데이터베이스는 비즈니스의 역사적 진실(고객, 주문, 청구서, 감사 기록 등)을 보관하기 때문입니다. 코드의 경우 재배포나 재작성으로 복구할 수 있지만, 잃어버린 또는 손상된 기록은 재구성하기 어렵고 재무적·법적·신뢰의 문제를 초래할 수 있습니다.
데이터 변경은 공유되고 영구적입니다.
하나의 데이터베이스는 종종 다음과 같은 여러 소비자를 위한 단일 진실 소스가 됩니다:
앱을 재작성하더라도 이 모든 소비자들은 안정적인 테이블, ID, 의미를 계속 필요로 합니다.
대부분의 경우 그렇지 않습니다. 실제로 많은 “마이그레이션”은 데이터 계약을 안정적으로 유지하면서 애플리케이션 구성 요소를 변경하도록 단계적으로 진행됩니다.
일반적인 접근 방식:
대부분 팀은 추가적(additive) 변경을 목표로 합니다:
이렇게 하면 이전 코드와 새 코드가 나란히 동작하며 전환할 수 있습니다.
모호함은 코드보다 오래갑니다.
실용적 조치:
billing_address_id).NOT NULL, 유니크, 체크 등).예상치 못한 ‘이상한’ 행에 대비하세요.
마이그레이션 전에 다음을 계획하세요:
프로덕션에 가까운 데이터로 마이그레이션을 테스트하고, 단순 변환 로직뿐 아니라 검증 단계를 포함하세요.
컴플라이언스 의무는 UI가 아니라 기록에 붙습니다.
다음과 같은 것을 보관·재현해야 할 수 있습니다:
필드를 재구성하거나 삭제하면 추적 가능성, 리포팅 정의, 감사 가능성이 깨질 수 있어 앱이 옮겨갔더라도 그대로 유지해야 합니다.
호환성은 숨은 의존성을 만듭니다:
사용 중단(deprecation)은 제품 변경처럼 취급하세요: 의도 문서화, 소비자 추적, 폐기 계획 수립.
실용적 체크리스트:
이렇게 하면 재작성(rewrite)이 위험한 ‘데이터 구조 작업’이 아니라 일상적 활동이 됩니다.