모델링이 주는 핵심 가치에 대하여

감히 시도하는 설계의 정석

Nov 25. 2025

불현듯 모델링을 세 가지 축으로 정의하고 싶었습니다. 깊이 생각할 필요도 없이 첫 번째는 '시각화Visualization'였습니다. 두 번째는 '구조화構造化'를 떠올렸습니다. 구조화를 떠올릴 때 잠시 제 머릿속에서 '표준화'와 겨뤘지만, 요소들과의 관계와 총체적 양상을 함께 드러내야 하는 모델링의 유용성을 생각하면 확실히 구조화가 중요합니다. 나머지 하나가 문제였는데, 그걸 찾은 기쁨으로 글을 씁니다.

시각화, 구조화, 최적화라는 모델링의 가치

인공지능 길들이기 습관으로 언어 모델들에게 그림을 그려 달라고 했습니다. 이번에는 (최근에는 주로 카나나가 좋았는데) 의외로 클로드의 승리입니다.[1]

첫 번째는 클로드 솜씨, 두 번째는 퍼플렉시티 그림

내친김에 둘에게 저의 정의에 대해서 비판적으로 평가해 달라고 요구했습니다. 그 결과도 클로드가 마음에 들었습니다. 클로드는 제 정의를 실용적으로 보았고, 동시에 개념 구분의 엄밀성이 떨어진다고 평가했습니다

이후에 이들에 대해 다루기로 하고, 설계에 대한 중요한 문제 하나를 먼저 다루겠습니다.

텍스트나 코드로 정교하게 규정하면 모델링인가?

설계에 대한 실무 경험에 더하여 설계 방안에 대해 생각을 꽤 오래 해 왔는데 뾰족하게 풀리지 않는 의문이 하나 있습니다.

TDD도 설계 방법인가?

이에 대해서는 올봄에 <TDD는 디자인에 반한다는 교수의 주장에 대해>를 쓰면서 생각을 정리한 기록이 있군요. 이 글의 주제인 모델링으로 좁혀 보면 코드를 유도하는 잘 쓰인 테스트케이스도 모델링으로 볼 수 있느냐는 것이죠. 저는 그럴 수 있다고 보는데, 퍼플렉시티에게도 물었습니다. 모호한 답을 했는데, 클로드에게도 똑같이 물었습니다. 비슷한 수준의 모호한 말을 하네요. 질문이 영어라면 다를까요?

영어로 묻고 한국말로 번역했더니 좀 낫군요.

상세한 테스트 케이스 작성은 TDD에서 중요한 설계 활동이며, 이를 소프트웨어 모델링의 일종으로 간주하는 것이 타당합니다. 테스트 케이스가 명세화된 모델로서 설계와 개발을 연결하는 역할을 하기 때문입니다. 요약하면, TDD에서 작성하는 상세 테스트 케이스는 설계와 구현의 중간 단계인 실행 가능한 소프트웨어 모델로 이해할 수 있습니다. 이는 설계 문서와 테스트 검증을 동시에 수행하는 중요한 개발 활동입니다

저는 TDD도 설계 방법으로 볼 수 있다고 생각합니다. 다만, 기능 중심적인 설계로는 실용적이지만, 구조 설계에 대해서는 리팩터링이라는 절차만 있어 부족함이 있다[2]는 것이 제 생각입니다. Kent Beck이 그린 그림을 인용하면 붉은색 영어이 구조 설계 부분인데, 구체적인 방법론이 제시되어 있지 않아 모호할 수 있습니다.

그중에서도 시각화는 압도적인 제1 가치

TDD가 설계 방법이냐? 또는 TDD가 모델링이냐? 두 가지 문제에 대해서 견해가 다르더라도, 말로 소통하는 방식에 비해 글자와 도식으로 명확하게 쓰고 눈에 보이는 사항을 바탕으로 설계에 대해 소통하고 함께 일하는 일은 분명히 유익합니다. 그렇기 때문에 모델링의 제1 가치는 눈에 보이게 하는 것 그리고, 중요한 사항은 암묵적인 내용을 명시적으로 만들어 가급적 같은 것을 보고 협업하는 것이라고 말할 수 있습니다.

두 번째는 구조화인데, 특히 누적적으로 축적된 복잡한 구조에 대한 시각화가 도움이 될 때가 많습니다. 비유적으로 우리가 지도를 자주 보거나 네비를 보는 일이 일상에 매우 중요한 것과 비슷한 이치입니다. 구조화의 가치는 소프트웨어 개발에 있어서 지도나 내비게이션이 주는 가치와 매우 비슷하다고 할 수 있습니다. 앞서 TDD를 설계 방안으로 쓸 수 있다고 주장했는데, 다만 구조화 측면에서는 자신이 짠 코드가 아닌 부분에 대해 명확한 이해가 부족할 수 있습니다. 물론, 코드 리뷰로 보완할 수는 있지만, 전체를 이해한 사람이 개요를 표현하는 '구조화'된 시각 모델이 효과적이라고 믿습니다.

세 번째는 이름을 두고 고심했던 항목입니다. 최적화라고 했지만, '당장의 쓸모' 같기도 했습니다. 아니면, 모델 작성자와 모델 소비자 사이의 적절한 쓰임새에 맞춘 것이란 생각도 들었습니다. 그러다 보니 '용도 최적화' 같은 생각을 했는데, 일단 초안이라고 보고 생각을 노출하자 싶었습니다. 무의식적으로 글자수나 라임을 맞추려 했는지도 모르겠습니다.

모델링 가치에 대한 언어 모델의 제안

이렇게 생각을 다 뱉어놓고 나니, 클로드의 조언을 들을 여유가 생겼습니다. 아까는 눈에 잘 안 들어왔었거든요. 똑같은 내용인데, 기분이나 감정이 바뀐 모양입니다. 클로드가 무려 대안을 세 개나 제시했는데, 첫 번째는 구분이 좀 모호한 느낌이지만, 내용은 좋았습니다.

두 번째는 빠짐없이 망라한(MECE) 점에서는 좋지만, 지나치게 현학적이거나 작위적인 느낌이 들었습니다.

세 번째는 모델링의 가치가 아니라 모델링 결과물의 가치 평가 틀처럼 보였습니다.

구조화된 시각적 전달물 그리고 검증 가능성

이 글을 다 쓰고 나서 모델 혹은 모델링에 대한 지적 자극이 생긴 두 개의 사건이 있습니다. 하나는 <항상 내 재미를 스스로 찾을 수 있어야 하는 걸까?>를 쓰면서 다음 그림을 그릴 때입니다. 어떤 현상을 설명하기 위해서 이렇게 빠르게 특징만 포착해서 '구조화된 시각적 전달물'을 만드는 일은 개념 모델링의 전형적 쓸모가 아닌가 싶었습니다.

두 번째는 비슷한 시기에 <아이디어 불패의 법칙>을 읽을 때 찾아왔습니다.

여러분의 신제품 아이디어가 막연하고, 부정확하고, 애매모호하고, 여러 해석을 가능하게 한다면, 더 이상 진행할 단단한 토대가 없는 것과 같다. 어느 아이디어를 테스트하려면 충분히 명확하고 정확하게 또렷한 언어로 표현할 수 있어야 한다.
출처:<아이디어 불패의 법칙> 107쪽