LLM으로 몇 달간 코딩한 후, 다시 내 두뇌를 쓰기로 했어요

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

DevOps

대상자

• 중급~고급 개발자, AI 도구 활용자, 인프라 설계자*
• 난이도: 중급 이상 (인프라 도구, 코드 리뷰, 아키텍처 이해 필요)*

핵심 요약

• 고성능 LLM 활용한 인프라 구축의 한계
• 코드 품질 저하, 유지보수성 약화, 중복/불일치 구조 발생
• AI 의존도 높은 개발 방식의 위험성
• 코딩 감각 저하, 복잡한 문제 해결력 약화, 실수 증가
• Go와 Clickhouse 기반의 새로운 인프라 설계 전략
• LLM 활용한 아키텍처 설계 + 자체 코드 리뷰 및 리팩터링 강화

섹션별 세부 요약

###LLM 활용한 인프라 구축의 문제점

• AI 생성 코드의 비일관성
• 동일 기능 파일의 이름/파라미터/구조 불일치 (예: "WebAPIprovider" vs "webApi")
• 중복된 메소드와 설정 파일 접근 방식 불일치
• 개발자 역량 저하 가능성
• AI 의존 시 직접적인 코드 이해 및 문제 해결 능력 약화
• 비개발자 기반의 AI 개발 시 오류 반복, 구조 파악 어려움
• 고성능 LLM의 한계
• 클릭하우스 수억 행 쿼리 처리 실패, 복잡한 설정 요구
• 모델/프롬프트 일관성 결여로 인한 결과 불확실성

###AI 활용의 한계와 방향 전환

• AI 도구의 보조적 활용 전략
• Cursor 등의 툴로 코드 변환/자동 변경 (단순 반복 작업)
• 새로운 기능 기획/코드 초안 작성은 직접 수행 후 AI 검증
• 코드 리뷰 및 리팩터링 강화
• 코드베이스 정돈 미흡 시 데이터 제공 우선
• 코드 리뷰 시간 확보, 중복/혼란 요소 제거
• 인프라/기술 학습 필요성
• Go와 Clickhouse 경험 부족 대응
• 문서/동영상 자료를 통한 자기주도적 학습 강조

###AI 사용의 현실적 고려사항

• AI 도구의 장단점 인식
• LLM은 빠른 프로토타입 작성에 유용 (예: iOS의 간단한 뷰 생성)
• 복잡한 비즈니스 로직/비동기 처리 시 한계 (Swift/ SwiftUI 환경)
• 개발자 역할 재정의
• AI가 제공하는 "방향 제시"에 대한 의존성 경계
• 인터페이스 정의는 직접, 구현은 AI에 위임 (DevOps 영역 적용)
• AI 사용 강제의 위험성
• LLM 사용 실적 집계로 인한 해고 지표 가능성
• AI 의존도 높은 개발 시 실력 퇴화, 생산성 저하 경고

결론

• AI는 보조 도구로, 코드 리뷰, 리팩터링, 유지보수는 개발자 직접 수행
• Go와 Clickhouse 기반의 체계적 인프라 설계 + LLM 활용한 아키텍처 검토
• AI 의존도를 줄이고, 직접적인 코드 이해와 문제 해결 능력 강화를 위한 실무 전략 수립