AI와 함께 사고하기 위한 음성: 왜 키보드는 잘못된 도구인가

저도 예전엔 음성을 접근성 인터페이스나 편의 기능 정도로만 생각했어요. AI 도구를 매일 쓰기 시작하면서 마음이 바뀌었어요. 키보드는 정밀 작업에 훌륭하지만, AI와 함께 사고하기에는 빈약한 도구예요. 아이디어가 준비되기도 전에 좁은 채널로 강제로 밀어넣게 만들거든요.

키보드 병목

빠른 타이피스트도 분당 70단어 정도가 최대치예요. 대화 속 말하기는 분당 150단어에 가깝고, 내면의 사고는 그보다 더 빠를 수 있어요. 정확한 숫자보다 중요한 건 형태예요. 키보드는 아이디어가 채 정리되기 전에 사고를 다듬어진 조각들로 직렬화하도록 만들어요.

그게 키보드 병목이에요. 타이핑이 절대적으로 느린 게 아니에요. 사고를 형성하는 동안 동시에 편집하도록 강요한다는 게 문제예요. AI와 함께라면 이런 이른 압축은 유용한 모호함을 제거해버려요. 단서, 대안, 모델이 고려해줬으면 하는 불확실한 지점 같은 것들 말이에요.

피곤할 때 가장 크게 느껴요. 하루가 끝나갈 무렵엔 타이핑한 프롬프트가 점점 짧아지고, 모델도 그만큼 덜 유용해져요. 같은 저녁에 같은 도구에 같은 의도를 받아쓰면 더 나은 답이 나와요. 음성 버전은 손으로는 잘라냈을 컨텍스트를 그대로 가지고 있거든요. 키보드는 단순히 저를 느리게 만드는 게 아니라, 어느 시간 이후부터는 모델의 협업자로서의 저를 더 나쁘게 만들어요.

AI가 프롬프트의 형태를 바꿔놨다

LLM과 일하는 건 명령을 내리기보다는 협업자에게 브리핑하는 것에 가까워요. 좋은 프롬프트엔 보통 컨텍스트, 동기, 제약, 예시, 불확실성이 담겨 있어요. 문제가 아직 흐릿할 때 음성 프롬프트가 AI 도구에 더 잘 작동해요. 주변 컨텍스트를 우아하게 다듬으려고 멈추지 않고 그냥 말할 수 있으니까요.

그래서 사고를 위한 음성이 중요해요. "버그가 캐시 키에 있는 것 같은데, 사용자 로케일이 그 일부인지는 확실하지 않아. 그 경로부터 먼저 확인하고 내가 틀렸으면 알려줘."라고 말할 수 있죠. 타이핑하면 보통 "캐시 버그 확인"이 돼요. 짧아진 프롬프트는 그 사고를 잃어버려요.

프롬프트의 형태는 이제 작업의 서문이 아니라 작업의 일부예요. 프롬프트를 만들어내는 산출물로 다루면, 음성이 자연스러운 작성 도구가 돼요. 자신이 문제를 실제로 어떻게 이해하고 있는지의 구조를, 확실하지 않은 부분까지 포함해서 보존하거든요. 반쯤 형성된 형태를 받는 모델이, 자신 있지만 부분적인 명령을 받는 모델보다 더 나은 답을 내놓는 경우가 많아요.

생각을 바꾼 세 가지 순간

첫 번째는 디버깅 세션이었어요. 에이전트에 짧은 프롬프트를 타이핑해서 회귀 문제를 살펴봐 달라고 했어요. 잘못된 방향으로 갔더라고요. 그래서 지저분한 버전을 받아썼어요. 무엇이 바뀌었고, 무엇을 의심하고, 무엇을 의심하지 않으며, 제 가설을 반증할 수 있는 게 뭔지를요. 에이전트는 더 빨리 문제를 찾아냈어요. 마침내 제 불확실성의 형태를 줬기 때문이에요.

두 번째는 글쓰기였어요. 저희 모델 스택에 대한 깔끔한 단락을 타이핑했더니, 맞는 말이긴 했지만 죽어 있는 느낌이었어요. 같은 아이디어를 걸으면서 말로 했어요. 그 아키텍처에 도달하게 만든 답답함까지 담아서요. 받아쓴 버전엔 실제 논증이 들어 있었어요. 그래도 편집은 했지만, 무미건조한 개요가 아니라 살아 있는 초고에서 시작한 편집이었어요.

세 번째는 길고 어색한 고객 답변이었어요. 깔끔한 답이 없는 질문이었고, 솔직한 답엔 트레이드오프와 작은 사과가 포함돼야 했어요. 타이핑한 답은 여섯 번 편집해도 여전히 뻣뻣했어요. 받아쓴 첫 번째 버전은 더 따뜻하고 직설적이었고, 한 단어만 고치면 됐어요. 그 버전을 보냈고 대화는 잘 진행됐어요. 이제 톤이 조금이라도 필요한 메시지에는 타이핑한 답을 믿지 않아요.

지금 음성을 쓰는 방식

저는 초안 사고에는 음성을 쓰고, 최종 정밀도에는 쓰지 않아요. 지저분한 브리프를 Claude Code, Cursor, Obsidian, 또는 평범한 마크다운 파일에 받아써요. 그다음 정확한 편집에는 키보드로 전환해요. 이 분업이 각 도구를 자기 자리에 두게 해줘요. 컨텍스트엔 음성, 수술엔 키보드.

• 코딩 전: 변경 사항, 위험, 테스트 경로를 받아써요. 받아쓴 버전엔 보통 타이핑이었으면 넘어갔을 위험이 드러나요.
• 글쓰기 전: 개요 짜기 전에 논증을 소리 내어 말해봐요. 2분 안에 논증을 말할 수 없으면, 아직 제가 무슨 생각인지 모르는 거예요.
• 미팅 전: 그 통화에서 필요한 결정을 받아써요. 명명된 결정을 가지고 미팅에 들어가면 대화가 달라져요.
• 실패 후: 기억이 흐려지기 전에 무엇이 놀라웠는지 받아써요. 다음 날 아침이면, 기록하지 않은 교훈은 사라져 있어요.

음성 속도와 받아쓰기 패턴에 대한 외부 컨텍스트로는 Nielsen Norman Group의 음성 인식 글과 분당 단어 수 참고 자료가 좋은 출발점이에요.

계속 듣는 반론들

"공유 공간에서 일해요." 맞아요, 그건 실제 제약이에요. 제 답은 이거예요. 하루에 조용히 10분만 어려운 프롬프트를 받아써도, 타이핑한 하루치보다 더 유용해요. 음성은 워크플로를 지배해야만 그걸 바꿀 수 있는 게 아니에요.

"저는 타이핑하면서 사고할 수 있어요." 진짜로 그럴 수 있는 사람도 있어요. 시험은 타이핑으로 텍스트를 만들어낼 수 있느냐가 아니에요. 타이핑으로 만들어낸 텍스트가, 말로 했을 사고와 같은 형태를 가지고 있느냐예요. 저를 포함한 대부분에게, 타이핑한 버전은 일관되게 덜 완전해요.

"받아쓰면 산만하게 들려요." 첫 주는 거칠어요. 두 번째 주는 훨씬 나아지고요. 배우는 기술은 말하기가 아니에요. 발화한 사고를 독자(또는 모델)가 쓸 수 있는 형태로 다듬는 거죠. 대화에서 이미 다 써본 적이 있으니까, 생각보다 빨리 돌아와요.

Loqua가 자리 잡는 곳

저희가 Loqua를 만든 건, 원본 전사 정리를 감수하지 않고도 사고를 위한 음성을 쓰고 싶었기 때문이에요. 잘못된 시작을 제거하고, 기술적 이름을 유지하고, 제가 있는 앱에 맞게 출력 포맷을 맞춰줘요. 부드럽게 정리하면 이거예요. 아이디어가 키보드를 먼저 통과시키기엔 너무 크거나 너무 깨지기 쉬울 때 Loqua를 쓰세요.

이 논증의 실용적인 버전은 보이스 퍼스트 워크데이를 확인해보세요. 그 글은 음성이 언제 통하고, 언제 실패하고, 언제 여전히 키보드로 손이 가는지를 보여줘요. 이 글의 요점은 왜고, 그 글은 어떻게예요.