"바이브 코딩"의 유혹, 그리고 Rackula가 보여준 AI 협업의 현명한 길

"온전히 '바이브'에 몸을 맡기고, 기하급수적 성장을 받아들이며, 코드가 존재한다는 사실조차 잊어버리는 새로운 종류의 코딩이 있습니다. ... 저는 프로젝트나 웹 앱을 만들고 있지만, 사실 코딩이라기보다는 그냥 보고, 말하고, 실행하고, 복사 붙여넣기 할 뿐인데, 대부분 잘 돌아갑니다." — <cite>안드레이 카파시(Andrej Karpathy), 2025년 2월</cite>

어느 날 아침, 저는 사이드 프로젝트에 시간을 쏟을 생각에 잔뜩 들떠 잠에서 깼습니다. 드디어 에너지가 넘쳤거든요. 지난 한 주 동안 셀프 호스팅 커뮤니티를 헤매고 작은 Intel NUC를 세팅하며 시간을 보냈습니다. 이제야 프로젝트를 어떻게 진행해야 할지 감이 잡히는 듯했죠. 자신감 있게 OpenCode를 열고 30분 정도 지났을까요? 그놈의 프로젝트, LLM, 그리고 노트북까지 창밖으로 던져버리고, "아니야, 그렇게 하는 거 아니야!"라고 아주 짜증 나는 프로그램에 소리 지르지 않아도 되는 다른 직업을 찾아야겠다고 생각했습니다.

당시 코드를 보는데 완전히 단절감을 느꼈어요. 무엇을 하는 코드인지는 알았고, 전부 검토했지만, 왠지 모르게 낯설었습니다. 개발 흐름이 끊겨버렸고, 다음 며칠은 손으로 코딩하는 방법을 다시 떠올리는 데 시간을 보냈습니다. 기쁜 소식은, 저는 메모리 내 저장소와 카운트를 늘리고 줄이는 API까지 갖춘, 세상에서 가장 과도하게 설계된 카운터 애플리케이션을 만들어냈다는 겁니다.

이른바 '바이브 코딩'은 개발자 커뮤니티를 휩쓸며, 이해 없는 스택 오버플로우 복사 붙여넣기를 의도적으로, 그리고 기하급수적으로 가속화했습니다. 하지만 저 역시 AI 지원 개발에 의존해야 할 이유가 있었고, LLM 디톡스가 정신 건강에 엄청난 도움이 되었지만, AI와 함께 소프트웨어를 더 잘 작성할 방법을 계속 찾아 헤맸습니다.

그리고 Rackula의 창시자, 가레스 에반스(Gareth Evans)가 이 주제에 대해 공유할 경험이 많다고 생각합니다.

Rackula, 그 시작

모든 것은 2025년 말에 시작되었습니다. 가레스의 말에 따르면:

"원래는 아버지의 어수선한 서버 랙을 정리하는 걸 돕고 싶었어요. 그 랙에는 크고 무거운 오디오 앰프와 네트워크 장비들이 잔뜩 있었죠. 이 무겁고 다루기 힘든 장비들을 한 번 이상 움직이지 않고도 랙 배치와 장비 구성을 좀 더 체계적으로 생각하고 싶었습니다. 아버지는 토목 기술자라 도표와 계획을 정말 좋아하시거든요. 그래서 랙과 장비 레이아웃을 시각화하는 데 도움이 될 만한 도구를 찾아봤는데, 놀랍게도 제 요구 사항에 맞는 도구는 하나도 없었습니다. 사용하기 쉽고, 이미지를 내보낼 수 있으며, 데이터를 특정 형식에 묶어두지 않는 그런 도구 말이죠."

아, 사이드 프로젝트의 유혹이란! 마치 사이렌처럼 겉으로 보이는 단순함과 즐거운 시간을 보내리라는 약속으로 우리를 속입니다. LLM은 이런 불길에 기름만 더 붓는 격이죠.

"2025년 11월에서 12월이 LLM 기반 도구들이 실질적으로 소프트웨어 구축에 활용될 수 있음을 보여주기 시작한 시점이었다는 것을 기억하실 겁니다. 그래서 저도 다른 많은 사람처럼 Claude Code를 가지고 놀면서 무엇을 할 수 있는지 알아보고 있었죠. 처음에는 랙 레이아웃과 장비 배열을 시각화하고, 아이템들을 드래그 앤 드롭으로 움직일 수 있는 방법을 원했습니다. 또한 쉽게 공유하고 가져올 수 있는 형식으로 저장하고 싶었고, 레이아웃을 이미지로 내보내는 기능도 필요했습니다."

"저는 하퍼 리드(Harper Reed)의 'My LLM codegen workflow atm' 블로그 게시물을 읽었던 것을 특히 기억합니다. 그가 AI를 사용해 아이디어를 구상하고, 그 아이디어를 바탕으로 LLM에게 코드를 생성하도록 프롬프트를 작성하는 방법을 설명했죠. 그래서 저는 필요한 기능을 염두에 두고 한동안 사양을 구축하는 데 시간을 보냈고, 그 후 아주 빠르게 작동하는 프로토타입을 만들어낼 수 있었습니다."

좋은 점, 나쁜 점, 그리고 사파리

코드를 작성하는 것은 쉽습니다. 뭘 써야 할지 알 때 말이죠. LLM이 있든 없든 상관없이요. 가레스는 초기에 데이터 모델과 스키마를 정의하는 것이 예상외로 어렵다는 것을 깨달았습니다. "결국 깨달았죠. 확장 가능하고 유지보수 가능한 시스템을 구축하려면 잘 정의된 스키마가 정말 중요하다는 것을요."

저도 비슷한 결론에 도달했습니다. LLM은 소프트웨어를 처음부터 설계하는 데는 정말 형편없습니다. 하지만 명확한 시작점과 몇 가지 가이드라인을 제공하면, 과도하게 의욕 넘치는 코딩 에이전트들을 다루기가 훨씬 쉬워집니다. 제가 실무에서 여러 LLM을 사용해봤을 때, 명확한 설계도 없이 무작정 코드를 뽑아내려 하면 엉뚱한 방향으로 빠지거나 불필요하게 복잡한 코드를 내뱉는 경우가 많았습니다. 핵심 로직과 데이터 구조를 먼저 잡는 것이 결국 시행착오를 줄이는 지름길이었죠.

영감을 얻을 만한 좋은 자료들이 많이 있다고 생각합니다. 예를 들어 Rackula의 스키마는 NetBox에서 영감을 받았습니다. 코드 구조는 완전히 다를 수 있지만, 랙이 무엇인지, 장비가 무엇인지, 어떤 속성을 가지는지, 어떻게 관련되는지에 대한 개념적 모델은 매우 유사합니다.

그리고 스코프 크립(Scope Creep), 즉 기능 추가 욕구는 항상 문제죠. 가능성이 무한할 때, '무엇을 만들지 않을 것인가'를 선택하는 것이 오히려 큰 문제가 됩니다. 가레스는 이렇게 말했습니다: "아이디어는 쉽습니다. 스코프 크립을 제한하는 것이 훨씬 어렵죠. 단순한 아이디어로 시작했지만, 빠르게 많은 움직이는 부품을 가진 복잡한 시스템으로 성장했습니다. 처음에는 모든 것을 다 하고 싶었어요. 모든 항목에 대한 엄청난 세부 정보를 유지하려고 했죠."

그는 또한 다시 시작한다면 의도적으로 범위를 제한하는 데 더 부지런했을 것이라고 말했습니다. "초기 기능에 필요하지 않은 기능에 분명히 많은 에너지를 낭비했습니다. 네트워킹 및 전원 연결 모델링에 대한 많은 아이디어가 있었는데, 물론 가치 있었지만 핵심 앱에는 중요하지 않았죠."

로마는 하루아침에 지어지지 않았고, 1040개의 커밋을 보면 Rackula는 수많은 반복을 거쳤음을 알 수 있습니다. 그리고 상당 부분은 브라우저의 기이한 동작 때문이었습니다.

"Rackula의 아키텍처는 브라우저에서 SVG를 사용하고 드래그 앤 드롭하는 데 중점을 둡니다. 간단하게 들리죠? 주요 브라우저마다 SVG와 드래그 앤 드롭을 처리하는 방식에 대한 고유한 '생각'이 있어서 일관되지 않은 결과로 이어집니다. 이로 인해 한 브라우저의 구현이 다른 브라우저의 사용자 경험에 어떤 영향을 미치는지 파고드는 데 상당한 시간을 보냈습니다. 저는 Safari/webkit 버그와 불일치를 위한 'damnit/safari'라는 GitHub 이슈 라벨을 가지고 있습니다."

프로젝트 이름조차 이 과정에서 변경되었습니다:

"처음에는 *arr 스위트(Sonarr, Radarr 등)를 유쾌하게 참조하여 Rackarr라고 지었습니다. 그리고 Reddit 커뮤니티에 소개했는데, *arr 스위트와는 관련이 없다는 이유로 거의 즉각적인 반발이 있었습니다."

결국은 UI가 핵심

Rackula의 핵심 철학은 직관적이어야 한다는 것입니다. 창시자의 말에 따르면:

"아직 목표에 도달했는지 확실하지 않지만, 제 부모님도 사용할 수 있는 도구가 되기를 바랐습니다. 이는 사용성에 대한 매우 높은 기준이죠."

그 과정은 분명 길고 비선형적이었습니다.

"저는 디자이너는 아니지만, 소프트웨어가 합리적일 때(혹은 그렇지 않을 때)를 안다고 생각합니다. 그래서 제 초기 레이아웃은 대충 던져놓은 듯했고, 종종 투박하거나 일관성이 없게 느껴졌습니다. 이로 인해 다른 캔버스 기반 앱들이 UI 디자인을 어떻게 처리하는지, 그리고 제 앱을 더 유연하게 만드는 방법을 찾아보는 데 깊이 빠져들었습니다. 시간이 더 있다면 개선할 점이 여전히 많고도 많습니다."

물론 더 많은 이야기가 있겠지만, Rackula에 쏟은 노력은 충분히 가치 있었다고 생각합니다. 저만 해도 쉽게 사용법을 익혔고, 설정에서 발견한 "바나나 스케일" 이스터 에그는 정말 마음에 들었거든요.

AI vs. 인간

Rackula의 품질에 진심으로 감탄했고, 그중 얼마만큼이 가레스의 공헌이고 얼마만큼이 AI의 공헌인지 궁금하지 않을 수 없었습니다. 그래서 그의 비법을 제 프로젝트에 적용해볼 희망으로 그에게 물어봤고, 그가 공유한 내용은 다음과 같습니다.

"앞서 언급했듯이, 저는 TDD(Test Driven Development)를 특히 사용하여 AI 우선 접근 방식을 옹호한 하퍼 리드 및 다른 사람들을 기반으로 AI를 광범위하게 사용했습니다. AI(Claude Code)는 반복적인 피드백을 통해 사양을 정의하는 데 사용되었고, 거기에서 테스트를 위한 청사진과 프롬프트 계획을 정의하여 결국 앱을 구성하는 코드를 만들었습니다. 앤트로픽이 크리스마스 휴가 동안 사용량 제한을 두 배로 늘렸던 것을 기억하실 겁니다. 이것이 저에게는 불에 기름을 끼얹은 격이었죠. 저는 5개 이상의 에이전트를 병렬로 실행하며 테스트와 코드를 쏟아냈고, AI 없이는 절대 해낼 수 없었을 겁니다."

그의 과정은 제게 카이젠(Kaizen) 또는 그 파생인 도요타 생산 방식(The Toyota Way)과 많이 비슷하게 들립니다. 코드 생성 자체는 기계가 할지라도, 인간이 통제권을 가지고 품질이 떨어질 때 생산을 멈출 의무가 있는 것이죠.

하지만 가장 중요한 것은, 저는 올바른 것을 올바른 이유로 만들어야 한다고 생각합니다. 가레스에게 Rackula에 대한 그의 포부를 물었고, 프로젝트 이름과는 달리 세계 정복은 로드맵에 없었습니다.

"음, 이전에 저는 어떤 프로젝트도 제대로 된 반응을 얻어본 적이 없었습니다. 그래서 처음에는 '누군가 내 것을 클릭해줬으면' 하는 꿈이 전부였죠. 그런데 몇 달이 지난 지금, GitHub에서 1천 개 이상의 스타를 받았습니다. 이제는 Rackula가 사용하는 여러 커뮤니티에서 필수 도구가 되는 것이 저의 가장 큰 꿈입니다. 정말로 원하는 것은 프로젝트가 스스로 생명력을 얻는 지점까지 가는 것입니다. 이미 여러 개인이 PR을 보내고 프로젝트를 형성하는 데 도움을 주는 것을 보았고, Rackula가 성장하여 커뮤니티를 위한 가치 있는 도구가 될 잠재력이 크다고 믿습니다."

저는 창의적인 과정이 우리 인간의 손에 남아 있는 이런 방식이야말로 지속 가능한 AI 지원 개발의 길이라고 생각합니다. 또한, AI 모델을 자체 호스팅하는 것이 그 목표를 위한 중요한 이정표가 될 것이라고 믿습니다. 그리고 혹시라도 이 글을 읽다가 서버 랙을 만들고 싶다는 영감을 받으셨다면, Rackula를 한번 사용해보세요.

정말 멋진 작은 소프트웨어입니다.

---

원문: https://dev.to/valeriavg/great-little-software-rackula-1pa1 수집일: 2026-05-21 01:58:06