한빛출판네트워크

ⓒnew-york-city-cityscape, freepik.com

아키텍트를 도시 설계자에 좀 더 비유하자면, 그의 구역zone은 어디일까?

아마 서비스 경계 또는 서비스의 대단위coarse-grained 그룹에 해당할 것이다. 아키텍트로서 우리는 구역 내의 일보다는 구역 사이에서 발생하는 일을 더 걱정해야 한다. 이것은 아키텍트가 서비스 간 통신 방법에 대해 고민하거나 시스템의 전반적인 상태를 적절히 모니터링하는 데 더 많은 시간을 할애해야 한다는 것을 의미한다.

구역 내 사안에 관여할 방법은 상당히 다양하다. 많은 조직이 팀의 자율성을 극대화하기 위해 마이크로서비스를 적용해왔다(10장에서 자세히 설명한다). 이 책을 읽는 독자가 그러한 조직에 몸담고 있다면 팀이 구역 내 사안에 대해 올바른 결정을 내릴 것이라고 더욱 신뢰할 것이다.

그러나 우리는 구역 간 또는 전통적인 아키텍처 다이어그램의 박스들 사이에서 주의를 기울여야 한다. 여기서 잘못되면 온갖 종류의 문제로 이어지고 해결하기도 매우 어려워질 수 있다.

서비스별로 팀들이 서로 다른 기술 스택과 데이터 저장소를 사용해도 문제없다 할 수 있지만, 여기서 다른 우려 상황이 발생할 수 있다. 지원이 필요한 10가지 기술 스택을 보유하고 있는 팀의 팀원을 고용하고 이동시키는 일이 더 어렵다는 사실을 고려하면, 업무에 적합한 도구에 대한 선택권을 팀에 허용하자는 주장은 다소 누그러질 수 있다. 마찬가지로 만약 각 팀이 서로 완전히 다른 저장소를 사용한다면 그것들을 대규모로 운용하는 데 충분한 경험이 부족하다는 것을 깨닫게 될 것이다. 예를 들어 넷플릭스는 데이터 저장 기술을 대부분 카산드라Cassandra로 통일했다. 비록 모든 경우에 적합한 최선의 대응책은 아닐지라도, 넷플릭스는 카산드라와 관련된 도구 및 전문지식을 통해 얻는 가치야말로 몇몇 특정 태스크에 더 적합할 수 있는 다수의 이종 플랫폼 확장을 지원하고 운영하는 것보다 더 중요하다고 생각했다. 넷플릭스는 확장성을 가장 중요한 요소로 생각하는 극단적인 사례일 수 있지만, 그들의 생각을 이해할 수는 있을 것이다.

하지만 서비스 사이는 얼마든지 엉망이 될 수 있다. 만약 한 서비스는 HTTP 상에서 REST를 노출하고, 다른 서비스는 프로토콜 버퍼(옮긴이 주_ 구글에서 개발한 구조화된 데이터를 직렬화하는 방법으로, 네트워크 통신과 데이터 저장에 사용된다. 데이터 구조(메시지)와 서비스를 proto 정의 파일에 정의하고 다양한 언어로 인코딩/디코딩하여 이기종간의 호환이 가능하다. 유사한 기술로는 아파치 쓰리프트와 아브로가 있다.)를, 또 다른 서비스는 자바 RMIRemote Method Invocation를 사용하기로 결정한다면, 호출하는 서비스가 의사소통을 위한 다양한 스타일을 이해하고 지원해야 하므로 통합 작업은 악몽이 될 수 있다. 이것이 필자가 다이어그램 박스들 간에 벌어지는 이벤트를 걱정하고, 내부에서의 일에 대해서는 자유로워야 한다는 지침에 집착하는 이유다.

코딩하는 아키텍트

 

아키텍트가 만들어내는 시스템을 개발자도 수용하기 원한다면 아키텍트는 그 같은 결정의 파급력을 이해할 수 있어야 한다. 이것은 적어도 아키텍트가 팀과 함께 시간을 보내고, 이상적으로는 팀과 함께 실제로 코딩하는 것을 의미한다. 짝 프로그래밍pair programming 연습을 위해서라도 아키텍트가 짝 프로그래밍의 일원으로서 짧은 기간 팀에 참여하는 작업은 그리 어려운 일이 아니다. 이상적으로, 팀의 정상 근무를 제대로 이해하려면 일반적인 스토리에 공을 들여야 한다. 아키텍트가 개발팀 옆에 앉는 것이 얼마나 중요한지 아무리 강조해도 지나치지 않다. 이것은 전화를 하거나 단순히 코드를 리뷰하는 것보다 훨씬 효과적이다.

아키텍트가 팀과 함께 작업하는 빈도는 협업 중인 팀의 규모에 크게 좌우된다. 여기서 요점은 이러한 활동이 일상적이어야 한다는 것이다. 예를 들어 4개 팀과 일하고 있는 아키텍트라면 4주에 한번씩 각 팀과 반나절을 보내는 과정에서 상호인식 및 팀과의 의사소통 능력을 향상시킬 수 있다.