새 모델 발표를 언제부턴가 안 열어보고 있습니다

9월 1일에 Fable 5.1 이 나왔고, 다음 날 Gemini 3.8 Flash 가 나왔고, 그다음 날 GPT-6 Astra 가 나왔습니다. 사흘 연속이었습니다.

처음에는 정리해두려고 했습니다. 뭐가 나왔고 뭐가 달라졌고 어느 쪽으로 옮기는 게 나은지. 문서를 열고 목록을 만들다가 세 줄쯤에서 닫았습니다. 이걸 다 채워놔도 다음 주에 또 나올 텐데, 그때 이 문서는 뭐가 되나 싶었습니다.

그래서 이 글에는 9월 첫 주에 무엇이 나왔는지 정리한 표가 없습니다. 정리하고 싶어지는 마음 쪽을 보는 글입니다. 그리고 문서를 닫고 나서야 알았는데, 저는 이미 한참 전부터 안 따라가고 있었습니다. 그만두기로 정한 날이 없는데도 그렇게 돼 있었습니다.

따라가면 앞선다는 감각은 어디서 왔나

이 믿음에는 출처가 있습니다. 2023년에서 2024년 사이에는 실제로 그랬습니다.

그때는 새 모델이 나오면 못 하던 일이 됐습니다. 파일 하나를 통째로 못 넣던 것이 들어가게 되고, 대화가 열 번을 못 넘기던 것이 오십 번을 넘겨도 앞을 기억했습니다. 늦게 옮긴 사람은 그 몇 달 동안 실제로 못 하는 일이 있었습니다. 그러니 "새 게 나오면 바로 확인한다"는 습관은 그 시절에는 합리적인 투자였습니다.

문제는 그 시절 학습이 몸에 남아 있다는 겁니다. 새 모델 발표를 보면 "지금 안 옮기면 뒤처진다"는 감각이 먼저 옵니다. 감각이 틀린 게 아니라 그 감각이 만들어진 조건이 사라졌습니다.

지금은 새 모델이 나와도 못 하던 일이 갑자기 되지는 않습니다. 하던 일을 조금 더 잘합니다. 그 "조금 더"는 발표 자료를 읽어서는 확인이 안 됩니다. 벤치마크 점수는 남이 고른 문제로 잰 값이고, 제가 실제로 시키는 일과 겹치는 구간이 얼마인지는 아무도 안 알려줍니다. 그래서 확인하려면 제 작업으로 직접 돌려봐야 하는데, 제대로 하려면 반나절이 갑니다.

두 달 사이에 제가 알림으로 받은 발표만 여덟 번이었습니다. 여덟 번을 전부 확인하면 나흘입니다. 그 나흘 동안 새로 두세 개가 더 나옵니다. 이건 따라잡히는 종류의 줄이 아닙니다.

주말에 갈아탄 사람의 다음 주

이 손해가 시간으로만 계산되면 그래도 나은데, 실제로는 다른 게 더 크게 빠져나갑니다. 흔한 순서를 한번 펼쳐보겠습니다.

금요일 밤에 발표를 봅니다. 벤치마크가 눈에 띄게 올라가 있고, 데모 영상이 잘 만들어져 있습니다. 토요일 오전에 키를 발급받고 붙여봅니다. 잘 됩니다. 그런데 기존 프롬프트를 그대로 넣으니 출력 형식이 조금 다릅니다. 그래서 프롬프트를 새 모델에 맞게 손봅니다. 오후 내내 손봅니다. 저녁쯤 되면 꽤 잘 나오고, 기분이 좋습니다. 이 기분은 진짜입니다. 잘 만든 도구를 처음 만졌을 때 나는 각성이 있습니다.

일요일에는 두어 개 더 시켜보고 "이거 괜찮네" 하고 마무리합니다.

월요일에 실제 일에 씁니다. 어딘가에서 틀립니다. 그런데 그게 새 모델이라서 틀린 건지, 원래 그 작업이 어려운 건지, 아니면 어제 손본 프롬프트 때문인지 알 수가 없습니다. 확인하려면 이전 모델에 같은 걸 넣어봐야 하는데, 프롬프트는 이미 새 모델 기준으로 고쳐놨습니다. 원래 프롬프트가 어땠는지도 정확히 기억이 안 납니다.

화요일에 되돌립니다. 되돌리면서 보니 손볼 게 생각보다 많습니다. 수요일쯤 되면 "그래서 내가 주말에 뭘 한 거지" 상태가 됩니다.

그리고 목요일에 다른 회사에서 새 모델이 나옵니다.

여기서 실제로 잃은 건 이틀이 아니라 비교할 기준선입니다. 새 걸 붙여보는 일 자체는 나쁘지 않은데, 붙여보면서 기존 설정을 같이 흔들어놓으면 그 뒤로는 뭐가 좋아졌고 뭐가 나빠졌는지 판단할 근거가 없어집니다. 그 상태가 몇 달 쌓이면 남는 건 "요즘 뭐가 제일 좋아요?"라는 질문뿐입니다. 자기가 쓰는 도구를 몇 달 썼는데도 남한테 물어보게 되는 겁니다.

한 시대를 살아가는 개인 입장에서 지금 이 판은 예측할 대상이 아니라 대비할 대상에 가깝게 보입니다. 태풍이 온다고 할 때 어느 기압골이 이길지 맞추는 사람은 없습니다. 창문을 점검하고 물을 받아둡니다. 어느 회사가 이기는지는 제가 알 수 있는 게 아니고, 제 쪽에서 할 수 있는 건 그 정도입니다.

확인하던 걸 언제 그만뒀는지 모르겠습니다

여기까지 적어놓고 보니 제가 손익을 따져보고 결정한 것처럼 읽히는데, 아닙니다. 위에 적은 나흘이라는 계산도 이 글을 쓰면서 처음 해봤습니다.

초기에는 확실히 달랐습니다. 새 모델이 나오면 일단 붙여봤습니다. 뭐가 달라졌는지 확인하고, 예전에 안 되던 걸 다시 넣어보고, 되면 어디까지 되는지 밀어봤습니다. 안 되던 게 되는 순간이 재미있어서 했습니다. 누가 시킨 것도 아니고 그 확인이 필요해서도 아니었습니다.

지금은 안 합니다. 대신 그냥 씁니다. 아침에 켜놓고 하루 종일 열어둔 채로 뭐 하나 물어보고 넘어가고, 저녁에 또 씁니다. 물 마시듯 밥 먹듯 씁니다. 확인하고 테스트하는 대상이 아니라 그냥 쓰는 물건이 됐습니다.

언제 그렇게 됐는지는 모르겠습니다. 그만두기로 한 날이 없습니다. 쓰는 횟수가 늘다가 어느 지점을 지나면서 신기한 물건에서 그냥 도구로 내려앉았고, 내려앉고 나니 발표를 열어볼 일이 자연히 없어졌습니다.

물건이 생활 안으로 들어오면 사람은 사양표를 안 봅니다. 냉장고 새 모델이 나왔다고 소비전력을 비교하지 않습니다. 지금 것이 돌아가면 그냥 씁니다. 문이 잘 안 닫히거나 이상한 소리가 나면 그때 알아봅니다. 지금 제가 모델을 대하는 거리가 딱 그 정도입니다.

그래서 아래에 적는 것들은 제가 지켜야겠다고 정해놓은 원칙이 아닙니다. 이미 그렇게 하고 있던 걸 나중에 말로 옮겨본 쪽에 가깝습니다. 순서도 제가 만든 게 아니라, 되짚어보니 이런 모양이었습니다.

올여름에 Meta 는 닫고 Alibaba 는 열었습니다

그렇다고 아무거나 하나 골라서 오래 쓰면 되는 것도 아닙니다. 그 반대로 갔다가 최근에 크게 어긋난 자리가 하나 있습니다.

몇 년 동안 "오픈소스 진영은 Meta"라는 정리가 통했습니다. 그런데 올여름에 Meta 는 Muse Code 베타와 Muse Spark 1.2 를 냈고, Muse Spark 는 4월에 나온 독점 모델의 후속입니다. Llama 후속작은 미뤄졌고, 저커버그는 초지능 수준 모델을 오픈소스로 내지 않겠다고 직접 못 박았습니다. 닫는 쪽으로 갔습니다.

같은 여름에 반대 방향으로 간 곳이 Alibaba 입니다. Qwen 3.8 가중치가 8월 중순에 공개됐고, 27B 는 Apache 2.0 입니다. 그리고 Max 급 체크포인트까지 가중치로 나왔습니다. 이전까지 Max 는 전부 API 전용이었습니다. 이 부분은 설치하기 전에 뭐가 달라진 건지부터 찾아봤을 때 좀 놀랐던 자리이기도 합니다.

이걸 어느 쪽이 착하다는 이야기로 읽으면 재미는 있는데 쓸모는 없습니다. 제가 보는 건 다른 겁니다.

2년 전에 "내 기계에서 돌릴 수 있는 모델은 Meta 쪽에서 온다"고 정리하고 그 위에 계획을 세운 사람은, 지금 그 계획을 다시 짜야 합니다. 그 사람이 판단을 못 한 게 아닙니다. 정리해둔 것 자체의 유통기한이 짧았던 겁니다. 회사 안에 오픈웨이트를 들여놓는 계산을 예전에 한 번 해본 적이 있는데, 그때 깔아둔 전제 중에 지금도 유효한 게 몇 개나 되는지 세어보면 마음이 좀 복잡해집니다.

여기에 하나 더 붙습니다. xAI 가 8월에 Grok 4.6 을 내면서 자사 채널보다 GitHub Copilot 이나 Microsoft Foundry 같은 남의 배포 경로를 앞세웠습니다. 이건 모델이 오는 방식이 바뀌고 있다는 신호입니다. 제가 고르러 가는 게 아니라, 제가 이미 쓰고 있는 도구 안에 어느 날 새 모델이 들어와 있습니다. 선택한 기억이 없는데 이미 쓰고 있는 상태가 됩니다.

이게 저한테는 좀 곤란한 이야기입니다. 앞에서 저는 안 따라가고 있다고 적었는데, 안 따라가도 모델은 알아서 바뀝니다.

실제로 어느 주에 쓰던 도구가 평소와 다르게 답한 적이 있습니다. 같은 걸 물었는데 형식이 달라졌고, 예전에는 잘 잡던 걸 놓쳤습니다. 처음에는 제가 뭘 잘못 넣었나 싶어 입력을 세 번쯤 고쳐봤습니다. 그러다 릴리스 노트를 찾아보니 그사이에 뒷단 모델이 올라가 있었습니다. 저는 아무것도 고른 적이 없습니다.

여기서부터가 좀 이상해집니다. 앞에서 저는 갈아타면 기준선을 잃는다고 적었습니다. 그런데 갈아타지 않아도 기준선은 그냥 흔들립니다. 제가 고정해뒀다고 믿은 건 도구 이름이었지 그 안에서 도는 모델이 아니었습니다. 이름만 같고 속은 몇 달마다 바뀌는 물건을 붙잡고 기준선이라고 부르고 있었던 셈입니다.

그러면 기준선이라는 말이 성립하기는 하는지 의심스러워집니다. 여기에는 아직 답이 없습니다. 지금은 이 정도로 보고 있습니다. 완전히 고정된 기준선은 못 만들고, 대신 바뀐 걸 알아채는 자리는 만들 수 있습니다. 자주 시키는 일 중에 제가 답을 정확히 아는 걸 두어 개 남겨두는 정도입니다. 그게 이상하게 나오면 뭔가 바뀐 겁니다.

대단한 방법은 아닙니다. 다만 순서가 반대라는 점은 마음에 듭니다. 발표를 보고 뭐가 바뀌었는지 아는 게 아니라, 손이 먼저 이상하다고 하고 그다음에 확인하러 가는 순서입니다. 냉장고에서 이상한 소리가 나면 그때 알아본다고 위에 적었는데, 그것과 같은 순서입니다. 그리고 이 순서는 알림을 안 봐도 돌아갑니다.

그리고 반대편에는 아예 못 쓰는 것도 늘고 있습니다. Gemini 3.8 Flash Cyber 는 특정 프로그램 참여자에게만 열리고, GPT-6 Astra 도 보안 프로그램 고객 쪽에 먼저 갔습니다. 개인이 "지금 세상에서 제일 좋은 모델"을 쓰겠다는 목표는, 그 모델이 개인에게 안 열린다는 이유만으로도 이미 성립하지 않습니다. 순위표를 아무리 잘 읽어도 제 손에 안 오는 항목이 위쪽에 섞여 있습니다.

따라가지 않는 것과 모르는 것은 다릅니다

여기까지 적고 보니 오해할 자리가 있어서 하나 붙입니다. 알림을 전부 끄고 반년쯤 아무것도 안 보는 것도 같은 정도로 손해입니다.

갈리는 선은 이쯤인 것 같습니다. 바뀐 걸 아는 일과 바로 옮기는 일은 다른 일입니다. 바로 앞에 적은 Meta 와 Alibaba 이야기가 그 예입니다. 그건 새 모델 하나가 나온 사건이 아니라 판의 모양이 바뀐 사건이고, 이런 건 놓치면 나중에 비싸게 됩니다. 반대로 벤치마크가 몇 점 올라갔다는 소식은 놓쳐도 아무 일 안 일어납니다.

요즘 제가 뭘 열어보고 뭘 안 열어보는지 돌아보면 두 종류로 갈려 있습니다. 순위가 흔들렸다는 소식은 안 열어봅니다. 라이선스가 바뀌었다거나, 접근 조건이 새로 생겼다거나, 값을 매기는 방식이 달라졌다거나, 어제까지 열려 있던 게 닫혔다는 소식은 봅니다. 앞엣것은 잠깐 좋아졌다 마는 값이고, 뒤엣것은 제 선택지의 모양을 바꿉니다. 정해놓고 나눈 건 아닌데, 안 열어본 쪽을 나중에 확인해봐도 아쉬웠던 적이 없어서 그대로 굳었습니다.

물론 이 구분이 늘 맞지는 않습니다. 저도 놓친 적이 있습니다.

한동안 쓰던 방식이 있었는데, 그게 더 간단한 방법으로 대체된 지 몇 달이 지나서야 알았습니다. 그동안 저는 잘 돌아가고 있으니 그대로 뒀습니다. 알고 나서 억울했느냐 하면 그렇지는 않았습니다. 그 몇 달 동안 하려던 일은 다 했으니까요. 다만 "안 열어봐도 손해가 없다"는 말이 언제나 참은 아니라는 건 그때 확인했습니다. 손해가 없는 게 아니라 손해가 작아서 안 보이는 쪽에 가깝습니다. 그리고 작은 손해는 오래 두면 커집니다.

그래서 요즘은 안 따라가는 대신 가끔 뒤를 돌아봅니다. 몇 달에 한 번쯤 지금 하는 방식이 아직도 제일 편한지 확인해보는 정도입니다. 이것도 날을 정해놓고 하는 건 아니고, 대체로 뭔가 불편해졌을 때 하게 됩니다. 불편이 신호 역할을 하는 셈인데, 신호가 늦게 온다는 게 이 방식의 약점입니다. 그건 알고 있고, 그래도 발표를 매번 열어보는 쪽보다는 낫다고 보고 있습니다.

하나 더 있습니다. 속도가 사람 쪽 준비를 앞질러 가는 상황은 전에 한 번 적어본 적이 있는데, 그때 든 생각이 지금도 같습니다. 발표가 빨라지는 속도와 그게 실제로 제 손에 들어오는 속도 사이에는 간격이 있습니다. 그 간격 안에서 서두르면 얻는 것보다 되돌릴 일이 많아집니다. 그리고 그 간격이 닫힐 때는 대체로 조용히 닫힙니다. 발표하는 날이 아니라 몇 달 뒤 아무 날에, 어제까지 안 되던 게 그냥 되는 형태로요. 그런 건 따라다니지 않아도 어차피 알게 됩니다.

모델이 바뀌는 동안 제 쪽에서 안 바뀐 것

그러면 그동안 저는 뭘 하고 있었나 싶어 되짚어봤습니다. 모델이 여덟 번 바뀌는 사이에 제 쪽에서 그대로였던 게 대충 세 덩어리로 남습니다.

가장 먼저 무엇을 시킬지 정하는 일이 있습니다. 모델이 좋아져도 문제를 정의하는 건 사람이 합니다. 이건 당연한 말처럼 들리는데, 실제로는 여기서 갈리는 경우가 많습니다. 같은 모델을 주고 같은 상황에 놓아도 어떤 사람은 세 번 만에 원하는 걸 받아내고 어떤 사람은 스무 번을 돌려도 못 받아냅니다. 차이는 모델 쪽에 없습니다.

구체적으로는 이런 차이입니다. "이 코드 리뷰해줘"와 "여기서 두 사람이 같은 항목을 동시에 수정하면 어디가 깨지는지 봐줘"는 같은 모델에 넣어도 다른 게 나옵니다. 뒤엣것을 물으려면 이 코드가 어디서 터질지 짐작이 먼저 있어야 하고, 그 짐작은 모델이 안 줍니다. 그리고 모델이 좋아질수록 앞엣것에 대한 답도 그럴듯해져서, 앞엣것만 물어도 되는 것처럼 보입니다. 그게 함정입니다.

"프롬프트 공부는 모델 바뀌면 무용지물"이라는 말이 도는데, 절반만 맞는 것 같습니다. 모델별 요령은 날아갑니다. 어떤 말투를 좋아하고 어떤 지시어에 반응이 좋은지 같은 건 다음 버전에서 그냥 사라집니다. 그런데 무엇을 물을지 아는 건 안 날아갑니다. 제가 쓴 글들을 나중에 다시 열어봤을 때 남아 있던 것도 요령 쪽이 아니었습니다.

그다음이 검증인데, 이건 길어질 것 같아 따로 적겠습니다.

마지막은 제 맥락과 자료가 어디에 있느냐입니다. 프롬프트와 규칙과 참고 문서가 특정 서비스 안에만 들어 있으면 그 서비스를 떠날 수 없습니다. 나가는 순간 다시 만들어야 하니까요. 저는 그냥 파일로 두는 게 편해서 파일로 뒀는데, 그러다 보니 어디에든 붙습니다. 대비하려고 그런 건 아니었고 결과적으로 대비가 된 셈입니다. 갈아타라는 뜻은 아닙니다. 갈아탈 수 있는데 안 갈아타는 것과 못 갈아타는 것은 완전히 다른 상태라는 뜻입니다.

모델이 좋아질수록 틀린 걸 알아채기가 어려워집니다

이게 요즘 제일 자주 걸리는 자리입니다.

OpenAI 는 Astra 를 내면서 자사 모델 중 처음으로 위험 수준의 사이버보안 능력 기준을 넘겼다고 스스로 밝혔습니다. 제로데이 취약점을 찾아낼 수 있다는 이야기가 같이 나왔습니다. 그래서 보안 프로그램 고객 쪽에 먼저 배포했습니다.

이 발표를 성능 자랑으로만 읽으면 절반만 읽은 겁니다. 뒤집으면 이렇게 됩니다. 그 모델이 찾아냈다고 말하는 취약점이 진짜인지, 저는 판단할 방법이 없습니다.

검증이라는 게 뭔지 생각해보면 명확합니다. 저는 제가 아는 영역에서만 검증을 합니다. 답을 알고 있거나, 답은 몰라도 틀린 모양은 알아보거나 둘 중 하나입니다. 코드를 짜라고 시켰을 때 존재하지 않는 함수를 부르면 압니다. 논리가 중간에 끊기면 압니다. 그건 제가 그 영역에서 모델보다 낫거나 최소한 비슷하기 때문에 가능한 일입니다.

그런데 모델 능력이 제 능력을 넘어간 영역에서는 그게 안 됩니다. 남는 선택지가 믿거나 안 믿거나 둘뿐입니다. 그건 검증이 아닙니다.

더 곤란한 건 틀렸을 때의 겉모양입니다. 예전 모델은 틀리면 티가 났습니다. 문법이 깨지고, 없는 라이브러리를 부르고, 문단 중간에서 화제가 바뀌었습니다. 지금은 틀려도 형태가 멀쩡합니다. 컴파일되고, 테스트가 통과하고, 주석까지 붙어 있고, 근거처럼 보이는 설명이 세 문단 따라옵니다. 틀린 답과 맞는 답이 겉으로 구분이 안 되는 상태가 된 겁니다.

이게 코드 이야기로만 들리는데 그렇지 않습니다. 낯선 분야를 대신 조사시킬 때가 정확히 같은 구조입니다. 계약서 조항을 요약해달라고 하거나, 처음 보는 규정을 풀어달라고 하거나, 모르는 언어로 된 문서를 옮겨달라고 할 때. 시키는 이유 자체가 제가 모르기 때문인데, 모르니까 틀렸는지도 모릅니다. 그리고 돌아오는 문장은 단정합니다. 조항 번호까지 붙어 있고 말투에 망설임이 없습니다. 여기서 틀린 걸 잡아내려면 결국 원문을 열어야 하는데, 원문을 열 거면 애초에 시킬 이유가 없었습니다. 이 순환이 실제로 잘 안 풀리는 자리입니다.

장면을 하나 펼쳐보겠습니다. 부모님이 병원에서 받아온 안내문을 대신 읽어드리는 상황입니다. 용어가 절반쯤은 처음 보는 말입니다. 그래서 넣고 풀어달라고 합니다.

잘 나옵니다. 문단이 나뉘어 있고, 어려운 말에는 괄호로 설명이 붙어 있고, 주의할 점까지 아래에 정리돼 있습니다. 읽으면서 "아 이런 뜻이었구나" 하게 됩니다.

여기서 제가 확인할 수 있는 게 뭔지 따져보면 거의 없습니다. 원문 용어가 정말 그 뜻인지 저는 모릅니다. 안내문에 있던 조건 하나가 설명에서 빠졌는지도 모릅니다. 그리고 빠진 자리에는 아무 표시가 안 남습니다. 없어진 걸 알아보려면 원문을 알아야 하는데, 원문을 모르니까 시킨 겁니다.

그래서 이런 건 결국 사람한테 다시 묻게 됩니다. 풀어준 걸 들고 가서 "이렇게 이해했는데 맞나요" 하고 확인합니다. 그러면 시킨 의미가 없어지는 것 같은데, 그렇지도 않습니다. 아무것도 모르는 채로 묻는 것과 정리된 걸 들고 가서 맞는지 묻는 것은 다릅니다. 앞의 것은 설명을 처음부터 들어야 하고, 뒤의 것은 틀린 자리만 짚어주면 됩니다. 요즘 제가 쓰는 방식이 대체로 이쪽으로 굳었습니다. 답을 받는 쪽이 아니라 물어볼 거리를 만드는 쪽으로요.

그러니까 모델이 좋아지면서 두 가지가 동시에 일어납니다. 맞는 비율이 올라가고, 틀렸을 때 알아채기가 어려워집니다. 그리고 뒤엣것이 앞엣것보다 위험합니다. 열 번 중 아홉 번 맞는 도구를 계속 쓰다 보면 열 번째도 확인 안 하게 되기 때문입니다. 아홉 번 맞는 도구는 신뢰를 만들고, 그 신뢰가 열 번째를 통과시킵니다.

여기에 잔인한 지점이 하나 더 있습니다. 사람들이 새 모델로 갈아타는 이유는 대개 일을 줄이려고입니다. 그런데 검증 비용은 반대로 갑니다. 모델이 세질수록 확인해야 할 게 늘고, 확인하기는 더 어려워집니다. 그러니까 갈아타는 속도가 빠른 사람일수록 확인하지 않는 습관이 먼저 붙습니다. 속도를 가장 즐긴 사람이 그 대가를 제일 먼저 치르게 되는 구조입니다.

그럼 뭘 확인하나

뾰족한 수가 있는 건 아닙니다. 하다 보니 남은 것들이 있는데, 세련되지는 않고 대신 제 능력 안에 들어옵니다.

결과 말고 결과가 만드는 변화를 봅니다. 취약점을 찾아줬다고 하면 그 취약점이 실제로 재현되는지 봅니다. 취약점을 찾아내는 일은 제가 못 하지만, 주어진 취약점을 재현해보는 일은 할 수 있습니다. 이 둘의 난이도 차이가 큽니다. 성능이 올라가는 쪽은 앞의 일이고, 제 손에 남은 건 뒤의 일입니다. 코드도 같습니다. 설명을 읽고 판단하는 대신 실행해서 상태가 어떻게 바뀌는지 봅니다.

두 모델에 같은 걸 시켜서 갈리는 자리를 봅니다. 둘 다 맞는지는 여전히 모릅니다. 그런데 답이 갈리면 최소한 거기가 의심할 자리라는 건 압니다. 여러 개를 열어두고 있는 이유도 결국 이것 하나인 것 같습니다. 제일 좋은 걸 쓰려고 여러 개를 두는 게 아니라, 서로 어긋나는 지점이 보여서 그냥 두고 있습니다.

확인이 안 되는 건 되돌릴 수 있게 둡니다. 커밋을 잘게 나누고, 한 번에 한 군데만 바꾸고, 롤백 경로를 먼저 봐둡니다. 검증을 못 하면 복구 비용이 낮은 쪽으로 손이 갑니다. 이건 소프트웨어에서만 되는 이야기가 아닙니다. 문서든 계약서든 마찬가지고, 되돌릴 수 없는 일에는 확인 못 한 출력을 안 쓰게 됐는데 그것만으로도 대부분 걸러집니다.

세 가지 다 모델 성능과 상관이 없습니다. 그래서 다음 모델이 나와도 그대로 남아 있습니다.

구독을 하나씩 늘리다 보면

여기서부터는 갈라서 적겠습니다. 코드를 안 쓰시는 분이라면 이쪽이 더 가깝습니다.

비개발자 쪽에서 따라가기가 나타나는 형태는 대개 구독입니다. 새로운 게 좋다고 하니 하나 더 결제합니다. 원래 쓰던 것도 아까워서 못 끊습니다. 그러다 세 개가 됩니다.

세 개를 결제하면 세 개를 다 쓸 것 같지만 실제로는 그렇게 안 됩니다. 하나를 쓰다가 답이 시원찮으면 다른 데 넣어봅니다. 거기서도 애매하면 남은 하나에 넣어봅니다. 그러고 나면 세 도구 모두에서 초보 상태에 머물러 있습니다. 도구를 바꾸는 데 쓴 시간이, 하나를 깊이 쓰는 데 쓸 시간을 그대로 먹었기 때문입니다.

돈 이야기도 생각보다 안 보입니다. 구독은 한 번 결제하면 조용히 빠져나가서, 목록을 실제로 적어보기 전에는 몇 개인지도 모릅니다. 저도 회사가 지원해주는 걸 쓰면서 개인 결제를 또 했던 적이 있는데, 그때 목록을 전부 적어보고 나서야 상황이 보였습니다.

그런데 구독만 문제인 것도 아닙니다. 안 옮기고 하나만 써도 도구 쪽이 알아서 바뀝니다.

어제까지 되던 방식이 오늘 안 되는 일이 있습니다. 화면이 개편돼서 늘 누르던 자리가 없어지기도 하고, 같은 문장을 넣었는데 답이 눈에 띄게 짧아지기도 합니다. 이때 제일 곤란한 건 원인을 알 수 없다는 겁니다. 내가 잘못 쓴 건지, 오늘따라 서버가 이상한 건지, 뒷단이 바뀐 건지 밖에서는 구분이 안 됩니다. 개발자라면 로그라도 열어보겠는데 여기서는 열어볼 게 없습니다. 그래서 대개 자기 탓을 하고 넘어갑니다.

쓰던 기능이 위 등급으로 올라가는 경우도 있습니다. 무료로 되던 게 유료가 되고, 유료로 되던 게 더 비싼 쪽으로 갑니다. 그러면 선택지가 둘로 줄어듭니다. 돈을 더 내거나, 그 일을 하던 방식 자체를 바꾸거나. 아래에서 개발자가 모델 API 에 묶여 있으면 벤더 결정을 그냥 받아들이게 된다고 적을 텐데, 구조는 똑같고 손댈 여지만 더 적습니다. 코드를 고쳐서 빠져나갈 수 있는 쪽이 차라리 형편이 낫습니다.

제 경우에 이쪽에서 할 수 있었던 건 도구 밖에 남겨두는 것 하나였습니다. 자주 쓰는 지시문이나 정리해둔 자료를 그 서비스 안에만 두지 않고 메모든 파일이든 따로 갖고 있는 정도입니다. 준비라고 부르기도 민망한 수준입니다. 그런데 도구가 바뀌었을 때 다시 만들지 않아도 된다는 것 하나가 생각보다 큽니다. 다시 만들어야 하면 대개 안 만들고 그냥 참게 되기 때문입니다.

저는 결과적으로 하나를 오래 쓰게 됐습니다. 그게 나은 선택이라고 판단해서가 아니라 옮길 이유가 안 생겨서인데, 오래 쓰다 보니 그 도구로 무엇을 시킬지가 저절로 다듬어졌습니다. 도구 목록은 다음 도구로 안 옮겨가지만, 무엇을 어떻게 시킬지 아는 건 옮겨갑니다. 한 도구를 반년 쓴 사람은 새 도구로 옮겨도 일주일이면 따라잡습니다. 반대로 여섯 개를 한 달씩 쓴 사람은 일곱 번째에서도 똑같이 헤맵니다.

"이번 건 진짜 다른 것 같은데"라는 느낌이 들 때가 있습니다. 그 느낌 자체는 매번 옵니다. 앞에서 적은 주말 이야기의 토요일 저녁이 정확히 그 지점입니다. 그건 모델 성능이 아니라 새 도구를 처음 만졌을 때의 각성이고, 며칠 지나면 가라앉습니다. 가라앉은 뒤에도 남아 있으면 그때 옮기면 됩니다.

제가 실제로 옮겼던 때를 돌아보면 대개 같은 상황이었습니다. 지금 쓰는 도구로 안 되는 일이 구체적으로 생겼을 때였습니다. 남이 좋다고 할 때가 아니라, 제가 하려는 일이 여기서 안 될 때. 그때는 옮겼고, 그때가 아니면 대체로 그냥 있었습니다.

모델을 바꾸려는데 코드가 안 놔줍니다

개발자 쪽은 문제가 조금 다르게 생겼습니다. 여기서는 갈아타고 싶어도 못 갈아타는 상황이 먼저 옵니다.

코드가 특정 모델 API 에 묶여 있으면 모델 교체가 리팩터링이 됩니다. 그러면 새 모델이 나와도 붙여볼 엄두를 안 내게 되고, 결과적으로 벤더가 가격을 올리든 정책을 바꾸든 그냥 받아들이게 됩니다. 선택지가 없는 상태에서는 판단이라는 게 성립하지 않습니다.

그래서 하네스와 워크플로우 층을 모델 호출에서 떼어놓는 일이 중요하다고들 하는데, 여기에 함정이 하나 있습니다. 떼어놨다고 믿는 것과 실제로 떼어져 있는 것은 다릅니다.

추상화 계층을 만들어놓고 한 번도 다른 모델로 돌려본 적이 없는 코드는 추상화가 된 게 아니라 추상화처럼 생긴 코드입니다. 실제로 옮겨보면 대개 새어 나온 자리가 나옵니다. 특정 벤더에서만 되는 응답 형식을 어딘가에서 그대로 쓰고 있거나, 토큰 제한을 하드코딩해뒀거나, 스트리밍 처리 방식이 한쪽 SDK 모양을 그대로 따라가고 있거나 합니다. 저도 묶여 있다고 믿었던 걸 실제로 열어본 적이 있는데, 열어보기 전과 후의 그림이 상당히 달랐습니다.

그래서 계층을 잘 그려놓는 것보다 한 번 실제로 옮겨서 돌려보는 것이 훨씬 많이 알려줍니다. 저는 쓸 생각도 없으면서 한 번 돌려본 적이 있는데, 그때 어디가 새는지 목록이 나왔습니다. 그 목록이 나온 뒤로는 새 모델 소식이 와도 마음이 편합니다. 옮길지 말지를 고를 수 있는 상태니까요. 그전까지는 옮길 수 있다고 믿고 있었는데, 그 믿음에 근거가 없었습니다.

가격 구조도 여기에 붙습니다. Fable 5.1 은 입출력 단가를 그대로 두고 캐시 읽기 비용만 크게 내렸습니다. 이 말은 캐시를 많이 쓰는 워크플로우가 유리해졌다는 뜻이고, 반대로 캐시를 안 쓰는 쪽은 아무것도 안 달라졌다는 뜻입니다. 벤더마다 가격이 움직이는 축이 다릅니다. 한쪽은 컨텍스트 길이를 늘려주고, 한쪽은 캐시를 깎고, 한쪽은 배치 처리를 싸게 합니다.

그래서 한 벤더 가격 구조에 맞춰 최적화한 워크플로우는 다른 데서 최적이 아닙니다. 여기서 잘 나오던 구성이 저기서는 비싸게 나옵니다. 이걸 모르면 옮겨보고 "역시 이게 낫네" 하고 돌아오는데, 사실은 옮긴 쪽에 맞는 구성을 안 써본 것뿐인 경우가 많습니다. 비교를 하려면 양쪽 다 그쪽 방식으로 짜봐야 하는데, 그게 귀찮으니까 대부분 안 합니다. 저도 잘 안 합니다.

그리고 오픈웨이트 쪽이 하나 더 있습니다. 27B 급이 Apache 2.0 으로 나온다는 건, 최소한 하나는 내 기계에 두고 기준선으로 삼을 수 있다는 뜻입니다. 성능으로 이기라는 게 아니라 없어지지 않는 비교 대상을 하나 갖는다는 의미입니다. API 모델은 어느 날 버전이 바뀌고, 조용히 응답이 달라지고, 가끔 없어집니다. 로컬에 둔 건 안 그렇습니다. 앞에서 기준선 이야기를 했는데, 개발자 쪽에서 기준선은 이런 형태로 남습니다.

지금은 여기까지 보고 있습니다

이 글을 쓰면서 Astra 를 안 써봤습니다. 안 써보고 판단을 적는 게 맞나 싶어서 한참 걸렸는데, 다 써보고 쓰려면 이 글은 영영 못 씁니다. 그리고 그게 이 글이 하려는 말이기도 합니다.

아직 잘 모르겠는 부분도 있습니다. 안 바뀐 게 셋이라고 적어놨는데, 그중 검증 쪽은 사실 지금 흔들리고 있습니다. 제 능력을 넘어간 출력이 늘어나는 속도가, 제가 확인 방법을 만들어내는 속도보다 빠릅니다. 위에 적은 세 가지도 언제까지 통할지는 모르겠습니다. 재현해보는 방법 자체가 안 통하는 영역이 늘어나면 그때는 다른 걸 찾아야 할 텐데, 아직 뭔지 모르겠습니다.

기준선 이야기도 마찬가지입니다. 위에서 알아채는 자리를 두면 된다고 적어놨는데, 그 자리에 무엇을 둘지도 결국 제가 고른 겁니다. 제가 안 보는 쪽에서 뭐가 바뀌면 여전히 모릅니다. 이건 해결됐다기보다 조금 미뤄둔 문제에 가깝습니다.

다음 주에도 뭔가 나올 겁니다. 아마 안 열어볼 겁니다. 안 열겠다고 마음먹어서가 아니라, 그 시간에 지금 쓰는 걸로 하던 일을 하고 있을 테니까요. 열어봐야 할 이유가 생기면 그때 열겠습니다.