作った道具が全部つながった箱を、ストップウォッチと天秤で測っている

만든 도구들이 전부 연결된 상자를 스톱워치와 천칭으로 측정하고 있다

지난 기사에서, 직접 만든 AIShell을 사용하는 Codex와 일반 Codex에 동일한 과제를 주고 비교했더니, token이 25.86% 감소했다. 효과가 있을 것 같다고 생각했다. 다만, 3개 과제 9회 시행의 결과였기에 확신까지는 가질 수 없었다.

이번에는 기능을 늘리고, 벤치마크 (Benchmark) 규모도 크게 하여 다시 측정했다. 결과부터 말하자면, token은 52.44% 감소까지 도달했다. 지난번보다 향상되었으며, 예상 이상이었다.

편리해 보이는 도구를 전부 만들었다

기능을 늘리는 것에 대해 Claude에게 물어보았다. 나의 개발 환경을 바탕으로 어떤 도구가 있으면 편리할지. 여러 가지 제안이 돌아왔다.

Claude는 처음에 몇 개만 구현해서 경과를 지켜보는 안을 권했다. 나는 거의 취미로 하는 개인 개발자이고, 본업의 이면에서 AI를 돌리고 있을 뿐이기에, 개발한 결과에 따른 리스크를 고려할 필요가 없다. 전부 만들기로 했다.

현재 AIShell의 기능

지난 시점에 있었던 기능은 5개였다.

• 작업 폴더의 현재 상태와 지난번으로부터의 변경 사항을 정리해서 반환
• 여러 파일에서 필요한 양만큼 읽기
• 지정된 범위를 검색
• 빌드 (Build)나 테스트 (Test)를 실행하고 중요한 진단 (Diagnosis)을 반환
• 저장된 완전한 출력물로부터 필요한 범위를 읽기

이번에 늘어난 기능을 전부 나열한다.

• 변화를 기다리기: 파일의 변화나 빌드의 완료를 AIShell이 감지할 때까지 기다린다. 기다리는 동안 AI는 확인 명령어를 입력하지 않아도 된다.
• 백그라운드에서 실행하고 필요할 때 보기: 빌드나 테스트를 백그라운드에서 실행한 채로 AI는 다음 작업을 진행한다. 중간 경과와 결과는 필요할 때 가져온다.
• 실행 중인 처리 취소: 백그라운드에서 실행 중인 처리를 도중에 취소하여 남김없이 종료한다.
• 여러 파일을 한꺼번에 변경하기: 여러 파일의 변경을 한 번에 적용한다. 적용 전에 편집의 전제가 된 파일의 내용이 바뀌지 않았는지 확인하고, 바뀌어 있다면 중단한다.
• 변경 영향 범위 산출: 이 파일을 바꾸면 어떤 소스(Source)와 어떤 테스트에 영향이 가는지 반환한다. 빌드 의존성 기록으로부터도 영향을 추적할 수 있다. 추적할 수 없는 의존성은 알 수 없는 것으로 보고한다.
• 작업 폴더 기억의 영속화: AIShell을 재시작해도 이전 상태를 기억하고 있으며, 멈춰 있는 동안 발생한 변경 사항을 차분 (Diff)으로 반환한다.
• 브랜치 (Branch)와 Worktree 비교: 브랜치 간의 차이나 Worktree에서 일어나고 있는 변경을 정리해서 반환한다.
• Git의 세밀한 상태 파악: 스테이지 (Stage)된 상태와 스테이지되지 않은 상태가 섞인 상태나, 파일 이름의 변경을 변경의 맥락을 유지한 채 보고한다.
• 프로젝트 구성 기억: 이 프로젝트의 빌드 명령어와 테스트 명령어가 무엇인지 기억하여 반환한다. package.json과 같은 구성 파일이 바뀌면 다시 기억한다.
• 여러 검색의 일괄 실행: 여러 검색 질의를 한 번에 받아, 변경된 파일과 테스트를 우선하면서 정리해서 반환한다.
• 의미론적 검색: 문자의 일치를 넘어 함수나 변수의 연결을 따라가며 찾는다. 편집 직후에는 편집 전의 오래된 해석 결과를 오래된 것으로 취급한다.
• 진단 정형화: 빌드나 테스트가 내보내는 진단을 형식에 따라 정해진 구조로 정리하여 반환한다. 형식이 깨져 있다면 깨져 있다고 보고한다.
• 확인 결과 재사용: 동일한 확인을 반복할 때 입력이 바뀌지 않았다면 이전 결과를 사용한다. 입력이 바뀌었다면 다시 실행한다.
• 실행해야 할 테스트 제안: 변경 내용으로부터 지금 실행해야 할 테스트를 제안한다. 제안만 하고 멈출 수도 있고, 허가를 기다린 후 실행할 수도 있다.
• 과거 실행 결과 검색 및 비교: 저장된 여러 번의 실행 출력을 가로질러 검색한다. 2번의 실행을 비교하여 늘어난 경고와 사라진 경고를 출력한다.
• 복구용 조작: AIShell 자체의 상태 확인과 관리 앱을 여는 조작. 설정이 부족할 때나 관리 앱에서 AI의 조작을 멈추고 있는 동안에도 이 두 가지는 사용할 수 있다.

이 중 '변화를 기다리기', '백그라운드에서 실행하고 보기', '한꺼번에 변경하기', '영향 범위' 4개는 새로운 도구로서 추가했다. '복구용 조작'도 상태 확인과 관리 앱을 여는 2개의 도구가 되었다. 나머지 기능은 기존에 있던 5개의 도구 안에 넣었다. AI가 볼 수 있는 도구의 수는 5개에서 11개로 늘어났다.

각각이 실제로 얼마나 효과가 있었는지를 이후에 과제별로 살펴보겠다.

벤치마크를 32개 과제로 늘렸다

과제는 실제 개발에서 발생하는 상황을 바탕으로 32개를 만들었다. 빌드 완료를 기다리기, 여러 파일에 변경 사항 적용하기, 과거 실행 결과에서 원인 찾기 등의 내용으로 구성되었으며, 각각을 일반적인 Codex와 AIShell에 3회씩 전달했다. 성공 여부는 과제마다 정해진 조건에 따라 기계적으로 판정했다.

token은 52.44% 감소했다

전체 결과는 다음과 같다.

성공 1과제당 token은 실패한 시도에 사용된 분량을 포함한 합계를 3회 모두 성공한 과제의 수로 나눈 수치다. 지난번의 25.86% 감소보다 수치가 높아졌으며, 성공한 과제의 수도 늘어났다.

課題別のtoken削減率。プロジェクト構成の把握し直しと待つ場面で7割減、壊れた診断の判定では3割増

과제별 token 감소율. 프로젝트 구성 재파악 및 대기 상황에서 70% 감소, 깨진 진단 판정에서는 30% 증가

여기서부터 기능별로 무엇을 만들었는지, 어떤 과제에서 어떤 일이 일어났는지 살펴보겠다. 효과가 없었던 기능도 그대로 기술한다.

새로운 도구 4개의 결과

변화를 기다리기

일반적인 Codex는 기다리는 동안에도 확인 명령어를 계속 입력하기 때문에, 그 확인 과정이 모두 token과 시간 소모로 이어진다. AIShell은 변화가 일어났을 때 알려준다.

通常のCodexは確認コマンドを繰り返し、AIShellは1回頼んで知らせを待つ

일반적인 Codex는 확인 명령어를 반복하고, AIShell은 1회 요청 후 알림을 기다린다

32개 과제 중 가장 차이가 컸던 기능이었다. 외부 편집을 기다리는 과제에서 token이 75~78% 감소했고, 시간은 90% 이상 단축되었다. 변경 알림이 끊긴 것을 감지하여 재조사로 전환하는 과제에서도 68% 감소했다.

백그라운드에서 실행하고 필요할 때 확인하기

이 기능의 과제는 두 가지다. 실행 중인 빌드에서 첫 번째 실패 원인을 추출하고, 완료되면 종료 코드를 보고하는 과제와, 실행 중인 프로세스를 취소하여 남김없이 종료하는 과제다. 일반적인 Codex는 6회 모두 실패했다. AIShell은 6회 중 5회 성공했다. 효율성을 떠나, 셸(Shell)을 경유해서는 완수할 수 없었던 종류의 작업이었다.

여러 파일을 한꺼번에 변경하기

적용하기 전에, 편집의 전제가 된 파일의 내용이 바뀌지 않았는지 확인하고, 바뀌었다면 중단하는 메커니즘을 갖추고 있다.

과제는 3개였으며, 일반적인 Codex는 9회 중 5회 성공, AIShell은 9회 모두 성공했다. 두 모델 모두 성공한 과제와 비교했을 때, token은 33~40% 감소했다.

변경 영향 범위 파악하기

직접적인 의존성을 추적하는 과제는 일반적인 Codex가 3회 중 0회, AIShell이 3회 모두 성공했다. 빌드 의존성 기록으로부터 영향을 파악하는 과제도 1대 3의 비율로 AIShell이 우세했으며, token은 49% 감소했다.

AIShell이 실패한 과제도 여기에 있었다. 추적할 수 없는 의존성이 섞여 있을 때 "여기서부터는 알 수 없다"라고 보고하는 과제에서, 일반적인 Codex는 2회 성공했으나 AIShell은 3회 모두 실패했다. 알 수 없는 부분에 대한 보고 방식에 아직 허점이 있다.

기존 도구에 대한 확장 결과

작업 폴더의 기억 유지하기

AIShell을 재시작해도 이전 상태를 기억하고 있으며, 정지해 있는 동안 발생한 변경 사항을 차분(diff)으로 반환한다. 재시작 후 복구에서 token 44% 감소, 정지 중 편집 감지에서 32% 감소했다.

Git 상태 파악

브랜치 간 비교나 Worktree 비교 기능을 도구로 갖추었다. 파일명 변경이 포함된 상태의 파악에서 63% 감소, Worktree 변경 파악에서 51% 감소했다. 스테이징(Staged)된 상태와 스테이징되지 않은(Unstaged) 상태가 섞인 상황을 정확히 보고하는 과제는 일반적인 Codex가 3회 모두 실패했고, AIShell은 3회 모두 성공했다.

프로젝트 구성 파악

이 프로젝트의 빌드 명령어와 테스트 명령어가 무엇인지 기억하여 반환한다. package.json이 바뀌면 다시 기억한다. 구성 변경 후 재파악에서 77% 감소, 기억한 내용을 그대로 사용할 수 있는 상황에서 46% 감소했다.

검색 및 읽기

여러 검색 질의를 한꺼번에 실행하는 과제에서 54% 감소했다. 함수나 변수의 연결 고리를 따라 찾는 검색은, 편집 직후에 오래된 분석 결과를 그대로 내놓지 않도록 하는 것까지 과제로 포함했는데, 일반적인 Codex는 6회 중 0회, AIShell은 5회 성공했다.

여기에도 실패는 있다. 정해진 양에 들어오는 만큼만 읽고 나머지는 이어서 반환하는 과제는 둘 다 3회 모두 실패했다.

빌드 및 테스트 실행 관련

실행 결과 진단을 정해진 형식으로 정리하는 과제는 성공 횟수가 1대 2였으며, token은 42% 적게 사용했다. 변경 사항에 대해 실행해야 할 테스트를 제안하고, 허가를 기다린 후 실행하는 과제는 일반적인 Codex가 6회 중 0회, AIShell이 5회 성공했다.

효과가 없었던 과제들도 여기에 모여 있다. 의도적으로 형식을 망가뜨린 진단 데이터를 망가진 것으로 판정하게 하는 과제에서는, 일반적인 Codex보다 30% 더 많은 토큰 (token)을 사용했다. 동일한 확인을 반복할 때 이전 결과를 재사용하는 기능은 토큰 (token) 차이가 거의 나지 않았다. 이미 수중에 있는 정보를 다루는 장면에서는, AIShell을 경유함에 따른 추가 비용이 남는다.

과거 실행 결과의 검색

AIShell은 실행의 완전한 출력을 저장하고 있다. 여러 번의 실행을 가로질러 에러를 검색하는 과제에서 48% 감소, 2번의 실행 결과를 비교하여 늘어난 경고와 사라진 경고를 출력하는 과제에서 46% 감소했다. 일반적인 Codex는 다시 실행하여 출력을 새로 만드는 것부터 시작하기 때문에 이러한 차이가 발생한다.

지난 질문의 이어짐

지난 기사는 "AI라면 셸 (shell)도 터미널 (terminal)도 필요 없지 않을까?"라는 의문에서 시작했다.

이번 결과에서는 셸 (shell)을 통하지 않는 접속 방식이 토큰 (token)과 시간 모두 적게 소요되었고, 성공한 과제도 더 많았다. 적어도 이 벤치마크 (benchmark) 범위 내에서는, AI는 셸 (shell)을 사용하지 않는 편이 더 좋은 결과를 내고 있다.

다음으로는 평소의 개발 과정에서 동일한 효과가 나타나는지 확인해 나갈 것이다.

Discussion