Techlist.io - Korean Tech Blog Curator

naverOriginal article

Naver TV (opens in new tab)

This technical session from NAVER ENGINEERING DAY 2025 explores the architectural journey of building a low-latency query system for real-time transaction reports. The project focuses on resolving the tension between high data freshness, massive scalability, and rapid response times for complex, multi-dimensional filtering. By leveraging Apache Iceberg in conjunction with StarRocks’ materialized views, the team established a performant data pipeline that meets the demands of modern business intelligence. ### Challenges in Real-Time Transaction Reporting * **Query Latency vs. Data Freshness:** Traditional architectures often struggle to provide immediate visibility into transaction data while maintaining sub-second query speeds across diverse filter conditions. * **High-Dimensional Filtering:** Users require the ability to query reports based on numerous variables, necessitating an engine that can handle complex aggregations without pre-defining every possible index. * **Scalability Requirements:** The system must handle increasing transaction volumes without degrading performance or requiring significant manual intervention in the underlying storage layer. ### Optimized Architecture with Iceberg and StarRocks * **Apache Iceberg Integration:** Iceberg serves as the open table format, providing a reliable foundation for managing large-scale data snapshots and ensuring consistency during concurrent reads and writes. * **StarRocks for Query Acceleration:** The team selected StarRocks as the primary OLAP engine to take advantage of its high-speed vectorized execution and native support for Iceberg tables. * **Spark-Based Processing:** Apache Spark is utilized for the initial data ingestion and transformation phases, preparing the transaction data for efficient storage and downstream consumption. ### Enhancing Performance via Materialized Views * **Pre-computed Aggregations:** By implementing Materialized Views, the system pre-calculates intensive transaction summaries, significantly reducing the computational load during active user queries. * **Automatic Query Rewrite:** The architecture utilizes StarRocks' ability to automatically route queries to the most efficient materialized view, ensuring that even ad-hoc reports benefit from pre-computed results. * **Balanced Refresh Strategies:** The research focused on optimizing the refresh intervals of these views to maintain high "freshness" while minimizing the overhead on the cluster resources. The adoption of a modern lakehouse architecture combining Apache Iceberg with a high-performance OLAP engine like StarRocks is a recommended strategy for organizations dealing with high-volume, real-time reporting. This approach effectively decouples storage and compute while providing the low-latency response times necessary for interactive data analysis.

naverOriginal article

Research on Protecting the Webtoon (opens in new tab)

Naver Webtoon is proactively developing technical solutions to safeguard its digital creation ecosystem against evolving threats like illegal distribution and unauthorized generative AI training. By integrating advanced AI-based watermarking and protective perturbation technologies, the platform successfully tracks content leaks and disrupts unauthorized model fine-tuning. These efforts ensure a sustainable environment where creators can maintain the integrity and economic value of their intellectual property. ## Challenges in the Digital Creation Ecosystem - **Illegal Content Leakage**: Unauthorized reproduction and distribution of digital content infringe on creator earnings and damage the platform's business model. - **Unauthorized Generative AI Training**: The rise of fine-tuning techniques (e.g., LoRA, Dreambooth) allows for the unauthorized mimicry of an artist's unique style, distorting the value of original works. - **Harmful UGC Uploads**: The presence of violent or suggestive user-generated content increases operational costs and degrades the service experience for readers. ## AI-Based Watermarking for Post-Tracking - To facilitate tracking in DRM-free environments, Naver Webtoon developed an AI-based watermarking system that embeds invisible signals into the pixels of digital images. - The system is designed around three conflicting requirements: **Invisibility** (signal remains hidden), **Robustness** (signal survives attacks like cropping or compression), and **Capacity** (sufficient data for tracking). - The technical pipeline involves three neural modules: an **Embedder** to insert the signal, a differentiable **Attack Layer** to simulate real-world distortions, and an **Extractor** to recover the signal. - Performance metrics show a high Peak Signal-to-Noise Ratio (PSNR) of over 46 dB, and the system maintains a signal error rate of less than 1% even when subjected to intense signal processing or geometric editing. ## IMPASTO: Disrupting Unauthorized AI Training - This technology utilizes **protective perturbation**, which adds microscopic changes to images that are invisible to humans but confuse generative AI models during the training phase. - It targets the way diffusion models (like Stable Diffusion) learn by either manipulating latent representations or disrupting the denoising process, preventing the AI from accurately mimicking an artist's style. - The research prioritizes overcoming the visual artifacts and slow processing speeds found in existing academic tools like Glaze and PhotoGuard. - By implementing these perturbations, any attempts to fine-tune a model on protected work will result in distorted or unintended outputs, effectively shielding the artist's original style. ## Integrated Protection Frameworks - **TOONRADAR**: A comprehensive system deployed since 2017 that uses watermarking for both proactive blocking and retrospective tracking of illegal distributors. - **XPIDER**: An automated detection tool tailored specifically for the comic domain to identify and block harmful UGC, reducing manual inspection overhead. - These solutions are being expanded not just for copyright protection, but to establish long-term trust and reliability in the era of AI-generated content. The deployment of these AI-driven defense mechanisms is essential for maintaining a fair creative economy. By balancing visual quality with robust protection, platforms can empower creators to share their work globally without the constant fear of digital theft or stylistic mimicry.

slack3 min readCurated summary

Streamlining Security Investigations with Agents

Slack’s Security Engineering team uses a multi-agent AI system to investigate security alerts across billions of daily events. After finding that a single prompt produced inconsistent results, the team replaced it with a controlled workflow of specialized model invocations, structured outputs, and application-level orchestration. The resulting system improves consistency, enables evidence review, and allocates more capable models only where they add the most value. ## From Prompt Prototype to Controlled Workflow - The initial prototype consisted of a roughly 300-word prompt defining: - The analyst’s role - Available data sources - Investigation methodology - Report formatting - Response classifications - A stdio-based MCP server safely exposed selected security data sources to the model. - A coding-agent CLI served as the prototype execution environment. - Results varied significantly: - Sometimes the model cross-referenced evidence effectively. - Other times it reached convenient or unsupported conclusions too quickly. - Prompt refinements helped somewhat, but prompts were ultimately too limited for fine-grained process control. ## Structured Investigation Tasks - Slack decomposed the investigation into a sequence of model invocations. - Each invocation performs one well-defined task and returns a structured output. - The application chains these tasks together and passes only the necessary context between stages. - Structured outputs use JSON schemas to constrain model responses. - They improve predictability, but can still fail when schemas are too complex and remain vulnerable to hallucination or attempts to circumvent constraints. - Guidance such as “question your evidence” became an explicit workflow step rather than merely an instruction in a prompt. ## Persona-Based Agent Architecture - Slack drew inspiration from research on meta-prompting, multi-persona collaboration, and security tabletop exercises. - Instead of representing multiple personas within one model call, Slack implemented each persona as an independent model invocation. - Every agent/task pair has: - A defined responsibility - A carefully designed output structure - Specific prompts and instructions - Potentially different models and tools - The application orchestrates the agents and controls how knowledge moves through the investigation. ## The Investigation Loop - **Director agent** - Guides the investigation from beginning to end. - Forms questions for domain experts. - Uses a journaling tool to plan and organize progress. - Decides how to continue based on reviewed findings and timelines. - **Expert agents** - Investigate questions using specialized knowledge and data sources. - Slack currently uses four domains: - **Access:** Authentication, authorization, and perimeter services - **Cloud:** Infrastructure, compute, orchestration, and networking - **Code:** Source code and configuration management - **Threat:** Threat intelligence and analysis - **Critic agent** - Acts as a meta-expert reviewing domain findings. - Applies a defined rubric to assess quality. - Adds analysis and credibility scores to individual findings. - Helps identify reliable evidence and reduce hallucinations. - Returns its conclusions to the Director, closing the investigation loop. - The Critic’s mildly adversarial role provides an independent challenge to expert conclusions. ## The Knowledge Pyramid - Different stages use different model capabilities and costs. - Domain experts operate at the base: - They query complex data sources. - They may make many tool calls. - Processing their results can consume substantial tokens. - The Critic reviews the larger set of expert findings and identifies the most valuable or credible evidence. - Higher-level reasoning can therefore use a smaller, more focused context. - Because each stage is independent, Slack can select different model versions, prompts, tools, and output formats for different tasks. Slack’s main recommendation is to treat complex agent behavior as an explicitly orchestrated workflow rather than relying on one increasingly elaborate prompt. Specialized agents, structured outputs, independent critique, and tiered model usage provide more predictable investigations while preserving the flexibility of AI-assisted analysis.

Read original(opens in new tab)
tossOriginal article

In Search of the Toss Brand Symbol (opens in new tab)

Toss, a leading Korean fintech platform, embarked on a UX research journey to define its visual identity as it expanded from digital services into offline environments like Toss Pay payment stations. The study revealed that while users strongly associate the brand with seamless "usability," they lacked a single, clear mental image of a visual symbol. By analyzing user perceptions of fonts, colors, and shapes, Toss identified a specific visual formula—combining the app icon shape with a white, blue, and black palette—to ensure the brand remains instantly recognizable in the physical world. ## The Challenge of Offline Brand Recognition * The project began with the need to design "danglers" (small signage at payment counters) to signal that Toss Pay is accepted at offline merchants. * While Toss had successfully used various logo iterations online, the team realized that "Toss-ness" learned within the app might not automatically translate to unfamiliar offline environments. * Initial internal debates focused on superficial visual tweaks, such as background colors or language choices, rather than understanding the core assets that trigger brand recognition. ## Identifying Usability as the Core Brand Image * In-depth interviews were conducted with participants selected for their ability to articulate abstract brand impressions. * Research showed that users primarily associate Toss with keywords like "clean," "practical," and "convenient," rather than specific aesthetic elements. * One participant described Toss as a "program made by a genius engineer in Excel," highlighting that the brand’s value was rooted in its utility rather than a distinct visual symbol. * This presented a challenge: since the "app experience" cannot be felt through a static offline sign, the team had to find a visual surrogate for that functional reliability. ## Deconstructing the Toss Symbol: Font, Color, and Shape * **Font:** Testing revealed that the most recognizable font was the black English "toss" wordmark, primarily because users see it most often in external media and news rather than inside the app. * **Color:** Surprisingly, users did not associate Toss with a single shade of blue. Instead, they recognized the specific combination of a "blue logo on a white background." * **Logo:** When asked to draw the logo from memory, users consistently included a square border. This indicated that users perceive the brand’s "face" specifically as the smartphone app icon (the blue logo inside a rounded square) rather than the standalone logo mark. ## Implementing the "Toss Formula" in Design * The research led to a refined brand identity formula: **White background + Black bold English font + Blue app-icon-shaped logo.** * In the "10 to 100" 10th-anniversary campaign, the company shifted away from all-blue backgrounds in favor of this white-based combination to maximize recognition. * Toss Pay payment screens were updated to remove blue backgrounds, adopting the white-and-black layout to align with how users intuitively identify the service. For UX researchers and designers, this case demonstrates that brand identity is often a composite of environmental cues rather than a single graphic. When moving a digital-first brand into the physical world, it is essential to look beyond the logo and identify the specific "visual formula" that triggers the user's memory of the product experience.

tossOriginal article

From Legacy Payment Ledger to Scalable System (opens in new tab)

Toss Payments successfully modernized a 20-year-old legacy payment ledger by transitioning to a decoupled, MySQL-based architecture designed for high scalability and consistency. By implementing strategies like INSERT-only immutability and event-driven domain isolation, they overcame structural limitations such as the inability to handle split payments. Ultimately, the project demonstrates that robust system design must be paired with resilient operational recovery mechanisms to manage the complexities of large-scale financial migrations. ### Legacy Ledger Challenges * **Inconsistent Schemas:** Different payment methods used entirely different table structures; for instance, a table named `REFUND` unexpectedly contained only account transfer data rather than all refund types. * **Domain Coupling:** Multiple domains (settlement, accounting, and payments) shared the same tables and columns, meaning a single schema change required impact analysis across several teams. * **Structural Limits:** A rigid 1:1 relationship between a payment and its method prevented the implementation of modern features like split payments or "Dutch pay" models. ### New Ledger Architecture * **Data Immutability:** The system shifted from updating existing rows to an **INSERT-only** principle, ensuring a reliable audit trail and preventing database deadlocks. * **Event-Driven Decoupling:** Instead of direct database access, the system uses Kafka to publish payment events, allowing independent domains to consume data without tight coupling. * **Payment-Approval Separation:** By separating the "Payment" (the transaction intent) from the "Approval" (the specific financial method), the system now supports multiple payment methods per transaction. ### Safe Migration and Data Integrity * **Asynchronous Mirroring:** To maintain zero downtime, data was initially written to the legacy system and then asynchronously loaded into the new MySQL ledger. * **Resource Tuning:** Developers used dedicated migration servers within the same AWS Availability Zone to minimize latency and implemented **Bulk Inserts** to handle hundreds of millions of rows efficiently. * **Verification Batches:** A separate batch process ran every five minutes against a Read-Only (RO) database to identify and correct any data gaps caused by asynchronous processing failures. ### Operational Resilience and Incident Response * **Query Optimization:** During a load spike, the MySQL optimizer chose "Full Scans" over indexes; the team resolved this by implementing SQL hints and utilizing a 5-version Docker image history for rapid rollbacks. * **Network Cancellation:** To handle timeouts between Toss and external card issuers, the system uses specific logic to automatically send cancellation requests and synchronize states. * **Timeout Standardization:** Discrepancies between microservices were resolved by calculating the maximum processing time of approval servers and aligning all upstream timeout settings to prevent merchant response mismatches. * **Reliable Event Delivery:** While using the **Outbox pattern** for events, the team added log-based recovery (Elasticsearch and local disk) and idempotency keys in event headers to handle both missing and duplicate messages. For organizations tackling significant technical debt, this transition highlights that initial design is only half the battle. True system reliability comes from building "self-healing" structures—such as automated correction batches and standardized timeout chains—that can survive the unpredictable nature of live production environments.

kakaoOriginal article

YEYE is Watching – (opens in new tab)

Kakao developed YEYE, a dedicated Attack Surface Management (ASM) system, to proactively identify and manage the organization's vast digital footprint, including IPs, domains, and open ports. By integrating automated scanning with a human-led Daily Security Review (DSR) process, the platform transforms raw asset data into actionable security intelligence. This holistic approach ensures that potential entry points are identified and secured before they can be exploited by external threats. ## The YEYE Asset Management Framework * Defines attack surfaces broadly to include every external-facing digital asset, such as subdomains, API endpoints, and mobile APKs. * Categorizes assets using a standardized taxonomy based on scope (In/Out/Undefined), type (Domain/IP/Service), and identification status (Known/Unknown/3rd Party). * Implements a labeling system that converts diverse data formats from multiple sources into a simplified, unified structure for better visibility. * Establishes multi-dimensional relationships between assets, CVEs, certificates, and departments, allowing teams to instantly identify which business unit is responsible for a newly discovered vulnerability. ## Daily Security Review (DSR) * Operates on the principle that "security is a process, not a product," bridging the gap between automated detection and manual remediation. * Utilizes a rotating group system where security engineers review external feeds, public vulnerability news, and YEYE alerts every morning. * Focuses on detecting "shadow IT" or assets deployed without formal security reviews to ensure all external touchpoints are accounted for. ## Scalable and Efficient Scanning Architecture * Resolved internal network bandwidth bottlenecks by adopting a hybrid infrastructure that leverages public cloud resources for high-concurrency scanning tasks. * Developed a custom distributed scanning structure using schedulers and queues to manage multiple independent workers, overcoming the limitations of single-process open-source scanners. * Optimized infrastructure costs by identifying the "sweet spot" in server specifications, favoring the horizontal expansion of medium-spec servers over expensive, high-performance hardware. * Mitigates service impact and false alarms by using fixed IPs and custom User-Agent (UA) strings, allowing service owners to distinguish YEYE’s security probes from actual malicious traffic. To effectively manage a growing attack surface, organizations should combine automated asset discovery with a structured manual review process. Prioritizing data standardization and relationship mapping between assets and vulnerabilities is essential for rapid incident response and long-term infrastructure hardening.

tossOriginal article

Toss Payments' Open API (opens in new tab)

Toss Payments treats its Open API not just as a communication tool, but as a long-term infrastructure designed to support over 200,000 merchants for decades. By focusing on resource-oriented design and developer experience, the platform ensures that its interfaces remain intuitive, consistent, and easy to maintain. This strategic approach prioritizes structural stability and clear communication over mere functionality, fostering a reliable ecosystem for both developers and businesses. ### Resource-Oriented Interface Design * The API follows a predictable path structure (e.g., `/v1/payments/{id}`) where the root indicates the version, followed by the domain and a unique identifier. * Request and response bodies utilize structured JSON with nested objects (like `card` or `cashReceipt`) to modularize data and reduce redundancy. * Consistency is maintained by reusing the same domain objects across different APIs, such as payment approval, inquiry, and cancellation, which minimizes the learning curve for external developers. * Data representation shifts from cryptic legacy codes (e.g., SC0010) to human-readable strings, supporting localization into multiple languages via the `Accept-Language` HTTP header. * Standardized error handling utilizes HTTP status codes paired with a JSON error object containing specific `code` and `message` fields, allowing developers to either display messages directly or implement custom logic. ### Asynchronous Communication via Webhooks * Webhooks are provided alongside standard APIs to handle asynchronous events where immediate responses are not possible, such as status changes in complex payment flows. * Event types are clearly categorized (e.g., `PAYMENT_STATUS_CHANGED`), and the payloads mirror the exact resource structures used in the REST APIs to simplify parsing. * The system ensures reliability by implementing an Exponential Backoff strategy for retries, preventing network congestion during recipient service outages. * A dedicated developer center allows merchants to register custom endpoints, monitor transmission history, and perform manual retries if automated attempts fail. ### External Ecosystem and Documentation Automation * Developer Experience (DX) is treated as the core metric for API quality, focusing on how quickly and efficiently a developer can integrate and operate the service. * To prevent the common issue of outdated manuals, Toss Payments uses a documentation automation system based on the OpenAPI Specification (OAS). * By utilizing libraries like `springdoc`, the platform automatically syncs the technical documentation with the actual server code, ensuring that parameters, schemas, and endpoints are always up-to-date and trustworthy. To ensure the longevity of a high-traffic Open API, organizations should prioritize automated documentation and resource-based consistency. Moving away from cryptic codes toward human-readable, localized data and providing robust asynchronous notification tools like webhooks are essential steps for building a developer-friendly infrastructure.

naverOriginal article

Naver TV (opens in new tab)

Naver’s Integrated Search team is transitioning from manual fault response to an automated system using LLM Agents to manage the increasing complexity of search infrastructure. By integrating Large Language Models into the DevOps pipeline, the system evolves through accumulated experience, moving beyond simple alert monitoring to intelligent diagnostic analysis and action recommendation. ### Limitations of Traditional Fault Response * **Complex Search Flows:** Naver’s search architecture involves multiple interdependent layers, which makes manual root cause analysis slow and prone to human error. * **Fragmented Context:** Existing monitoring requires developers to manually synthesize logs and metrics from disparate telemetry sources, leading to high cognitive load during outages. * **Delayed Intervention:** Human-led responses often suffer from a "detection-to-action" lag, especially during high-traffic periods or subtle service regressions. ### Architecture of DevOps Agent v1 * **Initial Design:** Focused on automating basic data gathering and providing preliminary textual reports to engineers. * **Infrastructure Integration:** Built using a specialized software stack designed to bridge frontend (FE) and backend (BE) telemetry within the search infrastructure. * **Standardized Logic:** The v1 agent operated on a fixed set of instructions to perform predefined diagnostic tasks when triggered by specific system alarms. ### Evolution to DevOps Agent v2 * **Overcoming V1 Limitations:** The first iteration struggled with maintaining deep context and providing diverse actionable insights, necessitating a more robust agentic structure. * **Enhanced Memory and Learning:** V2 incorporates a more sophisticated architecture that allows the agent to reference historical failure data and learn from past incident resolutions. * **Advanced Tool Interaction:** The system was upgraded to handle more complex tool-calling capabilities, allowing the agent to interact more deeply with internal infrastructure APIs. ### System Operations and Evaluation * **Trigger Queue Management:** Implements a queuing system to efficiently process and prioritize multiple concurrent system alerts without overwhelming the diagnostic pipeline. * **Anomaly Detection:** Utilizes advanced detection methods to distinguish between routine traffic fluctuations and genuine service anomalies that require LLM intervention. * **Rigorous Evaluation:** The agent’s performance is measured through a dedicated evaluation framework that assesses the accuracy of its diagnoses against known ground-truth incidents. ### Scaling and Future Challenges * **Context Expansion:** Efforts are focused on integrating a wider range of metadata and environmental context to provide a holistic view of system health. * **Action Recommendation:** The system is moving toward suggesting specific recovery actions, such as rollbacks or traffic rerouting, rather than just identifying the problem. * **Sustainability:** Ensuring the DevOps Agent remains maintainable and cost-effective as the underlying search infrastructure and LLM models continue to evolve. Organizations managing high-scale search traffic should consider LLM-based agents as integrated infrastructure components rather than standalone tools. Moving from reactive monitoring to a proactive, experience-based agent system is essential for reducing the mean time to recovery (MTTR) in complex distributed environments.

lineOriginal article

Code Quality Improvement Techniques Part 25 (opens in new tab)

Effective code review communication relies on a "conclusion-first" approach to minimize cognitive load and ensure clarity for the developer. By stating proposed changes or specific requests before providing the underlying rationale, reviewers help authors understand the primary goal of the feedback immediately. This practice improves development productivity by making review comments easier to parse and act upon without repeated reading. ### Optimizing Review Comment Structure * Place the core suggestion or requested code change at the very beginning of the comment to establish immediate context. * Follow the initial request with a structured explanation, utilizing headers or numbered lists to organize multiple supporting arguments. * Clearly distinguish between the "what" (the requested change) and the "why" (the technical justification) to prevent the intended action from being buried in a long technical discussion. * Use visual formatting to help the developer quickly validate the logic behind the suggestion once they understand the proposed change. ### Immutability and Data Class Design * Prefer the use of `val` over `var` in Kotlin `data class` structures to ensure object immutability. * Using immutable properties prevents bugs associated with unintended side effects that occur when mutable objects are shared across different parts of an application. * Instead of reassigning values to a mutable property, utilize the `copy()` function to create a new instance with updated state, which results in more robust and predictable code. * Avoid mixing `var` properties with `data class` features, as this can lead to confusion regarding whether to modify the existing instance or create a copy. ### Property Separation by Lifecycle * Analyze the update frequency of different properties within a class to identify those with different lifecycles. * Decouple frequently updated status fields (such as `onlineStatus` or `statusMessage`) from more stable attributes (such as `userId` or `accountName`) by moving them into separate classes. * Grouping properties by their lifecycle prevents unnecessary updates to stable data and makes the data model easier to maintain as the application scales. To maintain high development velocity, reviewers should prioritize brevity and structure in their feedback. Leading with a clear recommendation and supporting it with organized technical reasoning ensures that code reviews remain a tool for progress rather than a source of confusion.

dropbox3 min readCurated summary

Building the future: highlights from Dropbox’s 2025 summer intern class

Dropbox’s 2025 intern program brought together 43 interns from 27 universities for 12 weeks of mentorship, technical work, and community-building. The 28 engineering interns contributed to systems spanning AI, search, storage, data infrastructure, and developer tools, with many projects supporting Dropbox Dash. Their work demonstrates how targeted refactoring, automation, and intelligent infrastructure can improve reliability, reduce costs, and expand product capabilities. ## A Diverse, Mentorship-Focused Internship Program - Interns received more than 6,000 hours of one-on-one mentorship. - The cohort included students from institutions in the United States, Canada, Poland, and Ireland. - Programming included Virtual First events, employee resource group activities, and an in-person Emerging Talent Summit. - Projects were aligned with Dropbox’s production systems and company goals rather than being isolated experiments. ## Infrastructure and Reliability Improvements - **Filesystem Data:** Rhea Rai redesigned Dropbox’s file history tracking system, emphasizing strongly tested code and simpler metadata infrastructure while reducing operational costs. - **Storage Core:** Albert Joon Sung reduced Magic Pocket write latency during disk restarts by adding storage-health caching and routing writes away from degraded volumes. - **Metrics:** Yonatan Ginsburg developed adaptive anomaly detection for Vortex2, accounting for changing patterns and seasonality to reduce alert fatigue and improve incident response. - **Analytics Platform:** Sanjith Udupa built recommendations for optimizing Databricks queries and ETL pipelines, and documented a plan to migrate a 500 TB mobile-events dataset to liquid clustering. ## AI, Search, and Dropbox Dash - **ML Platform:** Ben Juntilla created AI Sentinel, which gives engineers real-time visibility into machine-learning deployment health and improves confidence in model releases. - **Connector Platform:** Eddie Ormseth built tools that provide access to fresher Dash persistence data and additional third-party metadata without requiring connector teams to reprocess data. - **Retrieval Platform:** Rishi Peddakama expanded unified search to more than 20 languages by integrating language detection into indexing and retrieval. - **Find & Discover:** Francesca Venditti created in-context document previews for Dash, including PDF viewing and links to AI-powered follow-up chat. - **Conversational AI:** Alan Zhu developed a modular web-automation agent and connected it to Dropbox APIs for actions such as searching for and uploading files. ## Developer Automation - Ahmed Ibrahim built an AI-assisted code migration tool on Dropbox’s internal migration platform. - Developers can run migrations on selected folders, configure them through a CLI or automated workflow, and receive pull requests automatically when jobs succeed. - The tool enabled two major migrations during the internship and illustrates how automation can reduce repetitive engineering work. ## Broader Impact The interns’ projects improved system performance, operational visibility, multilingual accessibility, data freshness, and developer productivity. Together, they supported Dropbox’s move toward AI-first products while reinforcing the company’s emphasis on trustworthy, maintainable, and efficient engineering. For students interested in production-scale software, AI, and infrastructure, Dropbox presents its internship program and open roles as opportunities to contribute directly to products such as Dropbox Dash.

Read original(opens in new tab)
tossOriginal article

The era when everyone does research (opens in new tab)

In an era where AI moderators and non-researchers handle the bulk of data collection, the role of the UX researcher has shifted from a technical specialist to a strategic guide. The core value of the researcher now lies in "UX Leadership"—the ability to frame problems, align team perspectives, and define the fundamental identity of a product. By bridging the gap between business goals and user needs, researchers ensure that products solve real problems rather than just chasing metrics or technical feasibility. ### Setting the Framework in the Idea Phase When starting a new project, a researcher’s primary task is to establish the "boundaries of the puzzle" by shifting the team’s focus from business impact to user value. * **Case - AI Signal:** For a service that interprets stock market events using AI, the team initially focused on business metrics like retention and news consumption. * **Avoiding "Metric Traps":** A researcher intervenes to prevent fatigue-inducing UX (e.g., excessive notifications to boost CTR) by defining the "North Star" as the specific problem the user is trying to solve. * **The Checklist:** Once the user problem and value are defined, they serve as a persistent checklist for every design iteration and action item. ### Aligning Team Direction for Product Improvements When a product already exists but needs improvement, different team members often have scattered, subjective opinions on what to fix. The researcher structures these thoughts into a cohesive direction. * **Case - Stock Market Calendar:** While the team suggested UI changes like "it doesn't look like a calendar," the researcher refocused the effort on the user's ultimate goal: making better investment decisions. * **Defining Success Criteria:** The team agreed on a "Good Usage" standard based on three stages: Awareness (recognizing issues) → Understanding (why it matters) → Preparation (adjusting investment plans). * **Identifying Obstacles:** By identifying specific friction points—such as the lack of information hierarchy or the difficulty of interpreting complex indicators—the researcher moves the project from "simple UI cleanup" to "essential tool development." ### Redefining Product Identity During Stagnation When a product's growth stalls, the issue often isn't a specific UI bug but a fundamental mismatch between the product's identity and its environment. * **Case - Toss Securities PC:** Despite being functional, the PC version struggled because it initially tried to copy the "mobile simplicity" of the app. * **Contextual Analysis:** Research revealed that while mobile users value speed and portability, PC users require an environment for deep analysis, multi-window comparisons, and deliberate decision-making. * **Consensus through Synthesis:** The researcher integrates data, user interviews, and market trends into workshops to help the team decide where the product should "live" in the market. This process creates team-wide alignment on a new strategic direction rather than just fixing features. The modern UX researcher must move beyond "crafting the tool" (interviewing and data gathering) and toward "UX Leadership." True expertise involves maintaining a broad view of the industry and product ecosystem, structuring team discussions to reach a consensus, and ensuring that every product decision is rooted in a clear understanding of the user's context and goals.

lineOriginal article

Practical security knowledge growing with (opens in new tab)

LINE CTF 2025 serves as a collaborative platform for global security experts to exchange technical knowledge and tackle real-world cybersecurity challenges through a competitive framework. Under the newly integrated LY Corporation, the event evolved to prioritize anti-AI problem design and enhanced privacy protections, reinforcing its position as a top-tier competition in the Asian security community. The event successfully demonstrated that high-quality problem engineering and community-focused operations can drive both individual growth and organizational security excellence. ## Strategic Shift and AI-Resilient Design * **Multisite Collaboration:** While previous years were led primarily by the Japanese team, 2025 saw a shift where the Korean security team led preparations and the Vietnamese team contributed the highest volume of technical challenges. * **Counter-AI Engineering:** To maintain fairness in an era of LLMs, problems were specifically designed to mislead automated AI analysis, requiring human logic and deep conceptual understanding to arrive at the correct "flag." * **Systemic Integration:** This was the first year applying the unified LY Corporation administrative and approval processes, resulting in a more refined timeline for problem verification and quality control. ## Competition Format and Problem Engineering * **Jeopardy-Style Challenges:** The event featured 13 independent challenges—6 Web, 4 Pwnable, and 3 Reverse Engineering—where teams earned points based on difficulty. * **Three-Stage Validation:** Every problem underwent a rigorous cycle of idea conception, technical environment isolation/testing, and internal peer review to eliminate unintended "cheese" solutions or bugs. * **Technical Philosophy:** Problems were modeled after real-world service vulnerabilities and latest security trends, targeting a difficulty level that requires several hours of dedicated analysis by a skilled researcher. ## Platform Evolution and Performance * **Privacy-First Infrastructure:** The team customized the open-source CTFd framework to remove email-based registration, instead using a recovery-code system to ensure participant anonymity and data security. * **Growing Technical Prestige:** The competition’s rating on CTFtime (a global community platform) has climbed steadily over three years, reaching a weight of 66.5 in 2025, reflecting its high quality and difficulty. * **Competitive Results:** The Korean team "The Duck" maintained dominance with a third consecutive win, while the battle for second place was decided by a dramatic last-minute solve by the Japanese team "GMO Ierae." Participating in CTFs like LINE CTF offers an invaluable practical learning environment for security engineers to master vulnerability analysis and exploit development. Aspiring and professional researchers are encouraged to engage with these challenges to sharpen their analytical skills and contribute to a more robust, collaborative global security culture.

naverOriginal article

Naver TV (opens in new tab)

This session from NAVER Engineering Day 2025 explores how developers can transition AI from a simple assistant into a functional project collaborator through local automation. By leveraging local Large Language Models (LLMs) and the Model Context Protocol (MCP), development teams can automate high-friction tasks such as build failure diagnostics and crash log analysis. The presentation demonstrates that integrating these tools directly into the development pipeline significantly reduces the manual overhead required for routine troubleshooting and reporting. ### Integrating LLMs with Local Environments * Utilizing **Ollama** allows teams to run LLMs locally, ensuring data privacy and reducing latency compared to cloud-based alternatives. * The **mcp-agent** (Model Context Protocol) serves as the critical bridge, connecting the LLM to local file systems, tools, and project-specific data. * This infrastructure enables the AI to act as an "agent" that can autonomously navigate the codebase rather than just processing static text prompts. ### Build Failure and Crash Monitoring Automation * When a build fails, the AI agent automatically parses the logs to identify the root cause, providing a concise summary instead of requiring a developer to sift through thousands of lines of terminal output. * For crash monitoring, the system goes beyond simple summarization by analyzing stack traces and identifying the specific developer or team responsible for the affected code segment. * By automating the initial diagnostic phase, the time between an error occurring and a developer beginning the fix is dramatically shortened. ### Intelligent Reporting via Slack * The system integrates with **Slack** to deliver automated, context-aware reports that categorize issues by severity and impact. * These reports include actionable insights, such as suggested fixes or links to relevant documentation, directly within the communication channel used by the team. * This ensures that project stakeholders remain informed of the system's health without requiring manual status updates from engineers. ### Considerations for LLM and MCP Implementation * While powerful, the combination of LLMs and MCP agents is not a "silver bullet"; it requires careful prompt engineering and boundary setting to prevent hallucination in technical diagnostics. * Effective automation depends on the quality of the local context provided to the agent; the more structured the logs and metadata, the more accurate the AI's conclusions. * Organizations should evaluate the balance between the computational cost of running local models and the productivity gains achieved through automation. To successfully implement AI-driven automation, developers should start by targeting specific, repetitive bottlenecks—such as triaging build errors—before expanding the agent's scope to more complex architectural tasks. Focusing on the integration between Ollama and mcp-agent provides a secure, extensible foundation for building a truly "smart" development workflow.

naverOriginal article

@RequestCache: Developing a Custom Annotation (opens in new tab)

The development of `@RequestCache` addresses the performance degradation and network overhead caused by redundant external API calls or repetitive computations within a single HTTP request. By implementing a custom Spring-based annotation, developers can ensure that specific data is fetched only once per request and shared across different service layers. This approach provides a more elegant and maintainable solution than manual parameter passing or struggling with the limitations of global caching strategies. ### Addressing Redundant Operations in Web Services * Modern web architectures often involve multiple internal services (e.g., Order, Payment, and Notification) that independently request the same data, such as a user profile. * These redundant calls increase response times, put unnecessary load on external servers, and waste system resources. * `@RequestCache` provides a declarative way to cache method results within the scope of a single HTTP request, ensuring the actual logic or API call is executed only once. ### Limitations of Manual Data Passing * The common alternative of passing response objects as method parameters leads to "parameter drilling," where intermediate service layers must accept data they do not use just to pass it to a deeper layer. * In the "Strategy Pattern," adding a new data dependency to an interface forces every implementation to change, even those that have no use for the new parameter, which violates clean architecture principles. * Manual passing makes method signatures brittle and increases the complexity of refactoring as the call stack grows. ### The TTL Dilemma in Traditional Caching * Using Redis or a local cache with Time-To-Live (TTL) settings is often insufficient for request-level isolation. * If the TTL is set too short, the cache might expire before a long-running request finishes, leading to the very redundant calls the system was trying to avoid. * If the TTL is too long, the cache persists across different HTTP requests, which is logically incorrect for data that should be fresh for every new user interaction. ### Leveraging Spring’s Request Scope and Proxy Mechanism * The implementation utilizes Spring’s `@RequestScope` to manage the cache lifecycle, ensuring that data is automatically cleared when the request ends. * Under the hood, `@RequestScope` uses a Singleton Proxy that delegates calls to a specific instance stored in the `RequestContextHolder` for the current thread. * The cache relies on `RequestAttribute`, which uses `ThreadLocal` storage to guarantee isolation between different concurrent requests. * Lifecycle management is handled by Spring’s `FrameworkServlet`, which prevents memory leaks by automatically cleaning up request attributes after the response is sent. For applications dealing with deep call stacks or complex service interactions, a request-scoped caching annotation provides a robust way to optimize performance without sacrificing code readability. This mechanism is particularly recommended when the same data is needed across unrelated service boundaries within a single transaction, ensuring consistency and efficiency throughout the request lifecycle.

figma3 min readCurated summary

Version Control: One Founder’s Mission to Save Local Farms with Figma Make | Figma Blog

Aaron Veale used Figma Make to build Planet Food, a marketplace connecting British Columbia farmers with Vancouver restaurants, in under three weeks. Motivated by the financial crisis facing local farms, he used rapid AI-assisted prototyping to validate the idea directly with farmers and chefs. The project shows how prompt-to-app tools can help founders move quickly while tailoring products to real user workflows. ## The problem facing local farms - British Columbia farmers lost a record CAD $457 million last year, with the sector operating at a net loss since 2017. - Rising costs, disrupted supply chains, regulatory changes, and factory-farm competition are pushing small growers out of business. - Farmers are skilled at producing food but often lack time and resources for marketing and sales. - Large distributors can pressure farmers into selling produce at a loss. - Veale envisioned a marketplace linking farms directly with restaurants seeking high-quality local ingredients. ## Building the first marketplace prototype - Veale spent six weeks interviewing farmers before developing the product. - Planet Food required two connected systems: - **Farm OS:** Farmers record and categorize available produce. - **Restaurant OS:** Chefs search for and order ingredients. - He built both systems in parallel using separate Figma Make projects. - Roughly 20 prompts produced the first prototype in a single day. - Early versions became conversation starters that Veale could show farmers and restaurants for immediate feedback. ## Designing for farmers’ daily reality - The app uses dark mode to reduce glare for farmers working outdoors. - Because farmers may work 12–16-hour days, tasks were designed to take fewer than three clicks. - Veale prioritized simple workflows over feature-heavy interfaces. - He used screenshots of familiar interactions, such as swipes and slide-ups, as prompt references. - Figma Make allowed him to refine the product’s mobile-first interface without relying on a large engineering team. ## Humanizing the product through personas - Veale used his design and filmmaking background to treat prompting as a form of storytelling. - He created detailed personas describing users’ traits, motivations, responsibilities, and pain points. - The farmer persona emphasized: - Small or midsize British Columbia operations - Limited administrative capacity - Seasonal workloads and slim teams - The need for fair prices and predictable income - Common frustrations included manually updating spreadsheets, guessing restaurant demand, and overselling or underselling due to poor synchronization. - Veale used ChatGPT to turn these personas and the onboarding flow into more detailed Figma Make prompts. - Custom icons and branded interactions helped make the interface more approachable and engaging. ## Speed as a startup advantage - Figma Make enabled Veale to move from an idea to a functioning MVP in weeks rather than following the traditional fundraising-and-development sequence. - Demonstrating an actively used product gave him stronger evidence of market demand and a potential signal for investors. - The process also let him remain closely involved in product design instead of compromising his vision through multiple layers of implementation. Planet Food illustrates how AI-assisted development can accelerate product validation while keeping design grounded in user research. For founders addressing urgent problems, rapid prototyping combined with direct customer feedback can be more valuable than waiting to assemble a conventional product team.

Read original(opens in new tab)