여섯 번째 붙여 넣기에서 오전이 무너졌다
지난주 수요일 오전 10시 17분, 저는 Gemini 창 두 개와 번역 문서 하나를 번갈아 보다가 같은 문장을 일곱 번째 붙여 넣고 있었습니다. 답을 고르는 데는 3분이 걸렸는데, 어느 창이 최종본인지 다시 찾는 데는 12분이 걸렸습니다. 글자는 빨리 나왔는데 제 오전은 전혀 빨라지지 않았습니다.
그래서 저는 Gemini Voyager를 기능표보다 작업 동선의 문제로 먼저 봅니다. Google Gemini를 더 영리하게 만드는지보다, 비개발자 직장인이 같은 클릭을 세 번 덜 하게 만드는지가 더 중요하다고 생각합니다.
좋은 모델만 고르면 하루가 가벼워진다는 착각
다들 먼저 묻습니다. Gemini가 낫냐, ChatGPT가 낫냐, Claude가 낫냐. 저도 한동안 그 질문만 붙들었습니다. 그런데 기술을 직접 만드는 사람이 아닌 제 일상에서는, 모델 점수보다 창 전환 비용이 더 크게 남았습니다.
이건 일을 잘하는 신입에게 엉킨 지시를 던지는 장면과 비슷합니다. 사람은 똑똑한데 파일은 메일에 있고 수정 요청은 메신저에 있고 최종본은 드라이브 어딘가에 있으면, 실력보다 왕복이 먼저 사람을 지치게 합니다. AI도 같습니다. 답은 괜찮은데 맥락이 창마다 끊기면, 사용자는 결국 다시 설명하고 다시 복붙하고 다시 확인합니다.
저는 지난달에 서비스 세 개를 오가며 번역 지시문 12개를 다시 만들었습니다. 품질은 조금 나아졌지만, 오후 4시에 제가 한 일의 절반은 문장 개선이 아니라 정리 실패를 수습하는 일이었습니다.
더 똑똑한 답보다 덜 끊기는 손이 먼저 값을 만든다
제 주장은 분명합니다. Gemini Voyager 같은 통합형 확장 프로그램은 “더 좋은 답”보다 “덜 흩어지는 작업”을 먼저 증명해야 합니다. 여기에 동의하지 않는 분도 있을 겁니다. 그래도 비개발자 직장인의 실제 하루를 기준으로 보면, 답변 품질 5퍼센트보다 반복 동작 30퍼센트 감소가 오래 남는 경우가 많습니다.
제가 지난달 번역 초안 하나를 재보니 총 43분이 들었습니다. 이 가운데 순수하게 문장을 다듬은 시간은 17분이었고, 나머지 26분은 원문 찾기, 이전 맥락 복원, 말투 맞추기, 결과를 문서 형식에 다시 끼워 넣는 데 썼습니다. 자동화는 미래를 과시하는 장난감이 아니라 이런 26분을 돌려주는 기술이어야 한다고 저는 봅니다.
이번 건은 현재 공개 기록에는 원문 링크가 아직 연결되어 있지 않습니다. 그래서 Gemini Voyager의 실제 권한 범위, 저장 방식, 사용자 수, 어느 정도까지 자동화하는지는 확인하지 못했습니다. 저는 이런 빈칸을 덮고 기능을 단정하는 글을 별로 믿지 않습니다. 다만 제목에 붙은 “Google Gemini를 보완하는 통합형 확장 프로그램”이라는 설명만으로도, 무엇을 시험해야 하는지는 충분히 정할 수 있습니다.
| 비교 항목 | 새 모델로 갈아탈 때 기대하는 것 | 통합형 확장 프로그램에서 먼저 줄어야 하는 것 |
|---|---|---|
| 답변 품질 | 더 나은 문장, 더 긴 추론 | 같은 질문 재작성 횟수 |
| 작업 속도 | 잘 맞으면 한 번에 끝남 | 탭 이동, 복붙, 맥락 복원 시간 |
| 학습 비용 | 모델 성격을 다시 익혀야 함 | 기존 습관 위에 얹기 쉬워야 함 |
| 실패했을 때 손해 | 결과가 별로면 처음부터 다시 | 불편하면 제거하고 원래 흐름으로 돌아올 수 있어야 함 |
제가 이런 표를 굳이 남기는 이유는 단순합니다. 많은 사람이 AI 도구를 “정답 기계”처럼 고르지만, 실무에서 먼저 새는 건 정답의 질보다 손의 리듬이기 때문입니다. 메일 초안, 회의 메모, 웹페이지 요약, 번역 수정 같은 일은 특히 그렇습니다. 지금 보고 있는 화면의 문맥을 다시 설명하지 않아도 되고, 결과를 바로 문서 문장으로 옮길 수 있고, 내가 방금 고친 톤을 조금이라도 이어받는다면, 그때부터 확장 프로그램은 장식이 아니라 작업 시스템이 됩니다.
저는 이런 도구를 볼 때 늘 한 줄로 정리합니다.
> 좋은 AI는 답을 잘 주고, 쓸 만한 AI는 사람을 덜 왕복시킨다.
회사 노트북에 바로 얹으면 오히려 손해인 사람도 있다
물론 이 기준이 모든 사람에게 맞지는 않습니다. 하루에 Gemini를 한두 번만 쓰는 사람이라면 확장 프로그램 하나 더 올리는 일이 오히려 귀찮을 수 있습니다. 보안이 엄격한 조직에서는 설치 자체가 막혀 있기도 합니다.
저도 예전에 편의를 믿고 외부 도구에 고객사 문장 메모를 너무 빨리 넣었다가, 삭제 경로와 보관 범위를 다시 확인하느라 40분을 날린 적이 있습니다. 그 뒤로는 공개 출처가 연결되지 않았거나 권한 설명이 불명확한 도구에 회사 문서부터 연결하지 않습니다. 편의는 시간을 아껴주지만, 확인되지 않은 저장 방식은 그 절약분을 한 번에 되가져갑니다.
그래서 Gemini Voyager를 시험한다면, 저는 개인 자료나 공개 문서부터 붙여볼 겁니다. “생산성”이라는 말보다 먼저, 내 문장이 어디까지 흘러가는지부터 확인해야 합니다.
내일 아침에 셀 숫자는 토큰이 아니라 창 전환이다
오늘 바로 해볼 일은 크지 않습니다. 내일 오전 첫 30분만 아래 세 숫자를 적어보세요.
- 같은 문장을 다른 창에 몇 번 붙여 넣는지
- 이미 했던 설명을 AI에게 몇 번 다시 쓰는지
- 최종본을 찾거나 형식을 맞추는 데 몇 분이 드는지
이 셋이 생각보다 크다면, 당신에게 필요한 건 “제일 똑똑한 모델”보다 “덜 흩어지는 작업 동선”일 수 있습니다. 저는 자동화를 그렇게 씁니다. 멋있어 보이는 데서가 아니라, 하루를 덜 잘게 부수는 곳에서부터요.
다음 편에서는 브라우저 확장 하나를 붙일 때 어디까지를 편의로 보고, 어디서부터는 멈춰야 하는지 적겠습니다. 권한과 저장, 그리고 회사 자료를 넣어도 되는 경계선 이야기입니다.
핵심 정리
- 지난주 수요일 오전 10시 17분, 저는 Gemini 창 두 개와 번역 문서 하나를 번갈아 보다가 같은 문장을 일곱 번째 붙여 넣고 있었습니다.
- 그래서 저는 Gemini Voyager를 기능표보다 작업 동선의 문제로 먼저 봅니다.
- 다들 먼저 묻습니다.
→ 영어판 보기
