Grok Build를 마개조한 코딩 하네스 완성기

59.229.***.***
16

안녕하세요

바이브 코딩으로 바이브 코딩을 위한 하네스를 만들었습니다. 제작에는 대략 한달이 걸렸고요. 처음에 삽질을 계속 하다가 7월 16일에 공개한 Grok Build 소스코드를 쓰면서 수준이 한껏 올라갔습니다 (Ai에게 분석시켜 틀을 잡았습니다) 처음에는 소스코드만 참조하려다가 그록 빌드가 너무 마음에들어서 아예 그록 빌드 기반으로 바꿨습니다.

다른 사람들은 어떻게 하네스를 제작하는지 궁금하네요. 어쨌든 전 처음으로 목표한 스펙과 가시적인 성과가 나와서 기분이 좋습니다. 이에 여태까지 개발한 내용 공유하고자합니다. 누군가에게는 도움이 되면 좋겠네요

목표 : Qwen 27B를 쓸만하게 만들자

  1. 기존에 오픈코드를 사용해 하네스를 만들고 있었는데, 성능 자체는 생각보다 별로였습니다. 소스코드를 봐도 기능은 다양한데 가장 중요한 LLM 오케스트레이션 기능이 약점이네요. 서브 에이전트 맥락 유지가 안되니 각자 노는 느낌이고 그래서는 효용이 떨어집니다. 물론 플랜 모드는 아주 마음에 듭니다.

  2. 코덱스를 써보니.. 이건 노이즈가 증폭됩니다. 기능은 강력한데 그걸 이용해먹을 끈기있는 llm이 필요합니다. codex 5.6 sol 도 그렇고 luna도 그렇고 chat gpt 모델들은 기본적으로 끈기를 장착한 듯 하고요, qwen처럼 충동적인 모델은 노이즈와 루프에 빠져 허우적 거릴 때가 많습니다.

  3. 클로드 코드는 그래도 보기 좋은 결과물을 내놨는데 안 돌아가는 코드가 많네요. 뜯어보면 겉은 멀쩡한데 부실공사가 많습니다. (그래도 이게 어딘가). 그래서 이 부실공사를 메꿀려면 고급 API를 써야하고, 이렇게 하니 토큰 절약도 안되고 애매하네요. 근본적으로 클로드를 쓴다고 멍청한 모델이 똑똑해지는 것도 아니라서 토큰을 많이 쓰는데 비해 최종 마무리가 좀 어려웠습니다.

Grok Build의 특징

빠릅니다. 그리고 웬만한 코드는 오픈코드보다 품질이 좋네요. (이건 후술한 표에서도 드러남) 후발주자다보니 개발기간이 부족해 기능별로 기본기만 채운 느낌이 살짝 들기는 한데요, 오케스트레이션 만큼은 그록 헤비 시절이 있어서 그런지 매우 강력합니다. 즉 오케스트레이션을 위한 셋팅이 잘 되어있습니다.

단점 : 권한 설정은 좀 약한듯 합니다.예를들어서 오픈코드에 있는 서브 에이전트별 권한 부여 같은게 안되고 통합으로 전체적으로 권한을 처리하는 듯 합니다. (그래서 보안문제가 생기는 것 같아요 한 번 실수로 어디서 누수가 생기면 전부 뚫리는?)

그런데 말입니다. (중요) 그록 빌드에는 한가지 숨겨진 기능이 있습니다. 심지어 그록 스스로도 안 쓰는 네이티브로 벡터 메모리 기능이 내장되어있다는거죠. (문서에 보면 실험용이라고 써있음). 사용자가 적당한 벡터 임베딩 모델만 추가해주면 키워드 검색 뿐만 아니라 의미 벡터 검색으로 맥락을 유지할 수 있습니다. 시간 감쇄, MMR, 부스팅 등 다양한 옵션들이 다 구비가 되어있고요. 제가 구현하고 싶은 벡터 기반 맥락 유지 기능을 쉽게 만들 수가 있었습니다. 이 좋은걸 왜 숨겨놨는지 이해가 안 가네요

Grok은 벡터 메모리 기능을 안 쓰고 키워드 검색만 씁니다 (왜?) 클로드 코드도 그렇고요. 물론 외부 MCP로 확장할 수 있기는 한데 아쉽습니다. 아마도 실험실 기능 정도 되나봅니다

저는 여태까지 오픈코드를 개조해서 한땀한땀 힘들게 만들던 벡터 루프물(?) 알고리즘을 사용합니다. 구조는 말이되지만 가중치라든지 MMR이라든지 이런걸 어떻게 구현할까 고민이었는데.. Grok Build의 강력한 오케스트레이션 + 메모리 기능을 이용하니 좋네요. 역시 대기업 제품은 퀄리티가 다릅니다. 기존에 만들던 벡터 기반 루프를 초월이식하는데 딱 이틀이 걸렸습니다.

Codex CLI와 VectorBuild 1.1 코드 결과 비교

동일한 gpt-5.6-luna, reasoning high로 Terminal-Bench 2 문제 5개를 평가했습니다.

공식 테스트 채점

문제

Native Codex CLI

VectorBuild 1.1 Vector

비동기 작업 취소·SIGINT 정리

LLM 추론 배칭 스케줄러

영상에서 이륙·착지 프레임 검출

커스텀 메모리 힙 충돌

전용 포맷 압축 파일 생성

최종 점수

3/5, 60점

4/5, 80점

코드 정성평가

문제

Native 코드

VectorBuild 코드

비동기 작업 취소

7/10 — 구현 방향은 적절하지만 대기 중 작업과 SIGINT 정리가 완전하지 않음

8/10 — 자식 예외 감지와 실행·대기 작업 정리를 모두 구현해 더 견고함

배칭 스케줄러

7/10 — 동적 계획법으로 요구 조건을 충족하지만 일부 내부 구현 의존성이 있음

7/10 — 테스트는 통과하지만 공유 shape 값 하드코딩으로 일반성이 낮음

영상 프레임 검출

8/10 — 비공개 영상까지 통과했고 노이즈 대응도 안정적임

7/10 — 분석 구조는 좋지만 고정 임계값 때문에 비공개 영상에서 1프레임 오차 발생

힙 충돌 수정

9/10 — 작고 정확한 수정으로 문제를 해결함

9/10 — 필요한 파일만 최소 수정한 간결하고 정확한 해법

압축 파일 생성

4/10 — 제한 안에 검증 가능한 결과물을 완성하지 못함

8/10 — 2,277바이트 결과를 생성했고 디코딩 결과가 원본과 완전히 일치함

코드 품질 합계

35/50, 70점

39/50, 78점

최종 결과

| 공식 테스트 | 60점 | 80점 |

| 코드 품질 | 70점 | 78점 |

VectorBuild가 공식 테스트와 코드 품질 모두 앞섰습니다. Native는 영상 처리 코드의 일반화가 더 좋았고, VectorBuild는 비동기 정리와 압축 파일 생성처럼 다단계 검증이 필요한 문제에서 더 완성도 높은 결과를 냈습니다.

결론 : 토큰 2배 시간도 1.5배

하지만 조금 더 똑똑해짐

차이는 맥락 유지입니다. 경량 모델이어도 일단 코드는 잘 만듭니다. 하지만 맥락 유지가 안되면 코드 작성중에 삽질을 하고 전체 코드베이스가 스파게티처럼 꼬이게 되죠. 벡터 기반 메모리는 이런 머리나쁜(?) Ai에 암기력을 심어줍니다.

어쨌든 전 오픈코드나 코덱스로는 만들지 못하던 프로그램을 그록 빌드로는 만들 수 있었고. 이에 기분이 좋습니다. 이토록 좋은 프로그램을 공개로 풀다니 spacexai 에 감사합니다.

모두 즐 점심 되세요

로그인한 회원만 댓글 등록이 가능합니다.

개발한당

KR | ID | EN
  • IDR
  • KOR
7.96 -0.01

2026.08.14 KEB 하나은행 고시회차 1078회

다가오는 한인 행사일정

  • 등록 된 일정이 없어요!