저장소(Repository)는 끝났다. AI에게는 워크스페이스(Workspace)가 필요하다.

AI 에이전트(AI agents)가 실패하는 이유는 코드를 읽지 못해서가 아닙니다.

그들이 실패하는 이유는 저장소(repositories)가 소프트웨어 시스템(software systems)을 설명하지 못하기 때문입니다.

모두가 AI가 코드를 이해한다고 말합니다.

그것은 완전히 사실이 아닙니다.

AI는 텍스트(text)를 이해합니다.

저장소는 텍스트입니다.

소프트웨어 시스템은 그렇지 않습니다.

그 차이는 에이전트에게 프로덕션 변경(production change)을 요청하기 전까지는 작게 들릴 수 있습니다.

에이전트는 파일을 읽을 수 있습니다. 함수를 요약할 수 있습니다. 올바르게 보이는 패치(patch)를 생성할 수 있습니다.

하지만 시스템의 어느 부분이 리팩터링(refactor)하기에 안전한지 알고 있을까요?

어떤 서비스가 결제(billing) 뒤에 위치하는지 알고 있을까요?

어떤 폴더가 데모 경로이고 어떤 폴더가 고객 대상(customer-facing)인지 알고 있을까요?

변경 사항을 배포(ship)하기 전에 무엇을 검증해야 하는지 알고 있을까요?

대개는, 모릅니다.

그리고 그것이 진짜 문제입니다.

저장소는 시스템이 아니다

에이전트가 다음 두 파일을 본다고 상상해 보세요:

auth.ts
billing.ts

언어 모델(language model)에게 두 파일 모두 읽을 수 있는 컨텍스트(context)입니다.

그것들은 텍스트입니다.

하지만 프로덕션 팀에게 그것들은 완전히 다른 의미를 가질 수 있습니다.

한 파일은 데모 흐름(demo flow)의 일부일 수 있습니다.

다른 파일은 송장(invoices), 결제(payments), 고객 신뢰(customer trust), 컴플라이언스(compliance), 그리고 릴리스 게이트(release gates)와 관련이 있을 수 있습니다.

코드만으로는 항상 그 차이를 드러내지 않습니다.

따라서 중요한 질문은 이것이 아닙니다:

에이전트가 파일을 읽을 수 있는가?

중요한 질문은 이것입니다:

에이전트는 시스템 내부에서 이 파일이 무엇을 의미하는지 어떻게 아는가?

대부분의 AI 코딩 워크플로우(AI coding workflows)는 여전히 그 차이를 평면화(flatten)합니다.

그들은 소프트웨어를 파일의 더미로 취급합니다.

하지만 프로덕션 소프트웨어는 평면적이지 않습니다.

일반적인 멘탈 모델(mental model)은 불완전하다

많은 사람들이 AI가 소프트웨어를 이해하는 방식은 다음과 같이 상상합니다:

그 모델은 설명을 위해서는 유용합니다.

하지만 엔지니어링(engineering)을 위해서는 충분하지 않습니다.

그 모델은 텍스트가 모델에 어떻게 도달하는지는 알려줍니다.

하지만 모델이 결과(consequence)를 어떻게 이해하는지는 알려주지 않습니다.

저장소는 에이전트에게 무엇이 존재하는지는 알려줄 수 있습니다.

그것은 에이전트에게 무엇이 중요한지는 신뢰성 있게 알려주지 못합니다.

이를 위해서는 또 다른 계층(layer)이 필요합니다.

워크스페이스(Workspace)는 누락된 계층이다

워크스페이스는 단순히 더 큰 폴더가 아닙니다.

그것은 소프트웨어 시스템의 운영 경계(operating boundary)입니다.

워크스페이스는 단일 소스 파일에 거의 존재하지 않는 다음과 같은 정보들을 포함합니다:

• 소유권 (ownership)
• 의존성 (dependencies)
• 정책 (policies)
• 계약 (contracts)
• 검증 경로 (verification paths)
• 릴리스 가정 (release assumptions)
• 운영 리스크 (operational risk)
• 고객 영향 (customer impact)

다시 말해:

저장소(Repository)는 에이전트에게 무엇이 존재하는지 알려줍니다.

워크스페이스(Workspace)는 에이전트에게 무엇이 중요한지를 알려줍니다.

이것이 바로 변화(shift)입니다.

더 큰 컨텍스트 윈도우(Context Window)가 이를 해결해주지는 않는다

해답이 단순히 더 많은 컨텍스트(context)라고 생각하기 쉽습니다.

더 많은 파일.

더 많은 토큰 (tokens).

더 많은 검색 (retrieval).

더 큰 프롬프트 창 (prompt window).

하지만 이 문제는 단순히 크기에 관한 것이 아닙니다.

모델에게 백만 개의 토큰을 주더라도 여전히 다음 질문에 답하지 못할 수 있습니다:

무엇을 가볍게 변경해서는 안 되는가?

그러한 정보는 종종 코드로 작성되어 있지 않습니다.

그것은 아키텍처 결정, 팀 소유권, 배포 경계, 과거의 장애 사례, 정책 규칙, 그리고 검증 습관 속에 존재합니다.

때로는 암시적(implicit)이고,

때로는 분산되어 있으며,

때로는 숙련된 엔지니어들이 알고 있기 때문에 존재하기도 합니다.

이것이 바로 저장소 컨텍스트(repository context)와 워크스페이스 컨텍스트(workspace context)가 서로 다른 이유입니다.

저장소 (Repository)	워크스페이스 (Workspace)
파일 (Files)	시스템 (System)
...

더 큰 프롬프트 창은 에이전트에게 더 많은 텍스트를 제공합니다.

워크스페이스 모델은 에이전트에게 지도(map)를 제공합니다.

이것들은 서로 다른 능력(capabilities)입니다.

RAG(Retrieval-Augmented Generation)로도 충분하지 않다

검색(Retrieval)은 유용합니다.

RAG는 파일을 찾을 수 있습니다.

문서를 가져올 수 있습니다.

그리고 다음과 같이 말할 수 있습니다:

여기 billing.ts 파일이 있습니다.

하지만 프로덕션급(production-grade) 에이전트에게는 검색된 텍스트 그 이상이 필요합니다.

에이전트에게는 유도된 이해(derived understanding)가 필요합니다.

그것은 다음과 더 가까운 무언가가 필요합니다:

결제(Billing) 시스템은 송장(invoices)을 관리합니다.
결제(payments)에 관여합니다.
고객과 직접 맞닿아 있습니다.
...

그것은 단순한 검색(retrieval)이 아닙니다.

그것은 워크스페이스 인텔리전스(workspace intelligence)입니다.

RAG는 정보를 검색(retrieve)합니다.

워크스페이스 인텔리전스(Workspace Intelligence)는 이해(understanding)를 도출(derive)합니다.

에이전트에게 부족한 것은 운영적 가중치(Operational weight)입니다

두 파일이 똑같이 읽기 쉬울 수 있지만, 운영 측면에서는 불균등할 수 있습니다.

이것이 대부분의 에이전트 시스템이 여전히 평면적으로 처리하고 있는 부분입니다.

어떤 파일은 리팩터링(refactor)하기에 안전할 수 있습니다.

반면 다른 파일은 결제(billing), 인증(authentication), 컴플라이언스(compliance), 또는 릴리스 검증(release verification) 뒤에 위치할 수 있습니다.

에이전트는 무언가를 변경하기 전에 그 차이를 알아야 합니다.

저는 이를 **운영적 가중치(operational weight)**라는 용어로 부르는 것을 좋아합니다.

운영적 가중치는 간단한 질문에 답합니다:

이것을 변경할 때 얼마나 주의를 기울여야 하는가?

이는 설정 파일(config file)의 단일 필드로 존재하는 것이 아닙니다.

그것은 워크스페이스(workspace)로부터 발현됩니다.

데모 컴포넌트(demo component)는 운영적 가중치가 낮습니다.

결제 계약(payment contract)은 운영적 가중치가 높습니다.

공유 인증 미들웨어(shared authentication middleware)는 파일 자체의 크기가 작더라도 매우 높은 운영적 가중치를 가질 수 있습니다.

코드 크기가 시스템적 중요도(system significance)와 동일한 것은 아닙니다.

에이전트에게는 중요도가 필요합니다.

구조(Structure)와 상태(state)는 다릅니다

여기에 또 다른 함정이 있습니다.

워크스페이스에 관한 모든 사실이 동일한 수명(lifetime)을 갖는 것은 아닙니다.

어떤 사실은 구조적(structural)입니다.

어떤 사실은 실시간 상태(live state)입니다.

소유권(Ownership)은 천천히 변할 수 있습니다.

의존성 그래프(dependency graph)는 며칠 동안 유효할 수 있습니다.

상태 확인(health check)은 몇 초 동안만 유효할 수 있습니다.

릴리스 상태(release status)는 바로 지금 검증되어야 할 수도 있습니다.

구조(Structure)는 에이전트에게 무엇이 중요한지를 알려줍니다.

상태(State)는 에이전트에게 지금 무엇이 사실인지를 알려줍니다.

신뢰할 수 있는 AI는 이 두 가지 모두가 필요합니다.

만약 에이전트가 구조(Structure)를 상태(State)로 취급한다면, 안정적인 사실들을 다시 발견하는 데 시간을 낭비할 수 있습니다.

그것은 비효율적이지만, 대개 안전합니다.

하지만 에이전트가 상태(State)를 구조(Structure)로 취급한다면, 위험해질 수 있습니다.

어제의 녹색 상태 체크(Health check)가 오늘의 증거는 아닙니다.

지난주의 릴리스 상태(Release status)가 릴리스 게이트(Release gate)는 아닙니다.

유용한 워크스페이스(Workspace) 모델은 어떤 사실이 지속 가능한지, 그리고 어떤 사실을 사용하기 전에 갱신해야 하는지를 알아야 합니다.

모든 사실은 신선도 계약(Freshness contract)을 수반합니다.

그것이 없다면, 에이전트는 오래된 증거를 바탕으로 행동하면서도 자신감 있게 말할 수 있습니다.

에이전트에게 워크스페이스가 생기면 무엇이 변하는가?

흐름이 "파일을 읽고 답변하기"에서 "시스템을 이해하고 결정하기"로 바뀝니다.

이제 에이전트는 더 나은 질문을 던질 수 있습니다:

• 어떤 프로젝트들이 존재하는가?
• 어떤 서비스가 이것에 의존하는가?
• 이 경계(Boundary)의 소유자는 누구인가?
• 어떤 계약(Contracts)들이 영향을 받는가?
• 어떤 명령어를 실행하는 것이 안전한가?
• 어떤 증거가 오래되었는가?
• 릴리스 전에 어떤 검증(Verification)이 필요한가?
• 이 변경의 영향 범위(Blast radius)는 어디까지인가?

이것은 다른 종류의 컨텍스트(Context)입니다.

단순히 더 많은 입력값이 아닙니다.

이것은 공유된 운영 모델(Operating model)입니다.

미래는 저장소 인식(Repository-aware) AI가 아니다

저장소 인식(Repository-aware) AI는 시작점일 뿐입니다.

그것은 에이전트가 코드를 탐색하는 것을 도와줍니다.

하지만 소프트웨어 엔지니어링은 단순히 코드 탐색만이 아닙니다.

그것은 변경 관리(Change management)입니다.

그것은 소유권(Ownership)입니다.

그것은 검증(Verification)입니다.

그것은 리스크(Risk)입니다.

그것은 릴리스 규율(Release discipline)입니다.

그것은 올바르게 보이는 패치(Patch)가 여전히 수용 불가능한 변경일 수 있음을 아는 것입니다.

수년 동안 우리는 저장소(Repository)를 최적화했습니다.

그다음에는 프롬프트(Prompt)를 최적화했습니다.

다음 단계는 다릅니다.

우리는 이해(Understanding)를 최적화해야 합니다.

이는 워크스페이스(Workspace)를 일급 엔지니어링 기본 요소(First-class engineering primitive)로 취급해야 함을 의미합니다.

• 아키텍처(Architecture)가 가시적인 곳
• 소유권(Ownership)이 명시적인 곳
• 리스크(Risk)가 무게를 갖는 곳
• 증거(Evidence)가 최신성을 유지하는 곳
• 검증(Verification)이 워크플로우(Workflow)의 일부인 곳
• 인간과 에이전트(Agent)가 동일한 모델을 바탕으로 의사결정을 내리는 곳

이것이 제가 가장 중요하다고 생각하는 변화입니다.

AI 지원 엔지니어링(AI-assisted engineering)의 미래는 가장 많은 파일을 읽을 수 있는 에이전트에 의해 결정되지 않을 것입니다.

그 파일들이 무엇을 의미하는지 에이전트가 이해하도록 돕는 시스템이 승리할 것입니다.

저장소(Repository)는 코드를 보여줄 수 있지만,

워크스페이스(Workspace)는 결과(Consequence)를 보여줄 수 있기 때문입니다.

그리고 결과야말로 진정한 엔지니어링이 시작되는 지점입니다.

만약 이러한 방향성에 공감하신다면, 제가 이 주변을 정의하고 싶은 카테고리는 다음과 같습니다:

소프트웨어 시스템을 위한 오픈소스 워크스페이스 인텔리전스 (Open-source Workspace Intelligence for software systems).

또 다른 코딩 어시스턴트(Coding assistant)가 아닙니다.

또 다른 프롬프트 트릭(Prompt trick)도 아닙니다.

인간, CI, IDE, 그리고 AI 에이전트를 위한 공유 운영 모델(Shared operating model)입니다.