AI 도입에는 느낌(vibes)이 아닌 증거가 필요합니다

다음 단계의 진정한 AI 우위는 가장 시끄러운 데모를 보여주는 팀에서 나오지 않을 것입니다. 그것은 AI가 실제로 업무를 어떻게 변화시키는지 증명할 수 있는 팀에서 나올 것입니다.

이것이 바로 당신이 경제학자가 아니더라도 OpenAI의 새로운 경제 연구 교환(Economic Research Exchange)을 주목해야 하는 이유입니다. OpenAI는 이를 일자리, 생산성, 그리고 더 넓은 경제에 미치는 AI의 영향을 연구하기 위한 방법으로 정의했습니다. OpenAI의 새로운 공익 로드맵(public-benefit roadmap) 및 기밀 S-1 신고서(S-1 filing)와 함께 살펴보면 신호는 명확합니다. AI는 모델의 구경거리(model spectacle) 단계에서 책임성(accountability) 단계로 이동하고 있습니다. 투자자, 규제 기관, 기업, 그리고 노동자들은 이제 더 어려운 질문을 던질 것입니다. "AI 때문에 무엇이 변했는가?"

빌더(Builders)들은 다른 모든 사람들이 대신 질문하기 전에 스스로 같은 질문을 던져야 합니다.

느낌(vibe)에 기반한 AI 출시 방식은 한계에 직면하고 있습니다

대부분의 AI 도입은 여전히 일련의 어지러운 일화(anecdotes)들로 시작됩니다. 누군가는 코딩 어시스턴트(coding assistant)가 더 빨라진 것 같다고 말합니다. 지원 팀은 요약 기능이 시간을 절약해 준다고 말합니다. 창업자는 에이전트(agents)가 곧 워크플로우(workflow)를 대체할 것이라고 말합니다. 그중 일부는 사실입니다. 일부는 전략으로 포장된 희망 사항일 뿐입니다.

문제는 열정이 아닙니다. 문제는 약한 측정(weak measurement)입니다. 만약 개발자가 AI를 사용하여 기능을 2시간 더 빨리 출시했지만 미묘한 보안 버그(security bug)를 만들었다면, 생산성이 향상된 것일까요? 만약 마케팅 팀이 3개 대신 10개의 초안을 생성했지만 동일한 양의 유용한 결과물을 게시했다면, 그 도구는 가치가 있었을까요? 만약 고객 서비스 상담원이 더 많은 티켓(tickets)을 처리했지만 에스컬레이션(escalations)이 증가했다면, 모델이 정확히 무엇을 개선한 것일까요?

AI는 진정으로 유용할 수 있으면서도 여전히 잘못 측정될 수 있습니다. 그것이 더 많은 팀이 머물러야 할 불편한 중간 지대입니다.

OpenAI의 연구 추진이 빌더들에게 의미하는 바

OpenAI의 경제 연구 교환(Economic Research Exchange)은 노동 시장, 생산성, 일자리, 그리고 경제적 결과와 같은 더 큰 질문들을 목표로 합니다. 하지만 개발자와 제품 팀을 위한 실질적인 교훈은 더 작고 날카롭습니다. AI 기능을 장식(decorations)이 아닌 개입(interventions)으로 취급하십시오.

"AI를 추가해야 할까요?"라고 묻는 대신, 다음과 같이 물으십시오:

어떤 작업이 더 쉽고, 빠르고, 안전하며, 저렴해집니까?
모델이 워크플로 (workflow)에 진입하기 전과 후에 사용자는 무엇을 합니까?
추천사 (testimonial)에 의존하지 않고 개선 사항을 증명할 수 있는 지표 (metric)는 무엇입니까?
AI가 조용히 실패할 수 있는 지점은 어디이며, 우리는 그것을 어떻게 포착할 것입니까?

그러한 사고방식은 제품 브리프 (product brief)를 변화시킵니다. 코드 리뷰 어시스턴트 (code-review assistant)는 단순히 코멘트를 생성하는 것에 그쳐서는 안 됩니다. 리뷰 대기 시간을 줄이고, 반복되는 결함 유형을 잡아내며, 개발자들이 무시하게 되는 소음 섞인 제안을 피해야 합니다. 문서 에이전트 (document agent)는 단순히 질문에 답하는 것에 그쳐서는 안 됩니다. 출처를 인용하고, 불확실성을 보여주며, 사용자가 의사결정을 내리는 데 걸리는 시간을 단축해야 합니다. 영업 어시스턴트 (sales assistant)는 단순히 이메일을 작성하는 것에 그쳐서는 안 됩니다. 모든 메시지를 일반적인 쓰레기 (sludge)로 만들지 않으면서 응답 품질을 향상시켜야 합니다.

AI 워크플로를 위한 간단한 측정 루프 (measurement loop)

실제 워크플로에 AI를 추가하고 있다면, 지루한 기준점 (baseline)부터 시작하십시오. 여기서는 지루한 것이 좋습니다. 모델이 작업에 손을 대기 전의 현재 작업을 측정하십시오.

시간 (Time): AI 없이 해당 작업에 얼마나 오래 걸립니까?
품질 (Quality): 무엇이 좋은 결과물로 간주되며, 누가 그것을 판단합니까?
리스크 (Risk): 어떤 실수가 재작업, 고객 피해, 또는 보안 노출을 초래합니까?
채택 (Adoption): 사용자들이 새로움이 사라진 후에도 해당 도구를 계속 사용합니까?
비용 (Cost): 유용한 결과물 하나당 토큰 (token), 인프라 (infrastructure), 검토 및 지원 비용은 얼마입니까?

그런 다음 동일한 워크플로에 AI 버전을 실행하십시오. 모델의 정확도 (accuracy)만을 고립시켜 측정하지 마십시오. '인간+모델'로 구성된 전체 시스템을 측정하십시오. 많은 유용한 AI 도구들은 완전히 자율적이지 않습니다. 그것들은 레버리지 도구 (leverage tools)입니다. 즉, 인간이 더 빠르게 검색하고, 더 일찍 초안을 작성하며, 더 많은 사례를 검사하거나, 더 나은 초안을 만들 수 있도록 돕습니다.

그것 역시 여전히 가치가 있습니다. 하지만 정직한 회계 (accounting)가 필요합니다.

가장 강력한 AI 팀은 덜 마법처럼 보일 것입니다

이 부분은 모델 출시(model launches)와 비교했을 때 지루하게 느껴질 수도 있습니다. 승자들은 아마도 스프레드시트(spreadsheets), 평가 세트(evaluation sets), 리뷰 대기열(review queues), 감사 로그(audit logs), 그리고 불편한 사후 분석(postmortems)을 갖추고 있을 것입니다. 그들은 AI가 어디에서 도움이 되고 어디에서 도움이 되지 않는지를 알 것입니다. 그들은 데모(demo)는 잘 되지만 실제 운영(production) 환경에서는 실패하는 기능들을 폐기할 것입니다. 그들은 판단이 중요한 곳에는 인간을 루프 안에 유지(humans in the loop)하고, 실제로 반복 가능한 부분들은 자동화할 것입니다.

그렇다고 해서 AI가 덜 흥미로워지는 것은 아닙니다. 오히려 더 사용 가능하게(usable) 만드는 것입니다.

하이프 사이클(hype cycle)은 사람들에게 "모델이 무엇을 할 수 있는가?"라고 묻도록 가르쳤습니다. 다음 단계는 "워크플로(workflow)에서 무엇이 변했는가, 그리고 그것을 증명할 수 있는가?"라고 묻는 사람들에게 보상을 줄 것입니다.

빌더(builders)들에게 이것은 더 나은 질문입니다. 이는 AI를 반짝이는 부가 기능(add-on)에서 하나의 엔지니어링 규율(engineering discipline)로 탈바꿈시킵니다.

References

원문 게시 위치: https://blog.jenuel.dev/blog/ai-adoption-needs-evidence-not-vibes