3편 : DBA가 AI로 AWS 비용절감을 위한 DMS 분석 자동화 툴 만든 썰 (feat. AWS Q Developer)

“DMS(Database Migration Service)라면 산전수전 다 겪었다고 자부했는데…”

안녕하세요. 저는 SSU(Specialty Service Unit) Data Modernization 조직에서 클라우드 DB 운영 업무를 맡고 있는 ‘데이터쟁이’ 입니다.

DMU(Data Modernization Unit)는 클라우드 데이터베이스(DB) 도입부터 운영까지  진단(Assessment), 이관(Migration), 튜닝(Tuning) 및 통합 운영 관리(MSP) 서비스를 통해 고객사의 기술적 난제를 해결하고 운영 안정성과 비용 효율화를 실현하는 전문 조직입니다.

그중 제 메인 업무는 DB 운영이지만, ‘부캐’로는 IDC에서 클라우드로의 대규모 이전(Migration) 프로젝트를 종횡무진 누비고 있습니다.

그러다 보니 자연스럽게 가장 손에 익은 도구가 바로 AWS DMS(Database Migration Service)입니다.

정말이지 안 옮겨본 DBMS가 없을 정도입니다. 이기종 간의 데이터 이동은 물론, 클라우드 RDB를 거의 실시간에 가깝게 복제해 주는 DMS의 매력에 푹 빠져 살았습니다.

“DMS라면 이제 눈 감고도 설정하지!”라고 자부하던 저였습니다.

그런데 말입니다. 

지금까지 DMS를 ‘잘 쓰는 법’만 고민했지, 이걸 ‘깊게 분석해 볼’ 생각은 미처 못 했습니다. 

그러던 어느 날, 팀장님으로부터 청천벽력 같은 미션이 떨어졌습니다.

“김 OO님, DMS를 ETL 대체 솔루션으로 쓰는 고객사가 있는데 비용이 너무 많이 나오고 연동이 스파게티 라고 합니다.. 라이트하고 심플하게 쓰고 싶어 사용 현황 및 미래의 모델에 대한 컨설팅 요청인데 이번에 모든 Account의 DMS 인스턴스 분석 보고서 부탁드립니다.”

이 메일을 받은 순간, DB 엔지니어인 제 머릿속엔 단 한 가지 생각만 스쳤습니다. ‘아… 올 것이 왔구나.’

저는 시니어 DBA입니다. SQL 튜닝이나 아키텍처 설계라면 밤새 떠들 수 있지만, 애플리케이션 개발은 신입 사원 때 1년 깨작거려본 게 전부입니다. 파이썬? import가 뭔지는 알지만, 라이브러리가 뭐고 문법이 어떻게 되는지는 전혀 모르는, 소위 ‘코알못(코딩을 알지 못하는)’ 아재죠.

그런데 이번 과제는 만만치 않았습니다. 4개 계정에 흩어진 35개 인스턴스, 190개 엔드포인트를 일일이 들어가서 확인해야 했거든요. 단순 계산으로 인스턴스 하나당 30분만 잡아도 17시간이 넘는 대장정이었습니다.

“이걸 손으로 다 하라고? 2025년에?”

단순 반복 작업을 병적으로 싫어하는 제 성격상 이건 고문이나 다름없었습니다. 그래서 결심했습니다. 요즘 핫하다는 AI에게 코딩을 시켜보기로요.

이 글은 파이썬 함수 하나 모르는 DBA가 AWS Q Developer CLI라는 AI 부사수를 데리고, 한 달 동안 지지고 볶으며 만들어낸 ‘AWS DMS 분석 보고서 자동 생성기’ 개발 기록입니다.

1. 시작: 왜 하필 ‘AI 코딩’이었나?

사실 처음부터 거창한 자동화 시스템을 만들 생각은 없었습니다. 하지만 상황을 뜯어보니 도저히 맨손으로는 안 되겠더군요. 제가 AI라는 ‘동아줄’을 잡게 된 계기는 크게 4가지였습니다.

(1) 감당 불가능한 ‘규모의 문제’

가장 큰 이유는 물리적인 양이었습니다. AWS Account 4개, DMS 인스턴스 35개. 하나하나 콘솔에 로그인해서 CloudWatch 그래프를 캡쳐하고 엑셀에 붙여넣는 일명 ‘복붙’ 작업은, 시니어 엔지니어의 자존심을 떠나 시간 낭비 그 자체였습니다.

(2) 효율성에 대한 (순진한) 기대

“반복 작업이니까 프로그램으로 짜면 금방 끝나겠지?” 당시엔 이런 순진한 생각을 했습니다. 자동화하면 시간을 획기적으로 줄일 수 있을 거라 믿었죠. (물론, 그 프로그램을 만드는 데 한 달 동안 삽질을 하게 될 줄은 꿈에도 몰랐지만요. 😅)

(3) 회사의 ‘AI Vibe’

회사 전체적으로 “AI 좀 활용해 봐라, 업무에 적용해 봐라” 하는 분위기가 형성되어 있었습니다. AI 활용을 적극 독려하는 분위기를 따라 저도 시도해보게 되었지만, 내심 ‘진짜 업무에 도움이 되나?’ 하는 의구심 반, 기대 반이었습니다.

(4) 엔지니어로서의 ‘호기심’

솔직히 가장 큰 이유는 이거였습니다. “내 도메인 지식(DB)과 AI의 코딩 실력이 만나면 뭐가 나올까?” 개발은 못 하지만 설계는 할 줄 아는 제가, 코딩 기계인 AI를 리드했을 때 어떤 시너지가 날지 궁금했습니다. 그래서 무모하지만 과감하게 ‘AI Vibe Coding’에 도전장을 내밀었습니다.

2. 이것이 바로 ‘AI Vibe Coding’이다: 코딩이 아니라 ‘티키타카’

제가 경험한 AI Vibe Coding은 단순히 “코드 좀 짜줘”라고 시키는 게 아니었습니다. 그것은 마치 손은 엄청 빠른데 경험은 부족한 신입 사원과 실시간으로 대화하며 일하는 느낌이었습니다.

(1) 문법 몰라도 OK, 논리만 있으면 된다

과거엔 파이썬으로 AWS 데이터를 가져오려면 boto3 라이브러리 문서를 뒤지며 session = boto3.Session(…)부터 막혔을 겁니다. 하지만 Vibe Coding에선 달랐습니다.

• 나의 프롬프트(Prompt) : “AWS 프로필 ‘prod-account’를 사용해서 DMS 인스턴스 목록을 가져오는 함수를 만들어줘. 리전은 ‘ap-northeast-2’야. 결과는 리스트로 반환해.”
• AI의 응답(Code) : (알아서 boto3 연결하고, describe_replication_instances API 호출하는 완벽한 파이썬 코드 생성)

저는 describe_replication_instances라는 API 이름조차 몰랐지만, 제 의도(Logic)가 코드로 변환되는 데는 10초도 걸리지 않았습니다. “어떻게(How)” 구현할지는 AI가 고민하고, 저는 “무엇을(What)” 만들지만 고민하면 되는 것이죠.

(2) 속도감 있는 ‘티키타카’ (The Rhythm)

코딩하다가 에러가 나면 구글링하느라 30분을 날리던 시절은 끝났습니다. 에러가 발생하면 에러 로그를 그대로 AI에게 던집니다.

• 나: “야, AccessDenied 에러 나는데? 권한 문제인가?”
• AI: “아, 죄송합니다. 해당 프로필에 권한이 없는 것 같습니다. try-except 구문을 추가해서 권한 에러 시 로그를 남기도록 수정했습니다.”

이 빠른 주고받음(Tiki-Taka). 막힘없이 흘러가는 이 리듬감(Vibe)이 바로 AI 코딩의 묘미였습니다.

3. 시련: 7번의 삽질과 ‘평균의 배신’

물론, AI가 만능은 아니었습니다. 프로젝트 기간 1개월 중 3주는 AI가 싼 똥(?)을 치우고, 구조를 뜯어고치는 시간이었습니다. 무려 7번이나 시스템 구조를 갈아엎었죠.

$$결정적 위기 1$$ – “평균의 배신” (DBA의 짬바가 빛난 순간)

AI에게 “리소스 사용률 분석해줘”라고 했더니, 이 친구가 CloudWatch의 Average 통계만 긁어오더군요.

DB쟁이들은 압니다. DB 성능 이슈는 평균이 아니라 순간적인 피크(Max)에서 터진다는 걸요. 평균 사용률 20%라고 보고했는데, 알고 보니 새벽 2시에 100% 찍고 뻗어있었다면? 그건 분석이 아니라 사기죠.

20%라고 보고했는데, 알고 보니 새벽 2시에 100% 찍고 뻗어있었다면? 그건 분석이 아니라 사기죠.

“야, 평균 말고 MAX 값 가져와! 그리고 튀는 구간 시간대도 찍어!” 만약 제가 개발만 아는 사람이었다면 AI가 주는 대로 평균값만 보고 “문제없음”이라고 보고했을 겁니다.

여기서 ‘도메인 지식’의 중요성을 뼈저리게 느꼈습니다. AI는 시키는 대로만 합니다. 제대로 시키는 능력이 중요합니다.

$$결정적 위기 2$$ – “그림을 못 그리는 화가”

원래는 AI가 Confluence(위키)에 직접 접속해서 글도 쓰고 차트 이미지도 딱딱 붙이게(MCP 활용) 하려 했습니다.

그런데 텍스트는 잘 쓰는데, 이미지를 죽어도 못 올리는 겁니다. 파이썬을 모르는 저로서는 디버깅할 방법이 없었습니다.

그래서 과감하게 ‘타협’했습니다.

“그래, 못하는 건 포기하자. 차트는 내가(아니 파이썬 라이브러리가) 그리고, 너는 글만 써.”

4. 해결: 5단계 하이브리드 워크플로우 (v1.0)

그렇게 완성된 최종 아키텍처는 인간(설계/검증)과 AI(코딩/글쓰기)의 완벽한 분업 시스템입니다.

5. 결과: “이게 되네?”

결과는 성공적이었습니다. 스크립트를 실행하고 커피 한 잔 마시고 오면, 35개의 Confluence 페이지가 생성되어 있습니다.

• Before: 인스턴스 하나 분석하는 데 30분 × 35개 = 약 17.5시간 (꼬박 2일)
• After: 스크립트 실행 약 10분 + AI가 쓴 내용 검수 (끝!)

무엇보다 가장 큰 수확은 “파이썬 까막눈인 나도 자동화 툴을 만들 수 있다”는 자신감과 성취감이었습니다. 16년 동안 쌓아온 DB 운영 노하우를 AI라는 도구에 태우니, 1년 차 개발자보다 더 효율적인 결과를 낼 수 있었으니까요.

6. 마치며: AI는 ‘똑똑한 비서’가 아니라 ‘빠릿한 신입’이다

16년 차 DBA가 느낀 ‘AI Vibe Coding’의 교훈은 명확합니다.

• 디테일이 생명이다: “분석해줘”라고 하면 소설을 씁니다. “CPU가 80% 넘는 구간이 있는지 확인하고 있다면 시간을 적어”라고 아주 구체적으로 시켜야 합니다.
• 검증은 필수다: AI는 뻔뻔하게 거짓말(Hallucination)을 합니다. 결과 데이터는 반드시 원본(CloudWatch)과 크로스 체크해야 합니다.
• 도메인 지식이 깡패다: 코딩 문법은 몰라도 됩니다. “무엇을 봐야 하는지”를 아는 사람이 AI를 쓰면 호랑이에 날개를 다는 격입니다.

저처럼 코딩이 두려운 인프라 엔지니어, DBA 분들이 계신다면 주저 말고 AI를 켜보세요. 

여러분의 10년 짬바(경험)가 AI를 만나면 어떤 마법을 부리는지 직접 경험해 보시길 바랍니다.

👉 Migration & Modernization 문의하기

✍️by 김권환, Specialty Service Unit

공유하기