Translated from the Korean original. Some screenshots show the original Korean interface.
MaxPaper: A Daily Operations Report for MaxGauge
Hi, I'm Seongbin Lim from the DB Technology Division.
As a MaxGauge engineer, I support product maintenance and DB performance analysis.
MaxGauge is a database performance monitoring solution that excels at real-time incident response and post-incident analysis. It collects everything that happens in the database and lets you analyze it in many ways and from many angles.
MaxPaper is a tool built on MaxGauge that delivers an analysis of your production DBs as a daily report you can read every day, like a newspaper. In this post, I'll share how this project grew from a small idea through planning and implementation, and how I built MaxPaper with DBAs and infrastructure engineers in mind.
1. DB performance analysis goes from big to small
1-1. Why you need an overall view of DB health
There's one question that comes to mind first when you start performance analysis.
"Is this DB behaving the way it usually does, or not?"
The fastest way to answer it is to scan the flow of the entire previous day at once. You need to know the usual pattern before anomalies stand out, and that's what tells you where to dig in first.
MaxPaper condenses this first step into a single page. Every day, it automatically aggregates the performance data MaxGauge has collected over 24 hours and turns it into a one-page daily report covering key metrics per instance, alert history, tablespaces, TOP-SQL, and new SQL.
With MaxPaper added to MaxGauge, users naturally get two points of view. Day to day, they check the big picture of yesterday's operations in MaxPaper, and when something looks suspicious, they go into MaxGauge for detailed analysis by time and by session.
💡 The biggest differentiator is that on top of MaxGauge's deep analysis capabilities,
you get a one-page summary, organized every day.
1-2. MaxPaper-MaxGauge integration
MaxPaper's overall summary panel shows the number of instances, the number of Warning / Critical alerts, and the average and maximum CPU and memory at a glance. With the instance table's status column and the 24-hour trend charts, you can see from the big picture which instances behaved differently than usual.
The TOP-SQL panel on the same page shows which queries actually put load on that instance over the previous day. Queries are sorted by metrics such as Elapsed Time, CPU Time, and Wait Time, so you can quickly pick out suspicious queries from whatever angle you need. When you find a query that needs deeper analysis, you can jump straight from that SQL to MaxGauge. The context you were viewing (instance, date, sort criteria) carries over, so MaxGauge automatically opens a screen with the same conditions.
For me, MaxPaper's most practical value is in the routine people repeat every morning: "come in and check how yesterday went." It connects that routine seamlessly on one page, from reviewing the full flow of the previous day, to pinpointing suspicious queries through TOP-SQL, to detailed analysis in MaxGauge.
2. The potential and limits of AI tools
2-1. AI as a development tool
I did almost all of the coding for MaxPaper with Claude Code, from the backend and frontend to deployment scripts and operations automation. It wasn't a matter of copying down code it handed me. I explained the requirements and constraints, and it read the relevant files itself, worked out the scope of impact, and produced changes in a consistent style. Even when I touched one small feature, it also took care of the surrounding files that needed attention, so I could finish the cascading fixes and leftover cleanup that are easy to miss on your own in a single pass.
I treated it like drawing a rough sketch first: I laid out the intent and goals up front, then repeatedly refined what it produced and reviewed it against the production environment. This Flow let me try new ideas without hesitation and iterate quickly on all kinds of improvements and experiments, big and small. Instead of betting everything on one big decision, I could find the direction through many small attempts, and the time saved went back into design, verification, and checking user scenarios.
2-2. Where a human touch is still needed
The biggest letdown was design. In code, where the right answer is relatively clear, AI followed my intent well. But in areas where taste matters more than a right answer, like color, spacing, style, and overall tone, it was hard to get a satisfying result in one go. Even after generating the same screen several times, there was often a spot that felt awkwardly empty, or the result was slightly off from what I intended.
I had to revise and re-request many times until it felt right, and it reminded me that design is only finished when human eyes and hands stay involved to the very end. It also made me realize that design isn't just about making a screen look good. It's closer to polishing that screen so the people who face it every day don't get worn out by it.
3. Working through it alone, with help from others
3-1. Taking things out is harder than adding them
The hardest part was deciding "which features to include and which to leave out." Since this might one day be a screen the people in charge actually use, I asked them directly for their opinions, and thankfully many of them replied. Every piece of feedback made sense and was helpful, which made it all the harder to decide which opinions to reflect, and how far.
I set the direction based on that feedback, but I held to one standard to the end: "keep it to a single page." Even features that looked good had to be cut if they broke that standard. I couldn't include every suggestion, and having to decide on my own, every time, what to keep and what to cut weighed on me the most.
3-2. A clue found inside our own products
Early in planning, I assumed that with AI, any technical problem would be easy to solve. But the MaxGauge integration was a knot I had to wrestle with for a long time. A link that simply opens a MaxGauge screen isn't hard. Carrying over the instance, time, and metric context you were viewing in MaxPaper so that MaxGauge automatically opens a screen with the same conditions took far more work than I expected.
In the end, I found a clue in how InterMax integrates with MaxGauge, and after some twists and turns I got the two screens to connect naturally. It reminded me that a feature you want to build may already exist in a similar form inside the company, and that taking a look at that material can turn out to be the fastest route.
Wrapping up
The first thing I want to improve is the design. Since people look at this screen every day, I want to refine it into an interface anyone can use more easily and intuitively, putting care into every small screen and every small piece of wording so users don't feel burdened. I'll also keep incorporating feedback from the people in charge to round out the features, and keep developing MaxPaper so it becomes a dependable companion to MaxGauge.
This project started from a small wish, "it would be nice to have a tool like this." It may look like a solo effort, but underneath it were MaxGauge, a solidly established foundation, and the wealth of experience and material built up inside the company. Because that foundation was there, I could lay a single sheet of paper on top of it, and I see MaxPaper as one small step added to that flow.
Take a look at MaxGauge for database performance management.
Learn more 👉🏻
Related articles
