TL;DR

  • 바이브 코딩은 빠르게 작동하는 제품을 만들 수 있지만, 이해의 단계가 빠지면 개발자는 자신이 관리해야 할 시스템의 지도를 잃게 됨.
  • Anthropic의 무작위 대조 시험은 개발자 52명 전체를 대상으로 진행됐으며, 그중 절반은 AI 지원을 받았고 AI 지원 그룹은 개념 퀴즈에서 17% 낮은 점수를 기록함.
  • AI 지원 개발자 중 높은 점수를 받은 사람들은 코드 생성에 그치지 않고 접근 방식과 실패 상황, 값의 출처를 계속 질문했으며, 이 과정에서 86%에 도달함.
  • Microsoft Research와 CMU의 조사에서는 AI 결과물에 대한 신뢰가 높을수록 보고된 비판적 사고가 줄어드는 경향이 나타났으며, 오류를 채팅창에 곧바로 붙여 넣는 방식은 다른 업무와 언어에도 통하는 디버깅 역량을 약화시킴.
  • Ninchi는 AI 생성 코드를 검증하는 대신 개발자가 코드 변경을 이해했는지 질문과 답변 기록으로 확인하며, 바이브 코딩에서 중요한 차이는 사람이 이해의 고리를 닫는지 여부임.

바이브 코딩이 코드 소유 관계를 바꾸는 방식

  • 원하는 것을 설명하고 에이전트가 만든 결과물을 한 시간 뒤에 작동하게 하는 과정은 즐거우며, 특히 1인 개발자나 2인 팀에는 감당할 수 없던 인력을 얻은 듯한 경험임.
  • 문제는 그 한 시간이 코드와 맺는 관계를 바꾼다는 점임.
  • 시스템을 직접 작성하면 잘 작성하지 못했더라도 상태가 어디에 있는지, 어떤 함수가 지나치게 많은 일을 하는지, 보기 흉한 우회 방법이 어디에 있고 왜 존재하는지에 대한 지도가 남음.
  • 에이전트가 작성한 경우 제품은 남지만 지도는 남지 않을 수 있음. 한동안은 제품이 작동하므로 문제가 드러나지 않지만, 에이전트가 한 번에 해결하지 못하는 운영 환경 버그가 나타나거나 아키텍처 전반에 걸친 고객 요청이 들어오면 개발자는 저장소 안의 블랙박스를 구경하는 처지가 될 수 있음.
  • 이런 현상은 뛰어난 엔지니어에게도 나타나며, 역량 부족이 아니라 업무 방식의 부작용임.

AI 지원 개발에 관한 연구

  • 1월에 Anthropic은 이 현상을 다룬 무작위 대조 시험을 발표함. 주로 주니어인 개발자 52명이 익숙하지 않은 비동기(async) 라이브러리를 사용해 기능 두 개를 만들었으며, 참가자 중 절반은 AI 지원을 받고 나머지는 받지 않음.
  • 과제를 마친 뒤 참가자들은 방금 사용한 개념에 관한 퀴즈를 치렀음. AI 지원 그룹의 점수는 17% 낮았으며, 이는 대략 두 등급 차이에 해당함. 격차는 디버깅과 실행 흐름 추적에서 가장 컸음.
  • AI 지원 그룹은 유의미하게 더 빠르지도 않았음. 작업 전체를 모델에 위임한 사람들의 평균 점수는 40% 미만임.
  • 성적이 좋았던 AI 사용자와 그렇지 않은 사용자의 차이는 모델이 코드를 생성한 뒤에도 질문을 이어갔는지 여부였음. 이들은 접근 방식을 택한 이유, 실패하면 어떤 일이 생기는지, 값이 어디서 오는지 물었음.
  • 이들은 여전히 프롬프트를 입력했지만, 결과물에서 질문을 멈추지 않았음.
  • 전년도 지식 노동자 설문조사에서 Microsoft Research와 CMU가 발견한 결과도 이와 일치함. AI 결과물에 더 큰 신뢰를 둔 사람일수록 스스로 비판적 사고를 덜 했다고 보고함.
  • 도구를 신뢰하면 도구 확인을 멈추게 됨. 누구도 이를 의식적으로 선택하지 않지만, 저항이 가장 적은 경로이며 도구는 그 경로를 매우 매끄럽게 만듦.

사라지는 것은 다른 업무에도 통하는 역량

  • 약화되는 것은 특정 기술 스택이 아니라 이식 가능한 역량임.
  • 파일을 열기 전에도 버그가 있을 법한 위치를 짐작하는 감각, 스택 트레이스를 읽고 가설을 세우는 능력은 직무와 프로그래밍 언어를 넘어 통하는 역량이며, 주니어에서 시니어로 성장하게 하는 능력이기도 함.
  • 오류 메시지를 매번 곧바로 채팅창에 붙여 넣는 방식은 이런 역량을 가장 먼저 약화시킴.

이해를 의도적인 단계로 만들기

  • 도구 사용을 거부하는 것은 비현실적이고 좋은 방법도 아니므로, 이해가 과정 중에 저절로 생기기를 기대하는 대신 이해 자체를 의도적인 단계로 만들어야 함.
  • Anthropic의 데이터에 따르면 이 단계는 큰 비용이 들 필요가 없음. 코드 생성 뒤 실제 질문 몇 가지를 이어간 참가자들은 86%에 도달함.
  • 문제는 마감 압박이 있을 때 이 단계가 가장 먼저 생략되며, 생략 여부를 기록하는 장치도 없다는 점임.

Ninchi가 확인하는 것

  • Ninchi는 이 간극을 위해 구축한 도구임. AI 생성 코드를 검증하는 대신, 사람이 AI 생성 코드를 이해했는지 검증함.
  • 코드 제출 때마다 개발자에게 제출할 코드에 관한 질문을 몇 가지 던지며, 이는 숙련된 시니어가 코드 리뷰에서 물을 법한 질문임. 답변 기록은 살펴볼 수 있는 형태로 보관됨.
  • 변경 내용을 설명할 수 있으면 기록으로 확인할 수 있으며, 설명할 수 없다면 운영 환경에 도달하기 전에 알게 됨.
  • 1인 개발자에게 이 기록은 주로 자신을 위한 것으로, “에이전트가 처리함”을 “에이전트가 한 일을 알고 있음”으로 바꾸는 강제 장치임.
  • 소규모 팀에게는 에이전트와 함께 빠르게 움직이면서도 자기 시스템을 유지보수하지 못하는 사람들로 조용히 변해가는 일을 막는 장치임.

코드를 만드는 것과 소유하는 것

  • 바이브 코딩은 개발 방식으로 괜찮지만, 코드를 소유하는 방식으로는 형편없음.
  • 차이는 사람이 이해의 고리를 닫는지 여부이며, 그 선택은 여전히 사람이 할 수 있음.