데우스랠리 / 2025.06 ~

데우스랠리 코어 로직 테스트 작성

참고 자료 · 데우스랠리 데모 영상 보기 ↗

TL;DR

데우스랠리 첫 배포 이후에는 기능을 계속 빠르게 쌓아야 했어요. 그런데 한쪽 기능을 고치면 이전에 잘 되던 동작이 다시 깨지는 일이 반복됐어요.

그래서 잠시 속도를 늦추더라도, 이후 개발 속도를 지켜줄 회귀 테스트를 먼저 만들기로 했어요. 약 2주 동안 새 기능 작업을 내려놓고 데우스 직렬화 데이터 변환, 타임라인 계산, 코드젠 흐름, React Testing Library 기반 주요 동작 테스트를 코어 로직 중심으로 작성했어요.

모든 edge case를 증명하려는 테스트라기보다, 이미 잘 돌아가던 핵심 흐름이 다시 깨지지 않게 잠그는 positive regression test에 가까웠어요.

문제 정의 Problem

데우스랠리는 하나의 데이터가 조작 패널, 타임라인, 프리뷰, 코드젠까지 여러 영역에서 함께 쓰이는 에디터였어요. 그래서 특정 기능을 빠르게 고쳐도 그 영향이 다른 영역으로 쉽게 번졌어요.

매주 위클리에서 지난주까지 되던 게 이번주에 안 된다는 이야기가 나왔고, 첫 배포 이후에도 기능 개발은 계속 이어가야 했어요. 이 상태에서는 기능을 빨리 추가할수록 회귀 위험도 같이 커졌어요.

테스트 커버리지 숫자를 높이는 게 목표는 아니었어요. 팀이 기능을 계속 개발하면서도 기존 동작이 쉽게 무너지지 않도록, 자주 깨지면 안 되는 흐름을 먼저 고정하는 장치가 필요했어요.

접근 방식 Approach

모든 경우의 수를 증명하려고 하지는 않았어요. 실제로 자주 쓰이고 깨지면 안 되는 흐름을 지키는 데 초점을 두고, 테스트를 순수 함수 테스트와 React Testing Library 기반 동작 테스트로 나눴어요.

먼저 데우스 직렬화 데이터가 데우스랠리 전용 데이터로 변환되는 흐름을 테스트 범위에 넣었어요. storageDataToDST에서 마지막 코드젠 흐름까지 이어지는 변환 로직, 타임라인 계산처럼 에디터 핵심 동작을 좌우하는 순수 로직을 테스트했어요.

사용자가 체감하는 주요 positive interaction은 React Testing Library로 묶었어요. 예를 들어 A를 누르면 팝업이 열린다처럼, 내부 구현보다 사용자가 실제로 기대하는 동작이 예전처럼 이어지는지 확인하는 방향이었어요.

핵심 결정 Decision

먼저 기능 개발을 잠시 멈추고 테스트코드 작성에 집중했어요. 단기적으로는 새 기능 개발 속도를 늦추는 선택이었어요. 하지만 당시에는 기능을 빨리 쌓을수록 기존 동작이 깨지는 비용도 같이 커지고 있었기 때문에, 계속 달리기 전에 기존 동작을 잠그는 장치가 필요했어요.

테스트는 positive test 위주로 작성했어요. 일어날 수 있는 모든 edge case를 증명하기보다, 이미 잘 돌아가던 핵심 흐름이 계속 유지되는지 확인하는 쪽에 무게를 뒀어요.

물론 이 방식은 일부 예외 상황을 테스트 범위 밖에 남기는 선택이기도 했어요. 그래도 그 시점에 가장 필요했던 건 완벽한 테스트 커버리지보다, 기능을 개발하는 중에 멀쩡하던 동작이 다시 깨지지 않게 막아주는 회귀 테스트였어요.

해결 결과 Result

회귀로 동작이 깨지는 일이 눈에 띄게 줄었어요. 예전에는 매주 위클리에서 지난주까지 되던 게 이번주에 안 된다는 이야기가 나왔지만, 테스트를 작성한 뒤로는 그런 이야기가 거의 사라졌어요.

문제가 생겼을 때의 대화도 달라졌어요. 누가 깨뜨렸는지 책임을 묻기보다, 이 케이스는 테스트코드가 없었네요. 추가하시죠 같은 개선 중심의 대화로 이어졌어요.

배운 점 Learning

이 작업을 하면서 테스트코드는 기능 회귀를 막는 장치이면서, 팀이 문제를 다루는 방식을 바꾸는 도구이기도 하다는 걸 배웠어요.

테스트가 없을 때는 문제가 생기면 어느 변경에서 깨졌는지부터 이야기하게 돼요. 하지만 핵심 흐름에 회귀 테스트가 생기면, 다음에는 어떤 케이스를 추가로 잠글지 이야기하게 돼요. 기능 개발을 더 자신 있게 만드는 것뿐 아니라, 협업 대화를 더 생산적으로 만드는 효과가 있었어요.

이 작업을 다시 한다면 Next

다음에 비슷한 에디터를 만든다면 첫 배포 이후가 아니라, 핵심 데이터 흐름이 안정되는 시점부터 positive regression test를 같이 쌓고 싶어요.

데이터 하나가 여러 UI와 변환 로직에서 함께 쓰이는 구조라면 테스트는 나중에 붙이는 안전망이 아니라, 기능 개발 속도를 유지하는 기반에 더 가까워요. 다음에는 이 기준을 더 일찍 적용해야겠다고 느꼈어요.