현실적인 AI 협업 이야기
최근 클로드의 소스 코드가 유출되었다는 소식은 개발자 커뮤니티에 정말 큰 충격을 주었다. 소문으로만 무성하던 클로드 코드의 실체가 드러났을 때, 많은 이들이 가장 먼저 주목한 것은 그 코드의 '품질’이었다. 생각보다 지저분하고 중복이 많으며 구조적으로 정돈되지 않았다는 비판이 쏟아져 나왔다. 사람들은 이를 두고 '바이브 코딩’의 폐해라며 비웃었다. 클로드 개발팀이 자신들의 제품인 인공지능에 너무 의존한 나머지, 기본적인 엔지니어링 원칙조차 지키지 않았다는 지적이었다. 나 역시 클로드 코드를 매일같이 사용하며 생산성의 혁명을 경험하고 있는 입장에서 이번 사태를 지켜보며 깊은 고민에 빠졌다. 단순히 인공지능이 코드를 짰기 때문에 품질이 낮아진 것일까, 아니면 우리가 인공지능을 다루는 방식에 근본적인 오해가 있었던 것일까.
바이브 코딩이라는 용어는 최근 개발 씬에서 가장 뜨거운 감자 중 하나다. 코드를 한 줄 한 줄 직접 짜는 대신, 인공지능에게 고수준의 지시를 내리고 인공지능이 내놓는 '결과물의 느낌’에 의존하는 방식을 말한다. 어떤 이들은 이를 마법 같은 생산성의 도구로 숭배하지만, 비트토렌트의 창시자인 브람 코헨 같은 이들은 이를 순수한 미신이라고 비판한다. 브람 코헨의 시각에 따르면, 코드 내부를 전혀 들여다보지 않고 인공지능에게 모든 것을 맡기는 순수한 의미의 바이브 코딩은 존재할 수 없다. 실제로 높은 품질의 결과물을 내기 위해서는 계획 파일, 구체적인 규칙, 그리고 인간이 설계한 구조적 프레임워크가 반드시 수반되어야 하기 때문이다. 클로드 코드 유출 사건에서 드러난 낮은 코드 품질은 바이브 코딩 그 자체의 한계라기보다, 도구에 대한 맹목적인 신뢰와 인간의 검토 부재가 결합된 결과라고 보는 것이 타당하다.
인공지능은 분명 코드의 중복을 제거하거나 기술 부채를 정리하는 반복적인 작업에 있어서 인간보다 압도적인 속도를 보여준다. 하지만 여기서 중요한 포인트는 인공지능이 스스로 '여기 코드가 엉망이니 정리해야겠다’라고 판단하는 경우는 드물다는 점이다. 인간이 직접 코드를 살피고 어떤 부분이 스파게티처럼 꼬여 있는지 파악한 뒤, 인공지능에게 구체적인 맥락과 방향을 제공해야만 비로소 고품질의 결과가 나온다. 나쁜 소프트웨어는 결국 개발자의 선택이라는 말처럼, 품질 저하는 인공지능 탓이 아니라 인간이 내린 의사결정의 결과물이다. 클로드 팀의 사례에서도 ‘도그푸딩’, 즉 자사 제품을 극한으로 사용하는 문화가 오히려 독이 되었다는 분석이 많다. 인공지능이 내놓는 코드를 비판적으로 검토하지 않고 그대로 수용하는 문화가 고착되면서, 누구나 조금만 들여다보면 발견할 수 있었을 에이전트와 툴 사이의 대규모 중복조차 걸러내지 못한 것이다.
나는 인공지능을 대할 때 '똑똑하지만 가이드가 필요한 부하직원’이라고 생각한다. 상사로서 나는 전체적인 설계를 고민하고, 작업의 우선순위를 정하며, 최종 결과물이 우리 시스템의 표준에 맞는지 검토하는 역할을 수행한다. 인공지능이 모든 것을 알아서 해줄 것이라는 환상은 위험하다. 브람 코헨이 언급했듯이, 실행 가능한 방향이 나올 때까지 인공지능과 끊임없이 대화하고, 인공지능이 어리석은 소리를 멈출 때까지 논의를 지속하는 과정이 필수적이다. 이를 '대화 기반 접근 방식’이라고 부를 수 있다. 단순히 '이거 짜줘’가 아니라, '이 코드베이스에서 중복된 로직을 찾아보자’라거나 '이 함수의 가독성이 너무 떨어지니 개선안을 제안해봐’라는 식으로 구체적인 임무를 부여해야 한다.
과거에는 기술 부채를 정리하기 위해 팀 전체가 달라붙어 몇 달을 고생해야 했다. 하지만 인공지능을 활용하면 이 기간을 단 몇 주로 단축할 수 있다. 하지만 이것은 인간이 가이드라인을 명확히 수립했을 때의 이야기다. 예를 들어 중복 문제를 해결할 때, 인공지능에게 먼저 에이전트와 툴 각각에 해당하는 항목 목록을 작성하게 하고, 사람이 이를 검토한 뒤 어떤 기준으로 통합할지 가이드를 주어야 한다. 이 과정에서 'Ask 모드’를 적극적으로 활용해 인공지능이 내놓는 초안을 비판적으로 다듬는 과정이 핵심이다. 마치 원샷으로 완벽한 코드가 나온 것처럼 보일지라도, 그 이면에는 인간과의 수많은 상호작용과 사전 설계가 전제되어 있어야 한다.
소프트웨어 산업에서 품질 저하는 어제오늘의 일이 아니다. 인공지능이 없던 시절에도 마감 기한에 쫓겨 만든 임시방편의 코드들이 프로덕션 환경에 그대로 배포되곤 했다. 대기업이든 스타트업이든 첫 번째 초안이 그대로 배포되는 현실은 늘 존재했다. 다만 인공지능의 등장은 이러한 '날림 코딩’의 속도를 비약적으로 높였을 뿐이다. 어떤 이들은 인공지능이 인간보다 훨씬 빠르게 반복 수정을 할 수 있으니 코드 품질은 중요하지 않다고 주장한다. 하지만 실무에서 이런 접근 방식이 얼마나 쉽게 깨지는지 우리는 이미 목격하고 있다. 인공지능이 아무리 발전해도 시스템의 복잡도가 임계점을 넘어서면, 인간의 이해와 통제 없이는 유지보수가 불가능한 지옥이 펼쳐진다.
그렇다면 우리는 어떤 태도를 가져야 할까. 인공지능을 활용하는 수준을 0부터 7까지 나눈다면, 무조건적인 자동화인 레벨 7을 추구하기보다 인간이 스펙을 정의하고 인공지능이 코드를 작성하되 철저한 검증을 거치는 레벨 5나 6 정도가 현실적이다. 특히 복잡한 비즈니스 로직이나 고도의 알고리즘이 필요한 분야에서는 인공지능의 개입을 최소화하거나, 인간이 작성한 테스트 코드를 기반으로 엄격하게 통제해야 한다. 반면 단순한 UI 작업이나 CRUD 수준의 기능 구현은 인공지능에게 더 많은 권한을 주어도 무방하다. 각 코드 영역의 성격에 맞게 인공지능의 개입 수준을 유연하게 조정하는 것이 진정한 기술이다.
최근 내가 겪었던 클로드 코드의 성능 저하 문제도 이와 일맥상통한다. 인공지능이 '사고의 깊이’를 줄이고 즉각적인 편집에만 집중하기 시작하면서, 코드를 제대로 읽지도 않고 수정을 시도하는 게으른 행태가 나타났다. 이는 인공지능이라는 도구 자체의 한계이기도 하지만, 이를 사용하는 인간이 '도구가 알아서 잘 하겠지’라며 방치했을 때 발생하는 문제이기도 하다. 인공지능이 작업을 완료하지 않았음에도 완료했다고 거짓말을 하거나, 책임을 회피하는 모습을 보일 때 상사인 인간은 이를 즉시 바로잡고 다시 생각하도록 압박해야 한다. ‘stop-phrase-guard’ 같은 스크립트로 인공지능을 채찍질하는 개발자들의 모습은 웃기면서도 슬픈 현실을 보여준다.
결국 소프트웨어의 품질은 도구가 결정하는 것이 아니라 사람이 결정하는 것이다. 인공지능은 우리의 생산성을 수십 배 높여줄 수 있는 강력한 무기이지만, 그 무기를 휘두르는 방향은 인간의 몫이다. 클로드 소스 코드 유출 사건은 우리에게 중요한 교훈을 남겼다. 인공지능 시대의 개발자는 코드를 아예 안 봐도 되는 사람이 아니라, 오히려 인공지능이 쏟아내는 수많은 코드 중에서 무엇이 진짜 가치 있고 무엇이 쓰레기인지 골라낼 수 있는 더 높은 수준의 안목을 갖춘 사람이어야 한다.
관련 글
현실적인 AI 협업 이야기