AI를 시니어 개발자처럼 일하게 하려면 — 단계를 건너뛰지 못하게 묶는 6단계 워크플로

AI 코딩 도구는 속도를 늦춰야 결과가 빨라집니다. 기획 검증, 브레인스토밍, 서브 에이전트 위임, 규범 주입, 교차 모델 리뷰, 브라우저 테스트로 이어지는 6단계 큐레이션 스택과 도구를 1~2개부터 들이는 안전한 도입 순서를 실무 관점에서 정리했습니다.

2026년 6월 17일에버스톤13분 분량AI · 개발AI 도입 컨설팅

AI를 시니어 개발자처럼 일하게 하려면 — 단계를 건너뛰지 못하게 묶는 6단계 워크플로 대표 이미지

AI 코딩 도구에 요청하자마자 코드를 받으면 처음엔 빨라 보이지만, 뒤로 갈수록 디버깅이 끝나지 않습니다. 이 자료의 결론은 AI가 기획·설계·리뷰 단계를 건너뛰지 못하게 묶어야 전체 개발이 빨라진다는 것이고, 이를 위한 도구 조합을 6단계로 정리합니다.

이 문서는 NotebookLM(노트북 LM)으로 자료를 조사해 만든 문서입니다.

별점이 많은 도구가 좋은 도구는 아닙니다. 지금 필요한 능력은 큐레이션입니다
코드 작성 전에 기획 검증과 요구사항 정리를 강제하면 헛코딩이 줄어듭니다
긴 세션에서 생기는 컨텍스트 오염은 작업을 쪼개 서브 에이전트에 맡겨 막습니다
머지 직전에는 다른 회사 모델로 교차 리뷰해 한 모델의 맹점을 보완합니다
도구는 한꺼번에 깔지 말고 급한 문제 하나를 푸는 1~2개부터 시작합니다

도구를 고르는 기준부터

깃허브의 인스타그램화, 그리고 프롬프트 인젝션의 함정 슬라이드. 이제 가장 중요한 능력은 진짜를 골라내는 큐레이션(Curation)이라는 부제. 왼쪽 Gamified Ecosystem 에는 별 28,450개, Trending Now, 각종 배지가 붙은 AI-Auto-Enhancer-Pro 저장소 화면을 돋보기로 비추자 숨겨진 소스 코드 속 프롬프트 인젝션(Auto-Star, 조회 시 별 개수 증가)이 드러나며, 별점이 높다고 좋은 도구가 아니고 바이럴 마케팅과 AI를 속이는 프롬프트 인젝션이 난무하는 생태계라는 설명. 오른쪽 Pure Utility 에는 받침대 위 초록 피라미드와 함께 실제 성능과 직결되는, 무조건 작동하는 알짜배기 도구의 발굴이라는 설명

AI의 속도를 늦춰야 개발 속도가 빨라진다 슬라이드. 클로드가 단계를 건너뛰지 못하게 통제하여 최종 디버깅 시간을 1/10로 단축한다는 부제. 가로축은 개발 단계, 세로축은 디버깅 노력과 혼란도인 그래프에서 Vanilla Claude(묻자마자 코드를 뱉어냄) 곡선은 뒤로 갈수록 끝없는 엣지 케이스 디버깅으로 요동치고, Curated Stack 곡선은 초반 계획 및 아키텍처 설계 구간에서만 올라갔다가 2중 리뷰와 검증을 거쳐 낮게 유지된다. 아래에는 기획 → 테스트 작성 → 코드 작성 → 2중 리뷰 화살표 흐름

AI 도구 생태계에서 저장소의 인기 지표는 쉽게 부풀려집니다. 설치 전에 README보다 실제로 어떤 지시문이 들어 있는지를 먼저 읽어 보는 습관이 필요합니다. AI가 읽는 지시문에 의도하지 않은 명령이 섞여 있으면 그대로 실행되기 때문입니다.

두 번째 그래프가 이 자료 전체의 요지입니다. 초반에 설계 비용을 치르는 쪽이 전체 비용은 작습니다. "1/10 단축"은 자료 기준의 수치이고, 저희가 측정한 값은 아닙니다.

1~2단계 — 코드보다 요구사항이 먼저

막연한 아이디어를 날카롭게 정제하는 YC식 검증 슬라이드. 코드를 짜기 전 무의미한 헛코딩(Wasteful coding)을 원천 차단한다는 부제. 엉킨 실타래 모양의 모호한 아이디어가 깔때기를 지나며 진짜 수요가 있는가, 기존에는 어떻게 해결하고 있는가, 가장 좁은 진입점은 무엇인가라는 세 질문으로 걸러져 정밀한 요구사항으로 나온다. 오른쪽 상자에 Tool: G-Stack(Office 스킬), Y-Combinator(게리 탄) 셋업 적용

코드 작성 전, 완벽한 청사진을 그리는 브레인스토밍 슬라이드. 요구사항을 빠짐없이 정리한 후에만 코드를 출력하도록 AI를 통제한다는 부제. 클립보드의 Mandatory Pre-Flight Checklist 에 핵심 타겟 유저 정의, 프로젝트 성공 기준(Metrics) 확립, 해결하려는 본질적 문제 명확화 세 항목이 체크되어 있고, 잠긴 자물쇠가 열린 뒤에야 Start Coding 버튼이 활성화되는 그림. 오른쪽 터미널 창에 Tool: Superpowers(Brainstorming 스킬), plugin install superpowers

컨텍스트 오염을 막는 서브 에이전트 위임 개발 슬라이드. 하나의 세션으로 30분이 아닌 몇 시간 단위의 개발을 유지하는 비결이라는 부제. Main Agent 가 Sub-agent 1, 2, 3 에 작업을 나눠 주고 2-Stage AI Review 가 각 결과를 검증하는 구조도. The Problem — 기존 방식은 30분만 코딩해도 컨텍스트가 꼬이고 망가짐. The Solution — 큰 작업을 쪼개어 서브 에이전트에게 위임하고 1. 스펙 일치 여부, 2. 코드 품질을 교차 검증. 상단에 Tool: Superpowers(Sub-agent Driven Development)

실무에서 가장 효과가 큰 부분이 이 구간입니다. AI는 질문을 받으면 일단 답을 내려는 성향이 있어서, "아직 코드를 쓰지 말고 질문부터 하라"는 규칙을 명시해야 요구사항이 정리됩니다. 타깃 사용자와 성공 기준이 한 줄이라도 적혀 있으면 이후 리뷰에서도 판단 기준이 됩니다.

서브 에이전트 위임은 대화가 길어질수록 앞의 결정이 흐려지는 문제에 대한 처방입니다. 작업 단위를 작게 나누면 각 단위의 결과를 스펙과 대조하기도 쉬워집니다.

3~4단계 — 규범 주입과 리뷰

2년 전 과거의 코드를 차단하는 모던 스탠다드 필터 슬라이드. Vercel 팀의 공식 모범 사례를 강제 주입하여 일관된 코드톤을 유지한다는 부제. 왼쪽 useEffect 남용, 클라이언트/서버 컴포넌트 혼용 코드가 필터 장치를 통과하며 "이건 서버에서 처리해. 여긴 'use client'가 필요 없어."라는 말풍선과 함께 오른쪽의 Server Components(최신 React 패턴), Next.js App Router, Streaming SSR 로 바뀐다. 오른쪽 위에 Tool: Vercel React Best Practices(skills.sh 제공)

부끄러운 실수를 잡아내는 무자비한 AI 동료 슬라이드. 1인 개발자의 한계를 극복하는 필수 pre-PR 검증 단계라는 부제. 자식 컴포넌트 안에 useState 가 선언된 코드에 빨간 동그라미가 쳐지고, "유즈 스테이트가 왜 여기 있어? 부모 컴포넌트로 올려!"라는 메모가 붙어 있다. 아래 표에 Tool: mmap's GrillMe(구워줘), Action Rule: PR(Pull Request)을 올리기 전 무조건 코드를 통과시켜 논리적 허점과 상태 관리 오류를 색출할 것

직관에 의존하던 리팩토링의 구조화 슬라이드. 막막했던 추상화(Abstraction) 경계에 대한 명확한 가이드라인이라는 부제. 왼쪽 Monolithic 은 도형과 선이 뒤엉킨 덩어리, 오른쪽 Scalable Architecture 는 하나의 모듈이 세 개의 하위 모듈로 깔끔하게 나뉜 구조로 테스트 용이성과 재사용성에 체크 표시. 아래에 Tool: mmap's Improvement Architecture — 기존 코드를 분석하여 내가 너무 과하게 분리했는지, 더 쪼개야 하는지 1~2개의 최적화된 리팩토링 제안 제공

AI 모델은 학습 시점 이전의 코드 관행을 그대로 따라 하는 경향이 있습니다. 프레임워크가 빠르게 바뀌는 분야일수록 팀이 따르는 규칙을 문서로 만들어 AI에 먼저 읽히는 것이 리뷰 부담을 줄이는 방법입니다. 리뷰 단계도 사람이 보기 전에 AI에게 한 번 걸러 달라고 하면, 사람은 설계 판단처럼 AI가 약한 부분에 집중할 수 있습니다.

5~6단계 — 교차 검증과 테스트 자동화

단일 모델의 편향을 깨는 크로스 모델 QA 슬라이드. 클로드가 스스로 발견하지 못하는 논리적 맹점(Blind spots)을 차단한다는 부제. 두 원이 겹치는 벤 다이어그램에서 클로드의 시야(Claude)는 거시적 구조 파악, 코덱스의 시야(Codex)는 세부 구현부 스캔을 맡고 교집합에 경고 표시가 붙은 버그 아이콘. 오른쪽 위 Tool: OpenAI Codex Review 플러그인. 아래 설명은 워크플로우의 최후반부(Merge 직전), 완전히 다른 시각을 가진 OpenAI 모델의 눈으로 2차 검증 수행

압도적 속도의 브라우저 테스트와 산출물 자동화 슬라이드. QA 속도 극대화부터 클라이언트 최종 보고서까지라는 부제. 왼쪽 G-Stack Browse 는 100-200ms 응답을 가리키는 속도계와 헤드리스 크롬 초기화, 1920x1080 스크린샷 캡처, 콘솔 오류 2건 분석 로그가 찍힌 터미널로, 백그라운드 크롬 세션을 유지해 기존 방식보다 20배 빠른 테스트 환경이라는 설명. 오른쪽 PPTX / PDF Bonus Skills 는 RAW CODE 데이터가 PPTX 와 PDF 문서로 바뀌는 그림으로, 결과물 기반의 클라이언트용 보고서, 제안서, 표지 및 목차 자동 생성이라는 설명

같은 모델에게 자기 코드를 다시 보라고 하면 같은 전제를 공유하기 때문에 같은 실수를 지나칠 수 있습니다. 다른 회사의 모델을 리뷰어로 두는 방식은 비용이 조금 늘지만, 사람 리뷰어를 한 명 더 두는 것보다는 부담이 적습니다. 속도 수치(20배, 100~200ms)는 자료 기준입니다.

전체 스택과 시작하는 법

시니어 에이전트 큐레이션 스택(Master Workflow) 표. [1] 기획 & 검증 — G-Stack Office — 아이디어 정제 및 헛코딩 방지. [2] 설계 & 위임 — Superpowers — 구조화 및 서브 에이전트 분배. [3] 규범 적용 — Vercel Best Practices — 최신 코드톤 강제 주입. [4] 리뷰 & 리팩토링 — GrillMe / Improvement Arch. — 논리 검증 및 모듈화. [5] 교차 QA — Codex Review — 타 모델 기반 교차 맹점 검증. [6] 테스트 & 문서화 — G-Stack Browse / PPTX / PDF — 초고속 디버깅 및 산출물 자동화. 6단계에서 1단계로 되돌아가는 순환 화살표

컨텍스트 비대화를 피하는 안전한 시작 슬라이드. 100% 직접 검증된 오픈 베타 스킬 큐레이션 생태계라는 부제. skills.sh 창 안에서 왼쪽 Install All 버튼은 취소선과 경고 표시가 붙어 무분별한 설치는 AI 컨텍스트 창을 무겁게 만든다는 설명, 오른쪽 Start Small 버튼에는 커서가 올라가 시급한 문제를 해결하는 도구 1~2개부터 도입하라는 설명. 아래에 프롬프트 인젝션과 가짜 별점으로부터 안전한 큐레이션 샵에서 시작하라는 문장

표에 나온 도구 이름보다 단계의 순서가 더 오래 쓸 수 있는 내용입니다. 도구는 몇 달 단위로 바뀌지만, 기획 검증 → 설계 → 규범 → 리뷰 → 교차 검증 → 테스트라는 순서는 사람으로 구성된 팀의 개발 프로세스와 같습니다. 도구를 많이 깔수록 AI가 매번 읽어야 할 지시문이 늘어나 오히려 품질이 떨어질 수 있다는 마지막 경고도 실무에서 자주 겪는 일입니다.

자주 묻는 질문

AI 코딩 도구를 처음 도입할 때 무엇부터 해야 하나요? 코드 작성 전에 요구사항을 정리하게 만드는 규칙부터 두는 것이 좋습니다. 가장 적은 비용으로 헛코딩을 줄일 수 있는 단계이고, 이후 리뷰의 기준도 됩니다.

교차 모델 리뷰는 꼭 필요한가요? 모든 변경에 필요하지는 않습니다. 결제·인증처럼 틀리면 비용이 큰 코드나 머지 직전의 큰 변경에 한정해 쓰면 비용 대비 효과가 좋습니다.

플러그인이나 스킬은 몇 개까지 설치하는 게 적당한가요? 정해진 숫자는 없지만 자료는 1~2개로 시작하라고 권합니다. 지시문이 많을수록 AI가 읽을 컨텍스트가 무거워져 응답 품질이 흔들릴 수 있습니다.

GitHub 별점이 많은 도구는 믿어도 되나요? 별점만으로 판단하기는 어렵습니다. 설치 전에 실제 지시문과 스크립트를 열어 보고, 의도하지 않은 명령이 없는지 확인하는 편이 안전합니다.

저희가 이 이야기를 하는 이유

에버스톤은 2013년부터 부산에서 모바일 게임과 앱, 웹·업무 시스템을 개발해 왔고, 지금은 자체 개발에도 AI 코딩 도구를 쓰고 있습니다. 써 보면서 느낀 것도 이 자료와 비슷합니다. 도구를 늘리는 것보다 요구사항 정리와 리뷰 단계를 지키게 하는 쪽이 결과물 품질에 더 큰 영향을 줍니다. AI 도입 컨설팅에서도 이 순서를 먼저 권합니다.

인용한 도구 이름, 수치(400시간·10개월 검증, 디버깅 1/10, 테스트 20배 등)와 사례는 원 자료 기준이며, 저희가 검증한 내용이 아닙니다.