AI가 코드를 작성하고 수정하는 시대가 도래했습니다. 하지만 여전히 LLM(대형 언어 모델)이 가진 한계와 문제점이 존재합니다. 특히 Claude Sonnet을 기반으로 코딩을 수행할 때 발생하는 주요 맹점을 정리했습니다. 이를 이해하고 대비하면 AI 코딩을 더욱 효과적으로 활용할 수 있습니다.
🔎 1. 문제 해결 능력 부족 (Stop Digging)
LLM은 특정 작업을 수행하는 데 집중하지만, 문제 발생 시 방향을 바꾸는 능력이 부족합니다.
📌 문제 상황
- 기능 X를 구현하다가 기능 Y가 선행되어야 함을 인지하지 못하고 계속 X를 수행하려고 함.
- 예상과 다른 결과가 나와도 원인을 분석하지 않고 계속 같은 방식으로 시도.
✅ 해결 방법
- AI에게 명확한 계획을 제공: 먼저 작업 순서를 분석하고 선행 작업을 명확히 정의해야 함.
- 추론 모델 활용: Sonnet 같은 AI 에이전트가 계획 수립을 돕도록 활용.
- 자동 감시 시스템 도입: 별도의 감시 LLM이 문제를 감지하고 방향 전환을 요청하도록 설정.
🏆 사례
Monte Carlo 시뮬레이션에서 난수 샘플링 방식을 변경했을 때, AI가 이를 인식하지 못하고 기존 테스트 조건을 완화하는 방식으로 해결하려고 함. 대신 결정론적 시뮬레이션 방식으로 수정하는 것이 더 적절한 해결책이었음.
🛠️ 2. 정적 타입 필요 (Use Static Types)
LLM은 보일러플레이트 코드와 리팩토링을 자동화할 수 있어 동적 타입 언어(Python, JavaScript)에서도 유용하지만, 유지보수를 위해서는 정적 타입이 필요합니다.
📌 문제 상황
- 동적 타입 환경에서는 타입 오류 발생 가능성이 높음.
- Python 및 JavaScript에서 점진적 타입 시스템(Type Hints, TypeScript)을 활용하지 않으면 AI가 타입 불일치 문제를 해결하지 못함.
✅ 해결 방법
- 엄격한 타입 체크 설정: Python에서는 mypy, JavaScript에서는 tsc를 적극 활용.
- LLM이 타입 오류를 감지하도록 프롬프트 설계: AI가 타입 문제를 인식하도록 지시.
- Rust 같은 정적 타입 언어를 활용: Rust는 타입 안정성이 높아 AI 코드 생성 시 오류 발생 가능성이 낮음.
🏆 사례
Sonnet 3.7이 TypeScript 프로젝트에서 타입 체크를 수행할 때 npm run typecheck를 잘못된 명령어로 추론하는 경우 발생. AI가 직접적으로 타입 검사를 수행하도록 설정하는 것이 필요함.
🔍 3. 블랙 박스 테스트 불가 (Black Box Testing)
AI는 코드 컨텍스트를 포함하고 있어 블랙 박스 테스트를 수행하기 어려움.
📌 문제 상황
- AI가 내부 구현을 알고 있기 때문에 블랙 박스 테스트 원칙을 따르지 않음.
- 테스트 파일의 중복 제거를 시도해 오히려 버그 탐지 능력이 감소.
✅ 해결 방법
- 구현 세부 정보를 AI에게 숨기기: 특정 파일을 제외하거나 요약된 정보를 제공.
- 블랙 박스 테스트 경계를 명확히 정의: AI가 내부 구현을 수정하지 않도록 제한.
🏆 사례
Sonnet 3.7이 테스트 코드 수정 시 하드코딩된 상수를 내부 알고리즘 기반으로 자동 계산하도록 변경. 원래는 하드코딩된 값이 유지되어야 했음.
🔐 4. MCP 서버 필요 (Use MCP Servers)
MCP(Model Context Protocol) 서버를 사용하면 AI가 환경과 상호작용할 수 있습니다.
📌 문제 상황
- Sonnet과 같은 AI가 필요한 파일을 자동으로 검색하지 못하고 사용자가 직접 제공해야 함.
- 빌드 및 테스트 수행 후 AI가 자동으로 문제를 수정하는 기능 부족.
✅ 해결 방법
- MCP 서버 활용: AI가 MCP 서버를 통해 필요한 파일을 직접 불러올 수 있도록 설정.
- 커스텀 MCP 서버 구축: 특정 명령만 수행할 수 있도록 보안성을 강화.
🏆 사례
Sonnet 3.7이 TypeScript 프로젝트의 타입 체크 오류를 수정할 때 MCP를 사용해 자동으로 파일을 수정. 그러나 잘못된 npm 명령을 추론하는 경우도 발생함.
🎭 5. 불필요한 리팩토링 발생 (Preparatory Refactoring)
AI가 과도한 리팩토링을 수행해 코드가 불필요하게 변경될 수 있음.
📌 문제 상황
- 필요하지 않은 리팩토링을 수행하여 코드가 복잡해짐.
- Sonnet 3.7은 명령 수행 정확도가 떨어져 비관련 리팩토링 발생 가능.
✅ 해결 방법
- AI에게 리팩토링 단계를 명확히 지시: 수정 전후를 구분하여 리팩토링을 수행하도록 설정.
- 편집할 코드 범위를 명확히 정의: 불필요한 수정 방지.
🏆 사례
AI에게 import 오류 수정 요청 시 람다 함수에 불필요한 타입 주석이 추가됨. 잘못된 주석이 포함되면서 코드 오류가 발생함.
📌 6. 기타 주요 문제점 요약
| 문제점 | 해결 방범 |
| 🚧 환경 설정 실패 (Mise en Place) | AI가 환경을 설정하도록 사전에 명령 제공 |
| 🛠️ 상태 의존 도구 사용 문제 (Stateless Tools) | 모든 명령을 프로젝트 루트에서 실행 가능하도록 설정 |
| 📜 명세 위반 가능성 (Respect the Spec) | AI가 테스트 삭제, API 변경을 임의로 수행하지 못하도록 제한 |
| 🔄 반복 작업 과다 수행 (Bulldozer Method) | AI가 같은 작업을 반복하지 않도록 명확한 지시 제공 |
| 📜 요구 사항 명확화 필요 (Requirements, not Solutions) | 문제 해결 전에 요구 사항을 구체적으로 작성 |
| 🧐 과학적 디버깅 부족 (Scientific Debugging) | 문제의 원인을 명확히 분석 후 AI에게 수정 요청 |
| 🖊️ 코드 스타일 불일치 (Use Automatic Code Formatting) | 자동 코드 포맷터를 사용해 스타일 통일 |
| 🤹 중요 작업보다 사소한 문제에 집중 (The Tail Wagging the Dog) | AI가 우선순위를 잘못 설정하지 않도록 컨텍스트 제공 |
| 📁 큰 파일 수정 문제 (Keep Files Small) | AI가 다룰 수 있는 크기로 파일을 분할 |
| 🚧 자신의 한계 인식 부족 (Know Your Limits) | AI가 수행할 수 없는 작업을 명확히 정의 |
| 📚 문서 학습 부족 (Read the Docs) | AI가 사용법을 정확히 이해하도록 문서를 제공 |
| 🏗️ 초기 시스템 동작 우선 (Walking Skeleton) | 최소한의 기능이 동작하도록 코드 작성 |
| 🏗️ 코드 중복 문제 (Rule of Three) | 동일 코드가 세 번 복제될 때 리팩토링 수행 |
LLM을 활용한 코딩은 강력한 도구이지만, 여전히 해결해야 할 문제가 많습니다. AI 코딩을 효과적으로 활용하려면 명확한 요구 사항 정의, 환경 설정 자동화, MCP 서버 활용 등의 전략이 필요합니다. 앞으로 AI가 더욱 발전함에 따라 이러한 문제들도 점차 개선될 것으로 기대됩니다. 🚀
https://ezyang.github.io/ai-blindspots/
AI Blindspots
Blindspots in LLMs I’ve noticed while AI coding. Sonnet family emphasis. Maybe I will eventually suggest Cursor rules for these problems.
ezyang.github.io
'인공지능' 카테고리의 다른 글
| [GTC 2025] AI 시대를 위한 새로운 ‘NVIDIA AI Data 플랫폼’ (0) | 2025.03.21 |
|---|---|
| [GTC 2025] 내 책상 위의 AI 슈퍼컴퓨터! 엔비디아 DGX 스파크 & DGX 스테이션 출시 (0) | 2025.03.21 |
| AI 추론 성능을 극대화하는 오픈소스 솔루션, NVIDIA Dynamo (0) | 2025.03.20 |
| GTC 2025: 젠슨 황 키노트 요약 – AI 추론의 새로운 시대 (0) | 2025.03.20 |
| [GTC 2025] NVIDIA의 에이전틱 AI 플랫폼 공개 – 차세대 AI 혁신을 이끄는 핵심 기술 (0) | 2025.03.20 |
