E12 · 컴투스플랫폼 · 2023.02 – 2026.02
말로 요청하면 인프라 코드를 만들어주는 AI
로컬 LLM과 벡터 DB로 만든 프로토타입, 그리고 검증에서 찾은 한계
- AI
- LLM
- RAG
- Ollama
- Chroma
- Docker
- Terraform
한 줄 요약
로컬 LLM과 벡터 DB로 인프라 코드 생성 프로토타입을 만들어 팀에 시연했고, 검증에서 한계를 찾아 다음 설계까지 정리했습니다. 실무 정착까지는 이어가지 못했습니다.
배경
수백 개의 Terraform·Terragrunt 모듈을 운영하며, 새 리소스를 만들 때마다 기존 구조를 찾아보고 비슷한 코드를 반복 작성하는 데 시간이 많이 들었습니다.
실행
- Docker 환경에 로컬 LLM(Ollama로 실행)과 Chroma 벡터 데이터베이스를 구축했습니다.
- 운영 중인 Terraform·Terragrunt 모듈 구조를 인덱싱했습니다.
- 자연어로 요청하면 비슷한 기존 코드를 찾고, LLM이 그 구조에 맞춰 새 코드를 생성하도록 구성했습니다.
- 팀에 소개하고 시연했습니다.
쉬운 설명RAG가 뭔가요?
RAG(검색 증강 생성)는 AI가 답하기 전에 관련 자료를 먼저 찾아서 함께 보여 주는 방식입니다.
AI는 우리 회사의 코드를 모르기 때문에, 비슷한 코드를 찾아 “참고해서 만들어 줘”라고 같이 넘겨주는 것입니다.
이를 위해 코드를 작은 조각으로 나누고, 각 조각의 의미를 숫자 목록(임베딩)으로 바꿔 벡터 DB에 저장합니다. 요청이 들어오면 요청도 숫자로 바꿔 의미가 가장 가까운 조각을 찾습니다.
결과
검증에서 발견한 한계
단순 RAG 방식은 AI가 모듈 구조를 이해해서 만드는 것이 아니라, 검색된 코드의 패턴을 맞추는 수준에 머물렀습니다.
검색 결과에 없는 조합을 요청하면, 그럴듯해 보이지만 모듈 간 연결이 맞지 않는 코드가 나왔습니다.
다음 단계 설계
- 임베딩 기반 유사도 검색 고도화
- LangChain(검색·프롬프트·생성 단계를 연결하는 프레임워크) 기반 RAG 파이프라인으로 전환
팀 우선순위가 바뀌면서 실무 정착까지는 이어가지 못했습니다.
배운 점
AI 결과는 반드시 검증해야 합니다.
좋은 도구라도 팀의 우선순위와 맞지 않으면 쓰이지 않습니다. 만들기 전에 “지금 팀의 어떤 문제를 해결하는가”를 먼저 확인해야 합니다.
혼자 완성도를 높이기보다 초기에 방향을 공유했다면 한계를 더 빨리 확인할 수 있었습니다.