당신은 AI 주도 개발을 받아들일 수 있나요? (AIDD)

LTT·2025년 11월 27일

AI CS 학습노트

개발 환경은 지금, 그 어느 때보다 빠르게 변화하고 있습니다. GitHub Copilot, Cursor, Claude Code, Windsurf…

AI 코딩 도구의 춘추전국시대가 도래한 것이죠.

이제 개발자에게 중요한 질문은 더 이상

“AI 코딩 도구를 쓰면 기본 지식이 뒤쳐지지 않을까?”

가 아니라,

“AI를 어떻게 하면 팀과 개발 프로세스에 맞게 잘 활용할 것인가?”

로 바뀌고 있습니다.

과거에는 AI 코딩 도구를 사용할 것인지 말 것인지가 논쟁거리였습니다. 하지만 2025년의 개발 환경에서 그 질문은 이미 시대에 뒤처졌습니다.

이제 핵심은

“AI를 얼마나 잘 활용해 더 나은 개발 사이클을 만드는가?”

그리고 이 질문은 단순 자동완성 다음의, 새로운 개발 패러다임으로 확장되고 있습니다. 그것이 바로 AI-Driven Development(AIDD)입니다.

AI가 마구마구 뱉어내는 "스파게티 코드"

AI 코딩 툴이 마냥 좋기만 할까요? 2024년 발표된 GitClear의 리포트는 꽤 충격적인 데이터를 보여줬었는데요.

"AI 도입 후 코드 이동은 늘었고, 코드 재사용률은 오히려 줄었다."

AI가 코드를 너무 쉽게 짜주다 보니, 기존 코드를 재사용하기보다 "복사/붙여넣기"하는 경향이 강해졌다는 것입니다. 이는 장기적으로 유지보수가 불가능한 '기술 부채(Technical Debt)'를 가속화합니다.

과거: 고민해서 10줄 작성
현재: AI가 1초 만에 100줄 생성 -> 검증 없이 Commit -> 레거시 폭탄

우리는 “AI가 짠 코드를 믿지 않는 것"에서부터 AIDD를 시작해야 합니다. 물론 AI는 점점 발전하며 신뢰성 있는 코드를 짜 나아갈테지만 말이죠.

단순 자동완성의 시대의 끝, AIDD란?

이제 막 Copilot v1이 다음 변수명이나 함수 시그니처를 추천해주던 시대는 끝났습니다. 단순한 '코드 스니펫 생성(Code Snippet Generation)'은 더 이상 AIDD라고 부르지 않습니다.

그렇다면 진정한 AIDD는 무엇일까요?

AI를 개발 프로세스 전반을 주도하는 '사고 파트너(Thought Partner)'로 활용하는 개발 방법론의 총체를 의미합니다.

AIDD가 기존 자동완성과 다른 결정적인 차이점

구분	단순 자동완성 (2022년 이전)	AIDD (AI Driven Development)
인식 범위	현재 파일, 최근 몇 줄의 코드	전체 코드베이스 (프로젝트 구조, 컨벤션, 의존성)
수행 임무	다음 단어/줄 예측, 단순 함수 생성	아키텍처 변경, 모듈 간 버그 수정, 테스트 코드 작성
개발자 역할	타이핑 속도를 높여주는 보조자	복잡한 문제 해결을 함께 논의하는 사고 파트너

AIDD의 두 가지 핵심

AIDD는 개발자에게 두 가지 근본적인 변화를 요구합니다.

1. RAG(Retrieval-Augmented Generation) 기반의 '맥락 이해'

Cursor와 같은 최신 도구들은 RAG 기술을 이용해 단순히 다음 코드를 예측하는 것을 넘어, 프로젝트 전체 파일의 구조와 팀 컨벤션을 인덱싱합니다.

이로 인해 AI는 "여기에 getUserInfo를 넣으면 되겠네"가 아니라, "이 로직은 우리 팀의 Redux 아키텍처에서 Store와 Action을 어떻게 변경해야 할지"까지 이해하고 제안할 수 있게 됩니다. 이는 곧 '코딩'의 영역에서 '설계 및 리팩토링'의 영역으로 AI의 역할이 확장되었음을 의미합니다.

2. 'AI 코드'의 신뢰성 확보를 위한 방법론 통합

AI는 빠르게 코드를 짜지만, 그 코드가 항상 정확하고 견고하지는 않습니다. 바로 앞서 언급했던 GitClear 리포트의 경고가 여기에 해당됩니다.

따라서 AIDD는 'AI는 구현 도구, TDD는 검증 도구'라는 명제를 핵심으로 삼습니다. AI에게 "테스트 통과 코드"를 요청하고, 개발자는 "테스트 코드가 비즈니스 요구사항을 정확히 반영하는지"를 검토하는 방식으로 역할이 재정의됩니다.

AIDD는 곧 AI를 비판적으로 활용하여 개발 방법론(TDD, Test-Driven Development)에 녹여내는 과정이라고 할 수 있겠습니다.

AI-Driven Development라고 했는데 TDD가 왜 튀어나오나요?

AIDD(AI Driven Development)의 핵심은 궁극적으로 '신뢰할 수 있는 소프트웨어'를 빠르고 효율적으로 만드는 것입니다. 하지만 AI가 코드를 짜는 과정에서 근본적인 한계점이 발생하고, 이 지점에서 TDD(Test-Driven Development, 테스트 주도 개발)는 단순한 개발 방법론을 넘어 AIDD의 안전망이자 핵심 방법론이 됩니다.

1. AI 코드의 본질적인 한계: 불확실성과 환각 (Hallucination)

LLM(Large Language Models) 기반의 AI 코딩 도구는 '가장 확률 높은 다음 토큰'을 예측하여 코드를 생성합니다. 이 과정에서 발생하는 AI 코드의 가장 큰 위험 요소는 다음과 같습니다.

불확실성 (Non-Deterministic): 같은 프롬프트에도 다른 코드가 나옵니다.
환각 (Hallucination): 존재하지 않는 API나 라이브러리를 사용하거나, 현재 프로젝트 맥락과 맞지 않는 잘못된 로직을 자신 있게 제시합니다.
오버 엔지니어링 (Over-Engineering): 요구 사항보다 훨씬 복잡하거나 불필요한 코드를 생성하여 기술 부채를 유발합니다. (앞서 언급된 [GitClear Report]의 핵심 경고입니다.)

즉, AI는 '빠른 코드 작성'이라는 생산성은 제공하지만, '코드의 정확성과 안정성'이라는 품질은 보장하지 못합니다.

2. TDD: AI 코드를 '신뢰할 수 있는 코드'로 만드는 검증 안전 장치

TDD는 코드를 짜기 전에 테스트 코드를 먼저 작성하는 개발 방식입니다. AIDD에 TDD가 결합되어야 하는 이유는 AI의 불안정성을 완벽하게 상쇄시키기 때문입니다.

A. AI에 대한 명확한 지시서 역할

AIDD에서 테스트 코드는 단순한 검증 도구가 아닌, AI에게 던지는 가장 명확하고 구체적인 요구사항 정의서가 됩니다.

일반 프롬프트: "회원가입 기능을 만들어줘." (AI에게 넓은 자유도)
TDD 기반 프롬프트: (테스트 코드를 제시하며) "이 테스트 케이스를 통과하는 UserService.register 함수를 구현해줘." (AI에게 명확한 목표 제시)

이는 AI가 요구사항을 잘못 해석하거나 불필요한 코드를 넣는 환각의 위험을 최소화합니다.

B. Red-Green-Refactor 사이클의 생산성 극대화

TDD의 "빨간불 - 초록불 - 리팩토링" 사이클이 AI를 만나 혁신적으로 빨라집니다.

🔴 Red (빨간불): 개발자가 실패하는 테스트 코드를 작성합니다. (인간의 설계)
🟢 Green (초록불): AI에게 '이 테스트를 통과하는 구현 코드'를 작성하게 합니다. (AI의 구현 속도 극대화)
Refactor (리팩토링): AI에게 '방금 생성된 구현 코드를 더 깔끔하게 리팩토링하고 SOLID 원칙을 적용해달라'고 요청합니다. (인간의 검토 및 AI의 보조 리팩토링)

이러한 협력 모델은 인간의 사고 능력과 AI의 구현 속도 및 패턴 인식 능력을 결합하여, 단순히 속도만 빠른 개발이 아니라 품질과 속도를 동시에 잡는 개발을 가능하게 합니다.

바이브 코더와 주니어에게 AIDD가 '필수'인 이유 = 시니어처럼 일하기

바이브 코더(Vibe Coder)나 개발 경력이 길지 않은 주니어 개발자에게 AI Driven Development (AIDD)는 단순한 생산성 도구를 넘어 "시니어 개발자처럼 일하는 방법"을 가르쳐주는 핵심적인 성장 수단이 될 수 있다고 생각합니다.

AIDD를 채택해야 하는 구체적인 이유 3가지를 정리했습니다.

시니어 엔지니어의 '사고방식' 학습

주니어 개발자가 가장 어려움을 느끼는 부분은 '어떻게 코드를 짜야 하는가'가 아니라, '왜 이 코드를 이렇게 짜야 하는가'에 대한 의사 결정 과정입니다.

즉각적인 피드백 루프: 바이브 코더는 코드를 짠 후 AI에게 "이 코드가 SOLID 원칙을 따르나요?", "이 함수는 테스트하기 쉽게 리팩토링할 수 있나요?"라고 질문하고 즉시 피드백을 받을 수 있습니다.
패턴 및 컨벤션 내재화: Cursor의 .cursorrules , Claude Code의 CLAUDE.md등을 통해 팀의 컨벤션(명명 규칙, 아키텍처 패턴)을 AI에게 학습시키고, AI가 생성한 코드를 분석함으로써 팀이 중요하게 생각하는 코딩 습관을 빠르게 체화할 수 있습니다. 물론 작성 후 리뷰를 요청해도 가능합니다. AI가 일종의 24시간 대기하는 코드 리뷰어이자 멘토 역할을 하는 것입니다.

불안 해소 및 생산성 가속화

바이브 코더는 새로운 기능을 구현할 때 '어디서부터 시작해야 할지', '혹시나 심각한 버그를 만들지 않을지'에 대한 불안감을 느끼기 쉽습니다.

TDD 기반 개발 습관 획득: AIDD는 TDD를 강제합니다. 코드를 직접 짜기 전에 테스트 코드를 작성하는 경험을 반복하면, 바이브 코더는 구현보다는 기능의 설계에 집중하는 습관을 들이게 됩니다. AI가 빠른 속도로 구현(Green)을 책임지므로, 구현 실패의 부담이 줄어들어 개발 속도가 가속화됩니다.
레거시 코드의 즉각적인 해석: 난해한 레거시 코드를 만나도 AI에게 "이 모듈의 주요 역할과 의존성은 뭐야?"등을 질문하여 코드 문맥을 빠르게 파악할 수 있습니다. 이는 시니어 개발자가 상황을 파악하는 속도, 순서와 유사합니다.

풀스택 개발 역량 확장

현대 개발 환경은 백엔드(Python/Java), 프론트엔드(React/TypeScript), 인프라(YAML/Terraform) 등 다양한 언어와 기술 스택을 요구합니다.

다국어(Polyglot) 코드 생성: 바이브 코더가 주력 언어가 아닌 다른 스택을 다룰 때, AI는 즉시 해당 언어의 Idiomatic Code(관용적인 코드)를 생성해 줍니다. 예를 들어, "TypeScript로 작성된 React 컴포넌트를 Svelte 컴포넌트로 바꿔줘"와 같은 요청을 통해, 문법 오류에 대한 걱정 없이 새로운 기술 스택을 빠르게 탐색하고 적용할 수 있습니다.
시간 절약: 레퍼런스 문서를 뒤지며 사소한 문법이나 설정 파일을 찾는 시간을 절약하고, "문제 해결"이라는 본질적인 작업에 에너지를 집중할 수 있게 됩니다.

결론적으로, AIDD는 주니어에게 시니어의 지식과 경험을 복사하고, 실수의 불안감을 줄이며, 빠른 속도로 다양한 기술 스택을 경험하게 해주는 최고의 개발 방법론이자 교육 환경으로 자리잡고 있습니다.

AI 개발, 피할 수 없다면 더 똑똑하게 사용하자

풀 AI 개발보다는 사람의 손을 많이 탄 개발을 선호하는 사람들은 대개 이유가 명확합니다.

유지보수성이 떨어진다.
구조가 뒤죽박죽이다.

이 외에도 여러가지가 있을 수 있지만 이 두가지가 대표적이기에 언급해봤습니다.

반대로 생각해보면 이 두 가지만 해결할 경우 반대하는 사람의 과반수는 마음을 돌릴 수 있게 될 것 같습니다. 무작정 AI 도입을 통해 후회하기 보다는, AI를 제대로 활용하는 다양한 방법들을 익히시고 사용하는 연습을 해보면 좋을 것 같습니다.

AI Agent 사용이 익숙하지 않은 개발자분들은 우선 익숙한 Github Copilot으로 코드 부분부분 작성하는 것부터 익숙해지고, 다음은 Gemini CLI 로, 필요하다면 Claude Code, Cursor, 이번에 나온 AntiGravity등등 필요 여부에 따른 툴들로 확장시켜 나가면 좋을 것 같습니다.

더 이상 “기본기는 진짜 빵빵한” 개발자는 메리트가 없는 것 같습니다. 기본기는 이제 AI가 훨씬 잘하니까요.

Reference

LTT

개발자에서 엔지니어로, 엔지니어에서 리더로

이전 포스트

프로젝트 파악, 이제 그만두세요.

다음 포스트