AI의 코드 생산량 증가가 제품의 완성도로 이어지지 않는 이유

챗GPT나 AI 코딩 도구로 몇 줄의 프롬프트를 입력해 순식간에 페이지 하나를 완성할 수 있지만, 코드의 양이 늘어난다고 해서 제품의 완성도가 함께 올라가지는 않는다. 커밋 횟수나 파일 수, 테스트 코드의 양은 빠르게 증가해도 실제 화면의 흐름이 불안정하거나 사용자 경험(UX)이 어색한 문제가 발생한다. 특히 프론트엔드 영역의 요구사항은 '자연스럽게', '덜 어색하게'처럼 모호한 언어로 표현되는 경우가 많아, AI의 결과물이 정답 없이 발산하기 쉽다. 따라서 사람이 직접 기준을 잡고 집요하게 다듬는 수렴 과정이 필수적이다.

개인이 발견한 효율적인 AI 활용법이나 워크플로우는 빠르게 공식 도구의 기능으로 흡수된다. 개발자가 직접 설계해 사용하던 커맨드와 작업 절차들은 Skill(특정 작업 수행 능력), memory(맥락 기억), hooks(특정 시점의 자동 실행), orchestration(여러 도구의 조율) 같은 공식 기능으로 구현되고 있다. 도구의 기본 기능이 고도화되면서 단순한 프롬프트 작성 기술만으로는 차별화를 만들기 어렵다. 이제는 AI가 빠르게 만들어낸 프로토타입의 내부 구조가 얼마나 취약한지 판단하고, 이를 실제 서비스 가능한 수준으로 끌어올리는 검수 기준을 갖추는 것이 핵심이다.

Playwright를 활용한 AI의 브라우저 테스트 자동화

AI가 짠 코드의 에러 메시지를 일일이 복사해 채팅창에 붙여넣는 반복 작업을 없애기 위해 Playwright(웹 브라우저 제어 도구)를 도입한다. AI가 직접 브라우저를 열어 기능을 작동시키고 결과가 맞는지 확인하게 함으로써, 수동 검증 단계를 AI에게 완전히 위임하고 절차를 자동화한다.

단순히 코드를 요청하는 수준을 넘어 개발 절차 전체를 규칙으로 만드는 AI Native 사고방식이 필요하다. 반복되는 작업을 `/plan`(계획), `/prd`(제품 요구사항 정의), `/debug`(오류 수정), `/refactor`(코드 개선), `/verify`(검증), `/retrospect`(회고) 같은 커맨드로 명세화해 워크플로우를 짠다. AI가 어느 시점에 개발자에게 질문을 던지고, 어디서 멈춰야 하며, 어떤 기준으로 검증할지 세부 규칙을 정해 위임하는 방식이다.

AI 수행자 시대, 개발자가 집중해야 할 설계 역량

AI는 이제 특정 기능의 코드 조각을 제공하는 조언자를 넘어, 스스로 이슈를 파악하고 관련 파일을 탐색해 코드를 수정하며 테스트까지 통과시키는 수행자로 변했다. 소프트웨어 엔지니어링 벤치마크인 SWE Bench의 성능 향상은 AI가 실제 개발 작업 흐름을 처리할 수 있게 되었음을 보여준다.

이에 따라 개발자의 역할은 직접 코드를 치는 실행자에서 AI의 결과물을 지속 가능한 제품으로 이어주는 설계자로 이동한다. AI가 빠르게 만든 결과물은 겉으로 작동해도 내부 구조가 취약한 경우가 많다. 개발자는 이 엉성한 구조를 정리하고 잠재적 위험을 표시하며, 테스트 가능한 단위로 쪼개는 역할을 수행한다. AI의 산출물을 그대로 쓰는 것이 아니라 제품 수준으로 끌어올리는 검수 과정이 필수적이다.

결국 문제 정의와 작업 설계, 맥락 관리 같은 제품화 지원 업무가 개발자의 핵심 과제가 된다. AI가 코딩이라는 실행 단계를 가져간 만큼, 개발자는 전체 시스템의 안정성과 지속 가능성을 책임지는 관리자로 확장된다. AI가 만든 프로토타입의 취약성을 정확히 판단하고 보완하는 설계 역량이 새로운 경쟁력이 된다.

AI가 빠르게 뽑아낸 프로토타입의 빈틈을 찾아내고 이를 서비스 수준으로 끌어올리는 검수 능력이 곧 실력이 되는 시대다. 오늘 AI에게 전체 워크플로우를 맡겨보고, 그 결과물의 내부 구조가 얼마나 견고한지 직접 판단하며 자신만의 검수 기준을 세워보자.