내부 개인 설정 전환 작업을 바탕으로 썼다. 사내 티켓·도메인·민감 정보는 빼고, 구조와 판단 기준만 정리한다.

회사 정책 변경으로 AI 개발 도구를 바꿔야 했다.

예전 같으면 꽤 번거로운 일로 느꼈을 것이다. IDE를 바꾸고, 설정을 다시 만들고, 매번 쓰던 프롬프트와 작업 순서를 옮기고, 익숙한 자동화도 포기해야 한다고 생각했을 테니까.

그런데 이번에는 큰 비용 없이 전환할 수 있었다.

이유는 단순했다. 내가 의존하던 핵심이 특정 IDE 자체가 아니라, 그 위에 쌓아 둔 작업 규칙이었기 때문이다. 규칙만 분리해 두면 도구가 바뀌어도 다시 만들 것은 많지 않다.

TL;DR

  • 회사 정책 변경으로 AI 도구가 바뀌어도, 전환 비용은 작업 규칙을 얼마나 분리해 두었는지에 크게 좌우된다.
  • IDE 안에만 있는 규칙은 도구를 바꿀 때 다시 만들어야 한다.
  • 공통 규칙, 작업 절차, 비공개 규칙을 나누면 전환이 쉬워진다.
  • 외부 도구 연동은 그대로 복사하지 말고 도구별로 다시 판단해야 한다.
  • 이번 전환은 “Cursor를 버린 일”이 아니라, Cursor에서 쌓은 작업 방식을 도구 밖으로 꺼낸 일에 가깝다.

문제는 IDE가 아니라 규칙이었다

기존에는 Cursor 안에 많은 것이 있었다.

  • 반복 작업을 처리하는 규칙
  • 특정 상황에서만 쓰는 스킬
  • 리뷰와 마감 순서
  • Jira, Figma, 브라우저 같은 외부 도구 연결
  • 개인적으로만 쓰는 비공개 규칙

이런 것들이 잘 맞물리면 IDE 안에서 작업이 빠르게 굴러간다. 문제는 도구를 바꿔야 할 때다. 규칙이 IDE에 강하게 묶여 있으면 도구 변경이 곧 작업 방식 변경이 된다.

그래서 이번 전환의 핵심 질문은 “어떤 AI 도구를 쓸 것인가?”가 아니었다.

내 작업 규칙을 특정 도구 밖에서도 다시 쓸 수 있는가?

이 질문으로 보면 해야 할 일이 명확해진다. Cursor에서 쓰던 것을 그대로 복사하는 것이 아니라, 규칙을 역할별로 다시 나누면 된다.

나눈 기준

크게 네 가지로 나눴다.

종류 처리 방식
항상 적용되는 작업 원칙 공통 지침으로 이동
특정 작업에서만 필요한 절차 스킬로 분리
외부 도구 연결 도구별로 재검토
비공개 규칙 로컬 전용으로 유지

이 기준만 잡아도 전환은 단순해졌다.

예를 들어 “답변 톤”, “변경 범위를 좁히기”, “비공개 규칙을 공개 영역에 섞지 않기” 같은 것은 항상 적용되는 지침이다.

반대로 “티켓 종료 절차”, “로컬 개발 환경 설정”, “블로그 발행 절차” 같은 것은 항상 읽을 필요가 없다. 그 요청이 들어왔을 때만 읽으면 된다.

도구 전환에서 중요한 것은 모든 규칙을 한 파일에 몰아넣는 것이 아니다. 언제 읽혀야 하는지를 나누는 것이다.

실제로 옮긴 방식

이번 전환에서 가장 먼저 한 일은 규칙의 원본 위치를 바꾸는 것이었다. 말 그대로 Cursor가 읽던 파일 경로에 있던 규칙을 GPT/Codex가 읽을 수 있는 쪽으로 옮겼다.

기존에는 Cursor 전용 사용자 설정 아래에 규칙이 있었다. 이 상태에서는 Cursor를 계속 쓸 때는 편하지만, 다른 AI 도구로 넘어갈 때마다 같은 내용을 다시 옮겨야 한다. 그래서 공유 가능한 규칙은 별도 저장소로 빼고, GPT/Codex가 읽는 개인 설정과 스킬 위치가 그 저장소를 바라보게 했다.

구조만 보면 단순하다.

~/.cursor 안의 개인 규칙
→ ~/Codes/my-gpt 안의 공유 가능한 규칙 저장소
→ ~/.codex, ~/.agents처럼 GPT/Codex가 읽는 위치

여기서 중요한 것은 경로 이름 자체가 아니다. 핵심은 규칙의 원본을 특정 IDE 내부에만 두지 않았다는 점이다. Cursor가 읽던 위치에서 GPT/Codex가 읽는 위치로 옮기되, 실제 원본은 도구 밖의 저장소에 두었다.

이렇게 바꾸니 IDE를 바꾸는 일이 곧 규칙을 다시 쓰는 일이 아니게 됐다. 새 도구에서는 그 도구가 규칙을 읽는 연결 지점만 맞추면 됐다.

예를 들어 항상 적용되어야 하는 작업 태도와 기본 원칙은 Codex의 개인 지침으로 옮겼다. 반대로 블로그 작성, 티켓 종료, 로컬 개발 서버 실행처럼 특정 요청에서만 필요한 절차는 각각 스킬로 나눴다. 기존 Cursor 규칙 파일을 그대로 버린 것이 아니라, 새 구조 안에서 어떤 것은 공통 지침이 되고, 어떤 것은 스킬이 되고, 어떤 것은 참고용 레거시가 됐다.

기존 Cursor 규칙도 필요하면 다시 확인할 수 있도록 레거시 영역에 남겨 두었다. 다만 새 도구가 직접 읽어야 하는 규칙과, 참고용으로만 남길 규칙은 분리했다.

이 작업 덕분에 전환은 “새 도구에 맞춰 전부 다시 작성하기”가 아니라 “규칙을 읽는 연결 지점 바꾸기”에 가까워졌다.

옮기면서 줄인 것

처음에는 기존 설정을 최대한 많이 옮기고 싶었다. 하지만 곧 생각을 바꿨다.

전환은 복사가 아니라 정리다.

기존 도구에서 잘 쓰던 설정이라도 새 환경에서 그대로 좋은 선택이라는 보장은 없다. 예를 들어 GitHub 작업은 여러 방식으로 붙일 수 있지만, 이미 gh CLI가 충분히 명확했다. 인증과 디버깅도 CLI 쪽이 단순했다. 그래서 GitHub는 굳이 새 방식으로 옮기지 않았다.

Slack도 마찬가지였다. 기존 앱의 인증 정보를 그대로 쓰면 인증 화면은 열릴 수 있다. 하지만 어떤 앱 권한으로 연결되는지 설명이 애매해진다. 이런 경우에는 억지로 옮기지 않는 편이 낫다.

반대로 업무 관리 도구나 디자인 도구처럼 작업 맥락을 직접 읽어야 하는 도구는 전용 연결을 유지하는 편이 유리했다.

결론은 이렇다.

붙일 수 있는가? 보다
왜 붙여야 하는가? 를 먼저 본다.

비공개 규칙은 끝까지 로컬에 둔다

이번 전환에서 가장 조심한 부분은 비공개 규칙이었다.

개인 계정, 투자, 토큰, 인증서, 사내 링크처럼 공개 영역에 들어가면 안 되는 정보는 반드시 로컬에만 있어야 한다. 하지만 로컬에만 둔다고 해서 AI 도구가 못 쓰게 만들 필요는 없다.

해결은 단순했다.

  • 공유 가능한 규칙은 공통 설정으로 관리한다.
  • 비공개 규칙은 로컬에 둔다.
  • AI 도구가 작업할 때는 로컬에서만 그 규칙을 볼 수 있게 한다.

즉, 공유 영역에는 올리지 않지만 내 로컬 작업 환경에서는 계속 사용할 수 있게 했다.

이 구조가 중요하다. “공개 가능한 것”과 “내 로컬에서만 보여야 하는 것”을 섞지 않으면, 도구를 바꿔도 비공개 경계를 다시 설계할 필요가 없다.

운영 규칙은 남기고, 민감 정보는 빼기

전환 과정에서 로컬 개발 환경 설정도 함께 정리했다.

여기서도 원칙은 같았다.

남긴 것은 절차다. 오류가 났을 때 무엇을 확인할지, 로컬 개발 서버를 어떻게 띄울지, 브라우저 테스트에서 어떤 예외를 허용할지 같은 운영 규칙은 남겼다.

반대로 인증서 파일, 개인 키, 환경변수 파일은 남기지 않았다.

이 차이를 지키면 운영 규칙은 공유할 수 있고, 민감 정보는 새지 않는다.

비용이 작았던 이유

도구를 바꾼다고 해서 모든 것을 다시 만들 필요는 없었다.

이미 작업 방식이 규칙과 절차로 나뉘어 있었기 때문이다. Cursor 안에 있던 것들을 다음처럼 재분류하면 됐다.

  • 매번 필요한 원칙
  • 특정 요청에서만 필요한 절차
  • 로컬에만 둬야 하는 비공개 규칙
  • 다시 연결할 외부 도구
  • 버려도 되는 도구별 편의 설정

이 분류가 끝나면 전환은 꽤 기계적이다.

새 도구가 무엇이든 결국 필요한 것은 비슷하다.

  • 어떤 규칙을 항상 읽을 것인가
  • 어떤 절차를 필요할 때만 읽을 것인가
  • 어떤 도구에 접근할 것인가
  • 어떤 정보는 절대 공유 영역에 넣지 않을 것인가

이 질문에 답할 수 있으면 AI 도구 전환은 큰 프로젝트가 아니다.

배운 점

1. AI 도구보다 작업 규칙이 오래 간다

도구는 계속 바뀐다. Cursor를 쓰다가 Codex를 쓰고, 또 다른 도구를 쓰게 될 수 있다.

하지만 리뷰 순서, 마감 기준, 비공개 경계, 검증 절차는 더 오래 간다.

따라서 중요한 것은 “어떤 IDE가 정답인가”가 아니라, 내 작업 방식이 도구 밖에 남아 있는가다.

2. 규칙은 작게, 절차는 따로 둔다

항상 읽히는 규칙은 짧아야 한다. 모든 런북을 공통 지침에 넣으면 오히려 매번 방해가 된다.

자주 쓰지만 특정 상황에서만 필요한 내용은 절차로 분리하는 편이 낫다. 그래야 AI 도구도 필요한 순간에만 그 문맥을 읽는다.

3. 전환은 “복사”가 아니라 “가지치기”다

기존 설정을 다 옮기는 것이 목표가 아니다.

이번 도구에서도 필요한지 다시 봐야 한다. 어떤 것은 옮기고, 어떤 것은 CLI로 남기고, 어떤 것은 아예 버리는 것이 맞다.

4. 비공개 경계는 처음부터 설계해야 한다

비공개 규칙은 나중에 빼기 어렵다. 처음부터 공유할 것과 로컬에만 둘 것을 나누는 편이 안전하다.

지금의 결론

이번 전환은 특정 제품을 버린 일이 아니다.

회사 정책 변경 때문에 도구를 바꿔야 했지만, 실제 전환 비용은 크지 않았다. 작업 규칙을 제품 밖으로 꺼낼 수 있었기 때문이다.

IDE는 바뀔 수 있다. 모델도 바뀔 수 있다. 구독 정책도 바뀔 수 있다.

그때마다 처음부터 다시 시작하지 않으려면, 내 작업 방식은 도구 안이 아니라 도구 밖에 있어야 한다.

내가 이번에 정리한 기준은 세 줄이다.

규칙은 작게.
절차는 필요할 때만.
비공개는 로컬에.

이 정도만 지켜도 AI 도구 전환은 덜 무겁다.