발표는 좋았는데 내 업무에서는 시작할 수 없었다
AI 활용사례 공유회가 끝난 뒤 참가자가 가져가야 할 것은 감탄보다 다음 행동이다. 어떤 업무에서 시도할지, 무엇을 준비할지, 어디까지 사람의 판단이 필요한지 알 수 있어야 한다. 사례를 많이 보여 주는 것과 조직이 다시 수행할 수 있는 방법을 늘리는 것은 다른 성과다.
가상의 공유회를 떠올려 보자. 발표자는 몇 번의 입력으로 완성도 높은 제안서를 만든다. 참가자는 프롬프트를 받아 자기 팀에서 실행하지만 비슷한 결과를 얻지 못한다. 나중에야 발표자의 도구가 정리된 내부 자료에 연결돼 있었고, 고객 맥락을 아는 전문가가 결과를 여러 차례 수정했다는 사실을 알게 된다. 공유된 것은 성공 장면이었고 성공 조건은 빠져 있었다.
이런 차이를 도구 활용 능력의 격차로만 설명하면 교육을 더 듣게 하는 처방으로 끝나기 쉽다. 그러나 자료 접근권한, 기존 양식, 검토자, 후속 처리 방식이 다르다면 같은 문장을 입력해도 같은 업무 결과를 기대하기 어렵다. 개인의 입력 기술과 조직의 실행 조건을 나눠 봐야 한다.
AI 사례 재현은 화면을 똑같이 따라 하는 일이 아니다. 같은 업무 목적을 달성하는 데 필요한 조건을 확인하고, 자기 현장에 맞게 조정해 다시 수행하는 일이다. 공유회의 기획 단위도 ’잘 쓴 프롬프트’에서 ’다른 사람이 시도할 수 있는 업무 사례’로 옮겨야 한다.
프롬프트 뒤에 있는 연결 환경부터 보여 준다
2026년 9월 발표된 Kenton O’Hara, Michael Massimi, Miftah Khan의 연구는 IT 서비스 기업 Plative에서 조직 내부에 연결된 LLM 도구 Plaito가 협업에 어떻게 사용되는지 살폈다. 첫 인터뷰에는 14명이 참여했고, 이 가운데 9명이 후속 인터뷰에 참여했다. 후속 인터뷰에서는 실제 활용 장면과 관련 문서·화면을 통해 업무의 흐름을 구체적으로 확인했다.
이 연구는 한 조직의 질적 연구다. 교육 효과를 비교한 실험도, 모든 기업의 AI 활용을 대표하는 조사도 아니다. 다만 도구의 유용성을 모델 성능만으로 설명하기 어렵고, 기존 업무 시스템과 문서, 동료 간 조정 속에서 이해해야 한다는 점을 보여 준다.
O’Hara 외, Figure 1, PDF 12쪽. 자연어 입력창과 업무 시스템별 바로가기 버튼이 있는 실제 연구 대상 도구 화면이다. 범용 채팅창만으로 같은 결과를 재현할 수 있다는 근거는 아니다.
이 사례를 기업교육에 적용하면 발표 전에 확인할 항목이 달라진다. 어떤 자료가 도구에 연결돼 있는지, 발표자와 참가자의 접근권한이 같은지, 결과를 만드는 데 특정 조직의 문서 양식이 사용되는지부터 확인해야 한다. 프롬프트가 짧다는 이유만으로 업무가 간단해졌다고 설명해서는 안 된다.
모든 참가자에게 같은 권한을 열어 주자는 뜻은 아니다. 공유 가능한 조건과 제한되는 조건을 분명하게 나누자는 뜻이다. 접근할 수 없는 실제 자료 대신 적절한 교육용 자료를 준비할 수 있는지, 연결 환경이 다른 팀에서는 어느 단계까지 적용할 수 있는지 알려 줘야 한다. 실행 조건이 다르다는 설명은 확산을 방해하는 단서가 아니라 실패를 줄이는 학습 정보다.
발표 자료에는 도구명과 입력문 외에 업무 목적, 입력 자료의 종류, 필요한 권한, 사람이 확인한 항목, 후속 전달처를 적는 편이 좋다. 복잡한 기술 구조를 모두 설명할 필요는 없다. 재사용자가 자신의 환경과 차이를 판단할 수 있을 정도로 준비 조건을 드러내면 된다.
완성 화면보다 사람이 고친 지점을 나눈다
사례 공유에서 가장 쉽게 빠지는 부분은 사람의 수정이다. 발표자는 매끄러운 흐름을 보여 주려다 초안의 오류나 보완 과정을 생략하기 쉽다. 그러나 다른 사람이 배우는 데 필요한 것은 바로 그 차이다. 어떤 결과를 그대로 썼고 무엇을 바꿨는지 알아야 품질 판단을 배울 수 있다.
O’Hara 등의 연구에서는 고객 요구가 사용자 스토리 문서로 정리되고, 검토를 거쳐 Jira 업무 항목으로 이어지는 과정이 소개된다. AI 결과는 기존 협업 문서와 처리 절차에 맞게 사용됐으며, 프로젝트 책임자의 전문적 검토가 남아 있었다. 문서를 생성하는 장면과 실제 업무로 넘기는 장면을 분리해서 이해해야 한다.
O’Hara 외, Figure 3, PDF 30쪽. 사용자 스토리, 수용 기준, 해결 구성요소 등이 정리된 원문 문서 화면이다. 자동 생성 결과가 검토 없이 곧바로 업무에 적용됐다는 뜻은 아니다.
기업의 공유회에서도 결과물의 전후 차이를 보여 주자. 가상의 보고서 사례라면 AI가 만든 초안, 검토자가 수정한 부분, 수정 이유, 다음 사람이 요구한 형식을 함께 살필 수 있다. 민감한 내용은 공유 가능한 예제로 바꾸되 판단 구조까지 지우지 않는 것이 중요하다.
수정 이유는 ‘더 전문적으로’나 ’우리 회사답게’ 같은 표현으로 끝내지 않는다. 근거가 부족했는지, 적용 범위를 잘못 잡았는지, 다음 담당자가 사용할 정보가 빠졌는지 구체화한다. 같은 수정도 이유가 달라지면 다음 사례에서의 판단이 달라진다. 결과를 대신 고쳐 주는 것보다 고칠 기준을 설명하는 편이 동료학습에 도움이 된다.
또한 수정이 필요 없었던 부분도 확인한다. 모든 AI 결과를 반드시 고쳐야 한다는 인상을 주면 검토가 형식적인 문장 손질로 바뀔 수 있다. 기준을 충족한 부분과 충족하지 못한 부분을 구별해야 한다. 공유회의 초점은 사람의 손을 얼마나 많이 거쳤는지가 아니라 어떤 판단이 품질을 결정했는지다.
발표자의 설명 뒤에 재사용자의 질문을 배치한다
발표자가 사례를 준비하면 설명은 성공한 경로를 중심으로 구성되기 쉽다. 재사용자는 다른 질문을 한다. 우리 팀의 입력 자료가 덜 정리돼 있어도 가능한가. 다른 고객 유형에서도 적용되는가. 검토자가 없는 날에는 어디까지 진행할 수 있는가. 실패했을 때 기존 방식으로 돌아갈 수 있는가.
이 질문을 마지막의 자유 질의에만 맡기지 말고 회의의 중심에 두자. 발표자가 성공 조건을 설명한 뒤 실제로 재사용할 팀이 자기 환경의 차이를 제시한다. 두 사람이 함께 유지할 조건과 바꿔야 할 조건을 정리하면 사례가 개인의 노하우에서 조직의 실행안으로 바뀐다.
| 공유회에서 남길 기록 | 재사용자가 판단할 내용 |
|---|---|
| 해결하려던 업무와 결과의 사용처 | 내 업무에도 같은 문제가 있는가 |
| 입력 자료·접근권한·기존 양식 | 준비 조건을 갖출 수 있는가 |
| 사람이 수정한 부분과 이유 | 필요한 검토 역량이 있는가 |
| 적용하지 않은 조건과 예외 | 어디서 사용을 멈춰야 하는가 |
| 다시 시도할 담당자와 확인 시점 | 누가 다음 결과를 가져올 것인가 |
이 표는 본문의 연구가 검증한 운영 양식이 아니라 공유회를 위한 설계 제안이다. 모든 발표를 같은 서식에 가두려는 목적도 아니다. 다만 재사용 여부를 결정하는 데 필요한 정보는 사례의 형식과 관계없이 남아 있어야 한다.
재사용자가 없으면 사례를 버려야 하는 것은 아니다. 탐색 단계의 아이디어로 보관할 수 있다. 그러나 이미 확산 가능한 표준 사례처럼 표시하지는 말아야 한다. 최초 시도, 다른 팀의 재현 확인, 운영 채택을 구분하면 참가자도 어떤 수준의 근거를 보고 있는지 알 수 있다.
함께 모이는 시간에는 해결하지 못한 판단을 다룬다
BCG가 2026년 9월 공개한 Five Ways That AI Front-Runners Change How Work Gets Done은 AI 선도기업의 업무 방식 변화를 질적 인터뷰로 살폈다. 이 글에서 회의는 단순한 상태 전달보다 판단과 토론을 위한 자리로 재편되는 모습이 소개된다. Workera의 리더십 회의 사례에서는 AI가 결정된 사항과 남은 결정을 정리해 사람의 논의에 활용된다.
이는 특정 기업들의 운영 사례이며, 회의를 이렇게 바꾸면 교육 전이가 일정 비율 높아진다는 인과 근거는 아니다. 또한 선도기업 표본의 특징을 모든 기업의 준비 상태로 간주해서는 안 된다. 기업교육에 적용할 수 있는 질문은 제한적이지만 유용하다. 이미 문서로 전달할 수 있는 정보와, 사람끼리 함께 판단해야 하는 문제를 구분하고 있는가.
도구 소개와 기본 사용 절차는 사전에 읽거나 볼 수 있다. 함께 모인 자리에서는 초안의 모호한 부분, 다른 팀에 적용할 때의 예외, 검토 기준이 엇갈린 부분을 다루는 편이 낫다. 모든 참가자가 같은 화면을 수동적으로 보는 시간보다 서로 다른 업무 판단을 비교하는 시간이 중요하다.
회의 운영자는 기술적으로 가장 능숙한 발표자일 필요는 없다. 질문이 도구 자랑으로 흐를 때 업무 목적을 다시 묻고, 특정 개인의 경험이 전체 조직의 기준처럼 굳어질 때 적용 범위를 확인하는 사람이 필요하다. 정답을 바로 내는 능력보다 논의가 실제 행동으로 이어지게 하는 능력이 중요하다.
참가자 수가 많다면 모든 사람이 모든 사례를 볼 필요도 없다. 업무 문제나 검토 기준이 연결되는 사람끼리 논의하고, 다른 집단에는 재사용 조건과 남은 질문을 전달할 수 있다. 전사 행사의 규모가 커지는 것이 곧 동료학습의 밀도가 높아지는 것은 아니다.
재시도에서 막힌 조건을 다음 공유회의 첫 안건으로 올린다
사례 공유회의 성과는 발표가 끝난 날보다 재사용자가 다시 시도한 뒤에 드러난다. 같은 결과가 나왔는지뿐 아니라, 어디에서 추가 준비가 필요했는지 확인해야 한다. 자료를 정리하는 데 시간이 더 들었거나 검토 기준이 달랐다면 그것도 중요한 결과다.
후속 공유에서는 성공 여부만 묻지 않는다. 원래 사례의 어떤 조건을 유지했고 무엇을 바꿨는지, 결과를 누가 검토했는지, 다음 업무에서 실제로 사용됐는지를 확인한다. 재시도에 실패했다면 학습자의 능력 부족으로 단정하기 전에 입력·권한·검토·인계 조건을 다시 살핀다.
적용하지 않기로 한 판단도 남겨야 한다. 준비 비용이 예상 이익보다 크거나, 품질을 확인할 사람이 없거나, 해당 업무의 제약과 맞지 않을 수 있다. 이런 결정을 공유하면 다른 팀이 같은 시행착오를 반복하는 일을 줄일 수 있다. 모든 사례의 사용률을 올리는 것보다 적합한 범위를 찾는 것이 목적이다.
처음부터 조직 전체로 확산하려 하지 말고 실제로 유사 업무를 하는 팀에서 한 번 더 수행해 보는 방식으로 시작할 수 있다. 이때 사례의 발표자와 재사용자가 함께 결과를 검토한다. 발표자는 설명에서 빠뜨린 전제를 발견하고, 재사용자는 자신의 업무 조건을 더 명확하게 말하게 된다.
다음 회의는 새로운 시연으로만 채우지 않는다. 이전 사례의 재시도 결과와 수정된 조건을 먼저 검토한 뒤 새 사례를 다룬다. 이렇게 해야 공유회가 계속 새로움을 소비하는 행사에 머물지 않고 조직의 사용 기준을 축적하는 자리가 된다.
사례 라이브러리에는 성공 표식보다 유효 조건을 남긴다
사례를 문서로 저장했다고 조직 지식이 되는 것은 아니다. 검색한 사람이 언제, 어디에서, 누구의 검토 아래 사용할 수 있는지 알 수 있어야 한다. 제목에 도구명만 넣기보다 해결한 업무 문제를 드러내고, 적용 조건과 마지막 확인 시점을 함께 남기는 편이 좋다.
프롬프트 파일과 발표 영상을 보관하더라도 그것만으로 충분하지 않다. 연결 자료가 바뀌거나 업무 양식이 변경되면 기존 사례의 조건도 달라질 수 있다. 사례의 유지 담당자를 정하고, 중요한 변경이 있을 때 재검토할 수 있게 해야 한다. 발표자가 부서를 옮겼다는 이유로 아무도 검증하지 않는 자료가 계속 추천돼서는 안 된다.
기록을 남길 때는 공유 가능한 범위도 확인한다. 실제 고객 자료나 직원 정보가 포함된 화면을 교육 편의를 위해 넓게 배포할 필요는 없다. 판단에 필요한 구조는 유지하면서 적절한 예시 자료를 사용할 수 있다. 여기서 중요한 것은 모든 맥락을 숨기는 것이 아니라 학습에 필요한 조건과 공개하면 안 되는 내용을 구별하는 일이다.
사례 상태는 발견, 재현 확인, 운영 사용, 재검토 필요처럼 구분할 수 있다. 이것 역시 조직이 상황에 맞춰 정할 운영 제안이다. 상태 이름보다 중요한 것은 누구의 어떤 확인을 거쳤는지 추적할 수 있다는 점이다. 인기 있는 사례라도 유효 조건이 확인되지 않았다면 최신 표준처럼 제시하지 않는다.
참석률 대신 다른 사람의 다음 수행을 확인한다
공유회에 많은 사람이 참석하고 반응이 좋았다는 사실은 행사 운영의 성과다. 그것만으로 업무에서 다시 사용됐거나 판단 역량이 높아졌다고 말할 수는 없다. 참가자의 만족과 현업 재수행을 분리해 확인해야 한다.
교육팀은 다른 사람이 실제로 시도했는지, 결과를 검토할 기준이 전달됐는지, 기존 사례의 적용 조건이 수정됐는지를 살필 수 있다. 재현 건수만 늘리려 하면 작은 사례를 억지로 반복할 수 있으므로, 업무상의 의미와 검토 결과를 함께 봐야 한다. 시간 절감 주장도 준비와 검토, 인계까지 포함한 범위를 확인한 뒤 사용한다.
지식 공유를 잘하는 직원에게도 발표 횟수만으로 보상하지 않는 편이 좋다. 다른 사람이 이해하도록 조건을 설명했는지, 재시도 질문에 답했는지, 사례의 오류와 한계를 갱신했는지를 함께 인정해야 한다. 성공을 과시하는 사람보다 재사용 가능한 근거를 남기는 사람이 조직 학습에 기여한다.
AI 활용사례 공유회의 목적은 모든 직원이 같은 도구를 같은 방식으로 쓰게 만드는 데 있지 않다. 다른 사람의 시도를 자기 업무에 맞게 해석하고, 필요한 조건을 갖춘 뒤 책임 있게 다시 수행할 수 있게 하는 데 있다. 다음 발표 자료를 준비할 때는 완성 화면 한 장보다 ’다른 팀이 다시 해보려면 무엇이 필요한가’에 먼저 답해야 한다.
함께 읽을 글
출처
- Kenton O’Hara, Michael Massimi, Miftah Khan. Exploring How Knowledge Workers Situate an Organisationally Embedded LLM Agent in their Collaborative Work Practices. Computer Supported Cooperative Work 35, 16. 2026-09-24. 원문. 단일 기업 질적 연구, 1차 14명·후속 9명. Figure 1, 3과 관련 업무 맥락 참조.
- Sagar Goel, Julie Bedard, Matthew Kropp, Ashley Sim, Charikleia Kaffe. Five Ways That AI Front-Runners Change How Work Gets Done. BCG, 2026-09-24. 원문. 2026년 3–8월 선도기업 인터뷰 기반 분석. 회의·조정 방식 관련 해석이며 교육 효과의 인과 검증이 아님.