방금 나눈 대화로 Continue가 규칙을 작성하게 만드는 방법 (2026년 가이드)

지침 파일은 보통 에이전트에게 무엇이 필요할지 상상하며 미리 작성됩니다. 이는 빌드 명령, 스타일, 리뷰 단계와 같이 안정적인 요소를 캡처하는 합리적인 방법입니다. 하지만 그 외의 모든 것은 체계적으로 놓치게 됩니다. 에이전트가 실제로 발을 헛디디기 전까지는 무엇이 걸림돌이 될지 알 수 없기 때문입니다.

Continue는 규칙의 용도를 명확히 정의합니다. 규칙은 "Agent 모드, Chat 및 Edit 요청 시 모델에 시스템 메시지 지침을 제공"하며, "시스템 메시지를 구성하기 위해 규칙은 툴바에 나타나는 순서대로 줄바꿈으로 결합됩니다." 즉, 규칙은 매 요청마다 다시 전송되는 프롬프트 수준의 설정입니다. 이러한 프레임워크는 정확하며, 상상만으로 규칙을 작성할 때 왜 내용이 부실해지는지 설명해 줍니다. 시스템 메시지의 내용을 그저 짐작하고 있을 뿐이기 때문입니다.

수정 사항은 다릅니다. 좋은 규칙이 갖추어야 할 모든 것, 즉 잘못된 특정 동작, 올바른 동작, 그리고 (사람들이 짜증이 났을 때 흔히 소리 내어 말하듯) 그 이유가 이미 포함되어 있습니다. "대조 작업에 배치 엔드포인트를 사용하지 마세요. 만 개 이상의 행에서는 타임아웃이 발생하기 때문입니다." 이 마지막 절이 바로 미래의 결정 과정에서도 규칙이 살아남을 수 있게 만드는 핵심입니다. 단순한 금지 조항은 처음 불편함이 생기는 순간 무시되기 마련입니다.

사람들이 이 사실을 몰라서 기록하지 않는 것이 아닙니다. 기록하는 행위 자체가 두 번째 작업이 되기 때문이며, 특히 두 번째 작업을 할 의욕이 가장 안 나는 순간에 해야 하기 때문입니다. 그리고 이것이 바로 도구 호출(tool call)이 존재하는 이유입니다.

매 세션마다 제약 조건 다시 입력하기. 이는 가장 기본적인 방법이며, 코드가 올바르게 나온다는 점에서 효과가 있습니다. 하지만 제약 조건의 수명이 사용자의 기억력만큼만 유지되며, 팀의 다른 구성원에게는 보이지 않는다는 단점이 있습니다. 이 문제의 전반적인 양상은 AI에게 컨텍스트를 반복해서 설명하지 않는 방법에서 다루고 있습니다.

하나의 거대한 상시 활성화 규칙 파일. 학습된 모든 내용을 alwaysApply: true가 설정된 단일 규칙에 넣는 방식입니다. 규칙이 항상 적용된다는 장점이 있지만, 그것이 곧 문제입니다. 몇 달이 지나면 모델은 매 요청마다 수천 단어에 달하는 누적된 수정 사항을 받게 되며, 그 중 대부분은 현재 작업과 무관합니다. 결국 중요한 규칙과 중요하지 않은 규칙이 서로 경쟁하게 됩니다. 모델에 제공하는 정보를 최소화하는 것이 대개 더 나은 선택이며, 이에 대해서는 에이전트 메모리와 정보 최소화 유지에서 논의한 바 있습니다.

README나 설계 문서에 작성하기. 직관은 맞았으나 그릇이 틀렸습니다. Continue는 .continue/rules에서 규칙을 읽습니다. README는 무언가가 강제로 주입하지 않는 한 시스템 메시지에 포함되지 않습니다. 지식은 인간을 위해 보존되지만 에이전트에게는 누락됩니다.

대화 내용 신뢰하기. 수정 사항이 채팅에 그대로 남아 있으니 모델이 기억할 것이라 믿는 방식입니다. 이번 세션 동안은 기억하겠지만, Continue의 규칙이 존재하는 이유는 바로 이 경계 때문입니다. 지침은 요청마다 다시 제공되며, 채팅은 저장소가 아닙니다. 자세한 이유는 에이전트가 지침 파일을 무시하는 이유에서 다룹니다.

스킬(Skill) 활용하기. 스킬은 절차를 패키징합니다. 하지만 수정 사항은 절차가 아니라 코드베이스에 대한 사실(fact)이며, 이 차이는 생각보다 중요합니다. 에이전트 스킬이 메모리가 아닌 이유를 참고하세요.

1단계: 규칙 생성 기능을 켜고 수정하는 즉시 사용하기

create_rule_block은 에이전트가 호출하는 도구이며, Continue 문서에 따르면 "활성화된 경우"에만 작동하므로 사용하기 전에 Agent 모드 도구 목록에서 사용 가능한지 확인하세요. Continue는 대화에서 규칙을 생성하는 대신 처음부터 직접 작성하고 싶을 때 사용할 수 있는 "Add Rules" 버튼도 제공합니다.

가장 효과적인 사용 패턴은 수정과 캡처를 동시에 진행하는 것입니다. "아니요, 여기서는 스트리밍 파서를 사용하세요"라고 말하고 그냥 넘어가는 대신, "아니요, 여기서는 스트리밍 파서를 사용하세요. 배치 엔드포인트는 만 개 이상의 행에서 타임아웃이 발생합니다. 이에 대한 규칙을 만들어주세요"라고 말하세요. 그러면 에이전트는 방금 나눈 대화에서 파생된 규칙을 .continue/rules에 작성하며, 이는 지침뿐만 아니라 그 이유까지 포함하게 됨을 의미합니다.

생성된 파일에서 두 가지를 확인해야 합니다. 이 두 가지가 2단계의 모든 것을 결정하기 때문입니다. Continue 문서에 따르면 규칙은 "적절한 YAML 프론트매터(frontmatter)가 있는 .md 파일이어야 하며", 폴더는 반드시 .continue/rules/여야 합니다. 문제 해결 섹션에서 특별히 언급한 오타인 .continue/rule/이 아니어야 합니다. 그런 다음 에이전트가 작성한 프론트매터를 읽어보세요. 에이전트는 사용자를 대신해 globs, description, alwaysApply에 대한 선택을 내렸을 것이며, 그 선택은 추측에 불과합니다.

이러한 기능을 제공하는 것은 Continue뿐만이 아닙니다. Cursor에도 비슷한 동작을 하는 /create-rule 명령어가 있습니다. 하지만 Continue가 더 명확하게 문서화하고 있는 부분은 검색(retrieval) 측면이며, 바로 이 부분에서 흥미로운 결정들이 이루어집니다.

2단계: 의도에 맞는 검색 동작 선택하기

Continue의 세 가지 프론트매터 필드는 서로 상호작용하여 세 가지 고유한 동작을 만들어내며, 문서에 자세히 설명되어 있습니다.

alwaysApply: true를 설정하면 규칙이 "항상 포함"됩니다. 이는 작업 중인 대상과 무관하게 항상 참인 제약 조건에만 사용해야 합니다. 대조 엔드포인트에 대한 수정 사항은 여기에 해당하지 않습니다.

alwaysApply: false를 설정하면 규칙은 "glob이 존재하고 파일 컨텍스트와 일치하거나, 에이전트가 설명을 기반으로 규칙을 컨텍스트로 가져오기로 결정한 경우에 포함"됩니다. 이는 캡처된 대부분의 수정 사항에 가장 적합한 모드이며, 두 가지 독립적인 트리거를 가집니다. 제약 조건이 적용되는 파일을 알고 있다면 globs를 설정하세요. Continue 문서에서는 glob이 "파일이 컨텍스트로 제공될 때" 일치한다고 설명합니다. 제약 조건이 경로가 아닌 개념에 관한 것이라면 description을 활용하고, 요약이 아닌 검색 쿼리 형태로 작성하세요. Continue는 "alwaysApply가 false일 때 에이전트가 이 설명을 읽고 규칙을 컨텍스트로 가져올지 여부를 결정할 수 있다"고 명시하고 있습니다. 설명이 "대조 제약 조건"으로 되어 있으면 야간 정산 작업을 할 때 실행되지 않을 수 있습니다. 하지만 "대량 엔드포인트, 대조, 정산 및 대규모 행 수에 걸친 페이징에 대한 제약 조건"으로 작성하면 실행될 것입니다.

alwaysApply를 완전히 생략하면 기본값인 "glob이 존재하지 않거나, glob이 존재하고 일치하는 경우 포함"이 적용됩니다. 즉, glob과 alwaysApply가 모두 없는 규칙은 항상 켜져 있게 됩니다. 이는 합리적인 기본값처럼 보이지만 심각한 실수가 될 수 있습니다. 에이전트가 프론트매터가 없는 파일을 생성했다면, 의도치 않게 항상 켜져 있는 규칙을 만든 셈이 됩니다.

알아두어야 할 정렬 세부 사항 한 가지는 "규칙 파일은 사전순(lexicographical order)으로 로드되므로, 파일 이름 앞에 숫자를 붙여 적용 순서를 제어할 수 있다"는 점입니다. 예를 들어 01-general.md 및 02-frontend.md와 같은 이름을 사용할 수 있습니다. 규칙들이 하나의 시스템 메시지로 결합되기 때문에, 실제로는 순서가 우선순위를 결정합니다. 캡처된 수정 사항은 일반적으로 일반적인 규칙보다 뒤에 위치하여, 아래쪽에서 더 일반적인 규칙과 충돌하지 않고 세부 조정 사항으로 읽히도록 하는 것이 좋습니다.

3단계: 폴더가 가득 차기 전에 규칙과 사실을 분리하기

몇 주 동안 규칙을 캡처한 후, .continue/rules 폴더를 읽고 각 파일에 대해 질문해 보세요. 이것은 규칙(convention)인가요, 아니면 사실(fact)인가요?

규칙은 명명 규칙, 에러 처리 형태, 테스트 러너 등 이곳에서 작업이 수행되는 방식을 말합니다. 이는 안정적이고 광범위하게 적용되며, 정확히 시스템 메시지가 필요한 이유에 부합합니다. 이는 그대로 유지하세요. 안정적이지만 규모가 큰 도메인 지식은 세 번째 케이스에 해당하며, 프롬프트가 아닌 저장소에 보관해야 합니다. 이에 대해서는 Claude에게 영구적인 도메인 지식 제공하기를 참고하세요.

사실은 일어난 일을 말합니다. "메모리 회귀 문제 이후 7월에 스트리밍 파서 사용을 중단했습니다." "벤더 샌드박스에는 픽스처 서버가 필요하므로 결제 테스트는 다른 명령을 사용합니다." "불안정한 통합 테스트에 대해 두 가지 해결책을 시도했으나 모두 동일한 이유로 실패했습니다." 이러한 사실들은 규칙에는 없는 특성을 가집니다. 제한 없이 누적되고, 수정되기보다는 대체되며, 대부분 분기당 몇 가지 작업에만 관련이 있습니다.

규칙으로 저장된 사실은 보이지 않게 노후화됩니다. 규칙이 8월에 번복된 결정을 설명하고 있는지 알려주는 장치는 없으며, 번복된 결정이 시스템 메시지 지침으로 제공되는 것은 규칙이 아예 없는 것보다 나쁩니다. 이는 리뷰 이력 시스템이 드리프트되는 것과 동일한 실패 사례이며, 피드백을 통해 개선되는 에이전트에서 살펴본 바 있습니다.

Continue의 문서화된 메커니즘(세 가지 검색 모드가 있는 규칙)은 규칙을 잘 다룹니다. 하지만 팀이 확립한 내용을 누적하고 대체할 수 있는 기록을 보관하는 저장소에 대응하는 기능은 문서에 없습니다. 이는 규칙 시스템의 범위에 대한 설명이지 한계를 지적하는 것이 아닙니다. 시스템 메시지는 어떤 도구에서든 그 작업에 적합한 형태가 아니기 때문입니다.

MemoryLake는 사실에 해당하는 절반의 영역을 보관하는 곳입니다. 리포지토리 외부에 존재하며 확립된 결정을 보관하고, 소리 없는 노후화 대신 대체(supersession)를 지원하며, 실행 중인 에이전트가 MCP 또는 API를 통해 읽을 수 있는 저장소입니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 보내보세요. 동일한 키가 Continue, 팀원의 에디터, 그리고 CI에서도 작동합니다.

2단계: 첫 번째 메모리 업로드하기

현재 재시도 정책의 배경이 된 장애 보고서, 아무도 반복하고 싶지 않은 디자인 리뷰, 그리고 방금 규칙이 아닌 사실로 분류한 규칙 파일 등 프로젝트의 결정 사항이 이미 담겨 있는 문서, 이미지, 파일을 업로드하세요.

3단계: AI 및 에이전트 연결하기

Claude, Codex, OpenClaw 및 기타 에이전트에 MCP 또는 API를 통한 액세스 권한을 부여하세요. Continue에서는 확립된 사실이 시스템 메시지에 영구적으로 상주하는 대신, 관련이 있을 때만 검색되어 제공됨을 의미합니다.

규칙 폴더가 무한정 커지는 일이 없어집니다. 사실을 보관할 다른 장소가 생기면, .continue/rules는 실제 규칙의 크기로 수렴합니다. 대부분의 리포지토리에서 이는 작고 가독성이 높으며 풀 리퀘스트(PR)에서 검토할 수 있는 수준입니다.

설명(description)을 보관용이 아닌 검색용으로 작성하게 됩니다. description이 해야 할 유일한 일이 에이전트가 규칙을 가져올지 여부를 결정하도록 돕는 것뿐일 때, 작성 방식이 달라지며 보관 중인 규칙이 제때 실행되기 시작합니다.

수정 사항이 리포지토리보다 오래 살아남습니다. 규칙은 하나의 체크아웃에 상주합니다. 하지만 외부에서 캡처된 사실은 옆에 있는 다른 서비스에서 동일한 제약 조건이 나타날 때도 사용할 수 있으며, 실제로 반복적인 설명이 가장 많이 발생하는 곳이 바로 여기입니다.

그리고 캡처하는 습관을 유지하는 비용이 매우 저렴해집니다. 이것이 바로 create_rule_block이 제공하는 진정한 가치입니다. 무언가를 기록하는 비용이 단 몇 마디 말로 줄어듭니다. 그것이 올바르게 다시 불러와지는지는 별개의 결정이며, 이제 이를 의도적으로 관리할 수 있습니다.

항상 이유를 포함하세요. "X를 사용하지 마세요"는 무시되기 쉽습니다. "Y 때문에 X를 사용하지 마세요"는 무시되지 않습니다.

프론트매터를 절대 방치하지 마세요. 에이전트가 생성한 내용을 확인하세요. globs와 alwaysApply가 없는 파일은 모든 요청에 적용됩니다.

설명을 레이블이 아닌 쿼리로 작성하세요. alwaysApply가 false일 때 설명은 검색 신호가 됩니다. 실제로 입력할 법한 단어를 포함하세요.

규칙 파일에 번호를 매기세요. 사전순 로드 순서가 실제 우선순위가 됩니다. 일반적인 규칙은 앞쪽에, 세부 조정 사항은 뒤쪽에 배치하세요.

Markdown 파일을 권장합니다. Continue는 규칙이 원래 YAML로 정의되었으나 현재는 Markdown 형식을 권장한다고 명시하고 있습니다. 하나의 형식으로 통일하면 폴더를 검토하기가 더 쉬워집니다.

매달 폴더를 다시 읽어보세요. 규칙을 정리하기 위해서가 아니라, 소리 없이 잘못된 정보가 된 사실들을 찾아내기 위해서입니다.

create_rule_block은 대부분의 도구가 사용자의 자율성에 맡겨두었던 실제 문제를 해결합니다. 즉, 제약 조건을 인지하는 것과 이를 기록하는 것 사이의 마찰을 없애줍니다. "이것에 대한 규칙을 만들어줘"라고 말하면 수정 사항이 추론 과정이 첨부된 파일로 변환되며, 이는 대부분의 수동 작성 규칙보다 더 뛰어난 결과물입니다.

사용자에게 남겨진 절반의 과제는 검색이며, Continue는 이를 올바르게 수행할 수 있는 구성 요소를 제공합니다. 경로 범위 제약 조건을 위한 globs, 개념 범위 제약 조건을 위한 description, 무조건 적용되는 소수의 항목을 위한 alwaysApply, 그리고 우선순위를 위한 사전순 정렬이 그것입니다. 특히 에이전트가 생성한 파일에서 이를 의도적으로 사용하세요. 전혀 실행되지 않는 규칙과 절대 멈추지 않고 실행되는 규칙은 서로 반대 방향으로 실패하며, 두 경우 모두 규칙 폴더가 가득 찬 것처럼 보이기 때문입니다.

그 다음 전체 시스템을 건강하게 유지하기 위한 분류 작업을 수행하세요. 규칙은 시스템 메시지에 속해야 합니다. 사실은 계속 늘어나고 수정 가능한 기록을 보관할 수 있으며 중요한 부분만 돌려줄 수 있는 곳에 속해야 합니다. 이 경계를 올바르게 설정하는 것이 캡처하는 습관이 아무도 읽지 않는 디렉토리로 변하는 것을 방지하는 방법입니다.