전자기기
서류와 메신저에 치여 살던 컨설팅 부서 아저씨의 AX(AI 전환) 생존기 - 인박스의 배신 편
조회 339 · 공감 0 · 댓글 1
안녕하세요.
평범하게 B2B 자문·컨설팅 부서에서 일하고 있는 직장인입니다.
클리앙에 종종 올라오는 로컬 AI나 업무 자동화 후기들을 재미있게 읽다가, 지난 수개월 동안 편해보겠다고 부서 전용 AI 업무 시스템을 직접 바닥부터 깎으며 겪었던 피땀 눈물 나는 삽질기를 한 번 정리해 보면 재밌겠다 싶어 써봅니다.
사실 이 글도 제 실제 작업 디렉토리를 읽어서 분량과 내용을 정리해달라고 AI한테 시켜서 쓴 글을 토대로 합니다.
글이 꽤 길어질 것 같아 총 3편으로 나누어 올려봅니다.
- 1편: 흩어진 메일·슬랙·캘린더를 하나로 모으려다 겪은 AI의 기상천외한 배신들 (이번 글)
- 2편: 계약서·기안문·견적서 자동화와 돈(재무/정산) 앞에서 벌어진 대참사
- 3편: 클라우드비 아끼려다 서버가 잠든 사연, 그리고 폭주하는 AI 코딩 에이전트에게 '헌법'을 씌우기까지
1. 왜 멀쩡한 현업 부서에서 직접 시스템을 깎기 시작했나
겉으로 보기에 컨설팅이나 전문 자문 부서라고 하면 그럴싸한 기획서 쓰고 고객사 미팅하는 스마트한 모습을 상상하시겠지만, 실상을 까보면 거대한 수작업 행정 노가다 집합소에 가깝습니다.
하루 일과를 돌아보면 기가 막힙니다. 아침에 출근하면 지메일로 고객사 문의와 첨부파일이 쏟아지고, 슬랙에서는 수십 개 채널과 개인 DM으로 실무 논의가 오가며, 공용 구글 캘린더에는 미팅 일정이 제각각 올라옵니다. 문제는 이 정보들이 전부 파편화되어 있다는 겁니다.
- "어제 A 고객사 담당자가 메일로 보낸 수정 요청 사항 어디 갔지?"
- "지난주 슬랙에서 이야기했던 외주 단가 합의 내용이 어느 채널에 있더라?"
- "사내 웹메일 대용량 첨부파일 링크가 30일 지나서 만료됐네? 누가 백업 안 해뒀어?"
본업인 자문과 기획에 써야 할 에너지를 이메일 뒤적거리고, 엑셀 칸 맞추고, 그룹웨어 기안문 복붙하는 데 다 쓰고 있더라고요.
"이러다간 서류 더미에 깔려 죽겠다"는 위기감이 들어서, 결국 AI 코딩 에이전트를 붙잡고 우리 부서에서만 사용하는 부서 전용 통합 시스템을 직접 만들기 시작했습니다.
처음엔 참 순진했습니다. "요즘 LLM 성능이 저렇게 좋은데, 메일이랑 슬랙 다 긁어와서 AI한테 던져주면 알아서 프로젝트별로 예쁘게 정리해 주겠지?" 라고 생각했거든요. 그리고 가동 첫 주부터 온갖 기상천외한 일들이 터지기 시작합니다.
2. "네, 감사합니다" 한 줄에도 꼬박꼬박 과금되던 토큰 먹는 하마
제일 먼저 만든 건 지메일, 슬랙, 공용 캘린더를 한곳으로 모으는 **[통합 인박스]**였습니다. 메시지가 들어오면 AI가 본문을 읽고 [배경 - 핵심내용 - 후속조치] 3단으로 깔끔하게 요약한 뒤, 이게 현재 진행 중인 '프로젝트' 건인지, 신규 '영업 리드(CRM)' 건인지, 아니면 '부서 내부 이슈'인지 분류해 주는 파이프라인이었죠.
그런데 며칠 돌려보고 API 사용량 로그를 까봤다가 뒷목을 잡았습니다. 슬랙이나 업무 메일 특성상 전체 메시지의 절반 이상이 "네, 확인했습니다", "감사합니다. 수고하세요!", "넵" 같은 단답형 인사말이잖아요? 초기 코드는 아무 생각 없이 이런 한 줄짜리 인사말까지 전부 꼬박꼬박 프롬프트 수천 자를 붙여서 LLM API로 날리고 있었던 겁니다. 심지어 이메일 본문에 달린 길고 긴 과거 회신 내역(RE: RE: FW:)까지 통째로 다 넣고 있었으니 토큰이 녹아내릴 수밖에요.
결국 AI를 부르기 전에 앞단에서 돈을 아끼는 거름망부터 짰습니다.
- 단순 인사말이나 단답, 기호만 있는 메시지는 정규식과 길이 체크로 걸러서 AI 호출 0건으로 즉시 스킵.
- 수만 자짜리 긴 이메일이나 문서는 통째로 넣지 않고, 핵심 맥락이 담긴 서두(60%)와 결론(40%)만 스마트하게 발췌해서 인풋 토큰을 75% 이상 다이어트.
- 사내 웹메일에 걸려오는 '30일 시한부 대용량 첨부파일 링크'는 HTML 태그를 벗기기 전에 정규식으로 낚아채서, 백그라운드 스레드가 조용히 구글 드라이브에 영구 백업해 두도록 처리.
이렇게 하고 나니 그제야 API 비용이 정상 궤도로 들어오더군요.
3. 슬랙에 '핀' 하나 꽂았더니 며칠 전 남의 대화를 납치해 오다
슬랙의 모든 대화를 다 인박스로 가져오면 쓰레기장이 되니까, 실무자가 중요하다고 판단한 메시지에 **'핀(고정)'**을 꽂거나 특정 리액션을 달면 그때만 인박스로 수집되게 설계했습니다. 그런데 메신저 대화라는 게 한 문장으로 끝나는 법이 없잖아요? 엔터를 탁탁 치면서 서너 줄에 걸쳐 이야기하는 경우가 많으니, 핀이 꽂힌 메시지 앞뒤 맥락을 같이 묶어서 가져오게 짰습니다.
그랬더니 어떤 참사가 벌어졌냐면... 조용한 채널에서 며칠 전에 끝난 '갑 프로젝트' 대화가 위에 있었고, 오늘 새로 '을 프로젝트' 이야기를 짧게 한 뒤 핀을 꽂았는데, 수집기가 기계적으로 직전 N개 대화를 한 묶음으로 긁어오면서 며칠 전 갑 프로젝트 이야기까지 같이 납치해 온 겁니다. AI는 또 시키는 대로 그걸 다 읽더니, 오늘의 을 프로젝트 메시지에다가 며칠 전 갑 프로젝트 제목을 떡하니 붙여서 요약해 버렸습니다. 실무자는 "어? 이거 옛날에 등록한 건데 왜 또 중복으로 들어왔지?" 하고 지워버리는 바람에 정작 중요한 오늘 대화가 증발할 뻔했죠.
고민 끝에 **'스마트 버스트 윈도잉(Smart Burst Windowing)'**이라는 4단계 룰을 만들었습니다.
- 1원칙 (앵커 중심): 무조건 핀이 꽂힌 바로 그 메시지를 절대 기준으로 삼는다.
- 2원칙 (완결형 문서 격리): 만약 핀 꽂힌 메시지 자체에 글머리 기호나 줄바꿈이 충분히 있고 글자 수가 80자 이상이거나 첨부파일이 있으면, 그 자체로 완결된 보고서이므로 이전 대화는 아예 쳐다보지도 않는다.
- 3원칙 (3분 룰): 짧은 단문일 때만 이전 대화를 거슬러 올라가되, **'시간차 3분(180초) 이내 + 동일한 발화자'**가 연속으로 친 메시지만 합친다. 중간에 다른 사람이 끼어들거나 3분이 넘어가면 칼같이 자른다.
이 룰을 적용하고 나서야 메신저 특유의 '엔터 쪼개 치기'와 '옛날 대화 섞임' 문제가 동시에 거짓말처럼 사라졌습니다.
4. "고객사 추천 1위: 우리 회사" 사건과 자가 진화 메모리
제일 크게 웃었던(그리고 속이 쓰렸던) 사건은 인박스 AI 자동 매칭 추천 엔진을 붙였을 때였습니다.
수집된 이메일이나 일정을 보고 "이 건은 현재 돌아가고 있는 OO 프로젝트로 넘기시겠습니까?" 하고 드롭다운 최상단에 추천해 주는 기능인데, 매번 LLM을 부르면 느리고 비싸니까 **과거에 사람이 승인했던 이력(발신자 도메인, 키워드, 고객사명)을 점수화해서 스스로 학습하는 메모리(BPE 방식)**를 구축했습니다. 자주 매칭된 고객사에는 누적 사용 횟수(usage_count) 가산점도 조금씩 주도록 설계했죠.
그런데 어느 날 인박스를 열어보니, 외부에서 들어온 온갖 이메일 상단에 보라색 추천 뱃지로 **'저희 회사(조직) 이름'**이 당당하게 1순위로 떠 있는 겁니다. 심지어 전혀 무관한 외부 거래처 메일인데도요.
"아니, 왜 우리 회사가 가망 고객사 1등으로 뜨는 거야?!" 하고 DB를 까봤더니 원인이 기가 막혔습니다.
초기에 사내 행정 메일들을 이관할 때 수행 주체였던 우리 회사 이름이 고객사 칸에 몇 번 들어간 적이 있었는데, 이게 누적되다보니 다른 후보들을 다 제치고 1등을 먹고 있었던 겁니다.
결국 두 가지를 뜯어고쳤습니다.
- 내용 일치(Relevance) 필수 가드: 발신자나 고객사명, 본문 키워드 중 실제 내용 일치가 0점이면, 과거 누적 사용 횟수가 천 번이든 만 번이든 가산점은 무조건 0점으로 강제 초기화.
- 자사명 영구 블랙리스트: 우리 회사 정식 명칭, 약칭, 부서명은 코드 레벨에서 고객사 후보로 절대 올라오지 못하게 영구 배제하고, 기존에 오염됐던 과거 레코드도 전수 정제.
이 과정을 거쳐 초기에는 37% 수준이던 자동 분류 정확도가 최근 3개월 실데이터 330여 건 검증 기준 83% 이상으로 껑충 뛰었습니다. 고객사 이름이 없는 일반 일정('디자인 미팅', '구독 갱신' 등)을 억지로 프로젝트에 쑤셔 넣지 않고 '부서 운영 이슈' 쪽으로 똑똑하게 빼주는 건 덤이고요.
[1편을 마치며]
처음에는 그저 "이메일이랑 슬랙 좀 한곳에서 편하게 보자"고 시작한 일이었는데, 실제 현업의 지저분한 데이터(인사말, 단문 쪼개 치기, 전달된 메일의 꺾쇠괄호 < >가 HTML 태그로 오인돼서 이메일 주소가 화면에서 증발하던 버그 등)와 부딪히다 보니 프롬프트 한 줄보다 데이터 전처리와 구조적 가드레일이 열 배는 더 중요하다는 걸 뼈저리게 배웠습니다.
다음 편에서는 현업의 진짜 보스 몬스터였던 '계약서 법률 검토 & 사내 기안문 마법사'(도장 찍힌 스캔본 PDF를 넣었더니 AI가 5,000만 원짜리 소설을 쓴 사건)와, 매출이 1억 배로 뻥튀기될 뻔했던 'ERP 전표 및 외주 정산 자동화' 이야기를 풀어보겠습니다.
댓글 1