이 글은 「opencode 12일 집중」 7일차로, opencode의 프로젝트 메모리 파일인 AGENTS.md를 설계하고 활용하는 방법을 다룹니다.
어제 6일차에서 opencode의 내장 툴 — 파일 읽기·쓰기, 셸 실행, grep/glob 검색, LSP 연동까지 살펴봤습니다. 도구가 아무리 강력해도 “이 프로젝트가 뭔지” 모르는 에이전트는 매번 같은 질문을 반복합니다. 오늘은 그 문제를 근본적으로 해결하는 열쇠, AGENTS.md를 다룹니다.
오늘의 핵심 3가지
- AGENTS.md는 프로젝트의 장기 기억이다 — 세션이 바뀌어도, 팀원이 바뀌어도, 에이전트는 같은 맥락에서 시작한다.
- /init 한 줄이면 뼈대가 만들어진다 — 코드베이스를 분석해 초안을 자동 생성하고, 여기에 프로젝트 고유 규칙을 채워 넣는다.
- /compact로 실시간 컨텍스트를 압축하고, git commit으로 팀 전체가 공유한다 — 개인의 노하우가 팀의 자산이 된다.
AGENTS.md가 필요한 이유
AI 코딩 에이전트의 가장 큰 약점은 맥락 소실입니다. 새 세션을 열 때마다 에이전트는 백지 상태로 돌아갑니다. “우리 프로젝트는 Python 3.11 이상만 쓴다”, “테스트는 pytest로 돌린다”, “DB 마이그레이션은 Alembic이다” — 이런 기본 사실을 매번 다시 알려줘야 합니다.
AGENTS.md는 이 문제를 해결하는 프로젝트 레벨 시스템 프롬프트입니다. 프로젝트 루트에 이 파일이 있으면, opencode는 세션을 시작할 때 자동으로 읽어서 컨텍스트에 주입합니다. Claude Code의 CLAUDE.md, Cursor의 .cursorrules와 같은 역할이지만, opencode의 AGENTS.md는 어떤 모델·프로바이더에서든 동일하게 동작한다는 점이 BYOK 철학과 맞닿아 있습니다.
AGENTS.md와 컨텍스트 파일의 계층 구조
opencode는 AGENTS.md를 단일 파일이 아니라 계층적으로 탐색합니다. 프로젝트 루트부터 현재 작업 디렉터리까지 경로상의 모든 AGENTS.md를 수집해서, 루트가 가장 먼저, 하위 디렉터리 것이 나중에 주입됩니다.
/project/AGENTS.md— 프로젝트 전체 규칙/project/backend/AGENTS.md— 백엔드 모듈 전용 규칙/project/backend/api/AGENTS.md— API 레이어 세부 규칙
이 구조 덕분에 모노레포에서도 각 서비스마다 독립적인 규칙을 정의하면서, 공통 규칙은 루트에서 한 번만 관리할 수 있습니다. 하위 파일은 상위를 보완하는 것이지 덮어쓰는 게 아닙니다. 충돌이 생기면 하위가 우선하되, 대부분의 경우 계층을 나누면 충돌 자체가 발생하지 않습니다.
/init으로 AGENTS.md 자동 생성하기
빈 파일부터 시작할 필요가 없습니다. opencode의 /init 슬래시 커맨드는 현재 코드베이스를 분석해서 AGENTS.md 초안을 자동으로 만들어 줍니다.
# opencode TUI를 열고
opencode
# 프롬프트에서 /init 실행
/init/init이 하는 일은 다음과 같습니다.
- 프로젝트 구조 스캔 — 디렉터리 트리, 주요 설정 파일(package.json, pyproject.toml, go.mod 등)을 읽습니다.
- 기술 스택 추론 — 언어, 프레임워크, 테스트 도구, 린터, 빌드 시스템을 식별합니다.
- AGENTS.md 초안 작성 — 추론한 내용을 구조화된 마크다운으로 프로젝트 루트에 생성합니다.
자동 생성된 초안은 출발점일 뿐입니다. 진짜 가치는 여기에 프로젝트 고유의 규칙과 맥락을 직접 채워 넣을 때 나옵니다.
AGENTS.md 모범 템플릿
실무에서 바로 쓸 수 있는 AGENTS.md 템플릿을 단계별로 구성했습니다. 모든 섹션을 다 채울 필요는 없습니다. 프로젝트에 맞는 섹션만 골라서 시작하세요.
# AGENTS.md
## Project Overview
- 프로젝트명: my-service
- 한 줄 설명: 사용자 인증·인가를 담당하는 마이크로서비스
- 주요 언어: Python 3.12
- 프레임워크: FastAPI + SQLAlchemy 2.0
## Architecture
- 레이어: API → Service → Repository → DB
- DB: PostgreSQL 16 (Alembic 마이그레이션)
- 캐시: Redis 7 (세션 토큰 저장)
- 메시지 큐: 없음 (향후 Kafka 도입 예정, 아직 코드 없음)
## Development Rules
- 모든 코드는 ruff로 린트, mypy --strict로 타입 체크
- 테스트: pytest, 커버리지 80% 이상 유지
- 커밋 메시지: conventional commits (feat/fix/docs/test/chore)
- PR은 반드시 1명 이상 리뷰 후 머지
## File Structure
- src/auth_service/ — 메인 소스
- src/auth_service/api/ — FastAPI 라우터
- src/auth_service/domain/ — 비즈니스 로직
- src/auth_service/infra/ — DB, Redis 어댑터
- tests/ — 테스트 (구조는 src/ 미러링)
- alembic/ — DB 마이그레이션
## Conventions
- 환경변수는 pydantic-settings로 관리 (src/auth_service/config.py)
- 비밀값(DB 패스워드, JWT 시크릿)은 .env에만 두고 코드/커밋에 포함 금지
- API 응답은 항상 {"data": ..., "error": ...} 형식
- 날짜는 UTC, ISO 8601 형식으로 통일
## Do NOT
- anthropic SDK 직접 호출 금지 (내부 프록시 경유)
- ORM 모델에 비즈니스 로직 넣지 말 것 (domain 레이어에서 처리)
- print() 대신 structlog 사용
- SELECT * 금지 — 필요한 컬럼만 명시이 템플릿의 핵심은 7개 섹션입니다. 하나씩 짚어 보겠습니다.
1. Project Overview — 에이전트의 첫인상
프로젝트가 무엇인지, 어떤 언어와 프레임워크를 쓰는지 한눈에 보여 줍니다. 에이전트는 이 섹션을 읽고 “아, Python FastAPI 프로젝트구나”라고 즉시 판단합니다. 여기가 부실하면 에이전트가 package.json을 찾아 헤매거나, Go 프로젝트에 npm 명령어를 제안하는 사고가 일어납니다.
2. Architecture — 구조적 지도
레이어 구분, 외부 의존성(DB, 캐시, 큐), 인프라 구성을 기술합니다. “향후 도입 예정이지만 아직 코드 없음”처럼 부정 정보(negative knowledge)도 중요합니다. 없는 것을 있다고 가정하고 코드를 생성하는 실수를 막아 줍니다.
3. Development Rules — 팀의 개발 규칙
린트, 테스트, 커밋 메시지 규칙, PR 프로세스 등 팀이 합의한 규칙입니다. 에이전트가 코드를 생성할 때 이 규칙을 자동으로 따르게 됩니다. “ruff로 린트한다”고 적어두면, 에이전트는 black이나 flake8 설정을 건드리지 않습니다.
4. File Structure — 디렉터리 안내판
에이전트가 파일을 찾거나 새로 만들 때 어디에 놓아야 하는지 알려 줍니다. 특히 모노레포나 레이어 구분이 명확한 프로젝트에서 효과적입니다. “테스트는 src/를 미러링한다”고 적으면, src/auth_service/domain/user.py의 테스트를 tests/domain/test_user.py에 정확히 만들어 줍니다.
5. Conventions — 코딩 관례
API 응답 형식, 날짜 포맷, 설정 관리 방식 등 코드 수준의 관례입니다. 이것을 적지 않으면 에이전트는 매번 다른 패턴으로 코드를 생성합니다. 한 번은 {"result": ...}, 다음엔 {"data": ...}, 그다음엔 {"response": ...} — 일관성이 사라집니다.
6. Do NOT — 금지 사항
이 섹션이 의외로 가장 효과적입니다. 에이전트는 “하라”보다 “하지 마라”에 더 잘 반응합니다. 특히 보안 관련 금지 사항(SELECT * 금지, 비밀값 코드 포함 금지)은 반드시 명시하세요. 한 번 적어두면 모든 세션에서 자동으로 지켜집니다.
7. (선택) 도메인 용어집
금융, 의료, 물류처럼 도메인 전문 용어가 많은 프로젝트라면 용어집 섹션을 추가하세요.
## Domain Glossary
- KYC: Know Your Customer — 고객 확인 절차
- AML: Anti-Money Laundering — 자금세탁 방지
- FDS: Fraud Detection System — 이상거래 탐지
- 전문(電文): 금융 기관 간 통신 메시지 포맷에이전트가 “KYC 검증 로직을 구현해 줘”라고 요청받았을 때, 용어의 정확한 의미를 알고 코드를 생성하는 것과 추측으로 생성하는 것은 품질 차이가 큽니다.
실전: AGENTS.md 작성부터 활용까지
기존 프로젝트에 AGENTS.md를 도입하는 전체 흐름을 따라가 보겠습니다.
Step 1 — /init으로 초안 생성
# 프로젝트 디렉터리에서 opencode 실행
cd ~/projects/my-service
opencode
# TUI에서 /init 실행
/initopencode가 프로젝트를 스캔하고 AGENTS.md 초안을 생성합니다. 파일이 이미 존재하면 덮어쓰지 않고 보완 제안을 합니다.
Step 2 — 초안 검토 및 보강
자동 생성된 내용을 검토합니다. /init이 잡아내지 못하는 것들이 있습니다.
- 팀 관례 — 코드에서 추론할 수 없는 암묵적 규칙 (PR 리뷰 정책, 커밋 메시지 규칙)
- 금지 사항 — 과거 장애나 보안 이슈로 정한 “절대 하지 말 것” 목록
- 도메인 맥락 — 비즈니스 로직의 배경, 용어, 외부 시스템 연동 규칙
- 부정 정보 — “아직 없는 것”, “더 이상 쓰지 않는 것”
이런 항목들은 직접 채워 넣어야 합니다. AGENTS.md의 가치는 기계가 추론할 수 없는 인간의 지식을 담을 때 극대화됩니다.
Step 3 — 에이전트에게 직접 물어보기
AGENTS.md를 한 번에 완벽하게 작성할 필요는 없습니다. opencode에게 물어보면서 점진적으로 보강하는 방법이 실용적입니다.
# opencode TUI 프롬프트에서
이 프로젝트의 AGENTS.md에 빠진 내용이 있는지 코드베이스를 분석해서 제안해 줘에이전트는 코드를 읽고, 현재 AGENTS.md에 없는 패턴이나 규칙을 발견하면 추가를 제안합니다. 예를 들어 “테스트에서 conftest.py의 공통 fixture를 사용하는 패턴이 보이는데, AGENTS.md에 언급이 없습니다”라고 알려줄 수 있습니다.
Step 4 — 세션에서 효과 확인
AGENTS.md를 저장한 뒤 새 세션을 시작하면, 에이전트의 응답 품질이 달라지는 것을 체감할 수 있습니다.
# AGENTS.md 없이 요청
"사용자 생성 API를 만들어 줘"
→ 에이전트가 Flask로 만들거나, 응답 형식이 제각각
# AGENTS.md 있을 때 같은 요청
"사용자 생성 API를 만들어 줘"
→ FastAPI 라우터, domain 레이어 분리, {"data": ..., "error": ...} 형식,
structlog 사용, 테스트 파일 위치까지 올바르게 생성이것이 AGENTS.md의 본질입니다. 같은 프롬프트로 더 정확한 결과를 얻는 것. 프롬프트 엔지니어링을 매번 반복하는 대신, 한 번 잘 적어두면 됩니다.
/compact로 컨텍스트 압축하기
긴 세션을 진행하다 보면 대화 컨텍스트가 점점 커집니다. 모델의 컨텍스트 윈도우에는 한계가 있고, 토큰을 많이 쓸수록 비용도 올라갑니다. /compact 커맨드는 이 문제를 해결합니다.
# 세션 중간에 컨텍스트 압축
/compact/compact가 하는 일:
- 현재까지의 대화 히스토리를 요약합니다.
- 핵심 결정 사항, 변경된 파일, 진행 상황을 보존합니다.
- 중간 과정의 시행착오, 반복 질문 등 불필요한 부분을 제거합니다.
- 압축된 요약으로 컨텍스트를 교체합니다.
중요한 점은, /compact 후에도 AGENTS.md는 항상 전문이 유지된다는 것입니다. 대화 히스토리만 압축될 뿐, 프로젝트의 장기 기억인 AGENTS.md는 손대지 않습니다. 이것이 AGENTS.md와 대화 컨텍스트의 근본적인 차이입니다.
/compact를 쓰면 좋은 타이밍
- 작업 전환 시 — “인증 모듈 수정”에서 “결제 API 추가”로 넘어갈 때
- 긴 디버깅 후 — 시행착오 대화가 많이 쌓였을 때
- 컨텍스트 경고가 뜰 때 — 모델이 컨텍스트 한계에 가까워지면 opencode가 알려줍니다
# 특정 주제로 압축 (선택적 인자)
/compact 인증 모듈 리팩터링 완료, 이제 결제 API 작업 시작인자를 넣으면 에이전트가 해당 맥락을 중심으로 요약합니다. “인증 모듈은 끝났고, 결제 API를 시작한다”는 방향을 명확히 할 수 있습니다.
AGENTS.md와 /compact의 협업
이 두 기능의 조합이 opencode 컨텍스트 관리의 핵심 패턴입니다.
- AGENTS.md = 장기 기억 (프로젝트 수명 동안 유지)
- 대화 컨텍스트 = 단기 기억 (세션 내 작업 흐름)
- /compact = 단기 기억의 정리 도구 (핵심만 남기고 압축)
비유하자면, AGENTS.md는 팀 위키에 적힌 프로젝트 가이드이고, 대화 컨텍스트는 오늘의 작업 메모이고, /compact는 메모를 정리해서 핵심만 남기는 것입니다. 위키(AGENTS.md)는 항상 참조 가능하고, 메모(대화)는 필요에 따라 정리합니다.
세션이 길어질 때의 전략
실무에서 하나의 세션이 수십 턴을 넘기는 경우가 많습니다. 이때 컨텍스트 관리 전략이 없으면 에이전트의 응답 품질이 떨어집니다.
# 권장 패턴: 작업 단위마다 /compact
# 1. 인증 모듈 수정 (10턴)
/compact 인증 모듈 — JWT 만료 로직 수정 완료, 테스트 통과
# 2. 결제 API 추가 (15턴)
/compact 결제 API — POST /payments 엔드포인트 추가, PG 연동 미완
# 3. PG 연동 마무리 (8턴)
/compact 결제 PG 연동 완료, 통합 테스트 통과이렇게 하면 각 작업 단위의 핵심이 깔끔하게 보존되면서, 불필요한 중간 대화는 제거됩니다. AGENTS.md가 “이 프로젝트가 뭔지”를 담당하고, 압축된 컨텍스트가 “오늘 뭘 했는지”를 담당하는 분업입니다.
팀 공유 전략 — AGENTS.md를 git에 커밋하기
AGENTS.md의 진짜 힘은 팀 전체가 공유할 때 발휘됩니다. 이 파일을 git에 커밋하면, 팀원 누구나 opencode를 열었을 때 동일한 컨텍스트에서 시작합니다.
git 커밋이 정답인 이유
- 버전 관리 — 규칙이 바뀌면 diff로 변경 이력을 추적할 수 있습니다.
- 코드 리뷰 — AGENTS.md 변경도 PR을 통해 팀원이 검토합니다. “이 규칙이 맞나?”를 논의할 수 있습니다.
- 브랜치 격리 — feature 브랜치에서 실험적으로 규칙을 바꿔 보고, 효과가 있으면 main에 머지합니다.
- 온보딩 — 신규 팀원이 리포를 클론하면 AGENTS.md가 자동으로 따라옵니다. 별도 설정 없이 팀의 규칙이 에이전트에 주입됩니다.
# AGENTS.md를 git에 추가
git add AGENTS.md
git commit -m "docs: add AGENTS.md for opencode context"
git push origin main.gitignore에 넣으면 안 되는 이유
간혹 “개인 설정 파일이니 .gitignore에 넣어야 하지 않나?”라고 생각할 수 있습니다. AGENTS.md는 개인 설정이 아니라 프로젝트 문서입니다. README.md를 .gitignore에 넣지 않듯, AGENTS.md도 리포의 일부로 관리해야 합니다.
다만 개인적인 선호(특정 모델 설정, 로컬 경로 등)는 AGENTS.md에 넣지 않습니다. 그런 것들은 opencode의 사용자별 설정 파일(~/.config/opencode/config.toml)에 두는 게 맞습니다.
모노레포에서의 AGENTS.md 전략
모노레포라면 계층적 AGENTS.md 구조를 적극 활용하세요.
monorepo/
├── AGENTS.md # 전체 공통 규칙
├── packages/
│ ├── auth-service/
│ │ ├── AGENTS.md # 인증 서비스 전용
│ │ └── src/
│ ├── payment-service/
│ │ ├── AGENTS.md # 결제 서비스 전용
│ │ └── src/
│ └── shared-lib/
│ ├── AGENTS.md # 공유 라이브러리 전용
│ └── src/
└── infra/
├── AGENTS.md # 인프라 전용
└── terraform/루트 AGENTS.md에는 “conventional commits 사용”, “PR 리뷰 필수” 같은 공통 규칙을 둡니다. 각 서비스의 AGENTS.md에는 해당 서비스의 기술 스택, 도메인 용어, 금지 사항을 둡니다. cd packages/auth-service에서 opencode를 실행하면, 루트 + auth-service 두 파일이 모두 로딩됩니다.
AGENTS.md 작성 팁 — 효과를 극대화하는 방법
구체적으로 적어라
“코드를 잘 작성하라”는 의미가 없습니다. 에이전트는 이미 코드를 잘 작성하려고 합니다. 구체적인 지시가 필요합니다.
# ❌ 나쁜 예
- 테스트를 잘 작성할 것
# ✅ 좋은 예
- 테스트 파일은 tests/ 아래에 src/ 구조를 미러링하여 배치
- 픽스처는 conftest.py에 정의, 테스트 함수 내 직접 정의 금지
- DB 의존 테스트는 @pytest.mark.integration 마커 부착
- 단위 테스트에서 외부 호출은 반드시 모킹 (httpx.AsyncClient mock)Do NOT 섹션을 두려워 말라
금지 사항은 많으면 많을수록 좋습니다. 단, 각 항목에 이유를 한 줄씩 달아주면 에이전트가 유사한 상황에서도 올바른 판단을 합니다.
## Do NOT
- datetime.now() 사용 금지 → datetime.now(tz=timezone.utc) 사용 (서버 타임존 의존 방지)
- requests 라이브러리 사용 금지 → httpx 사용 (async 통일)
- f-string으로 SQL 쿼리 조합 금지 → SQLAlchemy 바인드 파라미터 사용 (SQL 인젝션 방지)
- print() 금지 → structlog.get_logger() 사용 (구조화 로깅 정책)너무 길면 오히려 독
AGENTS.md가 수백 줄이 되면 오히려 효과가 떨어집니다. 모든 내용이 컨텍스트에 주입되므로, 핵심이 아닌 정보가 많으면 중요한 규칙이 묻힙니다. 목표는 200줄 이내. 넘어가면 하위 디렉터리 AGENTS.md로 분산하거나, 정말 핵심적인 내용만 남기세요.
주기적으로 갱신하라
프로젝트는 진화합니다. 3개월 전에 적은 규칙이 지금은 맞지 않을 수 있습니다. 정기적으로(예: 스프린트 회고 때) AGENTS.md를 리뷰하고 업데이트하세요. 에이전트에게 “현재 코드베이스를 기준으로 AGENTS.md에 틀린 내용이 있는지 확인해 줘”라고 요청하면 불일치를 잡아낼 수 있습니다.
AGENTS.md vs 다른 도구의 컨텍스트 파일
AI 코딩 도구마다 비슷한 기능이 있습니다. 비교해 보겠습니다.
- Claude Code → CLAUDE.md: 기능적으로 가장 유사. 계층적 탐색, Do NOT 패턴 모두 지원. 다만 Claude 모델 전용.
- Cursor → .cursorrules: IDE 통합이 강점. 하지만 Cursor 에디터에서만 동작.
- GitHub Copilot → .github/copilot-instructions.md: GitHub 생태계 연동. VS Code + Copilot 조합에서 동작.
- opencode → AGENTS.md: BYOK이므로 어떤 모델에서든 동작. 터미널·데스크톱·IDE 어디서든 동일하게 인식.
opencode의 차별점은 벤더 독립성입니다. 오늘 Anthropic 모델로 작업하다가 내일 OpenAI로 바꿔도, AGENTS.md는 그대로 동작합니다. 프로젝트의 지식이 특정 도구에 종속되지 않습니다.
또 하나, 이 파일들은 서로 배타적이지 않습니다. 한 프로젝트에 AGENTS.md와 CLAUDE.md가 동시에 존재해도 됩니다. 팀원 중 누구는 opencode를, 누구는 Claude Code를 쓸 수 있으니까요. 내용이 겹치면 하나를 정본으로 두고 다른 쪽에서 참조하는 방식으로 관리하면 됩니다.
실전 시나리오 — 레거시 프로젝트에 AGENTS.md 도입
가장 효과가 큰 상황은 레거시 프로젝트에 도입할 때입니다. 문서가 부실하고, 암묵적 규칙이 많고, 신규 투입 인력이 적응하는 데 시간이 오래 걸리는 프로젝트. 정확히 AGENTS.md가 빛나는 곳입니다.
# Step 1: opencode로 코드베이스 분석
opencode
> 이 프로젝트의 기술 스택, 디렉터리 구조, 주요 패턴을 분석해서 AGENTS.md 초안을 만들어 줘
# Step 2: 시니어 개발자가 금지 사항과 도메인 지식 추가
# (이 부분은 코드에서 추론이 어려우므로 사람이 채움)
# Step 3: PR로 팀 리뷰
git checkout -b docs/add-agents-md
git add AGENTS.md
git commit -m "docs: add AGENTS.md for AI-assisted development"
git push origin docs/add-agents-md
# → PR 생성 → 팀 리뷰 → 머지이 과정에서 뜻밖의 부수 효과가 있습니다. AGENTS.md를 작성하면서 팀이 그동안 암묵적으로만 공유하던 규칙을 명문화하게 됩니다. “우리 프로젝트에서 절대 하면 안 되는 것”을 한 곳에 모아 적는 행위 자체가, 에이전트뿐 아니라 사람에게도 유익한 문서화입니다.
Gotcha 미니 코너 — AGENTS.md에 비밀을 적지 마세요
AGENTS.md는 git에 커밋하는 파일입니다. 절대로 API 키, 패스워드, 내부 서버 IP, 토큰 같은 비밀 정보를 적지 마세요.
# ❌ 절대 금지
## Credentials
- DB 패스워드: myp@ssw0rd
- API 키: sk-xxxxxxxxxxxx
- 내부 서버: 10.0.1.52:5432
# ✅ 올바른 방법
## Credentials
- DB 패스워드는 환경변수 DB_PASSWORD로 주입 (.env.example 참조)
- API 키는 환경변수 SERVICE_API_KEY로 주입
- 내부 서버 주소는 환경변수 DB_HOST로 주입비밀값의 존재와 주입 방법만 적고, 실제 값은 절대 넣지 않습니다. 이것은 AGENTS.md 고유의 문제가 아니라 git에 커밋하는 모든 파일의 기본 규칙이지만, AGENTS.md 작성에 몰입하다 보면 “에이전트가 알아야 하니까” 하고 실수로 적는 경우가 있습니다. 주의하세요.
한 가지 더 — 사내 시스템의 구체적인 아키텍처나 보안 정책도 공개 리포에 적지 마세요. 프라이빗 리포라면 팀 판단에 따르되, 공개 리포라면 도메인 맥락을 일반화해서 적는 습관을 들이는 게 좋습니다.
마무리 — 프로젝트의 기억을 설계하는 것
AGENTS.md는 단순한 설정 파일이 아닙니다. 프로젝트의 기억을 설계하는 행위입니다. 어떤 규칙을 적고, 어떤 금지 사항을 남기고, 어떤 구조를 안내할 것인가 — 이 선택이 에이전트의 모든 응답 품질을 결정합니다.
오늘 배운 것을 정리하면:
/init으로 초안을 생성하고, 팀의 암묵지를 명문화해서 채운다./compact로 세션 컨텍스트를 관리하되, AGENTS.md는 항상 온전히 유지된다.- git에 커밋해서 팀 전체가 동일한 컨텍스트를 공유한다.
- 200줄 이내로 핵심만 담고, Do NOT 섹션을 두려워하지 않는다.
내일 8일차에서는 커스텀 슬래시 커맨드를 다룹니다. AGENTS.md가 “에이전트가 아는 것”이라면, 커스텀 커맨드는 “에이전트가 할 수 있는 것”을 확장하는 도구입니다. 반복되는 작업을 한 줄 커맨드로 자동화하는 방법, 기대해 주세요.
◀ 이전 6화 (다음 차수는 아직 게시되지 않았습니다)
참고 자료
- opencode 공식 문서 — AGENTS.md — opencode에서 AGENTS.md 파일의 역할과 작성법을 설명하는 공식 가이드
[…] 집중 — 터미널 네이티브 AI 코딩 에이전트 완전 정복 (총 12화 중 8화)◀ 이전 7화 (다음 차수는 아직 게시되지 […]
[…] [opencode 12일 집중 — 터미널 네이티브 AI 코딩 에이전트 완전 정복] 7/12화: AGE… […]