새 AI가 나올 때마다 시스템을 갈아엎지 않으려면 — 오래가는 중심과 갈아 끼우는 바깥층

📝 한줄 요약

새로운 AI 모델과 도구가 나올 때마다 내 작업환경을 다시 만들어야 할 것 같아 지쳤다. 문제는 새 기술이 계속 나오는 것이 아니라, 오래 가져갈 업무 기준과 자주 바뀌는 실행 도구가 한 덩어리로 붙어 있던 것이었다. 둘을 나누고 시스템을 한 장의 지도로 그려본 뒤에야 “중심은 보존하고 바깥만 갈아 끼우면 된다”는 감각이 생겼다.

바쁘시면 이것만 읽어도 돼요:

• 새 AI가 나올 때마다 지침과 폴더를 전부 옮기는 방식은 오래 유지하기 어렵다.
• 내가 계속 보유해야 할 것은 모델이 아니라 목표, 자료, 권한, 완료 기준, 검수 방법과 기록이다.
• Claude나 Codex 같은 AI와 검색·브라우저·MCP 같은 도구는 필요할 때 교체하는 바깥층으로 두었다.
• 공통 지침을 특정 도구의 파일에 복사하지 않고, 하나의 원본과 얇은 연결 파일로 나누었다.
• 구조를 그래프로 보자 보이지 않던 시스템의 흐름이 처음으로 이해됐고, 막연한 불안도 줄었다.
• 아직 완전한 자동 위임은 아니지만, 다음 도구가 나와도 전체 시스템을 다시 짓지 않을 기준은 생겼다.

🎯 이런 분들께 도움돼요

• 새로운 AI 도구가 나올 때마다 지금 시스템을 버리고 옮겨야 할 것 같은 사람
• Claude에서는 잘 되던 지침이 Codex에서는 적용되지 않아 곤란했던 사람
• 전역 지침, 프로젝트 지침, 스킬과 메모리가 계속 늘어나 관리가 어려운 사람
• 내 작업환경이 실제로 어떻게 연결되어 있는지 눈에 보이지 않아 불안한 비개발자
• AI를 오래 쓰고 싶지만 특정 모델이나 서비스에 모든 것을 맡기고 싶지는 않은 사람

😫 문제 상황 — 새 기술을 따라가려다 유지보수만 하게 될 것 같았다

AI를 공부하다 보면 새로운 모델과 도구가 계속 나온다. 어떤 것은 가상 컴퓨터를 쥐여주고 혼자 일하게 하고, 어떤 것은 여러 에이전트를 조직처럼 움직이게 한다. 내가 원하던 기능이 새 도구에 들어 있는 것을 보면 당연히 써보고 싶어진다.

그런데 반가움보다 부담이 먼저 들 때가 많았다.

“저걸 쓰려면 지금까지 만든 지침을 또 옮겨야 하나?”

“새 도구의 폴더 구조와 설정 방식에 다시 맞춰야 하나?”

“몇 달 뒤 더 좋은 것이 나오면 또 이사해야 하나?”

모델이 좋아지면 프롬프트를 쓰는 방식도 달라졌다. 예전에는 빈틈없이 긴 지침과 자세한 스펙을 주는 것이 중요해 보였는데, 모델 성능이 오르자 지나치게 빽빽한 지침이 오히려 방해가 되기도 했다. 도구가 바뀌면 읽는 파일도 달랐다. Claude는 CLAUDE.md를 읽지만 Codex는 같은 방식으로 움직이지 않았다.

나는 최근 Claude를 주로 사용하면서 중요한 규칙을 CLAUDE.md에 계속 넣고 있었다. 당장은 편했다. 하지만 Codex로 작업하면 그 내용을 제대로 이어받지 못했다. 그러면 다시 설명해야 했고, 설명하지 못한 부분에서는 엉뚱한 폴더를 만들거나 오래된 규칙을 따르는 일이 생겼다.

그 문제를 막으려고 전역 지침에 더 많은 내용을 넣었다. 어느 프로젝트에서든 읽히게 만들고 싶었기 때문이다. 그 결과는 반대였다.

• 모든 프로젝트에 필요한 규칙과 특정 프로젝트에만 필요한 규칙이 섞였다.
• 같은 내용이 여러 AI용 파일에 복사됐다.
• 어느 파일이 원본인지 알기 어려워졌다.
• 규칙 하나를 고치면 다른 사본은 낡은 채로 남았다.
• 시스템을 정리하는 시간이 실제 일을 하는 시간보다 커질 조짐이 보였다.

새 기술을 잘 따라가고 싶어서 만든 시스템이 오히려 새 기술을 시도하기 무서운 시스템이 되어가고 있었다.

💡 전환점 — 시스템에는 잘 안 바뀌는 것과 자주 바뀌는 것이 함께 있었다

이 문제를 이야기하다가 단순하지만 중요한 구분을 만났다.

시스템 전체가 매번 바뀌는 것이 아니다. 오래 유지되는 중심과 자주 바뀌는 바깥이 붙어 있어서 전부 바뀌는 것처럼 느껴졌던 것이다.

내가 정말 오래 보유해야 하는 것은 특정 AI 모델이 아니었다.

• 내가 이루려는 목표
• 내가 쌓아온 문서와 지식
• AI가 해도 되는 일과 하면 안 되는 일
• 무엇을 완료라고 볼지 정하는 기준
• 결과를 어떻게 검수할지 정하는 방법
• 작업이 끝난 뒤 무엇을 기록하고 다음에 어떻게 이어갈지에 대한 계약

반대로 자주 바뀌어도 되는 것도 있었다.

• Claude, Codex 같은 AI 모델과 실행 서비스
• 각 도구가 지침을 읽는 파일 이름과 방식
• 검색, 브라우저, 파일, MCP 같은 작업 도구
• 화면과 명령어
• 한 작업을 어느 AI에게 나눠줄지 정하는 방식

이 둘을 한 덩어리로 관리하고 있었기 때문에 AI를 바꾸는 일이 곧 시스템 전체를 이사하는 일처럼 느껴졌던 것이다.

🗺️ 보이지 않던 시스템을 한 장의 흐름으로 그렸다

나는 비개발자라서 파일 이름과 설정 목록만 보면 전체 구조가 잘 잡히지 않는다. 문서가 열 개 있다는 사실을 알아도 그 열 개가 어떤 순서로 움직이는지 보이지 않으면 계속 불안하다.

이번에는 시스템을 파일 목록이 아니라 흐름으로 그려보았다.

나의 목표와 자료
      ↓
업무 의뢰서
목표 · 자료 · 권한 · 완료 조건
      ↓
교체 가능한 AI와 도구
Claude · Codex · 검색 · 브라우저 · 파일
      ↓
검수대
완료 기준 · 실제 동작 · 안전 · 근거
      ↓
결과 상자
결과 · 변경 내용 · 남은 문제 · 다음 행동
      ↓
다시 내 기록과 지식으로

이 그림을 보고 나서야 처음으로 “아, 내 시스템은 이런 식으로 움직이는구나”라는 감각이 들었다.

AI는 내 시스템 그 자체가 아니었다. 가운데서 일을 수행하는 교체 가능한 작업자였다. 특정 AI가 사라지거나 더 좋은 모델이 나와도, 앞의 업무 의뢰서와 뒤의 검수·기록 방식이 남아 있다면 전체 흐름은 유지할 수 있었다.

이 구조는 기술적으로 거창해서 의미가 있었던 것이 아니다. 눈에 보이지 않던 것을 내가 이해할 수 있는 모양으로 바꿔주었다는 점이 중요했다. 시스템을 이해하지 못해서 생기던 막연한 불안이 “어느 부분을 보존하고 어느 부분을 바꾸면 되는지” 판단할 수 있는 문제로 바뀌었다.

🔧 실제로 바꾼 것

1. 공통 원칙의 원본을 한 곳으로 좁혔다

Claude용 파일과 Codex용 파일에 같은 규칙 전문을 각각 복사하는 방식을 줄였다. 공통 규칙은 하나의 원본에 두고, 각 도구가 그 원본을 찾아가도록 연결했다.

여기서 연결 파일은 번역기이자 안내판에 가깝다.

공통 규칙 원본
   ├─ Claude가 읽는 얇은 입구
   ├─ Codex가 읽는 얇은 입구
   └─ 다른 실행기가 읽는 얇은 입구

도구별 입구에는 그 도구에서만 필요한 최소한의 설명만 둔다. 업무 원칙 전체를 복사하지 않는다. 그러면 공통 규칙을 한 번 고쳤을 때 각 사본을 찾아다니며 다시 수정할 필요가 줄어든다.

2. 전역 규칙과 프로젝트 규칙을 분리했다

모든 프로젝트에 적용할 규칙과 한 프로젝트에서만 필요한 사실을 나눴다.

전역에는 이런 것을 남겼다.

• 사용자에게 쉽게 설명하기
• 기존 파일과 관련 없는 변경 보호하기
• 삭제나 외부 공개처럼 위험한 일은 먼저 확인하기
• 현재 사실과 과거 기록을 구분하기

프로젝트에는 이런 것을 두었다.

• 이 프로젝트의 목표
• 지금 해야 할 일
• 완료 조건과 검증 방법
• 건드리면 안 되는 범위
• 최근 결정과 다음 작업

이렇게 나누자 다른 프로젝트의 사정이 전역 지침에 계속 쌓이는 것을 막을 수 있었다.

3. 파일 이름보다 역할을 먼저 정했다

이전에는 CLAUDE.md, AGENTS.md, HANDOFF.md 같은 파일 이름부터 보였다. 하지만 파일 이름만 외우면 새로운 도구가 나왔을 때 다시 혼란스러워진다.

그래서 먼저 역할을 정했다.

도구가 바뀌면 이 역할에 맞는 새 입구만 연결하면 된다. 중심 문서의 의미까지 다시 만들 필요는 없다.

4. 지침이 존재하는지뿐 아니라 실제로 읽히는지도 확인했다

파일을 만들어두었다고 AI가 반드시 읽는 것은 아니었다. 특히 실행 도구가 바뀌면 “분명 지침이 있는데 왜 모르지?”라는 일이 생겼다.

그래서 파일의 존재만 확인하지 않고, Claude와 Codex처럼 서로 다른 실행 환경에서 대표 규칙을 실제로 따르는지 확인했다. 처음에는 검사 환경이 실제 사용 환경과 달라 거짓 경고가 나오기도 했다. 그 경험 때문에 검사 결과도 무조건 믿지 않고, 실제 실행 조건이 같은지 함께 보게 됐다.

이 과정에서 배운 것은 단순했다.

지침을 썼다는 사실과 AI가 그 지침을 읽고 행동했다는 사실은 다르다.

5. 새 도구는 전체 이사가 아니라 얇은 어댑터로 받아들이기로 했다

앞으로 새로운 에이전트 도구가 나와도 먼저 모든 자료를 옮기지 않기로 했다.

대신 세 가지를 확인한다.

1. 지금 시스템에 없는 어떤 능력을 주는가?
2. 기존 업무 의뢰서와 결과 형식을 그대로 사용할 수 있는가?
3. 그 도구를 빼도 내 자료와 기록이 남는가?

세 조건을 만족하면 새 도구는 교체 가능한 작업자나 얇은 어댑터로 붙인다. 만족하지 못하고 그 서비스 안에 모든 지침과 기록을 다시 넣어야 한다면, 도입 비용을 더 신중하게 본다.

📊 무엇이 달라졌나

가장 큰 변화는 “이제 어떤 AI든 완벽하게 위임할 수 있다”가 아니다. 아직 거기까지 가지 못했다.

달라진 것은 새 기술을 바라보는 기준이다.

이전에는 새 도구를 보면 이런 생각부터 했다.

저걸 쓰려면 지금까지 만든 걸 어떻게 옮기지?

지금은 이렇게 묻게 됐다.

저 도구는 내 흐름의 어느 자리에 끼울 수 있지?
기존 중심은 그대로 두고 바깥 연결만 바꿀 수 있나?

이 차이는 작아 보이지만 내게는 컸다. 새 기술을 무조건 따라가거나 무조건 피하는 대신, 내 시스템을 기준으로 도입 여부를 판단할 수 있게 됐기 때문이다.

또 하나의 변화는 시스템을 설명할 수 있게 된 것이다. 예전에는 “뭔가 지침이 많고 여러 AI가 연결되어 있다”고밖에 말하지 못했다. 지금은 내가 보유하는 자료, 업무 의뢰, 교체 가능한 작업자, 검수, 기록이라는 흐름으로 설명할 수 있다.

내가 설명할 수 있다는 것은 문제가 생겼을 때 어느 층을 살펴봐야 하는지도 조금씩 알게 되었다는 뜻이었다.

⚠️ 아직 남은 문제

구조를 나눴다고 해서 유지보수가 사라지는 것은 아니다.

• 새로운 AI가 공통 지침을 실제로 읽는지 확인해야 한다.
• 도구별 입구가 너무 두꺼워져 공통 규칙의 사본이 되지 않는지 살펴야 한다.
• 오래된 프로젝트 지침이 다시 쌓이지 않도록 주기적으로 검수해야 한다.
• 자동 검사는 시스템의 일부만 확인하므로 실제 결과와 사용자 판단이 여전히 필요하다.
• 처음 해보는 일이나 취향을 함께 만들어야 하는 일은 사람과 AI의 대화가 많이 필요하다.

그리고 나는 아직 AI에게 큰일을 통째로 맡긴 뒤 완전히 자리를 떠나는 단계는 아니다. 다만 모든 작업에서 매 순간 옆에 붙어 있어야 하는 구조와, 한 사이클을 맡겨보고 마지막에 결과를 확인하는 구조의 차이는 조금씩 경험하고 있다.

💭 가장 크게 배운 것

처음에는 더 좋은 에이전트를 만들면 위임 문제가 해결될 거라고 생각했다. 그러다 지침을 정리했고, 문서 역할을 나눴고, 완료 기준과 검수 흐름을 만들었다. 그 과정에서 문제의 범위는 더 커졌지만 방향은 오히려 단순해졌다.

오래 가져갈 것은 내가 소유하고, 빨리 바뀌는 것은 교체 가능하게 둔다.

내 자료와 기준, 완료 조건과 검수 기록을 특정 AI 서비스 안에 가두지 않으면 새 기술이 나와도 전부 이사할 필요가 없다. 더 좋은 모델은 내 시스템을 대체하는 새 집이 아니라, 같은 작업실에서 새로 고용할 수 있는 작업자가 된다.

완성된 시스템은 아니다. 하지만 이제는 새 도구가 나올 때마다 “또 다 뜯어고쳐야 하나”라는 막연한 불안 대신, “어느 층만 바꾸면 되는가”를 물을 수 있게 됐다.

비개발자인 내게 이번 개편의 가장 큰 결과는 자동화 기능 하나가 아니었다. 내 시스템이 어떤 구조로 움직이는지 처음으로 조금 이해하게 된 것, 그리고 그 구조를 내가 계속 가꿔갈 수 있겠다는 감각이었다.

이 글은 1편 「왜 나는 AI에게 일을 맡길 수 없었을까」에서 이어집니다. 1편에서는 브리프, 완료 기준과 검수 흐름을 만들며 처음으로 업무 한 사이클을 맡겨본 과정을 다뤘습니다.