PRD를 만들지 말라? DHH의 실용주의 철학과 AI 시대의 제품 개발

게시 2026/01/21 업데이트 2026/01/21

By BLUEBUG

30 분읽는 시간

PRD 를 만들지 말라고?
쓴소리 전문 개발자 DHH 에이전트를 정말 좋아한다, 오늘도 Google AI Studio 써서 급하게 웹사이트 데모 만드느라 PRD도 없이 시작했던 것을 늦게 알아차리고 README 하고 지금까지 작업한 implementation들 퀄러티 리뷰하고, next phase development 계획 짤 목적으로 필요한 PRD draft를 지금이라도 쓰는 게 어떻겠냐고 architect agent 한테 먼저 공손히 여쭤봤다. 아키텍트는 당연히 좋은 생각이라고 추천을 하길래, 그럼 그걸 DHH 한테도 물어보라고 했더니 돌아온 답변이다.
어떤 결정을 하든 그건 각자가 가진 경험과 인사이트에 따라 다르겠지만, 이런 가상 에이전트들과 다양한 아이디어들을 시뮬레이션하고 결정할 수 있다는 것 자체가 신기하고 재밌을 따름이다.
https://www.threads.com/@focusrefresh/post/DTv6DmEko-v

들어가며

소프트웨어 개발의 세계에서 PRD(Product Requirements Document)는 오랫동안 제품 개발의 필수 문서로 여겨져 왔다. 하지만 Ruby on Rails의 창시자이자 Basecamp의 공동 창업자인 DHH(David Heinemeier Hansson)는 이러한 전통적 접근에 정면으로 도전한다. 더 흥미로운 점은 이제 우리가 AI 에이전트를 통해 DHH와 같은 다양한 개발 철학자들의 관점을 시뮬레이션하고, 실시간으로 의사결정 과정에서 그들의 조언을 받을 수 있다는 것이다.

DHH의 반PRD 선언: Getting Real 철학의 핵심

“부질없다, 형식을 우선시하는” 행위인가?

DHH 에이전트가 제시한 첫 번째 메시지는 명확하다. “transactions 데이블과 badges 시스템을 위해 방대한 제품 요구 사양서를 작성하는 것은 실제 진행을 방해하는 전형적인 ‘부질없다 형식을 우선시하는’ 행위”라는 것이다. 이는 단순한 문서 작성에 대한 거부가 아니라, 현대 소프트웨어 개발에서 무엇이 진정으로 가치를 창출하는지에 대한 근본적인 질문이다.

전통적인 개발 프로세스에서 PRD는 일종의 안전장치로 여겨진다. 모든 요구사항을 명확히 하고, 이해관계자들의 합의를 도출하며, 개발 방향의 나침반 역할을 한다고 믿는다. 하지만 DHH의 관점에서 이는 종종 실제 문제 해결을 지연시키고, 명확한 비전과 실제로 동작하는 코드라는 더 중요한 것들로부터 주의를 분산시킨다.

Getting Real: 현실적으로 접근하라

“Getting Real”은 DHH와 37signals 팀이 2006년에 출간한 책의 제목이자, 그들의 핵심 개발 철학을 담은 개념이다. 이 철학은 간단하지만 강력한 원칙 위에 세워져 있다: 실제로 동작하는 것을 만들고, 빠르게 출시하고, 실제 사용자의 피드백을 받아 개선하라.

DHH 에이전트가 제안한 접근법을 보면 이 철학이 어떻게 구현되는지 명확히 알 수 있다:

문제 정의보다 핵심 질문에 집중하라

“왜 상거래 활동을 추적하는가?” - 이는 단순한 기능 나열이 아니라, 사용자에게 실제로 누가 거래했는지 알아야 하는 이유를 묻는다.
“해결책: 이 기능이 반드시 수행해야 할 가장 중요한 세 가지는 무엇인가?” - 범위를 제한하고 핵심에 집중한다.
“제약 사항: 1단계에서 하지 않을 것은 무엇인가?” - 과도한 엔지니어링을 방지한다.

이러한 질문들은 장황한 요구사항 목록보다 훨씬 강력하다. 팀이 “왜”에 집중하게 만들고, 무엇이 정말 중요한지 끊임없이 재평가하게 한다.

스키마에서 시작하여 UI로: 실용적 개발의 순서

DHH의 세 번째 조언은 구체적이고 실행 가능하다. “스키마에서 시작하여 UI로 넘어가라”는 것이다. 이는 추상적인 문서가 아니라, 실제로 동작하는 시스템의 뼈대부터 만들라는 의미다.

데이터베이스 스키마 우선 접근의 가치

Transactions 테이블의 예시를 보면: sender_id, receiver_id, amount, status와 같은 포함된 단순한 데이터를 만드는 것이 팀의 토대가 된다. 이는 여러 가지 이점이 있다:

구체성: 추상적인 요구사항이 아니라 실제 데이터 구조로 대화가 시작된다.
제약의 발견: 데이터베이스 설계를 하다 보면 자연스럽게 비즈니스 규칙과 제약사항이 드러난다.
신속한 프로토타이핑: 스키마가 있으면 바로 CRUD 작업을 구현하고 테스트할 수 있다.

Badges 시스템도 마찬가지다. “Verified Founder”, “Top Contributor”와 같은 배지 3개를 하드코딩하고 단순한 트리거에 따라 할당하는 것으로 시작한다. 이는 복잡한 배지 관리 시스템을 설계하는 대신, 실제로 동작하는 최소한의 기능으로 시작하는 것이다.

출시하고 의견을 들어라: 완벽함의 적은 좋음이다

네 번째 원칙은 현대 애자일 개발의 핵심이다. “오늘 당신이 필요하고 생각하는 로직을 불렀을 가능성이 높습니다. 커뮤니티가 어떻게 사용하는지 관찰한 후 개선하십시오.”

이는 우리가 미래를 예측하는 능력의 한계를 인정하는 것이다. 아무리 경험 많은 프로덕트 매니저나 개발자라도, 실제 사용자들이 제품을 어떻게 사용할지 완벽하게 예측할 수 없다. 따라서 다음과 같은 접근이 더 효과적이다:

빠른 출시: 완벽을 기다리지 말고, 동작하는 최소한의 기능을 먼저 출시한다.
관찰과 학습: 실제 사용 패턴을 관찰하고 데이터를 수집한다.
반복적 개선: 실제 피드백을 바탕으로 지속적으로 개선한다.

권건 사항: POV(관점) 문서의 대안

흥미롭게도 DHH 에이전트는 PRD의 완전한 폐기를 주장하지 않는다. 대신 “POV(관점) 문서”라는 대안을 제시한다. 이는 길지 않으면서도, 한 페이지 분량의 문서로 스키마를 구축한 뒤 바로 UI 개발에 착수하는 것이다.

이 POV 문서는 “참여”를 보는 것보다 실제 소프트웨어를 만드는 것이 훨씬 낫다는 철학을 반영한다. 즉, 회의실에서 “합의”를 도출하는 대신, 실제로 동작하는 프로토타입을 만들어 보여주고 거기서 논의를 시작하라는 것이다.

AI 에이전트 시대의 의사결정: 다양한 관점의 시뮬레이션

가상 전문가 패널의 등장

이 사례에서 가장 혁신적인 부분은 개발 방법론 자체가 아니라, 의사결정 과정에서 AI 에이전트를 활용하는 방식이다. 개발자는 Google AI Studio를 사용하면서 급하게 웹사이트 데모를 만들다가, 프로세스를 점검하고 싶어졌다. 그때 그는 단순히 혼자 고민하거나 팀원에게 물어보는 대신, 두 가지 다른 AI 에이전트와 대화를 시작했다:

Architect Agent: 전통적이고 체계적인 접근을 선호하는 아키텍트 관점
DHH Agent: 실용주의적이고 빠른 실행을 중시하는 관점

Architect 에이전트에게 먼저 물었을 때, 예상대로 PRD 작성을 추천받았다. README와 지금까지의 구현을 검토하고, 다음 단계 개발 계획을 세우기 위해 PRD draft를 작성하는 것은 “당연히 좋은 생각”이라는 답변이었다. 이는 소프트웨어 엔지니어링의 전통적인 모범 사례를 반영한다.

하지만 같은 질문을 DHH 에이전트에게 던졌을 때, 완전히 다른 답변을 받았다. 그리고 이 대조적인 관점의 충돌이야말로 진정한 가치를 창출한 순간이다.

다양한 관점이 주는 가치

“어떤 결정을 하든 그건 각자가 가진 경험과 인사이트에 따라 다르겠지만, 이런 가상 에이전트들과 다양한 아이디어들을 시뮬레이션하고 결정할 수 있다는 것 자체가 신기하고 재밌을 따름이다.”

이 문장은 AI 시대 의사결정의 새로운 패러다임을 보여준다. 과거에는 다양한 관점을 얻기 위해서는:

여러 전문가와 미팅을 잡아야 했고
컨설턴트를 고용해야 했고
책을 읽고 컨퍼런스에 참석해야 했다

이제는 몇 분 안에 다양한 사고방식을 가진 가상 전문가들과 대화하고, 그들의 관점을 비교하고, 자신의 상황에 맞는 최선의 접근법을 선택할 수 있다. 이는 단순히 정보 접근성의 향상을 넘어서, 의사결정 품질의 근본적인 개선을 의미한다.

시뮬레이션을 통한 학습

AI 에이전트를 활용한 의사결정의 또 다른 가치는 “안전한 실험”이 가능하다는 것이다. 실제 프로젝트에서 DHH의 접근법을 따라 PRD 없이 진행했다가 실패하면 큰 손실이 발생할 수 있다. 하지만 AI 에이전트와의 대화를 통해서는:

비용 없는 탐색: 다양한 접근법을 시도해보고 그 결과를 예측해볼 수 있다.
빠른 반복: 한 가지 접근법이 맞지 않으면 즉시 다른 방향을 탐색할 수 있다.
학습 가속화: 실패의 비용 없이 다양한 방법론을 경험하고 학습할 수 있다.

PRD vs No-PRD: 이분법을 넘어서

맥락이 결정한다

DHH의 접근법이 항상 옳은 것은 아니다. 그리고 DHH 자신도 이를 인정할 것이다. 문제는 “PRD를 만들어야 하는가 말아야 하는가”가 아니라, “어떤 상황에서 어떤 수준의 문서화가 필요한가”이다.

PRD가 유용한 경우:

대규모 조직에서 여러 팀 간의 조율이 필요할 때
규제 산업에서 감사 추적이 필요할 때
복잡한 시스템 통합이 필요하고 다양한 이해관계자가 있을 때
외주 개발이나 분산된 팀과의 협업이 필요할 때

No-PRD/Minimal-PRD가 유용한 경우:

작은 팀이 빠르게 움직여야 할 때
요구사항이 아직 불명확하고 탐색이 필요할 때
시장 반응을 빠르게 테스트해야 할 때
팀원들이 높은 자율성과 전문성을 가지고 있을 때

핵심은 “가치 창출까지의 시간”

결국 두 접근법 모두 같은 목표를 추구한다: 사용자에게 가치를 제공하는 제품을 만드는 것. 차이는 그 목표에 도달하는 경로에 있다.

전통적인 PRD 접근은 “계획의 완성도”를 통해 리스크를 줄이려 한다. DHH의 Getting Real 접근은 “빠른 실행과 학습”을 통해 리스크를 줄이려 한다. 어느 접근이 더 효과적인지는 프로젝트의 성격, 팀의 역량, 조직의 문화, 시장의 상황에 따라 달라진다.

실무 적용: 하이브리드 접근법

DHH 철학의 실용적 적용

DHH의 모든 조언을 맹목적으로 따를 필요는 없다. 오히려 그의 철학에서 핵심 원칙을 추출하고, 자신의 상황에 맞게 적용하는 것이 중요하다.

핵심 원칙 1: 문서화보다 실행 우선

적용: 긴 PRD를 쓰기 전에, 1-2일 안에 프로토타입을 만들어볼 수 있는지 고려하라.
균형점: 프로토타입과 함께 간단한 1페이지 컨셉 문서를 작성하라.

핵심 원칙 2: 핵심 질문에 집중

적용: “왜 이것이 필요한가?”와 “가장 중요한 3가지는 무엇인가?”를 먼저 답하라.
균형점: 이 질문들의 답을 문서화하되, 세부 요구사항은 구현하면서 발견하라.

핵심 원칙 3: 스키마부터 시작

적용: UI 목업을 그리기 전에, 데이터 구조를 먼저 설계하라.
균형점: 스키마 설계를 하면서 자연스럽게 비즈니스 로직을 검증하라.

핵심 원칙 4: 빠르게 출시하고 학습

적용: 완벽을 기다리지 말고, 동작하는 최소 기능을 먼저 출시하라.
균형점: 기술 부채를 측정하고, 리팩토링 시간을 계획에 포함하라.

팀 문화와의 정렬

DHH의 접근법을 도입하려면 팀 문화의 변화가 필요할 수 있다:

실패에 대한 태도: 빠른 실행은 빠른 실패를 의미한다. 팀이 실패를 학습 기회로 받아들일 수 있어야 한다.
자율성과 책임: 상세한 PRD 없이 진행하려면 팀원들이 높은 자율성을 가지고 올바른 결정을 내릴 수 있어야 한다.
의사소통의 변화: 문서 대신 동작하는 코드와 빠른 피드백 사이클로 의사소통하는 방식에 익숙해져야 한다.
측정 지표의 변화: “문서 완성도”나 “계획 준수율”이 아니라 “사용자 피드백 반영 속도”나 “가치 창출까지의 시간”을 측정해야 한다.

AI 에이전트 활용 전략

효과적인 가상 자문단 구성

이 사례에서 배울 수 있는 것은 단순히 AI를 사용하는 것이 아니라, “어떻게” 사용하는가이다:

1. 다양한 관점의 에이전트를 준비하라

보수적인 아키텍트 관점
진보적인 실용주의자 관점
사용자 경험 중심 관점
비즈니스/성과 중심 관점

2. 구체적인 맥락을 제공하라

현재 상황 (급하게 데모를 만들고 있다)
고민하는 지점 (PRD를 지금 써야 하는가)
제약사항 (시간, 리소스 등)

3. 대조적인 조언을 의도적으로 구하라

한 에이전트에게만 의존하지 말라
반대 관점을 적극적으로 탐색하라
긴장관계(tension)가 있는 곳에 진실이 있다

4. 최종 판단은 스스로 하라

AI 조언은 참고사항이다
프로젝트의 맥락을 가장 잘 아는 사람은 당신이다
다양한 조언을 종합하여 자신만의 길을 찾아라

학습 도구로서의 AI 에이전트

AI 에이전트는 단순한 생산성 도구를 넘어서 강력한 학습 도구가 될 수 있다:

사고방식의 내재화

DHH 에이전트와 지속적으로 대화하면서 그의 사고방식을 학습할 수 있다
다양한 상황에서 그가 어떻게 생각할지 시뮬레이션할 수 있다
점차 에이전트 없이도 그런 관점에서 생각할 수 있게 된다

멘토링 경험의 민주화

모든 개발자가 DHH, Martin Fowler, Kent Beck 같은 거장들의 조언을 받을 수 있다
경험의 격차를 줄이고 학습 곡선을 가속화할 수 있다
다양한 방법론을 안전하게 실험하고 학습할 수 있다

미래 전망: 개발 방법론의 진화

문서 vs 코드의 경계 흐림

AI 도구들이 발전하면서 전통적인 “문서”와 “코드”의 경계가 흐려지고 있다:

실행 가능한 문서: 코드 주석과 문서가 AI에 의해 자동으로 동기화된다
대화형 요구사항: PRD를 읽는 대신, AI와 대화하며 요구사항을 탐색한다
자동 생성 아키텍처: 간단한 POV 문서에서 상세한 아키텍처가 자동 생성된다

개인화된 방법론의 시대

앞으로는 “우리 팀은 Scrum을 한다” 또는 “우리는 Waterfall을 한다”는 이분법적 선택이 아니라, 프로젝트마다, 심지어 기능마다 최적의 접근법을 선택할 수 있게 될 것이다. AI 에이전트는 이러한 선택을 돕는 조력자가 될 것이다:

프로젝트 특성 분석
유사 사례 검색 및 학습
맞춤형 프로세스 제안
실시간 피드백 및 조정

인간 판단의 중요성 증대

역설적이게도 AI가 더 많은 역할을 하게 되면서, 인간의 판단과 선택은 더욱 중요해진다. AI는 다양한 옵션을 제시하고 각각의 장단점을 분석할 수 있지만, 최종적으로 “우리 팀에게 지금 이 순간 가장 적합한 접근법은 무엇인가?”를 결정하는 것은 인간의 몫이다.

이는 소프트웨어 개발자의 역할이 “코드 작성자”에서 “의사결정자”로 진화하고 있음을 의미한다. 기술적 구현 능력도 중요하지만, 다양한 옵션을 평가하고 맥락에 맞는 최선의 선택을 내리는 능력이 더욱 중요해진다.

결론: 도그마를 넘어서

DHH의 조언은 또 하나의 관점일 뿐이다

DHH의 “PRD를 만들지 말라”는 조언은 충격적이고 도발적이다. 하지만 이를 새로운 도그마로 받아들여서는 안 된다. 오히려 이는 우리에게 근본적인 질문을 던진다:

우리는 왜 이 문서를 작성하는가?
이 프로세스가 실제로 가치를 창출하는가?
더 빠르고 효과적인 방법은 없는가?

실용주의의 진정한 의미

진정한 실용주의는 “문서를 쓰지 않는 것”이 아니라, “무엇이 실제로 효과가 있는지”를 끊임없이 질문하고 실험하는 것이다. 어떤 프로젝트에서는 DHH의 접근법이 완벽하게 작동할 것이고, 다른 프로젝트에서는 전통적인 PRD가 더 적합할 것이다.

중요한 것은 맹목적으로 한 가지 방법론을 따르는 것이 아니라, 각 상황에서 무엇이 최선인지 판단하는 능력을 기르는 것이다. 그리고 AI 에이전트는 이러한 판단력을 향상시키는 강력한 도구가 될 수 있다.

AI 시대의 새로운 가능성

이 사례가 보여주는 가장 중요한 통찰은 이것이다: 우리는 더 이상 하나의 방법론에 갇혀 있을 필요가 없다. AI 에이전트를 통해 다양한 관점을 탐색하고, 각 접근법의 장단점을 빠르게 평가하고, 자신의 상황에 맞는 최적의 길을 찾을 수 있다.

“가상 에이전트들과 다양한 아이디어들을 시뮬레이션하고 결정할 수 있다는 것 자체가 신기하고 재밌을 따름이다”라는 문장은 단순한 감탄이 아니다. 이는 소프트웨어 개발의 미래, 의사결정의 미래를 엿보는 것이다.

우리는 이제 세계 최고의 전문가들의 지혜를 손쉽게 접근하고, 그들의 관점으로 우리의 문제를 바라보고, 그들이라면 어떻게 했을지 시뮬레이션할 수 있다. 하지만 최종 결정은 여전히 우리의 몫이다. 그리고 그것이야말로 인간 개발자의 진정한 가치가 발휘되는 순간이다.

작성 일자: 2026-01-21
주제 분류: #소프트웨어개발 #개발방법론 #PRD #DHH #GettingReal #AI에이전트 #의사결정
참고자료: DHH의 Getting Real 철학, AI 에이전트 활용 사례

AI, Material

AI Material ai-agent DHH Getting-Real Claude.write