10월 27일 화요일

AI 도입을 성과로 바꾸려면 조직은 구매보다 어떤 업무 검증, 책임, 전환 조건을 먼저 설계해야 하는가?

오늘의 다섯 신호를 한 흐름으로 읽으면, AI 도입의 핵심은 성능이 높아졌다는 사실보다 그 변화가 실제 업무의 어느 지점을 통과해 결과가 되는지 확인하는 데 있다. 기술 대기업을 묶은 Mag 7에서는 직원당 매출과 이익률 개선이 관찰됐지만, 나머지 S&P 493 기업과 거시 생산성 지표에서는 뚜렷한 성과가 보이지 않았고 지출도 소수 기업에 집중돼 있었다. 이는 일반 기업이 값이 내려가는 AI를 샀다는 사실만으로 매출과 이익이 따라오지 않는다는 경고로 읽힌다. 같은 날 소개된 도구들은 이 간극을 더 구체적으로 보여준다. AI가 만든 코드를 사람이 이해했는지 푸시 전에 묻는 장치, 여러 문서 형식을 업무에 쓰기 좋은 형태로 바꾸는 파서, 검색 결과에서 근거 구절까지 좁히는 재정렬 모델, 특정 연산의 처리량을 크게 올려도 다른 작업은 거의 빨라지지 않는 사례가 나란히 놓였다. 공통점은 도구의 존재가 아니라 검증할 업무 단위가 분명하다는 것이다. 누가 무엇을 이해해야 하는지, 어떤 입력을 바꿔야 하는지, 어느 결과를 정확도·비용·속도로 확인할지, 개선되지 않는 병목은 무엇인지가 정해질 때 기술 변화가 운영 변화로 이어진다.

1. 01

   성과가 안 보일 때 기능보다 흐름을 본다

   기술업계 밖의 AI 성과가 아직 뚜렷하지 않다는 관찰은 도입을 멈추라는 결론이라기보다 측정 대상을 다시 고르라는 신호다. 조직 전체의 막연한 생산성을 곧바로 기대하면 어느 팀의 어떤 일이 달라졌는지 설명하기 어렵다. 반대로 입력, 판단, 산출, 검토로 이어지는 한 업무 흐름을 정하면 AI가 시간을 줄였는지, 결과의 품질을 바꿨는지, 사람의 재작업을 늘렸는지를 구분할 수 있다. 지출이 소수 기업에 집중됐다는 사실까지 함께 보면, 일반 기업의 과제는 규모를 흉내 내는 것이 아니라 저렴해지는 기술을 자기 매출과 이익의 경로에 붙이는 일이다. 따라서 도입안에는 제품 이름보다 바뀔 업무, 확인할 결과, 중단할 조건이 먼저 적혀야 한다.

2. 02

   사람의 이해를 배포 조건으로 만든다

   Sphinx는 AI가 작성한 코드를 곧바로 통과시키지 않고 Git 푸시를 잠시 멈춘다. 별도 리뷰어 모델이 상황형 질문을 만들고, 개발자는 코드와 변경 내역을 보며 동작과 실패 조건을 설명한다. 틀리면 같은 답을 외우게 하는 대신 다른 상황으로 다시 묻는다. 여기서 업무 설계의 핵심은 퀴즈라는 형식이 아니라 산출물을 승인할 사람이 그것을 이해했는지를 과정 안에서 확인한다는 점이다. AI가 일을 대신했다는 이유로 책임까지 사라지는 것은 아니다. 오픈북 검증처럼 실제 자료를 보며 설명하게 하면 속도와 이해를 함께 다룰 수 있다. 조직은 생성량만 세기보다, 담당자가 실패 조건을 말할 수 있는지와 수정 판단을 내릴 수 있는지를 완료 기준에 넣을 수 있다.

3. 03

   입력 정리가 자동화의 범위를 결정한다

   kordoc은 HWP·HWPX뿐 아니라 PDF, 오피스 문서, 이미지까지 Markdown이나 JSON으로 바꾸고 병합된 표 구조와 로컬 OCR을 지원한다. 이 사례는 AI 활용 전에 문서가 읽히고 구조가 보존되어야 한다는 현실을 드러낸다. 고객 문서나 사내 자료가 여러 형식에 흩어져 있다면, 질문을 잘 만드는 것보다 먼저 입력을 일관된 형태로 바꾸는 단계가 필요하다. 동시에 한컴 DRM 문서는 처리하지 못한다는 한계가 명시돼 있다. 운영자는 지원 형식만 볼 것이 아니라 제외되는 문서가 핵심 업무에 얼마나 많은지 확인해야 한다. 변환 성공 여부, 표 구조 보존, 로컬 처리 필요, 처리 불가 문서의 우회 절차까지 정해야 자동화 범위가 과장되지 않는다.

4. 04

   좋은 검색은 답보다 근거를 좁힌다

   Cohere의 Rerank 5는 검색 결과의 순서를 다시 매기고 Context Focus로 문서 안의 핵심 근거 구절까지 추린다. 공급사가 공개한 평가에서는 정답률이 46%에서 58%로 높아졌고, 검색 에이전트가 쓰는 토큰은 35% 감소했다. 이 수치는 공급사의 자체 평가라는 경계를 지닌다. 그래도 업무 관점의 질문은 분명하다. 더 많은 문서를 넣는 것이 아니라, 사람이 확인할 근거를 더 짧고 정확하게 제시할 수 있는가다. 고객 응대나 내부 조사에 적용한다면 평균적인 정답률 하나만 보지 말고, 근거 구절이 실제 문서와 맞는지, 줄어든 입력량이 중요한 맥락을 버리지 않는지, 빠른 모델과 정교한 모델 가운데 어느 쪽이 업무 조건에 맞는지 따로 확인해야 한다.

5. 05

   성능 향상은 병목을 옮길 뿐일 수 있다

   GPU-unlock 사례에서 RTX 3090 Ti의 BF16 처리량은 87.50에서 157.41 TFLOPS로 늘었지만, 메모리 대역폭에 묶인 언어 모델의 토큰 생성과 INT8 작업은 거의 개선되지 않았다. 한 수치의 큰 상승을 업무 전체의 속도 향상으로 번역하면 안 된다는 뜻이다. 조직이 확인할 것은 최고 처리량이 아니라 실제로 기다리는 단계가 무엇인지다. 연산 제한이 풀려도 데이터 이동이나 다른 작업 방식이 병목이라면 사용자가 느끼는 대기 시간은 그대로일 수 있다. 도입 검토에서도 같은 원칙이 필요하다. 기능 시연의 가장 좋은 수치보다 자기 업무의 입력, 처리, 검토 가운데 가장 느린 구간을 찾고, 그 구간이 바뀌었을 때만 성과로 인정해야 한다.

다섯 신호가 제안하는 도입 순서는 단순하다. 먼저 한 업무 흐름과 원하는 결과를 정하고, 사람이 산출물의 동작과 실패 조건을 설명할 수 있게 하며, 실제 문서 입력의 지원 범위와 예외를 확인한다. 그다음 검색의 근거 품질과 비용 절감처럼 결과에 가까운 지표를 재고, 가장 화려한 성능 수치가 아니라 현장의 병목이 줄었는지 본다. Mag 7과 나머지 기업 사이의 차이는 모든 조직에 같은 처방을 주지 않는다. 다만 AI 지출을 성과로 바꾸는 과정이 구매 뒤에 시작된다는 점은 보여준다. 작은 업무 단위에서 이해, 근거, 예외, 병목을 함께 기록할 수 있을 때 조직은 확대 여부를 판단할 수 있고, 고객에게도 무엇이 좋아졌으며 어디까지 책임질 수 있는지 설명할 수 있다. 이 조건이 없다면 기술은 새로워져도 일의 결과는 달라졌다고 말하기 어렵다. 첫 적용을 고를 때도 질문은 구체적이어야 한다. 담당자가 산출물을 설명할 수 있는가, 변환하지 못하는 입력은 무엇인가, 제시된 근거를 원문에서 확인할 수 있는가, 빨라진 연산이 실제 대기 구간인가를 기록한다. 네 질문 가운데 답하지 못한 항목이 있다면 확대보다 그 빈칸을 먼저 검증하는 편이 오늘 자료가 허용하는 신중한 선택이다. 이 기록은 도구를 계속 쓸지, 범위를 줄일지, 다른 흐름을 시험할지 결정하는 공통 언어가 된다.