Orkas는 AI 네이티브 회사가 돌아가는 기반이 되고자 합니다. 이 목표를 세우면 곧바로 한 가지 질문에 닿습니다. 여러 사람과 여러 에이전트가 같은 프로젝트에서 어떻게 협업해야 할까요?
그 답은 우리에게 익숙한 팀워크와 상당히 다릅니다. 이유를 이해하려면 사람 사이의 협업이 어디서 왔는지부터 짚어 보는 것이 좋습니다. (제품을 단계별로 쓰는 방법은 공유 프로젝트: Orkas에서 사람과 AI 에이전트가 함께 일하는 방식에서 다뤘습니다. 이 글은 그 뒤에 있는 생각을 이야기합니다.)
사람의 협업을 만든 두 가지 한계
첫째, 사람의 대역폭과 기억력에는 한계가 있습니다. 한 번에 받아들일 수 있는 정보도, 기억할 수 있는 양도 정해져 있습니다. 그래서 팀은 끊임없이 소통해야 합니다. 업데이트를 공유하고, 목표를 맞추고, 진행 상황을 맞춥니다. 주간 회의, 스탠드업, 일일·주간 보고, “잠깐 싱크 좀 할까요?”, “한번 맞춰 보죠” 같은 것들이 모두 이 한계를 메우기 위한 것입니다.
둘째, 그중 상당 부분은 얼굴을 맞대고 이루어져야 합니다. 직접 만나면 말 외에도 정보가 오가는 통로가 더 있습니다. 몸짓, 어조, 표정이 모두 정보를 전합니다. 테이블 건너편에서 누군가 “계획 괜찮아 보이네요”라고 말하면, 진심인지 아닌지 들으면 압니다. 그만큼 중요한 점은 직접 만나야 신뢰가 쌓인다는 것입니다. 그래서 많은 원격 팀이 지금도 때때로 한자리에 모입니다.
에이전트가 합류하면 달라지는 것
사람과 에이전트가 함께하는 팀에서도 협업의 인간적인 측면은 여전히 중요합니다. 하지만 에이전트와 일하는 것은 사람과 일하는 것과 매우 다릅니다. 에이전트에게는 뚜렷한 강점 세 가지와 뚜렷한 약점 세 가지가 있습니다.
세 가지 강점
대역폭이 넓고 실행력이 강합니다. 목표가 명확하고 측정 가능한 작업에서는 특히 그렇습니다. 게다가 에이전트가 끝까지 해낼 수 있는 작업은 빠르게 더 길고, 어렵고, 복잡해지고 있습니다. Meta는 자사 코딩 에이전트를 소개하면서, 에이전트가 GPU 커널 최적화 작업에서 최대 24시간 동안 일하며 1,000회가 넘는 도구 호출을 한 사례를 들었습니다(Meta). 2026년 10월에는 Linus Torvalds가 Linux 커널 패치 시리즈를 올렸습니다. 코드와 테스트 프로그램, 커밋 메시지 초안은 Claude Code가 작성했고, 측정은 그가 자기 컴퓨터에서 직접 했습니다(LWN).
세상의 지식과 도구를 갖추고, 여러 분야를 넘나들며 처음부터 끝까지 해냅니다. 사전 학습을 거치며 세상의 지식은 이미 모델 안에 담겼습니다. 알맞은 도구만 주면 에이전트는 하나의 일을 여러 분야에 걸쳐 처음부터 끝까지 끌고 갈 수 있습니다. PRD 작성 → 디자인 → 개발 → 테스트 → 출시. 같은 일을 사람이 하면 프로덕트, 디자인, 엔지니어링, QA가 함께 움직여야 하고, 일이 넘어갈 때마다 다시 한번 맞춰야 합니다.
사람다운 약점이 거의 없고, 신뢰부터 쌓을 필요도 없습니다. 에이전트는 지치지 않고, 컨디션이 나쁜 날도 없으며, 기초적인 질문을 민망해하지도 않습니다. 새 에이전트는 프로젝트의 컨텍스트만 받으면 바로 일을 시작할 수 있습니다. 적응 기간도, 먼저 쌓아야 할 관계도 없습니다.
세 가지 약점
깨끗한 컨텍스트가 필요합니다. 잘못된 컨텍스트는 에이전트를 엉뚱한 방향으로 이끕니다. 저희도 직접 겪었습니다. 분석 대시보드의 한 필드에 데이터를 “연결할 수 없다”고 나와 있었습니다. 실제로는 연결할 수 있었고, 그 필드 자체가 잘못 계산된 것이었습니다. 서로 다른 두 에이전트가 그 문장을 읽고는 둘 다 사용자 여정 분석 전체를 포기했습니다. 사람이라면 그런 결론을 보고 “이거 지금도 맞나?” 하고 물어볼 겁니다. 에이전트는 대개 그대로 받아들입니다.
장기적인 원인 분석에 약합니다. 여러 변수가 동시에 결과에 영향을 주면 엉뚱한 변수를 원인으로 지목하기 쉽고, 사람이 바로잡아 줘야 합니다. 한동안 저희 사이트의 새 페이지 몇 개가 Google에 색인되지 않았습니다. 한 에이전트는 “사이트 권위가 부족해서 Google이 크롤링 예산을 쓰지 않는다”고 결론 내리고, 백링크부터 쌓자고 제안했습니다. 저희가 반론을 제기하고 확인해 보니, 사이트 페이지의 대부분은 이미 색인되어 있었습니다. 색인되지 않은 몇 페이지는 사이트가 다루는 분야와 주제가 너무 동떨어진 경우에 더 가까워 보였습니다. 크롤링 예산과는 아무 관련이 없었고, 백링크를 쌓았다면 잘못된 조치였을 것입니다.
변하는 환경에 적응하는 데 서툽니다. 그 변화가 사전 학습 데이터에 없을 때는 더욱 그렇습니다. 막 개편된 사이트, 막 바뀐 플랫폼 규칙, 지난달 출시된 제품. 사람은 “뭔가 달라졌다”는 걸 알아차리고 방식을 바꿉니다. 에이전트는 이미 알고 있는 것을 바탕으로 계속 일하면서 같은 시도를 몇 번이고 되풀이하는 경우가 많습니다.
채팅 앱이 맞지 않는 이유
채팅 앱은 사람과 사람이 함께 일하도록 설계되었습니다. 메시지는 하나씩 밀려 올라가고, @멘션과 읽음 표시로 모두가 같은 상황을 파악하며, 정보는 여러 채널에 흩어집니다. 이 설계는 바로 앞에서 말한 두 가지 한계를 메우기 위한 것입니다. 사람은 대역폭이 좁고 기억이 짧으니, 계속 글을 올리고 계속 맞춰 가는 것입니다.
에이전트에게는 맞지 않는 구조입니다.
- 잡담, 중간에 오간 논의, 나중에 폐기된 계획은 에이전트에게 모두 컨텍스트 노이즈입니다.
- 에이전트는 대화로 신뢰를 쌓을 필요가 없습니다.
- 에이전트에게 정말 필요한 것은 깨끗한 컨텍스트와 명확한 작업입니다.
그래서 사람과 에이전트의 협업은 다시 설계해야 합니다. 그리고 에이전트가 계속 유능해지는 만큼, 협업 방식도 계속 바뀔 것입니다. Orkas에서도 아직 그 답을 찾아가는 중입니다.
Orkas의 방식: 변하지 않은 것은 지키고, 변한 것은 다시 설계하기
저희의 접근은 협업에서 변하지 않은 부분은 지키고, 변한 부분은 다시 설계하는 것입니다. 아래는 Orkas의 공유 프로젝트 화면입니다. 네 가지 아이디어가 강조 표시된 네 영역에 각각 대응합니다.
1. 일의 배정, 인계, 검토: 할 일
이것은 에이전트가 등장하기 훨씬 전부터 있던 것이고, 지금도 필요합니다. 현재로서는 저희 프로젝트의 모든 작업에 사람 담당자가 있고, 최종 결과는 사람이 책임집니다.
제품에서는 이렇게 작동합니다. 할 일은 각각 한 사람에게 배정되고, 어떤 에이전트가 일을 할지는 그 사람이 정합니다. 할 일을 시작할 수 있는 사람은 담당자뿐입니다. 에이전트는 담당자 본인의 컴퓨터에서 담당자의 모델과 크레딧으로 실행됩니다. 일이 끝나면 에이전트는 할 일을 스스로 완료 처리하지 않고 확인 대기 중으로 옮깁니다. 담당자가 확인하고 필요한 부분을 고친 뒤에야 완료됩니다.
2. 목표, 배경, 컨텍스트 공유: 목표와 규칙, 메모리
여기서는 사람과 에이전트가 같은 컨텍스트를 공유하므로 핵심 사실이 어긋나지 않습니다.
프로젝트의 목표와 규칙, 메모리는 이 프로젝트의 모든 대화에서 공유되고, 에이전트는 매번 이를 따릅니다. 예를 들어 “월간 리텐션 = 다음 달에 다시 돌아온 신규 사용자” 같은 지표 정의를 목표와 규칙에 적어 두고, 주요 결정은 프로젝트 메모리에 기록합니다. 새 멤버와 그 멤버의 에이전트가 합류하면 첫날부터 똑같은 내용을 읽게 됩니다.
3. 인계는 파일로, 과정은 따로
프로젝트의 라이브러리는 멤버 간에 동기화되고, 할 일에는 어떤 파일이든 첨부할 수 있습니다. 일은 채팅 기록이 아니라 파일로 넘겨집니다.
중간 과정의 대부분은 일부러 따로 떼어 둡니다. 에이전트에게 해로운 컨텍스트 노이즈가 되지 않게 하기 위해서입니다. 잠긴 작업 탭과 자동화 탭은 오직 나만의 것입니다. 에이전트는 보고서 하나를 내기까지 수백 단계를 거치고 세 가지 방법을 시도할 수도 있습니다. 동료가 받는 것은 보고서뿐입니다. 과정은 내 작업에 남고, 동료 에이전트의 컨텍스트에 섞여 들어가지 않습니다.
4. 개인 에이전트를 팀과 공유하기
멤버는 자신의 개인 에이전트를 팀의 다른 사람들이 쓸 수 있도록 공유할 수 있습니다. 이런 에이전트에는 소유자의 경험과 품질에 대한 판단이 담겨 있습니다. 공유하면 모두의 속도가 빨라지고, 쓰면서 발견한 문제는 자기 진화로 고쳐 나갈 수 있어 프로젝트 전체가 할 수 있는 일이 늘어납니다.
에이전트를 공유하면 Orkas는 그 에이전트의 작업 지침과 스킬을 하나로 묶습니다. 에이전트가 일하면서 스스로 쌓은 스킬도 포함됩니다. 메모리와 채팅 기록은 포함되지 않습니다. 공유한 사람이 에이전트를 업데이트하면 멤버들은 새 버전을 자동으로 받습니다.
아직 초기 단계의 열린 문제
사람과 에이전트의 협업은 아직 아주 초기 단계이고, 답은 하나로 모이지 않았습니다. 모델이 발전하면서 에이전트가 협업에 필요로 하는 것의 상당 부분이 모델 자체로 옮겨 갈 것입니다.
이미 이를 자체적으로 해내는 모델도 있습니다. 여러 하위 에이전트를 병렬로 돌려 문제를 여러 각도에서 탐색하거나, 먼저 계획을 세운 뒤 하위 에이전트에게 실행을 맡깁니다. Meta가 2026년 10월 오픈 웨이트로 공개한 Muse Spark Open은 일을 쪼개 하위 에이전트에게 넘기고 이들을 조율하도록 학습되었다고 소개되어 있습니다(PyTorch 블로그).
그러니 협업 방식은 모델이 좋아질수록 바뀔 것입니다. 할 일, 공유 컨텍스트, 파일 인계, 공유 에이전트는 오늘날의 모델이 할 수 있는 일에 맞춘 저희의 답이지, 최종 형태가 아닙니다.
맺으며
변하지 않은 것은 지켰습니다. 누군가 일을 책임지고, 누군가 검토하며, 목표와 컨텍스트를 계속 맞춰 가는 것입니다. 변한 것은 다시 설계했습니다. 파일로 인계하고, 과정은 따로 두고, 각자의 경험과 안목을 팀이 쓸 수 있는 에이전트로 바꾸는 것입니다.
저희도 아직 탐색하는 중이고, 함께 의견을 나누고 싶습니다. 사람과 에이전트가 함께 일하는 팀을 이끌고 있다면, 먼저 프로젝트 하나로 시작해 보세요. Orkas는 macOS와 Windows용으로 무료 다운로드할 수 있습니다.