Sponsors

최신 채용 공고를 확인하려면 LinkedIn에서 팔로우하고, 매일 알림을 받으려면 Discord 커뮤니티에 참여하세요.

5월 18일, Salmon과 함께 Dev Korea #8을 진행했습니다. 약 150명이 저녁 시간을 함께해 주셨습니다. 개발자, QA 엔지니어, 그리고 서울 테크 씬 곳곳에서 모인 다양한 분들이 두 개의 발표와 그 뒤로 길게 이어진 대화를 위해 자리를 채워 주셨습니다.

Salmon과 함께한 Dev Korea #8 현장: 더 나은 에러 핸들링, 더 똑똑한 QA, 그리고 서울을 가득 채운 하루

This article is also available in English.Read in English →

현장의 분위기가 궁금하신가요? 발표부터 네트워킹까지, 모든 순간을 담은 Dev Korea #8 트레일러를 확인해보세요 🎥.

5월 18일, Salmon과 함께 Dev Korea #8을 진행했습니다. 약 150명이 저녁 시간을 함께해 주셨습니다. 개발자, QA 엔지니어, 그리고 서울 테크 씬 곳곳에서 모인 다양한 분들이 두 개의 발표와 그 뒤로 길게 이어진 대화를 위해 자리를 채워 주셨습니다.

이번 행사는 Salmon 덕분에 가능했습니다. 메인 스폰서로 함께해 주셨을 뿐 아니라, 연사와 굿즈를 준비해 주셨고, 저녁 내내 사람들이 다시 찾게 만든 포토부스까지 마련해 주셨습니다.

Salmon

두 발표 모두 소프트웨어 품질에 관한 이야기였지만, 서로 정반대 지점에서 출발했습니다. 하나는 우리가 코드에 실패(failure)를 어떻게 담아내는지에 대한 이야기였고, 다른 하나는 팀이 릴리스 전에 무엇을 실제로 테스트할 가치가 있는지를 어떻게 판단하는지에 대한 이야기였습니다. 둘을 합쳐 보면, 결국 같은 질문을 던지고 있었습니다. 어떻게 하면 더 이해하기 쉬운 소프트웨어를 만들 수 있을까요?

실패를 더 이해하기 쉽게 만들기

첫 번째 발표는 Salmon Group Ltd의 Lead Software Engineer인 Sergey Chernov가 맡았습니다. 주제는 Kotlin에서의 도메인 에러와 함수형 에러 핸들링이었습니다.

Sergey Chernov

그는 대부분의 백엔드 개발자가 공감할 만한 문제로 이야기를 시작했습니다. 메서드 시그니처만 봐서는 그 안에서 실제로 무엇이 잘못될 수 있는지 알기 어렵다는 점입니다. 함수는 밖에서 보면 단순해 보이지만, 구현 내부에는 예상 가능한 비즈니스 실패가 가득할 수 있습니다. 유효하지 않은 코드, 만료된 문서, 이미 닫혀 버린 서명 기간, 이미 서명된 문서, 요청을 거부하는 정책 규칙 같은 것들이죠.

이런 실패들이 구현 안에만 숨어 있으면, 그 존재를 알 수 있는 유일한 방법은 메서드를 열어서 직접 읽어 보는 것뿐입니다. 자기가 쓴 코드라도 번거로운 일인데, 오래된 코드나 익숙하지 않은 코드, 혹은 AI 에이전트가 작성한 코드라면 정말 고통스러운 일이 됩니다.

Sergey의 주장은, 예상 가능한 실패는 구현 안에 묻혀 있을 게 아니라 메서드의 계약(contract)에 드러나 있어야 한다는 것이었습니다. 런타임 예외에 의존하는 대신, Kotlin에서 sealed interface, 타입이 명시된 result 모델, 그리고 Either 방식을 활용해 성공과 실패를 명시적으로 표현하는 방법을 보여 주었습니다.

그는 또한 하나의 거대한 공용 에러 타입을 만들려는 습관에도 반대했습니다. 그보다는 메서드마다 좁은 범위의 에러 union을 정의해서, 각 메서드가 실제로 발생시킬 수 있는 실패만 노출하도록 하는 편을 선호했습니다. 그러면 호출하는 쪽은 일어날 수 없는 케이스를 처리하지 않아도 되고, 컴파일러가 발목을 잡는 대신 우리를 위해 일하기 시작합니다.

물론 비용은 있습니다. 타입이 늘어나고, 매핑 코드가 늘어나고, 시그니처도 더 장황해집니다. 그 대가로 얻는 것은 더 명확한 계약과, 실제로 예측 가능한 에러 핸들링입니다. 그의 말을 빌리자면, 목표는 예외를 완전히 없애는 게 아닙니다. 이미 알고 있는 실패를 더 이상 숨기지 않는 것입니다.

더 많은 테스트에서 더 나은 집중으로

두 번째 발표는 Salmon Group Ltd의 Lead QA Engineer인 Artemii Zakharov가 맡았습니다. 주제는 테스트 케이스에서 리스크 관리로의 전환이었습니다.

Artemii Zakharov

그의 출발점은 아주 구체적이었습니다. 회귀 테스트(regression testing)는 어느 시점부터 더 이상 확장되지 않는다는 것입니다. 그의 팀에는 약 2,000개의 테스트 케이스가 있었고, 그중 약 500개는 자동화되어 있었으며 나머지는 수동이었습니다. QA 엔지니어 8명 기준으로 따지면 서류상으로는 약 57시간의 회귀 테스트였지만, 분석과 재테스트, 오가는 논의, 버그 수정까지 더하면 릴리스 하나를 검증하는 데 약 5일이 걸리기도 했습니다.

문제는 테스트 케이스가 부족한 게 아니었습니다. 테스트 케이스를 더 많이 쌓는 것이 더 이상 도움이 되지 않게 됐다는 점이었습니다. 제품이 커지고 각 부분이 더 촘촘히 연결될수록, 한 곳의 작은 변경이 온보딩, 결제, 고객 지원, 전환율, 혹은 실제 돈의 흐름으로까지 번질 수 있습니다. 테스트를 더 많이 한다고 해서, 정말 중요한 부분에 더 많은 주의를 기울이게 되는 건 아닙니다.

여기서 리스크 기반 테스트(risk-based testing)가 등장합니다. 무작정 테스트를 적게 하자는 이야기가 아닙니다. 어느 영역이 비즈니스에 가장 큰 타격을 줄 수 있는지를 파악하고, 거기에 노력을 집중하자는 것입니다. Artemii는 이를 세 가지 질문으로 정리했습니다. 이 문제가 사용자나 비즈니스에 얼마나 큰 피해를 줄 수 있는가(impact), 변경이 시스템에 얼마나 넓게 영향을 미칠 수 있는가(change surface), 그리고 자동화된 테스트, 리뷰, 모니터링처럼 이미 존재하는 보호 장치가 얼마나 있는가(safety net)입니다.

가장 많은 관심을 받은 부분은 그의 팀이 릴리스 영향 분석에 AI를 어떻게 활용하는지였습니다. AI가 최종 결정을 내리지는 않습니다. 대신 팀이 어디를 살펴봐야 하는지를 짚어 주는, 사람이 읽을 수 있는 리포트를 생성하고, 테스트 케이스를 반드시 테스트(must test), 권장(recommended), 생략 가능(can skip)으로 분류해 줍니다. 마지막 분류가 특히 유용합니다. 리스크가 낮은 영역을 생략하는 건 부주의가 아니라, 실제로 피해를 줄 수 있는 부분에 사람의 주의를 아껴 두는 일이기 때문입니다.

그는 한계에 대해서도 솔직했습니다. AI는 런타임 의존성, 숨겨진 영향 범위(blast radius), 허술한 테스트 매핑, 완전히 새로운 기능, 비즈니스에 결정적인 경계 같은 것들을, 팀이 충분한 맥락을 제공하지 않으면 잡아내지 못합니다. 핵심은 AI가 QA를 대체한다는 게 아니었습니다. AI가 반복적인 분석 작업을 덜어 줌으로써, QA 엔지니어가 판단력, 탐색, 그리고 자신만이 가진 비즈니스 맥락에 시간을 더 쓸 수 있게 한다는 것이었습니다.

가득 찬 공간, 그리고 가득했던 Salmon의 에너지

약 150명이 저녁 시간을 끝까지 함께해 주셨습니다. 발표를 보러 왔지만, 발표가 끝난 뒤에도 서로 인사를 나누고, 질문을 던지고, 사진을 찍으며 자리를 지켜 주셨습니다.

버거와 피자는 순식간에 동났습니다. 발표 사이사이 모두의 배를 채워 주었고, 사람들이 서둘러 자리를 뜨는 대신 잠시 머물며 이야기를 나눌 핑계가 되어 주었습니다.

F&B

두 발표가 끝난 뒤의 Q&A도 정말 알찼습니다. Kotlin vs Java, 에러 타입이 걷잡을 수 없이 늘어나는 걸 어떻게 막을지, 큰 팀에서 타입 기반 에러 핸들링을 어떻게 강제할지, 실제 레포지토리에서 AI 기반 QA가 어떤 모습인지, 그리고 팀이 휴먼 에러나 비개발자가 올린 버그 리포트, 릴리스 이후의 테스트 커버리지를 어떻게 다루는지 같은 질문들이 오갔습니다.

포토부스도 좋은 포인트였습니다. 사진 몇 장을 가볍게 남길 수 있는 공간이 있으니, 저녁이 격식 있는 컨퍼런스라기보다 사람들이 함께 어울리는 자리처럼 느껴졌습니다. 무언가를 배우면서 동시에 한국의 글로벌 테크 씬의 일원이라고 느낄 수 있는 자리, 우리가 만들고 싶은 저녁은 바로 그런 모습입니다.

Photobooth

진심으로 감사드립니다

이번 행사는 다음 분들이 없었다면 불가능했습니다.

다음 행사에서 또 뵙기를 기대하고 있습니다.

발표 다시 보기

두 발표 모두 온라인에서 보실 수 있습니다.

지금까지 공개된 모든 Dev Korea 발표는 talks 페이지에서 확인하실 수 있습니다.


다음 커리어를 준비하고 계신가요?
dev-korea.com/ko/jobs에서 최신 채용 공고를 살펴보세요. 채용 중이시라면 dev-korea.com/ko/post-a-job에 공고를 올리고, 성장하는 글로벌 테크 커뮤니티와 연결되실 수 있습니다.