시스템 모델링을 할 때 빠지지 않고 그리게 되는 그림이 몇 있는데, 그중 하나가 Sequence Diagram입니다. 이 Diagram은 특정한 결과를 반환해야 하는 이벤트의 시퀀스를 정의하는 데 사용하죠. 우선 특정 객체를 나열하고 그 아래 대시 라인을 수직으로 그리게 되는데, 이를 Lifeline(클래스의 인스턴스)이라 하며 시간의 흐름을 나타내는 축으로 사용합니다. 그리고, 수평으로 메시지가 전달되는 모습을 화살표로 그려주게 됩니다.
잘 그려진 여러 다이어그램은 전혀 시스템을 모르는 개발자라 할 지라도, 전체 시스템의 구조 및 의존관계를 쉽게 이해하고 작업에 들어갈 수 있게 해 준다는 장점이 있습니다. 그럼에도 큰 시스템이라면 기능들이나 이벤트의 다이어그램들을 모두 작성하는 건 큰 부담이 되죠. 어쨌든, 옛날에는 설계와 개발을 명확히 분리하여 작업하는 경우가 많았기 때문에, 정확한 커뮤니케이션을 위해 UML Unified Modeling Language을 사용했습니다. 하지만, 요즘은 여러 작업자들이 같은 자리에서 긴밀하게 협업을 하며 빠른 속도로 개발을 해내는 Agile 방법론이 유행하다 보니, 많이 사용하지는 않게 되는 것 같네요. (물론 장단점은 분명히 있으니, 진행하게 될 프로젝트의 성격이나 주변의 상황에 따라 적절히 기법들을 tailoring 해서 방법론을 정의해야겠죠.)
사실 UML이나 방법론보다는, 어떤 기능을 구현하려는데 여러 면에서 매끄럽지 않을 때, 혹은 어떤 문제점을 해결해야 할 때, Sequence Diagram을 꽤 유용하게 사용할 수 있다는 이야기를 하고 싶었습니다. 보통 그런 작업을 할 때는 개발자와 조력자들이 함께 논의를 하게 되는데, 서로 정보나 지식의 간극이 존재하기 때문에 말만으로는 상황을 파악하는데 생각보다 많은 시간이 걸리거든요. 똑똑한 사람들끼리 붙여놔도 생각보다 자주 그런 상황이 발생한다니까요? 그럴 때 이 Sequence Diagram을 사용하게 되면 서로 상황을 파악하고 문제를 해결하는데 꽤 도움이 됩니다.
얼마 전 채팅 서비스 플랫폼 안에서 동일 회사에서 제공하는 인증서비스를 사용하는 기능을 구현하려 했던 적이 있었습니다. 그런데, 만족할만한 사용자 경험이 안 나오는 겁니다. 그래서, 개발자의 설명을 들으며 다른 방법들을 찾아보려 했는데, 인증 관련 프로세스가 상당히 복잡해서 대충 이해해서는 문제 해결이 불가능하겠더라고요. 그때 개발자와 같이 Sequence Diagram을 먼저 같이 그렸죠. 개발자라고 하더라도 – A부터 Z까지 모든 부분을 혼자 개발하게 되는 경우는 드물기 때문에 – 구조를 잘못 이해하고 있는 경우가 종종 있어요. 같이 하나하나 Lifeline 위에 메시지 선을 그리다 보면, 그런 부분들이 정리되면서 현 상황을 완벽하게 파악하는 것이 가능해집니다. 여기서 가장 중요한 것은 작업을 진행하다가 뭔가 애매한 경우에는 반드시 그것을 해소해야 한다는 거예요. 보통은 클래스(혹은 서브시스템)를 분리하여 별도의 Lifeline을 만들게 되는데, 조금 전 이야기했던 인증 서비스를 예로 들어 보겠습니다.
처음에는 고객이 사용하게 되는 채팅 플랫폼으로 하나의 Lifeline을 만드는 게 전혀 이상하지 않습니다. 하지만 서브시스템 간의 메시지 선을 그리다 보니, 메시지 전달에 논리적인 문제가 생기게 되는 거예요. 그 이유는 채팅 플랫폼 안에서 대화 스레드 영역과 인앱 브라우저가 서로 배타적으로 작동하기 때문이었습니다. 그런 경우에는 채팅 플랫폼을 다시 대화 영역과 인앱 브라우저로 구분하여 서로 다른 Lifeline을 가지도록 조정하면 보다 완벽하게 구조를 그려낼 수 있게 됩니다.(인증 같은 경우에는 메시지(인증 정보)의 전달과, 어떤 서브시스템이 해당 정보를 알고 있는지가 중요하니까요.)
하지만, Sequence Diagram도 해결해줄 수 없는 영역이 있는데, 바로 이해가 된 상태에서 해법을 찾는 부분이 그것입니다. 제한된 구조 안에서 새로운 가치를 만들어내기 위해서는 역시 창의적인 발상이 필요할 테니 말이죠. 어떤 경우에는 ‘이 문제를 해결할 수 있는 방법이 없다’는 것을 명확하게 이해하게 되는 경우도 있다니까요? 그게 도움이 된 건지는 모르겠지만…
