AI 코딩 도구 두 개를 같은 자동화에 붙일 때, 공용 본체와 도구별 러너를 나누는 이유
처음 배선이 어긋난 이유는 코덱스가 클로드 설정에 매달려 있었기 때문이다
클로드코드에 맞춰 둔 자동화에 코덱스를 두 번째 도구로 연결했다. 처음에는 코덱스가 클로드코드 설정 폴더의 파일을 빌려 쓰게 했다. 둘이 같은 일을 처리하므로 빠르게 붙일 수는 있었지만, 구조는 대등하지 않았다. 코덱스가 독립된 도구가 아니라 클로드코드 설정에 기대어 움직이는 모양이 됐다.
여기서 말하는 표면은 같은 자동화를 쓰는 각 AI 코딩 도구의 설정과 실행 접점이다. 공용 본체는 두 도구가 함께 쓰는 실제 동작이고, 러너는 그 본체를 각 도구의 실행 방식에 맞게 부르는 얇은 설정 또는 실행 파일이다.
내가 다시 세운 기준은 아래와 같다.
| 구분 | 두면 안 되는 곳 | 두어야 하는 곳 |
|---|---|---|
| 공용 동작 | 특정 도구의 설정 폴더 | 도구 중립 위치 |
| 도구별 설정 | 다른 도구의 파일을 직접 빌려 쓰는 구조 | 각 도구의 러너 |
| 공통 문서 | 두 도구 폴더에 복제한 사본 | 원본 하나와 참조 한 줄 |
공용 문서를 복제하지 않은 이유도 같다. 같은 문서를 두 파일에 복제하면, 수정 뒤 어느 파일이 최신인지 다시 관리해야 한다. 그래서 원본은 하나만 두고 다른 쪽에서는 그 원본을 참조하게 했다.
이 구조가 맞는지 볼 때는 질문 하나면 충분했다. 세 번째 도구가 들어와도 공용 본체는 건드리지 않고 러너만 더하면 되는가. 아직 세 번째 도구를 실제로 연결하지 않았으므로, 이 질문은 검증 결과가 아니라 구조를 점검하는 기준이다.
공용 본체를 나눠도 도구별 실행 조건은 따로 확인해야 한다
파일을 어디에 둘지 정한 뒤에도, 훅과 세션이 같은 방식으로 움직인다고 볼 수는 없었다. 코덱스에서 실제로 확인한 조건은 세 가지였다.
| 확인한 조건 | 실제로 본 현상 | 그래서 바꾼 판단 |
|---|---|---|
| 훅 신뢰 승인 | 설정에 등록해도 승인 전에는 오류 없이 실행되지 않았다. 명령 훅마다 현재 파일 해시를 신뢰해야 했고, 파일을 고치면 다시 승인해야 했다. | 훅 등록만으로 작동을 판단하지 않고, 새 세션에서 실제 실행 여부를 확인한다. |
| 세션 시작 주입 | 약 10KB에서 잘렸다. 47.8KB를 넣었을 때 카탈로그 파일은 빠지고 나머지는 임시 파일로 밀려났다. | 세션에 넣을 정보는 작게 유지하고, 긴 내용은 다른 경로로 넘긴다. |
| 세션 종료 이벤트 | 대화를 보관·삭제하거나 30분 방치했을 때만 발생했다. | 수확 시점을 세션 종료가 아니라 세션 시작으로 옮겼다. |
훅은 새 세션부터 적용됐다. 이미 열려 있던 대화에는 바뀐 훅이 소급되지 않았다. 반대로 세션을 열자마자 닫으면 기록 파일 자체가 만들어지지 않아 검증할 수도 없었다. 설정 파일을 저장한 사실과 자동화가 실제로 움직인 사실은 다른 문제였다.
같은 이름의 폴더가 서로 다른 일을 하는 경우도 있었다. 두 도구 모두 rules 폴더를 가졌지만, 한쪽은 에이전트가 읽는 행동 규칙 문서 폴더였고 다른 쪽은 셸 명령을 allow, prompt, forbidden으로 나누는 권한 정책 폴더였다.
| 이름은 같았던 폴더 | 한 도구에서의 역할 | 다른 도구에서의 역할 |
|---|---|---|
rules | 에이전트 행동 규칙 문서 | 셸 명령 권한 정책 |
전역 지침을 읽는 방식도 달랐다. 한쪽은 전역 지침 파일과 규칙 폴더의 직속 파일을 계속 읽었고, 다른 쪽은 지침 파일 하나만 자동으로 읽었다. 후자의 지침 파일은 필요한 규칙을 찾아 읽도록 안내하는 역할이었다. 공용 본체를 분리하더라도, 러너를 만들기 전에는 각 도구의 실행 조건을 따로 확인해야 하는 이유다.
대화 기록과 큐는 처리 전에 출처와 크기를 정리해야 한다
실행 파일의 경계만 나눠서는 충분하지 않았다. 자동화로 들어오는 기록이 어느 표면에서 왔는지, 그대로 읽을 수 있는 크기인지도 먼저 정해야 했다.
대화 기록에는 이미지가 base64로 들어갈 수 있다. base64는 이미지 같은 이진 데이터를 텍스트로 기록하는 방식이다. 실제 기록 한 건은 511줄이었지만, 이미지 데이터 때문에 파일 크기가 118MB였다. 사람의 발화와 답변만 추출하는 리더를 거치자 21KB가 됐다.
| 처리 대상 | 원본 상태 | 처리 기준 |
|---|---|---|
| 대화 기록 | 511줄, 118MB. 이미지 base64가 한 줄에 포함될 수 있다. | 사람 발화와 답변만 추출해 자동화에 넘긴다. |
| 큐 레코드 | 14줄 중 9줄에 표면 이름이 없었다. 그중 하나는 자동화 실행 로그였다. | 판단하기 전에 출처 필드를 정규화한다. |
큐의 경우에는 출처를 모른 채 내용을 처리하면, 자동화가 남긴 실행 로그가 사람의 작업 기록처럼 지식에 들어갈 수 있었다. 그래서 내용의 가치를 판단하기 전에 먼저 출처를 정리했다.
리포 안에서만 찾으면 놓치는 경계도 있었다. 스크립트를 옮기면서 옛 경로를 지웠지만, 리포 밖의 크론이 그 삭제된 경로를 계속 호출하고 있었다. 또 코덱스 데스크톱은 대화마다 날짜와 대화 식별자로 된 임시 폴더를 만들었다. 이 폴더명이 프로젝트 이름 자리에 들어가 잡담 한 건이 가짜 프로젝트를 만들 뻔한 사례가 세 번 있었다.
이 사례들이 말하는 것은 단순하다. 공용 본체와 러너를 나누는 일은 실행 경계를 정하는 일이고, 기록의 출처와 크기를 정리하는 일은 입력 경계를 정하는 일이다. 둘 중 하나만 정리해도 자동화는 다시 잘못된 대상을 처리할 수 있다.
아직 확인하지 못한 것은 확장성과 장기 마찰이다
재편 뒤에는 코덱스 세션이 정상적으로 처리되는 것까지 확인했다. 배선 대상인 코덱스에게 교차 검토를 시켰고, 그 과정에서 훅 신뢰 승인이 빠진 것도 발견했다.
다만 아래 두 가지는 아직 확인하지 못했다.
- 세 번째 AI 코딩 도구를 실제로 연결했을 때, 공용 본체는 건드리지 않고 러너만 추가하면 되는지
- 훅 파일을 고칠 때마다 필요한 신뢰 재승인이 오래 운영할수록 얼마나 큰 마찰이 되는지
여러 AI 코딩 도구를 같은 자동화에 붙일 때 설정 파일을 한곳에 모으는 것만으로는 부족했다. 공용 동작은 도구 중립 위치에 두고, 각 도구에는 러너를 남긴다. 그 뒤에 훅 승인, 세션 주입 한도, 이벤트 조건, 기록 출처처럼 도구마다 다른 조건을 실제로 확인해야 한다.