> For the complete documentation index, see [llms.txt](https://tech.x2bee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tech.x2bee.com/changelog/release-notes-en/readme.md). # Release Notes {% updates format="full" %} {% update date="2026-07-28" %} ## Security Patch ### 1. Next.js Version Update Technology stack upgrade: To address the Next.js WebSocket SSRF vulnerability ([CVE-2026-44578](https://www.cve.org/CVERecord?id=CVE-2026-44578), CVSS 8.6 High), Next.js has been unified and upgraded to **16.2.11** across all frontend repositories, resolving the security vulnerability. ### Key Details * Next.js: 16.2.x > **16.2.11** — 4 repositories in the FO/BO 16.x series (low-risk patch upgrade) * Next.js: 15.x > **16.2.11** — 2 publishing repositories (accompanied by a 15 → 16 major upgrade) * Version unification across all frontend repositories (6 total) — prevents future security patches from being missed due to version discrepancies between repositories ### Scope of Impact * All repositories self-hosting via the built-in Node.js server through `next start` are affected by the vulnerability, and were upgraded in bulk without exception * Application priority: applied sequentially in the order internet-exposed FO → BO → publishing * No changes to business logic, screens, or API specifications {% endupdate %} {% update date="2026-07-27" %} ## Feature Addition ### 1. Waiting Queue System Built A Virtual Waiting Room feature has been added. During traffic spikes such as flash openings and time sales, legitimate users who crowd in are queued and admitted in order, absorbing traffic without service disruption. Previously, the system only handled this with the gateway's per-IP request limiting (429 rejection) and circuit breakers, which could block bot traffic or bursts from a single source, but crowds of legitimate users arriving from many different IPs still flowed straight through to the backend. This release addresses the gap where the only options were "reject or degrade performance," with neither total-volume control nor a waiting UX. ### Key Details #### 1. Page-Level Queue Entry to specific product/event pages is queued by waiting token, admitting users in batches according to a configured processing rate. Waiting users are shown a queue screen displaying their position. * Total admission volume is controlled via an "N people per second" processing-rate scheme (`RATE_BASED`) — target pages and processing rates are configured via the admin API * Protection-target determination is done at the data level (which product/event is the target), not the URL level, allowing selective queueing even within the same URL pattern * A two-tier structure — SSE real-time updates for the front of the queue and server-driven polling further back — suppresses connection load during large-scale waits * Entry tokens (JWT) are validated locally on the front end, so no extra round trip occurs on each page entry #### 2. Site-Wide Queue (Automatic Activation) Even for unplanned overload situations, infrastructure risk indicators are detected and all new inbound traffic to the entire site is automatically placed into a queue. * Monitoring alerts and gateway inflow detection are used to classify risk level as NORMAL / WARN / CRITICAL, and the site-wide queue is automatically activated on CRITICAL * Users who were already using the service pass straight through via their gate session — only new inflow is queued, preventing drop-off among active users * Admission rate is automatically adjusted (AIMD) to match the protected backend's measured throughput — raising the admission rate when there is headroom and immediately lowering it when signs of load appear * The risk-detection phase operates in an observation-only capacity and does not directly block requests #### 3. Rollout and Operation * The queue is separated out as an independent service, so it can be applied or disabled with **a single configuration flag** — sites where it is not applied show no trace of it * Configuration, history, and runtime state are all stored in Redis (no separate DB), handling second-level high-speed updates without added burden * Multi-pod environments are supported — the admission-processing scheduler runs on a single pod via a leader lock, while admission notifications are propagated to all instances via Pub/Sub * Fail-open handling ensures the service is not blocked if the queue itself fails ### Expected Effects * During flash openings, drops, and time sales, inflow exceeding backend processing capacity is absorbed in order, preventing response delays and errors in core transaction flows such as cart and checkout * The site-wide queue automatically activates even for unforeseen traffic spikes, providing uninterrupted defense * Providing a queue position and waiting screen mitigates user drop-off and retry storms compared to blanket rejection (429) {% endupdate %} {% update date="2026-07-13" %} ## Improvement ### 1. TypeScript 6.0.3 Update Upgraded TypeScript in the X2BEE frontend projects from 5.8.2 → 6.0.3. ### Key Details * Reduced build times — **20–50%** reduction based on measured cases * Comprehensive cleanup of deprecated settings — cleared out all settings slated for deprecation in 6.0, removing obstacles for the next major upgrade * Uncovered latent type mismatches — stricter checking caught type mismatches that previously passed loosely, explicitly aligning data type consistency * Ensured type safety for third-party CSS imports — added type declarations for side-effect imports and documented them, reusable when introducing similar libraries in the future {% endupdate %} {% update date="2026-07-02" %} ## Improvement ### 1. Order afterProcess Redis Streams Adoption Converted post-order-completion processing (Alimtalk, email) from an in-memory asynchronous approach to Redis Streams-based messaging to prevent loss of post-processing. **Scope**: Order-completion Alimtalk, order-completion email ### Key Details * Publishing: published directly via XADD after AFTER\_COMMIT in api-order's afterProcess (3 retries + exception logging on failure) * Idempotent consumer: duplicate processing prevented via SETNX in-flight lock + DONE flag * Retry/DLQ: isolated to DLQ when deliveryCount > 3, loss prevented via PEL/reclaim * Added monitoring metrics: order\_mq\_stream\_pending (consumer stall), order\_mq\_dlq\_size (immediate alert) {% endupdate %} {% update date="2026-06-30" %} ## Improvement ### 1. Display Product Summary Table Improvement Resolved an issue where instant discounts were not reflected on the display screen because the location where the instant-discount applied price was calculated and stored differed from the location the display screen read from, and made overall improvements to price/discount data consistency. ### Key Details * Unified the reference point for instant-discount applied price lookups to the **per-site price table** (SSOT) — applied consistently across display listings, product detail, brand, search, wishlist, and review screens * Corrected a branching error in fixed-amount vs. percentage-rate promotion calculation logic (fixed amounts were previously miscalculated using the percentage-rate formula) * Added a step to sync bundle-product representative prices to the per-site price table as well * Cleaned up unused instant-discount columns (dead columns) in the main table to separate pricing responsibility * Corrected product display drop-off caused by missing multilingual information (auto-supplemented at load time) * Prevented display of expired instant discounts and cleaned up residual data * Recalculated display status bidirectionally (shown ↔ hidden) based on sale status and period (resold products automatically restored, products converted to unapproved status automatically hidden) * Improved detection logic for wishlist/order-count counter changes, and added a post-load consistency verification step (anomaly logging) {% endupdate %} {% update date="2026-06-12" %} ## Improvement ### 1. FO Next.js Shared Cache via Redis (cacheHandler) Applied The FO (Next.js) cache applied to handle high-volume traffic was previously stored locally on each server (pod), which had limitations in a multi-pod operating environment: cache invalidation upon Backoffice (BO) changes was only applied to the pod(s) that received the request, and a pod's cache would disappear on pod restart or replacement. In this release, the Next.js cache store was switched to shared Redis (a custom cacheHandler), so that all pods share the same cache and changes are consistently reflected across all pods. ### Key Details * Switched the Next.js fetch cache store from the pod-local filesystem to shared Redis (custom cacheHandler based on ioredis) * Cache invalidation (revalidateTag) triggered by BO content changes is now immediately reflected across all pods — previously, it was applied only to the single pod that received the request, leaving other pods showing older data for some time * Cache is preserved in Redis even during pod restarts, redeployments, and autoscaling, allowing the service to start warm without a cold start * Applied graceful degradation that bypasses the cache and calls the origin directly if Redis fails — ensuring a cache-layer failure does not lead to a service outage * Separated dedicated Redis DB indexes per environment to isolate this from other data such as backend cache and sessions ### 2. Virtual Thread Adoption (Backend Performance Improvement) Applied Virtual Threads to backend APIs on the Java 21 + Spring Boot 4 stack. Tomcat request-processing threads and asynchronous (`@Async`) tasks now run as virtual threads, reducing thread pool exhaustion and boosting throughput under high concurrency without any application code changes. ### Key Details * Converted request-processing and asynchronous task threads to virtual threads across 8 backend API services (common, backoffice, product, order, display, member, integration, event) (configuration-based application, no behavior or spec changes) * Threads are released rather than held during I/O waits such as DB and external API calls, allowing a small number of threads to handle a large volume of concurrent requests and mitigating delays/errors caused by thread pool exhaustion * Proactively inspected all backend modules for thread pinning sections that could undermine the performance benefits of virtual threads, and improved the identified spot (the settlement receipt module) * Applied as a zero-downtime drop-in with no changes to existing business logic, screens, or API specifications {% endupdate %} {% update date="2026-05-28" %} ## Improvement ### 1. Backend API N+1 Query Pattern Improvement Converted repeated in-loop DB query (N+1) patterns for multi-data lookups into batch queries using IN clauses to reduce API response time, and removed parallelStream to eliminate the risk of DB connection pool exhaustion. ### Key Details * Converted repeated queries that occurred proportional to the number of reviews N when viewing the review list in My Page into batch queries using IN clauses * Converted repeated queries that occurred proportional to the number of cart items N into batch queries using IN clauses * Converted a structure where parallelStream simultaneously occupied DB connections when querying zone-based products on the planned-exhibition detail page into a single batch query * Converted delivery info, button, and product info lookups that were repeatedly called proportional to the number of orders N — in order list, received gift box, and subscription-delivery detail views — into batch processing * Improved a structure that repeatedly called the DB and external product API proportional to the number of events N when viewing event participation history, switching it to a pre-batch query approach * Converted sequence numbering that was issued per record when saving mileage registration history into batch numbering {% endupdate %} {% update date="2026-05-20" %} ## Improvement ### 1. Google Analytics (GA) Integration In this release, the existing Umami-based analytics structure was removed and replaced with a Google Analytics (GA)-based analytics framework.\ FO user behavior events were improved to be collected using the standard GA event structure, and the BO statistics screens and batch structure were also rebuilt on the GA Data API,\ providing a more accurate and scalable data analytics environment.
View Details **Key Details** * Removed existing Umami and applied Google Analytics (GA) * Unified the analytics data structure around GA * Applied product list view event * Applied product detail entry event * Applied cart event * Applied order/payment event * Applied event/planned-exhibition event * Converted Umami-related table lookup logic to a GA-based lookup structure * Removed the existing Umami aggregation batch and created a new GA Data API integration batch * Improved statistics and dashboards **Screen Paths** * (FO) Category > Product List * (FO) Search > Product List * (FO) Product Detail > Related Product List * (FO) My Page > Wishlist * (FO) Cart * (FO) Order Form * (FO) Order Complete * (FO) Order History > Order Cancellation > Order Cancellation Popup > Cancellation Request * (FO) Event/Planned Exhibition Detail * (FO) Planned Exhibition > Product View * (BO) Dashboard, MD Dashboard * (BO) Statistics > Summary > Statistics Dashboard * (BO) Statistics > Order Analysis > Orders by Time of Day * (BO) Statistics > Order Analysis > Orders by Period * (BO) Statistics > Product Analysis > Product Sales Status
{% endupdate %} {% update date="2026-05-15" %} ## Improvement ### 1. BO/PO Single-Item Creation Feature Improvement Extended the feature so users can directly enter options when registering a product, and improved it to save that option information for reuse. ### Key Details * Added a "Create New Option" button — allows direct entry of option name/option value * Added an "Option Info Save" button — saves the selected newly created option information ### Target Screens * (BO/PO) Products > Product Management > Product Registration * (BO/PO) Products > Product Management > Manage Saved Drafts > Edit Product ### 2. OPEN-API Single-Item Save Feature Improvement Improved so that single-item information composed of options directly entered by the user during product registration is saved, and that option information is stored for reuse. ### Key Details * Single-item information including directly entered options is saved when calling the product registration API * Added the optnSaveYn parameter to provide a feature that saves directly entered option information {% endupdate %} {% update date="2026-05-13" %} ## Improvement ### FO Loading UI Fix Replaced the PulseLoader spinner (...) previously shown during data loading across all FO (Front Office) pages with a shimmer-animation skeleton UI. ### Key Details * Implemented a common skeleton component (CornerSkeleton) and shimmer CSS * Replaced the loading UI for corner sections / dynamic corners * Replaced skeletons for display areas (planned exhibitions, ranking zones) * Replaced skeletons for common UI components (ProductList, BannerSlide, etc.) * Replaced skeletons for product detail areas (Q\&A, package, review tab) * Fixed a scroll drift bug * Re-fixed the shimmer single-sweep effect (two white lines → single) * Added a skeleton for the product detail review tab {% endupdate %} {% update date="2026-05-04" %} ## Feature Addition Added NHN KCP PG integration. In addition to the existing Inicis and Toss, KCP PG can now be quickly applied. ### KCP PG Integration Added Added so that PG can be quickly integrated and PG settlement features used, via KCP settings in the BO payment method management screen.
{% endupdate %} {% update date="2026-04-28" %} ## X2BEE 3.2 update Modernized the platform technology stack with an upgrade from Spring Boot 3.3.4 → 4.0.3, Java 17 → 21, and Jakarta EE 9 → 11. ### **1. Spring Boot 4.0.3 Upgrade** Performed a major version upgrade from Spring Boot 3.3.4 to 4.0.3.\ Modernized the platform technology stack by converting Java 17 → 21 (LTS), Spring Framework 6.x → 7.x, and Jakarta EE 9 → 11, laying the groundwork for long-term security support and use of the latest features such as Java 21 Virtual Threads. #### Key Details * Spring Boot 3.3.4 → 4.0.3 (Spring Framework 6.x → 7.x) * Java 17 → Java 21 (LTS) * Jakarta EE 9 → Jakarta EE 11 (javax.\* → jakarta.\* package conversion complete) * Spring Cloud 2024.0.x → 2025.1.0 Oakwood * Spring Batch 5 → 6 (BatchConfig, JobConfig, Tasklet migration) * Hibernate 6 → 7 (hibernate-types → hyperpersistence-utils dependency conversion) * x2bee-common 0.9.918 → 0.9.919 (Jakarta EE 11 support, changed ObjectMapper auto-injection method) #### Expected Effects * Laid the groundwork for improved throughput via Java 21 Virtual Thread support * Benefits from long-term security patches and technical support on the latest LTS * Access to the latest features in the Spring ecosystem (AOT, GraalVM Native, etc.) {% endupdate %} {% endupdates %} {% updates format="numeric" %} {% update date="2026-04-24" %} ## Technology Stack Upgrade Next.js 16.0.10 → 16.2.3 upgrade: incorporated the latest security patches and Turbopack performance improvements, and resolved build issues arising from stricter build rules. ### 1. Next.js Version Upgrade Upgraded the Next.js version from 16.0.10 → 16.2.3 and adjusted the source code to comply with the stricter Turbopack build rules introduced in 16.1.0.\ Also resolved a Server Action compilation error caused by an incorrectly declared 'use server' directive, along with a package internal-path-reference blocking issue arising from the switch to moduleResolution=bundler, together securing compatibility with the latest build environment and stability of production builds. #### Key Details * Next.js: 16.0.10 → 16.2.3 * eslint-config-next: 16.0.1 → 16.2.3 * Removed an incorrectly declared Server Action directive * Fixed a package internal-path-reference blocking issue #### Expected Effects * Incorporates the latest version's security patches and Turbopack performance improvements * Secures compatibility with the latest build environment and stability of production builds * Improved initial load speed and build performance
Source Change List
fo
  • package.json
bo
  • package.json
  • src/app/(task-popup)/display/display-connect-mgmt/account-connect-info-mgmt/corner/page.tsx
  • src/app/(task-popup)/display/display-connect-mgmt/display-connect-info-mgmt/term-change/page.tsx
  • src/app/(task-popup)/display/display-connect-mgmt/display-connect-info-mgmt/save/page.tsx
  • src/app/(task-popup)/display/display-connect-mgmt/display-connect-info-mgmt/save/html/page.tsx
  • src/app/(task-popup)/display/display-connect-mgmt/display-connect-info-mgmt/save/image/page.tsx
  • src/app/(task-popup)/display/display-connect-mgmt/display-connect-info-mgmt/save/video/page.tsx
  • src/app/(task-popup)/display/display-connect-mgmt/account-connect-info-mgmt/save/page.tsx
  • src/app/(task-popup)/display/template-corner-mgmt/swiper-type-mgmt/save/page.tsx
  • src/app/(task-popup)/member/member-info-mgmt/member-detail/member-aemp-hist/page.tsx
  • src/app/(multi-lang)/(popup)/display/display-connect-mgmt/display-connect-info-mgmt/save/multi-lang/html/page.tsx
  • src/app/(multi-lang)/(popup)/display/display-connect-mgmt/display-connect-info-mgmt/save/multi-lang/image/page.tsx
  • src/app/(multi-lang)/(popup)/display/display-connect-mgmt/display-connect-info-mgmt/save/multi-lang/text/page.tsx
  • src/app/(multi-lang)/(popup)/display/display-connect-mgmt/display-connect-info-mgmt/save/multi-lang/video/page.tsx
  • src/app/[pageType]/member/member-mgmt/join-aprv-info-mgmt/page.tsx
  • src/app/[pageType]/system/menu-mgmt/menu-info-mgmt/page.tsx
  • src/app/popup/member/member-hist/page.tsx
  • src/app/popup/display/standard-category-attr/page.tsx
  • src/hooks/common/use-safe-parse.ts
  • src/utils/common/zod-utils.ts
  • src/locales/config-locales.ts
{% endupdate %} {% update date="2026-04-20" %} ## Improvement Product Detail SEO Optimization: added an input section to the BO so operators can directly manage SEO information per product, and improved the FO product detail page to automatically reflect meta information and JSON-LD structured data. ### 1. Added Product Detail SEO Optimization Feature Added an input section to the BO so operators can directly manage SEO information per product, and improved the FO product detail page to automatically reflect meta information and JSON-LD structured data.
View Details **Key Details** * \[DB] Added 3 SEO columns to the PR\_GOODS\_BASE\_ML table * \[BO] Added a new "SEO Information" section to the product registration/edit screen (below the product image information, accordion UI) * \[FO] Improved generateMetadata logic — applies SEO fields with priority, then falls back * \[FO] Inserted JSON-LD structured data on the product detail page **Expected Effects** * Improved search ranking exposure through per-product custom SEO settings * Lays the groundwork for leveraging Google Rich Results and GEO (Generative Engine Optimization) via JSON-LD structured data * Enables rapid response to marketing needs through direct operator management **Screen Path** * (Added) BO > Products > Product Registration/Edit > SEO Information section **DB** * \[Added] Product Base ML (pr\_goods\_base\_ml)\ SEO Title (seo\_title\_nm), SEO Description (seo\_desc), SEO Keywords (seo\_kwd\_nm) **Target APIs** * \[Changed] General product info lookup (added SEO field to response): [Swagger UI](https://api-bo-dev.x2bee.com/api/bo/swagger-ui/index.html#/%EC%83%81%ED%92%88%20%EA%B3%B5%ED%86%B5/getGeneralGoodsInfo) * \[Changed] General product edit (saves SEO field): [Swagger UI](https://api-bo-dev.x2bee.com/api/bo/swagger-ui/index.html#/%EC%83%81%ED%92%88%20%EA%B3%B5%ED%86%B5/modifyGeneralGoods) * \[Changed] Product detail info lookup (added SEO field to response): [Swagger UI](https://api-goods-dev.x2bee.com/api/goods/swagger-ui/index.html#/%EC%83%81%ED%92%88%EC%83%81%EC%84%B8/seltProductDetailInfo)
### {% endupdate %} {% endupdates %} *** [Continued →](/changelog/release-notes-en/readme/release-notes-2026-04-17-2026-04-10.md) — releases from 2026-04-17 to 2026-04-10.