Looking Back on Five Years at NAVER

After four years and eight months, I left NAVER. I joined through its open recruitment program in late 2021 and started on Vintage City, a vintage fashion platform. Later, I helped launch NAVER’s dedicated shopping app, then moved to NAVER LABS to work on a platform for managing robots.

I feel lucky to have spent those years at NAVER. From the start, I met generous leaders and teammates who taught me a great deal, trusted me with meaningful work, and gave me room to grow.

I left because I wanted to work in English and try something new. Before I move on, I wanted to take a moment to look back at what I did and what those experiences meant to me.

Vintage City: Learning to Build for a Product

Near the end of the new-hire training program, I had a chance to choose a team. I applied to Vintage City (which, sadly, no longer exists 😭). The idea of a large company like NAVER building a vintage clothing platform for Japan intrigued me, and the team’s presentation made the work sound genuinely fun. I’ve always liked trying new things, and the team felt like an opportunity made for me.

I had just graduated from university and didn’t even know Java. As soon as I joined, I started with a Java book and studied whatever the team used. I’m still grateful to the teammates who gave me time to find my footing 🙇. I worked through the topics my lead suggested, one by one, and began sharing what I learned with the team.

My first assignment was to keep Vintage City’s sitemap up to date so search engines could crawl the site more effectively. I remember going to a café that stayed open until midnight after work and reading the Spring Batch documentation because I was still learning what Spring Batch was. After a few twists and turns, I got the job running. Watching a batch job I had built improve our search-crawling metrics felt incredible.

Most items in a vintage shop have only one unit in stock. Once an item sells, it can no longer be purchased, and listings are often removed. I made the sitemap provide crawlers with only the items currently for sale. Compared with the previous period, 404 crawl errors fell by half. That first task gave me a sense of how to spot an inefficiency and do something about it.

Once I had settled in, I learned a range of technologies through different features. While building a Places feature connected to a trip I’ll mention below, I used Elasticsearch geo queries. I also worked with Kafka to connect to downstream Elasticsearch and wrote Kubernetes YAML myself. New technologies gradually stopped feeling intimidating. I began to see the need each open-source tool had been built to address and the situations where it made sense to use it.

The hardest task at the time was helping introduce change data capture (CDC) to the team. I was asked to look into Debezium, so I kept returning to the official documentation to understand why we needed it and how we might use it, then shared what I found. Today, AI probably would have helped me grasp it much faster. Back then, even getting a hands-on setup running was difficult.

We used CDC for cache invalidation and history logging. We had also considered it for Elasticsearch reindexing, but the database and Elasticsearch schemas didn’t map one to one. Aggregating the additional data would have made the system much harder to operate. That taught me a concrete lesson about trade-offs. More than that, it was the first time I went beyond doing an assigned task: I explained to teammates why we might adopt a technology, where it could help, and where it was better not to use it. I created issues and divided up some of the work, getting a chance to lead even though I was the most junior person on the team.

Around that time, a fire at a Pangyo data center disrupted KakaoTalk for nearly two days, and disaster recovery was on everyone’s mind. We set up Kafka disaster recovery with MirrorMaker 2. We barely had a chance to operate it, though. About a month later, Vintage City was shut down.

Vintage City was an independent service within NAVER, so we had a few experiences that weren’t typical of a large-company team. One of the most memorable was a trip to Japan. We were building a Places feature to put information about physical vintage shops on an online map, and I went to see the shops before launch. Seeing so many vintage stores around Shimokitazawa in person gave me a feel for the place that I couldn’t have gained from Korea. Since then, whenever I travel to Japan and notice a vintage shop, I find myself stepping inside and remembering that trip.

At one point, product planning had become a bottleneck. The developers held an internal hackathon to propose new features, and our team suggested a way for people to show items they owned. The idea was selected, developed further with planners and designers, and released as a feature called Snap. I’d never imagined that an idea proposed by developers could make it all the way into the product. Seeing it happen made me more engaged in the work and, I think, brought the team closer together.

Looking back, Vintage City gave me the chance to work hard on a small, fast-growing team and touch a remarkably wide range of technologies. I made memories with my colleagues, and some of the seniors and teammates I met there are still friends I turn to today. That may have been the greatest piece of luck.

When the service closed, I was disappointed and, honestly, a little bitter. It felt as though it could have gone further, and I kept thinking about how much work had gone into collecting all that data. I had so many memories of building, deploying, and rushing out hotfixes. I never expected to watch the servers go down myself. It was a pretty eventful start to my career.

NAVER Shopping: Learning to Operate at Scale

After Vintage City closed, I moved to a backend team building the server for a dedicated NAVER Shopping app. We developed features for the native app through a backend-for-frontend (BFF) that called APIs across several domains and brought their responses together. Compared with Vintage City, there was much more to think about operationally. Because our server depended on so many domain APIs, we paid close attention to circuit breakers, caching, and asynchronous calls. We expected a large number of users, so we ran performance tests under different configurations. I learned how Netty, Spring WebFlux, and caching could affect performance.

The business domain was more complicated, too. Large ecommerce services have many details to understand, and bringing those domains together meant working with many different teams. The area I remember most is benefits and discounts. We needed an API to calculate a product’s discounted price, but the answer depended on whether someone was logged in, whether they had a membership, whether they had already used their maximum discount, whether they held a coupon, and more. The API had close to a hundred fields.

It was a legacy area with planning documents that didn’t clearly capture all the rules. I took on a task many people would have preferred to avoid and had to trace undocumented rules and exceptions through the existing web server code, one by one. That experience showed me how important it is to record complex business rules for the next person who has to build on them. I saw the work through, earned recognition for it, and felt that I had taken a step forward as an engineer.

Around the same time, a new version of our internal platform as a service was released. Just before the app launch, we decided to adopt it early. I took on the migration of a logging pipeline tied to our old NGINX setup as we moved to an Envoy-based load balancer. The platform was still in beta and didn’t yet have a log exporter for the load balancer, so I worked with the platform team to request one. We built a pipeline from the load balancer’s log exporter through Kafka and Logstash to OpenSearch.

Right after launch, we learned that we’d underestimated the log traffic: consumer lag climbed to nearly a million. We brought it down by improving the efficiency of our Logstash filters, adjusting worker threads, and increasing the number of Kafka partitions. That was a firsthand lesson in how much good monitoring and logging help when you’re debugging a live system. Because we were among the first teams to adopt the new platform, my teammates and I also recorded a video about the experience and presented it at an internal engineering day. I was proud of what we’d accomplished.

There were many other complicated problems along the way, and I got to see how a large-scale system worked up close. We spent about a year pushing hard toward launch, then several more months operating and monitoring the app. After learning a great deal from that experience, I wanted to try a new domain, so I moved teams again.

NAVER LABS: Entering a New Domain

Through NAVER’s internal transfer program, I joined the Robot Software Platform team at NAVER LABS. Until then, I’d mainly built web services for shopping. Now I was building backend platform services for robots and the people who operated them. With delivery robots, drones, humanoids, and other kinds of robots taking shape, I was curious about where I could take my experience in this new domain.

At first, I knew almost nothing about robotics, and it took me a while to understand the domain. The infrastructure was very different from what I’d worked with at NAVER, and there was a lot to build from the ground up. My part was a robot device management platform, which we were developing beyond a proof of concept an intern had created.

My first assignment was to build an identity and access management (IAM) service that could give different operators different levels of access to robots. The robots were deployed in places such as NAVER’s 1784 building, the Yaesu building in Japan, and Saudi Arabia, and included different models such as Rookie 1 and Rookie 2. We needed to make sure only authorized users could control the right robots. Building that service helped me quickly understand how the platform’s different modules communicated and fit together.

Another problem was how long it took to deploy software to the robots. If something went wrong with a robot overseas, someone might have to travel there. As part of my onboarding, I went to Japan for a robot deployment. In the Yaesu building, I plugged an Ethernet cable into a robot, updated its software, and debugged its settings when it didn’t work. I remember thinking, Do we really have to do this every time?

To improve that process, I built a server for remotely delivering over-the-air (OTA) software updates to the robots. On my first deployment, we stayed at the office from the end of robot operating hours at 6 p.m. until 1 a.m. Later, with OTA updates, we could finish by 9 p.m., then 8 p.m. Work that had taken roughly seven or eight hours could be done in about 30 minutes to an hour.

Around this time, Claude Code and Codex became popular, along with vibe coding and agentic programming. Coding got much faster, but keeping up with reviews was a constant challenge. I helped introduce an AI code review workflow to ease that bottleneck. Drawing on spec-driven development, I also created skills that gave agents more context about our conventions and past discussions. As agents improved, some of those supporting workflows became less useful. Still, I was trying to help my busy teammates work more productively.

Because I joined during the pandemic in 2021, when fewer new graduates were hired, I hadn’t had many chances to work with colleagues who were less experienced than I was. At NAVER LABS, I worked with six interns. Through many code reviews, design reviews, and shared tasks, I started thinking about how to divide work well and how I could make the experience useful for their careers, too.

After my trip with Vintage City, I never expected to travel to Japan again with a different NAVER team. Somehow, I got to travel abroad quite a bit. NAVER LABS also gave me the chance to attend ROSCon 2025 in Singapore. I didn’t use ROS directly in my backend work, but seeing examples of how people were putting robots to work was a valuable learning experience.

After about a year at NAVER LABS, I left the company. I wanted to work with people across borders and gain a wider range of experiences.

What Changed in How I Work

I worked on a small team where we could throw ourselves into a growing product, on a team where careful attention to every detail and stable operations came first, and on a team where we had to figure out what was needed and build it without a dedicated planner. Over those four or five years, I learned that I work best with teammates who share a positive outlook and care deeply about making the product better.

At first, I was busy learning whatever technology a task called for. Over time, I learned to think about where a technology belonged, what I should take responsibility for, and how to operate what we built. More than anything, I learned the importance of owning a piece of work and seeing it through.

I’m in Canada now, ready to try something new. I want to keep approaching technology with care and optimism, and keep working toward becoming an engineer whose work helps people, even in small ways. Thank you for reading.