자동화의 '눈먼 부분' 발견하기
어제 아침, 드림팀 햄스터즈의 봇이 갑자기 멈췄다. 구글 시트에 적힌 상품 설명문을 5개 언어로 자동 번역하는 작은 스크립트였는데, 번역 검증 단계를 추가하면서 뭔가 이상했다.
원본: "경량 소재로 편안한 착용감을 제공합니다."
스페인어 번역: "Proporciona una sensación de uso cómoda con material ligero."
포르투갈어 번역: "Fornece uma sensação de desgaste confortável com material leve."
겉으로는 정상이었다. 하지만 문맥 검증 로직을 추가했을 때, AI가 같은 표현을 여러 언어로 다르게 해석하고 있다는 걸 알아챘다. 일부 번역은 공식적이고, 일부는 너무 캐주얼했다. B2B 바이어들에게 보낼 콘텐츠로서는 톤(Tone)이 불일치했다.
문제의 원인: 프롬프트의 불충분함
Claude Code에 "번역해줘"라고만 지시하면, 모델은 의도를 충분히 이해하지 못한다. 무역 문서이므로 formal한 톤이 필요하다는 맥락이 빠져있었다. 우리는 프롬프트에 다음을 추가했다.
"각 언어별로 B2B 바이어 대상의 공식 톤을 유지하세요. 특히 기술 용어는 업계 표준 표기를 따릅니다."
그 후 또 다른 문제가 드러났다. 일부 언어에서는 문장 길이 제한이 없어서 원본보다 훨씬 길어지는 경우가 있었다. UI 폼에 입력할 때 글자 수 초과 오류가 발생했다.
자동화에 '검증 레이어' 추가하기
이 경험에서 배운 건, 비개발자가 자동화를 만들 때 가장 쉽게 놓치는 부분이 바로 「품질 검증」이라는 것이었다. 우리는 다음 단계를 추가했다.
1. **길이 검증**: 원본 대비 번역문 길이를 비교해, 150퍼센트 초과시 알림.
2. **톤 검증**: 프롬프트에 명확한 스타일 가이드를 포함시켜, 각 언어의 일관성 유지.
3. **스팟 체크**: 일주일에 한 번, 무작위로 5개 번역을 뽑아 수동으로 검토.
맥미니에서 돌아가던 자동화 프로세스가 윈도우 디바이스의 스프레드시트와 연동되면서, 이런 검증 로직이 없으면 오류가 거의 보이지 않는다는 걸 깨달았다. 시스템이 "빠르게" 작동할수록, 오류도 빠르게 전파된다.
결론: 속도보다 신뢰성
비개발자가 자동화를 운영할 때, 우리가 개발자보다 갖는 장점은 현장을 더 잘 안다는 것이다. 역설적으로, 그 장점이 약점이 될 수 있다. 우리는 "작동하는 것 같다"는 느낌에 만족하기 쉽기 때문이다.
AI 에이전트가 90퍼센트 정확하다면, 10퍼센트의 오류가 바이어 신뢰를 완전히 무너뜨릴 수 있다. 드림팀 봇들이 더 똑똑해질수록, 우리는 그들을 더 의심해야 한다는 아이러니가 있다.
다음 번에 새로운 자동화를 만들 땐, 「검증」을 처음부터 설계에 포함시켜야겠다.