아키텍쳐가 필요한 이유와 4가지의 효과 (더 많지만 간략하게)

 

나도 예전에는 정말 아무렇게나 개발을 했었다. 하지만 내가 다니던 학교에는 훌륭한 선배들이 많이 계셨고. 그 분들을 통해서 코드를 잘짜는 것이 중요하다는 것을 배울 수 있었다. 특히 아키텍처는 나의 프로그래밍을 바꾸어 놓았다. 그렇기에 더 많은 사람들이 단순히 동작에 집중하는 것이 아니라, 아키텍처에 대해서 익혔으면 한다. 하지만 아키텍처는 직접 구현해보기 전까지는 그 진입장벽이 높아 공부하기 어려우며 그 중요성이 크게 와닿지 않는다는 점이 있다. 그렇기에 이번 글을 통해 아키텍처에 대해 최대한 와닿을 수 있게 아키텍처의 효과에 대해서 써보고자 한다.

 

아키텍처에 대한 예시

만약 규모가 좀 있는 일을 해본다고 하자. 당신 혼자서 이 일을 전부 마무리 할 수 없다. 그렇기에 당신은 조직을 구성해서 이 일을 해결해야 한다. 그렇다면 당신은 이 조직을 어떻게 구성할 것 인가? 대부분 초보 프로그래머는 조직을 구성하지 않고 주먹구구 식으로 일을 처리한다. 그냥 눈에 보이는대로 일을 시키는 것 이다. 만약 정말 간단한 작업이라면 이 편이 훨씬 낫다.

 

하지만 당신이 빌딩을 지을때도 이럴 수 있을까? 주먹구구식으로 지었다가는 당신이 지은 빌딩은 폭삭 주저앉을 것 이다. 이럴때 필요한 것이 아키텍처이다. 아키텍처는 조직에서 부서를 나누고 부서들간의 소통하는 법을 규정해준다. 아키텍처는 당신의 조직(코드)을 체계적으로 구성하는 것을 도와줄 것 이고. 일을 효율적으로 처리할 수 있게 해줄 것 이다. 

 

어디서 에러가 나는지 감을 쉽게 잡을 수 있다.

이 말도 잠시만 생각해보면 이해할 수 있을 것 이다. 주먹구구식으로 업무를 하는 조직에서 책임소재 파악이 쉬울까? 아마 한 사람 한 사람 다 조사해봐야 할 것 이다. 하지만 부서가 잘 짜여진 조직(코드)이라면? 책임이 있는 부서에 가서 상황을 파악하면 그만이다. 당신이 만약 아키텍처를 잘 구성해놓았다면 에러 찾기는 훨씬 쉬워질 것 이다.

 

코드 변경을 최소화 시킬 수 있다.

전체적인 변경이 아니라면 굳이 모두에게 전달할 필요가 없다. 하지만 주먹구구에서는 전체 인원에게 이 사항을 전달해야 한다. 하지만 잘 짜여진 조직(코드)이라면 해당 부서에만 변경사항을 요청하면 된다. 부서 하나를 바꾸는게 쉬울까? 아니면 전체사람들을 바꾸는게 쉬울까?

 

테스트가 용이하다.

테스트는 업무평가라고 생각해보자. 주먹구구식으로 일하고 있는 사람들을 어떻게 업무평가할 것 인가? 나는 차라리 업무평가를 포기할 것 같다. 하지만 잘 짜여진 조직(코드)이라면 부서별로 담당하는 업무에 따라 기준을 세우고 쉽게 업무평가를 할 수 있다. 이 과정을 통해서 당신의 조직은 좀 더 견고해질 수 있을 것 이다.

 

프로젝트에 대한 제어

주먹구구식으로 하는 조직을 당신은 제어할 수 있는가? 아마 여기저기서 새롭고도 참신한 문제들이 발생할 것 이다. 당신은 제어력을 잃을 것 이다. 제어력을 잃는다면 그 다음부터는 말을 하지 않아도 알 것이라 생각한다. 그러니 당신은 조직을 제대로 구성해서 제어를 잘 해내야 한다. 정말 간단한 일이 아니라면 아키텍처를 잘 구성하길 바란다.