계정 시스템을 꼭 만들어 보세요.

대부분의 개발자는 단위 모듈, 단위 화면 중심에 개발을 진행하게 된다.

 

즉, 모든 구성 요소가 존재하는 상태에서 요구사항과 화면에 필요한 구성요소를 가지고 개발을 하게 된다.

 

왜 계정 시스템을 꼭 만들어 보아야 할까?

 

계정 시스템을 개발해 보지 않고는 절대 단위 모듈과 화면 개발에 대한 근본적인 사고를 할 수 없기 때문이다.

 

우리가 단순히 계정 시스템은 로그인과 로그아웃, 회원가입과 인증만 처리하는 것으로 생각하기 쉽다.

 

계정시스템은 단순히 위 기능을 넘어서 모든 단위 개발에 기초가 시작되는 지점이다.

 

또한 계정계를 어떻게 개발했는지에 따라 단위 개발에 개발 편의성이 달라진다.

 

웹 개발에 있어 로그인 이후에 벌어질 이후를 생각해 보자.

 

로그인 이후에 단위 개발자는 로그인한 유저가 누구이고 소속과 일부 개인 정보, 각종 사용자 또는 단체의 설정 정보를 가지고 다녀야 한다면 어떻게 처리해야 할까?

 

모든 Controller Method, Service, Repository마다 위와 같은 사항을 모두 조회하는 코드를 가지고 다녀야 할까?

즉, Copy & Paste로 한다는 이야기다.

 

정말 멍청한 짓이 아닐 수 없다.

 

우리는 ASP.NET이 되었든, Spring Boot가 되었든, Node가 되었는 Request에 대한 Lifecycle이 존재함을 알고 있다.

 

또한 대부분의 Framework가 IoC Container를 탑재하고 있음을 알고 있다.

 

어떻게 처리되어야 할까?

 

Request Lifecycle, 즉, Middleware에서 위와 같은 사항이 이미 처리 또는 조회 되어서  Controller 생성자 또는 Autowired로 주입 되어야 한다.

 

그 주입에 대한 구현이 어떻게 처리 되든, 즉, Transiant이든, Scope이든, Singleton이든 Controller에 진입되기 전에 조회되어야 한다.

 

그래서 단위 개발자는 단순히 Property에 노출된 내역만을 가지고 처리 할 수 있게 해야 한다.

 

따라서, 개발자가 계정계 시스템을 만들어보지 않는다면, 계정계에 대한 정보가 어떻게 효과적으로 단위 개발에 사용될지 고려하지 않는다면 무수한 Copy & Paste 코드가 난무하고 이것들을 정리하려면 엄청난 시간과 인력, 노력이 투입되어야 한다.

 

어쩌면 차라리 다시 개발하는 것이 좋을지 모른다는 판단을 할 정도로 말이다.

 

Context 패턴에 대해 알고 있다면 유용하게 적용할 수 있을 것이다.

 

또한 Lazy Singleton에 대해 알고 있다면 유용하게 적용할 수 있다.

 

간혹, 누군가는 이러한 것들을 모두 Session을 통해서 처리하고자 한다면 이미 웹 개발자, 서버측 Backend 개발자로서 상실이다.

 

Session이 무엇인지 알고 있다면 개발 과정에서 Session을 통해 이러한 것들을 처리한다는 것이 얼마나 고통을 수반하는 일인지 알고 있어야 한다.

 

이전 글에서도 적었지만, Session은 정말 필요한 최소한의 용도로만 사용해야 한다.

 

그리고 우리는 Redis를 알고 있다.

 

개발자 분들이여, 꼭 한번 계정계 시스템부터 만들어 보자.

 

그 한번의 시도가 당신의 개발 인생에 있어 엄청난 고민과 성과를 동시에 안겨줄 것이다.