AI 도입에 관한 논의는 대개 이 한마디에서 시작됩니다.

회의록을 요약하는 에이전트,

문의에 답변하는 에이전트,

티켓을 자동으로 생성하는 에이전트.

만들어 보면 확실히 작동합니다.

편리합니다. 데모도 분위기가 달아오릅니다.

하지만 그 이후가 이어지지 않는 경우도 적지 않습니다.

우선 개인으로서 접해보는 것은 AI 활용을 조직으로 확산시키기 위한 필수적인 첫걸음입니다.

한편, 거기서 얻은 깨달음이 팀의 흐름이나 판단으로 연결되지 않은 채로 남아 있다면, 확산되더라도 단발적인 부분 적용에 그쳐 개선 효과도 한정적이기 쉽습니다. 몇 달 후에는 만든 본인만이 사용하고 있게 됩니다.

현장의 평가는 "편리하지만, 없어도 곤란하지 않다".

결과적으로 AI는 조직을 바꾸는 메커니즘이 아니라, 개인의 효율을 조금 높이는 도구로 끝나버리고 맙니다.

이 기사에서는 왜 그렇게 되기 쉬운지, 그리고 어떻게 하면 "편리한 도구"로 끝내지 않고 조직에 효과가 있는 형태로 만들 수 있는지 정리합니다.

이 기사를 통해 다음의 세 가지 질문에 답해 나가겠습니다.

• 태스크(Task) 단위의 자동화가 왜 조직의 성과로 이어지기 어려운가?
• 개인 이용에 머무는 에이전트와 조직에 효과적인 에이전트의 차이는 어디에 있는가?
• "편리한 도구"로 끝내지 않고 워크플로(Workflow), 의사결정, 지식(Knowledge)을 일체로 설계하려면?

AI 도입을 검토하면 자연스럽게 "무엇을 자동화할 수 있는가"라는 이야기가 됩니다.

이것은 출발점으로서 옳습니다.

다만, 여기서 사고가 멈추면 완성되는 것은 점의 자동화입니다.

예를 들어 "회의록을 요약한다"는 편리합니다.

하지만 그 요약이 다음 액션으로 이어지는지는 별개의 문제입니다.

담당자에게 공유되는지, 티켓이 되는지, 승인에 사용되는지, 나중에 검색할 수 있는지. 전후의 흐름이 설계되어 있지 않으면 성과는 한정적입니다.

즉, AI 에이전트가 처리하고 있는 것은 하나의 태스크일 뿐이며, 업무 전체의 흐름은 변하지 않았습니다. 그 때문에 개인의 작업 시간은 줄어들어도 팀의 연계나 조직의 스피드로 이어지기 어렵습니다.

여기서 다시 질문하고 싶은 것은 "이 AI는 무엇을 처리하는가"가 아니라, "이 AI는 누구의 어떤 흐름을 앞으로 나아가게 하고, 어떤 판단을 돕는가"입니다.

점의 자동화에 머무르면 정보는 다음 공정이나 의사결정에 도달하지 않습니다.

그렇기에 워크플로, 의사결정 프로세스, 지식을 일체로 설계하는 관점을 살펴볼 필요가 있습니다.

에이전트는 처음에 열의가 높은 사람이 만듭니다.

그러면 그 사람의 업무 맥락에 최적화된 설계가 되기 쉽습니다.

프롬프트(Prompt)도, 참조하는 정보도, 기대하는 출력도, 만든 사람의 머릿속에 있는 전제에 의존하게 됩니다.

그 결과, 다른 사람이 보기에는 "어떤 때에 사용해야 할지 모르겠다", "출력의 용도를 알 수 없다", "내 업무에는 맞지 않는다"라는 상태가 됩니다.

만든 사람에게는 편리해도 조직에는 확산되지 않는다.

이것은 AI의 성능 문제가 아니라, 설계 대상이 개인에게 닫혀 있는 것이 원인입니다.

AI 에이전트의 품질은 참조할 수 있는 정보의 품질에 강하게 의존합니다.

사내 문서가 산재해 있다, 최신 정보를 알 수 없다, 용어가 부문마다 다르다.

데이터 소스(Data Source)가 갖춰지지 않은 상태에서는 아무리 고성능 모델을 사용해도 돌아오는 답변은 무난하고 일반적인 내용이 되기 쉽습니다.

"AI를 도입했는데 기대만큼 똑똑하지 않다"라고 느끼는 장면의 대부분은 모델의 한계라기보다, 지식 기반(Knowledge Base, 데이터 소스)의 미비에 기인합니다. AI만 추가해도 토대가 약하면 품질은 안정되지 않습니다.

중요한 것은 **"어떤 작업(Task)을 AI로 자동화할 것인가"가 아니라 "어떤 업무를 변혁할 것인가"**입니다.

하나하나의 태스크를 개선하는 것도 물론 중요합니다. 하지만 그것만으로는 점의 개선에 머물고 맙니다. 업무 전체를 조망하며 AI를 전제로 업무를 재구성하는 것이 중요합니다.

나쁜 예: 회의록을 요약하는 에이전트를 만든다

좋은 예: 회의 → 회의록 생성 → 태스크 추출 → 담당자 통지 → 진척 확인까지를 하나의 흐름(워크플로)으로서 설계한다

이 차이는 큽니다. 전자는 편리한 기능이지만, 후자는 업무 프로세스 그 자체를 바꿉니다. AI의 가치는 단발적인 출력보다 사람에서 사람으로, 공정에서 공정으로 정보를 매끄럽게 잇는 데 있습니다.

여기서 유효한 것이 서비스 디자인(Service Design)의 사고방식입니다.

워크플로를 단순한 사내 절차로 보는 것이 아니라, 고객, 현장 담당자, 승인자, 관리자 등 관계자 각각의 경험이 어디서 연결되고 어디서 단절되는지를 조망합니다.

AI를 전제로 DX (디지털 전환)를 생각한다면, 개별 태스크를 대체하는 것에 그치지 않고 서비스 블루프린트(Service Blueprint)나 고객 여정 지도(Customer Journey Map)와 같이 "업무 흐름과 정보의 바통이 어디서 전달되고 어디서 끊기는지를 가시화하는 지도"를 사용하여, 표면의 고객 접점과 이면의 업무·시스템·지식(Knowledge)의 흐름을 한눈에 파악하는 것이 중요합니다.

그 바탕 위에서, 어떤 접점에 AI를 결합해야 전체적인 가치 제공이 원활해질지를 설계합니다.

개인의 작업 효율이 올라가는 것 자체는 좋은 일입니다.

하지만 그것만으로는 조직의 성과로 직결되기 어렵습니다.

조직에 효과를 내기 위해서는 승인, 공유, 판단, 우선순위 설정과 같은

의사결정 프로세스에 AI를 넣어야 합니다.

예를 들어, 다음과 같은 방식입니다.

• 문의 내용을 분류하고, 긴급도나 영향 범위에 따라 리스크를 특정하여 우선순위를 제시
• 승인 요청의 요점을 요약하고, 판단 자료로서 과거의 실패 사례나 유사 케이스를 병기
• 여러 안의 장단점을 정리하여, 의사결정자가 확인해야 할 논점을 미리 제시
• 과거 사례를 바탕으로 대응 방침의 초안(Draft)을 제시

이러한 메커니즘은 단순한 시간 단축이 아니라, 판단의 지연이나 정보의 단절을 줄입니다. 즉, AI가 조직의 속도에 작용하기 시작합니다.

AI의 정밀도를 높이고 싶다면 프롬프트(Prompt)만 고민해서는 부족합니다.

참조하는 정보의 구조, 업데이트 규칙, 검색성까지 포함하여 설계해야 합니다.

특히 중요한 것은 다음과 같은 관점입니다.

여기서 말하는 정보는 사실이나 소재로서 축적된 데이터(Data)입니다.

반면, 지식(Knowledge)은 그곳에 배경, 판단 기준, 과거의 배움이 더해져 다음 행동이나 의사결정에 사용할 수 있는 형태가 된 지혜를 가리킵니다.

• 문서(정보의 최소 단위)별 목적이 명확한가
• 최신 정보와 구 정보를 구분할 수 있는가
• 용어나 정의가 통일되어 있는가
• 인간이 읽어도 AI가 읽어도 따라가기 쉬운 구조로 되어 있는가

AI 도입을 계기로 지식 정비를 진행하면, 결과적으로 사람에게도 AI에게도 친화적인 정보 환경이 구축됩니다.

이 부분을 뒤로 미루면, 에이전트는 언제까지나 "그럴듯하지만 얕은" 답변에서 벗어나지 못합니다.

여기서 실제 저자의 활동에 대해 잠시 말씀드리겠습니다.

저는 현재 BIPROGY 사내 디자인 조직에 소속되어 UI/UX, 서비스 디자인 등을 담당하고 있으며, 평소 업무의 일환으로 서비스나 앱, 업무 시스템의 디자인도 수행하고 있습니다.

※ BIPROGY에서의 UI/UX 활동 전반에 대해서는 아래 기사에서 소개하고 있습니다.

위와 같은 설계 사상을 실천하는 도구 중 하나로서, 저는 실제로 Atlassian 사의 제품을 활용하며 데이터 소스가 정비된 환경에서 AI를 사용하여 업무를 하고 있습니다.

사상(업무 및 의사결정의 설계)과 도구(AI)가 갖춰져야 비로소 AI는 단순한 편리 기능이 아니라, 업무 흐름을 뒷받침하는 메커니즘으로서 움직이기 시작합니다.

데이터 소스가 축적됨에 따라, Atlassian의 AI인 Rovo는 검색뿐만 아니라 컨텍스트(Context)를 고려한 발견이나, 업무에서 활용할 수 있는 수준의 아웃풋(Output) 작성을 지원해 줍니다.

AI 활용이 개인의 편리한 도구로 끝날지, 조직에 효과적인 메커니즘이 될지는 첫 질문에서 상당 부분 결정됩니다.

이 차이는 구현의 차이라기보다 설계 사상의 차이입니다.

에이전트를 만드는 것 자체를 목적으로 하면 아무래도 국소 최적화(Local Optimization)가 됩니다.

반면, 업무 흐름이나 의사결정을 대상으로 하면 필요한 데이터, 연계, 운영 규칙까지 포함하여 생각하게 됩니다.

<구체적인 예시>

예를 들어 문의 대응을 서비스 블루프린트로 보는 경우,

"고객이 문의한다"
"1차 접수처가 내용을 확인한다"
"담당 부서가 조사한다"
"답변을 작성 및 승인한다"
"고객에게 회신한다"

라는 표면의 흐름뿐만 아니라, 그 이면에 있는

"지식 검색, 과거 사례 참조"
"담당자 배정"
"승인 규칙, CRM 및 티켓 관리와의 연계"

까지를 한 장의 지도로 가시화합니다.

그러면 AI로 단순히 회신문을 만드는 것에 그치지 않고, 문의 분류, 필요 정보의 부족 감지, 과거 사례 제시, 답변안 생성, 승인 전 체크, 지식 업데이트 등 어떤 접점에 AI를 결합했을 때 업무 전체의 경험이 개선될지를 생각하기 쉬워집니다.

서비스 디자인 (Service Design)의 관점: AI를 전제로 DX (디지털 전환)를 생각한다면, 개별 태스크 (Task)의 자동화에서 시작하는 것만으로는 불충분합니다. 이용자, 현장 담당자, 관리자, 고객 등 관계자의 경험을 연결하여 파악하고, 업무 전체를 조망하면서 어디에서 정보가 정체되고, 어떤 판단이 지연되며, 어떤 접점에서 가치가 손실되고 있는지를 파악해야 합니다. 서비스 디자인 (Service Design)의 사고방식을 활용함으로써, AI를 단순한 효율화 도구가 아니라 업무 프로세스, 지식 (Knowledge), 의사결정, 고객 경험을 일체로 재설계하기 위한 전제로 위치시킬 수 있습니다.

AI 도입 시 흔히 발생하는 실수는, **"우선 에이전트를 만든다"**는 것부터 시작하여,

점의 개선에 머물러 버리는 것입니다.

그 결과, 개인에게는 편리하지만 조직 전체의 흐름이나 의사결정에는 효과를 발휘하기 어려운 구조가 늘어나게 됩니다.

그렇게 되지 않기 위해서는, 에이전트를 개별적으로 만들기 시작하기 전에,

먼저 업무 전체를 조망하여 디자인하는 것이 중요합니다.

누구의 어떤 경험을 바꿀 것인지, 어떤 워크플로 (Workflow)를 진전시킬 것인지, 어떤 의사결정을 지원할 것인지를 먼저 정의하고, 그 전체 설계 안에서 개별 최적화로서의 에이전트를 위치시킵니다.

AI의 가치는 단독 작업을 조금 더 빠르게 만드는 것에만 있지 않습니다.

정보의 흐름을 정돈하고, 판단을 지원하며, 조직의 움직임을 진전시키는 단계까지 설계할 수 있을 때 비로소 커다란 가치가 됩니다.

이를 위해서는 태스크 단위의 자동화가 아니라, 워크플로 (Workflow), 의사결정, 지식 기반 (Knowledge Base)을 일체로 파악하는 관점이 필수적입니다.

먼저 전체를 디자인하고, 그 안에서 필요한 에이전트를 만든다.

이 순서가 편리한 도구로 끝날지, 조직에 효과적인 구조가 될지를 결정짓는 분수령이 됩니다.