최근 Anthropic 관련 뉴스 기사를 읽다가 「Environment-centric (환경 중심)」이라는 표현이 눈에 들어왔습니다. 출처는 BigGo 파이낸스의 해설 기사 「AI 경쟁의 세력도를 바꾸다: Anthropic의 『환경 중심』 설계 사상이 이끄는 약 47.6조 엔의 성장」입니다.

「환경 중심 (environment-centric)」, 「Memory Moat (기억의 해자)」, 「3가지 기둥」과 같은 정리는 Anthropic 공식에서 내놓은 용어가 아니라, 위의 BigGo 기사에 의한 해설상의 프레이밍과 이를 받은 필자의 정리입니다. Anthropic 공식 문서나 공식 블로그에 이 형태 그대로 명문화되어 있는 것은 아니라는 점에 유의해 주십시오. 본 기사는 어디까지나 「BigGo 기사의 정리를 기점으로, Anthropic의 각 프로덕트를 횡단하며 다시 읽어보는」 시도로서 읽어주시면 감사하겠습니다.

이 기사 속에서 제시된 정리는 Anthropic의 최근 프로덕트군, 즉 **Claude Code · Agent Skills · MCP (Model Context Protocol)**의 방향성을 깔끔하게 설명하고 있으며, 저 자신도 평소 이것들을 사용하며 막연하게 느끼고 있었던 「Anthropic은 LLM 그 자체보다는, 그 주변의 『환경』을 정돈하려 하고 있다」는 감각과 일치하는 것이었습니다.

본 기사에서는 이 「환경 중심」 설계 사상이란 무엇인지, BigGo 기사와 Anthropic의 공식 정보를 참조하며 나름대로 읽어보겠습니다. 어디까지나 하나의 관점으로 읽어주시면 좋겠습니다.

또한, 본 기사는 AI 모델의 우열론이 아닙니다. **「모델 성능을 어떻게 측정할 것인가」가 아니라, 「모델을 『무엇 안에서』 움직일 것인가」**라는 설계 레이어(layer)의 이야기로서 정리해 나가겠습니다.

BigGo의 기사에서는 Anthropic의 접근 방식을 다음과 같이 요약했습니다.

지식을 외부의 스킬 폴더에 분산시키고, 문맥을 파일 시스템에 영속화하며, 접속을 프로토콜로 표준화한다

조금 풀어서 설명하면 다음과 같은 사고방식이 됩니다.

즉, AI의 「똑똑함」을 모델 내부에서만 완결 짓는 것이 아니라, 모델 외부에 있는 환경 (파일 시스템 · 스킬 라이브러리 · 프로토콜) 에 책임을 분산시켜 나가는 것이 「환경 중심」의 뉘앙스입니다.

여기서 한 가지 유의해 두어야 할 점은, 이것이 「모델 개발을 포기했다」는 이야기가 결코 아니라는 점입니다. Anthropic 스스로도 Opus / Sonnet / Haiku와 같은 모델 계열의 개선을 병행하고 있습니다. 어디까지나 **「모델의 똑똑함에 더해, 환경 측면의 레버리지 (leverage)를 취하러 가고 있다」**고 이해하는 것이 정확할 것입니다.

그렇다면 왜 Anthropic은 굳이 환경 측면에도 힘을 쏟기 시작했을까요?

BigGo 기사 속에서 시사되었던 것은, **「모델 성능은 오픈 소스화를 포함한 경쟁사의 추격으로 인해 급격히 따라잡힌다」**라는 구조적인 사정이었습니다. 이는 확실히 최근 몇 년간의 흐름을 보면 실감할 수 있는 이야기로, 프론티어 모델 (Frontier Model)이 반년에서 1년 만에 타사에 캐치업 (catch-up) 되는 상황이 상시화되고 있습니다.

그 위에서 한 단계 더 깊이 들여다보면 다음과 같은 순서가 되어 있는 듯합니다.

• 모델의 절대 성능만으로 격차를 계속 벌리기는 어렵다.
• 하지만 모델이 놓이는 **「환경」**은 각 조직의 고유한 것이 될 수 있다.
• 환경 측면을 표준화 및 확장 가능한 형태로 설계해 두면, 「자사 모델이 놓인 환경」 자체가 경쟁 우위가 된다.

BigGo 기사는 이를 **「Memory Moat (기억의 해자)」**라는 단어로 표현했습니다. 조직이 오랜 운용을 통해 축적한 스킬 라이브러리와 파일 시스템 구조, 에이전트 간의 상호작용 이력은 복제가 어려운 자산이 된다는 발상입니다.

이것은 단정 지으려는 것은 아니지만, 과거 클라우드 경쟁에서 '단발적인 API 성능'보다 '그 클라우드 위에 쌓인 데이터와 운용 노하우'가 전환 비용(Switching Cost)이 되었던 구도를 떠올리게 합니다. AI에서도 유사한 현상이 일어난다면, 확실히 환경 측면의 표준화는 빠르게 움직여 둘 가치가 있을 것입니다.

BigGo 기사에서 「환경 중심」을 뒷받침하는 세 가지 기둥으로 꼽은 것이 바로 Claude Code · Agent Skills · MCP입니다. 각각이 「환경의 어느 부분을 정비할 것인가」에 대응하고 있으며, 정리해 보면 역할이 깔끔하게 나뉩니다.

Claude Code는 IDE의 확장 기능으로서가 아니라, 터미널에서 직접 실행하여 작업시키는 것을 전제로 설계되어 있습니다. 이를 통해 AI는 「보조 역할」에서 「작업자」의 레이어로 올라가며, git · npm · cargo · 각종 CLI 도구를 직접 다루는 것을 전제로 워크플로우를 구성할 수 있게 됩니다.

반대로 말하면, AI를 IDE 플러그인에 가두어 두는 한, AI가 접할 수 있는 환경은 IDE 내부에 국한된다는 뜻이기도 합니다. 실제 운영 환경은 터미널과 셸 위에 있으므로, 그곳에 직접 배치한다는 판단은 **「AI에게 환경 그 자체를 조작하게 하고 싶다」**는 설계 사상에 있어 자연스러운 귀결이라고 느껴집니다.

Agent Skills는 AI에게 전달하고 싶은 지식이나 절차를 SKILL.md 등의 폴더 구조로 관리하고, 필요에 따라 로드하는 메커니즘입니다. 중요한 점은,

**「모든 것을 한꺼번에 컨텍스트 (Context)에 채워 넣지 않는다」**는 설계로 되어 있다는 점입니다.

이는 Anthropic이 제창하는 **단계적 공개 (Progressive Disclosure)**라는 개념과 직결되어 있으며, 필요한 정보를 필요한 타이밍에만 로드하는 운용을 통해 다음과 같은 이점을 얻을 수 있습니다.

• 컨텍스트 윈도우 (Context Window)의 압박 방지
• 스킬 단위로 버전 관리 가능
• 용도별로 공유 및 재사용 가능

저 개인적으로 Skills를 업무에 사용하며 가장 효과적이라고 느끼는 점은, **「조직이나 개인별로 커스터마이징한 절차를 폴더로서 리포지토리 (Repository)에 둘 수 있다는 것」**입니다.

MCP (Model Context Protocol)는 AI 모델과 외부 서비스를 연결하기 위한 오픈 공통 프로토콜입니다. 각 기업이 독자적인 사양으로 연결하던 「도구 호출 (Tool Calling)」「리소스 제공 (Resource Provisioning)」「프롬프트 공유 (Prompt Sharing)」를 MCP로서 규격화하려는 움직임입니다.

여기서의 핵심은, Anthropic이 이 규격을 자사 제품 전용으로 만들지 않고 오픈 소스로 공개하고 있다는 점입니다. 단기적으로는 자사의 락인 (Lock-in) 효과를 약화시키는 판단으로 보일 수 있지만, 장기적으로는 「표준화된 접속 레이어를 빠르게 구축한 쪽이 에코시스템 (Ecosystem) 전체의 중력을 갖게 된다」는 전략으로 보입니다.

세 가지 기둥을 세로로 나열하면,

• OS / 셸 (Shell) (Claude Code)
• 파일 시스템 (File System) (Agent Skills)
• 외부 서비스 (MCP)

라는, 개발자에게 친숙한 3계층을 전부 「AI가 직접 접할 수 있는 환경」으로 다시 정비하려 한다는 관점이 가능합니다. 이는 상당히 야심 찬 그림이라고 생각합니다.

BigGo 기사에서 등장한 키워드 중 하나가 **단계적 공개 (Progressive Disclosure)**였습니다. 이는 Agent Skills의 근저에 깔린 설계 사상이기도 합니다.

간단히 정리하자면,

• 필요한 때에, 필요한 스킬이나 정보만을 로드한다.
• 폴더 구조 그 자체를 문서로 사용하여, AI에게 「목차」를 보여준다.
• 상세 내용은 파일 경로(File Path)나 링크로 전달하여, 필요해진 타이밍에 AI 스스로 읽으러 가게 한다.

라는 접근 방식입니다. 컨텍스트 윈도우 (Context Window)는 확실히 수백 K ~ 수백만 토큰으로 확대되고 있지만, "그렇기 때문에 전부 다 집어넣는 것"이 아니라, "그렇기 때문에 필요한 것만 꺼내 쓰게 하는" 방향으로 완전히 선회한 것이 Anthropic의 판단으로 보입니다.

이는 저 자신도 거대한 CLAUDE.md를 만들어 전부 집어넣는 운용을 시도해 본 후, "긴 문장의 CLAUDE.md보다 Skills로서 작게 분할해 두는 편이 파손되기 어렵다"는 체감을 얻었던 경험과도 일치합니다. 프로젝트에 따라 궁합은 있겠지만, Skills 분할 쪽으로 기울어지는 편이 안정적인 케이스가 많다고 느낍니다.

"환경 중심" 설계의 전략적인 목표를 BigGo 기사는 **"Memory Moat (기억의 해자)"**라는 단어로 표현했습니다.

이를 뒤집어 말하면, "모델을 교체하는 것 = 환경 자산을 버리는 것"이 되지 않도록 설계되어 있다고도 할 수 있습니다. MCP와 같은 공통 프로토콜이 있다면, 특정 모델 벤더에 환경 자산이 락인 (Lock-in)될 가능성도 낮아집니다. 이는 도입하는 측면에서도 안심할 수 있는 요소라고 생각합니다.

다만, 이 Memory Moat론에는 주의도 필요합니다. "조직이 키워나가는" 측면이 크기 때문에, 처음부터 자동으로 해자가 파이는 것은 아니다라는 점입니다. Skills를 정비하고, MCP 서버를 작성하고, 파일 시스템 구조를 의도적으로 설계하는 등의 꾸준한 투자가 전제되어야 합니다. "도구를 넣으면 바로 해자가 생긴다"고 생각하지 않는 편이 좋습니다.

BigGo 기사에서 언급된 구체적인 사례도 "환경 중심"의 효과를 뒷받침하는 재료로서 읽어볼 만한 가치가 있었습니다.

강화학습 (RL) 코드베이스에 대해, Claude가 기술한 2만 2,000행에 달하는 대규모 코드 수정이 단 하루 만에 검증 및 머지 (Merge)되었다

통상적으로라면 2주 규모로 예상되는 작업량을 4단계 프로세스로 처리했다고 합니다.

BigGo 기사는 또 하나, Epic의 사례도 언급했습니다.

Epic에서는 Claude Code 이용자의 절반 이상이 비엔지니어 직군

이는 "환경 중심" 이야기와 직결됩니다. AI를 IDE 플러그인에 가두어 두던 시대에는 당연하게도 IDE를 사용하는 엔지니어 중심이었습니다. 반면, 터미널 + 파일 시스템 + 외부 연결이 갖춰진 환경에 AI를 배치하면, 의료·업무 도메인 담당자 등 코드를 작성하지 않는 직종에서도 자신의 업무를 에이전트 (Agent)에게 맡길 수 있게 됩니다.

"누가 AI를 사용할 수 있는가는 AI의 모델 성능이 아니라, AI가 놓여 있는 환경의 형태로 결정된다"는 점은 기억해 둘 만한 시사점이라고 느꼈습니다.

BigGo 기사는 Anthropic의 연구원이자 "Building Effective Agents"의 공동 저자인 Erik Schluntz 씨의 말도 인용했습니다.

코드는 잊어도 좋지만, 제품의 존재는 결코 잊어서는 안 된다

이는 바이브 코딩 (Vibe Coding)에 관한 발언으로 알려져 있지만, "환경 중심"의 맥락에서 다시 읽어보면 또 다른 의미를 띠게 됩니다.

코드: 모델 내부의 출력물. 휘발적이며, 다시 쓰일 수 있는 것 -
제품: 환경 측에 쌓여가는 사용자 경험·데이터·스킬·연결의 집합체

즉, 엔지니어가 지켜야 할 것은 "자신이 쓴 한 줄 한 줄"이 아니라, "프로덕트로서 제공하는 가치와 그 배후의 환경 설계"라는 정리로도 이어집니다.

이 부분은 저의 개인적인 해석도 조금 포함되어 있습니다만, 「환경 중심 (Environment-centric)」 설계 사상과 Erik Schluntz 씨의 조언은 **「휘발되는 것(코드)을 너무 움켜쥐려 하지 말고, 남는 것(환경과 가치)을 다뤄라」**라는 동일한 뿌리를 가지고 있다고 느껴집니다.

지금까지 Anthropic 측의 전략을 분석해 왔습니다만, 이를 자신의 팀으로 끌어온다면 몇 가지 실무적인 질문이 생겨납니다.

이것들은 전부 한꺼번에 할 필요는 없으며, 자신의 손이 닿는 범위 내에서 하나씩 환경을 정비해 나간다는 이미지로 임하는 것이 현실적입니다. 예를 들어 "처음에는 CLAUDE.md만 정비한다", "다음에는 빈번한 조작을 Skill화한다", "그다음에는 MCP 서버를 딱 하나만 작성한다"와 같은 방식입니다.

역으로 말하면, **「Anthropic이 말하는 환경 중심의 그림을 자신의 팀에서도 축소판으로 재현할 수 있다」**는 점이 이 설계 사상의 즐거운 부분입니다. Anthropic이 대기업용 전용 플랫폼을 만들고 있는 것이 아니기에, 개인이나 소규모 팀에서도 동일한 사상을 도입할 여지가 있습니다.

「환경 중심」은 강력한 사고방식이지만, 몇 가지 유의해야 할 점도 있습니다.

자동으로 해자가 파지는 것은 아니다: Skills나 MCP를 작성하는 노력은 누군가가 부담해야 합니다. 초기 몇 달간은 투자가 선행되어야 합니다 -
환경이 성장할수록, 초기에 결정한 디렉토리 구조의 부채가 영향을 미친다: 빠른 단계에서 "어떤 입도(granularity)로 Skill을 나눌 것인가"를 한 번 진지하게 고민해 두면 나중에 편합니다 -
모든 작업에 적합한 것은 아니다: 일회성 스크립트나 개인 프로토타입의 경우, 환경을 정비하기 전에 직접 손을 움직이는 것이 더 빠른 상황도 있습니다 -
모델 성능을 경시하는 것이 아니다: 환경을 정비하더라도 모델이 약하면 결국 고전하게 됩니다. "환경과 모델의 양륜 (Two wheels)"이 현실적인 운용입니다

이러한 점들을 고려하면서, "내 프로젝트의 어디에 환경 투자를 집중할 것인가"를 파악해 나가는 것이 현재 가장 적절한 지점이라고 느낍니다.

마지막으로, 본 기사의 요점을 간단히 되짚어 보겠습니다.

「환경 중심」이란, AI의 똑똑함을 모델 내부의 영역에만 가두지 않고, 파일 시스템 · 스킬 라이브러리 · 프로토콜에까지 책임을 분산하는 설계 사상입니다 -
이를 뒷받침하는 세 가지 기둥은 **Claude Code (터미널) · Agent Skills (파일 시스템) · MCP (외부 연결)**이며, 각각이 "환경의 어느 계층을 정비할 것인가"를 담당합니다 -
전략적인 목표는, 모델 성능만으로는 차별화가 어려워지는 상황 속에서, 환경 측에 조직 고유의 자산 (Memory Moat)을 쌓아 올려 경쟁 우위를 만드는 것입니다 -
구체적인 사례로, 22,000행에 달하는 PR의 검증 가능한 설계나, Epic에서 비엔지니어 직군이 이용자의 절반 이상을 차지하는 침투 방식이 소개되었습니다 -
자신의 팀에서도 CLAUDE.md 정비, Skills 분할, MCP 서버의 점진적 추가, 계획 문서의 Git 관리 등의 형태로 축소판을 재현할 수 있을 것입니다 -
한편, "환경을 키우는 것"은 시간과 의사결정이 필요한 작업이므로, "도구를 도입하는 순간 해자가 생긴다"라는 기대는 하지 않는 편이 안전합니다

"휘발하는 코드가 아니라, 남는 환경 쪽을 다룬다"라는 발상은 Erik Schluntz 씨의 as old as civilization (매니지먼트가 고대부터 다뤄온 테마)과도 통합니다. AI의 진화가 한 단계 가속화되는 가운데, 우리 업무의 어느 부분을 "환경"으로서 남기고, 어느 부분을 휘발시켜도 좋을 것인가. 그 라인을 의식적으로 그어 나가는 작업이 앞으로 몇 년간의 핵심 과제가 될 것입니다.

• 본 기사의 출발점이 된 해설 기사: https://finance.biggo.jp/news/xvvxrJ0Bh5an-7Ghs500
• Anthropic 공식 'Building Effective Agents': https://www.anthropic.com/research/building-effective-agents
• Model Context Protocol (MCP) 공식: https://modelcontextprotocol.io/