Editor View 핵심 기능: 탭 자동완성·인라인 명령·자연어 코드 지시
Editor View는 내 손이 닿는 구간을 빠르게 만드는 화면입니다. 여기서의 목표는 단순합니다. 작은 변경은 더 빨리 끝내고, 변경이 커지는 순간에는 에이전트에게 넘길 준비를 갖추는 것입니다.
Antigravity는 Editor 안에서 쓰는 AI 기능을 크게 Tab과 Command(인라인 지시)로 구분해 설명합니다.1 이 둘을 잘 쓰면 "타이핑을 줄이는 수준"을 넘어, 수정 루프 자체를 짧게 만들 수 있습니다.
Editor View에서 '손코딩'이 빨라지는 3단 기어
Editor View에서의 생산성은 보통 세 가지 기어로 움직입니다.
1단(타이핑 절약): 자동완성으로 다음 몇 글자~몇 줄을 받아 적는다.
2단(파일 단위 편집): "이 블록을 이렇게 바꿔줘" 같은 지시로 diff를 받아 빠르게 수정한다.
3단(작업 단위 위임): 여러 파일/테스트/실행/검증이 엮이면 에이전트에게 넘긴다.
이 챕터는 1단과 2단을 확실히 익혀, "아직 에이전트까지는 아니지만 손으로 하기엔 귀찮은" 영역을 최대한 줄이는 데 집중합니다.
Tab 자동완성: '내가 다음에 칠 문장'을 받아 적는 기술
Tab 자동완성은 전통적인 IntelliSense(심볼/메서드 목록)와 다릅니다. IntelliSense가 "가능한 후보 목록"을 보여주는 기능이라면, Tab 자동완성은 문맥을 보고 다음 편집의 덩어리를 제안하는 쪽에 가깝습니다.23
VS Code의 IntelliSense는 언어 서비스가 제공하는 후보를 보여주고, 사용자가 Tab/Enter로 선택한 항목을 삽입하는 방식으로 동작합니다.2 반면 AI 기반 Tab은 주변 코드·최근 수정·린트/오류 같은 신호를 바탕으로 다음 코드를 제안하는 형태로 설명됩니다.3
Tab을 '코드 생성'이 아니라 '미세 편집'에 쓰는 습관
Tab 자동완성은 강력하지만, 가장 효율이 좋은 구간은 의외로 거창한 신규 기능 구현이 아니라 미세 편집입니다. 다음 같은 상황에서 Tab은 거의 "자동 타이핑"에 가깝게 작동합니다.
반복되는 패턴 이어쓰기: 비슷한 if/guard, 로깅, 에러 핸들링, props 전달 등
타입/스키마에 따른 자연스러운 채우기: 인터페이스 필드, DTO 매핑, 객체 리터럴 채우기
이름 규칙 유지: 프로젝트의 네이밍/스타일을 따라 변수·함수명을 자연스럽게 제안
요령은 하나입니다. Tab 제안이 뜨면 "맞다/아니다"를 1초 안에 결정합니다. 1초 이상 망설이면 이미 손으로 치는 게 더 빠르거나, 2단(인라인 지시)로 넘어갈 신호일 가능성이 큽니다.
'수락/거절' 키를 몸에 붙이기
대부분의 편집기는 제안을 Tab으로 수락하고, Esc/Del로 거절하는 패턴을 제공합니다.4 수락/거절이 매끄럽지 않으면 Tab은 오히려 흐름을 끊습니다.
특히 "목록 기반 자동완성(IntelliSense)"과 "회색 글자 인라인 제안(whole-line/AI 제안)"이 겹치면, 같은 Tab 키가 서로 다른 일을 하기도 합니다. Visual Studio의 IntelliCode는 이런 충돌을 설명하면서, 목록 항목을 먼저 수락하고 다음 Tab으로 인라인 제안을 수락하는 흐름('Tab Tab')까지 안내합니다.4
Antigravity에서도 핵심은 같습니다. Tab은 수락의 키로 쓰되, 충돌이 나면 설정/단축키를 정리해 "내 손이 기억하는 한 가지 동작"으로 고정하는 편이 좋습니다.
Tab이 안 먹히는 대표 원인: 포커스/단축키 충돌
Tab이 '완성 수락'이 아니라 포커스 이동으로 동작하면 체감 생산성이 급락합니다. VS Code에서는 Tab이 포커스를 옮기도록 토글되어 있는 경우가 있고('Toggle Tab Moves Focus'), 이 설정 때문에 자동완성 수락이 꼬였다고 느끼는 경우가 있습니다.5
또 다른 흔한 원인은 "다른 확장/기능이 Tab을 가로채는" 상황입니다. Cursor 커뮤니티에서도 인라인 제안을 Tab으로 수락하지 못할 때, 키보드 단축키 설정을 점검하거나 특정 기능(예: Cursor Tab)을 토글하라고 안내합니다.6
정리하면, Tab을 편집에 쓰려면 먼저 Tab의 우선권을 확보해야 합니다.
Tab 자동완성의 '적정 범위': 여기까지는 손으로, 여기부터는 지시로
Tab은 한 번에 한 덩어리를 빠르게 넣는 데 강합니다. 하지만 덩어리가 커질수록 "내가 원하는 코드"와 "모델이 제안하는 코드" 사이의 오차도 커집니다.
그래서 실전에서는 다음 경계선을 권합니다.
한 함수 안에서 끝나는 편집은 Tab로 밀어붙이되, 제안이 2번 연속 빗나가면 즉시 멈춘다.
파일 여러 곳을 동시에 바꿔야 하는 편집(예: 변수명 변경이 여러 함수로 퍼짐)은 Tab로 억지로 이어붙이지 말고 2단으로 간다.
여러 파일/테스트/실행이 얽히는 변경은 3단(에이전트)으로 넘어갈 준비를 한다.
이 경계가 '작은 변경은 더 빨리, 큰 변경은 위임'이라는 핵심을 실제 행동으로 만들어 줍니다.
인라인 명령(Command): "이 블록을 이렇게 바꿔줘"를 diff로 받기
인라인 명령은 Editor에서 가장 자주 쓰게 되는 두 번째 무기입니다. 방식은 단순합니다.
코드를 선택하거나 커서를 두고, 자연어로 "무엇을 어떻게 바꿀지"를 적으면, 도구는 바뀐 결과를 diff 형태로 제안하고 사용자는 이를 수락/거절합니다.78
이 'diff로 검토'가 중요한 이유는, 인라인 지시는 속도가 빠른 대신 실수가 섞이기 쉬워서입니다. 수락 전에 바뀐 내용을 눈으로 확인할 수 있어야, Editor View의 즉시성이 유지됩니다.
선택 영역 편집 vs 커서 위치 생성
대부분의 인라인 지시 도구는 다음 규칙을 따릅니다.
코드를 선택하고 호출하면 선택한 범위를 편집한다.
선택하지 않으면 커서 위치에 새 코드를 생성한다.78
이 단순한 규칙을 '편집 전략'으로 바꿔보면 이렇게 됩니다.
함수 하나를 통째로 다듬고 싶으면 그 함수 블록을 선택합니다. 반대로, 새 헬퍼 함수를 추가하고 싶으면 커서를 "추가하고 싶은 위치"에 두고 지시합니다. 이렇게 하면 AI가 맥락을 오해할 여지가 크게 줄어듭니다.
좋은 인라인 지시는 '요구사항'이 아니라 '변경 계약'이다
인라인 지시는 짧을수록 좋지만, 너무 짧으면 모델이 임의로 결정을 내립니다. 실전에서는 아래 3가지를 한 문장에 담는 방식이 안정적입니다.
목표: 무엇을 달성할지(예: null 처리 추가)
제약: 무엇을 건드리면 안 되는지(예: 함수 시그니처 유지)
검증 기준: 무엇이 맞는지(예: 테스트 통과, 린트 경고 0)
예를 들면 이런 식입니다.
"이 함수에 null/undefined 방어 로직을 추가해줘. 외부 API는 바꾸지 말고, 기존 반환 타입을 유지해. 예외는 throw 대신 Result 타입으로 내려."
이 정도만으로도 '리팩터링' 같은 추상 지시보다 결과가 훨씬 예측 가능해집니다.
수락/거절을 빠르게 만드는 습관
인라인 지시를 자주 쓰면 병목은 생성 속도가 아니라 검토 속도가 됩니다. Augment는 diff 뷰에서 변경을 확인하고 Enter로 수락, Esc로 거절하는 흐름을 명시합니다.7 Windsurf도 비슷하게 코드 렌즈/단축키로 수락·거절·후속 지시를 이어가게 설계했습니다.8
즉, 인라인 지시는 "잘 쓰면 빠르다"가 아니라 "검토 루프가 빨라야 빠르다"입니다.
바뀐 줄이 20줄 이하면 Editor에서 즉시 검토하고 수락
바뀐 줄이 100줄을 넘어가면 '왜 이렇게 많이 바뀌었지?'를 먼저 의심
영향 범위가 파일 밖으로 보이면, 그 순간이 3단으로 넘어갈 타이밍
자연어 코드 지시의 역할 분담: Tab vs Command vs Agent
세 기능은 서로 대체재가 아니라 역할이 다릅니다.
Tab: 내가 방향을 확실히 아는 '다음 한 걸음'
Tab은 내가 이미 결정을 내렸고, 다음 코드가 거의 확실할 때 가장 강합니다. 함수 이름과 반환 형태가 머릿속에 있고, "타이핑만 귀찮다"면 Tab을 씁니다. IntelliSense처럼 후보를 빠르게 삽입하는 방식도 여전히 유효하고, VS Code는 Ctrl+Space로 제안을 트리거할 수 있다고 안내합니다.2
Command: 파일 안에서 끝나는 '의미 있는 변경'
Command는 한 파일에서 끝나지만 손으로 하면 번거로운 작업에 최적입니다.
예를 들어, 에러 처리 방식 통일, 특정 API 호출부를 새 유틸로 감싸기, 매직 넘버 상수화, 함수 쪼개기 같은 작업은 "설명할 수는 있는데 직접 치기엔 길다"에 해당합니다. 이때 선택 영역 + 변경 계약(목표/제약/검증)을 주고 diff로 받으면 속도가 크게 오릅니다.78
Agent: 파일을 넘어서는 '작업 단위'
여러 파일을 수정해야 하거나, 테스트/실행/브라우저 확인까지 엮이면 "코드 편집"이 아니라 "작업 수행"이 됩니다. Antigravity가 Tab/Command와 별개로 Agent를 1급 모달리티로 둔 이유도 여기 있습니다.1
Editor View의 핵심은 Agent를 쓰지 않는 게 아니라, Agent에게 넘길 때 내 의도가 깨끗하게 전달되도록 정리해 주는 것입니다.
에이전트에게 넘기기 직전: Editor에서 준비해야 하는 4가지
큰 변경을 Agent로 넘길수록, 넘기기 직전의 준비가 결과를 좌우합니다. Editor View에서 아래 네 가지를 준비하면, 다음 챕터(에이전트 사이클)로 넘어갈 때 시행착오가 줄어듭니다.
첫째, 목표를 코드 옆에 고정합니다. TODO 주석이든, 작은 체크리스트든, "무엇을 끝내야 완료인지"가 파일에 남아 있으면 에이전트가 맥락을 잡기 쉬워집니다.
둘째, 실패한 시도(에러 로그/린트 경고/테스트 실패)를 한 번은 직접 확인합니다. 탭 자동완성과 인라인 지시는 빨라도, 잘못된 방향으로 달리면 되돌리기가 더 느립니다.
셋째, 변경 범위를 가늠합니다. 지금 고치려는 것이 한 파일인지, 모듈 전체인지, API 계약을 바꾸는지 판단해두면 "지금은 Command로 충분한지, Agent가 필요한지"가 선명해집니다.
넷째, 검증 방법을 한 문장으로 말할 수 있게 만듭니다. "테스트 X가 통과하면 된다" "이 화면에서 버튼을 눌렀을 때 토스트가 떠야 한다"처럼 검증 기준이 명확하면, 에이전트는 작업을 끝까지 완주하기 쉬워집니다.
미니 워크플로 3가지: 오늘부터 바로 쓰는 패턴
1) '한 줄 더' 패턴: Tab으로 뼈대를 이어붙이기
내가 이미 쓰고 있는 코드 패턴을 한 줄 더 반복해야 할 때, Tab은 가장 강합니다. 예를 들어 비슷한 필드 매핑이나 조건문 가지가 하나 더 필요할 때, Tab 제안을 보고 수락/거절만으로 타이핑을 크게 줄입니다.3
2) '블록 교체' 패턴: 선택 + 인라인 지시로 diff 받기
리팩터링처럼 "내가 원하는 그림은 분명한데 손이 많이 가는" 작업은 선택 범위를 좁혀 인라인 지시를 겁니다. 그리고 diff를 검토해 수락/거절합니다.78
3) '경계선' 패턴: 변경이 커지면 멈추고 Agent로 전환
인라인 지시가 제안한 diff가 커지고, 파일 밖 영향이 보이기 시작하면 멈춥니다. 이때부터는 Editor View에서 억지로 끝내려 하지 말고, 목표/제약/검증을 정리해 Agent에게 넘기는 편이 빠릅니다.1
참고
1Google Antigravity Documentation (Tab)
2IntelliSense (Visual Studio Code Documentation)
4IntelliCode Whole-line autocompletions - Visual Studio (Windows) | Microsoft Learn
5Tab autocomplete in Visual Studio Code doesn't work (Stack Overflow)
6How to enable tab-to-complete for inline auto-suggestions? (Cursor Community Forum)
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.