Furigana - No more stopping for kanji

• If you've ever studied Japanese, you probably know that kanji is one of the biggest barriers to reading fluently. Furigana starts by automatically adding contextually accurate furigana to Japanese text. My ultimate goal is to turn the mental burden of reading Japanese into curiosity and excitement about the content itself, creating a learning experience where reading Japanese feels as natural and enjoyable as keeping up with your favorite Japanese dramas or anime.
• Furigana generators already exist, and I've used them myself. However, because they rely heavily on dictionary-based readings, they often produce pronunciations that don't fit the context. I thought LLMs could solve this problem relatively easily.

• I initially expected LLMs to make this straightforward, but generating natural, context-appropriate furigana across different types of text turned out to be more challenging than I anticipated. Through repeated experiments, I've been testing which instructions and context sizes help the model perform best, while improving accuracy through pre- and post-processing. With models evolving rapidly, I'm also exploring how to manage this ongoing process as efficiently as possible.
• To consistently deliver a rewarding reading experience, my top priority is building a library of high-quality content. I'm collaborating with creators in Japan who share this vision. Rather than conventional learning materials, I want to offer distinctive writing that reflects each creator's unique perspective. Ultimately, I envision Furigana as a community-driven content platform where users are not just readers but also contributors who can share their own writing.

• I want to read Japanese without stopping for kanji

AI Filmmaking

• I'm experimenting with how far AI can push the quality of independent filmmaking. My goal is to pursue an auteur-driven approach to filmmaking, where AI serves strictly as a production tool and remains invisible in the final work, allowing the story itself to entertain, move, and convey meaningful messages to audiences.

• I'm currently focused on developing original screenplays and building an AI-powered previsualization workflow, with plans to bring these stories to audiences as short films and drama series in the near future.

Planning and Developing the AI Meeting Cheat Sheet

• Yess targets service businesses such as agencies and studios. I planned and developed features by diving deep into the real challenges these businesses face when trying to win new projects.

• For a period of time, everyone on the team participated in product planning, regardless of whether they were developers or product planners. During this process, I hypothesized that customers spent the most time and faced the greatest challenges preparing for meetings, one of the earliest stages of the sales process. I validated this hypothesis through customer interviews and designed the Meeting Cheat Sheet feature by sketching low-fidelity wireframes myself.
• To deliver real-time AI-generated data through a seamless streaming UI/UX, I experimented with several technical approaches. Since our implementation depended on the text editor and WebSocket library already in use, testing in an isolated environment with reduced complexity proved helpful. I joined a hackathon with my teammates to experiment with the Vercel AI SDK and also built a custom streaming module using RxJS. However, integrating these approaches into the actual product still introduced significant complexity and failed to ensure consistent behavior. To address this, I proposed a server-driven approach where responses would include cursor-position data for streaming. After discussions with the team, we settled on a compromise: handling this logic at the WebSocket library layer between the server and client, and refined the implementation accordingly.

• The Meeting Cheat Sheet became the starting point for planning several key features that support customers throughout their sales process, including project context analysis, meeting summaries, and proposal generation. Together, these features formed the AI Sales Copilot in Yess 1.0, laying the foundation for Yess to enter a market with established competitors as its first AI-native player.
• Throughout the planning process, my primary focus was identifying the UX customers would actually need in real-world situations. This user-centered approach also inspired the feature's name.

• I learned the importance of defining clear UX goals when working with AI. There are many ways to implement AI streaming, but choosing an approach based on the desired experience, rather than implementation difficulty or complexity alone, can ultimately save more time. AI itself is only a means to an end, so it's important to break down goals and apply it selectively where it is genuinely needed and useful.

• Building an AI Sales Copilot - (1) A developer who designs
• Building an AI Sales Copilot - (2) Streaming Queue
• Building an AI Sales Copilot - (3) Delta-Driven UI

Building and Improving a Design System

• Everyone on the team agreed that a design system was essential for providing a consistent, intuitive UI/UX across the web app, helping users get familiar with the product with minimal learning effort.
• A design system also helps maintain both quality and speed. Even when shipping new features every week, components covered by the design system can ensure a baseline level of quality without extensive deliberation. Reusing these components also eliminates the need for additional design and implementation work from scratch.

• I defined design tokens based on Material Design. For key components, I used Radix Primitives, a headless UI library, to handle core functionality while implementing custom styles.
• I carefully considered the order in which to introduce the components. Initially, I tried replacing every button in the web app with the newly developed component. While this ensured design consistency, it proved too time-consuming. For the next iteration, instead of replacing individual component types across the app, I focused on applying the design system to the top-level pages users first encounter.
• During maintenance, I also adapted the compound component pattern to improve reusability and ease of use.

• Introducing the design system significantly improved the efficiency of translating design mockups into UI implementations. Unnecessary communication about styling was noticeably reduced, and we gained better control over UI fragmentation as new features were introduced.
• By prioritizing the most important areas first, we achieved substantial improvements in a relatively short period.

• Aligning the entire team's understanding of the design system, regardless of individual roles, was a valuable experience. In particular, I learned the importance of continuously ensuring that everyone shares the same understanding of design intent and its implementation in code.
• Continuously improving and maintaining a design system is even more important than its initial implementation. While unnecessary communication should be minimized, active reviews and ongoing improvements from team members are essential for evolving it into a mature system.

• Improving a design system with the compound component pattern

Incrementally Adopting a New Editor Library

• Document editing is one of the most critical features of the Yess web app, making it highly dependent on its editor library. The existing Quill library was slow to receive updates and lacked flexibility for customization, so various features had been built on top of an older fork. This made it difficult to benefit from regular version updates. Moreover, the fork's lack of strict typing had become an obstacle to developing features quickly and reliably. With the growing need to support more interactive experiences powered by generative AI, I concluded that adopting a new editor library was necessary.

• I selected Tiptap, a ProseMirror-based editor library, for evaluation and conducted several rounds of proof-of-concept testing. To make tackling these challenging problems less daunting, we worked through them in pair programming sessions outside the regular sprint scope.
• Following the POCs, we partially introduced Tiptap during a sprint to implement the email editor for the Workflow Automation feature. When unexpected issues arose, my limited understanding of ProseMirror's data structures made troubleshooting difficult. However, with help from my teammates, we worked through the problems together and overcame the learning curve of the new library.

• Starting with a relatively simple feature made subsequent POCs for core functionality feel much more manageable. If we had attempted to implement concurrent editing and AI streaming with the new editor from the beginning, the number of unknowns would have been too overwhelming to justify the decision.
• We also became able to respond more quickly to product requirements involving editable content. Unlike when we relied solely on the existing Quill-based module, we now had Tiptap as an alternative, offering stronger type safety and a better developer experience. As a result, we've been gradually expanding its adoption.

• I learned that even a steep learning curve becomes easier and faster to overcome with the support of a team. While making an effort to solve problems independently is important, knowing when to ask for help matters just as much. I also learned that when asking for help, it's essential to clearly communicate what I've understood about the problem so far and what still needs to be resolved.

• How to adopt a new WYSIWYG editor

Improving Widget SDK Performance

• Yess provides a JavaScript widget SDK that users can embed into their websites with a code snippet to collect customer inquiries. However, the Inquiry Form within the widget took approximately 5 seconds to load initially. I worked on improving its performance to deliver a blazingly fast experience with virtually no loading time.

• When the widget was first developed, the Inquiry Form was offered as a standalone service, so it was implemented by embedding its public URL in an iframe. However, since the widget SDK itself also ran inside an iframe, this resulted in nested iframes and additional network requests.
• Improving network response times was one possible approach, but after considering a more fundamental solution, we decided to migrate to a monorepo. As a vertical SaaS product, Yess has multiple features that can operate as standalone services while potentially sharing functionality and dependencies. Taking this architecture into account, we consolidated the web app and widget, which had previously been maintained in separate repositories, into a single monorepo.

• The monorepo enabled multiple apps to reference each other at build time, eliminating the additional loading time for the Inquiry Form within the widget. The new structure also made shared code easier to manage and simplified the process of building new apps and setting up their deployment environments using existing code.

• Making a fundamental architectural change to a sizable legacy codebase involved a great deal of repetitive work and troubleshooting unexpected build errors. However, having a clear goal of delivering a blazingly fast experience helped the team recognize these challenges as necessary steps and work through them together. I learned that the working backwards approach is equally valuable when proposing, aligning on, and executing engineering strategies.

• Working backwards from the user experience

Improving Error Handling in the Partner Service

• The partner service had not been properly maintained since its initial implementation, making it difficult to trace its development history. Its high complexity and inflexible code also made implementing new features challenging. To minimize bottlenecks in future partner-related projects, I focused on improving error handling, which I considered the most pressing issue.

• Since this involved extensive changes to the legacy codebase without affecting existing functionality, I carefully considered various use cases, validation methods, and defensive strategies throughout the process.
• I brought together two teammates working on partner-related features and divided responsibilities among us. We held regular discussions and actively reviewed each other's code to ensure consistent implementation.

• Previously, the partner service lacked a systematic way to handle API communication failures and JavaScript errors. By improving its error handling, we established standardized exceptions for predictable failures and implemented defensive UI mechanisms for unexpected errors. We also introduced an error-tracking tool for the production environment, improving both the user and developer experience.

• Since error handling is essential to any service, this project gave me valuable experience in separating reusable error-handling mechanisms from business-specific logic and improving them independently.
• I also gained experience in proactively addressing problems, bringing together teammates to work toward a shared goal, and taking ownership of project management.

• Error handling from scratch in a legacy codebase

Leading Development for the Accommodation & Transportation Domain

• To diversify MyRealTrip beyond its core guided-tour business, I took responsibility for the accommodation and transportation domain and worked on various projects.
• I also focused on reducing technical debt to improve the stability of the domain's codebase.

• I led the development of product discovery, one of the two key stages of the commerce journey alongside booking. My projects included bringing the rental car service in-house, building a promotional page for a nationwide accommodation campaign, fully refactoring the domestic accommodation service, and improving features for accommodation partners.
• I also rebuilt and migrated all accommodation and transportation products from the legacy 2.0 codebase to the improved 3.0 version. The new codebase adopted TypeScript for greater reliability and separated server state from client state to reduce complexity. By applying newly established team conventions, we successfully introduced a more stable and maintainable codebase across the domain.

• Following its launch, the rental car service rapidly broke performance records, reaching ₩100 million in daily transaction volume. While monitoring service metrics, I discovered that closing a modal unexpectedly triggered page navigation, affecting payment conversion. To address this, I implemented a mechanism to preserve the modal stack in browser history, resulting in a 3% increase in the payment conversion rate.
• I also completely refactored the aging nationwide accommodation campaign page and domestic accommodation service, improving maintainability and scalability. In particular, I resolved an issue where URL query parameters were lost, which had been causing user frustration, improving both the customer experience and business operations.

• Working to deliver business impact quickly while maintaining code quality led me to rethink the product development process. I learned the importance of considering maintainability and scalability beyond simply implementing features, as well as prioritizing developer testing.
• When I took responsibility for managing tasks and schedules while collaborating with teammates in the same domain, I found myself with less time for development. This experience helped me understand the challenges of management and taught me that breaking down goals and setting clear priorities are essential for effective task delegation.

• When to separate logic and when not to

Building an Image Asset Management Tool

• Uploading assets such as promotional images and icons was handled manually by frontend developers. Even simple asset changes required requests from product planners or designers to be submitted as tickets, creating a repetitive and inconvenient workflow. I developed a productivity tool to streamline this process.

• I built a Figma plugin that allows anyone who needs an asset URL to obtain it directly from the Figma design files.
• In addition to the Figma plugin, I developed a web-based image management tool offering more comprehensive features and greater extensibility.

• The tool eliminated the need for developers to handle asset uploads manually, as well as the need for requesters to submit and track tickets.
• By managing the information required for uploads programmatically, we could manage assets more consistently and efficiently than through the previous manual process.

• This project gave me experience in identifying repetitive manual tasks and proactively finding and implementing ways to automate them.
• Integrating the Figma API also helped me recognize the value of plugins and the importance of platforms that support such extensibility. In particular, passing Figma canvas data through postMessage prompted me to explore how to ensure reliable communication between separate JavaScript execution contexts.

Building an Email Content Editor

• VARY is an email marketing SaaS platform that helps businesses improve their marketing effectiveness by delivering personalized email experiences to customers. Creating high-quality content is equally important to the email experience, but businesses without dedicated designers or developers often struggle with content creation. To address this, I developed an email editor that enables users to create high-quality content without requiring design or development resources.

• I implemented core editing features, including creating, reading, updating, and deleting content and its styling at the block level, as well as undo, redo, and preview. By standardizing the data structure of blocks, I enabled dynamic rendering of different view types, such as JSX and email markup, depending on the use case.
• I used Redux for state management and Redux-Observable to handle asynchronous operations through reactive streams. Data persistence was delegated to the main product API, allowing the editor to function as a standalone frontend application.

• By analyzing existing email editors and identifying areas for improvement, I built an intuitive UI that received positive feedback from users on its usability.
• Integrating the editor directly into the platform enabled users to complete the entire email marketing process without leaving the service.

• Managing all data in a centralized global state led to increased complexity and performance issues. This experience made me more aware of the potential drawbacks of global state management.
• I also had to replace the initially selected WYSIWYG library due to critical flaws. This taught me the importance of thoroughly evaluating a library's strengths, limitations, and suitability before adopting it.
• Additionally, I gained experience building responsive email layouts within the constraints of email markup, where modern web technologies are often unavailable.

• Using redux with React Context API
• How to choose a WYSIWYG editor
• Evolving the project folder structure: why I changed it and what I learned

Building the Core Product

• Launching the email marketing service required building various features and supporting workflows. I contributed to developing key pages for email campaign management, recipient management, and account management.

• I built a design system to improve development efficiency. I structured components using Styled System and used Storybook for testing and documentation.
• As part of a small team developing a new business, I actively participated in product planning alongside my development responsibilities. We worked through rapid cycles of product development and improvement, continuously sharing ideas and feedback.

• We completed the email editor and core product development and launched the service within a year. We also received positive feedback from actual users who were able to carry out their email marketing more effectively.
• On a personal level, this was my first professional development experience, and it became an opportunity for tremendous growth as I built my skills from the ground up.

• After initially implementing the design system, I continuously refactored it to improve code reusability. I learned to distinguish between responsibilities that should be delegated through component interfaces and those that should be handled internally by the design system.
• I also gained a better understanding of the specifications and capabilities commonly required of UI components in web applications.