Claude Code의 변화는 agent(목표를 받아 도구를 사용해 작업하는 AI)가 코드를 작성하는 데서 그치지 않는다는 점에 있습니다. Claude Mods를 이용하면 작업 흐름과 터미널 화면도 바꿀 수 있습니다. 팀에서는 Claude Tag를 통해 같은 프로젝트 맥락을 공유하며 일합니다. 다만 여러 agent가 상시 실행되며 하나의 화면에서 협업하는 모습은 현재의 사용 방식과 구분해야 할 발전 방향입니다.
작업 환경을 바꾸는 Claude Mods
Claude Mods는 Claude Code에 기능을 더하는 확장 구조입니다. 이전의 연결 방식이 특정 시점에 외부 명령이나 스크립트를 실행하는 데 초점을 맞췄다면, Mods는 TypeScript 실행 환경 안에서 작동합니다. 대화 횟수, 메시지 기록, 시스템 이벤트 같은 정보를 바탕으로 작업 흐름을 바꾸고, 터미널에 표시되는 요소도 조정할 수 있습니다.
활용 예는 단순한 화면 꾸미기를 넘어섭니다. 작업이 끝났는지 별도의 sub-agent(주 agent에서 분기해 보조 작업을 맡는 agent)가 확인하고, 완료됐다면 사용자가 변경 사항을 이해했는지 묻는 퀴즈를 띄우는 구성을 만들 수 있습니다. 코드를 작성하는 동안 사용한 가정을 기록해 마지막에 모아 보여 주는 구성도 가능합니다. 이렇게 분기한 sub-agent는 주 대화에서 이미 처리한 입력의 캐시를 이어받아 적은 비용으로 빠르게 실행되고, 검토 과정의 메시지가 본래 작업 대화에 쌓이는 것도 줄일 수 있습니다.
이는 agent가 자신의 작업 도구를 필요에 맞게 조정할 수 있다는 뜻입니다. 그러나 모든 설정을 자동으로 맡기는 것과는 다릅니다. 예를 들어 요청의 난도를 판단해 사용할 모델을 바꾸는 기능을 Mods로 구성할 수 있지만, 어려운 요청을 잘못 분류할 위험 때문에 자동 모델 선택이 기본 동작으로 제공되는 것은 아닙니다. 수정 가능성만큼 어떤 변경이 실제로 도움이 되는지 확인하는 일이 중요합니다.
▲ 작업 흐름의 확장
잘 쓰는 출발점은 설정을 늘리는 일이 아닙니다
작업 환경을 바꿀 수 있다고 해서 지시를 많이 쌓아야 하는 것은 아닙니다. CLAUDE.md는 프로젝트 지침을 담는 파일이지만, 새 프로젝트를 시작할 때 예상되는 실패를 규칙으로 미리 채우는 방식은 권장되지 않습니다. 같은 실수가 반복해서 확인됐을 때 필요한 지침을 추가하고, 모델을 바꾼 뒤에는 이전 지침이 여전히 필요한지 다시 살펴봐야 합니다. 이전 모델의 문제를 피하려고 만든 규칙이 새 모델의 판단까지 제한할 수 있기 때문입니다.
설정보다 먼저 명확히 할 것은 작업의 목적과 제약입니다. prompt(모델에 전달하는 지시와 맥락)에 시제품인지 실제로 사용할 코드인지, 어떤 설계 결정을 이미 내렸는지를 담으면 뒤늦게 결과를 되돌리는 일을 줄일 수 있습니다. Ask User Question은 agent가 구현 전에 불분명한 요구를 확인하는 기능입니다. 데이터 구조나 호출 관계처럼 결과에 큰 영향을 주는 선택은 코드 작성 전에 사람과 확인하는 편이 낫습니다.
작업에 따라 모델이 추론에 들이는 노력 수준(effort)도 달리할 수 있습니다. 보안 검토와 코드 리뷰에는 높은 effort가 결과를 크게 끌어올리지만, 단순한 화면 구현은 낮은 effort로 충분하고, 예외 상황을 챙겨야 하는 API 구현은 중간 수준이 알맞습니다. 모델이 실패할 때는 올바른 해법을 검토하고도 스스로 기각한 경우가 많습니다. 그래서 구현 전에 결정 사항과 구현 계획을 기록하게 하면, 사람이 기각된 선택지까지 보고 방향을 확인할 수 있습니다.
개인 도구에서 팀의 공동 작업 공간으로
현재의 팀 협업 사례는 Claude Tag에서 볼 수 있습니다. Slack의 공유 공간에서 팀원들이 같은 프로젝트 맥락을 놓고 Claude에 물을 수 있습니다. 예를 들어 개발자가 변경 사항을 일일이 설명하는 대신, 법무 담당자가 예정된 코드 변경에 관해 직접 확인하는 방식입니다. 여러 담당자가 동시에 맥락을 살펴야 하는 장애 대응에도 이러한 공유 방식이 쓰입니다.
한편 더 넓은 구상은 인터페이스, 모델의 추론, 실제 실행 환경을 분리하는 것입니다. Claude가 만드는 대화형 화면인 Artifacts는 정보를 보여 주는 데 그치지 않고 상태를 저장하는 데이터베이스를 갖추고, 구조화된 정보를 Claude에 다시 전달할 수 있습니다. MCP(모델과 외부 도구를 연결하는 규격)를 통하면 여러 Claude agent가 같은 데이터에 접근해 작업할 수도 있습니다. 이를 바탕으로 사용자가 공동 작업 화면에서 진행 상황을 확인하고 업무를 나누는 형태가 제시됩니다.
| 구분 | 현재의 사용 방식 | 발전 방향 |
|---|---|---|
| 실행 | 개인 컴퓨터 또는 원격 환경에서 작업 | 클라우드 agent가 로컬·원격 실행을 조율 |
| 협업 | Claude Tag로 팀의 공유 맥락에 접근 | Claude Projects를 더 넓은 팀 환경으로 확장 |
| 화면 | 터미널과 Artifacts를 작업에 활용 | 여러 agent의 상태를 보는 공동 작업 화면 |
이 방향이 모든 팀에서 완성된 형태로 쓰인다는 뜻은 아닙니다. Claude Projects는 개인 중심의 경험에서 팀 공유 환경으로 확장하는 방향이며, 화면·추론·실행을 분리한 협업 구조도 계속 발전 중입니다. agent를 여러 개 두고 작업을 나누면 작업에 쓰는 token(모델이 처리하는 텍스트 단위)과 지연 시간이 늘 수 있다는 점도 함께 고려해야 합니다.
▲ 팀 협업과 권한 경계
도입 전에는 변경 효과와 권한을 확인합니다
작업 환경을 수정할 때는 기능을 더하는 일 자체보다 효과를 검증하는 일이 우선입니다. Mods나 다른 기능을 적용했다면 작은 실제 작업에서 결과가 나아졌는지 시험하고, 불필요해진 지침은 걷어내는 편이 좋습니다. 새 프로젝트라면 CLAUDE.md를 비워 둔 채 시작해 반복되는 문제만 기록할 수 있습니다.
팀 협업에서는 권한 경계가 더 중요합니다. 한 agent가 개인의 연결 도구와 팀의 공유 자료를 함께 다룰 때, 누가 어떤 데이터에 접근할 수 있는지 불분명하면 다른 공간으로 정보가 넘어갈 위험이 있습니다. 외부 양식처럼 검증되지 않은 입력이 팀 채널로 바로 들어오면, 그 안의 문구가 넓은 권한을 가진 agent를 조종하려는 prompt injection(데이터에 숨긴 지시로 모델을 오도하는 공격)의 통로가 될 수도 있습니다. 외부에서 들어온 내용과 내부 작업 공간을 분리하고, 실행 환경을 격리하며, 쓰기 권한과 승인 범위를 좁혀야 합니다. Claude Code가 향하는 방향은 사람이 개발에서 빠지는 모습이라기보다, 사람이 목표와 권한을 정하고 수정 가능한 도구와 여러 agent의 작업을 확인하는 방식에 가깝습니다.