모호함이라는 적진을 단박에 제압하는 모델의 힘

감히 시도하는 설계의 정석

Feb 9. 2026

사전이나 책에 있는 정의를 그대로 쓰지 않고 스스로 정의하는 일에는 상당한 용기가 필요한 듯합니다. 그럼에도 불구하고 제가 풀어내고 싶은 내용을 고스란히 담은 정의가 없어 '모델링'에 대한 정의 정의를 내려 보았습니다.

모델링이란 나의 관점에서 풀어낸 생각을 차려서 시각화하는 작업을 하고
이를 활용해 소프트웨어 개발에 필요한 소통과 협력을 이끌어 내는 일이다.

모델링은 주관적인 생각을 차려서 시각화하는 일이다

먼저 구체적인 예를 가지고 설명해 보겠습니다. 마침 운이 좋게 최근에 모델링 업무를 수행한 직후입니다.

한국 상품을 수출하는 기업에서 두 개 이상의 서로 다른 시스템을 연동하여 고객 주문의 후방 업무를 처리하는 시스템 구축 과정에서 '모델링'이 어떻게 쓰이는지를 설명하려고 합니다. 먼저 일을 맡긴 클라이언트(이하 '고객')와 업무 범위에 대해 협의는 하였으나 처음으로 연동하는 두 개 시스템과 정확하게 어떻게 붙이는지 그리고 이렇게 어떻게 업무가 연속성 있게 진행될지 모호한 영역이 있는 상황이었습니다. 그래서 전체적인 업무 진척을 한 화면에서 내려다 보듯이 파악할 수 있는 '대시보드'를 만들기로 했습니다.

나중에는 메뉴 이름이기도 하고 화면 이름이 될 수도 있지만 개발 과정의 바로 이 시점에서는 모호한 내용을 드러내고 고객과 개발자 이해의 공통 기반을 구축하거나 넓히는 일이 초점이자 목표입니다. 특히나 우리가 도메인 지식이라고 부르는 현장에서 통용되는 업무 지식은 특정 조직의 문화와 관습을 포함합니다. 따라서, 개발자가 그 조직에 이미 몸담고 있었던 상황이 아닌 경우는 해당 내용을 알지 못하거나 오해할 수 있습니다. 이는 부실한 로직이나 논리적 오류를 포함하는 프로그램 구현으로 이어질 수 있습니다.

한편, 개발자들이 프로그래밍을 위해 다뤄야 하는 구체적인 기술적 지식 그대로를 고객과 소통하는 일은 현실적으로 가능하지 않습니다. 더구나 흔히 '레거시'라고 불리우는 기존 시스템을 구성하는 프로그램 코드에는 기술적인 내용뿐 아니라 해당 조직의 문화와 관습에 바탕을 둔 알고리듬과 작명, 정책 따위가 뒤엉켜 있습니다.

이런 상황에서 고객과 개발자 사이에 효과적인 소통을 할 수 있다면 의미 있는 투자가 된다고 할 수 있습니다.

모호함을 대상으로 하는 전쟁에 유용한 모델링

모델링에 대한 저의 정의에서 먼저 모델러 주관의 표출 혹은 줏대를 드러내는 일의 중요성을 말하고 싶습니다. 사실 사회 초년부터 모델링을 해 왔던 터에 무의식적으로 익숙해진 기법이라 말로 설명할 필요도 없었고, 또 그런 요령과 모델링과 직접적인 연관성을 따져 본 일도 없습니다. 그런데, 거의 매번 개발 프로젝트 초기에 어려운 문제를 풀 때 저는 항상 '종심타격(縱深打擊)'을 선택하는 경향이 있습니다.

앞서 예로 든 대시보드에 대해 떠올린 일 역시 종심타격의 응용이라 할 수 있습니다. 전쟁 용어로 종심(縱深)은 후방 깊숙히 자리한 사령부를 뜻합니다. 고구려가 수나라나 당나라의 대군과 싸울 수 있는 힘을 거론할 때 철기병의 힘을 말하곤 합니다. 철갑을 두른 말을 타는 철기병 즉, 기동력과 전투력을 모두 갖춘 소수의 정예 병력이 적진을 관통해 사령관이 있는 막사까지 침투해서 우왕좌왕하게 할 수 있다면 절대적으로 유리하겠죠. 미군의 F-15 전투기의 효용성도 비슷하게 설명하는 사람들이 있습니다.

다만, 적국을 대상으로 한 전쟁이 아니라 복잡성이나 모호함과 대적하는 일에 응용하는 것이죠. 단 시간 내에 오랫동안 시장이나 조직의 관습을 파악하고 거기에 소프트웨어를 적용해서 과거에 불가능했던 것을 가능하게 하거나 사용자 편의성을 높이거나 작업의 효율을 높이기 위한 일을 해야 합니다. 이를 위해서는 해당 프로젝트의 목표를 눈에 보이게 하고, 그 목표가 시스템으로 어떻게 드러날지에 대해 고객과 개발자 사이에서 소통할 수 있는 기반을 만들어야 합니다.

그러다 보니 '종심타격(縱深打擊)'으로 확실한 기반을 만들고 싶은 욕망을 갖게 되는 것은 당연한 일입니다. 한 번 맛보면 참을 수가 없는 요령이 되고, '일잘러'로 평가 받게 되던 보상 패턴이 만드는 선순환 또는 일종의 강화입니다.

개발자 입장에서 확인하는 시스템의 상태 정보

아무튼 그러한 배경으로 선택한 대시보드 시각화가 어떤 결과를 낳을까요? 먼저 개발자가 다음과 같은 화면을 내놓았습니다.

구현 과정에서 자연스럽게 모델러(이 상황에서는 저죠) 관점에서 설정한 상태 설정과 상태 이름에 대한 평가가 이뤄집니다. 그러나 개발자의 관점은 '그 이름이 적절하냐?'와 같이 흔히 말하는 도메인이 지식에 부합하느냐로 향하지는 않습니다. 그보다는 다음과 같은 질문으로 개발자 관점을 예로 들 수 있습니다.

화면에 상태 변화를 어떻게 구분하고 배열할 것인가?

상태 진입이나 전환은 어떻게 촉발되는가?

API로 연동하는 외부 시스템의 상태 중에 우리가 주목해야 하는 것들은 무엇이 있는가? (상태 관리 대상 식별)

외부 시스템의 상태 변화를 어떤 방법으로 알 수 있는가?

도메인 지식이 모델에 흡수되는 피드백 장면

이와 동시에 고객에게 대시보드를 보여주면 '우리 비즈니스 상황에 적합한 상태 구분과 이름인가?'에 해당하는 피드백을 받을 수 있습니다. 그중 일부를 인용하면 다음과 같습니다.

WB에서 주문이 들어오면 출고대상 주문으로 표시가 되는 거죠?

만일 주문이 몇 백개가 되면 전부 표시할 수 있나요?

출고대상 주문에서 출고 지시를 클릭하면 출고 요청 중으로 넘어오고, 동시에 창고로 주문이 들어가는 거네요.

창고에서 작업이 완료되면 출고 완료로 보여지는 거네요. 작업이 완료된 이후인가요? 아니면 창고 출고가 완료되었을 때인가요?

창고 출고후 수출통관, 해상운송 중에 보여지는 구간이 선박 이동 중이네요.

선박 이동 중 진입은 비엘 번호가 들어가거나, 선사 부킹번호가 들어가거나, 한국 수출면장 번호가 들어가거나 이 셋 중 하나를 선정해서 수동기입하는 방법으로만 구현이 가능할거 같습니다.

파워포인트를 이용한 시각화 그리고 개발자의 화면 구현으로 얻어낸 결과는 한 차례의 대면 미팅 이후에 채팅을 통한 원격 소통으로 빠른 속도로 도메인 지식을 추려내고 습득하여 구현에 반영할 수 있게 된다는 점입니다.

은유로 사용한 '종심타격(縱深打擊)'의 효과라는 관점으로 설명해 볼까요? 모델러 입장에서는 유사 경험을 갖고 있긴 하지만 새로운 국가로 수출해야 하고, 처음 보는 창고와 창고 관리 시스템 그리고 새로운 이커머스 시스템 API이라는 모르는 영역이 엮어서 만들어내는 '모호함'을 소통 가능한 수준으로 제압할 수 있게 되었습니다.

모호함이라는 적진을 단박에 종심타격한 모델의 힘

이제 모델러는 고객과 개발자와 함께 이야기할 수 있는 '용어'들이 생겼고, 그들 용어가 어떻게 엮여 쓰이는지 예시가 되는 일종의 '정보 지도'를 얻게 되었습니다. 과거에 같은 조직에 속해 일해 본 경험이 없고 서로 입장과 역할이 다른 사람들이 소프트웨어 개발이라는 공동의 목표를 향해 원격 소통을 할 수 있는 단단한 기반이 생겼습니다.

물론, 단박에 소통이 풀리지 않는 경우도 있습니다. 모델러의 최초 파악에 오류가 있을 수도 있고요. 앞선 예시의 경우에도 중첩되는 상태를 두고 같은 상태 이름을 쓰는 오류가 있어서 상태 이름 변경을 하기로 했습니다.

개발자와 고객 피드백을 받아 모델은 계속 개선이 됩니다. UML로 모델링을 하던 시절에는 이를 모델 정제(refinement)라고 불렀는데요. 찾아보면 컴퓨팅 분야뿐 아니라 다양한 분야에서 '정제'를 하고 있습니다.

출처: 좌측은 네이버 한자사전, 우측은 위키피디아 페이지

업무 지식을 추려 집약한 정보로 지도 역할을 하는 도식

모델러는 여기서 대시보드로 겨냥했던 목표 즉, 모호한 내용 중에 뼈대가 되는 첫 번째 지식을 하나의 문서로 만들 수 있습니다. 자연어로 문서를 쓸 수도 있지만, UML과 같은 모델링 언어를 활용해 도식(diagram)을 만들면 지식을 더욱 압축한 정보로 문서(그림 형태지만)을 만들 수 있습니다. 제 경우는 상태도가 적합하다고 판단이 되어서 다음과 같이 그립니다.