RAD 방법론과 AI 코딩 시대: 바이브 코딩이 놓치는 것과 스펙 주도 개발의 부활

핵심 메시지

• 1982년 제임스 마틴이 쓴 '프로그래머 없는 애플리케이션 개발'과 1991년의 RAD 방법론은 오늘의 에이전트 코딩과 놀랄 만큼 닮아 있다.
• RAD가 당시에 자리 잡지 못한 이유는 방법론이 틀려서가 아니라, 그 시절 코드 생성기가 쓸 만한 애플리케이션을 만들지 못했기 때문이다.
• AI 에이전트 시대에는 프롬프트가 사실상 요구사항 문서 역할을 하고, 에이전트가 만든 프로토타입이 곧 사용자 설계 단계가 된다.
• 프롬프트에 적히지 않은 규칙은 코드에도 없다. 화면을 클릭해 보는 것만으로는 '본인이 자기 경비를 승인하는' 종류의 구멍을 찾아낼 수 없다.
• 해법은 프로토타입에서 배운 내용을 명세로 적어 두는 스펙 주도 개발이며, 명세에 적힌 규칙은 코드가 통과해야 할 테스트가 된다.

쉽게 이해하기

IBM 테크놀로지의 마틴 킨은 1982년에 나온 책 제목 하나를 꺼내며 이야기를 시작한다. 컴퓨터 과학자 제임스 마틴이 쓴 '프로그래머 없는 애플리케이션 개발'이다. 마틴은 이 아이디어를 1991년에 RAD(신속 응용 개발)라는 방법론으로 정리했는데, 프로그래머 없이 애플리케이션을 만든다는 그 발상은 오늘날 에이전트형 AI로 실제 벌어지고 있는 일이기도 하다.

RAD는 상세한 사전 계획을 앞세우던 폭포수 방식과 달리 속도와 반복, 사용자 피드백을 우선하는 네 단계 방법론이다. 첫 단계인 요구사항 계획은 풀려는 문제와 사용자, 넣을 기능과 제약 정도만 가볍게 정하는데, 사용자는 무언가를 눈으로 보고 반응하기 전까지 자신이 원하는 바를 잘 모른다는 것이 RAD의 출발 가정이기 때문이다. 이어지는 사용자 설계 단계에서는 클릭 가능한 프로토타입을 빠르게 만들어 실제 사용자 앞에 내놓는데, 잘못된 가정을 고치는 비용이 아직 쌀 때 걸러 내자는 취지이며 이 프로토타입은 버리는 물건이 아니라 계속 키워 제품 자체가 된다. 나머지 두 단계는 테스트와 피드백을 병행하는 짧은 주기의 구축, 그리고 운영 배포와 데이터 이전과 사용자 교육까지 포함하는 전환이며, 마틴의 책은 작은 팀이 90일 남짓의 타임박스 안에 동작하는 시스템을 내놓는 그림을 그렸다.

그렇게 좋아 보이는 방법론이 왜 남지 않았을까. 영상은 그 시절의 코드 생성기, 즉 CASE 도구가 정교한 애플리케이션을 만들어 내지 못했기 때문이라고 정리한다. 그런데 평범한 말로 설명해 동작하는 애플리케이션을 얻는 일은 지금 실제로 가능해졌다. 프로토타입 제작이 극도로 빨라지면서, RAD의 네 단계가 AI 개발 흐름 위에 자연스럽게 겹쳐진다는 것이 이 영상의 핵심 주장이다.

예시로 등장하는 것은 바이브 코딩으로 흔히 만들어 보는 경비 승인 앱이다. 재무팀 담당자가 사용자와 승인 규칙을 평범한 말로 적어 에이전트에 보내면 그 프롬프트가 요구사항 문서가 되고, 에이전트가 내놓은 동작하는 앱이 프로토타입이 된다. 사용자가 승인 화면이 헷갈린다거나 배경색이 AI 티가 난다고 피드백하면 에이전트가 다시 만들고, 데이터 스키마와 워크플로 로직, 알림 연결 같은 구축 작업도 함께 해치운다.

문제는 마지막 전환 단계다. 데모를 본 사람들이 전사 배포를 묻는 순간, AI가 전부 작성한 코드를 그대로 운영에 올려도 되는지 물어야 한다. 아무도 '직원이 자기 경비를 스스로 승인할 수 없다'고 프롬프트에 적지 않았다면 에이전트는 2차 결재 규칙을 아예 쓰지 않았을 수 있고, 그러면 900달러짜리 경비를 올린 사람이 스스로 승인해 버릴 수 있다. 영상은 AI 생성 코드 표본의 45% 정도에서 어떤 형태로든 보안 약점이 발견됐다는 연구 결과를 함께 인용한다.

주요 인사이트

• RAD 시절 코드 생성기에는 채팅 창이 없었고, 분석가가 데이터 모델과 업무 규칙을 담은 명세를 넣으면 기본 코드가 나왔다. 즉 마틴의 계획은 원래 '정확한 서술'과 '코드 생성'이라는 두 반쪽으로 이뤄져 있었다.
• 오늘의 AI 에이전트는 그중 코드 생성 반쪽을 아주 잘 해내지만, 서술 반쪽은 다른 곳에서 와야 한다. 그 자리를 채우는 것이 스펙 주도 개발이다.
• 프로토타입을 클릭해 보는 사용자는 존재하지 않는 규칙을 클릭할 수 없다. 반면 명세를 읽는 보안 담당자는 '내가 내 경비를 승인하는 걸 무엇이 막느냐'고 물을 수 있다. 결함의 종류에 따라 발견 경로가 다르다는 뜻이다.
• 명세에 규칙이 들어가는 순간 그것은 생성된 코드가 통과해야 할 테스트가 된다. 프로토타입은 여전히 남기되, 운영에 올라가는 것은 프로토타입이 가르쳐 준 내용을 정리한 명세 쪽이다.
• 가볍게 계획하고, 일찍 프로토타입을 만들고, 짧은 주기로 구축하고, 검증 전에는 운영으로 넘기지 않는다는 35년 된 네 단계는 지금도 그대로 통한다. 다만 프로그래머는 사라진 것이 아니라 명세를 쓰고 결과를 검증하는 쪽으로 자리를 옮겼을 뿐이다.

자주 묻는 질문

관련 AI 소식