Claude Code가 저수준 암호 코드를 디버깅하다

• ML-DSA라는 NIST 지정 양자내성 서명 알고리듬의 Go 구현 과정에서 서명 검증이 실패하는 문제 발생
• Claude Code v2.0.28이 테스트 코드와 소스 경로만으로 복잡한 저수준 버그를 신속히 찾아냄
• 문제 원인은 Verify 단계에서 w1의 상위 비트를 중복 계산한 함수 병합 오류로 확인
• 이어진 두 번째 실험에서도 Claude가 Montgomery 상수 계산 오류와 서명 길이 불일치 버그를 각각 찾아냄
• 세 번의 시도 모두 성공적으로 버그를 식별해, AI의 저수준 디버깅 활용 가능성을 보여줌

---

ML-DSA 구현과 초기 문제

• 작성자는 NIST가 지정한 ML-DSA(Post-Quantum Signature Algorithm) 를 Go 언어로 새로 구현
  • 4일간의 라이브코딩 후 테스트에서 Verify 함수가 모든 서명을 거부하는 문제 발생
  • 테스트 로그에는 invalid signature 오류가 반복 출력됨
• 피로로 인해 디버깅을 중단하고, Claude Code에 문제를 분석하도록 요청

Claude Code의 첫 번째 디버깅

• Claude Code v2.0.28(모델 Opus 4.1, 시스템 프롬프트 없음)에 다음 정보를 제공
  • 테스트 실행 명령(bin/go test crypto/internal/fips140/mldsa)
  • 코드 위치(src/crypto/internal/fips140/mldsa)
  • “서명이 항상 거부된다”는 설명과 “w1이 다르다”는 힌트
• Claude는 몇 분 만에 완전한 수정 제안을 반환
  • 원인은 HighBits와 w1Encode를 하나로 합친 뒤, Verify에서 이미 상위 비트를 생성한 UseHint 결과에 다시 상위 비트를 취한 것
  • 즉, w1의 상위 비트를 두 번 계산한 구조적 오류
• Claude는 코드 로드를 마친 직후 원인을 파악하고, 자체 테스트를 작성해 가설을 검증
  • 제안된 수정은 완벽하지 않았으나, 핵심 원인 파악으로 디버깅 시간을 단축
• 이후 작성자는 w1Encode를 리팩터링해 상위 비트를 입력으로 받는 구조로 변경, Montgomery 표현 변환 과정도 단축

두 번째 실험: 서명 생성 단계의 버그

• 서명 생성 구현에서도 테스트 실패 발생
  • 첫 번째 버그: Montgomery 도메인에서 상수(1, -1) 계산 오류
    • 찾기 어려운 문제로, 수많은 printf와 추측이 필요했으며 약 1~2시간 소요
  • 두 번째 버그: 서명에 포함되는 값의 길이 오류(32비트 대신 32바이트)
    • 서명 길이 차이로 비교적 쉽게 발견
• 작성자는 이 두 버그가 Claude의 성능 검증에 적합하다고 판단하고, 이전 버전 코드로 Claude Code를 재실행

Claude Code의 두 번째 디버깅 결과

• 첫 번째 프롬프트에서 Claude는 printf 디버깅과 값 추적을 수행하며 잘못된 상수를 찾아 수정
  • 처리 시간은 인간보다 짧았으며, 테스트 실패 원인을 정확히 식별
• 두 번째 프롬프트에서는 서명 길이 불일치 문제를 찾아냄
  • Claude는 여러 경로를 탐색한 후, 할당 길이만 수정하는 제안을 제시
  • 제안된 수정은 완전하지 않았으나, 핵심 오류 위치를 정확히 지적
• 세 번의 독립적 시도 모두에서 Claude가 정확한 버그 원인을 단독으로 찾아냄

AI 디버깅의 효율성과 시사점

• Claude의 접근은 테스트 실패 원인 탐색에 특화된 자동화 도우미로서 효과적
  • 사용자는 Claude의 수정안을 그대로 적용하지 않고, 버그 위치만 확인 후 직접 수정
• 작성자는 “테스트 실패 시 자동으로 LLM이 원인을 분석해 알려주는 도구”의 필요성을 언급
  • 단순 채팅이나 자동 PR 생성보다 테스트 기반 디버깅 에이전트 형태가 이상적이라 평가

후원 및 기타 정보

• 작성자의 오픈소스 유지보수는 Geomys를 통해 지원받으며,
  Smallstep, Ava Labs, Teleport, Tailscale, Sentry 등이 후원
• Ava Labs는 암호 프로토콜의 지속 가능한 오픈소스 개발의 중요성을 강조
• Teleport는 사용자 계정 탈취 방지 및 접근 제어 강화를 위한 Teleport Identity 플랫폼을 소개

부록: 이미지 및 개인 언급

• 글에는 Microsoft Office의 클리피(Clippy) 가 “w1의 상위 비트를 두 번 취했다”는 말풍선과 함께 등장
• 마지막에는 고양이 사진이 포함되어 있으며, AI에 대한 감정적 논쟁을 완화하는 유머로 제시됨

[ajh508]

최근 triton이나 cuda 이용해서 gpu커널 개발을 좀 하고 있는데, 3.5만해도 제대로 실행되는걸 못보다가 4.5에서는 어느정도 제대로된 코드나 최적화를 해주는게 보이더라구요

[GN⁺]

Hacker News 의견

• 코딩 에이전트를 이용해 버그의 근본 원인을 추적하는 방식이 꽤 잘 작동함
  세 번의 원샷 디버깅 모두 성공했음. LLM이 코드를 직접 수정하는 게 아니라, 내가 스스로 판단하고 고칠 수 있도록 버그 위치만 알려주는 도우미 역할을 하는 게 핵심임
  이런 접근은 LLM 회의론자들에게도 좋은 출발점이 될 수 있음. 코드를 대신 작성하지 않고, 단지 골치 아픈 버그를 찾아주는 역할만 맡기면 됨

  • 이런 에이전트들이 너무 공격적으로 해결책을 찾으려다 본질을 놓치는 경우가 많음
    “이걸 고쳐야 한다”는 제안이 틀리진 않지만, 핵심과는 무관한 경우가 많음. 결과적으로 쓸데없는 수정 제안이 쌓이고, 주니어 개발자가 그걸 그대로 반영하면 불필요한 작업만 늘어남
    나도 이런 도구를 써보지만, 종종 “주니어에게 설명하느라 오히려 시간이 더 드는” 느낌을 받음
  • LLM이 알고리즘 버그에는 꽤 강하지만, 동시성 버그에는 약함
    테스트 생성도 알고리즘 쪽은 잘하지만, 동시성 상황에서는 한계가 있음. 그래도 “테스트 생성”이나 “디버깅” 용도로는 충분히 가치 있음
    코드 리팩터링이나 장기 유지보수 관점에서는 여전히 부족함
  • 개인적으로는 LLM이 취미 프로젝트에서는 훌륭했지만, 대규모 코드베이스에서는 덜 유용했음
    하지만 블로그에서 추천한 대로 버그 헌터로 써보니 놀라울 정도로 효과적이었음. 몇 주 만에 여러 생산 환경 버그를 잡아냈음
  • 내가 가장 좋아하는 활용법은 LLM에게 문서화 작업을 맡기는 것임
    코드를 본격적으로 파기 전에 관련 문서를 길게 써보게 하면, 실수가 있어도 부담이 적고, 회의적인 사람에게도 좋은 시작점이 됨
  • 버그를 찾고 고치는 과정은 개발자로서 가장 지적 만족감이 큰 일 중 하나임
    이 과정을 기계에 맡기면 아쉬울 것 같음. 버그 헌팅은 시스템 구조를 깊이 이해하게 하고, 장기적으로 더 나은 프로그래머로 성장하게 함
    이런 경험이 없으면 결국 자신의 코드 판단조차 LLM에 의존하게 될 위험이 있음

• 내 조언은 단 하나, AI First임
  먼저 AI에게 문제를 던져보면, 모델의 한계를 배우는 동시에 프롬프트 구조화 능력도 키울 수 있음
  최신 모델들은 대부분의 문제에서 동료처럼 다룰 수 있을 정도로 강력함. 다만 실패 패턴을 이해하고 직관을 쌓는 게 중요함
  새로운 모델 세대가 나올 때마다 기존 프로세스를 버리고, GPT-5-Codex나 Sonnet 4.5 같은 최신 모델로 실험해보는 걸 추천함

  • 하지만 “AI에게 먼저 던져보라”는 접근은 완전히 통하지 않음
    도메인 전문가라면 LLM의 환각과 오류를 구분할 수 있지만, 그렇지 않다면 오히려 시간 낭비가 됨
    결국 이 도구들은 전문가에게 가장 유용하고, 초보자에게는 품질이 들쭉날쭉함
    나도 Sonnet 4.5를 써봤지만, 이전 버전보다 약간 나아진 정도였음. 여전히 시간 낭비가 잦음

• Anthropic이 나에게 몇 달간 Claude Max를 무료로 제공했음
  최근엔 Instagram 광고에서도 Claude 관련 콘텐츠가 넘쳐남. “Claude Code 설치” 같은 광고가 계속 뜨는 걸 보면, 마케팅팀이 정말 열심히 일하는 듯함

  • 아마 제품-시장 적합성을 찾은 듯함
    개발자들이 Claude Code를 매우 유용하게 느끼고, 월 200달러 구독도 많음. 수익성이 있다면 마케팅에 돈을 쏟는 게 당연함

• LLM이 버그를 찾을 때 도움이 되지만, 엉뚱한 설명을 내놓아 시간을 낭비하게 만들기도 함
  결국 중요한 건 비판적 사고를 유지하는 것임

  • OP가 말한 건 “LLM이 아니라 내가 스스로 판단한다”는 의미였음
    LLM은 훌륭한 도구지만, 성급한 결론을 잘 내림. 사람이 생각을 멈추는 순간, 모델은 엉뚱한 방향으로 달려감

• “LLM을 채팅이나 자동완성 형태로만 쓰는 건 별로”라는 의견에 공감함
  나도 Claude Code/Codex를 쓰면서 비로소 가능성을 느꼈음. 지속적으로 실행되는 모드가 있다면 더 흥미로울 듯함

  • 채팅 UI는 느리고 비효율적이지만, LLM에게 시스템 접근 권한을 주는 건 보안과 프라이버시 측면에서 위험함
    실수로 파일을 지우거나 Git 저장소를 망칠 수도 있음. 그래서 나는 샌드박스 환경에서만 실험함
  • 나도 같은 생각임. 진짜 원하는 건 함께 코딩하는 코파일럿임
    모델이 내게 질문하고, 내가 직접 개입하며 배우는 소크라틱 방식의 협업 도구를 원함
    지금의 “자동화 중심” 접근은 개발자를 코드 문맹으로 만들 위험이 있음. 반대로 잘 설계하면 이해와 직관을 증폭시키는 도구가 될 수 있음

• CLI 터미널은 여전히 강력한 인터페이스임
  Gemini CLI나 Qwen Code는 무료이고, OpenAI 호환 API도 쉽게 붙일 수 있음.
  단순한 작업은 자동화하고, 어려운 부분은 Grok으로 원샷 처리하면 효율적임. CLI + MCP 서버 + MD 파일만으로도 똑똑한 프로그램을 만들 수 있음

  • Gemini CLI는 Claude Code나 OpenAI Codex와 비교해 어떤지 궁금함
  • 그래도 Claude Code의 UX는 정말 훌륭함

• 테스트가 실패할 때마다 LLM이 자동으로 원인을 분석하게 하는 아이디어가 흥미로움
  Git hook을 이용해 Claude CLI를 실행하면 가능함.
  예시와 치트시트는 이 가이드에서 볼 수 있음

  • 수동으로 실행하려면 간단한 Bash 스크립트로도 구현 가능함. 나도 재미 삼아 만들어볼 생각임

• 곧 LLM 학습 데이터에 대한 적대적 공격으로 암호학적 오류를 유도하는 사례가 나올 것 같음

• “수정이 완전히 새로운 함수 추가를 포함한다”는 건 암호 구현에서는 위험하다고 느낌
  글이 잘못된 조언을 주는 것 같음

  • 하지만 글의 요지는 LLM이 버그를 찾는 데만 쓰였다는 점임
    수정 코드는 버리고, 사람이 직접 작성했음. 오히려 보수적이고 책임감 있는 활용 사례로 보임
  • 글에서도 명확히 말했듯, 핵심은 해결책이 아니라 탐지 과정임
    LLM은 “수리공”이 아니라 가스 누출 탐지기처럼, 문제의 위치를 알려주는 도구로 쓰는 게 맞음

• LLM이 코드의 모호한 패턴을 인식해 지루한 문제를 많이 없앴음
  하지만 이게 부작용이 되기도 함. 내 코드베이스는 Node.js처럼 보이지만 실제로는 아니어서, 모델이 계속 Node 프로젝트로 오인함