이 기사에서는 AI 에이전트에게 코드를 작성하게 하는 「AI 주도 개발 (AI-Driven Development)」과 궁합이 좋은 기술 스택을 정리합니다.

기술 스택의 궁합은 물론 개발하는 앱의 사양이나 실행 환경, 팀 체제 등에 따라서도 달라집니다.

이번에는 그중에서도 어디까지나 「AI 주도 개발과의 궁합」을 전면에 내세워 조사했습니다.

공개된 통계·연구·공식 문서의 원전을 확인하면서, 저 자신이 여러 서비스를 병행하여 개발·운영하는 과정에서 느끼고 있는 감각을 섞어서 쓰고 있습니다.

대상 독자는 다음과 같은 분들을 상정하고 있습니다.

• 앞으로 개인 개발이나 사내 SaaS의 기술 선정을 할 엔지니어
• 이미 Claude Code나 Cursor 등으로 코드를 작성하게 하고 있으며, 「어떤 언어·구성이 에이전트와 가장 잘 맞는지」를 언어화하고 싶은 분
• 「AI가 잘 아는 언어」만으로 선택했다가, 나중에 타입 붕괴나 할루시네이션 (Hallucination)으로 고민하고 있는 분

기술 선정은 사업의 페이즈·팀의 숙련도·운영 체제에도 좌우되기 때문에, 이 기사의 내용이 유일한 정답이라는 뜻은 아닙니다.

본문의 통계·버전은 모두 2026년 7월 시점의 것이며, 이 영역은 몇 개월 만에 상황이 변합니다.

• 현시점에서 제가 가장 유력하다고 생각하는 구성은 용도에 따라 3계통으로 나뉩니다. Web·업무 시스템은 TypeScript, AI·데이터 처리는 Python, Gateway·상주 서비스는 Go입니다.
• 범용적인 Web 개발에서는, TypeScript를 중심으로 두고, 필요한 부분만 Python이나 Go로 분리하는 구성이 가장 균형 잡혀 있다고 느낍니다. - AI 주도 개발과의 궁합은 「LLM이 해당 언어를 알고 있는가」만으로 결정되지 않습니다. 타입(Type)·LSP·컴파일러(Compiler)·테스트·규약의 명확성과 같이 「AI의 오류를 기계적으로 검출할 수 있는가」가 그만큼 중요합니다.
• Python은 LLM이 가장 잘 아는 언어 중 하나이지만, 있는 그대로라면 생성된 오류를 실행 전에 발견하기 어렵습니다. 타입 힌트 (Type Hint)·Pydantic·Pyright·Ruff·pytest와 세트로 「타입이 지정된 Python」으로서 운용한다는 전제하에 선택하고 있습니다.
• 기술의 이름을 정하는 것보다, 리포지토리(Repository) 측에서 검증 명령어를 하나로 고정해 두는 것이 체감상 효과가 더 큽니다.
• 처음부터 TypeScript·Python·Go·Rust를 전부 넣는 것은 피하고 있습니다. 우선 TypeScript로 모듈러 모놀리스 (Modular Monolith)를 만들고, 측정 결과가 나온 부분만 다른 언어로 분리해 나가는 단계적인 확장을 기본 방침으로 하고 있습니다.

먼저 전제 정리부터 하겠습니다.

「AI가 잘 아는 언어를 선택하면 된다」라는 이야기를 자주 듣지만, 실제로 오랫동안 에이전트에게 코드를 작성하게 하다 보면 그것만으로는 부족하다고 느낍니다.

제 안에서는 궁합을 다음과 같은 곱셈으로 파악하고 있습니다.

AI 주도 개발과의 궁합
＝ LLM의 언어 이해도
× 타입·LSP에 의한 의미 해석
...

곱셈이기 때문에, 어느 하나라도 극단적으로 낮으면 전체가 무너집니다.

예를 들어 LLM이 아무리 잘 알더라도, 생성한 오류를 실행 전에 검출할 수 없는 언어라면 리뷰 비용이 치솟습니다.

반대로, 다소 코드량이 적은 언어라도 컴파일러와 테스트를 통해 「올바른지 여부」를 매번 기계적으로 확인할 수 있다면, 수정 루프는 오히려 안정됩니다.

이 관점에서 보면, AI 주도 개발의 기술 선정은 「LLM이 알고 있는가」에서 「AI의 실수를 얼마나 빠르고 확실하게 없앨 수 있는가」로 축이 이동합니다.

상용 LLM은 언어별 학습 토큰 수를 공개하지 않습니다.

따라서 다음은 공개된 코드량·문서량·이용자 수·코드 생성 연구·도구의 성숙도로부터의 종합적인 견해입니다.

코드 생성 연구에서도 Python·Java·JavaScript와 같은 「고리소스 언어 (High-resource language)」는, 코드나 문서가 적은 언어보다 LLM의 생성 성능이 높아지기 쉽다는 점이 지적되고 있습니다.

다음 표는 저의 주관을 포함한 종합 평가입니다.

이것은 범용적인 언어 성능 순위가 아니라, Web·SaaS를 중심으로 생성 후의 검증 루프까지 포함하여 평가한 주관적 랭크입니다.

머신러닝 (Machine Learning) 연구라면 Python, 임베디드나 시스템 개발이라면 Rust나 C++, 대규모 기존 업무 시스템이라면 Java나 C#이 상위에 오는 경우도 있습니다.

「AI 주도 개발 적성」의 S / A와 같은 랭크는 어디까지나 감각적인 정리이므로, 참고 정도로 봐주시기 바랍니다.

GitHub의 Octoverse 2025에 따르면, 월간 컨트리뷰터 수 기준으로 2025년 8월 시점에 TypeScript가 처음으로 Python을 제치고 가장 많이 사용된 언어가 되었습니다.

GitHub는 주요 프레임워크가 TypeScript를 기본값으로 설정하고 있다는 점에 더해, AI 지원 개발과 타입 지정 언어(Typed Language)의 성장이 상관관계가 있다고 분석합니다.

다만, 이는 어디까지나 관찰된 시그널일 뿐, AI가 TypeScript로의 이행을 일으켰다는 인과관계까지 실증한 것은 아닙니다.

해당 리포트가 인용하고 있는 연구에서는, 여러 오픈 LLM에 TypeScript로 코드를 생성·변환·수정하게 한 실험에서 발생한 컴파일 에러의 평균 94%가 타입 체크(Type Check) 실패였다고 보고되었습니다.

실제 개발에서 발생하는 모든 LLM 에러에 일반화할 수 있는 수치는 아니지만, 생성 시 발생하는 기계적인 에러의 상당 부분을 타입 검사로 받아낼 수 있는 가능성을 보여주는 사례라고 생각합니다.

한편, Python은 AI·데이터 사이언스 영역에서 계속해서 중심적인 존재입니다.

Stack Overflow의 2025년 조사에서도 JavaScript, SQL, Python 같은 언어들이 상위에 나란히 이름을 올렸으며, TypeScript도 주요 언어 중 하나로 정착했습니다.

LLM이 JavaScript, TypeScript, React 코드를 대량으로 학습하고 있다는 점에 더해, TypeScript에는 다음과 같은 장점이 있습니다.

• 타입이 코드 내에 명시됨
• 프론트엔드와 백엔드를 동일한 언어로 작성 가능
• JSON, HTTP, 브라우저와의 대응이 자연스러움
• 타입 체크가 빠름
• React, Node.js, 테스트, UI 라이브러리가 풍부함
• AI가 수정한 직후에 에러를 기계적으로 검출할 수 있음

이 "수정 직후에 기계가 오류를 알려준다"는 점이 AI 주도 개발에서는 특히 효과적입니다.

다만, any나 타입 어설션(Type Assertion)을 남용하면 이 장점은 쉽게 사라집니다.

최소한 다음과 같은 설정으로 타입의 빈틈을 막아두는 것이 전제되어야 한다고 생각합니다.

{
"compilerOptions": {
"strict": true,
...

Python은 LLM이 가장 잘 알고 있는 언어 중 하나입니다.

반면 동적 타입 지정(Dynamic Typing) 언어이기 때문에, 그대로 사용하면 AI가 생성한 오류를 실행 전에 찾아내기 어렵다는 약점이 있습니다.

제가 과거에 고생했던 경우도 대부분 Python의 "타입을 작성하지 않은 계층"이었습니다.

따라서 AI 주도 개발에서는 Python을 단독으로 사용하는 것이 아니라, 다음과 같은 세트로 "타입이 지정된 Python"으로서 운용하고 있습니다.

Python
+ 타입 힌트 (Type Hints)
+ Pydantic
...

Pyright는 커맨드라인 타입 검사와 Language Server를 모두 제공합니다.

생성된 코드에 대해 타입 검사를 매번 실행함으로써 동적 타입 지정의 약점을 상당히 보완할 수 있습니다.

Go는 TypeScript나 Python만큼 코드량이 많지 않을 수도 있습니다.

그럼에도 불구하고 다음과 같은 특성 덕분에 실제 AI 수정 루프가 안정적으로 돌아간다고 느낍니다.

• 언어 사양이 비교적 작음
• 표준 포매터(Formatter)가 통일되어 있음
• 컴파일이 빠름
• 암시적인 메타 프로그래밍(Metaprogramming)이 적음
• 표준 라이브러리가 풍부함
• 단일 바이너리로 만들기 쉬움
• gopls가 매우 성숙해 있음

암시적인 마법이 적은 만큼, AI가 읽어도 실행 시의 동작을 상상하기 쉽습니다.

특히 LLM Gateway, MCP 서버, CLI, 데몬(Daemon), 백그라운드 워커와 같이 "빠르고 잘 망가지지 않는 상주 서비스"를 만들고 싶은 상황에서는 유력한 선택지가 됩니다.

언어 선택 이야기를 하다 보니 타입이나 LSP가 반복해서 나오므로, 여기서 한 번 LSP의 역할을 정리하겠습니다.

LSP (Language Server Protocol)는 에디터나 에이전트에게 다음과 같은 "의미 정보"를 제공하는 메커니즘입니다.

• 정의로 이동 (Go to Definition)
• 참조 위치 열거 (Find References)
• 심볼 검색 (Symbol Search)
• 타입 정보 (Type Information)
• 인터페이스 구현 (Interface Implementation)
• 이름 변경 (Rename)
• 진단 에러 (Diagnostic Errors)
• 코드 액션 (Code Action)
• 자동 완성 (Completion)

LSP는 에디터와 Language Server 간의 통신 방식을 표준화한 것입니다.

이를 통해 서로 다른 에디터나 AI 도구에서도 동일한 의미 분석 (Semantic Analysis) 기능을 사용할 수 있습니다.

LLM만으로 코드를 찾는다면, 기본적으로는 문자열 검색 (String Search)이 됩니다.

각 수단이 "코드를 어떻게 바라보고 있는지"를 나열해 보면 그 차이가 명확해집니다.

LLM + grep
→ 코드를 문자열로 바라봄
LLM + Tree-sitter
...

이러한 단계적 축적을 바탕으로, 제가 이상적으로 생각하는 코딩 에이전트 (Coding Agent)의 동작 순서는 다음과 같습니다.

언어를 선택할 때 "LSP가 성숙해 있는가"를 신경 쓰는 이유는, 이 5~9번의 피드백이 더 빠르고 정확해지기 때문입니다.

주요 Language Server를 정리하면 다음과 같습니다.

Go의 gopls는 Go 팀 공식이며, 내비게이션(Navigation)・자동 완성(Completion)・진단(Diagnostics)・분석(Analysis)・리팩터링(Refactoring)을 제공합니다.

나아가 gopls는 v0.20(2025년 7월)부터 실험적인 MCP 서버를 내장하여, Claude Code와 같은 AI 어시스턴트가 의미 분석 기능을 호출할 수 있도록 되어 있습니다.

즉, gopls가 가진 기능 중 일부를 MCP 도구로 공개하여 에이전트가 사용할 수 있는 방향으로 나아가고 있는 것입니다.

typescript-language-server는 VS Code가 내부적으로 사용하는 tsserver를 LSP 대응 에디터용으로 래핑(Wrap)한 비공식 어댑터입니다.

여기서부터는 실제로 구축할 때의 구성을 용도별로 작성하겠습니다.

거듭 말씀드리지만, 이는 현재 시점에서의 저의 구성 방식일 뿐 유일한 정답은 아닙니다.

Web 중심의 서비스에서는 TypeScript를 중심으로 다음과 같은 구성을 기본으로 하고 있습니다.

Language TypeScript
Frontend React
App 설계 Next.js App Router / React SPA
...

Next.js와 Vite는 어느 쪽이 더 우수하다는 이야기가 아니라, 적합성에 따라 선택하고 있습니다.

Next.js가 적합하다고 느껴지는 상황은 다음과 같습니다.

• SEO가 중요할 때
• SSR(Server Side Rendering)이나 빌드 시 생성(SSG)이 필요할 때
• LP(Landing Page)・미디어・SaaS를 일체화하고 싶을 때
• Server Components나 Server Actions를 사용하고 싶을 때
• Vercel에서 운영할 때

반면, Vite + React가 적합하다고 느껴지는 상황은 다음과 같습니다.

• 관리자 페이지나 사내 업무용 앱
• SEO가 불필요할 때
• 백엔드 API를 명확하게 분리하고 싶을 때
• SSR・캐시(Cache)・Server/Client 경계를 도입하고 싶지 않을 때
• 구성을 단순하게 유지하고 싶을 때

AI 주도 개발 (AI-Driven Development) 관점에서만 본다면, SEO가 불필요한 업무용 앱에서는 Vite + React가 더 단순하고 견고할 수 있습니다.

Next.js는 LLM이 잘 알고 있는 편이지만, 다음과 같은 혼동이 일어나기 쉽기 때문입니다.

• App Router와 Pages Router의 혼동
• Server Component와 Client Component의 혼동
• Route Handler와 Server Action의 혼동
• 캐시 사양의 버전 차이
• Node Runtime과 Edge Runtime의 차이
• 오래된 API 생성

그렇다고 해서 이것이 Next.js가 뒤처진다는 뜻은 아닙니다.

기능이 방대한 만큼 선택지가 많아서, AI가 서로 다른 세대의 API를 섞어서 생성하기 쉽다는 의미일 뿐입니다.

Next.js를 사용하는 경우에는 이용 버전을 고정하고, 현재의 공식 문서를 에이전트(Agent)에게 전달하도록 하고 있습니다.

ORM도 자주 질문을 받기에, 저의 정리를 적어둡니다.

결론부터 말하자면, 둘 다 AI와 궁합이 좋으며, 팀의 SQL 숙련도에 따라 선택하는 것이 가장 솔직한 방법이라고 생각합니다.

Prisma의 장점은 LLM이 잘 알고 있고, 문서와 사례가 많으며, 스키마(Schema)가 명확하고, 생성되는 타입(Type)이 강력하며, CRUD를 빠르게 만들 수 있다는 점입니다.

단점은 독자적인 스키마 언어가 늘어나고, 생성된 클라이언트(Client)에 대한 이해가 필요하며, 복잡한 SQL에서 추상화가 누락되기 쉽고, 마이그레이션 (Migration) 동작을 파악해야 한다는 점입니다.

Drizzle의 장점은 TypeScript와 SQL의 대응이 명시적이고, 추상화가 얇으며, AI가 SQL로 변환하기 쉽고, 타입과 테이블 정의가 가까워 생성된 코드를 추적하기 쉽다는 점입니다.

단점은 Prisma보다 사례가 적고, 고도의 처리를 위해서는 SQL 지식이 필요하며, 라이브러리 업데이트 시 정보가 섞이기 쉽다는 점입니다.

저의 구분 방식은 대략 다음과 같습니다.

일반적인 CRUD 중심의 SaaS
→ Prisma
SQL을 이해하고 있으며, 투명성을 중시하고 싶을 때
...

하지만 AI에게 정말 중요한 것은 ORM의 이름이 아닙니다.

스키마(Schema)・마이그레이션(Migration)・제약 사항(Constraint)・테스트(Test)가 리포지토리(Repository) 내에 명시되어 있는 것이 훨씬 더 효과적입니다.

AI 기능이 있다고 해서 시스템 전체를 Python으로 만들 필요는 없다고 생각합니다.

저는 오히려 언어를 역할에 따라 나누는 구성을 선호합니다.

Python 측은 다음과 같은 구성으로 묶고 있습니다.

FastAPI
Pydantic
SQLAlchemy
...

이때 중요한 것은 TypeScript 측과 Python 측의 경계에 스키마를 두는 것입니다.

OpenAPI 또는 JSON Schema를 단일 진실 공급원(Single Source of Truth)으로 삼아 양측의 타입을 생성합니다.

이때 OpenAPI를 기준으로 하는 '계약 우선 (Contract-first)' 방식과, Python 구현으로부터 OpenAPI를 출력하는 '코드 우선 (Code-first)' 방식을 혼재시키지 않는 것도 중요합니다.

수동으로 타입을 이중 관리하면, 한쪽만 수정하여 시스템이 망가지는 사고가 발생합니다.

AI는 특히 이러한 이중 관리를 조용히 망가뜨리는 경향이 있으므로, 경계의 타입은 생성 방식에 가깝게 유지합니다.

LLM Gateway나 상주 프록시(Proxy)와 같은 서비스에서는 Go를 유력한 후보로 두고 있습니다.

Language Go
Language Server gopls
HTTP net/http / chi
...

Go를 선택하는 이유는 생성 능력 그 자체보다, 생성 후의 검증이 단순하기 때문입니다.

다음 4단계를 매번 에이전트에게 실행하게 하면, 구문(Syntax)・타입(Type)・정적 분석(Static Analysis)・테스트(Test)・빌드(Build)를 짧은 시간 안에 확인할 수 있습니다.

gofmt -w .
go vet ./...
go test ./...
...

이 루프의 짧음이 상주 서비스의 안정적인 운용에 그대로 직결됩니다.

이 부분은 특히 호불호가 갈리는 부분이기에, "저는 이렇게 피하고 있습니다"라는 방식으로 작성하겠습니다.

너무 최신인 프레임워크는 LLM이 구버전의 API를 생성하기 쉽고, 검색 결과나 학습 데이터도 섞이기 쉽습니다.

독자적인 DSL이나 사내 프레임워크는 공개된 코드나 문서가 적어, 모델이 추측으로 구현해 버립니다.

동적 메타 프로그래밍 (Dynamic Metaprogramming)에 과도하게 의존하는 것도 코드를 읽어도 실행 시의 동작을 알기 어렵게 만들며, LSP나 정적 분석을 약화시킵니다.

초기 단계부터의 마이크로서비스 (Microservices)화는 리포지토리・계약・배포・로그・인증・테스트가 분산되어 에이전트의 컨텍스트 (Context) 소비를 증가시킵니다.

같은 TypeScript라도 Serverless・Edge・Node를 무질서하게 섞으면, 이용 가능한 API나 런타임 (Runtime) 제약이 달라져 혼란의 원인이 됩니다.

비슷한 역할의 라이브러리를 병용하는 것도 가급적 피하고 있습니다.

Jest + Vitest
Prisma + Drizzle
Express + Fastify + Hono
...

AI는 "어떤 스타일을 사용해야 하는지"를 판단하지 못하며, 기존 코드와 다른 패턴을 추가하기 쉽습니다.

너무 최신 기술이나 독자적인 규약이 많은 기술을 피한다는 생각은, 참고한 Zenn 기사의 지적과도 일치합니다.

오랫동안 운용하며 가장 실감하는 것은 기술 그 자체보다 일관성(Consistency)이 더 효과적이라는 점입니다.

AI가 다루기 쉬운 것은 다음과 같이 역할이 정리되고 검증 명령어가 고정된 리포지토리입니다.

repo/
├── apps/
│ ├── web/
...

그 위에 에이전트에게 전달할 명령어를 고정해 둡니다.

make format
make lint
make typecheck
...

이상적인 것은 make check나 pnpm check와 같은 단 한 번의 명령어로 최소한 다음 사항들을 실행할 수 있는 상태입니다.

format check
→ lint
→ typecheck
...

AI에게 매번 복잡한 명령어를 생각하게 하는 것이 아니라, 리포지토리 측에서 "올바른 검증 방법"을 고정해 두는 것입니다.

이 작은 수고가 생성(Generation) → 검증(Verification) → 수정(Correction) 루프의 안정성을 몇 배나 높여줍니다.

현재 제가 도달한 구성을 마지막으로 다시 한번 정리하겠습니다.

범용적인 SaaS 및 업무용 애플리케이션의 표준은 다음과 같은 구성입니다.

TypeScript (strict)
React
Next.js 또는 Vite
...

Python 고유의 ML(머신러닝)·데이터 처리 라이브러리가 필요한 부분은 Python 계열(FastAPI, Pydantic, Pyright strict, Ruff, pytest)로의 분리를 검토합니다.

LLM API 호출이나 RAG, SSE 스트리밍, 일반적인 Gateway는 TypeScript로도 충분히 작성할 수 있으므로, 우선은 TypeScript로 구현합니다.

그 후, 부하 측정이나 운영 요구사항에 따라 병렬 처리 성능, 메모리 효율, 단일 바이너리 배포 등이 필요해지는 단계에서 Go 계열(gopls, pgx, sqlc, OpenTelemetry)로의 분리를 검토합니다.

언어를 늘릴수록 API 계약, 배포, 모니터링, 장애 대응 비용도 증가하므로, 분리 조건은 "기능 카테고리"가 아니라 "TypeScript로는 충족할 수 없는 구체적인 요구사항"에 두는 것이 안전하다고 생각합니다.

가장 피해야 할 것은 처음부터 TypeScript, Python, Go, Rust를 모두 집어넣는 것입니다.

기본 방침은 다음과 같은 단계적인 확장입니다.

AI 주도 개발(AI-Driven Development)의 기술 선정 축이 "LLM이 해당 언어를 알고 있는가"에서 "AI의 실수를 얼마나 빠르고 확실하게 잡아낼 수 있는가"로 이동하고 있다는 점이 이번에 제가 가장 전달하고 싶은 핵심입니다.

타입(Type), LSP(Language Server Protocol), 컴파일러, 테스트, 그리고 리포지토리의 일관성을 갖춰 놓으면, 동일한 LLM이라도 생성의 안정도가 완전히 달라집니다.

여기에 적은 것은 어디까지나 저의 현시점 구성 방식이며, 사업의 단계나 팀의 숙련도에 따라 최적해는 달라질 수 있습니다.

• Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1 (GitHub Blog)
• 2025 Stack Overflow Developer Survey
• Knowledge Transfer from High-Resource to Low-Resource Programming Languages for Code LLMs (arXiv)
• Type-Constrained Code Generation with Language Models (94%의 타입 에러 출처, arXiv)
• Language Server Protocol 공식 페이지
• typescript-language-server (GitHub)
• Gopls: The language server for Go (Go 공식)
• gopls MCP support (Go 공식)
• Pyright (Microsoft)
• 개인 개발 기술 스택 완전 가이드 (ShiftB)
• AI 주도 개발을 위한 기술 선정: 궁합이 좋은 기술 스택 판별법 (Zenn)