이번에 베타 버전을 런칭하며 계정 당 1회에 한해서 14일 짜리 무료 플랜과 1000 크레딧을 제공한다.
가벼운 캐주얼 게임들을 제작해보며 1일차에 느낀 점과 몇가지 정보를 작성한다.
우선은 14일 동안 크레딧을 전부 소모한다는 생각으로 써본 뒤에 후기를 정리하여 업로드 할 예정이다.
간단한 Image 생성을 직접해준다.
모델은 Flux 2 시리즈를 쓴다. pro 를 쓸 때도 있고 preview 를 쓸 때도 있다. 이미지의 경우 생각보다 결과물이 나쁘지 않은 편. 프로토타이핑에 쓰기에 최적이다.
Unity Editor 위에 붙여놓은 AI 어시스턴트이므로 에디터의 Refresh 사이클을 따라간다.
Play, Stop, Refresh 등등 에디터가 리프레쉬 되는 환경이면 얄짤없이 창이 깜빡이며 대화 내역을 다시 렌더링한다. 사용에 불편함이 있는 것은 아니지만 은근슬쩍 신경쓰이는 부분. 또한 에디터에 붙여놓은 이상 사양이 무거워지는 것도 피할 수 없다.
별도의 조건을 작성하지 않는다면 UI 는 UIToolkit 으로 만든다.
하이어라키와 씬을 조작하는 것이 아닌 웹표준이므로 코드로 접근가능하기 용이하기 때문으로 추정.
몇번의 추가적인 작업으로 기존에 지능형 에이전트 IDE 등이 MCP 를 통해서 몇번이고 삽질하던 해상도 대응을 비교적 잘 해주는 모습을 보였다.
GeminiCLI, Claude Code, Codex 와 같이 기존 사용하던 AI 의 API 호출을 통해 가져다쓰는 경우, 미리 만들어놓은 md 파일들을 우선 참조한다.
Gemini API 무료 플랜 기준 Gemini 3 Flash 를 호출했을 시, 가벼운 하이퍼캐주얼 프로젝트를 읽히는 경우 RPM 4~5회(+@ 추정), TPM 55k~65k, RPD 8~13회 정도를 소모하는 것으로 측정되었다.
현재 타사 AI API 를 호출하여 대화 세션을 여는 경우, 대화 세션을 변환했다가 다시 돌아왔을 때 세션과 AI 의 연결이 제대로 되지않는 문제가 발생하고 있다.
Gemma4, Codex 도 동일한 것으로 보아하니 아직 베타 버전의 문제일 가능성도 있음. (정확한 원인 파악X)
API KEY 외에도 Environment Variables 을 통해 직접 특정 모델을 호출 가능하다.
예시) KEY) GEMINI_MODEL VALUE) gemma-4-31b-it
트레일러 영상등에서 보여준 모습은 아직 미흡하거나 특출나지 않다는 의견이 있음
바퀴가 바닥에 묻혀서 작동하는 등 제대로 된 디테일을 보여주지 못한다. (필자) 다만 이건 모든 AI 툴의 한계이므로 디테일까지 맡기는 건 현 단계에서는 매우 욕심같은 의견임
UnityCLI, CoplayDev 등의 기존 MCP 가 있으므로 이걸 사용할 이유가 없다는 평. (필자) 고급 작업으로 갈 수록 사람이 손을 대는 경우가 많아진다. 특히나 코드 생성에 대해서는 대부분의 모델들이 프로젝트 구조를 읽고 (대부분은 프로젝트 코드간의 의존성 및 관계도) 작업에 들어간다는 커다란 골자가 그대로이기 때문에 나오는 의견으로 보임. UnityAI 가 타 모델에 비해서 압도적인 경쟁력을 갖추려면 코드가 아닌 비주얼 작업에 특화되어야 한다는 의견에는 동의한다.
과금모델 산정 방식이 너무나 구시대적임
토큰이나 화폐 단위가 아니라 Credit 이라는 자체 단위를 사용하고 있다. 생성 비용 게시가 명확하지 않으면 사용자들은 요금 산정에 어려움을 느끼고, 이는 곧 진입 장벽이 된다. (필자) 이는 구구절절 맞는 말이라고 생각한다. 약 10~15년전 마이크로소프트의 XBOX 는 확장성을 강조하며 정작 스토어 결제 재화를 현금으로 포인트를 구매하는 방식의 자체 재화를 사용했는데, 이는 화폐 결제로 변경하는 순간까지 불편함을 토로하는 유저가 끊임없이 나타나며 결제 진입 장벽의 고질병으로써 언급되었다.
유료 결제를 해야하는 MCP 자체가 별로 없으므로 접근 제한 자체가 문제가 된다. (필자) MCP 를 사용하는데 1000credit/20$ 의 최소 금액을 지불하며 사용하라고하면 부담감을 느끼는 유저가 적지 않다는 생각을 당연히 해봤다. 사용하는 만큼 내는 것이니 결국 credit 제도는 API 요금제와 비슷한 결을 가지게 된다. 위 문제와 연결되는 의견이 된다.
실제 깃 스타를 많이 받았더라도 실무에 당장 쓸 수 있다기보다는 레포 소스가 갖고있는 잠재성 등을 보고 평가를 했기 때문도 있으며,
한 때 GStack 과 같은 명령어 팩으로 배포한 방법론 역시 개발영역과 스택에 따라서 찬반이 꽤 갈리는 편이다.
부족한 견해로 정리해본 결과, 프롬프트부터 이어진 하네스 엔지니어링 역시 AI 라는 도구를 어떻게 다루어야하는가에 대한 방법론을 정립해나가는 과도기에서 나타난 단계 중 하나라고 생각이 든다.
따라서, 더 많은 AI 와 작동 구조를 인지하고 내 자신에게 맞는 AI 프롬프팅과 작업 프로세스를 구축하는 것이 현재로써는 가장 좋은 방법이 아닐까? 라는 생각을 갖게 만든다.
2. Unity 애니메이션 관련.
생각보다 클라이언트가 만질 일이 많다.
애니메이터 컨트롤러, 오버라이드 컨트롤러, 아바타 마스크, IK Constraints...
최근 중심적으로 복습하는건 Constraints 와 IK 제어 스크립트 관련이다.
최근 재미있게 하고있는 해외 대기업 게임사의 게임이 있는데,
이 게임의 전투 시스템을 모작하는 것이 곧 애니메이터와 기초 전투 시스템과 애니메이터의 복습을 거의 완벽하게 도와줄 것 같았다.
이건 나중에 기초편과 스크립트 자체를 포스팅하는 식으로 올릴 예정.
3. AI 에 맞는 타 게임 엔진 탐색
Love2D 와 Godot 엔진 쪽을 입맛을 다셔보는 중이다.
yaml 형식의 유니티 메타 파일은 guid 를 통해 리소스와 연결된다.
단순히 메타 파일을 몇개 읽는 것 만으로는 객체의 계층 구조를 알기가 쉽지 않다는 것.
토큰을 왕창 쏟아부으면 가능할지도 모르겠지만 가벼운 수정 하나에도 고비용을 지출하고 싶은 개발자는 없을 것이다.
고도 엔진은 문서 자체에 노드 속성 (오브젝트 이름, 타입... 등) 이 그대로 적혀있는 구조이므로 AI 가 직접 수정해도 에디터에서 문제가 일어날 확률도 적을 뿐더러, 특정 오브젝트에 대한 제한된 작업을 하더라도 필연적으로 다른 파일을 읽어야 할 가능성이 줄어들 것이다.
Godot 엔진은 이미 23년 유니티 요금제 개편 사태 때 대안으로 많이 떠올랐기도 하고,
벤더락인의 문제는 단순히 AI 에서만 나타나는 일은 아닐테니까 다른 엔진 맛을 야금야금 계속해서 봐두는 것도 향후 큰 도움이 될지도 모른다.
터미널을 통해 설치한 이유는 매우 빡빡한 사양 내에서 최대한 컨텍스트 크기를 확보하기 위해서이며,
조금이라도 VRAM 을 아끼기 위한 발버둥이기도 하다...
가장 큰 이유는 터미널을 통해 serve 를 하면, 로그를 바로 확인할 수 있다는 점이다.
매번 터미널을 열어서 명령어와 환경변수를 입력하면 귀찮으니까 아래 bat 을 작성한다.
@echo off
:: 0. 한글 깨짐 방지 (UTF-8 모드로 전환)
chcp 65001 >nul
title Ollama Server
echo [!] 작업 표시줄(트레이)에 Ollama가 실행 중이라면 먼저 종료해야 합니다.
echo.
:: 1. 네트워크 및 호스트 설정
set OLLAMA_HOST=0.0.0.0:11434
:: 2. 디버그 모드 활성화 (상세 로그 출력)
set OLLAMA_DEBUG=1
:: 3. 최적화 설정
set OLLAMA_FLASH_ATTENTION=1
set OLLAMA_MAX_LOADED_MODELS=1
set OLLAMA_NUM_PARALLEL=1
echo [*] OLLAMA_HOST 가 %OLLAMA_HOST% 로 설정되었습니다.
echo [*] 디버그 모드가 활성화되었습니다.
echo [*] 메모리 및 병렬 처리 최적화가 적용되었습니다.
echo [*] 서버를 시작합니다...
echo.
ollama serve
pause
OLLAMA_DEBUG
이 모드를 활성화하면, Modelfile 을 통해 새로이 작성한 LLM 모델에서도 토큰입출력량 및 상세 로그가 출력된다. 계속해서 문제가 발생한다면, 이를 통해서 문제를 파악하자.
OLLAMA_FLASH_ATTENTION
Flash Attention 이라는 알고리즘을 활성화하며, 메모리 읽기/쓰기 횟수를 줄여준다.
OLLAMA_MAX_LOADED_MODELS
메모리에 동시에 올려두는 모델의 개수이다. 사양이 최소 사양에 근접하므로 1개를 주었다.
OLLAMA_NUM_PARALLEL
한 번에 처리하는 병렬 요청 수
Ollama 는 여러 요청을 동시에 처리할 때 KV 캐시를 쪼개서 나눠준다.
이 값이 1 일 때, GPU 가 가진 코든 KV 캐시 용량을 단 하나의 질문에 할당한다. 즉 Modelfile 에서 설정한 값에 따른 메모리를 다 쓰겠다는 소리.
# 1. 베이스 모델 설정
FROM gemma4:e2b
# 2. 컨텍스트 크기 설정 (원하시는 대로 숫자를 바꾸셔도 됩니다)
# 65536 = 64k (RTX 3090 추천)
# 128000 = 128k (최대치지만 VRAM 부족으로 에러 날 확률 있음)
PARAMETER num_ctx 65536
# 3. 기타 최적화 파라미터
PARAMETER temperature 1
PARAMETER top_k 64
PARAMETER top_p 0.95
# 4. 모델 템플릿 및 엔진 설정 (기본값 유지)
TEMPLATE "{{ .Prompt }}"
RENDERER gemma4
PARSER gemma4
temperature : 0 에 가까울수록 결정론적 결과를 내놓는다.
top_k : 모델이 다음 단어를 선택할 때 선택지를 몇개까지 둘 것인지 지정하는 수치
값이 작다면 응답이 일관적이나, 표현이 단조롭거나 반복적일 수 있다. 코딩에 쓴다면 값을 더 줄여도 된다.
값이 커지면 그만큼 헛소리를 하거나 잘못 된 정보에 대한 신념... 이 생길 수 있다
top_p : 값에 따라서 다음에 올 단어들의 확률이 높은 순으로 합계가 몇 %가 될 때까지 선정할 지를 지정하는 수치이다.
값이 작다면 상위권 단어 몇개만으로 후보군을 지정하므로, 모델이 이상한 소리를 못하게 예방하는 효과가 있다.
값이 높다면 창의적인 표현등을 사용하나, 목적에 맞지않는 동문서답을 할 수 있다.
이제 위 Modelfile 을 확장자 없이 저장하고. 저장한 위치에서 터미널을 열어 아래 명령어를 입력하자.
agent-model-name 은 원하는 이름으로 작명하여 넣자.
ollama create agent-model-name -f Modelfile
이제 num_ctx 의 값을 적용한 모델이 작성되었다.
터미널을 통해 ollama 모델을 실행하고, kilocode 에서 UnityMCP 를 통해 가벼운 명령어를 내려보자.
어떻게 되기는 되지만, e2b 모델이라 매우 정확히 명령을 내려야하며
체감상 IvanMurzak 의 UnityMCP 를 쓸 때보다 씬 오브젝트 구성의 경우 정확도가 매우 떨어진다.
씬을 구성하고 디자인을 하는 용도로 쓰기보다는, e2b 는 간단한 알고리즘 보조도구, 반복 작업용으로써 이용하는 것을 권장한다.
클라우드 유료 모델을 쓸 때는 처리 과정이 좀 길지만, 대충 말해도 알아서 적당히 만들어준다.
만약 제한 된 사양 내에서라면
현재 툴과 모델의 조합이 얼마나 맞는지도 찾아나가야 할 필요가 있을 것이다.
[ 마치며 ]
쓸데 없이 글이 길어졌지만, 이렇게 로컬 llm 모델을 설치하고 작동시키며 MCP 까지 물리는 작업을 완료했다.
컴퓨터 부품 값이 천정부지로 치솟는 오늘날, llm 모델을 설치하고 운용하기 위한 그래픽카드를 사는 것 자체가
새로운 폴더를 임의의 이름으로 만들어 내부에 SKILL.md 에 작성한 뒤에 인식시켜보자.
---
name: test-skill
description: >-
스킬 시스템이 정상적으로 로드되었는지 확인하고, 에이전트와 스킬 간의 연결 상태를
즉각적으로 검증하기 위한 테스트 도구입니다.
metadata:
category: development-test
source:
repository: 'local'
path: test-skill
---
# Test Skill (테스트 스킬)
이 스킬은 커스텀 스킬 시스템이 환경 설정에 올바르게 반영되었는지, 그리고 에이전트가 지정된 명령어에 따라 적절한 출력을 내놓는지 테스트하기 위해 사용됩니다.
## When to Use This Skill
- 새로운 스킬 경로를 추가한 후 인식이 잘 되었는지 확인할 때
- 에이전트가 커스텀 .md 파일을 스킬로 인지하고 있는지 테스트할 때
- 복잡한 로직을 수행하기 전, 시스템의 기본 작동 여부를 점검할 때
- "테스트 스킬 실행해"라는 명령에 시스템이 즉각 반응하는지 볼 때
## What This Skill Does
1. **시스템 연결 검증**: 에이전트가 이 .md 파일의 내용을 읽고 해석할 수 있는지 확인합니다.
2. **고정 문구 출력**: 사용자의 특정 호출에 대해 약속된 응답을 반환합니다.
3. **상태 증명**: 스킬 시스템이 활성화되어 있으며 명령을 받을 준비가 되었음을 알립니다.
## How to Use
### 기본 테스트 실행
"테스트 스킬 실행해"
"test-skill 실행해"
### 상태 확인 요청
"스킬 시스템 정상이야? 테스트해줘."
## Example
**User**: "테스트 스킬 실행해"
**Output**: "스킬 테스트입니다"
## 명령 및 응답 가이드
### 호출어 (Triggers)
에이전트는 다음 문구가 포함된 요청을 받으면 이 스킬을 활성화해야 합니다:
- "테스트 스킬 실행해"
- "test-skill 실행"
- "스킬 테스트 시작"
### 필수 응답 (Required Output)
이 스킬이 호출되면 에이전트는 다른 부연 설명 없이 혹은 답변의 최우선 순위로 다음 문구를 출력해야 합니다:
**"스킬 테스트입니다"**
## Advanced Features
### 실행 환경 확인
사용자가 상세 정보를 요구할 경우, 현재 이 스킬이 로드된 파일 경로와 이름을 함께 출력하여 설정 파일의 위치를 사용자에게 안내합니다.
### 연속 테스트
반복적인 호출에도 동일한 응답을 내놓는지 확인하여 에이전트의 일관성을 테스트할 수 있습니다.
이렇게 인식을 한다. 결과는 아래처럼 나온다.
[ 마치며 ]
지금까지 잘 따라왔다면, kilocode 에서 로컬 llm 을 돌리는 방법과각 에이전트의 사용 방법과 설정, 그리고 Global Rules 와 Skill 을 추가하는 방법을 익혔을 것이다.다음 글에서는 UnityMCP 와 KiloCode 를 연결하는 방법을 작성할 예정이다.
스크린샷과 설명 때문에 스크롤이 길어졌지만, 실제로 해보면 어렵지않음을 느낄 수 있다.한번 세팅해두면 향후 로컬 llm 이 공개될 때마다 모델만 설치하고 갈아끼우면 되니까 더 간편하게 느껴질 것이다.
1. 터미널에서 아래와 같은 명령어를 사용하거나 [Ollama 다운로드] 에서 운영체제에 맞는 인스톨러를 받아서 설치하자.
Windows
winget install Ollama.Ollama
MacOS
curl -fsSL https://ollama.com/install.sh | sh
2. 설치 확인을 위해 아래 방법 중 하나를 사용해보자.
터미널로 확인
아래 명령어를 터미널에 입력하면 스크린샷과 같은 버전명이 뜬다.
ollama --version
시스템 트레이 확인
윈도우나 맥 환경에서 시스템 트레이에 정면을 보는 라마 얼굴이 떠 있다면 엔진이 도는 중이다.
브라우저로 확인
http://localhost:11434
를 브라우저에 입력하여 Ollama is running 이라는 문구가 뜨면 서버가 작동 중이다.
아파치 입문할 때 써보신 분들도 있을 듯.
이제 터미널에서 아래와 같은 명령어 중 하나를 통해 모델을 선택하여 설치한다.
pull 을 run 으로 바꾸면 모델이 없는 경우 다운로드 후 바로 채팅 모드로 들어간다.
스크롤이 귀찮은 사람을 위해 사양표를 다시 첨부한다. (권장 VRAM 의 약 2.5배는 여유를 잡을 것)
모델 명칭
명령어
권장 VRAM
특징
Gemma 4 E2B
ollama pull gemma4:e2b
2~3GB
초경량, 모바일/엣지 기기용, 매우 빠름
Gemma 4 E4B
ollama pull gemma4:e4b
4~6GB
가성비 추천, 일반적인 코딩 보조에 적합
Gemma 4 26B
ollama pull gemma4:26b
16~20GB
MoE(전문가 혼합) 구조, 높은 지능과 속도의 균형
Gemma 4 31B
ollama pull gemma4:31b
24GB+
가장 강력한 성능, 복잡한 설계 및 아키텍처용
다운로드를 받은 뒤 ollama list 를 터미널에 입력하여 설치 된 모델을 확인 가능하다.
또는 Ollama 앱의 채팅 하단의 드롭박스를 통해서도 확인할 수 있다.
설치한 모델을 선택하여 말을 걸어보자.
앱을 통해서 채팅을 하는 경우
터미널을 통해서 채팅을 하는 경우
다음과 같이 정상적으로 작동하는 것을 볼 수 있다.
또한 kilocode 등을 이용하여 mcp 등을 같이 사용하는 경우, 컨텍스트 삽입 때문에 기본 토큰량이 커질 수 있다.
이를 위하여 ollama 앱 자체에서 컨텍스트 크기를 조절하자.
Settings 의 최하단에서 조절이 가능하다.
Gemma4 의 컨텍스트 크기는 128000토큰 이지만 필자는 64k 로 먼저 사용하며, 조절하는 단계를 밟고 있다.
필요에 따라서는 각 모델이 제공하는 최대 크기로 땡겨놓고 쓰면서 조율해도 될 것 같다...
이제 로컬 LLM 의 기본적인 설치는 다 끝났다.
다음은 kilocode 에 연동하는 방법과 이후로는 UnityMCP 를 설정하는 방법을 알아보자.
[ 부록 (Modelfile) ]
Modelfile 은 커스텀 모델을 만들기 위한 설정을 담은 파일이다. Docker 경험자라면 Dockerfile 과 유사함을 바로 아실 듯 하다.예를 들면, 우리는 SKILL.md (Gemini 라면 GEMINI.md) 와 같은 마크다운 파일에 모델의 행동 강령을 설정할 것이다.이처럼 Modelfile 은 로컬 LLM 모델을 커스텀화하기 위한 레시피인 것이다.
기본 파일의 설정은 아래와 같다.
# 1. 기반이 되는 모델
FROM gemma4:e2b
# 2. 성능 및 메모리 설정
PARAMETER num_ctx 8192 # 컨텍스트 크기를 8k로 고정
PARAMETER temperature 0.3 # 낮을수록 정확하고 일관된 답변 (코딩용)
PARAMETER top_p 0.9 # 답변의 풍부함 조절
# 3. 에이전트의 성격 및 지침 (SYSTEM 프롬프트)
SYSTEM """
너는 'Kilocode'와 연결되어 작동하는 전문 풀스택 개발자 에이전트이다.
- 코드는 항상 최신 문법을 따르며, 가독성이 높을 것.
- 사용자가 묻지 않아도 잠재적인 버그나 보안 이슈가 보이면 반드시 지적할 것.
- 답변은 한글로 하되, 기술 용어는 영어와 병기할 것.
"""
파일을 생성한 뒤, 파일이 있는 경로에서 터미널을 열고 아래 명령어를 입력한다.
agent-model-name 에는 원하는 이름을 넣을 것.
ollama create agent-model-name -f Modelfile
설치가 끝나면 ollama list 를 통하여 agent-model-name 이 생겼음을 알 수 있다.
이제 해당 커스텀 모델을 ollama 앱이나 터미널에서 똑같은 방식으로 접근할 수가 있게 되었다.
다만 Kilocode 와 같은 코딩 에이전트 역시 설정에 Temperature 같은 값을 갖고있다.
이 값은 낮을 수록 원 질문에 가장 안정적인 대답을 하며, 높은 값을 설정하면 무작위성이 짙어져 예상하지 않은 답을 내거나, 거짓된 정보를 뱉을 수도 있다.
또한 modelfile 과 에이전트의 Temperature 값이 다른 경우, 일반적으로는 에이전트의 값을 따르므로
이를 잘 고려하여 양 설정의 값을 결정하거나, 에이전트의 설정하나로 일원화하는 것이 편할 것이다.
처음에는 OpenCode 를 썼는데 뭔가 잘못 설정한건지, MCP 인식이 제대로 안됐던건지 모르겠지만
ai-game-developer 의 tools 의 리스트는 읽어오지만 제대로 통신이 안되는 모습을 보여줬다.
kilocode 로 바꾸고 여차저차해서 성공했지만, 본체 사양이 낮아서 무겁게 동작할 때도 간간히 있다.
UnityMCP 에서 제공하는 kilocode mcp 서버 설정방법은 잘못돼서 kilocode 의 mcp 설정 사양으로 바꾸는 작업이 필요했다.
또한 ollama 의 기본 토큰이 4096으로 잡혀있고, kilocode 에서는 cli 를 통해 질문을 보낼때와 달리 다른 정보를 포함하여 프롬프트를 보내기 때문에 최적화가 되지않은 상태에서는 거의 질문당 1만 토큰이 들어오는 경우가 있어서 이를 따로 확장하는 작업이 필요했다.
아래는 로컬에서 ollama 로 gemma4:e2b 를 kilocode 로 테스트 했을 때의 로그다.
세션에 아래 명령어를 통해 간이 테스트 가능. 꼭 동일한 프롬프트를 쓸 필요는 없다. 가벼운 작업 지시도 ok
(후킹을 지원하지 않는 경우)context-mode 를 통해, 현재 프로젝트 폴더 내의 가장 큰 스크립트 파일을 찾아줘. (후킹을 지원하는 경우) 현재 프로젝트 폴더 내의 가장 큰 스크립트 파일을 찾아줘.
context-mode 를 통해 라고 쓰는 경우는 후킹을 지원하지 않는 툴의 경우 관성적으로 익숙한 기존 방식을 고수하려하기 때문
글로벌 스킬.md 에 넣어놓아도 지키지 않는 경우가 많으니 명시적으로 언급하면 확실함.
파일을 찾은 뒤 ctx stats 를 통해 토큰 절약 비율이 나오면 성공
context-mode: AI 에이전트를 위한 컨텍스트 가상화 레이어
1. 개요
context-mode는 LLM(Large Language Model) 기반 AI 에이전트의 컨텍스트 윈도우 한계를 극복하기 위해 설계된 MCP(Model Context Protocol) 기반 가상화 서버임. AI가 도구를 실행할 때 발생하는 방대한 출력 데이터를 필터링하고 압축하여 모델의 토큰 소모를 비약적으로 줄이는 기능을 수행함.
AI 에이전트가 실행하는 도구(Tool)의 출력을 모델에게 직접 전달하지 않고, 가상화 레이어에서 관리함. 이를 통해 모델이 처리해야 할 정보의 양을 최소화함.
데이터 압축: 최대 98%의 컨텍스트 절감 효과 제공 (예: 315KB의 원시 데이터를 5.4KB의 요약본으로 변환).
토큰 효율성: 불필요한 로그 및 중복 데이터를 제거하여 API 호출 비용 절감 및 모델의 집중도 향상.
2.2 샌드박스 기반 실행 (Sandboxed Execution)
모든 명령 및 도구 실행은 격리된 환경에서 이루어짐.
격리 환경: 독립된 서브프로세스로 실행되어 메인 프로세스와의 간섭 차단.
보안: gh, aws, docker 등 주요 CLI 도구의 인증 정보와 작업 환경을 안전하게 분리하여 관리.
2.3 세션 연속성 및 검색 (Session Continuity)
긴 대화 흐름 속에서도 이전 작업 상태를 유실하지 않도록 영속성 계층을 제공함.
SQLite 통합: 작업 이력, 파일 편집 내역, 오류 로그를 SQLite 데이터베이스에 기록.
고급 검색:FTS5(Full-Text Search) 인덱싱과 BM25 알고리즘을 활용하여 과거의 맥락 중 필요한 부분만 정밀하게 추출하여 재삽입.
3. 기술 스택 및 구조
구분
내용
프로토콜
Model Context Protocol (MCP)
언어/환경
TypeScript, Node.js
데이터베이스
SQLite (with FTS5 extension)
지원 런타임
JS, Python, Go, Rust 등 10개 이상 언어
4. 활용 시나리오
대규모 로그 분석: 수천 줄의 빌드 로그 중 에러 원인이 되는 핵심 라인만 AI에게 전달.
장기 프로젝트 수행: 컨텍스트 윈도우가 가득 차서 이전 기억을 잃는 문제를 방지하고 6배 이상 긴 세션 유지.
복합 CLI 작업: 여러 도구(Git, AWS, NPM 등)를 동시에 사용하는 복잡한 워크플로우 제어.
5. 결론
context-mode는 단순한 도구 모음이 아닌, LLM이 가진 하드웨어적 한계(Context Window)를 소프트웨어 아키텍처로 해결하려는 시도임. Claude Code나 기타 MCP 호환 클라이언트를 사용하는 개발 환경에서 컨텍스트 관리 효율을 극대화할 수 있는 필수 레이어로 평가됨.
