실제 작업 과제를 사용한 Nemotron 3.5 Bolt 평가

저는 신규 모델을 실제 업무 과제를 주어 평가합니다. 이 과제들은 이미 신뢰할 수 있는 모델이 완료했던 작업들입니다. 저의 일반적인 워크플로우는 Gemini에서 태스크/요청을 계획하고, 수행해야 할 작업과 승인 기준(acceptance criteria)을 간략하게 설명하는 마크다운 명세서(spec-sheet)를 작성한 다음, 이를 새로운 pi.dev 세션에 붙여넣어 모델이 따르도록 하는 것입니다. 이번 경우에는 Nemotron 3.5 Bolt에게 제가 실제 업무(데이터 엔지니어)로 진행하고 있는 ETL 리팩토링 작업에서 Qwen Flash Next (UD-IQ4_XS, llama.cpp)가 완료했던 두 가지 과제를 주었습니다. 이 두 과제는 '바다를 끓이는' 수준의 어려운 과제는 아니지만, 제가 LLM에 위임하는 업무 유형을 보여줍니다. 두 과제의 핵심 지침은 다음과 같습니다: 1. 기존 Python 가상 환경(venv) 해결 로직을 유지하면서, run-new.sh에 정의된 디자인 패턴, 플래그 관리, 구조화된 로깅, AWS SNS 오류 처리에 맞게 run.sh 스크립트를 리팩토링합니다. 2. 시간 간격(일별 또는 월별, 실행 시 인자 기반)의 순서를 생성하고 각 기간마다 run.sh를 순차적으로 호출하는 orchestrator.py라는 Python 스크립트를 작성합니다. 이 역시 엄청나게 어렵거나 까다로운 과제는 아니지만, 제가 접하게 되는 유형의 일들입니다: 클라이언트가 사용하는 확립된 패턴에 맞게 스크립트를 업데이트하거나 일부 작업을 자동화하는 것입니다. 새로운 모델이 작업을 완료한 후, 저는 명세서, 관련 파일(원래 run.sh 및 run-new.sh), 그리고 두 모델의 결과를 Gemini에 로드하여 성능을 평가하고 우승자를 선정하도록 요청합니다. 태스크 #1 (run.sh 리팩토링)에서는 Gemini가 Nemotron이 더 나은 작업을 수행했다고 판단했습니다. 다음은 명세서와 비교하여 리팩토링된 스크립트를 상세히 비교한 Gemini의 내용입니다. Model 1은 Nemotron이고 Model 2는 Qwen Flash Next입니다: `` Text 1. 디렉토리 경로 지정 (LOG_DIR vs SCRIPT_DIR) - Model 1: 상단에 SCRIPT_DIR=$(cd dirname ${BASH_SOURCE[0]} && pwd)를 정의하고, LOG_DIR로 $SCRIPT_DIR/logs를 사용합니다. .

이것은 로그가 스크립트 디렉터리 기준으로 생성되도록 보장합니다. 어느 위치에서 스크립트를 호출하든 상관없습니다. - Model 2: 상단에 LOG_DIR="$(pwd)/logs"를 정의하고 SCRIPT_DIR의 정의를 파일 후반부로 미룹니다. 만약 사용자가 /tmp에서 /path/to/run.sh를 호출하면, Model 2는 애플리케이션 디렉터리가 아닌 /tmp/logs에 로그를 생성합니다.

플래그 파싱 및 인자 전달 (Flag Parsing & Argument Forwarding)
두 모델 모두 while / case 루프를 사용하여 동일하고 강력한 인자 파서를 구현했으며, 모든 필수 플래그(-o, -x, -s, -e, -i, -b, -h, -d)와 그 긴 형식의 등가물을 올바르게 구문 분석합니다. 두 모델 모두 요구사항 2를 엄격히 준수하여 CLI 인자를 환경 변수로 불필요하게 내보내지 않았습니다.

오류 처리, 트랩 및 프로세스 실행 의존성 확인 (Error Handling, Traps & Process Execution Dependency Checks):
Model 1은 출력을 리디렉션하기 전에 필수 바이너리(tee, aws)의 존재 여부를 확인합니다. Model 2는 tee가 존재하는지 확인하기 전에 프로세스 치환(process substitution) >(tee -a ...)을 사용하여 출력을 리디렉션합니다.

• exec 동작 (exec Behavior):
  • run-old.sh는 exec "$VENV/bin/python" ...를 사용했습니다.
  • Model 2는 exec를 유지하지만, exec가 실행 중인 셸 프로세스를 Python으로 대체하기 때문에, 셸에 정의된 모든 trap ... EXIT은 Python이 완료될 때 우회됩니다. Model 1은 exec를 제거하고 Python을 자식 프로세스로 호출하여, 종료 시 셸 트랩이 깔끔하게 정리되도록 합니다.

결론 (Conclusion)
Model 1 (run-model1.sh)이 더 우수한 리팩토링입니다. 이는 모든 수용 기준을 준수하고, 로그 디렉터리를 pwd가 아닌 SCRIPT_DIR에 올바르게 루트화하며, 설정 작업을 논리적으로 순서화(프로세스 치환 사용 전에 tee 확인)하고, 트랩을 깔끔하게 관리합니다.

In task #2 ( orchestrator.py build) Gemini judged Qwen Flash Next to have done a better job. Here is Gemini's detailed comparison of the python scripts judged against the specifications in the spec-sheet, Model 1 is Nemotron and Model 2 in Qwen Flash Next:
``
**Text 1. Specification Compliance ( subprocess.run )**
*   Model 1: `subprocess.Popen`을 사용하여 스트림 파이핑(stream piping)을 구현하며, `stdout=subprocess.PIPE` 및 `stderr=subprocess.STDOUT`을 사용합니다. 이는 로그를 스트리밍하지만, 프로세스 읽기 루프와 리턴 코드를 수동으로 관리해야 합니다.
*   Model 2: `subprocess.run(cmd, check=True)`를 사용하여 사양 지침을 엄격히 따릅니다. 스트림 캡처 인자를 생략함으로써 자식 프로세스는 부모의 stdout/stderr를 네이티브로 상속받아 실시간으로 로그를 스트리밍하며, Python이 프로세스 수명 주기를 깔끔하게 처리하도록 합니다.

**견고성 및 파일 경로 처리 (Robustness & File Path Handling)**
*   Model 1: `./run.sh`가 스크립트가 실행되는 현재 작업 디렉터리(CWD)를 기준으로 위치한다고 가정합니다.
*   Model 2: `run.sh`를 스크립트의 디렉터리(`Path(__file__).resolve().parent /

제가 얻은 결론은 Nemotron 3.5 Bolt가 제 작업에 적합한 모델이며, 게다가 서버에서 빠르다는 장점이 있다는 것입니다. 평균 속도가 약 130t/s로 측정되었는데, 이 정도의 성능을 2-bit 양자화(quant)로 달성했다는 점이 인상적입니다. Qwen Flash Next를 완전히 대체하지는 못할 것이며, 특히 크고 복잡한 레포지토리 수준의 작업에서는 그렇지 않을 것입니다. 하지만 모든 것을 너무 깊게 생각하지 않으면서 빠르게 처리하고 싶은 가벼운~중간 난이도의 작업을 위해서는 Gemma4-31B를 대신할 가능성이 높습니다. 곧 M5 Mac Studio를 장만하게 되어 에이전트/서브에이전트 워크플로우를 구축하고 싶고, Bolt가 Qwen Flash Next(바라건대 Qwen4)가 사양을 전달하여 구현하는 서브에이전트로 정말 좋을 것 같습니다. submitted by /u/CulturalKing5623 [link] [comments]