[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]
다음 영상에서 뵙겠습니다. 집중하시고 계속 구축해 나가세요.