# Claude Code가 저수준 암호 코드를 디버깅하다 > Clean Markdown view of GeekNews topic #24092. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24092](https://news.hada.io/topic?id=24092) - GeekNews Markdown: [https://news.hada.io/topic/24092.md](https://news.hada.io/topic/24092.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-02T15:32:51+09:00 - Updated: 2025-11-02T15:32:51+09:00 - Original source: [words.filippo.io](https://words.filippo.io/claude-debugging/) - Points: 2 - Comments: 2 ## Topic Body - **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에 대한 감정적 논쟁을 완화하는 유머로 제시됨 ## Comments ### Comment 45791 - Author: ajh508 - Created: 2025-11-02T17:01:45+09:00 - Points: 1 최근 triton이나 cuda 이용해서 gpu커널 개발을 좀 하고 있는데, 3.5만해도 제대로 실행되는걸 못보다가 4.5에서는 어느정도 제대로된 코드나 최적화를 해주는게 보이더라구요 ### Comment 45789 - Author: neo - Created: 2025-11-02T15:32:52+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45784179) - 코딩 에이전트를 이용해 버그의 **근본 원인**을 추적하는 방식이 꽤 잘 작동함 세 번의 원샷 디버깅 모두 성공했음. 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**를 실행하면 가능함. 예시와 치트시트는 [이 가이드](https://www.howtouselinux.com/post/the-complete-claude-code-cli-cheat-sheet-and-guide)에서 볼 수 있음 - 수동으로 실행하려면 간단한 **Bash 스크립트**로도 구현 가능함. 나도 재미 삼아 만들어볼 생각임 - 곧 **LLM 학습 데이터에 대한 적대적 공격**으로 암호학적 오류를 유도하는 사례가 나올 것 같음 - “수정이 완전히 새로운 함수 추가를 포함한다”는 건 **암호 구현**에서는 위험하다고 느낌 글이 잘못된 조언을 주는 것 같음 - 하지만 글의 요지는 LLM이 **버그를 찾는 데만** 쓰였다는 점임 수정 코드는 버리고, 사람이 직접 작성했음. 오히려 **보수적이고 책임감 있는 활용** 사례로 보임 - 글에서도 명확히 말했듯, 핵심은 **해결책이 아니라 탐지 과정**임 LLM은 “수리공”이 아니라 **가스 누출 탐지기**처럼, 문제의 위치를 알려주는 도구로 쓰는 게 맞음 - LLM이 코드의 **모호한 패턴**을 인식해 지루한 문제를 많이 없앴음 하지만 이게 **부작용**이 되기도 함. 내 코드베이스는 Node.js처럼 보이지만 실제로는 아니어서, 모델이 계속 Node 프로젝트로 오인함