슬라이드 대신 프로토타입 가져가기: Shopify의 Codex 활용과 아키텍처 탐색 패턴

OpenAI가 공개한 Shopify의 Mikhail Parakhin 인터뷰 영상은 수천 명 규모의 엔지니어링 조직에서 코딩 에이전트가 의사결정 방식을 어떻게 바꾸는지를 다룬다. Codex Originals 시리즈에 등장한 Mikhail Parakhin은 매일 아침 상세한 명세서 없이 작업 목록을 에이전트에게 맡기고, 회의 시간에 정적인 와이어프레임(wireframe)이나 슬라이드 대신 작동하는 프로토타입을 바로 가져오는 규칙을 소개한다.

결론부터 말하면, 에이전트 도입의 가장 큰 변화는 기존 개발 단계를 조금 더 빠르게 처리하는 데 그치지 않고, 시간 제약 때문에 하나만 골라야 했던 여러 아키텍처 대안을 동시에 구현·비교하고 작동하는 코드로 논의를 시작하게 만드는 데 있다. 다만 이 글은 OpenAI가 공개한 인터뷰 영상과 화면에 등장한 프롬프트 구성을 바탕으로 엔지니어링 워크플로를 정리한 것이며, 조직 전체의 정량적인 생산성 지표를 별도로 검증한 결과는 아니다.

와이어프레임과 슬라이드 없는 기획 회의

전통적인 제품 개발에서는 코드를 작성하는 비용이 높기 때문에, 구현 전에 슬라이드나 와이어프레임으로 아이디어를 설명하고 합의를 거치는 단계가 필수적이었다. 하지만 정적인 그림만으로는 실제 상호작용이나 기술적 병목을 확인하기 어렵다.

Mikhail Parakhin이 설명하는 변화는 명확하다. 프로토타입을 만드는 비용이 급격히 낮아졌기 때문에, 아이디어가 있다면 슬라이드 대신 작동하는 프로토타입을 바로 회의에 가져오도록 기준을 바꾼 것이다.

One thing we started doing now is you're not allowed to bring into the meeting just wireframes or slides. If you have an idea, bring a prototype right away because it's so easy.

이는 기획과 구현의 순서를 바꾸는 접근이다. 문서로 길게 설득한 뒤 첫 코드를 짜는 대신, 에이전트가 빠르게 만든 초기 프로토타입을 먼저 실행해 보고 그 위에서 아키텍처와 제품 방향을 결정하는 방식이다.

화면에 공개된 3가지 프롬프트 패턴

영상(00:12, 00:19, 00:44 부근)에서는 GPT-6 Astra(Extra High 추론 설정)와 Approve for me 옵션을 켜고 실행하는 세 가지 구체적인 프롬프트가 등장한다. 모두 상세한 구현 절차를 일일이 지시하기보다, 목표와 검토 기준을 위임하는 형태를 띤다.

단계	화면에 등장한 프롬프트 원문	워크플로 내 역할
1. 개념에서 프로토타입 생성	`Take this idea from concept to working prototype. Review the repo, map the architecture, break the work into tasks, implement the core workflow, add tests, and flag any key decisions or risks for my review.`	저장소 구조 파악부터 핵심 워크플로 구현, 테스트 추가, 주요 의사결정·리스크 식별까지 한 번에 위임
2. 프로토타입 정제 및 단순화	`Review the prototype against the original goal. Fix the highest-impact issues, simplify anything over-engineered, rerun tests, and summarize what changed and what still needs a decision.`	초기 생성물에서 과도하게 복잡한(over-engineered) 코드를 덜어내고 사람의 결정이 필요한 항목만 요약
3. 복수 아키텍처 대안 탐색	`Research the architectural options for this project. Compare the tradeoffs, explore each path, and organize the next steps for my review.`	단일 설계에 바로 묶이지 않고 여러 아키텍처 선택지의 트레이드오프를 병렬로 탐색

여기서 가장 실용적인 패턴은 두 번째 단계인 과잉 설계 단순화(simplify anything over-engineered)와 미결 사항 분리(what still needs a decision)다. 에이전트가 처음 만든 코드는 불필요한 추상화가 섞이기 쉬운데, 이를 사람이 직접 다 고치는 대신 에이전트에게 다시 원래 목표와 대조해 단순화하도록 지시하고 사람은 핵심 의사결정 지점만 검토하는 흐름이다. 장기 실행 작업 가이드

아키텍처 대안을 모두 탐색한다는 것의 의미

일정이 촉박한 프로젝트에서는 아키텍처 후보가 세 가지 있어도 직관에 의존해 하나만 골라 구현에 들어가는 경우가 많다. 실패 비용이 크다 보니 안전한 기존 방식을 반복하게 된다.

반면 에이전트에게 각 아키텍처 경로의 탐색과 초기 구현을 맡기면, 이전에는 시간 부족으로 포기했던 대안들을 실제로 비교해 볼 수 있다. 영상에서 강조하듯 이전에 하던 일을 더 빨리 하는 것(doing things faster)과, 이전에는 비용 때문에 시도조차 못 하던 다중 탐색을 수행하는 것(doing things you previously couldn't do)은 구분해서 봐야 한다.

프로토타입 중심 워크플로를 도입할 때 확인할 점

실무 팀에서 “슬라이드 대신 프로토타입” 원칙과 위임형 프롬프트를 적용할 때는 다음 경계를 명확히 해두는 편이 안전하다.

프로토타입과 프로덕션 코드의 경계: 회의를 위해 빠르게 만든 프로토타입이 보안·성능 검증 없이 그대로 메인 브랜치에 합쳐지지 않도록, 검증용 코드와 배포용 코드의 기준을 분리한다.

과잉 설계(Over-engineering) 점검 단계 포함: 에이전트에게 구현만 시키고 끝내지 말고, 2단계 프롬프트처럼 불필요한 복잡성을 줄이고 변경 요약과 미결 리스크(flag any key decisions or risks)를 보고하게 만든다.

의사결정 병목 관리: 에이전트가 프로토타입과 아키텍처 비교표를 빠르게 쏟아낼수록, 이를 검토하고 방향을 확정하는 사람의 리뷰 역량이 새로운 병목이 될 수 있다. 무엇을 사람이 결정할지(what still needs a decision)를 명확히 추려 받는 프롬프트 설계가 중요하다.

결국 에이전트를 또 하나의 실행 팀처럼 활용하려면, 사람이 모든 세부 구현 지시서를 작성하는 병목에서 벗어나야 한다. 에이전트에게는 구조 파악과 초안 구현·단순화를 맡기고, 개발자와 리더는 추출된 리스크와 아키텍처 트레이드오프를 결정하는 데 집중하는 것이 핵심이다.