‘Vibe Coding’을 멈추고. Orchestrating 시작: 에이전틱 뉴스룸을 어떻게 구축했는가 (Wrapper가 아니라)

Source: Dev.to

Rizwanul Islam (Afraim) – 인텔리전트 미래 설계자 | Gaari 및 The Trail 설립자

그들은 이를 **“Vibe Coding”**이라고 부릅니다—데이터베이스 스키마가 어떻게 작동하는지 이해하지 못하고도 프롬프트 엔지니어링만으로 유니콘을 만들 수 있다는 생각입니다. 이는 매혹적인 거짓말입니다. Vibe Coding은 장난감을 만들기에 좋지만 시스템을 구축하는 데는 재앙이 됩니다. 나는 장난감을 만들지 않습니다. 나는 수천 명의 사용자를 버틸 수 있을 만큼 신뢰할 수 있는 아키텍처를 구축합니다.

내가 The Trail(고성능 뉴스 집계기)과 Gaari(방글라데시의 프리미엄 차량 대여 플랫폼)를 설계했을 때, 나는 AI를 사용해 코드를 대신 작성하게 하지 않았습니다. 나는 설계한 코드를 실행하기 위해 AI를 사용했습니다.

“Vibe Coding” 함정

“Vibe Coding”은 확률에 의존합니다. LLM에게 “뉴스 앱을 만들어라”라고 요청하면, 보기에는 예쁘지만 부하가 걸리면 실패하는 React 컴포넌트를 환상처럼 만들어 냅니다. 구문 오류를 없애 주지만, 이해의 마찰도 없애 버립니다.

Gaari와 같이 다음을 처리하는 시스템을 구축할 때는

• 110개 이상의 API 엔드포인트
• 복잡한 다중 서비스 예약 흐름
• 실시간 결제 게이트웨이 (Stripe / Bkash)

데이터베이스에서 발생하는 레이스 컨디션을 “감각”에 맡길 수 없습니다. 흔들림 없는 신뢰성이 필요합니다.

전환

AI를 코드를 작성하는 “매직 8‑볼”처럼 대하는 것을 멈추세요.
AI를 엄격한 아키텍처 제약이 필요한 주니어 개발자로 대하기 시작하세요.

사례 연구: “The Trail”를 스웜으로 설계하기

대부분의 “AI 뉴스 앱”은 OpenAI API를 감싸는 래퍼에 불과합니다: 사용자가 질문을 하면 → 봇이 답변합니다. 이는 취약하고 환각이 발생하기 쉽습니다.

The Trail의 경우, 챗봇을 원하지 않았습니다. 디지털 뉴스룸을 원했습니다. 그래서 Agentic Swarm 아키텍처를 채택했습니다. 하나의 프롬프트 대신, 시스템은 전문화된 에이전트들로 구성됩니다:

• The Planner – 웹을 스캔하여 트렌드 주제를 찾고 범위를 정의합니다.
• The Researcher – 검증된 출처에서 데이터를 가져옵니다 (환각 금지).
• The Writer – Researcher의 데이터만을 기반으로 콘텐츠 초안을 작성합니다.
• The Critic (핵심) – 품질 루브릭(SEO, 가독성, 사실‑검증)에 따라 초안을 검토합니다. 점수가 < 8/10이면 초안을 거부하고 재작성하도록 합니다.

코드 vs. 오케스트레이션

// Writer 에이전트가 초안을 생성합니다
let draft = await writerAgent.write(plan, facts);

// 오케스트레이션 루프
if (review.score < 8) {
  console.log(`Quality fail (${review.score}). Rewriting...`);
  // 재작성 로직 트리거
}
return await publisherAgent.publish(draft);

스택: Next.js + Supabase (신뢰성 레이어)

AI만큼 빠르게 움직이면서 은행만큼 안전한 인프라가 필요합니다. Gaari와 The Trail 모두에 대해 저는 Next.js + Supabase 스택을 표준화했습니다.

왜 Supabase?

Gaari의 아키텍처는 민감한 사용자 데이터(예약, 결제)를 처리합니다. AI 에이전트가 탈선하거나 프론트엔드 버그가 발생하더라도, 데이터베이스는 물리적으로 무단 쿼리를 거부합니다. 이것이 흔들리지 않는 신뢰성입니다.

왜 Next.js 14?

Next.js는 서버 사이드 렌더링, API 라우트, 그리고 엣지 런타임 기능을 제공하여 실시간 AI 오케스트레이션 및 빠른 반복 작업과 완벽하게 맞아떱니다.

“Founder Mode” 마인드셋

“Founder Mode”에 대한 뜨거운 논쟁이 있습니다—리더는 세부 사항을 알아야 한다는 생각입니다. 저는 이러한 시스템의 설계자로서 데이터베이스 스키마를 위임하지 않습니다. API를 “블랙 박스”처럼 여기지 않습니다. 저는 The Trail의 스키마에 있는 30개가 넘는 테이블을 모두 알고 있습니다.

2026년에 100× 엔지니어가 되려면 전환이 필요합니다:

• From: 구문 작성 (AI가 할 수 있습니다).
• To: 시스템 설계 (AI는 할 수 없습니다).

Conclusion: Build the Engine, Don’t Just Paint the Car

My work with Gaari and The Trail proves that you don’t need a team of 50 to build enterprise‑grade software. You need a system mindset. Stop vibing and start orchestrating.

If you are building something that needs to scale, stop looking for “code snippets” and start looking at architecture patterns.

토론

코드를 작성하기 위해 AI를 사용하고 있나요, 아니면 AI가 실행할 시스템을 설계하고 있나요?