DES·3DES가 레거시인 이유: AES 전환 시 확인할 데이터와 키

1장 DES와 3DES는 왜 아직 문제가 되는가#

DES와 3DES는 오래된 암호 알고리즘입니다.

신규 서비스를 처음 만드는 개발자라면 직접 선택할 가능성이 낮지만, 오래 운영된 시스템에서는 여전히 발견될 수 있습니다.

예를 들어 다음과 같은 곳입니다.

오래된 업무 시스템
레거시 데이터베이스
배치 프로그램
외부 기관 연계
과거 백업 파일
장기 보존 데이터

원문에서는 DES를 56비트 유효 키를 사용하는 오래된 블록 암호로 설명하고, 3DES 역시 DES 연산을 반복해 보완했지만 작은 블록 크기와 성능·보안 한계 때문에 신규 시스템에서 선택할 이유가 약하다고 설명합니다.

중요한 것은 단순히:

DES는 오래됐으니 AES로 바꾸자.

가 아닙니다.

이미 DES나 3DES로 암호화된 데이터가 존재한다면 기존 데이터를 읽는 문제와 새 데이터를 암호화하는 문제를 분리해서 생각해야 합니다.

2장 DES란 무엇인가#

DES는 대칭키 기반 블록 암호입니다.

원문의 핵심 특성은 다음과 같습니다.

유효 키 길이
56비트

블록 크기
64비트

대칭키 암호이므로 같은 비밀키를 기반으로 암호화와 복호화를 수행합니다.

flowchart LR
    P[평문]
    E[DES 암호화]
    C[암호문]
    D[DES 복호화]
    P2[평문]
    K[공유 비밀키]

    P --> E --> C --> D --> P2
    K --> E
    K --> D

문제는 오늘날 기준에서 56비트 키 공간이 너무 작다는 점입니다.

3장 56비트 키가 왜 문제가 되는가#

키 길이가 56비트라면 가능한 키의 수는 매우 많아 보입니다.

하지만 현대적인 컴퓨팅 환경에서는 과거와 같은 보안 강도를 기대하기 어렵습니다.

핵심은 다음과 같습니다.

키 공간이 작다
↓
가능한 키를 모두 시험하는 공격 가능성이 커진다
↓
장기간 비밀을 보호하기 어렵다

DES가 레거시로 취급되는 가장 대표적인 이유 중 하나입니다.

4장 3DES는 DES를 여러 번 사용한다#

DES의 한계를 보완하기 위해 등장한 대표적인 방식이 3DES입니다.

3DES는 이름처럼 DES 연산을 반복합니다.

개념적으로 단순화하면 다음과 같습니다.

flowchart LR
    P[평문]
    D1[DES 연산 1]
    D2[DES 연산 2]
    D3[DES 연산 3]
    C[암호문]

    P --> D1 --> D2 --> D3 --> C

단순 DES보다 강화된 방식이지만, 이것이 오늘날 신규 시스템에서 3DES를 선택해야 한다는 뜻은 아닙니다.

5장 3개의 키를 사용하면 168비트 보안인가#

3DES를 처음 보면 다음과 같이 생각하기 쉽습니다.

DES 키
56비트

3개 사용
56 × 3
=
168비트

따라서:

3DES는 168비트 보안이니 충분하지 않은가?

라고 생각할 수 있습니다.

하지만 원문에서는 세 키를 합친 168비트라는 숫자와 실효 보안 강도를 동일하게 보면 안 된다고 명확히 설명합니다.

즉:

키 길이 숫자를 단순 합산한 값
≠
실제 공격에 대한 보안 강도

입니다.

6장 3DES의 또 다른 문제는 64비트 블록이다#

DES와 3DES는 64비트 블록을 기반으로 합니다.

원문에서는 같은 키로 많은 데이터를 처리할 때 작은 블록 크기 때문에 충돌 위험을 고려해야 한다고 설명합니다.

이 부분은 키 길이와 별개의 문제입니다.

키 길이
→ 키 공간과 관련

블록 크기
→ 한 번에 처리하는 데이터 단위와 관련

3DES의 키를 자주 교체한다고 해서 64비트 블록이라는 알고리즘 구조 자체가 바뀌는 것은 아닙니다.

7장 키 길이와 블록 크기를 따로 봐야 한다#

레거시 암호를 평가할 때 흔히 키 길이에만 관심을 둡니다.

하지만 실제로는 다음 두 가지를 구분해야 합니다.

flowchart TB
    CIPHER[블록 암호]

    KEY[키 길이]
    BLOCK[블록 크기]

    KEY --> K1[키 공간]
    BLOCK --> B1[데이터 처리 단위]

    CIPHER --> KEY
    CIPHER --> BLOCK

3DES에서는:

키 구조
DES보다 확장됨

블록 크기
여전히 64비트

라는 점이 중요합니다.

8장 성능 측면에서도 신규 시스템에서 매력이 줄었다#

3DES는 DES 연산을 여러 차례 수행합니다.

즉 단순 DES보다 연산량이 증가합니다.

신규 시스템에서는 AES 같은 현대적인 대칭키 암호와 검증된 구현을 사용할 수 있기 때문에 굳이 3DES를 새로운 시스템의 기본 암호로 선택해야 할 이유가 줄어듭니다.

원문에서도 3DES의 문제를 작은 블록 크기뿐 아니라 성능·보안 한계와 함께 설명합니다.

9장 정책 측면에서도 레거시로 봐야 한다#

원문에서는 NIST SP 800-67 Rev.2가 2024년 1월 1일 철회되었다고 설명합니다.

여기서 중요한 것은 철회의 의미를 단순화하지 않는 것입니다.

특히 원문은:

과거에 보호한 데이터를 복호화하기 위한 제한적인 레거시 처리를 신규 암호화 허용으로 해석해서는 안 된다.

고 강조합니다.

즉 다음 두 상황은 다릅니다.

기존 3DES 데이터 읽기

와:

오늘 새 데이터를 3DES로 암호화

는 같은 정책 판단이 아닙니다.

10장 마이그레이션의 핵심은 읽기와 쓰기를 분리하는 것이다#

레거시 암호 전환에서 가장 중요한 원칙 중 하나입니다.

기존 데이터는 당장 모두 변환되지 않을 수 있습니다.

따라서 일정 기간:

읽기
→ DES·3DES와 새 형식 모두 지원

쓰기
→ 새 암호 방식만 사용

하는 전략을 사용할 수 있습니다.

원문에서도 읽기 경로는 일정 기간 기존 형식을 지원하고 쓰기 경로는 새 AEAD 형식으로 전환하는 방법을 제시합니다.

11장 읽기와 쓰기를 그림으로 보면#

flowchart TB
    APP[Application]

    READ{읽기}
    WRITE{쓰기}

    OLD[기존 DES·3DES 데이터]
    NEW[새 암호 형식]

    APP --> READ
    APP --> WRITE

    READ --> OLD
    READ --> NEW

    WRITE --> NEW

이 구조의 장점은 신규 데이터를 더 이상 레거시 암호로 증가시키지 않으면서 기존 데이터도 일정 기간 사용할 수 있다는 것입니다.

12장 가장 나쁜 전환은 신규 데이터까지 계속 3DES로 만드는 것이다#

다음과 같은 상태를 생각해보겠습니다.

신규 기능은 AES 도입

하지만 기존 모듈에서는 계속 3DES 생성

이 경우 시간이 지나도 레거시 데이터가 계속 늘어납니다.

flowchart LR
    OLD[기존 레거시 데이터]
    WRITE[레거시 쓰기 계속]
    MORE[레거시 데이터 증가]

    OLD --> WRITE --> MORE

마이그레이션의 첫 번째 목표 중 하나는 새로운 레거시 데이터가 더 이상 생성되지 않도록 만드는 것입니다.

13장 AES 전환에서 먼저 해야 할 것은 데이터 조사다#

AES 코드를 만드는 것부터 시작하면 안 됩니다.

먼저 현재 어디에서 DES·3DES가 사용되는지 찾아야 합니다.

원문은 전환 대상을 운영 DB에만 한정하지 않습니다.

다음까지 조사해야 합니다.

운영 데이터베이스
외부 연계 파일
배치 작업
시험 데이터
장기 백업

이 부분을 놓치면 운영 시스템만 전환한 뒤 몇 년 후 백업 복구 과정에서 문제가 발생할 수 있습니다.

14장 암호 데이터는 생각보다 여러 곳에 존재한다#

실제 시스템 구조를 생각해보겠습니다.

flowchart TB
    APP[업무 시스템]

    DB[(운영 DB)]
    BATCH[배치]
    FILE[외부 연계 파일]
    TEST[(시험 데이터)]
    BACKUP[(장기 백업)]

    APP --> DB
    APP --> BATCH
    APP --> FILE

    DB --> BACKUP
    DB --> TEST

DES·3DES 사용 여부를 조사할 때 애플리케이션 코드 한 곳만 검색해서는 부족할 수 있습니다.

15장 외부 연계 시스템도 반드시 확인해야 한다#

내부 시스템은 AES로 전환했는데 외부 기관이나 오래된 장비가 여전히 특정 형식을 요구할 수 있습니다.

예:

내부 시스템
→ AES

외부 연계
→ 기존 3DES 형식 요구

이런 상황에서는 단순 알고리즘 교체가 아니라 인터페이스 전환 계획이 필요합니다.

외부 연계까지 조사해야 한다는 원문의 지적이 중요한 이유입니다.

16장 장기 백업이 특히 어렵다#

운영 DB를 모두 재암호화했다고 하겠습니다.

하지만 5년 전 백업에 3DES 암호문이 남아 있다면 어떻게 될까요?

해당 백업을 복원할 가능성이 있다면 과거 데이터를 읽을 수 있는 방법이 필요할 수 있습니다.

그래서 원문은 백업에 남은 암호문까지 전환 범위에 포함해야 한다고 설명합니다.

17장 데이터 형식을 자동으로 추측하면 위험하다#

오래된 시스템에서는 다음과 같은 코드가 생기기 쉽습니다.

이 길이면 DES겠지?

복호화가 실패하면 AES로 시도하자.

특정 문자열로 시작하면 3DES로 판단하자.

이 방식은 위험합니다.

원문은 오래된 데이터의 형식을 자동으로 추측하는 것보다 버전 표식을 사용하는 것이 좋다고 설명합니다.

18장 암호문에 버전 정보를 두는 이유#

예를 들어 암호화 데이터의 형식을 다음처럼 설계할 수 있습니다.

version
algorithm
mode
key_version
nonce
tag
ciphertext

개념적인 예는 다음과 같습니다.

version = 2
algorithm = AES
mode = GCM
key_version = 7
nonce = ...
tag = ...
ciphertext = ...

그러면 애플리케이션은 암호문의 구조를 추측할 필요가 없습니다.

19장 버전 표식으로 복호화 경로를 선택한다#

flowchart TB
    DATA[암호 데이터]

    VER{버전 확인}

    V1[Legacy 복호화]
    V2[새 암호 복호화]

    DATA --> VER

    VER -->|v1| V1
    VER -->|v2| V2

원문에서 설명하듯 이 방법은 복호화 실패와 잘못된 키 선택을 줄이는 데 도움이 됩니다.

20장 알고리즘만 기록해서도 부족하다#

원문은 암호문 형식에 다음을 기록하도록 권장합니다.

알고리즘
모드
키 버전

예를 들어 단순히:

AES

라고만 기록하면 부족할 수 있습니다.

실제 복호화에는 어떤 모드와 어떤 키가 사용되었는지 알아야 하기 때문입니다.

21장 키 버전은 왜 필요한가#

마이그레이션 과정에서는 여러 키가 공존할 수 있습니다.

예:

DES Key A
3DES Key B
AES Key v1
AES Key v2

데이터마다 어떤 키가 사용되었는지 모르면 복호화가 어렵습니다.

flowchart LR
    DATA[암호문]
    ID[Key Version]
    STORE[Key Store]
    KEY[해당 키]

    DATA --> ID --> STORE --> KEY

따라서 데이터와 키를 연결하는 식별 체계가 중요합니다.

22장 실제 비밀키와 키 식별자는 다르다#

암호문에:

key_version = 4

를 기록하는 것과 실제 비밀키를 암호문 옆에 저장하는 것은 전혀 다릅니다.

키 식별자
→ 어떤 키를 사용했는지 알려주는 정보

비밀키
→ 실제 암호화·복호화에 사용되는 비밀값

실제 키는 적절한 통제 영역에 보관해야 합니다.

23장 새로운 암호 형식은 AEAD를 고려한다#

원문에서는 쓰기 경로를 새 AEAD 형식으로 전환하는 예를 제시합니다.

AEAD는 암호화와 함께 데이터 무결성 검증을 제공하도록 설계된 암호 사용 방식입니다.

개념적으로:

flowchart LR
    P[평문]
    A[AEAD 암호화]
    C[암호문]
    T[인증 태그]

    P --> A
    A --> C
    A --> T

레거시 전환에서는 단순히 DES를 AES로 이름만 바꾸는 것이 아니라 현대적인 암호 사용 방식 전체를 설계하는 것이 중요합니다.

24장 마이그레이션 전에 샘플 데이터를 먼저 검증한다#

대규모 재암호화를 바로 실행하는 것은 위험합니다.

원문에서는 적용 전 다음을 검증하도록 권장합니다.

샘플 복호화

샘플 재암호화

장애 복구

예를 들어 먼저 적은 수의 데이터를 선택합니다.

flowchart LR
    OLD[Legacy Sample]
    DEC[기존 키로 복호화]
    VERIFY[평문 검증]
    ENC[새 방식 재암호화]
    CHECK[복호화 재검증]

    OLD --> DEC --> VERIFY --> ENC --> CHECK

이 과정을 통과한 뒤 전체 데이터로 확대하는 편이 안전합니다.

25장 재암호화는 단순 UPDATE 작업이 아니다#

예를 들어 DB에 백만 건의 암호 데이터가 있다고 하겠습니다.

다음처럼 생각하기 쉽습니다.

전체 조회
↓
복호화
↓
AES 암호화
↓
UPDATE

하지만 중간에 장애가 발생하면 문제가 됩니다.

30만 건 완료
↓
프로세스 중단
↓
어디까지 했는지 모름

따라서 재암호화 작업 자체도 장애를 고려해 설계해야 합니다.

26장 진행 기록이 필요한 이유#

원문은 재암호화 도중 중단되어도 다시 시작할 수 있도록 진행 기록을 설계해야 한다고 설명합니다.

예를 들면 다음 상태를 관리할 수 있습니다.

대상 ID
기존 버전
새 버전
마이그레이션 상태
완료 시간
검증 결과

구조적으로:

flowchart LR
    WAIT[대기]
    RUN[변환 중]
    VERIFY[검증]
    DONE[완료]
    FAIL[실패]

    WAIT --> RUN
    RUN --> VERIFY
    VERIFY --> DONE
    RUN --> FAIL
    VERIFY --> FAIL
    FAIL --> RUN

실패한 데이터만 다시 처리할 수 있어야 합니다.

27장 무결성 검증도 함께 해야 한다#

재암호화 프로그램이 오류 없이 끝났다고 해서 데이터가 정상이라는 보장은 없습니다.

확인해야 할 것은:

기존 데이터 정상 복호화

새 데이터 정상 암호화

새 데이터 재복호화

원본과 결과 일치

입니다.

원문도 재암호화 작업에 무결성 확인을 함께 설계해야 한다고 설명합니다.

28장 재암호화 전체 흐름#

flowchart TB
    A[Legacy 데이터 조회]
    B[형식·Key ID 확인]
    C[기존 방식 복호화]
    D[평문 검증]
    E[새 AEAD 암호화]
    F[새 형식 저장]
    G[재복호화·무결성 검증]
    H[완료 기록]

    A --> B --> C --> D --> E --> F --> G --> H

어느 단계에서 실패했는지 기록할 수 있어야 재시작과 문제 해결이 쉬워집니다.

29장 데이터 전체를 한 번에 바꾸지 않아도 된다#

시스템 규모에 따라 단계적인 전환이 가능합니다.

예:

1단계#

신규 암호화에서 DES·3DES 사용 중단

2단계#

읽기 경로에서 Legacy + New 지원

3단계#

사용 빈도가 높은 데이터부터 재암호화

4단계#

배치로 나머지 데이터 전환

5단계#

백업과 외부 연계 정리

6단계#

Legacy 키 폐기 검토

이 접근은 시스템 중단 위험을 줄이는 데 도움이 됩니다.

30장 읽을 때 자동 마이그레이션하는 방법도 생각할 수 있다#

개념적으로 레거시 데이터를 읽었을 때:

Legacy 데이터 발견
↓
복호화
↓
새 방식으로 다시 암호화
↓
저장

하는 방법도 생각할 수 있습니다.

sequenceDiagram
    participant A as Application
    participant D as Database

    A->>D: 데이터 요청
    D-->>A: Legacy 암호문
    A->>A: Legacy 복호화
    A->>A: 새 형식 암호화
    A->>D: 새 암호문 저장

다만 원문은 특정 마이그레이션 패턴을 강제하지 않으므로 실제 적용에서는 트랜잭션·성능·오류 처리 조건을 별도로 설계해야 합니다.

31장 백그라운드 배치 재암호화도 가능하다#

많은 데이터가 존재한다면 별도의 배치 프로세스로 이동할 수도 있습니다.

flowchart LR
    DB[(Legacy DB)]
    JOB[Migration Job]
    KEYOLD[Legacy Key]
    KEYNEW[New Key]
    NEW[(Migrated Data)]

    DB --> JOB
    KEYOLD --> JOB
    KEYNEW --> JOB
    JOB --> NEW

이때 핵심은 원문이 강조하는 것처럼 재시작 가능성과 검증 가능성입니다.

32장 오래된 키를 바로 삭제하면 안 되는 이유#

새 암호 방식으로 쓰기 경로를 전환했다고 즉시 레거시 키를 지워버리면 문제가 생길 수 있습니다.

아직 다음 데이터가 남아 있을 수 있기 때문입니다.

전환하지 않은 DB 레코드
장기 백업
외부 연계 파일
시험 데이터
과거 보관 자료

이 중 하나라도 읽어야 한다면 Legacy 키가 필요할 수 있습니다.

33장 그렇다고 오래된 키를 영원히 유지해서도 안 된다#

반대로 모든 Legacy 키를 무기한 보관하면 공격 표면과 운영 부담이 늘어날 수 있습니다.

그래서 원문은 재암호화 완료 후 오래된 키에 대해 보존·폐기 정책을 적용하도록 설명합니다.

즉:

무조건 즉시 삭제

도 아니고:

영구 보존

도 아닙니다.

데이터 보존 정책과 복구 요구를 기준으로 판단해야 합니다.

34장 키 폐기 전에 확인할 것#

레거시 키를 폐기하기 전에 최소한 다음과 같은 질문이 필요합니다.

모든 운영 데이터가 전환됐는가?

외부 연계에 레거시 암호문이 남아 있는가?

백업 데이터는 어떻게 처리할 것인가?

법적·업무상 장기 보존 데이터가 있는가?

복구 테스트가 완료됐는가?

하나라도 남아 있다면 키 폐기 시점을 다시 검토해야 할 수 있습니다.

35장 백업 전략과 키 전략은 함께 설계해야 한다#

암호화된 백업이 있어도 해당 키가 없으면 복원하지 못할 수 있습니다.

반대로 백업과 비밀키를 아무 통제 없이 같은 곳에 보관하면 보안 위험이 커질 수 있습니다.

따라서:

flowchart TB
    BACKUP[암호화 백업]
    KEY[복호화 키]
    POLICY[보존·복구 정책]

    BACKUP --> POLICY
    KEY --> POLICY

백업 보존기간과 키 보존기간을 함께 고려해야 합니다.

36장 3DES 키를 자주 교체하면 계속 사용할 수 있을까#

원문의 FAQ는 이 질문에 명확하게 답합니다.

키 교체는 누적 사용량을 제한하는 데 도움을 줄 수 있습니다.

하지만 알고리즘 자체의 기본 한계와 정책상 제한을 없애지는 못합니다.

즉:

키 교체
=
3DES를 현대 암호로 만들어주는 것

은 아닙니다.

지원되는 현대 암호 체계로 전환하는 계획이 필요합니다.

37장 단순히 DES를 AES로 문자열 치환해서는 안 된다#

기존 코드가 다음과 같다고 하겠습니다.

DES

를 찾아:

AES

로 바꾸는 것은 마이그레이션이 아닙니다.

실제로는 다음이 모두 달라질 수 있습니다.

키 길이
키 저장 방식
운영 모드
Nonce
인증 태그
암호문 형식
메타데이터
오류 처리

따라서 알고리즘 이름의 교체보다 암호 데이터 형식의 세대 교체로 보는 편이 적절합니다.

38장 암호 민첩성 관점으로 설계하면 다음 전환이 쉬워진다#

이번에는 3DES에서 AES로 전환한다고 하겠습니다.

하지만 앞으로도 암호 정책이나 시스템 요구가 바뀔 수 있습니다.

따라서 암호문 형식을:

version
algorithm
mode
key_version
...

처럼 명시하면 향후 전환에 유리합니다.

flowchart LR
    V1[Legacy v1]
    V2[AES v2]
    V3[향후 암호 형식 v3]

    V1 --> V2 --> V3

한 알고리즘을 영원히 고정하는 것보다 변경 가능성을 구조에 반영하는 접근입니다.

39장 실제 마이그레이션 계획 예제#

가상의 서비스가 있다고 하겠습니다.

현재:

고객 데이터
3DES

신규 서비스
AES 기반 형식 도입 예정

장기 백업
3DES 데이터 존재

전환 절차를 다음처럼 구성할 수 있습니다.

flowchart TB
    A[DES·3DES 사용처 조사]
    B[데이터 형식·Key ID 수집]
    C[신규 3DES 암호화 중단]
    D[새 AEAD 쓰기 적용]
    E[Legacy 읽기 유지]
    F[샘플 재암호화 검증]
    G[전체 데이터 단계적 전환]
    H[백업·외부 연계 검토]
    I[잔존 Legacy 확인]
    J[오래된 키 보존·폐기]

    A --> B --> C --> D --> E --> F --> G --> H --> I --> J

이것이 단순 알고리즘 교체보다 현실적인 전환 흐름입니다.

40장 단계 1: DES·3DES 사용처를 전부 찾는다#

검색 대상은 코드만이 아닙니다.

애플리케이션 코드
DB 컬럼
배치 스크립트
외부 연계
파일 저장소
백업
테스트 데이터
키 저장소

원문이 운영 데이터베이스 외에도 외부 연계·배치·시험 데이터·백업을 조사하도록 요구하는 이유입니다.

41장 단계 2: 데이터 형식과 키 식별자를 수집한다#

원문은 전환 작업에서 가장 먼저 데이터 형식과 키 식별자를 수집하도록 제안합니다.

예를 들어 조사표를 만들 수 있습니다.

대상	암호 방식	Key ID	신규 쓰기	재암호화
고객 DB	3DES	K01	중단 필요	필요
배치 파일	3DES	K02	중단 필요	필요
장기 백업	DES	K03	없음	정책 검토
신규 데이터	AES	K10	사용	해당 없음

이런 목록이 있어야 전환 범위를 파악할 수 있습니다.

42장 단계 3: 신규 레거시 암호 생성을 먼저 막는다#

가장 먼저 해야 할 중요한 조치입니다.

flowchart LR
    OLDWRITE[DES·3DES 신규 쓰기]
    STOP[중단]
    NEWWRITE[새 암호 형식]

    OLDWRITE --> STOP --> NEWWRITE

기존 데이터 전체를 변환하는 데 시간이 걸리더라도 새 레거시 데이터가 더 이상 증가하지 않게 할 수 있습니다.

43장 단계 4: Legacy 읽기는 임시로 유지한다#

쓰기 경로를 바꾼다고 해서 과거 데이터가 즉시 사라지는 것은 아닙니다.

따라서 일정 기간:

v1
→ Legacy decrypt

v2
→ New decrypt

같은 구조가 필요할 수 있습니다.

중요한 것은 이것이 영구적인 Legacy 지원이 아니라 전환 단계라는 점입니다.

44장 단계 5: 일부 데이터로 복구까지 검증한다#

샘플 데이터에서 다음을 확인합니다.

Legacy 복호화 성공

새 방식 재암호화 성공

재복호화 후 원본 동일

오류 발생 시 복구 가능

중단 후 다시 시작 가능

원문 역시 샘플 복호화·재암호화와 장애 복구를 적용 전에 검증하라고 요구합니다.

45장 단계 6: 전체 데이터를 단계적으로 전환한다#

전체 DB를 한 트랜잭션으로 처리하기보다 환경에 맞춰 작은 단위로 나눌 수 있습니다.

예:

1,000건 처리
↓
검증
↓
진행상태 기록
↓
다음 1,000건

대용량 데이터에서는 이런 접근이 장애 복구와 운영 부하 관리에 유리할 수 있습니다.

46장 단계 7: 백업까지 확인한다#

현재 DB가 전부 AES로 바뀌었다고 마이그레이션 완료를 선언하면 안 됩니다.

원문에 따라 다음까지 확인합니다.

백업
외부 파일
배치
시험 데이터

레거시 암호문이 남아 있는 위치를 정확히 파악해야 합니다.

47장 단계 8: 마지막으로 Legacy 키 정책을 적용한다#

모든 전환이 끝난 뒤:

어떤 키는 폐기

어떤 키는 일정 기간 보존

어떤 키는 장기 백업 때문에 별도 보관

같은 정책을 적용할 수 있습니다.

키의 생명주기도 마이그레이션의 일부입니다.

48장 DES·3DES 마이그레이션에서 흔히 하는 실수#

신규 3DES 암호화를 계속 허용한다#

레거시 데이터가 계속 증가합니다.

운영 DB만 조사한다#

백업·배치·연계 파일을 놓칠 수 있습니다.

암호문 형식을 자동 추측한다#

잘못된 복호화 방식이나 키를 선택할 수 있습니다.

AES라는 정보만 저장한다#

모드와 키 버전을 알 수 없게 될 수 있습니다.

전체 데이터를 한 번에 재암호화한다#

중간 장애에서 복구가 어려워질 수 있습니다.

재암호화 성공 여부만 보고 끝낸다#

복호화와 무결성 검증이 필요합니다.

전환 직후 Legacy 키를 전부 삭제한다#

남은 백업 데이터를 복호화하지 못할 수 있습니다.

49장 마이그레이션 체크리스트#

조사#

DES·3DES 사용 코드를 찾았는가
운영 DB를 확인했는가
외부 연계를 확인했는가
배치 작업을 확인했는가
테스트 데이터를 확인했는가
장기 백업을 확인했는가

데이터 형식#

알고리즘 정보가 있는가
모드가 기록되어 있는가
키 버전이 있는가
Legacy와 신규 형식을 구분할 수 있는가

전환#

신규 Legacy 쓰기를 중단했는가
신규 암호 형식을 적용했는가
Legacy 읽기가 필요한 범위를 정했는가
샘플 재암호화를 검증했는가
중단 후 재시작 가능한가

검증#

복호화 결과가 정상인가
재암호화 결과가 정상인가
무결성을 확인했는가
장애 복구를 테스트했는가

키#

Legacy Key ID를 파악했는가
백업 복원을 고려했는가
보존기간을 정했는가
폐기 조건을 정했는가

50장 DES·3DES FAQ#

DES는 왜 레거시인가#

원문에서는 DES가 56비트 유효 키를 사용하는 오래된 블록 암호라고 설명합니다. 현대 시스템에서 사용하기에는 키 공간 등의 한계가 있습니다.

3DES는 DES보다 강한데 왜 레거시인가#

DES 연산을 반복해 보완했지만 작은 64비트 블록, 성능과 보안상의 한계가 있으며 신규 시스템에서 선택할 이유가 약합니다.

3DES의 키는 168비트 아닌가#

세 키의 길이를 합친 숫자와 실제 보안 강도를 동일하게 해석해서는 안 된다고 원문에서 설명합니다.

3DES 키를 자주 바꾸면 계속 사용해도 되나#

키 교체는 누적 사용량 제한에는 도움이 될 수 있지만 알고리즘의 구조적 한계나 정책상 제한을 없애지는 못합니다.

기존 3DES 데이터도 즉시 읽지 못하게 해야 하나#

원문은 기존 데이터 읽기와 신규 데이터 생성을 분리하는 전략을 제시합니다. 일정 기간 Legacy 읽기를 지원하면서 신규 쓰기를 새로운 형식으로 전환할 수 있습니다.

암호 알고리즘은 데이터만 보고 자동 판단하면 안 되나#

원문에서는 자동 추측보다 명시적인 버전 표식을 사용하는 것이 복호화 실패와 잘못된 키 선택을 줄이는 데 도움이 된다고 설명합니다.

AES로 전환할 때 DB만 바꾸면 되는가#

아닙니다. 외부 연계 파일·배치·시험 데이터·장기 백업도 조사해야 합니다.

재암호화 작업이 중간에 실패하면 어떻게 하나#

원문은 중단 후 다시 시작할 수 있도록 진행 기록을 만들고 무결성 검증을 설계하도록 제안합니다.

Legacy 키는 언제 삭제할 수 있나#

재암호화 완료 후에도 백업과 장기 보존 데이터 등의 복호화 요구를 확인한 뒤 보존·폐기 정책을 적용해야 합니다.

핵심 정리#

DES와 3DES에서 AES 같은 현대적인 암호 체계로 전환할 때 가장 중요한 것은 단순히 알고리즘 이름을 변경하는 것이 아닙니다.

먼저 다음을 구분해야 합니다.

기존 데이터 읽기
≠
새 데이터 암호화

신규 쓰기는 가능한 한 새로운 암호 형식으로 전환하면서 기존 데이터는 필요한 기간 동안 읽을 수 있도록 관리합니다.

전체적인 전환 흐름은 다음과 같습니다.

flowchart LR
    A[Legacy 사용처 조사]
    B[형식·Key ID 확인]
    C[신규 Legacy 암호화 중단]
    D[새 암호 형식 적용]
    E[기존 데이터 재암호화]
    F[백업·외부 연계 확인]
    G[검증]
    H[Legacy 키 보존·폐기]

    A --> B --> C --> D --> E --> F --> G --> H

특히 원문이 강조하는 세 가지 원칙은 중요합니다.

신규 암호화와 레거시 복호화 용도를 분리한다.

알고리즘·모드·키 버전을 암호문 형식에 기록한다.

샘플 복호화·재암호화와 장애 복구를 검증한다.

그리고 마이그레이션 범위는 운영 DB 하나가 아닙니다.

운영 데이터
외부 연계
배치
시험 데이터
백업
키 저장소

전체를 함께 살펴야 합니다.

결국 DES·3DES의 레거시 전환에서 가장 어려운 부분은 새로운 암호 알고리즘을 호출하는 코드가 아닙니다.

어떤 데이터가 어떤 키와 형식으로 암호화되어 있는지 정확히 파악하고, 신규 레거시 생성을 중단하며, 기존 데이터를 검증 가능하고 재시작 가능한 방식으로 옮기고, 마지막에 오래된 키까지 안전하게 정리하는 것이 실제 마이그레이션의 핵심입니다.