디스코드에서 AI 직원에게 말로 업무를 시켜보려다 알게 된 것들

[FMNOTE]

텔레그램으로 AI 직원에게 일을 시키는 흐름은 생각보다 괜찮았습니다. 짧은 지시를 남기고, 결과를 받고, 필요하면 다시 수정시키는 정도는 충분히 됩니다. 근데 막상 계속 쓰다 보니 한 가지 아쉬움이 남았습니다. 급하게 상태만 확인하거나, 화면을 보면서 “이거 말고 저쪽으로 해보자” 같은 말을 하고 싶을 때는 텍스트가 살짝 답답했습니다.

그래서 디스코드 음성 채널에 AI 직원을 붙여보는 실험을 했습니다. 말로 부르면 들어오고, 지시를 STT로 받아 적고, 필요한 답은 TTS로 돌려주는 구조입니다. 처음 머릿속에서는 꽤 단순했습니다. 음성방에 들어가서 “헬대리, 이거 확인해줘”라고 말하면 알아듣고 움직이는 그림이었죠. 솔직히 이 정도면 거의 사무실 직원 호출 느낌이 날 줄 알았습니다.

결론부터 말하면, 음성 인터페이스는 분명 쓸모가 있습니다. 다만 정식 작업 지시 전체를 음성만으로 처리하기에는 아직 피곤한 부분이 많았습니다. 결국 제 기준에서는 음성은 보조 인터페이스, 실제 작업 지시는 텍스트 병행이 맞았습니다.

왜 텔레그램만으로는 조금 부족했나

텔레그램은 작업 지시용으로 꽤 편합니다. 어디서든 보내기 쉽고, 로그가 남고, 나중에 다시 찾기도 괜찮습니다. 특히 “이 글 수정해”, “서치콘솔 확인해”, “비공개로 올려놔” 같은 지시는 텍스트가 훨씬 안전합니다. 말로 하면 빠르게 지나가는 정보가 텍스트에서는 그대로 남습니다.

문제는 작업 중간입니다. AI 직원이 뭔가를 확인하고 있을 때, 옆에서 바로 방향을 틀고 싶은 순간이 있습니다. 예를 들면 “아 그건 공개하지 말고 비공개로만 둬”, “그 페이지 말고 96번 글 기준으로 봐”, “지금 멈춘 것 같은데 상태만 말해봐” 같은 것들입니다. 이런 짧은 말은 텍스트로 치는 것보다 그냥 말하는 게 자연스럽습니다.

그래서 음성은 본 작업을 대체한다기보다, 작업 중간의 핸들처럼 쓰면 좋겠다고 봤습니다. 운전대를 통째로 넘기는 게 아니라, 급할 때 브레이크나 방향지시등처럼 쓰는 쪽입니다.

디스코드 음성방에 AI 직원을 붙여보고 싶었다

이번 실험의 목표는 거창하지 않았습니다. 디스코드 음성 채널에 들어가면 AI 직원도 따라 들어오고, 제가 말하면 그걸 듣고, 필요한 답을 다시 말하거나 텍스트로 남기는 구조였습니다. 사람 직원에게 “잠깐 들어와 봐”라고 하는 것과 비슷한 흐름을 만들고 싶었습니다.

여기서 중요한 건 AI가 사람처럼 대화하는 느낌 자체가 아니었습니다. 저는 오히려 그쪽에는 큰 기대가 없었습니다. 진짜 보고 싶었던 건 업무 흐름이었습니다. 음성으로 빠르게 지시를 넣고, 결과는 텍스트로 남기고, 중요한 작업은 다시 명시적으로 확인하는 구조가 가능한지 보는 쪽이었습니다.

처음에는 이게 꽤 단순해 보였습니다. 디스코드에서 음성을 받고, STT로 텍스트화하고, 그 텍스트를 에이전트에게 넘기면 됩니다. 답변은 TTS로 읽어주면 끝. 글로 쓰면 세 줄입니다. 실제로 붙이면 세 줄이 아닙니다. 당연히 그렇습니다.

실제 구성은 이렇게 잡았다

큰 흐름은 네 덩어리였습니다. 디스코드 음성 수신, 음성 인식, 음성 출력, 그리고 사용자를 따라오는 follow-me 동작입니다.

• VoiceReceiver: 디스코드 음성 채널에서 실제 음성을 받는 쪽입니다.
• STT: local faster-whisper small 모델을 한국어 기준으로 붙여봤습니다.
• TTS: Gemini 계열과 Edge 계열을 테스트했습니다.
• follow-me: 제가 음성방에 들어가면 헬대리도 따라 들어오는 식으로 잡았습니다.

구조만 보면 깔끔합니다. 사용자가 음성방에 들어갑니다. AI 직원이 따라옵니다. 사용자가 말합니다. VoiceReceiver가 음성을 받습니다. STT가 문장으로 바꿉니다. 에이전트가 처리합니다. 필요한 답은 TTS로 읽습니다. 텍스트 채널에는 기록을 남깁니다.

근데 실제 운영에서는 작은 설정 하나가 계속 분위기를 바꿉니다. voice mode를 어떤 상태로 둘지, 모든 말을 받을지, 멘션이나 호출어가 있을 때만 받을지, 봇끼리도 서로 호출할 수 있게 할지 같은 부분입니다. 처음엔 단순히 all로 고정하면 편할 것 같았는데, 이러면 필요 없는 소리까지 너무 많이 들어옵니다. 반대로 너무 빡빡하게 막으면 정작 부를 때 못 듣습니다.

막힌 부분은 생각보다 현실적이었다

가장 먼저 부딪힌 건 음성 품질보다 연결 안정성이었습니다. NaCl decrypt failed 같은 복호화 오류가 나면 말 그대로 음성이 깨집니다. 디스코드 음성 패킷을 받는 쪽에서 삐끗하면 STT까지 갈 것도 없습니다. 이건 글로 보면 에러 한 줄인데, 실제로는 “분명 말했는데 왜 못 듣지?”가 됩니다.

STT도 늘 깔끔하지 않았습니다. local faster-whisper는 로컬에서 돌릴 수 있다는 점이 좋지만, 짧은 말과 주변 소음이 섞이면 기대만큼 안정적이지 않을 때가 있습니다. Gemini STT 쪽도 봤는데, 503 같은 서버 오류가 나오면 그 순간에는 별 방법이 없습니다. 음성은 실시간성이 있어서 잠깐 실패해도 체감이 큽니다.

TTS도 마찬가지였습니다. 답을 말로 들려주는 건 좋습니다. 근데 connection reset이 나거나, 읽는 속도가 흐름과 안 맞거나, 중간에 끊기면 오히려 텍스트보다 답답합니다. 사람은 그냥 “다시 말해줘”라고 하면 되지만, 봇은 재시도, 큐, 상태 관리가 필요합니다. 솔직히 여기서부터는 음성 기능보다 운영 기능에 가깝습니다.

Discord 429도 신경을 써야 했습니다. 봇이 너무 자주 상태 메시지를 보내거나, typing 비슷한 신호를 반복하거나, 중간 알림을 많이 보내면 제한이 걸릴 수 있습니다. 몇 마디 안 한 것 같은데 시스템 입장에서는 자동 전송이 훨씬 많이 쌓여 있을 수 있습니다. 이건 텔레그램에서도 비슷하게 겪었습니다. 사람이 보낸 문장 수가 아니라, 봇이 실제로 API에 던진 요청 수가 문제였습니다.

음성이 좋은 순간은 확실히 있다

그래도 음성은 버릴 기능이 아니었습니다. 짧은 확인에는 확실히 편합니다. “지금 살아 있어?”, “그 작업 멈춰”, “헬대리한테 넘겨”, “그건 공개하지 마” 같은 말은 음성이 잘 맞습니다. 타이핑보다 빠르고, 맥락을 유지한 채 바로 끼어들 수 있습니다.

특히 작업 중 상태 확인에는 좋았습니다. 긴 보고서를 받을 필요 없이, “지금 어디까지 했어?”라고 묻고 한두 줄 답을 듣는 정도면 충분합니다. 화면을 보면서 동시에 말할 수 있다는 것도 장점입니다. 텍스트 채팅은 손이 키보드로 가야 하는데, 음성은 시선과 손을 덜 빼앗습니다.

AI 직원을 여러 명으로 나눠 쓰는 구조에서도 가능성이 있습니다. 예를 들어 헬대리가 블로그 운영 판단을 하고, 코대리가 실제 작성과 업로드를 맡는 식이라면, 음성은 “누구에게 넘길지”를 빠르게 지정하는 데 쓸 수 있습니다. 다만 이건 봇끼리의 멘션, 응답 대상, 세션 분리까지 같이 맞아야 합니다. 그냥 음성만 붙인다고 해결되지는 않습니다.

긴 작업 지시는 텍스트가 이긴다

반대로 긴 작업 지시는 음성만으로 하기 어렵습니다. 제목, 톤, 금지 조건, 발행 상태, 이미지 조건, 공개 여부가 섞이면 말로 전달하는 순간 빠지는 게 생깁니다. 특히 블로그 발행이나 계정 설정처럼 실수하면 곤란한 작업은 텍스트가 맞습니다.

음성 지시는 빠르지만, 빠른 만큼 애매합니다. “아까 말한 그 글” 같은 표현은 사람끼리도 헷갈립니다. AI에게는 더 위험합니다. 사이트가 5개 있고, WordPress와 Tistory가 섞여 있고, 공개 발행과 비공개 테스트가 나뉘면 음성만으로는 사고가 나기 쉽습니다.

그래서 지금 기준은 단순합니다. 음성은 시작, 중단, 상태 확인, 방향 전환에 씁니다. 정식 작업 지시는 텍스트로 남깁니다. 공개 발행, 삭제, 계정 변경, 외부 제출은 텍스트 확인을 거칩니다. 이 정도로 나누면 음성이 편해지지, 위험해지지는 않습니다.

지금 정착한 기준

이번 실험 뒤에 제 기준은 꽤 명확해졌습니다. 디스코드 음성대화는 AI 직원을 더 사람처럼 보이게 만드는 장식이 아닙니다. 오히려 작업 흐름의 입력 장치를 하나 늘리는 일에 가깝습니다. 키보드, 텔레그램, 디스코드 텍스트, 브라우저 조작 사이에 음성이라는 짧은 통로가 하나 더 생기는 겁니다.

그래서 음성 기능을 만들 때는 “얼마나 자연스럽게 대화하나”보다 “실패했을 때 어디에 기록이 남나”를 먼저 봐야 합니다. STT가 틀렸으면 원문 음성이나 인식 텍스트가 남아야 하고, TTS가 실패하면 텍스트 답변은 남아야 합니다. Discord 제한에 걸리면 조용히 반복 전송하지 말고 멈춰야 합니다. 재시작해도 현재 작업 상태를 잃지 않아야 합니다.

이런 기준으로 보면 음성은 메인 채널이 아니라 보조 채널입니다. 근데 보조 채널이라고 가치가 낮은 건 아닙니다. 잘 붙이면 작업 중간의 마찰을 꽤 줄여줍니다. 다만 모든 지시를 말로 해결하려고 하면 다시 복잡해집니다. 결국 편하려고 붙인 음성이 새로운 장애물이 됩니다.

다시 세팅한다면 먼저 볼 것

• 음성방 입장 조건을 먼저 정합니다. 항상 대기인지, 호출할 때만 들어오는지부터 정해야 합니다.
• STT 결과는 반드시 텍스트 채널에 남깁니다. 나중에 “내가 그렇게 말했나?”를 확인할 수 있어야 합니다.
• TTS 실패 시 텍스트 응답으로 fallback합니다. 말이 안 나오면 작업이 멈춘 것처럼 보입니다.
• 봇 상태 알림은 최소화합니다. 자동 알림이 많아지면 429 제한부터 맞습니다.
• 긴 작업 지시는 텍스트 카드로 넘깁니다. 음성은 작업 카드 생성의 트리거 정도가 적당합니다.
• 공개 발행, 삭제, 계정 변경은 음성 단독으로 처리하지 않습니다.
• 봇끼리 호출할 때는 멘션 규칙을 고정합니다. 누가 누구에게 답하는지 흐려지면 로그가 바로 지저분해집니다.

공개 글에서 뺀 것

이 글에는 실제 봇 토큰, 계정 정보, 내부 경로, 서버 주소, 내부 식별값, 개인 대화 원문은 넣지 않았습니다. 공개해도 되는 수준의 구성과 시행착오만 남겼습니다. 이런 글은 기술 기록이지만, 동시에 운영 기록입니다. 어디까지 공개할지 선을 긋는 게 기능 설명보다 중요할 때가 있습니다.

지금은 음성으로 모든 걸 처리하는 구조보다, 음성과 텍스트가 서로 보완하는 구조가 맞다고 봅니다. 말로 빠르게 부르고, 텍스트로 정확하게 남기고, 위험한 작업은 다시 확인합니다. 재미는 음성 쪽에 있는데, 안정성은 여전히 텍스트 쪽에 있습니다. 아쉽지만 이게 지금 제일 덜 꼬이는 방식입니다.