Go로 GUI 앱을? 선언형 프레임워크 'Gova'의 시도

Go는 왜 GUI에서 약했을까

Go 언어 좋아하시는 분들 많으시죠. 서버, CLI, 네트워크 도구에서는 거의 무적이거든요. 그런데 이상하게 데스크톱 GUI 앱을 만들려고 하면 갑자기 선택지가 확 줄어들어요. Fyne, Wails, Gio 정도가 그나마 알려져 있지만, React나 SwiftUI에 익숙한 개발자가 쓰기엔 뭔가 올드한 API 스타일이거나, 아니면 결국 웹뷰(Chromium)를 띄우는 방식이라 "이거 그냥 Electron이랑 뭐가 달라?" 싶은 느낌이 들곤 했어요.

이런 상황에서 최근 GitHub에 등장한 Gova는 흥미로운 제안을 해요. 부제가 "The declarative GUI framework for Go"인데, 선언형(declarative) UI를 Go 네이티브 문법으로 쓸 수 있게 하자는 거예요. 선언형이 뭐냐면, "버튼을 그려라", "색을 빨갛게 바꿔라"처럼 방법을 지시하는 게 아니라, "상태가 X면 UI는 이렇게 생겼어야 해"라고 결과를 서술하는 방식이에요. React, SwiftUI, Flutter, Jetpack Compose가 전부 이 계열이죠.

Gova의 접근 방식 뜯어보기

Gova의 코드를 보면 Flutter와 SwiftUI의 영향이 꽤 느껴져요. 위젯(Widget)을 함수처럼 호출해서 트리를 구성하고, 상태가 바뀌면 해당 서브트리만 다시 빌드하는 식이에요. Go는 제네릭이 있고 구조체 리터럴이 깔끔한 편이라, 타입 안전한 DSL(Domain Specific Language)을 짜기에 나쁘지 않은 언어예요. JavaScript의 JSX처럼 별도 전처리기를 쓰지 않고도 비교적 읽기 쉬운 트리 표현이 가능하다는 게 Gova의 강점이죠.

상태 관리는 전형적인 useState 스타일이라고 보시면 돼요. 상태 변수를 선언하고, 이벤트 핸들러에서 업데이트하면 프레임워크가 알아서 리렌더링을 트리거해요. 렌더링 백엔드가 어디냐가 관건인데, 레포 초기 버전에서는 커스텀 렌더러 혹은 기존 그래픽 라이브러리 위에 얹는 구조를 시도하고 있어요. 이 부분은 프로젝트가 성숙해지면서 바뀔 여지가 커요.

기존 Go GUI 진영과 비교

Fyne은 자체 캔버스 렌더러를 쓰고 크로스플랫폼 배포가 쉬운 대신, 네이티브 느낌이 덜하고 API가 다소 명령형이에요. Gio는 immediate mode라고 해서 매 프레임 전체를 다시 그리는 방식인데, 성능은 훌륭하지만 학습 곡선이 가팔라요. Wails는 프론트엔드를 웹 기술로 짜고 Go와 브릿지로 연결하는 Electron 스타일이고요.

Gova는 이 중 Gio나 Fyne과 같은 네이티브 렌더링 계열에 서고 싶어 하는 것 같지만, API는 Flutter/React에 익숙한 개발자에게 친숙한 선언형을 내세워요. 만약 이게 잘 성숙하면, "Go로 서버를 짜던 사람이 별도 언어 학습 없이 데스크톱 클라이언트까지 만들 수 있다"는 시나리오가 현실이 될 수 있어요.

다만 현실적으로 아직은 실험 단계예요. 컴포넌트 라이브러리 규모, 접근성(a11y) 지원, 한글 입력 같은 IME 처리, 고해상도 스케일링, 그리고 macOS/Windows/Linux 각각의 네이티브 룩앤필 등 "실제 제품에 쓰려면 꼭 필요한 것들"이 아직 많이 부족해요. 커뮤니티가 붙어줘야 채워질 영역이죠.

업계 흐름 속 위치

재미있는 건, 선언형 UI의 흐름이 이제 거의 모든 언어로 번지고 있다는 점이에요. Swift는 SwiftUI, Kotlin은 Compose Multiplatform, Rust는 Dioxus와 Iced, C++는 Slint, Python은 Flet. 과거에 Win32나 GTK, Qt가 대표했던 "명령형 위젯 조작" 시대는 확실히 저물고 있어요. Go는 그동안 이 흐름에서 약간 뒤처져 있었는데, Gova 같은 프로젝트들이 그 공백을 메우려 하고 있는 셈이에요.

한국 개발자에게 의미

당장 사내 툴이나 프로덕트에 Gova를 도입하는 건 시기상조예요. 그래도 살펴볼 가치는 충분해요. 첫째로, 선언형 UI가 어떻게 구현되는지 내부를 들여다보기 좋은 스터디 자료예요. React가 어떻게 동작하는지 궁금했다면, 규모가 작고 Go로 짜인 Gova 코드를 읽으며 리컨실리에이션(상태 변화 반영) 로직을 파악해볼 수 있어요.

둘째로, 사내 개발자용 내부 도구를 만들 때 Electron이 부담스러운 경우에 대안이 될 수 있어요. 팀이 이미 Go 백엔드를 다룰 수 있다면, 프론트엔드를 위해 TypeScript 생태계를 통째로 들여오는 비용을 아낄 수 있거든요. 셋째로, 오픈소스에 기여하기 좋은 규모예요. 대형 프레임워크에 PR 넣는 건 부담되지만, Gova 정도면 위젯 하나 추가하는 수준의 기여로도 의미 있는 커밋을 쌓을 수 있어요.

마무리

Go가 서버 언어의 틀을 넘어 GUI까지 넘볼 수 있을까요? 선언형 UI가 결국 모든 플랫폼의 표준이 되고 있는 지금, Go 진영에서도 이런 시도가 나온 건 자연스러운 흐름이에요. 여러분은 데스크톱 앱을 만들 때 어떤 스택을 선호하시나요? Electron 피로감을 느껴본 경험이 있다면 그 대안으로 무엇을 고려해보셨는지 댓글로 나눠주세요.