우아한형제들

For a Seamless User Experience: The Journey (opens in new tab)

To provide a seamless user experience, Baedal Minjok (Baemin) successfully integrated KakaoTalk brand vouchers directly into its ordering system, overcoming significant technical and organizational barriers between platforms. This project was driven by a mission to resolve long-standing customer friction and strategically capture external purchase demand within the Baemin ecosystem. By bridging the gap between Kakao’s gifting infrastructure and Baemin’s delivery network, the team successfully transformed a fragmented journey into a unified, user-centric service. ### Bridging User Friction and Business Growth - Addressed persistent Voice of Customer (VOC) complaints from users who found it inconvenient to use KakaoTalk vouchers through separate brand apps or physical store visits. - Aimed to capture untapped external traffic and convert it into active order volume within the Baemin platform, enhancing customer retention and "lock-in" effects. - Defined the project’s core essence as "connection," which served as a North Star for decision-making when technical constraints or business interests conflicted. ### Navigating Multi-Party Stakeholder Complexity - Coordinated a massive ecosystem involving Kakao (the platform), F&B brands, third-party voucher issuers, and internal Baemin backend teams. - Managed conflicting KPIs across organizations, balancing Kakao’s requirement for platform stability with voucher issuers' needs for settlement clarity. - Employed "context-aware communication" to bridge terminology gaps, such as reconciling Baemin’s "register and use" logic with the voucher companies' "inquiry and approval" workflows. ### Standardizing External Voucher Integration - Developed a standardized technical framework to accommodate diverse external voucher issuers while maintaining a consistent and simple interface for the end-user. - Resolved technical trade-offs regarding API response speeds, error-handling policies, and real-time validation across disparate systems. - Empowered Product Managers to act as "technical translators" and "captains," proactively managing complex dependency chains and prioritizing core features over secondary improvements to meet delivery timelines. The successful integration of KakaoTalk vouchers demonstrates that overcoming platform silos requires more than just technical API mapping; it requires a fundamental shift toward user-centric thinking. By prioritizing the "seamlessness" of the connection over individual platform boundaries, organizations can unlock significant new growth opportunities and deliver a superior digital experience.

WOOWACON 202 (opens in new tab)

To ensure the integrity of the "WOOWA POP!" mini-game during WOOWACON 2025, the development team focused on moving security from an external layer into the core game mechanics. By implementing a deterministic physics simulation, they created a system where the server could independently verify player scores by replaying their inputs. This approach effectively turned game sessions into verifiable mathematical proofs, preventing cheating in a high-stakes environment full of tech-savvy attendees. ### The Limitations of Traditional Game Security * Standard methods like code obfuscation and variable renaming only delay hackers rather than stopping them, as determined users can eventually reverse-engineer the logic. * Integrating external security measures like CAPTCHA often ruins the user experience; as seen in historical examples, the game eventually stops being a game and starts being a "humanity test." * Modern AI and computer vision have rendered many traditional CAPTCHA generations (OCR and image recognition) obsolete, requiring a more robust architectural solution. ### Building a Deterministic Verification System * The team utilized Matter.js for physics but had to address the challenge of non-determinism caused by floating-point inconsistencies across different browsers and operating systems. * Instead of sending massive amounts of frame-by-frame data (which would reach 30,000 frames for a 10-minute session), the system records only "Events"—the specific coordinates and timing of user drops. * By synchronizing the random seed and the discrete input events, the server can re-simulate the entire game state to ensure the final score submitted by the client matches the result of the server-side replay. ### Practical Fraud Detection and Mathematical Proofs * The system was put to the test when a user submitted an impossibly high score of 14,570; the server-side verification caught the discrepancy because the re-simulated score did not match the submitted value. * This architecture mirrors the concept of one-way functions: while it is difficult for a player to achieve a high score (the "work"), it is computationally inexpensive for the server to verify the legitimacy of that score. * The project demonstrates that for competitive digital environments, security should be treated as an inherent property of the system's mathematical design rather than a separate protective shell. By shifting the focus from "preventing the act of cheating" to "verifying the integrity of the result," developers can maintain a seamless user experience while ensuring fair competition. Leveraging deterministic simulations allows for a robust "Proof of Play" that is resilient even against sophisticated automated scripts and manual manipulation.

Delivering the Future: Global (opens in new tab)

The Global Hackathon 2025 served as a massive collaborative initiative to unite over 270 technical employees from seven global entities under DeliveryHero’s umbrella, including Woowa Brothers. By leveraging the community-building expertise of the Woowahan DevRel team, the event successfully bridged geographical and technical gaps to foster innovation in "Delivering the Future." The hackathon concluded with high-level recognition from global leadership and a strategic partnership with Google Cloud, demonstrating the power of synchronized global technical synergy. ## Strategic Planning and Global Coordination * The event adopted a hybrid "Base Camp" model, where participants worked from their local entity offices while staying connected through 24-hour live streaming and centralized online channels. * Organizers meticulously navigated the logistical hurdles of spanning 70 countries, including coordinating across vastly different time zones and respecting local public holidays and vacation seasons. * Efficiency was maintained through a decentralized communication strategy, using entity-specific meetings and comprehensive guidebooks rather than frequent global meetings to prevent "meeting fatigue" across time zones. ## Technical Infrastructure and Regulatory Compliance * To accommodate diverse technical preferences, the infrastructure had to support various stacks, including AWS, Google Cloud Platform (GCP), and specific machine learning models. * The central organization team addressed complex regulatory challenges, ensuring all sandbox environments complied with strict global security standards and GDPR (EU General Data Protection Regulation). * A strategic partnership with Google Cloud provided a standardized Google AI-based environment, enabling teams to experiment rapidly with mature tools and cloud-native services. ## Local Operations and Cross-Entity Collaboration * Physical office spaces were transformed into immersive hackathon hubs to maintain the high-intensity atmosphere characteristic of offline coding marathons. * The event encouraged "office sharing" between entities located in the same city and even supported travel for members to join different regional base camps, fostering a truly global networking culture. * Local supporters used standardized checklists and operational frameworks to ensure a consistent experience for participants, whether they were in Seoul, Berlin, or Dubai. Building a successful global technical event requires a delicate balance between centralized infrastructure and local autonomy. For organizations operating across multiple regions, investing in shared technical sandboxes and robust communication frameworks is essential for turning fragmented local talent into a unified global innovation engine.

Considerations for Adopting Flutter into (opens in new tab)

To efficiently manage millions of daily orders across a diversifying device ecosystem including Windows, Android, macOS, and iOS, the Baedal Minjok Order Reception team adopted Flutter combined with Clean Architecture. This transition moved the team from redundant platform-specific development to a unified codebase approach that balances high development productivity with a consistent user experience. By focusing on "Write Once, Adapt Everywhere," the team successfully integrated complex platform-specific requirements while maintaining a scalable architectural foundation. ## Strategic Shift to Flutter and Multi-Platform Adaptation * **Business Efficiency**: Moving to a single codebase allowed the team to support Android, macOS, and Windows simultaneously, reducing the need for platform-specific developers and accelerating feature parity across devices. * **Adaptation over Portability**: The team shifted from the "Run Everywhere" ideal to "Adapt Everywhere," recognizing that different OSs require unique implementations for core features like app updates (Google Play In-App Updates for Android vs. Sparkle for macOS). * **Unified UX**: Providing a consistent interface across all devices lowered the learning curve for restaurant partners and reduced support issues arising from UI discrepancies between operating systems. ## Pragmatic Abstraction Strategy * **Abstraction Criteria**: To avoid over-engineering and excessive boilerplate, the team only applied abstractions when implementations varied by platform, relied on external libraries prone to change, or required mocking for tests. * **Infrastructure Isolation**: Technical implementations like `AppUpdateManager` and `LocalNotification` were hidden behind interfaces, allowing the business logic to remain independent of the underlying technology. * **Case Study (MQTT to SSE)**: Because real-time communication was abstracted via a `ServerEventReceiver` interface, the team successfully transitioned from MQTT to Server-Sent Events (SSE) by simply swapping the implementation class without modifying any business logic. ## Clean Architecture and BLoC Implementation * **Layered Design**: The project follows a strict separation into Data (Repository Impl, DTO), Domain (Entity, UseCase, Interfaces), and Presentation (UI, BLoC) layers, with an additional Infrastructure layer for hardware-specific tasks like printing. * **Explicit State Management**: The BLoC (Business Logic Component) pattern was chosen for its stream-based approach, which provides a clear audit trail of events and states (e.g., tracking an order list from `InitializeListEvent` to `LoadedOrderListState`). * **Reliability over Conciseness**: Despite the boilerplate code required by BLoC, the team prioritized the ability to trace state changes and debug complex business flows in a high-traffic production environment. ## Evolution Toward an App Shell Model * **Rapid Deployment**: To further increase agility, the team is transitioning toward a WebView-based "App Shell" container, which allows for immediate web-based feature updates that bypass lengthy app store review processes. * **Hybrid Approach**: While the core "Shell" remains in Flutter to handle system-level permissions and hardware integration, the business features are increasingly delivered via web technologies to maintain high update frequency. By establishing a robust foundation with Flutter and Clean Architecture, the team has successfully balanced the need for cross-platform development speed with the technical rigor required for a mission-critical order reception system. Their pragmatic approach to abstraction ensures the system remains maintainable even as underlying communication protocols or platform requirements evolve.

Enhancing the “Frequently (opens in new tab)

Baedal Minjok (Baemin) has significantly improved its cart recommendation system by transitioning from a basic Item2Vec model to a sophisticated two-stage architecture that combines graph-based embeddings with Transformer sequence modeling. This evolution addresses the "substitutability bias" and lack of sequential context found in previous methods, allowing the system to understand the specific intent behind a user's shopping journey. By moving beyond simple item similarity, the new model effectively identifies cross-selling opportunities that align with the logical flow of a customer's purchase behavior. ### Limitations of the Item2Vec Approach * **Substitutability Bias:** The original Item2Vec model, based on the Skip-gram architecture, tended to map items from the same category into similar vector spaces. This resulted in recommending alternative brands of the same product (e.g., suggesting another brand of milk) rather than complementary goods (e.g., cereal or bread). * **Loss of Sequential Context:** Because Item2Vec treats a basket of goods as a "bag of words," it ignores the order in which items are added. This prevents the model from distinguishing between different user intents, such as a user starting with meat to grill versus a user starting with ingredients for a stew. * **Failure in Cross-Selling:** The primary goal of cart recommendations is to encourage cross-selling, but the reliance on embedding similarity alone limited the diversity of suggestions, often trapping users within a single product category. ### Stage 1: Graph-Based Product and Category Embeddings * **Node2Vec Implementation:** To combat data sparsity and the "long-tail" problem where many items have low purchase frequency, the team utilized Node2Vec. This method uses random walks to generate sequences that help the model learn structural relationships even when direct transaction data is thin. * **Heterogeneous Graph Construction:** The graph consists of both "Item Nodes" and "Category Nodes." Connecting items to their respective categories allows the system to generate initial vectors for new or low-volume products that lack sufficient historical purchase data. * **Association Rule Weighting:** Rather than using simple co-occurrence counts for edge weights, the team applied Association Rules. This ensures that weights reflect the actual strength of the complementary relationship, preventing popular "mega-hit" items from dominating all recommendation results. ### Stage 2: Transformer-Based Sequence Recommendation * **Capturing Purchase Context:** The second stage employs a Transformer model to analyze the sequence of items currently in the user's cart. This architecture is specifically designed to understand how the meaning of an item changes based on what preceded it. * **Next Item Prediction:** Using the pre-trained embeddings from Stage 1 as inputs, the Transformer predicts the most likely "next item" a user will add. This allows the system to provide dynamic recommendations that evolve as the user continues to shop. * **Integration of Category Data:** By feeding both item-level and category-level embeddings into the Transformer, the model maintains a high level of accuracy even when a user interacts with niche products, as the category context provides a fallback for the recommendation logic. ### Practical Conclusion For production-scale recommendation systems, relying solely on item similarity often leads to redundant suggestions that do not drive incremental sales. By decoupling the learning of structural relationships (via graphs) from the learning of temporal intent (via Transformers), engineers can build a system that is robust against data sparsity while remaining highly sensitive to the immediate context of a user's session. This two-stage approach is recommended for e-commerce environments where cross-category discovery is a key business metric.

We Refactor Culture Just Like (opens in new tab)

The Commerce Web Frontend Development team at Woowa Brothers recently underwent a significant organizational "refactoring" to manage the increasing complexity of their expanding commerce platform. By moving away from rigid, siloed roles and adopting a flexible "boundary-less" part system, the team successfully synchronized disparate services like B Mart and Baemin Store. This cultural shift demonstrates that treating organizational structure with the same iterative mindset as code can eliminate operational bottlenecks and foster a more resilient engineering environment. ### Transitioning to Boundary-less Parts * The team abandoned traditional division methods—such as project-based, funnel-based, or service-vs-backoffice splits—because they created resource imbalances and restricted developers' understanding of the overall service flow. * Traditional project-based splits often led to specific teams being overwhelmed during peak periods while others remained underutilized, creating significant delivery bottlenecks. * To solve these inefficiencies, the team introduced "boundary-less parts," where developers are not strictly tied to a single domain but are encouraged to work across the entire commerce ecosystem. * This structure allows the organization to remain agile, moving resources fluidly to address high-priority business needs without being hindered by departmental "walls." ### From R&R to Responsibility and Expandability (R&E) * The team replaced the traditional R&R (Role & Responsibility) model with "R&E" (Responsibility & Expandability), focusing on the core principle of "owning" a problem until it is fully resolved. * This shift encourages developers to expand their expertise beyond their immediate tasks, fostering a culture where helping colleagues and understanding neighboring domains is the standard. * Work is distributed through a strategic sync between team and part leaders, but team members maintain the flexibility to jump into different domains as project requirements evolve. * Regular "part shuffling" is utilized to ensure that domain knowledge is distributed across the entire 20-person frontend team, preventing the formation of information silos. ### Impact on Technical Integration and Team Resilience * The flexible structure was instrumental in the "ONE COMMERCE" initiative, which required integrating the technical stacks and user experiences of B Mart and Baemin Store. * Because developers had broad domain context, they were able to identify redundant logic across different services and abstract them into shared, common modules, ensuring architectural consistency. * The organization significantly improved its "Bus Factor"—the number of people who can leave before a project stalls—by ensuring multiple engineers understand the context of any given system. * Developers evolved into "domain-wide engineers" who understand the full lifecycle of a transaction, from the customer-facing UI to the backend administrative and logistics data flows. To prevent today's organizational solutions from becoming tomorrow's cultural legacy debt, engineering teams should proactively refactor their workflows. Moving from rigid role definitions to a model based on shared responsibility and cross-domain mobility is essential for maintaining velocity and technical excellence in large-scale platform environments.

In Search of Lost Accessibility | Woowa (opens in new tab)

Achieving a high accessibility score on automated tools like Lighthouse does not always translate to a functional experience for users with visual impairments. This post explores how a team discovered that their "high-scoring" product actually required over 300 swipes for a screen reader user to reach a purchase button, leading them to overhaul their approach. By focusing on actual screen reader behavior rather than just checklists, they successfully transformed a fragmented interface into a streamlined, navigable user journey. ### Navigational Structure with Landmarks and Headings * The team implemented a clear hierarchy using landmarks (header, main, footer) and heading levels, which allows screen reader users to jump between sections via tools like the iOS VoiceOver "Rotor." * To ensure consistency, they developed a reusable component that automatically wraps content in a `<section>` and links it to a heading using the `aria-labelledby` attribute. * They addressed a common CSS pitfall: because setting `list-style: none` can cause VoiceOver to stop recognizing elements as a list, they explicitly added `role="list"` to maintain structural context for the user. ### Consolidating Fragmented Text for Readability * Information that should be heard as a single unit, such as prices (e.g., "990" and "Won"), was often fragmented into separate swipes; the team corrected this by using template literals to merge data into single strings. * For cases where visual styling required separate DOM elements, they used a "NoScreen" component strategy: hiding the visual elements from screen readers with `aria-hidden="true"` while providing a single, visually hidden description for the screen reader to announce. * The team noted that `aria-label` on generic containers like `<span>` or `<div>` is often ignored by iOS VoiceOver, making screen-reader-only text a more reliable method for cross-platform accessibility. ### Defining Roles for Interactive Elements * The team identified that generic buttons like "View All" lacked context, so they updated them with specific labels (e.g., "View all 20 reviews") to clarify the outcome of the interaction. * They ensured that all interactive elements have clearly defined roles, preventing the ambiguity that occurs when a screen reader identifies an element as a "button" without explaining its specific purpose or the data it controls. True accessibility is best measured by the physical effort required to complete a task, such as the number of swipes or touches. Developers should move beyond automated audits and regularly perform manual testing with screen readers like VoiceOver or TalkBack to ensure their services are genuinely usable for everyone.

We Did Everything from Planning to (opens in new tab)

The 7th Woowacourse crew has successfully launched three distinct services, demonstrating that modern software engineering requires a synergy of technical mastery and "soft skills" like product planning and team communication. By owning the entire lifecycle from ideation to deployment, these developers moved beyond mere coding to solve real-world problems through agile iterations, user feedback, and robust infrastructure management. The program’s focus on the full stack of development—including monitoring, 2-week sprints, and collaborative design—highlights a shift toward producing well-rounded engineers capable of navigating professional environments. ### The Woowacourse Full-Cycle Philosophy * The 10-month curriculum emphasizes soft skills, including speaking and writing, alongside traditional technical tracks like Web Backend, Frontend, and Mobile Android. * During Level 3 and 4, crews transition from fundamental programming to managing team projects where they must handle everything from initial architecture to UI/UX design. * The process mimics real-world industry standards by implementing 2-week development sprints, establishing monitoring environments, and managing automated deployment pipelines. * The core goal is to shift the developer's mindset from simply writing code to understanding why certain features are planned and how architecture choices impact the final user value. ### Pickeat: Collaborative Dining Decisions * This service addresses "decision fatigue" during group meals by providing a collaborative platform to filter restaurants based on dietary constraints and preferences. * Technical challenges included frequent domain restructuring and UI overhauls as the team pivoted based on real-world user feedback during demo days. * The platform utilizes location data for automatic restaurant lookups and supports real-time voting mechanisms to ensure democratic and efficient group decisions. * Development focused on aligning team judgment standards and iterating quickly to validate product-market fit rather than adhering strictly to initial specifications. ### Bottari: Real-Time Synchronized Checklists * Bottari is a checklist service designed for situations like traveling or moving, focusing on "becoming a companion for the user’s memory." * The service features template-based list generation and a "Team Bottari" function that allows multiple users to collaborate on a single list with real-time synchronization. * A major technical focus was placed on the user experience flow, specifically optimizing notification timing and sync states to provide "peace of mind" for users. * The project demonstrates the principle that technology serves as a tool for solving psychological pain points, such as the anxiety of forgetting essential items. ### Coffee Shout: Real-Time Betting and Mini-Games * Designed to gamify office culture, this service replaces simple "rock-paper-scissors" with interactive mini-games and weighted roulette for coffee bets. * The technical stack involved challenging implementations of WebSockets and distributed environments to handle the concurrency required for real-time gaming. * The team focused on algorithm balancing for the weighted roulette system to ensure fairness and excitement during the betting process. * Refinement of the service was driven by direct feedback from other Woowacourse crews, emphasizing the importance of community testing in the development lifecycle. These projects underscore that the transition from a student to a professional developer is defined by the ability to manage shifting requirements and technical complexity while maintaining a focus on the end-user's experience.

Test Automation with AI: (opens in new tab)

This blog post explores how a development team at Woowahan Tech successfully automated the creation of 100 unit tests in just 30 minutes by combining a custom IntelliJ plugin with Amazon Q. The author argues that while full AI automation often fails in complex multi-module environments, a hybrid approach using "compile-guaranteed templates" ensures high success rates and maintains operational stability. This strategy allows developers to bypass repetitive setup tasks while leveraging AI for logic implementation within a strictly defined, valid structure. ### Evaluating AI Assistants for Testing * The team compared various AI tools including GitHub Copilot, Cursor, and Amazon Q to determine which best fit their existing IntelliJ-based workflow. * Amazon Q was selected for its superior understanding of the entire project context and its ability to integrate seamlessly as a plugin without requiring a switch to a new IDE. * Initial manual use of AI assistants highlighted repetitive patterns: developers had to constantly specify team conventions (Kotest FunSpec, MockK) and manually fix build errors in 15% of the generated code. * On average, it took 10 minutes per class to generate and refine tests manually, prompting the team to seek a more automated solution via a custom plugin. ### The Pitfalls of Full Automation * The first version of the custom plugin attempted to generate complete test files by gathering class metadata through PSI (Program Structure Interface) and sending it to the Gemini API. * Pilot tests revealed a 90% compilation failure rate, as the AI frequently generated incorrect imports, hallucinated non-existent fields, or used mismatched data types. * A critical issue was the "loss of existing tests," where the AI-generated output would completely overwrite previous work rather than appending to it. * In complex multi-module projects, the AI struggled to identify the correct classes when multiple modules contained identical class names, leading to significant manual correction time. ### Shifting to Compile-Guaranteed Templates * To overcome the limitations of full automation, the team pivoted to a "template first" approach where the plugin generates a valid, compilable shell for the test. * The plugin handles the complex infrastructure of the test file, including correct imports, MockK setups, and empty test stubs for every method in the target class. * This approach reduces the AI's "hallucination surface" by providing it with a predefined structure, allowing tools like Amazon Q to focus solely on filling in the implementation details. * By automating the 1-minute setup and letting the AI handle the 2-minute implementation phase, the team achieved a 97% success rate across 100 test cases. ### Practical Conclusion For teams looking to improve test coverage in large-scale repositories, the most effective strategy is to use IDE plugins to automate context gathering and boilerplate generation. By providing the AI with a structurally sound template, developers can eliminate compilation errors and significantly reduce the time spent on manual refinement, ensuring that even complex edge cases are covered with minimal effort.

How Woowa Brothers Detects Failures (opens in new tab)

Woowa Brothers addresses the inevitability of system failures by shifting from traditional resource-based monitoring to a specialized Service Anomaly Detection system. By focusing on high-level service metrics such as order volume and login counts rather than just CPU or memory usage, they can identify incidents that directly impact the user experience. This approach ensures near real-time detection and provides a structured response framework to minimize damage during peak service hours. ### The Shift to Service-Level Monitoring * Traditional monitoring focuses on infrastructure metrics like CPU and memory, but it is impossible to monitor every system variable, leading to "blind spots" in failure detection. * Service metrics, such as real-time login counts and payment success rates, are finite and offer a direct reflection of the actual customer experience. * By monitoring these core indicators, the SRE team can detect anomalies that system-level alerts might overlook, ensuring that no failure goes unnoticed. ### Requirements for Effective Anomaly Detection * **Real-time Performance:** Alerts must be triggered in near-real-time to allow for immediate intervention before the impact scales. * **Explainability:** The system favors transparent logic over "black-box" AI models, allowing developers to quickly understand why an alert was triggered and how to improve the detection logic. * **Integrated Response:** Beyond just detection, the system must provide a clear response process so that any engineer, regardless of experience, can follow a standardized path to resolution. ### Technical Implementation and Logic * The system leverages the predictable, pattern-based nature of delivery service traffic, which typically peaks during lunch and dinner. * The team chose a Median-based approach to generate "Prediction" values from historical data, as it is more robust against outliers and easier to analyze than complex methods like IQR or 2-sigma. * Detection is determined by comparing "Actual" values against "Warning" and "Critical" thresholds derived from the predicted median. * To prevent false positives caused by temporary spikes, the system tracks "threshold reach counts," requiring a metric to stay in an abnormal state for a specific number of consecutive cycles before firing a Slack alert. ### Optimization of Alert Accuracy * Each service metric requires a tailored "settling period" to find the optimal balance between detection speed and accuracy. * Setting a high threshold reach count improves accuracy but slows down detection, while a low count accelerates detection at the risk of increased false positives. * Alerts are delivered via Slack with comprehensive context, including current status and urgency, to facilitate rapid decision-making. For organizations running high-traffic services, prioritizing service-level indicators (SLIs) over infrastructure metrics can significantly reduce the time to detect critical failures. Implementing simple, explainable statistical models like the Median approach allows teams to maintain a reliable monitoring system that evolves alongside the service without the complexity of uninterpretable AI models.