이 글의 배경이 되는 이야기는 6화: 제품 100만 개를 담을 그릇에서 읽을 수 있습니다.
이 글을 읽으면 알 수 있는 것
- 비개발자가 기술 스택을 고를 때 어떤 기준이 작동하는지
- Django vs FastAPI, Next.js vs React SPA의 선택 논리
- “AI가 잘 아는 기술”이 스택 선택에 미치는 영향
문제: 뭘로 만들 것인가
프로젝트의 방향이 정해지고, 데이터 수집 구조가 윤곽을 잡은 시점에서 기술 스택을 결정해야 했습니다.
비개발자에게 이 결정은 특이한 상황입니다. 보통 개발자는 이전 프로젝트 경험, 팀 역량, 커뮤니티 규모 등을 기준으로 스택을 고릅니다. 저에게는 이전 경험이 없었습니다. 모든 것이 처음이었습니다.
대신 있었던 것은 AI 파트너였습니다. 코드의 대부분을 AI와 함께 작성하는 구조이므로, “AI가 이 기술을 얼마나 잘 아는가”가 중요한 기준이 됐습니다.
백엔드: Django vs FastAPI
AI에게 물었습니다. “식품 데이터 100만 건을 관리하고, ETL 파이프라인을 돌리고, REST API를 제공하는 백엔드를 만들려면 뭐가 좋을까?”
두 가지 선택지가 나왔습니다.
| 기준 | Django | FastAPI |
|---|---|---|
| ORM / 마이그레이션 | 내장 (강력) | 별도 설정 (SQLAlchemy) |
| Admin 패널 | 내장 | 없음 |
| ETL 커맨드 | management command 패턴 | 직접 구축 |
| API 구축 | DRF (성숙한 생태계) | 기본 제공 (빠름) |
| AI 학습 데이터 양 | 매우 많음 | 많음 |
Django를 선택했습니다. 이유가 세 가지 있습니다.
첫째, management command 패턴. Django에는 python manage.py import_i1250 같은 형태로 ETL 작업을 실행하는 구조가 기본 제공됩니다. 12개 데이터 소스를 각각 커맨드로 만들고, 공통 로직은 부모 클래스에서 상속받는 구조가 자연스러웠습니다. FastAPI에서는 이 구조를 직접 만들어야 했습니다.
둘째, Admin 패널. 데이터 100만 건을 적재한 후, “이 제품의 원재료가 제대로 들어갔는가”를 확인하려면 관리 도구가 필요합니다. Django Admin은 코드 몇 줄로 조회·검색·수정 화면을 만들어줍니다. 매칭 결과를 검수할 때 특히 유용했습니다.
셋째, AI의 숙련도. Django는 2005년부터 존재하는 프레임워크입니다. 인터넷에 축적된 코드 예제, 에러 해결법, 패턴이 방대합니다. AI에게 질문했을 때 정확한 답이 돌아올 확률이 높았습니다.
프론트엔드: Next.js vs React SPA
| 기준 | Next.js | React SPA |
|---|---|---|
| 라우팅 | 파일 기반 자동 | react-router 직접 설정 |
| SEO | SSR/SSG 지원 | 추가 작업 필요 |
| 배포 | Vercel 최적화 | 별도 설정 |
| 학습 곡선 | 약간 높음 | 낮음 |
Next.js를 선택했습니다.
식품 성분 분석 서비스는 검색 엔진에 노출되는 것이 중요합니다. “새우깡 성분”을 검색했을 때 이 서비스가 나와야 합니다. React SPA는 검색 엔진 최적화(SEO)에 추가 작업이 필요하지만, Next.js는 서버 사이드 렌더링(SSR)을 기본 지원합니다.
그리고 Vercel이라는 배포 플랫폼과의 궁합이 좋았습니다. Next.js를 만든 회사가 운영하는 플랫폼이라, 배포 과정이 단순합니다. 비개발자에게 배포의 단순함은 큰 장점이었습니다.
데이터베이스: PostgreSQL
데이터베이스는 고민이 적었습니다.
MySQL과 PostgreSQL 중에서 PostgreSQL을 선택한 이유는 두 가지입니다.
Full-text Search 지원. 원재료 이름으로 제품을 검색하는 기능이 필요했습니다. PostgreSQL은 한국어 전문 검색을 DB 수준에서 지원합니다. 별도의 검색 엔진(Elasticsearch 등)을 도입하지 않아도 되었습니다.
JSON 필드 지원. API 원본 응답을 그대로 저장하는 용도로 JSON 필드를 사용합니다. PostgreSQL의 jsonb 타입은 JSON 데이터를 효율적으로 저장하고 쿼리할 수 있습니다.
인프라: Railway + Vercel
| 항목 | 선택 | 이유 |
|---|---|---|
| 백엔드 배포 | Railway | PostgreSQL 원클릭, Django 자동 감지 |
| 프론트 배포 | Vercel | Next.js 공식 호스팅, 무료 티어 |
| 로컬 개발 | Docker Compose | PostgreSQL + Django를 한 번에 |
스타트업 단계에서 AWS를 직접 구축하는 것은 과잉이라고 판단했습니다. Railway와 Vercel은 코드를 올리면 자동으로 빌드하고 배포해주는 서비스입니다. 인프라를 직접 관리하지 않아도 됩니다.
AI가 스택 선택에 미친 영향
돌이켜 보면, 기술 스택 선택에서 가장 큰 영향을 미친 것은 **“AI가 이 기술을 잘 아는가”**였습니다.
| 기술 | AI 숙련도 | 체감 |
|---|---|---|
| Django | 매우 높음 | 복잡한 ORM 쿼리도 정확히 생성 |
| FastAPI | 높음 | 정확하지만 Django보다 예제가 적음 |
| Next.js | 높음 | App Router 최신 패턴도 이해 |
| Tailwind CSS | 매우 높음 | UI 수정 시 속도가 5배 이상 빠름 |
“AI와 함께 개발한다”는 것은 단순히 “AI에게 코드를 시킨다”는 뜻이 아닙니다. AI가 잘 아는 기술을 선택하면, AI의 도움 품질이 올라갑니다. 마이너한 프레임워크를 선택하면 AI가 환각(Hallucination)을 일으킬 확률이 높아집니다.
이것은 비개발자가 AI와 개발할 때 특히 중요한 기준입니다. 개발자는 AI의 틀린 답을 잡아낼 수 있지만, 비개발자는 그렇지 못합니다. AI가 자신 있게 틀리면, 비개발자는 그 틀린 코드를 그대로 사용합니다.
결과
| 항목 | 선택 |
|---|---|
| 백엔드 | Django 5.x + DRF + PostgreSQL |
| 프론트엔드 | Next.js (App Router) + Tailwind CSS |
| 배포 | Railway (백엔드) + Vercel (프론트) |
| 로컬 | Docker Compose |
한계
Next.js App Router는 아직 변화가 빠릅니다. 버전이 올라갈 때마다 API가 바뀌는 경우가 있어서, AI가 이전 버전의 패턴을 제안하는 일이 가끔 있었습니다.
Railway 무료 티어의 한계. 무료 크레딧이 소진되면 유료로 전환해야 합니다. MVP 단계에서는 충분하지만, 트래픽이 늘면 비용 구조를 재검토해야 합니다.
한 줄 교훈
AI와 함께 개발할 때, “이 기술이 좋은가”보다 “이 기술을 AI가 잘 아는가”가 더 중요한 기준일 수 있습니다.