아침에 나름 제 생각에는 획기적인 발상이 떠올랐어요. 직원을 한 명 더 고용하는 거지요. 그래서 codex씨를 델꼬 왔어요. 제가 생각했을 때, 이 방식을 통해 제가 기대한 것은 토큰 관리 수월성, 업무 분담에 따른 할루시네이션 현상 감소, 상호 비판을 통한 변증법적 수렴 발전이에요.

구체적으로 설계, 점검, 관리의 업무와 생성, 정리의 업무를 분리했어요. 우리의 신입 코덱스씨는 후자를 담당했지요. 상호간에 소통과 진행도 공유를 위해 일종의 채팅방 겸 log저장소를 개설했어요.

이 체계를 어느 정도는 완성하고 문제를 생성했어요. 문제는 꽝..

따라서 1차 검수뿐만 아니라 2차 검수 과정도 계획했습니다. 2차 검수의 초기 목표는 이 문제가 평가원스러운 문제인가를 검증하는 게 목표였어요.

몇 차례 추가 테스트를 거쳐, 2차 검수의 범위와 과정을 대폭 확대하게 되었어요. '교육과정 정합성 검수 -> 난이도 적절성 검수 -> 평가원 적합도 검수' 이렇게 3축 체제로 진화시켰어요.

자동적인 업무 진행을 위해 scheduling과 모니터링 시스템을 도입하여 이제 에이전트들끼리 피드백을 자동으로 할 수 있게 되었어요.

또 몇 차례 테스트를 진행하다가, 기존 생성된 문제와의 유사성 제한을 3축 체제에 추가하여 4축 체제로 발전시켰어요.

오늘의 가장 큰 문제는 이 4축 체제를 통해 문제를 완전히 걸러내는 시스템 구축이었어요. 4축에 각각의 점수와 단계를 부여해서 특정한 점수나 조건이 만족되지 못하면 검수자인 안티그래비티가 문제를 반려하고 코덱스에게 수정을 요구하는 그런 방식이에요. 이렇게 루프를 돌면서 수정을 거치면 최종적으로 만족스러운 문제가 나올 것이다는 게 제 생각이었죠.

하지만 여러 차례의 테스트에서 검수 과정에서의 빈틈이 조금씩 보이더군요. 그래서 생각해 본 결과.. 하위 에이전트와 그들 간의 동기화를 통해서 한 번에 수 개, 수십 개의 문제를 뽑아내고 각 문제들마다 검수 과정에서의 문제점을 분석하여 검수 체계를 보완하려고 했어요. 또한 표본도 매일 조금씩 늘려서 문제의 가능한 풀과 학습량을 늘리고자 25년도 시행된 고3 9모도 학습시켰어요.

하지이만~ 토큰 이슈로 일단 오늘은 여기까지~~

(저번에 바이브 코딩인가? 얘기하셨던 분이 있으셨는데 제가 그 땐 몰랐지만 지금 제가 하는 게 바이브 코딩이더군요! 죄송해요)