GitHub에서 음성으로 텍스트 입력하기: 실제로 어떻게 작동할까

GitHub에는 음성 입력이 없습니다. 일은 당신의 단축키가 합니다.

사람들이 실제로 구글에 검색하는 질문에 답해 보겠습니다. 아니요, GitHub에는 음성-텍스트 입력 기능이 내장되어 있지 않습니다. 이슈 편집기, PR 양식, 리뷰 패널, Discussions, 위키 어디에도 자체 받아쓰기 기능은 없습니다. 그것들은 모두 표준 웹 텍스트 영역입니다. 그 칸에 받아쓰려면 음성은 다른 곳에서 와야 합니다. 운영체제, 브라우저, 또는 서드파티 앱이죠.

GitHub가 받아쓰기를 막는 일은 없습니다. 다만 자체적으로 제공하는 게 없을 뿐입니다. 그래서 선택지는 대략 세 가지입니다. 운영체제에 받아쓰기가 내장되어 있습니다. Windows에서는 Win+H로 음성 입력, macOS에서는 받아쓰기를 쓸 수 있죠. Voice In 같은 브라우저 확장 프로그램은 Chrome이나 Edge 탭 안에 입력해 줍니다. 또는 Whisper 같은 시스템 전역 데스크톱 앱은 브라우저든 아니든, 어떤 앱의 어떤 입력란에든 받아씁니다.

이 셋의 차이는 도달 범위입니다. 운영체제 받아쓰기는 무료지만 한 번에 하나의 플랫폼에서만 동작하고 품질도 들쭉날쭉합니다. 브라우저 확장은 탭 안에서만 살아 있어서, IDE나 GitHub CLI까지 따라오지 못하고 클라우드에서 실행됩니다. Whisper 같은 데스크톱 앱은 탭에 묶여 있지 않습니다. 운영체제 수준에서 동작하기 때문에 Chrome, Firefox, Safari, Edge의 GitHub에 받아쓰고, GitHub Desktop의 커밋 메시지에도 받아씁니다.

실제로 받아쓸 수 있는 것 (그리고 받아쓸 수 없는 단 한 가지)

실수로라도 넘지 않게 하려는 선이 하나 있습니다. Whisper는 코드 주변의 글을 받아씁니다. 코드 자체를 써 주지는 않습니다.

그 범위가 솔직히 개발자가 하루에 타이핑하는 일의 대부분을 차지합니다. 이슈 보고서. 풀 리퀘스트 설명. 코드 리뷰 메모. Discussions 답글. README와 마크다운 문서. 변경 사항을 설명하는 글이지, 변경 사항 그 자체는 아닙니다. 마이그레이션이 왜 위험한지 설명하는 문단을 말하면 Whisper는 잘 처리합니다. 하지만 마이그레이션 자체를 받아쓰려 들면, 오후 시간을 망치게 될 겁니다.

이유는 단순합니다. 말로 한 코드는 이 여정을 살아남지 못합니다. 함수 이름, JSON, snake_case 대 camelCase, kubectl 플래그, API 경로 같은 것들은 최선을 다한 영어 받아쓰기로 나오기 때문에 손으로 고쳐야 합니다. 음성 모델은 "user underscore I D"를 듣고 "user ID"라고 쓰고, 그러면 당신은 그걸 바로잡고 있게 됩니다. 그러니 "이 PR은 인증 미들웨어의 null 체크를 고친다"는 문장을 받아쓰고, 실제 식별자는 직접 타이핑하세요. 어차피 대부분의 이슈와 PR 본문은 80%가 설명이고 20%가 코드 조각입니다. 80은 받아쓰고, 20은 타이핑하세요.

단축키를 누르고 말하면, 포커스된 입력란에 텍스트가 들어옵니다

동작 방식은 다른 어떤 앱에서 쓰던 것과 똑같고, 바로 그게 핵심입니다. 채우려는 GitHub 입력란을 클릭합니다. 단축키를 누른 채로. 말합니다. 뗍니다. 받아쓴 글이 커서 위치에 나타납니다.

기본 단축키는 Windows에서는 Ctrl+Space, macOS에서는 Command+Option입니다. 둘 다 누르고 말하는 방식(push-to-talk)으로, 말하는 동안 누르고 있다가 멈추려면 떼면 됩니다. 다른 것과 충돌하면 설정에서 바꿀 수 있습니다. 단축키 충돌과 싸워 본 적이 있다면, 그 설정이 왜 자리를 차지하고 있는지 알 겁니다(자세한 내용은 아래에서).

범위에 대한 솔직한 한 가지. Whisper는 당신이 포커스해 둔 한 개의 입력란에, 한 번에 하나씩 붙여 넣습니다. GitHub 이슈 양식 전체를 한 호흡에 채우지는 않습니다. 그래서 새 이슈를 만드는 흐름은 이렇습니다. 제목을 클릭하고 받아쓰고, 본문을 클릭하고 받아쓰고. 입력란 둘, 누름 둘. 마법이라기보다는, 키보드에 손도 안 대는 빠른 타이피스트에 가까운 느낌입니다. 그게 올바른 사고방식입니다.

앱 전체를, 실시간으로

이건 스크린샷이 아니라 바로 여기서 실행 중인 진짜 앱입니다. 마음껏 눌러 보세요. 설정, 단축키 선택기, 모델 선택 모두 진짜입니다.

클릭하면서 알아 두면 좋은 점 두 가지. GitHub 전용 탭도 없고 "GitHub 모드"도 없습니다. 그럴 필요가 없기 때문입니다. Whisper에게 GitHub PR 설명은 여느 텍스트 입력란과 다를 바 없습니다. 이슈 편집기에 받아쓰는 그 설정 그대로 이메일에도, IDE에도 받아씁니다. 한 번만 설정하면 됩니다. 도달 범위가 곧 기능입니다.

진가가 드러나는 곳: 이슈, PR 설명, 리뷰, 토론

진가는 지루하고 반복적인 글쓰기에서 드러납니다. 타이핑이 귀찮아서 자꾸 미루게 되는 바로 그런 것들이죠.

이슈. 좋은 버그 리포트는 대부분 서술입니다. 무엇을 했고, 무엇을 기대했고, 대신 무엇이 일어났는지. 그게 바로 받아쓰기의 홈그라운드입니다. 옆자리 동료에게 설명하듯 재현 단계를 말로 풀어내고, 스택 트레이스는 손으로 붙여 넣으세요.

풀 리퀘스트 설명. diff가 "스스로 말한다"는 이유로 다들 쓰기를 건너뛰는 PR 본문(사실은 스스로 말하지 않습니다). 왜 그렇게 했는지를 받아쓰고 — 리뷰어에게 필요한 맥락 말입니다 — 무엇을 했는지는 diff가 말하게 두세요.

코드 리뷰. 리뷰 댓글은 어조가 중요한 곳이자 사람들이 설명을 너무 아끼는 곳입니다. 리뷰 메모를 말로 하면, 회의 사이사이에 타이핑한 것보다 더 사람답고 더 충실하게 나오는 경향이 있습니다. "엣지 케이스?" 한 마디 대신 "이건 동작하지만, 리스트가 비면 깨질 겁니다"라고 쓰게 되죠.

토론과 문서. 긴 글, 바로 음성이 잘하는 것이자 아무도 타이핑하고 싶어 하지 않는 것입니다. README 도입부, Discussions 답글, 마이그레이션 가이드 — 초안을 받아쓰고, 마크다운은 나중에 다듬으세요. 같은 논리가 Jira 티켓이나 다른 트래커에 받아쓸 때도 적용됩니다. GitHub은 그 더미 위의 또 하나의 입력란일 뿐입니다.

받아쓴 내용을 자동으로 다듬기

날것의 받아쓰기에는 군더더기가 있습니다. "음," "있잖아," 두 번 시작한 문장 같은 것들이죠. Whisper에는 군더더기 단어, 문장 부호, 대소문자를 고쳐 주는 선택적 AI 다듬기 단계가 있어서, 이슈나 PR이 마치 공들여 쓴 것처럼 읽히게 만들어 줍니다.

두 가지 방식이 있습니다. 무료 로컬 등급에서는 Ollama를 통해 다듬기가 당신의 기기에서 실행됩니다. Pro에서는 자신의 OpenAI 키를 가져와 다듬기가 클라우드에서 실행되며, 웹 답변도 함께 이용할 수 있습니다. 어느 쪽이든 선택 사항입니다. 끄면 날것의 받아쓰기 그대로 받습니다. 저는 PR 설명에는 켜 두고 빠른 댓글에는 꺼 둡니다. 빠른 댓글은 다듬을 필요가 없고, PR 설명은 필요하니까요.

다듬기가 해 주지 못하는 한 가지는 말로 한 코드를 구해 내는 것입니다. 영어 문장은 다듬지만, 당신이 "get user by I D"라고 말했을 때 getUserById를 의도했다는 건 알지 못합니다. 글은 계속 받아쓰고, 식별자는 계속 타이핑하세요.

오프라인이자 비공개: 로컬 모드에서는 아무것도 기기를 벗어나지 않습니다

공개되지 않은 코드에 대한 이슈나 PR을 받아쓴다면, 음성이 어디로 가는지가 중요합니다. Whisper의 로컬 모드에서는 받아쓰기가 전적으로 당신의 기기에서 일어납니다. 당신이 말한 어떤 것도 클라우드 서비스로 전송되지 않습니다. 받아쓰는 동안에는 인터넷이 전혀 필요 없습니다. 온라인에 연결되는 유일한 순간은 한 번뿐인 모델 다운로드인데, 선택한 모델에 따라 약 140MB에서 3GB 사이입니다.

여기서만큼은 제 진짜 의견을 드리겠습니다. 클라우드 전용 받아쓰기는 받아 적히기만을 기다리는 프라이버시 재앙입니다. 한번은 어느 내부 팀이 자체 제작한 받아쓰기 프로토타입이 모든 발화를 API로 보내는 바람에 한 분기 만에 다섯 자릿수 클라우드 청구서를 쌓는 걸 지켜봤습니다. 더 끔찍한 건 청구서가 아니라, 출시되지 않은 제품에 대한 모두의 음성 메모가 이제 어느 벤더의 로그에 남게 되었다는 점이었습니다. 상사의 연봉 스프레드시트, 비공개로 제출하는 보안 이슈, PR에서 설명하는 독점 아키텍처 — 그중 어느 것도 단지 음성으로 문단 하나를 입력하고 싶었다는 이유로 당신의 노트북을 벗어나서는 안 됩니다. 당신의 기기에는 이미 마이크와 CPU가 있습니다. 문단 하나에는 중간에 서버가 끼어들 필요가 없습니다. 당신의 도구가 클라우드에서만 돌아간다면, 제가 가장 먼저 고칠 부분이 바로 그것입니다.

이것이 위한 게 아닌 것 (코드 작성)

음성으로 코드를 쓰는 방법을 찾아 여기까지 왔거나, "Hey, GitHub!"을 기억하며 그게 어디로 갔는지 궁금해할지도 모릅니다. 솔직한 답 두 가지를 드립니다.

"Hey, GitHub!"과 GitHub Copilot Voice는 GitHub Next의 기술 프리뷰였습니다. GitHub은 2024년에 그 프리뷰를 중단했습니다. 끝내 제품이 되지는 못했고, 거기서 얻은 교훈은 VS Code Speech 확장으로 흘러 들어갔습니다. 그러니 오늘날 어떤 블로그 글이 "Hey GitHub"을 켜라고 한다면, 그건 몇 년이나 철 지난 정보입니다.

음성으로 코드를 다루는 영역은 여전히 존재합니다. 다만 github.com이 아니라 당신의 편집기와 터미널에 살고 있을 뿐입니다. VS Code Speech 확장(때로 "Hey Code"라고도 불립니다)은 편집기와 Copilot Chat에 대고 말해 코드와 명령을 다룰 수 있게 해 줍니다. 그리고 GitHub Copilot CLI에는 최근 터미널에서 Copilot 에이전트를 움직이는 로컬 음성 입력이 추가되었습니다. 이 둘은 코드와 AI 에이전트를 조종하기 위한 것입니다. 어느 쪽도 브라우저에서 GitHub 이슈에 글을 받아쓰지는 않습니다. 그건 다른 영역이고, 바로 Whisper가 차지한 영역입니다. 코드 주변의 글쓰기 말이죠.

GitHub 워크플로에서 Whisper를 건너뛰어야 할 때

제가 만든 도구보다 당신에게 맞는 도구를 쓰셨으면 합니다. 그래서 Whisper를 건너뛰어야 할 때를 알려 드립니다.

정말로 원하는 게 음성으로 Copilot이나 편집기를 조종하는 것이라면 — "이 함수 고쳐줘," "테스트 실행해," "이 블록 설명해줘" — 그건 글이 아니라 코드/에이전트 영역입니다. 대신 VS Code Speech 확장이나 GitHub Copilot CLI 음성 입력을 쓰세요. 그것들은 기계에 말을 걸고, Whisper는 사람이 읽을 말을 씁니다.

어쩌다 한 줄짜리 댓글만 가끔 받아쓴다면, 운영체제가 이미 그걸 공짜로 해 줍니다. Windows에서는 Win+H를 누르거나 macOS에서는 받아쓰기를 켜면, 아무것도 설치하지 않고도 GitHub 입력란에 짧은 문장을 떨어뜨릴 수 있습니다. Whisper가 제값을 하기 시작하는 건, 여러 앱에 걸쳐 진짜 문단을 쓰거나, 오프라인으로 동작하길 원하거나, 일부 입력란만 커버하는 운영체제 기능 대신 어디서나 통하는 하나의 단축키를 원할 때입니다. 그 기준 아래라면 내장 옵션으로 충분하고, 저는 아닌 척하지 않겠습니다.

무료 로컬, 클라우드는 Pro로

로컬 파이프라인 — 받아쓰기, 기기 내 AI 다듬기, 단축키 등 GitHub에 받아쓰는 데 필요한 모든 것 — 은 로그인한 사용자에게 무료이며, 가입 시 카드가 필요하지 않습니다. 설치하고, 로그인하고, 받아쓰기를 시작하면 됩니다.

Whisper Pro는 클라우드 영역을 더합니다. OpenAI 클라우드 받아쓰기, 자신의 키를 사용하는 클라우드 AI 다듬기, 그리고 웹 답변이며, 이 등급에는 짧은 체험 기간이 있습니다. 이슈와 PR을 받아쓰는 용도라면 무료 로컬 등급이 전부 커버합니다. Pro의 숫자는 가격 페이지에 있습니다. 문단 한가운데서 그 숫자를 들이밀지는 않겠습니다.

그 단축키에 대한 마지막 한마디

단축키가 왜 변경 가능한지에 대한 한마디로, 이 모든 걸 하나로 묶어 보겠습니다. Whisper의 첫 버전은 특정 Windows 기기에서 키를 한 번 누를 때마다 녹음 중지를 여섯 번씩 발동했습니다. 입력 프레임워크에서 나오는 유령 같은 키 떼기 이벤트였는데, 깨끗한 설치 환경에서는 멀쩡하다가 실제 기기에서는 깨지는 그런 종류였죠. 300ms 디바운스와, 인정하고 싶지 않을 만큼의 시간이 걸려서야 안정적으로 만들었습니다. 그 과정에서 Windows 입력 처리에 대해 알고 싶었던 것보다 훨씬 많이 배웠습니다. 그때 새긴 교훈이 있습니다. 단축키가 당신의 기기에 맞춰 휘어야지, 그 반대가 되어서는 안 된다는 것. 입력란을 클릭하고, 키를 누른 채 말하세요. 코드는, 여전히 당신이 직접 타이핑합니다. 그게 이 거래의 정직한 버전이라고 생각합니다.