여러 AI를 사용하기 전에, 원본을 하나로 정할 이유

ChatGPT, Claude, Cursor 등 용도에 따라 여러 AI를 사용하는 것이 한 사람이라도 조사, 집필, 개발을 진행하는 데 수월합니다.

하지만 단순히 사용하는 AI를 늘린다고 해서 업무가 정리되는 것은 아닙니다. 오히려 각 AI가 다른 전제를 가지고 같은 질문에 다른 답을 내놓거나, 어떤 것이 최신 정보인지 알기 어려워질 때가 있습니다.

제가 여러 AI를 사용할 때 가장 먼저 정한 것은 AI별로 고도화된 프롬프트가 아니었습니다. 그보다 먼저 정한 것은 어떤 정보를 원본(原本)으로 다룰 것인가였습니다.

이 글에서는 비엔지니어가 여러 AI 사용을 시작하기 전에, 원본을 하나로 만드는 이유와 무리 없이 지속할 수 있는 작은 운영 방법을 소개합니다.

예를 들어, 오전에 ChatGPT로 기획을 하고, 오후에 Cursor로 구현하고, 밤에 다른 AI로 설명문을 작성한다고 가정해 봅시다.

각 AI와의 대화만 보면 작업이 순조롭게 진행되는 것처럼 보입니다. 하지만 다음과 같은 불일치가 발생하기 쉽습니다.

• 오전에 정한 대상 독자가 오후의 구현 단계에 전달되지 않음
• 구현 중에 바뀐 사양이 밤의 설명문에 반영되지 않음
• 채택하지 않은 안을 다른 AI가 결정 사항으로 취급함
• 오래된 채팅창을 열고, 이미 변경된 내용으로 작업을 재개함
• AI마다 다른 '다음 할 일'이 남아 있음

문제는 어떤 AI가 우수한지가 아닙니다. AI 바깥에 모두가 확인할 수 있는 현재 지점(現在地)이 없는 것입니다.

대화는 생각하는 데 편리하지만, 결정 사항을 보관 장소로 사용하면 어느 대화가 최신인지 사람이 계속 기억해야 합니다. 작업량이 늘어날수록, 이 기억에 의존하는 운영은 고통스러워집니다.

여기서 말하는 원본은 모든 정보를 저장하는 거대한 데이터베이스가 아닙니다.

최소한 다음 내용을 확인할 수 있는 장소입니다.

목적: 무엇을 위한 프로젝트인가
현재 지점: 어디까지 끝났는가
결정 사항: 무엇을 채택하고, 무엇을 채택하지 않았는가
...

저는 로컬의 Markdown을 중심으로 사용합니다. Obsidian에서 읽고 쓸 수 있고, 필요에 따라 Git으로 변경 이력도 확인할 수 있기 때문입니다.

하지만 중요한 것은 Obsidian이라는 제품 이름이 아닙니다. 텍스트 파일이라도 좋고, GitHub상의 문서라도 좋고, 팀에서 관리하는 다른 시스템이어도 괜찮습니다.

중요한 것은 AI의 답변이 아니라, 사람이 확인하여 저장한 기록을 원본으로 삼는 것입니다.

AI가 새로운 안을 내놓아도 그것만으로는 결정 사항이 되지 않습니다. 사람이 확인하고 원본에 반영하는 시점부터 비로소 다음 작업에 사용되는 전제가 됩니다.

원본을 만든다고 하면 과거 자료를 모두 정리해서 AI에게 전부 읽게 하고 싶어집니다. 하지만 정보량이 늘어날수록 정확해진다는 보장은 없습니다.

오래된 계획, 기각한 안, 참고 자료, 현재 사양을 한 번에 전달하면, AI가 그것들을 같은 중요도로 취급할 수 있습니다. 그래서 저는 현재 지점을 작은 파일로 나눕니다.

예를 들어, 다음 4가지입니다.

README.md 프로젝트의 목적과 입구
CURRENT_STATUS.md 현재 지점과 완료된 것
DECISIONS.md 판단과 이유
...

비밀 정보나 고객 정보는 AI와 공유할 원본에 섞지 않습니다. API 키, 비밀번호, 개인 정보, 공개 전 기밀 정보는 다른 안전한 장소에서 관리합니다.

'모두가 읽을 수 있게 한다'기보다는 '이 작업에 필요한 확인된 정보만 읽을 수 있게 하는 것'이 여러 AI 운영의 출발점입니다.

원본을 만들어도 AI가 매번 다른 파일부터 읽기 시작하면 판단이 흔들립니다. 저는 작업을 시작하기 전에 읽는 순서까지 정합니다.

1. 목적 확인
2. 현재 지점 확인
3. 이번에 관련된 결정 사항 확인
...

AI에게 요청하는 내용도 다음과 같이 짧아질 수 있습니다.

README.md, CURRENT_STATUS.md, DECISIONS.md 순서로 확인해 주세요.
확인된 사실과 제안을 나누어 주세요.
미확인 내용을 보완하지 말아 주세요.
...

이 요청에서 중요한 것은 AI를 세밀하게 통제하는 것이 아닙니다. 작업 시작 전에 공통의 현재 지점으로 돌아오는 것입니다.

ChatGPT로 기획할 때도, Cursor로 코드를 고칠 때도, 다른 AI로 문장을 다듬을 때도, 처음에 같은 원본을 확인합니다. 역할은 달라도 출발점은 같게 합니다.

AI와의 대화에는 채택된 안뿐만 아니라, 도중의 가설이나 생각나는 것들도 포함되어 있습니다. 대화 전문 전체를 그대로 원본에 넣으면, 결정 사항과 검토 중인 안이 뒤섞입니다.

그래서 작업 후에 남길 내용을 3가지로 나눕니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

확인할 수 없었던 내용은 완료된 것으로 원본에 작성하지 않습니다. '미확인', '보류', '다음 번 확인' 등으로 남깁니다.

이러한 구분이 있으면 다른 AI가 작업을 인계받더라도, 제안을 구현된 것과 착각하기 어렵습니다.

원본을 공유하면 이번에는 여러 AI가 동시에 수정하는 문제가 발생합니다. 같은 파일을 따로따로 업데이트하면, 어느 것을 남길지 판단할 필요가 생깁니다.

따라서 한 번의 작업에서는 업데이트 담당자를 하나로 정합니다.

조사하는 AI: 후보와 근거를 정리한다
작업하는 AI: 결정한 범위만 변경한다
리뷰하는 AI: 차이점과 모순을 확인한다
...

여러 AI를 사용하더라도, 같은 순간에 모두에게 같은 파일을 자유롭게 편집하게 할 필요는 없습니다. 조사, 작업, 리뷰를 순서대로 나누기만 해도 충돌은 줄일 수 있습니다.

또한, 원본을 업데이트했다면, 업데이트 날짜와 변경 이유를 짧게 남깁니다. 긴 일지(日報)를 쓸 필요가 없습니다.

2026-10-04
변경: 여러 AI의 시작 절차 추가
이유: 작업마다 참조하는 현재 위치가 어긋났기 때문에
...

이 짧은 기록이 다음 AI에게는 진입점이 됩니다.

처음부터 전체 업무의 정보 기반을 만들 필요는 없습니다. 우선, 하나의 작은 프로젝트만으로 시도해 봅니다.

• 프로젝트용 폴더를 만든다
• 목적, 현재 위치, 금지 사항, 다음 작업을 작성한다
• AI에게 그 파일을 먼저 읽게 한다
• 작업 후에 사실, 판단, 다음 작업만 업데이트한다
• 다음 날 다른 AI로도 같은 현재 위치에서 재개할 수 있는지 시험해 본다

잘 인계되지 않았다면, 프롬프트를 길게 하기 전에 원본에 부족한 정보가 없는지 확인합니다.

AI가 틀렸을 때도, '더 똑똑하게 답변해 줘'라고 부탁하는 것만으로는 재발을 막기 어렵습니다. 판단 기준이 원본에 없다면 추가하고, 오래된 정보가 남아 있다면 정리합니다. 개선할 대상을 AI의 성격이 아니라 공유 정보의 구조에 두는 것입니다.

원본을 만들었다고 해서 문서가 늘어날 뿐 사용되지 않으면 의미가 없습니다. 저는 주기적으로 다음 3가지를 확인합니다.

• 처음 읽는 AI가 프로젝트 목적을 설명할 수 있는지
• 완료된 것과 아직 실행하지 않은 것을 구분할 수 있는지
• 다음에 변경해도 되는 범위와, 건드려서는 안 되는 범위를 설명할 수 있는지

답변이 모호하면, AI에게 추측하게 하지 않고 원본의 문장을 고칩니다. 예를 들어 '향후 추가할'과 '추가 완료됨'이 같은 단락에 있다면, 현재와 미래를 다른 제목으로 나눕니다. 오래된 정보가 필요하다면 이력(履歴)으로 옮기고, 현재 위치 파일에는 지금의 판단만 남깁니다.

원본은 한 번 완성하는 결과물이 아니라, 작업을 재개하기 위한 도구입니다. 매번 깨끗한 문장을 만들 필요는 없습니다. 날짜, 상태, 근거, 다음 수순이 짧게 확인되는 것이 더 유용합니다.

또한, AI에게 원본의 요약을 만들게 할 경우에도, 그 요약을 새로운 원본으로 삼지 않습니다. 요약은 그 시점의 작업 메모로 취급하고, 판단을 바꿀 때는 원래 기록으로 돌아갑니다. 복사본이 너무 많아지는 것도 '어떤 것이 최신인지 알 수 없다'는 것을 막기 위한 운영의 일부입니다.

여러 AI를 사용할 때 처음에 필요한 것은 복잡한 연동이 아닙니다.

• 원본을 하나 정한다
• 목적, 현재 위치, 판단, 금지 사항, 다음 작업을 남긴다
• AI에게 읽게 하는 순서를 고정한다
• 사실과 제안을 나눈다
• 마지막 채택과 업데이트는 인간이 확인한다

이 5가지만으로도, AI마다 전제가 달라지는 문제를 줄일 수 있습니다.

AI는 역할별로 바꿔도, 현재 위치는 매번 같은 장소로 돌아옵니다. 이렇게 해두면, 새로운 AI를 시도할 때도 과거의 경위를 모두 설명할 필요가 없습니다.

여러 AI 시스템을 크게 만들기 전에, 먼저 하나의 프로젝트에서 '어제와 다른 AI가, 같은 현재 위치에서 작업을 재개할 수 있는지'를 시험해 보세요. 거기서 막힌 부분이 다음에 원본에 추가해야 할 정보입니다.

이 글은 로컬 Markdown을 원본으로 삼고, AI별 역할과 Human Approval(인간 승인)을 분리해 온 본 프로젝트의 운영 기록을 바탕으로 구성되었습니다. 특정 AI가 항상 옳다는 전제가 아니라, 인간이 확인한 기록을 작업의 출발점으로 삼는 방법을 다루고 있습니다.