AI를 세 개 돌려봤는데, 남은 건 제일 똑똑한 것이 아니었습니다
지난 글은 2월 25일에 폴더를 정리하고 끝났습니다. 열여드레 동안 일곱 번 방법을 바꾸고도 마지막 한 칸을 못 넘긴 이야기였습니다. 그 뒤 석 달 동안 저는 도구를 세 번 바꿨습니다. 정확히는 두 번 갈아탔고, 한 번은 십 분 만에 접었습니다.
이번에 그 석 달의 기록을 다시 열어보니, 제가 기억하던 "성능 좋은 걸로 갈아탔다"는 말이 틀려 있었습니다. 마지막에 남은 기준은 성능이 아니었습니다.
3월 4일, 한 시간 만에 옮겼습니다
폴더 정리 일주일 뒤, 커뮤니티에서 배포하는 작은 도구를 받았습니다. 코딩용 AI 에이전트를 메신저에 연결해 주는 것이었는데, 압축을 풀고 봇 토큰을 넣으니 점심 전에 첫 대화 스레드가 생겼습니다. 기록상 11시 51분입니다.
전 도구와 다른 점은 하나였습니다. 답이 아니라 행동이 돌아왔습니다. 파일을 읽고, 고치고, 결과를 보고했습니다. 열여드레 동안 안 되던 "마지막 한 칸"이 어떻게 됐는지는 뒤에 나옵니다. 일단 그날은 옮기는 데 한 시간이 안 걸렸다는 것만 적어 둡니다.
닷새 뒤, 십 분짜리 시도
3월 9일 저녁 6시 56분에 이전 도구의 작업 폴더를 통째로 압축했습니다. 백업 파일 이름에 그 시각이 박혀 있습니다. 그리고 7시 1분에 다른 회사의 코딩 에이전트를 설치했습니다.
설치 폴더에 남은 대화 기록은 한 건입니다. 제가 보낸 말은 "hello" 한 마디. 7시 10분에 마지막 파일이 저장됐고, 그 폴더는 오늘까지 한 번도 다시 열리지 않았습니다. 십 분입니다. 같은 날 그 에이전트용 메신저 연결 도구도 내려받았는데, 압축을 푼 흔적만 있고 봇은 만들지 않았습니다.
왜 십 분 만에 접었는지는 기록이 없습니다. 기억으로 메우자면, 첫 도구가 이미 돌고 있는데 두 번째를 같은 자리에 세울 이유를 못 찾았던 것 같습니다. 그때는 "비교"라는 생각 자체가 없었습니다.
봄 내내 둘을 같이 썼습니다
접은 건 세 번째 후보였고, 실제로는 봄 내내 두 개를 같이 썼습니다. 새로 온 코딩 에이전트와, 그 전부터 쓰던 대화형 AI입니다.
역할이 자연스럽게 갈렸습니다. 대화형 쪽은 3월 7일부터 매일 아침 제 메일로 전날의 통화와 메시지를 정리해 보내는 일을 맡았습니다. 이건 지금도 같은 엔진으로 돌고 있습니다. 코딩 에이전트 쪽은 서류를 데이터로 바꾸는 일, 표를 분석하는 일, 그리고 3월 22일 기록에 이렇게 적혀 있습니다 — "기획과 구조 설계는 이쪽을 선호. 데이터 분석과 기초 작업은 이쪽이 우수."
4월 22일에 제가 커뮤니티에 남긴 말이 있습니다. "이쪽만 쓰고 있었는데 저쪽도 고민해 봐야 할 정도로 잘 뽑네요." 엿새 뒤에는 이렇게 썼습니다. "비교해서 돌려 보면 같은 프롬프트여도 나랑 잘 맞는 게 나와요." 성능표를 본 게 아니라 같은 일을 시켜 보고 고른 겁니다. 그 방식은 지금도 안 바뀌었습니다.
4월 12일, 남의 도구 위에 내 것을 얹었습니다
받은 도구를 그대로 쓰는 데는 한 달을 못 갔습니다. 4월 12일에 제 폴더를 새로 팠습니다. 설치 스크립트, 상태 점검 스크립트, 켜고 끄는 조작판. 그리고 나흘 뒤에 2월의 실패한 폴더에서 살릴 것만 골라 옮겼습니다. 판매 채널 스크립트 아홉 개와 업무 지식. 성격 파일과 영혼 파일은 안 가져왔습니다.
이 시점부터 "도구"라는 말이 조금 달라졌습니다. 엔진은 남의 것인데 그 위에 쌓이는 지침 파일과 스크립트는 제 것이었습니다. 이게 뒤에 결정을 가르게 됩니다.
6월 초, 진짜 병행
5월 중순에 커뮤니티 도구가 큰 업데이트를 했습니다. 두 회사의 에이전트를 봇 하나씩에 붙여 동시에 돌릴 수 있게 됐고, 리눅스 호환 계층 위에서 돌아갔습니다. 저는 5월 29일에 "이쪽을 메인으로 쓴다"고 써 놓고도 그걸 받았습니다. 궁금했던 것 같습니다.
6월 1일 밤 설치가 실패했습니다. 종료 코드 125. 저는 그 설치 폴더를 이미 쓰고 있던 코딩 에이전트에 물려서 "왜 안 되는지 찾아 달라"고 했고, 원인 보고를 커뮤니티에 올린 뒤 잤습니다. 다음 날 설치가 됐습니다. 봇 두 개를 만들어 하나에는 이쪽 엔진, 하나에는 저쪽 엔진을 붙였습니다. 6월 2일 기록에 두 봇의 첫 스레드가 나란히 있습니다.
그 뒤 닷새는 이렇습니다. 6월 3일 업데이트가 연결 오류를 내서 이전 버전으로 되돌림, 호환 계층 안의 로그인 세션이 자꾸 풀림. 6월 4일 응답 지연으로 원격 점검. 같은 날 커뮤니티에 예순 개 작업으로 잰 엔진 벤치마크 표가 올라왔습니다. 저는 그 표를 봤지만 결정에는 안 썼습니다.
6월 5일에 제가 남긴 말이 이렇습니다.
프롬프트가 절반인 것 같아요. 나한테 필요한 md 파일을 구축하는 데 시간이 제일 많이 소비됩니다. 유튜브에서 떠드는 것처럼 자동으로 되는 건 없더라고요.
열흘 만에 하나로
6월 10일, 봇 하나가 제 폴더 쪽으로 옮겨 왔습니다. 커뮤니티 도구 아래에 있던 봇 번호가 그날부터 제 저장소 아래에서 첫 작업(매일 리포트 유지)을 시작합니다. 커뮤니티 도구 쪽의 마지막 작업 스레드는 6월 16일이고, 그 뒤로는 업데이트 알림만 쌓였습니다. 같은 날 커뮤니티에 이렇게 썼습니다. "저는 윈도우에서 코딩 에이전트를 써서 자동화를 세팅하고." 도구는 리눅스 계층 위에서 돌았고, 제 자동화는 윈도우 창과 프로그램을 직접 눌러야 했습니다.
그러니까 수렴은 이랬습니다. 벤치마크에서 이긴 쪽이 남은 게 아니라, 제가 고칠 수 있는 쪽이 남았습니다. 설치가 죽었을 때 원인을 찾아 준 건 이미 돌고 있던 그 에이전트였고, 제 지침 파일이 쌓여 있는 곳도 거기였고, 제 업무가 실제로 일어나는 윈도우 화면에 손이 닿는 것도 거기였습니다. 병행 열흘 동안 저는 봇 두 개, 로그인 두 벌, 되돌리기 한 번을 관리했고, 그 비용이 두 번째 엔진이 주는 차이보다 컸습니다.
남은 것 세 가지
하나. 비교는 표가 아니라 같은 일로 합니다. 3월에도 4월에도 6월에도, 결정은 "같은 걸 시켜 보니 이쪽이 나랑 맞다"에서 났습니다. 벤치마크는 봤고, 참고했고, 쓰지 않았습니다. 지금도 새 모델이 나오면 제 업무 하나를 똑같이 시켜 보고 판단합니다.
둘. 엔진은 갈아타도 지침 파일은 남습니다. 지난 글에서 성격 파일 서른일곱 줄을 쓰고 기억 규칙은 안 만들었다고 했습니다. 이번 석 달의 결론은 그 반대편입니다. 4월 12일 이후 쌓인 지침과 스크립트가 있었기 때문에 6월의 병행이 "이사"가 아니라 "엔진 교체 검토"로 끝났습니다. 엔진에 붙어 있는 자산은 엔진과 함께 사라지고, 파일에 있는 자산은 남습니다.
셋. 병행에는 값이 있습니다. 두 개를 돌리면 비교가 되는 대신 관리가 두 배가 됩니다. 저는 열흘을 썼고, 그 정도가 답을 얻는 데 필요한 값이었습니다. 다만 한 달을 넘겼다면 비교가 아니라 습관이 됐을 겁니다.
그리고 2월에 못 넘긴 "마지막 한 칸" — 파일을 만들어 놓고 화면에 올리지 못했던 그 등록 업무는 이 병행이 끝난 뒤에야 다시 돌기 시작했습니다. 그 얘기는 봇을 세 대로 나눈 이야기와 함께 다음 글에 씁니다.
이 글의 날짜는 설치 폴더와 백업 파일에 남은 시각, 커뮤니티에 제가 직접 쓴 메시지, 매일 아침 오던 정리 메일에서 확인한 것입니다. 3월에서 6월 사이는 그 밖의 기록이 얇아서, 왜 그렇게 판단했는지는 기억으로 메운 부분이 있고 본문에 그렇게 적었습니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.