AI가 제대로 작동하는 제품까지 만들어주지는 않는다. 그건 여전히 당신의 몫이다

소프트웨어를 만드는 일이 이토록 쉽게 느껴진 적은 없었다. 평범한 영어로 아이디어를 설명하면 몇 분 만에 작동하는 프로토타입이 화면에 나타난다. UI가 있고 데이터베이스에 연결되며, 상상했던 기능을 실제로 수행한다. 코드를 한 줄도 작성해 본 적 없는 사람에게는 마법 같은 순간이다. 컴파일러와 스택 트레이스를 붙들고 씨름해 온 사람에게도 놀라운 일이다.

프로토타입은 노트북에서 실행된다. 하지만 부하가 걸리면 망가지고 오류 처리도 없다. API 토큰이 유출되고 있을 가능성도 뒤늦게 발견한다. 데모에서는 그럴듯했던 데이터 모델이 두 번째 사용자를 추가하자마자 무너진다. 인증은 여러 가정에 기대어 간신히 작동하고 있다. 모든 것이 안전한지 계속 마음에 걸린다. 배포하려는 순간, ‘작동한다’와 ‘준비됐다’ 사이에 거대한 간극이 있다는 사실을 마주한다.

프로토타입을 만드는 일은 원래부터 어렵지 않았다

소프트웨어 엔지니어는 예전부터 무언가를 빠르게 실행할 수 있었다. 시간이 걸린 건 그 밖의 모든 일이었다. 규모가 커져도 버티는 시스템을 설계하고, 사용자가 마주치지 않으리라 생각했지만 결국 마주치는 예외를 처리하고, 문제가 생겼을 때 알아챌 수 있도록 관측 가능성을 확보해야 했다. 3년 뒤에 조금이라도 덜 후회할 데이터 아키텍처를 신중하게 결정하는 일도 필요했다. 이 가운데 달라진 것은 없다. AI는 처음 작동하는 버전을 만드는 시간을 획기적으로 줄였지만, 그 버전에서 프로덕션 수준의 제품에 이르는 거리는 줄이지 못했다.

혼란이 생기는 이유는 개발 초반의 피드백 주기가 매우 빨라졌고 그 과정에서 큰 성취감을 얻을 수 있기 때문이다. 요청하면 결과가 나오고, 곧바로 눈으로 확인할 수 있다. 이 과정은 분명 신나며 소프트웨어 개발의 나머지 단계도 비슷하게 단축됐으리라는 인상을 준다. 하지만 그렇지 않다. 소프트웨어 개발에서 어려운 문제는 애초에 문법에 맞는 코드를 작성하는 일이 아니었다. 무엇을 만들고 어떻게 구성할지, 무엇을 미룰지, 언제 거절할지를 판단하는 일이었다. 이런 판단력이 바이브 코더를 조각가이자 장인으로 만든다. 프로토타입과 프로덕션 수준의 시스템을 가르는 것도 바로 이 판단력이다.

컴퓨터 과학을 배울 필요가 없다는 잘못된 주장

예상할 수 있듯 AI가 생성한 코드를 누구나 쉽게 이용할 수 있게 되자 업계에 새로 진입한 사람들 사이에서 컴퓨터 과학을 여전히 배울 필요가 있는지 의문을 제기하는 목소리가 쏟아졌다. 설명만으로 작동하는 애플리케이션을 만들 수 있다면 알고리즘, 자료구조, 운영체제, 이론을 공부하는 데 왜 몇 년을 써야 할까?

컴퓨터 과학 교육의 가치는 단순히 코드를 만들어 내는 능력에만 있지 않았다. 시스템이 어떻게 동작하고, 어떻게 실패하며, 왜 실패하는지 이해할 사고 체계를 기르는 데 있었다. 이 사고 체계가 있으면 AI가 작성한 쿼리가 5천만 행짜리 테이블 전체를 스캔하리라는 사실을 알아볼 수 있다. AI가 제안한 캐싱 전략이 동시 부하에서 경쟁 상태를 일으킬 것도 파악할 수 있다. 제안된 아키텍처가 설명한 문제는 해결하더라도 그다음 문제를 훨씬 어렵게 만들리라는 점도 판단할 수 있다.

이런 기초가 없으면 모델의 판단에 전적으로 의존하게 된다. 하지만 모델에는 판단력이 없다. 모델은 패턴을 맞추고 사용자의 의도와 일치한다고 여기는 코드를 적극적으로 생성할 뿐이다. 무엇을 살펴봐야 하는지 모른다면, 모델이 자신 있게 생성한 코드는 겉보기에 올바르고 관례도 따르지만 프로덕션에서 장애를 일으킬 수 있다. 그 원인을 진단하는 데 며칠이 걸릴 수도 있다.

지금은 어쩌면 역사상 컴퓨터 과학을 배우기에 가장 좋은 시기다. 이해한 내용을 결과물로 구현하기까지의 간극이 사라졌기 때문이다. 분산 시스템의 작동 원리를 제대로 이해한 학생이라면 이제 10년 전보다 훨씬 짧은 시간에 실제 시스템을 만들 수 있다.

달라지는 것과 달라지지 않는 것

코드를 기계적으로 작성하고 요구사항을 한 줄씩 구현으로 옮길 수만 있는 엔지니어에 대한 수요는 실제로 줄고 있다. 그 업무는 자동화되고 있다.

생산성 분포의 하단은 압축되고 상단에 있는 사람들의 한계는 더 높아지고 있다. 최신 AI 도구를 사용하는 숙련된 엔지니어는 5년 전에는 상상하기 어려웠던 속도로 일할 수 있다. 어려운 문제가 사라져서가 아니라, 많은 시간과 주의를 빼앗던 기계적인 작업을 AI가 대부분 처리하기 때문이다. 덕분에 하루 중 전문성이 실제로 필요한 업무에 쓸 시간이 늘어난다.

뒤처질 엔지니어는 AI 활용 능력이 부족한 사람이 아니다. 이해를 대신하는 수단으로 AI를 사용하는 사람이다. 자신이 논리적으로 설명할 수 없는 시스템을 바이브 코딩으로 만들다 문제가 생겨도 고치지 못하고, 사용량이 늘어도 확장하지 못하며, 유지보수할 사람에게 자신이 무엇을 만들었는지 설명하지도 못하는 이들이다.

다른 차원에서 일하는 법 배우기

필요한 변화는 새로운 도구를 도입하는 데 있지 않다. 기본기에 뿌리를 둔 채 더 높은 추상화 수준에서 일해야 한다. 이 조합은 매우 강력하지만 실제로 갖춘 사람은 드물다.

앞으로 몇 년 동안 동료들을 크게 앞서 나갈 엔지니어는 AI를 깊은 지식을 대체하는 수단이 아니라 그 효과를 증폭하는 도구로 다루는 사람이다. 이들은 모델에 무엇을 만들어 달라고 요청하는지 이해한다. 주니어 엔지니어의 pull request를 검토할 때처럼 비판적인 시선으로 생성된 코드를 살핀다. 기능을 설명하는 데 그치지 않고 아키텍처 관점에서 모델과 대화한다. 모델의 제안에 언제 이의를 제기해야 하는지도 안다.

기존 역량을 새로운 환경에 적용해 훨씬 큰 효과를 얻는 것이다.

프로토타입은 쉬운 단계다. 이제는 누구나 그 사실을 분명히 확인할 수 있다는 점만 달라졌다. 프로토타입 이후의 작업은 여전히 어렵고, 진정한 엔지니어링 판단력이 필요하다. 이 판단력이 신뢰할 수 있는 소프트웨어를 출시하는 개발자와 데모만 내놓는 개발자를 가른다.

기본기부터 배워라. 그런 다음 새로운 도구를 배워라. 반드시 그 순서여야 한다.

^{source https://weeraman.com/the-prototype-isnt-the-product/}

HN에서는 AI가 시제품 제작을 크게 앞당겼다는 사실보다, 그 속도를 제품 완성도와 혼동해도 되는지를 두고 판단이 갈렸다. 여러 개발자는 개별 변경은 그럴듯해 보여도 작업이 누적되면 설계의 일관성이 무너지고, 코드베이스 전체가 미묘하게 어긋난다고 지적했다. 특히 테스트가 부족하고 요구사항이나 배포 방식이 불명확한 기존 시스템에서는 모델이 잘못된 가정과 임시방편을 쌓기 쉽다는 경험이 반복됐다.

그렇다고 AI를 시제품 제작에만 쓸 수 있다고 단정하기도 어렵다. 범위가 작고 위험이 낮은 사내용 도구나 개인용 앱은 상세한 계획을 세우고 단계별 구현과 테스트를 거치면 실제 운영까지 이어갈 수 있었다. 코드 대부분을 모델에 맡기더라도 사람이 제안을 비판적으로 검토하고 성능과 정확성을 확인할 장치를 마련하면 유용한 결과를 낼 수 있다는 사례도 나왔다. 관건은 한 번의 지시로 끝내느냐가 아니라 목표에 맞게 계속 검증하고 수정하느냐다.

판단 기준은 코드 생성량이 아니라 책임의 범위에 가깝다. 대규모 기존 코드베이스와 장기 유지보수, 장애 대응이 필요한 서비스에서는 아키텍처와 도메인 지식, 사용자 문제에 대한 이해가 여전히 결정적이다. 반면 곧 폐기할 실험이나 제한된 내부 도구에 같은 수준의 확장성과 예외 처리를 요구할 필요는 없다. 필요한 수명과 실패 비용을 먼저 정해야 품질 기준도 분명해진다.

결국 생성된 결과를 누가 이해하고 설명할 수 있는지, 요구사항과 설계가 남아 있는지, 테스트가 실제 동작과 성능을 검증하는지를 확인해야 한다. 빠른 구현이 생각과 검토를 대신하면 기술 부채도 빠르게 쌓인다. 사람이 구조와 품질 기준을 주도하면서 반복 작업을 맡길 때 AI는 강력한 도구가 된다. 제품 수준을 가르는 것은 생성 속도보다 결과를 검증하고 책임지는 체계다.