LLM 추론 능력의 진화와 하드웨어 엔지니어의 다음 역할

GPT-3에서 GPT-5.5까지: “텍스트 생성기”에서 “실행 가능한 에이전트”로

2020년에는 few-shot generalization, 2021년에는 자연어→코드 인터페이스, 2022년에는 instruction following과 대화형 인터페이스, 2023년에는 고난도 추론, 2024년에는 실시간 멀티모달, 2025년에는 라우터와 사고 깊이, 2026년에는 computer-use·터미널 코딩·전문 업무 산출물까지 결합된 실행형 에이전트로 진화했습니다.

LLM은 어떻게 동작하는가? — 입력을 토큰화하고 문맥을 계산해 다음 토큰을 생성한다

LLM은 텍스트를 토큰으로 바꾸고, 각 토큰을 벡터로 표현한 뒤, Transformer가 문맥 관계를 계산해 다음 토큰의 확률을 만들고, 이 과정을 반복해 문장을 생성하는 모델입니다. 이 장에서는 학습보다도 입력 → 문맥 계산 → 다음 토큰 생성이라는 실제 동작 순서에 초점을 맞춥니다.

LLM의 최소 동작 그림: 학습과 추론

1) Tokenization

문장을 토큰 단위로 쪼개어 모델이 다룰 수 있는 ID 시퀀스로 바꿉니다.

2) Embedding

각 토큰을 연속 벡터로 바꾸고, 위치 정보까지 더해 초기 표현을 만듭니다.

3) Transformer Blocks

Self-attention과 MLP 층이 문맥을 섞어가며 “지금 무엇이 중요한가”를 계산합니다.

4) Output Head

다음에 올 토큰의 확률 분포를 계산합니다. 즉, 정답 후보들의 점수를 뽑습니다.

5) Autoregressive Loop

선택된 다음 토큰을 다시 입력 뒤에 붙이고, 이 과정을 반복해 문장을 생성합니다.

이미지로 보는 LLM 내부 동작

1) Token Embeddings

토큰 ID를 연속 벡터 공간으로 바꾸는 단계입니다. 모델은 이제 단어가 아니라 숫자 벡터를 처리합니다.

2) Positional Encoding

토큰 순서를 표현에 더해 “앞뒤 위치” 정보를 잃지 않게 합니다. 순서 정보가 있어야 문맥 해석이 가능합니다.

3) Masked Self-Attention

현재 토큰이 앞선 토큰들 가운데 무엇을 얼마나 참고할지 계산합니다. GPT 계열은 미래 토큰을 볼 수 없도록 마스킹합니다.

4) Output Logits → Next Token

마지막 벡터를 vocabulary 점수로 바꾸고, 확률이 높은 후보 중 하나를 다음 토큰으로 선택해 다시 루프에 넣습니다.

도식 출처: Jay Alammar, The Illustrated GPT-2

학습 단계

정답 다음 토큰과 예측 분포의 차이를 loss로 계산하고, backpropagation으로 가중치를 업데이트합니다. 이 단계가 “피팅”에 해당합니다.

추론 단계

서비스 단계에서는 가중치를 더 이상 바꾸지 않습니다. 학습된 가중치를 고정한 채 다음 토큰 확률만 계산하고, 토큰을 하나씩 생성합니다.

Local LLM vs Cloud LLM: 2024→2026 트렌드 변화와 권장 구성

실무 기본값은 여전히 Hybrid입니다. 2024년에는 GPT-4o와 Gemini 1.5 같은 cloud frontier가 시장을 주도했고, 2025년에는 Apple Mac Studio(M4 Max / M3 Ultra)와 NVIDIA DGX Spark·DGX Station 발표로 로컬 AI 컴퓨팅 관심이 크게 늘었습니다. 다만 실제 제품 운영 관점에서는 여전히 cloud·hybrid가 기본값이었고, 2026년에는 메모리 절감 연구와 경량·오픈 모델 성숙으로 local training이 아니라 local inference / fine-tuning / agent execution 쪽의 기회가 더 커지고 있습니다.

API 호출 기반 코딩에서 대화형·에이전트형 코딩으로

코딩의 중심이 “함수를 잘 호출하는 사람”에서 “대화 흐름과 에이전트 협업 구조를 설계하는 사람”으로 이동하고 있습니다. 중요한 변화는 단순 프롬프트가 아니라, 계획·라우팅·도구 사용·반복 검증, 그리고 이 전체를 감싸는 harness 설계가 이미 제품 내부에서 실행되기 시작했다는 점입니다.

RTL을 칩 품질로 묶는 설계/검증 하네스

Hardware RTL에서 harness-engineered pipeline은 “LLM이 Verilog를 써준다”가 아닙니다. spec, microarchitecture, RTL, golden model, testbench, assertion, coverage, regression, sign-off evidence를 하나의 실행 가능한 검증 하네스로 묶어, 설계 변경이 생길 때마다 품질 신호가 자동으로 되돌아오게 만드는 방식입니다.

OpenCode, Antigravity, Codex, Claude Code, Gemini CLI, OpenClaw: 에이전트 툴이 쏟아지는 이유

2025~2026의 차이는 “AI 코딩 툴이 또 하나 늘었다”가 아닙니다. 에이전트 툴이 쏟아지는 가장 큰 이유는 단순한 유행이 아니라 효용성이 이미 너무 크기 때문입니다. 코드베이스 이해, 파일 수정, 실행, 검증, 재시도, 병렬 작업을 하나의 루프로 묶으면 개발자의 병목이 “직접 타이핑”에서 목표 설정, 검토, 승인, 아키텍처 판단으로 이동합니다.

하드웨어 엔지니어로서 어느 정도까지 무엇을 해야 하는가?

지금 시점에서 가장 좋은 전략은 “완전 자율화”를 기다리는 것이 아니라, 반복적이면서 구조화된 검증/디버깅/리포트 루프를 먼저 자동화하고, 사람이 아키텍처·승인·최종 sign-off를 잡는 구조를 만드는 것입니다.

Hardware Coding Future: 사람이 직접 치는 코드보다, 루프를 설계하는 능력이 중요해진다

하드웨어 설계와 검증도 소프트웨어가 먼저 겪은 변화를 따라가게 됩니다. 먼저 템플릿 자동화가 들어오고, 그다음에는 보고서/테스트/버그 요약 자동화가 들어오며, 이후에는 다중 에이전트가 설계-검증-문서화를 연결하는 폐루프 구조가 중심이 됩니다.

실전 적용 사례: OpenCode로 시작해 병렬 실행·감독형 운영으로 확장

이 장은 OpenCode로 출발하여 agentic coding을 적용하고, 이후 harness engineering 관점에서 병렬 실행·감독형 운영으로 확장한 적용 사례를 화면으로 보여주는 파트입니다.

소프트웨어는 이미 가장 빠르게 AI화되는 영역

공개 수치와 업계 리더의 발언을 보면, 소프트웨어는 AI-generated code share가 가장 먼저 크게 올라간 분야입니다. 대기업 내부 측정치는 25~30% 수준까지 올라왔고, 스타트업 일부 cohort에서는 95% 사례가 보고됐으며, 업계 리더는 90%+ 구간을 전망하고 있습니다.

개발 현장의 AI 도구 사용 확산

GitHub 2024 survey, Stack Overflow 2025 Developer Survey 기준.

AI가 작성한 코드 비중에 대한 공개 시그널

Google 공식 측정치, Microsoft CEO 추정치, Y Combinator cohort 사례, Anthropic CEO 전망치 기준.

Alphabet Q3 2024 earnings call · TechCrunch · Nadella 20–30% · GitHub survey 2024 · Stack Overflow Developer Survey 2025 · Y Combinator post · CFR · Dario Amodei

예시 1. 한 세션에서 원인 분석과 수정 방향 정리

초기 단계에서는 OpenCode 단일 세션으로 문제 원인을 분석하고, 어떤 파일을 왜 바꿔야 하는지 설명받는 방식으로 사용했습니다. 이 단계만으로도 사람이 직접 코드를 모두 뒤지지 않고 빠르게 문제 구조를 파악할 수 있었습니다.

예시 2. diff와 오류 메시지를 다시 읽혀 다음 패치를 생성

다음 단계에서는 에러 메시지, 수정 diff, 다음에 읽을 파일 위치를 다시 모델에 넣어 폐루프를 만들었습니다. 즉, “답변”이 아니라 “패치 → 재빌드 → 재질문” 루프를 만들기 시작한 단계입니다.

예시 3. 외부 스크립트·도구까지 확장한 자동화

이후에는 단일 코드 수정에 그치지 않고, 배치 처리와 로그 생성, 진행 옵션 제어, 외부 스크립트까지 포함하는 자동화 파이프라인으로 확장했습니다. 즉 에이전트를 IDE 보조가 아니라 실제 작업 파이프라인의 일부로 붙인 것입니다.

예시 4. 모든 프로세스를 한눈에 모니터링하며 에이전트 상호작용을 감독

이 화면은 여러 에이전트가 각자 코딩, 검증, 아이디어 제시를 수행하고 그 결과를 사용자가 한눈에 모니터링하는 상황을 보여줍니다. 즉 사람은 직접 한 작업을 치는 것이 아니라, 에이전트들이 상호작용하며 내놓는 산출물과 예외를 감독하는 역할로 이동합니다.

예시 5. 다수의 LLM을 병렬 호출하고 진행률·병합·로그를 관리

이 단계에서는 여러 모델과 런을 동시에 호출해 progress, 로그, 병합 결과를 관리합니다. 결국 사람은 전체 실행 팜의 상태를 보면서 실패 작업만 집어 들고, 성공한 작업은 계속 자동으로 흘려 보내는 운영 모델에 가까워집니다.

OpenCode 사용 팁

OpenCode에서는 다섯 가지를 구분해 보면 덜 헷갈립니다. AGENTS.md는 기본 행동 규칙, command는 사용자가 직접 치는 슬래시 명령, skill은 에이전트가 필요할 때만 불러오는 작업 플레이북, MCP는 외부 도구·데이터 연결 표준, /init은 저장소를 스캔해 AGENTS.md를 만들거나 다듬는 내장 명령입니다.

AGENTS.md = 기본 행동 규칙

프로젝트 루트의 AGENTS.md는 그 디렉터리 이하에서 적용되고, ~/.config/opencode/AGENTS.md는 모든 세션에 공통 적용됩니다. OpenCode는 시작 시 현재 디렉터리에서 위로 올라가며 로컬 규칙을 찾고, 그다음 글로벌 규칙, 마지막으로 Claude Code 호환용 CLAUDE.md를 fallback으로 봅니다.

예시처럼 AGENTS.md에는 저장소 범위, 실제 엔트리포인트, 자주 쓰는 명령, 검증 방법, 건드리면 안 되는 파일 같은 프로젝트 기본 운영 규칙을 모아 둡니다. 그래서 새 세션을 열어도 에이전트가 같은 작업 기준을 공유합니다.

빌드·린트·테스트 명령, 중요한 실행 순서, 저장소 구조, 프로젝트 특유의 컨벤션과 운영상의 주의점을 적어 두는 곳입니다.

command = 사용자가 직접 실행하는 매크로

/test, /review 같은 커스텀 슬래시 명령입니다. opencode.json의 command 항목으로 정의하거나, .opencode/commands/ 또는 ~/.config/opencode/commands/ 아래 markdown 파일로 만들 수 있습니다.

TUI에서 /help, /review, /skills처럼 사용자가 직접 선택해 실행하는 계층입니다. 즉 command는 에이전트가 알아서 불러오는 지식 모듈이 아니라, 사람이 반복 작업을 매크로처럼 호출하는 슬래시 명령입니다.

내용은 프롬프트 템플릿이고, $ARGUMENTS, $1, $2 같은 인자 치환, !명령어의 셸 출력 주입, @파일경로의 파일 자동 포함도 지원합니다. 특정 agent·model 지정과 subtask 강제도 가능합니다.

skill = 에이전트가 필요할 때만 여는 작업 플레이북

스킬은 SKILL.md 기반의 재사용 가능한 지침입니다. OpenCode는 먼저 스킬 목록과 설명만 보고, 에이전트가 필요하다고 판단할 때 native skill tool로 본문을 로드합니다. 즉 기본 프롬프트에 항상 다 들어가는 것이 아니라 온디맨드로 불러오는 지식 모듈입니다.

예시처럼 skill은 Firebase, Genkit, Firestore, 배포 같은 작업별 폴더로 나뉘고 각 폴더의 SKILL.md가 전문 플레이북 역할을 합니다. AGENTS.md가 항상 깔리는 기본 규칙이라면, skill은 필요한 순간에만 열어 보는 작업별 매뉴얼입니다.

경로는 .opencode/skills/<name>/SKILL.md 또는 ~/.config/opencode/skills/<name>/SKILL.md를 쓰고, YAML frontmatter의 name과 description이 필수입니다.

MCP = 외부 도구·데이터 연결 표준

MCP는 OpenCode 고유 포맷이 아니라 Model Context Protocol이라는 외부 표준입니다. 공식 문서는 이를 AI용 USB-C 포트에 비유합니다. OpenCode에서는 opencode.json의 mcp 항목에 서버를 등록해 로컬·리모트 MCP를 붙입니다.

핵심은 저장소 안 규칙을 정리하는 것이 아니라 GitHub·Jira·문서 검색기 같은 바깥 시스템과 연결해 실제 도구와 데이터를 가져오게 하는 것입니다. MCP는 컨텍스트 사용량을 크게 늘릴 수 있으므로 많이 붙일수록 무거워질 수 있습니다.

더보기

정확히 말하면 MCP 서버가 LLM과 직접 대화하는 것은 아닙니다. OpenCode, Claude Desktop, Cursor 같은 AI 앱이 MCP Host이자 MCP Client가 되고, 외부 기능을 제공하는 프로그램이 MCP Server가 됩니다. LLM은 Host가 알려준 tool schema를 보고 “어떤 도구를 쓸지” 결정하고, 실제 통신과 실행은 Host와 MCP Server가 JSON-RPC로 처리합니다.

1. 사용자 요청 2. OpenCode 같은 AI Host가 LLM에 tool 목록과 schema 제공 3. LLM이 필요한 tool 호출을 결정 4. Host 내부 MCP Client가 MCP Server에 JSON-RPC 요청 전송 5. MCP Server가 실제 파일/API/DB/명령을 실행 6. 결과를 JSON-RPC 응답으로 반환 7. Host가 결과를 LLM context에 넣고, LLM이 최종 답변 생성

구성	역할	예시
Resource	읽기용 데이터	파일 내용, DB schema, 문서, 설정값
Tool	실행 가능한 함수	검색, 빌드 실행, 테스트 실행, API 호출
Prompt	재사용 프롬프트 템플릿	코드 리뷰 템플릿, SVA 리뷰 템플릿

JSON-RPC로 보면: Host는 먼저 initialize로 protocol version과 capability를 맞추고, tools/list로 tool 목록을 가져오며, 실제 실행은 tools/call 요청으로 합니다.

{
  "jsonrpc": "2.0",
  "id": 11,
  "method": "tools/call",
  "params": {
    "name": "search_signal",
    "arguments": {
      "signal_name": "axi_awvalid"
    }
  }
}

로컬 stdio 방식: OpenCode가 MCP 서버를 subprocess로 실행하고, stdin/stdout으로 JSON-RPC 메시지를 주고받습니다. 그래서 MCP 서버에서 debug용 print()를 stdout에 막 쓰면 통신이 깨질 수 있고, 로그는 stderr로 보내는 것이 안전합니다.

OpenCode
  ├─ subprocess: python rtl_mcp_server.py
  ├─ stdin  → JSON-RPC request
  └─ stdout ← JSON-RPC response

OpenCode 연결 예: local MCP는 opencode.jsonc의 mcp 섹션에서 실행 명령과 환경변수를 지정합니다.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "rtl-helper": {
      "type": "local",
      "command": ["python", "/home/user/mcp_servers/rtl_mcp_server.py"],
      "enabled": true,
      "environment": {
        "PROJECT_ROOT": "/home/user/my_rtl_project"
      }
    }
  }
}

RTL/DV에 붙이면: search_signal, read_rtl_file, find_module, parse_sim_log, extract_assertion_failures, generate_sva_candidate 같은 tool을 만들 수 있습니다. 그러면 자연어 요청 하나가 내부적으로 파일 검색 → RTL 읽기 → 로그 분석 → SVA 후보 생성 같은 tool 호출 체인으로 바뀝니다.

보안 포인트: MCP tool은 실제 파일 읽기, command 실행, API 호출, DB 접근을 할 수 있으므로 위험할 수 있습니다. 임의 shell command를 그대로 받는 tool보다 unit_test, lint, sim_smoke처럼 허용된 작업만 enum으로 제공하는 방식이 안전합니다.

한 줄 요약: MCP는 “AI가 외부 기능을 호출할 수 있도록 함수 목록, 입력 스키마, 실행 결과를 JSON-RPC로 표준화한 client-server 프로토콜”입니다.

참고: MCP server docs · MCP Tools spec · MCP Transports · Python SDK · OpenCode MCP servers

Hardware 검증 관점에서의 MCP 툴 활용에 대한 더보기

MCP를 사용한 Stitch 연결 예제: 화면 흐름

아래 흐름은 “하네스 엔지니어링을 하드웨어 RTL 설계/검증 모델로 시각화해 달라”는 요청을 Stitch에 만들고, OpenCode가 MCP 서버를 통해 그 화면과 산출물을 읽고 개선하는 예시입니다. 발표에서는 1번부터 9번까지 순서대로 보면 MCP가 단순 설정 파일이 아니라 외부 도구를 에이전트 작업 루프에 붙이는 연결 표준이라는 점이 드러납니다.

1

기준 UVM 테스트벤치 이미지 준비

기존 UVM Testbench 구조를 기준 이미지로 준비합니다. 이후 Stitch와 에이전트는 이 이미지를 출발점으로 하네스 엔지니어링 구조를 확장합니다.

2

Stitch에 목표 입력

첨부한 기준 이미지를 하드웨어 개발·검증용 하네스 엔지니어링 모델로 확장해 달라고 Stitch에 요청합니다.

3

Stitch 화면과 MCP 연결 준비

Stitch가 만든 UVM testbench 참조와 아키텍처 다이어그램을 확인하고, 오른쪽 패널에서 OpenCode MCP 연결을 준비합니다.

4

OpenCode에 MCP 서버 등록

opencode.json의 mcp 항목에 Stitch 서버를 등록합니다. 로컬 작업기인 OpenCode가 외부 디자인 도구를 호출할 수 있는 통로가 생깁니다.

5

TUI에서 연결 상태 확인

OpenCode TUI의 MCP 상태 창에서 stitch connected와 Enabled 상태를 확인합니다. 이때부터 에이전트가 Stitch 도구를 쓸 수 있습니다.

6

에이전트가 Stitch 화면을 읽음

에이전트가 stitch_get_screen, stitch_list_screens 같은 MCP 도구로 화면과 산출물을 읽고, HTML 다이어그램으로 옮길 구조를 추출합니다.

7

초기 HTML 산출물 생성

Stitch 화면에서 읽은 구조를 먼저 HTML/SVG 다이어그램으로 옮긴 버전입니다.

초기 HTML 크게 열기

8

HTML 산출물을 다시 개선 요청

초기 HTML 결과와 Stitch 화면을 비교하면서, 발표에 쓸 최종 RTL harness loop 이미지에 더 가깝게 다시 생성하도록 요청합니다.

9

최종 HTML 산출물 확인

자율 하네스 엔지니어링 루프를 RTL 설계/검증 관점으로 정리한 최종 버전입니다.

최종 HTML 크게 열기

여담 1. Claude Code 유출로 사람들이 알게 된 사실과 가능성

이 파트는 보안 사고의 시시비비보다, 유출 이후 커뮤니티가 무엇을 빠르게 읽어냈는가에 집중합니다. 핵심은 weights가 아니라 agent product layer가 공개됐고, 그 결과 구조 분석 · 기능 해석 · 재구현 · 로드맵 추정이 거의 실시간으로 일어났다는 점입니다.

여담 2. Harness Engineering 요약과 출처

Harness engineering은 에이전틱 코딩을 잘 하도록 “파이프라인 하나를 짜는 일”보다 더 넓습니다. 더 정확히는 모델이 실제로 일을 끝내도록 state · prompts · tools · permissions · memory · verification · observability · retry loop · artifact handoff를 설계하는 시스템 설계·운영 practice입니다.

여담 3. 4월 26일 업데이트: 모델 성능 경쟁보다 비용·메모리·운영 리스크가 더 중요해진다

이번 업데이트의 결론은 단순히 “GPT-5.5가 더 좋아졌다”가 아닙니다. 프론티어 모델 성능은 계속 오르고, GLM-5.1 같은 오픈 모델도 빠르게 추격하지만, 동시에 API 비용·구독 한도·DRAM/NAND 공급·로컬 장비 수요가 모두 압박 요인으로 바뀌고 있습니다.

2026년 4월 27일 기준 GitHub Trending Today 페이지에서 보이는 상위 10개 실제 레포를 간단히 정리했습니다. 눈에 띄는 점은 skills, code intelligence, agent memory, Claude/Codex workflow, multi-agent framework처럼 에이전트 실행 환경을 보강하는 레포들이 상단에 많이 올라왔다는 점입니다.