기획서에서 프롬프트까지, 기획의 추상화 역사

기획의 역사를 돌아보면 한 가지 패턴이 보인다. 점점 덜 쓰는 방향으로 왔다. 수십 페이지 기획서에서 와이어프레임으로, 와이어프레임에서 PRD로, PRD에서 프롬프트로. 이 흐름이 우연이 아니라는 걸 개발의 역사에서 먼저 확인할 수 있다. 개발도 정확히 같은 방향으로 진화해왔기 때문이다.

기계어에서 자연어까지, 개발의 추상화 역사

초기 프로그래머는 기계어로 코드를 짰다. 0과 1의 나열이었다. CPU가 직접 이해하는 언어였고, 사람이 이해하기 위해서는 엄청난 인지 비용이 필요했다. 어셈블리어가 등장하면서 숫자 대신 MOV, ADD 같은 기호를 쓸 수 있게 됐다. 그래도 여전히 하드웨어에 가까웠다. C언어가 나오면서 메모리 관리를 직접 하되 사람이 읽을 수 있는 문법이 생겼다. Java는 메모리 관리를 언어가 대신 처리했다. Python은 타입 선언도 없애고 문법을 더 단순하게 만들었다. 그리고 지금은 자연어로 코드를 생성한다.

이 흐름의 핵심은 "기계에 가까운 언어"에서 "사람에 가까운 언어"로의 이동이다. 각 단계마다 추상화 레이어가 하나씩 쌓였고, 그 덕분에 프로그래머는 하드웨어 세부사항 대신 문제 자체에 집중할 수 있게 됐다. 기계어를 알아야 C를 쓸 수 있는 게 아니듯, 각 추상화 단계는 이전 단계의 복잡성을 감추고 더 높은 수준의 사고를 가능하게 했다. 추상화의 역사는 곧 "덜 쓰는 방향"으로의 진화였다.

중요한 건 이 과정에서 사라진 것이 없다는 점이다. 기계어가 없어진 게 아니라 감춰진 것이다. C가 없어진 게 아니라 Python 아래에 있는 것이다. 추상화는 제거가 아니라 은닉이다. 그리고 그 은닉 덕분에 개발자는 "어떻게 실행할 것인가"가 아니라 "무엇을 만들 것인가"에 집중할 수 있게 됐다.

수십 페이지 기획서에서 프롬프트까지

기획도 같은 경로를 걸어왔다. 2000년대 초반 기획서는 수십 페이지짜리 문서였다. 화면 설계, 기능 명세, 예외 처리, 데이터 흐름까지 모든 것을 텍스트로 기술했다. 개발자가 이 문서를 읽고 구현했기 때문에, 기획서는 곧 실행 명세서였다. 빠진 내용이 있으면 개발이 멈췄다. 기획자는 모든 경우의 수를 미리 써야 했다.

와이어프레임이 등장하면서 텍스트 대신 시각적 구조로 의사소통하기 시작했다. 화면 흐름과 레이아웃을 그림으로 보여주면 됐다. 세부 기능 명세는 여전히 필요했지만, 수십 페이지 분량이 줄었다. PRD(Product Requirements Document)는 더 나아갔다. 기능 명세보다 "왜 만드는가"와 "무엇을 달성해야 하는가"에 집중했다. 어떻게 구현할지는 개발자에게 위임했다. 그리고 지금은 프롬프트다. "사용자가 로그인하면 대시보드로 이동하는 기능을 만들어줘"라고 쓰면 AI가 코드를 생성한다. 기획자가 써야 하는 분량이 수십 페이지에서 한 문장으로 줄었다.

이 흐름도 개발의 추상화와 구조가 같다. 각 단계마다 기획자가 직접 다뤄야 하는 세부사항이 줄었다. 화면 설계의 세부사항은 와이어프레임 도구가 처리했고, 구현 방식은 개발자에게 위임됐고, 이제는 AI가 코드 생성까지 맡는다. 기획자는 점점 더 높은 수준의 추상화에서 일하게 됐다. 그리고 그 추상화가 올라갈수록, 기획자가 집중해야 하는 것이 무엇인지가 더 선명해진다.

추상화가 올라갈수록 남는 것

개발의 추상화 역사에서 끝까지 사라지지 않은 것이 있다. 문제 정의다. 기계어로 짜든 Python으로 짜든 자연어로 생성하든, "무엇을 만들어야 하는가"는 사람이 결정해야 했다. 추상화가 올라갈수록 이 질문이 더 중요해졌다. 구현 비용이 낮아질수록 잘못된 문제를 빠르게 푸는 것의 위험이 커지기 때문이다.

기획도 마찬가지다. 프롬프트 한 줄로 기능을 만들 수 있는 세상에서, 기획자가 해야 하는 일은 더 많은 기능을 더 빠르게 정의하는 것이 아니다. 어떤 문제를 풀어야 하는지를 정확하게 정의하는 것이다. 수십 페이지 기획서를 쓰던 시절에는 기획자의 시간 대부분이 "어떻게 구현할 것인가"를 기술하는 데 쓰였다. 와이어프레임과 PRD를 거치면서 그 비중이 줄었다. 프롬프트 시대에는 그 비중이 거의 0에 수렴한다. 남는 것은 "왜 이 문제인가"와 "이 문제가 맞는가"뿐이다.

나는 이것이 기획자에게 위기가 아니라 본질로의 귀환이라고 본다. 기획서를 잘 쓰는 능력, 와이어프레임을 빠르게 그리는 능력, PRD 포맷을 정확하게 채우는 능력. 이것들은 각 시대의 추상화 레이어에 맞는 기술이었다. 그 기술들이 AI에게 넘어가는 것이다. 그리고 그 아래에 항상 있었지만 가려져 있던 것, 문제 정의 능력이 수면 위로 올라온다.

다음 추상화 레이어는 이미 시작됐다

개발의 추상화가 자연어에서 멈추지 않을 것처럼, 기획의 추상화도 프롬프트에서 멈추지 않을 것이다. 다음 레이어가 무엇인지는 아직 모른다. 다만 패턴은 분명하다. 매번 추상화가 올라갈 때마다 이전 단계의 기술은 도구 안으로 흡수됐고, 사람에게는 더 높은 수준의 판단이 요구됐다.

결국 이 역사가 말하는 것은 하나다. 기획자의 가치는 더 많이 쓰는 데 있지 않았다. 더 정확하게 정의하는 데 있었다. 추상화가 올라갈수록 그 사실이 더 선명해질 뿐이다.