AI 코드만능주의 시대, '손맛' 담은 Rackula 개발기가 던지는 메시지
2026. 5. 20.
AI 코드만능주의 시대, '손맛' 담은 Rackula 개발기가 던지는 메시지
"요즘 저는 '감성 코딩'이라 부르는 새로운 방식의 코딩을 하고 있습니다. 온전히 '감성'에 몸을 맡기고, 기하급수적인 속도에 환호하며, 코드가 존재한다는 사실조차 잊어버리는 거죠. ... 저는 프로젝트나 웹 앱을 만들고 있지만, 이건 코딩이 아닙니다. 그저 뭔가를 보고, 말하고, 실행하고, 복사해서 붙여 넣을 뿐인데, 대충 다 작동하거든요." -- <cite>안드레이 카르파티 (Andrej Karpathy), 2025년 2월</cite>
어느 날 아침, 저는 사이드 프로젝트에 시간을 쏟을 생각에 잔뜩 들떠서 잠에서 깼습니다. 드디어 에너지가 넘쳤거든요. 지난 한 주 동안 자체 호스팅 커뮤니티를 들락거리며 제 작은 Intel NUC를 세팅하는 데 시간을 보냈고, 마침내 프로젝트를 어떻게 진행해야 할지 감을 잡은 것 같았습니다. 의기양양하게 OpenCode를 열었죠. 그런데 30분도 채 지나지 않아, 제 프로젝트와 LLM, 노트북을 창밖으로 던져버리고, "아니, 아니, 그게 아니야!"라고 짜증 나는 프로그램에 소리칠 필요 없는 다른 직업으로 전향하고 싶다는 충동에 사로잡혔습니다.
화면 속 코드를 보는데, 왠지 모르게 저와 동떨어진 느낌이 들었습니다. 코드가 뭘 하는지는 분명히 알았고, 전부 검토했지만, 마치 낯선 언어처럼 느껴졌죠. 개발 흐름은 끊겼고, 저는 다음 며칠을 직접 손으로 코딩하는 방법을 다시 떠올리는 데 보냈습니다. 그리고 기쁜 소식 하나! 저는 인메모리 스토리지와 카운트를 늘리고 줄이는 API까지 갖춘, 세상에서 가장 과하게 설계된 카운터 애플리케이션을 기어코 만들어냈습니다.
'감성 코딩'은 개발자 커뮤니티를 휩쓸며 스택 오버플로우에서 이해도 없이 복사 붙여넣는 속도를 의도적이고 기하급수적으로 가속화시켰습니다. 하지만 저 역시 AI 기반 개발에 의존해야만 하는 이유가 있었습니다. LLM 디톡스가 정신 건강에 지극히 이롭긴 했지만, 저는 AI를 활용해 소프트웨어를 더 잘 작성할 방법을 찾고 싶었죠.
그리고 Rackula의 창시자, Gareth Evans는 이 주제에 대해 공유할 경험이 무척 많다고 생각합니다.
Rackula, 그 시작은?
이야기는 2025년 말에 시작됩니다. Gareth의 말에 따르면:
"원래는 아버지가 지저분하게 쌓여 있는 서버 랙을 정리하는 걸 돕고 싶었어요. 거대한 오디오 앰프와 네트워크 장비들이 여기저기 뒤섞여 있었거든요. 무겁고 불편한 장비들을 한 번 이상 옮기지 않고도 랙의 레이아웃과 장비 배치를 좀 더 체계적으로 구상하고 싶었습니다. 아버지는 토목 기술자셔서 도표와 계획을 무척 좋아하시죠. 그래서 랙 레이아웃과 장비를 시각화하는 데 도움이 될 만한 도구를 찾아봤지만, 놀랍게도 제 필요를 충족하는 것은 없었어요. 사용하기 쉽고, 이미지로 내보낼 수 있으며, 데이터가 특정 포맷에 묶이지 않는 그런 도구요."
아, 사이드 프로젝트의 유혹이란! 마치 사이렌처럼 겉으로 보기엔 단순해 보이는 모습과 즐거운 시간을 보내리라는 약속으로 우리를 기만하죠. LLM은 여기에 기름을 붓는 격입니다. 제가 실무에서 사이드 프로젝트를 시작할 때마다 느끼는 건데, 처음엔 단순해 보여도 파고들수록 예상치 못한 난관에 부딪히기 마련이거든요.
"2025년 11월에서 12월이 LLM 기반 도구들이 소프트웨어 개발에 실질적으로 활용될 수 있음을 보여주기 시작한 시기였음을 기억하실 겁니다. 그래서 저도 다른 많은 사람처럼 Claude Code를 가지고 놀면서 어떤 일을 할 수 있는지 테스트해보고 있었죠. 처음에는 랙 레이아웃과 장비 배치를 시각화하고, 아이템을 드래그 앤 드롭으로 움직일 수 있는 방법을 원했어요. 또한, 쉽게 공유하고 가져올 수 있는 형식으로 저장하고 싶었고, 레이아웃을 이미지로 내보내는 기능도 필요했습니다."
"특히 하퍼 리드(Harper Reed)의 My LLM codegen workflow atm이라는 블로그 게시물을 읽었던 것이 기억납니다. 그는 AI를 이용해 아이디어를 구상하고, 그 아이디어를 기반으로 LLM에 코드를 생성하도록 프롬프트를 작성하는 워크플로우를 설명했죠. 그래서 저는 필요한 기능을 염두에 두고 한동안 사양을 구축하는 데 시간을 보냈고, 그 후에는 아주 빠르게 작동하는 프로토타입을 만들어낼 수 있었습니다."
좋았던 점, 나빴던 점 그리고 사파리
코드를 작성하는 것은 쉽습니다. 뭘 작성해야 할지 안다면 말이죠. LLM이 있든 없든 상관없이요. Gareth는 초기에 데이터 모델과 스키마를 정의하는 것이 예상외로 어렵다는 것을 깨달았습니다. "결국(꽤 나중에야) 잘 정의된 스키마가 확장 가능하고 유지보수하기 쉬운 시스템을 구축하는 데 결정적이라는 것을 알게 되었죠."
저도 같은 결론에 도달했습니다. LLM은 소프트웨어를 처음부터 설계하는 데는 형편없지만, 시작점과 몇 가지 가드레일이 주어지면 지나치게 의욕적인 코딩 에이전트들을 통제하기가 훨씬 쉬워집니다. 저도 수많은 프로젝트를 거치면서 뼈저리게 느낀 부분이에요. 특히 LLM으로 초반 아키텍처를 잡으려다 보면, '그럴싸하지만 속 빈 강정' 같은 결과물을 마주하게 되죠. 결국 인간의 정교한 설계와 가이드라인이 필수적입니다.
저는 영감을 얻을 만한 좋은 자료들이 많다고 생각합니다. 예를 들어, Rackula의 스키마는 NetBox에서 영감을 받았습니다. 코드 구조는 완전히 다르지만, 랙이 무엇인지, 장비가 무엇인지, 어떤 속성을 가지는지, 그리고 그것들이 어떻게 서로 관련되어 있는지에 대한 개념적 모델은 매우 흡사합니다.
그리고 '스코프 크립(scope creep)' 문제가 있습니다. 가능성이 무한할 때, 무엇을 만들지 말아야 할지 선택하는 것이 문제가 됩니다. Gareth는 이렇게 표현했습니다. "아이디어는 쉽지만, 스코프 크립을 제한하는 것은 훨씬 어렵습니다. 단순한 아이디어로 시작했지만, 빠르게 많은 움직이는 부품을 가진 복잡한 시스템으로 성장했죠. 처음에는 _모든 것_을 하고 싶었습니다. 모든 항목에 대해 엄청나게 많은 세부 정보를 담으려고 했어요."
그는 만약 다시 시작한다면, 의도적으로 범위를 제한하는 데 더 부지런했을 것이라고도 말했습니다. "초기 기능에 필요하지 않은 기능에 분명히 많은 사이클을 낭비했어요. 네트워킹 및 전력 연결을 모델링하는 것에 대한 수많은 아이디어가 있었는데, 비록 가치 있는 기능들이었지만 핵심 앱에는 중요하지 않았죠."
로마는 하루아침에 이루어지지 않았고, 1040개의 커밋으로 미루어 짐작컨대 Rackula는 수많은 반복을 거쳤습니다. 그리고 상당 부분은 브라우저의 특성 때문이라고 할 수 있습니다.
"Rackula의 아키텍처는 브라우저 내의 SVG와 드래그 앤 드롭에 중점을 둡니다. 간단하게 들리죠? 물론입니다, 각 브라우저마다 SVG와 드래그 앤 드롭을 처리하는 방식에 대한 고유한 '아이디어'가 있어서 일관된 동작을 얻으려고 노력할 때까지는 말이죠. 이는 한 브라우저의 구현이 다른 브라우저의 사용자 경험에 어떻게 영향을 미치는지 파고드는 데 상당한 시간을 보냈다는 것을 의미합니다. Safari/webkit 버그와 불일치로 인한 수많은 문제에 대해 '젠장/사파리(damnit/safari)'라는 GitHub 이슈 라벨까지 만들었을 정도예요."
프로젝트 이름마저도 이 과정에서 변경되었습니다.
"처음에는 *arr 스위트(Sonarr, Radarr 등)를 유쾌하게 참조하여 Rackarr라고 이름을 지었고, Reddit 커뮤니티에 소개했습니다. 그런데 *arr 스위트와는 전혀 관련이 없다는 이유로 거의 즉각적인 반발이 있었죠. 그래서 Rackula로 바꿨습니다."
모든 것은 UI에 달렸다
Rackula의 핵심 철학은 직관적이어야 한다는 것입니다. 창시자의 말에 따르면:
"아직 목표에 도달했는지는 모르겠지만, 제 부모님도 사용할 수 있는 도구가 되기를 바랐습니다. 이는 사용성 측면에서 매우 높은 기준이죠."
그 과정은 분명 길고 비선형적이었습니다.
"저는 디자이너가 아니지만, 소프트웨어가 합리적인지(또는 그렇지 않은지)는 안다고 생각합니다. 그래서 초기 레이아웃은 대충 던져놓은 느낌이었고, 종종 투박하거나 일관성이 없다고 느꼈죠. 이로 인해 다른 캔버스 기반 앱들이 UI 디자인을 어떻게 처리하는지, 제 앱을 어떻게 더 유동적으로 만들 수 있는지 알아보는 토끼굴에 빠져들었습니다. 시간이 더 있다면 개선하고 싶은 점이 여전히 많습니다."
물론 더 많은 이야기가 있겠지만, 저는 Rackula에 들인 노력이 충분히 가치 있었다고 생각합니다. 저만 해도 이 앱을 쉽게 이해할 수 있었고, 설정에서 발견한 '크기 비교용 바나나'라는 작은 이스터 에그가 너무나 마음에 들었으니까요.
AI vs 인간
Rackula의 품질에 진심으로 감탄했고, 얼마나 많은 부분이 Gareth의 공헌이고, 또 얼마나 많은 부분이 AI의 공헌일지 궁금하지 않을 수 없었습니다. 그래서 저는 저의 프로젝트에도 적용할 수 있을까 하는 희망으로 그의 비결을 물어봤습니다. 그가 공유한 내용은 다음과 같습니다.
"앞서 언급했듯이, 저는 하퍼 리드(Harper Reed)와 AI 우선 접근 방식, 특히 테스트 주도 개발(TDD)을 옹호했던 다른 이들을 기반으로 AI를 광범위하게 사용했습니다. AI(Claude Code)는 반복적인 피드백을 통해 사양을 정의하는 데 사용되었고, 거기서부터 앱을 구성하는 코드를 최종적으로 정의하는 테스트에 대한 청사진과 프롬프트 계획을 정의하는 데 활용되었죠. Anthropic이 크리스마스 휴가 기간 동안 사용량 제한을 두 배로 늘렸던 것을 기억하실 겁니다. 이것이 저에게는 불에 기름을 부은 격이었죠. 5개 이상의 에이전트를 병렬로 실행하여 테스트와 코드를 쏟아냈고, AI 없이는 이런 일을 해낼 수 없었을 겁니다."
그의 작업 방식은 저에게 '카이젠(Kaizen)'이나 그 파생형인 '더 도요타 웨이(The Toyota Way)'와 비슷하게 들립니다. 코드 생성 자체는 기계가 할지라도, 인간은 통제권을 쥐고 있으며, 품질이 떨어질 때 생산 라인을 멈추는 코드를 당길 의무가 있다는 것이죠.
하지만 가장 중요한 것은, 저는 '올바른 것'을 '올바른 이유'로 만드는 것이라고 생각합니다. Gareth에게 Rackula에 대한 그의 목표를 물어봤는데, 프로젝트 이름과 달리 '세계 정복'은 로드맵에 없었습니다.
"음, 이전에는 어떤 프로젝트도 진정한 주목을 받은 적이 없었어요. 그래서 처음에는 '누군가 내 작품을 클릭했으면 좋겠다'는 꿈을 꿨고, 지금 몇 달이 지난 후에는 GitHub에서 1천 개 이상의 스타를 받았습니다. 이제 제 가장 원대한 꿈은 Rackula가 이 도구를 사용하는 여러 커뮤니티의 '즐겨 찾는 도구'가 되는 것입니다. 정말로, 저는 이 프로젝트가 스스로 생명력을 얻는 지점까지 가기를 바랍니다. 이미 여러 개별 기여자들이 PR을 제출하고 프로젝트를 형성하는 데 도움을 주는 것을 보았고, Rackula가 성장하여 커뮤니티에 가치 있는 도구가 될 잠재력이 크다고 믿고 있습니다."
저는 창의적인 과정이 우리 인간의 손에 남아있는 이런 방식이 지속 가능한 AI 보조 개발로 가는 가장 올바른 길이라고 생각합니다. 또한, AI 모델을 자체 호스팅하는 것 역시 그 목표를 위한 중요한 이정표가 될 것이라고 믿습니다. 그리고 혹시 이 글을 읽고 서버 랙을 구축하고 싶은 영감을 받으셨다면, Rackula를 한번 사용해보세요.
정말 괜찮은 물건입니다.
원문: https://dev.to/valeriavg/great-little-software-rackula-1pa1 수집일: 2026-05-20 01:59:02