Weekly Tech Trend Talk 스터디(26.04.23)

공개 전부터 화제였던 “Duct Tape”

사실 이 모델, 공식 발표 이전부터 커뮤니티를 들썩이게 만들었다. 2026-04-04 LMArena image arena에 세 개의 익명 변종이 조용히 등장했고, 이름이 모두 접착 테이프 계열이라 커뮤니티는 통칭 “Duct Tape”으로 불렀다.

• maskingtape-alpha
• gaffertape-alpha
• packingtape-alpha

특히 한글·중국어·일본어 텍스트 렌더링이 압도적이라 아시아권 커뮤니티가 먼저 발견해 퍼뜨렸다. 며칠 뒤 세 변종은 아레나에서 조용히 제거됐고, “신모델 사전 테스트다”라는 해석이 정설로 굳어졌다. 2026-04-21 ChatGPT Images 2.0이 공식 출시되면서 “그 Duct Tape이 이거였다”가 확정됐다.

지금도 Arena Text-to-Image Overall 1위다. gpt-image-2 (medium) 1,512점, 2위 gemini-3.1-flash-image-preview 1,270점으로 +242점 차이가 난다. 공개 전 익명 모델로 먼저 화제가 됐고, 출시 후에도 리더보드 상단을 유지하고 있다.

그럼 세 변종은 각각 뭐였을까?

OpenAI는 세 코드명의 의미를 공개하지 않았다. 커뮤니티 해석은 크게 두 갈래다.

가설 A: 기능 분화설

가설 B: 모드 매핑설

세 변종과 실제 출시 모델의 1:1 대응은 공개되지 않았다. 출시 후 공개된 API에서는 gpt-image-2 단일 모델과 quality 파라미터(low / medium / high)가 핵심이다.

DALL·E에서 GPT Image로

먼저 이름부터 정리해야 한다. DALL·E는 OpenAI의 이전 이미지 생성 모델 라인이고, GPT Image는 2025년부터 ChatGPT·API·Codex 이미지 생성을 묶어 가는 새 모델 패밀리다.

핵심 변화는 “DALL·E 이름이 GPT Image로 바뀌었다”가 아니다. DALL·E 3까지는 이미지 전용 모델에 ChatGPT가 프롬프트를 잘 써주는 느낌이 강했다면, GPT Image 계열은 생성·편집·참조 이미지·멀티턴 대화를 하나의 작업 흐름으로 묶는 쪽으로 진화하고 있다.

DALL·E API 스냅샷은 2026-05-12부로 종료된다. 새 이미지 생성 작업은 이제 gpt-image-2를 기본 선택지로 두고 보는 편이 자연스럽다.

무엇이 바뀌었나: 개선의 네 축

수치·공식 제약 근거는 다음과 같다.

• LMArena Image Arena 1,512 Elo, 2위와 +242pt 마진
• gpt-image-2는 최대 edge 3840px, 비율 3:1 이내, 총 8,294,400px 이하의 유연한 해상도 지원
• OpenAI 프롬프트 가이드는 핵심 능력으로 photorealism, identity preservation, reliable text rendering, structured visuals, real-world knowledge/reasoning을 명시

이미지 생성에서 말하는 Reasoning

여기서 reasoning은 모델의 생각을 문장으로 보여준다는 뜻이 아니다. 사용자의 요청을 이미지로 바꾸기 전에 무엇을 그려야 하는지, 어떤 레이아웃이 맞는지, 어떤 정보와 맥락을 유지해야 하는지를 더 잘 구조화한다는 의미에 가깝다.

실제 API 흐름은 다음처럼 이해하면 된다.

핵심은 “이미지 모델이 속으로 생각한다”가 아니라 이미지 생성이 대화형 작업 흐름 안으로 들어왔다는 점이다. 이제 사용자는 프롬프트를 한 번 던지는 사람이 아니라, 결과물을 보며 계속 디렉팅하는 사람에 가까워진다.

어디서, 누가, 어떻게 쓰나

플랫폼

API 핵심 옵션

입출력 포맷

지원 입력은 텍스트 프롬프트(다국어 포함), 참조 이미지(style reference), 마스크(inpaint), 멀티턴 대화형 편집이다. 출력은 다음과 같이 조절한다.

대표 활용

가격

API 가격은 text token, image input token, image output token을 합산한다. 첫 추산은 “이미지 한 장당 대략 얼마인가”에서 시작하면 된다.

참조 이미지가 많거나 멀티턴 편집이 길어질수록 입력 토큰 비용도 함께 늘어난다.

공식이 밀고 있는 활용 카테고리

한계와 주의점

Google Nano Banana Pro, Midjourney, Ideogram 등 이미지 생성 경쟁자도 공격적이다. gpt-image-2의 우위는 오래 고정되지 않을 수 있다. 특히 텍스트 렌더링 격차는 빠르게 좁혀질 가능성이 높다.

결론

DALL·E 3의 최대 약점이었던 텍스트·다국어·일관성을 크게 개선했고, reasoning 모델과 이미지 생성 도구가 결합된 agentic image workflow를 주류화했다.

이미지 생성은 더 이상 “프롬프트 한 줄로 결과를 받는” 작업이 아니다. 대화 맥락 위에서 디렉팅하고 편집하는 흐름으로 옮겨가고 있고, gpt-image-2는 그 흐름의 현재 기준선이다.

참고 자료

1차 공식 자료

• DALL·E: Creating images from text
• DALL·E 2
• DALL·E 3
• Introducing 4o Image Generation
• Introducing our latest image generation model in the API
• The new ChatGPT Images is here
• Introducing ChatGPT Images 2.0
• Image generation guide
• gpt-image-2 모델 페이지
• GPT Image Generation Models Prompting Guide
• Introducing gpt-image-2: available in API and Codex

외부 평가 자료

• TechCrunch: ChatGPT’s new Images 2.0 model is surprisingly good at generating text
• The Decoder: ChatGPT Images 2.0 thinks before it generates
• VentureBeat: Multilingual text, infographics, slides, maps, even manga seemingly flawlessly
• Axios: Images in ChatGPT major update
• The New Stack: ChatGPT Images 2.0
• DEV Community: OpenAI’s ‘duct-tape’ model appeared on Arena, then vanished

이번 글에서는 세 가지 질문에 답한다.

• Opus 4.6과 비교해 실제로 무엇이 좋아졌는가?
• GPT-5.4, Gemini 3.1 Pro, Mythos Preview와 비교하면 어디쯤인가?
• 어떤 작업에서는 오히려 기대치를 낮춰야 하는가?

Weekly Tech Trend Talk 스터디(26.04.23)

이번 세대의 개선 축

Opus 4.7이 내세우는 변화는 네 가지로 압축된다. 질문은 “이전보다 똑똑해졌나?”가 아니라 “어떤 업무를 덜 감독하고 맡길 수 있게 됐나?”에 가깝다.

Opus 4.6 대비 변화

공식 메인 벤치마크 표부터 본다.

전반적 상승이 아니라 특정 영역에서 선명하게 올랐다.

가장 눈에 띄는 것은 SWE-bench Pro와 CharXiv다. 전자는 “진짜 개발 일을 맡길 수 있는가”, 후자는 고해상도 비전이라는 모델 레벨 변화와 직접 연결된다. SWE-bench Verified는 상위 모델들이 포화 구간에 들어가고 있어, 단독 점수보다 어려운 작업형 벤치마크와 같이 읽는 편이 낫다.

다른 모델과 비교한 순위

Artificial Analysis Intelligence Index 기준 Opus 4.7은 57.3점이다. Gemini 3.1 Pro 57.2, GPT-5.4 56.8과 95% 신뢰구간 ±1 안에 들어가 사실상 공동 1위 그룹으로 해석한다.

BenchLM 리더보드도 같이 보면 위치가 더 뚜렷해진다. 공개된 exact-source benchmark 결과만 집계하는 사이트인데, Mythos Preview가 1위로 올라와 있고 Opus 4.7이 바로 그 뒤를 잇는다.

BenchLM은 provisional #2/111, verified #2/15로 표시한다. 단, 공개 exact-source benchmark가 아직 13개뿐이라 확정 순위가 아니라 현재 공개 지표 기반 상위권 위치로 읽는 편이 안전하다. Mythos Preview는 제한 공개 모델이므로 일반 사용자 기준에서는 Opus 4.7이 사실상 최상단으로 볼 수 있다.

강점

1. 실제 업무형 에이전트 — GDPval-AA 1위

GDPval-AA는 44개 직업·9개 산업의 실제 지식 노동 태스크를 agentic loop로 평가한다. Opus 4.7은 1,753 Elo로 1위, 다음 그룹(Sonnet 4.6, GPT-5.4)보다 약 79 Elo 앞선다.

퀴즈형 지식이 아니라 웹·셸을 쓰며 산출물을 만드는 업무에 강하다는 뜻이다. 기대할 변화도 “질문에 잘 답한다”보다 “기획·조사·작성·검증이 섞인 업무를 더 오래 맡긴다” 쪽이다.

2. 코딩 에이전트와 도구 사용

공식 표 기준 Opus 4.7은 일반 공개 모델 중 SWE-bench Pro, SWE-bench Verified, MCP-Atlas에서 강하다. 특히 MCP-Atlas는 복잡한 multi-turn tool-calling을 본다는 점에서 Claude Code 같은 도구의 체감 강점과 직결된다.

코드를 한 번에 쓰는 능력보다 작업을 나누고, 도구를 부르고, 실패를 회복하고, 검증까지 이어가는 능력이 올라간 쪽이다.

3. 고해상도 비전과 시각 추론

이미지 입력 한계가 1568px → 2576px(약 3.75MP)로 확장됐다. 변화는 CharXiv에서 그대로 드러난다.

앞으로 차트·논문 그림·대시보드·앱 화면·스크린샷 디버깅에서 이전보다 높은 기대를 걸 수 있다.

4. 모르면 멈추는 능력

AA-Omniscience 결과에서 Opus 4.7은 Opus 4.6보다 hallucination rate가 크게 내려갔다. 정확도가 극적으로 오른 게 아니라, 모르는 문제에서 더 자주 abstain하는 쪽에 가깝다.

업무용 에이전트에서는 “그럴듯한 오답”보다 “자료 부족 명시 + 다음 확인 단계 제안”이 훨씬 안전하다.

약점과 주의점

공식 발표만 보면 약점이 잘 보이지 않는다. 외부 자료와 표에서 후퇴하거나 밀리는 지점을 따로 봐야 한다.

1. 검색형 에이전트는 오히려 하락

BrowseComp는 multi-step web research 지표인데, Opus 4.6 83.7% → Opus 4.7 79.3%로 -4.4pp 하락했다.

에이전트 전반에서 무조건 상위호환이 아니다. 웹 검색을 많이 하고 여러 페이지를 종합하는 리서치 워크플로우라면 GPT-5.4나 Gemini 3.1 Pro가 더 맞을 수 있다.

2. 비용은 같지만 사용량이 달라질 수 있다

가격표는 Opus 4.6과 동일($5 / $25)이지만, 마이그레이션 가이드에 따르면 tokenizer가 바뀌어서 같은 입력이 최대 약 1.35배 더 많은 토큰으로 계산될 수 있다. xhigh·max effort는 더 오래 생각하고 출력 토큰을 더 쓴다.

단, Artificial Analysis 자체 측정에서 Intelligence Index 실행 비용은 오히려 낮게 나왔다. Opus 4.7 ≈ $4,406 < Opus 4.6 ≈ $4,970로, 더 높은 점수를 내면서 출력 토큰을 덜 썼다.

tokenizer가 바뀌어서 같은 출력이 더 비싸 보일 수 있지만, 더 효율적인 처리 덕에 실제 쓰는 토큰의 절대량이 오히려 줄어들 수도 있다. 최종 비용은 workload, effort level, 이미지 사용량, 캐시 사용 여부에 따라 갈린다.

3. 마이그레이션 리스크

Opus 4.7은 이전보다 지시를 문자 그대로 따른다. 잘 만든 프롬프트에서는 장점이지만, 기존 프롬프트가 모델의 관대한 해석에 기대고 있었다면 결과가 달라질 수 있다.

production에서는 모델 ID만 바꾸지 말고, 대표 작업에 대한 regression eval을 먼저 돌리는 편이 맞다.

실전 사용 가이드

기대치를 올려도 되는 작업

기대치를 낮춰야 할 작업

결론

Claude Opus 4.7은 Anthropic이 어디에 집중하는지를 보여주는 모델이다. 예쁘게 답하는 챗봇보다, 코드를 고치고·도구를 쓰고·긴 작업을 끝까지 가져가고·모르면 멈추는 업무형 에이전트 쪽에 무게가 실려 있다.

다만 “최강 모델 하나로 통일”이라고 말하기엔 조심해야 한다. Artificial Analysis 기준으로는 GPT-5.4, Gemini 3.1 Pro와 사실상 공동 1위 그룹이고, 웹 리서치처럼 오히려 후퇴한 영역도 있다.

빠르면 오늘 밤 GPT-5.5가 공개될 예정이다. 5.5가 나오면 이 순위는 곧바로 뒤집힐 가능성이 농후하다.

참고 자료

• Introducing Claude Opus 4.7
• Claude Opus 제품 페이지
• Models overview
• Migration guide
• Introducing Anthropic’s Claude Opus 4.7 model in Amazon Bedrock
• Artificial Analysis - Opus 4.7: Everything you need to know
• BenchLM - Claude Opus 4.7

기본 스킬의 기준선

이번 글에서 말하는 기본 스킬은 공식 GitHub kepano/obsidian-skills를 기준으로 잡는다. README를 보면 현재 공식 팩에는 5개가 들어 있다. 이 다섯 개는 Obsidian을 다루는 바닥 능력을 넓게 깔아 주는 층에 가깝다. 노트 문법, Bases, Canvas, CLI, 웹 본문 정리처럼 “공통으로 필요한 일”은 대부분 여기서 출발한다.

여기까지만 보면 꽤 든든하다. 실제로도 이 다섯 개만으로 할 수 있는 일이 적지 않다. 다만 이 스킬들은 어디까지나 Obsidian을 다루는 공용 능력이다. 내 vault의 기준 문서가 무엇인지, 어떤 정보는 장기 메모로 올리고 어떤 것은 그냥 메모에 남겨야 하는지 같은 판단까지 대신해 주지는 않는다.

전체 스킬 맵

지금 내가 실제로 굴리는 구성은 단순하다. 공식 기본 스킬 5개가 바닥에 있고, 그 위에 직접 만든 비서 운영 스킬 2개가 얹혀 있다. 위층은 공용 능력이고, 아래층은 내 운영 방식이다.

표로 보면 그냥 7개 나열처럼 보이지만, 성격은 꽤 다르다. 기본 스킬은 범위가 넓은 대신 얕다. 반대로 비서 운영 스킬은 범위는 좁지만 훨씬 깊다. 실제로는 읽어야 하는 기준 문서와 응답 형식까지 한 덩어리로 붙는다.

비서 운영 스킬이 붙는 자리

기본 스킬만으로도 꽤 많은 일은 된다. 그런데 어느 지점부터는 금방 한계가 보인다. 파일 포맷을 아는 것과, 내 vault에서 무엇이 기준 문서인지 아는 것은 완전히 다른 일이기 때문이다.

내가 직접 써 보며 가장 크게 느낀 차이도 여기였다. 기본 스킬은 “이 파일이 무엇인가”를 안다. 비서 운영 스킬은 “이 vault에서는 무엇을 먼저 읽고, 어디에 적고, 무엇은 섣불리 올리면 안 되는가”를 안다. 개인 비서처럼 오래 쓰려면 결국 뒤쪽이 필요해진다.

스킬을 언제 만들지도 여기서 갈린다. 그냥 시켜도 늘 잘 되는 일이라면 굳이 스킬로 만들지 않아도 된다. 반대로 원하는 능력은 분명한데 결과가 계속 마음에 들지 않아서, 피드백을 주고 결과물을 여러 번 고치게 되는 일이 있다. 내 경우에는 그런 작업이야말로 스킬 후보였다. 몇 번의 피드백 끝에 “이 정도면 내가 원하던 결과다” 싶은 상태가 되면, 그때까지의 피드백과 최종 결과물을 바탕으로 “다음에도 같은 요구가 오면 이렇게 처리해 달라”고 정리해서 스킬로 올리는 쪽이 가장 잘 맞았다.

비서 운영 스킬 사례

내가 직접 붙인 비서 운영 스킬은 daily-note-followup와 organize-instructions 두 개다. 둘 다 공용 스킬 위에서 움직이지만, 실제 느낌은 “프롬프트 두 개”와는 거리가 멀다. 차라리 작은 작업 패키지에 가깝다. SKILL.md가 있고, 세부 판단을 담은 참조 문서가 있고, 필요하면 agents/openai.yaml까지 붙는다.

daily-note-followup

이 스킬은 이름만 보면 “일기 정리” 정도로 들린다. 그런데 실제로 뜯어 보면 훨씬 넓다. 완성된 일간 기록 하나를 읽고 나서, 어디까지 자동 반영할지 정해 둔 운영 절차에 가깝다. 일기 교정, 일정 보정, 장기 메모 승격, TODO 생성, 장소 노트 승격, 미래 노트 생성이 한 흐름으로 이어진다.

폴더 구조도 이렇게 생겨 있다. SKILL.md만 있는 게 아니라, 판단 기준과 예시가 references 아래로 빠져 있다.

daily-note-followup/
├── SKILL.md
├── agents/openai.yaml
└── references/
    ├── action-rubric.md
    ├── examples.md
    └── place-note-pattern.md

이 구조를 보면 역할도 바로 나뉜다. SKILL.md는 메인 흐름을 잡고, action-rubric.md는 자동 반영 기준과 섹션 경계를 더 세게 못 박는다. place-note-pattern.md는 장소 노트를 어떻게 만들지 패턴을 잡아 주고, examples.md는 실제 결과 모양을 맞출 때 참고점으로 쓴다.

SKILL.md의 가운데 부분만 추리면 흐름은 대략 이렇게 읽힌다.

1. Read the target daily note first.
2. Locate the user-only block and the `## 일기` section before touching anything else.
7. Sync the agent-managed sections after diary correction.
8. Before mutating the vault, use these canonical references:
   - `00_agent_docs/플레이북/Base Board 작업 지침.md`
   - `00_agent_docs/플레이북/일일기록 일정 작성 플레이북.md`
   - `00_agent_docs/플레이북/개인 정보 업데이트 플레이북.md`
9. Apply the repository-specific rules in `references/action-rubric.md`.
17. Create or update `06_TODO`, future daily notes, `10_아이디어`, and month or year hubs only when the rubric says the evidence is strong enough.

이 발췌에서 중요한 건 문장이 길다는 게 아니다. 스킬이 혼자 판단하지 않는다는 점이다. 먼저 일간 기록을 읽고, 그다음 기준 문서를 읽고, 그 기준 위에서만 움직인다. 그래서 이 스킬은 공용으로 돌리기 어렵다. 일간 기록에서 무엇을 장기 메모로 올릴지, 어떤 TODO를 자동 생성할지, ## 메모와 ## 에이전트 메모를 어디서 나눌지는 결국 내 운영 규칙이기 때문이다.

하위 참조 문서는 이 판단을 더 촘촘하게 만든다. 예를 들어 action-rubric.md는 섹션 경계와 자동 반영 기준을 이렇게 적어 둔다.

- `## 일정`: Day Planner-compatible list only.
- `## 메모`: Supplementary facts not already covered in the diary.
- `## 에이전트 메모`: agent's own work log and future reference observations.
- Auto-create a TODO only when the next action, actor, and intent are clear.

references 내부 파일도 역할이 나뉘어 있다.

• action-rubric.md: 자동 반영 범위, 섹션 경계, TODO 생성 조건처럼 가장 자주 흔들리는 판단 기준을 잡는다.
• examples.md: 이 스킬이 언제 발동하고 어떤 결과 모양으로 끝나야 하는지 예시로 맞춘다.
• place-note-pattern.md: 장소 노트를 언제 승격하고 어떤 구조로 만들지 패턴을 정리한다.

그리고 agents/openai.yaml은 로직보다 표면을 다듬는 층에 가깝다. 여기서 이 스킬이 어떤 이름으로 보이고, 암묵 호출을 열어둘지 같은 사용감을 정리한다.

interface:
  display_name: "일기 정리"
policy:
  allow_implicit_invocation: true

organize-instructions

organize-instructions는 2편과 3편에서 계속 이야기했던 문제를 실제로 다루는 스킬이다. 문서가 많아졌을 때 무엇이 라우터이고, 무엇이 기준 문서이고, detail을 어디로 내려야 하는지를 감으로 정리하지 않게 해 준다. 한마디로 하면 지침 구조를 점검하는 정리 스킬이다.

이 스킬도 마찬가지로, 프롬프트 한 장이라기보다 작은 점검 도구 세트에 가깝다.

organize-instructions/
├── SKILL.md
├── agents/openai.yaml
└── references/
    ├── classification-framework.md
    ├── discovery-audit-workflow.md
    ├── local-example-obsidian-vault.md
    └── output-contract.md

여기서는 discovery-audit-workflow.md가 실제 지침 면을 어떻게 훑을지 안내하고, classification-framework.md가 규칙을 어떤 층으로 분류할지 잡아 준다. output-contract.md는 결과를 어떤 형식으로 내야 하는지 정리하고, local-example-obsidian-vault.md는 필요할 때만 참고하는 예시 축에 가깝다.

이쪽 SKILL.md도 중심 흐름은 꽤 분명하다.

1. Discover the instruction surface.
2. Classify each rule before moving it.
3. Diagnose the current problems.
4. Design the target architecture.
5. Translate the design into concrete actions.
6. Produce the final output with the correct contract.

내가 이 스킬을 따로 둔 이유도 여기에 있다. 단순히 “문서를 정리한다”가 아니라, 발견하고, 분류하고, 문제를 짚고, 구조를 다시 그리는 순서를 강제하기 때문이다. 그냥 손에 잡히는 파일부터 옮기기 시작하면 중복만 더 늘어날 때가 많았다.

하위 참조 문서는 이 흐름을 더 구체적으로 잘라 준다. discovery-audit-workflow.md만 봐도, 처음부터 파일을 옮기지 말고 실제 지침 면을 먼저 훑으라고 못 박는다.

1. Top-level router docs
2. Named operating areas
3. Task-specific instruction packages
4. Preference and operating context docs

references 내부 파일도 각각 맡는 역할이 다르다.

• discovery-audit-workflow.md: 실제 지침 표면을 어떤 순서로 훑고 inventory할지 정리한다.
• classification-framework.md: 발견한 규칙을 어떤 층과 문서로 보낼지 분류 기준을 잡는다.
• output-contract.md: 점검 결과를 어떤 형식으로 정리해 내놓을지 맞춘다.
• local-example-obsidian-vault.md: 필요할 때만 참고하는 예시 자료로, 실제 구조를 감 잡는 데 쓴다.

이 스킬은 daily-note-followup와 달리 암묵 호출을 열어두지 않았다. 매일 도는 루틴이라기보다, “지금 지침 구조를 점검해야겠다” 싶을 때 일부러 꺼내는 도구에 더 가깝기 때문이다.

interface:
  display_name: "Organize Instructions"
policy:
  allow_implicit_invocation: false

직접 커스텀 스킬을 만들어야 하는 시점

스킬은 많다고 좋은 게 아니다. 먼저 내 비서에게 어떤 능력이 필요한지 파악하는 게 먼저다. 그냥 시켜도 늘 잘 되는 일이라면 굳이 스킬로 고정할 필요가 없다. 내가 실제로 스킬을 만들게 되는 시점은, 결과가 계속 흔들리거나 같은 작업을 반복해서 시키게 될 때였다.

에이전트의 결과물이 마음에 안 들 때

결과가 조금 아쉽다고 바로 스킬을 만들지는 않는다. 보통은 먼저 피드백을 주면서 내가 원하는 결과가 나올 때까지 계속 다듬는다. 이 단계가 중요한 이유는, 내가 원하는 결과물의 기준이 아직 선명하지 않을 때가 많기 때문이다.

내가 보통 거치는 흐름은 이렇다.

• 먼저 그냥 시켜 본다.
• 결과가 자꾸 흔들리면 피드백을 주면서 원하는 모양으로 계속 고친다.
• 몇 번 반복한 뒤 “이 정도면 다음에도 같은 요구를 잘 처리하겠다” 싶은 결과물이 나온다.
• 그때까지 쌓인 피드백과 최종 결과물을 바탕으로 플레이북을 만든다.

이때 플레이북에 남기는 재료도 꽤 분명하다.

• 지금까지의 피드백
• 대화 내역
• 실제 작업 흐름
• 최종 결과물

플레이북을 먼저 만드는 이유도 분명하다.

• 시행착오를 줄이기 위해
• 다음에 같은 실수를 하지 않게 하기 위해
• 같은 요구가 다시 왔을 때 기준 문서로 삼기 위해

즉, 스킬보다 플레이북이 먼저 생기고, 스킬은 그 플레이북이 반복 실행 단위가 될 때 올라간다.

반복해서 시키는 작업이 생겼을 때

어떤 작업은 한 번 잘 끝나는 것으로는 부족하다. 다음 주에도, 다음 달에도 비슷한 요청을 또 하게 된다. 이런 작업은 단순 플레이북을 넘어 스킬 후보가 된다.

여기서 내가 나누는 기준은 비교적 단순하다. 플레이북은 사람이 읽어도 되는 절차 문서이고, 스킬은 에이전트가 명시적으로 호출해서 같은 작업을 반복 처리하게 만드는 실행 단위다.

특히 아래 조건이 겹치면 스킬로 올리기 좋았다.

• 요청 형태가 반복된다.
• 원하는 결과물 모양이 비교적 명확하다.
• 이미 플레이북과 피드백이 쌓여 있다.
• 다음에도 같은 기준으로 처리되길 원한다.

내 경우에는 이런 작업이 쌓일 때, 기존 플레이북과 원하는 결과물을 바탕으로 하나의 스킬로 승화시키는 편이 잘 맞았다. 그러면 다음부터는 매번 긴 설명을 다시 하지 않아도 되고, 비서도 같은 기준 위에서 움직이기 쉬워진다.

여기서 중요한 건 두 가지다. 하나는 스킬을 너무 빨리 만들지 않는 것이다. 그냥 시켜도 잘 되는 일은 굳이 스킬로 고정할 필요가 없다. 다른 하나는 공용 기본 스킬과 역할을 겹치지 않는 것이다. 기본 스킬이 이미 markdown, .base, .canvas, CLI, 웹 인입을 맡아주고 있다면, 비서 운영 스킬은 그 위에 내 판단 기준과 참조 문서만 얹는 편이 훨씬 깔끔하다. 모든 걸 로컬 스킬 하나에 우겨 넣기 시작하면 금방 다시 두꺼워진다.

마무리

지금 돌아보면 공식 기본 스킬 5개는 꽤 좋은 출발선이었다. 다만 거기서 멈췄다면 그냥 “Obsidian을 잘 다루는 AI” 정도였을 것이다. 내 vault에서 실제로 오래 쓰는 개인 비서가 되기 시작한 건, 직접 만든 비서 운영 스킬이 붙은 뒤였다.

결국 기본 스킬은 바닥이고, 비서 운영 스킬은 내 운영 방식이다. 내가 지금 쓰는 구조도 두 층을 섞기보다 겹쳐 놓는 쪽에 가깝다. 기본 스킬은 공용 능력을 맡고, 비서 운영 스킬은 내 기준 문서와 작업 습관을 맡는다. 지금으로서는 그 분리가 가장 덜 흔들린다.

작업 공간으로서의 Obsidian

이번 글은 실제로 남긴 핵심 플러그인 여섯 개가 각각 무엇을 맡고, 같이 붙었을 때 어떻게 작업 공간이 되는지를 정리한 글이다. Obsidian은 파일을 저장하는 앱에 그치지 않고, 이미 갖춰진 탐색 UI, 링크 구조, 사이드바, 뷰어, 플러그인 확장점 위에 작업 흐름을 얹을 수 있다. 그래서 에이전트도 바닥부터 앱을 다시 만들 필요 없이, 이미 만들어진 인터페이스와 고정된 규칙 위에서 움직이면 된다.

이 위에는 전역 Obsidian 스킬이 기본 읽기·쓰기 능력을 얹고, Vault 전용 로컬 스킬이 내 작업 절차를 얹는다. 다만 이번 글의 중심은 실제 플러그인 구성이고, 전역/로컬 스킬의 분업은 5편에서 따로 정리하겠다.

기록 플러그인 구성

기록 쪽에서는 Periodic Notes, Templater, Day Planner 세 개가 한 묶음으로 움직인다. 먼저 각 플러그인이 하는 일을 짧게 보면 아래와 같다.

Periodic Notes와 Templater

기록 흐름은 노트 생성 규칙과 기본 섹션이 고정될 때 비로소 에이전트 친화적으로 바뀐다. Periodic Notes는 날짜 기반 생성 경로를 고정하고, Templater는 그 경로에 맞는 템플릿을 자동 적용한다. 이 둘이 같이 붙어 있어야 일간 기록이 단순한 빈 파일이 아니라, 처음부터 일기, 일정, 메모, 에이전트 메모 같은 고정된 구조를 가진 작업 단위가 된다.

실제 설정은 거의 이렇게 읽힌다.

// periodic-notes
"daily": {
  "enabled": true,
  "format": "YYYY/MM/YYYY-MM-DD",
  "folder": "12_일일기록",
  "template": "_Templates/일일기록 일간 노트.md"
}

// templater-obsidian
{
  "regex": "^12_일일기록/\\d{4}/\\d{2}/\\d{4}-\\d{2}-\\d{2}\\.md$",
  "template": "_Templates/일일기록 일간 노트.md"
}

이 조합의 좋은 점은 “노트를 자동 생성한다”보다 “생성 규칙을 예측 가능하게 만든다”에 있다. calendar는 여기서 날짜 클릭과 이동을 도와주는 보조 유틸에 가깝다. 편하긴 하지만, 이 흐름의 핵심은 어디까지나 Periodic Notes + Templater다.

실제 일간 템플릿도 같은 방향이다.

## 일기

## 일정

## 메모

## 에이전트 메모

## 사진

섹션 구조가 고정되면 사용자는 입력을 덜 고민하게 되고, 에이전트는 어디를 읽고 어디에 써야 하는지를 덜 틀리게 된다.

Day Planner

obsidian-day-planner는 여기서 기록을 다시 실행 인터페이스로 바꾼다. 이 vault에서는 일간 노트의 ## 일정을 표준 섹션으로 쓰고, Day Planner가 그 섹션을 읽어 타임라인으로 보여준다.

내가 이 플러그인을 계속 남겨둔 이유는 AI 기능이 있어서가 아니다. 오히려 반대다. 에이전트는 markdown만 정리하면 되고, 화면 출력은 Day Planner가 맡는다. 그러면 사용자는 긴 노트 대신 “지금 무엇을 해야 하는가”를 바로 볼 수 있다.

실행 플러그인 구성

실행 쪽에서는 Base Board와 Dataview가 각각 시각화와 조회를 맡는다. 둘 다 데이터를 따로 소유하지 않고 note와 frontmatter 위에 읽기 레이어를 얹는다는 점이 핵심이다.

Base Board

실행 흐름은 UI가 데이터를 소유하지 않을 때 오래 간다. 이 점에서 Base Board는 생각보다 중요한 플러그인이다. 보드를 따로 관리하는 데이터베이스가 아니라, markdown 파일과 frontmatter를 읽어 칸반 뷰를 얹는 레이어이기 때문이다.

실제 .base 파일을 보면 보드가 무엇을 읽고 어떻게 묶는지 바로 드러난다.

filters:
  and:
    - file.inFolder("06_TODO")
    - status != null
views:
  - type: kanban
    name: TODO 칸반
    groupBy:
      property: status
    boardColumns:
      - 시작 전
      - 진행 중
      - 완료

즉 카드 이동의 본질은 보드를 움직이는 일이 아니라, 결국 status 같은 frontmatter 값을 바꾸는 일이다. 그래서 에이전트도 보드 UI 자체를 조작하는 쪽보다 markdown 파일과 속성 값을 직접 다루는 쪽이 더 안정적이다.

TODO 템플릿도 이 원칙을 그대로 따른다.

---
tags:
  - <% tp.file.folder(true).split("/").pop() %>
date: <% tp.date.now("YYYY-MM-DD") %>
scheduled_date:
completed_date:
protected: false
status: 시작 전
important: false
kanban_order: 0
---

이렇게 보면 Base Board의 장점은 예쁜 칸반이 아니라, “파일이 곧 데이터”라는 사실을 깨지 않는 데 있다.

Dataview

Dataview는 여기서 조회 레이어를 보강한다. Bases만으로는 어려운 동적 목록, 조건식, 집계, 역링크 기반 조회를 메워 주기 때문이다. 실제로는 특정 폴더의 TODO를 날짜순으로 다시 모아 보거나, 속성 기준으로 조건 목록을 만들 때 이 플러그인이 들어간다. 중요한 건 Dataview도 데이터 소유층이 아니라는 점이다. 실제 정보는 여전히 note와 frontmatter에 있고, Dataview는 그 위에 더 유연한 읽기 방법을 얹는다.

정리 플러그인 구성

정리 쪽에서는 obsidian-custom-attachment-location 하나가 훨씬 큰 역할을 한다. 눈에 가장 덜 띄는 플러그인이지만, 에이전트 운영에서 실패를 가장 많이 줄이는 레이어이기도 하다.

Custom Attachment Location

obsidian-custom-attachment-location은 붙여넣는 순간 첨부 파일 경로를 _attachments/YYYY/MM/DD/ 규칙에 맞춰 주고, 이 단순한 자동화가 생각보다 큰 차이를 만든다.

실제 설정은 거의 그대로 이렇게 잡혀 있다.

{
  "attachmentFolderPath": "_attachments/${date:{momentJsFormat:'YYYY'}}/${date:{momentJsFormat:'MM'}}/${date:{momentJsFormat:'DD'}}",
  "attachmentRenameMode": "All",
  "shouldHandleRenames": true,
  "generatedAttachmentFileName": "img-${date:{momentJsFormat:'YYYYMMDD-HHmmssSSS'}}"
}

여기에 첨부 운영 플레이북이 한 번 더 기준을 잡아 준다.

- 기본 저장 위치는 `_attachments/YYYY/MM/DD/`다.
- `_attachments/` 루트에 첨부 파일을 직접 두지 않는다.
- 파일명은 이미지 내용을 설명하는 짧은 한국어 캡션으로 정한다.
- 옮기거나 이름을 바꿨다면 해당 파일을 참조하는 링크도 함께 갱신한다.

이 흐름이 중요한 이유는, 에이전트가 이미지를 다룰 때 “이 파일이 왜 여기 있지?” 같은 의문을 줄여 주기 때문이다. 경로와 이름 규칙이 고정돼 있으면 첨부 정리는 플레이북 문제로 내려가고, 매번 즉흥적으로 판단할 일이 크게 줄어든다.

에이전트와의 결합

에이전트는 플러그인을 직접 이해해서 똑똑해지는 게 아니라, 플러그인이 만들어 준 고정된 규칙 위에서 덜 틀리게 된다. 이번 시리즈에서 계속 등장한 daily-note-followup가 좋은 예다.

로컬 스킬은 작업 절차를 캡슐화하지만, 그 스킬이 매번 제멋대로 파일을 만들지는 않는다. 실제로는 아래처럼 canonical reference를 먼저 읽고 움직인다.

- `00_agent_docs/플레이북/Base Board 작업 지침.md`
- `00_agent_docs/플레이북/일일기록 일정 작성 플레이북.md`
- `00_agent_docs/플레이북/개인 정보 업데이트 플레이북.md`
- `00_agent_docs/플레이북/13_my 업데이트 검증 체크리스트.md`

여기서 플러그인 조합의 의미가 분명해진다.

결국 전역 스킬은 Obsidian과 상호작용하는 기본 능력을 주고, 로컬 스킬은 내 Vault 규칙에 맞는 작업 절차를 얹는다. 이 둘이 잘 겹치려면, 그 사이에 있는 플러그인과 템플릿 규칙이 먼저 안정돼 있어야 한다.

운영 포인트

좋은 플러그인 구성이란 기능이 많은 구성이 아니라 authoritative copy가 분명한 구성이다. 실제로 오래 쓰다 보면 기능보다 “무엇을 기준 문서로 삼을 것인가”가 더 중요해진다.

지금 내 기준에서 “핵심 플러그인”은 예쁜 기능을 추가하는 것보다, 에이전트가 덜 틀리고 사용자는 덜 헤매게 만드는 쪽에 더 가깝다.

마무리

내가 Obsidian을 메모 앱이 아니라 작업 공간으로 계속 쓰는 이유는, 모든 걸 바닥부터 만들지 않아도 되기 때문이다. Periodic Notes, Templater, Day Planner, Base Board, Dataview, Custom Attachment Location처럼 각자 작은 역할을 맡은 플러그인들이 연결되면, 기록은 기록대로, 실행은 실행대로, 정리는 정리대로 서로 다른 책임을 분담하게 된다.

그 위에서 에이전트는 갑자기 똑똑해지는 게 아니라, 더 적게 틀리게 된다. 이 시리즈의 5편에서는 Obsidian 기본 능력을 주는 전역 스킬을 왜 전역에 두고, 내 개인 비서용 절차는 왜 로컬 스킬로 분리했는지 정리해 보려 한다.

들어가기에 앞서: 구조 다음에는 운영이 남는다

2편에서 구조를 나눴다면, 3편에서는 그 구조를 어떻게 덜 망가지게 유지하는지 본다. 폴더, 허브, AGENTS.md, 플레이북, 스킬을 한 번 만들어 둔다고 끝나지 않는다. 실제 운영에서는 새로운 사실이 일간 노트에 들어오고, 사용자 선호가 더 분명해지고, 작업 절차가 길어지면서 문서 역할이 계속 흔들린다.

이 글에서는 실제 vault의 AGENTS.md, 에이전트 문서 운영, 개인 정보 업데이트 플레이북, 장기 메모 업데이트 검증 체크리스트(13_my 업데이트 검증 체크리스트), daily-note-followup 스킬을 바탕으로, 공개 가능한 범위만 일반화해 excerpt로 보여준다. 핵심은 처음부터 완벽한 문서를 쓰는 것이 아니라, 사용할수록 더 얇고 정확한 문서 체계로 수선하는 것이다.

운영 원칙

문서 유지보수는 “무엇을 안다”보다 “이 정보가 어떤 종류인가”를 먼저 가르는 일에 가깝다. 그래서 새 입력이 오면 기록보다 분류를 먼저 한다.

기본 분기 표

세 가지 운영 기준

일회성인가 장기적인가

같은 정보라도 날짜성 사건이면 일단 일간 기록에 남기고, 날짜를 벗겨도 다시 참고할 가치가 있을 때만 장기 메모로 올린다. 장기 기억은 많이 쌓는 것보다, 나중에도 다시 쓸 수 있는 정보만 남기는 쪽이 더 중요하다.

전역 규칙인가 작업 절차인가

모든 일을 AGENTS.md에 적기 시작하면 금방 라우터가 아니라 매뉴얼이 된다. 전역 불변 규칙은 AGENTS.md, 단계별 수행 절차는 플레이북, 실제 실행 순서는 스킬로 내려보내는 분리가 핵심이다.

새 문서가 필요한가 기존 문서를 갱신하면 되는가

운영 문서는 새 파일을 만드는 비용도 크다. 같은 축의 정보가 이미 있으면 먼저 기존 문서에 흡수하고, 문서가 길어져 역할이 갈릴 때만 분리한다. 이 기준이 없으면 같은 규칙이 여러 파일에 중복되기 쉽다.

실전 장면 1: 새 정보가 생겼을 때

새 입력이 들어오면 바로 장기 메모를 고치는 게 아니라, 먼저 그것이 사건인지 패턴인지 해석 수정 신호인지 분리해야 한다. 이 단계가 빠지면 장기 메모가 일기 복사본처럼 변한다.

대표 excerpt

개인 정보 업데이트 플레이북의 기본 흐름

실제 플레이북을 단순화하면 아래 순서에 가깝다.

1. 입력의 핵심 사실을 먼저 뽑는다.
2. 이 입력이 일간 노트에 남길 사건인지부터 판단한다.
3. 관련 일간 기록과 기존 장기 메모 노트를 먼저 읽는다.
4. `새 사실`, `기존 패턴의 추가 증거`, `기존 해석 수정 신호`로 구분한다.
5. 장기 가치가 높을 때만 해당 대표 장기 메모 노트로 승격한다.

검증 체크리스트가 마지막에 묻는 질문

실제 체크리스트의 요지는 “썼는가”가 아니라 “비교했는가”다.

- 이번 입력은 새로운 사실인가, 기존 패턴의 추가 증거인가, 기존 해석 수정 신호인가
- 직접 비교해야 할 기존 노트는 무엇인가
- 이미 기록된 사건의 연속 설명은 아닌가
- 기존 기록과 충돌하거나 수정해야 할 내용은 없는가
- 일반화 가능한 성향이나 기준이 드러났다면 어느 상시 노트에 올려야 하는가

입력 분기 표

바로 적용할 규칙

• 일단 일간 기록에 남기고, 장기 가치가 확인되면 장기 메모로 승격한다.
• 장기 메모를 반영하기 전에는 같은 축의 기존 노트를 먼저 읽어 중복과 충돌을 확인한다.
• 새 입력이 해석을 바꾸는 신호라면, 상시 노트만 고치지 말고 분석 스냅샷까지 같이 볼지 판단한다.

실전 장면 2: 새 규칙이 생겼을 때

새 규칙은 많아지는데 AGENTS.md는 얇게 남아 있어야 한다. 그래서 규칙이 생길 때 가장 먼저 할 일은 “무슨 규칙인가”를 분류하는 것이다.

대표 excerpt

AGENTS.md가 직접 소유하는 것

실제 AGENTS.md의 역할을 줄이면 아래 세 줄로 요약된다.

- 역할은 `전역 불변 규칙 + 작업 트리거 + 정답 문서 안내`로 한정한다.
- 새 노트가 생겼다는 이유만으로 이 문서를 갱신하지 않는다.
- 폴더 역할, 경로 패턴, 예외 규칙, 문서 라우팅이 바뀔 때만 갱신한다.

운영 문서의 분류 기준

00_agent_docs/운영/에이전트 문서 운영.md는 새 규칙을 어디로 보낼지 이렇게 자른다.

- 전역 불변 규칙, 공통 경로 패턴, 예외 규칙이면 `AGENTS.md`
- 사용자 선호나 금지사항이면 `사용자 요구사항/`
- 단계별 수행 절차면 `플레이북/`
- 안정적인 환경 정보면 `장기 메모리/`

규칙 배치 표

바로 적용할 규칙

• AGENTS.md는 라우터처럼 쓰고, 설명서처럼 키우지 않는다.
• 같은 규칙이 반복 실행 절차라면 플레이북으로 내리고, 실제 순서는 스킬이 읽게 만든다.
• 새 규칙이 생겼을 때는 “어디를 고칠까”보다 “이 규칙의 수명이 얼마나 긴가”를 먼저 본다.

실전 장면 3: 스킬이 문서를 읽고 움직일 때

실제 운영에서는 스킬이 문서를 대신 읽고 움직이기 때문에, 문서 수정은 곧 실행 규칙 수정이 된다. 이 점을 이해하면 왜 AGENTS.md를 얇게 유지해야 하는지도 같이 설명된다.

대표 excerpt

daily-note-followup 스킬은 vault를 수정하기 전에 참조할 문서를 직접 지정해 둔다. 실제 스킬 파일의 핵심만 추리면 이런 구조다.

Before mutating the vault, use these canonical references:

- `00_agent_docs/플레이북/Base Board 작업 지침.md`
- `00_agent_docs/플레이북/일일기록 일정 작성 플레이북.md`
- `00_agent_docs/플레이북/개인 정보 업데이트 플레이북.md`
- `00_agent_docs/플레이북/13_my 업데이트 검증 체크리스트.md`

이 한 덩어리만 봐도 역할 분리가 분명하다. AGENTS.md는 작업 트리거와 섹션 경계만 알려주고, 실제 문법과 검증 질문은 플레이북과 체크리스트가 맡는다. 스킬은 그 문서를 읽는 실행기다.

문서 계층과 실행 계층

바로 적용할 규칙

• 작업 절차를 바꾸고 싶다면 스킬만 고치지 말고, 스킬이 읽는 기준 문서부터 점검한다.
• 실행 결과가 흔들릴 때는 스킬 프롬프트보다 플레이북과 체크리스트의 authoritative copy가 어디인지 먼저 본다.
• AGENTS.md까지 세부 절차를 밀어 올리지 않아야, 같은 규칙을 한 군데만 고쳐도 실행 계층 전체가 같이 정렬된다.

실전 장면 4: 문서가 비대해질 때

문서가 망가지는 신호는 보통 길이보다 역할 혼합에서 먼저 보인다. 조사 노트가 운영 문서에 섞이거나, 최신성이 높은 사실이 장기 메모리에 들어오기 시작하면 구조는 서서히 무너진다.

대표 excerpt

운영 문서가 막는 비대화

실제 운영 문서는 00_agent_docs에 이런 것을 두지 말라고 못 박는다.

- 주제별 조사 노트, 원시 데이터, 서비스별 산출물을 두지 않는다.
- 새 문서를 추가할 때는 먼저 기존 문서와 중복 여부를 확인한다.
- 내용이 폐기되었거나 더 이상 유효하지 않으면 삭제하거나 관련 문서에 통합한다.

장기 메모리에 남길 것과 빼야 할 것

장기 메모리 문서는 범위를 더 좁게 잡는다.

여기에 기록할 것

- 현재 vault의 핵심 구조와 운영 방식
- 자주 참조하는 메인 보드, 허브 노트, 기준 폴더
- 설치된 핵심 플러그인과 그 역할

기록하지 않을 것

- 최신성이 매우 높은 사실
- 특정 조사 작업의 결과
- 금방 폐기될 임시 판단

비대화 신호 표

바로 적용할 규칙

• 문서가 길어졌다는 사실보다, 한 문서가 두 역할 이상을 동시에 맡기 시작했는지를 먼저 본다.
• 지우는 것도 유지보수다. 더 이상 유효하지 않은 운영 정보는 남겨두지 말고 삭제하거나 통합한다.
• 장기 메모리는 “오래 남아야 하는 것”만 넣고, “최근에 알게 된 것”은 자동 승격하지 않는다.

마무리

Obsidian 개인 비서를 오래 쓰는 일은 좋은 구조를 한 번 만드는 것으로 끝나지 않는다. 새 정보가 들어올 때마다 사건과 장기 맥락을 구분하고, 새 규칙이 생길 때마다 전역 규칙과 작업 절차를 분리하고, 스킬이 읽는 기준 문서를 계속 authoritative copy로 유지해야 한다.

그래서 3편의 핵심은 거창한 유지보수 철학이 아니다. AGENTS.md는 얇게, 플레이북은 구체적으로, 장기 메모리는 좁게, 스킬은 그 문서를 읽는 실행기로 두는 것이다. 다음 편에서는 왜 VS Code 대신 Obsidian을 작업 공간으로 쓰는지, 그리고 실제로 남겨둔 핵심 플러그인들이 이 흐름을 어떻게 받쳐주는지 이어서 정리해보겠다.

llmfit Documentation - llmfit

Right-size LLM models to your system's RAM, CPU, and GPU

alexsjones-llmfit.mintlify.app

GitHub - AlexsJones/llmfit: Hundreds of models & providers. One command to find what runs on your hardware.

Hundreds of models & providers. One command to find what runs on your hardware. - AlexsJones/llmfit

github.com

llmfit이란

llmfit는 모델 실행기라기보다 하드웨어 적합도 기반 추천 도구에 가깝다. 여러 모델을 무작정 내려받아 시험해보기 전에, 현재 기기에서 가능성이 높은 후보를 먼저 정리해준다는 점이 핵심이다.

llmfit의 강점은 모델 자체의 절대 서열을 보여주는 데 있지 않다. 내 맥에서 어느 정도 여유로 돌아갈지, 어떤 용도에 더 맞는지까지 함께 보여주기 때문에 초기 선택 비용을 줄여준다. 특히 Ollama나 LM Studio에서 어떤 모델을 먼저 받아볼지 고민할 때 유용하다.

설치와 실행

macOS에서는 Homebrew 설치가 가장 단순하다. 설치 후 llmfit를 실행하면 바로 추천 모델 대시보드를 볼 수 있다.

brew install llmfit
llmfit

추천 모델 판단 기준

llmfit의 핵심은 컬럼을 전부 외우는 데 있지 않다. 실제로는 몇 개 지표만 잘 읽어도 추천 모델을 꽤 빠르게 좁힐 수 있다.

추천 모델 판단 순서

추천 모델은 될까를 먼저 보고, 그다음 빠를까와 버틸까를 확인하는 순서가 안정적이다.

Score는 절대 성능 점수라기보다 여러 요소를 합친 종합 추천 점수다. 그래서 본문에서는 Score를 “내 환경에서 균형이 좋은 후보를 찾는 지표” 정도로 읽고, 실제 계산식과 하위 점수 의미는 맨 뒤 번외에서 함께 보는 편이 흐름상 더 자연스럽다.

활용 흐름

llmfit는 모델을 직접 실행하는 도구라기보다, Ollama나 LM Studio에서 어떤 모델을 먼저 받아볼지 정하는 전 단계 도구로 쓰는 편이 가장 효율적이다.

결국 핵심은 무작정 모델을 받아보는 대신, 내 컴퓨터에서 구동 가능한 후보 중 우선순위가 높은 모델부터 좁혀보는 데 있다. llmfit는 이 과정에서 “될 모델”과 “당장 시도해볼 모델”을 분리해주는 필터 역할을 한다.

번외: 세부 지표 해설

본문에서는 Score를 해석하는 데 집중했고, 여기서는 계산 방식과 세부 표기를 따로 정리한다. 이런 정보는 유용하지만, 초반에 너무 먼저 들어가면 오히려 모델 선택 기준이 흐려질 수 있다.

Score 계산 방식

Score는 아래 네 가지 하위 점수의 가중합이다. llmfit는 이 값을 소수점 한 자리까지 반올림해서 보여준다.

Score = Quality × wq + Speed × ws + Fit × wf + Context × wc

하위 점수 의미

본문에서 보던 Score는 결국 이 네 가지 질문을 한 번에 요약한 값이다.

세부 계산 기준

• Speed: 체감 응답 속도와 가장 직접적으로 연결된다.
• Fit: 메모리 적합도를 가장 직접적으로 보여주는 지표다.
• Context: 긴 문맥을 얼마나 감당할 수 있는지를 뜻한다.
• Quality: 모델 자체 성능 기대치를 추정하는 축이다.

Fit은 50~80% 사용 구간을 가장 좋은 영역으로 보고 100점을 준다. Context는 목표 길이를 넘기면 100점, 절반 이상이면 70점, 그보다 작으면 30점으로 잡힌다. 이런 세부 규칙까지 보면 Score가 단순한 인기 순위가 아니라 현재 환경에 맞춘 계산 결과라는 점이 더 분명해진다.

Use Case별 가중치

용도에 따라 무엇을 더 중요하게 볼지가 다르기 때문에, 같은 모델이라도 Use Case가 바뀌면 점수 해석도 달라진다.

Coding과 Reasoning은 Quality 비중이 높고, Chat은 Speed 쪽 비중이 더 높다. 그래서 채팅용 모델과 코딩용 모델의 추천 순위가 다르게 나오는 것이 자연스럽다.

Quant 표기 해설

Quant가 헷갈리는 이유는 같은 모델이라도 어떤 런타임을 기준으로 보느냐에 따라 표기가 달라질 수 있기 때문이다. Apple Silicon에서는 MLX 쪽 표기가 자주 보이고, GGUF 계열에서는 Q4_K_M, Q5_K_M, Q8_0 같은 이름이 많이 보인다.

Q4_K_M 같은 이름은 “대략 4비트급 K-quant 계열의 M variant” 정도로 읽으면 충분하다. 중요한 건 표기 하나를 외우는 것보다, 현재 런타임과 하드웨어 기준으로 어떤 절충을 의미하는지 이해하는 것이다.

Apple Silicon 기준 해석

Apple Silicon에서는 llmfit가 MLX 쪽을 우선 보기 때문에, GGUF 계열 모델도 mlx-*처럼 보일 수 있다. 그래서 Quant는 혼자 보기보다 Fit, Score, Mode와 함께 읽는 편이 맞다.

결국 Quant는 고정된 절대값이 아니라 현재 하드웨어와 런타임 기준으로 읽어야 하는 값이다. 아주 단순하게 보면, 더 높은 비트와 덜 공격적인 양자화는 품질 쪽에 유리하고, 더 낮은 비트와 더 강한 압축은 메모리 쪽에 유리하지만 품질 손실 가능성도 커진다.

마무리

llmfit는 모델을 직접 돌리는 프로그램이라기보다, 내 맥에서 먼저 시도할 만한 로컬 LLM 후보를 좁혀주는 도구다. Fit, Score, tok/s*, Mem %를 먼저 읽고 후보를 줄인 뒤, 필요할 때만 번외의 세부 지표까지 확인하면 로컬 LLM 선택 과정의 시행착오를 꽤 줄일 수 있다.

AI가 똑똑해도 vault가 읽히지 않으면 운영비는 다시 사람에게 돌아온다. 2편에서는 내가 Obsidian vault를 어떻게 나눴고, AGENTS.md, 허브 노트, 00_agent_docs, 로컬 스킬을 어떤 계층으로 배치했는지를 실제 구조 그대로 보여주려 한다.

왜 구조가 먼저 필요한가

먼저 용어를 짧게 맞춰두자

이 글에서 자주 나오는 말만 먼저 짧게 정리하면 이렇다.

• 허브 노트: 한 폴더의 대표 진입점이 되는 안내 노트
• front matter: 노트 맨 위의 YAML 메타데이터 영역
• 위키링크: [[노트 이름]] 형태로 같은 vault 안 다른 노트를 가리키는 링크
• 스킬: 특정 작업 절차를 캡슐화한 에이전트용 로컬 작업 단위

AI도 읽는 vault여야 한다

보통 Obsidian 구조를 이야기할 때는 “내가 보기 편한가”를 먼저 생각한다. AI Agent를 붙이면 기준이 하나 더 생긴다. 사람이 아니라 에이전트도 이 vault를 읽고, 어디에 적어야 하고, 무엇을 건드리면 안 되는지 바로 판단할 수 있어야 한다.

이때 구조는 정리 취향이 아니라 인터페이스가 된다. 폴더 이름, 허브 노트, 전역 지침, 작업별 플레이북이 모두 “에이전트가 이 vault를 어떻게 읽을지”를 결정한다.

구조가 없으면 다시 사람이 정리한다

구조가 없을 때 생기는 문제는 꽤 단순하다.

• 새 노트가 루트나 임의의 폴더에 흩어진다.
• 비슷한 주제 노트가 중복 생성된다.
• TODO와 일반 노트의 경계가 흐려진다.
• 규칙이 바뀌어도 어디를 고쳐야 하는지 모른다.

결국 AI를 붙여도 사람이 다시 뒤에서 정리해야 한다. 내가 1편에서 말했던 “유지비가 너무 커지는 문제”가 구조 레벨에서 다시 돌아오는 셈이다.

내 vault를 이렇게 나눴다

최상위 폴더는 역할 단위로 자른다

내가 실제로 쓰는 구조의 핵심만 뽑으면 이렇다.

/
├── .agents/           # Codex용 로컬 스킬
├── .claude/           # Claude Code용 로컬 스킬
├── 00_agent_docs/     # AI 운영 문서
├── 06_TODO/           # Base Board 실데이터
├── 12_일일기록/       # 일간·월간·연간 기록
├── 13_my/             # 날짜를 벗겨도 남길 장기 메모
├── 14_플레이스/       # 장기적으로 남길 만한 장소 노트
├── _attachments/      # 이미지 첨부
├── CLAUDE.md
└── AGENTS.md

핵심은 “주제”보다 “역할”을 먼저 나누는 것이다.

• 12_일일기록/은 날짜순 원본 기록
• 13_my/는 날짜를 벗겨도 다시 참고할 장기 맥락
• 06_TODO/는 보드가 아니라 실제 마크다운 데이터
• 00_agent_docs/는 에이전트 운영 문서

이렇게 나눠두면 같은 정보라도 어디에 남겨야 하는지 판단이 쉬워진다. 예를 들어 오늘 일기에서 나온 장기 선호는 12_일일기록에 그대로 묻히지 않고 13_my로 승격할 수 있고, TODO는 일반 메모가 아니라 06_TODO/ 실파일로 들어가야 한다는 규칙이 구조 자체에 드러난다.

허브 노트는 README이자 MOC다

이 구조에서 중요한 건 폴더만이 아니다. 대부분의 폴더에는 허브 노트를 둔다. 허브 노트는 파일 목록이 아니라 “이 폴더가 무엇이고, 어디서부터 읽으면 되는지”를 알려주는 README + MOC(Map of Content)에 가깝다.

실제 00_agent_docs 허브는 이렇게 생겼다.

`00_agent_docs/` 폴더 허브이자 단일 진입점. 루트 지침은 [[AGENTS]]와 [[CLAUDE]]에서 확인한다.

## 바로 보기

- 사용자 요구사항: [[사용자 요구사항 메모]]
- 플레이북: [[Base Board 작업 지침]], [[일일기록 일정 작성 플레이북]]
- 장기 메모리: [[장기 메모리 메모]]
- 운영 원칙: [[에이전트 문서 운영]]

이게 중요한 이유는 에이전트가 폴더를 열었을 때 “전수 목록”보다 “대표 진입점”을 먼저 볼 수 있기 때문이다. 새 문서를 만들 때도 허브가 있으면 어디에 소속되는지 자연스럽게 정해진다.

코드블럭 안의 [[AGENTS]] 같은 표기는 Obsidian의 위키링크다. 일반 파일 경로보다 짧고, 허브끼리 연결 구조를 만들기 쉬워서 에이전트가 따라가기도 편하다.

허브가 잘 잡혀 있으면 그래프 뷰에서도 구조가 읽힌다. 아래처럼 허브가 중심이 되면, 단순히 노트가 많이 있는 vault가 아니라 어떤 묶음으로 운영되는지가 한눈에 드러난다.

에이전트는 어떤 문서를 읽고 움직이는가

AGENTS.md는 얇은 라우터다

내 vault에서 AGENTS.md는 모든 걸 설명하는 매뉴얼이 아니다. 역할을 아주 좁게 둔다.

## 이 문서의 역할

- 역할은 `전역 불변 규칙 + 작업 트리거 + 정답 문서 안내`로 한정한다.
- 길이는 대략 200줄 내외를 유지한다.
- 새 노트가 생겼다는 이유만으로 이 문서를 갱신하지 않는다.

즉, AGENTS.md는 얇아야 한다. 전역 작성 원칙, 폴더 구조, 예외 규칙, 문서 라우팅처럼 오래 안 바뀌는 것만 둔다. 세부 절차까지 다 넣기 시작하면 금방 비대해지고, 결국 아무도 안 읽는 문서가 된다.

세부 절차는 00_agent_docs/로 내린다

반복 작업에 필요한 상세 절차는 00_agent_docs/ 아래로 내린다. 실제 운영 문서도 이 기준을 분명히 적고 있다.

## 문서 분류 기준

- 전역 불변 규칙, 공통 경로 패턴, 예외 규칙이면 `AGENTS.md`, `CLAUDE.md`
- 사용자 선호나 금지사항이면 `사용자 요구사항/`
- 단계별 수행 절차면 `플레이북/`
- 안정적인 환경 정보면 `장기 메모리/`
- 폴더 운영 규칙, 인덱스, 유지보수 정책이면 `운영/`

이 계층을 두면 새 정보가 생겼을 때 어디에 적어야 하는지도 분명해진다. 예를 들어 “모든 일반 노트는 한국어로 쓴다”는 AGENTS.md에 갈 전역 규칙이지만, “Day Planner용 ## 일정은 어떤 문법으로 쓰는가”는 플레이북으로 내려가는 게 맞다.

작업별 운영 로직은 스킬에 둔다

여기서 더 아래로 내려가면 작업별 스킬이 있다. 지금 실제로 쓰고 있는 로컬 스킬은 이런 식이다.

.agents/skills/
├── daily-note-followup/
└── organize-instructions/

Claude Code 쪽도 같은 구조를 .claude/skills/에 맞춰 두고 있다. 핵심은 전역 지침 문서가 작업별 절차를 다 품지 않고, 정말 작업 특화된 로직은 스킬 폴더로 내려보낸다는 점이다.

그래서 AGENTS.md는 얇게 유지되고, 스킬은 작업별로 깊어질 수 있다. 이 분리가 없으면 top-level 문서가 금방 플레이북과 스킬의 역할까지 먹어버린다.

이 구조가 실제로 어떻게 동작하는가

예시 1: 새 TODO를 추가할 때

사용자가 할 일을 하나 추가해달라고 하면, 에이전트는 바로 카드 UI부터 건드리지 않는다. 먼저 AGENTS.md에서 TODO / Base Board 라우팅을 보고, 그다음 Base Board 작업 지침과 TODO LIST.base를 확인한다.

실제 .base 파일에는 이런 정보가 들어 있다.

filters:
  and:
    - file.inFolder("06_TODO")
    - status != null
views:
  - type: kanban
    boardColumns:
      - 시작 전
      - 진행 중
      - 완료

이걸 먼저 읽어야 status 값을 추측하지 않고 정확한 문자열로 넣을 수 있다. 즉, 구조가 있으면 에이전트는 “할 일을 어디에 만들지”뿐 아니라 “어떤 스키마로 만들어야 하는지”까지 찾을 수 있다.

실제 TODO 노트 쪽에는 이런 값이 front matter나 속성으로 들어가고, .base는 그 값을 읽어 보드처럼 보여준다.

예시 2: 일일기록을 후처리할 때

1편에서 다룬 daily-note-followup도 같은 구조 위에서 움직인다. AGENTS.md는 12_일일기록의 섹션 소유권과 기본 경계를 설명하고, 실제 일정 문법이나 시간 해석 같은 상세 규칙은 일일기록 일정 작성 플레이북으로 내려간다. 그리고 작업 전체 오케스트레이션은 daily-note-followup 스킬이 맡는다.

이렇게 나눠두면 한 작업 안에서도 역할이 분리된다.

• AGENTS.md: 전역 경계와 라우팅
• 플레이북: 세부 문법과 절차
• 스킬: 실제 작업 순서와 판단 흐름

그래서 한 파일에 모든 판단 로직을 몰아넣지 않아도 된다.

예시 3: 새 규칙이 생겼을 때

이 구조의 장점은 “새 규칙이 생겼을 때 어디를 고칠지”도 분명하다는 점이다.

예를 들어 어떤 규칙이 생겼다고 해보자. 그때 먼저 묻는 질문은 하나다. 이게 전역 불변 규칙인가, 사용자 선호인가, 작업 절차인가?

• 전역 불변 규칙이면 AGENTS.md
• 사용자 선호면 00_agent_docs/사용자 요구사항/
• 작업 절차면 00_agent_docs/플레이북/

이 분류가 있으면 규칙이 늘어나도 문서 체계가 쉽게 무너지지 않는다. 반대로 이 분류가 없으면 모든 게 AGENTS.md 한 파일로 몰리거나, 여기저기 중복된다.

마무리

2편에서 말하고 싶었던 건 단순하다. 좋은 Obsidian 개인 비서는 좋은 모델만으로 유지되지 않는다. AI가 읽을 수 있는 구조, 얇은 전역 지침, 허브 노트, 작업별 플레이북과 스킬이 함께 있어야 오래 간다.

1편에서 보여준 일일기록 -> 후처리 -> Day Planner 흐름도 결국 이 구조 위에서만 안정적으로 돌아간다. 구조는 보기 좋으라고 만드는 게 아니라, AI가 일관되게 일하기 위한 인터페이스다.

다음 편에서는 이 구조를 오래 굴리기 위해 규칙과 기억을 어떻게 유지보수하는지, 즉 지침이 커질 때 어떻게 정리하고 분리하는가 쪽을 이어서 다뤄보려고 한다.

Claude Code, Codex, OpenClaw 같은 로컬 파일 기반 AI Agent가 등장하면서 이 전제도 바뀌기 시작했다. Obsidian은 이제 내가 끝까지 직접 관리해야 하는 메모 앱이 아니라, 정리와 유지 보수를 넘길 수 있는 작업 공간이 됐다.

들어가기에 앞서: AI Agent가 필요한 이유

2년 전에는 유지비가 너무 컸다

2년 전에도 Obsidian을 진지하게 써보려 한 적이 있었다. 처음 며칠은 늘 괜찮다. 폴더를 만들고, 데일리 노트를 켜고, 태그를 붙이면 금방 체계가 생긴 것처럼 보인다. 문제는 그 다음이다.

시간이 지나면 초반에 대충 적어둔 노트를 다시 열어 제목을 고치고, 위치를 옮기고, 링크를 연결하고, 메타데이터를 손봐야 한다. 일정과 TODO까지 한곳에 넣기 시작하면 그 유지비는 더 커진다. 메모를 잘 쓰려고 만든 도구인데, 정작 메모를 유지하는 일이 너무 커졌다.

오래 못 간 이유를 줄이면 이렇다.

• 처음에는 아무 규칙 없이 적게 된다.
• 시간이 지나면 폴더 구조, 링크 방식, front matter, 허브 노트 같은 규칙이 필요해진다.
• 규칙이 생긴 뒤에는 기존 노트를 전부 다시 맞춰야 한다.
• 일정, TODO, 지식 메모까지 한 곳에 넣으면 구조 유지 비용이 더 커진다.

Obsidian이 나빠서가 아니었다. 사람이 직접 감당해야 할 유지비가 너무 커서 오래 못 갔다. 입력은 쉬웠지만 유지가 무거웠다.

지금은 그 유지비를 넘길 수 있다

지금은 상황이 다르다. Obsidian은 애초에 로컬 markdown 파일 기반이고, 요즘 AI Agent는 그 파일들을 직접 읽고 쓸 수 있다. 그래서 예전에는 사람이 하던 유지 작업을 이제는 에이전트에게 넘길 수 있다.

기존 노트를 검색해 중복을 막고, front matter 규칙을 맞추고, 관련 노트에 위키링크를 연결하고, 허브 노트나 장기 메모를 갱신하고, 일일기록에서 일정과 TODO를 다시 뽑아내는 일들이다.

중요한 건 자동화가 멋지다는 게 아니다. 사람이 지치던 반복 유지 작업을 대신 맡길 수 있다는 점이다. 그래서 Obsidian을 다시 열었을 때의 감각도 달라졌다. 예전에는 “이걸 또 언제 정리하지?”였다면, 지금은 “일단 적어두면 에이전트가 정리해주겠지”에 더 가깝다.

내가 만들고 싶었던 것

목표는 메모 앱이 아니라 개인 비서였다

내가 원한 건 예쁜 노트 모음이 아니다. 하루 기록을 남기면, 그걸 다시 손으로 정리하지 않아도 오늘 바로 쓸 수 있는 형태로 바뀌는 시스템이었다.

핵심은 간단하다. 먼저 일일기록이라는 입력 노트에 편하게 적는다. 그러면 AI가 그 기록을 읽고 일정, 메모, TODO, 그리고 날짜를 벗겨도 남길 가치가 있는 장기 메모(13_my) 후보로 다시 분해한다. 내가 실제로 보는 최종 출력은 raw markdown이 아니라 Day Planner 타임라인이다. 입력은 느슨하게, 출력은 실행 가능하게 만들고 싶었다.

바닥부터 새로 만들고 싶지는 않았다

물론 처음부터 전용 앱을 만들 수도 있다. 하지만 그러면 다시 “도구를 만드는 일”이 본업이 된다. 내가 원한 건 바닥부터 새 시스템을 짜는 게 아니라, 이미 잘 만들어진 Obsidian의 UI/UX와 플러그인 생태계 위에 AI Agent 개인 비서를 올리는 방식이었다.

검색, 위키링크, 그래프 뷰, daily note, 플러그인 UI는 이미 있다. 에이전트는 그 위에서 파일을 읽고 쓰며 정리와 유지 보수를 맡으면 된다. 이 조합이 훨씬 실전적이었다.

일일기록에서 Day Planner까지

1. 입력: 일일기록을 먼저 적는다

지금 내가 가장 자주 쓰는 패턴은 일일기록을 입력창처럼 쓰는 방식이다. Obsidian을 안 쓰는 사람에게 풀어 말하면, 하루 동안 있었던 일과 해야 할 일을 가장 먼저 흘려 적는 기본 노트다. 처음부터 완벽하게 구조화하려고 하지 않고, 그날 있었던 일과 해야 할 일, 짧은 일기를 먼저 적는다. 입력 단계에서는 마찰을 줄이고, 구조화는 후처리 단계로 넘긴다.

예를 들면 이런 식이다.

## 일기

늦게 일어나서 카페에서 발표 자료를 정리했다.
다음 주 병원 예약도 잡아야 하는데 아직 못 했다.
요즘은 오전보다 밤에 더 집중이 잘 되는 느낌이다.

실제 화면도 비슷하다. 왼쪽에는 체크리스트와 일기가 있고, 오른쪽 Day Planner에는 아직 시간표가 채워지지 않았다. 사람이 읽으면 무슨 하루였는지는 알 수 있지만, 바로 따라갈 수 있는 일정은 아직 아니다.

2. 후처리: 직접 만든 daily-note-followup 스킬이 다시 정리한다

그래서 여기서부터는 사람이 다시 정리하지 않는다. 내가 쓰는 핵심 워크플로우는 daily-note-followup라는 사용자 정의 스킬이다. 일일기록 후처리를 자동화하려고 직접 만든 스킬로, 일일기록을 읽고 오늘 노트 안의 일정, 메모, 에이전트 메모를 정리하고, 필요하면 TODO를 만들고 다음 날 노트나 장기 메모(13_my)까지 함께 갱신한다.

여기서도 경계는 분명하다. 사용자가 직접 쓰는 ## 일기는 그대로 두고, 오타나 띄어쓰기처럼 의미를 바꾸지 않는 가벼운 교정만 예외적으로 한다. 실제 후처리의 중심은 에이전트가 관리하는 섹션이다. ## 일정은 Day Planner가 읽을 시간표이고, ## 메모는 일기를 반복하지 않는 보충 사실이며, ## 에이전트 메모는 사용자의 하루를 다시 적는 곳이 아니라 에이전트가 한 작업과 나중에 참고할 맥락을 남기는 곳이다.

중요한 건 이 스킬이 아무 정보나 발명해서 채우지 않는다는 점이다. 시간 근거가 약하면 억지로 일정을 만들지 않고 메모로 남기거나 짧게 확인하고 멈춘다. 자동화의 핵심은 그럴듯한 요약이 아니라, 실제로 다시 써도 되는 수준의 정리다.

후처리 결과는 먼저 “무엇이 바뀌었는지”를 요약해서 보여준다. 실제 캡처에서도 일기 교정, 오늘 노트 보강, TODO 생성, 다음 날 노트 생성, 장기 메모 반영이 한 번에 묶여 있다.

그리고 나면 같은 일일기록 안에 이런 식의 결과가 생긴다.

## 일정

- 08:10 - 11:30 집에서 오전 작업
- 12:50 - 13:30 강가 산책로 따라 카페 이동
- 13:30 - 16:30 카페에서 마무리 작업

## 메모

- 오전 수정 작업은 카드 리스트 정렬 문제와 모바일 여부 보정에 집중했다.
- 카페에서는 문서 확인, 에러 로그 정리, 메모를 한 번에 처리했다.

## 에이전트 메모

- TODO 생성
- 다음 날 노트 생성
- 장기 메모 반영

여기서 중요한 건 단순 요약이 아니라 재배치다. 오늘 바로 실행해야 할 것은 일정과 TODO로, 일기에 다 담기지 않은 보충 사실은 메모로, 장기적으로 다시 참고할 정보는 장기 메모(13_my)로 나뉜다. 그래서 같은 기록이 “읽는 글”에서 “운영 가능한 하루”로 바뀐다.

3. 출력: 내가 실제로 보는 것은 Day Planner다

이 흐름의 최종 출력은 markdown 자체가 아니다. 내가 실제로 보는 건 오른쪽의 Day Planner 타임라인이다. Day Planner는 별도의 AI 기능이 아니라, 일일기록 안의 ## 일정 섹션을 읽어 시간표로 보여주는 Obsidian 플러그인이다. 상단에는 아직 시간에 얹지 않은 할 일이 남고, 아래에는 시간대별 일정이 배치된다.

즉, 일일기록은 입력 인터페이스에 가깝고, Day Planner는 실행 인터페이스에 가깝다. 나는 하루를 처음부터 다시 정리하는 대신, 타임라인을 보고 바로 움직인다. 핵심도 여기에 있다. 기록을 많이 남기는 게 아니라, 기록을 당장 쓸 수 있는 일정으로 바꾸는 것.

왜 하필 Obsidian인가

로컬 markdown이라 에이전트와 궁합이 맞다

Obsidian에서는 노트가 곧 파일이다. 그래서 에이전트가 직접 읽고 쓰기 쉽고, 특정 서비스의 API나 폐쇄적인 데이터 구조에 덜 묶인다. 유지 보수를 맡기려면 결국 파일 단위로 건드릴 수 있어야 하는데, Obsidian은 그 점이 강하다.

이미 갖춰진 UI/UX를 다시 만들 필요가 없다

내가 원한 건 새 제품을 만드는 일이 아니라, 이미 잘 만들어진 화면과 플러그인 위에 에이전트를 얹는 일이었다. 그래프 뷰로 vault를 훑고, daily note와 Day Planner를 그대로 쓰면서, 뒤쪽의 정리 작업만 에이전트에게 넘기면 된다.

오래 쓰는 시스템으로 만들려면

지침도 같이 관리해야 한다

에이전트가 노트를 대신 작성하고 정리해주기 시작하면, 다음 문제는 “무슨 규칙으로 움직이게 할 것인가”가 된다. 어디까지 수정해도 되는지, 어떤 폴더 구조를 따르는지, 일일기록에서 무엇을 추출해야 하는지 같은 기준이 있어야 결과가 흔들리지 않는다.

그래서 나는 vault 안에 AGENTS.md 같은 전역 지침 문서를 두고 운영한다. 다만 이 문서가 모든 절차를 다 적는 건 아니다. AGENTS.md는 전역 작성 원칙, 폴더 구조, 문서 라우팅 같은 큰 기준만 담는 얇은 문서이고, 작업별 세부 절차는 별도 운영 문서와 스킬 파일로 내려둔다. 에이전트를 오래 쓰려면 프롬프트보다 운영 문서가 더 중요해진다.

이 부분은 다음 편에서 더 다룰 생각이다

다만 이 글에서 그 구조 설명을 길게 하지는 않으려 한다. 1편의 핵심은 “AI Agent 덕분에 Obsidian이 다시 실용적인 개인 비서가 됐다”는 점과, 그 감각이 일일기록 -> 후처리 -> Day Planner 흐름에서 가장 분명하게 드러난다는 점이기 때문이다. 폴더 구조, 허브 노트, 지침 설계는 다음 편에서 따로 정리해보겠다.

마무리

내가 Obsidian을 다시 쓰게 된 이유는 메모 습관이 갑자기 좋아져서가 아니다. 예전에는 내가 직접 떠안아야 했던 유지 비용을 이제는 AI Agent가 대신 처리해줄 수 있게 되었기 때문이다.

그래서 지금의 Obsidian은 단순한 메모 앱이 아니다. 일일기록에 먼저 적으면, 에이전트가 그 기록을 다시 읽어 일정과 메모, TODO와 장기 맥락으로 재배치한다. 나는 Day Planner에서 오늘을 따라간다. 2년 전에는 “좋아 보이지만 오래 못 쓰는 시스템”이었다면, 지금은 “내가 계속 쓸 수 있는 방식으로 돌아가는 시스템”에 더 가깝다.

이 시리즈의 1편에서는 왜 다시 시도할 만해졌는지, 그리고 그 출발점이 왜 하필 일일기록이었는지를 정리했다. 다음 편에서는 이 개인 비서를 오래 굴리기 위해 어떤 구조와 지침을 깔아뒀는지 이어서 다뤄보겠다.

비슷한 증상은 openai/codex 이슈 #14010에도 등록돼 있다.

증상

아래는 문제가 발생했을 때의 화면이다.

• 스레드 목록 사이드바가 열린 상태에서 창이 넓게 고정돼 있다.

• 사이드바를 닫아도 창 너비가 충분히 줄어들지 않는다.
• 정확히는 창이 1200px 근처 아래로 더 줄어들지 않았고, 사이드바를 닫아도 최소로 줄일 수 있는 너비는 변하지 않았다.
• 즉 패널이 열려 있어서 넓어 보이는 문제가 아니라, 최소 너비 자체가 비정상적으로 크게 잡힌 상태에 가깝다.

원인

문제의 핵심은 ~/.codex/.codex-global-state.json 안의 electron-persisted-atom-state.review-open 값이었다. 리뷰 패널이 실제로는 닫혀 있어도 이 값이 true로 stale하게 남아 있으면, 앱이 계속 리뷰가 열린 창으로 판단하면서 최소 너비를 크게 잡는다.

확인했을 때 메인 창 최소 크기는 일반 상태에서 800 x 600, review-open: true 상태에서는 1200 x 800으로 잡혀 있었다. 다만 macOS Retina 환경에서는 스크린샷의 물리 픽셀보다 pt 기준 최소 크기로 이해하는 편이 맞다.

해결 방법

Codex가 실행 중이면 종료 시 상태 파일을 다시 덮어쓸 수 있다. 반드시 앱을 완전히 종료한 뒤 수정해야 한다.

1. Codex를 Cmd+Q로 완전히 종료한다.
2. 필요하면 상태 파일을 먼저 백업한다.

cp ~/.codex/.codex-global-state.json ~/.codex/.codex-global-state.json.bak

1. 아래 명령으로 review-open 값을 false로 바꾼다.

perl -0pi -e 's/"review-open":true/"review-open":false/g' ~/.codex/.codex-global-state.json

1. 값이 잘 바뀌었는지 확인한다.

jq '."electron-persisted-atom-state"["review-open"]' ~/.codex/.codex-global-state.json

1. false가 나오면 Codex를 다시 실행한다.

문제가 해결되면 같은 창이 훨씬 좁은 폭까지 줄어든다.

그래도 정확히 반 화면까지는 안 갈 수 있는 이유

이 방법은 stale 상태 때문에 비정상적으로 넓게 고정되는 문제를 푸는 방법이지, 모든 환경에서 무조건 반 화면 이하까지 줄여 주는 방법은 아니다.

Codex 메인 창 자체에 기본 최소 너비가 있고, 현재 디스플레이의 실제 작업 영역 절반이 그보다 더 좁으면 반 화면 배치는 불가능하다.

예를 들어 내가 확인한 환경은 다음과 같았다.

• MacBook Pro 14형 (Apple M4)
• 디스플레이 기본 해상도 사용
• 내장 디스플레이 작업 영역 폭 약 1512pt
• 화면 절반 약 756pt

이 환경에서는 review-open 문제를 해결해도 기본 최소 너비 800보다 화면 절반 756이 더 좁기 때문에, 기본 해상도에서는 반 화면보다 약간 더 넓은 수준까지만 줄어드는 것이 정상이다.

다시 같은 문제가 생기면

• ~/.codex/.codex-global-state.json의 review-open 값이 다시 true로 돌아갔는지 먼저 확인한다.
• 값이 true인데 리뷰 패널이 실제로 닫혀 있다면 같은 종류의 stale state 문제일 가능성이 높다.

화면이 넓게 고정되는 현상 때문에 Codex를 화면분할로 쓰기 어려웠다면, 먼저 이 상태값부터 확인해보면 된다.

Weekly Tech Trend Talk 스터디(26.03.12)

Playwright MCP

Codex에 Playwright MCP를 추가하면 AI가 직접 브라우저를 조작할 수 있게 된다.

codex mcp add playwright -- npx @playwright/mcp@latest

추가되는 Tool 목록

MCP를 추가하면 다양한 브라우저 조작 도구들이 생긴다. 의미별로 묶으면 다음과 같다.

• 페이지 이동: navigate, navigate_back, tabs, close
• 입력/조작: click, hover, type, fill_form, select_option, press_key, drag, handle_dialog, file_upload
• 관찰/디버깅: snapshot, take_screenshot, console_messages, network_requests, evaluate, run_code
• 환경 보조: resize, wait_for, install

이 tool들을 AI가 적절히 조합해서 브라우저를 자동화한다.

Playwright Skills

Codex에는 skill-installer 스킬로 설치할 수 있는 playwright, playwright-interactive 같은 Playwright 관련 스킬들이 있다. skill-installer는 openai/skills 레포의 curated 목록에서 스킬을 내려받아 설치한다.

MCP와 Skill은 경쟁 관계가 아니라 역할이 다르다.

• MCP는 Codex에 실제 브라우저 tool을 연결해 주는 방식이다. 외부 시스템에 대한 실행 능력을 추가한다.
• Skill은 반복해서 쓰는 절차를 SKILL.md, scripts, references로 묶어 둔 워크플로우 패키지다.

Skill은 metadata만 먼저 보이고, 선택되었을 때만 SKILL.md와 필요한 references/scripts를 읽는 progressive disclosure 방식으로 설계되어 있다. 반면 MCP는 tool 표면이 넓어질수록 action surface가 커지기 때문에, OpenAI 문서에서도 처음부터 모든 tool을 붙이지 말고 실제 workflow에 필요한 몇 개부터 연결하라고 권장한다.

playwright 스킬

playwright 스킬은 브라우저 tool을 새로 추가하는 것이 아니라, Codex가 playwright-cli 또는 번들 wrapper script를 사용해 브라우저를 자동화하도록 안내하는 CLI 중심 워크플로우다.

• MCP처럼 mcp__playwright__... tool이 생기지는 않는다
• open, snapshot, click, fill, screenshot 같은 절차를 CLI 명령으로 재사용하도록 돕는다
• 브라우저 capability를 늘리는 것보다, 절차를 재사용 가능하게 만드는 것에 가깝다

playwright-interactive 스킬

playwright-interactive 스킬은 js_repl 안에서 Playwright 세션을 계속 유지하면서, 같은 브라우저나 Electron 앱 핸들을 재사용해 반복 디버깅하는 워크플로우다.

GPT 5.4가 이 스킬을 사용하여 위와 같은 게임들을 만들었다고 한다. 스크린샷은 테마파크 시뮬레이션 게임으로, 이소메트릭 뷰의 놀이공원을 운영하는 “Miniature” 게임이다. 이 외에도 RPG 게임, 골든 게이트 브리지 상공 비행 게임 등 다양한 장르를 생성했다.

• MCP처럼 tool을 추가하는 것이 아니라, 지속 세션 기반 디버깅 절차를 제공한다
• 코드 변경 후 reload/relaunch를 반복하며 QA와 시각 확인을 수행하기 좋다
• 단발성 CLI 실행보다 로컬 웹 앱이나 Electron 앱을 오래 붙들고 점검하는 데 더 적합하다

정리

MCP는 실행 능력을 제공하고, Skill은 그 능력을 효과적으로 사용하는 방법을 제공하는 관계라고 볼 수 있다.