왜 갑자기 Spring으로 프로젝트를 만드시려는거에요..?

1. 제대로 된 백엔드 알기

자바스크립트를 공부하고 간단한 프로젝트를 만들 때에는 매우 자유로운 언어 특성상 코드가 잘 짜여진 건지 너무 막 짜고 있는 건 아닌 지 항상 고민했다. 특히 프로젝트의 구조를 잡는 것이 어려웠다.

사실 프론트엔드의 코드나 폴더 구조는 그리 고민하지 않았다. NodeJS와 Express를 사용한 백엔드를 구현할 때는 잘 짜여진 구조에 대해 고민을 많이 했다. 최대한 MVC패턴을 지켜보기 위해 route, controller, service로 폴더를 나누어 각각의 관심사를 분리시키고자 했다.

분명 개발할 당시에는 나름 잘 분리시킨 듯 하였으나 내 코드의 문제점은 리팩터링하고자 할 때 드러났다.
나는 리팩터링을 위한 test code를 작성할 수가 없었다.
( 정확히 말하자면 매우매우 어려웠다. )

service 에 해당하는 각각의 함수들을 테스트하고자 할 때 추상화되지 않은 함수들은 테스트 코드 작성을 매우 어렵게 했다. controller를 테스트하고자 하면 의존하는 service를 수정해야했고, service를 테스트하고자 하면 DB에 직접 접근해야했다.
Mock 함수를 만들어가며 시도해봤지만 Sequelize ORM을 사용한 Query의 결과는 도저히 결과값을 예상할 수가 없었다. 만약 service 계층에서 추상화된 DB접근 방식을 사용했더라면 나만의 DB결과를 Mocking 할 수 있었을텐데 말이다.
뭔가 구조에 큰 문제가 있다는 걸 느꼈다.

이를 조금이나마 해결하기 위해 Express를 확장시킨 Nest.js 프레임워크를 공부하려고 했다. TypeScript가 Default이고 MVC패턴을 지켜 개발하도록 도와주는 좋은 프레임워크였다. 그런데 Nest.js를 공부하다보니 그냥 Spring이 보였다. SpringMVC 혹은 SpringBoot의 개발 방법을 Node.js로 가져온 것이라는 생각이 들었고 차라리 엔터프라이즈 웹 애플리케이션 프레임워크인 Spring을 공부해보자는 결론이 도출됐다.

2. 객체지향에 대한 흥미

함수형으로 프로그램을 작성할 때와 다른 재미가 있었다.
객체지향의 사실과 오해라는 책을 읽고 제대로 된 객체지향 프로그래밍을 해보고 싶었다. 그 동안은 Vehicle 클래스와 그에 상속된 Car, Ship, Plane 클래스가 객체지향의 전부인 줄 알았다. 이제 그것이 진정한 객체지향이 아니라는 것을 알았고 매우 흥미가 생겼다.

Spring은 JAVA 웹 애플리케이션을 더욱 객체지향적으로 작성할 수 있도록 도와주는 프레임워크이다. JavaScript나 TypeScript가 객체지향, 함수형 프로그래밍을 둘 다 취하고 있다고 한들 진정한 객체지향을 지키기는 어렵다고 생각했다. 왜냐하면 객체간의 협력에 의해서만 시스템이 동작하는 자바와는 달리 자바스크립트 기반 언어들은 객체의 메서드가 아닌 그냥 함수들이 객체와 상관없이 난무하기 때문에 객체지향 관련 원칙들을 지켜가며 코딩하기에는 어렵다고 생각한다.

Node.js 버려?

절대 안 버릴 것이다. node.js는 객체지향과는 또 다른 재미가 분명 있다. 함수를 리팩터링하고, 책임을 나누고 함수끼리 의존하고 협업하는 것은 객체지향과는 또 다른 매력이 있다. 다만 그렇더라도 Spring을 어느정도 공부하며 백엔드의 best practice를 조금이나마 깨우친 다음 가져가는 것이 좋을 것같다는 생각이 든다. 그 때는 express가 아닌 Nest.js 를 공부할 것이다.