Controller는 뭘 하는 녀석일까?

 

 

 

먼저 요약하자면, Controller - Service - Repository 구조에서 클라이언트의 요청(Request)에 대한 응답(Response)를 수행하는 역할을 전담하는 녀석이다. 즉 언제나 사용자와 맞닿아 있고, 사용자가 그 너머를 볼 수 없게 하는(인지하지 못 하게 하는) 역할을 한다고도 말 할 수 있다. 개발자 입장에서는 백엔드 개발 요청에 대해 Request와 Response를 어떤 방식으로 할 것인지를 일차적으로 정의해볼 수 있는 공간이 될 것이다.

 

 

 

Controller

스마트폰으로 예를 들어보자면, 전원을 켜고 끄는 것, 앱 목록을 여는 것, 채팅 앱을 실행하는 것, 채팅창을 여는 것, 그 안에서 키보드를 사용해 글을 쓰는 것, 작성한 문자를 버튼을 눌러 전송하는 것 전부 사용자의 컨트롤(Control)의 영역이다. 이 때, 각자의 역할을 하는 기능들의 내부가 어떻게 작동하는지 사용자가 알 길이 있을까? 아마 알아내기 쉽지 않을 것이다.

이렇게, 표면적으로 드러나있는 기능들을 실행했을 때, 이 기능들이 실행될 수 있는 중간다리 역할을 해주는 것이 컨트롤러라고 볼 수 있다. 조금 더 정확하게 말하자면, 사용자가 누른 버튼(Request)이 어떤 버튼인지, 그래서 무슨 일이 일어났는지 알려주는(Response) 역할만을 담당한다고 보면 될 것이다. 내부가 어떻게 돌아가는지는 컨트롤러에게 있어서는 상관이 없고, 어떤 요청이 들어왔는지, 그래서 어떤 결과가 튀어나왔는지만 보여주는 역할을 하는 것이다.

스마트폰을 웹이라고 가정했을 때의 예시. 실제 스마트폰이 어떻게 작동하는지는 나도 모른다.

컨트롤러는 명령 실행 지시 및 결과만 보여주도록 되어있는 것을 볼 수 있다. 이것과 비슷한 맥락으로 Service와 Repository 또한 각자의 역할을 하나씩만 담당하도록 되어있다. 각자의 역할은 철저하게 분담되어있어야 하며, 이렇게 함으로써 기능의 수정 요구나 오류 대처에 있어서 오류가 발생한 부분만을 수정하거나, 다른 영역을 수정해야 한다고 해도 그 영역의 수정을 최소화 시킬 수 있게 된다. 이런 구조를 소프트웨어 용어로는 느슨한 결합(Loose Coupling) 이라고 하며, 이로 인해 얻는 효과를 유지보수성이 증가한다 라고 한다.

 

 

이렇게 컨트롤러가 무엇인가에 대한 설명은 끝이 났고, 그러면 다음에는 스프링부트에서의 @Controller 어노테이션은 대체 어떤 역할을 하는 것이고, 기존의 어떠한 점을 편리하게 만들어 놓았을까에 대해 알아보도록 하자.