클로드AI 코딩, 점점 이상해지는 이유 4가지

클로드AI 코딩을 쓸수록 코드가 점점 이상해진다면, 당신만의 문제가 아닙니다. AI 코딩 도구를 쓸수록 코드베이스가 무너지는 현상에는 이름이 있는데, 바로 소프트웨어 엔트로피입니다. 왜 이 현상이 발생하는지, 그리고 현업에서 바로 적용할 수 있는 4가지 실패 패턴 해결책을 살펴봅시다.

AI 코딩, 쓸수록 코드가 이상해지는 건 기분 탓이 아닙니다

"코드는 싸다." 생성형AI 코딩 도구가 보편화되면서 개발자들 사이에서 자주 오가는 말입니다. 스펙을 글로 적으면 AI가 코드로 바꿔주고, 문제가 생기면 스펙만 수정해서 LLM을 다시 돌리면 된다는 스펙 주도 개발(Spec-Driven Development)의 흐름이 생기면서 그 말은 더 자주 들립니다.

 

근데 직접 써본 분들은 알 겁니다. 첫 번째 실행은 그럭저럭 나옵니다. 두 번째는 조금 더 안 좋아집니다. 세 번째가 되면 진짜 이상한 코드가 나오기 시작합니다. 결국 코드를 들여다보게 되고, 보고 나면 충격입니다. 코드가 점점 쓰레기가 되고 있었던 겁니다.

 

수치도 이 현실을 뒷받침합니다. Stack Overflow 2026 설문에 따르면 현재 코드의 42%가 AI가 생성하거나 AI 지원으로 작성됩니다. 반면 AI 신뢰도는 2024년 40%에서 2026년 29%로 하락했습니다. SonarSource 2026 분석에서는 AI 코딩 도구 도입 후 PR당 인시던트가 23.5% 증가하고, AI를 많이 활용한 프로젝트에서 작성 후 2주 내 수정되거나 롤백되는 코드 비율이 39% 늘어났습니다.

 

왜 이렇게 될까요. AI의 근본적인 작동 방식에 답이 있습니다. AI는 눈앞의 변경에만 집중합니다. "이 함수 고쳐줘"라고 하면 그 함수만 봅니다. 주변 모듈이 어떻게 짜여 있는지, 전체 시스템 디자인은 어떤 방향을 가지고 있는지는 관심 밖입니다. 한 번이면 괜찮습니다. 100번, 1000번 맡기면 그때 진짜 못 알아볼 코드가 됩니다.

소프트웨어 엔트로피란 무엇인가

엔트로피는 물리학에서 온 개념입니다. 모든 것이 점점 흩어지고 무너진다는 뜻입니다. 코드베이스도 마찬가지입니다. 코드에 변경을 가할 때 전체 시스템 디자인을 무시하고 부분만 수정하면, 시간이 갈수록 코드 구조가 무너집니다. 이를 소프트웨어 엔트로피, 또는 "software rot(소프트웨어 부패)"라고 부릅니다.

 

이 개념을 처음 도입한 건 1974년 Manny Lehman입니다. 소프트웨어 진화 법칙에서 그는 이렇게 말했습니다. 복잡한 소프트웨어 시스템은 지속적인 수정이 필요한데, 엔트로피를 줄이기 위한 특별한 작업 없이는 수정이 거듭될수록 시스템의 엔트로피가 증가한다고요. 반세기 전 이야기지만, 지금 AI 코딩 시대에 정확히 들어맞습니다.

 

좋은 코드베이스와 나쁜 코드베이스의 차이는 단순합니다. 좋은 코드베이스는 바꾸기 쉬운 코드베이스고, 나쁜 코드베이스는 바꾸기 어려운 코드베이스입니다. AI를 쓰면 이 차이가 더 극명하게 드러납니다. 좋은 코드베이스에서는 AI가 진짜 잘 동작합니다. 나쁜 코드베이스에서는 AI가 코드를 더 망가뜨립니다.

 

아래 예시가 그 과정을 잘 보여줍니다.

// 소프트웨어 엔트로피 누적 시나리오

// 1차 LLM 실행: 깔끔한 코드
function processOrder(order) {
  validateOrder(order);
  chargePayment(order);
  sendConfirmation(order);
}

// 5차 LLM 실행 후: 엔트로피 누적
function processOrder(order) {
  // TODO: 임시 패치 (3차에서 추가됨)
  if (order.type === 'special') {
    return handleSpecialOrder(order); // 별도 함수로 분기
  }
  // HACK: 2차에서 깨진 부분 우회
  const tempFix = order.items?.filter(i => i) ?? [];
  if (tempFix.length === 0) return null;
  validateOrder(order);
  chargePayment(order);
  sendConfirmation(order);
  // 4차에서 추가: 포인트 적립 (왜 여기 있는지 모름)
  if (order.userId) addPoints(order.userId, tempFix.length);
}

실행할 때마다 조금씩 다른 방식으로 코드가 추가됩니다. 처음 설계한 흐름은 어디 갔는지 모르게 됩니다. 이게 반복되면 누가 봐도 이해하기 어려운 코드가 됩니다. 물론 AI도 마찬가지입니다.

4가지 실패 패턴과 해결법

AI 코딩 실패 패턴에는 공통된 구조가 있습니다. 증상은 달라 보여도 원인은 대부분 하나로 수렴합니다. AI에게 필요한 컨텍스트를 충분히 주지 않은 것입니다. 패턴별로 하나씩 살펴보겠습니다.

패턴 1. AI가 내 머릿속 그림과 완전히 다른 걸 만든다

클로드AI 코딩을 써보신 분들이라면 한 번쯤 겪었을 겁니다. 분명히 머릿속엔 설계도가 있는데, AI가 만들어온 결과물은 방향이 완전히 다릅니다. 더 자세히 설명해도, 더 길게 적어도 소용없습니다.

 

문제는 소통이 아니라 공유된 디자인 컨셉의 부재입니다. 여러 사람이 함께 무언가를 설계할 때, 머릿속에 떠다니는 비가시적인 아이디어가 있습니다. 이건 마크다운 파일에 그대로 옮길 수 있는 게 아닙니다. 보이지 않는 공유된 이론 같은 겁니다. 개발자와 AI 사이에 이 공유가 없으면, 아무리 설명을 잘해도 결과물이 어긋납니다.

 

해결책은 코딩 전에 공유된 디자인 컨셉 문서를 만드는 것입니다. Thoughtworks의 스펙 주도 개발(SDD) 연구에 따르면, 인간이 정제한 스펙은 LLM이 생성하는 코드 오류를 50% 감소시킵니다. 그리고 AI에게 충분히 질문하게 하세요. 작업 지시를 주기 전에 AI 스스로 아키텍처와 설계 원칙을 명시하게 만드는 것이 핵심입니다.

# design-concept.md (공유된 디자인 컨셉 문서 예시)

## 핵심 설계 원칙
- 모든 API 응답은 { success, data, error } 구조로 통일
- 에러 처리는 중앙 ErrorHandler에 위임
- 컴포넌트는 단일 책임 원칙 준수

## 현재 아키텍처
- /api → Controller → Service → Repository
- Controller: 입력 검증만 담당
- Service: 비즈니스 로직 전담
- Repository: 데이터 접근만 담당

## 이 문서를 먼저 읽고 작업을 시작할 것

이 문서가 있으면 AI는 함수를 만들 때마다 이 원칙을 기준으로 작동합니다. 없으면 AI 나름의 판단으로 매번 다른 패턴을 씁니다.

패턴 2. AI가 같은 말을 다른 단어로, 너무 장황하게 한다 (DDD)

반도체 회사 개발자가 칩 도메인 전문가와 협업하는 상황을 떠올려 보세요. 전문가는 당연하게 "칩"이라고 하는데, 개발자는 "반도체 소자", "IC 회로", "마이크로칩"을 번갈아 씁니다. 대화가 계속 어긋납니다. AI와의 협업도 정확히 이 상황입니다.

 

DEV Community의 분석에 따르면, AI 에이전트는 명확한 도메인 지식, 일관된 용어, 명시적 경계가 필요한 신입 팀원과 같습니다. "client"라는 단어가 컨텍스트마다 다른 의미를 가지면 AI는 혼란스러워하고, 그 혼란이 코드에 그대로 드러납니다.

 

도메인 주도 설계(DDD)가 여기에 답을 줍니다. 개발자끼리, 도메인 전문가와, 코드 안에서, AI와 협업할 때 모두 같은 도메인 모델에서 나온 단어를 쓰자는 개념입니다. 도메인 언어 사전을 만들어 두고 코드도 DDD 기반으로 짠 뒤에 AI에게 작업을 지시하면, AI의 사고방식 자체가 바뀝니다. 훨씬 덜 장황하게, 더 정확하게 코드를 만듭니다.

# domain-glossary.md (도메인 언어 사전 예시)

## 핵심 용어 정의
- Order: 고객이 결제 완료한 주문 (pending 상태는 Order가 아님)
- Cart: 결제 전 임시 선택 목록
- Fulfillment: 주문 처리 및 배송 준비 프로세스
- SKU: 재고 관리 단위 (Stock Keeping Unit)

## 사용 규칙
- 코드, 변수명, 주석 전반에서 반드시 위 용어 사용
- "order"와 "cart"를 혼용 금지
- AI에게 작업 지시 시 이 사전을 컨텍스트로 첨부

이 파일 하나가 AI와의 소통 정확도를 크게 끌어올립니다. 특히 여러 개발자가 함께 AI 코딩 도구를 쓰는 팀이라면 필수입니다. 같은 팀인데 AI가 사람마다 다른 코드 스타일을 만들어주는 상황을 막아줍니다.

패턴 3. AI가 만든 코드가 작동하지 않는다 (TDD)

AI가 원하는 걸 만들었다고 하는데 실제로 동작하지 않는 경우입니다. 이건 AI의 피드백 루프 문제입니다. AI는 한 번에 너무 많은 것을 해버리는 경향이 있습니다. 거대한 코드를 먼저 짜놓고 테스트는 나중에 돌립니다. 이러면 뭔가 하나 잘못됐을 때 어디가 문제인지 찾기가 너무 어렵습니다.

 

테스트 주도 개발(TDD)은 이 문제를 구조적으로 해결합니다. 테스트를 먼저 작성하고, 그 테스트를 통과하는 최소한의 코드를 작성하고, 그 다음에 코드를 정리하는 Red-Green-Refactor 사이클입니다. 이렇게 하면 AI도 어쩔 수 없이 작은 단위로 차근차근 일하게 됩니다. 조금 만들고 검증하고, 다시 조금 만들고 검증하는 방식입니다. 결과적으로 훨씬 빠릅니다. 중간에 큰 실수가 없으니까요.

 

Google Cloud에서 발간한 DORA 보고서에 따르면, TDD를 도입한 팀은 결함 밀도가 40~90% 감소했습니다. TDD의 가장 큰 강점은 AI로 테스트 코드 자체를 생성할 수 있다는 점입니다. AI에게 구체적인 테스트 스위트를 먼저 제공하면, AI가 자가 수정(self-correct)하면서 정밀하게 구현합니다.

// TDD 방식으로 Claude Code와 작업하는 예시

// 1단계 (Red): 테스트 먼저 작성
test('calculateDiscount: 10만원 이상 주문은 10% 할인', () => {
  expect(calculateDiscount(100000)).toBe(10000);
  expect(calculateDiscount(99999)).toBe(0);
  expect(calculateDiscount(150000)).toBe(15000);
});

// Claude에게: "위 테스트를 통과하는 calculateDiscount 함수를 작성해줘"

// 2단계 (Green): AI가 생성한 코드
function calculateDiscount(amount) {
  return amount >= 100000 ? Math.floor(amount * 0.1) : 0;
}

// 3단계 (Refactor): 필요 시 리팩토링
// 상수 추출 등으로 가독성 향상

물론 TDD 자체도 어렵습니다. 유닛을 얼마나 크게 잡을지, 무엇을 모킹할지, 어떤 동작을 테스트할지. 이 결정들이 서로 얽혀 있습니다. 유닛이 크면 테스트가 불안정해지고, 유닛이 작으면 모킹할 게 많아집니다. 처음에는 익숙해지는 데 시간이 걸립니다. 하지만 TDD에 익숙해진 코드베이스는 그 자체로 좋은 코드베이스입니다. 좋은 코드베이스가 좋은 피드백을 주고, 좋은 피드백이 좋은 AI 결과를 만듭니다.

패턴 4. AI가 코드 패턴을 뒤죽박죽으로 만든다

기능은 추가됐는데 다른 기능이 갑자기 동작을 안 하는 경험, 있으신가요. AI 코드 품질 저하 중에서 가장 눈에 안 띄다가 나중에 터지는 유형입니다. 코드베이스에 규칙성이 없을 때 발생합니다.

 

규칙성 없는 코드베이스에서는 AI도 개발자도 모든 정보를 머릿속에 다 담아야 합니다. 이 함수가 저 함수를 부르고, 저 함수는 또 다른 곳을 부르고, 이걸 다 추적하다가 컨텍스트가 초과됩니다. arXiv 2026 연구에 따르면 AI 도입 기술 부채(self-admitted technical debt)는 2025년 초 수백 건에서 2026년 2월 기준 110,000건 이상으로 폭증했습니다. 6,275개 GitHub 저장소, 30만 건 이상의 AI 작성 커밋을 분석한 결과입니다.

// 규칙성 없는 코드 (나쁜 예)
async function getUser(id) { ... }         // async/await 방식
function fetchProduct(id, callback) { ... } // 콜백 방식
const loadOrder = (id) => new Promise(...) // Promise 방식
// AI가 어느 패턴을 써야 할지 모름 → 매번 다른 패턴으로 생성

// 규칙성 있는 코드 (좋은 예)
async function getUser(id) { ... }
async function fetchProduct(id) { ... }
async function loadOrder(id) { ... }
// AI가 일관된 패턴으로 코드 생성 가능

METR의 2025년 무작위 대조 실험에서 숙련 오픈소스 개발자들이 AI 코딩 도구를 사용했을 때 오히려 19% 느려진 결과가 나왔습니다. 개발자들은 자신이 20% 빨라졌다고 느꼈지만 실측은 반대였습니다. 불규칙한 코드베이스를 관리하는 비용이 그만큼 크다는 의미입니다. 코드 작성이 끝나면 반드시 코드 가이드 준수 여부를 확인하고 규칙성을 유지하는 루틴이 필요합니다.

지금 바로 적용할 수 있는 4단계 실전 가이드

위 4가지 패턴을 한 번에 해결하려면 막막합니다. 메이커 에반(Maker Evan) 채널의 실전 적용 가이드를 바탕으로, 지금 당장 시작할 수 있는 순서를 정리했습니다.

 

1. 현재 프로젝트 분석: AI에게 코드베이스 특징을 끈질기게 물어보세요. "이 코드베이스의 아키텍처 패턴은 무엇인가", "일관성이 없는 부분이 있다면 어디인가"처럼 구체적인 질문을 던져서 현재 상태를 파악하는 것부터 시작합니다.
2. 도메인 사전 만들기: 프로젝트의 핵심 용어를 마크다운 파일로 정리하세요. 이게 DDD의 시작이고 가장 쉬운 첫걸음입니다. 파일 하나가 AI와의 소통 방식 전체를 바꿉니다.
3. 다음 기능에 TDD 한 번 시도: 테스트 먼저 작성하고, 통과시키고, 정리하는 사이클을 딱 한 기능에만 적용해 보세요. 한 번만 해보면 감이 옵니다. 특히 AI와 함께하면 테스트 코드 작성 자체도 AI한테 맡길 수 있어서 생각보다 빠릅니다.
4. 코드 규칙 검토 루틴 만들기: 개발이 완료되면 코드 가이드 준수 여부를 확인하는 루틴을 만드세요. AI에게 "이 코드가 우리 코드 가이드를 잘 따르고 있는지 확인해줘"라고 주기적으로 검토하게 하면 규칙성을 지속적으로 유지할 수 있습니다.

CodeRabbit 분석에 따르면 AI 공동 작성 코드는 사람이 작성한 코드 대비 보안 취약점이 약 2.74배 높습니다. 이 4단계 방법론들은 그 격차를 줄이는 데 직접적으로 기여합니다. AI를 제대로 활용하는 팀과 그렇지 않은 팀의 코드 품질 차이는 이미 벌어지고 있습니다.

AI는 훌륭한 병사, 전략은 개발자의 몫

AI를 현장에서 일하는 훌륭한 병사로 생각해 보면 어떨까요. 전술적인 일, 그러니까 줄 단위 코딩은 우리보다 빠를 수 있습니다. 근데 그 위에서 전략적으로 생각하는 사람이 여전히 필요합니다. 큰 그림을 보고 설계를 결정하고 방향을 잡는 일은 개발자의 몫입니다.

 

4가지 원칙을 간결하게 정리하면 이렇습니다. AI와 디자인 컨셉을 공유할 것. 도메인 주도 설계(DDD)로 같은 언어를 쓸 것. 테스트 주도 개발(TDD)로 작은 단위로 일할 것. 그리고 테스트하기 좋은 코드베이스를 만들 것. 이 네 가지는 AI 코딩 이전에도 좋은 개발 원칙이었고, AI 코딩 시대에는 더 중요해졌습니다.

 

나쁜 코드는 그 어느 때보다 비싸졌습니다. AI를 써서 더 빨리 나쁜 코드를 만들 수 있게 됐기 때문입니다. 좋은 코드베이스가 좋은 AI를 만들고, 좋은 AI가 또 좋은 코드베이스를 만드는 선순환이 목표입니다. 지금 당장 자신의 프로젝트에서 이 4가지 원칙 중 하나라도 시작해 보면, 몇 주 뒤 코드베이스의 변화를 직접 경험할 수 있을 겁니다.