당신의 에이전트가 92%의 확신을 가지고 수정안을 건넵니다.

그 92%가 무엇을 의미하는지가 아니라, 무엇이 그 92%를 만들어냈는지 스스로에게 물어보십시오. 무엇이 그것을 생성했는지를 말입니다.

모델이 자신의 출력물에 대해 그 숫자를 작성한 것입니다. 아무것도 실행되지 않았습니다. 아무것도 파싱(Parsing)되지 않았습니다. 어떤 테스트도 실행되지 않았습니다. 그것은 언어 모델(Language Model)이 언어 모델의 제안에 대해 어떻게 느끼는지에 대한 언어 모델의 추정치일 뿐입니다. 그리고 그것은 컴파일러(Compiler)에서 나온 숫자와 동일한 폰트, 동일한 녹색 색상으로 표시됩니다.

디버깅 도구를 만들면서 제가 계속 생각했던 부분이 바로 이것입니다. AI의 수정안이 틀렸다는 뜻이 아닙니다. 대부분은 괜찮습니다. 문제는 좋은 수정안과 나쁜 수정안이 외관상 동일하게 보인다는 점입니다. 그래서 당신은 매번 모든 수정안을 주의 깊게 읽어야 하며, 이는 당신이 시간을 아끼려고 노력했던 대부분의 상황과 상충됩니다.

Stack Overflow의 2025년 개발자 설문조사에 따르면, 개발자의 84%가 AI 도구를 사용하고 있으며, 45%는 AI가 작성한 코드를 디버깅하는 것이 예상보다 오래 걸린다고 답했습니다. 또한 66%는 가장 큰 불만 사항으로 "거의 맞지만, 완전히 맞지는 않은" 답변을 꼽았습니다.

"거의 맞음"은 비용이 많이 드는 실패입니다. 명백하게 틀린 것은 5초면 비용이 발생합니다. 하지만 "거의 맞음"은 이미 그 코드를 기반으로 작업을 진행한 후, 세 개의 파일을 넘나들며 20분을 허비하게 만듭니다.

느낌 대신 필드(Field)

그래서 DebugAI는 모든 제안된 수정안에 대해 verified 필드를 반환하며, 여기에는 두 개가 아닌 세 가지 상태가 있습니다.

{
  "rank": 1,
  "title": "Add the missing import",
...

• **true**는 기계적 검사(Mechanical check)가 실행되었고 통과했음을 의미합니다.
• **false**는 검사가 실행되었으나 실패했음을 의미합니다. 실패한 검사 또한 당신이 원하는 정보이기 때문에, 수정안은 확신도(Confidence)가 제한된 상태로 여전히 제공됩니다.
• **null**은 아무것도 검증하지 않았음을 의미합니다. 이때의 확신도는 모델 자체의 추정치이며, 정확히 그 의미로만 읽혀야 합니다.

제가 고수하는 규칙은 null이 절대 false로 렌더링되지 않으며, 아예 아무것도 표시되지 않아서도 안 된다는 것입니다. "검증되지 않음"과 "검증되었고 문제없음"은 서로 다른 주장입니다. 이 둘을 하나로 합치는 것이야말로, 누군가 거짓말을 하기로 결정하지 않았음에도 도구가 거짓말을 하기 시작하는 방식입니다.

여기서부터 여러분 중 일부는 저를 놓칠 수도 있겠습니다.

두 가지 종류의 버그를 확인합니다. 그 모든 것 중에서.

버전 1은 정확히 두 가지 클래스를 다룹니다.

파싱(Parse). SyntaxError와 IndentationError. Python은 프로세스 내에서 ast.parse를 거칩니다. JavaScript는 임시 디렉터리에서 서브프로세스로, CPU 제한 2초 및 실시간 시계 제한 2초를 두고 node --check를 사용합니다. 이것은 수정안의 구문이 유효함을 증명합니다. 하지만 그 수정안이 올바른지에 대해서는 아무것도 증명하지 못합니다.

임포트(Import). ImportError와 ModuleNotFoundError. 이 것은 DebugAI가 요청을 위해 이미 검색한 파일들과 비교하여 이름 지정된 임포트를 해결합니다.

그리고 모든 이런 종류의 도구에 속해 있으면서도 거의 아무 곳에서도 볼 수 없는 문장이 있습니다. 임포트 확인이 패키지가 설치되었음을 증명하지는 않습니다. 엔진은 사용자의 실제 의존성 그래프(dependency graph)에 접근할 수 없습니다. 임포트 확인에서 verified: true라는 것은

덜 숭고하지만 두 번째 이유가 있습니다. Narrow는 테스트가 가능합니다. 결정론적 검사기 (deterministic checkers)를 가진 두 클래스는 CI에서 검증될 수 있습니다. 반면 "우리의 AI가 당신의 수정안을 검증합니다"는 불가능합니다.

샌드박스, 그리고 작동하지 않았던 두 가지

모델이 작성한 코드에 대해 node --check를 실행한다는 것은 당신이 작성하지 않은 입력값에 대해 서브프로세스 (subprocess)를 실행한다는 것을 의미합니다. 이는 제한(bounded)되어야 합니다.

현재 이를 제한하는 요소는 다음과 같습니다: 2초로 설정된 RLIMIT_CPU, 서브프로세스 호출에 대한 실시간 타임아웃 (wall-clock timeout), 그리고 해당 프로세스가 벗어날 수 없는 임시 디렉토리입니다.

우리가 2026-07-09에 가정이 아닌 경험적 근거를 바탕으로 시도했다가 되돌린 사항들은 다음과 같습니다:

RLIMIT_AS (주소 공간, address space)를 설정하면, 128MB에서 2048MB 사이의 모든 값에서 아주 사소한 파일임에도 불구하고 node --check가 멈추거나 uv_thread_create 어설션 실패 (assertion failure)와 함께 중단되었습니다. V8은 실제 힙 (heap) 사용량과 관계없이 시작 시 대규모 가상 주소 공간을 예약하므로, 엄격한 AS 제한은 대상 코드(candidate code)가 아닌 Node 자체의 초기화 과정과 충돌하게 됩니다.

**RLIMIT_NPROC**는 Linux에서 서브프로세스 단위가 아닌 실제 UID (real-UID)당 제한입니다. 이를 설정하면 엔진이 실행되는 사용자 계정 전체의 프로세스 및 스레드 생성이 제한되었습니다. 값이 16일 때 Node의 워커 스레드 (worker thread) 시작이 동일한 중단 오류와 함께 완전히 깨졌습니다. 어떤 값이든 이는 잘못된 도구입니다. 샌드박스화된 자식 프로세스가 아니라 전체 프로세스를 제한하기 때문입니다.

시스템 콜 (syscall) 수준의 네트워크 차단은 존재하지 않으며, 이는 실제적인 공백(gap)이자 문서에도 명시되어 있습니다. 이것이 허용되는 이유는 node --check가 대상 코드를 실행하지 않고 파싱만 하기 때문에, 이 경로 상의 어떤 것도 외부 호출을 할 수 없기 때문입니다. 소스 코드의 노트에는 향후 검사가 실제로 대상 코드를 실행해야 할 경우, 리소스 제한만으로는 충분하지 않으며 네트워크 네임스페이스 (network namespace)나 전용 저권한 UID가 우선적으로 필요하다고 명시되어 있습니다.

제가 제 샌드박스의 한계를 말씀드리는 이유는, 여러분이 곧 스택 트레이스 (stack traces)를 이곳으로 보낼 것이기 때문입니다. 실행하기 전에 무엇이 가능한지 알고 있어야 합니다.

사용법

DebugAI는 MCP 서버로 실행되므로, 어떤 MCP 클라이언트든 이를 호출할 수 있습니다.

npx -y @debugai/mcp setup

브라우저 로그인이 필요하며, 복사할 키는 없습니다. 발견되는 모든 MCP 클라이언트(Claude Code, Claude Desktop, Cursor, Windsurf, Zed, Gemini CLI, Cline)에 대한 설정을 작성하며, 먼저 각 파일을 백업한 다음 연결이 실제로 작동하는지 확인합니다.

작성 전 미리 확인하기:

npx -y @debugai/mcp install --dry-run

모든 흔적 제거하기:

npx -y @debugai/mcp uninstall

동일한 서버를 등록하는 VS Code 확장 프로그램도 있습니다. CLI가 모든 도구를 중복해서 제공하는 대신 기본적으로 VS Code를 건너뛰는 이유가 바로 이것입니다.

무료 티어는 카드 등록 없이 하루 10회의 디버깅이 가능합니다. Pro 버전은 월 $12입니다. 월 $9의 창립자 요금(founding rate)은 평생 유지되며, 2026년 9월 1일까지 신청할 수 있습니다.

제가 여러분이 이 글에서 실제로 얻기를 바라는 것

제품이 아닙니다. 이 분야(field)에 대한 통찰입니다.

만약 여러분이 개발자에게 제안을 전달하는 무언가를 만든다면, 유용한 질문은 "모델의 확신도가 얼마나 높은가"가 아닙니다. "무엇이, 혹은 어떤 것이 이것을 검증했는가"이며, 정직한 답변은 빈번하게 "아무것도 없다"입니다. 그렇게 말하십시오. 수정 사항 옆에 아무도 보지 않았음을 의미하는 초록색 92%를 표시하는 것보다, 회색의 "검증되지 않음"을 표시하는 것이 더 가치 있습니다.

저는 추측을 결과인 것처럼 꾸미기보다는 차라리 null을 보여주는 쪽을 택하겠습니다.

원문은 debugai.io에 게시되었습니다.