시작하면서…

소프트웨어 아키텍처는 굉장히 핫한 주제입니다. 개발 블로그 포스팅으로 쉽게 찾아볼 수 있고, 소프트웨어 컨퍼런스에서 한 두 개씩은 꼭 나오는 단골 주제이기도 합니다. 개발자 채용 면접에서도 연차가 올라갈 수록 필요성이 올라가는 아주 중요한 주제라고 할 수 있죠. 그렇다면 저는 왜 ‘아키텍처를 경계하라’라는 제목을 달고 글을 쓰게 되었을까요?

아키텍처는 왜 중요한가?

소프트웨어의 철학이자 뼈대

아키텍처는 곧 그 소프트웨어의 철학이자 뼈대입니다. 소프트웨어를 새롭게 이해하고자 하는 개발자, 개발하고 있는 개발자 모두에게 아키텍처는 가이드 역할을 합니다. 기능을 어떻게 추가할 것인가? 어떤 방법을 쓸 것인가? 등 소프트웨어 개발의 갈림길에서 배가 산으로 가지 않게 막아주며 장기적으로 일관적이고 높은 품질의 소프트웨어를 개발할 수 있게 합니다.

우아함, 아름다움

잘 구조화된 아키텍처가 있는 코드는 우아하고 아름답습니다. 보기만 해도 심신이 안정되고 나도 굉장한 코드를 만들어낼 수 있을 것 같은 기분이 듭니다. 같은 코드를 작성한다고 하더라도, 좋은 아키텍처 안에서 작성하는 것이 그렇지 않을 때보다 더 의욕과 장인 정신이 생깁니다.

아키텍처의 문제

당신도 모르는 사이에, 아키텍처가 당신을 통제할지도 모른다.

아키텍처가 당신을 통제하는 방법

분명 아키텍처는 개발자가 만들어낸 것이 맞지만, 개발자를 보이지 않게 통제하기도 합니다. 가장 흔하게 쓰이는 4계층 아키텍처를 생각해봅시다. 4계층 아키텍처의 애플리케이션 계층에서 개발자는 비즈니스 로직에 집중하게 되며, 이 때 아키텍처는 데이터베이스에 실제로 보낼 쿼리, 네트워크 연결 작업 등을 개발자의 시선에서 ‘치워버립니다’. 이렇게 함으로써 개발자는 현실의 문제를 가져오는 데에 좀 더 집중할 수 있지만, 다른 가능성 있는 해결 방법을 떠올리기 어렵게 만듭니다.

예시

4계층 아키텍처를 통해서 API를 개발하는 예시를 하나 들어보겠습니다. Python 함수에 로직을 작성할 수도 있고 데이터베이스에 프로시져 혹은 함수를 정의해서 문제를 해결할 수 있습니다. 4계층 아키텍처의 관점에서 후자는 좀 불편하게 보일 수 있습니다. 데이터베이스에 의존한다는 점에서 소프트웨어의 유연성을 해치고 비즈니스 로직의 위치가 분산되어 코드 가독성을 해칠 우려가 있기 때문입니다. 하지만 데이터베이스를 변경할 일이 정말 생길까요? 작성한 SQL과 함수에 주석을 잘 작성한다면 가독성을 그렇게 해치지 않는 것 아닐까요? 이런 관점에서 전혀 문제가 아닐 수 있습니다. 오히려 네트워크를 통한 데이터 이동이 줄어들며 퍼포먼스 개선을 기대해 볼 수 있습니다.

정말 필요한가? 아키텍처가 목적은 아닌가?

아키텍처를 잘 아는 개발자가 좋은 개발자를 의미하지는 않는다.

컴퓨터공학의 핵심은 추상화이고, 아키텍처는 그 핵심 정수입니다. 소프트웨어 아키텍처를 가지고 씨름하는 일은 추상화의 정수라는 점에서 수준 높은 개발자의 소양인 것처럼 보입니다. ‘코더’가 아닌 ‘소프트웨어 개발자’가 되기 위한 필수 역량인 것처럼 보이죠. 실제로 그것이 틀린 말은 아니지만, 아키텍처가 모든 것을 해결해주진 않습니다. Facade가 무엇인지, CQRS가 무엇인지 잘 안다고 해서 훌륭해보이는 개발자가 될 수 있을지언정 반드시 훌륭한 개발자가 될 수 는 없습니다.

좋아보이는 신기술, 좋은 아키텍처에 매달려 있지는 않았나?

능력있어보이는 스마트한 개발자로 보이기 위해서 아키텍처를 선택한 것은 아닐까요? 신기술을 학습하고 적용하는 것도 좋은 일이지만 실제 적용했을 때 반드시 유의미한 성과를 보인다는 보장은 없습니다.

중요한 것은 어떤 것을 사용해야할지 판단하는 것

아무런 아키텍처가 없는 단순한 스크립트에 가까운 코드도 얼마나 사용할 코드인지, 작업에 쓸 수 있는 시간은 얼마나 되는지에 따라서 명백한 정답이 될 수 있습니다. 거기에 더해 누가 사용할 아키텍처인지, 모든 팀원이 납득할 수 있는 이유가 있는지도 중요한 문제입니다. 코드는 현실 세계와 별개로 존재하는 것이 아닙니다. 현실 세계의 문제와 연결되어 있고, 연결된 모든 것이 코드의 문제가 될 수 있습니다. 개발자에게 코드가 처한 현실 문제에 맞는 아키텍처가 무엇인지 판단하는 것이 가장 중요합니다.

아키텍처를 경계하라

아키텍처를 경계합시다. 아키텍처를 고민하면서, 문제의 해결책을 짜내는 일은 즐겁습니다. 하지만 동시에, 고민하고 있는 해결책이 문제에서 멀어지고 있을지도 모를 일이고, 문제가 정말 문제가 아닐지도 모를 일입니다. 정말 중요한 것은 소프트웨어를 설계하는 것이 아니라 그 전에 진짜 문제가 무엇인지 아는 것, 정말 선택한 아키텍처가 문제에 적합할지 고민하는 일입니다.

답은 언제나 문제에 있다.

문제가 무엇인지에 집중합시다. 추상화, 패러다임의 논리에 갖혀 문제에서 멀어지고 구현에만 파묻히는 것을 경계합시다. 해결하려는 문제가 무엇인지 정확하게 이해하는 일이야 말로 우리가 가장 중요하게 여겨야 할 일입니다.