Poteto 대화록

안녕하세요, 저는 Lauren Tan이고 Cursor에 온 지 한 다섯 달 됐습니다. 그런데 제가 하나 느낀 게 있는데, 꽤 흥미로운데, 매니지먼트 스킬이랑 에이전트를 다루는 방식이랑 겹치는 지점이 정말 많아요. 오늘 여러분하고 이야기하고 싶었던 큰 부분도 그게 맞고요. 네, 그게 저입니다.

네, 에이전트로 코드를 짜면서 제게 가장 큰 테마는, 여기 계신 분들도 비슷한 경험을 하셨을 텐데, 어떻게 믿느냐는 거예요. 특히 아주 오랫동안 코드를 짜온 엔지니어라면, 좋은 엔지니어링에 대한 의견과 교훈이 많잖아요.

그런데 에이전트가 그냥 대충 하고, 추측하고, 환각하고, 백 번째인데도 자신 있게 스모킹 건을 찾았다고 하는데 실제 문제는 아닌 걸 보면, 신뢰가 많이 깨져요. 에이전트를 못 믿으면 진짜 제대로 못 써먹는 것 같아요. 저한테는 그게 매니지먼트랑 똑같아요.

제가 엔지니어링 매니저이고 팀에 엔지니어들이 있는데 그들을 못 믿으면, 그때 제가 하는 운영 방식은 마이크로매니지먼트가 되겠죠. 팀원들 어깨 너머로 계속 들여다보고, 일을 잘하고 있는지, 프로덕션에 버그를 안 넣고 있는지 확인하는 데 시간을 많이 쓰게 되고요.

그래서 이 차트를 그렸어요. 과학적인 차트는 아니지만, 제가 에이전트를 쓰면서 걸어온 여정을 이렇게 상상하는 거예요. 한 1년 전쯤, 아직 에이전트로 코딩하는 사람이 거의 없던 때로 빠르게 되감아 보면, 한 명 또는 몇 명의 에이전트랑 루프 안에 아주 깊게 들어가게 되거든요.

그리고 에이전트가 뭘 하는지 계속 이해하려고 하게 돼요. 아주 깊게 루프 안에 있는 거죠. 출력마다 다 보고, 앉아서 프롬프트를 넣고. 그 이상으로 병렬화도 못 해요. 신뢰가 없으니까. 에이전트 하나 출력도 못 믿는데 백 개를 띄울 수는 없잖아요.

지난 다섯 달 동안 저는 이 신뢰 곡선을 꽤 올라온 것 같아요. 지금은, 말하기가 좀 무섭고 슬롭 아티스트처럼 들릴 수도 있는데, 약속하건대 그건 아니에요. 에이전트가 이제 PR을 자동 머지해 줘요. 되게 미친 소리죠. 오늘 아침에 일어났더니 PR이 스무 개 정도 랜딩돼 있었고, 저는 이미 메인에 올라간 걸 리뷰했는데, 괜찮았어요.

그래서 어떻게 거기까지 갔느냐, 그게 오늘 이야기하고 싶었던 거예요.

그리고 다시, 네, Denis, 질문 있으면 언제든 끼어드세요.

아, 맞다, 이 차트도 보여줘야죠.

아니, 믿지 마세요, 누가 제 컴퓨터 제어를 요청했는데 그건 안 할 것 같아요.

네, 이 차트를 보여주는 건 자랑하려고가 아니라 여정을 보여주려고예요. 곡선이 Cursor에서 제가 랜딩한 기여랑 거의 반대로 맞춰지거든요. 다섯 달 전에 입사했고, 첫 달은 코드베이스를 배우는 중이어서 생산성이 별로였어요. 뭐가 어떻게 돌아가는지 전혀 몰랐고요.

에이전트를 더 믿게 되면서 생산성이 확 올랐어요. 지난달에 PR을 천 개 올렸는데, 말도 안 되죠. 이번 달은 아직 12일인데 벌써 거의 800개가 랜딩됐어요. 속도는 확실히 높고, 이 코드가 얼마나 좋은지 질문하실 분들이 많을 거예요. 그 질문은 충분히 타당하다고 생각해요.

하지만 에이전트를 잘 세팅하면 비슷한 수준까지 갈 수 있다고 봐요. 그래서 우리가 그걸 어떻게 하는지 이야기할게요.

저로서는, Denis 경험도 궁금하긴 한데요. 에이전트와 일할 때 도구함에 꼭 있어야 하는 가장 중요한 스킬은 검증이에요. 검증이라는 건 에이전트가 실제로 코드를 돌리거나, CPU 트레이스를 찍거나, 힙 스냅샷을 뜨거나, iOS 시뮬레이터를 열거나, 사용자가 앱을 만나는 그 방식 그대로 할 수 있다는 뜻이에요.

똑같이 실제로 돌려보고, 안 되면 테스트하고 검증하는 거죠. 그게 루프를 닫아주는 거예요. 좋은 코드를 쓴다는 보장은 아니지만, 적어도 맞는 코드를 쓰게 해 주고, 에이전트를 믿기 위한 아주 큰 한 걸음이에요. Cursor 안의 예 하나를 보여드릴게요.

앗. 이거 열어볼게요.

전체 화면으로 만들게요. 됐습니다.

Cursor의 Agents Window 이야기인데, 좀 재밌어요. Cursor에 다섯 달 전 들어왔을 때, 원래 다른 팀으로 가기로 돼 있었어요. Cloud Agents 팀이요. 그런데 제가 React를 많이 해왔고 Agents Window가 React 앱이라, Agent Window 일을 도와달라고 하더라고요.

저를 도와줄 스킬이 거의 없었어요. 그래서 그냥, 좋아, Agents Window가 일주일 뒤에 나간다, 마감이 진짜 타이트하다, 그런 상황이었죠.

앉아서 Chrome DevTools 성능 패널을 열고 트레이스를 찍고, 플레임 그래프를 혼자 해석하려고 했어요. 첫 주였다는 걸 기억하세요. 뭘 보고 있는지도 몰랐고, 어느 쪽인지도 몰랐어요. 조금은 알긴 했지만 코드베이스는 완전히 새로웠고, 제 에이전트도 전혀 모르더라고요.

트레이스 스크린샷을 찍고, 트레이스를 받아서 보내면, 에이전트가 음 이쯤 같아 보이는데요, 이러는 거예요. 자신 있게 이거라고 하고, 그걸 고쳐보면, 실제 문제가 아니었어요.

아주아주 느린 과정이었죠. 성능 일을 직접 해보셨거나, 검증 스킬 없이 에이전트랑 개발해 보셨다면, 검증하는 사람이 당신이에요. 당신이 병목이에요. 에이전트에게 시키면 코드를 짜고, 로컬 개발 빌드를 열고, 안 된다고 하고.

그러면 스크린샷이든 콘솔 에러든 복사해서 붙여넣고, 에이전트가 그걸 천천히 이해하고 고치려고 하죠. 그런데 계속 루프 안에 있어서 병목이 되고, 병렬화할 방법이 없어요. 그래서 Control Glass 스킬이 Cursor에서 제가 만든 첫 스킬 중 하나예요.

Glass는 내부에서 쓰는 Agents Window 코드네임이고, 그냥 Cursor죠.

이 스킬 자체 코드는 별로 안 흥미로워요. 에이전트가 쉽게 만들어 줄 수 있어요. Electron 앱이든 웹 앱이든 iOS든, Chrome DevTools Protocol을 쓰게 가르치거나, Apple에도 시뮬레이터를 돌리고 트레이스를 찍고 프로그램으로 제어하는 유틸이 있어요. 그건 정말 유용하고요.

그런데 제가 이야기하고 싶은 건 이거예요.

README가 어디 있지? 이 스킬에는 아주 독특한 기능이, 기능이 아니라 독특한 파일이 있는데, feature map이에요. 스토리는, 이 스킬을 만들어서 이제 에이전트가 에이전트 윈도우를 실제로 돌리고 트레이스를 찍을 수 있게 됐다는 거예요.

그런데 에이전트 윈도우가 뭔지는 전혀 몰랐어요.

누가 왼쪽 사이드바가 버벅인다, 오른쪽 PR 탭이 안 된다, 이러면 에이전트가 허둥대는 거죠. 코드를 찾아보고, 이 기능이 어디 있지, UI에서 어떻게 가지, 시간을 많이 쓰는데, 사실상 쓸모가 없었어요. 로컬에서 이 스킬을 돌리면

개발 빌드를 띄우긴 하는데, 그냥 뺑뺑이만 도는 거예요. 여기를 클릭해 보고, 어떻게 가는지 모르고, 경험이 최악이었어요.

누가 제 화면에 화살표를 그리고 있는 거죠?

그래서 이 feature map이 정말 유용했어요. 에이전트에게 기능에 어떻게 가는지 가르치거든요. 제가 만든 플러그인 pstack에서, 구글에 pstack cursor를 검색하면 나와요. 그 플러그인에 create verification 스킬이 있어요. 이런 걸 직접 세팅하도록 도와주고, feature map도 포함해서, 코드를 탐색하고 초기 feature map을 만들어 줘요.

그게 에이전트에게 여러 기능에 어떻게 가는지 알려주는 거죠. 이게 엄청 강력해요. 들어오는 유저 리포트가 막연해도, 스크린샷이어도 매핑할 수 있거든요. Cursor 내부에도 있어요. Slack 채널에서 사람들이 Agents Window랑 Grokbot 피드백을 많이 주거든요.

그런데 리포트가 자주 나빠요. 품질이 낮아요. 스크린샷만 던지고 물음표 물음표 물음표, 이게 뭐야, 이런 식. 이게 없으면 에이전트는 전혀 몰라요. 이런 feature map이 있으면 어떻게 탐색하고 기능에 가는지에 대한 맥락과 이해가 훨씬 많아져요.

예를 들어 사이드바가 뭔지, 그 안의 하위 기능들, 사용자 관점에서 어떻게 가는지, 키보드 단축키, DOM 요소, CDP로 고를 때 쓰는 속성까지 다 들어 있어요. 그래서 에이전트에게 정말 강력해요.

네, pstack이 꽤 재밌어요. 이름이 좀 바보 같거든요. pstack의 P는 potato, potato snack이에요. Y Combinator CEO인 Gary Tan이라는 유명한 분이 계시고, 그분이 Gstack이라는 플러그인을 만드셨거든요. 공교롭게 성이 같아요. 친척은 아니에요. Gary를 좀 놀리면서 그분 플러그인의 제 버전으로 pstack을 만들면 재밌겠다 싶었어요.

제 엔지니어링 실천에 맞게 다듬은 거죠.

솔직히 pstack을 만들려고 시작한 건 아니었어요. 스킬 몇 개에서 시작된 거예요. Control Glass 스킬로 시작했고, Howl이라는 스킬도 에이전트를 관찰하면서 만들었어요. 이 사다리를 오르던 초기에 저는 루프 안에 너무 깊이 있었고, 에이전트를 극단적으로 쪼고 있었어요. 이 기능이 멈췄어, 버그 리포트야, 왜 안 돼, 이렇게 말했죠.

그러면 에이전트가 자주 자신 있게, 아 이거일 거야, 이거야, 하는 거예요. 실제 툴 콜을 보니 영향받을 코드를 읽고 있지가 않더라고요. 그때부터 극도로 의심스러웠고, 이 에이전트는 더 이상 못 믿겠다, 완전 환각이구나, 싶었어요. 그런 불신이 쌓이고 무기력해지기 쉬워요. 에이전트가 성공하도록 어떻게 도와야 할지 모르겠는 거죠. 그런데 다시, 매니지먼트 비유가 진짜 도움이 돼요. 엔지니어링 팀 매니저인데, 코딩은 잘하는데 비즈니스 맥락은 전혀 없는 사람을 방금, 5초 전에 온보딩했다고 생각해 보세요. 그 사람을 어떻게 효과적으로 가르치겠어요?

그게 스킬이에요. 스킬은 그냥 마크다운이잖아요. 그런데 정보와 지시가 많이 들어가고, 에이전트에서 지능을 많이 끌어낼 수 있어요. 트위터에서는 에이전트를 다른 잠재 공간으로 끌어당긴다고들 하는데, 있어 보이게 말하는 거고, LLM이 다음 토큰을 예측하니까

처음에 고품질 토큰을 주면, 더 똑똑한 쪽 공간에서 패턴 매칭을 할 수 있는 거죠.

네, eval은 기본적으로 스킬을 유닛 테스트하는 방법이에요. pstack에서는 Potato mode 아래에 Eval Playbook이라는 플레이북이 있어요. 검색하면 나와요. 꽤 엄격하게 되어 있어요. 제가 하는 건, 서브에이전트를 많이 띄우고, 메인 코디네이터 에이전트가 스킬이 하길 원하는 것에 대한 루브릭을 만들고, 서브에이전트를 띄워서 각자 디렉터리를 만드는 거예요. 이름을 교묘하게 지어서 서브에이전트가 평가받는 줄 모르게 해요. 에이전트는 알아채면 행동을 바꾸거든요.

그런 식으로, 제가 만들거나 바꾸는 스킬이 제가 생각하는 대로 도는지 테스트해요. Cursor의 좋은 점 하나는 모델을 정말 많이 지원해서, 스킬을 여러 모델에 걸쳐 eval하고, 특히 쓰는 모델에서 얼마나 잘하는지 감을 잡을 수 있다는 거예요.

저는 이걸 자주 해요. 스킬을 수정할 때마다 Eval Playbook 같은 걸 돌려서 원하는 결과로 가는지 확인해요. 그런데 말하자면,

스킬 유지는 사실 꽤 어려워요. 취향과 관찰이 많이 필요해요. 백시트 드라이버를 잘해야 해요. 페어 프로그래밍을 해보셨으면, 동료가 코딩하는 걸 보면서 저라면 더 잘할 텐데, 왜 이렇게 안 했지, 질문을 많이 하잖아요. 여기도 비슷해요. 에이전트를 수동적으로만 보면 안 돼요.

자기 스킬 세트를 쌓는 초기에는 운전석에 있어야 해요. pstack 같은 걸 써도 되지만, 자기 스킬을 만든다면 툴 콜을 다 열고 코드를 읽고 에이전트 행동과 thinking 블록을 읽는 게, 어디서 실패하는지 보는 정말 좋은 방법이에요.

어디서 헤매는지 보고 그걸 스킬로 만드는 거죠. 검증을 어떻게 믿느냐도 비슷한 반복 루프예요. 검증 스킬 자체를 검증할 때도 같은 과정을 썼어요. eval의 재미있는 점은 힐클라임할 수 있다는 거예요. eval이 점수를 내잖아요.

코디네이터가 점수를 내게 할 수도 있고, 다른 모델의 judge 에이전트를 둬서 교차 확인하고 첫 모델이 편향되지 않았는지 볼 수도 있어요. 서브에이전트들을 채점하는 그 모델이요.

힐클라임은 Cursor에서 slash loop를 써서, 이 eval을 10점 만점이 될 때까지 계속 돌려, 이런 식이에요. Control 스킬도 거의 같은 방식으로 했어요. 꽤 손을 떼고 했죠. CLI를 그 스킬 안에서 그렇게 만들었고, 시간이 지나면서 정말 좋아졌어요. 처음엔 전혀 순탄하지 않았고 반복이 많이 필요했어요. 제게 비유가 하나 있는데, 나중에 그림의 다른 슬라이드에서 할게요.

지금은 엔지니어로서 좀 매니저에 가깝다고 봐요. 제가 좋아하는 비유는 식당의 셰프예요. 헤드 셰프. 음식을 다 직접 안 만들어요. 쿡 팀이 있고, 라인 쿡이 있고, 수셰프가 있고, 스테이션이 여러 개죠.

제 일은 환경을 설계하는 거예요. 주방을 세팅하고, 사람들에게 일을 나눠 주는 거죠.

한 겹만 더 들어가 볼게요. 뭔가에 대한 eval이나 스킬을 만들고, 말씀하신 것처럼 알아서 나아지게 하고 싶다면요.

시작은 로컬이 제일 좋아요. 관찰할 수 있으니까. 에이전트가 뭘 하는지 확실히 볼 수 있어요. 검증 스킬을 직접 만든다면 로컬에서 시작하고, 에이전트가 앱을 띄우게 하세요. CLI든 데스크톱 앱이든. 그러면 에이전트가 앱과 어떻게 상호작용하는지 볼 수 있어요.

앱과 상호작용하는 API를 어떻게 호출하는지도요.

저 개인적으로는 클라우드 에이전트에 거의 올인했어요. 엄청 강력하거든요. Cursor의 진짜 강력한 점이 클라우드 에이전트예요. 환경을 조금 세팅하고 이 컨트롤 스킬, 검증 스킬을 두면 효과가 커요. 엔지니어 한 명을 좋게 만드는 게 아니라 팀 전체, 회사 전체를 끌어올리거든요. 클라우드 에이전트로 자동화를 생각하게 돼요. 나중에 더 이야기하겠지만 잠깐 말하면, Benny라는 에이전트가 있어요. 들어오는 버그 리포트를 다 받아서 클라우드로 가서, 자기 데스크톱을 열고, 자기 컴퓨터에서 Cursor를 돌리고, 같은 컨트롤 스킬로 앱을 만지면서 버그나 유저 리포트를 재현하려고 해요.

이게 너무 강력해요. 한 번에 정보가 자동으로 엄청 들어와요. 이 예에서는 Benny가 버그를 재현했는데, 이미 메인에서 고쳐져 있어요. 문제는 이미 고쳤고, Cursor 빌드만 하나 더 내면 된다는 확인인 거죠.

에이전트랑 한 시간 앉아서 고쳐졌나 안 고쳐졌나 볼 필요가 없는, 큰 정보예요. 시간을 많이 되찾게 되고, 팀 모두가, 회사 모두가 이득을 봐요.

클라우드 에이전트를 쓰는 건 정말 강력하다고 생각해요. 그런데 여정이에요. 이 지점까지 오려면 먼저 믿어야 해요. 여기서 말한 걸로 돌아가면, 정말 어렵고, 거의 불가능에 가깝고요.

네. 지금까지를 정리하면, 로렌이 걸어온 여정을 가려면 검증부터 시작하고, 스킬을 만들고, 에이전트가 적어도

맞는 코드를 내는지 보는 방법을 만드는 거죠. 좋은 코드인지는 별개 질문일 수 있고, 스택 트레이스를 보고 앱의 실제 동작을 보고 기술적으로 문제를 푸는 거고요.

네, 정확해요. 그래서 이 곡선을 그린 거예요. 제가 시작했을 때 에이전트 몇 개도 겨우 쓰고 전부 관찰하던 여정이거든요. 여기서 저기로 가는 지름길은 없다고 봐요. 에이전트에 대한 개인적 신뢰 수준이니까요. 엔지니어로서 프로덕션에 슬롭을 넣고 싶진 않잖아요.

그 신뢰를 어떻게 쌓느냐. 취향과 판단이 많이 필요해요.

pstack 같은 플러그인이 속도를 훨씬 빨리 올려줄 수는 있어요. 저를 믿고 pstack을 믿으면, 연장선에서 에이전트도 믿을 수 있을지도 모르죠. 저를 안 믿으면, 맹목적으로 믿으라고는 절대 안 하고요.

자기 스킬 세트를 쌓으면서 pstack을 보고 포크하고 자기 것으로 만들고 스킬을 개선하는 건 정말 권해요. 저한테는 결국 늘 신뢰로 돌아와요. 이 채팅에 계신 분들마다 엔지니어링 기준이 다르고, 코드베이스에서 중요한 것도 달라요. 그걸 스킬에 인코딩하고 에이전트가 실제로 하는지를 검증할 수 있으면, 이 곡선을 올라갈 수 있어요.

아직 안 한 세 번째가 있는데, 리팩터링과 재작성이에요. 업계에서 제일 논쟁적인 주제 중 하나가, 앱을 다시 짜야 하느냐 아니냐인 것 같아요. 엔지니어들이 특히 회사에 들어가서 코드베이스를 보면, 이거 뭐야, 누가 이 코드를 썼어, 최악이야, 전부 다시 짜고 싶어지거든요.

아주 흔한 충동이에요. 에이전트 이전에도, 지금도, 재작성을 말리는 사람이 많죠. 그런데 저는 왜 고려해 볼 만할 수 있는지 말하고 싶어요.

경우에 따라 달라요. 브라운필드 앱은, 이미 잘 세팅돼 있으면 꽤 괜찮은 자리라고 봐요. 최근에 사람들 이야기도 듣고 관찰하다가 느낀 평행이, 빅테크 회사 문제가 이제 모두의 문제가 됐다는 거예요. Meta에 있을 때 거대한 모노레포가 있었고, 엔지니어가 몇만 명이 키보드를 두드리며 코드를 치고, Meta에도 훌륭한 엔지니어가 많았는데

코드 품질이 그렇게 좋지는 않다는 거에 놀라실 거예요. 그래서 농담으로, AI 슬롭 전에 인간 슬롭이 있었다고 해요. Meta나 Google 같은 빅테크 인프라는 그걸 위해 설계된 면이 있어요. 말하기 좀 그렇지만, 팀에서 가장 약한 엔지니어에 맞춰서요.

프레임워크를 만들고, 컨벤션을 만들고, 가드레일을 만들고, 인턴이 프로덕션 DB를 날리지 못하게 자격 증명을 제한하죠.

그 수준의 인프라가 이미 있으면, 에이전트도 이미 꽤 잘할 수 있다고 봐요. 난리를 안 피우거나 너무 큰 난리를 안 피우게 가드레일이 이미 있으니까. 가드레일은 더 넣을 수도 있고요.

그린필드, 완전 새 앱이 제 생각엔 제일 큰 리스크이자 제일 큰 기회예요. 프로젝트를, 프로토타입을 바이브 코딩하면, Grokbot이 그랬거든요. Grokbot은 아주아주 빨리 띄웠어요. Grokbot을 모르시면, 어제 막 런칭한 새 앱이에요. 정말 멋져요.

각자 정체성을 가진 개별 에이전트를 만들고 오케스트레이션할 수 있어요. 진짜 멋지니 꼭 보세요.

대부분의 프로토타입처럼 아주 그린필드였어요. 바이브 코딩을 아주 빨리 했고, 사람은 코드를 전혀 안 읽었어요. 최근에 오가닉 아키텍처에 대한 트윗을 했었어요.

찾아볼게요. 아이디어는, 완전히 바이브 코딩된 앱에는 가드레일이 전혀 없다는 거예요. 그래서 에이전트는

일을 주면 제일 편한 방법으로만 풀고, 시간이 지나면 코드베이스가 통제를 벗어나 버려요. 당신은 이해를 못하고, 에이전트는 어떤 식으로는 이해하지만, 지름길에 최적화된 걸 만들어 놔서, 그 앱에서 고생을 많이 하게 돼요.

그래서 코드베이스를 아주 강한 제약으로 시작하는 게 필요하다고 봐요. 믿을 수 있는 코드베이스, 에이전트가 좋은 코드를 쓰도록 돕는 가드레일이 있으면, 오늘 아침에 일어나니 에이전트가 PR 스무 개를 머지해 둔 그 곡선 구간으로 갈 수 있어요. 어제 계산해 보니 600개 넘는 PR에 시간을 썼거든요.

Grokbot 전체를 제가 만들고 있는 이 새 아키텍처로 리팩터링할 때요.

지금은 코드를 거의 안 봐요. 정말 안 봐요. 토큰을 팔려고 하는 말이 아니라, 거기까지 가는 데 일이 많았고 토큰을 많이 써서, 더 이상 안 봐도 되는 코드베이스가 된 거예요. 그게 저만의 이득이 아니라 Grokbot에 기여하는 모두, 디자이너, PM, GTM까지 기능을 넣어도, 새벽에 누가 perf 리그레션을 머지했나 걱정 안 해도 되니까 신나요. 제약과 CI가 잔뜩 있어서 Grokbot에서 코드 짜는 건 사람한테는 진짜 짜증나지만, 그 짜증을 에이전트가 다 흡수해요.

경우에 따라 다른 것 같아요.

이 정도는 괜찮아요. 그런데, 별로 안 흥미로운데 재밌는 팩트는 Grokbot이랑 Cursor의 시각화가 Preact로 돌아간다는 거예요. 누가 만든 비교적 새 라이브러리예요. 흥미로우니 보세요. 중요한 건 아니고요. 평균 PR 크기는 사실 잘 모르겠어요. 이걸 클릭하고 싶진 않고.

하드캡은 확실히 없어요. 다만 에이전트에게 일을 여러 PR로 쪼개라고 권해요. 에이전트 세상에 커밋이 너무 많아서 이제는 더 어렵긴 한데, git 히스토리가 아주 풍부한 컨텍스트 소스라는 아이디어를 좋아하고, 각 PR이

그 작은 조각이 하는 일을 원자적으로 기술하면, 되돌리기도 쉽고, 버그를 넣었을 때 여기다, 뭐가 들어갔는지 모르는 4만 줄 PR 안이 아니다, 를 알 수 있거든요.

네, Grokbot 한정으로요. Dune이 Grokbot용으로 만든 아키텍처의 장난스러운 코드네임이에요. CI는 꽤 짜증나게 보여요. 전부 체크하거든요. React를 써보셨으면 useEffect가 제일 큰 풋건 중 하나라는 걸 아실 거예요. Dune이랑 Grokbot에서는 useEffect를 금지했어요.

Dune의 멘탈 모델은 Electron 앱용 Next.js 같고, 에이전트가 쓰도록 설계됐고, 우리 에이전트 파워드 앱에 맞춰져 있어요. CI 체크도 거기에 특화돼 있어요. useEffect 쓰지 마, 금지야, CI가 실패하고 소리를 지르죠. 눈썹이 올라갈 만한 것 중 하나는 코드 주석도 금지한 거예요. 흥미로운데, 99%의 경우 에이전트가 코드랑 전혀 상관없는 역사적 이야기를 주석으로 쓰거든요. Lauren이 이건 절대 하지 말랬어, 가 코드 주석에 들어가 있어요. 뭐야, 왜, 그건 지속되는 글로벌 규칙으로 말한 게 아니라 이 PR이 별로니까 그 부분을 고치라는 거였거든요. 에이전트는 의외로 우리를 잘 이해를 못하고, 너무 많이 가정하고 바보 같은 방식으로 해요. 그래서 에이전트가 못하는 건 상상할 수 있는 전부 금지해요. Agents Window에서 많이 고생하는 예가, Agents Window를 써보셨으면 성능 이슈를 보셨을 거예요. 계속 고치는데 끝나지 않아요.

PR이 너무 많이 머지되어서 어느 하나라도 성능이나 안정성이나 신뢰성을 리그레스할 수 있거든요. Agents Window에는 이 아키텍처가 아직 없어요. 이 배움을 가져가서 거기도 리팩터링할 계획이에요.

리그레스가 너무 자주 나요. 한 예가 프로세스 격리가 아주 약하다는 거예요. Electron에서는 UI를 그리는 렌더러 스레드가 있고, 렌더러를 막을 필요 없는 코드를 돌리는 메인 스레드가 있는데, 분리를 잘못해서 코드가 실수로 렌더러 스레드에서 돌아가게 되는 일이 자주 있어요.

그러면 갑자기 렌더러랑 경쟁하게 돼요. 60 FPS를 원하면 매 프레임이 16밀리초 안에 그려져야 해요. 프레임 데드라인이 아주 작아요. 부드러운 제품을 원하면요. 계산이 무겁거나 I/O가 많은 걸 실수로 끌어들이면 젠크가 많이 생겨요.

FPS가 떨어지고, 프레임을 잃고, 16밀리초가 넘는 롱 태스크가 나오고, 끊기는 경험이 되죠. Electron 앱을 만들며 배운 그 패턴들을 이 프레임워크에 넣었고, 하드 실패가 돼요.

Grokbot에는 말 그대로 electron-main, electron-renderer 디렉터리가 있고, import CI로 의존성 그래프를 검사해서 한 디렉터리 코드가 다른 쪽으로 실수로 import되지 않게 해요. CI가 강제하고, Cursor의 코드 리뷰 툴인 Bugbot도 CI에서 돌아가요. AGENTS.md에도 여기저기 있어요.

좋은 코드베이스를 만드는 레이어가 여러 개라고 생각해요. 코드베이스 자체가 하나인데, 이렇게 극도로 엄격하고 기능 만드는 법이 아주 컨벤셔널하면, 그게 제일 강한 강제예요. 에이전트는 기존 패턴을 복사하는 걸 좋아하거든요.

Grokbot 예로, feature라는 개념이 있고 entry point가 있고 transcript card가 있어요. 채팅에 보이는 카드요. 프레임워크 안의 명사들이죠. 만드는 법이 아주 정해져 있고, feature는 예로 디렉터리 하나에 다 들어가요.

그 feature에 기여하는 코드가 한 디렉터리에 같이 있어서 코로케이션되고, 에이전트가 grep으로 어디 있나 찾아다닐 필요가 없어요. 온보딩 feature를 Grokbot에서 작업한다, 이 디렉터리에서 하면 되고, 일의 80%는 거기 캡슐화돼 있어요.

다시, 제일 멍청한 에이전트를 위해 설계된 거예요. 생각할 필요가 없게.

이 프레임워크의 핵심 원칙 하나는, 가장 짧은 길이 가장 좋은 길이다, 예요.

에이전트가 코드를 좋아하는 방식과 정확히 맞거든요. 지름길을 좋아해요. 제일 빠른 방법으로 문제를 풀죠. 그럼 그 빠른 길을 최선의 길로 만들면 되잖아요. 세부까지는 안 들어가겠습니다.

이 프레임워크는 오픈소스할 무엇이라기보다 아이디어와 원칙의 모음에 가까워요. 원하시면 스크린샷 찍어서 에이전트에게 비슷한 걸 만들어 달라고 하셔도 돼요.

네, 결국 레이어예요. 코드베이스가 한 부분이고, feature와 디렉터리, import되면 안 되는 의존성을 막는 것, 그걸 전부 강제하고 정적 분석. CI 체크, 관찰한 나쁜 패턴에 대한 린트, 컴파일러 진단이요.

규칙이랑 Bugbot은 한 3, 4, 5처럼 더 소프트하고, 이쪽 둘은 CI를 빨갛게 만들어요. 에이전트가 쓰레기 코드를 못 쓰게 하는 하드 제약이죠. 규칙이랑 스킬이랑 Bugbot은 에이전트가 잊을 수 있어요. 항상 일관되게 적용하지 않을 수도 있고. 그래서 겹겹이 쌓되, 강제 수단을 그것만 믿지는 않아요. 너무 소프트하거든요.

규칙과 Bugbot과 스킬과 스타일 가이드만 있으면, 코드베이스가 완전 쓰레기가 되는 건 시간문제예요. 미안하지만 그래요.

하드하게 강제할 수 있는 것에 투자하라고 권해요. 그래서 기술 스택 선택도 중요해요. Rust가 다시 뜨는 이유도 컴파일러가 너무 엄격해서예요. 지켜야 할 게 많고, 빌림 검사기를 달래야 하죠. 에이전트가 unsafe 블록만 안 쓰게 하면, 컴파일되면 아마 동작하고 괜찮을 거라는 자신감이 어느 정도 생겨요.

그게 인간 엔지니어가 직접 안 봐도 되는 신뢰와 자신감을 줘요. 코드와 정적 분석에 기대서 훨씬 수월해지는 거죠.

최악은 코드 리뷰 땅에 갇히는 거예요. 코드베이스의 제약과 불변식을, 사람이 코드를 읽고 이건 하지 마, 라고 강제하는 거죠. 그럴 때마다 코드 스멜, 안티패턴으로 보세요.

PR에 코멘트하는 대신, 이걸 어떻게 하드 규칙으로 만들지? 린트 규칙으로? CI 실패로? 아니면 이 문제 자체를 아예 없앨 수는 없나?

네. 솔직히 지금 말씀하신 게 저예요. 이런 규칙이 다 없거든요. 이 세션 끝나고 할 일이 생겼어요. 에이전트 스케일 면에서 저는 로컬에서 병렬로 두세 개 정도, 그 단계예요. 여기 계신 대부분도 그럴 것 같아요. 몇 분 남았는데, Lauren, 더 짚고 싶은 게 있으세요?

정말 좋은 포인트예요. 저는 AI 랩에서 일하고 토큰이 무제한이니까, 모두가 저랑 똑같이 해야 한다고는 절대 못 해요. 은행을 털지 않고도 여기까지 갈 수는 있다고 봐요.

엔지니어링 리더이거나 스타트업을 이끄신다면, 저한테는 ROI 질문이에요. 앞단계에서 토큰에 돈을 많이 쓰죠. 코드베이스 리팩터링도 토큰이 많이 들고, 이런 걸 넣는 데도 토큰이 들어요. 그런데 에이전트가 코드를 다 짜는 세상으로 가면, 린하게 가고 싶잖아요. 사람을 많이 뽑고 싶지 않고, Meta처럼 되고 싶지 않고, 엔지니어링 조직 만 명 되고 싶지 않은 거죠. 멋진 고민이긴 하지만 오버헤드가 너무 커요. 플래닝도 있고, 저 개인적으로는 별로 안 재미있고요. 아주 기민하게 있고 싶어요. 에이전트의 가치는 예전엔 못 하던 일을 하게 해 주는 거라고 봐요. 사소한 것마다 토큰을 쓰는 게 아니라요. 저한테 예전엔 못 하던 일은, 이 수준의 제약을 코드베이스에 혼자 강제하는 거였어요. 저 한 명이거든요. 이 프레임워크를 만들고 리팩터링하고 직접 테스트하고 검증하려면 몇 년이 걸렸을 거예요. 에이전트 이전 시대에 저 혼자였다면 너무 오래 걸렸겠죠. 제 연봉도 꽤 높고요.

엔지니어링 리더의 질문은, 사람을 뽑을 것인가, 아니면 제일 순진한, 제일 멍청한 에이전트도 잘하게 코드베이스를 세팅하는 데 토큰을 쓸 것인가, 그 트레이드오프예요. 이 지점에 오면, 페이블 사이즈가 아닌 에이전트도 코드를 아주 잘 짜고, 저한테도 배당이 커요. 저만이 아니라 PM, 디자이너,

Grokbot을 잘 모르는 엔지니어까지 지속 가능하게 기여하게 됐어요. 확실히 트레이드오프고, 공짜는 없고, 토큰은 비싸요. 아, 오늘 Grok 4.6을 발표했어요. 드디어 나와서 정말 신나요. Grok 4.6은 아주 똑똑하고 벤치마크도 좋고, 토큰은, 잘못 말하면 안 되는데, 토큰당 비용이 4.5와 같다고 알고 있어요.

같은 비용으로 지능을 더 얻는 거죠. Cursor와 SpaceXAI가 정말 최적화하려는 영역이, 비용 대 지능의 파레토 프론티어예요. 제일 큰 모델을 만들 필요는 없어요. 돌리는 데 너무 비싸거든요. 스위트 스팟을 찾는 거죠. 거대 모델이 아니어도 아주 똑똑하고, 추론은 비싸지 않게.

여기서 Grokbot이 정말 강력했어요. Grokbot 전에는 Cursor만 있었죠. Agents Window, CLI, IDE. 파워 유저 툴이고 개발자용이라 아주 개발자 중심이에요. 지식 노동도 할 수는 있는데 UI가 거기에 최적화돼 있진 않아요. GTM이나 프로덕트가 Cursor로 일하긴 했을 텐데, 즐거운 경험은 아니었을 거예요. 지금은 Grokbot으로,

테크에 없는 사람들에게 Cursor 모멘트가 된 것 같아요. 아주 편하고 익숙한 인터페이스로 에이전트를 쓰는, 아주 접근성 있는 방식이에요. iMessage처럼 생겼고, 재미있기도 해요. 에이전트에 재미있는 이름을 줄 수 있고요.

오케스트레이션도 아주 자연스럽게 해요. 각 에이전트가 사람 같고, 에이전트 팀이 일하게 되고, 예로 관리하는 계정마다 에이전트 하나. PM이면 Lauren이 어젯밤 한 일을 요약하는 에이전트를 둘 수 있어서, 제가 뭘 했는지 알게 되죠. PM들이 그걸 많이 쓰고, 코드도 찍어요.

자주, 여기 버그야, 내가 고쳤어, 봐줄래, 하면 리뷰해 보면 진짜 완벽해요.

스탬프 찍으면 되는 거죠. Dune 아키텍처가 버티고 있다는 뜻이에요. 아주 빡센 제약 덕분에 엔지니어링 전문가가 아닌 사람도 높은 수준으로 기여할 수 있어요. 디자이너와 PM이 기능을 바로 찍는 걸 이미 많이 보고 있고, 그래서 Grokbot 팀이 엄청 빨라요. 이렇게 빨리 찍을 수 있으니까.

멋져요. 시간이 다 됐네요. Lauren을 응원하려면 Grokbot 써 보시고, 4.6도 써 보시고, 피드백 주시면 좋겠어요. 정말 좋았어요. 시간 내주셔서 감사합니다. 채팅 메시지도, 좋은 질문도 많았어요. 다 못 다뤘고, 처음에 말한 대로 소화할 수 있는 것보다 질문이 훨씬 많았어요. 정말 감사해요. 와 주셔서 감사합니다.