AI-powered Software Engineering

소프트웨어 엔지니어링 패러다임의 근본적 전환

• 개발자의 역할이 직접 코드를 입력하는 ’실행자(Executor)’에서, AI 에이전트의 방향을 잡고 오케스트레이션하는 ’조향자(Steerer)’로 변화함.
• 최신 프론티어 모델들은 소프트웨어 엔지니어의 전체 업무 프로세스를 수행할 수 있음.
• 코드 생성 비용의 감소: 코드를 작성, 리팩토링, 삭제하는 비용이 사실상 ’0’에 수렴함. 코딩 구현(Implementation)은 더 이상 희소한 자원이 아님.
• 코드는 보존해야 할 유산이 아니라 언제든 폐기하고 다시 만들 수 있는 결과물임.
• 과거에는 인력 부족으로 우선순위에서 밀리던 작업(P3 등)이나 6개월 이상 걸리던 마이그레이션 작업을 10~15개의 병렬 에이전트를 투입해 즉시 완수할 수 있게 됨

AI 코딩 패러다임의 문제점

• 인간의 한계: AI 도구의 실행 능력은 극대화되었으나, 이를 처리하는 인간의 뇌(신경계)는 한계가 있음.
• 도구의 과부하: 여러 에이전트(Cursor, Claude Code, Codex 등)를 동시 실행할 경우, 잦은 맥락 전환(Context Switching)과 결과물 검토 피로로 오전 11시면 이미 지침.
• 무한대로 확장되는 에이전트: 에이전트는 24시간 무한 확장이 가능하지만 개발자가 에이전트의 모든 실행 과정을 지켜봐야 한다면 생산성 향상은 착시에 불과함
• 확률론적: 전통적인 소프트웨어 개발은 결정론적인 코드를 작성하지만, AI 에이전트를 다루는 것은 자율성과 맥락에 기반한 추론이 확률적임
• 저품질 결과물(AI Slop): 모델의 능력이 부족해서가 아니라, 인간이 “좋은 코드란 무엇인가”에 대한 비기능적 요구사항을 명시하지 않았기 때문.
• 대규모 코드베이스에 대한 이해 부족: 여전히 AI는 대규모 코드베이스에 대해 작업할 때 컨텍스트의 한계로 인해 전체 시스템에 대해 알 수 없으므로 복잡한 시스템에서는 단일 코드 줄에서 보이지 않는 **창발적 오류(Emergent behavior)**가 발생할 수 있음

AI 시대에도 소프트웨어 엔지니어가 필요한 이유

코드는 엔지니어의 목적(Job)이 아니라, 작업의 결과물(Artifact)일 뿐이다. 소프트웨어 엔지니어의 핵심은 코드 완성이 아니라 수많은 의사결정과 시스템 설계이다.

• 문제 정의: AI는 명확한 지시에는 강하지만, 모호하고 상충하는 비즈니스 요구사항을 파악하고 구체적인 기술 결정으로 번역하는 것은 여전히 사람의 판단이 필요하다.
• 시스템 설계: 여러 컴포넌트가 상호작용하는 대규모 시스템의 아키텍처를 설계하고, 확장성·유지보수성·성능 간의 트레이드오프를 판단하는 능력은 AI가 대체하기 어렵다.
• 품질 검증과 책임: AI 생성 코드는 오류와 불완전한 구현을 포함할 수 있어 코드의 정확성, 보안, 엣지 케이스를 검증하고 최종 책임을 지는 주체는 결국 사람이어야 한다.
• 보안 책임: 접근 제어, 개인정보 보호, 공급망 보안과 같은 위험은 전문 엔지니어가 설계하고 관리해야 한다.
• 운영과 장애 대응: 복잡한 프로덕션 장애나 예측 불가능한 버그의 근본 원인을 추론하고 해결하는 데는 경험 기반의 직관과 논리적 추적 능력이 요구된다.
• 도메인 이해: 조직의 업무 규칙과 사용자 맥락을 소프트웨어에 정확히 반영하려면 도메인 지식이 필요하다.
• 도메인 지식 통합: 특정 산업이나 조직의 맥락, 규제, 기존 레거시 시스템에 대한 깊은 이해를 바탕으로 AI 제안을 걸러내고 조정하는 역할이 필요하다.
• AI 활용 체계 구축: AI가 안전하게 작업하도록 데이터, 권한, 도구, 평가 기준을 설계해야 한다.
• 수요 확대: AI 확산은 개발 비용을 낮추지만 동시에 더 많은 AI 제품과 자동화 시스템의 개발 수요를 만든다.
• 역할의 진화: 소프트웨어 엔지니어는 단순 코드 작성자에서 AI를 감독하고 시스템 전체를 책임지는 역할로 이동한다.
• 팀 협업과 의사소통: 다른 엔지니어, 기획자, 경영진과 협업하며 우선순위를 조율하고 기술적 결정을 설명하는 커뮤니케이션 능력은 여전히 인간 고유의 영역이다.

코드의 본질

가장 좋은 코드는 작성하지 않은 코드다(Jeff Atwood 명언)

• 작성된 모든 코드 줄은 유지보수, 디버깅, 가독성의 **부채(Burden)**를 동반함.
• AI가 코드를 엄청나게 많이 만들어낸다고 해서 좋은 것이 아니며, 프로덕션에는 최소한의 필요한 코드만 들어가는 것이 이상적임.

코딩은 트레이드오프(Trade-off)의 연속

• 모놀리스(Monolith) vs. 마이크로서비스(Microservices) vs. 이벤트 기반(Event-driven) 아키텍처 선택 등 모든 구현에는 성능, 복잡성, 유지보수성 간의 타협이 존재함.

LLM 패턴 매칭의 한계

• LLM은 텍스트 및 패턴 생성 도구임.
• 일정 규모 이상의 프로덕션 시스템은 레거시와 독자적인 특이점(Snowflake)을 지니고 있어, 기존 패턴 매칭만으로는 실제 복잡한 아키텍처 의사결정을 내릴 수 없음.

AI 코딩 패러다임의 문제점 해결하기

컨텍스트 효율성을 고려한 코드베이스 구조화

• 모델의 컨텍스트 윈도우 낭비를 구조적으로 방지하기 위한 코드 베이스 구조를 고려
• 린터나 테스트가 실패했을 때 출력되는 에러 메시지 자체에 “에이전트가 어떻게 코드를 수정해야 하는지” 구체적인 프롬프트 지침을 포함시킴

비기능적 요구사항 문서화

• 고품질 코드를 만드기 위해 필요한 수백 가지의 암묵적 결정(타임아웃, 재시도, 에러 처리, 보안 패턴, 유지보수성 등)을 문서화해야 함.
• Architecture Decision Records(ADR), QA 플랜, 페르소나별 가이드, 명확한 수락 기준(Acceptance Criteria)을 리포지토리에 커밋하여 에이전트에게 제공해야 함.

상태 데이터의 변화: “Text is the New State”

• 문제점 (Trap): 현실 세계의 복잡한 문맥과 사용자 의도를 Boolean 플래그, Enum, 단단히 고정된 JSON 스키마로 가두려고 함
• 해결책 (Fix): 문맥적 의미(Semantic Meaning)를 원본 텍스트 형태로 보존하여 하류(Downstream) 에이전트가 이를 유연하게 해석할 수 있도록 함
• 예시: 단순 is_approved: True 대신 “Approved, but focus on the US market and ignore CA”와 같이 지시문과 조건이 포함된 raw 텍스트 자체를 상태로 유지
• 개인화 예시: unit = Celsius 대신 “평소에는 섭씨를 선호하지만, 요리할 때는 화씨를 선호함”과 같은 맥락성 원본 텍스트 보존

AI와 사람의 역할 분리

• AI 에이전트: 빠른 속도, 지치지 않는 실행, 반복 패턴 처리, 코드 작성.
• 인간 개발자: 의도 설정, 직관/취향(Taste), 결과에 대한 판단, 멈출 때를 아는 결정력.

확산 모드 활용

• 하드코딩 중에는 ’집중 모드’가 작동하지만, 막힌 문제의 영감은 산책/샤워 등 책상을 떠난 ’확산 모드’에서 나옴.
• AI 에이전트가 스스로 검증하고 작업할 수 있다면, 개발자는 책상을 떠나 산책 중에도 모바일/음성으로 일의 방향을 지시할 수 있음.

테스트에서 평가로 검증 방식의 전환

• LLM 출력은 비결정론적이므로 단일 테스트 통과 여부만으로는 안정성을 보장할 수 없음
• 단언 대신 평가 시스템 도입
  • 동일 프롬프트 N회 반복 평가
  • 네거티브 케이스 검증
  • 결과 중심 평가
  • 트레이싱 필수

API 설계 방식 전환

• 에이전트는 개발자가 가진 맥락이나 사내 암묵지를 갖고 있지 않음. 오직 명세와 문서를 보고 판단함
• 에이전트 전용(Agent-Ready) API 설계
• 명시적이고 서술적인 이름 사용
• 상세하고 명확한 문서화

삭제를 위한 가벼운 구축

• 더 뛰어난 모델과 에이전트가 빠르게 등장하므로, 에이전트를 둘러싼 코드 하네스는 상시 재작성 및 삭제가 용이하도록 가볍게 구축하라

인간-에이전트 협업 및 코드 리뷰 체계

• Pull Request의 역할: PR은 인간과 에이전트가 소통하는 ‘클린룸’ 공간임.
• 페르소나 기반 리뷰 에이전트: 보안, 프론트엔드 아키텍처, 신뢰성 엔지니어 페르소나를 가진 에이전트가 PR 생성 시 자동 리뷰를 수행.
• 쓰레기 수거의 날:주 1회 팀 전체가 한 주 동안 발생한 에이전트의 실수 및 저품질 코드 패턴을 분석. 이를 문서, 린트 규칙, 테스트, 프롬프트 가이드로 변환하여 동일한 실수가 영구적으로 재발하지 않도록 시스템을 보완.

AI가 코드를 작성하기 쉬운 환경

1. 문서화된 표준 및 관행: 어떤 패키지/패턴을 사용할지 기준 명시.
2. 단순하고 재현 가능한 환경: 개발 환경 구축의 단순화.
3. 접근 가능하고 자동화된 테스트 인프라: 생성된 코드를 즉시 검증할 수 있는 로컬/CI 테스트 환경.
4. 명확한 경계 설정: 작업 모듈 및 스코프의 한계 명확화.
5. 구체적으로 정의된 작업: 모호한 요청 대신 구체적인 사양 전달.

4가지 기술 스택

① 신호 레이

• Slack, Linear 등의 소통 채널을 직접 열어보지 않고, **MCP(Model Context Protocol)**를 통해 에이전트가 신호를 수집.
• AI가 노이즈를 제거하고 “개발자의 조치가 필요한 핵심 요약(Delta)“만 브리핑하게 만들어 불필요한 알림 피로 감소.

② 음성 우선 워크플로우

• 키보드 타자(평균 90 wpm)보다 음성 입력(180+ wpm)이 2배 이상 빠름.
• 여러 커서/터미널 창에 음성으로 프롬프트를 번갈아 던짐으로써 다중 에이전트를 실시간 병렬 스케줄링함.

③ 원격 제어

• 로컬/클라우드 개발 환경의 Claude Code 세션을 외부 네트워크(모바일)와 연동.
• 개발자가 산책 중 떠오른 아이디어를 폰(음성)으로 전달하면, 로컬 데브 머신의 에이전트가 즉시 코드 반영 및 테스트 수행.

④ 자기 개선 시스템

• Claude Code 등의 로컬 대화 기록(JSONL 파일)을 주간 단위로 AI가 자동 스캔.
• 반복된 작업 패턴, 비효율적인 비동기 대화 지점을 찾아내어 스스로 새로운 ’자동화 스킬/프롬프트’를 생성하도록 구축.

병목 현상

코드 이해의 어려움

• AI 코딩이 가져온 변화: AI 에이전트가 50,000줄짜리 PR(Pull Request)을 척척 만들어내는 시대입니다. 개발속도는 비약적으로 빨라졌으나, 인간이 이를 따라잡기는 점점 더 힘들어지고 있다
• 잘못된 접근 - 검증을 위한 이해 (Understand to verify)
  • 흔히 “코드 리뷰가 새로운 병목이다”라며, 인간의 역할을 단순히 AI 결과물의 옳고 그름(Correctness)을 체크하는 ’검상자’로 제한합니다.
  • 하지만 테스트와 자가 수정 루프(Verification loop)가 발전함에 따라 단순 올바름 검증에서 인간이 차지하는 비중은 점차 줄어들고 있습니다.
• 본질적 접근 - 참여를 위한 이해 (Understand to participate)
  • 인간이 코드를 이해해야 하는 진짜 이유는 “다음 창의적인 아이디어(The next idea)“를 내고 계속 프로젝트에 능동적으로 참여하기 위함입니다.맥락과 구조를 머릿속에 쥐고 있어야만 다음 단계로 넘어가는 독창적인 비전을 제시할 수 있습니다.
• 인지적 부채 (Cognitive Debt)의 위험성
  • 코드가 어떻게 작동하는지 모른 채 AI가 짠 코드를 계속 받아들이면 ’인지적 부채’가 누적됩니다.
  • 기술 부채(Technical Debt)와 마찬가지로, 당장은 빠르게 진행되는 것 같지만 결국 개발자가 전체 맥락을 상실(Lost the plot)하여 시스템을 전혀 컨트롤할 수 없는 지경에 이르게 됩니다.

AI로 인간의 이해를 돕는 방법

기법 1. 문학적 설명문과 퀴즈 (Explanations & Quizzes)

단순히 코드 변경 내역(Diff)만 나열하는 것은 최악의 설명입니다. AI에게 개발자를 위한 맞춤형 커리큘럼 문서를 작성하도록 시킵니다.

1. 배경(Background) 설명부터 시작: 코드 수정 내역 이전에, 해당 시스템의 구조와 좌표계, 엔진 작동 방식 등 사전 지식을 먼저 설명합니다.
2. 직관 선행 (Intuition before details): 복잡한 코드나 수식 전에 “이 변경의 목적이 무엇인지” 직관적인 예시와 원리를 먼저 제공합니다.
3. 인터랙티브 시각화 (Interactive figures): 슬라이더를 조절하거나 요소를 직접 드래그해볼 수 있는 미니 인터랙션 UI(HTML/노션 블록)를 문서 내에 포함하여 직접 체험하게 합니다.
4. 문학적 코드 Diff (Literate code diffs): 가독성 높은 글(Prose)과 코드를 융합하여 흐름에 맞게 설명합니다.
5. 속도 조절 장치로서의 퀴즈 (Quizzes as speed regulators):문서 하단에 AI가 작성한 5가지 이해도 테스트 퀴즈를 삽입합니다.개발자 자신이 이 퀴즈를 통과하지 못하면 동료에게 코드 리뷰를 요청하지 않는 규칙을 둡니다.퀴즈는 무분별하게 속도만 올리는 AI 개발 과정에서 개발자가 제대로 이해했는지 확인해 주는 ‘속도 조절기’ 역할을 합니다.

기법 2. 마이크로월드 (Micro-worlds)

교육학자 **시모어 페퍼트(Seymour Papert)**의 “Mathland(아이들이 프랑스에 살며 자연스럽게 불어를 배우듯, 수학적 환경에 거주하며 수학을 직관적으로 배우는 개념)” 철학에서 착안한 기법입니다.

• 핵심 개념: AI 에이전트에게 단순히 ’제품 코드’만 작성하게 하는 것이 아니라, 인간이 시스템 동작 원리를 쉽게 체득할 수 있는 ‘시뮬레이션 UI/디버거(마이크로월드)’ 코드를 직접 짜달라고 요청합니다.
• **사례 1 (Prolog 언어 인터프리터 시각화 디버거)**인터프리터의 내부 스택과 상태를 단계별(Timeline)로 스크러빙하며 볼 수 있는 임시 UI를 Claude로 제작.버그 수정뿐만 아니라 엔진 내부의 오퍼레이션을 직관적·감각적으로 이해하게 됨.
• **사례 2 (웹사이트 마이그레이션 제어판 게임)**웹사이트 마이그레이션 스크립트를 짤 때, 한 번에 실행하는 대신 Step-by-Step 버튼을 누르면 구 사이트에서 신 사이트로 요소와 파일이 이동하는 모습을 시각적으로 보여주는 ‘제어판(게임)’ 형태의 UI 제작.

기법 3. 공유 공간 (Shared Spaces)

개인의 이해를 넘어 **팀 전체의 공동 이해(Collective Understanding)**를 구축하는 방법입니다.

• 다자간 협업 공간에 AI 통합: 노션(Notion) 문서나 공유 차트에 기획자(PM), 개발자, 그리고 AI 에이전트(Claude, Cursor 등)가 함께 참여합니다.
• 공동 논의 구조: 1:1 대화에 갇히는 것이 아니라, Slack 채널처럼 모든 팀원이 AI 에이전트와의 질의응답 및 기획·기술 플랜 수립 과정을 실시간 공유하고 댓글로 의견을 교환합니다.
• 이를 통해 팀 전체가 용어, UI 요소, 시스템 구조에 대해 동일한 대화 맥락과 깊은 공통 이해를 형성할 수 있습니다.

워크 플로우

원칙

1. 지시하지 말고, 코드로 강제하라: 프롬프트 지시는 컨텍스트가 찰수록 잊어짐. 파이프라인 관문(Gate)과 상태 머신으로 행동을 제어해야 함
2. 신뢰 대신 증거를 요구하라: 에이전트의 주관적 보고를 믿지 마라. 해시값, Playwright UI 자동 녹화 영상, 스크린샷 등 물리적 증거를 제출받아 검증하라
3. 모든 실패는 시스템 버그다: 에이전트가 만들어낸 결과물 코드를 사람이 직접 수정해주지 마라. 하네스(Harness/시스템)를 수정하여 에이전트가 다음번 실행 때 스스로 해결하게 만들어라
4. 실패의 자산화 및 회고: 실패 원인을 회고하고 마크다운 형태의 프로젝트별 메모리를 자동 업데이트하여 동일한 실수를 방지하라
5. 가이드하되 규정하지 마라: 에이전트에게 기초적인 코딩을 다시 가르치려 하지 말고, 내 제품 특유의 “지뢰/함정” 위치만 가리켜 주라
6. 컨텍스트 유효성 측정: 추가된 컨텍스트가 실제로 성능 수치(Delta score)를 개선하는지 A/B 테스트로 수치화하여 검증하라
7. 에이전트를 주요 소비자로 인식하라: 개발자 경험(DX)을 설계하듯 에이전트 경험(Agentic Experience)을 고려하여 API 및 CLI 환경을 구축하라

1. Research (조사 및 탐색) 단계

목적: 시스템의 현재 동작 방식과 관련 파일 위치를 객관적인 사실 기반으로 파악하고 압축하는 단계

• 해야 하는 것 (Do)
  • 코드베이스의 현재 상태와 데이터/코드 흐름을 사실 그대로 객관적으로 파악
  • 수정에 관련된 모든 핵심 파일 경로, 함수, 라인 번호를 찾아 명시
  • 메인 에이전트의 컨텍스트 오염을 막기 위해 **서브 에이전트(Sub-agent)**를 활용하여 수직적 탐색(Vertical Slices) 수행
  • 수집된 대량의 탐색 정보를 요약하여 단일 파일로 압축
• 해서는 안 되는 것 (Don’t)
  • 버그 탐지나 해결책 제시를 미리 시도하지 말 것 (현상 파악에만 집중)
  • 코드를 직접 수정하거나 편집하지 말 것
  • 주관적인 의견이나 추측(Hallucination)이 문서에 들어가게 두지 말 것
• 산출물 (Deliverable)
  • research.md (약 300~1,000줄): 코드베이스 현황, 관련 파일 및 라인 정보, 객관적 사실만 담은 분석 요약 문서
• 유의사항 (Caution)
  • 인간 개발자의 검토 필수: AI가 조사한 시스템 이해도가 맞는지 인간이 먼저 확인해야 함 (조사 단계의 1줄 오류는 향후 1,000줄의 쓰레기 코드를 만듦)

2. Plan (설계 및 기획) 단계

목적: 구현할 변경 사항과 검증 절차를 명시하여 개발 의도를 완벽하게 압축하는 단계

• 해야 하는 것 (Do)
  • 단계별(Phase) 구체적인 구현 순서와 절차 작성
  • 수정할 정확한 파일명, 라인 번호, 추가/변경할 실제 코드 스니펫(Snippet) 포함
  • 자동화 검증(빌드/테스트 명령) 및 수동 검증(UI 확인 등) 절차를 명시적으로 정의
  • 완료 여부를 체크할 수 있는 성공 기준(Success Criteria) 설정
• 해서는 안 되는 것 (Don’t)
  • 코드 스니펫 없이 단순히 체크박스 항목만 열거하는 모호한 계획 작성 금지
  • 너무 추상적이거나(부족한 명세), 반대로 너무 길고 복잡하게 작성하여 가독성을 떨어뜨리지 말 것 (가독성과 신뢰성의 균형 지점 확보)
  • 인간 검토 없이 곧바로 구현 단계로 넘어가기 금지
• 산출물 (Deliverable)
  • plan.md (약 300~1,000줄): 정확한 파일 위치, 코드 조각, 빌드/테스트 검증 명령이 포함된 상세 실행 계획서
• 유의사항 (Caution)
  • 계획 검토(Plan Review)가 최고의 레버리지: 인간 개발자는 코드를 읽는 것보다 300줄짜리 plan.md를 검토하는 데 집중해야 함. 계획이 완벽하면 모델이 낮은 성능이더라도 실패하지 않음

3. Implement (구현 및 실행) 단계

목적: plan.md를 바탕으로 컨텍스트 사용량을 40% 미만으로 유지하며 유효한 코드를 작성하는 단계

• 해야 하는 것 (Do)
  • 기존 대화 기록을 지우고, plan.md만 로드한 새롭고 깨끗한 컨텍스트 창에서 시작
  • 한 번에 한 단계(Phase)씩 완전히 구현하고 즉시 검증
  • 코드 수정 후 명시된 테스트 및 빌드 명령어(cargo test, npm run build 등)를 실행하여 동작 확인
  • 진행 상황에 따라 plan.md 내의 체크박스 항목을 업데이트하며 진행
  • 예상과 다른 상황이 발생하면 즉시 작업을 멈추고 인간에게 질문하거나 계획을 수정
• 해서는 안 되는 것 (Don’t)
  • 컨텍스트 창 사용량이 40% (~170k 토큰 중 상위 구간)를 넘어가도록 방치하지 말 것
  • 에이전트가 실패했을 때 동일한 대화 창에서 계속 “너 틀렸어, 다시 해”라고 훈계(Resteering)하며 컨텍스트를 더럽히지 말 것 (오류 시 차라리 fresh context로 새로 시작하거나 progress.md로 의도적 압축 수행)
  • 빌드나 테스트 실패를 무시하고 다음 단계로 진행하지 말 것
• 산출물 (Deliverable)
  • 작업 단위별 초안 코드 및 업데이트된 plan.md
  • 기초 단위 테스트 통과 로그

4. Verify & Review (코드 검증 및 리뷰) 단계

목적: 구현된 코드가 정적 분석, 실제 동작, 프로젝트 규성을 완벽히 만족함을 3단계 검증 게이트(Verification Gates)를 통해 에이전트 스스로 증명하는 단계

• 해야 하는 것 (Do)
  • Gate 1: Lint & Build (코드 및 타입 수준 검증)
    • tsc, 린터, 단위 테스트를 자동 실행하여 구문 오류, 타입 불일치, 불필요한 임포트 등을 스스로 감지하고 수정
  • Gate 2: Browser & Computer Use (동작 및 시각적 검증)
    • 에이전트가 헤드리스 브라우저/컴퓨터 유즈 도구를 구동해 실제 앱에 접속하고, UI를 클릭·엔드투엔드 테스트하며 스크린샷과 시각적 결과물 제출
  • Gate 3: Rules & Constitutional Review (규칙 및 컨벤션 검증)
    • CLAUDE.md 또는 프로젝트 룰북 기반으로 별도의 **리뷰어 서브 에이전트(Constitutional Reviewer)**를 띄워 코딩 스타일, UI 체크리스트, 아키텍처 규칙 준수 여부를 다각도로 검토
• 해서는 안 되는 것 (Don’t)
  • 빌드/타입 에러나 린트 경고가 남아있는 상태에서 PR을 생성하거나 검증을 종료하지 말 것
  • 인간 개발자에게 “직접 앱을 띄워 확인하라”고 미루지 말 것 (스크린샷이나 E2E 실행 로그 등 직접적인 시각적 증거를 에이전트가 먼저 제출해야 함)
  • 작성자 에이전트가 자기 코드를 직접 셀프 리뷰하고 ’이상 없음’으로 자가 승인하는 단독 통과 행위 금지 (반드시 독자적인 룰/리뷰어 에이전트 검증 거칠 것)
• 산출물 (Deliverable)
  • 3단계 검증 리포트가 첨부된 최종 PR (빌드/테스트 성공 로그 + 브라우저 캡처 스크린샷 + 룰 준수 체크리스트 포함)
• 유의사항 (Caution)
  • 검증 자동화가 ’데스크 이탈(Untethered Productivity)’의 핵심: 에이전트가 자체 검증 증거(스크린샷, 테스트 로그)를 완벽히 낼 수 있어야 개발자가 화면 앞을 지키지 않고도 모바일이나 음성으로 결과를 신뢰하고 승인할 수 있음

5. 전체 워크플로우 통합 유의사항 (General Rules)

• 생각을 AI에게 외주 주지 말 것: AI는 인간의 생각을 증폭할 뿐임. 인간은 [Research 검토], [Plan 검토], 그리고 최종 **[Gate 검증 결과 확인]**이라는 가장 높은 레버리지 지점에만 최소한으로 개입해야 함
• 작업 난이도에 따른 워크플로우 유연 적용:
  • 단순 오탈자/색상 변경: AI와 직접 대화 후 Gate 1(Lint/Build) 검증만 거쳐 해결
  • 중소형 기능: 간단한 plan.md 작성 후 구현 및 Gate 1, 2 적용
  • 대형 리팩토링/복잡한 Brownfield 기능: 전체 RPIV (Research → Plan → Implement → Verify) 프로세스 엄수
• 단일 도구 숙련도(Reps) 확보: 여러 에이전트 도구를 번갈아 쓰지 말고, 하나의 도구로 컨텍스트 제어 및 검증 게이트 연결 직관이 생길 때까지 충분히 연습할 것

서브 에이전트

서브 에이전트는 인간처럼 특정 직무에 대한 역할극을 위한 기능이 아니다.

서브 에이전트의 진짜 목적은 ’컨텍스트 통제 및 격리’이다.

• 메인 에이전트가 수십 개의 파일을 읽고 검색하면서 컨텍스트를 더럽히는 대신, 별도의 독립된 컨텍스트 창을 갖는 Sub-Agent를 생성하여 탐색 작업을 시킵니다.
• Sub-Agent는 대량의 코드를 읽은 뒤, 메인 에이전트에게 **“네가 수정해야 할 파일은 src/main/… 이 파일 하나뿐이야”**라는 극도로 압축된 결론만 반환합니다.
• 메인 에이전트는 깨끗한 컨텍스트를 유지한 채 즉시 작업에 들어갈 수 있습니다.

에이전트를 대하는 자세

생각(Thinking)을 AI에게 외주 해서는 안된다

AI는 인간의 ’생각’을 대체하는 것이 아니라, 인간이 한 생각을 증폭(Amplify)하는 도구이다.