개발자에게 아키텍처가 중요한 이유

 

클린 아키텍처

 클린 아키텍처는 프로젝트가 확장될 때 그 위력을 발휘한다. 프로젝트가 확장됨에 따라 로직이 여러 차례 바뀌게 되고 데이터 의존성은 뒤죽박죽 되기 십상이다. 이를 사전에 방지하기 위해서는 처음부터 견고하게 프로젝트 구조를 잡아야 한다. 

 

 클린 아키텍처는 객체 지향 설계를 원칙으로 한다. 이 원칙은 SOLID 원칙이라고도 불리는데 의존성 분리가 핵심이다. 예를 들어 로그인을 위해 아이디와 패스워드를 입력하는 유저가 있다고 해보자. 로그인 시 해당 정보는 사전에 정의된 api경로로 요청을 보낸다. 이후 API 서버에서는 해당 경로의 컨트롤러로 정보를 보내주고 컨트롤러는 해당하는 정보가 있는지 모델에서 알맞은 정보를 가져온다. 알맞은 정보가 있다면 로그인 성공이라는 메시지를 사용자에게 반환해준다. 이 과정에서 모델은 컨트롤러나 뷰(사용자에게 반환된 정보)에 대해 어떤 간섭도 해선 안된다. 쉽게 말해, 모델에서 사용자에게 표시되는 화면의 정보를 수정하거나 컨트롤러를 직접 호출하면 안 된다는 이야기다.

 

 그러나 기능이 다른 로직을 추가해야한다면 얘기는 달라진다. 객체 지향 설계에서는 단일 책임의 원칙에 따라 클래스는 하나의 기능만 가질 수 있다. 이에 따라 컨트롤러는 뷰에서 비롯된 사용자 입력을 적절히 가공해서 모델을 업데이트하고, 모델을 반환할 뷰를 선택하는 역할로 만 수행해야 된다. 이때 컨트롤러에서 다른 기능을 동시에 수행하게 되면 컨트롤러는 2가지의 목적을 수행하게 되고 개발 유지보수 입장에서 번거로울 수 있는 문제가 발생한다. 

 

 

시간 절약에서의 기초

 기초가 무너지면 모두 무너진다. 개발에 있어서 함수/변수명 짓기가 가장 어렵다고 알려진 데에는 그 이유가 있다. 적어도 이름을 짓는 데에는 그 의미가 반드시 내포되어야 하기 때문이다.

 개발자는 코드를 짜기 전에 그 코드가 달성해야 하는 목적과 이유를 알고 있어야 한다. 만일 그러지 않는다면, 함수는 제 기능을 수행하지 못하고 Dead code(사용되지 않는 코드)가 되고야 만다. 함수 로직을 작성하는 데 있어 함수의 목적에 맞지 않는 코드를 입력한다면, 추후에 그 함수를 재사용할 때 버그가 생길 가능성이 높다. 그렇게 된다면 같은 기능을 수행하지만 목적이 다른 코드를 한 번 더 작성하게 되고 이전 코드는 재사용되지 않는 일회성 코드가 된다. 이는 프로젝트의 품질을 낮출 뿐 아니라 기능 추가의 관점에서도 비효율적인 결과를 보여준다. 그렇기에 코드의 목적을 정의하고 올바른 기능을 수행하도록 한다는 건 가장 기초라고 할 수 있다. 

 

 

유명한 짤

 

 이름 짓기 또한 아키텍처의 일부이다. 개발자에게 로직의 역할만 주어지고 구현하라고 한다면 쉽게 하겠지만, 정작 그 코드가 왜 필요하고 어디에 쓰이는지 설명하라고 한다면 구현보다는 힘들게 느껴진다. 머릿속에 로직은 물론이거와 방향성과 도출되는 결과, 목적까지 알고 있어야 되기 때문이다.

 

 아키텍처 없는 코드란, 설계도 없는 건축시공과 같다. 건축 설계도에는 설계 뿐 아니라 배치도, 투시도, 평면도, 조감도 등 수많은 설계를 포함한다. 그렇게 해야만 설계된 이미지 그대로 지을 수 있고 견고한 집을 지을 수 있기 때문이다. 또한 작업 분배에도 유리해서 어떤 작업자가 어떤 일을 해야 효율적인지를 파악해서 일을 분산할 수 있다. 당연하게도 일을 분산시키면 단기간에 최대한의 효율을 내며 자원을 절약할 수 있다. 아키텍처도 마찬가지다. 개발 목적에 맞는 아키텍처를 적용한다면 시간 절약에 있어 혜택을 본다. 

 

 

개발 생산성

 코드가 복잡해 질 수록 기능 추가에도 어려움이 있다. 

 

https://martinfowler.com/bliki/DesignStaminaHypothesis.html

 설계-지구력 가설이라고 불리는 그래프이다. 시간이 흐르면서 좋은 설계는 기능을 추가하는데 시간이 들지 않고, 설계가 없다면 점점 누적기능이 줄어드는 현상을 설명하고 있다.

 이 그래프는 경제적 관점으로 해석할 수 있다. 시간이 지남에 따라 전체 코드의 맥락을 해석하는데 드는 시간은 상대적으로 높아진다. 다만, 코드의 품질이 좋고 유지 보수하기 쉬운 구조로 설계되어 있다면 주석 없이 코드만 봐도 그 의도를 이해하는데 어려움이 없다. 이는 프로젝트를 완성하는 데 걸리는 시간을 단축시켜주고 장기적인 관점에서 프로젝트를 바라보게끔 작용한다.

 

정리

 기초 없이 응용할 수는 없다. 모든 발명에는 그 근간이 되는 과학 이론이 존재하듯이 기초를 무시한 채 응용한다는 건 불가능하다. 일부 개발자를 예로 든다면, 부트캠프나 독학으로 일부 프레임워크만 배우면 대부분의 개발을 할 수 있다고 한다. 그러나 이는 코더에 불과하다. 적어도 다음 단계의 개발자로 성장하고 싶다면 프레임워크의 동작 원리를 파악하고 이를 만들어낼 수 있는 수준으로 가야 한다. 

 

 

참고 자료

https://velog.io/@summerdewyes/%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90-%ED%8C%A8%ED%84%B4-MVC-MVP-MVVM#mvc-model-view-controller

아키텍쳐 패턴 (MVC, MVP, MVVM)

 

https://www.nextree.co.kr/p6960/

객체지향 개발 5대 원리: SOLID