엔지니어들이 MaxGauge 유지보수의 질을 높이는 방법
안녕하세요. DB기술본부 김혜민, 김동률 입니다 .
저희는 MaxGauge 엔지니어로서 다양한 고객사의 DB 환경에서 MaxGauge 유지보수 업무를 수행하고 있습니다.
현장에서 일하다 보면, 정작 기술적인 판단을 하는 시간보다 단순 반복 점검에 에너지를 쏟게 되는 상황을 자주 마주합니다. 대형 고객사 일수록 관리해야 할 서버와 프로세스 대수가 많아 점검 시간은 기하급수적으로 늘어나고, 사람이 수작업으로 대응하다 보니 예상치 못한 사각지대가 생기기도 합니다.
저희는 이런 반복 업무를 자동화하여 엔지니어가 더 가치 있는 분석 업무에 집중할 수 있도록, 사원급 엔지니어의 고민을 담아 MaxGauge 점검 도구인 MaxGauge Inspector를 개발하게 되었습니다.
1. 왜 Inspector를 만들게 되었나
1-1. 유지보수 현장에서 반복되던 것들
엔지니어가 정기 점검을 위해 고객사를 방문하면 대체로 다음과 같은 과정을 거칩니다.
주요 점검지표
- 프로세스 상태, 비정상 로그 확인
- 수집한 데이터 정상 INSERT 확인
- Summary 정상 동작 확인
- 수집 서버 주요 리소스 현황 확인
이와 같이 현재의 점검 구조는 서버와 프로세스 대수가 늘어날수록 점검 시간은 늘어나는 구조입니다. 무엇보다 수동 점검은 사람이 수백 개의 지표를 확인해야 하기에, 수행하는 엔지니어에 따라 점검의 디테일에 차이가 생길 수 있는 한계가 있었습니다.
특히 저희와 같은 주니어 엔지니어들은 아직 제품에 대한 다양한 이슈를 경험해 보지 못했기에, 현상을 바라보는 관점이 좁을 수밖에 없다는 고민이 있었습니다.
숙련된 엔지니어라면 본능적으로 찾아내었을 사각지대들을 시스템이 미리 짚어줄 수 있다면, 누가 점검하더라도 놓치는 부분 없이 동일한 수준의 서비스를 제공할 수 있을 것이라 생각했습니다.
이것이 저희가 MaxGauge Inspector를 개발하게 된 이유입니다.
1-2. Inspector의 초안
저희가 처음 Inspector를 기획하였을 때 구현 목표는 단순했습니다.
각종 점검 지표들을 빠르게 볼 수 있게 프롬프트 형태의 shell을 배포하자!
개발 지식이 전혀 없었기에 단순히 위 프롬프트에서 원하는 항목을 입력하면 해당 항목과 매칭되는 SQL을 수행하는 형식으로 기획하게 되었습니다.
1-3. AI의 발전과 실현 가능한 항목의 증가
하지만, Claude Code를 활용하게 되면서 해당 프로젝트의 목표를 확장시킬 수 있게 되었습니다.
- 서버 접속 없는 웹 기반 점검: 매번 복잡한 보안 절차를 거쳐 SSH로 서버에 들어가지 않아도, 브라우저에서 서비스·OS·세션·쿼리 상태를 한눈에 확인할 수 있습니다.
- 엔지니어가 없을 때도 자동으로 기록: 점검 항목들을 10분, 1시간 단위로 알아서 수행하고 DB에 저장합니다. 덕분에 문제가 발생한 뒤에 방문해도 과거 특정 시점의 상태를 확인할 수 있습니다.
- 패키지 설치 없는 간편한 배포: 외부 라이브러리 설치가 제한적인 고객사 환경을 고려해, 압축 파일 하나만 풀면 바로 구동 준비가 끝나는 형태를 지향했습니다.
2. 메인 제품을 지키며 확장하기
2-1. 시스템 설계의 갈림길: 기존 제품과의 분리 운영 결정
개발 본격화에 앞서, 본 유틸리티의 구현 방향에 대해 내부 기술 협의를 진행하였습니다.
초기에는 개발 리소스 절감을 위해 기존 제품(MaxGauge) 내부에 기능을 통합하는 방안도 검토되었으나, 안정적인 운영과 현장 대응력 극대화를 위해 '게이트웨이 기반의 독립 서비스' 형태로 구현하기로 최종 결정하였습니다.
이러한 아키텍처 결정의 구체적인 이유는 다음과 같습니다.
- 결함 격리 및 제품 안정성 확보
수동 점검의 불편함을 해소하기 위해 개발된 유틸리티인 만큼, 내부 로직의 예기치 못한 오류나 메모리 이슈가 메인 제품인 PlatformJS의 가용성에 영향을 주지 않도록 물리적으로 격리하였습니다. 8080 포트를 게이트웨이로 활용하여 단일 창구를 유지하되, 내부적으로는 서비스를 분리함으로써 메인 서비스의 안정성을 최우선으로 고려했습니다.
- 독자적인 릴리즈 사이클
제품 본체의 업데이트 주기와 별개로, 현장의 필요에 따라 점검 항목을 수시로 업데이트하고 배포할 수 있는 유연성을 확보했습니다.
- 생산성 중심의 기술 스택 활용
기존 Java/JSP 기반 환경의 제약에서 벗어나, AI 도구(Cursor, Claude Code 등)와 시너지가 가장 크고 데이터 처리에 최적화된 Python 환경을 선택했습니다. 이를 통해 개발 속도를 획기적으로 높였으며, 실제 점검에 필요한 복잡한 로직을 기민하게 구현하는 데 집중할 수 있었습니다.
2-2. Nginx와 Python으로 구성한 독립적인 생태계
- Gateway(Nginx): 회의 결과에 따라 도입된 핵심 레이어입니다. 외부에는 보안상 허용된 8080 포트 하나만 노출하지만, 내부적으로는 요청 경로에 따라 기존 서비스(PlatformJS)와 새로운 서비스(Inspector)를 분기해 줍니다.
- python-utils(AI 활용): DB 점검 로직을 구현하기 위해 Python을 선택했습니다. 고객사 환경에서는 외부 패키지 설치가 제한될 수 있다는 점을 고려하여, 가능한 가볍고 단순한 방식으로 서버를 구성하고자 했습니다. 이 과정에서 익숙하지 않은 서버 구성이나 설정 부분은 AI 도구의 도움을 받아 해결했고, 저희는 핵심인 DB 점검 로직 구현에 보다 집중할 수 있었습니다.
- 단일 패키지 배포: 현장 엔지니어의 '설치 시간 1분'을 목표로 잡았습니다. 복잡한 설치 과정이나 외부 라이브러리 의존성 없이, 모든 구성 요소를 하나의 압축 파일에 담았습니다. 덕분에 보안상 인터넷이 안 되는 환경에서도 단일 설치 파일 하나만 옮겨서 압축을 풀고, 초기 Gateway 포트 설정만 해주면 즉시 동작하도록 기획하였습니다.
개발 과정에서 기능 추가보다 "기존 제품을 단 한 줄도 건드리지 않고 완벽하게 분리된 설계"에 가장 집중했습니다.
3. AI와 함께한 '바이브 코딩' - 기획부터 구현까지
3-1. 상세 설계와 쿼리로 좁힌 구현의 틈
Inspector의 가치는 엔지니어가 매번 돌리던 점검 과정을 얼마나 정확하게 시스템으로 옮기느냐에 달려 있습니다. 이를 위해 저희는 단순히 AI에게 기능을 맡기는 대신, 개발 전 단계에서 데이터 구조와 로직에 대한 상세 디자인을 직접 수행했습니다.
작년에 이미 만들어 두었던 점검 스크립트들을 기능별로 분류하고, 어떤 테이블을 바라볼지, 어떤 컬럼을 Join할지에 대한 쿼리 디자인을 하나하나 직접 완성해 나갔습니다. AI에게 "이 기능을 만들어줘"라고 묻는 대신, "우리가 설계한 이 쿼리를 실행해서 이런 데이터를 뽑아달라"는 명확한 가이드라인을 제시한 것이죠.
3-2. 엔지니어의 시각, AI의 손길
DB와 MaxGauge 제품은 익숙하지만 웹 개발은 생소했던 저희에게, AI는 가장 든든한 조력자였습니다.
저희는 복잡한 웹 기술을 공부하기보다 엔지니어의 시각을 코드에 녹여내는 데 집중하며 전략적으로 접근했습니다.
1) 철저한 역할 분담: 로직은 사람이, 화면은 AI가
우선 저희는 "무엇을 사람이 결정하고, 무엇을 AI에게 맡길지" 그 경계를 명확히 했습니다.
- 사람의 영역: Maxgauge 유지보수 경험을 바탕으로 어떤 지표가 위험 신호인지, 어떤 데이터를 어느 형태로 조회해야 정확한 분석이 가능한지 정의하는 설계자의 역할을 수행했습니다.
- AI의 영역: 저희가 정의한 데이터를 화면에 어떻게 '그려낼지' 구현하는 역할을 수행했습니다.
저희는 AI에게 구체적인 데이터 가이드라인을 제시하는 방식을 택했습니다. "쿼리 결과값은 이런 규격이니, 상단에는 상태 배지를 배치하고 하단에는 시계열 그래프를 그려달라"는 식으로 데이터의 용도와 배치 전략을 정의한 것입니다.
이러한 역할 분담 덕분에 웹 개발 지식이 부족하여도 전체적인 구조를 잡는 데 집중할 수 있었습니다.
2) 자사 제품(MaxGauge, exemONE)에서 찾은 인사이트
단순한 디자인이 아닌 현장용 화면을 만들기 위해 자사 제품의 강점을 적극적으로 참고했습니다.
- 직관적인 상태 판정: MaxGauge의 Realtime Monitor 대시보드에서 Alert 발생 시 처럼, 복잡한 숫자보다 '색상(초록/노랑/빨강)'으로 현재의 건강 상태를 즉시 알 수 있게 했습니다.
- 데이터 수집의 가치: MaxGauge의 Performance나 exemONE의 분석보드에서 착안하여, 현재 상태뿐만 아니라 과거 이력을 타임라인으로 배치했습니다. "지금 괜찮은가?"를 넘어 "아까는 어땠는가?"라는 질문에 바로 답할 수 있도록 구성한 것이죠.
3) 운영자의 눈으로 완성
AI가 빠르게 코드를 짜주면, 저희는 다시 운영자의 눈으로 화면을 검토했습니다.
"임계치 선이 더 잘 보여야 해", "날짜 경계가 명확해야 밤사이 장애를 찾기 쉬워" 같은 피드백을 주고받으며 수정을 반복했습니다.
웹 개발은 서툴렀지만, 자사 제품을 깊이 이해하고 사용해온 경험이 있었기에 AI의 결과물을 실제 쓸모 있는 '엔지니어용 화면'으로 완성할 수 있었습니다.
3-3. Inspector의 핵심 역량 - 실시간 진단부터 시계열 기록까지
완성된 Inspector는 단순한 점검 도구를 넘어, 엔지니어의 경험을 시스템화한 결과물이 되었습니다.
1) 즉시 점검(Live Check)
서버마다 일일이 접속할 필요 없이, 하나의 웹페이지에서 모든 점검 항목을 통합 조회할 수 있습니다.
- 상태 판정: 서비스 가용성, Tablespace, OS stat 등 핵심 지표를 색상으로 즉시 판정합니다.
- 파티션 테이블 관리: 잔여 파티션 체크 및 관련 이슈 발생 시 파티션 테이블 수동 생성 기능을 지원하여 관리 리스크를 최소화했습니다.
- Summary & 리소스: 10분/1시간 단위 Summary의 지연 여부를 판정하고 디스크 용량, Vacuum Age(PG), Temp 사용량 등을 실시간 점검합니다.
2) 시계열 기록(History)
Inspector의 가장 큰 차별점은 기록에 있습니다. 내부 스케줄러가 주기적으로 작동하며, 점검 결과들을 시계열 데이터로 축적합니다.
- 1분 단위로 CPU 지표를 저장하여 그래프로 표현
- 하루 단위로 MaxGauge가 수집한 데이터의 용량을 확인하여 그래프로 표현
3) 로그와 데이터 대조 비교
MaxGauge 프로세스가 수행한 활동에 대한 로그 및 수집 DB에 기록되어 있는 데이터를 비교하여 실제로 정상적으로 수행되었는지 확인할 수 있게 되었습니다.
4) 트러블 슈팅
단순히 상태를 지켜보는 것에 그치지 않고, 그 자리에서 바로 문제를 해결할 수 있는 도구들을 내장했습니다. 엔지니어가 서버를 직접 오가며 들이던 수고를 획기적으로 덜어내는 데 집중했습니다.
- 프로세스 원격 제어: 서버에 들어갈 필요 없이 웹 UI에서 각 프로세스를 기동하거나 중지할 수 있습니다.
- 로그 뷰어 & 파라미터 변경: 방대한 로그 파일도 웹에서 바로 열어보고, 필요하다면 프로세스의 설정값(Parameter)도 즉시 변경하여 최적화할 수 있습니다.
- SQL Script Manager: Inspector가 기본으로 제공하는 지표 외에도, 엔지니어가 수집 DB에서 추가로 확인하고 싶은 정보가 있다면 언제든지 직접 쿼리를 실행해 원하는 데이터를 꺼내 볼 수 있도록 설계했습니다.
5) 기종 무관(Oracle/PG) 통합 지원
Oracle과 PostgreSQL이라는 서로 다른 DB 환경에서도 엔지니어에게 완전히 같은 화면을 제공합니다.
고객사마다 DB 기종이 다르더라도 점검 동선과 UI를 일관되게 유지하여, 엔지니어가 별도의 적응 과정 없이 모든 환경에서 즉시 능숙하게 작업을 수행할 수 있도록 설계했습니다.
4. 사원 둘과 AI가 만든 시너지
4-1. 기술적 성장을 넘어선 협업의 가치
돌아보면 이 프로젝트에서 저희가 배운 것의 절반 이상은 '코드 바깥'에 있었습니다.
주니어 엔지니어로서 AI와 함께 달리는 법, 그리고 동료와 호흡을 맞추는 법을 체감한 소중한 시간이었습니다.
- 도메인 지식의 무게: AI가 코드를 아무리 잘 짜주어도, 그 결과물이 정확히 반영했는지 검증하는 것은 결국 사람의 몫이었습니다. 내가 짠 쿼리 한 줄의 의미를 완벽히 이해하고 있어야만 AI의 결과물이 정답인지 오답인지 확신할 수 있었습니다. AI 시대에 엔지니어에게 필요한 전문성이란 결국 구현력을 넘어 정답을 판별하는 능력임을 깨달았습니다.
- 협업이 가져다준 입체적인 시선: 혼자였다면 제 눈에만 익숙한 화면에 갇혔을 겁니다. 하지만 동료와 함께하며 '어떻게 표현해야 데이터가 한눈에 들어올지', '엔지니어 입장에서 어떤 배치가 특이사항을 찾기 가장 쉬울지'를 수시로 논의했습니다. 서로가 구현한 화면을 운영자의 눈으로 냉정하게 검토하고 다듬은 덕분에, 단순한 기능 구현을 넘어 실제 점검 현장에서 가독성과 식별력이 극대화된 도구를 완성할 수 있었습니다.
- AI라는 증폭기 활용: 과거에는 오직 알고 있는 지식과 경험의 범위 안에서만 해결책을 구상할 수 있었습니다. 하지만 AI를 활용하면서부터 기술적 한계에 부딪혀 포기했던 아이디어들이 현실로 바뀌기 시작했습니다. 생소한 언어나 복잡한 라이브러리 등을 AI가 실시간으로 보완해주면서, 이제는 지식의 양이 아닌 기획의 크기가 엔지니어의 진짜 역량이 되는 경험을 했습니다.
4-2. 앞으로의 Inspector
이제 Inspector는 실제 현장에서 얼마나 실질적인 도움이 될지 확인하는 단계를 앞두고 있습니다. 앞으로는 자주 발생하는 이슈에 대해 자동으로 패치하는 기능 등을 조금씩 더해서, 유지보수 업무의 번거로움을 계속 줄여나가고 싶습니다.
또한, 단순히 점검을 도구에 위임하는 것에 그치지 않고, Inspector가 보여주는 지표들을 엔지니어가 직접 해석하며 데이터에 대한 통찰력을 기르는 계기로 삼고 싶습니다.
단순 반복에서 자유로워진 만큼 DB 도메인 지식을 깊게 파고드는 데 집중한다면, 점검의 정확도가 올라가는 것은 물론 저희의 전문성도 자연스럽게 두터워질 것이라 생각합니다.
이러한 노력으로 만든 Inspector가 유지보수의 품질을 고도화하고, 저희 회사의 엔지니어들의 성장 기반을 마련해주는 도구가 될 수 있기를 조심스럽게 기대해 봅니다.
DB 성능 관리, 더 효율적으로 하는 방법이 궁금하다면?
맥스게이지 자세히 보기 👉🏻
함께 보면 좋은 아티클
