AI

월 800만 원짜리 API 청구서를 받아든 날 2025년 4분기, 우리 팀의 LLM API 청구액이 처음으로 800만 원을 돌파했습니다. 서비스가 성장하고 있다는 신호이기도 했지만, 동시에 "이대로 두면 스케일이 두 배가 될 때 비용도 두 배가 되는 구조"라는 사실을 직시해야 했습니다. 애플리케이션 코드를 뜯어보니 문제는 명확했습니다.

벡터 DB를 고르는 일이 왜 이렇게 어려운가 — 선택 실수가 운영비로 돌아오는 이유 필자가 속한 팀이 처음 RAG 파이프라인을 도입했을 때, 선택은 빨랐습니다. 이미 PostgreSQL을 운영 중이었고, pgvector 익스텐션 하나면 벡터 검색을 바로 붙일 수 있었기 때문입니다. 초기 문서 수 40만 건, 쿼리 QPS 20 수준에서는 완벽했습니다.

파인튜닝은 하고 싶은데 GPU가 없다는 딜레마 사내 도메인 특화 LLM 도입을 검토하던 2025년 말, 팀이 처음 맞닥뜨린 벽은 "7B 모델 풀 파인튜닝에 H100 4장이 필요하다"는 사실이었습니다. 클라우드 GPU 비용을 계산하는 스프레드시트가 점점 붉게 물들었고, "그냥 RAG로 갈까요?"라는 말이 슬랙에 올라왔습니다. 하지만 RAG가 만능은 아닙니다.

LLM 보안은 왜 우리가 알던 웹 보안과 완전히 다른가 엔지니어링 팀이 처음으로 내부 RAG 챗봇을 프로덕션에 올린 것은 2025년 초였습니다. 사용자가 PDF를 업로드하면 임베딩 파이프라인을 거쳐 벡터 DB에 저장되고, 이후 대화에서 관련 청크를 꺼내 GPT-4o에 컨텍스트로 주입하는 전형적인 RAG 구조였습니다.

한 달 만에 터진 품질 회귀, 그리고 우리가 내린 결론 지난해 11월, 필자가 속한 팀에서는 고객 응대 자동화 서비스에서 예상치 못한 품질 회귀를 경험했습니다.

왜 똑같은 Claude Code를 써도 어떤 팀은 생산성이 3배가 되고 어떤 팀은 사고가 나는가 Claude Code를 처음 도입하는 팀이 흔히 빠지는 함정이 있습니다. "좋은 프롬프트만 쓰면 된다"는 가정입니다. 같은 CLI 도구를 써도 개발자마다 결과가 극명하게 갈립니다.

인공지능(AI) 기술, 특히 LLM(거대 언어 모델)의 발전은 이제 단순히 채팅을 넘어 기업의 실제 비즈니스 로직에 깊숙이 침투하고 있습니다. 하지만 OpenAI의 GPT나 Anthropic의 Claude를 기업용 서비스에 그대로 도입하려는 개발자들은 공통된 난관에 부착하게 됩니다.

인공지능(AI)과 거대 언어 모델(LLM)의 발전 속도는 따라잡기 벅찰 정도입니다. 불과 몇 년 전만 해도 자연스러운 대화가 가능한 챗봇에 열광했지만, 이제 우리는 AI가 직접 코드를 작성하고, 복잡한 시스템의 로그를 분석하며, 인간을 대신해 다양한 도구(Tools)를 자율적으로 제어하는 'AI 에이전트(AI Agent)'의 시대에 살고 있습니다.