회사에서 ‘기피 프로젝트’였던 AI 사이드 프로젝트를 맡게 되기까지

우리 회사에는 사이드로 운영되는 AI 프로젝트가 하나 있다.
C레벨 중 한 분이 총괄을 맡고 있고, 조직 내에서는 모두가 선뜻 손을 들지 않는 프로젝트 중 하나였다.

원래는 미들급 개발자가 맡던 프로젝트였지만, 여러 사정으로 인력이 이동하거나 퇴사하며 공백이 생겼다.
나는 사수가 퇴사하면서 인수인계를 받는 형태로 이 프로젝트를 맡게 되었다.
당시 개인적으로도 회사 일에 매너리즘을 느끼고 있었고, LLM과 AI에 대한 관심이 커지고 있던 시기라 성장해보자는 마음으로 시작했다.

솔직히 중간중간 '이걸 왜 맡았을까' 라는 생각이 들 정도로 쉽지 않은 프로젝트였다.

프로젝트 환경과 구조적 어려움

실무 관점의 판단보다는 방향성 중심의 의사결정이 주를 이뤘다.
LLM 서비스 자체도 회사 내부에서 처음 시도하는 영역이었고,
개발팀 역시 AI/LLM에 대한 경험이 없었다.

"요즘 AI가 대세니까 한번 해보자" 는 기대는 컸지만
실제로 어떤 리소스가 필요하고, 무엇이 가능한지에 대한 합의는 부족한 상황이었다.

1년 반 동안 이 프로젝트에서 내가 한 일들

짧지 않은 시간 동안, 이 프로젝트에서 아래와 같은 작업들을 맡았다.

UI 전면 리뉴얼
LLM 기반 서비스 구조 설계
회사 도메인에 맞춘 새로운 LLM 플로우 설계 및 구현
편의성 개선 등...

처음부터 AI을 잘 알았던 것은 아니다.
AI에 대해 아무것도 모르는 상태에서 시작했다.

AI를 처음부터 다시 배우게 된 과정

AI 부트캠프 참여

주말에만 운영되는 AI 부트캠프에 참여했다.
딥러닝 기초부터 LangChain, 여러 학습 기법을 다뤘지만,
8주라는 짧은 기간에 모든 내용을 깊게 이해하는 것은 현실적으로 불가능했다.
그러나 전체 흐름을 한 번 훑어보며 무엇을 모르는지를 알게 되었고
현업 AI 엔지니어들과 멘토링할 수 있었던 점은 큰 도움이 되었다.

기존 AI 서비스의 한계와 RAG 도입 결정

기존 서비스 구조의 문제

프로젝트 초기에 있던 AI 서비스는 굉장히 단순했다.

캐릭터 페르소나 프롬프트
간단한 키워드 기반 프롬프트를 동적으로 조합하는 방식

=> 회사 도메인과 LLM이 느슨하게 결합된 구조였고, 아래와 같은 문제점이 있었다.

할루시네이션 발생 가능성
회사의 톤앤매너, 기존 상품과 일관성이 맞지 않는 응답

파인튜닝에 대한 논의와 현실적인 판단

대표님은 파인튜닝을 하시길 원했지만

하지만 파인튜닝을 하려면
- 정제된 학습 데이터
- 데이터 관리 체계
- 지속적인 유지보수 리소스가 필요하다.
당시 회사에는 데이터가 여러 곳에 산재되어 있었고,
이를 학습 데이터로 가공할 인력과 시간도 부족했다.

AI를 처음 다뤄보는 조직이고 개발자 1명(나) 포함 3~4명으로 이루어진 소규모 팀이었기 때문에 파인튜닝은 리스크가 컸다.

RAG를 선택한 이유

그래서 선택한 방향이 RAG였다.

학습 데이터를 새로 만들지 않고
회사 도메인 지식을 백과사전 형태로 정리
메타데이터 기반으로 분류
유사도 검색을 통해 관련 문서를 컨텍스트로 제공하는 구조

회의 때 이렇게 해보겠다고 말씀드렸는데, 처음에는 반대를 하셨다.

하지만 파인튜닝이나 RAG나 퀄리티 높은 답변을 얻는 것에 목표를 두는 것이기 때문에 따로 시간을 들여 간단히 프로토타입을 만들어서 보여드렸다.

모두가 개선된 응답 퀄리티에 만족했었고, 파인튜닝 대신 RAG를 사용하는 것으로 설득이 되었다.

RAG 플로우를 추가한 후,

응답 품질이 눈에 띄게 개선되었고
회사가 판매하는 기존 상품들과 톤앤매너를 맞출 수 있었으며
할루시네이션을 상당 부분 제어할 수 있었다.

성과도 꽤 좋았다.

매출 최대 2배 이상 증가
유저 설문에서 "추천한다" 는 응답 비중이 50% 이상으로 상승
- 이전에는 "추천하지 않는다"가 더 많았던 상태였다.

이 프로젝트를 통해 느낀 점들

AI는 목적이 아니라 수단이다

회사 도메인과 결합했을 때 의미 있는 시너지가 나는지 반드시 검증해야 한다.
AI는 항상 옳은 답이나 깊이 있는 인사이트를 주지 않는다.
때로는 규칙 기반 로직이 더 안정적이고 낫고, 해결하고자 하는 문제가 무엇인지 파악한 후, UI/UX 선에서 개선할 수 있다면 굳이 AI를 택하지 않아도 된다.

AI 서비스의 현실적인 리스크

많은 소규모 팀들이 자체 모델을 만들지 않고, 빅테크의 API에 의존하고 있다.
서비스가 커질수록 비용 부담이 커지고
외부 API 장애가 곧바로 우리 서비스 장애로 이어질 수 있다.
일정 수준 이상의 품질을 항상 보장해야 하는 상품 영역에서는 규칙 기반 플로우 위에 AI가 스며드는 형태가 더 현실적이다.

도메인 지식 정리의 중요성

AI를 붙이기 전에 반드시 점검해야 할 것이 있다.

회사 도메인 지식이 디지털화되어 있는지
한 곳에 잘 모여 있는지
검색과 재사용이 가능한 구조인지

특히 RAG를 고려한다면 아래 3가지 사항들을 체크해봐야한다.

메타데이터를 어떻게 설계할 것인지
어떤 기준으로 문서를 나눌 것인지
이 지식을 AI 응답 요청에서 어떻게 활용할 것인지

이 부분은 개발자뿐 아니라
기획자 역시 반드시 함께 고민해야 하는 영역이라고 느꼈다.

소규모 AI 서비스에 대한 견해

사람들이 열광하는 것은 여전히 파운데이션 모델을 직접 만드는 테크 대기업들이다.
챗지피티, 클로드, 제미나이는 이미
- 검색
- 에이전트
- 음성 인터페이스
  등 일반 소비자가 원하는 기능을 대부분 갖추고 있다.

여기서 우리팀의 도메인이 어떤 차별점 얻을 수 있는 지 반드시 체크를 해야한다.

소비자의 니즈를 파악하는 것도 중요하다.

우리 팀의 도메인은 엔터테인먼트, 콘텐츠다.

정확도, 정밀도가 아닌 유저들과 감정을 교류하고 즐거움을 전하는 서비스라서 AI의 타격이 없지는 않았다.

어쩌면 많은 소비자들은 완벽한 답을 바라지 않을 수도 있다.
적당히 싼 값에 원하는 것의 70%를 얻을 수 있다면 그 쪽을 더 선택하지 않을까 싶다.
실제로 GPT-4 출시 이후부터 SNS을 통해 챗지피티를 활용한 콘텐츠들이 많이 올라오고 있다.
콘텐츠가 메인인 곳들은 개인화 와 퀄리티를 더 깊이 파고들어야할 것 같다. 단순히 결제하고 끝나는 것이 아니라, 각 유저별로 콘텐츠 사용 목록을 분석해서 컨텍스트를 생성하는 플로우가 필요하지 않나 싶다.
챗지피티에서도 유저가 원하는 페르소나 챗봇을 만들려면 유저가 직접 프롬프트를 수정하거나 챗봇을 다그치는 과정들이 필수적인데 이런 번거로운 과정을 UX로 풀어나갈 수 있다면 좋을 것 같다.

소비자의 니즈를 제대로 풀어내지 않으면 성능 좋은 모델을 사용했음에도 챗지피티 무료버젼보다 가성비 떨어지는 서비스가 될 가능성도 있다고 느꼈다.

마무리하며

이 프로젝트는 쉽지 않았다.

다시 같은 선택을 하라고 하면 망설일 것 같기도 하다.

그러나, 한 프로젝트의 개발 리드를 맡아 몰입하면서 기술적으로도 많은 것을 배웠다.
이전까지는 유지보수가 주 업무였는데 직접 설계를 고민하고, 구현해보고 성과까지 파악할 수 있는 귀중한 경험을 가질 수 있었다.
여러모로 풀스택 개발자에 가까워지고 있다.

앞으로는 새로 출시한 랭체인 V1와 랭그래프를 통해 플로우를 개선하고, 재활용 가능한 하나의 LLM 기반 시스템을 만들어보려고 한다.

AI가 유행한다해도
제품은 여전히 사람이 만든다는 것을 명심해야겠다.

[회고] 소규모 팀에서 LLM 서비스 만들기