자동차 경주 미션이라는 소식을 듣고 level1 때 처음 진행했던 미션이 떠올랐다. level1때 작성한 코드를 다시 보니 수정할 부분이 많이 보였고 그 만큼 성장했다는 것이 느껴져서 좋았다. 이번 미션은 console로 동작하던 자동차 경주를 spring을 이용해서 웹으로 동작하도록 구현하는 것이었다. 스프링을 이용해 본 경험이 있었지만 이해를 기반으로 한 것이 아니어서 모든 것이 새롭게 느껴졌고 급하지 않게 꾸준히 학습하는 것을 목표로 삶고 미션을 수행했다.
Layered Architecture를 사용하고 느낀점
이번 미션에서는 소프트웨어 개발에서 일반적으로 널리 사용되는 Layered Architecture를 이용했다. 그 이유는 일반적으로 소프트웨어 개발 시에 널리 사용되어 모르는 부분이 생겼을 때 자료를 찾기 쉽다는 것과 주변 크루들이 쉽게 알려줄 수 있다는 장점이 있어서 였다. 미션의 요구사항을 크게 분류하면 다음과 같이 정리할 수 있다.
- 참가자 이름과 실행횟수를 담고 있는 요청이 들어온다. - 요청
- 게임을 실행한다. - 비즈니스 로직 수행
- 게임 결과 및 우승자를 저장한다. - 데이터 저장
즉, 그림으로 도식화를 하면 다음과 같이 정리가 가능했다.
위의 그림을 보면 알 수 있듯이 관심사의 분리를 다음과 같이 했다.
- controller - 사용차의 요청을 전달하고 화면에 나타낼 정보를 반환
- service - 요청을 통해 비즈니스 로직을 수행
- repository / dao - 데이터를 저장 및 읽어오기 기능을 수행
위와 같이 관심사를 분리하여 개발을 하면서 느낀 장점들이 있었다. 가장 먼저 유지보수를 하는 것이 쉬었다. 명확한 역할과 책임이 부여되어 수정을 하는데 있어서 빠르게 리소스를 찾을 수 있었고 빠르게 수정을 할 수 있었다. 또한 캡슐화가 깨지지 않았고 단위 테스트를 작성하는 것이 편리했다. 물론 layered Architecture는 요구사항이 많아지고 기능들이 많아지면 확장에는 어려움이 있다고 하는데 아직은 프로젝트 크기가 작아서 단점을 느끼지는 못했다.
스프링 빈으로 등록을 해야하는 것은 어떤 것일까?
Spring은 스프링 컨테이너 내에 객체를 bean으로 관리하여 객체를 호출하게 되면 참조하는 래퍼런스를 외부에서 주입해주어 개발자로 하여금 생성에 대한 리소스를 줄이고 비즈니스 로직을 작성하는 것에 집중하도록 도움을 줍니다. 그러면 여기서 고민을 했던 것이 과연 어떤 것을 스프링 bean으로 등록하는 것이 좋을지에 대해 페어와 함께 고민을 했고 다음과 같은 결론을 내렸다.
- 상태를 가지지 않는 객체 (상태 조회만 가능한 객체)
- 언제든지 동일하게 동작하는 객체
위와 같이 크게 두가지로 정의를 했다. 다음과 같이 결론을 내린 이유는 스프링 bean은 싱글톤으로 관리되기 때문입니다. 싱글톤은 하나의 인스턴스만을 생성해서 이용한다는 것이다. 그렇기에 여러요청이 들어왔을 때 같은 인스턴스를 공유한다는 것이고 동시성 문제를 가져올 수 있다. 즉, 상태를 가지는 객체에 상태를 수정하는 요청이 동시다발적으로 들어오게 된다면 요청을 보낸 사람들이 원하는 결과를 가져올 수 없다는 것이다. 그렇기에 스프링 bean은 싱글톤으로 관리되는 만큼 상태를 가지지 않는 객체들을 등록하는 것이 좋다.
그 동안에는 스프링을 사용하기 위해 구글에 검색하고 그대로 적용한 이후에 “왜”라는 질문을 하지 않았고 이해하려는 노력이 부족했었다. 그래서 처음 접하는 크루에게도 설명을 해줄 수 없는 제 모습을 보면서 반성을 했고 앞으로는 크루들에서 설명을 할 수 있을 만큼 학습을 해야겠다고 느꼈다.
