🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Matt Pocock의 에이전틱 엔지니어링 워크플로우는 최신 모델만 좇기보다 하네스, 스킬, 코드베이스 품질, 인간의 전략적 판단을 함께 설계해야 성과가 난다는 주장입니다.

📌 핵심 요점

1. AI 코딩 생산성의 핵심 레버리지는 모델 자체보다 프롬프트, 스킬, 실행 환경, 코드베이스 구조를 포함한 하네스에 있다.
2. AI는 전술적 코딩을 빠르고 싸게 처리하지만, 무엇을 만들지, 어떻게 나눌지, 어떤 기준으로 검증할지는 여전히 사람의 전략적 엔지니어링 역량에 달려 있다.
3. Teach Skill 데모는 바이브 코더가 Git, 디버깅, 테스트, 배포 같은 주변 역량을 실제 프로젝트 목표에 맞춰 배우도록 만드는 개인화 학습 흐름을 보여준다.
4. 좋은 에이전트 스킬은 모델이 자동 호출하는 ability와 사용자가 의도적으로 실행하는 procedure로 나뉘며, 컨텍스트 누수와 통제권을 고려해 설계해야 한다.
5. AFK 에이전트, 샌드박스, GitHub Actions 리뷰, 작업 큐 기반 운영은 사람의 체크포인트를 최종 검토에 가깝게 밀어내며 개발 흐름을 병렬화한다.

🧩 배경과 문제 정의

• AI 코딩 생산성의 차이는 최신 모델을 쓰는지보다, 모델을 둘러싼 하네스·프롬프트·스킬·실행 환경을 얼마나 잘 설계하느냐에서 더 크게 벌어진다.
• 전술적 코딩은 AI가 빠르고 저렴하게 처리할 수 있지만, 코드베이스 구조·인터페이스·테스트·문서화처럼 전략적 프로그래밍 역량은 여전히 사람의 한계를 결정한다.
• 개발자의 도메인 이해와 위임 능력이 AI 활용 성과를 제한하며, 특히 시니어 개발자는 AI를 통해 더 큰 배율 효과를 얻을 수 있다.
• Teach Skill 데모는 바이브 코더가 실제 프로젝트 목표를 기준으로 학습 경로를 만들고, Git·디버깅·테스트·배포처럼 코드 주변 역량을 보완하는 흐름을 보여준다.

🕒 시간순 섹션별 상세정리

1. 모델보다 하네스와 코드베이스 설계가 더 큰 레버리지다

• AI 활용의 핵심은 모델 자체보다 하네스에 있으며, 좋은 프롬프트·작업 스킬·실행 환경이 모델의 잠재력을 실제 결과로 바꾼다 [00:19]
• 사용자가 직접 통제하기 어려운 모델보다 통제 가능한 하네스에 개선 여지가 더 크고, 30~40년간 검증된 코드베이스 설계 원칙도 여전히 유효하다 [00:34]

2. 전술적 코딩은 AI가 가져가고 전략적 프로그래밍이 차이를 만든다

• 전술적 프로그래밍은 문법 처리, 버그 대응, 코드 작성, 커밋 생성 같은 현장 실행에 가깝고, 전략적 프로그래밍은 코드베이스의 방향과 팀의 속도를 설계하는 장기 판단에 가깝다 [00:51]
• AI가 전술적 프로그래밍을 더 싸고 빠르게 처리할수록, 사람에게 남는 핵심 역량은 수많은 전술 프로그래머를 어떻게 지휘하고 배치하느냐가 된다 [01:38]

3. 개인의 실력은 AI 활용의 상한선이 된다

• 최신 구독과 도구는 누구나 쓸 수 있지만, 같은 AI를 써도 어떤 사람은 사업 성장과 출시 속도를 크게 높이고 어떤 사람은 작은 보조 효과에 그친다 [02:52]
• 개발자의 설계 감각, 판단력, 도메인 이해가 깊을수록 AI가 활용할 맥락도 풍부해지며, 코드베이스를 감독하고 원하는 구조를 지시하는 능력이 결과 품질을 끌어올린다 [03:24]

4. 검색 데이터 인프라 문제와 SERP API 활용 사례가 연결된다

• 대규모 웹 검색 데이터 수집은 스크래퍼가 잠시 작동하더라도 레이아웃 변경, CAPTCHA, 프록시 차단, rate limit 때문에 곧 유지보수 부담으로 바뀐다 [04:48]
• SERP API는 Google·Bing·Yahoo 검색 결과를 단일 API 호출과 구조화된 JSON으로 제공해, 깨진 HTML 처리나 프록시 회전 없이 필요한 데이터를 가져오게 한다 [05:07]

5. Teach Skill은 교육 이론을 에이전트 스킬로 바꿔 즉석 커리큘럼을 만든다

• 10년간의 교육 경험과 개발자 교육 경험이 Teach Skill의 기반이 되며, 근접발달영역과 지식·기술·지혜의 구분 같은 교육 개념이 스킬 내부에 반영된다 [05:57]
• Teach Skill은 어떤 주제든 즉석에서 코스를 만들 수 있고, 루빅스 큐브 학습처럼 기억에 기반한 실제 수행 능력을 만드는 데 쓰인다 [06:13]

6. 바이브 코더 학습 흐름은 미션 정렬과 실제 프로젝트로 출발한다

• Teach Skill은 빈 워크스페이스에서 실행되며, 사용자는 기본 CLI와 코드 읽기 정도만 아는 바이브 코더라는 현재 상태와 더 나은 소프트웨어를 만들고 싶다는 목표를 자연어로 입력한다 [07:34]
• 단순히 배우고 싶은 과목을 말하는 대신 미션과 이유를 제시하면, 에이전트는 교사처럼 학습자의 목적에 맞춰 먼저 가르칠 내용을 정렬한다 [08:10]

7. 상태를 기억하는 Teach Skill과 개인화 학습

• Teach Skill은 로컬 정보를 활용하는 상태 있는 스킬이며, 좋은 교사처럼 이전 학습, 현재 위치, 다음 목표, 미션을 기억해야 개인화된 학습 경로를 만들 수 있다 [12:10]
• reference cheat sheet와 첫 lesson을 HTML로 만들면 브라우저에서 rich content를 열 수 있어, terminal-only 학습의 피로를 줄이고 초보 개발자가 실습 흐름을 더 쉽게 따라갈 수 있다 [12:28]

8. 새 모델 채택은 hype보다 실사용 조건이 우선

• Claude Code 운영은 Opus 4.8 medium effort에 머물고, Fable은 아직 채택 대상이 아니며, 새 모델 전환은 기능 향상뿐 아니라 workflow 비용까지 함께 고려한다 [12:45]
• 출시 직후의 one-shot 성공담은 noise가 크고, token cost·availability·latency까지 감안하면 실제 평가가 안정될 때까지 기다리는 편이 손실을 줄인다 [13:03]

9. Git lesson은 HTML, 실습, 퀴즈로 기억을 강화한다

• lesson one은 project undo button을 다루며 HTML의 rich display로 저장되기 때문에, terminal 안에서만 학습하는 방식보다 복습성과 가독성이 높다 [13:43]
• lesson은 folder 생성, Git 초기화, file 생성, status 확인, stage, snapshot 저장 같은 terminal exercises를 직접 요구해 Git 개념을 실제 조작과 연결한다 [14:01]

10. learning record는 지식 그래프를 선형 학습 경로로 바꾼다

• lesson은 Pro Git book 같은 primary source로 넘어갈 선택지를 남기고, follow-up questions와 next lesson 생성으로 학습 흐름을 이어간다 [15:30]
• knowledge는 graph처럼 넓게 퍼져 있지만, Teach Skill은 learner가 배운 내용을 learning record에 남기고 그 기록을 기준으로 linear path를 만든다 [15:42]

11. 좋은 skill은 ability와 procedure로 갈린다

• 좋은 agent skill의 기준은 목적에 따라 달라지며, 크게 사용자가 직접 실행하는 procedure와 model이 스스로 호출하는 ability로 나뉜다 [17:21]
• ability는 React coding standards처럼 agent가 coding 중 필요한 rule을 불러와 useEffect를 피하는 식의 coding convention을 적용할 때 적합하다 [17:43]

12. context leakage를 줄이고 senior developer의 절차를 skill로 만든다

• AI 활용 격차를 만드는 역량에는 model이 언제 질문해야 하는지 설계하는 감각도 포함된다. 예시는 vision을 먼저 던지고, consequential design·architecture·product decisions를 선별하게 하는 방식이다 [20:25]
• skill을 ability로 많이 등록할수록 각 description이 context window에 새어 들어간다. 100개 skill은 100개 description leakage를 만들며, prompt budget과 model behavior에 부담을 준다 [21:14]

13. 지식·기술·지혜의 차이와 재사용 가능한 작업 단위

• 지혜는 실제로 필요한 정확한 맥락에서 직접 수행한 경험이 있어야 얻기 어렵다. 단순한 지식이나 반복 기술만으로는 현실 적용 능력이 완성되지 않는다 [24:02]
• Anthropic 같은 특정 조직의 방식을 체득하려면 그 조직의 실제 환경에서 일해야 한다. 외부에서 얻을 수 있는 것은 주로 지식과 기술에 가깝다 [24:21]

14. Sand Castle 기반 AFK 개발과 샌드박스 실행 환경

• 로컬 계획 수립과 일부 구현에는 Claude Code를 사용하며, Opus 4.8 medium effort 설정이 안정적인 기본값으로 자리 잡는다 [24:57]
• 개발 작업의 상당 부분은 키보드에서 떨어진 상태로 진행된다. Sand Castle은 에이전트를 샌드박스 안에서 실행해 원격·비동기 작업을 가능하게 한다 [25:12]

15. GitHub Actions 리뷰 에이전트와 병렬 작업 확장

• GitHub Actions에서 PR 브랜치를 체크아웃한 뒤, 로컬 프롬프트 기반 리뷰 에이전트를 실행해 타입 체크와 검토 결과를 자동으로 남긴다 [26:18]
• 리뷰 에이전트는 변경 사항을 점검하고 타입 체크 통과 여부를 확인한 뒤 결과를 댓글처럼 반환한다. 반복적인 검토 작업이 자동화되는 구조다 [26:33]

16. 모델보다 하네스에 집중해야 하는 이유

• 모델 선택은 Claude Code Opus 4.8 medium에서 크게 벗어나지 않으며, 성과 차이는 모델 자체보다 실행 체계와 주변 환경에서 더 크게 발생한다 [27:19]
• 관심은 F1 자동차의 엔진에 해당하는 모델에 쏠리기 쉽다. 하지만 실제 성능은 차체, 공기역학, 프롬프트, 스킬, 코드베이스 상태까지 포함한 전체 하네스에서 나온다 [27:41]

17. bitter lesson 논쟁과 코드베이스 품질의 가치

• 머신러닝의 bitter lesson은 원시 컴퓨트 증가가 많은 최적화를 결국 이긴다는 관점이다. 그러나 모델 향상만 기다리면 하네스 개선의 가치를 과소평가할 수 있다 [29:08]
• 모델 성능 향상을 기다리기보다 에이전트가 잘 작동할 코드베이스와 작업 환경을 만드는 편이 중요하다. 그래야 시작부터 에이전트를 불리하게 만드는 구조를 피할 수 있다 [29:49]

18. 소프트웨어 기본기와 개발자 역량이 AI 활용의 상한선

• 30~40년 동안 효과가 검증된 원칙, 특히 변경하기 쉬운 코드베이스는 토큰 사용량을 줄인다. 그 결과 더 저렴하거나 덜 똑똑한 모델로도 같은 작업을 수행할 수 있다 [32:09]
• 아키텍처와 가드레일이 좋은 코드베이스는 에이전트가 탐색에 낭비하는 토큰을 줄인다. 반대로 구조가 나쁘면 같은 작업에도 더 강한 모델이 필요해진다 [32:31]

19. 브라우저 자동화 에이전트 사례와 보안 리스크

• 개발자는 제품 결정과 방향성을 직접 통제해야 한다. AI에 모든 것을 위임할 수 없기 때문에 코드와 제품을 이끌 수 있는 기술이 필요하다 [34:34]
• Twitter API 콘솔에서 버튼이 로드되지 않는 문제가 여러 브라우저와 확장 프로그램 비활성화 후에도 해결되지 않았다. 이후 Cursor의 Fable 기반 에이전트가 대체 해결 경로로 투입됐다 [35:00]

20. AI가 작업을 많이 맡아도 인간의 판단 책임은 남는다

• Cursor 안에서 프로젝트를 진행하는 동안 목표와 이유는 사람이 정의했지만, 콘솔 로그인과 결제 이후 대부분의 작업을 AI가 수행하면서 사람의 가치가 낮아진 듯한 감각이 생긴다 [36:00]
• 에이전트가 좋은 결과를 냈는지 판단하려면 완료 기준, 보안 테스트, 방향성 검증이 필요하고, 이 부분에는 여전히 사람이 필요하다 [36:36]

21. 강한 모델은 더 넓은 문제를 발견하지만 비전은 여전히 사람에게 있다

• Fable 같은 최신 모델은 최적화나 기능 구현 중 사용자가 찾지 못했던 깊은 버그를 발견했고, 다른 모델들이 놓친 문제까지 잡아낸 사례가 나온다 [37:29]
• 프런트엔드 재설계 중 백엔드 API의 중대한 보안 문제가 발견되면, AI의 관여도는 단순 50대 50 협업보다 더 커진다 [37:58]

22. 모델 성능보다 올바른 하네스와 반복 검사가 더 중요하다

• 보안 리뷰를 매일 실행하는 크론 작업처럼 저장소의 다른 부분을 계속 점검하는 구조를 만들면, 비교적 단순한 모델로도 의미 있는 결과를 얻을 수 있다 [39:06]
• 깊은 보안 문제도 더 강한 모델만의 산물이 아니라, 올바른 위치를 보게 하고 적절한 프롬프트나 하네스를 제공하면 더 저렴한 모델로도 발견될 수 있다 [39:34]

23. 버그 발견의 진짜 교훈은 자기개선 시스템을 만드는 일이다

• Fable이 보안 문제를 찾았다는 사실에서 얻을 교훈은 모델의 우수성만이 아니라, 코드 안에 보안 취약점이 존재했고 앞으로 더 많은 문제를 검사할 장치가 필요하다는 점이다 [40:53]
• 보안 문제가 왜 그 지점까지 남아 있었는지 원인을 찾아야 하며, 같은 문제가 반복된다면 자전거 도난에 자물쇠가 필요한 것처럼 시스템적 방어가 필요하다 [41:30]

24. 루프 담론은 인간참여 작업과 AFK 작업의 구분으로 계속된다

• 에이전틱 루프에 대한 관심은 일부는 토큰 사용을 늘리는 과장된 담론이고, 일부는 실제로 유용한 작업 자동화 방식일 수 있다 [42:58]
• 인간참여 작업은 사람이 에이전트와 함께 계획, 복잡한 구현, 범위가 불명확한 문제를 조율하는 방식이며, 현장에서 맥락을 정리해야 할 때 유용하다 [43:26]

25. 지속 루프보다 작업 큐가 에이전트 운영에 더 잘 맞는다

• Ralph loop 같은 방식은 Claude Code를 while loop로 반복 실행해 언젠가 완료되게 하는 구조지만, 실제로 필요한 것은 반복 자체보다 특정 작업을 맡아 처리하는 AFK 에이전트다 [44:28]
• 더 적합한 모델은 루프가 아니라 큐이며, 큐는 완료해야 할 버그 리포트, 기능 요청, 이슈 같은 작업 백로그를 의미한다 [45:21]

26. 자동화된 버그 처리와 인간 체크포인트의 후퇴

• 여러 버그 리포트 중 중요한 항목을 우선순위화하고, 외부 협업 요청의 평판을 확인하는 일은 사람의 판단처럼 보이지만 에이전트 흐름 안에서도 자동화할 수 있다 [48:00]
• 라이브 애플리케이션의 오류가 Sentry 같은 관측 도구에서 이슈로 생성되고, 에이전트가 코드베이스 탐색 결과와 즉시 수정 가능 여부를 구조화된 데이터로 반환할 수 있다 [48:28]

27. 자동 병합의 경계와 리뷰가 주는 두 가지 가치

• 버그가 들어올 때만 작동하는 자동화는 무한 루프가 아니며, OpenAI나 Anthropic 비용을 불필요하게 계속 쓰는 구조와는 다르다 [49:37]
• 작은 UI 변경이나 단순 버그처럼 위험이 낮은 변경은 하네스, 스킬, 좋은 모델, 여러 에이전트의 판단을 거쳐 곧바로 프로덕션에 병합될 가능성이 커진다 [50:00]

28. 코드 리뷰에서 시스템 리뷰로 확장되는 검증 방식

• 내부 리팩터링처럼 동작 변화가 없는 PR은 AI가 리뷰 생략 가능 여부를 판단할 수 있지만, 그 판단을 내리는 AI 역시 지속적인 검증과 피드백의 대상이 되어야 한다 [51:38]
• 사람이 검토하지 않아도 된다고 분류된 PR도 일부는 샘플링해 실제로 안전한지 확인해야 하며, 검토 범위는 코드에서 코드를 만든 시스템까지 확장된다 [51:55]

29. 더 풍부한 리뷰 경험과 AI 보조 검토

• 프런트엔드 변경에서는 AI가 변경된 화면과 코드를 직접 탐색하는 영상을 녹화하고, 텍스트 음성 변환을 붙여 PR 안에서 작동 모습을 보여줄 수 있다 [53:09]
• 리뷰 자료가 영상, 음성, 실행 화면까지 포함되면 사람은 변경 내용을 더 빠르게 이해할 수 있고, 코드 리뷰의 피로와 병목도 줄어든다 [53:32]

30. AI 시대에도 변하지 않는 제품 개발의 기본

• 비즈니스를 만들 때는 고객과 직접 대화하고, 그들이 실제로 필요로 하는 문제를 찾은 뒤, 그 문제를 푸는 프로토타입을 만들어야 한다 [54:39]
• AI는 구현 속도와 절차 위임에서 큰 이점을 주지만, 고객이 원하는 것을 모르면 올바른 아이디어나 제품을 대신 만들어주지 못한다 [55:03]

31. 시니어 경험, AI 실험성, AX의 결합

• AI 도구를 적극적으로 쓰는 시니어는 큰 생산성 향상을 얻지만, 과거의 실망스러운 경험 때문에 최신 모델과 하네스의 개선을 받아들이지 않는 개발자도 있다 [56:40]
• AI 도구, 모델, 스킬, 에이전트별 강점을 잘 아는 젊은 개발자는 기술 기본기와 결합될 때 큰 출력과 빠른 학습 속도를 낼 수 있다 [57:06]

32. 윤리적 불편감과 개발자 역할의 전환

• AI 도구에는 Anthropic이 소설을 가져와 Claude에 넣었다는 식의 윤리적 불편감이 남아 있으며, 이런 문제를 찝찝하게 느낄 수 있다 [1:00:02]
• 그럼에도 AI는 이미 현장에 들어와 있고, 개발자의 일은 이런 도구가 존재하는 조건 위에서 계속 바뀌고 있다 [1:00:14]

33. 실천 단계는 빈 상태에서 다시 쌓고 AFK 에이전트로 위임하는 것이다

• 첫 단계는 모든 스킬, 플러그인, MCP 서버, Claude.md, agents.md를 지우고 완전히 빈 상태로 돌아가, 에이전트가 기본 모드에서 무엇을 하는지 관찰하는 것이다 [1:00:49]
• 많은 사용자가 컨텍스트 창을 과도한 지시와 설정으로 부풀리기 때문에, 빈 슬레이트에서 다시 시작해야 실제로 필요한 절차와 불필요한 장식을 구분할 수 있다 [1:01:01]

🧾 결론

• 이 영상의 중심 메시지는 “더 좋은 모델을 기다리는 것”보다 “모델이 잘 일할 수 있는 환경을 만드는 것”이 더 통제 가능하고 지속적인 개선 방향이라는 점입니다.
• 개발자는 AI에게 코딩 작업을 많이 위임할수록 오히려 목표 설정, 아키텍처 판단, 보안·테스트 기준, 리뷰 체계 같은 상위 판단을 더 잘해야 한다.
• 코드베이스가 변경하기 쉽고 테스트와 문서가 갖춰져 있을수록 에이전트는 적은 토큰과 낮은 시행착오로 더 좋은 결과를 낼 수 있다.
• Teach Skill 사례는 AI 시대의 학습도 단순 지식 전달이 아니라 미션, 현재 수준, 실습, 기록, 다음 수업으로 이어지는 상태 기반 코칭이 중요하다는 점을 보여준다.
• AI가 깊은 버그나 보안 문제를 발견했다면 단순히 “모델이 뛰어나다”로 끝낼 것이 아니라, 왜 그 문제가 남아 있었는지 점검하고 반복 가능한 검사 시스템으로 바꿔야 한다.

📈 투자·시사 포인트

• AI 개발 도구의 경쟁력은 모델 성능뿐 아니라 에이전트 실행 환경, 샌드박스, 워크플로우 자동화, 코드 리뷰 보조, 작업 큐 관리 같은 하네스 계층에서 크게 갈릴 수 있다.
• 기업과 개발팀은 단순히 최신 모델을 도입하는 것보다 코드베이스 품질, 테스트 체계, 문서화, 리뷰 자동화, 보안 점검 루틴을 개선하는 데 투자필요가 있다.
• 시니어 개발자의 가치는 줄어들기보다 전략적 설계와 위임 능력을 통해 더 커질 수 있으며, AI에 익숙한 주니어도 기본기와 실험성이 결합될 때 높은 성장 속도를 낼 수 있다.
• 에이전트가 더 많은 실행을 맡는 환경에서는 “코드 리뷰”가 “시스템 리뷰”로 확장될 가능성이 크며, 사람이 모든 변경을 직접 보는 방식은 점차 비효율적이 될 수 있다.
• 개인 개발자나 팀은 처음부터 복잡한 스킬과 설정을 쌓기보다 빈 상태에서 모델의 기본 동작을 관찰하고, 실제 병목을 해결하는 절차형 스킬만 선택적으로 추가하는 접근이 유효한다.

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

• 영상에서 언급된 Claude Code의 Opus 4.8 medium effort, Fable, Sand Castle, SERP API, aihero.dev/skills 등의 도구명·버전·제공 조건은 발화 기반 정보이므로, 실제 사용 전 공식 문서나 현재 제품 상태를 별도로 확인해야 한다.
• “시니어 개발자는 AI로 훨씬 큰 배율 효과를 얻고, 주니어는 상대적으로 작은 부스트만 얻는다”는 주장은 발표자의 관찰과 해석에 가깝다. 조직, 코드베이스 품질, 온보딩 방식, 리뷰 체계에 따라 결과가 달라질 수 있다.
• Cursor 내장 브라우저에서 에이전트가 로그인 후 API 키를 생성하고 앱 설정을 조정한 사례는 특정 상황의 일화로 보인다. 이를 일반적인 운영 방식으로 받아들이기보다 보안 정책, 권한 분리, 감사 로그, 키 관리 기준을 먼저 검토해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 사용하는 AI 코딩 환경을 모델 중심이 아니라 하네스 관점에서 점검한다: 프롬프트, 스킬, 실행 환경, 테스트, 문서, 코드베이스 구조를 각각 분리해 개선 후보를 정리한다.
• 등록된 에이전트 스킬을 ability와 procedure로 나누고, 항상 모델이 자동 호출해야 하는 것과 사용자가 직접 호출해야 하는 것을 구분한다.
• 컨텍스트 창에 불필요하게 새어 들어가는 스킬 설명, 과도한 지시문, 오래된 설정 파일을 정리하고, 빈 상태에서 필요한 절차만 다시 추가하는 실험을 한다.
• AI에게 맡길 수 있는 전술적 작업과 사람이 직접 유지해야 하는 전략적 판단을 구분한다: 아키텍처, 제품 방향, 보안 기준, 완료 기준은 별도 체크포인트로 남긴다.

❓ 열린 질문

• 우리 팀이나 개인 워크플로우에서 AI에게 맡겨도 되는 전술적 작업과 사람이 직접 책임져야 하는 전략적 판단의 경계는 어디까지인가?
• 현재 코드베이스는 에이전트가 탐색하기 쉬운 구조인가, 아니면 불필요한 토큰과 시행착오를 많이 쓰게 만드는 구조인가?
• 스킬을 많이 추가하는 것보다 빈 상태에서 다시 쌓는 방식이 실제 생산성에 도움이 되는지, 어떤 기준으로 측정할 수 있을까?