Mock 테스트

Mock 테스트란 무엇인가

Mock 테스트는 검증하려는 대상이 의존하는 실제 구성요소를 가짜(mock) 객체로 대체해, 인터페이스와 동작을 고립된 상태에서 확인하는 테스트 기법이다. 데이터베이스, 외부 결제망, 타 부서가 개발 중인 모듈처럼 아직 준비되지 않았거나 호출 비용이 큰 의존을 미리 약속된 응답으로 흉내 내는 것이 핵심이다.

이렇게 하면 검증 대상이 의존의 상태나 가용성에 휘둘리지 않고, 정해진 입력에 대해 정해진 출력을 내는지를 반복 가능하게 점검할 수 있다. 즉 무엇을 만들었는가가 아니라 약속한 대로 주고받는가를 보는 도구다.

왜 가짜로 대체하는가

실제 의존을 그대로 붙여 테스트하면 결함이 발생해도 원인이 검증 대상에 있는지 의존 쪽에 있는지 분리하기 어렵다. 외부 시스템이 잠시 응답하지 않거나 데이터가 그날그날 달라지면, 같은 코드가 어제는 통과하고 오늘은 실패하는 불안정한 결과를 낳는다.

Mock은 의존의 응답을 고정해 이 변수를 제거함으로써, 실패가 곧 검증 대상의 문제라는 인과를 분명히 한다. 또한 정상 응답뿐 아니라 지연·오류·빈 값 같은 비정상 응답까지 의도적으로 만들어 낼 수 있어, 실제 환경에서 재현하기 까다로운 예외 경로를 안정적으로 검증하게 해 준다.

단위 검증과 통합의 경계

Mock 테스트는 작은 단위를 빠르게 검증하는 데 강점이 있지만, 가짜 응답이 실제 시스템의 행동과 어긋나면 통과한 테스트가 현실을 보장하지 못하는 함정이 생긴다. 약속한 인터페이스 규약이 실제 구현과 일치한다는 전제 위에서만 Mock의 결과가 의미를 가지기 때문이다.

따라서 단위 수준에서는 Mock으로 폭넓게 경로를 훑되, 핵심 흐름은 실제 의존을 연결한 통합 테스트로 한 번 더 확인하는 이중 구조가 안전하다. 가짜로 빠르게 넓히고 진짜로 좁혀 확정하는 분업이 품질과 속도를 모두 지킨다.

인터페이스 합의의 도구

여러 팀이 병렬로 개발하는 프로젝트에서 Mock 테스트는 단순한 검증을 넘어 인터페이스 합의의 매개가 된다. 호출하는 쪽은 상대 모듈이 완성되기 전에도 약속된 규격에 맞춘 Mock을 두고 자기 로직을 먼저 검증할 수 있고, 이는 일정상의 의존을 끊어 병목을 줄인다.

다만 이때 Mock이 가정하는 입출력 규격이 양 팀의 실제 합의와 한 글자라도 어긋나면, 통합 시점에 충돌이 한꺼번에 드러난다. 그래서 Mock의 응답 정의는 개인의 추측이 아니라 문서화된 인터페이스 명세에 근거해야 하며, 명세가 바뀌면 Mock도 함께 갱신하는 규율이 필요하다.

QA와 QC 관점의 차이

Mock 테스트를 바라보는 시선은 품질 보증(QA)과 품질 관리(QC)에서 결이 다르다. 결함을 찾아내 걸러 내는 QC 관점에서 Mock은 예외 경로까지 촘촘히 훑는 검출 수단이다.

반면 프로세스가 제대로 작동하도록 설계하는 QA 관점에서는, Mock이 실제 규격과 동기화되도록 유지하는 절차 자체가 더 중요한 관리 대상이 된다. 가짜 응답이 낡은 채 방치되면 테스트는 초록불을 켜지만 실제로는 아무것도 보장하지 못하는 위험한 상태가 된다.

결함을 잡는 일과 그 검증이 신뢰할 만한지를 보장하는 일은 별개이며, Mock 테스트는 두 관점을 동시에 요구한다.

운영 적용 시 유의점

실무에서 Mock 테스트는 자동화 회귀 검증의 토대가 되지만, 과하게 의존하면 현실과 멀어진 안심을 줄 수 있다. 모든 의존을 가짜로 덮으면 테스트는 빨라지나, 실제 연동 지점에서만 드러나는 결함은 그대로 통합·운영 단계로 흘러간다.

따라서 가짜로 대체할 의존과 실제로 연결할 의존을 의식적으로 구분하고, 그 경계를 팀의 기준으로 명문화하는 편이 좋다. 또한 인터페이스 명세가 변경될 때 Mock 갱신을 잊지 않도록 명세와 Mock을 같은 변경 단위로 다루는 운영 습관이 장기적인 신뢰성을 좌우한다.