대학 시절 7개의 AI 앱을 만들며 깨달은, 아무도 말해주지 않는 사실들
요약
대학 시절 7개의 AI 앱을 출시한 개발자의 경험을 바탕으로, 1인 개발자를 위한 효율적인 기술 스택과 제품 출시 전략을 공유합니다. Groq와 같은 고속 추론 도구 활용법과 MVP 중심의 빠른 실행력을 강조합니다.
핵심 포인트
- React, Vite, Tailwind CSS를 활용한 빠른 프론트엔드 구축
- Groq의 LPU를 활용한 초고속 AI 추론 경험 제공
- 완벽주의를 버리고 MVP를 빠르게 출시하여 사용자 피드백 확보
- 인증 시스템 등 공통 기능은 직접 구현하지 말고 외부 도구 활용
대부분의 학생은 대학에 입학했을 때 첫 번째 할 일 목록(to-do app) 튜토리얼을 따라 하며 헤매고 있습니다. 저는 대신 회사를 만들기로 결심했습니다.
저는 Ahmedabad에 위치한 IITRAM의 B.Tech 학생인 Adhitya입니다. 대학 생활 첫 2년 동안, 저는 저의 인디 스튜디오인 Rewrite Labs를 통해 7개의 실제 수익 창출이 가능한 AI 애플리케이션을 구축하여 출시했으며, 다른 개발자들이 사용하는 7개의 오픈 소스 라이브러리도 만들었습니다.
컴퓨터 과학 (CS) 학위는 필요하지 않았습니다. 대형 기술 기업에서의 인턴십도 없었습니다. 그저 노트북 한 대, 놀라운 도구들의 무료 티어 (free tiers), 그리고 제품을 출시하는 것에 대한 집착뿐이었습니다.
제가 시작하기 전에 누군가 말해줬으면 좋았을 모든 것들을 공유합니다.
1. 1인 AI 앱 개발자에게 실제로 작동하는 기술 스택 (Stack)
교훈을 말하기 전에, 제가 모든 앱에 사용하는 정확한 기술 스택을 소개하겠습니다. 고통스러운 시행착오 끝에 이 스택을 결정했으며, 그 이후로 바꿀 필요가 없었습니다.
| 계층 (Layer) | 도구 (Tool) | 이유 |
|---|---|---|
| 프론트엔드 (Frontend) | React + Vite + Tailwind CSS | 빠른 개발, 거대한 생태계 |
| ... | ... | ... |
이 스택을 사용하면 아이디어에서 실제 유료 앱 출시까지 일주일 미만으로 걸립니다. 모든 도구에는 무료 티어가 있습니다. 모든 도구는 훌륭한 문서화 (documentation)를 갖추고 있습니다. 혼자 개발할 때는 더 복잡한 것을 사용할 이유가 전혀 없습니다.
2. Groq는 당신의 AI 앱에 대한 생각을 바꿔놓을 것입니다
대부분의 사람들은 기본적으로 OpenAI를 선택합니다. 저도 약 5분 동안은 그랬습니다.
그러다 Groq를 사용해 보았는데, 마치 다이얼업(dial-up) 인터넷에서 광랜(fiber)으로 전환한 것 같은 기분이었습니다.
Groq는 LPU (Language Processing Units)라고 불리는 맞춤형 하드웨어에서 LLM 추론 (inference)을 실행합니다. 결과는 어떨까요? 응답이 너무 빠르게 스트리밍되어 즉각적인 것처럼 느껴집니다. 저의 AI 동반자(AI companion)인 Nura와 같은 채팅 앱의 경우, 이것은 제품이 살아있는 것처럼 느껴지는지 아니면 너무 깊게 생각하느라 버벅거리는 것처럼 느껴지는지의 차이를 만듭니다.
API가 OpenAI와 거의 동일하기 때문에 마이그레이션 (migration)이 매우 쉽습니다. 그리고 무료 티어는 단순히 "맛보기" 수준이 아니라 실제로 사용할 수 있는 수준입니다.
오늘 AI 앱을 만들고 있다면 Groq로 시작하세요. 모델은 나중에 언제든지 바꿀 수 있습니다.
3. 일단 투박하게 출시하세요. 다듬는 것은 나중에 하세요. 진심입니다.
저의 첫 번째 앱은 출시하기 전에 계속 다듬기만 했기 때문에 너무 오래 걸렸습니다.
잔혹한 진실은 이렇습니다: 당신이 말하기 전까지는 아무도 당신의 앱을 보지 않습니다. 즉, 첫 10명의 사용자를 만나기 전까지 픽셀 하나하나를 완벽하게 다듬는 데 쓰는 모든 시간은 낭비라는 뜻입니다.
저의 현재 프로세스는 다음과 같습니다:
- 2~3일 안에 핵심 기능 루프 (core feature loop) 구축
- 라이브 배포 (모습이 거칠더라도)
- 실제 사용자 5명 확보하여 사용하게 하기
- 고장 난 부분 수정
- 그다음에 다듬기
당신이 처음 출시하는 앱의 버전은 버전 1.0의 모습과 전혀 다를 것입니다. MVP (Minimum Viable Product, 최소 기능 제품)를 포트폴리오 작품처럼 대하는 것을 멈추세요.
4. 인증(Auth)은 당신의 문제가 아닙니다 — 직접 만들지 마세요
초기에 저는 커스텀 인증 시스템 (authentication system)을 구축하는 데 이틀을 허비했습니다. 세션 토큰 (Session tokens), 비밀번호 해싱 (password hashing), 이메일 인증 (email verification) 등 모든 것을 다 했습니다.
그러다 Clerk를 발견했고, 그 모든 것을 삭제했습니다.
Clerk가 제공하는 것들:
- 이메일 + 소셜 로그인
- API 라우트를 위한 JWT (JSON Web Token) 검증
- 사전 구축된 React 컴포넌트
- 사용자 관리 대시보드
설정에는 말 그대로 10분밖에 걸리지 않습니다. 월간 활성 사용자(MAU) 10,000명까지는 무료입니다. 2025년에 1인 개발자로서 인증 시스템을 직접 만드는 (hand-rolling) 시나리오는 단 하나도 없습니다.
같은 원칙이 어디에나 적용됩니다. 직접 데이터베이스 계층 (database layer)을 구축하는 대신 Supabase를 사용하고, 직접 서버를 관리하는 대신 Vercel을 사용하세요. 당신의 일은 인프라 (infrastructure)가 아니라 *제품 (product)*을 만드는 것입니다.
5. 수익화는 생각보다 쉽습니다 (일찍 시작한다면)
저는 두 번째 앱에 페이월 (paywall, 결제창)을 설치했습니다. 당시에는 대담하고, 거의 오만하게 느껴졌습니다. 대학생이 만든 것에 누가 돈을 지불할까 싶었으니까요.
결과는 이랬습니다: 가치를 느끼는 사람들이 있었습니다.
학생으로서 AI 앱의 가격을 책정하며 배운 점은 다음과 같습니다:
- 첫날부터 비용을 청구하세요. 무료 플랜도 괜찮지만, 유료 티어 (paid tier)를 두세요. 이는 당신이 돈을 지불할 가치가 있는 무언가를 만들도록 강제합니다.
- 구독 모델 (Subscriptions)이 일회성 결제보다 낫습니다. 반복 매출 (Recurring revenue)은 성장을 예측할 수 있게 해줍니다. Razorpay는 구독 플랜 API를 통해 이를 간단하게 만들어 줍니다.
- 페이월은 사실 하나의 기능입니다. 페이월은 진지하지 않은 사용자를 걸러냅니다. 유료 사용자는 더 좋은 피드백을 주고 더 오래 남습니다.
앱이 "준비"될 때까지 수익 모델에 대해 생각하는 것을 미루지 마세요. 비즈니스 모델은 처음부터 설계의 일부여야 합니다.
6. 오픈 소스 (Open Source)는 최고의 마케팅 수단입니다
제 앱들은 (지식 재산권(IP) 보호를 위해) 비공개이지만, 재사용 가능한 부분들을 추출하여 **7개의 오픈 소스 라이브러리 (open source libraries)**로 만들었습니다. 예를 들면 다음과 같습니다:
react-premium-gate— Razorpay 구독 페이월 (paywall) 컴포넌트react-macro-rings— 애니메이션 SVG 영양 상태 진행 링react-toast-native— 가벼운 토스트 알림 (toast notifications)groq-chain— LangChain 없이 Python으로 구현한 LLM 체이닝 (chaining)llm-router— 복잡도와 비용에 따라 프롬프트를 적절한 LLM으로 라우팅
각 라이브러리는 코드의 탈을 쓴 튜토리얼과 같습니다. 개발자들은 이를 발견하고, 사용하며, 누가 만들었는지 알게 됩니다. 이것은 가장 진정성 있는 형태의 마케팅입니다. 무언가를 파는 것이 아니라, 그저 유용함을 제공하는 것이니까요.
앱을 만들고 있다면, 계속해서 다시 만들고 있는 부분들을 찾아 오픈 소스로 공개하세요. 이는 당신의 GitHub 프로필, 평판, 그리고 네트워크를 동시에 구축해 줍니다.
7. 대학 시절 무언가를 만들 때 아무도 말해주지 않는 사실
모두가 기술적인 측면에만 집중합니다. 하지만 아무도 말하지 않는 더 어려운 부분은 바로 **멘탈 게임 (mental game)**입니다.
아무것도 작동하지 않는 몇 주를 보낼 수도 있습니다. 버그 하나를 찾는 데 사흘이 걸리는데, 알고 보니 단 하나의 누락된 await 때문인 경우도 있습니다. 무언가를 출시했는데 아무도 관심을 갖지 않을 수도 있습니다. 대학 과제와 운영 환경(production)의 치명적인 버그가 충돌할 수도 있습니다.
당신을 계속 나아가게 하는 것은 동기 부여가 아닙니다. 동기 부여는 신뢰할 수 없습니다. 당신을 계속 나아가게 하는 것은, 그럼에도 불구하고 매일 나타나서 무언가를 출시하는 습관을 기르는 것입니다.
저에게 도움이 되었던 몇 가지 방법들입니다:
- 빌드 인 퍼블릭 (Build in public) (조용히라도 하세요). 무엇을 만들고 있는지에 대해 글을 쓰는 것은 책임감을 만들어 줍니다.
- 매주 무언가를 출시하세요 (Ship something every week), 아주 작은 것이라도 좋습니다. 모멘텀 (Momentum)은 복리로 쌓입니다.
- 자아를 제품과 분리하세요. 당신의 앱이 실패했다고 해서 당신이 실패한 것은 아닙니다. 그것은 단지 시간 외에는 아무런 비용도 들지 않는 무언가를 배웠다는 뜻입니다.
승리하는 빌더(builder)는 가장 똑똑한 사람이 아닙니다. 재미가 없어졌을 때도 계속 나아가는 사람들입니다.
다음에 무엇을 만들 것인가
Rewrite Labs는 여전히 성장하고 있습니다. 앱 제품군(app suite)은 확장 중이며, 오픈 소스(OSS) 라이브러리 수도 늘어나고 있습니다.
만약 이 글을 읽고 있는 학생 중 시작할지 말지 고민하고 있다면 — 시작하세요. 도구들은 그 어느 때보다 저렴해졌고, 지식은 그 어느 때보다 접근하기 쉬워졌으며, 시장은 AI 제품에 그 어느 때보다 열려 있습니다.
허락은 필요 없습니다. 그저 출시(ship)하면 됩니다.
계속 지켜봐 주세요 — Dev.to의 바로 이곳에 기술적인 심층 분석(technical deep-dives), 빌드 로그(build logs), 그리고 현장에서 얻은 솔직한 교훈들을 게시할 예정입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기