실용적인 포트와 어댑터 적용
MSA 기술과 적용 연구 3
그렇다. 한 단어로 된 말이 입에 잘 붙는다. 게다가, 영어 사용자라면 육각이란 형상이 기억하기도 쉽겠지.
헥사고널 vs. 포트와 어댑터
지난 글에 인용한 위키피디아 정의에도 그렇고, 이를 고안한 Alistair Cockburn의 글에도 둘을 같은 말(Alternative name)로 규정한다.
입에 잘 붙기는 하지만, 반면에 실용적 측면에서 육각이란 형태 자체는 큰 의미가 없다. 의미상으로는 핵심을 이루는 응용 프로그램들의 분류가 중요한데, 그게 6과는 별 의미가 없다. 원저자인 콕번이 그린 예시도 4개 유형으로 묶지 않았나? 아마 내가 지금 당장 실무를 한다고 하면, 저 4개 분류를 바로 써먹을 만하다. '우리에게 4자기 요소가 뭐가 있지?' 이렇게 생각하는데 몇 초 걸리지 않으니까 말이다. 하지만, 육각은 별 의미가 없다.
그런 탓에 포트와 어댑터라는 의미가 명확한 또 다른 이름이 필요하다. 포트와 어탭터는 핵심 응용을 이루는 코드가 외부 인터페이스 관심사에 의해 직접 영향을 받도록 느슨한 연결(loosely coupling) 구현하는 핵심 구성 요소다. 써먹기 위해서는 포트와 어댑터가 무엇인지 알아야 하는데, 라인엔지니어링의 유팔복님 글에 잘 나와 있다. 코드 예제까지 포함해서 명쾌하게 이해할 수 있는 글이다. :)
여기까지는 알려져 있는 사실에 대한 소개다. 이번에는 이러한 패턴을 왜 써야 하는가 혹은 내가 만드는 응용 프로그램에 필요한가 하는 질문을 던져보자.
응용 프로그램은 빠르게 고칠 수 있어야 한다
응용 프로그램이라고 하면, 결국 사용자에게 쓸모를 제공해야 한다. 사용자가 다수가 되어야 하는 가정이 있다면 결국 빨리 피드백을 받아 바르게 수정하는 프로그램이 승리한다. 근데, 언제까지 승리해야 하는가? 답은 없다. Kent Beck이 소프트웨어 개발에 있어서 완벽(perfect)이란 그저 진행형(verb)일 뿐이라고 말한 것과 같은 이치다.
In software development, “perfect” is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories.
빠른 비즈니스 전개를 위한 설계 방안
이전 글에서 마이크로 서비스(MSA) 도입의 이유로 빠른 비즈니스 전개를 말했다. 나는 XP의 빅팬이기도 한데, XP는 빠른 비즈니스 전개에도 매우 유익하다. XP에서 설계는 주기적이고 지속하는 작업이다. 한때, 먼저 하느냐 나중에 하느냐 논쟁이 많았지만, XP 입장에서는 별 의미없는 사소한 결정이다.
왜냐하면, 설계는 항상 해야 하는 일이다. XP에서도 그렇고, 내 상식에 따라도 그렇고, 내 습관도 그렇다.
그렇기 때문에 언제 하느냐가 중요하지 않고, 소프트웨어를 설계 요소를 최대한 단순하게 유지하는 노력을 기울여야 한다. (조금 어려운 말일 수 있다. 코드를 단순하게 하자는 말은 난해하여 설계 요소로 수정한다.)
비즈니스 전개 속도, XP, 그리고 헥사고널
이쯤에서 제가 위에 열거한 이슈들 즉, 헥사고널(혹은 포트와 어댑터)과 비즈니스 전개 속도 그리고 XP의 설계 방식이 무슨 관련인가 의문을 갖는 분들이 있을 것이다. 그렇다면 성공이다. :)
자, 독자들에게 인내심을 갖고 나머지 글을 읽어주시길 제안한다. (말 재주가 별로인지라) 일단 Alistair Cockburn 이 자신의 책으로 헥사고널 패턴을 소개한 시점은 2005년이고, 라인의 글은 2020년이다. 15년의 긴 세월이 존재한다. 이걸 어떻게 해석해야 할까? 다시 그림을 보자. Alistair Cockburn 의 그림이다. 아이콘으로 묘사한 다시 말해 매우 추상적인(또는 모호한) 쓰임새를 담은 그림이다.
이번에는 라인엔지니어링의 유팔복님 그림을 보자. 웹 기반의 분산 환경을 전제하고 있다. 15년 사이에 이 패턴이 바다를 건너 우리나라에서 유용하게 쓰이는 이유가 한 가지는 아니겠지만 분산 환경을 확산을 중요한 요인으로 들 수 있다.
MSA 도입보다 안전한 이름은 분산 환경 도입
거의 같은 말이라고 할 수 있지만, 마이크로 서비스 아키텍처 도입보다는 분산 환경 도입이 조금 더 안전하다. 왜냐하면, 위 그림에서 Domain 혹은 Application 이라고 부르는 영역은 하나로 하고 포트와 어댑터 도입만으로도 충분히 훌륭한 분산 프로그래밍 환경을 만들 수 있고, 비즈니스 전개 속도 향상을 기대할 수 있기 때문이다.
비즈니스 효과도 불분명한데, 전보다 개발하는 속도가 늦어진다면 헛 일이다.
발빠른 AWS의 영업
AWS 한국 블로그에서는 발 빠르게 Developing evolutionary architecture with AWS Lambda 라는 글을 번역해서 올렸다. 자사의 서비스인 Lambda가 포트와 어댑터 패턴에 어떻게 쓰일 수 있나 하는 질문을 던져 만들어낸 생산적(돈도 벌고)이고 유익한(많이 찾을) 글이다.
우리회사 CTO님 말씀이 Lambda 쓸 때, 과금을 주의해야 하는 부분이 있었는데 정확히 어떤 내용인지 기억이 나지는 않는다.
암튼, 포트와 어댑터 패턴에 흥미가 가는 개발자라면 스스로 이렇게 물어볼 일이다.
포트와 어댑터 패턴을 써서 우리 서비스에 어떤 비즈니스 효과를 줄 수 있지?
