AI Chat 컴퍼넌트 코드 개선

 

🪁 Before / After

기존 AI Chat 컴포넌트는 UI, 비즈니스 로직, API 호출이 하나의 파일에 집중되어 있어 코드의 복잡도가 높았습니다. 기능이 추가될수록 유지보수 비용이 증가하고, 새로운 기능을 적용하거나 버그를 수정할 때 다른 기능에 영향을 줄 가능성이 존재했습니다.

이번 리팩토링에서는 역할을 명확하게 분리하여 컴포넌트는 화면(View)만 담당하도록 변경하였고, 비즈니스 로직과 API 호출을 각각 독립적인 모듈로 분리했습니다.

• 코드 라인 감소
  • 1534 → 358 Line
  • 총 1,176 Line 감소(약 77%)
• 하나의 컴포넌트가 담당하던 책임을 여러 모듈로 분리하여 가독성과 유지보수성을 향상
• 기능 추가 시 기존 코드를 수정하는 범위를 최소화하도록 구조 개선

---

🎱 AI Chat의 역할

AI Chat은 단순한 채팅 UI가 아니라 사용자의 요청에 따라 다양한 AI 기능을 수행하는 핵심 컴포넌트입니다.

주요 기능은 다음과 같습니다.

• AI 채널 생성
• 음악 큐레이션
• AI CM Song 생성
• 사용자와 AI 간 메시지 관리
• AI 응답 상태 및 진행 과정 관리

여러 기능이 하나의 컴포넌트에 집중되어 있었기 때문에 지속적인 기능 추가 과정에서 코드 복잡도가 증가하는 문제가 있었습니다.

---

🪃 기존 이슈

1. View와 Business Logic의 결합

기존에는 컴포넌트 내부에서

• API 호출
• 응답 데이터 가공
• 상태 관리
• 화면 렌더링

모든 역할을 수행하고 있었습니다.

이로 인해 화면 수정만 필요한 경우에도 비즈니스 로직을 함께 확인해야 했으며, 작은 수정에도 예상치 못한 사이드 이펙트가 발생할 가능성이 있었습니다.

---

2. Message 구조가 일관되지 않음

메시지 타입이 규격화되어 있지 않아

• Message마다 다른 데이터 구조 사용
• 조건문 증가
• 새로운 Message 타입 추가 시 기존 코드 수정 필요

등의 문제가 발생했습니다.

메시지가 많아질수록 코드의 복잡도가 빠르게 증가하는 구조였습니다.

---

3. 문자열 상수 사용

메시지 타입과 이벤트 이름 등이 문자열(String Literal)로 관리되고 있어

"TEXT"
"LOADING"
"SONG"

오타 하나만 발생해도 런타임에서 오류가 발생할 가능성이 있었으며, IDE의 자동완성이나 타입 검증도 활용하기 어려웠습니다.

---

🛠 개선 사항

1. 역할별 디렉토리 분리

기존에는 하나의 컴포넌트에서 대부분의 역할을 담당했지만, 리팩토링 이후에는 각 책임을 독립적인 모듈로 분리했습니다.

src
├── components
│   └── AiChat.vue          // View
├── composables
│   └── useAiChat.js        // Business Logic
├── service/api
│   └── aiChatApi.js        // API
└── shared
    ├── adapter
    │   └── ai-chat.js      // 데이터 변환
    └── factory
        └── ai-chat.js      // Message 생성

이를 통해 View는 화면 렌더링만 담당하고, 비즈니스 로직과 API 호출은 독립적으로 관리할 수 있도록 개선했습니다.

---

2. Business Logic 분리

비즈니스 로직을 useAiChat으로 이동하여

• 테스트 용이성 향상
• View 코드 단순화
• 재사용 가능한 로직 구성

이 가능하도록 개선했습니다.

---

3. API 계층 분리

API 호출을 별도의 Service Layer로 분리하여

• API 변경 시 수정 범위 최소화
• Mock API 적용 용이
• 유지보수성 향상

효과를 얻을 수 있었습니다.

---

4. Adapter & Factory 패턴 적용

메시지 생성과 데이터 변환을 각각 Factory와 Adapter로 분리하여

• Message 생성 로직 일원화
• 데이터 구조 변경에 대한 대응력 향상
• 새로운 Message 타입 추가 시 영향 범위 최소화

할 수 있도록 개선했습니다.

---

5.Strategy Pattern 적용

AI Channel, 시간별 큐레이션, AI CM Song은 동일한 Chat UI를 사용하지만 메시지를 생성하고 전송하는 방식이 서로 달랐습니다.

기존에는 서비스별로 if/else를 통해 전송 로직을 분기했지만, AI 기능이 추가될수록 조건문이 증가하는 문제가 있었습니다.

이를 해결하기 위해 메시지 타입별 Handler를 매핑하는 전략(Strategy) 방식을 적용했습니다.

constsendHandlerMap= {
  [AI_CHAT_TYPES.AI_CHANNEL]:sendDefaultMessage,
  [AI_CHAT_TYPES.TIME_CURATION]:sendDefaultMessage,
  [AI_CHAT_TYPES.AI_CM_SONG]:sendCmSongMessage
};

sendHandlerMap[type]?.();

이 구조를 통해

• 조건문(if, switch) 제거
• 전송 로직을 Handler 단위로 분리
• 새로운 AI 기능은 Handler만 추가하면 되므로 기존 호출부 수정 불필요
• 유지보수성과 확장성 향상

이라는 효과를 얻었습니다.

---

🎯 개선 효과

• 코드 라인 77% 감소 (1534 → 358)
• View / Business Logic / API의 책임 분리
• 메시지 생성 방식 표준화
• 유지보수성과 가독성 향상
• 기능 추가 시 변경 범위 최소화
• 재사용 가능한 구조로 개선
• 확장성과 테스트 용이성 확보