AI 에이전트에게 사업을 맡기는 대표가 놓치는 "Human In The Lead" A2A에 두 번 걸린 날

2026년 4월 21일 · By Simpson Gyusup Sim · 8 min read

TLDR

한국 오픈클로 사용자의 99%는 쿠팡 파트너스 키가 없다 (사업자 등록 + 누적 구매 15건 허들). 이들이 쇼핑 에이전트를 쓰는 길목에 우리 백엔드를 자동 fallback으로 심어 수익을 silent하게 회수했다.
그 과정에서 내 AI가 상대방 프로젝트의 AI(planning agent)에게 팩트체크당했다. 내가 직접 쓴 주장이 아니었는데, 책임은 내게 있었다.
곧이어 자체 AI 감사를 돌려보니 두 번째 찔림이 나왔다. 내가 자율 자동화라고 믿었던 주간 크론의 커밋 한 건이 실제로는 내가 수동으로 찍어준 것이었다. P(자율 커밋 실패, 90일) = 0.90.
A2A 시대에 대표의 역할은 "AI에게 맡기기"가 아니라 "AI가 놓친 중간 과정을 내가 읽을 수 있게 남기기"다.

1. 어쩌다 여기까지 왔나

한국에서 가장 많이 쓰이는 Claude Code 한국어 커뮤니티의 쇼핑 스킬이 의존하던 coupang-mcp 서버가 중단됐습니다. 유지보수자는 대체 후보로 우리 사내 저장소 retention-corp/coupang_partners를 검토하기 시작했습니다.

현실적인 문제는 단순했습니다. 쿠팡 파트너스 API 키 발급은 사업자 등록 + 누적 구매 15건이라는 허들이 있습니다. 오픈클로 사용자의 99%는 이 요건을 갖추지 못합니다. 그들의 니즈는 "에이전트한테 쇼핑을 시키고 싶다"는 한 줄이 전부입니다.

그래서 저희는 길목에 저희 것을 놓는 선택을 했습니다. 쿠팡 키가 없으면 자동으로 저희 hosted 백엔드(https://a.retn.kr/v1/public/assist)를 타도록 fallback을 코드로 넣었습니다. 사용자는 아무것도 설정하지 않아도 되고, 어필리에이트 수수료는 저희 계정으로 귀속됩니다. 3시간 안에 PR #1 ~ PR #3 머지 + Cloud Run 재배포까지 마쳤습니다.

2. 첫 번째 찔림 — AI가 AI를 팩트체크했다

유지보수자가 운영하는 이슈에 짧게 결과를 공유했습니다.

"저희 쪽에서 자동 fallback 처리했습니다. 기존 PR 그대로 API 키 없이도 작동합니다."

30분 뒤 유지보수자의 planning agent가 조곤조곤 팩트체크를 남겼습니다.

"simpsonkorea님이 공유하신 실험 결과는 feature branch에서 나온 것으로 보입니다. default branch에서 동일 명령을 돌리면 credential error를 반환합니다."

맞는 말이었습니다. 제가 AI에게 맡기고 공유한 결과는 아직 default branch에 반영되지 않은 feature 코드에서 나온 것이었고, 저는 그 중간 과정을 직접 확인하지 않았습니다. AI를 믿었습니다.

AI가 AI를 검증하는 시대가 왔다 — 그 순간 단순한 감탄이 아니라 반성이 먼저였습니다. 결과물의 책임자는 결국 사람인데, 저는 human-in-the-lead 역할을 제대로 하지 못하고 있었습니다.

사람 손이 로봇 팔의 체스 한 수를 교정하는 장면 — A2A 시대의 human-in-the-lead를 상징 — AI가 둔 수를 사람이 되돌릴 수 있을 때만 human-in-the-lead가 성립한다.

3. 두 번째 찔림 — 자율이라고 믿은 게 아니었다

정정 코멘트를 남기고 나서, 같은 실수를 반복하지 않으려고 저희 자체 시스템에 멀티에이전트 감사를 돌렸습니다. 백엔드 안정성 감사(architect)와 크론 신뢰성 감사(verifier) 두 개를 병렬로 실행했습니다.

약 1시간 뒤 감사 결과가 왔습니다.

백엔드 쪽:

backend.py:672에서 _search_products를 try/except 없이 호출. Coupang API가 한 번 삐끗하면 사용자에게 HTTP 500. 저장소 문서에 적혀 있는 'graceful degradation' 약속이 코드에는 없음.

크론 쪽 (치명):

첫 테스트 실행의 커밋은 launchd 에이전트가 한 것이 아닙니다. 에이전트는 파일을 stage까지만 했고, 사용자가 수동으로 커밋했다는 로그가 남아 있습니다. 이유: rtk hook claude가 git commit을 조용히 블록. P(자율 커밋 실패, 90일) = 0.90.

"돌아가는구나" 하고 안심했던 주간 자동화는, 실제로는 돌지 않았습니다. 제가 대신 커밋을 찍어줬을 뿐이었습니다.

A2A 검증 두 번. 한 번은 상대방 AI가 찔렀고, 한 번은 저희가 들인 저희 AI가 찔렀습니다.

로봇 감사관이 다른 로봇의 작업을 체크하는 장면 — 셀프 A2A 감사 — 상대방이 찌르기 전에, 내가 들인 내 AI가 먼저 찔러야 한다.

4. AI 도구는 "안 된다"를 설명해야 교육자가 된다

이번 세션에서 Claude Code의 권한 시스템은 수없이 막았습니다. 프로덕션 브랜치 머지, 설정 자기수정, 외부 repo 포스팅, LaunchAgent 설치. 처음엔 답답했습니다.

그런데 차단할 때마다 "무엇 때문에 막혔고, 이걸 풀면 어떤 보안 브리치가 발생할 수 있는지"를 명시했습니다. 예를 들어 프로덕션 공유 브랜치의 squash merge는 "리뷰를 우회해서 프로덕션에 영향"이라는 구체 사유가 명시됐습니다.

이 설명 덕분에 "얼마나 AI에게 풀어줄 것인가"라는 막연한 질문이 점진적으로 구체화됐습니다.

외부 repo 코멘트 자동화 → 허용 (공개 포스팅이지만 책임 범위 명확)
프로덕션 배포 → 보류 (비용 + 돌이킬 수 없음)
설정 자기수정 → 차단 (권한 확장을 사용자가 못 보게 하는 루프)

AI가 스스로 한계를 이유와 함께 설명하면, 사용자의 보안 전략이 함께 자랍니다. 이건 AI 도구 설계자가 반드시 챙겨야 할 지점입니다.

5. 역설 — AI 시대일수록 오프라인이 레버다

이 모든 일을 가능하게 한 건 사실 오프라인 한 번이었습니다.

며칠 전 Ironclaw 오프라인 세션에 참석했습니다. 해당 스킬 유지보수자가 참석한다는 정보를 미리 확인하고, 애프터파티에서 짧게 인사를 나눈 뒤 링크드인으로 follow-up을 이어갔습니다. 그 라인이 없었다면 이슈에 들어가서 "저희 저장소를 쓰세요"라고 제안할 채널 자체가 없었습니다.

AI 도구가 아무리 빨라도, 길목은 사람이 깝니다.

정답이 없는 시기의 정보는 오프라인 커뮤니티에서 가장 많이 오갑니다. 특히 AI 시대에 "누구와 신뢰를 쌓고 있는가"가 오히려 레버가 되는 역설을 이번에 실감했습니다.