자동화를 생활화 합시다. — Online DDL 테스트 자동화 이야기

안녕하세요, 여기어때컴퍼니 SRE팀 인턴 제이드입니다.

오늘은 제가 여기어때컴퍼니에 인턴으로 합류하게 된 이후에 진행했던 주요 프로젝트 중 하나인 ‘온라인 DDL 테스트 자동화 프로젝트’에 대해 이야기하려고 합니다.

본격적으로 프로젝트를 소개하기에 앞서, 온라인 DDL이라는 개념이 익숙하지 않으신 분들을 위해 간단히 개념부터 설명드리겠습니다.

출처: Chat GPT 제작 이미지

온라인 DDL이란?

온라인 DDL(Online Data Definition Language)은 데이터베이스의 테이블 구조를 변경하거나, 인덱스를 추가하거나 삭제하거나, 컬럼을 수정하는 작업을 서비스 중단 없이 수행할 수 있는 방식입니다. 이러한 기능은 24시간 운영되는 서비스에서 데이터베이스 작업으로 인한 다운 타임을 방지하기 위해 필수적입니다. 참고로 저희가 사용하는 Amazon Aurora MySQL에서는 온라인 DDL이 기본적으로 활성화되어 있어, 스키마 변경 작업 시 적절한 알고리즘을 자동으로 선택해줍니다.

온라인 DDL 작업을 실행하기 위해서는 작업 방식에 따라 Instant, Inplace, Copy라는 세 가지 알고리즘 중 하나가 사용됩니다. 이 알고리즘들은 각각 작업 시간과 데이터베이스 리소스 소모 측면에서 차이를 보이며, 작업 성격에 따라 적합한 방식이 선택됩니다.

Instant 알고리즘은 테이블의 메타데이터만 수정하여 작업을 완료하는 방식입니다. 데이터 자체에는 전혀 영향을 주지 않기 때문에 가장 빠르고 리소스를 거의 사용하지 않습니다. 메타데이터는 테이블의 구조나 속성을 정의하는 정보로, 테이블 이름, 열의 정보, 기본값 등이 포함됩니다. 예를 들어, 테이블에 새로운 열(column)을 추가하거나 열의 기본값을 변경하는 작업이 Instant 알고리즘으로 처리됩니다. 데이터 복사가 없기 때문에 테이블 락이 발생하지 않으며, 서비스에 미치는 영향도 없습니다.

Inplace 알고리즘은 기존 데이터를 복사하지 않고, 데이터를 유지한 상태에서 작업을 수행합니다. 예를 들어, 테이블에 새로운 열을 추가하되 기존 데이터에 기본값을 적용하거나 열의 데이터 타입을 변경하지 않는 작업이 해당됩니다. 데이터 복사가 없기 때문에 Copy 알고리즘보다 리소스를 적게 사용하며, 작업 도중 일부 락이 발생할 수 있지만 테이블 전체가 잠기지는 않아 서비스에 미치는 영향이 최소화됩니다. Inplace 알고리즘은 작업 성능과 안정성을 동시에 고려해야 하는 경우에 적합한 방식입니다.

Copy 알고리즘은 원본 데이터를 새로운 테이블로 복사한 후, 변경 사항을 적용하는 방식으로 동작합니다. 작업 완료 후 기존 테이블은 삭제되고 새로 복사된 테이블이 원본 테이블을 대체하게 됩니다. 이 과정은 데이터의 양에 따라 시간이 오래 걸리고, 스토리지와 I/O 리소스를 많이 사용하게 됩니다. 특히, 대량의 데이터나 트래픽이 많은 환경에서는 성능 저하가 발생할 수 있으므로 신중하게 사용해야 합니다. Copy 알고리즘은 데이터 구조와 내용에 모두 영향을 주는 복잡한 작업에 사용됩니다.

이 세 가지 알고리즘은 작업 성격과 데이터베이스의 상황에 따라 자동으로 선택되지만, 서비스 성능과 작업 효율성을 극대화하기 위해서는 적절한 알고리즘을 미리 선정하여 작업해야 합니다.

온라인 DDL 테스트 자동화 이유

출처: Chat GPT 제작 이미지

위에서 언급했듯이 Aurora MySQL에서는 별도의 알고리즘을 지정하지 않더라도 Instant → Inplace → Copy 순서로 자동으로 최적의 알고리즘을 찾아 적용합니다. 덕분에 사용자는 알고리즘 선택에 신경 쓰지 않아도 됩니다.

그러나 상용 환경에서 작업을 수행할 때는 알고리즘을 명시적으로 지정하는 것이 권장됩니다. 최적의 알고리즘을 미리 선정하여 실행 시간을 최소화하고 서비스에 미치는 영향을 줄여야 자동 알고리즘 선택 과정에서 불필요한 연산이 추가되는 것을 방지할 수 있기 때문입니다.

또한, DDL이 온라인 DDL로 실행 가능한지 레퍼런스를 일일이 확인하는 것은 번거롭기 때문에, 사전에 알고리즘을 선정하여 불필요한 Cost를 줄이는 것이 효과적입니다.

그리고 상용 환경에 온라인 DDL을 적용하기 전에는 반드시 테스트 환경에서 작업을 사전 검증해야 합니다. 온라인 DDL 작업 시 소요 시간, 데이터 무결성 유지 여부, 작업 후 서비스 안정성 등을 미리 파악해야 상용 환경에서 발생할 수 있는 리스크를 최소화할 수 있기 때문입니다. 이를 통해, 작업 실패나 성능 저하로 인한 서비스 장애를 예방할 수 있습니다.

온라인 DDL은 서비스 중단 없이 데이터베이스 스키마를 변경할 수 있는 강력한 기능이지만, 알고리즘 선정과 작업 검증 과정을 통해 신중히 적용해야만 상용 환경에서의 안정성을 보장할 수 있습니다. 이러한 알고리즘 선정과 작업 검증 과정을 자동화 시키는 것이 이번 온라인 DDL 테스트 자동화 프로젝트 입니다.

프로젝트 목표

출처: Chat GPT 제작 이미지

참고로, 본 프로젝트는 DB 시스템 운영 권한이 있는 SRE팀 내 DBA 파트에서 진행하였습니다.

이번 온라인 DDL 테스트 자동화 프로젝트의 주요 목표는 다음과 같습니다.

직접 온라인 DDL 테스트를 진행하는 것이 아니라 자동화된 테스트가 가능하도록 합니다.

온라인 DDL을 적용하고자 하는 타겟 클러스터를 복제하여 테스트 환경을 구성하고, 복제된 클러스터에 온라인 DDL을 사전 적용하여 최적의 알고리즘을 도출합니다.

이 과정에서 온라인 DDL 작업의 소요 시간, 기존 테이블의 메타데이터, 그리고 작업 후 변경된 테이블의 메타데이터를 수집합니다. 수집된 데이터는 별도로 구성된 히스토리 테이블에 저장되며, 이를 통해 이후 상용 환경에서 같은 온라인 DDL 작업의 알고리즘 최적화와 예측이 가능하도록 합니다.

웹 서비스를 통해 온라인 DDL 테스트 서비스가 가능하도록 합니다.

온라인 DDL 테스트를 보다 효율적으로 수행하기 위해 웹 기반 서비스를 구축하여 테스트 환경을 제공합니다. 이 웹 서비스는 사용자 친화적인 인터페이스를 통해 온라인 DDL 테스트를 쉽게 설정하고 실행할 수 있도록 합니다.

사용자는 간단한 선택과 입력만으로 타겟 클러스터를 복제하고, 사전 정의된 테스트 절차에 따라 온라인 DDL 작업을 실행할 수 있습니다. 이를 통해 DDL 테스트 프로세스를 표준화하고, 사용자들이 손쉽게 테스트 작업을 관리할 수 있도록 합니다.

여러 DBA들이 진행한 테스트 내역들을 공유할 수 있도록 합니다.

여러 DBA들이 진행한 온라인 DDL 테스트 내역을 효과적으로 관리하고 공유할 수 있도록 이전의 온라인 DDL 작업 내역들에 관한 히스토리 기능을 제공합니다. 모든 테스트 작업의 실행 내역과 결과는 별도의 데이터베이스에 저장되며, 이를 웹 서비스를 통해 팀원들이 손쉽게 확인할 수 있도록 합니다.

저장된 데이터는 자동으로 매핑되어 작업 소요 시간, 리소스 사용량, 테이블 변경 내역 등을 포함한 리포트 형태로 제공되며, 이를 통해 테스트 결과를 한눈에 파악할 수 있습니다. 이러한 기능은 테스트 결과에 기반한 의사 결정을 더욱 명확하고 신속하게 만들어 작업 승인 절차를 간소화하는 데 도움을 줍니다.

온라인 DDL 테스트 알림이 Slack 채널을 통해 실시간으로 전송하도록 합니다.

온라인 DDL 테스트의 진행 상황과 결과를 실시간으로 공유하기 위해 Slack 알림 기능을 구현하였습니다. 테스트가 시작되면 해당 작업의 정보를 Slack 채널로 전송하고, 작업 완료 시 결과와 주요 데이터를 포함한 요약 정보를 알림으로 제공합니다.

이를 통해 DBA들은 테스트 상황을 실시간으로 모니터링 할 수 있으며, 작업 실패나 성능 이슈가 발생할 경우 빠르게 대응할 수 있습니다. Slack 알림을 통해 테스트 작업의 가시성을 높이고, 팀 내 협업에 도움을 줄 수 있도록 하였습니다.

사용 기술 스택

이번 프로젝트에서는 백엔드 서버로 Flask를 사용하여 간결하면서도 확장성 높은 RESTful API를 구현했습니다. 입사 전에는 주로 Spring Boot를 활용해 백엔드 서버를 구축했지만, SRE팀에서는 파이썬을 주로 사용해 업무 관련 도구들을 개발하고 있어 유지보수의 편의성을 고려해 파이썬을 선택했습니다. 또한, 파이썬의 빠른 개발 속도와 다양한 라이브러리를 활용할 수 있는 점을 감안해 Flask로 백엔드 서버를 구축했습니다.

데이터베이스로는 기존 여기어때컴퍼니에서 사용하고 있던 Amazon Aurora MySQL을 사용하여 구축하였으며, 실시간 작업 데이터와 히스토리 데이터를 안정적으로 관리할 수 있도록 설계하였습니다. 프론트엔드는 HTML/CSS를 활용하여 사용자 친화적인 인터페이스를 제공하였으며, 직관적으로 기능을 구현했습니다.

데이터베이스 구축 내용

데이터베이스는 Amazon Aurora MySQL을 통해 구축하였습니다.

processList

현재 실행하고 있는 온라인 DDL 작업 정보를 저장하는 테이블입니다. 테스트 대상이 되는 인스턴스(TargetDB)의 endPoint, DDL 작업의 processId, DDL문 등이 저장됩니다.

ddlHistory

테스트를 완료한 온라인 DDL 작업들의 히스토리를 저장하는 테이블입니다. 온라인 DDL 테스트 작업에 소요된 시간, 테스트 날짜, DDL문, TargetDB, 적용 알고리즘 등과 같은 테스트와 관련된 내용들이 포함됩니다.

주요 동작 방식

해당 프로젝트가 어떠한 방식으로 동작하고 있는지 간단히 살펴보겠습니다. 사용자는 해당 웹 사이트에 접속하여 서비스를 이용하게 되고, 웹사이트로 보내지는 모든 사용자의 요청은 Flask API Server로 보내지게 되고 해당 서버로부터 응답을 받게 됩니다. 또한 히스토리 기능과 같이 DB 연동이 필요한 기능 같은 경우에는 Flask API Server가 Amazon Aurora와 통신하여 필요한 값들을 가져오게 됩니다.

주요 구현 기능 내용

제가 해당 프로젝트에서 구현한 주요 기능들에 대해서 설명드리도록 하겠습니다. 설명드릴 기능은 테스트 기능, 테스트 과정 슬랙 알림 전송 기능, 실시간 작업 리스트 표시 기능, 취소 기능, 히스토리 기능입니다.

먼저, 테스트 기능부터 설명드리겠습니다.

• 테스트 기능

폼 작성 후 사용자는 테스트 버튼을 클릭하여 테스트 시작

1번에서 선택한 인스턴스에 존재하는 DB 리스트가 출력이되고, 각 DB의 사이즈도 확인 가능

사용자는 주어진 폼을 작성하여 온라인 DDL 테스트를 할 수 있습니다. 또한 모든 API는 비동기로 동작하도록 구현하였기 때문에 여러 테스트를 동시에 진행할 수 있도록 하였습니다. 폼 내부의 각 요소에 대해 설명 드리겠습니다.

1.TargetDB 인스턴스를 선택하세요

온라인 DDL을 적용할 데이터베이스가 위치한 인스턴스를 선택합니다. 사용자는 제공된 인스턴스 리스트에서 해당 DB가 존재하는 인스턴스를 선택하면 됩니다.

2.테스트를 적용할 TargetDB명을 선택하세요.

온라인 DDL 테스트를 실행할 데이터베이스를 선택합니다. 1번에서 선택한 인스턴스 내에 존재하는 데이터베이스 리스트가 표시되며, 여기서 원하는 DB를 선택하면 됩니다. 또한 위의 사진에서도 볼 수 있듯이 리스트의 각 DB사이즈도 확인할 수 있어서 작업 대상 데이터베이스의 크기를 사전에 파악할 수 있습니다. 이를 통해 작업에 필요한 예상 리소스를 추정할 수 있으며, 대규모 데이터베이스의 테스트 작업을 신중하게 계획하는 데 도움이 될 수 있도록 하였습니다.

3.입력하신 TargetDB의 정보를 이용하여 클론을 생성하시겠습니까?

클론을 생성하여 테스트를 할 지 선택합니다. 클론을 생성할 시 1번과 2번에서 입력한 정보를 토대로 클론을 생성하게 됩니다. 대부분의 온라인 DDL 테스트는 클론 환경에서 진행하게 되고, 클론 작업은 실제와 가장 유사한 환경에서 테스트를 하기 위해서 클러스터 단위로 클론을 생성합니다. 클론을 생성하지 않을 경우, 3.1번에서 테스트를 적용할 인스턴스를 별도로 입력해야 합니다.

3.1테스트 할 인스턴스를 선택하세요.

만약 3번에서 클론 생성을 ‘아니오’로 선택했다면, 이 옵션에서 테스트에 사용할 인스턴스를 직접 입력해야 합니다.

이는 이미 수작업(AWS 콘솔에서 직접 생성)으로 생성된 TargetDB의 클론 인스턴스를 활용하려는 경우에 해당됩니다. 이 경우, 3.1번에서 입력한 인스턴스의 TargetDB(2번에서 입력)를 대상으로 테스트가 진행됩니다.

4.실행하실 DDL 구문을 입력해주세요.

테스트를 진행하고자 하는 DDL 문들을 입력합니다. 단, 알고리즘 부분은 제외하고 입력하며, DDL 문의 끝에는 반드시 ‘;’을 추가해야 합니다. 복수의 DDL 문을 테스트할 경우, ‘;’을 기준으로 구문을 분리하여 순차적으로 TargetDB에 테스트가 진행됩니다.

• 테스트 과정 Slack 알림 기능

테스트 시작, 클론 생성 시작, 클론 생성 완료, DDL 테스트 결과 등 주요 정보를 Slack 채널에서 확인할 수 있습니다. 이를 통해 팀원들과 실시간으로 진행 상황을 공유하며, 작업 실패나 성능 이슈 발생 시 빠르게 대응할 수 있습니다.

• 실시간 작업 리스트 표시 기능

현재 진행 중인 작업이 없을 때의 홈 화면의 Executing List

현재 진행 중인 작업이 있을 때의 Executing List

processList 테이블에 존재하는 현재 진행되고 있는 온라인 DDL 테스트 작업은 화면 오른쪽 Executing List에서 확인할 수 있습니다. 또한 각 작업 별로 TargetDB 인스턴스명, 테스트 중인 DDL 문, 테스트 사용자 이름을 한눈에 파악할 수 있고, 테스트 진행 상태(클론 중, DDL 작업 중, 취소 중, …)도 한눈에 파악할 수 있습니다.

또한 목록의 각 작업을 클릭 시 작업의 실시간 DDL 진행 시간, TargetDB 정보, 클론 유무 정보 등 상세 정보를 확인할 수 있습니다.

해당 리스트에서 각 작업 클릭 시 작업 상세 정보 화면으로 이동

참고로 실시간 DDL 소요 시간 부분은 클론을 하거나 클론을 삭제하는 과정에서는 시간 측정이 안되고, 실질적인 온라인 DDL 테스트가 진행되는 동안에만 밀리세컨드 단위까지 측정이됩니다.

그리고 각 작업 항목의 오른쪽에 있는 x 버튼은 어떤 기능인지 궁금해하실 분들이 있을텐데, 해당 내용은 아래에서 설명드리겠습니다.

• 취소 기능

진행 중인 작업은 각 항목의 x 버튼을 통해 작업을 중단할 수 있습니다. 취소 요청 시, 작업이 종료되며, 관련 데이터는 히스토리 테이블에 저장되지 않습니다. 참고로 취소 작업이 완료되는 시간은 클론 생성 여부와 같은 테스트 조건에 따라 상이할 수 있습니다.

• 히스토리 기능

홈 화면에서 상단 히스토리 버튼 클릭시 히스토리 화면으로 이동합니다.

진행했던 테스트 내역들을 확인할 수 있습니다. 히스토리 목록에 표시되는 항목은 테스트 진행 날짜, 테스트 진행자, 테스트 온라인 DDL 구문이 표시됩니다. 작성자와 DDL 문을 기준으로 검색이 가능하며, 히스토리 데이터는 이후 테스트 계획 수립 시 참고 자료로 활용됩니다.

그리고 히스토리 내역이 많아질 경우, 페이지네이션 작업을 통해 페이지 단위로 확인할 수 있도록 구현하였습니다. 또한 히스토리의 각 항목을 클릭하면 테스트의 상세 정보도 확인할 수 있도록 하였습니다.

히스토리 목록의 항목 클릭 시 상세 정보로 이동

주요 기능 동작 과정

위에서 설명한 주요 기능 중 테스트 기능과 취소 기능이 구체적으로 어떠한 과정으로 동작하는지 간단히 살펴보겠습니다.

테스트 기능

주어진 폼을 입력 후 Test 버튼 클릭 시 테스트 기능 동작

실제 로직은 위 다이어그램보다 더 복잡하지만, 간단한 설명을 위해 테스트 기능의 주요 흐름만 정리하였습니다.

사용자가 테스트 버튼을 클릭하면, 폼에 입력된 내용을 기반으로 테스트가 시작되며, 작업 정보가 이미 구축되어 있는 processList 테이블에 저장됩니다. 이후, 사용자가 설정한 3번 옵션에 따라 클론을 생성하여 테스트를 진행하거나 생성하지 않고 원본 DB에 테스트를 진행하게 됩니다. 해당 단계 이후, 취소 상태가 설정되어 있는지 확인합니다. 만약 취소 상태가 설정되어 있다면, 더 이상 작업을 진행하지 않고 생성된 클론이 있을 시 삭제하며 테스트를 종료합니다.

취소 상태가 설정되지 않은 경우에는 온라인 DDL 알고리즘을 통해, 입력된 DDL 문을 실행하며 본격적인 테스트가 진행됩니다. 온라인 DDL 테스트 진행 중 취소 상태가 설정된 경우, 실행 중인 온라인 DDL 작업은 별도의 스레드에서 동작하는 취소 API 로직을 통해 Kill 명령어로 종료됩니다.

이후, 취소 상태 확인 로직을 통해 DDL 프로세스가 완전히 종료된 것을 확인한 뒤, 생성된 클론을 삭제합니다. 클론이 삭제된 후에는 prcessList에서 진행 중인 테스트 내용에 해당하는 Row를 제거 후 테스트를 종료하게 됩니다.

온라인 DDL 작업 실행 후 취소 상태가 설정되어 있지 않다면, 사용한 클론을 삭제하고 테스트 결과 내역을 히스토리 DB에 저장하게 됩니다. 그리고 processList 테이블에 해당 테스트 내용에 해당하는 Row를 제거하여 현재 작업 중인 목록(Executing List)에서 제거되게 하고, 테스트를 종료하게 됩니다.

취소 기능

각 항목의 X버튼 클릭 시 취소 기능 동작

취소 작업은 이렇게 진행됩니다. 버튼을 클릭하면 가장 먼저 그 상태가 설정되며, processList 테이블에서 이 작업의 인스턴스 endpoint를 조회한 후 테스트 진행 중인 데이터베이스에 접속합니다. 데이터베이스에서는 information_schema.processlist 테이블을 통해 현재 진행 중인 작업의 processId를 조회하게 됩니다. 만약 processId가 조회된다면, 이는 현재 실행 중인 온라인 DDL 작업이 있다는 뜻이므로 해당 프로세스를 Kill 명령어로 종료하고 취소 작업을 완료합니다. 반대로, processId가 조회되지 않는다면 그 테스트가 클론을 생성하는 작업과 같이 실질적인 온라인 DDL 작업이 아직 시작되지 않았다는 뜻이므로 취소 상태만 설정 후 추가작업 없이 종료합니다.

취소 상태가 설정된 작업은 위 테스트 기능 동작 과정에서 설명드렸듯이, 아래와 같이 테스트 기능 동작 중간 중간에 존재하는 취소 상태 확인 로직에 따라 별도로 처리 됩니다.

느낀점

이번 프로젝트에서 크게 느낀 점은 총 3가지였습니다.

첫 번째는 정확한 요구사항 수립의 중요성입니다. 프로젝트를 시작하기 전, 요구사항을 명확하게 정리하고 각 단계에서 이를 철저히 검토하는 과정이 얼마나 중요한지 깨달았습니다. 요구사항이 명확 할 수록 프로젝트의 방향성이 분명해지고, 작업 범위를 보다 체계적으로 관리할 수 있었습니다. 만약 요구사항이 명확하지 않거나 변경이 잦은 경우, 작업 중 불필요한 반복과 혼란이 발생할 수 있다는 것을 이번 경험을 통해 알게 되었습니다. 다행히 이번 프로젝트에서는 초기에 요구사항을 구체화하는 데 충분한 시간을 할애했고, 이를 통해 프로젝트 진행 중 발생할 수 있는 추가 요구사항으로 인한 프로젝트 마감이 딜레이 되는 문제 등을 사전에 방지할 수 있었습니다. 명확한 요구사항 정리는 프로젝트의 성패를 결정짓는 요소임을 다시 한 번 느끼게 된 계기였습니다.

두 번째는 API의 비동기 처리에 대한 고려입니다. 이번 프로젝트에서는 여러 테스트 작업이 동시에 진행될 수 있도록 비동기 처리를 적극적으로 활용했습니다. 주요 API는 모두 비동기로 처리하여, 여러 사용자가 동일한 사이트에서 동시에 작업을 수행하더라도 시스템 성능에 큰 영향을 주지 않도록 설계했습니다. 이를 위해 각 작업이 독립적으로 실행될 수 있도록 설계하고, 작업 간 자원 충돌을 방지하며 안정적인 처리 속도를 유지하는 데 중점을 두었습니다. 이러한 비동기 설계로 인해 시스템의 전반적인 성능과 사용성을 크게 향상시킬 수 있었습니다.

비동기 API 설계 과정에서 공유 자원 관리 문제, 스레드 상태 관리, 리소스 효율성 등을 고려하는 것이 쉽지 않았지만, 이러한 설계와 구현 과정을 통해 시스템 성능 최적화에 대한 이해도를 높일 수 있었던 기회가 되었습니다. 특히, 작업의 비동기 처리를 통해 테스트 작업의 효율성을 극대화 시킨 점은 프로젝트의 실질적인 사용성을 높이는데 큰 도움이 되었습니다.

세 번째는 팀원 간 소통과 피드백의 중요성입니다. 프로젝트를 수행하면서 팀원들과의 원활한 소통과 지속적인 피드백 교환이 얼마나 중요한지 깊이 깨달았습니다. 이번 프로젝트는 저 혼자서 진행하게 된 프로젝트임에도 불구하고, 팀원 분들이 꾸준히 제 결과물을 검토해주시고 첨언을 해주신 덕분에 프로젝트를 더 나은 방향으로 발전시킬 수 있었습니다.

특히, 서로의 의견을 공유하는 과정에서 예상치 못했던 새로운 아이디어와 해결책이 도출되었고, 이를 통해 프로젝트의 완성도를 더욱 높일 수 있었습니다. 이러한 경험은 팀원과의 소통과 피드백이 개인의 노력을 뛰어넘어 프로젝트의 전반적인 성과를 높이는 데 얼마나 중요한 역할을 하는지를 다시금 느끼게 해주었습니다.

마무리하며

이번 프로젝트를 통해 온라인 DDL 테스트 작업의 효율성을 크게 향상시킬 수 있었으며, 상용 환경에서 발생할 수 있는 Cost를 효과적으로 최소화하는 데 기여할 수 있었습니다. 또한 온라인 DDL 테스트 자동화를 통해 작업의 신뢰성을 높이는 동시에 DBA분들의 작업 시간을 절약할 수 있는 중요한 도구로 활용될 수 있었습니다.

이번 프로젝트는 기술적 성장을 이루었을 뿐만 아니라 협업 능력과 프로젝트 진행 관련 역량도 키울 수 있었던 값진 경험이었습니다. 데이터베이스 작업에서 안정성과 효율성을 동시에 추구하신다면, 온라인 DDL 테스트 과정을 꼭 자동화를 해보시길 추천드립니다. 긴 글 읽어주셔서 감사합니다! 😊