Qwen3.8-27B-Fable-5-Coding-Distilled 모델 분석: '확인 후 수정' 기능의 진실성을 파헤치다

Nokka (นก-กา) 작성 | 2026년 10월 9일

본 기사는 AI(deepseek-v4.1-flash)가 Hermes Agent를 통해 작성했으며, Nokka (นก-กา)의 인간 검토 및 품질 관리 하에 있습니다.

최근 개인 장치에서 AI를 구동하는 사용자들 사이에서 하나의 모델이 유행하고 있습니다. 많은 사람들이 이 모델을 코딩 전문 모델의 진정한 경쟁자로 칭찬하며 공유하고 있습니다.

그 이름은 Qwen3.8-27B-Fable-5-Coding-Distilled로 매우 길며, Ollama나 LM Studio에 로드할 수 있는 일반적인 GGUF 파일과 비슷한 외관을 하고 있습니다.

하지만 사람들이 종종 놓치는 부분이 하나 있습니다. 바로 'Fable 5'라는 이름이 Qwen 팀에서 나온 것이 아니라는 점입니다.

이 작업은 누가 무엇을 했는가

이름을 분해해서 보면, 이 프로젝트는 세 팀의 손을 거쳤다는 것을 알 수 있습니다.

첫 번째 단계는 Qwen3.8-27B입니다. Alibaba가 2026년 8월 초에 Apache 2.0 라이선스로 발표한 모델로, 약 27조 개의 파라미터를 가진 텍스트와 이미지를 모두 처리할 수 있는 dense 모델입니다[1].

두 번째 단계는 khazarai 팀이 이 기본 모델을 가져가 코딩 및 에이전트적(agentic) 버그 수정에 특화되도록 추가 학습(fine-tune)시킨 것입니다[2].

세 번째 단계는 mradermacher가 그 결과를 일반 사용자들이 로컬 장치에서 편리하게 실행할 수 있도록 GGUF 파일로 변환한 사람입니다[3].

따라서 누군가

기반 모델은 스크립트에 무언가 있을 수 있다고 신중하게 작성하지만, 파일이 아직 보이지 않는다고 인정하다가 결국 추측으로 해결책을 제시하며 도구를 호출하지 않습니다.

이 차이가 바로 이 작업의 소유자가 1억 9,500만 토큰 규모의 데이터셋이 강조하기 위해 만들어졌다는 주요 신호라고 말하는 부분입니다[2]。

데이터 수치 및 출처

참고된 학습 데이터셋은 에이전트의 대화와 작업 흔적을 모아 놓은 것으로, 2,380개의 트래젝토리(trajectories)와 12,490개의 학습 행(training rows)으로 구성되어 있습니다[4]。

분류별로 가장 큰 그룹은 도구 호출(tool calling) 694개 트래젝토리이며, 그 다음이 명령 수행(instruction following) 559개, 시스템 생성(system generation) 312개입니다. 디버깅 작업만 따로 280개가 있습니다[4]。

반드시 읽어야 할 부분은 데이터의 출처입니다. 배포자는 메타데이터 페이지에 명확히 machine-generated라고 기재하여, 실제 인간 개발자의 작업 기록이 아니라 기계가 생성한 것임을 밝혔습니다[4]。

같은 페이지에는 Claude Fable 5 세션이 문제 탐색부터 도구와 논쟁하고 최종 답변을 내놓는 전 과정을 담아 수집되었다고 쓰여 있습니다.

분리해야 할 핵심 포인트는 '실제 데이터에서 수집된 모델의 세션'과 '개발자로부터 얻은 실제 버그 기록'이라는 두 가지가 서로 다른 영역이라는 점입니다.

배포자는 또한 검수 절차도 설명했습니다. 즉, 코딩 작업 세션은 지정된 테스트를 통과하고 수정이 금지된 파일을 통과해야 하며, 명령 수행 세션은 도구 호출 및 답변 제한에 대한 검사를 거쳐야 한다는 것입니다[4]。

여기에 추가로 사고 노력의 깊이를 단계적으로 낮추는 메커니즘도 있습니다. 만약 심층적으로 생각한 라운드가 검사에 통과하지 못하면, 중간 수준과 낮은 수준으로 내려가고, 그중 가장 먼저 통과된 라운드를 기록합니다[4]。

이 모든 과정 덕분에 '검사를 통과했다'는 말이 실제로 무게를 가지게 되었지만, 이것이 데이터셋 제작자의 기준을 통과했다는 의미일 뿐, 답변 내용 자체가 100% 정확하다는 보증은 아니라는 점을 이해해야 합니다.

실제 파일 크기 열한 단계

가장 많이 질문하는 수치는 파일 크기인데, 이것이 우리 장비로 구동할 수 있는지를 결정하기 때문입니다.

GGUF 라이브러리에는 가장 작은 Q2_K부터 Q8_0까지 총 열한 단계의 파일이 제공됩니다[3]

• Q2_K: 10.86 기가바이트
• Q3_K_S: 12.26 기가바이트
• Q3_K_M: 13.50 기가바이트
• Q3_K_L: 14.56 기가바이트
• IQ4_XS: 15.42 기가바이트
• Q4_K_S: 15.83 기가바이트
• Q4_K_M: 16.81 기가바이트
• Q5_K_S: 18.97 기가바이트
• Q5_K_M: 19.54 기가바이트
• Q6_K: 22.43 기가바이트
• Q8_0: 29.05 기가바이트

같은 저장소에는 f16 크기 0.93 기가바이트와 Q8_0 크기 0.63 기가바이트인 mmproj 파일 두 개도 있습니다[3].

mmproj 파일이 있다는 것은 기본 모델이 이미지를 처리할 수 있음을 의미하며, 순수 텍스트 모델이 아님을 보여줍니다. 이는 기본 모델이 스스로를 image-text-to-text라고 명시한 것과 일치합니다[1].

khazarai 팀도 자체 GGUF 저장소를 공개했지만, Q8_0 크기 28.60 기가바이트만 있습니다[5]. imatrix 형태를 원하는 사람들을 위해 별도의 저장소도 마련되어 있습니다.

파일 크기가 필요한 RAM과 같지 않은 이유

왜 Q2_K가 실제로는 2비트가 아닌가

KV cache: 사람들이 자주 놓치는 부분

이것은 제가 가장 많이 오해하는 지점이라고 생각합니다.

Q2_K 크기 10.86 기가바이트인 파일이 가중치당 몇 비트를 사용해야 하는지 역으로 계산해 봅시다.

params   = 27e9          # 기본 모델의 파라미터
file_gb  = 10.86         # 실제 Q2_K 파일 크기
bits_per_weight = file_gb * 8 * 1e9 / params
...

파일 이름은 2비트라고 하지만, 실제 파일을 계산해 보면 약 3.2비트에 가깝습니다. 이는 모든 레이어가 동일하게 압축되지 않았음을 의미합니다.

임베딩(embedding) 및 출력 레이어와 같이 품질에 민감한 부분은 더 높은 해상도로 유지되는 경향이 있으며, 어텐션(Attention) 및 피드 포워드(Feed Forward) 레이어는 더 강하게 압축됩니다. 이로 인해 전체 파일 크기가 이름에서 제시하는 것보다 커지게 됩니다[3].

따라서

실제 config 값으로 계산하면, full attention 레이어는 16개이고 Key-Value 헤드가 4개이며 각 헤드는 256 차원을 가집니다[1]

full_layers, kv_heads, head_dim = 16, 4, 256
per_tok = 2 * full_layers * kv_heads * head_dim * 2   # K 및 V가 2 바이트
print(per_tok * 1000 / 1e6)   # 토큰당 65.5 MB
...

48개의 linear attention 레이어는 자체적인 상태를 가지고 있지만, 이는 컨텍스트 길이에 따라 증가하지 않는 고정된 크기이며, full attention 레이어가 저장하는 메모리보다 훨씬 작습니다[1]。

이 수치에는 운영체제와 모델 실행 프로그램의 공간은 포함되지 않았습니다.

명확한 예를 들자면, Q4_K_M을 사용하고 컨텍스트를 32,768 토큰으로 설정할 경우, 약 19GB 이상의 총 RAM이 필요합니다.

만약 파일 크기를 한 단계 낮춘 Q3_K_M(13.50 GB)을 선택하고 컨텍스트 8,192 토큰에 대한 KV 캐시(약 0.54 GB)를 더하면, 총 약 14GB로 실행할 수 있습니다.

하지만 수만 토큰에 달하는 긴 컨텍스트를 사용하거나 Q6_K와 같은 고해상도 파일을 긴 컨텍스트와 함께 사용하려면, 16GB 그래픽 카드는 부족하기 시작하며 더 많은 RAM을 가진 장비로 이동해야 합니다.

모델 페이지가 아직 준비되지 않은 부분

확인이 필요한 빈칸

자체 테스트 결과 없음

여기는 솔직하게 말해야 할 부분인데, 이 내용들이 모델 페이지 안에 있습니다.

이번 작업의 모델 페이지에는 배포 전에 정보를 채워야 한다는 경고 메시지가 남아있습니다. 기반 모델로부터 라이선스 계승 여부, 데이터셋 구성 요소 및 출처, 학습 시 파라미터, 사용된 하드웨어에 대한 확인이 필요하다고 명시되어 있습니다[2]。

일부 칸에는 '기반 모델에서 상속(inherit)'이라고 자체적으로 표기되어 있고 괄호 안에 실제 값을 확인해 달라는 요청까지 있습니다.

학습 방식 칸도 아직 비어있으며, SFT 또는 LoRA 중 무엇인지 명확하게 지정되지 않았습니다.

가장 중요한 것은 이 모델 페이지에 자체 테스트 결과가 전혀 없다는 것입니다. 기반 모델이나 다른 모델과 비교하는 벤치마크 표가 없습니다.

제가 언급한 수치들, 예를 들어 SWE-bench Pro에서 61.7점 또는 LiveCodeBench에서 90.3점 같은 점수[6]는 모두 기반 모델인 Qwen3.8-27B의 점수이며, 이번에 추가 학습된 버전의 점수가 아닙니다.

이 부분은 반드시 구분해야 합니다. 그렇지 않으면 우리가 실수로 추가 학습 작업에 그들이 수행하지 않은 점수를 부여하게 될 수 있습니다.

실제로 사용해 본 사람들도 자체적으로 테스트 결과가 없다고 말하고 있습니다.

실제 사용자들의 목소리

두 명의 사용자 보고서

모델 페이지에는 사용자들이 직접 보고한 두 개의 대화 스레드가 있습니다. 이는 추측이 아닌 실제 사용 경험에서 나온 가장 가치 있는 정보입니다.

첫 번째 사용자는 xmesaj2라는 이름으로 9월 말에 글을 올렸는데, 모델이 수정 작업을 하기 전에 분석하는 데 시간을 들인다는 점과 그로 인해 감소한 반복 횟수(number of rounds)가 명확하게 보였다고 이야기했습니다. 즉, 모델이 이해하기 전에는 바로 수정을 시작하지 않는다는 것입니다[7]。

그는 또한 이 버전이 다른 모델보다 문서를 더 자주 읽어들이며, 아직 루프에 빠지는 현상은 겪지 않았다고 언급했습니다.

사용 장비는 Mi50 그래픽 카드 32GB를 사용했으며, mx-llama.cpp와 테스트용 ROCm 버전을 통해 컨텍스트 길이 65,000 토큰과 Q6_K 파일로 구동했다고 합니다[7]。

그는 이 모델이 Qwen3.8-27B에서 파생된 모델들 중 코딩에 가장 적합한 선택지라고 결론 내렸습니다.

다만, 이는 테스트 결과가 아니라 자신이 시도해 본 다른 버전들과의 비교일 뿐이라고 스스로 강조했습니다.

두 번째 사용자는 newbieai2025라는 이름으로 9월 말에 보고했는데, 약 6천만 토큰 분량의 긴 작업을 3시간 이상 연속으로 수행했음에도 모델이 잘 작동했고, 루프에 빠지거나 반복적인 사고를 하지 않았으며, 자신의 결과를 신중하게 검토했다고 합니다[8]。

그가 지적한 점은 자신이 사용한 버전이 BF16이라 일반 구동에는 너무 무거우니, 팀 측에서 FP8 버전을 만들어 달라는 요청이었습니다.

주목할 만한 점은 두 보고 모두 긍정적인 사용자 경험이지만, 특정 하드웨어에 기반한 두 명의 사용자 사례일 뿐이며, 이 모델이 다른 모델보다 체계적으로 우수하다는 통계적 증거는 아니라는 것입니다.

결정을 내리기 전에 알아야 할 세 가지 사항

하나: 데이터셋 출처가 모호함

둘: 쌍으로 존재하는 데이터셋이 무언가를 알려줌

셋: 알아두면 좋은 산업별 컨텍스트

첫 번째 이야기: 데이터셋 출처의 모호성

모델 페이지에서는 DSFFGFG456/fable-5-coding-and-debugging-traces[2]라는 데이터셋으로 학습되었다고 주장합니다. 하지만 해당 데이터셋의 README 페이지를 열어보면, 인용(citation) 부분이 greghavens/fable-5-coding-and-debugging-traces[4]라는 다른 계정을 가리키고 있습니다.

직접 greghavens 주소를 확인했을 때, 글을 작성한 시점에는 로그인해야 접근할 수 있었고 공개적으로 읽을 수 없었습니다[9]。

결론적으로, 현재 실제로 열람 가능한 데이터셋은 DSFFGFG456 계정 아래의 것이며, 언급된 원본 출처는 현재로서는 접근 불가능합니다.

데이터셋 작성자 계정에는 'synthetic-corrections[10]'이라는 이름의 또 다른 세트가 있습니다. 이 세트는 합성적으로 수정되어 검증된 흔적이며, 원래 데이터셋에서는 기준을 통과하지 못한 흔적들을 가져와 재검토한 것입니다.

현재는 트랙토리 1개에 데이터 행 2줄로 매우 작은 규모이지만, 작성자는 이 세트가 아직 성장 중이라고 밝혔습니다.

이 세트의 존재는 우리가 본 2,380개의 트랙토리가 전부 생성된 것이 아니라, 기준을 통과한 부분만 모인 것임을 알려줍니다. 기준에 미달하는 것은 분리되어 별도의 처리 과정을 거치고 있습니다.

세 번째: 알아두면 좋은 산업적 맥락

이 데이터셋은 Anthropic의 모델인 Claude Fable 5 세션에서 생성되었습니다.

이는 이 작업을 비난하려는 것이 아니며, 작성자가 메타데이터와 출처를 명확히 공개했기 때문에 그렇습니다. 다만, 한 모델의 결과를 가져와 다른 모델을 학습시키는 행위가 업계에서 주목받는 사안임을 맥락적으로 설명하는 것입니다.

Anthropic 자체도 2026년 2월에 Claude의 능력이 산업적 수준으로 추출되는 현상을 발견했다고 발표했습니다. 이 과정에서 가짜 계정 약 24,000개를 통해 1,600만 건 이상의 대화가 생성되었으며, 이는 서비스 이용 약관을 위반한 것입니다[11].

이후 2026년 9월에는 10일 동안 약 5,000개의 계정 네트워크를 통해 Claude에 거의 30만 건의 요청이 전송되었다는 보도가 있었습니다. 이 요청들은 주로 Opus 모델을 겨냥한 것이었습니다[12].

이 수치들은 다른 회사들의 것이며, 본 작업의 것은 아닙니다. 하지만 이것이 바로 다른 모델에서 정제된 작업을 상속하는 과정이 작성자 자신조차 확신하지 못하고 모델 페이지에 확인용으로 남겨두는 이유입니다[2]

그럼 시도해 볼 만 할까요?

기기에 적합한 파일 선택 방법

만약 우리의 목표가 AI에게 코드베이스를 읽게 하고, 버그의 원인을 찾거나, 테스트 스위트를 수정하거나, 혹은 자신이 소유할 수 있는 코드를 작성하는 에이전트를 만드는 것이라면 이 모델을 시도해 볼 만합니다.

신중하게 고려해야 할 점은 GGUF 파일을 기기에 맞게 선택하는 것입니다. 단순히 파일 크기만 보지 말고 KV 캐시와 시스템 메모리까지 염두에 두어야 합니다.

앞서 계산했듯이, 16GB 그래픽 카드는 사용 맥락에 맞춰 파일을 잘 선택한다면 아직 충분합니다. 하지만 수만 토큰 단위의 긴 컨텍스트를 사용하고 싶다면 더 많은 RAM을 가진 기기로 옮기거나, 파일 크기를 줄이는 대신 품질 저하를 감수해야 합니다.

그리고 한 가지 더 말씀드리자면, 이 모델이 코딩의 왕이라고 하는 칭찬을 당장 믿지 마세요. 저희가 직접 프로젝트에 적용해보기 전까지는요. 왜냐하면 공식적인 테스트 결과가 아직 없고, 좋은 평가를 남긴 사용자들 역시 특정 하드웨어에서 몇몇 사용자들에 국한되어 있기 때문입니다.

이 모델이 정말 당신의 작업에 적합한지 알고 싶다면, 가장 확실한 방법은 자신의 프로젝트에서 실제 작업을 두세 가지 가져와서 테스트해보고 현재 사용 중인 모델과 비교 측정해보는 것입니다.

그렇다면 여러분은요? 이렇게 이름이 길어서 끝까지 읽기 힘든 새로운 모델을 만났을 때, 다운로드하기 전에 확인하는 자신만의 방법이 있나요?

AI가 코드를 작성할 수는 있지만, 병합(merge)되는 코드에 대해 검토하고 책임을 지는 사람은 여전히 사람입니다.

참고 자료