컨텍스트 손실 없이 GitHub Copilot에서 Tabnine으로 마이그레이션하는 방법 (2026)

Copilot의 커스터마이징 영역에는 5개의 레이어가 있으며, 그중 3개만 파일입니다.

개인 지침(Personal instructions). 문서는 범위와 위치를 모두 명확히 규정하고 있습니다. 이 지침은 "GitHub의 GitHub Copilot Chat에서만 지원"되며, "GitHub.com의 Copilot Chat 페이지 팝업에서" 설정하고, Copilot은 이를 사용자 본인에게만 "적용"합니다. 파일도 없고, 리포지토리도 없습니다. 개인별로 웹 페이지에 있는 텍스트 상자만 존재할 뿐입니다.

리포지토리 사용자 지정 지침(Repository custom instructions)은 세 가지 유형이 있습니다. .github 디렉터리의 copilot-instructions.md 파일에 있는 리포지토리 전반의 지침, .github/instructions 내부 또는 하위의 .instructions.md로 끝나는 하나 이상의 파일에 있는 경로별 지침, 그리고 문서에서 "리포지토리 전반의 사용자 지정 지침과 유사하지만 현재 모든 Copilot 기능에서 지원되지는 않는다"고 설명하는 에이전트 지침(이는 AGENTS.md, CLAUDE.md 또는 GEMINI.md 파일에 지정됨)이 있습니다.

조직 사용자 지정 지침(Organization custom instructions)은 조직 소유자가 Copilot 설정에서 지정하며, 문서의 표현을 빌리자면 "해당 조직으로부터 Copilot 구독을 받는지 여부와 관계없이 조직의 모든 구성원"에게 적용됩니다.

이제 이들이 해결되는 순서는 다음과 같습니다.

"Copilot에 전송되는 요청에는 여러 유형의 사용자 지정 지침이 적용될 수 있습니다. 개인 지침이 가장 높은 우선순위를 가집니다. 그다음으로 리포지토리 지침이 오고, 조직 지침이 마지막으로 우선순위를 갖습니다. 그러나 관련된 모든 지침 세트가 Copilot에 제공됩니다."

사람들이 흔히 건너뛰는 부분이 바로 마지막 문장입니다. 우선순위는 충돌을 해결할 뿐, 레이어를 제거하지 않습니다. 적용 가능한 모든 지침은 여전히 전송됩니다. 따라서 조직 표준과 모순되는 개인 지침은 조직 표준을 대체하는 것이 아니라, 두 지침이 모두 컨텍스트에 남아 있는 상태에서 더 높은 순위를 차지할 뿐입니다.

Tabnine 측에서 이에 해당하는 영역은 가이드라인(guidelines)입니다. 문서에서는 이를 "프로젝트의 /.tabnine/guidelines/ 디렉터리에 저장된 마크다운 파일"로 설명하며, 이 디렉터리는 홈 디렉터리나 프로젝트별 디렉터리 모두에 위치할 수 있다고 명시합니다. Tabnine 문서가 제시하는 비유는 다음과 같습니다. "이를 다른 에이전트 도구들이 사용하는 agents.md 파일과 유사하게 생각하십시오." 권장 크기는 "guidelines.md 파일을 500행 이하로 유지하는 것"입니다.

그리고 마이그레이션의 판도를 뒤집는 문장이 나옵니다. 관리자 콘솔(Admin Console)에 입력된 가이드라인에 대한 설명입니다.

"Guidelines that are input here will have the same effect as guidelines listed in your guidelines.md file, but they will take precedence over personal guidelines that exist in the guidelines.md file."

즉, 파일은 전송됩니다. Tabnine이 여러 가이드라인 파일을 지원하므로 경로별 범위 지정도 대략적으로 전송됩니다. 전송되지 않는 것은 해결 순서입니다. 그리고 마이그레이션할 대상이 전혀 없는 것은 바로 팝업입니다. 리포지토리에 존재한 적도 없고, 검토된 적도 없으며, 다른 누구에게도 보이지 않았던 개인별 지침 말입니다.

이 모든 것과 별개로 구분해야 할 점은, 이러한 레이어 중 어느 것도 코드베이스 인식(codebase awareness)이 아니라는 점입니다. 지침 파일은 어시스턴트에게 어떻게 행동해야 하는지를 알려줄 뿐, 코드에 무엇이 포함되어 있는지를 알려주지 않습니다. 그렇기 때문에 Copilot forgetting codebase context는 Copilot이 규칙을 무시한다는 불만과는 다른 문제입니다. Tabnine의 해결책은 Personalization과 Connection 기능이며, 두 번째 문제에 대한 해결책은 가이드라인입니다. 한 문제를 해결할 것이라 기대하며 다른 문제를 마이그레이션하지 마십시오.

작업을 계획하기 전에 알아두어야 할 두 번째 구조적 차이점이 있습니다. 이 차이점은 팀을 둘로 나눌 수 있기 때문입니다. Tabnine의 CLI는 IDE 플러그인처럼 프로젝트 가이드라인 디렉터리를 읽지 않습니다. 문서의 시작 부분에 이 차이가 명확하게 기술되어 있습니다.

"Agent guidelines are managed differently in Tabnine CLI than they are for the Tabnine IDE plugin."

CLI에는 두 가지 흐름이 있습니다. 조직 및 서비스 계정 지침은 "에이전트의 운영 컨텍스트에 추가"되며, CLI가 시작될 때 인증된 계정에 대해 자동으로 가져옵니다. 이와 별개로, 코딩 가이드라인은 에이전트가 언어별 규칙이 필요할 때 호출하는 내장된 Tabnine Coaching Guidelines 도구를 통해 액세스할 수 있습니다. 문서는 이 두 가지를 신중하게 구분하고 있는데, 토글 스위치가 둘 중 하나만 제어하기 때문입니다.

"This setting doesn't control whether organization or service-account instructions are fetched and added to the session context."

두 단계로 진행되며, 첫 번째 단계는 모두가 건너뛰는 단계입니다.

1단계: 팝업에서 개인 지침 가져오기

파일을 하나라도 건드리기 전에, 팀의 모든 구성원에게 GitHub.com의 Copilot Chat 페이지를 열고 자신의 개인 지침을 소리 내어 읽어달라고 요청하십시오. 요약하지 말고 그대로 읽어야 합니다.

이 작업은 번거로운 일처럼 느껴질 수 있지만, 두 가지 이유로 전체 마이그레이션에서 가장 가치 있는 시간입니다. 첫째, 개인 지침은 Copilot의 우선순위에서 최상위에 위치하므로, 그 안에 포함된 내용이 리포지토리 표준 및 조직 설정과의 충돌에서 조용히 승리해 왔음을 의미합니다. 둘째, 이 지침들은 보이지 않습니다. grep할 파일도 없고, 검토할 PR도 없으며, 감사 추적도 불가능합니다. 만약 누군가가 8개월 전에 "항상 이전 버전의 클라이언트 라이브러리를 사용하세요. 새 버전은 프록시를 손상시킵니다"라고 작성했다면, 그 지침은 그 이후로 계속 그 사람의 출력 결과에 영향을 미쳤을 것이고 다른 누구도 그 존재를 알지 못했을 것입니다.

수집된 내용을 두 개의 더미로 분류하십시오. 응답 언어, 상세도, '한 줄에 하나의 개념만 설명하기'와 같은 순수한 개인적 선호도는 개인 영역에 그대로 둡니다. 개인의 탈을 쓴 프로젝트 관련 사실들은 리포지토리로 이동해야 합니다. 원래 그곳에 있어야 했기 때문입니다. 이는 agents ignoring your instruction files의 이면에 있는 실패 모드와 동일합니다. 결국 승리하는 지침은 여러분이 작성했다고 생각하는 지침이 아닙니다.

팝업을 확인하는 동안, setting up Copilot memory in VS Code에서 다룬 IDE의 메모리 기능 등 Copilot의 다른 사용자별 영역 역시 개인별로 적용되며 파일이 아니라는 점에 유의하십시오. 이 내용도 함께 확인하십시오.

2단계: 파일 레이어를 가이드라인으로 재구축하고 모든 충돌을 다시 결정하기

이제 기계적인 복사 작업이 이어지며, 그 후에는 기계적이지 않은 작업이 기다리고 있습니다.

리포지토리 전반의 copilot-instructions.md는 .tabnine/guidelines/의 가이드라인 파일이 됩니다. 경로별 .instructions.md 파일은 추가 가이드라인 파일이 됩니다. Tabnine은 디렉터리에서 여러 파일을 읽으므로 병합하지 말고 분리된 상태로 유지하고, 다루는 내용에 맞게 이름을 지정하십시오. AGENTS.md는 기술 스택의 다른 도구들이 읽는 개방형 규칙이므로 그대로 둘 수 있습니다. 다만 Tabnine의 가이드라인 디렉터리가 자체 문서에서 가리키는 위치라는 점만 유의하십시오. 지침 파일이 원래 다른 환경에서 시작되었다면, moving a CLAUDE.md into Copilot에서 해당 파일들이 도달한 형태를 다룹니다.

진행하는 김에 한 가지 바로잡을 점이 있습니다. Tabnine 문서는 이 비유를 소문자인 agents.md로 작성했습니다. 하지만 동일한 규칙을 읽는 다른 도구들은 대문자 파일명을 요구하며, 소문자 파일명은 경고 없이 건너뜁니다. 여러 도구에서 공유하는 리포지토리에서는 이름을 AGENTS.md로 지정하십시오.

그다음이 진짜 작업입니다. 조직 표준과 누군가의 개인 지침이 일치하지 않았던 모든 부분에 대해 이제 승자를 선택해야 합니다. Tabnine의 관리자 콘솔이 여러분을 대신해 승자를 선택할 것이며, 그 결과는 Copilot이 선택했던 것과 정반대일 것이기 때문입니다. 충돌을 하나씩 검토하면서 각 규칙을 어떤 레이어에 둘지 결정하십시오. 진정한 조직 표준에 해당하는 것은 관리자 콘솔에 배치하며, 이제 이는 모든 사람의 로컬 파일보다 우선합니다. 문서에 언급된 전파 지연 시간에 유의하십시오. 변경 사항은 "15분 후에 IDE 확장 프로그램에 적용되거나, IDE 또는 확장 프로그램을 재시작할 때 적용됩니다."

이 단계는 어떤 마이그레이션 가이드도 대신해 줄 수 없는 부분을 발견하는 곳이기도 합니다. 어떤 규칙이 승리할지 결정하려면 각 규칙이 왜 존재하는지 알아야 하지만, 그 정보는 두 도구 어디에도 들어있지 않습니다.

2단계에서 해결하려는 충돌이 어려운 유일한 이유는 그 이유가 기록되지 않았기 때문입니다. "이전 버전의 클라이언트 라이브러리 사용" 대 "현재 SDK로 표준화"라는 두 가지 명령형 규칙은 그 자체로는 해결할 수 없습니다. 하지만 그중 하나가 프록시가 고장 났던 주에 작성되었고, 그 프록시가 지난 6월에 교체되었다는 사실을 알게 된다면 문제는 아주 단순해집니다.

MemoryLake은 두 도구의 외부에서 이러한 레이어(결정 사항, 기각된 대안, 이유)를 유지하며, MCP 또는 API를 통해 요청하는 모든 에이전트에 이를 제공합니다. 가이드라인은 .tabnine/guidelines/에 짧고 명령조로 유지되고, 관리자 콘솔은 표준을 보유하며, 각 표준 뒤에 숨겨진 '이유'는 어떤 도구를 사용하는 누구든 쿼리할 수 있게 됩니다.

1단계: API 키 생성

키를 생성하고 약 30초 만에 첫 번째 요청을 완료해 보세요. 위의 2단계를 진행하기 전에 이 작업을 수행하면, 충돌을 해결할 때마다 기록해 둘 공간을 확보할 수 있습니다.

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

유지한 모든 규칙에 대해 무엇이 결정되었고, 무엇이 제외되었으며, 그 이유는 무엇인지 기록하십시오. 1단계에서 수집한 개인 지침이 여기서 가장 풍부한 원천이 됩니다. 대부분의 지침에는 실제 장애나 사건이 담겨 있기 때문입니다. 관련 문서와 파일도 같은 위치에 업로드합니다.

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

Tabnine, Claude, Codex 및 기타 에이전트에 MCP 또는 API를 통해 액세스 권한을 부여하십시오. 다음 표준이 제안될 때, "그거 예전에 시도해 보지 않았나요?"에 대한 답변이 그 추론과 함께 제공될 것입니다.

첫 번째 변화는 보이지 않던 레이어가 더 이상 보이지 않는 상태로 남지 않는다는 점입니다. Copilot의 가장 높은 우선순위 지침 영역은 개인별 텍스트 상자였습니다. 마이그레이션 이후 이에 상응하는 콘텐츠는 명시적인 개인적 선호도이거나 기록된 프로젝트 결정 사항이 되며, 후자는 팀 전체가 읽을 수 있습니다.

두 번째는 관리자 콘솔의 우선순위가 함정이 아닌 유용한 기능이 된다는 점입니다. 조직 표준이 진정으로 조직적인 성격(검토되고, 논리적 근거가 있으며, 기록됨)을 갖추게 되면, 로컬 파일보다 우선하도록 설정하는 것이 원래 원하던 방향이 됩니다. 이러한 역전 현상은 관리자 콘솔이 단지 추측성 규칙만 담고 있을 때만 문제가 됩니다.

세 번째는 IDE와 CLI의 분리로 인해 팀이 파편화되는 현상이 멈춘다는 점입니다. IDE를 사용하는 개발자는 가이드라인 파일을 읽고, CLI를 사용하는 개발자는 조직 및 서비스 계정 지침과 Coaching Guidelines 도구를 제공받습니다. 이들은 서로 다른 메커니즘이지만, 양쪽 모두가 쿼리할 수 있는 공유 추론 레이어가 있다면 두 환경의 답변을 일치시킬 수 있습니다.

네 번째는 다음 마이그레이션이 진짜 단순한 파일 복사 작업이 된다는 점입니다. 이번 마이그레이션을 어렵게 만들었던 부분, 즉 명령형 규칙에서 의도를 재구성하는 작업은 단 한 번만 수행하면 됩니다. 이는 what coding agents actually read가 특정 도구가 선호하는 파일 형식보다 더 중요한 이유와 일맥상통합니다.

파일을 감사하기 전에 팝업을 먼저 감사하십시오. 개인 지침은 Copilot에서 최우선 순위이며 파일 흔적이 남지 않습니다. 이전 설정 중에서 나중에 다시 복구할 수 없는 유일한 부분입니다.

표준은 관리자 콘솔에, 선호도는 로컬 파일에 두십시오. 이제 우선순위 규칙은 이러한 분리를 장려하며, 로컬에 표준을 중복으로 두어 이에 맞서는 것은 결국 콘솔이 승리하는 충돌만 만들어낼 뿐입니다.

가이드라인 파일은 짧고 분리된 상태로 유지하십시오. 문서에서는 파일당 500행 이하를 권장하며, 디렉터리는 여러 파일을 수용할 수 있습니다. 하나의 긴 파일보다 파일당 하나의 주제를 다루는 것이 좋습니다.

전파 지연 시간을 기억하십시오. 관리자 콘솔의 변경 사항은 대기 시간이나 재시작 후에 IDE 확장 프로그램에 도달합니다. 표준이 변경되면 구성원들이 알아서 확인했을 것이라 가정하지 말고 직접 알리십시오.

CLI가 프로젝트 가이드라인을 읽는다고 가정하지 마십시오. CLI의 문서화된 흐름은 조직 및 서비스 계정 지침과 Coaching Guidelines 도구입니다. 팀이 두 영역으로 나뉘어 있다면 각 영역이 실제로 무엇을 로드하고 있는지 확인하십시오.

대문자 AGENTS.md를 사용하십시오. 한 벤더의 소문자 예시는 다른 벤더에게는 경고 없이 건너뛰는 원인이 될 수 있으며, 올바르게 작성하는 데 비용이 들지 않습니다.

규칙 옆에 이유를 함께 작성하십시오. 이번 마이그레이션에서 해결한 모든 충돌은 누군가가 원인을 밝히지 않고 명령형 규칙만 작성했기 때문에 발생했습니다. 이유를 기록할 공간이 없다면 다음 충돌 역시 마찬가지일 것입니다.

GitHub Copilot에서 Tabnine으로 마이그레이션하면 3개의 파일 레이어는 깔끔하게 이동하지만, 눈에 보이지 않는 한 가지가 역전됩니다. Copilot은 개인 지침을 최우선 순위로, 조직 지침을 최하위 순위로 문서화하면서도 적용 가능한 모든 레이어를 모델에 전송합니다. 반면 Tabnine은 관리자 콘솔이 개인 guidelines.md보다 우선한다고 명시합니다. 이를 해결하지 않고 파일만 복사하면, 이전에는 승리했던 규칙들이 동일한 입력값에 대해 조용히 패배하기 시작할 것입니다.

마이그레이션을 안전하게 만드는 작업은 복사가 아닙니다. 팝업을 비우고, 순수한 선호도와 프로젝트 사실을 분류하며, 각 규칙을 어떤 레이어에 둘지 결정하는 일입니다. 그리고 이는 규칙이 왜 존재하는지 알아야만 가능합니다. 두 도구의 외부에서 이를 한 번만 기록해 두면, 향후의 모든 이동은 이번 마이그레이션이 겉으로 보였던 모습, 즉 마크다운 파일을 이동하고 로그인하는 단순한 작업이 될 것입니다.