들어가며
안녕하세요. Game Platform실의 이형중, 김민희, 정소영입니다. 저희 조직은 게임 퍼블리 싱에 필요한 다양한 기능을 개발하고 운영하는 역할을 맡고 있습니다.
저희는 ‘자연어 질문 → SQL 생성 → 실행/시각화’까지 이어지는, 이른바 대화형 BI 애플리케이션(ChatGamesight)을 만들고 있습니다. 사용자는 데이터 테이블을 직접 찾아 들어가거나 대시보드를 이리저리 탐색하지 않아도, 궁금한 내용을 질문 형태로 던지고 결과를 바로 확인할 수 있습니다.
여기서 BI(Business Intelligence)란 조직에 쌓인 데이터를 지표, 대시보드, 리포트 형태로 정리해 지금 무슨 일이 벌어지고 있는지를 빠르게 판단할 수 있게 돕는 체계입니다. 다만 기존에는 지표 정의와 배경 맥락이 여러 곳에 흩어져 있어, 질문이 생길 때마다 담당자가 정의를 다시 확인하고 쿼리를 작성해야 했습니다. 그 결과 비데이터 직군은 답을 얻기까지의 허들이 높았고, 데이터 담당자는 반복 문의와 컨텍스트 스위칭 비용을 꾸준히 떠안는 구조가 되기 쉬웠습니다.
이런 배경에서 질문만 하면 답이 나오는 BI를 만들고자 LLM을 도입했을 때, 처음에는 SQL을 그럴듯하게 생성해 주기만 하면 될 것 같아 보였습니다. 하지만 실제 데이터 환경에 얹어 운영을 도입하려고 하니, 중요한 건 질문-응답의 한두 번 성공이 아니라 ‘운영 가능한 신뢰’라는 것을 곧바로 체감했습니다. 운영 환경에서는 ‘가끔 틀리는 답’과 ‘가끔 위험한 쿼리’가 결국 애플리케이션 전체의 신뢰를 무너뜨리기 때문입니다.
이번 글에서는 이 과정에서 마주친 문제와, 대화형 BI에 운영 가능한 신뢰를 더하기 위해 설계한 구조와 안전장치를 공유하고자 합니다.
대화형 BI 애플리케이션을 운영하며 마주한 과제
먼저 원활한 이해를 돕기 위해 저희가 개발해 서비스하고 있는 대화형 BI 애플리케이션의 동작 흐름에 대해 소개하겠습니다.
대화형 BI는 겉으로는 ‘질문하면 답한다’로 보이지만, 내부적으로는 질문 해석, 지식 검색, SQL 생성, 실행/시각화, 답변 생성 단계가 촘촘히 연결됩니다.
이 흐름을 실제 운영 환경에 적용하면서 가장 크게 부딪힌 문제는 두 가지였습니다. 하나는 사내 데이터의 의미를 모델에 어떻게 전달할 것인가였고, 다른 하나는 모델이 생성한 SQL을 권한, 개인정보, 리소스 관점에서 어떻게 안전하게 실행할 것인가였습니다.
문제 1: LLM은 사내 데이터의 의미를 모른다
스키마(DDL)와 컬럼 설명만으로는, 비즈니스에서 쓰는 지표의 의미나 데이터 간 관계를 온전히 전달하기 어렵습니다.
- 동일한 매출이라도 환불 또는 취소 반영 여부, 기준 시점(결제일 또는 정산일), 집계 단위(일/주/월)가 다를 수 있음
- 테이블 간 JOIN 키는 존재하지만 ‘이 JOIN은 이런 목적일 때만 사용해야 한다’는 암묵지가 있음(중복 제거, 최신 스냅샷, 유효 기간 등)
- 대시보드에 숨어 있는 필터와 계산식이 사실상의 표준 정의가 되어 있음
결과적으로 모델이 만든 SQL이 문법적으로 그럴듯해도, 의도한 지표와 다른 값을 내거나 해석이 어려운 결과를 내는 일이 발생했습니다. 운영에서 신뢰를 무너뜨리는 건 보통 이런 ‘그럴듯한 오답’입니다.
예를 들어 다음과 같은 경우가 있었습니다.
- 질문 의도는 ‘활 동 유저’였는데, SQL은 ‘로그인 유저’를 집계하는 식으로 정의가 미묘하게 어긋나는 경우
- 기본 제외 조건(테스트 계정, 특정 채널 등)이 누락되어 숫자가 더 크게 나오는 경우
- 관계가 복잡한 JOIN에서 중복이 생겨 합계/카운트가 부풀어 오르는 경우
이런 케이스는 실행 자체는 성공하므로, 오히려 운영 신뢰를 더 크게 흔들었습니다. 정답이 아닌데도 자신 있게 말하는 답은 사용자 입장에서 가장 다루기 어렵습니다.
처음에는 이 문제를 프롬프트 개선으로 해결하려고 했습니다. 스키마를 프롬프트에 넣고, 예시(SQL few-shot)를 늘리고, 금지 규칙을 덧붙이는 방식이었습니다. 하지만 의미 문제는 단순히 지식을 더 많이 넣는다고 해결되지 않았습니다.
- 정의는 계속 변합니다: 지표 정의, 예외 규칙, 대시보드 필터는 운영 중에도 바뀌고, 프롬프트는 그 변화를 따라가기 어렵습니다.
- 정의는 텍스트만이 아닙니다: 표준 정의는 문서, 대시보드, 운영 관례에 흩어져 있고, 어디를 근거로 삼았는지가 중요합니다.
- 오답의 원인을 분해하기 어렵습니다: 정의가 틀린 것인지, 근거가 빠진 것인지, SQL이 어긋난 것인지가 한 덩어리로 섞이면 개선이 느려집니다.
결국 이 문제를 풀기 위해서는 의미를 책임지는 지점을 분해해 개선 단위를 만들고, 그 단위가 참고할 수 있는 근거를 애플리케이션 안으로 끌어오는 두 가지가 동시에 필요했습니다. 이 두 축이 아래의 A2A 역할 분리와 온톨로지 기반 RAG로 이어집니다.
문제 2: LLM이 생성한 SQL을 그대로 실행할 수 없다
대화형 BI는 결국 ‘쿼리 실행’까지 가야 가치가 생깁니다. 그런데 운영 환경에서는 다음과 같은 리스크가 항상 따라옵니다.
- 권한: 사용자에게 허용되지 않은 리소스(예: 특정 서비스 범위)를 조회할 수 있음
- 개인정보 및 민감정보:
SELECT *또는 컬럼 선택 실수로 개인 식별자 계열 컬럼이 노출될 수 있음 - 리소스 사용: 과도하게 넓은 기간이나 큰 테이블 JOIN으로 실행 비용이 커지거나 서비스 안정성에 영향을 줄 수 있음
이런 리스크는 프롬프트만으로 안정적으로 통제되기 어렵습니다. 운영에서는 가끔 발생하는 예외가 결국 언젠가 터지는 사고가 됩니다.
정리하면, 의미(정확도)와 안전(정책과 권한)은 서로 다른 성질의 문제입니다. 저희는 이 문제를 하나의 프롬프트에 몰아넣기보다, 의미를 다루는 A2A 프로토콜 기반 에이전트 역할 분리와 온톨로지 기반 RAG, 실행을 통제하는 Query Guardrail이라는 세 가지 접근으로 나눠 풀었습니다.
A2A 프로토콜 기반으로 에이전트 역할 분리
가장 먼저 한 일은 대화형 BI에 필요한 판단을 하나의 에이전트에 맡기지 않고, 책임 단위로 나누는 것이었습니다.
왜 도메인 전문성의 분리가 필요했나
대화형 BI는 표면적으로는 SQL 생성처럼 보이지만, 운영에서는 결국 도메인 정의와 운영 정책의 문제로 돌아옵니다. 예를 들어 전환율, 활동 유저, 리텐션 같은 표현은 누구나 쓰지만, 조직마다 표준 정의와 예외 규칙이 다릅니다.
이 정의와 규칙이 에이전트 내부에 뒤섞이면, 개선이 누적될수록 프롬프트는 비대해지고, 문제가 발생했을 때 원인도 분해하기 어려워집니다.
또한 작은 수정이 전체 회귀로 이어져, 개선 비용이 증가하고 점점 보수적으로 변하게 됩니다. 그래서 저희는 구조부터 바꿨습니다.
A2A로 에이전트 간 계약을 표준화하기
그래서 저희는 역할을 분리하고, 에이전트 간 통신을 A2A(Agent-to-Agent) 오픈 프로토콜로 표준화했습니다. 핵심은 ‘에이전트를 많이 만든다’가 아니라, 각 에이전트가 어떤 입력을 받고 어떤 출력에 책임지는지를 계약처럼 명확히 만드는 것입니다.
- 입출력 스키마: 질문 요약, 근거 묶음, SQL 후보, 검증 결과, 사용자 메시지
- 실패 표현: 근거 부족, 정의 충돌, 권한 위반, 리소스 위험 등을 서로 다른 실패 유형으로 구분
- 근거 전달: 최종 답변뿐 아니라 왜 그렇게 해석했는지에 대한 근거도 함께 전달
- 개입 지점: 특정 단계의 결과를 사람이 검토하거나 수정할 수 있게 하는 개입 지점(예: SQL 실행 전 승인)
역할 분리의 기준: 전문성의 경계
운영에서 발생하는 실패 유형을 관찰해 보면 대체로 아래 중 하나로 수렴합니다.
- 정의 및 의미 해석 실패: 지표 정의, 기본 제외 조건, 기간 해석이 흔들림
- 근거 부족: 필요한 문서와 대시보드 맥락이 누락되어 추측으로 답을 만듦
- SQL 실패: JOIN, 중복 제거, 필터 반영이 불완전하거나 성능이 불안정
- 정책 실패: 권한 또는 리소스 제한을 위반
- 커뮤니케이션 실패: 결과만 던지고 근거와 재현성이 남지 않음
그래서 저희 대화형 BI 애플리케이션은 이 전문성 경계를 따라 에이전트를 분리했습니다.
- Domain Agent: 지표, 세그먼트 정의, 해석 규칙을 책임지고, 결과 해석에서 반드시 지켜야 할 기본 조건을 제안
- Retrieval Agent: 온톨로지와 메타데이터 인덱스에서 근거를 구성하고, 근거 부족을 명시적으로 반환
- SQL Agent: 근거를 반영해 실행 가능한 SQL 후보를 만들고, 중복, 필터, 기간 규칙을 일관되게 적용
- Guardrail/Policy 에이전트: 실행 전 정책(RLS, CLS, 리소스)을 강제하고, 위반 시 수정 힌트를 구조화해 반환
- Report Agent: 결과를 재사용 가능한 형태(요약과 리포트)로 정리해 커뮤니케이션 비용을 낮춤
이렇게 나누면 각 에이전트가 책임지는 규칙과 실패 유형이 명확해지고, 개선이 필요한 지점을 단계별로 분해해서 다룰 수 있습니다. A2A 계약이 유지되는 한, 특정 에이전트의 내부 구현(프롬프트 및 도구 체인)을 교체하더라도 전체 시스템의 회귀를 줄일 수 있습니다. 또한 각 분야의 전문가가 전체 시스템을 몰라도 자신의 에이전트를 개선하고 배포할 수 있는 환경을 구축했습니다.
아래는 A2A 기반 에이전트 역할 분리의 전체 구조입니다.
Langflow + AI Admin으로 에이전트를 제품화하기
역할 분리만으로는 충분하지 않습니다. 분리된 에이전트가 운영에서 실제로 가치가 있으려면 개발, 검증, 배포 흐름이 갖춰져야 합니다.
저희 실에서 운영하고 있는 사용자 친화적인 UI 기반 AI Admin 시스템을 활용하여 아래와 같은 파이프라인으로 에이전트를 제품화할 수 있었습니다.
- 개발: Langflow로 플로우(프롬프트, 도구 연결, 출력 스키마)를 시각적으로 구성
- 검증: 샘플 질문 세트로 최소 품질 확인(회귀 방지)
- 배포: AI Admin에서 flow ID로 버전 관리하고 런타임에서 호출
이 방식의 장점은 코드 배포와 플로우 배포의 리듬을 분리해, 작은 개선을 더 자주 안정적으로 가져갈 수 있다는 점입니다. 특히 도메인 규칙은 자주 바뀌고(지표 정의, 예외), 그 변화를 빠르게 반영할수록 운영 품질이 올라갑니다.
다만 역할을 나누는 것만으로는 충분하지 않았습니다. 각 에이전트가 같은 기준으로 판단하려면, 공통으로 참조할 수 있는 지식 기반이 필요했습니다. 다음 섹션에서는 그 기반이 된 온톨로지 기반 RAG를 설명하겠습니다.
온톨로지 기반 RAG 구축
역할을 분리해도, 에이전트가 참고할 근거가 없다면 여전히 그럴듯한 오답은 줄지 않습니다. 그래서 두 번째 축은 ‘데이터의 의미(정의, 관계, 기본 규칙)를 전달하는 지식 기반’이었습니다.
여기서 중요한 포인트는 SQL을 더 잘 만들기만이 아니라, SQL 기반 데이터 조회에 더해 연관 지식 검색까지 함께 제공해 맥락의 부재와 지식의 단절을 줄이는 것이었습니다. 이를 위해 RAG는 크게 두 역할을 동시에 수행합니다.
쿼리 구체화: 질문에 없는 조건을 메타데이터로 채우기
운영에서 자주 등장하는 질문은 의외로 단순합니다. 예를 들어 “A 이벤트 효과 어땠어?” 같은 질문은 자연스럽지만, SQL로 옮기려면 최소한 아래가 필요합니다.
- 이벤트 기간(시작과 종료)
- 대상(어떤 게임 또는 서비스인 지)
- 평가 기준 KPI(전환, 매출, 잔존 등)
이때 사용자가 매번 기간과 대상을 명시하도록 요구하면 대화형의 장점이 줄어듭니다. 그래서 이벤트/캠페인 등 도메인 객체의 메타데이터를 먼저 조회해, 기간 및 대상 조건을 자동으로 도출하고 SQL에 반영하는 방식으로 쿼리를 구체화합니다.
지식 검색: 수치 해석에 필요한 정의/배경/맥락을 함께 제공
같은 질문에서도 사용자가 원하는 건 ‘숫자 한 줄’이 아닐 때가 많습니다. 특히 회고, 리뷰, 의사결정 문맥에서는 ‘이 수치가 왜 이렇게 나왔는가’를 설명할 근거가 필요합니다.
그래서 RAG는 KPI를 조회하는 것과 동시에, 관련된 용어 정의, 프로모션/이벤트 문서, 대시보드 설명, (필요 시) 외부 시장 자료 등을 검색해 답변에 함께 제공합니다. 결과적으로 자연어 질문 하나로 수치와 배경을 함께 얻을 수 있습니다.
아래 예시는 이벤트 효과를 묻는 질문이 쿼리 구체화와 지식 검색을 거쳐 처리되는 흐름을 보여줍니다.
이 두 가지 역할을 가능하게 하는 기반이 바로 온톨로지 기반 RAG입니다.
온톨로지: 정의, 관계, 규칙을 검색 가능한 형태로 만들기
분석에 필요한 정보는 단일 DB에 존재하지 않습니다. 스키마 메타데이터, 대시보드 설명, 용어집, 이벤트 문서, 외부 시장 데이터는 서로 긴밀하게 연관되어 있지만, 형식과 저장 위치, 갱신 주기는 제각각입니다. 이를 그대로 LLM에 투입하면 노이즈가 커지고, 소스별로 분리 처리하면 데이터 간 연결이 끊어집니다.
이 문제를 해결하기 위해 Ontology DB를 구축했습니다. Tableau, OpenMetadata 등 다양한 소스에서 데이터를 수집해 공통 스키마로 정규화해 중앙화하고, 단순한 데이터 집합이 아닌 데이터 간 의미와 관계를 구조적으로 정의하는 것에 초점을 뒀습니다.
예를 들어 특정 지표가 어떤 대시보드에서 어떻게 정의되는지, 어떤 이벤트 및 게임과 연결되는지를 구조적으로 연결해, 질문에 필요한 정보를 여러 소스에서 결합해 제공할 수 있도록 했습니다. 단순히 문서를 잘 찾는 RAG가 아니라, 데이터 간 의미와 관계를 먼저 정의한 뒤 검색하는 온톨로지 기반 RAG가 필요했던 이유입니다.
아래는 각 데이터 소스가 도메인별로 정규화되는 구조입니다.
정규화된 데이터는 온톨로지로 연결되어, 지표와 이벤트, 게임, 대시보드 간 관계를 표현합니다.
왜 Graph DB 대신 Vector DB로 시작했나
온톨로지로 데이터 간 관계를 정의한다고 하면 Graph DB가 먼저 떠오를 수 있습니다. 관계를 노드와 엣지로 명시적으로 표현하는 Graph DB는 이 구조에 이상적으로 보이 지만, 저희는 우선 Vector DB 기반으로 시작하는 결정을 내렸습니다.
이유는 실용적인 것이었습니다. Graph DB는 스키마 설계와 관계 정의에 필요한 초기 투자 비용이 크고, 어떤 관계가 실제 질의 품질에 영향을 미치는지 충분히 검증되지 않은 시점에서 그래프 모델을 먼저 확정하는 것은 리스크가 있었습니다. 반면 공통 스키마로 정규화된 문서에 연관 노드 참조를 텍스트로 포함시켜 임베딩하는 방식은 빠르게 시작할 수 있었고, 의미적 연결도 어느 정도 표현할 수 있었습니다.
다만 한계도 분명했습니다. 관계가 명시적으로 정의되어 있지 않다 보니, 2~3홉 떨어진 간접 관계를 LLM이 추론에 의존해 채워야 했고, 그 과정에서 답변 정확도가 불안정해졌습니다. 이 경험은 온톨로지 설계에서 어떤 관계를 먼저 정의해야 하는지에 대한 기준이 되었고, 이후 Graph DB 도입 시 그래프 스키마 설계의 토대가 될 예정입니다.
Retrieval 동작 방식
구축한 Ontology DB를 실제 질문에 활용하는 방식은 세 단계로 이루어집니다.
Ontology Routing
사용자의 질문이 들어오면 먼저 Intent Parser가 질문의 의도와 핵심 용어를 추출합니다. Ontology Router는 이를 바탕으로 Ontology Metadata의 Entity-Relation Mapping을 참조해, 질문에 답하기 위해 어떤 데이터 도메인과 인덱스를 검색해야 하는지 Retrieval Plan을 수립합니다. 어떤 데이터를 찾을지보다 어디에서 찾을지를 먼저 결정하는 단계입니다.
Dual-track Retrieval
Retrieval Plan을 받은 Retriever 에이전트는 두 가지 방향으로 동시에 동작합니다.
하나는 OpenSearch의 하이브리드 검색(키워드와 의미 기반 검색)으로 관련 문서를 수집하는 것이고, 다른 하나는 질의가 지표 계산을 요구할 경우 검색된 맥락을 바탕으로 집계 조건(기간, 게임, 지표 정의)을 구체화해 SQL 생성에 전달하는 것입니다. 지식 검색과 쿼리 구체화, 앞서 언급한 두 역할이 이 단계에서 함께 실행됩니다.
Grounded Answer
Answer Composer는 Retriever Agent로부터 받은 검색 컨텍스트와 집계 결과를 결합해 최종 답변을 생성합니다. 이때 답변에 사용된 데이터 소스를 함께 제시함으로써, 사용자가 근거를 확인하고 필요하면 직접 검토할 수 있도록 했습니다.
이렇게 온톨로지 기반 RAG로 의미를 보강해도, 생성된 SQL을 실제로 실행하는 순간에는 별도의 안전장치가 필요했습니다. 다음 섹션에서는 실행 전 SQL을 검증하는 Query Guardrail을 설명하겠습니다.
Query Guardrail 개발
두 번째 문제(안전한 실행)는 결국 프롬프트가 아니라 시스템이 책임져야 한다고 결론 내렸습니다. 그래서 쿼리 실행 직전에, 독립 서비스에서 SQL을 검증해 차단하거나 피드백을 제공하는 Query Guardrail을 만들었습니다. 여기서 Guardrail은 단순한 차단기가 아니라, 대화형 BI에서 신뢰를 만들기 위한 피드백 루프의 한 축이었습니다.
서비스 형태: REST + MCP 도구
Query Guardrail은 독립 API로 구성되어 있고, 두 가지 형태로 호출할 수 있습니다.
- REST: 애플리케이션 서버가 실행 직전에 호출하기 좋은 인터페이스
- MCP 도구: 에이전트가 도구 호출로 검증을 요청하고, 실패 시 피드백을 읽어 스스로 수정하기 좋은 인터페이스
동일한 검증 로직을 시스템 경로(실행 전 강제)와 에이전트 경로(자기 수정 루프)에서 모두 재사용할 수 있게 설계했습니다. 운영에서는 이 차이가 큽니다. 차단만 하면 사용자 경험이 나빠지고, 피드백이 없으면 개선 속도가 느려집니다.
검증 로직: RLS + CLS
- RLS(Row-Level Security): 사용자가 허용된 리소스 범위만 조회하는가?
- CLS(Column-Level Security): 개인 식별자 계열 등 민감 컬럼이 노출되는가?
RLS: 접근 리소스 목록을 구해 권한과 대조한다
RLS를 단순한 규칙(문자열 매칭)으로 처리하면 우회가 너무 쉽습니다. 그래서 SQL을 파싱해 ‘접근 리소스 목록을 반환하는 쿼리’로 재작성하고, 실행 결과를 사용자 권한과 대조하는 방식으로 설계했습니다.
CLS: 최종 노출 컬럼 집합을 계산한다
컬럼 수준 검증은 SELECT * 확장, 별칭, 서브쿼리까지 고려한 최종 노출 컬럼 집합을 계산해 민감 컬럼이 노출되는지 판단합니다. 문자열 매칭은 누락이 생기기 쉽고, 운영에서는 ‘언젠가 터지는 문제’가 됩니다.
차단 메시지: 사용자도, 에이전트도 이해할 수 있어야 한다
Guardrail이 단순히 ‘권한 없음’만 반환하면, 사용자는 무엇을 고쳐야 할지 알기 어렵습니다. 에이전트도 마찬가지입니다. 그래서 Guardrail 응답에는 다음을 포함하도록 했습니다.
- 어떤 정책을 위반했는지(RLS, CLS, 리소스)
- 어떤 리소스 또는 컬럼이 문제였는지(요약)
- 수정 방향 힌트(필수 필터 키, 금지 컬럼 계열 등)
정리하면, 역할 분리로 개선 단위를 만들고, 온톨로지 기반 RAG로 의미를 공급하고, Guardrail로 안전을 강제하는 방식으로 운영 가능한 신뢰에 필요한 세 축을 채웠습니다.
세 가지 접근 방법 도입 결과
앞서 소개한 세 가지 접근 방법은 각각 독립된 기능이 아니라, 실제 서비스에서 하나의 대화 흐름 안에서 함께 동작합니다. 사용자가 질문을 입력하면 요청이 적절한 에이전트로 라우팅되고, 온톨로지 기반 RAG로 맥락이 보강되며, 생성된 SQL은 실행 전 Query Guardrail 검증을 거칩니다.
아래는 실제 동작 예시입니다. 이벤트 KPI를 묻는 질문이 들어오면 A2A를 통해 이벤트 내용을 검색하는 에이전트와 쿼리를 작성하는 에이전트가 함께 호출되고, 수치와 맥락이 결합된 분석 답변이 반환됩니다. 개인정보 및 보안 정책을 위반하는 질문에는 실행이 차단되고 그 이유가 명확하게 전달됩니다.
정식 릴리스 이후 가장 먼저 체감한 변화는 반복 문의와 수작업 리포팅 부담이 일부 줄어들기 시작했다는 점입니다. 매주 같은 지표를 뽑아 정리하던 작업이나 담당자에게 반복해서 물어보던 질문 중 일부가 대화 한 줄로 해결되기 시작했습니다. 분석 결과와 함께 쿼리를 숨기지 않고 보여주며 사람이 직접 확인하고 수정할 수 있도록 한 것이 사용자 신뢰를 높이는 데 기여했습니다.
이렇게 저희는 세 가지 접근 방법을 기반으로, 데이터에 익숙하지 않은 사용자도 자연어 질문 하나로 수치와 맥락을 함께 얻을 수 있는 환경을 만들어가고 있습니다.
마치며
이 글의 세 가지 접근은 결국 세 가지 키워드로 정리됩니다. 의미(Meaning)는 온톨로지 기반 RAG로 지표 정의와 배경을 근거로 공급해 ‘그럴듯한 오답’을 줄이는 것이고, 안전(Safety)은 Query Guardrail로 실행 전 검증을 강제해 권한, 민감정보, 리소스 리스크를 시스템 차원에서 통제하는 것이며, 구조(Structure)는 A2A 기반 역할 분리로 전문성 경계에 따라 에이전트의 책임을 나눠 개선과 회귀를 관리 가능한 형태로 만드는 것이었습니다.
이번 작업을 통해 가장 크게 깨달은 것은, 대화형 BI의 신뢰는 모델이 아니라 설계에서 온다는 점입니다. 더 좋은 모델을 쓰는 것보다, 의미를 책임지는 구조를 만들고 안전을 시스템으로 강제하는 것이 운영 가능한 신뢰에 더 가까웠습니다.
완성된 이야기라기보다는 현재 진행형에 가까우며, 앞으로도 사용자 피드백을 반영하며 계속 발전시켜 나갈 계획입니다.
긴 글 읽어주셔서 감사합니다.
