Lauren Tan이 말한 에이전트 신뢰의 조건: Evals·검증 스킬·CI·아키텍처 | DAKER 커뮤니티

에이전트를 여러 개 붙여 빠르게 개발하는 이야기는 많지만, 정작 중요한 질문은 따로 있습니다. 정말 믿고 맡길 수 있는가입니다. 이 질문이 풀리지 않으면 사람은 결국 모든 출력을 다시 읽고, 고치고, 확인하는 병목으로 남게 됩니다.

Cursor의 Lauren Tan은 xAI GrokBot 워크숍에서 이 문제를 꽤 실무적으로 정리합니다. 핵심은 에이전트를 더 똑똑하게 쓰는 요령이 아니라, 평가(Evals)·엔지니어링 스킬·에이전트 친화 아키텍처로 신뢰를 설계하는 일입니다. 아래는 그 내용을 해커톤·바이브코딩 참가자도 바로 적용할 수 있게 다시 묶은 글입니다.

원 영상은 채널 Tech Bridge의 「[한영자막] Cursor 핵심 개발자 Lauren Tan: AI 에이전트를 실전에서 제대로 신뢰하는 법 (xAI GrokBot 워크숍)」(약 60분)입니다.

신뢰가 없으면 병렬화도 멈춥니다

Tan은 에이전트 활용의 중심 질문을 어떻게 에이전트를 신뢰할 수 있을까에 둡니다. 이 지점이 중요한 이유는 단순합니다. 믿기지 않으면 사람은 출력을 일일이 감시하게 되고, 그 순간 에이전트는 속도를 높이는 도구가 아니라 확인할 일이 늘어나는 대상이 됩니다.

에이전트 하나도 못 믿는 상태에서는 수십 개를 동시에 돌리는 그림이 성립하기 어렵습니다. 반대로 검증과 가드레일이 갖춰지면, 사람이 모든 diff를 읽지 않아도 되는 범위가 생기고, 그 안에서 에이전트가 더 많은 일을 맡을 수 있습니다.

사람이 모든 diff를 읽지 않아도 되게, 검증과 규칙을 시스템에 심는 것이 목표입니다.

신뢰를 만드는 세 가지 축

Tan이 제시하는 신뢰의 기반은 크게 세 가지입니다. 각각이 따로 노는 것이 아니라, 함께 맞물릴 때 효과가 납니다.

Evals: 에이전트용 단위 테스트에 가까운 장치

Evals(평가)는 에이전트가 기대한 방식으로 일하는지 확인하는 장치입니다. 특별한 프레임워크가 꼭 있어야 하는 것은 아니고, 팀이 원하는 엄밀도에 맞춰 직접 만들 수 있다고 설명합니다. Pstack에는 eval playbook이 기본으로 배포된다는 언급도 나옵니다.

소프트웨어 엔지니어링 스킬: 특히 검증 능력

두 번째는 소프트웨어 엔지니어링 스킬입니다. 여기서 특히 강조되는 것은 검증입니다. 에이전트가 코드를 작성하는 데서 멈추지 않고, 직접 실행하고 확인할 수 있어야 한다는 뜻입니다. CPU 트레이스, 힙 스냅샷, 시뮬레이터 같은 수단을 통해 스스로 결과를 점검하게 만들면 사람이 중간에서 스크린샷을 붙여 넣으며 안 된다고만 말하는 루프를 줄일 수 있습니다.

에이전트 친화적 아키텍처: 실수하기 어려운 구조

세 번째는 에이전트 친화적 아키텍처입니다. 에이전트가 자주 실수하는 패턴을 구조적으로 막고, 어디까지가 안전한 경계인지 분명하게 만드는 방식입니다. GrokBot 쪽에서는 Dune이라는 아키텍처 코드명과 함께, 엄격한 CI로 금지 패턴을 강제하는 예시가 소개됩니다.

Evals, 검증 스킬, 아키텍처는 에이전트를 더 많이 쓰기 위한 장식이 아니라, 믿고 맡기기 위한 기반입니다.

Pstack: 프롬프트가 아니라 절차를 스킬로 옮기는 방식

Pstack은 Tan의 닉네임 Potato에서 온 스킬 프레임워크로 소개됩니다. 여기서 중요한 점은 한 번 잘 시키는 프롬프트가 아니라, 문제 정의·구현·검증의 절차를 스킬로 인코딩하는 데 있습니다.

이렇게 검증 스킬을 만들고 유지하면 실행 환경이 달라도 흐름을 이어갈 수 있습니다. UI, Electron, 웹, iOS처럼 환경이 달라져도 CDP나 시뮬레이터 같은 수단으로 확인 절차를 계속 수행할 수 있다는 설명입니다.

또 하나 눈에 띄는 대목은 남이 만든 스킬을 그대로 믿지 말라는 점입니다. 팀마다 기준과 취향, 판단이 다르기 때문에 반복되는 기준은 스킬과 eval로 옮기되, 자기 팀 방식에 맞게 고쳐 써야 한다고 강조합니다.

취향과 판단은 남더라도, 반복되는 기준은 스킬과 eval로 옮기는 것이 좋습니다.

PR에서 반복할 말을 린트와 CI로 바꾸기

Tan의 메시지 가운데 실무적으로 가장 바로 적용하기 쉬운 부분은 여기입니다. 잘못된 패턴을 PR 댓글로만 계속 지적하면, 에이전트는 다음에도 같은 실수를 반복할 수 있습니다. 그래서 질문이 바뀝니다. 이 문제를 린트 규칙이나 CI 실패, 혹은 아예 불가능하게 만드는 구조로 바꿀 수 있는가입니다.

예시로는 React의 useEffect를 CI에서 금지해 허술한 패턴이 제출되지 못하게 막는 방식이 나옵니다. 중요한 것은 리뷰어의 기억이나 성향에 기대지 않고, 기계적으로 일관되게 적용되는 규칙으로 옮기는 일입니다.

리뷰어가 반복해서 남기는 잔소리는, 가능한 것부터 린트와 CI로 옮겨야 합니다.

Electron 렌더러 병목이 보여준 아키텍처의 중요성

Cursor 쪽 사례로는 Electron의 렌더러 스레드와 메인 스레드 격리가 충분히 단단하지 않을 때 생기는 문제가 언급됩니다. UI 프레임은 초당 60프레임 기준 약 16ms 안에서 돌아가야 하는데, 무거운 연산이나 IO가 같은 자원을 두고 경쟁하면 버벅임이 생길 수 있다는 설명입니다.

이 사례가 시사하는 바는 분명합니다. 에이전트가 코드를 빠르게 많이 만들어낼수록, 어디에 무엇을 두어도 되는지 미리 정해 두지 않으면 성능과 신뢰가 함께 흔들릴 수 있습니다. 결국 아키텍처와 CI는 코드 품질만이 아니라 에이전트 활용의 상한선을 정하는 장치가 됩니다.

오늘 바로 옮겨볼 수 있는 체크포인트

이 워크숍 내용을 해커톤이나 바이브코딩 팀의 언어로 바꾸면, 시작점은 거창하지 않습니다. 먼저 에이전트 출력에서 반복해서 고친 실수를 떠올려 보면 됩니다. 그리고 그중 일부라도 린트나 CI 실패로 바꿀 수 있는지 살펴보는 것이 좋습니다.

다음으로는 실행해서 확인하는 검증 스킬, 혹은 최소한의 체크리스트 하나를 만드는 방식이 유효합니다. 사람이 스크린샷만 붙이며 다시 설명하는 루프를 줄이는 것이 핵심입니다. 에이전트 수를 늘리는 일은 그다음입니다. Tan의 메시지대로 병렬화는 출발점이 아니라, 신뢰가 쌓인 뒤 따라오는 보상에 가깝습니다.

정리

에이전트를 믿는다는 말은 맹신과 다릅니다. Evals, 검증 스킬, 엄격한 CI, 에이전트 친화 구조를 통해 실수를 더 싸게 만들고, 사람이 매번 같은 확인을 반복하지 않게 만드는 일에 가깝습니다.

Tech Bridge에 올라온 Lauren Tan 워크숍은 이 순서를 해커톤과 바이브코딩의 맥락으로 옮겨 보기 좋은 실전 강의로 읽힙니다.

참고 자료

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

여러분 팀에서는 에이전트가 반복해서 틀리는 패턴을 어떤 방식으로 규칙이나 검증으로 옮기고 있는지 궁금합니다.