기능 목록은 AI 코딩 플랫폼을 선택하는 데 있어 좋지 않은 방법입니다.

결정은 다섯 가지 작업, 즉 저장소 온보딩 (repository onboarding), 제한된 코드 변경 (bounded code change), 테스트 실행 (test execution), 실패한 작업 진단 (failed-task diagnosis), 그리고 증거 검토 (evidence review)를 통과해야 합니다. 만약 플랫폼이 이러한 작업들을 관찰 가능하게 (observable) 만들지 못한다면, 모델의 품질도 워크플로 (workflow)를 구원할 수 없을 것입니다.

MonkeyCode는 AI 작업 실행을 관리형 개발 환경 (managed development environments), 모델 관리 (model management), 프로젝트 요구사항 (project requirements), 팀 워크플로 (team workflows), 그리고 셀프 호스팅 (self-hosted) 옵션과 결합하기 때문에 평가할 가치가 있습니다. 핵심 저장소는 AGPL-3.0 라이선스 하에 공개되어 있습니다.

주요 출처: MonkeyCode의 저장소 및 README, 2026년 7월 16일 검토.

공개 사항: 저는 MonkeyCode 사용자로서 저의 경험을 공유하는 것이며, 해당 프로젝트와 관련이 없습니다. 이 기사는 평가 프로토콜 (evaluation protocol)이며, 벤치마크 (benchmark)나 보안 인증이 아닙니다.

AGPL-3.0 저장소에서 가져온 MonkeyCode 공식 작업-워크스페이스 스크린샷. 출처: frontend/public/monkeycode-1.png.

제가 이 프로젝트를 후보에 올린 이유

MonkeyCode는 또 다른 자동 완성 (autocomplete) 확장 프로그램으로 포지셔닝되지 않았습니다. 공개된 아키텍처 (architecture)와 기능 세트는 다른 작업 단위(unit of work)를 목표로 합니다: 팀이 개발 요구사항을 제출하고, 이를 서버 측 환경 (server-side environment)에서 실행하며, 결과로 나온 작업과 산출물 (artifacts)을 검토하는 방식입니다.

병목 현상 (bottleneck)이 코드를 타이핑하는 것이 아니라 환경, 모델, 요구사항 및 검토를 조정하는 것이라면, 이러한 차이점은 매우 중요합니다.

현재 프로젝트에서 문서화하고 있는 내용은 다음과 같습니다:

• 브라우저 기반 온라인 사용;
• 빌드, 테스트 및 프리뷰 워크플로 (build, test, and preview workflows)를 포함한 서버 측 개발 환경;
• 중앙 집중식 AI 모델 및 작업 관리;
• 팀 협업 및 요구사항 관리;
• 네이티브 모바일 지원;
• 엔터프라이즈 네트워크 내부의 프라이빗 배포;
• AGPL-3.0 하의 공개 소스.

이러한 것들은 테스트를 해봐야 할 이유이지, 맹목적으로 배포해야 할 이유는 아닙니다.

5가지 작업 수락 테스트 (The five-task acceptance test)

합성 데이터 (synthetic data)가 포함된 일회용 저장소 (disposable repository)를 사용하세요. 시작하기 전에 MonkeyCode 버전 또는 커밋, 모델 (model), 베이스 커밋 (base commit), 그리고 환경 이미지 (environment image)를 고정 (pin)하십시오.

evaluation:
  repository: "synthetic/acceptance-fixture"
  base_commit: "<sha>"
...

첫 번째 평가 (evaluation) 단계에서 운영 환경의 자격 증명 (production credentials)이나 고객 코드를 넣지 마십시오.

1. 과도한 권한을 부여하지 않고 저장소 온보딩하기

피스처 (fixture)를 가져오고 요청된 모든 권한을 기록하십시오.

다음 질문에 답할 수 있는 경우에만 통과입니다:

• 플랫폼이 읽을 수 있는 저장소는 어디인가?
• 직접 쓸 수 있는가, 아니면 검토 가능한 변경 사항 (reviewable change)만 생성할 수 있는가?
• 자격 증명 (credentials)은 어디에 저장되고 주입 (injected)되는가?
• 작업이 공용 네트워크 (public network)에 도달할 수 있는가?
• 어떤 사용자가 작업을 시작했는가?

결과물은 성공적인 로그인이 아니라, 신뢰 경계 지도 (trust-boundary map)여야 합니다.

user -> MonkeyCode control plane -> task environment -> repository
                              |-> model provider
                              |-> artifact storage

셀프 호스팅 (self-hosting)의 경우, 데이터베이스, 객체 스토리지 (object storage), 이미지 레지스트리 (image registry), 인그레스 (ingress), 그리고 백업 경계를 추가하십시오. 설치 스크립트를 실행하기 전에 검토하고, 변경되는 원격 스크립트를 셸 (shell)에 직접 파이핑 (piping)하는 것보다 고정된 아티팩트 (pinned artifact)를 사용하는 것을 권장합니다.

2. 하나의 제한된 코드 변경 수행하기

하나의 허용된 파일과 하나의 금지된 파일이 포함된 이슈 (issue)를 생성하십시오:

목표: `pageSize`에 대한 검증 (validation) 추가.
허용됨: src/query.ts, test/query.test.ts
금지됨: deployment/**, .github/workflows/**
...

최종 디프 (diff)가 범위 내에 머물러 있거나, 권한 확장을 명확하게 요청하는 경우에만 통과입니다. 설명되지 않은 무관한 편집이 포함된 올바른 패치 (patch)는 수락 테스트 실패입니다.

기록:

{
  "baseCommit": "<sha>",
  "changedPaths": ["src/query.ts", "test/query.test.ts"],
...

3. 테스트가 실패할 수 있음을 증명하기

패치 전에도 이미 통과 상태였다면, 녹색(pass)으로 표시되는 테스트 스위트 (test suite)는 약한 증거에 불과합니다.

다음과 같은 회귀 테스트 (regression test)를 요구하십시오:

1. 기록된 베이스 커밋 (base commit)에 대해 실패함;
2. 후보 패치 (candidate patch)에 대해 통과함;
3. 의도된 경계 (boundary)를 실행함;
4. 기존의 어설션 (assertion)을 약화시키지 않음.

명령어 (command), 종료 코드 (exit code), 소요 시간 (duration), 그리고 정제된 출력값 (sanitized output)을 저장하십시오. 근거가 되는 데이터가 사용 가능한 상황에서 “모든 테스트 통과”와 같은 산문 형태의 요약 (prose summary)을 수락하지 마십시오.

4. 실패를 주입하고 복구 과정을 점검하십시오

의존성 URL (dependency URL) 하나를 깨뜨리거나, 테스트 전용 권한 (test-only permission) 하나를 제거하거나, 빌드 시간이 짧은 타임아웃 (timeout)을 초과하도록 만드십시오.

작업은 눈에 띄게 실패해야 합니다. MonkeyCode가 다음 사항들을 보존하는지 검토하십시오:

• 원래의 요구사항 (requirement);
• 베이스 리비전 (base revision);
• 실패 진단에 필요한 로그 (logs);
• 부분적인 아티팩트 (artifacts);
• 취소 상태 (cancellation state);
• 안전한 재시도 경로 (retry path).

장시간 실행되는 작업을 위한 플랫폼은 세련된 성공 화면뿐만 아니라 유용한 실패 상태 (failure state)도 필요합니다.

5. 증거로부터 의사결정을 재구성하십시오

작업을 시작하지 않은 검토자 (reviewer)에게 저장된 증거만을 제공하십시오. 그리고 그들에게 해당 변경 사항이 준비되었는지 결정하도록 요청하십시오.

검토자는 다음 사항들을 식별할 수 있어야 합니다:

• 누가 작업을 요청했는지;
• 저장소 (repository) 및 베이스 커밋 (base commit);
• 사용된 모델 (model) 및 환경 (environment);
• 변경된 파일들;
• 실행된 명령어 (commands);
• 이전에는 실패했으나 이후에는 통과한 테스트들;
• 해결되지 않은 경고 (warnings);
• 병합 권한 (merge authority)이 여전히 인간에게 있는지 여부.

만약 검토자가 무슨 일이 일어났는지 설명하기 위해 원래 작업자에게 물어봐야 한다면, 해당 워크플로 (workflow)는 아직 팀 단위로 사용할 준비가 되지 않은 것입니다.

결과 점수 산정

가중치 점수를 매기기 전에 엄격한 게이트 (hard gates)를 사용하십시오:

신원 (identity), 비밀 정보 (secrets), 리비전 바인딩 (revision binding), 또는 병합 권한 (merge authority) 중 단 하나라도 실패한다면 배포 (rollout)를 차단해야 합니다. 치명적인 경계 위반 사항을 친근한 점수로 평균 내어 뭉뚱그리지 마십시오.

엄격한 게이트를 통과한 후에는 운영 적합성 (operational fit)을 비교하십시오:

• 요구사항부터 검토 가능한 패치 (reviewable patch)까지 걸리는 시간;
• 수락된 변경 사항당 리뷰어 소요 시간 (reviewer minutes per accepted change);
• 작업 실패 및 재시도율 (task failure and retry rate);
• 환경 시작 시간 (environment startup time);
• 수락된 변경 사항당 모델 및 인프라 비용 (model and infrastructure cost per accepted change);
• 수동 정리 (manual cleanup)가 필요한 변경 사항의 비율.

이 지표들을 귀하의 저장소(repository)에서 측정하십시오. 저는 의도적으로 지어낸 숫자를 발표하거나, 특정 모델이나 배포 모드가 보편적으로 승리한다고 주장하지 않겠습니다.

온라인인가, 셀프 호스팅(self-hosted)인가?

온라인 서비스는 워크플로우 적합성을 테스트하기 위한 더 빠른 경로입니다. 네트워크 배치, 데이터 지역성 (data locality), 모델 라우팅 (model routing), 또는 인프라 제어가 필수 요구사항인 경우에는 셀프 호스팅이 더 강력한 후보입니다.

셀프 호스팅은 운영 소유권 (operational ownership) 또한 이전합니다. 현재 README에서는 콘솔의 경우 최소 2C / 4 GB / 40 GB, 개발 환경 호스트의 경우 8C / 16 GB / 100 GB를 권장합니다. 이는 프로젝트 권장 사항으로 간주해야 하며, 귀하의 워크로드에 대한 용량 보증이 아닙니다.

셀프 호스팅을 선택하기 전에 업그레이드, 백업, 자격 증명 순환 (credential rotation), 이미지 출처 (image provenance), 작업 격리 (task isolation), 관측 가능성 (observability), 그리고 사고 대응 (incident response)을 담당할 소유자를 지정하십시오. “우리 네트워크 내부에서 실행된다”는 것은 토폴로지 (topology)에 대한 진술일 뿐, 완료된 보안 검토가 아닙니다.

나의 권장 사항

팀이 로컬 코드 완성 (local code completion) 이상의 기능, 즉 중앙 집중식 작업 실행 (centralized task execution), 관리형 개발 환경 (managed development environments), 모델 선택 (model choice), 요구사항 추적 (requirement tracking), 협업 (collaboration), 또는 프라이빗 배포 (private deployment)가 필요할 때 MonkeyCode를 후보 목록에 올리십시오.

기능 매트릭스 (feature matrix)가 길다는 이유만으로 도입하지 마십시오. 앞서 언급한 5가지 작업이 리뷰어가 신뢰할 수 있고 플랫폼 팀이 운영할 수 있다는 증거를 생성할 때만 도입하십시오.

첫 번째 롤아웃 (rollout)은 하나의 합성 저장소 (synthetic repository), 하나의 제한된 작업 클래스 (bounded task class), 프로덕션 비밀 정보(production secrets) 없음, 자동 병합(automatic merge) 없음, 그리고 명시적인 종료 기준 (exit criterion)을 갖추어야 합니다. 데모가 아닌, 증거가 더 많은 권위를 얻은 후에 확장하십시오.

귀하의 환경에서 AI 코딩 플랫폼을 차단할 엄격한 게이트 (hard gate)는 무엇입니까: 네트워크 송신 (network egress), 자격 증명 처리 (credential handling), 리비전 바인딩 (revision binding), 아니면 인간의 병합 제어 (human merge control)입니까?