Codex를 상담 상대가 아닌 '작업장'으로 만들기――답변이 아닌 파일을 성과로

AI와의 긴 채팅으로 업무의 현재 위치를 알 수 없게 되면, 가장 먼저 떠오르는 대책은 "AI에게 더 많이 기억하게 하는 것"일지도 모릅니다.

기억 기능을 사용한다. 긴 문맥(Context)을 전달한다. 요약을工夫한다.

저도 시도해 보았습니다. 하지만 AI가 어디까지 기억하고 있는지를 계속 신경 쓰는 것보다, 업무 상태를 AI가 읽을 수 있는 곳에 두는 것이 더 확실했습니다.

이 연재의 제2회에서는 Codex와 GitHub 리포지토리(Repository)를 "상담 도구"가 아닌 "업무의 작업장"으로 사용하는 사고방식을 소개합니다.

답변이 아니라, 리포지토리의 변경을 성과로

중심이 되는 전환은 하나입니다.

AI의 답변을 성과로 하는 운용에서, 리포지토리의 변경을 성과로 하는 운용으로 옮겨가는 것입니다.

통상적인 채팅에서는 AI로부터 좋은 답변을 받은 후에 인간이 마무리 작업을 수행합니다.

AI가 전반부를 빠르게 하더라도, 성과를 올바른 장소로 되돌리는 것은 인간입니다.

이 마지막 "전기(Transcription)\

결과물 (Artifact)을 저장하는 것뿐만 아니라, 결과물을 다시 만들어낼 수 있는 상태를 저장합니다.

그러면 입력이 바뀌더라도 처음부터 다시 설명할 필요가 없습니다. 오류를 발견했을 때도 어느 단계에 원인이 있었는지 조사할 수 있습니다.

업무가 대화 속의 일회성 출력에서, 재실행 가능한 공정 (Process)으로 변합니다.

대화 중심의 운용에서는 AI나 채팅을 바꾸는 것이 두려워집니다. 그만큼 쌓아온 문맥 (Context)을 잃어버리기 때문입니다.

리포지토리 (Repository)에 현재 위치, 판단, 로그, 코드, 출력, 다음 단계가 남아 있다면, 특정 대화가 문맥의 본체가 되지 않습니다.

어떤 AI를 사용하더라도, 처음에 읽을 문서와 작업 규칙을 전달할 수 있습니다. 어려운 정리는 고성능 모델, 정형 작업은 가벼운 모델로 분담하기도 쉬워집니다.

AI에게 일을 가르치는 것이 아니라, 일의 측면을 AI가 읽을 수 있도록 만드는 것입니다.

그렇게 하면 AI는 고정된 파트너가 아니라, 동일한 작업장에 참여할 수 있는 작업자가 됩니다.

처음부터 많은 파일을 준비할 필요는 없습니다.

우선 하나의 LOG.md

에 현재 위치와 다음 단계를 남깁니다. 정보가 늘어나고 실제로 어려움을 겪을 때만 역할별로 파일을 나눕니다.

작업장을 만드는 것 자체가 목적은 아닙니다. 다른 날, 다른 세션, 다른 AI에서도 안전하게 다음 내용을 이어갈 수 있는 것이 목적입니다.

다만, 리포지토리를 준비하는 것만으로는 정보가 다시 묻히게 됩니다. 다음 회차에서는 생로그(Raw log), 현재 위치, 작업 로그를 어떻게 나누고, Markdown을 AI의 외부 기억 (External memory)으로 사용할지를 다룹니다.