병렬 에이전트에 프롬프트 받아쓰기, 레인 하나씩

코딩 에이전트를 나란히 두 개 돌려 보는 첫날, 뭔가 어긋난 느낌이 드는데 그게 뭔지 이름 붙이기까지는 시간이 좀 걸립니다. 에이전트는 각각 빠릅니다. 하나만 놓고 보면 어느 쪽이든 분명한 이득입니다. 둘이면 이득도 두 배여야 합니다. 그런데 하루는 하나만 돌릴 때보다 더 잘게 쪼개지고, 오후가 끝날 때 보면 기대했던 것보다 끝난 게 적습니다.

원인은 에이전트가 아닙니다. 에이전트가 필요로 하는 입력의 모양입니다. 코딩 에이전트는 산문으로 돕니다. "이 핸들러를 쪼개고, 공개 시그니처는 유지하고, 타임아웃 경로에 테스트를 하나 추가해." 산문은 생각하기엔 싸고 전달하기엔 비쌉니다. 전달한다는 건 알맞은 순간에 알맞은 창으로 손과 주의를 옮겨 놓는 일이니까요. 에이전트가 하나면 그 순간은 내 리듬과 맞아떨어집니다. 셋이면 순간은 저쪽 사정에 맞춰 오고, 그때마다 내가 하던 일이 끊깁니다.

이 글은 생각하는 문제가 아니라 전달하는 문제에 관한 글입니다. Mac에서 병렬 에이전트 레인에 프롬프트를 받아쓰는 실전 워크플로이고, 솔직한 한계도 함께 담았습니다. Claude Code를 목소리로 조종하기를 아직 안 읽었다면 그 글이 레인 하나짜리 기본을 다룹니다. 이 글은 이미 여러 개를 돌리고 있다고 가정합니다.

왜 병렬 레인은 유독 타이핑을 벌하는가

프롬프트에는 세 가지 비용이 있습니다. 만드는 비용, 전달하는 비용, 그다음 복귀하는 비용입니다. 만드는 건 피할 수 없고 대부분 머릿속에서 벌어집니다. 타이핑으로 전달한다는 건 에이전트의 터미널로 포커스를 옮기고, 입력 줄을 찾고, 마흔에서 여든 개 단어를 치고, 엔터를 누르는 일입니다. 복귀는 에이전트가 부르기 전에 하던 것으로 돌아가는 일입니다.

레인이 하나면 전달 비용은 작습니다. 그 터미널을 이미 보고 있었을 가능성이 크니까요. 병렬 레인에서는 거의 그렇지 않습니다. 레인 2의 diff를 읽는 동안 레인 1이 질문을 던집니다. 질문은 쉽고 답은 한 문장입니다. 그런데 답하려면 diff를 떠나야 하고, 돌아오면 마지막 서른 줄을 다시 읽으며 어디까지 봤는지 찾습니다.

여기에 모든 방향 수정, 모든 "그래, 계속해", 모든 "아니, 다른 파일"을 곱하면 오버헤드가 누적됩니다. 병렬 레인이 실패하는 건 에이전트가 느려서가 아닙니다. 내가 메시지 버스가 되기 때문이고, 창 사이를 물리적으로 이동해야 하는 메시지 버스의 지연은 끔찍합니다.

음성은 전달 비용의 대부분을 걷어냅니다. 눈은 diff에 두고, 키를 누른 채 문장을 말하고, 뗍니다. 말은 에이전트의 입력 필드에 들어갑니다. 당신은 어디로도 떠나지 않았습니다.

실제로 되는 셋업

셋업은 이렇고, 일부러 심심하게 두었습니다.

창이 아니라 핫키. Keebye는 메뉴 막대에 살면서 누르거나 탭하는 핫키를 기다립니다(기본은 오른쪽 ⌘, 다른 선택지는 Fn과 오른쪽 ⌥, 진행 중인 받아쓰기는 Esc로 취소). 열 앱 창이 없고 들어갈 모드도 없습니다. 누르고, 말하고, 뗍니다. 이건 들리는 것보다 중요합니다. 자기 창이 필요한 받아쓰기 도구는 레인이 하나 더 늘어난 것에 불과합니다.

포커스된 필드로 삽입. 전사된 텍스트는 커서가 있는 곳에 들어갑니다. 기본은 붙여넣기이고, 터미널을 이해하는 청크 분할이 있어 긴 프롬프트가 셸을 덮치지 않습니다. tmux나 SSH 안에서 에이전트를 돌리고 붙여넣기가 험하게 동작한다면, 텍스트를 유니코드 키 입력으로 넣어 주는 선택형 합성 타이핑 모드가 있습니다. 언제 바꿔야 하는지는 터미널에서도 살아남는 받아쓰기에 있습니다.

스트리밍이 아니라 배치. Keebye는 키를 뗄 때 하나의 발화로 전사합니다. 말하는 동안 단어가 나타나지는 않습니다. 프롬프트에는 이게 옳은 거래입니다. 에이전트의 입력창에 생각의 절반이 벌써 놓인 채로 단어가 하나씩 맺히는 걸 보는 대신, 정리된 문장 전체가 한 번에 들어오는 쪽이 낫습니다.

전부 온디바이스. 전사는 로컬에서 돕니다(기본은 영어에 맞춘 모델, 원하면 25개 언어 모델). 모델을 내려받은 뒤에는 Wi-Fi를 꺼도 됩니다. 에이전트 프롬프트에서 이건 프라이버시 연출보다 지연 문제입니다. 왕복이 없으니 짧은 프롬프트는 키를 떼자마자 거의 준비됩니다.

레인을 넘나드는 리듬

결국 몸에 붙은 워크플로에는 습관이 셋 있습니다.

눈은 판단이 필요한 레인에 머문다. 어느 순간에도 내 주의가 있어야 할 레인은 하나이고, 보통은 diff나 테스트 출력입니다. 읽는 건 그 레인입니다. 나머지는 짧은 구두 지시만 받습니다. 레인 2가 결정을 원하면, 눈길을 주고, 그 입력창을 클릭하고, 키를 누른 채 결정을 말하고, 떼고, 클릭해서 돌아옵니다. 기계적 비용은 그 클릭뿐이고 문장 자체는 공짜입니다.

프롬프트는 완전한 문장으로 말한다. 에이전트는 전보식 단편보다 완전한 문장을 더 잘 처리하고, 받아쓰기는 자연스럽게 완전한 문장을 만듭니다. 사람이 말하는 방식이 그러니까요. "스키마 변경은 되돌리고 API 이름 변경은 유지한 다음, 마이그레이션을 다시 돌려서 출력을 보여 줘"는 괜찮은 구어 프롬프트입니다. 타이핑으로는 지루한 프롬프트입니다.

군말은 걷히고 뜻은 남는다. Keebye의 정리는 기본이 규칙 기반입니다. "음", "어", 반복된 단어를 걷어내고 당신의 표현은 그대로 둡니다. 문장을 좀 더 매끈하게 만드는 온디바이스 로컬 LLM 다듬기도 선택형으로 있고, 그 뒤에는 다듬은 결과에서 심한 토큰 손실이나 팽창, 반복이 보일 때 있는 그대로의 전사로 되돌리는 충실도 가드가 있습니다. 그 가드는 휴리스틱이고 의미 검사가 아닙니다. 다듬은 텍스트가 당신의 뜻이나 부정을 지켰는지는 확인하지 않습니다. 에이전트 프롬프트에서는 대부분 다듬기를 꺼 둡니다. 있는 그대로의 전사는 정확히 내가 말한 것이고, 그게 바로 에이전트가 실행하기를 바라는 것이니까요.

음성이 잘 맞는 곳, 레인별로

모든 프롬프트가 말로 나오고 싶어 하는 건 아닙니다. 몇 달 써 본 뒤의 대략적인 구분입니다.

방향 수정과 계속 진행: 언제나 음성. "계속해." "아니, 다른 설정." "빈 케이스 테스트를 추가하고 다시 돌려." 병렬 세션에서 가장 물량이 많은 프롬프트이고 전부 숨 한 번 길이입니다.

리뷰 피드백: 대체로 음성. diff를 읽으면서 무엇이 잘못됐는지 소리 내어 서술하는 건 자연스럽습니다. "이 재시도 루프가 에러를 삼키고 있어. sleep 앞에서 로그를 남기고 시도 횟수는 다섯 번으로 제한해." 받아쓰기는 눈을 코드에 둔 채 이걸 말하는 속도로 잡아냅니다.

최초 작업 브리프: 섞임. 파일 경로와 제약이 들어간 길고 구조적인 브리프는 여전히 타이핑이 낫거나, 거친 판을 받아쓴 뒤 손보는 게 낫습니다. 산문 부분은 음성으로 충분하고, 정확한 식별자는 치는 게 편합니다. 여기서 사용자 사전이 도움이 됩니다. 프로젝트의 모듈 이름과 반복되는 은어를 한 번 등록해 두면, 가장 가까운 영어 단어로 전사되는 일이 멈춥니다.

코드가 들어가는 건: 타이핑. 정규식을 받아쓰는 건 괴로운 시간입니다. 산출물이 아니라 지시를 받아쓰세요("버전 헤더에 매치되는 정규식을 써 줘").

솔직한 한계

일부는 Keebye의 한계이고, 일부는 이 분야 전체의 한계입니다.

첫 받아쓰기의 지연. 마이크는 세션의 첫 받아쓰기 뒤에 예열되고, 그다음부터 500 ms의 프리롤을 유지합니다. 그날 맨 처음 누를 때는 스트림 시작 비용을 치를 수 있고, 버퍼가 걸리기 전에 나온 단어는 잘릴 수 있습니다. 그 작동 방식은 받아쓰기 앱이 첫 단어를 먹는 이유에 있습니다.

식별자 정확도. 스네이크 케이스 변수명과 내부 약어는 어느 음성 모델에나 힘든 대목입니다. 사전이 이걸 줄이지만 완전히 지우지는 못합니다. 되돌릴 수 없는 명령에 엔터를 누르기 전에는 프롬프트를 읽으세요.

보안 입력 필드. Keebye는 비밀번호와 보안 입력 필드에 삽입하기를 거부합니다. 의도한 동작이고, 터미널이 패스프레이즈를 물을 때는 이따금 불편합니다.

음성 명령은 없습니다. "줄바꿈"이나 "전체 선택" 같은 어휘가 없습니다. Keebye는 받아쓰기 도구이고 음성 제어 계층이 아닙니다. 레인 사이 이동은 여전히 클릭이나 키보드 단축키입니다.

macOS 전용. Windows 빌드는 출시하지 않았습니다.

다음으로 갈 곳

에이전트가 대체로 에디터 한 곳에 산다면 Cursor와 Claude Code를 위한 음성 받아쓰기 가이드에 도구별 세부가 있습니다. 이 워크플로를 위해 받아쓰기 앱을 고르고 있다면 Keebye vs Superwhisper가 솔직한 비교이고, Superwhisper가 더 맞는 지점도 담고 있습니다.

위의 모든 걸 짧게 줄이면 이렇습니다. 병렬 에이전트는 당신이 더 빨리 타이핑하기를 원하지 않습니다. 당신이 에이전트 사이에서 가장 느린 구간이기를 그만두기를 원합니다. 판단이 필요한 레인에 눈을 두고, 나머지에는 말하세요.