# Show GN: NambaAI - Codex 작업을 SPEC, 검증, PR handoff 흐름으로 정리하는 CLI 도구

> Clean Markdown view of GeekNews topic #29659. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29659](https://news.hada.io/topic?id=29659)
- GeekNews Markdown: [https://news.hada.io/topic/29659.md](https://news.hada.io/topic/29659.md)
- Type: show
- Author: [namcher9428](https://news.hada.io/@namcher9428)
- Published: 2026-05-19T23:29:04+09:00
- Updated: 2026-05-19T23:29:04+09:00
- Original source: [github.com/Nam-Cheol](https://github.com/Nam-Cheol/namba-ai)
- Points: 2
- Comments: 1

## Topic Body

Codex를 사용할 때 모호한 요청이 바로 코드 변경으로 이어지는 흐름이 불편해서, 이를 더 구조적인 개발 절차로 정리하는 CLI 도구를 만들고 있습니다.  
  
NambaAI는 Codex를 대체하는 도구는 아니고, Codex 주변에서 동작하는 워크플로 레이어에 가깝습니다.  
  
기본 아이디어는 다음과 같습니다.  
  
request → SPEC → execution → validation → PR handoff  
  
즉, 사용자의 요청을 바로 구현으로 넘기기보다 먼저 목표, 범위, 제약사항, 수락 기준을 정리하고, 이를 SPEC 파일로 남긴 뒤 작업을 진행하도록 돕습니다.  
  
현재는 다음 흐름을 중심으로 구성되어 있습니다.  
  
namba project  
namba plan "작업 요청"  
namba run SPEC-XXX  
namba sync  
namba pr  
namba land  
  
여러 SPEC을 순차적으로 처리하기 위한 queue 흐름도 실험하고 있습니다.  
  
이 도구를 만들게 된 이유는 AI 코딩이 편리해질수록 변경 과정이 추적되지 않거나, 어떤 기준으로 구현됐는지 나중에 확인하기 어려운 경우가 많았기 때문입니다. 특히 Codex를 반복적으로 사용하다 보면 “무엇을 하기로 했는지”, “어디까지가 범위였는지”, “검증은 어떻게 했는지”, “PR에서 무엇을 봐야 하는지”가 흐려질 수 있다고 느꼈습니다.  
  
NambaAI는 이 부분을 다음 방식으로 줄여보려는 시도입니다.  
  
- 작업 전 목표와 범위를 먼저 정리  
- 구현 전에 SPEC 파일 생성  
- 실행 결과와 검증 evidence 기록  
- PR handoff 문서 생성  
- Codex가 만든 변경사항을 사람이 리뷰하기 쉽게 정리  
- 단발성 프롬프트가 아니라 반복 가능한 개발 프로세스로 관리  
  
기존 AI agent framework처럼 범용 자율 에이전트를 만들려는 방향은 아닙니다. 현재는 Codex를 중심에 두고, 개발자가 검토할 수 있는 단위로 작업을 쪼개고 기록하는 쪽에 초점을 두고 있습니다.  
  
아직 초기 단계라 부족한 부분도 많습니다.  
  
- 실제 사용 예제 부족  
- 온보딩 문서 개선 필요  
- eval pack 부족  
- installer/hook 보안 검토 필요  
- macOS, Linux, Windows 교차 테스트 필요  
- 기존 AI coding harness와의 비교 부족  
- 실제 프로젝트에서의 검증 부족  
  
직접 만든 초기 오픈소스 프로젝트이고, 아직 완성도 높은 제품이라기보다는 방향성을 검증하고 있는 단계입니다.  
  
Codex를 실무나 개인 프로젝트에서 사용하시는 분들께 특히 아래 부분에 대한 피드백을 받고 싶습니다.  
  
1. 이런 SPEC 기반 Codex workflow가 실제 개발 과정에서 유용해 보이는지  
2. 어떤 부분이 과하게 설계된 것처럼 보이는지  
3. 실제 프로젝트에 적용하려면 어떤 신뢰 장치가 더 필요할지  
4. 비교해볼 만한 기존 도구나 패턴이 있는지  
5. 설치/사용 흐름에서 불편하거나 위험해 보이는 부분이 있는지  
  
비판적인 의견도 괜찮습니다. 아직 초기 단계라, 지금은 좋은 말보다 실제로 어디가 약한지 아는 것이 더 도움이 됩니다.

## Comments



### Comment 57844

- Author: namcher9428
- Created: 2026-05-20T00:03:10+09:00
- Points: 1

Cli를 목표로 만들었지만 저는 요즘 codex desktop에서 사용하고 있습니다 ! Codex desktop 내장 하네스랑 충돌이 있을까 걱정했는데 다행히도 호환히 아주 매끄럽습니다 ㅎㅎ  
  
이 외에도 이번 0.131.0 codex 업데이트 내용도 반영해야되고, 하네스는 이것만 사용하고 있어서 부족한 부분도 계속 보이지만 몸이 제일 부족하네요...