테스트를 늘리기 전에 리스크 맵부터 만든 이유

테스트 품질 이야기는 추상적으로 흐르기 쉬워요. 테스트를 더 추가하자, 커버리지를 올리자, 회귀를 더 빨리 잡자 같은 말은 모두 맞지만 충분하지는 않아요.

하지만 제품 안에 auth, billing, webhook, streaming, 외부 API 호출이 같이 들어오기 시작하면, 단순한 테스트 개수는 좋은 계획 도구가 되지 못해요.

그래서 Porta는 또 한 번 넓게 테스트를 늘리기 전에, 먼저 리스크 맵을 만들었어요.

중요한 질문은 테스트 개수가 아니었다

여기서 유용했던 질문은 "테스트가 몇 개인가?"가 아니었어요.

진짜 중요한 질문은 이거였어요.

"현재 테스트가 놓쳤을 때 제품에 가장 크게 아픈 실패는 무엇인가?"

이 질문으로 바꾸면 대화가 달라져요. Mock 기반 happy-path 테스트 하나와 DB-backed idempotency 테스트 하나는 같은 "1개의 테스트"로 보일 수 있지만, 줄여주는 리스크는 전혀 달라요.

맵은 프레임워크가 아니라 요청 흐름에서 시작했다

먼저 도움이 됐던 건 위험한 영역을 제품 언어로 다시 쓰는 일이었어요.

• auth와 authorization
• billing consume와 idempotency
• webhook deduplication
• external API resilience
• abuse와 rate limiting

이 프레이밍이 중요한 이유는 테스트를 모듈이 아니라 실패 모드에 연결해 주기 때문이에요.

"이 router 테스트를 더 늘려야 한다"가 아니라, "이 경로는 중복 과금, 권한 누수, 동시성 경합을 일으킬 수 있다"라고 말할 수 있게 돼요.

훨씬 더 좋은 우선순위 언어이에요.

P0 경로에는 DB-backed integration test를 먼저 붙였다

맵이 명시되자 첫 투자처도 분명해졌어요.

가장 위험한 흐름은 mock가 실제 문제를 가릴 수 있는 곳들이었어요.

• owner와 admin의 접근 차이
• billing request_id 중복 처리
• webhook receipt 고유성
• 실제 insert와 timestamp에 의존하는 rate-limit window

이런 곳은 DB가 단순한 저장소가 아니라, 동작 자체의 일부예요.

그래서 전략은 자연스럽게 이렇게 정리됐어요.

"위험한 경로부터 DB-backed integration test로 옮긴다."

같은 가정을 반복하는 mock 테스트를 더 쌓는 것보다 훨씬 의미 있는 방향이었어요.

PR 체인이 작업을 더 검토 가능하게 만들었다

리스크 맵에서 특히 좋았던 건 PR tracker였어요.

각 단계마다:

• 범위가 좁고
• 상태가 있고
• 어떤 리스크를 줄였는지 한 문장으로 적혀 있어요

행정적으로 보일 수 있지만, 실제로는 꽤 강한 엔지니어링 도구예요.

작업을 검토 가능하게 만들고, 테스트 개선 작업이 하나의 모호한 "품질 향상 브랜치"로 커지는 걸 막고, 각 테스트 묶음이 왜 존재하는지 설명하게 만들어요.

이 접근은 production code를 덜 비틀게 했다

테스트 개선 작업에는 함정이 있어요.

계획이 너무 커지면 production code가 harness에 맞춰 휘기 시작해요.

여기서 더 좋은 결과는 더 보수적인 방식이었어요.

• production 동작은 명시적으로 유지하고
• 리스크가 큰 곳에만 real DB fixture를 쓰고
• 불안정한 외부 시스템만 mock하고, 핵심 내부 로직은 그대로 검증하는 것

빠르게 움직이는 제품에서 테스트 스위트를 키우는 데는 이런 방식이 더 건강해요.

실제로 바뀌는 건 테스트만이 아니에요

리스크 맵은 테스트 파일 정리표 이상이었어요.

팀이 자신감을 말하는 방식 자체도 바꿔요.

"테스트가 꽤 넓다" 대신 아래처럼 말할 수 있기 때문이에요.

• auth와 project access는 DB-backed matrix로 확인한다
• billing deduplication은 실제 uniqueness 제약 아래에서 본다
• webhook duplication race는 harness에 들어가 있다
• rate-limit window는 저장된 이벤트 기준으로 본다

이쪽이 훨씬 더 날카롭고, 설명 가능한 자신감이에요.

마무리

테스트가 많다고 자동으로 좋은 건 아니에요. 리스크를 더 줄여야 좋은 거예요.

Porta에서는 맵을 먼저 쓴 덕분에, 제품이 실제로 취약한 곳에 테스트 비용을 더 정확히 쓸 수 있었어요.

나중에 도구가 바뀌더라도, 이 순서만큼은 계속 남길 가치가 있어요.