Wails v3 베타, Go 데스크톱 앱의 구조를 다시 짰어요

Wails v3가 3년 넘는 알파 개발을 마치고 베타 단계에 들어갔어요. Go 백엔드와 웹 프론트엔드로 데스크톱 앱을 만드는 방식은 그대로지만, 복잡한 제품을 다루기 위한 내부 구조는 크게 달라졌어요. 여러 창과 서비스의 수명주기를 코드에서 명확히 관리할 수 있게 된 점이 이번 변화의 중심이에요. 1
핵심 요약
| 구분 | 달라진 점 | 개발자가 확인할 부분 |
| 앱 구조 | Application, Window, Service를 명시적인 객체로 다뤄요 | 창과 서비스의 생성·종료 시점을 코드에서 추적하기 쉬워져요 |
| 멀티윈도우 | 여러 창을 기본 기능으로 지원해요 | 에디터, 설정, 검사 도구처럼 창이 많은 앱에 잘 맞아요 |
| 프론트엔드 연결 | Go 소스를 분석해 TypeScript 바인딩을 만들어요 | 실제 매개변수 이름과 주석을 프론트엔드 API에 반영할 수 있어요 |
| 빌드 | Taskfile 기반 작업을 직접 확인하고 바꿀 수 있어요 | 빌드 과정을 확장하거나 오류를 찾기 수월해져요 |
| 안정성 | v3는 아직 베타이고 v2가 안정 버전이에요 | 기존 제품은 마이그레이션 범위와 회귀 테스트 비용을 먼저 계산해야 해요 |
1. 가벼운 GUI 래퍼에서 앱 구조를 다루는 프레임워크로
Wails는 Go로 백엔드를 만들고 HTML, CSS, JavaScript나 React, Vue로 화면을 구성해요. macOS, Windows, Linux용 앱을 단일 바이너리로 묶을 수 있어 Electron 대안으로 알려졌어요. v3는 이 조합을 유지하면서 기존 `wails.Run` 호출과 암묵적인 컨텍스트에 기대던 구조를 정리했어요. 개발자는 Application, Window, Service를 객체로 만들고 각 요소의 수명주기를 직접 다뤄요. 2
이 변화는 창 하나짜리 유틸리티보다 규모가 큰 앱에서 더 또렷하게 보여요. 편집기 본체와 Inspector, Preferences, Tool Window를 따로 띄우는 앱이라면 창마다 상태와 종료 순서를 관리해야 해요. v3는 멀티윈도우를 기본 기능으로 제공해 별도 우회 코드를 줄여요. 운영체제별 창 동작이 다른 부분은 실제 대상 환경에서 확인해야 하지만, 애플리케이션 모델 자체가 여러 창을 전제로 바뀌었다는 점은 분명해요.
Service가 백엔드 경계를 드러내요
기존 binding 대신 Go Service가 프론트엔드에 노출할 기능을 묶어요. Go 소스를 정적 분석해 TypeScript 바인딩을 만들기 때문에 주석과 실제 매개변수 이름도 살릴 수 있어요. 런타임 reflection에만 기대는 방식보다 프론트엔드 개발자가 읽는 API 정보가 풍부해져요.
Service는 Go API와 프론트엔드 asset, script를 함께 제공할 수 있어요. 기능 모듈을 한 단위로 배포하는 구조를 설계할 때 쓸 만한 기반이에요. 다만 v3에 범용 설치형 플러그인 시스템이 완성돼 있다는 뜻은 아니에요. 플러그인 마켓이나 권한 격리까지 필요하다면 제품 쪽 설계를 따로 해야 해요.
빌드 과정과 서버 실행 방식도 열렸어요
v3는 빌드 단계를 프레임워크 안에 감추지 않고 Taskfile 작업으로 보여줘요. 팀에서 코드 생성, 프론트엔드 번들링, 서명, 패키징 순서를 바꾸려면 해당 작업을 직접 확장할 수 있어요. 빌드 오류가 났을 때 어느 단계에서 막혔는지도 확인하기 쉬워져요.
네이티브 창 없이 같은 Application과 Service를 실행하는 Server Build도 지원해요. 데스크톱 화면과 Go 로직을 분리해 테스트하거나, 같은 서비스 계층을 다른 실행 환경에서 쓰고 싶을 때 선택지가 생겨요. Linux 기본 스택은 GTK4와 WebKitGTK 6.0으로 바뀌었고 macOS·Windows·Linux의 amd64와 arm64를 지원해요. iOS와 Android 지원은 아직 실험 단계예요. 1
v2 앱은 자동으로 옮겨지지 않아요
v2에서 v3로 갈 때 패키지 버전만 바꾸는 식으로 끝나지 않아요. Application과 Window의 수명주기, Service 경계, 기존 Runtime API, 프론트엔드 바인딩을 다시 맞춰야 해요. 앱 규모가 클수록 포팅 작업에 가까워져요.
GitHub의 최신 v3 베타 릴리스도 API는 안정적이지만 정식 3.0 전에는 문제가 남아 있을 수 있는 사전 릴리스라고 밝혀요. 같은 저장소에서 v2.14.0은 안정 버전으로 따로 제공돼요. 새 프로젝트에서 v3를 시험하기는 좋아졌지만, 운영 중인 제품은 창 관리와 서비스 호출, 빌드·패키징을 포함한 회귀 테스트 계획부터 잡는 편이 안전해요. 3
왜 중요한가요
웹 기술로 만드는 데스크톱 앱은 화면 구현보다 앱 수명주기와 운영체제 통합에서 복잡해지는 경우가 많아요. 창이 늘고 백엔드 기능이 커지면 암묵적인 컨텍스트와 전역 런타임 호출이 유지보수를 어렵게 만들어요. Wails v3는 창, 서비스, 앱의 경계를 코드에 드러내 이 문제를 다루려 해요. 2
Go를 이미 쓰는 팀이라면 Electron의 Node.js 런타임 대신 기존 Go 코드와 웹 프론트엔드 역량을 조합할 수 있어요. 반대로 v2 제품을 운영 중이라면 베타 진입 자체보다 마이그레이션 비용을 먼저 봐야 해요. 멀티윈도우, TypeScript 바인딩, Taskfile 빌드가 주는 이점이 포팅과 플랫폼별 테스트 비용보다 큰지 작은 기능부터 확인하는 접근이 현실적이에요.
참고 자료
- Wails v3 Beta - Go 데스크톱 앱을 위한 새로운 기반 — GeekNews
- Wails v3 Beta — Wails 공식 블로그
- Wails Releases — Wails 공식 GitHub
'IT & AI' 카테고리의 다른 글
| AI를 많이 쓰는 것이 생산성은 아니에요: 사람이 루프를 잡는 법 (0) | 2026.08.14 |
|---|---|
| Grok 4.6, 성능보다 비용표가 더 눈에 띄어요 (0) | 2026.08.14 |
| 영상 타임라인에 Claude와 Codex가 들어왔어요, Palmier Pro (0) | 2026.08.14 |
| uBlock Origin이 Facebook 광고 대응을 멈춘 이유 (0) | 2026.08.13 |
| Qwen3.8 2.4T를 397GB로 줄인 Unsloth, 로컬 실행의 현실 (0) | 2026.08.13 |