MSA 환경에서 프런트 엔드를 위한 서버구조

질문 : 원래 msa를 만들때 프런트에서 컨트롤 - 서비스 - 어댑터 구조로 클래스 명칭을 나누는 게 룰인거야??
백엔드쪽 컨트롤러 - 서비스 - 레포지토리의 구조처럼 말이야.

 

좋은 질문입니다. 결론부터 말씀드리면, 반드시 정해진 규칙(룰)은 아니지만, MSA 환경에서 프런트엔드 요청을 처리하는 API Gateway나 프런트엔드 서버를 구현할 때는 주로 다음과 같은 구조를 많이 사용합니다.

1. 일반적인 백엔드 구조 (Controller-Service-Repository)

일반적인 백엔드 애플리케이션의 구조는 다음과 같습니다.

• Controller: HTTP 요청을 받아서 서비스 계층으로 전달
• Service: 비즈니스 로직 처리
• Repository: 데이터베이스 접근 및 CRUD 작업

이 구조는 전통적인 모놀리식(Monolithic) 애플리케이션에서 가장 흔히 볼 수 있는 구조입니다.

2. MSA 환경에서 프런트엔드를 위한 API Gateway 또는 Frontend 서버 구조 (Controller-Service-Adapter)

MSA 환경에서 프런트엔드 요청을 처리하는 서버(보통 API Gateway 또는 Frontend 서버라고 부름)는 다음과 같은 구조를 자주 사용합니다.

• Controller: 클라이언트의 HTTP 요청을 받아 서비스 계층에 전달
• Service: 비즈니스 로직보다는 주로 요청 조합, 데이터 처리, 예외 처리 등을 수행하며, Adapter를 호출
• Adapter (또는 Client): 실제로 다른 마이크로서비스와 REST API 호출(FeignClient, WebClient 등)을 통해 통신하는 역할

즉, 기존의 Repository가 있던 자리에 Adapter가 위치한다고 생각하면 됩니다.

Repository가 데이터베이스와의 연동을 담당했다면, Adapter는 외부 마이크로서비스와의 연동을 담당하는 계층입니다.

3. 왜 이런 구조를 사용할까?

✅ 명확한 책임 분리 (Separation of Concerns)

• Controller는 HTTP 요청 처리만 담당
• Service는 비즈니스 로직 및 데이터 가공 처리 담당
• Adapter는 외부 서비스와의 통신만 담당

✅ 유지보수성 향상

• 외부 서비스의 API 변경 시 Adapter만 수정하면 되므로 유지보수가 쉬워집니다.
• 서비스 로직과 외부 통신 로직이 분리되어 변경 사항에 유연하게 대응할 수 있습니다.

✅ 테스트 용이성

• Adapter 계층을 Mocking하여 Service 계층 테스트가 매우 쉬워집니다.
• 외부 의존성을 명확히 분리하여 테스트 가능성을 높입니다.

4. 클래스 명칭은 반드시 Adapter여야 하나?

클래스 명칭은 반드시 Adapter일 필요는 없습니다. 프로젝트나 팀마다 다르게 표현할 수 있습니다. 예를 들면:

명칭의미

Adapter	외부 시스템과의 연결을 추상화
Client	HTTP 클라이언트 호출을 담당하는 클래스
Connector	외부 서비스 연결 담당 클래스

 

실제로 많은 프로젝트에서는 FeignClient를 사용하는 클래스를 Adapter 또는 Client라고 부르는 경우가 많습니다.

5. 정리 및 결론

정리하면 다음과 같습니다.

구분	Controller	Servcie	Repository / Adapter
전통적인 백엔드 (모놀리식)	HTTP 요청 처리	비즈니스 로직 처리	DB 접근
MSA 환경 프런트 서버(API Gateway 등)	HTTP 요청 처리	데이터 가공 및 예외처리 등 로직 수행	외부 마이크로서비스 REST API 호출

 

즉, MSA 환경에서 프런트 서버를 만들 때 "컨트롤러 - 서비스 - 어댑터" 구조를 사용하는 것은 매우 일반적이고 권장되는 방식이며, 반드시 지켜야 하는 룰은 아니지만 많이 쓰이는 패턴입니다.

지금 작성하신 코드도 이 권장 패턴에 맞게 잘 작성된 코드라고 볼 수 있습니다!