AI 코딩의 단위가 ‘채팅’에서 ‘프로젝트’로 바뀐다

AI 코딩을 처음 쓸 때는 꽤 단순했다.

기능 하나를 설명하고 결과가 나오면 다음 기능을 요청했다. 문제가 생기면 새로운 세션을 열고 다시 설명했다.

그런데 프로젝트가 커질수록 코드를 만드는 것과 별개로 사람이 관리해야 할 일이 늘어났다.

어떤 작업을 먼저 할지 정해야 했고, 서로 연결된 기능을 나눠야 했고, 한쪽을 수정한 뒤 다른 부분이 영향을 받지 않았는지도 다시 확인해야 했다.

여러 coding agent를 사용해 앱을 만들면서 느낀 건, 모델이 코드를 만들어주는 속도보다 내가 작업을 어떻게 나누고 관리하느냐가 더 중요하다는 점이었다.

처음에는 AI에게 기능 하나를 설명하고 결과가 나오면 다음 작업을 이어가는 방식으로 사용했다. 그런데 프로젝트가 커질수록 여러 기능이 서로 얽히고, 한쪽을 수정하면 다른 부분을 다시 확인해야 했으며, 이미 검증한 내용을 또 확인하거나 여러 세션의 맥락을 내가 직접 이어줘야 하는 일이 많아졌다.

이 경험 때문에 Claude Code Projects에서 내가 주목하는 부분도 단순히 여러 작업을 동시에 돌릴 수 있다는 점이 아니다.

AI 코딩의 관리 단위가 하나의 채팅이나 세션에서 하나의 프로젝트 목표로 커지고 있다는 점이다.

코드 생성보다 어려웠던 것은 작업 관리였다

AI가 코드를 만드는 능력이 좋아질수록 사람이 코드를 직접 입력해야 하는 순간은 줄어들 수 있다.

하지만 실제 프로젝트에서는 새로운 관리 일이 생긴다.

무엇을 먼저 시킬 것인지.

기능을 어디까지 나눌 것인지.

어떤 작업끼리 동시에 진행해도 되는지.

결과가 나오면 무엇을 다시 확인할 것인지.

그리고 어느 상태를 완료라고 판단할 것인지.

결국 사람이 코드를 직접 쓰는 시간은 줄어들었지만, 대신 무엇을 먼저 시킬지, 작업을 어디까지 쪼갤지, 완료 기준을 무엇으로 둘지, 어떤 결과를 다시 검증할지를 결정하는 일이 더 중요해졌다.

이건 단순한 프롬프트 작성과는 조금 다른 문제다.

AI에게 좋은 문장을 입력하는 것보다 프로젝트 전체를 이해하고 작업의 경계와 검증 지점을 정하는 일이 필요해진다.

Claude Code Projects가 바꾸려는 부분

Anthropic은 공식 발표에서 Claude Code의 Projects를 재설계했다고 설명한다.

Anthropic 발표 기준, 사용자가 프로젝트 목표와 repo 또는 context를 지정하면 Claude가 작업 범위를 정하고 여러 thread에 작업을 나눈다. 각 thread는 Claude Code cloud session으로 동작하고, coordinator가 전체 진행을 관리하며 결과를 조정·검토한 뒤 최종 결과를 조립한다.

Projects에는 thread 사이에서 공유되는 memory와 library도 포함되어 이전 결정과 프로젝트 자료를 다음 작업에서 이어서 활용하도록 설계됐다.

Anthropic은 재설계된 Projects에서 프로젝트 목표를 기준으로 여러 Claude Code cloud session을 조정하는 구조를 소개했다.

출처: Anthropic

여기서 중요한 것은 thread가 여러 개라는 사실 자체가 아니다.

지금까지 사람이 직접 맡았던 작업 분배와 진행 상태 관리, 결과 취합의 일부를 프로젝트 안의 coordinator가 맡도록 설계했다는 점이다.

내가 주로 경험했던 방식과 비교하면 차이가 조금 더 선명해진다.

기존에는 내가 기능을 나누고 각 세션에 맥락을 전달한 뒤 결과를 다시 확인하는 일이 많았다.

Projects가 제시하는 구조에서는 하나의 프로젝트 목표 아래에서 작업 범위 설정, thread 분배, 진행 상황 확인, 결과 검토와 조립이 하나의 흐름으로 묶인다.

이 변화가 실제 프로젝트에서 어느 정도까지 안정적으로 작동하는지는 별개의 문제다.

Claude Code Projects 자체를 충분히 사용해 검증한 경험은 아직 없기 때문에, 실제 생산성 향상이나 개발 속도 개선 같은 성과는 이 글에서 주장하지 않는다.

사람이 Agent를 관리하던 방식도 달라질 수 있다

여러 AI 세션을 동시에 사용하는 것 자체는 새로운 경험이 아니다.

문제는 세션이 늘어날수록 사람이 각각의 상태를 기억하고 결과를 연결해야 한다는 데 있었다.

어떤 세션이 무엇을 수정했는지.

어떤 결정이 다른 작업에도 영향을 주는지.

이미 확인한 내용인지 다시 검증해야 하는지.

프로젝트가 길어질수록 이런 관리 비용은 눈에 잘 보이지 않지만 계속 쌓인다.

Claude Code Projects에서 흥미로운 부분은 이 조정 역할의 일부가 AI 시스템 안으로 들어간다는 점이다.

VECTORLOG 개념도. 세션별 작업을 사람이 직접 연결하던 방식과 프로젝트 목표 아래 여러 작업을 조정하는 방식을 비교한다.

출처: VECTORLOG

사람이 모든 thread를 직접 움직이는 대신 프로젝트 목표를 설정하고 coordinator가 작업을 나누도록 한다.

물론 이것이 사람이 빠진다는 뜻은 아니다.

오히려 사람이 결정해야 할 위치가 조금 달라질 수 있다.

어떤 목표를 줄 것인지.

무엇을 절대 건드리면 안 되는지.

어떤 테스트를 통과해야 하는지.

어느 단계에서 사람이 직접 확인해야 하는지.

어떤 결과를 최종 완료라고 볼 것인지.

AI가 작업 분배까지 맡기 시작하면 이런 기준이 더 중요해질 수 있다.

프롬프트보다 완료 기준이 중요해진다

AI 코딩을 하다 보면 모델에게 얼마나 자세한 지시를 해야 하는지에 집중하기 쉽다.

나 역시 처음에는 프롬프트를 더 구체적으로 쓰면 결과가 좋아질 것이라고 생각했다.

하지만 프로젝트가 커지면서 생각이 조금 달라졌다.

앞으로 중요한 능력은 AI에게 코드를 자세히 설명하는 것보다, 무엇을 만들 것인지와 어떤 상태를 완료라고 볼 것인지 명확하게 정의하는 능력에 더 가까워질 수 있다.

예를 들어 기능 하나를 만든다고 해도 완료라는 말은 여러 의미를 가질 수 있다.

화면이 보이면 끝인지.

실제 데이터가 연결되어야 하는지.

권한까지 확인해야 하는지.

기존 기능이 깨지지 않았는지 테스트해야 하는지.

배포된 환경에서도 동일하게 작동해야 하는지.

이 기준이 없으면 Agent가 작업을 빠르게 진행해도 사람이 다시 처음부터 확인해야 한다.

반대로 완료 조건과 검증 지점이 명확하면 AI에게 맡길 수 있는 작업의 경계도 더 선명해진다.

프로젝트 단위 AI는 coding에만 머물까

Claude Code Projects는 coding 제품이지만, 이 구조 자체는 다른 지식 업무를 생각하게 만든다.

Research도 하나의 질문을 여러 조사 작업으로 나눌 수 있다.

Marketing도 시장 조사, 콘텐츠 기획, 자료 확인, 배포 준비처럼 여러 작업으로 분리된다.

Data Analysis도 데이터 확인, 분석, 결과 검토, 보고서 작성처럼 단계가 나뉜다.

다만 Claude Code Projects 하나만으로 이런 업무 전체가 같은 방식으로 바뀐다고 단정할 수는 없다.

여기서 볼 수 있는 것은 하나의 방향이다.

AI에게 개별 작업을 하나씩 요청하던 방식에서, 목표를 주고 여러 작업을 조정하게 만드는 방식으로 인터페이스가 확장되고 있다는 점이다.

그 방향이 실제 업무에 자리 잡는다면 사람의 역할도 세부 작업 수행보다 목표·우선순위·검증 기준을 설계하는 쪽에 더 가까워질 수 있다.

AI 코딩의 다음 질문

지금까지 AI 코딩에서 자주 했던 질문은 이랬다.

어떤 모델이 코드를 더 잘 짜는가.

어떤 프롬프트를 쓰면 원하는 결과가 나오는가.

어떤 coding agent를 써야 하는가.

앞으로는 질문 하나를 더 추가해야 할 것 같다.

나는 AI에게 프로젝트의 완료 상태를 제대로 설명할 수 있는가.

Agent가 코드를 작성하고 작업을 나누고 결과를 합치는 범위가 넓어질수록, 사람이 모든 과정을 직접 수행할 필요는 줄어들 수 있다.

대신 무엇을 만들 것인지, 어디까지 맡길 것인지, 어디에서 멈추고 확인할 것인지 결정하는 일은 남는다.

Claude Code Projects에서 내가 보는 변화는 바로 그 지점이다.

AI 코딩의 단위가 채팅에서 프로젝트로 커지고 있다면, 사람도 이제 프롬프트 하나보다 프로젝트 전체의 기준을 더 잘 정의해야 한다.