Web Dev Learn

Theme

11-7. 사람의 역할과 개발의 미래 ​

한 줄 요약: 에이전트가 코드 작성·검증의 많은 부분을 수행하는 환경에서 사람이 유지해야 할 책임을 구체적으로 나열하고, 개발 조직의 변화를 근거와 불확실성을 함께 담아 전망할 수 있다.

학습 목표 ​

  • 에이전트에게 위임 가능한 작업과 사람이 유지해야 하는 책임을 구분한 역할 매트릭스를 작성할 수 있다.
  • "코드를 쓰는 사람"에서 "작업을 명세하고 검증하고 조율하는 사람"으로의 역할 이동을 구체적 활동으로 설명할 수 있다.
  • 팀 구조에 생기는 새 책임(워크플로 소유, 하네스 유지보수, 검증 소유)을 기존 역할의 재배치로 설계할 수 있다.
  • 미래 개발 방식의 시나리오들을 가능성과 한계, 제한 요소와 함께 평가할 수 있다.
  • 에이전트 시대에 기본기 학습이 왜 덜이 아니라 더 중요해지는지 논증할 수 있다.

배경: 왜 이것이 존재하는가 ​

기술 커리큘럼의 마지막 문서가 미래 전망인 것은 관례적 마무리가 아니다. 실용적 이유가 있다. 이 Phase에서 배운 워크플로·하네스·검증 설계는 모두 사람의 시간을 어디에 쓸 것인가의 재배치이고, 재배치의 방향을 정하려면 "무엇이 사람의 일로 남는가"에 대한 각자의 답이 필요하다. 그 답 없이는 도구가 바뀔 때마다 표류한다.

전망 문서에는 규율이 필요하다. 이 분야의 담론은 "개발자는 끝났다"와 "그래 봤자 자동완성이다" 사이에서 진동해 왔고, 양쪽 모두 판단을 돕지 않는다. 이 문서의 규율은 세 가지다. 관측된 것에서 출발한다 — 실제 PR 데이터, 실증 연구, 우리가 이 Phase에서 직접 돌려 본 루프. 메커니즘으로 논증한다 — "AI가 발전하니까"가 아니라 어떤 구조적 이유로 어떤 일이 이동하는지. 불확실성을 명시한다 — 단정하지 않고, 각 전망이 어떤 조건에서 틀리는지 함께 쓴다.

한 가지 관점 전환을 미리 제안한다. "AI가 개발자를 대체하는가"는 좋은 질문이 아니다. 컴파일러는 어셈블리 작성자를, 클라우드는 서버 관리 업무의 상당 부분을 '대체'했지만, 그때마다 개발자라는 직업은 추상화 수준을 올려 재정의됐다. 더 나은 질문은 **"이번 추상화 이동에서 무엇이 위로 올라가고, 무엇이 사람에게 남는가"**이며, 이 Phase 전체가 그 답의 재료를 만들어 왔다.

핵심 개념 ​

남는 책임의 목록: 구체적으로 ​

"창의성과 판단력이 중요해진다"는 문장은 아무 행동도 안내하지 못한다. 책임 단위로 구체화하면:

책임내용왜 사람에게 남는가
문제 정의무엇을 만들지, 왜 만들지, 무엇을 안 만들지목표 설정은 위임의 출발점이라 위임 대상이 될 수 없다 (구조적)
요구사항의 모순 조정이해관계자 간 충돌, 암묵적 제약의 발굴정보가 코드·문서 밖(사람들 머릿속)에 있다
설계 의사결정아키텍처, 기술 선택, 트레이드오프의 결단검증이 생성만큼 어려운 영역(11-5의 비대칭), 결과 책임 동반
검증 기준 설정무엇이 "맞음"인지의 정의, 증거 요구 수준기준 자체를 최적화 대상에게 맡기면 굿하트의 법칙이 작동
보안·개인정보·접근성 책임법적·윤리적 의무의 이행 보증책임은 법인격에 귀속된다 (자동성-책임 구분, 11-1)
병합·배포 승인변경을 사용자에게 노출하는 결정위와 동일
장애 대응판단이 필요한 비정형 상황, 사후 책임신뢰 경계 밖 자동화에 맡길 수 없는 최후 방어선
팀 커뮤니케이션신뢰 구축, 갈등 조정, 컨텍스트 전파조직은 사람 간 신뢰로 동작한다

"왜 남는가" 열의 근거 유형을 구분해 읽을 필요가 있다. 구조적 이유(문제 정의, 검증 기준)는 모델이 아무리 발전해도 변하지 않는다 — 위임이라는 행위 자체의 논리적 전제이기 때문이다. 책임 귀속 이유(승인, 보안 의무)는 기술이 아니라 법·조직이 정하는 것으로, 역시 모델 성능과 무관하다. 현재 능력의 한계(모순 조정의 일부, 비정형 장애 대응의 일부)만이 모델 발전으로 이동할 수 있는 부분이다. 즉 목록의 대부분은 시간이 지나도 침식되지 않는 축이다.

위임되기 쉬워지는 일 ​

반대편 목록도 명시하자. 이 Phase의 기준(성공 조건의 기계 판정 가능성, 11-1)으로 예측하면, 다음은 이미 이동 중이거나 이동이 빠를 것이다: 반복 구현, 테스트 보강, 코드 탐색과 요약, 문서 초안, 작은 리팩터링, 프레임워크·API 마이그레이션 보조, PR 설명, 회귀 원인 탐색. 실증 연구도 이 예측과 부합한다 — Agentic Refactoring 연구는 현재 에이전트의 리팩터링이 기계적·지역적 변경에서는 유효하지만 넓은 설계 변경에서 품질이 떨어짐을 보이고, PR 데이터 연구는 에이전트 기여가 정형화된 작업 유형에 집중됨을 관찰한다.

단서가 하나 붙는다. "위임되기 쉬워진다"는 "사람이 안 봐도 된다"가 아니다. 이동하는 것은 작성 노동이고, 남는 것은 그 결과에 대한 검토와 책임이다. 이 구분이 아래의 역할 변화를 만든다.

역할의 이동: 작성자에서 편집자·검증자·운영자로 ​

개발자의 하루를 활동 비중으로 그려 보면 이동이 선명하다.

text
      이전                              이후
──────────────────                ──────────────────────────
코드 작성        ████████          작업 명세 작성      ███
디버깅           ████              계획·diff 리뷰      ████
코드 리뷰        ██                검증 설계·증거 검토  ███
회의·문서        ██                에이전트 실행 조율   ██
                                  하네스·지시문 정비   █
                                  설계·문제 정의       ███
                                  코드 직접 작성       ██  (남는다)

이 이동을 겪는 개발자에게 필요한 능력을 이 Phase의 언어로 재기술하면: 좋은 작업 명세를 쓰는 능력(11-2) — 요구사항 분석의 압축판, 컨텍스트를 설계하는 능력(11-3) — 문서화의 재발견, 검증 루프를 설계하는 능력(11-5) — 테스트 전략의 확장, 위험을 경계 짓는 능력(11-6) — 운영 감각의 적용. 어느 것도 무에서 새로 배우는 것이 아니라, 시니어 개발자가 이미 가진 능력의 명시화·전면화다. 이것이 "프롬프트 작성자"라는 표현이 역할을 오도하는 이유다 — 실제 역할은 에이전트 작업의 **편집자(무엇을 실을지 결정), 검증자(증거를 요구하고 판정), 운영자(권한과 실패에 대응), 설계자(작업과 시스템의 구조를 결정)**다.

주의할 것: 코드 직접 작성이 0이 되지 않는다. 검증 수단이 없는 영역의 정지 작업, 에이전트가 반복 실패하는 까다로운 문제, 그리고 뒤에서 다룰 "검증 능력을 유지하기 위한 훈련"으로서의 작성이 남는다.

팀 구조: 새 직함보다 책임의 재배치 ​

에이전트가 팀에 들어오면 이전에 없던 책임이 생긴다. 이를 새 직함으로 만들기 전에, 기존 역할의 확장으로 먼저 설계하는 것이 조직 변화의 비용을 줄인다.

새 책임내용자연스러운 확장 원점
AI workflow owner작업 명세 템플릿, 위임 기준, 워크플로 개선테크 리드, 프로세스 관심 시니어
harness maintainer지시문·도구·MCP·권한 구성의 관리와 개선빌드·인프라 담당 (DevEx)
verification owner증거 요건, 평가 세트, 검증 게이트의 설계QA·테스트 아키텍트
security/governance reviewer권한 정책, 감사, injection 대응, 규정보안 챔피언

플랫폼 팀이 있는 조직이라면 harness maintainer 책임은 자연스럽게 그쪽으로 흡수된다 — 하네스가 팀의 공유 개발 환경이 되기 때문이다. 작은 팀이라면 네 책임을 두어 명이 겸하되, 누가 갖는지가 명시되어 있는 것이 중요하다. 11-6의 감사 질문("에이전트발 사고의 대응자가 정해져 있는가")이 이 명시성의 검사기다.

주니어 성장 경로는 이 재편의 가장 어려운 문제다. 전통적으로 주니어는 위임되기-쉬운-작업 목록(반복 구현, 테스트 작성)을 하며 성장했는데, 그 사다리의 아래 칸들이 에이전트로 이동한다. 관측되는 대응은 두 방향이다: 주니어를 "에이전트와 함께 일하는 법"부터 훈련시키는 방향(명세·검증을 일찍 가르침), 그리고 훈련 목적의 직접 구현을 의도적으로 보존하는 방향(효율이 아니라 학습이 목적인 작업의 구분). 어느 쪽이 유효한지는 아직 데이터가 부족하며, 팀이 실험할 문제다.

미래 시나리오: 가능성과 한계를 짝으로 ​

시간 지평 1~5년의 시나리오 네 개를, 각각의 실현 조건과 제한 요소와 함께 평가한다.

S1. 현재 도구의 점진 확장 — 개인 개발자의 에이전트 사용이 깊어지지만 팀 프로세스는 크게 안 변하는 미래. 실현 조건: 없음(이미 진행 중). 이것이 기본 시나리오이며, 나머지는 이 위에 얹힌다.

S2. PR 단위 에이전트 협업의 일반화 — 이슈를 에이전트에 배정하고 PR로 받는 흐름이 표준 워크플로가 되는 미래. 근거: PR 데이터 연구가 보여 주는 에이전트 PR의 빠른 증가. 제한 요소: 리뷰 병목 — 생산이 검증보다 빨라지면 리뷰가 형식화되거나 적체된다(11-5의 재배분 문제). 이 시나리오의 실현 속도는 모델 능력이 아니라 팀의 검증 역량이 결정할 가능성이 높다.

S3. 반자동 개발 파이프라인 — 이슈→계획→구현→검증→리뷰가 게이트 있는 파이프라인으로 연결되고, 사람은 게이트의 승인자가 되는 미래. 근거: CI/CD가 걸어온 같은 경로, 하네스의 headless 실행 성숙. 제한 요소: 비결정성 관리와 실패 귀인의 비용, 그리고 신뢰 — 파이프라인의 어느 단계도 "가끔 조용히 틀리는" 컴포넌트를 견디도록 설계된 적이 없다. 정형화된 작업 유형(dependency, 보안 패치, 마이그레이션)부터 부분적으로 실현될 것이다.

S4. Agent-ready가 경쟁력이 되는 흐름 — 문서화된 UI 계약, 스키마, 테스트를 갖춘 코드베이스와 API가 "에이전트가 일하기 좋은 자산"으로서 가치를 갖는 미래. 근거: 이 Phase 전체의 논리 — 에이전트 산출 품질이 환경 품질의 함수라면, 환경 품질이 곧 생산성 자산이 된다. Hermes류 연구가 보여 주는 "기계 소비 가능한 문서"의 계량화. 제한 요소: 문서·테스트 투자는 늘 미뤄져 왔다는 조직 현실. 다만 이번에는 투자의 회수가 즉각적(에이전트 성공률)이라는 점이 과거와 다르다.

프론트엔드 특화 전망은 S4의 구체화다. 디자인 시스템, Storybook, Playwright 스위트, 접근성 규칙, performance budget, API schema — 이 Phase에서 검증 도구로 쓴 것들이 에이전트의 작업 기반 인프라로 지위가 오른다. "문서화된 UI 계약"을 가진 팀과 아닌 팀의 에이전트 활용 격차는 모델 선택의 격차보다 클 것이다. 이는 예언이 아니라 11-1의 하네스-환경 논리의 직선 연장이다.

모든 시나리오 공통의 제한 요소: 비결정성과 hallucination(신뢰 상한을 만든다), 장기 유지보수 문제(에이전트 생산 코드의 5년 뒤 비용은 아직 데이터가 없다), 책임 소재의 법적 불확실성, 보안 사고(대형 injection 사고 한 번이 도입 속도를 크게 되돌릴 수 있다), 저품질 코드의 대량 생산 가능성, 도구 종속성, 그리고 주니어 성장 경로 약화가 만들 10년 뒤의 시니어 공급 문제. 강한 전망 담론(참고 자료의 The End of Software Engineering류)을 읽을 때는 이 제한 요소들에 대한 답이 있는지를 기준으로 삼으라.

기본기의 역설: 왜 덜이 아니라 더 중요해지는가 ​

"에이전트가 코드를 짜 주니 기본기 학습은 덜 중요하다"는 추론은 이 Phase의 내용 전체와 충돌한다. 세 단계로 논증한다.

  1. 검증은 아는 만큼만 가능하다. 에이전트 diff에서 stale closure, 캐시 무효화 누락, 접근성 후퇴, 리렌더 폭증을 잡아내는 것은 Phase 3·5·8의 동작 모델을 가진 사람뿐이다. 검증자가 모르는 결함은 증거 패키지를 뚫고 병합된다. 역할이 작성자에서 검증자로 이동한다는 것은 기본기의 용도가 바뀐다는 뜻이지 필요가 주는 것이 아니다 — 오히려 작성자는 자기 코드만 알면 됐지만 검증자는 남(에이전트)의 온갖 접근을 판정해야 한다.
  2. 명세와 귀인은 동작 모델을 요구한다. 좋은 작업 명세의 성공 조건과 멈출 조건(11-2)은 무엇이 잘못될 수 있는지 아는 사람만 쓸 수 있고, 실패 귀인(11-5)은 계층별 동작 모델 없이는 소거법을 시작할 수 없다.
  3. 표면 지식의 가치만 급락한다. API 시그니처, 문법 세부, 보일러플레이트 패턴 — 검색과 자동완성의 영역이던 지식은 에이전트가 완전히 흡수한다. 급락하는 것과 남는 것의 경계선이 정확히 이 커리큘럼의 선 — 사용법이 아니라 동작 모델·설계 배경·경계 조건 — 이다.

개인 성장 전략도 여기서 나온다. 학습 시간을 줄이는 것이 아니라 표면에서 모델로 재배분하고, 에이전트를 학습 도구로 역이용한다(모르는 코드베이스의 탐색·설명은 에이전트가 잘하는 일이다). 단, 검증 능력은 생산 능력에서 나오므로 — 좋은 코드를 써 본 적 없는 사람은 좋은 코드를 판정하지 못한다 — 직접 작성 훈련을 완전히 버리는 것은 검증자로서의 자기 능력을 침식하는 선택이다.

실무 관점 ​

역할 매트릭스 작성법 (실습 과제 E와 연결) ​

자기 업무에 적용하는 형식은 단순하다. 현재 업무를 나열하고 세 열로 분류한다:

분류기준예
위임 가능 (사후 검토)성공 조건 기계 판정, 낮은 피해 반경테스트 보강, 코드 탐색, 문서 초안
부분 자동화 (사람 승인)생산은 위임, 판정·승인은 사람기능 구현, 리팩터링, 버그 수정
사람의 판단이 핵심구조적·책임적 이유로 남는 것설계 결정, 요구사항 조정, 배포 승인, 장애 지휘

이 분류는 고정이 아니다. 검증 인프라에 투자하면 2열의 항목이 1열로 이동한다(예: visual regression을 갖추면 UI 변경의 검토 비용이 급락한다). 매트릭스의 열 이동을 만드는 것이 곧 이 Phase에서 배운 하네스·검증 투자라는 것이 핵심 통찰이다. 3열은 투자로도 이동하지 않는다.

전망을 소비하는 자세 ​

이 문서의 시나리오들도 2026년의 관측에 기반한 잠정 판단이다. 도구와 데이터는 빠르게 바뀌므로, 전망 자체보다 전망을 평가하는 기준을 챙기는 것이 오래간다: ① 주장이 관측 데이터에 기반하는가, 시연에 기반하는가. ② 메커니즘이 있는가("AI가 발전해서"는 메커니즘이 아니다). ③ 제한 요소(비결정성, 검증 병목, 책임, 보안)에 대한 답이 있는가. ④ 이해관계는 무엇인가(도구 판매자의 전망과 연구자의 전망은 다르게 읽는다). 연 1회, 자신의 역할 매트릭스와 학습 로드맵을 이 기준으로 재검토하는 것을 권한다.

조직에서 이 변화를 이끄는 사람의 체크리스트 ​

  • 도입 논의를 "생산성 몇 배"가 아니라 작업 등급표와 검증 요건(11-6)에서 시작한다.
  • 리뷰 병목의 재배분 계획 없는 생산량 확대에 반대 근거를 제시한다(11-5).
  • 네 가지 새 책임(workflow, harness, verification, governance)의 담당을 명시한다.
  • 주니어의 학습 목적 작업을 효율 논리로부터 보호한다.
  • 팀의 agent-ready 투자(문서, 테스트, Storybook, 스키마)를 기술 부채 상환이 아니라 생산성 자산 구축으로 프레이밍한다.

더 깊이 ​

자동화 역사와의 유비, 그리고 유비의 한계 ​

컴파일러, 가비지 컬렉터, 클라우드, CI/CD — 개발 자동화의 역사는 매번 "아래 계층의 노동이 사라지고 위 계층의 판단이 남는" 패턴을 반복했고, 이 문서의 낙관적 골격은 그 귀납이다. 그러나 유비의 한계도 명시해야 정직하다. 과거의 자동화는 결정적이었다 — 컴파일러는 같은 입력에 같은 출력을 내고, 그 정확성은 수십 년에 걸쳐 신뢰가 축적됐다. 에이전트는 비결정적이고 확률적으로 틀리며, 이런 컴포넌트가 개발 파이프라인의 중심에 놓인 전례가 없다. 따라서 "역사가 반복된다"는 안심도, "이번은 다르다"는 공포도 모두 과잉 확신이다. 남는 것은 이 Phase가 반복한 방법론이다: 신뢰를 가정하지 말고 검증으로 사고, 실패를 예산에 넣고 설계하라.

The End of Software Engineering 류의 강한 전망 읽기 ​

참고 자료의 해당 논문은 "소프트웨어 엔지니어링의 종말"이라는 제목으로 agentic engineering으로의 전환을 주장하는 강한 전망의 대표 사례다. 비판적으로 읽는 연습을 해 보면: 유효한 통찰 — 엔지니어링 활동의 중심이 코드 작성에서 명세·검증·조율로 이동한다는 방향성은 이 문서의 관측과 일치한다. 과잉 확장 — "종말"이라는 프레임은 검증 비대칭, 책임 귀속, 비결정성이라는 제한 요소를 시간이 해결한다고 암묵 전제하는데, 그 전제의 근거는 제시되지 않는다. 이런 문헌의 실용적 소비법은 방향(무엇이 이동 중인가)은 취하고 속도·종착점(언제까지, 어디까지)의 단정은 할인하는 것이다.

프론트엔드라는 직군의 특수성 ​

마지막으로, 프론트엔드 개발자에게 이 전환이 갖는 고유한 각도를 짚는다. 프론트엔드의 산출물은 사람이 경험하는 인터페이스이고, 그 최종 판정(사용성, 감각, 신뢰감)은 기계 검증의 잔여 영역으로 가장 오래 남을 부류다. 동시에 프론트엔드는 검증 도구 생태계(테스트, 스크린샷, 접근성 트리, 성능 계측)가 가장 풍부한 직군이라 에이전트 활용의 이득도 크다. 즉 프론트엔드는 위임의 이득과 사람 판단의 잔여가 모두 큰 직군이며, 그래서 이 Phase에서 배운 "무엇을 위임하고 무엇을 붙잡을지"의 경계 감각이 다른 직군보다 더 자주, 더 섬세하게 쓰일 것이다. 사용자 가치 판단과 UI 품질 감각 — 코드 뒤에 숨어 있던 프론트엔드 개발자의 능력이 전면에 나오는 방향이다.

정리 ​

  • 사람에게 남는 책임은 추상적 "창의성"이 아니라 구체적 목록이다: 문제 정의, 요구사항 조정, 설계 결정, 검증 기준 설정, 보안·접근성 책임, 승인, 장애 대응, 커뮤니케이션 — 이 중 다수는 구조적·책임 귀속적 이유로 모델 발전과 무관하게 남는다.
  • 역할은 작성자에서 편집자·검증자·운영자·설계자로 이동하며, 필요한 능력(명세, 컨텍스트, 검증, 위험 경계)은 시니어가 이미 가진 능력의 명시화다.
  • 팀의 새 책임(workflow/harness/verification/governance)은 새 직함보다 기존 역할의 재배치로 먼저 설계하고, 담당의 명시성을 확보한다.
  • 미래 시나리오(점진 확장, PR 협업 일반화, 반자동 파이프라인, agent-ready 경쟁력)는 각각 제한 요소 — 검증 병목, 비결정성, 책임, 보안 사고, 주니어 경로 — 와 짝으로 평가하며, 실현 속도는 모델 능력보다 팀의 검증 역량이 결정할 가능성이 높다.
  • 기본기는 덜이 아니라 더 중요해진다: 검증은 아는 만큼만 가능하고, 급락하는 것은 표면 지식뿐이며, 동작 모델·설계 배경·경계 조건이라는 이 커리큘럼의 축이 곧 에이전트 시대의 잔존 가치다.

확인 문제 ​

  1. 경영진이 "에이전트 도입으로 개발 인력을 절반으로 줄일 수 있는가"라고 묻는다. 이 문서의 프레임(위임 가능한 것의 목록, 남는 책임, 제한 요소)으로 근거 있는 답변을 구성하라.
정답과 해설

구성 요지: ① 이동하는 것은 작성 노동이다 — 반복 구현, 테스트, 탐색, 문서 초안에서 실제 시간 절감이 관측되고 있다. ② 그러나 절감분의 상당량은 소멸이 아니라 재배분된다 — 검증·리뷰·명세·하네스 관리라는 새 노동이 생기며, 이를 무시하고 생산량만 늘리면 리뷰 병목과 결함 병합으로 되돌아온다(검증 비용의 재배분). ③ 사람 수의 함수가 아닌 책임이 남는다 — 문제 정의, 설계 결정, 승인, 장애 대응, 보안 책임은 인원 절감의 대상이 아니라 남는 인원의 업무 구성이 된다. ④ 제한 요소를 명시한다 — 비결정성, 장기 유지보수 비용의 데이터 부재, 대형 보안 사고 리스크, 주니어 공급 문제. 결론 형태: "N%의 작성 노동 이동은 현실적이나 인력 절반은 검증·책임 노동을 0으로 가정한 계산이다. 정확한 답은 우리 팀의 평가 세트와 실행 리포트 데이터로 계측하자"고 제안하는 것 — 감이 아니라 계측으로 답하는 것이 이 Phase의 방법론이다.

  1. 5년차 프론트엔드 개발자가 "이제 React 내부 동작 같은 깊은 공부는 시간 낭비 아니냐"고 묻는다. 기본기의 역설 논증을 이 개발자의 실제 업무 장면으로 구체화해 답하라.
정답과 해설

업무 장면으로 번역: ① 에이전트가 제출한 diff에 useEffect 의존성 배열 조작으로 리렌더를 '해결'한 코드가 있다 — stale closure와 렌더링 모델(Phase 3·5)을 모르면 이것이 시한폭탄임을 판정할 수 없고, 증거 패키지의 "테스트 통과"는 이 결함을 잡지 못한다. 검증자의 능력 상한이 곧 병합 코드의 품질 상한이다. ② 성능 개선 작업의 명세를 쓸 때, 병목이 리렌더인지 번들인지 네트워크인지의 가설(Phase 8)이 없으면 성공 조건과 측정 방법을 쓸 수 없다 — 명세 능력은 동작 모델의 함수다. ③ 에이전트가 반복 실패할 때 컨텍스트 부족인지 모델 한계인지 귀인하려면, 자신이 그 문제를 이해하고 있어야 소거법이 가능하다. 마무리: 가치가 떨어지는 것은 API 시그니처·문법·보일러플레이트 같은 표면 지식이고, 동작 모델·경계 조건은 검증자 역할에서 오히려 더 자주 호출된다. 다만 학습 방법은 바꿀 수 있다 — 에이전트를 탐색·설명 도구로 역이용하면 깊은 공부의 비용 자체가 내려간다.

  1. 두 팀이 있다. A팀: 디자인 시스템, Storybook, Playwright 스위트, OpenAPI 스키마, ADR이 정비됨. B팀: 문서 없음, 테스트 드묾, 컴포넌트 관례 부재. 같은 에이전트 도구를 도입할 때 두 팀의 1년 뒤 격차를 이 Phase의 개념들로 예측하고, B팀이 격차를 줄이기 위한 투자 순서를 제안하라.
정답과 해설

예측: 격차는 도구가 아니라 환경에서 벌어진다(모델-하네스-환경). A팀은 — 에이전트가 Storybook·Playwright로 자체 검증 루프를 돌고(피드백 신호), 스키마·ADR·디자인 시스템이 컨텍스트로 공급되고(agent-ready 문서), 검증 기계화 덕에 위임 가능 작업의 범위가 넓다(역할 매트릭스의 열 이동). B팀은 — 에이전트가 "컴파일된다" 이상의 피드백을 못 받아 검증되지 않은 그럴듯한 코드가 쌓이고, 관례 부재로 세션마다 다른 스타일이 생산되며, 모든 결과를 사람이 정독해야 해 리뷰 병목이 즉시 온다. 1년 뒤 A팀은 반복 작업의 무인화 단계로, B팀은 "에이전트는 우리한테 안 맞더라"로 갈 가능성이 높다. B팀의 투자 순서(11-4의 단계 + 실패 귀인 역산): ① 저장소 지시문 + 실행·검증 명령 문서화(반나절, 즉효). ② 핵심 플로우의 스모크 테스트와 타입 강화 — 에이전트 루프의 최소 피드백 신호. ③ 작업 명세 템플릿과 참조 구현 지정 — 관례를 문서로. ④ Playwright·Storybook 등 UI 검증 인프라 — 위임 범위 확장. 각 단계는 에이전트 실패 기록으로 우선순위를 보정한다.

참고 자료 ​