How to trace exposure issues in one go

Operational issues in module stores and corner areas are hard to diagnose by looking at a single API response alone. The final screen is the combined result of display data, internal post-processing logic, and responses from multiple services.

To trace a problem, you typically had to go through all of the following:

• Checking module settings
• Checking whether source data was saved
• Checking the request values of the called API
• Verifying the response data
• Checking whether anything was excluded or changed during post-processing

and previously this meant manually stitching together DB lookups, log checks, and source analysis across multiple systems.

To reduce this inefficiency, we built the internal debugging service YoungWonHee (YoungWonHee). Centered on the logGroupId created and passed at the start of a service request, it logs internal API calls, detailed logic, and query lookups together, collects them in chronological order, and displays them all on a single screen. Logs are delivered to a Kafka Topic, and a Consumer receives them and stores them in MongoDB.

The core of the design is not putting a burden on the actual service logic. Logs are recorded at common processing points, and annotations are used to minimize changes to individual services. It started out centered on module stores and was gradually expanded to corner logic, frequent purchases, and more.

YoungWonHee 1.0 focused on collecting request/response logs centered on module stores, viewing the flow per request, checking logs in chronological order, and tracing sections where data went missing. However, it had a limited scope and was less useful unless you entered directly through debug mode.

In 2.0, the scope was expanded to cover display as a whole, and it was integrated with Swagger so that APIs could be called directly from the screen. It's no longer just a tool for viewing accumulated logs—it has become an executable debugging tool that can directly reproduce a request and immediately trace the flow of its results.

Since its introduction, this has led to effects such as:

• Quickly identifying at which stage data disappeared in exposure issues
• Distinguishing between API response problems, intermediate transformation problems, and final display-processing problems
• Enabling reproduction-based debugging by calling directly under the same conditions to narrow down the cause
• Finding unnecessarily repeated API calls and using that to improve performance

Currently, YoungWonHee is only accessible from internal IPs, and the log for a single request is deleted after 1 hour. The focus is on handling recurring operational inquiries faster and reducing the situation of not knowing where to even start looking.