최근 Fizzy 를 개인 서버로 옮겨 쓰는 경험을 해봤어요.
결론부터 말하면, “이 정도까지 잘 정리된 Rails 오픈소스가 흔할까?” 싶을 정도로 만족스러운 경험이었어요.
Fizzy는 목표(goal)와 작업(task)을 아주 단순한 카드(card) 단위로 관리하는 서비스예요.
복잡한 기능 대신 의도적으로 덜어낸 UX가 인상적인 서비스죠.
클라우드(SaaS) 버전 제공
동시에 소스 코드 공개 (O’Saasy License 적용) -> SaaS로 원저작자와 직접 경쟁하는 것은 금지되어 있어, 전통적인 오픈소스와는 다름
self-hosted 버전은 무료 (개인/회사 내부 용도)
클라우드 버전은 카드 생성/삭제 포함 1,000장 초과 시 월 $20로 unlimited
처음에는 클라우드 버전으로 약 30개 정도의 카드만 가볍게 써봤는데, 이 “이 정도면 충분하다”는 감각이 너무 마음에 들었어요.
그래서 자연스럽게 self-hosted로 이어졌습니다.
Fizzy는 37signals 가 만든 서비스답게, 레포지토리 자체가 하나의 Rails 운영 가이드처럼 느껴졌어요.
Ruby on Rails 기반
Kamal 배포 가이드 제공
Docker 실행 방법도 문서로 정리되어 있음
이미 Kamal 배포 경험이 있었던 터라, 가이드만 따라가니 큰 시행착오 없이 서버에 띄울 수 있었어요.
“아, 이래서 37signals가 Rails의 원조구나” 라는 생각이 절로 들더라고요.
Fizzy는 이메일 기반 magic link 로그인 방식을 사용해요. 그래서 배포 과정에서 가장 중요한 설정은 SMTP였어요.
저는 개인 용도라서 Mailgun 의 테스트용 sandbox 계정을 사용했어요. 설정 자체는 아주 간단했지만 실제 로그인 이메일 도메인이 다르다 보니 스팸함으로 빠지는 문제가 있었어요.
당장은 문제 없었지만, 장기적으로는 자체 도메인 + 정상 발송 주소로 바꿀 예정이에요.
여기까지는 정말 막힘 없이 진행됐어요. 그런데 딱 하나, 아쉬웠던 점이 있었어요.
클라우드 버전에서 export한 데이터를 self-hosted 버전으로 import하는 기능이 없다는 점이에요.
GitHub Discussion에서 확인해보니 2024년 12월부터 개발 중이라는 코멘트가 있었고, 코멘트가 달린지 한 달쯤 지난 시점이라 문의를 해보니 아직 개발 중이라는 답변을 받았어요.
그래서 개인 용도로 쓰기 위해 직접 rake task를 하나 만들었습니다.
클라우드에서 export한 데이터를 self-hosted DB 구조에 맞게 변환해서 문제없이 import 성공했고, 구체적인 데이터 구조 파악은 claude code를 통해서 진행하니 정말 빠르게 구현할 수 있었어요.
코드는 여기에서 볼 수 있어요.
이 덕분에 클라우드에서 쓰던 흐름을 그대로 이어갈 수 있었고, self-hosted로 옮기길 잘했다는 확신도 들었어요.
Fizzy 오픈 소스에 직접 기여하고 싶기도 했지만 아직 마땅히 기여 포인트를 찾지는 못했어요.
그래도 이렇게 실제로 써보고 부족한 부분을 직접 만들고 필요하면 다시 고쳐보고 이 과정을 반복하다 보니, 언젠가는 자연스럽게 기여할 수 있는 날도 오지 않을까 하는 기대감이 생기더라고요.
Fizzy를 self-hosted로 옮기고 나니, 이 서비스를 단순한 “목표 관리 도구”를 넘어서 앞으로 할 일들을 쌓아두는 기반 데이터베이스로 써보고 싶다는 생각이 들었어요.
Fizzy의 card 모델은 생각보다 범용적이에요.
goal / task 구조가 단순하고
상태 변화가 명확하며
불필요한 메타데이터가 거의 없어서
앞으로 내가 하는 일들을 가장 작은 단위로 저장하기에 꽤 좋은 형태라고 느꼈어요.
그래서 이후에는 Fizzy를
“내가 하는 모든 일의 최소 단위 저장소”
처럼 두고, 그 위에 표현 방식만 바꿔보는 시도를 해보고 싶어요.
개인적으로 철학과 UI가 정말 마음에 들지만, 가격 때문에 계속 결제해서 쓰지는 못하고 있는 서비스가 있어요.
바로 Timestripe예요.
장기 목표를 시간 축으로 정리하고, 지금 해야 할 일을 자연스럽게 연결해주는 UX는 정말 인상적인데, 개인 용도로 쓰기엔 비용이 늘 아쉬웠어요.
그래서 떠올린 다음 단계는,
Fizzy를 백엔드(데이터 저장소)로 두고 Timestripe 스타일의 UI를 직접 만들어서 써보는 것
이에요.
구조적으로는
Fizzy는 변하지 않는 데이터의 원천(source of truth)
UI는 언제든 바꿀 수 있는 표현 레이어
로 두고, 내 작업 방식에 맞게 시간 축 기반 UI를 실험해보려는 계획이에요.
Fizzy를 self-hosted로 옮긴 경험은 단순히 “월 $20을 아끼기 위해서”라기보다는,
Rails로 잘 만든 서비스는 어떤 모습인지
운영까지 고려한 오픈소스는 무엇이 다른지
단순함을 지키는 제품 철학이 얼마나 중요한지
를 다시 한 번 느끼게 해준 시간이었어요.
아직은 개인 실험 단계지만, 이렇게 직접 써보고 확장해보는 경험이 쌓이다 보면 언젠가는 더 자연스럽게 오픈소스에 기여할 수 있지 않을까 조심스럽게 기대해봅니다.
]]>I recently had the experience of moving Fizzy to my personal server.
To cut to the chase, it was such a satisfying experience that I thought, “How often do you find a Rails open-source project this well-organized?”
Fizzy is a service that manages goals and tasks in very simple card units.
What’s impressive is its intentionally minimal UX instead of complex features.
Cloud (SaaS) version available
Source code publicly available (O’Saasy License)
→ Competing directly with the original author as a SaaS is prohibited, so it differs from traditional open source
Self-hosted version is free (for personal/internal company use)
Cloud version
→ $20/month for unlimited when exceeding 1,000 cards (including creation/deletion)
I initially tried the cloud version lightly with about 30 cards, and I really liked this sense of “this is enough.”
That naturally led me to self-hosting.
As a service made by 37signals, Fizzy’s repository felt like a Rails operations guide in itself.
Based on Ruby on Rails
Kamal deployment guide provided
Docker execution method documented as well
Since I already had experience with Kamal deployment, following the guide allowed me to get it running on my server without major issues.
It made me think, “Ah, so this is why 37signals is the origin of Rails.”
Fizzy uses an email-based magic link login method. So the most important configuration during deployment was SMTP.
Since it was for personal use, I used Mailgun’s test sandbox account. The setup itself was very simple, but since the actual login email domain was different, there was an issue with emails going to spam.
It wasn’t a problem for now, but I plan to switch to a custom domain + proper sending address in the long run.
Up to this point, everything went smoothly. But there was one thing that was disappointing.
There’s no feature to import data exported from the cloud version into the self-hosted version.
Checking the GitHub Discussion, I found a comment saying it’s been in development since December 2025, and when I inquired about a month after that comment, I received a response that it’s still in development.
So for personal use, I built my own rake task.
I converted the data exported from the cloud to match the self-hosted DB structure and successfully imported it. Using Claude Code to understand the specific data structure made implementation really fast.
You can see the code here: https://github.com/leegeng/fizzy/blob/main/lib/tasks/import.rake
Thanks to this, I could continue the workflow I had in the cloud, and I was convinced that moving to self-hosted was the right choice.
I wanted to contribute directly to Fizzy’s open source, but I haven’t found a suitable contribution point yet.
Still, through this cycle of actually using it, building missing parts myself, and fixing things as needed, I started to feel hopeful that someday I’ll naturally be able to contribute.
After moving Fizzy to self-hosted, I started thinking about using this service not just as a “goal management tool” but as a foundational database for storing things to do.
Fizzy’s card model is more versatile than expected.
Simple goal/task structure
Clear state changes
Almost no unnecessary metadata
I felt it’s a pretty good format for storing what I do in the smallest units.
So from now on, I want to think of Fizzy as
“The minimum unit storage for everything I do”
and try changing only the presentation layer on top of it.
There’s a service whose philosophy and UI I really love, but I can’t keep paying for due to the price.
It’s Timestripe.
The UX that organizes long-term goals on a time axis and naturally connects them to what needs to be done now is really impressive, but the cost has always been a concern for personal use.
So the next step I came up with is:
Use Fizzy as the backend (data storage) and build a Timestripe-style UI myself to use
Structurally:
Fizzy as the unchanging source of truth
UI as a presentation layer that can be changed anytime
With this approach, I plan to experiment with a time-axis-based UI tailored to my work style.
The experience of moving Fizzy to self-hosted wasn’t simply about “saving $20 a month,” but rather:
What a well-made Rails service looks like
What makes open source that considers operations different
How important a product philosophy of maintaining simplicity is
It was a time that reminded me of all these things once again.
It’s still at a personal experiment stage, but as I accumulate experiences of actually using and extending things like this, I cautiously hope that someday I’ll be able to contribute to open source more naturally.
]]>最近、Fizzy を個人サーバーに移行して使う経験をしました。
結論から言うと、「ここまで整理されたRailsオープンソースはなかなかないのでは？」と思うほど満足のいく経験でした。
Fizzyは目標（goal）とタスク（task）を非常にシンプルなカード（card）単位で管理するサービスです。
複雑な機能の代わりに意図的に削ぎ落としたUXが印象的なサービスです。
クラウド（SaaS）版を提供
同時にソースコード公開（O’Saasy License適用）
→ SaaSとして原著作者と直接競合することは禁止されているため、従来のオープンソースとは異なる
セルフホスト版は無料（個人/社内用途）
クラウド版は
→ カード作成/削除含め1,000枚超過で月額$20でunlimited
最初はクラウド版で約30枚程度のカードを軽く試してみましたが、この「これで十分だ」という感覚がとても気に入りました。
それで自然とセルフホストに移行することになりました。
37signals が作ったサービスらしく、Fizzyのリポジトリ自体が一つのRails運用ガイドのように感じられました。
Ruby on Railsベース
Kamalデプロイガイド提供
Dockerの実行方法もドキュメント化されている
すでにKamalデプロイの経験があったので、ガイドに従うだけで大きな試行錯誤なくサーバーに立ち上げることができました。
「ああ、だから37signalsがRailsの元祖なんだな」という考えが自然と浮かびました。
Fizzyはメールベースのmagic linkログイン方式を使用しています。 そのため、デプロイ過程で最も重要な設定はSMTPでした。
個人用途なのでMailgun のテスト用sandboxアカウントを使いました。 設定自体はとても簡単でしたが、実際のログインメールドメインが異なるため、スパムフォルダに入る問題がありました。
当面は問題ありませんでしたが、長期的には独自ドメイン+正規の送信アドレスに変更する予定です。
ここまでは本当にスムーズに進みました。 しかし、一つだけ残念な点がありました。
クラウド版からexportしたデータをセルフホスト版にimportする機能がないという点です。
GitHub Discussionで確認したところ、2025年12月から開発中というコメントがあり、そのコメントから約1ヶ月経った時点で問い合わせたところ、まだ開発中という回答を受けました。
そこで個人用途で使うために自分でrake taskを一つ作りました。
クラウドからexportしたデータをセルフホストのDB構造に合わせて変換し、問題なくimport成功しました。具体的なデータ構造の把握はClaude Codeを通じて行ったので、本当に速く実装できました。
コードはこちらで見られます： https://github.com/leegeng/fizzy/blob/main/lib/tasks/import.rake
これのおかげでクラウドで使っていたワークフローをそのまま継続でき、セルフホストに移行して良かったという確信も得られました。
Fizzyのオープンソースに直接貢献したいとも思いましたが、まだ適切な貢献ポイントを見つけられていません。
それでも、実際に使ってみて、足りない部分を自分で作って、必要なら修正して、このサイクルを繰り返していると、いつかは自然と貢献できる日が来るのではないかという期待感が生まれました。
Fizzyをセルフホストに移行してみると、このサービスを単なる「目標管理ツール」を超えて、これからやることを蓄積する基盤データベースとして使ってみたいという考えが浮かびました。
Fizzyのcardモデルは思ったより汎用的です。
goal / task構造がシンプル
状態変化が明確
不要なメタデータがほとんどない
これから私がやることを最小単位で保存するのにかなり良い形態だと感じました。
そこで今後はFizzyを
「私がやる全てのことの最小単位ストレージ」
として位置づけ、その上で表現方法だけを変える試みをしてみたいです。
個人的に哲学とUIがとても気に入っているけど、価格のせいで継続して課金して使えていないサービスがあります。
それはTimestripeです。
長期目標を時間軸で整理し、今やるべきことを自然につなげてくれるUXは本当に印象的ですが、個人用途で使うには費用がいつも気になっていました。
そこで思いついた次のステップは、
Fizzyをバックエンド（データストレージ）として置いて TimestripeスタイルのUIを自分で作って使うこと
です。
構造的には
Fizzyは変わらないデータの原典（source of truth）
UIはいつでも変更可能な表現レイヤー
として位置づけ、私の作業スタイルに合わせて時間軸ベースのUIを実験してみる計画です。
Fizzyをセルフホストに移行した経験は、単純に「月$20を節約するため」というよりは、
Railsでうまく作られたサービスはどんな姿か
運用まで考慮したオープンソースは何が違うのか
シンプルさを守る製品哲学がどれほど重要か
を改めて感じさせてくれた時間でした。
まだ個人的な実験段階ですが、このように実際に使って拡張してみる経験を積み重ねていけば、いつかはもっと自然にオープンソースに貢献できるのではないかと、控えめに期待しています。
]]>이전에 스크린세이버 문제로 Omarchy 설치만 해놓고 제대로 사용하지 못했었는데, 최근 3.0이 나오면서 자체 ISO 파일을 제공하여 설치가 훨씬 간편해졌다는 소식을 듣고 재도전하게 되었어요.
새로운 설치 과정은 정말 간편했고 화면도 매우 유려해서 인상 깊었는데, 설치 후 예상치 못한 네트워크 문제가 발생했어요. 같은 문제를 겪으실 분들을 위해 해결 과정을 정리해봤어요.
환경: iMac 27” 5K 2015 Late, 유선 네트워크 연결
설치 환경은 랜선으로 네트워크를 연결해 놓은 상황이었고, 설치 과정에서도 업데이트를 잘 받아왔기 때문에 네트워크 자체에는 문제가 없었어요. 하지만 설치 완료 후 다음과 같은 문제가 발생했어요:
ping 8.8.8.8은 성공하지만 ping google.com은 실패즉, 물리적인 연결과 IP 할당은 정상이었지만 DNS 해석에 문제가 있다는 것으로 문제 범위를 좁힐 수 있었어요.
ChatGPT를 활용해서 다음과 같은 절차로 상태를 확인해봤어요.
Omarchy 문서에는 네트워크와 관련해서 iwctl 내용이 있는데, 사실 이 명령어는 무선 네트워크를 관리하는 것이기 때문에 현재 문제와는 무관했어요. systemd-networkd와 systemd-resolved 서비스들은 정상 동작하는 것으로 보였어요.
systemctl status systemd-resolved
확인 결과 ISP DNS 서버는 잘 잡혀있는 상태였어요. 하지만 여전히 도메인 이름 해석이 실패하고 있었어요.
hosts 라인에 mdns_minimal [NOTFOUND=return]이 resolve보다 앞에 들어있어서 mDNS 단계에서 멈추고 일반 DNS까지 요청이 가지 않을 수 있을 것 같다는 추정을 했어요. hosts 라인에서 mdns_minimal 관련 속성을 제거하고 resolve를 앞으로 당겨봤어요.
status에서 볼 수 있는 로그를 확인한 결과 “DNSSEC validation failed” 메시지를 발견했어요. 이것이 핵심 문제였어요.
결론적으로 실제 문제 해결에 도움이 된 변경사항은 DNSSEC 비활성화였어요.
/etc/systemd/resolved.conf 파일을 다음과 같이 편집했어요:
[Resolve]
DNS=8.8.8.8 1.1.1.1
DNSSEC=no
설정 변경 후 systemd-resolved 서비스를 재시작해요:
sudo systemctl restart systemd-resolved
이렇게 DNSSEC을 비활성화하니 네트워크가 정상적으로 작동하기 시작했어요.
Omarchy 3.0으로 업그레이드하면서 기존에는 없던 문제가 발생해서 다른 분들도 겪을 것 같아 해결 방법을 정리해봤어요.
앞으로 한국에도 Omarchy 커뮤니티가 좀 더 활발해지면 좋겠네요.
]]>지난 글 (AI로 코드 작성 생산성 향상하기: Cursor, Devin, Cline 비교 분석)에 이어서 최근(2025년 9월)에 사용하고 있는 AI 도구들에 대해 정리해보려고 해요.
불과 5개월 전인 2025년 4월에 Cursor, Devin, Cline을 비교하는 글을 썼었는데요. 그때는 Cline과 Cursor를 조합해서 쓰면 좋겠다고 생각했었어요. 그런데 지금은 완전히 새로운 도구들을 사용하고 있어서, 기술의 변화가 정말 빠르다는 걸 새삼 느끼게 돼요.
현재는 Claude Code와 Codex, Gemini Code Assist를 적절히 섞어서 사용하고 있어요.
가장 자주 함께 작업하는 도구는 Claude Code예요. Opus4 모델을 사용하면서 훨씬 납득이 가고 퀄리티 높은 코드를 얻을 수 있게 됐어요. 특히 구조가 어느 정도 잡혀있는 monorepo 형태의 프론트엔드 레포지토리에서 큰 도움을 받고 있어요.
회사에서는 10년이 넘은 Ruby on Rails 레포지토리를 메인으로 유지보수하고 개발하고 있는데요. 이런 대규모 레거시 환경에서는 전체 코드 컨텍스트를 모두 담으려 하지 않고, 동료들이 잘 정의해준 CLAUDE.md를 기반으로 설정된 룰을 활용하고 있어요.
핵심은 태스크의 단위를 작게 잡는 것이에요. 예를 들어 하나의 피쳐를 구현할 때, 기본적인 껍데기는 제가 주석과 함께 잡아두고, Claude Code에게 주석에 있는 내용을 구현하도록 유도해요. 상호 참조되는 클래스가 많아지거나 복잡도가 올라가는 신호(너무 오래 코드를 수정하거나, 변경되는 파일이나 라인 수가 급격히 늘어나는 경우)가 보이면 태스크를 중단하고 더 디테일하게 설명하거나 스코프를 줄여요.
최근에는 실험적으로 모듈 단위별로 README.md를 작성해서 구현하는 피쳐의 맥락을 남겨두고 있어요. LLM이 이 맥락을 명시적으로 사용하도록 지시하면 더 나은 결과를 얻을 수 있고, 추가 수정이 발생할 때마다 해당 문서를 업데이트하게 해서 코드와 문서가 함께 관리되는 점이 좋아요. 무엇보다 사람이 이해할 수 있는 문서를 남기는 것이 결과적으로 LLM에게도 도움이 된다고 생각해요.
Codex는 OpenAI에서 제공하는 도구로, 과거 글에서 언급했던 Devin과 비슷한 역할을 해요. 하지만 퀄리티와 가격 면에서 정말 큰 차이를 보여주고 있어요. ChatGPT Plus 요금으로도 이 기능을 사용할 수 있어서 가성비가 좋아요.
주로 개인 프로젝트의 작은 기능들을 비동기로 지시해서 초안을 만들게 하는 용도로 사용하고 있어요. 개인 프로젝트는 코드베이스가 작고 도메인이 명확하기 때문에 AI 도구가 작성해주는 코드의 범위가 그리 크지 않아서 이런 방식이 효과적이에요.
실제 사용 패턴을 보면, 출근하다가 “이 기능 필요할 것 같은데”라는 생각이 들면 메모해둬야 까먹고 안하게 되니까, 그냥 생각나는 대로 프롬프트를 작성해서 바로 시켜버려요. 결과물이 항상 완벽하지는 않지만, 그래도 초안을 잡아준 상태에서 해당 브랜치를 체크아웃 받아서 조금 수정하면서 다듬다 보면 생각만 하고 지나칠 뻔한 기능들을 작은 부분이라도 실제로 구현할 수 있는 게 큰 장점이에요.
작업이 끝나면 GitHub PR로 올려서 코드 리뷰와 약간의 수정을 통해 프로젝트를 조금씩 성장시키는 데 큰 도움이 되고 있어요.
Gemini Code Assist는 테스트 삼아 사용해보고 있어요. 코드 베이스가 구글에 공유되어도 크게 문제없는 개인 프로젝트에서만 사용하고 있고요. GitHub 연동이 정말 쉬워서 시도해볼 만해요.
PR이 생성되면 자동으로 코드 리뷰를 해주는 도구인데, CodeRabbit의 대안으로 생각하면 돼요. 아직까지는 퀄리티도 괜찮게 느껴지고 있고, 무료라는 점도 큰 장점이에요. 특히 코멘트에 Priority를 표기해주는 기능이 정말 마음에 들어요.
Claude Code도 GitHub 연동을 하면 Gemini Code Assist와 똑같은 역할을 할 수 있어요. 다만 기본 설정으로는 PR에 코드 라인마다 코멘트를 해주는 기능이 조금 다른 설정이 필요한 것 같고, 대략적인 요약을 해주는 정도라서 지켜보고 있어요.
좋은 점 하나는 Gemini Code Assist가 작성한 코멘트에 Claude를 호출해서 바로 수정을 지시할 수 있다는 거예요.
정리하면 이런 식으로 사용하고 있어요:
회사 업무: Claude Code를 주력으로 사용
개인 프로젝트: Codex를 비동기로 활용하면서, 직접 작업할 때는 Claude Code 사용
코드 리뷰: Gemini Code Assist와 Claude Code를 동시에 활용
이런 역할 분담을 하는 이유는 코드베이스의 규모와 특성 때문이에요. 회사의 방대한 레거시 코드베이스에서는 비동기로 태스크를 맡겨서 해결하기에는 적합하지 않고, 세밀한 지시와 단계적 접근이 필요해요. 반면 개인 프로젝트는 바쁠 때 직접 개발할 시간이 부족하기도 하고, 코드베이스가 작고 도메인이 명확해서 AI 도구가 비교적 안전하게 큰 단위의 작업을 해낼 수 있거든요.
몇 개월 뒤에는 또 어떻게 환경이 바뀌어 있을지 모르겠어요. 하지만 소프트웨어 엔지니어로서 이런 변화에 꾸준히 적응하고 따라가다 보면, 과거의 퍼포먼스와 비교했을 때 그때는 상상도 할 수 없었던 일들을 해내고 있을 거라고 생각해요.
AI 도구들을 사용하면서 느낀 점은, 각 도구의 특성을 파악하고 프로젝트의 규모와 성격에 맞게 적재적소에 활용하는 것이 가장 중요하다는 거예요. 대규모 레거시 코드에서는 세밀한 컨트롤이 필요하고, 작은 개인 프로젝트에서는 과감한 위임이 효과적이죠.
또한 AI 도구를 위한 특별한 문서화보다는, 사람이 이해할 수 있는 좋은 문서를 작성하는 것이 결국 AI에게도 도움이 된다는 점도 중요한 깨달음이었어요. 기술은 빠르게 변하지만, 좋은 소프트웨어를 만들기 위한 본질적인 원칙들은 여전히 유효하다고 생각해요.
]]>개발자로 일하다 보면 새로운 기능을 만들 때마다 당연하게 어드민 페이지를 만들어요. 사용자 관리, 데이터 모니터링, 기능 토글 등 서비스 운영에 필요한 모든 것들을 한눈에 보고 관리할 수 있도록 말이에요. 팀원들과 함께 기능을 개발하고 개선해나가는 데 어드민만큼 중요한 도구는 없다고 생각해요.
그런데 문득 이런 생각이 들었어요. 회사 업무에는 이렇게 체계적인 관리 도구를 잘 만들면서, 정작 내 개인 생활은 여전히 반복적인 수작업으로 가득하다고 느꼈어요.
매주 같은 사이트들을 돌아다니며 정보를 수집하고, 같은 형태의 작업을 반복하고, 구독 서비스들을 일일이 확인하며… 이런 일들을 하면서도 자동화해야겠다는 생각은 미뤄두고 있었어요.
요즘은 ChatGPT부터 시작해서 Cursor, Claude Code, Lovable 등 정말 다양한 AI 도구들이 나오고 있어요. 개발 생산성도 크게 향상되었고, 바이브 코딩 코딩으로 바로바로 원하는 기능을 만들어볼 수 있는 시대가 되었어요. 그렇다면 이런 도구들을 활용해서 회사 업무뿐만 아니라 내 일상도 좀 더 효율적으로 만들 수 있지 않을까요? 개인 맞춤형 자동화 시스템을 구축해서 반복 작업을 줄이고, 더 중요한 일에 시간을 쓸 수 있도록 말이에요.
이런 생각으로 시작한 프로젝트가 바로 ‘Stark Desk’예요. 토니 스타크의 자비스처럼은 아니더라도, 내 일상의 반복 작업들을 자동화해주는 개인용 어드민 시스템을 만들어보자는 목표로 시작했어요. (이름은 토니 스타크를 따라한 건 아니고, 회사에서 사용하는 영어 이름이에요 😅)
첫 번째로 만든 기능은 매주 발행하는 Ruby on Rails 뉴스레터를 위한 도구였어요. 기존에는 여러 사이트를 직접 돌아다니며 소식을 찾고, 하나씩 정리하는 작업을 반복했어요. 시간도 오래 걸리고 놓치는 소식들도 많았죠. 내용의 인사이트를 뽑고 생각을 정리하기보다는, 또 괜찮은 소식이 없으려나 하는 생각이 더 컸던 것 같아요.
이제는 미리 등록해둔 소스들에서 자동으로 정보를 수집하고, AI가 1차적으로 내용을 요약해서 후보를 뽑아줘요. 선택된 후보들은 자동으로 데이터베이스로 정리되어 들어가고, 제가 마무리로 약간의 수정을 통해 뉴스레터 준비가 완료되죠.
뉴스레터 도구가 어느 정도 안정화되고, 좀 더 발전된 기능을 추가했어요. 바로 개인 맞춤형 뉴스 피드예요. 여기서 가장 재미있고 기대하는 부분은 임베딩을 활용한 개인화예요:
이 기능 덕분에 업계 동향을 파악하는 시간이 크게 줄어들었고, 뉴스레터 소재 발굴도 훨씬 효율적이 되었어요.
AI 도구들이 늘어나면서 구독 서비스 지출도 함께 늘어나더라고요. ChatGPT Plus, Cursor Pro, Claude Pro, 각종 SaaS 도구들… 어느새 월 구독료가 상당한 금액이 되었어요.
그래서 마지막으로 추가한 기능이 구독 서비스 관리 도구예요. 각 서비스의 구독 현황을 한눈에 보고, 갱신일을 미리 알림받을 수 있도록 만들었어요. 무엇보다도 현황을 보면서 불필요해진 서비스를 까먹지 않고 해지할 수 있는 환경이 된 점이 가장 중요하다고 생각했어요.
아직 모든 기능이 100% 완성된 것은 아니지만, 예전에는 소재 준비부터 발송까지 3시간은 걸렸던 뉴스레터 발송 준비 시간을 이제 2시간 이내로 줄였고, 그만큼 콘텐츠 퀄리티에 집중할 수 있게 되었어요.
프로젝트에 사용한 주요 기술들을 간단히 소개하면:
| 범주 | 사용 도구 |
|---|---|
| 백엔드 | Ruby on Rails |
| 프론트엔드 | TailwindCSS 4 |
| DB | Sqlite3 |
| 벡터 DB | Pinecone (무료 플랜) |
| 임베딩 | Vertex AI text-multilingual-embedding |
| 개발 도우미 | Cursor, Claude Code, CodeRabbit 등 |
개인 프로젝트라서 다양한 AI 도구들을 자유롭게 실험해볼 수 있는 좋은 환경이었어요.
“나도 만들어보고 싶다”고 생각하신다면, 다음과 같은 순서로 시작해보시길 추천해요.
먼저 일상에서 반복하고 있는 작업들을 찾아보세요. 매일/매주 같은 사이트 확인하기, 동일한 형태의 데이터 정리 작업, 정기적인 리마인더가 필요한 일들, 여러 서비스를 오가며 하는 작업들 등이 좋은 후보예요.
그 다음에는 가장 간단한 것부터 시작하세요. 거창한 기능을 만들려고 하지 마세요. 성취감과 지속 가능성이 더 중요해요. Stark Desk도 처음에는 뉴스 소스를 단순히 나열하는 것부터 시작했어요. 그 다음에 AI 요약 기능을 추가하고, 개인화 기능을 넣고… 이런 식으로 점진적으로 발전시켜 나갔어요.
요즘 나오는 AI 개발 도구들을 활용하면 혼자서도 충분히 복잡한 기능을 만들 수 있어요. 완벽한 코드를 처음부터 작성하려고 하지 말고, AI와 함께 빠르게 프로토타입을 만들어보세요.
마지막으로는 꾸준함과 일단 시도하는 것이 중요하다고 생각해요. 단기적으로 큰 효과를 기대하기보다는, “토니 스타크의 자비스로 나아갈 수 있는 코드 한 줄을 꾸준히 만들어간다”는 마음가짐으로 접근해보세요. 작은 자동화 하나하나가 쌓여서 결국 내 일상을 크게 바꿀 수 있을 거예요.
AI 도구들이 이렇게 발달한 시대에 우리는 정말 많은 것들을 시도해볼 수 있게 되었어요. 회사에서 멋진 서비스를 만드는 것도 좋지만, 내 생활을 조금 더 편하게 만들어주는 도구를 직접 만들어보는 것은 어떨까요?
기획서도, 거창한 목표도 필요 없어요. 오늘 내가 반복하고 있는 작업 하나를 찾아서, 그것을 자동화할 수 있는 방법을 생각해보는 것부터 시작해보세요.
작은 첫 걸음이 결국 나만의 개인 비서, 나만의 자비스를 만들어가는 여정의 시작이 될 수 있을 거예요.
]]>us,ko 키보드 전환뿐 아니라, fcitx5를 활용한 완전한 한글 조합 입력(예: “ㅎㅏㄴㄱㅡㄹ” → “한글”)까지 다루고 있어요.
Hyprland에서는 ~/.config/hypr/hyprland.conf 파일의 input 블럭에서 키보드 레이아웃을 설정할 수 있어요. Omarchy의 경우 기본적으로 en과 de가 써있고 주석처리 되어 있는데 아래와 같이 변경하면 돼요.
input {
kb_layout = us,kr
kb_options = compose:caps,grp:alt_space_toggle
}
us: 기본 영어 레이아웃kr: 한글 키보드 레이아웃 (ko 대신 kr을 사용하는 게 더 호환성이 좋아요)compose:caps,grp:alt_space_toggle: Alt + Space로 레이아웃 전환💡 문제 해결 팁:
만약 invalid keyboard layout passed 오류가 발생한다면 kr로 변경하거나 다음 패키지를 설치해보세요:
sudo pacman -S xkeyboard-config
단순한 레이아웃 전환만으로는 조합형 한글 입력이 되지 않아요. 자연스러운 한글 입력을 위해 fcitx5 입력기를 설정해줘야 해요.
sudo pacman -S fcitx5 fcitx5-hangul fcitx5-configtool
fcitx5: 메인 입력기 프레임워크fcitx5-hangul: 한글 입력 지원fcitx5-configtool: 설정 GUI~/.config/hypr/environment.conf 파일을 열고 아래 내용을 추가해요:
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx
export INPUT_METHOD=fcitx
Hyprland 설정에 다음을 추가해요:
exec-once = fcitx5 &
GUI 툴로 입력기를 설정할 수 있어요:
fcitx5-configtool
Hangul 입력기를 추가해요.Shift + Space로 설정해요.Hangul → Keyboard - English (US)로 정렬해요.Alt + Space → Hyprland 키보드 레이아웃 전환 (us ↔ kr)Shift + Space → Fcitx5 한영 전환setxkbmap -query
Wayland 환경에서 클립보드 기능을 제대로 활용하려면 다음 패키지를 설치하면 좋아요:
sudo pacman -S wl-clipboard
wl-pastewl-copy이 설정을 완료하면 Arch Linux + Hyprland 환경에서도 안정적으로 한글 입력을 할 수 있어요.
Hyprland의 키보드 전환과 Fcitx5의 한글 입력을 함께 사용하면 매우 유연한 환경이 만들어져요.
아직은 익숙하지 않은 환경이라 하루에 30분 정도만 사용해보면서 필요한 환경을 만들고 있는데, 익숙해지기만 한다면 마음속에 꿈꿔왔던 애플 맥으로부터의 탈출을 시도해볼 수 있지 않을까하는 기대를 가지고 있어요. 지금은 홈랩 장비로 쓰다가 방치하고 있던 구형 데스크탑을 사용하고 있어서, 블루투스도 안되는 열악한 환경이지만 잘 적응하면 좋은 장비를 구매하는 핑계로 삼아봐야겠어요.😁
]]>Rails 개발자로서, 그리고 DHH의 생각을 늘 관심있게 지켜봐온 사람으로서 이런 변화가 꽤 인상깊었어요. 특히 단순한 선언에 그치지 않고 실제로 실행에 옮기고 있다는 점이 흥미로웠죠. 하지만 동시에 솔직히 말하면 이해가 안 되는 부분도 있고, 막연한 두려움도 느껴졌어요.
DHH가 제시한 이유들을 보면 나름 설득력이 있어요. 특히 두 가지 포인트가 인상적이었어요.
첫 번째는 “오픈소스 생태계에서 일하면서 데스크톱 OS만 상용 제품을 쓰는 것의 모순”이라는 지적이에요. 처음에는 좀 과격한 표현이라고 생각했는데, 생각해보니 일리가 있더라고요. 우리가 Rails, Ruby, VSCode, Git 같은 오픈소스 도구들로 매일 개발하면서, 정작 그 기반이 되는 OS는 애플이라는 거대 기업의 상용 제품에 의존하고 있잖아요.
두 번째는 고객과의 단절감이에요. “고객의 절반이 Windows를 쓰는데 Mac만 쓰면서 단절감을 느꼈다”는 부분은 정말 핵심을 찌르는 말이라고 생각해요. 이건 제품을 만드는 사람이라면 정말 느끼는 바가 클 것 같아요. iOS 앱을 개발하면서 안드로이드폰을 메인으로 쓰거나, 안드로이드 앱을 개발하는데 아이폰을 메인으로 쓰는 개발자들을 보면서 늘 의아했던 점과 같은 맥락이에요. 더 나아가서는 내가 만들고 있는 서비스를 실제 생활에서 잘 쓰지 않는 것도 비슷한 문제라고 생각해요.
그렇다고 해서 당장 Linux로 갈아탈 수 있을까요? 솔직히 말하면 여러 현실적인 장벽들이 있어요.
우선 비용 문제가 있어요. 지금 개인 장비인 Mac mini M4와 회사 장비인 MacBook Pro 14 M4를 쓰고 있는데, 이 정도 성능의 Linux 장비를 새로 장만하는 것은 부담스러워요. 더 저렴한 중고 장비를 고려해보고는 있지만, 선뜻 도전하기가 어렵더라고요.
앱 생태계에 대한 막연한 두려움도 있어요. 지금 Cursor를 주 에디터로 쓰고 있는데, Linux에서 제대로 지원되는지 모르겠어요. 차선책으로 VSCode에 Cline을 연결해서 써야 할 수도 있고요. Sequel Ace나 DB Browser for SQLite 같은 도구들도 대체재를 찾아야 할 거고요.
가상머신으로 Linux를 경험해봤지만, 메인 머신이 아니면 그 경험을 온전히 느끼기 어렵다는 것도 알고 있어요. 듀얼부팅은 Mac 환경에서 쉽지 않고, 가상환경은 성능 차이가 너무 나죠.
그런데 이런 핑계들을 늘어놓다 보니, 문득 이런 생각이 들어요. 혹시 내가 너무 편안함에 안주하고 있는 건 아닐까?
2010년부터 15년 넘게 Mac을 써왔어요. 윈도우에 비해 시간이 지나도 느려지지 않고 안정적이라는 점이 마음에 들어서 계속 써왔죠. 하지만 그만큼 Mac 환경에 익숙해져서, 다른 환경을 시도해볼 용기를 잃은 건 아닐까요?
DHH의 글에서 인상깊었던 부분 중 하나는 “지난 몇 달간 Linux를 파고들면서 개발 플랫폼으로서 얼마나 좋아졌는지 발견하는 것이 즐거웠다”는 표현이었어요. 새로운 도전을 통해 얻는 즐거움, 그리고 그 과정에서 발견하게 되는 새로운 가능성들 말이에요.
개발자로서 늘 새로운 기술을 배우고 도전하라고 하면서, 정작 가장 기본이 되는 개발 환경에 대해서는 안전지대에 머물러 있었던 것 같아요.
DHH의 또 다른 포인트도 생각해볼 만해요. Framework 같은 회사를 지지한다는 부분 말이에요. “내가 보고 싶은 미래에 투표하는 기분”이라고 표현했는데, 이것도 단순히 도구 선택을 넘어선 가치관의 문제인 것 같아요.
개발자이자 메이커로서, 우리가 사용하는 도구들이 어떤 철학과 가치를 담고 있는지 생각해보는 것도 중요하지 않을까요? 오픈소스 생태계에서 혜택을 받으면서도, 그 생태계를 지지하고 기여하는 방식으로 도구를 선택하는 것 말이에요.
특히 Rails 개발자라면 더욱 그렇지 않을까 싶어요. Rails 자체가 오픈소스이고, Ruby 커뮤니티의 철학도 개방성과 공유를 중시하잖아요.
당장 메인 환경을 Linux로 바꾸는 것은 쉽지 않겠지만, 작은 도전부터 시작해볼 수는 있을 것 같아요.
예를 들어 Docker나 dev container를 더 적극적으로 활용해보는 것부터 시작할 수 있겠죠. 지금은 배포할 때만 Docker를 쓰고 있지만, 개발 환경도 컨테이너로 구성해보면 Linux 환경에 조금 더 가까워질 수 있을 거예요.
아니면 중고 장비라도 하나 장만해서 서브 머신으로 Linux를 써보는 것도 방법이겠고요. Flutter 개발의 경우 iOS 빌드는 여전히 Mac이 필요하지만, 주 개발은 Linux에서 하고 빌드만 Mac에서 돌리는 방식도 가능할 테니까요.
DHH의 글을 읽으면서 가장 큰 깨달음은, 도구 선택도 결국 가치관의 문제라는 점이었어요. 단순히 편리함이나 익숙함만으로 도구를 선택할 것이 아니라, 내가 추구하는 가치와 일치하는지도 생각해봐야 한다는 거죠.
물론 DHH의 결정이 모든 개발자에게 맞는 답은 아닐 거예요. 하지만 적어도 한 번쯤은 생각해볼 만한 문제라고 생각해요. 우리가 너무 편안함에 안주해서 새로운 가능성을 놓치고 있는 건 아닌지 말이에요.
언젠가 다음 글에서는 실제 Linux 도전 경험담을 쓸 수 있기를 바라면서, 일단은 이 글로 제 생각을 정리해봤어요. 편안함에 안주하지 말고 새로운 도전을 해보자는 스스로와의 약속이기도 하고요.
37signals의 새로운 개발자 기본 환경인 Linux (Linux as the new developer default at 37signals) - DHH 20년간의 Apple 생활 이후 Linux 및 Android와 함께 생활하기 (Living with Linux and Android after two decades of Apple) - DHH
]]>지난 Ruby on Rails #50번째 소식 뉴스레터에서 처음으로 진행했던 “한국에서 Rails, 어디에 배포하시나요?” 설문조사 결과를 공유해요.
응답자들의 배포 환경 선택은 다음과 같았어요:
1. DigitalOcean, GCP, 자체 서버 (NAS, 라즈베리파이 등)
2. 자체 서버 (NAS, 라즈베리파이 등)
3. AWS, 자체 서버 (NAS, 라즈베리파이 등)
4. DigitalOcean
5. DigitalOcean
6. 자체 서버 (NAS, 라즈베리파이 등)
환경별 사용 현황:
흥미롭게도 6명 중 2명이 여러 환경을 동시에 사용하고 있어, 용도에 따라 배포 환경을 나누어 활용하고 있음을 알 수 있어요.
설문조사에서 수집한 실제 답변들이에요:
자체 서버 선택 이유들:
- “작게 시작하기에는 셀프호스트 만한 것이 없습니다”
- “학습의 목적 및 1인 개발로 프로젝트 크기가 크지 않아 리소스의 부담이 적고, 생각보다는 빠르다는 점”
- “돈이 안 들고 성능 빵빵”
DigitalOcean 선택 이유:
- “내게 익숙한 서비스, 저렴하고 자유도가 높음”
- “편리한 UX, 문서, 가격(최근에는 비싸져서 고민중)”
최근 Josh Pigford가 트위터에서 “Rails + Postgres 앱을 간편하게 배포할 수 있는 솔루션이 뭐가 있을까요?”라는 질문을 올렸을 때, 해외 커뮤니티에서는 다음과 같은 답변들이 나왔어요:
한국과 해외 모두 자체 서버(라즈베리파이 포함) 사용 사례가 있지만, 한국에서는 상대적으로 자체 서버의 비중이 높게 나타났어요.
비록 응답 모수가 적어 일반화하기는 어렵지만, 몇 가지 흥미로운 패턴을 발견할 수 있었어요:
1. 높은 자체 서버 사용률 전체 응답자의 67%가 자체 서버를 사용하고 있어요. 이는 사업용보다는 사이드프로젝트나 학습 목적의 프로젝트가 많아 비용에 민감한 특성이 반영된 것으로 보여요.
2. 복합 환경 활용 응답자 중 1/3이 여러 환경을 동시에 사용하고 있어, 용도별로 최적화된 배포 전략을 구사하고 있음을 알 수 있어요.
3. 실용적 선택 “가성비”, “학습 목적”, “리소스 부담 적음” 등의 키워드가 자주 언급되어, 실용성을 중시하는 경향을 보여요.
처음으로 진행한 설문조사였지만, 한국 Rails 개발자들의 배포 환경 선택에 대한 실제 목소리를 들을 수 있어 의미가 있었어요.
특히 자체 서버를 활용한 홈랩 운영에 관심이 있으시다면, 실제 운영 경험을 담은 다음 글들도 참고해보세요:
앞으로도 Ruby on Rails 뉴스레터를 통해 한국 Rails 커뮤니티의 다양한 목소리를 전달할 수 있으면 좋겠어요. 설문조사에 참여해주신 모든 분들께 감사드려요!
Ruby on Rails 개발자를 위한 최신 소식과 유용한 정보를 매주 받아보세요. Ruby on Rails 커뮤니티 소식을 한눈에 확인할 수 있어요.
]]>I’m sharing the results of our first survey “Where do you deploy Rails in Korea?” conducted through the Ruby on Rails Newsletter #50.
The deployment environment choices from our respondents were as follows:
1. DigitalOcean, GCP, Self-hosted servers (NAS, Raspberry Pi, etc.)
2. Self-hosted servers (NAS, Raspberry Pi, etc.)
3. AWS, Self-hosted servers (NAS, Raspberry Pi, etc.)
4. DigitalOcean
5. DigitalOcean
6. Self-hosted servers (NAS, Raspberry Pi, etc.)
Usage by Platform:
Interestingly, 2 out of 6 respondents use multiple environments simultaneously, indicating they strategically choose different deployment environments based on their specific needs.
Here are the actual responses we collected from the survey:
Reasons for choosing self-hosted servers:
- “Nothing beats self-hosting when starting small”
- “For learning purposes and solo development, project size isn’t too big, so resource burden is minimal, and it’s surprisingly fast”
- “No cost and great performance”
Reasons for choosing DigitalOcean:
- “Familiar service, affordable and high degree of freedom”
- “Convenient UX, documentation, pricing (though getting expensive lately, so reconsidering)”
Recently, Josh Pigford asked on Twitter: “What are the options for easily deploying Rails + Postgres apps?” The international community responded with:
While both Korean and international communities have self-hosted server (including Raspberry Pi) use cases, the proportion of self-hosted servers appears relatively higher in Korea.
Although the sample size is small and difficult to generalize, we discovered several interesting patterns:
1. High Self-Hosted Server Usage Rate 67% of all respondents use self-hosted servers. This likely reflects a cost-sensitive approach, as many projects appear to be side projects or learning-oriented rather than business applications.
2. Multi-Platform Strategy One-third of respondents use multiple environments simultaneously, showing they employ optimized deployment strategies based on different use cases.
3. Practical Choices Keywords like “cost-effectiveness,” “learning purposes,” and “minimal resource burden” were frequently mentioned, indicating a tendency to prioritize practicality.
Although this was a small-scale survey, it was meaningful to hear real voices from Korean Rails developers about their deployment environment choices.
We’ll continue to share diverse voices from the Korean Rails community through our Ruby on Rails newsletter. Thank you to everyone who participated in our first survey!
]]>