▲

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

 (mastodon.social)
8P by GN⁺ 11일전 | ★ favorite | 댓글 1개
  • Joshua Rogers가 자신만의 AI 기반 도구 세트를 이용해 curl 코드베이스에서 대규모의 잠재적 문제 목록을 찾아냄
  • 이 목록에는 사소한 코드 스타일 결함뿐 아니라, 사소한 버그와 잠재적 보안 허점까지 포함
  • 찾아낸 문제는 대부분 작은 버그이나, 1~2개의 보안상 치명적인 결함일 수도 있음
  • 기존에 발견되지 않았던 문제점들이므로 실제로 매우 가치 있는 결과
  • 보고된 내용을 바탕으로 22건의 버그 수정이 이미 완료된 상태
  • 아직 두 배 이상의 확인되지 않은 이슈가 남아 있어, 계속해서 리뷰 및 수정을 진행 중
  • 상세 문제는 "Reported in Joshua's sarif data"로 표기되었으며, 관심이 있다면 해당 데이터를 직접 확인 가능함
▲
GN⁺ 11일전  [-]
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는 도구 세트로 묘사했지만, 실제로 도구를 사용한 기여자의 생각도 궁금함
  • 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 툴이 구체적으로 무엇이었는지 바로 파악하기 어려웠음
    기존에 여러 도구들이 버그를 못 찾았던 상황에서 이번 전략이 왜 더 효과적이었는지 궁금함
  • 관련성 있는 이슈로 "AI로 뭘 해놓고 본인이 뭘 하는지 모르는 경우" 사례를 소개함 You did this with an AI and you do not understand what you're doing here
답변달기