그랜트는 여러 해에 걸쳐 상태가 바뀌는 연구 프로그램이고 기획, 제출, 심사, 수행, 연차 관리, 종료로 국면이 넘어갈 때마다 앞 국면이 남긴 것을 꺼내 쓴다. 제안서를 내고 몇 달 뒤 선정 통보를 받는다. 두어 해가 지나 연차 보고를 쓰는 자리에서 두 번째 Aim의 성공 기준을 왜 그 값으로 잡았는지 설명해야 하는 상황이 온다. 제안서 파일을 열면 그렇게 쓴 문장은 있는데 그 문장이 어떤 논문의 어떤 결과에서 나왔는지, 당시 어떤 대안을 검토하고 무엇 때문에 버렸는지는 어디에도 없다. 함께 쓴 사람들은 다른 일로 옮겨 갔고 그때 주고받은 메일을 뒤져도 어느 첨부가 최종 제출본인지 확신할 수 없다. 결국 근거를 다시 만들게 되는데 새로 만든 근거는 제출 당시의 판단과 미세하게 어긋나고 그 어긋남을 설명할 방법도 남아 있지 않다. 아래 사례는 여러 운영 경험에서 반복되는 구조만 남기고 만들었으며 사업명, 기관, 금액, 기간, 심사 결과, 참여자는 쓰지 않는다. 사례로 삼는 과제는 여러 해에 걸친 다년 과제이고 Aim이 셋이며 각 Aim이 서로 다른 종류의 증거에 의존한다는 조건만 갖는다. 나라와 제도에 따라 서식과 규정은 크게 다르지만 국면이 바뀌는 순서와 국면이 바뀔 때 잃어버리는 것은 대체로 비슷하다.
그랜트를 관리한다는 말이 대체로 제안서 파일 하나를 관리한다는 뜻으로 쓰인다. 그 파일이 완성되어 제출되면 관리가 끝난 것처럼 느껴지고 실제로 많은 폴더가 제출일 이후로 갱신되지 않는다. 그런데 제출은 전체 여정의 중간에 있는 한 시점이고 그 뒤로 심사 대응, 수행, 연차 보고, 변경 관리, 종료가 남아 있다. 각 국면은 앞 국면이 남긴 것을 필요로 하는데 남긴 것이 파일 한 개뿐이면 필요한 것을 대부분 다시 만들어야 한다. 과제는 다음 순서로 상태를 바꾼다. 각 상태에는 세 가지를 적어 둔다. 이 상태로 들어오는 조건, 이 상태를 끝냈다고 말할 수 있는 조건, 그리고 그 판정을 내리는 사람이다.
공고 탐색
↓
적합성, 자격, 기한 판단
↓
과학적 질문과 Aim 확정
↓
팀, 예산, 행정 자료 조립
↓
내부 검토와 제출
↓
심사 대응과 수정
↓
선정과 수행 개시
↓
연차 보고, 집행, 변경 관리
↓
종료, 성과 정리, 후속 과제진입 조건과 완료 조건을 적어 두지 않으면 상태 이름이 느낌에 따라 붙고 같은 폴더를 두 사람이 서로 다른 단계로 이해하게 된다. 판정자를 적어 두는 이유는 상태 변경이 대부분 외부 사실에 달려 있기 때문이다. 선정 여부, 협약 체결, 변경 승인은 연구실 안에서 결정되는 일이 아니므로 확인하지 않은 채 상태를 앞당기면 폴더가 실제보다 낙관적인 그림을 그리게 된다. 폴더의 상태를 실제 행정 상태보다 먼저 바꾸지 않는다는 규칙은 사소해 보이지만 지키기 어렵다. 발표가 잘 끝났다는 느낌만으로 수행 단계 폴더를 만들어 두거나 사실상 끝난 과제를 아직 진행 중인 자리에 두는 일이 반복된다. 상태가 실제와 어긋나면 그 폴더를 근거로 만든 모든 요약이 함께 어긋나고 다음 세션의 에이전트는 어긋난 상태를 사실로 읽는다. 상태 변경은 통보 문서, 협약, 공식 회신처럼 확인 가능한 사건에 붙인다. 확인되지 않은 동안에는 상태를 그대로 두고 무엇을 기다리는 중인지만 적는다.
국면이 아홉 자리로 나뉘어도 파일 시스템에 드러나는 구분은 그보다 거칠다. 실제로 쓰는 것은 다섯 단계다. 지금 손을 대고 있는 것, 새로 추진하기로 한 것, 선정되어 수행 중인 것, 종료 처리가 끝난 것, 그리고 지난 회차로 넘어간 것이다. 이 다섯 단계를 문서 안에만 적어 두면 폴더 목록을 훑을 때는 보이지 않으므로 폴더 이름 자체가 상태를 드러내게 한다. 목록을 한 번 내려 보는 것만으로 지금 무엇이 어느 단계에 있는지 보이고 어느 과제가 오래 한곳에 멈춰 있는지도 함께 보인다. 상태를 이름에 얹으면 상태를 바꾸는 일이 곧 폴더를 옮기는 일이 되므로 이동은 자동으로 처리하지 않는다. 되돌릴 수단이 동기화 서비스의 버전 기록뿐인 환경에서는 잘못 옮긴 폴더를 원래 자리로 정확히 복원하기 어렵고 그 사이에 걸어 둔 링크가 끊긴다. 그래서 단계 사이의 이동에는 사람의 확인을 강제한다. 에이전트는 무엇을 옮겨야 하는지 목록을 만들고 옮기는 조작 자체는 사람이 승인한 뒤에 수행한다. 덮어쓰기 전에 먼저 읽고 무엇을 어떻게 바꿀지 보이고 승인을 받는 순서는 이 작업 공간 전체에 같이 걸린다.
과제를 소유한 작업 공간의 최상위 배치가 이 다섯 단계를 그대로 보여 준다.
Grants/
├── AGENTS.md
├── wiki/
│ ├── index.md 제안서와 수행 과제의 현재 상태
│ ├── log.md 구조와 규칙의 변경 이력
│ ├── proposals/ 제안서별 페이지 묶음
│ ├── post-award/ 수행 과제별 페이지 묶음
│ ├── meeting-minutes/ 회의록 목록
│ ├── lifecycle/ 생애주기와 명명 규칙
│ ├── presentations/ 발표 자료 규칙
│ └── references/ 참고 자료
├── {작업 중}/ 지금 손대고 있는 것
├── {추진 중}_{기관}_{약칭}/ 제안 단계
├── {수행 중}_{기관}_{약칭}/ 선정된 과제
├── {종료}/ 끝난 과제
└── {공통 행정}/ 생애주기 밖의 자산폴더 이름은 예시이므로 상태를 나타내는 말은 각자 쓰는 표현으로 정하면 되고 정하고 나면 바꾸지 않는 것이 이름 규칙의 전부다. 다섯 단계가 최상위에 그대로 드러나 있어서 목록을 한 번 내려 보면 지금 손대고 있는 것과 제안 단계와 수행 단계와 끝난 것이 한눈에 갈린다. 공통 행정 자산은 어느 단계에도 속하지 않으므로 생애주기 밖에 따로 둔다. 기관 서식이나 반복해서 쓰는 증빙처럼 과제가 바뀌어도 그대로 쓰는 것이 여기에 들어가고 개별 과제 폴더에 두면 그 과제를 종료 처리할 때 함께 묻힌다. 위키 아래는 제안서와 수행 과제와 회의록으로 갈리고 생애주기와 명명 규칙, 발표 자료 규칙, 참고 자료가 각각 자리를 갖는다. 제안서와 수행 과제가 목록 색인을 따로 갖는 이유는 두 국면에서 열어 봐야 하는 문서가 다르기 때문이다. 제안서 하나마다 위키에 페이지 묶음이 하나씩 붙고 그 묶음이 그 제안서의 통제층이 된다. 최상위 규칙 파일은 강제 규칙과 어디로 갈지만 담고 단계 사이의 이동은 여기서도 사람이 승인한 뒤에 실행한다.
아래 블록은 AI 도구의 채팅창에 그대로 붙여 넣는 프롬프트다. 그랜트 작업 공간을 처음 세울 때 쓰는 프롬프트다. 꺾쇠 안은 자기 경로와 표기로 바꾼다.
<과제 작업 폴더 경로>에 그랜트 작업 공간을 만들어 줘.
- 최상위에 AGENTS.md 하나와 wiki/ 하나를 두고 나머지는 과제 폴더로 둔다
- 과제 폴더 이름은 상태를 나타내는 말을 맨 앞에 붙이고 그 뒤에 기관과 약칭을 쓴다
- 상태는 작업 중, 추진, 수행, 종료, 지난 회차 다섯 가지로 고정한다
- 생애주기에 속하지 않는 공통 행정 자산은 별도 폴더 하나에 모은다
- wiki/에 index.md와 log.md를 만들고 proposals/, post-award/, meeting-minutes/,
lifecycle/, presentations/, references/를 빈 폴더로 만든다
- 제안서를 하나 등록할 때마다 proposals/ 아래에 index, timeline, action register,
communications, scientific plan, 자료 목록 여섯 페이지를 함께 만든다
- AGENTS.md에는 다음 세 줄을 강제 규칙으로 적는다
1. 파일 이름에는 문서명과 버전만 넣고 무엇을 했는지는 붙이지 않는다
2. 과제 폴더 안에 진행 메모나 변경 기록 파일을 만들지 않고 wiki/log.md에 덧붙인다
3. 상태 폴더 사이의 이동은 옮길 목록을 먼저 보여주고 내가 승인한 뒤에만 실행한다과제 하나를 운영하려면 서로 다른 갱신 주기를 가진 문서 몇 개가 필요하다. 이 문서 묶음을 control plane, 곧 과제의 현재 상태와 다음 행동을 결정하는 통제층이라고 부른다. 통제층을 나누는 기준은 갱신 단위다. 마감은 자주 바뀌고 과학적 계획은 드물게 바뀌며 자료의 위치는 파일을 만들 때마다 바뀐다. 갱신 주기가 다른 것들을 한 문서에 몰아넣으면 그 문서는 매번 통째로 다시 읽어야 하고 결국 아무도 읽지 않게 된다. 제안서 하나에 붙는 묶음은 여섯 종류다.
| 문서 | 답하는 질문 |
|---|---|
| 과제 index | 현재 상태는 무엇이고 제출일은 언제이며 기준이 되는 작업본은 어느 파일인가 |
| Timeline | 외부 마감에서 역산한 내부 milestone은 무엇인가 |
| Action register | 누가 무엇을 언제까지 어떤 결과물로 끝내는가 |
| Communications | 외부와 무엇을 주고받았고 무엇이 합의되거나 바뀌었는가 |
| Scientific plan | Aim, 근거, 방법, 위험, 대안이 어떻게 연결되는가 |
| 자료와 렌더링 점검 | 원본 양식과 작업본과 참고자료가 어디에 있고 제출 파일이 제대로 렌더링되는가 |
과제 index는 얇게 유지한다. 현재 상태, 기준이 되는 작업본, 다음 제출일, 지금 가장 크게 열려 있는 미결, 그리고 나머지 문서로 가는 링크면 충분하다. 새 정보가 들어올 때마다 index에 문단을 덧붙이면 몇 주 만에 아무도 끝까지 읽지 않는 긴 문서가 되고 그러면 통제층이 있으나 마나 해진다. 여기에 결정 기록을 일곱 번째 문서로 더하고 싶어지는데 작업 폴더 안에는 진행 메모, 변경 기록, 피드백 파일을 만들지 않는다. 결정과 그 이유는 작업 공간 위키의 로그 문서에 덧붙인다. 로그 항목의 형식은 여덟 항목으로 고정되어 있다. 무엇이 이 작업을 촉발했는지, 그때 원본이 어떤 상태였는지, 무엇을 실행했는지, 무엇을 확인했는지, 무엇을 발견했는지, 무엇을 결정했는지, 무엇이 남았는지, 어떤 산출물이 나왔는지다. 확인 결과에는 다섯 가지 상태 라벨을 붙인다. 확인됨, 불일치, 미확인, 보류, 재실행필요다. 그랜트에서 이 라벨이 특히 값을 하는 이유는, 확인하지 못한 것을 이상 없음으로 적는 순간 그 항목이 마감 전날에 되살아나기 때문이다. 상대 기관의 확약서를 아직 못 받은 상태와 받아서 내용을 대조한 상태는 전혀 다른데, 둘 다 완료로 적히면 그 구분이 사라진다.
성공 기준은 새 세션을 시작한 에이전트에게 이 과제의 현재 상태와 다음 마감, 지금 가장 크게 비어 있는 곳을 물었을 때 세 가지를 모두 문서에서 찾아 답할 수 있는가다. 파일을 두는 폴더도 역할로 나눈다. 기관이 배포한 원본 양식은 받은 그대로 원본 폴더에 두고 절대 덮어쓰지 않으며 손을 대야 할 때는 새 파일명으로 작업본을 만든다. 원본을 한 번 덮어쓰면 나중에 서식이 바뀌었는지 우리가 바꿨는지 구분할 수 없고 서식이 어긋나 반려되면 원인을 찾는 데 며칠이 든다. 지금 제출하는 산출물은 작업 폴더의 루트에 둔다. 최신본을 초안 폴더나 현재본 폴더 아래로 한 단계 내리면 폴더를 열었을 때 무엇을 제출하는 중인지 몇 초 안에 보이지 않고 급할 때 엉뚱한 파일이 올라간다. 새 버전이 나오면 직전 버전을 같은 레벨의 지난 판 폴더로 밀어내고 분석 중간 산출물과 임시 파일은 그 아래나 작업 공간 밖의 임시 폴더로 내린다. 작업 폴더 루트에 임시 폴더를 새로 만들지 않는 것이 이 배치를 유지하는 유일한 방법이다. 파일 이름에는 문서명과 버전만 넣고 무엇을 했는지는 붙이지 않는다. 수정본, 심사의견반영, 최종수정 같은 말이 이름에 붙기 시작하면 이름이 길어지고 정렬이 무너지며 며칠 지나면 어느 것이 최신인지 이름만으로는 판정할 수 없다. 무엇을 왜 바꿨고 어떻게 검증했는지는 로그가 담고 파일 이름은 어느 문서의 몇 번째 판인지만 말한다. 이 구분은 23장에서 정한 owner와 SSOT의 구분을 파일 층위에 그대로 적용한 것이다.
제안서를 쓰기 전에 확정할 것은 이 공고에서 우리가 무엇을 약속할 수 있는가다. 지원 자격, 연구 범위, 수행 기간, 예산의 한도와 항목 제약, 반드시 포함해야 하는 참여 조건, 제출 형식과 분량, 그리고 공식 마감이다. 각 항목은 반드시 지금 유효한 공고 원문에서 확인한다. 지난번에 냈던 제안서나 예전 공고의 기억을 현재 규정으로 쓰는 일이 실무에서 가장 흔한 사고이고 형식 요건 하나가 바뀐 것을 놓쳐 제출 자체가 막히는 경우가 있다. 적합성 판단에서는 두 문장을 분리해야 한다. 우리 연구가 이 공고와 관련이 있다는 문장과, 이 공고에서 경쟁력 있는 약속을 할 수 있다는 문장은 전혀 다른 주장이다. 뒤의 문장은 필요한 예비 결과가 이미 있는지, 약속한 산출물을 기간 안에 낼 수 있는지, 심사자가 물을 만한 반론에 답할 수 있는지를 묻는다. 두 문장을 섞으면 관련성만으로 착수했다가 제출 직전에 예비 결과가 없다는 사실을 발견하게 된다.
에이전트가 이 단계에서 잘하는 일은 대조다. 공고 원문의 요건 목록과 현재 우리가 가진 자료를 나란히 놓고 빈칸을 찾는 일, 이미 수행 중인 과제와 연구 내용이 겹치는지 확인하는 일, 예비 결과가 필요한 Aim이 어느 것인지 표시하는 일은 사람이 빠뜨리기 쉽고 기계는 빠뜨리지 않는다. 반대로 이 공고에 낼 만한가라는 판단은 기관 사정, 사람의 여력, 다른 과제와의 관계가 얽힌 문제여서 사람이 한다. 대조 결과를 받아 판단을 내리고 판단의 이유를 로그에 남기는 순서가 된다. 지원하지 않기로 한 결정도 반드시 남긴다. 이유 없이 지나간 공고는 다음 회차에 다시 검토 대상으로 올라오고 같은 논의를 처음부터 반복하게 된다. 자격이 맞지 않아서인지, 예비 결과가 부족해서인지, 시기가 겹쳐서인지를 한 줄로 적어 두면 다음 회차에는 그 한 줄이 바뀌었는지만 확인하면 된다. 예비 결과가 부족해서 포기한 경우라면 그 부족한 결과가 다음 해의 연구 계획에 항목으로 들어간다.
Aim은 그것을 지탱하는 과학적 근거와 명시적으로 이어 두어야 나중에 다시 쓸 수 있다. 제안서를 쓰는 동안에는 근거가 머릿속에 있어 연결이 필요 없어 보이는데 그 머릿속 연결은 제출과 동시에 사라진다. 심사자가 특정 Aim의 전제를 물었을 때, 연차 보고에서 계획 대비 진척을 설명해야 할 때, 후속 과제에서 같은 논리를 다시 쓸 때 필요한 것은 제안서 문장 뒤에 있던 근거다. 근거와 주장을 짝지어 두는 구조는 19장에서 다뤘고 여기서는 그 구조를 Aim 단위로 적용한다. 위키에 잘 정리된 최신 결과가 있으면 그 결과를 중심으로 Aim을 세우고 싶어진다. 그런데 제안서의 Aim은 지원 사업의 목적과 우리가 실제로 밟을 수 있는 결정 경로를 함께 만족해야 한다. 세 해 안에 결론에 도달할 수 없는 질문, 우리 손에 데이터가 오지 않는 질문, 결과가 어느 쪽으로 나와도 다음 결정이 달라지지 않는 질문은 흥미롭더라도 Aim이 되지 못한다. 여기서 역할이 갈린다. 문헌 근거와 그 근거를 종합한 페이지는 문헌 위키가 소유하고 제안서의 파일과 버전과 검증 절차는 과제 쪽 작업 공간이 소유한다. 두 자리는 서로의 내용을 복사하지 않고 절대경로로 가리키며 과제 쪽 라우팅 표에는 이 위키에 중복해 적지 않는다는 열이 따로 있다. 참조는 양방향이어서 문헌 위키의 아젠다 문서도 과제 폴더의 경로를 되가리킨다. 근거를 과제 폴더로 복사해 두면 원문 쪽 종합 페이지가 갱신되었을 때 제안서 쪽 사본만 옛 판단으로 남고 그 사실을 알아차릴 방법이 없다. 절차는 여섯 단계로 진행한다.
여섯 번째 단계를 건너뛰는 유혹이 크다. 정리 기록에 이미 요약이 있고 그 요약이 대체로 정확하기 때문이다. 그러나 제안서에 들어가는 주장은 심사자가 원문과 대조할 수 있는 주장이고 요약 단계에서 조건이 하나 빠진 문장은 원문 앞에서 과장으로 읽힌다. 어떤 방법이 특정 조건에서만 성립했는데 조건을 떼고 인용하면, 그 한 문장 때문에 Aim 전체의 신뢰가 흔들린다. 이 작업의 산출물은 Aim과 근거를 맞춘 표다. 각 행은 하나의 주장이고 열에는 그 주장을 지탱하는 근거, 근거의 출처, 근거의 강도, 아직 없는 근거, 그 근거를 언제 확보할 계획인지가 들어간다. 표가 완성되면 어떤 Aim이 실제로는 근거 하나에만 매달려 있는지, 예비 결과가 없다고 표시된 칸이 몇 개인지가 눈에 보인다. 근거 하나에만 매달린 Aim은 심사에서 가장 먼저 공격받는다. 예비 결과가 없다고 표시된 칸은 제출 전에 확보하거나 계획 안에서 정직하게 인정해야 한다. 그 표에서 아직 없는 근거 칸이 최소 하나 비어 있어야 하고 모든 칸이 채워졌다면 근거를 정직하게 평가하지 않았을 가능성이 높다.
여러 기관이 함께 제출하는 형태는 어느 제도에서나 반복된다. 이때 가장 먼저 적고 싶어지는 것은 기관별 전문성인데, 전문성 목록은 제안서 문장으로는 필요해도 운영에는 거의 쓸모가 없다. 운영에 필요한 것은 각 참여자가 무엇을 언제 넘겨주는가와 그것이 오지 않으면 무엇이 막히는가다. 산출물과 의존 관계를 먼저 적고 나면 전문성 문장은 그 표에서 자동으로 따라 나온다. 역할은 책임으로 나눈다. 과학적 방향을 정하는 사람, 행정 절차를 책임지는 사람, 데이터를 보유한 쪽, 분석을 수행하는 쪽, 시료를 관리하는 쪽, 예산을 집행하는 쪽은 서로 다른 책임이고 종종 서로 다른 기관에 있다. 한 사람이 여러 책임을 겸하더라도 표에서는 분리해 둔다. 겸직을 하나로 합쳐 적으면 그 사람이 빠졌을 때 무엇이 함께 사라지는지 알 수 없다. 책임을 분리해 두면 담당이 바뀌었을 때 바뀐 칸만 고치면 된다.
여러 기관이 얽히면 시간이 길어진다. 확약서 한 장을 받는 데 걸리는 시간, 서명을 받는 데 걸리는 시간, 기관 내부 검토가 요구하는 여유는 연구자가 통제할 수 없고 대체로 예상보다 길다. 그래서 외부 마감에서 역산할 때 과학적 작업보다 이런 절차의 소요 시간을 먼저 자리에 놓는다. 마감 전 마지막 주에 서명을 요청하는 계획은 희망에 가깝다. 아직 오지 않은 숫자와 문서는 예정으로 표시하고 비워 둔다. 상대 기관이 아직 확정하지 않은 예산 항목, 아직 회신하지 않은 참여 의사, 아직 받지 않은 실적 수치를 그럴듯한 값으로 채우면 그 값이 며칠 뒤 확정값처럼 읽힌다. 에이전트에게 초안 정리를 맡길 때 특히 위험한데, 빈칸이 있는 표를 주면 모양을 맞추려고 값을 채우는 경향이 있기 때문이다. 확정되지 않은 partner 기여는 빈칸으로 두고 미확인 라벨을 붙인 다음 누구에게 무엇을 요청한 상태인지를 함께 적는 편이, 채워진 표를 나중에 검증하는 것보다 훨씬 싸다.
외부 마감 하나는 그 자체로 실행할 수 없는 항목이다. 마감에서 거꾸로 세어 과학적 검토, 예산 확정, 행정 검토, 서명, 업로드, 최종 확인의 자리를 잡아야 비로소 일이 된다. 각 자리에는 그 일을 끝냈다고 말할 수 있는 조건을 붙인다. 예산 확정은 항목별 근거가 붙고 집행 규정에 어긋나지 않는지 확인된 상태이고 최종 확인은 올라간 파일이 우리가 의도한 그 파일인지 다시 열어 본 상태다. 완료 조건을 적지 않으면 모든 항목이 마감 당일에 동시에 걸린다. 일정표에 과제 이름을 통째로 넣는 방식은 잘 작동하지 않는다. 큰 이름이 적힌 세 시간 블록은 무엇을 하면 끝나는지 알 수 없어서 다른 일에 잠식된다. 두 번째 Aim의 논리 수정, 예산 항목과 인건비 대조, 협력 기관 확약서 검토처럼 끝났는지 아닌지가 판정되는 이름을 붙인다. 참여 기관이 함께 모이는 회의와 혼자 준비하는 시간은 다른 층에 둔다. 옮길 수 없는 회의와 옮길 수 있는 준비를 같은 목록에 두면 마감이 가까워질 때 준비 시간이 먼저 밀린다. 일정이 바뀌면 세 곳이 함께 바뀌어야 한다. Timeline의 milestone, action register의 기한, 그리고 실제 일정표다. 셋 중 하나만 고치는 일이 반복되면 어느 것이 현재 계획인지 알 수 없게 되고 마감이 가까워질수록 이 불일치가 비싸진다. 세 곳을 대조해 서로 어긋나는 항목, 담당이 없는 항목, 완료 조건이 비어 있는 항목, 이미 지난 기한을 찾아내는 일은 규칙이 분명하고 사람이 성실하게 하기 어려워서 에이전트에게 맡길 만하다. 다만 무엇을 미루고 무엇을 살릴지는 사람이 정하고 제출 버튼을 누르는 일도 결과의 책임이 사람에게 있으므로 사람이 확인하고 사람이 실행한다.
단계가 나뉜 심사는 여러 제도에서 반복되는 형태다. 서면 심사를 통과하면 발표나 면담이 이어지고 그 사이에 자료를 보완하거나 질의에 답해야 한다. 이 국면에서 가장 자주 일어나는 사고는 새로 만든 자료가 제출본의 약속과 어긋나는 것이다. 발표 자료를 만들면서 메시지를 다듬다 보면 제출본에는 없던 표현이 들어가거나 제출본이 조심스럽게 쓴 대목이 발표에서는 단정으로 바뀐다. 그래서 심사 국면의 통제층에는 네 가지가 연결되어 있어야 한다. 지금 작업 중인 파일, 실제로 제출한 파일, 심사 측이나 주최 측이 요청한 내용, 그리고 발표에서 쓸 근거의 출처다. 제출본은 손대지 않고 지난 판 자리에 그대로 보존한다. 되돌릴 수단이 동기화 서비스의 버전 기록뿐이므로 제출본을 실수로 덮어쓰면 복구가 며칠 전 판본으로 후퇴하는 일이 되고 그사이의 수정이 함께 사라진다. 발표 자료는 제출본의 어느 대목을 어떻게 옮긴 것인지 표시한다. 새로 만든 숫자나 그림이 있다면 제출본의 어떤 값과 대응하는지, 값이 달라졌다면 왜 달라졌는지를 적는다. 값이 갱신되었다는 사실 자체는 괜찮고 갱신을 설명할 수 없으면 그 값을 근거로 쓸 수 없다.
검증 가능한 요구는 따로 모아 별도의 확인 목록으로 관리한다. 분량 제한, 서식, 파일 형식, 발표 시간처럼 맞았는지 틀렸는지가 기계적으로 판정되는 항목이 여기에 들어간다. 내용 논의가 길어지면 형식 확인은 마지막 날로 밀리고 마지막 날에 형식 문제가 발견되면 고칠 시간이 없다. 형식 확인은 내용과 무관하게 정해진 시점에 독립적으로 수행하고 결과를 파일 하나 단위로 확인됨이나 불일치로 적는다. 발표 국면에서 언어 모델이 만든 문장의 유혹이 특히 크다. 매끄러운 요약 문장은 몇 초 만에 나오고 대체로 그럴듯하다. 그러나 이 국면에서 먼저 볼 것은 현재 version의 그림, 숫자, 예산, 인용이 서로 맞는지다. 발표에서 말한 수치가 제출본의 표와 다르면 그때 신뢰를 잃고 매끄러운 문장은 그 손실을 보상하지 못한다. 문장을 다듬는 일은 정합성 확인이 끝난 뒤에 한다.
앞서 밝힌 합성 사례의 과제는 Aim이 셋이고 각 Aim이 서로 다른 종류의 증거에 기댄다. 첫 번째 Aim은 이미 공개된 데이터의 재분석으로 뒷받침되고 두 번째 Aim은 아직 수집하지 않은 데이터를 전제로 하며 세 번째 Aim은 다른 기관이 보유한 자료에 의존한다. 서면 단계를 통과해 발표 국면에 들어갔을 때, 세 Aim은 준비의 성격이 완전히 다르다. 첫 번째는 결과를 보여 주면 되고 두 번째는 왜 지금 없는 데이터를 확보할 수 있는지 설명해야 하며 세 번째는 우리가 통제하지 못하는 조건을 어떻게 관리할 것인지 답해야 한다. 세 Aim을 같은 방식으로 준비하면 가장 약한 하나가 나머지 둘의 평가까지 끌어내린다. 이 차이를 실행 항목으로 옮기면 네 갈래가 나온다. 과학적 논리를 다듬는 일, 그림과 수치를 현재 version에 맞추는 일, 예산과 인력 계획을 발표 내용과 맞추는 일, 그리고 형식과 행정 요건을 확인하는 일이다. Action register에서 갈래를 나누고 각각에 담당과 완료 조건을 붙이면, 과학 논의가 길어져도 나머지 셋의 진척이 보인다. 발표 준비에서 따로 정해 두어야 하는 것이 근거의 경계다. 지금 말할 수 있는 것, 조건을 붙여야 말할 수 있는 것, 아직 말할 수 없는 것을 미리 셋으로 나눠 둔다. 질문을 받으면 아직 없는 결과를 있는 것처럼 말하고 싶어지는데 그때는 통과하더라도 수행 단계에서 그대로 부메랑이 된다. 에이전트에게 예상 질문 목록을 만들게 할 수는 있지만 어느 답변이 우리가 감당할 수 있는 약속인지는 사람이 판정한다.
같은 과제가 여러 기관이 함께 쓰는 형태로 진행되면 문제의 성격이 바뀐다. 원고는 여러 곳에서 동시에 자라고 각 부분의 최신본이 서로 다른 곳에 있으며 분량 제한은 전체에 걸리는데 작성은 부분별로 이루어진다. 한 사람이 자기 절을 늘리면 다른 절이 줄어야 하는데 그 조정을 마감 직전에 하면 문장부터 잘려 나간다. 어느 절이 아직 초안인지, 어느 절이 확정인지, 확정된 절의 파일이 어느 것인지가 보이면 조정이 내용 수준에서 가능해진다. 과학 track과 행정 track은 나란히 굴러가되 섞이지 않게 한다. 과학 쪽은 Aim과 방법과 근거를, 행정 쪽은 서식과 자격 서류와 확약서와 예산 양식과 서명을 다루는데 진행 속도가 다르고 막히는 이유도 달라서 한 문서에 적으면 서로의 진척을 가린다. 다만 마지막에는 합쳐서 본다. 과학 쪽에서 늘린 인력이 예산 쪽에 반영되었는지, 행정 쪽에서 바뀐 기간이 연구 계획의 일정과 맞는지는 각 track 안에서는 보이지 않고 통합 검수에서만 보인다. 어느 파일이 현재 작업본이고 어느 것이 지난 판인지, 어느 파일이 기관에서 받은 원본인지가 목록에 있어야 여러 사람이 같은 파일을 고친다. 문서명과 버전만 담은 이름이 여기서 값을 하는데 작성자 이름이나 수정 내용이 이름에 붙은 파일이 여러 기관에서 동시에 돌아오면 정렬만으로는 최신본을 고를 수 없기 때문이다. 외부에서 온 요청과 합의는 메일 본문에 흩어져 있으므로 요청 내용, 요청한 쪽, 회신 기한, 현재 상태를 한 줄씩 옮겨 적는다. 옮겨 적는 일이 번거로워 보이지만 마감 사흘 전에 어떤 확약서가 아직 안 왔는지 메일함에서 찾는 일과 비교하면 싸다. 에이전트가 잘하는 일이 바로 이 대조여서 자료 목록과 소통 기록과 실행 항목을 함께 읽고 빠진 것을 찾아 달라고 요청하면 사람이 놓친 항목이 대체로 나온다.
선정되면 같은 연구가 다른 규칙 위로 옮겨 간다. 제안서 단계에서 중요했던 것이 설득력이었다면 수행 단계에서 중요한 것은 약속한 것을 실제로 하고 그것을 증명하는 일이다. 참여 인력의 등록과 변경, 인건비의 지급 근거, 집행할 수 있는 항목과 없는 항목, 증빙 서류, 기간을 넘긴 예산의 처리처럼 제안서를 쓸 때는 생각하지 않던 제약이 매일의 결정에 들어온다. 이 제약들은 제도마다 다르고 같은 제도 안에서도 개정되므로 현재 규정 문서에서 확인해야 한다. 수행 단계의 통제층에는 그래서 규정 확인 기록이 별도로 필요하다. 연차 관리의 산출물은 대시보드 한 장이다. 대시보드에는 계획했던 것, 실제로 진척된 것, 계획과 어긋난 부분, 어긋난 이유, 수정 계획, 그리고 다음 보고까지 남은 의무가 들어간다. 계획대로 되지 않은 항목을 적어 두면 다음 해에 그 항목이 어떻게 처리되었는지 이어서 볼 수 있고 종료 시점에 전체 이야기가 복원된다. 어긋남을 지우고 성과만 남기면 대시보드는 보고서의 초안이 될 뿐 운영 문서가 되지 못한다.
여기서 제출 시점에 만든 Aim과 근거의 표가 다시 일을 한다. 연차 보고에서 설명해야 하는 것은 대체로 계획 대비 진척인데, 진척을 설명하려면 애초에 그 계획이 무엇에 근거했는지를 말할 수 있어야 한다. 표가 남아 있으면 각 Aim의 전제가 여전히 유효한지, 그 사이에 나온 새 연구가 전제를 흔들었는지, 예비 결과가 없다고 표시했던 칸이 채워졌는지를 그대로 확인할 수 있다. 표가 없으면 제안서 문장을 다시 읽으며 근거를 역추적해야 하고 그 작업은 제출 당시의 판단을 재현하지 못한다. 제출 시점에 몇 시간을 들여 표를 만들어 두면 몇 해 뒤에 며칠을 아낀다. 과학적 산출과 행정적 준수는 서로 연결되어 있지만 한 문단에 섞어 쓰지 않는다. 논문이 늦어진 이유와 예산 집행이 늦어진 이유는 성격이 다르고 해결 방법도 다르며 확인해야 할 상대도 다르다. 다만 인력 변경처럼 두 track에 동시에 걸리는 사건은 양쪽 모두에 기록하고 서로를 가리키게 한다. 예산과 인사에 관한 최종 판단은 규정과 기관의 승인에 달린 일이므로 에이전트는 누락과 모순을 찾는 데까지만 쓰고 결정은 사람이 한다.
종료 시점에는 성과 목록과 함께 최종 산출물이 어디에 있는지, 데이터와 코드가 어느 저장소에 있고 누가 접근 권한을 가지고 있는지, 어떤 논문이 이 과제의 지원을 받았는지, 아직 끝나지 않은 의무가 남아 있는지, 나중에 감사나 확인 요청이 왔을 때 필요한 자료가 무엇인지를 적는다. 종료 직후에는 모든 것이 기억나므로 이 정리가 불필요해 보이는데 기억은 반년이면 흐려지고 사람은 이동한다. 종료 정리는 몇 해 뒤에 이 폴더를 여는 사람을 위해 쓴다. 그 사람이 자신일 확률도 낮지 않다. 종료된 과제를 진행 중인 자리에 계속 두면 현재 상태를 보는 눈이 흐려진다. 그렇다고 실제 종료 처리가 끝나기 전에 옮기면 남은 의무를 놓친다. 이동은 종료가 행정적으로 확인된 뒤에, 그리고 남은 의무가 없다는 것을 확인한 뒤에 한다. 다섯 단계 사이의 이동은 되돌리기 어렵고 걸어 둔 링크를 끊을 수 있으므로 에이전트에게 자동으로 맡기지 않는다. 무엇을 옮겨야 하는지 목록을 만들게 하고 옮기는 조작은 사람이 확인한 뒤에 수행한다.
다음 과제로 넘길 지식은 판단이다. 선정된 제안서의 표현을 복사해 다음 제안서에 붙이는 방식은 흔하지만 대체로 효과가 없다. 통했던 것은 그 표현이 지탱한 논리 구조였고 다음 공고는 다른 목적과 다른 심사 기준을 가진다. 남겨야 하는 것은 어떤 Aim이 실제로 수행 가능했고 어떤 가정이 틀렸는지, 어떤 일정이 비현실적이었고 어디서 시간이 예상보다 오래 걸렸는지다. 틀린 가정의 기록이 다음 과제에서 가장 값이 나가는 자산이다. 과제 폴더에서 얻은 것 가운데 문헌 위키로 되돌릴 것은 골라서 옮긴다. 수행 과정에서 정리한 방법론, 검증된 개념 설명, 출판된 결과는 다른 작업에서도 쓰이므로 위키의 종합 문서에 반영한다. 반면 예산 내역, 참여자 정보, 심사 관련 기록, 미공개 데이터는 과제를 소유한 자리에 남기고 문헌 위키로 복사하지 않는다. 문헌 위키는 출판된 지식의 층이라서, 준비 중이거나 심사 중인 원고는 제목조차 들어가면 안 되고 진행 중인 원고 메모는 아젠다 자리에 남는다. 복사가 한 번 일어나면 어느 쪽이 정본인지 흐려지고 개인정보와 비공개 정보가 검색되는 자리로 새어 나간다. 무엇을 되돌릴지 판단하는 기준은 출판되었거나 재사용 가능한 지식인가 하나다.
과제 lifecycle을 소유하는 작업 공간은 여러 과제를 담고 다른 업무 공간과 같은 골격을 쓴다. 입구 문서는 강제 규칙과 라우팅 표만 담은 얇은 라우터이고 위키의 index가 지도와 현재 규칙 표를, 위키의 로그가 구조와 규칙의 변경 이력을, 영역별 문서가 실제 절차와 실패 조건과 검증을 담는다. 입구 문서를 읽고 위키 index로 지도를 잡고 로그에서 최근에 무엇이 바뀌었는지 확인한 다음, 해당 영역 문서를 연다. 규칙의 출처는 언제나 현재 영역 문서이고 로그는 이력과 최근 결정을 복원할 뿐 현재 문서를 덮어쓰지 못한다. 입구에 각 과제의 세부를 적기 시작하면 과제가 셋만 넘어도 입구가 가장 오래된 정보를 담은 문서가 된다. 세부는 각 과제의 index가 소유하고 입구는 어느 과제가 지금 살아 있는지만 알려 준다. 수행 중인 큰 과제는 그 폴더 안에 자기 입구 문서와 자기 위키를 따로 갖기도 한다. 상위 규칙에는 하위에 자체 규칙이 있으면 그 안에서 하위가 우선한다고 못 박아 두는데 그렇게 하지 않으면 같은 항목에 두 층의 규칙이 동시에 살아 있게 된다.
공통 규칙과 과제별 상태를 나누는 것이 이 구조의 핵심이다. 생애주기 단계의 이름과 전이 조건, version과 파일 이름 규칙, 원본 보존 규칙, 발표 자료와 외부 자료를 연결하는 방식은 모든 과제에 같이 적용되므로 공통 규칙 문서가 소유한다. 반면 이 과제의 다음 마감이 언제이고 지금 무엇이 막혀 있는지는 과제별 문서가 소유한다. 공통 규칙을 과제마다 복사해 두면 규칙이 바뀔 때 일부만 고쳐지고 시간이 지나면 과제마다 다른 규칙으로 운영된다. 규칙 문장에는 특정 과제 이름, 날짜, 세션을 넣지 않고 상황과 행동과 검증만 적는다. 한 번 있었던 일을 규칙 문장 안에 박아 두면 다음 사람이 그 사례에 해당하지 않는다는 이유로 규칙 전체를 건너뛴다. 다른 업무 공간의 상세 규칙도 이쪽으로 복제하지 않고 실제 의존이나 공유하는 정본이 있을 때만 링크를 만든다. 새 규칙이 필요해지는 시점은 대체로 같은 판단을 세 번째 반복할 때이고 그때 공통 규칙 문서를 고치면 이후의 모든 과제가 함께 따라온다.
세 종류의 과제는 통제층의 모양이 서로 다르다. 심사 단계를 지나는 과제는 현재 기준 파일과 version 계보, Aim 구조, 회의에서 정해진 것, 근거의 경계가 한 index에서 연결되어야 한다. 여러 손이 함께 쓰는 과제는 과학 계획, 일정, 참여자별 소통, 자료 목록, 실행 항목을 각각 다른 문서로 나눠야 동시 진행을 통제할 수 있다. 수행 중인 과제는 기본 정보, 수행 상태, 집행 규칙, 열려 있는 행정 확인, 다음 보고 기한이 중심이고 제안서 시절의 문서 구조와 다르다. 같은 틀을 세 경우에 억지로 맞추면 어느 하나는 반드시 비어 있는 칸으로 가득 찬다. 새 정보가 들어왔을 때 어디에 넣을지는 정보의 종류로 정한다. 기한은 timeline에, 담당과 완료 조건은 action register에, 외부 요청은 communications에, 과학적 변경은 scientific plan에, 파일의 상태는 자료 목록에, 무엇을 왜 바꿨는지는 로그에 넣는다. 과제 index에는 현재 상태와 링크만 유지한다. 과제 index가 길어지기 시작하면 다른 문서들이 갱신되지 않고 있다는 뜻이다. 파트 3이 반복하는 운영 순서는 공고와 메일과 파일에 흩어져 있는 원자료가 들어오고 각 정보가 어느 문서의 소유인지 판정하고 에이전트가 검색과 정리와 누락 탐지를 수행하고 연구책임자가 무엇을 약속하고 무엇을 포기할지 판단하고 제출이나 회신 같은 외부 행동이 일어나고 그 결과와 현재 상태가 소유 문서로 되돌아가는 순환이다. 마지막 단계가 빠지면 다음 순환이 다시 흩어진 원자료에서 시작한다. 순환을 닫는 데 드는 시간은 회신을 보내고 나서 몇 분이면 되지만 그 몇 분을 생략한 대가는 다음 마감 주간에 몰려서 돌아온다.
얇게 유지하는 규칙이 무너지는 조건은 대체로 하나다. 마감이 걸린 주간에 새 정보가 빠르게 들어오면 어느 문서가 그것을 소유하는지 판정하는 몇 초가 아까워지고 판정을 미룬 것이 전부 index로 간다. 그렇게 부풀어 오른 index는 다른 문서가 갱신되지 않고 있다는 표시이므로 길이 자체를 신호로 읽으면 회복 시점을 놓치지 않는다. 상태를 폴더 이름의 접두어로 표현하기로 한 것도 같은 문제에 대한 대응이었다. 작업 중과 신규 추진과 진행 중과 종료와 지난 것 다섯 단계를 폴더 이름에 붙여 두면 그 판정을 문서 안에 적을 필요가 없고 대신 상태를 옮기는 일이 되돌리기 어려워서 옮길 때 사람 확인을 강제한다. 파일 이름에는 문서명과 version만 넣고 무엇을 왜 바꿨는지는 로그가 담게 한 것도 index를 얇게 유지하는 장치다. 이름에 작업 내용을 붙이기 시작하면 파일 이름이 요약이 되고 요약이 된 이름은 아무도 갱신하지 않는다.
규칙 문서 쪽에서 실제로 무너진 사례는 다른 종류였다. 사람 이름과 프로젝트 이름을 규칙 문장 안에 박아 넣기 시작했고 그렇게 하면 규칙이 무한히 자란다는 지적을 받고서야 문제가 보였다. 고친 방향은 규칙 문장을 일반 알고리즘으로 바꾸고 한 번뿐인 결정은 별도의 데이터 파일로 옮기는 것이었다. 규칙에 이름이 박혀 있으면 다음 사람이 자기에게 해당하지 않는 사례라는 이유로 규칙 전체를 건너뛰는데 이 실패는 규칙을 어기는 것과 달리 눈에 띄지 않는다. 지금 규칙 문서에 남긴 형식은 상황과 행동과 검증 셋뿐이고 특정 과제 이름과 날짜와 세션은 넣지 않는다. 새 규칙을 언제 만들지도 정해 두었다. 같은 판단을 세 번째 반복할 때가 그 시점이고 두 번까지는 그 과제의 기록에만 남긴다.