AI 루프의 작업 공간이란? 파일 격리·워크트리·산출물 관리

AI 루프의 작업 공간이란? 파일 격리·워크트리·산출물 관리#

두 AI 작업자가 같은 보고서 파일을 동시에 고쳤다고 상상해 보자. 한쪽은 표를 수정하고 다른 쪽은 결론을 작성했다. 마지막에 저장한 쪽의 내용이 앞선 수정을 덮어써 버리면, 두 작업이 모두 완료되었다는 기록만 남고 실제 파일은 불완전할 수 있다.

AI가 파일을 다루는 루프에는 어디에서 일할지, 무엇을 읽을지, 어느 결과물을 최종본으로 볼지가 필요하다. 이때 사용하는 개념이 작업 공간이다. 작업 공간은 입력 파일, 작업 중인 초안, 완료본과 로그의 위치를 정하고 여러 작업이 서로 간섭하지 않게 만드는 구조다.

작업 공간이 루프 엔지니어링에 중요한 까닭은 한 번의 실행이 실패해도 처음부터 다시 하지 않게 만들기 때문이다. 트리거가 시작한 업무에 실행 ID를 부여하고, 각 단계의 산출물을 그 ID 아래에 보관하면 다음 실행은 어느 단계에서 멈췄는지 확인할 수 있다.

작업 공간과 루프 단계의 관계#

단계	작업 공간에 남는 것	다음 판단에 쓰이는 질문
계획	목표·입력 파일 목록·업무 ID	올바른 자료와 범위를 선택했는가
실행	중간 계산, 초안, 도구 반환값	어느 단계까지 실제로 수행했는가
관찰	오류 기록과 산출물 위치	무엇이 실패했고 원본은 안전한가
검증	점검 결과와 승인 상태	최종본으로 옮길 수 있는가

파일을 많이 만드는 것이 목적은 아니다. 완료하지 않은 초안을 완료본으로 혼동하지 않고, 실패한 지점으로 돌아갈 수 있게 하는 것이 목적이다.

‘워크트리’는 모든 AI 작업 폴더의 이름일까#

원고는 워크트리를 ‘AI에게 할당된 격리된 파일 시스템 공간’으로 설명한다. 비유로는 이해하기 쉽지만 용어는 구분해야 한다.

작업 폴더는 AI가 파일을 읽고 쓰는 일반적인 디렉터리다. Git 워크트리는 하나의 Git 저장소에서 별도의 브랜치를 각 디렉터리에 체크아웃해 병렬로 작업하는 기능이다. 샌드박스는 파일·명령·네트워크 등 실행 환경의 접근을 제한하는 격리 장치다.

개념	주로 해결하는 문제	그 자체만으로 보장하지 않는 것
작업 폴더	입력과 산출물 정리	권한 제한, 실행 격리
Git 워크트리	같은 저장소에서 브랜치별 병렬 수정	다른 시스템 파일 접근 차단
컨테이너·샌드박스	프로세스와 자원에 대한 격리	결과물의 품질·사실 검증

폴더 이름을 /workspace로 만들거나 forbidden_paths를 설정 파일에 적었다고 해서 운영체제의 접근이 자동으로 차단되지는 않는다. 실제 파일 권한, 실행 환경, 도구의 제한을 함께 설정해야 한다.

작업 공간이 필요한 세 가지 이유#

파일을 어디에 두었는지 다시 찾기 위해#

AI가 ‘보고서 완료’라고 말해도 어느 파일이 최종본인지 찾지 못하면 업무를 이어갈 수 없다. 문서 위치와 버전, 생성된 시각을 기록해야 다음 세션에서 동일한 결과물을 확인할 수 있다.

같은 파일을 동시에 덮어쓰지 않기 위해#

서로 다른 에이전트가 같은 디렉터리의 report.md를 수정하면 충돌이 생길 수 있다. 작업마다 독립 폴더를 만들고, 결과물을 취합하는 단계를 별도로 두면 원인을 추적하기 쉽다.

실수를 되돌리기 위해#

AI가 원본 데이터를 바꾸거나 완료본을 덮어썼다면 이전 상태를 복원할 방법이 필요하다. 입력은 읽기 전용으로 두고, 초안은 별도 위치에 저장하며, 코드 작업은 버전 관리와 검토 절차를 사용한다.

‘수신함 → 작업 중 → 완료본’ 구조로 시작하기#

원고의 ‘인박스·작업·아카이브’ 아이디어를 간단하게 적용할 수 있다.

project/
  input/            # 사용자가 제공한 원본, 읽기 전용
  work/             # 작업별 초안·중간 결과
  output/           # 검증을 통과한 결과물
  manifest.md       # 현재 작업 상태와 파일 위치

이 폴더 구성은 설명용 예시다. 실제 서버에서 읽기 전용을 강제하려면 파일 권한이나 도구 권한 설정이 필요하다.

주간 보고서 업무라면 input/sales.csv를 읽고 work/weekly-report/draft.md를 만든다. 원본 합계와 결과를 검증한 뒤에만 output/weekly-report.md로 옮긴다. manifest.md에는 어느 자료를 사용했고 어떤 검증을 통과했는지 적는다.

어떤 파일이 ‘완료본’인가#

파일을 저장하는 순간 완료로 표시하면 위험하다. 다음 기준을 통과한 결과만 완료 위치로 이동한다.

파일을 실제로 열 수 있는가?
필요한 섹션이 있는가?
원본 데이터를 훼손하지 않았는가?
중요한 수치와 이름을 확인했는가?
사람의 승인이 필요한 단계라면 승인 상태를 기록했는가?

보고서 PDF를 만들었으나 내부 표가 깨졌다면 파일 생성 성공, 업무 검증 실패다. 상태를 분리해야 다시 생성할 수 있다.

Git 워크트리가 유용한 경우#

작업 대상이 코드 저장소라면 Git 워크트리를 활용할 수 있다. 예를 들어 AI 작업자 A는 버그 수정을, B는 문서 수정을 맡는다. 각자 독립 디렉터리에서 다른 브랜치를 체크아웃하고 변경 내용을 검토한 뒤 병합한다.

하나의 Git 저장소
├─ 주 작업 디렉터리: main
├─ 작업 디렉터리 A: fix-login 브랜치
└─ 작업 디렉터리 B: docs-auth 브랜치

두 작업자가 같은 파일의 같은 부분을 수정했다면 병합 충돌이 발생할 수 있다. 워크트리는 수정하는 동안 서로 덮어쓰지 않도록 작업 디렉터리를 나누는 기능이다. 병합 충돌이나 접근 권한을 자동으로 해결하는 보안 장치는 아니다.

보고서 작성이나 CSV 분석만 한다면 Git 워크트리를 반드시 쓸 이유가 없다. 작업별 폴더나 임시 디렉터리로 충분할 수 있다.

작업 공간 선택 기준#

상황	시작점	추가로 필요한 것
일회성 문서 정리	작업별 임시 폴더	결과물 보관 위치
반복적인 보고서 작성	프로젝트별 영구 폴더	정리·보존 정책
코드의 병렬 수정	Git 브랜치와 워크트리	리뷰·병합 절차
신뢰할 수 없는 코드 실행	제한된 실행 환경	파일·네트워크 권한 통제
여러 사람이 공유하는 자료	공용 저장소와 작업별 분리	접근 제어와 변경 기록

실무 사례: 세 AI 작업자가 자료를 나눠 처리할 때#

한 팀이 시장 자료를 수집하고, 가격표를 계산하고, 최종 보고서를 쓰는 AI 흐름을 만든다고 하자. 세 역할 모두 같은 report.md에 쓰게 하면 누구의 결과인지 알기 어렵다.

더 명확한 구조는 다음과 같다.

input/brief.md                 # 사용자가 승인한 목표
work/research/evidence.md     # 조사 결과와 출처
work/data/prices.csv          # 수치와 계산 근거
work/writer/draft.md          # 두 결과를 사용한 초안
output/final-report.md        # 검증·승인된 결과

조사 작업자는 가격 계산 파일을 수정하지 못하고, 작성 작업자는 원본 가격 파일을 덮어쓰지 않는다. 보고서 작성자가 참조한 자료 버전도 기록한다. 파일의 경로가 역할 사이의 전달 계약이 된다.

로그는 어떻게 관리할까#

에이전트가 작업 폴더를 마음대로 삭제할 수 있다면 같은 폴더에 둔 오류 기록도 사라질 수 있다. 중요한 실행 로그는 AI가 수정할 수 없는 별도 저장소에 기록한다. 다만 로그에도 고객 정보와 비밀값을 남기지 않도록 한다.

직접 해보기: 작은 작업 공간 설계#

보고서 하나를 대상으로 다음 표를 적는다.

질문	내가 정할 답
원본 파일은 어디에 두는가
AI가 수정해도 되는 폴더는 어디인가
최종본은 누가 승인하고 어디에 저장하는가
이전 버전으로 되돌릴 방법은 무엇인가
오래된 임시 파일은 언제 정리하는가

세 번째 부품은 AI에게 넓은 저장 공간을 제공하는 것이 아니다. 작업의 입력과 출력을 분리하고, 충돌과 삭제가 일어났을 때 복구 가능한 구조를 제공하는 것이다.

다음 글의 외부 메모리에는 작업 공간의 모든 파일을 복사하지 않는다. 어느 파일이 현재 초안인지, 어떤 근거가 검증되었는지, 다음에는 무엇을 해야 하는지만 기록하고 실제 파일의 내용은 필요할 때 다시 읽는다.

AI 루프의 작업 공간이란? 파일 격리·워크트리·산출물 관리