Multiplayer agentic engineering — Arjun Singh, Superconductor
📺 원본 영상: Multiplayer agentic engineering — Arjun Singh, Superconductor
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-08-10
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Arjun Singh의 발표는 coding agent를 개인 생산성 도구가 아니라 팀 전체가 함께 사용하는 협업 인프라로 재정의하는 데 초점을 둔다. 그는 agent를 중심에 두는 논의는 많지만, 정작 그 agent가 사람의 업무 흐름 안에서 어떻게 작동해야 하는지에 대한 논의는 부족하다고 지적한다.
강연의 핵심은 “agent를 더 똑똑하게 만드는 것”보다 “팀이 agent와 함께 일할 수 있는 구조를 만드는 것”에 있다. 이를 위해 그는 모델과 harness에 종속되지 않는 운영 방식, Slack·GitHub·앱을 넘나드는 동일 session, 외부 신호를 코드로 전환하는 자동화, cloud sandbox 기반 실행 환경, 그리고 실제 codebase 기준 benchmark의 필요성을 설명한다.
개인용 Agent에서 팀용 Agent로
Arjun Singh은 Superconductor 팀이 agentic workflow를 실험하기에 흥미로운 사례라고 소개한다. 공동창업자 Sergey와 그는 Berkeley 박사과정에서 만나 robotics와 computer vision을 연구했고, 이후 Gradescope를 공동창업해 수백만 명의 학생과 수천 개 대학에서 쓰이는 채점 플랫폼을 만들었다. 현재 Superconductor 팀의 상당수도 Gradescope 시절부터 함께 일해 온 사람들이기 때문에, 발표자는 이 팀이 “잘 협업하던 기존 개발 조직”이 agent를 적극적으로 도입했을 때 어떤 병목을 만나고 어떻게 해결했는지를 관찰할 수 있었다고 설명한다.
그가 보기에 현재 agent 논의의 상당 부분은 agent 자체의 능력에 집중되어 있다. 새로운 모델이 얼마나 강력한지, 어떤 benchmark에서 높은 점수를 받았는지, 어떤 coding harness가 더 좋은지를 이야기하는 것은 중요하지만, 실제 제품을 만드는 팀에서는 그보다 복잡한 문제가 생긴다. 한 사람이 laptop에서 agent를 실행하고 결과를 기다리는 방식은 개인에게는 편리할 수 있어도, 팀원들이 같은 맥락을 공유하고 검토하며 이어받는 데에는 한계가 있다.
따라서 발표의 출발점은 agent를 단순한 개인 assistant로 보지 않는 것이다. agent가 팀의 업무 시스템 안으로 들어오려면, 사람이 이미 일하는 공간에 자연스럽게 연결되어야 하고, agent가 수행한 작업도 팀이 볼 수 있어야 한다. 이 관점에서 “multiplayer agentic engineering”은 여러 사람이 같은 agent session을 중심으로 협업하고, 외부에서 들어오는 신호를 빠르게 구현 가능한 코드로 바꾸며, 그 과정 전체를 안전하게 통제하는 운영 모델에 가깝다.
Model과 Harness에 종속되지 않는 구조
강연자가 첫 번째 원칙으로 제시한 것은 model-agnostic, harness-agnostic한 환경을 만드는 것이다. 그는 가장 좋은 model과 harness가 주 단위로 바뀔 수 있다고 말한다. 새로운 모델이 출시되기도 하고, 잘 쓰던 모델이 갑자기 접근 불가능해질 수도 있으며, 특정 팀의 codebase에서는 대중적인 benchmark와 다른 결과가 나올 수도 있기 때문이다.
이 지점에서 중요한 것은 선택권이다. 발표자는 open-weight model도 충분히 좋아지고 있으며, 팀이 GLM 계열 모델 같은 더 저렴한 대안을 실험할 수 있어야 한다고 설명한다. 그러나 workflow 전체가 특정 vendor나 특정 harness에 묶여 있으면, 좋은 대안이 생겨도 도입 비용이 높아지고 반대로 기존 선택지가 사라졌을 때 업무 흐름이 크게 흔들린다.
또 하나의 현실적인 이유는 비용과 incentive의 불일치다. 강연자는 token을 판매하는 쪽의 목적과 제품을 만드는 팀의 목적이 완전히 같지는 않다고 지적한다. 개발팀은 고객 경험을 개선하고 제품을 더 좋게 만들기 위해 필요한 만큼의 token에는 기꺼이 비용을 지불할 수 있지만, 필요 이상으로 token을 쓰는 구조까지 받아들일 이유는 없다. model과 harness를 바꿀 수 있는 구조는 기술적 유연성뿐 아니라 비용 통제와 운영 주도권을 지키는 수단이 된다.
모든 Human Interface를 Agent Interface로 바꾸기
Arjun Singh은 coding agent가 laptop 안에 갇혀 있으면 팀 협업이 제한된다고 설명한다. Slack bot은 이 문제를 어느 정도 완화한다. Claude Code, Codex, Superconductor 같은 도구가 Slack에서 호출될 수 있다면 다른 팀원도 agent에게 지시하고 결과를 볼 수 있기 때문이다. 그러나 그는 이것만으로는 충분하지 않다고 말한다. agent가 laptop에서 Slack으로 옮겨졌을 뿐, 여전히 특정 interface 안에 갇혀 있기 때문이다.
그가 제안하는 방식은 같은 agent session을 Slack, 전용 app, GitHub 등 여러 interface에서 이어서 다룰 수 있게 만드는 것이다. 예를 들어 어떤 작업은 Slack에서 시작되고, 이후 engineer가 desktop app이나 mobile app에서 더 세밀하게 이어받으며, 마지막 검토와 병합은 GitHub에서 끝날 수 있다. 이때 핵심은 각 interface가 별개의 bot 대화가 아니라 동일한 session을 공유한다는 점이다. Slack에서 나눈 맥락이 GitHub에서는 사라지는 구조라면, 사람은 계속 context를 복사하고 설명해야 하며 agent 협업의 장점은 크게 줄어든다.
03:51 - Slack에서 시작한 agent session을 app과 GitHub로 이어가는 동일 session workflow 설명
이 구조는 비기술 직군이 제품 개발에 참여하는 방식도 바꾼다. 고객지원 담당자나 growth 담당자가 사용자와 대화하다가 발견한 bug나 개선점을 바로 agent에게 요청하고, engineer는 그 결과를 검토해 merge할 수 있다. 기존에는 Linear 같은 issue tracker에 ticket을 만들고, PM이 triage하고, engineer가 나중에 처리하는 흐름이 필요했다면, agentic workflow에서는 “발견한 사람이 곧바로 실행 가능한 변경을 촉발하는” 구조가 가능해진다.
Agent Work를 팀 전체에 보이게 만들기
두 번째 핵심은 agent가 무엇을 하고 있는지 팀이 볼 수 있어야 한다는 것이다. 강연자는 Superconductor의 app view를 예로 들며, 하나의 ticket에 Sergey, 본인, growth 담당자 등 여러 사람이 참여한 상황을 설명한다. 화면 상단에는 누가 이 session과 상호작용했는지, 누가 알림을 받을지, 누가 이미 보았는지 같은 정보가 표시되는 것으로 보인다. 이 정보는 특히 비기술 직군이 작업을 시작했을 때 중요하다. engineer는 해당 요청이 이미 검토된 것인지, 누가 맥락을 알고 있는지, 어떤 의도로 만들어졌는지를 빠르게 파악해야 하기 때문이다.
04:28 - 여러 팀원이 하나의 ticket 또는 agent session에 참여한 app view 설명
이 방식에서는 review 과정도 달라진다. reviewer가 “왜 이렇게 구현했는가?”라고 질문할 때 반드시 원래 작업자에게 GitHub comment로 답변을 기다릴 필요가 없다. 동일 agent session 안에 결정 과정과 실행 맥락이 남아 있다면, reviewer는 agent에게 직접 물어보고 필요한 배경을 확인할 수 있다. 이는 agent가 코드를 생성하는 도구를 넘어, 작업의 기록과 설명을 보존하는 협업 매체가 된다는 의미다.
또한 발표자는 artifact의 중요성을 강조한다. agent가 만든 screenshot, video, preview 같은 산출물이 Slack에만 있거나 GitHub에만 있으면 팀원은 “어디에서 봐야 하는가”를 계속 고민해야 한다. 반대로 artifact가 session 단위로 통합되어 어디서든 보인다면, 작업을 시작한 위치와 검토하는 위치가 달라도 같은 결과물을 기준으로 논의할 수 있다. 이때 visibility는 단순한 편의 기능이 아니라, agent-generated work의 품질과 신뢰성을 높이는 협업 조건이 된다.
외부 신호를 코드로 전환하는 Workflow
세 번째 원칙은 모든 external signal을 팀이 빠르게 평가할 수 있는 code로 바꾸는 것이다. 여기서 external signal은 Slack 대화, 고객 meeting, onboarding call, sales call, internal meeting, Sentry alert, bug tracker, customer email, feature request 등 제품 주변에서 발생하는 거의 모든 신호를 뜻한다. 이미 많은 팀이 MCP(Model Context Protocol) 등을 통해 agent가 email, Notion, ticket system을 읽을 수 있게 만들고 있지만, 발표자는 그것만으로는 부족하다고 말한다. agent가 여러 시스템을 읽을 수 있어도 “무엇을 해야 하는지”를 사람이 지정해야 한다면 여전히 coordination cost가 남기 때문이다.
Superconductor가 사용하는 예시 중 가장 흥미로운 것은 meeting bot이다. 발표자는 Expo booth에서 Google Meet에 meeting bot을 하루 종일 초대해 두었고, bot이 대화를 들으며 여러 아이디어와 작업 항목을 생성했다고 설명한다. 이미 진행 중인 작업과 관련된 내용이면 새 ticket을 중복 생성하지 않고 기존 작업에 연결하며, 새로운 아이디어라고 판단되면 ticket을 만들고 구현까지 시작한다. 이 과정에서 사람은 “이 대화에서 나온 특정 이메일을 처리해라” 같은 수동 지시를 하지 않아도 된다.
07:30 - meeting bot이 booth 대화에서 아이디어를 감지하고 ticket을 생성하는 사례 설명
가장 구체적인 사례는 acceptance criteria에 관한 아이디어였다. 어떤 참석자가 coding agent에게 작업을 맡길 때, agent가 완료를 선언하기 전에 스스로 품질을 평가할 명확한 기준이 있으면 좋겠다고 말했고, meeting bot은 이를 포착해 ticket을 생성한 뒤 ticket form에 acceptance criteria 관련 field를 추가하는 prototype을 만들었다. 발표자는 이 결과를 그대로 ship하지는 않을 것이라고 선을 긋지만, 중요한 점은 아이디어가 곧바로 만져볼 수 있는 형태가 되었다는 데 있다. 수백, 수천 개의 흩어진 아이디어가 회의록이나 메모에 머무는 대신, 평가 가능한 prototype과 PR로 전환되면 팀은 고객이 실제로 요구하는 속도에 훨씬 가깝게 움직일 수 있다.
08:02 - acceptance criteria field가 추가된 ticket form prototype 화면 설명
Cloud Sandbox가 필요한 이유
강연자가 반복해서 강조하는 전제는 agent workflow가 개인 laptop에 묶여 있어서는 안 된다는 것이다. isolated cloud environment에서 codebase와 project가 실행될 수 있어야 Slack, app, GitHub, meeting bot 같은 여러 interface가 같은 agent session을 공유할 수 있다. 그는 이 구조가 이른바 “lid anxiety”를 없앤다고 설명한다. laptop을 닫으면 agent 작업이 멈출까 걱정하거나, 공항과 이동 중에도 laptop을 열어 둔 채 작업을 유지해야 하는 상황에서 벗어날 수 있다는 뜻이다.
그러나 발표자가 더 중요하게 보는 이유는 security와 access control이다. 개발자의 laptop에는 agent가 접근해서는 안 되는 token, file, credential, project data가 존재할 가능성이 높다. sandbox와 approval flow가 있더라도, 사람은 매번 많은 권한 요청을 승인하거나 YOLO mode가 제대로 설정되었기를 기대하게 된다. agent가 점점 더 autonomous하고 resourceful해질수록, 잘못된 credential을 찾아 production database에 접근하는 식의 사고 가능성은 무시하기 어렵다.
Cloud sandbox는 agent에게 필요한 것만 제공하는 방식으로 이 위험을 줄인다. 발표자는 network sandbox를 구성해 agent가 접근할 수 있는 domain과 접근할 수 없는 domain을 구분하고, 새로운 vendor documentation이 필요할 때 ticket 단위나 project 단위로 접근을 승인할 수 있다고 설명한다. 이는 단순히 credential 유출을 막는 문제가 아니라, code, secret, customer content가 의도치 않은 외부 위치로 exfiltration되는 것을 막는 문제이기도 하다. 결과적으로 sandbox는 agent 사용을 제한하는 장치가 아니라, 더 많은 팀원이 더 자유롭게 agent를 활용할 수 있게 만드는 기반이 된다.
11:42 - configurable network sandbox와 접근 허용 범위를 설명하는 구간
실제 Codebase 기준으로 Agent를 Benchmark하기
마지막으로 발표자는 agent를 자신의 codebase에서 직접 benchmark해야 한다고 주장한다. public benchmark인 SWE-bench나 Terminal-Bench는 유용한 신호를 제공하지만, 특정 팀의 업무와 완전히 일치하지 않는다. 그는 SWE-bench가 Python 중심인 반면 Superconductor는 Ruby on Rails codebase를 사용한다고 설명하며, benchmark의 전반적 추세는 참고할 수 있어도 결과가 그대로 적용되지는 않는다고 말한다.
Superconductor의 방식은 좋은 engineering work를 대표하는 pull request를 선택하고, 여러 agent와 harness가 그 작업을 어떻게 수행하는지 비교하는 것이다. 여기서 비교 기준은 quality, cost, time이다. 발표자는 자사 codebase에서 Anthropic 계열 agent는 지속적으로 품질이 좋아졌지만 속도는 크게 빨라지지 않았고, Codex agent와 Cursor는 빠르면서도 꽤 좋은 결과를 보였다고 설명한다. open-weight 계열도 점점 좋아지고 있지만, 그들의 환경에서는 상대적으로 느린 편이었다고 덧붙인다.
14:23 - 자사 codebase 기준 quality versus cost, quality versus time benchmark chart 설명
이 benchmark는 실제 운영 선택을 바꿨다. 발표자에 따르면 Anthropic 계열은 Superconductor 기준으로 비용이 훨씬 높았고, Codex 계열은 더 많은 session을 처리하면서도 전체 비용이 낮았다. 그 결과 팀은 default를 Codex로 바꾸었고, 특정 모델이 잠시 좋아 보이면 며칠간 default를 바꿨다가 다시 돌아오는 식으로 유연하게 움직일 수 있었다. 중요한 것은 어떤 모델이 영구적으로 최고라는 결론이 아니라, 모델과 harness에 종속되지 않는 구조 덕분에 frontier의 cost, speed, quality 지점으로 계속 이동할 수 있었다는 점이다.
| 강연에서 언급된 비교 축 | 설명 |
|---|---|
| Quality | 실제 codebase의 대표 PR을 기준으로 agent 산출물의 품질을 평가 |
| Cost | token 사용량과 실행 비용을 비교 |
| Time | 작업 완료까지 걸리는 시간을 비교 |
| Applicability | public benchmark가 아니라 팀의 언어, framework, codebase 특성에 맞는지 확인 |
이 접근은 향후 model routing으로 이어진다. 발표자는 “어떤 third party가 우리 codebase에 가장 적합한 model routing을 어떻게 알 수 있겠는가”라는 문제를 제기한다. 결국 task별 최적 model은 일반 benchmark가 아니라 조직의 실제 작업 이력과 codebase에서 도출되어야 한다. Superconductor가 구상하는 방향은 이러한 benchmark 결과를 바탕으로 특정 task에 가장 적합한 model을 자동으로 routing하는 것이다.
Agent가 만든 PR과 인간 Review의 균형
발표자는 Superconductor의 pull request 중 99.9%가 heavily agent-generated라고 말한다. 이는 agent가 단순 보조 도구를 넘어 실제 개발 생산량의 대부분을 생성하는 단계에 이르렀다는 의미다. 하지만 그는 quality, reliability, security가 여전히 중요하기 때문에 모든 작업은 human-reviewed라고 강조한다. agent가 코드를 많이 만든다고 해서 engineer의 역할이 사라지는 것이 아니라, engineer의 역할이 직접 작성에서 평가, 검증, 방향 설정으로 이동하는 것이다.
비용과 사용량도 흥미로운 신호를 제공한다. 발표자는 상대적으로 작은 팀이 지난 한 달 동안 105억 token을 사용했다고 언급한다. 또한 Claude Code run은 3,300회였고 token 기준 비용이 10,000달러 수준으로 표시되었지만, 실제로는 plan이 있어 그 금액을 그대로 지불한 것은 아니라고 설명한다. 반면 Codex는 네 배 많은 session을 처리하면서도 전체 비용은 더 낮았고, 현재 대부분의 작업이 Codex를 통해 merge된다고 말한다.
16:22 - 최근 한 달 token 사용량과 Claude Code, Codex session 비용 비교 화면 설명
이 수치는 특정 vendor의 우열을 일반화하기 위한 자료라기보다, 조직마다 agent economics가 다르게 나타난다는 사례로 읽어야 한다. 발표자도 “우리 codebase 기준”이라고 여러 차례 선을 긋는다. 따라서 중요한 takeaway는 특정 agent 하나를 선택하라는 것이 아니라, 팀이 직접 benchmark를 돌리고 실제 결과에 따라 default를 바꿀 수 있는 운영 체계를 갖추라는 것이다.
마무리 / 핵심 정리
Arjun Singh의 결론은 세 가지로 압축된다. 첫째, codebase와 agent를 sandbox에서 실행할 수 있게 만들어야 한다. 이는 laptop 의존성을 줄이고, security boundary를 명확히 하며, 비기술 직군까지 실제 product work를 촉발할 수 있게 만든다.
둘째, agent를 팀이 이미 사용하는 human interface에 통합해야 한다. Slack, GitHub, app, meeting, support flow가 서로 단절되어 있으면 agent가 만든 생산성은 context switching과 coordination cost에 의해 쉽게 상쇄된다. 반대로 동일 session과 artifact를 여러 interface에서 공유하면, agent work는 개인 작업이 아니라 팀의 공동 작업물로 전환된다.
셋째, model과 harness를 benchmark하고 비종속적으로 운영해야 한다. public benchmark만으로는 자신의 codebase에서 어떤 agent가 cost, speed, quality 측면에서 가장 적합한지 알 수 없다. 결국 multiplayer agentic engineering의 핵심은 더 강한 agent 하나를 기다리는 것이 아니라, 팀의 workflow, security model, evaluation loop를 agent 시대에 맞게 다시 설계하는 데 있다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Multiplayer agentic engineering — Arjun Singh, Superconductor |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-08-10 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.