작성일 댓글 한 개

[휴먼 인 더 루프(Human-in-the-Loop): AI 시대, 사람만 할 수 있는 일] 4/12화: 금융 챗봇 8년, AI가 끝맺지 못하는 일의 정체

금융 챗봇에서 사람 상담사로 연결되는 순간

어느 금요일 오후 4시 58분의 전화

금요일 오후 4시 58분. 은행 영업 마감 2분 전이었다. 챗봇 관제 화면에 빨간 알림이 떴다. 70대 고객이 챗봇과 47분째 대화 중이었다. 돌아가신 배우자의 계좌를 정리하고 싶다는 내용이었다.

챗봇은 완벽하게 동작하고 있었다. 상속 관련 필요 서류 목록을 안내했고, 가까운 지점 위치도 알려줬고, 예약 가능한 시간대까지 제시했다. 기술적으로는 모든 답변이 정확했다. 그런데 고객은 같은 질문을 조금씩 바꿔가며 계속 물었다. “그러면 남편 이름으로 된 적금은요?” “남편이 매달 넣던 자동이체는요?” “남편 카드 연회비는 어떻게 되나요?”

숫자로 보면 챗봇의 응답 정확도는 100%에 가까웠다. 그런데 이 대화는 끝나지 않고 있었다. 47분이나.

관제실의 후배가 물었다. “봇이 답을 다 하고 있는데, 왜 안 끝나는 거죠?”

나는 전화기를 들었다. 상담사에게 즉시 연결해달라고 요청했다. 상담사가 전화를 걸었고, 고객은 5분 만에 울음을 터뜨렸다. “어디서부터 시작해야 할지 모르겠어요. 남편이 다 알아서 했거든요.”

그날 이후 나는 확신하게 됐다. AI가 아무리 정확하게 ‘답’을 해도, ‘끝맺음’은 전혀 다른 차원의 일이라는 것을.

지난 3화에서 AI를 잘 쓰는 팀과 못 쓰는 팀의 결정적 차이가 ‘피드백 루프’에 있다고 이야기했다. 오늘은 그 루프의 가장 끝단, 즉 ‘닫는 순간’에 대해 이야기하려 한다. 8년 동안 금융 챗봇을 운영하면서 쌓인 이야기다.

금융 챗봇 8년, 무엇이 바뀌었고 무엇이 안 바뀌었나

내가 처음 금융 챗봇 프로젝트에 투입된 것은 2018년이었다. 당시 챗봇이라고 부르기도 민망한, 키워드 매칭 기반의 FAQ 응답기였다. “잔액 조회”라고 치면 잔액 조회 방법을 안내하는 수준. 고객들은 “이게 챗봇이냐”며 별점 1점을 남겼고, 우리는 매주 키워드 사전을 손으로 업데이트했다.

8년이 지난 지금, 기술은 비교할 수 없을 만큼 발전했다. 자연어 이해 수준은 상전벽해라는 말로도 부족하다. 고객이 “지난달에 어디서 쓴 건지 모르겠는데 8만 원 정도 빠져나간 게 있어요”라고 쓰면, 챗봇은 카드 이용 내역에서 해당 건을 특정하고 가맹점명까지 알려준다. 음성 인식도 되고, 이미지 첨부도 되고, 다국어도 지원한다.

그런데 이상한 일이 있다. 기술이 이렇게 발전했는데, 상담사 연결 요청은 줄지 않았다.

금융 챗봇 8년 세대별 변화 타임라인

정확하게 말하면, ‘단순 문의’에서의 상담사 연결은 확실히 줄었다. 잔액 조회, 이체 한도 확인, 카드 분실 신고 같은 건. 이런 것들은 챗봇이 80% 이상 자체 해결한다. 그런데 전체 상담사 연결 건수의 절대량은 크게 달라지지 않았다. 왜일까.

답은 단순했다. 챗봇이 단순 문의를 빨리 처리해주니까, 고객들이 더 복잡한 요구를 들고 오기 시작한 것이다. “이 정도는 봇이 해주니까” 하는 기대치가 올라가면서, 봇으로 해결이 안 되는 건에 대한 불만도 같이 올라갔다. 기술이 좋아질수록 ‘남은 것들’의 난이도가 올라가는 역설. 이것을 우리 팀에서는 “라스트 마일 역설”이라고 불렀다.

챗봇 세대별 변화와 ‘남은 문제’의 진화

8년을 크게 세 시기로 나눠볼 수 있다.

1세대 (2018~2020): 키워드 매칭 시기. 챗봇이 못하는 게 너무 많아서 상담사 연결이 자연스러웠다. 고객도 “챗봇은 이 정도겠지” 하고 금방 상담사를 찾았다. 역설적으로 불만이 적었다. 기대가 낮았으니까.

2세대 (2020~2023): 의도 분류 + 시나리오 시기. 머신러닝으로 고객 의도를 분류하고, 의도별 시나리오를 설계해서 대화를 이끌었다. “카드 분실이시군요 → 분실 신고 하시겠어요? → 네 → 완료되었습니다” 식의 태스크 완결형 봇. 단순 업무 해결률이 급등했다. 동시에 고객 기대치도 급등했다. “분실 신고는 되는데 왜 보험 청구는 안 돼?”

3세대 (2023~현재): 대규모 언어 모델 시기. 자연어 이해가 사람 수준에 근접했다. 고객이 뭘 원하는지 ‘이해’하는 데는 거의 문제가 없어졌다. 그런데 바로 여기서 근본적인 질문이 등장했다. 이해한다고 해서 끝낼 수 있는 건 아니라는 것.

AI가 ‘답’은 하는데 ‘끝’은 못 내는 것들

8년간 챗봇을 운영하면서 “이건 AI가 절대 혼자 못 끝낸다”고 확신하게 된 영역들이 있다. 기술이 아무리 발전해도, 적어도 금융이라는 맥락에서는 사람의 개입 없이 닫을 수 없는 일들. 하나씩 풀어보겠다.

첫 번째: 감정이 얽힌 민원의 종결

금융 민원은 독특하다. 돈이 걸려 있기 때문이다. 식당 서비스에 불만이 있으면 “다음에 안 가면 그만”이지만, 금융 민원은 다르다. 내 돈이 잘못 빠져나갔거나, 대출이 거절됐거나, 보험금이 안 나오면 — 그건 생활이 걸린 문제다.

챗봇은 민원을 ‘접수’할 수 있다. 분류도 잘 한다. 관련 규정도 안내할 수 있다. 처리 예상 기간도 알려줄 수 있다. 그런데 민원이 ‘종결’되려면 고객이 “이제 됐다”고 느껴야 한다. 그리고 그 느낌은 정보 전달만으로는 만들어지지 않는다.

실제 사례를 하나 들겠다. 물론 익명 처리한다.

60대 자영업자 고객이 대출 연장이 거절됐다. 챗봇에 사유를 물었고, 챗봇은 신용평가 기준에 따른 거절 사유를 정확하게 안내했다. 고객은 “그럼 어떻게 하면 되느냐”고 물었다. 챗봇은 신용점수 개선 방법, 다른 대출 상품 안내, 서민금융 안내까지 빠짐없이 제시했다. 기술적으로 완벽한 응답이었다.

그런데 고객은 만족하지 않았다. 다음 날 다시 왔다. 그다음 날도. 일주일 동안 매일 챗봇에 접속해서 비슷한 질문을 반복했다. 로그를 분석해보니, 고객이 진짜 원했던 건 ‘다른 방법’이 아니었다. “20년 거래했는데 이렇게 되냐”는 억울함을 누군가에게 말하고 싶었던 것이다.

결국 상담사가 전화를 걸었다. 상담사는 20분 동안 이야기를 들었다. “네, 20년 동안 거래해주셨는데 이런 결과가 나와서 정말 속상하시겠습니다.” 이 한마디가 일주일치 챗봇 대화보다 더 큰 효과를 냈다. 고객은 결과 자체는 바뀌지 않았지만, “알겠다, 다른 방법을 찾아보겠다”며 전화를 끊었다.

종결은 정보의 문제가 아니라 관계의 문제다. AI는 정보를 완벽하게 전달할 수 있다. 하지만 “이제 됐다”는 느낌을 만들어내는 건, 적어도 현재의 AI로는 불가능하다.

두 번째: 규정의 회색 지대에서 내리는 판단

금융은 규제 산업이다. 모든 것에 규정이 있고, 그 규정을 지키지 않으면 벌금이나 제재가 따른다. 챗봇도 당연히 규정에 맞게 답변해야 한다. 그런데 문제는, 규정이 항상 깔끔하게 흑백으로 나뉘지 않는다는 것이다.

예를 들어보자. 고객이 해외에서 카드를 사용했는데, 본인이 사용한 건 맞지만 가맹점에서 금액을 잘못 청구한 것 같다고 한다. 이런 경우 ‘이의제기(chargeback)’ 절차를 안내해야 하는데, 여기서부터 회색 지대가 시작된다.

규정상 이의제기는 ‘부정 사용’과 ‘거래 분쟁’으로 나뉜다. 부정 사용이면 A 프로세스, 거래 분쟁이면 B 프로세스. 그런데 고객의 설명이 어중간하다. “제가 쓴 건 맞는데, 금액이 다르고, 그 가게가 좀 이상했어요.” 이게 부정 사용인가, 거래 분쟁인가?

챗봇은 규정을 기반으로 분류를 시도한다. 하지만 경계선에 있는 건은 어느 쪽으로 분류하느냐에 따라 고객의 보호 수준과 처리 속도가 달라진다. 잘못 분류하면 고객이 불이익을 받을 수 있고, 반대로 지나치게 관대하게 분류하면 회사가 리스크를 떠안는다.

이런 판단을 AI에게 맡길 수 있을까? 기술적으로 가능할 수도 있다. 확률적으로 이쪽에 더 가깝다는 판정을 내릴 수는 있다. 하지만 금융에서는 “확률적으로 이쪽 같습니다”가 통하지 않는다. 누군가가 판단에 대해 책임을 져야 하고, 그 책임은 사람에게만 귀속될 수 있다.

AI 에스컬레이션 5가지 판단 패턴 플로우

우리 챗봇 시스템에는 “회색 지대 감지기”라는 내부 모듈이 있다. 고객의 질문이 규정의 경계선에 걸리면, 자동으로 플래그를 세우고 상담사에게 넘긴다. 이 모듈을 만드는 데 2년이 걸렸다. 재미있는 건, 이 모듈의 핵심 기능이 “답하지 않는 것”이라는 점이다. AI가 가장 잘 동작하는 순간이, 자신이 답하면 안 되는 상황을 정확히 인지하는 순간이라니. 역설적이지만 이것이 현실이다.

세 번째: 예외적 인생 상황에 대한 대응

글의 서두에서 이야기한 70대 고객의 사례로 돌아가보자. 배우자를 잃고 처음으로 금융 업무를 혼자 처리해야 하는 상황. 이런 일은 드물지 않다.

사별, 이혼, 중병, 사기 피해, 자연재해. 금융 챗봇을 8년 운영하면 이런 상황을 수도 없이 만난다. 그리고 이런 상황에서 고객이 원하는 건, 단순한 업무 처리가 아니다.

사별 후 계좌 정리를 문의하는 고객에게 필요한 건 서류 목록이 아니라, “지금 당장 다 하지 않아도 됩니다. 천천히 하셔도 괜찮습니다”라는 한마디다.

보이스피싱 피해를 당한 고객에게 필요한 건 신고 절차 안내가 아니라, “고객님 잘못이 아닙니다”라는 확인이다.

챗봇이 이런 말을 할 수 있을까? 기술적으로는 가능하다. 감정 분석을 해서 고객이 힘든 상황에 있다고 판단하면, 공감 문구를 먼저 출력하도록 프로그래밍할 수 있다. 실제로 우리도 그렇게 했다.

그런데 효과가 없었다.

이유를 오래 고민했다. 결론은 이렇다. 같은 말이라도 ‘누가’ 하느냐가 중요하기 때문이다. “고객님 잘못이 아닙니다”라는 말은, 기계가 하면 프로그래밍된 응답이고, 사람이 하면 위로다. 고객은 그 차이를 안다. 아니, 느낀다. 챗봇이 “걱정되시겠습니다”라고 말하면, 고객은 “어차피 자동 응답이겠지”라고 생각한다. 하지만 상담사가 잠깐 말을 멈추고 “…정말 힘드셨겠네요”라고 하면, 그 침묵과 목소리의 떨림에서 진심을 감지한다.

이것을 기술로 해결할 수 있을까? 언젠가는 될 수도 있다. 하지만 “언젠가”와 “지금”은 다르다. 그리고 금융은 “언젠가”를 기다릴 여유가 없는 산업이다. 지금 당장 눈앞의 고객이 울고 있으면, 지금 당장 사람이 나서야 한다.

네 번째: 책임의 서명이 필요한 순간

금융에서 가장 무거운 단어 중 하나가 ‘책임’이다. 그리고 책임에는 항상 서명이 따른다.

대출 승인, 보험금 지급, 투자 상품 권유, 고객 정보 변경. 이런 것들에는 반드시 ‘누군가의 결재’가 필요하다. 법적으로 그렇고, 내부 통제 기준으로도 그렇다.

챗봇이 아무리 정확하게 고객의 대출 적격 여부를 판단해도, 최종 승인 버튼은 사람이 눌러야 한다. 챗봇이 보험 약관을 완벽하게 해석해서 “이 경우 보험금이 지급됩니다”라고 판단해도, 실제 지급 결의서에는 심사역의 도장이 찍혀야 한다.

이것은 기술의 한계가 아니다. 제도의 설계다. 금융 시스템은 “누군가가 책임진다”는 원칙 위에 세워져 있다. AI가 판단의 정확도를 99.9%로 올려도, 그 0.1%가 현실이 됐을 때 “AI가 그랬습니다”는 답이 되지 않는다. 규제 기관 앞에서, 법정에서, 금융감독원의 민원 조정 과정에서 — 결국 사람이 서서 “제가 판단했습니다”라고 말해야 한다.

챗봇 운영 초기에 우리 팀 내부에서 논쟁이 있었다. “왜 챗봇이 직접 처리해버리면 안 되냐. 기술적으로 가능한데.” 그때 컴플라이언스 팀의 답변이 아직도 기억난다.

“기술적으로 가능한 것과, 해도 되는 것은 다릅니다.”

이 한마디가 금융에서 AI의 역할을 정의한다고 생각한다.

다섯 번째: 맥락이 대화를 넘어서는 경우

챗봇은 대화의 맥락을 기억한다. 대화가 시작된 이후의 맥락은. 하지만 금융에서 진짜 중요한 맥락은 대화 밖에 있다.

한 번은 이런 일이 있었다. 고객이 갑자기 전 계좌의 해지를 요청했다. 챗봇은 해지 절차를 안내하려 했고, 이탈 방지 로직이 작동해서 “해지하시면 이런 혜택을 잃게 됩니다”라는 멘트를 출력했다. 기술적으로 맞는 대응이다.

그런데 이 고객은 보이스피싱 피해자였다. 범인의 지시를 받고 있었다. “빨리 계좌를 해지하고 새 계좌를 만들어야 한다”고 속은 상태였다. 챗봇의 이탈 방지 멘트는 오히려 고객을 초조하게 만들었다. “왜 빨리 안 해주느냐”며 더 다급해졌다.

이런 상황을 챗봇이 감지할 수 있을까? 대화 내용만으로는 어렵다. “계좌를 해지하고 싶다”는 말 자체는 정상적인 요청이다. 하지만 이 고객의 최근 거래 패턴, 갑작스러운 행동 변화, 통화 이력, 접속 환경 등을 종합하면 이상 징후를 감지할 수도 있다.

문제는 이런 종합 판단이 단순한 패턴 매칭이 아니라는 점이다. 경험 많은 상담사는 고객의 목소리 톤, 말의 속도, 질문의 패턴에서 “뭔가 이상하다”는 직감을 얻는다. 그리고 그 직감을 바탕으로 “고객님, 혹시 누군가 지시를 받고 계신 건 아닌가요?”라고 조심스럽게 물을 수 있다. 이 질문 하나가 수천만 원의 피해를 막기도 한다.

AI는 데이터를 분석할 수 있다. 하지만 “뭔가 이상하다”는 직감, 그리고 그 직감을 바탕으로 조심스럽게 개입하는 판단은 아직 사람의 영역이다.

왜 ‘끝맺음’이 ‘시작’보다 어려운가

여기서 잠깐, 좀 더 근본적인 질문을 던져보자. 왜 AI는 대화를 ‘시작’하고 ‘이어가는’ 것은 잘 하면서, ‘끝맺는’ 것은 못 할까?

답은 생각보다 단순하다. ‘끝맺음’에는 판단, 책임, 공감이 동시에 필요하기 때문이다.

대화를 시작하는 것은 쉽다. “무엇을 도와드릴까요?” 대화를 이어가는 것도 상대적으로 쉽다. 질문에 답하고, 추가 질문을 하고, 정보를 제공하면 된다. 하지만 대화를 끝내려면 — 특히 금융 맥락에서 만족스럽게 끝내려면 — 다음 세 가지가 동시에 충족돼야 한다.

첫째, 상황에 대한 올바른 판단. 이 고객의 문제가 진짜 해결됐는가? 표면적으로 답을 줬다고 해서 문제가 해결된 게 아닐 수 있다. 앞서 든 대출 거절 사례처럼.

둘째, 결과에 대한 책임. “이 조언대로 하시면 됩니다”라고 말하려면, 그 조언이 틀렸을 때의 결과도 감수해야 한다. AI가 “이 펀드에 투자하시면 됩니다”라고 말할 수 있을까? 기술적으로 가능하다. 하지만 그 투자로 손실이 나면 누가 책임지나?

셋째, 인간적 공감. “이제 끝이다”는 느낌은, 상대방이 나를 이해하고 있다는 확신에서 온다. 규정에 맞는 답변을 받았다고 해서 자동으로 “이해받았다”고 느끼지는 않는다.

이 세 가지가 동시에 충족되는 순간, 대화는 자연스럽게 종료된다. 고객이 “감사합니다, 알겠습니다”라고 하고 전화를 끊는 그 순간. 그것이 진정한 ‘끝맺음’이다.

AI는 이 세 가지 중 첫 번째에만 강하다. 정보 분석과 상황 판단. 나머지 두 개는 — 적어도 금융이라는 고위험 맥락에서는 — 아직 사람의 몫이다.

8년간 배운 것: 끝맺음의 다섯 가지 패턴

운영 데이터를 분석하면서 금융 챗봇에서 ‘사람의 끝맺음’이 필요한 상황을 다섯 가지 패턴으로 분류할 수 있었다. 이 분류가 우리 팀의 에스컬레이션 정책의 뼈대가 됐다.

패턴 1: 감정 잔여(Emotional Residue)

정보는 전달됐지만 감정이 해소되지 않은 경우. 앞서 든 대출 거절, 사별 후 계좌 정리 사례가 여기에 해당한다. 고객이 같은 질문을 반복하거나, 답변을 받고도 대화를 종료하지 않는 패턴으로 감지한다.

우리 팀의 대응: 동일 주제 반복 3회 이상 감지 시 상담사 연결 제안. 강제 연결이 아니라 제안. “혹시 상담사와 직접 이야기하고 싶으시면 연결해드릴까요?” 수용률이 약 60%. 그리고 상담사가 연결된 후 종결까지 걸리는 시간은 평균 8분. 챗봇과 반복 대화하던 시간보다 훨씬 짧다.

패턴 2: 규정 경계(Regulatory Boundary)

고객의 요청이 규정의 경계선에 걸리는 경우. 챗봇이 어느 쪽으로도 명확하게 답할 수 없고, 잘못 답하면 법적 리스크가 생기는 상황.

우리 팀의 대응: 앞서 말한 “회색 지대 감지기”가 작동한다. 이 모듈은 규정 DB와 고객 질문을 매칭해서, 매칭 확신도(confidence)가 임계값 이하이면 자동 에스컬레이션. 임계값은 분기별로 컴플라이언스 팀과 조율해서 조정한다.

이 패턴에서 중요한 건, 에스컬레이션 자체가 답이라는 점이다. “지금 이 질문에는 전문 상담사가 정확하게 안내해드려야 합니다”라는 응답도 하나의 좋은 답변이다. 오히려 애매하게 답하는 것보다 훨씬 나은.

패턴 3: 생애 사건(Life Event)

사별, 이혼, 은퇴, 중병 등 고객의 인생에 큰 변화가 생긴 상황에서의 금융 문의. 업무적으로는 계좌 명의 변경, 보험 청구, 연금 수령 등이지만 감정적으로는 훨씬 복잡하다.

우리 팀의 대응: 특정 키워드(상속, 사망, 이혼, 장애 등)가 감지되면 대화 톤을 전환하고, 초기부터 상담사 연결을 적극 제안한다. 그리고 연결되는 상담사도 일반 상담사가 아니라, 해당 분야 전문 교육을 받은 상담사로 라우팅한다.

이 패턴에서 기술이 기여하는 부분은 ‘감지’와 ‘라우팅’이다. 챗봇이 상황을 빠르게 파악해서 적합한 사람에게 연결해주는 것. 기술의 역할이 “대신 처리하는 것”이 아니라 “적합한 사람을 빨리 찾아주는 것”으로 바뀌는 영역이다.

패턴 4: 다중 접점 이력(Multi-touch History)

같은 문제로 여러 채널(챗봇, 전화, 지점, 이메일)을 거친 고객. 이미 여러 번 설명했는데 아직 해결이 안 된 상태. 이런 고객의 첫마디는 대개 “이거 몇 번째 연락인지 아세요?”다.

이 패턴에서 챗봇이 가장 못 하는 건 ‘이전 맥락의 연속성 보장’이다. 기술적으로 이전 대화 기록을 보여줄 수는 있다. 하지만 “아, 이전에 전화로 OOO 상담사랑 통화하셨었네요. 그때 말씀드린 부분에서 추가로 궁금하신 거죠?”라는 자연스러운 맥락 이어가기는 사람이 해야 한다.

우리 팀의 대응: 동일 이슈로 3회 이상 접촉한 고객은 자동으로 전담 상담사를 배정한다. 그리고 그 상담사에게는 이전 모든 채널의 대화 요약을 AI가 만들어 제공한다. 여기서 AI의 역할은 “직접 상담”이 아니라 “상담사의 무기 장전”이다.

패턴 5: 의사결정 요청(Decision Request)

“제 상황에서 뭘 해야 하나요?” 이 질문이 가장 까다롭다.

“적금 만기가 됐는데 재예치할까요, 펀드에 넣을까요?” “대출 갈아탈까요, 그냥 둘까요?” “보험 하나 더 들어야 할까요?”

챗봇은 각 선택지의 정보를 비교해서 보여줄 수 있다. 금리, 수수료, 세금 혜택, 리스크 수준. 훌륭한 정보 제공이다. 하지만 “그래서 뭘 하라”는 말은 할 수 없다. 아니, 해서는 안 된다.

이것은 기술의 한계가 아니라 금융 규제의 영역이다. 투자 권유는 자격이 있는 사람만 할 수 있다. 그리고 권유에는 책임이 따른다. 적합성 원칙, 설명 의무, 냉정 기간 안내. 이 모든 것이 ‘사람’에게 부여된 의무다.

챗봇이 “A 상품이 고객님께 더 유리해 보입니다”라고 말하는 순간, 그것은 투자 권유가 된다. 그리고 그 권유의 주체가 AI라면? 현행 금융 규제 체계에서는 아직 명확한 답이 없다. 규제가 기술을 따라가지 못하는 전형적인 사례다.

우리 팀의 대응: 의사결정 요청이 감지되면 “정보는 이렇습니다”까지만 제공하고, “구체적인 상담은 전문 상담사와 진행하시는 게 좋겠습니다”로 마무리한다. 이것이 가장 안전하고, 동시에 가장 정직한 대응이다.

그렇다면 금융 챗봇은 무엇을 하고 있는가

여기까지 읽으면 “그럼 챗봇은 쓸모없는 거 아니야?”라고 생각할 수도 있다. 절대 아니다. 오히려 반대다.

AI가 ‘못 끝내는 일’을 명확히 알기 때문에, AI가 ‘잘하는 일’에 더 집중할 수 있다.

8년간 챗봇이 해온 일을 정리하면 이렇다.

1. 단순 반복 업무의 즉시 처리. 잔액 조회, 이체 한도 확인, 카드 분실 신고, 비밀번호 재설정. 이런 것들은 사람이 할 이유가 없다. 365일 24시간 즉시 처리. 이것만으로도 고객 만족도가 크게 올랐다.

2. 상담사의 업무 부하 분산. 단순 문의를 챗봇이 처리해주니까, 상담사가 복잡한 건에 더 집중할 수 있게 됐다. 상담사 1인당 복잡 민원 처리량이 3년 전 대비 40% 늘었다. 사람이 사람다운 일에 집중할 수 있게 된 것이다.

3. 사전 정보 수집과 라우팅. 고객이 상담사와 연결되기 전에, 챗봇이 기본 정보를 수집하고 문제를 분류한다. 상담사가 전화를 받는 순간 이미 고객의 상황을 70% 파악한 상태로 시작할 수 있다. 이것이 체감 상담 품질을 엄청나게 올린다.

4. 이상 징후 감지. 보이스피싱 의심 패턴, 비정상적 거래 시도, 본인 인증 실패 반복 등을 실시간으로 감지해서 경보를 울린다. 사람이 24시간 모니터링할 수 없는 영역을 AI가 보완한다.

5. 상담 품질 데이터 축적. 모든 대화가 로그로 남는다. 이 데이터를 분석하면 고객 니즈의 트렌드, 불만의 패턴, 규정의 사각지대를 발견할 수 있다. 이 인사이트가 다시 서비스 개선으로 이어진다.

정리하면, 금융 챗봇의 진짜 가치는 ‘사람을 대체하는 것’이 아니라 ‘사람이 더 잘 일할 수 있게 만드는 것’이다. 이것이 8년간의 결론이다.

현장에서 만난 오해 세 가지

금융 챗봇을 운영하면서 가장 많이 들은 오해들이 있다. 이 자리에서 정리해두고 싶다.

오해 1: “AI가 더 발전하면 상담사가 필요 없어질 것이다”

앞서 말한 ‘라스트 마일 역설’이 답이다. AI가 발전할수록 남은 문제의 난이도가 올라간다. 단순 문의가 사라진 자리를 복잡한 문의가 채운다. 상담사의 역할은 사라지는 게 아니라 바뀌는 것이다. 키보드로 잔액을 알려주던 상담사가, 이제는 고객의 인생 상황에 맞는 금융 조언을 하는 전문가로 진화하고 있다.

실제로 우리 조직에서 최근 3년간 상담사 인력은 줄지 않았다. 대신 채용 기준이 바뀌었다. 이전에는 “빠르고 정확한 정보 전달”이 핵심 역량이었다면, 지금은 “복잡한 상황에서의 판단력과 공감 능력”이 핵심이다.

오해 2: “챗봇의 성공 지표는 자체 해결률이다”

초기에는 우리도 이렇게 생각했다. 챗봇이 상담사 도움 없이 자체적으로 해결한 비율이 높을수록 좋은 챗봇이라고. 그래서 자체 해결률을 KPI로 잡았다.

결과는 재앙이었다. 자체 해결률을 올리려고 하니, 챗봇이 상담사 연결을 회피하게 됐다. 고객이 “사람하고 얘기하고 싶다”고 해도 “제가 도와드릴 수 있습니다, 어떤 문제인가요?”라고 버티는 봇. 고객 만족도가 급락했다.

지금 우리의 핵심 지표는 ‘적시 에스컬레이션율’이다. 사람이 개입해야 할 상황에서 적절한 시점에 사람에게 넘겼느냐. 너무 빨리 넘기면(챗봇이 할 수 있는 건데 바로 넘기면) 비효율적이고, 너무 늦게 넘기면(사람이 필요한데 버티면) 고객이 떠난다. 이 타이밍을 맞추는 것이 챗봇의 가장 중요한 능력이다.

챗봇 핵심 지표 변화: 자체해결률에서 적시 에스컬레이션율로

오해 3: “대화형 AI면 충분하다”

금융 챗봇을 “대화형 AI”로만 보면 절반만 보는 것이다. 금융 챗봇은 대화 인터페이스를 가진 업무 자동화 시스템이다. 뒤에는 계정 시스템, 카드 시스템, 대출 시스템, 보험 시스템, 컴플라이언스 시스템이 연결돼 있다. 대화는 빙산의 일각이다.

대화 자체를 아무리 자연스럽게 만들어도, 뒤의 시스템이 받쳐주지 않으면 소용없다. “잔액 알려줘”라는 말을 이해하는 건 대화 AI의 몫이지만, 실제로 잔액을 조회하는 건 코어뱅킹 시스템의 몫이다. 그리고 이 두 세계를 안전하게 연결하는 건 엔지니어링의 몫이다.

금융 챗봇의 난이도는 “대화를 얼마나 잘 하느냐”가 아니라 “대화 뒤에서 일어나는 업무 처리를 얼마나 안전하고 정확하게 하느냐”에 있다.

끝맺음의 기술: 사람에게 필요한 새로운 역량

AI가 끝맺지 못하는 일을 사람이 해야 한다면, 그 사람에게는 어떤 역량이 필요할까? 이것도 8년간 현장에서 관찰한 내용이다.

역량 1: 맥락 전환 능력

AI가 만들어놓은 대화 요약을 빠르게 읽고, 3초 안에 상황을 파악하는 능력. 상담사가 전화를 받는 순간 “아, 이 고객은 이런 상황이구나”를 바로 잡아야 한다. 예전에는 고객이 처음부터 설명했지만, 이제는 AI가 정리해놓은 맥락 위에서 시작하는 거다. 이것은 새로운 종류의 읽기 능력이다.

역량 2: 감정 해독력

“화난 고객”과 “두려운 고객”은 표면적으로 비슷해 보인다. 둘 다 목소리가 높고, 빨리 해달라고 다그친다. 하지만 대응 방법은 완전히 다르다. 화난 고객에게는 공감과 사과가 먼저고, 두려운 고객에게는 안심이 먼저다. AI의 감정 분석은 “부정적 감정”이라고만 알려준다. 그 안에서 화, 두려움, 실망, 억울함을 구분하는 건 사람의 몫이다.

역량 3: 판단의 설명 능력

회색 지대에서 판단을 내렸다면, 그 판단의 이유를 고객에게 설명할 수 있어야 한다. “규정이 이래서요”가 아니라, “고객님의 상황을 이렇게 이해했고, 이 규정을 이렇게 적용한 결과입니다”라고. 이것은 규정에 대한 깊은 이해와, 그것을 일반인의 언어로 번역하는 능력이 동시에 필요한 일이다.

역량 4: 기술과의 협업 감각

AI가 만들어놓은 정보를 활용하되, 맹목적으로 따르지 않는 능력. AI가 “이 고객은 이탈 위험이 높습니다”라고 분석했어도, 실제 대화에서 “아, 이건 이탈이 아니라 단순히 궁금한 거구나”라고 판단할 수 있어야 한다. AI의 분석을 참고하되 무비판적으로 수용하지 않는, 건강한 회의를 유지하는 것.

역량 5: 종결의 타이밍 감각

언제 “더 궁금하신 건 없으시죠?”라고 물어야 하는지. 이 타이밍이 빠르면 고객은 “나를 빨리 끊으려고 한다”고 느끼고, 늦으면 불필요하게 시간을 잡아먹는다. 이것은 매뉴얼로 정할 수 없는, 순전히 경험과 감에 의존하는 영역이다.

1화에서 4화까지, 이제 보이는 그림

잠깐 뒤를 돌아보자.

1화에서는 AI 도입 후 오히려 더 바빠진 현실을 이야기했다. 2화에서는 ‘휴먼 인 더 루프’라는 개념이 어떻게 오해되고 있는지 살펴봤다. 3화에서는 AI를 잘 쓰는 팀과 못 쓰는 팀의 차이가 피드백 루프에 있다는 것을 확인했다.

그리고 오늘 4화에서 금융이라는 구체적인 도메인에서, AI가 절대 혼자 끝맺지 못하는 일의 실체를 들여다봤다.

이 네 편을 관통하는 메시지는 하나다. AI의 가치는 사람을 대체하는 데서 오는 것이 아니라, 사람이 사람만이 할 수 있는 일에 집중할 수 있게 만드는 데서 온다.

그런데 여기서 자연스러운 의문이 생긴다. 그렇다면 그 ‘사람만이 할 수 있는 일’이란 정확히 무엇이고, 그것은 미래에도 계속 사람의 영역으로 남을까? AI가 계속 발전하면, 지금 “사람만 할 수 있다”고 말한 것들도 결국 AI가 하게 되지 않을까?

솔직히 말하면, 나도 이 질문에 100% 확답을 못 한다. 다만 8년간의 경험에서 얻은 잠정적인 답은 있다.

기술은 끊임없이 ‘할 수 있는 것’의 경계를 넓히지만, ‘해도 되는 것’의 경계는 기술만으로 넓어지지 않는다. 규제, 윤리, 사회적 합의, 그리고 무엇보다 “누가 책임지느냐”라는 질문. 이것들이 기술의 경계를 다시 좁힌다. 그리고 그 좁혀진 영역, 기술이 할 수 있지만 해서는 안 되는 영역 — 그곳이 바로 사람의 자리다.

현장의 목소리: 같이 일하는 사람들의 한마디

마지막으로, 현장에서 함께 일하는 동료들이 했던 말 중 기억에 남는 것들을 옮긴다. 물론 익명이다.

상담사 A (경력 12년): “예전엔 하루에 100통 받으면 80통이 잔액 조회 같은 거였어요. 지금은 100통 중 80통이 진짜 상담이에요. 일은 줄지 않았는데, 일의 밀도가 완전히 바뀌었어요. 솔직히 더 피곤해요. 근데 더 보람 있어요.”

개발자 B (경력 7년): “챗봇 만들 때 제일 어려운 건 대화를 자연스럽게 만드는 게 아니에요. ‘여기서 사람한테 넘겨야 해’를 판단하는 로직을 만드는 게 열 배 더 어려워요. 그리고 그걸 만든 뒤에도, 현장에서 계속 수정해야 해요. 한번 짜면 끝인 코드가 아니에요.”

컴플라이언스 담당자 C (경력 15년): “AI가 잘못 안내해서 고객이 손해를 봤다. 이런 민원이 들어오면 우리는 어떻게 해야 하나요? 규정은 아직 이 상황을 충분히 다루지 못해요. 기술이 규제보다 빨리 가는 게 항상 문제입니다.”

팀장 D (경력 20년): “나는 챗봇을 도입한 가장 큰 성과가 뭔지 알아? 우리가 ‘진짜 상담이 뭔지’ 다시 생각하게 된 거야. 예전엔 잔액 알려주는 것도 상담이라고 생각했거든. 지금은 아니지. 그건 정보 제공이야. 상담은 사람만 할 수 있는 거야.”

이번 주 한 줄 노트

AI에게 ‘답변’을 맡기고, 사람에게 ‘끝맺음’을 맡겨라. 고객은 정보가 아니라 종결을 원한다.

이 한마디가 8년 운영의 가장 짧은 요약이다. 회사 공식 입장이 아닌, 8년간 관제 화면 앞에서 수만 건의 대화 로그를 읽은 한 사람의 개인적 결론이다.


다음 5화에서는 시야를 넓혀, AI와 사람 사이의 ‘신뢰’라는 문제를 다뤄보려 한다. 금융만이 아니라 의료, 법률, 교육까지 — 고위험 영역에서 사람들은 왜 AI를 ‘알면서도’ 완전히 믿지 못할까? 그리고 그 불신은 합리적인 것일까, 아니면 극복해야 할 편견일까? 실무자의 관점에서 이야기하겠다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.


📚 시리즈: 휴먼 인 더 루프(Human-in-the-Loop): AI 시대, 사람만 할 수 있는 일 (총 12화 중 4화)
이전 3화  (다음 차수는 아직 게시되지 않았습니다)
작성일 댓글 남기기

Open WebUI 설치 가이드 – 내 PC에 ChatGPT 대안 무료 구축법

Open WebUI AI 채팅 인터페이스가 표시된 노트북 화면

ChatGPT 구독료 없이 나만의 AI 채팅 서비스를 만들 수 있다면?

ChatGPT Plus는 월 20달러, Team은 월 30달러입니다. Claude Pro도 비슷한 가격이죠. AI를 업무에 적극 활용하는 분이라면 이 비용이 결코 적지 않습니다. 특히 가족이나 팀원 여러 명이 사용해야 한다면 부담은 배로 늘어나고요.

그런데 내 PC나 서버에 ChatGPT와 똑같은 형태의 AI 채팅 인터페이스를 설치하고, 완전히 무료로 운영할 수 있는 오픈소스 프로젝트가 있습니다. 바로 Open WebUI입니다.

Open WebUI는 GitHub 스타 수 10만 개를 돌파한 초대형 오픈소스 프로젝트로, Ollama에서 실행하는 로컬 AI 모델은 물론 OpenAI·Claude·Gemini 같은 외부 API까지 하나의 깔끔한 웹 인터페이스에서 관리할 수 있게 해줍니다. 대화 기록 저장, 프롬프트 템플릿, 파일 업로드, RAG, 멀티유저 관리까지 ChatGPT에서 제공하는 거의 모든 기능을 갖추고 있습니다.

이 글에서는 Docker를 이용해 Open WebUI를 설치하고, 로컬 AI 모델과 외부 API를 연결하여 실제로 사용 가능한 나만의 AI 채팅 환경을 완성하는 과정을 처음부터 끝까지 안내합니다. 컴퓨터에 Docker만 설치되어 있다면 10분이면 충분합니다.

Open WebUI 시스템 아키텍처 구성도

Open WebUI란 무엇인가

핵심 개념과 특징

Open WebUI(구 Ollama WebUI)는 LLM(대형 언어 모델)을 위한 셀프호스팅 웹 인터페이스입니다. 쉽게 말해 ChatGPT 웹사이트와 동일한 형태의 대화형 AI 채팅 화면을 내 서버에 직접 설치해서 운영하는 것입니다.

기존에 Ollama를 터미널에서만 사용해본 분이라면, 검은 화면에 텍스트만 오가는 방식이 불편했을 겁니다. Open WebUI는 이 문제를 완벽하게 해결합니다. 브라우저만 열면 ChatGPT와 거의 동일한 UI에서 AI와 대화할 수 있습니다.

Open WebUI의 핵심 특징을 정리하면 이렇습니다.

  • 완전 무료 오픈소스 – MIT 라이선스로 상업적 사용까지 자유롭습니다
  • Ollama 네이티브 연동 – 로컬에서 실행 중인 모든 Ollama 모델을 자동 인식합니다
  • OpenAI API 호환 – GPT-4o, Claude, Gemini 등 외부 API도 동시에 연결 가능합니다
  • 멀티유저 지원 – 가족이나 팀원 각각 별도 계정으로 사용할 수 있습니다
  • 대화 기록 영구 보관 – 모든 대화가 로컬 데이터베이스에 저장됩니다
  • RAG(문서 기반 응답) – PDF, 텍스트 파일을 업로드하면 해당 내용 기반으로 답변합니다
  • 프롬프트 라이브러리 – 자주 쓰는 프롬프트를 저장하고 공유할 수 있습니다
  • 이미지 생성 통합 – AUTOMATIC1111이나 ComfyUI와 연동해 이미지 생성도 가능합니다
  • 모바일 반응형 – 스마트폰 브라우저에서도 최적화된 화면으로 사용됩니다

ChatGPT와 비교했을 때의 장단점

솔직하게 비교하면, ChatGPT Plus가 제공하는 최신 GPT-4o 모델의 성능 자체를 로컬 모델이 완벽히 따라잡기는 어렵습니다. 하지만 Open WebUI만의 분명한 강점이 있습니다.

Open WebUI가 유리한 점:

  • 월 구독료가 없습니다. 전기료만 나갑니다
  • 인터넷이 끊겨도 로컬 모델로 동작합니다
  • 모든 대화 데이터가 내 서버에만 저장되어 프라이버시가 완벽합니다
  • 사용 횟수 제한이 없습니다. 하루에 몇 백 번을 물어봐도 됩니다
  • 여러 명이 동시에 사용해도 추가 비용이 없습니다
  • 다양한 모델을 한 화면에서 전환하며 비교할 수 있습니다

ChatGPT가 유리한 점:

  • 설치 과정 없이 바로 사용 가능합니다
  • GPT-4o 최신 모델의 추론 성능이 뛰어납니다
  • 플러그인 생태계가 더 풍부합니다
  • 서버 관리 부담이 없습니다

결론적으로, 프라이버시를 중시하거나 여러 명이 비용 없이 AI를 활용하고 싶다면 Open WebUI가 최적의 선택입니다. 특히 이미 NAS나 홈서버를 운영 중인 분이라면 설치 난이도도 매우 낮습니다.

설치 전 준비사항

시스템 요구사항 확인

Open WebUI 자체는 가벼운 웹 애플리케이션이라 거의 모든 PC에서 실행됩니다. 다만 로컬 AI 모델을 함께 돌리려면 어느 정도의 하드웨어가 필요합니다.

Open WebUI만 설치하는 경우(외부 API 사용):

  • RAM: 2GB 이상
  • 저장 공간: 1GB 이상
  • CPU: 특별한 요구사항 없음
  • GPU: 불필요

Ollama + Open WebUI 함께 사용하는 경우:

  • RAM: 8GB 이상(7B 모델 기준), 16GB 이상 권장
  • 저장 공간: 10GB 이상(모델 크기에 따라 다름)
  • GPU: NVIDIA GPU 6GB VRAM 이상 권장(없어도 CPU로 실행 가능하나 느림)

참고로 외부 API(OpenAI, Claude 등)만 사용할 계획이라면 Raspberry Pi 같은 초소형 장비에서도 Open WebUI를 운영할 수 있습니다. 무거운 건 AI 모델 실행이지, 웹 인터페이스 자체는 가볍습니다.

Docker 설치 확인

Open WebUI는 Docker로 설치하는 것이 가장 간편합니다. 아직 Docker가 설치되어 있지 않다면, 운영체제별로 설치 방법이 다릅니다.

Windows: Docker Desktop을 공식 사이트에서 다운로드하여 설치합니다. WSL2 백엔드가 자동으로 설정됩니다.

macOS: Docker Desktop for Mac을 공식 사이트에서 다운로드합니다. Apple Silicon(M1 이상)과 Intel 모두 지원합니다.

Linux(Ubuntu/Debian):

sudo apt update
sudo apt install docker.io docker-compose-plugin
sudo systemctl enable --now docker
sudo usermod -aG docker $USER

설치 후 터미널에서 아래 명령어로 정상 동작을 확인합니다.

docker --version
docker compose version

두 명령어 모두 버전 정보가 출력되면 준비 완료입니다.

Ollama 설치(선택사항)

로컬 AI 모델을 사용하려면 Ollama가 필요합니다. 이미 설치되어 있다면 이 단계를 건너뛰세요.

Windows/macOS: Ollama 공식 사이트(ollama.com)에서 설치 파일을 다운로드합니다.

Linux:

curl -fsSL https://ollama.com/install.sh | sh

설치 후 기본 모델 하나를 미리 다운로드해둡니다.

ollama pull llama3.1:8b

llama3.1:8b는 약 4.7GB 크기로, 8GB RAM 이상의 PC에서 쾌적하게 동작하는 범용 모델입니다. 한국어 성능도 상당히 좋아서 일상적인 질문에 충분히 활용할 수 있습니다.

Open WebUI Docker 설치 3단계 일러스트

Open WebUI 설치하기

방법 1: Ollama와 함께 설치(가장 일반적)

이미 PC에 Ollama가 설치되어 실행 중인 상태라면, Docker 명령어 한 줄로 Open WebUI를 설치할 수 있습니다.

docker run -d \
  --name open-webui \
  --restart always \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  --add-host=host.docker.internal:host-gateway \
  ghcr.io/open-webui/open-webui:main

각 옵션의 의미를 하나씩 살펴보겠습니다.

  • -d – 백그라운드에서 실행합니다
  • –name open-webui – 컨테이너 이름을 open-webui로 지정합니다
  • –restart always – PC를 재시작해도 자동으로 다시 실행됩니다
  • -p 3000:8080 – 브라우저에서 3000번 포트로 접속합니다
  • -v open-webui:/app/backend/data – 대화 기록 등 데이터를 영구 보관합니다
  • –add-host=host.docker.internal:host-gateway – 컨테이너 내부에서 호스트 PC의 Ollama에 접근할 수 있게 합니다

실행 후 브라우저에서 http://localhost:3000에 접속하면 Open WebUI 초기 설정 화면이 나타납니다.

방법 2: Ollama를 Docker에 포함해서 한 번에 설치

Ollama를 별도로 설치하지 않고 Docker 안에서 모두 해결하고 싶다면, 번들 이미지를 사용합니다. NVIDIA GPU가 있는 경우 아래 명령어를 사용합니다.

docker run -d \
  --name open-webui \
  --restart always \
  -p 3000:8080 \
  --gpus all \
  -v ollama:/root/.ollama \
  -v open-webui:/app/backend/data \
  ghcr.io/open-webui/open-webui:ollama

GPU가 없는 경우에는 –gpus all 옵션만 제거하면 됩니다. CPU로도 실행은 가능하지만 응답 속도가 다소 느릴 수 있습니다.

방법 3: Docker Compose로 설치(권장)

장기적으로 관리하기 가장 편한 방법은 Docker Compose 파일을 작성하는 것입니다. 나중에 설정 변경이나 업데이트가 쉬워집니다.

작업 디렉토리를 만들고 docker-compose.yml 파일을 생성합니다.

mkdir ~/open-webui && cd ~/open-webui

docker-compose.yml 파일 내용은 아래와 같습니다.

version: '3.8'

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: always
    ports:
      - "3000:8080"
    volumes:
      - open-webui-data:/app/backend/data
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      - OLLAMA_BASE_URL=http://host.docker.internal:11434
      - WEBUI_SECRET_KEY=your-secret-key-here
      - ENABLE_SIGNUP=true

volumes:
  open-webui-data:

WEBUI_SECRET_KEY는 세션 암호화에 사용되는 키로, 임의의 긴 문자열로 반드시 변경하세요. 예를 들어 터미널에서 openssl rand -hex 32를 실행하면 안전한 랜덤 키를 생성할 수 있습니다.

파일을 저장한 후 아래 명령어로 실행합니다.

docker compose up -d

로그를 확인하려면 아래 명령어를 사용합니다.

docker compose logs -f open-webui

“Uvicorn running on http://0.0.0.0:8080″이라는 메시지가 보이면 성공입니다.

초기 설정과 기본 사용법

관리자 계정 생성

브라우저에서 http://localhost:3000에 처음 접속하면 회원가입 화면이 나타납니다. 여기서 생성하는 첫 번째 계정이 자동으로 관리자(Admin) 권한을 갖게 됩니다.

이름, 이메일, 비밀번호를 입력하고 가입하면 곧바로 채팅 화면으로 이동합니다. 이 화면이 바로 ChatGPT와 거의 동일한 Open WebUI의 메인 인터페이스입니다.

중요: 가족이나 팀원이 사용할 계정은 이후에 별도로 생성합니다. 첫 번째 계정 생성 후에는 관리자 패널에서 추가 회원가입 허용 여부를 설정할 수 있으니, 보안이 걱정된다면 가입 후 바로 회원가입 기능을 비활성화하는 것을 추천합니다.

Ollama 모델 연결 확인

Ollama가 정상적으로 실행 중이라면, 채팅 화면 상단의 모델 선택 드롭다운에서 Ollama에 설치된 모델 목록이 자동으로 표시됩니다.

만약 모델이 보이지 않는다면 다음 사항을 확인하세요.

  • Ollama가 실행 중인지 확인: 터미널에서 ollama list 명령어로 확인합니다
  • 관리자 패널(좌측 하단 톱니바퀴) → Connections → Ollama API URL이 http://host.docker.internal:11434로 설정되어 있는지 확인합니다
  • 방화벽이 11434 포트를 차단하고 있지 않은지 확인합니다

모델이 정상적으로 인식되면 드롭다운에서 원하는 모델을 선택하고 바로 대화를 시작할 수 있습니다. Open WebUI 내에서 새 모델을 다운로드하는 것도 가능합니다. 관리자 패널에서 모델 이름(예: gemma2:9b)을 입력하면 Ollama를 통해 자동으로 다운로드됩니다.

Open WebUI 대시보드 채팅 화면 예시

외부 API 연결하기(OpenAI, Claude 등)

로컬 모델만으로는 성능이 아쉬운 작업이 있을 수 있습니다. 복잡한 코딩이나 긴 문서 분석 같은 경우죠. 이럴 때 외부 API를 함께 연결하면 상황에 따라 적절한 모델을 선택해서 사용할 수 있습니다.

OpenAI API 연결:

  1. 관리자 패널 → Connections → OpenAI API 섹션으로 이동합니다
  2. API URL: https://api.openai.com/v1
  3. API Key: OpenAI에서 발급받은 API 키를 입력합니다
  4. 저장 후 모델 목록에 gpt-4o, gpt-4o-mini 등이 추가로 표시됩니다

Claude API 연결:

Claude API는 OpenAI 호환 형식이 아니므로 직접 연결이 안 됩니다. 대신 LiteLLM Proxy라는 중간 서비스를 사용하면 Claude를 포함한 거의 모든 AI API를 OpenAI 호환 형식으로 변환해서 사용할 수 있습니다.

docker run -d \
  --name litellm \
  --restart always \
  -p 4000:4000 \
  -e ANTHROPIC_API_KEY=your-anthropic-key \
  ghcr.io/berriai/litellm:main-latest \
  --model anthropic/claude-sonnet-4-20250514

이후 Open WebUI의 OpenAI API 설정에서 URL을 http://host.docker.internal:4000/v1로 지정하면 Claude 모델도 Open WebUI에서 사용할 수 있게 됩니다.

이렇게 설정하면 하나의 인터페이스에서 로컬 Llama 모델, GPT-4o, Claude를 자유롭게 전환하며 사용할 수 있습니다. 간단한 질문은 무료 로컬 모델로, 복잡한 작업은 유료 API로 나눠 쓰면 비용 효율이 극대화됩니다.

실전 활용: 업무 효율을 높이는 고급 기능

프롬프트 템플릿으로 반복 작업 자동화

매번 비슷한 형태의 질문을 하고 있다면 프롬프트 템플릿을 활용하세요. Open WebUI의 Workspace → Prompts 메뉴에서 자주 쓰는 프롬프트를 저장할 수 있습니다.

예를 들어 이런 템플릿을 만들어둘 수 있습니다.

이메일 답장 작성기:

아래 이메일에 대한 정중하고 전문적인 답장을 작성해줘.
톤: {{tone}}
원본 이메일:
{{email_content}}

코드 리뷰어:

아래 코드를 리뷰해줘. 버그, 성능 이슈, 보안 취약점을 중점적으로 확인하고
개선 방안을 코드와 함께 제시해줘.
언어: {{language}}
코드:
{{code}}

회의록 정리:

아래 회의 내용을 정리해줘.
형식: 1) 핵심 논의사항 2) 결정 사항 3) 액션 아이템(담당자, 기한)
회의 내용:
{{meeting_notes}}

이중 중괄호({{ }})로 감싼 부분은 사용 시 실제 내용으로 교체하는 변수입니다. 채팅창에서 슬래시(/)를 입력하면 저장된 템플릿 목록이 나타나고, 선택하면 자동으로 프롬프트가 채워집니다.

RAG로 내 문서 기반 AI 상담사 만들기

Open WebUI의 가장 강력한 기능 중 하나가 RAG(Retrieval-Augmented Generation)입니다. PDF, 텍스트 파일, 웹 페이지를 업로드하면 AI가 해당 문서의 내용을 기반으로 답변합니다.

문서 업로드 방법:

  1. 좌측 사이드바의 Workspace → Knowledge 메뉴로 이동합니다
  2. 새로운 Knowledge Collection을 생성합니다(예: “회사 규정집”)
  3. 관련 PDF 파일들을 드래그앤드롭으로 업로드합니다
  4. 채팅할 때 # 기호를 입력하면 Knowledge Collection 목록이 나타납니다
  5. 원하는 Collection을 선택하면 해당 문서 기반으로 답변합니다

실생활에서 유용한 활용 사례를 몇 가지 소개합니다.

  • 보험 약관 분석 – 보험 약관 PDF를 업로드하고 “내 보험에서 치과 치료비가 보장되는 조건이 뭐야?”라고 물으면 약관 내용에서 정확히 찾아 답변합니다
  • 사내 위키 검색 – 회사의 사내 문서를 업로드하면 신입 사원 온보딩 질문 답변 AI가 됩니다
  • 요리 레시피북 – 가지고 있는 요리책 PDF를 업로드하고 “냉장고에 닭가슴살이랑 브로콜리가 있는데 뭘 만들 수 있어?”라고 물으면 레시피북에서 적합한 요리를 찾아줍니다
  • 학습 도우미 – 교재 PDF를 업로드하고 “3장 내용을 요약해줘” 또는 “이 개념을 쉽게 설명해줘”라고 활용합니다

모델파일로 나만의 AI 캐릭터 만들기

Open WebUI에서는 Modelfile이라는 기능으로 AI의 성격과 행동을 커스터마이징할 수 있습니다. Workspace → Models 메뉴에서 새 모델을 생성할 때 시스템 프롬프트를 지정하는 방식입니다.

예를 들어 이런 커스텀 모델을 만들 수 있습니다.

영어 회화 선생님:

You are an English conversation tutor for Korean speakers.
Always respond in English first, then provide Korean translation.
Correct any grammar mistakes politely.
Adjust difficulty based on the user's level.
Use everyday conversation topics.

건강 식단 어드바이저:

당신은 영양학 전문가입니다.
사용자의 식단을 분석하고 개선점을 제안합니다.
칼로리, 영양소 균형을 고려한 대안을 제시합니다.
과학적 근거를 함께 설명합니다.
한국 음식 위주로 추천합니다.

이렇게 만든 커스텀 모델은 모델 선택 드롭다운에 별도로 표시되어, 용도에 따라 쉽게 전환할 수 있습니다. 가족 구성원마다 다른 커스텀 모델을 만들어주는 것도 좋은 방법입니다.

웹 검색 통합으로 최신 정보 활용하기

로컬 AI 모델의 가장 큰 한계는 학습 데이터 이후의 최신 정보를 모른다는 점입니다. Open WebUI는 이 문제를 웹 검색 통합으로 해결합니다.

관리자 패널 → Web Search 설정에서 검색 엔진을 연결할 수 있습니다. 지원되는 검색 엔진은 다양합니다.

  • SearXNG(추천) – 셀프호스팅 가능한 메타 검색 엔진으로 무료입니다
  • Google PSE – Google Programmable Search Engine API를 활용합니다
  • Brave Search – 무료 API 제공(월 2000회)
  • DuckDuckGo – 별도 API 키 없이 사용 가능합니다

웹 검색이 활성화되면 채팅창에서 지구본 아이콘을 클릭하거나 대화 중에 AI가 자동으로 최신 정보가 필요하다고 판단하면 웹 검색을 수행합니다. “오늘 서울 날씨 어때?”처럼 실시간 정보가 필요한 질문에도 답변할 수 있게 됩니다.

Open WebUI 핵심 기능 4가지 요약

멀티유저 환경 구성과 보안 설정

가족·팀원 계정 관리

Open WebUI의 큰 장점 중 하나는 여러 사용자가 각자의 계정으로 독립적으로 사용할 수 있다는 점입니다. ChatGPT라면 인당 월 20달러씩 지불해야 하지만, Open WebUI는 사용자를 얼마든지 추가해도 무료입니다.

사용자 추가 방법:

  1. 관리자 패널 → Admin Panel → Users 메뉴로 이동합니다
  2. “Add User” 버튼으로 새 계정을 생성합니다
  3. 권한 레벨을 설정합니다: Admin(관리자), User(일반 사용자), Pending(승인 대기)

권한별 차이점:

  • Admin – 모든 설정 변경, 사용자 관리, 모델 관리 가능
  • User – 채팅, 문서 업로드, 프롬프트 사용 가능. 시스템 설정은 변경 불가
  • Pending – 관리자 승인 전까지 로그인 불가

각 사용자의 대화 기록은 완전히 분리되어 저장됩니다. 부모님이나 자녀에게 계정을 만들어주면 각자 독립적인 AI 비서를 갖게 되는 셈입니다.

외부 접속 보안 강화

집 밖에서도 Open WebUI에 접속하고 싶다면 보안 설정이 중요합니다. 절대로 Open WebUI를 보안 조치 없이 인터넷에 직접 노출하지 마세요.

추천하는 외부 접속 방법(안전한 순서):

  1. Tailscale VPN(가장 추천) – 설치만 하면 어디서든 안전하게 접속 가능합니다. 무료 플랜으로 충분합니다
  2. Cloudflare Tunnel – 도메인이 있다면 Cloudflare Zero Trust와 함께 사용합니다. 추가 인증 레이어를 걸 수 있습니다
  3. Nginx + SSL + HTTP Basic Auth – 리버스 프록시 앞에 기본 인증을 추가하는 전통적 방법입니다

환경 변수에서 반드시 설정해야 할 보안 관련 항목들입니다.

# 회원가입 비활성화 (관리자가 직접 계정 생성)
ENABLE_SIGNUP=false

# 세션 시크릿 키 변경 (기본값 사용 금지)
WEBUI_SECRET_KEY=your-long-random-secret-key

# CORS 설정 (특정 도메인만 허용)
CORS_ALLOW_ORIGINS=https://your-domain.com

업데이트와 백업

Open WebUI 업데이트 방법

Open WebUI는 활발하게 개발되는 프로젝트라 매주 새 기능과 버그 수정이 릴리즈됩니다. Docker로 설치했다면 업데이트가 매우 간단합니다.

Docker run으로 설치한 경우:

# 최신 이미지 다운로드
docker pull ghcr.io/open-webui/open-webui:main

# 기존 컨테이너 중지 및 삭제
docker stop open-webui
docker rm open-webui

# 동일 옵션으로 재실행 (볼륨이 유지되므로 데이터 보존)
docker run -d \
  --name open-webui \
  --restart always \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  --add-host=host.docker.internal:host-gateway \
  ghcr.io/open-webui/open-webui:main

Docker Compose로 설치한 경우:

docker compose pull
docker compose up -d

Compose를 사용하면 단 두 줄로 업데이트가 완료됩니다. 이것이 Docker Compose를 권장하는 이유 중 하나입니다.

데이터 백업

Open WebUI의 모든 데이터(대화 기록, 사용자 정보, 프롬프트, 설정)는 Docker 볼륨에 저장됩니다. 정기적으로 백업하는 것을 추천합니다.

수동 백업:

# 볼륨 데이터를 tar 파일로 백업
docker run --rm \
  -v open-webui:/data \
  -v $(pwd):/backup \
  alpine tar czf /backup/open-webui-backup-$(date +%Y%m%d).tar.gz -C /data .

관리자 패널에서 내보내기:

Open WebUI 관리자 패널 → Database 메뉴에서 “Export” 버튼을 클릭하면 전체 데이터를 JSON 파일로 내보낼 수 있습니다. 이 방법이 더 간편하고 다른 Open WebUI 인스턴스로 마이그레이션할 때도 유용합니다.

복원이 필요할 때는 같은 메뉴에서 “Import”를 선택하고 백업 파일을 업로드하면 됩니다.

추천 모델과 용도별 조합

Open WebUI를 설치했다면 어떤 모델을 사용할지 고민될 수 있습니다. 용도별로 추천 조합을 정리했습니다.

일상 대화·간단한 질문

  • Llama 3.1 8B – 범용 모델, 한국어 성능 양호, 8GB RAM이면 충분
  • Gemma 2 9B – Google 모델, 추론 능력 우수, 비슷한 사양 필요
  • Phi-3 Mini – Microsoft 모델, 매우 가벼움(3.8B), 저사양 PC에 적합

코딩·개발 작업

  • CodeGemma 7B – 코드 생성 특화, 다양한 언어 지원
  • DeepSeek Coder V2 16B – 코딩 벤치마크 상위권, 16GB RAM 권장
  • GPT-4o API(외부) – 복잡한 아키텍처 설계나 디버깅에 활용

한국어 특화 작업

  • EXAONE 3.0 7.8B – LG AI Research의 한국어 특화 모델
  • Qwen 2.5 7B – 한중일 다국어 성능이 뛰어난 Alibaba 모델

고성능이 필요한 전문 작업

  • Llama 3.1 70B – 최상급 로컬 모델, 48GB VRAM 이상 필요(또는 CPU로 느리게 실행)
  • Claude API(외부) – 긴 문서 분석, 복잡한 추론에 최적

실용적인 전략은 이렇습니다. 일상적인 질문은 가벼운 로컬 모델로 무료 처리하고, 정말 복잡하거나 정확도가 중요한 작업에만 유료 API를 선택적으로 사용하는 겁니다. Open WebUI에서 모델 전환은 드롭다운 클릭 한 번이면 되니까요.

마무리: 나만의 AI 플랫폼을 소유한다는 것

Open WebUI를 설치하고 나면, AI 서비스에 대한 관점이 달라집니다. 더 이상 특정 회사의 구독 정책이나 가격 변동에 휘둘리지 않아도 됩니다. 내 대화 데이터가 어디로 가는지 걱정할 필요도 없습니다.

지금 당장 시작해볼 수 있는 단계를 정리하면 이렇습니다.

  1. Docker 설치 확인 (5분)
  2. Open WebUI Docker 컨테이너 실행 (2분)
  3. 관리자 계정 생성 및 Ollama 연결 확인 (3분)
  4. 기본 모델(llama3.1:8b)로 첫 대화 시작
  5. 프롬프트 템플릿 2~3개 만들어보기
  6. 가족 계정 생성 후 함께 활용해보기

총 10분이면 나만의 AI 채팅 서비스가 완성됩니다. ChatGPT Plus 한 달 구독료면 앞으로 영원히 무료로 사용할 수 있는 AI 환경을 갖게 되는 셈입니다. 특히 이미 NAS나 홈서버를 운영하고 계신 분이라면 주저할 이유가 없습니다.

다음에 ChatGPT 구독 갱신 알림이 왔을 때, 한 번쯤 Open WebUI를 떠올려보세요. 생각보다 만족스러운 경험이 될 겁니다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.