아키텍처 변경·진화·마이그레이션

1. 프로그램을 되돌렸는데 거래 하나가 사라졌다

저장 구현을 바꾸기 전 백업에는 A=100, B=200이라는 두 기록이 있었다. 새 구현을 켠 뒤 C=50이라는 정상 기록을 받아들였다. 문제가 생겼다고 옛 프로그램과 옛 백업을 함께 복원하면 A와 B는 돌아오지만 C는 어디로 갈까?

코드 판본을 바꾸는 행위와 사용자가 이미 만든 정상 상태를 보존하는 일은 다르다. 아키텍처 변경은 새 구조를 고르는 데서 끝나지 않고, 현재 상태를 어떤 경계에서 넘기며 실패하면 무엇을 보존하고 어디로 돌아갈지까지 관리하는 일이다. 이 절은 앞의 공방 취소 서비스에서 저장 어댑터를 바꾸는 가상 변경을 이어 다룬다. 실제 시스템을 전환하거나 승인한 기록은 아니다.

구조와 계약은 그대로 비교 기준이 된다

아키텍처 드라이버·뷰·스타일·문서화에서 APP-1 안의 다섯 모듈과 I-CANCEL-v1·I-STORE-v1의 책임을 정했다. 모듈 관계·실행 경로·배치 뷰는 서로 다른 질문을 같은 구조에 대해 설명했다. 변경에서는 그중 무엇을 바꾸고 무엇을 유지하는지 먼저 적는다.

미확인 위험은 승인으로 바뀌지 않는다

아키텍처 평가와 트레이드오프에서 중요한 시나리오를 구조에 대입하고 근거가 부족한 판단은 미확인으로 남겼다. 필수 조건 위반은 높은 점수로 상쇄하지 않았고 결과 보관·재요청 기간은 아직 미정이었다. 변경 제안도 그 미정을 임의의 숫자로 채워 완료 처리하지 않는다.

구현 적합성 검사는 범위를 가진다

아키텍처 이행·적합성·기술부채에서 의도한 모듈과 관찰한 의존을 비교하고 누락된 검사 자료는 통과가 아니라 판정 부족으로 구분했다. 정적 의존 규칙과 저장·응답·재요청의 실행 증거는 다른 검사였다. 이번에는 그 편차를 변경 제안·영향 분석·전환·종료 결정으로 연결한다.

배포와 되돌림의 기법을 다시 정의하지 않는다

DevOps·CI/CD·가치흐름에서 개발과 운영이 변경의 검증·전달·운영 피드백을 함께 책임지는 DevOps를 배웠다. 카나리·블루그린·롤백과 롤포워드는 적용 조건이 달랐으며 코드 복귀만으로 새 데이터의 문제가 사라지지는 않았다. 여기서는 그 기법을 구조 변경의 영향·승인·데이터 보존 조건에 적용한다.

바뀌는 부분과 유지하는 약속을 나눈다

공방은 요청을 받는 창구와 업무 규칙을 유지하면서 저장 기능의 내부 구현을 바꾸려 한다. 창구에서 보이는 결과는 이전과 같아야 하지만, 내부 표현과 운영 절차는 달라질 수 있다. 새 구현이 잘 작동해도 이전 정상 거래를 잃거나 응답의 뜻을 바꾸면 성공한 변경이 아니다.

작은 오류 수정도 중요 구조·계약·품질 조건에 영향을 준다면 아키텍처 차원의 판단이 필요할 수 있다. 반대로 코드 한 줄을 바꿨다는 이유만으로 모든 변경에 똑같은 대규모 심의를 붙일 필요도 없다. 먼저 영향과 위험에 비례하는 확인·책임·승인 경계를 정한다.

정의: 제안부터 전환 결과의 확인까지

아키텍처 변경관리는 기존 구조·계약·운영 상태에 대한 변경을 식별하고 영향을 분석하여 승인 또는 보류한 뒤, 전환·검증·기록·후속 조치로 의도한 구조와 품질 조건을 유지하는 과정이다.

이행 절이 설계 의도와 실제 구현의 차이를 확인했다면, 여기서는 그 차이나 새로운 요구를 어떤 변경으로 처리할지 결정한다. 한 번의 변경이 끝나도 운영 결과와 요구가 달라지면 다시 평가하므로 구조는 확인 가능한 변경의 연속으로 진화한다.

승인 권한, 기록 보관과 보안 영향의 구체적 요구는 조직·시스템에 맞춰 정한다. NIST의 변경 통제·영향 분석 항목은 기술 검토 질문의 참고이며 이 공방이나 모든 국내 시스템에 같은 법적 의무가 적용된다는 뜻이 아니다. [CH-S1]

CH-AS-1의 저장 어댑터 변경을 구체화한다

앞 절의 CH-AS-1은 저장 어댑터의 구현 기술을 바꾸되 업무 규칙과 외부 계약을 유지하는 상황이었다. 이 절에서는 추가 가정 CH-M1로 “업무·운영 책임자가 합의한 짧은 쓰기 중단 구간을 둘 수 있는 교육용 대상”을 둔다. 중단 허용 자체도 실제 전환 전에 확인할 승인 사항이지 여기서 이미 승인되었다는 뜻은 아니다.

APP-1과 M-ENTRY·M-USECASE·M-RESERVATION·M-STORE-PORT·M-STORAGE를 유지하고 M-STORAGE의 구현과 필요한 저장 구성을 바꾼다. 이를 다섯 서비스로 분리하는 것으로 해석하지 않는다. 취소 확정·거절·결과 미확인의 구분, 같은 요청 식별자의 결과 확인, 소유권과 업무 규칙은 계속 적용한다.

환불 자동 실행, 자리 반환 시점, 요청 결과 보관기간은 새로 확정하지 않는다. 이 중 전환 안전성에 필요한 미정 조건이 해결되지 않으면 실제 쓰기 재개를 승인하지 않는다. 아래 금액 표는 데이터 대조를 위한 별도 단순 자료이지 공방의 환불 정책이 아니다.

2. 변경의 필요성과 영향을 문서로 고정한다

제안 CH-01에는 현재 문제, 목표, 바꾸는 요소, 바꾸지 않는 계약, 대안과 평가 근거를 적는다. “새 제품이 좋다”는 설명 대신 현재 저장 구현의 구체적 제약과 필요한 결과를 기술한다. 실제 제약이나 이득을 측정하지 않았다면 확인할 가정으로 남긴다.

요청자, 구조·코드 담당, 업무 책임자, 운영 책임자가 제공할 근거와 결정 권한을 구분한다. 담당자가 세 명인 가정에서도 검토 질문과 승인 책임이 사라지는 것은 아니다. 같은 사람이 여러 역할을 맡는 경우에도 무엇을 자기 판단으로 승인했는지 기록한다.

변경 통제는 승인된 변경을 실행하고 결과와 기록을 검토하는 과정까지 포함한다. 단순 티켓 생성이나 회의 참석을 완료 증거로 삼지 않는다. [CH-S1]

영향 분석은 직접 바꾸지 않는 곳까지 따라간다

변경 영향 분석은 제안된 변경이 요구·계약·구현·데이터·운영·보호 조건에 미칠 영향을 관련 경로와 근거를 따라 확인하는 활동이다. 저장 코드만 바꾸더라도 시간초과, 요청 결과 조회, 권한, 데이터 해석, 배포 설정에 영향이 생길 수 있다. 변경 전에 예상하고 변경 후 필요한 조건이 유지되는지 확인한다. [CH-S1]

어떤 요소가 변경에 무관하다고 판단했다면 이유도 남긴다. 확인하지 않은 주변 시스템을 “영향 없음”으로 채우는 것은 분석이 아니다.

비교할 판본은 코드 하나보다 넓다

변경 전후의 묶음에는 코드·빌드 산출물뿐 아니라 설정, 스키마·변환 규칙, 계약·뷰, 운영 절차와 확인한 시험 결과가 포함된다. 무엇을 승인했는지 식별할 수 있어야 시험한 대상과 배포한 대상이 다른 문제를 피할 수 있다. [CH-S2]

예컨대 구현 코드는 같아도 저장 연결 대상이나 권한 설정이 바뀌면 실행 결과가 달라질 수 있다. 따라서 “같은 커밋”만으로 같은 실행 상태라고 판단하지 않는다. 자료의 유효 범위와 관찰 환경도 함께 남긴다.

변경 전 기준을 남긴다는 것은 옛 프로그램 경로를 영구히 유지한다는 뜻이 아니다. 이력·증거는 보존하되 승인된 종료 시점에는 사용하지 않는 실행 경로와 설정을 제거한다. 기록 보존과 운영 경로 유지의 책임을 구별한다.

승인·보류·거절의 근거를 다르게 남긴다

필수 계약과 보호 조건을 위반하는 안은 다른 이득으로 상쇄하지 않는다. 영향 범위나 복구 조건이 미확인이면 승인으로 간주하지 않고 보류하며 필요한 자료와 담당자를 지정한다. 목표와 비용을 비교해 현재 변경이 필요 없다고 판단할 수도 있다.

CH-01에서는 업무상 중단 허용, 모든 쓰기 주체의 통제, 식별자별 데이터 대조, 요청 결과 기록의 처리, 실패 시 대응과 관찰 계획을 실제 적용 전 확인한다. 결과 보관기간을 아직 합의하지 않았다면 재요청 안전성에 대한 승인도 열린 상태다.

승인은 특정 판본·범위·환경에 대한 결정이다. 이후 목표나 데이터 변환 규칙이 바뀌면 기존 승인을 재사용할 수 있는지 영향을 재평가한다. 변경 전·후 보안 영향을 확인한다는 참고 절차와 모든 위험이 사라졌다는 보증은 다르다. [CH-S1]

제안과 전환을 하나의 추적으로 묶는다

전환 도중 자료가 부족해졌다면 정한 중단 조건으로 돌아간다. 이미 시작했다는 이유로 성공 칸을 채우지 않는다. 성공한 경우에도 이전 경로의 정리와 운영 책임 인계가 남았는지 확인한다.

3. 교체 방식과 상태 전환 방식을 구분한다

카나리는 노출과 관찰의 기법이지 두 데이터 저장소를 저절로 동기화하는 방법이 아니다. 블루그린의 두 애플리케이션이 같은 저장소를 쓰면 저장소의 잘못된 상태는 양쪽에 영향을 줄 수 있다. 실제 상태 공유와 고장 범위를 확인한다. [CH-S2][CH-S3]

CH-M1에서는 승인된 쓰기 중단을 이용하는 단순 경로를 분석한다. 무중단이 필수인 다른 대상에는 동기화·충돌·최신성·전환 기준점의 별도 설계와 검증이 필요하다. 쓰기 중단이 허용되지 않는데 같은 절차를 이름만 바꿔 적용하지 않는다.

기능을 조금씩 대체할 때도 끝이 있어야 한다

스트랭글러 피그(strangler fig) 방식은 기존 시스템의 기능을 점진적으로 새 구현으로 대체하면서 요청을 해당 구현으로 보내고, 대체가 끝난 기존 부분을 제거하는 전환 방식이다. [CH-S4]

먼저 다른 기능과의 경계를 식별할 수 있는 책임을 고르고 새 구현을 검증한다. 어떤 요청이 새 구현을 사용할지 명확히 분기하고, 공통 데이터·의존 관계 때문에 여전히 옛 구현이 필요한지 확인한다. 기능의 소유권이 불명확하면 두 곳에서 서로 다른 처리를 수행할 위험이 있다.

요청을 분기하는 구성 자체도 복잡도와 장애 지점이 될 수 있다. 더 작은 단일 변경이 적합한데 이 방식을 무조건 넣을 이유는 없다. 목표는 두 구현의 영구 공존이 아니라 위험을 관리하며 대체를 끝내는 것이며 종료 조건·소비자 전환·불필요한 경로 제거를 처음부터 계획한다.

데이터 마이그레이션은 의미와 기준 시점을 옮긴다

데이터 마이그레이션은 원래 데이터를 목표 저장 구조나 표현으로 옮기면서 식별·내용·관계와 필요한 상태의 의미를 정한 규칙에 따라 보존·변환하고 검증하는 작업이다. 파일이 복사되었다는 사실만으로 완료되지 않는다. 금액 단위, 시간대, 빈 값의 의미와 관계를 잘못 바꾸면 바이트가 정상이어도 업무 결과가 달라진다.

CH-01에서는 예약 상태뿐 아니라 이미 처리한 요청의 식별자·내용·결과 연결도 전환 영향에 포함한다. 무엇을 옮기고 무엇을 옮기지 않을지 명시하며, 미정인 보관·재요청 조건을 숫자로 발명해 제외하지 않는다.

아래 절차는 쓰기를 안전하게 멈춘 가상 범위의 대조다. 실제 제품의 온라인 마이그레이션이나 손실 없는 자동 복구를 실행했다는 뜻이 아니다. 상태를 바꾸는 변경의 복귀가 복잡할 수 있다는 원리를 이 사례에 적용한다. [CH-S2]

쓰기 중단이라는 전제부터 증명한다

전환 기준 시점 t0를 정하고, 요청 창구뿐 아니라 배치·재시도 작업·관리 기능 등 쓰기 주체를 목록으로 만든다. 새 요청만 막아도 이미 처리 중인 작업이나 예약된 재시도가 남아 있으면 상태가 바뀔 수 있다. 시작 조건에는 이를 종료·대기·격리하는 구체적 방법과 관찰 근거가 필요하다.

모든 쓰기가 멈췄다고 확인한 뒤 선택한 시점의 자료를 추출하고 변환한다. 어느 작업이 처리 중인지 알 수 없으면 “중단 완료”로 넘기지 않는다. 원본과 대상의 변환 검증이 끝나기 전에 사용자의 새 쓰기를 열지 않는 것이 이 학습 경로의 규칙이다.

중단 허용 시간이 지나거나 대조가 끝나지 않으면 예정한 실패 분기로 간다. 이때 어느 저장소가 기준 상태인지와 이미 허용한 작업이 있는지를 먼저 확인한다. 시간 초과 그 자체가 자료 삭제 권한이나 자동 성공을 뜻하지 않는다.

행 수와 합계가 같아도 틀린 이관일 수 있다

CH-D1에서는 식별자별 정수 금액의 의미가 바뀌지 않는 단순 변환을 가정한다. 원본과 대상의 키·금액은 다음과 같다.

잘못된 대상도 기록 수 2와 합계 300은 맞는다. 그러나 A와 B의 금액이 각각 바뀌었으므로 의미 보존에 실패했다. 이 예의 검증은 키 집합, 중복·누락, 키별 금액까지 비교한다. 실제 데이터에서는 합의한 변환 규칙·관계·상태 조건을 추가해야 한다.

입력 자료 자체에서 키가 중복되면 미리 사전형으로 바꾸어 마지막 값만 남기지 않는다. 중복을 먼저 오류로 드러낸다. 전체 대조를 하지 못한 표본 검사라면 그 한계도 결과에 표시한다.

정상 새 기록이 생긴 뒤에는 옛 백업이 현재가 아니다

별도 CH-D2 예에서 t0의 기준 기록은 A=100, B=200이다. 전환 검증 뒤 쓰기를 재개하고 C=50을 정상 접수했다. 그 직후 목표 저장소의 문제를 발견했다고 하자.

t0 백업       = [(A,100), (B,200)]       합계 300
t1 정상 접수  = (C,50)
t1 현재 기록  = [(A,100), (B,200), (C,50)] 합계 350
옛 백업만 복원 → C 누락, 현재 기대 합계와 50 차이

되돌림은 코드의 판본뿐 아니라 t0 이후 정상 변경의 보존 가능성을 확인해야 한다. C가 실제로 확정되었는지조차 불명확하다면 먼저 결과를 조사해야 하며, 존재하지 않았다고 가정해 버리지 않는다. 승인된 백업이라는 이름도 그 이후 거래를 삭제해도 된다는 허가가 아니다.

반대로 아직 목표에 새 쓰기를 허용하지 않았고 원본을 보존했다면 복귀 조건이 단순해질 수 있다. 두 상황을 같은 버튼으로 취급하지 않는다. [CH-S2]

기록 하나만 바꿔 직접 대조해 보자. 새 기록이 C=50 대신 C=80으로 확정됐다면 현재 기대 합계는 100 + 200 + 80 = 380이고 옛 백업 300과의 차이는 80이다. 차이 80을 찾는 데서 끝내지 않고, 현재 키 집합에 C가 있는지와 C의 내용이 80인지 확인해야 한다. A=180·B=200의 두 기록만 복원해 합계 380을 맞춰도 C가 없고 A가 바뀌었으므로 의미는 보존되지 않는다. 합계가 맞으니 복귀해도 된다라고 답했다면 행 수와 합계가 같아도 틀린 이관일 수 있다의 키별 대조로 돌아간다. 실제 복귀 판단에는 C의 확정 증거, 변환·재반영 방법, 중복 방지와 검증 가능한 상태가 필요하며, 합계를 계산했다는 사실만으로 그 방법이 마련되지는 않는다.

전환 단계마다 다음 단계의 시작 조건을 둔다

전환(cutover)은 실제 요청이나 처리의 기준을 준비한 목표 구현·상태로 넘기는 결정과 실행이다. CH-M1의 학습 절차에서는 먼저 판본·승인·시작 조건을 확인하고 쓰기를 중단한다. 그다음 t0 기준 자료를 변환하고 키별·계약별 대조를 마친다.

대상 설정과 권한, 결과 조회, 취소 확정의 의미를 확인한 뒤 새 쓰기 허용 여부를 결정한다. 시험 요청이 실제 취소·알림 등 외부 효과를 발생시키지 않는 격리 방법도 필요하다. 쓰기를 연 뒤에는 실제 정상 변경과 오류를 구분해 관찰한다.

상태표에는 단계의 시작·끝, 기준 저장소, 허용한 쓰기 주체, 증거와 다음 분기를 남긴다. 스크립트가 마지막 줄까지 실행되었다는 것과 사용자의 결과가 올바르다는 것은 다른 사실이다. 전환 완료는 정한 검증과 관찰의 종료 조건으로 판단한다.

복귀 가능·수습 필요·판정 부족을 구분한다

새 기록의 역변환이 가능하다는 확인, 원래 구현이 새 표현을 읽을 수 있다는 확인, 실제 복구 권한은 서로 다른 조건이다. 단순히 금액 합계가 맞는 것으로 모두 대체하지 않는다.

롤포워드 역시 안전이 자동 보장되는 선택은 아니다. 수정할 범위·상태·회귀 위험을 확인해야 하고, 복귀와 수정 모두 불확실하면 우선 추가 피해를 제한하며 담당자가 판단할 자료를 모은다.

4. 노출 비율과 전체 평균이 숨기는 문제

이 절의 별도 가상 관찰 CH-Q2에서는 새 판본 요청이 100건이고 그중 오류가 20건이다. 기존 판본은 9,900건에 오류 0건이다. 이는 앞의 AS-Q1 동시 취소 확정 시험과 다른 관찰 집합이며 실제 카나리 실행 결과가 아니다.

전체 0.2%만 보면 새 판본 20%의 오류를 놓칠 수 있다. 판본별 분모와 사용자 결과를 나누어 보고, 관련 없는 과거 구간이나 성공 요청만의 집계로 바꾸지 않는다. 사전에 정한 중단 조건에 비추어 판단하며 여기서 20%를 보편적 임계값으로 제안하지 않는다. [CH-S3]

비교군이 있어도 관찰이 충분한지 확인한다

새 판본에 들어온 요청이 쉬운 조회뿐이라면 실제 취소 경로의 위험을 평가했다고 할 수 없다. 사용자·요청 유형·부하와 관찰 기간이 중요한 장면을 대표하는지 확인한다. 요청이 한 건도 없는데 오류가 없다는 이유로 안정성이 검증된 것으로 표시하지 않는다. [CH-S2][CH-S3]

기존·새 판본이 같은 저장소나 외부 서비스를 공유하면 공통 장애 때문에 둘 다 나빠질 수 있다. 상대 차이가 작아도 절대적인 성공·지연·정확성 조건이 위반될 수 있으므로 둘을 함께 본다. 표시된 결과가 빠른 오류인지 실제 올바른 완료인지도 분리한다.

CH-Q2의 계산은 집계가 문제를 숨기는 반례다. 실제 새 판본을 확대할 판단에는 충분한 관찰, 비교 조건, 필수 계약과 상태 보존의 근거가 더 필요하다. 비율 한 개만으로 승인하지 않는다.

겉으로 같은 취소가 두 번 실행되는 전환을 막는다

CH-01의 저장 대조에서 예약 상태만 옮기고 요청 식별자별 처리 결과를 빠뜨리면, 응답을 잃은 요청의 재조회 의미가 달라질 수 있다. 기존 결과의 존재와 재요청 허용 범위가 어떻게 유지되는지 확인해야 한다. 기간이 미정이면 현재 필요한 보장을 설명할 수 없는 부분을 그대로 남긴다.

다른 구현을 동시에 시험한다며 실제 쓰기 요청을 양쪽에 복제하면 취소나 알림의 부작용이 두 번 일어날 수 있다. 비교 실행이 필요한 경우 외부 효과와 공유 상태를 격리할 수 있는지 확인한다. 읽기 요청처럼 보이는 경로에도 기록·과금 같은 효과가 있는지 조사한다. [CH-S3]

변경 후 UNKNOWN을 REJECTED로 바꾸어 표시하면 의미를 보존한 것도 아니다. 성공 응답 여부뿐 아니라 미확인 결과·중복 요청·다른 내용의 같은 식별자·권한 없는 요청의 처리까지 기존 계약과 대조한다.

서로 다른 검증 증거를 한 칸으로 합치지 않는다

정적 의존 검사는 M-USECASE가 저장 구현을 직접 참조하는지 등을 살핀다. 실행 계약 검사는 확정·거절·미확인·재요청의 결과를 확인한다. 자료 대조는 t0 이전과 이후의 정상 상태를 확인한다. 성능·장애 관찰은 정한 부하와 실패 상황의 품질을 평가한다.

변경 전 보안 영향 검토와 변경 후 권한·설정 확인도 필요하다. NIST의 해당 통제는 변경 후에도 요구가 충족되는지를 확인하는 질문을 포함하며, 한 번의 기능 시험 성공이 모든 보안 조건을 검토한 증거는 아니다. [CH-S1]

시험한 코드·설정·자료 규칙과 전환한 판본이 다르면 증거의 적용 범위를 다시 확인한다. 수행하지 않은 시험은 빈칸 또는 미실행으로 남기고, 성공·실패·판정 부족을 구별한다. 환경에 접근하지 못한 작성자가 성공 로그를 대신 만들어서는 안 된다.

전환 뒤에는 문서와 실행 경로를 함께 정리한다

변경 후 모듈·실행·배치 뷰, I-STORE의 구현 대응, 구성 목록과 운영 절차를 현재 상태에 맞게 갱신한다. 외부 계약을 그대로 유지했다면 그 사실과 검증 범위를 기록하고, 실제로 바뀐 조건은 변경 전후 차이를 남긴다. 결정 기록의 과거 이유를 지워 현재만 남기지 않는다.

구현이 달라졌는데 문서가 옛 경로만 가리키면 다음 장애 대응이나 변경 분석이 잘못될 수 있다. 반대로 문서를 새로 썼다고 구현 적합성이 자동 확인되는 것도 아니다. 현재 구현·문서·검증 기록의 대응이 필요하다.

사용을 끝낸 코드는 복구 명분으로 영구 실행 경로에 남기지 않는다. 필요한 이력과 증거는 버전 관리로 보존하고, 실제 운영에 남길 구성은 명시적 책임과 필요성으로 결정한다.

종료 기준은 새 구현의 기동 성공보다 넓다

단계적 대체라면 남은 소비자·배치·관리 도구가 옛 경로를 사용하지 않는지 확인한다. 결과 조회와 필요한 기록의 보존 조건, 접근권한, 관찰과 담당자 인계도 종료 조건에 포함한다. 대체한 기능의 실제 의존이 남았는데 코드부터 삭제하지 않는다. [CH-S4]

반대로 대체가 검증되고 옛 경로가 더는 필요 없으면 불필요한 분기·설정·자격 정보를 정리한다. 옛 경로가 남아 있다는 사실 자체가 복구 가능성의 증거는 아니다. 합의한 복귀 기간이 끝난 뒤의 장애는 현재 상태를 기준으로 별도 대응한다.

종료 기록에는 원래 목표의 충족 여부, 남은 위험·기술부채, 새 운영 책임과 다음 재평가 조건을 적는다. 해결하지 않은 항목을 지우는 대신 후속 작업으로 연결한다.

긴급 변경도 책임과 기록을 없애지 않는다

심각한 장애 때문에 평소의 긴 관찰을 그대로 수행하기 어려운 상황이 있을 수 있다. 조직이 정한 긴급 절차에 따라 변경의 영향·권한·핵심 확인·중단 경계를 결정하고, 생략하거나 축소한 검증과 이유를 기록한다. 긴급하다는 말만으로 승인·보호 조건을 모두 없애지는 않는다. [CH-S2]

복구 뒤에는 실제 변경, 사용자 영향, 정상 상태 보존, 미실행 검증을 다시 확인하고 기록을 정리한다. 사후 검토는 앞선 미검증을 실제로 통과했다고 소급해 꾸미는 절차가 아니다.

이 공방 예에서 무엇이 법적 필수 승인인지 판단하는 것은 범위 밖이다. 기술적으로도 누가 어떤 상태에서 무엇을 결정했는지 모르면 다음 복구 판단이 어려워진다는 점을 배운다.

아키텍처 변경관리의 전체 판단

변경의 원인과 목표를 특정 판본의 구조·계약·데이터·운영에 연결한다. 대안과 영향·위험을 분석하여 승인·보류·거절을 결정하고, 승인된 범위만 준비·리허설·전환한다. 전환 경계에는 쓰기·상태 기준점과 검증 조건, 실패 시 정상 데이터 보존 방안을 둔다.

관찰에서는 판본별·사용자 결과별 증거와 절대 품질 조건을 함께 살핀다. 조건을 충족하면 문서·운영 책임·옛 경로를 정리하고, 미확인이나 위반이 있으면 상태를 보존하며 후속 판단으로 연결한다. 종료 뒤의 부하·요구·배포 책임 변화는 새 평가와 변경의 입력이다.

이 절의 이행·전환·마이그레이션 사례는 승인된 기준이 없는 무제한 자동 변경을 정당화하지 않는다. 교육용 계산과 판정 목록은 실제 서비스의 백업·복구·보안·운영 승인을 대신하지 않는다.

독립 연습 — 행 수와 합계를 확인한 뒤에도 남는 것

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

원본은 (A,100),(B,200)이고 대상은 (A,150),(B,150)이다. 두 집합 모두 2 행·합계 300이다. 별도의 전환 사례에서는 올바른 A·B를 옮긴 뒤 새 정상 기록 C=50을 접수했지만 담당자가 옛 백업만 복원하려 한다.

• 첫 집합의 의미 보존을 판정하고 추가 대조 단위를 쓰라.
• 두 번째 사례에서 보존해야 하는 정상 상태와 옛 백업만 복원했을 때의 차이를 계산하라.
• 새 쓰기 여부 자체를 모르면 어떤 분기로 가야 하는지 쓰라.

10점 문제: 배운 조건으로 판단하기

자체 작성 문제이며 실제 기출이 아니다.

아키텍처 변경관리의 주요 활동과 영향 분석 대상을 설명하고, 코드 롤백만으로 데이터 상태의 안전한 복귀가 보장되지 않는 이유를 제시하시오.

정의만 나열하지 말고 문제의 단위·조건·근거와 결론을 연결한다. 제시하지 않은 실험 결과나 승인 사실을 만들어 답하지 않는다.

25점 문제: 배운 조건으로 판단하기

자체 작성 문제이며 실제 기출이 아니다.

공동 배포하는 공방 서비스의 저장 어댑터를 바꾸려 한다. 원본 A=100·B=200과 대상 A=150·B=150의 기록 수와 합계는 같다. 새 구현은 전환 뒤 C=50을 정상 접수했다. 별도 가상 관찰에서 새 판본은 100건 중 오류 20건, 기존 판본은 9900건 중 오류 0건이다. 영향·승인·데이터 전환·복귀·관찰·종료 조건을 제시하고 각 수치가 의미 보존과 확대 승인에 충분한지 판단하시오.

정의만 나열하지 말고 문제의 단위·조건·근거와 결론을 연결한다. 제시하지 않은 실험 결과나 승인 사실을 만들어 답하지 않는다.

출처와 적용 범위

이 절의 상황·숫자·표·도식·문제·답안은 집필자가 작성했다. 아래 자료의 기술적 사실을 독립적으로 설명했으며 원문의 사례·도표를 복제하지 않았다. 출처 문서의 현재 전체 적용성, 모델 이용 권한 또는 사람 승인은 별도 검토 사항이다.

[CH-S1] Ron Ross and Victoria Pillitteri / NIST. Assessing Security Requirements for Controlled Unclassified Information, SP 800-171A Revision 3. 위치: 03.04.03 Configuration Change Control; 03.04.04 Impact Analyses. 원문: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/800-171Ar3/NIST.SP.800-171Ar3.html 이 집필에서 위치 대조: 2026-09-06. 등록 출처의 원래 관찰일은 별도 보존하며 출판일로 바꾸지 않는다.

[CH-S2] Microsoft. Architecture strategies for safe deployment practices - Microsoft Azure Well-Architected Framework | Microsoft Learn. 위치: Failure-detection mechanisms; health checks; rolling back changes; progressive exposure and emergency deployment controls. 원문: https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/safe-deployments 이 집필에서 위치 대조: 2026-09-06. 등록 출처의 원래 관찰일은 별도 보존하며 출판일로 바꾸지 않는다.

[CH-S3] Google Inc.; O'Reilly Media. Google SRE - Canary Release: Deployment Safety and Efficiency. 위치: Requirements of a Canary Process; Choosing a Canary Population and Duration; Selecting and Evaluating Metrics; Dependencies and Isolation. 원문: https://sre.google/workbook/canarying-releases/ 이 집필에서 위치 대조: 2026-09-06. 등록 출처의 원래 관찰일은 별도 보존하며 출판일로 바꾸지 않는다.

[CH-S4] Microsoft Azure Architecture Center. Strangler Fig pattern. 위치: Context and problem; Solution; Issues and considerations; gradual replacement and removal of the legacy application. 원문: https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig 이 집필에서 위치 대조: 2026-09-06. 등록 출처의 원래 관찰일은 별도 보존하며 출판일로 바꾸지 않는다.

남겨야 할 판단

구조 변경의 시작은 바꿀 이유와 범위를 특정하는 일이고, 끝은 새 구조의 계약·상태·운영 책임과 불필요한 옛 경로를 정리하는 일이다. 그 사이에는 영향 분석·승인·시작 조건·전환·검증과 실패 시 정상 상태 보존이 연결되어야 한다.

기록 수와 합계의 일치, 코드 롤백, 낮은 전체 오류율은 각각 의미 보존·안전한 복귀·확대 승인을 보증하지 않는다. 어떤 근거가 부족한지 드러내고 실제 수행 결과로 다음 판단을 한다. 이 반복이 새로운 요구와 운영 결과를 반영하는 아키텍처 진화의 기본이다.

직접 연습: 중단 확인, 중복 식별, 정상 변경의 재반영을 구별한다.

다음은 전환 시작 조건과 자료 대조를 이해하기 위한 별도 가상 사례이다. 계산에서 정한 재반영 규칙을 실제 저장소의 복구 기능이나 실행 승인으로 간주하지 않는다.

1. CH-W. t0에 웹 창구의 새 쓰기를 막았다. 원본은 A=100, B=200이고 이를 대상에 복사했다. 그러나 이미 대기하던 배치가 t0 이후 원본에 D=40을 정상 기록했다. 다른 쓰기는 없고, 대상에는 D가 없다. 두 저장소의 현재 키와 합계는 무엇인가? ‘새 웹 요청이 0건’이라는 사실로 쓰기 중단과 전환 대조가 완료됐다고 할 수 있는가? 다음 단계로 가기 전에 무엇을 확인해야 하는가?
2. CH-K. 추출된 원본 행 목록은 (A,100), (B,200), (B,200)이고 대상은 (A,100), (B,200)이다. 원본을 먼저 사전형으로 만들면 같은 키 B의 마지막 값만 남는다. 행 목록 기준 원본의 행 수와 합계, 사전형으로 바꾼 뒤의 키 수와 합계는 각각 무엇인가? 변환된 사전과 대상이 같다는 이유로 원본을 올바르게 이관했다고 판정해도 되는가? 중복 행이 올바른지에 대한 추가 근거는 없다.
3. CH-I. 기준 자료 A=100, B=200에 정상 새 기록 C=50을 다시 반영하려 한다. 별도로 합의한 연습 규칙은 ‘같은 요청 식별자와 같은 내용은 한 번만 반영하고, 같은 식별자에 다른 내용이 오면 충돌로 남기며 덮어쓰지 않는다’이다. 재반영 목록에 (R701,C,50)이 두 번 있다. 두 행을 무조건 추가했을 때의 기록 수와 합계, 규칙대로 한 번 반영했을 때의 키 수와 합계는 무엇인가? 그 뒤 (R701,C,80)이 오면 무엇을 해야 하는가? 이 계산만으로 실제 복구 절차가 검증됐다고 할 수 있는가?