Inside Dev Korea #8 with Salmon: better error handling, smarter QA, and a packed room in Seoul

Want to feel what the night was like? From the talks to the networking and everything in between, here's a quick trailer of Dev Korea #8 🎥.

On May 18 we ran Dev Korea #8 with Salmon. Around 150 people came out for the evening. Developers, QA engineers, a good mix of folks from across the Seoul tech scene, all there for two talks and the usual long tail of conversations afterward.

Salmon made the night happen. They came on as the main sponsor, brought their speakers, handed out swag, and even set up a photobooth that people kept coming back to all evening.

Both talks were about software quality, but they came at it from opposite ends. One was about how we write failures into our code. The other was about how teams decide what's actually worth testing before a release. Put together, they were really asking the same thing: how do we build software that's easier to reason about?

Making failures easier to understand

The first talk was by Sergey Chernov, Lead Software Engineer at Salmon Group Ltd, on domain errors and functional error handling in Kotlin.

He started with a problem most backend developers will recognize: a method signature rarely tells you what can actually go wrong inside it. A function looks simple from the outside, but the implementation might be full of expected business failures. An invalid code, an expired document, a signing window that already closed, a document that was already signed, a policy rule that rejects the request.

When those failures live inside the implementation, the only way to know they exist is to open the method and read it. That's annoying with your own code and genuinely painful with old code, unfamiliar code, or code an AI agent wrote.

Sergey's argument was that expected failures belong in the method contract, not buried in the body. Instead of leaning on runtime exceptions, he showed how to make success and failure explicit in Kotlin using sealed interfaces, typed result models, and the Either approach.

He also pushed back on the instinct to create one big shared error type. He'd rather define a narrow union of errors per method, so each method only advertises the failures it can really produce. The caller stops handling impossible cases, and the compiler starts working for you instead of against you.

The cost is real: more types, more mapping code, more verbose signatures. What you get back is clearer contracts and error handling you can actually predict. As he put it, the goal isn't to get rid of exceptions. It's to stop hiding the failures you already know about.

From more tests to better focus

The second talk was by Artemii Zakharov, Lead QA Engineer at Salmon Group Ltd, on moving from test cases to risk management.

His starting point was very concrete: regression testing stops scaling at some point. His team had around 2,000 test cases, roughly 500 automated and the rest manual. With eight QA engineers, that was about 57 hours of regression on paper, and once you added analysis, retesting, back-and-forth, and bug fixes, a release could take around five days just to validate.

The issue wasn't a shortage of test cases. It was that piling on more of them had stopped helping. As a product grows and its parts get more connected, one small change can ripple into onboarding, payments, support, conversion, or real money moving around. More tests doesn't mean more attention on the things that actually matter.

That's the case for risk-based testing. It isn't about testing less at random. It's about figuring out which areas can hurt the business most and putting your effort there. Artemii framed it around three questions: how much would this hurt users or the business (impact), how far can the change reach (change surface), and how much protection already exists, like automated tests, reviews, or monitoring (safety net).

The part that got the most interest was how his team uses AI for release impact analysis. The AI doesn't make the call. It produces a readable report flagging where the team should look, sorting test cases into must test, recommended, and can skip. That last bucket is the valuable one. Skipping a low-risk area isn't carelessness; it's saving human attention for the parts of the release that can actually do damage.

He was honest about the limits too. AI won't catch runtime dependencies, hidden blast radius, weak test mapping, brand-new features, or business-critical boundaries unless the team feeds it that context. The point wasn't that AI replaces QA. It's that AI can take the repetitive analysis off your plate so QA engineers can spend their time on judgment, exploration, and the business context only they have.

A full room and a lot of Salmon energy

Around 150 people stayed through the evening. They came for the talks but hung around to meet each other, ask questions, and take photos.

The burgers and pizza went fast. They kept the room fed between talks and gave people a reason to stand around and chat instead of rushing off.

The Q&A after both talks was genuinely good. People asked about Kotlin vs Java, how to keep error types from sprawling, how to enforce typed error handling across a big team, what AI-assisted QA looks like in a real repo, and how teams deal with human error, non-technical bug reports, and test coverage after a release ships.

The photobooth was a nice touch, a casual way to grab a few photos that made the night feel more like people hanging out than a conference. That's the kind of evening we're trying to build: somewhere you can learn something and also feel part of Korea's international tech scene.

Huge thanks

This event wouldn't have happened without:

Sergey Chernov and Artemii Zakharov for two honest, practical talks
Salmon Group Ltd for backing the event
Maru by the Asan Nanum Foundation for hosting us
Cry Cheeseburger for the burgers
Everyone from Salmon who helped run the night: Aleksey, Bertijn, Brian, Marcus, Oscar, Sonali, Suhyun, Svetlana, and Valentina
And everyone who showed up, asked questions, took photos, shared posts, and stuck around to talk

We're looking forward to the next one.

Watch the talks

Both talks are online:

You can find every published Dev Korea talk on our talks page.

Ready for your next move?
Visit Dev Korea to explore the latest job openings at dev-korea.com/jobs, or if you're hiring, post a job at dev-korea.com/post-a-job and connect with our growing international tech community.