두 시간마다 Codex 가 제가 검토할 이메일 답변을 준비합니다.
초안 대부분은 훌륭합니다. 하지만 그래도 저는 수정합니다.
오래된 스레드나 대면 대화에서 나온 결정을 추가하거나, 발신자를 알기에 톤을 부드럽게 하거나, 아직 준비되지 않은 약속을 제거하기도 합니다. 초안이 잘 쓰여졌더라도 여전히 일반적으로 느껴질 수 있습니다. 그 일반적인 느낌을 흔히 "AI 슬롭"이라고 부르지만, 이런 경우 문제는 지능이 아닙니다. 부족한 컨텍스트 때문입니다.
누구도 잘못한 것은 없습니다. Codex 는 가진 정보를 바탕으로 작업했고, 제 수정은 Codex 가 없던 컨텍스트를 제공했습니다. 흥미로운 점은 그 수정 자체에도 컨텍스트가 담겨 있다는 것입니다. 제가 무엇을 유지했는지, 무엇을 바꿨는지, 무엇을 거절했는지, 무엇을 보내는 것이 불편했는지 등 그 상황에서 중요했던 것이 드러납니다.
대부분의 자동화는 그 컨텍스트를 보존하지 않습니다. 다음 실행은 동일한 불완전한 그림에서 시작됩니다.
저는 컨텍스트를 두 가지 범주로 생각하는 것이 유용하다고 봅니다.
첫째, 작업을 시작하기 전에 필요한 컨텍스트입니다: 이력, 사실, 제약 조건, 관계, 이전 결정 등.
둘째, 작업 후에 드러나는 컨텍스트입니다: 검토 과정에서 사람이 유지, 변경, 거절, 전송, 또는 보류한 것 등.
그러면 두 개의 루프가 생깁니다. 내부 루프는 작업에 적절한 컨텍스트를 가져와 초안을 생성합니다. 외부 루프는 검토를 통해 학습하고 다음 작업 실행 시 해당 컨텍스트를 사용할 수 있게 만듭니다.
내부 루프: 작업에 컨텍스트 가져오기
이메일의 경우, 내부 루프는 메시지에 답변이 필요한지 판단하고, 관련 컨텍스트를 찾고, 답변 초안을 작성하고, 주장을 확인한 후 검토할 초안을 만듭니다.
워크플로는 코드로 작성되거나 워크플로 빌더로 구축된 워크플로에서 고정될 수 있습니다: 메시지 가져오기, 노이즈 필터링, 분류, 초안 작성, 결과 확인. 또는 Codex 가 "매일 아침 9시에 답장해야 할 이메일 초안을 작성해줘"와 같은 간단한 프롬프트로 어떤 단계를 수행할지 결정할 수 있으며, 새로운 스레드를 검사하고, 관련 이력을 복구하고, 누락된 내용을 조사하고, 답변을 준비하고, 불명확한 부분을 표시합니다.
어느 접근 방식이든 작동할 수 있습니다. 중요한 것은 검색이 작성의 일부라는 점입니다.
답변은 유사한 이메일, 6개월 전 결정, 프로젝트 트래커의 현재 상태, 승인된 소스의 사실 등에 의존할 수 있습니다. Codex 는 해당 컨텍스트를 수집하거나 하위 에이전트에게 특정 질문을 조사하도록 요청할 수 있습니다. 목표는 모든 것을 검색하는 것이 아니라, 답변을 정확하고 구체적으로 만드는 데 필요한 가장 작은 정보 집합을 찾는 것입니다.
저는 작업을 되돌릴 수 있도록 유지합니다: 초안을 작성하고 절대 보내지 않습니다. 편집하기 전에 내부 루프는 제안된 답변, 그 출처, 프롬프트 및 작성 가이드라인의 버전을 저장합니다. 그 기록이 없으면 검토는 일화에 불과합니다. 기록이 있으면 검토는 증거가 됩니다.
외부 루프: 검토에서 컨텍스트 복구하기
외부 루프는 제가 초안을 검토한 후 시작됩니다. 변경 없이 전송되었는지, 편집 후 전송되었는지, 삭제되었는지, 또는 보류 상태로 남았는지 확인합니다.
이 결과들은 각각 다른 의미를 갖습니다. 변경 없이 전송되었다면 초안이 잘 작동했음을 시사합니다. 편집 후 전송되었다면 전후 비교 쌍이 생깁니다. 삭제된 초안은 해석하기 어렵습니다: 잘못되었거나 답변이 필요 없었을 수 있습니다. 보류된 초안은 거의 알려주지 않습니다.
전송된 이메일조차도 제가 수락한 내용만 기록할 뿐, 답변이 효과적이었는지는 알려주지 않습니다. 실제 결과는 후속 응답이나 작업에서 나타날 수 있습니다. 그럼에도 검토는 초안 작성 시점에는 없었던 증거를 추가합니다.
초안과 전송된 버전의 차이는 증거입니다. 자동으로 교훈이 되는 것은 아니며, 자동으로 프롬프트 변경이 되어서도 안 됩니다.
더 짧은 서두는 글쓰기 선호도를 보여줄 수 있습니다. 추가된 사실은 내부 루프가 잘못된 곳을 검색했음을 드러낼 수 있습니다. 제거된 약속은 워크플로에 필요한 확인을 가리킬 수 있습니다. 다시 작성된 문단은 인간이 유지해야 할 판단을 반영할 수 있습니다.
diff 는 무엇이 변경되었는지 보여줄 수 있습니다. 그 의미를 이해하는 것이 외부 루프의 진정한 작업입니다.
외부 루프는 내부 루프를 개선합니다
외부 루프는 다음 내부 루프 실행을 더 좋게 만들기 위해 존재합니다.
Codex 의 초안과 제가 보낸 버전 사이에 무엇이 변경되었는지 검토한 후, "Codex 가 처음부터 더 가깝게 만들기 위해 무엇이 도움이 되었을까?"라고 묻습니다.
답변은 더 나은 작성 가이드라인, 다른 출처, 새로운 검색 단계, 지원되지 않는 약속 확인, 또는 더 이른 시점에 나에게 인계하는 것일 수 있습니다. 모든 편집이 규칙이 되는 것은 아닙니다. 외부 루프는 패턴을 찾고, 가장 작은 유용한 변경을 제안하며, 제가 무엇을 유지할지 결정합니다.
실제로 저는 이러한 승인된 교훈을 간단한 마크다운 파일에 보관합니다. 외부 루프는 해당 파일에 업데이트를 제안하고, 내부 자동화는 다음 이메일 초안을 작성하기 전에 그 파일을 읽습니다.
이것이 검토가 내부 루프를 개선하는 방식입니다: 오늘 제가 수정하는 것이 내일 실행에 유용한 컨텍스트가 됩니다.
두 개의 루프, 두 개의 시계
루프는 서로 다른 속도로 실행됩니다. 내부 루프는 빠르게, 아마도 두 시간마다 도움을 줍니다. 외부 루프는 충분한 예시가 쌓일 때까지 기다리며, 하루가 끝날 때, 열 개의 검토된 초안 후, 또는 예시가 드물 때는 매주 실행됩니다.
외부 루프를 너무 자주 실행하면 일반적이지 않은 사례에서 학습할 수 있습니다. 결코 실행하지 않으면 유용한 수정 사항이 다음 초안과 함께 사라집니다.
동일한 패턴은 데크, 보고서, 브리프, 이슈 트리아지에도 적용됩니다. 각각의 경우, 워크플로가 두 가지 종류의 컨텍스트(첫 번째 초안 전에 알려진 것과 검토 후에 드러난 것)를 모두 사용할 수 있을 때 작업이 개선됩니다.
모델은 이미 충분히 능력이 있습니다. 기회는 동일한 컨텍스트를 매번 다시 발견하지 않도록 하는 워크플로를 구축하는 데 있습니다.
내부 루프는 작업에 적절한 컨텍스트를 가져옵니다. 외부 루프는 작업을 통해 드러난 컨텍스트를 보존합니다.
