「AI에게 DB 마이그레이션을 돕게 하고 싶다. 하지만 실데이터를 외부 AI에 넘기는 것은 통제상 할 수 없다」 ―― 엔터프라이즈의 AI 활용이 가장 먼저 멈추는 곳은 기술이 아니라 바로 이 선이 아닐까요.

본 글에서는 호환성이 없는 이종 DB 간 마이그레이션(Oracle 19c→SQL Server 2022)의 전처리를, AI 코딩 에이전트(Claude Code)에 실데이터를 일절 넘기지 않고 수행한 실천을 보고합니다. 전처리란 호환성 리스크의 도출, 스키마 변환 설계, 마이그레이션 대상 실기에서의 동작 검증을 가리킵니다. AI에 넘긴 「데이터」는 DDL(테이블 정의 등 스키마 정의문)·에러 로그·실행 결과 메타데이터뿐이며, 행 데이터·개인정보는 일절 포함하지 않습니다. 검증 데이터는 모두 합성(더미) 데이터입니다. 또한 검증 환경으로의 원격 접속 정보는 사람의 통제하에 일시적으로 제공하고, 작업 후에 로테이션(무효화)하는 운용으로 하고 있습니다.

결론을 먼저 말하자면, 이 제약을 유지한 채로 마이그레이션 대상 실기로의 적용 29배치·에러 0건, 검증용 스키마에 담은 Oracle 고유 기능의 변환 전체(SEQUENCE 채번·PL/SQL 프로시저·CONNECT BY 계층 쿼리·ROWNUM 페이징·머티리얼라이즈드 뷰 대체·Unicode 처리)의 동작 증명까지 도달할 수 있었습니다. 진행 방식은 완전 자동이 아니라, 요소요소에 사람의 승인 게이트를 둔 반자동입니다. 또한 그 과정에서 AI의 안전 가드레일이 위험한 조작을 2회 차단하는, 거버넌스 관점에서 시사하는 바가 큰 사건도 있었습니다.

1. DB 마이그레이션은 「기술」보다 먼저 「통제」와 「사람」에서 멈춘다 #

Oracle 데이터베이스로부터의 마이그레이션(이른바 「탈Oracle」, 대상을 좁히는 「감Oracle」)은 많은 기업에서 반복적으로 검토되어 온 주제입니다. 2026년 6월 시점의 공표 정보로는 Oracle Database 19c의 Premier Support는 2029년 말, Extended Support는 2032년 말까지로 되어 있습니다(^[1]). 언뜻 보면 유예가 생긴 것처럼 보이지만, 연장 기간 중 제공 내용에는 조건이나 제외 사항이 있을 수 있으므로 자사 계약에서의 확인이 필요합니다. 오히려 「기한에 쫓긴 막판 마이그레이션은 계획이 허술해진다」는 것이야말로 과거의 교훈이며, 시간이 있을 때 마이그레이션의 고정비(전처리 비용)를 낮춰 두는 데 가치가 있습니다.

한편으로 마이그레이션 프로젝트가 진행되지 않는 이유는 대체로 3가지로 집약됩니다.

1. 호환성의 불확실성 ― 어디가 깨질지 사전에 알 수 없다. 발견이 후공정으로 미뤄질수록 재작업 비용은 자릿수가 다르게 불어난다고 한다
2. 인재 ― Oracle과 SQL Server 양쪽에 정통한 엔지니어는 채용 시장에서 확보하기가 극히 어렵다
3. 통제 ― 실데이터·운영 정보를 외부 AI에 넘기는 것이 사내 규정상 불가능하다

인재 측면의 핍박은 통계에도 나타나 있지만(경제산업성 시산〔2019년〕에서 2030년에 IT 인재가 중위 시나리오로 약 45만 명 부족(^[2]), IPA 조사에서 DX 인재의 「질」 부족 응답이 51.7%(^[3])), 현장의 실감은 더 단순합니다. 사내의 Oracle을 속속들이 아는 담당자의 정년·이동이 임박한 한편, 유지보수비는 매년 경직적으로 나갑니다. 마이그레이션 검토는 「언젠가 한다」가 아니라 「할 수 있는 사람이 있을 때 누가 하느냐」의 문제가 되고 있습니다.

본 글은 이 3가지, 특히 「3. 통제」를 제약으로 받아들인 다음, 1과 2를 AI로 어디까지 해소할 수 있는지에 대한 실지 검증입니다.

2. 본고의 스코프 ― 한 것·아직 하지 않은 것 #

과장을 피하기 위해, 먼저 범위를 명시합니다. 마이그레이션 도구는 SSMA(SQL Server Migration Assistant. Microsoft 정품 마이그레이션 지원 도구)의 이용을 전제로 합니다.

포인트는 순서입니다. (3)기댓값을 (2)도구 실측보다 먼저 쓰고, (5)실기에서 동작 증명까지 해 둡니다. 동작이 증명된 기댓값은 도구 출력을 리뷰하기 위한 「검수 기준」으로 사용할 수 있습니다. 테스트 주도 개발의 발상을 마이그레이션 프로젝트에 들여온 형태입니다. 또한 기댓값은 T-SQL(SQL Server의 SQL 방언)로 기술합니다.

25개 항목의 체크리스트는 현시점에서는 어디까지나 사전 예측입니다. SSMA의 실측 결과와의 대조, 즉 예측이 어디까지 맞고 어디가 빗나가는지는 다음 편 글에서 보고합니다.

또 하나, 본고가 다루지 않는 영역도 명시해 둡니다. DB 마이그레이션 프로젝트 전체에는 애플리케이션 측 자산(임베디드 SQL, 데이터 액세스 계층, 장표, 배치 잡, DB 링크 연계 등)의 개수(改修)라는 큰 공정이 있으며, 일반적으로 총 공수의 과반을 차지합니다. 본고가 커버하는 것은 스키마와 DB 내 로직의 변환 부분이며, 전체에서 보면 일부입니다. 다만 이곳은 「먼저 확정하지 않으면 후속의 모든 것이 재작업이 되는」 기초 공사이기도 합니다.

3. 가장 먼저 정한 통제 3원칙 ― 「AI에게 무엇을 넘기지 않을 것인가」의 설계 #

작업 개시 전에, 다음 3원칙을 고정했습니다.

1. 실데이터는 다루지 않는다(검증 데이터는 모두 완전 합성)
2. 크레덴셜은 코드·파일에 영구 저장하지 않는다
3. 마이그레이션 대상 DB의 포트를 불필요하게 외부 공개하지 않는다

AI에게 넘겨도 되는 정보의 선 긋기는 다음과 같습니다.

※검증기로의 원격 접속 정보는, 사람의 관리하에 일시적으로 제공하고 작업 후에 로테이션하는 운용으로 했습니다(제10장 참조).

「외부 AI 서비스에 보낸다」는 것 자체의 정리 #

「실데이터를 넘기지 않는다」고 하더라도, DDL이나 에러 로그도 정보 자산임에는 변함이 없습니다. 외부 AI 서비스의 이용에 있어서는 최소한 다음의 계약 조건을 확인한 다음에 선 긋기를 정할 필요가 있습니다.

• 입력·출력이 모델의 학습에 이용되지 않을 것(본 검증에서 이용한 Claude Code는 상용 이용 조건에서 입력을 기본적으로 모델 학습에 이용하지 않는다는 취지가 공표되어 있습니다. 이용 플랜별 최신 약관의 확인은 필수)
• 데이터의 보존 기간과 삭제 조건
• 처리 리전과 준거법
• 스키마 자체가 기밀에 해당하는 경우의 추가 조치. 테이블명·열명을 기계적으로 익명화하여 넘기고, 결과를 사내에서 역변환하는 방법을 취할 수 있습니다(대응표는 사내에서만 보관)

이 원칙이 먼저 있음으로써, 후속의 기술 판단이 자동으로 방향이 잡혔습니다. 예를 들어 DB 인증은 OS 통합 인증으로 모으고, 「비밀번호라는 비밀 정보를 애초에 만들지 않는」 구성을 채택하고 있습니다. 그 결과, 완료 시점에 산출물 파일·스크립트·실행 로그 어디에도 DB 접속의 비밀 정보는 존재하지 않습니다.

시사: AI 이용 가이드라인은 「해서는 안 되는 것의 일람」으로 선반에 두는 것이 아니라, 프로젝트 규약·프롬프트로서 AI에게 가장 먼저 읽혀 두면 집행력이 크게 높아집니다. 다만 본 검증에서는 그래도 일탈의 시도가 2회 발생했습니다(제8장). 사전 지시는 단독으로는 완결되지 않으며, 승인 게이트·가드레일을 포함한 3계층으로 비로소 통제로서 성립합니다.

4. 실데이터 대신 무엇을 넘겼는가 ― 마이그레이션 검증 키트의 구성 #

실데이터를 넘기지 않는 대신, AI에게는 먼저 「호환성 문제를 의도적으로 담은 검증용 Oracle 스키마」를 설계하게 했습니다. 운영 스키마의 대리로서, 마이그레이션에서 문제가 되기 쉬운 요소를 하나의 스키마에 응축한 것입니다.

검증 키트(5가지 산출물)

합성 데이터의 설계에는 한 가지 궁리를 더했습니다. 일본어·NULL·경곗값·특수문자·이모지 같은 「문제를 일으키기 쉬운 값」을, 난수에 맡기지 않고 「보증 행」으로서 반드시 투입하는 설계로 했습니다. 운영 데이터에서 일어나는 문제를, 합성 데이터로 미리 재현하기 위해서입니다. 난수 시드를 고정하고 있기 때문에, 동일한 검증 데이터를 몇 번이고 재현할 수 있는 설계입니다(Oracle 실기에서의 생성 실행은 다음 편 스코프. 감사 시의 재현을 의도하고 있습니다).

AI 자신은 셀프 리뷰로, 직접 만든 생성 SQL의 버그 3건(비결정적인 조인, 멀티바이트 문자에서의 길이 상한 초과, 유효하지 않은 최적화 힌트)을 실행 전에 검출·수정하고 있습니다. 「AI의 산출물은 무오류」인 것이 아니라, 「자기 검증의 루프 포함으로 빠르다」가 올바른 이해입니다. AI의 출력 또한 검증 대상이다 ―― 이 전제는 본 수법 전체를 관통하고 있습니다.

5. 호환성의 함정을 「업무 임팩트」로 읽는다 #

Oracle→SQL Server의 호환성 문제는 기술 용어로 이야기되기 쉽지만, 의사결정의 자리에서는 업무 임팩트로 번역할 필요가 있습니다. 체크리스트 25개 항목 중, 특히 위험한 6가지를 발췌합니다.

본 장에 기재하는 SSMA의 거동은 모두 실행 전의 사전 예측입니다(실측과의 대조는 다음 편).

① VARCHAR2/CLOB의 비Unicode 변환 #

• 예측: 기본 변환에서는 VARCHAR/VARCHAR(MAX)로 될 전망. 콜레이션의 코드 페이지에 없는 문자(이모지·확장 한자 등)가 「?」로 깨지고, 일본어 이외의 콜레이션 환경에서는 일본어 전체가 깨진다
• 업무 임팩트: 고객명·주소의 비가역적인 데이터 훼손. 마이그레이션 후에 알아채도 원래대로 되돌릴 수 없다
• 대처: NVARCHAR/NVARCHAR(MAX)를 명시

② Oracle DATE의 시각 소실 #

• 예측: Oracle의 DATE는 초까지 보유한다. SQL Server의 DATE 형에 안이하게 매핑하면 시각이 사라진다(SSMA 기본값은 DATETIME2(7)로 예측하고 있으며, 그 경우 시각은 보유되지만 정밀도 과잉)
• 업무 임팩트: 수주 시각·감사 증적의 타임스탬프가 사라져, 마감 처리·SLA 계측이 깨진다
• 대처: DATETIME2(0)으로 받는다

③ 정밀도 없는 NUMBER의 FLOAT화 #

• 예측: 정밀도 지정이 없는 NUMBER가 부동소수점 형으로 변환될 전망으로, 반올림 오차가 섞인다
• 업무 임팩트: 금액·수량이 어긋나서 경리 대조가 통과되지 않는다
• 대처: DECIMAL/BIGINT를 명시

④ 빈 문자열과 NULL의 취급 차이 #

• 예측: Oracle에서는 빈 문자열 ''은 NULL. SQL Server에서는 별개로 취급된다(이것은 두 제품의 사양 차이이며 예측이 아니라 확정 사항)
• 업무 임팩트: 에러는 나지 않는데 업무 로직의 판정 결과만 바뀐다. 가장 발견하기 어렵다
• 대처: 마이그레이션 시의 정규화 방침을 사전 결정

⑤ CONNECT BY 계층 쿼리 #

• 예측: 자동 변환 불가로 예측. 조직 계층·BOM·계정 과목 트리의 쿼리가 대상
• 업무 임팩트: 수동 재작성 공수가 견적에 직격
• 대처: 재귀 CTE(공통 테이블 식에 의한 계층 질의)로 재작성. 등가 구현을 준비 완료

⑥ 머티리얼라이즈드 뷰 #

• 예측: 완전한 등가 기능은 없다(인덱스 뷰는 자동 유지되지만, 리프레시 지정·집계의 자유도 등 제약이 크다)
• 업무 임팩트: 야간 배치·장표 집계의 기반을 재설계
• 대처: 테이블＋리프레시 처리, 또는 제약을 허용할 수 있는 경우에는 인덱스 뷰

25개 항목 전체의 예측 내역은, 자동 변환할 수 있을 전망 10·요리뷰 경고 11·자동 변환 불가 2·사람의 설계 판단이 필요 6. 합계 29분류가 되는 것은, 복수 구분에 해당하는 항목이 있기 때문입니다. 즉 예측 단계에서, 「도구에 맡겨 그대로 끝나는」 전망은 전체의 4할 정도. 나머지 6할에 어떻게 대비할지가 마이그레이션 품질을 결정합니다.

이 25개 항목 체크리스트는, 독자의 마이그레이션 안건에서도 「리뷰 관점표」「견적 근거」로서 전용할 수 있는 입도로 만들어 두었습니다.

6. 기댓값 스키마 ― 마이그레이션의 「검수 기준서」를 AI에게 쓰게 한다 #

본 수법의 핵심은, SSMA의 출력을 보고 나서 생각하는 것이 아니라, 마땅히 그래야 할 변환 결과(기댓값)를 먼저 고정하는 것입니다. AI가 생성한 기댓값 스키마에는, 모든 변환에 이유 코멘트가 붙어 있습니다. 형 대응표의 발췌를 제시합니다.

주목해 주셨으면 하는 것은, 같은 DATE 형이라도 「주문 일시는 DATETIME2(0), 생일은 DATE」와 같이 열 단위로 판단을 나누고 있는 점입니다. 이것은 기계적인 일괄 변환에서는 나오지 않는, 업무를 감안한 설계 판단입니다. 이 판단은 사람이 처음부터 쓴 것이 아니라, AI가 제안하고 코멘트로 이유를 명시하며, 사람이 리뷰하여 승인한 것입니다.

「AI가 만들었다」로 끝내지 않고, 변환 이유·채택하지 않은 대안을 코멘트로서 산출물에 남긴다. 이것을 의무화하는 것만으로, AI 산출물은 후임자·감사인이 판단을 추적할 수 있는 추적 가능한 문서가 됩니다.

7. 마이그레이션 대상 실기에서의 동작 증명 ― 「변환했다」와 「동작한다」는 다르다 #

기댓값 스키마는, 쓴 것만으로는 검수 기준이 되지 않습니다. 기준 자체가 동작하지 않는 것으로는, 도구 출력을 재는 잣대가 되지 않기 때문입니다. 그래서 마이그레이션 대상의 SQL Server 2022 실기(콜레이션 Japanese_XJIS_140_CI_AS)에 적용하여, 기능 검증까지 수행했습니다.

적용 결과: 29배치 실행·에러 0건(테이블 11〔업무 10표＋머티뷰 대체 테이블 1〕／뷰 3／함수 1／프로시저 2. 적용 도구 측의 불량을 수정한 다음의 최종 적용 시의 결과입니다)

기능 스모크 테스트(Oracle 고유 기능의 변환이 「동작한다」는 것의 증명):

가장 전하고 싶은 것은 Unicode 검증입니다. 이모지를 포함하는 문자열 「絵文字A😀🍣」를 투입·취득한 결과, LEN=6／DATALENGTH=16바이트로 완전 일치했습니다. 「_140」 세대의 콜레이션이 서로게이트 페어(이모지 등의 보조 문자)를 올바르게 1문자로 취급한다는 것을, 정성 평가가 아니라 수치로 확인한 것이 됩니다. 일본어 데이터를 다루는 엔터프라이즈에서는, 여기까지 검증하고서야 비로소 「문자가 깨지지 않는다」고 말할 수 있습니다.

검증의 작법으로서, 기능 테스트는 일회용 스크래치 DB를 생성하여 실행하고, 종료 후에 폐기하고 있습니다. SSMA 실측을 기다리는 본 검증 DB는, 깨끗한 채로 유지되고 있습니다.

검증 중에는, AI가 쓴 검증 스크립트 자체의 버그(SQL 배치의 분할 처리나, 시스템 뷰의 열명 오류 등)가 실기 에러로 드러나, AI가 에러 메시지를 읽고 자기 수정하는 장면이 여러 차례 있었습니다. 「실기에 부딪혀 고친다」는 수수한 반복이 사람 손 없이 돌아가는 것. 이것이 공수 압축의 실태에 가장 가까운 묘사입니다.

공평을 기하기 위해, 이 검증의 한계도 명시합니다. 검증 스키마도 기댓값도 AI가 설계하고 있어, 구도로서는 「자작한 시험에 합격한」 단계입니다. 이것이 독선으로 끝나지 않도록, 기댓값은 SSMA라는 독립된 변환기의 출력과의 diff(다음 편)로 대조하는 설계로 하고 있습니다. 또한 어디까지나 10표 규모에서의 성공이며, 수백～수천 오브젝트 규모, DB 링크·파티션·PL/SQL 패키지가 얽힌 실제 스키마에서 새롭게 나타나는 문제는 미검증입니다.

8. 예상 밖의 수확 ― AI의 가드레일이 「통제의 파수꾼」이 되었다 #

본 검증에서 시사하는 바가 컸던 것은, 계획하지 않았던 사건이었습니다. 작업 중, AI 측의 안전 기구(가드레일)가 2회, 조작을 실행 전에 차단한 것입니다. 또한 대상은 모두 인터넷 비공개의 자사 검증 환경이며, 운영 환경·고객 환경은 포함되지 않습니다.

• 사례①: AI가 작업 효율을 우선하여, 보안 설정을 약화시키는 방향의 조작(보호 기구를 완화하여 처리를 통과시키는 접근)을 제안·시도했을 때, 실행 전에 안전 기구가 거부. AI는 우회책을 찾는 것이 아니라, 더 안전한 기본 설정 그대로 성립하는 대체 수단으로 전환하여 속행했다
• 사례②: AI가 인증 정보를 파일에 기록하여 이용하려고 했을 때, 실행 전에 거부. 방침을 전환하여, 본 검증 페이즈에서는 「비밀번호라는 비밀 정보를 애초에 만들지 않는」 OS 통합 인증 기반의 구성에 도달했다

중요한 것은, 2건 모두 사람 측이 서두에서 고정한 통제 3원칙과 일치하는 제지였다는 점입니다. 가드레일은 작업의 방해가 아니라 「설계 원칙의 파수꾼」으로서 기능하여, 최종 구성을 오히려 안전 측으로 끌어올렸습니다.

다만, 이것을 「AI의 안전 기구가 있으니까 괜찮다」고 읽는 것은 잘못입니다. 가드레일의 거동은 모델이나 버전에 의존하며, 단독으로 통제의 근거가 되지는 않습니다. 본 검증에서 도출할 수 있는 실무적인 모델은 3계층 통제입니다.

1. 제1계층: 사전 원칙 ― 넘겨도 되는 정보의 선 긋기와 금지 사항을, AI에 대한 최초의 지시로서 고정한다
2. 제2계층: 사람의 승인 게이트 ― 전제가 무너진 국면에서는 AI는 선택지의 제시에 그치고, 사람이 방침을 결정한다
3. 제3계층: 가드레일 ― 제1·2계층을 빠져나간 위험 조작의 최종 방파제

제2계층은 본 검증에서도 실제로 기능하고 있습니다. 환경의 전제가 상정과 다르다고 판명된 장면에서는, AI는 독단으로 진행하지 않고 선택지를 제시하고, 사람이 방침을 결재했습니다. 채번 방식의 선정 같은 설계 판단도 마찬가지입니다.

통제의 전제로서, AI에게 부여한 실행 환경도 한정하고 있습니다. 대상은 인터넷 비공개 세그먼트의 검증 전용기뿐이며, 운영계로의 접속 경로는 없습니다. 조작은 모두 기록되며, 사람이 언제든지 세션을 정지할 수 있습니다. 나아가, 가드레일이 작동하지 않았을 경우에 대비한 탐지 수단은 사람 측에 갖게 합니다. 구체적으로는, 워크 로그상의 조작 기록을 「인증·권한·외부 송신에 관련된 조작」이라는 관점에서 사후 리뷰하는 운용입니다.

그리고, 어떤 판단을 AI가 하고, 어디서 사람이 승인하고, 어디서 가드레일이 작동했는지를 시계열로 기록한 워크 로그가, 그대로 AI 이용의 감사 증적이 됩니다.

9. AI에게 맡긴 손수, 사람에게 남은 판단 #

본 검증을 통한 역할 분담의 실적은 다음과 같습니다.

이 선 긋기가 의미하는 것은, 마이그레이션에 필요한 인재상의 변화입니다. 「Oracle과 SQL Server 양쪽을 처음부터 쓸 수 있는 양손잡이 엔지니어」를 찾는 것이 아니라, AI가 생성한 형 대응표·체크리스트·선택지를 읽고 판단할 수 있는 리뷰어가 있으면 됩니다. 후자 쪽이, 조달도 육성도 훨씬 현실적입니다.

공수에 대해서도 언급해 둡니다. 본 검증(10표 규모)의 내역은 다음과 같습니다.

당사의 지금까지의 경험으로는, 같은 종류의 전처리는 두 DB에 정통한 인력을 확보한 다음 주 단위를 요하는 것이 통례였습니다. 다만 소요는 안건 규모·스키마 복잡도에 의존하므로, 이 비교를 정량 효과로서 일반화하는 것은 삼갑니다. 독자가 자신의 안건에서 견적할 때는, 「대상 오브젝트 수 × 리뷰 시간(형·채번·날짜의 판단이 필요한 테이블일수록 무겁다)」을 사람 측 공수의 기초에 두고, AI 측의 생성·검증은 그 종속 변수라고 생각하는 것이 실태에 가까울 것입니다.

「리뷰어가 있으면 된다」의 리뷰어 요건도 구체화해 둡니다. 필요한 것은 앞서 게재한 역할 분담표의 오른쪽 열, 즉 채번 방식·날짜 형·콜레이션·NULL 방침의 판단을 내릴 수 있는 것으로, 실질적으로는 SQL Server 측의 설계 경험자가 1명 있으면 충분합니다. 사내에 SQL Server의 운용·설계 경험자가 있으면 내제 가능, 없으면 그 판단 부분만 외부 리뷰를 병용한다, 는 것이 현실적인 분기입니다.

10. 자사에서 시도하기 위한 체크리스트 #

본 수법을 자사의 마이그레이션 검토에 적용하는 경우의 요점을 정리합니다.

정보의 선 긋기(AI 이용 가이드라인으로의 반영)

• 넘겨도 됨: DDL·스키마 구조·에러 로그·통계 메타데이터
• 넘기지 않음: 행 데이터·개인정보·DB의 영구적인 인증 정보
• 작업상 부득이하게 일시 공유하는 접속 정보는, 사람의 관리하에 제공하고 작업 후에 반드시 로테이션
• 스키마 자체가 기밀인 경우: 테이블명·열명의 익명화, 구조만의 추출을 검토

합성 데이터의 요건

• 완전 합성(운영 값의 혼입 없음)
• 난수 시드 고정으로 재현 가능한 설계
• 일본어·NULL·경곗값·특수문자·이모지의 「보증 행」을 포함

산출물의 요건

• 모든 변환 판단에 이유 코멘트(채택하지 않은 대안도)
• 예측과 실측의 분리 기록(체크리스트에 「예측」 라벨)
• 워크 로그의 보전(판단 주체가 시계열로 추적될 수 있을 것. 사외 제공 시는 새니타이즈)

운용의 요건

• 사람의 승인 게이트를 통과시키는 판단 포인트의 사전 정의
• AI의 거부(가드레일 작동) 이벤트도 기록 대상으로

11. 정리 ― 마이그레이션 품질은 「나중에 발견한다」에서 「먼저 고정한다」로 #

실증된 것

• 실데이터를 1행도 AI에 넘기지 않고, 마이그레이션 전처리(호환성 예측·변환 설계·마이그레이션 대상 실기에서의 적용과 기능 검증)는 완수할 수 있다
• 기댓값 스키마를 먼저 써서 실기에서 동작 증명하는 「검수 기준의 사전 고정」은, AI로 실용 속도가 된다
• 통제 원칙을 가장 먼저 AI에 부여하고, 승인 게이트와 가드레일을 겹치면, 통제 측의 구조로서 기능한다

아직 실증되지 않은 것

• SSMA에 의한 실변환의 결과(25개 항목 체크리스트는 사전 예측의 단계)
• 실데이터 마이그레이션 페이즈의 과제(데이터 품질·건수 규모에서의 성능·운용 설계). 이곳은 계속해서, 통제된 사내 환경에서 사람과 전용 도구가 담당하는 영역입니다

다음 편에서는, SSMA for Oracle의 Assessment Report를 실측하여, 25개 항목의 예측이 어디까지 맞고, 어디가 빗나갔는지를 1건씩 대조합니다. 예측을 먼저 문서로서 고정했기에 가능한 검증입니다. 예측이 빗나간 항목이야말로, 조직에게 가장 가치 있는 지견이 될 것입니다.

부록 A: 호환성 체크리스트 25개 항목의 전체상(SSMA 변환 결과의 사전 예측) #

구분의 범례: 자동=자동 변환 전망／경고=변환되지만 요리뷰／에러=자동 변환 불가의 전망／설계=사람의 설계 판단이 필요

부록 B: AI 이용 가이드라인 조문 예시(사내 검토의 초안) #

1. (정보의 구분) AI에 제공해도 되는 정보는, 스키마 정의(DDL), 에러 로그, 통계 메타데이터로 한다. 행 데이터, 개인정보, 영구적인 인증 정보의 제공을 금지한다.
2. (검증 데이터) AI를 이용한 검증에 사용하는 데이터는 완전 합성으로 하고, 생성 조건(난수 시드 등)을 기록하여 재현 가능성을 확보한다.
3. (승인 게이트) 설계 판단 및 작업 전제의 변경은, AI에 의한 선택지의 제시와 담당자의 승인을 거쳐 실시한다.
4. (기록) AI의 조작·판단·안전 기구의 작동 이벤트는 시계열로 기록하고, 보전한다. 사외 제공 시는 새니타이즈를 행한다.
5. (일시 인증 정보) 작업상 일시적으로 공유한 인증 정보는, 작업 완료 후에 무효화한다.

출처 #

• [1]: Oracle Lifetime Support Policy: Oracle Technology Products(Oracle 공식) https://www.oracle.com/us/assets/lifetime-support-technology-069183.pdf （보충 보도: The Register, 2025년 2월 https://www.theregister.com/2025/02/18/oracle_extends_19c_support/ ）。연장 기간 중 제공 내용·제외 사항은 자사 계약에서의 확인을 권장합니다.
• [2]: 경제산업성 「IT 인재 수급에 관한 조사」(2019년) https://www.meti.go.jp/policy/it_policy/jinzai/gaiyou.pdf
• [3]: IPA 「DX 백서 2023」. DX를 추진하는 인재의 「질」이 대폭 부족하다고 응답한 기업은 2022년도 조사에서 51.7%(2021년도 30.5%) https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108046.pdf