brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Apr 02. 2024

관리 요소 식별을 위한 조기 시각화의 필요성

베터코드 인사이트의 부활

동료와 함께 결정한 빠른 출시는 효과가 분명하다는 생각이 듭니다. 아직은 사용자가 호불호를 말할 단계는 아니지만, 그런 시점에서도 출시를 하면 배울 수 있는 점이 있습니다. 가장 중요한 것은 물론 쓰임 자체와 쓰임새로 드러나는 사회적 가치이지만, 이 글은 다른 관점의 효과에 대해 쓰고자 합니다.

인스턴스의 전용 공유(dedicated share)

같은 기능을 조금은 다른 용처에 그대로 노출했습니다. 멀티 태넌시(Multitenancy)를 도입하는 꼴이 되는 것이죠. 위키피디아 정의를 볼까요?

다음 단락까지 계속 DeepL해서 훑어봅니다. 눈에 띄는 표현이 있습니다. 바로 인스턴스의 전용 공유인데요. 전용dedicated과 공유share라는 얼핏 보면 상호모순적인 개념이 합쳐진 말입니다. 무슨 뜻일까요?

위키피디아에서 인스턴스instance의 뜻도 찾아봅니다. 설명에서 컨택스트라고 하는 것은 개발자가 작성한 프로그램과 관련 데이터를 논리적인 묶음으로 설정한 단위입니다. 그렇게 보면, 인스턴스란 개발자가 한 덩어리라고 설정한 내용을 메모리 상에 올려서 실행할 수 있게 한 것이라 할 수 있습니다.

구조 문제를 시각화하기

프로그래머 입장에서는 코드 저장소의 결과물이 인스턴스를 만들 때 이를 가능하게 하는 것입니다. 코드 작성 방식의 문제이기 때문에 기본적으로 정해진 틀이 아닙니다. 정해진 것이 없기 때문에 눈에 보이게 하기 위해 시각화를 합니다.

문제를 영역으로 표기만 합니다. 구체적인 형상은 개발자가 결정해야 하기 때문에 대화를 통해 서로의 인식을 맞춰야 합니다. 그림은 대화를 하기 위한 준비로 마치 효과적인 회의를 위해 의제agenda를 준비하는 일과 비슷합니다.

하나일 때는 보이지 않던 요소가 보이기 시작한다

자, 이제 멀티 태넌시가 무엇인지 이야기는 이 정도로 하고, 초기부터 이를 도입해서 얻는 이점을 말할 차례입니다. 인스턴스 즉 사용처가 하나일 때는 보이지 않았던 '목록'의 의미가 보다 분명해지는 것이죠. 다음은 <관성적 일상에서 나와 차리는 일상으로 바꾸기> 내용을 일부입니다. 이때는 해당 기능을 하나의 태넌트만을 대상으로 노출했습니다.

보이기 시작하는 요소를 시각화하기

마치 삼각측량처럼 하나만 볼 때는 명확하지 않던 요인들이 보입니다. 가령, '목록'은 '썩 마음에 들지 않는다'는 느낌은 있지만, 그래서 취할 수 있는 행동이 분명하지 않았습니다. 새롭게 드러나는 부분은 제 머릿속에서 그려진 것이기 때문에 동료들도 볼 수 있도록 그림을 표현합니다.

먼저, 목록list이란 이름은 View에서는 사용자에게 번거로움(페이징이라 스크롤)만 제공하는 관행입니다. 그래서 이는 사용자의 작동 방식을 실제로 관찰하면서 새롭게 정의하기로 합니다. 그럼에도 불구하고 list가 존재했던 이유는 있겠죠. 그래서, View 영역이란 것을 그리고 그 바깥으로 표현해 보니 분명해집니다.

공통 기능을 만들어 제공할 때 하나의 표준화된 통로로 만들면 비용[1]이 적게 듭니다. 목록list이란 말은 정형화한 형태의 디지털 자산을 만들어 복수로 제공한다는 의미입니다.[2] 이렇게 사고하면 저장소(혹은 창고)에서 박스를 꺼내듯 데이터를 꺼낸다는 구조를 상상할 수 있습니다. 상상을 넘어서 설계하고 구현할 수도 있고요.

여기까지 그려 놓으면 앞서 '차이'를 어디에 넣을지 논의할 때에도 활용할 수 있겠네요.

화면을 보고 쓰임새를 확인하기

이제 화면 혹은 View 관점에서 보겠습니다. 두 번째 쓰임새(혹은 태넌트)는 첫 번째와는 많이 달랐습니다. 시작부터 발행한 모든 글을 보던 방식(태넌트 A)과는 다르게 상당 기간 협업이 필요해서 탭도 기본이 '임시 글'이어야 합니다.

그런데, 의미도 '임시 글'이라고 볼 수 없습니다. 이번에 번역을 하면서 쓰임새를 재확인한 이단 편집 형태의 편집 도구를 제공해야 합니다.

여기에 더해져야 할 추가적인 기능과 경험을 다루는 것은 글의 범위를 벗어납니다. 여기서는 목록list을 공통 기능과 View를 연결하는 통로로 옮긴 후에 논리적 균열이 발생하지 않기 위해 어떤 변화가 있어야 하는지를 다루는 것으로 마칩니다.

관리 요소 식별을 위한 조기 시각화의 필요성

'임시 글'에서 수정한 화면이 '이단 편집'이라고 한다면 최근 수정 순서로 나열되는 일이 필요합니다. 더불어 복수의 작업자를 가정하기 때문에 협업을 지원하도록 대화가 붙어 있어야 하고, 수정 내역을 비교할 수 있어야 합니다.

멀티 태넌시는 '인스턴스의 전용 공유'를 비교적 낮은 비용으로 공급하는 일로 경쟁력을 가질 수 있습니다. 그래서 이러한 부분들을 시각화해서 개발자뿐 아니라 제품이나 비용 의사결정에 참여하는 사람들 사이의 정교한 소통을 할 수 있어야 한다고 생각합니다. 이를 위해서 초기부터 멀티 태넌시를 노출하고 시각화하여 관리 대상을 분명하게 해야 개발자만의 외로운 싸움 혹은 개발자와 다른 관계자의 간격이 벌어져서 생기는 문제를 막을 수 있다고 생각합니다.