무엇이 문제였나 — 다음 세션에게 넘기는 문서 하나
SGK 스튜디오는 AI 코딩 에이전트에게 회사 업무 자동화 작업을 통째로 맡기고, 세션 하나가 끝나면 다음 세션이 그 뒤를 잇습니다. 문제는 세션과 세션 사이에는 아무것도 남지 않는다는 점입니다. 에이전트는 대화가 끊기면 그 전 세션에서 무엇을 왜 그렇게 했는지 기억하지 못하고, 새 세션은 매번 처음부터 상황을 다시 파악해야 합니다.
이 손실을 막으려고 세션을 마칠 때 다음 세션에게 넘길 인수인계 문서를 한 장 만들어 둡니다. 지금 상황이 어떤지, 무엇을 먼저 읽어야 하는지, 무엇을 반드시 살려야 하는지, 언제 끝난 것으로 볼 수 있는지를 적어 저장소 맨 위 폴더에 파일 하나로 남기는 방식입니다. 다음 세션은 이 문서를 열자마자 곧바로 일을 이어받고, 다 쓰고 나면 그 문서를 보관 폴더로 옮깁니다.
이 문서를 만드는 계기는 두 가지입니다. 하나는 세션을 마치면서 다음 세션에게 미리 넘겨주는 경우이고, 다른 하나는 세션을 열자마자 무엇을 해야 할지 스스로 알 수 없다는 사실을 자동 검사가 잡아내는 경우입니다. 뒤쪽 경우에는 사람에게 되묻지 않고, 저장소와 작업 목록에 남아 있는 근거로 스스로 목적지를 세운 뒤 같은 턴에 곧바로 일을 시작합니다.
두 계기가 만드는 문서는 채우는 내용의 분량만 다를 뿐, 저장되는 자리는 똑같이 저장소 맨 위 폴더의 같은 이름입니다. 자리가 같으면 편리하지만, 동시에 그 자리를 둘러싼 모든 사고도 결국 같은 파일 하나에서 시작됩니다.
문제는 이 파일의 이름이 하나뿐이라는 데 있었습니다. 인수인계 문서를 새로 쓰는 순간, 그 저장소에서 지금까지 있던 인수인계 문서는 같은 이름 자리에 있었기 때문에 그대로 덮어써집니다. 직전 문서가 이미 다음 세션에 읽혀서 다 쓴 상태라면 덮어써도 무방합니다. 하지만 아직 누군가의 결정을 기다리느라 살아 있는 문서였다면, 그 순간 그 문서는 조용히 사라집니다.
더 나쁜 경우도 있었습니다. 작업 목록 문서 안의 어떤 항목이 그 인수인계 파일을 근거로 가리키고 있으면, 파일이 덮어써져도 그 항목의 화살표(경로)는 그대로 살아 있습니다. 화살표가 가리키는 위치는 안 바뀌었는데 그 위치에 있는 내용만 통째로 바뀌는 셈입니다. 다음 세션이 그 항목을 열어 보면, 자신이 찾던 인수인계 문서가 아니라 전혀 다른 작업의 인수인계 문서를 읽게 됩니다.
이 손실이 문제가 되는 이유는 단순합니다. 세션이 매번 처음부터 상황을 파악해야 하면, 그만큼 실제 업무에 쓸 수 있는 시간이 줄어듭니다. 회사 안에서 에이전트에게 맡기는 일은 웹사이트를 만들고 콘텐츠를 발행하고 반복 업무를 자동화하는 작업인데, 세션을 열 때마다 지난 세션의 맥락을 다시 설명해야 한다면 자동화가 주는 이점 자체가 줄어듭니다. 인수인계 문서 한 장은 이 반복 설명 비용을 없애려고 만든 장치였고, 그래서 이 장치 자체가 고장 나면 손해가 더 컸습니다.
처음 잰 숫자 — 발급 4번에 아카이브는 1번뿐이었다
짐작이 아니라 실제로 세어 봤습니다. 측정은 저장소의 버전 관리 기록을 시간 순서대로 나열해, 인수인계 문서가 새로 저장된 시점과 직전 문서가 보관 폴더로 옮겨진 시점을 하나씩 대조하는 방식으로 했습니다. 한 저장소에서 인수인계 문서를 손으로 새로 발급한 횟수와, 그 전에 있던 문서를 제대로 보관 폴더로 옮긴 횟수를 대조했습니다. 발급은 4회 있었는데, 직전 문서가 보관 폴더로 옮겨진 경우는 1회뿐이었습니다. 나머지 3회는 새 문서가 저장되면서 직전 문서 자리를 그대로 차지했고, 직전 문서는 보관되지 않은 채 사라졌습니다. 발급 4회에 보관 1회, 그러니까 4번 중 3번이 깨진 셈입니다.
이 중 한 번은 특히 위험했습니다. 사라진 문서는 아직 누군가의 결정을 기다리느라 살아 있던 문서였습니다. 다 쓴 문서가 아니라 진행 중인 문서가 그 자리에서 통째로 바뀌었습니다. 게다가 작업 목록의 한 항목이 그 문서를 근거로 가리키고 있었기 때문에, 화살표는 살아 있는 채 가리키는 내용만 바뀌는 상태가 함께 발생했습니다. 버전 관리 기록에 남아 있어 복구할 수 있었지만, 아무도 그 사실을 눈치채지 못했다면 다음 세션은 전혀 엉뚱한 문서를 열어 그 내용을 진짜 인계 사항으로 오인합니다.
세운 가설 — 사람이 규칙을 안 지켜서 그런 걸까?
처음 든 생각은 단순했습니다. '소비했으면 보관 폴더로 옮겨 둔다'는 규칙이 이미 있었는데, 그 규칙을 사람이 매번 지키지 않아서 생긴 문제라고 봤습니다. 세션을 마칠 때마다 해야 할 일이 여러 가지인데, 그중 하나인 보관 이동을 깜빡했다는 설명이 가장 그럴듯해 보였습니다.
이 가설이 맞다면 처방도 단순합니다. 사람에게 다시 한번 규칙을 상기시키거나, 마무리 체크리스트에 항목을 하나 추가하면 됩니다. 실제로 처음에는 '소비했으면 밀어내라'는 문장 형태의 규칙을 계속 문서에 적어 두는 방식으로 대응했습니다.
이런 인수인계 문제는 사람이 하는 업무에서도 흔합니다. 담당자가 바뀔 때 '인수인계 문서를 꼭 남기라'고 아무리 강조해도, 실제로는 빠짐없이 넘겨지지 않는 경우가 많습니다. 그래서 처음에는 에이전트 쪽도 사람과 같은 습관 문제일 거라고 판단했고, 규칙을 다시 한번 강조하는 쪽으로 방향을 잡았습니다.
이 규칙은 처음부터 아무렇게나 만든 것이 아니었습니다. 세션을 마칠 때 다음 세션에게 무엇을 넘길지 정리하는 절차 안에 이 문장을 명시적으로 적어 두었고, 세션을 마무리할 때마다 이 문장을 직접 눈으로 볼 수 있었습니다. 그런데도 결과가 나아지지 않았다면, 문제는 규칙이 있고 없고가 아니라 다른 곳에 있다고 봐야 했습니다.
가설이 틀린 지점 — 규칙은 있었다, 파일명이 문제였다
"소비했으면 밀어내라"는 문장 규약은 발급 4번 중 3번 안 지켜졌다.
규칙을 문서에 적어 두는 것만으로는 달라지지 않았습니다. 실측 결과를 다시 보면, 규칙이 없어서가 아니라 규칙이 분명히 있는데도 4번 중 3번이 어겨진 것입니다. 사람이 매번 부주의해서 이런 일이 반복된다고 보기는 어려웠습니다.
인수인계 문서를 발급하는 시점은 세션을 마무리하며 여러 가지를 동시에 처리하는 순간입니다. 그 와중에 '이전 파일을 다른 이름으로 옮기고, 그 파일을 가리키던 화살표도 새 이름으로 고친다'는 손 작업 두 단계를 매번 빠짐없이 챙기라고 요구하는 것 자체가 무리한 전제였습니다. 규칙을 더 강조하는 처방은 틀린 방향이었습니다.
진짜 원인 — 왜 파일 하나가 헌 축을 조용히 덮어썼나?
진짜 원인은 파일 이름 설계에 있었습니다. 인수인계 문서는 저장소 맨 위 폴더에 항상 같은 이름으로 저장됩니다. 새 문서를 쓰는 동작과 이전 문서를 보관 폴더로 옮기는 동작은 서로 다른 두 단계인데, 이 둘을 하나로 묶어 강제하는 장치가 없었습니다. 새 문서를 저장하는 손 작업 한 번이면 그 자리에서 끝나 버리기 때문에, 이전 문서를 옮기는 두 번째 단계는 안 해도 아무 오류도 나지 않았습니다.
파일 이름을 하나로 고정한 원래 이유는 단순함이었습니다. 다음 세션이 열자마자 어디를 봐야 하는지 헤매지 않도록, 인수인계 문서는 항상 같은 위치의 같은 이름에 있어야 한다는 원칙이었습니다. 이 원칙 자체는 지금도 유효합니다. 문제는 '항상 같은 이름'이라는 원칙과 '새로 쓰기 전에 먼저 옮겨 둔다'는 절차가 같은 하나의 동작으로 묶여 있지 않았다는 데 있었습니다.
작업 목록 안의 화살표(경로 참조)도 같은 구조의 문제였습니다. 문서를 옮겼으면 그 문서를 가리키던 화살표도 새 경로로 함께 고쳐야 하는데, 이 역시 강제하는 장치가 없어서 사람이 기억해서 손으로 고쳐야 했습니다. 결국 실패는 사람의 부주의가 아니라, 반드시 함께 일어나야 하는 세 가지 일 — 새 문서 저장, 이전 문서 보관, 화살표 갱신 — 을 서로 다른 세 번의 손 작업으로 쪼개 놓은 설계 자체에 있었습니다.
이 구조가 위험한 이유는 화살표가 깨지는 방식에 있습니다. 파일이 통째로 사라지거나 경로가 틀리면 다음 세션은 곧바로 오류를 보고 문제를 알아차립니다. 하지만 이번 사고에서는 화살표가 가리키는 경로 자체는 멀쩡했고, 그 경로에 있는 내용만 조용히 다른 작업의 것으로 바뀌었습니다. 오류 없이 조용히 틀린 상태가 가장 늦게 발견되는 실패입니다.
조치 — 손으로 쓰지 않고 명령 하나로 발급한다
손으로 하던 절차를 명령 하나로 바꿨습니다. 이 명령을 실행하면 동작 3개가 한 번에 일어납니다.
- 이전 인수인계 문서를 주제와 날짜가 담긴 새 이름으로 보관 폴더에 옮긴다
- 작업 목록 문서 안에서 그 문서를 가리키던 화살표를 방금 옮긴 새 이름으로 함께 고친다
- 새로 쓴 인수인계 문서가 판정 기준을 충족하는지 자동으로 검사한다
보관할 때 파일 이름에 주제와 날짜를 함께 넣는 데도 이유가 있습니다. 나중에 어떤 인수인계 문서가 언제, 어떤 작업 축을 다루려고 만들어졌는지 이름만 보고 알 수 있어야 하기 때문입니다. 이름에 이 정보가 없으면 여러 개를 보관해 둬도 결국 하나씩 열어 봐야 어떤 문서인지 알 수 있습니다.
발급 전에도 확인 단계를 하나 더 뒀습니다. 지금 남아 있는 작업 목록만으로 다음 세션이 충분히 이어받을 수 있는 상태라면, 인수인계 문서를 아예 새로 쓰지 않습니다. 이미 자기 완결적인 상태에서 문서를 하나 더 만들면 다음 세션이 그 문서를 안 읽는 중복만 늘어나기 때문입니다.
이 확인 단계가 없으면 어떤 일이 생기는지도 실측으로 확인했습니다. 다음 세션이 이어받을 작업 목록이 이미 충분한데도 매번 새 인수인계 문서를 만들면, 다음 세션은 두 문서 중 어느 쪽이 최신인지부터 판단해야 합니다. 문서 하나를 아끼려고 만든 장치가 오히려 판단할 거리를 하나 더 늘리는 셈입니다.
아홉 칸 골격 — 무엇을 채우면 무슨 일이 안 생기나?
인수인계 문서 자체의 형식도 아홉 칸으로 표준화했습니다. 이번 세션이 하는 일 한 문장, 먼저 읽을 것, 지금 상황, 원칙, 항목별로 다른 성격, 반드시 살려야 하는 내용, 만드는 방법, 하지 말 것, 완료 판정, 작업 규약 — 이 아홉 칸 중 어느 칸이 비면 각각 다른 방식으로 문제가 생깁니다. 예를 들어 완료 판정 칸이 비어 있으면 에이전트는 '됐습니다'라는 말로 일을 조기에 마무리해 버리고, 반드시 살려야 하는 내용 칸이 비면 분량을 줄이는 작업 중에 핵심이 조용히 지워집니다.
다섯 칸을 고른 기준은 '지금 이 순간 결정에 꼭 필요한가'였습니다. 먼저 읽을 것이나 만드는 방법 같은 칸은 세션을 닫으며 다음 세션에게 넘길 때는 꼭 필요하지만, 세션을 스스로 여는 순간에는 이미 저장소 안에서 직접 확인할 수 있는 정보라 다시 적을 이유가 없습니다.
세션을 닫으며 다음 세션에게 발급할 때는 아홉 칸을 전부 채웁니다. 반면 세션을 열자마자 목적지·기준·완료 조건이 없다는 사실을 스스로 알아챈 경우에는 9개 칸 중 5개 칸만 채우고 바로 같은 턴에 착수합니다. 나머지 4개 칸까지 채우면 응답 분량만 낭비합니다.
재측정 결과 — 다섯 축 전부 통과, 재질문 0회로 완주했다
이 아홉 칸 골격으로 실제로 쓴 인수인계 문서 하나가 다른 프로젝트에서 판정을 받았습니다. 검사기가 보는 다섯 개 축을 전부 통과해 5개 축 중 5개, 즉 만점을 받았고, 그 문서를 넘겨받은 세션은 실제로 일을 진행하면서 되묻는 질문을 한 번도 하지 않고 재질문 0회로 완주했습니다.
손으로 쓸 때는 발급 4번 중 보관이 1번만 성공했던 것과 비교하면, 명령으로 발급을 강제한 뒤에는 동작 3개가 한 번의 실행 안에서 전부 함께 일어나기 때문에 그중 하나만 빠지는 경우 자체가 생기지 않습니다. 살아 있는 인수인계 문서와 보관된 문서 목록을 한 번에 볼 수 있는 명령도 같이 만들었습니다. 예전에는 저장소 폴더를 직접 열어야 확인할 수 있었던 걸, 이제는 명령 한 줄로 확인합니다. 확인하는 행위 자체가 손 작업에서 명령으로 바뀌었으니, 확인을 건너뛸 이유도 함께 줄었습니다.
다만 이 결과는 아직 사례 1건에서 나온 값입니다. 검사기 판정과 완주 여부는 이 골격을 실제로 쓴 다른 프로젝트 하나에서 확인한 수치이고, 다른 저장소나 다른 주제에서도 같은 결과가 나오는지는 사례를 더 쌓아야 확실해집니다. 다만 손으로 쓸 때 4번 중 3번이 깨졌던 원인 — 세 가지 동작을 서로 다른 손 작업으로 쪼개 둔 설계 — 은 이제 구조적으로 사라졌습니다.
이 재측정에서 눈여겨볼 부분은 다섯 축 만점 그 자체보다 재질문 0회 쪽입니다. 검사기 판정은 문서의 형식이 갖춰졌는지를 봅니다. 재질문 0회는 그 형식이 실제로 다음 세션의 판단에 도움이 됐는지, 즉 형식을 넘어 내용이 통했는지를 보여 주는 결과입니다. 형식과 내용이 같이 갖춰졌을 때만 나올 수 있는 숫자입니다. 형식만 맞고 내용이 빠졌다면 축은 채워도 되묻기는 남았을 겁니다.
남는 한계 — 같은 문서를 쓰는 건 막았는데, 같은 일을 하는 건 왜 못 막았나?
명령으로 바꾼 뒤에도 남는 문제가 있었습니다. 이 설계 전체는 '다음 세션이 작업 목록 맨 위 항목부터 집는다'는 전제 위에 서 있습니다. 세션이 하나일 때는 이 전제가 자연스럽지만, 여러 세션을 동시에 열어 두면 그대로 충돌 장치가 됩니다. 새로 열리는 세션마다 같은 항목을 집기 때문입니다. 실제로 2026년 8월 27일에는 옆 세션이 이미 붙잡고 있는 항목을 새 세션이 처음부터 다시 시작하는 상황을 하루에 여러 번 손으로 막아야 했습니다.
문서를 쓰는 쪽 충돌은 이미 두 겹으로 막혀 있었습니다. 자기 완결 여부를 먼저 확인하는 단계가, 남이 이미 만든 인수인계 문서가 작업 목록보다 새것이면 새로 만들지 않고 넘어가고, 보관 파일 이름 규칙도 주제별로 갈라 놓았기 때문입니다. 정작 막히지 않은 쪽은 같은 문서를 쓰는 쪽이 아니라 같은 일을 하는 쪽이었습니다. 같은 문서를 동시에 쓰는 문제는 막았지만, 같은 일을 동시에 하는 문제는 아무도 지켜보지 않았습니다.
그래서 항목에 손대기 전에 먼저 표시해 두는 절차를 추가했습니다. 어떤 항목에 착수하기 전에 그 항목을 자기 것으로 표시하고, 이미 남이 표시해 둔 항목이면 묻지 않고 다음 미표시 항목으로 넘어갑니다.
- 표시를 시도해 성공하면 그 항목은 내 것이 되고 바로 진행한다
- 이미 남이 표시해 둔 항목이면 그 항목을 버리고 다음 미표시 항목으로 넘어간다 — 되묻지 않는다
- 지금 누가 무엇을 표시해 두었는지는 한 번에 확인할 수 있다
이 표시는 사람이 직접 관리하지 않습니다. 세션이 살아 있는 동안에는 턴이 끝날 때마다 표시 유효 시간이 자동으로 늘어나고, 세션이 완전히 끝나면 표시가 전부 자동으로 풀립니다. 세션이 응답 없이 죽어 버린 경우에도, 그 세션이 더 이상 실행되고 있지 않다는 사실만으로 표시가 회수됩니다. 사람이 손으로 표시를 지워야 하는 경우는 작업을 중간에 포기할 때뿐입니다.
다만 이 절차에도 아직 헷갈리는 지점이 남아 있습니다. 표시가 하나도 없는 상태를 '아무도 일하지 않는다'로 읽기 쉬운데, 실제로는 '아무도 표시하지 않았다'는 뜻일 뿐입니다. 옆에 동료 세션이 붙어 있는데도 표시가 0건이면, 맨 위 항목은 이미 누군가 집었을 확률이 가장 높다는 뜻이므로 그 상태를 함께 보여 주는 장치를 별도로 붙여야 했습니다.
파일을 겹쳐 쓰는 사고와 항목을 겹쳐 시작하는 사고는 겉보기엔 다르지만 뿌리가 같습니다. 둘 다 '누가 이걸 이미 하고 있는지, 또는 하고 있었는지'를 확인할 방법이 없어서 생긴 문제였습니다. 파일 쪽은 이름 하나에 여러 축이 겹치는 문제였고, 항목 쪽은 세션 여러 개가 같은 항목에 겹치는 문제였습니다. 겹침을 막는 방법도 결국 같은 방향이었습니다 — 사람이 조심하기보다, 손대기 전에 먼저 표시하고 그 표시를 기계가 대신 관리하게 만드는 방식입니다.
두 사고 모두에서 공통으로 배운 점은, 여러 에이전트 세션을 동시에 굴리기 시작하는 순간 세션 하나만 있을 때는 문제가 되지 않던 전제가 소리 없이 무너진다는 사실입니다. 세션이 하나면 '지금 이 문서는 나만 보고 있다'거나 '이 항목은 나만 집었다'는 가정이 저절로 성립합니다. 세션 수가 둘 이상으로 늘어나는 순간부터는 그 가정을 성립시켜 주는 장치를 따로 만들어야 하고, 만들지 않으면 늘어난 세션 수만큼 겹침이 늘어납니다.
이번에 정리한 문제는 세션이 첫 지시만으로 얼마나 멀리 갈 수 있는지를 측정한 이야기와 같은 뿌리에서 나왔습니다. Claude Code 자율 실행이 한 턴 만에 멈추는 이유를 잰 글에서는 인수인계 문서가 왜 필요한지를 계측으로 다뤘고, 이 글은 그 문서 자체가 손 작업 때문에 깨지던 지점을 다뤘습니다. 여러 AI 에이전트 세션을 동시에 굴리며 업무 자동화를 설계하는 상황이라면 상담에서 저희가 실제로 쓰는 인수인계 방식을 더 자세히 나눌 수 있습니다.