결국 메리는 FTGO 애플리케이션을 마이크로서비스 아키텍처로 전환하기로 했습니다.

소프트웨어 아키텍처는 기능 요건과는 거의 무관합니다. 애플리케이션 기능 요건(functional requirement), 즉 유스 케이스(use case, 용례)는 어느 아키텍처든 구현할 수 있습니다. 실제 FTGO처럼 성공한 애플리케이션이 진흙잡탕이 되어 버리는 경우가 의외로 많습니다.

그러나 아키텍처는 ‘~성(-ilities)’으로 끝나는 갖가지 서비스 품질 요건(비기능 요건(nonfunctional requirement))에 적잖이 영향을 미칩니다. FTGO 애플리케이션은 점점 몸집이 커지면서 여러 가지 품질 속성이 악화되었고, 그중 소프트웨어 전달 속도(관리성(maintainability, 유지보수성), 확장성(extensibility), 테스트성(testability))가 가장 큰 영향을 받았습니다.

평소 훈련이 잘된 팀은 팀원들이 열심히 노력하면 애플리케이션 모듈성을 유지하고 종합적인 자동화 테스트를 작성해서 모놀리식 지옥에 빠지는 속도를 늦출 수 있습니다. 하지만 규모가 큰 팀에서 여러 사람이 모놀리식 애플리케이션 하나에 달라붙어 작업할 때 일어나는 문제들은 불가피하고, 점점 더 쓰지 않는 기술 스택이 쌓여 가는 문제도 어쩔 도리가 없습니다. 팀 차원에서 필연적인 결과를 조금 늦추는 일 외에는 할 수 있는 것이 없죠. 모놀리식 지옥에서 벗어나려면 반드시 마이크로서비스라는 새 아키텍처로 갈아타야 합니다.

요즘은 크고 복잡한 애플리케이션을 구축할 때 마이크로서비스 아키텍처를 당연히 고려하는 추세입니다. 그럼 대체 마이크로서비스란 무엇일까요? (마이크로(micro)서비스라는) 명칭 자체는 크기만 부각되어서 이해하는 데 별로 도움이 되지 않고, 실제로 사람마다 의견이 천차만별입니다. 글자 그대로 아주 작은(예: 코드 줄 수가 100 미만) 서비스라는 사람도 있고, 개발하는 데 2주 정도 걸리는 서비스라고 하는 이도 있습니다. 과거 넷플릭스에 근무했던 애드리안 콕크로프트(Adrian Cockcroft)는 마이크로서비스 아키텍처를 경계 컨텍스트(bounded context)가 있는, 느슨하게 결합된 엘리먼트(element)로 구성된 서비스 지향 아키텍처라고 정의합니다. 괜찮은 표현이지만 조금 난해하게 들립니다. 더 명쾌한 정의는 없을까요?