소프트웨어 설계에서 파동의 응용
한국의 마틴 파울러가 되기
트위터에서 눈에 뜨인 Chris Richardson의 글을 캡처해 두었습니다. chains of synchronous calls는 클라이언트 서버 기반의 프로그램 방식에서는 일반적인 패턴이지만, 마이크로 서비스 아키텍처의 이점을 상쇄시키는 안티패턴이 될 수 있기 때문이죠.
소프트웨어 설계에서 파동의 응용
그런데, 그가 소개한 링크의 페이지에 갔더니 내용보다는 <입자와 파동의 이중성을 소프트웨어 설계에 응용하기>가 가능하다는 생각이 들었습니다. 게다가 <소프트웨어 설계에서 입자의 응용>은 다뤘지만, 아직 파동에 대해서는 뚜렷한 아이디어가 없는데 이번 참에 자연스럽게 시작할 수 있을 듯합니다.
그는 먼저 안티패턴이라 할 수 있는 RPC 방식을 소개합니다. 디테일로 REST이나 gRPC처럼 구체적인 RPC 프로코톨에 대한 내용도 있지만 일단 글에서는 클라이언트 앞쪽에서 중개 역할을 하는 서비스가 대기 시간이 길어질 수 있다는 점 때문에 마이크로 서비스 아키텍처를 채택할 때는 피하라고 하는 것입니다.
이와 같은 서비스 사이의 호출 관계를 파동에 비유하면, 그 형태를 바꾸는 것이 의도한 효과를 내는데 적합하다는 제안으로 읽을 수 있습니다. 물론, Chris Richardson이 파동에 대해 이야기하는 것은 아닙니다. 제가 입자와 파동 이중성을 설계에 적용하고 싶어 그 틀로 설명할 뿐입니다.
파동에 대한 배경 지식이 부족해서 응용에 한계가 느껴집니다.
유레카처럼 찾은 설명 방법
최근에 읽은 <듣기의 말들> 89쪽에 이런 표현이 있습니다.
소리는 대기를 통해 자유롭게 이동하며 형태가 없어서 온전히 제어하거나 억압하기 어렵다
사실 제 아이디어와 아무 관련이 없는 글이긴 합니다. 그런데, 설명을 쉽게 할 준비가 안 되었지만 지금 수준에서 꼭 이 글을 설명하겠다고 마음먹고 난 후에 갑자기 관련성이 있다고 느껴졌습니다.
앞선 그림을 다시 보며 설명하겠습니다. 파동이라면 사방으로 퍼지니까 순차적으로 처리할 이유가 없습니다. Chris Richardson이 chains of synchronous calls이라는 형태로 OrderService가 대기하면서 중재하는 부담을 져야 할 이유가 전혀 없습니다. 레스토랑 웨이터도 아니니까 말이죠.
이를 해소하여 퍼트리는 방식을 바로 '파동'으로 은유할 수 있습니다. 소리가 퍼져나가듯이 경계를 허물고 전달될 수 있습니다.
하지만, 구현을 하려면 파동의 형태가 무엇이냐를 생각할 필요가 있습니다. 구현하려면 어찌 되었든 모양을 만들어야 하니까요.
이벤트는 변경을 알리는 표준 프로그래밍 단위
여기에 대해서는 이미 영감을 기록해 둔 글이 있었습니다. 바로 Vaughn Vernon의 링크드인 글에서 영감을 받아 쓴 <이벤트는 변경을 알리는 표준 프로그래밍 단위>입니다.
파동을 구현할 빌딩블록이 바로 이벤트입니다.
그리고 파동을 전달받은 컨슈머 프로그램들이 여기에 적절하게 반응하면 됩니다.
Consumers should translate events to commands to react to the events.
지난 한국의 마틴 파울러가 되기 연재
2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기
4. 기술 부채를 Code Smell로 관리할 수 있는가?
6. 설계 요소의 사분면
7. 입자와 파동의 이중성을 소프트웨어 설계에 응용하기
