AI 디버깅이란 무엇인가요?

1947년 9월 9일, Harvard Mark II 컴퓨터의 엔지니어들은 릴레이 중 하나에서 나방을 발견해 이를 로그북에 붙였습니다. 이 기록은 현재 스미스소니언 협회에 보관되어 있으며, ‘버그가 실제로 발견된 최초 사례’라고 적혀 있습니다.¹ Mark II 팀의 컴퓨터 과학자인 그레이스 호퍼(Grace Hopper)는 이 이야기를 널리 알렸지만, 버그라는 용어 자체는 호퍼 이전부터 사용되었습니다. 토머스 에디슨(Thomas Edison)은 1878년 편지에서 ‘버그(bugs)’를 언급하며 불평했고, 옥스퍼드 영어사전은 이러한 공학적 용례가 1870년대와 1880년대로 거슬러 올라간다고 설명합니다.²

엔지니어링 버그는 일반적으로 세 가지 유형으로 나뉩니다.³ 구문 오류는 프로그래밍 언어의 문법을 깨뜨리는 오류로, 괄호 누락 등이 그 예이며 프로그램이 실행되기 전에 발견됩니다. 런타임 오류는 유효한 코드가 실행 도중 실패할 때 발생하며, 0으로 나누는 경우가 이에 해당합니다. 논리 오류는 가장 발견하기 어렵습니다. 프로그램은 문제없이 실행되지만 잘못된 결과를 반환합니다.

개발자는 자동화된 테스트와 디버거를 사용해 이러한 문제에 대응할 수 있습니다. 자동화된 테스트에는 코드의 작은 각 부분이 예상 결과와 일치하는지 확인하는 단위 테스트가 포함되며, 디버거는 실행 중인 프로그램을 검사할 수 있도록 일시 중지합니다. 중단점은 실행이 멈추는 지점을 표시한 코드 줄로, 개발자는 프로그램을 한 단계씩 실행하며 변수를 검사할 수 있습니다. Python에 내장된 pdb가 대표적인 예입니다. 프로그램이 완전히 충돌하면 일반적으로 스택 추적이 생성됩니다. 스택 추적은 오류로 이어진 함수 호출을 보여 주는 보고서입니다.⁴

2013년 Cambridge Judge Business School의 연구에 따르면, 개발자는 평균적으로 프로그래밍 시간의 절반을 버그 탐색 및 수정에 사용하며, 이로 인한 전 세계 연간 비용은 약 3,120억 달러에 달합니다.⁵ 물론 AI 지원 디버깅은 이러한 비용을 줄일 수 있다는 가능성을 제시합니다.

LLM은 방대한 양의 텍스트와 코드로 학습되어 다음 ‘토큰’(단어, 단어 일부 또는 기호)을 예측하는 머신 러닝 시스템입니다. 이는 ChatGPT나 Claude 같은 AI 챗봇의 기반이 되는 자연어 처리 기술입니다. 학습 과정에서 LLM은 수십억 줄의 공개 코드와 함께 관련 오류 메시지, 버그 보고서 및 수정 사항을 사실상 ‘읽습니다’. LLM이 출시될 때쯤이면 수백만 개의 버그와 그 해결 방법을 학습했을 가능성이 큽니다. 

문서화된 공개 코드 학습 데이터에는 개발자가 버그와 수정 사항을 보고하는 기록인 GitHub ‘이슈’ 및 ‘풀 리퀘스트’ 대화가 포함됩니다. 이를 통해 특별히 학습된 모델은 결함이 있는 코드를 사람이 어떻게 수정하는지 보여 주는 기록에 액세스할 수 있습니다.

일반적인 AI 디버깅 워크플로에서 개발자는 모델에 관련 코드와 오류 메시지 또는 스택 추적을 제공합니다. 그러면 모델은 가능한 원인을 설명하고 수정 후보를 제안합니다. ChatDBG와 같은 연구 시스템은 한 단계 더 나아가 LLM을 GDB, LLDB 및 Python의 pdb 같은 표준 디버거에 연결합니다. 이를 통해 개발자는 모델이 실행 중인 프로그램을 검사하고, 근본 원인을 분석하며, 수정 사항을 제안하는 동안 “x가 null인 이유는?”과 같은 일반 언어 질문을 할 수 있습니다.6.

AI 디버깅을 처음 사용하는 사람이 알아야 할 몇 가지 한계도 있습니다. 먼저 프롬프트 엔지니어링과 관련된 맥락이 중요합니다. 모호한 프롬프트는 모호한 진단을 낼 가능성이 더 크므로, 정확한 오류, 실패한 테스트 및 문제가 의심되는 코드 부분을 제공하는 편이 더 유용합니다. 사용자는 모델이 한 번에 고려할 수 있는 최대 텍스트 양인 컨텍스트 윈도우도 알아야 합니다. 이는 각각 몇 개의 문자로 구성된 청크인 ‘토큰’을 기준으로 측정됩니다. 실제 GitHub 이슈를 바탕으로 한 SWE-bench 벤치마크가 보여 주듯, 복잡한 코드베이스의 실제 버그는 여러 파일에 걸쳐 있는 경우가 많습니다. 모델이 관련 코드를 모두 컨텍스트에 담을 수 없다면 이에 대해 추론하기 어려울 수 있습니다.

AI 디버깅은 일반적으로 개발자의 코딩 작업 공간에 내장되거나 이를 중심으로 구축된 AI 코딩 어시스턴트를 통해 이루어집니다. 이러한 작업 공간은 대개 통합 개발 환경(IDE)입니다. 예를 들어 GitHub Copilot은 널리 사용되는 IDE에서 코드 제안을 제공할 수 있는 코딩 어시스턴트입니다. Cursor와 Windsurf는 이와 유사한 지원 기능을 프로그래밍 경험의 중심에 더 가깝게 배치하는 AI 중심 코딩 작업 공간입니다.⁷ 또한 ‘에이전틱 엔지니어링’의 확산이 일반화됨에 따라, 일부 소프트웨어는 사용자가 IDE와 상호 작용하는 주된 창으로 코딩 어시스턴트의 채팅 창을 사용하도록 설계됩니다. 이는 IBM Bob을 사용하는 방법 중 하나입니다.

코딩 어시스턴트는 모델에 구애받지 않도록 설계된 경우가 많습니다. 예를 들어 GitHub Copilot은 OpenAI, Anthropic 및 Google을 비롯한 제공업체의 모델을 사용할 수 있습니다. xAI는 Grok Code Fast 1 모델이 코딩 에이전트 워크플로를 위해 구축되었으며 Copilot, Cursor 및 Windsurf를 포함한 도구를 통해 사용할 수 있다고 설명했습니다.^{8 9} IBM Bob은 다양한 모델을 사용하며 복잡성과 비용에 따라 적절한 모델로 쿼리를 자동 라우팅합니다. 2026년 릴리스 자료에서는 “코드 추론, 보안 및 다음 편집 예측을 위한 전문 미세 조정 모델과 함께 Anthropic Claude, Mistral 오픈 소스 모델 및 IBM Granite를 포함한 프론티어 모델 조합”을 언급합니다.

일부 AI 디버깅 에이전트는 범용형이며, 다른 일부는 전문형입니다. 범용형 분야에서는 2025년에 도입된 GitHub의 Copilot 코딩 에이전트에 GitHub 이슈를 할당할 수 있습니다. 이 에이전트는 GitHub Actions를 사용해 백그라운드에서 작업하고, 풀 리퀘스트(인간 개발자가 검토할 코드 변경 묶음)로 제안된 변경 사항을 제출할 수 있습니다.¹⁰ 여러 모델을 사용하는 IBM Bob도 범용형에 가깝습니다. 전문형에는 보안 취약점을 구체적으로 대상으로 하는 Copilot Autofix가 있습니다. Copilot Autofix는 GitHub의 코드 스캔 엔진인 CodeQL을 AI가 생성한 설명 및 수정 제안과 결합하는 방식으로 작동합니다. 시간 절감 효과는 상당할 수 있습니다. GitHub는 중앙값 기준 수정 시간이 28분인 반면, 수동 수정에는 1.5시간이 걸린다고 보고합니다.¹¹

생성형 AI 최전선의 성과는 인상적이지만, 고르지 않은 측면도 있습니다. IBM이 최근 2,000명의 최고 경영자를 대상으로 실시한 CEO 연구에 따르면, 최근 몇 년간 기대한 투자 수익을 달성한 AI 이니셔티브는 25%에 불과했습니다.

이러한 엇갈린 결과는 AI 디버깅에도 적용됩니다. 2024년 DebugBench 연구에서 연구진은 비공개 소스 모델이 전반적으로 여전히 사람의 성능에 미치지 못하며, 논리 오류는 구문 오류와 참조 오류보다 수정하기 훨씬 어렵다는 사실을 확인했습니다.¹²

하지만 더 나은 전문 도구가 전망을 개선하고 있습니다. 예를 들어 ChatDBG는 LLM을 실행 중인 디버거에 연결하여, 문제가 의심되는 코드 텍스트만 보는 대신 프로그램이 실패했을 때 정확히 무엇을 하고 있었는지 파악할 수 있도록 합니다. 한 평가에서는 ChatDBG에 한 번만 쿼리해도 Python 프로그램에 실행 가능한 수정 사항을 적용할 수 있는 경우가 67%에 달했습니다. 후속 질문을 한 번만 허용했을 때 이 비율은 85%로 높아졌습니다.¹³

상황을 더 복잡하게 만드는 점은 모델을 평가하는 기준이 끊임없이 변화한다는 것입니다. 유명한 SWE-bench¹⁴의 더욱 까다로운 후속 버전인 SWE-bench Pro는 더 현실적이고 데이터 오염에 강하도록 설계되었습니다. 최근 평가에서 최고 수준의 프론티어 모델은 여전히 25%에 미치지 못했으며, GPT-5는 23.3%를 기록했습니다.¹⁵  

개발자 행동은 과학적으로 측정할 수 있는 속도보다 더 빠르게 변화할 수 있습니다. METR의 2025년 초 무작위 대조 시험에 따르면, 경험이 있는 오픈 소스 개발자는 AI 도구를 사용할 때 작업 시간이 19% 더 길어졌습니다. 그러나 METR은 이 결과가 빠르게 최신성을 잃었다고 밝혔습니다. 2026년 후속 연구에서는 생산성 향상이 가속화되었다는 일부 증거를 확인했지만, 이러한 가속화를 정확히 측정하기는 어렵다고 덧붙였습니다.¹⁶ METR이 이 어려움을 설명한 내용은 시사하는 바가 큽니다. “AI 없이 일하고 싶지 않아 연구 참여를 선택하지 않는 개발자가 크게 증가한 것을 관찰했습니다. 이는 AI 지원으로 인한 속도 향상 추정치를 하향 편향시킬 가능성이 높습니다.” 

AI 지원 개발과 디버깅은 분명 사라지지 않을 것입니다. 하지만 현재로서는 AI 디버깅 도구를 신뢰할 수 있는 자동 조종 장치가 아니라 강력한 보조 도구로 이해하는 것이 가장 적절합니다. 이러한 도구는 스택 추적을 설명하고, 구문 오류를 포착하며, 수정 후보 패치를 빠르게 작성할 수 있습니다. 그러나 논리 오류, 복잡한 코드베이스 및 보안에 민감한 코드와 같은 가장 어려운 사례에는 코드베이스에 병합하기 전에 여전히 테스트, 중단점 및 수정 사항을 검토할 숙련된 사람이 필요합니다.