제미나이+오퍼스 혼합 AI 코딩 워크플로: 아름다운 풀스택 앱 한 번에 만들기

핵심 메시지

• 제미나이 3.5 플래시는 저렴하고 빠르며 사람이 손으로 만든 듯한 UI를 잘 뽑아내지만, 페이지 문구 같은 실제 정보는 종종 환각(hallucination)을 일으킨다.
• 오퍼스 4.8은 UI 제작보다 긴 추론과 기획, 통합 작업에서 강점을 보여, 두 모델의 장점을 결합하는 워크플로가 제안됐다.
• 핵심 설계는 모든 단계를 별도의 코딩 에이전트 세션으로 나누고, 각 단계가 마크다운 핸드오프 문서를 출력해 다음 단계로 넘기는 방식이다.
• 단계를 나누는 이유는 한 대화 안에서 프로바이더를 바꿀 수 없고, LLM은 한 세션에 너무 많은 일을 맡기면 성능이 무너지기 때문이다.
• 제미나이가 저렴한 덕분에 UI 디자인에 토큰을 많이 써도 비용이 낮고, 기획은 더 비싼 오퍼스에 맡겨 비용과 품질의 균형을 맞춘다.

쉽게 이해하기

발표자는 구글의 제미나이 3.5 플래시가 저렴하고 빠른 데다 사람이 직접 만든 것처럼 보이는 프론트엔드를 잘 만든다는 점에 주목한다. 보통 LLM이 약한 영역이지만, 안티그래비티 같은 도구에서 한 번의 요청(one-shot)만으로도 인상적인 화면을 뽑아냈다고 말한다. 다만 화면은 훌륭해도 페이지에 들어가는 실제 정보와 문구는 사실과 다르게 지어내는 경우가 많았다고 한다.

반대로 앤트로픽의 오퍼스 4.8은 UI를 만드는 능력은 제미나이만 못하지만, 전반적인 추론과 페이지 문구 설계, 백엔드·인증 같은 통합 작업에서 더 안정적이라고 평가한다. 그래서 두 모델 중 하나만 고르는 대신, 제미나이는 UI 디자인을, 오퍼스는 기획과 통합을 맡기는 혼합 워크플로를 구성했다고 소개한다.

이 워크플로의 가장 중요한 원칙은 모든 단계가 서로 다른 코딩 에이전트 세션이라는 점이다. 각 단계는 마크다운 핸드오프 문서를 만들어 다음 단계 시작 시 곧바로 읽히게 한다. 예컨대 첫 탐색 단계는 소넷으로 저장소와 명세를 훑어 context.md로 요약하고, 이를 기획 단계가 이어받는다.

단계를 이렇게 쪼개는 데는 두 가지 이유가 있다. 하나는 한 대화 창에서 프로바이더를 바꿀 방법이 사실상 없기 때문이고, 다른 하나는 각 세션이 한 가지 작업에만 집중해야 결과가 좋기 때문이다. 오퍼스처럼 뛰어난 모델도 탐색·기획·UI·통합을 한꺼번에 맡기면 사소하지 않은 앱에서는 무너진다고 강조한다.

전체 흐름은 탐색(소넷) → 기획(오퍼스, 콘텐츠·통합·배포의 3개 섹션) → UI 디자인(제미나이, Pi 또는 안티그래비티) → 통합·검증·수정 → 배포 → 브라우저 자동화로 사용자처럼 확인하는 스모크 테스트로 이어진다. 발표자는 이 방식이 모든 앱을 한 번에 만들어 주지는 않지만, 사소하지 않은 풀스택 앱의 개념 증명(PoC)이나 MVP에는 매우 잘 맞는다고 정리한다.

주요 인사이트

• 오퍼스가 기획 단계에서 사이트의 구조(그리드·열 배치 등)까지 지시하자, 제미나이의 디자인 강점을 눌러 결과물이 눈에 띄게 나빠졌다. 그래서 기획에는 콘텐츠와 의도만 담고 레이아웃은 제미나이에 맡긴다.
• 프로바이더 혼합은 품질뿐 아니라 비용 전략이기도 하다. 제미나이 3.5 플래시는 입력 100만 토큰당 약 1.5달러로, UI 반복 작업에 토큰을 넉넉히 쓰면서도 더 비싼 오퍼스는 기획에만 집중시킨다.
• 핸드오프 문서 방식은 실험과 검증에도 유리하다. 각 단계의 산출물을 사람이 확인하며 개입할 수 있고, 특정 단계의 모델을 손쉽게 다른 프로바이더로 바꿔 최적 조합을 찾을 수 있다.
• 탐색·검증처럼 추론이 크게 필요 없는 단계는 소넷 같은 가벼운 모델로 돌려 속도와 토큰을 아끼고, 기획·수정처럼 사고가 필요한 단계에만 오퍼스를 쓰는 식으로 작업별 모델 배분이 권장된다.

자주 묻는 질문

관련 AI 소식