Mocklantis: 현대적인 API 모킹을 간단하게

발행: 3일 전 (2025년 12월 12일 오후 11:48 GMT+9)

14 min read

Source: Dev.to

Mocklantis screenshot

의존성의 숨은 비용: 목킹이 중요한 이유

마이크로서비스 아키텍처와 함께 일한다는 것은 의존성을 감수한다는 뜻입니다. 여러분의 서비스는 다른 서비스와 통신하고, 그 서비스는 또 세 개의 서비스와 통신합니다. 그리고 이 체인 어딘가에 결제 게이트웨이, 알림 서비스, 그리고 아마도 공격적인 속도 제한을 가진 서드파티 API가 존재합니다.

모든 것이 정상적으로 가동되고 있다면 삶은 좋습니다. 하지만 아무도 묻고 싶어 하지 않는 질문이 있습니다: 서비스가 동작하지 않을 때는 어떻게 할까요?

타임아웃 상황을 어떻게 테스트하나요?
결제 서비스에서 503 오류를 어떻게 시뮬레이션하나요?
재시도 로직이 실제로 동작하는지, 문제가 발생하기 전에 어떻게 알 수 있나요?

이 질문들은 불편합니다. 솔직한 답은 종종 “우리는 하지 않는다” 혹은 “최선을 바라본다”이기 때문입니다.

충분히 이야기되지 않는 문제들

마이크로서비스 개발에서는 모두를 느리게 만드는 마찰 지점이 있지만, 제대로 다뤄지는 경우는 드뭅니다.

의존성이 진행을 막는다. 여러분의 서비스는 준비됐지만, 의존하고 있는 서비스는 아직 아닙니다. 다른 팀이 아직 개발 중일 수도 있고, 샌드박스 제한이 있는 서드파티 API일 수도 있습니다. 혹은 프로덕션에서만 정상 동작하는 결제 게이트웨이일 수도 있습니다. 이유가 무엇이든, 여러분은 통제할 수 없는 무언가를 기다리고 있습니다.

단위 테스트는 잘못된 자신감을 만든다. 테스트가 통과합니다. 초록색 체크마크가 여기저기 보이죠. 하지만 단위 테스트가 통과한다는 것은 코드가 격리된 상태에서—프로그래밍한 대로 동작하는 목(mock) 인터페이스와 함께—잘 동작한다는 의미일 뿐입니다. 실제 서비스는 그렇지 않습니다. 타임아웃이 발생하고, 예상치 못한 응답을 반환하며, 일요일 새벽 3시에 실패하기도 합니다.

실패를 시뮬레이션하는 것이 기능을 만드는 것보다 어렵다. 하위 서비스가 503을 반환했을 때 어떤 일이 일어나는지, 회로 차단기(circuit breaker)를 테스트하고, 폴백 로직이 정상 작동하는지 확인해야 합니다. 이러한 조건을 만드는 과정에서 팀은 포기하고 모니터링이 프로덕션에서 문제를 잡아주길 기대합니다.

모두가 목킹을 다르게 한다. 어떤 개발자는 JSON 응답을 하드코딩하고, 또 다른 개발자는 작은 Express 서버를 작성합니다. 또 다른 사람은 YAML 설정을 가진 CLI 도구를 사용합니다. 스테이징 환경은 네 팀이 공유하고 끊임없이 깨집니다. “내 컴퓨터에서는 동작한다”가 팀의 모토가 됩니다.

이러한 상황은 드문 경우가 아닙니다. 대부분의 백엔드 팀에게는 화요일과도 같습니다.

마이크로서비스만의 문제가 아니다

의존성 문제는 마이크로서비스 아키텍처에만 국한되지 않습니다. 두 시스템이 서로 통신해야 하는 곳이라면 어디든 존재합니다.

백엔드 API가 준비되길 기다리는 프론트엔드 팀.
서버 엔드포인트가 아직 배포되지 않아 차단되는 모바일 앱.
서드파티 시스템의 속도 제한이나 샌드박스 제약으로 인해 지연되는 통합 프로젝트.

패턴은 동일합니다: 여러분의 작업은 완료됐지만, 다른 무언가가 없어서 검증할 수 없습니다. 여러분이 막힌 것은 코드가 아니라 외부 요인입니다.

이때 목킹은 선택이 아니라 필수 요소가 됩니다—그저 ‘있으면 좋은’ 것이 아니라 소프트웨어가 구축되고 테스트되는 근본적인 부분이죠.

목킹이 나쁜 평판을 갖는 이유

목킹 개념은 단순합니다: 가짜 서비스를 만들어 예측 가능한 응답을 반환하고, 여러분의 코드를 그 위에서 테스트하며, 필요한 모든 시나리오를 시뮬레이션합니다.

이론적으로는 완벽한 해결책입니다. 실제로는 대부분의 팀이 회피합니다.

전통적인 목킹은 설정 파일(YAML 또는 JSON), CLI 명령, 또 다른 도구의 문법 학습을 필요로 합니다. 응답을 바꿀 때마다 서버를 재시작하거나 설정을 다시 로드해야 합니다.

“이미 기능을 구현했고, 단위 테스트도 작성했습니다. 이제 다른 사람이 끝냈어야 할 서비스를 시뮬레이션하기 위해 또 다른 설정을 해야 한다니?”

마찰이 너무 커서 팀은 불안정한 스테이징 환경을 사용하거나 통합 테스트 자체를 건너뛰게 됩니다. 어느 쪽도 좋지는 않지만, 두 경우 모두 목‑서버 설정과 싸우는 것보다 실용적으로 느껴집니다.

Mocklantis가 이를 바꿉니다.
Mocklantis는 목 서버를 손쉽게 만들 수 있는 무료 데스크톱 애플리케이션입니다. macOS, Windows, Linux에서 로컬로 실행되며 HTTP/REST 엔드포인트, WebSocket 연결, Server‑Sent Events, 웹훅을 모두 하나의 앱에서 지원합니다.

차별점은 바로 경험입니다:

설정 파일이 없습니다.
CLI 명령이 없습니다.
배울 YAML 스키마가 없습니다.

앱을 열고, 서버를 만들고, 엔드포인트를 추가하고, 바로 테스트를 시작합니다. 변경 사항은 즉시 적용됩니다—재시작도, 재빌드도 필요 없습니다. 모든 것이 시각적이고 즉각적이어서 “이 시나리오를 테스트하고 싶다”와 “이 시나리오를 테스트하고 있다” 사이의 거리가 몇 시간에서 몇 초로 단축됩니다.

Mocklantis 사용 예시

워크플로는 매우 직관적입니다:

애플리케이션을 엽니다.
포트 8080에 서버를 생성합니다.
엔드포인트를 추가합니다, 예시:
```
POST /payments/process
```
JSON 응답과 상태 코드를 입력합니다. 완료. 엔드포인트가 바로 살아 있고, 서비스는 즉시 호출할 수 있습니다.

타임아웃 처리 테스트 – 지연을 추가하면 즉시 적용됩니다.
오류 시나리오 테스트 – 상태 코드를 503으로 바꾸고 서비스가 어떻게 반응하는지 확인합니다.

동적 데이터

Mocklantis는 템플릿 변수—요청마다 재생성되는 UUID, 타임스탬프, 이메일, 이름, 사용자 정의 패턴 등을 지원합니다. 총 14가지 종류의 랜덤 변수 타입이 내장되어 있습니다.

WebSockets

Mocklantis는 세 가지 WebSocket 모드를 제공합니다:

Conversational – 요청‑응답 패턴.
Streaming – 지속적인 데이터 흐름.
Triggered streaming – 클라이언트 메시지가 응답 시퀀스를 트리거(AI 스타일 상호작용에 최적).

Server‑Sent Events (SSE)

이벤트를 구성하고, 간격을 설정하며, 연결 시 메시지를 정의합니다—AI 애플리케이션에서 토큰 단위 스트리밍을 테스트하기에 이상적입니다.

Webhooks

엔드포인트가 호출될 때 Mocklantis는 인증, 재시도 로직, 지연을 설정할 수 있는 HTTP 요청을 다른 URL로 전송합니다.

모든 것이 시각적이고 즉각적이며, 별도의 서버 코드를 작성할 필요가 없습니다.

작은 기능, 큰 영향

몇몇 기능은 실제로 필요해 보기 전까지는 사소해 보입니다. Mocklantis는 이러한 디테일을 정확히 구현합니다.

재시작 없이 실시간 업데이트 – 서비스가 실행 중일 때도 응답을 수정하고, 지연을 추가하고, 상태 코드를 전환합니다.
자동 영구 저장 – 모든 변경이 즉시 저장됩니다(500 ms 디바운스). 앱을 닫아도 그대로 복원됩니다.
실시간 요청 로그 – 목 서버에 들어오는 모든 요청을 헤더, 바디, 타이밍과 함께 확인합니다.
프록시 모드 – 일부 엔드포인트는 목으로, 나머지는 실제 서비스로 포워드해 특정 의존성만 격리하고 나머지 스택은 그대로 유지합니다.
어디서든 가져오기 – cURL 명령을 붙여넣고, OpenAPI 스펙을 가져오고, .mock 파일을 로드합니다.
로컬 전용 운영 – 모든 것이 localhost에서 실행됩니다; 클라우드 계정이 필요 없고, 데이터가 머신을 떠나지 않으며, 민감한 테스트 데이터가 외부에 기록될 염려가 없습니다.

각 기능 자체는 혁신적이지 않을 수 있지만, 함께 작동하면 팀이 제대로 테스트하는 것을 방해하던 마찰을 제거합니다.

마찰 문제

개발자 도구는 보통 **‘기능이 많을수록 복잡성도 증가한다’**는 패턴을 따릅니다—학습 곡선이 가파르고, 문서가 방대하며, Stack Overflow 질문이 늘어납니다. Mocklantis는 강력한 목킹 기능을 코드 없이, 설정 파일 없이, 외부 서비스 없이 간단한 시각 인터페이스로 제공함으로써 이 흐름을 뒤집습니다. 그 결과 개발자는 도구와 싸우는 시간을 줄이고, 신뢰할 수 있는 소프트웨어를 만드는 데 더 많은 시간을 할애할 수 있게 됩니다.