Antigravity CLI를 이용해 sr-hanspell-mode를 작업하던 과정의 이야기들
앞서 올린 글을 통해 개인적인 욕구(?)로 인해 sr-hanspell-mode 개발을 Antigravity CLI(이하 agy)를 채찍질해서(?) 하기로 하면서 어떤 과정으로 일을 처리하면 좋을까 좀 고민했던 게 있다. 이 글은 그 결과로써 어떤 식으로 작업을 진행했는지 간략히 기록으로 남겨본 내용이다.
어떤 식으로 일을 진행하면 좋을까?
처음에는 좀 막막했다. 원래 소프트웨어를 하나 개발하려면 요구사항이 정리되고 청사진 같은 걸 먼저 만들면서 UI 설계도도 나오고 그다음 실제 개발이 진행되어야 할 거다. 이후에는 개발팀에서 일을 잘게 나눠서 각각 처리하고 요구사항과 싸우고 개발한 게 합치면서 결과물이 점점 산으로 가거나 바다에 빠지거나 하는 경우가 많지만 어쨌든 이렇게 일이 진행이 된다.
그렇다면 AI 에이전트에게 일을 시킬 때는 어떻게 하면 좋을까? 비슷하게 모든 기능 요구사항과 간략한 UI 설계를 문서화해서 이대로 처리해 달라고 하는 게 좋을까?
천천히 생각해 보니 이렇게 하면 운이 좋으면 한 방에 개발이 될 가능성이 없지는 않았다. 하지만 스펙 문서의 내용에 주관적인 성향이 있다면 과연 결과물이 내가 생각하는 대로 나와줄지는 솔직히 회의적이다. 사람들끼리 한참 회의를 하면서 해도 의도 이해가 달라지면서 산으로 가는데 말이다. 아니 이건 여럿이 해서 그런가? 어쨌든 무엇보다 문서를 만드는 데 시간을 너무 많이 뺏길 것 같다.
그래서 차라리 이런 설계 문서 없이 말로써 일을 쪼개서 바로 시켜보기로 했다. 개인 프로젝트를 진행할 때처럼 머릿속에 있는 것을 최대한 잘게 나눠서 순서대로 일을 처리하는 방식이다. AI 에이전트를 관련 지식이 없는 한 사람으로서 대우(채찍질)를 한다는 말이다.
"일을 (찰싹!) 해라 (찰싹!) 일을 (찰싹!) 제대로 (찰싹!) 해라 (찰싹!) 잘했어! (찰싹!)"
아주 어릴 때 봤던 어떤 만화에서 노예를 부리던 장면이 연상된다. 그렇게 옆에 붙어서 일을 잘할 때까지 때리면 되겠지?
실제 작업의 흐름
프로젝트 준비
아직 agy를 때릴 때는 아니다. 아는 게 없으니 일단 가장 기초적인 지식이라도 알아둬야 할 것 같아서 말이다. 그래야 채찍도 더 잘 때릴 수 있을 테니 말이다.
그래서 우선 Gemini에게 Emacs 확장 개발을 어떻게 시작하면 좋냐고 물어봤다. 그리고 얻어낸 답과 비슷한 구조로 프로젝트 디렉터리를 준비했다.
이후 터미널을 열고 프로젝트 디렉터리로 이동해서 agy를 띄웠다.
근데 기껏 ai-code-interface.el를 세팅해 놓고 왜 굳이 다른 터미널에 agy를 띄웠을까?
이유는 단순한데, 콘텍스트를 가급적 깔끔하게 유지하고 싶어서다. Emacs는 개발 도중에 재시동할 가능성이 충분히 있는데 이러면 이전에 나눴던 대화를 찾아보기 위해 추가 작업이 필요할 텐데 이게 좀 귀찮고 지저분해질 것 같기도 해서다. 사실은 그냥 취향이지만 말이다.
어쨌든 이제 실제로 agy를 채찍질할 단계다.
목적의 소개
우선은 agy에게 뭘 만들지 목적을 먼저 소개했지만 당장 만들라고 하지 않고 빈 모드부터 만들어보자고 했다.
바로 시작하지 않고 목적부터 이야기했던 이유는 간단하다. 에이전트에게 현재 채팅의 콘텍스트를 확실하게 해 주려는 것이었다. 이러면 아마 이 프로젝트에서 벗어나는 일을 하지는 않을 것이다.
어쨌든 agy는 약간 진도를 더 나가려고 하길래 채찍으로 때려주면서 시키는 대로 해달라고 했다. 멋대로 진도를 나가버리면 커밋 메시지 작성이 너무 어려워지니 말이다.
시작점의 생성
이제 agy에게 트리거 함수를 하나 만들어서 이걸 실행시키면 Emacs 상에서 팝업 윈도우를 띄우고 여기에 만들었던 모드를 적용하는 코드를 작성해 달라고 했다.
에이전트는 알아서 언급하지도 않았던 버퍼를 생성해서 앞서 생성한 메이저 모드를 적용시키는 코드를 만들어 줬다. 딱히 어렵게 모든 것을 설명할 필요는 없었던 모양이다. 상대적으로 관련 지식이 부족했던 내 자신이 약간 초라해졌다.
어쨌든 이 채찍은 굉장히 좋은 채찍인 것 같다. 적당히 찰지게 아픈 모양이다.
실제 작업의 시작
이제 hanspell-cli를 이용해 원본 버퍼 내용을 체크한 결과를 새로 띄운 버퍼에 표시하도록 수정해 달라고 했다.
agy는 의도대로 정말 잘 코딩해 주었다.
이제 여기까지면 본격적인 시작점이 세팅된 것 같았다. 요구사항을 간략히 정리했을 때의 모양이 만들어졌으니 말이다.
본격적인 다듬기
기본 골격 구조가 완성되었으니 이제 다듬기를 시작했다. 대충 다음과 같은 식으로 일을 나눠서 요청했다:
- 메이저모드를 읽기전용 모드로 바꿔줘.
- q 키를 누르면 팝업이 닫히게 해 줘: 이후 오류로 수 차례 트러블슈팅
- hanspell-cli 결과가 너무 복잡하니 필터 기능을 붙여서 좀 더 간략화해줘.
- 각 제안 내용을 내비게이션 할 수 있게 구현해 줘.
- 네비게이션 때 제안 내역의 원본 내용을 원본 버퍼에서 검색해 줘.
- a 키를 누르면 선택된 제안을 반영해 줘: 여기서 AI가 알아서 모두 반영되면 제안 내역에서 사라지게 멋대로 구현해 줌
이렇게 조금씩 진도를 나가다 보니 거의 원하던 기능이 완성이 되어있었다.
참고로 위의 마지막 항목에서 프롬프트를 입력하다 엔터키가 잘못 눌려서 내용이 끊겼는데도 agy가 찰떡같이 의도를 알아채는 모습은 정말 신기했다.
만약 중간에 이 의도 파악이 제대로 안 되었다면 일이 좀 꼬이거나 산으로 갔을 가능성도 없지는 않았다. 결과적으로 다행스러운 일이었다. 이것이 바로 찰진 채찍질의 힘인가.
마무리 트러블슈팅
이후 약간의 문제들이 있긴 했다. 에이전트가 만들어준 코드를 시험해 보면 자꾸 읽기전용 버퍼를 수정하려 한다는 Emacs의 경고가 뜬다며 이를 해결해 달라고 했다. 이 과정에서 agy는 원본 버퍼를 수정하는 게 아니라 메이저모드가 적용된 버퍼 내용을 수정하려 했다거나 혹은 evil 때문에 버퍼 내용 수정이 안 된다거나 혹은 버퍼가 text-mode를 상속받은 상태로 readonly로 만들어서 이상해졌다거나 등등 꽤 많은 채찍질을 당했다.
이런 여러 과정을 거쳤지만 완벽하게 문제가 해결되진 않았는데, 고백하자면 사실 AI는 나보다는 완벽했다. 그저 Emacs를 껐다 켜서 완전히 깔끔하게 만들자 문제가 해결되기 시작했기 때문이다. 그러니까 개발 도중에 생긴 찌꺼기들이 메모리에 남아 문제를 일으키고 있었던 것이었다.
결과적으로 Emacs를 껐다 켠 것 만으로 모든 문제가 잘 해결되었다. 어쨌든 이 직접적인 테스트 과정은 AI 에이전트가 직접 하질 않았기에 한계일 수 있지만 불평불만만 듣고도 원인을 어떻게든 찾아서 처리하는 모습을 보니 AI 에이전트가 대부분의 작업을 점령하는 시대도 조만간 올 지도 모르겠다.
그리고
일 처리를 잘게 나눈 이유 중 하나로 바로 커밋 타이밍을 만들기 위한 의도도 있었다. 즉 각 과정 중간중간 git을 이용해 직접 커밋을 처리했다는 말이다.
물론 커밋도 AI 에이전트가 할 순 있다. 하지만 여기서 사람은 관리자적인 존재로 직접 일 처리 과정을 보고 평가를 하고 페이스를 관리함과 동시에 토큰도 아끼겠다는 성스러운 일을 수행해야 한다. 왜인지 나보다 AI 에이전트 몸값이 더 비싸다고 가정해야 해서 좀 슬프기도 했지만 사실이니 어쩔 수 없다. 하지만 채찍은 나에게 있다! 하하하!
최종적으로 github에 push 한 뒤 README 메시지는 직접 작성했다. 이것도 맡길 걸 그랬나 싶었다. 너무 귀찮았으니 말이다. 그래서 문서에는 게으르고 귀찮다는 단어가 남발되었다. 뭐 이것도 특색이라면 특색이 될 수도 있긴 할 거다.
여담
만약 일 처리를 잘게 나누지 않고 대놓고 첫 프롬프트에서 목적과 동작 방식 등을 모조리 설명한 뒤 일을 맡겼다면 어떻게 되었을까? 개인적으론 실패와 동시에 큰 토큰 낭비가 있지 않았을까 추측된다. 진도를 조각조각 내서 조금씩 접근하는 데도 시행착오가 좀 있었으니 말이다. 아주 상세하고 완벽하게 서술하지 않는 이상 AI 에이전트가 의도대로 일을 해주는 건 아마도 힘들었을 것이다.
어디까지나 추측이지만 말이다.
하여간 AI 에이전트를 마치 사람처럼 다루며 일을 하나하나 나눠서 시키고 중간중간 확인하면서 의도에 맞게 수정도 요구도 했다. 정말 사람들끼리 일을 하고 있는 느낌으로 말이다. AI가 사람의 뇌신경 구조를 참조한 신경망을 이용해서 동작하는 이상 사람처럼 다루는 게 효율이 좋지 않을까 하는 생각도 있었다. 설마 잘 때리면 특정 사람처럼 좋아ㅎ... 이건 넘어가자.
어쨌든 그래서 결과물도 괜찮게 잘 나왔다고 생각한다.
이렇게 조금씩 진행했던 방식은 큰 장점이 있다. 바로 커밋 메시지를 풍부하게 만들 수 있어서 나 일 많이 하고 있다고 자랑할 수 있다는 점이다. 그리고 채찍을 많이 휘두를 수 있는 것도 취향에 따라 장점...인가?
