네이버, 티스토리, Velog 등 여러 블로그 플랫폼이 있지만, 다양한 제약에서 벗어나기 위해 GitHub Pages를 통해 블로그 사이트 주소를 만들고, 화면은 Avalonia와 Markdown을 이용하여 구현해 보려고 합니다. Slog라고 하기엔 늦은 감이 있지만, 마무리에 힘을 더하고자 이 과정을 함께 기록하려 합니다.
GitHub Pages는 정적 사이트를 쉽게 호스팅할 수 있는 서비스입니다. Markdown 파일(.md)을 HTML로 렌더링할 수 있으며, React 라이브러리도 사용할 수 있어 다양한 웹사이트를 구축할 수 있습니다.
GitHub Pages Themes 활용
Markdown 렌더링: HTML 위에 Markdown 파일을 쉽게 띄울 수 있습니다.
HTML 제작: 직접 HTML을 작성해 원하는 화면을 만들 수 있습니다.
React 지원: React 라이브러리를 이용해 동적인 웹 페이지도 구현 가능합니다.
지킬(Jekyll)을 사용하지 않는 이유
지킬(Jekyll) 은 Ruby 기반의 정적 사이트 생성기입니다. 많은 사람들이 GitHub Pages 블로그를 만들 때 Jekyll 테마를 활용하곤 합니다. 저도 처음에는 Jekyll 테마를 적용하려 했지만, 정적 페이지 기반이라는 점 때문에 다른 선택을 하게 되었습니다. 닷넷 기술도 활용하고 싶었기 때문입니다.
Avalonia를 선택한 이유
닷넷 기술을 활용해 Blazor 외에도 웹사이트를 구축할 수 있다는 것을 보여주고 싶었습니다. 그래서 OpenSilver와 Avalonia 두 가지를 후보로 놓고 고민했습니다.
OpenSilver
여러 시도 끝에 OpenSilver로 HTML에 가까운 화면을 구현하는 데 성공했지만, 제가 필요로 하는 XAML 기반의 Markdown 렌더링 컨트롤이 없다는 문제에 직면했습니다. (아마 제가 못 찾은 것일 수도 있습니다…)
Avalonia
결국 Avalonia를 선택한 이유는 닷넷 기술을 활용해 정적 페이지에서 원하는 기능들을 구현할 수 있었기 때문입니다. Markdown 파일을 화면에 쉽게 뿌릴 수 있고, 제가 구상한 블로그 구조를 효율적으로 만들 수 있었습니다.
폰트 파일을 다운로드하면 보통 -Black, -Bold, -Thin 등 여러 개의 TTF 파일로 나뉘어 있습니다. WPF에서는 각 TTF 파일을 일일이 등록하고 키를 따로 지정해야 했던 기억이 있습니다. 하지만 Avalonia에서는 여러 개의 TTF 파일을 하나의 키로 설정할 수 있다는 사실을 알게 되었습니다.
FontFamily 설정 예시
<FontFamily x:Key="NotoSansKR">avares://lukewireBlog/Assets/Fonts#Noto Sans KR</FontFamily>
최근 제가 겪은 여정은 매우 복잡하고도 교훈적이었습니다. 데스크탑에서 애플리케이션을 빌드할 때와 로컬에서 웹 브라우저를 띄울 때는 모든 것이 정상적으로 작동했기에, 정적 서버에서도 동일하게 동작할 것이라고 믿었습니다. 그러나 여러 번의 시도와 깊은 고민, 그리고 ChatGPT와의 고문을 통해, 정적 서버에서 WASM이 제대로 동작하지 않을 것이라는 결론에 도달했습니다. 결과적으로 반은 맞고 반은 틀렸던 것입니다.
틀렸던 가설들
내가 세운 여러 가설 중 특히 두 가지가 눈에 띄었습니다. 첫째, "폰트 리소스를 불러오지 못하는 것인가?"라는 의문이었습니다. 둘째, "동적 컨트롤 생성이 불가능한 것인가?"라는 고민이었습니다. 웹 브라우저에서는 디버깅이 쉽지 않고, 콘솔 로그도 확인할 수 없었던 터라 이 문제를 해결하는 것은 매우 어려운 일이었습니다. 그래서 마지막 수단으로 try-catch 구문을 사용해 예외 메시지를 컨트롤 텍스트로 바인딩하여 확인해보기로 했습니다. 그 결과, 마주한 오류는 API를 통해 받은 JSON 데이터에서의 Reflection 이슈였습니다.
이렇게 고군분투하던 중, ChatGPT에게 도움을 요청했습니다. "WASM에서는 System.Text.Json보다 Newtonsoft.Json을 사용해보라"는 조언을 받았습니다. 그리하여 Newtonsoft.Json을 사용해 보았고, 놀랍게도 모든 것이 정상적으로 작동했습니다.
결론
이번 경험은 저에게 많은 것을 가르쳐주었습니다. 기술적 문제는 종종 예상치 못한 곳에서 발생하며, 이를 해결하기 위해서는 올바른 도구를 선택하는 것이 중요합니다. WASM 환경에서의 개발은 때때로 예기치 않은 장애물을 가져올 수 있지만, 끈기와 적절한 리소스를 통해 극복할 수 있음을 깨달았습니다. 앞으로도 이러한 경험을 바탕으로 더 나은 해결책을 찾아 나가야겠다는 다짐을 하게 됩니다.
System.Text.Json 은 추측 변환이 엄격히 제한되어 있다는 특징이 있습니다.
즉, Newtonsoft.Json 은 알아서 해주는 것이 많아서, 어지간하면 문제를 일으키지 않은 반면, System.Text.Json 은 직렬화 관련 문제 있는 필드를 무시하거나, 예외를 일으킬 수 있습니다.
네 제 Slog를 올리고 나서 Newtonsoft.Json을 사용해서 좋게 넘어가려고 했는데…
뭔가
WASM을 쓰려면 System.Text.Json을 쓰면 안되!
라는 인식을 남겨줄까 계속 원인이 뭘까 찾아보고 있었는데 @BigSquare 님이 JsonSerializerOption 관련된 내용을 남겨주셨네요!
우선 맞는 말씀이신거같아요.
조언해주시는 조건 외에도 제 API에 Null관련된 문자열이 포함되어 있는 부분도 존재했었습니다만 미해결되었네요…(결국엔 Newtonsoft.Json…)
Desktop과 로컬Web을 통한 디버깅으로 했을 때 정상적으로 넘어갔다는게 아직도 의문입니다… 단지 WASM만의 문제라고 짚는게 맞을까 고민이 되기도하고요
블로그 프로젝트가 오늘로써 막을 내리게 될 것 같습니다. 사실, 나만의 블로그는 크게 실행하진 않았지만, 이 과정을 통해 많은 것을 배우고 느꼈습니다. 블로그의 핵심인 Markdown 게시글에 한계가 오면서 업데이트를 기다려야 할 시점에 이르렀습니다.
사용한 기술과 도전 과제
현재까지 Avalonia.HTMLRenderer를 활용하여 Markdig와 함께 화면을 구성해왔습니다. 그러나 한글이 제대로 표시되지 않는 이슈를 발견했습니다. 처음에는 단순히 Avalonia 컨트롤의 폰트를 설정하면 될 것이라는 막연한 생각으로 접근했지만, 설정한 폰트가 적용되지 않았습니다. HTML에 웹 폰트를 강제로 불러오는 방법을 시도해보았지만, 프로그램 내에서는 변화가 없었습니다. 다행히 HTML을 웹 브라우저에서 띄워보니 문제 없이 출력되었습니다.
이에 따라 Markdown.Avalonia 라이브러리를 사용하여 MatoEditor의 스타일과 Markdown.Avalonia.Html을 적용해 현재의 모습까지 구축하게 되었습니다.
해결하지 못한 문제들
하지만 웹 버전에서 다음과 같은 문제들이 남아 있었습니다:
URL 링크 이동 문제
소스 코드를 확인해보니 WebBrowser에 대한 처리 부분이 누락되어 있었습니다. 링크 클릭 시 URL 이동이 이루어지지 않는 상황이 발생했습니다.
csharp
코드 복사
public static void GoTo(string url)
{
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
Process.Start(new ProcessStartInfo(url)
{
UseShellExecute = true,
Verb = "open"
});
else if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
{
Process.Start("xdg-open", url);
}
else if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
{
Process.Start("open", url);
}
}
이미지 링크 불러오기 문제
상대 경로가 아닌 절대 경로를 사용했음에도 이미지를 불러오지 못하는 상황이 발생했습니다. 이 부분은 CORS 설정이나 경로 문제로 의심되며, 추가적인 조사가 필요할 것 같습니다.
마무리 및 소감
닷넷 데스크탑 앱만 개발하던 저에게 웹사이트를 만들고 개인 블로그를 개설하며 화면을 구축하는 경험은 정말 값진 시간이었습니다. 이번 프로젝트를 통해 웹 프레임워크 기술(ASP.NET, Blazor 등)의 필요성을 깊이 이해할 수 있었고, 웹 환경에서의 다양한 문제 해결 능력도 기를 수 있었습니다.
이제는 더 나은 블로그를 위해 업데이트를 기다려야 할 것 같습니다. 앞으로의 여정에서도 이러한 경험이 많은 도움이 될 것이라 믿습니다. 여러분도 각자의 블로그를 만드는 여정에서 이러한 도전과 성장을 경험하시길 바랍니다!