코드 한 줄 없이 손익관리팀이 만든 에이전트 — 신한EZ손해보험 Agentic 리더십이 비즈니스 현실이 된 날

PM 코치 에세이 · 2026년 6월 5일, 손해보험사 한 워크숍 워룸에서의 하루

관련 기사: 「유데미, LG CNS와 국내 기업의 AI 역량 강화를 위한 파트너십 체결」(뉴스1, 2025-12-16). 본 워크숍은 해당 파트너십이 금융·손해보험 부문에서 구현된 사례이며, 신한EZ손해보험 사명·인용은 워크숍 운영 합의 범위 내에서 사용했습니다.

오후 세 시쯤이었습니다. 전사 손익관리·기획을 맡으신 한 분의 화면에 표 하나가 그려졌습니다. 월 손익 마감의 계획 대비 실제 차이를 손해율·사업비율·투자손익·해지율 같은 driver별로 분해하고, 핵심 원인 세 가지에 경영진 코멘트 초안까지 붙인 표였습니다. 그 옆에는 같은 업무를 자동화했을 때의 3년 NPV와 ROI, 투자 회수기간을 계산한 시뮬레이션 대시보드가 떠 있었습니다.

이 화면을 만든 분은 개발자가 아닙니다. 코드를 한 줄도 쓰지 않으셨습니다. 손익을 마감하고, 예실차의 원인을 찾고, 경영진에게 실적을 보고하는 일을 매일 하시는 재무·기획 담당자입니다. 그분이 사전 설문에 적어 두셨던 본인의 가장 큰 괴로움은 한 문장이었습니다.

“데이터는 많은데, 원인을 찾는 과정이 매번 반복됩니다.”

오후 세 시의 그 화면은 바로 그 한 문장을 정면으로 푼 화면이었습니다. 매번 반복되던 원인분석을 에이전트가 초안으로 만들고, 사람은 수치를 확정하고 판단만 합니다. 본인이 오전에 적은 괴로움이 본인의 오후에 도구가 되어 돌아온 셈입니다. 저는 그 화면 앞에서 잠깐 멈췄습니다. 멈춘 이유는 결과물이 멋져서가 아니라, 이 화면을 만든 사람이 누구인가 때문이었습니다.

그날 워크숍 워룸에 앉아 계셨던 스물다섯 분의 명단을 다시 펼쳐 보겠습니다.

리스크관리, 보상기획, 민원관리, 회사 손익관리·기획, 인보상 기획, 상품 프라이싱, 결산·규제 검증, 장기보험 계리결산, 내부감사, 수재보험금 관리, 상품개발, Claim Operation, 법인계약·수수료, 데이터 분석, 자동차보상·구상, IT 자산관리, 오토 언더라이팅, 물적·투자자산 관리, 화재보험 체결, 결산·공시 총괄, 복리후생 운영, 일반보험 UW·재보험 정산, AI 거버넌스, 예산관리, 보상 NCRP.

소프트웨어를 직접 만드는 엔지니어가 한 명도 없습니다. 전원이 손해보험사의 비즈니스 부서입니다. 언더라이팅, 보상, 계리, 결산, 손익관리, 재보험, 감사, 예산. 회사를 굴리는 현업의 한복판에 있는 분들이고, 그동안 ‘AI를 만든다’는 일을 본인의 일이라고 생각해 본 적이 한 번도 없는 분들입니다.

그런데 그 스물다섯 분 중 다수가 사전 설문의 ‘오늘 가져가고 싶은 것’ 칸에 같은 단어를 적으셨습니다. 응답의 60% 이상이 “자동화”, “나만의 AI Agent”, “내 업무 에이전트 뼈대”였습니다. 이것이 워크숍 시작 시점에 제가 가장 먼저 확인한 신호였습니다. 비즈니스 부서가 에이전트를 남이 만들어 주기를 기다리는 게 아니라, 본인이 만들고 싶어 한다는 신호. 이 신호는 제 경험상 2025년까지는 드물었고, 2026년에 들어 급격히 흔해졌습니다.

여기서 한 가지 오해를 먼저 정리하고 싶습니다.

비즈니스 부서가 에이전트를 만든다고 하면, 많은 의사결정자가 “그건 IT부서나 데이터 조직이 할 일 아닌가”라고 반문하십니다. 이 반문은 5년 전이라면 옳았습니다. 그때는 에이전트를 만들려면 파이썬을 알아야 했고, 서버를 띄워야 했고, API를 다뤄야 했습니다. 비즈니스 담당자가 넘기 어려운 벽이었고, 그래서 ‘AI는 IT의 일’이라는 분업이 자연스러웠습니다.

그 벽이 2026년에 Agentic 도구로 완전히 무너졌습니다. 손익관리 담당자가 오후 세 시에 만든 그 에이전트는, 본인이 평소 쓰는 업무 언어로 지시를 내려서 만든 것입니다. “내 업무에 가장 적합한 에이전트 스킬을 추천해 줘. 가치효과·ROI·NPV·재무건전성·자동화효율을 고려해서.” 코드가 아니라 본인의 도메인 판단 기준으로 지시한 것입니다. 그날의 데모가 만든 손익관리 에이전트 세 가지는 이렇게 정리됐습니다.

이 표에서 ROI와 NPV를 계산하고, 세 에이전트의 도입 순서를 “Quick Win → Core → Foundation”으로 정렬하고, 어느 것이 본인 Pain 1위를 푸는지 판단한 것은 전부 비즈니스 담당자의 영역입니다. 재무건전성을 ROI보다 약간 높게 가중한 것도, 전략적이지만 구축비가 큰 K-ICS 자본 시나리오 에이전트를 일부러 후순위로 미룬 것도, 도메인을 아는 사람만 내릴 수 있는 판단입니다. 에이전트를 만드는 일의 핵심은 코딩이 아니라 도메인 판단으로 이동했습니다. 그리고 도메인 판단은 IT부서가 아니라 비즈니스 부서가 가지고 있습니다.

회고에서 한 분이 이렇게 적으셨습니다.

“AI를 단순히 자료취합 수준으로만 좁게 바라보던 저의 삶과 안목이 커졌습니다.”

저는 이 응답의 “안목”이라는 단어 위에서 멈췄습니다. 이분이 말씀하신 안목의 변화는 도구의 변화가 아닙니다. 어제까지 ‘AI = 자료 취합 도구’였던 인식이, 오늘 ‘AI = 내 업무를 함께 굴리는 비서’로 바뀐 것입니다. 이 인식 전환이 본 워크숍의 가장 중요한 성과였고, 회고 응답의 다수가 같은 전환을 직접 증언했습니다. “웹 검색용 AI에서 에이전트 모드로 일하는 AI로 인식이 바뀌었다”는 것입니다.

그런데 이 인식 전환이 왜 비즈니스 부서에서 더 중요한가. 엔지니어는 도구가 바뀌어도 본인이 만들면 됩니다. 비즈니스 담당자는 그동안 도구를 ‘기다리는’ 위치에 있었습니다. IT가 만들어 줄 때까지, 데이터 조직이 분석해 줄 때까지, 외부 벤더가 납품해 줄 때까지 기다렸습니다. 기다리는 동안 본인의 도메인 IP — 예실차를 읽는 안목, 거래선을 다루는 노하우, 요율을 산정하는 감각 — 은 본인 머릿속에만 있었고, 시스템에는 닿지 못했습니다.

안목이 커졌다는 응답은, 그 기다림이 끝났다는 신호입니다. 이제 비즈니스 담당자가 본인의 도메인 IP를 본인 손으로 에이전트에 담을 수 있습니다. 누가 만들어 주기를 기다리지 않아도 됩니다. 그것이 비즈니스 부서에게 Agentic 리더십이 ‘있으면 좋은 것’이 아니라 ‘없으면 뒤처지는 것’이 된 이유입니다. 옆자리 동료는 본인 업무를 에이전트로 굴리기 시작했는데, 나만 기다리고 있다면, 6개월 뒤의 격차는 도구의 격차가 아니라 안목의 격차가 됩니다.

다만 한 가지를 분명히 적어 두어야 합니다. 비즈니스 부서가 에이전트를 만들 수 있게 됐다는 것은, 동시에 비즈니스 부서가 에이전트를 다스릴 책임까지 지게 됐다는 뜻입니다. 그리고 이 책임은 손해보험이라는 도메인에서 특히 무겁습니다.

그날 워크숍 워룸에는 AI 거버넌스 담당자도, 내부감사 담당자도, 결산·공시 총괄도 함께 앉아 계셨습니다. 한 분이 회고에 적으신 문장이 그 무게를 정확히 짚었습니다.

“업무 효율 증가가 기대되는 동시에, 보안 관점에서 개인·민감 정보 유출과 해킹을 고려해야 하는 것이 염려됩니다.”

저는 이 응답을 그날의 가장 성숙한 통찰로 꼽았습니다. 효율과 위험을 동시에 본 시각이기 때문입니다. 손익·요율·준비금·공시 수치, 법인 수수료, 계약자 사고정보 — 이 데이터들은 외부 생성형 AI에 그대로 입력하면 안 되는 정보입니다. 그래서 그날의 모든 데모는 두 가지 원칙 위에서만 돌아갔습니다. 첫째, 수치의 확정과 경영 판단은 반드시 사람이 한다(HITL). 에이전트는 초안과 근거만 만듭니다. 둘째, 민감 데이터는 가명·예시로 치환해서만 다룬다(신용정보법). 실데이터는 워크숍 워룸 밖으로 나가지 않습니다.

이 두 원칙을 세우고 지키는 일이야말로 비즈니스 부서 Agentic 리더십의 절반입니다. 에이전트를 만드는 것이 앞쪽 절반이라면, 에이전트가 무엇을 만지고 무엇을 만지면 안 되는지의 선을 긋는 것이 뒤쪽 절반입니다. 엔지니어는 도구를 안전하게 만들 수 있지만, 무엇이 위험한 데이터인지를 아는 사람은 그 데이터를 매일 다루는 비즈니스 담당자입니다. 거버넌스조차도 결국 도메인을 아는 사람의 일입니다. 그래서 비즈니스 부서가 에이전트를 만드는 시대의 리더십은, 만드는 능력과 다스리는 책임을 한 사람이 동시에 지는 리더십입니다.

한 가지 더. 그날 오전에 저는 한 단계를 일부러 비워 두었습니다. 자동화로 곧장 달려가기 전에 “이 일을 아예 없앨 수는 없는가, 줄일 수는 없는가”를 먼저 묻는 ERRC 단계입니다. 비즈니스 부서가 에이전트를 만들 수 있게 되면 가장 먼저 빠지는 함정이 ‘모든 일을 자동화하려는’ 충동입니다. 없애도 되는 일을 자동화하면, 없애도 될 일을 영원히 살려 두는 결과가 됩니다. 리더십의 첫 질문은 “어떻게 자동화할까”가 아니라 “이 일이 꼭 있어야 하는가”여야 합니다. 이 순서를 지키는 것도 도메인을 아는 비즈니스 리더만 할 수 있는 판단입니다.

워크숍 워룸에서 나오면서 저는 다음 회차를 위한 메모 한 줄을 남겼습니다.

비즈니스 부서 워크숍에서 가장 길게 살아남는 자산은 에이전트 결과물이 아니다. “내 업무를 내 손으로 에이전트에 담아 봤다”는 한 번의 경험이다. 그 경험을 한 비즈니스 담당자는, 다음 주 회의에서 같은 일을 본인 힘으로 다시 시작한다. 코치의 일은 그 첫 한 번을 옆에서 만들어 주는 일이다.

회고의 마지막에 한 분이 적으신 문장이 그 메모를 증명합니다.

“이제부터는 저의 몫이겠지만, 오늘을 발판 삼아 새로운 모습으로 나아가고자 합니다.”

“저의 몫”이라는 단어가 핵심입니다. 이분은 오늘의 경험을 강사의 것으로도, 도구의 것으로도 돌리지 않으셨습니다. 본인의 몫으로 가져가셨습니다. 비즈니스 부서 Agentic 리더십의 출발점이 바로 이 한 문장입니다. 도구가 본인을 일하게 하는 게 아니라, 본인이 도구를 부려서 일하는 위치로 옮겨 가는 것. 그 위치 이동을 본인의 몫으로 받아들이는 것.

이 글을 읽으시는 비즈니스 부서의 리더, 그리고 인재개발·경영지원 담당자께 두 가지를 권유드리고 싶습니다.

첫째, 다음 AI 교육을 IT부서나 데이터 조직에만 배정하지 마시기 바랍니다. 손익관리, 언더라이팅, 보상, 계리, 결산, 예산 — 본인의 도메인 판단을 매일 내리는 비즈니스 담당자야말로 에이전트를 가장 잘 만들 수 있는 사람입니다. 만드는 일의 핵심이 코딩에서 도메인 판단으로 이동했기 때문입니다. 비즈니스 부서를 ‘에이전트를 받는 쪽’이 아니라 ‘에이전트를 만드는 쪽’으로 옮기는 결정이, 향후 2년의 조직 역량 격차를 가릅니다.

둘째, 그 결정에 거버넌스를 함께 묶으시기 바랍니다. 비즈니스 부서가 에이전트를 만드는 시대에는, 무엇이 민감 데이터인지를 아는 사람이 그 데이터의 선을 긋는 사람이어야 합니다. HITL — 수치 확정과 판단은 사람이, 가명처리 — 실데이터는 외부로 내보내지 않기. 이 두 원칙을 비즈니스 담당자 본인의 책임으로 내재화하는 것이, 만드는 능력만큼이나 중요한 리더십의 절반입니다.

스물다섯 분의 비즈니스 담당자가 한나절 만에 통과한 입구를, 본인의 부서도 통과할 수 있습니다. 입구는 코딩이 아니라 안목에 있습니다. 그리고 그 안목은, 본인이 이미 매일의 업무 속에서 가지고 계십니다. 코치인 저의 일은 그 안목이 도구에 담기는 첫 순간을 옆에서 만들어 드리는 일입니다. 다음 회차에서, 또 다른 비즈니스 부서를 위해 같은 자리를 다시 만들겠습니다.

본 에세이는 신한EZ손해보험 AX Insight 워크숍(2026-06-05, 7시간, 참여자 25명, 에이전트 모드 실전)의 산출물과 참가자 회고 데이터를 기반으로 작성된 PM 코치 1인칭 서사입니다. 참여자 인용은 모두 익명 처리(직무군만 보존)했고, 손익·재무 수치는 사내 실측이 아닌 워크숍 데모의 예시·가정값입니다(인건비·소요시간·구축비 가정 기반 추정). 실데이터·민감정보는 워크숍 전 과정에서 가명·예시로만 다루었습니다.

• 지금 Agentic으로 전환해야 하는 이유 — 삼성·LG·KT·Clean&Science가 증명한 다섯 가지 가치
• Agentic PM의 시대가 열리다 — LG전자 SW PM 워크숍을 마치며
• 삼성전자 PMC: AI와 함께하는 PM 교육 혁신
• Agentic PM 시리즈 진입 가이드 (3-Axis Decision Tree)