1. Context Layer: 프로젝트의 장기 기억 AI가 매번 프로젝트를 처음 보는 것처럼 행동하지 않게 만드는 '기억' 레이어입니다.

• CLAUDE.md: 프로젝트의 핵심 규칙, 아키텍처, 자주 사용하는 패턴을 미리 기록하여 반복적인 설명 없이도 AI가 프로젝트를 깊이 이해하도록 돕습니다.
• /init 커맨드: 프로젝트 구조를 자동으로 스캔하여, 해당 프로젝트에 최적화된 CLAUDE.md 초안을 생성해 시작 시간을 단축합니다.
• 의미 기반 탐색: 코드의 의도와 흐름을 분석하여 정확한 버그 발생 지점을 찾아냅니다.

2. Composition Layer: 팀 역량의 패키징 우리 팀만의 노하우를 재사용 가능한 도구로 만들어 팀 전체의 역량으로 만드는 단계입니다.

• Custom Slash Command: 반복되는 복잡한 작업을 슬래시 커맨드(/.)로 등록해 필요할 때마다 즉시 호출합니다.
• SKILLS: 특정 상황(예: 특정 라이브러리 사용법)에서 AI가 참조해야 할 전문 지식을 MD 파일로 만들어두면, AI가 필요할 때 스스로 불러와 적용합니다.
• SUBAGENTS: 큰 작업을 전문화된 서브 에이전트들에게 병렬로 위임하여 작업 효율을 극대화합니다.

3. Control Layer: 안전한 실행 통제 AI가 스스로 코드를 수정할 때 생길 수 있는 실수를 방지하는 안전망입니다.

• Plan Mode: 실행 전에 AI가 세운 계획과 수정할 파일 내용을 미리 검토하고 필요시 수정할 수 있게 하여, 원치 않는 파일 수정 등을 방지합니다.
• Hooks: preToolUse(도구 실행 전), postToolUse(도구 실행 후) 훅을 설정해 특정 동작 전에 반드시 승인을 받거나 로그를 남기게 합니다.
• Headless Mode (-p): 상호작용 없이 자동 실행되도록 설정하여, CI/CD 파이프라인이나 스크립트에 통합합니다.

4. Capability Layer: 외부 서비스 연동과 자동화 Claude Code의 능력을 프로젝트 외부까지 확장하여 실제 업무를 자동화하는 단계입니다.

• MCP Server: Jira, GitHub, Slack 등 외부 도구와 인터페이스를 연결하여 이슈 생성, PR 작성, 알림 발송 등을 자동화합니다.
• Git Workflow: 자연어 명령어로 Git 커밋과 PR 생성을 수행하여, 복잡한 명령어 학습 부담을 줄여줍니다.
• TDD 및 리팩토링: AI가 테스트 코드를 작성하고 리팩토링까지 수행하게 하여 개발자가 핵심 로직에만 집중할 수 있게 합니다.

Layer 1. CLAUDE.MD

두가지 범위 글로벌 vs 프로젝트

• Global CLAUDE.md (~/.claude/CLAUDE.md)
  • 범위: 사용자 홈 디렉터리에 위치하며, 해당 PC에서 진행되는 모든 프로젝트에 공통으로 적용됩니다.
  • 주요 용도: 개인 전반의 작업 스타일 및 공통 환경 설정
    • 응답 언어 및 기본 스타일: 예) "한국어로 답변해줘", "코드 설명은 간결하게 작성해줘" 등
    • 선호 도구 및 개인 규칙: 작업 시 개인적으로 자주 사용하는 기본 CLI 명령어나 작업 패턴
• Project CLAUDE.md (.claude/CLAUDE.md)
  • 범위: 특정 프로젝트(저장소) 루트에 위치하며, 해당 저장소 안에서만 적용됩니다.
  • 주요 용도: 해당 프로젝트 전용 규칙 및 팀 단위 공유 지침
    • 아키텍처 규칙: 프로젝트 특화 폴더 구조, 프레임워크 사용 규칙
    • 디렉토리 맵 & 테스트 정책: 파일 위치 가이드, 테스트 실행/작성 규칙 (예: npm test 기준)
    • 팀 단위 협업 공유: Git 커밋 대상에 포함시켜 팀원 모두가 동일한 Claude 지침을 공유

Layer2. SKILLS - on demand 가 핵심이다.
SKILL.MD

SKILLS 는 처음에는 하나만 만들고, 가장 반복적으로 하는 작업

코드리뮤, pr 작성, testcase 케이스 등등 하나를 골라서 해보자.

동작하는걸 확인하고 늘려나가보자.

Layer3. HOOKS -> 다른 계층과 차이는 LLM이 개입하지 않는다.

AI AGENT 의 특정 행동 전후에 자동으로 무언가를 실행한다.

작업명령 완료시 팀채널에 알린다든지 ... 그런것들을 HOOKS 로 구현할 수 있다.

주요 이벤트는 5가지 있다.

SessionStart 세션시작시 환경점검

PreToolUse 도구 실행 전 검증, 차단

PostToolUse 도구 완료 후 포맷, 알림

Stop 응답 완료 후 슬랙 알림

SubagentStop 서브에이전트 완료 감지

Hook 은 위험한 명령어가 오면 차단한다, 반드시 실행한다는 것이다. AI는 의존적이지 않다.

Hook Script가 실행이 안된다면, 실행권한 누락일 가능성이 크다.

Layer4. SUBAGENTS - 전문가에게 맡기는 기술

위임만 한다, 결과만 받는다 - 무한 루프 없이 메인 컨텍스트를 보호합니다.

Explore Agent - 코드베이스 탐색 전담, 읽기 전용 도구만 허용

Test Runner - 테스트 실행 및 분석

Code Reviewer - 보안 담당

핵심 규칙 : 서브에이전트는 서브에이전트를 스폰할 수 없습니다. 무한 재귀 방지가 내장되어 있습니다.

Layer5. PLUGINS - 개인 역량을 팀 인프라로

NPM 패키지 ...

내가 PLUGIN 으로 묶으면

./install plugin 으로 다른사람이 받아서 사용 가능하다.

[플러그인 루트 (my-team-plugin/)]
 ├── .claude-plugin/
 │    └── plugin.json (매니페스트: 이름, 버전, 설명 정의)
 ├── skills/
 │    └── deploy/
 │         └── SKILL.md (스킬 정의)
 ├── agents/
 │    └── reviewer.yml (에이전트 정의)
 ├── hooks/
 │    └── hooks.json (훅 정의)
 └── .mcp.json (MCP 설정)

위 구조를 기반으로 배포 및 설치되는 과정은 다음과 같습니다.

[개발/작성]                  [배포/공유]                     [설치/사용]
 플러그인 구조 구성   ───>   GitHub Push 후      ───>   /plugin install team-devkit@my-org
 (skills, agents 등)        한 줄 공유                     (팀원들이 한 번에 적용)

핵심 개념 정리

• 패키징: 스킬(SKILL.md), 에이전트(reviewer.yml), 훅(hooks.json), MCP 설정(.mcp.json)을 하나의 플러그인 폴더(my-team-plugin)로 묶고 .claude-plugin/plugin.json 메니페스트 파일에 메타정보를 기록합니다.
• 배포 및 설치: npm 패키지처럼 GitHub에 푸시한 뒤 명령어 한 줄(/plugin install team-devkit@my-org)로 팀 전체가 공유하여 설치할 수 있습니다.

사내 전용이면 비공개 git host 를 강력하게 추천한다.

전략적 prompt를 팀내부에서만 할수 있다.

그래서 위에 단계를 그냥 한눈에 도식화한 구조로 보여주면 ....

.claude/
 ├── CLAUDE.md                   # [Layer 1] 프로젝트 규칙 및 최상위 가이드라인
 ├── skills/                     # [Layer 2] 온디맨드 지식
 │    └── feature-name/
 │         ├── SKILL.md          # 스킬 정의 및 핵심 지침
 │         ├── scripts/          # 실행 스크립트
 │         └── references/       # 참고 문서
 ├── agents/                     # [Layer 4] 서브에이전트
 │    └── agent-name.yml         # 독립적인 작업 에이전트 설정
 ├── plugins/                    # [Layer 5] 설치된 플러그인 모음
 ├── hooks.json                  # [Layer 3] 가드레일 (특정 이벤트 시 자동 실행)
 ├── .mcp.json                   # MCP 서버 연결 (Slack, Jira, GitHub 등 외부 서비스 연동)
 ├── settings.json               # 프로젝트 공통 설정 및 권한 제어 (도구 허용/차단, 환경변수)
 └── settings.local.json         # 개인별 설정 (.gitignore 대상)

주요 요소 정리

• commands/: .claude/commands/deploy.md와 같이 작성 시 /deploy 형태의 슬래시 명령어로 자동 등록됩니다.
• .mcp.json: 표준 프로토콜을 이용해 Slack, Jira, GitHub 등 외부 도구를 Claude 환경에 연결합니다.
• settings.json: 허용/차단 도구 목록, 플러그인 목록, 환경 변수 등 세밀한 실행 권한을 관리합니다.

Claude Code 5계층 아키텍쳐가 있다.

아래부터 위로 쌓여가는 구조이다.

우리는 그냥 코드를 짜는 도구로만 Claude Code 를 사용하고 있다.

개발자들은 1단계만 사용하고 있다.

• Layer 1: CLAUDE.md (Memory)
  • 역할: 프로젝트 전반에 항상 로드되는 에이전트의 규칙이자 헌법입니다.
  • 특징: 프로젝트 컨텍스트, 코드 스타일, 기본 지침 등 AI가 작업을 수행할 때 항상 준수해야 할 핵심 지침을 담고 있습니다.
• Layer 2: SKILLS (Knowledge)
  • 역할: 특정 작업 상황에서 필요에 따라 호출되는 모듈형 전문 지식 및 스킬입니다.
  • 특징: 모든 작업에 상시 로드되지 않고, 특정 태스크나 도구 사용 시에만 맞춤형 지침을 제공하여 효율성을 높입니다.
• Layer 3: HOOKS (Guardrails)
  • 역할: LLM의 개입 없이 동작하는 결정론적 통제 제어 장치입니다. -> 이과정에서 AI 가 개입하지 않는다.
  • 특징: 명령 실행 전후의 검증, 권한 관리, 보안 정책 적용 등 AI의 오작동이나 유해한 동작을 원천 차단하는 가드레일 역할을 합니다.
• Layer 4: SUBAGENTS (Delegation)
  • 역할: 전문 작업을 위임하는 독립 에이전트 계층입니다.
  • 특징: 메인 에이전트의 부담을 줄이기 위해 특정 하위 작업(예: 테스트 실행, 리팩토링, 코드 분석 등)을 전담하는 별도의 세부 에이전트에게 역할을 분담하고 제어합니다.
• Layer 5: PLUGINS (Distribution)
  • 역할: 팀 전체에 배포 및 공유하는 패키지/인프라 계층입니다.
  • 특징: 정의한 스킬, 훅, 서브에이전트 등의 환경 설정을 하나로 묶어 팀원 전체가 동일한 개발 환경과 제어 체계를 활용할 수 있도록 공유하고 배포합니다.

문제점1

"매번 같은 컨텍스트를 다시 입력한다."

-> CLUADE.md 글로벌 세팅으로 세션 시작부터 규칙이 자동 적용된다.

문제점2 

"프로젝트가 커지면 AI가 맥락을 잃는다"

-> skills + subagents로 메인 컨텍스트 창을 꺠끗이 유지된다.

문제점3

"AI가 위험한 명령을 실행할까 불안해요"

-> Hooks 레이어가 LLM 개입 없이 100% 결정론적으로 차단한다.

문제점4

"나만 잘쓰고, 팀전파가 너무 어려워요"

-> Plugins 로 역량을 패키징해 팀원이 원클릭으로 설치합니다.

아래 사항을 집중적으로 본다.

보유기간 3~5년으로 가정.

1. 투자 목적 : 일단 나는 앞으로 전력망과 데이터센터 관련 주식이 더 오를것이라고 예상한다. 앞으로 MYRG는 몇년간 매출이랑 주당이익을 키울것이라고 생각함. -> 자 그래서 지속 가능한가? 가능하다고 본다.

2. 사업 이해 - MYRG는 뭐로 돈을 벌까 ? : 전기 인프라를 시공, 유지보수하는 회사다.

T&D : 송배전<송전선 등>, C&I: 상업, 산업<데센 등>

일단 매출은 각 분야 50%정도로 거의 균일하다.

3. 산업, 경쟁력 : 시장이 커질때 MYRG가 수혜를 받는가?

받는다 . 경쟁력도 인정, 하지만 높은 이익률로 오랫동안 보장받는 기업으로 평가하지는 않는다. 시공 능력과 원가 관리가 계속 검증되어야 한다.

4. 재무 상태 - 실적 최근 어떤가?

최근 분기는 확실히 좋아졌다.

여기서 실적만 봤을땐, 좋다. 굉장히 좋다. 진심 좋다... 하지만,

부채와 현금흐름을 봐야한다.

상반기 영업현금흐름은 1억 1천만 -> 8.8만로 줄었다. <단기적인지는 두고봐야 한다.>

5. 미래실적 - 성장 더 할것인가?

수주잔고 O, 이미 확보 했지만, 아직 매출로 인식하지 않은 공사 물량이다.

경영진에 의하면, 일부 대형 송전 프로젝트는 2027년 하반기부터 미출 기여가 본격화될 예정이다. 수주가 늘었다고, 바로 다음 분기 매출이 되는것은 아니라는 것을 의미.

6. 현재 가격이 싼가? 288$가 싼가?

이정도면 향후 성장을 어느정도 기대하는 가격이라고 생각한다.

자 그러면, EPS, PER을 봐야 한다.

보수적으로 계산해도 싸다는 확신이 들지는 않는 것 같다...

7. 위험, 반대 근거 - 내판단이 틀렸다는 증거?

일단.. 전력 수요 전망은 맞아도, 주주에게 돌아오는 이익이 기대에 못 미칠 수 있다는 것이다.

8. 매매 계획

현재 288달러 부근에서는 우선 관찰하는게 맞지 않을까 ? 

내 기준가와 비슷한 만큼 서둘러 크게 살 이유는 부족하다.

결론 : RSI는 현재 30근처로, 과매도로 생각듬. 장기로는 모르겠지만, 단기 반등은 노려볼 수 있는 자리 인것같다.

일단 결제 AI Agent project 를 진행하기 전에 AI 에 대해서 뭔지 정확하게 짚고 넘어가야 할 것 같다.

AI ? AI Agent? -> 일단 쉽게 예시로 설명하자면,

1. 제미나이 같은 AI는 어떤 역할을 할까?

제미나이의 AI 모델은 질문을 이해하고, 주어진 정보를 바탕으로 판단하고, 답변을 만드는 역할을 하고, 이런 언어 모델을 LLM 이라고 부른다.

예를 들어 이렇게 물어본다.

나: “주식에서 RSI가 뭐야?”
AI: “최근 주가의 상승과 하락 강도를 비교하는 지표야.”

이건 모델이 배운 지식으로 설명할 수 있다. 그런데 다음 질문은 다르다..

나: “애플의 지금 주가와 최신 실적을 확인해서 분석해 줘.”

제미나이가 실시간으로 주가를 보고있는건 아니고 -> 최신 정보를 얻으려면 외부 데이터를 조회할 기능이 필요하다.

즉, 우리가 쓰는 제미나이, Chat GPT 같은 앱은 AI 모델에 검색 등의 기능을 붙인 서비스 라고 이해하면된다.

2. 그렇다면 AI에 '도구'를 붙인다는건 뭘까? (Tool Calling)

개발자가 AI를 위해 이런 기능을 준비한다고 생각해보자.

여기서 도구는 실제로 실행할 수 있는 프로그램의 기능이다. 외부 서비스에 데이터를 요청할 때 쓰는 접점을 API라고 하고,

예를 들어 주가를 조회하는 과정은 다음과 같다.

1. 너: “애플 현재 주가 알려줘.”
2. AI: 사용할 수 있는 도구 설명을 보고 주가 조회 도구를 선택해.
3. AI: 프로그램에 **“get_stock_price를 종목 코드 AAPL로 실행해 줘”**라고 요청해.
4. 프로그램: 실제 주가 서비스에 요청하고 결과를 받아.
5. AI: 받은 결과를 읽고 너에게 답해.

이처럼 모델이 사용할 도구와 입력값을 지정하는 것을 Tool Calling, 도구 호출이라고 한다.

중요한 건 AI가 실행을 요청하고, 실제 실행은 프로그램이 한다는 점. 모델이 인터넷의 아무 기능이나 저절로 사용할 수 있는 건 아니고, 연결해 둔 도구와 권한이 있어야함. < MCP 도구 공식 문서 >

3. 그럼 AI Agent는 뭐가 달라?

AI Agent는 목표를 달성하기 위해 AI가 다음 행동을 선택하고, 도구를 사용하고, 결과를 확인하면서 작업을 이어 가는 시스템

이렇게 부탁했다고 가정하면,

“애플의 최근 실적과 주가 하락 이유를 확인해서 분석해 줘.”

에이전트는 이런 식으로 진행한다.

1. “최근 실적부터 필요하겠네.” → 재무제표 조회
2. “매출은 늘었는데 주가는 떨어졌네.” → 관련 뉴스 검색
3. “실적 전망이 문제라는 기사가 있네.” → 회사 발표 자료 확인
4. “이제 설명할 근거가 모였네.” → 분석 결과 작성

-> 가장 큰 핵심은, 중간 결과에 따라 다음에 할 일을 선택한다는게 핵심, 사람이 매번 뉴스 찾아, 공시 찾아 라고 안해도 된다는 것!

반면 개발자가 “주가 조회 → 뉴스 조회 → 요약” 순서를 고정해 놓으면 보통 AI 워크플로라고 구분한다. 실제 서비스에서는 고정된 절차와 에이전트의 판단을 함께 쓰기도 해. <Anthropic의 에이전트 설명>

즉, 내가 만들게 되는것도 AI 모델을 직접 훈련 X, 기존 모델을 이용해서 이런 작업을 수행하는 프로그램을 만드는 것에 가깝다.

4. MCP는 여기서 왜 나오는 걸까?

MCP는 AI 앱이 외부 도구와 데이터를 연결해서 사용하도록 정해 둔 공통 통신 규칙이다.

A 증권사가 이렇게 기능을 제공하고 있다.

A증권사 : "우리가 가지고있는 도구(Tool)는 재무제표 조회 도구 사용", "주가 조회 등등이 있어"

A증권사 : "각 도구의 설명과 필요한 입력값도 알려줄수 있어"

이제 우리는 그걸 골라서 필요한 도구를 호출할 수 있다.

그러니까, Tool Calling은 "이 기능을 실행해 줘"라는 행동이고, MCP는 그 기능을 발견하고 호출할 때 사용하는 공통 규칙이다.

그리고 AI Agent를 만들때 MCP는 필수가 아니며, 직접 주가 API를 연결해도 된다. MCP는 여러 도구 제공자를 공통 방식으로 연결하고 싶을때 도움이 되는 것이다.

추가적으로 설명하면, AI가 주가 조회 도구(ex)를 사용하도록 만드는 방법은 총 2가지다.

1. '직접 연결하는 방법' -> API

  1) 제미나이가 get_stock_price("AAPL") 실행을 요청해. 

  2) 네 프로그램이 네가 만든 함수를 실행해.

  3) 함수가 A 업체의 API를 호출해서 주가를 받아.

  4) 결과를 받은 제미나이가 답변해.

2. 'MCP를 통해 연결하는 방법'

  1). 제미나이가 get_stock_price("AAPL") 실행을 요청해.

  2). 네 프로그램의 MCP 클라이언트가 서버에 도구 실행을 요청해.

  3) MCP 서버가 주가를 조회해서 결과를 돌려줘.

  4) 결과를 받은 제미나이가 답변해.

-> 그 회사가 MCP 서버를 제공한다면, 내 프로그램에서 연결해서 사용하기만 하면된다.(MCP 클라이언트를 사용해서)

Q.그러면 여기서 MCP는 우리 서버 혹은 pod에 올릴필요가 없는지?

A. 외부 업체가 운영하는 원격 MCP 서버를 이용한다면, 우리 서버에 MCP 서버를 따로 올릴 필요는 없다.

     다만 어디서 실행하는 MCP 서버인지에 따라 다르다.

예를 들어 주식 데이터 업체가 원격 MCP 서버를 제공하면:

우리 서버의 AI Agent 프로그램이
업체의 MCP 서버에 “애플 주가 조회해 줘”라고 요청하고 결과를 받는 것

이때 우리 프로그램에는 MCP 서버와 통신하는 ‘MCP 클라이언트’ 기능만 들어가면 된다. 보통 라이브러리를 사용해서 구현하고, 별도 서버로 띄울 필요는 없다.

다시 본론으로 돌아와서..

그러면 여러 도구 제공자를 연결할때 왜 편해질까? 에 대한 답변도 나온다.

다만 모든 차이를 없애 주는 건 아님.

서버마다 도구 이름과 입력값은 다를 수 있고, 인증·이용료·사용 권한도 별도로 처리해야한다.

비유하면 MCP는 여러 기기를 연결하는 공통 규격 같은 것.

연결 규격은 같아도 프린터와 카메라의 기능과 사용법은 다르듯, 각 도구의 설명은 여전히 확인해야 한다.

자. 이제 이 흐름을 그림으로 정리한다면 ....

AI에게 "애플 주가 알려줘"라고 요청했을 때의 흐름을 도식화 해서 나타내면..

1. GDP = "우리나라 안에서 얼마나 생산했나?"

**GDP(국내총생산)**는 일정 기간 동안 한 나라의 영토 안에서 생산된 최종 재화·서비스의 가치예요.

예를 들어 한국에서

• 삼성전자가 휴대폰을 생산하고
• 현대차가 자동차를 생산하고
• 식당이 음식을 팔고
• 미용실이 서비스를 제공했다면

이런 국내에서 발생한 생산활동을 합친 것이 GDP예요.

여기서 중요한 건 누가 생산했느냐가 아니라 어디에서 생산했느냐예요.

🇰🇷 한국에서 미국 기업이 생산 → 한국 GDP에 포함
🇺🇸 미국에서 한국 기업이 생산 → 한국 GDP에는 포함 X

2. 명목GDP vs 실질GDP

여기가 가장 중요해요.

🍎 아주 간단한 예

작년에 사과를 10개, 개당 1,000원에 생산했다고 해볼게요.

→ 작년 GDP = 10,000원

올해는 사과를 똑같이 10개 생산했는데 가격이 2,000원이 됐어요.

→ 올해 GDP = 20,000원

그런데 실제로 생산량은 10개 → 10개, 하나도 증가하지 않았죠.

그럼 경제가 진짜 2배 성장한 걸까요?

아니죠. 가격만 오른 거예요.

그래서 GDP를 두 가지로 나눠서 봅니다.

명목GDP

현재 가격 × 현재 생산량

즉, 가격이 올라가도 GDP가 커져요.

위 예에서는

• 작년: 1,000원 × 10개 = 10,000원
• 올해: 2,000원 × 10개 = 20,000원

→ 명목GDP는 2배가 됐어요.

하지만 이건 물가 상승 때문일 수도 있어요.

실질GDP

기준연도의 가격 × 현재 생산량

가격을 고정시켜서 실제로 생산량이 얼마나 늘었는지 보는 거예요.

위 예에서는 생산량이 똑같이 10개니까

→ 실질GDP는 그대로입니다.

⭐ 한 줄로 정리

그래서 뉴스에서

"한국 경제성장률 2%"

라고 하면 일반적으로 실질GDP 성장률을 말한다고 생각하면 됩니다.

3. 그럼 GDP 디플레이터는?

명목GDP와 실질GDP를 비교하면 경제 전체의 물가 수준이 어떻게 변했는지도 알 수 있어요.

이를 GDP 디플레이터라고 합니다.

쉽게 말하면:

GDP 디플레이터 = 명목GDP ÷ 실질GDP × 100

예를 들어

• 명목GDP = 110
• 실질GDP = 100

이라면

→ GDP 디플레이터 = 110

즉, 기준연도보다 전반적인 가격 수준이 높아졌다는 뜻이에요.

**소비자물가지수(CPI)**와 비슷하게 물가를 보여주지만, GDP 디플레이터는 국내에서 생산된 재화·서비스 전체를 대상으로 한다는 차이가 있어요.

4. GNI = "우리나라 국민이 얼마나 벌었나?"

이제 **GNI(국민총소득)**가 나옵니다.

GDP가 **"어디에서 생산했느냐"**를 중요하게 본다면,

GNI는 **"누가 소득을 벌었느냐"**를 중요하게 봐요.

예를 들어:

🇰🇷 한국 기업이 미국에서 돈을 벌었다

한국 기업이 미국 공장에서 100억 원의 소득을 벌었다면

→ 미국 GDP에는 포함
→ 한국 GNI에는 포함

🇺🇸 미국 기업이 한국에서 돈을 벌었다

미국 기업이 한국 공장에서 100억 원의 소득을 벌었다면

→ 한국 GDP에는 포함
→ 미국 GNI에는 포함

그래서 대략적으로

GNI = GDP + 해외에서 우리 국민이 받은 소득 − 외국인이 국내에서 받은 소득

이라고 생각하면 됩니다.

5. GDP와 GNI 차이를 그림처럼 생각하면

GDP

"한국 땅에서 얼마를 생산했어?"

🇰🇷
↳ 한국 기업 ✅
↳ 미국 기업 ✅
↳ 일본 기업 ✅

국적 상관없이 한국에서 생산하면 GDP

GNI

"한국 사람/기업이 얼마를 벌었어?"

🇰🇷 사람·기업
↳ 한국에서 번 돈 ✅
↳ 미국에서 번 돈 ✅
↳ 베트남에서 번 돈 ✅

장소보다는 소득의 귀속이 중요

6. 1인당 GDP / 1인당 GNI

여기서 또 자주 나오는 게 1인당 GDP와 1인당 GNI예요.

1인당 GDP

GDP ÷ 인구

"우리나라에서 생산된 경제적 가치가 국민 1명당 얼마 정도인가?"

1인당 GNI

GNI ÷ 인구

"우리 국민이 벌어들인 소득이 1인당 얼마 정도인가?"

따라서 국민의 평균적인 소득 수준을 보려면 1인당 GNI가 더 직접적인 지표가 될 수 있어요.

다만 이것도 어디까지나 평균값이라서 국민 개개인의 실제 생활수준과 완전히 같은 것은 아닙니다.

7. GDP 관련 용어를 한 번에 정리하면

시험이나 경제뉴스에서 헷갈리면 이렇게 생각하세요.

GDP
→ 🇰🇷 국내에서 생산한 것

명목GDP
→ 💰 현재 가격으로 계산한 GDP

실질GDP
→ 📦 가격 영향을 제거하고 실제 생산량 중심으로 본 GDP

GDP 성장률
→ 📈 실질GDP가 얼마나 증가했는지

GNI
→ 👨‍👩‍👧‍👦 우리 국민이 벌어들인 소득

1인당 GDP
→ GDP를 인구로 나눈 것

1인당 GNI
→ GNI를 인구로 나눈 것

GDP 디플레이터
→ 📊 GDP에 포함되는 전반적인 가격 수준을 보여주는 지표

🧠 진짜 쉽게 암기하는 법

딱 이것만 기억해도 상당 부분 해결됩니다.

GDP = 어디서?
GNI = 누가?

명목 = 가격 포함
실질 = 가격 제거

그리고 경제성장률을 볼 때는:

"실질GDP가 얼마나 늘었지?" → 실제 경제성장

결제AGENT 무슨일을 하는지(대표 프로토콜 x402 등등), 
그리고 필요한 기술들이 뭔지.. 
그리고 우리가 나아가야할 방향은 어떤건지(난이도 조절)

챗 GPT 는 2022년 11월 말에 출시 -> 약 3개월만에 1억사용자 확보.
틱톡 1억 -> 9개월, 인스타그램 1억 -> 2년 반

--> 챗 GPT 의 구독 상승 추세는 무섭다.

기본적인 스택오버플로, 블로그 X -> LLM에게 문제 영역에 대해 개인화된 듀토리얼 작성 요청 후 그 주제에 대해 질문 답변을 이어나가면 된다.(프로그래밍에서는 LLM 기반 어시스턴트와 협력해 스캐폴딩을 구축하면 손쉽게 가능하다.)

스캐폴딩 : 새 프로젝트, 모듈을 시작할때 초기 구조 설정을 자동으로 생성하는 과정

1.1 LLM 은 마법이다.

이 책의 필자는 모두 깃허브 코파일럿, 코드 자동 완성 제품의 초기 연구 개발자다.

LLM 아이디어를 들을때만해도 5년을 걸릴것이다 라고 생각..

한 모델은 다음 단어를 예측할 뿐 아니라, 독스트링만 가지고 전체 문장과 전체 함수를 생성할 수 있었다.

또한 그 함수가 제대로 작동했다는 것이다. LLM은 단순히 다음 단어를 예측 하는 수준을 넘어서 

문장 -> 함수 -> 실제 동작하는 코드 까지 만들어 냈다.

-> 그래서 이 모델의 성능을 측정하고 싶었다., 또한 새로운 시대를 여는 엔진이 될 것을 예감했음. 점점 생각이 바뀌었다.

그래서 GitHub 엔지니어들이 수행하던 코딩작업을 LLM에게 시켜봤는데

-> 한번에 해결하지 못한느 문제도 몇번 다시 시도할 기회를 주면 대부분 해결했다.

--> 이것이 시사하는 바는, LLM 자체가 완벽한 프로그래머일 필요는 없고, LLM이 코딩을 잘할수 있도록 주변 환경을 제대로 만들어주면된다. 

2023년 초 점검하게 된다.

LLM에게 숫자를 영어 문장으로 변환하는 함수처럼 예외가 많은 까다로운 코딩 문제를 직접 제시하면서 LLM의 능력을 확인하게 된다.

-> LLM 은 코드를 한번에 완벽하게 만드는것이 아님, 복잡한 문제도 반복적인 시도를 통해 해결할 수 있다는 것이다.

이것이 LLM을 활용한 프롬프트 프로그래밍의 개발 방식의 출발점이다.

1.2 언어 모델 : 어쩌다 우리가 여기까지 왔지?
테크 역사상 우리가 이 매우 흥미로운 지점에 도달 했는지 이해하려면 언어 모델이 무엇인지 알아야한다.

언어 모델이란 ? 문장의 다음 단어를 예측하는 것. (GPT 답변)

-> 아이폰에 텍스트 입력시 키패드 위에 자동완성도 그 예가 될 수 있다.

1.2.1 초기 언어 모델

사실 언어 모델은 예전에도 있었는데, 1948년 최초로 소개된 자연어 처리용 마르코프 모델에 기반한다.

2014년 까지 가장 강력한 언어 모델은 구글에서 소개한 se12seq(sequence-to-sequence)이다.
-> 하지만 이는 정보 병목으로 아키텍처의 역량이 제한된다는 것이다.

1.인코더는 텍스트를 받으면서 처리가 시작된다.

2.텍스트를 받으면 인코더는 입력 시퀀스의 정보를 축적하는 숨겨진 상태벡터를 업데이트한다.(특별한 '시작' 토큰이 최초로 디코더에 전송이된다.)

3.처리가 다 마지막까지 되면, 숨겨진 상태의 최종값(사고벡터라고 한다.)이 디코더로 전송된다.)

4.디코더는 사고 벡터의 정보를 사용해 출력 토큰을 생성한다. 

5. 이 프로세스를 반복적으로 루프를 돌린다.

6. 마지막으로 디코더는 특별한 '종료' 토큰을 전송해서 디코딩 프로세스가 완료됐음을 나타낸다.

그 후 Attention 메커니즘이 주목을 받았다. -> 디코더가 모든 벡터에 대해 소프트 검색을 수행하도록 한것. -> 성능 향상, 번역 품질 향상

그 후 트랜스포터 아키텍처의 개념이 나온다. (Attention을 핵심 부품으로 사용해서 문장을 처리하는 신경망 구조)

-> 이는 GPT 모델의 직접적인 전신이기 때문에 중요하다.

RNN vs Transformer

기존 RNN은:

나는 → 밥을 → 먹었다
 ↓       ↓       ↓
1단계 → 2단계 → 3단계

앞의 결과를 받아야 다음 단계로 갈 수 있어서 순차적으로 처리했어.

반면 Transformer의 Self-Attention은:

나는   밥을   먹었다
 ↓      ↓      ↓
 └──── 서로의 관계를 동시에 계산 ────┘

처럼 각 토큰이 서로를 한꺼번에 참고하면서 계산할 수 있어.

그래서 학습할 때는 특히 병렬 처리가 가능해서 훨씬 효율적이야.

1.2.2 GPT의 등장

2018논문에 GPT 아키텍처가 소개됨 -> 사실 이 아키텍처는 인코더를 뜯어내고 디코더만 남긴 프랜스포머에 불과하다.

GPT-1 -> GPT-2 : "크게 만들었더니 새로운 능력이 생겼다."

초기 GPT는 대량의 텍스트로 사전학습(Pre-training)한 뒤, 특정 작업에 맞게 파인튜닝(Fine-tuning)해서 사용하는 방식이었어.

그런데 GPT-2에서 모델과 학습 데이터의 크기를 크게 늘리자 놀라운 현상이 나타남.

특정 작업을 위해 별도로 파인튜닝하지 않아도 요약, 번역, 질의응답 등의 작업을 꽤 잘하기 시작한 것.

즉, 단순히 다음 단어를 예측하도록 학습시켰는데 다양한 언어 작업 능력이 나타났다.

... 근데 GPT2에서 문제가 생겼다.

→ 자연스러운 텍스트 생성 능력이 강해지면서 허위정보·사칭·스팸 같은 악성 활용도 쉬워짐.

GPT-3에서는 규모가 또 크게 증가했어.

파라미터가 증가했고, 성능도 증가한다. 학습비용도 증가한다.

2022년 ChatGPT가 등장하고 이후 GPT-4가 나오면서 LLM 성능이 다시 크게 올라갔어.

동시에 LLaMA, Claude, Gemini 등 다양한 LLM이 등장했고,

더 작고 빠른 모델에서도 과거 대형 모델과 비슷한 수준의 성능을 내는 방향으로 발전하고 있어.

즉 LLM 발전은 단순히

"모델을 무조건 크게 만들자"

에서 끝나는 게 아니라,

더 싸고, 더 빠르고, 더 효율적으로 높은 성능을 내자

로 발전하고 있다는 거야.

GPT-3 이후

모델은 그대로 두고 입력(프롬프트)을 잘 만들어 원하는 행동을 끌어낸다.

1.3 프롬프트 엔지니어링

LLM에게 주는 입력 텍스트 = 프롬프트

프롬프트 엔지니어링 = 문제를 해결하는 데 필요한 정보를 프롬프트에 적절하게 넣는 것

-> 하지만 이 책에서는 , 이것 뿐 아니라 LLM을 이용해서 실제 애플리케이션 전체를 설계하는 방법까지 포함한다.

대화형 AI에서는 '상태(State)'관리도 필요하다.

예를 들어

나: 삼성전자 분석해줘

AI: ...

나: 그럼 경쟁사는?

두 번째 질문에서 "그럼 경쟁사는?"만 LLM에게 보내면 삼성전자 이야기라는 걸 모를 수 있어.

그래서 애플리케이션이 이전 대화를 같이 전달해.

[이전 대화]
삼성전자 분석...

[현재 질문]
그럼 경쟁사는?

하지만 대화가 계속 길어지면 문제가 생겨.

Context가 너무 길어짐 → 비용 증가 + 불필요한 정보 증가

그래서 오래되거나 중요하지 않은 내용은 제거하고, 필요한 내용은 요약해서 압축하는 등의 Context 관리가 필요해.

여기서부터 지금의 AI Agent와 연결돼.

LLM이 모든 정보를 알고 있을 필요가 없어.

필요하면 외부 시스템을 사용하게 만들면 돼.

예를 들어 사용자가

"다이앤에게 5월 5일 미팅 초대장 보내줘."

라고 한다면 LLM이

연락처 검색
↓
다이앤 이메일 확인

Calendar API
↓
일정 확인

Email API
↓
초대장 발송

처럼 외부 도구를 이용할 수 있어.

즉,

LLM + API + 외부 데이터 + 프로그램 로직

이 결합되면서 단순한 챗봇을 넘어 실제로 행동하는 AI 애플리케이션이 되는 거야.

즉 사람이 모든 과정을 하나하나 지시하지 않아도 목표를 주면 AI가 어느 정도 스스로 판단해서 작업을 수행하는 것이 Agent의 핵심이다. -> 목표가 구체적이지 않으면 실패 가능성도 높다.