[1부] AI 도입의 명과 암: 누구를 위한 AI인가

🤖 이 글에서 다루는 내용

• AI 도입으로 데이터 접근, 시각화, 원인 탐색은 어떻게 쉬워졌나
• 중의적인 질문에 조용히 틀리는 Lang2SQL과, 같은 지표를 다른 숫자로 보여주는 대시보드
• AI로 쓴 리포트를 AI로 읽게 되는 이유와, AI에 익숙하지 않은 동료에게 생긴 새로운 장벽
• 사내 AI의 고객은 동료이며, 교육과 흐르는 지식이 도입을 받쳐줘야 하는 이유

---

1. 이 글을 쓰게 된 이유

얼마 전 동료가 공유한 분석 리포트를 읽다가 멈칫했다. 지표 이야기로 시작했다가 갑자기 특정 세그먼트로 넘어가고, 어디서 나온 가정인지 모를 문장이 중간중간 끼어 있었다. 그래서 나는 그 리포트를 AI에게 넣고 이렇게 물었다.

이거 핵심만 요약해줘

 

그 순간 조금 이상한 기분이 들었다. 이 리포트는 AI와 대화하며 쓰였을 것이고, 나는 그걸 AI로 읽고 있다. 사람과 사람 사이의 소통에 AI가 양쪽으로 끼어 있는 셈이다.

 

돌아보면 AI를 도입하며 기대했던 것들은 꽤 많이 현실이 됐다. 그런데 운영을 해보니 데모에서는 보이지 않던 그림자도 따라온 것 같다. 나는 AI 도입을 총괄하는 사람이 아니고, 이 글도 데이터 조직 안에서 겪은 경험에 한정된다. 다만 AI를 매일 업무 도구로 쓰고, 직접 Lang2SQL을 만들어보기도 한 분석가로서 정리해볼 수 있는 지점은 있다.

 

그 전에 하나만 짚고 가자. 사내에서 AI로 만든 도구의 고객은 누구일까? 개인적으로는 Lang2SQL이든 대시보드든 AI 리포트든, 고객은 결국 함께 일하는 동료라고 생각한다. 이 글의 명과 암은 모두 이 질문을 기준으로 봤다.

 

이 도구는 동료의 업무 시간을 실제로 줄여주고 있는가?

---

2. 명(明): AI가 바꿔놓은 것들

2.1. Lang2SQL — 데이터 접근의 문턱이 낮아졌다

예전에는 데이터를 보려면 SQL을 알거나, SQL을 아는 사람에게 부탁해야 했다. 이제는 SQL을 모르는 구성원도 "지난달 신규 가입자 중 7일 안에 재방문한 비율은?" 같은 질문을 직접 던질 수 있다. 데이터 접근이 기술의 문제에서 질문의 문제로 옮겨간 느낌이다.

2.2. HTML 대시보드 — 시각화의 자유도가 높아졌다

BI SaaS 툴은 편리하지만, 툴이 허락하는 범위 안에서만 표현할 수 있었다. AI와 함께 HTML로 대시보드를 직접 만들면서 이 제약이 사라졌다. 예전 같으면 프론트엔드 개발자가 필요했을 일을 이제는 분석가가 직접 하고 있다는 게 아직도 좀 신기하다.

2.3. AI 드릴다운 — 문제를 찾기가 쉬워졌다

플랫폼의 거래액이 떨어졌을 때 지역별, 채널별, 가게 유형별로 쪼개보며 원인을 찾는 과정은 늘 고되다. AI를 활용한 드릴다운은 어느 차원에 변화가 몰려 있는지 빠르게 좁혀준다. 덕분에 사람은 "어디를 볼지"보다 "왜 그런지"에 더 많은 시간을 쓸 수 있게 됐다.

---

3. 암(暗): 기대와 달랐던 것들

3.1. Lang2SQL — 정말 생산성이 올랐을까

Lang2SQL을 쓰다 보면 가끔 멈칫하게 된다. 그런데 요즘 틀리는 지점은 지표 이름을 헷갈리는 단순한 실수가 아닌 것 같다. 사내 용어와 지표 정의를 잘 정리해두면 그런 실수는 거의 사라진다. 까다로운 건 질문 자체가 여러 갈래로 읽힐 때다.

쿠폰을 사용한 신규 고객의 주문 수 알려줘

 

 이 질문은 두 가지로 읽힌다. 쿠폰을 쓴 적 있는 신규 고객의 전체 주문일 수도 있고, 신규 고객의 주문 중 쿠폰이 적용된 주문일 수도 있다. 여기에 "지난달 신규 입점한 OD 가게를 기존 가게와 비교해서, 지역별로 전월 대비 증감까지" 같은 복합적인 요구가 한 문장에 담기면, 갈래는 더 늘어난다.

 

사람 분석가라면 여기서 되묻는다. 하지만 Lang2SQL은 그중 하나를 골라 조용히 답한다. 지난 글에서 AI는 불명확한 질문에 되묻거나 추측으로 답한다고 썼는데, Lang2SQL은 대개 후자였다. 그리고 그 추측은 그럴듯한 숫자로 나온다. 에러가 나면 차라리 다행이다. 틀린 숫자가 멀쩡하게 나오는 게 더 무섭다.

 

이렇게 보면 Lang2SQL의 정확도는 모델 성능만큼이나 질문이 얼마나 구조화되어 있는가에 달린 게 아닐까. 지난 글에서 정리한 명확한 질문의 5가지 요소(기간, 대상, 조건, 지표, 출력)가 여기서도 그대로 통한다. 문제는 Lang2SQL의 주 사용자가 바로 그 구조화에 익숙하지 않은 동료들이라는 점이다.

 

그래서 AI가 짠 쿼리를 사람이 다시 검토하게 된다. 그런데 SQL을 모르면 쿼리가 맞는지 스스로 판단할 수 없고, 결국 분석가에게 검토를 요청한다. 두 경우를 나란히 놓으면 차이가 선명하게 보인다.

 

	AI 도입 전	AI 도입 후
요청 문장	이 데이터를 뽑아주세요	AI가 뽑은 이 데이터가 맞나요?
분석가의 일	쿼리 작성	쿼리 해석 및 검증
요청자의 과정	요청 1번	AI 1번 + 검토 요청 1번
분석가 대기 시간	있음	여전히 있음

 

요청의 형태만 바뀌었을 뿐, 전문가에 대한 의존과 대기 시간은 여전히 존재한다. 게다가 처음부터 직접 짜는 것보다 남이 짠 쿼리를 검증하는 게 더 어려울 때도 많다.

 

이건 우리만의 고민이 아닌 듯하다. METR의 2025년 연구에서는 숙련된 오픈소스 개발자들이 AI 도구를 쓰자 작업 시간이 오히려 약 19% 늘었다. 그런데 참가자들은 AI 덕분에 약 20% 빨라졌다고 느꼈다. 전문가조차 체감과 실제가 어긋날 수 있다는 뜻이다. "AI를 쓰니까 빨라졌다"는 느낌만으로는 부족하다. 검토와 대기 시간까지 포함한 리드타임을 재봐야 할 것 같다.

3.2. HTML 대시보드 — 자유도는 곧 파편화였다

누구나 대시보드를 만들 수 있게 되자 대시보드가 빠르게 늘었고, 관리가 그 속도를 따라가지 못했다. 같은 명칭의 지표가 대시보드마다 조금씩 다르게 계산되고, 만든 사람이 자리를 옮기면 대시보드는 과거 로직으로 멈춘 채 돌아간다.

돌이켜보면 이건 SSOT(Single Source of Truth), 즉 하나의 지표는 하나의 정의에서 나와야 한다는 원칙이 무너진 문제에 가까운 것 같다. SaaS 툴에서는 대체로 미리 정의된 데이터셋과 지표를 거쳐서 차트를 만들었지만, HTML 대시보드는 각자 쿼리를 짜서 AI에게 넘기면 대시보드가 뚝딱 나온다. 자유도가 높아진 만큼 지표의 정의도 대시보드 수만큼 늘어난 셈이다. 그때는 SaaS 툴의 제약이 불편했지만, 그 제약이 일종의 표준 역할을 하고 있었던 것 같다.

그리고 이 문제는 3.1과도 이어진다. Lang2SQL이 중의적인 질문을 하나의 해석으로 골라 답하듯, 대시보드도 만든 사람의 해석대로 지표를 계산한다. 결국 "지난주 Net.GMV(실결제 거래액)가 얼마야?"라는 질문에 답이 여러 개 생기고, 어느 숫자가 맞는지 확인하는 일은 다시 분석가에게 돌아온다.

3.3. AI 리포트 — 쓰는 데 아낀 시간을 읽는 사람이 낸다

1장의 리포트는 왜 읽기 어려웠을까? AI와 분석하다 보면 대화를 따라 지표에서 지역으로, 지역에서 특정 가게 유형으로 분석이 이어진다. 그렇게 나온 리포트는 논리의 구조가 아니라 대화의 순서대로 전개된다. 대화에 없던 사람은 맥락을 쫓아갈 수 없으며, 같은 사람이 쓴 리포트도 그날의 대화에 따라 매번 구조가 다르다. 결국 작성자는 AI로 인코딩하고, 독자는 AI로 디코딩하는 지경에 이른 게 아닐까.

 

바깥에서도 비슷한 이야기가 나온다. 2025년 Harvard Business Review에 소개된 "워크슬롭(workslop)"은 그럴듯해 보이지만 알맹이가 부족해서, 받는 사람이 해석하고 보완하는 부담을 떠안게 되는 AI 결과물을 말한다. 응답자의 약 40%가 최근 한 달 안에 이런 결과물을 받았고, 한 건에 평균 2시간 가까이 썼다고 답했다. 작성자가 아낀 시간이 읽는 사람의 비용으로 넘어가고 있는 셈이다.

 

그렇다고 AI와 대화하며 분석을 넓혀가는 방식이 문제는 아니다. 문제는 확장한 것을 버리지 않는 것이다. 이 이야기는 다음 글에서 따로 풀어보려 한다.

3.4. AI 친화도 격차 — 새로운 장벽

AI에 능숙한 사람은 앞의 문제를 "AI로 요약하면 되지"로 넘길 수 있다. 하지만 AI 친화도가 낮은 동료에게 AI로 쓴 리포트는 읽기 어렵고, 그걸 읽으려고 AI를 써야 하는 상황은 한 번 더 어렵다. 데이터 접근의 장벽을 낮추려고 도입한 AI가, 역설적으로 정보 접근의 새로운 장벽이 되고 있는 건 아닐까.

---

4. 그래서, 무엇을 명심해야 할까

4.1. 선택받지 못하면 슬롭일 뿐이다

1장에서 이야기했듯, 사내 AI의 고객은 동료다. 아무리 훌륭한 기술이라도 동료가 쓰지 않으면 의미가 없다. 쓰이지 않는 대시보드, 끝까지 읽히지 않는 리포트, 결국 다시 검토해야 하는 쿼리는 슬롭(slop)일 뿐이다.

 

그래서 만든 개수가 아니라 쓰인 정도를 봐야 한다고 생각한다. 대시보드는 재방문율로, Lang2SQL은 결과를 고쳐 쓴 비율로, 리포트는 의사결정으로 이어졌는지로 본다.

4.2. 교육은 멈추지 않는다

도구만 던져주고 "알아서 쓰세요"는 잘 통하지 않는 것 같다. AI 친화도의 격차가 곧 정보 격차가 되는 만큼, 교육은 한 번의 설명회가 아니라 반복되어야 한다. "Lang2SQL 사용법"보다 "주간 Net.GMV를 Lang2SQL로 뽑고 검증하는 법"처럼, 도구가 아니라 업무 사례와 검증 습관을 가르쳐야 오래 남는다.

4.3. 흐르지 않는 지식은 죽은 지식이다

Lang2SQL이 틀리는 이유의 상당수는 모델이 아니라 맥락의 부재에서 온다. 지난 글에서도 이야기했듯이, 우리 조직에서 Net.GMV가 어떻게 정의되는지, OD가 무엇을 뜻하는지는 AI가 알 수 없다. 대시보드마다 숫자가 다른 것도 같은 이유다.

 

그리고 지식은 한 번 정리하면 끝이 아니다. 지표 정의를 한곳에 두고(SSOT) Lang2SQL과 대시보드가 함께 참조하게 하고, AI가 틀렸을 때 올바른 규칙이 다시 지식으로 돌아오는 경로를 만들어야 한다. 같은 실수가 반복된다면 모델보다 이 경로가 막혀 있는 건 아닌지 먼저 의심해봐야 한다.

 

그래서 요즘은 이 SSOT를 관리하는 역할이 더 중요해지고 있다고 느낀다. 데이터 엔지니어링이든 애널리틱스 엔지니어링이든 조직마다 이름은 다르겠지만, 지표의 정의를 만들고 지키는 사람들 말이다. AI 덕분에 쿼리와 대시보드를 만드는 비용은 거의 사라졌는데, 그만큼 "어느 숫자가 맞는가"를 보증하는 일의 가치는 오히려 커진 게 아닐까. 누구나 답을 만들 수 있는 시대일수록, 믿을 수 있는 정의를 쥐고 있는 쪽이 조직의 기준이 되는 것 같다.

 

사실 이 고민의 상당수는 내가 직접 Lang2SQL '알려조요'를 만들면서 하게 된 것이다. 이 이야기도 따로 풀어보려 한다.

---

5. 마치며 — 이 AI는 누구를 위한 것인가

AI는 데이터에 접근하는 문턱을 낮추고, 표현의 자유도를 높이고, 문제를 찾는 속도를 끌어올렸다. 그런데 돌아보면 그림자의 대부분은 기술이 아니라 사람과 사람 사이에서 생겼다. 쿼리를 검토해줄 사람을 기다리고, 남이 쓴 리포트를 해독하고, AI에 익숙하지 않은 동료가 뒤처진다.

 

그래서 AI 도입을 평가하는 질문은 "무엇을 만들었는가"가 아니라 "누가 쓰고 있는가"에 가까운 것 같다. 좋은 사내 AI는 만드는 사람을 빛나게 하는 기술이 아니라, 쓰는 동료의 시간을 돌려주는 도구일지도 모른다.

 

다음 글에서는 3.3에서 남겨둔 이야기, AI와 함께 넓힌 분석을 리포트에서 어떻게 좁힐 것인가를 다룬다.

 

 

---

참고 자료

• 데이터 협업이 느린 진짜 이유: 질문과 소통의 구조 (지난 글)
• AI 시대의 데이터 리터러시: 좋은 답은 좋은 질문에서 시작된다 (지난 글)
• METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.
• Niederhoffer, K. et al. (2025). AI-Generated "Workslop" Is Destroying Productivity. Harvard Business Review.