😊예전에 만든 MVVM 라이브러리를 다시 개선해보자.

gellston · 1월 13, 2026, 6:16오후

개발 당시에는 chatGPT를 쓰지도 않고 개발을 했는데.
몇 년 지나서 보니 정말 코드가 부끄럽군요.
이번에는 그냥 마음을 내려놓고 chatGPT와 대화를 하면서 최대한 빠르게 개선을 해보고 싶어졌습니다.
가끔 귀찮게 연락 드리면서 @이광석 @jamesnet214 좋은 말씀 듣고 있는데 배움에는 끝이 없군요.

이광석 · 1월 13, 2026, 9:32오후

안귀찮아요..재밌어요

gellston · 1월 15, 2026, 8:57오후

chatGPT와 질문하면서 배운점.

물어보면서 다시 하나하나 chatgpt가 만든 코드들을 보고 이전에 몰랐던 것들을 정리해보았습니다. 
(-_-) 뭔가 AI에게 패배한 기분이었습니다.

1. ViewModelBase vs ObservableObject

Prism에서는 ViewModelBase로 부르는데 CommunityToolkit에서 ObservableObject로 부르는 이유도 있더군요. 실무에서는 간혹 모델에 ViewModelBase를 상속받는데 그럼 ViewModel처럼 보이니까 CommunityToolkit에서는 ObservableObject 혹은 ObservableRecipient로 부르더군요.
그 의도가 좋은 것 같아서 ComvMVVM2에 있던 ViewModelBase이름을 다시 변경했습니다.

2. CommunityToolkit의 IoC 컨테이너 관련 기능

예전에 손으로 내 마음대로 ioc 컨테이너를 구현 할 적에는 내가 자주 쓰는 기능만을 구현했는데.
내가 몰랐던 기능들이 많았습니다.

1. 공용 인터페이스 묶음의 객체들을 한번에 가져오는 기능.


var vms = serviceProvider.GetServices<IAInterface>();

예전 구현에서는 IAInterface와 구상체를 1개만 매칭해서 넣게 만들었었는데 CommunityToolkit은 여러개를 등록 할 수 있나봅니다. ㅠ

2. Factory로 객체를 생성할 수 있도록 도와주는 ActivatorUtilities 존재

이 녀석은.. CommunityToolkit에 없는 녀석인 것 같은데 어디서 튀어나와서 chatGPT가 알고있는지 모르겠지만. 코드를 보니 되게 일리가 있었습니다.
제가 WPF 프로그램을 개발 할 때에는 객체 생성을 위한 Factory를 Lambda로 정의해서 생성자로 주입 받고 사용했었습니다.

// 대충 이런 느낌 
serviceCollection.AddTransient<AViewModel>();
serviceCollection.AddTransient<Func<AViewModel>>((serviceProvider) =>{
    return () => serviceProvider.GetService<AViewModel>();
})

//만약 Factory에 인자를 주입하면서 생성하고 싶다면
serviceCollection.AddTransient<BViewModel>();
serviceCollection.AddTransient<Func<int, int, AViewModel>((serviceProvider) => {
   return (a, b) => {
         var vm = serviceProvider.GetService<BViewModel>();
         vm.A = a;
         vm.B = b;
         return vm;
   }
});

하지만.. ActivatorUtilities 가 있다면 내가 힘들게 Factory를 만들어서 주입 할 필요 없이 Factory를 만들 수 있더군요 갓 MS
그리고 serviceProvider.GetService(); 가 되도록 return this 처리가 되어있어서
객체의 생성자 주입으로 IServiceProvider를 받을 수 있다는 것도 이번에 이야기하면서 알게 되었습니다. 다만 생각해보니 저렇게 IServiceProvider를 주입 받아서 쓰면 뭔가 지저분 해 질 것 같은데. 여러 객체를 많이 만들때에는 조건부로 사용하는게 좋을 것 같다는 생각을 했습니다.

3. 메신저 관련 기능

1. IWeakReferenceMessenger의 Token기능.

모르면 몸이 고생한다고.. 토큰을 설정해서 특정 토큰으로만 메세지를 전달하는 기능이 있더군요 세상에나.. 이걸 몰라서 매번 메세지에 보낼 곳 적고 받는 쪽에서 switch처리했는데 쩝..

2. ObservableRecipient의 IsActive=True 동작.

IsActive가 True일때 ObservableRecipient가 상속 받은 IRecipient의 메세지핸들러?가 자동으로 등록이 된다는 것을 이번에 처음 알았습니다 -_-… 이전에는 OnActivation이었던가 거기서 등록을 했었는데 불필요한 삽질이었습니다. 반대로 IsActive=False일때에는 모든 메세지 핸들러가 등록이 해제되는 것 같더군요. 상속받고 메세지 핸들러를 구현한 후에 IsActive만 키면 자동등록 기억해야겠습니다. ㅠ

4. Prism관련 기능

1. INavigationService의 동작

나름대로 생각해서 만들었었는데 다 엉터리였습니다.
필히 route키?를 이용한 화면 이동? 기능이 들어가야 진정한 INavigationService가 아닐가 싶네요.
route가 왜 필요한지도 chatGPT선생님에게 배웠습니다.

2. Region이 왜 ItemsControl같은 녀석들에게도 붙도록 설계되어 있는가?

Region을 이용해서 화면을 붙이는 건 이전에 납득이 가서 구현을 했었는데 ItemsControl같은 리스트형태의 녀석에도 Region을 붙이도록 하는 기능이 이해가 되지 않아서 구현을 하지 않았습니다.
근데 chatGPT 선생님이 말씀하시는 부분에서 큰 깨닫음을 얻었습니다.
만약 ItemsControl에 Region이 붙지 않는다면 ItemsControl을 소유한 View의 ViewModel에서 ItemsControl에 뿌려야 할 객체 묶음을 관리하게 되기 때문에 View와 ViewModel이 늘어날 수록 일관된 관리가 힘들어진다는 점입니다.
Region이 없다면 멀리 떨어진 ViewModel과 화면끼리의 묶음 데이터 교환과 시각화 과정이 불필요하게 복잡해 지기 때문에 ItemsControl을 소유하고 있는 View의 ViewModel이 복잡해진다는 거지요.

3. Module의 On-Demand 로드

Assembly는 로드한 상태로 Module에 들어가 있는 View나 ViewModel, 서비스등의 생성이 필요할때 모듈을 초기화한다는 기능이 있다는 것도 몰랐습니다 ㅠ 이 기능이 있으면 프로그램 시작이 빨라져서 좋을 것 같아 이번에 구현하기로 했습니다.

이광석 · 1월 15, 2026, 10:51오후

어제 @gellston 님이랑 얘기하다가
“ItemsControl에 왜 굳이 Region을 썼을까?”를 다시 생각해봤습니다.
저도 한동안 딱 잘라 설명하기는 애매했는데, 정리해보면 이런 이유인 것 같습니다.

ItemsControl을 바인딩으로 쓰다 보면
결국 DataTemplate로 ViewModel 타입마다 화면을 나누게 되는데,
1~2개면 몰라도 화면이 늘어나기 시작하면
자칫 XAML이 끝없이 늘어나는 구조가 되기 쉽습니다.

게다가 화면이 확장되면서 기능이 붙기 시작하면,
특정 타입일 때만 동작하는 로직이나
연결해야 할 서비스가 생기는 경우도 많아지고,
이런 요소들이 쌓이면서
단순히 DataTemplate 안에서 해결하기엔
UI 형태나 복잡도가 감당하기 어려운 수준까지 올라갈 수 있습니다.

Region을 쓰는 쪽은 이걸 구조적으로 끊을 수 있고요.
각 View는 필요할 때 Region에 들어오고,
ItemsControl 쪽 ViewModel은
“뭘 그릴지”보다는 “자리를 내주는 역할”에 가까워집니다.

ItemsControl의 Region뿐만 아니라,
Region 구조 자체가
MVVM을 아주 엄격하게 가져가는 방식보다는,
View–ViewModel을 한 쌍으로 묶어
컴포넌트처럼 다루는 데 잘 맞는 선택 같다는 생각이 들었습니다.