How a Side Project Turned Someone into a Product Engineer: If It's Inconvenient, Build It Yourself

Kim Min-su of MyRealTrip's Core Platform Development Team has always taken on unfamiliar work, moving through roles as a card company DB administrator, backend developer, cloud/server/mobile lead at a startup, and search engineer. The habit he built up along the way wasn't some grand methodology, but simply an attitude of building things himself when something was inconvenient, and automating them when they repeated.

His representative case is the Japan mapcode conversion site. When using rental cars in Japan, navigation systems only supported Japanese, making it hard to search for destinations, and the services for finding mapcodes were also Japanese-only, so he built one himself. It worked by obtaining GPS coordinates via the Google Places API and converting them into mapcodes. The service, originally built for his own use, got a huge response in Japan travel communities after being made public, and he even received a gift from an administrator there.

Afterward, he kept building tools like vacancy alerts for accommodations, an app to identify company phone callers, delivery tracking automation, transfer automation, and stock execution alerts. The core idea was to build systems that reduce hassle upfront, so as not to do the same work twice.

His perspective also changed once he started releasing services publicly. From the moment you put something out even if it's not perfect, you start experiencing deployment and testing, user metrics, marketing, and security. In fact, once he attached Google Analytics, he found there were almost no visitors; even after doing SEO, only search bots came in. Through the process of gaining exposure via blogs and Google Ads and watching traffic grow, he came to viscerally understand the meaning of marketing costs.

Having handled backend, frontend, and mobile all himself, he also came to understand the constraints of other roles. Realizing why frontend requires complex API specs, and why backend can't just hand things over in the exact form desired, made it possible to collaborate not by simply saying "it can't be done," but by understanding the reasons and finding alternatives together. He also learned through experience the difference between building something 90 points versus 99 points, why requirements inevitably change during operation, and that security is something you only truly grasp by experiencing it firsthand.

His conclusion was "just build it." Building, releasing, and operating something yourself reduces fear, lets you see the whole flow, and gives you an experience of touching the market even with a small service. Notably, he mentioned that the mapcode site, untouched since 2017, still steadily draws 30,000 visitors a month, and emphasized that what matters isn't a single product, but the experience of earning 100 won through a process.

Entering the AI era, he sees the center of gravity of the role shifting. In a flow where natural language becomes source code and AI-generated code is consumed like binaries, the engineer's role is moving away from writing a lot of code directly and toward designing the very way AI generates code. He calls this context engineering, harness engineering, or more broadly, a meta engineer, and ultimately presents the goal of becoming a developer who builds AI developers.

The final message is clear: the essence of a PE isn't a career title, but someone who directly solves their own inconveniences. Like a site built because he couldn't find his way while traveling, automation built to reduce repetitive work, or an alert system built to find vacant rooms—looking back, the dots all connected into a single line.