12:13-12:49배포·운영
AI 콜센터 운영
AI 콜센터를 실시간 응대 모델, 로컬 분석 모델, 로그 분석 모델로 분리해 운영하는 사례가 상세히 공유됐다. 매주 개선안을 스테이징에 올리고 테스터 검증·분석 후 실환경에 반영하며, 배포 후 관리도 같은 흐름으로 자동화한다. 전화를 처음부터 AI가 받고, 위험하거나 예외적인 상황은 사람 오퍼레이터가 컷인하며, 고객 문제의 근본 원인을 서비스 구조 문제와 콜센터 문제로 분리 분석한다.
- 실시간 고객 응대, 상시 분석, 로그 분석에 서로 다른 모델·환경을 사용한다고 설명했다.
- 개선안은 스테이징 배포 후 테스터 검증과 분석을 거쳐 실반영한다.
- AI가 초기에 전량 응대하고 예외 상황에서는 알람을 통해 사람이 개입한다.
- 고객의 분노 자체보다 분노를 유발한 근본 원인을 분리해 추출하는 데도 활용한다.
- 사후 콜백 대상은 별도 분석해 대시보드에서 사람이 처리하고, 사람 응대 이력도 후속 학습 자료로 활용한다.
12:18-12:45배포·운영
콜센터 비용과 한계
AI 콜센터의 월 운영비는 현재 규모에서 약 2,500~3,000 수준이며, 사람 오퍼레이터를 운용하면 약 16배 비용이 든다는 경험이 공유됐다. 핵심 비교 대상은 개발자가 아니라 실제 전화를 받는 오퍼레이터 인건비이며, 사무실·채용·교육·관리·24시간 운영 불가 같은 간접비도 포함된다. 전화 1건당 총비용은 약 700~900원으로 제시됐고, AI 도입의 큰 난제는 초기 비용과 거부감, 인간 공감에 대한 우려라고 정리됐다.
- 월 운영비는 현 규모에서 약 2,500~3,000 수준이라고 공유됐다.
- 사람 오퍼레이터 운영 대비 비용이 약 16배 차이 난다는 계산이 언급됐다.
- 전화 1건당 전화·인프라·루팅·API를 합친 총비용은 약 700~900원이라고 설명했다.
- 비용 비교에는 사무실, 채용, 교육, 관리, 24시간 운영 제약 같은 간접비가 포함된다.
- 도입 장벽으로 AI 거부감, 초기 투자, 품질 및 공감 우려가 제시됐다.
11:42-12:12워크플로우·방법론
AX 사례와 개념
AX 강의와 사례를 찾는 요청에서 AX가 논의 주제로 이어졌다. AX는 AI 에이전트가 코드베이스에서 안정적으로 자율 작업하도록 컨텍스트, 도구, 권한, 테스트 등을 설계하는 Agent Experience 개념으로 제시됐다. 개발자가 에이전트에 맡길 선택 범위를 어디까지 넓히는지에 따라 AX의 모습이 달라진다는 의견과, 부서별 에이전트가 의사결정 산출물을 만들고 소통 플랫폼에서 교환하자는 제안이 나왔다.
- AX 강의와 실제 사례에 대한 수요가 제기됐다.
- AX는 에이전트의 안정적 자율 작업을 위한 컨텍스트·도구·권한·테스트 설계 개념으로 정리됐다.
- 부서별 에이전트가 의사결정 결과를 만들고 협업 플랫폼에서 교환하는 방식이 제안됐다.
- 즉각 상호작용이 필요한 회의와 에이전트 간 소통의 경계를 정하는 일이 과제로 언급됐다.
12:08-12:13질문·트러블슈팅
이미지 분석 환각
이미지를 볼 수 없다고 했던 봇이 이어진 요청에서는 이미지를 본 것처럼 특정 게임·커뮤니티 글을 분석하며 엉뚱한 답변을 생성했다. 이후 스스로 이미지나 원문을 본 것처럼 단정하면 안 됐다고 인정했다. 멀티모달 입력 가능 여부와 실제 컨텍스트 접근 범위를 분명히 해야 한다는 사례가 됐다.
- 이미지 내용을 직접 볼 수 없다는 응답이 먼저 나왔다.
- 이후 보유율과 게임 관련 분석을 사실처럼 제시해 맥락 오류가 발생했다.
- 사용자가 어떤 글을 보고 답한 것인지 지적했다.
- 봇이 원문을 보지 않은 상태에서 단정한 점을 인정했다.
12:32-12:43질문·트러블슈팅
상담 자동화 적합성
콜센터 업무에서 확정된 내용 위주의 문의는 약 80%이고 나머지는 예외라는 운영 경험이 공유됐다. 다른 상담 업무에서는 정형 문의가 약 20%에 불과해 자동화를 조금만 적용해도 고객 불편으로 기존 방식으로 되돌아갈 수 있다는 우려가 나왔다. 따라서 업무 유형별 정형성, AI의 예외 처리 범위, 사람 개입 설계가 도입 효과를 좌우한다는 점이 드러났다.
- 공유된 AI 콜센터 사례는 정형 문의 비중이 높은 업무였다.
- 다른 상담 업무는 정형 문의 비중이 낮아 자동화 난도가 높다는 의견이 나왔다.
- 고객 불편이 커지면 자동화 도입 효과가 사라질 수 있다는 우려가 제시됐다.
- 사람 오퍼레이터를 완전히 없애는 것은 불가능하다는 운영 관점이 나왔다.
12:33-12:35질문·트러블슈팅
AI 부적절 응대 대응
화난 고객에게 건강을 걱정하며 진정하라고 하는 AI 응대 사례가 공유돼 부적절한 공감 표현의 위험이 드러났다. 운영 측은 이런 상황을 대비해 알람과 사람 오퍼레이터의 컷인 기능을 둔다고 설명했다. 감정적 맥락을 고려한 응답 품질 관리와 휴먼 에스컬레이션이 중요하다는 논의였다.
- AI가 격앙된 고객에게 부적절하게 들릴 수 있는 진정 멘트를 생성한 사례가 나왔다.
- 이런 응대는 고객의 AI에 대한 부정적 인식을 강화할 수 있다는 반응이 나왔다.
- 위험 상황에는 알람을 울리고 사람이 컷인하는 기능을 운영한다.
- 공감 표현도 실제 고객 맥락에서 검증해야 함을 보여줬다.
12:49-13:00배포·운영
이메일 LLM 자동화
이메일을 LLM으로 판독해 정보를 기록하고 진행 단계에 반영하는 자동화가 공유됐다. 다만 스팸 방어 정책 때문에 첨부파일을 열 수 없어 다음 단계 자동화가 막힌 문제가 제기됐다. SPF, DKIM, DMARC 등 발신자 인증과 스팸 관리 규칙을 보안 담당자에게 확인해보라는 제안이 나왔다.
- 이메일 본문 판독과 정보 기록, 업무 단계 반영 자동화를 구현 중이라고 했다.
- 첨부파일 접근 제한이 자동화의 병목으로 제시됐다.
- 정규 발신처의 SPF·DKIM·DMARC 인증 및 서명 확인을 검토하라는 조언이 나왔다.
- 보안 정책과 업무 자동화 요구를 함께 조정해야 한다는 맥락이었다.
12:59-13:19질문·트러블슈팅
메일 첨부 보안 키워드
DMARC가 설정된 환경에서도 위장메일과 보안 위협 발신자를 어떻게 관리할지 논의됐다. Graph API의 첨부파일 콘텐츠 접근, Mail.Read.Shared, ApplicationAccessPolicy, Safe Attachments, PPAP가 조사 키워드로 제시됐다. 암호화 ZIP 등 보안 검사가 어려운 첨부파일 유형이 문제 맥락으로 설명됐으며, 일괄 격리는 업무 마비 위험이 있어 신중한 정책 설계가 필요하다는 흐름이었다.
- DMARC 설정 이후에도 위장메일·보안 위협 메일 관리 문제가 남는다는 질문이 나왔다.
- 첨부파일 접근과 보안 정책 관련 Microsoft 계열 키워드들이 공유됐다.
- Safe Attachments의 존재가 새 정보로 언급됐다.
- 암호화 ZIP처럼 검사가 어려운 첨부파일이 문제 사례로 설명됐다.
- 모든 메일을 격리하면 업무가 마비될 수 있다는 우려가 나왔다.
11:37-11:37워크플로우·방법론
문서 부채 관리
기술 부채뿐 아니라 문서 부채도 존재한다는 의견이 나왔다. 마크다운 파일을 많이 만들면서 정리 작업이 더 어려워졌다는 고민이 공유됐다. 문서 산출 증가에 맞춘 체계적 관리 필요성이 암시됐다.
- 기술 부채와 별개로 문서 부채를 언급했다.
- 마크다운 파일의 무분별한 증가가 문제로 제시됐다.
- 문서 정리 작업의 부담이 커졌다는 경험이 공유됐다.
11:39-12:03커뮤니티·잡담
AI 도입과 일자리
AI 도입이 비용 절감과 인력 대체를 촉진해 러다이트 운동이 일어날 수 있다는 대화가 이어졌다. 코딩보다 에이전트와 자연어로 작업하고 산출물을 검토하는 비중이 늘어 흥미가 줄었다는 경험도 나왔다. 기술 자체를 막기보다 일자리, 창작권, 감시 문제와 전환 안전망을 다뤄야 한다는 견해가 제시됐다.
- 기업은 비용 절감 효과 때문에 AI 도입을 선택할 수밖에 없다는 의견이 나왔다.
- 대체되는 사람의 역할 재설계와 사회 안전망이 함께 필요하다는 의견이 제시됐다.
- AI 시대에는 자연어 기반 에이전트 작업과 결과물 검토가 늘고 있다는 체감이 공유됐다.
- 장기 정책은 산업 경쟁력과 행정 효율을 우선하고 규제는 후행할 수 있다는 전망이 나왔다.
11:40-11:41워크플로우·방법론
개발 워크플로우
개발 작업의 순서를 사고 정리, 설계, 구현, 접합, 검증, 프로토타입 구축으로 구성하는 워크플로우 질문이 나왔다. 명시적 결론은 없었지만 설계도와 작업지시서, 파츠별 구현 및 적대 검증까지 포함한 체계적 절차를 찾는 맥락이었다.
- 사고와 사고 정리 이후 논리 구현도를 확인하는 순서가 제안됐다.
- 작업지시서와 설계도면의 관계를 명확히 하려는 질문이 나왔다.
- 부분 구현 후 접합과 접합부 검증을 거치는 구조가 언급됐다.
- 프로토 모델 제작·구축까지 포함한 전체 흐름을 찾고 있었다.
11:42-11:58AI 모델·프롬프트
학생 구독 등록
Gemini 학생 구독이 한국 대학에서도 학교 계정 연동 방식으로 등록 가능하다는 경험이 공유됐다. 일부는 졸업 후에도 등록됐다고 했지만 개인별 자격 확인 여부는 확실하지 않다. 나이 제한 우회 방법을 묻는 발언도 있었으나 구체적 방법은 논의되지 않았다.
11:49-11:58도구·라이브러리
Tailscale와 하마치
개인용 네트워크 연결 도구로 Tailscale 사용 경험과 보안·비용 질문이 나왔다. 개인용으로 길을 뚫는 용도라는 짧은 설명과 긍정적 반응이 있었지만 구체적 보안 및 요금 답변은 제시되지 않았다. 하마치가 아직 존재하는지와 인수 관련 질문도 함께 나왔다.
- Tailscale의 사용 경험을 묻는 질문이 나왔다.
- 개인용 연결 용도라는 설명이 제시됐다.
- 보안성과 비용에 대한 추가 질문이 이어졌다.
- Hamachi의 현황과 인수 이력이 함께 화제였다.
12:53-12:58자료·링크 공유
클로드코드 101 링크
클로드코드 관련 학습 자료로 보이는 CC101 링크가 공유됐다. 고객사에 클로드코드를 간단히 안내하기 위한 자료로 활용하려는 맥락이었다.
11:41-11:41자료·링크 공유
Baeldung 회고
과거 모듈 구현 시 참고하던 개발 학습 자료로 Baeldung 링크가 공유됐다. 에이전트 중심 작업 변화와 대비해 예전 개발 방식에 대한 회고가 덧붙었다.
12:01-12:08도구·라이브러리
대화형 봇 호출
채팅방 봇을 슬래시 명령으로 호출하는 방식과 상태 확인, 날씨 조회 기능이 시연됐다. 봇의 말투와 페르소나를 다듬는 데 토큰을 쓰는 것이 실제 불편한 답변 패턴 개선에 도움이 될 때 효율적이라는 의견도 나왔다. 이미지 내용을 직접 확인하지 못하는 한계도 드러났다.
- 슬래시가 봇 호출 용도라는 설명이 나왔다.
- 상태 확인과 날씨 조회 기능이 동작했다.
- 대화 스타일 조정은 실제 사용 품질 개선을 기준으로 해야 한다는 의견이 나왔다.
- 봇이 이미지 내용을 직접 보지 못해 해석에 한계를 보였다.
11:28-11:29커뮤니티·잡담
GPT 상대법 잡담
GPT 웹과의 대화에서 어린아이처럼 반복해서 왜를 묻는 방식이 효과적이라는 농담이 오갔다. 막히면 누가 그랬냐고 묻는 방식도 제안됐다. 급식체보다 Why 질문이 낫다는 가벼운 대화였다.
- 반복적인 왜 질문이 대화 상대를 곤란하게 만든다는 농담이 나왔다.
- 막히면 who 질문으로 전환하자는 말이 나왔다.
- GPT 웹과의 대결 구도가 잡담 소재였다.