몇 해 전만 해도 최상위 수준의 언어 모델을 다루는 일은 대규모 연산 인프라를 갖춘 소수의 실험실에만 열려 있었습니다. 지금은 오픈 가중치로 공개된 모델을 개인 개발자가 로컬 머신에서 돌립니다. 격차가 좁혀지고 있다는 말은 오픈소스 쪽에서 오래전부터 나왔지만, 최근 눈에 띄는 것은 좁혀진다는 방향보다 좁혀지는 속도입니다.

성능이 평준화되는 만큼 실무 커뮤니티에서 오가는 이야기도 옮겨가고 있습니다. 그중 하나가 하네스(harness)입니다. 하네스는 에이전트 실행 루프, 컨텍스트 관리, 도구 호출 순서를 묶는 틀을 가리킵니다. 모델 선택이나 프롬프트 기술보다 한 단계 아래에 있는 레이어인데, 이 층을 설명하는 글이 늘어난다는 건 실무자들이 관심을 두는 지점이 변하고 있다는 신호로 읽힙니다.

모델 성능이 평준화될수록, 그 옆에서 무슨 일이 생기는가

두 가지 변화가 나란히 진행됐습니다.

첫째, 오픈 가중치 모델의 실용 성능 향상. Qwen 시리즈, Meta의 Llama 계열, Mistral 계열은 코딩·수학·추론 벤치마크에서 같은 시기 상용 모델에 근접하는 성적을 잇달아 내놓았습니다. 여기에 양자화(quantization) 기술이 발전하면서 소비자용 GPU로도 중형 규모의 모델을 로컬에서 운영할 수 있게 됐습니다. 클로즈드 모델과 오픈 모델 사이의 성능 격차는 여전히 존재하지만, 그 간격이 비용 차이를 정당화하기 어려워지는 지점에 가까워지고 있습니다.

둘째, 학습 데이터를 둘러싼 법적 불확실성. 미국에서는 The New York Times가 OpenAI를 상대로 제기한 저작권 소송이 진행 중이고, 유럽에서는 학습 데이터 투명성을 요구하는 규제가 AI법을 중심으로 다뤄지고 있습니다. 어느 법원이 어느 방향으로든 명확한 판결을 내리는 순간, 현재 오픈소스 생태계가 공유하는 학습 데이터셋 상당수의 법적 지위가 흔들릴 수 있습니다. 이미 일부 모델 개발사들은 웹 크롤링 데이터 의존도를 줄이고 합성 데이터(synthetic data)와 라이선스 계약 데이터 비중을 높이는 방향으로 전략을 조정하고 있습니다.

하네스를 모르면 모델이 좋아도 쓸 수가 없습니다

모델 성능 경쟁이 치열했던 시기, 실무자들이 가장 많이 물은 질문은 어떤 모델을 쓸 것인가였습니다. 지금 커뮤니티의 질문 패턴은 달라졌습니다. 이 모델을 내 시스템에 어떻게 붙일까, 컨텍스트 창이 넘칠 때 무엇을 자르고 무엇을 남길까, 에이전트가 도구를 잘못 호출했을 때 어떻게 복구시킬까 같은 질문이 많아졌습니다.

이 전환은 에이전트 시스템이 늘어난 탓이기도 하지만, 더 근본적으로는 모델 선택이 성능을 결정하는 주요 변수에서 내려오고 있기 때문입니다. 하네스, 즉 실행 루프를 어떻게 짜느냐에 따라 같은 모델이 전혀 다른 결과를 냅니다. 어떤 도구를 언제 호출하고, 오류가 생겼을 때 재시도 횟수를 얼마나 허용하고, 이전 단계의 결과를 다음 단계 컨텍스트에 얼마나 압축해 넘길지 — 이런 설계 결정이 모델 선택보다 최종 성능에 더 크게 작용하는 상황이 생기고 있습니다.

저작권 이슈는 이 맥락에서 하네스 설계와 겹칩니다. 학습 데이터 적법성이 불확실한 모델을 기업 서비스에 연결할 때, 하네스 레이어가 그 모델의 출력을 얼마나 필터링하고 검증하느냐가 법적 리스크 관리의 한 축이 될 수 있습니다. 법원 판결 방향에 따라 특정 오픈소스 모델 자체를 쓰기 어려워지는 시나리오도 나올 수 있고, 그때 하네스를 모델 교체에 유연하게 설계해 둔 팀과 특정 모델에 종속된 팀의 이행 비용 차이는 상당할 겁니다.

기술 전환기마다 반복되는 패턴이 하나 있습니다. 경쟁의 병목이 어느 레이어에 있는지가 바뀌면, 그 레이어를 다루는 역량이 곧 차별화 지점이 됩니다. 모델 성능이 평준화되는 국면에서 병목은 모델 자체가 아니라 모델을 붙여 쓰는 구조 쪽으로 옮겨갑니다. 어떤 모델을 고를지가 아니라 무엇을 어떻게 붙여 돌릴지가 결과를 가르는 상황이 늘어난다는 뜻입니다.

1인 사업자·소규모 팀이 지금 점검할 것들

이 두 가지 변화 — 모델 격차 축소와 학습 데이터의 법적 불확실성 — 는 대기업 전략 이슈처럼 보이지만, 실제로는 1인 사업자와 소규모 팀에게 더 직접적인 영향을 줍니다. 대기업은 리스크를 분산할 내부 역량이 있지만, 소규모 운영자는 잘못된 도구 선택 하나가 6개월치 작업 방식을 바꿔야 하는 상황으로 이어집니다.

도구 선택 시 저작권 리스크를 묻는 습관. 사용 중인 AI 도구가 어떤 학습 데이터 기반인지, 해당 기업이 데이터 라이선스 관련 소송에 노출돼 있는지를 한 번쯤 확인해 두세요. 지금 당장 사용이 금지되는 건 아니지만, 법원 판결 하나로 서비스 정책이 하루아침에 바뀔 수 있습니다. 클라이언트 납품물이나 유료 서비스에 AI 생성물을 포함한다면, 해당 도구의 이용약관 중 상업적 사용 조항과 학습 데이터 출처 공개 여부를 구분해서 확인해 두는 게 좋습니다.

하네스 개념을 실무에 적용하기. AI를 단발성 쿼리로 쓰는 것과 반복 작업 루프에 연결하는 건 다릅니다. 지금 본인의 작업 흐름에서 AI가 연속으로 개입하는 구간이 있다면 — 예를 들어 원고 초안 생성 → 검토 → 요약 → 발행 준비 — 그 흐름을 어떻게 묶고 각 단계 오류를 어떻게 처리할지를 명시적으로 설계해 보세요. 이 설계를 특정 모델에 묶어두지 않는 것이 핵심입니다. Prompt 구조와 실행 순서를 별도로 문서화해 두면, 나중에 더 나은 모델로 교체할 때 재작업 비용을 크게 줄일 수 있습니다.

오픈 모델 실험을 미뤄두지 말기. 클로즈드 API 하나에만 의존하고 있다면, 로컬 또는 저비용 오픈 모델을 한 가지 작업에만 테스트해 보는 것도 좋습니다. 성능 격차가 좁혀지는 속도를 직접 감지해 두는 게, 나중에 도구 전환 결정을 내릴 때 막연한 불안 대신 경험 기반의 판단으로 이어집니다.

모델이 좋아지는 속도보다 모델 주변의 레이어 — 실행 구조와 학습 데이터 적법성 — 가 경쟁 변수로 올라오는 속도가 더 빠른 지금, 도구를 고르는 감각보다 도구를 연결하는 설계 감각이 실무 경쟁력에서 차지하는 비중이 달라지고 있습니다.