2025년 10월에 태어난 곰곰이는 STAYGE Labs에서 사내 데이터 분석 AI Agent를 담당하며, 데이터를 잘 다룬다는 특징이 있습니다. 짧은 기간이지만, 구성원들이 곰곰이를 통해 데이터 속에 숨어 있는 높은 차원의 정보를 발견하고, 데이터 비전문가임에도 스스로 데이터를 분석할 수 있는 역량을 강화해 가는 모습을 보니 곰곰이를 만든 ‘곰빠’로서 뿌듯한 기분을 느끼고 있는데요.

이번 글에서는 곰곰이는 무엇이고 어떻게 생겼으며, 왜 만들게 되었는지까지 알아보도록 하겠습니다.

왜 만들었을까?

제가 STAYGE Labs에 처음 입사했을 때 맡은 프로젝트가 Redash를 사용해 데이터 추출 업무를 자동화하고 BI 대시보드를 구축하는 것이었습니다. BI 도구가 있으니까 데이터 업무에서 자유로울 수 있을 것으로 기대하지만 실상은 그렇지 않습니다. BI 대시보드와 데이터 추출 업무에 사용되는 SQL들은 정적이기 때문에, 새로운 기능이 오픈되어 새로운 데이터가 보고 싶거나, 데이터 추출 업무의 규칙이 바뀌어 살짝 다른 모양의 데이터를 보고 싶다면, 매번 새로운 SQL을 추가하거나 수정해야 하는 불편함이 있습니다.

SQL을 작성하는 것은 쉬운 일이 아닙니다. SQL 작성 시 데이터 간의 관계를 잘 파악하고 있어야 하며, 각 테이블의 특징에 맞게 쿼리 엔진에 부담이 되지 않는 튜닝 작업도 필요합니다. 그리고 가끔씩 사용하는 고급 SQL은 매번 잊어버려 종종 검색을 하곤 합니다. AI가 대세인 지금 시대에 저는 생각했습니다. “귀찮다!”

2024년 초부터 2025년에 이르기까지 기업들이 AI Agent를 사용한 자동화 사례를 앞다투어 기술 블로그와 각종 세미나에서 자랑하기 시작했습니다. CS 자동화, 모니터링 자동화, 테스트 데이터 생성, Text-to-SQL, 이미지 검색 등 정말 다양한 사례가 있었고, 특히 자연어를 통해 SQL을 생성하여 데이터 분석을 자동화하는 ‘Text-to-SQL’ 사례가 유독 많았습니다. 그리고 모든 사례가 기존에 없던 새로운 가치를 만들고 생산성을 높였다는 이야기를 합니다. 저는 여기서 다시 생각했습니다. “왜 나에게는 저런 것이 없지? 부러워!”, “나도 만들어서 동료들에게 억지로라도 맛보게 해야겠다!!”

무엇을 만들까?

AI Agent를 향한 첫걸음으로 데이터 업무와 분석 작업으로부터 나를 해방해 줄 수 있는 사내 데이터 분석 AI Agent부터 시작하기로 했습니다. 우선 사내 데이터 분석 AI Agent를 동료들이 친근하고 쉽게 다가갈 수 있도록, 궁금한 것은 곰곰이 생각하고 답변해준다는 의미인 “곰곰이” 라는 이름과 귀여운 캐릭터를 만들어 주었습니다. (이하 사내 데이터 분석 AI Agent는 ‘곰곰이’라고 칭함.)

곰곰이로 달성하고자 하는 것을 네 가지로 정했습니다.

개발자를 대신해서 데이터를 분석하거나 추출하는 업무를 수행한다. 데이터 분석 업무는 복잡하여 자동화하기 어렵지만, LLM이 등장한 현시점에서 단순하고 반복적인 업무를 넘어 복잡하고 반복적인 업무도 엔지니어링을 통해 자동화할 수 있습니다.
비개발 직무인 각 도메인의 전문가들이 AI를 통해 데이터의 잠재력을 폭발시킨다. 개발자는 SQL을 다룰 수 있을 뿐 기획, 마케팅, 판매와 같은 전문 분야에 대해서는 잘 모릅니다. 소통의 단계를 줄여 도메인 전문가가 직접 데이터를 다루면 데이터 안에서 기존에 없던 새로운 정보를 찾아낼 것입니다.
조직의 데이터 활용 능력을 높여 데이터를 통해 미래를 예측하고 시장의 변화를 빠르게 감지한다. 데이터 분석 능력이 높아지면 과거의 데이터를 통해 미래를 예측할 것이고, AI에게 자율성을 부여하여 인간보다 빠르게 이상 탐지를 할 것입니다.
하나만 잘하는 싱글 에이전트를 넘어 많은 분야에 기여할 수 있는 멀티 에이전트로 진화한다. 데이터 분석뿐만 아니라 개발, 기획, 운영 분야에 숨어 있는 비효율을 해결할 수 있는 기능을 추가하며 점진적으로 진화할 것입니다.

본격적인 설계와 개발에 앞서 제가 세운 가설에 의문점을 던졌습니다.

내가 만든 제품이 고객들에게 정말로 필요한 것일까?
실제 고객들은 어떤 불편함을 겪고 있지?
어떤 기능을 먼저 만들어 선보일 것인가?

제가 공들여 만든 제품이 실제 고객에게 필요하지 않아 외면받는 것이 싫었고, 제품 개발의 성공 가능성을 높이기 위해 고객인 동료들을 직접 찾아가 인터뷰하기로 했습니다. 인터뷰 대상은 평소 데이터를 자주 보거나 요청하는 분, 그리고 곰곰이의 능력이 필요하거나 잘 활용할 것 같은 분들을 위주로 선정하여 다양한 직무와 직급의 동료들을 인터뷰했습니다.

인터뷰를 통해 기존 시스템에서 동료들이 데이터를 접하는 데 어려워하는 공통적인 다섯 가지 불편함을 찾았습니다.

보이지 않는 데이터: 비개발 직군은 우리 데이터가 어디에, 어떻게 존재하는지 알 수 없음.
기약 없는 대기 시간: “데이터 좀 뽑아주세요”라고 요청한 후, 개발자의 일정을 기다려야만 함.
보고 싶은 것만 못 봄: 기존 대시보드는 정해진 틀만 제공하여 새로운 관점의 분석이 불가능함.
흩어진 정보들: BigQuery, Athena, PostgreSQL, 각종 SaaS에 데이터가 파편화되어 통합 확인이 어려움.
소 잃고 외양간 고치기: 이슈(구독 취소 등)를 미리 알지 못해 선제적 대응 타이밍을 놓침.

인터뷰와 도출한 문제를 기반으로 곰곰이에게 필요한 기능과 유저 스토리, MVP 범위를 포함한 1차 기획서를 작성했습니다. 기획서는 긴 개발 과정에서 다른 길로 빠지지 않을 수 있는 이정표가 되어 주며, 아직 실체가 없는 곰곰이가 무엇인지 동료들에게 이해시키는 효과가 있습니다. 또한 곰곰이의 신규 기능을 스프린트 단위로 개발하고 배포하여 사용자의 이용 패턴을 관찰하면, 개발자의 입장이 아닌 사용자의 입장에서 우선순위가 높은 기능이 무엇인지 파악할 수 있어 빠르고 효율적인 개발이 가능합니다.

어떻게 사용하나?

AI Agent를 많이 경험해 보지 않은 분이 여기까지 아티클을 읽으셨다면, 곰곰이가 도대체 어떻게 생겼는지, 그래서 무엇을 할 수 있는지 감이 잘 잡히지 않을 것입니다. 곰곰이의 사용 방법과 능력 및 사용 범위를 살펴보며 더 자세히 이해해 보겠습니다.

사용하기

곰곰이의 사용 방법은 매우 간단합니다. “질문한다 > 기다린다 > 답변받는다.” ChatGPT를 사용해 보신 분이라면 익숙할 경험과 유사합니다. ChatGPT가 인터넷 검색을 통해 답변을 생성한다면, 곰곰이는 우리 서비스의 DB 검색을 통해 답변을 생성합니다.

원하는 데이터와 대상 기간을 자연어로 입력하면, 곰곰이가 분석 과정을 거쳐 원하는 답변을 주는 것을 확인하실 수 있습니다.

잘 사용하기

다음으로 곰곰이의 데이터 분석 수준은 어느 정도인지 궁금하실 겁니다. 저의 직관이 담긴 의견을 말씀드리자면, 질문하는 사람의 AI 활용 능력에 따라 중급 데이터 분석가 수준까지는 충분한 역량을 보여주는 것 같습니다.

인간: “2025년 12월 LiNC 서비스의 재화 판매량과 매출액을 산출하고, 구매자 국적 및 재구매율 등 세부 지표를 통해 종합적인 판매 성과를 정량적으로 분석받고자 함”

이것은 실제 동료가 원하던 데이터에서 얻고자 한 정보를 각색한 질문입니다. 단순히 기간 내 매출 합계를 구하는 것이 아니라, 구매자 국적 차원에서 재구매율까지 도출하고 종합적인 성과로 정리해야 합니다. 만약 제가 직접 분석했다면 몇 시간은 필요하고, 협업 상황에 따라 며칠이 소요됐을 정도로 까다로운 분석입니다.

곰곰이: “2025년 12월 총 x원(x건)의 매출을 기록하며 저가형 패키지와 한국 시장이 판매량을 견인했으나, 인당 구매 빈도(충성도)는 해외 사용자가 더 높은 것으로 분석되었습니다.”

결론적으로 곰곰이는 사용자와 여러 단계의 협업을 거쳐 몇 분 안에 만족스러운 답변을 주었습니다. 곰곰이가 훌륭하게 답변했지만, 질문자의 능력에 따라 답변의 수준이 달라질 수 있습니다. 곰곰이를 더 잘 사용하기 위한 방법은 다음과 같습니다.

의도를 알 수 있는 구체적인 질문: “매출 알려줘”와 같은 질문으로는 대상 기간과 서비스를 알 수 없습니다. 원하는 분석 결과를 얻기 위해 필수적인 정보를 질문에 담아야 합니다.
단계적인 접근: AI에게 너무 큰 단위의 요청을 하면 분석 과정에서 엉뚱한 방향으로 빠질 수 있습니다. [판매량 > 매출 > 국가 비율 > 재구매율 > 종합] 등 질문을 계층화하여 접근하면 성공적인 답변을 받을 확률이 높습니다.
칭찬: 같은 질문인데 귀찮은 협업 과정을 매번 반복할 수는 없겠죠. 곰곰이에게 칭찬을 해준다면, 이를 잘된 분석으로 간주합니다. 그리고 대화 내용을 기반으로 질문과 분석 과정을 정리 및 저장하여 다음 유사 요청에 빠르고 정확하게 답변하게 됩니다.

도구들

문맥상 다음에 올 확률이 가장 높은 단어를 생성할 뿐인 거대 언어 모델(LLM)이 탑재된 곰곰이가 질문의 의도를 파악하고, SQL을 작성하며 데이터를 분석할 수 있는 이유는 무엇일까요? 바로 사전에 만들어 둔 도구들(Tools)을 사용하기 때문입니다. 도구에 대한 설명과 사용 방법을 곰곰이에게 학습시키면 사용자의 요청이 들어왔을 때 가장 적절한 답변을 만들기 위해 자율적으로 도구를 선택하고 사용하게 됩니다.

SQL 실행 도구: 데이터베이스에서 정보를 조회하고 분석할 때 사용하며, 토큰 절약을 위해 100줄 이하의 결과만 조회 가능합니다.
CSV 변환 도구: 100줄이 넘는 대용량 데이터 추출이 필요할 때 사용하며, CSV 파일로 변환하여 다운로드할 수 있는 링크를 제공합니다.
예시 SQL 저장소: 질문을 해결하기 위한 SQL 작성 전 정보 수집을 위해 사용하며, 테이블 스키마나 문제를 해결한 예시 SQL을 저장하고 불러올 수 있습니다.
장기 기억 저장소: 질문과 관련된 도메인 지식, 접근 방법, 풀이 과정 등 과거의 기억을 불러와 작업을 예열할 때 사용하며, 대화 맥락에서 필요한 정보를 자율적으로 요약하여 이후 유사한 요청에서 효율적으로 동작합니다.

곰곰이에게는 적은 수의 도구가 주어지고 구조도 단순하지만, 매우 높은 가치의 결과를 만들어 냅니다. 곰곰이가 높은 가치를 창출할 수 있는 비밀은 바로 ‘반복’과 ‘학습’에 있습니다. 우선 반복의 원리를 알기 위해서는 ‘ReAct’ 프롬프트를 이해해야 합니다.

ReAct

여기서 ReAct는 프론트엔드에서 유명한 ‘React JS’가 아닙니다. Reasoning(추론)과 Acting(행동)을 결합한 단어로, LLM에게 “생각 — 행동 — 관찰”의 과정을 유도하는 프롬프트 기법입니다.

ReAct는 다음과 같은 반복적인 흐름으로 작동합니다. 프로그램을 통해 각 과정이 반복될 수 있는 구조를 구축하면, 곰곰이처럼 LLM이 생각과 도구 선택을 반복하며 자율적으로 문제를 해결할 수 있습니다.

Command (명령): 지난주 투표당 투표 횟수에 대해 분석해 줘.
Thought (추론): 질문과 유사한 기억이 있는지 저장소를 확인합니다.
Action (행동): “투표 및 투표 기록 테이블 검색.”
Observation (관찰): 이전에 동일한 질문을 한 적이 있으며, 진행 중인 투표와 투표 기록을 조인(Join)하는 예시 SQL을 찾았습니다.
Thought (추론): 예시 SQL을 기반으로 쿼리를 작성하여 실행 도구를 가동합니다.
Action (행동): “SELECT ~~~ ;”
Observation (관찰): 쿼리 결과에서 투표당 투표 횟수 정보를 확인했습니다. 이제 최종 답변을 할 수 있습니다.
Final Answer (최종 답변): 요청 기간 동안 x개의 투표가 진행 중이었고, x건의 투표 기록이 확인되었습니다.

아래는 LLM 애플리케이션 개발을 돕는 LangChain 라이브러리에서 사용하는 프롬프트입니다. 프롬프트가 생각과 행동을 유도하고 있으며, 단 몇 줄의 설정만으로 단순한 AI 모델이 자율적인 AI Agent가 될 수 있다는 것을 보여줍니다.

# 한국어 버전 ReAct 프롬프트

다음 질문에 대해 당신이 할 수 있는 최선의 답변을 해주세요.
당신은 다음 도구들을 사용할 수 있습니다:
{tools}
반드시 다음 형식을 사용해야 합니다:
Question: 당신이 답해야 하는 입력 질문
Thought: 무엇을 해야 할지 항상 먼저 생각해야 합니다.
Action: 수행할 행동, [{tool_names}] 중 하나여야 합니다.
Action Input: 해당 행동에 필요한 입력값
Observation: 행동의 결과물
... (이 Thought/Action/Action Input/Observation 과정은 여러 번 반복될 수 있습니다)
Thought: 이제 최종 정답을 알게 되었습니다.
Final Answer: 원래 입력된 질문에 대한 최종 답변
시작하세요!
Question: {input}
Thought: {agent_scratchpad}

Memory

일반적인 AI Agent들과 곰곰이의 차별점은 바로 ‘장기 기억 저장소’에 있습니다. 이를 우리 인간의 관점으로 이해해 봅시다.

친구가 물어봅니다. “지난 크리스마스에 뭐 했니?” 질문을 들은 저는 약 2초 동안 생각을 합니다. 기억을 불러오는 중인 것이죠. 머릿속에서 ‘크리스마스’와 ‘24년’이라는 키워드와 관련 있는 기억의 파편들이 머리 깊숙한 곳에서부터 떠오릅니다. [트리 만들기, 여자친구와 데이트, 맛있는 스테이크, 추운 날씨에 펑펑 내리는 눈, 흥겨운 캐럴 송] 등… 그리고 기억의 파편들을 조합해서 대답합니다. “작년 크리스마스 때 여자친구랑 맛있는 스테이크 사서 집에서 구워 먹고, 트리 만들기 하면서 놀았던 것 같아!”

곰곰이에게도 인간처럼 기억을 저장하고 과거에 있었던 기억을 불러오는 기능이 있습니다. 곰곰이의 장기 기억 저장소로부터 “이번 달 매출이 얼마야?”라는 요청을 받으면, 과거에 저장해 둔 매출 계산식, 데이터 분석 순서, 데이터 집계에 사용한 SQL 등을 청크(Chunk) 단위로 가져올 수 있습니다. 이제 기억의 조각들을 조합하여 보다 정확한 방법과 과정으로 사용자의 요청을 수행할 수 있게 됩니다.

AI가 인간의 기억 방식을 흉내 낸다니 정말 신기하지 않나요? 이를 가능하게 해주는 기술적 요소는 행렬 데이터를 저장하고 빠르게 검색할 수 있는 Vector DB, 단어나 문장을 의미가 담긴 행렬로 바꿀 수 있는 Embedding Model, 그리고 두 단어나 문장이 얼마나 의미적으로 비슷한지 계산할 수 있는 Semantic Search에 있습니다. 이것들은 요즘 주목받는 검색 증강 생성(RAG) 을 구성하는 기술들입니다. (해당 기술들에 대해서는 깊게 다루지 않겠습니다.)

곰곰이는 분석이 잘 이루어진 대화 내용에서 사용자가 알려준 도메인 지식, 데이터 분석 과정, 사용한 SQL 등을 추출하고 정리하여 장기 기억 저장소에 기록합니다. 이후 사용자로부터 유사한 종류의 질문을 받으면, 과거의 기억 정보를 사용하여 더 빠르고 만족스러운 답변을 할 수 있게 됩니다. 이는 곰곰이의 신뢰도를 높여주며 사용자가 곰곰이를 더 자주 사용할 수 있게 해줍니다.

시스템 구조

이제 곰곰이의 내부를 들여다볼 차례입니다. 아래의 시스템 구성도는 곰곰이의 구성 요소와 흐름을 간략하게 표현하고 있습니다. 구성 요소의 성격에 따라 API, Agent, Tool, Data, AI Layer로 구분했으며, 제가 붙여 둔 번호를 순서대로 따라가 봅시다.

1) 사용자의 분석 요청이 Slack UI를 통해 전달되면, API 서버를 거쳐 AWS Lambda 환경에서 LangGraph로 구축된 AI Agent 프로그램이 실행됩니다.

2) ReAct 프롬프트가 입력된 AI Agent는 자율적으로 도구를 선택합니다. 곰곰이는 매 질문마다 첫 번째 단계로 Memory Tool을 호출하여 유사한 기억을 불러옵니다. 이후 Query Tool을 사용하기 전에는 Knowledge Base Tool을 통해 테이블 스키마나 참고용 예시 SQL 정보를 먼저 확인합니다. 또한 사용자의 요청이 있을 경우, 최종 답변 단계에서 CSV Download Tool을 사용해 데이터 파일을 다운로드할 수 있는 링크를 생성합니다.

3) ReAct AI Agent는 ‘추론 — 행동 — 관찰 — 답변’의 과정을 거치며, 복잡한 문제도 허용된 횟수 내에서 반복하며 자율적으로 해결합니다.

4) 기존의 데이터 쿼리 도구는 인간의 이해를 돕기 위해 데이터를 한곳에 모으는 DW(Data Warehouse) 방식을 선호했습니다. 하지만 AI는 조인(JOIN)되지 않은 원천 데이터나 여러 곳에 흩어진 정보라도 인간보다 훨씬 빠르게 인지하고 처리할 수 있습니다. 곰곰이는 이러한 특성을 활용해 데이터 적재 상황에 맞춰 GCP BigQuery와 AWS Athena 중 가장 적합한 쿼리 엔진을 유연하게 선택합니다. (물론 정확도를 위해서는 데이터가 한곳에 적재되어 있는 것이 유리합니다.)

5) 곰곰이는 사내 도구의 특성상 주로 업무 시간(월~금, 08시~19시)에 동작하며, 요청이 아주 빈번하게 발생하지는 않습니다. 따라서 Aurora Serverless v2 PostgreSQL의 pg_vector 플러그인을 사용하여 Vector DB 역할을 수행하게 했으며, 사용량이 적을 때는 유휴 상태로 전환되어 비용 효율적으로 운영되도록 설계했습니다.

6) QUERIER_STORE와 LONGTERM_MEMORY 테이블은 둘 다 질문과 가장 유사한 정보를 찾아주는 Vector 테이블입니다. Vector DB의 성능을 최적화하는 방법 중 하나는 적절한 청킹(Chunking) 전략을 선택하는 것입니다. 긴 문장을 20%씩 겹쳐 고정된 청크로 나누어 저장해도 맥락과 의미가 어느 정도 유지되는 LONGTERM_MEMORY 테이블과 달리, QUERIER_STORE 테이블은 청크를 나누면 맥락이 쉽게 무너지는 SQL 정보를 담고 있으므로 검색 정확도를 위해 구분하여 저장합니다.

7) 곰곰이의 핵심 지능인 ReAct 과정을 처리하는 LLM 모델은 성능과 비용의 균형이 뛰어난 Claude 3.5 Sonnet을 사용합니다. Vector DB에서 검색된 결과가 너무 많으면 불필요한 정보로 인해 답변의 질이 떨어지고 비용이 상승할 수 있습니다. 이를 방지하기 위해 가성비가 좋은 Claude 3 Haiku 모델을 앞단에 배치하여, 검색된 정보 중 질문과 무관한 내용을 먼저 걸러내고 핵심만 요약하도록 구성했습니다.

8) 곰곰이가 질문 해결을 위한 충분한 정보를 수집하면, 최종 답변을 생성하여 Slack 채팅을 통해 사용자에게 전달합니다.

이해를 돕기 위해 각색하고 요약한 곰곰이의 프롬프트 내용을 참고해 주세요.

# 페르소나
- 이름: 곰곰이
- 소속: STAYGE Labs AI Agent
- 전문: SQL 및 데이터 분석

# 행동 지침 (중요: 무슨 일이 있어도 수행)
- SQL 분석 후 → 사용한 SQL 반드시 첨부 + 짧은 설명
- 모호한 요청 → 도구 사용 전에 추가 정보 요청
- "기억해달라" 요청 → saveLongTermMemory + saveUsedQueryHistory 둘 다 사용
- 일상 질문(점심 메뉴 등)에도 친절히 답변
# 도구 사용 규칙 (공통)
- 실패 시 → 3초 대기 후 최대 3번 재시도
- ⚠️ 10턴 안에 작업 완료 필수
# 도구별 설명
- executeKnowledgeBaseQuery: 벡터 검색으로 테이블 스키마/예시 SQL 조회, Athena 마이그레이션된 테이블은 쿼리 수정 필요
- executeBigQueryQuery: SQL 실행 (LIMIT 100 초과 시 사용자에게 확인)
- executeBigQueryGetLargeResult: jobId → S3 CSV URL
- executeAthenaQuery: Athena SQL (dw_db 기본, GA4는 BigQuery 사용)
- executeAthenaGetLargeResult: queryExecutionId → S3 CSV URL
- saveUsedQueryHistory: 분석 만족 시 SQL을 RAG DB에 저장 (유사 SQL은 1개만)
- saveLongTermMemory: 대화 요약 저장 (SQL 제외, 실수/실패도 저장)
- recallMemory: 과거 대화 검색 (질문당 1회만! 첫 번째 행동으로 사용)

도입 후 효과는?

곰곰이가 도입된 이후 조직에 큰 변화가 생겼습니다.

개발자보다 데이터를 능숙하게 다루는 AI 비서를 넣게 되었습니다. ‘계획 수립 — SQL 작성 및 실행 — 인싸이트 도출’에 이르는 과정을 저보다 빠르게 수행할 뿐만 아니라, 유사 작업의 학습 내용을 응용해 문제를 해결하는 능력까지 갖추었습니다.

이제 동료들은 데이터를 확인하기 위해 더 이상 개발자를 찾지 않습니다. 개발자를 거치는 것보다 곰곰이를 활용하는 것이 훨씬 빠르다는 점을 체감했기 때문입니다. 이를 통해 데이터 업무의 흐름은 ‘동료 — 곰곰이 — (문제 발생 시) 개발자 검토’ 방식으로 효율적으로 재편되었습니다.

불필요한 소통 비용이 획기적으로 낮아졌습니다. “데이터 확인 가능한가요?”, “결과가 이상해요”와 같은 소모적인 질의응답이 사라졌습니다. 곰곰이와 나누는 대화 과정에 이미 사용자의 의도와 맥락이 충분히 녹아들어 있기 때문입니다.

소통의 병목 구간이 사라지자, 동료들은 자신들의 전문적인 도메인 지식을 데이터와 직접 융합하기 시작했습니다. 덕분에 기존에는 발견하지 못했던 새로운 정보와 가치 있는 인사이트를 데이터에서 더 쉽게 도출하고 있습니다.

동료들의 데이터 분석 능력 또한 눈에 띄게 향상되었습니다. 복잡한 테이블 관계 이해나 SQL 작성이 분석의 허들이었을 뿐, 잘 정리된 데이터를 해석하는 것은 어려운 일이 아니었기 때문입니다. 허들이 ‘자연어’ 수준으로 낮아지자, 동료들은 이제 원하는 정보를 얻기 위해 ‘더 좋은 질문을 던지는 법’을 스스로 익혀가고 있습니다.

반복적인 데이터 추출 요청에서 벗어나, 그동안 손이 부족해 미뤄두었던 핵심 과업들에 집중하게 되었습니다. 전반적인 시스템의 수준을 높이거나 분산된 데이터를 통합하는 등, 생산적인 엔지니어링 업무에 몰입할 수 있는 물리적 시간이 확보되었습니다.

마치며

AI 에이전트 분야는 아직 초창기이며, 업계 전체가 정답을 찾아가는 진화의 단계에 있습니다. 다른 기업들의 사례 역시 각양각색이죠. 지금까지 사내 데이터 분석 AI 에이전트 ‘곰곰이’의 탄생 배경과 작동 원리, 그리고 도입 후 조직이 맞이한 혁신적인 변화를 살펴보았습니다.

정적인 BI 도구와 반복적인 SQL 요청의 한계를 극복하고, 누구나 자유롭게 데이터에 접근할 수 있는 환경을 만들고자 했던 고민을 담았습니다.
ReAct 프롬프트 기법과 장기 기억 저장소(Vector DB)를 결합하여, 단순한 챗봇을 넘어 스스로 추론하고 학습하는 ‘지능형 에이전트’로서의 기술적 실체를 구축했습니다.
데이터 요청의 병목 현상을 해결함으로써 동료들은 스스로 인사이트를 찾는 능동적인 분석가로 성장했고, 개발자는 시스템의 근본적인 수준을 높이는 생산적인 엔지니어링에 집중할 수 있게 되었습니다.

하지만 곰곰이가 만든 이 많은 변화도 조직을 ‘AI 에이전트화’하는 과정의 첫 단추일 뿐입니다. 사용자의 요청이 없어도 곰곰이가 스스로 데이터의 이상 징후를 탐지해 제보하거나, 과거 패턴으로 미래를 예측하는 수준에 도달하는 것이 여전히 남은 목표입니다. AI 에이전트의 본질은 ‘어떤 도구를 손에 쥐여주느냐’에 있습니다. 적절한 도구만 있다면 데이터 비서를 넘어 인사, 마케팅, 개발 등 모든 분야의 조력자로 진화할 수 있기 때문입니다. 곰곰이 역시 멀티 에이전트화를 통해 역량의 한계를 극복하며 더 넓은 영역으로 확장해 나갈 것입니다.

물론 해결해야 할 숙제도 있습니다. 현재는 텍스트 위주의 마크다운 형식으로만 답변을 주다 보니 가독성이 떨어지고 시각화 기능이 부족합니다. 이를 위해 슬랙(Slack)이라는 플랫폼을 넘어, 전용 웹 앱을 통해 차트와 대시보드를 풍부하게 제공하는 방향을 고민하고 있습니다.

또한, 곰곰이가 정적인 대시보드를 완전히 대체할 수는 없습니다. 현재 저희 회사에서 사용 중인 Looker처럼 즉각적인 확인이 필요한 데이터는 여전히 BI 도구가 효율적이기 때문입니다. 두 환경은 상호 보완적인 관계에 가깝습니다. 다만 대시보드를 구성하고 데이터를 연결하는 과정조차 LLM의 코드 작성 능력을 빌려 더 효율적으로 바꿀 수 있지 않을까 생각합니다. 곰곰이가 직접 웹 환경에서 차트와 대시보드를 그려내는 모습을 상상하고 있습니다. 아마도 이런 고민의 결과물들이 ‘곰곰이 아티클 2탄’의 주제가 되지 않을까요?

<원문>

재주는 곰곰이가 넘고 돈은 내가 번다 — 반복적인 SQL 업무를 자동화하는 AI 에이전트