"AI가 코드를 짜는 시대, 진짜 일은 '안전한 병합'부터 시작된다"...개발자 유수프 아이타스 "데모 완성은 결승선 아냐"

[한국정보기술신문] 인공지능(AI)이 코드를 점점 더 잘 짜는 시대에, AI로 코드를 빠르게 만들어 내는 일과 그 코드를 실제 제품에 안전하게 들여보내는 일은 전혀 다른 작업이라는 개발자의 분석이 나왔다. 소프트웨어 엔지니어 유수프 아이타스(Yusuf Aytas)는 6월 14일(현지시간) 자신의 블로그에 올린 글에서, 분위기에 맡겨 코드를 뽑아내는 이른바 '바이브 코더(vibe coder)'와 개발 전 과정을 책임지는 '소프트웨어 엔지니어'를 구분하며 둘을 가르는 여섯 가지 차이를 제시했다. 이 글은 객관적 보도가 아니라 한 개발자의 경험과 견해를 담은 분석에 해당한다.

바이브 코딩이란 사람이 코드를 한 줄씩 직접 짜는 대신, AI에 원하는 바를 말로 일러 주고 AI가 만들어 낸 코드를 받아 쓰는 방식을 가리킨다. 아이타스는 바이브 코더를 "아이디어를 시제품으로 만들어 빠르게 시험해 보려는 사람"으로, 소프트웨어 엔지니어를 "소프트웨어 개발의 전체 생애주기를 생각하는 사람"으로 규정했다. 그는 둘을 가르는 것은 어떤 도구를 쓰느냐가 아니라 책임이 어디서 시작되고 어디서 끝나느냐라고 강조했다. AI가 코드를 짤 수 있느냐는 더 이상 쟁점이 아니며, 그 코드가 실제 이용자와 데이터, 규제, 장애, 그리고 그것을 유지·보수해야 할 사람이 있는 진짜 코드 저장소에 들어갔을 때 무슨 일이 벌어지느냐가 문제라는 것이 그의 진단이다.

아이타스가 첫 번째로 꼽은 차이는 무엇을 성과의 잣대로 삼느냐다. 그는 바이브 코딩을 둘러싼 논의가 대체로 잘못된 것을 재고 있다고 지적했다. 아이디어에서 작동하는 앱까지 얼마나 빨리 갔는지를 자랑하지만, 팀에서 일할 때는 누군가 그 코드를 검토하고, 의도를 이해하고, 외부 부품(의존성)이 적절한지 판단하고, 시험 코드가 실제 동작을 검증하는지 확인하고, 되돌리기(롤백) 방안을 마련하고, 장애 대응 안내서(런북)를 써야 한다는 것이다. 검토와 롤백, 런북 같은 일은 혼자 만드는 장난감 같은 프로젝트에는 들어 있지 않다고 그는 짚었다.

이런 이유로 아이타스는 AI가 만든 결과물을 '안전한 병합까지 걸리는 시간(time to safe merge)'이라는 다른 잣대로 재야 한다고 제안했다. 병합이란 한 사람이 만든 코드를 여러 사람이 함께 쓰는 본래의 코드 저장소에 합치는 작업을 말한다. 그는 이 잣대에 검토 가능성, 위험, 시험의 질, 소유권, 롤백, 그리고 작성자가 변경의 핵심 결정을 설명할 수 있는지가 모두 들어간다고 설명했다. 만약 AI가 코드 생성은 싸게 만들었지만 안전한 병합은 더 비싸게 만들었다면, 팀이 얻은 것은 생각만큼 크지 않다는 것이다. 그는 "데모(시연)는 잘못된 결승선"이라며, 시연은 무언가를 보여 줄 수 있다는 사실만 증명할 뿐 그것을 팀이 받아들일 수 있다는 것까지 증명하지는 못한다고 적었다.

두 번째 차이로 그는 '작업의 단위'를 들었다. 아이타스는 AI가 거든 코드는 더 커지는 것이 아니라 더 좋아져야 한다고 주장했다. 도구가 더 많이 만들어 내도록 해 준다면, 사람은 그만큼 더 많이 제약을 걸어야 한다는 것이다. 그렇지 않으면 일을 줄이는 것이 아니라 유지·보수라는 형태로 일을 하류로, 즉 다른 누군가의 몫으로 떠넘기는 셈이 된다고 그는 봤다.

그는 AI가 거든 코드도 손으로 짠 코드와 똑같은 기준을 통과해야 한다고 강조했다. 코드는 좁아야 하고, 존재해야 할 이유가 하나여야 하며, 관련 없는 정리 작업을 끼워 넣거나 모델이 내키는 대로 파일의 절반을 다시 손보거나 분명한 설명 없이 외부 부품을 추가해서는 안 된다는 것이다. 모델이 너무 많이 생성해 변경 규모가 커졌다면 쪼개야 한다고도 했다. 그는 열 줄이면 될 일에도 AI가 불필요한 군더더기 코드를 잔뜩 만들어 내는 일을 여러 번 겪었다며, 작성자가 의미 있게 바뀐 파일마다 왜 바뀌었는지 설명하지 못한다면 그 코드는 병합될 준비가 안 된 것이라고 적었다. 바이브 코더는 생성된 결과물을 진척으로 여기지만, 소프트웨어 엔지니어는 모든 변경을 책임의 단위로 본다는 것이 그의 결론이다. 속도가 관리되지 않으면 '검토 부채(review debt)', 즉 나중에 갚아야 할 검토 부담으로 쌓인다고 그는 경고했다.

세 번째 차이는 소유권이다. 아이타스는 AI가 생성한 코드를 검토하는 일이 사람이 짠 코드를 검토하는 일과 다르다고 했다. 사람이 코드를 짤 때는 대개 결정의 흔적이 남아, 왜 그 방식을 택했는지 물어볼 수 있다는 것이다. 반면 AI가 만든 코드에서는 그 일부가 결정이 아니라 단순한 '자동 완성'이라고 그는 지적했다. 작성자가 생성된 결과물을 자신이 책임지는 작업으로 바꿔 놓지 않으면, 검토하는 사람이 검토와 더불어 '저작 복원', 즉 누가 왜 이렇게 만들었는지를 되짚는 일까지 두 가지를 떠안게 된다는 것이다.

그는 바이브 코더는 "모델이 만들었다"고 말할 수 있지만, 소프트웨어 엔지니어는 "내가 책임진다"고 말해야 한다고 강조했다. 코드는 모델에서 시작됐더라도, 책임까지 모델에 머물러서는 안 된다는 것이다. 그는 작성자가 검토를 요청하기 전에 생성된 결과물을 하나의 엔지니어링 결정으로 바꿔 놓는 것이 기본적인 소유권이라고 적었다.

네 번째 차이로 그는 맥락을 어떻게 다루느냐를 들었다. 아이타스는 모델이 이제 많은 코드를 읽을 수 있게 됐지만, 그렇다고 시스템을 이해하는 것은 아니라고 했다. 엔지니어링 맥락의 상당 부분은 코드가 아니라 과거의 장애 경험, 오래된 데이터 이전 작업, 이용자의 행동, 운영상의 고충, 팀의 관행, 보안 요구사항, 규제 규칙, 과거의 기묘한 결정들 속에 있다는 것이다. 모델은 이런 맥락을 알려 주지 않으면 모르고, 알려 주더라도 엔지니어처럼 그것을 지니고 다니지는 못한다고 그는 설명했다. 모델은 한 번에 다룰 수 있는 정보의 범위인 '컨텍스트 윈도우' 안에서만 작동하기 때문에, 과제가 클수록 부분만 최적화하다가 전체를 망가뜨리기 쉽다는 것이다.

그래서 그는 "그냥 전체를 고쳐 달라고 시키는 것"은 나쁜 습관일 뿐 아니라 아직 제대로 작동하지도 않는다고 했다. 더 나은 방법은 코드를 요청하기 전에 결정의 여지를 줄이는 것이라고 그는 제안했다. 자신이 더 구체적으로 지시할 때 모델이 더 나은 결과를 낸다는 것이다. 다만 구체적으로 지시하려면 자신이 무엇을 하려는지를 스스로 이해하고 있어야 한다고 그는 덧붙였다. 그는 경험 많은 엔지니어가 AI에서 가장 큰 가치를 얻는 지점이 바로 여기라고 봤다. 모델에 더 많은 자유를 주는 것이 아니라 오히려 더 적게 주는 것, 즉 "이 부분만 써라, 이 계층은 건드리지 마라"는 식으로 범위를 정한 과제로 잘라 주는 데서 엔지니어링이 이뤄진다는 것이다. 바이브 코더는 모델에 목표를 주지만 소프트웨어 엔지니어는 범위를 정한 과제를 주며, 좋은 지시문은 마법이 아니라 작성자가 이미 그 경계를 이해하고 있다는 증거라고 그는 적었다.

다섯 번째 차이는 '발견'과 '전달'의 구분이다. 아이타스는 프로그래밍 언어 '지그(Zig)'를 만든 앤드루 켈리(Andrew Kelley)가 최근 인터뷰에서 이 언어 프로젝트가 AI 기여를 금지하고 그것을 "예외 없이 쓰레기"라고 불렀다는 사실을 소개했다. 오픈소스 프로젝트의 관리자들이 관련 없는 변경과 깨진 기존 동작, 이상한 부품 추가가 뒤섞인 대규모 AI 생성 코드 제안을 받고 있으며, 정작 기여자는 자신이 제출한 코드를 설명하지 못한다는 것이다.

다만 아이타스는 이런 혼란이 AI에 대한 평결은 아니라고 봤다. 그것은 바이브 코딩이 '선을 잘못 넘었을 때' 빚어지는 결과일 뿐이며, 따라서 금지할 것이 아니라 제자리에 두어야 한다는 것이다. 그가 말하는 선은 발견(discovery)과 전달(delivery)의 구분이다. 시제품을 빠르게 만들어 보는 발견 단계에서는 아무도 그 임시 코드를 책임지지 않으므로 어수선해도 괜찮지만, 실제 사업 성과를 내야 하는 전달 단계에서는 설명되지 않는 혼란을 용납할 수 없다는 것이다. 그는 "때로는 그냥 옳아야만 한다"며, 틀려도 되는 비용이 낮은 곳에는 바이브 코딩을, 틀렸을 때의 비용이 고객과 팀과 사업에 돌아가는 곳에는 엔지니어링 규율을 써야 한다고 적었다. 그는 도구가 좋아지면서 이 선이 계속 움직이고 안전한 병합의 비용도 줄겠지만, 줄어드는 것이 사라지는 것은 아니라며, 누군가 결과를 책임져야 하는 한 어느 정도의 규율은 늘 필요하다고 강조했다.

마지막 차이로 그는 견습의 문제를 들었다. 견습이란 신참이 숙련자와 일하며 일을 배워 나가는 과정을 말한다. 아이타스는 신입 엔지니어가 AI를 쓰는 것은 당연하고 또 그래야 한다면서도, 나쁜 방식이 있다고 했다. 만약 신입이 시스템을 이해하는 일을 피하려고 AI를 쓴다면, 더 많이 만들어 내면서 더 적게 배우는 좋지 않은 거래를 하게 된다는 것이다. 엔지니어로 일하는 처음 몇 해는 머릿속에 시스템에 대한 모형을 세우는 시기인데, 그 모형은 기계에서 빌려 오는 것이 아니라 스스로 세워야 한다고 그는 강조했다.

그는 AI가 단기적으로는 신입을 더 생산적으로 보이게 하면서도, 그들을 강한 엔지니어로 키우는 학습의 고리를 약하게 만든다고 우려했다. 그는 켈리가 코드 검토를 '기여자 포커', 즉 프로젝트가 핵심 구성원으로 키울 만한 사람을 가려내는 과정이라고 부른 점을 들며, AI 제출물은 기여자가 코드 기반을 익히지도, 피드백을 흡수하지도 않기 때문에 그 과정을 망가뜨린다고 전했다. 아이타스는 엔지니어링에는 어느 정도의 견습이 필요한데 바이브 코딩은 사람을 혼자 일하도록 유혹한다며, 일의 본질은 결과물이 아니라 판단이고 그 판단은 시스템과 사람들과의 접촉을 통해 길러진다고 적었다.

아이타스는 바이브 코더가 주된 산출물이 아이디어일 때 유용하고, 소프트웨어 엔지니어는 주된 비용이 소유권일 때 필요하다고 정리했다. 그는 이 구분이 고정된 정체성이 아니라며, 같은 사람이 발견 단계에서는 바이브 코딩을 하고 전달 단계에서는 엔지니어링으로 전환해야 한다고 했다. 핵심은 자신이 지금 어느 모드에 있는지를 아는 것이며, 한쪽의 습관이 다른 쪽으로 새어 들지 않게 하는 것이라는 설명이다.

다만 이번 글은 검증된 연구가 아니라 한 소프트웨어 엔지니어의 경험과 견해를 담은 분석이라는 점에서 한계가 있다. AI 코딩 도구의 효용과 위험을 어떻게 평가할지는 개발 조직의 규모와 분야, 협업 방식에 따라 다를 수 있고, '안전한 병합까지의 시간'을 어디까지 적용할지나 신입의 학습에 AI가 미치는 영향에 대한 판단도 보는 관점에 따라 갈릴 수 있다. AI 기여를 전면 금지한 지그 프로젝트의 사례 역시 모든 개발 현장에 그대로 들어맞는 것은 아니며, 도구의 발전 속도에 따라 이 글이 그은 선도 계속 달라질 수 있다는 점은 글쓴이 본인도 인정한 대목이다.