LazyVoom.Hosting에 MewUI를 연동시켜봤습니다.

LazyVoom.Hosting@al6uiz 님의 MewUI 를 연동해보는 작업을 진행해보았습니다.

회사 업무를 하다 보면, 가끔 아주 간단한 테스트용 프로그램을 빠르게 만들어야 하는 상황이 생기는데
그럴 때마다 “구성은 최대한 단순하게, 개발 속도는 빠르게” 가져가고 싶다는 생각이 늘 있었습니다.

마침 최근에는 개인적으로 AIAgent Framework를 가지고 이것저것 실험하고 있어서, 단순함을 유지하면서도 나중에 확장 가능한 구조가 있으면 좋겠다는 생각이 들었고, 그 연장선에서 이번 연동을 시도하게 되었습니다.

사실 이 조합은 라이브러리 본래의 배포 크기나 지향점과는 다소 다른 사용 사례일 수도 있습니다.
다만,

  • 명령 기반으로 빠르게 동작하고
  • 결과를 간단히 보여주기에 부담이 없으며
  • 전체 구조를 가볍게 유지할 수 있다는 점에서

“간단한 도구를 만들기엔 이만한 선택지도 많지 않다”는 느낌을 받았습니다.

이번 연동은 어디까지나 실험적인 시도에 가깝지만,
비슷한 고민을 하시는 분들께는 하나의 참고 사례가 될 수 있을 것 같아 공유해봅니다.

6개의 좋아요

글 잘 읽었습니다.
감사합니다.

글을 읽다가 wpf쪽에서 궁금한게 생겨서 질문 댓글 하나 남겨봅니다.

Host를 사용하여 프로그램을 실행하는 부분입니다.
실행 자체를 App.xaml 과 App.xaml.cs에서 하는것이 아닌
Program.cs 에서 하신 이유가 있으실까요?

1개의 좋아요

좋은 질문 감사합니다 :slightly_smiling_face:

사실 말씀하신 부분은 기술적으로 큰 차이가 있다기보다는, 구조를 바라보는 관점의 차이 에 더 가깝다고 생각합니다.

저 같은 경우에는 약간 “심리적인 분리” 때문에 Program.cs 에서 시작하는 방식을 사용하고 있습니다.

App.xaml 안에서 모든 걸 시작해버리면, 그 애플리케이션이 완전히 WPF에 종속된 느낌 이 강해집니다.
즉, “이건 그냥 UI 앱이다”라는 경계 안에 갇히는 느낌이 들더라고요.

반대로 Program.cs 에서 Host 를 구성하고 시작하게 되면,
애플리케이션을 하나의 호스팅 환경 위에서 돌아가는 여러 구성 요소들의 조합 으로 보게 됩니다.

예를 들어,

  • UI와 무관한 Worker Service가 추가된다거나
  • WPF는 유지하면서 내부적으로 Web API 서버를 함께 띄운다거나

이런 확장 시나리오를 떠올렸을 때,
구조적으로 “아, 이건 나중에 분리도 가능하겠다”라는 감각이 자연스럽게 생깁니다.

물론 실제로 그렇게 확장하려면 결국 프로젝트 분리나 구조 정리는 필수지만,
처음부터 Program.cs 기반으로 가져가면
“나중에 떼어낼 수 있는 구조”를 염두에 두고 개발하게 되는 점 이 개인적으로는 장점이라고 느꼈습니다.

정리하면,

기능적인 차이보다는
“이걸 하나의 UI 앱으로 볼 것인가,
아니면 여러 역할을 가진 호스팅 애플리케이션으로 볼 것인가”
그 관점 차이에서 선택한 방식입니다.

7개의 좋아요

좋은 답변 감사합니다!
program.cs에서 실행하시는 분들을 보았으나, 그렇게 하는 이유는 찾아보기가 힘들어 질문 드렸었습니다. ㅎㅎ

2개의 좋아요