팀의 업무는 이메일, 채팅, 문서, 태스크, CRM 사이를 오갑니다. 문제는 이 이동 자체보다, 이동하는 순간 맥락이 잘린다는 데 있습니다. 고객의 메일에서 나온 요청은 태스크 관리 도구로 옮겨지고, 결정 사항은 문서에 복사되며, 관련 대화는 채널에 남습니다. 시간이 지나면 왜 이 일이 시작됐는지 추적하기 어려워집니다.
macro-inc/macro는 이 단절을 하나의 인터페이스로 가리는 대신, 데이터 구조 차원에서 연결하려고 합니다. README에 따르면 이메일·메시지·문서·태스크·에이전트·통화·파일·Pull Request·CRM이 같은 백엔드를 공유하고, 표면 사이의 참조는 bidirectional graph로 저장됩니다. 고객 지원 메일에서 만든 태스크가 원본 맥락과 이어지고, 문서 안에 이메일을 @링크로 삽입하며, 채널에서 논의된 내용과 CRM 기록도 연결할 수 있습니다.
사용 흐름도 이 철학을 반영합니다. 메일, 메시지, @멘션, 처리할 태스크를 하나의 목록에서 키보드로 탐색하고, 메일에서 바로 태스크를 만들 수 있습니다. 채널은 처음 몇 개 답글을 인라인으로 보여준 뒤 나머지를 스레드로 접어 기술적 논의의 밀도를 높입니다. 문서는 CRDT 기반 실시간 협업을 사용하고, 제품은 SolidJS와 Rust로 구축됐습니다.
에이전트는 이 그래프 위에서 팀 단위 메모리를 사용합니다. Macro는 메일 첨부 PDF를 찾을 때 스레드와 첨부를 따로 오가는 대신 통합 검색으로 첨부 파일을 직접 찾을 수 있고, AI 채팅에서 메일을 작성·편집·전송할 수 있다고 설명합니다. 기억이 여러 앱에 흩어지지 않으면, 에이전트가 단순한 문답을 넘어 검색과 실행을 맡을 여지가 커집니다.
동시에 통합은 새로운 경계 문제를 만듭니다. 스레드 링크를 다른 채널에 공유하고 이메일을 DM이나 채널에 보낼 수 있는 구조는 협업을 빠르게 하지만, 어떤 정보가 누구에게까지 이어지는지 명확해야 합니다. 특히 에이전트가 팀 메모리를 검색하고 행동하는 환경에서는 권한 상속, 검색 범위, 공유 이후의 회수, 변경 이력과 감사 가능성이 핵심 운영 조건이 됩니다. README가 보여주는 연결성은 강력하지만, 연결의 반대편인 격리와 통제까지 제품 경험으로 완성해야 합니다.
그래서 Macro를 평가할 때는 기능 개수보다 업무 그래프가 실제로 얼마나 잘 작동하는지 봐야 합니다. 원본 메일에서 태스크로, 태스크에서 대화와 PR로 양방향 이동이 자연스러운지, 에이전트가 같은 연결을 권한에 맞게 활용하는지, 정보가 잘못 공유됐을 때 범위를 되돌릴 수 있는지가 관건입니다. 도구를 하나로 합치는 것보다 어려운 일은, 팀의 기억을 연결하면서도 필요한 경계를 잃지 않는 것입니다.