덜 대중적인 프로그래밍 언어를 위한 AI

Claude Code부터 Cursor, Codex에 이르기까지 AI 에이전트(AI agents)는 매우 인기가 높으며, 이들은 모두 TypeScript나 Python과 같이 가장 대중적인 프로그래밍 언어를 위한 코드를 작성할 수 있습니다. 하지만 덜 대중적인 프로그래밍 언어들은 AI 에이전트가 헛바퀴를 돌게 만들고 필요 이상의 토큰(tokens)을 소모하게 만드는 고유의 뉘앙스를 가지고 있습니다.

AI 에이전트 vs. Emacs Lisp

저는 OpenCode와 Junie를 사용하여 단 하나의 파일로 구성된 Emacs 플러그인을 작성할 때 이런 일을 겪었습니다. 저는 VS Code 외에도 때때로 집중력을 유지하는 코딩을 위해 텍스트 에디터로 Emacs를 사용하곤 하는데, Emacs와 다른 IDE(통합 개발 환경)의 강력한 기능 중 일부는 플러그인에 있습니다. Emacs를 위한 새로운 플러그인을 작성하거나 유용한 플러그인을 수정하려면 Emacs Lisp 프로그래밍 언어를 사용해야 합니다.

괄호의 균형 맞추기

TypeScript나 Python 같은 언어에서는 다음과 같이 변수를 할당하고 함수를 호출합니다:

test = 123
hello_world(test)

Emacs Lisp에서는 다음과 같이 합니다:

(let ((test 123))
  (hello-world test))

괄호가 변수 할당과 함수 호출을 감싸고 있는 것이 보이시나요? 이것이 바로 AI 에이전트들이 계속해서 걸려 넘어졌던 부분입니다. 제가 어떤 AI 모델을 사용하든 상관없이, 모두가 불균형한 괄호(unbalanced parenthesis) 및 기타 구문 오류(syntax errors) 문제를 겪었습니다. AGENTS.md 프롬프트의 일부로, 저는 내장 함수인 check-parens와 바이트 컴파일(byte compilation)을 사용하여 이를 확인하는 방법을 언급했습니다. 불행하게도, AI 에이전트들이 이 문제를 확인할 수는 있었지만, 파일의 정확히 어느 지점에 누락되거나 추가된 괄호가 있는지 찾아내기 위해 커스텀 스크립트를 돌리며 루프(loop)에 빠지고 토큰을 낭비했습니다. 이것은 단 하나의 파일로 된 플러그인에 대한 이야기임을 기억하세요. 파일이 더 많아지면 상황이 얼마나 악화될지 상상해 보시기 바랍니다.

OpenCode는 GLM 5.2를 사용하여 누락되거나 추가된 괄호가 파일 내 어디에 있는지 정확히 찾아내기 위한 커스텀 Emacs Lisp을 작성했습니다. 이 모델은 파일의 다양한 부분을 확인하기 위해 커스텀 코드를 다시 작성했습니다. 이 과정 하나하나가 도구 사용 (tool use)이며, 매우 많은 토큰 (tokens)을 소모했습니다. 다음 단계는 AI 에이전트가 작성한 이러한 커스텀 스크립트를 프로세스를 가속화하기 위한 도구 (tool)로 변환하거나, 프로세스를 가속화하기 위해 다른 도구들을 사용하는 방법을 보여주는 기술 (skill)로 만드는 것입니다.

패키지 및 의존성 (Packages and Dependencies)

또 다른 문제는 모델의 종류와 상관없이 AI 에이전트들이 커스텀 코드를 작성하는 것을 선호한다는 점입니다. Emacs 패키지 및 의존성 (dependencies)을 추가할 수 있다는 점을 지적했을 때, 플러그인 사용자에게 의존성을 설치해야 함을 알리고 폴백 (fallback)이 사용되고 있는지 알려주기 위해서는 프롬프트 (prompt)에 추가적인 내용이 필요했습니다.

이는 Emacs 패키지 저장소 소스를 조회하는 MCP 또는 도구 (tool)를 추가함으로써 도움을 받을 수 있습니다. 저는 직접 패키지를 검색한 뒤 프롬프트에 추가하는 방식으로 문제를 해결했습니다. 예를 들어, 저는 Emacs에서 터미널로 주로 ansi-term을 사용합니다. OpenCode AI 에이전트에게 터미널 렌더링을 수정해 달라고 요청했을 때, 에이전트는 eat이나 vterm과 같은 더 현대적인 터미널이 존재한다는 제안을 하는 대신 ansi-term을 구성하고 수정하려고 시도했습니다.

새롭고 활발하게 개발 중인 덜 대중적인 언어들의 경우, 해당 언어의 인기 패키지는 매달 바뀔 수 있습니다. AI 모델이 사용할 최신 패키지를 확인할 방법이 없다면, 코드는 작성되자마자 레거시 (legacy)가 되어 버립니다.

덜 대중적인 프로그래밍 언어를 위한 AI

이는 다시 우리가 어떻게 덜 대중적인 프로그래밍 언어를 위해 AI 에이전트를 최적화할 것인가라는 질문으로 돌아오게 합니다. 수십 년 동안 풍부한 코드 예제, 문서, 튜토리얼이 존재해 온 텍스트 에디터용 플러그인을 작성하는 데 AI 에이전트를 사용하는 것조차 문제에 부딪힌다면, 덜 대중적인 프로그래밍 언어들은 사용 가능하게 만들기 위해 훨씬 더 많은 노력이 필요할까요?

여기 몇 가지 아이디어가 있습니다:

• 프롬프트 (Prompt)에 더 많은 컨텍스트 (Context)를 담으세요.
• RAG (Retrieval Augmented Generation, 검색 증강 생성)를 사용하여 프롬프트에 관련 예시를 추가하세요.
• AI 에이전트가 매번 언어를 "다시 학습"하게 하는 대신, 린팅 (Linting), 포매팅 (Formatting), 컴파일 (Compilation) 속도를 높이기 위해 사용할 수 있는 도구들을 만드세요.
• 테스트 (Testing), 디버깅 (Debugging), 문서화 (Documenting)의 공통적인 패턴을 코드화한 스킬 (Skills)을 만드세요.
• 한 언어를 다른 언어로 매핑 (Map)하세요. AI 에이전트를 혼란스럽게 할 수 있는 구문 (Syntax)을 사용하는 대신, 다른 구문을 사용하여 이를 다른 언어로 매핑하고 변환할 수 있도록 하세요.