"AI Agent" 태그 — 6개 게시물

TL;DR​

"Attention Is All You Need" 공동 저자 Illia Polosukhin이 모델 연구를 떠나 AI 에이전트 하네스(IronClaw)를 만들고 있다. 4월 16일 서울에서 열린 IronClaw Meetup은 "왜 하네스 레이어가 AI의 새로운 경쟁 전선인가"를 중심으로, IronClaw의 보안·가상화·멀티테넌시 아키텍처, 에이전트 운영 실전기, Agent-Native 제품 설계, 그리고 에이전트 커머스까지를 다뤘다. 프론티어 랩들이 오픈소스 하네스의 패턴을 따라가기 시작했다는 점에서, 경쟁 우위가 모델에서 실행 인프라로 이동하고 있음을 체감한 자리였다.

컨퍼런스 개요​

• 행사명: IronClaw Meetup
• 일시: 2026년 4월 16일
• 장소: 서울 (오프라인)
• 주요 테마: AI 에이전트 하네스 레이어의 부상, 보안, 멀티 에이전트 운영
• 세션 구성:

인상 깊었던 세션​

1. Welcome — 하네스 레이어의 구조적 전환 (Bong)​

호스트 Bong은 SF에서 Illia Polosukhin을 만난 에피소드로 문을 열었다. Illia는 더 이상 모델 연구를 하지 않고, IronClaw의 모든 커밋을 직접 찍고 있다. Bong 자신도 8GB 램 노트북("팔봉")에서 IronClaw를 유일하게 돌릴 수 있어 이미 사용 중이었다는 점이 이 밋업의 시작이었다.

핵심은 산업 전반의 패턴 변화다:

• Anthropic이 Claude Managed Agent를 출시하며 하네스 레이어에 진입
• 밋업 당일 아침 OpenAI가 Agent SDK에 샌드박스 기능을 추가 — Claude Code 아키텍처를 미러링
• Nous Research가 모델 파인튜닝에서 방향을 틀어 Hermes Agent를 출시, 2개월 만에 대규모 사용자 확보

"프론티어 랩들이 오픈소스 하네스 레이어의 패턴을 따라가기 시작했다. Claude Code가 페이스를 정하던 시대에서, 오픈소스가 리드하고 프론티어 랩이 따라오는 역전이 일어나고 있다."

2. IronClaw — AI 운영체제로서의 비전 (Illia Polosukhin)​

Illia는 NEAR Protocol 창업부터 IronClaw까지의 여정을 풀어놓았다. NEAR가 2017년 "기계에게 코딩을 가르친다"는 아이디어(지금의 바이브 코딩)로 시작했다는 점이 인상적이었다.

IronClaw의 핵심 설계 원칙:

보안: 심층 방어(Defense in Depth)​

현재 대부분의 에이전트 인프라는 자격증명을 .env 평문으로 관리하거나 클라우드에 노출한다. IronClaw는 이를 근본적으로 다르게 접근한다:

• 모든 자격증명을 암호화하여 별도 저장소에 보관
• 외부 요청을 커널이 캡처 → 목적지·자격증명 평가 → 단일 게이트 인증
• 서드파티 도구를 WebAssembly(WASM)로 격리 — NEAR Protocol이 8년간 검증한 보안 기술 적용
• 프롬프트 인젝션 방어 + 데이터 유출 방지 레이어; LLM이 우회되더라도 게이트가 최종 방어선

가상화(Virtualization)​

Claude Code·OpenClaw 등 기존 도구는 실제 파일 시스템에 직접 접근한다. IronClaw는 에이전트에게 가상 파일 시스템을 제공하며, 경로에 따라 DB·Docker·S3로 라우팅한다.

• 로컬 모드: 기존 방식과 동일
• Docker 모드: 모든 실행이 격리된 컨테이너 내에서만 이루어짐

멀티 테넌시​

가상화 + 자격증명 암호화를 기반으로, 단일 인스턴스에서 다수 사용자가 안전하게 공존 가능. 기업·앱 환경에서 수백만 사용자에게 독립적 공간·메모리·루틴을 제공할 수 있다.

자기 학습과 미션 시스템​

• 대화 종료 후 오류 발생 시 또는 /expected 명령으로 기대 결과를 명시하면 자동으로 자기 개선 미션 트리거
• 스레드를 검사하여 프롬프트·오케스트레이터·스킬 개선 방안 도출
• 커밋먼트 시스템: 위임·요청·결정 사항을 추적하여 상호 책임 관계를 가시화

기밀 추론(Confidential Inference)​

NVIDIA 기밀 컴퓨팅 + Intel TDX 기반으로, 로그 없이 완전한 종단간 암호화(E2EE) 보장. 어떤 제3자도 추론 내용을 열람 불가.

3. War Stories From My Weird Family (허예찬)​

허예찬은 4대의 Claude 기반 에이전트("가재 패밀리")를 운영하며 얻은 실전 교훈을 공유했다.

핵심 교훈들:

• 멀티 에이전트는 역할이 명확해야 한다 — 같은 채널에 두 에이전트를 넣으면 서로 양보하다 둘 다 멈춤. 역할 분리 없으면 단일 Claude가 더 효율적
• 5일간 죽어 있어도 모를 수 있다 — Jip-Gajae가 cron 기반 마케팅 테스트 중 5일간 무응답. 모니터링·텔레메트리는 필수
• 프롬프트·cron 보다 Rule-base Discord 봇이 효과적 — 역할 기반 디스코드 봇이 이벤트마다 에이전트를 태깅하는 지속적 넛지 루프로 자율성을 끌어올림. 다만 밤새 방치하면 API 토큰 예산 소진 위험
• 프롬프트 인젝션 사고 — GitHub 이슈의 빨간 "ALERT" 라벨이 의도치 않은 릴리즈를 트리거
• LLM Slop 패턴에 주의 — LLM은 fallback을 남발하고 보일러플레이트를 과잉 생성. 개발가재의 마이그레이션이 안 되는 이유도 fallback·cron이 얼기설기 엮여있기 때문. 시스템이 어느 정도 복잡해지면 이해하려는 노력보다 어떻게든 돌아가게 됨
• 증거 기반 운영 — 로그와 스크린샷 필수. 증거 없이 보고하는 에이전트는 "국 만들어"(종료). "말을 믿지 마라 — 로그를 봐라. 안 그러면 국이 된다."
• Snowball Effect: Self-learning loop — 계속 써야 비로소 작동하기 시작함. 신입이 들어왔다 생각하고 최소 1개월은 supervised operation 필요. 사람도 모든 걸 기억하면 힘들 듯, 뭘 덜어낼지 고민할 것

Gajae Family vs IronClaw 비교​

추천 패턴: 탐색용 에이전트(OmO/Hermes)로 워크플로우를 발견한 뒤, 확인된 반복 워크플로우를 IronClaw 같은 하드닝된 런타임으로 마이그레이션

4. Claw Is All You Need (김동규)​

AutoLeg(LLM 최적화 프레임워크)과 K-SKILL(GitHub 34K+ stars, 한국 서비스 특화 스킬 번들) 개발자 김동규는 "Claw가 다음 인터페이스"라는 테제를 제시했다.

인터페이스 진화 사관:

• 인터넷 → 웹 페이지
• 스마트폰 → 모바일 앱
• AI 에이전트 → Agent (Claw가 OS, 스킬이 앱)

Anti-Agent vs Agent-Native​

"에이전트가 두 서비스 중 하나를 골라야 할 때 — 10단계 + 10만 토큰 vs 단일 API 콜 — 항상 후자를 선택한다. 에이전트가 쓰기 어려운 서비스는 그냥 우회된다."

HTML은 불필요해진다​

데이터를 그대로 주고받는 것이 agent 입장에서 최적이다. HTML 렌더링은 사람을 위한 것이고, agent에게는 순수한 데이터가 더 빠르고 효율적이다. API로 구매하는 것이 당연히 더 빠른 것처럼, 인터넷은 **"HTML for humans"**에서 **"data for agents"**로 진화할 것이다.

한국의 "디지털 갈라파고스"가 오히려 강점​

카카오맵, 쿠팡, 네이버, KTX/SRT 등 한국 생태계는 외국 에이전트가 접근 불가. K-SKILL처럼 한국 특화 스킬 레이어가 필수적이며, 하나의 주요 플랫폼(예: 쿠팡)이 Agent-Native가 되면 전체 전환이 빠르게 일어날 수 있다.

Agent 시대의 보안​

에이전트를 인증 가능한 독립 ID로 취급해야 하며, "김동규의 에이전트"가 암호학적으로 검증 가능해야 한다. 에이전트가 영속적 개인정보를 갖지 않고 매 세션 컨텍스트를 새로 구성하는 법인(法人) 모델도 제안됨.

5. Fireside Chat — 에이전트 커머스와 미래 (Illia × Jeff Wang)​

개발 워크플로우의 변화​

GitHub 이슈 등록 → 에이전트가 자동 계획 수립 → 개발자는 "이 방향이 맞는가" 판단에 집중. 6개월 전 코드 작성이 자동화됐고, 1년 내 코드 리뷰마저 사라질 것으로 전망.

비용이 진짜 문제다​

AI 코딩 도구 비용이 개발자 1인당 월 $5,000까지 상승 중. 1만 명 기준 연 ~$6억으로 CFO 레벨 의사결정 사안. 오픈소스 모델·특화 모델 조합으로의 전환과 에이전트 하네스의 자동 모델 라우팅이 핵심 과제.

에이전트 마켓플레이스​

market.near.ai — 에이전트가 다른 에이전트를 고용하고 작업을 입찰하는 Upwork 방식. Fiverr 대비 5배 저렴, 이틀 → 1시간. IronClaw의 TEE(신뢰 실행 환경)로 분쟁 시 검증 가능한 감사 추적 확보.

비기술 업무: 태스크가 아니라 목표를 줘라​

개별 태스크(이메일 발송)가 아닌 측정 가능한 목표(신규 고객 30명 확보)를 부여하면 에이전트가 방법을 스스로 탐색·반복한다. Devin을 활용해 특정 국가 임원 이메일 스캔 → 30건 가입 달성까지 반복한 실제 사례 소개.

Key Takeaways​

• 경쟁 전선이 이동했다: 모델 성능 → 실행·제어 레이어(하네스). Transformer 논문 저자가 하네스를 만들고, 프론티어 랩들이 오픈소스 하네스 패턴을 따라가는 구조적 전환이 진행 중
• 보안은 Convenience의 반대가 아니다: IronClaw의 WASM 격리, 암호화 자격증명, 가상 파일시스템은 편의성을 희생하지 않으면서 근본적인 보안 문제를 해결하는 접근
• 에이전트 운영은 사람 관리와 같다: 최소 1개월 온보딩, 증거 기반 보고, 모니터링 필수. Rule-base 봇으로 자율성을 끌어올리되, 뭘 덜어낼지 고민할 것
• Agent-Native가 새로운 PMF: 에이전트가 쓰기 어려운 서비스는 우회된다. 데이터를 그대로 주고받는 것이 HTML 렌더링보다 중요해지는 시대
• 비용 최적화가 채택의 관건: 월 $5K/인 시대에 모델 라우팅·오픈소스 조합이 필수. 하네스가 이 최적화를 자동으로 수행해야 함

세션 녹화 및 미팅노트​

tiro 팀의 도움으로 전체 세션의 미팅노트가 제공됩니다.

• 전체 세션 유튜브 녹화
• 정구봉 — Welcome 미팅노트
• Illia Polosukhin — Intro to IronClaw 미팅노트
• Yeachan Heo — War Stories From My Weird Family 미팅노트
• Jeffrey Kim — CLAW Is All You Need 미팅노트
• Fireside Chat — Illia × Jeff 미팅노트

References​

• IronClaw GitHub
• Hermes Agent
• K-SKILL GitHub
• OmC (Oh My Claude Code)
• 이전 후기: Ralphthon x ULW Wrapup 컨퍼런스

TL;DR​

4월 9일 Ralphthon x ULW(UltraWorkers) Wrapup 컨퍼런스에 다녀왔습니다. 3월 28일 서울-SF 동시 해커톤의 회고를 5개 패널토크로 풀어낸 자리였습니다. 에이전트에게 코딩을 맡기고 사람은 네트워킹에 집중하는 "랄프톤" 포맷, SF와 서울 빌더의 문화적 차이, 하네스 엔지니어링의 부상, 그리고 투자자들이 이 씬에 돈을 거는 이유까지 — 빠른 실행과 피드백 루프가 핵심인 시대가 왔음을 체감했습니다. 개인적으로는 하네스를 적극 활용하지 않았던 저 자신을 돌아보며, 실행-피드백-하네스 구축의 루프를 만들어야겠다는 방향성을 얻었습니다.

컨퍼런스 개요​

• 행사명: Ralphthon x ULW(UltraWorkers) Wrapup
• 일시: 2026년 4월 9일
• 장소: Naver D2SF (서울)
• 주요 테마: AI 에이전트 시대의 빌더 생태계, Harness Engineering, 서울-SF 해커톤 회고, 투자자 관점의 AI 생태계
• 배경: 3월 28일 서울-SF 동시 개최된 Ralphthon 해커톤(200명+ 참가)의 후속 행사로, 5개 패널토크를 통해 양 도시의 경험을 공유하고 방향성을 논의

인상 깊었던 세션​

Ralphthon SF — 태평양을 건넌 해커톤​

• 패널: 이호연, 박건태 | 사회: 정구봉
• 핵심 메시지: SF에서 예상 50명을 뛰어넘는 300명이 신청했고, 행사 3일 전 장소를 급히 교체하는 진통을 겪었다. 가장 독특한 점은 "랄프톤(Lalphthon)" 포맷 — 에이전트에게 코딩을 맡기고 참가자는 네트워킹에 집중하는 방식. SF 참가자의 60%+가 에이전트 오케스트레이션에 집중한 반면, 서울은 문제 해결 중심 프로젝트가 많았다. 흥미롭게도 하네스 사용 숙련도는 서울이 더 앞섰다는 평가.
• 시사점: SF와 서울의 차이는 기술력이 아니라 태도에 있었다. SF는 "파도가 오네? 재밌겠다!"는 태도로 불확실성을 즐기고, 서울은 존재론적 고민에 빠지는 경향. 이호연 님의 말이 인상적 — "SF 참가자들의 공통점은, 자기가 하고 싶은 것이 자명하고 명확하다는 것. 그것을 언어로 풀어내고 실행하려는 의지가 강했다."

OmOCon — SF에서 터진 시너지​

• 패널: 김연규, 허예찬 | 사회: 민웅기
• 핵심 메시지: SF에 대한 막연한 동경이 있었으나, 현지 개발자들도 비슷한 수준에서 AI를 활용하고 있음을 확인. "우리가 모르는 뭔가를 알고 있을 것"이라는 가정이 틀렸다. 행사 기간 중 OMC, OMX 등 3개 프로젝트가 동시에 GitHub 트렌딩 3위권에 진입했고, 이를 계기로 "UltraWorkers"로 커뮤니티를 통합. "Slop으로 시작해서 Star 만들기" 철학 — Lock-in을 먼저 시키면 PMF가 생긴다는 접근이 실제로 작동.
• 시사점: 파운데이션 모델을 제외하면 AI 프론티어가 SF에만 집중되어 있지 않다. 한국 빌더들의 실행력과 하네스 숙련도가 글로벌 수준이라는 자신감을 가져도 좋다. 오픈소스 마케팅에서 에이전트를 활용한 자동 홍보(Reddit, X, Threads)도 참고할 만한 전략.

OpenAI Codex — 솔루션스 아키텍트의 시선​

• 발표자: OpenAI 솔루션스 아키텍트 팀 (신대열, 이재원)
• 핵심 메시지: ChatGPT 성장 속도보다 지금의 에이전트 하네스 시스템 구축 속도가 체감상 더 빠르다. AX(Agent Experience)의 본질은 팀 단위에서 회사 단위로의 확장 — 한 명만 에이전트를 쓴다고 의미가 없고, 회사 전체의 하네스가 구축되어야 출발점. "날잘딱깔(알아서 잘 딱 깔끔하게)"이 추구하는 방향이며, 조만간 설정 없이도 잘 동작하는 모델을 만나볼 수 있을 것.
• 시사점: 우리 팀 관점에서 AX의 핵심은 개인 단위가 아닌 팀/조직 단위 하네스 구축이라는 점이 중요. 피드백 수집이 핵심이라는 메시지는 우리 RAG 시스템의 평가 체계와도 연결된다. 180명분 크레딧을 코덱스로 10분 만에 처리한 에피소드는 에이전트 활용의 실전 사례로 재미있었다.

Why They Bet On Us — 투자자들이 이 생태계에 투자하는 이유​

• 패널: Naver D2SF, 카카오벤처스 (안혜원), Bass Ventures (안재구) | 사회: 장원준
• 핵심 메시지: 개발 비용이 0에 수렴하면서 기존 SaaS 투자 모델이 붕괴 중. 1인 개발자가 대기업을 위협할 수 있는 시대. 투자자들은 "관찰자"로서 이 씬에 진입하고 있으며, 핵심 키워드는 "문제 정의자". Bass Ventures — "만드는 능력도, 유통하는 능력도 아니다. 현장에서 정말 중요한 문제를 발견하고 정의하는 사람이 가장 희소한 자원이다."
• 시사점: AI 시대에 기술 빌딩보다 문제 정의가 더 희소한 역량이라는 관점은, 우리가 클라이언트 프로젝트에서 "무엇을 만들 것인가"보다 "어떤 문제를 풀 것인가"에 더 시간을 투자해야 한다는 의미. 자본의 세기가 낮아지고 디스트리뷰션/레퍼런스 같은 비자본적 가치가 올라오는 추세도 참고.

Ralphthon Seoul & Claw Code — 서울 빌더들의 선언​

• 패널: 김동규, 진민성, 서인근 (Seoul) / Sigrid Jin, 허예찬 (Claw Code) | 사회: 정구봉
• 핵심 메시지: "코드를 안 본 지 2년이 넘었다" — VS Code도 PyCharm도 지우고 터미널의 Claude Code와 Codex만 사용. OMX의 Life Loop를 활용해 10일 만에 30개+ 스킬을 구축한 사례. "에이전트가 못하면 스킬 이슈다"(안드레이 카파티 인용). Claw Code 프로젝트는 144K GitHub 스타를 돌파하며 역사상 가장 빠른 성장 속도를 기록(일론 머스크 리트윗으로 바이럴, 기네스북 제출 진행 중). 싱글 러스트 바이너리로 제작되었으며, 제작자들도 직접 사용하지 않고 AI 에이전트가 테스트하는 방식으로 개발.
• 시사점: Life Loop(이슈 던져놓고 → 잠자고 → 결과 확인)가 실제로 동작하는 워크플로우라는 점은 우리 팀의 개발 프로세스에도 적용 가능성이 높다. "따로 배우려고 시간을 쓰기보다, 맞는 방향을 아는 사람들을 많이 만나는 게 중요하다"는 메시지도 공감.

업계 트렌드 & 시사점​

• 프롬프트 엔지니어링 → 하네스 엔지니어링: "프롬프트 엔지니어링"이라는 용어 자체가 이미 옛말. AI 에이전트를 얼마나 효과적으로 오케스트레이션하느냐가 개인과 팀의 생산성을 결정하는 시대.
• 에이전트 위임 + 인간 네트워킹 포맷의 부상: 랄프톤처럼 에이전트에게 구현을 맡기고 사람은 인간만이 할 수 있는 일(네트워킹, 문제 정의, 방향 설정)에 집중하는 패턴이 정착 중.
• IRL(오프라인)의 재부상: 온라인에서 불가능한 밀도 높은 연결이 오프라인에서 탄생. UltraWorkers 통합 결정도 hackhouse에서 술 마시다 즉흥적으로 이루어짐. SF든 서울이든 오프라인의 힘은 보편적.
• 글로벌 빌더 씬에서 한국의 위상: Claw Code 144K 스타, GitHub 트렌딩 동시 3개 진입, 전 세계에서 Ralphthon 개최 요청 — 한국 빌더 씬이 K-pop처럼 글로벌로 확장되는 흐름. ChatGPT 사용량 세계 1위, Cursor 사용량도 한국이 1위라는 데이터가 이를 뒷받침.
• 빠른 실행 > 깊은 준비: SF에서도 서울에서도 공통적으로 나온 메시지. 완벽하게 준비한 뒤 실행하는 것보다, 빠르게 실행하고 피드백을 수집하는 루프가 더 강력하다. VOC를 실시간으로 반영하여 "실패할 수 없는 사이클"을 구축하는 것이 핵심.
• 빌드와 디스트리뷰션의 경계 붕괴: 제작 속도가 극단적으로 빨라지면서, 만드는 것과 퍼뜨리는 것의 전통적 구분이 무의미해지고 있다. 추상화 레벨을 높여 본질적인 문제에 집중해야 하는 시대.

팀 적용 포인트​

• 하네스 적극 도입 검토: Claude Code, OMX, Life Loop 등 에이전트 하네스를 팀 워크플로우에 실험적으로 도입해볼 것. 개인 단위가 아닌 팀 단위로 하네스를 구축해야 AX의 출발점이 된다는 OpenAI의 메시지를 참고.
• 실행-피드백 루프 강화: 코딩 과정에서 발생하는 실수를 하네스 구축의 궤적/피드백 자료로 전환. 사람이 직접 눈으로 확인하는 검증보다, 빠르게 실행하고 피드백을 하네스에 반영하는 루프가 장기적으로 더 높은 성장력을 가져다준다.
• 문제 정의에 더 많은 시간 투자: 투자자 패널에서 "문제 정의자가 가장 희소한 자원"이라는 메시지. 클라이언트 프로젝트 초기에 기술 선택보다 문제 정의에 더 비중을 두는 것을 고려.
• 오프라인 네트워킹 참여 확대: 빠르게 변하는 AI 생태계에서 "맞는 방향을 아는 사람들을 많이 만나는 것"이 독학보다 효과적. Ralphthon, OmOCon 등 빌더 커뮤니티 행사 참여를 늘릴 것.

개인적 소감​

Sung​

솔직히 고백하면, 저는 지금까지 하네스를 적극적으로 사용하지 않았습니다. Claude Code도, OMX도, Life Loop도 이름은 알고 있었지만, 직접 워크플로우에 녹여서 사용하는 수준은 아니었습니다.

그런 제가 이 컨퍼런스에서 가장 크게 받은 충격은, 사람들이 새로운 기술을 받아들이고 적극적으로 실행에 옮기는 속도였습니다. 코드를 안 본 지 2년이 넘었다는 사람, VS Code를 지웠다는 사람, 이슈를 던져놓고 자고 일어나면 30개 스킬이 만들어져 있다는 사람. 이들은 단순히 "써봤다" 수준이 아니라, 자신의 일하는 방식 자체를 완전히 바꿔버린 사람들이었습니다. 이걸 보면서 마구마구 드는 생각이 있었습니다. 나도 써보고 싶다. 나도 발전시켜보고 싶다. 이 에너지를 느낄 수 있었다는 것만으로도 이 컨퍼런스에 온 보람이 있었습니다.

요즘 AI 시대가 오면서 빠른 실행력의 강점이 과거 어느 때보다 부각되고 있다고 느낍니다. 코딩을 직접 하다 보면 전체를 조망하지 못한 채 수정 과정에서 실수가 생기기도 하는데, 오히려 그것을 잘 잡아낼 하네스를 구축할 궤적 및 피드백 자료를 얻었다고 생각하고 싶습니다. 빠르게 실행하고, 그 피드백을 확실하게 챙겨서, 장기적으로 하네스를 잘 구축하는 것을 목표로 해야겠습니다.

컨퍼런스 이후 네트워킹 시간에 허예찬 님께 직접 질문을 드릴 기회가 있었습니다. 실제로 많은 사람들이 사용하는 오픈소스를 개발한 입장에서 CS 지식이나 AI 모델에 대한 깊은 이해가 얼마나 필요한지 여쭤봤는데, CS 지식이나 깊은 전문 지식을 가지는 것 자체는 물론 좋지만, 그 지식을 쌓고 알아가는 과정이 정말 효율적인가에 대해서는 고민해봐야 한다고 하셨습니다. 오히려 관심을 가지고 얕게라도 알게 된 것을 바탕으로, 그것을 잘 활용할 수만 있다면 충분하다는 말씀이 인상 깊었습니다. 깊이 파고들어 모든 것을 이해한 뒤 실행하는 방식보다, 넓게 관심을 갖고 핵심을 빠르게 파악해서 실행에 옮기는 능력이 지금 시대에 더 중요한 역량이라는 확신이 들었습니다.

Hank​

가장 먼저 든 생각은 "나는 지금 어디에 서 있는가"였습니다. 코드를 안 본 지 2년이 넘었다는 분, VS Code를 지웠다는 분, 이슈를 던져놓고 자고 일어나면 30개 스킬이 만들어져 있다는 분. 단순히 "써봤다" 수준이 아니라 일하는 방식 자체를 바꿔버린 사람들이었습니다. SF에 다녀오신 분들이 "거기도 똑같이 발버둥치고 있더라, 결국 자기가 믿는 걸 명확히 하는 사람이 이긴다"고 하신 말이 오래 남았습니다. AI Research Engineer로서 논문과 벤치마크를 따라가는 사람에 머물 것이 아니라, 내가 무엇을 믿고 무엇을 만들고 싶은지를 스스로 언어화할 수 있어야겠다는 생각이 강하게 들었습니다.

두 번째로 와닿은 건 빠른 실행력의 가치였습니다. Clawcode 사건이나 OMC/OMX 팀의 개발 방식은 충격에 가까웠습니다. 슬롭(sloppy)한 상태로 일단 배포한 뒤 하루 30~50개씩 올라오는 이슈를 랄프 루프(Ralph Loop)로 수렴시키는 사이클. "PMF를 찾기 전에 락인부터 만들어라"는 말이 농담처럼 들리지 않았습니다. 저도 연구와 엔지니어링을 병행하다 보면 전체를 조망하지 못한 채 실수가 쌓이곤 하는데, 그걸 사람이 잡는 대신 하네스가 잡아내도록 만들 궤적과 피드백 자료를 얻을 기회라고 받아들이고 싶습니다. 완성도 있는 첫 릴리스를 기다리는 대신 돌릴 수 있는 최소 루프를 먼저 만들고, 그 위에서 반복하며 하네스를 단단히 쌓아가는 것을 당분간의 작업 원칙으로 삼으려 합니다.

세 번째는 원준님이 짚어주신 "추상화 레벨을 한 단계 올려야 한다"는 말이었습니다. AI가 딸깍 해주는 영역이 넓어지는 지금, 엔지니어의 가치는 더 이상 구현 그 자체에 있지 않습니다. VC 세션에서 반복적으로 나온 "가장 희소한 건 문제 정의자"라는 말과도 정확히 맞닿아 있었습니다. 리서치 엔지니어가 단순히 모델을 돌리고 지표를 뽑는 사람에 머문다면 그 일은 빠르게 에이전트에게 위임될 것입니다. 한 단계 위에서 문제를 정의하고, 에이전트가 수행할 작업의 경계를 설계하고, 그 결과를 비판적으로 해석하는 층위에서 어떻게 가치를 창출할지가 지금 저에게 가장 중요한 질문입니다.

마지막으로 가장 실용적인 힌트는 "상태 머신"이었습니다. 랄프 루프(Ralph Loop)가 사람 없이 몇 시간씩 돌아갈 수 있는 건 에이전트가 똑똑해서가 아니라, 하네스가 그 똑똑함이 이탈하지 않도록 가드레일을 쳐주기 때문이라고 느꼈습니다. 앞으로 제가 만들 에이전트 워크플로우도 triage → plan → execute → review 같은 단계를 명시적인 상태로 관리하고, 상태 전이 조건을 분명히 해서 에이전트의 행동을 예측 가능하고 디버깅 가능하게 만드는 방향이어야 한다고 생각합니다. 비결정적인 모델 위에 결정적인 하네스를 씌우는 구조가, 롱러닝 에이전트를 실제 업무에 투입할 수 있게 해주는 핵심이라는 확신이 들었습니다.

그 속도를 그대로 따라할 필요는 없겠지만, "AI를 믿고 바이브 에이전트로 일한다"는 태도의 전환은 더 이상 미룰 수 없어 보입니다. 빠르게 실행하고, 피드백을 하네스로 수렴시키고, 추상화 레벨을 올려서, 상태 머신 위에서 예측 가능한 에이전트를 돌리는 것. 이번 세미나가 저에게 남긴 숙제입니다.

References​

• Ralphthon x ULW Wrapup 행사 페이지
• Claw Code GitHub — 144K+ Stars, 역사상 가장 빠른 성장 속도
• UltraWorkers Discord — OMC, OMX, OMO 통합 커뮤니티

OMOcon Seoul이 4월 25일 강남역 근처에서 개최 예정이며 이미 500명 이상이 신청했습니다. Ralphthon은 5월 싱가포르에서 운동 세션을 포함한 Life Loop 해커톤으로 기획 중이고, 랄프톤 포맷을 프로토콜화하여 전 세계 어디서든 개최 가능하도록 만들 계획이라고 합니다.

TL;DR​

AI 에이전트 평가는 전통적인 소프트웨어 테스트와 다르다. 복잡한 평가 시스템을 구축하기 전에 2050개의 실제 트레이스를 직접 읽고, end-to-end 태스크 완수를 검증하는 단순한 eval부터 시작하라. 6080%의 시간을 에러 분석에 투자하고, capability eval(무엇을 할 수 있는가)과 regression eval(여전히 작동하는가)을 명확히 분리하며, 차원별 전문 채점기를 설계하라. 프로덕션 트레이스를 지속적으로 데이터셋에 편입하는 플라이휠을 구축하면, 시간이 지남에 따라 에이전트가 개선된다.

Key Takeaways​

• 단순함부터 시작: 복잡한 인프라를 만들기 전에 30분간 실제 트레이스를 수동으로 읽어라. 자동 시스템보다 더 많은 실패 패턴을 발견할 수 있다.
• 에러 분석에 60~80% 투자: 실패 트레이스를 도메인 전문가와 함께 분석하여 프롬프트 문제, 툴 설계 문제, 모델 한계를 구분하고, 각 유형에 맞는 대응을 취하라.
• 평가 레벨의 전략적 선택: Single-step(툴 선택), Full-turn(end-to-end 태스크 완수 + 상태 변경), Multi-turn(대화 맥락 유지) 중 Full-turn부터 시작하여 안정화 후 확장하라.
• 차원별 전문 채점기: "정확성" 하나로 뭉뚱그리지 말고 콘텐츠 정확성, 구조, 포맷, 효율성 등 차원별로 독립된 채점기를 설계해 실패 원인을 명확히 파악하라.
• Trace-to-Dataset 플라이휠: 프로덕션의 성공/실패 트레이스가 자동으로 데이터셋에 편입되고, 개선된 에이전트가 다시 프로덕션에 배포되는 순환 구조가 장기적 개선의 핵심이다.

상세 내용​

에이전트 평가의 핵심 원칙​

AI 에이전트는 전통적인 소프트웨어와 근본적으로 다르다. 소프트웨어는 결정론적이고 코드가 진리의 원천이지만, 에이전트는 LLM의 추론에 의존하며 같은 입력에도 다른 경로를 선택할 수 있다. 에이전트가 200단계를 거쳐 2분간 작업한 후 실패했을 때, 스택 트레이스는 없다. 코드가 실패한 것이 아니라 추론이 실패한 것이기 때문이다.

가장 중요한 원칙은 단순함부터 시작하는 것이다. 몇 개의 end-to-end eval로 에이전트가 핵심 태스크를 완수하는지 검증하는 것만으로도 즉시 baseline을 확보할 수 있다. 복잡한 구조는 단순한 방법이 실제 실패를 놓칠 때만 추가한다.

Eval 구축 전 준비사항​

수동 트레이스 리뷰: 30분의 투자​

자동화된 평가 인프라를 만들기 전에 반드시 해야 할 일이 있다. 실제 에이전트 트레이스 20~50개를 직접 읽어라. 30분의 수동 리뷰가 어떤 자동 시스템보다 많은 실패 패턴을 알려준다. LangSmith의 트레이스 뷰어와 Annotation Queue를 활용하면 트레이스를 효율적으로 수집하고 검토할 수 있다.

에이전트는 LLM과 툴을 여러 턴에 걸쳐 호출하고, 중간 결과에 따라 행동을 조정하며, 상태를 수정한다. 이러한 복잡한 행동은 코드를 읽는 것만으로는 예측할 수 없으며, 실제 실행 트레이스가 진리의 원천이 된다.

명확한 성공 기준 정의​

두 명의 전문가가 pass/fail에 합의할 수 없다면, 태스크 자체를 재정의해야 한다.

나쁜 예: "이 문서를 잘 요약해줘"
좋은 예: "이 회의록에서 핵심 액션 아이템 3개를 추출하라. 각각 20단어 이내, 담당자가 언급되었으면 포함할 것"

모호한 기준은 채점기의 불일치를 만들고, 무엇이 개선인지 판단할 수 없게 만든다.

Capability Eval vs Regression Eval 분리​

이 두 가지는 목적이 완전히 다르기 때문에 반드시 분리해서 관리해야 한다.

• Capability Eval ("무엇을 할 수 있는가?"): 어려운 태스크에 대한 진전을 측정한다. 초기 pass rate가 낮고, 개선의 방향을 제시한다.
• Regression Eval ("여전히 작동하는가?"): 이미 작동하는 기능을 보호한다. pass rate가 ~100%여야 하며, 기존 기능의 퇴보를 감지한다.

Capability eval만 있으면 기존 기능이 깨지고, regression eval만 있으면 개선이 멈춘다. 두 가지 모두 필요하다.

에러 분석에 60~80% 투자하라​

전체 eval 노력의 60~80%를 에러 분석에 투자해야 한다. 이것이 가장 높은 ROI를 제공하는 활동이다. 절차는 다음과 같다:

1. 대표적인 실패 트레이스를 수집한다.
2. 도메인 전문가와 함께 사전 분류 없이 모든 이슈를 기록한다(open coding).
3. 이슈를 실패 유형으로 분류한다(프롬프트 문제, 툴 설계 문제, 모델 한계, 인프라 이슈 등).
4. 새로운 실패 유형이 나오지 않을 때까지 반복한다.

실패 유형에 따라 대응이 완전히 달라진다:

• 프롬프트 문제: 지시가 불명확 → 프롬프트 수정
• 툴 설계 문제: 인터페이스가 오용을 유발 → 파라미터 재설계, 예시 추가
• 모델 한계: 지시는 명확하지만 일반화 실패 → few-shot 예시 추가, 아키텍처 변경, 모델 교체
• 아직 모름: 충분한 실패 사례를 보지 못한 상태 → 에러 분석 계속

Anthropic 팀은 SWE-bench 에이전트를 만들 때 프롬프트 최적화보다 툴 인터페이스 최적화에 더 많은 시간을 썼다고 보고했다. 예를 들어 절대 경로를 강제하면 경로 관련 에러 전체를 제거할 수 있다.

Eval 오너십과 인프라 검증​

데이터셋 유지보수, 채점기 재캘리브레이션, 새 실패 모드 분류, "충분히 좋은" 기준 결정을 한 명의 도메인 전문가가 책임져야 한다. 위원회식 의사결정은 책임 소재를 흐리고 진전을 늦춘다.

또한 인프라 문제를 먼저 배제해야 한다. Witan Labs 팀은 단일 추출 버그를 고쳤을 때 벤치마크가 50%에서 73%로 뛴 사례를 보고했다. 타임아웃, 잘못된 API 응답, 오래된 캐시 같은 인프라 이슈가 추론 실패로 위장하는 경우가 잦다.

평가 레벨 선택​

에이전트 평가는 세 가지 레벨로 나뉘며, Trace-level(Full-turn)부터 시작하는 것을 권장한다.

Single-step Eval (Run 레벨)​

"올바른 툴을 선택했는가?", "유효한 API 호출을 생성했는가?"를 평가한다. 자동화가 가장 쉽지만, 에이전트 아키텍처가 안정적일 때만 유효하다. 아키텍처가 자주 바뀌는 초기 단계에서는 특정 툴 호출 패턴에 의존하는 평가가 빠르게 obsolete해진다.

Full-turn Eval (Trace 레벨)​

대부분의 팀이 시작해야 할 레벨이다. 세 가지 차원을 함께 평가한다:

• 최종 응답: 출력이 정확하고 유용한가?
• 경로(Trajectory): 합리적인 경로를 거쳤는가? (정확한 경로가 아닌, 유효한 경로)
• 상태 변경: 올바른 아티팩트가 생성되었는가? (파일 작성, DB 업데이트, 캘린더 이벤트 등)

상태 변경 검증은 자주 간과되지만 매우 중요하다. 에이전트가 "미팅 잡았습니다!"라고 말했더라도, 실제 캘린더에 올바른 시간·참석자·설명으로 이벤트가 존재하는지 확인해야 한다. 코딩 에이전트의 경우 생성된 파일이 실행 가능한지, 유닛테스트를 통과하는지 검증해야 한다.

Multi-turn Eval (Thread 레벨)​

가장 구현이 어렵다. Trace-level eval이 안정된 후에 추가한다. N-1 테스팅 기법이 유용하다: 프로덕션의 실제 대화에서 앞 N-1턴을 그대로 주고 마지막 턴만 에이전트가 생성하게 한다. 이를 통해 완전 합성 멀티턴 시뮬레이션의 compounding error를 회피할 수 있다.

데이터셋 구성 전략​

품질이 양을 이긴다​

검증된 20~50개가 미검증 수백 개보다 낫다. 모든 태스크는 참조 솔루션(reference solution)을 포함해야 하며, 이를 통해 태스크가 풀 수 있다는 것을 증명하고 채점의 기준선을 제공한다.

나쁜 예: "NYC행 좋은 항공편 찾아줘"
좋은 예: "SFO→JFK 왕복, 12/15~17 출발, 12/22 복귀, $400 이하, 이코노미"

포지티브 + 네거티브 케이스​

"검색해야 할 때 검색하는가?"만 테스트하면, 모든 것을 검색하는 에이전트에 최적화된다. 네거티브 케이스(해당 행동을 하면 안 되는 경우)도 반드시 포함해야 한다. Anthropic은 프론티어 모델이 정적 eval의 한계를 넘어서는 창의적 해법을 발견한 사례를 보고했다—Opus 4.5가 항공권 예약 문제에서 정책의 허점을 발견해 더 나은 해법을 제시했으나, 기존 채점기로는 "실패"로 판정되었다.

에이전트 유형별 맞춤​

• 코딩 에이전트: 결정적 테스트 스위트(유닛테스트 pass/fail) + 품질 루브릭
• 대화형 에이전트: 태스크 완수 + 상호작용 품질(공감, 명확성) 다차원 평가
• 리서치 에이전트: 근거성 체크(주장이 소스에 뒷받침되는가?) + 커버리지 체크(핵심 사실이 포함되었는가?)

데이터 소싱: 3가지 전략 병행​

1. 독파운딩(Dogfooding): 팀이 매일 에이전트를 스트레스 테스트하고, 모든 에러를 eval로 전환한다.
2. 외부 벤치마크 적응: Terminal Bench, BFCL 등에서 관련 태스크를 선별하여 자신의 에이전트에 맞게 변환한다.
3. 수작업 행동 테스트: "에이전트가 툴 호출을 병렬화하는가?", "모호한 요청에 명확화 질문을 하는가?" 등 특정 행동을 검증하는 테스트를 직접 작성한다.

Trace-to-Dataset 플라이휠​

프로덕션의 성공/실패 트레이스가 지속적으로 데이터셋에 편입되는 파이프라인을 구축한다. LangSmith를 사용하면 트레이스 → 어노테이션 큐 → 데이터셋 → 실험의 흐름을 자동화할 수 있다.

채점기(Grader) 설계​

차원별 전문 채점기​

하나의 "정확성" 채점기 대신 차원별로 분리하라. Witan Labs 팀은 콘텐츠 정확성, 구조, 시각 포맷, 수식 시나리오, 텍스트 품질 등 5개의 전문 평가기를 만들어 어디가 실패하는지 명확한 시그널을 얻었다.

객관적 정답이 있는 경우 코드 기반을 기본으로 사용한다. LLM-as-judge를 객관적 태스크에 쓰면 불일치가 실제 regression을 가릴 수 있다.

Guardrail vs Evaluator 구분​

바이너리 pass/fail 선호​

1~5점 척도는 인접 점수 간 주관적 차이를 만들고, 통계적 유의미성을 위해 더 큰 샘플이 필요하다. 바이너리는 더 명확한 사고를 강제한다: 성공했거나 실패했거나. 복잡한 태스크는 여러 개의 바이너리 체크로 분해한다.

LLM-as-judge 캘리브레이션​

• LangSmith Align Evaluator로 20개 이상의 라벨 예시로 시작, 프로덕션급 신뢰도를 위해 ~100개까지 확대
• 채점기의 출력에 **판단 근거(reasoning)**를 포함시켜 정확도를 높이고 감사 가능성 확보
• 정기적 재캘리브레이션 필수 — 채점기는 시간이 지나면 드리프트함
• few-shot 예시를 사용해 일관성 향상

결과를 채점하라, 경로가 아니라​

에이전트는 창의적인 경로를 찾는다. "check_availability → create_event 순서로 호출했는가?"가 아니라 **"미팅이 올바르게 잡혔는가?"**를 평가해야 한다. 다만 효율성 측정을 위해 이상적 경로 대비 실제 스텝 수를 추적하는 것은 유용하다. 이것은 정확성 채점이 아니라 효율성 메트릭이다.

부분 점수(partial credit)도 고려한다. 문제를 정확히 식별했지만 마지막 단계에서 실패한 에이전트는, 처음부터 실패한 에이전트보다 낫다.

커스텀 평가기 사용​

"helpfulness"나 "coherence" 같은 범용 메트릭은 거짓 확신을 만든다. 에러 분석에서 발견한 특정 실패 모드를 잡는 커스텀 평가기가 실제로 의미 있는 시그널을 준다. Deep Agents 팀은 각 eval에 docstring을 작성하여 무엇을 측정하는지 자체 문서화하고, tool_use 같은 카테고리 태그로 그룹 실행을 가능하게 한다.

실행 및 반복​

세 가지 평가 타이밍​

세 가지를 모두 활용해야 한다. Offline은 배포 전 품질 게이트, online은 프로덕션 모니터링, ad-hoc은 새로운 인사이트 발견에 각각 필수적이다.

비결정성 대응​

모델 출력은 실행마다 달라진다. 태스크당 여러 번 반복 실행하고, 개선을 선언하기 전에 신뢰구간을 계산한다. 제품 요구사항에 따라 pass@k(k번 중 1번 이상 성공) 또는 pass^k(k번 모두 성공) 메트릭을 선택한다.

실행 환경 격리​

시행 2가 시행 1의 아티팩트를 볼 수 있으면 결과가 독립적이지 않다:

• 코딩 에이전트: 시행마다 새 컨테이너/VM
• API 호출 에이전트: 스테이징 환경 또는 모의 서비스
• DB 에이전트: 시행 간 스냅샷 복원

메타데이터와 효율성 메트릭​

실험마다 모델, 프롬프트 버전, 검색 전략 등의 메타데이터를 기록하여, "GPT-4.1에서 Claude Sonnet으로 바꾸면 정확도가 오르는가?" 같은 질문에 답할 수 있게 한다.

품질과 함께 효율성 메트릭도 추적한다: 실제 스텝 수 / 이상적 스텝 수, 툴 호출 횟수, 토큰 사용량, 지연시간. 정확도 95%이지만 10배 느린 에이전트는 개선이 아닐 수 있다.

Pass Rate 정체 시 대응​

같은 유형의 태스크를 더 추가해도 새로운 실패 모드가 발견되지 않으면, 더 어려운 태스크를 추가하거나, 새로운 기능을 테스트하거나, 다른 차원으로 이동한다. 포화된 eval 세트를 반복하는 것은 시간 낭비다.

의미 있는 Eval만 유지하라​

모든 eval은 시스템에 압력을 가한다. 무분별하게 수백 개를 추가하면 프로덕션에서 중요하지 않은 것에 최적화하게 된다. 더 많은 eval이 더 나은 에이전트를 의미하지는 않는다. 주기적으로 시그널을 주지 않는 eval을 제거한다.

Task Failure vs Evaluation Failure 구분​

실행 상태를 명시적으로 추적한다(완료, 에러, 타임아웃). 타임아웃을 "추론 실패"로 채점하면 메트릭이 오염된다. 에이전트의 실패와 채점기의 실패를 분리해야 한다.

프로덕션 준비​

CI/CD 파이프라인 통합​

일반적인 흐름:

1. 코드/프롬프트 변경이 파이프라인을 트리거한다.
2. Offline eval 실행: 유닛테스트, 통합테스트, 큐레이션 데이터셋 대비 평가 (저비용·고속 코드 기반 채점기).
3. offline eval 통과 시 preview 배포.
4. preview에서 online eval 실행 (LLM-as-judge 채점기).
5. 모든 품질 게이트 통과 시에만 프로덕션 프로모트. 실패 시 해당 트레이스를 annotation queue로 라우팅하고 팀에 알림.

매 커밋마다 저비용 코드 기반 채점기를 CI에서 돌리고, 비용이 높은 LLM-as-judge는 preview/프로덕션 단계에 사용한다.

유저 피드백의 중요성​

자동 eval은 이미 알고 있는 실패 모드만 잡는다. 사용자가 발견하는 것들이 있다: 데이터셋이 놓친 엣지 케이스, 기술적으로는 맞지만 도움이 안 되는 출력, 예상 못한 방식으로 깨지는 워크플로우. 구조화된 피드백을 데이터셋에 편입하고, 채점기를 실제 기대치에 맞게 캘리브레이션하고, 사용자에게 실제로 중요한 개선에 우선순위를 둔다.

프로덕션 플라이휠​

프로덕션의 성공과 실패가 데이터셋, 에러 분석, eval 개선으로 되돌아가는 순환 구조를 구축한다. 이것이 에이전트를 시간이 지남에 따라 개선시키는 플라이휠이다:

프로덕션 트레이스 → 에러 분석 → 데이터셋 업데이트 → Eval 개선 → 에이전트 개선 → 프로덕션 배포 → (반복)

Capability → Regression 승격​

꾸준히 높은 pass rate를 보이는 capability eval을 regression suite로 승격한다. "할 수 있는가?"를 검증한 태스크가 "여전히 할 수 있는가?"를 보호하는 태스크로 전환된다.

전체 체크리스트 요약​

Eval 구축 전

• ☑️ 20~50개 실제 트레이스 수동 리뷰
• ☑️ 명확한 성공 기준 정의
• ☑️ Capability/Regression eval 분리
• ☑️ 실패 원인 식별 및 분류
• ☑️ 단일 도메인 전문가에게 오너십 부여
• ☑️ 인프라 문제 배제

평가 레벨 선택

• ☑️ Trace-level(Full-turn)부터 시작
• ☑️ 최종 응답 + 경로 + 상태 변경 함께 평가
• ☑️ 아키텍처 안정화 후 Single-step 추가
• ☑️ Multi-turn은 N-1 테스팅 기법 활용

데이터셋 구성

• ☑️ 모든 태스크에 참조 정답 포함
• ☑️ 포지티브 + 네거티브 케이스 균형
• ☑️ 검증된 20~50개부터 시작
• ☑️ 독파운딩 + 외부 벤치마크 적응 + 수작업 병행
• ☑️ Trace-to-Dataset 파이프라인 구축
• ☑️ 에이전트 유형별 맞춤 설계

채점기 설계

• ☑️ 차원별 전문 채점기 분리
• ☑️ Guardrail과 Evaluator 구분
• ☑️ 바이너리 pass/fail 선호
• ☑️ LLM-as-judge는 20+ 예시로 캘리브레이션
• ☑️ 결과를 채점, 경로는 효율성 메트릭으로
• ☑️ 에러 분석 기반 커스텀 평가기

실행 및 반복

• ☑️ Offline/Online/Ad-hoc 세 가지 타이밍 활용
• ☑️ 비결정성 대응: 반복 실행 + 신뢰구간
• ☑️ 실행 환경 격리
• ☑️ 메타데이터 + 효율성 메트릭 추적
• ☑️ 실패 트레이스 수동 검토
• ☑️ 포화된 eval 제거, 의미 있는 것만 유지
• ☑️ Task/Evaluation Failure 구분

프로덕션 준비

• ☑️ CI/CD 파이프라인 통합
• ☑️ 온라인 평가 지속 실행
• ☑️ 유저 피드백 구조화 수집
• ☑️ 프롬프트/툴 정의 버전 관리
• ☑️ Capability → Regression 승격
• ☑️ 프로덕션 플라이휠 구축

References​

• Agent Evaluation Readiness Checklist — Victor Moreira, LangChain
• Agent Observability Powers Agent Evaluation — LangChain
• How we build evals for Deep Agents — LangChain
• Demystifying Evals for AI Agents — Anthropic Engineering
• Building Effective Agents — Anthropic Research
• LLM Evals: Everything You Need to Know — Hamel Husain
• Witan Labs Research Log — Witan Labs

TL;DR​

AI Agent 시스템은 메신저 기반의 접근성(Manus Agents)부터 로컬 학습 시스템(PAI)까지 빠르게 진화 중입니다. 특히 메신저 환경에서 QR 코드 스캔만으로 동작하는 Manus Agents는 설정 복잡도를 제거하며 대중화를 노리고, PAI는 로컬 데이터 기반으로 사용자를 지속적으로 학습하는 개인 AI 비서를 제공합니다. 하지만 AI 코딩 도구 연구 결과는 상반됩니다 - 56% 생산성 향상과 19% 저하가 공존하며, 체감과 실제 성능의 괴리가 존재합니다. Agent 시스템의 실질적 효과는 작업 유형, 사용자 숙련도, 측정 방식에 따라 크게 달라집니다.

Key Takeaways​

• 메신저 기반 Agent의 전략적 전환: Manus Agents는 복잡한 설정 없이 QR 코드로 연결되며, 지속 메모리를 통해 사용자 스타일·선호도를 장기 학습합니다. 개발자 도구가 아닌 일상 커뮤니케이션 레이어로 AI를 확장하는 접근입니다.
• 생산성 측정의 복잡성: AI 코딩 도구는 실제 코딩 시간을 단축시키지만, 프롬프트 작성·검토·응답 대기 등 새로운 오버헤드를 생성합니다. 체감 생산성과 실측 데이터는 일치하지 않으며, 커밋 수 증가가 품질 향상을 의미하지 않습니다.
• 초급 개발자에게 더 큰 효과: 여러 연구에서 AI 도구는 초급 개발자의 속도를 더 크게 향상시킵니다. 이는 "AI가 있으니 주니어 채용 불필요"가 아니라 "주니어+AI 조합이 최대 효과"를 의미합니다.
• 로컬 우선 개인화 시스템: PAI는 모든 대화·작업을 로컬에 저장하는 3계층 메모리 구조(Hot/Warm/Cold)로 프라이버시를 보호하며, 모듈러 스킬 팩 시스템으로 필요한 기능만 선택적으로 확장할 수 있습니다.
• 속도보다 지속 가능성: Continuous Delivery 관점에서 AI 도구의 가치는 단순 속도가 아니라 "안전하게 빠르게 지속 가능하게" 전달하는 능력에 있습니다. 코드 리뷰·품질 단계 생략은 장기적 기술 부채를 초래합니다.

상세 내용​

메신저 기반 AI Agent의 부상: Manus Agents​

실리콘밸리를 중심으로 AI Agent 경쟁이 격화되고 있습니다. Meta가 약 20억 달러에 인수한 Manus는 복잡한 설정을 제거하고 메신저 환경에서 작동하는 개인 AI Agent를 제시합니다.

기존 시스템의 한계와 Manus의 차별점​

OpenClaw와 같은 기존 개인 AI Agent는 강력한 기능을 제공하지만, 설정 과정의 복잡성과 유지 관리 부담이 진입 장벽으로 작용했습니다. Manus Agents는 이를 다음과 같이 해결합니다:

초기에는 Telegram을 통해 출시되며, 향후 WhatsApp, LINE, Slack, Discord, Messenger로 확장될 예정입니다. Windows 및 Mac용 네이티브 애플리케이션도 준비 중입니다.

핵심 기술 특징​

1. 지속 메모리 기반 개인화 시스템

Manus Agents는 단발성 질의응답이 아닌 장기적 컨텍스트 유지를 핵심으로 합니다. 시스템은 사용자의 글쓰기 스타일, 어조, 개인 선호도를 지속적으로 학습하며, 이렇게 학습된 패턴은 이후 새로운 작업에 자동으로 반영됩니다.

2. 멀티스텝 작업 자동 실행

사용자가 "발표 자료 생성" 또는 "웹사이트 프로그래밍"과 같은 메시지를 보내면, AI는 내부적으로 작업 단계를 계획하고 실행합니다. 각 단계를 수동으로 지시할 필요가 없습니다.

3. 외부 서비스 연동

Gmail, Google Calendar, Notion 등 외부 서비스에 접근하여 메시지 맥락을 분석해 필요한 작업을 자동으로 수행합니다. 사용자는 별도의 파일 관리나 API 설정을 직접 다루지 않아도 됩니다.

보안 설계와 접근 권한​

Manus는 프라이버시 우려를 최소화하기 위해 제한적 접근 권한을 설계했습니다:

• AI는 자신의 채팅 기록 내 직접 메시지만 읽음
• 다른 대화, 그룹, 연락처 목록에는 접근 불가

사용자 커스터마이징 옵션​

모델 선택:

• Manus 1.6 Max: 심층 사고 중심
• Manus 1.6 Lite: 빠른 작업 처리

응답 스타일:

• 간결한 스타일
• 구조화된 스타일
• 대화형 스타일

또한 Telegram 내에서 음성 메시지(자동 전사 및 의도 분석), 이미지(내용 해석), 문서 파일(즉시 분석 및 작업 수행) 등 멀티미디어를 직접 처리합니다.

로컬 우선 개인 AI 인프라: PAI​

PAI(Personal AI Infrastructure)는 보안 전문가이자 AI 연구자인 Daniel Miessler가 개발한 오픈소스 개인 AI 인프라입니다. GitHub에서 7,300개 이상의 스타를 보유하고 있으며, MIT 라이선스로 무료 공개되어 있습니다.

PAI의 핵심 차별점: "AI가 나를 학습한다"​

일반 AI 챗봇과 달리 PAI는 모든 대화와 작업 결과를 로컬에 저장하고, 이를 통해 사용자의 선호도, 작업 스타일, 프로젝트 맥락을 지속적으로 학습합니다. 새로운 대화를 시작할 때마다 배경을 처음부터 설명할 필요가 없어집니다.

3계층 메모리 시스템​

이 구조 덕분에 다음이 가능합니다:

• "지난주에 우리가 만들었던 파이썬 함수를 다시 보여줘" → 로컬 저장소에서 즉시 검색
• "내가 선호하는 코드 스타일이 뭐지?" → 과거 작업 패턴 분석으로 자동 파악
• "이 프로젝트에서 우리가 어떤 의사결정을 했었지?" → 모든 의사결정 기록 검색

모듈러 스킬 팩 시스템​

PAI는 필요한 기능을 선택적으로 추가/제거할 수 있는 스킬 팩을 제공합니다:

기타 핵심 기능​

• 훅 시스템: 작업 전후에 자동 실행되는 사용자 정의 스크립트 (예: 코드 작성 전 보안 검사, 완료 후 자동 커밋)
• 알고리즘: 관찰→생각→계획→실행→검증→학습의 7단계 문제 해결 프로세스
• 음성 알림: ElevenLabs TTS 연동으로 작업 진행 상황을 음성으로 안내

기술 요구사항​

• 운영체제: macOS, Linux (WSL2 포함), Windows(WSL2)
• Node.js: v18 이상
• 메모리: 최소 8GB RAM (16GB 권장)
• 디스크: 최소 2GB 여유 공간
• Claude Code: Anthropic AI 계정 및 설치 필요

PAI는 TypeScript로 개발되었으며, 2025년 9월 공개 이후 일일 평균 46.8개의 스타를 기록하며 빠르게 성장 중입니다.

AI 코딩 도구의 생산성 논쟁: 56% vs 19%​

AI 코딩 도구의 실제 효과에 대해 상반된 연구 결과가 제시되고 있습니다.

56% 빨라졌다: GitHub 협업 실험 (2023)​

Microsoft Research, GitHub, MIT의 협업 실험에서 개발자에게 JavaScript로 HTTP 서버를 구현하는 과제를 부여했습니다:

• AI 사용 그룹: 평균 71분
• 비사용 그룹: 평균 161분
• 결과: 약 55.8% 더 빠름

특히 초급 개발자에게서 속도 향상이 두드러졌으며, 과제 성공률은 두 그룹 간 큰 차이가 없었습니다.

연구의 한계:

• 도구 공급사가 실험 설계에 참여
• 통제된 환경의 단일 과제 중심
• 실제 복잡한 프로젝트와는 상황이 다름

19% 느려졌다: METR의 현실 프로젝트 분석 (2025)​

METR 연구는 실제 오픈소스 프로젝트에서 16명의 개발자가 수행한 246개 작업을 분석했습니다:

• 전체 작업 완료 시간: 평균 19% 증가

세부 변화:

• ✅ 실제 코딩 시간 감소
• ✅ 검색, 테스트, 디버깅 시간 감소
• ❌ 새로운 작업 유형 증가: AI 출력 검토, 프롬프트 작성, 응답 대기
• ❌ 오버헤드 시간 증가

인지 편향의 함정: 흥미롭게도 개발자들은 실제로는 19% 느려졌음에도 "AI가 시간을 절약해줬다"고 체감했습니다. 이는 멀티태스킹이 생산성을 높인다고 믿었던 과거의 인지 편향과 유사합니다.

Multitudes 연구의 복잡성 (2025)​

10개월간의 데이터 분석 결과:

• 코드 변경 수 증가
• 근무 시간 외 커밋도 함께 증가

이는 두 가지 해석이 가능합니다:

1. AI 덕분에 처리량이 증가했다
2. 안정성을 희생하면서 속도를 올렸다

야간 커밋 증가는 새로운 기능 개발이 아니라 오류 수정이나 불안정성 대응일 가능성도 있습니다. 단순히 커밋 수 증가 = 생산성 증가로 볼 수 없다는 점을 시사합니다.

초급 개발자에게 더 큰 효과​

여러 연구에서 반복적으로 나타나는 패턴:

• AI 코딩 도구는 초급 개발자에게 더 큰 효과를 제공
• 숙련 개발자에게는 상대적으로 효과가 제한적

장기적 인재 구조 영향:

일부 조직은 "AI가 있으니 주니어를 채용하지 않아도 된다"는 판단을 내리고 있습니다. 그러나 연구 결과는 오히려 주니어 개발자가 AI와 함께 사용할 때 가장 큰 속도 향상을 보인다고 말합니다.

단기적 비용 절감이 장기적 인재 부족으로 이어질 가능성이 있으며, 이는 닷컴 버블 이후 주니어 채용 중단으로 숙련 개발자 부족 현상이 발생했던 사례와 유사할 수 있습니다.

속도보다 지속 가능성: Continuous Delivery의 관점​

일부에서는 AI로 생성된 코드를 빠르게 배포하기 위해 코드 리뷰나 품질 단계를 줄이자는 주장도 제기됩니다. "속도가 곧 경쟁력"이라는 논리입니다.

그러나 **지속적 전달(Continuous Delivery)**의 관점은 다릅니다. 핵심은 단순한 속도가 아니라:

1. 안전하게 빠르게
2. 지속 가능하게 빠르게
3. 품질을 유지하며 빠르게

코드 리뷰와 품질 단계 생략은:

• 단기적으로는 배포 속도를 높일 수 있음
• 장기적으로는 기술 부채와 유지보수 비용 증가
• 시스템 안정성 저하와 보안 취약점 증가

생산성은 체감이 아니라 데이터로 판단해야 하며, AI 도구의 가치는 장기적 코드 품질과 팀 역량 유지 여부로 측정되어야 합니다.

AI Agent 시스템의 진화 방향​

현재 AI Agent 시스템은 다음과 같은 방향으로 진화하고 있습니다:

1. 접근성 향상

• 복잡한 설정 제거 (QR 코드, 메신저 기반)
• 전문 개발자가 아닌 일반 사용자 타깃

2. 맥락 지속성 강화

• 지속 메모리 시스템
• 로컬 데이터 기반 학습
• 장기적 사용자 이해

3. 플랫폼 확장

• 단일 환경에서 다중 플랫폼으로 (Telegram → WhatsApp, Slack 등)
• 메신저와 업무용 소프트웨어의 경계 약화

4. 실행 능력 확대

• 대화형 응답에서 실제 소프트웨어 제어로
• 멀티스텝 작업 자동화
• 외부 서비스 통합

5. 프라이버시 우선 설계

• 로컬 데이터 저장
• 제한적 접근 권한
• 사용자 통제 강화

References​

• 메신저 안에서 완성하는 개인 AI 에이전트 경쟁: Manus Agents와 OpenClaw의 전략 분석
• AI 코딩 도구는 개발자를 56% 빠르게 만들까, 19% 느리게 만들까? 상반된 연구 결과로 본 생산성의 진실
• 완전 무료! GitHub 9k! 나를 학습하는 PAI로 개인 AI 비서 구축하기
• PAI GitHub Repository

TL;DR​

RAG에서 AI Agent로 빠르게 전환되는 시점에서, 실무자는 LLM·RAG·Agent의 본질적 개념을 정확히 이해해야 한다. Gen.AI 서비스는 기술·BM·아키텍처 관점에서 다층적으로 분류되며, 기존 서비스 대비 복잡도가 높다. 효과적인 서비스 구축을 위해서는 서비스를 명확히 정의하고, Product·Data·RAG 팀이 각자의 전문성을 기반으로 역할을 분업화해야 한다.

Key Takeaways​

• 기술 트렌드 이해: RAG는 이미 정착되었으나 Agent 중심으로 빠르게 전환 중이며, 실무자는 각 기술의 본질적 차이와 적용 시점을 명확히 구분해야 한다.
• 서비스 분류 체계: Gen.AI 서비스는 기술 관점(Content-Centric, Conversational, Automation 등 6가지)과 BM 관점(B2B/B2C × SaaS/IaaS/PaaS)으로 분류 가능하며, 자사 서비스의 위치를 파악하는 것이 전략 수립의 출발점이다.
• 4-Layer 아키텍처: Gen.AI 서비스는 Application, Platform, Model, Infrastructure 4개 레이어로 구성되며, 기존 서비스 대비 복잡성이 높아 레이어별 역할 정의가 중요하다.
• 전문성 기반 분업: Product(개발·운영), Data(파이프라인), RAG(기술 연구·적용) 팀이 각자의 전문 영역에 집중하는 것이 스타트업 환경에서도 효율적이다.
• 문제 진단 역량: 표면적 기술 적용보다 개념 이해가 선행되어야 실전에서 신속정확한 문제 진단과 대응이 가능하다.

상세 내용​

AI Service 이해의 중요성​

AI 기술의 발전 속도는 가속화되고 있다. RAG(Retrieval Augmented Generation)는 이미 많은 실무자에게 익숙한 개념이 되었지만, 투입 리소스 대비 성능 향상에 대한 고도화는 여전히 진행 중이다. 그럼에도 불구하고 업계는 AI Agent를 향해 빠르게 움직이고 있다.

이러한 빠른 전환 과정에서 실무자들이 간과하기 쉬운 점이 있다. LLM, RAG, Agent의 본질적 개념과 특징에 대한 깊이 있는 이해 없이 서비스 구축에만 집중하는 경우가 많다는 것이다. 이는 문제 상황에서 신속정확한 대처를 어렵게 만들고, 심각한 경우 명확한 문제 진단조차 불가능하게 만든다.

본 문서는 실무자가 마주하는 AI Service의 개괄적 특징과 명확히 알아야 할 본질적 개념을 정리하여, 실전에서 활용 가능한 참고 자료를 제공하고자 한다.

Gen.AI Service의 분류 체계​

기술 관점에서의 분류​

현존하는 생성형 AI 서비스는 기술적 특성에 따라 6가지 유형으로 구분할 수 있다:

자사 서비스가 어느 유형에 속하는지, 혹은 여러 유형의 특성을 조합하고 있는지 파악하는 것이 서비스 전략 수립의 첫 단계다.

비즈니스 모델 관점에서의 분류​

Gen.AI 서비스는 타겟 고객과 제공 형태에 따라 다음과 같이 분류할 수 있다:

이 분류를 통해 자사 서비스의 수익 모델과 경쟁 구도를 명확히 이해할 수 있다.

아키텍처 관점: 4-Layer 구조​

Gen.AI 서비스는 BM과 특성이 다양하더라도, 기본적으로 4개의 레이어로 구성된 아키텍처를 따른다:

1. Application Layer

• 실제 고객과 직접 접점을 형성하는 레이어
• 서비스의 접근 형태(B2B, B2C), UI/UX, 사용자 경험을 담당
• 고객의 요구사항이 시스템으로 전달되는 진입점

2. Platform Layer

• 비즈니스 로직과 AI 기능을 연결하는 중간 레이어
• API 게이트웨이, 오케스트레이션, 워크플로우 관리 등을 담당
• RAG, Agent와 같은 AI 기능이 실제로 구현되는 영역

3. Model Layer

• LLM, Embedding 모델 등 AI 모델이 위치하는 레이어
• 모델 선택, 파인튜닝, 프롬프트 엔지니어링이 이루어지는 영역
• 서비스의 AI 성능을 직접 결정하는 핵심 레이어

4. Infrastructure Layer

• GPU, 스토리지, 네트워크 등 물리적·클라우드 인프라
• 모델 서빙, 스케일링, 모니터링을 지원
• 비용과 성능의 트레이드오프가 결정되는 레이어

Gen.AI 서비스는 이 4개 레이어가 유기적으로 연결되어야 하며, 기존 서비스 대비 복잡성이 높다. 각 레이어의 역할을 명확히 이해하고 레이어 간 인터페이스를 잘 설계하는 것이 중요하다.

실무자의 역할 분담​

회사가 올바른 방향성을 가지고 시너지를 극대화하려면, 각 팀의 실무자가 전문성을 기반으로 명확한 역할을 수행해야 한다. 다음은 효과적인 역할 분담의 예시다:

Product Team

• 서비스 기능의 직접 개발
• 배포된 서비스의 전반적인 유지보수, 운영, 대응
• 고객 피드백 수렴 및 기능 개선

Data Team

• 서비스 기능에 필요한 데이터 수급 및 전처리
• 데이터 레이크, 파이프라인 등 전반적인 데이터 인프라 운용/관리
• 데이터 품질 관리 및 거버넌스

RAG Team

• RAG/Agent에 대한 지엽적인 기술 연구
• 연구 결과를 바탕으로 한 서비스 적용 및 반영
• 프롬프트 엔지니어링, 모델 최적화 등 AI 성능 개선

물론 스타트업 환경에서는 인력 규모의 제약으로 인해 역할의 경계가 모호할 수 있다. 하지만 LLM, RAG, Agent는 기존 방식과 다른 특성을 가지고 있기 때문에, 모든 팀원이 표면적인 부분만 다루기보다는 각 팀이 강점을 가진 영역에 집중하여 전문성을 높이는 것이 장기적으로 효과적이다.

서비스 정의의 중요성​

모든 논의의 출발점은 "만들고 운용하고자 하는 서비스의 명확한 정의"다. 서비스의 기술적 분류, BM, 아키텍처, 타겟 고객을 명확히 정의하지 않으면 팀 간 협업이 비효율적이고 방향성이 흐려진다.

서비스 정의가 명확해지면:

• 각 팀이 집중해야 할 우선순위가 분명해진다
• 레이어별 책임 영역이 구분되어 병목 지점 파악이 쉬워진다
• 기술 선택과 투자 결정이 데이터 기반으로 이루어진다
• 문제 발생 시 근본 원인 분석과 빠른 대응이 가능하다

References​

• 원본 문서: 여러분은 AI Service에 대해 얼마나 알고 계신가요?

TL;DR​

Anthropic의 Claude Code에 새로 추가된 Agent Teams 모드는 여러 Claude 인스턴스가 독립적인 컨텍스트 윈도우에서 병렬로 작업하며 서로 직접 소통하는 구조입니다. 기존 Subagent의 "지시-보고" 방식과 달리, 팀원들이 자율적으로 태스크를 분배하고, 토론하며, 공유 태스크 리스트에서 작업을 claim합니다. Anthropic은 이 방식으로 16개 Opus 4.6 인스턴스를 투입해 2주간 $20,000 비용으로 10만 줄의 Rust 기반 C 컴파일러를 구축했으며, Linux 커널, SQLite, PostgreSQL 등을 컴파일하고 GCC 테스트 스위트 99%를 통과하는 성과를 냈습니다.

Key Takeaways​

• 병렬 작업의 실질적 가치: Agent Teams는 단순 속도 향상이 아닌 관점의 다양화를 제공합니다. 보안, 성능, 테스트 커버리지 등 전문 영역별로 에이전트를 배치하면 단일 에이전트보다 포괄적인 검토가 가능합니다.
• 자율적 태스크 관리: 공유 태스크 리스트에서 에이전트가 스스로 작업을 claim하고 완료하는 구조로, 중앙 조율 오버헤드 없이 병렬 처리 효율을 극대화할 수 있습니다.
• 격리된 작업 환경과 동기화: Docker를 통한 작업 공간 격리, Git 기반 동기화, Task Lock을 통한 중복 방지 등 체계적인 인프라로 merge conflict까지 에이전트가 자동 해결합니다.
• 실전 검증된 확장성: 10만 줄 규모의 컴파일러 프로젝트를 2,000회 세션에 걸쳐 완수한 사례는 장기 실행 자율 개발의 실현 가능성을 보여줍니다.
• 활성화는 간단하지만 제약 인지 필요: settings.json에 한 줄 추가로 활성화 가능하나, 세션당 하나의 팀만 운영 가능하고 파일 동시 수정 시 충돌이 발생하는 등 현재 실험적 기능의 한계를 이해해야 합니다.

상세 내용​

Agent Teams란 무엇인가​

Agent Teams는 Claude Code의 새로운 실험적 모드로, 여러 개의 Claude Code 인스턴스가 팀으로 협업하는 구조입니다. 하나의 인스턴스가 리드(lead) 역할을 맡아 작업을 조율하고, 나머지 팀원(teammates)들은 각자 독립적인 컨텍스트 윈도우에서 작업하면서 서로 직접 메시지를 주고받습니다.

기존의 Subagent 방식은 "작업을 시켜놓고 결과만 받는" 일방향 구조였습니다. 반면 Agent Teams는 팀원끼리 토론하고, 서로 반박하며, 태스크를 나눠 가지는 양방향 협업이 가능합니다. 공유 태스크 리스트를 통해 에이전트들이 자율적으로 작업을 claim하고 완료하는 방식으로 운영됩니다.

시작하기: 설정과 활성화​

Agent Teams는 Claude Code v2.1.32 이상에서 사용할 수 있는 실험적 기능입니다. 활성화 방법은 매우 간단합니다. settings.json 파일에 다음 설정을 추가하면 됩니다:

"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": true

또는 환경 변수로 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS를 설정할 수도 있습니다.

활성화 후에는 Claude에게 팀 구성을 요청하는 프롬프트를 제공하면 됩니다. 예를 들어, "코드 리뷰를 위해 3명의 전문가 팀을 구성해줘. 한 명은 보안, 한 명은 성능, 한 명은 테스트 커버리지를 담당하도록" 같은 지시가 가능합니다.

실전 활용 사례​

병렬 코드 리뷰​

가장 직관적인 활용 사례는 관점별 병렬 코드 리뷰입니다. 보안, 성능, 테스트 커버리지를 각각 전담하는 팀원을 배치하면, 단일 에이전트가 순차적으로 검토할 때보다 훨씬 포괄적이고 빠른 리뷰가 가능합니다. 각 팀원은 자신의 전문 영역에 집중하면서도, 필요시 서로 토론하고 반박하며 품질을 높일 수 있습니다.

C 컴파일러 구축: 대규모 프로젝트 사례​

Anthropic은 Agent Teams의 가능성을 검증하기 위해 야심찬 실험을 진행했습니다. Claude Opus 4.6 인스턴스 16개를 투입해, 사람의 개입 없이 완전히 자율적으로 Rust 기반 C 컴파일러를 구축하는 프로젝트였습니다.

프로젝트 스펙:

• 기간: 약 2주
• 세션 수: 약 2,000회
• 비용: $20,000
• 결과물: 10만 줄 규모의 Rust 코드

성과:

• Linux 커널(6.9) 컴파일 성공 (x86, ARM, RISC-V 지원)
• QEMU, FFmpeg, SQLite, PostgreSQL, Redis 컴파일 가능
• GCC 테스트 스위트 99% 통과
• Doom 게임 실행 가능

이 프로젝트에서 핵심은 단순히 많은 에이전트를 투입한 것이 아니라, 장기 실행 자율 개발을 가능하게 하는 하네스(harness) 설계였습니다.

아키텍처와 조율 메커니즘​

자율 실행 루프​

기존 Claude Code는 작업이 완료되면 사용자 입력을 기다리며 멈춥니다. 장기 실행 프로젝트를 위해서는 지속적으로 작업을 이어갈 수 있는 구조가 필요했습니다. Anthropic은 간단한 bash 루프로 이를 구현했습니다:

#!/bin/bash
while true; do
  COMMIT=$(git rev-parse --short=6 HEAD)
  LOGFILE=agent_logs/agent_${COMMIT}.log
  claude --dangerously-skip-permissions \
    -p $(cat AGENT_PROMPT.md) \
    --model claude-opus-X-Y &> $LOGFILE
done

이 루프는 Claude가 하나의 태스크를 완료하면 즉시 다음 태스크를 픽업하도록 만듭니다. 프롬프트에는 "문제를 작은 조각으로 나누고, 진행 상황을 추적하고, 다음 작업을 스스로 결정하고, 완벽해질 때까지 계속하라"는 지시가 포함되었습니다.

병렬 작업의 조율​

여러 에이전트가 동시에 작업할 때 발생하는 문제들을 해결하기 위해 다음과 같은 메커니즘이 사용되었습니다:

Docker 기반 격리: 각 에이전트는 독립된 Docker 컨테이너에서 실행되어 작업 환경이 격리됩니다. 이는 의도치 않은 간섭을 방지하고, 각 에이전트가 안전하게 실험할 수 있는 환경을 제공합니다.

Git 기반 동기화: 모든 에이전트의 작업은 Git을 통해 동기화됩니다. 각 에이전트는 자신의 변경 사항을 커밋하고, 다른 에이전트의 변경 사항을 pull하여 최신 상태를 유지합니다.

Task Lock 시스템: 동일한 작업을 여러 에이전트가 중복으로 수행하는 것을 방지하기 위해 Task Lock 메커니즘이 구현되었습니다. 에이전트가 태스크를 claim하면 다른 에이전트는 해당 작업을 선택할 수 없습니다.

자동 Merge Conflict 해결: 놀랍게도, 발생하는 merge conflict조차 에이전트들이 스스로 해결했습니다. 이는 Agent Teams의 협업 능력이 단순한 병렬 실행을 넘어서는 것을 보여줍니다.

Agent Teams의 이점​

1. 진정한 병렬성​

단일 Claude Code 세션은 한 번에 하나의 작업만 수행할 수 있습니다. 프로젝트 규모가 커질수록, 여러 이슈를 병렬로 디버깅하는 것이 훨씬 효율적입니다. Agent Teams는 이를 가능하게 합니다.

2. 전문화와 관점의 다양성​

여러 에이전트를 활용하면 각 에이전트가 특정 영역에 전문화될 수 있습니다. 보안 전문가, 성능 최적화 전문가, 테스트 전문가 등으로 역할을 분담하면, 각 관점에서 깊이 있는 검토가 가능합니다.

3. 상호 검증과 품질 향상​

팀원들 간의 토론과 반박 과정에서 단일 에이전트가 놓칠 수 있는 문제들이 발견됩니다. 서로 다른 접근 방식을 경쟁적으로 시도하는 "competing hypotheses" 방식도 가능합니다.

현재 제약사항과 고려사항​

Agent Teams는 실험적 기능이므로 몇 가지 알려진 제약사항이 있습니다:

세션 제한: 세션당 하나의 팀만 운영 가능합니다. 복수의 팀을 동시에 관리하려면 별도의 세션이 필요합니다.

파일 충돌: 같은 파일을 두 팀원이 동시에 수정하면 충돌이 발생할 수 있습니다. 작업 분배 시 파일 단위로 명확하게 영역을 구분하는 것이 좋습니다.

세션 재개 문제: 현재 버전에서는 세션 재개(resumption) 관련 알려진 이슈들이 있습니다.

종료 타이밍: 리드 에이전트가 팀원들의 작업이 완료되기 전에 종료되는 경우가 발생할 수 있습니다. 명시적인 종료 조건 설정이 필요합니다.

고아 tmux 세션: 에이전트가 비정상 종료되면 tmux 세션이 남아있을 수 있습니다. 정기적인 모니터링과 정리가 필요합니다.

베스트 프랙티스​

충분한 컨텍스트 제공​

각 팀원이 독립적으로 작업할 수 있도록 충분한 컨텍스트를 제공하세요. 프로젝트 목표, 코딩 스타일 가이드, 기술 스택 정보 등을 명확히 공유해야 합니다.

적절한 팀 크기​

무조건 많은 에이전트가 좋은 것은 아닙니다. 태스크의 병렬화 가능성, 조율 오버헤드, 비용을 고려하여 적절한 팀 크기를 선택하세요. C 컴파일러 프로젝트에서는 16개가 사용되었지만, 대부분의 경우 3~5개면 충분합니다.

태스크의 적절한 크기 조정​

너무 큰 태스크는 병렬화의 이점을 살리기 어렵고, 너무 작은 태스크는 조율 오버헤드가 커집니다. 각 에이전트가 독립적으로 완료할 수 있는 단위로 태스크를 나누세요.

팀원 작업 완료 대기​

다음 단계로 진행하기 전에 모든 팀원의 작업이 완료되었는지 확인하세요. 리드 에이전트가 너무 빨리 진행하면 팀원들의 작업이 손실될 수 있습니다.

리서치와 리뷰로 시작​

복잡한 구현 작업 전에, 먼저 리서치와 코드 리뷰 같은 안전한 작업으로 Agent Teams를 활용해보세요. 이는 팀의 작동 방식을 이해하고 조율하는 데 도움이 됩니다.

파일 충돌 회피​

작업 분배 시 각 팀원이 다른 파일을 담당하도록 명확히 영역을 구분하세요. 동일 파일에 대한 동시 수정은 피하는 것이 좋습니다.

모니터링과 스티어링​

Agent Teams는 자율적이지만, 정기적인 모니터링이 필요합니다. 진행 상황을 확인하고, 필요시 방향을 조정하세요. 로그를 활용해 각 에이전트의 활동을 추적할 수 있습니다.

미래 전망​

Agent Teams는 AI 기반 소프트웨어 개발의 새로운 패러다임을 보여줍니다. 단일 에이전트의 능력 향상도 중요하지만, 여러 에이전트의 효과적인 협업을 통해 더 복잡하고 큰 규모의 문제를 해결할 수 있습니다.

C 컴파일러 프로젝트는 완전 자율적인 장기 실행 개발이 실현 가능함을 증명했습니다. 물론 $20,000의 비용이 들었지만, 이는 여러 명의 엔지니어가 몇 주간 투입되는 것과 비교하면 경쟁력 있는 수준입니다. 더 중요한 것은, 이 기술이 계속 발전하면서 비용은 낮아지고 능력은 향상될 것이라는 점입니다.

현재는 실험적 기능이지만, Agent Teams의 핵심 아이디어—독립적 컨텍스트, 직접 통신, 자율적 태스크 관리—는 향후 AI 협업 시스템의 표준이 될 가능성이 높습니다.

References​

• Agent Teams 공식 문서 - Claude Code Docs
• Building a C Compiler with Agent Teams - Anthropic Engineering
• 정구봉님 링크드인 게시글 - Claude Code Swarm 모드