실전 예제 X-to-Book System 분석 완벽 가이드

Claude Agent SDK의 핵심 스킬들이 실제 프로젝트에서 어떻게 조합되는지 X-to-Book System을 통해 분석합니다. 멀티 에이전트 패턴부터 메모리 시스템까지, 실전 아키텍처의 비밀을 파헤쳐 봅니다.

---

목차

1. 프로젝트_개요_X_모니터링에서_일일_북_생성까지
2. 폴더_구조_탐색_examples_x-to-book-system
3. 적용된_스킬_다섯가지_핵심_패턴
4. 아키텍처_결정_사항_분석
5. PRD와_Skills_매핑_읽기
6. 김개발의_도전_직접_구현해보기

---

1. 프로젝트 개요 X 모니터링에서 일일 북 생성까지

김개발 씨는 회사에서 흥미로운 프로젝트를 맡게 되었습니다. "X(트위터)에서 특정 주제의 트윗을 모니터링하고, 매일 자동으로 책 형태의 콘텐츠를 생성하는 시스템을 만들어 주세요." 처음에는 단순해 보였지만, 막상 설계를 시작하니 생각보다 복잡한 문제들이 산적해 있었습니다.

X-to-Book System은 소셜 미디어 모니터링부터 콘텐츠 생성까지 전 과정을 자동화하는 멀티 에이전트 시스템입니다. 마치 뉴스룸에서 기자들이 취재하고, 편집자가 정리하고, 최종적으로 책으로 엮어내는 과정을 AI 에이전트들이 협업하여 수행합니다.

이 시스템을 이해하면 복잡한 AI 워크플로우를 설계하는 핵심 원리를 터득할 수 있습니다.

다음 코드를 살펴봅시다.

// X-to-Book System의 핵심 파이프라인 구조
interface XToBookPipeline {
  // 1단계: X 모니터링 에이전트
  monitorAgent: {
    role: "collector";
    sources: ["twitter_api", "search_queries"];
    output: "raw_tweets";
  };
  // 2단계: 콘텐츠 분석 에이전트
  analysisAgent: {
    role: "analyzer";
    input: "raw_tweets";
    output: "categorized_insights";
  };
  // 3단계: 북 생성 에이전트
  bookAgent: {
    role: "writer";
    input: "categorized_insights";
    output: "daily_book_content";
  };
}

김개발 씨는 입사 1년 차 AI 엔지니어입니다. 어느 날 팀장님이 다가와 새로운 프로젝트를 설명했습니다.

"요즘 X에 올라오는 기술 트렌드를 매일 정리해서 팀원들과 공유하고 싶은데, 수작업으로는 한계가 있어요. 자동화할 수 있을까요?" 김개발 씨는 처음에는 간단한 크롤러 정도면 될 줄 알았습니다.

하지만 요구사항을 정리하다 보니 생각보다 복잡했습니다. 단순히 트윗을 수집하는 것에서 끝나는 게 아니라, 의미 있는 내용을 선별하고, 주제별로 분류하고, 읽기 좋은 형태로 가공해야 했습니다.

그렇다면 X-to-Book System이란 정확히 무엇일까요? 쉽게 비유하자면, 이 시스템은 마치 출판사의 워크플로우와 같습니다.

기자가 현장에서 뉴스를 취재하고, 편집자가 기사를 다듬고, 최종적으로 편집장이 책으로 엮어내는 것처럼요. X-to-Book System에서는 각 역할을 AI 에이전트가 담당합니다.

첫 번째 에이전트는 모니터링 에이전트입니다. 이 에이전트는 X API를 통해 특정 키워드나 계정의 트윗을 실시간으로 수집합니다.

마치 특파원이 세계 각지에서 뉴스를 모아오는 것과 같습니다. 두 번째 에이전트는 분석 에이전트입니다.

수집된 수많은 트윗 중에서 의미 있는 것을 골라내고, 주제별로 분류합니다. 스팸이나 광고성 트윗은 걸러내고, 실제로 가치 있는 인사이트만 추출합니다.

세 번째 에이전트는 북 생성 에이전트입니다. 분석된 인사이트를 받아 읽기 좋은 책 형태의 콘텐츠로 가공합니다.

단순 나열이 아니라, 스토리텔링이 있는 구조화된 문서를 만들어냅니다. 이 세 에이전트가 파이프라인 형태로 연결되어 매일 자동으로 작동합니다.

아침에 시스템이 돌아가면, 저녁에는 그날의 기술 트렌드를 정리한 북이 완성되어 있는 것입니다. 김개발 씨는 이 구조를 이해하고 나서야 비로소 프로젝트의 전체 그림이 보이기 시작했습니다.

단일 프로그램이 아니라, 여러 전문가가 협업하는 팀을 만드는 것이었습니다. X-to-Book System의 핵심은 관심사의 분리입니다.

각 에이전트는 자신의 역할에만 집중하면 됩니다. 모니터링 에이전트는 수집만, 분석 에이전트는 분석만, 북 생성 에이전트는 글쓰기만 담당합니다.

이렇게 하면 각 부분을 독립적으로 개선하고 테스트할 수 있습니다.

실전 팁

💡 - 복잡한 AI 시스템은 단일 에이전트보다 역할별 에이전트로 분리하는 것이 유지보수에 유리합니다

• 파이프라인의 각 단계는 명확한 입력과 출력 인터페이스를 정의해야 합니다

---

2. 폴더 구조 탐색 examples x-to-book-system

김개발 씨가 X-to-Book System의 예제 코드를 처음 열어봤을 때, 수많은 폴더와 파일에 잠시 당황했습니다. 하지만 선배 박시니어 씨가 옆에서 차근차근 설명해주기 시작했습니다.

"폴더 구조를 이해하면 시스템의 절반은 파악한 거예요."

잘 설계된 폴더 구조는 프로젝트의 지도와 같습니다. X-to-Book System의 폴더 구조는 관심사별로 명확하게 분리되어 있어, 어떤 기능이 어디에 있는지 직관적으로 파악할 수 있습니다.

이 구조를 익히면 비슷한 멀티 에이전트 프로젝트를 설계할 때 참고할 수 있는 좋은 템플릿이 됩니다.

다음 코드를 살펴봅시다.

// X-to-Book System 폴더 구조
examples/x-to-book-system/
├── agents/                 // 개별 에이전트 정의
│   ├── monitor-agent.ts    // X 모니터링 담당
│   ├── analysis-agent.ts   // 콘텐츠 분석 담당
│   └── book-agent.ts       // 북 생성 담당
├── tools/                  // 에이전트가 사용하는 도구들
│   ├── x-api-tool.ts       // X API 호출
│   ├── storage-tool.ts     // 데이터 저장
│   └── format-tool.ts      // 출력 포맷팅
├── memory/                 // 메모리 시스템
│   ├── short-term.ts       // 단기 메모리
│   └── long-term.ts        // 장기 메모리
├── orchestrator.ts         // 에이전트 조율자
└── config.ts               // 설정 파일

김개발 씨는 VS Code에서 프로젝트 폴더를 열어봤습니다. 처음 보는 구조에 어디서부터 봐야 할지 막막했습니다.

그때 박시니어 씨가 다가왔습니다. "폴더 구조를 읽는 것도 하나의 스킬이에요.

마치 건물의 평면도를 보는 것처럼, 전체 구조를 먼저 파악하면 세부 사항이 눈에 들어오기 시작합니다." 먼저 agents 폴더를 살펴봅시다. 이 폴더에는 시스템의 핵심인 세 개의 에이전트가 정의되어 있습니다.

monitor-agent.ts는 X에서 데이터를 수집하는 역할을, analysis-agent.ts는 수집된 데이터를 분석하는 역할을, book-agent.ts는 최종 콘텐츠를 생성하는 역할을 담당합니다. 다음은 tools 폴더입니다.

에이전트들이 실제로 작업을 수행할 때 사용하는 도구들이 모여 있습니다. 마치 목수에게 망치와 톱이 필요하듯, AI 에이전트에게도 API 호출이나 파일 저장 같은 도구가 필요합니다.

memory 폴더는 특히 흥미롭습니다. 에이전트가 이전에 처리한 정보를 기억하고 활용할 수 있게 해주는 메모리 시스템이 구현되어 있습니다.

단기 메모리는 현재 작업 중인 정보를, 장기 메모리는 과거의 인사이트를 저장합니다. 최상위에 있는 orchestrator.ts는 지휘자와 같은 역할을 합니다.

세 에이전트가 언제, 어떤 순서로 작동할지를 조율합니다. 마치 오케스트라의 지휘자가 각 악기의 연주 순서를 조율하는 것처럼요.

config.ts는 시스템의 설정값들을 한곳에 모아둔 파일입니다. API 키, 모니터링 키워드, 스케줄 정보 등이 여기에 정의됩니다.

설정을 코드와 분리해두면 환경에 따라 쉽게 변경할 수 있습니다. 김개발 씨는 폴더 구조를 훑어보며 고개를 끄덕였습니다.

"아, 이렇게 역할별로 분리해두니까 어디를 수정해야 할지 바로 알 수 있겠네요." 박시니어 씨가 덧붙였습니다. "맞아요.

예를 들어 X API가 변경되면 tools/x-api-tool.ts만 수정하면 됩니다. 다른 부분은 건드릴 필요가 없어요.

이게 바로 관심사 분리의 장점이에요." 이 폴더 구조는 클린 아키텍처의 원칙을 따르고 있습니다. 비즈니스 로직(agents)과 인프라(tools), 그리고 상태 관리(memory)가 명확히 분리되어 있습니다.

실전 팁

💡 - 새로운 프로젝트를 시작할 때 이 폴더 구조를 템플릿으로 활용할 수 있습니다

• 폴더명은 그 안에 무엇이 있는지 명확하게 드러내야 합니다

---

3. 적용된 스킬 다섯가지 핵심 패턴

박시니어 씨가 화이트보드에 다섯 개의 키워드를 적었습니다. "이 시스템에는 다섯 가지 핵심 스킬이 적용되어 있어요.

이걸 이해하면 왜 이렇게 설계했는지 알 수 있습니다." 김개발 씨는 메모장을 꺼내 집중하기 시작했습니다.

X-to-Book System에는 Multi-Agent Patterns, Memory Systems, Context Optimization, Tool Design, Evaluation이라는 다섯 가지 핵심 스킬이 적용되어 있습니다. 이 스킬들은 Claude Agent SDK에서 제공하는 패턴들로, 복잡한 AI 시스템을 구축할 때 반드시 알아야 할 개념들입니다.

다음 코드를 살펴봅시다.

// 다섯 가지 핵심 스킬의 적용 예시
const systemSkills = {
  // 1. 멀티 에이전트 패턴: 역할 분담
  multiAgentPatterns: {
    pattern: "pipeline",
    agents: ["monitor", "analysis", "book"],
    coordination: "sequential"
  },
  // 2. 메모리 시스템: 컨텍스트 유지
  memorySystems: {
    shortTerm: "current_session_tweets",
    longTerm: "historical_insights_db"
  },
  // 3. 컨텍스트 최적화: 토큰 효율화
  contextOptimization: {
    strategy: "sliding_window",
    maxTokens: 100000
  },
  // 4. 도구 설계: 명확한 인터페이스
  toolDesign: {
    principles: ["single_responsibility", "clear_schemas"]
  },
  // 5. 평가: 품질 검증
  evaluation: {
    metrics: ["relevance", "coherence", "accuracy"]
  }
};

김개발 씨는 다섯 가지 스킬을 하나씩 살펴보기 시작했습니다. 각각이 시스템의 어떤 부분과 연결되는지 이해하는 것이 중요했습니다.

첫 번째는 Multi-Agent Patterns, 즉 멀티 에이전트 패턴입니다. 이 시스템에서는 파이프라인 패턴을 사용합니다.

세 에이전트가 순차적으로 작동하며, 앞 에이전트의 출력이 뒤 에이전트의 입력이 됩니다. 마치 공장의 조립 라인처럼, 각 단계에서 가공된 결과물이 다음 단계로 전달됩니다.

두 번째는 Memory Systems, 메모리 시스템입니다. 에이전트가 모든 것을 처음부터 다시 처리하면 비효율적입니다.

어제 분석한 트윗을 오늘 다시 분석할 필요가 없지요. 메모리 시스템은 과거의 처리 결과를 저장해두었다가 필요할 때 참조할 수 있게 해줍니다.

세 번째는 Context Optimization, 컨텍스트 최적화입니다. AI 모델에는 한 번에 처리할 수 있는 토큰 수에 제한이 있습니다.

수천 개의 트윗을 한꺼번에 던져줄 수는 없지요. 슬라이딩 윈도우 전략을 사용해 가장 관련성 높은 정보만 선별하여 컨텍스트에 포함시킵니다.

네 번째는 Tool Design, 도구 설계입니다. 에이전트가 사용하는 도구들은 명확한 인터페이스를 가져야 합니다.

각 도구는 하나의 책임만 지며(단일 책임 원칙), 입력과 출력의 스키마가 명확하게 정의되어 있습니다. 이렇게 하면 도구를 교체하거나 수정할 때 다른 부분에 영향을 주지 않습니다.

다섯 번째는 Evaluation, 평가 시스템입니다. AI가 생성한 콘텐츠가 실제로 품질이 좋은지 어떻게 알 수 있을까요?

관련성, 일관성, 정확성 등의 지표를 정의하고, 자동으로 품질을 측정합니다. 품질이 기준에 미치지 못하면 재생성을 요청할 수도 있습니다.

박시니어 씨가 설명했습니다. "이 다섯 가지 스킬은 서로 독립적이면서도 유기적으로 연결되어 있어요.

멀티 에이전트 패턴이 시스템의 뼈대라면, 메모리 시스템은 기억력, 컨텍스트 최적화는 집중력, 도구 설계는 손과 발, 평가 시스템은 자기 점검 능력이라고 볼 수 있지요." 김개발 씨는 이제 각 스킬이 왜 필요한지 이해했습니다. 단순히 코드를 작성하는 것이 아니라, 이런 원칙들을 바탕으로 설계해야 견고한 시스템이 만들어지는 것입니다.

실전 팁

💡 - 다섯 가지 스킬은 독립적으로 학습하고, 실제 프로젝트에서 조합하여 적용합니다

• 각 스킬에 대한 깊은 이해는 Claude Agent SDK 문서를 참고하세요

---

4. 아키텍처 결정 사항 분석

김개발 씨가 코드를 더 깊이 살펴보다가 문득 궁금해졌습니다. "왜 이렇게 설계했을까요?

다른 방법도 있었을 텐데..." 박시니어 씨가 웃으며 대답했습니다. "좋은 질문이에요.

모든 아키텍처 결정에는 이유가 있습니다."

아키텍처 결정은 단순한 코딩이 아니라 트레이드오프의 연속입니다. X-to-Book System에서는 왜 파이프라인 패턴을 선택했는지, 왜 메모리를 이원화했는지, 왜 특정 도구 인터페이스를 사용했는지 각각의 이유가 있습니다.

이 결정들을 이해하면 여러분의 프로젝트에서도 올바른 선택을 할 수 있게 됩니다.

다음 코드를 살펴봅시다.

// 아키텍처 결정 사항 문서화 예시
const architectureDecisions = {
  decision1: {
    title: "파이프라인 vs 병렬 처리",
    choice: "파이프라인",
    reason: "각 단계의 출력이 다음 단계의 입력으로 필요",
    tradeoff: "처리 속도보다 데이터 일관성 우선"
  },
  decision2: {
    title: "단기/장기 메모리 분리",
    choice: "이원화된 메모리 시스템",
    reason: "실시간 처리와 장기 인사이트 모두 필요",
    tradeoff: "복잡도 증가 vs 기능성 확보"
  },
  decision3: {
    title: "에이전트 간 통신 방식",
    choice: "메시지 큐 기반",
    reason: "느슨한 결합으로 독립적 확장 가능",
    tradeoff: "즉시 호출보다 약간의 지연 허용"
  }
};

소프트웨어 아키텍처에서 "정답"은 없습니다. 있는 것은 "상황에 맞는 최선의 선택"뿐입니다.

X-to-Book System의 주요 아키텍처 결정을 하나씩 살펴보겠습니다. 첫 번째 결정은 파이프라인 패턴의 선택입니다.

세 에이전트를 병렬로 실행할 수도 있었습니다. 하지만 이 시스템에서는 분석 에이전트가 모니터링 에이전트의 결과를 필요로 하고, 북 생성 에이전트가 분석 에이전트의 결과를 필요로 합니다.

순서가 중요한 것입니다. 병렬 처리가 더 빠를 수 있지만, 데이터의 일관성을 보장하기 어렵습니다.

파이프라인을 선택함으로써 각 단계가 완전한 데이터를 받아 처리할 수 있게 되었습니다. 두 번째 결정은 메모리 시스템의 이원화입니다.

단일 메모리로 구현하는 것이 더 단순했을 것입니다. 하지만 단기 메모리와 장기 메모리는 그 특성이 다릅니다.

단기 메모리는 현재 세션에서 빠르게 접근해야 하는 정보를 담습니다. 속도가 중요합니다.

반면 장기 메모리는 며칠, 몇 주에 걸친 인사이트를 저장합니다. 검색 가능성과 지속성이 중요합니다.

이 두 가지를 분리함으로써 각각에 최적화된 저장 전략을 적용할 수 있었습니다. 세 번째 결정은 에이전트 간 통신 방식입니다.

에이전트끼리 직접 함수를 호출하는 방식이 더 단순합니다. 하지만 메시지 큐를 통한 간접 통신을 선택했습니다.

이렇게 하면 각 에이전트가 독립적으로 확장될 수 있습니다. 모니터링 부하가 커지면 모니터링 에이전트만 늘리면 됩니다.

또한 한 에이전트에 문제가 생겨도 다른 에이전트에 직접적인 영향을 주지 않습니다. 박시니어 씨가 말했습니다.

"아키텍처 결정은 현재의 요구사항뿐 아니라 미래의 변화도 고려해야 해요. 지금 당장은 복잡해 보여도, 시스템이 성장할 때 빛을 발하는 결정들이 있지요." 김개발 씨는 고개를 끄덕였습니다.

단순히 "돌아가는 코드"가 아니라 "성장할 수 있는 코드"를 작성해야 한다는 것을 깨달았습니다. 아키텍처 결정을 문서화하는 것도 중요합니다.

왜 이런 선택을 했는지 기록해두면, 나중에 시스템을 수정할 때 맥락을 잃지 않을 수 있습니다.

실전 팁

💡 - 모든 아키텍처 결정에는 트레이드오프가 있음을 인식하세요

• 결정의 이유를 문서화해두면 나중에 큰 도움이 됩니다

---

5. PRD와 Skills 매핑 읽기

프로젝트 폴더에서 김개발 씨는 PRD.md 파일을 발견했습니다. "PRD가 뭐예요?" 박시니어 씨가 대답했습니다.

"Product Requirements Document, 제품 요구사항 문서예요. 이걸 어떻게 기술 스킬과 매핑하는지 아는 것이 중요합니다."

PRD는 "무엇을"만들어야 하는지를 정의하고, Skills 매핑은 "어떻게" 만들지를 연결합니다. X-to-Book System에서는 각 요구사항이 어떤 스킬로 구현되는지 명확하게 매핑되어 있습니다.

이 매핑을 읽을 줄 알면 요구사항에서 구현까지의 사고 과정을 이해할 수 있습니다.

다음 코드를 살펴봅시다.

// PRD 요구사항과 Skills 매핑
const prdToSkillsMapping = {
  // PRD 요구사항 1: 실시간 트윗 모니터링
  requirement1: {
    prd: "특정 키워드의 트윗을 실시간 수집",
    skills: ["tool-design"],
    implementation: "x-api-tool.ts"
  },
  // PRD 요구사항 2: 중복 제거 및 분류
  requirement2: {
    prd: "중복 트윗 제거 및 주제별 분류",
    skills: ["memory-systems", "context-optimization"],
    implementation: "analysis-agent.ts + long-term.ts"
  },
  // PRD 요구사항 3: 일일 북 자동 생성
  requirement3: {
    prd: "매일 정해진 시간에 북 형태로 출력",
    skills: ["multi-agent-patterns", "evaluation"],
    implementation: "orchestrator.ts + book-agent.ts"
  }
};

김개발 씨는 PRD.md 파일을 열어봤습니다. 거기에는 시스템이 해야 할 일들이 사용자 관점에서 정리되어 있었습니다.

"X에서 특정 키워드가 포함된 트윗을 실시간으로 수집한다." "수집된 트윗 중 중복을 제거하고 주제별로 분류한다." "매일 오전 9시에 전날의 인사이트를 책 형태로 생성한다." 이런 요구사항들이 나열되어 있었습니다. 하지만 이것만으로는 어떻게 구현해야 할지 바로 떠오르지 않았습니다.

박시니어 씨가 설명했습니다. "PRD는 비즈니스 언어로 작성됩니다.

이걸 기술 언어로 번역하는 과정이 필요해요. 그게 바로 Skills 매핑입니다." 첫 번째 요구사항인 "실시간 트윗 수집"을 보겠습니다.

이것은 tool-design 스킬과 연결됩니다. X API를 호출하는 도구를 잘 설계해야 안정적으로 데이터를 수집할 수 있습니다.

두 번째 요구사항인 "중복 제거 및 분류"는 더 복잡합니다. 이미 처리한 트윗인지 확인하려면 memory-systems가 필요합니다.

또한 수많은 트윗 중에서 관련성 높은 것을 선별하려면 context-optimization이 필요합니다. 세 번째 요구사항인 "일일 북 생성"은 여러 에이전트의 협업이 필요합니다.

multi-agent-patterns로 에이전트들을 조율하고, 생성된 결과물의 품질을 evaluation으로 검증합니다. 이렇게 요구사항 하나가 여러 스킬과 연결될 수 있고, 하나의 스킬이 여러 요구사항에 활용될 수도 있습니다.

김개발 씨가 물었습니다. "이런 매핑은 누가 하는 건가요?" "보통 시니어 개발자나 아키텍트가 합니다.

하지만 주니어도 이 매핑을 읽고 이해할 줄 알아야 해요. 그래야 자신이 작업하는 부분이 전체 시스템에서 어떤 역할을 하는지 알 수 있으니까요." PRD와 Skills 매핑을 이해하면 또 다른 이점이 있습니다.

새로운 요구사항이 추가될 때, 어떤 스킬이 필요한지 빠르게 파악할 수 있습니다. 또한 특정 스킬에 문제가 생겼을 때, 어떤 요구사항이 영향을 받는지 역추적할 수 있습니다.

실전 팁

💡 - PRD를 읽을 때 "이걸 구현하려면 어떤 기술이 필요할까?"를 항상 생각하세요

• 매핑을 문서화해두면 팀원 간 소통이 원활해집니다

---

6. 김개발의 도전 직접 구현해보기

박시니어 씨가 마지막으로 말했습니다. "이제 이론은 충분해요.

직접 구현해보는 것만큼 좋은 학습은 없습니다." 김개발 씨는 조금 긴장되면서도 설레는 마음으로 키보드에 손을 올렸습니다.

이론을 완벽히 이해했다고 해도 직접 코드를 작성해보지 않으면 진정한 이해라고 할 수 없습니다. X-to-Book System을 직접 구현해보면서 앞서 배운 다섯 가지 스킬을 실제로 적용해봅시다.

작은 부분부터 시작해서 점진적으로 확장하는 것이 핵심입니다.

다음 코드를 살펴봅시다.

// 도전 과제: 간단한 버전부터 시작하기
// Step 1: 기본 에이전트 구조 만들기
import { Agent } from "@anthropic-ai/agent-sdk";

const monitorAgent = new Agent({
  name: "monitor",
  description: "X에서 트윗을 수집합니다",
  tools: [xApiTool],
  // 도전: 여기에 적절한 설정 추가하기
});

// Step 2: 간단한 파이프라인 연결
async function runPipeline(keyword: string) {
  const tweets = await monitorAgent.run(`${keyword} 관련 트윗 수집`);
  // 도전: 분석 에이전트와 북 생성 에이전트 연결하기
  return tweets;
}

// Step 3: 메모리 시스템 추가
// 도전: 중복 트윗 필터링 로직 구현하기

김개발 씨는 빈 프로젝트 폴더를 열었습니다. 어디서부터 시작해야 할까요?

박시니어 씨의 조언이 떠올랐습니다. "처음부터 완벽하게 만들려고 하지 마세요.

가장 작은 동작하는 버전부터 시작하세요." 첫 번째 도전은 기본 에이전트 구조 만들기입니다. Claude Agent SDK를 설치하고, 가장 단순한 형태의 모니터링 에이전트를 만들어봅니다.

아직 실제 X API 연동은 하지 않아도 됩니다. 하드코딩된 샘플 데이터로 시작해도 좋습니다.

두 번째 도전은 파이프라인 연결입니다. 모니터링 에이전트의 출력을 분석 에이전트의 입력으로 전달하는 구조를 만들어봅니다.

여기서 데이터 형식을 어떻게 정의할지 고민하게 될 것입니다. 이 고민 자체가 학습입니다.

세 번째 도전은 메모리 시스템 추가입니다. 이미 처리한 트윗을 기억하고, 새로운 트윗만 처리하도록 만들어봅니다.

처음에는 단순한 배열로 시작해도 됩니다. 나중에 더 복잡한 저장소로 교체할 수 있습니다.

김개발 씨가 물었습니다. "막히면 어떻게 하죠?" 박시니어 씨가 대답했습니다.

"막히는 것이 정상이에요. 그때 examples/x-to-book-system 폴더의 코드를 참고하세요.

하지만 복사 붙여넣기는 하지 마세요. 왜 그렇게 작성했는지 이해하면서 자신만의 코드를 작성하세요." 실제로 구현을 시작하면 여러 가지 결정을 내려야 합니다.

에러가 발생하면 어떻게 처리할지, 로그는 어떻게 남길지, 설정은 어떻게 관리할지. 이런 작은 결정들이 모여서 여러분만의 시스템이 됩니다.

김개발 씨는 첫 번째 에이전트를 만들기 시작했습니다. 예상보다 어려웠지만, 한 줄 한 줄 코드가 늘어날 때마다 뿌듯함을 느꼈습니다.

다음 단계로 나아가기 전에 현재 단계가 제대로 동작하는지 확인하세요. 작은 성공들이 모여 큰 시스템이 됩니다.

테스트를 작성하는 것도 좋은 습관입니다. 마지막으로, 완성된 시스템을 다른 사람에게 설명해보세요.

설명하다 보면 자신이 제대로 이해하지 못한 부분이 드러납니다. 그 부분을 다시 공부하면 됩니다.

실전 팁

💡 - MVP(최소 기능 제품)부터 시작해서 점진적으로 기능을 추가하세요

• 막힐 때는 공식 문서와 예제 코드를 참고하되, 그대로 복사하지 말고 이해하며 작성하세요
• 완성 후에는 꼭 다른 사람에게 설명해보세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!