당신의 AI 코딩 워크플로우는 잘못되었습니다.

대부분의 개발자들은 동일한 벽에 부딪힙니다: 커서나 VS 코드(CURSOR or VS CODE)를 열고, 클로드(Claude)나 GPT-4를 실행하고, 기발한 프롬프트를 입력하면 거의 작동하는 200줄의 코드가 생성되는 모습을 지켜보게 됩니다. 처음 10분은 마법 같지만, 다음 2시간은 오프 바이 원 오류, 누락된 임포트, 실제 데이터 모델과 일치하지 않는 함수들을 수정하는 데 사라집니다.

그 고통은 조용한 실패 모드에서 비롯됩니다: 맥락 부패. 대규모 모델은 수만 개의 토큰을 다루지만, 당신의 프로젝트는 여러 파일, API 계약, 그리고 반쯤 기억나지 않는 설계 결정으로 인해 빠르게 이를 초과합니다. 세 번째 또는 네 번째 프롬프트에서는 AI가 더 이상 Postgres를 Firebase보다 선택한 이유나 사용자 역할이 별도의 서비스에 존재하는 이유를 "기억"하지 못합니다.

컨텍스트 부패는 모델이 이전에 리팩토링했던 오래된 패턴을 자신 있게 다시 도입할 때 나타납니다. 당신은 새로운 `BillingClient`로 업데이트해 달라고 요청하지만, 모델은 이전 메시지에서 사용되었던 구식의 `StripeService`를 되살립니다. 환경 변수 이름을 잊고, 타입을 재창조하며, 당신의 실제 아키텍처에서 점차 멀어집니다.

그런 변화는 치명적인 하류 비용을 초래합니다. 정교하고 면밀한 수정 사항 대신, 파일에 흩어져 있는 새로운 헬퍼 함수, 중복된 로직, 일관되지 않은 오류 처리 등 다양한 변경 사항이 섞인 잡다한 결과물을 얻게 됩니다. 각 AI 수정 작업은 이 혼란을 악화시켜, 디버깅이 단일 버그에 관한 것이 아니라 동일한 기능의 세 가지 약간 다른 버전을 조정하는 문제로 변하게 됩니다.

개발자들은 5-10개 이상의 파일이 있는 프로젝트에서 코드를 작성하는 것보다 AI 출력물을 검토하는 데 더 많은 시간을 할애하고 있음을 보고하고 있습니다. 다음과 같은 문제가 발생합니다: - 형식이 상충하는 중복 DTO - 동일한 개념에 대한 상이한 네이밍 규칙 - 공용 인터페이스에 대한 무음의 파손 변화

순진한 프롬프트는 가짜 자신감 뒤에 복잡성을 숨깁니다. 모델은 기꺼이 리프레시 토큰, PKCE 또는 적절한 토큰 저장을 무시하는 "작동하는" OAuth 흐름을 생성하여, 겉보기에는 괜찮아 보이지만 실제로는 보안상의 책임이 있는 결과를 남깁니다. 데이터베이스 마이그레이션, 백그라운드 작업 및 캐싱 계층에서도 동일한 일이 발생합니다.

진지한 AI 코딩 워크플로우는 모델을 시스템의 일부분으로 간주하며, 요정처럼 다루지 않습니다. 이는 계획, 명확한 프로젝트 맥락, 그리고 AI가 마지막 메시지가 아닌 실제 코드베이스에 집중할 수 있도록 하는 스택 인식 프롬프트를 의미합니다.

“챗봇을 자극하는 것”에서 시스템을 운영하는 것으로 전환하세요. 이는 레이 페르난도와 콜 메딘이 계속해서 강조하는 핵심 철학입니다. 진지한 AI 코딩이란 엔지니어가 파이프라인을 운영하듯 모델, 도구, 컨텍스트를 조율하는 것을 의미합니다. 단순히 코드를 요청하는 것이 아니라 모델이 여러분의 프로젝트에 대해 알고, 보고, 기억하는 방식을 형성합니다.

전통적인 프롬프트 엔지니어링은 한 가지 메시지에 집중합니다: 쿼리를 다듬고 제약 조건을 추가하며, 어쩌면 코드 스니펫을 붙여넣는 것입니다. 이는 도움이 되지만, 모든 상호작용이 모델의 이해를 리셋하기 때문에 빠르게 한계에 도달하게 됩니다. 좁은 질문에 대한 스마트한 답변을 얻을 수는 있지만, 레포, 아키텍처, 로드맵을 이해하는 협력자는 아닙니다.

컨텍스트 엔지니어링은 그것을 뒤집습니다. AI가 귀하의 스택, 즉 문서, 스키마, API, 데이터 흐름 및 제약 조건을 어떻게 소화할지를 설계합니다. 단일의 기발한 프롬프트 대신, 저장소 인덱서, 프로젝트 요약 및 모든 요청과 함께 전송되는 구조화된 “시스템” 프롬프트와 같은 도구를 활용하여 지속적인 프로젝트 브레인을 구축합니다.

Ray의 워크플로우는 8K, 32K 또는 200K 토큰의 문맥 창을 희소하고 고가치 자원으로 취급합니다. 그는 높은 신호를 가진 아티팩트를 선별할 것을 권장합니다: 한 페이지의 아키텍처 개요, 기능 사양, 데이터 모델, 의존성 맵. 이러한 자료들은 새로운 기능 작업 전에 Cursor, Claude 또는 GPT 스타일 모델에 주입하는 재사용 가능한 문맥 블록으로 존재합니다.

선임 엔지니어와 새로운 인턴의 차이점으로 생각해 보세요. 선임 엔지니어는 디자인 문서를 읽었고, 트레이드오프를 이해하며, 6개월 전에 있었던 이상한 마이그레이션을 기억합니다. 반면 인턴은 당신이 건넨 파일 하나만 보고, 왜 구조가 이렇게 되어 있는지 전혀 알지 못합니다.

프롬프트 중심의 워크플로우는 AI를 반응적인 인턴으로 바꾸어 놓습니다: 즉흥적이고, 편협하며, 기존 패턴에 끊임없이 놀랍니다. 반면, 맥락 설계된 워크플로우는 AI를 모듈 간의 논리를 이해하고, 아키텍처 회귀를 포착하며, 일관된 추상화를 제안할 수 있는 선임 개발자로 변모시킵니다. 동일한 모델이지만, 행동이 극적으로 다릅니다.

AI 스택을 장난감이 아닌 인프라처럼 운영하세요. 자신이 컨텍스트 엔지니어라는 것을 내재화하면, 문서 작성 방식, 리포지토리 구조화 방식, 모델과 소통하는 방식 등 작업 흐름의 모든 부분이 변합니다.

청사진 우선의 워크플로우는 매우 저기술적인 것에서 시작합니다: 서면 계획입니다. 레이 페르난도는 이를 절대 양보할 수 없는 것으로 여기며, 프로젝트 문서가 미니 제품 사양, 아키텍처 스케치, 테스트 계획이 결합된 것처럼 읽힐 때까지 커서나 클로드를 열기를 거부합니다.

그 문서는 기능 요구사항을 일반적인 언어로 시작합니다. 그는 사용자 스토리, 명확한 "완료" 기준, 성능 목표, 지연 예산 또는 브라우저 지원과 같은 제약 조건을 작성하여 모델이 잘못된 목표를 조용히 최적화하지 못하도록 합니다.

다음은 데이터 흐름입니다. Ray는 엔티티, 입력, 출력 및 데이터가 시스템 내에서 어떻게 이동하는지를 매핑합니다: 요청 페이로드, 데이터베이스 스키마, 캐시 레이어, 외부 API, 그리고 백그라운드 작업. 만약 기능이 인증, 청구 및 알림에 영향을 미친다면, 코드 한 줄이 존재하기 전에 각 단계가 명명되고 설명됩니다.

그는 모델의 기본 설정에 맡기지 않고 기술 스택 결정을 확정합니다. 계획에는 언어, 프레임워크, ORM, 큐 시스템, 테스트 도구, 배포 대상을 포함하여 종종 버전까지 명시됩니다: “Next.js 15, React Server Components, PostgreSQL과 함께하는 Prisma, 속도 제한을 위한 Redis, 단위 테스트를 위한 Vitest, CI를 위한 GitHub Actions.”

레이는 엣지 케이스와 실패 모드에 대해서도 강제로 패스를 요구합니다. 그는 “부분 결제 성공”, “웹훅 재시도”, “오래된 JWT” 또는 “모바일 오프라인 동기화”와 같은 시나리오를 나열하고, 시스템이 어떻게 저하되거나 복구되어야 하는지를 지적합니다. 이러한 항목들은 나중에 테스트 프롬프트와 모니터링 체크로 발전합니다.

그 초기 문서는 전체 AI 세션의 시드 컨텍스트가 됩니다. 그는 그것을 새 채팅창에 붙여넣고 계약처럼 다룹니다: 이후의 모든 프롬프트는 프로젝트를 처음부터 다시 설명하는 대신 계획의 섹션을 참조합니다.

이 단계는 모델이 아키텍처를 만들어내는 것을 차단합니다. 원래 Postgres를 원했을 때 놀라운 MongoDB가 나오지 않고, 단일 구조체가 필요할 때 신비로운 마이크로서비스가 등장하지 않으며, 이미 Auth0를 사용 중일 때 자동 생성된 인증이 발생하지 않습니다. 모델은 당신이 그린 틀 안에서만 '창의적'일 수 있습니다.

이 분야의 실제 사례를 Ray Fernando YouTube 채널 – AI 코딩 및 워크플로우에서 그의 라이브 빌드와 심층 분석을 통해 확인할 수 있습니다. 여기서는 프롬프트가 아닌 계획이 전체 코딩 세션을 이끌어갑니다.

컨텍스트는 당신의 AI 페어 프로그래머를 위한 RAM처럼 작용합니다: 빠르고 강력하며 절대적으로 제한적입니다. 현대의 대형 언어 모델(LLM)은 8,000에서 200,000 토큰까지 처리할 수 있지만, 프레임워크 글루 코드, 타사 라이브러리 및 문서화가 부족한 서비스가 추가되면 그 공간이 놀라울 정도로 빠르게 차버립니다. 그 공간을 바닥이 없는 구덩이가 아닌 예산으로 취급하세요.

대부분의 개발자들은 모델이 한계에 도달할 때까지 원본 파일을 붙여넣어 이 예산을 소진합니다. 이로 인해 부분적인 이해, 허구의 인터페이스, 잘못된 모듈에 대한 "유용한" 재작성만을 얻게 됩니다. Ray Fernando의 접근 방식은 이를 뒤집습니다: 매 요청에 함께 따라다니는 간결하고 신호가 강한 프로젝트 요약에 조기에 투자하여 모델이 즉시 방향을 잡을 수 있도록 합니다.

자동화된 프로젝트 인덱서가 여기서 핵심 도구입니다. 120개의 파일을 제공하는 대신, 레포 크기의 2–5%에 해당하는 구조화된 “목차”를 생성하여 AI에 필요한 정보의 80–90%를 포함할 수 있습니다. 이 인덱스는 다음을 포함할 수 있습니다: - 고수준 아키텍처 - 주요 모듈과 그 책임 - 데이터 모델 및 관계 - 외부 API와 통합 지점

Cursor, Windsurf와 맞춤형 CLI 스크립트 같은 도구들은 프로젝트가 발전함에 따라 이 인덱스를 유지할 수 있습니다. Cursor의 레포 수준 프롬프트는 이 요약을 지속적인 지침으로 고정할 수 있게 해 주며, 모든 채팅, 수정 및 "이것 수정하기" 명령이 동일한 공유된 사고 모델을 통해 실행됩니다. 이는 AI에게 처음부터 스택을 다시 설명하는 대신 지속적인 디자인 문서를 제공하는 것과 같습니다.

시스템 프롬프트는 해당 컨텍스트 위에 정책 레이어로 작용합니다. 커서에서는 "인증을 건드리지 마세요", "함수형 React 컴포넌트를 선호하세요" 또는 "모든 새로운 코드는 Jest 테스트를 포함해야 합니다"와 같은 규칙을 정의할 수 있습니다. 이러한 가이드라인은 개별 메시지 위에 존재하므로, AI는 작은 차이에 집중하고 있을 때에도 이를 준수합니다.

높은 신호의 맥락이 항상 원시 볼륨을 이깁니다. 1,500토큰의 아키텍처 요약, 데이터 스키마 및 라우팅 맵이 필터링되지 않은 20,000토큰의 컨트롤러, 유틸리티 및 불필요한 코드보다 더 나은 성능을 발휘합니다. AI가 당신의 node_modules를 헤치고 다니지 말고 맵을 읽도록 해야 합니다.

노이즈는 하드 토큰 한계에 도달하기 훨씬 이전에 모델 성능을 저하시킵니다. 프로젝트 인덱스와 리포 프롬프트를 구성함으로써 코드베이스를 모델이 일관되게 추론할 수 있는 형태로 압축할 수 있습니다. 이는 "파일을 붙여넣어 문제가 발생할 때까지"에서 실제 컨텍스트 엔지니어링된 워크플로우를 운영하는 것으로의 도약입니다.

대부분의 사람들은 가장 똑똑한 모델을 빠른 타이피스트처럼 대합니다. 그러나 레이 페르난도와 콜 미딘 같은 워크플로우 엔지니어들은 이를 최고 설계자처럼 대합니다. 당신은 클로드 3 오푸스나 GPT-4 터보에게 단순히 for-loop을 작성하라고 돈을 주는 것이 아닙니다; 당신은 무엇이 처음에 존재해야 하는지를 결정하도록 그들에게 보상을 주는 것입니다.

최고 수준의 모델을 사용하여 고밀도 사고를 진행하세요: 시스템 설계, 트레이드오프 분석 및 실패 모드. 여러 아키텍처를 제안하고, 이를 비교하며 데이터 모델, API 경계 및 배포에 대한 선택의 이유를 제시하도록 하세요. 구성 요소, 책임, 인터페이스 및 단계별 구현 계획을 포함한 기술 사양서를 출력하도록 하세요.

그 "아키텍트 패스"는 몇 달러의 API 호출 비용이 들 수 있지만, 어려운 사고 과정을 사전에 정리합니다. 명시적인 가정, 제약 조건, 그리고 위험 요소가 포함된 계획을 얻으며, 이는 수석 엔지니어의 설계 문서처럼 검토할 수 있습니다. 승인을 받으면, 그 사양을 동결하여 이후 모든 것의 단일 진실 출처로 삼습니다.

그런 다음 저렴하고 빠른 모델인 Claude 3 Haiku, GPT-4o mini 또는 AI IDE의 내장 도우미로 전환하여 계획을 실행합니다. 관련 사양의 일부와 로컬 파일만 제공하고, 작고 배포 가능한 차이를 요청하세요: 단일 모듈, 테스트 모음 또는 마이그레이션 스크립트. 검토하고, 테스트를 실행하며, 프리미엄 토큰을 낭비하지 않고도 빠른 속도로 반복하세요.

전형적인 스택은 다음과 같을 수 있습니다: - Claude 3 Opus / GPT-4 Turbo: 아키텍처, 사양, 리스크 분석 - Claude 3 Sonnet / GPT-4o: 기능 수준 코드, 리팩토링, 문서 - Claude 3 Haiku / GPT-4o 미니: 보일러플레이트, 테스트, 소소한 수정

이 "설계 후 실행" 패턴은 품질을 극대화하고 비용을 통제합니다. 비싼 사고 과정을 몇 번의 신호가 뚜렷한 통과로 집중시킨 다음, 저렴한 모델이 반복적인 코딩을 처리하도록 맡깁니다. 또한 변동성을 줄입니다: 모든 변경 사항이 검토된 계획으로 다시 추적될 때, 더 적은 수의 신비한 회귀 및 상황에 의해 유발된 환상에 대처하게 됩니다.

시간이 지남에 따라 요구 사항이 변경되면 사양을 다시 생성할 수 있으며, 그 후 영향을 받은 구현 단계만 다시 실행할 수 있습니다. 그 결과는 로봇과 대화하는 것처럼 느껴지기보다는 소프트웨어 아이디어에 대한 빌드 시스템을 운영하는 것에 더 가깝습니다.

현대 AI 코딩 워크플로는 점점 더 단일 채팅 창처럼 보이지 않고, 오히려 소규모의 전문 에이전트 스튜디오처럼 보입니다. 각 채팅 세션은 고유한 맥락, 역사 및 제약이 있는 특정 문제를 위한 작업대가 되어, 모든 것을 기억하려는 혼란스러운 다목적 스레드 대신 됩니다.

전체 스택 기능을 상상해 보세요: 아바타와 활동 피드를 갖춘 사용자 프로필. 한 에이전트는 순전히 데이터베이스 스키마와 데이터 모델에 집중하고, 또 다른 에이전트는 React UI를 처리하며, 세 번째 에이전트는 통합 배선 및 API 계약을 관리합니다.

데이터베이스 스레드에서는 테이블, 인덱스 및 마이그레이션과 관련된 모든 것을 저장합니다. PostgreSQL 스키마를 반복하고, Prisma 모델을 생성하며, 외래 키와 성능에 대해 논의할 수 있도록 요청합니다. 이 모든 과정은 React 컴포넌트나 CSS가 그 맥락을 오염시키지 않도록 합니다.

한편, 별도의 React 스레드는 레이아웃, 상태 관리 및 컴포넌트 구조를 소유합니다. 이 스레드는 훅, 프롭 및 Tailwind 클래스의 세부 사항에 깊이 들어갈 수 있으며, 당신이 붙여넣는 API 형태만 참조하고 전체 백엔드 코드베이스는 참조하지 않을 수 있습니다.

이것은 Cursor, Replit, GitHub Copilot Workspace와 같은 AI IDE가 다중 에이전트 사고로 나아가도록 유도하는 방식과 유사합니다. 이들은 다음을 장려합니다: - 고수준 설계를 위한 하나의 "아키텍트" 채팅 - 특정 변경 사항을 위한 지역화된 "파일" 또는 "diff" 채팅 - 관련된 코드만을 표면에 드러내는 배경 인덱서

레이 페르난도의 시스템은 이러한 패턴을 냉철한 맥락 분리로 정립합니다. 그의 마이 프로 클로드 코드 워크플로 – 레이 페르난도 워크스루는 스키마 설계, API 계약 및 UI 흐름을 위한 새로운 클로드 세션을 설정한 다음, 이를 마스터 프로젝트 브리프를 통해 연결하는 방법을 보여줍니다.

이 접근법은 맥락 오염에 직접적으로 대처합니다. 이는 단일 과도하게 배치된 채팅이 반쯤 기억난 결정과 모순된 지침으로 탈선되는 현상입니다. 문제를 분리함으로써 각 모델 인스턴스를 "정신적으로" 좁고 높은 신호로 유지하여 환상과 충돌하는 제안을 줄입니다.

주요 고수준 대화는 목표, 제약, 이정표, 그리고 거래를 깔끔하게 유지합니다. 하위 에이전트는 "어떻게"를 처리하지만, 주된 주제는 "왜"를 지키며 프로젝트의 진실의 원천 역할을 합니다.

방향을 조정해야 할 때, 먼저 마스터 플랜을 업데이트한 다음, 변경 사항을 전문 채팅으로 전파합니다. 이러한 위에서 아래로 흐르는 방식은 복잡한 프롬프트 더미를 명확한 다중 에이전트 워크플로우로 전환시켜, 이를 분석하고 디버깅하며 개선할 수 있게 합니다.

대규모 AI 생성 풀 리퀘스트는 인상적이지만 누군가 이를 검토하려고 하면 상황이 달라진다. 800줄에 달하는 차이 분석이 14개의 파일에 걸쳐 있으며, 리팩토링, 새로운 기능, 그리고 즉흥적인 수정이 뒤섞여 있다. 어떤 인간이나 코드 소유자 봇도 그런 종류의 변경 사항을 신뢰성 있게 검증할 수 없으므로, 팀들은 이를 단순히 승인하거나 영원히 차단하는 두 가지 선택만 할 수 있다.

현대 AI 작업 흐름은 스택된 차이로 그 혼란을 극복합니다. 하나의 대규모 커밋 대신, 작은 논리적으로 격리된 변경 사항의 시퀀스로 작업을 수직적으로 나누어 제작합니다: 여기서 타입 조정, 거기서 새로운 헬퍼, 그 다음 기능 연결, 그리고 테스트입니다. 각 단계는 컴파일되고 실행되며 독립적으로 배포할 수 있습니다.

실제로, 모델이 레포 수준이 아니라 diff 수준에서 작동하도록 안내합니다. "X에 대한 데이터 모델만 추가하는 단일 최소 커밋을 제안해 주세요. 컨트롤러, UI, 테스트는 아직 포함하지 마세요."라고 말한 뒤, 현재의 git diff를 붙여넣고 그 패치를 다듬도록 요청합니다. 변경 사항이 검토 가능하다고 느껴질 때까지 멈추세요.

좋은 스택 워크플로우는 명시적인 마이크로 프롬프트로 전환됩니다. 예를 들어:

• 11단계: 인터페이스와 타입만 추가하세요.
• 2“2단계: 해당 유형을 사용하는 순수 함수를 추가하세요.”
• 3"3단계: 기존 엔드포인트에 통합하기."
• 4“4단계: 새로운 동작에 대한 테스트와 문서를 추가하세요.”

각 단계는 GitHub, GitLab 또는 Phabricator와 같은 도구가 자체 diff 스택으로 표시할 수 있는 별도의 분기 또는 커밋이 됩니다. 리뷰어는 “유효성 검사 헬퍼 추가”라는 40줄의 변경 사항을 보고, 인증을 조용히 재작성하는 400줄의 서프라이즈를 보지 않습니다. AI와 인간 모두에게 맥락을 간결하게 유지합니다.

스택 디프는 AI를 코드 배급기에서 통제된 변경 생성기로 전환합니다. 이를 통해 더 작은 폭발 반경, 쉬운 롤백, 깔끔한 git 히스토리, 그리고 현실적인 코드 리뷰를 얻을 수 있어 AI가 작성한 코드를 실제로 생산 팀의 주요 브랜치에 안전하게 머지할 수 있게 됩니다.

좋은 AI 작업 흐름의 직관에 어긋나는 현실: 시간이 지나면서 모델에 대한 필요성을 줄인다. 만약 당신의 구성 방식이 매주 자동 완성과 채팅 스레드에 더 의존하게 만든다면, 당신은 AI로 코딩하는 것이 아니라, 당신의 두뇌를 AI에 아웃소싱하고 있는 것이다.

모델을 소크라테스 식 파트너로 대하고, 자판기로 취급하지 마십시오. 중요한 변경 사항이 있을 때마다 코드가 무엇을 하는지, 이 설계가 다른 대안보다 나은 이유, 그리고 어디에서 문제가 발생할 가능성이 있는지 설명하도록 요청하세요. 스스로 논쟁하게 하십시오: "이 접근 방식의 약점을 3가지 나열하고 더 안전한 패턴을 제안하세요."

모델을 활용해 평소 급하게 넘어가던 아티팩트를 생성하세요: 다이어그램, 문서, 서사. 다음을 생성하게 하세요: - 요청 파이프라인에 대한 시퀀스 다이어그램 - 주요 엔티티에 대한 데이터 흐름 맵 - 일반 언어로 작성된 한 페이지 아키텍처 개요

그 결과물을 장식용이 아니라 학습 자료로 사용하세요. AI가 생성한 아키텍처 문서를 읽고 나서 “이 서비스를 샤딩한다고 가정하고 이 다이어그램을 다시 그려줘” 혹은 “이 내용을 주니어 개발자에게 5개의 핵심 포인트로 설명해줘”와 같은 후속 질문을 하세요. AI가 반복적인 그리기와 형식을 처리하는 동안 당신은 시스템에 대한 자신의 사고 모델을 훈련하고 있습니다.

적극적으로 암기를 줄이세요. 모든 헬퍼 함수나 설정 플래그를 기억하려고 하기보다는 AI가 살아있는 인덱스를 유지하도록 하세요: “각 모듈의 책임을 1~2줄로 요약하세요.” 이렇게 하면 제한된 작업 기억이 줄 번호가 아닌 개념의 캐시로 바뀝니다.

주 동안, 이로 인해 권력의 균형이 바뀝니다. 당신은 AI를 사용하여 구조를 잡기 시작합니다 — 보일러플레이트, 마이그레이션, 테스트 하네스 — 그러면서도 아키텍처, 불변 조건, 실패 모드는 여전히 당신이 소유합니다. 모델은 빠른 페어 프로그래머가 되며, 주 엔지니어가 아닙니다.

레이다 펀란도와 콜 메딘이 옹호하는 성숙한 워크플로우는 궁극적인 숙련으로 나아갑니다. 기능을 구상하고, 대부분(80%)을 스스로 구현한 다음, 인공지능을 활용해 특정 리팩토링, 테스트 및 엣지 케이스를 처리할 수 있어야 합니다. 최종 목표는 인공지능이 당신을 가속화하지만, 당신의 이해가 제품을 구현하는 것입니다.

하루를 시작할 때, 당신이 구축하고 있는 것, 그 이유, 그리고 그것이 효과가 있는지 아는 방법에 대해 3-5 문장으로 간단히 서술하세요. 이것이 당신의 씨앗 맥락입니다. 제약 조건을 포함하세요: 대상 API, 성능 기대치, 및 수정하지 말아야 할 코드베이스의 영역.

다음으로, 해당 설명을 마이크로 사양으로 변환하세요. "/users 엔드포인트에 페이지네이션 추가" 또는 "모든 실패한 인증 시도 기록"과 같은 3~7개의 구체적인 결과 체크리스트를 추가하세요. 이제 당신과 AI 조수 간의 작은 감사 가능한 계약이 생겼습니다.

새로운 AI 세션을 엽니다. 계획을 붙여넣고 프로젝트의 인덱스 파일을 첨부하거나 붙여넣습니다: 라우트 맵, 주요 진입점, 스키마 파일 및 구성. 모델이 앱의 구조를 볼 수 있도록 하고, 모든 임의의 유틸리티는 제외해야 합니다.

IDE가 리포지토리 컨텍스트(커서, GitHub Copilot 작업 공간, Codeium)를 지원한다면 리포지토리를 지정하되 계획을 강조하세요. 모델에게 작업에 대한 이해를 5–10개의 핵심 포인트로 재진술하도록 요청하세요. 10–20%라도 부정확한 부분이 있다면 수정하세요. 그 오류는 모든 제안에 반영될 것입니다.

정렬이 잠금 해제된 상태에서 AI에게 명확히 말하세요: “이것을 스택형 차이로 구현하십시오. 한 번에 하나의 논리적 변경입니다.” 이제 당신의 스탠드업은 다음의 반복이 됩니다: - 다음 가장 작은 차이를 제안합니다 - 영향을 받을 파일을 보여줍니다 - 패치를 생성합니다 - 당신이 검토하고 테스트를 실행합니다

한 화면 또는 두 화면에 맞는 패치를 고집하세요. 변경 사항이 5개 이상의 파일이나 150–200줄을 넘는 경우, “더 작고 검토 가능한 단계로 나누세요.”라고 보내세요. Ray Fernando의 Stop Pushing AI Code Straight to Main – Ray Fernando에서는 이 규정이 왜 당신을 병합 지옥에서 구해주는지 정확하게 설명합니다.

허용된 각 수정 사항 후에 요약 한 단락과 짧은 리스크 노트를 요청하세요: 마이그레이션, 성능 변화 또는 API 표면 수정. 그 요약을 커밋 메시지에 붙여넣으세요. 당신의 git 기록은 “wip again” 대신 자동 생성된 변경 로그가 됩니다.

세션을 끝내고 모델을 문서화 도우미로 전환합니다. 어떤 문서가 있는지 알려주세요—README, API 참조, ADR 등—그리고 구체적인 수정을 요청하세요: 새로운 섹션, 업데이트된 예제, 사용 중단 노트. 이러한 변경 사항을 문서 리포지토리에 최종 차이점으로 복사하고 코드와 함께 배포하세요.

당신은 더 이상 예측 엔진에 줄을 입력하는 타이피스트가 아닙니다; 당신은 모델, 도구 및 자동화를 조율하는 지휘자입니다. 일은 “코드를 더 빨리 쓰라”는 것이 아니라 “신뢰할 수 있는 소프트웨어를 안정적으로 배포하는 시스템을 설계하라”로 바뀝니다. 키 입력은 당신이 맥락을 어떻게 형성하고, 작업을 분해하며, 적시에 적절한 AI에 올바른 작업을 어떻게 전달하느냐보다 덜 중요해집니다.

현대 AI 코딩은 미니 플랫폼을 운영하는 것처럼 보입니다: 고급 플래너 모델, 레포 인식 비서, 테스트 생성기, 리팩토링 봇이 모두 에디터와 CI에 연결되어 있습니다. 가장 뛰어난 엔지니어들은 이미 워크플로우로 생각합니다: “요구 사항” 에이전트, “디자인” 에이전트, 그리고 단일 기능 브랜치만 수정하는 “차이” 에이전트를 차례로 설정합니다. 한 모델에게 모든 작업을 맡기지 않고, 파이프라인을 조정합니다.

번창하는 개발자들은 AI를 장난감 자동 완성과 같은 것이 아니라 인프라로 여기는 이들입니다. 그들은 다음을 소유할 것입니다: - 주요 기능 이전에 문서화된 프로젝트 청사진 - 구조 설계, 구현 및 검토를 위한 전문 AI 세션 - 모든 변경 사항을 리뷰 가능하고 되돌릴 수 있도록 유지하는 스택 차이 규칙

AI IDE는 이 오케스트레이션을 기본화하기 위해 경쟁하고 있습니다. Cursor, GitHub Copilot 및 Replit과 같은 도구들은 이미 리포지토리 인덱싱, 테스트 인식 리팩토링, 다중 파일 편집 등을 단일 흐름으로 통합하고 있습니다. 향후 12~24개월 내에 귀하의 편집기에서 “기능 계획”, “컨텍스트 프로필” 및 “검토 스택”과 같은 1급 개념들이 “실행” 및 “디버그”와 나란히 위치할 것으로 기대하십시오.

갭은 모델 접근성이 아닐 것입니다; 모든 사람은 대체로 비슷한 LLM을 갖게 될 것입니다. 갭은 실제 세계의 복잡성, 버전 관리 및 팀 워크플로우를 견딜 수 있는 강력한 AI 기반 시스템을 설계할 수 있는 사람에게서 발생할 것입니다. 이 갭은 한 엔지니어가 규율 있는 AI 파이프라인을 운영하여 3-5배 더 많은 검토된, 생산 준비 완료 코드로 조용히 출하하는 팀에서 이미 드러나고 있습니다.

오래된 습관—즉시 실행하고 기도하기, 1,000줄의 차이, 전혀 계획하지 않기—는 단순히 시간을 낭비하는 것이 아닌, 당신을 적극적으로 방해합니다. 지휘자처럼 행동하기 시작하세요: 먼저 설계를 하고, 맥락을 조정하며, 하위 에이전트를 만들어내고, 차이를 쌓고, AI를 사용하여 스스로가 AI를 덜 필요로 하도록 만드세요. 소프트웨어의 미래는 “AI가 당신을 위해 코드를 작성하는 것”이 아니라, AI를 사용할 가치를 만들어내는 오케스트라를 지휘하는 당신입니다.

AI 코딩에서 '컨텍스트 엔지니어링'이란 무엇인가요?

프로젝트 정보(계획, 도면, 요약)를 구조화하고 AI 모델에 제공하는 과정으로, 코드 생성 전에 코드베이스에 대한 높은 신호를 가진 정확한 이해를 보장하는 것입니다.

왜 '프로젝트 우선, 프롬프트 우선 아님' 접근 방식이 더 나은가요?

고급 계획과 문서 작성을 우선적으로 요구하여, 더 coherently, 정확하며 유지 관리가 용이한 AI 생성 코드를 제공합니다. 이는 재작업과 디버깅을 줄이는 데 기여합니다.

이 고급 AI 워크플로우에 가장 적합한 도구는 무엇인가요?

Cursor와 같은 AI 네이티브 IDE는 이상적입니다. 이들은 프로젝트 인덱싱, 다중 에이전트 대화, 스택형 차이(diff)를 비롯한 기능을 통합하여 컨텍스트 우선 워크플로를 직접 지원합니다.

이 워크플로우는 시간이 지남에 따라 AI에 대한 의존도를 줄이는 데 어떻게 도움이 됩니까?

AI를 사용하여 자신의 스택을 문서화하고 이해함으로써, 코드베이스에 대한 강력한 정신 모델을 구축할 수 있습니다. 이는 더 복잡하고 새로운 작업에만 AI를 사용하고, 간단한 기능은 스스로 구현할 수 있게 해줍니다.