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

데우스랠리는 데이터 하나가 조작 패널, 타임라인, 프리뷰, 코드젠 등 여러 곳에서 함께 쓰이는 에디터였어요. 한쪽 기능을 빠르게 고치면 다른 영역의 멀쩡하던 동작이 깨지는 일이 잦았어요. 매주 위클리에서 지난주까지 되던 게 이번주에 안 된다는 이야기가 나왔고 첫 배포 뒤에도 기능 개발은 계속 이어가야 했어요. 이 상태라면 기능을 빨리 추가할수록 회귀 위험도 같이 커진다고 봤어요. 이후 기능을 개발하면서도 기존 기능을 지켜줄 회귀 테스트가 절실했어요.

테스트는 순수 함수 테스트와 React Testing Library 기반 동작 테스트로 나눴어요. 모든 edge case를 증명하기보다 이미 잘 돌아가던 핵심 흐름을 계속 지키는 positive regression test에 집중했어요. 새 기능 작업을 잠시 내려놓고 자주 깨지면 안 되는 코어 흐름부터 테스트 범위로 추렸어요. 데우스 직렬화 데이터 변환, storageDataToDST, 타임라인 계산, 마지막 코드젠 흐름까지 순수 로직 중심으로 테스트했어요.

A를 누르면 팝업이 열린다처럼 사용자가 체감하는 주요 positive interaction을 React Testing Library로 묶었어요. 테스트 데이터를 넣고 특정 함수 호출 결과가 기대한 값과 맞는지 확인하는 순수 함수 테스트를 작성했어요. 데우스 직렬화 데이터가 데우스랠리 전용 데이터로 변환되는 흐름을 테스트 범위에 넣었어요. storageDataToDST에서 마지막 코드젠 흐름까지 이어지는 변환 로직을 테스트했어요. 타임라인 계산 로직처럼 에디터 핵심 동작을 좌우하는 로직도 테스트했어요.

React Testing Library로 사용자의 주요 동작이 예전처럼 이어지는지 확인하는 동작 회귀 테스트를 작성했어요.

기능 개발을 잠시 멈추고 테스트코드 작성에 집중했어요. 첫 배포 이후 약 2주 동안 새 기능을 손에서 놓고 코어 로직 회귀 테스트 작성에 매달렸어요. 당시에는 기능을 빨리 쌓을수록 잘 돌아가던 동작이 깨지는 비용이 더 커지고 있었어요. 기능 개발 속도를 계속 유지하려면 먼저 기존 동작을 잠그는 장치가 필요했어요. 단기적으로는 기능 개발 속도를 늦추는 선택이었어요. positive test 위주로 작성했어요. 모든 경우의 수를 증명하기보다 잘 돌아가던 흐름을 지키는 쪽에 무게를 뒀어요.

테스트코드는 일어날 수 있는 모든 edge case를 따지기보다, 기존 동작을 지키는 데 의의가 있다고 봤어요. 그때 필요했던 건 완벽한 테스트 커버리지보다 기능을 개발하는 중에 멀쩡하던 동작이 다시 깨지지 않게 잠그는 회귀 테스트였어요. 일부 예외 상황은 테스트 범위 밖에 남기도 했어요.

회귀로 동작이 깨지는 일이 눈에 띄게 줄었어요. 예전에는 매주 위클리에서 지난주까지 되던 게 이번주에 안 된다는 이야기가 나왔지만 테스트를 작성한 뒤로는 그런 이야기가 거의 사라졌어요. 문제가 생겼을 때도 책임을 묻는 대화보다, 이 케이스는 테스트코드가 없었네요. 추가하시죠 같은 개선 중심의 대화로 이어질 수 있었어요.

테스트코드는 기능 회귀를 막고 기능 개발을 자신 있게 해주기도 하지만 팀 협업에서도 책임을 묻기보다 더 의미 있는 개선을 이야기하게 해주는 도구가 된다는 걸 알았어요.

다음에 비슷한 에디터를 만든다면 첫 배포 이후가 아니라, 핵심 데이터 흐름이 안정되는 시점부터 positive regression test를 같이 쌓고 싶어요. 데이터 하나가 여러 UI와 변환 로직에서 함께 쓰이는 구조라면, 테스트는 나중에 붙이는 안전망이 아니라 기능 개발 속도를 유지하는 기반으로 더 일찍 가져가야 한다고 느꼈어요.