hexdrinker

아키텍처란?

-3 min read

소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다. 그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다.

💬

위에서 말한 컴포넌트가 서로 의사소통하는 방식이 객체지향의 사실과 오해에서 말하는 객체 간의 협력이 아닐까 싶다.

이러한 일을 용이하게 만들기 위해서는 가능한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다.

아마 소프트웨어 아키텍처의 목표가 시스템을 제대로 동작하도록 만드는 데 있다고 생각하고 있었을 것이다. 그래서 위 정의가 낯설 수도 있다.

그러나 시스템 아키텍처는 시스템의 동작 여부와는 거의 관련이 없다. 형편없는 아키텍처를 갖춘 시스템도 수없이 많지만, 잘 동작한다. 이러한 시스템들은 대체로 운영보다는 배포, 유지보수, 계속되는 개발 과정에서 어려움을 겪는다.

아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다. 좋은 아키텍처는 시스템에 대한 이해와 개발, 유지보수, 배포를 쉽게 해준다. 아키텍처의 궁극적인 목표는 시스템의 수명에 쓰이는 비용은 최소화하고 프로그래머의 생산성은 최대화하는 데 있다.

개발

시스템 아키텍처는 개발팀들이 시스템을 쉽게 개발할 수 있도록 뒷받침해야만 한다. 팀 구조가 다르면 아키텍처 관련 결정도 달라지게 된다.

작은 팀에서는 개발 초기에 아키텍처 관련 제약들이 오히려 방해가 된다고 여길 수도 있다. 수 많은 시스템에서 좋은 아키텍처가 결여된 이유가 이 때문이다.

배포

배포 비용이 높을수록 시스템의 유용성은 떨어진다. 따라서 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데 그 목표를 두어야 한다.

안타깝지만 초기 개발 단계에서는 배포 전략을 거의 고려하지 않는다. 그래서 개발은 쉬울지 몰라도 배포하기는 어려운 아키텍처가 만들어진다.

개발 초기 단계에서 MSA(Micro Service Architecture)를 사용하자고 결정할 수도 있다. 컴포넌트 간의 경계가 뚜렷해져서 개발이 쉬워질 것이라고 판단했을지 모른다. 그러나 배포 시기가 되면 수많은 마이크로서비스를 연결하기 위해 설정하고 작동 순서를 결정하는 과정에서 오작동이 발생할 가능성이 생기게 된다.

운영

아키텍처가 시스템 운영에 미치는 영향은 개발, 배포, 유지보수보다는 적은 편이다. 운영에서 겪는 대다수의 어려움은 시스템에 영향을 주지 않고 단순히 하드웨어를 더 투입해서 해결할 수 있다.

하드웨어는 값싸고 인력은 비싸다는 말은 운영을 방해하는 아키텍처가 개발, 배포, 유지보수를 방해하는 아키텍처보다는 비용이 덜 든다는 뜻이다.

유지보수

유지보수는 소프트웨어 시스템에서 가장 비용이 많이 드는 부분이다. 유지보수의 가장 큰 비용은 탐사와 이로 인한 위험부담에 있다.

변경사항을 반영할 때 의도치 않은 결함이 발생할 가능성은 항상 존재하며, 이로 인한 위험부담 비용이 추가된다. 주의를 기울여 신중하게 아키텍처를 만들면 이 비용을 크게 줄일 수 있다.

선택사항 열어 두기

소프트웨어는 두 가치 가치를 지닌다. 구조적 가치는 행위적 가치보다 더 중요하다. 소프트웨어를 부드럽게 만드는 것은 구조적 가치에서 온다.

소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 많이, 오랫동안 열어두는 것이다. 이 선택사항은 중요하지 않은 세부사항을 말한다.

모든 소프트웨어 시스템은 정책과 세부사항으로 나눌 수 있다. 정책은 업무 규칙과 업무 절차를 구체화한다. 시스템의 본질적인 가치가 존재하는 곳이다. 세부사항은 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소지만 정책이 가진 행위에 영향을 주지 않는다.

아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 두고, 세부사항은 정책과 무관하게 만들 수 있는 형태의 시스템을 구축하는 데 있다. 세부사항에 몰두하지 않은 채 고수준의 정책을 만들 수 있다면, 이러한 세부사항에 대한 결정을 오랫동안 미루거나 연기할 수 있다.

결론

좋은 아키텍트는 세부사항을 정책으로부터 신중하게 가려내고, 정책과 세부사항이 결합되지 않도록 엄격하게 분리한다. 정책은 세부사항에 대해 알지 못하며, 어떤 경우에도 세부사항에 의존하지 않아야 한다. 세부사항에 대한 결정을 가능한 오랫동안 미룰 수 있는 방향으로 정책을 설계해야 한다.