Beyond Functional Correctness: Design Issues in AI IDE-Generated Large-Scale Projects

이 논문은 FD-HITL 프레임워크를 활용해 Cursor 로 생성한 대규모 프로젝트가 기능적 정확도는 높지만, 코드 중복과 복잡성 등 유지보수성을 위협하는 설계 결함을 다수 포함하고 있음을 실증적으로 규명했습니다.

핵심

🤖 AI 가 만든 거대 프로젝트: "일단 작동은 하는데, 집은 엉망이야?"

이 논문은 최신 AI 코딩 도구 (특히 '커서'라는 AI IDE) 가 혼자서 거대한 소프트웨어 프로젝트를 얼마나 잘 만들 수 있는지, 그리고 그 결과물이 어떤 문제점을 가지고 있는지 연구한 내용입니다.

핵심 내용을 집을 짓는 상황에 비유해서 쉽게 설명해 드릴게요.

---

1. 연구의 배경: AI 가 혼자 집을 지어준다면?

과거의 AI 코딩 도구는 "벽돌 하나만 쌓아줘"라고 하면 벽돌을 쌓아주는 도구 수준이었습니다. 하지만 최신 AI(커서 등) 는 "우리 집 한 채를 지어줘"라고 하면 건축가, 시공팀, 감리까지 다 맡아서 전체 프로젝트를 만들어냅니다.

연구진들은 "AI 가 혼자서 아파트 한 동 (거대 프로젝트) 을 지을 수 있을까? 그리고 그 집이 실제로 살 만한 수준일까?"라는 궁금증을 품고 실험을 시작했습니다.

2. 실험 방법: "AI 와 함께하는 체계적인 건축 계획"

AI 에게 "집 좀 지어줘"라고 막연히 말하면 AI 는 엉뚱한 것을 만들거나 중간에 멈춥니다. 그래서 연구진들은 **FD-HITL(기능 중심 인간-루프)**이라는 체계적인 건축 계획서를 만들었습니다.

• 비유: AI 를 무작정 시키는 게 아니라, 인간 건축주가 "먼저 기초를 다지고, 그다음 1 층을 짓고, 그다음 2 층을 짓자"라고 단계별로 지시하고, AI 가 각 단계마다 "이게 맞나요?"라고 물어보면 인간이 확인하고 수정하는 방식입니다.
• 결과: 이 방법으로 AI 는 10 개의 거대한 프로젝트 (모바일 앱, 웹사이트, 유틸리티 등) 를 성공적으로 만들었습니다. 코드 양만 해도 평균 1 만 7 천 줄이 넘었고, 파일도 100 개 이상이었습니다.

3. 핵심 발견 1: "일단 작동은 한다!" (기능적 정확성)

연구진이 직접 AI 가 만든 프로그램을 돌려보니, 약 91% 는 의도대로 작동했습니다.

• 비유: AI 가 지은 집은 문도 잘 열리고, 수도도 잘 나오고, 침실도 있습니다. 사람이 살 수 있는 수준으로 '일단 완성'된 것입니다.

4. 핵심 발견 2: "하지만 집은 엉망진창이다!" (디자인 문제)

하지만 기능만 작동한다고 해서 좋은 집은 아닙니다. 전문가 (정적 분석 도구) 가 집을 자세히 검사하니 치명적인 문제점들이 쏟아져 나왔습니다.

• 문제 1: 중복된 공사 (코드 중복)

  • 상황: 거실 벽을 칠할 때, 주방 벽을 칠할 때, 화장실 벽을 칠할 때 똑같은 공법과 자재를 3 번이나 따로따로 사용했습니다.
  • 문제: 나중에 벽을 고쳐야 하면 3 군데를 다 고쳐야 해서 수리비가 비싸지고 관리가 어렵습니다. (DRY 원칙 위반)

• 문제 2: 너무 복잡한 방 (코드 복잡도)

  • 상황: 한 방 안에 벽장, 주방, 욕실, 서재 기능이 모두 섞여 있습니다. 문이 11 개나 있어서 어디로 나가야 할지 헷갈립니다.
  • 문제: 나중에 방을 개조하려면 전체를 부수고 다시 지어야 할 정도로 복잡합니다. (단일 책임 원칙 위반)

• 문제 3: 안전 장치 부재 (예외 처리)

  • 상황: 지진이 나거나 화재가 났을 때 대피할 비상구 표시가 없거나, 비상벨이 고장 나면 아무것도 안 됩니다.
  • 문제: 작은 오류가 발생하면 전체 시스템이 멈춰버릴 위험이 큽니다.

• 문제 4: 장애인 접근성 무시

  • 상황: 휠체어를 탄 사람이 들어갈 수 있는 경사로가 없거나, 시각 장애인을 위한 점자 표시가 없습니다.
  • 문제: 모든 사람이 편안하게 쓸 수 있는 집이 아닙니다.

5. 결론: AI 는 훌륭한 '시공 팀'이지만, '건축주'는 여전히 인간이다

이 연구는 다음과 같은 결론을 내립니다.

1. AI 는 강력하다: 체계적인 지시 (FD-HITL) 를 받으면 AI 는 거대한 프로젝트를 빠르게 만들 수 있습니다.
2. 하지만 품질은 낮다: AI 가 만든 코드는 기능은 작동하지만, 유지보수가 어렵고, 구조가 엉망인 경우가 많습니다.
3. 인간의 역할: AI 는 '일꾼'일 뿐, '건축주'나 '감리자'는 여전히 유능한 인간 개발자여야 합니다. AI 가 만든 코드를 그대로 쓰면 나중에 큰 낭패를 볼 수 있습니다.

💡 일반인을 위한 교훈

"AI 가 다 해준다"라고 믿고 아무 생각 없이 코드를 받아쓰면 안 됩니다. AI 는 빠르고 많은 일을 해주는 훌륭한 비서이지만, 설계도 (아키텍처) 를 검토하고, 안전 장치를 점검하며, 깔끔하게 정리하는 일은 여전히 사람의 손이 필요합니다.

**"AI 가 지은 집은 일단 들어갈 수 있지만, 나중에 수리할 때 고생하지 않으려면 인간 건축주가 꼼꼼히 감리해야 한다"**는 것이 이 논문의 핵심 메시지입니다.

기술 요약

1. 연구 배경 및 문제 제기 (Problem)

• 배경: 최근 LLM 기반 코딩 도구 (GitHub Copilot 등) 는 코드 스니펫 생성에 탁월하지만, 프로젝트 전체를 컨텍스트 내에서 생성하는 능력은 제한적이었습니다. 반면, Cursor 와 같은 AI 에이전트 기능을 갖춘 차세대 AI IDE 는 프로젝트 컨텍스트를 이해하고 대규모 코드를 생성할 수 있는 잠재력을 보입니다.
• 문제: 기존 연구는 주로 단순한 코드 스니펫이나 소규모 프로젝트의 품질을 평가했습니다. AI IDE 가 **대규모 프로젝트 (Large-scale projects)**를 생성할 수 있는지, 그리고 생성된 시스템이 장기적인 유지보수와 진화에 치명적인 **설계 결함 (Design Issues)**을 포함하고 있는지에 대한 실증적 증거는 부족했습니다.
• 연구 목표: Cursor 를 사용하여 대규모 프로젝트를 생성할 수 있는지 확인하고 (RQ1), 생성된 프로젝트에서 발견되는 설계 문제의 유형과 심각성을 분석하는 것 (RQ2) 입니다.

2. 연구 방법론 (Methodology)

연구는 10 개의 대규모 프로젝트를 생성하고 이를 정적 분석 도구로 평가하는 2 단계 프로세스로 진행되었습니다.

2.1 Feature-Driven Human-In-The-Loop (FD-HITL) 프레임워크

단순한 프롬프트 (Ad hoc prompting) 나 'Vibe Coding' 방식의 비체계적 접근은 대규모 프로젝트 생성에 실패한다는 초기 피드백을 바탕으로, 저자들은 FD-HITL 프레임워크를 제안하고 적용했습니다.

• 프로젝트 초기화: 비즈니스 도메인 정의 및 기술 스택 (Tech Stack) 선정.
• 요구사항 및 설계: requirements.md (시스템 요구사항) 와 tasklist.md (기능별 점진적 개발 로드맵) 생성.
• 점진적 구현: 백엔드/데이터베이스 → 프론트엔드 순서로 기능별 (Feature-wise) 로 반복적으로 구현. 각 기능마다 블랙박스 테스트와 디버깅을 수행.
• 전체 시스템 검토: 모든 기능 구현 후 통합 테스트 및 UI/UX 일관성 확인.

2.2 데이터 생성 및 평가

• 프로젝트 생성: FD-HITL 프레임워크를 사용하여 10 개의 대규모 프로젝트 (Web, Mobile, Utility 도메인) 를 Cursor Pro 로 생성.
  • 기술 스택: React, Spring Boot, Django, React Native, PHP 등 다양한 스택 사용.
  • 규모 기준: 최소 8,000 줄의 코드 (LoC) 이상, 3 개 이상의 기술 스택, 복잡한 아키텍처.
• 기능적 정확성 평가: 수동 평가를 통해 생성된 프로젝트가 요구사항을 충족하는지 확인.
• 설계 품질 평가: 두 가지 정적 분석 도구를 사용하여 설계 결함을 탐지.
  • CodeScene: 고수준 설계 문제 (복잡도, 중복 등) 탐지.
  • SonarQube: 저수준 코드 스멜 및 설계 원칙 위반 탐지 (1,612 개의 오탐지 제거 후 분석).

3. 주요 기여 (Key Contributions)

1. FD-HITL 프레임워크 제안: AI IDE 를 사용하여 대규모 프로젝트를 체계적으로 생성하기 위한 인간 - AI 협업 프로세스를 정립.
2. 대규모 프로젝트 생성 실증 연구: Cursor 를 사용하여 10 개의 산업 수준 프로젝트 (평균 16,965 LoC, 114 개 파일) 를 성공적으로 생성하고 분석한 데이터셋 제공.
3. 설계 문제의 체계적 분류: 정적 분석 도구를 통해 발견된 4,000 개 이상의 설계 문제를 20 개 이상의 카테고리로 분류하고, 이를 설계 원칙 (SRP, DRY, KISS 등) 위반과 연결하여 분석.
4. 공개 데이터셋 (DIinAGP): 10 개의 프로젝트 설명, 생성된 소스 코드, 식별된 설계 문제 등을 포함한 데이터셋을 공개.

4. 연구 결과 (Results)

4.1 RQ1: Cursor 의 대규모 프로젝트 생성 능력

• 생성 가능성: FD-HITL 프레임워크를 사용할 경우, Cursor 는 평균 **16,965 줄의 코드 (LoC)**와 114 개 파일로 구성된 기능적으로 작동하는 대규모 프로젝트를 생성할 수 있음.
• 기능적 정확성: 생성된 10 개 프로젝트의 평균 기능적 정확도는 **91%**로 높았음. (최고 96%, 최저 85%).
• 한계: 기능은 작동하지만, 일부 요구사항 누락이나 논리적 오류가 존재하며, 이는 인간의 개입 (리뷰 및 수정) 이 필요함을 시사.

4.2 RQ2: 설계 문제 (Design Issues) 분석

생성된 프로젝트는 기능적 정확도는 높으나 심각한 설계 결함을 다수 포함하고 있음.

• CodeScene 분석 결과 (1,305 개 문제, 9 개 카테고리):

  • 코드 중복 (Code Duplication, 28.4%): 가장 빈번한 문제. DRY 원칙 위반.
  • 복잡한 메서드 (Complex Method, 27.9%) & 대형 메서드 (Large Method, 12.6%): SRP (단일 책임 원칙) 위반.
  • 전체 코드 복잡도 (Overall Code Complexity): SoC (관심사 분리) 원칙 위반.
  • 기타: 복잡한 조건문, 과도한 함수 인자, 깊은 중첩 등.

• SonarQube 분석 결과 (3,193 개 문제, 11 개 카테고리):

  • 프레임워크 모범 사례 위반 (35.3%): React Props 검증 누락, Spring Boot 주입 방식 오류 등.
  • 사망/중복/불필요한 코드 (12.4%): 사용되지 않는 변수, 중복된 CSS 선택자 등.
  • 예외 처리 문제 (10.4%): 너무 일반적인 예외 (Generic Exception) 포착, 빈 catch 블록 등.
  • 접근성 문제 (6.1%): 스크린 리더 지원 부재, 키보드 네비게이션 불가 등.
  • 기술별 특성: JavaScript/React/Node.js 관련 문제가 전체 기술별 문제의 64% 를 차지.

• 설계 원칙 위반: 발견된 문제들은 DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), KISS (Keep It Simple, Stupid), SoC (Separation of Concerns) 등 핵심 설계 원칙을 위반하고 있음.

• 중복 문제: CodeScene 과 SonarQube 모두에서 발견된 중첩 문제는 133 개로 적었으나, 이 중 대부분은 코드 복잡도 (Code Complexity) 관련이며 SonarQube 에서 'Critical' 등급으로 분류됨.

5. 의의 및 시사점 (Significance & Implications)

• AI IDE 의 현재 위치: AI IDE 는 프로토타이핑이나 초기 개발 속도를 높이는 데 탁월하지만, **산업 수준의 유지보수 가능성 (Maintainability) 과 진화 가능성 (Evolvability)**을 보장하기 위해서는 여전히 숙련된 개발자의 심층적인 코드 리뷰와 설계 감독이 필수적입니다.
• 개발자의 역할 변화: 개발자는 단순한 코딩 작업을 AI 에게 위임하기보다, **요구사항 정의, 아키텍처 설계, 기능 분해 (Decomposition)**와 같은 고수준 작업에 집중해야 합니다. (Human-in-the-loop 전략의 중요성 강조).
• 실무자 권고:
  • 기능적 정확성뿐만 아니라 설계 품질 지표 (복잡도, 중복도 등) 를 지속적으로 모니터링해야 함.
  • 접근성 요구사항을 명시적으로 정의하고 자동화 도구를 활용해야 함.
  • 백엔드/데이터베이스 구현을 먼저 완료하고 검증한 후 프론트엔드를 통합하는 방식이 효과적임.
• 연구자 권고: 정적 분석 도구만으로는 아키텍처 수준의 문제를 놓칠 수 있으므로, LLM 기반의 설계 분석 도구 개발 및 다양한 AI IDE 에 대한 비교 연구가 필요함.

결론

이 연구는 AI IDE 가 대규모 소프트웨어를 생성할 수 있는 기술적 능력을 입증했지만, 동시에 기능이 작동한다고 해서 설계가 양호하다는 것을 의미하지는 않는다는 중요한 사실을 밝혔습니다. 생성된 코드는 코드 중복, 높은 복잡도, 설계 원칙 위반 등 장기적인 유지보수 리스크를 내포하고 있으므로, AI 를 활용한 개발 과정에서도 인간의 설계 판단과 엄격한 품질 관리가 절대적으로 필요함을 강조합니다.