AI 기준 기술 스택 제안 (2026)
먼저 전제: "AI 친화적"이란 무엇인가
AI 코드 생성 품질을 결정하는 요소는 세 가지입니다.
| 요소 |
설명 |
| 훈련 데이터 볼륨 |
GitHub 공개 레포, 공식 문서, Stack Overflow 누적량 |
| 패턴 일관성 |
같은 기능을 구현하는 방식이 생태계 내에서 얼마나 통일되어 있는가 |
| 타입 명시성 |
AI가 컨텍스트 힌트를 얼마나 읽을 수 있는가 |
솔직한 언어/프레임워크 AI 품질 평가
Tier 1 — AI가 가장 잘 생성하는 영역
TypeScript (React/Next.js)
Python (FastAPI, Django)
SQL (표준 ANSI SQL)
이유: 훈련 데이터 압도적, 패턴 수렴도 높음, 오류 복구 쉬움
Tier 2 — AI가 충분히 잘 생성하나 보정 필요
C# / ASP.NET Core 8
Java (Spring Boot)
PostgreSQL 고급 기능
C#에 대해 솔직히 말씀드리면:
- Microsoft가 GitHub Copilot 훈련에 직접 투자했기 때문에 C# AI 품질은 생각보다 좋습니다
- CQRS + MediatR 패턴은 훈련 데이터에 상당히 존재합니다
- 다만 "최신 .NET 8 기능 + Dapper + 특수 패턴" 조합에서 hallucination이 늘어납니다
Tier 3 — AI가 틀리기 쉬운 영역
Vue.js 3 CDN (no build tools, Options API)
MSSQL 특수 문법 (일부)
최신 실험적 프레임워크
한국 로컬 라이브러리
Vue.js 3 CDN에 대해 솔직히:
AI는 기본적으로 Vue SFC + Vite 형태로 생성합니다. CDN + Options API 패턴을 강제하려면 반드시 .cursorrules / AGENTS.md 에 명시적 주입이 필요하며, 이 비용이 실제로 존재합니다.
도메인별 2026 최적 스택 제안
Case 1: 비개발자 + 빠른 MVP
Frontend : Next.js 15 + TypeScript
UI : Tailwind CSS + shadcn/ui
Backend : Next.js API Routes (초기) → FastAPI (확장)
DB : PostgreSQL + Drizzle ORM
Auth : Clerk 또는 Better Auth
Deploy : Vercel + Supabase
Drizzle 선택 이유 (Prisma 대비):
- SQL에 가까운 추상화 → AI 추론 오류 적음
- Migration 파일이 plain SQL → 검토 용이
- 단, 이것은 커뮤니티 피드백 기반이며 제가 벤치마크를 직접 측정한 건 아닙니다 (불확실성 명시)
Case 2: 엔터프라이즈 ERP / 그룹웨어
여기서 핵심적으로 다른 말씀을 드립니다.
CQRS가 AI에게 왜 유리한가:
// AI는 이 구조를 매우 명확하게 이해합니다
// Command: 쓰기 의도가 명시적
public record CreateWorkOrderCommand(string Title, int AssigneeId) : IRequest<int>;
// Query: 읽기 의도가 명시적
public record GetWorkOrderListQuery(int DepartmentId) : IRequest<List<WorkOrderDto>>;
CQRS는 AI에게 "이 코드가 무엇을 하는지"를 명시적으로 알려주는 구조입니다. 오히려 AI 컨텍스트 전달 측면에서 장점입니다. 문서가 CQRS를 "독"이라 한 건 비개발자 MVP 맥락에서만 유효한 말입니다.
Case 3: AI Agent / AI 기능 탑재 시스템
AI Backend : Python (FastAPI + LangGraph 또는 직접 Anthropic SDK)
Web Backend : ASP.NET Core 8 또는 Next.js API
통신 : REST 또는 gRPC
솔직한 말: Python은 AI/ML 생태계에서 압도적입니다. AI 에이전트 백엔드를 C#으로 구축하는 것은 가능하지만, 훈련 데이터와 라이브러리 생태계 면에서 Python 대비 열세입니다. 이건 사실입니다.
핵심 제안
"스택 전환"보다 "하니스 강화"가 먼저입니다
현재 ASP.NET Core 8 + CQRS 스택을 버리고 Next.js로 가는 것은 잘못된 우선순위입니다.
이유:
- 도메인 지식 비용: 결재/근태/권한 도메인을 새 스택에서 다시 설계하는 비용이 AI 생산성 향상을 상쇄합니다
- C# AI 품질은 충분: Tier 2지만 CQRS + MediatR + Dapper 조합은 훈련 데이터에 존재합니다
- 진짜 병목은 스택이 아닙니다
진짜 병목은 이것입니다
[현재 AI 코딩의 실제 병목]
1. AI가 내 코드베이스를 얼마나 아는가 → AGENTS.md / rules 품질
2. AI 생성 코드를 얼마나 빠르게 검증하는가 → 테스트 전략
3. AI가 틀렸을 때 얼마나 빠르게 복구하는가 → 오류 복구 패턴
4. AI에게 올바른 제약을 얼마나 잘 주입하는가 → 하니스 엔지니어링
스택보다 이 네 가지가 더 중요합니다.
권장하는 실제 로드맵
단기 (현재 프로젝트)
기존 스택 유지
+ AGENTS.md 고도화 (anti-pattern 명시, 도메인 규칙 주입)
+ Vue.js 3 → Vite + SFC 전환 고려 (CDN 방식의 AI 비용 줄이기)
+ 단위 테스트 최소 Command/Query 핸들러에 추가
중기 (신규 프로젝트 착수 시)
Frontend : Next.js + TypeScript (기존 Vue CDN 탈피)
Backend : ASP.NET Core 8 유지 (도메인 지식 활용)
DB : PostgreSQL 검토 (MSSQL 유지도 나쁘지 않음)
AI 기능 : Python FastAPI 마이크로서비스 분리
장기 (AI Agent 통합 시)
Orchestrator : Python (LangGraph 또는 직접 Anthropic API)
Web System : ASP.NET Core 8 (안정적 운영)
Frontend : Next.js
통신 : REST API 또는 MQ (RabbitMQ / Azure Service Bus)
불확실하다고 명시하는 부분
| 주장 |
확실성 |
| TypeScript/Next.js AI 품질 최상위 |
✅ 높음 |
| C# AI 품질 Tier 2 |
✅ 높음 |
| CQRS가 AI 컨텍스트에 유리 |
✅ 높음 (구조적 이유) |
| Drizzle이 Prisma보다 AI hallucination 적음 |
⚠️ 커뮤니티 경험 기반, 직접 측정 아님 |
| Python FastAPI AI 품질 우위 |
✅ 높음 |
| Vue CDN AI 비용 존재 |
✅ 높음 (패턴 불일치 명확) |
결론
스택을 바꾸는 것보다, 현재 스택에서 AI가 정확하게 작동하도록 하니스를 고도화하는 것이 단기 ROI가 더 높습니다. 단, 신규 프로젝트라면 TypeScript + Next.js 생태계로 가는 것이 2026 기준 최선입니다.