How Documents Find Developers at Toss

*This is the English version of a previously published article.

Every developer has been here. You're deep in building a new feature, thirty tabs open, and suddenly you need to look up how an internal tool works… except you can't even remember where the documentation is. So you ping a teammate and wait. Just like that, your flow is gone. Ever had the same experience?

It was a problem our Frontend Chapter knew all too well. So we tried a different approach: instead of making documentation better to find, we made it come to developers.

Breaking Path Dependence in Documentation

Documentation path dependency is the constraint that forces users to follow a predetermined route just to reach the information they need. Traditional technical docs are structured from the writer's perspective, which means finding exactly what you're looking for often takes multiple searches. To break that pattern, we began observing developers in their natural work environment and interviewing them about how they actually get things done.

The dominant way developers got knowledge was simply by “asking.” A tap on the shoulder, a quick Slack message to a teammate who might know the answer. It's natural, and honestly, makes a lot of sense. Searching through pages of documentation takes time and effort that a thirty-second conversation doesn't. So rather than fight that instinct, we leaned into it.

We asked ourselves what it would take to give documentation that same immediacy, to make it respond like a knowledgeable colleague rather than a reference manual. Documentation that answers back, fetching the right context for the exact question being asked, is documentation worth using.

And that’s how Mr. Park was created.

Mr. Park: Talk to your Docs

• How it works: Ask a question and get an answer straight from the docs
• Where to find it: IDE (VSCode, Cursor) and on the company’s messenger
• What it does: Find information through “conversation” not “navigation”
• Fun fact: Mr. Park was named after the persona of Sojin Park, the Head of the Frontend Chapter

Mr. Park is a RAG(Retrieval-Augmented Generation) based chatbot built to make LLM responses more accurate and trustworthy. It draws from existing documents to deliver reliable answers, always with sources attached. Developers can ask questions naturally and get what they need without ever opening a doc or running a search. The answers are more precise than what you'd get from a teammate, and consistent no matter who's asking.

For Mr. Park to give quality answers, it needs a solid knowledge base to draw from. So we've put serious effort into improving both the quantity and quality of our documentation. But technical writers and a handful of developers alone couldn't produce enough coverage. For this system to scale, we needed an easy way to document an individual’s knowledge. That's what led us to build Sillokbot, a documentation automation tool.

Sillokbot: Auto-document your conversations

• What it does: Automatically documents key information from company messenger conversations
• How it works: React to a thread with the Sillokbot emoji, or call the bot directly. It analyzes the conversation, summarizes it using AI, and opens a PR.
• How it helps: Knowledge gets captured automatically as problems get solved, with no one having to sit down and write a separate document

Sillokbot automatically summarizes the important conversations happening within the team. The thing is, developers have already been exchanging knowledge on the company messenger all along, answering questions and talking through problems. The trouble is those conversations disappear fast, and the same questions keep coming back up. Sillokbot steps in to capture those threads, summarizes them, and opens a PR to the documentation repository, so useful discussions get preserved with almost no extra effort.

Say a developer realizes that a bug-fixing thread was particularly useful. They call Sillokbot on it, and just like that, the whole discussion becomes a document that Mr. Park learns from. The next person with the same question gets an answer without having to open the same discussion. Documentation stops being a separate chore and starts happening naturally, at the exact moment knowledge gets shared.

Knowledge that Flows

Thanks to Mr. Park and Sillokbot, knowledge at the Toss Frontend Chapter no longer pools around a single person, and the same questions have stopped making the rounds on the team. The right information reaches people at the right moment, and knowledge moves the way it should. That's had a direct impact on the team's productivity and efficiency. The bet paid off. By observing how developers actually work and treating technical documentation as a system for learning and problem-solving rather than a static collection of information, we got real results.

Technical writing has evolved alongside all of this. The old focus was on structuring information and explaining features well from the writer's perspective. Now the focus is on building a system that actually puts documentation to work for developers. Because at the end of the day, technical writing has always been about making documentation genuinely useful for developers.

The Toss Frontend Platform Team is looking for people to join us in building a learning infrastructure where knowledge is easy to share and access. There's a lot ahead, like pushing the AI-powered documentation system further, building documentation automation that connects naturally with code, and creating a documentation ecosystem that works seamlessly across the company messenger and other platforms.

Join us if building an environment where developers do their best work sounds like your kind of challenge.