[한영자막] Cursor 핵심 개발자 Lauren Tan: AI 에이전트를 실전에서 제대로 신뢰하는 법 (xAI GrokBot 워크숍)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Cursor 개발자 Lauren Tan이 말하는 AI 에이전트 신뢰의 기반은 실제 앱 검증, 반복 평가, 강제 가능한 코드 제약을 갖추고 자율성을 단계적으로 확대하는 것이다.

📌 핵심 요점

1. 신뢰는 에이전트가 실제 앱을 실행하고 결과를 확인할 때 쌓인다. CPU 트레이스·힙 스냅샷·시뮬레이터로 사용자 환경의 동작을 검증해야 사람이 모든 결과를 전달하는 병목을 줄일 수 있다.
2. 앱 조작 능력과 제품 맥락을 함께 제공해야 한다. Control Glass는 앱 제어를 돕고, Feature Map은 기능별 UI 접근 경로를 알려준다. Pstack은 관찰한 실패를 개별 스킬로 바꾸며 발전했다.
3. 스킬도 검증 대상이다. 도구 호출과 실제 코드 조사를 관찰하고, 스킬을 수정할 때마다 Eval을 실행하며, 다른 모델의 교차 평가로 평가 편향을 점검한다.
4. 지속적인 자동화에는 강제 가능한 구조가 필요하다. GrokBot의 Dune은 디렉터리·import 경계와 CI 검사로 잘못된 구현을 막는다. 반복되는 리뷰 지적은 린트나 CI 실패 조건으로 전환한다.
5. 병렬 실행과 자동 병합은 선행 투자로 확보한 신뢰의 결과다. Tan은 GrokBot 구조 개선에 600개가 넘는 PR을 투입했다고 설명한다. 높은 PR 처리량만으로 품질을 판단할 수 없으며, 초기 토큰 비용과 장기 생산성을 함께 따져야 한다.

🧩 배경과 문제 정의

• Lauren Tan은 Netflix의 엔지니어링·관리 업무와 Meta의 React 컴파일러 개발을 거쳐 Cursor에서 일하고 있다. 엔지니어와 관리자를 오간 경험을 바탕으로 팀 관리와 AI 에이전트 운영의 공통점을 짚는다.
• 에이전트가 코드를 충분히 확인하지 않고 원인을 단정하거나 잘못된 수정을 반복하면 신뢰가 무너진다. 사람이 모든 출력을 감시하고 직접 검증해야 하는 상태에서는 여러 작업을 병렬로 맡기기 어렵다.
• 핵심 과제는 에이전트가 실제 애플리케이션을 실행하고 결과를 검증할 환경을 마련하는 것이다. 검증 스킬과 제품 맥락, 반복 평가를 통해 신뢰를 쌓되, 올바르게 동작하는 코드와 좋은 코드는 구분해야 한다.

🕒 시간순 섹션별 상세정리

1. 신뢰 부족은 에이전트 운영을 마이크로매니지먼트로 만든다

• 에이전트가 추측과 환각을 섞어 문제의 원인을 자신 있게 단정하고도 틀리면, 사용자는 결과를 믿기 어려워진다. 팀원을 신뢰하지 못하는 관리자처럼 모든 작업을 곁에서 확인하게 된다 [03:06]
• 모든 출력을 지켜보고 계속 프롬프트를 입력하는 방식으로는 병렬 작업을 확대하기 어렵다. 에이전트 하나의 결과도 신뢰하지 못한다면 100개를 동시에 운영할 기반도 없다 [04:45]

2. 자동 병합과 높은 처리량은 신뢰를 쌓은 뒤 도달한 결과다

• Tan은 지난 5개월 동안 신뢰를 쌓아 에이전트가 PR을 자동 병합하는 단계에 도달했다. 당일 아침에는 약 20개의 PR이 이미 병합되어 있었고, main에서 사후 검토했을 때 결과가 좋았다고 보여준다 [05:17]
• 입사 초기에는 낯선 코드베이스 때문에 생산성이 낮았지만, 에이전트에 대한 확신이 커지면서 처리량도 늘었다. 지난달에는 PR 1,000개를 반영했고 이번 달에는 12일 시점에 거의 800개를 반영했지만, 이 숫자만으로 코드 품질을 확신할 수 있느냐는 의문은 타당하다고 인정한다 [06:34]

3. 검증의 핵심은 실제 사용자 환경에서 코드를 실행하는 능력이다

• 에이전트에 필요한 핵심 역량은 검증이다. 코드를 실행하고 CPU 트레이스나 힙 스냅샷을 수집하거나 iOS 시뮬레이터를 여는 등, 사용자가 애플리케이션을 사용하는 방식에 맞춰 실제 동작을 확인해야 한다 [07:48]
• 실행과 검증은 코드 작성 이후의 피드백 고리를 완성한다. 좋은 코드를 보장하지는 않지만, 적어도 올바르게 동작하는 코드를 작성하도록 돕는다는 점에서 신뢰의 중요한 기반이 된다 [08:15]

4. 사람이 결과를 전달하는 성능 분석 과정은 병목이 된다

• Cursor 입사 첫 주에 React 기반 Agent Window의 개발을 돕게 됐고, 출시까지 약 일주일밖에 남지 않은 상황에서 성능 문제를 분석해야 했다. 코드베이스가 낯선 상태로 Chrome DevTools의 트레이스와 플레임 그래프를 직접 해석했다 [09:05]
• 에이전트에 스크린샷과 트레이스를 전달해도 원인을 잘못 단정하는 일이 있었다. 사람이 개발 빌드를 열고 오류를 확인한 뒤 스크린샷이나 콘솔 오류를 다시 전달하는 구조에서는 사람이 검증 병목이 되어 병렬화하기 어렵다 [10:14]

5. Control Glass 스킬로 애플리케이션 조작과 관측을 맡긴다

• 이 병목을 줄이기 위해 초기에 만든 스킬이 Control Glass다. Glass는 내부에서 Agent Window를 부르는 코드명이며, 스킬은 에이전트가 애플리케이션을 직접 다루도록 돕는다 [11:13]
• Electron·웹 앱에서는 Chrome DevTools Protocol을, iOS에서는 Apple의 관련 유틸리티를 활용해 프로그램으로 앱을 조작하고 시뮬레이터 실행이나 트레이스 수집을 수행하도록 가르칠 수 있다 [11:38]

6. Feature Map은 제품 기능과 실제 UI 접근 경로를 연결한다

• 앱 실행과 트레이스 수집이 가능해져도, 에이전트가 제품 구조를 모르면 검증은 막힌다. 사이드바가 느리거나 PR 탭이 작동하지 않는다는 보고를 받아도 해당 기능을 찾고 UI에서 접근하는 데 시간을 소모했다 [12:19]
• Feature Map은 각 기능에 도달하는 방법을 알려준다. Pstack의 검증 스킬 생성 기능은 코드를 탐색해 초기 지도를 만들며, 이는 모호한 보고나 스크린샷만 있는 피드백을 해석하는 데도 맥락을 제공한다 [13:24]

7. Pstack은 반복해서 발견한 실패를 스킬로 바꾸며 성장했다

• Pstack은 Tan 자신의 엔지니어링 관행에 맞춘 플러그인이지만, 처음부터 완성된 플러그인을 목표로 만들지는 않았다. Control Glass와 how 같은 개별 스킬을 에이전트의 행동을 관찰하면서 점진적으로 추가했다 [16:21]
• 버그 원인을 자신 있게 단정하는 에이전트의 도구 호출을 확인해 보니, 실제로 영향이 있을 것으로 예상한 코드를 읽지 않은 경우가 있었다. 이런 관찰이 추측을 줄이고 실제 코드 조사를 유도하는 스킬의 필요성으로 이어졌다 [16:56]

8. 스킬은 코딩 능력이 있는 에이전트에 업무 맥락을 가르치는 수단이다

• 에이전트는 코딩은 잘하지만 업무 맥락은 전혀 모르는 신입 엔지니어에 비유할 수 있다. 실패를 보고 불신만 쌓기보다, 새 팀원이 효과적으로 일하려면 어떤 맥락과 지침이 필요한지 생각해야 한다 [17:31]
• 스킬은 Markdown으로 정보와 지침을 담는 수단이다. Tan은 질 높은 입력이 더 나은 응답 패턴을 끌어낼 수 있다는 관점에서, 관찰한 실패마다 실제 코드를 검색하고 확인하며 추측을 멈추도록 하는 스킬을 추가했다 [18:05]

9. Eval로 스킬의 의도와 실제 행동이 일치하는지 확인한다

• Eval은 에이전트용 단위 테스트에 가까운 개념이며, 반드시 특별한 프레임워크가 필요한 것은 아니다. 원하는 엄밀성에 맞춰 직접 만들 수 있다 [19:59]
• Pstack의 Potato Mode에는 Eval Playbook이 있다. 조정 에이전트가 평가 기준을 만들고 여러 하위 에이전트를 개별 디렉터리에서 실행하며, 평가를 인지하면 행동이 달라질 수 있다는 이유로 디렉터리 이름에도 주의를 기울인다 [20:49]

10. 스킬 유지보수에는 초기의 적극적인 관찰과 판단이 필요하다

• 스킬 유지보수는 어렵고, 좋은 결과를 판단하는 감각과 세밀한 관찰이 필요하다. 초기에는 페어 프로그래밍처럼 에이전트의 선택을 적극적으로 살피고 다른 접근이 가능했는지 따져야 한다 [22:29]
• 도구 호출을 펼쳐 보고 코드와 에이전트의 행동을 읽으면 실패 지점을 구체적으로 찾을 수 있다. 자체 스킬을 구축할 때는 이런 관찰을 통해 발견한 문제를 다음 스킬 개선으로 연결한다 [23:00]

11. 검증 스킬 자체도 교차 평가와 반복 개선의 대상이다

• 검증 스킬을 신뢰하는 과정에도 같은 평가·개선 고리를 적용한다. 조정 에이전트가 점수를 산출하고 다른 모델의 심사 에이전트가 교차 확인하게 해, 평가 모델의 편향을 점검할 수 있다 [23:30]
• Cursor의 /loop로 평가를 반복하며 점수를 높이는 방식도 사용할 수 있다. “모든 항목이 10점 만점이 될 때까지”는 반복 목표의 예시이며, Tan은 비슷한 방식으로 제어 스킬의 CLI를 개선했지만 초기에는 많은 반복이 필요했다고 보여준다 [24:14]

12. 엔지니어의 역할은 작업 환경 설계와 업무 배분으로 확장된다

• 에이전트와 일하는 엔지니어는 모든 음식을 직접 만드는 사람보다 여러 조리 담당자를 이끄는 총괄 셰프에 가까워진다. 직접 수행하는 작업 외에도 팀이 일할 수 있는 환경을 설계하는 역할이 커진다 [25:03]
• 주방을 구성하고 담당자별 업무를 배분하듯, 에이전트가 효과적으로 작업할 환경을 준비하고 과제를 나누는 일이 중요해진다 [25:26]

13. 검증 체계의 출발점은 행동을 직접 관찰할 수 있는 로컬 환경이다

• 처음 검증 스킬을 만들 때는 로컬에서 시작하는 것이 좋다. 에이전트가 CLI나 데스크톱 앱을 실행하게 하면 실제로 어떻게 애플리케이션과 상호작용하는지 직접 볼 수 있다 [26:24]
• 앱을 제어하는 API를 어떤 방식으로 호출하는지도 관찰할 수 있어, 검증 과정이 의도대로 작동하는지 확인하기 쉽다 [26:46]

14. 클라우드 검증 자동화는 개인의 도구를 팀 전체의 자산으로 만든다

• 클라우드 실행 환경에 제어·검증 스킬을 갖추면 개인뿐 아니라 팀과 회사 전체가 혜택을 얻을 수 있다. 같은 스킬을 자동화에 활용해 반복적인 확인 작업을 처리할 수 있기 때문이다 [27:02]
• 내부 에이전트 Benny는 버그 보고를 받아 클라우드의 자체 데스크톱에서 Cursor를 실행하고, 같은 제어 스킬로 앱을 조작하며 문제 재현을 시도한다 [27:51]

15. 대규모 병렬화는 검증에 대한 신뢰를 확보한 뒤 확대해야 한다

• 클라우드 에이전트의 활용도 단계적인 신뢰 형성이 전제다. 아직 결과를 믿지 못하는 상태에서 수많은 에이전트를 한꺼번에 실행하면 토큰을 낭비하고 비용이 크게 늘 수 있다 [29:00]
• 출발점은 검증 스킬과 확인 방법을 마련해 에이전트가 적어도 문제를 실제로 해결하는 코드를 만드는지 판단하는 것이다. 스택 트레이스와 앱의 실제 동작이 근거가 되며, 코드 자체가 좋은지는 별도의 판단으로 남는다 [29:35]

16. 자동화의 확대는 검증으로 쌓은 신뢰에 달려 있다

• 로컬 에이전트 활용 다음에는 클라우드 에이전트가 버그 보고를 받아 문제를 해결하고 PR을 만드는 단계가 있으며, PR 자동 병합까지 나아갈지는 각자의 신뢰 수준에 달려 있다. 모든 행동을 관찰하는 초기 단계에서 높은 자율성으로 넘어가는 데 지름길은 없다. [30:01]
• 플러그인이나 다른 사람의 스킬을 맹신하기보다 직접 검토하고 수정해야 한다. 팀마다 중요한 엔지니어링 기준을 스킬에 담고 에이전트의 준수를 검증할 수 있어야 자동화 범위를 넓힐 수 있다. [31:16]

17. 기존 코드베이스의 보호 장치는 에이전트에게도 유효하다

• 애플리케이션 재작성은 흔히 만류되는 선택이지만, 에이전트 시대에는 상황에 따라 다시 검토할 여지가 있다. 특히 기반이 잘 갖춰진 기존 애플리케이션은 에이전트 활용에 유리한 위치에 있다. [32:14]
• 대규모 조직도 뛰어난 엔지니어가 많다는 이유만으로 코드 품질이 높아지지는 않는다. 프레임워크, 관례, 가드레일, 자격 증명 제한처럼 사람의 실수를 막던 기반이 이미 있다면 에이전트도 그 안에서 안정적으로 작업할 수 있다. [33:25]

18. 보호 장치 없는 신규 프로젝트는 편법이 누적되기 쉽다

• 신규 애플리케이션은 큰 기회이자 위험이다. GrokBot도 빠르게 만든 프로토타입에서 출발했으며, 초기에는 사람이 코드를 전혀 읽지 않은 채 개발했다. [34:49]
• 제약 없는 코드베이스에서 에이전트는 당장 가장 편리한 방식으로 과제를 해결한다. 이런 선택이 쌓이면 사람이 이해하지 못하고 지름길에 최적화된 구조가 생겨, 코드베이스를 통제하기 어려워진다. [35:50]

19. 자동 병합을 가능하게 만든 대규모 구조 개선

• 코드베이스에는 처음부터 강한 제약이 필요하다. GrokBot을 새로운 아키텍처로 리팩터링하는 데 600개가 넘는 PR을 투입했으며, 이러한 선행 작업을 거친 뒤에는 자고 일어났을 때 에이전트가 PR 약 20개를 병합한 상태에 도달했다. [36:30]
• 코드를 거의 직접 보지 않는 작업 방식은 상당한 시간과 토큰 투자로 얻은 결과다. 엄격한 제약과 CI는 디자이너·PM·GTM 담당자의 기능 추가도 뒷받침하며, 개발 과정의 번거로움은 에이전트가 감당한다. [37:15]

20. PR은 줄 수보다 변경의 독립성을 기준으로 나눈다

• 정확한 평균 PR 크기는 알 수 없지만, 작업에 따라 약 50줄에서 수백 줄, 천 줄 정도까지 달라진다. 파일 삭제가 대부분인 변경도 있어 줄 수만으로 작업 성격을 판단하기 어렵다. [39:22]
• PR 크기에 상한을 두지는 않되 여러 PR로 작업을 나누도록 권장한다. 각 PR이 하나의 작은 변경을 독립적으로 설명하면 Git 이력이 유용한 맥락으로 남고, 버그 위치를 찾거나 변경을 되돌리기 쉬워진다. [39:51]

21. Dune은 반복되는 실수를 CI 실패로 바꾼다

• GrokBot의 아키텍처인 Dune은 에이전트가 코드를 작성하도록 설계한 것으로, Electron 앱을 위한 Next.js와 비슷한 개념이다. React의 useEffect 사용을 금지하고 이를 어기면 CI가 실패하게 한다. [40:58]
• 코드 주석도 금지한다. 에이전트가 특정 PR에 대한 일회성 피드백을 영구적인 전역 규칙처럼 주석에 남기는 등, 코드와 무관한 과거 맥락을 고착시키는 문제가 그 이유다. [41:55]

22. 프로세스 분리 부족은 반복적인 성능 저하로 계속된다

• Agents 창에는 아직 같은 아키텍처가 적용되지 않았으며, 많은 PR이 병합되는 과정에서 성능·안정성·신뢰성이 자주 퇴행한다. GrokBot에서 얻은 교훈을 해당 코드에도 적용해 리팩터링할 계획이다. [42:53]
• Electron에서 메인 스레드와 렌더러의 역할이 제대로 분리되지 않으면 무거운 연산이나 I/O가 렌더러로 유입된다. 60fps를 위해 프레임당 약 16밀리초 안에 처리를 마쳐야 하는 상황에서 이런 작업은 프레임 손실과 끊김을 만든다. [43:28]

23. 의존성 그래프 검사로 실행 영역의 경계를 강제한다

• Electron 앱 개발에서 배운 위험 패턴을 프레임워크에 반영하고, 위반하면 검사가 실패하도록 만든다. GrokBot은 electron main과 electron renderer 디렉터리를 구분하며, 의존성 그래프를 검사해 두 영역 사이의 잘못된 import를 막는다. [44:37]
• 같은 경계를 CI뿐 아니라 코드 리뷰 도구 Bugbot과 AGENTS.md에도 반영한다. 하나의 안내에 의존하지 않고 여러 층에서 제약을 적용한다. [45:04]

24. 가장 쉬운 구현 경로가 올바른 경로가 되도록 설계한다

• 에이전트는 기존 패턴을 모방하므로 기능 구현 방식 자체를 엄격하고 일관되게 만드는 것이 강력한 통제 수단이다. GrokBot은 기능, 진입점, 대화 카드 같은 개념에 정해진 생성 방식을 제공한다. [45:25]
• 한 기능에 기여하는 코드를 하나의 디렉터리에 모아 둔다. 온보딩 기능을 수정한다면 해당 디렉터리에서 작업할 수 있고, 약 80%의 작업이 그 안에 국한되어 관련 코드를 찾아다닐 필요가 줄어든다. [46:08]

25. 규칙과 스킬은 강제 가능한 검사 위에 겹쳐야 한다

• 디렉터리 구조와 import 제한에 정적 분석, CI 검사, 나쁜 패턴을 잡는 린트, 컴파일러 진단을 결합한다. 이러한 검사는 위반 시 CI를 실패시키는 강제 수단이다. [47:31]
• 규칙·스킬·Bugbot은 에이전트가 잊거나 일관되게 적용하지 않을 수 있다. 여러 층으로 활용하되 유일한 통제 수단으로 삼지 말고, 반드시 강제할 수 있는 제약에 투자해야 한다. [48:16]

26. 반복되는 코드 리뷰 지적은 자동 검사로 전환한다

• 사람이 매번 코드를 읽으며 금지 사항과 불변 조건을 지키게 하는 상태는 자동화의 병목이다. 같은 제약을 PR 댓글로 반복해서 설명해야 한다면 이를 개선할 신호로 봐야 한다. [49:46]
• 반복 지적은 린트 규칙이나 CI 실패 조건으로 바꾸고, 가능하다면 문제가 생기는 경로 자체를 구조적으로 제거해야 한다. [50:06]

27. 초기 토큰 비용은 인력과 장기 생산성의 교환 관계다

• 무제한 토큰을 사용할 수 있는 AI 연구소의 환경이므로, 모두가 같은 방식으로 투자해야 한다고 일반화할 수는 없다. 큰 비용 없이 비슷한 수준에 도달할 가능성은 있다고 보지만, 리팩터링과 제약 구축에는 상당한 초기 토큰이 든다. [51:29]
• 에이전트의 가치는 이전에는 하기 어려웠던 일을 가능하게 하는 데 있다. 혼자 프레임워크를 만들고 전체 리팩터링과 검증까지 했다면 수년이 걸렸을 작업을 기준으로, 인력 채용과 토큰 투자의 수익성을 비교해야 한다. [52:43]

28. 모델 선택에서도 비용 대비 지능이 중요하다

• Grok 4.6의 성능을 긍정적으로 평가하며, 토큰당 가격은 4.5와 같다고 알고 있다는 단서를 붙인다. 가격에 대한 기억이 맞다면 같은 비용으로 더 높은 지능을 얻는다는 해석이다. [54:24]
• 목표는 무조건 가장 큰 모델을 만드는 것이 아니라 지능과 추론 비용 사이의 적절한 균형을 찾는 것이다. 아키텍처 투자 역시 팀 전체의 생산성 향상을 포함해 분석하면 긍정적인 수익을 기대할 수 있다는 전망이다. [54:57]

29. 비개발 직군에는 익숙한 에이전트 인터페이스가 필요하다

• 기존 Agents 창·CLI·IDE는 개발자 중심 도구여서 지식 업무에도 쓸 수는 있지만, 제품·GTM 담당자에게 적합한 사용 경험은 아니었다. [56:25]
• GrokBot은 iMessage처럼 익숙한 인터페이스에서 에이전트에 이름을 붙이고 팀원처럼 조율하게 한다. 관리하는 고객 계정마다 에이전트를 두거나, PM이 밤사이 엔지니어의 작업을 요약받는 식으로 활용할 수 있다. [57:08]

30. 엄격한 구조는 PM과 디자이너의 직접 기여로 계속된다

• PM이 에이전트로 버그를 고친 뒤 리뷰를 요청하고, 수정이 적절해 그대로 승인되는 사례가 나타난다. 이러한 경험은 Dune의 엄격한 제약이 엔지니어링 전문가가 아닌 사람의 높은 수준의 기여를 뒷받침한다는 근거가 된다. [57:51]
• 디자이너와 PM이 기능을 직접 출시하면서 GrokBot 팀의 개발 속도가 빨라지는 효과를 체감하고 있다. 추가 기능도 계획하고 있지만, 구체적인 내용이나 일정은 제시하지 않는다. [58:18]

🧾 결론

• 올바르게 동작하는 코드와 좋은 코드는 구분해야 한다. 실행 검증이 통과해도 구조·유지보수성에 대한 판단은 남는다.
• 로컬에서 행동을 관찰하고 검증 스킬을 다듬은 뒤, 클라우드 작업과 자동 병합으로 범위를 넓히는 순서가 중요하다.
• 규칙과 스킬은 정적 분석·린트·CI 같은 강제 수단 위에 겹쳐야 한다. 가장 쉬운 구현 경로가 올바른 경로가 되도록 설계하는 것이 핵심이다.

📈 투자·시사 포인트

• 에이전트 도입의 경제성은 토큰 지출뿐 아니라 검증에 드는 사람의 시간, 구조 개선 비용, 팀 전체의 기여 확대를 함께 비교해야 한다.
• 프레임워크·관례·보호 장치가 갖춰진 기존 코드베이스는 에이전트 활용의 기반이 될 수 있다. 신규 프로젝트도 초기 제약 설계가 중요하다.
• 엔지니어의 역할은 직접 구현에서 작업 환경 설계와 업무 배분으로 확장된다. 엄격한 구조는 PM·디자이너의 직접 기여도 뒷받침할 수 있다.
• 모델 선택에서는 지능과 추론 비용의 균형이 중요하다. 다만 발표의 생산성 사례만으로 특정 제품의 수익성이나 보편적인 투자 성과를 확정할 수는 없다.

⚠️ 불확실하거나 확인이 필요한 부분

• PR 처리량과 자동 병합 사례는 발표자의 경험이다. PR 크기와 성격이 다양하며, 처리량만으로 결함률이나 유지보수 품질을 확인할 수 없다.
• 무제한 토큰을 사용할 수 있는 AI 연구소의 환경이 전제돼 있다. 일반 팀이 같은 수준의 자동화에 도달하는 비용과 기간은 제시되지 않았다.
• Grok 4.6의 가격이 4.5와 같다는 언급은 발표자의 기억에 따른 조건부 주장이다. 가격과 성능 우위는 별도 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 로컬에서 에이전트가 앱을 실행하고 문제를 재현하며 트레이스나 오류를 수집하는 과정을 직접 관찰한다.
• 주요 기능의 UI 접근 경로·단축키·DOM 선택 정보를 Feature Map으로 정리하고 갱신 방법을 마련한다.
• 반복되는 실패를 스킬에 반영하고, 수정 전후의 실제 행동을 Eval로 비교한다.
• 반복되는 리뷰 지적과 아키텍처 경계 위반을 린트·정적 분석·CI 실패 조건으로 전환한다.

❓ 열린 질문

• 우리 팀은 어떤 검증 결과와 코드 품질 기준을 충족했을 때 자동 병합을 허용할 것인가?
• 초기 리팩터링·스킬 유지보수·토큰 비용을 상쇄할 만큼 사람의 검증 시간과 반복 작업이 줄어드는가?
• Eval에서 높은 점수를 받은 스킬이 실제 사용자 환경의 성능·안정성 퇴행도 충분히 찾아내는가?