이 기사의 위치

이 기사는 지금까지 진행해 온 AIO 실천 시리즈의 연장선에 있습니다.

다만, 이 기사에서 다루는 대상은 llms.txt, llms-full.txt, JSON-LD, XMP, ID3, robots.txt, AI bot governance 그 자체가 아닙니다.

지금까지의 기사에서는 주로 다음과 같은 질문들을 다루어 왔습니다.

• AI에게 웹사이트를 어떻게 읽히게 할 것인가
• AI가 오독하지 않도록 어떤 문맥을 정전(Canon)으로서 전달할 것인가
• llms.txt와 llms-full.txt를 어떻게 구분해서 사용할 것인가
• Robots Exclusion Protocol과 AIO 문맥 공급을 어떻게 나눌 것인가
• Google Search Central의 구조화 데이터나 Schema.org와 AI용 문맥 설계를 어떻게 연결할 것인가
• 이미지나 음성 등 HTML 외부에 있는 에셋에도 XMP나 ID3v2.3로 의미를 남길 수 있는가
• AI bot을 하나로 묶지 않고, OpenAI crawler docs, Google crawlers and fetchers, Applebot, Common Crawl FAQ 등의 1차 정보로부터 용도별로 분류할 수 있는가

본고에서는 그 다음 단계로 나아갑니다.

AI 코딩 이야기가 나오면 논의는 즉시 도구 비교로 기울어집니다.

• Cursor가 강한가
• Windsurf가 강한가
• Claude Code가 강한가
• Devin은 실무에서 쓸 수 있는가
• GitHub Copilot만으로 충분한가
• OpenAI Codex는 클라우드형과 CLI형이 무엇이 다른가
• Cline이나 Roo Code와 같은 OSS 에이전트를 사용해야 하는가
• Continue와 같은 오픈하고 확장 가능한 AI 개발 환경을 조직에 도입해야 하는가
• Zed와 같은 고속 네이티브 에디터는 AI 시대에 우위에 있는가
• Replit Agent나 StackBlitz WebContainers와 같은 브라우저 내·클라우드 내 실행 환경은 어디까지 실용적인가

물론 이러한 비교에는 의미가 있습니다.

하지만 도구 이름만 봐서는 AI 코딩의 본질에 도달할 수 없습니다.

왜냐하면 AI 코딩을 성립시키는 것은 채팅창, 보완(Completion) UI, 에이전트의 이름이 아니라, 그 이면에 있는 다음과 같은 기반(Infrastructure)이기 때문입니다.

• 에디터의 렌더링 기반 (Rendering Infrastructure)
• 로컬 또는 클라우드의 실행 환경 (Runtime Environment)
• 샌드박스 (Sandbox)
• 터미널 실행 제어 (Terminal Execution Control)
• 파일 편집 권한 (File Editing Permissions)
• 장문맥 처리 (Long Context Processing)
• RAG (Retrieval-Augmented Generation)
• AST (Abstract Syntax Tree)
• code graph
• GraphRAG
• 타입 검사 (Type Checking)
• 테스트 실행 (Test Execution)
• 컴파일러 (Compiler)
• 린터 (Linter)
• diff
• PR (Pull Request)
• checkpoint
• branch
• 권한 규칙 (Permission Rules)
• 인간의 승인 경계 (Human Approval Boundary)
• AI 간의 정전 계승 (Canonical Inheritance between AIs)

즉, AI 코딩의 본질은 단순한 'AI 에디터 사용 비교'가 아닙니다.

본고에서는 이 총체를 AI Coding Infrastructure라고 부릅니다.

먼저 결론부터

본고의 결론은 다음 5가지입니다.

1. AI 코딩은 IDE 기능이 아니라, 실행 통치 기반이다.
2. AI가 코드를 쓰기 전에, AI가 무엇을 읽을 수 있는지, 무엇을 실행할 수 있는지, 어디서 멈출지를 설계해야 한다.
3. RAG만으로는 코드베이스 이해가 불충분하며, AST·타입·의존 관계·테스트 결과 등의 결정론적 근거가 필요하다.
4. 자율형 에이전트의 가치는 '멋대로 움직이는 것'이 아니라, 실행·검증·되돌리기·승인을 인간이 제어할 수 있는 데 있다.
5. AI 코딩의 성숙도는 사용 중인 AI 도구의 이름이 아니라, 실행 기반·문맥 기반·검증 기반·권한 기반·통치 기반의 정비 수준으로 결정된다.

본고에서 다루는 범위

본고는 AI 코딩 도구의 랭킹 기사가 아닙니다.

다루는 것은 AI 코딩을 성립시키는 '이면의 기반'입니다.

참고한 주요 1차 정보·공식 정보

본고에서는 가능한 한 공식 정보와 1차 정보를 우선합니다.

Zenn Markdown Guide

Zenn CLI Guide

OpenAI Codex Cloud

OpenAI Codex CLI GitHub Repository

OpenAI Code generation guide

OpenAI Agents SDK

Devin Docs

Cognition: Introducing Devin

Claude Code Overview

Claude Code Permissions

Claude Code Security

Cline Official Site

Cline GitHub Repository

Cline Tools Reference

Cline MCP Overview

Windsurf Cascade

Windsurf Rules

Cursor Docs

Cursor Rules

GitHub Copilot documentation

GitHub Copilot coding agent

GitHub Copilot code review

WebContainers

StackBlitz

Replit Agent

Nix

Tvix

Tree-sitter

ast-grep

Sourcegraph Cody

CodeRabbit

SWE-bench

AIDev: Studying AI Coding Agents on GitHub

Fingerprinting AI Coding Agents on GitHub

Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance

Measuring the Permission Gate: A Stress-Test Evaluation of Claude Code's Auto Mode

1. AI 코딩을 「IDE 기능」이 아닌 「기반」으로 파악하기

AI 코딩을 이해할 때, 많은 사람은 가장 먼저 UI를 봅니다.

• 채팅창이 있다
• 보완(Completion)이 빠르다
• 파일을 읽을 수 있다
• 코드를 다시 작성한다
• 터미널을 실행한다
• PR(Pull Request)을 만든다
• 에러를 수정한다
• 테스트를 실행한다

하지만 이것들은 표층에 불과합니다.

예를 들어, OpenAI Codex Cloud는 코드를 읽고, 편집하고, 실행할 수 있는 코딩 에이전트(coding agent)로 설명됩니다.

Devin은 「write, run and test code」할 수 있는 자율형 AI 소프트웨어 엔지니어로 설명됩니다.

Claude Code는 터미널 위에서 코드베이스를 이해하고, 편집하며, 명령어를 실행하는 에이전트형 코딩 도구(agentic coding tool)입니다.

Cline

는 VS Code 위에서 파일 편집, 터미널 실행, 브라우저 조작, MCP 연결을 다루는 OSS 에이전트입니다.

GitHub Copilot coding agent

는 issue나 PR을 기점으로 브랜치 상에서 변경 사항을 생성합니다.

이것들은 모두 서로 다른 경험처럼 보입니다.

하지만 뒷단에서 일어나고 있는 처리를 추상화하면 구조는 비슷합니다.

이 흐름 중 어느 하나라도 깨지면, AI 코딩은 무너집니다.

특히 중요한 것은 AI가 생성하는 코드 그 자체보다, 그 전후 단계입니다.

즉, AI 코딩은 "AI가 코드를 쓰느냐 마느냐"의 문제가 아니라, AI가 코드를 쓰기 전후의 기반이 설계되어 있는가의 문제입니다.

2. AI Coding Infrastructure란 무엇인가

본고에서는 AI 코딩을 성립시키는 기반 전체를 AI Coding Infrastructure라고 부릅니다.

이것은 단순한 개발 환경이 아닙니다.

AI Coding Infrastructure는 최소 5개의 계층으로 구성됩니다.

이 5개 계층을 보지 않은 채 AI 도구를 비교해봐야 본질적인 판단을 내릴 수 없습니다.

똑같이 "AI가 코드를 쓸 수 있다"라고 해도, 아래는 완전히 다릅니다.

중요한 것은 어떤 것이 더 뛰어난가가 아닙니다.

중요한 것은, 어느 계층의 책임을 AI에게 넘기고, 어느 계층을 인간이 유지할 것인가입니다.

3. 표층 비교가 실패하는 이유

AI 코딩 비교는 흔히 다음과 같이 이루어집니다.

이러한 비교는 AI를 "똑똑한 보완 기능"으로 본다면 유효합니다.

하지만 AI가 파일을 다시 쓰고, 터미널을 실행하며, PR을 만들고, issue를 처리하는 단계에서는 불충분합니다.

왜냐하면 에이전트형 AI에서는 다음과 같은 질문이 필요하기 때문입니다.

• 그 AI는 어떤 파일을 읽었는가
• 어떤 규칙(rule)을 적용했는가
• 어떤 명령어를 실행했는가
• 실행 결과를 어떻게 해석했는가
• 실패했을 때 어디까지 되돌릴 수 있는가
• 변경 범위가 인간이 리뷰 가능한 수준인가
• 그 PR에 대한 최종 책임은 누가 지는가
• AI가 실행해도 되는 권한 범위는 어디까지인가
• 생성물이 어떤 정전(canon)을 따르고 있는가
• 다음 AI에게 상태를 어떻게 인계할 것인가

다만, 본고는 제1편이므로 책임 경계 분류 그 자체는 다음 기사에서 심도 있게 다루겠습니다.

본고에서는 그 전제가 되는 "기반"을 다룹니다.

4. 에디터 기반: AI 출력을 받아내는 UI는 가벼운가

AI 코딩에서 의외로 중요한 것이 에디터 기반입니다.

AI 모델이 빠르게 코드를 생성하더라도, 에디터 측이 무거우면 개발자의 인지 흐름(cognitive flow)이 끊깁니다.

예를 들어, VS Code는 거대한 확장 기능 생태계를 가지고 있으며, GitHub Copilot, Cline, Continue와 같은 AI 확장의 기반이 됩니다.

반면, Cursor나 Windsurf

는 VS Code 계열의 경험을 계승하면서, AI를 전제로 IDE를 재설계하고 있습니다.

또한, Zed

는 Rust로 작성된 고속 에디터이며, AI 시대의 에디터 기반을 생각할 때 중요한 대조축이 됩니다.

Tree-sitter

와 같은 구문 분석 (Parsing) 기반도 에디터와 AI의 문맥 이해 (Context Understanding)를 잇는 가교 역할을 합니다.

에디터 기반의 차이는 단순한 취향의 문제가 아닙니다.

AI 에이전트가 대량의 차이점 (Diff)을 생성하면 다음과 같은 현상이 발생합니다.

• diff 표시가 무거워짐
• 파일 트리 탐색이 증가함
• 여러 파일 편집의 시인성이 떨어짐
• AI 제안과 인간의 수정이 혼재됨
• 체크포인트 (Checkpoint) 비교가 필요해짐
• 터미널 출력이 증가함
• 에러 수정 루프가 길어짐
• PR 설명과 실제 diff 간의 정합성 확인이 필요해짐

이때, 에디터가 단순한 텍스트 편집기라면 한계가 있습니다.

AI 코딩 시대의 에디터는 다음과 같은 역할을 맡기 시작합니다.

이러한 변화로 인해 에디터의 본질은 '쓰는 곳'에서 '통치하는 곳'으로 이동합니다.

5. 실행 기반: AI는 어디에서 코드를 실행하는가

AI 코딩에서 가장 위험한 것은 AI가 코드를 작성하는 것이 아닙니다.

AI가 어디에서 무엇을 실행하는가입니다.

같은 '테스트 실행'이라도 실행 장소에 따라 리스크가 달라집니다.

AI에게 실행 권한을 부여할 때, 살펴봐야 할 것은 '편리한가'가 아닙니다.

살펴봐야 할 것은 다음과 같습니다.

• 파일을 삭제할 수 있는가
• 환경 변수를 읽을 수 있는가
• 네트워크 액세스가 가능한가
• 외부 API를 호출할 수 있는가
• 데이터베이스에 접속할 수 있는가
• 운영 환경 인증 정보에 접근할 수 있는가
• 마이그레이션 (Migration)을 실행할 수 있는가
• 배포 (Deploy)할 수 있는가
• 시크릿 (Secret)을 로그에 남길 수 있는가
• 실패 시 되돌릴 수 있는가

따라서 AI 코딩을 도입할 때는 가장 먼저 실행 환경을 분류해야 합니다.

이 분류를 하지 않은 채 'AI에게 맡긴다'고 하면, AI의 능력 이전에 운영 체계가 무너집니다.

6. 샌드박스: AI를 가두는 사고방식

AI 에이전트에게 실행 권한을 부여하는 경우, 샌드박스 (Sandbox)는 필수입니다.

단, 여기서 말하는 샌드박스는 단순한 '안전해 보이는 환경'이 아닙니다.

본고에서는 샌드박스를 다음과 같이 정의합니다.

OpenAI Codex Cloud나 Devin과 같은 클라우드형 에이전트 환경은 이 관점에서 중요합니다.

반면, Claude Code, OpenAI Codex CLI, Cline과 같은 로컬 · IDE · CLI형에서는 사용자가 실행 경계 (Execution Boundary)를 설계하는 비중이 높아집니다.

dev containers, Docker, Nix, Tvix 등은 AI 코딩 시대의 실행 재현성을 뒷받침하는 중요한 기반입니다.

브랜치(Branch)는 Git 관리 하의 파일 차분(diff)을 되돌릴 수는 있지만, 다음 사항들은 지킬 수 없습니다.

.env

의 읽기 - 로컬 DB 삭제

• 외부 API 실행
• 캐시 파괴
• 글로벌 설정 변경
• 인증 토큰 유출
• Docker volume 삭제
• npm postinstall 등의 부작용
• migration 실행
• deploy command 실행

즉, Git branch는 "코드 차분의 되돌리기"이지, "실행 부작용의 격리"가 아닙니다.

AI에게 실행을 맡기려면 최소한 다음 사항들을 설계해야 합니다.

• 작업 디렉토리 (Working directory)
• 쓰기 가능 범위
• 실행 가능 명령어
• 네트워크 연결 가능 여부
• secret 참조 가능 여부
• package install 가능 여부
• database 연결 가능 여부
• 파괴적 명령어 (destructive command) 가능 여부
• 타임아웃 (timeout)
• 로그 (log) 저장
• 롤백 (rollback) 단위

이러한 설계 없이 AI 에이전트(Agent)를 도입하는 것은, 권한 관리가 되지 않은 외부 위탁자에게 운영 환경 터미널을 넘겨주는 것과 비슷합니다.

7. 문맥 기반 (Context Foundation): AI는 무엇을 읽고 코드를 쓰는가

AI가 코드를 쓸 때, 가장 먼저 문제가 되는 것은 모델 성능이 아닙니다.

무엇을 읽고 있는가입니다.

AI는 읽지 않은 것에 대해서는 따를 수 없습니다.

읽었다 하더라도 우선순위가 모호하다면 일반적인 해답(General solution)으로 돌아갑니다.

문맥(Context)에는 여러 종류가 있습니다.

AI 코딩의 실패는 문맥의 부족만으로 발생하는 것이 아닙니다.

문맥이 너무 많아도 실패합니다.

이것들은 단순한 "문서"가 아닙니다.

AI 시대에 이것들은 Context Governance(문맥 거버넌스)의 구현물입니다.

8. RAG만으로는 코드베이스 이해에 부족하다

AI 코딩의 문맥 기반(Context Foundation)으로서 RAG는 중요합니다.

RAG는 필요한 정보를 검색하여 그 정보를 컨텍스트(Context)로서 모델에 전달하는 메커니즘입니다.

하지만 코드베이스에서의 RAG에는 한계가 있습니다.

왜냐하면 코드는 단순한 텍스트가 아니기 때문입니다.

코드에는 다음과 같은 구조가 있습니다.

• import / export
• 타입 (Type)
• 함수 호출 (Function Call)
• 상속 (Inheritance)
• 인터페이스 (Interface)
• 의존성 그래프 (Dependency Graph)
• 부작용 (Side Effect)
• 빌드 설정 (Build Config)
• 테스트 의존성 (Test Dependency)
• 런타임 동작 (Runtime Behavior)
• 환경 변수 (Environment Variable)
• 프레임워크 컨벤션 (Framework Convention)
• 라우트 (Route)
• 스키마 (Schema)
• 마이그레이션 (Migration)
• 권한 (Permission)
• 라이프사이클 훅 (Lifecycle Hook)

일반적인 텍스트 RAG는 이것들을 충분히 다룰 수 없습니다.

예를 들어, Tree-sitter는 다국어 구문 분석(Parsing) 기반으로서 에디터·검색·분석과 궁합이 좋으며, ast-grep은 AST 기반의 코드 검색 및 재작성(Rewrite)을 다룰 수 있습니다.

또한, 코드베이스를 위한 GraphRAG의 연구 및 구현 사례로는 Reliable Graph-RAG for Codebases, ast-asg-graph-rag, Memgraph의 GraphRAG for Devs와 같은 방향성이 있습니다.

텍스트 RAG만으로 코드를 작성하게 하면 다음과 같은 문제가 발생합니다.

• 동일한 이름의 함수를 혼동함
• 사용해서는 안 되는 오래된 API를 사용함
• import 경로를 틀림
• 타입 제약(Type Constraint)을 무시함
• 테스트 대상을 놓침
• 런타임(Runtime) 전제를 오해함
• 부작용(Side Effect)을 간과함
• 의존 방향을 역전시킴
• 이미 구현된 공통 함수를 재발명함
• 설계상 금지된 패턴을 부활시킴

즉, 코드베이스 이해에는 텍스트 검색뿐만 아니라 결정론적인 구조 이해가 필요합니다.

9. AST·타입·의존 관계에 의한 결정론적 그라운딩 (Deterministic Grounding)

여기서 중요해지는 것이 **결정론적 그라운딩 (Deterministic Grounding)**입니다.

AI는 확률적으로 문장이나 코드를 생성합니다.

하지만 코드는 실행됩니다.

따라서 AI 코딩에서는 다음과 같은 연결이 필요합니다.

이 연결이 없으면 AI는 '그럴듯한 코드'를 작성합니다.

이 연결이 있으면 AI는 '검증 가능한 후보'를 내놓을 수 있습니다.

두 가지는 별개의 것입니다.

Deterministic Grounding은 AI를 부정하는 것이 아닙니다.

오히려 반대입니다.

AI의 생성 능력을 실무에 사용하기 위해, AI의 출력을 검증 가능한 구조로 연결하는 것입니다.

10. 실행 피드백: AI는 에러로부터 학습하는가

AI 코딩의 강점은 단순히 코드를 쓰는 것이 아닙니다.

실행하고, 실패하고, 고칠 수 있다는 점입니다.

여기서 중요해지는 것이 **실행 피드백 (Execution Feedback)**입니다.

Execution Feedback이란 AI가 생성한 코드를 실행하고, 그 결과를 다음 수정에 사용하는 루프를 말합니다.

이 루프에는 강력한 가치가 있습니다.

단, Execution Feedback에도 함정이 있습니다.

AI가 에러를 보고 수정할 경우, 다음과 같은 나쁜 행동을 할 수 있습니다.

• 테스트를 통과시키기 위해 테스트 코드를 재작성함
• 타입 에러를 any로 뭉개버림
• lint를 무효화함
• 예외(Exception)를 삼켜버림 (Swallow)
• 사양(Specification)을 약화시킴
• 실패하는 단언문 (Failing Assertion)을 삭제함
• 에러 로그의 근본 원인을 보지 않고 대증요법만 시행함
• 타임아웃 시간만 늘림
• 마이그레이션을 억지로 통과시킴
• 실행 환경을 더럽혀서 통과한 것처럼 보이게 함

따라서 AI에게 수정을 맡길 때라도 다음과 같은 규칙이 필요합니다.

여기서 필요한 것은 AI의 똑똑함이 아니라, 검증 기반을 AI로부터 보호하는 설계입니다.

11. 권한 기반: AI에게 무엇을 허용하고 무엇을 금지할 것인가

AI 에이전트가 파일을 읽고 쓸 수 있으며, 명령어를 실행할 수 있게 되면 권한 설계 (Permission Design)가 필요해집니다.

예를 들어, Claude Code Permissions에서는 Allow, Ask, Deny의 권한 규칙을 정의할 수 있습니다.

해당 문서에서는 규칙 평가 순서가 deny -> ask -> allow이며, 가장 먼저 일치하는 규칙이 우선되기 때문에 Deny가 항상 우선된다고 설명하고 있습니다.

Cline Tools Reference에서는 파일 조작, 터미널 조작, 브라우저 조작 등 에이전트가 다루는 도구군 (Tools)이 정리되어 있습니다.

Cline MCP Overview나 Model Context Protocol은 AI가 외부 도구 또는 데이터 소스에 연결하는 기반으로서 중요합니다.

AI 코딩에서의 권한은 최소한 다음과 같이 나뉩니다.

권한 설계에서는 다음의 3가지 분류가 기본이 됩니다.

하지만 이것만으로는 부족합니다.

AI의 조작은 단일 액션이 아니라, 여러 액션의 조합으로 인해 위험해지기 때문입니다.