curl에서 AI 도구로 발견된 잠재적 문제들

Hacker News 의견

• 내가 생각하는 'AI 코딩 동반자'의 이상적인 모습임
  코드를 직접 작성하거나 고쳐주는 대신, 코드에서 의심스러운 부분과 내가 더 자세히 살펴봐야 할 위치를 알려주는 역할을 원함
  Claude에게 내 2만 줄짜리 C 라이브러리의 버그를 찾아달라고 하면, 파일을 쪼개서 특정 코드 패턴을 grep 하는 방식으로, 결국 내 FIXME 주석만 나열해줌(웃음)
  사실 단순한 bash 스크립트가 할 수 있는 수준이고 꽤 실망스러움
  ChatGPT는 그보다 더 쓸모가 없는데, 그냥 "다 좋아보여요! 대단해요! 하이파이브~"만 반복함
  지금까지 실제 버그를 찾는 데에는 전통적인 정적 분석이 훨씬 도움되었지만 정적 분석이 깨끗하다고 논리적 버그가 없다는 뜻은 아님
  바로 이 지점에서 LLM이 빛을 발해야 한다고 생각함
  만약 LLM에서 더 유용한 잠재적 버그 정보를 얻으려면 엄청나게 맞춤화된 환경을 만들어야 한다면, 정적 분석 도구도 복잡한 설정이 요구될 때 잘 안 쓰이는 것처럼 결국 쓰임이 떨어짐
• 많은 프로그래머들이(특히 반복적인 코드 빼고) 직접 설계하고 코딩하는 걸 좋아하는 반면, 코드 리뷰하는 걸 선호하지 않는다는 점은 거의 논의되지 않음
  AI가 코드를 작성하고 프로그래머는 리뷰만 하라는 방향은 어딘가 잘못된 흐름 같음
  물론 "코드 라인 수가 증가합니다~" 방식으로 판매하려는 이유는 이해함
• Claude에게서 언급된 것처럼 실망스러운 결과가 나오면, 종종 "어떤 프롬프트가 효과적일지 Claude 본인에게 직접 물어보는" 방법이 잘 통함
  예를 들어 "Claude Code에게 FIXME, TODO 같은 주석은 무시하고 논리적 버그를 효과적으로 리뷰하는 계획을 세우도록 하려면 어떤 프롬프트를 써야 하나요?"라고 물음
  결과 프롬프트가 길어서 여기엔 못 쓰지만 gist로 공개된 예시에서 볼 수 있음
  그 결과를 토대로 계속 개선해서 에이전트로 만들 수도 있음
• Cursor BugBot이 이런 역할에 꽤 잘 맞음
  무료 체험 후에 우리 개발팀 내에서 인기가 좋아서 정식으로 도입했음
  가끔 잘못 감지하는 경우를 빼면 매우 유용함
  PR 작성자와 리뷰어 모두 시간 절약 효과가 큼
• Claude에게 "특정 엔드포인트에서 응답 속도가 느린 버그가 있는데 CPU/메모리 사용량 또는 DB와 연관성이 없다, 원인이 뭘까요?"라고 질문하면 몇 번 반복 끝에 정말 찾기 힘든 버그 힌트를 얻었던 경험 있음
  기존에는 몇 시간이나 걸렸을 문제를 단서를 받고 해결했던 적이 있음
  이런 식의 AI 활용 가능성에 기대감 큼
• GPT-5는 이런 상황에서 이전 모델들보다 훨씬 아첨하지 않음
  '모든 게 좋아 보여요' 같은 답변이 나온 점이 좀 놀람
  Codex CLI에서 사용할 때는 종종 의문을 제기해줌
  Gemini 2.5 Pro도 이 부분 괜찮음
• curl과 AI 이야기로 긍정적인 에피소드가 나올 줄은 정말 예상 못 했음
  히스토리를 참고하면 좋을 듯 curl+AI 관련 HN 검색 링크
• Daniel Stenberg가 AI 버그 리포트 관련해서 과거 여러 가지 문제를 겪었음에도 이번에 너그러운 태도로 접근한 점, 정말 대단하다고 생각함
• '도구 세트'라는 점이 포인트로 보임
  자동 조종 장치로 착각하지 않고, 제대로 도구들 조합해서 시스템처럼 쓰고 있음
• 기고자가 본문에서 더 많은 상세 설명을 담았을 것 같음
  참고 블로그 (Mastodon 언급: 관련 링크)
• 논의가 "자율주행 vs. 방임" 같은 이분법적 구도로 축소된 것에 아쉬움
  결국 제대로 이해하고 쓰는 사람 vs. 단순 분위기로 코딩하는 사람의 차이로 좁혀지는 관점이 맞는 듯
• Stenberg는 도구 세트로 묘사했지만, 실제로 도구를 사용한 기여자의 생각도 궁금함
• AI는 본질적으로 비결정론적임
  결과가 예측불가능하다는 의미
  그러니까 AI로 버그를 만드는 대신 문제를 찾게 해야 함
  그리고 AI가 감지한 인사이트를 바탕으로 결정론적 탐지 도구(예를 들어 단순, 짧고 이해하기 쉬운 스크립트, 파일명/라인/종료코드 포함)를 만들게 해야 함
  이런 방식으로만 AI의 불확실함을 반복적이고 검증 가능하게 전환할 수 있으며, 이 툴을 CI에 통합해 오래 유지하면 같은 실수를 반복하지 않게 됨
• curl 저장소에서 "sarif data"를 언급한 55개의 closed PR이 있는데, 이번에 언급된 PR들이 바로 이 그룹임
  Daniel Stenberg가 과거 AI가 만든 엉성한 오탑보안 이슈에 시달렸던 것과 대조적임
  HackerOne 관련: "AI가 만든 쓰레기 이슈 신고자는 바로 밴 처리함. 사실상 DDoS 공격 수준임. 시간 낭비에 대해 청구라도 하고 싶을 정도"
  올해 1월 Daniel의 블로그 글도 참고: The I in LLM stands for Intelligence?
• 일부 버그(예: size_t에서 잘못된 printf 포맷 지정자 사용)는 컴파일러 warning 플래그만 잘 설정해도 감지됨
  "중요한 컴파일러 경고 플래그가 빠져있습니다"라고 AI가 조언해주는 건 꽤 쓸모 있을 것임
  일부 PR은 dependabot 일치 때문일 것 같고, "Joshua sarif data"로 검색하면 더 구체적인 PR 목록을 볼 수 있음 링크
• 당시 사용된 모델들이 많이 발전한 듯 보임
  Daniel Stenberg의 인상이 바뀐 이유로 추측함
• 상용 SAST 스캐너 중에는 좋은 것도 있지만 대부분은 만족스럽지 않음
  AI 기반 SAST 기술을 도입하자는 주장이 많고 실제로 관련 제품도 출시되고 있지만, 대다수는 아직 기대 이하임
  실망만 해도 다행이고, 잘못하면 잘못된 보안에 대한 믿음이 생겨서 위험함
  AI 기반 SAST 스캐너에 대한 비판적 시각 및 근거는 여기에서 소개
• AI 툴이 구체적으로 무엇이었는지 바로 파악하기 어려웠음
  기존에 여러 도구들이 버그를 못 찾았던 상황에서 이번 전략이 왜 더 효과적이었는지 궁금함
• 제품 관련 챕터가 있는 블로그에서 좀 더 정보 찾을 수 있음
  Mastodon 링크는 잘못된 코드 스니펫이 있어도 진짜 버그가 맞다는 확인용으로 추정함
• 관련성 있는 이슈로 "AI로 뭘 해놓고 본인이 뭘 하는지 모르는 경우" 사례를 소개함 관련 댓글
• 이 사례가 마음에 듦
  관련 Mastodon 링크
  요약: "코드는 맞지만 네이밍이 틀렸다"
• Rust로 다시 쓰라는 이야기가 나올 거라 생각했는데, 오히려 요즘 그런 반응이 뜸함
  혹시 이제 분위기가 바뀐 건가 하는 농담 섞인 의문임