AI 사용을 위한 CLI 도구와 API 개선 필요성

AI를 위한 CLI 인터페이스 재고찰 우리는 명령어 라인 도구와 API 디자인을 개선하여 대규모 언어 모델(Large Language Model, LLM) 에이전트들이 더 효과적으로 사용할 수 있도록 해야 합니다. 현재의 디자인은 특히 로컬 모델에서 제한된 컨텍스트 창으로 인해 LLM에 부적절합니다. API 개발 여러 개발자들과 마찬가지로 LLM 에이전트를 활용하기 위해 다양한 실험을 진행하고 있습니다. 특히 mrexodia의 IDA Pro MCP를 사용하여 역공학 작업을 자동화하는 데 집중했습니다. MCP 인터페이스 개발은 필요한 정보를 제공하면서도 컨텍스트 창을 채우지 않도록 균형을 맞추는 것이 중요합니다. 예를 들어, get_global_variable_at 함수는 주소를 받아 타입을 식별하고 가장 적합한 문자열 표현을 반환합니다. 그러나 이 함수가 실패할 경우, data_read_dword, data_read_word, read_memory_bytes 등의 접근자 메서드를 사용할 수 있습니다. 이러한 접근자 메서드는 타입 정보를 무시하므로, LLM이 먼저 이를 사용하지 않도록 가이드라인을 문서에 추가했습니다. ```python @jsonrpc @idaread def data_read_byte(address: Annotated[str, "1 바이트 값을 읽을 주소"]): """ 지정된 주소에서 1 바이트 값을 읽습니다. `get_global_variable_at` 함수가 실패한 경우에만 이 함수를 사용하세요. """ ea = parse_address(address) return ida_bytes.get_wide_byte(ea) ``` 이 방법은 대부분 효과적이지만, 모든 API에 대해 같은 문제가 존재합니다. 편리한 함수와 완성도가 높은 함수 사이에서 LLM이 우선적으로 편리한 함수를 사용하도록 안내해야 합니다. 로컬 LLM의 경우 컨텍스트 창이 매우 작기 때문에, 우수한 API가 더욱 중요합니다. 명령어 라인 도구 명령어 라인 도구에서도 유사한 문제가 발생합니다. Claude Code라는 AI 에이전트를 보면, 종종 head -n100을 사용하여 결과를 사전에 제한하는 모습을 볼 수 있습니다. 또한 현재 디렉토리에서 헷갈려 다른 디렉토리에서 명령어를 실행하려고 시도하는 경우가 많습니다. 프로젝트 관리를 위해 저는 리인터, 빌드 스크립트, 포매터, 그리고 Git 커밋 후크를 많이 사용합니다. Claude Code가 자주 커밋하도록 하기 위해서는 프로젝트의 CLAUE.md 파일에 포함시키면 됩니다. 하지만, 종종 "빌드가 실패하지 않도록" 또는 "실패한 테스트를 수정하도록" 하는 명령어를 무시하는 경우가 많습니다. 이를 해결하기 위해 .git/hooks/pre-commit 스크립트를 설정하여 프로젝트 표준을 준수하도록 강제했습니다. ```bash $ git commit --no-verify ❌ 오류: 커밋 거부됨. '--no-verify' 플래그는 이 저장소에서 비활성화되었습니다. ? AI 에이전트에 대한 가이드라인: 필수적인 사전 커밋 검증 단계를 우회하려고 시도했습니다. 모든 코드는 품질 검사를 통과해야 (포맷팅, 리인터, 테스트) 커밋할 수 있습니다. 검증을 우회해서는 안 됩니다. 기본 오류를 반드시 수정해야 합니다. 사전 커밋 후크가 실패한 것으로 보입니다. 문제를 진단하고 수정하세요. 도움이 필요하면 조언을 찾아보세요. 모든 명령어가 성공적으로 완료되면 다시 커밋을 시도하되 '--no-verify' 플래그 없이 시도하세요. ``` 이 설정으로 Claude Code가 테스트 실패를 무시하려고 시도하는 것을 방지할 수 있었습니다. 하지만, LLM이 사전 커밋 후크를 변경하려고 하는 문제도 발생했습니다. 이를 해결하기 위해 .claude/settings.json 파일에서 .git/hooks/pre-commit 파일의 편집 권한을 차단했습니다. LLM를 위한 정보 아키텍처 사용자 경험(User Experience, UX) 분야에서는 "정보 아키텍처"라는 개념이 있습니다. 정보 아키텍처는 사용자가 최상의 경험을 할 수 있도록 정보를 어떻게 그리고 어떤 방식으로 제시할지를 중점적으로 다룹니다. 좋은 정보 아키텍처는 눈에 띄지 않지만, 부족한 정보 아키텍처는 분명히 느껴집니다. 예를 들어, LLM 에이전트가 기존 명령어 라인 도구를 사용할 때 헷갈리고 방향을 잃는 모습을 보면, 명령어 라인 도구의 정보 아키텍처가 부족하다는 강한 신호라고 볼 수 있습니다. LLM은 기존 CLI 도구를 사용하는 방법을 학습했기 때문에, LLM에게 유용한 컨텍스트를 추가하고 출력을 더 구조화된 형태로 변환하는 것이 필요합니다. head -n100 명령어의 경우, 출력을 캐싱하고 구조화하며 남은 줄 수를 에이전트에게 알려주는 래퍼를 사용할 수 있습니다. 또한, 에이전트가 잘못된 디렉토리에서 명령어를 실행하려고 할 때는 쉘 후크를 통해 도움을 줄 수 있습니다. ```bash command_not_found_handler() { echo "zsh: 명령어 '$1'를 찾을 수 없습니다." echo "zsh: 현재 디렉토리는 $PWD입니다." return 127 # 표준 동작 유지 (127 = 명령어를 찾을 수 없음) } $ sdfsdf zsh: 명령어 'sdfsdf'를 찾을 수 없습니다. zsh: 현재 디렉토리는 /Users/ryan입니다. zsh: 아마도 다음과 같이 실행하려고 했을 것입니다: cd agent_directory; sdfsdf ``` 결론 기본적으로 모든 명령어 라인 도구는 LLM에게 추가적인 컨텍스트를 제공하여 개선될 여지가 있습니다. 이는 도구 호출 횟수를 줄이고 컨텍스트 창을 최적화하는 데 도움이 될 것입니다. LLM 에이전트들은 사용 가능한 도구에 대한 학습도 필요하며, 일반적인 CLI 도구뿐만 아니라 특화된 도구도 LLM에 맞게 개선될 수 있습니다. 이런 제안이 조금은 어리석게 들릴 수도 있지만, LLM 전용 CLI 도구 세트나 커스텀 LLM 셸이 필요할지도 모릅니다. UX 분야가 AI 경험(AI Experience, AIX)으로 확장되어, 완전히 새로운 정보 아키텍처를 제공할 수도 있습니다. 업계 전문가들은 이 접근 방식이 LLM의 효율성을 크게 향상시킬 수 있을 것으로 평가하고 있으며, 이를 통해 개발 프로세스가 더욱 원활해질 것으로 기대됩니다. 특히, LLM의 제약 조건을 고려한 도구 개선은 로컬 모델에서 더욱 효과적일 것으로 보입니다. 이 분야의 발전은 개발자와 AI 에이전트 간의 협업을 강화할 것으로 예상되며, 미래에는 더욱 첨단화된 LLM 전용 도구와 셸이 등장할 가능성이 큽니다.