AI 코딩의 서막

AI 코딩, 바이브 코딩하면 어떤 생각이 드는가.

먼저 AI, 생산성, 자동화 이야기가 화두가 되면 어떤 이들은 기존의 삶에 위협을, 어떤 이들은 이를 기회로 본다.

둘 다 맞는 말이라고 생각한다.

좀 더 주관적인 견해로, 짧은 생각을 말해보자면

"AI 툴과 그들의 도입은 마치 아날로그 업무 방식에서 디지털로의 전환이 오던 그 과도기와 닮을 수도 있겠다" 이다.

가령 엑셀이나 워드가 존재하지 않던 때(그 때 없었지만..)에는 문서 작성이나 도표, 테이블 계산은 오로지 사람의 몫이었다.

직접 그리거나 타자기, 간단 프린트의 영역이었고 실수나 손이 많이 타는 업무의 모습이었다.

그러나, 엑셀 function의 도입과 PC를 비롯한 컴퓨터의 대대적인 보급으로 이를 사용하고 안하고의 격차는 어떤 면에서든 커지게 되었고, 시간이 감에 따라 이는 일반적인 업무의 모습이 되었다.

여기서 AI의 도입과 현재 모습을 보이는 과도기 또한 그렇지 않을까하는 생각을 했다.

몇 년 전까지만 해도 '자동완성'이라 하면 변수명이나 몇 글자 채워주는 수준이었다.

지금은 옆에 채팅창 하나 띄워놓고 키보드로 토니 스타크 마냥 모니터 속 2차원 자비스에게 "이 컴포넌트 리팩토링 해줘"라고 치면, 파일을 열고 수정하고 테스트까지 돌려서 결과를 보여주는 게 일상이 됐다.

문제는 이 도구들을 제대로 이해하지 못한 채 쓰면, 편해지기는커녕 더 헷갈리고 비효율적이게 된다는 점이다.

토큰이 뭔지 모르고 쓰다가 요금 폭탄을 맞기도 하고, MCP가 뭔지 모른 채 "그거 연결해두면 편하대요"라는 말만 듣고 대충 설정했다가 보안 사고로 이어지는 글들이나 소식도 종종 들려오곤 한다.

그래서 이번 포스팅에서는 웹 개발자 입장에서 지금 이 시점에 알아야 할 AI 코딩의 포괄적인 개념을 한 번 정리해보려 한다.

LLM(Large Language Model)이란?

대량의 텍스트 데이터를 학습해서, 입력받은 질문이나 지시문(이를 프롬프트라 부른다)에 대해 다음에 올 단어를 확률적으로 예측하며 답을 생성하는 인공지능 모델이다. ChatGPT의 GPT, Claude, Gemini 같은 이름이 전부 이 LLM을 기반으로 만들어진 서비스다.

이 글에서 다루는 코딩 도구들은 전부 이 LLM에 "코드를 이해하고 다룰 수 있는 능력"을 얹어서 에디터나 터미널과 연결한 것이라고 보면 된다.

AI 도구, 종류부터 구분하자

"AI 코딩 도구"라는 말로 뭉뚱그려 부르지만, 실제로는 동작 방식이 꽤 다른 몇 갈래로 나뉜다.

이를 구분 하지 못하면 제대로된 도구를 잘못 고를 수 있다..

자동완성형 (Completion 기반)

커서 위치에서 다음에 올 코드를 예측해서 제안하는 방식이다.

GitHub Copilot이 초기부터 이 포지션이었다.

타이핑하는 흐름을 끊지 않고 인라인으로 코드를 채워주는 게 강점이라, 반복적인 보일러플레이트나 패턴이 명확한 코드를 짤 때 특히 체감이 크다.

채팅/어시스턴트형

에디터 옆에 채팅창을 두고 질문하거나 코드 설명, 리뷰, 특정 함수 작성을 요청하는 방식이다.

이와 같은 대화형이라 맥락을 주고받으며 다듬어갈 수 있다는 게 장점이다.

에이전트형 (Agentic)

여기가 최근 흐름의 핵심이다.

단순히 코드 한 줄을 제안하는 게 아니라, 목표를 던지면 스스로 파일을 탐색하고, 여러 파일을 수정하고, 터미널 명령을 실행하고, 결과를 검증하는 과정까지 자율적으로 수행한다.

Claude Code, Cursor의 Agent 모드, Windsurf 같은 도구들이 이 카테고리다.

모두 초창기 출시 당시에 써봤던 것들이고, 특히나 Cursor나 Windsurf 툴은 그 당시에 맥락 파악이나 기능의 한계 등 실망스러운 점이 많았기에 stackoverflow+chatgpt 조합을 고수하며 잊고 지냈다.

그러나 발전 속도와 툴의 기능 수준의 발달은 무섭게 성장했고, "함수 하나 짜줘" 수준이 아니라 "버그 원인 찾아서 분석&해결&보고", 기능 구현 같은 작업 단위 요청이 가능해지기 까지 했다.

마치 모든 소프트웨어 개발자가 바라던 자동형 이상향이 시작된 듯 했다.

에이전트(Agent)란?

스스로 계획을 세우고, 도구(파일 읽기/쓰기, 명령 실행, 웹 검색 등)를 호출하고, 결과를 관찰해서 다음 행동을 결정하는 반복 루프를 도는 LLM을 말한다.

사람이 매 단계 지시하지 않아도, "생각 → 도구 호출 → 결과 확인 → 다음 행동"을 스스로 반복한다는 점이 일반 채팅형 어시스턴트와의 결정적 차이다.

지금 실무에서 쓰이는 대표 도구들

몇 가지만 짚고 넘어가자.

어떤 게 더 좋다기보다, 성격이 다르다는 것부터 이해하는 게 먼저라고 생각한다...

• GitHub Copilot — IDE 통합형 자동완성의 표준. 최근에는 Copilot Workspace처럼 에이전트 기능도 붙었다.
• Cursor — VS Code 포크 기반 에디터. 코드베이스 전체를 인덱싱해두고 채팅/에이전트 모드를 자연스럽게 오갈 수 있게 만든 게 특징이다.
• Claude Code — 터미널 기반 에이전트형 CLI 도구. 에디터에 종속되지 않고, 저장소 전체 맥락에서 여러 파일을 넘나들며 작업을 수행한다.
• Windsurf — Cursor와 비슷한 포지션의 에이전틱 에디터.

GitHub Copilot · Your AI pair programmer

GitHub Copilot works alongside you directly in your editor, suggesting whole lines or entire functions for you.

GitHub

Cursor: AI coding agent

Built to make you extraordinarily productive, Cursor is the best AI coding agent.

Cursor

Claude Code by Anthropic | AI Coding Agent, Terminal, IDE

Anthropic's agentic coding tool for developers. Claude Code understands your codebase, edits files, runs commands, and helps you ship faster.

Claude

체감상 흐름은 명확하다.

"에디터 안에서 자동완성 받기"에서 "에이전트에게 작업 단위를 위임하기"로 무게중심이 옮겨가고 있다.

코드를 한 줄씩 밀어내는 게 아니라, PR 단위 작업을 맡기고 사람은 리뷰어 역할에 가까워지는 흐름이다.

에이전트형 3파전: Claude Code, Codex, Antigravity

에이전트형 도구 중에서도 지금 가장 많이 비교되는 세 가지를 짚어보자.

셋 다 "목표를 던지면 알아서 작업한다"는 큰 그림은 같지만, 실행 환경과 개입 방식이 꽤 다르다.

Claude Code

Anthropic이 만든 터미널 기반 에이전트 CLI다.

에디터에 종속되지 않고 로컬 저장소를 그대로 컨텍스트로 삼아, 파일 탐색·수정·명령 실행을 반복하며 작업을 진행한다.

특징은 권한 모델이다.

파일 수정이나 명령 실행처럼 되돌리기 까다로운 동작은 기본적으로 사용자 승인을 거치도록 되어 있어서, 자율성과 통제 사이의 균형을 도구 차원에서 잡아준다.

CLI 기반이라 특정 에디터에 묶이지 않고, CI 파이프라인이나 훅 같은 자동화 워크플로우에 끼워 넣기도 수월하다.

Codex

OpenAI의 코딩 에이전트로, 클라우드 샌드박스 환경에서 작업을 수행하는 방식이 특징이다.

작업을 맡기면 격리된 컨테이너에서 코드를 실행하고 테스트를 돌린 뒤, 그 결과를 PR 형태로 정리해서 보여준다.

로컬 환경을 직접 건드리지 않고 클라우드에서 여러 작업을 병렬로 돌릴 수 있다는 점이 강점이라, "여러 이슈를 한 번에 던져놓고 결과만 리뷰"하는 흐름에 잘 맞는다.

Antigravity

구글이 내놓은 에이전틱 개발 플랫폼으로, Gemini 모델을 기반으로 에디터·터미널·브라우저를 하나의 에이전트가 오가며 작업하도록 설계된 게 특징이다.

단일 채팅창이 아니라 "에이전트 매니저"가 여러 에이전트의 작업을 동시에 관리하고, 각 작업의 실행 과정(어떤 파일을 봤고, 어떤 명령을 실행했는지)을 아티팩트(작업 결과물이자 실행 로그)로 남겨 검증할 수 있게 한 점이 다른 도구와의 차이다.

Claude Code by Anthropic | AI Coding Agent, Terminal, IDE

Anthropic's agentic coding tool for developers. Claude Code understands your codebase, edits files, runs commands, and helps you ship faster.

Claude

https://openai.com/codex/

openai.com

Google Antigravity

Experience liftoff with the next-gen agent platform

Google Antigravity

셋 중 뭐가 "더 낫다"보다는, 작업 성격에 따라 골라 쓰는 게 맞다.

로컬 저장소를 깊게 파고드는 작업엔 Claude Code, 여러 이슈를 병렬로 던져놓고 결과만 확인하고 싶다면 Codex, 여러 에이전트를 한 화면에서 관리하며 실행 과정 자체를 검증하고 싶다면 Antigravity가 강점을 보이는 구조다.

어떤 모델을 골라야 할까

도구 얘기만 했지만, 사실 그 안에서 돌아가는 모델도 골라야 한다.

같은 도구 안에서도 여러 모델 중 하나를 선택하게 되어 있는 경우가 대부분이라, 이 판단 기준도 알아둘 필요가 있다.

크게 두 갈래로 나뉜다.

reasoning(추론)형 모델은 답을 내놓기 전에 내부적으로 더 오래, 더 깊게 생각하는 방식으로 동작한다. 복잡한 아키텍처 설계, 까다로운 버그 원인 추적처럼 "정답률"이 중요한 작업에 적합하지만, 그만큼 느리고 비용도 더 든다.

경량/고속 모델은 반대로 응답이 빠르고 저렴하다. 자동완성, 간단한 질의응답, 반복적인 패턴 작업처럼 속도가 더 중요한 상황에 맞는다.

Models overview

Claude is a family of state-of-the-art large language models developed by Anthropic. This guide introduces the available models and compares their performance.

Claude Platform Docs

결국 "제일 좋은 모델 하나로 다 해결"보다, 작업 성격에 맞춰 무게가 다른 모델을 오가며 쓰는 게 비용과 속도 양쪽에서 유리하다.

토큰, 알아야 손해를 안 본다

AI 도구를 쓰다 보면 결국 "토큰"이라는 단위와 마주친다.

이걸 모르고 쓰면 왜 답변이 갑자기 잘리는지, 왜 요금이 예상보다 많이 나오는지 이해할 수 없다.

토큰(Token)이란?

LLM이 텍스트를 처리하는 최소 단위다. 한 단어가 그대로 토큰 하나가 되기도 하고, 긴 단어는 여러 조각으로 쪼개지기도 한다. 영어 기준으로 대략 4글자당 1토큰, 한글은 이보다 더 잘게 쪼개지는 경향이 있다.

모델은 입력(prompt)과 출력(completion) 모두를 토큰 단위로 세고, 이 총량으로 비용과 처리 가능한 맥락 길이가 결정된다.

컨텍스트 윈도우

모델이 한 번에 "기억"할 수 있는 토큰의 최대치를 컨텍스트 윈도우라 부른다.

대화가 길어지거나 큰 파일을 여러 개 물려서 던지면 이 한도에 금방 닿는다.

에이전트형 도구를 쓸 때 특히 중요한데, 저장소 전체를 훑고 여러 파일을 오가는 작업 특성상 컨텍스트가 눈덩이처럼 불어나기 쉽다.

효율적으로, 경제적으로 쓰는 법

• 불필요한 파일을 통째로 던지지 않는다. 필요한 부분만 발췌해서 전달하면 토큰도 아끼고, 모델이 관련 없는 내용에 흔들릴 가능성도 줄어든다.
• 대화(세션)를 목적 단위로 끊는다. 하나의 세션에 서로 다른 작업을 계속 이어붙이면 컨텍스트가 불필요하게 쌓인다. 작업이 바뀌면 새 세션으로 시작하는 게 오히려 정확도와 비용 양쪽에 이득이다.
• 캐싱을 활용한다. 반복적으로 재사용되는 시스템 프롬프트나 문서는 프롬프트 캐싱을 지원하는 도구/API를 쓰면 같은 내용을 매번 다시 계산하지 않아 비용이 크게 줄어든다.
• 요청을 구체적으로, 작게 쪼갠다. "전체 리팩토링 해줘"보다 "이 파일의 이 함수만 정리해줘"가 결과 품질도 좋고 토큰 낭비도 적다.

프롬프트, 아무렇게나 치면 안 된다

토큰을 아끼는 게 "얼마나 넘길지"의 문제라면, 프롬프트 엔지니어링은 "무엇을, 어떻게 넘길지"의 문제다.

같은 요청이라도 어떻게 표현하느냐에 따라 결과 품질이 크게 갈린다.

몇 가지 자주 쓰이는 패턴이 있다.

• 역할을 부여한다. "너는 시니어 프론트엔드 개발자다"처럼 역할을 먼저 지정하면, 그 역할에 맞는 관점으로 답을 좁혀준다.
• 원하는 출력 형식을 명시한다. "요약해줘"보다 "3줄 이내로, 불릿 포인트로 요약해줘"가 훨씬 예측 가능한 결과를 낸다.
• 예시를 함께 준다(few-shot). 원하는 결과물의 예시 한두 개를 같이 넘기면, 설명을 길게 늘어놓는 것보다 정확하게 의도가 전달된다.
• 하지 말아야 할 것도 명시한다. "이 라이브러리는 쓰지 마" 같은 제약을 명확히 적어두면 엉뚱한 방향으로 새는 걸 줄일 수 있다.

최근에는 이걸 한 단계 넓혀서 컨텍스트 엔지니어링이라는 말도 쓰인다.

프롬프트 문장 하나를 다듬는 것을 넘어, 어떤 파일을 보여줄지, 어떤 문서를 참조시킬지, 이전 대화 중 무엇을 남기고 무엇을 버릴지까지 설계하는 개념이다.

에이전트형 도구를 쓸수록 이 컨텍스트 설계 능력이 실질적인 결과물 품질을 좌우한다.

Prompt engineering overview

Learn when prompt engineering is the right solution, and find Claude prompting techniques and interactive tutorials.

Claude Platform Docs

2026년, 현업에서는 이렇게 쓰인다

지금 시점 흐름을 정리하면 이렇다.

• 반복 작업의 자동화 — 테스트 코드 작성, 타입 정의, 마이그레이션 스크립트처럼 패턴이 명확한 작업은 에이전트에게 맡기고 결과만 검토하는 방식이 정착되고 있다.
• 명세 기반 개발(Spec-Driven) — 사람이 코드를 직접 짜기보다, 요구사항과 제약을 명확히 문서화해서 AI에게 넘기고, 그 명세를 기준으로 결과를 검증하는 방식이 늘고 있다. 결국 "어떻게 짤까"보다 "무엇을, 어떤 기준으로"를 정의하는 능력이 더 중요해진 셈이다.
• 코드 리뷰의 역할 변화 — 1차 리뷰(스타일, 명백한 버그, 컨벤션 위반)를 AI가 먼저 훑고, 사람은 아키텍처나 비즈니스 로직 같은 더 상위 판단에 집중하는 구조로 바뀌고 있다.
• AI 활용하는 개발자의 역할 변화 — 단순 구현보다, AI가 만든 결과물을 읽고 검증하고 근거를 이해하는 능력이 더 먼저 요구되는 분위기다. 코드를 "짜는" 사람에서 "판단하는" 사람으로 무게중심이 옮겨가는 중이다.

바이브 코딩(Vibe Coding), 그리고 그 논쟁

이 흐름과 함께 자주 회자되는 말이 바이브 코딩이다.

코드를 한 줄씩 이해하며 짜기보다, AI가 뽑아주는 결과물을 감(vibe)으로 계속 굴려가며 원하는 결과물에 도달하는 방식을 가리킨다.

빠르게 프로토타입을 만들거나 사이드 프로젝트를 굴릴 때는 확실히 생산성이 높다.

문제는 실무 코드베이스에서다. 왜 이렇게 동작하는지 이해하지 못한 채 쌓인 코드는, 나중에 버그가 생겼을 때 아무도 원인을 찾지 못하는 상황으로 이어지기 쉽다.

그래서 "속도가 중요한 실험 단계"와 "책임지고 유지보수해야 하는 프로덕션 코드"를 구분해서, 바이브 코딩을 어디까지 허용할지 팀 차원에서 선을 긋는 게 최근 분위기다.

AI 코드 리뷰 봇

사람이 첫 리뷰를 하기 전에, AI가 PR에 자동으로 코멘트를 다는 도구들도 자리잡았다.

CodeRabbit, Greptile 같은 도구가 대표적이며, 스타일 위반이나 명백한 버그, 잠재적 보안 이슈를 사람보다 먼저 훑어준다.

AI Code Reviews | CodeRabbit | Try for Free.

AI-first pull request reviewer with context-aware feedback, line-by-line code suggestions, and real-time chat.

www.coderabbit.ai

AI Code Review | Greptile | Merge 4X Faster, Catch 3X More Bugs

AI Code Reviews that understand your entire codebase. Automate PR reviews, catch bugs faster, improve code quality with AI-driven analysis. Try Greptile free!

Greptile

사람 리뷰어는 이 1차 필터를 통과한 뒤, 아키텍처나 비즈니스 로직처럼 AI가 판단하기 어려운 영역에 집중하는 구조로 자연스럽게 역할이 나뉘고 있다.

MCP, 인프라로서의 AI 도구

에이전트형 도구가 늘어나면서 자연스럽게 따라온 개념이 **MCP(Model Context Protocol)**다.

MCP란?

LLM이 외부 도구, 데이터, 서비스에 접근할 수 있도록 만든 표준 프로토콜이다. Anthropic이 공개했고, 이후 여러 AI 도구 생태계에서 공통 규격처럼 자리잡았다.

MCP가 없던 시절엔 "AI가 깃허브에 접근하게 하려면" 도구마다 각자 다른 연동 코드를 짜야 했다. MCP는 이걸 하나의 공통 인터페이스로 통일해서, 서버 하나만 만들면 어떤 MCP 호환 클라이언트에서든 재사용 가능하게 만든다.

What is the Model Context Protocol (MCP)? - Model Context Protocol

Model Context Protocol

USB가 기기마다 제각각이던 연결 단자를 표준화한 것과 비슷한 포지션이라고 보면 이해가 쉽다.

AI 모델과 외부 시스템 사이의 "연결 규격"인 셈이다.

실무에서 쓰이는 MCP 서버 예시

• 파일시스템 MCP — 로컬 파일을 읽고 쓸 수 있게 해주는 기본 서버.
• GitHub MCP — 이슈 조회, PR 생성, 코드 검색을 에이전트가 직접 수행하게 해준다.
• DB/Slack/Notion MCP — 사내 데이터베이스 조회, 팀 커뮤니케이션 도구, 문서 도구와의 연동.

에디터나 CLI에 이런 MCP 서버를 붙여두면, 에이전트가 "이슈 확인하고 → 관련 코드 찾고 → 수정하고 → PR까지 생성"하는 흐름을 하나의 요청으로 처리할 수 있게 된다.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"]
    }
  }
}

설정 자체는 이렇게 서버 실행 명령과 인자를 등록해주는 정도로 단순하다.

어떤 서버를, 어떤 권한 범위로 붙일지 판단하는 게 오히려 더 중요한 부분이다.

MCP 말고도 알아둘 인프라 개념들

MCP가 요즘 제일 많이 들리는 이름이긴 하지만, 그 앞뒤로 같이 알아두면 좋은 개념들이 몇 가지 더 있다.

Function calling (도구 호출)

사실 MCP보다 먼저 자리잡은 더 기본적인 개념이다.

LLM에게 "이런 이름과 파라미터(함수에 전달하는 입력값)를 가진 함수가 있다"는 스키마를 미리 알려주면, 모델이 대화 중 필요한 순간에 그 함수를 호출하겠다는 신호를 반환하는 방식이다.

MCP는 이 function calling을 표준화된 프로토콜로 감싸서, 매번 직접 스키마를 짜고 연동하지 않아도 되게 만든 것에 가깝다.

Function calling | OpenAI API

Learn how function calling enables large language models to connect to external data and systems.

OpenAI Developers

RAG와 벡터 DB

**RAG(Retrieval-Augmented Generation)**는 모델이 원래 알지 못하는 정보(사내 문서, 최신 코드베이스 등)를 답변 시점에 검색해서 함께 넘겨주는 구조다.

이때 문서를 의미 단위로 쪼개 임베딩(숫자 벡터)으로 바꿔 저장해두는 저장소가 벡터 DB다. Pinecone, pgvector, Weaviate 같은 것들이 여기 해당한다.

에이전트형 코딩 도구가 저장소 전체를 매번 통째로 읽는 대신, 관련 있는 코드 조각만 검색해서 가져오는 것도 이 RAG 구조를 내부적으로 활용하는 경우가 많다.

Retrieval-Augmented Generation (RAG) | Pinecone

Explore the limitations of foundation models and how retrieval-augmented generation (RAG) can address these limitations so chat, search, and agentic workflows can all benefit.

www.pinecone.io

A2A (Agent2Agent) 프로토콜

MCP가 "에이전트와 도구/데이터를 잇는 규격"이라면, A2A는 "서로 다른 벤더의 에이전트끼리 통신하기 위한 규격"이다. 구글이 주도해서 공개했다.

예를 들어 코드 리뷰를 맡는 에이전트와 배포를 맡는 에이전트가 서로 다른 회사의 도구라 해도, A2A를 통해 표준화된 방식으로 작업을 위임하고 결과를 주고받을 수 있게 하는 게 목표다.

지금 당장 개인 개발자가 직접 설정할 일은 적지만, 여러 에이전트가 협업하는 구조(Antigravity의 에이전트 매니저 같은)가 늘어날수록 이 개념도 자연스럽게 마주치게 된다.

Redirecting

a2a-protocol.org

여러 에이전트를 동시에 굴리는 워크플로우

에이전트형 도구가 자리잡으면서 생긴 또 다른 습관은, 에이전트를 하나만 쓰지 않는다는 점이다.

같은 저장소를 여러 개의 작업 디렉터리로 분리해주는 git worktree를 활용해서, 브랜치마다 별도의 에이전트를 동시에 돌리는 방식이 늘고 있다.

예를 들어 한쪽 에이전트는 버그를 고치고, 다른 쪽은 새 기능을 구현하고, 또 다른 쪽은 테스트를 보강하는 식으로 여러 작업을 병렬로 진행할 수 있다.

물론 사람이 그 결과를 동시에 리뷰해야 한다는 부담은 그대로 남는다.

그래서 "얼마나 많은 에이전트를 동시에 굴릴 수 있는가"보다 "그 결과를 얼마나 꼼꼼히 검증할 수 있는가"가 실질적인 병목이라는 이야기가 많다.

클라우드로 보내기 꺼려진다면: 로컬 LLM

지금까지 다룬 도구들은 대부분 코드를 외부 서버로 보내 처리한다.

그런데 금융, 공공, 보안 규제가 엄격한 조직에서는 코드 한 줄도 외부로 나가면 안 되는 경우가 있다.

이럴 때 대안이 되는 게 로컬 LLM이다. Ollama, llama.cpp 같은 도구로 모델을 자기 컴퓨터나 사내 서버에 직접 올려서 돌리는 방식이다.

Ollama

Ollama is the easiest way to automate your work using open models, while keeping your data safe.

ollama.com

장점은 명확하다. 코드가 외부로 나가지 않고, 사용량과 무관하게 추가 요금이 없다.

대신 대가도 있다. GPU 같은 하드웨어 자원이 필요하고, 클라우드의 최상위 모델만큼의 품질을 기대하기는 아직 어렵다.

그래서 보통은 "민감한 코드베이스는 로컬 모델로, 일반 작업은 클라우드 모델로" 나눠 쓰는 절충안이 현실적인 선택이 된다.

AI가 짠 코드, 저작권은 누구 것일까

의외로 잘 안 짚고 넘어가는 주제인데, AI가 생성한 코드의 저작권과 라이선스 문제는 실무에서 은근히 자주 걸린다.

크게 두 가지 논쟁이 있다.

첫째, 모델이 학습한 데이터 안에 있던 오픈소스 코드가 라이선스 표기 없이 그대로 재현될 가능성이다. 특히 카피레프트 라이선스(GPL 등)가 걸린 코드가 원본 표시 없이 섞여 나오면, 그걸 그대로 상용 프로젝트에 쓰는 순간 라이선스 위반 소지가 생긴다.

둘째, AI가 생성한 결과물 자체의 저작권 귀속이 법적으로 아직 명확하지 않다는 점이다. 국가와 판례에 따라 결론이 다르고, 여전히 정리되는 중인 영역이다.

404 - GitHub Docs

docs.github.com

그래서 회사 단위로는 "공개 코드와 유사도가 높은 제안은 걸러낸다"는 필터 옵션을 도구 차원에서 켜두거나, 사내 정책으로 AI 생성 코드의 리뷰·출처 확인 절차를 두는 경우가 늘고 있다. 개인 프로젝트라도 라이선스가 명시된 코드 조각을 그대로 가져다 쓰는 건 아닌지 한 번쯤 의심하는 습관이 필요하다.

효율적으로 활용하는 방법

• 맥락을 미리 정리해두자. 프로젝트 규칙, 폴더 구조, 코딩 컨벤션을 문서(예: CLAUDE.md, .cursorrules 같은 설정 파일)로 정리해두면, 매번 같은 설명을 반복할 필요 없이 AI가 일관된 기준으로 작업한다.
• 작업 단위를 작게 쪼개자. 큰 기능을 통째로 맡기기보다, 검증 가능한 단위로 나눠서 요청하면 중간에 방향이 틀어져도 되돌리기 쉽다.
• 결과를 반드시 검증하자. 특히 에이전트가 여러 파일을 동시에 수정하는 경우, 의도치 않은 사이드이펙트가 섞이기 쉽다. diff를 확인하는 습관은 여전히, 아니 오히려 더 중요해졌다.
• 모델과 도구를 작업 성격에 맞게 고르자. 단순 자동완성이면 가벼운 도구로 충분하고, 여러 파일에 걸친 리팩토링이라면 에이전트형 도구가 맞다. 모든 작업에 제일 무거운 도구를 쓸 필요는 없다.

주의사항과 보안

할루시네이션(Hallucination)이란?

AI가 실제로는 존재하지 않는 함수, 라이브러리, API를 마치 있는 것처럼 그럴듯하게 지어내는 현상이다.

확신에 찬 어조로 틀린 답을 내놓는 경우가 많아서, 오히려 모르는 영역일수록 더 위험하다. 결과를 직접 실행해보거나 공식 문서와 대조하는 습관이 사실상 유일한 방어책이다.

• 민감 정보를 그대로 넘기지 않는다. API 키, 토큰, 고객 데이터가 포함된 파일을 통째로 프롬프트에 붙여넣는 일이 의외로 흔하다. .env나 시크릿 파일은 애초에 AI 도구의 접근 범위에서 제외해야 한다.
• MCP 서버의 권한 범위를 최소화한다. 파일시스템 MCP를 프로젝트 루트가 아니라 전체 홈 디렉토리에 열어두는 식의 설정은 위험하다. 필요한 범위만 정확히 지정하자.
• 프롬프트 인젝션을 염두에 둔다. 에이전트가 외부 웹페이지, 이슈 코멘트, PR 설명 같은 외부 콘텐츠를 읽고 그 내용을 지시로 착각해 행동할 수 있다. 외부 입력이 섞이는 워크플로우일수록 결과를 더 꼼꼼히 확인해야 한다.
• 자동 실행 권한을 무분별하게 허용하지 않는다. 파일 삭제, 강제 푸시, 프로덕션 배포처럼 되돌리기 어려운 작업은 자동 승인 목록에서 빼두고, 항상 사람이 마지막에 확인하는 구조를 유지하자.
• AI의 출력을 그대로 신뢰하지 않는다. 그럴듯해 보이는 코드가 실제로는 존재하지 않는 API를 호출하거나, 미묘하게 틀린 로직을 담고 있는 경우가 있다. 특히 테스트가 없는 코드일수록 검증 없이 병합하지 않는다.