기존 시스템을 안전하게 변경하기
완료기존 계약을 유지하면서 변경을 도입하세요. 이전 클라이언트, 데이터, 배포 순서를 고려하세요.
이해도 확인같은 릴리스에서 데이터베이스 열의 이름을 바꾸고 애플리케이션을 업데이트합니다. 그래도 어떤 문제가 발생할 수 있을까요?실습하기
학습할 내용
- 국소적인 코드 변경이 영향을 줄 수 있는 계약을 찾습니다.
- 단계적으로 확장한 뒤 기존 요소를 제거하는 변경 방식을 설명합니다.
- 코드 롤백과 데이터 복구를 구분합니다.
변경과 관련된 계약을 확인하세요
기존 소프트웨어에는 호출 주체, 저장된 데이터, 예약 작업, 운영 절차가 있습니다. 수정하려는 파일에서 보이지 않는 의존성도 있습니다. 에이전트가 해당 부분에서는 올바르지만 이런 계약 중 하나를 깨뜨리는 변경을 만들 수 있습니다.
구현 전에 영향받는 데이터를 읽거나 쓰는 구성 요소를 확인하세요. 경로, 백그라운드 작업, 보고서, 외부 연동을 살펴보세요. 다른 팀이나 이전 클라이언트 버전이 현재 동작에 의존하는지 확인하세요.
에이전트에게 이 의존 관계를 뒷받침하는 증거를 제시하도록 요청하세요. 검색 결과는 유용한 출발점이지만, 동적 호출과 외부 사용 시스템의 의존성은 담당자의 확인이 필요할 수 있습니다.
현재 동작을 관찰할 수 있게 하세요
문서가 부족한 모듈에는 유지해야 할 동작을 집중적으로 확인하는 검사를 추가하세요. 이 검사는 현재 계약을 설명합니다. 기존 동작이 모두 바람직하다는 것을 입증하지는 않습니다.
현재 동작이 요구사항과 충돌하면 그 충돌을 기록하세요. 테스트에 반영되어 있다는 이유만으로 보안 결함을 유지하지 마세요. 의도한 동작과 결함을 구분하는 데 필요한 결정을 받으세요.
민감한 정보가 없는 현실적인 테스트 데이터를 사용하세요. 이전 데이터 구조나 불완전한 레코드가 발생할 수 있다면 이를 포함하세요. 새로 생성한 데이터만으로 새 스키마를 테스트하면 마이그레이션 문제가 드러나지 않을 수 있습니다.
버전 사이의 전환을 검토하세요
customer_name을 display_name으로 바꾸는 가상의 예를 생각해 보세요. 즉시 이름을 바꾸면 배포 중에 이전 애플리케이션 인스턴스가 실패할 수 있습니다. 하나의 풀 리퀘스트에서 두 파일을 모두 바꿔도 배포가 원자적으로 이루어지는 것은 아닙니다.
단계적으로 진행하면 호환성을 유지할 수 있습니다.
- 기존 필드를 제거하지 않고 새 필드를 추가합니다.
- 새로 데이터를 쓸 때 필요한 값들의 일관성을 유지하는 방법을 정합니다.
- 다시 시작할 수 있는 프로세스로 기존 레코드의 새 필드를 채웁니다.
- 데이터가 빠짐없이 채워졌는지와 읽기 동작을 검증합니다.
- 데이터를 읽는 구성 요소가 새 필드를 사용하도록 전환합니다.
- 기존 필드를 사용하는 구성 요소가 없어졌을 때만 해당 필드를 제거합니다.
구체적인 방법은 데이터베이스와 쓰기 패턴에 따라 달라집니다. 두 곳에 쓰는 방식에서는 한쪽 쓰기가 실패하면 불일치가 생길 수 있습니다. 데이터베이스 트랜잭션이나 다른 명시적인 동기화 방법이 필요할 수 있습니다. 시스템이 보장하는 동작을 확인하지 않고 이 예를 적용하지 마세요.
Martin Fowler는 이런 일반적인 전환 방식을 parallel change 또는 expand-and-contract라고 설명합니다. 핵심은 기존 요소를 제거하기 전에 호환성을 유지하며 전환하는 것입니다.
롤백과 별도로 복구를 계획하세요
코드 롤백은 이전 애플리케이션 버전을 복원합니다. 데이터 마이그레이션까지 자동으로 되돌리지는 않습니다. 이전 버전은 새 데이터를 이해하지 못할 수 있습니다. 데이터를 삭제하는 마이그레이션은 코드 롤백으로 복구할 수 없는 정보를 제거할 수 있습니다.
각 단계의 복구 방법을 확인하세요. 다시 시작할 수 있는 데이터 채우기 작업은 안전하게 재개할 수 있을 것입니다. 잘못된 변환은 보존된 원본 데이터로 수정해야 할 수 있습니다. 데이터를 파괴하는 작업에는 검증된 복원 절차가 필요할 수 있습니다.
복구 결정을 누가 맡고 얼마나 걸릴 수 있는지 확인하세요. ‘백업이 있다’는 말만으로 복구가 서비스 요구사항을 충족한다고 판단하지 마세요.
검토할 수 있는 범위로 변경을 유지하세요
관련 없는 정리 작업은 기능 변경과 분리하세요. 풀 리퀘스트에 호환성 계획, 검증 결과, 제거 조건을 제공하세요. 어느 시점부터 롤백에 추가 작업이 필요한지 표시하세요.
에이전트는 데이터를 사용하는 구성 요소를 조사하고 마이그레이션 코드를 준비하는 데 도움을 줄 수 있습니다. 그래도 책임 있는 담당자가 전환 및 복구 계획을 수락해야 합니다. 최종 설계는 안전한 변경의 한 부분일 뿐입니다.
실습하기
작은 필드 변경이나 API 변경을 선택하세요. 백그라운드 작업을 포함해 데이터를 읽거나 쓰는 모든 구성 요소를 나열하세요. 기존 요소를 유지하면서 추가하는 첫 단계, 전환 검사, 제거 조건을 설명하세요. 어느 단계가 롤백을 막을 수 있는지 확인하세요.
워크시트 다운로드(Markdown)이 선택을 해제하면 이 브라우저에 저장된 모든 진도가 삭제됩니다.
진도는 이 브라우저에만 저장됩니다. 계정과 추적은 없습니다.