AI 코딩 및 에이전트를 위한 최고의 코드베이스 아키텍처 (Aider, Claude Code, Cursor)

IndyDevDan 구독자 43,800명

요약

이 영상은 AI 코딩 도구와 에이전트가 코드를 생성하는 시대에 대비하여, 코드베이스를 어떻게 최적화할 것인지 논의한다. 토큰 효율성을 극대화하고, AI 도구가 빠르게 이해하고 실행할 수 있도록 여러 아키텍처 패턴—아토믹 컴포저블, 레이어드, 수직 슬라이스, 파이프라인, 그리고 싱글 파일 에이전트—의 장단점을 분석한다. 각각의 구조는 재사용성, 모듈화, 테스트 용이성 등에서 차이를 보이며, AI 도구들의 컨텍스트 관리와 실행 효율성을 개선하는 데 초점을 맞춘다. 마지막으로 향후 AI 코딩 환경에서 효과적으로 경쟁할 수 있는 디자인 패턴과 접근법에 대해 전망과 실전 팁을 제시합니다.

주요 키워드

AI 코딩 코드베이스 아키텍처 토큰 효율성 아토믹 컴포저블 레이어드 아키텍처 수직 슬라이스 파이프라인 싱글 파일 에이전트 컨텍스트 관리 에이전트 개발

하이라이트

🔑 AI 코딩 시대의 도래와 함께, 코드베이스를 토큰 효율적으로 설계해야 한다는 점을 강조합니다.
⚡️ 아토믹 컴포저블 아키텍처는 작은 단위(아톰, 분자, 유기체, 멤브레인)로 구성되어 재사용성과 테스트 용이성이 높으나, 수정 시 체인 반응 문제가 발생할 수 있음을 지적합니다.
🌟 레이어드 아키텍처는 명확한 관심사의 분리를 제공하지만, AI 도구가 여러 디렉터리와 파일을 동시에 로드해야 하는 단점이 있습니다.
📌 수직 슬라이스 아키텍처는 기능별로 코드를 분리해 컨텍스트 프라이밍을 단순하게 만들어, 토큰 절감과 빠른 코드 분석에 유리합니다.
🚀 파이프라인 및 싱글 파일 에이전트 설계는 순차 처리와 간결한 구조를 통해 AI 에이전트 개발에 최적의 환경을 제공한다고 설명합니다.
🔑 전체적으로, 코드를 AI 도구가 쉽게 파악할 수 있도록 구조화하는 것이 장기적으로 개발 효율과 비용 절감에 큰 영향을 미친다는 메시지를 전달합니다.

용어 설명

아토믹 컴포저블 아키텍처

작은 단위(아톰, 분자, 유기체, 멤브레인)로 구성하여 재사용성과 테스트 용이성을 높이는 구조. UI 컴포넌트부터 전체 시스템까지 다양한 수준에서 적용됨.

레이어드 아키텍처

기능별 폴더와 디렉터리(예: API, 모델, 비즈니스 로직 등)를 통해 관심사를 분리하여 코드를 구성하는 전통적인 아키텍처.

수직 슬라이스 아키텍처

기능별(또는 특징별)로 코드를 조직하여 관련된 모든 파일과 모듈을 하나의 슬라이스로 관리, 컨텍스트 프라이밍과 토큰 효율성을 높임.

파이프라인 아키텍처

기능 또는 데이터 처리 단계가 순차적으로 연결되어 각 단계에서 데이터를 처리하는 방식으로, 주로 데이터 파이프라인 및 ML Ops에 활용됨.

싱글 파일 에이전트

에이전트의 모든 기능을 한 파일 내에 집약하여 단일 컨텍스트 프라임팅으로 빠르게 실행할 수 있도록 하는 구조.

컨텍스트 관리

AI 도구가 코드를 실행할 때 필요한 정보를 최적화하여 토큰 사용을 줄이고, 효율적으로 코드를 분석 및 실행하게 만드는 설계 원칙.

AI 코딩 도구가 곧 코드를 작성하게 될 미래를 대비하여 최적의 코드베이스 아키텍처 설계가 필요함을 소개합니다. 토큰 효율성과 AI 도구의 컨텍스트 관리의 중요성을 강조합니다.

[00:00] AI 코딩 에이전트의 시대가 도래함에 따라, 코드베이스를 어떻게 AI 친화적으로 설계할 것인지가 중요한 과제로 대두되고 있습니다.

[00:31] 다양한 AI 코딩 도구들이 등장하고 발전하는 가운데, 중요한 것은 AI가 이해하고 작동하기 쉬운 컨텍스트 시스템을 설계하는 것입니다.

[01:02] AI 코딩과 AI 에이전트를 위한 최적의 코드베이스 아키텍처를 찾는 것이 중요하며, 이는 컨텍스트 관리가 곧 결과 관리로 이어지기 때문입니다.

아톰, 분자, 유기체, 멤브레인 등의 작은 단위로 구성된 아키텍처의 구조와 재사용성, 테스트 용이성 등 장점을 설명합니다. 단, 하위 단위 수정 시 연쇄적 영향 문제를 지적합니다.

[02:09] 원자적 조합 아키텍처는 재사용성이 높고 관심사가 명확히 분리되어 있어, AI 도구가 쉽게 이해할 수 있는 구조를 제공합니다.

[03:01] Brad Frost의 원자 디자인 프레임워크에서 시작된 이 개념은 이제 전체 엔지니어링 스택에서 널리 사용되고 있습니다.

[03:19] 자연의 구조처럼 작은 단위(원자)가 더 큰 단위(분자, 유기체)를 구성하는 방식으로 코드를 구성할 수 있으며, 이는 멤브레인과 생태계 수준까지 확장 가능합니다.

[03:40] 이 아키텍처의 가장 큰 장점은 테스트가 용이하다는 것입니다. pocket pick이라는 MCP 서버를 예로 들어 설명하겠습니다.

[04:00] Source 디렉토리는 깔끔한 원자적 구조를 가지고 있으며, modules는 단일 추상화 계층으로 구성되어 있고, 이는 MCP 서버의 기본 단위가 됩니다.

[04:50] 이 구조의 장점은 깔끔한 테스트 아키텍처를 제공하며, 세밀한 기능을 독립적으로 테스트할 수 있다는 것입니다. 38개의 테스트가 성공적으로 실행되는 것을 확인할 수 있습니다.

[05:40] 하지만 '새로운 기능 수정 체인 문제'라는 단점이 있습니다. 하위 레벨 원자를 수정할 때 이를 사용하는 모든 상위 구성요소들도 함께 수정해야 하는 문제가 발생합니다.

[06:13] 원자적 구성 가능한 아키텍처의 단점으로, 하나의 변경사항이 있을 때 모든 상위 레벨 구성요소를 다시 테스트해야 하는 번거로움이 있습니다.

[06:32] AI 코딩 도구에서는 작은 변경사항에도 모든 상위 계층을 업데이트해야 하며, 이는 컨텍스트 윈도우에 더 많은 정보가 필요함을 의미합니다.

[07:00] 계층형 아키텍처는 가장 널리 사용되는 패턴으로, 인터페이스 계층, API 엔드포인트, 데이터 모델, 비즈니스 로직 등 논리적으로 구성된 디렉토리 구조를 가집니다.

폴더와 디렉터리를 이용한 전통적 코드 구조의 장단점을 검토합니다. 관심사 분리를 통한 명확한 역할 분담과 함께, AI 도구가 여러 파일을 읽어야 하는 점에서의 토큰 소모 문제를 논의합니다.

[07:41] PostgreSQL과 Redis 코드베이스를 예로 들어, 계층형 아키텍처의 실제 구현을 살펴볼 수 있습니다. 특히 Redis는 평면적이지만 전형적인 계층형 구조를 보여줍니다.

[08:06] 계층형 아키텍처의 주요 단점은 계층 간 임포트가 필요하고 AI 코딩 도구가 모든 영역을 처리해야 한다는 것입니다.

[08:40] 계층형 아키텍처는 빠른 기능 추가와 수정이 가능하다는 장점이 있지만, AI 코딩 도구에는 최적이 아닐 수 있습니다.

[09:07] 계층형 아키텍처 내에서 utils와 같은 원자적 구조가 가장 하위 레벨에 위치하지만, 이는 여러 모듈 간의 임포트 관계를 복잡하게 만드는 시작점이 됩니다.

[09:43] 계층형 아키텍처는 확장성과 개발 용이성 측면에서 장점이 있지만, AI 코딩 도구가 모든 디렉토리를 검토해야 하는 단점이 있습니다.

기능별로 코드를 분리하여 하나의 슬라이스로 관리하는 방식의 효율성을 설명합니다. 단일 컨텍스트 프라임팅으로 토큰 절감과 빠른 코드 분석이 가능하다는 점을 강조합니다.

[10:15] 수직 슬라이스 아키텍처가 AI 코딩 도구와 에이전트 코딩 도구에 최적화된 구조로 제안되었습니다.

[10:42] 수직 슬라이스 아키텍처는 features 디렉토리 내에 각 기능별로 필요한 모든 컴포넌트(API, 모델, 서비스 등)를 포함하는 구조입니다.

[11:20] 이 구조는 깔끔하고 간결하며, 단일 디렉토리 임포트와 컨텍스트 프라이밍으로 효율적인 AI 코딩이 가능합니다. 기능별 구성으로 관련 코드를 쉽게 찾고 관리할 수 있습니다.

[12:01] AI 코딩 도구 설정을 위한 컨텍스트 프라이밍의 중요성을 설명하면서, 하나의 프롬프트로 모든 컨텍스트를 설정할 수 있다고 소개합니다.

[12:27] 수직 슬라이스 아키텍처의 실제 구조를 보여주며, features 폴더 내의 projects, tasks, users 등의 구성을 설명합니다.

[12:59] 여러 AI 코딩 도구(Claude, Cursor)에서 동일한 컨텍스트 프라이밍 방식을 적용하는 방법을 시연합니다.

[13:44] 도구 자체보다는 패턴과 원칙이 더 중요하다는 점을 강조하며, Principal AI Coding의 핵심 개념을 설명합니다.

[14:17] 다양한 AI 코딩 도구들이 동일한 패턴으로 작동하는 것을 시연하며, 수직 슬라이스 아키텍처의 실용성을 입증합니다.

[15:06] 수직 슬라이스 아키텍처의 기본 개념과 프롬프트 컨텍스트 프라이밍의 중요성을 설명하면서, 횡단 관심사 최소화의 장단점을 소개합니다.

[15:32] 기능 중심, 가치 중심의 구조를 강조하며, 코드베이스보다 사용자와 고객 관점의 중요성을 설명합니다.

[15:50] 수직 슬라이스 아키텍처의 주요 단점으로 코드 중복 문제와 유틸리티 공유의 위험성을 상세히 설명합니다.

[16:46] 신입/중급 엔지니어들이 이 아키텍처에서 겪을 수 있는 어려움과 코드 중복의 현실적인 문제를 다룹니다.

[17:09] AI 코딩 도구에서 단일 컨텍스트 격리의 중요성을 강조하고, 파이프라인 아키텍처로 화제를 전환합니다.

데이터 또는 작업 단계를 순차적으로 처리하는 파이프라인 구조를 소개합니다. 주로 ML Ops 및 데이터 처리에 적합하며, 단계별 처리의 장점을 살펴봅니다.

[17:41] 파이프라인 아키텍처의 실제 활용 사례로 데이터 엔지니어링과 ML Ops 분야를 소개합니다.

[17:53] 파이프라인 아키텍처의 기본 구성 요소로 유틸리티와 단계별 구성요소가 있으며, 이들이 모여 실행 가능한 파이프라인을 형성합니다.

[18:04] LLM 개발에서 파이프라인 아키텍처의 장점은 순차적 처리에 적합하고, 타입과 명확한 경로를 제공하며 패턴 기반 접근이 가능하다는 것입니다.

[18:28] AI 코딩 도구들은 이러한 구조화된 패턴과 타입을 선호하며, 이를 통해 작업 수행과 단계 재배열이 용이합니다.

[18:43] 파이프라인 아키텍처의 주요 단점은 파이프라인 기반이 아닌 시스템에는 적합하지 않으며, 상태 관리가 복잡할 수 있다는 것입니다.

[19:14] AI 시스템을 위한 주요 아키텍처로 원자적 구성, 계층화된 파이프라인, 수직 슬라이스를 검토했으며, 특히 수직과 원자적 구조가 AI 코딩에 효과적입니다.

AI 에이전트를 구축하기 위한 구조적 접근법을 논의합니다. 아토믹, 수직 슬라이스, 싱글 파일 에이전트 등 다양한 구조의 특성과 적용 가능성을 비교합니다.

[19:47] AI 에이전트 구축을 위한 최적의 구조로 원자적 구성, 수직 슬라이스, 단일 파일 에이전트가 추천되며, 이는 모든 AI 제공자와 호환됩니다.

[20:35] 원자적 구조의 구성 요소인 atoms, molecules, organisms, membranes에 대해 설명하면서, membrane이 시스템의 API 계층으로서 상호작용 방식을 정의한다고 소개합니다.

[21:17] organism은 파일 에이전트로, molecules에서 필요한 컴포넌트를 구성하며, atoms는 가장 낮은 수준의 테스트 가능한 단위로 설명됩니다.

[22:10] 이 구조는 실행 가능한 코드가 아닌 AI 에이전트 설계를 위한 참고 아키텍처임을 설명합니다.

[22:28] 수직 슬라이스 아키텍처를 대안으로 제시하며, 각 에이전트를 개별 기능으로 보는 접근 방식을 설명합니다.

[23:08] 블로그 에이전트 예시를 통해 수직 슬라이스 아키텍처의 장점과 빠른 버전 관리 가능성을 설명합니다.

[23:34] 단일 파일 에이전트의 버전 관리와 수정이 매우 용이함을 설명합니다. 전체 파일을 복사해서 새 버전을 만들거나 LLM 제공자를 변경하는 등의 작업이 간단하게 가능합니다.

[23:49] 에이전트 아키텍처 중에서 수직 슬라이스 아키텍처와 단일 파일 에이전트가 주목할 만한 방식임을 설명합니다.

모든 에이전트 기능을 하나의 파일에 집약하는 설계를 소개합니다. 단일 파일로 컨텍스트를 쉽게 프라임팅하여 AI 도구가 빠르게 실행할 수 있음을 보여줍니다.

[24:06] 단일 파일 에이전트의 특징을 설명합니다. 700줄의 코드가 한 파일에 있는 것이 일반적으로는 안티패턴이지만, 이 구조에서는 독립적인 컨텍스트 에이전트로서 장점이 됩니다.

[24:42] 단일 파일 에이전트의 실용적인 장점을 설명합니다. 파일 참조와 프롬프팅이 매우 단순하고 직관적으로 이루어질 수 있습니다.

[25:23] 채널의 주요 주제인 AI 코딩과 에이전트 코딩에 대해 설명하며, 단일 파일 에이전트 코드베이스의 중요성을 강조합니다.

[25:51] 아키텍처의 중요성에 대한 결론을 제시합니다. 단기적으로는 컨텍스트 관리를 위해 중요하지만, LLM 기술이 발전할수록 그 중요성이 감소할 수 있다고 설명합니다.

[26:32] 컨텍스트 관리의 중요성을 강조하며, 특히 대규모 코드베이스에서 AI 도구들이 효율적으로 작동하기 위해서는 명확한 경로와 구조가 필요함을 설명합니다.

[27:00] 현재 AI 코딩 도구들이 단순 정보 검색에도 많은 토큰을 소비하는 문제점을 지적하고, 레이어드 아키텍처의 한계를 설명합니다.

[27:34] 버티컬 슬라이스 아키텍처를 도입하면 토큰 사용을 크게 절약할 수 있으며, 이는 비용 효율성으로 이어진다고 설명합니다.

코드베이스 구조가 AI 도구의 성능과 비용 효율성에 미치는 영향을 정리합니다. 향후 AI 코딩과 에이전트 개발의 발전 방향 및 교육 프로그램 안내로 마무리합니다.

[28:06] 향후 AI가 대부분의 코드를 작성할 것이므로, 코드베이스를 AI 관점에서 구조화해야 한다는 새로운 패러다임을 제시합니다.

[28:47] 3월 말에 발표될 AI 코딩 현황 에세이에 대해 소개하며, 이를 통해 AI 코딩의 현재와 미래, 그리고 실질적인 가이드라인을 제공할 것임을 예고합니다.

[29:33] 2025년 1분기 AI 코딩 현황에 대한 독점 콘텐츠를 Principled AI Coding 수료 멤버들과 공유할 예정임을 안내합니다.

[29:46] 뛰어난 설계와 아키텍처에 관심 있는 엔지니어들을 위한 Principled AI Coding 과정을 소개하고 참여를 권장합니다.

[30:03] AI 코딩에서 에이전트 코딩으로의 전환을 설명하며, 2025년이 이 변화에 동참할 수 있는 마지막 기회임을 강조합니다.

[30:31] 8개 강의를 통해 컨텍스트, 모델, 프롬프트 등 핵심 원칙들을 다루며, 초급부터 고급까지 체계적인 학습을 제공합니다.

[00:00] 안녕하세요, 엔지니어 여러분. Indie Dev Dan입니다.

[00:03] 기술 생태계에서는 이미 논쟁의 여지가 없습니다.

[00:06] 우리 모든 개발자들이 알고 있듯이

[00:09] 곧 모든 코드는 AI 코딩 에이전트가 작성하게 될 것입니다.

[00:13] 그렇다면 자연스럽게 다음 질문이 나옵니다.

[00:16] AI 코딩 도구에 최적화된 코드베이스를

[00:20] 어떻게 설계할 수 있을까요?

[00:23] AI 코딩 에이전트가 우리의 코드베이스를 운영할 것이므로

[00:26] 우리는 코드베이스를

[00:29] 토큰 효율적으로 설계해야 합니다.

[00:31] Cursor, Zed, Claude Code, Aider나

[00:33] Windsurfer 중 어떤 도구를 사용하든

[00:37] 이러한 도구들은 계속 변화하고 발전할 것입니다.

[00:40] 일부는 사라지고 일부는 번창할 것입니다.

[00:43] 중요한 것은 AI 코딩 도구가

[00:47] 쉽게 이해하고 작동할 수 있는

[00:50] 컨텍스트 시스템을 어떻게 설계하느냐입니다.

[00:53] 항상 3가지 핵심 요소를 기억하세요: 컨텍스트, 모델, 프롬프트

[00:57] 이 영상에서는 다음 질문을 탐구해볼 것입니다.

[01:02] AI 코딩과 AI 에이전트를 위한

[01:04] 최적의 코드베이스 아키텍처는 무엇일까요?

[01:07] 왜 이것이 중요할까요?

[01:11] 컨텍스트를 관리하면

[01:13] 결과를 관리할 수 있기 때문입니다.

[01:16] 생성형 AI 시대에서는 이것이 핵심입니다.

[01:19] 컨텍스트를 관리하면

[01:22] 결과를 관리할 수 있습니다.

[01:25] 우리가 답할 주요 질문들을 살펴보겠습니다.

[01:27] AI 코딩을 위한 최적의 코드베이스 아키텍처는 무엇인가?

[01:29] AI 에이전트 구축을 위한

[01:31] 최적의 코드베이스 아키텍처는 무엇인가?

[01:33] 그리고 마지막으로 가장 중요한 것은

[01:36] 이것이 정말 중요한가입니다.

[01:39] AI 코딩 도구가 발전하고

[01:42] Claude Code와 같은 새로운 에이전트 도구가 등장하면서

[01:45] 우리는 한 걸음 물러서서

[01:48] 이것이 정말 중요한지 질문해야 합니다.

[01:51] 훌륭한 엔지니어는 항상 멈춰서

[01:54] 자신이 해결하려는 문제가

[01:56] 해결할 가치가 있는지 고민합니다.

[02:00] 코드베이스 아키텍처가

[02:01] 어떤 모습인지가 중요할까요?

[02:03] 이 세 가지 질문에 관심이 있다면

[02:06] 계속 시청해 주세요. 먼저 인기있지만 잘못 사용되는

[02:09] 코드베이스 아키텍처부터 시작하겠습니다.

[02:11] 이것이 바로 원자적 조합 아키텍처입니다.

[02:14] 우리가 살펴볼 모든 구조에는

[02:15] 여러 가지 이름이 있지만, 일반적인 용어를 사용하겠습니다.

[02:18] 이 코드베이스 아키텍처는

[02:19] 어떤 모습일까요?

[02:22] 원자들이 분자로 조합되고

[02:24] 분자들이 다시 유기체로 조합됩니다.

[02:27] 우리가 살펴볼 각 아키텍처에 대해

[02:29] 장단점을 분석해볼 것입니다.

[02:31] 장점은 무엇일까요?

[02:33] 매우 재사용성이 높습니다.

[02:35] 전체 아키텍처가 기본적으로

[02:37] 재사용 가능한 조각들로 이루어져 있죠.

[02:40] 이는 놀라운 장점입니다.

[02:42] 나중에 살펴볼 아키텍처들과는

[02:44] 대조적일 것입니다.

[02:45] 매우 명확한 관심사의 분리가 있습니다.

[02:47] 원자, 분자, 유기체에 대한

[02:50] 간단한 설명만 있다면

[02:52] AI 도구가 이 아키텍처를

[02:54] 매우 쉽게 이해할 수 있을 것입니다.

[02:57] 참고로, 원자, 분자, 유기체라는 용어는

[02:59] 다른 이름으로도 불릴 수 있습니다.

[03:01] 이는 Brad Frost가 대중화한

[03:04] 원자 디자인 프레임워크입니다.

[03:07] 원래는 UI 컴포넌트를 구성하는

[03:09] 프론트엔드 코드베이스를 위해 채택되었지만

[03:12] 이제는 엔지니어링 스택 전반과

[03:15] 모든 유형의 코드베이스에서

[03:17] 채택되고 있습니다.

[03:19] 자연에서처럼

[03:21] 작은 조각들이 더 큰 조각을 만드는 것처럼

[03:23] 원자가 분자를 만들고

[03:26] 분자가 유기체를 만드는 것처럼

[03:28] 이 영상에서 보시겠지만

[03:30] 이것을 멤브레인과 생태계로까지 확장할 수 있습니다

[03:33] 유기체 수준을 넘어서서

[03:35] 필요한 만큼의 추상화 레벨을

[03:37] 얼마든지 만들 수 있죠

[03:40] 이 아키텍처의 또 다른 매우 중요한 점은

[03:42] 테스트가 매우 쉽다는 것입니다

[03:45] 제가 정확히 무슨 의미인지 보여드리겠습니다

[03:47] 이전 영상에서 우리는 pocket pick을 다뤘는데

[03:49] 이것은 정보를 빠르게 저장하고 검색하는데 도움을 주는

[03:52] MCP 서버입니다

[03:54] Source 디렉토리에서 tree 명령어를 실행하면

[03:57] .gitignore를 통해

[04:00] 깔끔한 원자적 구조를 볼 수 있습니다

[04:03] modules만 살펴보면

[04:06] 단일 추상화 계층이 있습니다

[04:08] 하나의 조합 가능한 계층인 modules가 있고

[04:11] 매우 명확하게 말씀드리면, 우리의 모듈들은

[04:14] 바로 우리의 원자들입니다

[04:16] 그리고 그 위에는 단 하나의 상위 레벨이 있는데

[04:19] 바로 이 모듈들을 사용하는

[04:22] MCP 서버입니다

[04:24] 우리는 단 하나의

[04:26] 원자적 단위 레벨을 가지고 있고

[04:28] 원하면 이것들을 추가 디렉토리로 나눌 수 있지만

[04:30] 핵심은 이것들이 모두 원자라는 것입니다

[04:33] 이것들은 모두 큰 조각을 만드는

[04:35] 작은 조각들이죠

[04:38] 이 경우에는 MCP 서버라는

[04:40] 하나의 큰 조각만 있습니다

[04:42] Claude Code로 단일 프롬프트에서 이것을 만드는 영상 링크를

[04:45] 설명란에 넣어두었는데

[04:47] 그 영상이 엄청난 반응을 얻었습니다

[04:50] 여기서 우리가 얻는 것은

[04:52] 테스트 작성을 위한 깔끔한 아키텍처이고

[04:55] 이것이 아마도 원자적 아키텍처의

[04:57] 가장 큰 장점일 것입니다

[05:00] 세밀한 기능을 만들고 이를

[05:02] 테스트에서 분리할 수 있죠

[05:05] 우리는 빠르게 UV run P test를 실행하고

[05:07] 모든 기능이 검증되는 것을 볼 수 있습니다

[05:10] 38개의 테스트가 실행되었고, 이는 잘 테스트된

[05:13] 잘 정돈된 컴팩트한 코드베이스입니다

[05:16] 원자적 구조 덕분이고

[05:18] 작은 조각들 덕분이죠

[05:20] AI 코딩 도구를 사용한다면

[05:22] 여기에 빠르게 컨텍스트를 추가하고

[05:24] 바로 작업을 시작할 수 있습니다

[05:26] 이것이 바로 원자적 조합 가능한 아키텍처입니다

[05:28] AI 도구가 이해하기 쉬운

[05:30] 매우 간단한 패턴이고

[05:31] 원자, 분자, 유기체를

[05:33] 계속 추가할 수 있어 확장성도 좋습니다

[05:35] 단점은 무엇일까요? 엔지니어와 개발자로서 우리가 하는 모든 일에는

[05:39] 트레이드오프가 있습니다

[05:40] 원자적 구조의 단점은 무엇일까요?

[05:42] 이것은 제가 부르는

[05:44] '새로운 기능 수정 체인 문제'를 겪습니다

[05:46] 이게 무슨 뜻일까요?

[05:48] 많은 용어가 섞여있는데, 기본적으로

[05:51] 유기체를 수정하거나 새로운 유기체를 추가할 때

[05:53] 또는 새로운 상위 레벨 구성을 추가하고

[05:55] 하위 레벨에서 뭔가를 변경하고 싶을 때

[05:57] 이제 하위 레벨 원자를 사용하는

[05:59] 모든 것을 다시 변경해야 합니다

[06:02] 이는 정말 귀찮은 일이 될 수 있죠

[06:05] 정말 짜증날 수 있습니다

[06:07] 더 많은 분자와 유기체를 만들수록

[06:08] 그리고 멤브레인이나 생태계같은

[06:11] 더 높은 수준의 추상화가 있다면

[06:13] 멤브레인이나 에코시스템과 같은 구조를

[06:15] 다루는 것은 정말 귀찮은 작업이 될 수 있죠

[06:18] 왜냐하면 하나의 변경사항을 추가하려면

[06:20] 모든 것을 다시 테스트해야 하기 때문입니다

[06:23] 상위 레벨의 모든 구성요소에 대해서

[06:25] 테스트가 필요하죠. 이것이 주요 단점입니다

[06:27] 게다가 적절한 구성 체인을 유지하기 위해서는

[06:29] 엄격한 규율이 필요합니다

[06:32] AI 코딩 도구에서 특히 귀찮은 점은

[06:35] 제가 언급했듯이, 삽입에 대한

[06:37] 하나의 변경이나 분자 수준의

[06:39] 작은 변경이 필요할 때조차

[06:42] 이를 사용하는 모든 것을 업데이트해야 한다는 것입니다

[06:44] 즉, 모든 상위 계층을 업데이트해야 하고

[06:47] 이는 AI 코딩 도구가 더 많은 컨텍스트를

[06:51] 컨텍스트 윈도우에 포함해야 한다는 의미입니다

[06:53] 이것이 원자적 구성 가능한 아키텍처입니다

[06:56] 보시다시피 이 구조에는 장단점이 있습니다

[06:58] 다음으로 넘어가보겠습니다

[07:00] 계층형 아키텍처는 가장 널리 알려지고

[07:03] 확립된 패턴입니다

[07:05] 기본적으로 임의의 계층들로 구성되어 있죠

[07:08] 임의의 디렉토리들이 있고

[07:12] 이들은 논리적으로 파일들을 모아놓은 것입니다

[07:14] 일반적으로 인터페이스 계층이 있고

[07:17] API 엔드포인트,

[07:20] 데이터 모델, 비즈니스 로직,

[07:21] 그리고 유틸리티 등이 있습니다

[07:24] 이는 매우 전형적인 구조입니다

[07:27] 실제로 어떤 코드베이스든

[07:29] 열어보면 이런 구조를 찾을 수 있습니다

[07:31] PostgreSQL 코드베이스를 보면

[07:34] 소스 코드에서 이러한 아키텍처를

[07:36] 쉽게 발견할 수 있습니다

[07:38] 이는 가장 단순한 아키텍처로

[07:41] 동적이며 확장성이 매우 좋습니다

[07:43] 보시다시피 특정 기능을 포함하는

[07:45] 여러 폴더들이 있습니다

[07:47] Redis 코드베이스에서도 같은 것을 볼 수 있는데

[07:49] Redis는 흥미롭게도

[07:51] 상대적으로 평면적인 아키텍처를 가지고 있으며

[07:53] 헤더와 C 파일들이 많이 있지만

[07:55] 그럼에도 이는 전형적인 계층형 아키텍처입니다

[07:57] 간단히 살펴보면, 명확한 관심사의 분리가 있고

[08:00] 각 디렉토리의 책임과 경계를

[08:02] 이해하기 쉽습니다

[08:04] 단점은 기본적으로

[08:06] 이러한 계층들 간에 임포트를 해야 한다는 것입니다

[08:08] AI 코딩 도구들은 API, 모듈, 서비스, 유틸리티 등

[08:10] 모든 것들을 처리해야 합니다

[08:15] 모든 영역에서 작동해야 하죠

[08:18] 이것이 이 아키텍처를 사용할 때의 트레이드오프입니다

[08:20] 주목할 점은 이것이 아마도

[08:24] 가장 인기 있는 아키텍처라는 것입니다

[08:27] 즉, 가장 널리 사용되는 아키텍처에서는

[08:28] 컨텍스트 윈도우에

[08:30] 많은 것을 임포트해야 합니다

[08:32] 이것은 매우 중요한 포인트입니다

[08:34] 계층형 아키텍처가

[08:35] AI 코딩 도구에 가장 적합한 것일까요?

[08:38] 저는 그렇지 않다고 생각합니다

[08:40] 이것이 계층형 아키텍처입니다

[08:42] 장점은 빠르게 작업하고

[08:44] 새로운 기능을 추가할 수 있다는 것입니다

[08:46] 이 아키텍처가 비즈니스와

[08:48] 개발팀 운영 측면에서 의미하는 바를 생각해보면

[08:50] 빠르게 기능을 추가하고 수정할 수 있어야 합니다

[08:53] 이것이 핵심이죠

[08:55] 이 아키텍처의 의미를 생각해보면

[08:57] 비즈니스와 개발팀이 어떻게 운영되는지

[09:00] 빠르게 추가하고 수정할 수 있어야 하며

[09:02] 이것이 여기서의 핵심입니다

[09:04] 그리고 이것이 기본적인 원리입니다

[09:07] 일반적으로 알다시피 어떤 형태의

[09:09] 계층화된 원자적 아키텍처가

[09:12] 계층형 아키텍처 내부에 포함되어 있죠

[09:14] 예를 들어, utils는 보통

[09:16] 가장 하위 레벨에 있습니다. utils는

[09:19] 여기로 돌아가보면 원자(atoms)와 같은 거죠

[09:22] 하지만 여기서부터 문제가 시작됩니다

[09:23] 그 이후에는 모든 종류의

[09:25] 모듈들을 가로지르는 임포트가 생길 수 있고

[09:29] 코드베이스를 봤을 때 명확하지 않습니다

[09:31] 예를 들어 우리가 postgres 데이터베이스로

[09:33] 돌아가서 소스를 클릭해보면

[09:38] 누가 누구를 임포트하는지,

[09:40] 어떤 규칙이 있는지 전혀 명확하지 않죠

[09:43] 이것이 바로 계층형 아키텍처입니다

[09:45] 매우 인기 있는 구조죠. 나쁘다는 게 아닙니다

[09:47] 이 아키텍처가 존재하는 데는 이유가 있어요

[09:48] 많은 고민 없이도 확장하고 이동하고

[09:50] 구축할 수 있게 해주죠

[09:52] 새로운 API가 필요하면 API 레이어로 가고

[09:54] 새 모델이 필요하면 models 디렉토리로 가면 됩니다

[09:57] 이런 식으로 계속되는 거죠

[09:59] 다시 말하지만 가장 큰 단점은

[10:01] AI가 이 모든 디렉토리를

[10:04] 살펴봐야 한다는 겁니다

[10:05] Claude 코드, Cursor 에이전트 모드에서는

[10:08] 모든 파일을 살펴봐야 하고

[10:10] 당연히 이것은

[10:12] 많은 토큰을 소비하게 됩니다

[10:15] 이제 매우 흥미로운 아키텍처로 넘어가보죠

[10:17] 여러 AI 코딩 분야의 프린시펄 멤버들과

[10:19] 수직 슬라이스 아키텍처에 대해 이야기를 나눴는데

[10:21] 계속해서 반복적으로 언급되었습니다

[10:23] 결론부터 말씀드리자면

[10:25] 수직 슬라이스 아키텍처가

[10:27] AI 코딩 도구와 에이전트 코딩 도구에 최적화된 구조라고 생각합니다

[10:30] 왜 그런지 설명해드리죠

[10:32] 한번 살펴보시면

[10:34] 바로 이해하실 수 있을 겁니다

[10:36] 이해하기가 매우 매우 간단합니다

[10:40] 왜 이것이 AI 코딩 도구에 최적화되어 있는지

[10:42] 모든 것이 슬라이스로 되어 있습니다

[10:46] features 디렉토리가 있고 그 안에

[10:49] 각각의 디렉토리들이 있는데, 이들은

[10:52] 특정 기능에 대한 모든 기능을 포함하고 있습니다

[10:54] 여러분의 제품 내에서

[10:56] 애플리케이션 안에서 users 기능 슬라이스가 있고

[10:59] 여기엔 API, 모델, 서비스가 포함되어 있습니다

[11:03] images 기능이 있고 여기에는

[11:05] API, 모델, FFmpeg가 포함되어 있죠

[11:08] 명확히 하자면

[11:10] 같은 파일 구조를 가질 필요는 없지만

[11:11] AI 코딩 도구에는 확실히 도움이 됩니다

[11:13] 모든 기능에 걸쳐 비슷한 api.py를 가지고 있다면

[11:16] 그리고 맨 아래에는

[11:18] messaging 기능이 있습니다

[11:20] 여기서 볼 수 있듯이 이것이

[11:21] 매우 매우 깔끔하고 간결할 수 있다는 걸 알 수 있죠

[11:25] 코딩 도구를 위해서요. 단순히 이 디렉토리 전체를

[11:29] 임포트하고 이 단일 디렉토리로 컨텍스트 프라이밍을 하면

[11:32] 바로 시작할 수 있습니다

[11:35] 심지어 두 개의 기능을

[11:37] 동시에 작업하고 있다면

[11:39] 두 기능도 함께 할 수 있죠

[11:40] 이것이 왜 매우 매우 흥미로운

[11:44] 코드베이스 아키텍처인지 이해하실 수 있을 겁니다

[11:45] 장점은 임의의 기술적 계층이 아닌

[11:49] 기능별로 구성되어 있다는 것입니다

[11:51] 물론 임의의 계층도

[11:53] 논리적 계층이라는 의미가 있지만

[11:55] 기능별로 구성함으로써

[11:57] 필요한 모든 것을 모으기가

[11:59] 훨씬 더 쉬워집니다

[12:01] 필요한 모든 컨텍스트를 하나의 컬렉션으로 모을 수 있고

[12:04] 여기서 할 수 있는 멋진 점은

[12:06] 이 모든 것이 하나의 프롬프트 컨텍스트 프라이밍이라는 겁니다

[12:09] AI 코딩 도구를 설정할 때

[12:11] 단 한 번의 작업으로 이걸 구현할 수 있죠

[12:12] 제가 이걸 빠르게 보여드리겠습니다

[12:14] 여기서 커서를 열고

[12:17] 단일 파일 에이전트 코드베이스로 들어가보면

[12:20] 새로운 디렉토리가 있는데

[12:22] codebase architectures라는 폴더가 있습니다

[12:25] 터미널을 열고 이 디렉토리로 이동해보면

[12:27] 수직 슬라이스 코드베이스 아키텍처가 있고

[12:30] 이게 수직 슬라이스의 모습입니다

[12:31] features 폴더가 있고 그 안에

[12:33] projects, tasks, users 등이 있습니다

[12:35] AIDER를 실행하고

[12:38] /add features/users/ 명령어를 입력하면

[12:44] 필요한 모든 코드베이스 컨텍스트가 설정됩니다

[12:46] 이게 전부입니다. 끝났죠

[12:49] 이제 '이게 뭘 하는 건가요?'라고 물어보면

[12:54] AI 코딩 어시스턴트가 준비를 마치고

[12:55] 바로 작업을 시작할 수 있는 상태가 됩니다

[12:58] 맞죠

[12:59] 똑같은 방식으로

[13:01] Claude 코드를 실행하려면 cd 명령어로

[13:04] codebase architectures vertical로 이동하고

[13:07] Claude를 열어서 우리가 자주 쓰는

[13:09] 컨텍스트 프라이밍 read 명령어를 사용합니다

[13:12] 마찬가지로 features/tasks/*.* 를 입력하면

[13:14] 모든 파일을 읽어들이고, 이제 보시면

[13:16] Claude가 이 파일들을 읽기 시작합니다

[13:20] 보세요, 새로운 병렬 하위 작업으로

[13:22] 모든 파일을 병렬로 읽어들이는데

[13:25] 도구들이 이런 기능을 제공하는 게 정말 좋죠

[13:27] 이제 준비가 완료됐습니다

[13:30] 엄청난 양의 토큰을 절약했고

[13:32] 시간도 많이 절약했으며

[13:35] 간단한 컨텍스트 프라이밍 프롬프트로

[13:37] 물론 여기에 README도

[13:38] 추가하고 싶을 테니 README도 포함시키면

[13:42] 이제 모든 준비가 끝났습니다

[13:44] 여기서 중요한 점을 말씀드리면

[13:45] 도구 자체는 그렇게 중요하지 않다는 겁니다

[13:48] 중요한 건 패턴이고 기술이며

[13:50] 원칙들입니다

[13:52] 바로 여러분입니다

[13:53] 너무 진부하게 들릴 수 있지만

[13:56] 원칙에 입각한 AI 코딩이 핵심입니다

[13:58] 이런 원칙들과 패턴들은

[14:00] 우리가 채널에서 다루고

[14:02] Principal AI Coding 코스에서 가르치는 것들인데

[14:04] 이를 통해 어떤 도구든, 어떤 모델이든

[14:07] 어떤 코드베이스든 시간이 지나도 다룰 수 있게 됩니다

[14:10] 저는 여러분이 오늘뿐만 아니라

[14:12] 내일, 모레도 계속 성공하기를 바랍니다

[14:14] 다른 도구를 열어보겠습니다

[14:17] 커서의 에이전트 모드를 열고

[14:19] '이걸 읽어줘'라고만 하면 됩니다

[14:23] 보세요, 네 개의 파일을

[14:25] 전부 읽어들이고 있습니다

[14:27] 커서 에이전트도 read 명령어를 인식해서

[14:29] model 파일, service 파일,

[14:31] app.py 파일을 읽어들이는 걸 볼 수 있죠

[14:33] read 도구들이 보이시죠? 이게 전부입니다

[14:37] 준비가 끝났어요. 이제 이 기능으로

[14:39] 작업할 수 있습니다. 어떤 도구를 쓰든

[14:41] 상관없습니다. 중요한 건 이런 기능들이

[14:44] 있다는 거죠. 우리는 컨텍스트 프라이밍으로

[14:46] 커서 에이전트 모드, Claude 코드, 그리고

[14:50] AIDER까지, 이 모든 코딩 도구들이

[14:53] 이제 준비됐고 여러분이

[14:55] 특정 컨텍스트 청크로

[14:58] 작업할 준비가 됐다는 겁니다

[15:00] 이 수직 슬라이스 컨텍스트로요

[15:04] 이것이 수직 슬라이스 아키텍처가 매우 중요한 이유입니다

[15:06] 프롬프트 컨텍스트 프라이밍이나

[15:08] 하나의 ADD 명령어로 넘어가면서

[15:11] 장점으로는 횡단 관심사를 최소화합니다.

[15:13] 여러분의 머릿속에서 톱니바퀴가 돌아가듯

[15:15] 이 코드베이스 아키텍처로 일해본

[15:17] 엔지니어라면 누구나,

[15:19] 아니면 단순히 이것의 트레이드오프를

[15:20] 고민해보신 분이라면 알겠지만

[15:22] 횡단 관심사를 최소화한다는 점이

[15:23] 엄청난 단점이 되기도 합니다.

[15:26] 자, 우리는 또한 기능 중심의, 가치 중심의

[15:29] 구조를 가지고 있죠.

[15:32] 항상 코드베이스 관점이 아닌

[15:34] 사용자와 고객의 관점에서

[15:35] 생각해야 합니다.

[15:37] 많은 장점들이 있지만

[15:41] 우리는 소프트웨어 엔지니어로서

[15:43] 너무 자만해서는 안 됩니다.

[15:45] 균형 잡힌 시각이 필요하죠.

[15:47] 단점들을 살펴보면, 이 구조는

[15:50] 코드 중복이 심각하게 발생합니다.

[15:53] 그 이유는 유틸리티나 공유 코드를

[15:56] 구축하는 것을 원하지 않기 때문입니다.

[15:58] 기능을 공유하는 유틸리티 폴더를

[16:01] 만들고 싶지 않습니다.

[16:03] 실제로 그런 공유를 피하고 싶습니다.

[16:05] 여기서 횡단 코드 공유는

[16:07] 큰 실수이며 안티패턴입니다.

[16:10] 수직 슬라이스 아키텍처를 사용할 때

[16:12] 왜 그럴까요?

[16:13] 모든 기능을 격리하고 싶기 때문입니다.

[16:17] 유틸리티를 구축하기 시작하면

[16:19] 여러 기능에 걸쳐 사용하게 되고

[16:21] 갑자기 유틸리티 파일이

[16:24] 점점 더 커지게 됩니다.

[16:25] 그리고 유틸리티 함수를 업데이트할 때

[16:27] 여러 기능에 걸쳐 업데이트해야 하고

[16:29] 결국 수직 슬라이스 아키텍처의

[16:31] 장점을 잃게 됩니다.

[16:33] 말 그대로 이 아키텍처의 목적을

[16:35] 무력화시키는 것이죠.

[16:38] 이러한 이유들로 인해

[16:39] 이 모든 것들이 거의 동일한 문제를 가집니다.

[16:41] 모두 같은 부작용에 대해

[16:43] 이야기하고 있습니다.

[16:44] 코드 재사용이 매우 어렵죠.

[16:46] 신입이나 중급 엔지니어들은

[16:48] 이 아키텍처에 매우 어려움을 겪을 것입니다.

[16:50] 코드가 중복될 수밖에 없기 때문이죠.

[16:52] 동일한 API 코드가 여기저기에

[16:54] 있을 것이고

[16:56] 비슷한 모델 스캐폴딩이

[16:58] 계속해서 반복될 것입니다.

[17:00] 이것은 훌륭하지만 보시다시피

[17:03] 트레이드오프는 어디에나 있습니다.

[17:05] 수직 슬라이스 아키텍처는 제가

[17:07] 앞으로 더 많이 실험해볼 것입니다.

[17:09] 단일 컨텍스트 패키지와 단일 청크에

[17:12] 모든 것을 격리하는 이 아이디어는

[17:16] AI 코딩 도구에 매우 강력합니다.

[17:19] 다음으로 파이프라인 아키텍처입니다.

[17:23] 파이프라인 아키텍처를 언급하지 않을 수 없죠.

[17:25] 함수형 프로그래머들,

[17:27] 진정한 프로그래머들이

[17:29] 이 아키텍처를 사랑합니다.

[17:31] AI 코딩 도구에는 특별히 강력하거나

[17:33] 중요하지는 않지만

[17:36] 그래도 나쁜 아키텍처는 아닙니다.

[17:38] 이것을 다루고 싶은 이유는

[17:41] 데이터 엔지니어나

[17:42] 데이터 파이프라인 작업을 하는

[17:44] ML Ops 엔지니어들에게

[17:46] 매우 일반적인 아키텍처이기 때문입니다.

[17:49] 파이프라인이 있고 공유 코드가 있죠.

[17:51] 파이프라인이 있고

[17:53] 유틸리티가 있고 그 다음에 단계별 구성요소가 있죠.

[17:55] 이 단계들이 모여서 파이프라인을 구성하고

[17:57] 그 파이프라인을 실행하게 됩니다.

[17:59] 파인튜닝을 하거나

[18:01] LLM을 처음부터 학습하거나 구축하는 사람이라면

[18:04] 이런 종류의 파이프라인 아키텍처를 가지고 있을 겁니다.

[18:06] 장점을 살펴보면, 순차적 처리에 아주 좋고

[18:09] LLM은 타입과 명확한 경로를 좋아합니다.

[18:12] 패턴을 좋아하죠.

[18:14] 따라서 이는 단계와 과정을 전달하는데

[18:17] 아주 좋은 아키텍처입니다.

[18:18] 단계들은 항상 적절한 타입과

[18:21] 데이터 구조를 연결하거나

[18:23] 외부 데이터베이스 구조에 저장하게 되죠.

[18:26] 그리고 당연히

[18:28] 언어 모델 AI 코딩 도구들은 이것을 좋아합니다.

[18:30] 패턴을 좋아하고 타입을 좋아하죠.

[18:31] 그들이 무엇을 해야 하는지

[18:33] 어디서 해야 하는지 이해하기 쉽게 만듭니다.

[18:35] 이러한 단계들을 가지고 쉽게

[18:37] 실험해볼 수 있고

[18:39] 순서를 빠르게 재배열할 수 있습니다.

[18:41] 병렬 처리는 파이프라인 아키텍처의

[18:43] 큰 장점입니다. 단점으로는

[18:46] 파이프라인 기반이 아닌

[18:48] 다른 것들에는 적합하지 않다는 것입니다.

[18:50] 다른 것들은 빠르게 넘어가보면

[18:52] 가장 큰 문제는

[18:53] 대부분의 코드베이스 구조에는 맞지 않는다는 것입니다.

[18:55] 우리 중 아주 소수만이

[18:58] 10% 미만의 엔지니어만이 파이프라인

[19:00] 아키텍처를 구축하고 있고

[19:01] 상태 관리가

[19:03] 까다로울 수 있습니다. 이렇게 네 가지를 봤는데

[19:05] 다른 아키텍처들도 많이 있지만

[19:07] 이 네 가지가 가장

[19:08] 중요하고 일반적인 구조라고 생각합니다.

[19:10] AI 시스템을 위한

[19:12] 아키텍처를 고려할 때 말이죠.

[19:14] AI 코딩을 위해 원자적 구성

[19:16] 계층화된 파이프라인, 수직 슬라이스를 살펴봤습니다.

[19:19] 이 모든 것들이 좋은 선택지입니다.

[19:20] 저는 AI 코딩에 최적화된 코드베이스를 구축하는데

[19:23] 수직과 원자적 구조를

[19:26] 강력히 선호합니다.

[19:27] 물론 AI 코딩에 최적화된 코드베이스를 만들 때

[19:30] 각각의 아키텍처에는 언급했듯이 트레이드오프가 있습니다.

[19:33] 이제 AI 에이전트로 관심을 돌려보면

[19:35] 흥미로운 질문이 생깁니다.

[19:38] 많은 사람들이 궁금해하는

[19:41] 질문이죠.

[19:42] AI 에이전트를 구축하는데

[19:44] 최적의 아키텍처는 무엇일까요?

[19:47] 세 가지 코드베이스 구조가 눈에 띕니다.

[19:48] 원자적 구성, 수직 슬라이스,

[19:52] 그리고 단일 파일 에이전트입니다.

[19:55] 우리 채널에서 단일 파일 에이전트를 다뤘는데

[19:57] 여기서는 이 세 가지 구조가 왜 좋은지

[20:00] 간단히 설명하고 싶습니다.

[20:03] AI 에이전트를 구축하려고 할 때

[20:06] 어떤 프레임워크를 사용하든

[20:07] 상관없습니다.

[20:09] MCP를 사용하든, Anthropic 에이전트나

[20:11] OpenAI 에이전트, Gemini 에이전트를 좋아하든

[20:13] 중요하지 않습니다.

[20:16] 이것은 모두 구조적인 것이고

[20:18] 모든 제공자와 함께 작동합니다.

[20:21] 몇 가지를 강조해보겠습니다.

[20:23] 단일 파일 에이전트 코드베이스로 가서

[20:25] 예제 에이전트 아키텍처를 보면

[20:27] 에이전트 아키텍처가

[20:29] 어떻게 생겼는지 보여드리겠습니다.

[20:31] 원자적 구성 아키텍처에서는

[20:33] 비슷한 구조를 사용하고 있는 것을 볼 수 있습니다.

[20:35] 이름들은 아시다시피 원자적 구조에서

[20:39] 정의된 대로 atoms, molecules, organisms,

[20:41] 그리고 membranes로 구성됩니다.

[20:43] 위에서부터 시작해보겠습니다.

[20:45] membrane은 메인 파일입니다.

[20:48] 이것은 실제로 에이전트를

[20:50] 시작하는 데 사용되며, 여기 아래에 main이 있습니다.

[20:54] args를 전달할 수 있고,

[20:56] 원한다면 여기서

[20:58] MCP를 구축할 수도 있습니다.

[21:01] 이렇게 MCP 에이전트를 만들고

[21:03] 이제 커맨드 라인 인터페이스와

[21:05] MCP 인터페이스를 갖게 됩니다.

[21:09] membrane은 말 그대로

[21:10] API 계층입니다. 시스템과 상호작용하는

[21:14] 모든 방법을 정의합니다.

[21:17] 원자적 시스템과의 상호작용 방식을 정의하고

[21:19] 실제 내용으로 들어가면

[21:22] organism이 있습니다.

[21:25] 여기서 organism은 우리의 파일 에이전트

[21:28] 예제에서 파일 에이전트입니다.

[21:31] 파일 에이전트는 molecules에서

[21:33] 필요한 것들을 구성합니다.

[21:36] 파일 리더와 파일 라이터를 구성하고

[21:38] 그 파일들은 파일 도구들을 구성합니다.

[21:42] 이렇게 위에서 아래로 작동하는 것을 볼 수 있죠.

[21:46] membrane은 접근 계층이고

[21:48] organism은 실제 파일 에이전트,

[21:50] molecule은 파일 에이전트를 구성하는 컴포넌트,

[21:53] 그리고 마지막으로 atoms는

[21:56] 가장 낮은 수준의 단위입니다.

[21:58] 독립적으로 테스트하고 실행할 수 있는

[22:01] 여기 insert file을 보면

[22:04] 단순한 함수입니다.

[22:06] 단일 함수로

[22:07] 격리되어 있고 쉽게 테스트하고 구성할 수 있습니다.

[22:10] 이것이 AI 에이전트가

[22:13] 원자적 구조 내에서 가질 수 있는 설계입니다.

[22:15] 참고로 이 디렉터리는 실행할 수 없습니다.

[22:17] 여기서 실행하려고 하지 마세요.

[22:18] 저는 이 공간을 탐구하고 있고

[22:20] 우리는 단지 다양한

[22:22] 잠재적 아키텍처를 살펴보고 있습니다.

[22:24] 이것이 AI 에이전트를 위한

[22:26] 원자적 구조입니다. 다른 좋은 옵션은

[22:28] 수직 슬라이스

[22:30] 아키텍처가 될 것 같습니다.

[22:32] 앞서 언급한 이유와 같은 맥락에서,

[22:35] 기능이나 슬라이스가 에이전트로 구분된다고

[22:38] 상상해볼 수 있습니다.

[22:41] 수직 슬라이스 아키텍처로 돌아가보면

[22:44] 일반적인 제품 애플리케이션의 기능 대신

[22:47] 에이전트를 구축할 때는

[22:49] 각각의 에이전트를 개별 기능으로 볼 수 있습니다.

[22:52] 이것이 정말 환상적인 이유는

[22:54] 에이전트 아래의 모든 것이

[22:56] 시작하는 데 필요한 모든 컨텍스트이기 때문입니다.

[22:58] AER을 열고

[23:00] vertical로 들어가서

[23:03] AER D- no get/add features SL blog agent를 실행하면

[23:06] 동일한 패턴을 볼 수 있습니다.

[23:08] 이제 우리의 에이전트가 준비되었고

[23:11] 더 이상 할 일이 없습니다.

[23:14] 블로그 에이전트를 운영하는 데 필요한

[23:16] 모든 도구가 있고, 모든 컨텍스트와

[23:18] 매니저, 모든 도구,

[23:21] 그리고 최상위 레벨의

[23:23] 블로그 에이전트가 있습니다.

[23:25] 이것이 수직 슬라이스가 중요한 이유이고

[23:27] AI 에이전트 구축에 아주 좋을 것 같습니다.

[23:29] 버전 관리가 매우 빠르기 때문이죠.

[23:31] 블로그 에이전트의 새 버전을

[23:32] 만들고 싶다면

[23:34] 전체를 그냥 복사해서

[23:36] 원하는 대로 업데이트하면 됩니다

[23:39] 아래처럼 블로그 에이전트 V2로 만들 수 있죠

[23:41] 파일 에이전트, 파일 에이전트 V2처럼요

[23:44] LLM 제공자를 변경하고 싶다면

[23:45] Gemini나 다른 걸로 바꿀 수도 있습니다

[23:47] 원하는 대로 할 수 있죠

[23:49] 에이전트를 만들고

[23:51] 에이전트 아키텍처를 설계할 때

[23:54] 수직 슬라이스 아키텍처가

[23:55] 확실히 눈에 띄는데요

[23:58] 마지막 아키텍처인 단일 파일 에이전트는

[24:00] 이전 영상에서 다뤘던 것처럼

[24:01] 매우 강력한 후보라고 생각합니다

[24:03] 아래로 스크롤해보면

[24:06] 단일 파일 에이전트

[24:08] 코드베이스에서 볼 수 있듯이

[24:10] 수많은 단일 파일 에이전트들이 있습니다

[24:14] 이 중 하나를 클릭해보면

[24:16] 최신 버전인 파일 에디터 v37이 있네요

[24:18] 이걸 클릭해보면

[24:21] 모든 것이 하나의 파일에 있습니다

[24:22] 다른 코드베이스에서 700줄짜리 파일은

[24:25] 안티패턴으로 여겨지지만

[24:28] 이 구조에서는

[24:30] 단일 파일 에이전트 코드베이스 아키텍처에서는

[24:33] 완전히 독립적인 단일 파일

[24:36] 컨텍스트 에이전트입니다

[24:39] 이것의 장점은 매우 단순한데

[24:42] 최상위 디렉토리로 이동해서

[24:45] 파일을 참조하고

[24:48] Claude를 열어서 읽기만 하면 됩니다

[24:51] 사실 이것조차도 필요 없이

[24:53] 바로 프롬프팅을 시작할 수 있죠

[24:55] Claude를 열고

[24:57] 프롬프팅을 시작하면 됩니다

[24:59] blah를 bleb로 바꾸는 등 원하는 작업을 할 수 있죠

[25:03] 이는 에이전트를 만드는 데

[25:05] 중요한 아키텍처입니다

[25:07] 저는 계속해서 단일 파일 에이전트를

[25:09] 강조할 건데요, 하나의 파일로

[25:13] AI 코딩 어시스턴트가

[25:15] 에이전트를 빠르게 업데이트할 수 있다는 점이

[25:18] 큰 장점이라고 생각합니다

[25:21] 명시적으로 언급하자면

[25:23] 이 채널에서 중점을 두는 두 가지 큰 주제는

[25:25] AI 코딩과 에이전트 코딩, 그리고

[25:28] AI 에이전트입니다

[25:31] 여기 AI 에이전트를 만들 때

[25:32] 사용할 수 있는 최적의 아키텍처가 있습니다

[25:35] 단일 파일 에이전트 코드베이스를

[25:37] 아직 확인하지 않으셨다면

[25:38] 설명란의 링크를 통해 확인해보세요

[25:40] 에이전트 아키텍처를 이해하고

[25:43] 새로운 생성형 AI 기술로

[25:45] 코드베이스를 구축하고 실행하는 것에 대해

[25:48] AI 코딩 도구와 AI 에이전트를 다룹니다

[25:51] 결론적으로 이게 정말 중요할까요?

[25:55] 우리가 살펴본

[25:57] 여러 아키텍처들의 장점을

[25:59] 확인했는데, 실제로 중요할까요?

[26:02] 이에 대해 두 가지 답변이 있습니다

[26:04] 단기적으로나 중기적으로는

[26:06] 좋은 코드베이스 아키텍처가 우리와

[26:10] AI 도구들의 컨텍스트 관리를

[26:12] 더 쉽게 만들어주므로 중요합니다

[26:15] 하지만 시간이 지날수록

[26:17] LLM과 Gemini가 발전함에 따라

[26:20] 코드베이스 구조의 중요성이

[26:23] 점점 줄어들 것이라고

[26:24] 주장할 수 있을 것 같습니다

[26:27] 이런 간단한 예시들을 통해

[26:29] 작은 규모에서도 알 수 있듯이

[26:32] 그리고 실제 대규모 코드베이스에서도

[26:35] 컨텍스트 관리가 중요합니다. 만약

[26:38] 컨텍스트를 잘 관리하면 결과도 잘 관리할 수 있죠

[26:41] 정확한 컨텍스트 관리가

[26:44] 여전히 중요합니다. AI에게는 명확한 경로가 필요해요

[26:47] 구체적으로 말하면 LLM이나

[26:49] LLM 또는 AI 코딩 도구들에게는 명확한 경로가 필요합니다

[26:52] 단일 파일뿐만 아니라 파일들의 모음,

[26:55] 정보의 모음이 필요하죠

[26:58] 우리 모두 알다시피 Claude, Copilot 같은

[27:00] 이런 도구들은 토큰을 소비합니다

[27:03] 그리고 단순히 정보를 찾는 데에도 토큰을 소비하죠

[27:07] 실제 작업이나 가치 창출도 하기 전에

[27:09] 토큰을 소비합니다

[27:11] 이는 코드베이스의 잘못된 구조 때문이에요

[27:14] 계속 강조하지만

[27:16] 레이어드 아키텍처는

[27:19] AI 코딩 도구가 모든 것을 읽도록 강요합니다

[27:22] 전부 다 살펴봐야 하죠

[27:24] API 파일을 찾을 때도

[27:26] 20개의 파일을

[27:27] 전부 검색해야 합니다

[27:28] API 관련 20개의 파일을 모두 살펴봐야 하죠

[27:31] 이런 상황에서 아토믹 구조와

[27:34] 특히 버티컬 슬라이스 구조가

[27:37] 더욱 돋보이게 됩니다

[27:40] 버티컬 슬라이스

[27:41] 아키텍처를 잘 구현할 수 있다면

[27:44] 엄청난 양의 토큰을 절약할 수 있습니다

[27:47] 왜 이게 중요한지 아시겠죠?

[27:50] 코드베이스를 구성할 때

[27:51] 시간과 토큰을

[27:52] 쉽게 절약할 수 있게 만드는 거죠

[27:54] 이는 곧 비용 절감을 의미합니다

[27:57] 잘 구조화된 코드는 비용 효율적입니다

[28:00] 균형이 매우 중요한데

[28:01] 대부분은 아직도

[28:03] 사람이 읽기 쉽게 코드를 작성하고 있죠

[28:06] 이제 이 트렌드를 바꿔야 할 때입니다

[28:08] 저는 이미 바꾸고 있어요

[28:10] 여러분도 함께 하시길 바랍니다

[28:12] 앞으로는 대부분의 코드를 AI가 작성할 겁니다

[28:14] AI 도구들, AI 코딩 어시스턴트,

[28:17] 에이전트 코딩 도구들이

[28:19] 대부분의 코드를 작성할 거예요

[28:20] 이제 우리는 코드베이스를

[28:23] AI의 관점에서 생각해야 합니다

[28:25] 컨텍스트 관리를 단순화하고

[28:28] 전체 프로세스를

[28:30] AI 도구에 효과적으로 넘길 수 있도록

[28:33] 이것이 바로 AI 가독성이

[28:35] 이제 사람의 가독성보다 더 중요해진 이유입니다

[28:38] 목표는 개발자와 AI 도구 모두가

[28:41] 코드베이스를 효율적이고 효과적으로

[28:44] 탐색할 수 있도록 돕는 것입니다

[28:47] 모든 Principled AI Coding 멤버들에게

[28:48] 중요한 소식을 전해드리겠습니다

[28:51] 3월 말에 AI 코딩의 현재 상태에 대한

[28:54] 에세이를 발표할 예정입니다

[28:57] 이를 통해 AI 코딩과 에이전트 코딩의

[29:00] 현재 동향을 이해하실 수 있을 겁니다

[29:02] 제가 추가하는 도구들과

[29:05] 제거하는 도구들을 공유하고

[29:07] 앞으로의 방향에 대해 논의할 것이며

[29:09] 엔지니어로서 여러분이

[29:11] 현재 어느 수준이고 어디까지 성장할 수 있는지

[29:14] 티어 리스트로 정리해 드릴 예정입니다

[29:17] 모든 내용을 하나의 포괄적인

[29:19] 문서로 정리할 것입니다

[29:21] 이 에세이를 통해

[29:23] AI 코딩과 에이전트 코딩에 대한 인사이트와

[29:26] 제가 보고 있는 주요 트렌드,

[29:29] 그리고 제가 시간과 자금을 투자하며

[29:31] 준비하고 있는 방향을 공유하겠습니다

[29:33] 이러한 아이디어들과 더 많은 내용을

[29:35] 2025년 1분기 AI 코딩 현황에 대해

[29:38] 여러분과 공유할 예정인데, 이는 과정을 완료한

[29:42] Principled AI Coding 멤버들만을 위한

[29:43] 독점 콘텐츠가 될 것입니다.

[29:46] 아직 Principled AI Coding에 참여하지 않으셨다면,

[29:49] 이 과정을 꼭 확인해보시기를

[29:51] 추천드립니다. 특히 이 영상을

[29:52] 여기까지 보셨다면, 확실히 실력이 있으시고

[29:54] 훌륭한 설계와 아키텍처에 관심이 있는

[29:57] 엔지니어라는 것이 분명합니다.

[29:59] AI 코딩 열차를 놓치지 마세요.

[30:03] 우리는 빠르게 AI 코딩에서

[30:06] AI 코딩의 다음 단계인 에이전트 코딩으로

[30:08] 전환하고 있습니다. 이것이 새로운 표준입니다.

[30:12] 아직 깨닫지 못하셨다면,

[30:13] 이것이 바로 코드가 작성되는 방식입니다.

[30:17] 우리가 논의했듯이 대부분의 코드는

[30:19] AI 코딩 도구에 의해 작성될 것입니다.

[30:23] 2025년은 이 열차에 탑승할 수 있는 마지막 해입니다.

[30:27] 여러분의 경력이 낙후되기 전에,

[30:29] 엔지니어링 능력이 뒤처지기 전에 참여하세요.

[30:31] 8개의 강의를 통해 핵심 원칙들을 다룹니다.

[30:34] 빅3라고 하는 컨텍스트, 모델, 프롬프트와 같은

[30:37] 원칙들을 배우게 되는데, 이는

[30:40] 생성형 AI 시대에서 엔지니어로서 성공하는데

[30:43] 도움이 될 것입니다. 초급에서 중급,

[30:45] 고급까지 다루며,

[30:48] 현업 엔지니어들로부터 훌륭한 평가를

[30:50] 받고 있습니다. 지금 참여하세요.

[30:53] 링크는 설명란에 있습니다.

[30:55] 기존 Principled AI Coding 멤버들은

[30:57] 3월 말에 공개될 AI 코딩 현황 분석을

[31:00] 기대해 주세요.

[31:04] 많은 가치 있는 내용을 담아

[31:07] 의사결정에 도움을 드리고

[31:09] 생성형 AI 물결의 최전선에 설 수 있도록

[31:11] 도와드리겠습니다. 저를 찾으실 곳은

[31:14] 매주 월요일입니다. 좋아요와 구독,

[31:18] 댓글 부탁드립니다.

[31:20] 다음 영상에서 뵙겠습니다. 집중하시고 계속 구축해 나가세요.