아키텍처는 의사소통에 관한 문제라서?
도메인 모델링 세미나 4
지난 글에서 Vaughn Vernon의 링크드인 최근 글을 화두로 던지며 <아키텍처는 의사소통에 관한 문제다>를 쓴 일이 있다. 소프트웨어 개발에 있어서 의사소통은 알면 알수록 다양한 영향을 미친다는 사실을 알 수 있다.
오케스트라 지휘자와 같은 코드를 그냥 두지 말자
Vaughn Vernon의 또 다른 링크드인 글과 이미지는 여러가지 자극을 촉발했다. 우선 그는 Smart Client를 지휘자에 비유했다. 사실 API는 프로그램 사이에서 벌어지는 일종의 서비스이다. 잘 만들어진 API는 클라이언트 코드를 짜는 개발자에게 짜릿함과 편리함을 제공한다. 반면 Client(API를 사용하는 코드를 말한다)가 Smart 하다는 의미는 결코 좋은 의미가 아니다.
특히 다수 API를 지휘(?)하는 정도로 Smart 코드라면 다수의 조건과 규칙을 보관하고 있을 가능성이 높다. 이런 코드는 난이도가 높고 아무나 수정할 수 없게 된다. 이렇게 되면 자연스럽게 수정을 꺼리게 되고, 비즈니스 속도에 영향을 끼칠 수 있다.
분산 API 혹은 REST 형태가 널리 쓰이기 전에도 비슷한 일은 있었다. 일종의 Fat Client 는 존재했다. 자바 진영에서는 Spring을 도입한 이후에는 그렇게 구현하기가 도리어 어려워졌지만, 10 여년 전에 나는 2만 줄이 넘는 주문 코드를 본 일이 있다. 주문과 주문과 연관한 규칙들을 지휘하는 코드들이었다. (놀라운 사실은 아직 그 코드가 그렇게 거대한 덩어리로 살아 있을 가능성이 높다는 점이다.)
서비스 오케스트레이션을 외치던 벤더들
IBM과 같은 대형 IT 벤더들이 분산 서비스를 주장하던 시절이 있었다. 그때 기술 이름이 SOA(Service Oriented Architecture)였다. 개념은 합리적이었지만, 결국 자사의 복잡한 솔루션을 사는 것을 배경에 깔고 있었다. 돌아보면 흑역사일 수도 있지만, 벤더 주도로 기업용 시스템을 끌고 가고 싶은 자연스러운 도전이었는지도 모른다.
적절한 분량으로 나눠진 코드의 체계적인 조직
소프트웨어 설계 원칙 중에 단일 책임 원칙(Single-responsibility principle)이라는 것이 있다.
The single-responsibility principle (SRP) is a computer-programming principle that states that every module, class or function in a computer program should have responsibility over a single part of that program's functionality, and it should encapsulate that part. All of that module, class or function's services should be narrowly aligned with that responsibility.
하나의 책임을 갖는 것으로 배분된 코드 단위로 만들어진 시스템은 질서를 만들어내고 직관적인 이해를 돕는다. 더불어 이런 코드로 이뤄진 코드를 다룬다면 업무 배분을 하기에도 좋을 것이다. 하지만, 현실에서는 그렇게 하지 못하는 경우가 많다. 다음 주에 어느 개발팀 자문을 하러 가는데 업무 분담 기준에 대한 논의를 할 예정이다. 그때 공감을 얻기 위해 이런 이야기를 해야 될 지도 모르겠다.
아키텍처가 의사소통에 대한 문제라는 말을 떠올렸던 이유를 여기서 말할 수 있다. 업무 배분을 위한 기준이 투영하는 일도 아키텍처와 관련한 일이다. 그리고, 적절하게 책임을 나눠 수정이 수월한 분량으로 코드를 조직화 하는 일 역시 아키텍처에 범주에 넣을 수 있다.
