🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI 에이전트로 하루에 PR 40개를 올리는 방법의 핵심은 코딩 속도 자체보다 계획 품질, 병렬 세션 운영, 자동 검증 파이프라인으로 사람의 병목을 줄이는 데 있다.

📌 핵심 요점

1. AI 에이전트가 코드 작성과 1차 검증을 많이 맡기 시작하면, 사람이 모든 코드 라인을 직접 리뷰하는 방식은 곧 병목이 된다.
2. 생산성을 키우려면 짧은 지시보다 상세한 요구사항, 측정 가능한 목표, 시각 자료가 포함된 계획을 제공해 에이전트가 더 오래 자율 실행하게 해야 한다.
3. 여러 에이전트 세션을 병렬로 돌리면 사람의 개입은 시작·끝·판단 대기 지점에 집중되고, 대기 시간 동안 다른 작업을 진행할 수 있다.
4. 병렬 개발에는 작업 공간 충돌을 피하는 worktree 관리, Treehouse 같은 재사용 가능한 작업 공간 풀, 팀 전체 visibility 확보가 중요하다.
5. 대량 PR 환경에서는 라인 단위 리뷰보다 intent, risk, test evidence, E2E 검증을 중심으로 변경을 평가하는 자동화된 리뷰 흐름이 더 중요해진다.

🧩 배경과 문제 정의

• AI 에이전트가 코드 작성과 1차 검증의 상당 부분을 맡게 되면, 사람이 모든 코드 라인을 직접 검토하는 기존 방식은 생산성의 병목이 된다.
• 하루 20~40개 PR이 생성되는 수준에서는 기존의 코딩 중심 워크플로우와 팀 조율 방식만으로는 속도를 따라가기 어렵다.
• 더 큰 성과를 내려면 요구사항을 명확히 설계하고, 에이전트가 더 오래 자율적으로 실행되도록 하며, 사람은 애매한 판단과 최종 검증에 집중해야 한다.
• 개발자의 역할은 직접 코딩하는 사람에서 여러 에이전트 세션을 병렬로 감독하고, 필요한 순간에 개입하는 방향으로 이동한다.

🕒 시간순 섹션별 상세정리

1. 모든 코드 검토가 병목이 되는 에이전트 개발 환경

• 모든 코드 라인을 사람이 직접 검토하는 방식에서는 사람이 곧 병목이 되며, 에이전트의 1차 코드에서 사람이 새로 발견하는 문제가 거의 없어지는 단계가 온다 [00:13]
• 동시에 최소 5개 세션과 평균 20~30개 에이전트가 돌아가고 하루 20~40개 PR이 생성되는 흐름에서는, 기존 개발 조직의 작업 방식이 더 이상 충분히 준비된 구조가 아니게 된다 [00:28]

2. 계획 품질이 에이전트의 자율 실행 시간을 좌우

• 계획 단계에서는 사람이 더 많은 시간을 쓰고 에이전트가 보조하지만, 코드 작성 단계는 거의 전적으로 에이전트가 맡으며 검증 단계도 대부분 에이전트가 처리한다 [01:49]
• 에이전트가 코드 작성과 검증 루프를 오래 유지할수록 사람의 직접 개입 없이 끝나는 일이 늘어나고, 이 자율 실행 시간을 늘리는 것이 생산성 확장의 핵심이 된다 [02:21]

3. 병렬 세션으로 사람 개입 구간을 압축

• 사람의 개입은 주로 작업의 시작과 끝에 집중되며, 여러 세션을 병렬화하면 에이전트가 실행되는 동안 사람의 시간도 계속 생산적으로 활용된다 [04:12]
• 병렬화는 여러 프로젝트 사이에서도 가능하고, 같은 프로젝트 안에서도 서로 다른 작업을 여러 세션에 나눠 맡기는 방식으로 적용할 수 있다 [04:46]

4. 에이전트 작업의 가시성과 터미널 중심 개발 환경

• Cursor, Claude Code, Codex 같은 도구를 쓰면 Slack 버그 제보부터 배포된 수정까지 코드 에디터 밖의 기록 없이 이어질 수 있으며, 규모가 커질수록 조율 공백이 커진다 [05:31]
• 에이전트가 어떤 작업을 맡았고 누가 배정했는지 보이지 않으면, 실행 속도는 빨라져도 팀 전체의 작업 가시성은 약해진다 [05:51]

5. 스크린샷과 오픈코드로 시각 문제를 계획 단계에 반영

• 화면 개선 작업은 먼저 스크린샷을 찍고, 현재 화면의 문제를 이미지와 함께 에이전트에게 전달하는 방식으로 시작된다 [07:10]
• 오픈소스 도구인 open code를 사용하면 새 모델이 나올 때마다 여러 모델을 빠르게 바꿔 시험해볼 수 있다는 장점이 있다 [07:27]

6. HTML 기반 계획 협업과 대기 시간의 병렬 활용

• 계획 단계에서는 같은 요청에 “Lavish를 사용해 질문과 함께 논의하라”는 조건을 추가해, 시각 편집기 기반 협업 방식으로 전환한다 [09:04]
• Lavish는 HTML over markdown 글을 계기로 만든 시각 편집기이며, HTML은 토큰 비효율 우려와 달리 인간과 에이전트가 함께 다루는 협업 artifact로 풍부한 상호작용을 제공한다 [09:32]

7. worktree의 충돌 회피와 관리 부담

• 같은 디렉터리에서 다른 에이전트를 추가로 실행하면 서로의 작업을 덮거나 방해할 수 있으므로, 병렬 작업에는 독립된 작업 공간이 필요하다 [12:00]
• 일반적인 Git worktree 방식은 별도 디렉터리를 만들지만, 이후 해당 worktree가 어떤 작업용인지, 아직 사용 중인지, 재사용 가능한지 판단해야 하는 인지 부담이 생긴다 [12:35]

8. Treehouse로 재사용 가능한 작업 공간 풀을 만든다

• worktree를 수동으로 고르고 정리하는 방식은 각 디렉터리의 상태와 용도를 계속 기억해야 하므로 인지 부하가 크다 [13:48]
• Treehouse는 새 작업을 시작할 때 명령 한 번으로 관리형 worktree를 만들고 바로 그 디렉터리로 이동시켜, 사용자가 기존 worktree 재사용 여부를 직접 고민하지 않게 한다 [14:00]

9. 시각적 artifact와 주석 기반 피드백

• 에이전트가 작성한 제안은 HTML 기반 시각 artifact로 나타나며, 긴 텍스트 벽보다 사람이 구조와 문제 지점을 훨씬 빠르게 파악할 수 있다 [15:07]
• artifact 안에서 마음에 들지 않는 요소를 직접 클릭해 주석을 달 수 있고, “이 부분은 신경 쓰지 않는다” 같은 피드백을 특정 위치에 붙일 수 있다 [15:45]

10. Lavish Axi와 인터랙티브 계획 선택

• Lavish Axi는 GitHub repo에서 바로 사용할 수 있으며, 별도 LLM API 키 없이 기존 에이전트 세션 안에서 기술 계획이나 artifact를 생성한다 [17:22]
• CSS 수정 후 artifact는 현재 레이아웃 문제와 개선 방향을 시각적으로 보여주어, 텍스트 설명만 볼 때보다 옵션별 차이를 빠르게 비교하게 해준다 [18:11]

11. 새 프로젝트 기획은 비판과 리스크 검토로 구체화된다

• 처음부터 시작하는 프로젝트는 더 긴 기획 시간이 필요하며, 초기 아이디어의 핵심 요소를 에이전트와 함께 브레인스토밍하는 단계가 먼저 필요하다 [19:52]
• 에이전트는 초기 생각을 그대로 확정하지 않고 약점, 리스크, 충분히 검토되지 않은 영역을 찾아낸 뒤, 그 의견을 HTML artifact 형태로 되돌려준다 [20:14]

12. 디자인 시스템과 다중 에이전트 세션 운영

• Lavish editor에는 사용자의 선호와 “필요하면 반박해도 된다” 같은 협업 지침이 내장되어 있어, 에이전트가 도구를 사용할 때 기본 작업 방식까지 함께 따른다 [21:32]
• 시각 디자인에는 Cloud Design을 많이 쓰며, 특히 새 프로젝트에서는 디자인 시스템을 먼저 만들면 여러 컴포넌트에 같은 체계를 쉽게 적용할 수 있다 [22:00]

13. 서브 에이전트는 탐색 컨텍스트를 분리할 때 유효하다

• 현재 모델과 하네스는 서브 에이전트를 자발적으로 활용하는 능력이 제한적이며, 복잡한 질문에서 built-in explore 같은 일부 사례에만 자동 분업이 일어난다 [24:00]
• Cloud Code나 Codex의 explore 계열 서브 에이전트는 코드베이스를 조사한 뒤 결과를 돌려주는 역할을 하지만, 이런 활용은 아직 예외적인 패턴에 가깝다 [24:19]

14. 독립 실험은 병렬 서브 에이전트로 분산한다

• 서로 독립적인 실험 아이디어가 10개 있다면 각각을 서브 에이전트에 맡길 수 있으며, 병렬 격리 실행은 메인 세션의 시간과 토큰 소모를 줄인다 [25:41]
• ProgramBench는 에이전트가 FFmpeg 같은 프로그램을 처음부터 만들고, 요구사항과 테스트를 통과하는지 측정하는 벤치마크다 [26:40]

15. agents.md는 테스트 방식까지 고정하는 운영 지침이 된다

• 프로젝트별 agents.md에는 구조 맥락과 테스트 지침을 함께 넣어, 에이전트가 작업 후 어떤 검증을 해야 하는지 미리 고정한다 [28:15]
• 테스트 지침이 없으면 에이전트는 기본 테스트 수준에 머물기 쉽고, 복합 UI나 실제 사용자 흐름을 충분히 검증하지 못할 가능성이 커진다 [28:45]

16. 수동 검증 절차는 에이전트 지침으로 전환된다

• 에이전트는 기본적으로 순수 코드 기반 단위 테스트를 선호하지만, 이런 테스트만으로는 프런트엔드나 데스크톱 앱의 실제 동작을 끝까지 보장하기 어렵다 [30:13]
• Codex의 내장 브라우저 확인은 일반 프런트엔드 변경에는 맞을 수 있지만, Electron 데스크톱 앱에는 별도의 검증 시설과 절차가 필요하다 [30:30]

17. AI가 만든 대량 변경은 사람 리뷰를 병목으로 만든다

• 작업 완료 후 에이전트가 변경 목록을 반환해도, 그 변경이 좋은지와 버그가 없는지를 판단하는 검증 단계가 실제 병목이 된다 [31:58]
• 일반적인 diff 라인 단위 리뷰는 AI가 대량의 코드를 생성할수록 사람이 검토 흐름의 병목이 되는 구조를 만든다 [32:21]

18. No Mistakes는 새 컨텍스트에서 의도와 변경을 검증한다

• No Mistakes는 작업 세션을 읽어 의도를 파악하고, 원격 main 최신 상태 위로 변경을 rebase해 나중의 머지 충돌 위험을 줄인다 [33:30]
• 변경 리뷰 단계는 edge case, 버그, 논리 오류를 강하게 찾는 고회수율 검증으로 구성되고, 사람이 모든 줄을 보는 부담을 대체한다 [33:55]

19. fresh context 리뷰와 intent 단계의 역할

• 같은 세션에서 “변경을 리뷰해 달라”고 하면 에이전트가 이미 본 작업 흐름과 맥락에 편향되고, 기존 구현이 맞다는 전제를 갖기 쉬워 엣지 케이스를 놓칠 수 있다 [36:07]
• fresh context window를 쓰면 기존 세션 전체를 복사하지 않고도 더 많은 엣지 케이스가 잡히며, 검토자는 작업 과정의 영향을 덜 받은 상태에서 결과를 본다 [36:31]

20. 테스트 단계는 로컬 확인을 넘어 회귀와 증거를 확인한다

• review 단계는 코드 검토를 맡고 test 단계는 테스트를 실행하지만, 기본 에이전트의 로컬 검증보다 CI에 가까운 방식으로 다른 기능의 회귀까지 확인한다 [37:30]
• test 단계는 변경이 실제로 작동한다는 증거로 스크린샷이나 비디오 같은 아티팩트를 남기며, 검토자는 결과물을 보고 기대한 동작인지 빠르게 판단할 수 있다 [38:01]

21. E2E 자동화는 느리지만 안정성을 높이고 병렬 작업으로 비용을 줄인다

• Playwright 같은 브라우저 테스트 도구를 활용하면 특정 시나리오나 사용자 플로우를 end-to-end로 확인할 수 있고, 에이전트가 필요한 프레임워크와 도구를 대체로 찾아낸다 [39:27]
• 여러 검증 단계를 거치면 기능 출시 속도는 느려지지만, 사용자가 있는 제품에서는 변경이 다른 부분을 깨뜨리지 않는다는 확신이 더 중요해진다 [39:47]

22. 모든 변경에 무거운 검증을 붙이지 않고 의미 있는 단위에 적용한다

• No Mistakes는 대부분의 변경에 활용되지만, 단순 문서 업데이트처럼 영향이 작고 검증 비용·토큰 사용량을 정당화하기 어려운 경우에는 생략된다 [41:18]
• 무거운 검증은 모든 PR을 QA 팀에 보내는 절차가 아니라, 일정 수준 이상의 의미 있는 변경이나 마일스톤에 선택적으로 붙이는 점검에 가깝다 [41:47]

23. AI 시대의 PR 속도는 기존 팀 프로세스를 흔든다

• 기존 소프트웨어 팀 프로세스는 엔지니어가 월 10~15개 PR을 만드는 속도에 맞춰져 있으며, 이 정도라면 동료 리뷰와 관련 절차가 감당 가능하다 [43:46]
• AI로 PR 수가 10배 가까이 늘어나면 사람 중심 리뷰 체계와 팀 구성은 그 속도를 따라가지 못하고, 기존 프로세스의 전제가 흔들리기 시작한다 [44:18]

24. PR 결과물은 위험도·문서·증거를 기준으로 사람의 시간을 배분한다

• 완료된 파이프라인은 문서 단계의 누락을 찾아 수정했고, 코드 변경이 영향을 줄 수 있는 문서 위치까지 함께 찾는 점에서 실무적 가치가 있다 [45:19]
• 생성된 PR은 원래 세션에서 파악한 의도, 변경 내용, 위험도 평가를 요약하며, 낮은 위험은 검토 시간을 줄이고 중간·높은 위험은 사람이 diff를 더 자세히 보게 한다 [45:58]

25. 검증 중심 리뷰와 하루 수십 개 PR 워크플로

• 라인 단위 코드 리뷰보다 변경 내용과 리스크를 확인하는 리뷰가 더 유용하며, 에이전트가 만든 결과물에는 검증 과정과 위험 점검이 함께 붙어야 한다 [48:10]
• 하루 PR 수는 보통 22~40개 수준까지 올라가며, 구현을 에이전트에게 맡긴 뒤 사람은 다른 작업으로 전환하는 병렬 흐름이 높은 처리량을 만든다 [48:27]

26. 많이 만들고 많이 실패하면서 기술 감각을 키우기

• 기술 역량을 키우는 첫 단계는 장난감 프로젝트나 버릴 만한 아이디어라도 많이 만들어보는 것이며, 그 과정에서 에이전트가 잘하는 부분과 부족한 부분이 드러난다 [50:20]
• 한 가지 아이디어를 오래 고른 뒤 실패하고 멈추는 방식은 학습량을 줄이며, 떠오르는 아이디어마다 에이전트에 프롬프트를 던져 실행해보는 방식이 더 많은 피드백을 만든다 [50:44]

27. 병렬 에이전트와 코드 외 업무 자동화로 사람 병목 줄이기

• 더 많은 토큰과 여러 에이전트를 병렬로 쓰는 습관은 사람이 루프 안에 과도하게 머무는 병목을 줄이고, 워크플로를 확장하도록 압박하는 장치가 된다 [51:28]
• 에이전트의 생산성을 키우려면 한 번에 하나씩 기다리는 방식에서 벗어나 사람이 루프 밖으로 이동해야 하며, 병렬 실행은 더 많은 작업량을 확보하는 핵심 수단이 된다 [51:44]

28. 세션 분석, 토큰 사용, 공개 도구 공유

• 클로드 코드의 insights 명령은 이전 세션을 분석해 추가할 skill, 조정할 memory 파일, 효율 개선 지점을 찾아주며, 대화 기록 자체가 자동화 후보를 찾는 입력이 된다 [53:13]
• 결론적으로 핵심 조언은 여러 아이디어를 반복 실행하고, 여러 에이전트로 더 많은 시도를 만들며, 코드 작성 외 영역까지 AI 활용을 확장하는 세 가지 흐름으로 압축된다 [53:50]

🧾 결론

• 이 영상의 핵심 메시지는 “AI가 코드를 많이 쓰게 하라”가 아니라, 사람이 코딩 루프 안에 계속 머무는 구조를 바꾸라는 데 있다.
• Kun Chen의 워크플로우에서는 사람의 시간 대부분이 구현보다 계획, 판단, 위험 검토, 결과 확인에 배치된다.
• 하루 20~40개 PR 수준의 처리량은 단순히 더 빠른 모델만으로 설명되지 않고, 병렬 세션, 시각적 계획 artifact, 독립 작업 공간, 자동 리뷰·테스트 파이프라인이 함께 맞물릴 때 가능해진다.
• AI가 만든 변경을 무조건 신뢰하는 것도 아니며, fresh context 리뷰, edge case 탐색, 스크린샷·비디오 증거, E2E 테스트를 통해 검증 부담을 구조화한다.
• 따라서 AI 에이전트 시대의 개발 역량은 직접 코드를 많이 쓰는 능력에서, 여러 에이전트를 설계·감독·검증하는 운영 능력으로 이동하고 있다.

📈 투자·시사 포인트

• 개발 도구 시장에서는 단순 코드 생성기보다 계획, 병렬 실행, 작업 공간 관리, 리뷰 자동화, 테스트 증거 생성까지 묶는 agentic workflow 도구의 가치가 커질 가능성이 있다.
• AI 도입으로 PR 생산량이 급증하면 기존 동료 리뷰 중심 프로세스가 흔들릴 수 있어, 기업은 리뷰·QA·문서화·배포 검증 체계를 함께 재설계해야 한다.
• 소규모 팀이나 개인 개발자는 병렬 에이전트와 자동 검증을 잘 활용하면 더 많은 실험을 빠르게 수행할 수 있지만, 검증을 생략하면 제품 안정성 리스크가 커질 수 있다.
• worktree, Treehouse, Lavish, No Mistakes 같은 사례는 앞으로 AI 개발 환경의 경쟁축이 “모델 성능”뿐 아니라 “사람이 병목이 되지 않는 운영 인터페이스”로 이동할 수 있음을 보여준다.
• 검증 필요: 영상에서 언급된 특정 도구들의 실제 성숙도, 장기 유지보수성, 팀 환경에서의 확장성은 transcript만으로 단정하기 어렵고, 실제 사용 사례와 공개 저장소 상태를 별도로 확인해야 한다.

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

• “하루 20~40개 PR”과 “평균 20~30개 에이전트”는 발표자의 실제 워크플로 경험으로 제시되지만, 모든 팀이나 제품 환경에 일반화 가능한 수치인지는 별도 검증이 필요하다.
• Lavish, Lavish Axi, Treehouse, No Mistakes, ProgramBench 등 언급된 도구의 현재 공개 여부, 설치 방법, 라이선스, 유지보수 상태는 영상 내용만으로 확정하기 어렵다.
• “사람이 추가로 잡는 문제가 거의 사라지는 단계”라는 설명은 발표자의 반복 개선 결과로 보이지만, 어떤 기준으로 사람 리뷰와 에이전트 리뷰의 결함 탐지율을 비교했는지는 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 에이전트에게 작업을 맡기기 전, 짧은 지시 대신 요구사항·제약·성공 기준·검증 방법을 포함한 상세 스펙을 먼저 작성한다.
• 프로젝트별 agents.md 또는 유사한 지침 파일에 테스트 명령, E2E 검증 절차, 스크린샷 확인 방식, 완료 기준을 명시한다.
• 여러 에이전트 세션을 병렬로 운영할 경우, 작업별 독립 worktree 또는 관리형 작업 공간을 사용해 파일 충돌을 방지한다.
• UI 작업에서는 텍스트 설명만 주지 말고 스크린샷, 시각적 artifact, 주석 기반 피드백을 활용해 계획 단계의 오해를 줄인다.

❓ 열린 질문

• 어떤 기준을 넘는 변경부터 No Mistakes 같은 무거운 리뷰·테스트 파이프라인을 적용해야 할까?
• 에이전트가 생성한 PR의 위험도 평가는 어떤 신호를 기준으로 산정해야 신뢰할 수 있을까?
• 하루 수십 개 PR이 발생하는 환경에서 팀 전체 visibility를 유지하려면 어떤 대시보드나 작업 추적 체계가 필요할까?