오케이징은 원래 텍스트에 가까운 시스템이었다. Discord에서 메시지를 받고, 작업을 수행하고, 결과를 다시 글로 남긴다. 이 구조에서는 답변이 조금 길어도 괜찮았다. 사용자가 스크롤하면 되고, 파일 경로나 명령어는 그대로 복사하면 된다.
voice mode를 붙이면 이 텍스트를 그냥 읽어주면 될 것 같았다. 답변은 그대로 두고, 마지막에 TTS만 생성하면 되는 문제처럼 보였다. 실제로 기능만 보면 그렇게도 만들 수 있다. 하지만 사용해보니 "읽어주는 채팅봇"과 "말하는 동료" 사이에는 차이가 있었다.
읽어주는 채팅봇은 텍스트의 보조 기능이다. 말하는 동료는 대화의 기본 단위가 음성이다. 이 둘은 설계 기준이 다르다.
텍스트에서는 사용자가 답변 전체를 한눈에 본다. 첫 문장이 조금 돌아가도 아래쪽에서 결론을 찾을 수 있다. 하지만 음성에서는 첫 문장이 방향을 잡는다. "지금 뭘 했는지", "결과가 괜찮은지", "내가 뭘 알아야 하는지"가 빨리 나와야 한다.
그래서 voice mode에서 오케이징의 첫 문장은 더 짧아져야 했다. "응, 해봤고 통과했어"처럼 상태를 먼저 말하고, 그다음에 필요한 배경을 붙이는 편이 낫다. 반대로 "요청하신 작업을 수행하기 위해 다음과 같은 절차를 진행했습니다" 같은 문장은 텍스트 보고서에는 괜찮아도 음성에서는 너무 느리다.
이 변화는 작아 보이지만 크다. 오케이징이 작업자에서 대화 상대로 넘어가는 지점이기 때문이다.
음성 답변에서 가장 위험한 건 과한 자신감이다. 텍스트에서는 "검증하지 못한 부분"을 아래에 따로 적을 수 있다. 하지만 음성에서는 긴 caveat가 뒤로 밀리면 사용자는 앞의 결론만 듣는다.
그래서 오케이징이 말할 때는 확실한 것과 불확실한 것을 같은 호흡 안에서 말해야 한다. 예를 들면 "빌드는 통과했어. 다만 배포는 아직 안 했어"처럼 짧게 붙여야 한다. 이게 실제 동료와 일할 때 더 자연스러운 방식이다. 좋은 동료는 결과만 말하지 않고, 어디까지 확인했는지도 같이 말한다.
voice mode에서는 이 기준이 더 강해진다. 음성은 인상이 빠르게 만들어진다. 그래서 오케이징이 모르는 것을 아는 척하면 텍스트보다 더 거슬린다. 반대로 한계를 짧게 인정하면 신뢰가 생긴다.
음성으로 이야기하면 사용자의 요청도 덜 정제된 형태로 들어온다. "이거 좀 해줘", "방금 말한 거 글로 써줘", "속도 좀 빠르게 해줘"처럼 말한다. 텍스트 프롬프트처럼 요구사항이 딱 정리되어 있지 않다.
이때 오케이징은 매번 사용자를 멈춰 세워서 확인하면 안 된다. 위험하지 않고, 되돌릴 수 있고, 맥락이 충분하면 바로 해석해서 실행해야 한다. voice mode의 장점은 빠른 흐름인데, 매번 확인 질문을 던지면 그 흐름이 깨진다.
대신 작업으로 넘어가는 순간 ticket이나 파일, build 결과 같은 검증 가능한 상태를 남겨야 한다. 말은 자연스럽게 하되, 뒤쪽 운영 구조는 더 단단해야 한다. 음성 인터페이스가 가벼워질수록, 내부 상태 관리는 더 중요해진다.
텍스트 채팅에서 오케이징은 작업을 대신 처리하는 assistant에 가까웠다. voice mode에서는 조금 다르다. 사용자는 결과 문서를 읽기보다, 옆에서 누가 짧게 보고해주길 기대한다. 그래서 오케이징은 답변을 "작성"하는 존재에서 답변을 "말하는" 존재로 바뀐다.
이 변화는 기능 추가라기보다 역할 변화에 가깝다. 같은 작업을 하더라도, 사용자가 듣는 방식이 바뀌면 시스템이 보여줘야 하는 인격과 리듬도 달라진다. 오케이징이 Hermes라는 실행 체계 위에서 움직인다는 사실은 그대로다. 하지만 사용자에게 닿는 표면은 점점 더 동료에 가까워진다.
결과적으로 voice mode는 오케이징을 더 사람처럼 만들기 위한 장식이 아니었다. 작업 요청을 받고, 실행하고, 검증하고, 짧게 말해주는 전체 운영 방식의 변화였다.