Qwen Coder 실험 - "보조 프로세서 (co-processor)"로 사용하기

저는 90년대 초반의 게임을 디컴파일(decompile)하여 다시 컴파일하고, 새로운 .exe 파일 및 .html 버전의 게임 등을 만들 수 있도록 하는 개인 프로젝트를 진행 중입니다. 이 작업을 하면서 처음에는 ChatGPT를 사용했으나, 토큰(tokens) 소모가 너무 빠르고 제가 원하는 결과에 도달하지 못한다는 것을 발견했습니다. 그래서 저는 더 저렴한 DeepSeek으로 전환하기로 결정했습니다. 제가 하는 작업 중 일부는 GPT-5.5 수준의 깊이가 아니라 단순히 토큰만 많이 필요하기 때문입니다. 이 과정에서 Qwen Coder를 사용하면 개선될 수 있을지 확인해 보기로 했습니다. 이곳의 많은 분이 Qwen Coder가 유용하다고 계속 말씀하시더군요. 프로젝트의 병렬 개발을 위해 DeepSeek을 사용하여 Qwen Coder의 활용도를 높였을 때 제가 발견한 결과는 다음과 같습니다.

요약(TLDR): Qwen Coder를 무료로 사용할 수 있음에도 불구하고, 출력 결과물을 고려할 때 엣지 케이스(edge cases)에서만 가치가 있는 것으로 보이며, 실제로 DeepSeek을 통해 사용하는 것이 토큰 비용이 더 적게 드는 것보다 더 많이 들 수 있습니다.

시스템이 작성하도록 한 보고서는 다음과 같습니다 -

Qwen Coder를 코딩 사이드카(sidecar)로 강화하는 데 30분을 투자한 후, 직접 코드를 작성하는 것과 A/B 테스트를 진행했습니다

설정: RTX 3090, Ollama를 통한 qwen3-coder:30b, 메인 코딩 루프(Codex/Ralph) 내부의 서브 에이전트(sub-agent)로 실행.
문맥: 저는 1992년 DOS 게임을 역공학(reverse-engineering)하여 플레이 가능한 재구성 버전을 만들고 있습니다(완료되면 공유하겠습니다. 이는 어밴던웨어(abandonware)입니다). 저는 제가 검증 및 수정을 진행하는 동안 Qwen이 병렬로 Python 코드를 생성하도록 돕기를 원했습니다. 기존의 래퍼(wrapper)는 Qwen을 조언 전용 출력(advisory-only output)으로 강력하게 제한하고 있었습니다. 즉, Codex에게 어떤 파일을 조사해야 할지는 알려주지만 실제로 코드를 생성하지는 않았습니다.
저는 래퍼를 강화하는 데 30분을 보낸 후, Qwen의 도움을 받는 경우와 받지 않는 경우에 대해 동일한 코딩 작업을 A/B 테스트했습니다.

강화(Hardening) 문제
기존 래퍼(Ralph/Qwen sidecar)는 안전을 최우선으로 설계되었습니다:
· 강제된 조언 형식: Qwen은 TASK_UNDERSTANDING → VERIFIED_FACTS → FILES_TO_INSPECT → HYPOTHESES → IMPLEMENTATION_PLAN → VALIDATION_PLAN → RISKS → UNSUPPORTED_CLAIMS_AUDIT 순서로 반환하도록 지시받았습니다.

심지어 "이 함수를 작성해줘"라고 요청했을 때도, "Codex가 combat.py를 검사한 다음 함수를 작성해야 합니다"라고 답변했습니다.
· 고정된 시드 (seed 7) 및 온도 (temperature) 0.1 설정: 모든 호출에서 동일한 출력이 생성되었습니다. 반복 작업이 무의미했습니다.
· 과도하게 공격적인 거부 가드 (rejection guard): "for example"이나 "such as"와 같은 문구가 포함되면, Qwen이 프롬프트의 증거를 올바르게 반복하고 있는 상황임에도 거부 반응을 일으켰습니다.
· 최대 출력 토큰 2048개: 실제 코드 생성(code generation)을 하기에는 너무 제한적이었습니다.

변경 사항

항목	변경 전	변경 후
출력 형식	권고(Advisory)만 수행	--DIRECT 플래그 사용 시 권고를 건너뛰고, "generate output" 시스템 프롬프트와 함께 프롬프트를 원문 그대로 전송
온도/시드	0.1, seed=7 (결정론적)	0.35, 시드 없음 (호출마다 결과가 다양함)
최대 토큰	2048	32768
거부 가드	"for example", "such as" 차단	"might be named", "could be called"만 차단
검증 (Verification)	없음	모든 출력에 VERIFICATION 섹션 포함

강화(hardening) 후의 결과는? 래퍼(wrapper)가 처음으로 Python 코드를 생성했습니다. 올바른 레이아웃, 색상 및 입력 처리를 포함한 100줄 이상의 완전한 Pygame 실행기(runner)를 만들어냈습니다.

A/B 테스트

동일한 전투 해결 모듈(combat resolution module)을 두 가지 다른 방식으로 연결했습니다:

**패스 A: Qwen 사용 (--DIRECT 모드)

1. 전투 API 및 필요한 함수에 대한 상세한 프롬프트와 함께 Qwen을 실행했습니다.
2. Qwen이 생성하는 동안(90초), 기존 런타임 코드를 검토했습니다.
3. Qwen은 올바른 구조를 가진 괜찮은 100줄 규모의 스캐폴드(scaffold)를 반환했습니다.
4. 하지만 수정해야 할 7가지 이슈가 있었습니다: 누락된 임포트(import), 사용되지 않는 데드 변수 (hit = True), 단일 몬스터 대상 지정만 가능, 잘못된 로그 소스, 잘못된 상태 딕셔너리(status dict) 형식.
5. 이를 수정하고, 테스트를 작성하여 실행기에 통합했습니다.

• 나의 소요 시간: 약 4분. Qwen 소요 시간: 약 1.5분 (병렬 작업).*

**패스 B: Qwen 미사용

1. 제1원칙(first principles)에 따라 동일한 전투 모듈을 작성했습니다.
2. 상태 관리를 위해 깨끗한 dataclass를 사용하고, 승리/패배 쿼리를 위해 프로퍼티(properties)를 사용했습니다.
3. 테스트를 작성하고 실행기에 통합했습니다.

• 나의 소요 시간: 약 3분. Qwen 소요 시간: 0.*

결과

지표	Qwen 사용 시	Qwen 미사용 시
신규 코드 라인 수	150 (100 + 50 수정)	93
수정할 버그 수	7	0
나의 Codex 토큰 비용	약 3k 토큰 ($0.08)	약 2k 토큰 ($0.06)
Qwen 토큰 비용	$0 (로컬)	$0 (해당 없음)
총 소요 시간 (Wall time)	약 4분	약 3분

이 작업에 대해 Qwen을 사용한 버전은 측정 가능한 모든 면에서 약간 더 좋지 않았습니다. 스캐폴드 (scaffold) 덕분에 타이핑 시간을 약 90초 절약했지만, Qwen의 가정을 진단하고 수정하는 데 그보다 더 많은 시간이 소요되었습니다. Qwen을 사용하지 않은 버전이 더 깔끔하고, 코드 양도 적었으며, 첫 시도에 정확했습니다.

Qwen이 실제로 도움이 되었던 경우 (테스트 초기 단계)

테스트 단계 초기(이 A/B 테스트 이전)에 Qwen은 완전한 Pygame 러너 스캐폴드(window init, 렌더링 구조, 색상 상수, 입력 스켈레톤, 이벤트 텍스트 오버레이)를 생성했습니다. 그 스캐폴드는 다음과 같은 이유로 진정으로 유용했습니다:

· 100라인 이상의 보일러플레이트 (Boilerplate, 로직보다 구조 중심)였습니다.
· "오류"는 대부분 API 불일치(ReconstructedData.from_generated() 대신 ReconstructedData()라고 작성함)였으며, 이를 수정하는 데 몇 초밖에 걸리지 않았습니다.
· 렌더링 루프 스켈레톤을 처음부터 직접 타이핑할 필요가 없었습니다.

여기서 얻은 경험칙: Qwen은 정확도(correctness)보다 구조(structure)가 더 중요한 작업, 즉 대규모 UI 스캐폴드, 보일러플레이트가 많은 모듈, 데이터 포맷 덤퍼(data format dumpers)에 가장 적합합니다. 집중적인 로직(<100 라인)의 경우, 처음부터 직접 작성하는 것이 더 빠릅니다.

진정한 병목 현상

기존의 래퍼 (wrapper)가 너무 과하게 제약되어 있어서 Qwen이 유용한 결과물을 생성할 수 없었습니다. 제약을 풀고 난 후 Qwen은 유용한 것을 만들어냈지만 감독(supervision)이 필요했습니다. 컴팩트한 전투 모듈의 경우 시간 절약 효과가 마이너스였지만, 더 큰 러너 스캐폴드의 경우 플러스였습니다.

제한 요인은 모델의 품질이 아닙니다. 모든 출력물은 신뢰하기 전에 인간의 검토가 필요하며, 작은 모듈의 경우 검토 시간이 작성 시간보다 더 오래 걸린다는 점입니다. 효율성의 손익분기점은 약 150~200라인의 보일러플레이트 지점이라고 추정합니다.

시작하기 전에 알았더라면 좋았을 것들

조언 전용(advisory-only) 래퍼 패턴은 코딩에 있어 Qwen의 유용성을 떨어뜨립니다. 만약 당신의 사이드카(sidecar)가 코드 대신 FILES_TO_INSPECT를 반환한다면, 코드 생성 용도로 잘못 사용하고 있는 것입니다.

직접 출력 모드(direct-output mode)를 추가하세요.

반복(iteration)을 위한 고정 시드(fixed seed)를 제거하세요. 0.1의 온도(temp)와 시드 7을 사용하면 모든 호출이 동일한 출력을 반환합니다. 시드가 없으면 반복을 통해 다양성을 확보할 수 있으며, 가장 좋은 결과를 선택할 수 있습니다.

거절(rejection)을 과도하게 방어하지 마세요. "예를 들어(For example)"는 LLM이 확답을 피하기 위해 사용하는 방식이며, 이는 환각(hallucination)이 아닙니다. 명시적인 허구 패턴(explicit invention patterns)만을 잡아내세요.

컴팩트한 작업의 경우, 그냥 직접 작성하세요. 프롬프팅(prompting) + 대기 + 검토 + 수정에 드는 오버헤드는 약 100라인 미만의 작업에 대해서는 직접 타이핑하는 시간보다 더 오래 걸립니다.

[이 작업은 qwen3-coder:30b가 실행되는 로컬 3090 환경에서 수행되었습니다]
제출자: /u/jzatopa
[링크] [댓글]