DHH의 바이브 코딩 발표: 내 AI 시스템을 확장할 때 무엇을 검증할까

큐레이터의 판단

바이브 코딩으로 코드를 생성하면 자신이 운영하는 AI 시스템에 기능을 직접 더할 여지가 커진다. DHH는 작은 도구를 직접 만들고 개인 에이전트가 쓸 CLI를 요구하는 사례를 보여 주면서도, 에이전트로 만든 변경을 여럿 합쳤을 때 아키텍처가 군데군데 뚫린 듯했다고 말한다. 이 큐레이션은 직접 확장의 가능성과 함께 생성한 변경을 어떻게 통합·검증·유지할지를 살펴본다. 생산성과 속도에 관한 발언은 발표자의 경험담이며 독립적으로 검증된 측정 결과가 아니다.

누구에게 유용한가

에이전트를 이미 사용하고 있으며, 자신의 데이터·작업 흐름·도구를 연결한 AI 시스템을 직접 구축하거나 운영하는 사람. CLI와 에이전트 작업 위임의 기본을 알고, 생성된 코드의 테스트·통합·보안·유지보수 책임까지 살펴볼 준비가 있으면 좋다.

핵심 내용

1. 01

   20:45 · 생성 속도와 통합의 비용 ↗

   • DHH는 37signals에서 손으로 코드를 쓰는 일을 통상적인 방식이 아니라 예외 상황으로 보기로 했다고 말한다. 에이전트가 원하는 결과를 내지 못하면 직접 코드를 쓰기보다 그 원인을 고치겠다는 것이다.
   • 앞서 Basecamp 5 마무리 단계에서 디자이너들이 바이브 코딩으로 만든 PR은 하나씩 보면 그럴듯했지만, 20~30개를 합치자 아키텍처가 군데군데 뚫린 듯했다고 회고한다.
   • 그는 그때 수작업 검토로 돌아간 판단이 틀렸으며, 조금만 기다렸다면 더 나은 모델로 아마 의도대로 작동했을 것이라고 본다.
2. 02

   31:46 · 대화보다 비동기 위임 ↗

   • DHH는 에이전트와 일하는 가장 좋은 방식이 채팅창에서 출력을 기다리는 것이 아니라, 동료에게 맡기듯 작업을 넘기고 결과가 준비되면 검토하는 비동기 방식이라고 말한다.
   • 37signals도 여러 방식을 시험 중이며, 작업이 아니라 결과나 문제를 맡길 수 있는 수준의 지능이 나온 지 몇 달밖에 되지 않아 적합한 방식이 아직 정해지지 않았다고 인정한다.
3. 03

   45:15 · 개인 에이전트가 쓸 CLI ↗

   • DHH는 앱마다 챗봇을 넣는 방식 대신, 자신이 쓰는 개인 에이전트가 CLI로 여러 앱을 다룰 수 있게 해 달라고 요구한다.
   • HEY CLI를 쓴 에이전트가 키워드가 아니라 개념으로 검색해, 상대도 연도도 기억나지 않던 5년 전 이메일을 몇 분 만에 찾았다는 사례를 든다.
4. 04

   48:13 · 직접 만드는 작은 도구 ↗

   • DHH는 자신의 아이디어를 담아 만든 운영체제 환경 Omarchy와, 그 위에서 에이전트로 만든 계산기·글쓰기 앱·영상 편집기·발표 도구를 사례로 든다.
   • C++와 Qt를 잘 몰랐지만 프롬프트를 넣은 지 7분 만에 계산기를 얻었고, 글쓰기 앱은 에이전트가 만든 코드를 한 줄도 보지 않았다고 말한다.

큐레이터의 해석•제안

• DHH의 사례는 생성이 쉬워져도 통합과 검증이 끝나지는 않는다는 관점에서 읽을 수 있다. 그의 제작 경험이 같은 수준의 유지·운영 능력을 보장하지는 않으므로, 코드를 직접 읽지 않는다면 무엇으로 동작과 품질을 확인할지 정하기를 권한다.
• 비동기로 작업을 위임할 때는 작업의 단위와 완료 조건, 실패 시 되돌리는 방법을 먼저 정하기를 권한다. 결과가 준비된 뒤 이를 검토할 기준으로 삼을 수 있다.
• 개인 에이전트가 자기 자료와 작업 흐름을 잇도록 CLI를 쓰더라도, 접근 권한·승인·작업 기록·오류 복구의 경계는 함께 설계하기를 권한다. CLI 자체가 이 문제들까지 해결한다고 보기는 어렵다.

출처 정보

이 큐레이션은 Ruby on Rails의 원문을 바탕으로 작성했습니다. 전문 번역이 아니며, 원저자의 전체 맥락을 대신하지 않습니다.