주말 프로젝트가 어쩌다 스타트업 아키텍처가 됐을까요
개발자라면 다들 하나쯤 갖고 있는 게 있죠. 퇴근 후나 주말에 만지작거리는 사이드 프로젝트요. 영어권에서는 이걸 '펫 프로젝트(pet project)'라고 부르는데요, 반려동물처럼 애정을 갖고 돌보는 나만의 작은 프로젝트라는 뜻이거든요. 그런데 최근 한 개발자가 재미있는 문제 제기를 했어요. AI 코딩 도구 덕분에 이 '펫'이 너무 커져서, 더 이상 쓰다듬을 수 없는 지경이 됐다는 거예요.
스코프를 지켜주던 건 사실 '내 타이핑 속도'였어요
예전의 펫 프로젝트는 작을 수밖에 없었어요. 평일 저녁 두어 시간, 주말 반나절이라는 시간 제약이 있으니 기능을 욕심껏 넣고 싶어도 물리적으로 불가능했거든요. 그 덕분에 모든 코드를 내가 직접 타이핑했고, 코드베이스 전체가 머릿속에 들어 있었죠. 어디를 고치면 뭐가 깨지는지 훤히 아는 상태, 그게 펫 프로젝트의 매력이었어요.
그런데 LLM 에이전트가 등장하면서 이 제약이 사라졌어요. 이제 주말 하루면 2만 줄짜리 코드가 생성되거든요. 글쓴이 본인의 경험담이 압권인데요. 처음엔 500줄짜리 Flask 습관 트래커였던 프로젝트가, 에이전트 기반 코딩 도구를 쓰기 시작한 뒤로 React 프론트엔드, 백그라운드 잡 큐, OAuth 로그인, 플러그인 시스템, 심지어 쿠버네티스 매니페스트까지 갖추게 됐대요. 본인 표현으로는 '사용자가 한 명뿐인데 스타트업 아키텍처'가 된 거죠.
펫이 가축이 되는 순간
이렇게 커지면 뭐가 문제일까요? 글쓴이는 세 가지를 짚어요. 첫째, 취미 시간에 유지보수 부채를 갚아야 해요. 즐거우려고 시작한 프로젝트인데 의존성 업데이트하고 배포 파이프라인 고치다가 주말이 끝나는 거죠. 둘째, 학습 기능이 사라져요. 펫 프로젝트의 진짜 가치는 새 기술을 밑바닥부터 만져보며 배우는 건데, 내가 이해하지 못하는 코드가 쌓이면 그 가치가 없어지거든요. 셋째, 가장 뼈아픈 표현인데요, 펫이 '가축'이 돼요. 같이 놀아주는 존재가 아니라 관리해야 하는 대상이 되는 거예요.
물론 글쓴이도 반대 의견을 인정해요. 로봇 직원들을 지휘하는 매니저 역할 자체가 즐거운 사람도 있고, 예전 같으면 혼자서는 꿈도 못 꿨을 규모의 프로젝트가 가능해진 건 분명한 선물이라는 거죠. 요즘 흔히 말하는 '바이브 코딩'의 순기능이기도 하고요.
그래서 제안하는 것: '쓰다듬기 예산'
글쓴이의 처방이 실용적이에요. 스스로에게 '쓰다듬기 예산(petting budget)'을 정하라는 건데요. 기준은 간단해요. 한자리에 앉아서 코드베이스 전체를 다시 읽을 수 없다면, 그 프로젝트는 이미 너무 큰 거예요. 그럴 땐 기능을 과감히 지우고, 화려한 마이크로서비스 대신 지루한 단일 파일 아키텍처를 선호하고, AI는 '어차피 내가 쓰려던 코드를 빨리 쳐주는 타이핑 가속기'로만 쓰라는 거죠. 스코프를 늘리는 가속기가 아니라요.
핵심 통찰은 이거예요. 취미 코딩에서 희소한 자원은 더 이상 타이핑 시간이 아니라 '이해력'이라는 것. 코드를 생산하는 비용은 거의 0이 됐지만, 그 코드를 머릿속에 담아두는 비용은 그대로거든요.
한국 개발자에게도 남 얘기가 아니에요
요즘 커서나 클로드 코드 같은 도구로 사이드 프로젝트 하시는 분들 많잖아요. 시작한 지 2주 만에 인증, 결제, 어드민까지 갖춘 프로젝트가 뚝딱 나오는데, 정작 한 달 뒤에 버그 하나 고치려면 내 프로젝트인데도 남의 코드 읽는 기분이 들 때가 있죠. 포트폴리오용이라면 규모가 미덕일 수 있지만, 배움과 재미가 목적이라면 '내가 전부 이해하는 작은 프로젝트'가 여전히 답일 수 있어요.
한줄 요약: AI 시대의 사이드 프로젝트는 '얼마나 크게 만들 수 있나'가 아니라 '얼마나 작게 유지할 수 있나'가 실력이다.
여러분의 사이드 프로젝트는 어떤가요? AI 도구 도입 후에 프로젝트가 커져서 오히려 손이 안 가게 된 경험, 있으신가요? 아니면 반대로 혼자서는 불가능했던 걸 완성한 성공담이 있다면 들려주세요.
🔗 출처: Hacker News