최근, AI (Codex 데스크톱 버전)를 사용하여 하나의 툴을 완성했습니다.

이전에는 설계서를 전달했지만, 이번에는 설계서를 전달하지 않고 다음과 같이 부탁하는 방식이었습니다.

SourceTree의 대용이라기보다, 모노레포(Monorepo)에서 「폴더 단위의 Git 이력」을 보는 것에
특화된 작은 GUI 툴을 만들고 싶습니다.
MVP는, 로컬 Git 리포지토리를 열어서, 루트 직하 폴더를 선택하면
...

그곳에서 체험한 것은, 지금까지의 개발 상식이 통하지 않을 정도의 「속도」와 「당혹감」입니다. 최근의 트렌드인 「기술 선정이나 설계부터 AI에게 통째로 맡기는」 수법을 시도한 결과, 개인 개발의 방식이 어떻게 변했는지.

실제 세션 로그를 공개할 테니, 그 뒷이야기를 즐겨주세요. ← 뭐, 이번에는 너무 순조롭게 진행되어 재미는 없지만...

1. 상담의 계기: 무의식적으로 포기하고 있었던 「불편함」의 정체

계기는 모노레포 구성으로 개발하던 중에 느끼고 있던 작은 스트레스였습니다. 하나의 리포지토리에 여러 플랫폼이 공존하고 있으면, 표준 GUI 툴로는 특정 폴더만의 이력을 추적하는 것이 의외로 번거롭습니다.

저는 이것을 「모노레포의 사양상 어쩔 수 없는 일」이라며 절반쯤 포기하고 있었습니다. 하지만, Codex에 이 「푸념」을 던져보았더니, 의외의 대답이 돌아왔습니다.

AI (Codex): "그것은 만들 가치가 있는 타입의 것입니다."

AI와의 대화를 통해, 자신이 「어쩔 수 없다」고 믿고 있었던 불편함이, 사실은 「해결해야 할 명확한 과제 (아이디어)」로 변한 순간이었습니다.

2. 기술 선정과 설계를 「통째로 맡겨」 보기

이번에는 구현을 지시하기 전에 「기술 선정과 설계」부터 AI에게 제안하게 했습니다. 스스로 생각하는 것이 아니라, AI에게 리드를 맡겨본 것입니다.

GUI: Tauri + React / TypeScript

Git 조작: 라이브러리를 직접 보유하기보다, 동작의 신뢰성이 높은 Git CLI를 직접 호출하는 구성

화면 설계: 모노레포의 「폴더 단위」 열람에 특화된 3-pane 구성

Tauri를 선택한 이유는, OS 표준 WebView를 이용하기 때문에 배포용 exe가 매우 경량화된다는, 지극히 합리적인 이유였습니다.

3. 왜 백엔드에 Rust인가?

「TypeScript만으로 완결되는 것 아닌가?」라는 의문에 대해서도, Codex는 명확한 역할 분담을 제시했습니다.

TypeScript: 화면의 묘사나 상태 관리를 담당.

Rust (Tauri): 브라우저 환경 (TS)에서는 다루기 어려운 「OS 측의 작업 (git 명령 실행이나 파일 시스템 접근)」을 안전하게 담당.

Rust는 「빌드 시에 exe로 컴파일되기」 때문에, 배포 대상 PC에 Rust를 설치할 필요도 없습니다. 이 「UI는 웹 기술, 로컬 조작은 Rust」라는 구분 제안을 통해, 개발의 해상도가 단번에 높아졌습니다.

4. 「한 번에 작동함」에 대한 당혹감

놀랍게도, 지시를 내린 직후 AI는 900행이 넘는 코드를 작성해냈고, 한 번에 실행되는 MVP (Minimum Viable Product, 실용 최소 제품)를 전달해 주었습니다.

여기서 일종의 당혹감이 생깁니다. 「스스로 처음부터 시행착오를 겪으며 코드를 작성하던 시절의 손맛」이 어디에도 없습니다. 하지만 앱을 만지기 시작하자, 곧바로 「인간만이 할 수 있는 일」이 산더s처럼 나타났습니다.

• 「커밋 메시지를 전체 읽을 수 있도록 줄바꿈을 해줬으면 좋겠다」
• 「패널 리사이징이 안 되면 결국 스트레스가 쌓인다」
• 「특정 파일만의 차이점(diff)을 전환하고 싶다」
• 「아이콘이 있는 편이 시각적인 인지 비용이 낮아진다」
• 「스크롤바가 레이아웃의 부작용으로 사라져 버린 것을 고치고 싶다」

이것들은 AI가 생성한 「정답 같은 코드」를 「나의 도구」로서 생명력을 불어넣는 작업입니다. 한 번에 작동하는 코드가 나온 후, 이러한 세부 사항에 대한 「고집」스러운 수정이야말로, 지금 시대의 개발에 있어서의 장인 정신일지도 모릅니다.

5. 요약: AI 시대의 개인 개발에 있어서의 「활용술」

이번 체험을 통해 확신한 것은, AI는 단순한 「코딩 툴」이 아니라는 점입니다.

• 불만의 언어화: 자신이 느끼고 있는 「어딘가 모를 불편함」을 AI에게 던져, 과제로 승화시킨다.
• 설계의 브레인스토밍 (打ち合わせ): 기술 선정의 타당성을 AI와 논의하여 최적의 구성을 이끌어낸다.
• 디렉션: 작동하는 것이 나온 후, 자신의 「심미안」으로 철저하게 다듬어 올린다.

「직접 만들고 있다는 느낌」의 형태는 변했습니다. 하지만 그만큼 우리는 「어떤 도구가 자신에게 최고인가」를 고민하는 데 더 많은 시간을 쓸 수 있게 되었습니다.

Codex 데스크톱 버전이라는 강력한 파트너를 얻어, 여러분도 「자신만의 전용 도구」를 만들어 보시는 건 어떨까요?

이하 세션 로그입니다.

AI가 설계하고 있는 로그를 보니... 인간과 똑같다는 생각이 들어버렸습니다.

🧑💻 사용자

SourceTree의 대체라기보다, 모노레포 (Monorepo)에서 「폴더 단위의 Git 이력」을 보는 것에 특화된 작은 GUI 툴을 만들고 싶습니다.

MVP (Minimum Viable Product)는 로컬 Git 리포지토리 (Repository)를 열고 루트 직하 폴더를 선택하면,

git log -- <folder> 에 상당하는 이력이 표시되고, 커밋을 선택하면

변경 파일과 diff (차이점)가 보이는 것입니다.

먼저 기술 선정과 설계를 상담하고 싶습니다.

🤖 Codex

좋습니다. SourceTree 대체가 아니라 「모노레포의 특정 폴더 이력 뷰어」로 범위를 좁힌다면, 상당히 작고 기분 좋게 만들 수 있습니다. MVP의 핵심도 명확합니다.

저라면 우선 Tauri + React/TypeScript + Git CLI 를 제1후보로 꼽겠습니다.

추천 구성

• GUI: Tauri
• UI: React + TypeScript
• Git 조작: 우선은 git 커맨드 (Command) 호출
• 차이점 표시: monaco-editor 또는 react-diff-viewer 계열
• 상태 관리: 처음에는 React state / Zustand 정도
• 배포 대상: Windows 우선이라면 Tauri는 궁합이 매우 좋습니다.

이유는, Git 이력 뷰어는 「로컬 파일」, 「로컬 Git」, 「네이티브에 가까운 가벼움」이 중요하기 때문에, Electron보다 Tauri 쪽이 더 작게 시작하기 쉽기 때문입니다. Git 조작도 처음부터 libgit2 등을 포함하기보다는, Git CLI에 맞추는 편이 동작이 사용자의 기대와 일치하기 쉽습니다.

MVP 화면 설계

크게는 3-페인 (3-pane) 구조가 좋을 것 같습니다.

┌──────────────────────────────────────────────┐
│ Repository: C:\path\to\repo │
├───────────────┬──────────────────────────────┤
...

MVP에서는 루트 직하 폴더만 대상으로 하고, 나중에 packages/*나 임의의 경로 선택으로 확장하는 것이 좋다고 생각합니다.

Git 커맨드 설계

처음에는 이 정도면 충분합니다.

# 리포지토리 판정
git -C <repo> rev-parse --show-toplevel
# 루트 직하 폴더 목록
...

단, pretty=format은 파싱 (Parsing)이 깨지기 어렵도록 구분자를 고안하는 것이 좋습니다. 예를 들어 \x1f나 \x1e를 사용하는 식입니다.

아키텍처 (Architecture)

Tauri라면, Git 실행은 프론트엔드(Frontend)가 아니라 Rust 측의 커맨드 (Command)로 몰아넣고 싶습니다.

Frontend React
↓ invoke()
Tauri Rust commands
...

타입 (Type)은 대략 이렇습니다.

type RepoInfo = {
path: string;
root: string;
...

처음에 결정하고 싶은 설계 판단

가장 중요한 것은 「Git 이력의 의미」를 어디까지 정확하게 다룰 것인가입니다.

MVP에서는 git log -- <folder> 에 상당하는 수준이면 되지만, 장래에는 다음 사항들이 논점이 됩니다.

• 리네임 (Rename) 추적을 할 것인가: --follow는 단일 파일에 적합하며 폴더에는 특이한 점이 있습니다.
• 머지 커밋 (Merge Commit)을 어떻게 보여줄 것인가
• 거대한 diff를 어떻게 다룰 것인가
• 삭제된 폴더의 이력을 보고 싶은가
• 서브모듈 (Submodule)을 다룰 것인가
• 워크트리 (Worktree)의 커밋되지 않은 변경 사항도 볼 것인가

MVP에서는 다음과 같이 선을 긋는 것이 좋아 보입니다.

• 대상은 일반적인 로컬 Git 리포지토리
• 루트 직하의 현재 존재하는 디렉토리(Directory)만 표시
• 이력은 git log -- <folder>
• diff는 1개 커밋분만 표시
• 거대한 diff는 일정 사이즈에서 자름
• 커밋되지 않은 변경 사항은 대상에서 제외

제가 제안하는 초기 로드맵

• 리포지토리(Repository) 선택
• 루트 직하 폴더 목록 표시
• 폴더 선택 시 커밋 목록 표시
• 커밋 선택 시 변경 파일 목록 표시
• 파일 선택 또는 커밋 전체 diff 표시
• 검색, 작성자, 기간 필터는 나중에 처리

기술 선정으로는 저는 Tauri + React + Git CLI를 추천합니다.

"빠르게 MVP(Minimum Viable Product)를 만질 수 있는 형태로 만든다", "Git의 동작이 실제와 일치한다", "향후 Windows용으로 가볍게 배포할 수 있다"의 균형이 좋습니다.

🧑💻 사용자

우선 그것으로 만들어 보고 싶습니다

🤖 Codex

만들었습니다. Tauri + React/TypeScript + Git CLI 기반의 MVP로, 리포지토리를 열고, 루트 직하 폴더를 선택하며, git log -- <folder>에 해당하는 이력을 확인하고, 커밋 선택 시 변경 파일과 diff를 보는 부분까지 포함되어 있습니다.

주요 진입점은 src/App.tsx와 src-tauri/src/main.rs입니다.

환경 측면에서 한 가지 대응 사항으로, Tauri 최신 버전의 의존성이 Rust 1.88 이상을 요구했기 때문에, rustup update stable을 통해 로컬의 Rust stable을 1.95.0으로 업데이트했습니다. 다음으로는 실제 규모가 큰 모노레포(Monorepo)에서 테스트하며, diff 사이즈 제한, 파일 단위 diff 선택, 기간/작성자 필터 등을 추가하는 것이 좋을 것 같습니다.

13개의 파일이 변경되었습니다 (+992).

🧑💻 사용자

앱을 실행해서 동작을 확인하고 싶습니다

🤖 Codex

기동되었습니다. 상단의 「참조」에서 Git 리포지토리를 선택하고, 왼쪽의 루트 직하 폴더를 선택해 주세요. 커밋 목록, 변경 파일, diff가 표시된다면 MVP의 주요 경로를 통과한 것입니다.

🧑💻 사용자

커밋 메시지가 말줄임표(...)로 생략되는데, 전체 내용을 볼 수 있게 할 수 없나요?

🤖 Codex

대응했습니다. 커밋 메시지의 말줄임표 생략을 없애고, 여러 줄로 전체 내용이 표시되도록 했습니다.

변경 사항은 src/styles.css입니다.

🧑💻 사용자

앱을 실행해서 동작을 확인하고 싶습니다

🤖 Codex

업데이트된 앱을 재빌드하여 기동했습니다.

커밋 목록에서 긴 메시지가 줄바꿈되어 전체 내용이 표시되는지 확인해 보세요.

🧑💻 사용자

(이미지 첨부)

우측 상단의 파일을 클릭했을 때 해당 파일의 차분(diff)을 표시할 수 있게 할 수 없나요?

🤖 Codex

대응했습니다. 우측 상단의 Changed Files에서 각 파일을 클릭하면, 해당 파일만의 diff를 우측 하단에 표시합니다. 선택 중인 파일은 연한 파란색으로 하이라이트됩니다.

변경 사항은 src/App.tsx, src/styles.css, src-tauri/src/main.rs입니다.

🧑💻 사용자

앱을 실행해서 동작을 확인하고 싶습니다

🤖 Codex

업데이트된 앱을 재빌드하여 기동했습니다.

우측 상단의 Changed Files에서 파일을 클릭하면, 우측 하단의 Diff가 해당 파일의 내용으로 전환될 것입니다.

🧑💻 사용자

각 패널의 크기를 변경할 수 있게 할 수 없나요?

🤖 Codex

대응했습니다. 각 패널의 경계선을 드래그하여 크기를 변경할 수 있습니다.

• 폴더 목록과 커밋 목록 사이
• 커밋 목록과 우측 상세 페인(Pane) 사이
• 우측의 Changed Files와 Diff 사이

변경 사항은 src/App.tsx와 src/styles.css입니다.

🧑💻 사용자

앱을 실행해서 동작을 확인하고 싶습니다

🤖 Codex

업데이트된 앱을 재빌드하여 기동했습니다.

패널 사이의 가는 경계선을 드래그하면 좌우 폭과 우측 상하 높이를 변경할 수 있습니다.

🧑💻 사용자

앱 실행 시 화면 중앙에 표시되도록 해주세요.

🤖 Codex

대응했습니다. 실행 시 창이 화면 중앙에 나타나도록 src-tauri/tauri.conf.json의 window 설정에 center: true를 추가했습니다.

🧑💻 사용자

앱을 실행해서 동작을 확인하고 싶습니다

🤖 Codex

기동되었습니다. 창이 화면 중앙에 표시되는지 확인해 보세요.

🧑💻 사용자

🧑💻 사용자

다음 리포지토리(Repository)에 커밋(Commit), 푸시(PUSH)를 부탁합니다.

🤖 Codex

커밋하여 푸시했습니다.

• 리포지토리: my-proj/MonorepoViewer
• 브랜치: main
• 커밋:
  4ecxxxx

Initial monorepo viewer MVP

작업 트리(Working tree)도 깨끗합니다.

🧑💻 사용자

(이미지 첨부됨)

이런 느낌으로 차이점(Diff)을 보기 쉽게 만들 수 없을까요?

🤖 Codex

가능합니다. 그렇게 구현했습니다. 우측 하단의 diff 표시를 일반 텍스트에서 행 번호 포함, 덩어리(Hunk) 분할, 추가/삭제 색상 구분 표시로 변경했습니다. 파일 헤더도 표시되므로 커밋 전체 diff에서도 보기 편해졌습니다.

추가/변경한 주요 파일은 src/DiffViewer.tsx, src/diffParser.ts, src/App.tsx, src/styles.css입니다.

🧑💻 사용자

앱을 실행해서 동작 확인을 하고 싶습니다.

🤖 Codex

업데이트된 앱을 재빌드하여 기동했습니다.

첫 번째 빌드는 이전 앱이 실행 중이라 실행 파일(exe)을 잠그고 있었기에, 한 번 종료한 후 재빌드했습니다. 우측 하단의 diff가 행 번호 포함, hunk 분할, 추가/삭제 색상 구분으로 표시되는지 확인해 보세요.

🧑💻 사용자

우측 끝의 스크롤바가 사라져 버렸습니다. 수정할 때 지워버린 것 아닌가요?

🤖 Codex

말씀하신 대로, diff 뷰 개선 시에 "지운" 것은 아니지만, pre에서 div 기반의 구조화된 표시로 변경하면서 WebView 측에서 스크롤바 표시가 약해졌습니다. 그 부분을 수정했습니다.

변경 내용은 src/styles.css이며, 다음을 명시했습니다.

• 세로 스크롤바를 상시 확보
• diff 영역은 overflow-y: scroll
• 스크롤바 폭을 두껍게 설정
• 트랙(Track)과 핸들(Thumb)의 색상을 보이도록 조정

🧑💻 사용자

앱을 실행해서 동작 확인을 하고 싶습니다.

🤖 Codex

업데이트된 앱을 재빌드하여 기동했습니다.

우측 끝의 스크롤바가 폴더/커밋/변경 파일/diff 영역에서 보이는지 확인해 보세요.

🧑💻 사용자

앱을 실행해서 동작 확인을 하고 싶습니다.

🤖 Codex

업데이트된 앱을 재빌드하여 기동했습니다.

긴 diff 행이 있는 상태에서도 우측 하단 diff 패널의 우측 끝에 세로 스크롤바가 남아있는지 확인해 보세요.

🧑💻 사용자

파일 종류에 따라 아이콘을 표시하면 더 알기 쉽지 않을까요?

🤖 Codex

넣었습니다. Changed Files의 각 행에 확장자 기반의 아이콘을 표시합니다.

현재 분류는 대략 다음과 같습니다.

• 이미지: png, jpg, svg, ico 등
• 코드: ts, tsx, rs, cs, kt, dart, py 등
• 마크업/UI: html, css, xaml, xml 등
• 설정: toml, yaml, config, dotfile 등
• JSON/lockfile, DB, 텍스트, 기타

변경 사항은 src/App.tsx와 src/styles.css입니다.

🧑💻 사용자

앱을 실행해서 동작 확인을 하고 싶습니다.

🤖 Codex

업데이트된 앱을 재빌드하여 기동했습니다.

Changed Files의 경로 왼쪽에 파일 종류별 아이콘이 나오고 있는지 확인해 보세요.

🧑💻 사용자

아이콘이 나오게 되었는데, 다시 우측 끝의 스크롤바가 사라져 버렸습니다.

🤖 Codex

네, 다시 레이아웃 측의 부작용이었습니다. 아이콘 추가로 인해 Changed Files의 행이 3열 그리드(Grid)가 되면서, 행 요소가 부모 너비를 밀어내어 우측 끝의 스크롤 레인이 찌그러지는 케이스가 발생했습니다.

수정했습니다.

• 각 패널을 overflow: hidden으로 설정하여 자식 요소의 넘침을 방지
• .list / .file-list / .file-row를 width: 100%, min-width: 0, max-width: 100%로 고정
• 경로 문자열 열만 생략되도록 조정

변경 사항은 src/styles.css입니다.

🧑💻 사용자

앱을 실행해서 동작 확인을 하고 싶습니다.

🤖 Codex

업데이트된 앱을 다시 빌드하여 실행했습니다.

아이콘 표시가 있는 상태에서도 오른쪽 끝의 스크롤바가 각 패널에 남아 있는지 확인해 보세요.

🧑💻 사용자

일단 커밋(Commit) 및 푸시(Push) 부탁드립니다.

🤖 Codex

커밋하여 푸시(Push)했습니다.

• 커밋:
  6875684

Improve diff viewer and file list UI - Push 대상: origin/main

작업 트리(Working tree)도 깨끗합니다.

🧑💻 사용자

폴더를 선택하면 해당 폴더에 대해서도 커밋 로그를 알 수 있는데, 역시 전체 커밋 로그를 보고 싶다는 생각이 드네요.

🤖 Codex

대응했습니다. 왼쪽 폴더 목록의 맨 앞에 All을 추가하여, 그것을 선택하면 리포지토리(Repository) 전체의 커밋 로그를 표시합니다. 리포지토리를 연 직후에도 자동으로 All이 선택되어 전체 로그가 나오도록 했습니다.

폴더를 선택한 경우에는 기존과 동일하게 git log -- <folder>

All인 경우에는 git log에 해당합니다.

전체 로그입니다. 커밋 상세 내용도 All에서는 커밋 전체의 변경 파일/diff를, 폴더 선택 시에는 해당 폴더 내의 내용만 보여줍니다.

변경 사항은 src/App.tsx, src/styles.css, src-tauri/src/main.rs입니다.

🧑💻 사용자

앱을 실행해서 동작 확인을 하고 싶습니다.

🤖 Codex

업데이트된 앱을 다시 빌드하여 실행했습니다.

리포지토리를 열면 왼쪽 상단에 All이 나타나며, 초기 상태에서 전체 커밋 로그가 표시될 것입니다. 폴더를 선택하면 해당 폴더의 로그로 전환됩니다.

🧑💻 사용자

(이미지 첨부)

오른쪽 끝에 스크롤바가 나오게 할 수 없을까요?

🤖 Codex

수정했습니다. 오른쪽 상세 패널(Detail pane)이 긴 diff 행이나 파일 경로에 밀려 가로로 넓어지면서, 오른쪽 끝의 스크롤바가 화면 밖으로 벗어났던 것이 원인이었습니다.

대응 내용:

• detail-panel, file-pane, diff-pane을 부모 너비 내로 고정
• Changed Files와 Diff의 스크롤 영역을 width: 100% / min-width: 0 / overflow: hidden으로 제한
• diff 내부의 행이 부모 패널을 넓히지 않도록 조정

변경 사항은 src/styles.css입니다.

🧑💻 사용자

앱을 실행해서 동작 확인을 하고 싶습니다.

🤖 Codex

업데이트된 앱을 다시 빌드하여 실행했습니다.

오른쪽의 Changed Files와 Diff의 세로 스크롤바가 패널 오른쪽 끝에 표시되는지 확인해 보세요.

🧑💻 사용자

thx

🤖 Codex

다행입니다. 이것으로 일단락되었네요.

다음에 작업한다면, All과 폴더 이력 전환 기능이 추가되었으므로, 커밋 전에 한꺼번에 build / cargo check를 수행한 뒤 푸시(Push)하는 것이 좋을 것 같습니다.

🧑💻 사용자

그것도 부탁드립니다. 푸시(Push)까지 해주셨으면 좋겠어요.

🤖 Codex

커밋하여 푸시(Push)했습니다.

• 커밋:
  af7xxxx

Add repository-wide history view - Push 대상: origin/main

작업 트리(Working tree)도 깨끗합니다.

🧑💻 사용자

이 프로젝트에 대해 조금 알려주세요. Tauri는 데스크톱 앱으로 만들기 위해 사용하고 있는 거죠?

Rust는 왜 사용하고 있나요?

TypeScript로 완결될 수 있다고 생각했습니다. 저 자신이 그 부분의 장단점 같은 기술적인 내용은 잘 모르니 알려주셨으면 합니다.

🤖 Codex

네, 이해하신 내용이 거의 맞습니다. Tauri는 "React/TypeScript로 만든 화면을 데스크톱 앱으로 감싸기 위해" 사용합니다.

이 프로젝트에서 Rust를 사용하는 이유는, 간단히 말해 TypeScript만으로는 안전하게 다루기 어려운 "PC 본체 측의 작업"을 담당하기 위해서입니다.

이 앱에서는 역할이 다음과 같이 나뉘어 있습니다.

React + TypeScript
화면, 버튼, 리스트, 검색, diff 표시, 상태 관리
Rust / Tauri
...

실제로 src-tauri/src/main.rs

그러면 Rust가 git 명령어를 호출하고 있습니다. 예를 들어 open_repository, get_folder_history, get_commit_detail, get_file_diff와 같은 함수가 Rust 측에 있으며, TypeScript 측의 src/App.tsx에서 invoke("get_folder_history", ...)와 같이 호출하고 있습니다.

TypeScript 단독, 즉 일반적인 브라우저 앱이라면 보안상의 이유로 로컬 PC의 임의 폴더를 읽거나 git 명령어를 직접 실행할 수 없습니다. Tauri에서는 그 "브라우저 같은 UI"와 "OS에 가까운 처리" 사이의 가교 역할을 Rust가 수행합니다.

따라서 이 프로젝트에서 Rust는 복잡한 비즈니스 로직(Business Logic)용이라기보다,

"UI로부터 요청받은 일을 로컬 환경에서 안전하게 실행하는 작은 백엔드(Backend)"

라는 위치에 있습니다.

"TypeScript로 완결할 수 있지 않나요?"라는 느낌도 상당히 자연스럽습니다. 화면만 본다면 완결됩니다. 다만, 이 앱은 로컬의 Git 이력을 보기 때문에 git log나 git show를 실행해야 합니다. 그 지점부터는 브라우저/TypeScript의 전문 영역을 조금 벗어나기 때문에, Tauri의 Rust 측에 맡기고 있습니다.

Electron이라면 Node.js를 같은 역할로 사용하는 경우가 많습니다. Tauri는 그 백엔드 역할로 Rust를 사용하는 설계라고 이해하시면 됩니다.

🧑💻 사용자

Electron은 사용해 본 적이 있는데, 이번에 Tauri로 바꾸면 exe 하나로 배포가 끝나는 등의 이점이 있나요?

🤖 Codex

아마 Electron을 떠올리고 계신 것 같습니다. VS Code나 Slack 계열에서 자주 사용되는 것이죠.

결론부터 말씀드리면, Tauri로 만들면 "상당히 작고 배포하기 쉬운 exe"가 되기 쉽습니다. 다만, 엄밀하게 "항상 exe 1개만으로 완전히 완결된다"라고 단정 짓기에는 약간의 주의가 필요합니다.

이 프로젝트에서는 README에도 나와 있듯이, 빌드하면 우선 단일 실행 파일이 나옵니다.

src-tauri/target/release/monorepo-viewer.exe

따라서 개발자 관점에서는 "이 exe를 실행하면 앱이 동작한다"라는 형태에 가깝습니다.

Electron과의 큰 차이점은 이 부분입니다.

Electron
Chromium + Node.js를 앱에 동봉함
사이즈가 커지기 쉬움
...

즉, Tauri는 "브라우저 엔진을 통째로 들고 배포하는" 것이 아니라, Windows에 있는 WebView2를 사용합니다. 그만큼 exe나 설치 프로그램이 가벼워지기 쉽습니다.

하지만 주의점도 있습니다.

• Windows 측에 Microsoft Edge WebView2 Runtime이 필요함 (대부분의 환경에는 이미 설치되어 있음)
• 이미지, DB, 외부 도구 등을 별도 파일로 가지는 설계로 할 경우, exe 단독으로 끝나지 않는 경우도 있음
• 이 앱은 로컬의 git CLI를 호출하므로, 이용하는 PC에 Git이 설치되어 있다는 전제가 필요함

이번 Monorepo Viewer의 경우, Tauri를 선택하는 이점은 상당히 많습니다.

• Git 이력 뷰어이므로 로컬 파일이나 git 명령어에 접근할 필요가 있음
• 웹 앱보다 자연스럽게 로컬 PC와 연동할 수 있음
• Electron보다 경량화된 배포물이 되기 쉬움
• React + TypeScript의 UI 자산을 그대로 사용할 수 있음
• Rust 측은 얇은 "로컬 명령 대행자" 역할만으로 충분함

그래서 이미지로 표현하자면,

Electron:
TypeScript/Node.js로 전부 하기 쉽지만, 배포물은 큼
Tauri:
...

라는 느낌입니다. 이번 용도라면 Tauri는 궁합이 매우 좋습니다.

🧑💻 사용자

일반적인 이야기를 알려주세요. 제가 Rust의 쓰임새를 이해하지 못해서, 학습해도 어디에 써야 할지 모르겠다고 생각했거든요. 이번처럼 데스크톱 앱에 사용하는 것이 일반적인가요? 배포 대상 PC에 Rust가 설치되어 있어야 하지는 않나요?

🤖 Codex

네, 이번처럼 데스크톱 앱의 뒷단(Backend)에 Rust를 사용하는 것은 상당히 일반적인 일이 되어가고 있습니다. 특히 Tauri를 사용한다면 Rust는 표준적인 구성입니다.

중요한 부분부터 말씀드리자면, 배포 대상 PC에 Rust는 필요하지 않습니다.

Rust는 「개발·빌드하는 사람의 PC」에 필요합니다. 빌드하면 Rust 코드는 .exe 안에 컴파일됩니다. 배포 대상(配布先)에서는 Rust 컴파일러나 Cargo는 필요하지 않습니다.

개발 PC:
Rust가 필요함
cargo build / tauri build로 exe를 생성
...

Tauri의 경우, 배포 대상에서 필요할 수 있는 것은 Rust가 아니라, Windows라면 WebView2 Runtime입니다. 이는 최근의 Windows 환경이라면 대부분 설치되어 있습니다.

Rust의 사용처는 대략 말하자면 「OS에 가까운 처리」 「속도가 필요한 처리」 「고장 나면 곤란한 기반 부분」 입니다.

예를 들어 다음과 같은 곳에서 자주 사용됩니다.

데스크톱 앱:
Tauri의 백엔드 (Backend)
파일 조작, 프로세스 실행, OS 연동
...

반대로, React 화면을 만들기만 하거나, 관리 화면을 만들기만 하거나, 간단한 Web API를 빠르게 만들기만 한다면 Rust일 필요성은 낮습니다. TypeScript, Python, Go, C# 등이 더 편한 경우도 많습니다.

Rust의 강점은 이 지점에 있습니다.

빠름 — C/C++에 가까운 성능을 내기 쉬움 -
배포 용이 — 단일 exe로 만들기 쉬움 -
메모리 안전 (Memory Safety) — C/C++ 같은 영역을 다루면서도, 위험한 버그를 컴파일 시점에 방지하기 쉬움 -
병렬 처리 (Concurrency)에 강함 — 여러 처리를 안전하게 실행하기 쉬움 -
런타임 (Runtime)이 가벼움 — Node.js나 .NET 같은 거대한 실행 환경에 의존하지 않기 쉬움