2주차 — 바이브 코딩 에이전트: 세션·컨텍스트와 산업용 온프레미스 설계

바이브 코딩을 '쓰는 사람'이 아니라 '만드는 사람(공급자)'의 눈으로 해부한다. 세션의 정체는 KV 캐시 식별 아이디이고, 컨텍스트는 토큰의 합이며, 컴팩트는 스냅샷 경계다 — 이 세 문장이 강의 전체를 관통한다. 후반부는 금융·증권·제조 온프레미스 현장이 실제로 요구하는 것들을 설계 요구사항으로 바꾸고, 비즈니스 서버부터 만드는 개발 계획으로 닫는다.

0. 사전 필수 용어 (선행지식)

본 강의는 "여러분은 사용자였지 공급자가 아니었다"는 전제에서 출발한다. 아래 용어를 모르면 세션·컨텍스트 논의가 흐릿해진다. 각 용어는 입문자 기준으로 정의하고 비유를 붙였다.

1. KV 캐시 (Key-Value Cache) LLM이 이미 처리한 토큰들의 키(Key)·값(Value) 벡터를 저장해 두는 메모리. 다음 토큰을 만들 때 앞부분을 다시 계산하지 않게 해 준다. 비유: 긴 회의록을 매번 처음부터 다시 읽지 않도록 '읽은 데까지 책갈피와 요점 메모'를 붙여 두는 것. 본문 3장·6장에서 "세션의 정체 = KV 캐시 아이디"로 계속 쓰인다.

2. 프리픽스 캐시 (Prefix Cache) 대화의 앞부분(prefix)은 변하지 않는다는 성질을 이용해, 그 앞부분에 대한 KV 계산 결과를 재활용하는 것. 비유: 매번 같은 인트로가 붙는 영상이라면 인트로 렌더링을 한 번만 해 두고 재사용하는 것. 본문 3장의 캐시 영속화·이벤트 소싱과 직접 연결된다.

3. 이벤트 소싱 (Event Sourcing) 현재 상태를 직접 저장하는 대신, 상태를 바꾼 사건(이벤트)들을 순서대로 append해 두고 그것들을 재생해 현재를 만드는 방식. 비유: 은행 잔고를 숫자로 저장하지 않고 '입금·출금 내역'만 쌓아 두고 더해서 잔고를 구하는 것. 본문 3·6·8장의 아키텍처 논의의 뼈대다.

4. 온프레미스 (On-Premise) 서비스를 외부 클라우드가 아니라 기업 내부 서버·PC에 직접 설치해 운영하는 방식. 비유: 배달 앱을 쓰는 대신 회사 구내식당을 직접 차리는 것 — 자유롭지만 모든 살림을 내가 떠안는다. 본문 2·5·6장 산업용 요구사항의 전제다.

5. RAG (Retrieval-Augmented Generation, 검색 증강 생성) 모델이 답하기 전에 외부 지식베이스에서 관련 문서를 검색해 근거로 넣어 주는 방식. 비유: 시험을 오픈북으로 보되, 필요한 페이지를 먼저 찾아 책상에 펼쳐 주는 조교가 있는 것. 본문 5장의 사내 문서·코드·벡터 DB 웹검색이 전부 RAG다.

6. 모노레포 / 터보레포 (Monorepo / Turborepo) 여러 개의 독립 앱과 공유 라이브러리를 하나의 저장소에서 함께 관리·빌드하는 방식과 그 빌드 도구. 비유: 여러 부서를 각자 건물에 흩는 대신 한 캠퍼스에 모아 공용 시설을 공유하는 것. 본문 4·6장 기술 스택의 골격이다.

📚 참고: 토큰(모델이 텍스트를 쪼개 세는 단위)과 컨텍스트 윈도우(한 번에 넣을 수 있는 토큰 한도, 예: 200K·262K)는 4·6장 컴팩트 계산에서 반복해 등장한다. "컨텍스트 80%가 찼다"는 말은 보낸 메시지의 토큰 수가 한도의 80%라는 뜻이지 실제 RAM을 말하는 게 아니다.

1. 주제 정의 — '공급자'로서의 바이브 코딩 에이전트

이 강의의 정체성은 첫머리에서 못 박힌다. 여러분은 지금까지 바이브 코딩의 사용자였지 공급자가 아니었다. 그래서 코덱스·클로드 코드를 열심히 써 봤어도 그 시스템이 내부적으로 무엇인지는 잘 모른다. 시중의 에이전트 책을 보고 "도구 사용 좀 붙이면 바이브 코딩이 되겠지"라고 생각하지만, 강사는 단호하다. "안 된다. 안 돼."

바이브 코딩 에이전트란 AI가 복잡한 개발 작업을 스스로 이해·수행하며 코드를 생성·수정·최적화하는 과정을 담당하는 시스템이다. 단순 자동완성이 아니라 전체 개발 프로세스의 자동화를 목표로 한다. 그러나 이 강의의 핵심은 그 '기능 소개'가 아니라, 그것을 직접 구현하는 사람이 마주치는 난이도다.

강의의 지향점도 분명하다. 강사는 산업형(온프레미스) 에이전트를 만드는 강의를 하겠다고 선언한다. 자신이 실제로 만드는 게 그것이기 때문이다. 그래서 2주차는 두 개의 축으로 나뉜다.

• 전반부(이론): 세션과 컨텍스트가 정확히 무엇인지 — KV 캐시, 프리픽스 캐시, 캐시 영속화, 세션 서버 아키텍처, 컨텍스트 구성, 컴팩트.
• 후반부(사업·설계): 왜 온프레미스인가, 산업 현장이 요구하는 기능들, 설치 형태별 함정, 그리고 실제 기술 스택과 개발 계획.

💡 실무 노하우: 강사는 "저번 시간에 2시간 반을 폭주했다"며 이번엔 개념을 천천히 짚겠다고 한다. 즉 2주차는 개념의 정밀화 회차다. 기능을 외우기보다 "세션이 왜 KV 캐시인가", "컴팩트를 언제 어떻게 판단하나" 같은 원리 질문을 붙잡는 게 이 회차의 올바른 학습법이다.

강의 도입에서 강사는 자신의 분산 추론 프로젝트도 잠깐 보여 준다. 컴퓨터 한 대에 GPU가 여러 개 있고(보통 최대 8개), 자원을 할당해 노드를 만들고, 원격에 있는 여러 컴퓨터(스파크, GB10 통합메모리, 맥 64GB, 게이밍 노트북, 윈도우 데스크톱 등)의 노드를 컨트롤러에서 결합해 하나의 세트처럼 쓴다. 이렇게 VRAM 350GB·RAM 400GB급을 긁어모아 35B~500GB(Q5) 모델을 분산 로딩한다. MI250(AMD 128GB×4, ROCm) 같은 데이터센터용도 언급된다. 이 도입부의 요지는 "모델을 돌리는 물리 계층부터 이렇게 복잡하다"는 감각을 주려는 것이다.

2. 풀려는 문제 — 왜 온프레미스 산업용 에이전트를 만드는가

핵심 질문은 이것이다. "바이브 코딩 에이전트를 왜 만드는가?" 강사의 대답은 명확하다. 납품(納品) 때문이다. 코덱스·클로드 코드가 이미 훌륭한데 왜 또 만드느냐는 질문에 대한 답은 한 단어, 온프레미스다.

문제의 구조는 이렇다. 금융권·증권사·대기업·제조사·공장 등 산업 영역은 데이터가 밖으로 나가면 안 된다. 그래서:

• 웹 검색이 안 된다. 에이전트가 밖으로 나가 검색할 수 없다.
• 모델도 사내 기밀이다. 외부 API를 못 쓰고 사내 LLM을 써야 한다.
• 수많은 보안 프로그램(파수 같은 DRM, 방화벽, 파일 암호화 툴)이 깔려 있다.
• 그래서 "일반 양키즈나 중국계가 만든 자유로운 영어 기반 에이전트가 안 통한다."

결국 이들은 사서 써야 한다. 그래서 이 시장이 존재한다. 코덱스·클로드 코드 자체는 큰 기술 격차를 만들지 않는다 — "오픈코드에 클로드 API 물려 쓰는 것과 거기서 거기"라고 다들 생각한다. 진짜 가치는 그 위에 얹는 온프레미스 통합·보안·조직 관리에서 나온다.

⚠️ 주의: "그게 그거지"라는 인식이 곧 기회다. 모델·에이전트 코어가 상향 평준화될수록, 차별화는 온프레미스에서만 필요한 지저분한 요구사항을 다 처리해 주는 능력으로 이동한다. 그 지저분함(웹검색 대체, 보안 호환, 인증, RAG, 파인튜닝)을 다룰 줄 알면 "몇억 원짜리"로 팔린다.

이 문제의식은 강의 전체의 방향을 정한다. 즉 우리가 배울 것은 "코딩을 어떻게 하나"가 아니라 "코덱스한테 뭘 시킬지", 그리고 "코덱스가 못 하는 온프레미스 요구를 어떻게 채워 줄지"다.

3. 핵심 개념·구조 — 세션, 컨텍스트, 그리고 두 가지 세션 서버

3.1 세션의 정체 = KV 캐시 식별 아이디

세션 처리 방법은 여러 가지지만, 그 밑바닥을 파면 모델 KV 캐시 식별 아이디가 있다. 세션을 2개까지 병렬로 진행하려면 KV 캐시를 두 세트 만들어야 하고, 그래야 두 대화가 동시에 각자 굴러간다. 캐시 요구량이 올라갈수록 메모리 사용량이 커진다.

여기서 강의의 첫 번째 큰 명제가 나온다.

세션의 정체는, KV 캐시 입장에서 보면, 모델이 실제 로딩하고 있는 KV 캐시의 식별 아이디와 마찬가지다. 그 캐시의 아이디가 달라지면 다른 세션이다.

한 세션은 대화가 이어져야 하므로 같은 KV 캐시를 붙잡고 있어야 한다. 그래서 프리픽스 캐시를 유지하는 것이 세션 유지의 실체다.

3.2 캐시 영속화 (Cache Persistence)

클로드 코드에는 캐시 영속화 기능이 있다. 동작은 이렇다.

1. 세션을 포크(fork) 하면, 그 포크 지점까지의 컨텍스트를 이어받은 새 세션이 태어난다. 이때 앞 세션의 KV 캐시를 처음부터 다시 만들지 않고 복사(copy) 해 온다.
2. VRAM에 KV 캐시를 계속 유지하면 메모리 소비가 크다. 그래서 세션을 안 쓰면 약 20분 뒤 캐시를 내려버린다.
3. 다시 입장할 때 캐시가 없으면 앞의 거대한 내용을 처음부터 프롬프트 프로세싱해야 해 너무 오래 걸린다. 그래서 내릴 때 하드에 직렬화해 저장해 두고, 재입장 시 그 저장본을 KV 캐시로 복원한다.

즉 캐시 영속화 = 세션의 연속성을 하드로 옮겼다가 되살리는 기능이다. 여기 나오는 "세션들"이란 결국 KV 캐시를 유지하는 세션 아이디들의 목록이다.

3.3 두 가지 세션 서버 아키텍처

세션 서버를 구성하는 방식은 크게 둘로 갈린다.

(A) 세션별 인스턴스 방식 — 클로드 코드 개별 세션마다 채널을 개설해 운영한다. 세션 하나가 완전히 독립된 채널 방(채팅방)이다. 옛날 부트캠프에서 만들던 채팅 서버처럼, 채팅방 하나하나를 세션 격리해 소켓 서버로 만든 구조와 같다. 이 방식에는 "세션을 점유·계약하고 있는 클라이언트"라는 개념이 있어, 원격 제어·다중 접속이 불편해진다.

(B) 스트리밍(이벤트 소싱) 방식 — 코덱스(전환 중) 거대한 카프카 같은 흐름 하나가 있다고 보자. 서버 입장에선 메시지/이벤트 플로우가 있을 뿐이다. 이벤트 메시지 안에 "이건 세션 3번 거, 저건 5번 거"라고 표시만 해서 던진다. 서버는 이 모두를 하나의 메시지 스트림으로 인식한다.

이 방식이 나온 논리적 근거가 중요하다. 프리픽스 캐시 때문에 앞부분이 불변으로 구현된다 → 그럴 거면 그냥 이벤트 소싱 서버처럼 구현하면 되지 않나? 그래서 코덱스는 세션 인스턴스 방식에서 스트리밍 방식으로 아키텍처를 계속 바꾸고 있다.

💡 실무 노하우: 스트리밍 방식의 결정적 장점은 클라이언트를 안 가린다는 것. 모든 클라이언트가 '이벤트 수신자이자 발송자'일 뿐이라, 모바일에서 연 세션을 브라우저에서 열어도 똑같이 보이고 똑같이 반응한다. 세션과 클라이언트가 연결(계약)을 맺지 않기 때문이다. 그래서 원격 접속·원격 권한 허가는 코덱스가 클로드 코드보다 압도적으로 좋다. 클로드 코드도 원격 지원 때문에 스트리밍 방향으로 바꾸는 중이다.

이벤트 소싱은 콜드 스트림/핫 스트림으로도 자연스럽게 이어진다. 세션 서버를 처음 열면 콜드 스트림(과거)을 싹 가져오고, 최신으로 올라오려면 핫 스트림을 이어 받는다. 강사는 "우리도 이렇게 구현할 생각"이라고 밝힌다.

4. 실습·구현 가이드 (Step 1·2·3·4)

강의는 "오늘은 개발 계획만 얘기하고 끝낸다"고 했지만, 그 계획 자체가 구현 로드맵이다. 4개 스텝으로 정리한다.

Step 1 — 컨텍스트를 계층적으로 구성한다

세션이 처음 열리면 기반 컨텍스트가 쌓인다. 순서는 다음과 같다(OpenAI 공식 문서 기준으로 강사가 설명).

1) 시스템 프롬프트   ← 로딩한 모델별로 분기(라우터)
2) 도구 정리(Tool Definitions)
3) 인스트럭션스       ← 항목이 6~7개
4) 프로젝트 퍼미션 설정
5) 개발자 인스트럭션   ← config.toml에서 에이전트별 기본 프롬프트 지정
6) AGENTS.md          ← 계층별 로딩
7) 실행 환경          ← 프로젝트 경로 등 계산해 삽입
8) README
9) 이후 대화 히스토리가 이 뒤에 append

⚠️ 주의: 시스템 프롬프트는 모델 성향에 따라 다르게 정리되어 있어, 실제 코드에는 "어떤 모델이 어떤 시스템 프롬프트를 로딩할지" 정하는 라우터가 있다. 그래서 세션 도중 모델을 바꾸면 재로딩이 필요하고, "중간에 모델 바꾸면…"이라는 경고를 본 적이 있을 것이다. 최근에는 다이나믹 프롬프트 교체로 경고를 덜 띄우는 듯하다.

기반 컨텍스트는 모델 컨텍스트의 5% 이내로 유지하려 한다. 앞이 자리를 많이 먹으면 주인공(히스토리)이 못 들어오기 때문. 코덱스도 시작 시 약 4%를 먹는다.

Step 2 — 스킬·도구·MD의 로딩과 우선순위를 처리한다

이 부분이 "지옥"이라고 반복된다. 도구 리스트조차 쉽지 않다.

• 스킬 로딩에는 그 스킬을 쓸 도구 지정이 필요하고, 에이전트 로딩에는 에이전트의 도구가 지정된다. 퍼미션에 따라 쓸 수 있는/없는 도구가 갈린다 — 이 모두를 동시에 계산해야 한다.
• 스킬 리스트는 더 지옥이다. 전역(.codex/.claude)의 스킬과 프로젝트의 스킬이 함께 계산된다. 게다가 시스템 스킬도 따로 있다.
• 이름 중복: 여러 곳에 같은 이름 'A' 스킬이 있으면 어느 A가 이겨야 하는지 우선순위를 정해야 한다. 클로드 코드는 강사가 나열한 순서대로 특정 위치가 이긴다.
• 같은 문제가 MCP·도구·커맨드·룰·MD 전부에서 생긴다.

CLAUDE.md/AGENTS.md의 계층 로딩은 특히 까다롭다. MD가 존재할 수 있는 공간이 너무 많고, "내가 어디에 속해 있느냐(현재 작업 폴더)"에 따라 관련 계층(예: 4개 + 5개)을 다 합친 뒤 200K 이내로 다시 줄인다. 단순 concat이 아니라 현재 폴더 기준의 합산 + 압축이다.

Step 3 — 컨텍스트 컴팩트를 구현한다

컴팩트는 컨텍스트 한도에 봉착하면 무조건 일어난다. 보통 기반 컨텍스트는 안 건드리고 턴 로그만 건드린다. 어려운 건 언제, 어떻게 하느냐다.

• 언제? 사용자 요청이 올 때? 그렇다면 남은 컨텍스트가 이번 응답에 충분한지 어떻게 아나? 이번 응답이 얼마나 길어질지 어떻게 아나? 리퀘스트·도구 호출·도구 결과·최종 응답 매 시점마다 토큰을 계산해 판단할 것인가? 가장 좋은 컴팩트는 흔히 80%에 도달했을 때라고 하지만, 80%인지를 프로그램이 어떻게 아는가가 핵심이다. 컨텍스트는 실제 메모리가 아니라 모델에 보내는 전체 메시지의 토큰 수이므로, 매번 전체 메시지를 파싱해 토큰을 세야 한다.
• 왜 미리 해야 하나? 인퍼런스 서버에는 이미 잘림 정책이 있다 — 롤링 윈도우(앞을 뭉개며 진행), 트렁켓 미들(중간에서 멈춤), 스탑 리미트(한도에서 끊음). 바이브 코딩에서 이런 잘림이 나면 치명적이므로, 그 전에 에이전트 수준에서 컴팩트해야 한다.

어떻게? 방식이 여러 개다.

1. 요청/응답만 남기기: 컴팩트에서 많은 양을 차지하는 건 중간의 도구 호출부다. 그것을 지우고 요청·응답만 남긴다. 그래도 길어지면 슬라이딩 윈도우로 앞을 제거한다.
2. 모델에 의한 요약(코덱스 방식): 262K 토큰을 모델이 프롬프트로 요약한다. 그러나 손실·할루시네이션 위험이 크다(7장 참고).
3. 검색형 요약(요즘 유행): 턴이 200개면 각 턴을 한 줄로만 요약하고, 상세가 필요하면 도구로 해당 턴 ID를 조회해 원문을 읽는다. 도구와 결합된 방식이라 낫다. 단, 턴 누적을 막기 위해 이것도 슬라이딩 윈도우로 구현한다.

Step 4 — 불변 리스트와 컴팩트 레코드의 관계를 설계한다

세션은 이벤트 소싱에 가까운 불변 리스트다. 그런데 리스트 중간에 컴팩트 레코드가 등장하면?

• 컴팩트 레코드는 스냅샷 구분점이 된다. 모델에 보낼 때는 마지막 컴팩트 이후(아래)만 보낸다.
• 컴팩트는 한 번만 일어나지 않는다. 여러 번 일어나므로 전체 로그에 레코드가 다수 존재할 수 있다. 스트림을 만들 때 항상 최신 컴팩트 밑으로만 컨텍스트를 구성하도록 구조를 바꿔야 한다.
• 컴팩트 레코드 병합 전략도 쓴다. RAG의 청크 병합에서 온 방법으로, 앞 컴팩트로 다음 컴팩트를 만들고 이전 컴팩트들을 모아 또 컴팩트를 만든다. 이렇게 누적 결합하면 요약 반복에 의한 열화가 다소 방지된다.

✅ 확인: Step 1~4를 한 문장으로 — "기반 컨텍스트를 계층적으로 쌓고(Step1), 스킬·MD의 중복·우선순위를 계산해 붙이고(Step2), 토큰 수를 세어 미리 컴팩트하며(Step3), 컴팩트를 스냅샷 경계로 삼아 이벤트 스트림을 재구성한다(Step4)."

5. 사례·적용 — 산업 현장의 요구사항과 설치 형태

5.1 누가 사는가

금융권·증권사·대기업·제조사·공장 등 산업 영역이 온프레미스 에이전트를 산다. 이들이 요구하는 기능은 방대하다.

• 조직 관리: 계정·팀·권한 관리. 조직 구성에 따른 스킬·도구·플러그인 접근 제어.
• 마켓 + 동기화: 엔터프라이즈 코덱스를 사면 조직 전용 마켓을 열어 준다. 회사 전용 스킬을 올리고, "우리 팀은 이 스킬을 다 깐다"는 동기화.
• 토큰 제어·대시보드: 계정별 토큰 사용량 제어, 이용 통계 — "너 오늘 일 많이 했네"를 사장이 보고 싶어 한다.
• 사내 정보 연동(RAG): 사내 코드베이스·문서 DB·Q&A DB·고객 상담 이력을 연동. 코드-RAG, PDF 밀어넣기, ARS 기록까지. "일반적인 RAG 프로젝트의 귀찮음이 다 따라온다."
• 파인튜닝: 사내 소형 모델을, 임베디드 C나 로봇 팔 모션 제어기용 특정 라이브러리 규격대로만 코딩하도록 튜닝. 강사는 RLVR로 만든 모델을 선호 정렬해 납품한다고 언급. 사용 로그로 궤적 학습·자기성찰도 시킨다.
• 일반 업무 에이전트: 코딩만이 아니라 ERP·인트라넷·오피스 도구까지 연동. "내 하드에 기안서 있는데 기안 좀 해 줘" 같은 일반 업무까지 시킨다.
• 모델 라우터: 엔터프라이즈 토큰 소진 시 사내 LLM으로 자동 전환. 쉬운 업무는 사내 LLM, 어려운 업무만 코덱스로 자동 분기해 달라는 요구도 흔하다.
• 가드레일: 사내 보안 프로그램(파수, NHN 두레이 등)·방화벽과 호환되게 만들기. 기업의 거버넌스(정책)를 가드레일로 변환.

5.2 설치 형태별 함정

⚠️ 주의: 도구 사용은 트레이닝된 환경과 달라지면 성능이 안 나온다. 그래서 네이티브형은 자신이 WSL에서 돌게 바꾸거나(리눅스 방향 트레이닝), 쉘을 고를 수 있게 한다. PowerShell은 기본 인코딩이 CP949라 한글이 자주 깨지므로 UTF-8로 지정해야 한다. Docker는 권한 문제가 깔끔히 풀리지만, 엔터프라이즈 RHEL 보안이 컨테이너를 막는 현장이 많아 네이티브로 가야 하는 경우가 잦다.

5.3 클라이언트 인터페이스와 과금

• IDE 플러그인: 자바 친화 기업은 IntelliJ, 그 외는 VS Code 플러그인.
• 에이전트 전용 앱: 바이브 코딩에 숙련된 회사가 선호.
• 웹사이트/브라우저 앱: 설치가 아예 안 되는 곳이 많아 브라우저로 제공.
• CLI: 금융권은 터미널만 허용 → CLI 클라이언트. 세션 하나만 감당하므로, 여러 세션은 tmux 등으로 창을 여러 개 띄운다.
• 과금·라이센스: 온프레미스라 관여를 못 하니 내부에 시한폭탄을 심는다. 인터넷이 없어 타임 서버 접근이 안 되므로 컴퓨터 시간을 믿어야 하고, 시간 조작 속임수를 극복해야 한다.
• 웹 검색 대체: 벡터 DB로 제공. 네이버 뉴스 + 나무위키 + 특정 크롤링 + 사내 GitHub를 인덱싱하고 USB로 주기 갱신. "온프레미스 세계는 검색 엔진을 만들고 온다."

💡 실무 노하우: 이 모든 "지저분한" 요구가 곧 매출이다. 산업용은 "요거 추가할 때마다 돈 받으면 되니 손해가 아니다." 코덱스가 지원 안 해 줄 것 같이 생긴 것들 — 그것 때문에 팔린다. "파트너만 잘 걸리면 팔린다."

6. 핵심 원리 — 세 개의 관통 명제와 기술 스택

강의 전체를 세 문장으로 압축하면 다음과 같다.

1. 세션의 정체 = KV 캐시 식별 아이디. 세션 유지란 프리픽스 캐시를 붙잡는 것이고, 병렬 세션은 캐시 세트를 늘리는 것이며, 세션 복원은 캐시 영속화다.
2. 컨텍스트 = 모델에 보내는 토큰의 합. "몇 % 찼다"는 실제 메모리가 아니라 파싱한 토큰 수의 비율이다. 그래서 구성(계층 로딩)과 관리(컴팩트) 모두 토큰 회계 위에서 이뤄진다.
3. 컴팩트 = 스냅샷 경계. 세션은 불변 이벤트 리스트이므로, 컴팩트는 데이터를 지우는 게 아니라 "여기부터 아래만 모델에 보낸다"는 경계를 찍는 일이다.

6.1 기술 스택 (개발 계획)

강사는 에이전트가 아니라 비즈니스 서버를 먼저 만든다고 한다. 통합 대시보드 서버 = 마스터 권한과 각종 설정을 쥐는 서버이며, 여기서 내려와 에이전트가 동작한다. 이 서버는 AI가 관여하지 않는 평범한 웹 서버다.

베이스:  Docker 위 Node.js LTS(24/25/26 중)
DB:     PG Vector(PostgreSQL + 벡터 확장) + 카프카 대체 이벤트 스트림 플러그인
프론트: React + TypeScript + Tailwind
백엔드: Express (웹소켓 + 일반 백엔드 겸용, 한 대로)
구조:   Turbo 모노레포 (apps + packages)

• 터보 모노레포: apps/에 빌드 단위 서비스(오케스트레이션)를 두고, packages/에 순수 핵심 도메인 로직을 둔다. 의존은 apps → packages 단방향. 실제 프로젝트에는 packages/linker_domain, packages/llama_domain 같은 도메인이 배치되고, apps/는 웹 서비스(링커)와 llama.cpp 백엔드(C++, CMakeLists.txt) 같은 이질적 프로젝트도 함께 빌드·통합한다. 터보의 큰 장점은 하부가 꼭 JS일 필요 없이 아무 프로젝트나 통합한다는 것.
• 단일 서버 배포: 프론트와 백엔드는 따로 빌드하되, 백엔드 번들이 프론트 dist를 정적으로 서빙하도록 경로를 잡아 한 대의 Express가 둘 다 처리한다. SSR은 안 쓴다(문제를 많이 일으켜서).

✅ 확인: "왜 packages는 apps를 참조하면 안 되나?" → packages는 순수 도메인 로직이라 오케스트레이션(apps)에 의존할 이유가 없다. 의존이 역류하면 핵심 도메인이 실행 세부에 오염된다.

6.2 비즈니스 서버가 품는 것

• 자체 인증: 온프레미스라 구글 로그인이 안 된다 → 자체 로그인 + 토큰 기반 세션키 발급, 중앙 모니터링. 퇴사 시 세션키·계정 즉시 제거, 이상 행위 감지 시 세션키 즉시 만료(중간 통제).
• 풋프린트: 로그인 시 사내 IP·부서·사번·노트북 보안코드 등을 남긴다. 회사마다 요구가 달라 커스터마이즈 가능해야 한다.
• 중간관리자 위임: 팀장이 팀원 계정·권한을 관리 → 관리자 페이지가 로그인한 사람의 역할에 따라 다르게 렌더된다.
• 인가(Authz): 도구 접근(보안 1등급 문서 접근 도구/아닌 도구), 저장소 접근, 특정 스킬 접근, 팀 전용 스킬·RAG.
• 공유 드라이브: 프로젝트 생성을 로컬이 아닌 공유 드라이브/사내 GitLab·GitHub Enterprise에서만 허용해 소스 노출을 막는다. 팀별·개인별·전체 공유 자원 설정은 S3 버킷 설정과 유사하다.

7. 한계·트레이드오프

강의는 이상론이 아니라 "만들어 보면 그지같다"를 반복한다. 주요 트레이드오프를 정리한다.

1. 컴팩트의 근본적 딜레마 — 언제·어떻게가 모두 어렵다 너무 자주 컴팩트하면 낭비, 늦으면 잘림. 80% 판단은 매 시점 토큰을 세야 알 수 있고, 응답 길이는 미리 알 수 없다. "약간만 걱정될 때마다 컴팩트할 수는 없다."

2. 모델 요약의 열화·할루시네이션 5% 기반 + 95% 히스토리 상태에서 모델 요약을 하면, 95%가 5%로 줄어 전체는 약 10%만 남는다. 95% 분량 정보를 5%로 압축한 셈이라 중요 정보가 대량 분실되고, 262K를 요약하는 과정에서 엄청난 할루시네이션이 끼어든다. 그런데도 민감한 코딩 작업을 이어가야 한다 → "요약 방식에 따라 바이브 코딩 성능이 완전히 달라진다."

3. 캐시 영속화의 메모리 vs 시간 VRAM에 캐시를 계속 유지하면 즉시 응답이지만 메모리 소비가 커 다세션에서 비현실적. 하드로 내리면 메모리는 회수되지만 복원 로딩 시간이 든다. 20분 유휴 후 직렬화 → 재입장 복원이 그 절충점이다.

4. 설치 형태의 상호 배제 Docker는 보안을 풀어도 되지만 네이티브 개발이 안 되고 RHEL서 막힌다. 네이티브는 강력하지만 보안 설정이 까다롭다. 한쪽을 택하면 다른 쪽 장점을 포기한다.

5. 온프레미스의 구조적 불편 웹검색은 벡터 DB로 근사할 뿐 전체 웹이 아니다. 인덱스는 특정 시점(예: 2026년 4월)에 고정되어 USB로 갱신해야 한다. 라이센스는 시간 조작에 취약하다. 보안 프로그램(파수·두레이·파일 암호화)과의 호환은 늘 깨질 위험을 안는다.

⚠️ 주의: 이 한계들은 "해결됐다"가 아니라 "공급자가 계속 연구해야 하는 열린 문제"로 제시된다. "컴팩트를 잘해 주고 싶은데, 잘하는 방법을 여러분이 연구해야 한다는 게 문제다. 우리가 공급자니까."

8. 다른 접근과 비교

8.1 세션 인스턴스 vs 스트리밍(이벤트 소싱)

이벤트 소싱의 지연은 보통 서비스에서 크리티컬하지만, 바이브 코딩에서는 모델 인퍼런스가 압도적으로 느려 티가 안 난다. 그래서 셔딩 없이 안정적 메시지 큐 구조를 택하는 게 낫다.

8.2 컴팩트 방식 비교

판정: 민감한 코딩을 이어갈 때는 정보 보존이 좋은 검색형 요약이 우세하되, 어느 방식이든 결국 슬라이딩 윈도우를 병행하게 된다. 열화 완화를 위해 컴팩트 레코드 병합을 얹는다.

8.3 개발 순서 — 에이전트 우선 vs 비즈니스 서버 우선

직관은 "에이전트를 먼저"지만, 강사는 비즈니스 서버 우선을 택한다. 조직·인증·권한·설정의 최상위가 먼저 서야 에이전트가 그 아래로 내려와 동작하기 때문이다. 산업용은 이 마스터 계층 없이는 성립하지 않는다.

8.4 조직론 — 개인 작업 vs 팀 원탁

강사는 현재의 개발 조직을 "벽 보고 개인별로 앉아 토큰 태우는" 구조라고 비판한다. 마차 운송에서 자동차 운송으로 넘어가는 전환기처럼, 기술 세트 전체가 바뀌었다("히든 피겨스"의 수학자들이 코딩으로 전업하듯). 코딩은 어차피 에이전트가 하므로, 사람이 할 일은 팀이 원탁에 모여 목적·규칙·마일스톤·스프린트를 확정해 던지고 퇴근한 뒤, 아침에 모여 리뷰하는 것이다. 혼자 하면 개인 수준 생산성에 갇힌다.

📚 참고: 이 비교의 실무 함의 — "여러분의 근무시간에 할 일은 팀원과 원타겟에 모여 계획 문서를 만드는 것"이다. 밤새 에이전트가 작업하고, 사람은 계획과 검증에 집중한다.

9. 메타인지 자기평가

아래 질문에 스스로 답해 보라. 막히면 해당 섹션으로 돌아간다.

개념 회상 (0·3장) - [ ] 인퍼런스 서버 관점에서 '세션의 정체'를 한 문장으로 말할 수 있는가? (→ KV 캐시 식별 아이디) - [ ] 프리픽스 캐시·캐시 영속화·이벤트 소싱을 각각 비유로 설명할 수 있는가?

구조 이해 (3·4장) - [ ] 기반 컨텍스트가 쌓이는 9단계 순서를 순서대로 나열할 수 있는가? - [ ] 왜 기반 컨텍스트를 5% 이내로 유지하려 하는지 설명할 수 있는가? - [ ] AGENTS.md 로딩이 단순 concat이 아닌 이유(현재 폴더 기준 합산 + 200K 압축)를 말할 수 있는가?

적용 (4·5장) - [ ] "80% 찼다"를 프로그램이 어떻게 판단하는지 설명할 수 있는가? (→ 전체 메시지 토큰 수 계산) - [ ] 도구 호출이 많을 때 어떤 컴팩트 방식을 1차로 택하는가? - [ ] 엔터프라이즈 토큰 소진 시 모델 라우터가 무엇을 해야 하는가?

분석·평가 (7·8장) - [ ] 모델 요약 컴팩트에서 전체가 왜 약 10%만 남는지 수치로 설명할 수 있는가? - [ ] 세션 인스턴스 vs 스트리밍 중 다중 클라이언트에 유리한 쪽과 그 이유를 댈 수 있는가? - [ ] 네이티브 vs Docker 설치형의 트레이드오프를 두 축 이상으로 비교할 수 있는가? - [ ] "혼자 바이브 코딩 가능하다"는 통념을 반박할 수 있는가?

종합·창작 (5·6장) - [ ] 산업용 에이전트의 조직 관리 시스템에 무엇을 넣을지 직접 설계할 수 있는가? - [ ] 에이전트가 밤새 자율 진행할 마일스톤/스프린트 문서의 뼈대를 그릴 수 있는가?

✅ 확인: 이 회차의 목표 도달선은 "기능을 안다"가 아니라 "공급자로서 설계 결정을 내리고 그 트레이드오프를 말할 수 있다"이다. 위 체크리스트에서 절반 이상 막히면 3·4장을 다시 정독하라.

부록 A — 강의에서 언급된 고유명사(맥락 보존용)

아래는 강사가 발화한 그대로의 식별자다. 개념 이해의 맥락으로만 참고하고, 각 항목의 최신 스펙·버전·성능은 별도 확인이 필요하다(본 자료는 강의 내용 정리이지 제품 스펙 검증서가 아니다).

• 하드웨어/분산: GPU 노드 결합, 스파크, GB10(통합메모리), MI250(AMD 128GB×4, ROCm), Q5/Q4 양자화, 35B·118B·262K 컨텍스트.
• 에이전트/도구: 코덱스, 클로드 코드, 오픈코드, config.toml, AGENTS.md/CLAUDE.md, MCP·스킬·커맨드·룰.
• 기술 스택: Docker, Node.js LTS, PG Vector(PostgreSQL + 벡터 확장), 이벤트 스트림 플러그인, React·TypeScript·Tailwind, Express, Turbo 모노레포(apps/packages: linker_domain·llama_domain), llama.cpp(C++/CMakeLists).
• 보안/온프레미스: 파수, NHN 두레이, RHEL(레드햇), 파일 암호화 툴, 거버넌스/가드레일, RLVR·선호 정렬·궤적 학습.
• 모델 라우터 UI 예시: 강사가 오픈라우트에서 예로 든 오픈소스 모델들(네모트론 계열, 미모, 라구나/링, 딥식 계열 등). 이는 강의 시점의 예시 언급이며 현재 라인업·성능과 다를 수 있다.

부록 B — 한 줄 요약 모음

• 세션 = KV 캐시 아이디. 병렬 세션 = 캐시 세트 증가. 세션 복원 = 캐시 영속화.
• 컨텍스트 = 보낸 토큰의 합. 구성은 계층 로딩, 관리는 컴팩트.
• 컴팩트 = 스냅샷 경계. 마지막 컴팩트 아래만 모델에 보낸다.
• 온프레미스 = 자유를 버리고 살림을 떠안는 대가로 산업 시장을 얻는 것.
• 사람의 일 = 코딩이 아니라 팀 원탁에서의 계획·검증.