AI 에이전트와 대화할까, 작업을 맡길까? 언제 무엇을 써야 할까

AI 에이전트와 대화를 나눌 수도 있고, 작업을 맡길 수도 있습니다. 매일 코딩 에이전트를 운영하는 팀들은 이 둘을 서로 다른 도구로 취급합니다. 반대로 이 둘을 혼동하는 팀은 나중에 그 대가를 치르죠. 의사결정은 개인 채팅 기록 속에 묻히고, 작업은 끝났는데 아무도 검토하지 않으며, 세션이 스크롤되어 사라진 지 3주 뒤에 동료가 "그거 우리 어디서 합의했죠?"라고 묻는 상황 말입니다.

Sharkly는 이 구분을 제품에 녹여 넣었습니다. 채팅은 추적 가능한 기록이 필요해지기 전에 에이전트와 함께 탐색하고, 계획하고, 실행하는 용도입니다. 태스크는 소유권, 상태, 실행 이력, 검토가 필요한 작업을 위한 것이죠. 둘 다 에이전트 실행을 시작할 수 있습니다. 하지만 저장되는 기록이 다르고, 바로 그 차이가 핵심입니다.

이 가이드에서는 각 화면이 무엇을 위한 것인지, Sharkly의 채팅 모드가 어떻게 동작하는지, 유망한 채팅을 실제 태스크로 넘기는 방법, 그리고 팀의 공유 기록을 정직하게 유지하는 판단 기준을 설명합니다.

TL;DR

질문을 던지거나, 주제를 조사하거나, 태스크를 열지 않고 계획을 다듬고 싶을 때는 AI 에이전트와 채팅하세요. 담당자, 상태, 완료 기준, 검토, 또는 팀이 볼 수 있는 지속적인 기록이 필요한 작업이라면 태스크를 할당하세요. 채팅 메시지는 세션에 남고, 태스크 결과는 태스크로 돌아가서 사람들이 검토하고 승인합니다.

문제: 하나의 에이전트, 두 종류의 작업

터미널에서 Claude Code나 Codex를 돌려본 사람이라면 이미 두 종류의 작업을 모두 알고 있습니다. 어떤 세션은 질문입니다. 이 모듈은 무슨 일을 하는지, 왜 이 테스트가 불안정한지, 마이그레이션에 비용이 얼마나 들지. 다른 세션은 약속입니다. 이 버그를 고치고, 이 엔드포인트를 배포하고, 이 문서를 업데이트하는 것처럼요.

터미널은 둘을 똑같이 취급합니다. 사소한 질문에 답한 세션이든, 팀 전체가 의존하는 변경을 만들어낸 세션이든, 모든 세션은 한 사람의 컴퓨터에 남는 개인 기록일 뿐입니다. 질문 세션이야 그대로 둬도 괜찮습니다. 문제는 약속 세션이죠. 목표도, diff도, 논의도, 결과도 다른 사람은 볼 수 없으니까요.

대부분의 팀은 이 문제를 뼈저리게 겪고 나서야 깨닫습니다. 한 개발자가 에이전트와 채팅하며 프로덕션 수정을 진행하고, 수정은 배포됩니다. 그런데 그 근거는 금요일에 지워질 스크롤백 버퍼에만 남아 있죠. 반대의 실패도 일어납니다. 팀이 사소한 질문까지 전부 태스크 트래커로 보내면, 보드가 "캐싱에 대해 물어보기" 같은 죽은 티켓으로 가득 차게 됩니다.

해결책은 한쪽 화면을 금지하는 규칙이 아닙니다. 각 화면이 무엇을 기록하는지 이해하고, 작업을 의도적으로 두 화면 사이로 옮기는 것입니다. 그 시작은 AI 에이전트와의 채팅이 무엇을 저장하고 무엇을 저장하지 않는지 이해하는 것입니다.

Sharkly의 에이전트 채팅이란?

에이전트 채팅은 에이전트 또는 크루와 나누는 독립형 채팅입니다. 질문을 하거나, 주제를 조사하거나, 계획을 세우거나, 태스크를 먼저 열지 않고 작업을 시작하고 싶을 때 사용하세요. 각 독립형 채팅은 자체 세션과 메시지를 기반으로 하며, 세션은 만든 사람에게 속합니다.

Sharkly에는 두 가지 채팅 화면이 있고, 문서는 이 둘을 엄격히 구분합니다:

• 독립형 에이전트 채팅은 어떤 태스크에도 속하지 않습니다. 에이전트의 채팅 화면을 열고 메시지를 보내면 새 세션이 시작됩니다. 해당 에이전트와 함께하는 나만의 작업 공간입니다.
• 태스크에서의 에이전트 채팅은 해당 태스크에 속합니다. 태스크 댓글이 아니며, 태스크가 먼저 그 에이전트에게 할당되어 있어야 할 필요도 없습니다.

여기서 중요한 경계가 세 가지 있습니다. 각각이 합리적인 사람이라면 잘못 짐작할 만한 지점이기 때문입니다.

채팅은 댓글이 아닙니다. 에이전트 채팅에서 메시지를 보내도 태스크 댓글이 생성되지 않습니다. 태스크의 에이전트 채팅에서 메시지를 보내도 활동(Activity)에 댓글로 나타나지 않습니다. 태스크 댓글은 태스크 관련 논의를 위한 공식 기록으로 남고, 채팅은 두 화면 모두에서 별도의 기록입니다.

채팅은 기본적으로 팀에 공개되지 않습니다. 독립형 세션은 만든 사람에게 속하며, 다른 조직 구성원은 현재 채팅 API를 통해 그 세션에 접근할 수 없습니다. 태스크에서는 새 채팅 메시지가 담당자와 이미 그 대화에 참여한 사람들에게 알림을 보냅니다. 태스크를 팔로우하는 모든 사람에게 전달되지는 않습니다.

채팅에는 할당이 필요하지 않습니다. 태스크를 열고 그 에이전트가 담당자가 아니더라도 스페이스의 어떤 에이전트와든 해당 태스크에 대해 대화할 수 있습니다. 할당은 실행 책임을 정할 뿐, 대화 접근 권한을 정하지 않습니다.

애초에 에이전트가 무엇인지가 낯설다면(지침, 런타임, 스킬, 리포지토리를 갖춘 저장된 작업 구성), 에이전트 해설 글에서 그 기초를 다룹니다.

채팅에는 없고 태스크에는 있는 것은?

태스크는 Sharkly의 핵심 작업 단위입니다. 목표와 설명, 상태, 우선순위, 레이블, 책임자, 실행을 맡은 에이전트 또는 크루, 댓글과 첨부 파일, 그리고 에이전트의 실행 상태·추적·결과를 담습니다. 작업에 관한 모든 것이 태스크로 돌아오고, 접근 권한이 있는 사람은 누구나 이를 확인할 수 있습니다.

이 한 문장 안에는 채팅이 제공할 수 없는 네 가지 구체적인 보장이 숨어 있습니다:

1. 소유권. 태스크에는 담당자가 있습니다. 일이 멈추면 책임질 이름이 있죠. 채팅 세션에는 참여자 목록만 있을 뿐, 책임 구조가 없습니다.
2. 상태. 태스크는 팀이 정의한 워크플로를 따라 이동합니다. 백로그, 시작됨, 검토, 완료. 누구든 보드를 보면 물어보지 않고도 작업이 어디까지 진행됐는지 알 수 있습니다.
3. 실행 이력. 태스크에 대한 모든 실행은 흔적을 남깁니다. 언제 대기열에 들어갔고, 언제 시작됐고, 어떤 도구를 호출했고, 왜 실패했는지. 실행이 깨지면 기억을 더듬어 재구성하는 대신 실행 기록을 읽으면 됩니다.
4. 검토. 에이전트는 태스크를 사람의 답변이나 사람의 검토를 기다리는 상태로 남길 수 있고, 그 신호는 책임자의 받은편지함(Inbox)에 도착합니다. 승인은 분위기가 아니라 기록되는 단계입니다.

태스크 기반 실행에는 구조적인 장점도 있습니다. 태스크의 리포지토리 작업은 격리된 디렉터리, 보통 실행마다 별도의 git worktree에서 이루어지므로, 여러 태스크가 서로 충돌하지 않고 같은 코드베이스를 병렬로 변경할 수 있습니다. 그 동작 방식은 Sharkly가 에이전트를 병렬로 실행하는 방법에서 다룹니다. 할당된 태스크에 후속 댓글을 달면 또 다른 실행이 시작될 수 있고, Sharkly는 빠르게 이어지는 댓글을 하나로 합쳐 중복 작업이 생기지 않게 합니다.

실제 작업에 태스크가 적합한 이유를 보여주는 인간-에이전트 계약은 이렇습니다. 에이전트는 태스크에 대해 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다. 채팅 세션은 이 계약의 전반부만 지원합니다. 후반부를 지원하는 것은 태스크뿐입니다.

에이전트 채팅 vs 태스크 할당: 판단 기준표

판단 기준은 작업이 얼마나 큰지가 아니라, 무엇을 기록해야 하는지입니다.

묻고, 비교하고, 조사하고, 구체화할 때는 채팅을 사용하세요. 담당자, 상태, 완료 기준, 또는 누군가 승인해야 하는 결과가 필요할 때는 태스크를 사용하세요.

이 원칙이 교리가 되지 않도록 하는, 솔직한 반대 규칙 두 가지가 있습니다:

모든 질문마다 태스크를 만들지 마세요. "이 모듈은 무슨 일을 하나요?"는 티켓이 아니라 채팅이 어울립니다. 질문 모양의 태스크로 가득한 보드는 실제 작업을 묻어버리는 소음이며, 소음은 바로 사람과 에이전트를 위한 작업 관리 시스템이 막기 위해 존재하는 것입니다.

채팅이 슬그머니 프로젝트가 되게 두지 마세요. 대화에서 팀이 실행하거나 검토하거나 기억해야 할 무언가가 나온 순간, 그 대화는 세션의 범위를 넘어섰습니다. 팀이 결론을 봐야 한다면 태스크 설명이나 댓글에 옮겨 적으세요. 원래 세션은 나만의 개인 기록으로 남고, 태스크가 공유 기록이 됩니다.

세 가지 채팅 모드: 탐색, 계획, 실행

Sharkly의 채팅은 한 가지 동작만 하지 않습니다. 입력창에는 세 가지 모드가 있고, 선택한 모드는 세션에 저장되며, 어느 턴이든 그 전에 바꿀 수 있습니다.

탐색은 읽기 전용 조사입니다. 에이전트는 변경 없이 살펴보고, 설명하고, 비교하고, 요약합니다. 분석만 원하고 그 외에는 아무것도 원하지 않을 때 탐색을 선택해 두세요. "인증 흐름을 설명해 줘", "이 두 라이브러리 중 코드베이스가 이미 의존하는 건 어느 쪽이야?"에 맞는 모드입니다.

계획은 에이전트가 검토할 액션을 제안하도록 합니다. 에이전트는 하위 태스크가 포함된 계획된 태스크 초안을 작성하고, 사용자가 확인하기 전까지는 아무 일도 일어나지 않습니다. 제안을 수정할 수도, 작업을 시작하지 않고 확인만 할 수도, 확인과 동시에 바로 시작할 수도 있습니다. 계획 모드는 좋은 대화와 추적되는 약속을 잇는 다리이며, 채팅에서 태스크로 넘어가는 비용을 낮춰주는 모드입니다.

실행은 에이전트가 구성된 CLI를 통해 직접 행동하고 세션에 결과를 반환하도록 합니다. 다른 기본값을 설정하지 않았다면 새 채팅은 실행 모드로 시작합니다. 첫날부터 알아두면 좋은 점이죠. 읽기 전용 대화를 원한다면 에이전트가 뭔가를 시작한 뒤가 아니라 첫 메시지를 보내기 전에 탐색으로 바꾸세요.

모드에 대한 판단 기준은 앞의 더 큰 판단과 같습니다. 결과가 아직 질문인 동안에는 탐색이나 계획을 사용하세요. 채팅에서 실행은 팀 기록에서 빠져도 괜찮은 작업에만 사용하고, 나머지는 모두 태스크를 쓰세요.

실제로 채팅을 쾌적하게 만드는 동작이 몇 가지 있습니다. 실행 중에는 에이전트 출력이 세션에 스트리밍되고, 언제든 실행을 중지할 수 있습니다. 에이전트가 작업하는 동안 다른 메시지를 보내면, Sharkly는 병렬 중복 실행을 시작하는 대신 다음 턴을 위해 대기열에 넣습니다. 같은 브라우저에서 채팅을 전환해도 보내지 않은 초안 텍스트는 대화별로 유지됩니다. 세션은 이름을 바꾸고, 보관하고, 기록에서 다시 열 수 있으며, 보관된 세션은 읽을 수는 있지만 읽기 전용입니다.

채팅을 태스크로 넘기는 방법

인계는 두 화면이 만나는 지점이며, Sharkly 문서는 구체적인 순서를 제시합니다. 논의에서 확정할 만한 액션이 나오면:

1. 채팅에서 결과를 요약하세요. 에이전트에게 목표, 범위, 제약, 완료 기준을 한 메시지로 정리해 달라고 하세요. 이것이 태스크에 필요한 문단이고, 에이전트는 이미 그 내용을 쓸 맥락을 갖고 있습니다.
2. 계획 모드로 태스크 초안을 만드세요. 계획으로 전환하고 에이전트가 태스크와 하위 태스크를 제안하도록 하세요. 확인하기 전에 제안을 검토하고 수정하세요. 이 과정을 건너뛰고 직접 태스크를 만들어도 됩니다. 핵심은 사람이 약속의 형태를 잡는다는 점입니다.
3. 시작 여부와 함께 확인하세요. 확인하면 계획된 태스크가 생성됩니다. 지금 시작해야 하면 확인 후 시작하고, 스프린트나 의존성을 기다려야 하면 시작하지 않고 확인만 하세요.
4. 할당하세요. 담당자 컨트롤을 통해 태스크를 적절한 사람, 에이전트, 또는 크루에게 보내세요. 범위가 잘 정리된 채팅 요약이 있어야 할당이 가능합니다. 여러 역할이 필요한 작업이라면 리더 에이전트를 둔 크루가 단일 실행자 대신 태스크 전체를 맡을 수 있습니다.
5. 대화 기록이 아니라 맥락을 옮기세요. 태스크가 반드시 보존해야 할 내용은 설명이나 댓글에 복사하세요. 채팅 세션은 별개의 개인 기록으로 남습니다. 팀이 볼 수 없으니 팀의 기억으로 의존하지 마세요.

그 시점부터 피드백은 태스크의 규칙을 따릅니다. 태스크별 주고받기는 태스크의 에이전트 채팅에서 계속되고, 팀 전체가 봐야 할 결론은 활동 댓글에 남기며, 할당된 태스크에 적합한 댓글이 달리면 후속 실행이 시작됩니다. 결과, 차단 요소, 최종 응답은 태스크로 돌아오며, 이것이 나중의 검토를 가능하게 합니다.

배치에 관한 참고 하나. 에이전트에 할당된 태스크는 백로그에 있는 동안에는 시작되지 않습니다. 백로그는 주차 공간입니다. 태스크를 백로그에서 옮기면 컴퓨터와 런타임이 준비된 할당 에이전트가 시작되므로, 지금 채팅에서 작업을 준비해 두고 팀이 준비되면 풀어놓을 수 있습니다. 그 실행이 물리적으로 어디서 일어나는지는 별개의 문제이며, 컴퓨터 해설 글에서 다룹니다.

퀵 채팅: 태스크를 벗어나지 않고 태스크 맥락 활용하기

기본기를 익혔다면 알아둘 만한 세 번째 화면이 있습니다. 태스크 상세 화면의 헤더 툴바에 있는 퀵 채팅입니다. 현재 태스크를 맥락으로 실행되는, 저장된 프롬프트와 에이전트 조합이죠.

각 퀵 채팅에는 이름, 선택적 프롬프트, 선택한 에이전트 또는 크루, 공개 범위 설정이 있습니다. 비공개 퀵 채팅은 만든 사람만 볼 수 있고 실행할 수 있습니다. 공유 퀵 채팅은 스페이스의 모든 사람이 볼 수 있지만, 편집은 만든 사람만 할 수 있습니다. 하나를 선택하면 왼쪽에 태스크, 오른쪽에 채팅이 있는 분할 화면이 열리고, 프롬프트와 에이전트, 태스크 맥락이 함께 전송됩니다.

이렇게 하면 반복되는 질문이 클릭 한 번으로 처리됩니다. 태스크를 계획 에이전트에게 보내는 "이거 견적 내줘"라는 공유 퀵 채팅이나, 리포지토리를 인식하는 에이전트에 연결된 "관련 코드 찾기"는 스페이스의 모든 사람이 어떤 태스크에서든 실행할 수 있는 기능이 됩니다. 이는 스킬을 이끄는 것과 같은 논리입니다. 가치는 각자가 채팅을 더 많이 여는 데서가 아니라 좋은 설정을 공유하는 데서 나옵니다.

헷갈리지 말아야 할 동작 두 가지. 각 퀵 채팅 실행은 자체적인 태스크 수준 대화를 만들고, 그 대화는 태스크에 남습니다. 할당된 에이전트의 일반 채팅을 재사용하지 않습니다. 그리고 퀵 채팅을 삭제하면 저장된 구성이 사라질 뿐, 이미 만들어진 대화는 사라지지 않습니다.

여러분의 스택에 태스크 계층이 없다면?

많은 팀이 오케스트레이션 플랫폼 없이 에이전트를 운영합니다. 순수 터미널 세션, tmux 패널, 셸 스크립트 같은 방식이죠. 이런 구성도 이 글에서 말한 구분의 채팅 쪽 절반은 그럭저럭 처리합니다. 터미널 세션은 에이전트 채팅과 마찬가지로 사적이고 탐색적인 에이전트 대화니까요.

직접 구축한 스택에 없는 것은 나머지 절반입니다. 담당자도, 상태도, 동료가 열어볼 수 있는 실행 추적도, 검토 단계도, 결과가 기본적으로 도착하는 장소도 없습니다. 모든 약속 세션이 모든 질문 세션과 똑같아 보이고, 그 차이는 뭔가가 깨져서 아무도 이유를 재구성할 수 없을 때에야 드러납니다. Claude Squad, Conductor, tmux 기반 구성 비교에서 각 접근 방식이 어디서 멈추는지 살펴봅니다.

빠진 절반을 채우기 위해 프로세스를 다시 만들 필요는 없습니다. Sharkly는 Claude Code, Codex 또는 다른 실행 도구를 대체하지 않습니다. 팀이 이미 쓰는 도구 주위에 공유 태스크, 맥락, 검토 계층을 더하는 것이며, 모델 사용은 그 도구들에 구성된 구독이나 API 키를 통해 계속 이루어집니다. 터미널이 좋다면 임시 작업용으로 남겨두세요. 확정된 작업은 태스크로 보내고, 티켓이 이미 다른 곳에 있다면 트래커를 바꾸지 않고도 Jira 티켓을 에이전트에게 바로 보낼 수 있습니다.

세 가지 시나리오로 살펴보기

불안정한 테스트. 한 엔지니어가 테스트가 간헐적으로 실패하는 것을 발견합니다. 그녀는 탐색 모드에서 팀의 코드 리더 에이전트와 채팅을 엽니다. "병렬 실행에서 auth_session_test가 왜 실패할까?" 10분쯤 코드를 읽은 뒤, 에이전트는 경쟁 조건이 있는 공유 픽스처를 지목합니다. 이제 이건 약속입니다. 그녀는 계획 모드로 전환하고, 에이전트가 수정 범위와 완료 기준("병렬 실행 50회 연속 통과")이 담긴 SH-341 태스크 초안을 작성합니다. 그녀는 확인하고 시작한 뒤 수정 담당 에이전트에게 할당합니다. 조사 내용은 그녀의 채팅 기록에 남습니다. 수정, diff, 검토는 SH-341에 남습니다.

아키텍처 질문. 한 테크 리드가 큐를 도입하면 세 개 서비스에 어떤 비용이 들지 알고 싶어 합니다. 며칠간의 조사지만 여전히 질문이므로, 그녀는 독립형 채팅 세션에 남겨두고 "큐 도입 검토"로 이름을 바꿉니다. 일주일에 걸쳐 그녀는 세션으로 돌아와 후속 질문을 하고, 에이전트가 옵션을 비교하도록 합니다. 리더십이 승인하면, 세션의 최종 요약이 에픽 수준 태스크의 설명이 되고, 계획 모드에서 하위 태스크로 분해됩니다. 어느 순간에도 어중간하게 추적된 것은 없습니다.

계속 반복되던 스탠드업 질문. 한 팀이 매일 아침 누군가가 검토 중인 태스크에 대해 어제 변경된 내용을 요약해 달라고 에이전트에게 묻는다는 걸 알아챕니다. 한 사람이 이를 "여기서 뭐가 바뀌었어?"라는 공유 퀵 채팅으로 저장하고 리포지토리를 인식하는 에이전트에 연결합니다. 질문을 다시 타이핑할 일이 없어지고, 모든 실행이 실행한 태스크에 대화를 남깁니다. 요청 시가 아니라 일정에 따라 요약이 필요하다면, 같은 발상을 자동화(Automations)로 발전시키면 됩니다.

세 가지 모두에서 같은 규칙이 화면을 결정합니다. 질문은 채팅에 남고, 약속은 태스크를 갖고, 답이 작업을 함축하는 순간 인계가 일어납니다.

결론

탐색할 때는 AI 에이전트와 채팅하고, 확정할 때는 태스크를 할당하세요. Sharkly는 두 화면을 의도적으로 분리해, 보드에는 질문이 아니라 실제 작업이 기록되고 질문은 아무도 읽지 않는 기록 속으로 사라지지 않게 합니다. 채팅 세션은 여러분의 것입니다. 태스크는 팀의 것이며, 맥락과 진행 상황, 차단 요소, 결과, 사람의 검토가 요청부터 릴리스까지 그 위에 계속 보입니다.

이 구분은 도입 비용이 들지 않습니다. 두 화면 모두 이미 눈앞에 있으니까요. 에이전트와 채팅을 열고 평소라면 코드베이스를 뒤져서 찾았을 무언가를 물어보세요. 그 대화에서 확정할 만한 것이 처음 나오면 계획 모드로 전환해 태스크 초안을 작성하게 하세요. 컴퓨터 하나를 연결하고, 에이전트 하나를 만들고, 별것 아닌 일로 두 방식 모두 시도해 보세요. 준비되면 플래그십 개요에서 나머지 플랫폼을 다룹니다.

자주 묻는 질문

태스크를 할당하지 않고도 에이전트와 그 태스크에 대해 채팅할 수 있나요?

네. 태스크를 열고 스페이스의 어떤 에이전트와든 채팅을 시작하세요. 할당은 대화의 전제 조건이 아닙니다. 할당은 누가 태스크를 실행하는지를 정할 뿐, 누구와 대화할 수 있는지를 정하지 않습니다.

채팅 메시지가 태스크의 활동 피드에 나타나나요?

아니요. 댓글은 팀 전체를 위해 활동에 나타납니다. 태스크의 에이전트 채팅은 담당자와 이미 그 대화에 참여한 사람들에게 알림을 보내며, 두 화면 모두에서 댓글과 별도로 저장됩니다.

동료가 내 독립형 에이전트 채팅 세션을 읽을 수 있나요?

아니요. 각 독립형 세션은 만든 사람에게 속하며, 다른 조직 구성원은 현재 채팅 API를 통해 접근할 수 없습니다. 결론이 팀에 중요하다면 태스크 설명이나 댓글에 복사하세요.

오프라인이거나 보관된 에이전트에게 메시지를 보내면 어떻게 되나요?

오프라인 에이전트는 생각 중이나 대기 중으로 표시되지 않고 오프라인으로 표시되므로, 오지 않을 답변을 기다리지 마세요. 보관된 에이전트는 새 메시지를 받을 수 없습니다. 입력창이 비활성화되지만 세션 기록은 계속 읽을 수 있습니다.

어떤 채팅 모드로 시작해야 하나요?

기본값을 바꾸지 않으면 새 채팅은 실행 모드로 시작합니다. 변경 없이 분석만 원한다면 첫 메시지를 보내기 전에 탐색으로 전환하세요. 에이전트가 검토하고 확인할 태스크를 제안하길 원할 때는 계획을 사용하세요.

에이전트와 채팅할 때 태스크 실행 설정이 사용되나요?

네. 채팅 실행도 동일한 에이전트 구성을 거칩니다. 지침, 런타임, 컴퓨터 말입니다. 실행 모드에서 에이전트는 태스크 실행을 구동하는 것과 같은 장치인, 구성된 CLI를 통해 행동합니다.

채팅은 언제 태스크가 되어야 하나요?

대화에서 누군가 소유하거나 검토하거나 기억해야 할 작업이 나오는 순간입니다. 목표, 범위, 제약, 완료 기준을 요약하고, 계획 모드나 직접 작성으로 태스크 초안을 만든 뒤 할당하세요. 채팅 기록은 팀의 기록이 아닙니다.

두 사람이 에이전트와의 채팅 세션 하나를 공유할 수 있나요?

독립형 세션은 단일 소유자이므로 불가능합니다. 태스크에서는 에이전트 채팅이 담당자와 이전 참여자에게 알림을 보내므로, 소규모 그룹이 태스크 수준 대화 하나를 함께 따라갈 수 있습니다. 팀 전체가 볼 논의에는 태스크 댓글을 사용하세요.