AI와 긴 작업을 하다 길을 잃어서, 지도 위에 커서를 찍었다

AI와 오래 작업할수록 이상한 일이 생겼습니다. 기록은 계속 늘어나는데, 다음 세션에서 다시 설명해야 할 것도 함께 늘어났습니다.

최종 결론만 남기면 왜 그 결론에 도착했는지가 사라졌습니다. 반대로 시행착오와 결정을 모두 한 문서에 넣으면, 새 세션의 AI는 오래된 판단과 지금 따라야 할 판단을 구분하지 못했습니다. 직전 대화만 이어 가면 당장 하던 일에는 빨리 들어갔지만, 그 일이 전체 프로젝트에서 왜 필요한지는 흐려졌습니다.

돌이켜 보면 저는 이 문제를 한동안 맥락의 양으로 다뤘습니다. 더 잘 기록하고, 더 충실하게 인계하면 된다고 생각했습니다. 하지만 기록이 충분한데도 같은 일이 반복됐습니다. 남아 있지 않은 것보다, 남아 있는 것 중 무엇이 지금 유효한지를 제어하기가 더 어려웠습니다.

마침 ‘AX 인재전쟁’ 해커톤이 열렸고, 저는 참가하기로 했습니다. 조사부터 문제 정의, 해결안 비교, 구현과 검증, 제출까지 긴 흐름을 AI와 함께 굴려야 하는 작업이었습니다. 이미 겪고 있던 문제가 그대로 다시 드러날 환경이었습니다.

이 작업의 구조를 생각할 때 실마리가 된 건, 같은 ‘AX 인재전쟁’에 도전한 Alex의 영상이었습니다.

Alex는 문제를 풀기 전에 전체 과정을 펼쳐 뒀다

영상에서 먼저 눈에 들어온 것은 프롬프트보다 작업이 놓일 구조였습니다. Alex는 회사별로 폴더와 지침, 작업할 자리, 조사 공간을 먼저 펼쳐 두었습니다. 그 위에서 요구사항과 출제 의도부터 조사, 문제와 해결안 비교, 구현, 검증까지 문제 해결의 전체 과정을 이어 갔습니다. 한 번 만든 순서를 따르는 데 그치지 않고, 작업하면서 그 구조도 다시 고쳤습니다.

Alex는 이 구조를 단계별 문제 풀이 과정을 구체화한 절차 지식(procedural knowledge)이라고 설명했습니다. 서로 다른 회사의 맥락을 분리한 채 같은 scaffold로 작업을 병렬 진행할 수 있다는 것은 그 구조가 만든 효과 중 하나였습니다. 동시에 scaffold만으로 좋은 결과가 보장되지는 않으며, 사람이 결과를 검토하고 별로인 지점을 판별하는 판단 감각이 필요하다고 했습니다.

제가 가져온 것은 그의 폴더 구조나 절차를 그대로 복사하는 일이 아니라, 긴 문제 해결 과정을 외부에 펼쳐 두면 AI와 사람이 덜 흔들릴 수 있다는 발상이었습니다.

그 발상을 제 문제에 대입하니, 작업 순서만 보이는 해커톤용 절차로는 부족했습니다. 여러 세션이 이어질 때 앞에서 어떤 가능성을 펼쳤고 무엇에 합의했는지 남아 있어야 했고, 동시에 지금 판단할 지점은 하나로 보여야 했습니다. 그래서 scaffold의 감각을 current라는 문서 하나로 옮겼습니다. 작업 저장소에 함께 커밋하는 파일로, 그 안에 전체 작업 지도와 그 위의 현재 위치 하나를 붙였습니다.

전체 지도는 남기고, 현재 위치는 하나만 둔다

제가 기억하는 첫 실제 적용은 ‘AX 인재전쟁’ 해커톤 작업이었습니다. 최초의 current에는 요구사항부터 제출까지 프로젝트 전체가 낮은 해상도의 나무로 펼쳐져 있었습니다.

전체 작업 지도
├─ 요구사항
│   └─ 원문 재확인   ← cursor: 지금 판단할 한 지점
├─ 조사와 문제 정의
├─ 해결안 탐색과 비교
├─ 구현과 검증
└─ 제출

처음 cursor는 요구사항 원문을 다시 확인하는 곳에 있었습니다. 조사가 시작되면 그쪽으로 옮겼고, 문제 후보를 비교할 때와 구현을 검증할 때도 같은 지도 위에서 움직였습니다. 저장소 기록에는 current가 커밋된 18개 버전으로 남았고, 활성 cursor 문장은 13번 바뀌었습니다. 이 숫자는 생산성 지표가 아닙니다. current가 프로젝트가 끝난 뒤 만든 회고 문서가 아니라, 작업 중 계속 고쳐 쓴 운영 문서였다는 흔적입니다.

요구사항 확인이 끝났을 때는 cursor를 조사 쪽으로 옮겼습니다. 조사 결과 전체를 current에 복사하지 않고, 해당 가지의 현재 결론과 다시 내려갈 경로만 남겼습니다.

처음 세운 원칙은 전체 지도를 한 문서에 두되 모든 내용을 그 안에 복사하지 않는 것이었습니다. 지나온 가지는 지도에서 지우지 않았고, 아직 가지 않은 가지는 확정된 계획이 아니라 그 시점의 가설로 두고 고쳐 갔습니다. 현재 실행할 계약, 그러니까 지금 구현이 따라야 할 조건을 적은 문서는 방향이 바뀌면 덮어썼습니다. 그 계약을 고른 이유와 시행착오는 과정 기록에 보존했습니다. 사실은 원자료와 실행 결과에서 다시 확인했습니다.

이 구분은 정보 정리 방식보다 갱신 규칙에 가까웠습니다.

• current는 전체 그림과 현재 판단점을 계속 고칩니다.
• 현재 실행 계약에는 지금 따라야 할 조건만 남깁니다.
• 과정 기록은 왜 그렇게 정했는지와 당시의 선택을 보존합니다.
• 사실은 원자료와 실행 결과에서 다시 확인합니다.

운영할 때는 주요 단계나 방향이 바뀔 때 AI가 갱신안을 만들었고, 저는 다음 cursor가 맞는지를 확인했습니다. 여기에 새 세션이 시작되면 과거 기록을 뒤지기 전에 먼저 이 문서를 읽고, 프로젝트, 현재 위치, 다음 할 일을 복기한 뒤 멈추라는 시작 규칙을 붙였습니다. 작업 전체를 문서에 맡긴 것이 아니라, 사람과 AI가 같은 화면에서 방향을 맞출 표면을 만든 셈입니다.

새 세션이 이전 세션의 자리를 찾았다

처음 체감한 변화는 새 세션에 다시 들어갈 때였습니다.

새 작업 세션에서 프로젝트와 구조를 파악해 달라고 요청했습니다. AI는 current와 연결된 기준을 읽은 뒤, 대략 이런 복기를 남기고 멈췄습니다.

이 프로젝트는 해커톤 과제 제출물을 만드는 저장소다. 현재 cursor는 요구사항 원문 재확인에 있다. 다음 할 일은 공식 안내 원문을 요구사항 정리와 대조해 제출 규칙을 확정하는 것이다. 실제 작업은 시작하지 않고 여기서 멈춘다.

저는 그 복기를 보고 요구사항 확인까지 끝났다고 바로잡은 뒤, 문제 정의와 조사로 다음 방향을 정했습니다.

AI는 앞서 붙여 둔 시작 규칙을 그대로 수행한 것이었습니다. 이전에는 제가 긴 설명으로 다시 만들어야 했던 출발점이 문서에 남아 있었습니다. 세션이 바뀌어도 사람과 AI가 프로젝트의 같은 지점에서 대화를 시작할 수 있었습니다.

이때부터 “뭔가 계속 유지되고 있다”는 감각이 들었습니다. 단순히 직전 할 일이 남은 것이 아니라, 앞에서 고민하며 넓게 펼쳤던 것과 사람과 AI가 합의한 판단이 다음 단계에서 다시 쓰일 수 있는 상태로 남았습니다.

넓게 펼친 조사가 수렴 과정에서 사라지지 않았다

초기 조사에서는 사용자와 상황을 나타내는 범주부터 먼저 고정하지 않기로 했습니다. 눈에 잘 띄는 회사의 표현에 자료를 끼워 맞출 수 있었기 때문입니다. 먼저 조사 범위와 근거 기준을 정하고, 반대 근거까지 넓게 본 뒤 반복 신호에서 질문을 좁히기로 했습니다.

AI는 이 합의를 따라 문제 범주를 정하지 않은 채 자료 20개를 모았습니다. 그러다 객관성이라는 외부 판단 기준을 적용하는 과정에서 한 번 과하게 꺾였습니다. 회사가 중요하게 보는 방향과 객관적인 사용자 문제를 서로 반대편에 놓고, 하나를 택해야 하는 것처럼 정리했습니다.

제가 원한 관계는 달랐습니다. 회사의 직접 증거는 해커톤에서 무엇에 높은 가중치를 둘지 알려 주지만, 그 자체로 실제 사용자 문제를 증명하지는 않습니다. 외부 기준은 앞의 자료를 지우지 않고 주장을 점검하는 검증 기준으로 써야 했습니다.

앞선 합의로 돌아온 뒤에야 그 20개를 문서 단위 대신 신호 단위로 다시 읽었습니다. 같은 신호 안에서 회사 방향을 보여 주는 범위와 사용자 문제를 증명하는 범위를 나눠 적었고, 그렇게 16개의 신호가 나왔습니다. 두 범위를 나눠 적는 일 자체가 과교정에서 되찾은 설계였습니다.

실제로 판단은 다음 순서로 움직였습니다.

넓게 펼치기
문제 범주를 정하지 않고 자료 20개
↓
과교정 발견
회사 방향과 사용자 문제를 양자택일로 바꿈
↓
앞선 합의로 복귀
회사 근거는 가중치, 외부 기준은 검증 기준
↓
신호 단위로 재배열
20개 자료 → 16개 신호, 증명 범위를 나눠 적기
↓
판을 지우지 않고 다시 펼치기
첫 후보판 보존 → 두 번째 후보판 재추출 → 5개 후보의 계보 연결
↓
수렴
3개 문제 → 9개 해결안 → Markdown 출력 초안 3개 → 1개 선택

여기서 중요했던 것은 최근 답변만 고치거나 첫 판단을 폐기하지 않았다는 점입니다. 첫 후보판과 당시의 합의를 남겨 뒀기 때문에, 원자료와 판단 기준에서 다시 만든 판이 무엇을 새로 봤고 무엇을 놓쳤는지 비교할 수 있었습니다. 5개 후보 중 바로 파고들지 않은 후보에는 어떤 조건이 확인되면 다시 열지를 함께 적어 두었습니다. current는 어떤 판단이 어느 가지에 있었고 무엇을 다시 열어야 하는지 찾는 입구가 됐습니다.

제가 current를 잘 사용했다고 느낀 지점은 바로 여기였습니다. 펼친 재료가 어디에 있고 지금 무엇을 좁히는 중인지 잃지 않은 채 수렴할 수 있었기 때문입니다.

current를 읽어도 최근 작업은 전체를 밀어냈다

그렇다고 이 구조가 맥락 문제를 해결한 것은 아니었습니다.

구현 교정과 검증이 아직 진행 중인 상태에서 외부 제출용 다섯 문항을 작성할 때, AI는 답변을 쓰기 전에 current를 읽었습니다. 그런데 프로젝트 전체에서 AI와 사람이 한 일을 묻는 답변까지 직전까지 붙들고 있던 구현과 검증에 과도하게 끌렸습니다. 최신 검사에서 무엇이 실패했고 어떻게 교정했는지는 구체적이고 읽기 쉬웠습니다. 그래서 앞선 조사, 첫 후보판과 분리해 다시 만든 문제 후보, 여러 해결안과 출력 초안 비교, 사용자의 최종 선택을 밀어내고 프로젝트 전체의 설명이 됐습니다.

제가 직전 구현이 프로젝트 전체를 대신하고 있다고 지적한 뒤에야 AI는 전체 지도로 올라갔습니다. 요구사항, 20개 자료와 16개 신호, 문제 후보, 9개 해결안, 3개 출력 초안, 선택한 제품, 최근 구현을 다시 시간순으로 연결하고 문항마다 필요한 범위를 나눴습니다.

이 사건은 이미 운영하던 지도가 어디까지 돕고 어디서 멈추는지를 드러냈습니다. current를 읽었다는 사실만으로 최근 맥락 편향이 사라지지는 않았습니다. 사람이 어긋남을 발견하고 범위를 다시 지정해야 했습니다. 그 뒤에는 프로젝트의 전체 생애주기를 다시 펼칠 압축된 경로가 있었습니다.

계속 고치는 문서는 저절로 최신이 되지 않는다

더 분명한 한계도 있었습니다. 마지막 세 번의 커밋 동안 current는 갱신되지 않았습니다.

구현과 검증의 통과 기준을 충족한 상태까지는 지도에 들어갔지만, 제출 파일을 만들고 다시 검증한 일, 제출 문항 답변과 실행 기록을 맞춘 일, 웹 업로드 실패 뒤 호환 파일을 준비한 일은 과정 기록과 산출물에만 남았습니다.

다음 세션이 current만 읽었다면 구현을 통과한 지점까지는 알 수 있었지만, 프로젝트의 실제 마지막 상태는 다른 기록에서 다시 추론해야 했습니다. 방향이 바뀔 때의 갱신 규칙은 있었지만, 작업 종료와 저장소 밖 사건까지 누가 확인하고 마지막 상태를 닫을지는 정해져 있지 않았습니다.

이후 작업에서는 current를 어떻게 읽을지만큼 누가 마지막으로 쓸지도 함께 정했습니다. 병렬 작업의 결과를 누가 전체 cursor에 합칠지, 배포나 제출처럼 저장소 밖에서 일어난 사건을 누가 반영할지, 작업 종료 조건에 마지막 갱신을 넣을지를 함께 봤습니다.

후속 장기 프로젝트에서 current는 147줄짜리 상태 보고서까지 불어났습니다. 전체 지도를 찾으려면 세부 상태를 다시 훑어야 했고, 이를 46줄의 지도 중심 문서로 줄였습니다. 다시 82줄까지 커졌을 때도 같은 기준으로 47줄까지 덜어냈습니다. 전체 지도를 둔다는 것과 모든 세부를 한 파일에 넣는 일은 달랐습니다.

읽는 방식도 역할마다 달라야 했습니다. 주 작업자에게 유효했던 “먼저 current를 읽고 복기한 뒤 멈춘다”는 규칙은, 독립 검증 세션에서는 검증을 시작하기도 전에 작업을 멈추게 했습니다. 첫 후보와 겹치지 않게 새 후보를 뽑으려던 세션도 같은 규칙 때문에 current를 먼저 읽었는데, 그 안에는 기존 후보의 지도가 그대로 있었습니다. 이전 문서를 건네지 않는 것만으로는 가림이 되지 않았습니다. 같은 지도라도 누가 무엇을 판단하는지에 따라 진입 규칙을 나눠야 했습니다.

current에는 자동 효력이 없습니다. 이름을 붙인다고 현재가 되지 않고, 읽었다고 질문의 범위를 정확히 잡는 것도 아니며, 작업이 끝났다고 스스로 갱신되지도 않습니다. 세부를 계속 받아 주면 지도이기를 멈추고, 누가 언제 읽고 쓸지를 정하지 않으면 역할에 따라 오히려 방해가 됐습니다.

기억을 늘리는 대신, 다시 맞출 자리를 만든다

이 사례만으로 current가 생산성을 높였다고 말할 수는 없습니다. 세션의 연속성에는 사용자 정정, Git, 과정 기록, 실행 결과, AI가 남긴 요약도 함께 작동했습니다. 실제로 어떤 재진입은 current를 다시 읽지 않은 채, 대화가 길어질 때 자동으로 남는 압축 요약만으로 직전 작업을 이어 갔습니다. 각각의 기여를 분리해 비교한 대조군도 없습니다.

그래도 저는 이후의 긴 AI 작업에서도 전체 지도와 현재 cursor를 함께 두고 있습니다. 이것을 AI의 외부 기억이라기보다, 사람과 AI가 다시 만났을 때 서로의 그림을 맞추는 작업면으로 봅니다. 최근 맥락 편향을 없애거나 마지막 상태를 저절로 갱신해 주지는 않지만, 작업이 흔들릴 때 전체 그림으로 돌아와 “우리는 지금 어디에 있는가”를 다시 맞출 자리는 남깁니다.

긴 작업에서 제가 지키고 싶었던 것은 모든 대화가 아니었습니다. 어떤 문제를 왜 펼쳤는지, 무엇에 합의했는지, 지금 무엇을 판단해야 하는지가 남아 있기를 바랐습니다.