오픈 엔진 — Claude·Codex·ChatGPT를 큐로 연결해 에이전트 핸드오프 자동화하기

핵심 메시지

• 우리는 너무 많은 AI를 쓰는데 서로 잘 대화하지 못해, 결국 사람이 도구들 사이에서 일을 나르는 '복도(hallway)' 역할을 떠안는다.
• 진짜 병목은 모델이나 에이전트의 능력이 아니라 에이전트 사이의 '핸드오프(경계)'다. 일이 한 도구를 떠나 다음 사람·에이전트에게 맥락째 넘어가지 못하는 문제다.
• 해법은 사람과 에이전트가 모두 읽고 쓸 수 있는 '큐(queue)'에 일을 올리는 것이다. Linear·Jira·칸반 보드처럼 단순해도 된다.
• 프롬프트는 답을 요청하지만, 티켓은 결과를 요청한다 — 소유자·맥락·완료 정의·멈출 지점·보여줄 결과를 담아 다음 주체가 이어받게 한다.
• 오픈 엔진은 Linear 큐와 4개의 스킬(설정·상태·큐 실행·스모크 테스트)로 구성되며, 에이전트가 이슈를 claim-lock하고 상태를 옮기며 '영수증(receipt)'을 남긴다.

쉽게 이해하기

발표자는 Claude, Codex, ChatGPT, OpenClaw, Hermes 같은 여러 AI를 서로 통합되길 기다리지 않고도 함께 일하게 만드는 자작 시스템 '오픈 엔진(Open Engine)'을 소개한다. 문제의식은 단순하다. AI는 너무 많은데 서로 대화가 안 되고, 그 틈을 메우려 사람이 매번 맥락을 복사-붙여넣기 하며 일을 나른다는 것이다. 발표자는 집과 회사 양쪽에서, 팀과 가족 단위로 이 시스템을 쓰고 있다고 말한다.

구체적 사례로, 아기를 키우며 에이전시를 운영하는 친구가 등장한다. 그는 이미 Claude Code, 자동화 루프, OpenClaw 등 최소 다섯 가지 AI 시스템을 능숙하게 쓰지만, 각 도구가 하루의 한 조각씩만 맡다 보니 그 사이를 잇는 노동을 본인이 떠안는다. Claude는 프런트엔드 디자인에, OpenAI는 백엔드 엔지니어링에 강한 식으로 도구마다 강점이 달라 단순히 하나로 통일할 수도 없다. 클라이언트 콜, 제품 스코핑, 갑자기 잡힌 아기 진료를 동시에 처리하려면 모델을 타협하거나 사람이 직접 조율해야 하는 상황이다.

발표자는 수요일 방송에서 '에이전트는 본질적으로 루프 매니저'라고 한 점을 상기시킨다. 유용한 에이전트는 다시 실행되며 무엇이 바뀌었는지 알아채고, 적절한 지점에서 멈춰 판단이 필요할 때 사람을 부르는 '기억된 워크플로'다. 문제는 모든 루프가 각자의 방에 갇혀 있으면 사람이 그 사이의 복도가 된다는 점이다. 리서치 루프가 끝나도 글쓰기 루프는 무엇이 바뀌었는지 모르고, 코딩 에이전트가 파일을 고쳐도 리뷰 담당자는 모호한 요약만 받는다. 앞서 제안한 '오픈 브레인'이 회사에 갇히지 않는 기억의 문제였다면, 오픈 엔진은 그다음 조각인 '일의 이동' 문제다.

핵심 동작은 의도적으로 매우 단순하다. 사람과 에이전트가 모두 읽고 쓸 수 있는 큐에 일을 올리는 것. Jira든, 직접 만든 칸반이든, 발표자가 선호하는 Linear 티켓 큐든 상관없다. 좋은 티켓에는 '무엇을 해야 하는지, 누가 소유하는지, 중요한 배경, 에이전트가 할 수 있는 일과 멈춰야 할 지점, 끝났을 때 보여줄 것'이 담긴다. 2025년의 프롬프트가 '답'을 요청했다면, 티켓은 '결과'를 요청하며, 서로 직접 통합돼 있지 않은 여러 에이전트라도 티켓을 공통 대화 장소로 삼아 협업할 수 있다. 발표자는 채팅창이나 Slack은 상태 관리에 형편없는 도구라고 잘라 말한다.

오픈 엔진은 다섯 구성요소로 이뤄진다. Linear 큐 하나와, AI에게 이 티켓 시스템 사용법(프로토콜)을 알려주는 네 가지 스킬 — 설정(setup), 상태(status), 큐 실행, 스모크 테스트다. 데모에서 Codex는 자기 큐를 확인해 처리 가능한 이슈를 찾고, 작업 전 이슈를 claim-lock 한 뒤 'agent working'으로 옮기고 'agent claimed' 영수증을 남긴다. 위임 시나리오에서는 Codex가 다른 사람(레오)의 에이전트인 Claude가 온라인인지 확인하고, 맥락을 담은 자족적 이슈를 만들어 넘긴다 — 서로 다른 제공자의 에이전트가 Linear 위에서 협업하는 것이다. 모호함에 부딪히면 추측하지 않고 'needs input'으로 옮겨 정확한 질문을 남기며, 사람은 그 이슈에서 답하고 감사 추적은 한곳에 남는다. 발표자는 이것이 '하나의 에이전트로 모두를 지배'하는 것이 아니라, 어수선한 AI 시스템들을 깔끔한 틀로 꿰매어 핸드오프 스트레스를 없애는 일이며, 가족의 페인트 색 고르기부터 영업 파이프라인 검토까지 같은 모양의 핸드오프 문제에 적용된다고 강조한다.

주요 인사이트

• 여러 AI를 쓸수록 사람이 그 사이의 '복도'가 된다. 진짜 병목은 모델 능력이 아니라 에이전트 간 핸드오프다.
• 도구마다 강점이 달라(Claude=프런트엔드, OpenAI=백엔드) 하나로 통일할 수 없으므로, 통합 대신 '조율 계층'이 필요하다.
• 사람과 에이전트가 함께 읽는 큐(Linear·Jira·칸반)에 일을 올리면, 직접 통합되지 않은 에이전트들도 티켓을 통해 협업할 수 있다.
• 프롬프트는 답을, 티켓은 결과를 요청한다. 소유자·맥락·완료 정의·멈출 지점·보여줄 결과가 담긴 티켓이 일을 진짜로 끝내게 한다.
• claim-lock과 상태 이동, '영수증', 'needs input' 패턴으로 무엇이 됐는지를 채팅을 뒤지지 않고도 투명하게 감사할 수 있다.

자주 묻는 질문

관련 AI 소식