20년 전 첫 커밋을 날렸을 때만 해도 버그 트리아지는 신성한 의식이었다. 코드 한 줄이 시스템을 무너뜨릴 수 있는 시절, 개발자들은 이슈를 앞에 두고 마치 중세 의사처럼 진맥하듯 로그를 들여다봤다. “이건 메모리 누수야”, “아니, 레이스 컨디션 같은데” 하며 토론이 이어졌고, 때로는 새벽까지 이어진 회의 끝에 겨우 우선순위가 결정됐다. 그때는 그게 당연하다고 생각했다. 버그는 인간의 직관과 경험이 아니면 해결할 수 없는 신비로운 존재였으니까.
그런데 이제 AI가 그 신성한 의식을 자동화하겠다고 나섰다. 데빈(Devin)이라는 이름의 소프트웨어 엔지니어 에이전트가 깃허브 이슈를 읽고, 재현하고, 분류하고, 심지어 다른 데빈들에게 분배까지 한다. 기술 뉴스를 보면 마치 공장 컨베이어 벨트처럼 버그가 투입되면 해결된 PR이 출력되는 미래가 눈앞에 펼쳐진 듯하다. 하지만 이 기술이 가져다줄 진짜 변화는 효율성 향상이 아니다. 오히려 개발자의 역할 자체를 재정의할 잠재력을 품고 있다.
우리가 AI 트리아지를 반기는 이유는 단순하다. 버그를 처리하는 일이 지루하고 반복적이기 때문이다. 같은 이슈가 반복해서 올라오고, 이미 해결된 문제를 다시 검토하고, 우선순위를 매기느라 시간을 낭비하는 건 누구나 겪어본 고통이다. 하지만 이 지루함의 이면에는 중요한 진실이 숨어 있다. 바로 버그 트리아지가 개발자의 사고를 확장하는 훈련장이라는 사실이다. 로그를 분석하며 시스템의 약점을 파악하고, 사용자의 피드백을 통해 제품의 방향성을 고민하는 과정은 개발자를 단순한 코드 작성자에서 문제 해결사로 진화시킨다.
문제는 AI가 이 훈련장을 없애버릴지도 모른다는 점이다. 데빈이 모든 이슈를 자동 분류하고 재현한다면, 개발자는 더 이상 버그의 맥락을 깊이 이해하지 않아도 된다. 그저 AI가 던져주는 해결책을 기계적으로 적용하기만 하면 된다. 이는 단기적으로는 생산성을 높일지 몰라도, 장기적으로는 개발자의 문제 해결 능력을 퇴화시킬 위험이 있다. 마치 내비게이션에 의존하다 보면 방향 감각을 잃어버리듯, AI에 의존하다 보면 시스템 전체를 이해하는 능력을 잃어버릴 수 있다.
보안 운영에서 이미 이런 현상이 나타나고 있다. 같은 이슈가 반복해서 분석되는 ‘트리아지 데자뷔’ 현상은 AI가 해결해야 할 문제가 아니라, 인간이 시스템을 제대로 이해하지 못했기 때문에 발생한 결과다. AI가 이 문제를 해결하려면 단순히 이슈를 분류하는 수준을 넘어, 왜 이 문제가 반복되는지 근본 원인을 파악해야 한다. 그런데 그 근본 원인을 찾는 과정 자체가 인간의 사고를 요구한다.
더 큰 문제는 AI가 버그를 처리하는 방식이 인간의 그것과 근본적으로 다르다는 점이다. 인간 개발자는 버그를 발견하면 “왜 이런 현상이 발생했지?”라는 질문을 던진다. 이는 시스템의 구조, 설계 의도, 사용자 행동 패턴 등을 종합적으로 고려한 결과다. 반면 AI는 통계적 패턴과 과거 데이터를 기반으로 결정을 내린다. 예를 들어 데빈이 특정 버그를 “우선순위 낮음”으로 분류했다면, 그것은 그 버그가 과거에 자주 발생하지 않았기 때문일 수 있다. 하지만 그 버그가 실제로 치명적인 보안 취약점일 수도 있다. AI는 그 미묘한 차이를 놓칠 수 있다.
그렇다고 AI 트리아지를 무조건 반대할 이유는 없다. 오히려 이 기술을 개발자의 파트너로 활용할 방법을 찾아야 한다. 예를 들어 AI가 이슈를 분류하되, 최종 결정은 인간 개발자가 내리도록 하는 하이브리드 시스템을 구축할 수 있다. 이때 AI는 단순한 분류기가 아니라, 개발자에게 “이 버그는 A 패턴과 유사하지만 B 조건에서는 다르게 동작합니다” 같은 맥락 정보를 제공하는 어시스턴트 역할을 해야 한다. 이렇게 되면 AI는 개발자의 사고를 확장하는 도구가 될 수 있다.
가장 흥미로운 가능성은 AI가 개발자의 편견을 깨는 데 활용될 수 있다는 점이다. 인간은 종종 자신의 경험에 갇혀 문제를 바라보는 경향이 있다. 예를 들어 특정 모듈에서 자주 버그가 발생하면, 그 모듈 자체에 문제가 있다고 단정짓기 쉽다. 하지만 AI는 시스템 전체를 객관적으로 분석해 “실제로는 이 모듈보다 데이터베이스 연결 부분에서 문제가 더 자주 발생합니다” 같은 통찰을 제공할 수 있다. 이런 객관성은 개발자의 사고를 한 단계 더 끌어올릴 수 있다.
결국 AI 트리아지는 개발자에게 질문을 던진다. 우리는 코드를 작성하는 기계가 될 것인가, 아니면 문제를 해결하는 사고를 가진 엔지니어가 될 것인가. AI가 버그를 자동으로 처리해줄수록, 개발자는 더 높은 수준의 고민으로 나아가야 한다. 시스템 설계, 아키텍처, 사용자 경험 같은 본질적인 문제에 집중할 시간을 벌 수 있다면, AI는 축복이 될 것이다. 하지만 그저 AI가 던져주는 해결책을 기계적으로 적용하는 존재가 된다면, 우리는 결국 스스로의 가치를 떨어뜨리는 셈이다.
이 기술이 가져올 진짜 혁신은 버그 처리 속도가 아니라, 개발자의 사고 방식에 있다. AI가 버그를 고치기 전에, 우리는 먼저 버그가 AI를 어떻게 활용할 것인지 고민해야 한다. 그 고민의 끝에서 우리는 더 나은 개발자가 될 수도, 아니면 그저 더 효율적인 코드 작성자로 전락할 수도 있다. 선택은 우리의 몫이다.
관련 내용은 Devin AI의 자동 트리아지 시스템에서 확인할 수 있다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
