Emacs에 Antigravity CLI가 붙으면 쓸만할까? (feat. ai-code-interface.el)

지금까지 몇몇 시험을 해보며 터미널에서 Antigravity CLI(이하 agy)를 그럭저럭 쓰고 있었다. 처음으로 토큰 한도까지 겪으며 하루 종일 못 쓰는 경험을 해보니 왜 사람들이 구독을 하는지 이해를 할 정도였다.

그러다 보니 주로 사용하는 에디터인 Emacs에서 agy를 좀 더 편하게 쓸 수 있는 방법이 있을까 갑자기 궁금해졌다. AI 에이전트가 한창 발전되는 와중에 설마 Emacs 관련 확장이 없지는 않았을 테고 말이다.

그래서 agy에게 확장에 관해 물어보고 사용하고 있는 Emacs 및 Doom Emacs 설정에 맞게 확장을 설치할 수 있게 해달라고 부탁해 봤다.

기특하게도 agy는 꽤나 괜찮게 일 처리를 해줬다.

agy가 해 준 것들

agy가 추전해 준 확장은 ai-code-interface.el이었다. 이를 Doom Emacs에 맞게 설정해 달라고 부탁했다.

agy는 우선 ~/.doom.d/package.el에 이런 내용 추가해 줬다.

(package! ai-code
  :recipe (:host github :repo "tninja/ai-code-interface.el"))

이 설정은 Doom Emacs에 의해 관리되지 않는 외부 확장 패키지를 설치할 때 흔하게 볼 수 있는 설정이다. 당연하게도 이걸 적용해 달라고 부탁했고 agy가 직접 해당 파일을 수정해 줬다.

이제 설정을 해야 할 차례다. agy는 SPC c a라는 단축키로 관련된 기능을 사용할 수 있는 설정을 알려줬다.

다만 알려준 설정에는 약간의 문제가 있었는데 기존에 SPC c a 키 조합은 이미 lsp-execute-code-action 용으로 배정된 상태였기 때문이다.

생각해 보니 이 lsp-execute-code-action 기능은 거의 안 쓰는 기능이긴 하다. LSP가 추천해 주는 변경사항을 실행시키는 기능인데 AI 에이전트가 대부분의 일을 처리해 버리는 이상 미래에는 정말 쓸 일이 없게 될 것 같은 기능이니 말이다.

그래서 agy에게 lsp-execute-code-action에 매핑할 키 조합을 다른 것으로 바꾸고 나머지는 추천해 준 설정으로 적용해 달라고 했다.

결과적으로 agy는 ~/.doom.d/config.el에 이런 내용 추가해 줬다.

(use-package! ai-code
  :defer t
  :init
  (map! :leader
        :desc "LSP Execute code action" "c A" #'lsp-execute-code-action
        :desc "AI Code Menu"            "c a" #'ai-code-menu)
  :config
  (ai-code-set-backend 'antigravity))

여기까지 agy는 꽤나 준수한 일 처리를 보여줬다. 약간의 트러블이 있었으나 지적해 주니 바로 고쳐주는 마치 사람 같은 모습까지 보였으니 말이다. 이러니 Emacs에 ai-code-interface.el을 붙이면 얼마나 더 편해질까 기대되기도 했다.

이제 마무리로 실제 확장 설치를 직접 진행했다. Doom Emacs를 쓰니 아래와 같은 sync 커맨드로 확장을 설치해 준 뒤 Emacs를 재시작했다.

~/.config/emacs/bin/doom sync

물론 이 과정도 agy에게 부탁해도 되겠지만 굳이 이런 일로 토큰을 소모하는 건 낭비 같다. 벌써부터 노동력의 가치가 AI에 역전되는 신비로운 일을 경험하고 있다. 좀 슬프다.

이제 시험해 볼까?

설치와 설정이 마무리되었으니 이제 SPC c a를 누르면 ai 관련 메뉴를 볼 수 있다. 그래서 CLI를 띄우는 키인 a를 추가로 눌러봤더니... vterm이 없다고 오류가 발생했다. 이건 왜 미리 안 해 줬을까. AI라고 모든 것을 한 번에 완벽하게 해주진 않는다. 이런 사람 같은 녀석...

그나저나 vterm은 왠지 낯이 익다. 아마도 일부러 안 쓰고 있던 터미널 확장 같은데 왜 이걸 요구할까 이런저런 생각이 흘러갔다. 어쨌든 다시 agy에게 불평을 털어놨다. vterm이 없다는데 어떻게 해결하면 좋을까 말이다.

낯이 익은 게 이유가 있었다. ~/.doom.d/init.el에 이미 주석으로 적혀있을 정도로 Doom Emacs 측에서 관리해 주고 있는 터미널 확장이었기 때문이다. 그래서 이번에도 토큰을 아끼기 위해 (젠장) 직접 init.el에서 vterm 앞에 붙어있던 주석만 제거해 주고 다시 sync를 진행했다. 그리고 agy의 권고대로 Emacs를 재시작했다.

이제 두근거리며 다시 CLI 시작 코 조합인 SPC c a a를 눌러봤다. vterm이 필요로 하는 바이너리들이 빌드된 다음에 바로 창이 분할되며 뭔가가 떴다.

음... 뭐랄까... 그냥 터미널에서 실행시킨 것과 무슨 차이가 있는지 당장은 모르겠지만 하여간 비슷한 화면이 Emacs 안에서 분할되어 나타났다.

이제 시험 삼아 아무거나 물어봐야겠다.

그런데 시작부터 문제를 겪었다. 프롬프트를 한글로 입력하고 싶었는데 vterm 안에서 한글 입력이 되질 않았다. 이건 매우 심각한 결함이다.

정확히 말해 현재 사용하는 Emacs 설정에서 한글 입력을 Emacs 내장 입력기로 하도록 환경을 만들어 놓은 상태였다. 그리고 vterm은 Emacs용 터미널이지만 성능을 위해 실제 터미널 기능은 외부 코드로 구현된 기능에 의존한다. 그래서 이 Emacs 내장 입력기가 vterm에는 전혀 통하지 않는 구조였던 것이다.

어떡하지? 그냥 프롬프트를 영어로 입력해야 하나? 설마 내 수준에서 그게 가능할 리가 없잖아.

그렇다면 고쳐달라고 해보자

기왕 이렇게 된 거 ai-code-interface.el의 첫 실전 겸 터미널 한글 입력 문제를 해결해 달라고 해봐야겠다.

우선 SPC c a a로 CLI를 실행시켜 뒀다.

그다음 ~/.doom.d/config.el 파일을 열고 ai-code-interface.el를 설정하는 부분을 비주얼 모드로 선택한 뒤 SPC c a q로 질문을 던져봤다. "vterm은 Emacs 내장 한글 입력기 사용에 문제가 있으니 다른 걸로 바꿔달라"는 식의 프롬프트로 말이다.

실제 질문 내용은 위 스크린샷을 참고하자.

이제 agy과 필요한 파일들에 대한 권한을 요구하며 분석을 하기 시작했다. 몇 개 안 했는데 벌써 토큰 수백 개가 소모되는 작업이었다.

그리고 어느덧 agy가 해결방안에 대해 몇 가지 선택지를 내놓았다.

CLI가 띄워진 분할창에 표시되는 색상이 영 이상하다. 아무래도 어둡게 세팅된 터미널 색상과 밝게 세팅된 Emacs 테마 사이의 괴리가 있어서 그런 것 같다. 이걸 제대로 보이게 만들고 싶은데 아직은 잘 모르겠다. 나중에 확인해 봐야겠다.

어쨌든 선택지에서 1번을 고르고 싶어서 프롬프트에 그냥 '1'을 입력했다. 이건 eat(Emacs Advanced Terminal)라는 확장을 써보라는 것이었다. agy는 찰떡같이 알아듣고 해당 설정 코드를 직접 반영해 주었다.

그리고 agy는 그 이후에 필요한 작업에 대해서도 물어왔다.

더 이상 토큰을 낭비하지 않기 위해 여기서 종료시켰다. 이미 토큰을 1K 넘게 써버린 상태였다. 로또 1등이 절실하다.

이걸로 문제가 완전히 해결되었을까?

안타깝게도 아직 AI는 역시나 한 번에 모든 것은 완벽하게 처리해 주진 않는다. 정작 중요한 eat 패키지를 설치하는 부분은 빼먹은 것이다.

그래서 eat 확장 설치는 직접 하기로 했다. Doom Emacs에 맞게 ~/.doom.d/packages.el을 열어서 아래 한 줄을 추가해 줬다.

(package! eat)

그러고 나서 아래와 같이 sync를 해줬다.

$ ~/.config/emacs/bin/doom sync

휴... 토큰 많이 아꼈다. 난 대단해. 후후... 이게 뭐야 도대체.

이제 준비는 되었으니 Emacs를 재시작했다. 그리고 바로 확인해 보기 위해 SPC c a a로 에이전트를 띄워봤다.

기대를 했건만 agy가 추천해 준 방법은 오히려 다른 문제를 만들어 냈다. eat로 CLI를 띄우니 화면이 난리가 났기 때문이다. 위 스샷에서 보다시피 색상 문제 수준이 아니라 아예 이상하게 표시가 되었다.

사실 스샷으론 느낄 수 없는데 더 큰 문제가 있었다. 위 상태에서 화면이 미친 듯이 깜빡이기 시작한 것이다. 도저히 쓸 수가 없는 상태였다. 다만 eat 창에서 포커스를 다른 곳으로 옮기면 잠잠해지긴 했지긴 이러면 별 의미는 없게 되는 것이니 말이다.

결국 포기하고 vterm으로 다시 돌아갔다. CLI 창에서 여러 선택지 입력을 위해선 완벽한 터미널 구현이 필요하니 딱히 다른 답이 없는 것 같다. AI가 모르는 답을 찾아낼 능력이 있을 리도 없고 말이다.

자 그럼 이제 어떻게 할까? ai-code-interface.el와 agy를 이용해 문제 해결을 시켰건만 전혀 해결은 못 하고 원점으로 돌아와 버렸는데 말이다.

사실 지금까지 외면했던 간단한 답이 있긴 있다. Emacs 내장 한글 입력기는 포기하고 그냥 macOS 한글 입력기를 쓰면 된다. 한글 입력 도중 완성되지 않은 상태에선 다른 키 입력이 한 번 씹히는 귀찮은 문제가 있지만 뭐 쓸 수 없을 정도는 아니니 말이다.

마무리

결론: 굳이 이게 꼭 필요한지를 아직은 잘 모르겠다.

ai-code-interface.el을 이용해 agy를 쓰는 상황에서 한 가지 좋은 점이 있다면 바로 Emacs에 열려있는 버퍼와 상호작용이 약간은 가능하다는 점이다. 위에서의 예처럼 현재 버퍼 상황을 이용해 프롬프트를 던질 수 있으니 말이다. 그냥 외부 터미널에서 agy로 비슷한 일을 해야 했다면 필요한 모든 파일들을 몽땅 액세스 한다고 계속 물어오고 토큰은 토큰대로 소비했어야 했을 테니 말이다.

그 외에 ai-code-interface.el의 장점은 무엇이 있을까?

SPC c a만 눌러두고 하단 커맨드 팔레트를 잘 살펴보면 ai-code-interface.el의 여러 기능을 확인할 수 있다. 위 스샷만 봐도 정말 뭐가 뭔지 모를 정도로 많은 기능들이 있다.

하지만 뭔가 더 특별한 기능이 있는가는 아직은 잘 모르겠다. 오래 써본 것도 아니고 겉핥기 수준이라 모르는 건 당연하겠지만 그래도 바로 와닿는 기능이 없는 것도 사실이다. 사실 대부분의 기능들은 그저 프롬프트 입력으로 넘어가기 때문에 결국은 프롬프트 입력을 잘해야 한다는 점은 그대로다.

결국 제목의 내용에 답을 달자면... '굳이 Emacs 안에서 agy를 같이 쓰지 않아도 딱히 크게 불편할 것 같지는 않다' 정도가 될 것 같다. 물론 토큰을 조금이라도 아끼고 싶다면 조금은 유용할 가능성이 있을지도 모르겠지만 말이다.

어쩌면 더 써보다 나중에 유용한 기능을 발견할 수 있을지도 모르겠다. 그때는 따로 글을 또 써봐야겠다.