신뢰할 수 있는 코딩 에이전트 시스템을 만드는 법

Lauren Tan은 Cursor에 합류한 지 약 5개월 만에 한 달 동안 PR 약 1,000개를 반영했고, 그다음 달에는 12일까지 약 800개를 추가로 반영했다. 어떤 날에는 에이전트가 밤사이에 PR 20개를 자동으로 병합하기도 한다. 그러나 출발점부터 에이전트를 이렇게 믿었던 것은 아니다. Meta의 React Compiler 팀과 Netflix의 테크 리드 및 엔지니어링 매니저를 거친 그는, 에이전트를 활용하는 일이 팀을 운영하는 일과 매우 비슷하다고 말한다.

에이전트의 생산량을 늘리는 핵심은 더 많은 작업을 동시에 맡기는 데 있지 않다. 먼저 사람이 반복해서 내리던 판단을 시스템이 자동으로 수행하게 해야 한다. Tan의 경험에 따르면, 그 시스템은 검증 도구와 기능 지도로 시작하여, 평가와 자동화로 확장되고, 마지막에는 아키텍처와 CI의 강제 규칙으로 완성된다.

신뢰는 프롬프트가 아니라 검증 능력에서 시작된다

숙련된 엔지니어는 에이전트가 추측하거나 환각하면서도 문제의 원인을 찾았다고 확신하는 모습을 여러 번 본다. 이런 경험이 쌓이면 사람은 모든 출력을 읽고, 모든 변경을 직접 실행하며, 화면과 오류를 다시 에이전트에게 전달하게 된다. 관리자가 팀원을 믿지 못할 때 세세한 부분까지 통제하는 상황과 같다. 사람 한 명이 검증을 전담하면 에이전트를 여러 개 실행하더라도 처리량은 늘어나지 않는다.

Tan이 말하는 검증은 테스트 명령 하나를 실행하는 데 그치지 않는다. 사용자가 제품을 경험하는 경로를 에이전트도 직접 재현할 수 있어야 한다. 코드를 실행하고, CPU 트레이스와 힙 스냅샷을 수집하고, iOS 시뮬레이터를 조작하며, 실제 화면에서 동작을 확인해야 한다. 검증은 에이전트가 좋은 코드를 쓰게 해 주지는 않지만, 적어도 코드가 올바르게 작동하는지 확인할 수 있게 하므로 에이전트에 맡길 수 있는 범위를 넓히는 첫 단계가 된다.

Cursor의 Agents 창 성능을 개선하던 초기 경험이 이 원칙을 분명하게 보여준다. 입사 첫 주에 Tan은 출시를 일주일 앞둔 React 애플리케이션을 맡았다. 그는 Chrome DevTools에서 플레임 그래프를 읽고 트레이스를 내려받아 에이전트에게 보여줬지만, 에이전트는 실제 병목과 관계없는 원인을 자신 있게 지목하곤 했다. 사람이 수정된 코드를 다시 실행하고 오류나 스크린숏을 전달해야 했기 때문에 작업은 느렸고 병렬화하기도 어려웠다.

Tan은 이 병목을 없애려고 control-glass 스킬을 만들었다. Glass는 Cursor 내부에서 Agents 창을 부르는 코드명이다. 이 스킬은 Chrome DevTools Protocol이나 Apple의 Simulator 도구를 사용하여 에이전트가 애플리케이션을 직접 실행하고 조작하며 성능 자료를 수집하게 한다. 웹, Electron, iOS처럼 사용자에게 노출되는 애플리케이션이라면 각각의 실제 실행 환경을 에이전트에게 제공할 수 있다는 설명이다.

기능 지도는 코드와 사용자 경험 사이를 연결한다

실행 도구만 제공해도 새로운 문제가 생겼다. 에이전트는 애플리케이션을 조작할 수 있었지만 제품의 구조를 몰랐다. “왼쪽 사이드바가 느리다”거나 “오른쪽 PR 탭이 작동하지 않는다”는 제보를 받으면, 해당 기능의 코드가 어디에 있고 화면에서는 어떻게 접근해야 하는지 찾느라 시간을 허비했다. 제품을 직접 실행할 수 있는 능력과 무엇을 검증해야 하는지 이해하는 능력은 서로 달랐다.

Tan은 검증 스킬에 feature map을 추가했다. 기능 지도에는 사용자의 관점에서 본 하위 기능, 접근 경로, 키보드 단축키, 그리고 Chrome DevTools Protocol이 요소를 선택할 때 사용할 DOM 속성까지 들어간다. 누군가 스크린숏 하나와 물음표뿐인 부실한 제보를 보내더라도, 에이전트는 기능 지도를 참고하여 관련 화면으로 이동하고 문제를 재현할 수 있다. 제품의 기능이 바뀌면 별도의 유지관리 스킬이 지도를 갱신한다.

검증 도구가 에이전트에 직접 조작하고 관찰하는 능력을 제공한다면, 기능 지도는 제품 안에서 길을 찾는 지식을 제공한다. 이 둘을 함께 갖춰야 사용자의 모호한 제보를 실제 기능과 코드에 연결할 수 있다. Tan이 공개한 Pstack 플러그인의 검증 스킬은 코드베이스를 탐색하여 초기 기능 지도를 만들고, 이후에도 그 지도를 유지하도록 돕는다.

Pstack은 처음부터 완성된 방법론으로 기획한 결과가 아니다. 이름은 Y Combinator CEO Gary Tan의 Gstack과 자신의 온라인 별명인 Potato를 조합하여 지은 것이다. 실제 내용은 에이전트의 실패를 가까이에서 관찰하면서 하나씩 추가한 스킬의 모음에 가깝다. 예를 들어 버그의 원인을 묻자 에이전트가 관련 코드를 읽지도 않고 답하는 모습을 보고, 먼저 코드에서 근거를 찾고 추측을 멈추도록 하는 스킬을 만들었다.

이 접근법은 신입 엔지니어를 온보딩하는 일과 비슷하다. 뛰어난 코딩 능력이 있더라도 사업 맥락과 코드베이스 지식이 없는 사람에게는 업무 방식을 가르쳐야 한다. 에이전트도 마찬가지다. 실패할 때마다 지시를 더 길게 덧붙이는 것보다, 실패 양상을 관찰하고 필요한 지식과 절차를 재사용 가능한 스킬로 명시하는 편이 낫다. 초기에는 도구 호출과 사고 과정을 세밀하게 살펴보면서 어디에서 근거 없이 판단하고 어떤 맥락을 놓치는지 찾아야 한다.

스킬은 평가로 다듬고 자동화는 로컬에서 출발한다

스킬도 작성했다고 해서 바로 신뢰할 수 있는 것은 아니다. Tan은 평가를 에이전트를 위한 단위 테스트처럼 사용한다. 먼저 주 에이전트가 스킬이 기대한 대로 작동하는지 평가할 기준을 만들고, 여러 하위 에이전트가 각자 격리된 디렉터리에서 같은 과제를 수행한다. 평가받고 있다는 사실이 행동을 바꿀 수 있으므로, 실행 디렉터리의 이름도 평가임을 드러내지 않게 정한다. Cursor가 지원하는 여러 모델로 같은 스킬을 실행하여 모델별 결과도 비교한다.

결과를 채점하는 주 에이전트만 믿지 않고 다른 모델을 판정자로 추가하여 편향을 교차 점검할 수도 있다. 점수가 충분히 높아질 때까지 평가와 개선을 반복하는 방식도 쓴다. Tan은 스킬을 수정할 때마다 이런 평가를 실행한다. 다만 자동 평가만으로 유지보수가 해결되지는 않는다. 에이전트의 행동을 관찰하고, 동료와 페어 프로그래밍할 때처럼 “왜 이 코드를 읽지 않았는가”와 “더 나은 경로는 무엇인가”를 알아차리는 사람의 취향과 판단이 필요하다.

Tan은 이 역할을 식당의 총괄 셰프에 비유한다. 이제 엔지니어는 모든 요리를 직접 만드는 사람이 아니다. 작업대를 배치하고, 역할을 나누며, 각 담당자가 일관된 결과를 내도록 주방을 설계한다. 에이전트 시대에 숙련된 엔지니어의 중요한 산출물은 개별 코드만이 아니라, 여러 에이전트가 좋은 결과를 반복해서 내도록 만드는 작업 환경이다.

검증 체계를 처음 만들 때는 로컬 환경이 적합하다. CLI, 데스크톱 애플리케이션, 웹 애플리케이션을 에이전트가 어떻게 실행하고 어떤 API로 조작하는지 사람이 직접 볼 수 있기 때문이다. 로컬에서 동작을 이해하고 결과를 신뢰하게 된 다음에야 클라우드 에이전트로 확장해야 한다. 처음부터 에이전트 수백 개를 실행하면 잘못된 작업에 토큰만 대량으로 소비할 가능성이 크다.

로컬에서 검증한 스킬을 클라우드 에이전트에 적용하면 더 큰 효과를 낸다. Cursor 내부의 Benny라는 에이전트는 새 버그 보고를 받으면 클라우드 환경에서 Cursor를 실행하고, 동일한 제어 및 검증 스킬로 문제를 재현한다. 한 사례에서는 제보된 버그를 재현한 뒤 main에서는 이미 문제가 해결되었다는 사실까지 확인했다. 사람이 한 시간 동안 조사하지 않아도 다음 빌드만 배포하면 된다는 결론을 얻은 것이다. 이런 자동화는 개인의 생산성뿐 아니라 같은 도구를 쓰는 팀 전체의 대응 속도를 높인다.

에이전트 시대에는 오래된 코드보다 무제약 신생 코드가 더 위험하다

Tan이 설명하는 신뢰의 단계는 한두 개의 에이전트를 계속 지켜보는 것에서 시작하여, 로컬 병렬 실행과 클라우드 에이전트를 거쳐 자동 병합에 이른다. 이 단계를 건너뛰는 지름길은 없다. 각 조직과 엔지니어마다 중요하게 여기는 품질 기준이 다르므로, 그 기준을 스킬에 명시하고 실제로 지켜지는지 검증하면서 에이전트에 대한 신뢰를 쌓아야 한다. Pstack을 그대로 믿을 필요도 없다. 내용을 살펴보고 포크한 뒤 자신의 기준에 맞게 바꾸는 편이 바람직하다.

이 관점은 오래된 애플리케이션을 다시 작성할 것인지에 관한 판단도 바꾼다. 일반적으로 재작성은 위험하다고 여겨지지만, 에이전트가 대부분의 코드를 작성하는 환경에서는 기존 대규모 코드베이스가 오히려 유리할 수 있다. Meta나 Google 같은 회사는 수많은 엔지니어가 동시에 기여해도 사고가 나지 않도록 프레임워크, 관례, 안전장치, 자격 증명 제한을 오래전부터 구축했다. 이런 장치들은 사람 가운데 경험이 가장 적은 구성원을 보호하기 위해 만들어졌지만, 에이전트가 잘못된 선택을 하지 못하게 막는 데에도 그대로 쓰인다.

반대로 아무런 제약 없이 빠르게 만든 그린필드 애플리케이션은 가장 큰 위험이자 가장 큰 개선 기회다. 에이전트는 주어진 과제를 해결하는 가장 편한 방법을 택하는 경향이 있다. 초기에 일관된 구조가 없으면 매번 다른 지름길이 쌓이고, 사람도 에이전트도 전체 구조를 이해하기 어려운 코드베이스가 된다. 빠른 프로토타입 제작에 성공했더라도 이 상태를 그대로 확장하면 성능, 안정성, 유지보수 문제가 누적된다.

Grokbot도 처음에는 사람이 코드를 거의 읽지 않은 채 빠르게 만든 프로토타입이었다. Grokbot은 이름과 역할이 있는 여러 에이전트를 익숙한 메시지형 화면에서 조율하는 애플리케이션이다. Tan은 이후 600개가 넘는 PR을 반영하여 새로운 아키텍처로 대대적으로 정리했다. 자동 병합을 가능하게 만든 것은 에이전트 모델에 대한 막연한 신뢰가 아니라, 잘못된 구현이 통과하기 어려운 코드베이스에 대한 신뢰였다. 제약이 충분하면 에이전트가 그 번거로움을 대신 감당하므로, 사람은 모든 코드를 직접 읽지 않아도 된다.

가장 쉬운 구현 경로를 가장 좋은 경로로 만든다

Tan은 Grokbot을 위해 만든 아키텍처를 Dune이라고 부른다. 에이전트가 Electron 애플리케이션을 작성하도록 설계한 프레임워크이며, 개념상 Electron용 Next.js에 가깝다. 이 구조에서는 기능 하나와 관련된 코드를 단일 디렉터리에 함께 배치하고, 진입점이나 트랜스크립트 카드 같은 주요 요소를 일정한 방식으로 구현한다. 온보딩 기능을 수정하는 에이전트는 여러 위치를 헤매지 않고 해당 기능 디렉터리 안에서 대부분의 작업을 끝낼 수 있다.

에이전트는 기존 패턴을 복사하고 가장 짧은 해결책을 택하는 데 익숙하다. 그러므로 나쁜 지름길을 매번 경고하는 대신 올바른 구조를 따르는 일이 가장 짧고 쉬운 경로가 되도록 설계해야 한다. 에이전트에게 좋은 선택을 요구하는 것보다, 가장 편한 선택이 곧 좋은 선택이 되도록 아키텍처를 만드는 편이 더 효과적이다. Dune은 공개할 단일 제품이라기보다 이런 원칙과 설계 선택을 모은 체계에 가깝다.

아키텍처 위에는 강제력이 다른 여러 층이 놓인다. 가장 단단한 층은 코드 구조, 컴파일러 진단, 린트, CI 검사다. 그 위에 규칙, 스킬, 스타일 가이드, Cursor의 코드 리뷰 도구인 Bugbot이 있다. 후자의 장치들은 유용하지만 에이전트가 잊거나 일관되게 적용하지 않을 수 있다. 반면 컴파일러와 CI는 조건을 위반하면 변경을 통과시키지 않는다. Tan은 구속력이 약한 지시만 쌓아 놓으면 결국 코드 품질이 무너진다고 본다.

Grokbot의 CI는 실제 실패에서 얻은 교훈을 구체적인 금지 규칙으로 바꾼다. React의 useEffect를 위험한 구현 수단으로 보고 사용을 금지하며, 과거의 일회성 지시를 영구 규칙처럼 남기는 경우가 많다는 이유로 코드 주석도 금지한다. 이러한 선택을 모든 프로젝트가 그대로 따라야 한다는 뜻은 아니다. 중요한 점은 에이전트가 반복해서 만드는 문제를 발견할 때마다 사람이 PR에 같은 말을 남기지 않고, 반복되는 지적 사항을 정적 분석 규칙이나 CI 검사로 전환한다는 데 있다.

Electron의 프로세스 격리는 더 구체적인 사례다. 렌더러 스레드는 화면을 초당 60프레임으로 부드럽게 표시하려면 프레임 하나를 약 16ms 안에 처리해야 한다. 계산이나 I/O가 무거운 코드가 실수로 렌더러에 포함되면 프레임 처리가 늦어져 화면이 끊긴다. Grokbot은 메인 프로세스와 렌더러 프로세스의 디렉터리를 분리하고, 의존성 그래프를 검사하여 한 프로세스의 코드가 다른 프로세스의 코드를 잘못 가져오는 일을 CI에서 차단한다. 사람의 주의력에 기대던 성능 원칙이 기계적으로 검사되는 구조가 된 셈이다.

Rust가 에이전트 개발에서 다시 주목받는 이유도 같은 맥락으로 설명한다. 엄격한 컴파일러와 빌림 검사기가 많은 오류를 미리 막고, unsafe 사용을 제한하면 컴파일 성공 자체가 일정 수준의 신뢰를 제공한다. 사람이 코드 리뷰에서 같은 불변 조건을 반복해서 지적하고 있다면, 그것은 사람에게 남겨 둘 판단이 아니라 린트, 컴파일러, CI, 또는 아예 문제가 발생할 수 없는 구조로 옮겨야 할 신호다.

PR의 크기에는 절대적인 상한을 두지 않는다. 작업에 따라 50줄에서 수백 줄, 때로는 1,000줄 정도가 될 수 있다. 다만 서로 다른 변경은 여러 PR로 나누도록 권장한다. 각 PR과 커밋이 작은 변경 하나만 담으면 Git 기록에 풍부한 맥락이 남고, 문제가 생겼을 때 원인을 찾거나 되돌리기도 쉽다. 4만 줄짜리 PR 하나에 모든 변경을 넣는 방식은 빠르게 많은 PR을 병합하려는 목표와 별개로 피해야 한다.

토큰 비용은 한 사람의 속도가 아니라 조직의 처리량으로 판단한다

Tan은 AI 연구소에서 사실상 제한 없이 토큰을 사용할 수 있으므로 자신의 방식을 모두가 그대로 따라야 한다고 주장하지 않는다. 아키텍처를 정리하고, 검증 도구를 만들고, 정적 분석 규칙을 추가하는 초기 작업에는 많은 토큰이 든다. 따라서 이 접근법은 무료가 아니며, 개인 개발자와 조직이 같은 규모로 적용할 수도 없다.

그럼에도 엔지니어링 리더나 스타트업 창업자라면 비용을 투자 수익률로 평가해야 한다고 말한다. 에이전트가 대부분의 코드를 작성하는 방향으로 간다면, 수천 명의 엔지니어를 고용하고 계획 및 조율 비용을 감당하는 방식과 에이전트가 좋은 코드를 쓰도록 기반을 정비하는 방식을 비교해야 한다. Tan이 혼자 Dune 같은 프레임워크를 만들고 대규모 리팩터링과 검증을 수행했다면 몇 년이 걸렸을 수 있다. 토큰 덕분에 한 사람이 예전에는 불가능했던 수준의 구조적 개선을 수행할 수 있었다.

초기 토큰 투자로 얻는 수익은 PR 개수만이 아니라, 경험이 적은 에이전트와 비개발 직군도 개발에 안전하게 기여함으로써 높아지는 조직 전체의 생산성으로 계산해야 한다. 엄격한 구조와 제약을 갖추면 가장 강력한 모델이 아니어도 좋은 결과를 낼 수 있다. Tan은 당시 발표된 Grok 4.6이 4.5와 같은 토큰 가격으로 더 높은 지능을 제공한다고 소개하면서, 규모가 가장 큰 모델을 선택하기보다 비용과 지능 사이의 적절한 지점을 찾는 일이 중요하다고 덧붙였다.

Grokbot은 이 효과를 개발팀 밖으로도 넓힌다. 기존 Cursor IDE와 CLI는 개발자 중심의 고급 사용자용 도구였지만, Grokbot은 iMessage와 비슷한 익숙한 화면에서 이름과 역할이 있는 에이전트를 여러 개 운영하게 한다. 영업 담당자는 계정별 에이전트를 두고, PM은 밤사이에 반영된 변경을 요약하는 에이전트를 사용할 수 있다. PM과 디자이너가 직접 버그를 수정하여 PR을 보내고, 그 결과물의 완성도가 높아 엔지니어가 검토한 뒤 그대로 승인한 사례도 생겼다.

결국 에이전트를 확장하는 방법은 감독을 포기하는 것이 아니다. 사람이 반복해서 수행하던 감독을 실행 가능한 검증, 탐색할 수 있는 제품 지식, 평가를 거친 스킬, 예측 가능한 아키텍처, 위반 사항이 있으면 실패하는 CI로 전환하는 일이다. 이 기반이 갖춰지면 사람은 모든 코드 줄을 읽는 역할에서 벗어나, 어떤 판단을 시스템에 새로 반영해야 하는지 결정하는 역할에 집중할 수 있다.

원본 영상

Deep Dive

2026-09-08

Core loop를 실제 검증 절차로 구체화한다

내 workflow의 PRODUCT.md에 core loop를 넣은 의도도 에이전트가 사용자의 핵심 흐름을 이해하고 검증하게 하려는 것이었다. Pstack의 프로젝트 전용 검증 스킬과 기능 지도는 같은 방향에서 실행 방법과 유지 절차를 더 구체화한 접근으로 이해할 수 있다.

이번에 확인한 원본 skills 저장소의 implement는 이미 변경한 흐름과 core loop의 대표 여정을 실행하고, 현재 코드가 실행 중인지와 실제 결과를 확인하도록 요구한다. 따라서 Pstack이 처음으로 사용자 흐름 검증을 도입하는 것은 아니다. 비교할 지점은 프로젝트마다 되풀이하는 실행 환경 조사와 제품 탐색을 얼마나 재사용 가능한 절차로 남기느냐에 있다.

기능 지도와 E2E 테스트의 중복은 실제 비용이다

처음에는 테스트 코드가 처음부터 끝까지 제품을 직접 조작하기 어려워서 기능 지도를 문서로 남기는 것인지 의문이 들었다. 하지만 E2E 테스트도 앱을 실행하고, 클릭하고, 입력하고, 저장 결과를 확인할 수 있다. Pstack 역시 기존 Playwright나 Cypress 같은 실행 도구가 있으면 활용하는 방향이다.

공식 노트 앱 예제를 보면 기능 지도에는 자연어로 적은 테스트 절차가 상당 부분 들어 있다. 도구가 검색어 입력 명령을 실행한 뒤, 에이전트가 “해당 노트와 일치한 본문 일부가 보여야 한다”는 문장을 읽고 결과를 판단한다. 테스트 코드에서는 이 기대 결과를 assertion으로 표현할 수 있다. 문서와 테스트에 같은 절차와 조건을 각각 적으면 변경할 곳이 두 군데가 된다.

문서가 추가로 유용할 수 있는 지점은 처음 보는 제품을 탐색하는 데 필요한 지식이다. “오른쪽 검색이 이상하다”는 모호한 제보를 받았을 때 어느 화면을 열고, 어떤 상태를 준비하고, 어떤 진입 경로를 비교할지 알려줄 수 있다. 이는 공식 문서의 구성에서 도출한 해석이다. 에이전트는 테스트 코드도 읽을 수 있으므로, 기존 테스트와 공통 실행 도구가 이 지식까지 충분히 전달한다면 별도 기능 지도의 이점은 줄어든다.

자연어 절차에는 해석과 누락의 여지도 있다. 공식 예제에서도 검색을 다시 열라는 설명 뒤에 검색어 입력 명령만 제시되는 등, 연결 동작 일부를 에이전트가 채워야 한다. 상황에 맞춰 탐색할 수 있다는 장점과, 같은 절차를 반복 실행할 때의 일관성을 함께 따져야 한다.

Pstack은 문서가 낡는 문제를 유지 절차로 관리한다

Pstack의 기능 지도는 코드 변경과 동시에 자동으로 동기화되는 산출물이 아니다. 생성 스킬로 초기 지도를 만들고, 유지관리 스킬을 실행하여 코드와 실제 앱을 대조한다. 살펴본 유지관리 절차는 다음과 같다.

1. 기능별로 코드를 읽어 기존 문서와의 차이를 찾고, 최근 추가되어 지도에서 빠진 기능도 확인한다.
2. 실제 앱에서 지도에 있는 모든 기능을 적어도 한 번씩 실행한다. 코드 검토에서 차이가 없었던 기능도 실행 대상에 포함한다.
3. 문서가 낡았다면 문서를 고치고, 조작 도구에 문제가 있다면 도구를 고친 뒤 다시 실행한다. 제품 자체의 회귀라면 문제를 보고한다. 잘못된 동작을 정상으로 인정하도록 기대 결과를 바꾸지 않는다.
4. 실행 근거를 바탕으로 검증 스킬과 기능 지도를 갱신하고, 해결하지 못한 항목은 차단 원인과 함께 남긴다.

이 방식은 동기화 작업을 없애지 않는다. 에이전트가 코드 조사와 실제 실행을 수행하도록 유지 작업을 절차화한 것이다. 유지관리 스킬이 존재한다는 것과 정기 실행이 설정되어 있다는 것도 별개다.

별도 기능 지도의 도입은 이번에는 보류한다. core loop에서 실제 검증으로 이어지는 방향은 이해했지만, 기존 테스트가 이미 전달하는 내용과 겹치는 문서를 추가할 가치는 더 검토하기로 했다. 다시 판단할 때에는 기능 지도가 줄이는 탐색 비용과 코드·테스트·문서를 함께 유지하는 비용을 비교해야 한다.

Key Insight

에이전트가 반복해서 내려야 하는 구현 판단은 재사용 가능한 API와 코드 구조, 린트·CI 검사로 줄인다. 별도 기능 지도는 기존 테스트가 전달하지 못하는 제품 지식의 가치가 유지 비용보다 클 때 도입을 검토한다.

References

• Pstack 검증 스킬 생성: 프로젝트 실행 환경과 조작 도구를 조사하여 검증 스킬과 초기 기능 지도를 만드는 절차를 확인했다.
• Pstack 기능 지도 공통 색인: 공통 준비 조건, 기능 문서의 네 가지 항목, 검증 증거 기준을 확인했다.
• Pstack 노트 검색 예제: 실제 명령과 자연어 기대 결과를 읽으며 E2E 테스트와 겹치는 부분을 비교했다.
• Pstack 검증 스킬 유지관리: 코드 조사와 실제 실행을 통해 문서 변경, 도구 문제, 제품 회귀를 구분하는 절차를 확인했다.
• Electron 렌더러 성능 지침: 무거운 작업이 화면을 멈추게 하는 이유와 별도 실행 환경으로 작업을 옮기는 예시를 이해하는 데 참고했다.