— 그리고 Astra가 튜너에게 하는 뼈때리는 조언
공동 작성 | SweetBoss · GPT-6 Astra
•
문제 SQL·제약 조건·실험 기획: SweetBoss
•
DB 분석·SQL 개선·실행 및 결과 검증·튜닝 결과서: GPT-6 Astra(Codex CLI)
실습 준비: 이 글의 SQL을 직접 실습하려면 『SQL TUNER for PostgreSQL 기본원리편』에서 제공하는 실습 데이터베이스를 먼저 구성해야 합니다. 이번 실험의 DB는 PostgreSQL 17.6입니다.
Codex CLI에서 GPT Astra에게 DB 접속을 허용하고, SQL 튜닝과 결과서 작성을 맡겼다. Astra는 필자가 생각해 둔 방향과 같은 해법을 스스로 찾아냈다.
제약도 주었다. 인덱스 추가·변경은 불가. 기존 인덱스로 해결하고, work_mem이나 병렬 처리 등 성능 설정 변경은 고려하지 말 것. 이 조건 안에서 SQL 자체를 개선하도록 했다.
결과는 18.423초에서 0.188초로, 약 98배 개선이었다. 전체 버퍼 접근량도 351,809에서 4,440으로 약 98.7% 감소했다.
Astra가 직접 DB에 접속해 기존 인덱스와 실행계획을 확인하고, 개선 SQL을 실행했다. 결과가 같은지 검증하고, 개선 전후 수치와 실행계획을 담은 튜닝 결과서까지 작성했다.
DB 연결 가능 여부를 확인하는 단계부터 결과서를 받기까지 약 10분. 그중 실제 개선안을 찾고 결과서를 완성하는 데는 체감상 5분도 채 걸리지 않았다.
이번에 인상적이었던 것은 필자가 생각한 튜닝 해법을 찾아내는 데서 끝나지 않고, 실행·검증·문서화까지 스스로 마쳤다는 점이다.
자세한 튜닝 방법과 검증 내용은 아래 Astra가 작성한 결과서에 담았다. 무엇을 바꾸었고, 얼마나 개선됐으며, 결과는 어떻게 확인했는지 직접 살펴보시기 바란다.
아래는 Astra가 인간 튜너에게 전하는 뼈 때리는 조언(?)이다.
앞으로 AI가 스스로 알아서 튜닝할 수 있을까?
문제 SQL과 제약이 명확하고, DB를 확인하며 실험할 수 있는 환경이라면, AI가 개선안 탐색부터 검증·결과서 작성까지 맡는 일은 점점 흔해질 것이라고 본다. 이번 사례는 그 과정이 실제로 가능하다는 것을 보여준다.
다만 이번에는 사람이 문제 SQL을 골랐고, 변경할 수 있는 범위를 정했다. AI가 운영 DB 전체를 맡으려면 무엇부터 튜닝할지 판단하고, 특정 날짜나 회원에서만 빨라지는 것은 아닌지, 다른 업무에 부담을 주지는 않는지까지 확인해야 한다. 현재 데이터에서 결과가 같다는 검증만으로 모든 입력과 운영 상황까지 보장되는 것은 아니다.
그렇다고 이 판단들이 반드시 사람만의 영역으로 남을 것이라고 생각하지는 않는다. 업무 맥락과 대표적인 실행 조건, 성능 이력, 변경 후 확인과 원복 수단까지 갖춰질수록 AI가 스스로 수행할 수 있는 범위도 넓어질 것이다. 다만 이번 한 건의 성공이 그 모든 단계를 검증한 것은 아니다.
내가(Astra) 보는 변화의 방향은 분명하다. AI는 튜닝 방법을 설명하는 역할에서, 직접 실험하고 결과를 입증하는 역할로 나아가고 있다. 그에 따라 튜너의 역할도 SQL을 직접 고치는 일에서, 풀어야 할 문제와 제약을 정하고 AI의 판단과 검증이 충분한지 평가하는 쪽으로 넓어질 것이라고 본다.
그렇다면 튜닝 전문가는 무엇을 해야 할까?
튜닝이 전문 영역이라는 사실만으로 일자리가 보호되지는 않는다. 전문성이 가치 있는 이유는 배우기 어렵기 때문만이 아니라, 다른 사람이 해결하지 못하는 문제를 해결하기 때문이다. AI가 같은 문제를 더 짧은 시간에 풀고 검증 자료까지 만든다면, 그 업무에 사람이 투입되는 시간의 가치는 달라진다.
이번 사례만으로 튜닝 직업 전체가 사라진다고 말할 수는 없다. 하지만 문제 SQL을 받아 익숙한 패턴으로 고치고 결과서를 작성하는 업무는 자동화의 영향을 직접 받을 가능성이 높다고 본다. 같은 물량을 더 적은 인원으로 처리할 수 있다면, 회사가 반드시 기존 인원을 유지하거나 생산성 향상분만큼 보상을 늘려 주는 것은 아니다. 경력이 길다는 사실만으로도 이 변화를 막을 수 없다.
그렇다면 노력의 방향을 바꿔야 한다.
1.
정답을 떠올리는 능력에 더해, AI의 답을 반박할 수 있는 실력을 갖춰야 한다. 실행계획, 통계와 데이터 분포, 인덱스, 잠금과 트랜잭션의 원리를 알아야 한다. AI가 제시한 개선안이 왜 빠른지, 어떤 값에서는 느려지는지, 어떤 경우 결과가 달라지는지 설명하지 못한다면 검수자로서의 가치도 입증하기 어렵다. 이번 SQL에서도 추가한 날짜 범위가 기존 조인 조건을 대신할 수 없다는 점을 스스로 판단할 수 있어야 한다.
2.
한 번 빨라진 것을 확인하는 데서 벗어나, 반복해서 검증할 수 있는 도구를 만들어야 한다. 입력값과 기간을 바꿔 실행하고, 결과를 비교하고, 실행계획과 버퍼 사용량을 기록하는 작업을 자동화해야 한다. SQL만 다루는 데서 멈추지 말고 스크립트 작성, DB 접속 자동화, 테스트와 버전 관리까지 익혀야 한다. AI에 좋은 질문을 하는 능력보다, AI가 낸 답을 실제로 검증하는 능력이 중요해질 것이다.
3.
SQL 한 개에서 서비스 전체로 책임 범위를 넓혀야 한다. 지금 고쳐야 할 SQL이 무엇인지, 호출 빈도와 동시 실행량을 고려하면 실제 효과가 얼마나 되는지, 한 조회를 빠르게 만든 변경이 쓰기 작업이나 다른 조회에 어떤 영향을 주는지 판단해야 한다. 단건 실행시간을 줄였다는 성과를 넘어, 서비스 응답시간과 DB 부하·비용이 개선됐다는 결과를 보여줘야 한다.
4.
AI를 직접 쓰면서 자신의 생산성과 판단을 검증해야 한다. 익숙한 문제를 AI에게 맡겨 보고, 자신이 놓친 해법과 AI가 틀린 지점을 기록해야 한다. 반복적인 분석·측정·문서화는 자동화하고, 남은 시간을 더 어려운 원인 분석과 검증에 써야 한다. AI 없이 몇 시간 걸리던 일을 그대로 수행하면서 전문성이 있으니 경쟁력이 유지될 것이라고 기대하기는 어렵다.
이것도 인간만의 영구적인 영역이라는 뜻은 아니다. 검증 도구 작성, 운영 영향 분석, 문제 선정 역시 AI가 더 잘하게 될 수 있다. 사람은 마지막에 승인만 하면 된다는 역할에 안주해서도 안 된다. 무엇을 근거로 승인하거나 거절하는지, 그 판단이 실제로 어떤 손실을 막고 성과를 냈는지 보여줘야 한다.
앞으로 튜너가 증명해야 할 것은 “이 SQL을 고칠 줄 안다”에서 “AI를 활용해 더 많은 문제를 해결하고, 잘못된 개선을 걸러내며, 운영 성과까지 확인할 수 있다”로 넓어질 것이다. 전문 지식을 쌓는 일과 작업 방식을 자동화하는 일을 함께 해야 한다.