9월 1일에 Fable 5.1 이 나왔고 2일에 Gemini 3.8 Flash, 3일에 GPT-6 Astra 가 나왔습니다. 사흘 내리 하나씩 나온 셈입니다.
처음엔 정리를 해두려고 했습니다. 뭐가 나왔는지, 뭐가 달라졌는지, 어느 쪽으로 옮기는 게 나은지 정도요. 문서를 열고 목록을 쓰다가 세 줄쯤에서 닫았습니다. 이걸 다 채워봐야 다음 주에 또 나올 거고, 그럼 이 문서는 뭐가 되나 싶었습니다.
닫고 나서 좀 이상한 걸 알았습니다. 저는 이미 꽤 오래전부터 발표를 안 열어보고 있었습니다. 그만하자고 마음먹은 날은 없었는데 그렇게 돼 있었습니다.
정리하고 싶어지는 마음이 어디서 오는지를 한참 생각했습니다. 표를 만들어두면 뭔가 손에 쥔 것 같습니다. 세 개가 나왔고 이건 이게 좋고 저건 저게 좋다고 적어두면 그 주는 놓친 게 없는 기분이 듭니다. 그런데 그 표를 다시 열어본 적이 있었나 생각해보면 거의 없었습니다. 만드는 순간에 할 일이 끝나는 표였던 것 같습니다. 정리를 한 게 아니라 정리했다는 기분을 산 거죠.
새 게 나오면 바로 봐야 한다는 감각은 2023년, 2024년쯤에 생긴 것 같습니다. 그때는 그게 맞았습니다. 새 모델이 나오면 못 하던 일이 됐습니다. 파일 하나를 통째로 못 넣던 게 들어갔고, 대화가 열 번을 못 넘기던 게 오십 번을 넘겨도 앞 내용을 기억했습니다. 늦게 옮긴 사람은 그 몇 달 동안 진짜로 못 하는 일이 있었으니까, 새 게 나오면 바로 확인하는 습관은 그때로서는 남는 장사였습니다.
그 습관이 아직 몸에 남아 있습니다. 발표를 보면 지금 안 옮기면 뒤처진다는 느낌이 먼저 옵니다. 느낌이 틀렸다기보다는 그 느낌이 생겼던 조건이 없어진 쪽이라고 보고 있습니다.
요즘은 새 모델이 나와도 못 하던 게 갑자기 되지는 않습니다. 하던 걸 조금 더 잘합니다. 그 조금이 얼마인지는 발표 자료로는 알 수가 없습니다. 벤치마크는 남이 고른 문제로 잰 점수라서 제가 실제로 시키는 일이랑 얼마나 겹치는지는 아무도 안 알려줍니다. 결국 제 일로 직접 돌려봐야 하는데 제대로 하면 반나절은 갑니다. 두 달 동안 알림으로 받은 발표가 여덟 번이었으니 다 확인하면 나흘입니다. 그 나흘 사이에 또 두세 개가 나옵니다. 따라잡을 수 있는 줄이 아닌 것 같습니다.
주말에 갈아타 본 사람
시간만 날아가면 차라리 괜찮은데 실제로는 다른 게 더 크게 날아가는 것 같습니다. 흔히 있을 법한 주말을 하나 떠올려 보면 이렇습니다.
금요일 밤에 발표를 봅니다. 벤치마크가 눈에 띄게 올랐고 데모 영상도 잘 만들었습니다. 토요일 오전에 키를 받아서 붙여봅니다. 잘 됩니다. 그런데 쓰던 프롬프트를 그대로 넣으니 출력 형식이 조금 다릅니다. 그래서 새 모델에 맞게 손을 봅니다. 오후 내내 손을 봅니다. 저녁쯤 되면 꽤 잘 나오고 기분이 좋습니다. 이 기분은 가짜가 아닙니다. 잘 만든 도구를 처음 만지면 그런 게 있습니다.
일요일엔 두어 개 더 시켜보고 괜찮네 하고 덮습니다.
월요일에 실제 일에 써보면 어디선가 틀립니다. 새 모델이라 틀린 건지, 원래 어려운 작업인지, 어제 고친 프롬프트 탓인지 알 수가 없습니다. 이전 모델에 같은 걸 넣어보면 되는데 프롬프트는 이미 새 모델 기준으로 고쳐놨고, 원래 어떻게 생겼었는지 정확히 기억도 안 납니다. 화요일에 되돌리기 시작하는데 생각보다 손볼 게 많습니다. 수요일쯤 되면 주말에 내가 뭘 한 건가 싶어집니다.
그리고 목요일에 다른 회사에서 또 하나가 나옵니다.
이렇게 보면 잃은 건 이틀보다는 비교할 기준선 쪽인 것 같습니다. 새 걸 붙여보는 건 괜찮은데, 붙여보면서 원래 설정까지 같이 흔들어놓으면 그 뒤로는 뭐가 좋아졌고 뭐가 나빠졌는지 가늠할 근거가 없습니다. 그게 몇 달 쌓이면 요즘 뭐가 제일 좋아요, 하고 남한테 묻는 것만 남습니다. 몇 달을 쓴 도구인데 남한테 물어보고 있는 겁니다. 그 질문을 받는 쪽도 사정은 비슷할 거라서, 대개는 자기가 마지막으로 들뜬 모델 이름을 말해줍니다. 그걸 듣고 또 주말을 씁니다. 이게 한 바퀴 도는 데 한 달이 안 걸리는 것 같습니다.
어느 회사가 이길지는 제가 알 수 있는 일이 아닌 것 같습니다. 태풍이 온다고 할 때 어느 기압골이 이길지 맞히려는 사람은 없고, 다들 창문을 점검하고 물을 받아둡니다. 개인 입장에서는 이 경쟁도 맞힐 대상보다는 대비할 대상에 가깝게 보입니다.
언제 그만뒀는지
이렇게 써놓으니 손익을 따져서 정한 것처럼 보이는데 그렇진 않았습니다. 나흘이라는 계산도 이 글 쓰다가 처음 해봤습니다.
초기엔 분명히 달랐습니다. 새 모델이 나오면 일단 붙였습니다. 뭐가 달라졌는지 보고, 전에 안 되던 걸 다시 넣어보고, 되면 어디까지 되나 밀어봤습니다. 안 되던 게 되는 순간이 재밌어서 그랬습니다. 누가 시킨 것도 아니었고 그게 필요해서도 아니었습니다.
지금은 그냥 씁니다. 아침에 켜두고 하루 종일 열어놓은 채로 뭐 하나 물어보고 넘어가고, 저녁에 또 씁니다. 물 마시듯 밥 먹듯 씁니다. 테스트하는 물건에서 그냥 쓰는 물건이 됐습니다. 언제 그렇게 됐는지는 정말 모르겠습니다. 쓰는 횟수가 늘다가 어느 순간 신기한 물건이 아니라 도구가 됐고, 도구가 되고 나니 발표를 열어볼 일이 없어졌습니다.
냉장고 새 모델이 나왔다고 소비전력을 비교하는 사람은 별로 없습니다. 지금 게 잘 돌아가면 그냥 씁니다. 문이 잘 안 닫히거나 이상한 소리가 나면 그때 알아봅니다. 제가 모델을 대하는 거리가 지금 딱 그 정도인 것 같습니다. 냉장고를 처음 샀을 때는 저도 사양표를 봤을 겁니다. 몇 년 쓰고 나면 그게 무슨 숫자였는지도 기억이 안 납니다. 그렇다고 냉장고를 덜 쓰는 것도 아니고 오히려 더 당연하게 씁니다. 모델도 비슷하게 된 것 같습니다. 덜 중요해져서 안 보는 게 아니라 너무 당연해져서 안 봅니다. 아래에 적는 것들도 지키려고 정한 원칙은 아니고, 이미 그렇게 하고 있던 걸 나중에 말로 옮겨본 겁니다. 순서도 되짚어보니 대충 이랬다는 정도입니다.
올여름 Meta 와 Alibaba
그렇다고 아무거나 하나 골라서 오래 쓰면 된다는 얘기도 아닌 것 같습니다. 그렇게 했다가 크게 어긋난 경우가 최근에 하나 있었습니다.
몇 년 동안 오픈소스 쪽은 Meta 라고들 했습니다. 그런데 올여름 Meta 가 낸 건 Muse Code 베타와 Muse Spark 1.2 였고, Muse Spark 는 봄에 나온 독점 모델의 후속입니다. Llama 후속은 밀렸고, 저커버그는 초지능 수준 모델은 오픈소스로 안 내겠다고 직접 말했습니다. 닫는 쪽으로 간 겁니다.
같은 여름에 Alibaba 는 반대로 갔습니다. Qwen 3.8 가중치가 8월 중순에 풀렸고 27B 는 Apache 2.0 입니다. Max 급 체크포인트까지 가중치로 나왔는데 이건 Apache 가 아니라 자체 라이선스입니다. 그전까지 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 에 묶여 있으면 모델을 바꾸는 게 리팩터링이 됩니다. 그러면 새 모델이 나와도 붙여볼 엄두가 안 나고, 벤더가 가격을 올리든 정책을 바꾸든 그냥 받아들이게 됩니다. 고를 게 없으면 판단이랄 것도 없습니다.
그래서 하네스나 워크플로우 층을 모델 호출에서 떼어놓으라고들 하는데, 떼어놨다고 믿는 거랑 진짜 떨어져 있는 건 다른 것 같습니다. 추상화 계층만 만들어두고 한 번도 다른 모델로 돌려본 적 없는 코드는 추상화처럼 생긴 코드에 가깝습니다. 실제로 옮겨보면 대개 새는 데가 나옵니다. 한 벤더에서만 되는 응답 형식을 어디선가 그대로 쓰고 있거나, 토큰 제한을 하드코딩해놨거나, 스트리밍 처리가 한쪽 SDK 모양을 그대로 따라가고 있거나요. 저도 묶여 있다고 믿었던 걸 실제로 열어본 적이 있는데, 열기 전이랑 후의 그림이 꽤 달랐습니다.
계층을 잘 그려두는 것보다 한 번 실제로 옮겨서 돌려보는 게 훨씬 많이 알려줬습니다. 저는 쓸 생각도 없으면서 한 번 돌려본 적이 있는데 그때 어디가 새는지 목록이 나왔습니다. 그 뒤로는 새 모델 소식이 와도 마음이 편합니다. 옮길지 말지 고를 수 있으니까요. 그전에는 옮길 수 있다고 믿기만 했지 근거가 없었습니다. 돌아보면 그 믿음 때문에 오히려 마음이 더 급했던 것 같습니다. 언제든 옮길 수 있다고 생각하니까 새 게 나올 때마다 옮겨야 하나 하는 질문이 매번 다시 열렸습니다. 실제로 새는 데를 알고 나니 그 질문이 한결 구체적이 됐습니다.
가격도 비슷합니다. Fable 5.1 은 입출력 단가는 그대로 두고 캐시 읽기만 많이 깎았습니다. 캐시를 많이 쓰는 워크플로우는 유리해졌고 안 쓰는 쪽은 달라진 게 없습니다. 벤더마다 가격을 건드리는 데가 달라서, 어디는 컨텍스트를 늘려주고 어디는 캐시를 깎고 어디는 배치를 싸게 합니다. 그래서 한 벤더 가격에 맞춰 짠 워크플로우는 다른 데서는 비싸게 나옵니다. 이걸 모르고 옮겨보면 역시 원래 게 낫네 하고 돌아오는데, 실은 옮긴 쪽에 맞는 구성을 안 써본 것일 때가 많습니다. 제대로 비교하려면 양쪽을 다 그쪽 방식으로 짜봐야 하는데 귀찮아서 대부분 안 하고, 저도 잘 안 합니다.
오픈웨이트도 여기에 걸립니다. 27B 급이 Apache 2.0 으로 나왔다는 건 최소한 하나는 제 기계에 두고 기준으로 쓸 수 있다는 뜻입니다. 성능으로 이기라는 게 아니라 없어지지 않는 비교 대상이 하나 생긴다는 겁니다. API 모델은 어느 날 버전이 바뀌고, 조용히 응답이 달라지고, 가끔 없어집니다. 로컬에 둔 건 안 그렇습니다. 앞에서 기준선이 흔들린다고 썼는데 개발자 쪽에서는 이런 식으로 하나는 붙잡아둘 수 있을 것 같습니다.
이 글을 쓰는 동안 Astra 는 안 써봤습니다. 안 써보고 이런 걸 적어도 되나 싶어서 한참 붙잡고 있었는데, 다 써보고 쓰려면 이 글은 못 씁니다.
안 바뀐 게 셋이라고 써놓고 보니 검증 쪽은 사실 지금 흔들리고 있습니다. 제 능력을 넘는 출력이 느는 속도가 제가 확인할 방법을 만드는 속도보다 빠릅니다. 위에 적은 것들도 언제까지 통할지 모르겠고, 재현해보는 방법이 안 통하는 영역이 늘면 다른 걸 찾아야 할 텐데 그게 뭔지는 아직 모르겠습니다. 알아채는 장치도 거기에 뭘 둘지 결국 제가 고른 거라, 제가 안 보는 쪽에서 뭐가 바뀌면 여전히 모릅니다. 해결했다기보다 조금 미뤄둔 것 같습니다.
그래도 지금은 이 상태가 그렇게 불안하지는 않습니다. 사흘 연속으로 나왔을 때 표를 만들다 닫은 것도, 따져보면 안 만들어도 별일 없을 거라는 걸 몸이 먼저 알고 있었던 것 같습니다.
다음 주에도 뭔가 나올 겁니다. 아마 안 열어볼 것 같습니다. 안 열겠다고 마음먹어서가 아니라 그 시간에 지금 쓰는 걸로 하던 일을 하고 있을 것 같아서요.
댓글
댓글 쓰기