잡동사니

[개발] 유지보수가 용이한 공통코드 관리 본문

IT/Web

[개발] 유지보수가 용이한 공통코드 관리

yeTi 2016. 1. 20. 22:40

이번 하이마트 G-CRM 서비스(​Spring기반)를 개발하면서 가장 아쉬운 부분이 유지보수의 용이성입니다.
그 동안 개발을 하면서 느낀거지만 DB중심의 서비스 구조를 가져다면 개발이 직관적이라 편해서 초기 구축의 생산성이 높아지는 장점이 있는 반면 실제 서비스단의 설계는 고려되지 않아 서비스의 규모가 커지거나 유지보수시 생산성이 떨어지는 단점이 있습니다. 물론 서비스단의 설계를 하면 되지만 프로젝트의 비용과 시간과 스스로의 능력 부족으로 설계하여 수행하기가 버겁다는것을 느낍니다.
이번에 문득 유지보수가 용이한 웹 어플리케이션의 설계는 어떤식으로 하면 좋을지에 대해 생각하면서 공통코드를 관리방법에 대해 정리한 부분을 남깁니다.

유지보수가 용이한 웹 어플이케이션의 가장 중요한 항목은 종속성의 제거라고 생각합니다. 실제 서비스를 시작하고 유지보수나 추가 기능 개발에 들어갈시 공통코드나 디비의 구조가 변경되면 DB-서버-클라이언트의 코드들을 수정해야하는 구조적인 문제가 발생할 수 있습니다.(물론 설계가 잘못된 겁니다.) 그러한 구조적인 문제를 가지면 개발 후 코드의 변경이 수행될 수록 비용이 많이들뿐만 아니라 개발자가 인지하지 못한 버그가 나타날 수 있습니다.
그렇다면 어떻게하면 DB구조에 독립적이고 DB-서버-클라이언트가 각각 독립적인 서비스를 만들 수 있을까요??

공통코드의 관리를 생각해볼 수 있습니다. DB는 데이터를 조회하기 위해 데이터를 코드화하여 관리하는 경우가 많습니다. 클라이언트단은 사용자 입력 데이터를 처리하기 위해 코드를 사용하고 서버단은 클라이언트로부터 받은 코드값으로 적절한 데이터를 제공하기 위해 코드를 이요하여 분기를 생성합니다. 제가 경험한 경우를 보면 DB에서 사용하는 코드들을 이용하여 사용자 입력 데이터와 맵핑하고 서버로 전송하여 서버는 이에 적합한 데이터를 제공하기 위해 전달받은 인자값으로 분기를 생성합니다. 또한 인자값으로 넘긴 코드가 서버를 통해 데이터를 조회하는 쿼리를 생성하기도 합니다. 여기서 문제가 발생합니다. DB의 공통코드를 변경하면 클라이언트에 맵핑한 코드들과 서버단에서 분기를 위해 사용한 코드들에 영향을 미쳐 서비스 전반적으로 코드를 수정해야합니다.
그렇다면 위의 두가지 문제, 클라이언트에 DB에서 사용하는 코드를 맵핑하는것과 서버단에서 분기하는 부분을 수정하면 공통코드에 대한 종속성을 제거할 수 있을거 같습니다.
첫 번째로 클라이언트단에서 DB 코드를 맵핑하는 부분을 해결해 보겠습니다. 사실 클라이언트단을 DB코드를 굳이 맵핑해 사용할 필요가 없습니다. 다만 개발 편의상 SQL을 쉽게 생성하기 위해 동일한 코드를 사용하는것 뿐입니다. 따라서 클라이언트에서 사용자에게 입력받는 코드를 독립적으로 사용해도 무방하고 DB-클라이언트간 종속성을 깨는 기본적인 방법이라고 생각합니다. 나아가 클라이언트-서버간 인터페이스를 정의하는것이 클라이언트의 공통코드를 관리하는 기본이 될것이라고 생각합니다.
두 번째로 서버단에서 분기하는데 공통코드를 사용하는 문제에 대해서 생각해보겠습니다. 서버단에서 공통코드가 사용된다고 생각하는 것부터가 근본적으로 잘못된 생각하고 이라고 생각합니다. 서버 입장에서보면 클라이언트로부터 받는 인터페이스를 정의하고 비지니스 로직을 만들어서 데이터를 가져오는 인터페이스를 정의하는 것이 역할이라고 생각합니다. 애시당초 클라이언트와 DB간 인터페이스를 정의하지 않고 주먹구구식으로 컨트롤을 생성하고 무의미한 서비스를 만들어서 DAO로 넘기는 방식 자체가 잘 못된거 같습니다. 이는 서버단의 개념을 정립하는것이 해결책이 될거같습니다. 이 내용은 별도의 주제로 포스팅을 하도록 하겠습니다.

결론을 내자면 서비스에서 공통코드를 관리함에있어 DB에서 사용하는 공통코드를 가지고 SQL을 간편하게 만들고자 클라이언트부터 코드를 맵핑해서 SQL단까지 사용하는 것이 유지보수를 하는데 고달픈 문제가 있어 이를 해결하고자 클라이언트-서버간 인터페이스를 정의하고 클라이언트에 필요한 공통코드는 따로 관리하도록하고 서버-DB간 인터페이스를 정의하고 서버에 비지니스로직을 설계하는 방식으로 생각해봤습니다.

Comments