techlist.io
KREN

Techlist.io - Korean Tech Blog Curator

gitlab3 min readCurated summary

Give your AI agent direct GitLab access with glab CLI

The post argues that connecting AI agents to GitLab through the `glab` CLI gives them reliable, current, structured project data instead of forcing them to rely on copied UI content or stale assumptions. Through Model Context Protocol (MCP), agents can inspect issues, merge requests, discussions, and pipelines, then take actions such as commenting or resolving review threads. This reduces friction and enables faster code review and issue triage. ## Why AI Agents Need Direct GitLab Access - Without direct access, agents may: - Hallucinate issue or merge request details. - Rely on outdated training data. - Require developers to manually copy information from GitLab. - `glab` lets agents fetch live project data, act on it, and report results. - The approach supports tools such as GitLab Duo, Claude, Cursor, and other AI assistants. ## Connecting an Agent Through MCP - Model Context Protocol allows AI tools to discover and use external capabilities at runtime. - Start the `glab` MCP server with: ```bash glab mcp serve ``` - Once configured, an agent can answer questions such as: - “What’s the status of my open merge requests?” - “Are there failing pipelines on `main`?” - When used through MCP, `glab` automatically adds `--output json` where supported, giving agents clean, structured responses. - Interactive commands are excluded from MCP so agents do not hang waiting for terminal input. - The implementation uses the official MCP SDK for compatibility with protocol changes. ## Using AI for Merge Request Review - Agents can inspect unresolved review feedback with: ```bash glab mr view 2677 --comments --unresolved --output json ``` - The response includes: - Merge request metadata and description. - Labels and author information. - Unresolved discussions and reviewer comments. - Whether blocking discussions remain unresolved. - The agent can turn this data into a prioritized list of required fixes and suggested changes. ## Resolving Review Discussions Programmatically - Agents can list discussions in structured form: ```bash glab mr note list 456 --output json ``` - After verifying that feedback has been addressed, they can resolve a discussion: ```bash glab mr note resolve 456 3107030349 ``` - Discussions can be reopened when further review is needed: ```bash glab mr note reopen 456 3107030349 ``` - Discussion IDs are available in the GitLab UI and API, so no additional lookup is required. ## Feeding AI Better GitLab Context Without MCP - Even without an MCP server, developers can use `glab` to provide agents with richer, more accurate data. - Instead of pasting a short summary such as issue counts, milestones, and labels, command output can provide structured issue, merge request, or pipeline details. - This gives the agent more context for triage and debugging while avoiding manual browser-based copying. ## Practical Recommendation Use `glab` as the structured interface between GitLab and AI agents. MCP is the most capable option for agents that need to query and modify GitLab directly, while ordinary JSON-producing `glab` commands are a useful fallback for supplying accurate context manually.

Read original(opens in new tab)
Machine LearningModel Context ProtocolCode ReviewJson+3
netflix3 min readCurated summary

Scaling Camera File Processing at Netflix

Netflix built its Media Production Suite (MPS) to automate repetitive media workflows, improve consistency, and give filmmakers more time for creative work. Rather than develop an image-processing engine internally, Netflix partnered with FilmLight and integrated its FilmLight API (FLAPI) into Netflix’s cloud infrastructure. This combination provides reliable, camera-aware processing at global scale while supporting open standards, auditability, and rapid turnaround. ## Why Netflix Built MPS - Netflix productions use a wide range of cameras, formats, workflows, regions, and vendors. - File-based workflows created recurring problems: - Manual file wrangling reduced creative time. - Media handling varied between productions. - Human-driven processes were difficult to audit. - Teams repeatedly rebuilt similar workflows. - MPS aims to: - Standardize media management and movement from production through post-production. - Improve efficiency, consistency, and quality control. - Reduce errors and non-creative administrative work. ## Choosing FilmLight’s Processing Engine - Building a complete image-processing engine would require long-term collaboration with camera manufacturers and the broader industry. - Netflix needed a system that could: - Inspect, trim, and transcode camera-original files. - Preserve trusted color science and metadata. - Support many current and future camera formats. - Run within Netflix’s scalable, observable encoding infrastructure. - FilmLight’s Baselight and Daylight products already serve professional color grading, dailies, and transcoding workflows. - FLAPI allowed Netflix to use this proven processing technology as a backend API instead of duplicating it internally. ## Camera Metadata Inspection - Productions upload media with ASC Media Hash List (MHL) files to verify ingest completeness and integrity. - During the subsequent inspection phase, FLAPI: - Extracts metadata from original camera files. - Maps critical fields into Netflix’s normalized schema. - Makes the metadata searchable and reusable. - The metadata supports: - Matching footage by timing and reel name. - Automated retrieval. - Pipeline validation and troubleshooting. - Investigating why footage appears a certain way after processing. - Packaging FLAPI in Docker allows nearly identical deployments across Netflix’s cloud and global production compute environments. ## VFX Plates and Media Deliverables - MPS generates VFX plates and other outputs while preserving framing, color management, and camera-specific decoding behavior. - FLAPI is used to: - Debayer original camera files with format-appropriate parameters. - Crop and de-squeeze images according to ASC Framing Decision Lists. - Apply ACES Metadata Files for repeatable color workflows. - Produce deliverables in multiple formats. - The workflows are automated, repeatable, and auditable. - AMF files accompany OpenEXR outputs so recipients can identify which color transformations have already been applied. - Because the backend uses FilmLight technology, Netflix specialists can validate automated decisions in Baselight before production begins. ## Cloud-Native Media Processing - Traditional facilities often rely on powerful GPU systems and specialized high-performance storage. - Netflix instead designed its processing around the Cosmos compute and storage platform. - Cloud-compatible tools must: - Run as short-lived serverless functions in Linux Docker containers. - Operate effectively on CPU-only instances. - Support headless execution through Java, Python, or command-line interfaces. - Remain stateless so failed workers can be terminated and relaunched. - This model favors parallel processing across many workers rather than maximizing the power of one machine. - It improves cost and performance efficiency while maintaining production turnaround targets. - FLAPI’s API-driven, container-friendly, and low-state architecture made it straightforward for Netflix to integrate and operate reliably. Netflix’s approach demonstrates the value of combining established industry expertise with cloud-scale orchestration. By using FLAPI for specialized media processing and Cosmos for elastic execution, MPS can deliver consistent, traceable camera-file workflows without requiring Netflix to build and maintain every component itself.

Read original(opens in new tab)
Database DesignCloud ComputingDocker & ContainersImage Processing+4
line4 min readCurated summary

ODW #4: From Copilot to Pilot, Automating from Implementation to PR with Agentic Coding

LY Corporation’s Orchestration Development Workshop promotes a shift from using AI as a code suggestion tool to using it as an autonomous development “pilot.” The team combined specification-driven development with Jira/Confluence access through MCP so AI agents could investigate requirements, plan implementations, write code, run checks, create pull requests, and respond to reviews. The approach improved development speed and planning, but still requires humans to review AI-generated code and retain responsibility for product quality. ## From Copilot to Agentic Coding - The team initially used GitHub Copilot for small code-generation tasks but saw limited productivity gains. - Two developments enabled a broader shift: - Existing requirements and design documents supported specification-driven development. - Jira and Confluence became accessible to AI coding tools through the Model Context Protocol (MCP). - Agentic coding gives an AI agent a high-level goal, which it decomposes into tasks and executes iteratively. - Unlike autocomplete tools, an agent can analyze the broader codebase, run commands and tests, fix lint errors, and continue until the requested feature is complete. ## Workshop Goals and Human–AI Responsibilities - The workshop focused on automating the process from implementation through pull-request creation. - Humans remained responsible for: - Defining requirements and writing specifications - Final testing, review, and release decisions - AI was assigned: - Implementation planning - Code implementation - Pull-request creation - Initial review and review-response work - This division preserved the existing development process while giving participants practical experience with agentic workflows. ## Stage 1: Research and Implementation Planning - Participants supplied a Jira ticket URL to a custom slash command. - The AI agent: - Retrieved Jira data through the Jira MCP tool - Followed Epic links and collected related tickets - Retrieved Confluence documentation through the Confluence MCP tool - Explored the codebase, using an Explore Agent where available - Wrote a detailed implementation plan to `specs/{ticket-or-topic}/plan.md` - The plan included requirements, affected components, technical analysis, implementation tasks, risks, testing considerations, and a checklist. - Saving the plan to a file made it available for human review, future sessions, and later PR generation. - The team emphasized planning early because vague instructions can lead to incorrect implementations and costly rework. ## Stage 2: Implementation and Pull-Request Creation - The reviewed plan was passed to an implementation command. - The AI was instructed to: - Understand the plan and implementation scope - Modify the code - Add or update tests - Run the test suite - Run linting and build commands - Fix any resulting problems - Explicitly listing these steps encouraged the coding agent to maintain a task checklist and complete the full development cycle. - A separate PR command generated the pull request using the team’s template. - Information gathered during the planning stage could be reused in the PR description, reducing administrative work. ## Stage 3: AI Review and Issue Resolution - An AI screening-review command analyzed the generated PR. - It also read existing comments, including: - The AI’s own prior review comments - Comments from other team members - The agent identified issues requiring changes and explained its assessment of existing comments. - After a human reviewed those conclusions, the AI could implement the necessary fixes, reducing the cost of responding to review feedback. ## Benefits and Risks - **Higher code-generation speed** - Agents can work with less frequent human intervention. - Developers can perform other tasks while agents work. - Multiple agents can potentially run in parallel. - **Earlier risk discovery** - Detailed implementation plans clarify the work before coding begins. - Planning can reveal overlooked tasks, dependencies, and risks. - **Greater review burden** - AI can generate large volumes of code that humans must still inspect. - The unfamiliar workflow may create stress for developers. - **Human accountability remains essential** - Developers are responsible for the quality of AI-generated code. - Poor-quality output increases reviewer workload and can add technical debt. ## Workshop Results - The workshop was delivered twice: - A hands-on practical session requiring prior preparation - An introductory session with more detailed support - Approximately 2,500 people participated. - More than 40% of respondents had already applied, or intended to apply, some aspect of the workshop. - The sessions provided concrete guidance on MCP server usage and effective ways to delegate coding tasks to AI agents. The recommended approach is to introduce agentic coding incrementally: keep human ownership of requirements and final quality decisions, while allowing AI to handle structured planning, implementation, testing, PR creation, and initial review.

Read original(opens in new tab)
AIModel Context ProtocolGithub CopilotAgentic Coding+4
gitlab2 min readCurated summary

curl removed from Omnibus-GitLab FIPS packages in 19.0

GitLab will remove its bundled curl from Omnibus-GitLab FIPS packages beginning with version 19.0 and use the customer’s Linux distribution package instead. The change is driven by curl 8.18.0 dropping support for OpenSSL 1.x and extends GitLab’s existing approach of relying on distribution-provided cryptographic libraries. GitLab instances should continue working normally, but customers will become responsible for keeping curl updated. ## Change to FIPS Packages - Starting with Omnibus-GitLab 19.0, FIPS packages will no longer include a GitLab-built curl. - The package will use curl supplied by the customer’s Linux distribution. - The change applies to all FIPS customers and will also be included in patch releases for existing supported versions. - GitLab 19.0 is scheduled for May 21, 2026. ## Why GitLab Is Making the Change - curl 8.18.0 deprecated compilation against OpenSSL 1.x. - This prevents GitLab’s previous curl-building approach on: - Amazon Linux 2 - AlmaLinux 8 - RHEL 8 environments - FIPS packages already use distribution-provided OpenSSL rather than bundled cryptographic libraries. - GitLab is extending that model to curl for maintainability and security, including on systems using OpenSSL 3.0 or newer. ## Customer Responsibilities - No immediate configuration or migration action is required. - Customers must keep their operating system’s curl package updated to receive security fixes. - Security scanners will report the host OS curl version instead of a GitLab-bundled version. - GitLab will no longer ship curl-specific security updates for FIPS packages. Customers experiencing problems should report them in the Omnibus-GitLab issue tracker.

Read original(opens in new tab)
GitlabDevSecOpsLinuxCurl+3
discord3 min readCurated summary

Measure Less to Learn More: Using Fewer, Higher-quality Metrics to Capture What Matters

Discord argues that experiments should measure fewer, higher-quality metrics rather than automatically collecting every potentially useful signal. Large metric sets increase compute and cognitive costs while creating a tradeoff between false positives and missed real effects. Multiple-testing corrections such as Benjamini–Hochberg reduce false discoveries but also lower recall, so the most effective solution is selecting metrics that represent distinct, important concepts. ## The Cost of Measuring Too Much - Discord’s “Default Metric List” gradually expanded as teams added metrics and rarely removed them. - More metrics create: - Higher compute costs - More difficult experiment readouts - Increased risk of false positives - With 100 metrics and an uncorrected significance threshold of 0.05, roughly five metrics may appear significant purely by chance. - Correcting for multiple comparisons reduces false alarms but makes genuine changes harder to detect. ## The Multiple Comparisons Problem - Discord uses the Benjamini–Hochberg (BH) procedure to control the false discovery rate at 5%. - BH ranks p-values and compares each one with a rank-specific threshold: `i × α / n` where `i` is the metric’s rank, `α` is 0.05, and `n` is the total number of metrics. - A metric with an unadjusted p-value of 0.038 might be significant without correction but fail after BH adjustment. - BH treats all metrics equally because it has no information about which ones are more likely to reflect a real effect. - The resulting tradeoff is: - Fewer false alarms - Lower recall for real changes - The article notes that Bayesian methods could potentially incorporate prior knowledge, but Discord’s default system is frequentist. ## Simulation Results - Discord simulated 50,000 experiments containing: - Twenty null metrics generated from `N(0, 1)` - One metric with a real effect centered at `z = 2.8` - The simulations tested how metric count affects: - Experiment-level false alarm rates - Recall of the metric with the known effect - Without correction, false alarm rates rose sharply as more metrics were added—approximately from 23% with five metrics to 93% with 50. - BH kept false alarm rates near 5%, but recall declined as the metric pool grew, falling from roughly 60% to 30% across the same range. - These results demonstrate that adding metrics makes statistical correction stricter and makes genuine effects harder to identify. ## Fewer, Higher-Quality Metrics - Reducing the metrics automatically included in experiments improves the balance between false alarms and recall. - Metrics should be selected for quality and conceptual distinctness rather than added “just to be safe.” - The article’s central conclusion is that no sophisticated statistical method eliminates the underlying tradeoff created by excessive measurement. Teams should maintain a focused default metric set, regularly remove low-value or redundant metrics, and reserve specialized metrics for experiments where they are genuinely relevant.

Read original(opens in new tab)
A B TestingStatistical AnalysisExperiment DesignBenjamini Hochberg Correction+3
toss5 min readCurated summary

Introducing Toss Place's Data Bot 'PANDA': How every team member works like a data expert

PANDA, short for Place Analytics & Data, is Toss Place’s AI data-analysis assistant, designed to let employees retrieve and interpret approved data without waiting for analysts. It was created after the team found that 70% of data requests involved simple metric lookups rather than complex analysis. The project’s main conclusion is that reliable AI analytics depends less on prompting alone and more on standardized data, business definitions, controlled table selection, and iterative validation. ## Why Toss Place Built PANDA - Employees previously relied on analysts to search dashboards, write SQL, or manually investigate data requests. - PANDA provides self-service access within each employee’s security permissions. - It reduces routine extraction work for analysts, allowing them to focus on deeper analysis. - The goal is to establish a stronger culture of “data democracy,” where employees can access and use data immediately. ## Challenges with a Simple AI Chatbot Early experiments showed that asking an AI model to search all company data produced unreliable and expensive results: - Referencing thousands of tables and internal documents consumed excessive tokens. - The model sometimes selected different tables for identical questions, producing inconsistent answers. - It often misunderstood business definitions. For example, “active stores” could mean stores with completed installations or stores that had processed payments. - Inefficient SQL caused unnecessary Snowflake data scans and higher warehouse costs. ## Standardized Data Marts as a Single Source of Truth Toss Place collaborated across its Data Analysis and Data Platform teams to establish reliable standard data marts. - Core concepts, such as store information, were consolidated into standardized tables. - Naming conventions made table and column purposes easier for both people and AI to understand: - Tables follow `{mart_type}_{domain}_{subject}`, such as `fact_device_error_log`. - Columns follow `{prefix}_{entity}_{attribute}_{suffix}`, such as `is_merchant_active`. - Table and column descriptions were documented comprehensively. - The standardization effort reduced ambiguity by ensuring the same business concepts were represented consistently. ## Connecting Business Language to Data Data structures alone could not answer questions about terms such as “installed store” or “store category.” - Domain-specific terms and metric definitions were documented. - These business definitions were linked to the relevant standard data marts. - Data analysts helped reconcile differing interpretations and establish shared organizational definitions. - This gave PANDA the context needed to apply the correct business logic. ## Scoring and Ranking for Reliable Table Selection PANDA limits its search to well-managed tables and uses dbt tags to import selected metadata into a Manifest file. - Tables are ranked using: - **Similarity score:** Based on relationships between the question and table, including table-name matches and description relevance. - **Hierarchy weight:** Reflecting the reliability of the data layer. - The final score is calculated as: `similarity score × hierarchy weight` - Weights are assigned as follows: - Company-wide SSOT metrics: ×4 - Validated standard marts: ×3 - Domain analysis marts: ×2 - Raw bronze data and logs: ×1 - This improves accuracy, consistency, and trustworthiness while reducing unnecessary warehouse exploration. ## Agentic Loop for Querying and Validation Rather than expecting a correct answer in one attempt, PANDA uses an agentic loop. - It selects appropriate tools based on the question. - It explores tables, generates and executes queries, and reviews the results. - If the result appears inaccurate, it can inspect the schema again, modify the query, and retry. - If necessary, it asks the user for clarification. - This approach allows PANDA to handle exceptions dynamically instead of relying only on predefined rules. ## Answers Designed for Practical Use PANDA structures responses so users can understand and apply the results: - **Result:** The requested data or metric. - **Query criteria:** The period, filters, and aggregation method used. - **Insight:** An interpretation that can support practical decisions. This makes PANDA more than a number-retrieval chatbot; it also exposes part of the reasoning process normally provided by a data analyst. ## Adoption and User Response PANDA quickly became part of everyday work at Toss Place. - One-third of employees used it on its first day. - Half of the organization had tried it within a week. - More than 4,000 messages were exchanged during that period. - Current adoption is approximately 70%. - Employees reported feeling more comfortable asking small questions and using data while away from their desks. - Users particularly valued receiving insights alongside raw figures. - Unexpectedly, developers and even data professionals used PANDA actively, suggesting that its answers achieved a meaningful level of trust. ## Future Development PANDA was developed and launched in just one month, but the team plans further improvements. - Increase data coverage to more than 90%. - Raise answer accuracy above 97%. - Use real user questions, follow-up behavior, and abandonment patterns to identify unmet needs. - Expand beyond basic data retrieval to reduce more of the data team’s workload. PANDA’s central lesson is that effective enterprise AI does not require the most complicated technology. It requires solving a real business pain point with trustworthy data foundations, clear definitions, and a workflow that users can rely on.

Read original(opens in new tab)
AIDatabase DesignMachine LearningSql+4
toss4 min readCurated summary

StarRocks Operations: Isolating Multi-tenant Workloads with Resource Groups

Toss adopted StarRocks as a real-time OLAP engine to consolidate service queries, analytics, validation, and dashboard workloads on one platform. As different workloads began competing within the same clusters, the key operational challenge became deciding which queries to protect during CPU contention. The article describes a gradual strategy: classify workloads, use `cpu_weight` by default, and introduce `exclusive_cpu_cores` only when stronger isolation is required. ## Why StarRocks - Toss previously relied on separate MySQL and Hadoop-based paths for serving, validation, monitoring, and analytics. - StarRocks reduced this duplication by providing: - A MySQL-compatible SQL interface - Large-scale analytical processing - Real-time service-oriented reads - Workloads eventually included: - Advertising and loan-underwriting services - Dashboards and monitoring tools - Kafka Connect ingestion - Batch jobs and backfills - Average traffic varied by cluster: - Service cluster: approximately 69 QPS over 24 hours and 87 QPS over a week - Monitoring and batch cluster: approximately 20 QPS, plus heavier batch workloads - Peak contention between different workloads mattered more than average QPS. ## Workload Classification Toss prioritized workloads in the following order: 1. Service queries 2. Server-side batch jobs 3. Large-scale ingestion and backfills 4. Monitoring and user query tools such as Grafana, Tableau, and Redash - Service queries required strict SLA protection. - Batch jobs needed to finish reliably but did not require real-time responses. - Ingestion and backfills could overwhelm the cluster and therefore needed explicit limits. - Monitoring queries received the lowest priority. ## Using `cpu_weight` for Shared Capacity - `cpu_weight` distributes CPU proportionally when workloads compete. - Higher-weight groups receive more CPU during contention. - When the cluster is idle, all groups can use available CPU regardless of weight. - Toss used this as the default mechanism for multi-tenant workload control. - Example priorities: - `service_wg`: weight 50 - `batch_wg`: weight 10 - `dashboard_wg`: weight 5 - Resource groups could also specify `mem_limit` and `concurrency_limit`. - StarRocks uses a scheduler inspired by Linux CFS, with pipeline drivers yielding in roughly 100 ms time slices. ## Using `exclusive_cpu_cores` for Strong Isolation - `exclusive_cpu_cores` reserves physical CPU cores for a resource group. - StarRocks binds worker threads to those cores using `pthread_setaffinity_np`. - The group receives separate pools for: - `DriverExecutor` - `ScanExecutor` - `ConnectorScanExecutor` - This prevents the protected workload from competing with shared thread pools. - `exclusive_cpu_cores` and `cpu_weight` cannot be used together within the same resource group, although both types can coexist in one cluster. - The setting is limited to `(0, min_be_cpu_cores - 1]`. - Because it is more rigid and consumes dedicated capacity, Toss recommends using it only when relative priority is insufficient. ## Toss Shopping Case - A cluster handled both real-time queries from `shopping_service` and heavy workloads from `commerce_batch`. - Initially, both workloads had similar priority, allowing large batch queries to degrade service latency. - First adjustment: - Increase `shopping_service`’s `cpu_weight` - Lower `commerce_batch`’s weight - This improved prioritization but did not eliminate latency spikes when heavy batch work overlapped with roughly 1,500 service requests per minute. - Second adjustment: - Place `shopping_service` in its own resource group - Assign dedicated CPU cores with `exclusive_cpu_cores` - Afterward, service latency remained stable even during heavy batch execution. - The operational approach was therefore incremental: begin with weights and escalate to dedicated cores only when necessary. ## Classifier Design and Resource Controls - Resource Groups control how resources are allocated; Classifiers determine which queries enter each group. - Classifiers can match attributes such as: - User - Role - Query type - Source IP - Database - The article recommends using stable identifiers such as `user` or `db` for reliable production behavior. - Examples include mapping service `SELECT` queries by service account and assigning server-side batch queries according to their dedicated user. - CPU isolation alone is insufficient for memory-heavy full scans or sudden spikes involving hundreds of concurrent queries, so memory and concurrency limits are also important. Toss’s practical recommendation is to start with clear workload classification and `cpu_weight`, then add memory and concurrency limits. Use `exclusive_cpu_cores` selectively for latency-sensitive workloads whose SLAs cannot be protected through proportional CPU scheduling alone.

Read original(opens in new tab)
Database DesignMysqlHadoopStarrocks+4
toss4 min readCurated summary

Applying Post-Quantum Cryptography for the Quantum Computing Era: Why Implement It 10 Years Early?

Toss Payments’ hardest legacy-modernization challenge was not replacing old systems, but improving security across tens of thousands of merchants with diverse, outdated environments. Over four years, it gradually introduced HTTP/3, removed vulnerable cipher suites, deployed TLS 1.3, and ultimately adopted post-quantum cryptography (PQC) in April 2026. The central lesson is that security upgrades must begin early and be introduced gradually, with merchant support and backward compatibility built in. ## Breaking the Inertia of Legacy Systems - Mission-critical payment services tend to follow the principle: “If it works, don’t touch it.” - Security protocol changes are particularly difficult because they can affect every merchant integration and may be hard to troubleshoot or roll back. - Many merchants still operate decades-old server-side systems that cannot support modern security policies. - Documentation alone is often insufficient, especially for merchants without dedicated development teams. - Because every API, SDK, payment window, and server connection is part of the security boundary, Toss Payments could not improve security independently of its merchants. ## Why Existing Encryption Must Evolve - Modern HTTPS, banking, and payment systems rely heavily on RSA and ECDSA. - These algorithms are considered secure because factoring large numbers and solving elliptic-curve problems is impractical for classical computers. - Quantum computers could solve these problems efficiently, making current public-key cryptography vulnerable. - The anticipated point at which quantum computers can break these systems is often called “Q-Day.” - The “Harvest Now, Decrypt Later” threat means attackers can collect encrypted payment data today and decrypt it years later when quantum computers become practical. ## A Four-Year Security Upgrade Program Toss Payments chose a gradual migration strategy to improve security without abruptly disrupting merchant payments: - **2022:** Introduced HTTP/3, which requires TLS 1.3. - **2022–2025:** Removed vulnerable TLS cipher suites. - **2022–2025:** Enabled TLS 1.3 across all endpoints. - **April 2026:** Introduced post-quantum cryptography. ## HTTP/3 as a Low-Impact Starting Point - HTTP/3 improves speed and reliability on unstable networks. - Because it requires TLS 1.3, enabling HTTP/3 also raised security standards. - Modern browsers automatically select HTTP/3, so merchants required no configuration changes. - This made HTTP/3 an effective first step with minimal migration risk. ## Gradual Cipher Suite Removal - A cipher suite defines the algorithms used by a client and server to establish encrypted communication. - Some legacy merchant servers supported only vulnerable suites, such as `TLS_RSA_WITH_AES_128_CBC_SHA`. - Removing them immediately could stop payments for affected merchants, while delaying removal would leave the wider ecosystem exposed. - Toss Payments used: - Merchant-by-merchant compatibility analysis - Individual notifications six months to a year in advance - Environment-specific documentation and configuration guidance - Technical consulting where necessary - The Technical Account Manager team was essential in coordinating these changes and communicating with merchants in accessible language. ## TLS 1.3 Deployment - TLS 1.2 remained the minimum supported version, while TLS 1.3 was added alongside it. - Clients capable of TLS 1.3 automatically use the stronger protocol. - Older clients continue using TLS 1.2 without forced changes. - TLS 1.3 was enabled endpoint by endpoint from 2022 and supported across all endpoints by 2025. - The process demonstrated that ecosystem-wide security improvements require more time helping merchants migrate than technically changing the servers. ## Post-Quantum Cryptography - Toss Payments began preparing for PQC in 2025 and completed deployment in April 2026. - Modern browsers and clients that support PQC automatically use stronger quantum-resistant channels. - Unsupported environments continue using established encryption methods, preserving compatibility. - Merchants do not need to change configurations or update their integrations. - The approach provides stronger protection against future quantum attacks while minimizing present-day disruption. ## Cross-Team Collaboration - **Infra Team:** Applied PQC within Toss Payments’ private data-center infrastructure and physical hardware. - **Server Platform Team:** Integrated PQC into live traffic paths in AWS. - **TAM Team:** Used its experience from the cipher-suite migration to guide merchants and assess integration environments. - The result was a large-scale, proactive security deployment across the private payment ecosystem. Toss Payments’ experience suggests that organizations should start security migrations well before threats become immediate. Compatibility layers, staged enforcement, and sustained technical support allow legacy ecosystems to adopt stronger security without sacrificing availability.

Read original(opens in new tab)
Database DesignApi IntegrationPost Quantum CryptographyHttp 3+3
naver1 min readCurated summary

Naver Search's Large-scale Metric Storage: VictoriaMetrics Operation Story

The provided content does not contain a substantive tech blog post. It consists of NAVER D2 navigation links, a “Hello world” placeholder, and a copyright notice, so there are no technical arguments or conclusions to summarize. ## Page Contents - “naver D2” branding - “Hello world” placeholder text - Links to: - D2 News - About D2 - NAVER Developers - DEVIEW - OpenSource - D2 STARTUP FACTORY - Copyright © NAVER Corp. All Rights Reserved. No practical technical recommendation can be derived from the provided text.

Read original(opens in new tab)
Open SourceSoftware DevelopmentDeveloper CommunityStartups
kakao3 min readCurated summary

The Calendar We Designed for KakaoTalk Booking

KakaoTalk Reservation built a time-block calendar to help sellers understand inventory and bookings more easily than with a card list. The main challenge was arranging bookings with different start times and durations so that they remain readable and use space efficiently. The solution combines sorting rules, graph-based layout calculation, DFS, and additional expansion logic for edge cases. ## Product Requirements - The calendar is designed for the seller-facing reservation management center. - Each time slot can contain up to 10 bookings. - A booking can last from one to six hours. - Booking blocks should be displayed as clearly as possible without leaving unnecessary gaps. - The input data provides booking start and end times, while the frontend must calculate the visual layout. ## Booking Placement Rules - **Sort by earliest start time** - Earlier bookings are placed first to match the seller’s natural workflow. - This also supports the typical visual scanning order from the upper-left toward the lower-right. - **For bookings starting at the same time, sort by longest duration** - Longer bookings can block shorter bookings from expanding. - Placing them first gives them enough space and allows later bookings to occupy the remaining areas more effectively. ## Graph-Based Expansion - The bookings are modeled as nodes in a graph. - Each node stores relationships with preceding and following overlapping bookings. - A depth-first search calculates: - Each node’s depth, representing its horizontal position. - The maximum distance to the final booking in its connected path. - These values are used to calculate: - `left`: the node’s horizontal starting position. - `width`: how far the booking can expand across available space. - Nodes at the far-left edge of the graph are processed first, allowing the bookings to fill the calendar while respecting overlaps. ## Handling Layout Exceptions - The initial graph and DFS calculation did not always fill all available space. - Problems occurred when: - Multiple root nodes existed. - An upper root node had a longer path than a lower root node. - Connected nodes were constrained by earlier width calculations. - The implementation searches for unused gaps between neighboring nodes. - When multiple gaps exist, connected nodes are expanded by the smallest available amount needed to close the gaps. - A gap is detected when the next node’s `left` position is greater than the current node’s `left + width`. ## Lessons from the Implementation - A calendar that appears visually simple can require substantial algorithmic design. - Frontend developers are responsible not only for rendering data, but also for deciding how that data should be presented to users. - The calendar is treated as an evolving implementation that will be refined as new bugs, data patterns, and better algorithms are discovered. The practical approach is to begin with clear sorting rules, represent overlapping bookings as a graph, use DFS to determine layout constraints, and add targeted post-processing for unused space and edge cases.

Read original(opens in new tab)
User InterfaceData VisualizationFrontendCalendar Ui+2
cloudflare3 min readCurated summary

Making Rust Workers reliable: panic and abort recovery in wasm‑bindgen

Rust Workers historically treated Rust panics and aborts as fatal WebAssembly failures, potentially poisoning a Worker instance and causing unrelated requests to fail. Cloudflare’s latest work upstreamed into `wasm-bindgen` adds comprehensive recovery: `panic=unwind` preserves application state after recoverable panics, while abort handling ensures Rust code cannot run again after an unrecoverable abort. ## Initial Recovery Mitigations - Early Rust Workers used a custom panic handler to track failures and reinitialize the entire application before serving later requests. - JavaScript bindings were wrapped with Proxy-based indirection so every Rust entry point passed through recovery logic. - Generated bindings were modified to reinitialize the WebAssembly module after failures. - This approach shipped by default in `workers-rs` 0.6 and prevented persistent failure modes, but reinitialization could discard in-memory state. ## Panic Unwinding with WebAssembly Exception Handling - WebAssembly’s `wasm32-unknown-unknown` target traditionally defaults to `panic=abort`, turning panics into traps and `WebAssembly.RuntimeError` exceptions. - With WebAssembly Exception Handling support, Rust can be compiled using: ```bash RUSTFLAGS='-Cpanic=unwind' cargo build -Zbuild-std ``` - Unwinding allows Rust destructors to run, preserving state and cleaning up resources instead of terminating the entire instance. - `std::panic::catch_unwind` can translate a Rust panic into a recoverable `Result`. ## Changes to wasm-bindgen - The Walrus WebAssembly parser was updated to understand `try`/`catch` exception-handling instructions. - The descriptor interpreter was updated to evaluate code containing exception blocks. - Generated exports now catch Rust panics at the Rust–JavaScript boundary and expose them as `PanicError` exceptions. - Async exports reject their JavaScript promises with `PanicError`. - Exported functions use `extern "C-unwind"` so unwinding is explicitly permitted across the boundary. - A `MaybeUnwindSafe` trait checks `UnwindSafe` requirements only when compiling with `panic=unwind`. - For closures that cannot safely unwind, `Closure::new_aborting` provides an explicit alternative that terminates on panic rather than risking invalid state. ## Results of `panic=unwind` - Panics in exported Rust functions are caught by `wasm-bindgen`. - JavaScript receives a `PanicError`. - Async calls reject their promises instead of poisoning the Worker. - Rust destructors execute correctly. - The WebAssembly instance remains valid and reusable. - Stateful applications, including Durable Objects, can recover without losing all in-memory state. ## Abort Recovery - `panic=unwind` cannot handle aborts such as out-of-memory failures because aborts do not unwind. - The remaining recovery mechanism prevents Rust code from being re-entered after an abort, avoiding repeated execution in a corrupted WebAssembly state. - Together, unwinding and abort recovery prevent one failed request from poisoning sibling or future requests. The recommended approach is to use the latest `wasm-bindgen` and Rust Workers releases, enabling `panic=unwind` where state preservation matters while using explicit aborting closures when unwind safety cannot be guaranteed.

Read original(opens in new tab)
Database DesignRustWebassemblyWasm Bindgen+2
line4 min readCurated summary

Implementing SLO/SLI for Improved Reliability Part 3 - Service Application Cases

SLI/SLO adoption is not merely a matter of choosing metrics; it requires redefining how a service is understood from the user’s perspective. LINE’s SRE team applies this approach by identifying critical user journeys, measuring reliability with clear criteria, and setting realistic objectives. The resulting data helps teams balance reliability, engineering costs, feature delivery, and incident response. ## The Mindset Behind SLI/SLO ### Understanding the Service and Users - Begin by identifying the services and features users depend on. - Map user journeys and select critical user journeys (CUJs) based on: - How frequently users use a feature - Whether the feature is essential to the service - Its relationship to business objectives - Aligning SLOs with business goals ensures that reliability work supports organizational priorities. ### Communication and Collaboration - SLI/SLOs should be defined and managed collaboratively rather than by a single team. - Product or service owners define CUJs because they understand the user experience best. - Infrastructure teams provide scalable systems for collecting and managing metrics. - SREs build the measurement tools and processes used to monitor and improve reliability. - Shared ownership is essential so SLOs can guide both daily operations and new feature launches. ## Implementing SLI/SLOs ### Analyze Critical User Journeys - List the services and functions provided to users. - Ask: - Which features are used most often? - Which features are indispensable? - LINE examples include: - Account registration - Sending and receiving messages - User authentication and encryption - LINE Login - Profile information - The goal is not to include every feature, but to select the most important ones from the user’s perspective. ### Define Service Level Indicators For each CUJ, determine: - **Measurement location:** Choose the point that best represents the user experience, such as a gateway, frontend, or backend. - **Measurement API:** Select a representative API to avoid unnecessarily complex calculations. - **Success criteria:** Establish clear boundaries between successful and failed requests. Common SLI criteria include: - **Latency:** Define a percentile, such as the 99.9th percentile, and the maximum acceptable response time. - **Success rate:** Define the required percentage of successful responses during the measurement period. For example, a messaging service might require 99.9% of requests to complete within 500 milliseconds and 99.999% of all requests to receive successful responses. If a CUJ cannot be measured reliably or its success criteria cannot be defined clearly, it may be excluded or supported with a dedicated measurement metric. ### Set SLO Targets - Define the reliability level the service must maintain over a specific period. - An example target is achieving the defined latency and success-rate criteria for 99.9% of a 28-day period. - Targets must be realistic: - Excessively high targets increase operational and infrastructure costs. - Excessively low targets can result in poor user experiences. - SLOs should balance reliability requirements with available resources. ### Visualize Reliability - Provide dashboards that allow all stakeholders to understand the current SLO status quickly. - Show overall SLO performance and error-budget consumption, with detailed dashboards for individual CUJs. - Keep dashboards simple and easy to scan rather than displaying excessive information. - Use visual indicators such as: - Green for healthy performance - Orange for warning conditions - Red for missed objectives ## How SLI/SLOs Are Used ### Quantifying Reliability - Replace vague descriptions such as “the service is slow” with measurable statements. - Teams can identify issues such as latency exceeding a 400-millisecond SLI threshold or success rates falling below 99.99%. - Dashboards also help correlate periods of poor performance with incidents or operational changes. ### Guiding Resource Allocation - SLOs show whether reliability targets are being met. - Error budgets indicate how much additional failure or downtime is acceptable. - When performance exceeds the SLO and the error budget is healthy, teams can invest more aggressively in: - New features - Faster release cycles - Product experimentation - When little error budget remains, resources can instead focus on prevention, remediation, and reliability improvements. ### Supporting On-Call Operations - LINE uses alerts triggered by changes in error-budget status to help on-call teams recognize and respond to service issues. - SLO reviews are also incorporated into regular meetings and preventive reliability work. SLI/SLO implementation works best as a shared, user-focused operating model. By combining clear CUJs, measurable criteria, realistic targets, and actionable dashboards, teams can make informed decisions about when to prioritize innovation and when to prioritize stability.

Read original(opens in new tab)
ObservabilitySite Reliability EngineeringResource AllocationService Level Indicator+4
gitlab3 min readCurated summary

GitLab AI Hackathon 2026: Meet the winners

Nearly 7,000 developers participated in GitLab’s 2026 AI Hackathon, creating more than 600 agents and workflows for the GitLab Duo Agent Platform. The winning projects focused on practical software delivery challenges—including organizational knowledge loss, security, compliance, migrations, and sustainability—rather than simple chatbot interactions. The results suggest that agentic AI is becoming most valuable when integrated directly into development workflows and given richer project context. ## Hackathon Scope and Evaluation - The hackathon ran from February 9 to March 25, 2026, on Devpost. - Google Cloud and Anthropic co-sponsored the event, contributing judges, prizes, and cloud resources. - Nineteen judges evaluated projects on: - Technical execution - Design - Potential impact - Quality of the idea - Total prizes reached $65,000. ## Grand Prize: LORE - LORE, or Living Organizational Record Engine, addresses the loss of institutional knowledge when engineers leave. - It combines: - Eight specialized agents - A router that directs questions to the appropriate agent - Protections against circular loops in its knowledge graph - A visual dashboard - Carbon tracking - Its command-line tool includes 43 tests, leading judges to describe it as a polished product rather than a typical hackathon prototype. ## Google Cloud and Anthropic Winners - **Gitdefender**, the Google Cloud Grand Prize winner, detects security issues during code review, writes fixes, and opens the review automatically. - **Aegis**, the Google Cloud Runner Up, explains the reasoning behind its AI decisions and is deployed on Google Cloud. - **GraphDev**, the Anthropic Grand Prize winner, maps code relationships and shows how systems evolve, helping developers understand the impact of changes. - **DocSync**, the Anthropic Runner Up, uses Detector, Writer, and Reviewer agents to update documentation. It opens a review when confident and creates an issue for human review when uncertain. ## Category Winners - **Time-Traveler**, winner for technical achievement, creates a safe copy of a production environment and runs database migrations against it using five connected agents, PostgreSQL, real data, and Google Cloud deployment. - **RedAgent**, the most impactful project, verifies AI-generated security findings before developers act on them, addressing distrust in automated reports. - **Launch Control**, recognized for ease of use, combined polished user experience, strong infrastructure, and sustainability considerations. ## Sustainability-Focused Projects - Five projects received sustainability prizes or bonuses as the organizers highlighted the growing energy cost of CI/CD systems and large language models. - **GreenPipe** analyzes CI/CD pipelines and generates carbon-footprint reports. - Sustainable Design bonuses recognized projects including: - **BugFlow**, which generated 10 fixes from one bug report in 20 minutes - **DELTA Cyber Reasoning**, an automated fuzz-testing tool - **CarbonLint**, which applies code analysis to energy consumption - **TFGuardian**, which includes carbon-footprint analysis - One project reduced monthly costs from $556 to $18, representing a reported 96% carbon reduction. ## Honorable Mentions - **SecurityMonkey** tests security scanners by injecting known vulnerabilities. - **stregent** enables CI/CD investigation and fixes through WhatsApp. - **Compliance Sentinel** evaluates merge requests for compliance risk and blocks critical violations. - **Carbon Tracker** measures the carbon footprint of individual pipeline jobs and suggests improvements. - **RepoWarden** captures the rationale behind code, not only its behavior. - **MR Compliance Auditor** maps merge-request evidence to SOC 2 controls and displays compliance scores in real time. ## What Comes Next The projects operated within a single GitLab project, but many teams supplemented their agents with local knowledge graphs to understand code relationships and dependencies. GitLab plans to build on this approach in future hackathons by providing agents with richer context. GitLab’s hackathon demonstrates that the strongest AI agents are workflow-integrated tools that can investigate, make decisions, execute changes, and involve humans when needed. Developers can explore the 600-plus projects in the gallery or build their own agents on the GitLab Duo Agent Platform.

Read original(opens in new tab)
Database DesignMachine LearningCI/CDGitlab+4
spotify3 min readCurated summary

Better Experiments with LLM Evals — A funnel, not a fork | Spotify Engineering

LLM evaluations and A/B experiments serve different purposes and should work as a funnel rather than alternatives. Evals verify whether a change meets qualitative standards and filter out weak ideas, while experiments validate whether it improves real user and business outcomes. Their greatest value comes from a feedback loop that continuously calibrates eval scores against online results. ## Evals as Verification, Experiments as Validation - LLM judges can assess relevance, coherence, tone, intent alignment, and other qualities at scale. - Evals identify promising candidates before they consume experiment capacity. - Experiments determine whether users actually respond better to the change. - An eval can uncover unexpected failure patterns, guide product fixes, and later verify that violations have decreased. - It cannot establish whether those fixes improve long-term outcomes such as engagement, trust, or retention. ## The Importance of Guardrails - Evals typically measure selected quality dimensions, not every possible business risk. - Spotify reports that roughly 42% of launched experiments are rolled back because of regressions in secondary metrics such as crashes, session length, or retention. - Online experiments expose production effects and monitor guardrail metrics that offline evals may miss. - Although only about 12% of Spotify’s A/B tests produce a shipped positive result, approximately 64% generate useful learning. ## Calibrating Evals Against Outcomes - Evals are proxies, so their scores must be validated against the outcomes they are intended to predict. - LLM judges introduce an additional calibration layer on top of conventional metrics such as precision, recall, and ranking scores. - Judges can reward superficial patterns or miss improvements that matter in real-world use. For example, Qodo’s coding evals did not detect improvements in Anthropic’s Opus 4.5 on longer tasks. - Both judges and quantitative metrics can drift, making offline-to-online comparison essential. - Continuous calibration clarifies when evals are reliable verification tools and whether they may eventually become strong enough to support validation. ## Closing the Evaluation Loop - Run evals early and frequently to select the strongest treatments. - Use experiments to confirm user impact, assess business outcomes, and detect unintended regressions. - Apply the same LLM evals to A/B test data to compare qualitative scores with actual user results. - A mismatch between eval scores and experiment outcomes is valuable diagnostic information: - Improved scores and improved outcomes validate the judge. - Improved scores without better outcomes show that the judge is measuring something that may not drive value. - Use lightweight experiments for iteration and learning, and more rigorous tests for launch decisions. The practical recommendation is to treat LLM evals as an upstream filter and a downstream calibration tool—not a replacement for experimentation. This funnel improves test efficiency while making both the judges and product decisions more trustworthy over time.

Read original(opens in new tab)
Machine LearningA B TestingLlm EvalsOnline Experiments+3
gitlab3 min readCurated summary

GitLab Patch Release: 18.11.1, 18.10.4, 18.9.6 | GitLab Docs

GitLab released patch versions 18.11.1, 18.10.4, and 18.9.6 on April 22, 2026, addressing multiple security vulnerabilities and bugs in CE and EE. Self-managed installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes include unauthenticated GraphQL and browser-based attacks, several denial-of-service flaws, and access-control weaknesses. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Affects all deployment types unless otherwise specified, including Omnibus, source installations, and Helm charts. - Recommended fixed versions: - 18.11.1 - 18.10.4 - 18.9.6 - GitLab issues detailing security vulnerabilities are made public 30 days after the relevant patch release. - GitLab publishes both scheduled patch releases, issued on the second and fourth Wednesdays, and ad-hoc critical patches for high-severity vulnerabilities. ## High-Severity Vulnerabilities - **CVE-2026-4922 — GraphQL CSRF** - CVSS 8.1. - An unauthenticated attacker could execute GraphQL mutations on behalf of an authenticated user because of insufficient CSRF protection. - Affects versions before 18.9.6, 18.10.4, and 18.11.1. - **CVE-2026-5816 — Web IDE path validation** - CVSS 8.0. - Under certain conditions, improper path validation could allow unauthenticated attackers to execute arbitrary JavaScript in a user’s browser session. - Affects the 18.10 and 18.11 release lines before the listed patches. - **CVE-2026-5262 — Storybook cross-site scripting** - CVSS 8.0. - Improper input validation could allow unauthenticated access to tokens in the Storybook development environment. - Affects versions from 16.1 through the unpatched 18.9, 18.10, and 18.11 releases. ## Denial-of-Service Fixes - **CVE-2025-0186:** Crafted requests to the discussions endpoint could exhaust server resources. - **CVE-2026-1660:** Improper input validation during Jira issue imports could enable resource exhaustion. - **CVE-2025-6016:** Insufficient limits when retrieving notes could cause service disruption. - **CVE-2025-3922:** Resource-allocation weaknesses in the GraphQL API could allow authenticated users to overwhelm the system. - Each issue carries a CVSS score of 6.5 and generally requires authentication. ## Access-Control and Session Fixes - **CVE-2026-6515 — Virtual registry credentials** - CVSS 5.4. - Invalidated or incorrectly scoped credentials could continue accessing Virtual Registries. - **CVE-2026-5377 — Confidential issue titles** - CVSS 4.3. - Authenticated users could potentially view titles of confidential or private issues in public projects. - **CVE-2026-3254 — Mermaid sandbox** - CVSS 3.5. - Improper validation could allow authenticated users to load unauthorized content into another user’s browser. - The release also lists **CVE-2025-9957**, involving improper access control in the project fork relationship API; the provided text does not include its full impact or severity details. Self-managed GitLab administrators should apply the appropriate patch release as soon as possible, especially because several vulnerabilities permit unauthenticated browser or API attacks.

Read original(opens in new tab)
GitlabGraphQLVulnerability ManagementCross Site Scripting+4