brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Jul 20. 2021

시스템의 상태와 상태도 작성

실전 시스템 수준 리팩토링 사례 3회

화이트보드에 아래와 같은 그림을 그리고 개발팀 다수와 회의를 한 이후에 협업시스템(두레이)으로 대화를 시도했습니다. 이번에는 시스템의 상태 정의와 상태 표현을 다루기로 합니다. (지난 글에 이어 두레이를 또 언급했는데, 연재 중에 언젠가는 두레이와 같은 협업 시스템을 이용해서 비대면으로 소프트웨어 디자인을 개선하는 발전시키는 이야기도 다르기로 하겠습니다.)

프론트 개발자의 피드백

협업 시스템으로 질문을 받은 프론트 개발자가 다음과 같은 답을 달았습니다. 협업 시스템 사용 경험이 없는 분들은 그저 업무용 게시판으로 보셔도 크게 틀리지 않습니다.

다음으로 이해했는데 내용이 맞을까요?
1. 물품이 접수, 분류, 생산의 상태를 거친다.
2. 그 상태들을 결정하는 것이 촉발자의 역할이다.
3. 촉발자의 역할인 상태 결정을 돕는 행위가 User interface 이다.

이해한 내용이 맞다면 다음과 같은 답답함으로 질문과 생각이 정리가 되지 않습니다. 저는 현재 user 페이지만 작업을 해왔기에 `접수` 상태만 이해도가 있습니다. `분류`와 `생산` 상태의 작업은 admin 화면에서 이루어지는 일이라 생각하고 있습니다. 두 가지의 상태를 각각 책임지는 촉발자들의 역할(매장 매니저, 되살림터 간사 등)에 대한 정확한 이해(촉발자의 역할에 따라 보이는 화면, 사용 가능한 기능 등)가 없습니다. User interface에 대한 생각 또한 쉽게 떠오르지가 않습니다. ...

피드백은 의사소통의 핵심입니다. 개발자 필독서로 추천하고 싶은 XP 2판에서 소프트웨어 개발의 5가지 가치를 정의하고 있는데, 그중 세 번째 가치가 바로 피드백이기도 합니다. (이에 대해 더 알고 싶은 분들은 댓글 주시면, XP 독서 모임에 초대하겠습니다.)

피드백으로 받은 댓글을 보니 상태란 말이 모호하구나 싶었습니다. 제가 화이트보드에 쓴 그림에는 상태들을 묶어 놓고 기부라고 표기했는데, 프론트 개발자는 물품의 상태라고 썼습니다. 일단, 우리가 보다 정교하게 대화하기 위해서는 객체의 상태에 대해 비슷하게 바라보는 것이 좋다는 생각이 들었습니다. 이 글을 쓰는 동기죠. 하지만, 객체의 상태를 바로 다루기 이전에 상태의 흔한 쓰임과 시스템의 상태에 대해 살펴보겠습니다.

업무의 상태와 시스템의 상태

먼저, 제가 일상에서 쓰고 있는 협업 시스템에서 매일 볼 수 있는 상태의 예시가 떠올랐습니다. 바로 아래 화면입니다.

두레이에서는 하나의 업무를 생성해서 관리하고 대화를 담을 수 있습니다. 각 업무는 상태를 지닙니다. 위 그림에서 상태가 나타나는 부분은 두 곳입니다. 먼저 좌측 상단에 Done(완료) 이라고 표기된 부분이 있습니다. 이것은 나의 작업 상태입니다. 반면에 오른쪽 끝에 보시면 Doing(진행 중) 이라고 푸른색 기표와 함께 쓰인 문자가 보입니다. 제 작업 상태는 Done(완료) 인데 반해, Doing(진행 중) 인데 이건 협업 시스템 두레이가 만든 규칙입니다. 담당자가 여럿인 공동 작업인 경우 업무의 상태가 담당자 작업 상태의 결과에 따라 결정됩니다. 예를 들어 한 명이라도 To do(할일) 상태인 작업자가 있다면 업무 상태는 To do가 됩니다. 모두 Doing 이상 즉, Doing 이거나 Done만 있다고 한다면 업무 상태는 Doing이 되고 같은 이치로 모두 Done일 때만 업무 상태가 Done이 되죠.

간단한 예시로 연습을 했으니 이제 정의를 살펴보겠습니다. 위키피디아 정의를 먼저 살펴보겠습니다. 상태에 해당하는 state에 대한 정의는 분야별로 다양한데, 아래는 IT 분야의 정의입니다.

In information technology and computer science, a system is described as stateful if it is designed to remember preceding events or user interactions; the remembered information is called the state of the system.

필요한 부분만 추출해서 정의하면 상태(state)는 시스템에 저장된 정보를 지칭하는 말인데, (주로) 선행한 일(preceding events)이나 사용자 상호작용(user interactions)에 대한 기록이죠. 정의를 조금 더 실용적으로 바꿔볼까요?

우선 정보시스템이라는 이름으로 불리는 시스템의 경우, 관계형 데이터베이스에 엔티티(entity) 단위로 저장을 해둡니다. 특정 시점에서 지금까지 변경한 이력 전체를 관리할 때, 보통 시작점이 엔티티가 됩니다. 하지만, 엔티티 사이에서도 관계가 있어서 좀 더 체계적인 접근을 위한 빌딩 블록으로 Aggregate라는 단위를 정해서 쓰기도 합니다. 이 글을 위해 미리 알아야 할 배경지식이 늘어나는 것도 부담스러우니 일단 이렇게 정의하겠습니다.

여러분이 어떤 시스템을 쓸 때, 마지막 상태가 기억되기를 바라는 일이 흔히 있습니다. 페이스북에 마지막으로 좋아요 했던 내용이 사라지기 바라지 않는 것과 같이요. 이런 경우 시스템이 상태를 갖는다고 하죠.

상태도(State diagram)

사용자가 인식하는 시스템 상태는 단순해야 합니다. 직적에 예로 들었던 페이스북 사례처럼요. 그래야 직관적으로 사용할 수 있고, 사랑받는 시스템이 되겠죠.

반면에 시스템을 구성하고 만드는 사람들의 경우라면 전혀 다릅니다. 다양한 구성요소로 만들어진 시스템의 경우는 구성요소의 상태의 조합이 시스템의 상태를 결정합니다. 따라서, 제대로 작동하는 시스템을 만들기 위해서는 상태에 대한 이해가 필요합니다. 아래 그림과 같이 차량 정비할 때도 각 구성요소의 상태를 점검하듯이, 눈에 보이지 않는 소프트웨어도 상태를 확인하고 표현할 방법이 필요합니다.