AI-Assisted Engineering Talk #17/27

CLI 기반 멀티 에이전트 파이프라인으로 “감(感) 코딩"에 신뢰를 더하는 방법

Vibe coding이 빠르게 코드를 뽑아내는 데 성공했지만, 프로덕션에서는 그것만으로 부족합니다. “Confidence는 컨텍스트 + 워크플로우 + Red Team(테스트·리뷰)에서 온다. 그리고 그것을 연결하는 자연스러운 인터페이스는 CLI다.”

핵심 주장

1. AI 코딩 도구는 세 세대를 거쳤다

Gen 1.0은 자동완성(IDE 플러그인), Gen 2.0은 에이전틱 채팅(IDE 포크), Gen 3.0은 SDLC 전역에 걸친 멀티 에이전트 워크플로우입니다. 핵심 전환점은 “에이전트에게 팀원처럼 명령을 내리고 end-to-end 흐름을 실행시키는 순간"이라고 Itamar는 짚습니다.

2. Vibe coding만으로는 프로덕션 신뢰를 얻을 수 없다

그린필드에서는 코드 생성만으로 충분하지만, 엔터프라이즈 규모의 기존 코드베이스에서는 버그 수정, 리팩토링, 유지보수가 핵심입니다. Karpathy 본인조차 vibe coding을 재고하며 “컨텍스트를 가져오고 워크플로우를 만들라"고 7단계 절차를 제안한 것이 그 증거입니다.

3. CLI가 멀티 에이전트 파이프라인의 자연스러운 인터페이스다

CLI는 에이전트를 유닉스 도구처럼 파이프로 연결하고, 백그라운드 실행과 워크플로우 조합이 가능합니다. Simon Willison이 데모에서 IDE 대신 CLI를 선택한 것이 우연이 아니라는 것이 Itamar의 관찰입니다.

4. 에이전트 간 통신(A2A)이 다음 게임 체인저다

50명의 발표자 중 A2A를 실제로 쓰는 사람은 아직 없었지만, 특화된 에이전트들이 각자의 크레덴셜과 베스트 프랙티스를 갖고 병렬로 소통하는 “에이전트 스웜"이 2025-2026년에 현실화될 것이라고 전망합니다.

세대별 진화와 핵심 구성요소

  • 1. Gen 1.0: 자동완성 시대 — IDE 플러그인이 몇 줄 앞을 예측해주던 시대. 개발자가 아니면 더 나아갈 수 없었던 한계가 있었습니다.
  • 2. Gen 2.0: 에이전틱 채팅 시대 — IDE 포크(Cursor 등)가 주니어 개발자의 생산성을 끌어올렸지만, 시니어와 엔터프라이즈는 리뷰 부담과 품질 문제에 직면했습니다.
  • 3. Gen 3.0: SDLC 전역 멀티 에이전트 — IDE 안에 갇히지 않고 SDLC 전체에 AI를 적용합니다. CLI가 이 확장의 자연스러운 진입점입니다.
  • 4. Karpathy의 재고: 컨텍스트 + 워크플로우 — Karpathy는 “professionally care about” 하는 코드에서 vibe coding의 한계를 인정하고, 컨텍스트 주입과 7단계 워크플로우를 제안했습니다. 이것이 곧 Qodo의 접근법과 같습니다.
  • 5. V자 압축: 에이전트 협업 — 계획 → 코드 → 테스트 → 리뷰의 V자 흐름을 에이전트들이 서로 대화하며 압축합니다. MCP와 A2A가 이 연결을 가능하게 합니다.
  • 6. CLI 파이프라인: 에이전트를 도구처럼 — 코드 생성 → 커버리지 테스트 → 리뷰 에이전트를 파이프로 연결합니다. 결과를 다음 에이전트의 입력으로 넘기는 유닉스 철학이 에이전트 세계에 적용됩니다.
  • 7. 조직 베스트 프랙티스 축적 — Qodo Merge가 코드 리뷰 과정에서 조직의 베스트 프랙티스를 수집하고, 이 컨텍스트가 코드 생성 시 Shift-left로 반영됩니다.
  • 8. 동적 인터페이스 생성 — CLI가 “초라해” 보일 수 있지만, CLI에서 작업에 맞는 인터페이스를 자동 생성할 수 있습니다. 코드 리뷰 전용 UI처럼, IDE에 종속될 이유가 사라집니다.

검증된 인사이트

💡 [Insight] CLI는 에이전트의 유닉스 철학을 실현한다

“한 가지를 잘하는 작은 프로그램을 파이프로 연결한다"는 유닉스 철학이 에이전트 세계에서 부활합니다. generate | cover | review처럼 에이전트를 파이프라인으로 연결하면, 각 에이전트는 자기 역할에 집중하고 조합은 사용자가 통제합니다. IDE 플러그인에서는 구조적으로 불가능한 패턴이며, 이것이 CLI가 Gen 3.0의 자연스러운 인터페이스인 이유입니다.

cli unix-philosophy composability pipeline

💡 [Insight] Confidence의 정체는 Red Team이다

Itamar가 “confidence"라고 부르는 것의 실체는 테스트와 리뷰를 “사후 점검"이 아닌 “적대적 검증자(Red Team)“로 격상시키는 것입니다. 코드 생성 에이전트와 리뷰 에이전트가 동등한 위상에서 긴장 관계를 유지할 때, vibe coding의 속도와 프로덕션의 신뢰가 양립합니다. Qodo의 Qodo Merge가 이 Red Team 역할을 담당합니다.

testing code-review red-team quality

💡 [Insight] 베스트 프랙티스는 코드 리뷰에서 수확한다

대부분의 조직이 코딩 가이드라인을 문서로 작성하지만, Qodo의 접근법은 다릅니다. 실제 코드 리뷰 과정에서 반복되는 패턴을 자동으로 수집하여 조직의 베스트 프랙티스 데이터베이스를 구축합니다. 이 축적된 컨텍스트가 코드 생성 시점에 Shift-left로 주입되어, “사후 교정” 대신 “사전 예방"이 가능해집니다.

shift-left best-practices organizational-knowledge ## 다른 영상과의 교차점

  • Dex의 “에이전트는 무상태 fold 함수” 원칙과 Itamar의 “에이전트를 파이프로 연결” 비전이 만납니다. 12-Factor의 제어 흐름 소유 원칙은 Qodo CLI가 워크플로우를 사용자 손에 돌려놓는 철학과 정확히 일치합니다.
  • “컨텍스트가 AI 코드 생성의 1순위"라는 Chris의 선언은 Itamar가 Karpathy의 재고를 인용하며 도달한 결론과 동일합니다. 두 발표 모두 vibe coding의 한계를 인정하고 구조화된 컨텍스트 주입을 해법으로 제시합니다.
  • Gen 3.0의 “SDLC 전역 에이전트” 비전은 “워크플로우에 사는 작은 에이전트들"과 같은 미래를 그립니다. 코드 생성을 넘어 테스트, 리뷰, 배포까지 에이전트가 담당하는 구조가 양쪽 발표에서 공통적으로 나타납니다.
  • Itamar의 “기존 대규모 코드베이스에서 AI 도구가 그린필드보다 덜 유용하다"는 관찰은, Factory가 “에이전트 친화적 코드베이스"를 별도 과제로 다루는 이유와 직결됩니다. 컨텍스트 품질이 에이전트 성능의 상한선이라는 공통 인식이 있습니다.
  • Qodo의 “조직 베스트 프랙티스를 코드 리뷰에서 수확하여 생성 시점에 주입"하는 패턴은, Copilot의 copilot-instructions.md와 .instructions 파일 체계와 같은 문제를 다른 방향에서 풀고 있습니다.

한 줄 소감

“Vibe"라는 단어가 주는 가벼운 인상과 달리, 이 발표의 본질은 꽤 무거운 질문이었습니다. 빠르게 만드는 것과 믿을 수 있게 만드는 것 사이의 긴장을 어떻게 해소하느냐. Itamar의 답은 명쾌합니다. 속도를 포기하는 것이 아니라, 속도의 뒤를 봐주는 Red Team을 세우고 그 전체를 CLI 파이프라인으로 엮는 것. 유닉스 철학이 반세기 만에 에이전트 세계에서 다시 빛을 발하는 모습을 보니, 좋은 원칙은 시대를 초월한다는 생각이 드옵니다.