Chapter 6. AIND 이해와 활용
AIND (AI Native Development) 개요
AIND 정의
LG CNS AIND란?
LG CNS의 AI Native Development(AIND)는 AI 기술로 최적화된 전 공정 개발 및 Pair Programming 구현 접근 방식입니다.
"분석, 설계, 개발, 테스트 전 공정에서 AI 기술을 적용하여 이행 프로세스를 최적화 하고, 다양한 AI Assistant를 활용하여 프로젝트 이행을 전면 혁신하는 것입니다."
AI Coding이란?
AI Coding
AI Coding이란 코드 자동완성, 함수 생성, 오류 수정 등 코드 작성 단계에서 AI를 생산성 도구로 활용하는 방식입니다.
개발 방식 자체는 기존과 동일하되, AI가 개발 속도를 높이는 보조 수단으로 기능합니다.
GitHub Copilot, Cursor의 코드 자동완성, ChatGPT에 코드를 물어보는 행위 모두 AI Coding의 범주에 해당합니다.
개발자가 원하는 코드를 AI에게 요청하면 AI가 결과를 생성하고, 개발자가 이를 검토/사용하는 단방향 요청-응답 구조가 특징입니다.
AI Coding의 주요 활용 유형
| 대표적인 AI Coding 활용 사례 | AI Coding의 한계 |
|---|---|
| - 함수 이름 타이핑 시 AI가 전체 코드 자동완성 - "이 오류 메시지 원인이 뭐야?" 질문 후 해결책 수령 - "정렬 알고리즘 코드 작성해줘" 요청 후 복사/붙여넣기 - 리팩토링 대상 코드 선택 후 AI에게 개선 요청 - 테스트 코드 초안 자동 생성 요청 → 특정 코드 작성 작업에 국한된 단발성 AI 활용 | - AI가 비즈니스 요구사항의 배경을 알지 못함 - AI가 설계 결정의 이유를 이해하지 못함 - 각 요청이 독립적이어서 전체 맥락 일관성이 낮음 - 코드 작성 이외 단계(분석/설계/검증)에 미적용 - 품질 판단과 모든 책임은 온전히 개발자에게 있음 → 이 한계를 극복하기 위해 AIND 등장 |
AI Coding 도구와 AIND의 관계
GitHub Copilot, Cursor, Claude Code 같은 도구 자체가 'AI Coding'인 것은 아닙니다.
이 도구들을 코드 작성 보조 용도로만 쓰면 AI Coding이고, 요구사항 배경/설계 의도/도메인 규칙까지 AI와 공유하며 전주기에 활용하면 AIND가 됩니다.
구분 기준은 도구가 아닌 활용 방식입니다.
AI Coding과 AIND의 차이
| 구분 | AI Coding | AIND |
|---|---|---|
| 활용 범위 | 코드 작성 중심 — 코드 자동완성, 함수 생성 등 특정 코딩 작업 단계에만 AI를 활용 | 요구사항 정의 → 설계 → 구현 → 검증 전주기 — 개발의 모든 단계에서 AI와 협력하며, 기획/분석/테스트까지 AI가 참여 |
| 역할 | 생산성 도구 — 개발자의 작업 속도를 높이는 보조 수단. 개발 방식 자체는 기존과 동일 | 개발 패러다임 — AI를 팀원 수준으로 포함하는 새로운 개발 방식. 사고/설계 방식 자체의 변화 |
| 구조 | 단발성 활용 — 필요한 시점에 AI에게 요청하고 결과를 수령 | 반복적 협업 구조 — 도메인 지식/요구사항/설계 의도를 AI와 지속적으로 공유하며 맥락(컨텍스트)을 쌓아가는 반복 협업 사이클 |
| 책임 | 개발자 중심 — AI의 결과물은 참고용이며, 모든 품질 책임은 개발자에게 있음 | 개발자 + AI 협업 — AI와 함께 품질 기준을 설정하고 검증. 결과 책임은 개발자에게 있으나 AI가 품질 과정에 참여 |
| 컨텍스트 관리 | 코드 레벨 맥락 유지 — Cursor 등 도구는 파일 구조/함수/코딩 패턴 등 기술적 맥락을 유지하지만, 비즈니스 도메인 지식이나 설계 의도는 포함되지 않음 | 비즈니스/도메인 레벨까지 확장 — 코드 레벨 맥락에 더해 요구사항 배경, 설계 결정의 이유, 품질 기준까지 AI와 공유/유지함. 컨텍스트 엔지니어링이 AIND의 핵심 역량임 |
| 대상 역할 | 개발자 전용 — 코드를 직접 작성하는 엔지니어에게 국한 | PM/기획자/개발자 — 요구사항 정의, 설계, 구현, 검증 등 전 역할이 AI와 협업하는 방식으로 확장 |
AIND의 등장 배경
수요 측면의 변화
[소프트웨어 복잡도 증가] 마이크로서비스로 시작된 시스템 복잡도는 멀티클라우드/하이브리드 환경, AI 컴포넌트 통합으로 더욱 심화되었으며, 비결정적 AI 동작, 분산된 인프라, 방대한 API 의존성 등이 맞물리면서 개발자 혼자 전체/맥락을 유지하며 개발하는 것이 구조적으로 어려워졌습니다. → AI가 맥락을 보조 유지하는 협업 파트너로 부상
[개발 생산성 요구 증대] 시장 경쟁이 심화됨에 따라 시장 출시 속도(Time-to-Market) 압박이 높아지면서 기존 방식만으로는 한계에 도달했으며, 더 적은 인력으로 더 빠르게 개발해야 하는 압력이 증가하고 있습니다. → 단순 코드 보조(AI Coding)를 넘어 전주기 AI 협업이 필요해짐
[개발 인력 수급 불균형] 숙련 개발자 부족과 인건비 상승이 지속되면서 분석/설계자 등 비코딩 직군도 AI를 통해 개발 과정에 직접 참여할 수 있는 방법이 요구되기 시작했습니다. → AIND는 전 직군이 AI와 협업하는 패러다임으로 확장
기술 공급 측면의 변화
[대규모 언어 모델(LLM)의 고도화] GPT-4, Claude 등 LLM이 수만 토큰의 긴 컨텍스트를 이해하고 유지할 수 있게 되어, 단순 문장 생성을 넘어 요구사항 분석과 설계 추론이 가능해졌습니다. → AI가 일회성 도구가 아닌 지속적 협업 파트너로 동작 가능
[코드 이해 및 생성 능력 향상] 코드 특화 LLM이 고도화되어 버그 탐지, 리팩토링, 테스트 코드 생성 등 개발 전반의 작업을 수행할 수 있게 되었습니다. → AI 역할이 코드 보조 → 개발 전주기 참여로 확대
생태계 측면의 변화
- [AI 개발 도구 생태계 성숙] Cursor, Claude Code 등 IDE 통합 AI 도구와 LangChain, AutoGen 같은 Agent 프레임워크가 등장하고, 고도화됨에 따라 AIND를 실제 업무에 적용할 수 있는 환경이 갖춰지고 있습니다. → AIND는 개념이 아니라, 실현 가능한 개발 방식이 됨
AIND의 핵심 개념
컨텍스트 엔지니어링과 AIND의 관계
AIND의 핵심 개념인 컨텍스트 엔지니어링(Context Engineering)을 이해하려면 먼저 도구와 방법론의 차이를 구분해야 합니다.
도구(Tool) vs 방법론(Methodology) — Cursor는 AI Coding인가 AIND인가?
Cursor, GitHub Copilot, Claude Code 같은 도구 자체가 AI Coding인지 AIND인지를 결정하는 것이 아닙니다. 그 도구를 어떤 방식으로 활용하느냐가 AI Coding과 AIND를 구분합니다.
| AI Coding 방식으로 Cursor를 사용하는 경우 | AIND 방식으로 Cursor를 사용하는 경우 |
|---|---|
| 코드 자동완성, 함수 생성 요청, 오류 수정 등 코드 작성 작업에만 활용한다. 프로젝트 맥락은 Cursor가 코드베이스를 인덱싱한 수준에서 유지된다. → Cursor의 기능을 쓰지만, 활용 범위는 코드 작성 단계에 국한 | .cursorrules에 비즈니스 규칙/도메인 용어/설계 원칙을 정의하고, Skills로 반복 워크플로우를 자동화한다. → 동일한 도구지만, 비즈니스 맥락까지 AI와 공유하는 AIND 방식 |
컨텍스트 엔지니어링이란?
컨텍스트 엔지니어링이란 AI가 좋은 결과를 내기 위해 필요한 배경 정보/도메인 지식/제약조건/목표를 체계적으로 구성하고 전달하는 기술로, 단순히 "프롬프트를 잘 쓰는 것"을 넘어 AI가 프로젝트 전체를 이해하고 지속적으로 협업할 수 있도록 맥락을 설계하는 행위입니다.
Cursor 같은 도구가 코드베이스를 인덱싱하여 유지하는 것은 코드 레벨 맥락이며, 컨텍스트 엔지니어링은 여기서 한 단계 더 나아가 "왜 이렇게 만들어야 하는가" — 비즈니스 목표, 설계 결정의 이유, 도메인 규칙까지를 AI가 이해하도록 설계하는 것입니다.
컨텍스트 깊이 비교
아래는 같은 요청이지만 컨텍스트 깊이가 다른 예시입니다. AI가 받는 맥락의 수준이 결과물의 품질을 결정합니다.
| 코드 레벨 컨텍스트 (AI Coding) | 비즈니스/도메인 레벨 컨텍스트 (AIND) |
|---|---|
| "사용자 목록을 가져오는 API를 만들어줘." (Cursor가 코드베이스를 인덱싱하고 있는 상태) → AI는 기존 코드 패턴을 참고하지만, 인증 방식/페이징 정책/비즈니스 규칙은 여전히 임의로 결정 | .cursorrules에 인증은 JWT, 페이징은 커서 기반, 응답은 표준 래퍼 사용 등의 규칙이 정의됨 → AI가 시스템 구조뿐 아니라 비즈니스 규칙과 제약까지 이해하고 적합한 코드를 생성 |
AI와의 협업 사이클 (Prompt → Review → Refine)
AIND의 작업 방식은 단발성 요청-응답이 아닌 반복적인 3단계 협업 사이클로 이루어지며, 이 사이클이 AI Coding과 AIND를 구조적으로 가르는 핵심 특성입니다.
| ① Prompt | ② Review | ③ Refine |
|---|---|---|
| 컨텍스트를 포함한 요청을 AI에게 전달한다. 단순 명령이 아닌 배경/목표/제약을 함께 제공한다. (컨텍스트 엔지니어링이 적용되는 단계) | AI의 결과물을 비즈니스 요구사항, 기술 기준, 팀 컨벤션에 맞게 검토한다. 개발자의 판단력이 핵심이다. | 검토 결과를 바탕으로 컨텍스트를 보완하고 AI에게 재요청한다. 결과물이 기준에 맞을 때까지 반복한다. |
이 사이클이 반복될수록 AI는 더 많은 맥락을 갖게 되고, 결과물의 품질이 점점 높아집니다. AIND는 "한 번에 완벽한 결과"가 아닌 "반복을 통한 정교화"를 전제로 합니다.
개발자 역할의 변화 — 코드 작성 중심에서 설계/검토 중심으로
AIND를 도입한다고 해서 기존의 개발 지식이나 역량이 사라지는 것은 아닙니다. 오히려 개발자의 핵심 역할이 "무엇을 만들 것인가"를 설계하고 판단하는 방향으로 상향됩니다.
변화의 핵심은 아래와 같이 세 가지로 볼 수 있습니다.
코드 작성자 → 컨텍스트 설계자 요구사항/도메인 지식/설계 의도를 AI가 이해할 수 있도록 구조화하여 전달하는 역할이 중요해짐. AI에게 무엇을 어떻게 전달하는지가 결과물의 품질을 결정함.
구현 중심 → 검토/판단 중심 AI가 생성한 코드/설계안이 요구사항에 맞는지, 기술적으로 적절한지를 판단하는 역량이 핵심이 됨. AI는 틀린 결과를 자신 있게 제시할 수 있으므로 개발자의 비판적 검토가 품질의 최후 방어선임.
독립적 작업 → 반복 협업 설계 한 번의 요청으로 끝내려 하지 않고, 컨텍스트를 단계적으로 쌓아가며 AI와 반복 협업하는 워크플로우를 설계하는 역량이 필요해짐.
| 기존 AI Coding 방식 | AIND 방식 |
|---|---|
| 코드 작성자 중심 — 요구사항을 받아 직접 코드로 구현. AI는 코드 자동완성 보조 도구. 각 작업이 독립적으로 처리됨. 구현 세부사항에 집중. 코드 품질 = 개발자 책임 | 설계자/검토자 중심 — 요구사항/설계 의도를 AI에게 전달/정의. AI와 함께 방향을 탐색하고 결과를 검토. 컨텍스트를 누적하며 반복 협업. 전체 아키텍처와 품질 기준에 집중. AI 결과물의 적절성을 판단/수정 |
AIND에서 개발자의 가치는 "코드를 얼마나 빠르게 작성하느냐"에서 "AI에게 올바른 맥락을 전달하고, AI의 결과물을 정확하게 검토/판단하는 역량"으로 이동합니다.
컨텍스트 설계 역량
AI에게 어떤 배경과 제약을 전달해야 하는지를 구조화하는 능력으로, 이를 위해서는 비즈니스 도메인 이해와 시스템 아키텍처 이해가 선행되어야 합니다. 컨텍스트를 잘 설계하는 개발자가 AIND 환경에서 더 높은 생산성을 발휘합니다.
AI 결과물 검토/판단 역량
AI가 생성한 코드/설계안이 요구사항에 맞는지, 기술적으로 적절한지를 판단하는 능력입니다. AI는 틀린 결과를 자신 있게 제시할 수 있으므로, 개발자의 비판적 검토 능력이 품질의 최후 방어선이 됩니다.
반복 협업 설계 역량
한 번의 요청으로 끝내려 하지 않고, 단계적으로 컨텍스트를 쌓아가며 AI와 협업하는 워크플로우를 설계하는 능력입니다. 특히 복잡한 기능 구현 시 이 역량이 결과물의 완성도를 결정합니다.
개발 단계별 AIND 적용
요구사항 정의~검증 전주기에서 AI 역할 요약
AIND의 핵심 특성 중 하나는 AI가 코드 작성 단계에만 머물지 않고, 개발 전주기에 걸쳐 서로 다른 역할로 참여한다는 것입니다.
| 단계 | AI Coding | AIND에서의 AI 역할 | 개발자의 역할 |
|---|---|---|---|
| 요구사항 분석 | 개발자 단독 분석 (AI 미활용) | 요구사항 구조화 보조, 누락 케이스 탐지, 유사 사례 제안 | 비즈니스 맥락 제공, AI 제안 검토 및 확정 |
| 설계 | 설계 후 AI에게 코드 요청 | 아키텍처 대안 제시, 설계 의도 기반 구조 초안 생성 | 설계 의도/제약 전달, 대안 평가 및 결정 |
| 구현 | AI가 코드 자동완성 보조 | 컨텍스트 기반 코드 생성, 반복 수정, 리팩토링 제안 | 컨텍스트 설계, 결과물 검토/수정, 품질 판단 |
| 테스트/검증 | 개발자가 직접 테스트 작성 | 테스트 케이스 생성, 엣지 케이스 탐지, 코드 리뷰 보조 | 테스트 기준 정의, AI 생성 케이스 검토 및 보완 |
AIND 적용 전/후 비교 시나리오
하나의 실제 개발 상황을 통해 AI Coding 방식과 AIND 방식의 차이를 구체적으로 확인할 수 있습니다.
시나리오 : 주문 처리 API 신규 개발
| AI Coding 방식 접근 | AIND 방식 접근 |
|---|---|
| - 요구사항 문서를 읽고 개발자가 설계를 단독으로 완료 - IDE에서 "주문 API 만들어줘"로 코드 자동완성 활용 - 생성된 코드 조각들을 붙여 전체 구조 완성 - 테스트는 개발자가 직접 작성 - AI는 각 코드 작성 순간에만 개입 | - AI에게 시스템 구조, 기존 패턴, 비즈니스 규칙을 먼저 공유 - AI와 함께 API 설계 초안 검토 → 개발자가 방향 확정 - 컨텍스트 기반으로 전체 구조 코드 생성 → 검토 → 수정 반복 - AI가 엣지 케이스 제안, 개발자가 기준에 맞는지 판단 - AI가 테스트 케이스 초안 생성 → 개발자가 보완/확정 |
두 방식의 결과 차이
| AI Coding 결과 | AIND 결과 |
|---|---|
| - 코드 작성 속도는 빠름 - 각 코드 조각의 맥락 일관성이 낮을 수 있음 - 설계 결정은 모두 개발자 단독 - 누락된 케이스는 개발자가 직접 발견해야 함 | - 초기 설정 시간이 있으나 전체 품질이 높음 - 전체 코드가 일관된 맥락 하에서 생성됨 - 설계 대안을 AI와 검토하며 결정 품질 향상 - AI가 엣지 케이스 선제 탐지에 기여 |
AIND 실무 활용
주요 AI Coding 도구의 특징 비교
AIND를 실무에서 구현하려면 도구의 특성을 이해하고 상황에 맞게 선택해야 합니다. 대표적인 AI Coding 도구인 Cursor, Claude Code, GitHub Copilot의 핵심 차이점을 비교합니다.
도구별 핵심 특징
| 구분 | Cursor | Claude Code | GitHub Copilot |
|---|---|---|---|
| 형태 | AI 기능 내장 IDE (VS Code 기반) | 터미널 기반 AI 에이전트 | IDE 확장(Extension) 플러그인 |
| 핵심 특징 | 코드베이스 자동 인덱싱, Tab 자동완성 + Cmd+K 인라인 편집, Chat / Composer / Agent 모드, .cursorrules로 프로젝트 규칙 설정 | 프로젝트 전체 파일 자율 접근, 코드 편집/실행/테스트 자동 수행, CLAUDE.md로 컨텍스트 설정, 터미널에서 자연어로 지시 | 인라인 코드 자동완성 중심, Chat 기반 코드 Q&A, VS Code / JetBrains 등 지원, Copilot Workspace(프리뷰) |
| 컨텍스트 관리 | 코드베이스 인덱싱 + @파일/@폴더 참조로 컨텍스트 직접 지정 가능 | 프로젝트 전체를 자동 탐색하며 필요한 파일을 스스로 찾아 참조 | 현재 열린 파일 및 인접 파일 중심의 제한적 컨텍스트 |
| AIND 적합성 | 높음 — 규칙 파일과 컨텍스트 지정 기능으로 AIND 방식 적용에 적합 | 매우 높음 — 전주기 협업에 적합한 에이전틱 코드 도구 | 보통 — 코드 작성 보조에 강점이 있으나 AIND 전주기 적용에는 제약 |
| 적합 시나리오 | IDE 환경에서 코드 작성과 설계를 AI와 함께 반복 협업할 때 | 대규모 리팩토링, 멀티파일 작업, 자율적 작업 위임이 필요할 때 | 기존 IDE를 유지하면서 코드 자동완성 생산성을 높이고자 할 때 |
도구 선택의 핵심 기준
도구 자체보다 활용 방식이 AI Coding과 AIND를 구분한다는 원칙은 변하지 않습니다.
다만 도구마다 AIND 방식 적용의 용이성에 차이가 있으므로, 프로젝트 특성과 팀 역량에 맞는 도구를 선택하는 것이 중요합니다.
주요 Use Case 비교
동일한 작업을 각 도구에서 어떻게 수행하는지 비교하면 도구별 특성을 더 명확히 이해할 수 있습니다.
| Use Case | Cursor | Claude Code | GitHub Copilot |
|---|---|---|---|
| 코드 자동완성 | Tab 키로 실시간 자동완성, 멀티라인 제안 | 터미널에서 자연어 지시 후 코드 생성 | 인라인 실시간 자동완성 (가장 빠른 반응) |
| 코드 리팩토링 | 코드 선택 → Cmd+K로 인라인 리팩토링 지시 | "이 모듈을 리팩토링해줘" → 자율적으로 관련 파일 탐색/수정 | Chat에서 리팩토링 요청 → 제안 코드 수동 적용 |
| 멀티파일 작업 | Composer/Agent 모드에서 여러 파일 동시 편집 | 프로젝트 전체를 자동 탐색하며 필요한 파일 모두 수정 | 파일 단위 개별 작업 (멀티파일 동시 편집 제한적) |
| 테스트 코드 생성 | 대상 코드 참조하여 테스트 생성 요청 | "테스트 작성하고 실행까지 해줘" → 생성+실행+수정 자동 | Chat에서 테스트 생성 요청 → 결과 복사/붙여넣기 |
| 디버깅 | 오류 코드 선택 후 "이 오류 원인 분석해줘" 요청 | 에러 메시지 전달 → 원인 분석 + 자동 수정 + 재실행 확인 | 에러 메시지 붙여넣기 → 원인 설명 및 수정안 제시 |
프로젝트 설정 파일 활용
AIND에서 컨텍스트 엔지니어링을 실현하는 가장 구체적인 수단이 프로젝트 설정 파일입니다. 이 파일들은 AI가 프로젝트의 규칙, 구조, 제약을 지속적으로 참조할 수 있게 하여 매번 반복 설명 없이도 일관된 결과물을 생성하도록 돕습니다.
.cursorrules (Cursor)
Cursor에서 프로젝트 루트에 위치하는 설정 파일로, AI가 코드를 생성하거나 수정할 때 자동으로 참조하는 규칙을 정의합니다.
- 역할: 프로젝트의 코딩 컨벤션, 아키텍처 규칙, 금지 패턴, 선호 패턴 등을 AI에게 지속적으로 전달
- 위치: 프로젝트 루트 디렉토리 (예: /project-root/.cursorrules)
- 적용 범위: 해당 프로젝트에서 Cursor의 모든 AI 기능(자동완성, Chat, Composer 등)에 적용
포함해야 할 주요 내용
| 항목 | 예시 |
|---|---|
| 기술 스택 명시 | "이 프로젝트는 Spring Boot 3.2 + Java 17 + PostgreSQL을 사용합니다" |
| 코딩 컨벤션 | "메서드명은 camelCase, 클래스명은 PascalCase를 사용합니다. 모든 public 메서드에 Javadoc을 작성합니다" |
| 아키텍처 규칙 | "Controller → Service → Repository 계층 구조를 따르며, Controller에서 직접 Repository를 호출하지 않습니다" |
| 금지 패턴 | "System.out.println 대신 SLF4J 로거를 사용합니다. 하드코딩된 비밀번호/API 키를 절대 포함하지 않습니다" |
| 선호 패턴 | "예외 처리는 GlobalExceptionHandler를 통해 일괄 처리합니다. DTO 변환은 MapStruct를 사용합니다" |
CLAUDE.md (Claude Code)
Claude Code가 프로젝트 작업 시 자동으로 읽어 참조하는 설정 파일입니다. .cursorrules와 유사한 목적이지만, Claude Code의 에이전틱 특성에 맞게 보다 포괄적인 프로젝트 정보를 포함합니다.
- 역할: 프로젝트 구조, 빌드/테스트 명령어, 코딩 스타일, 도메인 규칙 등 프로젝트 전반의 컨텍스트 제공
- 위치: 프로젝트 루트 디렉토리 (예: /project-root/CLAUDE.md)
- 특징: Claude Code가 자율적으로 파일 탐색/편집/실행할 때 이 파일의 규칙을 준수
포함해야 할 주요 내용
| 항목 | 예시 |
|---|---|
| 프로젝트 개요 | "B2B SaaS 주문관리 시스템. 멀티테넌트 구조이며 테넌트 간 데이터 격리가 핵심 보안 요건임" |
| 프로젝트 구조 | "src/main/java: 소스코드, src/test: 테스트, docs/: API 문서, config/: 환경설정" |
| 빌드/실행 명령어 | "빌드: ./gradlew build / 테스트: ./gradlew test / 로컬 실행: docker-compose up" |
| 코딩 스타일 및 규칙 | "Google Java Style Guide 준수. 모든 API는 OpenAPI 3.0 스펙을 먼저 작성한 후 구현" |
| 도메인 규칙 | "주문 취소는 결제 완료 후 24시간 이내만 가능. 할인율은 고객 등급에 따라 차등 적용" |
| 금지 사항 | "main 브랜치 직접 수정 금지. 환경변수에 민감정보 하드코딩 금지. ORM 없이 raw SQL 금지" |
설정 파일이 컨텍스트 엔지니어링의 실체인 이유
컨텍스트 엔지니어링은 "AI에게 배경/목표/제약을 체계적으로 전달하는 기술"입니다.
.cursorrules와 CLAUDE.md는 이 원칙을 파일 형태로 구현한 것입니다. 매 대화마다 반복 설명하는 대신, 프로젝트 규칙을 파일로 정의하면 AI가 지속적으로 일관된 컨텍스트를 참조하게 됩니다.
즉, 설정 파일 = 지속적 컨텍스트(Persistent Context)의 실현 수단입니다.
Skills (커스텀 명령어)
.cursorrules와 CLAUDE.md가 "AI가 항상 참조하는 규칙"이라면, Skills는 "개발자가 호출하거나 에이전트가 자동으로 적용하는 실행 가능한 워크플로우"입니다. 도메인 특화 지식, 스크립트, 템플릿을 마크다운 파일로 정의하면, 팀원 누구나 동일한 명령어로 표준화된 작업을 수행할 수 있습니다. Cursor와 Claude Code 모두 Skills 체계를 제공하며, Agent Skills는 에이전트 도구 간 호환을 목표로 하는 오픈 표준으로 발전하고 있습니다.
| 구분 | Claude Code Skills | Cursor Agent Skills |
|---|---|---|
| 정의 방식 | .claude/skills/스킬명/SKILL.md 디렉토리 구조 (기존 .claude/commands/ 단일 파일도 하위 호환 지원) | .agents/skills/스킬명/ 디렉토리에 SKILL.md 파일 생성. .cursor/skills/도 지원 |
| 디렉토리 구조 | 디렉토리 단위 — SKILL.md(필수) + scripts/, templates, examples(선택). 기존 .claude/commands/ 단일 파일도 호환 | 디렉토리 단위 — SKILL.md(필수) + scripts/, references/, assets/(선택) |
| 호출 방식 | 터미널에서 /review처럼 슬래시 명령으로 수동 실행 | 에이전트가 컨텍스트 기반으로 자동 호출하거나, Chat에서 /스킬명으로 수동 실행 |
| 자동 호출 | 지원 — 에이전트가 컨텍스트에 기반하여 자동으로 스킬을 적용하며, 사용자가 / 명령으로 수동 호출도 가능 | 지원 — 에이전트가 관련성을 판단하여 자동 적용. disable-model-invocation: true로 수동 전용 전환 가능 |
| YAML 프론트매터 | name, description, disable-model-invocation, user-invocable, allowed-tools, context, model 등 | name, description(필수), license, compatibility, disable-model-invocation 등 |
| 인수 전달 | $ARGUMENTS 변수로 호출 시 전달한 값을 본문에 삽입 | 에이전트가 컨텍스트에서 필요한 정보를 자동으로 판단하여 전달 |
| 셸 명령/스크립트 | 본문에 !command 구문으로 셸 명령을 전처리 실행하여 동적 컨텍스트를 생성 가능 (예: !gh pr diff) | scripts/ 디렉토리에 Bash/Python/JS 스크립트를 배치하고 SKILL.md에서 상대 경로로 참조 |
| 도구 제한 | allowed-tools 프론트매터로 사용 가능한 도구를 제한 (예: Read만 허용) | 별도 도구 제한 기능 없음 |
| 공유 범위 | .claude/commands/는 프로젝트 공유, ~/.claude/commands/는 개인용 | .agents/skills/는 프로젝트 공유 (Git 커밋), ~/.cursor/skills/는 개인용. GitHub URL로 원격 설치도 가능 |
실무에서는 코드 리뷰 포맷을 /review 스킬로 표준화하거나, 배포 절차를 scripts/가 포함된 스킬로 자동화하는 등 팀 단위의 반복 워크플로우를 정의하는 데 활용합니다.
실습 예시: Skill 작성 따라하기 — 코드 리뷰 스킬
위에서 언급한 "코드 리뷰 포맷을 /review 스킬로 표준화"하는 사례를 실제로 만들어 보겠습니다. 아래 예시는 Claude Code와 Cursor에서 대부분 동일하게 동작합니다. Claude Code와 Cursor는 유사한 형태의 Skill 구조(SKILL.md + 프론트매터)를 사용하므로, 대부분의 경우 동일한 방식으로 재사용할 수 있습니다.
(1) 디렉토리 구조
code-review/
├── SKILL.md # 필수 — 스킬 지침 (프론트매터 + 마크다운)
└── checklist.md # 선택 — 상세 체크리스트 참조 문서설치 위치는 도구 및 버전에 따라 다를 수 있습니다. 아래는 대표적인 예시이며, SKILL.md 파일의 내용은 동일하게 재사용할 수 있습니다.
| 도구 | 프로젝트 공유 경로 | 개인용 경로 |
|---|---|---|
| Claude Code | .claude/skills/code-review/ | ~/.claude/skills/code-review/ |
| Cursor | .cursor/skills/code-review/ 또는 .agents/skills/code-review/ | ~/.cursor/skills/code-review/ |
(2) SKILL.md 작성
---
name: code-review
description: >
변경된 코드를 정확성, 보안, 일관성 관점에서 리뷰합니다.
코드 리뷰를 요청하거나 PR을 검토할 때 사용합니다.
disable-model-invocation: true
---# 코드 리뷰
변경된 파일을 아래 기준으로 리뷰하고, 발견된 이슈를 심각도별로 정리하세요.
## 리뷰 기준
1. **정확성**: 요구사항을 올바르게 구현했는가?
2. **보안**: SQL Injection, XSS, 하드코딩된 시크릿 등 보안 취약점이 없는가?
3. **일관성**: 프로젝트의 기존 코딩 컨벤션과 일치하는가?
4. **에러 처리**: 예외 상황, null 체크, 경계값이 적절히 처리되었는가?
## 출력 형식
### 심각 (즉시 수정 필요)
- 파일명:라인번호 — 이슈 설명
### 권장 (개선 권장)
- 파일명:라인번호 — 이슈 설명
### 제안 (선택적 개선)
- 파일명:라인번호 — 이슈 설명
이슈가 없으면 "리뷰 완료: 이슈 없음"으로 마무리합니다.
상세 체크리스트는 checklist.md를 참조하세요.(3) 프론트매터 핵심 필드 설명
| 필드 | 값 | 설명 |
|---|---|---|
| name | code-review | 스킬 이름. /code-review로 호출할 때 사용 |
| description | 변경된 코드를... | AI가 이 스킬을 자동 적용할지 판단하는 기준. 용도와 사용 시기를 명확히 기술 |
| disable-model-invocation | true | AI가 자동으로 실행하지 않고, 개발자가 /code-review를 입력할 때만 동작 (환경에 따라 동작 방식은 다를 수 있음) |
disable-model-invocation을 true로 설정한 이유는 코드 리뷰처럼 개발자가 타이밍을 직접 결정해야 하는 작업에서 AI가 임의로 실행하는 것을 방지하기 위함입니다. 반대로, API 규칙이나 코딩 스타일처럼 항상 참고될 수 있는 지식형 스킬은 이 옵션을 생략할 수 있으며, 자동 적용 여부는 모델의 판단에 따라 달라질 수 있습니다.
(4) 호출 방법
| 도구 | 호출 방식 |
|---|---|
| Claude Code (터미널) | /code-review |
| Cursor (Chat/Agent) | /code-review |
두 도구 모두 /스킬명으로 동일하게 호출합니다.
이처럼 Skills는 한 번 작성하면 팀 전체가 /code-review 한 줄로 동일한 기준의 코드 리뷰를 수행할 수 있습니다. 리뷰 기준이 변경되면 SKILL.md만 수정하면 되므로, 팀의 리뷰 품질을 코드(파일)로 관리할 수 있다는 것이 Skills의 핵심 가치입니다.
기존 Cursor Commands에서의 마이그레이션
Cursor 2.4부터 기존 Commands 체계가 Skills로 전환되었습니다. 내장 /migrate-to-skills 명령을 실행하면 기존 슬래시 명령어가 disable-model-invocation: true 설정의 스킬로 자동 변환되어 기존 호출 방식이 유지됩니다.
Skills = 실행 가능한 컨텍스트(Executable Context)
설정 파일(.cursorrules, CLAUDE.md)이 AI가 항상 참조하는 "수동적 컨텍스트"라면, Skills는 개발자가 필요한 시점에 호출하거나 에이전트가 자동으로 적용하는 "능동적 컨텍스트"입니다. 둘을 조합하면 규칙 준수(설정 파일)와 작업 표준화(Skills)를 동시에 달성할 수 있습니다.
설정 파일이 컨텍스트 엔지니어링의 실체인 이유
컨텍스트 엔지니어링은 "AI에게 배경/목표/제약을 체계적으로 전달하는 기술"입니다. .cursorrules, CLAUDE.md, Skills는 이 원칙을 파일 형태로 구현한 것입니다. 매 대화마다 반복 설명하는 대신, 프로젝트 규칙과 워크플로우를 파일로 정의하면 AI가 지속적으로 일관된 컨텍스트를 참조하게 됩니다. 즉, 설정 파일 + Skills = 지속적 컨텍스트(Persistent Context)의 실현 수단입니다.
MCP, Skills, Rules/CLAUDE.md 비교
MCP는 여러 AI 도구에서 공통으로 사용되는 오픈 프로토콜이고, Skills와 Rules/CLAUDE.md는 각 도구의 설정 파일입니다. 추상화 수준은 다르지만, 실무에서는 함께 조합하여 사용하므로 역할을 비교하면 다음과 같습니다.
| 구분 | MCP | Skills | .cursorrules / CLAUDE.md |
|---|---|---|---|
| 역할 | 외부 도구 데이터 연결 | 에이전트 새 능력 추가 | 에이전트 행동 규칙 설정 |
| 작동 방식 | 도구 호출(Tool Use) | SKILL.md의 Description 기반 자동 발견 및 실행 | 항상 적용 또는 경로별 적용 (선언적) |
| 예시 | GitHub, Slack, DB 연동 | 배포 자동화, PR 리뷰, 코드 시각화 | 코딩 컨벤션, API 설계 규칙, 커밋 형식 |
즉, MCP가 외부 시스템을 "연결"하는 것이라면, Agent Skills는 에이전트에 새로운 능력을 "설치"하는 것이며, Rules/CLAUDE.md는 에이전트의 행동 규칙을 "설정"하는 것입니다.
같은 모델, 같은 스킬인데 왜 결과가 다를까? — 하네스(Harness)의 역할
Cursor와 Claude Code에 동일한 모델(예: Claude Sonnet)을 연결하고, 같은 프롬프트를 주더라도 결과물이 달라지는 경우가 많습니다. 모델이 같은데 왜 차이가 날까요? 그 핵심 원인이 바로 하네스(Harness) 입니다.
하네스는 원래 말에 씌우는 마구를 뜻합니다. 마구는 말이 아무 방향으로나 달리지 못하도록 움직임의 방향과 범위를 통제하는 장비입니다. AI 에이전트에서도 마찬가지로, 하네스는 모델을 감싸고 있는 실행 환경 — 시스템 프롬프트, 도구 호출 방식, 파일 접근 전략, 컨텍스트 주입 순서 등을 통칭하는 비유적 표현이며, 공식 표준 용어라기보다는 실무에서 사용하는 개념에 가깝습니다.
같은 말(모델)이라도 어떤 마구(하네스)를 씌우느냐에 따라 움직임이 완전히 달라지듯, 같은 LLM이라도 하네스 설계에 따라 결과물의 품질과 일관성이 크게 달라집니다. 실제로 도구 간 차이 역시 모델 자체보다는 이러한 실행 환경(하네스) 설계의 차이에서 비롯되는 경우가 많습니다.
| 하네스 구성 요소 | Cursor | Claude Code |
|---|---|---|
| 컨텍스트 수집 방식 | 코드베이스 인덱싱 + 사용자가 @파일로 지정 | 프로젝트 전체를 자율 탐색하며 필요한 파일을 스스로 선택 |
| 시스템 프롬프트 | IDE 내장 프롬프트 + .cursorrules | 터미널 에이전트용 프롬프트 + CLAUDE.md |
| 도구 실행 | IDE 내부에서 편집/미리보기 | 터미널에서 셸 명령/파일 편집/테스트 실행까지 자율 수행 |
| 세션 연속성 | 대화 히스토리 기반 | 진행 파일/git 커밋 기반으로 세션 간 상태 복원 |
도구별 차이(컨텍스트 관리, AIND 적합성 등)는 사실상 각 도구가 제공하는 하네스의 차이입니다. .cursorrules, CLAUDE.md, Skills 같은 설정 파일은 이 하네스를 개발자가 직접 커스터마이징하는 수단이며, 하네스를 얼마나 잘 설계하느냐가 동일 모델에서도 결과물의 품질을 가르는 핵심 변수입니다.
레거시 코드 분석 및 리팩토링
프로젝트에서 가장 빈번한 실무 시나리오 중 하나가 기존 레거시 시스템의 분석과 리팩토링입니다. AIND 방식을 적용하면 이 과정을 체계적이고 효율적으로 수행할 수 있습니다.
AI 도구를 활용한 레거시 코드 이해 전략
레거시 코드를 처음 접할 때 AI 도구를 활용하면 이해 속도를 크게 높일 수 있습니다. 다만 AI에게 단순히 "이 코드 설명해줘"라고 요청하는 것(AI Coding)과, 체계적으로 분석 맥락을 설계하여 요청하는 것(AIND)은 결과물의 깊이에서 큰 차이가 납니다.
| 분석 활동 | AI Coding 접근 | AIND 접근 |
|---|---|---|
| 코드 요약 | "이 파일 설명해줘" → 함수 단위 설명 | 시스템 목적, 비즈니스 규칙을 먼저 전달한 뒤 "이 모듈의 역할을 비즈니스 흐름 관점에서 분석해줘" |
| 의존관계 분석 | "이 클래스가 뭘 호출하는지 알려줘" | "아키텍처 규칙(계층 구조)을 기준으로 이 모듈의 의존관계가 적절한지 분석해줘" |
| 기술 부채 식별 | "이 코드 문제 있어?" → 표면적 이슈 탐지 | 팀 코딩 표준, 대상 아키텍처를 컨텍스트로 제공 후 "현재 코드와 목표 상태의 gap을 분석해줘" |
| 비즈니스 로직 추출 | "이 함수 뭐 하는 거야?" | "이 코드에 숨어 있는 비즈니스 규칙(할인 정책, 권한 검증 등)을 요구사항 형태로 정리해줘" |
리팩토링 시 범위 한정과 단계적 접근
AI 도구를 활용한 리팩토링에서 가장 중요한 원칙은 "한 번에 모든 것을 바꾸지 않는 것"입니다.
| 원칙 | 설명 | 실천 방법 |
|---|---|---|
| 범위 한정 | 리팩토링 대상을 명확히 한정하여 AI에게 전달. 전체를 한 번에 맡기면 일관성이 떨어짐 | "OrderService 클래스의 calculateDiscount 메서드만 리팩토링해줘. 기존 인터페이스(입출력)는 유지해줘" |
| 단계적 진행 | 큰 변경을 여러 단계로 나누어 진행. 각 단계마다 AI의 결과를 검증한 후 다음 단계 진행 | 1단계: 코드 구조 분석 → 2단계: 인터페이스 정의 → 3단계: 핵심 로직 리팩토링 → 4단계: 테스트 검증 |
| 제약 조건 명시 | 변경하면 안 되는 부분, 유지해야 할 외부 인터페이스, 성능 기준 등을 명확히 전달 | "외부 API 호출 시그니처는 변경 불가. 응답 시간 200ms 이하 유지. 기존 단위 테스트가 모두 통과해야 함" |
| 동작 보전 검증 | 리팩토링 전후로 동일한 동작을 보장하는지 반드시 확인 | 리팩토링 전 기존 테스트 통과 확인 → 리팩토링 수행 → 동일 테스트 재실행 → 신규 엣지 케이스 테스트 추가 |
AIND 방식 리팩토링의 핵심
AI에게 "이 코드 리팩토링해줘"(AI Coding)가 아니라, "변환 목표, 제약 조건, 유지해야 할 인터페이스"를 명시하고 단계별로 협업하는 것(AIND)이 결과물의 안정성과 품질을 결정합니다.
이는 Prompt → Review → Refine 협업 사이클의 전형적인 적용 사례입니다.
코드 리뷰 및 품질 검증
AIND에서 개발자는 "코드 작성자"에서 "검토자/판단자"로 역할이 이동합니다. AI가 생성한 코드를 효과적으로 검증하려면 AI 코드의 공통적인 문제 유형을 알고, 체계적인 리뷰 관점을 갖추어야 합니다.
AI 생성 코드의 흔한 문제 유형
AI가 생성한 코드는 겉보기에 완벽해 보일 수 있지만, 다음과 같은 유형의 문제를 자주 포함합니다. 개발자는 이 패턴을 숙지하고 의식적으로 검증해야 합니다.
| 문제 유형 | 증상 | 검증 방법 |
|---|---|---|
| Hallucinated API/라이브러리 | 실제로 존재하지 않는 함수, 클래스, 라이브러리를 자신 있게 사용 | import 문 확인, 공식 문서 대조, 컴파일/실행 테스트로 존재 여부 검증 |
| 불완전한 에러 처리 | Happy Path 중심 구현. 예외 상황, null 처리, 경계값 누락 | "어떤 예외가 발생할 수 있는지 분석해줘" 후속 요청, 엣지 케이스 테스트 |
| 과도한 추상화 | 불필요한 디자인 패턴 적용, 과도한 계층 분리로 코드 복잡도 증가 | 현재 요구사항 대비 필요 이상의 추상화인지 판단. YAGNI 원칙 적용 |
| 컨텍스트 불일치 | 프로젝트의 기존 패턴, 컨벤션과 다른 스타일로 코드 생성 | 기존 코드와의 일관성 확인. 설정 파일(.cursorrules 등)에 규칙 추가 |
| 보안 취약점 | SQL Injection, XSS, 하드코딩된 시크릿 등 보안 이슈 포함 | 보안 체크리스트 기반 검토, AI에게 "이 코드의 보안 취약점 분석해줘" 교차 리뷰 |
| 비효율적 구현 | 성능을 고려하지 않은 N+1 쿼리, 불필요한 반복 연산, 과도한 메모리 사용 | 대량 데이터 시나리오 테스트, 성능 기준 명시 후 AI에게 최적화 요청 |
AI 코드 리뷰 체크리스트
AI 생성 코드를 검토할 때 다음 관점에 대해 체계적인 확인이 필요합니다.
| 검토 관점 | 확인 항목 |
|---|---|
| 정확성 | - 요구사항을 정확히 구현했는가? - 사용된 API/라이브러리가 실제로 존재하고 올바르게 호출되었는가? - 비즈니스 로직이 도메인 규칙과 일치하는가? |
| 완전성 | - 에러 처리, 경계값, null 체크가 빠짐없이 구현되었는가? - 엣지 케이스(빈 리스트, 최대값 초과, 동시성 등)가 고려되었는가? |
| 일관성 | - 기존 코드베이스의 네이밍 컨벤션, 아키텍처 패턴과 일치하는가? - 프로젝트 설정 파일(.cursorrules, CLAUDE.md)의 규칙을 준수하는가? |
| 보안성 | - 입력 검증이 적절한가? (SQL Injection, XSS 등) - 민감정보가 노출되지 않는가? (API 키, 비밀번호 등) - 인증/인가 로직이 적절한가? |
| 유지보수성 | - 코드가 불필요하게 복잡하지 않은가? (과도한 추상화, 불필요한 패턴) - 적절한 주석과 문서화가 되어 있는가? - 테스트가 작성되어 있고 의미 있는 시나리오를 커버하는가? |
AI를 활용한 교차 리뷰
AI가 생성한 코드를 다시 AI에게 리뷰시키는 "교차 리뷰" 방식도 효과적인 품질 검증 방법입니다.
생성과 리뷰 분리: AI에게 코드를 생성시킨 후, 새로운 대화에서 "이 코드를 보안/성능/아키텍처 관점에서 리뷰해줘"라고 요청하면 자기 생성물에 대한 편향 없이 객관적 분석을 받을 수 있습니다.
역할 지정 리뷰: "너는 10년 경력의 시니어 보안 엔지니어야. 이 코드의 보안 취약점을 찾아줘"와 같이 특정 전문가 역할을 부여하면 해당 관점에 집중한 리뷰를 받을 수 있습니다.
체크리스트 기반 리뷰: 위의 리뷰 체크리스트를 AI에게 함께 제공하고 "이 체크리스트의 각 항목에 대해 이 코드를 평가해줘"라고 요청하면 체계적인 리뷰 결과를 얻을 수 있습니다.
AI 리뷰의 한계를 인식하라
AI 교차 리뷰는 유용한 보조 수단이지만, 최종 판단은 반드시 개발자가 해야 합니다.
AI는 비즈니스 맥락의 적절성, 조직 내 암묵적 규칙 준수 여부, 실제 운영 환경의 제약 등을 완전히 이해하지 못합니다.
개발자의 비판적 검토 역량이 품질의 최후 방어선이라는 원칙은 AI 리뷰를 활용할 때도 동일하게 적용됩니다.
보안 및 기밀성 고려사항
Cursor, Claude Code와 같은 상용 AI Coding 도구를 SI 프로젝트에 도입할 때 반드시 고려해야 할 보안 및 기밀성 이슈를 다룹니다. 도구의 기능적 장점만큼이나 데이터 보호와 법적 리스크에 대한 이해가 AIND 실무 역량의 필수 요소입니다.
소스코드 및 데이터 전송 리스크
상용 AI Coding 도구를 사용하면 코드와 프롬프트가 외부 AI 서비스(클라우드)로 전송됩니다. 이 과정에서 발생할 수 있는 리스크를 이해해야 합니다.
| 리스크 유형 | 설명 | 대응 방안 |
|---|---|---|
| 소스코드 외부 노출 | 프롬프트에 포함된 코드가 AI 서비스 제공자의 서버로 전송됨 | 기업용 플랜(데이터 비학습 보장) 사용, 민감 모듈은 AI 도구 사용 범위에서 제외 |
| 고객 데이터 유출 | 테스트 데이터나 설정 파일에 포함된 실제 고객 정보가 전송될 수 있음 | 실제 데이터 대신 마스킹/더미 데이터 사용, 환경변수로 민감정보 분리 |
| API Key/인증정보 노출 | 코드 내 하드코딩된 API 키, 비밀번호, 토큰 등이 AI에게 전달됨 | .env 파일 분리 + .gitignore 등록, 설정 파일에 "시크릿 하드코딩 금지" 규칙 명시 |
| 학습 데이터 활용 우려 | 전송된 코드가 AI 모델의 향후 학습 데이터로 사용될 가능성 | 서비스 약관의 데이터 활용 정책 확인, 학습 제외(Opt-out) 옵션 활성화 |
(1) 민감 파일 접근 제어 (Ignore / Deny 설정)
위 리스크에 대한 기술적 1차 방어선으로, AI 도구가 민감 파일을 자동으로 읽거나 참조하지 못하도록 설정하는 방법이 있습니다. 도구별로 제공하는 접근 제어 메커니즘이 다르므로 차이를 이해하고 적절히 조합해야 합니다.
| 구분 | .claudeignore | settings.json permissions.deny | .cursorignore |
|---|---|---|---|
| 도구 | Claude Code | Claude Code | Cursor |
| 위치 | 프로젝트 루트 (/.claudeignore) | ~/.claude/settings.json 또는 프로젝트 .claude/settings.json | 프로젝트 루트 (/.cursorignore) |
| 문법 | .gitignore와 동일한 글로브 패턴 | JSON 배열로 "도구(패턴)" 형태 지정 | .gitignore와 동일한 글로브 패턴 |
| 차단 수준 | 소프트 차단 — AI의 자동 탐색/인덱싱에서 제외 | 하드 차단 — 해당 도구의 실행 자체를 차단 (우회 불가) | 소프트 차단 — AI의 인덱싱 및 컨텍스트 참조에서 제외 |
| 우회 가능성 | 사용자가 명시적으로 파일을 지정하면 읽을 수 있음 | 우회 불가. 설정된 패턴에 대해 도구 실행이 거부됨 | 사용자가 직접 파일을 열어 참조하면 읽을 수 있음 |
| 권장 용도 | 테스트 데이터, 빌드 산출물 등 탐색 불필요 파일 제외 | .env, secrets, 인증정보 등 절대 읽으면 안 되는 파일 차단 | 민감 설정 파일, 고객 데이터 디렉토리 등 인덱싱 제외 |
(2) permissions.deny 실전 설정 예시
| 패턴 | 차단 대상 | 효과 |
|---|---|---|
| Read(.env) | .env 파일 | AI가 환경변수 파일을 읽는 것 자체를 차단 |
| Read(.env.*) | .env.local, .env.production 등 | 모든 환경별 설정 파일 읽기 차단 |
| Read(secrets/**) | secrets 디렉토리 전체 | 인증서, 키 파일 등 민감 디렉토리 전체 읽기 차단 |
| Bash(curl *) | curl 명령 실행 | AI가 외부 서버로 데이터를 전송하는 것을 차단 |
.claudeignore + permissions.deny 이중 방어 권장
.claudeignore는 AI가 자동으로 파일을 찾아 읽는 것을 방지하고, permissions.deny는 어떤 경우에도 해당 파일에 접근하지 못하도록 강제합니다. 민감 파일에는 두 설정을 모두 적용하는 이중 방어가 권장됩니다.
AI 생성 코드의 라이선스 및 저작권
AI가 생성한 코드의 법적 지위는 아직 명확하게 확립되지 않은 영역이 있으며, 실무에서 인지해야 할 주요 이슈는 다음과 같습니다.
저작권 귀속 불명확: AI가 생성한 코드가 저작권법상 보호받는 저작물인지, 저작권이 누구에게 귀속되는지에 대해 국가별로 해석이 다르며 판례가 축적되는 중입니다.
오픈소스 라이선스 위반 리스크: AI 모델이 학습한 오픈소스 코드와 유사한 코드를 생성할 가능성이 있으며, GPL 등 강한 카피레프트 라이선스의 코드가 포함될 경우 라이선스 위반 리스크가 존재합니다.
실무 대응: AI 생성 코드를 그대로 사용하기보다 개발자가 충분히 검토하고 수정하여 자체 저작물로서의 독창성을 확보하는 것이 권장됩니다. 또한 프로젝트 차원에서 AI 생성 코드 사용에 대한 가이드라인을 수립해야 합니다.
SI 프로젝트에서의 AI 도구 사용 가이드라인
AIND를 SI 프로젝트에 적용할 때 수립해야 할 보안 가이드라인의 주요 항목은 다음과 같습니다.
| 검토 관점 | 확인 항목 |
|---|---|
| 허용 도구 및 플랜 지정 | 프로젝트에서 사용 가능한 AI 도구와 플랜(기업용)을 명시하고, 개인용 플랜/무료 도구 사용을 제한 |
| AI 도구 사용 범위 정의 | AI 도구에 입력 가능한 코드/데이터의 범위와 제외 대상(보안 모듈, 인증 로직, 고객 데이터 등)을 명확히 정의 |
| 민감정보 처리 규칙 | API 키, 인증 토큰, 고객 데이터 등 민감정보가 AI 도구에 전달되지 않도록 하는 구체적 방법(환경변수 분리, 데이터 마스킹 등) 규정 |
| 코드 리뷰 의무화 | AI 생성 코드에 대해 반드시 인간 개발자의 리뷰를 거친 후 커밋하도록 프로세스 규정 |
| 라이선스 검증 | AI 생성 코드의 오픈소스 라이선스 위반 여부를 검증하는 절차(라이선스 스캐닝 도구 활용 등) 포함 |
한눈에 정리하는 이번 챕터
AIND는 AI를 개발 전주기의 협업 파트너로 삼는 패러다임이다. 코드 작성 보조 도구인 AI Coding과 구분된다.
AI Coding 도구(Cursor 등)도 코드 레벨 맥락은 유지한다. AIND의 차이는 비즈니스 도메인 지식/설계 의도/품질 기준까지 AI와 공유하는 것이다. 도구가 아니라 활용 방식이 AI Coding과 AIND를 가른다.
컨텍스트 엔지니어링은 AI에게 배경/목표/제약을 체계적으로 전달하는 기술로, AIND의 핵심 역량이다.
AIND의 협업 사이클은 Prompt → Review → Refine의 반복이다. 이 반복이 결과물 품질을 점진적으로 높인다.
AIND에서 개발자는 설계자/검토자 역할로 이동한다. 코드를 직접 쓰는 것보다 맥락을 설계하고 결과를 판단하는 역량이 중요해진다.
AIND는 개발자만의 방법론이 아니라 분석/설계자 포함 전 직군이 AI와 협업하는 방식으로 확장된다.
AI Coding 도구(Cursor, Claude Code, GitHub Copilot)는 각각 다른 강점을 가진다. 프로젝트 특성과 팀 역량에 맞는 도구를 선택하되, AIND 적용 용이성을 고려해야 한다.
.cursorrules와 CLAUDE.md 등 프로젝트 설정 파일은 컨텍스트 엔지니어링을 파일로 구현한 것이다. 코딩 규칙, 아키텍처 원칙, 도메인 규칙을 정의하여 AI의 일관된 결과물 생성을 유도한다.
레거시 코드 분석 및 리팩토링에 AIND를 적용할 때는 범위 한정, 단계적 진행, 제약 조건 명시, 동작 보전 검증의 4가지 원칙을 따른다.
AI가 생성한 코드는 Hallucinated API, 불완전한 에러 처리, 보안 취약점 등의 문제를 포함할 수 있다. 정확성/완전성/일관성/보안성/유지보수성 관점의 체계적 검토가 필수이다.
SI 프로젝트에서 AI 도구 사용 시 소스코드/고객 데이터의 외부 전송 리스크, 기업용 플랜의 데이터 정책, AI 생성 코드의 라이선스 이슈를 반드시 고려해야 한다.